Что такое уровни подтверждения Solana?

Что такое уровни подтверждения Solana?

Уровни подтверждения Solana — это стандартизированный способ измерить консенсус сети по конкретному блоку или транзакции. Запрашивая статус транзакции или данные аккаунта у RPC-ноды Solana (например, через getTransaction), вы можете указать желаемую степень окончательности данных. С помощью уровня подтверждения Solana позволяет клиентам выбирать баланс между задержкой и уверенностью: низкий уровень быстрее предоставляет результат, а высокий дает разработчикам более надежные гарантии того, что состояние не будет отменено.

Solana определяет три основных уровня подтверждения в порядке убывания окончательности:

Finalized

Высший уровень уверенности. Он означает, что блок подтвержден квалифицированным большинством стейка (≥66 %) и поверх него создан как минимум 31 дополнительный подтвержденный блок. Таким образом, слот достигает максимального lockout после 32 голосов. Транзакция со статусом finalized фактически необратима.

Confirmed

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

Processed

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

Эти уровни представляют этапы жизненного цикла транзакции. 

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

Рассмотрим каждый уровень подробнее.

Уровень подтверждения Processed

Транзакция получает статус Processed, как только нода валидатора, то есть текущий лидер, включает ее в блок. Это самое раннее подтверждение: транзакция получена и локально включена в состояние реестра.

Основные характеристики уровня Processed:

• Включение в блок: транзакция находится в блоке, созданном валидатором.
• Нет гарантии попадания в ветку большинства: этот блок может попасть или не попасть в ветку большинства — самую длинную или тяжелую.
• Самый быстрый результат: уровень сразу сообщает, что нода обработала транзакцию. Это удобно для быстрых обновлений на стороне клиента, например для отображения ожидающей транзакции в интерфейсе кошелька.
• Неполная безопасность: на этом этапе нет гарантии, что другие валидаторы увидели блок или проголосовали за него. Кластер все еще может «пропустить» этот блок или заменить его альтернативной веткой. Иными словами, Processed означает, что транзакция включена, но еще не подтверждена другими участниками.

Пример блока Processed: 

Предположим, Алиса отправляет перевод в Solana. Как только текущий лидер добавляет его в блок (слот N), транзакция получает статус Processed. Кошелек Алисы может сразу показать транзакцию как ожидающую/обработанную. 

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

Уровень подтверждения Confirmed

Уровень подтверждения Confirmed означает, что блок транзакции принят квалифицированным большинством кластера и с высокой вероятностью находится в канонической цепочке. С технической точки зрения confirmed означает, что за блок напрямую проголосовали валидаторы, представляющие ≥66% стейка. 

Основные характеристики:

• В ветке большинства: блок с транзакцией признан частью ветки большинства в реестре. Это означает, что сеть считает его каноническим.

• Голоса квалифицированного большинства: за подтверждение блока проголосовали участники, представляющие не менее двух третей общего стейка. Эти голоса собираются с помощью механизма gossip: валидаторы транслируют голоса за блок по сети и получают их от других участников. На этом этапе используется оптимистичное подтверждение, появившееся в Solana v1.3. Оно позволяет нодам считать блок подтвержденным сразу после того, как за него проголосовало квалифицированное большинство, еще до финализации.

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

• Быстрее Finalized: статус confirmed обычно присваивается вскоре после того, как блок или транзакция получает статус processed, — в течение одной-двух секунд, поскольку валидаторы быстро голосуют за новые блоки. Ожидать множество последующих блоков не нужно. Поэтому в обычных условиях confirmed обеспечивает хороший баланс скорости и уверенности.

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

Пример блока Confirmed: 

Транзакция Алисы из предыдущего примера получает статус Confirmed, когда валидаторы кластера голосуют за блок N. На практике, если следующие несколько валидаторов в слотах N+1, N+2 и далее голосуют и видят блок N, достигается порог 66%, и сеть помечает блок N как подтвержденный. Теперь кошелек Алисы может безопасно показать пользователю статус транзакции подтверждена. 

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

