Блокчейн для учёта электроэнергии: как сделать показания счётчиков проверяемыми, а начисления воспроизводимыми

На предприятии заменили трансформаторы тока. Счётчик продолжил передавать показания, система сбора данных работала без аварий, счета выставлялись вовремя. Через несколько месяцев обнаружилось, что в расчётах остался прежний коэффициент трансформации. Электроэнергия учитывалась, информация исправно сохранялась, но начисления были неверными.

В другой ситуации показания правильные, однако поставщик и потребитель используют разные версии тарифного расписания. В третьей после восстановления связи сервер повторно принимает архивные записи и ошибочно включает часть интервалов в расчёт дважды.

Ни одна из этих проблем не исчезает от того, что данные записаны в блокчейн.

Блокчейн (от англ. blockchain - «цепочка блоков») - это децентрализованная распределенная база данных, которая хранит информацию в виде непрерывной последовательности связанных между собой блоков. Записи в такой системе невозможно незаметно подделать или удалить, так как копия базы данных одновременно хранится и обновляется на тысячах независимых компьютеров (нод) по всему миру.

Распределённый реестр способен сделать историю устойчивой к незаметному изменению, но не превращает ошибочное измерение или неверный тариф в правильные. Национальный институт стандартов и технологий США (NIST) определяет блокчейн именно как распределённый журнал, в котором вмешательство в записи обнаруживается и затрудняется, а не как механизм установления физической истины.

Поэтому инженерная постановка задачи должна звучать точнее: создать систему, в которой можно установить происхождение показаний, обнаружить подмену, проверить полноту данных и независимо воспроизвести расчёт счёта. Ошибки при этом должны либо блокироваться формальными проверками, либо исправляться с сохранением первоначальной записи.

Решающим свойством такой системы становится прослеживаемость: от суммы в счёте до исходного измерения, конфигурации узла учёта и действовавшего правила расчёта.

Что действительно можно сделать «неоспоримым»

У показания счётчика есть несколько разных характеристик достоверности.

Первая относится к измерению. Правильно ли подключён прибор, соответствует ли измерительный тракт требуемым метрологическим характеристикам, действуют ли необходимые документы и процедуры контроля?

Вторая относится к происхождению. Какое устройство сформировало запись и можно ли подтвердить это криптографически?

Третья относится к сохранности. Не изменились ли данные после их получения?

Четвёртая относится к начислению. Использованы ли нужные интервалы, коэффициенты, тарифы и правила округления?

Блокчейн непосредственно помогает прежде всего с сохранностью и согласованием истории между участниками. Происхождение обеспечивается электронной подписью и управлением идентификаторами, а метрологическая достоверность требует самостоятельного комплекса мер. Международный документ OIML D 31:2023 рассматривает защиту метрологически значимого программного обеспечения, параметров и журналов событий независимо от применения блокчейна.

Отсюда следует важное ограничение: можно доказать, что конкретное устройство передало конкретное число и что после регистрации оно не изменялось. Но одного этого недостаточно, чтобы доказать соответствие числа фактически потреблённой электроэнергии.

Для внешних данных это известная проблема источника информации: распределённая система принимает сведения из физического мира через устройство или программный посредник. Компрометация такого источника способна привести к регистрации ложных данных без нарушения внутренних правил блокчейна. NIST прямо описывает этот риск для систем, использующих внешние источники данных.

Почему обычной базы данных иногда недостаточно

В централизованной системе поставщик хранит показания, выполняет расчёт и предъявляет результат потребителю. Для проверки потребитель обращается к той же организации, которая сформировала счёт.

Это не означает, что централизованная система обязательно ненадёжна. Электронные подписи, защищённые журналы, резервные копии и независимый архив позволяют построить качественную систему без распределённого реестра.

Блокчейн становится интересен, когда одной историей должны пользоваться несколько самостоятельных участников, а передавать исключительный контроль над ней одному из них нежелательно. Например, поставщик электроэнергии, оператор системы учёта и крупный потребитель хотят иметь согласованные доказательства того, какие данные были приняты для расчёта.

В таком случае распределённый реестр выполняет роль общего журнала: участники поддерживают согласованную последовательность записей по установленным правилам. Именно совместное ведение истории, а не наличие модного формата базы данных, составляет его практический смысл.

Если все серверы, ключи и права изменения правил принадлежат одной организации, независимость участников остаётся формальной. Для внутреннего учёта одного предприятия подписанный архив может оказаться проще и экономически разумнее. Это необходимо проверять до выбора платформы.

Предлагаемый фреймворк

