Сравнение алгоритмов консенсуса ETH vs TON vs SOLANA

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

Всем кто остался — приятного чтения:‑)

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

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

ETH2 на PoS (Ethereum 2.0):

Источники: https://ethereum.org/ru/developers/docs/consensus-mechanisms/ , https://ethereum.org/ru/developers/docs/consensus-mechanisms/pos/ , https://vitalik.ca/general/2017/12/31/pos_faq.html , https://ethos.dev/beacon-chain 

Ethereum (ETH) — крупнейшая PoS-криптовалюта по рыночной капитализации; в 2024 году это крупнейший пример Proof-of-Stake (PoS) в мире криптовалют.

Валидаторы

Доказательство владения является базовым механизмом, который дает возможность стать валидатором при достаточном залоге. В Ethereum пользователи должны заложить 32 ETH, чтобы стать валидаторами.

Владельцы эфиров ставят их в стейкинг (замораживают) как гарантию блокирования. Валидаторы выбираются случайным образом для создания каждого блока и отвечают за проверку и подтверждение блоков, которые они не создавали. В качестве стимула для правильной проверки также используется залог пользователей. Например, пользователь может потерять часть своего залога, если будет вне сети (поскольку не сможет выполнять свою функцию — подтверждение блоков), или даже весь залог из-за преднамеренного сговора.

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

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

Шардинг

При замене доказательства работы на доказательство владения возникнет дополнительная сложность с цепочками осколков (шардингом). Это отдельные блокчейн цепочки, которые позволяют масштабировать сеть ETH и ускоряют её работу.  Существует 64 цепочки осколков, и у них у всех должно быть единое понимание состояния сети. В результате необходима дополнительная координация, которую будет выполнять Beacon Chain.

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

Алгоритм консенсуса

Когда вы отправляете транзакцию в сеть ETH (на самом деле в один из шардов), за добавление вашей транзакции в блок будет отвечать валидатор. Валидаторы для предложения новых блоков выбираются алгоритмически-случайным образом сетью Beacon.

Далее происходит процесс аттестации блока. Если валидатор не выбран для предложения нового блока, он может аттестовать предложение другого валидатора. 

Для аттестации каждого блока осколка требуется не менее 128 валидаторов. Группа валидаторов называется «комитетом».

У комитета есть срок, в который он должен предложить и утвердить блок осколка. Это называется «ячейкой». На одну ячейку создается только один действительный блок, а 32 ячейки составляют «эпоху».

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

Как только предложение о новом блоке шарда получит достаточно аттестаций, создается «кросс-ссылка», которая подтверждает включение блока и вашей транзакции в сеть Beacon Chain.

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

В распределенных сетях транзакция, которая является частью блока, является «финальной», потому что блок уже не может измениться. Время на его подтверждение (finalize), при достаточном количестве участников сети около 10-15 минут или 2 эпохи.

Чтобы добиться этого в системе с доказательством владения, Casper, протокол финальности, заставляет валидаторов согласовывать состояние блока в определенных точках. Как только 2/3 валидаторов придут к согласию, блок становится окончательным и завершенным. Валидаторы потеряют все свои залоги, если попробуют это исправить позже с помощью атаки 51 %.

Негативные сценарии

Нарушения валидаторов:

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

• Отказ в сотрудничестве: Валидаторы могут отказываться от подписания блоков или блокировать процесс консенсуса, чтобы нарушить нормальное функционирование сети.

Возможные атаки и защита от них:

• Система с доказательством владения защищена тем фактом, что вам понадобится 51 % от общего количества ETH для компрометации этой цепочки. И что ваша каждая ставка (попытка атаки) аннулируется (средства будут заблокированы) за злонамеренное поведение.

• Проблема "nothing at stake". Это попытка создать новую цепь валидации. В ETH PoS от этой атаки защищают: Штрафы за двойную подпись, Слешинг, Финализация

Последствия (наказания)

Нарушения могут привести к штрафам и потере стейка валидатора.

