Какое именно правило «самой длинной цепочки» реализовано в протоколе Ethereum «Homestead»?

В этом документе от 2016 года утверждается (в разделе 3.3.2, где говорится о фактической реализации Ethereum, а не о спецификации), что:

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

(выделено в оригинале). Единственная предлагаемая ссылка относится к этой статье , которая, по-видимому, утверждает противоположное утверждение, что:

Вариант GHOST был принят и реализован проектом Ethereum.

Единственная ссылка на ethereum.org, так что это тоже не помогает. Я знаю об обширной документации , в которой описываются правила Ethereum для вознаграждения блоков ommer/uncle, часто говоря, что они «способствуют безопасности». Однако конкретный вопрос о том, учитываются ли оммеры/дяди при определении самой длинной цепочки, кажется, не так четко задокументирован.

Далее в первой статье утверждается:

Эфириум также недавно модифицировал свой алгоритм самой длинной цепи, включив в него унифицированный разрыв связей... [который] позволяет эгоистичному майнеру увеличить свои шансы догнать честную цепочку.

И в этом случае ссылки на конкретную фиксацию , а также на этот документ об оптимальных стратегиях эгоистичного майнинга , в котором указывается, что единообразное нарушение связи является особым компромиссом, который значительно усложняет атаки для хорошо связанных и скоординированных злоумышленников, в то же время немного облегчая атаки для менее связанные или координированные. Однако , поскольку эта статья посвящена Биткойну и предполагает правило самой длинной цепочки, не учитывающее дяди (и не учитывает конкретно стратегические последствия вознаграждений ommer/uncle), оценивая реальное влияние единообразного разрешения ничьих в Ethereum. по-прежнему требуется знать, учитывается ли сложность ommer/uncle в первую очередь.

Итак, что же делают узлы Ethereum в Homestead с точки зрения фактического правила самой длинной цепи?

Считают ли они трудность дядюшки вкладом в самую длинную цепочку? И они все еще делают тай-брейк в форме? Были ли внесены какие-либо другие изменения? Например, майнинг SPV стал преобладать в биткойнах, несмотря на то, что фактически не был реализован в официальных выпусках. Теоретически Ethereum предписывает, чтобы блоки в основной цепочке полностью проверялись, в то время как для блоков ommer/uncle проверялись только их заголовки. Однако как временные метки блоков, так и включение транзакций определенно были изменены майнерами ранее по стратегическим причинам.

То, что я хочу, — это просто лучший ответ на этот вопрос, который мы можем получить в настоящее время для узлов, фактически работающих в пулах, клиентах и ​​т. д. Обратите внимание, что ссылок на официальные или желтые документы здесь недостаточно, поскольку в этом документе конкретно утверждается, что реализация отличается от теории и документация. Ответы должны исходить от разработчиков реальных клиентов, таких как geth и parity, и/или напрямую ссылаться на репозитории, показывающие, как на самом деле реализовано правило.

Я хочу спросить, получит ли награду ребенок блока дяди?

Ответы (3)

Ethereum определяет самую длинную цепочку на основе общей сложности , которая заложена в заголовке блока. Связи рвутся случайным образом.

Общая сложность — это простая сумма значений сложности блоков без явного подсчета дядей. Сложность вычисляется на основе родительской сложности и временной метки, временной метки блока и номера блока , опять же без ссылки на дядей.

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

Спасибо за ясность: подтверждает пункты статьи: 1) дяди не учитываются при расчете общей сложности 2) Geth реализует унифицированный разрыв ничьей (хотя другие клиенты могут и не использовать).
@all: Нужны ли связанные здесь вопросы в новых или улучшенных ответах или в разъяснении технического документа? Например, такие части, как «способствуют безопасности основной цепи» .
Наверняка это была ошибка? Сообщение в блоге Виталика, оправдывающее примерно 12-секундное время блока, основывалось на преимуществах безопасности GHOST, но если дяди не учитываются в сложности, то преимущества безопасности нет. Согласно анализу, приведенному в eprint.iacr.org/2015/1019.pdf , в настоящее время Ethereum кажется уязвимым для атак ~34% . (Это теоретическая нижняя граница, предполагающая дискретные циклы распространения информации, которые занимают 12,6 секунды, поэтому реальность может быть немного другой, но атака 35~40% кажется очень правдоподобной.)
Вы имеете в виду, что Эфириум теперь использует выбор самой длинной цепочки, как в Биткойне, и единственная разница в том, что Эфириум активирует блоки дяди?
@MWH, и сложность регулируется также с использованием скорости выдачи дяди, но да, похоже, что «самый длинный» / «самый тяжелый» основан на общей сложности в цепочке, без дядей.

Все изменилось с тех пор, как был опубликован ответ Ника.

Особенно с введением EIP 100 (который был принят в июне 2017 года - всего через 3 месяца после ответа Ника), который меняет алгоритм расчета сложности, чтобы включить дядей.

Я новичок в Ethereum, поэтому я не совсем понимаю, какой эффект это имеет, поэтому, если кто-то может объяснить это, это будет здорово.

Новые ссылки на код:

Самая длинная цепочка, основанная на общей сложности.

Расчет сложности (теперь также зависит от дядей)

Я думаю, вы отвечаете на другой, но актуальный вопрос. EIP корректирует формулу таргетинга сложности, чтобы скорректировать выпуск ommer. Однако это не означает, что для вычисления самой «тяжелой» цепочки используется обычная сложность.

Здесь указано, что протокол GHOST не используется в эфириуме. Почему Ethereum отказался от протокола GHOST?

и что он был заброшен через 2 недели после запуска основной сети и что Ethereum использует модифицированную версию инклюзивного протокола.