Чтобы блокчейн работал (продолжайте расти и добавляйте новые транзакции), для решения проблемы распределенного консенсуса должны произойти две вещи. Как правило, эти задания выполняются полными узлами, как в случае с узлом субстрата по умолчанию.
Блочная авторизация . Узлы создают новые блоки. Каждый новый блок содержит ссылку на родительский блок.
Завершение блока . Когда в цепи появляются вилки, узлы должны выбрать, какую сторону вилки считать реальной или «канонической». Как только блок будет завершен, каноническая цепочка будет всегда содержать его.
Давайте рассмотрим каждый из упомянутых алгоритмов по отдельности и посмотрим, как они выполняют эти задачи.
Создание блока
Аура
Аура в основном обеспечивает создание блока. В ауре известной совокупности авторитетов разрешено производить блоки. Полномочия должны быть выбраны до начала производства блоков, и все органы должны знать весь набор полномочий. Время делится на «слоты» фиксированной длины. Во время каждого слота создается один блок, и власти по очереди производят блоки по порядку навсегда.
В Aura вилки происходят только тогда, когда для прохождения блока через сеть требуется больше времени, чем для интервала времени. Таким образом, вилки редко встречаются в хороших сетевых условиях.
Babe
Babe также в основном обеспечивает авторизацию блоков. Как, например, Aura, это алгоритм консенсуса на основе слотов с известным набором валидаторов. Кроме того, каждому валидатору присваивается вес, который должен быть назначен до начала производства блока. В отличие от Ауры, власти не ходят по очереди. Вместо этого во время каждого раунда каждый авторитет генерирует псевдослучайное число, используя VRF . Если случайное число меньше, чем их вес, им разрешается создавать блок.
Поскольку несколько валидаторов могут создавать блок в течение одного и того же слота, вилки чаще встречаются в Babe, чем в Auraи распространены даже в хороших сетевых условиях.
Реализация на субстрате Babe также имеет запасной механизм, когда в данном слоте не выбраны права доступа.
Proof of Work
Proof of Work также обеспечивает блок авторинга. В отличие от Babe и Aura, он не основан на слотах и не имеет известного набора полномочий. В доказательство работы каждый может создать блок в любое время, если он может решить сложную вычислительную задачу (обычно это хеш поиск прообраза ). Сложность этой проблемы может быть настроена так, чтобы обеспечить статистическую цель время блока.
Финализация блока
Вероятностные методы
Каждый из механизмов авторизации блокамы уже обсуждали ранее, необходимо знать , где в цепочке должен построить следующий блок. Такие методы, как «правило самой длинной цепи», «самое тяжелое наблюдаемое поддерево», часто работают на практике и обеспечивают вероятностную окончательность. То есть, с каждым новым блоком, который добавляется в цепочку, вероятность того, что он будет отменен, уменьшается, приближаясь к нулю. Когда требуется истинная уверенность в том, что блок является окончательным, можно использовать более сложную игру.
Дедушка
Дедушка обеспечивает завершение блока. У этого есть известный взвешенный авторитет, установленный как Детка. Однако дедушка не является автором блоков;он просто слушает слухи о блоках, которые были созданы каким-то авторским движком, таким как три, описанные выше. Каждый орган власти участвует в двух турах голосования по блокам. детали голосования выходят за рамки этого поста. После того, как 2/3 авторитетных дедушек проголосовали за определенный блок, он считается завершенным.
Гибридный консенсус
Как правило, механизм создания блоков и гаджет окончательности могут использоваться вместе в одной цепочке, поскольку Бабе и Дедушка в коде, связанном в вопросе. При использовании такой системы механизмы создания блоков должны быть осведомлены о завершенных блоках, чтобы они не тратили время на сборку поверх блоков, которые никогда не будут в канонической цепочке.
Примечание по весам : детка, дедушка и многие другие алгоритмы, которые не поставляются в комплекте с субстратом, зависят от весов. Сами алгоритмы консенсуса обычно не диктуют, как присваиваются веса, а скорее предполагают, что они присваиваются каким-то образом, оставляя присваивание внешнему механизму. В общедоступных сетях принято присваивать веса в зависимости от количества разнесенных токенов. В узле Substrate по умолчанию все весовые коэффициенты установлены на 1, потому что алгоритм phragmen сохраняет все валидаторы близкими к одинаковым ставкам.