Подобные действия могут замедлить работу сети и создать нестабильность.

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

При любом добровольном или принудительном выходе происходит задержка в четыре эпохи, прежде чем стейкеры смогут забрать свою ставку. В течение четырех эпох валидатора все еще можно поймать на нарушении и применить санкции. Баланс честного валидатора можно вывести примерно за 27 часов. Но пойманный на нарушении валидатор получает задержку в 8192 эпохи (приблизительно 36 дней). 

Слешинг 

За самые серьезные нарушения, которые честный валидатор не мог совершить случайно или получить в результате действий других валидаторов предусмотрены серьезные наказания - штраф в размере от 0,5 ETH до всей ставки валидатора. За совершение слеш-нарушения валидатор теряет не менее 1/32 своего баланса и деактивируется («forced exit»).
Такое наказание может понести валидатор пытающийся использовать атаку “Double Spending”, то есть предложение более одного блока на назначенный ему слот.

Вычисления и распределение ресурсов

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

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

TON (The Open Network)

Источники: https://docs.ton.org/catchain.pdf , https://ton.org/ru/validator , https://ton.org/ru/stake , https://ton.org/ru/analysis , https://habr.com/ru/companies/mercuryo/articles/490392/ , https://habr.com/ru/companies/mercuryo/articles/479354/ 

TON Blockchain как и ETH2 тоже использует консенсус PoS, описанный выше, но в реализации есть свои особенности связанные с более сложной и продвинутой архитектурой , например время на финализацию блока в сети TON составляет около 5 секунд. О них подробнее далее.

Шардинг

Главным узлом TON является Мастерчейн, который состоит из множества Воркчейнов, которые в свою очередь разделяются на Шардчейны.

Для обозначения мастерчейна используется ID = -1.

На данный момент в сети запущен один воркчейн, называемый basechain. В нём происходит основная часть пользовательских транзакций. Транзакции здесь гораздо дешевле и его использует основная часть сервисов.

Первый воркчейн имеет ID = 0

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

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

Шардчейны всегда относятся к конкретному Воркчейну и имеют единое устройство и формат, в зависимости от воркчейна в котором они созданы.

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

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

Раз в ≈4 секунды создается новый блок в мастерчейне, в этот блок включаются транзакции, которые происходили в мастерчейне, а также последние блоки из всех шардчейнов. Выглядит это так:

За время создания 1 блока в мастерчейне, в шардчейне может быть создано несколько блоков, поэтому в блок мастерчейна попадает только ссылка на последний из них.

Алгоритм консенсуса

Консенсусная сеть TON состоит из различных типов узлов: валидаторы, номинаторы, фишеры и коллаторы.

Валидаторами являются узлы PoS и производители блоков. Фишеры следят за консенсус-сетью с целью найти ошибку или выявить предположительно злонамеренный узел консенсуса и в случае, если фишер однозначно подтвердит, что узел является таковым, он получает вознаграждение в виде конфискации части доли этого валидатора.

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

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

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

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

Далее валидаторам необходимо достигнуть консенсуса на основе алгоритма BFT (Византийский протокол отказоустойчивости), аналогичного протоколу pBFT или Honey Badger BFT. Затем, после достижения консенсуса, создается новый блок, при этом комиссии за транзакции распределяются между валидаторами.

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

После того, как все новые блоки шардов цепи сгенерированы или таймаут окончен, появляется сообщение о том, что создан новый блок мастерчейна, включающий в себя хэши последних блоков всех шардов на основе pBFT-консенсуса всех валидаторов.

Catchain и безопасность

Первоначальное название протокола на предварительном этапе исследования и разработки было Catch-chain (блокчейн-ловушка), поскольку по сути это отдельный блокчейн, предназначенный для перехвата нежелательных событий, затрудняющих достижение консенсуса в основном блокчейне TON. В дальнейшем его название было сокращено до Catchain.

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

