Cosmos: сеть распределенных реестров

Введение

Совокупный успех экосистемы с открытым исходным кодом, децентрализованный обмен данными и публичные криптовалюты вдохновило на понимание того, что децентрализованные интернет-протоколы могут быть использованы для радикального улучшения социально-экономической инфраструктуры. Мы видели специализированные приложения blockchain, такие как Bitcoin PH_0000 ( криптовалюта), Zerocash [2] (криптовалюта для конфиденциальности) и обобщенные платформы smart contract, такие как Ethereum [3], с бесчисленное количество распределенных приложений для Etherium Virtual Машина (PH_0007), такая как Augur (рынок прогнозов) и TheDAO. [4] (инвестиционный клуб). Однако на сегодняшний день эти blockchain пострадали от ряда недостатков, включая их общую энергетическую неэффективность, плохое или ограниченная производительность и незрелые механизмы управления. Предложения по масштабированию пропускной способности транзакций Bitcoin, например: Segregated-Witness [5] и BitcoinNG [6] — вертикальное масштабирование. решения, которые остаются ограниченными емкостью одного физического машина, чтобы обеспечить свойство полной проверяемости. Lightning Network [7] может помочь масштабировать транзакцию Bitcoin.

объем, полностью исключив некоторые транзакции из реестра, и хорошо подходит для микроплатежей и обеспечения конфиденциальности платежные рельсы, но могут не подойти для более универсальных потребности в масштабировании. Идеальным решением является решение, позволяющее нескольким параллельным blockchain взаимодействовать, сохраняя при этом свои свойства безопасности. Это имеет оказалось трудным, если не невозможным, с proof-of-work. Объединено например, майнинг позволяет выполнить работу по защите родительского цепочку для повторного использования в дочерней цепочке, но транзакции все равно должны быть проверяется по порядку каждым узлом и слитным майнингом blockchain уязвим для атаки, если большая часть hashing мощности на родитель не занимается активным слитным майнингом дочернего процесса. Академический обзор альтернативных сетевых архитектур blockchain предусмотрены для дополнительный контекст, и мы предоставляем краткое изложение других предложений и их недостатки в смежных работах. Здесь мы представляем Cosmos, новую сетевую архитектуру blockchain. который решает все эти проблемы. Cosmos — это сеть из многих независимые blockchain, называемые зонами. Зоны питаются от Tendermint Core [8], обеспечивающий высокую производительность, согласованный, безопасный механизм консенсуса, подобный PBFT, в котором строгая ответственность за действия гарантирует сдерживание поведения злоумышленников. актеры. Алгоритм консенсуса BFT Tendermint Core хорошо подходит для масштабирования общедоступных proof-of-stake blockchains. Первая зона на Cosmos называется Cosmos Hub. Cosmos Hub — это мультиактивная криптовалюта proof-of-stake с простой механизм управления, который позволяет сети адаптироваться и обновление. Кроме того, концентратор Cosmos можно расширить за счет подключение других зон. Хаб и зоны сети Cosmos обмениваются данными с друг с другом через протокол связи между blockchain (IBC), своего рода виртуальный UDP или TCP для blockchains. Токены могут быть безопасно и быстро переносить из одной зоны в другуюбез необходимости обмена ликвидности между зонами. Вместо этого, все межзональные передачи token проходят через концентратор Cosmos, который отслеживает общее количество token, находящихся в каждой зоне. концентратор изолирует каждую зону от сбоя других зон. Потому что любой может подключить новую зону к хабу Cosmos, зоны позволяют для будущей совместимости с новыми blockchain инновациями. В этом разделе мы описываем консенсусный протокол Tendermint. и интерфейс, используемый для создания приложений с его помощью. Для более подробности смотрите в приложении. В классических византийских отказоустойчивых алгоритмах (BFT) каждый узел имеет одинаковый вес. В Tendermint узлы имеют неотрицательное значение. количество голосов и узлы, которые имеют положительное голосование мощности называются validators. Валидаторы участвуют в протокол консенсуса путем трансляции криптографических подписей или голосов, чтобы согласовать следующий блок. Право голоса валидаторов определяется на этапе генезиса или детерминировано изменено blockchain, в зависимости от приложение. Например, в приложении proof-of-stake, таком как концентратор Cosmos, право голоса может определяться сумма staking tokens, переданная в качестве залога. ПРИМЕЧАНИЕ. Такие дроби, как ⅔ и ⅓, относятся к долям общего числа голосов. мощность, а не общее количество validator, если только не все validator. иметь равный вес. >⅔ означает «более ⅔», ≥⅓ означает «по крайней мере ⅓». Tendermint — это частично синхронный консенсусный протокол BFT. получено на основе алгоритма консенсуса DLS [20]. Тендерминт - это

отличается своей простотой, производительностью и ответственностью за форк. Протокол требует yxed известного набора validators, где каждый validator идентифицируется по открытому ключу. Валидаторы пытаются прийти к консенсусу по одному блоку за раз, где блок представляет собой список сделок. Голосование за консенсус по блоку продолжается в раунды. В каждом раунде есть лидер раунда или предлагающий, который предлагает блок. Затем validator поэтапно голосуют за то, будет ли принять предложенный блок или перейти к следующему раунду. предлагающий раунд выбирается детерминированно из заказанных список validators, пропорционально их голосу. Полная информация о протоколе описана здесь. Безопасность Tendermint основана на использовании оптимального византийского отказоустойчивость посредством голосования сверхбольшинством (>⅔) и блокировки механизм. Вместе они гарантируют, что: ≥⅓ голосов должно быть византийским, чтобы вызвать нарушение безопасность, где зафиксировано более двух значений. если какой-либо группе validator когда-либо удастся нарушить безопасность или даже попытки сделать это, они могут быть идентифицированы протоколом. Это включает в себя как голосование за составные блоки, так и трансляцию необоснованные голоса. Несмотря на свои серьезные гарантии, Tendermint обеспечивает исключительные производительность. В тестах 64 узла, распределенных по 7 центры обработки данных на 5 континентах, на обычных облачных экземплярах, Консенсус Tendermint может обрабатывать тысячи транзакций за во-вторых, с задержкой фиксации порядка одной-двух секунд. Примечательно, что производительность более тысячи транзакций в второе сохраняется даже в суровых противоборствующих условиях, при validator происходит сбой или трансляция злонамеренно созданных голосов. См. Подробности приведены на рисунке ниже.

Основное преимущество алгоритма консенсуса Tendermint — простота. легкая безопасность клиентов, что делает его идеальным кандидатом для мобильных и Варианты использования Интернета вещей. Хотя легкий клиент Bitcoin должен синхронизироваться цепочки заголовков блоков и найти тот, у которого больше всего доказательств работы, легким клиентам Tendermint нужно только идти в ногу с изменениями в набор validator, а затем проверьте >⅔ PreCommits в последний блок для определения последнего состояния. Краткие легкие доказательства клиента также позволяют использовать inter-blockchain общение. В Tendermint предусмотрены защитные меры для предотвращения определенных заметные атаки, такие как двойные траты на большие расстояния по принципу «ничего не поставлено на карту» и цензура. Более подробно они обсуждаются в приложении.Алгоритм консенсуса Tendermint реализован в программа под названием Tendermint Core. Tendermint Core — это независимый от приложения «механизм консенсуса», который может превратить любую детерминированное приложение «черный ящик» в распределенно реплицируемую blockchain. Tendermint Core подключается к blockchain приложениям через интерфейс блокчейна приложения (ABCI) [17]. Таким образом, ABCI позволяет программировать blockchain приложений в любом язык, а не только язык программирования, на котором существует консенсус engine. Кроме того, ABCI позволяет легко замените уровень консенсуса любого существующего стека blockchain. Проведем аналогию с известной криптовалютой Bitcoin. Bitcoin — это криптовалюта blockchain, в которой каждый узел поддерживает полностью проверенная база данных вывода неизрасходованных транзакций (UTXO). Если хотелось создать систему, подобную Bitcoin, поверх ABCI, Tendermint Core будет отвечать за Совместное использование блоков и транзакций между узлами Установление канонического/неизменяемого порядка транзакций ( blockchain) Между тем, приложение ABCI будет отвечать за Ведение базы данных UTXO Проверка криптографических подписей транзакций Предотвращение траты транзакций на несуществующие средства Разрешение клиентам запрашивать базу данных UTXO Tendermint может разложить дизайн blockchain по предлагая очень простой API между процессом приложения и процесс консенсуса.

Cosmos Архитектура

Cosmos — это сеть независимых параллельных blockchain, которые каждый из них основан на классических алгоритмах консенсуса BFT, таких как Тендерминт 1. Первым blockchain в этой сети будет концентратор Cosmos. Cosmos Хаб подключается ко многим другим blockchain (или зонам) через новый протокол связи между blockchain. Концентратор Cosmos отслеживает многочисленные типы token и ведет учет общего количества количество tokens в каждой подключенной зоне. Токены могут быть безопасно и быстро переносить из одной зоны в другую без необходимости обмена жидкостью между зонами, поскольку все межзональные переводы монет проходят через концентратор Cosmos. Эта архитектура решает многие проблемы, с которыми сталкивается пространство blockchain. сегодняшние проблемы, такие как совместимость приложений, масштабируемость и возможность бесшовной модернизации. Например, зоны, производные от Bitcoind, Go-Ethereum, CryptoNote, ZCash или любая другая система blockchain может быть подключен к концентратору Cosmos. Эти зоны позволяют Cosmos бесконечно масштабироваться для удовлетворения глобального спроса на транзакции. Зоны также отличный вариант для распределенного обмена, который будет поддерживаться как ну. Cosmos — это не просто один распределенный реестр, а Cosmos Хаб — это не огороженный сад и не центр вселенной. Мы разработка протокола для открытой сети распределенных реестров которые могут послужить новой основой для будущих финансовых систем, основанный на принципах криптографии, разумной экономики, консенсуса теория, прозрачность и подотчетность. Хаб Cosmos является первым общедоступным blockchain в PH_0005. Сеть, основанная на алгоритме консенсуса BFT Tendermint. Проект с открытым исходным кодом Tendermint родился в 2014 году для решения скорость, масштабируемость и экологические проблемы алгоритма консенсуса доказательства работы Bitcoin. Используя и совершенствуя проверенные