Уровень подтверждения Finalized

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

Характеристики Finalized:

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

• Квалифицированное большинство + lockout: как и для Confirmed, блок поддержали участники, представляющие не менее 66% стейка. Кроме того, после него добавлен как минимум 31 последующий подтвержденный блок. Иными словами, поверх блока сеть построила глубокую цепочку и достигла глубины lockout, при которой реорганизация практически невозможна.

• Максимальный lockout (32 голоса): механизм Tower BFT в Solana экспоненциально удваивает период lockout голосов. Когда блок накапливает 32 голоса в tower, то есть остается во главе ветки еще 32 слота, он достигает максимального lockout и финализируется. После этого любой валидатор, пытающийся проголосовать за альтернативную ветку, нарушит правила консенсуса.

• Максимальная безопасность, самое медленное подтверждение: финализация обычно отстает от уровней processed и confirmed примерно на ~10–20 секунд в нормальных условиях, поскольку 32 слота по ~400 мс составляют около 13 секунд. Это плата за уверенность Finalized. Ожидая финализации, клиенты полностью исключают риск отбрасывания или отмены транзакции ценой дополнительной задержки.

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

Пример блока Finalized:

Транзакция Алисы получает статус Finalized, когда сеть продолжает создавать блоки после слота N. Предположим, к слоту N+32 квалифицированное большинство валидаторов проголосовало за каждый последовательный блок вплоть до N+32, и ни один форк не победил. Теперь блок N с транзакцией Алисы финализирован. 

На этом этапе транзакция Алисы навсегда остается в реестре Solana. Сколько бы времени ни прошло, состояние с ее переводом не изменится. 

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

Устаревшие уровни подтверждения

Ранние версии Solana, выпущенные до 2021 года, предоставляли дополнительные уровни подтверждения. Позднее они были признаны устаревшими в пользу трех описанных выше.

Для полноты перечислим прежние термины и их соответствие текущим уровням:

• recent — устарел; эквивалентен Processed. В старой документации recent обозначал последнее состояние, известное ноде.

• single и singleGossip — устарели; эквивалентны Confirmed. Они обозначали подтверждение одним валидатором или через gossip, что соответствует определению confirmed.

• root и max — устарели; эквивалентны Finalized. Root обозначал корневое состояние, финализированное в кластере, а max — максимальный lockout. Оба термина фактически означали finalized.

Сегодня при указании уровня подтверждения разработчикам следует использовать только processed, confirmed или finalized. Начиная с версии 1.5.5, Solana JSON-RPC API по умолчанию использует эти термины, а устаревшие варианты считает псевдонимами соответствующих уровней. 

Кроме того, если в RPC-запросе не указан уровень подтверждения, по умолчанию используется Finalized, то есть нода возвращает наиболее финализированное состояние.

Различия между уровнями подтверждения

Различия между Processed, Confirmed и Finalized определяются тем, какая доля сети признала транзакцию и насколько вероятна ее отмена. В таблице ниже, составленной на основе официальной документации Solana, представлены основные различия:

Итак, Processed означает только то, что транзакция находится в блоке. Confirmed означает, что кластер согласовал этот блок голосами квалифицированного большинства, но он все еще расположен близко к вершине цепочки. Finalized означает, что блок находится глубоко в цепочке и имеет много подтверждений, поэтому фактически неизменяем.

Различия также можно рассматривать с точки зрения вероятности того, что транзакция со временем останется в каноническом реестре. 

Сразу после обработки эта вероятность ниже 100% из-за риска форка или сбоя. После подтверждения участниками с долей стейка более 66% вероятность включения резко возрастает. Когда блок финализирован и поверх него созданы десятки других блоков, вероятность включения составляет ~100%. 

Это показано на графике ниже: вероятность финализации транзакции возрастает по мере прохождения слотов и повышения уровня подтверждения.

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

Как Solana определяет уровни подтверждения?

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

Proof of History (PoH) и создание блоков

