---
title: "Подтверждения блоков"
description: "Практическое руководство по проверке глубины подтверждения в PoW, состояний safe и finalized в PoS, замены транзакций в мемпуле, реорганизаций и правил зачисления биржевых депозитов."
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.
# Подтверждения блоков
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Подтверждение блока означает, что с точки зрения конкретного наблюдателя и протокола транзакция включена в блок текущей канонической цепочки этого наблюдателя. В распространенном инклюзивном соглашении Bitcoin Core блок включения считается первым подтверждением: при высоте включения `h` и высоте лучшей цепочки `H` глубина равна `H - h + 1`. Некоторые сервисы показывают только последующие блоки как `H - h`, поэтому соглашение о подсчете нужно указывать явно.
Глубина в Proof-of-Work снижает риск реорганизации при заданных предпосылках, но не создает магической точки абсолютной финальности. Системы Proof-of-Stake могут вместо этого предоставлять собственные протокольные состояния. Ethereum различает `latest`, `safe` и `finalized`; фиксированное число блоков, слотов или прошедших минут не заменяет эти метки. Состояния обнаружения, зачисления, доступности для торговли и доступности для вывода на платформе остаются отдельными внутренними правилами даже после достижения сетевого порога.
## Как это работает
1. Зафиксируйте цепочку и сеть, актив, идентификатор транзакции, узел или API, время наблюдения, модель консенсуса и соглашение о подсчете. Прежде чем считать совпавший хеш искомым платежом, проверьте получателя, сумму и memo или tag, если они нужны.
2. Разделяйте подписанную, отправленную, принятую локальным мемпулом одного узла и распространенную транзакцию. Мемпулы отражают локальную политику, а не глобальную очередь консенсуса. Проверьте комиссию, неподтвержденных предков, Replace-by-Fee или замену с тем же nonce и конфликтующие расходы.
3. Проверяйте включение по хешу и высоте блока, индексу транзакции и канонической цепочке предков, а не только по высоте или значку обозревателя. В цепочках со счетами проверяйте также статус квитанции, журналы и фактическое изменение состояния: включенное исполнение все равно может завершиться откатом.
4. Применяйте соответствующую модель консенсуса. Для PoW объявите соглашение о подсчете, вычислите глубину и сопоставьте независимые представления лучшей цепочки и накопленной работы. Для PoS запрашивайте нативные состояния головы, безопасности, обоснованности или финальности; не выводите их из фиксированного расстояния в блоках или слотах.
5. Отслеживайте жизненный цикл как явные состояния: создана, отправлена, принята локальным мемпулом, включена, имеет каноническую глубину либо статус safe или finalized, затронута реорганизацией, включена повторно, заменена или конфликтует. Реорганизация не гарантирует возврат исходной транзакции во все мемпулы.
6. Ведите реестр платформы отдельно: обнаружено, сетевой порог достигнут, зачислено, доступно для торговли и доступно для вывода. Применяйте действующие правила площадки для конкретного актива, сети, суммы и инцидента; техническое обслуживание, комплаенс и ручная проверка могут создавать независимые задержки.
7. Сверяйте независимые узлы или провайдеров и продолжайте мониторинг до требуемого состояния. Записывайте хеши, высоты, метки времени, метки RPC и снимок правил; заранее отрабатывайте замену, реорганизацию, задержку финальности, устаревший узел, ретрансляцию мостом и недоступность платформы.
## Разбор примеров
- **Соглашение о подсчете.** Транзакция Bitcoin находится в каноническом блоке `h = 900,000`, а вершина лучшей цепочки равна `H = 900,005`. Инклюзивная глубина составляет `900,005 - 900,000 + 1 = 6 confirmations`, а интерфейс, считающий только последующие блоки, покажет `900,005 - 900,000 = 5`. Разница терминологическая, если оба значения относятся к одному хешу блока и одной цепочке предков.
- **Реорганизация и повторное включение.** Сначала транзакция имеет `1 confirmation` в блоке `900,000`, затем этот блок покидает лучшую цепочку, и значение возвращается к `0`, если транзакция остается действительной и не конфликтует. Если она повторно включена на высоте `900,003`, а вершина достигает `900,006`, инклюзивная глубина составляет `900,006 - 900,003 + 1 = 4 confirmations`. Если ее вытеснила подтвержденная конфликтующая транзакция, Bitcoin Core может вместо этого показать отрицательное число подтверждений.
- **Метки PoS не являются числом блоков.** Допустим, транзакция Ethereum находится в блоке исполнения `20,000,000`, а узел сообщает `latest = 20,000,020`, `safe = 20,000,012` и `finalized = 19,999,980` в одной цепочке предков. Числовая глубина относительно latest равна `20,000,020 - 20,000,000 + 1 = 21`: транзакция безопасна, но еще не финализирована. Нужны проверка хешей и метки консенсусного клиента; одних высот недостаточно.
- **Сетевой порог и зачисление платформой.** Правила площадки требуют `6 confirmations`. Депозит в блоке `900,000` имеет статус `5/6` при вершине `900,004` и достигает `6/6` при `900,005`. Если затем площадка устанавливает `15-minute compliance hold`, сетевая пригодность и моменты внутреннего зачисления, допуска к торговле и выводу остаются разными состояниями; задержка не является седьмым подтверждением.
## Риски
- Проверка не той цепочки, сети или актива.
- Неверный хеш транзакции, получатель, memo или tag.
- Подписанная, но не отправленная транзакция считается ожидающей.
- Мемпул одного узла принимается за глобальное состояние сети.
- Пропущены отказ политики, вытеснение или отсутствие распространения.
- Не замечена замена RBF, с тем же nonce или конфликтующая замена.
- Неверно учтены неподтвержденные предки, потомки или пакетные комиссии.
- Смешаны инклюзивный подсчет и подсчет только последующих блоков.
- Доверие устаревшему, синхронизирующемуся или изолированному узлу.
- Сравнение высот без проверки хешей блоков и цепочки предков.
- Потеря подтверждений при короткой реорганизации PoW.
- Фиксированная глубина считается абсолютной защитой для любой суммы и противника.
- Смешиваются прошедшее время, слоты, эпохи и созданные блоки.
- Головной блок PoS считается безопасным.
- Безопасный блок считается финализированным.
- Не замечена задержка финальности при продолжающемся создании блоков.
- Включенное, но откатившееся исполнение считается успехом приложения.
- Журналы токена или интерфейс обозревателя смешиваются с итоговым состоянием.
- Обнаружение депозита, зачисление, торговля и разрешение вывода считаются одним состоянием.
- Подтверждение исходной цепочки считается завершением работы моста, эмитента или целевой системы.
## Распространенные заблуждения
- Доступный для поиска хеш транзакции или запись в локальном мемпуле уже означают подтверждение.
- Одно соглашение о подсчете и порог в шесть подтверждений применимы к любой цепочке, сумме и сервису.
- Более высокая комиссия ускоряет появление последующих блоков или финальность PoS.
- Фиксированное число блоков или слотов Ethereum эквивалентно `safe` или `finalized`.
- Включение в цепочку или финальность гарантирует успешное исполнение контракта, правильность реквизитов, зачисление платформой или завершение работы моста.
## Связанные темы
- [Мемпул](/ru/crypto/mempool/)
- [Bitcoin](/ru/crypto/bitcoin/)
- [Финальность](/ru/crypto/finality/)
## Источники
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (дата обращения: 2026-08-13)
- [Payment Processing](https://developer.bitcoin.org/devguide/payment_processing.html) - Bitcoin Developer Documentation (дата обращения: 2026-08-13)
- [gettransaction](https://developer.bitcoin.org/reference/rpc/gettransaction.html) - Bitcoin Developer Documentation (дата обращения: 2026-08-13)
- [BIP 125: Opt-in Full Replace-by-Fee Signaling](https://bips.dev/125/) - Bitcoin Improvement Proposals (дата обращения: 2026-08-13)
- [Proof-of-stake (PoS)](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (дата обращения: 2026-08-13)
- [Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (дата обращения: 2026-08-13)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (дата обращения: 2026-08-13)
- [Cryptocurrency deposit processing times](https://support.kraken.com/articles/203325283-cryptocurrency-deposit-processing-times) - Kraken Support (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/block-confirmation/index.mdx