Начнем

Для начала важно понимать, что существует несколько основных школ построения POS консенсуса:

Nakamoto-inspired (Peercoin, NXT, Ouroboros…)
PBFT-inspired (Tendermint, Casper FFG, Hotstuff…)
CBC Casper

Это очень большая и интересная тема для изучения, но мы сейчас не будем ее полностью разбирать, но разберем CBC Casper, ведь именно данная школа использована в основе POS алгоритма в Eth2.0

Философия дизайна Casper CBC

Correct-By-Construction

Фундаментальная философия проектирования, лежащая в основе Correct-By-Construction, заключается в том, чтобы сначала построить очень абстрактную, но надежную структуру и предоставить доказательства фундаментально важных свойств, которые гарантирует структура. Затем мы постепенно определяем структуру и наследуем все предыдущие доказательства и гарантии. Используя этот итеративный подход «определить-доказать-наследовать», мы создаем семейство протоколов, которые удовлетворяют одним и тем же доказательствам и обеспечивают одинаковые гарантии на высоком уровне, но при этом могут быть определены как достаточно специализированные для практического использования

Это называется correct-by-construction, потому что правильность новых протоколов гарантируется их построением, которое заключается в постепенном определении абстрактного (и доказуемо правильного) протокола в дальнейшем

Distributed Systems Approach

Casper CBC подходит к проблеме консенсуса Proof-of-Stake как к проблеме распределенных систем. В отличие от других механизмов консенсуса Proof-of-Stake, мы не определяем криптоэкономические методы, такие как депозиты и условия слэшинга, в нашем механизме консенсуса! Однако протокол, который мы определяем, является достаточно общим, чтобы определить эти вещи позже

Концепция ошибок в распределенных системах важна для консенсуса Casper CBC. Раздел 1.1 проекта описывает классификацию различных типов ошибок, которые могут возникнуть. Самый интересный тип ошибки (и единственный вид, который может привести к нарушению безопасности консенсуса) называется ошибкой двусмысленности. Мы рассмотрим этот тип ошибок позже, когда будем обсуждать правила консенсуса

Суть механизма консенсуса заключается в том, что «все будет хорошо, пока будет достаточно мало ошибок». Это можно сформулировать так: «только при достаточно большом количестве ошибок что-то пойдет не так»

Casper CBC Consensus Mechanism

Познакомимся с терминологией:

Валидаторы (Validators): ноды, формирующие консенсус, в сети называются валидаторами
Сообщения (Messages): сообщения генерируются и передаются валидаторами в попытке достичь консенсуса

Messages

Сообщения — это фрагменты информации, генерируемые и передаваемые валидаторами в процессе формирования консенсуса. В механизме консенсуса Casper CBC сообщения имеют следующую структуру:

Разберем структуру сообщения:

Value: это элемент, по которому валидатор предлагает сети прийти к консенсусу. Это значение должны быть из набора согласованных значений. Если мы строим целочисленный алгоритм консенсуса, то значения консенсуса будут целыми числами. Если мы строим алгоритм консенсуса блокчейна, то эти значения консенсуса будут блоками
Validator: это валидатор, который генерирует сообщение
Justification: это набор сообщений, которые валидатор просмотрел и подтвердил при создании этого конкретного сообщения. Как мы увидим позже, обоснование должно «оправдать» предложенное значение

Прежде чем мы обсудим правила, определяющие ограничения на сообщения, давайте рассмотрим две важные концепции:

Более поздние сообщения: если сообщение А находится в justification сообщения Б, то сообщение Б является более поздним, чем сообщение А
Estimator Function: функция оценки принимает обоснование(justification) (которое представляет собой набор сообщений) в качестве входных данных и возвращает набор согласованных значений, которые «обоснованы» входными данными. Например, при целочисленном консенсусе оценщик будет возвращать целочисленные значения. В условиях блокчейна оценщик вернет блоки, которые можно добавить поверх текущей цупочки

Consensus Rules

Эти правила классифицируют два типа ошибок: ошибка неверного сообщения (1) и ошибка двусмысленности (2)

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

Violation of Consensus Rules (Нарушение правил консенсуса)

Ошибка недопустимого сообщения (1) : нарушение этого правила приводит к тому, что сообщение становится недействительным и может быть обнаружено всеми, кто получает это сообщение. Для этого получатель запускает Estimator Function и проверяет, находится ли предлагаемое значение в наборе значений, возвращаемых оценщиком. Все сообщения, которые не нарушают это правило, являются действительными сообщениями
Equivocation Faults (2) : Нарушение второго правила не может быть обнаружено кем-либо, кто получает только одно из двух сообщений, нарушающих это правило. Это нарушение является разновидностью византийской неудачи, которую мы называем двусмысленностью. В оставшейся части этого поста я буду называть нарушение этого правила ошибками

Когда нода сомневается, она в основном выполняет несколько отдельных экземпляров протокола и может попытаться показать сообщения из одного экземпляра этих исполнений отдельным нодам в сети. Чтобы уточнить, что такое отдельные экземпляры протокола - рассмотрим валидатора, который нарушает правило консенсуса 2, создавая сообщения A и B, нарушающие правило. Затем валидатор начинает поддерживать две истории выполнения протокола, в одной из которых генерируется только сообщение A, а в другой — только сообщение B. В каждой отдельной версии выполнения протокола валидатор не сомневался

Например, на приведенном выше рисунке нода начинает выполнение протокола в состоянии A и продолжает однократное выполнение протокола до состояния B. Пиры в зеленом (левом) кружке и синем (правом) круге могут видеть, что нода следует одному выполнению протокола из состояния A в состояние B, наблюдая за сообщениями, которые он отправляет. Затем нода начинает поддерживать два отдельных экземпляра выполнения протокола. Она показывает пирам в зеленом (слева) кружке выполнение, ведущее к состоянию C, и показывает пирам в синем (справа) кружке выполнение, ведущее к состоянию D. Некоторые из пиров (на пересечении) могут видеть, что нода двусмысленна, и по мере того, как сеть будет распространять информацию, все больше нод узнают о двусмысленном поведении той ноды. Неудача консенсуса будет вызвана тем, что достаточно большое количество участников будет вести себя таким византийским образом

Decision Guarantee

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

Таким образом, нода «принимает решение» о согласованном значении (то есть достигает окончательности значения) после того, как она увидит достаточно большое количество валидаторов, предлагающих значение в действительных сообщениях. Это «достаточно высокое» число зависит от порога отказоустойчивости этого узла. Важный инструмент, который позволяет узлам обнаруживать окончательные решения, которые называются оракулом решений

Decision Oracle

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

Надеюсь статья была интересной и понятной!