Formalna weryfikacja mechanizmów konsensusu blockchain z wykorzystaniem Event-B

Podsumowanie

Niniejsze badanie przedstawia formalne ramy weryfikacji mechanizmów konsensusu blockchain oraz smart kontraktów, wykorzystujące metodę Event-B. Podejście to łączy abstrakcję z reprezentacji, dowod oparty na niezmiennicach oraz kontrolę modeli czasowych z formalnymi kontrolami bezpieczeństwa, żywotności i odporności na podwójne wydatki przed wdrożeniem.

Streszczenie

Niniejsze badanie opracowuje formalnie ugruntowany framework weryfikacji mechanizmów konsensusu blockchain oraz zachowania smart kontraktów, wykorzystując Event-B i platformę Rodin. W przeciwieństwie do wcześniejszych podejść, które opierały się głównie na symulacji lub walidacji opartej na przypadkach dla izolowanych kontraktów, praca ta integruje abstrakcji za metodą Maszyny Skończonej Stanu (FSM), dowody sterowane inwariantami, modelowanie udoskonalenia oraz weryfikację logiki czasowej do analizy Proof of Work (PoW), Proof of Stake (PoS) oraz mechanizmów zapobiegania podwójnemu wydatkowi. Smartkontrakty Solidity są abstrahowane w FSM i kodowane jako maszyny Event-B, co umożliwia formalną specyfikację przejść stanów i ograniczeń bezpieczeństwa. Właściwości bezpieczeństwa — w tym unikalność transakcji, spójność stanów, egzekwowanie kontroli dostępu oraz zachowanie niezmienne w księdze — są weryfikowane poprzez automatycznie generowane obowiązki dowodowe w Rodin. Łącznie wygenerowano 312 zobowiązań dowodowych, z czego 287 (92%) zostało automatycznie umorzonych, a 25 udowodniono interaktywnie, co skutkowało całkowitym niezmienniczym pokryciem. Właściwości żywotności były określane w Computation Tree Logic (CTL) i weryfikowane za pomocą modelowego sprawdzania, potwierdzając swobodę martwego zaglądania i ostateczny wybór walidatora w warunkach PoS. Zapobieganie podwójnym wydatkom było formalnie egzekwowane za pomocą modelowania księgi rejestrowej spójnego ze stanem, gdzie ograniczenia unikalności były dowodzone we wszystkich dostępnych stanach. Logika konsensusu na poziomie protokołu dla PoW i PoS została udoskonalona na trzech poziomach abstrakcji, zapewniając integralność bloku i poprawność walidatora poprzez stopniowe udoskonalanie. Wyniki pokazują, że dowody sprawdzone maszynowo zapewniają weryfikowalne gwarancje poprawności wykraczające poza ocenę opartą na symulacji, tworząc rygorystyczny i powtarzalny proces weryfikacji, który zwiększa zapewnienie poprawności i odporność na poziomie protokołu w systemach blockchain.

Wprowadzenie

Technologia blockchain ewoluowała w paradygmat rozproszonego rejestru, który umożliwia zdecentralizowane prowadzenie dokumentacji bez polegania na scentralizowanych organach. Poprzez replikację stanów księgi między uczestniczącymi węzłami i osiąganie porozumienia poprzez mechanizmy konsensusu, systemy blockchain zapewniają integralność, przejrzystość i odporność na manipulacje w otwartych i przeciwstawnych środowiskach. Jak opisują Yaga i ^in.1, architektura blockchain łączy prymitywy kryptograficzne, rozproszone protokoły konsensusu oraz komunikację peer-to-peer, aby zapewnić, że zweryfikowane transakcje stają się obliczeniowo niepraktyczne do modyfikacji. Podstawowe mechanizmy konsensusu, takie jak Proof of Work (PoW) i Proof of Stake (PoS), regulują wybór walidatora, walidację blokową oraz synchronizację księgi rachunkowej. Ponadto inteligentne kontrakty rozszerzają możliwości blockchaina, integrując programowalną logikę, która autonomicznie wykonuje zdefiniowane reguły, umożliwiając zdecentralizowane aplikacje w sektorach takich jak finanse, opieka zdrowotna i zarządzanie. W miarę jak technologie blockchain są coraz częściej wdrażane w środowiskach o wysokiej wartości i krytycznym dla bezpieczeństwa, zapewnienie poprawności mechanizmów konsensusu i zachowania smart kontraktów stało się kluczowe dla utrzymania niezawodności operacyjnej².