BFT алгоритмы, разработанные в Массачусетском технологическом институте в 1988 году [20], Tendermint команда была первой, кто концептуально продемонстрировал proof-of-stake криптовалюта, которая решает проблему «ничего на кону» пострадали от криптовалют proof-of-stake первого поколения, таких как как NXT и BitShares1.0. Сегодня практически все мобильные кошельки Bitcoin используют доверенные серверы для предоставить им проверку транзакции. Это связано с тем, что доказательство работы требует ожидания множества подтверждений, прежде чем транзакция может считаться необратимо совершенной. Атаки двойной траты уже были продемонстрированы на таких сервисах, как CoinBase. В отличие от других консенсусных систем blockchain, Tendermint предлагает Мгновенная и доказуемо безопасная проверка платежей мобильного клиента. Поскольку Tendermint вообще никогда не разветвляется, мобильные кошельки могут получать мгновенное подтверждение транзакции, что делает надежные и практичные платежи – реальность на смартфонах. Это имеет значительные последствия для приложений Интернета вещей, поскольку ну. Валидаторы в Cosmos выполняют аналогичную роль майнерам Bitcoin, но вместо этого используйте криптографические подписи для голосования. Валидаторы безопасные, выделенные машины, которые отвечают за совершение блоки. Лица, не validator, могут делегировать свои staking token (называемые «атомы») любому validator, чтобы заработать часть комиссий за блок и атом награды, но они подвергаются риску быть наказанными (урезанными), если делегат validator взломан или нарушает протокол. Проверенный гарантии безопасности консенсуса Tendermint BFT и сопутствующие депозит заинтересованных сторон – validator и делегаторов – обеспечивают доказуемая, количественная безопасность для узлов и легких клиентов. Распределенные публичные реестры должны иметь конституцию и система управления. Bitcoin опирается на Фонд Bitcoin имайнинг для координации обновлений, но это медленный процесс. Ethereum разделился на ETH и ETC после хард-форка по адресу Взлом DAO, в основном потому, что не было предварительного общественного договора. ни механизма принятия таких решений. Валидаторы и делегаты в хабе Cosmos могут голосовать за предложения, позволяющие изменить заданные параметры системы автоматически (например, лимит газа блока), координировать обновления, как а также голосовать по поправкам в удобочитаемую конституцию которые регулируют политику Cosmos Hub. Конституция позволяет обеспечить сплоченность заинтересованных сторон по таким вопросам, как кражи и ошибки (например, инцидент TheDAO), что позволяет быстрее и более чистое разрешение. Каждая зона также может иметь свою собственную конституцию и управление. механизм тоже. Например, концентратор Cosmos может иметь конституция, которая обеспечивает неизменность в Хабе (без откатов, за исключением ошибок реализации узла концентратора Cosmos), в то время как каждая зона может устанавливать свою собственную политику в отношении откатов. Обеспечивая совместимость между различными зонами политики, Сеть Cosmos предоставляет своим пользователям максимальную свободу и возможности для несанкционированные эксперименты. Здесь мы описываем новую модель децентрализации и масштабируемости. Cosmos — это сеть из множества blockchain, работающих на Мята. Хотя существующие предложения направлены на создание «единой blockchain» с общим заказом глобальных транзакций, Cosmos позволяет многим blockchain работать одновременно друг с другом сохраняя при этом совместимость. По сути, хаб Cosmos управляет множеством независимых blockchains, называемые «зонами» (иногда называемые «осколками», в ссылка на метод масштабирования базы данных, известный как «шардинг»).

Постоянный поток последних коммитов блоков из зон, опубликованных на Hub позволяет Hub отслеживать состояние каждой зоны. Аналогично, каждая зона следит за состоянием Хаба (но зоны не идти в ногу друг с другом, кроме как косвенно через Хаб). Пакеты информации затем передаются от одного зону другому, разместив доказательства Меркла в качестве доказательства того, что информация была отправлена и получена. Этот механизм называется связь между blockchain или сокращенно IBC. Любая из зон сама может быть хабом для формирования ациклического графа. но для ясности мы опишем только простое конфигурация, в которой есть только один концентратор и множество неконцентраторов зоны. Хаб Cosmos — это blockchain, на котором размещено несколько активов. распределенный реестр, в котором token могут храниться отдельными пользователями или по самим зонам. Эти token можно переместить из одной зоны. другому в специальном пакете IBC, называемом «пакет монет». Концентратор ответственный за сохранение глобальной инвариантности полной количество каждого token в зонах. IBC пачка монет транзакции должны быть зафиксированы отправителем, концентратором и получателем blockchainс.Поскольку Cosmos Hub действует как центральный реестр для всего системы, безопасность Хаба имеет первостепенное значение. Пока каждая зона может представлять собой Tendermint blockchain, защищенный всего 4 (или даже меньше, если консенсус BFT не требуется), Hub должен быть защищен глобально децентрализованным набором validator, который может противостоять самым серьезным сценариям атак, таким как раздел континентальной сети или атака, спонсируемая национальным государством. Зона Cosmos — это независимая зона blockchain, которая обменивается IBC. сообщения с помощью Hub. С точки зрения Хаба, зона — это учетная запись с несколькими подписями и динамическим членством, которая может отправлять и получать token, используя пакеты IBC. Как криптовалютный счет, зона не может перевести более tokens, чем он имеет, но может получать token от других, у которых они есть. Зона может быть обозначен как «источник» одного или нескольких типов token, предоставив ему возможность инзацировать этот источник token. Атомы Cosmos Hub могут быть застейканы validators зоны подключен к хабу. В то время как атаки двойного расходования на эти зоны приведет к разделению атомов с помощью системы подотчетности Tendermint, зоны, в которой > ⅔ голосов Византийский может совершить недействительное состояние. Концентратор Cosmos не поддерживает проверять или выполнять транзакции, совершенные в других зонах, поэтому ответственность пользователей отправлять token в зоны, которым они доверяют. В будущем система управления Cosmos Hub может пройти мимо Hub. предложения по улучшению, учитывающие сбои зон. Для например, исходящие переводы token из некоторых (или всех) зон могут регулироваться для обеспечения аварийного отключения зон (временная остановка передачи token) при обнаружении атаки. Теперь посмотрим, как Хаб и зоны общаются друг с другом. другое. Например, если есть три blockchain: «Зона1», «Зона2»,

и «Хаб», и мы хотим, чтобы «Зона 1» создавала пакет, предназначенный для «Зоны 2» через «Хаб». Чтобы переместить пакет из одного blockchain другому, доказательство отправляется в принимающую цепочку. Доказательство гласит, что передающая цепочка опубликовала пакет для предполагаемое место назначения. Чтобы принимающая цепочка могла проверить это доказательство, она должен быть в состоянии успевать за заголовками блоков отправителя. Это механизм аналогичен тому, который используется в сайдчейнах, что требует две взаимодействующие цепи, чтобы знать друг о друге через двунаправленный поток датаграмм подтверждения существования (транзакции). Протокол IBC естественным образом может быть разработан с использованием двух типов транзакции: транзакция  IBCBlockCommitTx , которая позволяет blockchain, чтобы доказать любому наблюдателю свой последний блок - hash, и транзакция  IBCPacketTx , которая позволяет blockchain доказать любому наблюдателю, что данный пакет действительно был опубликован приложением отправителя, через доказательство Меркла к недавнему блок-hash. Разделив механику IBC на две отдельные транзакции, мы позволить внутреннему рыночному механизму комиссий принимающей цепочки определить, какие пакеты будут зафиксированы (т.е. подтверждены), в то время как предоставляя полную свободу в цепочке отправки относительно того, как разрешено много исходящих пакетов. В приведенном выше примере для обновления блока hash «Zone1» на «Hub» (или «Hub» на «Zone2»), IBCBlockCommitTxтранзакция должна быть размещена на «Хабе» с блоком hash «Зона1» (или «Зона2» с блоком hash «Хаба»). Дополнительную информацию см. в IBCBlockCommitTx и IBCPacketTx. для двух типов транзакций IBC. Точно так же, как Bitcoin более безопасен, поскольку является распределенным, массово тиражируемый реестр, мы можем сделать биржи менее уязвимыми для внешние и внутренние хаки, запустив его на blockchain. Мы назовите это распределенным обменом. То, что криптовалютное сообщество называет децентрализованным сегодняшние обмены основаны на так называемых транзакциях «атомной кроссчейн» (AXC). При транзакции AXC два пользователя на две разные цепочки могут совершать две транзакции перевода, которые зафиксировано одновременно в обоих реестрах или не зафиксировано вообще (т. е. атомарно). Например, два пользователя могут обменять биткойны на эфир (или любые два token в двух разных реестрах) с использованием транзакций AXC, хотя Bitcoin и Ethereum не подключены друг к другу другое. Преимущество обмена транзакциями AXC заключается в что ни пользователям не нужно доверять друг другу, ни системе сопоставления сделок. сервис. Обратной стороной является то, что обе стороны должны быть онлайн для торговля произойдет. Другой тип децентрализованной биржи — это массово тиражируемая биржа. распределенный обмен, работающий самостоятельно blockchain. Пользователи на этот вид биржи может подать лимитный ордер и развернуть свои компьютер выключен, и сделка может выполняться без участия пользователя. онлайн. blockchain соответствует и завершает сделку от имени трейдера.

