Формальная проверка механизмов консенсуса блокчейна с помощью события-B

Краткое содержание

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

Аннотация

В данном исследовании разрабатывается формально обоснованная система верификации для механизмов консенсуса блокчейна и поведения смарт-контрактов с использованием Event-B и платформы Rodin. В отличие от предыдущих подходов, которые в основном опираются на симуляцию или валидацию изолированных контрактов на основе кейсов, эта работа интегрирует абстракцию с помощью конечных автоматов (FSM), доказательство с инвариантами, моделирование уточнения и верификацию временной логики для анализа доказательства работы (PoW), доказательства ставки (PoS) и механизмов предотвращения двойного расходования. Solidity смарт-контракты абстрагируются в FSM и кодируются как машины Event-B, что позволяет формально спецификовать переходы состояний и ограничения безопасности. Свойства безопасности — включая уникальность транзакций, согласованность состояния, контроль доступа и сохранение инвариантов реестра — проверяются с помощью автоматически сгенерированных обязанностей доказательства в Rodin. Всего было сгенерировано 312 доказательственных обязательств, из которых 287 (92%) были автоматически списаны, а 25 доказаны интерактивно, что привело к полному инвариантному покрытию. Свойства живости были определены в логике вычислительного дерева вычислений (CTL) и проверены с помощью проверки модели, что подтверждало свободу от тупиков и окончательный выбор валидатора в условиях PoS. Предотвращение двойного расходования формально осуществлялось с помощью моделирования реестра, согласованного с соответствующими состояниям, где ограничения уникальности были доказаны для всех достижимых состояний. Логика консенсуса на уровне протокола для PoW и PoS была уточнена на трёх уровнях абстракции, обеспечивая целостность блоков и корректность валидаторов постепенно доработанной. Результаты показывают, что машинно проверенные доказательства обеспечивают проверяемые гарантии корректности, выходящие за рамки симуляционной оценки, создавая строгий и воспроизводимый конвейер верификации, который повышает гарантию корректности и устойчивость на уровне протокола в блокчейн-системах.

Введение

Технология блокчейн эволюционировала в парадигму распределённого реестра, которая позволяет вести децентрализованную документацию без зависимости от централизованных органов. Реплицируя состояния реестра между участниками и достигая согласования с помощью механизмов консенсуса, блокчейн-системы обеспечивают целостность, прозрачность и устойчивость к вмешательству в открытых и враждебных средах. Как описывают Яга и ^др.1, архитектура блокчейна сочетает криптографические примитивы, распределённые протоколы консенсуса и одноранговую коммуникацию, чтобы гарантировать, что валидированные транзакции становятся вычислительно непрактичными для изменений. Основные механизмы консенсуса, такие как Proof of Work (PoW) и Proof of Stake (PoS), регулируют выбор валидатора, проверку блоков и синхронизацию реестра. Кроме того, смарт-контракты расширяют возможности блокчейна, внедряя программируемую логику, которая автономно выполняет заранее определённые правила, позволяя создавать децентрализованные приложения в таких секторах, как финансы, здравоохранение и управление. По мере того как блокчейн-технологии всё чаще внедряются в высокоценных, критически критически важных для безопасности средах, правильность механизмов консенсуса и поведения смарт-контрактов становится необходимым для поддержания операционной^{надёжности 2}.

Несмотря на свою децентрализованность, блокчейн-системы остаются уязвимыми к логическим и протокольным уязвимостям. Атаки на двойное расходование могут возникать, когда ограничения на согласованность реестра не соблюдаются строго. Слабые места на уровне консенсуса, такие как неправильная логика выбора валидаторов или ошибочные правила проверки блоков, а также уязвимости смарт-контрактов, включая повторный вход и неправильный контроль доступа, привели к значительным финансовым потерям в развернутых платформах. Хотя эмпирические фреймворки тестирования и моделирования широко используются для оценки поведения протоколов PoW и PoS, эти подходы предоставляют лишь иллюстративные наблюдения, а не комплексные гарантии корректности. Валидация на основе моделирования не может доказать инвариантное сохранение во всех доступных состояниях или обеспечить свойства безопасности и живости при каждом пути выполнения. Это ограничение подчёркивает необходимость математически обоснованных методов верификации, которые могут строго рассуждать о блокчейн-системах за пределами наблюдательного анализа.