Pomimo zdecentralizowanego charakteru, systemy blockchain pozostają podatne na luki logiczne i protokołowe. Ataki podwójnego wydatkowania mogą wystąpić, gdy ograniczenia spójności księgi nie są rygorystycznie egzekwowane. Słabości na poziomie konsensusu, takie jak błędna logika wyboru walidatora czy wadliwości reguł walidacji bloków, a także podatności w smart kontraktach, w tym ponowne wprowadzanie i nieprawidłowa kontrola dostępu, prowadziły do znacznych strat finansowych na wdrożonych platformach. Chociaż ramy testów empirycznych i symulacji są szeroko stosowane do oceny zachowania protokołów PoW i PoS, te podejścia dostarczają jedynie obserwacji ilustracyjnych, a nie kompleksowych gwarancji poprawności. Walidacja oparta na symulacji nie może udowodnić zachowania niezmienności we wszystkich osiągalnych stanach ani zapewnić właściwości bezpieczeństwa i żywotności na każdej ścieżce wykonania. To ograniczenie podkreśla potrzebę matematycznie ugruntowanych technik weryfikacji, które potrafią rygorystycznie rozważać systemy blockchain poza analizą obserwacyjną.

Metody formalne zapewniają takie podstawy, umożliwiając specyfikację systemu i weryfikację poprzez logikę matematyczną ^3,4. Zdarzenie-B rozszerza ten paradygmat poprzez stopniowe udoskonalanie, reprezentując systemy jako abstrakcyjne maszyny stanów, w których stany systemu są ograniczone przez inwarianty, a przejścia modelowane jako zdarzenia chronione⁵. Platforma Rodin automatycznie generuje zobowiązania dowodowe i wspiera ich zwolnienie, umożliwiając mechaniczną weryfikację zachowania niezmienników i spójności stanu⁶. Klasyczne techniki specyfikacji, takie jak B-Metoda⁷ i Z⁸, pokazują, jak rozumowanie oparte na niezmienniczości i formalne udoskonalanie mogą zapewnić poprawność systemu na różnych etapach rozwoju. Metody te były szeroko stosowane w systemach krytycznych dla misji i bezpieczeństwa, aby zapewnić poprawność przed wdrożeniem 9,10,11,12,13. Dodatkowe rozszerzenia, takie jak UML-B i graficzne ramy udoskonalania, dodatkowo pokazują skalowalność modelowania opartego na udoskonaleniu dla złożonych systemów przemysłowych 14,15,16,17,18,19. Te zmiany pokazują, że modelowanie formalne oparte na udoskonaleniu może skutecznie zarządzać złożonością systemu, jednocześnie zachowując silne gwarancje poprawności.

