Как клиент решает, какая цепочка блоков самая длинная, если есть форк?

Это только высота блока или усилие, затраченное на вилки? Другими словами: объясняет ли это решение различные трудности?

Ответы (2)

Ответ Гэри не совсем правильный. При сравнении двух цепочек сравниваются их общие «баллы». Каждый блок считается как (2^256 / block_target); это ожидаемое/среднее количество попыток, необходимых для его создания.

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

Спасибо, Питер. Я был сбит с толку, когда сначала прочитал ваш ответ как «это ожидаемое , деленное на среднее значение ...» Это второстепенный момент. Ваш ответ, кажется, расходится с ответом @NickOdells здесь: bitcoin.stackexchange.com/questions/37273/… , в котором утверждается, что это не оценка, а ряд правил, изложенных в CBlockIndexWorkComparator.
Этот ответ уточняет только первый критерий в CBlockIndexWorkComparator. Остальные предназначены только для того, чтобы разорвать тай-брейк.
Почему хэш блока не используется для расчета проделанной работы?
@JBaczuk Потому что среди множества допустимых хэшей каждый хеш равновероятен. Считать одни больше, чем другие, просто вводить дополнительную дисперсию (где одна ветвь, не имеющая достоинств, случайным образом будет учитываться больше, чем другая). Единственным практическим эффектом будет появление гораздо большего количества разветвлений и необходимость большего количества подтверждений, чтобы убедиться, что транзакция прошла.

Согласно статье Сатоши , применяется следующее:

Шаги для запуска сети следующие:

1) Новые транзакции рассылаются всем узлам.

2) Каждый узел собирает новые транзакции в блок.

3) Каждый узел работает над поиском сложного доказательства работы для своего блока.

4) Когда узел находит доказательство работы, он рассылает блок всем узлам.

5) Узлы принимают блок только в том случае, если все транзакции в нем действительны и еще не потрачены.

6) Узлы выражают свое принятие блока, работая над созданием следующего блока в цепочке, используя хэш принятого блока в качестве предыдущего хэша.

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

Это в значительной степени подводит итог. Если у вас есть больше действительных блоков, вы выигрываете, пока кто-то не придет с более действительными блоками.

Это то, что говорится в документе, и это то, что делал исходный код Сатоши, но это уже неверно. Если вы всегда выбираете самую длинную цепочку, то есть несколько относительно простых атак, которые работают, создавая длинные и легкие цепочки. В 2016 году основной код биткойна переключился на использование «самой рабочей» цепочки, которая не обязательно является самой длинной. Вот коммит... github.com/bitcoin/bitcoin/commit/…