1) Когда блоки создаются ДО достижения консенсуса (классические PoW, PoS и т.п. системы) с последующим сложным процессом согласования между участниками сети. При этом возможно одновременное существование нескольких “правильных” блокчейнов, из которых в дальнейшем выбирается одна истинная цепочка.
2) Когда блоки создаются ПОСЛЕ достижения консенсуса. В таких системах невозможно существование одновременно нескольких блокчейнов.

Catchain принадлежит ко второму типу алгоритмов, в которых предварительное согласование происходит до создания нового блока и промежуточные форки (разветвления) практически невозможны. Модель консенсуса Catchain основана на уже известном алгоритме practical Byzantine Fault Tolerance (Hyperledger Fabric, Zilliqa), обладающем повышенной стойкостью против атак Сивиллы в асинхронных сетях, а также имеет сходства с Tendermint (Cosmos) и алгоритмами dBFT (Neo, Algorand). Однако существует ряд принципиальных отличий, которые позволяют отнести его к отдельному классу алгоритмов.

Раунды валидации

Для конкретной задачи создания новых блоков одного из блокчейнов TON (мастерчейна или одного из активных шардчейнов) создается специальная группа, состоящая из нескольких валидаторов. Члены этой группы используются как для создания приватной оверлейной сети внутри ADNL, так и для запуска соответствующего экземпляра протокола Catchain.
Процесс достижения консенсуса состоит из нескольких раундов, которые выполняются внутри одного catchain. В один момент времени может проходить несколько раундов, поскольку одни этапы одного раунда могут пересекаться с другими.

Каждый раунд заканчивается либо коллективным принятием блока-кандидата, предложенного одним из участников процесса, либо принятием особого “нулевого кандидата”, т.е. не принятием ни одного из предложенных кандидатов. Раунд считается завершенным только после того, как потенциальный кандидат соберет подписи более чем 2/3 всех валидаторов и это событие может быть добавлено в специальный CommitSign, после чего процесс автоматически начинает участвовать в следующем раунде (с новым идентификатором).

События одного раунда валидации происходят в следующей последовательности:

В начале каждого раунда несколько валидаторов (из заранее составленного списка) предоставляют свои т.н. блок-кандидаты (с задержками в зависимости от приоритета) и фиксируют этот факт посредством Submit events в данный catchain.

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

Далее каждый валидатор голосует либо за кандидата, набравшего более 2/3 голосов, либо, если таких кандидатов еще нет, за действительного кандидата с наивысшим приоритетом. Голосование осуществляется путем создания событий голосования, встроенных в новые сообщения.

При каждой медленной попытке (т.е. любой попытке, кроме первой) процесс голосует либо за кандидата, который был предварительно принят (тем же самым процессом), либо за кандидата, который был предложен VoteFor.

Если в ходе такой попытки данный кандидат получил более 2/3 голосов «за», то создается следующее событие PreCommit, подтверждающее то, что все другие кандидаты отбрасываются.

Далее, если такой блок-кандидат собирает PreCommits более чем у 2/3 всех валидаторов внутри данной попытки, то он будет принят и отмечен событием CommitSign с действительной подписью блока.

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

Как только кандидат в блоки собирает подписи CommitSign более чем у 2/3 всех валидаторов, раунд считается завершенным и процесс автоматически начинает участвовать в следующем раунде, игнорируя все события, связанные другими раундами.

Защита от форков

Как уже говорилось выше, в блокчейнах с традиционными механизмами защиты посредством Proof-of-Work и Proof-of-Stake, а также их гибридами, какое-то непродолжительное время могут существовать несколько “правильных” цепочек блоков или форков, из которых потом выбирается одна.

Система TON Blockchain, построенная на основе множества небольших блокчейнов (multi-blockchain), практически не оставляет шансов для возникновения такого рода событий, т.к. использует блокчейн в качестве средства трансляции сообщений внутри определённой группы процессов. Однако, всё же существует небольшая вероятность создания и одновременного подтверждения нескольких идентичных блоков.