Formalne podejścia weryfikacji były również badane dla systemów blockchain. Techniki weryfikacji kontraktów oparte na SMT automatycznie sprawdzają twierdzenia w programach Solidity i mogą generować kontrprzykłady, gdy wystąpią naruszenia logiczne²⁰. Narzędzia takie jak VERISOL wykorzystują apstrakcje skończone do weryfikacji smart kontraktów², podczas gdy podejścia potwierdzające twierdzenia tłumaczą kontrakty na formalne ramy rozumowania, takie jak F*²¹. Ponadto formalizacje semantyczne Maszyny Wirtualnej Ethereum umożliwiają rygorystyczne rozumowanie dotyczące semantyki wykonania i wykrywania podatności²². Podobnie środowiska potwierdzające twierdzenia, takie jak Coq, zostały zastosowane do analizy właściwości bezpieczeństwa związanych z konsensusem oraz poprawności transakcyjnej²³. Chociaż te podejścia dostarczają cennych informacji, często koncentrują się niezależnie na poprawności na poziomie kontraktu lub na poziomie konsensusu. Inwarianty rejestru na poziomie systemowym, przejścia stanów konsensusu oraz zachowanie smart kontraktów rzadko są zintegrowane w ramach jednolitego systemu opartego na udoskonaleniu, który utrzymuje możliwość śledzenia między warstwami specyfikacji i artefaktami weryfikacyjnymi. Ponadto wiele istniejących podejść kładzie nacisk na wykrywanie podatności lub sprawdzanie asercji logicznych, zamiast systematycznego zachowania niezmienników na wielu poziomach udoskonalenia.

Niniejsze badanie wypełnia tę lukę metodologiczną, proponując jednolity formalny system weryfikacji, który integruje abstrakcji Solidity Machine-Machine (FSM) z modelowaniem udoskonalającym Event-B oraz maszynowo sprawdzanym zwolnieniem zobowiązań dowodowych w platformie Rodin. Zamiast traktować weryfikację kontraktów i modelowanie konsensusu jako oddzielne problemy, proponowane ramy formalnie określają przejścia stanów na poziomie protokołu dla PoW i PoS, ograniczenia integralności księgi rachunkowej, warunki unikalności transakcji oraz ewolucję stanu inteligentnych kontraktów w ramach jednego modelu strukturalnego. Właściwości bezpieczeństwa — w tym zachowanie niezmienniczego, unikalność transakcji, kontrolowane przejścia stanów oraz spójność księgi — wyrażane są jako inwarianty Zdarzenia-B i weryfikowane poprzez automatycznie generowane zobowiązania dowodowe. Właściwości zależne od czasu i kolejności wykonania są określane za pomocą logiki drzewa obliczeniowego i weryfikowane przez sprawdzanie modelu, aby zapewnić poprawność wykraczającą poza statyczne inwarianty. Kluczowym wkładem metodologicznym jest ustanowienie jawnej śledzowalności na warstwach abstrakcji: funkcje stałości są abstrahowane do przejść FSM, przejścia FSM kodowane jako zdarzenia B, a inwarianty wraz ze specyfikacjami czasowymi są bezpośrednio powiązane z uniespełnionymi zobowiązaniami dowodowymi i wynikami z sprawdzania modelu. To ustrukturyzowane mapowanie zapewnia, że każde twierdzenie o poprawności jest poparte dowodami zweryfikowanymi przez maszynę i wyraźnie odróżnia gwarancje oparte na dowodach od obserwacji symulatorskich.

Zakres tych prac jest celowo ograniczony, aby zapewnić precyzję i analityczną klarowność. Modelowanie koncentruje się na przejściach stanów na poziomie protokołu dla mechanizmów konsensusowych, ograniczeń integralności księgi rachunkowej, unikalności transakcji oraz zachowania stanu smart kontraktów. Aspekty na poziomie sieci, takie jak opóźnienia propagacji wiadomości, bizantyjskie strategie adwersarialne, mechanizmy rozwiązywania forków oraz szczegółowa semantyka gazu Ethereum Virtual Machine, wykraczają poza określone granice apstrakcji. Poprzez wyraźne zdefiniowanie tych założeń modelowania, ramy zapewniają, że twierdzenia weryfikacyjne pozostają zgodne z formalnie zweryfikowanymi dowodami. Pozostała część artykułu przedstawia metodologię abstrakcji, proces modelowania i udoskonalania Event-B, procedury weryfikacji inwariantnej i czasowej oraz wynikające z tego wyniki weryfikacji. Opierając protokół blockchain i weryfikację smart kontraktów na formalnym modelowaniu opartym na udoskonaleniu oraz dowodach sprawdzonych maszynowo, badanie to wzmacnia rzetelność metodologiczną i zwiększa zapewnienie poprawności przed wdrożeniem dla zdecentralizowanych systemów rejestrowych.

