Внутри обновлений Ethereum: Hegotá

Что Ethlabs считает приоритетным для Hegotá и почему.

Направление развития Ethereum важно для всех, кто строит на нём, использует его, держит ETH или просто верит в его потенциал. Хотя это будущее в конечном счёте будет определяться людьми, приложениями и сообществами, ежедневно строящими на Ethereum, сетевые обновления являются одним из основных способов эволюции протокола для удовлетворения их потребностей. Hegotá — следующее запланированное обновление сети Ethereum после Glamsterdam, и этот документ представляет взгляд Ethlabs на то, что, по нашему мнению, Ethereum должно сделать приоритетом для него, и почему.

Ethlabs — это 8-недельная некоммерческая R&D лаборатория для Ethereum и ETH, и наша миссия — сделать Ethereum расчётным слоем глобальной экономики. Мы находимся между реальным использованием Ethereum и разработкой протокола, и мы тратим время на то, чтобы слушать пользователей, кошельки, приложения, роллапы, институции, держателей ETH, исследователей и команды клиентов. Иногда мы даже строим ончейн, потому что нельзя построить арену, не участвуя в ней! Мы верим, что отличная инженерия протокола должна делать возможными отличные продукты, а отличные продукты должны помогать определять, куда протокол движется дальше.

Объём Hegotá в настоящее время находится на ранних стадиях формирования через открытый технический процесс Ethereum, и предложения ниже отражают работу многих людей, исследовательских групп и команд клиентов. Этот документ — прозрачный отчёт о том, что мы рекомендуем в качестве приоритетов и где наши взгляды ещё формируются. Это позиции, которые мы хотели бы, чтобы другие оценили, оспорили и помогли улучшить, и мы будем их дорабатывать по мере обсуждения и получения новых знаний в ближайшие дни и недели.

Для обновления Hegotá, учитывая все предложенные EIP, мы видим следующие области как наивысший приоритет для Ethereum:

1. Более сильная устойчивость к цензуре: Любой должен иметь возможность включить транзакцию, независимо от того, кто он и для чего использует Ethereum.
2. Более быстрый Ethereum: Более быстрые блоки означают более быстрое подтверждение, более свежие ончейн-цены и более быструю финализацию.
3. Нативная абстракция аккаунтов: Аккаунты должны поддерживать passkeys, спонсируемые транзакции, оплату газа в токенах, пакетирование и более сильную конфиденциальность, с путём к пост-квантовым ключам.
4. Продолжающееся масштабирование L1: Приложениям нужна ёмкость, которая остаётся доступной и предсказуемой, даже при скачках спроса.

Работа в открытую — основная цель Ethlabs, поэтому мы пишем еженедельные обновления и, в таких случаях, как этот, публикуем очень длинные технические статьи, чтобы поделиться своими мыслями 😅. В ближайшие недели мы также опубликуем более короткий контент для тех, кому нужны только основные моменты. Следующая часть будет длинной и технической. Тем из вас, кто прочитает всё это, — удачи!

С чего начать: как вообще работает процесс EIP?

Прежде чем углубляться в сами предложения, один важный момент: вторая фаза процесса определения объёма Hegotá только началась. Первая фаза выбрала FOCIL в качестве заголовка Hegotá. 6 августа был крайний срок для предложения не-заголовочных EIP, и процесс ACD теперь перейдёт к оценке обновления Hegotá в целом.

Все EIP ниже в настоящее время находятся на стадии PFI (Proposed for Inclusion), за исключением EIP, прошедших через процесс заголовка. Предложение EIP для включения разрешено без разрешения, и большинство из них никогда не попадают в финальное обновление.

В частности, по мере продвижения работы по реализации, предложения проходят через постепенно усиливающиеся стадии проверки и уверенности в конечном запуске:

• PFI (Proposed for Inclusion): идея была предложена для обновления. Этот этап не требует разрешения и не подразумевает поддержки клиента или окончательного включения.
• CFI (Considered for Inclusion): команды клиентов рассмотрели предложение и намерены создать прототип и протестировать его.
• SFI (Scheduled for Inclusion): существует широкая заинтересованность во включении, при условии, что реализация и тестирование продолжатся успешно.

Чтобы узнать больше о том, как работает этот процесс, мы рекомендуем посмотреть краткое объяснение Тима Бейко здесь.

Организационные моменты: как ориентироваться в этой статье

Мы следуем рейтингу уровней Forkcast, чтобы выразить наше мнение о приоритетности EIP для Hegotá. Чтобы минимизировать принятие решений, мы распределяем все рассмотренные EIP по четырём уровням со следующими интерпретациями:

• [S-уровень] настоятельно рекомендуем к включению.
• [A-уровень] рекомендуем к включению, если будут устранены оставшиеся препятствия, такие как сложность реализации, анализ влияния или принятие.
• [B-уровень] стоящие, но сложные для этого обновления.
• [D-уровень] не рекомендуем к включению в Hegotá в текущей форме.
• [формируем мнение] мы всё ещё формируем своё мнение по этому EIP.

Пожалуйста, учтите, что это \рекомендации\ Ethlabs. Мы оцениваем каждое предложение в основном с точки зрения цели, спецификации и нашего понимания вероятной сложности реализации, за исключением случаев, когда у нас есть большая уверенность или прямое участие (например, Frames и Quick Slots), и будем обновлять наше мнение на основе оценок от ethPandaOps, команд тестирования и клиентов по мере продвижения процесса.

