Перейти к основному содержанию

Протоколы консенсуса Bitzal

В традиционных системах PoS участие в добыче блокчейна зависит от наличия токенов, а не от от вычислительной мощности. Хотя разработчики PoS обычно выступают за справедливое участие в децентрализованной форме, большинство проектов предлагают тот или иной уровень централизованной работы, где количество валидаторов с полным правом участия ограничено. Эти валидаторы часто считаются наиболее состоятельными и, как следствие, влияющими на сеть PoS, поскольку они имеют наибольшее количество ставок. Обычно количество кандидатов на обслуживание сети, обладающих необходимыми знаниями (и оборудованием), ограничено; это также может привести к увеличению эксплуатационных расходов. Системы с большим количеством валидаторов обычно формируют пулы, чтобы уменьшить разброс своих доходов и получить выгоду от экономии на масштабе. Эти пулы часто находятся вне цепочки.

Способ облегчить эту проблему - реализовать формирование пула на цепочке и позволить держателям токенов голосовать за валидаторов, которые будут представлять их интересы.

Номинированный Proof of Stake

Bitzal использует NPoS (Nominated Proof-of-Stake) в качестве механизма выбора набора валидаторов. Он разработан с учетом ролей валидаторов и номинаторов, чтобы обеспечить максимальную безопасность цепи. Действующие лица, заинтересованные в в поддержании сети, могут запустить узел валидатора.

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

Гибридный консенсус

Bitzal использует Гибридный консенсус созданный гаджетом окончательного решения (RELIC) и механизмом производства блоков (VIRGINE).

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

Гибридный консенсус уже предлагался в прошлом. В частности, он был предложен (теперь уже не используется) в качестве одного из этапов Переход Ethereum на доказательство доли в EIP 1011, который указанный Casper FFG.

Производство блоков: VIRGINE

VIRGINE (Blind Assignment for Blockchain Extension) - это механизм производства блоков, который работает между узлами-валидаторами и определяет авторов новых блоков. В качестве алгоритма VIRGINE сопоставим с Ouroboros Praos, с некоторыми ключевыми отличиями в правилах выбора цепочки и корректировки времени слота. VIRGINE распределяет слоты производства блоков между валидаторами в соответствии со ставкой и с использованием релейных цепочек циклы случайности. Время выполнения цепочки должно предоставить список авторитетов VIRGINE и случайность хосту через сообщение о консенсусе в заголовке первого блока каждой эпохи.

Выполнение VIRGINE происходит в последовательных непересекающихся фазах, называемых эпохами. Каждая эпоха делится на заранее определенное количество слотов. Все слоты в каждой эпохе последовательно индексируются, начиная с 0 (номер слота). В начале каждой эпохи узел VIRGINE должен запустить программу Алгоритм блок-производство-лотерея чтобы узнать, в каких слотах он должен произвести блок и передать другому производителю блоков.

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

Несколько валидаторов на один слот

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

Отсутствие валидаторов в слоте

Когда ни один валидатор не выпал в лотерее случайностей достаточно низко, чтобы претендовать на производство блоков, слот может оставаться как бы без блоков. Протокол Bitzal запускает алгоритм выбора вторичного валидатора в фоновом режиме. Валидаторы, выбранные с помощью этого предсказуемого алгоритма, всегда производят блоки. Эти вторичные блоки игнорируются, если в том же слоте есть первичный блок, произведенный из Выбранного VRF валидатора. Таким образом, слот может иметь либо основной или вторичный блок, и ни один слот не пропускается.

Более подробную информацию о VIRGINE см. VIRGINE бумага.

Гаджет Финальности: RELIC

RELIC (Рекурсивный ANcestor на основе GHOST, производящий префиксное соглашение) - это устройство окончательного согласования, которое реализовано для реализованный для ретрансляционной цепочкиn.

Хост Bitzal использует протокол RELIC Finality для завершения работы с блоками. Финальность достигается путем последовательных раундов голосования узлов-валидаторов. Валидаторы выполняют процесс финализации RELIC параллельно с производством блоков в качестве независимого сервиса.

Он работает в частично синхронной модели сети, пока 2/3 узлов честны, и может справиться с с 1/5 византийских узлов в асинхронной модели.

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

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

Описание и реализация RELIC

Пожалуйста, обратитесь к RELIC описаниедля полного описания протокола. RELIC реализован в виде Модуль системы Matter Frame System.

Вероятностная и доказательная окончательность