Protokół

Dane wejściowe do badania
W tym badaniu użyto dwóch inteligentnych kontraktów Solidity jako danych wejściowych do weryfikacji. Pierwszy z nich był kontraktem w stylu Simple DAO, który służył jako studium przypadku re-entrancy. Drugim był zmniejszony kontrakt księgowy/przejściowy stanowy, zaprojektowany do testowania ograniczeń na poziomie kontraktu w porównaniu z podwójnym wydatkowaniem. Oryginalny kod źródłowy Solidity służył jako wejście do procesów abstrakcji i weryfikacji zdefiniowanych w tym protokole. Ogólny proces transformacji stosowany dla takich kontraktów jest zilustrowany na Rysunku 1, który pokazuje stopniową transformację kodu źródłowego Solidity w modele FSM, Event-B i SMV podczas weryfikacji.

Modelowanie granicy
Modelowanie formalne koncentruje się na logice przepływu sterowania inteligentnymi kontraktami, w tym na zachowaniu wejścia i wyjścia funkcji, wykonaniu wewnętrznego oraz przejściach stanów na poziomie kontraktów. Widoczność funkcji (publiczna, zewnętrzna, wewnętrzna i prywatna) była reprezentowana razem z odpowiadającym im zachowaniem stosu wywołań istotnym dla analizy re-entry. Typy abstrakcyjnych przejść (wywołanie, wysłanie, transfer) traktowano jako operacje przenoszenia eterów.

Zdefiniowano inwarianty na poziomie kontraktu, aby zapewnić unikalność transakcji i zapobiec podwójnemu wydawaniu w obrębie granicy abstrakcji. Aby odzwierciedlić wymagania dotyczące wyboru walidacji i integralności bloku, warstwa abstrakcji protokoł-logika została zdefiniowana na podstawie przejść stanów na poziomie protokołu zarówno Proof of Work, jak i Proof of Stake.

Granica abstrakcji nie obejmowała elementów warstwy sieciowej, w tym harmonogramowania dostarczenia wiadomości oraz opóźnień spowodowanych wieloma skokami, rozwiązywaniem forków, przeciwnikami sieciowymi stosującymi strategie bizantyjskie, semantyką Ethereum Virtual Machine oraz semantyką gazową kontrolowaną przez węzły sieciowe, propagacją wyjątków, asynchronicznymi wykonaniami, złożonym zachowaniem awaryjnym oraz ostatecznością na poziomie sieci. W związku z tym wyniki ustalania podwójnych wydatków dotyczą tylko inwariantów na poziomie kontraktu i nie stanowią umowy na poziomie sieci co do ostateczności.

Narzędzia i konfiguracja
Platforma Rodin była używana do modelowania, udoskonalania, generowania zobowiązań dowodowych oraz uruchamiania modelu Event-B (wersja 3.7.0), który umożliwiał dowodom PP, ML, SMT i Atelier-B automatyczne i interaktywne uruchamianie prób. nuXmv wersja 2.0.0 była uruchamiana na wygenerowanych modelach SMV w trybie pełnej eksploracji CTL w celu przeprowadzenia kontroli modeli CTL.

Wszystkie wykonania weryfikacji były wykonywane w kontrolowanym środowisku obliczeniowym, wykorzystując Ubuntu 22.04 LTS, OpenJDK 11 oraz Python 3.10.12. Web3 (7.6.0), NetworkX (3.4.2), Matplotlib (3.8.0), Graphviz (0.20.3), NumPy (1.26.4) oraz Pandas (2.2.2) zostały użyte do implementacji elementów symulacji i wizualizacji. Ten projekt gwarantował, że formalne wyniki weryfikacji i symulacji mogły być odtwarzane przy tych samych warunkach wykonywania.