[CL] означает, что EIP затрагивает клиенты консенсус-слоя, а [EL] означает, что он затрагивает клиенты слоя исполнения.

Обратите внимание, что мы являемся соавторами и участвуем в нескольких EIP (включая FOCIL, Frame Transactions и Quick Slots). Хотя мы стремимся оценивать все EIP независимо от нашего участия или его отсутствия, пожалуйста, учитывайте это при оценке нашей позиции.

Краткое содержание

Рейтинг CL

Вы можете поэкспериментировать с этим конкретным рейтингом [CL] на Forkcaster здесь.

Рейтинг EL

Вы можете поэкспериментировать с этим конкретным рейтингом [EL] на Forkcaster здесь.

А теперь, без лишних слов, вот наши взгляды на обновление Hegota в том виде, в каком они есть сегодня, в полном объёме:

Темы для Hegotá

0. FOCIL: усиление устойчивости к цензуре

EIP-7805: FOCIL уже имеет статус SFI и подтверждён как заголовок Hegotá. Три члена команды Ethlabs (Франческо, Барнабе и Джулиан) входят в число его соавторов, и мы решительно поддерживаем его включение. Учитывая, что решение уже принято, мы будем кратки. Только цепочка, нейтральная по отношению ко всем, может стать корнем доверия для всех. Это позволяет Ethereum масштабироваться, чтобы стать истинным расчётным слоем для глобальной экономики и для каждого человека в ней.

1. Quick Slots: Более быстрый Ethereum

12-секундный слот Ethereum — это задержка, которая снижает ценность для пользователя. Поэтому мы настоятельно рекомендуем включить [CL] EIP-8198: Quick Slots [S-уровень] в Hegotá по четырём причинам:

1. Улучшенный UX на L1 с более быстрым подтверждением транзакций.
2. Ончейн-рынки на L1 работают с более свежими ценами, улучшая спреды и экономику LP.
3. Финализация и правило быстрого подтверждения наследуют время слота, поэтому оба становятся быстрее с более быстрыми блоками, улучшая интероперабельность с Ethereum.
4. Больше proposer'ов блоков в секунду означает повышенную устойчивость к цензуре, включая экономическую устойчивость к цензуре: сумму, которую нужно заплатить, чтобы держать блоки пустыми в течение некоторого периода времени.

Ускорение при сохранении уникальной децентрализации Ethereum делает блокспейс Ethereum более ценным, и эта ценность поступает в сеть и в ETH. Каждое уменьшение — это немедленная доставка большей ценности нашим пользователям. Наконец, более быстрые блоки являются одним из наиболее часто запрашиваемых изменений от разработчиков приложений.

Аргумент в пользу начала сейчас заключается в том, что уменьшение времени слота никогда не будет одноразовым изменением. Как и в случае с масштабированием, реализованные уменьшения дают приложениям больше уверенности, чем обещания в дорожной карте. Путь к слотам менее 6 секунд начинается с того, что время слота становится изменяемым, а затем изменяется итеративно. EIP-8198 разделяет работу на две части:

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

Hegotá — правильный форк, чтобы оплатить одноразовые затраты. ePBS в Glamsterdam уже реструктурирует слот. Hegotá тогда является сравнительно лёгким форком для консенсус-слоя, окно, которое закрывается с декуплированным консенсусом в I*, так что пропускная способность CL для одноразового рефакторинга доступна сейчас так, как не будет доступна в течение нескольких форков.

Это означает: мы либо обязуемся оставаться на 12 секундах как минимум в течение следующих двух лет, либо получим 10 секунд примерно через год в Hegotá и, возможно, менее 10 секунд через год после этого. Эти два уменьшения — не теоретические улучшения. Они напрямую приносят повышенную ценность пользователям и улучшают экономику сети. Мы считаем, что пришло время начинать.

Наиболее распространённые возражения

Здесь мы обсуждаем 4 важных момента, которые были подняты во время предварительных обсуждений с разработчиками клиентов и EF Protocol:

1. Сложность реализации: Тайминг слотов с миллисекундной точностью уже объединён в спецификации консенсуса через работу над ePBS, и существуют черновики CL и EL спецификаций для EIP-8198, с пересчитанными базовой комиссией, лимитом газа и расписанием blob'ов для сохранения поведения в секунду. Оставшаяся стоимость — это хвост крайних случаев в клиентах и инструментарии, которые предполагают фиксированное время слота, плюс тестирование. Одноразовый рефакторинг как раз и выполняет эту работу заранее. После этого каждое уменьшение является изменением параметра.

2. Доказательства zkEVM: Две основные проблемы — это относительное время доказательства и постоянные накладные расходы на доказательство.

2.1 Относительное время доказательства измеряет долю времени слота, выделяемую на доказательство, и то, как эта доля меняется при изменении времени слота. Вот краткое описание соответствующих моментов в слоте. Текущие строители наблюдают за выпуском предыдущего полезного груза и могут начать строительство немедленно. Затем текущий beacon-блок фиксирует полезный груз текущего слота. Этот полезный груз должен быть доказан до выпуска блока следующим beacon-proposer'ом.

Для доказательства минимальное относительное время — это полный слот минус задержка выпуска beacon-блока. Задержка выпуска beacon-блока несжимаема, но по построению коротка, следовательно, на данном этапе она принципиально нас не ограничивает. Также существует возможность, что оптимизированные строители будут совместно доказывать полезный груз во время его построения, что позволит им начать доказательство до того, как выигравший полезный груз будет зафиксирован proposer'ом beacon-блока.