Приложения

Централизованная биржа может создать глубокую книгу заказов с лимитами. заказов и тем самым привлечь больше трейдеров. Ликвидность порождает больше ликвидность в биржевом мире, поэтому существует сильная сеть эффект (или, по крайней мере, эффект «победитель получает большую часть») при обмене бизнес. Текущий лидер криптовалютных бирж сегодня находится Poloniex с 24-часовым объемом $20 млн, а на втором месте находится Bitynex с 24-часовым объемом в 5 миллионов долларов. Учитывая такую сильную сеть эффектов, маловероятно, что децентрализованные биржи на базе AXC выиграть объем над централизованными биржами. Для децентрализованного биржа, чтобы конкурировать с централизованной биржей, ей потребуется для поддержки глубоких книг заказов с лимитными ордерами. Только распределенный обмен на blockchain может это обеспечить. Tendermint обеспечивает дополнительные преимущества более быстрой транзакции. совершает. Отдавая приоритет быстрой динамичности, не жертвуя при этом согласованность, зоны в Cosmos могут быстро анализировать транзакции – для как транзакции обменных заказов, так и переводы IBC token на и из других зон. Учитывая сегодняшнее состояние криптовалютных бирж, отличный приложение для Cosmos — это распределенный обмен (он же Cosmos DEX). Пропускная способность транзакций, а также задержка фиксации может быть сравнима с задержкой централизованного обмены. Трейдеры могут отправлять лимитные ордера, которые могут быть исполнены. без необходимости присутствия обеих сторон в сети. И с Тендерминтом, хаб Cosmos и IBC, трейдеры могут вводить и выводить средства быстрый обмен данными с другими зонами. Привилегированная зона может выступать в качестве источника мостового token еще одна криптовалюта. Мост похож на отношения между концентратором Cosmos и зоной; оба должны идти в ногу с последние блоки друг друга, чтобы проверить доказательства того, что tokens имеют перешел из одного в другой. «Мост-зона» на Cosmos. сеть не отстает от концентратора, а также от других

криптовалюта. Косвенное направление через зону моста позволяет логика Хаба должна оставаться простой и независимой от других blockchain консенсусные стратегии, такие как proof-of-work Bitcoin добыча полезных ископаемых. В каждой зоне моста validator будет работать сервер на базе Tendermint. blockchain со специальным мостовым приложением ABCI, а также с полным узлом «происхождение» blockchain. Когда в источнике добываются новые блоки, зона моста validators придут к соглашению о зафиксированных блоках, подписав и делятся своим местным мнением об источнике blockchain. совет. Когда мостовая зона получает платеж от источника (и было решено, что по делу были рассмотрены достаточные подтверждения цепочки PoW, например Ethereum или Bitcoin), соответствующий аккаунт создается в бридж-зоне с этим балансом. В случае Ethereum зона моста может использовать один и тот же validator — установлен как концентратор Cosmos. На стороне Ethereum ( origin), мостовой контракт позволит держателям эфира отправлять эфир в бридж-зону, отправив его в бридж-контракт на Ethereum. Как только эфир будет получен бридж-контрактом, эфир нельзя вывести, пока не будет получен соответствующий пакет IBC. полученные по бридж-контракту от бридж-зоны. Bridge-contract отслеживает набор validator зоны моста, который может быть идентичен набору validator концентратора Cosmos. В случае Bitcoin концепция аналогична, за исключением того, что вместо один мостовой контракт, каждый UTXO будет контролироваться пороговая мультиподпись P2SH. Из-за ограничений системе P2SH подписывающие стороны не могут быть идентичными Cosmos Ступица validator-комплект.Эфир в бридж-зоне («мостовой эфир») можно перевести на и из Хаба, а затем быть уничтожены с помощью транзакции, которая отправляет его на определенный адрес вывода средств Ethereum. IBC пакет, подтверждающий, что транзакция произошла в зоне моста может быть опубликован в мостовом контракте Ethereum, чтобы разрешить эфир быть отозванным. В случае Bitcoin система ограниченных сценариев делает это сложно отразить механизм перевода монет IBC. Каждый UTXO имеет свою собственную независимую публикацию, поэтому каждый UTXO должен быть перенесен на новый UTXO при изменении набора Bitcoin лица, подписавшие условное депонирование. Одним из решений является сжатие и распакуйте набор UTXO по мере необходимости, чтобы сохранить общее число из UTXOс не работает. Риск такого промежуточного контракта представляет собой мошеннический набор validator. ≥⅓ Византийское право голоса может вызвать форк, выводящий эфир из контракта о мосте на Ethereum, сохраняя при этом мост в зоне моста. Хуже того, более ⅔ византийского права голоса может украсть эфир начисто у тех, кто отправил его на бридж-контракт отклоняясь от исходной логики мостовой зоны. Решить эти проблемы можно, спроектировав мост так, чтобы он был полностью подотчетен. Например, все пакеты IBC от концентратора и происхождения, может потребоваться подтверждение со стороны мостовой зоны в таким образом, чтобы все переходы состояний мостовой зоны могли быть эффективно оспаривается и проверяется либо хабом, либо источником мост-контракт. Хаб и источник должны разрешить мостовой зоне validators размещать обеспечение, а token переводить из бридж-контракт должен быть отложен (и расторжение залога достаточно длительный период), чтобы можно было решать любые проблемы, независимые аудиторы. Мы оставляем дизайн спецификации и реализация этой системы открыта в будущем Cosmos

предложение по улучшению, которое должно быть принято Cosmos Hub система управления. Решение проблемы масштабирования является открытой проблемой для Ethereum. В настоящее время узлы Ethereum обрабатывают каждую транзакцию и также сохраните все состояния. связь. Поскольку Tendermint может фиксировать блоки намного быстрее, чем Ethereum Зоны proof-of-work, EVM, основанные на консенсусе Tendermint и работа на мостовом эфире может обеспечить более высокую производительность Ethereum blockchainс. Кроме того, хотя концентратор Cosmos и Механика пакетов IBC не допускает произвольной логики контракта исполнение как таковое, его можно использовать для координации token движений между Ethereum контрактами, работающими в разных зонах, обеспечивая основу для token-центричного Ethereum масштабирования с помощью шардинг. Зоны Cosmos выполняют произвольную логику приложения, которая определяется начало жизни зоны и потенциально может обновляться со временем правительством. Такая гибкость позволяет Cosmos зонам действовать как мосты к другим криптовалютам, таким как Ethereum или Bitcoin, а также допускает производные от этих blockchain, используя ту же кодовую базу, но с другим набором validator и первоначальное распространение. Это позволяет многим существующим криптовалютам фреймворки, такие как Ethereum, Zerocash, Bitcoin, CryptoNote и т. д. для использования с Tendermint Core, который механизм консенсуса с более высокой производительностью в общей сети, открывая огромные возможности для взаимодействия между платформы. Кроме того, в качестве мультиактива blockchain один транзакция может содержать несколько входов и выходов, где каждый ввод может быть любого типа token, что позволяет Cosmos служить непосредственно в качестве платформа для децентрализованного обмена, хотя заказы предполагаютсядля сопоставления через другие платформы. В качестве альтернативы зона может служить как распределенная отказоустойчивая биржа (с книгами заказов), которая может быть строгим улучшением по сравнению с существующими централизованными криптовалютные биржи, которые со временем часто подвергаются взлому. Зоны также могут служить blockchain версиями корпоративных и правительственные системы, где части конкретной услуги, которые традиционно управляются организацией или группой организаций вместо этого запускаются как приложение ABCI в определенной зоне, что позволяет ему унаследовать безопасность и совместимость общедоступных Cosmos сети, не жертвуя контролем над базовой сервис. Таким образом, Cosmos может предложить лучшее из обоих миров для организации, желающие использовать технологию blockchain, но которые опасаясь полностью передать контроль распределенной третьей стороне вечеринка. Некоторые утверждают, что основная проблема с обеспечением согласованности консенсусных алгоритмов, таких как Tendermint, заключается в том, что любая сеть раздел, из-за которого не существует ни одного раздела с размером >⅔ Количество голосов (например, выход из журнала ≥⅓) полностью остановит консенсус. Архитектура Cosmos может помочь смягчить эту проблему, используя глобальный центр с региональными автономными зонами, где право голоса для каждой зоны распределяются на основе общего географического регион. Например, общая парадигма может быть для отдельных города или регионы, чтобы управлять своими собственными зонами, разделяя при этом общий центр (например, Cosmos Hub), позволяющий муниципальной деятельности сохраняться в случае остановки хаба из-за временной неисправности сети перегородка. Обратите внимание, что это позволяет реальным геологическим, политическим и топологические особенности сети, которые следует учитывать при проектировании надежного федеративные отказоустойчивые системы.