Для практического проекта целесообразно разделить систему на несколько связанных уровней. Ниже представлена предлагаемая архитектура, а не описание готового сертифицированного продукта.

Разделение нужно не только для удобства разработки. У каждого уровня своя ответственность.

Счётчик измеряет. Подсистема сбора доставляет данные. Проверяющий модуль оценивает их допустимость. Реестр фиксирует согласованную историю. Расчётный модуль применяет правила. Проверяющая программа позволяет другой стороне воспроизвести результат.

Попытка возложить все эти функции на один «смарт-контракт» скрывает реальные границы доверия, а не устраняет их.

Паспорт точки учёта важнее отдельного показания

Допустим, в архиве имеется запись: «за интервал учтено 12,4 кВт·ч». Без дополнительного контекста она почти бесполезна.

Нужно знать, к какой точке учёта относится значение, какой регистр прочитан, учитывается ли импорт или экспорт энергии, применены ли коэффициенты измерительных трансформаторов. Необходимо также определить, относится ли значение к вторичной стороне измерительного тракта или уже пересчитано прибором.

Для предлагаемой системы паспорт точки учёта должен иметь собственные версии.

Принципиально важно хранить не только дату внесения новой конфигурации, но и момент начала её действия.

Если трансформаторы тока заменены 15-го числа, а сведения внесены 17-го, система должна различать время события и время регистрации. Иначе даже неизменяемый журнал не позволит правильно пересчитать промежуточный период.

OIML D 31:2023 предусматривает прослеживаемость изменений метрологически значимых параметров, включая время события, идентификацию параметра и его старое и новое значения. Это полезная основа для проектирования подобной истории конфигураций.

Как должна выглядеть измерительная запись

Записывать в реестр только число и время недостаточно. В предлагаемой модели запись содержит идентификатор точки учёта, идентификатор прибора, тип регистра, значение и единицу, начало и конец интервала, порядковый номер, признаки качества и ссылку на конфигурацию.

Отдельно сохраняются время приёма сервером и сведения о подписи.

Следует различать как минимум три момента: когда измерялась энергия, когда данные получил сервер и когда подтверждение вошло в реестр. Задержка связи может составлять часы, но это не переносит потребление в другой тарифный период.

Время включения в блокчейн также не является автоматическим доказательством точного времени измерения. Оно относится к регистрации транзакции в конкретной системе. Правильность часов прибора и порядок их корректировки остаются самостоятельными задачами.

Накопительные и интервальные показания

При использовании накопительного регистра расход определяется разностью:

Если требуется внешний коэффициент пересчёта:

Но коэффициент  допустимо применять только тогда, когда значения регистра ещё не приведены к нужной стороне учёта. Повторное применение уже учтённого коэффициента создаст ошибку, которую блокчейн лишь аккуратно зафиксирует.

При интервальном учёте расчёт опирается на последовательность значений за отдельные промежутки времени. В этом случае нужно проверять отсутствие пропусков, дублей и пересечений, а также согласованность интервалов с накопительными регистрами.

Предлагаемый фреймворк должен поддерживать оба вида данных и явно описывать их взаимосвязь.

Подпись счётчика и подпись шлюза

Наиболее прозрачная цепочка происхождения получается, если измерительная запись подписывается самим счётчиком. Проверяющая сторона может убедиться, что данные сформированы устройством, которому принадлежит соответствующий ключ.

Но это не отменяет проверки состояния прибора и измерительного тракта. Подпись удостоверяет происхождение сообщения, а не исправность всех физических компонентов.

Если счётчик не поддерживает нужную криптографическую функцию, подписывать данные может шлюз сбора. Тогда доказательство имеет другую границу: шлюз подтверждает, какие сведения он получил или сформировал. Без дополнительной защиты нельзя автоматически приравнять это к подписи самого измерительного прибора.

Такое различие должно быть отражено в документации системы и в доступном пользователю статусе записи. Риск внешнего источника данных сохраняется независимо от того, насколько надёжен сам реестр.

Для управления ключами потребуется отдельный регламент: выпуск, привязка к устройству, замена, отзыв, восстановление после отказа и расследование компрометации. Потеря доверия к ключу не должна приводить к молчаливому удалению старой истории.

Какие проверки выполняются до регистрации

Криптографически корректная запись ещё не обязательно пригодна для начисления. Поэтому предлагается разделить приём данных и допуск к расчёту.

При приёме проверяются формат, подпись, полномочия отправителя и уникальность записи. Затем оцениваются последовательность, временные границы и признаки качества.

Для накопительного регистра уменьшение значения требует объяснения: замена прибора, переполнение регистра, сброс или ошибка. Для интервального профиля пропуск не должен превращаться в нулевое потребление без специального правила.

