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

Правила выбора ветви: допустимые ветви, вес и каноническая вершина

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

Обновлено

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

Краткий ответ

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

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

«Самая длинная цепочка» — не универсальная формула. Bitcoin выбирает допустимую цепочку с наибольшей работой: решающей является совокупная ожидаемая работа PoW, а не простая высота. LMD-GHOST в Ethereum начинает с обоснованной контрольной точки, фильтрует жизнеспособные ветви и жадно следует к дочернему блоку с наибольшим балансом аттестаций последних сообщений плюс применимый proposer boost; учитывается только последнее допустимое сообщение каждого валидатора. Другие протоколы могут применять сертификаты доступности, блокировки лидера, раунды или явные сертификаты commit вместо постоянной конкуренции самых тяжёлых ветвей.

Результат зависит от точных входных данных: цепочки и сети, версии форка, доверенного якоря, текущего времени или слота, известных допустимых блоков, родительских связей, снимка работы или веса голосов, последних сообщений, свидетельств эквивокации, обоснованных и финализированных контрольных точек, доступности данных, времени proposer и детерминированного разрешения ничьих. Значок обозревателя блоков или один результат RPC — это наблюдение результата одного узла, а не само правило и не независимое подтверждение входных данных.

Как анализировать правило выбора ветви

  1. Зафиксируйте идентичность и версию. Запишите цепочку, сеть, форк консенсуса, версию клиента, genesis или доверенный якорь, текущую высоту или слот и точное действующее правило. Не переносите логику mainnet на testnet, sidechain, rollup или будущий проект.
  2. Постройте граф допустимых блоков. Проверьте хеши, родителей, доказательства консенсуса, переходы состояния, статус execution payload и требуемую доступность данных. Явно отметьте неизвестные, оптимистические, недопустимые и удалённые узлы: вес не может спасти недопустимую ветвь.
  3. Восстановите происхождение и ограничения. Найдите общего предка и проверьте, какие кандидаты происходят от обязательных контрольных точек, блокировок или сертификатов. Отделите наблюдаемое исходное дерево от отфильтрованного дерева, которое правило действительно рассматривает.
  4. Воспроизведите каждый вход веса. Для PoW декодируйте цели и суммируйте доказательство каждого блока в накопленную работу. Для правил голосования проверьте идентичность валидатора, активный эффективный баланс или иной вес, домен сообщения, целевой корень, слот или эпоху, замену последнего сообщения, обработку эквивокации и временные усиления.
  5. Точно выполните выбор и разрешение ничьих. Примените заданную рекурсию или компаратор на каждом разветвлении с округлением протокола и детерминированным порядком. Отметьте, допускает ли равный вес временное локальное предпочтение, а не выдавайте ничью за окончательное согласие.
  6. Согласуйте смену вершины. Когда победитель меняется, определите отсоединённые и присоединённые блоки, откатите и повторно примените состояние, согласуйте квитанции, журналы и mempool и вычислите глубину реорганизации от общего предка. Различайте метки head, safe, justified, committed и finalized.
  7. Проведите стресс-тест и мониторинг. Проверьте задержанные или удержанные блоки, разделения сети, устаревшие голоса, эквивокацию, балансировку, время proposer, расхождения клиентов, слабые контрольные точки и недоступные данные. Сравнивайте независимые узлы и предупреждайте о неожиданном расхождении вершин, глубокой реорганизации или конфликте с финализированным состоянием до необратимых действий последующих систем.

В текущем Bitcoin Core кандидаты сначала сравниваются по nChainWork; при равной работе они упорядочиваются по самой ранней активируемой последовательности с внутренним резервным разрешением ничьей. Поле RPC blocks — высота полностью проверенной цепочки с наибольшей работой, а bestblockhash определяет её вершину. В текущей спецификации выбора ветви Ethereum функция get_head(store) начинает с justified_checkpoint, проходит отфильтрованное дерево и на каждом шаге выбирает дочерний блок, максимизирующий (get_weight(store, child), child.root). Это детали конкретного протокола и версии, а не общие определения консенсуса.

Примеры расчёта

1. Переключение Bitcoin по накопленной работе

Две допустимые ветви имеют общего предка C. Текущие вершины имеют chainwork(A)=240 и chainwork(B)=235, поэтому узел выбирает A, даже если простое отображение высоты делает ветви похожими. Новый допустимый блок добавляет ветви B работу 10:

chainwork(B') = 235 + 10 = 245

Поскольку 245 > 240, B становится кандидатом с наибольшей работой. Узел отсоединяет блоки A после C, присоединяет B до B' и согласует транзакции. Простого числа блоков недостаточно, когда цели блоков различаются, а равенство работы — временная ничья, не доказательство финальности.

2. Жадный выбор самого тяжёлого наблюдаемого поддерева

Рассмотрим упрощённое дерево LMD-GHOST с корнем в обоснованной контрольной точке J. Его дочерние блоки — A и B. Последние допустимые сообщения валидаторов дают всему поддереву A вес 61, а поддереву B — 39, поэтому первый жадный шаг выбирает A. У A есть дочерние блоки A_1 и A_2 с весами поддеревьев 34 и 27; следующий шаг выбирает A_1.

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

3. Замена последнего сообщения

Предположим, что последние допустимые сообщения первоначально дают ветви A вес 55, а ветви B — 45. Валидатор с весом 20 затем отправляет более новое допустимое сообщение в поддержку потомка B. Учёт последнего сообщения убирает прежнюю поддержку валидатора из A и добавляет её к B:

A: 55 - 20 = 35; B: 45 + 20 = 65

Вес учитывается один раз, а не на обеих ветвях, поэтому выбранный путь может измениться. Это не разрешение голосовать противоречиво: если допустимое доказательство attester slashing выявляет эквивокацию, текущее хранилище Ethereum отмечает такого валидатора и исключает его вес из обычного подсчёта аттестаций.

4. Фильтрация по контрольной точке и proposer boost

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

Теперь рассмотрим два жизнеспособных дочерних блока в текущем слоте с весами аттестаций 35 и 50. В указанной конфигурации Ethereum своевременный proposer boost равен 40% веса одного комитета, а не 40 процентам всего stake. Если вес комитета равен 100 и усиление применяется к дочернему блоку с весом 35, его сравнительный балл становится 35 + 40 = 75, поэтому на этом шаге он превосходит 50. Усиление временно и зависит от форка; это не дополнительный голос валидатора и не финальность.

Риски и ошибки проверки

Набор кандидатов и доказательства

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

Выбор и операционные сбои

  • Описание правила Bitcoin как простой «наибольшей высоты», а правила Ethereum — как простого голосования двумя третями за вершину.
  • Замена жадной рекурсии по поддеревьям глобальной оценкой листьев либо пропуск proposer boost, округления и разрешения ничьи по корню.
  • Предположение, что узлы с разным порядком поступления, часами или представлениями сообщений обязаны немедленно показать одну вершину.
  • Неправильное отсоединение и повторное применение состояния, квитанций, журналов, индексов и записей mempool при реорганизации.
  • Расхождение реализаций клиентов в допустимости, жизнеспособности контрольных точек, последних сообщениях, времени или разрешении ничьих.
  • Пропуск условий балансировки, удержания, эквивокации, разделения, eclipse, задержанных голосов и proposer reorganization.
  • Доверие одному RPC, обозревателю, relay, семейству клиентов, облаку или оператору валидаторов как независимому представлению консенсуса.

Финальность и несоответствие приложения

  • Объявление выбранной вершины финализированной, необратимой или безопасной без отдельного свидетельства финальности протокола.
  • Разблокировка депозитов, сообщений моста или необратимых сделок на временной вершине без политики, учитывающей стоимость.
  • Предположение, что финализированный предок гарантирует корректность или доступность каждой новой вершины, payload, oracle или результата приложения.
  • Использование фиксированного числа подтверждений в цепочках с разными моделями работы, голосования, контрольных точек и восстановления.
  • Принятие аварийных контрольных точек, якорей weak subjectivity или social recovery за обычные входы выбора ветви без границы доверия.

Распространённые заблуждения

  • Самая длинная ветвь всегда побеждает. Протокол может сравнивать накопленную работу, взвешенные последние сообщения, сертификаты или другую оценку; простая высота не универсальна.
  • Самая тяжёлая наблюдаемая ветвь автоматически допустима. Допустимость и доступность фильтруют кандидатов до выбора по весу.
  • Выбор ветви и финальность — одно правило. Выбор ветви определяет текущую вершину для продолжения; финальность защищает предка при дополнительных условиях безопасности.
  • Каждый голос валидатора навсегда остаётся в сумме. В правилах последнего сообщения новое допустимое сообщение заменяет прежнюю поддержку валидатора.
  • Один обозреватель доказывает каноническую цепочку. Он сообщает представление одного инфраструктурного стека; независимая проверка и согласование всё равно необходимы.

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

Источники

Навигация

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