NameCoin был одним из первых blockchain, попытавшихся решить проблема разрешения имен путем адаптации Bitcoin blockchain. К сожалению, при таком подходе возникло несколько проблем. С помощью Namecoin мы можем убедиться, что, например, @satoshi был зарегистрированный с определенным открытым ключом в какой-то момент в прошлом, но мы не будем знать, был ли с тех пор открытый ключ обновлено недавно, если мы не загрузим все блоки с момента последнего обновление этого имени. Это связано с ограничением Bitcoin UTXO транзакция Модель Мерклеизации, где только транзакции (но не изменяемое состояние приложения) являются меркловскими в блок-hash. Это позволяет нам доказать существование, а не несуществование более поздних обновлений имени. Таким образом, мы не можем знать, определить самое последнее значение имени, не доверяя полной узла или понести значительные затраты на пропускную способность из-за загрузки весь blockchain. Даже если бы в NameCoin было реализовано дерево поиска в стиле Меркла, его зависимость от proof-of-work упрощает проверку клиента проблематично. Легкие клиенты должны загрузить полную копию заголовки для всех блоков всего blockchain (или, по крайней мере, всех заголовки с момента последнего обновления имени). Это означает, что Требования к пропускной способности линейно масштабируются с течением времени [21]. Кроме того, имя меняется на proof-of-work blockchain. требует ожидания дополнительных блоков подтверждения proof-of-work, это может занять до часа на Bitcoin. В случае с Tendermint все, что нам нужно, это самый последний блок — hash. подписано кворумом в validators (по числу голосов) и членом Меркла подтверждение текущего значения, связанного с именем. Это делает это возможно иметь краткий, быстрый и безопасный легкий клиент проверка значений имени. В Cosmos мы можем взять эту концепцию и расширить ее. Каждый Зона регистрации имен в Cosmos может иметь связанное имя домена верхнего уровня (TLD), например «.com» или «.org», и каждое имя-

зона регистрации может иметь собственное управление и регистрацию правила.

Управление и экономика

Хотя Cosmos Hub представляет собой распределенный реестр с несколькими активами, существует особый природный объект token, называемый атомом. Атомы — единственные staking token узла Cosmos. Атомы — это лицензия для владельца на голосуйте, подтверждайте или делегируйте полномочия другим validator. Нравится Ethereum эфира, атомы также можно использовать для оплаты комиссий за транзакции уменьшить спам. Дополнительные инзационные атомы и блочная транзакция гонорары вознаграждаются validator и делегаторов, делегирующих полномочия validatorс. Транзакция  BurnAtomTx  может использоваться для восстановления любого пропорциональная сумма tokens из резервного пула. Первоначальное распределение атомов tokens и validators в книге Бытия. пойдут донорам Cosmos Сбора средств (75%), ведущие доноры (5%), Cosmos Network Foundation (10%) и ALL IN BITS, Inc. (10%). Начиная с зарождения, 1/3 общего количества атомов будет будут вознаграждены связанным validator и делегатам каждый год. Дополнительные сведения см. в плане Cosmos. В отличие от Bitcoin или других proof-of-work blockchain, Tendermint blockchain становится медленнее при увеличении количества validator из-за увеличения сложность общения. К счастью, мы можем поддержать достаточно validators для создания надежного глобально распределенного blockchain с очень быстрым временем подтверждения транзакций и, что касается пропускной способности,

хранилища и увеличится мощность параллельных вычислений, мы сможем для поддержки большего количества validator в будущем. В день создания максимальное количество validator будет установлено равным 100, и это число будет увеличиваться со скоростью 13% в течение 10 лет, и расчет на уровне 300 validators. Владельцы атомов, которые еще этого не сделали, могут стать validators путем подписание и отправка транзакции  BondTx . Сумма атомы, предоставленные в качестве залога, должны быть ненулевыми. Любой может стать validator в любое время, за исключением случаев, когда размер текущего Набор validator превышает максимальное количество validator. разрешено. В этом случае сделка действительна только в том случае, если сумма атомов больше, чем количество эффективных атомов, удерживаемых наименьший validator, где эффективные атомы включают делегированные атомы. Когда новый validator заменяет существующий validator таким образом, существующий validator становится неактивным, и все атомы и делегированные атомы переходят в состояние разъединения. На validators должен быть наложен какой-то штраф за любое умышленное или неумышленное отклонение от санкционированного протокол. Некоторые доказательства являются допустимыми сразу, например, двойной знак на одной и той же высоте и витке, либо нарушение Год 0: 100  Год 1: 113  Год 2: 127  Год 3: 144  Год 4: 163  Год 5: 184  Год 6: 208  Год 7: 235  Год 8: 265  Год 9: 300  10 год: 300  ...

«prevote-the-lock» (правило консенсусного протокола Tendermint). Подобные доказательства приведут к потере validator своей хорошей репутации. и его связанные атомы, а также его пропорциональную долю tokens в резервный пул, который в совокупности называется «долей», будет сокращен. Иногда validator будут недоступны либо из-за региональных сбои в сети, сбой питания или другие причины. Если в любой момент точка в прошлых блоках  ValidatorTimeoutWindow , validator голосование за принятие не включено в blockchain более чем  ValidatorTimeoutMaxAbsent  раз, то validator станет неактивен и теряет  ValidatorTimeoutPenalty  (ПО УМОЛЧАНИЮ 1 %) ставка. Некоторые «злонамеренные» действия не приводят к явно различимым последствиям. доказательства по делу blockchain. В этих случаях validator могут координировать внеполосные действия, чтобы принудительно отключить эти вредоносные validators, если существует консенсус сверхбольшинства. В ситуациях, когда хаб Cosmos останавливается из-за коалиции ≥⅓ количество голосов теряется в журнале или в ситуациях, когда коалиция ≥⅓ Цензура голосов, свидетельствующая о злонамеренном поведении со стороны входя в blockchain, хаб должен восстановиться с помощью хард-форка реорг-предложение. (Ссылка на «Форки и цензурные атаки»). Cosmos Концентратор validators может принимать любой тип token или комбинацию типов в качестве комиссий за обработку транзакции. Каждый validator может субъективно установить любой обменный курс, который он хочет, и выбрать любые транзакции, которые он хочет, при условии, что  BlockGasLimit  не превышен. Собранные сборы за вычетом любых налогов, указанных ниже, перераспределяются среди связанных стейкхолдеров пропорционально их связанные атомы, каждый  ValidatorPayoutPeriod  (ПО УМОЛЧАНИЮ 1 час).Из собранной комиссии за транзакцию  ReserveTax  (ПО УМОЛЧАНИЮ 2%) будет идите к резервному пулу, чтобы увеличить резервный пул и повысить безопасность и ценность сети Cosmos. Эти средства также могут распределяться в соответствии с решениями производится системой управления. Владельцы атомов, которые делегируют свое право голоса другим validator. выплатить комиссию делегированному validator. Комиссия может устанавливается каждым validator. Безопасность хаба Cosmos является функцией безопасности лежащие в основе validators и выбор делегирования делегирующими лицами. Чтобы стимулировать обнаружение и раннее сообщение о найденных уязвимостей, хаб Cosmos призывает хакеров публиковать успешные эксплойты через транзакцию  ReportHackTx , в которой говорится: «Этот validator был взломан. Пожалуйста, пришлите награду на этот адрес». После такой эксплойт, validator и делегаторы станут неактивными,  HackPunishmentRatio  (по умолчанию 5%) всех атомов получит сокращено, а  HackRewardRatio  (по умолчанию 5%) всех атомов получит вознаграждение на баунти-адрес хакера. validator должен восстановить оставшиеся атомы, используя их резервный ключ. Чтобы предотвратить злоупотребление этой функцией для передачи неинвестированные атомы, доля наделенных и неинвестированных атомов validators и делегаторы до и после  ReportHackTx  будут останется прежним, а награда за хакера будет включать в себя некоторые нераспределенные атомы, если таковые имеются. Хаб Cosmos управляется распределенной организацией, которая требует хорошо продуманного механизма управления, чтобы координировать различные изменения в blockchain, например переменную

параметры системы, а также обновления программного обеспечения и конституционные поправки. Все validator несут ответственность за голосование по всем предложениям. Не удалось Своевременное голосование по предложению приведет к validator автоматически деактивируется на период времени, называемый  Прогул на штрафной период (ПО УМОЛЧАНИЮ 1 неделя). Делегаторы автоматически наследуют голоса делегированных validator. Это голосование может быть отменено вручную. Несвязанные атомы не получить голоса. Для каждого предложения требуется внести депозит в размере MinimumProposalDeposit.  token, которые могут представлять собой комбинацию одного или нескольких token. включая атомы. По каждому предложению избиратели могут проголосовать за принятие депозит. Если более половины избирателей выберут депозит (например, потому что предложение было спамом), депозит переходит на резервный пул, за исключением сгоревших атомов. По каждому предложению избиратели могут голосовать следующими вариантами: Да ДаСфорс Нет NayWithForce Воздерживаться Строгое большинство голосов за или YeaWithForce (или против, или голосов NayWithForce) требуется для того, чтобы предложение было принято как принято (или решено как проваленное), но 1/3+ могут наложить вето на большинство решение путем голосования «принудительным». Когда строгое большинство накладывает вето, все будут наказаны потерей  VetoPenaltyFeeBlocks  (ПО УМОЛЧАНИЮ блоков за 1 день) стоимость сборов (кроме налогов которая не будет затронута), и партия, наложившая вето на большинство