Пределы правдоподобия не следует превращать в средство автоматического «исправления» показаний. Необычное потребление может быть реальным. Проверка должна обнаружить отклонение, а решение о его природе принимается по установленной процедуре.

Что хранить в блокчейне, а что оставить в архиве

Передавать в общий реестр весь профиль каждого потребителя не всегда разумно. Это увеличивает объём хранения, усложняет доступ и может раскрывать чувствительную информацию.

Для предлагаемой архитектуры первичные записи целесообразно сохранять в защищённом архиве, а в реестре фиксировать их криптографические отпечатки, идентификаторы пакетов, периоды, статусы проверки и ссылки на действовавшие конфигурации.

Хеш представляет собой результат криптографического преобразования данных. При изменении исходного содержимого проверка соответствия хешу позволяет обнаружить подмену. На таких связях между блоками основана и проверяемость истории блокчейна.

Для большого пакета можно использовать дерево Меркла: оно позволяет сформировать компактное доказательство включения отдельной записи в зафиксированный набор. В проекте это удобно для проверки одного интервала без передачи всего архива.

Но хеш не заменяет сам документ. Если исходный файл утрачен, его отпечаток не восстановит показания. Поэтому доступность архива, резервирование и сроки хранения остаются обязательной частью проекта.

Нужно также заранее определить однозначное представление подписываемых данных. Два файла с одинаковым смыслом, но разными форматами дат или порядком полей могут иметь разные хеши. Для этого вводятся правила сериализации и версия формата.

Почему согласование записей не равно проверке счётчика

Участники распределённого реестра согласуют, какие допустимые транзакции входят в историю и в каком порядке. Они не выполняют повторное физическое измерение энергии.

Если все узлы получили одну ложную, но формально корректную запись, достижение согласия между ними не делает запись истинной. Это граница возможностей консенсуса, вытекающая из зависимости от внешнего источника.

Для коммерческого учёта логично рассматривать разрешительную сеть: участники заранее известны, а права выпуска и подтверждения записей определены соглашением.

При выборе механизма согласования необходимо описать модель отказов. Защита от отключения сервера и защита от намеренного нарушения протокола участником - разные требования. Нельзя объявлять систему защищённой от недобросовестных действий только потому, что у неё несколько копий данных.

В проекте должны быть определены независимые владельцы узлов, правила подтверждения, порядок изменения состава сети и условия восстановления после разделения связи. Архитектура распределённого реестра строится именно на согласованных правилах проверки и репликации.

Как сделать начисление воспроизводимым

Для простого зонного тарифа стоимость энергии можно представить как:

где Еi - энергия за интервал, Ti  - применимый к нему тариф.

Полный счёт может включать другие составляющие, поэтому формула не является универсальной моделью договора энергоснабжения. В предлагаемом фреймворке каждое дополнительное начисление получает собственное правило, версию и основание.

Расчёт должен ссылаться на зафиксированный набор исходных данных. Вместе с результатом сохраняются версия тарифного расписания, конфигурации учёта, расчётного алгоритма и правила округления.

Нужно различать два вида изменений: новый тариф, действующий с определённого момента, и исправление ранее ошибочно внесённого тарифа. Они имеют разный смысл и не должны оформляться одинаковым редактированием строки.

Смарт-контракт не гарантирует правильный счёт

Смарт-контракт - программа, работающая по правилам блокчейн-системы. Для одинаковых входных данных её исполнение должно давать согласованный результат. Но одинаковый результат может быть ошибочным, если ошибочна сама программа или исходные данные.

Поэтому в предлагаемой системе необходимы эталонные расчётные примеры и независимая проверяющая реализация. Отдельно тестируются границы тарифных периодов, изменение коэффициентов, пропуски, замены приборов и округление.

Денежные величины и энергию целесообразно представлять целыми числами в заранее выбранных единицах либо десятичными значениями с фиксированным масштабом. Порядок округления задаётся явно. Это проектное требование обеспечивает одинаковый расчёт в разных программных средах.

Разбор ошибки с коэффициентом трансформации

Вернёмся к ситуации с заменой трансформаторов тока.

До замены действовала конфигурация А. После замены должна действовать конфигурация Б. Однако оператор внёс её позже.

В предлагаемой системе изменение оформляется отдельным событием с моментом фактического начала действия, временем регистрации, документом-основанием и подтверждениями уполномоченных участников.

Первый расчёт не удаляется. Формируется новая версия начисления, которая ссылается на исходную и объясняет причину перерасчёта.

