Зачем выбирать самую длинную цепочку, прежде чем проверять двойную трату?

Можем ли мы внести следующие изменения в текущий протокол POW, чтобы избежать двойных расходов:

а) Для полных/майнинговых узлов, которые получают две цепочки, проверьте, есть ли одинаковые адреса, которые встречаются в обеих цепочках, которые выполняют двойную трату. Если они есть, игнорируйте цепочку, которая приведет к реорганизации узла ( reorg ), выберите другую цепочку;

б) Если таковой нет, выберите более длинную цепочку;

в) Для узлов, которые получают только одну цепочку, принять ее, если она не требует реорганизации.

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

Что именно вы имеете в виду под «которые выполняют двойную трату»? Вы имеете в виду, что две цепочки имеют две разные транзакции, каждая из которых тратит один и тот же вывод? Если да, то предлагаете ли вы каждому узлу просто придерживаться того, который он увидел первым?

Ответы (2)

Если есть попытка двойной траты, узел не может узнать, «какая цепочка (транзакция) на самом деле была первой и является законной» . Некоторые узлы могут сначала услышать о «легитимной» цепочке, некоторые могут сначала услышать о цепочке двойного расходования.

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

в) Для узлов, которые получают только одну цепочку, принять ее, если она не требует реорганизации.

Если нода получает только одну цепочку, то она никогда не потребует реорганизации. Только узел, который получает альтернативную, более длинную цепочку, будет реорганизован.

..слепо принимать самую длинную цепочку? Разве мы не должны проверить содержимое блока из обеих цепочек, прежде чем решить, какую из них принять?

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

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

Где вы прочитали, что самая длинная цепочка принимается вслепую? Конечно, никакая цепочка с двойной тратой в ней не годится — это полностью лишило бы цели.

Что действительно происходит (по крайней мере, в Bitcoin Core), так это то, что проверка на двойную трату и действительность подписи происходит только после того, как конкретная цепочка становится самой рабочей цепочкой. Но она не считается признанной лучшей цепочкой, пока не будет полностью подтверждена. Если двойная трата или недействительная подпись обнаружены в цепочке-кандидате на лучшую цепочку, эта цепочка отбрасывается, а алгоритм выбора возвращается ко второй по величине рабочей цепочке и полностью ее проверяет.

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