Построение высокопроизводительных разрешённых блокчейн-фабрик: проблемы и возможности

С момента появления Биткойна — первого широко распространенного приложения, основанного на блокчейнах, — интерес к проектированию приложений на основе блокчейнов чрезвычайно возрос. В основе этих приложений лежат протоколы консенсуса, которые безопасно реплицируют клиентские запросы среди всех реплик, даже если некоторые реплики являются византийски отказавшими. К сожалению, эти протоколы консенсуса обычно имеют низкую пропускную способность, и этот недостаток производительности часто называют причиной медленного более широкого внедрения технологии блокчейн. Следовательно, многие работы сосредоточены на проектировании более эффективных протоколов консенсуса для увеличения пропускной способности консенсуса. Мы считаем, что эта сосредоточенность только на протоколах консенсуса объясняет лишь часть истории. Чтобы исследовать это убеждение, мы задаем простой вопрос: Может ли хорошо продуманная система, использующая классический протокол консенсуса, превзойти системы, использующие современные протоколы? В этом руководстве мы отвечаем на этот вопрос, глубоко погружаясь в дизайн блокчейн-систем. Далее, мы подробно рассматриваем теорию, стоящую за консенсусом, что может помочь пользователям выбрать протокол, который наилучшим образом соответствует их требованиям. Наконец, мы делимся нашим видением высокопроизводительных блокчейн-систем, работающих в больших масштабах.

ВВЕДЕНИЕ

С момента появления Биткойна — первого широко распространенного приложения, основанного на блокчейне, — интерес к проектированию приложений на основе блокчейнов чрезвычайно возрос. Этот интерес привел к появлению нескольких решений и систем баз данных, вдохновленных блокчейном [2], [3], [17], [27], [39], [40]. Кроме того, системы на основе блокчейна использовались для решения задач в различных других областях, таких как производство продуктов питания, управление правами собственности на землю, торговля энергией и управление идентификационными данными.

