---
title: "Финальность блокчейна: доказательства, допущения и уровни расчёта"
description: "Финальность — это гарантия конкретного протокола, что решение не будет заменено без нарушения допущений безопасности или чрезвычайного восстановления. Валидность, выбор ветви, доказательство финальности, пределы отказов, зависимости уровней и расчёт приложения нужно анализировать отдельно."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Финальность блокчейна: доказательства, допущения и уровни расчёта
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Финальность — это гарантия конкретного протокола, что принятое решение, например блок, контрольная точка или обязательство состояния, не будет заменено без нарушения заявленных допущений безопасности либо чрезвычайной процедуры восстановления. Это не физическое свойство байтов транзакции и не просто «транзакция выполнена успешно». В утверждении необходимо назвать объект, сеть, версию протокола, доказательства, модель отказов и времени, доверенную исходную точку и наблюдателя.
Валидность, каноничность и финальность различны. Валидный блок удовлетворяет правилам перехода состояния и авторизации. Правило выбора ветви выбирает текущую каноническую вершину среди валидных кандидатов. Финализация применяет дополнительный предикат, например сертификат коммита или финализированную контрольную точку, к предку этой вершины. Транзакция может успешно выполниться в валидном блоке, который позднее проиграет выбор ветви; вершина может быть канонической, но не финальной; а финальное событие исходной сети всё ещё может завершиться ошибкой в мосте, бирже или приложении.
Proof of Work обычно даёт вероятностный расчёт, а не явный бит финальности: чем больше валидной совокупной работы накоплено поверх блока, тем менее вероятной и более дорогой становится его замена при заданных допущениях о хешрейте и сети. BFT-протокол может давать условную детерминированную финальность: после валидного сертификата два конфликтующих решения не могут быть одновременно закоммичены, если ошибочный вес остаётся ниже доказанного предела. Финальность PoS может быть также подотчётной или экономической, поскольку конфликтующие голоса выявляют вес, подлежащий слешингу. Эти термины описывают разные доказательства.
Ни один протокол не делает историю абсолютно неизменной. Катастрофическая компрометация ключей, нарушение предела отказов, ошибки клиентов, принятые реализациями невалидные переходы, вмешательство управления или социальное восстановление способны выйти за границы модели. «Финализировано» должно означать, что обычный путь реорганизации протокола не может заменить это решение при данных допущениях; чрезвычайное восстановление и полномочия на него документируются отдельно.
## Как анализировать финальность
1. **Назовите объект и область.** Определите транзакцию, блок, контрольную точку, корень состояния, межсетевое сообщение или вывод; зафиксируйте цепь, сеть, уровень, версию, высоту или слот, хеш блока и доверенную контрольную точку.
2. **Проверьте валидность до статуса.** Повторно выполните или иначе проверьте соответствующий переход состояния и происхождение. По реальным правилам кворум, оценка работы или значок интерфейса не могут финализировать невалидный объект.
3. **Разделите выбор вершины и финализацию.** Воспроизведите выбор ветви и текущий канонический путь, затем найдите финализированного или закоммиченного предка. Запишите, является ли статус лишь наблюдаемым, подтверждённым, оправданным, безопасным, закоммиченным или финальным.
4. **Воспроизведите доказательство.** Для PoW проверьте заголовки, цель и совокупный chainwork над блоком. Для голосования проверьте право подписи, снимок весов, домен сообщения, источник и цель, высоту, раунд, неравенство кворума, подписи, блокировки и происхождение сертификата.
5. **Укажите допущения safety и liveness.** Зафиксируйте византийский или офлайн-вес, синхронность, задержку, двойное голосование, компрометацию ключей, корреляцию клиентов, смену состава, доступность слешинга и поведение при остановке. Остановка может сохранить safety, но потерять liveness.
6. **Сопоставьте все уровни расчёта.** Проследите получение секвенсором, исполнение L2, публикацию данных, включение L1, финальность L1, завершение доказательства или спора, исполнение моста, зачисление биржей и действие приложения. Похожие метки на разных уровнях не обязательно означают один предикат.
7. **Задайте и контролируйте политику приложения.** Определите допустимые доказательства по стоимости и последствиям, опрашивайте независимые узлы, обрабатывайте реорганизации и тревоги о конфликтующей финальности, при нарушении допущений останавливайте необратимые действия и фиксируйте полномочия на восстановление.
Число подтверждений — наблюдение, а не универсальное правило финальности. В Bitcoin Core значение `confirmations` зависит от позиции блока в текущей активной цепи, а `chainwork` отражает совокупную ожидаемую работу. В Ethereum выбор вершины LMD-GHOST и оправдание и финализация контрольных точек Casper FFG — разные переходы состояния. В CometBFT коммит требует precommit более двух третей голосующего веса за один блок на одной высоте и в одном раунде. Каждый статус нужно понимать в рамках его протокола.
## Расчётные примеры
### 1. Вероятностный расчёт Proof of Work
В white paper Bitcoin смоделирован атакующий с долей хешрейта `q=0.10`, пытающийся догнать честную цепь после отставания `z=6`. При допущениях независимых попыток хеширования и распределения Пуассона рассчитанная вероятность догнать равна:
`P=0.0002428 = 0.02428%`
Результат мал, но не равен нулю и не является универсальной «гарантией шести подтверждений». Реальная политика должна учитывать стоимость транзакции, наблюдаемый chainwork, концентрацию хешрейта, риск eclipse-атаки или разделения сети, стимулы комиссий и правдоподобность постоянной доли атакующего.
### 2. Оправдание и финализация Ethereum
Рассмотрим упрощённый путь последовательных контрольных точек с общим активным эффективным балансом `100`. Голоса `67/100`, связывающие оправданную точку `C_0` с целью `C_1`, достигают как минимум двух третей и оправдывают `C_1`. Последующая допустимая связь `67/100` от `C_1` к непосредственному потомку `C_2` может финализировать `C_1` по применимому правилу Casper FFG.
Вершина может уйти дальше `C_2`, пока новая часть остаётся нефинальной. Если баланс `34` офлайн, остаётся лишь `66`, и немедленная финализация останавливается, хотя выбор ветви и выпуск блоков могут продолжаться. После более четырёх эпох без финальности inactivity leak Ethereum начинает штрафовать неучастие, чтобы активное сверхбольшинство со временем восстановило финальность.
### 3. Safety и liveness в CometBFT
Пусть общий голосующий вес равен `100`, а коммит требует `>2/3` precommit за один блок на одной высоте и в одном раунде. Целочисленного веса `67` достаточно. Любые два множества коммита весом 67 пересекаются как минимум на `67 + 67 - 100 = 34`. Если византийский вес меньше трети и честные валидаторы соблюдают блокировки, два конфликтующих коммита невозможны.
Если вес `34` недоступен, голосовать может только `66`, поэтому коммит не образуется. Протокол может сохранять safety при остановке финальности. «Нет конфликтующего финального блока» и «новые блоки продолжают финализироваться» — разные гарантии.
### 4. Статусы OP Stack и сроки вывода
Секвенсор OP Stack может сначала показать блок L2 как `unsafe`. Когда блок полностью выводится из данных текущей канонической цепи L1, rollup-узел может пометить его `safe`. Когда соответствующие входы L1 получают сигнал финальности L1, производный блок L2 может стать `finalized`.
Этот статус касается вывода из финальных входов. Выход optimistic rollup или вывод из L2 в L1 имеет отдельную процедуру доказательства и спора и может называться «финализированным» лишь после выполнения условия оспаривания. Приложение, сводящее подтверждение секвенсора, включение данных L1, финальность консенсуса L1 и исполнение вывода к одному моменту, может освободить средства слишком рано.
## Риски и ошибки проверки
### Определение и доказательства
- Называть «финальным» любое успешное исполнение, квитанцию, подтверждение, checkpoint или значок интерфейса.
- Не указывать цепь, сеть, версию, хеш объекта, высоту или слот, уровень и наблюдателя.
- Считать текущую вершину fork choice финальным предком или полагать, что финализация выбирает новейшую вершину.
- Считать блоки или минуты без проверки происхождения, целей, работы, голосов или сертификатов.
- Сравнивать «два подтверждения» или «десять минут финальности» у протоколов с разными доказательствами и отказами.
- Проверять подписи без права подписи, веса, домена, источника, цели, высоты и раунда.
- Приравнивать экономическую стоимость, слешинговое доказательство и фактическое применение штрафа.
- Представлять вероятностный риск нулевым, а условную детерминированную safety — безусловной необратимостью.
### Сбои протокола и эксплуатации
- Превысить византийский предел, потерять онлайн-вес для liveness или скрыть разделение сети.
- Допустить расхождение реализаций в валидности, fork choice, переходах, округлении кворума или происхождении сертификата.
- Принимать устаревшие, повторные или чужие для сети голоса, коммиты, checkpoints либо данные weak subjectivity.
- Сконцентрировать ключи, stake, хешрейт, клиенты, ретрансляторы, облака или RPC-представления за формально разными лицами.
- Полагать, что inactivity leak, timeout или смена view мгновенно и без последствий восстановят прогресс.
- Не оповещать о задержке финальности, конфликтующих сертификатах, глубокой реорганизации, двойном голосовании или расхождении финальных корней.
- Применять чрезвычайное управление или социальное восстановление без описания полномочий, координации, релиза клиентов и затронутых гарантий.
### Несоответствие уровней и приложения
- Считать включение секвенсором одновременно safety L2, публикацией L1, финальностью L1, принятием доказательства и завершением вывода.
- Разблокировать активы моста до выполнения политик событием источника и собственным путём проверки моста.
- Зачислять депозит или исполнять необратимую сделку по статусу одного RPC без независимой сверки.
- Полагать, что финальность цепи гарантирует истинность оракула, корректность контракта, доступность данных, платёжеспособность биржи или юридический расчёт.
- Применять один фиксированный порог к любой сумме, контрагенту, стимулу атаки и стоимости восстановления.
## Распространённые заблуждения
- **Успешная транзакция уже финальна.** Успех описывает один переход в истории-кандидате; каноничность и финальность требуют дополнительных доказательств.
- **Больше подтверждений делает риск PoW точно нулевым.** Вероятность модели может резко снизиться, но остаётся условной и не превращается в логическую невозможность.
- **Две трети всегда означают финальность.** Неравенство, тип сообщения, веса, высота, раунд, связь источника и цели и блокировка зависят от протокола.
- **Финальность гарантирует дальнейшую работу сети.** Safety может сохраниться, хотя недостаток участия или связи препятствует новой финализации.
- **Финальность L1 завершает любое действие L2 или моста.** Вывод данных, доказательство валидности или мошенничества, окно оспаривания и исполнение назначения добавляют отдельные сроки и отказы.
## Связанные темы
- [Подтверждения блока](/ru/crypto/block-confirmation/)
- [Реорганизации цепи](/ru/crypto/chain-reorg/)
- [Механизмы консенсуса](/ru/crypto/consensus-mechanism/)
- [Правила выбора ветви](/ru/crypto/fork-choice-rule/)
- [Слабая субъективность](/ru/crypto/weak-subjectivity/)
## Источники
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (дата обращения: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (дата обращения: 2026-08-19)
- [Bitcoin Core RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project (дата обращения: 2026-08-19)
- [Ethereum Proof-of-Stake Consensus](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (дата обращения: 2026-08-19)
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (дата обращения: 2026-08-19)
- [Ethereum Proof-of-Stake Rewards and Penalties](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (дата обращения: 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (дата обращения: 2026-08-19)
- [OP Stack Derivation Specification](https://specs.optimism.io/protocol/derivation.html) - Optimism (дата обращения: 2026-08-19)
Source: https://wiki.fcontext.com/ru/crypto/finality/index.mdx