Стандарт предлагает перенести управление депозитом валидатора на Execution Layer и устраняет необходимость в
eth1data голосовании. 🫣 Уфф, тут я подумал о том, как я мало знаю об Ethereum. Ну что ж, давайте разбираться.
▫️ Депозит валидатора
Здесь все просто: для того, чтобы стать валидатором нужно задепозить 32 ETH. В прошлых выпусках мы уже узнали, что эта цифра измениться вместе с Pectra. Но не суть, главное, что технически для это существует депозитный контракт.
Депозитный контракт — это системный смарт-контракт, развернутый на уровне исполнения и имеющий две функции:
- прием депозита для активации или пополнения баланса валидатора;
- регистрация события через EVM.
Для хранения информации о депозитах используется дерево Меркла. Оно, конечно, оптимизировано для вычисления корня, хранит только одну ветку и избегает хранения всех узлов в сети. Все ради того, чтобы можно было криптографически доказать, что определенный депозит является частью всей системы. Это прям отдельная история.
▫️ Как депозит работает сейчас?
Когда происходит депозит на системный контракт, то уровень исполнения об этом знает, он его обрабатывает. Но на уровне консенсуса об этом "ни сном ни духом", хотя казалось бы, там нужно встречать вновь прибывшего валидатора. Поэтому еще до форка "The Merge" был разработан мост Eth1-Eth2 для передачи информации о депозите между слоями исполнения и консенсуса.
Тогда уровень исполнения назывался Ethereum 1.0, а консенсуса Ethereum 2.0. Это чтобы понять откуда название моста взялось. В момент перехода c PoW на PoS мост был действительно необходим. В какой-то момент перехода узлы с консенсусом Eth 2.0 конкурировали в добавление новых блоков с Eth 1.0 и просто не могли делать свою работу без доверия к Eth 1.0.
А что делали с депозитами валидаторов на тот момент? Чтобы новый консенсус мог узнать о депозите валидатора, а старый консенсус не мог что-то испортить, был придуман процесс Eth1Data poll. Постоянный поллинг Eth1Data позволял новому консенсусу Eth 2.0 (он же Beacon Chain) получить состояние контракта депозита и прийти к консенсусу относительно списка валидаторов. Таким образом, в этой схеме исключены майнеры, так как они не рисковали эфиром, а значит в новой парадигме PoS им нельзя доверять.
Здесь нужно отметить, что получение Eth1Data совсем не быстрый процесс. Он занимает 2048 слотов и требует включения в блок, что несет за собой полноценный процесс голосования валидаторов по-этому вопросу.
▫️ Как это будет работать?
Уровень исполнения будет самостоятельно следить за контрактом депозита, проверять по дереву Меркла и поставлять данные консенсусу. Никакого poll. Никакого моста. Информация по депозитам будет добавляться в так называемый "execution payload" Beacon блока и валидатору останется только сверить список из блока со своим.
▫️Что это дает?
- Повышение безопасности. Вероятность влияния на мост сейчас низкая, но она есть. Передача проверки депозитов непосредственно валидаторами повышает безопасность, так как исключает уязвимый мост из процесса.
- 13 минут обработки депозита вместо 12 часов. Нет моста, нет смысла и в задержках, которые защищали от различного рода атак.
- Упрощение сложности. Все, что связано с полингом и мостом теперь красивыми частями распределяется между слоем исполнения и консенсуса. Реализация целого EIP-4881 по регламентации снепшотов контракта депозита идет под нож.
▫️ Вывод
Механизм обработки депозитов сейчас — это накопленный технический долг с форка The Merge. EIP-6110 должен помочь этот долг подчистить. Однако, интересный момент заключается в том, что стандарт требует от валидаторов включать данные о депозитах в блоки, что потенциально может сказаться на размере данных блокчейна. Предварительно прирост оценивается в 60MB в год и утверждается, что это незначительно. Есть и другие потенциальные недостатки. С ними можно ознакомится в тексте EIP.
Отдельное спасибо статье EIPs For Nerds #4, которая во многом легла в основу этого поста. Кому интересны детали, вам точно туда.
#в_гостях_у_Pectra #павел_найданов