решение будет дополнительно наказано потерей  VetoPenaltyAtoms  (ПО УМОЛЧАНИЮ 0,1%) его атомов. Любой из определенных здесь параметров можно изменить с помощью передача  ParameterChangeProposal. Атомы можно интегрировать и резервировать средства пула, потраченные с помощью принятие  BountyProposal. Все остальные предложения, такие как предложение по обновлению протокола, будет координироваться с помощью общего  TextProposal . См. План. В консенсусе blockchain было много нововведений и масштабируемость за последние пару лет. В этом разделе представлено краткое обзор избранного числа важных из них. Консенсус в присутствии злонамеренных участников является проблемой восходит к началу 1980-х годов, когда Лесли Лэмпорт придумал фраза «Византийская ошибка» относится к произвольному поведению процесса, которое отклоняется от запланированного поведения, в отличие от «аварии», при этом процесс просто аварийно завершает работу. Были обнаружены ранние решения для синхронных сетей, где существует верхняя границазадержка сообщения, хотя практическое использование было ограничено высокой контролируемые среды, такие как диспетчеры самолетов и центры обработки данных синхронизируются с помощью атомных часов. Так было до тех пор, пока В конце 90-х годов «Практическая византийская отказоустойчивость» (PBFT) PH_0000 была представлен как эффективный частично синхронный консенсус алгоритм, способный выдерживать поведение до ⅓ процессов произвольно. PBFT стал стандартным алгоритмом, породив множество вариации, включая самый последний, созданный IBM в рамках их вклад в Hyperledger. Основное преимущество консенсуса Tendermint по сравнению с PBFT заключается в том, что Tendermint имеет улучшенную и упрощенную базовую структуру. некоторые из них являются результатом принятия парадигмы blockchain. Блоки Tendermint должны фиксироваться по порядку, что позволяет избежать сложность и накладные расходы на связь, связанные с PBFT просмотр-изменения. В Cosmos и многих криптовалютах нет необходимо разрешить блок N+i, где i >= 1, для фиксации, когда блок N сама еще не взяла на себя обязательства. Если пропускная способность является причиной блокировки N не совершил коммит в зоне Cosmos, то использование не поможет голосование за разделение полосы пропускания для блоков N+i. Если сетевой раздел или узлы журнала являются причиной того, что блок N не зафиксировался, тогда Н+я в любом случае не буду брать на себя обязательства. Кроме того, группировка транзакций в блоки позволяет регулярное Merkle-hash состояние приложения, а не периодические дайджесты, как в схеме контрольных точек PBFT. Это позволяет для более быстрого и доказуемого подтверждения транзакций для легких клиентов и более быстрого меж-blockchain связь. Tendermint Core также включает в себя множество оптимизаций и функций. которые выходят за рамки того, что указано в PBFT. Например, блоки, предложенные validators, разделены на части, Меркле-изированы, и сплетничали таким образом, чтобы улучшить вещание производительность (для вдохновения см. LibSwift [19]). А еще Тендерминт Core не делает никаких предположений о двухточечном соединении.

возможность подключения и работает до тех пор, пока работает P2P-сеть. слабо связан. Хотя BitShares1.0 [12] не является первым развертыванием proof-of-stake (PoS), внес значительный вклад в исследование и внедрение PoS blockchain, особенно те, которые известны как «делегированные» PoS. В BitShares, заинтересованные стороны выбирают «свидетелей», ответственных за оформление заказа и совершение транзакций, а также «делегаты», ответственные за координация обновлений программного обеспечения и изменений параметров. BitShares2.0 нацелен на достижение высокой производительности (100 тыс. транзакций в секунду, 1 с). задержка) в идеальных условиях, когда каждый блок подписан одним подписывающему лицу, а качество транзакции занимает немного больше времени, чем интервал блока. Каноническая спецификация все еще находится в разработке. Заинтересованные стороны могут удалить или заменить свидетелей, плохо себя ведущих ежедневно, но нет существенного залога в виде свидетелей или делегаты по подобию Tendermint PoS, которые врезаются в случае успешной атаки двойной траты. Опираясь на подход, впервые предложенный Ripple, Stellar [13] Рейнед модель Федеративного Византийского соглашения, в которой процессы участие в консенсусе не представляют собой фиксированного и глобального известный набор. Скорее, каждый узел процесса курирует один или несколько «куски кворума», каждый из которых представляет собой набор доверенных процессов. А «Кворум» в Stellar определяется как набор узлов, содержащих хотя бы один срез кворума для каждого узла в наборе, такой, что соглашение может быть достигнуто. Безопасность механизма Stellar основана на предположении что пересечение любых двух кворумов непусто, а доступность узла требует, чтобы хотя бы один из его срезов кворума был полностью состоять из правильных узлов, создавая компромисс между использование больших или малых фрагментов кворума, которые может быть сложно сбалансировать без навязывания существенных предположений о доверии. В конечном счете,узлы должны каким-то образом выбрать адекватные фрагменты кворума, чтобы иметь достаточную отказоустойчивость (или вообще любые «неповреждённые узлы», из которых от этого зависит большая часть результатов статьи), и единственное предоставленная стратегия обеспечения иерархичности такой конфигурации и похож на протокол пограничного шлюза (BGP), используемый интернет-провайдерами высшего уровня для создания глобальных таблиц маршрутизации, а также который используется браузерами для управления сертификатами TLS; оба печально известные из-за их неуверенности. Критика в статье Stellar систем доказательства доли на основе Tendermint смягчается описанной стратегией token. здесь выдается новый тип token, называемый атомом, который представляют собой претензии на будущие части гонораров и вознаграждений. Таким образом, преимущество proof-of-stake на основе Tendermint является его относительным простота, но при этом обеспечивает достаточную и доказуемую безопасность гарантии. BitcoinNG — это предлагаемое улучшение Bitcoin, которое позволит для форм вертикальной масштабируемости, таких как увеличение размера блока, без негативных экономических последствий, обычно связанных с с таким изменением, таким как непропорционально большое влияние на мелких майнерах. Это улучшение достигается за счет разделения выборы лидера из трансляции транзакций: лидеры впервые избранный proof-of-work в «микроблоках», а затем имеющий возможность широковещательные транзакции, которые будут зафиксированы до появления нового микроблока найден. Это снижает требования к полосе пропускания, необходимые для выиграть гонку PoW, что позволит мелким майнерам более честно конкурировать, и разрешить более регулярное совершение транзакций со стороны последний майнер, нашедший микроблок. Casper [16] — это предложенный алгоритм консенсуса proof-of-stake для Ethereum. Его основной режим работы – «консенсус за ставкой». Автор позволяя validators итеративно делать ставки на то, какой блок, по их мнению, будет

стать приверженцем blockchain на основании других ставок что они видели до сих пор, инальность может быть достигнута в конечном итоге. связь. Это активная область исследований команды Casper. Задача состоит в создании механизма ставок, который можно было бы оказалась эволюционно стабильной стратегией. Основная польза от Casper по сравнению с Tendermint может предлагать «доступность» чрезмерная последовательность» – для достижения консенсуса не требуется кворум >⅔ количество голосов – возможно, за счет скорости принятия решений или сложность реализации. Протокол Interledger [14] не является строго решением масштабируемости. Это обеспечивает специальное взаимодействие между различными реестрами системы через слабосвязанную сеть двусторонних отношений. Как и в случае с Lightning Network, цель ILP – облегчить платежи, но он специально фокусируется на платежах по разным типы реестров и расширяет механизм атомарных транзакций для включать не только hash-замки, но и кворум нотариусов (так называемый «Атомный транспортный протокол»). Последний механизм для обеспечение атомарности в транзакциях между реестрами аналогично Механизм SPV легкого клиента Tendermint, поэтому иллюстрация различие между ILP и Cosmos/IBC гарантировано, и представлено ниже. 1. Нотариусы коннектора в ILP не поддерживают членство изменения и не допускают гибкого взвешивания между нотариусы. С другой стороны, IBC разработан специально для blockchains, где validators могут иметь разные веса, и где членство может меняться в течение blockchain. 2. Как и в Lightning Network, получатель платежа в ILP должен быть онлайн, чтобы отправить подтверждение отправителю. Вtoken передача через IBC, набор validator получателя За предоставление подтверждения отвечает blockchain, а не принимающий пользователь. 3. Самое поразительное отличие заключается в том, что разъемы ILP не ответственное или авторитетное государство в отношении платежей, тогда как в Cosmos validator концентратора являются полномочиями состояние IBC token передается, а также полномочия количество tokens, удерживаемое каждой зоной (но не количество tokens принадлежат каждой учетной записи в зоне). Это фундаментальная инновация, позволяющая обеспечить безопасную асимметричную перенос tokens из зоны в зону; аналог ILP соединитель в Cosmos — это постоянный и максимально безопасный blockchain реестр, концентратор Cosmos. 4. Платежи между реестрами в рамках ILP должны быть подкреплены биржевой стакан заявок, так как нет асимметричной передачи монеты из одного реестра в другой, только передача стоимости или рыночные эквиваленты. Сайдчейны [15] — это предлагаемый механизм масштабирования Bitcoin. сеть через альтернативные blockchain, которые «двусторонне привязаны» к Bitcoin blockchain. (Двусторонняя привязка эквивалентна мост. В Cosmos мы говорим «мост», чтобы отличить его от рыночной привязки). Сайдчейны позволяют биткойнам эффективно перемещаться из Bitcoin blockchain в сайдчейн и обратно, а также разрешить экспериментирование с новыми функциями сайдчейна. Как и в Cosmos Хаб, сайдчейн и Bitcoin служат лёгкими клиентами друг друга, используя доказательства SPV, чтобы определить, когда монеты должны быть переносится в сайдчейн и обратно. Конечно, поскольку Bitcoin использует proof-of-work, страдают сайдчейны, сосредоточенные вокруг Bitcoin. от многих проблем и рисков proof-of-work как механизм консенсуса. Кроме того, это Bitcoin-максималист решение, которое изначально не поддерживает различные token и