Данная работа распространяется по лицензии Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International. Чтобы ознакомиться с копией этой лицензии, посетите [http://creativecommons.org/licenses/by-nc-nd/4.0/.](http://creativecommons.org/licenses/by-nc-nd/4.0/)

Для любого использования, выходящего за рамки, покрываемые этой лицензией, получите разрешение по электронной почте [info@vldb.org.](mailto:info@vldb.org) Авторские права принадлежат владельцу/автору (авторам). Права на публикацию предоставлены по лицензии VLDB Endowment. Труды VLDB Endowment, Том. 13, №. 12 ISSN 2150-8097.

DOI: https://doi.org/10.14778/3415478.3415565

В основе этих блокчейн-приложений лежат протоколы консенсуса, устойчивые к византийским отказам (BFT), которые гарантируют, что все реплики этого блокчейн-приложения достигают консенсуса относительно порядка входящих клиентских запросов, даже если некоторые из реплик являются византийскими [8], [24], [27], [34], [45].

Спустя десятилетие после внедрения блокчейнов в криптовалюты и после нескольких известных исследовательских проектов мы видим, что криптовалюты по-прежнему остаются основными известными случаями использования блокчейнов. Это поднимает ключевой вопрос: Почему блокчейн-приложения получили такое медленное более широкое распространение? Низкая пропускная способность и высокая задержка BFT-консенсуса называются ключевыми причинами этого. Предыдущие работы показали, что традиционные распределенные базы данных могут достигать пропускной способности порядка 100 тыс. транзакций в секунду [29], [30], в то время как первоначальные разрешенные блокчейн-приложения, такие как Bitcoin [38] и Ethereum [44], имеют пропускную способность всего в несколько транзакций в секунду. В этих криптовалютных приложениях низкая пропускная способность считается приемлемой, поскольку эти затратные техники позволяют создать полностью децентрализованную валюту, которая не контролируется одним правительством или корпорацией. Действительно, блокчейны криптовалют обычно имеют открытое членство, так как кто-угодно может присоединиться к этим блокчейнам.

Хотя разрешенные блокчейны подчеркивают понятия децентрализации и устойчивости, их открытое членство часто не является необходимым для отказоустойчивой обработки транзакций. Это привело к созданию промышленных разрешенных блокчейнов, где участвовать может только определенная группа пользователей, некоторые из которых могут быть ненадежными [3]. Эти разрешенные конструкции используют традиционный BFT-консенсус для обеспечения пропускной способности до 10 тыс. транзакций в секунду [2], [3], что все еще ниже ожидаемой производительности современных систем. Несколько предыдущих работ [9], [11], [34], [45] винят низкую пропускную способность и масштабируемость разрешенных блокчейнов в лежащем в их основе BFT-консенсусе. Хотя эти утверждения не являются ложными, они объясняют лишь часть истории. С нашей точки зрения, разрешенные блокчейн-приложения могут достичь более широкого распространения за счет улучшений в трех важных направлениях.

Во-первых, хорошо известно, что эффективный протокол не всегда приводит к реализации с высокой пропускной способностью. Тот же принцип применим и к протоколам консенсуса, используемым в существующих разрешенных блокчейн-приложения. Хотя эти приложения предоставляют платформы для использования блокчейнов в различных случаях использования, эти приложения не дотягивают в своих архитектурных деталях [2], [3], [6], [21]. Мы утверждаем, что низкая пропускная способность этих приложения связана с упущенными возможностями во время их проектирования и реализации. Действительно, хорошо продуманный блокчейн-приложения может иметь увеличение пропускной способности на порядок, например, за счет использования возможностей параллелизации и конвейеризации.

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

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

Базой данных между различными заинтересованными сторонами. Федеративное управление данными само по себе является важным шагом на пути к решению проблем качества данных, возникающих из-за нефедеративного обмена информацией между различными заинтересованными сторонами, и, как такое, может снизить огромное негативное экономическое воздействие плохих данных [16], [33], [42]. В федеративном управлении данными устойчивость менее приоритетна, и фокус таких блокчейн-систем сосредоточен на быстром обновлении и извлечении данных, эффективной обработке запросов и модульном анализе данных.

ПЛАН РУКОВОДСТВА

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

Это руководство начинается с общего введения в блокчейны с точки зрения управления данными. После введения руководство будет сосредоточено на трех направлениях. Во-первых, мы рассмотрим теоретическую основу, в которой работают разрешенные блокчейны. Затем мы рассмотрим практические высокопроизводительные протоколы консенсуса и текущие разработки. Эта теоретическая основа предоставляет пользователям разрешенной блокчейн-системы правильные инструменты для выбора протоколов консенсуса, которые наилучшим образом соответствуют их требованиям. Во-вторых, мы рассмотрим архитектурные проблемы при проектировании высокопроизводительных разрешенных блокчейн-систем, где мы покажем, как существующие принципы параллелизации потоков и конвейеризации задач могут быть применены к блокчейн-приложения. Кроме того, мы проиллюстрируем способы оптимизации доступа к данным и обработки запросов в разрешенных блокчейн-приложениях. Наконец, мы рассмотрим проблемы проектирования для высокопроизводительных разрешенных блокчейн-систем будущего, которые могут работать с огромными объемами данных. Мы завершаем, представив наше видение будущих разработок. Далее мы подробно объясним эти три направления.

Протоколы BFT-консенсуса. Блокчейны, по своей сути, являются полностью реплицированными распределенными системами, которые aim to поддерживать целостность данных. Известная теорема CAP накладывает ограничения на типы отказов, с которыми эти блокчейны могут справляться, гарантируя непрерывное обслуживание [7], [20]. Однако теорема CAP накладывает довольно общие ограничения на проектирование блокчейнов. Также известны и более конкретные ограничения, поскольку проблема византийского консенсуса и другие связанные проблемы, такие как проблема византийского соглашения и проблема интерактивной согласованности, получили considerable внимание.

Известно, что проблема византийского соглашения может быть решена только при использовании синхронной связи [19], [37], [43]. В синхронной среде с n репликами, из которых f являются византийскими (например, злонамеренными), для византийского соглашения требуется, чтобы n > 3f [12], [13]. Когда доступны сильные криптографические примитивы, это можно улучшить до n > f [15], [35], [41] (хотя практические системы все равно будут требовать n > 2f ). Дополнительно известны ограничения на объем связи и качество сети [10], [12], [13], [14], [15], [18].

Предоставив теоретическую основу, мы делаем шаг к детализации практических протоколов консенсуса. Мы делаем это, полностью освещая протокол консенсуса Practical Byzantine Fault Tolerance Pbft Кастро и др. [8]. Далее мы также рассмотрим lineage протоколов консенсуса, которые улучшают и дорабатывают Pbft. Этот подробный обзор охватит многие из практических протоколов консенсуса, используемых в настоящее время, и одновременно охватит последние разработки. Наш обзор будет включать такие протоколы, как Pbft, HotStuff [45], Zyzzyva [4], [34], FaB [36], SynBFT [1], RBFT [5], PoE [23] и Multi-BFT [24], [25]. Все эти протоколы идут на некоторые компромиссы и, следовательно, достигают оптимальной пропускной способности только при определенных условиях. В нашем руководстве мы подробно обсудим эти компромиссы и условия, так как это позволяет выбрать протокол, который наилучшим образом соответствует требованиям их конкретного блокчейн-приложения.

Архитектурная парадигма. Хотя эффективный протокол консенсуса может помочь увеличить пропускную способность связанного разрешенного блокчейн-приложения, дизайн системы и ее реализация имеют не менее важное значение. В нашем руководстве мы покажем, что классические BFT-протоколы, которые считаются медленными, такие как Pbft [8], всегда могут превзойти оптимизированные для узких случаев BFT-протоколы, такие как Zyzzyva [34], если они реализованы в хорошо спроектированном и умело оптимизированном блокчейн-приложения. Мы используем Рисунок 1, чтобы проиллюстрировать такую возможность. На этом рисунке мы измеряем пропускную способность ResilientDB, нашей разрешенной блокчейн-системы [27], [28], и намеренно заставляем ее использовать "медленный" протокол Pbft. Затем мы сравниваем пропускную способность ResilientDB с разрешенной блокчейн-системой, которая применяет практики, предложенные в BFTSmart [6], и использует быстрый протокол Zyzzyva. Мы наблюдаем, что системно-ориентированный дизайн ResilientDB может использовать затратный трехфазный протокол Pbft (из которых две фазы требуют квадратичной связи между репликами), при этом все равно превосходя системы, использующие Zyzzyva (однофазный протокол с линейной связью между репликами). Десятилетия академических исследований [29], [30] помогли сообществу в проектировании эффективных распределенных баз данных и приложений. В этом руководстве мы изучаем существующие практики для проектирования оптимального разрешенного блокчейн-приложения. Эти практики включают использование спекуляции [34], [36], парадигм "выполнить-упорядочить" или "упорядочить-выполнить" [3], модульности компонентов [6], пакетной обработки или потоковой передачи транзакций [2], [11] и обработки сообщений вне порядка [28]. Кроме того, мы обсудим, как хранение данных, обслуживание данных, извлечение данных и поддержка NoSQL и реляционных баз данных обеспечиваются нашими современными разрешенными блокчейн-приложения [28]. Мы продемонстрируем эту функциональность через пользовательский интерфейс, который может облегчить обработку запросов и анализ данных.

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

Мы завершим наше руководство обсуждением недавних шагов к проектированию новых отказоустойчивых архитектур, которые отходят от полностью реплицированной природы блокчейнов, чтобы увеличить масштабируемость и способность обслуживать приложения, работающие с большими данными. Чтобы воплотить наше видение на практике, мы сначала рассмотрим две низкоуровневые техники: cluster-sending [31] и delayed-replication [32]. Далее мы рассмотрим высокоуровневые конструкции, обеспечиваемые этими техниками, для предоставления высокопроизводительного параллелизованного консенсуса [24], [25] и для предоставления высокопроизводительного консенсуса в шардированных и учитывающих географическое расположение архитектурах [27].

БИОГРАФИЧЕСКИЕ ОЧЕРКИ

Suyash Gupta — кандидат наук на факультете информатики Калифорнийского университета в Дэвисе. В UC Davis он является старшим членом Исследовательской лаборатории систем и работает под руководством проф. Садоги. Он также работает ведущим архитектором в блокчейн-компании Moka Blox и ResilientDB. Он также имеет степень магистра наук Университета Пердью и степень магистра наук (исследования) Индийского технологического института в Мадрасе. Его текущие исследования сосредоточены на достижении безопасного и эффективного отказоустойчивого консенсуса в распределенных и блокчейн-системах. Он также опубликовал работы, представляющие эффективные оптимизации компилятора и проекты для параллельных и распределенных алгоритмов.

Jelle Hellings закончил свое обучение в аспирантуре Технологического университета Эйндховена, Нидерланды, в 2011 году, с финальным исследовательским проектом, сосредоточенным на алгоритмах внешней памяти для индексации деревьев и ориентированных ациклических графов. Затем он перешел в Университет Хасселта, Бельгия, где занимался докторскими исследованиями в исследовательской группе "Базы данных и теоретическая информатика". Он закончил свои докторские исследования по выразительной силе языков запросов в 2018 году. С лета 2018 года Джелле является постдоком в UC Davis в Исследовательской лаборатории систем под руководством проф. Садоги. Его текущие исследования сосредоточены на теоретических пределах протоколов консенсуса в злонамеренных средах и, в более общем плане, на исследовании новых направлений для реплицированных систем в злонамеренных средах.

Sajjad Rahnama — аспирант факультета информатики Калифорнийского университета в Дэвисе, курируемый проф. Садоги. Он также является членом Исследовательской лаборатории систем. Он также работает системным дизайнером в блокчейн-компании Moka Blox и является главным разработчиком ResilientDB. Его текущие исследования сосредоточены на безопасной обработке транзакций и проектировании глобальных масштабируемых отказоустойчивых протоколов, распределенных систем и их приложений в блокчейне. Он имеет степень бакалавра компьютерных наук Технологического университета Амиркабира, Тегеран, Иран. До начала обучения в аспирантуре он работал в нескольких технологических компаниях в качестве инженера инфраструктуры и разработчика.

Mohammad Sadoghi — доцент факультета информатики в UC Davis. Он возглавляет исследовательскую группу ExpoLab с целью создания распределенного реестра, объединяющего безопасную транзакционную и аналитическую обработку в реальном времени (L-Store), все сосредоточенное вокруг демократической и децентрализованной вычислительной модель (ResilientDB). Он стал соучредителем блокчейн-компании Moka Blox LLC, ответвления ResilientDB. Он имеет более 80 публикаций в ведущих конференциях/журналах по базам данных и 34 поданные американские патенты. Он является соавтором книги под названием "Обработка транзакций на современном оборудовании", Morgan & Claypool Synthesis Lectures on Data Management, и в настоящее время является соавтором книги под названием "Отказоустойчивые распределенные транзакции в блокчейне", серия Morgan & Claypool.

БЛАГОДАРНОСТИ

Это руководство основано на плане нашей предстоящей книги по отказоустойчивой обработке транзакций в блокчейнах [26].

Кроме того, это руководство является развитием руководства, представленного на Middleware 2019 [22]. Мы обновили это руководство новыми и предстоящими техниками и идеями.

Эта работа частично поддержана Управлением научных исследований, Управлением программ инновационных исследований для малого бизнеса Министерства энергетики США в соответствии с номером награды DE-SC0020455.

1. 1. I. Abraham, S. Devadas, D. Dolev, K. Nayak, and L. Ren. Synchronous byzantine agreement with expected O(1) rounds, expected O(n2) communication, and optimal resilience, 2018.
2. 2. M. J. Amiri, D. Agrawal, and A. E. Abbadi. CAPER: A cross-application permissioned blockchain. PVLDB, 12(11):1385–1398, 2019.
3. 3. E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis, A. De Caro, D. Enyeart, C. Ferris, G. Laventman, Y. Manevich, S. Muralidharan, C. Murthy, B. Nguyen, M. Sethi, G. Singh, K. Smith, A. Sorniotti, C. Stathakopoulou, M. Vukoli´c, S. W. Cocco, and J. Yellick. Hyperledger Fabric: A distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, pages 30:1–30:15. ACM, 2018.
4. 4. P.-L. Aublin, R. Guerraoui, N. Kneˇzevi´c, V. Qu´ema, and M. Vukoli´c. The next 700 bft protocols. ACM Trans. Comput. Syst., 32(4):12:1–12:45, 2015.
5. 5. P.-L. Aublin, S. B. Mokhtar, and V. Qu´ema. RBFT: Redundant byzantine fault tolerance. In IEEE 33rd International Conference on Distributed Computing Systems, pages 297–306. IEEE, 2013.
6. 6. A. Bessani, J. Sousa, and E. E. Alchieri. State machine replication for the masses with BFT-SMART. In 44th Annual IEEE/IFIP International Conference on Dependable Systems and Networks, pages 355–362. IEEE, 2014.
7. 7. E. Brewer. CAP twelve years later: How the “rules” have changed. Computer, 45(2):23–29, 2012.
8. 8. M. Castro and B. Liskov. Practical byzantine fault tolerance and proactive recovery. ACM Trans. Comput. Syst., 20(4):398–461, 2002.
9. 9. H. Dang, T. T. A. Dinh, D. Loghin, E.-C. Chang, Q. Lin, and B. C. Ooi. Towards scaling blockchain systems via sharding. In Proceedings of the 2019 International Conference on Management of Data, pages 123–140. ACM, 2019.
10. 10. R. A. DeMillo, N. A. Lynch, and M. J. Merritt. Cryptographic protocols. In Proceedings of the Fourteenth Annual ACM Symposium on Theory of Computing, pages 383–400. ACM, 1982.
11. 11. T. T. A. Dinh, J. Wang, G. Chen, R. Liu, B. C. Ooi, and K.-L. Tan. BLOCKBENCH: A framework for analyzing private blockchains. In Proceedings of the 2017 ACM International Conference on Management of Data, pages 1085–1100. ACM, 2017.
12. 12. D. Dolev. Unanimity in an unknown and unreliable environment. In 22nd Annual Symposium on Foundations of Computer Science, pages 159–168. IEEE, 1981.
13. 13. D. Dolev. The byzantine generals strike again. J. Algorithms, 3(1):14–30, 1982.
14. 14. D. Dolev and R. Reischuk. Bounds on information exchange for byzantine agreement. J. ACM, 32(1):191–204, 1985.
15. 15. D. Dolev and H. Strong. Authenticated algorithms for byzantine agreement. SIAM J. Comput., 12(4):656–666, 1983.
16. 16. W. W. Eckerson. Data quality and the bottom line: Achieving business success through a commitment to high quality data. Technical report, The Data Warehousing Institute, 101communications LLC., 2002.
17. 17. M. El-Hindi, C. Binnig, A. Arasu, D. Kossmann, and R. Ramamurthy. BlockchainDB: A shared database on blockchains. PVLDB, 12(11):1597–1609, 2019.
18. 18. M. J. Fischer and N. A. Lynch. A lower bound for the time to assure interactive consistency. Inform. Process. Lett., 14(4):183–186, 1982.
19. 19. M. J. Fischer, N. A. Lynch, and M. S. Paterson. Impossibility of distributed consensus with one faulty process. J. ACM, 32(2):374–382, 1985.
20. 20. S. Gilbert and N. Lynch. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News, 33(2):51–59, 2002.
21. 21. G. Greenspan. Multichain private blockchain, 2015.
22. 22. S. Gupta, J. Hellings, S. Rahnama, and M. Sadoghi. An in-depth look of BFT consensus in blockchain: Challenges and opportunities. In Proceedings of the 20th International Middleware Conference Tutorials, pages 6–10. ACM, 2019.
23. 23. S. Gupta, J. Hellings, S. Rahnama, and M. Sadoghi. Proof-of-execution: Reaching consensus through fault-tolerant speculation, 2019.
24. 24. S. Gupta, J. Hellings, and M. Sadoghi. Brief announcement: Revisiting consensus protocols through wait-free parallelization. In 33rd International Symposium on Distributed Computing (DISC 2019), volume 146, pages 44:1–44:3. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, 2019.
25. 25. S. Gupta, J. Hellings, and M. Sadoghi. Scaling blockchain databases through parallel resilient consensus paradigm, 2019.
26. 26. S. Gupta, J. Hellings, and M. Sadoghi. Fault-Tolerant Distributed Transactions on Blockchains. Synthesis Lectures on Data Management. Morgan & Claypool Publishers, 2020. (to appear).
27. 27. S. Gupta, S. Rahnama, J. Hellings, and M. Sadoghi. ResilientDB: Global scale resilient blockchain fabric. PVLDB, 13(6):868–883, 2020.
28. 28. S. Gupta, S. Rahnama, and M. Sadoghi. Permissioned blockchain through the looking glass: Architectural and implementation lessons learned. In 40th International Conference on Distributed Computing Systems. IEEE, 2020.
29. 29. R. Harding, D. Van Aken, A. Pavlo, and M. Stonebraker. An evaluation of distributed concurrency control. PVLDB, 10(5):553–564, 2017.
30. 30. S. Harizopoulos, D. J. Abadi, S. Madden, and M. Stonebraker. OLTP through the looking glass, and what we found there. In Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data, pages 981–992. ACM, 2008.
31. 31. J. Hellings and M. Sadoghi. Brief announcement: The fault-tolerant cluster-sending problem. In 33rd International Symposium on Distributed Computing (DISC 2019), volume 146, pages 45:1–45:3. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, 2019.
32. 32. J. Hellings and M. Sadoghi. Coordination-free byzantine replication with minimal communication costs. In 23rd International Conference on Database Theory, volume 155, pages 17:1–17:20. Schloss Dagstuhl–Leibniz-Zentrum fuer Informatik, 2020.
33. 33. T. N. Herzog, F. J. Scheuren, and W. E. Winkler. Data Quality and Record Linkage Techniques. Springer New York, 2007.
34. 34. R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong. Zyzzyva: Speculative byzantine fault tolerance. In Proceedings of Twenty-first ACM SIGOPS Symposium on Operating Systems Principles, pages 45–58. ACM, 2007.
35. 35. L. Lamport, R. Shostak, and M. Pease. The byzantine generals problem. ACM Trans. Program. Lang. Syst., 4(3):382–401, 1982.
36. 36. J.-P. Martin and L. Alvisi. Fast byzantine consensus. IEEE Trans. Depend. Secure Comput., 3(3):202–215, 2006.
37. 37. S. Moran and Y. Wolfstahl. Extended impossibility results for asynchronous complete networks. Inform. Process. Lett., 6(3):145–151, 1987.
38. 38. S. Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2009.
39. 39. S. Nathan, C. Govindarajan, A. Saraf, M. Sethi, and P. Jayachandran. Blockchain meets database: Design and implementation of a blockchain relational database. PVLDB, 12(11):1539–1552, 2019.
40. 40. F. Nawab and M. Sadoghi. Blockplane: A global-scale byzantizing middleware. In 35th International Conference on Data Engineering (ICDE), pages 124–135. IEEE, 2019.
41. 41. M. Pease, R. Shostak, and L. Lamport. Reaching agreement in the presence of faults. J. ACM, 27(2):228–234, 1980.
42. 42. T. C. Redman. The impact of poor data quality on the typical enterprise. Commun. ACM, 41(2):79–82, 1998.
43. 43. G. Taubenfeld and S. Moran. Possibility and impossibility results in a shared memory environment. Acta Inform., 33(1):1–20, 1996.
44. 44. G. Wood. Ethereum: a secure decentralised generalised transaction ledger, 2016. EIP-150 revision.
45. 45. M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham. HotStuff: BFT consensus with linearity and responsiveness. In Proceedings of the ACM Symposium on Principles of Distributed Computing, pages 347–356. ACM, 2019.