$ETH
Спор вокруг нативной абстракции аккаунтов в Ethereum (AA): 8130 разбивают на три EIP
Как именно реализовать «нативную абстракцию аккаунтов (native Account Abstraction)» в Ethereum — разработческое сообщество спорило об этом довольно долго. Теперь появился компромиссный вариант, который приближает позиции двух сторон. Согласно треду на форуме Ethereum Magicians, исходное ключевое предложение EIP-8130 проходит рефакторинг и разделяется на три «компонуемых» новых EIP — 8398, 8399 и 8400.
Что такое нативная AA?
Почему спорят стороны 8130 и Frame
Цель абстракции аккаунтов (AA) — сделать «аккаунты на смарт-контрактах» первоклассными гражданами Ethereum: позволить настраивать логику верификации, поддерживать социальное восстановление, оплачивать gas за счет спонсора, выполнять пакетные транзакции и т. д. Сейчас преобладающий подход — идти через bundler в off-chain через ERC-4337, тогда как «нативная AA» хочет поддерживать это прямо на уровне протокола.
Спор разгорелся вокруг того, «как именно поддерживать». Одна сторона — подход «keystore», представленный EIP-8130: использовать белый список доверенных валидаторов для управления проверкой подписи. Плюсы — стоимость верификации предсказуема и ограничена (особенно удобно для Layer 2), а также встроенный стандарт аккаунта, содержащий policy и session key. В фокусе — простота и снижение фрагментации.
Другая сторона — Frame Transactions (EIP-8141): допускает «неструктурированную верификацию» произвольным EVM-кодом на любом этапе транзакции. Это открывает новые сценарии, например: «аккаунт без ETH получает средства в процессе выполнения». Взамен дается максимальная гибкость и пространство для инноваций без хардфорка. Но при этом растут риски фрагментации, а часть продвинутых сценариев требует приватного mempool.
Дерек Чианг (Ethlabs) в ранее опубликованном сравнении <8130 vs Frame Transactions> как раз точно обозначил компромисс между «простотой и контролируемостью» и «крайней гибкостью».
Компромиссное решение: разбивка на 8398, 8399, 8400
Разработчик Pedro UID 27 августа предложил «компонуемую нативную абстракцию аккаунтов», в рамках которой функциональность разделяют на три слоя базовых EIP, накладывающихся друг на друга (соответствующие GitHub PR #12248 открываются в тот же день):
EIP-8398 «портируемый keystore» — определяет участников (actor), валидаторов, настройки аккаунта, создание и межчейнную портируемость;
EIP-8399 — надстраивается поверх 8398: вводит нативный тип транзакции 0x79 для нативной AA и дополняет пакетность, спонсорство транзакций (sponsorship) и упорядоченный nonce;
EIP-8400 — требует предыдущие два, а затем добавляет policy, блокировку аккаунта и «транзакции без nonce», используя тот же единый транзакционный контейнер.
Изначальный EIP-8130 сохраняется без изменений — его переупаковывают как предшественник этих трех взаимодополняющих спецификаций.
Смысл: модульность позволяет цепям брать ровно столько, сколько нужно, но пока это остается на стадии предложения
Главная выгода от разбиения большого предложения на компонуемые модули — гибкость: разные цепи или команды могут выбрать только нужные им уровни, не принимая «всё или ничего».
Одна из интерпретаций в сообществе: примерно побеждает направление Frame, делающее акцент на гибкости, а идеи L2-ветки вокруг keystore также были интегрированы — другими словами, обе стороны не проиграли полностью. Однако стоит напомнить: сейчас все это все еще находится на стадии EIP-предложений и общественных обсуждений. Это пока не окончательное решение Ethereum. Дальше будет зависеть от того, как основные разработчики сведут эти три спецификации к формальной дорожной карте обновлений.
Эта статья «Спор вокруг нативной абстракции аккаунтов в Ethereum (AA): 8130 разбивают на три EIP» впервые появилась.
Спор вокруг нативной абстракции аккаунтов в Ethereum (AA): 8130 разбивают на три EIP
Как именно реализовать «нативную абстракцию аккаунтов (native Account Abstraction)» в Ethereum — разработческое сообщество спорило об этом довольно долго. Теперь появился компромиссный вариант, который приближает позиции двух сторон. Согласно треду на форуме Ethereum Magicians, исходное ключевое предложение EIP-8130 проходит рефакторинг и разделяется на три «компонуемых» новых EIP — 8398, 8399 и 8400.
Что такое нативная AA?
Почему спорят стороны 8130 и Frame
Цель абстракции аккаунтов (AA) — сделать «аккаунты на смарт-контрактах» первоклассными гражданами Ethereum: позволить настраивать логику верификации, поддерживать социальное восстановление, оплачивать gas за счет спонсора, выполнять пакетные транзакции и т. д. Сейчас преобладающий подход — идти через bundler в off-chain через ERC-4337, тогда как «нативная AA» хочет поддерживать это прямо на уровне протокола.
Спор разгорелся вокруг того, «как именно поддерживать». Одна сторона — подход «keystore», представленный EIP-8130: использовать белый список доверенных валидаторов для управления проверкой подписи. Плюсы — стоимость верификации предсказуема и ограничена (особенно удобно для Layer 2), а также встроенный стандарт аккаунта, содержащий policy и session key. В фокусе — простота и снижение фрагментации.
Другая сторона — Frame Transactions (EIP-8141): допускает «неструктурированную верификацию» произвольным EVM-кодом на любом этапе транзакции. Это открывает новые сценарии, например: «аккаунт без ETH получает средства в процессе выполнения». Взамен дается максимальная гибкость и пространство для инноваций без хардфорка. Но при этом растут риски фрагментации, а часть продвинутых сценариев требует приватного mempool.
Дерек Чианг (Ethlabs) в ранее опубликованном сравнении <8130 vs Frame Transactions> как раз точно обозначил компромисс между «простотой и контролируемостью» и «крайней гибкостью».
Компромиссное решение: разбивка на 8398, 8399, 8400
Разработчик Pedro UID 27 августа предложил «компонуемую нативную абстракцию аккаунтов», в рамках которой функциональность разделяют на три слоя базовых EIP, накладывающихся друг на друга (соответствующие GitHub PR #12248 открываются в тот же день):
EIP-8398 «портируемый keystore» — определяет участников (actor), валидаторов, настройки аккаунта, создание и межчейнную портируемость;
EIP-8399 — надстраивается поверх 8398: вводит нативный тип транзакции 0x79 для нативной AA и дополняет пакетность, спонсорство транзакций (sponsorship) и упорядоченный nonce;
EIP-8400 — требует предыдущие два, а затем добавляет policy, блокировку аккаунта и «транзакции без nonce», используя тот же единый транзакционный контейнер.
Изначальный EIP-8130 сохраняется без изменений — его переупаковывают как предшественник этих трех взаимодополняющих спецификаций.
Смысл: модульность позволяет цепям брать ровно столько, сколько нужно, но пока это остается на стадии предложения
Главная выгода от разбиения большого предложения на компонуемые модули — гибкость: разные цепи или команды могут выбрать только нужные им уровни, не принимая «всё или ничего».
Одна из интерпретаций в сообществе: примерно побеждает направление Frame, делающее акцент на гибкости, а идеи L2-ветки вокруг keystore также были интегрированы — другими словами, обе стороны не проиграли полностью. Однако стоит напомнить: сейчас все это все еще находится на стадии EIP-предложений и общественных обсуждений. Это пока не окончательное решение Ethereum. Дальше будет зависеть от того, как основные разработчики сведут эти три спецификации к формальной дорожной карте обновлений.
Эта статья «Спор вокруг нативной абстракции аккаунтов в Ethereum (AA): 8130 разбивают на три EIP» впервые появилась.
