Су Зе

Всем привет Это Су Зе Back-end разработчик, который любит технологию блокчейна.

Этот столбец ←Я продолжаю записывать свои конспекты по изучению смарт-контрактов и подводить итоги двух лет самостоятельного обучения и многочисленных обходных путей. Если вам это нравится, пожалуйста, поддержите меня ~

В предыдущих статьях этой рубрики подробно были представлены основные базовые знания о блокчейне. иметь Друзья, которые заинтересованы в обучении, могут посмотреть→http://t.csdnimg.cn/CstOy Наиболее доступно объяснены базовый состав и принципы шифрования блокчейна. Надеюсь, это поможет всем научиться

Ниже приводится текст

Оглавление

В предыдущих статьях этой рубрики подробно представлены основные базовые знания о блокчейне. Друзья, которые заинтересованы в обучении, могут ознакомиться с ними → http://t.csdnimg.cn/CstOy. Что касается базового состава и принципов шифрования блокчейна, мы рассказываем об этом. используйте самые базовые знания. Я объяснил это простым для понимания языком и надеюсь, что это поможет каждому научиться.

Ниже приводится текст

механизм консенсуса

Понимание практического византийского механизма отказоустойчивости

RBFT

Алгоритм RBFT обычно включает в себя следующие этапы: просмотр изменения, предложение, проверка и голосование и решение.

Конечно, существует много разных алгоритмов. Лучшего алгоритма в мире не существует, есть только относительно оптимальные решения в разных сценариях.

Часто используемый механизм консенсусаиметьPoW(Proof of Работа) доказательство рабочей нагрузки, PoS (доказательство) of Доля) Доказательство справедливости, DPoS (Делегированный Proof of Доказательство делегированного капитала, DBFT (Делегированный Byzantine Fault толерантность) и т.д.

EOS

Прежде чем изучать EOS, давайте сначала поговорим о DPOS.

В рамках механизма EOS узлы транслируются целевым образом. Расположение 21 узла прозрачно, и для указания порядка трансляции будет выбран кратчайший путь. Как показано на рисунке:

DBFT

консенсусная терминология

консенсусное сообщение

процесс консенсуса

три этапапроцесс консенсуса

Условно его можно разделить на несколько этапов:

механизм консенсуса

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

• Византийская отказоустойчивость : Византийская отказоустойчивость подчеркивает способность мириться с непредсказуемым поведением некоторых узлов Блокчейн из-за аппаратных ошибок, перегрузки или отключения сети, а также злонамеренных атак. Метод серии BFT представляет собой типичную византийскую отказоустойчивостьалгоритм,Такие как PBFT, HotStuff и т. д.
• Нет Византийская отказоустойчивость : Нет Византийская Под отказоустойчивостью обычно понимается способность допускать ошибки простоя на некоторых узлах Блокчейн, но не допускать сбоев системы, вызванных непредсказуемым вредоносным поведением. Общие консенсусы по CFT включают Paxos, Raft и т. д.

Понимание практического византийского механизма отказоустойчивости

Мы используем пример, чтобы проиллюстрировать этот механизм.

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

Большинство платформ используют Адаптивный механизм консенсуса , поддерживает несколько алгоритмов консенсуса, таких как RBFT, NoxBFT (тип BFT) и RAFT (тип CFT), для удовлетворения потребностей различных бизнес-сценариев. Далее в основном будут представлены алгоритмы консенсуса, такие как RBFT, NoxBFT и RAFT.

Здесь мы объясним один из них - RBFT.

RBFT

RBFT (Redundant Byzantine Fault Tolerance) — это византийский отказоустойчивый алгоритм, который повышает отказоустойчивую производительность системы за счет добавления резервных узлов. В алгоритме RBFT узлы в системе делятся на две категории: основной узел (Primary) и резервный узел (Backup). Главный узел отвечает за принятие решений и передачу их другим узлам, в то время как резервный узел используется для обеспечения отказоустойчивости, чтобы обеспечить нормальную работу системы, даже если главный узел допускает ошибки или вредоносное поведение.

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

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

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

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

Алгоритм RBFT обычно включает в себя следующие этапы: просмотр изменения, предложение, проверка и голосование и решение.

1. видвыключатель（View Изменение): В существующем алгоритме RBFT главный узел может вести себя неправильно или злонамеренно. Чтобы справиться с этой ситуацией, резервное Узел копирования может выбрать новый главный узел с помощью механизма переключения вида. В каждом виде узел может выбрать новый мастер-узел по заранее согласованным правилам. Цель этого этапа — обеспечить корректность и надежность работы мастер-узла.

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