Przepływ transformacji
Proces weryfikacji składał się z czterech faz. Kontrakty na wytrzymałość zostały po raz pierwszy przetłumaczone na reprezentację automatu stanów skończonych (FSM-SC). Model FSM-SC został następnie zakodowany w Event-B, z wyraźnie określonymi inwariantami i stopniami udoskonalenia. Abstrakcja FSM-SC została przetłumaczona na model SMV w nuXmv. Wyniki weryfikacji przedstawiono jako statystyki dotyczące umorzenia zobowiązań dowodowych i kontroli modeli CTL, a kontrprzykłady przedstawiono jako przypadki.

Budowa FSM
Każdy kontrakt był abstrahowany jako skończona maszyna stanów zdefiniowana jako:

Gdzie:
S = zbiór stanów
S₀ = stan początkowy
T = relacja przejściowa
V = mapowanie widoczności
G = predykaty strażnicze
A = akcje/aktualizacje stanu.

Algorytm 1: Konstrukcja FSM na podstawie Solidity
Wejście wejściowe: Kod źródłowy Solidity
Wyjście: FSM-SC

1) Analizować drzewo składni abstrakcyjnych kontraktów Solidity.
2) Utworzenie stanu początkowego S₀ na podstawie definicji konstruktora.
3) Dla każdej funkcji solidności f utworzyć odrębny stan sterowania S_f i zapisać widoczność V(f) ∈ {publiczne, zewnętrzne, wewnętrzne, prywatne}.
4) Dla każdego zdania w funkcji f wyprowadzamy przejście t poprzez wyodrębnianie predykatów strażniczych z warunków żądania/asercji oraz działań z aktualizacji zmiennych stanu.
5) Dodaj przejście t do T.
6) Tworzenie jawnych typów przejść dla operacji transferu Ether (wywołanie, wysłanie, transfer), wywołań wewnętrznych i zewnętrznych, wywołań delegatecall, samozniszczenie, użycie tx.origin, gałęzie warunkowe oraz konstrukcje pętli.
7) Zwróć FSM-SC = (S, S₀, T, V, G, A).

Każda funkcja Solidity jest powiązana z innym stanem sterowania FSM. Dla zrozumienia podatności, przepływy wykonawcze istotne dla podatności, np. takie przepływy z zewnętrznymi wywołaniami i aktualizacjami balansu, były wyraźnie abstrahowane do uporządkowanych przejść w uporządkowaną. Rysunek 2 opisuje przykładowy diagram FSM-SC dla kontraktu w stylu SimpleDAO, pokazujący, jak stany wejścia, przejścia wywołań zewnętrznych oraz sekwencje aktualizacji stanu były abstrahowane podczas tego etapu konstrukcji.

Kodowanie FSM do Zdarzenia-B
Przejście na FSM było przedstawione jako konstrukty Event-B. Wszystkie przejścia odpowiadają zdarzeniom Event-B, w tym konkretnym strażnikom i akcjom.

Algorytm 2: kodowanie FSM do Event-B
Wejście wejściowe: FSM-SC
Wyjście: Maszyna Event-B i kontekst

1) Zdefiniuj STATE_SET i FUNCTION w kontekście kontraktowym.
2) Deklaruj zmienne reprezentujące stan sterowania FSM i stan na poziomie kontraktu.
3) Reprezentować każdy stan sterowania FSM s ∈ S za pomocą current_state ∈ STATE_SET.
4) Dla każdego przejścia (s → s′, g, a) stwórz zdarzenie Zdarzenie-B E_t z:
5) GDZIE current_state = s ∧ g
6) WTEDY current_state := s′ ∥ zastosować(a)
7) Kodowanie ograniczeń widoczności za pomocą zabezpieczeń pochodzących z V(f).
8) Zdefiniuj inwarianty inv1–inv9, aby uchwycić właściwości bezpieczeństwa i spójności.
9) Definiuj INICJALIZACJĘ poprzez przypisanie wartości S₀ i domyślnych.

