Мягкий форк, жесткий форк, по умолчанию и обязательный

Автор: Vitalik Buterin

Исходное название: 《Hard Forks, Soft Forks, Defaults and Coercion》

Дата публикации: 14 марта 2017 года

В обсуждении тем, связанных с блокчейном, существует очень важная дискуссия о том, что лучше в механизме обновления протокола: предпочитать мягкие форки или жесткие форки. Основное различие между мягкими и жесткими форками заключается в том, что мягкий форк изменяет правила протокола, строго уменьшая количество действительных транзакций, поэтому узлы, следуя старым правилам протокола, все еще могут оставаться на новой цепочке (при условии, что большинство майнеров/валидаторов поддерживают форк), в то время как жесткий форк позволяет ранее недействительным транзакциям и блокам стать действительными, поэтому пользователи должны обновить свои клиенты, чтобы оставаться на новой цепочке после жесткого форка. В жестком форке есть два подтипа жестких форков: 1. Полностью расширяющий жесткий форк (strictly expanding hard forks), который полностью расширяет набор действительных транзакций, и поэтому старые правила могут эффективно совместиться с новыми правилами, 2. Двусторонний жесткий форк (bilateral hard forks), в котором оба набора правил несовместимы.

Здесь используется диаграмма Венна для иллюстрации типов форков:

Обычно упоминаются два преимущества:

1. Жесткие форки дают разработчикам большую гибкость при обновлении протокола, поскольку им не нужно дополнительно учитывать, подходят ли новые правила к старым правилам.
2. Мягкие форки более удобны для пользователей, поскольку пользователи могут продолжать оставаться на новой цепочке без дополнительных обновлений.
3. Мягкие форки менее вероятно приведут к расколу цепочки.
4. Мягкие форки в истинном смысле требуют лишь согласия майнеров/валидаторов (даже если пользователи используют старые правила, если узел заставляет эту цепочку использовать новые правила, то только транзакции, действительные по новым правилам, могут попасть в цепочку, и это всегда так). В то время как жесткий форк требует от пользователей выбора согласия.

Кроме того, основная критика жестких форков заключается в том, что жесткие форки являются "принудительными". Здесь под принудительностью подразумевается не физическая сила, а скорее принудительность сетевого эффекта. То есть, если сеть меняет правила с A на B, то даже если вы лично больше склоняетесь к A, если большинство пользователей предпочитает B и переключается на B, то даже если вам не нравится B и вы не согласны с переходом на B, чтобы оставаться синхронизированным с другими в одной сети, вы также должны переключиться на B.

Сторонники жестких форков обычно высмеиваются как пытающиеся оказать "враждебное влияние" на сеть и "принуждающие" пользователей следовать за ними. Кроме того, риск раскола цепочки обычно связан с тем, что жесткие форки небезопасны.

Лично я считаю, что эти критические замечания ошибочны. И в многих ситуациях эти случаи часто противоположны. Эта точка зрения не специфична для Ethereum, Bitcoin или других блокчейнов; она исходит из общих характеристик этих систем и применима к любому из них. Кроме того, нижеизложенные аргументы относятся только к спорным изменениям, в которых хотя бы одна из групп (майнеры/валидаторы и пользователи) имеет значительное количество несогласных; если изменение не является очень спорным, то его можно выполнить очень безопасно, независимо от формы этого форка.

Сначала давайте обсудим вопрос принудительности. Как мягкие, так и жесткие форки в той или иной степени изменяют протокол, что не нравится некоторым пользователям. Особенно когда этот протокол не получает 100% поддержки, изменение этого протокола вызывает недовольство у части пользователей. Кроме того, практически неизбежно, что в любых обстоятельствах несогласные больше ценят сетевой эффект синхронизации с большинством, чем свои предпочтения в протоколе. Таким образом, в этом смысле сетевого эффекта оба типа форков являются принудительными.

Тем не менее, между мягкими и жесткими форками существует принципиальное различие: жесткий форк является выборочным присоединением, в то время как мягкий форк не оставляет пользователям выбора. Чтобы пользователю было удобно присоединиться к цепочке жесткого форка, ему необходимо самостоятельно установить пакет программного обеспечения для реализации правил форка, и реакция группы пользователей, не согласных с изменением правил, будет более сильной, чем их ценность сетевого эффекта, теоретически они могут остаться на старой цепочке — и на самом деле, такое уже происходило.

Это применимо как к полностью расширяющим жестким форкам, так и к двусторонним жестким форкам. Однако в случае мягкого форка, если форк успешен, то цепочка без форка больше не существует. Таким образом, мягкий форк явно более системно склонен к принуждению, чем к разделению, в то время как жесткий форк имеет противоположную тенденцию. Моя личная моральная позиция заставляет меня больше поддерживать разделение, чем принуждение, хотя другие могут не согласиться (самый распространенный аргумент заключается в том, что сетевой эффект действительно очень важен, и для "правила одной монеты" он необходим, хотя существуют и более мягкие версии).

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

