Разработчик Ethereum Дерек Чианг заявил 7 сентября, что авторы EIP-8141 нашли способ выразить несколько функций транзакций как программируемые вызовы контрактов, вместо того чтобы добавлять их отдельно в оболочку транзакций Ethereum.
Резюме
- Разработчики Ethereum утверждают, что EIP-8141 может выражать функции транзакций через вызовы контрактов, известные как программируемые фреймы.
- Фреймы могут поддерживать срок действия, агрегацию подписей, доказательства конфиденциальности и пост-транзакционные проверки без новых полей оболочки.
- EIP-8141 запланирован для Hegotá, хотя его спецификация остается черновиком, а даты активации не установлены.
- Разработчики координируют EIP-8141 с EIP-8130 для сохранения структуры и улучшения читаемости транзакций для инфраструктуры.
- Виталик Бутерин утверждает, что разделение действий и зависимостей транзакций может обеспечить параллельную проверку и снизить затраты.
Чианг, соавтор EIP-8141 и участник Ethlabs, описал эту разработку как «прорыв в дизайне» в посте, обсуждая недавнюю работу авторов предложения. Подход рассматривает срок действия транзакции, агрегированные подписи, корни Меркла для пулов конфиденциальности и пост-транзакционные проверки как вызовы, называемые «фреймами».
Официальная черновая спецификация определяет фреймовую транзакцию как последовательность вызовов контрактов. Различные фреймы могут проверять транзакцию, одобрять оплату газа или выполнять пользовательские операции. Предложение в настоящее время предоставляет три режима: DEFAULT, VERIFY и SENDER.
Фрейм VERIFY может проверять, выполнено ли требуемое условие. Фрейм SENDER выполняет операцию от аккаунта, идентифицированного как отправитель транзакции. Фреймы также могут быть сгруппированы в атомарные пакеты, что означает, что все операции в пакете выполняются вместе или вся группа откатывается.
Предложение по-прежнему определяет базовую оболочку транзакции, содержащую такие поля, как идентификатор цепочки, nonce, отправитель, комиссии, подписи и список фреймов. Точка зрения Чианга более узкая: разработчики могут внедрять больше функциональности через новые цели фреймов и шаблоны вызовов, не создавая отдельный формат оболочки для каждой функции.
Стабильная оболочка может снизить координационные усилия
Изменение оболочки транзакций Ethereum затрагивает не только клиенты исполнения. Кошельки, сети второго уровня, блокчейн-эксплореры, устройства подписи, программные библиотеки и поставщики инфраструктуры должны понимать новый формат.
Чианг сказал, что обновления Ethereum происходят примерно каждые девять месяцев, что делает повторные изменения оболочки медленными и требующими значительной координации. Достаточно общий формат фреймов может служить стабильным интерфейсом, в то время как контракты или назначенные компоненты протокола предоставляют новые методы проверки.
Это не означает, что будущая функциональность никогда не потребует обновления сети. Сам EIP-8141 изменяет правила консенсуса Ethereum и требует реализации клиентами. Новые опкоды, прекомпиляции или правила газа также могут потребовать хард-форков. Предлагаемое преимущество заключается в том, что разработчикам не обязательно будет перепроектировать контейнер транзакций каждый раз.
Спецификация EIP-8141 перечисляет нативную абстракцию аккаунтов среди своих основных целей. Она может поддерживать ротацию ключей, альтернативные системы подписей, спонсируемые платежи за газ и пакетирование транзакций. Она также направлена на снижение зависимости аккаунтов Ethereum от системы подписей secp256k1, используемой обычными внешними аккаунтами.
Как сообщал crypto.news в своем освещении предложенного Виталиком Бутериным редизайна транзакций Ethereum, программируемая валидация в конечном итоге может помочь Ethereum внедрить новые системы аутентификации, не заменяя одну фиксированную схему подписи другой.
EIP-8130 может упростить проверку фреймов
Чианг также признал компромисс. Высокоабстрактные транзакции могут быть сложны для анализа кошельками, секвенсорами и другой инфраструктурой до выполнения. Например, секвенсор второго уровня может захотеть принимать только определенные методы подписи, поскольку их вычислительные затраты предсказуемы.
Поэтому разработчики изучают, как фреймы могут работать с EIP-8130, еще одним проектом предложения по абстракции аккаунтов. EIP-8130 создает ончейн-хранилище ключей, где аккаунты регистрируют акторов и контракты аутентификаторов. Транзакции явно указывают свой метод аутентификации.
Такая структура позволяет узлу определить, какой процесс валидации требуется транзакции, прежде чем запускать произвольный код кошелька. Согласно предложенному профилю второго уровня EIP-8130, цепочка может ограничить свой путь транзакций каноническим набором аутентификаторов с фиксированной стоимостью, оставляя другие методы аутентификации доступными через обычное выполнение EVM.
Чианг сказал, что EIP-8130 может наложить определенные структуры на фреймы EIP-8141. Сотрудничество может сохранить гибкость фреймов, предоставляя кошелькам и высокопроизводительным цепочкам более понятный формат транзакций. Комбинированный дизайн не финализирован, и обе спецификации остаются открытыми для пересмотра.
Ранее в освещении crypto.news рассматривалась конкуренция между EIP-8141 и EIP-8130 в ходе первоначального процесса определения масштаба Hegotá. Последние комментарии предполагают, что разработчики теперь ищут совместимые элементы, а не рассматривают предложения только как взаимоисключающие альтернативы.
Бутерин связывает фреймы с параллельной валидацией
Виталик Бутерин расширил техническое направление в отдельном посте, различая «действия» и «зависимости» транзакции. Действие изменяет состояние Ethereum, например, перевод ETH. Зависимость — это условие, которое должно быть выполнено, например, подпись, доказательство Меркла или доказательство с нулевым разглашением.
Бутерин утверждал, что независимые зависимости можно проверять параллельно. Условия, которые не обращаются к состоянию Ethereum, потенциально могут обрабатываться мемпулом один раз, а не повторяться во время выполнения. Несколько проверок в конечном итоге могут быть представлены рекурсивным доказательством STARK, хотя это остается направлением исследований, а не одобренной функцией.
Различие также может помочь клиентам отделить предсказуемые транзакции от операций, требующих полной динамической среды выполнения Ethereum. Бутерин сказал, что более статически анализируемая активность может получить более низкие затраты на газ и масштабироваться дальше. Такой график комиссий не был утвержден.
Модель фреймов обеспечивает потенциальный интерфейс для этого подхода, поскольку валидация и выполнение выглядят как идентифицируемые вызовы. Ethereum сохранит гибкое выполнение контрактов, позволяя более простым транзакциям объявлять больше информации о своих требованиях.
EIP-8141 запланирован, но даты остаются открытыми
Официальный Hegotá Meta EIP теперь перечисляет Frame Transactions и FOCIL как запланированные для включения в обновление Hegotá Ethereum. Это означает более высокий статус, чем ранее рассмотрение, но не замораживает текущий технический дизайн EIP-8141.
EIP-8141 по-прежнему помечен как черновое предложение Core. Его авторы могут пересматривать режимы фреймов, обработку подписей, учет газа и взаимосвязь с EIP-8130 по мере продолжения работы по реализации. Документ Hegotá также оставляет поля активации Sepolia, Hoodi и мейннета пустыми.
Следующие измеримые шаги включают обновленные спецификации, реализации клиентов исполнения, сети разработки и тестирование интероперабельности с кошельками и системами второго уровня. Разработчики также должны изучить риски отказа в обслуживании мемпула, поскольку программируемая валидация может сделать отклонение недействительных транзакций более вычислительно затратным.
Тестирование определит, сможет ли предложенная комбинация гибких фреймов и структурированных аутентификаторов удовлетворить потребности базового уровня Ethereum и более быстрых EVM-цепей. До публикации параметров активации EIP-8141 остается запланированной, но незавершенной частью Hegotá.
