Консенсус в Solana

Практические выводы

• Роль Proof-of-History (PoH) в синхронизации: PoH — не алгоритм консенсуса, а инструмент, который механизм консенсуса Solana использует для синхронизации. Аналогично, Proof-of-Stake (PoS) — не консенсус, а средство защиты от атак Сивиллы.
• Транзакции голосования необходимы для консенсуса: голоса внутри блоков — не лишние транзакции, искусственно завышающие показатели TPS. Если бы голоса распространялись только через gossip-протокол (неформальное одноранговое взаимодействие), валидаторы могли бы по-разному воспринимать состояние Tower, то есть состояние голосования.
• В Solana действуют два основных правила подтверждения: одно для краткосрочного выбора форка (оптимистическое подтверждение), другое — для полного консенсуса PoS, обеспечивающего финальность (финализированный/укоренённый блок). Клиенты и пользователи могут выбирать правила подтверждения в зависимости от требуемых свойств безопасности и желаемого UX. Им соответствуют два уровня обязательств: «confirmed» и «finalized».
• Понимание риска цензуры: валидаторы и разработчики должны учитывать потенциальные атаки с цензурой, при которых валидатор пытается нарушить последовательность производства блоков. Важно понимать механику таких атак, а также роль вычислительной мощности и стейка в их проведении.
• Будущие обновления протокола: валидаторам и разработчикам следует активно готовиться к предстоящим изменениям механизма консенсуса Solana, включая асинхронное выполнение и программный слэшинг.

Введение

По мере роста активности в Solana различные уровни её стека подвергаются беспрецедентной нагрузке. О таких «горячих» темах, как локальные рынки комиссий, много пишут и говорят, однако консенсусу в Solana долгое время уделяли мало внимания. Но рост активности и интереса требует, чтобы сообщество хорошо понимало консенсус: стимулы для вредоносных атак и потенциальная прибыль от эксплуатации уязвимостей увеличиваются.

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

Консенсус в распределённых системах изучают уже много лет. Работа Лэмпорта, Шостака и Пиза «Задача византийских генералов» была опубликована в начале 1980-х годов. Такие алгоритмы консенсуса, как RAFT, давно используются в web2. В криптоиндустрии большинство алгоритмов консенсуса представляют собой различные реализации консенсуса BFT, включая Gasper (Ethereum), Tendermint (Cosmos), MonadBFT (Monad), HotShot (Espresso) и Narwhal/Tusk (Sui). 

Эта статья не пытается формально доказать корректность механизма консенсуса Solana (TowerBFT). Её цель — объяснить разработчикам и всему сообществу, как работает консенсус в Solana. Пока эта тема в основном остаётся в сфере знаний участников Solana Labs и Firedancer. Мы также рассмотрим некоторые компромиссы и ограничения.

Краткое введение в консенсус

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

• Протоколы самой длинной цепочки: такие протоколы, как консенсус Накамото в Bitcoin, считают канонической цепочку, для создания которой потребовалось больше всего вычислительных усилий. Часто это цепочка с наибольшим количеством блоков, но точнее говорить о цепочке с максимальным объёмом совокупной работы или вычислительной мощности.
• Протоколы типа BFT: большинство протоколов PoS реализуют одну из версий алгоритма консенсуса BFT. Такие протоколы, как pBFT, используют пороговые значения для обеспечения живости и безопасности. Согласованность и доступность — две гарантии теоремы CAP. Она гласит, что любое распределённое хранилище данных может одновременно обеспечить только две из трёх гарантий: согласованность, доступность и устойчивость к разделению сети.

Безопасность протоколов консенсуса как самой длинной цепочки, так и типа BFT определяется их правилами подтверждения. Безопасность, включающая сохранность и живость, следует из конкретного правила подтверждения и не является свойством самой цепочки. По определению Ethereum Foundation, правило подтверждения — это «алгоритм, который выполняют ноды и который определяет, подтверждён ли конкретный блок. Если блок подтверждён, гарантируется, что он никогда не подвергнется реорганизации при определённых допущениях — прежде всего о синхронности сети и доле честного стейка».

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