Теперь давайте рассмотрим спорные форки, особенно те, которые конфликтуют с предпочтениями майнеров/валидаторов и пользователей. Здесь есть три случая: (i) двусторонний жесткий форк (ii) полностью расширяющий жесткий форк, (iii) так называемый "пользовательский активированный мягкий форк" (UASF), четвертый тип — это активация мягкого форка майнерами без согласия пользователей. Позже мы упомянем его.

Сначала я расскажу о двустороннем жестком форке. В идеальных условиях этот сценарий очень прост. Две монеты торгуются на рынке, трейдеры решают относительную ценность двух монет. Из примера ETH/ETC у нас есть подавляющее большинство доказательств того, что большинство майнеров предпочитают распределять свою вычислительную мощность между монетами в зависимости от ценового соотношения, чтобы максимизировать свою прибыль и доход, не учитывая свои исторические взгляды на распределение вычислительной мощности.

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

Здесь есть два крайних случая. Первый вариант: из-за неэффективного алгоритма регулировки сложности ценность майнинга падает из-за падения ценности монеты, но сложность майнинга не снижается. Это делает майнинг очень убыточным и невыгодным. Ни один майнер не будет продолжать продвигать цепочку вперед, если это не приносит прибыли, пока сложность не восстановится в равновесии. Это не случай Ethereum, но это может быть случаем Bitcoin. Поэтому цепочка с малой вычислительной мощностью может никогда не подняться, и, следовательно, она умрет. Обратите внимание, что это не обязательно хорошо, ответ зависит от вашего взгляда на принуждение и раскол. С моей точки зрения, я считаю, что такая цепочка с малой вычислительной мощностью с враждебным алгоритмом регулировки сложности — это не хорошо.

Второй крайний случай заключается в том, что если разница очень велика, цепочка с большой вычислительной мощностью может атаковать цепочку с малой вычислительной мощностью с помощью атаки 51%. Но даже если соотношение ETH/ETC составляет 10:1, такая атака не произошла. Так что это определенно не однозначный ответ. Однако, если майнеры на ведущей цепочке предпочитают принуждение и допускают отклонения, то эти майнеры всегда найдут способ добиться этого.

Теперь давайте посмотрим на полностью расширяющий жесткий форк (SEHF). В SEHF существуют свойства нефоркнутой цепочки, действительные по правилам форка, поэтому, если цепочка форка имеет более низкую цену, чем нефоркнутая цепочка, то вычислительная мощность цепочки форка будет ниже, чем у нефоркнутой цепочки, и поэтому нефоркнутая цепочка в конечном итоге будет принята оригинальным клиентом и клиентом форка как самая длинная цепочка. Таким образом, постепенно цепочка форка будет "поглощена".

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

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

Последний упомянутый тип форка — это пользовательский активированный мягкий форк. В UASF пользователи могут напрямую активировать правила мягкого форка, не заботясь о том, получено ли согласие майнеров; майнеры могут быть исключены из экономических интересов. Если очень много пользователей не следуют этому UASF, то эта монета будет разделена, что приведет к ситуации, аналогичной полностью расширяющему жесткому форку. Даже если UASF является выборочным, он использует экономическую асимметрию, чтобы сделать себя более склонным к успеху (хотя эта предвзятость не абсолютна, если этот UASF считается непопулярным, он также не будет успешным, и это приведет только к расколу блокчейна).

Тем не менее, пользовательский активированный мягкий форк — это опасная игра. Например, предположим, что разработчики проекта хотят создать патч UASF, который преобразует ранее принимаемые все транзакции неиспользуемых операционных кодов в транзакции, которые принимают только соответствующие некоторым новым функциям правила, что будет спорным как в политическом, так и в техническом плане, и майнеры вряд ли будут довольны этой функцией. У майнеров есть умный и хитрый способ противостоять этой ситуации: они могут в одностороннем порядке реализовать мягкий форк, активируемый майнерами (miner-activated soft fork), который будет всегда приводить к сбоям функций, созданных с помощью мягкого форка.

Теперь у нас есть три правила:

1. Операционный код X всегда действителен по оригинальному правилу.
2. Операционный код X действителен только тогда, когда другие транзакции соответствуют новым правилам.
3. Операционный код X всегда недействителен.

Обратите внимание, что пункт 2 является мягким форком по отношению к пункту 1, а пункт 3 является мягким форком по отношению к пункту 2. Теперь на пункт 3 существует сильное экономическое давление, поэтому мягкий форк не может достичь своей цели.

Таким образом, мой вывод таков: мягкий форк — это опасная игра, особенно когда они являются спорными, когда майнеры начинают контратаковать, эта игра становится все более опасной. Полностью расширяющий жесткий форк также является опасной игрой. Мягкий форк, активируемый майнерами, является принудительным, в то время как пользовательский активированный мягкий форк не так уж и принудителен, но из-за формирования экономического давления, выбор пользователя активировать мягкий форк все же имеет некоторую принудительность, что также имеет определенную опасность. Если вы действительно хотите провести спорное изменение и настаиваете на том, что социальные затраты, которые вы понесли, оправданы, то сделайте чистый и простой двусторонний жесткий форк, потратьте время на добавление защиты от повторных атак, а затем позвольте рынку, этой невидимой руке, помочь вам разобраться.