![caster-vs-tendermint caster-vs-tendermint](https://cryptocurrency.tech/wp-content/uploads/2018/01/caster-vs-tendermint-640x360.jpeg)
Tendermint
Общий обзор
Существуют различные способы реализации Proof-of-Stake-алгоритмов, но два основных вида дизайна Proof-of-Stake – это PoS на основе цепочки и PoS на основе устойчивого к византийской ошибке (BFT) консенсуса. Tendermint является примером PoS на основе BFT-консенсуса, Casper the Friendly Ghost – PoS на основе цепочки, а Casper the Friendly Finality Gadget представляет собой гибрид из этих двух подходов.
В теореме CAP из области компьютерных наук утверждается невозможность предоставления в распределённых системах данных более чем 2 из 3 следующих гарантий: доступности, корректности и устойчивости к разделению. При создании PoS-алгоритмов на основе цепочки предпочтение, как правило, отдаётся доступности данных перед их корректностью, где обеспечение доступности подразумевает обработку всех транзакций, но в ущерб согласованному воспроизведению состояний во всей сети. С другой стороны, в PoS-алгоритмах на основе BFT-консенсуса выбор делается строго в пользу корректности данных, в ущерб их доступности.
Proof-of-Stake на основе устойчивого к византийской ошибке консенсуса
Устойчивые к византийской ошибке (BFT) алгоритмы консенсуса основываются на огромном пласте исследований, охватывающем более 30 лет. Tendermint (2014) – это первая адаптация Proof-of-Stake-консенсуса, основанного на алгоритме Practical Byzantine Fault Tolerant (PBFT), представленном Кастро и Лисковым в 1999 году. PoS-протоколы, основанные на BFT-консенсусе, псевдослучайным образом присваивают валидатору право предложения новых блоков в процессе многоэтапного голосования. Однако завершение и финализация блоков зависит от квалифицированного большинства – более ⅔ кворума — всех валидаторов, утвердивших предложенный блок. Процесс финализации блоков может занимать несколько раундов. BFT-системы не могут справиться с более чем ⅓ ошибок, которые могут включать в себя также произвольное или злонамеренное поведение.
Ядро Tendermint
Tendermint состоит из двух основных технических компонентов: механизма консенсуса блокчейна и интерфейса универсального приложения. Механизм консенсуса, называемый ядром Tendermint, гарантирует, что на каждой машине те же транзакции записываются в том же порядке. Интерфейс, называемый блокчейн-интерфейсом приложения (Application Blockchain Interface, ABCI), позволяет обрабатывать транзакции на любом языке программирования.
На уровне ядра Tendermint функционирует как механизм голосования на основе раундов, позволяющий реализовать протокол консенсуса. Раунд разбивается на три этапа, в которых валидаторы предлагают блоки, сигнализируют о намерении их финализировать, а затем подписывают их для финализации новых блоков. Этот механизм обеспечивает защищённую машину репликации состояний для атомарной сети с добавленным слоем ответственности (сбои в системе безопасности в полной мере свойственны Tendermint).
Алгоритм консенсуса Tendermint начинается с валидаторов. Валидаторы хранят полную копию блокчейна и идентифицируются по своим публичным ключам. Они поочерёдно предлагают блоки на каждой новой высоте. В каждом раунде для голосования выставляется не более одного предложения. Каждое предложение подписывается секретным ключом соответствующего валидатора, чтобы в случае возникновения ошибки ответственного за это предложение валидатора можно было идентифицировать. Остальные валидаторы голосуют по каждому предложению, подписывая решение своими секретными ключами. Эта последовательность действий составляет один раунд. Однако из-за асинхронности сети для финализации блока может потребоваться несколько раундов.
Раунд голосования с изображением цикла частично синхронных предложений с последующим асинхронным голосованием. Отправив предложение, валидаторы получают возможность переходить к следующему шагу только после получения согласия ⅔ или более других валидаторов. Пунктирная стрелка показывает расширение консенсуса в атомическую сеть с переходом на следующую высоту блока.
Валидаторы могут не суметь финализировать блок по множеству произвольных причин: например, автор текущего предложения может оказаться офлайн, или могут случиться задержки в работе сети. В Tendermint есть возможность пропуска валидатора. Другие валидаторы в течение некоторого непродолжительного времени ждут получения полного предлагаемого блока, после чего голосуют за переход к следующему раунду. Эта зависимость от таймаутов и есть то, что делает Tendermint слабо синхронным, а не асинхронным, протоколом. Тем не менее остальная часть протокола является асинхронной, и валидаторы получают возможность переходить к следующему шагу только после получения согласия от более чем ⅔ всех валидаторов. Таким образом, для работы Tendermint требуется, чтобы квалифицированное большинство валидаторов было доступно 100% времени, потому что если ⅓ или более валидаторов находятся офлайн или не подключены к сети, то работа сети может остановиться.
При том допущении, что менее ⅓ валидаторов являются византийцами, Tendermint гарантирует, что его безопасность никогда не будет нарушена — то есть валидаторы никогда не будут создавать конфликтующие блоки на одной высоте. По этой причине в блокчейнах, основанных на Tendermint, не бывает форков.
В дизайне Tendermint предпочтение пока что отдаётся безопасности и окончательности перед жизнеспособностью. Существует довольно высокая вероятность того, что в реальном мире работа системы остановится, и участникам придётся организовываться вне протокола, чтобы каким-то образом обновить программное обеспечение для перезапуска системы.
Tendermint сформировал основу для исследования Casper, когда ещё очень немногие в криптовалютном сообществе понимали, какой вывод можно сделать из этого опыта и в чём заключалась ценность этого вывода. Аналитический вывод был следующим: если сама цепочка обладает высокой отказоустойчивостью, то можно положиться на цепочку, чтобы принимать правильные решения о том, кто может создавать блоки. Если же цепочка сама по себе менее надёжна, то в итоге вы придёте к проблеме курицы и яйца, которая погубила все более ранние алгоритмы консенсуса.
Это решение дизайна протокола воспринимается как уступающее протоколам, в которых приоритет отдаётся доступности, таким как Ethereum или Биткойн. Компромисс Биткойна выглядит следующим образом: если в его сети возникает двое и более ведущих, Биткойн утрачивает все свои гарантии безопасности при различных сценариях атаки. Это общая тема окончательности, которая заключается в том, что, если ваш доверительный интервал составляет менее 100%, то цепочка, которой вы следуете, является правильной, и вы используете её, чтобы выбрать, кто будет создавать следующий блок. Значит, если вы перейдёте на небезопасную цепочку, то ясного пути возврата к правильной цепочке уже не будет.
Краткий перечень свойств
- Доказуемая жизнеспособность.
- Порог безопасности: ⅓ валидаторов.
- Совместимость с публичными и частными блокчейнами.
- Мгновенная финализация блоков: 1–3 секунды, в зависимости от количества валидаторов.
- Приоритет корректности данных.
- Безопасность консенсуса в слабо синхронной сети.
(Продолжение следует.)
Будь в курсе! Подписывайся на Криптовалюта.Tech в Telegram!