Proof-of-Stake добавляет к модели BFT дополнительные уровни и требует от участников предоставлять собственный стейк. Участники получают вознаграждение за соблюдение набора правил, но могут подвергнуться слэшингу при доказанном нарушении, например двойной подписи. Это называют ответственностью за безопасность: протокол может выявлять и наказывать вредоносные ноды без негативных последствий для честных нод. Однако это не заменяет фундаментальный механизм безопасности протоколов консенсуса BFT. Чтобы сеть не остановилась, доля нечестных нод должна быть меньше одной трети, а чтобы не допустить подтверждения ложных транзакций — меньше двух третей. Система на основе стейка вводит последствия за действия, способные нарушить или снизить эффективность сети.

В такой BFT-сети есть два критических порога:

1. 1/3: если нечестные ноды составляют не менее трети от общего числа, сеть может «остановиться». Эти ноды могут просто отказаться от участия, и остальные не смогут набрать сверхбольшинство в две трети, необходимое для консенсуса. В результате сеть не создаёт некорректные транзакции, а полностью прекращает создавать любые транзакции. Популярная, хотя и грубая, метрика — коэффициент Накамото. Он показывает минимальное количество нод, необходимое для нарушения живости, то есть остановки производства блоков.
2. 2/3: если нечестные ноды составляют не менее двух третей, они могут вступить в сговор и подтвердить любые выбранные ими транзакции. Это наихудший сценарий: сеть перестаёт работать корректно и обрабатывает транзакции по указанию нечестного сверхбольшинства. Если злоумышленник контролирует более 67% стейка, он потенциально может изолировать честную ноду, например ноду крупной биржи (например, Binance). Для этого он может вступить в сговор с дата-центром и ограничить сетевой трафик ноды. Затем злоумышленник может заставить изолированную ноду финализировать подготовленный им блок, одновременно распространив конфликтующий блок по остальной сети. Такая атака использует ограниченное представление изолированной ноды и может привести к двойному расходованию, поскольку остальная сеть и изолированная нода видят разные состояния блокчейна.

Похожая атака возможна и с меньшим стейком — более 33%, но для этого потребуется разделить сеть, а не просто изолировать одну ноду. В такой ситуации византийский стейкхолдер может использовать разделение сети, чтобы передавать её разным сегментам противоречивую информацию. Это снова создаёт риск двойного расходования и других нарушений безопасности.

Как правило, чем больше нод, тем сложнее любой стороне скомпрометировать достаточно значительную их часть для достижения этих порогов — при условии географического распределения. Однако стремление увеличить сеть часто противоречит эффективности. Большое количество нод может замедлить консенсус из-за роста объёма передаваемых данных: распространение голосов занимает больше времени. В некоторых протоколах даже действует жёсткое ограничение на максимальное количество нод.

Proof-of-History (PoH)

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

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

В основе PoH лежит простой алгоритм хеширования, похожий на проверяемую функцию задержки (VDF), но технически не являющийся VDF. Solana реализует его с помощью последовательной устойчивой к нахождению прообраза хеш-функции SHA-256, которая работает непрерывно и использует результат одной итерации как входные данные для следующей. Эти вычисления выполняются на одном ядре каждого валидатора.

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

Рассмотрим пример с четырьмя валидаторами сети Solana: валидаторами A, B, C и D. В этом примере расписание лидеров может задавать последовательность производства блоков A - B - C - D. Валидатор A первым начинает генерировать блок. Для этого он использует механизм PoH: многократно запускает хеш-функцию SHA-256 и формирует временную шкалу из «тиков». Процесс хеширования создаёт уникальную и проверяемую запись затраченного времени, поэтому блок валидатора A точно отражает его течение. Когда валидатор A завершает блок, наступает очередь валидатора B, а затем валидатора C.

Предположим, валидатор C пытается нарушить последовательность и выпустить блок вне своей очереди — сразу после валидатора A, обойдя валидатора B. Чтобы убедительно занять место валидатора B, валидатор C должен воспроизвести последовательность хешей PoH, которую создал бы валидатор B. То есть ему нужно сгенерировать последовательность хешей, представляющую время, которое валидатор B потратил бы на производство блока. Производительность хеширования на одном ядре имеет физический максимум. Поэтому нам известно, что прошло определённое время: компьютер способен создать лишь ограниченное количество хешей за заданный интервал.

