Tower BFT: Высокопроизводительная реализация PBFT от Solana

Узнайте об одной из 7 ключевых технологий, которые делают Solana самым производительным блокчейном в мире

Solana — самый производительный блокчейн в мире. На текущих итерациях сеть Solana Testnet из 200 физических отдельных узлов поддерживает устойчивую пропускную способность более 50 000 транзакций в секунду при работе с графическими процессорами. Это достижение требует внедрения оптимизаций и новых технологий, в результате мы получаем прорыв в пропускной способности сети, который свидетельствует о новом этапе в разработке блокчейна.

7 ключевых технических инноваций, которые делают сеть Solana возможной:

  • Proof of History (POH)— часы перед консенсусом;
  • Tower BFT — PoH-оптимизированная версия PBFT;
  • Turbine — протокол распространения блоков;
  • Gulf Stream — протокол пересылки транзакций без Mempool;
  • Sealevel — Параллельно исполняемые смарт-контракты;
  • Cloudbreak — База данных горизонтально масштабируемых учетных записей;
  • Replicators — Распределенное хранение реестра

В этом посте мы рассмотрим Tower BFT, индивидуальную реализацию PBFT от Solana, которая предпочитает жизнеспособность, а не согласованность. Tower BFT использует PoH от Solana как часы до достижения консенсуса, чтобы уменьшить накладные расходы и задержки при обмене сообщениями.

“Для обеспечения жизнеспособности реплики должны перейти в новое представление, если они не могут выполнить запрос. Однако важно сделать максимальным период времени, когда по крайней мере 2f + 1 правильных реплик находятся в одном и том же виде, а также обеспечить экспоненциальное увеличение этого периода до тех пор, пока не будет выполнена какая-то запрошенная операция” (Практическая византийская устойчивость к сбоям, Мигель Кастро и Барбара Лисков).

Solana реализует вывод PBFT, но с одним принципиальным отличием. Proof of History (PoH) предоставляет глобальный источник времени до достижения консенсуса. Наша реализация PBFT использует PoH в качестве сетевых часов, и экспоненциально увеличивающееся время ожидания, которые реплики используют в PBFT, может быть вычислено и применено в самом PoH.

PoH является проверяемой функцией задержки, реализованной в виде последовательной хэш-функции. Мы используем свободное определение VDF, поскольку для проверки требуется (время вычисления)/(количество ядер). Основные принципы работы PoH:

  1. Алгоритм Sha256 зацикливается максимально быстро, так что каждые  выходные данные является следующими входными.
  2. Цикл работает, а число итераций и состояние записываются.

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

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

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

Скажем по-другому: представьте, что вы на острове, а мимо проплывает бутылка с флешкой. На этом носителе находится реестр Solana PoH. Используя только реестр PoH вы можете вычислить состояние всех узлов в сети. Например, узел считается нерабочим, если его вклад в реестр не был записан в течение Х последних хэшей. Мы можем считать, что реестр является действительным, если в течение последних X хэшей хешируется большая часть сети, которая подписало сообщение проверки.

  1. Все узлы, которые проверяют эту структуру данных, будут вычислять один и тот же результат, не требуя одноранговой связи.
  2. Хеш PoH однозначно идентифицирует эту ветвь главного реестра.
  3. Сообщение о проверке голосования действительно только в том случае, если в реестре присутствует хэш PoH, за который оно проголосовало.

Это подводит нас к голосованию и PBFT. Поскольку сам реестр работает как надежные сетевые часы, мы можем кодировать время ожидания PBFT в самом реестре.

  1. Голосование начинается с времени ожидания из N хэшей.

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

  1. Время ожидания для всех голосов предшественника удваиваются.

Чтобы сделать операции более управляемыми, голосование ограничено фиксированным периодом хэшей, который мы называем слотами. Наша цель для слотов — это число хэшей, которое составляет около 400 мс. Каждые 400 миллисекунд сеть имеет потенциальную точку отката, но каждый последующий голос удваивает количество реального времени, которое сети пришлось бы использовать, прежде чем она сможет отменить это голосование.