топология межзоновой сети, как это делает Cosmos. Тем не менее, ядро механизм двусторонней привязки в принципе такой же, как и у работает в сети Cosmos. Ethereum в настоящее время исследует ряд различных стратегий. сегментировать состояние Ethereum blockchain по адресу потребности в масштабируемости. Эти усилия имеют целью поддержание уровень абстракции, предлагаемый текущей виртуальной машиной Ethereum через общее пространство состояний. Многочисленные исследовательские усилия в настоящее время ведется. [18][22] Cosmos и Ethereum 2.0 Сиреневый [22] преследуют разные цели дизайна. Cosmos конкретно относится к token. Mauve — это масштабирование общий расчет. Cosmos не привязан к EVM, поэтому даже разные виртуальные машины могут взаимодействовать. Cosmos позволяет создателю зоны определить, кто проверяет зона. Любой может создать новую зону в Cosmos (кроме случаев, когда управление решит иначе). Концентратор изолирует сбои зон, поэтому глобальные инварианты token сохранился. Lightning Network — это предлагаемая сеть передачи данных token. работающий на уровне выше Bitcoin blockchain (и других общедоступных blockchains), позволяющие улучшить ситуацию на многие порядки. в пропускной способности транзакций за счет перемещения большинства транзакций за пределы консенсусного реестра в так называемые «платёжные каналы».Это стало возможным благодаря внутрисетевым скриптам криптовалюты, которые позволяют сторонам заключать двусторонние договоры, предусматривающие статус государства, в которых состояние можно обновлять путем обмена цифровыми подписями и контрактами. можно закрыть, опубликовав доказательства на blockchain, Механизм впервые популяризировался посредством атомных свопов между цепочками. Автор открытие каналов оплаты со многими сторонами, участниками Lightning Network может стать центром маршрутизации платежи других, что приводит к полностью подключенному платежному каналу сети, за счет капитала, привязанного к платежным каналам. Хотя сеть Lightning также может легко распространяться на несколько независимых blockchain для обеспечения передачи стоимости через валютный рынок, его нельзя использовать для асимметричного перенести token с одного blockchain на другой. Основная польза описанной здесь сети Cosmos заключается в том, чтобы обеспечить такую прямую token переводы. Тем не менее, мы ожидаем, что каналы оплаты и Lightning Network получит широкое распространение вместе с нашей token механизм передачи, предназначенный для экономии средств и обеспечения конфиденциальности. Segregated Witness — это Bitcoin ссылка на предложение по улучшению, которая направлен на увеличение пропускной способности транзакций на блок в 2 или 3 раза, одновременно ускоряя синхронизацию блоков для новых узлов. Гениальность этого решения в том, как оно работает внутри ограничения текущего протокола Bitcoin и допускает софт-форк обновление (т. е. клиенты с более старыми версиями программного обеспечения будут продолжать работать после обновления). Tendermint — новый продукт протокол, не имеет конструктивных ограничений, поэтому имеет другое масштабирование приоритеты. В первую очередь, Tendermint использует алгоритм циклического перебора BFT. на основе криптографических подписей вместо майнинга, что тривиально позволяет горизонтальное масштабирование посредством нескольких параллельных blockchains, в то время как регулярные, более частые фиксации блоков позволяют вертикальное масштабирование.

Консенсус и технические детали

Хорошо разработанный протокол консенсуса должен обеспечить некоторые гарантии в случае превышения допускаемой мощности и консенсус терпит неудачу. Это особенно необходимо в экономической сфере. системы, в которых византийское поведение может иметь существенные финансовые последствия. награда. Самой важной такой гарантией является форма форкаподотчетности, при которой процессы, вызвавшие консенсус, сбой (т. е. заставил клиентов протокола принимать разные значения - вилка) могут быть выявлены и наказаны в соответствии с правилами протокол или, возможно, правовая система. Когда правовая система ненадежны или слишком дороги в вызове, validator могут быть были вынуждены внести залог для участия, и те депозиты могут быть отозваны или сокращены в случае выявления злонамеренного поведения. обнаружен [10]. Обратите внимание, что это не похоже на Bitcoin, где разветвление происходит регулярно. из-за сетевой асинхронности и вероятностного характера поиска частичные hash коллизии. Поскольку во многих случаях вредоносный форк неотличим от форка из-за асинхронности, Bitcoin не может надежно реализовать форк-подотчетность, кроме неявной Альтернативная стоимость, которую платят майнеры за добычу потерянного блока. Мы называем этапы голосования PreVote и PreCommit. Голосование может быть за конкретный блок или для Nil. Мы называем коллекцию из >⅔ PreVotes за один блок в одном раунде Полька и коллекция >⅔ PreCommits для одного блока в одном раунде фиксации. Если >⅔ PreCommit for Nil в том же раунде, они переходят к следующему круглый. Обратите внимание, что строгий детерминизм в протоколе влечет за собой слабую предположение синхронности, поскольку дефектные лидеры должны быть обнаружены и

пропущен. Таким образом, validator ждут некоторое время, TimeoutPropose, прежде чем они проголосуют за ноль, и значение TimeoutPropose увеличивается с каждым раундом. Прогресс через оставшаяся часть раунда полностью асинхронна, то есть прогресс только сделано, как только validator получит сообщение от >⅔ сети. На практике потребуется чрезвычайно сильный противник, чтобы навсегда помешать предположение о слабой синхронности (из-за которого консенсус не может быть достигнут) когда-либо фиксировать блок), и это можно сделать еще более сложно использовать случайные значения TimeoutPropose для каждого validator. Дополнительный набор ограничений или правил блокировки гарантирует, что сеть в конечном итоге зафиксирует только один блок на каждой высоте. Любой злонамеренная попытка вызвать фиксацию более одного блока на заданной высоте можно идентифицировать. Во-первых, PreCommit для блока должно прийти с обоснованием, в виде польки для этого блока. Если validator уже имеет PreCommit блок на этапе R_1, мы говорят, что они заперты в этом квартале, и полька раньше оправдывала новый PreCommit в раунде R_2 должен прийти в раунде R_polka где Р_1 < Р_полька <= Р_2. Во-вторых, validator должны сделать предложение. и/или предварительно проголосовать за блок, на котором они заблокированы. Вместе эти условия гарантируют, что validator не выполняет PreCommit без достаточные доказательства в качестве оправдания, и что validators, которые имеют PreCommit уже не может предоставлять доказательства PreCommit что-то еще. Это обеспечивает безопасность и жизнеспособность алгоритм консенсуса. Полная информация о протоколе описана здесь. Необходимость синхронизации всех заголовков блоков в TendermintPoS устранена, поскольку существование альтернативной цепочки (форка) означает ≥⅓ облигационную ставку можно сократить. Конечно, поскольку слэшинг требует что кто-то поделится доказательствами форка, легкие клиенты должны хранить любой блок-hash фиксирует то, что видит. Кроме того, легкие клиентыможет периодически синхронизироваться с изменениями в наборе validator, в чтобы избежать атак на большие расстояния (но есть и другие решения). возможно). По духу схожий с Ethereum, Tendermint позволяет приложениям встроить глобальный корень Меркла hash в каждый блок, что позволяет легко проверяемые запросы состояния для таких вещей, как баланс счетов, значение хранится в контракте или наличие неизрасходованной транзакции выход в зависимости от характера приложения. Предполагая, что набор широковещательных сетей достаточно устойчив. и статический набор validator, любая вилка в blockchain может быть обнаружены, а депозиты нарушителей validator удалены. Это инновация, впервые предложенная Виталиком Бутериным в начале 2014 года, решает проблема «ничего на кону» другого proof-of-stake криптовалюты (см. раздел «Связанные работы»). Однако, поскольку validator устанавливает должен иметь возможность изменять в течение длительного периода времени исходный Все validator могут потерять связь и, следовательно, смогут свободно создать новую цепочку из генезис-блока, не неся никаких затрат, поскольку у них больше нет заблокированных депозитов. Эта атака произошла известная как Атака на дальнюю дистанцию (LRA), в отличие от Короткой атаки. Атака на расстоянии, при которой validator, которые в данный момент связаны, вызывают форк и, следовательно, наказуемы (при условии, что форк несет ответственность BFT алгоритм, такой как консенсус Tendermint). Атаки на дальние дистанции часто считается критическим ударом по proof-of-stake. К счастью, влияние LRA можно смягчить следующим образом. Во-первых, для validator разорвать связь (тем самым вернув залоговый депозит и больше не получаю комиссию за участие в консенсусе), депозит должен быть непереводимым в течение определенного периода времени известный как «период разъединения», который может быть порядка недели или месяцы. Во-вторых, чтобы легкий клиент был безопасным, в первую очередь при подключении к сети он должен проверить недавний блок — hash против надежного источника или, предпочтительно, нескольких источников. Это