2.2 Доказательство zkEVM в основном масштабируется линейно с размером блока, за исключением некоторых фиксированных накладных расходов. Более быстрые слоты означают, что фиксированные накладные расходы оплачиваются чаще, что добавляет больше задержки для того же объёма пропускной способности. При заданном фиксированном бюджете задержки необходимо убедиться, что хорошая пропускная способность всё ещё может быть получена. Здесь мы видим две возможности: Во-первых, инженерный прогресс будет продолжать снижать задержку этих фиксированных операций. Во-вторых, отсрочка вычисления корня состояния, как описано в EIP-7862, выводит большую часть доказательства за пределы критического пути, что означает, что мы можем увеличить наш бюджет задержки для несжимаемых операций. Схождение этих двух возможностей говорит нам о том, что более быстрые слоты не помешают значительному увеличению пропускной способности в будущем.

3. Пост-квантовый переход: Подход с декуплированным консенсусом получил достаточную поддержку, чтобы считаться стабильным в отношении будущей архитектуры консенсуса. Декуплинг означает вынесение голосования за финализацию за пределы критического пути производства блоков. В частности, крупномасштабная агрегация PQ-подписей и все связанные рекурсивные STARK-механизмы будут находиться вне критического пути. То, что остаётся для производства блоков и получения правила выбора форка для отслеживания головы результирующей цепочки, — это подкомитет, который, как ожидается, будет состоять из 512 валидаторов, а возможно, и 256. Размеры пост-квантовых подписей больше, но их можно комфортно распространять в пределах предлагаемого времени слота в 10 секунд и, вероятно, меньше в будущем.

4. Смарт-контракты и инфраструктура: Зависимость от времени слота в смарт-контрактах и инфраструктуре в настоящее время исследуется. Для смарт-контрактов мы объединились с Sourcify, чтобы провести анализ всех верифицированных контрактов. Мы изучаем влияние обновления времени слота на исторические корни beacon-блоков, хранящиеся в соответствии с EIP-4788: Beacon block root in the EVM. Что касается инфраструктуры, то, по анекдотическим данным, Etherscan упомянул, что изменение времени слота, вероятно, приведёт к большей нагрузке, но инфраструктура была построена во времена переменного времени слотов в Proof-of-Work, поэтому не требует больших изменений.

2. Абстракция аккаунтов: улучшение UX, безопасности и конфиденциальности

Ethereum и его более широкая экосистема давно ждут нативную AA, которая принесёт такие преимущества UX, как кошельки с passkeys, спонсируемые транзакции, оплата газа в ERC20, пакетирование транзакций и многое другое.

Однако путь к нативной AA был особенно тернист, потому что AA затрагивает каждую часть стека Ethereum, включая клиенты, L2, кошельки, RPC, инструменты разработчика и т. д., поэтому требует одобрения огромного разнообразия заинтересованных сторон. Это затрудняет продвижение любого EIP по AA через консенсусный процесс разработки Ethereum, а также достижение практического принятия после запуска EIP.

Поэтому мы помещаем предложение Hegotá по нативной AA, Frame Transactions, в A-уровень, не потому что оно технически недостаточно хорошо для S, а потому что мы хотим учесть риски практического принятия, для устранения которых потребуется огромная координация. Учитывая опыт нашей команды в AA, Ethlabs намерен сыграть важную роль в выводе Frame Transactions на рынок, работая с такими заинтересованными сторонами, как L2 и кошельки, для обеспечения успешного внедрения нативной AA.

Теперь перейдём к конкретным предложениям по AA для Hegotá.

[EL] EIP-8141: Frame Transactions [A-уровень]

Мы считаем, что EIP-8141: Frame Transactions является лучшим кандидатом для нативной системы AA Ethereum. По сравнению с другими предложениями по нативной AA, Frames обладает рядом желательных свойств, которые делают его уникально соответствующим мандату CROPS Ethereum:

• Разрешительные инновации в аккаунтах: логика валидации обрабатывается EVM-кодом, поэтому разработчики могут разрабатывать любую логику валидации, в отличие от некоторых других подходов AA, которые требуют белого списка логики валидации.
• Поддержка первого класса для протоколов конфиденциальности: как следствие первого пункта, протокол конфиденциальности, такой как Railgun, может обрабатывать логику валидации frame-транзакций, позволяя пользователям отправлять приватные транзакции, не полагаясь на централизованные ретрансляторы, как сегодня. Это делает протоколы конфиденциальности значительно более приватными и устойчивыми к цензуре.
• Пост-квантовая безопасность: frame-транзакции разрабатывались с учётом более широкой PQ-дорожной карты Ethereum. Например, frame-транзакции явно спроектированы так, чтобы подписи можно было агрегировать, что позволит Ethereum взимать низкую плату за газ для PQ-подписей, даже если каждая отдельная подпись может быть очень дорогой для проверки.

Основная слабость Frame Transactions также проистекает из их величайшей силы: поскольку валидация обрабатывается EVM-кодом, валидация теперь вызывает динамическую стоимость вместо фиксированной, что может создавать проблемы для цепочек с высоким TPS, таких как L2. Мы с оптимизмом смотрим на то, что эта проблема может быть решена с помощью дальнейших EIP или ERC поверх frame-транзакций, таких как EIP-7819, где транзакции могут статически указывать свою логику валидации, чтобы секвенсоры могли «сокращать» валидацию с помощью нативного кода при необходимости. Мы также намерены работать с L2 и EF для проведения бенчмарков frame-транзакций, чтобы выявить и устранить любые узкие места производительности.