Формальные методы предоставляют такую основу, позволяя спецификацию и верификацию системы с помощью математической^{логики 3,4}. Событие-B расширяет эту парадигму поэтапным уточнением, представляя системы как абстрактные автоматы состояния, в которых состояния системы ограничены инвариантами, а переходы моделируются как охраняемые события⁵. Платформа Rodin автоматически генерирует обязательства по доказательству и поддерживает их сбросок, что позволяет машинно проверять сохранение инвариантов и согласованность^{состояния 6}. Классические методы спецификации, такие как метод^B-7 и^{Z 8}, демонстрируют, как рассуждение на основе инвариантов и формальное уточнение могут обеспечить корректность системы на разных этапах разработки. Эти методы широко применяются в критически важных для миссии и безопасности системах для обеспечения правильности до^{развертывания 9, 10, 11, 12, 13}. Дополнительные расширения, такие как UML-B и графические рамки уточнения, дополнительно демонстрируют масштабируемость моделирования на основе уточнения для сложных промышленных^{систем 14, 15, 16, 17, 18, 19}. Эти достижения показывают, что формальное моделирование, основанное на уточнении, может эффективно управлять сложностью системы, сохраняя при этом высокие гарантии корректности.

Формальные подходы к верификации также изучались для блокчейн-систем. Методы проверки контрактов на основе SMT автоматически проверяют утверждения внутри программ Solidity и могут приводить контрпримеры при возникновении логических^{нарушений 20}. Инструменты, такие как VERISOL, используют конечные абстракции для проверки^{смарт-контрактов 2}, а методы доказывания теорем переводят контракты в формальные рамки рассуждения, такие как F*²¹. Кроме того, семантические формализации виртуальной машины Ethereum позволяют строго анализировать семантику выполнения и обнаружение^{уязвимостей 22}. Аналогично, среды доказывания теорем, такие как Coq, применялись для анализа свойств безопасности, связанных с консенсусом, и транзакционной^{корректности 23}. Хотя эти подходы дают ценные инсайты, они часто независимо сосредоточены либо на корректности на уровне контракта, либо на уровне консенсуса. Системные инварианты реестра, переходы состояний консенсуса и поведение смарт-контрактов редко интегрируются в единую структуру на основе уточнения, которая поддерживает прослеживаемость между уровнями спецификаций и артефактами верификации. Кроме того, многие существующие подходы делают упор на обнаружение уязвимостей или логическую проверку утверждений, а не на систематическое сохранение инвариантов на нескольких уровнях уточнения.

Настоящее исследование устраняет этот методологический пробел, предлагая единую формальную систему верификации, которая интегрирует абстракцию смарт-контрактов Solidity с моделированием уточнения событий B и машинно-проверенным доказательством обязательств в рамках платформы Rodin. Вместо того чтобы рассматривать проверку контрактов и моделирование консенсуса как отдельные задачи, предлагаемая структура формально определяет переходы состояний на уровне протокола для PoW и PoS, ограничения целостности реестра, условия уникальности транзакций и эволюцию состояния смарт-контракта в рамках единой структурированной модели. Свойства безопасности — включая сохранение инвариантов, уникальность транзакций, контролируемые переходы состояний и согласованность реестра — выражаются в виде инвариантов событий-B и проверяются через автоматически сгенерированные обязательства доказательства. Временные и зависящие от порядка выполнения свойства задаются с помощью логики дерева вычислений и проверяются с помощью проверки моделей для обеспечения корректности за пределами статических инвариантов. Ключевой методологический вклад заключается в установлении явной прослеживаемости через слои абстракции: функции солидности абстрагируются в переходы FSM, переходы FSM кодируются как события Event-B, а инварианты вместе с временными спецификациями напрямую связаны с обязательствами по выброшенным доказательствам и результатами проверки модели. Такое структурированное отображение гарантирует, что каждое утверждение о корректности подтверждается машинно проверенными доказательствами и чётко отличает гарантии, основанные на доказательствах, от наблюдений на основе моделирования.