Лидеры Solana быстро и последовательно создают блоки: по одному лидеру на слот продолжительностью ~400 мс. Транзакции передаются в хеш-цепочку Proof of History (PoH), формируя записи в блоке. Блоки быстро распространяются по сети через Turbine, протокол распространения блоков Solana. Когда лидер создает блок с вашей транзакцией, он сразу распространяется по сети, но еще не подтвержден. Это соответствует этапу Processed.

Голосование (Tower BFT)

Solana использует алгоритм BFT-консенсуса Tower BFT. Валидаторы, каждый из которых контролирует определенный стейк, голосуют за блоки, которые, по их мнению, должны стать следующей частью реестра. Сами голоса являются транзакциями Solana и используют концепцию lockout. Каждый раз, когда валидатор голосует за блок в слоте N, для него устанавливается lockout. Если позднее он проголосует за конфликтующую ветку, то может на некоторое время потерять возможность голосовать. 

Эти периоды lockout экспоненциально удваиваются с каждым последующим голосом за одну и ту же ветку: 1, 2, 4, 8... слотов lockout, вплоть до предела в 32 голоса. Если валидатор 32 раза подряд проголосовал за одну ветку, то есть блок 32 слота назад по-прежнему входит в самую тяжелую ветку, этот блок достигает максимального lockout. Такой механизм стимулирует валидаторов придерживаться ветки большинства и финализировать блоки.

Подтверждение (оптимистичное подтверждение)

После создания блока валидаторы транслируют голоса за него. Как только за блок проголосует квалифицированное большинство стейка (≥66%), ноды Solana считают его оптимистично подтвержденным. Это уровень подтверждения Confirmed. Он достигается быстро, часто в течение одного-двух слотов после блока, поскольку голоса распространяются через gossip. 

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

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

Финализация (укоренение блока)

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

По аналогии с PoW-цепочкой, уровень подтверждения Finalized фактически соответствует условию «блок получил ≥32 подтверждений», но Solana достигает этого с помощью голосов с временной блокировкой, а не подтверждений proof-of-work. Правило 32 слотов обусловлено архитектурой Tower BFT, где lockout удваивается до 2^32, и математически гарантирует окончательность при условии устойчивости к сбоям одной трети участников.

Выбор ветки и откат

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

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

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

Кратко о механике: Processed — блок создан с помощью PoH, но еще не получил широкую поддержку голосами; Confirmed — голоса кластера в Tower BFT достигли квалифицированного большинства по этому блоку, обеспечив оптимистичный консенсус; Finalized — блок сохранился как «корень» цепочки после множества дополнительных голосов, обеспечив абсолютную окончательность консенсуса. Архитектура Solana гарантирует, что подтвержденные блоки финализируются после небольшой задержки, сочетая быстрое подтверждение с последующей абсолютной окончательностью.

Сценарии использования каждого уровня подтверждения

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

Ниже приведены типичные сценарии и рекомендации для каждого уровня:

Используйте Processed для мгновенного результата и некритичных операций

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

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

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

Используйте Confirmed для большинства транзакций

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

Например, DeFi-приложение при обмене токенов или пользователь при переводе средств обычно полагаются на статус confirmed. После подтверждения транзакции приложение в штатной ситуации может считать ее завершенной. По сравнению с Processed этот уровень значительно снижает вероятность отбрасывания транзакции. Рекомендуется использовать уровень Confirmed, особенно при запросе недавних хешей блоков и отправке транзакций, поскольку он обеспечивает оптимальный баланс задержки и безопасности.

Используйте Finalized для крупных и критичных транзакций

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

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

Еще один сценарий — завершение серии транзакций. Перед признанием сложной операции завершенной можно убедиться, что итоговое состояние финализировано, например в процессе аудита или расчетов, где требуется окончательное состояние реестра. 

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

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

Многие приложения сочетают эти уровни: обновляют интерфейс при Processed, считают операцию завершенной при Confirmed и записывают ее в журнал при Finalized.

Влияние на надежность, производительность и безопасность транзакций

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

Надежность

