Как достичь компромисса относительно хард-форка — часть 3
В первой части мы говорили о технических аспектах будущего хард-форка. Во второй части мы предположили, как стоит измерять консенсус. А сейчас давайте попробуем разобраться, как пройдёт хард-форк.
Стратегии развития
Если уж хард-форк неизбежен, то я хочу, чтобы им занималась лучшая команда, и как можно больше людей внимательно следили за происходящим. Я имею в виду тех людей, которые в течение последних нескольких лет оттачивали развитие и улучшали Биткойн и его протокол. Согласен, они очень консервативны и на это потребуется немало времени, но вот в чем соль: если самые опытные разработчики скажут, что предложение не готово, я, пожалуй, поверю им.
Очевидно, что такому изменению потребуется от 12 до 18 месяцев, чтобы надежно укрепится после релиза: на текущий момент 4,7% узлов показывают, что они работают на 0.12.1, которому уже 16 месяцев. Также, стоит помнить о необходимости проведения активной кампании по информированию общественности.
Так как мы не хотим нарушать существующие транзакции, мы не можем создать обязательную двухстороннюю защиту от воспроизведения (replay protection). Но все же, альтернатива есть: на каком бы форке вы не создали транзакцию, она не будет действительна на другом форке. Например, если за 6 месяцев до хард-форка будет активирован софт-форк, чтобы запретить транзакции с высоким бит nVersion: такие транзакции будут разрешены только после хард-форка. По той же схеме, хард-форк, может запретить любые транзакции со вторым по величине битом nVersion.
Обратите внимание, что софт-форк дает 6 месяцев на подготовку, так как старые узлы могут не понимать зачем нужна активация этого софт-форка.
Уже не раз поднимались дискуссии о том, чтобы сделать старую сеть непригодной для использования, чтобы не дать злонамеренным майнерам обманывать не обновившиеся полные узлы путём продолжения поддержки в старой цепочке. В таком случае, никто не захотел бы остаться на старой цепочке, по крайней мере, так предполагалось, а лично я, могу в этом усомниться и считаю, что такие подходы не стоят даже обсуждения. Таким образом, установка (в настоящее время недействительного) более высокого бита в блоке nVersion в качестве метода хард-форка — предпочтительный метод разработчиков. К сожалению, без защиты для не обновлённых узлов, невозможно сократить временные рамки развертывания.
Также, ранее были споры о том, не поломает ли хард-форк SPV-узлы (которые не загружают весь блок, а верят «честному слову» майнеров) или даже, не должны ли SPV-узлы обнаруживать что хард-форк произошел (как и должно быть!). Использование высокого бита блока nVersion позволяет достичь высоких требований относительно обнаружения, и, в противном случае, возможность избежать любых требований к обновлению софта для SPV-узлов, кажется одновременно простым и желательным (например, spoonnet так и делает).
Вывод
Хардфорки действительно сложны, они требуют высокой заинтересованности, технического совершенства и универсальных обновлений. Лучшим сценарием отказа была бы отмена хард-форка. Остальные режимы отказа так или иначе включают какую-то степень эрозии биткойна как средства хранения стоимости.
А теперь, набросав примерный план того, как всё будет происходить, я могу с чистой совестью приступать к изучению, анализу и критике кода spoonnet и разных предложений, и призываю к сотрудничеству всех, у кого есть предложения по техническим вопросам. Надеюсь вы присоединитесь ко мне!
https://bitnovosti.com/2017/10/21/kak-dostich-kompromissa-otnositelno-hardforka-chast-3/ 