Так система не делает ошибку невозможной. Она делает невозможным её незаметное исправление в пределах принятой модели защиты и сохраняет материал для проверки. Именно устойчивость к скрытому изменению, а не абсолютную невозможность любых изменений, следует связывать с блокчейн-реестром.

Как исправлять данные, не разрушая историю

Неизменяемость не должна означать запрет на исправление.

Предлагается использовать связанные события: первоначальная запись, обнаружение ошибки, решение о корректировке и новый расчёт. У каждой корректировки указываются основание, автор, время и затронутый период.

Особенно важно различать измеренные и восстановленные данные. Если профиль утрачен, расчётное замещение не становится показанием счётчика даже после согласования сторонами.

В интерфейсе и выгрузке эти категории должны оставаться различимыми. Иначе система сохранит целостность истории, но утратит смысловую честность.

Такой подход согласуется с общим требованием защищать значимые журналы и сохранять прослеживаемость изменений. OIML D 31:2023 отдельно рассматривает защиту журналов событий от удаления и недопустимого изменения.

Что получает потребитель вместе со счётом

Одного номера транзакции недостаточно. Проверяемость должна быть доступна без обращения к внутренней базе поставщика.

Предлагаемый пакет доказательств включает исходные показания или согласованный доступ к ним, подписи, сведения о конфигурации, применённые тарифы, перечень замещений и корректировок, версию расчётного алгоритма и подтверждение фиксации данных в реестре.

Проверяющая программа должна последовательно ответить на вопросы: относятся ли данные к нужной точке, проходят ли проверку подписи, совпадают ли с зафиксированными отпечатками, полон ли период и воспроизводится ли итог.

Важно обеспечить доступ не только к красивому экрану личного кабинета, но и к машиночитаемому экспорту. Иначе независимость проверки останется заявлением.

Конфиденциальность и юридическая применимость

Общий журнал не означает общий доступ ко всем показаниям. Для предлагаемой архитектуры доступ к профилям ограничивается ролями, а персональные и договорные сведения по возможности отделяются от технических подтверждений.

Сам по себе хеш также не следует считать универсальным средством обезличивания. Особенно если исходные данные имеют небольшой набор возможных значений и могут проверяться перебором. Поэтому проект должен отдельно учитывать защиту содержимого и защиту метаданных.

Криптографическая проверяемость не равнозначна автоматическому юридическому признанию. Применимость записей зависит от законодательства конкретной страны, требований к коммерческому учёту, электронным документам, подписям и соглашениям сторон.

OIML D 31 полезен как международный ориентир по программному обеспечению средств измерений, но не является универсальным разрешением использовать любую блокчейн-запись как расчётное доказательство. Сам документ учитывает зависимость отдельных требований от национального законодательства.

Как проверить фреймворк до внедрения

Пилот следует проводить параллельно с действующим учётом, не подменяя им сразу коммерческие расчёты.

Испытания должны включать не только нормальную передачу данных. Необходимо воспроизвести потерю связи, повторную доставку, ошибочные часы, замену счётчика, изменение коэффициента, отзыв ключа, позднее поступление архива и перерасчёт.

Отдельная группа тестов проверяет вмешательство: изменение файла в архиве, попытку подменить конфигурацию, выпуск транзакции без полномочий и недоступность части узлов.

Критерии успеха формулируются измеримо: доля полноценных интервалов, время обнаружения пропуска, возможность независимого воспроизведения начисления, время подготовки доказательств и доступность исходных данных.

Обещание «ошибок не будет» для приёмки бесполезно. Проверяемое требование выглядит иначе: повторная доставка не увеличивает начисление, конфликтующие записи обнаруживаются, исправление сохраняет исходную версию, а независимая программа получает тот же результат по тем же входным данным.

Где заканчивается технология и начинается ответственность

Блокчейн не переносит ответственность со специалистов на алгоритм. Кто-то должен подтвердить конфигурацию узла учёта, ввести правильный тариф, обеспечить хранение архива и рассмотреть спорное событие.

Ценность распределённого реестра появляется тогда, когда эти действия становятся наблюдаемыми для участников и связаны с конкретными полномочиями. Подпись отвечает на вопрос об авторе сообщения, журнал - о последовательности событий, расчётная модель - о происхождении суммы. Ни один из этих механизмов не заменяет остальные.

Поэтому удачный проект начинается не с выбора блокчейн-платформы, а с определения того, что именно стороны хотят иметь возможность доказать. Если по любому начислению можно восстановить путь от измерения до суммы и увидеть все последующие исправления, система выполняет свою инженерную задачу. Если доступен только неизменяемый итог без объяснимых исходных данных, спор лишь перенесён в более сложную информационную среду.

Андрей Повный