Более высокие уровни подтверждения повышают вероятность того, что транзакция навсегда останется в реестре. Надежность финализированной транзакции фактически составляет 100%, если не учитывать чрезвычайные события. У подтвержденной транзакции она очень высока, но ниже 100%, а у обработанной — еще ниже. 

Как отмечалось выше, если учитывать только статус processed, около ~5% транзакций могут быть отброшены из-за смены форков. Статус confirmed снижает этот риск почти до 0%. 

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

Производительность (задержка)

Между скоростью получения подтверждения и его уровнем существует очевидный компромисс. 

Подтверждение Processed поступает почти мгновенно: в пределах времени создания блока, часто менее чем за секунду. 

Confirmed добавляет небольшую задержку на сбор голосов валидаторов — порядка одного-двух слотов, то есть еще ~0,5–1 секунду. Этот уровень все равно работает очень быстро, и пользователи обычно не замечают задержку. 

Finalized создает самую большую задержку, поскольку транзакция будет помечена как финализированная только после создания примерно 30 последующих блоков. Обычно для достижения окончательности требуется ~10–20 секунд. 

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

Пропускная способность и срок действия

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

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

Более свежий хеш блока со статусом Confirmed дает больше времени. Официальная рекомендация — использовать Confirmed для getLatestBlockhash, чтобы снизить риск истечения срока действия. 

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

Иными словами, при высокой нагрузке уровень Finalized может снизить живучесть: вы повышаете уверенность, но рискуете получить больше тайм-аутов транзакций, если сеть работает почти на пределе пропускной способности.

Безопасность

С точки зрения безопасности, например защиты от двойного расходования и форков, Finalized — самый надежный уровень. 

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

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

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

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

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

Итак, по уровню защиты от форков и двойного расходования: Finalized > Confirmed > Processed.

Уровень подтверждения при чтении и записи

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

Для запросов записи, то есть отправки транзакций, уровень подтверждения в основном определяет, как клиентская библиотека ожидает подтверждения. Распространенная схема — отправить транзакцию с определенным preflightCommitment, который может имитировать выполнение TX в последнем состоянии, а затем вызвать confirmTransaction с тем же уровнем подтверждения. При необходимости разработчики могут дождаться финализированного подтверждения.

Приведем реальные показатели: согласно недавним измерениям, Solana обрабатывала транзакцию примерно за ~0,4 секунды, достигала состояния confirmed примерно за ~0,6 секунды, а финализации — примерно за ~13 секунд. 

Если ваше приложение, например платежный сервис, не может ждать ~13 секунд для каждой транзакции, используйте confirmed: этот уровень все равно обеспечивает высокую безопасность. 

При переводе крупной суммы между цепочками можно подождать все ~13 секунд для полной уверенности. Если же вы разрабатываете решение, где критична скорость и допустим небольшой риск, например оптимистично обновляете интерфейс, статус processed поможет обеспечить быстрый отклик.

Заключение

Уровни подтверждения Solana — Processed, Confirmed и Finalized — это ключевой механизм, позволяющий разработчикам выбирать подходящий баланс скорости и уверенности для каждой транзакции.

Processed немедленно предоставляет результат с низкой уверенностью. Confirmed за одну-две секунды дает почти окончательное подтверждение, достаточное для большинства приложений. Finalized обеспечивает абсолютную окончательность спустя дополнительное время. 

На внутреннем уровне эти статусы соответствуют этапам достижения консенсуса Solana: от создания блока до голосования квалифицированного большинства и закрепления блока в реестре с максимальным lockout.

При разработке на Solana важно выбирать подходящий уровень подтверждения для каждой задачи:

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

Каждый уровень влияет на надежность включения транзакции и продолжительность ожидания. 

Понимая технические принципы — 66% голосов, 32 блока, форки и lockout — и следуя актуальным рекомендациям, разработчики могут получить обещанную Solana производительность, не жертвуя согласованностью и безопасностью своих приложений.

Дополнительные ресурсы

• Документация Solana — Настройка подтверждения состояния, Таблица статусов подтверждения
• Блог Helius — Консенсус в Solana (механика консенсуса и окончательности)