Валидатор C может попытаться подвергнуть валидатора B цензуре в расписании лидеров. Для этого он генерирует цепочку пустых блоков без транзакций, начиная с конца предыдущего легитимного блока — блока валидатора A. Чтобы успешно подвергнуть B цензуре, C должен выполнить два условия. Во-первых, C нужна вычислительная мощность для перебора пустой цепочки PoH. Во-вторых, C должен быстро распространить свой блок среди достаточного количества нод со стейком, чтобы его блок приняли во время назначенного ему слота, тем самым фактически подвергнув B цензуре. Валидатор с большим весом стейка может сделать это быстрее благодаря Turbine, который приоритизирует поток информации по весу стейка валидатора.

Такой сценарий атаки возможен, но окно для успешной цензуры ограничено. Атакующей ноде нужны значительные вычислительные ресурсы для хеширования SHA-256 и большой стейк, поскольку количество создаваемых ею блоков пропорционально её стейку.

Помимо необходимости опередить ноду A при распространении данных по сети, C также должен быстро генерировать хеши. В основном эта атака нацелена на сценарий, в котором валидатор, назначенный лидером слота n, пытается подвергнуть цензуре валидаторов, лидирующих в предыдущих слотах — до n. Масштаб доступной ему цензуры зависит от стейка, поскольку возможность получать лидерские слоты напрямую связана с объёмом стейка.

Механизм PoH также обеспечивает стабильную скорость производства блоков. Поскольку каждый валидатор может независимо проверить последовательность PoH, внешняя синхронизация времени не требуется. Например, Ethereum использует протокол сетевого времени (NTP) в каждом блоке для консенсуса. В Solana каждый валидатор самостоятельно и без внешнего протокола проверяет, что каждый блок был создан в правильном временном слоте.

Tower BFT — механизм консенсуса Solana

Tower BFT, механизм консенсуса Solana, начинает работать после распространения шредов — частичных блоков — среди других валидаторов:

Как упоминалось выше, Solana использует Tower BFT вместе с Proof-of-History. Tower BFT — похожий на pBFT алгоритм консенсуса, разработанный для использования синхронизированных вычислений времени из Proof-of-History. Они создают единые часы для всей сети, что позволяет эффективно пропускать слоты медленных или не отвечающих лидеров. Сети не приходится проводить синхронный раунд консенсуса для каждого слота. Это обеспечивает непрерывное производство блоков: валидаторам не нужно ждать поступления предыдущих блоков, прежде чем начать строить следующий.

Ещё одно заблуждение заключается в том, что механизм консенсуса Solana уже реализует программный слэшинг. Хотя слэшинг входит в планы развития, сейчас после нарушения безопасности сеть останавливается и при необходимости применяет слэшинг на основе социального консенсуса.

Механизм консенсуса Solana наделяет разные ноды разной степенью влияния. Голоса в сети не равны: их вес определяется стейком каждой ноды по тем же принципам, что и взвешенный по стейку QoS и Turbine. При прочих равных нода с большим стейком сильнее влияет на определение канонического консенсуса, чем нода с меньшим стейком.

Например, в сети из четырёх нод с общим стейком 100 распределение и влияние могут выглядеть так:

• Нода A имеет 10 единиц стейка.
• Нода B имеет 20 единиц стейка.
• Нода C имеет 30 единиц стейка.
• Нода D имеет 40 единиц стейка.

В такой конфигурации возможности каждой группы нечестных нод различаются. Одна нода, например D, способна остановить сеть благодаря большому стейку, хотя она составляет лишь 25% от общего числа нод. Аналогично, ноды C и D вместе могут одобрять некорректные транзакции. Они составляют только 50% нод, но обладают достаточным стейком, чтобы влиять на результат.

Порог в одну треть для остановки сети можно достичь за счёт нечестных, скомпрометированных или заблокированных нод. Однако достижение порога в две трети для подтверждения некорректных транзакций требует активного сговора: простой блокировки честных нод недостаточно. Поэтому достичь второго порога значительно сложнее. Для этого ноды нужно подкупить или скомпрометировать, чтобы они активно участвовали в нечестной схеме, а не просто блокировать честные ноды.