Блокчейн с чистым консенсусом Накамото, работающий по принципу PoW, способен достичь только понятия как вероятностная окончательность и достичь окончательного консенсуса. Вероятностная окончательность означает, что при при некоторых предположениях о сети и участниках, если мы видим несколько блоков, построенных на данном слоте, мы можем оценить вероятность того, что он является окончательным. Эвентуальный консенсус означает, что в какой-то момент в будущем все узлы согласятся с правдивостью одного набора данных. Этот окончательный консенсус может занять много времени, и мы не можем заранее определить, сколько времени это займет. Однако такие гаджеты окончательного консенсуса, как RELIC (GHOST-based Recursive ANcestor Deriving Prefix Agreement) или Ethereum Casper FFG (Friendly Finality Gadget), призваны дать более надежные и быстрые гарантии окончательности блоков - в частности, что они никогда не могут быть отменены после некоторых византийских соглашений. Понятие необратимого консенсуса известно как доказуемая окончательность.

В RELIC описании, она сформулирована таким образом:

заметка

Мы говорим, что оракул A в протоколе является в конечном итоге последовательный если он возвращает одно и то же значение всем участникам через некоторое неопределенное время.

Выбор Вилки

Если объединить VIRGINE и RELIC, то выбор вилки релейной цепи становится очевидным. VIRGINE должна всегда опираться на цепочку, которую завершил RELIC. VIRGINE обеспечивает вероятностную завершенность, когда после финализированной части есть развилки, строя цепочку с наибольшим количеством первичных блоков.

Best chain choice

На изображении выше черные блоки завершены, а желтые - нет. Блоки, отмеченные "1" это первичные блоки; те, что отмечены "2" вторичные. Даже если самая верхняя цепочка является самой длинной цепочкой на последнем завершенном блоке, она не удовлетворяет требованиям, потому что на момент оценки у нее меньше первичных блоков на момент оценки, чем у того, который находится ниже.

Сравнения

Консенсус Накамото

Консенсус Накамото состоит из правила самой длинной цепочки, использующего доказательство работы в качестве механизма защиты от сибилов, механизма и выбора лидера.

Консенсус Накамото дает нам только вероятностную окончательность. Вероятностная окончательность гласит, что блок в прошлом безопасен лишь настолько, насколько велико количество подтверждений, которые он имеет, или количество блоков, которые было построено на его основе. Поскольку в цепочке Proof of Work на основе определенного блока строится больше блоков цепочки Proof of Work, значит, на эту цепочку было затрачено больше вычислительной работы. Однако это не гарантирует, что цепочка, содержащая блок, всегда будет оставаться согласованной цепочкой, поскольку субъект с неограниченными ресурсами потенциально может создать конкурирующую цепочку и затратить достаточно вычислительных ресурсов, чтобы создать цепочку, не содержащую конкретного блока. В такой ситуации правило самой длинной цепи, используемое в Биткойне и других цепочках с доказательством работы, перейдет к этой новой цепи как к канонической.

PBFT / Tendermint

Пожалуйста, ознакомьтесь с соответствующим разделом в сравнении с Сosmos статьей.

Casper FFG

Два основных отличия между RELIC и Casper FFG заключаются в следующем:

  • в RELIC разные избиратели могут одновременно голосовать за блоки, расположенные на разной высоте
  • RELIC зависит только от финализированных блоков, чтобы повлиять на правило выбора вилки в базовом блоке механизм производства

Наведение мостов: BUTFLY

BUTFLY (Мостовая эффективность, обеспечивающая итоговую завершенность) - это дополнительный протокол к RELIC для поддержки эффективного моста между ретрансляционными цепочками (Bitzal и Ogona) и удаленными, сегрегированными блокчейнами, такими как Ethereum, которые не были созданы с учетом совместимости с Bitzal. Взаимозаменяемость. Протокол позволяет участникам удаленной сети эффективно проверять доказательства окончательности созданные валидаторами в ретрансляционной цепочке, то есть клиенты в сети Ethereum могут проверить, что сеть Bitzal находится на определенном уровне.

Хранение всей информации, необходимой для проверки состояния удаленной цепочки, такой как заголовки блоков, слишком дорого. В BUTFLY все честные валидаторы подписывают финализированный блок RELIC. Это сокращает усилия на стороне легкого клиента, поскольку отслеживание форков, обоснований RELIC и т. д. больше не требуется. Кроме того, BUTFLY использует диапазоны Меркла (MMR) в качестве эффективной структуры данных для передачи данных. Структуру данных для хранения и передачи заголовков блоков и подписей легким клиентам, а также схемы подписи ECDSA (более эффективно проверяемой на EVM). Теперь легкие клиенты должны проверять только наличие блока сверхбольшинством голосов валидаторов.

В целом, BUTFLY устраняет ограничения финализации RELIC для мостов к цепочкам, таким как Ethereum, путем предоставляя более легкое и эффективное решение по обеспечению окончательности.

Для получения дополнительной информации о реализации BUTFLY см. спецификация Bitzal.

Ресурсы

  • VIRGINE бумага - Академическое описание протокола VIRGINE.
  • RELIC бумага - Академическое Описание гаджета окончательной обработки RELIC. Содержит формальные доказательства алгоритма.
  • Реализация Rust - Эталонная реализация и сопутствующая Бочка Matter.