Самый дезориентирующий параграф Сатоши
Самый дезориентирующий параграф Сатоши
Самый дезориентирующий и сбивающий с толку параграф во всей «Белой книге» Сатоши – это, без сомнения, третий пункт 4-го раздела:
Proof-of-Work также решает проблему определения представительства при принятии большинства решений. Если бы суждение о мнении большинства выводилось из расчёта «один IP-адрес – один голос», то кто угодно мог бы проголосовать со многих IP-адресов. Proof-of-Work же, по сути, представляет собой голосование из расчёта «один CPU – один голос». Большинство принятых решений выражаются в виде самой длинной цепочки, в которой заложен наибольший объём PoW-доказательств. Если большая часть CPU контролируется честными узлами, то честная цепочка будет расти быстрее прочих и опережать все конкурирующие ветви. Для того, чтобы изменить завершённый блок, злоумышленнику придётся заново выполнить PoW-доказательство для этого и всех следующих за ним блоков, а затем догнать и превзойти длину цепочки, формируемой честными узлами. Позже мы продемонстрируем, что вероятность того, что цепочка, созданная более медленным злоумышленником, сможет превзойти длину основной цепочки, экспоненциально снижается по мере добавления последующих блоков.
Здесь есть несколько серьёзных проблем. Начнём с очевидного: никто больше не использует для майнинга CPU, очень немногие узлы до сих пор заняты майнингом, голосовать могут только майнящие узлы, а майнинговые пулы имеют тенденцию концентрировать голосование в руках нескольких операторов пула. Но есть ещё одна серьёзная проблема, которая часто упускается из виду: единственное, за что в действительности голосуют майнинговые узлы, – это за то, какую из нескольких действительных цепочек продолжать, а не за то, какие правила применять для определения корректности конкретной цепочки.
При первом прочтении это может показаться не настолько ясным – в конце концов, Накамото говорит лишь «при принятии большинства решений». Однако при более глубоком рассмотрении концепции (и глядя на реализацию Накамото), мы начинаем понимать, что, если бы узлы действительно голосовали по поводу того, какую цепочку считать правильной, алгоритмический характер консенсуса Накамото был бы тут же утрачен, а вместе с ним и твёрдые гарантии итоговой консистентности. Если узлы и правда будут обеспечивать такой выбор, очевидно, что в конце концов цепочки разойдутся и сеть станет фрагментарной. Без общего набора правил определения корректности конкретной цепочки, ничто не удержит узлы от разделения в отдельные сети – даже если у них будет меньше хэширующих мощностей, а возможно даже и вовсе без них.
Как показал хард-форк, разделивший Эфириум на ETH и ETC, цепочка с меньшей скоростью хэширования может продолжить своё развитие. Некоторые утверждают, что Биткойн отличается тем, что регулирование сложности занимает значительно больше времени. Но вопрос регулирования сложности – проблема хорошо известная, и это не зависит только от хард-форков. Любое внезапное падение скорости хэширования в сети приведет к этой проблеме, и неважно, какова была причина падения скорости хэширования. И если это должно произойти, то вполне вероятно, что многие участники сети скорее предпочли бы скорректировать алгоритм вторичного регулирования сложности, чтобы обойти эту проблему. Да, можно было бы также выделить этих участников сети в цепочку, отдельную от тех, кто выступает против такого вмешательства, но, может быть, стимулы к сотрудничеству с целью исправления сети окажутся достаточно сильными, чтобы преодолеть это противоречие. Каждый участник будет заинтересован в том, чтобы исправить сеть. И всё-таки, такой сценарий развития событий я бы предпочёл наблюдать как можно реже, а то и вовсе не видеть.
При форке ETH/ETC большая часть хэширующих мощностей не просто сделала выбор в пользу нового набора правил. Вся соль заключается в том, что эти хеширующие мощности попытались легитимировать процесс принуждения бирж и других экономически важных узлов к изменению их программного обеспечения ради эффективной поддержки нового протокола с новыми правилами. Старым символом на биржах, в сущности, стала обозначаться новая сеть с изменёнными правилами достижения консенсуса. Если бы экономически важные узлы отказались от обновления своих программ, то в коде старого протокола не было ничего, что могло бы повлиять на их решение. Таким образом, мы променяли алгоритмическую природу Proof-of-Work-консенсуса на политический процесс.
Софт-форки, применяемые с сигнальными механизмами – как BIP9 – принципиально отличаются от хард-форков: мы не нарушаем алгоритмический характер консенсуса Накамото – добавление новых правил консенсуса может происходить постепенно и только после того, как будут гарантированы непреодолимые стимулы к их соблюдению для владельцев хэширующих мощностей, и мы избегаем риска разделения цепочки, так как даже необновлённые валидирующие узлы могут продолжать проверять соответствие правилам, которые им известны, а новые блоки они будут просто признавать верными. По очевидным причинам, необновлённые узлы не могут валидировать соответствие новым правилам, которые им не знакомы. Это обстоятельство приводилось в качестве аргумента против софт-форков, однако нет никакого способа обойти эту проблему при помощи хард-форка, так что это спорный аргумент, если только он не высказывается против внесения любых изменений в правила достижения консенсуса когда бы то ни было. BIP9 гарантирует, что все узлы получают информацию о предстоящем софт-форке заранее, чтобы они могли предупредить своих пользователей и дать им возможность либо обновиться и продолжить работать с тем же программным обеспечением, либо полностью отказаться от участия в сети.
В случае же хард-форка, необходимо убедить экономически важные узлы, такие, как биржи, обновить их программное обеспечение до того, как станет понятно, что цепочка получит поддержку подавляющего большинства пользователей. Даже если цепочка получает такую поддержку, хэширующие мощности всегда могут переключиться на другие цепочки, если майнинг на них станет более выгодным. Хэш-мощности будут стремиться следовать за рынком. Это добавляет огромную неопределённость при внедрении и разрушительно влияет на коммерческую деятельность и рынки. И нет совершенно никаких гарантий, что мы в конце концов придём к соглашению. Две и более цепочки могут продолжать существовать сколь угодно долго, приводя к инфляции, разрушению взаимозаменяемости, перекрёстным атакам на цепочки и множеству других нежелательных последствий, не говоря уже о потенциальной враждебности в сообществе и, вместе с тем, балканизации.
В периоды выполнения недавних хард-форков Эфириума, связанных с проблемами безопасности сети, я запустил несколько узлов Эфириума. Я буду говорить только за себя: даже при моём обширном опыте и знаниях об этих типах сетей, синхронизация с сетями стала для меня настоящим испытанием. Я могу только догадываться, насколько сложно может быть для менее искушённых пользователей решать подобные вопросы регулярно. По этим причинам я считаю, что частые хард-форки будут отталкивать людей от работы с валидационными узлами.
Майнеры всегда обладали двумя умениями:
-выбирать, какие транзакции включать в свои блоки (в том числе и транзакции Coinbase, которая выплачивает им своё вознаграждение);
-выбирать, какую из множества действительных цепочек продолжать, если остальная часть сети также считает любую из этих цепочек корректной.
Правило Накамото о самой сложной цепочке позволяет остальной сети сходиться на одном реестре независимо от того, какой выбор делают майнеры.
Попытки дать майнерам право голоса в вопросе о хард-форках всегда идут вразрез с консенсусом Накамото*, поскольку это будет означать, что майнеры смогут произвольно изменять правила, даже если другие узлы сети не примут их цепочки как верные. В действительности, единственная возможность сделать такое изменение правил даже просто возможным – это обновить программное обеспечение валидационных узлов, добровольно или принудительно. Если изменение является очень спорным, то, если мы хотим сохранить единую сеть, некоторые из узлов должны быть к нему принуждены. А это возвращает нас обратно в область политических валют, от которых Сатоши пытался уйти.
Такие механизмы софт-форка как BIP9, вероятно, были неизвестны Накамото. Также был достигнут значительный прогресс в обособлении реализации правила достижения консенсуса и модульной организации программного обеспечения узлов для поддержки нескольких реализаций, которые по-прежнему будут записываться в один реестр.
источник
11.02.2017, 17:25
