Это вольный и краткий перевод статьи: https://blog.zilliqa.com/the-zilliqa-design-story-piece-by-piece-part-2-consensus-protocol-e38f6bf566e3
Перевод подготовлен Mia, специально для канала @miacoins
Все мои новые публикации вы можете читать теперь на busy.org
В данной статье мы бы хотели осветить один из самых важных механизмов работы Zilliqa — механизм консенсуса. Вы также можете прочитать первую часть, которая посвящена деталям работы протокола и концепции шардинга, которую Zilliqa применяет для достижения масштабируемости сети.
Важность протокола консенсуса для высокой производительности сети
Одно лишь применение механизма шардинга недостаточно для обеспечения высокой скорости обработки транзакций. Производительность также определяется скоростью, с которой каждый шард может верифицировать транзакции и формировать новый блок. Тут и возникает необходимость в эффективном алгоритме консенсуса.
Идеальный протокол консенсуса для Zilliqa — этот тот, который мог бы поддерживать небольшой размер шарда (примерно 600 нод) и позволял быстро достигать консенсуса.
А как же консенсус протоколы, используемые в Bitcoin/Ethereum?
Внимательный читатель мог заметить, что размер шарда, указанный ранее, намного меньше, чем в стандартных P2P блокчейн сетях, таких как Bitcoin или Ethereum, где сеть формируется десятками тысяч нод. И у него может возникнуть вопрос, почему же Zilliqa не может использовать такой же протокол в каждом из шардов? Более того, так как размер шарда намного меньше, чем в других сетях, то и консенсус между нодами в шарде должен достигаться быстрее.
В реальности же один лишь размер шарда не приводит к ускорению механизма консенсуса.
Давайте более внимательно рассмотрим алгоритм консенсуса, применяемый в Bitcoin и Ethereum. Эти блокчейн платформы используют так называемый консенсус Накамото. Согласно этому механизму консенсуса, сеть «выбирает» лидера через определенные промежутки времени, и этот лидер предлагает блок. Затем, он передает этот блок и ноды либо принимают, либо отклоняют его.
Ключ к консенсусу Накамото находится в способе определения этого лидера. Через приблизительно равные промежутки времени каждая нода публикует результат своих вычислений и та, которая произведет вычисления быстрее, и становится лидером. Разумеется, эти вычисления должны быть достаточно сложны, чтобы с высокой вероятностью появился лишь один лидер.
Проведение вычислений может замедлить алгоритм консенсуса. Более того, консенсус не зависит от количества нод, а от общей вычислительной мощности сети. Применимо к Zilliqa, алгоритм PoW не станет более эффективным при небольшом размере шарда, и поэтому нашей системе требуется другой протокол консенсуса.
Практическая византийская парадигма отказоустойчивости (PBFT) спешит на помощь
В Zilliqa используется протокол PBFT (практическая византийская парадигма отказоустойчивости) для достижения консенсуса в каждом шарде. Этот протокол был предложен Кастро и Лисков в 1999. При работе данного протокола считается, что до трети нод в каждом шарде могут быть нечестными (мошенническими).
Существует ряд причин, по которым мы выбрали именно этот протокол консенсуса. Главная причина: работа данного протокола зависит от размера сети, и малый размер шардов может позволить ему работать более эффективно.
В протоколе PBFT все ноды в группе (в шарде в нашем случае) имеют последовательность. Одна нода имеет статус главной (лидера), а остальные — вспомогательные. Процесс консенсуса проходит в три этапа:
1. Предварительная подготовка. На этом этапе лидер заявляет о новом блоке информации путем рассылки «предварительного сообщения».
2. Подготовка. Получив данное сообщение, каждая нода проверяет его и информацию в блоке на правильность, и рассылает сообщение о готовности всем другим нодам.
3. Выполнение. Получив сообщения о готовности от подавляющего большинства, каждая нода рассылает сообщение о выполнении транзакций в блоке. Наконец, каждая нода ожидает сообщения о выполнении от подавляющего большинства нод в шарде, что и будет означать, что информация, предложенная лидером, была принята.
Протокол PBFT основан на том, что лидер честен, потому как злонамеренные действия заморозят работу всего протокола. Чтобы справиться с этой проблемой, в протоколе существует процесс смены лидера. Если в течение заданного промежутка времени нет прогресса, каждая нода имеет право отправить запрос на смену лидера. Решение о смене лидера достигается подавляющим большинством нод, и следующим лидером становится нода из заранее оговоренного списка.
Другие достоинства PBFT
1. Завершенность транзакций. В протоколе PBFT транзакции считаются завершенными после достижения консенсуса. Подтверждение транзакций не требуется. При консенсусе Накамото требуется верификация транзакций для защиты от атаки двойного расходования.
2. Низкое энергопотребление. Так как протокол PBFT не основан на вычислительных процессах, то он не требует значительных затрат энергии. Zilliqa использует PoW только для защиты от атак сивиллы и для идентификации нод, но не для достижения консенсуса. После идентификации начинается работа по протоколу PBFT, и повторная идентификация проводится, скажем, через каждые 100 блоков. При консенсусе Накамото PoW требуется для каждого блока.
3. Меньшее различие между вознаграждениями майнеров. В протоколе PBFT консенсус достигается путем коллективного голосования и рассылки сообщений с подписью. Это позволяет снизить различие в размерах вознаграждений для майнеров.
Проблемы протокола PBFT
Протокол PBFT, безусловно, является подающим надежду способом достижения консенсуса в Zilliqa. Но у него есть один существенный недостаток: он работает эффективно только когда группа, достигающая консенсуса, мала (например, менее 50). Однако в Zilliqa используется размер шарда от 600 нод по причинам безопасности. В таком случае процесс коммуникации между нодами быстро становится узким местом, ведь каждая нода должна обмениваться сообщениями со всеми нодами в шарде.
Резюме
Один лишь механизм шардинга не достаточен для быстрой работы системы, поэтому требуется эффективный алгоритм консенсуса. Применяемый в Bitcoin/Ethereum алгоритм PoW не станет работать более эффективно при небольшом размере шарда, как в Zilliqa, так как зависит от общей вычислительной мощности сети.
В Zilliqa было принято решение использовать протокол PBFT (практическая византийская парадигма отказоустойчивости) для достижения консенсуса, так как он оптимален для небольшой сети. Кроме этого, PBFT обладает такими преимуществами как завершенность транзакций, низкое энергопотребление и меньшее различие между вознаграждениями майнеров.
При этом у PBFT есть один существенный недостаток: он работает эффективно только когда группа, достигающая консенсуса, мала (например, менее 50), в а в Zilliqa используется размер шарда от 600 нод по причинам безопасности.
***
Это вольный и краткий перевод статьи: https://blog.zilliqa.com/the-zilliqa-design-story-piece-by-piece-part-2-consensus-protocol-e38f6bf566e3
Перевод подготовлен Mia, специально для канала @miacoins
Все мои новые публикации вы можете читать теперь на busy.org