Представьте, что каждый валидатор проголосовал 32 раза за последние 12 секунд. Голосование 12 секунд назад теперь имеет время ожидания 2³² слотов или примерно 54 года. По сути, это голосование никогда не будет отменено сетью. В то время как самое последнее голосование имеет время ожидания 2 слота или около 800 мс. Поскольку новые блоки добавляются в реестр, все более вероятно, что старые блоки будут подтверждены, потому что количество слотов, за которые было старое голосование, удваивается каждый слот или каждые 400 мс.

Обратите внимание, что хотя это звучит как вероятностная окончательность в доказательстве работы, это не так. После того, как ⅔ валидаторов проголосовали по какому-либо хешу PoH, этот хеш PoH канонизируется и не может быть отменен. Это отличается от алгоритма proof of work, в котором нет понятия канонизации.

Чтобы защитить себя от блокировки остальной сетью, каждый валидатор гарантирует, что он проголосует только в том случае, если увидит, что большинство из сети голосует за один реестр. Каждый валидатор отслеживает, когда время ожидания при голосовании за старый блок увеличится выше заранее определенного порога (например, от 5 до 10 минут), и гарантирует, что большинство голосов сети проголосовало на вилке, содержащей этот голос. На практике валидаторы:

  1. Проверяют, проголосовало ли абсолютное большинство за слот в интервале времени, равном 10 минутам.
  2. Если нет, он не голосует

Итак, что происходит с сетью в момент раздела, когда время ожидания фактически истекает?

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

Для примера давайте рассмотрим сценарий, в котором текущее время ожидания:

64, 32, 16, 8, 4, 2

Если валидатор прекратил голосовать за 17 слотов и проголосовал снова, в результате время ожидания для валидатора будут:

64, 32, 2

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

64, 32, 4, 2

64, 32, 8, 4, 2

64, 32, 16, 4, 2

Наконец, 4-е голосование удвоит время ожидания

128, 64, 32, 16, 8, 4, 2

Такой подход позволяет сети непрерывно передавать потоки блоков без остановки реестра, пока абсолютное большинство не соберет тот же реестр. Еще одним примечательным аспектом является то, что каждый участник сети может вычислить время ожидания для любого другого участника без какой-либо связи P2P. Эта особенность делает алгоритм Tower BFT асинхронным.

Мы ожидаем, что будет много микро-вилок, которые быстро отбрасываются. Когда валидатор обнаруживает несколько вилок, честные валидаторы вычисляют эффективное взвешенное по ставке время ожидания каждой вилки и выбирают самое большое. Награды валидатора начисляются только за голоса, достигшие времени ожидания 2³². Поэтому для валидаторов естественно голосовать за самое массивное ответвление, поскольку ответвление с наибольшим взвешенным по ставкам времени ожидания будет генерировать наибольшее количество вознаграждений для сети.

Solana Validators and community: Take part in Tour de SOL and earn tokens!Валидаторы Solana и сообщество: Примите участие в Tour de SOL и заработайте токены!

Внедрение Solana Tower BFT, наряду с такими инновациями, как Proof of History, Proof of Replication и Gulf Stream, в совокупности создают самый производительный блокчейн в мире. Тестовая сеть Solana работает уже сегодня. Вы можете увидеть ее по адресу https://explorer.solana.com/. В целях экономии мы используем только несколько узлов. Однако во многих случаях мы распространили ее более чем 200 физических отдельных узлов (не на совместно используемом оборудовании) в 23 центрах обработки данных в AWS, GCE и Azure для сравнительного анализа.

Среда выполнения также работает уже сегодня, и разработчики могут развернуть код в тестовом режиме уже сейчас. Сегодня разработчики могут создавать смарт-контракты на C, мы активно работаем над набором инструментов Rust. Rust будет основным языком для разработки смарт-контрактов Solana. Набор инструментов Rust общедоступен как часть Solana Javascript SDK, мы продолжаем работу над пакетом разработки ПО.

Вскоре Solana запустит общедоступную бета-версию, стимулирующую валидаторов для запуска узлов через Tour de SOL — аналог «Game of Stakes» у Cosmos, которая ставит перед общественностью задачу протестировать пределы сети Solana, зарабатывая при этом токены.