2. Предложение решения (Предложение): В существующем алгоритме RBFT главный узел отвечает за предложение решений. Главный узел предложит решение об атаке или отступлении на основе определенных правил и условий и отправит его другим узлам. В нашем примере вновь избранный главный генерал предложит решение атаковать или отступить и отправит его другому резервному генералу. копированиеобщий
3. Проверка и голосование and Voting）：резервное После того, как узел копирования существует, получит предложение по принятию решения от главного узла, он проверит его. Ноды проверяют законность и правильность решений и сравнивают их с другими нодами. Если большинство узлов согласятся с решением, они проголосуют за это решение. существовать Пример,резервное Генерал-копировщик проверит решение главного генерала и свяжется с другим резервным. общая копия для сравнения. Если самое резервное Генералы копирования подтвердили то же решение и проголосовали за него.
4. Решение: Когда большинство узлов проголосуют за одно и то же решение, система достигнет консенсуса и выполнит решение. Правильные решения будут сообщены солдатам, чтобы они могли выполнить соответствующие действия. существуют примеры, когда наиболее резервное копированиеобщийдостичь соглашения,и проголосовать за то же решение,Решение будет доведено до сведения солдат.,чтобы они могли совершать наступательные или отступающие действия.

Благодаря сочетанию этих этапов алгоритм RBFT способен выдерживать ошибки или вредоносное поведение главных узлов и достигать консенсуса посредством голосования большинством. Этот механизм повышает отказоустойчивость и безопасность системы.

Конечно, существует много разных алгоритмов и лучшего алгоритма в мире не существует. Толькоиметьпо разным сценариямотносительнооптимальное решение

