Скорее всего, чтобы добиться компромисса необходимы следующие элементы: реальная скидка для не SegWit транзакций, постепенный рост (на 14–17% процентов в год), период применения не менее 12-18 месяцев, версия хардфорка nVersion bit, изыскание спуннета coinbase, replay protection.
Раньше я уже говорил, что проблема биткоина заключается в его недостаточной масштабируемости. Но эту проблему можно решить: немалый прогресс уже был сделан относительно масштабирования протокола и кода Биткоина, в части проверки блоков, их распространения и хранения. И всё это было проделано с достаточной осторожностью и обратной совместимостью.
Но в какой-то степени всё ещё необходимо обновление, которое невозможно отмотать назад, изменение, к которому должны будут подключиться все, так называемый хард-форк. Главное и наиболее очевидное, что нужно сделать – увеличить ограничение на размер блока (сейчас оно составляет 4MB на блок). Вокруг этого уже было столько шума и суматохи, что большинство разработчиков Core решили просто умыть руки и дождаться появления более консенсусного решения.
Но есть ещё много других полезных изменений, и за развертывание этой темы я должен отдать должное Люку-младшему (несмотря на то, что я и не совсем согласен с ним!).
Вещи, которых мы не будем делать
Если у Вас на текущий момент есть действующая, стандартная транзакция, то она должна сохраниться и после активации форка. У людей есть определенные временные рамки и ограничения относительно транзакций, и вы не сделаете себе чести, сказав: «погодите пока, не совершайте сегодня никаких транзакций». Например, это значит, что хэширование BIP143 нельзя использовать для более старых транзакций (например, это то, что сделал форке Bcash).
Если у вас есть какая-то сумма на блокчейне, которую вы можете потратить сегодня, то она должна остаться у вас и после хардфорка. В противном случае, это будет просто конфискацией денег.
В общем, это значит, что изменение транзакции дело не благодарное: новый код должен поддерживать и старый, и новый форматы, а формат SegWit является оптимальным, так как он поддерживает обновления. Изменение формата блока на самом деле очень полезно: в конечном итоге новый код может просто забыть старый формат (или поддерживать его на таком уровне, чтобы работать со старыми цепочками).
Но сложность теоретических проблем, связанных с атакой временных ограничений, может оказаться не стоящей усилий на её исправление, в зависимости от сложности кода.
То, что мы определенно сделаем
Доктор Джонсон Лау создал очень интересный проект под названием спуннет: он пытается подключить к своему хард-форку (или точнее сказать хард-спуну), много разных функций. И я настоятельно рекомендую почитать об этом. При этом, многие из предложенных функций весьма технические и тонкие.
Откровенно говоря, здесь необходимо отсеять лишнее: я, к слову, считаю, что изменения coinbase достойны внимания и весьма перспективны. Я не являюсь сторонником комплексных измерений размера блока: введение нескольких новых факторов значительно усложняет конструкцию.
Есть только одна вещь, которая для меня принципиально важна в будущих транзакциях – это изменение txid вычисления. Конкретнее — использование дерева Меркла, вместо линейного хеша с одной стороны, а с другой стороны — выходы. Благодаря этому можно будет доказать вывод, без предоставления полной транзакции. Это должно быть включено (если мы утвердим оба стиля txid сразу, это удвоит показатель индекса UTXO), скажем, при использовании верхнего бита транзакции по nVersion.
Мы можем просто ограничить старые транзакции (те, которые существовали до SegWit) до 100k (фактически, это можно было бы назвать софт-форком). Этот шаг уменьшил бы угрозу от разного рода атак, а так как большие транзакции уже являются нестандартными и не могут перемещаться по сети, то им будет нужна непосредственная помощь майнеров при любом раскладе.
Стоит ли увеличивать размер блока?
По всей видимости, разработчики всё-таки приближаются к консенсусу относительно двух вопросов: во-первых, наиболее безопасный способ увеличить размер блока это позволить транзакциям, активным до segwit получить скидку [с SegWit] и во-вторых, постепенное по времени увеличение размера блока.
Расширение
Когда «witnessed» были разделены (новым типом транзакции), «witnessed» (читай – подписи) начали считаться 1/4 от всей транзакции. На практике это выглядит так:
Люк-младший отметил, что если мы собираемся активировать хард-форк, мы можем предоставить такую скидку старым, созданным до segwit, транзакциям. Это будет иметь моментальный эффект и удвоит мощность транзакций, не делая зло (блоки по 4MB), ещё большим злом. Должен упомянуть некоторые технические изменения, так как нельзя откинуть полностью пользователей, не активировавших segwit. Необходимо добавить 32 байта в эффективный размер, чтобы отразить, что мы всё ещё помним ID транзакции. Как по мне – это выигрышный вариант.
Этот эффект может помочь избежать шока на рынке сборов, но этот шаг может показаться совершенно искусственным и произвольным, и не получить достаточную поддержку сообщества.
Увеличения размера
Два года назад Питер Вуйле опубликовал черновик BIP «Размер блока в аспекте технологического роста», в котором предлагал увеличивать размер блока ежегодно на 17,7% (тогда это казалось лучшим вариантом развития событий). Моя ставка была между 17% и 19%; справедливости ради скажу, что CISCO VNI предполагает, что в следующие 5 лет произойдет рост на 14%.
Люк-младший одобрил этот подход, хотя и с уточнением относительно отправной точки: общепринятый риск попыток оценить будущий рост, по-видимому, ничтожен, по сравнению с политическим и операционным риском, требующим повторного хард-форка для дальнейшего увеличения.
Консервативное предложение может начать рост через год (52596 блоков?) после первоначального хард-форка, чтобы позволить рынку адаптироваться к новой [транзакционной] ёмкости.
Гибкий размер блока
Идея создания размера блока подходящего для «прокачки» [транзакционной] ёмкости всплывает время от времени (так называемый «flexcap»), но схемы, которые я видел, работают лучше всего, как только доход от оплаты транзакций начинают значительно превышать «субсидию», в противном случае майнерам проще создавать пустые блоки (например, майнинг SPV), что не способствует увеличению пропускной способности сети. Существует также большое количество настроек, без четкого указания о том, что с ними делать.
Поэтому, если в ближайшее время не появится новое исследование, я, хоть с неохотой предлагаю такие изменения (оно может быть проведено софт-форком, но в таком случае это может уменьшить размер блока). Пожалуйста, докажите, что я ошибаюсь.
Измерение консенсуса
В идеале, было бы здорово обсудить идеальный консенсус относительно хард-форка, но как узнать заранее? Об этом поговорим во второй части…
Источник: cryptocurrency.tech