Контекст внутри слотов

В Solana лидерам назначают четыре последовательных слота общей продолжительностью около 1,6 секунды (4 блока × 400 мс на блок). Лидеров выбирают в начале каждой эпохи (432 000 слотов, или ~2–3 дня). Расписание лидеров формируется случайным образом с учётом веса стейка валидатора.

Лидер должен построить и предложить новый блок для каждого назначенного ему слота. Здесь нет разделения между предлагающим и создающим блок, как в экосистеме Ethereum. Другие валидаторы подтверждают действительность блока с помощью транзакций голосования, применяя правило выбора форка к собственному локальному представлению о вершине сети Solana.

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

Рассмотрим расписание лидеров с четырьмя участниками (A, B, C, D), где D пытается нарушить последовательность. Если D вмешается во время очереди C, ему придётся создать последовательность тиков PoH, которая фактически пропускает блок C. Получится такая цепочка:

A - B - [C отсутствует] - D.

Если блок C отсутствует, честный D должен сгенерировать последовательность PoH, покрывающую всю продолжительность слота C, прежде чем начать собственный слот. Тогда блок D будет выглядеть действительным, поскольку он следует за блоком B после истечения времени, выделенного слоту C.

Пока D создаёт последовательность PoH для слота C, валидатор C в обычных условиях передаёт поток своего блока, соединённого с блоком B соответствующей последовательностью PoH. Возможны два исхода:

• Если D вычисляет PoH не быстрее C: C завершает свой блок примерно в тот момент, когда D начинает транслировать собственный. Поскольку сеть уже увидела блок C, она отклонит блок D.
• Если D вычисляет PoH быстрее C: D начинает транслировать свой блок до того, как C завершит собственный. Но даже в этом случае D должен значительно опережать C, чтобы существенно повлиять на последовательность. Это маловероятно из-за высокой скорости и относительно близких верхних пределов производительности процессоров, которые валидаторы используют для вычисления SHA-256.

В обеих ситуациях вероятность того, что D успешно заменит C, минимальна. Более того, если попытка D заменить C провалится, D потеряет возможность выпустить блок в собственном слоте. Выпуск блока сразу после B, а затем ещё одного после C считается нарушением — созданием двух блоков для слота D — и влечёт за собой слэшинг. Каждая неудачная попытка лишает D возможности создать собственный блок, поэтому D вряд ли выберет такую стратегию. 

С точки зрения сети намерения D определить невозможно. Крайне сложно или даже невозможно отличить ситуацию, когда D просто не увидел блок C и не пытался подвергнуть его цензуре, от ситуации, когда D намеревался подвергнуть цензуре B. Поэтому такое поведение трудно обнаружить, и сеть не может за него наказать.

Транзакции голосования

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

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

Транзакции голосования необходимы для консенсуса — это не лишние транзакции, искусственно завышающие показатели TPS. Если бы голоса распространялись только через gossip-протокол — неформальное одноранговое взаимодействие, — валидаторы могли бы по-разному воспринимать состояние Tower, то есть состояние голосования. Из-за таких расхождений валидаторы могли бы по-разному оценивать, какой форк с большей вероятностью окажется правильным. Это способно привести к расхождению, когда валидаторы принимают эгоистичные решения на основе неполной или несогласованной информации. Непрерывное производство блоков требует постоянного голосования, особенно пока предыдущие блоки ещё подтверждаются. Для этого необходимо надёжное и согласованное представление о состоянии Tower.

Как и обычные транзакции пользователей, транзакции голосования должны оплачивать базовую комиссию (0,000005 SOL). Её оплачивает идентификатор валидатора, который должен находиться в горячем кошельке для постоянного подписания. Аккаунт голосования используется для поиска аккаунта и делегирования.

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

Получив несколько блоков для одного слота, валидатор отслеживает все возможные форки, пока не сможет определить «лучший». Валидаторы локально выполняют соответствующую функцию перехода состояния — это изменится при асинхронном выполнении, — а после воспроизведения голосуют за новые блоки. Голоса за конкретный форк выражаются через ончейн-транзакции голосования.

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

