---
title: "Консенсус Накамото: валидность, работа цепи, подтверждения и реорганизации"
description: "Консенсус Накамото объединяет независимо применяемые правила валидности, безразрешительное производство блоков proof of work, распространение и выбор валидной цепи с наибольшей накопленной работой. Локальные представления, chainwork, подтверждения, реорганизации, допущения общего префикса, стимулы и сетевые атаки следует анализировать отдельно."
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, при котором узлы независимо применяют правила валидности консенсуса, производители proof of work продолжают блоки без разрешенного списка участников, блоки распространяются по одноранговой сети, а каждый узел выбирает валидную ветвь с наибольшим накопленным proof of work. Он упорядочивает валидные по протоколу транзакции в наблюдаемом узлом представлении; он не делает невалидную транзакцию валидной, не устанавливает факты вне реестра и не создает немедленную детерминированную финальность.
Валидность предшествует выбору цепи. Ветвь с невалидным заголовком, proof of work, транзакцией, скриптом, уже потраченным выходом, суммой coinbase или лимитом блока отклоняется независимо от заявленных высоты или работы. Среди ветвей, прошедших правила узла и имеющих доступные данные, активную цепь определяет накопленный chainwork, а не только число блоков. Поэтому «самая длинная цепь» — неформальное сокращение для валидной цепи, представляющей наибольшие затраты proof of work.
Активная вершина предварительна. Конкурирующие валидные блоки могут временно дать хорошо связанным честным узлам разные локальные представления; дополнительная работа обычно разрешает форк, и узел может отключить одну ветвь и подключить другую при реорганизации. Число подтверждений транзакции измеряет ее глубину в текущей активной цепи наблюдателя. Большая глубина может снизить вероятность догоняния в заданной модели хешрейта и сети, но никакое число подтверждений не является финальным во всех случаях.
Термин описывает больше, чем хеширование. Аргумент безопасности также зависит от валидности блоков и транзакций, однорангового распространения, честного принятия валидной цепи с наибольшей работой, достаточной честной эффективной мощности майнинга, экономического поведения и независимого наблюдения пользователями нужной сети и ПО. Общий префикс, рост цепи и качество цепи — формальные свойства, доказанные лишь в заявленных моделях, а не безусловные факты каждой развернутой proof-of-work-цепи.
## Как анализировать консенсус Накамото
1. **Зафиксируйте идентичность и область наблюдения.** Запишите `chain`, `network`, `genesis hash`, `client version`, набор правил, checkpoints или настройки assume-valid, наблюдателя, пиров и время. Сохраните `bestblockhash`, `height` и `chainwork`; во время распространения сообщений два узла могут честно сообщать разные вершины.
2. **Проверяйте до сравнения работы.** Проверьте связь заголовков, временные ограничения, декодированную цель, proof of work, обязательства Merkle и witness, транзакции, скрипты, расходование UTXO, coinbase и ресурсные лимиты. Ветвь `invalid` не становится допустимой только из-за заявленной большей высоты или работы.
3. **Восстановите наблюдаемое дерево блоков.** Свяжите каждый кандидат хешем предыдущего блока с известным предком и отличайте полные блоки от одних заголовков. Сопоставьте статусы `active`, `valid-fork`, `valid-headers`, `headers-only` и `invalid` через интерфейсы вроде `getchaintips`; не называйте каждую видимую вершину валидной конкурирующей цепью.
4. **Пересчитайте накопленную работу.** Декодируйте цель `nBits` каждого заголовка и рассчитайте представленную работу по целочисленным правилам реализации, концептуально `work = floor(2^256 / (target + 1))`. Суммируйте по предкам и сравнивайте валидные ветви от общего предка; высота, оценка хешрейта и название пула не заменяют chainwork.
5. **Проследите выбор и реорганизацию.** Воспроизведите выбор кандидата с наибольшей работой, локальный порядок при равной работе и состояние прибытия. При появлении лучшей валидной ветви найдите точку форка, отключите старый суффикс, подключите новый, обновите `UTXO set` и сверяйте транзакции с `mempool` и записями приложения.
6. **Задайте политику подтверждений по риску.** Рассчитывайте `confirmations = tip_height - block_height + 1` только для блока текущей активной цепи. Укажите рискованную стоимость, обратимость, долю атакующего, распространение, риск eclipse, наблюдаемую stale-долю, глубину и план реакции; шесть — обычай, а не порог финальности протокола.
7. **Проведите стресс-тест всего аргумента.** Проверяйте разделения, задержку, удержание блоков, selfish mining, eclipse-атаки, концентрацию пулов и оборудования, резкие изменения хешрейта, стимулы комиссий и субсидии, расхождение клиентов, глубокие реорганизации и восстановление. Связывайте выводы с общим префиксом, ростом, качеством, персистентностью и живостью только при допущениях цитируемой модели.
Результат — воспроизводимое и специфичное для наблюдателя объяснение, какую валидную историю узел выбирает сейчас и почему. Правила задают допустимость; proof of work удорожает альтернативные истории; распространение показывает работу другим узлам; fork choice выбирает текущую историю; политика подтверждений определяет момент действия приложения. Сведение этих уровней к «одобрению сети» скрывает условия отказа.
## Разобранные примеры
### 1. Невалидная работа не побеждает
Пусть ветвь A сообщает `valid_A = false` и `chainwork_A = 1,200 units`, а B имеет `valid_B = true` и `chainwork_B = 1,000 units`. Узел отклоняет A и выбирает B. Работа сравнивается только между допустимыми кандидатами; proof of work не разрешает избыточную coinbase, невалидную подпись или двойное расходование.
Если у одного наблюдателя есть только заголовки A, а у другого полные блоки, их статусы могут различаться до завершения загрузки и проверки. Валидные заголовки не доказывают полной проверки всех транзакций и переходов состояния.
### 2. Высота не равна накопленной работе
В упрощенном примере с переменной целью C добавляет шесть блоков по 100 единиц, то есть `6 * 100 = 600 units`. D добавляет пять блоков по 130, то есть `5 * 130 = 650 units`. Если обе ветви валидны и начинаются с одинаковой работы, D имеет больше работы, хотя она короче на блок.
Если две валидные вершины имеют ровно `650 units`, равная работа не заставляет все узлы сразу видеть одну вершину. Порядок прибытия и локальное состояние реализации могут различаться, пока следующий валидный блок не сделает ветвь тяжелее. Временное равенство представлений не является детерминированной глобальной финальностью.
### 3. Подтверждения могут исчезнуть
Транзакция в блоке высоты `100` при активной вершине `105` имеет `tip_height - block_height + 1 = 105 - 100 + 1 = 6 confirmations`. Пусть альтернативная валидная ветвь отделяется после высоты 99 и на высоте 106 без этой транзакции становится ветвью с наибольшей работой. Реорганизация отключает старые блоки `100 through 105`; транзакция теряет шесть активных подтверждений и может вернуться в mempool, конфликтовать с другим расходованием или остаться вне цепи.
Приложения должны сверять хеш блока и предков, а не хранить только число шесть. Зачисление биржи, поставленный товар, сообщение моста или расчет дериватива могут быть экономически необратимы, хотя история исходной цепи еще обратима.
### 4. Вероятность догоняния зависит от модели
В иллюстративной модели whitepaper Bitcoin обозначим долю атакующего `q = 0.10`, честную долю `p = 0.90` и отрыв честной цепи `z = 6`. Приближение Пуассона дает `lambda = z * (q / p) = 0.6666667` и `P(catch up) = 0.0002428027 = 0.02428027%`. При `q = 0.30` на той же глубине результат возрастает до `P(catch up) = 0.1321111687 = 13.21111687%`.
Это не текущие гарантии Bitcoin. Расчет предполагает стабильные независимые хеш-попытки и условия гонки модели; он исключает eclipse-изоляцию, преимущество распространения, selfish-стратегии, реакции цены и аренды, ошибки реализации и реакцию приложения. Политика должна раскрывать модель и проверять худшие условия, а не просто ссылаться на шесть подтверждений.
## Риски и ошибки проверки
### Ошибки протокола и измерения
- Сравнивать работу до независимой проверки заголовка, тела блока и предков.
- Называть победителем самый высокий или первый увиденный блок без расчета накопленного chainwork.
- Подменять chainwork числом блоков, номинальным хешрейтом, долей пула или меткой обозревателя.
- Смешивать mainnet, testnet, signet, форки, версии клиента, checkpoints или идентичности genesis.
- Считать историю из одних заголовков, недоступных или оптимистичных данных полностью проверенной.
- Игнорировать декодирование цели, целочисленную арифметику, связь прошлого хеша или общего предка.
- Считать один RPC или обозреватель глобальной картиной без хеша, высоты, времени и пиров.
### Ошибки сети, стимулов и контроля
- Предполагать мгновенное распространение или одинаковый порядок прибытия на всех узлах.
- Считать равенство работы единым глобальным состоянием, а не временными локальными представлениями.
- Игнорировать stale-блоки, задержку, удержание, selfish mining и преимущество распространения.
- Выводить независимых майнеров из названий пулов или собственность оборудования из их долей.
- Игнорировать концентрацию пулов, прошивок, производителей, хостинга, энергии, географии и сети.
- Считать награды доказательством, что честное продолжение всегда оптимально для каждого.
- Исключать риски eclipse, разделения, Sybil, отравления пиров, DoS и манипуляции временем.
### Ошибки расчета и безопасности
- Называть подтверждение финальностью протокола или обещать, что шесть нельзя удалить.
- Применять одно число к любой стоимости, контрагенту, обратимости и модели угроз.
- Превращать вероятностный пример whitepaper в измеренную сегодня вероятность атаки.
- Заявлять, что большинство хешрейта подделывает подписи, берет любые монеты или валидирует инфляцию.
- Заявлять, что меньшинство не может выгодно отклоняться либо вызвать реорганизацию или цензуру.
- Приравнивать вершину с наибольшей работой к внешним фактам, юридической собственности или расчету приложения.
## Распространенные заблуждения
- **Самая длинная цепь всегда содержит больше блоков.** Узлы Bitcoin выбирают валидную цепь с наибольшей накопленной работой; при разных целях высота может быть плохой заменой.
- **Майнеры решают, какие правила протокола действуют.** Майнеры предлагают блоки, а каждый полный узел независимо применяет настроенные правила консенсуса.
- **Шесть подтверждений создают абсолютную финальность.** Шесть — обычай приложения; риск зависит от модели, глубины, противника, распространения и целостности наблюдения.
- **Атакующий с 51% может тратить чужие монеты.** Хешрейт может поддержать реорганизацию, двойное расходование и цензуру, но не дает чужой подписи закрытого ключа и не заставляет неизмененные узлы принять невалидную инфляцию.
- **Высокий общий хешрейт доказывает децентрализацию и безопасность.** Важны также фактический контроль, видимость сети, доступ к оборудованию, координация пулов, разнообразие клиентов, стимулы и длительность атаки.
## Связанные темы
- [Proof of work](/ru/crypto/proof-of-work/)
- [Правила выбора форка](/ru/crypto/fork-choice-rule/)
- [Подтверждения блоков](/ru/crypto/block-confirmation/)
- [Реорганизации цепи](/ru/crypto/chain-reorg/)
- [Selfish mining](/ru/crypto/selfish-mining/)
## Источники
- [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 Developer Guide: Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Project (дата обращения: 2026-08-19)
- [Bitcoin Core RPC: getchaintips](https://developer.bitcoin.org/reference/rpc/getchaintips.html) - Bitcoin Project (дата обращения: 2026-08-19)
- [Bitcoin Core: validation.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp) - Bitcoin Core (дата обращения: 2026-08-19)
- [The Bitcoin Backbone Protocol: Analysis and Applications](https://eprint.iacr.org/2014/765) - IACR Cryptology ePrint Archive (дата обращения: 2026-08-19)
- [Majority Is Not Enough: Bitcoin Mining Is Vulnerable](https://www.cs.cornell.edu/~ie53/publications/btcProcArXiv.pdf) - Cornell University (дата обращения: 2026-08-19)
- [Eclipse Attacks on Bitcoin's Peer-to-Peer Network](https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman) - USENIX Association (дата обращения: 2026-08-19)
Source: https://wiki.fcontext.com/ru/crypto/nakamoto-consensus/index.mdx