Масштаб этой работы намеренно ограничен для обеспечения точности и аналитической ясности. Моделирование сосредоточено на переходах состояний на уровне протокола для механизмов консенсуса, ограничениях целостности реестра, свойствах уникальности транзакций и поведении состояния смарт-контракта. Сетевые аспекты, такие как задержки распространения сообщений, византийские состязательные стратегии, механизмы разрешения форков и подробная семантика газа Ethereum Virtual Machine, выходят за пределы определённой границы абстракции. Явно определяя эти предположения моделирования, структура гарантирует, что утверждения на верификацию остаются согласованными с формально проверенными доказательствами. Остальная часть этой статьи представляет методологию абстракции, процесс моделирования и уточнения события B, процедуры инвариантной и временной верификации, а также итоговые результаты верификации. Основывая протокол блокчейна и верификацию смарт-контрактов на формальном моделировании на основе уточнения и машинно-проверенных доказательствах, это исследование усиливает методологическую строгость и повышает обеспечение корректности перед развертыванием для децентрализованных реестровых систем.

Протокол

Входные материалы для изучения
В этом исследовании в качестве входных данных для проверки использовались два смарт-контракта Solidity. Первый был контрактом в стиле Simple DAO, использовавшимся как кейс по повторному вступлению. Второй — это упрощённый реестр/переходный контракт, предназначенный для проверки ограничений на уровне контрактов против двойного расходования. Исходный код Solidity служил входом для процессов абстракции и проверки, определённых в этом протоколе. Общий процесс трансформации, используемый для таких контрактов, иллюстрирован на рисунке 1, где показано постепенное преобразование исходного кода Solidity в модели FSM, Event-B и SMV во время верификации.

Моделирование границы
Формальное моделирование сосредоточено на логике управления и потоком смарт-контрактов, включая поведение при входе и выходе функций, внутреннее выполнение и переходы состояний на уровне контракта. Видимость функций (публичная, внешняя, внутренняя и приватная) представлялась вместе с соответствующим поведением стека вызовов, относящимся к анализу повторного входа. Типы абстрактных переходов (вызов, отправка, передача) рассматривались как операции для передачи эфиров.

Инварианты на уровне контракта были определены для обеспечения уникальности транзакций и предотвращения двойного расходования в пределах границы абстракции. Для представления требований к выбору валидации и целостности блока уровень абстракции протокол-логики был определен с помощью переходов состояний на уровне протокола как Proof of Work, так и Proof of Stake.

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

Инструменты и конфигурация
Платформа Rodin использовалась для моделирования, доработки, генерации обязательств по доказательствам и внедрения модели Event-B (версия 3.7.0), которая позволяла доказателям PP, ML, SMT и Atelier-B автоматически и интерактивно выпускать доказательства. nuXmv версии 2.0.0 запускалась на сгенерированных моделях SMV в полном режиме CTL-исследования для проверки CTL-моделей.

Все выполнения верификации выполнялись в контролируемой вычислительной среде с использованием Ubuntu 22.04 LTS, OpenJDK 11 и Python 3.10.12. Web3 (7.6.0), NetworkX (3.4.2), Matplotlib (3.8.0), Graphviz (0.20.3), NumPy (1.26.4) и Pandas (2.2.2) использовались для реализации элементов симуляции и визуализации. Такая конструкция гарантировала возможность воспроизведения формальной верификации и симуляции при выполнении при тех же условиях выполнения.

Рабочий процесс трансформации
Этот процесс верификации состоял из четырёх этапов. Контракты твердости сначала были преобразованы в представление с использованием конечных автоматов (FSM-SC). Модель FSM-SC впоследствии была закодирована в Событии-B с чётко определёнными инвариантами и степенями уточнения. Абстракция FSM-SC была преобразована в модель SMV в nuXmv. Результаты верификации были представлены в виде статистики по списанию доказательств обязательств и проверки модели CTL, а также приводились контрпримеры в качестве кейсов.