Валидатор также подписывает хеш блока для каждого блока-предка между своим предыдущим голосом и укоренёнными/финализированными блоками. Это необходимо для обнаружения дублирующихся блоков. Если бы лидер отправлял каждой ноде разные блоки, все ноды проголосовали бы за разных предшественников одного слота. Однако в эпохе из 65 000 слотов размер каждого голоса в самом крайнем случае мог бы достигать 2 МБ. Для каждого из 65 000 слотов могли бы потребоваться хеши размером 32 байта. Мы подробнее рассмотрим это в следующей статье.

Валидаторы управляют «башней голосов» — последовательным стеком голосов, где каждый голос усиливает форк и является предком форка, расположенного над ним в башне. При добавлении нового голоса периоды блокировки всех предыдущих голосов в стеке удваиваются. Так постепенно увеличиваются обязательства и период блокировки более ранних решений. Сам процесс голосования регулируется несколькими проверками. Валидаторы должны соблюдать периоды блокировки предыдущих голосов, убеждаться, что значительная часть сети — обычно две трети — также поддерживает тот же форк, и получать существенное большинство — более 38% — голосов за альтернативные форки, прежде чем переходить на новый форк.

Для блока в слоте n голоса других валидаторов начинают появляться в блокчейне уже в n+1. Подкомитетов по голосованию нет: все валидаторы могут голосовать за все блоки. Сначала эти голоса появляются в блоках других валидаторов, расположенных рядом — на расстоянии одного перехода — в дереве Turbine. Голоса за слот n могут появляться вплоть до слота n+512, поскольку валидатор вправе голосовать за любой слот, «хеш слота» которого ещё известен, а хеши сохраняются на протяжении 512 слотов (спасибо Shinobi). Для слота n нет заранее заданной верхней границы на определённом блоке. Однако укоренённые слоты, над которыми построено не менее 32 непрерывных блоков, больше не принимают голоса и становятся финализированными.

В схеме голосования есть особенности, которые среда выполнения обеспечивает не полностью. Например, сейчас валидаторам выгодно голосовать только за «укоренённые» слоты, игнорируя вершину цепочки, и консенсус за это не наказывает. Валидатор может постоянно получать кредиты за голосование по форкам с чрезвычайно высокой вероятностью стать каноническими, не участвуя в фактических операциях консенсуса на вершине цепочки. Это происходит уже сейчас: у одного из валидаторов средняя «задержка голосования» превышает 68 слотов. Предлагаемая функция Timely Vote Credits призвана устранить это несоответствие стимулов.

Правило выбора форка Solana

Как и Ethereum (LMD Ghost и Casper FFG), Solana использует два правила подтверждения: одно для краткосрочного выбора форка, другое — для полного консенсуса PoS, обеспечивающего финальность. Это позволяет пользователям и клиентам выбирать желаемый UX при разных правилах подтверждения. Им соответствуют два уровня обязательств: «confirmed» и «finalized».

Для «подтверждённых» блоков, также известных как оптимистически подтверждённые, не менее 2/3 валидаторов должны проголосовать за конкретный блок с помощью транзакций голосования. Чтобы стало возможным нарушение финальности, слэшингу должно подвергнуться ~4,6% текущего стейка. Для «финализированных» блоков требуются голоса как минимум в 32 последующих слотах или сверхбольшинство (>2/3) голосов. При вредоносной атаке слэшингу подвергнется более 1/3 стейка. Такая финализация занимает значительно больше времени, чем подтверждение: для полной финальности необходимо дождаться блоков, укоренённых 32 блока назад.

Правило выбора форка позволяет сети достичь консенсуса относительно вершины цепочки. Реализация Solana Labs обрабатывает выбор форка преимущественно в файле Rust примерно на 4600 строк с уместным названием heaviest_subtree_fork_choice.rs. Он содержит логику, необходимую валидаторам для определения форка, который с наибольшей вероятностью станет каноническим. Подробный разбор кода появится в следующей статье, а на самом высоком уровне механизм выбора форка работает так:

