Разработчики Ethereum недавно сообщили о новых достижениях в дизайне EIP-8141. Этот提案 пытается реализовать часть функций транзакций в виде программируемых вызовов смарт-контрактов, так называемых «frames», вместо того чтобы каждый раз изменять формат обертки транзакций Ethereum при добавлении новой функциональности.
Функция торговли изменена на вызов через программирование
Эта концепция охватывает функции, такие как истечение срока сделки, агрегированная подпись, Merkle-корень, связанный с приватным пулом, и проверка утверждений после выполнения сделки. Разработчики считают, что если этот интерфейс будет достаточно универсальным, то при внедрении новых способов проверки в будущем Ethereum кошельки, браузеры, устройства для подписи и Layer 2 не будут вынуждены каждый раз адаптироваться под новые оболочки транзакций.
Черновик EIP-8141 определяет Frame Transaction как последовательность вызовов смарт-контрактов. Разные frame могут отвечать за проверку условий транзакции, одобрение оплаты газа или выполнение действий пользователя.
В настоящее время проект предусматривает три режима: DEFAULT, VERIFY и SENDER. Рамка VERIFY используется для проверки выполнения определенного условия, а рамка SENDER представляет выполнение операции от имени отправителя транзакции. Несколько рамок могут быть объединены в атомарную пакетную обработку, при которой либо все операции выполняются успешно, либо вся пакетная обработка откатывается.
Снизить стоимость координации кошельков и инфраструктуры
Основная точка зрения разработчика Дерека Чьяна заключается в том, что для добавления новых функций в будущем не обязательно создавать новую систему упаковки торговли. Возможности можно расширить, сохранив стабильность базовой структуры, просто используя новые цели frame и модели вызова.
Каждое изменение формата транзакции Ethereum затрагивает не только исполнительные клиенты. Кошельки, Layer 2, блокчейн-обозреватели, аппаратные и программные средства подписи, а также различные поставщики инфраструктуры должны понимать и поддерживать новый формат.
Чжан отметил, что обновления Ethereum происходят примерно каждые девять месяцев, и частые изменения в упаковке транзакций приводят к высоким затратам на координацию. В сравнении, если формат frame станет более стабильным интерфейсом, новые методы проверки можно будет больше передать на обработку смарт-контрактам или специфическим компонентам протокола.
Однако это не означает, что все будущие функции смогут обойти обновления сети. EIP-8141 по-прежнему будет изменять консенсусные правила Ethereum и требовать реализации в клиентах. Если речь идет о новых операциях, предварительно скомпилированных контрактах или правилах газа, может потребоваться жесткий форк.
EIP-8130 и направление параллельной верификации
Разработчики также признают, что повышение уровня абстракции транзакций усложняет анализ транзакций кошельками и сортерами до их выполнения. Для решения этой проблемы команда изучает способы совместного применения EIP-8141 и другого проекта абстракции аккаунтов — EIP-8130.
EIP-8130 предлагает структуру keystore на цепочке, позволяющую заранее зарегистрировать участников и сертифицирующий смарт-контракт, а также явно указывать способ аутентификации в транзакциях. Это позволяет узлам определить, какой процесс проверки требуется для транзакции, прежде чем запускать любой код кошелька. Для Layer 2 это помогает ограничить набор методов аутентификации до набора с более предсказуемыми затратами.
Виталик Бутерин также объяснил соответствующее направление в другом посте. Он разделил транзакции на две части: «действия» и «условия зависимости». Первая отвечает за изменение состояния Ethereum, а вторая включает предварительные условия, такие как подписи, доказательства Меркла или доказательства с нулевым разглашением. Если эти зависимости независимы друг от друга, в будущем их можно будет проверять параллельно, что снизит стоимость обработки некоторых транзакций.
Добавлено в Hegotá, но время активации не определено
Официальный Hegotá Meta EIP включил Frame Transactions в список запланированных обновлений, что означает, что его статус продвинулся по сравнению с предыдущим. Однако EIP-8141 пока остается основным черновиком, и технические детали еще не окончательно утверждены.
Дальнейшие задачи включают обновление спецификаций, завершение реализации исполняемого клиента, создание тестовой сети и проведение тестов на совместимость с кошельками и системами Layer 2. Разработчикам также необходимо оценить риски отказа в обслуживании из-за пулла памяти, поскольку программируемая проверка может повысить вычислительные затраты на фильтрацию недействительных транзакций.
В настоящее время времена активации Hegotá на Sepolia, Hoodi и основной сети остаются пустыми. EIP-8141 включен в план обновления, но до окончательного внедрения еще предстоит пройти этап реализации и тестирования.