[CL][EL] Дополнения к Frame Transactions

Существует ряд EIP, которые можно рассматривать как расширение Frame txs, развивающее их возможности.

[EL] [EIP-8250: Keyed Nonces for Frame Transactions](https://forkcast.org/eips/8250/) [A-уровень]

• Мы рассматриваем этот EIP как концептуальную часть EIP-8141: Frame Transactions и считаем, что он должен быть запущен вместе с ним.
• Этот EIP вводит 2D-нонсы для Frame-транзакций. 2D-нонсы позволяют аккаунтам отправлять параллельные транзакции в мемпул, а также позволяют протоколам конфиденциальности хранить nullifier'ы в качестве 2D-нонсов. Это важно, потому что 2D-нонсы — это специальное хранилище, которое стоит очень мало для чтения и хранения, поэтому приватные транзакции могут значительно экономить на газе по сравнению с хранением nullifier'ов в обычном динамическом хранилище, как сегодня. Это особенно важно в контексте переоценки стоимости хранения в Glamsterdam (EIP-8037: State Creation Gas Cost Increase).

[EL] [EIP-8272: Recent Roots for Frame Transactions](https://forkcast.org/eips/8272/) [B-уровень]

• Это ещё один EIP, улучшающий опыт использования протоколов конфиденциальности с Frame-транзакциями. Протоколам конфиденциальности необходим доступ к недавним корням обязательств во время валидации, которые, если хранить их в обычном хранилище, могут быть не только дорогими, но и конфликтовать с правилами публичного мемпула Frames. EIP-8272 решает эти проблемы, предоставляя системный контракт для хранения этих корней в кольцевом буфере, который автоматически очищает старые корни.
• Мы помещаем его в B-уровень, потому что этот EIP добавляет значительную сложность к frames для конкретного случая использования, и мы не уверены, может ли быть более общий/элегантный способ достижения той же цели.

[CL] [EIP-8369: VOPS Profiles for FOCIL Eligibility](https://forkcast.org/eips/8369/) [B-уровень]

• Этот EIP касается взаимодействия между Frames и VOPS (validity-only partial statelessness), который является предложением позволить узлам мемпула хранить ровно столько состояния, сколько необходимо для проверки транзакций, чтобы даже в мире без состояния (из-за zkEVM) мемпул оставался устойчивым к цензуре.
• Мы помещаем его в B-уровень, потому что этот EIP сильно привязан к определённому видению отсутствия состояния, по которому сообщество ещё не полностью достигло консенсуса.

[EL] [EIP-7906: Transaction Assertions via State Diff Opcode](https://forkcast.org/eips/7906/) [B-уровень]

• Этот EIP улучшает статическую проверяемость результатов транзакций. Пользователи уже могут утверждать, что должно произойти, но не то, что ничего другого не произошло. Доказательство отсутствия изменений состояния требует нового опкода. Сочетание положительных утверждений (например, баланс WETH увеличился как минимум на 1.5) с отрицательным утверждением (никаких других изменений состояния) позволяет пользователям ограничивать полные эффекты транзакции по построению, без симуляции, при этом аппаратные кошельки являются одним из явных бенефициаров.
• Учитывая сложность, включение его в хардфорк было бы очень ответственным выбором. Мы предлагаем сделать это только в том случае, если (a) команды клиентов действительно понимают нюансы и последствия этого конкретного EIP, и (b) поверхность тестирования и сложности очень хорошо поняты.

[EL] Миграция EOA [B-уровень]

[EL] EIP-7851: Code-Controlled EOA Delegation [B-уровень] и [EL] EIP-8151: Account Code Restricted ecRecover [B-уровень] лучше всего рассматривать как парные стандарты, которые вместе представляют историю того, как EOA могут перейти на смарт-аккаунты. В этой истории EOA сначала делегирует полномочия смарт-аккаунту через EIP-7702. Затем опкод, который вводит EIP-7851, делает делегирование 7702 постоянным, отключая корневой ключ ECDSA. С другой стороны, EIP-8151 сделает ecrecover осведомлённым о деактивации, чтобы старый ключ не мог вывести средства через потоки в стиле Permit.

Мы оцениваем эту пару в B-уровне, потому что это лишь один из многих подходов к миграции EOA на смарт-аккаунты, и этот конкретный подход не получил широкого обзора или одобрения. В частности, мы обеспокоены тем, что этот подход не отвечает на мультичейн-вопрос: как та же самая EOA мигрирует на L2? Пользователю пришлось бы выполнить то же самое действие на ВСЕХ цепочках, включая те, которые ещё не существуют, что приведёт к плохому UX. Мы подозреваем, что может быть лучший подход, при котором L2 могут использовать L1 как «корень доверия» для миграции EOA, поэтому мы резервируем A/S-уровни для подходов, которые позволят пользователям мигрировать один раз для всех EVM-цепочек.

[EL] Схема PQ-подписи [A-уровень]

Hegotá должен установить надёжный путь к пост-квантовым подписям, но мы должны подтвердить правильный механизм, прежде чем брать на себя обязательства.

• EIP-8355: Add ML-DSA verification прекомпилирует, делая пост-квантовую безопасность аккаунтов конкретной наряду с Frame Transactions.
• Альтернатива: предварительно зарегистрировать поддержку PQ без её активации или определить формат деривации, который сможет вместить PQ-ключи позже.

[EL] EIP-7819: Инструкция SETDELEGATE [A-уровень]

• Учитывая, что нативная AA, вероятно, появится в Hegota, важно, чтобы стоимость развёртывания новых смарт-аккаунтов была низкой, но развёртывание аккаунтов на самом деле станет дороже в Glamsterdam из-за EIP-8037. С помощью EIP-7819 новые аккаунты будут использовать простые делегирующие указатели вместо прокси-контрактов, что значительно уменьшит объём нового состояния, которое необходимо создать, тем самым снижая стоимость развёртывания.
• Мы помещаем этот EIP в A-уровень, потому что считаем, что более низкая стоимость развёртывания аккаунтов значительно снизит барьер для принятия AA.

3. Инженерия производительности: продолжающееся масштабирование L1

Glamsterdam ознаменовал сдвиг в подходе Ethereum к R&D, когда производительность рассматривается как ограничение первого класса как в дизайне протокола, так и в работе клиентов. Отложенное выполнение, переоценка ресурсов и множество работ по оптимизации клиентов позволили масштабироваться с 30M до (как минимум) 200M за последние два года. В целом, работа над производительностью даёт нам возможность выбора: полученный запас можно использовать для масштабирования, сокращения слотов, снижения требований к узлам или всего вышеперечисленного.

Сегодня мы по-прежнему считаем продолжающееся масштабирование необходимостью. Приложения решают, где строить, основываясь не только на текущих ценах, но и на том, может ли Ethereum предсказуемо расширять предложение блокспейса с течением времени. Последовательное обеспечение увеличения даёт больше уверенности, чем одни только обещания в дорожной карте. Пропускная способность мейннета также всё ещё довольно далека от возможности справляться со скачками спроса: на одиннадцатый день рождения Ethereum ежедневная медианная базовая комиссия составляла всего ~0.1 gwei, однако NFT-минт поднял её выше 10 gwei на некоторое время, при этом медианная стоимость транзакции достигла около $1, а 90-й перцентиль — более $5. Поэтому импульс масштабирования Glamsterdam должен продолжиться и в Hegotá.

В совокупности следующие EIP продолжают импульс масштабирования Glamsterdam, одновременно укрепляя более широкий принцип, лежащий в его основе: производительность должна оставаться проблемой первого класса как в работе клиентов, так и в дизайне протокола.

[EL] EIP-8131 и EIP-8279 [S-уровень]: Пакет переоценки данных

После Glamsterdam следующим узким местом становится распространение полезной нагрузки, отчасти потому, что различные источники байтов полезной нагрузки отражаются в учёте газа непоследовательно или не отражаются вовсе. EIP-8131: Unified Transaction Content Floor расширяет существующий минимальный уровень транзакции на контент, известный до выполнения, в то время как EIP-8279: Block Access List Byte Floor охватывает байты BAL, создаваемые динамически во время выполнения.

Это динамическое измерение делает EIP-8279 явно более сложным из двух. Однако мы предлагаем рассматривать их как единый пакет. Вместе они обеспечивают последовательный учёт байтов, связанных с транзакцией, ограничивая наихудший случай полезной нагрузки, оставляя при этом большинство обычных транзакций, не связанных с большими объёмами данных, без изменений. Это устраняет пробел в учёте ресурсов и открывает путь для дальнейшего увеличения лимита газа.

[CL][EL] EIP-8146: Block Access List Sidecars [Уровень A]

EIP-8146 дополняет переоценку, улучшая сам критический путь, за счёт отдельного распространения BAL от полезной нагрузки, что улучшает распространение и даёт клиентам выполнения фору в предварительной выборке состояния и вычислении корня пост-состояния. Мы видим в этом ту самую низко висящую оптимизацию, которую не следует упускать. Работа по внедрению в основном представляет собой знакомый механизм gossip на CL, что делает этот EIP малозатратным и высокоэффективным, особенно в форке, который, судя по всему, будет сильно нагружен изменениями на EL.

Другие связанные EIP

[EL] Перекалибровка CPSB [Уровень A]

• Очень простые изменения, рекомендуем держать их в работе и включить один из двух, если это будет сочтено необходимым на основе запланированного увеличения лимита газа и наблюдаемого использования газа состояния и выполнения.
• EIP-8368: CPSB Recalibration for New Gas Limit: Заранее запланированное продолжение EIP-8037, компенсирующее тот факт, что стоимость за байт состояния (CSPB) стала статической, а не функцией лимита газа, исключительно для упрощения реализации и тестирования. Идея заключалась в том, чтобы заменить корректировку от блока к блоку разовыми корректировками при форках, по мере необходимости, чтобы поддерживать рост состояния на целевом уровне при увеличении лимита газа. Поскольку текущий CPSB был откалиброван для лимита газа в 150M, вероятно, корректировка в Hegotá будет оправдана.
• EIP-8372: Normalized state gas limit: Всё ещё довольно минимальное расширение EIP-8368, позволяющее проводить более тонкую настройку, чем просто CPSB, компенсируя недостижение целевого показателя роста состояния или обычного целевого показателя газа из-за относительной неправильной ценообразования.

[EL] EIP-7862: Delayed State Root [Уровень B]

• Прост в спецификации, но, насколько нам известно, сложность реализации в клиентах не очень хорошо изучена. Корень состояния широко распространён в кодовых базах.
• Хотя есть некоторая выгода в снижении барьера для доступа к конкурентному построению блоков (быстрое вычисление корня состояния), наиболее существенный плюс этого EIP, по нашему мнению, в будущем (больше времени для доказательства вычисления корня состояния).
• EL уже является тяжёлой стороной в Hegotá.

[CL] EIP-8341: Partial Execution Payload Commitments [Уровень D]

• Рекомендуем отклонить: небольшая выгода (незначительная задержка вычисления корня состояния), не срочно, и заменяется EIP-7862: Delayed State Root (который даёт гораздо больше времени для этого).

Другие EIP

Теперь мы рассмотрим остальные EIP, сгруппированные по темам. По некоторым EIP мы всё ещё формируем своё мнение. Мы будем обновлять этот документ по мере получения дополнительной информации от команд клиентов и авторов EIP в ближайшие дни и недели.

Поскольку Hegotá, похоже, будет хардфорком с перекосом в сторону EL, мы предлагаем сохранять дисциплину и установить высокую планку для любого EIP на стороне EL. Мы считаем желательным сохранить Hegotá относительно лёгким на CL, помимо FOCIL и Quick Slots: более узкий круг вопросов сохраняет пропускную способность, чтобы дать командам клиентов пространство для подготовки к более крупному архитектурному переходу.

[CL] Эмиссия

Мы намеренно не присваиваем уровень EIP-8363: Tapered Issuance Burn. Мы считаем, что эмиссия — это не то решение, которое разработчики ядра должны принимать самостоятельно, а список уровней — это явная рекомендация разработчикам ядра. Для большинства EIP процесс ACD работает хорошо, поскольку решения носят в первую очередь технический характер, и сообщество эффективно делегировало их разработчикам ядра. Эмиссия отличается тем, что это вопрос денежно-кредитной политики, по которому само сообщество должно достичь примерного консенсуса. Мнение разработчиков ядра имеет значение, но как вклад в это публичное обсуждение. Ранжирование EIP-8363 наравне с другими EIP рассматривало бы его как обычное решение ACD, чем оно, по нашему мнению, не должно быть.

Технически мы видим смысл в изменении эмиссии в соответствии с EIP-8363. Проблемы, которые он решает, реальны: доверие к слэшингу снижается по мере увеличения объёма поставленного ETH, высокие коэффициенты стейкинга означают, что награды в основном компенсируют размытие, а эффект масштаба продолжает увеличивать разрыв между крупными операторами и соло-стейкерами. Изменение также сопряжено с рисками, от неопределённости эффектов до распределения стейка и сброса часов застывания денежно-кредитной политики. Тред Ансгара излагает обе стороны и отражает нашу позицию. Некоторые из нас в прошлом выступали за изменения эмиссии и продолжают придерживаться этого пути.

Мы рекомендуем принимать решение об эмиссии после всех остальных решений по объёму Hegotá. Это даст общественному обсуждению необходимое время и позволит избежать отвлечения от самого процесса определения объёма.

[CL] Функции стейкинга

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

[CL] EIP-8015: Remove deposit and eth1data fields [Уровень A]

• Очень простая очистка технического долга. Благодаря EIP-7688: Forward compatible consensus data structures, Merkle-доказательства несвязанных полей не затрагиваются, поэтому влияния на потребителей цепочки нет.

[EL][CL] EIP-8237: Independent CL/EL Sync [Уровень B]

• Развивает разделение beacon-блока и полезной нагрузки, введённое ePBS, позволяя EL и CL синхронизироваться независимо. Мы считаем, что это может упростить сложную часть клиентов Ethereum.

[CL] EIP-8205: Withdrawal credentials preregistration [Уровень D]

• Рекомендуем отклонить. Хотя EIP предлагает внутрипротокольное решение реальной проблемы в делегированном стейкинге, мы считаем, что существующее решение с предварительным депозитом является адекватным, и сложность добавляемого механизма в настоящее время не оправдана.

[CL] EIP-8148: Custom sweep threshold for validators [Уровень D]

• Рекомендуем отклонить. Мы считаем, что EIP слишком сложен (новый системный контракт, новый запрос на выполнение, механизмы CL) для своих преимуществ, которые мы видим в первую очередь как стимулирование некоторой незначительной дополнительной консолидации со стороны пула домашних операторов. Мы не думаем, что это сильно повлияет на общую консолидацию валидаторов, учитывая, как распределён стейк.

[CL] EIP-8375: ePBS Mandatory Burn of Execution Rewards [Уровень D]

• Рекомендуем отклонить. Мы считаем, что это, скорее всего, просто приведёт к большему количеству побочных каналов. Более того, многолетние обсуждения стратегий сжигания MEV не привели ни к одному предложению, достигшему широкого исследовательского консенсуса.

[CL] EIP-7716: Anti-correlation attestation penalties [Уровень D]

• Рекомендуем отклонить. Мы не считаем, что есть достаточно чётких доказательств того, что такое довольно масштабное изменение стимулов для стейкинга оправдано. Более того, стимулы для стейкинга, вероятно, будут переработаны в рамках развязанного консенсуса.

[CL] EIP-8333: Align Checkpoint with Epoch Boundary Block [Уровень D]

• Рекомендуем отклонить. Хотя это хорошая чистка, мы считаем, что стоит отложить её до предстоящего крупного перехода к развязанному консенсусу.

[CL] EIP-8359: Beacon Block Reporting Field [формируем мнение]

[CL] Дальнейшая подготовка к пост-квантовому переходу (PQ-prep)

Эти предложения уменьшают оставшиеся зависимости от BLS в преддверии будущего пост-квантового перехода.

[CL] EIP-8365: BLS withdrawal credential retirement [Уровень A]

• Выводит из обращения устаревшие учётные данные для вывода, подготавливая почву для упрощения протокола и упрощая будущий пост-квантовый переход.
• Учитывая, насколько это просто, мы считаем, что стоит включить это сейчас.

[CL] EIP-8367: Balance sunset for retired BLS validators [Уровень D]

• Рекомендуем отклонить. Мы считаем, что большинство валидаторов с 0x0, вероятно, изменят учётные данные (BLSToExecutionChange) до или после активации EIP-8365: BLS withdrawal credential retirement, либо для вывода своих средств, либо для возможности продолжать стейкинг. Мы не видим большой срочности во внедрении механизма для работы с оставшимся стейком 0x0. Мы рекомендуем просто включить EIP-8365 и посмотреть на результат, прежде чем принимать решение о следующих шагах.

[CL] EIP-8321: Hash-Chain RANDAO [Уровень D]

• Рекомендуем отклонить. Обеспечение пост-квантовой безопасности RANDAO в изоляции даёт мало протокольной безопасности, пока ключи валидаторов BLS остаются уязвимыми, но при этом добавляет примерно 32 байта на валидатора, новые механизмы управления секретами и в значительной степени одноцелевой механизм. Более широкая пост-квантовая архитектура консенсуса остаётся неопределённой. Мы поддерживаем итеративный переход, но его первый шаг должен следовать согласованной дорожной карте, а не рисковать быть заменённым окончательным дизайном.

[EL][CL] Подготовка к zkEVM

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

[CL] EIP-8025: Optional Execution Proofs [Уровень D]

• EIP не требует хардфорка. Предложение объединить его с Hegota является исключительно выражением приоритетности, и мы не согласны с этим выбором. Мы считаем, что работа над ним должна продолжаться, но Hegotá не должна быть заблокирована из-за него.
• Прежде чем внедрять опциональные доказательства, мы должны сначала определить конечное состояние, а затем ускориться в этом направлении, а не внедрять опциональные доказательства до того, как появится чёткое представление о долгосрочной модели валидатора/состояния.
• Ключевой открытый вопрос заключается в том, какую роль должны играть валидаторы в отношении состояния: должны ли они продолжать обслуживать или хранить его часть, а не стать полностью не сохраняющими состояние. Поскольку валидаторы являются основной когортой узлов с реальным аппаратным и сетевым значением, изменения, ослабляющие эту роль, должны преодолеть более высокий барьер.

[EL] EIP-7666: EVM-ify the identity precompile [Уровень A]

• Полезное, небольшое изменение.

[EL] EIP-8200: EVMification [Уровень B]

• EIP-8200 заменяет три нативных прекомпиля эквивалентным байт-кодом EVM. Два из них используются редко и, по-видимому, легко мигрируются. Третий широко используется в верификации SNARK, поэтому мы хотели бы получить оценку воздействия, прежде чем поддерживать его удаление.
• Если анализ воздействия покажет низкие затраты на миграцию для затронутых пользователей, или если третий прекомпиль будет исключён из области действия, мы переместим EIP-8200 на [Уровень A].

[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [Уровень D]

• Довольно разрушительно из-за очень большого увеличения стоимости газа, не срочно.
• Снижение рисков может включать анализ воздействия или выполнение этого позже с какой-либо формой прогрева на уровне блока (или ad-hoc прогрев этих значений) для уменьшения воздействия.

[EL] EIP-8268: Storage Roots in Block Access Lists [Уровень B]

• Может потребоваться анализ конкретного влияния на размеры BAL и связанное с этим влияние на стоимость транзакций (EIP-8279 предлагает взимать плату за байты BAL), поскольку запись BAL для каждого затронутого аккаунта получает дополнительный корень trie хранилища.

[EL] Функции EVM

Hegotá всё равно потребует некоторых ad-hoc решений по EVM. Мы считаем, что после Hegotá Ethereum должен работать над долгосрочной дорожной картой EVM, сформированной более широкой экосистемой EVM. Ethlabs внесёт свой вклад в это.

[EL] EIP-5920: PAY opcode [Уровень A]

• Очень просто, и мы считаем, что это хороший примитив для EVM.
• Было бы важно лучше понять конкретные случаи использования.

[EL] EIP-8163: Reserve EXTENSION (0xae) opcode [Уровень A]

• Очень полезно для L2, без реальных затрат для L1 (просто информационно).

[EL] Повторное использование / дедупликация кода [Уровень B]

• EIP-8058: Contract Bytecode Deduplication Discount и EIP-8298: SETCODEFROM Code Reuse Instruction оба пытаются использовать тот факт, что код контракта хранится отдельно от соответствующего аккаунта в клиентах, с хешем кода в качестве указателя между ними. Таким образом, идентичный общий код может храниться дедуплицированным. Оба EIP позволяют дешёво установить codehash аккаунта на хеш существующего где-то ещё кода.
• Мы считаем эту общую идею привлекательной, но важно понять последствия и прямую совместимость с бинарными деревьями. Пока нет предпочтений между двумя.

[EL] Реформа ценообразования памяти [Уровень B]

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

EIP-7686: Linear EVM memory limits

• Меньшее изменение, просто избавляется от квадратичной стоимости расширения памяти.

EIP-7923: Linear, Page-Based Memory Costing

• Более глубокая, более принципиальная переработка, но более сложная.

[EL] EIP-8219: Checked Arithmetic Opcodes [Уровень B]

• В целом, добавление безопасной математики в EVM кажется полезным.
• Ценообразование необходимо будет подтвердить с помощью бенчмарков, насколько это сложно?
• С бенчмарками и анализом воздействия (сколько транзакций может выиграть, насколько, какие компиляторы добавят поддержку?) это могло бы быть Уровнем A.

[EL] EIP-8360: TCREATE Opcode [Уровень B]

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

[EL] EIP-7645: Alias ORIGIN to SENDER [Уровень D]

• Рекомендуем отклонить: Ломающее изменение, неправильное использование ORIGIN.

[EL] EIP-8182: Private ETH and ERC-20 Transfers [Уровень D]

• Рекомендуем отклонить: Огромное изменение, добавляет zk-зависимости. Если когда-либо и вводить, то, по нашему мнению, это должно быть главным событием.

[EL] EIP-2488: Deprecate the CALLCODE opcode [формируем мнение]

[EL] EIP-4758: Deactivate SELFDESTRUCT [формируем мнение]

[EL] EIP-7979: Call and Return Opcodes for the EVM [формируем мнение]

[EL] EIP-8173: Foundations of EVM Control Flow [формируем мнение]

[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [формируем мнение]

[EL] EIP-8030: P256 algorithm support [формируем мнение]

[EL] Ценообразование EVM

Glamsterdam повысил цены на недооценённые операции, которые ограничивали общую пропускную способность. Предложения Hegotá по ценообразованию EVM в основном касаются другой стороны: снижения цен на отдельные операции, текущая стоимость которых ограничивает их использование, но не масштабируемость сети. Поэтому они являются приятными дополнениями с меньшим влиянием на каждый EIP. Мы открыты для целевых переоценок, но предложения, которые вводят новые механизмы измерения, следует включать только в том случае, если их дизайн является обоснованным и достаточно защищённым от рисков преданным своему делу чемпионом.

[EL] EIP-8358: Net Gas Metering for Account Changes [Уровень B]

• Не уверены в эффекте. В 900 семплированных блоках мейннета, ~400k транзакций: 2.07% всех транзакций сэкономили бы газ и 1.14% газа блока было бы сэкономлено.

[EL] EIP-7973: Warm Account Write Metering [формируем мнение]

[EL] EIP-7609: Decrease base cost of TLOAD/TSTORE [формируем мнение]

[EL] EIP-7971: Hard Limits for Transient Storage [формируем мнение]

[EL] EIP-3298: Removal of refunds [формируем мнение]

[EL] EIP-8374: Persist Warm Access Sets Across Reverts [формируем мнение]

[EL] EIP-8115: Batch priority fees at end of block [формируем мнение]

[EL] EIP-8188: Last-Written Block for Accounts and Slots [формируем мнение]

[EL][CL] Данные выполнения и индексация

[EL][CL] EIP-7668: Remove bloom filters [формируем мнение]

[EL][CL] EIP-7807: SSZ execution blocks [формируем мнение]

[EL] EIP-8116: Replace cumulative receipt fields [формируем мнение]

[EL] EIP-8304: Trustless log and transaction index [формируем мнение]

[EL][CL] Сеть

P2P-уровень Ethereum имеет возможности для целевых улучшений, особенно в том, как транзакции, блобы и аттестации распространяются по сети.

[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [Уровень A]

• В целом предотвращает полную реконструкцию и производительность узлов полного хранения как узкое место для масштабирования количества блобов.
• Ценно, в конечном счёте, какая-то форма распределённой реконструкции определённо должна попасть в протокол. Это могло бы позволить нам удалить хранение у валидаторов.
• Необходимо лучше понять сложность.

[CL] EIP-8142: Block-in-Blobs (BiB) [Уровень D]

• Преждевременно, нет сильной срочности, довольно поздно, много остающихся вопросов (KZG или нет? Новые темы gossip или нет?).
• Не хочется вводить KZG в критический путь производства блоков, альтернативы неясны и добавят дополнительную сложность.

[CL] EIP-8243: Batching Attestations at Source [Уровень D]

• Неясно, можем ли мы полагаться на это для уменьшения времени до финальности, это не накладывает чётких ограничений на нагрузку.
• Устойчивость механизма к DoS-атакам не до конца ясна.

[EL] EIP-8077: eth/XX - announce transactions with nonce [формируем мнение]

[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [формируем мнение]

[CL] EIP-8334: Bundled Attestation Propagation [формируем мнение]

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

Ещё (несколько) слов...

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

Наши позиции по Hegotá являются нашими наилучшими оценками на сегодняшний день, но мы будем обновлять наши мысли всякий раз, когда новые доказательства из обсуждений или работы по реализации изменят нашу точку зрения.

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

Мы благодарны быть маленькой частью этой экосистемы и с нетерпением ждём возможности помочь Ethereum реализовать свой потенциал.

– Ethlabs