Конструкция FSM
Каждый контракт абстрагировался как конечный автомат, определяемый как:

Где:
S = множество состояний
S₀ = начальное состояние
T = отношение перехода
V = карта видимости
G = охранительные предикаты
A = действия/обновления состояния.

Алгоритм 1: построение FSM из Solidity
Вход: исходный код Solidity
Выход: FSM-SC

1) Парсировать абстрактное синтаксисическое дерево контракта Solidity.
2) Создать начальное состояние S₀ из определения конструктора.
3) Для каждой функции солидности f создать отдельный S_f управляющего состояния и записать видимость V(f) ∈ {публичная, внешняя, внутренняя, приватная}.
4) Для каждого оператора в функции f выведите переход t, извлекая защитные предикаты из условий require/assert и действий из обновлений переменных состояния.
5) Добавить переход t к T.
6) Создавать явные типы переходов для операций передачи эфира (вызов, отправка, передача), внутренних и внешних вызовов, delegatecall, самоуничтожения, использования tx.origin, условных ветвей и конструкций циклов.
7) Возврат FSM-SC = (S, S₀, T, V, G, A).

И каждая функция солидности связана с разным управляющим состоянием FSM. Для понимания уязвимостей соответствующие уязвимости потоки исполнения, например, такие потоки с внешними вызовами, за которыми следовали обновления баланса, явно абстрагировались в упорядоченные переходы. Рисунок 2 описывает пример схемы FSM-SC для контракта в стиле SimpleDAO, показывающей, как на этапе строительства абстрагировались состояния входа, переходы внешних вызовов и последовательности обновления состояний.

Кодирование FSM в событие-B
Переход FSM был представлен как конструкции Event-B. Все переходы соответствуют событиям События-B, включая определённых охранников и действия.

Алгоритм 2: кодирование FSM в Event-B
Вход: FSM-SC
Вывод: машина Event-B и контекст

1) Определить STATE_SET и ФУНКЦИЮ в контексте контракта.
2) Объявить переменные, представляющие состояние контроля FSM и состояние на уровне контракта.
3) Представить каждое состояние управления FSM s ∈ S с помощью current_state ∈ STATE_SET.
4) Для каждого перехода (s → s′, g, a) создать событие Event-B E_t с:
5) ГДЕ current_state = s ∧ g
6) ТОГДА current_state := s′ ∥ применимо(a)
7) Кодировать ограничения видимости с помощью защитных, полученных из V(f).
8) Определить инварианты inv1–inv9 для захвата свойств безопасности и согласованности.
9) Определите INITIALIZATION, присваивая значения S₀ и по умолчанию.

Набор состояний, текущее состояние, видимость функций, стек вызовов, временная метка транзакции, статус передачи эфира, флаг вызова делегата, флаг самоуничтожения и условие верификации — это некоторые из переменных, отражаемых в модели Event-B. Инварианты (inv1-inv9) и действия инициализаций (act1-act6) совпадают с действиями формальной спецификации. Рисунок 3 также показывает, как поддерживаются ключевые события, связанные с уязвимостями, особенно переходы, связанные с повторным входом, в кодировании Event-B. На этом рисунке объясняется, как структурные паттерны модели FSM-SC, показанные на рисунке 2, отображаются в проверяемые события Event-B.

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

Алгоритм 3: Уточнение и разряд по доказательству
Вход: Абстрактная машина и усовершенствованная машина
Результаты: Обязательства по доказательствам и статистика

1) Генерировать доказательства для абстрактной машины в Родене.
2) Выполнить автоматические проверки с активным активом и записать результаты разряда.
3) Генерировать обязательства по обеспечению устойчивости к доработке для переработанной машины.
4) Применять автоматические доказательства к обязанностям по уточнению.
5) Выполнять оставшиеся обязательства интерактивно, когда это необходимо.
6) Экспорт статистики доказательств и отчётов о состоянии.

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

Спецификация свойств CTL и проверка модели
Абстракция FSM-SC была преобразована в модель SMV для временной проверки с временем ветвления в nuXmv.

