Перейти к содержанию
Financial Context Wiki

Консенсус Накамото: валидность, работа цепи, подтверждения и реорганизации

Консенсус Накамото объединяет независимо применяемые правила валидности, безразрешительное производство блоков proof of work, распространение и выбор валидной цепи с наибольшей накопленной работой. Локальные представления, chainwork, подтверждения, реорганизации, допущения общего префикса, стимулы и сетевые атаки следует анализировать отдельно.

Обновлено

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

Прямой ответ

Консенсус Накамото — это процесс типа 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% может тратить чужие монеты. Хешрейт может поддержать реорганизацию, двойное расходование и цензуру, но не дает чужой подписи закрытого ключа и не заставляет неизмененные узлы принять невалидную инфляцию.
  • Высокий общий хешрейт доказывает децентрализацию и безопасность. Важны также фактический контроль, видимость сети, доступ к оборудованию, координация пулов, разнообразие клиентов, стимулы и длительность атаки.

Связанные темы

Источники

Навигация

Поиск по вики...