Именно для предотвращения таких сценариев как раз и создан протокол Catchain, который методом создания двух (или более) разных версий одного и того же сообщения и рассылки их разным группам пиров, позволяет выявить форки на самой ранней стадии их возникновения.

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

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

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

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

Наказания и Слешинг

В блокчейне TON обычно существует два способа наказания валидаторов за ненадлежащее поведение: бездействие и злонамеренное поведение; оба из которых запрещены и могут привести к штрафу (в процессе, называемом слешингом) за их действия.

Если валидатор не участвует в создании блоков и подписании транзакций в течение значительного времени во время раунда проверки, он потенциально может быть оштрафован с использованием параметра « Стандартный штраф» . По состоянию на апрель 2023 года начисленный стандартный штраф составляет 101 TON

TON планирует увеличить стандартный штраф для валидаторов к концу 2023 года.

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

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

Вычисления и распределение ресурсов

В сети TON эти показатели идентичны ETH2 и другим проектам на алгоритме PoS, только с поправкой на уникальный алгоритм шардов. 

SOLANA

Источники: https://solana.com/solana-whitepaper.pdf ,

Одной из ключевых отличительных особенностей Solana является ее система консенсуса Proof of Stake (PoS), которая подкрепляется чем-то, названным Tower Consensus. Это вариант системы, известный как Практическая Византийская Отказоустойчивость (PBFT), он позволяет распределенным сетям достигать консенсуса, несмотря на атаки со стороны вредоносных узлов.

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

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

Валидаторы 

В сети Solana участвуют следующие типы нод:

1. Лидер (Leader) - нода, выбранная алгоритмом консенсуса для генерации последовательности Proof of History. Обрабатывает и упорядочивает транзакции от пользователей, подписывает состояния.

2. Валидаторы - ноды, которые реплицируют состояние блокчейна, проверяют корректность блоков и голосуют в рамках алгоритма PoS.

3. Ноды репликации - хранят полную копию блокчейна и предоставляют данные по запросам. Генерируют доказательства репликации.

4. Пользователи - генерируют транзакции и отправляют их в сеть. 

5. Ноды PoH - генерируют последовательность хешей Proof of History, обеспечивающую временные метки.

Основные функции:

• Лидер: секвенирование транзакций, подпись состояний. 

• Валидаторы: валидация блоков, голосование, предложение обновлений.

• Ноды репликации: хранение данных, генерация PoRep.

• Пользователи: создание транзакций.

• Ноды PoH: генерация временных меток.

Такое разделение функций позволяет масштабировать сеть и обеспечивает проверки и баланс между разными участниками.

Как показано на рисунке 1, в любой момент времени один из узлов системы является Лидером, который создаёт PoH-последовательность, обеспечивая в сети глобальную согласованность чтения и проверяемый ход времени. 

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

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

Рисунок 1

В неразветвленной сети в любой момент времени в сети есть один Лидер. Каждый Проверяющий узел имеет те же аппаратные возможности, что и лидер, и может быть избран лидером, что делается с помощью выборов на основе PoS.

Алгоритм консенсуса

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

1. Пользователь отправляет транзакцию в сеть Solana. Транзакция имеет следующий формат:

• Последний валидный хеш 

• Счетчик

• Плата за транзакцию  

• Отправитель

• Подпись отправителя

2. Лидер сети (выбранный с помощью PoH и PoS) принимает транзакции от пользователей и упорядочивает их для эффективной обработки. 

3. Лидер выполняет транзакции и записывает их в PoH последовательность, гарантируя уникальный глобальный порядок.

4. После обработки пачки транзакций лидер вычисляет хеш состояния и подписывает его своим приватным ключом. 

5. Лидер распространяет транзакции, PoH последовательность и подписанный хеш состояния среди валидаторов.

6. Валидаторы получают эту информацию и выполняют те же транзакции локально, чтобы вычислить состояние. 

7. Валидаторы сверяют полученный хеш состояния с тем, что предоставил лидер. 

8. Если хеши совпадают, валидаторы подписывают хеш состояния и публикуют свои подписи как подтверждения. 