Алгоритм 4: Проверка FSM в SMV и CTL
Вывод: результат проверки PASS/FAIL и контрпримерные трассы (если есть)

1. Записывать управляющие состояния FSM как перечисленное состояние SMV.
2. Преобразовать переходы FSM в охраняемые next(state) назначения.
3. Поддерживать флаги для уязвимых условий, таких как внешние вызовы и обновления баланса.
4. Закодировать свойства CTL в nuXmv и выполнить проверку модели.
5. Если свойство не работает, генерируйте контрпримерные следы, представляющие последовательности переходов FSM.

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

Проверены свойства безопасности
Контракт в стиле Simple DAO, предотвращающий повторный вход, был подтверждён безопасным упорядочением между внешними вызовами и обновлениями состояния через инварианты и ограничения CTL. Там, где это было разрешено, эти охранники проверяли ограничения доступа, чтобы несанкционированные переходы были ограничены инвариантами. Модель уменьшенного реестра проверяла инварианты уникальности сделок и согласованности реестра на уровне предотвращения внутри контракта.

Отчетные результаты
Раздел «Результаты» содержит отчёты по структурным метрикам FSM, метрикам модели Event-B и статистике для подтверждения обязательств и проверки CTL. Результаты формального доказательства и результатов проверки моделей CTL приводятся отдельно для различия доказательств гарантий корректности инвариантами и доказательств проверки времени с использованием временной проверки.

Результаты

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

Настройка среды и проверка зависимостей
Среда выполнения, используемая для трансформации моделей, верификации и моде...

Обсуждение

Формальная и симуляционная верификация демонстрирует, что многоуровневая система верификации, использованная в данном исследовании, способна проверять поведение смарт-контракта, корректность консенсус-механизма и свойство целостности реестра при чётко определённой границе абстракции. Событие-B обеспечивает математически обоснованное представление свойств безопасности, логики течения состояния и предотвращения повторного входа в виде инвариантов и логики на основе^{уточнен...}

Материалы

Список материалов, использованных в этой статье

Имя	Компания	Каталожный номер	Комментарии
Платформа Родина (v3.7.0)	Команда Родена / Фонд Затмения	https://www.event-b.org/install.html	Моделирование, уточнение событий B, а также генерация и сброс доказательств-обязательств
Метод Event-B	Университет Саутгемптона / Сообщество Родин	https://www.event-b.org/	Формальная модельная рамка для спецификации и уточнения инвариантов
nuXmv Проверка моделей (v2.0.0)	FBK (Fondazione Bruno Kessler)	https://nuxmv.fbk.eu/	Проверка символьных моделей свойств CTL
Graphviz (v0.20.3)	Команда Graphviz	https://graphviz.org/	Визуализация FSM и рендеринг графов
Python (v3.10.12)	Фонд программного обеспечения Python	https://www.python.org/downloads	Среда моделирования и выполнения
Web3.py (v7.6.0)	Ethereum Foundation / Contributors	https://web3py.readthedocs.io/	Взаимодействие блокчейна и симуляция транзакций
NetworkX (версия 3.4.2)	Разработчики NetworkX	https://networkx.org/	Моделирование графов блокчейн- и FSM-структур
Matplotlib (v3.8.0)	Команда разработчиков Matplotlib	https://matplotlib.org/	График времени добычи и распределений валидаторов
NumPy (v1.26.4)	Разработчики NumPy	https://numpy.org/	Численные вычисления
Панды (v2.2.2)	Команда разработки Pandas	https://pandas.pydata.org/	Анализ и обработка данных
OpenJDK 11	Сообщество Oracle / OpenJDK	https://openjdk.org/projects/jdk/11/	Требуемое время работы для платформы Родена
Ubuntu 22.04 LTS	Canonical Ltd.	https://ubuntu.com/download	Операционная система для всех экспериментов
Плотность	Ethereum Foundation	https://soliditylang.org/	Исходный язык смарт-контракта, используемый в качестве входных данных
Язык ввода nuXmv (SMV)	FBK	https://nuxmv.fbk.eu/documentation.html	Промежуточное представление модели для проверки CTL