Zestaw stanów, aktualny stan, widoczność funkcji, stos wywołań, znacznik czasu transakcji, status transferu Ether, flaga wywołania delegata, flaga samozniszczenia oraz warunek weryfikacji to niektóre ze zmiennych uwzględnionych w modelu Event-B. Inwarianty (inv1-inv9) oraz działania inicjalizacji (act1-act6) odpowiadają tym w formalnej specyfikacji. Rysunek 3 przedstawia również graficzną prezentację, jak kluczowe zdarzenia istotne dla podatności, zwłaszcza przejścia związane z ponownym wejściem, są utrzymywane w kodowaniu Event-B. Ten rysunek wyjaśnia, jak wzorce strukturalne modelu FSM-SC pokazane na Rysunku 2 są odwzorowane na weryfikowalne zdarzenia Event-B.

Strategia udoskonalania
Wprowadzono dwa poziomy udoskonalenia. Na poziomie abstrakcyjnym reprezentowano przepływ kontroli kontraktów na wysokim poziomie oraz inwarianty rdzeniowe. Udoskonalony poziom dodał ograniczenia specyficzne dla kontraktów, w tym ograniczenia stosu wywołań, ograniczenia widoczności oraz warunki zapobiegania ponownemu wejściu.

Algorytm 3: Udoskonalenie i zwolnienie z obowiązkiem dowodu
Input: Maszyna abstrakcyjna i maszyna udoskonalona
Wyjście: Umorzone zobowiązania dowodowe i statystyki

1) Generowanie obowiązków dowodowych dla maszyny abstrakcyjnej w Rodinie.
2) Wykonanie włączonych automatycznych dowodów i zapisywanie wyników wypisu.
3) Generowanie zobowiązań do dostosowania dla maszyny rafinowanej.
4) Stosowanie automatycznych dowodów do obowiązków związanych z udoskonalaniem.
5) Wypełnianie pozostałych zobowiązań interaktywnie, gdy jest to konieczne.
6) Statystyki dowodów eksportu i raporty statusowe.

Raportowanie dowodów obejmowało liczbę inwariantów, poziomy udoskonalenia, generowane zobowiązania dowodowe, automatyczną szybkość wyładowania, interaktywną szybkość wyładowania oraz końcową szybkość wyładowania.

Specyfikacja właściwości CTL i sprawdzanie modeli
Abstrakcja FSM-SC została przetłumaczona na model SMV do weryfikacji czasowej w czasie rozgałęzień w nuXmv.

Algorytm 4: Sprawdzanie FSM do SMV i CTL
Wyniki: Wynik weryfikacji PASS/FAIL oraz ślady kontrprzykładów (jeśli występują)

1. Zapisz stany sterujące FSM jako wyliczony stan zmiennej SMV.
2. Przekształcić przejścia FSM na chronione przydziały następnego stanu (następnego stanu).
3. Utrzymywanie flag dla warunków związanych z podatnościami, takich jak połączenia zewnętrzne i aktualizacje salda.
4. Zakoduj właściwości CTL w nuXmv i wykonaj model checking.
5. Jeśli jakaś własność nie działa, wygeneruj kontrprzykładowe ślady reprezentujące sekwencje przejść FSM.

Sprawdzanie CTL obejmowało wymagania kolejności ponownego wejścia, finalizację aktualizacji stanu po operacjach transferowych, ograniczanie nieograniczonego rekurencyjnego wprowadzania do krytycznych sekcji oraz unikanie martwego punktu.

Weryfikacja właściwości bezpieczeństwa
Prosty kontrakt w stylu DAO, który zapobiega ponownemu wejściu, został potwierdzony poprzez zapewnienie bezpiecznego porządkowania między zewnętrznymi wywołaniami a aktualizacjami stanu za pomocą inwariantów i ograniczeń CTL. Tam, gdzie było to dozwolone, strażnicy ci sprawdzali ograniczenia dostępu i kontroli dostępu, zapewniając, że nieautoryzowane przejścia są ograniczone przez inwarianty. Model zredukowanego rejestru weryfikował niezmienniki unikalności transakcji i spójności księgi na poziomie zapobiegania w kontrakcie.

