Abstract
The extent of formal verification methods applied to industrial projects has always been limited. The proliferation of distributed ledger systems (DLS), also known as blockchain, is rapidly changing the situation. Since the main area of DLSs' application is the automation of financial transactions, the properties of predictability and reliability are critical for implementing such systems. The actual behavior of the DLS is determined by the chosen consensus protocol, which properties require strict specification and formal verification. Formal specification and verification of the consensus protocol is necessary but not sufficient. It is required to ensure that the software implementation of the DLS nodes complies with this protocol. The verified software implementation of the protocol must run on a fairly reliable operating system. The so-called “smart contracts”, which are an important part of the applied implementations of specific business processes based on DLSs, must be verifiable as well. In this paper, we describe an ongoing industrial project that will result in a DLS verified at least at the four technological levels described above. We then share our experience with the formal specification and verification of HotStuff, a leader-based fault-tolerant protocol that ensures reaching distributed consensus in the presence of Byzantine processes.
Highlights
Устойчивость к византийским условиямПод протоколом консенсуса будем понимать распределенный алгоритм синхронизации состояния систем распределенного реестра (СРР) между узлами
We describe an ongoing industrial project that will result in a distributed ledger systems (DLS) veri ed at least at the four technological levels described above
По аналогии с C-коллектором, задачей E-коллектора является сбор сообщений от узлов с результатом исполнения транзакции, объединение подписей и отправка одного сообщения пользователю
Summary
Под протоколом консенсуса будем понимать распределенный алгоритм синхронизации состояния СРР между узлами. В рамках раунда протокола консенсуса узлам необходимо договориться о едином списке транзакций для выполнения. Что для любого момента времени найдется такой момент времени ′ ≥ , что все правильные узлы будут иметь одно и тоже состояние, которое будет являться результатом исполнения списка транзакций, согласованных в рамках протокола консенсуса. Что для любого момента времени найдется такой момент времени ′ ≥ , что состояние сети изменится при наличии корректных транзакций от пользователя. После получения 2 + 1 корректных сообщений от разных узлов – при условии исполнения транзакций с меньшим порядковым номером – команда, заключенная в транзакции. Удовлетворяющих этому условию, пусто, то в качестве хэш-значения используется специальное значение , сообщающее, что лидер сменился, но нет команд для исполнения. В случае смены лидера, необходимо повторить фазы для порядка транзакций (так как число злонамеренных узлов линейно зависит от общего числа узлов), что приводит к сложности порядка ( 3)
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
