Реорганизация сети ETH 2.0 25 мая на 7 блоков

Мартин Коппельман (Gnosis) рассуждает по поводу внезапной реорганизации beacon сети ETH 2.0 вчера:

https://twitter.com/koeppelmann/status/1529832225272897536

«Сеть beacon Ethereum пережила глубокую реорганизацию на 7 блоков 25 мая.

Почему это не так страшно, как выглядело:

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

Я не согласен с теми, кто утверждает, что «7 блоков - это всего 84 секунды» / «вы все равно должны дождаться финализации» / «это не проблема».

Реальность такова, что разветвление/реорганизация в 7 блоков в Ethereum не случалась годами, и это могло бы вызвать значительные проблемы для многих приложений.

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

Если нет чертовски веской причины (глобальные проблемы с интернет-инфраструктурой, массированная атака очень крупного валидатора ...), реорганизация 7 блоков НЕ ДОЛЖНА происходить.

Есть ответ на то, почему это произошло, и причина не в чем-то фундаментальном для пруф оф стейк консенсуса Ethereum, а в том, что можно и НУЖНО предотвратить в будущем!

Причина заключалась в том, что валидаторы строили свое поведение в зависимости от того, что они считали «лучшим блоком».

Рассмотрим следующую ситуацию.

Есть сеть, в которой есть клиенты сети n+1, n+2, n+3, n+4.

n+2 следует за n+1

n+3 вместо того, чтобы следовать за действиями n+2, сразу обратился к n+1

Предположим вы = n+4

Вам нужно решить, продолжать ли следовать за валидатором n + 3 или идти за n + 2.

Во-первых, вы можете подумать: n + 3 был злоумышленником и целенаправленно игнорировал n + 2, чтобы попытаться реорганизовать блокчейн, игнорируя n + 2. Однако - также возможно, что n + 2 намеренно сдерживал добычу своего блока, не давая n + 3 другого выбора, кроме как строить свои решения на n + 1 (предварительная реорганизация).

В зависимости от того, как большинство клиентов ведут себя в ситуации n + 4, злоумышленнику будет либо проще выполнять реорганизации ex-post (игнорируя n+2), либо ex-ante (следуя за n+3). Теперь исследования показали, что раньше провести реорганизацию ex-post было очень трудно, но реорганизация ex-ante была в некоторой степени возможна.

Изменение в поведении клиента: «proposer boost» было предназначено для того, чтобы найти лучший баланс, чтобы быть в безопасности от обоих видов атак. Однако - то, как это изменение было распространено в клиентах сети, это это было ошибкой.

Хотя технически это не было изменением, нарушающим консенсус (клиенты с обеими реализациями все равно в конечном итоге придут к консенсусу друг с другом), изменение правил того, что считать лучшим блоком * ДЛЯ НЕКОТОРЫХ КЛИЕНТОВ *, сделает реорганизацию намного более вероятной.

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

Это привело к ситуации, когда примерно 50% сети использовали правило A и 50% правило B.

Вывод таков: подобные изменения должны быть внедрены как хардфорки. С определенным моментом времени (номером блока), когда они активируются, и четким сообщением о необходимости обновить клиенты валидаторов.

Вкратце: если в будущем к таким обновлениям будут подходить более внимательно, нет никаких оснований полагать, что в будущем мы будем регулярно сталкиваться с реорганизациями Ethereum POS на глубину 7 блоков».