Raportowane wyniki
Sekcja Wyniki zawiera raporty dotyczące metryk strukturalnych FSM, metryk modelu Event-B oraz statystyk do dowodu zobowiązania i weryfikacji CTL. Wyniki dowodu formalnego oraz testów modelowych CTL są podawane osobno, aby rozróżnić dowody gwarancji poprawności za pomocą inwariantów oraz dowody weryfikacji czasowej za pomocą weryfikacji czasowej.

Wyniki

Wyniki tej pracy łączą formalne produkty weryfikacyjne Event-B i CTL z informacjami wykonywalnymi z symulacji blockchain. Połączenie tych wielowarstwowych wyników wspiera walidację kluczowych zachowań w inteligentnych kontraktach, ich systemów konsensusu oraz ograniczeń wiarygodności księgi w ograniczonym zakresie wzorowania projektu.

Konfiguracja środowiska i weryfikacja zależności
Środowisko wykonawcze używane do transformacji, weryfikacji i symulacji modeli zostało uru...

Dyskusja

Formalna i symulacyjna weryfikacja wykazuje, że wielowarstwowy system weryfikacji używany w danych badaniach był w stanie zweryfikować zachowanie smart kontraktów, poprawność mechanizmu konsensusu oraz właściwość integralności księgi rachunkowej w dobrze określonym zakresie abstrakcji. Zdarzenie-B zapewnia matematycznie ugruntowaną reprezentację właściwości bezpieczeństwa, przepływu stanu oraz logiki zapobiegania ponownemu wejściu w kategoriach inwariantów i logiki opartej na doprecyzowaniu ^5...

Materiały

Lista materiałów użytych w tym artykule

Nazwa	Firma	Numer katalogowy	Komentarze
Platforma Rodin (wersja 3.7.0)	Zespół Rodin / Fundacja Zaćmienia	https://www.event-b.org/install.html	Modelowanie, udoskonalanie oraz generowanie i rozładowywanie zobowiązań do dowodów
Metoda Event-B	Uniwersytet w Southampton / Społeczność Rodin	https://www.event-b.org/	Formalne ramy modelowania dla specyfikacji i udoskonalania niezmienników
nuXmv Model Checker (v2.0.0)	FBK (Fundacja Bruno Kessler)	https://nuxmv.fbk.eu/	Symboliczne sprawdzanie modeli właściwości CTL
Graphviz (v0.20.3)	Zespół Graphviz	https://graphviz.org/	Wizualizacja FSM i renderowanie wykresów
Python (v3.10.12)	Python Software Foundation	https://www.python.org/downloads	Środowisko symulacji i wykonania
Web3.py (v7.6.0)	Ethereum Foundation / Współtwórcy	https://web3py.readthedocs.io/	Interakcja blockchain i symulacja transakcji
NetworkX (wersja 3.4.2)	Deweloperzy NetworkX	https://networkx.org/	Modelowanie grafowe struktur blockchain i FSM
Matplotlib (v3.8.0)	Zespół Rozwojowy Matplotlib	https://matplotlib.org/	Wykres czasu wydobycia i rozkładów walidatorów
NumPy (v1.26.4)	Deweloperzy NumPy	https://numpy.org/	Obliczenia numeryczne
Pandas (wersja 2.2.2)	Zespół Rozwojowy Pandas	https://pandas.pydata.org/	Analiza i przetwarzanie danych
OpenJDK 11	Społeczność Oracle / OpenJDK	https://openjdk.org/projects/jdk/11/	Wymagany czas działania na platformie Rodin
Ubuntu 22.04 LTS	Canonical Ltd.	https://ubuntu.com/download	System operacyjny dla wszystkich eksperymentów
Solidność	Fundacja Ethereum	https://soliditylang.org/	Język źródłowy smart kontraktów używany jako wejście
nuXmv Input Language (SMV)	FBK	https://nuxmv.fbk.eu/documentation.html	Reprezentacja modelu pośredniego dla weryfikacji CTL