1. Голоса добавляются с помощью add_votes():

Функция перебирает новые голоса, при необходимости вычитает стейки аккаунтов голосования из старых слотов и добавляет стейк к новым слотам, за которые проголосовали валидаторы.

2. Вызывается generate_update_operations() для создания пакета операций обновления форка:

Она выполняет следующие действия:

• Вычитает стейк из старого форка
• Добавляет стейк к новому форку
• Агрегирует стейк вверх по каждому форку до корня

3. process_update_operations():

• При необходимости вызывает mark_fork_valid()/invalid()
• Вызывает aggregate_slot() вверх по каждому форку для обновления весов форков
• Вызывает add_slot_stake()/subtract_slot_stake() для обновления стейков

4. aggregate_slot():

• Суммирует стейк всех дочерних слотов
• Находит дочерний форк с наибольшим весом стейка
• Находит самый глубокий дочерний форк по высоте
• Передаёт эти значения вверх, чтобы найти самый тяжёлый и глубокий форк от этого слота

5. select_forks():

• Возвращает самый тяжёлый форк для производства блоков
• Возвращает самый тяжёлый форк, исходящий от последнего голоса

Стейк добавляется или вычитается в зависимости от голосов. Агрегация пересчитывает веса каждого форка снизу вверх. Лучшим форком для дальнейшего построения и голосования становится корень с самым тяжёлым взвешенным поддеревом.

Вероятность включения

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

Слоты могут быть «пропущены», например если лидер не в сети. Тогда транзакция может попасть в будущие блоки или не попасть в блокчейн вовсе.

Указанные здесь слоты — приблизительные оценки, которые помогают понять, когда обычно накапливаются голоса. Кроме того, для каждого блока процесс уникален: блоки могут достигать уровня подтверждения «confirmed» или «finalized» за разное время. Риск отката монотонно снижается на протяжении жизненного цикла транзакции. Даже после финализации — укоренения — блока теоретически социальный консенсус может создать форк и удалить блок из «канонической» цепочки.

Направления будущих исследований и заключение

В этой статье мы рассмотрели внутреннее устройство Tower BFT — механизма консенсуса Solana — и другие связанные механизмы. Мы изучили роль Proof-of-History, транзакций голосования и выбора форка в создании канонического форка для упорядочивания транзакций в Solana.

Существует множество дополнительных направлений для исследования и формализации этих механизмов, например:

• Исследователи Ethereum количественно оценили выгоду от игр со временем, когда производители блоков ждут до конца слота, прежде чем отправить блок. Как количественно выглядят такие игры в Solana и происходят ли они сейчас?
• Планируется, что асинхронное выполнение станет главным изменением протокола в 2024 году. Какие потенциальные векторы атак и аспекты безопасности существуют для нод, которые просто голосуют за существующие форки, а не вычисляют переходы состояния локально?
• Сейчас значительное меньшинство валидаторов (<20%) использует модификации клиента Solana Labs или Jito-Solana. Какие пороговые значения, не регулируемые средой выполнения или правилами подтверждения, они меняют?
• Реализация программного слэшинга. Сейчас, кроме социального консенсуса, почти нет экономических стимулов отказываться от высокоприбыльных торговых стратегий без риска слэшинга.
• Как выглядит производительность механизма консенсуса Solana при работе двух совершенно разных клиентов, даже если они пытаются следовать одним и тем же правилам подтверждения?
• Каковы ожидаемые преимущества подкомитетов по голосованию для производительности и сокращения состояния?
• Какие потенциальные векторы атак возникают при перезапуске с оптимистически подтверждённого слота вместо финализированного? Как сторонним офчейн-сервисам, например биржам, следует использовать оптимистическое подтверждение или полную финальность?
• Следует ли использовать средства, полученные от слэшинга, для страхования транзакций, затронутых нарушениями безопасности? Каковы механика и стимулы страхового пула, номинированного в SOL?

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

Спасибо anoushk (Tinydancer), dubbel06 (Overclock), Prithvi (Helius), Mert (Helius) и Jarry (Ellipsis Labs) за обсуждения и комментарии.