9. Когда имеется кворум подтверждений (2/3 от всего стейка), блок считается подтвержденным.

10. Валидаторы получают вознаграждение за успешное подтверждение блока. 

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

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

Негативные сценарии

Вот основные возможные атаки на систему Solana и механизмы защиты от них:

1. Атака с обратным порядком транзакций - злонамеренный лидер пытается сгенерировать альтернативную цепочку с обратным порядком транзакций. Защита - клиенты включают хеши предыдущих транзакций в свои транзакции.

2. Атака с фальсификацией транзакций - лидер изменяет данные транзакций. Защита - клиенты подписывают хеши транзакций своими ключами. 

3. Атака на основе скорости - злоумышленник генерирует альтернативную цепочку быстрее, чем основная сеть. Защита - использование нескольких лидеров для повышения скорости.

4. Долгосрочная атака - злоумышленник пытается переписать старые блоки с помощью старых ключей. Защита - механизм Proof of History затрудняет пересоздание long range-цепочек.

5. Атака с цензурой - злоумышленники отказываются голосовать за блоки с новыми транзакциями. Защита - постепенное списание ставок нод, отказывающихся от голосования.

6. Коллюзионная атака - валидаторы сговариваются с лидером и подтверждают невалидные блоки. Защита - лидер периодически отправляет специально сформированные невалидные блоки, чтобы наказать валидаторов, которые их подтверждают.

7. Атака отказа в обслуживании на репликацию - злоумышленник создает много ложных идентификаторов репликации. Защита - экономические издержки на создание идентификаторов репликации.

8. Атака "Трагедия общин" - валидаторы не проверяют Proof of Replication. Защита - экономические стимулы для валидаторов выполнять проверку.

9. ASIC-атаки на майнинг и голосование за счет применения специализированных чипов. Защита - алгоритм Proof of History усложняет применение ASIC.

Наказания и правила

Для валидаторов в системе Solana предусмотрен ряд правил и возможных негативных сценариев:

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

2. Валидаторы обязаны голосовать за валидные блоки путем подписания хешей состояний. Если валидатор пропускает голосование в течение некоторого времени, его ставка будет списана.

3. Если валидатор голосует одновременно на нескольких ветках (форках), это считается "двойным голосованием" и наказывается списанием ставки.

4. Валидатор не должен голосовать за невалидные блоки. Если он подтверждает блок с неверным хешом состояния, его ставка будет списана.

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

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

7. Злонамеренное меньшинство, отказывающееся голосовать за блоки с новыми ставками, будет в конечном итоге отсечено, когда их ставки истекут.

8. Валидаторы могут предлагать обновления протокола через механизм управления в сети. 

9. Валидаторы получают вознаграждение за успешное голосование в виде части комиссии за транзакции.

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

Вычисления и распределение ресурсов

Для нахождения консенсуса в системе выполняются следующие этапы:

1. Proof of History - генерация последовательности хешей, которая подтверждает временную последовательность событий. Этот процесс требует значительных вычислительных ресурсов, так как необходимо выполнять множество итераций хеширования. По оценкам документа, генерация 4000 хешей в секунду потребует доступа к GPU с 4000 ядрами и 0.25-0.75 мс времени на верификацию.

2. Пользовательские транзакции обрабатываются лидером сети и упорядочиваются для эффективной обработки. Этот этап ограничен пропускной способностью сети, в документе приводится оценка в 710 000 транзакций в секунду при 1 Гбит/с.

3. Валидаторы реплицируют состояние блокчейна и обеспечивают высокую доступность. Этот этап ограничен вычислительной мощностью валидаторов, экспериментально была достигнута скорость 900 000 ECDSA операций в секунду на GPU.

4. Происходит голосование валидаторов в рамках алгоритма Proof of Stake для подтверждения блоков. Каждый валидатор должен подтвердить хеш состояния в течение 500 мс.

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

Таблица сравнения моделей консенсуса ЕTH2, TON, SOLANA