Часто используемый механизм консенсусаиметьPoW(Proof of Work)доказательство работы,PoS(Proof of Stake)Доказательство доли,DPoS(Delegated Proof of Stakeназначать Доказательство доли,DBFT(Delegated Byzantine Fault Tolerance)ждать。

EOS

Делегированное доказательство справедливости используется для выбора некоторых репрезентативных узлов для голосования. Этот метод направлен на оптимизацию эффективности и результатов голосования сообщества, но он несет в себе некоторые риски централизации.

Прежде чем изучать EOS, давайте сначала поговорим о DPOS.

Предположим, что в примере с генералами у нас есть три узла, представляющие генерала A, генерала B и генерала C соответственно. Теперь применим этот пример к вышеупомянутой ситуации.

Предположим, что первым генералом, создавшим блок, является A, затем B и, наконец, C. Теперь General B решает сделать форк. Когда наступает очередь генерала Б строить блок, он больше не распознает блоки генерала С и генерала А, а строит блок в одиночку. В этом случае цепочка, разветвленная B, может создавать блок только каждые 9 секунд, в то время как C и A могут создавать блок каждые 6 секунд. В соответствии с механизмом DPOS, даже если он разветвляется, B все равно нужно дождаться, пока A и C создадут блоки, прежде чем он сможет продолжать создавать блоки. Поэтому скорость раздвоенных блоков никогда не сможет сравняться со скоростью исходной цепи, поскольку механизм консенсуса распознает только самую длинную цепочку. Это означает, что в случае разветвления небольшим количеством узлов раздвоенный узел не может расти быстрее, чем цепь, распознаваемая другими узлами. Если две трети узлов решают разветвиться, принцип тот же. Несколько последних честных узлов определяют самую быструю и длинную цепочку. Раздвоенные узлы не могут успевать за ростом цепочки, поддерживаемой другими узлами. существоватьDPOSмеханизм В консенсусе определение самой длинной цепочки достигается за счет концепции «последнего необратимого блока». Последний необратимый блок — это последний блок, который нельзя изменить. Согласно правилам DPOS, когда две трети узлов подтверждают блокировку, она становится необратимой. Если две трети узлов, создавших последний блок, подтверждают блокировку, то это последний необратимый блок. С помощью последнего необратимого блока вы можете подтвердить, является ли эта цепочка самой длинной цепочкой, подписанной двумя третями узлов. Таким образом, механизм DPOS может эффективно предотвращать византийское зло и обладает высокой византийской отказоустойчивостью. В этом примере перечислены только несколько серьезных злых ситуаций, а механизм DPOS может предотвратить множество других злых ситуаций, которые здесь не перечислены. Кроме того, транзакции как доказательство доли (TaPOS) относятся к транзакциям как к подтверждению данных, подтверждающих предыдущий блок. Когда количество блоков увеличивается, эту цепочку сложно заменить, поскольку изменение блока приведет к несовпадению всех значений TaPOS. В механизме DPOS EOS направленная трансляция используется для повышения скорости и производительности генерации блоков. В таких системах, как BitShares и STEEM, трансляция является случайной, и тот, кто первым получит блок, может передать его для генерации новых блоков. Однако EOS использует направленную трансляцию, что делает распространение блоков более эффективным. Этот механизм позволяет EOS достигать более высоких скоростей генерации блоков (например, 500 миллисекунд).

Как упоминалось выше, скорость генерации блоков BitShares составляет 3 с, тогда как EOS может достигать 500 мс. EOS может увеличить скорость производства блоков благодаря прямой трансляции.

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

В рамках механизма EOS узлы транслируются целевым образом. Расположение 21 узла прозрачно, и для указания порядка трансляции будет выбран кратчайший путь. Как показано на рисунке:

DBFT

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

NEO предложил алгоритм консенсуса dBFT (делегированная византийская отказоустойчивость, делегированная византийская отказоустойчивость), основанный на алгоритме PBFT (практическая византийская отказоустойчивость). Алгоритм определяет узлы, которые будут участвовать в следующем раунде консенсуса, на основе результатов голосования блокчейна в реальном времени, эффективно сокращая затраты времени алгоритма, тем самым увеличивая скорость генерации блоков и сокращая цикл подтверждения транзакции.

консенсусная терминология

консенсусное сообщение

dBFT 2.0 Алгоритм содержит 6 добрыйконсенсусное сообщение：

процесс консенсуса

три этапапроцесс консенсуса

Сейчас мы можем использовать общий пример, чтобы объяснить эти четыре шага.

Предположим, у нас есть три генерала A, B и C, и они проводят раунд консенсуса.

1. оратор инициирует консенсус, транслировать Prepare Запрос (подготовить запрос):
   • существовать На этом этапе,Генерал А был выбран оратором.,и отправьте запрос на подготовку,заявил, что готов начать процесс консенсуса.
   • Генерал А передает этот запрос на подготовку двум другим генералам B и C.
2. полученный Prepare Request назад,член парламентатранслировать Prepare Ответ (подготовить ответ):
   • Генерал Б и Генерал С получены после запроса на подготовку Генерала А.,Они соответственно транслируют свои заранее подготовленные ответы.
   • Эти подготовленные ответы указывают на то, что генерал Б и генерал С согласны участвовать в процессе достижения консенсуса.
3. достаточно добытый Prepare Response назад,Консенсусный узелтранслировать Совершить:
   • Как только генерал А получает достаточно ответов о подготовке (например, ответы о подготовке от B и C), он передает сообщение о фиксации.
   • Это сообщение о фиксации означает, что генерал А подтверждает, что консенсус достигнут, и готов перейти к следующему шагу.
4. достаточно добытый Commit назад,Консенсусный узел генерирует новые блоки и транслирует:
   • Как только генерал A получает достаточно сообщений о фиксации (например, от B и C), он начинает генерировать новые блоки.
   • Новый сгенерированный блок содержит данные консенсуса и передается Генералом А другим узлам, чтобы они могли обновить свои цепочки.

Условно его можно разделить на несколько этапов:

1. Инициализируйте информацию о локальном консенсусе и сбросьте контекст консенсуса:
   • Этот шаг аналогичен инициализации генералов и подготовке к новому раунду битвы. Они определяют, кто будет подавать, и устанавливают тайм-аут.
2. каждый Консенсусный узел контролирует сеть до истечения времени ожидания, собирает информацию о транзакции:
   • Этот шаг аналогичен тому, как генералы собирают разведывательную информацию о боевой обстановке и передвижениях противника до истечения тайм-аута.
3. Инициировать консенсус:
   • существования. На этом этапе оратор выбирает транзакции из пула памяти в соответствии со стратегией консенсуса и упаковывает их в запросы на подготовку (Prepare Запрос), а затем транслировать его, что эквивалентно тому, что генералы начинают новый раунд битвы.
4. транслировать Prepare Response：
   • На этом этапе член После получения запроса о подготовке от оратор парламента проверит и подготовит ответ (Подготовьте Response) транслировать go out, что равносильно реагированию на приказы генералов вероратор.
5. собирать Prepare Response & транслировать Commit：
   • На этом этапе оратор и полученный готовят запрошенных членов. После того, как генералы получат достаточно ответов, они проверяют и отправляют сообщение (Commit), что эквивалентно решению генералов выполнить план сражения после получения достаточного количества ответов.
6. собирать Commit информация & Из блоков:
   • На этом этапе сбор данных подготовлен для запроса информации о транзакции Консенсусного После того, как узелсобирать получает достаточное количество сообщений фиксации, он проверяется и генерируется новый блок, а затем выходит транслировать. Это эквивалентно тому, что генералы выполняют действия согласно плану боя и побеждают.
7. Вернуться в главу 1 Шаг, начните следующий раунд консенсуса:
   • На этом этапе, после завершения процесса консенсуса, начинается подготовка к новому раунду консенсуса, что эквивалентно завершению генералами одного раунда битвы и подготовке к переходу в следующий раунд.

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