Это состояние иногда называют «слабой субъективностью». Наконец, чтобы оставаться в безопасности, он должен синхронизироваться с последней версией validator, установленной по адресу по крайней мере так часто, как продолжительность периода отсоединения. Это гарантирует, что легкий клиент узнает об изменениях в validator устанавливается до того, как капитал validator будет освобожден от обязательств и, следовательно, больше не будет на кону, что позволило бы обмануть клиента, выполняя атака на дальнюю дистанцию путем создания новых блоков, начиная с высота, на которой он был прикреплен (при условии, что он контролирует достаточно многие из ранних закрытых ключей). Отметим, что преодоление ЛРА таким путем требует пересмотра исходная модель безопасности proof-of-work. В PoW это предположил, что легкий клиент может синхронизироваться с текущей высотой из доверенный блок генезиса в любое время, просто обрабатывая подтверждение работы в каждом заголовке блока. Однако, чтобы победить ЛРА, мы требуют, чтобы легкий клиент подключался к сети с некоторой регулярностью для отслеживать изменения в наборе validator и что в первый раз они выходят в Интернет, они должны быть особенно осторожны при аутентификации что они слышат из сети в отношении проверенных источников. Из конечно, последнее требование аналогично требованию Bitcoin, где протокол и программное обеспечение также должны быть получены от доверенного лица. источник. Вышеописанный метод предотвращения LRA хорошо подходит для validators. и полные узлы blockchain на базе Tendermint, потому что эти узлы предназначены для того, чтобы оставаться подключенными к сети. метод также подходит для легких клиентов, от которых можно ожидать часто синхронизируйтесь с сетью. Однако для легких клиентов, которые не предполагается, что они будут иметь частый доступ к Интернету или blockchain, можно использовать еще одно решение для преодоления ЛРА. Владельцы validator token могут публиковать свои token как залог с очень длительным периодом отсоединения (например, гораздо более длительный чем период отсоединения для validators) и обслуживать легких клиентов с вторичным методом подтверждения действительности текущих и прошлый блок-hashes. Хотя эти token не засчитываются в счет безопасности консенсуса blockchain, они, тем не менее, могутпредоставить надежные гарантии для легких клиентов. Если исторический блок-hash запросы поддерживались в Ethereum, любой мог связать свои tokens в специально разработанном smart contract и обеспечивают платные услуги по аттестации, что эффективно создает рынок безопасности LRA для легких клиентов. В связи с определением фиксации блока любая коалиция ≥⅓ блоков Право голоса может остановить blockchain, выйдя из журнала или нет транслируя свои голоса. Такая коалиция может также подвергать цензуре определенные транзакции, отклоняя блоки, которые включают в себя эти транзакций, хотя это привело бы к значительной доле блоков предложений, которые будут отклонены, что замедлит скорость блоковых коммитов blockchain, что снижает его полезность и ценность. Злонамеренная коалиция также может транслировать голоса небольшими порциями, поэтому при измельчении blockchain блок почти останавливается или вступает в любая комбинация этих атак. Наконец, это может привести к blockchain для разветвления путем двойной подписи или нарушения блокировки правила. Если бы в дело вмешался и глобально активный противник, он мог бы разделить сети таким образом, что может показаться, что это неправильный за замедление ответственно подмножество validators. Это не просто ограничение Tendermint, а скорее ограничение всех консенсусные протоколы, сеть которых потенциально контролируется активный противник. Для этих типов атак следует использовать подмножество validator. координировать действия с помощью внешних средств для подписания предложения о реорганизации, которое выбирает ответвление (и любые его доказательства) и начальное подмножество validators со своими подписями. Валидаторы, подписавшие такое предложение о реорганизации, отказываются от обеспечения на всех других форках. Клиенты должны проверить подписи на предложении о реорганизации, проверить любые доказательства, и вынести суждение или предложить конечному пользователю принять решение. Для Например, приложение телефонного кошелька может предложить пользователю ввести пароль безопасности.

предупреждение, а холодильник может принять любое предложение по реорганизации подписано +½ исходного числа validator по числу голосов. Никакой асинхронный византийский отказоустойчивый алгоритм не может прийти к консенсусу, когда ≥⅓ голосов нечестны, но это форк предполагает, что ≥⅓ голосов уже были нечестны двойное подписание или смена блокировки без обоснования. Итак, подписываем предложение о реорганизации представляет собой проблему координации, которую невозможно решить. решается любым несинхронным протоколом (т.е. автоматически, и не делая предположений о надежности базовая сеть). На данный момент мы оставляем проблему координации предложений по реорганизации на усмотрение человека посредством социального консенсуса. в интернет-СМИ. Валидаторы должны позаботиться о том, чтобы до подписания предложения о реорганизации не осталось никаких сетевых разделов, чтобы избежать ситуаций, когда подписываются два противоречивых предложения о реорганизации. Предполагая, что внешняя среда и протокол координации надежный, из этого следует, что форки вызывают меньшую озабоченность, чем цензура. атаки. Помимо форков и цензуры, требующей ≥⅓ византийского голосов, коалиция с числом голосов >⅔ может взять на себя обязательство произвольное, недействительное состояние. Это свойственно любому (BFT) система консенсуса. В отличие от двойной подписи, которая создает форки с помощью легко проверяемых доказательств, выявляющих совершение недействительное состояние требует, чтобы непроверяющие узлы проверяли целые блоки, что означает, что они сохраняют локальную копию состояния и выполняют каждой транзакции, вычисляя корень состояния независимо для себя. После обнаружения единственный способ справиться с таким сбоем происходит через социальный консенсус. Например, в ситуациях, когда Bitcoin не удалось, то ли форк из-за ошибок в программном обеспечении (как в марте 2013), или совершение недопустимого состояния из-за византийского поведения майнеры (как и в июле 2015 г.), сообщество с хорошими связями предприятия, разработчики, майнеры и другие организации установил социальный консенсус относительно того, какие ручные действия былинеобходимые участникам для исцеления сети. Кроме того, поскольку Можно ожидать, что validators Tendermint blockchain будут идентифицироваться, принятие недействительного состояния может даже быть наказуемо по закону или какой-либо внешней судебной практике, если это необходимо. ABCI состоит из трех основных типов сообщений, которые доставляются ядро приложения. Приложение отвечает соответствующие ответные сообщения. Сообщение  AppendTx  — это рабочая лошадка приложения. Каждый транзакция в blockchain доставляется с этим сообщением. приложению необходимо проверять каждую транзакцию, полученную с помощью Сообщение AppendTx о текущем состоянии, протоколе приложения, и криптографические учетные данные транзакции. проверенный затем транзакция должна обновить состояние приложения — путем привязка значения к хранилищу значений ключей или обновление UTXO база данных. Сообщение  CheckTx  похоже на AppendTx, но предназначено только для проверка транзакций. Ежегодные проверки мемпула Tendermint Core достоверность транзакции с CheckTx, действительны только реле транзакции со своими коллегами. Приложения могут проверять возрастающее nonce в транзакции и возвращает ошибку при CheckTx, если nonce старый. Сообщение  Commit  используется для вычисления криптографического обязательство по текущему состоянию приложения, которое будет помещено в заголовок следующего блока. У этого есть несколько полезных свойств. Несоответствия в обновлении этого состояния теперь будут отображаться как blockchain разветвляется, охватывая целый класс программирования ошибки. Это также упрощает разработку безопасных и легких клиентов, поскольку доказательства Merkle-hash можно проверить, проверив блок-hash и блок-hash подписаны кворумом из validators (по количеству голосов).

Дополнительные сообщения ABCI позволяют приложению отслеживать и измените набор validator, чтобы приложение получало информация о блоке, такая как высота и голоса за фиксацию. ABCI запросы/ответы — это простые сообщения Protobuf. Проверить из схемы yle. Аргументы: Данные ([]byte): байты транзакции запроса. Возврат: Код (uint32): код ответа. Данные ([]byte): байты результата, если таковые имеются. Журнал (строка): сообщение об отладке или ошибке. Использование:

Добавьте и запустите транзакцию. Если сделка действительна, возвращает КодТип.ОК Аргументы: Данные ([]byte): байты транзакции запроса. Возврат: Код (uint32): код ответа. Данные ([]byte): байты результата, если таковые имеются. Журнал (строка): сообщение об отладке или ошибке. Использование:

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

Возврат: Данные ([]байт): корень Меркла hash Журнал (строка): сообщение об отладке или ошибке. Использование:

Возвращает корень Merkle hash состояния приложения. Аргументы: Данные ([]byte): байты запроса запроса. Возврат: Код (uint32): код ответа. Данные ([]byte): байты ответа на запрос. Журнал (строка): сообщение об отладке или ошибке. Использование:

Очистить очередь ответов. Приложения, реализующие типы. Приложению не обязательно реализовывать это сообщение – оно обрабатывается проектом. Возврат: Данные ([]byte): информационные байты. Использование:

Возвращает информацию о состоянии приложения. Приложение специфический. Аргументы: Ключ (строка): ключ для установки.

Значение (строка): значение, которое нужно установить для ключа. Возврат: Журнал (строка): сообщение об отладке или ошибке. Использование:

Установите параметры приложения. Например. Key="mode", Value="mempool" для соединение с мемпулом или Key="mode", Value="consensus" для консенсусная связь. Другие параметры зависят от приложения. Аргументы: Валидаторы ([]Валидатор): Начальное происхождение — validators. Использование:

Вызванный однажды при зарождении Аргументы: Высота (uint64): высота блока, начиная с Использование:

Сигнализирует о начале нового блока. Вызывается перед любым AppendTxs. Аргументы: Высота (uint64): высота блока, который закончился. Возврат: Валидаторы ([]Validator): изменены validator на новые. право голоса (0 для удаления) Использование:

Сигнализирует об окончании блока. Вызывается перед каждым коммитом в конце концов транзакции Дополнительную информацию см. в репозитории ABCI.Существует несколько причин, по которым отправитель может захотеть подтверждение доставки пакета принимающей цепочкой. Например, отправитель может не знать статус сообщения. цепочка назначения, если ожидается, что она неисправна. Или отправитель может хотите установить для пакета тайм-аут (с помощью параметра MaxHeight  пакетный ответ), в то время как любая цепочка назначения может пострадать от атаки типа «отказ в обслуживании» с внезапным всплеском количества входящих пакетов. пакеты. В этих случаях отправитель может потребовать подтверждение доставки. установив первоначальный статус пакета на  AckPending . Тогда это ответственность принимающей сети за подтверждение доставки путем включения сокращенно IBCPacket  в приложении Merkle hash. Сначала IBCBlockCommit  и  IBCPacketTx  публикуются в «Hub». это доказывает существование IBCПакета  в «Зоне1». Скажи это  IBCPacketTx  имеет следующее значение: FromChainID: «Зона1» FromBlockHeight: 100 (скажем) Пакет: IBCПакет:

Заголовок: IBCPacketHeader: SrcChainID: «Зона1» DstChainID: «Зона2» Число: 200 (скажем) Статус: Подтверждено Тип: «монета» MaxHeight: 350 (скажем, «Hub» сейчас находится на высоте 300) Полезная нагрузка: <Байты полезной нагрузки «монеты»> Затем IBCBlockCommit и IBCPacketTx  публикуются в «Zone2». это доказывает существование IBCПакета  на «Хабе». Скажи это  IBCPacketTx  имеет следующее значение: FromChainID: «Хаб» ФромБлокХигхт: 300 Пакет: IBCПакет: Заголовок: IBCPacketHeader: SrcChainID: «Зона1» DstChainID: «Зона2» Количество : 200 Статус: Подтверждено Тип: «монета» Макс.Высота: 350 Полезная нагрузка: <Те же байты полезной нагрузки «монеты»> Далее «Зона2» должна включить в свое приложение-hash сокращенный пакет. который показывает новый статус  AckSent . IBCBlockCommit  и  IBCPacketTx  отправляются обратно на «Хаб», что доказывает существование сокращенного  IBCПакета  в "Zone2". Скажите, что IBCPacketTx  имеет следующее значение: FromChainID: «Зона2»

FromBlockHeight: 400 (скажем) Пакет: IBCПакет: Заголовок: IBCPacketHeader: SrcChainID: «Зона1» DstChainID: «Зона2» Количество : 200 Статус: Подтверждено Тип: «монета» Макс.Высота: 350 PayloadHash: Наконец, «Хаб» должен обновить статус пакета с  От AckPending до AckReceived. Доказательства этого нового статуса должен вернуться в «Зону2». Предположим, что IBCPacketTx  имеет следующее значение: FromChainID: «Хаб» ФромБлокХигхт: 301 Пакет: IBCПакет: Заголовок: IBCPacketHeader: SrcChainID: «Зона1» DstChainID: «Зона2» Количество : 200 Статус: Подтверждено Тип: «монета» Макс.Высота: 350 PayloadHash: Между тем, «Зона 1» может с оптимизмом предполагать успешную доставку. пакета «монет», если только не доказано обратное «Хаб». В приведенном выше примере, если «Хаб» не получил сообщение AckSent

статус из «Зоны2» в блоке 350, он бы установил статус автоматически на  Тайм-аут . Это свидетельство тайм-аута можно получить отправлено обратно в «Зону1», и любые token могут быть возвращены. В файле поддерживается два типа Merkle tree. Экосистема Tendermint/Cosmos: Простое дерево и IAVL+ Дерево. Простое дерево — это Merkle tree для статического списка элементов. Если количество предметов не является степенью двойки, некоторые листья будут находиться в разные уровни. Simple Tree пытается сохранить обе стороны дерева одинаковой высоты, но левая может быть на единицу больше. Это Merkle tree используется для Мерклеизации транзакций блока, а верхний уровень элементы корня состояния приложения.Целью структуры данных IAVL+ является обеспечение постоянного хранилище для пар ключ-значение в состоянии приложения, так что детерминированный корень Меркла hash может быть эффективно вычислен. дерево сбалансировано с использованием варианта алгоритма AVL, и все операции - O(log(n)). В дереве AVL высоты двух дочерних поддеревьев любого узла отличаются не более чем на единицу. Всякий раз, когда это условие нарушается обновлении, дерево перебалансируется путем создания новых узлов O(log(n)) указать на неизмененные узлы старого дерева. В оригинальном АВЛ алгоритме внутренние узлы также могут содержать пары ключ-значение. АВЛ+ алгоритм (обратите внимание на плюс) модифицирует алгоритм AVL, чтобы сохранить все значения на конечных узлах, используя только узлы ветвей для хранения ключей. Это упрощает алгоритм, сохраняя при этом след Меркла hash. короткий. Дерево AVL+ аналогично попыткам Патрисии Ethereum. Есть компромиссы. Ключи не требуется hash перед вставкой в Деревья IAVL+, что обеспечивает более быструю упорядоченную итерацию ключа. пространство, которое может принести пользу некоторым приложениям. Логика проще реализовать, требуя только два типа узлов – внутренние узлы и листовые узлы. Доказательство Меркла в среднем короче, поскольку                 *                 / \               /     \             /         \           /             \          *               *         / \             / \        /   \           /   \       /     \         /     \      *        *       *       h6     / \     / \     / \    h0  h1  h2  h3  h4  h5    Простое дерево с 7 элементами.

сбалансированное двоичное дерево. С другой стороны, корень Меркла Дерево IAVL+ зависит от порядка обновлений. Мы будем поддерживать дополнительные эффективные Merkle tree, такие как Патриция Три из Ethereum, когда бинарный вариант становится доступен. В канонической реализации транзакции передаются в Приложение-концентратор Cosmos через интерфейс ABCI. Хаб Cosmos примет ряд первичных транзакций. типы, включая  SendTx ,  BondTx ,  UnbondTx ,  ReportHackTx ,  SlashTx, BurnAtomTx, ProposalCreateTx и ProposalVoteTx, которые достаточно очевидны и будут задокументированы в будущая редакция этой статьи. Здесь мы документируем два основных типы транзакций для IBC:  IBCBlockCommitTx  и  IBCPacketTx . Транзакция  IBCBlockCommitTx  состоит из: ChainID (строка): идентификатор blockchain. BlockHash ([]byte): блок — hash байт, корень Меркла. который включает приложение-hash BlockPartsHeader (PartSetHeader): заголовок набора частей блока. байты, необходимы только для проверки подписей голосований BlockHeight (int): высота фиксации. BlockRound (int) : раунд фиксации. Commit ([]Vote): Предварительное принятие Tendermint >⅔ голосует за то, включать фиксацию блока ValidatorsHash ([]byte): корень дерева Меркла hash нового validator набор

ValidatorsHashProof (SimpleProof): SimpleTree Merkleproof для проверки ValidatorsHash на соответствие BlockHash. AppHash ([]byte): корень дерева Меркла IAVLTree hash состояние приложения AppHashProof (SimpleProof): SimpleTree, защищенный Мерклем для сравнение AppHash с BlockHash  IBCПакет  состоит из: Заголовок (IBCPacketHeader): заголовок пакета. Полезная нагрузка ([]byte): байты полезной нагрузки пакета. Необязательно PayloadHash ([]byte): hash для байтов пакета. Необязательно Должен присутствовать любой из  Payload  или  PayloadHash . hash пакета  IBCPacket       является простым корнем Меркла двух элементов:  Header  и  Полезная нагрузка . Пакет IBC без полной полезной нагрузки называется пакетом. сокращенный пакет. IBCPacketHeader  состоит из: SrcChainID (строка): идентификатор источника blockchain. DstChainID (строка): идентификатор пункта назначения blockchain. Номер (int): уникальный номер для всех пакетов. Статус (перечисление): может быть одним из AckPending, AckSent, AckReceived, NoAck или Timeout Тип (строка): типы зависят от приложения. Cosmos резервирует тип пакета «монета» MaxHeight (int): если статус не NoAckWanted или AckReceived. на этой высоте статус становится Timeout . Необязательно Транзакция  IBCPacketTx  состоит из:FromChainID (строка): идентификатор blockchain, который предоставление этого пакета; не обязательно источник FromBlockHeight (int) : высота blockchain, на которой следующий пакет включен (в формате Меркла) в блок - hash из исходная цепочка Пакет (IBCPacket): пакет данных, статус которого может быть одним из AckPending, AckSent, AckReceived, NoAck или Timeout PacketProof (IAVLProof): IAVLTree-доказательство Меркла для доказательства hash пакета по AppHash исходной цепочки по адресу заданная высота Последовательность отправки пакета из «Зоны1» в «Зону2» через «Хаб» изображен на {Рис. X}. Сначала IBCPacketTx  доказывает «Хабу», что пакет включен в app-состояние «Зона1». Затем другой IBCPacketTx  доказывает «Зоне2», что пакет включен в состояние приложения «Хаб». Во время этого процедуры, поля IBCPacket идентичны:  SrcChainID  всегда «Зона1», а  DstChainID — всегда «Зона2».  PacketProof  должен иметь правильный путь, защищенный Меркле, так как следует: Когда «Зона 1» хочет отправить пакет в «Зону 2» через «Хаб», Данные  IBCPacket  идентичны независимо от того, зарегистрирован ли пакет в «Зоне 1», «Хабе» или «Зоне 2». Единственный изменяемый Yeld - это  Статус для отслеживания доставки. Мы благодарим наших друзей и коллег за помощь в концептуализации, проверка и поддержка нашей работы с Tendermint и Cosmos. IBC///<Номер>

Заки Маниан из SkuChain оказал большую помощь в форматировании и формулировка, особенно в разделе ABCI Джехану Трембаку из Althea и Дастину Байингтону за помощь с начальные итерации Эндрю Миллер из Honey Badger за отзыв о консенсусе Грег Слепак за отзыв о консенсусе и формулировках Также спасибо Биллу Глейму и Сынхван Хану за различные взносы. Ваше имя и организация здесь за ваш вклад 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 ZeroCash: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 отдельных свидетелей: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 Сеть Lightning: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 Тендерминт: https://github.com/tendermint/tendermint/wiki 9 Невозможность ФЛП: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 Слэшер: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 BitShares: https://bitshares.org/technology/delegatedproof-of-stake-consensus/

13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 Интерледжер: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 сайдчейнов: https://blockstream.com/sidechains.pdf 16 Каспер: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum Шардинг: https://github.com/ethereum/EIPs/issues/53 19 ЛибСвифт: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnaлизOfLibswift.pdf 20 ДЛС: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 Безопасность тонкого клиента: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 Сиреневая бумага: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html

гл è