Екосистема Ethereum постійно розвивається та самооптимізується, незалежно від того, чи є це ринок «бичачий» чи «ведмежий». Серед них, абстракція облікових записів (AA) досягла значного прогресу за останні роки та проникла в усі частини екосистеми Ethereum, включаючи програми, інфраструктуру, користувачів і розробників. Ми можемо передбачити, що широкомасштабне впровадження АА знизить поріг використання блокчейну в цілому та впровадить користувальницький досвід web2 у галузь web3.
У цій статті команда BlockPI заглибиться в своє розуміння АА та поділиться своїми міркуваннями з точки зору постачальника інфраструктурних послуг.
EOA та контрактний гаманець
Концепція AA випливає з обмежень облікових записів EOA. Обліковий запис EOA (зовнішній обліковий запис) — це обліковий запис користувача в Ethereum, представлений відкритим ключем (блокчейн-адресою), доступ до якого здійснюється через закритий ключ. Це основний компонент екосистеми Ethereum, що дозволяє користувачам переказувати гроші через блокчейн або взаємодіяти зі смарт-контрактами. Однак для багатьох людей використання EOA може бути складним завданням саме по собі. Крім того, поточний обліковий запис EOA все ще має деякі незручності у використанні, що впливає на взаємодію з користувачем.
Перше – це питання плати за газ. Кожна транзакція коштуватиме користувачеві значну суму ETH як комісію за газ (взявши як приклад ціну на газ у 25 Gwei, комісія за газ для простого переказу ETH становить приблизно 0,5 долара США, і це буде дорожче за контрактну взаємодію або коли ціна на газ вища) . Це робить невеликі транзакції дуже дорогими, особливо в періоди сильного перевантаження мережі. Крім того, бензин можна оплачувати лише за допомогою ETH, а це означає, що користувачі повинні зберігати ETH у своїх гаманцях, що є високим бар’єром для входу для багатьох користувачів.
По-друге, для деяких складних операцій, які користувачі хочуть реалізувати, EOA повинен покладатися на інші розумні контракти. Наприклад, якщо користувач хоче встановити періодичний переказ за часом, йому потрібно перенести ETH на смарт-контракт із цією функцією, щоб виконати цю операцію.
Третьою проблемою EOA є фіксований алгоритм шифрування підпису. Мережа Ethereum використовує алгоритм цифрового підпису secp256k1 для забезпечення автентичності та безпеки транзакцій. Цей алгоритм жорстко закодовано в системі, і користувачі не можуть використовувати інші алгоритми шифрування.
На додаток до вищезазначених трьох проблем, обов’язковий зв’язок між відкритим і закритим ключами EOA також є проблемою. Приватний ключ — це єдиний спосіб для користувачів отримати доступ до EOA. Якщо приватний ключ буде втрачено, його не буде відновлено. Це також означає, що всі активи в межах EOA, пов’язані з ним, будуть неповерненими.
У той же час EOA також має обмеження при виконанні окремих лінійних завдань. Наприклад, якщо користувач бажає затвердити, обміняти та скасувати затвердження маркерів за одну операцію, потрібно виконати три окремі транзакції, що неефективно та забирає багато часу.
Хороша новина полягає в тому, що контрактні гаманці можуть вирішити всі перераховані вище проблеми. Контрактний гаманець — це, по суті, певний тип розумного контрактного облікового запису, який реалізує AA, який можна використовувати як гаманець користувача в Ethereum. І це може надати користувачам більш гнучкий та персоналізований спосіб управління коштами. Поки смарт-контракт Ethereum може реалізувати логіку, контрактний гаманець може реалізовувати та забезпечувати відповідні функції.
Зокрема, операції з декількома контрактними гаманцями можна об’єднати в транзакцію в ланцюжку, і ці операції можуть розділити вартість газу цієї транзакції. Якщо третя сторона бажає сплачувати комісію за газ, користувачам, які використовують контрактний гаманець, платити за газ не потрібно. Контрактні гаманці також можуть виконувати кілька лінійних завдань одночасно. Крім того, контрактний гаманець також підтримує алгоритм шифрування користувальницьких підписів і встановлює функцію відновлення гаманця тощо.
Оскільки обговорення переваг контрактних гаманців триває, спільнота Ethereum фактично провела довгострокове дослідження контрактних гаманців. Незважаючи на те, що багато EIP досліджували проблеми, пов’язані з абстракцією облікових записів, станом на 2021 рік не було встановлено єдиного стандарту. Нижче наведено кілька типових EIP.
EIP-86
Спочатку запропонований Віталіком Бутеріним у 2017 році. Схема реалізує низку змін із загальною метою «абстрагування» перевірки підпису та одноразової перевірки, таким чином дозволяючи користувачам створювати «контракти облікових записів», які виконують довільну перевірку підпису/одноразової перевірки.
EIP-2938
Представлений у 2020 році. Назва цього EIP – Абстракція облікового запису. Концепція АА добре описана в цьому EIP. Він вводить новий тип транзакцій, транзакцію AA. Транзакція ініціюється адресою точки входу (адреса EntryPoint) і викликає гаманець контракту AA. EIP-2938 надає уніфіковану специфікацію та офіційно вводить абстракцію облікового запису AA в консенсус Ethereum. Зокрема, він представляє два нових коди операцій, три глобальні змінні та іншу структуру корисного навантаження для консенсусу Ethereum.
EIP-3074
Представлений у 2020 році. Цей EIP представляє дві інструкції EVM, AUTH і AUTHCALL. AUTH встановлює змінну середовища відповідно до повноважень підпису ECDSA. AUTHCALL надсилає виклик як авторизований обліковий запис. Це дозволяє розумним контрактам надсилати транзакції від імені EOA. Але це все ще не ідеальне рішення для АА. У процесі транзакції авторизації EIP-3074 має певні обмеження щодо передачі вихідного значення. І якщо користувач втратить доступ до EOA, відновити його активи все одно буде неможливо. У разі витоку закритого ключа користувачеві потрібно перенести всі активи в новий обліковий запис.
Жодна з наведених вище пропозицій не була офіційно включена в протокол Ethereum через необхідність змін на рівні консенсусу або тому, що пропозиції були недостатньо повними. Тому спільнота Ethereum продовжувала досліджувати, як ввести AA в протокол Ethereum без зміни консенсусу, і нарешті запропонувала EIP4337.
ERC - 4337
EIP-4337 спочатку було запропоновано у вересні 2021 року та затверджено як ERC-4337 у березні 2023 року. Його авторами є Віталік Бутерін, Йоав Вайс, Крістоф Газсо, Намра Пател, Дрор Тірош, Шахаф Наксон і Тьяден Гесс.
EIP-4337 — це революційна пропозиція, яка може запровадити АА без зміни основного протоколу Ethereum. Згодом EIP-4337 став стандартом ERC-4337, який розробники можуть використовувати для впровадження власних гаманців з розумними контрактами. У той же час стандарт також представляє деяку додаткову інфраструктуру, включаючи «Bundlers» і «UserOperation mempool». Таким чином, він фактично відтворює мемпул Ethereum із подібними функціями на верхньому рівні системи блокчейну. Користувач надсилає вже не одну транзакцію, а UserOperation. Кілька UserOperations можна об’єднати в одну транзакцію та надіслати в Ethereum.
Нижче наведено детальне технічне пояснення ERC-4337 в Ethereum [офіційна документація]( разом із деякими корисними коментарями.
Ключові ролі та визначення ERC-4337
UserOperation — описує структуру транзакції, надісланої від імені користувача. Щоб уникнути плутанини, вона не називається "транзакція", і її буде надіслано до Bundler для упаковки як Bundle з іншими UserOperations. Потім пакет надсилається в мережу як одна транзакція.
Sender — договірний обліковий запис, який надсилає UserOperation. Договір гаманця має відповідати стандарту ERC-4337 для налаштування інтерфейсу IAaccount.
EntryPoint — глобальний єдиний контракт, який виконує пакет UserOperations. Підтримувані EntryPoints у білому списку пакетів/клієнтів. Контракт перевірено та схвалено для розгортання командою Infinitism, яка відповідає за обробку всіх операцій користувача та підключення контрактів з іншими ролями, зокрема Wallet Factory, Aggregator та Paymaster. Уся угода знаходиться за тією самою адресою в ланцюжку, сумісному з EVM.
Bundler — вузол, який пакує кілька UserOperations з mempool і створює транзакцію EntryPoint.handleOps() (поточний виробник блоку). Сервіс Bundler може працювати незалежно від вузлів блокчейну та надсилати запаковані UserOperations через RPC.
Агрегатор — допоміжний контракт, якому облікові записи довіряють для перевірки агрегованих підписів. Підтримувані агрегатори підписів у білому списку групувальників/клієнтів. Агрегатор має відповідати стандарту ERC-4337, щоб налаштувати інтерфейс IAggregator.
Paymaster — розумний контракт, який може оплачувати газ від вашого імені. Якщо він вносить достатню кількість ETH у контракт EntryPoint, він може сплатити комісію за газ для UserOperation для відправника, ефективно реалізуючи відбір газу. Paymaster має дотримуватися стандарту ERC-4337, щоб налаштувати інтерфейс Paymaster. Платіжник може укласти договір з Відправником. Наприклад, відправник платить USDC Paymaster, а Paymaster використовує ETH для оплати газу UserOperations, які він надсилає. Насправді Paymaster може вибрати підтримку будь-якого токена, включаючи токени ERC-20 і навіть токени в інших мережах.
Wallet Factory — розумний контракт, який може створювати контрактні гаманці для користувачів ERC-4337. Розгортання Wallet Factory не має дозволу. Як смарт-контракт у ланцюжку, його код відкритий для громадськості, і кожен може переглянути його. Фабрика Wallet Factory, яка широко використовується, повинна бути повністю перевірена професіоналами.
На діаграмі нижче пояснюється, як контракт EntryPoint взаємодіє з іншими учасниками.
Пакетувальники викликають функцію handleOps контракту EntryPoint, яка приймає UserOperation як вхідні дані.
handleOps перевірить UserOperation у ланцюжку, перевірить, чи він підписаний зазначеною адресою гаманця смарт-контракту, і підтвердить, чи гаманець має достатньо газу для компенсації Bundler.
Якщо перевірку пройдено, handleOps виконає функцію гаманця смарт-контракту відповідно до функції та вхідних параметрів, визначених у calldata UserOperation.
З іншого боку, коли Bundler використовує EOA для запуску функції handleOps, стягуватиметься комісія за газ. Гаманець із розумним контрактом може сплачувати комісію за газ пакетувальникам із балансу власного рахунку або вимагати оплати за контракт Paymaster. UserOperations не може пройти етап перевірки поза ланцюгом без достатньої кількості газу, тобто він зазнає невдачі перед виконанням транзакції в ланцюжку. Навіть якщо газу достатньо, UserOperations все одно може вийти з ладу через такі причини, як помилки під час виконання під час виконання. Для UserOperation, незалежно від того, успішно чи ні виконано контракт, контракт EntryPoint сплачуватиме комісію за газ Bundler-у, який запускає функцію handleOps.
(Витяг з офіційної документації:
Після набуття чинності ERC-4337 користувачі тепер можуть ініціювати блокчейн-транзакції двома способами. Один — традиційний спосіб, тобто EOA безпосередньо ініціює транзакцію. Інший полягає у використанні стандарту ERC-4337 для ініціювання UserOperation через Bundler, а потім Bundler запакує його в інші UserOperations і надішле до ланцюжка. Блок-схема нижче ілюструє різницю між звичайною транзакцією надсилання EOA та надсиланням UserOperation контрактного гаманця ERC-4337.
Дорогу заасфальтували, але пішоходів ще мало
ERC-4337 надає користувачам і розробникам потужну структуру для використання та створення АА на Ethereum. Незважаючи на те, що ця структура є важливим прогресом, все ще існують деякі проблеми та невизначеності, які необхідно розглянути та вирішити.
Прийняття АА все ще знаходиться в зародковому стані. За даними панелі аналізу Dune ERC-4337 (*[ERC-4337 Abstraction Account](з @niftytable), у ланцюжку було виконано лише 65 тисяч+ UserOperations, 90% з яких надходили з Polygon. Таким чином, кількість поточних виконаних UserOperations все ще дуже малий, і більшість із них. Частково це перевірка розробників, і лише невелика частина надходить від реальних користувачів. Ми помітили, що продукти, які інтегровано АА, все ще знаходяться на ранній стадії. Наразі ми можемо спостерігати, що Загалом пакетувальники все ще перебувають у стані збитків, і поточні втрати становлять понад 700 MATIC. Це головним чином спричинено тим, що деякі пакетувальники на Polygon неправильно оцінюють необхідний газ, у результаті чого газ, повернутий EntryPoint, є меншим за спожитий газ. Цю проблему потрібно вирішити на рівні клієнта Bundler.
Окрім цього, є кілька проблем, які потрібно вирішити. Однією з проблем є те, як Bundler обробляє помилки транзакцій.
Після пакетування кількох UserOperations разом Bundlerи спочатку змоделюють транзакцію, виявлять, чи буде збій у виконанні контракту, і розрахують, чи буде комісія за газ, яку повертає відправник або платіжник, більша за сплачену комісію за газ.
Якщо це прибутково, Bundler надсилає цю партію UserOperations як транзакцію на вузол блоку. Однак транзакція все ще може статися невдалою, в результаті чого Покупець сплатить комісію за газ, але не отримає відшкодування за газ від EntryPoint. Наприклад, користувач може надсилати дії до різних Bundlers. Якщо є прибуток і симуляція пройшла успішно, Bundlers передасть його в мережу. У цьому випадку, якщо UserOperation надіслано до вузла створення блоків різними Bundler-ами одночасно, лише одна транзакція буде успішною, що означає, що лише один Bundler отримає комісію за газ, повернуту EntryPoint, а всі інші Bundler-и зазнають невдачі. через ланцюг і втрачати газ. Хоча хтось може стверджувати, що таку поведінку слід вважати зловмисною атакою, і стверджувати, що Bundler може заборонити адресу відправника та відхилити будь-які майбутні запити з цієї адреси, це не є розумним рішенням, оскільки користувачі можуть вжити таку дію ненавмисно. Це питання має бути належним чином вирішено в коді, можливо, через публічний mempool, який знаходиться на стадії розробки. Крім того, Bundlers можуть зазнати збитків через раптові коливання газу, навіть якщо транзакцію успішно подано, а результати моделювання показують, що є можливість отримати прибуток.
Іншою проблемою є максимальне видобуте значення (MEV), яке можна отримати від AA. У контексті Ethereum MEV зазвичай відноситься до значення, яке майнери або інші процесори транзакцій витягують шляхом маніпулювання порядком транзакцій у блоці або вставлення власних транзакцій у блок. Можна помітити, що логіка MEV також може бути застосована до AA. Це пов’язано з тим, що в AA Bundlers можуть вільно послідовно виконувати UserOps, що дає їм можливість отримати MEV. Однак те, чи зможе Bundler отримати MEV, залежить від того, чи можна об’єднати достатню кількість UserOperations. Зараз весь ринок АА все ще знаходиться в зародковому стані, тому Bundler MEV також можна вважати зародковим. Можна побачити, що MEV AA може розвиватися в двох напрямках: один подібний до основної мережі Ethereum, за участю таких учасників, як Flashbots, Ultra Sound і BloXroute; інший напрямок полягає в формуванні консенсусу Bundler для реалізації справедливого сортування. А останнє повністю виключало б можливість вилучення МЕВ в АА.
майбутній розвиток
публічний mempool
Хоча екосистема АА вже працює, попереду ще багато роботи над розробкою. Дивлячись на всю екосистему АА, найбільше бракує наразі публічного mempool. Команда Etherspot, розробники клієнта Skandha Bundler, зараз розробляє p2p-мережу з публічним mempool. Очікується, що p2p-мережа публічних мемпулів буде запущена в серпні цього року.
Пакетний алгоритм
На цьому шляху фонд Ethereum профінансував кілька видатних команд розробників АА. Наразі розроблено кілька клієнтів Bundler, які доступні. Серед них деякі дуже зрілі. Це Candide (Voltaire Bundler, написаний на Python), Pimlico (Alto Bundler, написаний на Type), Etherspot (Skandha Bundler, написаний на Type), Stackup (Stackup-Bundler, написаний на Go) тощо.
Тут постає питання стратегії упаковки. Наразі через невелику кількість UserOperations Bundlerи можуть застосовувати просту логіку упаковки, наприклад фіксований часовий інтервал або певну кількість UserOperations у кожному Bundle. Однак із збільшенням кількості UserOperations, особливо після впровадження загальнодоступного mempool, стратегія вибору та упаковки UserOperations стає складнішою. Причина проста: в екології АА немає механізму, подібного до протоколу консенсусу блокчейну, і група Bundler стала темним лісом.Кожен Bundler розставляє пріоритети завдань відповідно до власних інтересів і конкурує один з одним. На відміну від публічних мемпулів, приватні мемпули можуть з'явитися раніше. Оскільки пакування UserOperations із загальнодоступного mempool є нерентабельним, усе ще можна пакувати UserOperations у приватний mempool. У цьому випадку Bundler більш конкурентоспроможний, ніж інші Bundlers, коли пакує.
Крім того, з поступовим популяризацією загальнодоступного mempool, UserOperations у ньому мають різні характеристики, такі як різні очікування прибутку Gas і складність виконання в ланцюжку. Розробники групування проводитимуть симуляції поза мережею, щоб оцінити прибутковість різних комбінацій UserOperations, щоб створити відповідні стратегії групування. Упаковка більшої кількості UserOperations має потенціал для отримання більших прибутків, але також збільшує ризик помилок перевірки. Навіть якщо перевірку пройдено, ризик збою виконання в ланцюжку все одно існує. Навпаки, менш упаковані UserOperations роблять протилежне. Пакетувальники повинні встановити власні параметри газу для транзакцій, що вплине на пріоритет виробників блоків для виконання цієї транзакції. За різних розрахункових умов ціни на газ і нестабільності газу постачальники можуть мати різні стратегії упаковки. У той же час, також необхідно враховувати вартість локальних апаратних обчислювальних ресурсів і ресурсів блокчейн-вузла для цих перевірок і розрахунків політики. Крім того, Bundlers також потрібно наполегливо працювати, щоб забезпечити користувачам якісний досвід роботи та гарантувати, що користувачі не стикаються з надмірними затримками після надсилання UserOperations.
Хоча шляхи вирішення цих завдань поки що неясні, ми можемо з упевненістю сказати, що розвиток індустрії АА та спільними зусиллями розробників зрештою вирішать ці проблеми. Як розробник інфраструктури, BlockPI сподівається відігравати роль вирішувача проблем у розвитку індустрії АА, як розробник або надавати інфраструктуру, зручну для АА, для інших розробників.
Інфраструктура повинна адаптуватися до АА
AA абстрагує різні ролі, які беруть участь у транзакціях у ланцюзі, включаючи Відправника, Пакетувальників, Платників за газ, контрактні гаманці та Підписувачів, щоб користувачі мали більший ступінь свободи під час використання блокчейну. У той же час постачальники інфраструктури можуть самостійно розгортати ці послуги відповідно до власної оцінки на ринку.
Щоб адаптуватися до широкомасштабного впровадження АА, постачальникам інфраструктури спочатку потрібно надати принаймні дві основні послуги: послугу Bundler і Paymaster.
У службах Bundler постачальникам інфраструктури може знадобитися розробити приватні пам’ятні пули з Bundlerами, щоб забезпечити хорошу взаємодію з користувачем. Зокрема, постачальникам інфраструктури потрібно інтегрувати кілька клієнтів Bundler, щоб забезпечити стабільність послуг Bundler. Ці клієнти Bundler наразі надають користувачам кілька стандартних методів JSON RPC, наданих основною групою розробки ERC-4337. Передбачається, що в майбутньому користувачам буде доступно більше методів RPC. Постачальникам інфраструктурних послуг необхідно своєчасно оновити підтримку цих методів під час цього процесу.
Крім того, дуже важливо оптимізувати між API Bundler і RPC клієнта вихідного вузла. Поточні клієнти вузлів не оптимізовані для AA. Деякі методи API Bundler вимагають від вузла надання індексу даних для AA. Наприклад, коли поточний клієнт шукає UserOperation за хешем, йому потрібно сканувати журнали контрактів EntryPoint у всіх блоках. Якщо немає індексу даних, споживання апаратних ресурсів для цього одного запиту буде досить великим, а час повернення запиту також стане дуже довгим.
Крім того, для того, щоб надати користувачам досвід без газу та різноманітні послуги, постачальники інфраструктури повинні співпрацювати з різними постачальниками послуг Paymaster для інтеграції різних служб Paymaster. У той же час, відповідно до потреб ринку, постачальники інфраструктури також можуть розробляти більш зручні інтегровані рішення на основі існуючих сервісів Paymaster. Інші сервіси, такі як агреговані підписи, фабрики гаманців тощо, також є потенційними напрямками майбутнього розвитку та інтеграції інфраструктури.
Коротше кажучи, щоб адаптуватися до широкомасштабного застосування АА, постачальники інфраструктури повинні постійно вдосконалювати та розширювати свої послуги. Це включає оптимізацію послуг Bundler, співпрацю з різними постачальниками послуг Paymaster, інтеграцію різних інтерфейсів API та розробку інших потенційних послуг. Оскільки індустрія АА продовжує розвиватися, ці зусилля допоможуть забезпечити більш ефективний, безпечний і зручний досвід блокчейну.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Як інфраструктура забезпечує мільярди користувачів через абстракцію облікових записів
Екосистема Ethereum постійно розвивається та самооптимізується, незалежно від того, чи є це ринок «бичачий» чи «ведмежий». Серед них, абстракція облікових записів (AA) досягла значного прогресу за останні роки та проникла в усі частини екосистеми Ethereum, включаючи програми, інфраструктуру, користувачів і розробників. Ми можемо передбачити, що широкомасштабне впровадження АА знизить поріг використання блокчейну в цілому та впровадить користувальницький досвід web2 у галузь web3.
У цій статті команда BlockPI заглибиться в своє розуміння АА та поділиться своїми міркуваннями з точки зору постачальника інфраструктурних послуг.
EOA та контрактний гаманець
Концепція AA випливає з обмежень облікових записів EOA. Обліковий запис EOA (зовнішній обліковий запис) — це обліковий запис користувача в Ethereum, представлений відкритим ключем (блокчейн-адресою), доступ до якого здійснюється через закритий ключ. Це основний компонент екосистеми Ethereum, що дозволяє користувачам переказувати гроші через блокчейн або взаємодіяти зі смарт-контрактами. Однак для багатьох людей використання EOA може бути складним завданням саме по собі. Крім того, поточний обліковий запис EOA все ще має деякі незручності у використанні, що впливає на взаємодію з користувачем.
Перше – це питання плати за газ. Кожна транзакція коштуватиме користувачеві значну суму ETH як комісію за газ (взявши як приклад ціну на газ у 25 Gwei, комісія за газ для простого переказу ETH становить приблизно 0,5 долара США, і це буде дорожче за контрактну взаємодію або коли ціна на газ вища) . Це робить невеликі транзакції дуже дорогими, особливо в періоди сильного перевантаження мережі. Крім того, бензин можна оплачувати лише за допомогою ETH, а це означає, що користувачі повинні зберігати ETH у своїх гаманцях, що є високим бар’єром для входу для багатьох користувачів.
По-друге, для деяких складних операцій, які користувачі хочуть реалізувати, EOA повинен покладатися на інші розумні контракти. Наприклад, якщо користувач хоче встановити періодичний переказ за часом, йому потрібно перенести ETH на смарт-контракт із цією функцією, щоб виконати цю операцію.
Третьою проблемою EOA є фіксований алгоритм шифрування підпису. Мережа Ethereum використовує алгоритм цифрового підпису secp256k1 для забезпечення автентичності та безпеки транзакцій. Цей алгоритм жорстко закодовано в системі, і користувачі не можуть використовувати інші алгоритми шифрування.
На додаток до вищезазначених трьох проблем, обов’язковий зв’язок між відкритим і закритим ключами EOA також є проблемою. Приватний ключ — це єдиний спосіб для користувачів отримати доступ до EOA. Якщо приватний ключ буде втрачено, його не буде відновлено. Це також означає, що всі активи в межах EOA, пов’язані з ним, будуть неповерненими.
У той же час EOA також має обмеження при виконанні окремих лінійних завдань. Наприклад, якщо користувач бажає затвердити, обміняти та скасувати затвердження маркерів за одну операцію, потрібно виконати три окремі транзакції, що неефективно та забирає багато часу.
Хороша новина полягає в тому, що контрактні гаманці можуть вирішити всі перераховані вище проблеми. Контрактний гаманець — це, по суті, певний тип розумного контрактного облікового запису, який реалізує AA, який можна використовувати як гаманець користувача в Ethereum. І це може надати користувачам більш гнучкий та персоналізований спосіб управління коштами. Поки смарт-контракт Ethereum може реалізувати логіку, контрактний гаманець може реалізовувати та забезпечувати відповідні функції.
Зокрема, операції з декількома контрактними гаманцями можна об’єднати в транзакцію в ланцюжку, і ці операції можуть розділити вартість газу цієї транзакції. Якщо третя сторона бажає сплачувати комісію за газ, користувачам, які використовують контрактний гаманець, платити за газ не потрібно. Контрактні гаманці також можуть виконувати кілька лінійних завдань одночасно. Крім того, контрактний гаманець також підтримує алгоритм шифрування користувальницьких підписів і встановлює функцію відновлення гаманця тощо.
Оскільки обговорення переваг контрактних гаманців триває, спільнота Ethereum фактично провела довгострокове дослідження контрактних гаманців. Незважаючи на те, що багато EIP досліджували проблеми, пов’язані з абстракцією облікових записів, станом на 2021 рік не було встановлено єдиного стандарту. Нижче наведено кілька типових EIP.
EIP-86
Спочатку запропонований Віталіком Бутеріним у 2017 році. Схема реалізує низку змін із загальною метою «абстрагування» перевірки підпису та одноразової перевірки, таким чином дозволяючи користувачам створювати «контракти облікових записів», які виконують довільну перевірку підпису/одноразової перевірки.
EIP-2938
Представлений у 2020 році. Назва цього EIP – Абстракція облікового запису. Концепція АА добре описана в цьому EIP. Він вводить новий тип транзакцій, транзакцію AA. Транзакція ініціюється адресою точки входу (адреса EntryPoint) і викликає гаманець контракту AA. EIP-2938 надає уніфіковану специфікацію та офіційно вводить абстракцію облікового запису AA в консенсус Ethereum. Зокрема, він представляє два нових коди операцій, три глобальні змінні та іншу структуру корисного навантаження для консенсусу Ethereum.
EIP-3074
Представлений у 2020 році. Цей EIP представляє дві інструкції EVM, AUTH і AUTHCALL. AUTH встановлює змінну середовища відповідно до повноважень підпису ECDSA. AUTHCALL надсилає виклик як авторизований обліковий запис. Це дозволяє розумним контрактам надсилати транзакції від імені EOA. Але це все ще не ідеальне рішення для АА. У процесі транзакції авторизації EIP-3074 має певні обмеження щодо передачі вихідного значення. І якщо користувач втратить доступ до EOA, відновити його активи все одно буде неможливо. У разі витоку закритого ключа користувачеві потрібно перенести всі активи в новий обліковий запис.
Жодна з наведених вище пропозицій не була офіційно включена в протокол Ethereum через необхідність змін на рівні консенсусу або тому, що пропозиції були недостатньо повними. Тому спільнота Ethereum продовжувала досліджувати, як ввести AA в протокол Ethereum без зміни консенсусу, і нарешті запропонувала EIP4337.
ERC - 4337
EIP-4337 спочатку було запропоновано у вересні 2021 року та затверджено як ERC-4337 у березні 2023 року. Його авторами є Віталік Бутерін, Йоав Вайс, Крістоф Газсо, Намра Пател, Дрор Тірош, Шахаф Наксон і Тьяден Гесс.
EIP-4337 — це революційна пропозиція, яка може запровадити АА без зміни основного протоколу Ethereum. Згодом EIP-4337 став стандартом ERC-4337, який розробники можуть використовувати для впровадження власних гаманців з розумними контрактами. У той же час стандарт також представляє деяку додаткову інфраструктуру, включаючи «Bundlers» і «UserOperation mempool». Таким чином, він фактично відтворює мемпул Ethereum із подібними функціями на верхньому рівні системи блокчейну. Користувач надсилає вже не одну транзакцію, а UserOperation. Кілька UserOperations можна об’єднати в одну транзакцію та надіслати в Ethereum.
Нижче наведено детальне технічне пояснення ERC-4337 в Ethereum [офіційна документація]( разом із деякими корисними коментарями.
Ключові ролі та визначення ERC-4337
UserOperation — описує структуру транзакції, надісланої від імені користувача. Щоб уникнути плутанини, вона не називається "транзакція", і її буде надіслано до Bundler для упаковки як Bundle з іншими UserOperations. Потім пакет надсилається в мережу як одна транзакція.
Sender — договірний обліковий запис, який надсилає UserOperation. Договір гаманця має відповідати стандарту ERC-4337 для налаштування інтерфейсу IAaccount.
EntryPoint — глобальний єдиний контракт, який виконує пакет UserOperations. Підтримувані EntryPoints у білому списку пакетів/клієнтів. Контракт перевірено та схвалено для розгортання командою Infinitism, яка відповідає за обробку всіх операцій користувача та підключення контрактів з іншими ролями, зокрема Wallet Factory, Aggregator та Paymaster. Уся угода знаходиться за тією самою адресою в ланцюжку, сумісному з EVM.
Bundler — вузол, який пакує кілька UserOperations з mempool і створює транзакцію EntryPoint.handleOps() (поточний виробник блоку). Сервіс Bundler може працювати незалежно від вузлів блокчейну та надсилати запаковані UserOperations через RPC.
Агрегатор — допоміжний контракт, якому облікові записи довіряють для перевірки агрегованих підписів. Підтримувані агрегатори підписів у білому списку групувальників/клієнтів. Агрегатор має відповідати стандарту ERC-4337, щоб налаштувати інтерфейс IAggregator.
Paymaster — розумний контракт, який може оплачувати газ від вашого імені. Якщо він вносить достатню кількість ETH у контракт EntryPoint, він може сплатити комісію за газ для UserOperation для відправника, ефективно реалізуючи відбір газу. Paymaster має дотримуватися стандарту ERC-4337, щоб налаштувати інтерфейс Paymaster. Платіжник може укласти договір з Відправником. Наприклад, відправник платить USDC Paymaster, а Paymaster використовує ETH для оплати газу UserOperations, які він надсилає. Насправді Paymaster може вибрати підтримку будь-якого токена, включаючи токени ERC-20 і навіть токени в інших мережах.
Wallet Factory — розумний контракт, який може створювати контрактні гаманці для користувачів ERC-4337. Розгортання Wallet Factory не має дозволу. Як смарт-контракт у ланцюжку, його код відкритий для громадськості, і кожен може переглянути його. Фабрика Wallet Factory, яка широко використовується, повинна бути повністю перевірена професіоналами.
На діаграмі нижче пояснюється, як контракт EntryPoint взаємодіє з іншими учасниками.
Пакетувальники викликають функцію handleOps контракту EntryPoint, яка приймає UserOperation як вхідні дані.
handleOps перевірить UserOperation у ланцюжку, перевірить, чи він підписаний зазначеною адресою гаманця смарт-контракту, і підтвердить, чи гаманець має достатньо газу для компенсації Bundler.
Якщо перевірку пройдено, handleOps виконає функцію гаманця смарт-контракту відповідно до функції та вхідних параметрів, визначених у calldata UserOperation.
З іншого боку, коли Bundler використовує EOA для запуску функції handleOps, стягуватиметься комісія за газ. Гаманець із розумним контрактом може сплачувати комісію за газ пакетувальникам із балансу власного рахунку або вимагати оплати за контракт Paymaster. UserOperations не може пройти етап перевірки поза ланцюгом без достатньої кількості газу, тобто він зазнає невдачі перед виконанням транзакції в ланцюжку. Навіть якщо газу достатньо, UserOperations все одно може вийти з ладу через такі причини, як помилки під час виконання під час виконання. Для UserOperation, незалежно від того, успішно чи ні виконано контракт, контракт EntryPoint сплачуватиме комісію за газ Bundler-у, який запускає функцію handleOps.
(Витяг з офіційної документації:
Після набуття чинності ERC-4337 користувачі тепер можуть ініціювати блокчейн-транзакції двома способами. Один — традиційний спосіб, тобто EOA безпосередньо ініціює транзакцію. Інший полягає у використанні стандарту ERC-4337 для ініціювання UserOperation через Bundler, а потім Bundler запакує його в інші UserOperations і надішле до ланцюжка. Блок-схема нижче ілюструє різницю між звичайною транзакцією надсилання EOA та надсиланням UserOperation контрактного гаманця ERC-4337.
Дорогу заасфальтували, але пішоходів ще мало
ERC-4337 надає користувачам і розробникам потужну структуру для використання та створення АА на Ethereum. Незважаючи на те, що ця структура є важливим прогресом, все ще існують деякі проблеми та невизначеності, які необхідно розглянути та вирішити.
Прийняття АА все ще знаходиться в зародковому стані. За даними панелі аналізу Dune ERC-4337 (*[ERC-4337 Abstraction Account](з @niftytable), у ланцюжку було виконано лише 65 тисяч+ UserOperations, 90% з яких надходили з Polygon. Таким чином, кількість поточних виконаних UserOperations все ще дуже малий, і більшість із них. Частково це перевірка розробників, і лише невелика частина надходить від реальних користувачів. Ми помітили, що продукти, які інтегровано АА, все ще знаходяться на ранній стадії. Наразі ми можемо спостерігати, що Загалом пакетувальники все ще перебувають у стані збитків, і поточні втрати становлять понад 700 MATIC. Це головним чином спричинено тим, що деякі пакетувальники на Polygon неправильно оцінюють необхідний газ, у результаті чого газ, повернутий EntryPoint, є меншим за спожитий газ. Цю проблему потрібно вирішити на рівні клієнта Bundler.
Окрім цього, є кілька проблем, які потрібно вирішити. Однією з проблем є те, як Bundler обробляє помилки транзакцій.
Після пакетування кількох UserOperations разом Bundlerи спочатку змоделюють транзакцію, виявлять, чи буде збій у виконанні контракту, і розрахують, чи буде комісія за газ, яку повертає відправник або платіжник, більша за сплачену комісію за газ.
Якщо це прибутково, Bundler надсилає цю партію UserOperations як транзакцію на вузол блоку. Однак транзакція все ще може статися невдалою, в результаті чого Покупець сплатить комісію за газ, але не отримає відшкодування за газ від EntryPoint. Наприклад, користувач може надсилати дії до різних Bundlers. Якщо є прибуток і симуляція пройшла успішно, Bundlers передасть його в мережу. У цьому випадку, якщо UserOperation надіслано до вузла створення блоків різними Bundler-ами одночасно, лише одна транзакція буде успішною, що означає, що лише один Bundler отримає комісію за газ, повернуту EntryPoint, а всі інші Bundler-и зазнають невдачі. через ланцюг і втрачати газ. Хоча хтось може стверджувати, що таку поведінку слід вважати зловмисною атакою, і стверджувати, що Bundler може заборонити адресу відправника та відхилити будь-які майбутні запити з цієї адреси, це не є розумним рішенням, оскільки користувачі можуть вжити таку дію ненавмисно. Це питання має бути належним чином вирішено в коді, можливо, через публічний mempool, який знаходиться на стадії розробки. Крім того, Bundlers можуть зазнати збитків через раптові коливання газу, навіть якщо транзакцію успішно подано, а результати моделювання показують, що є можливість отримати прибуток.
Іншою проблемою є максимальне видобуте значення (MEV), яке можна отримати від AA. У контексті Ethereum MEV зазвичай відноситься до значення, яке майнери або інші процесори транзакцій витягують шляхом маніпулювання порядком транзакцій у блоці або вставлення власних транзакцій у блок. Можна помітити, що логіка MEV також може бути застосована до AA. Це пов’язано з тим, що в AA Bundlers можуть вільно послідовно виконувати UserOps, що дає їм можливість отримати MEV. Однак те, чи зможе Bundler отримати MEV, залежить від того, чи можна об’єднати достатню кількість UserOperations. Зараз весь ринок АА все ще знаходиться в зародковому стані, тому Bundler MEV також можна вважати зародковим. Можна побачити, що MEV AA може розвиватися в двох напрямках: один подібний до основної мережі Ethereum, за участю таких учасників, як Flashbots, Ultra Sound і BloXroute; інший напрямок полягає в формуванні консенсусу Bundler для реалізації справедливого сортування. А останнє повністю виключало б можливість вилучення МЕВ в АА.
майбутній розвиток
публічний mempool
Хоча екосистема АА вже працює, попереду ще багато роботи над розробкою. Дивлячись на всю екосистему АА, найбільше бракує наразі публічного mempool. Команда Etherspot, розробники клієнта Skandha Bundler, зараз розробляє p2p-мережу з публічним mempool. Очікується, що p2p-мережа публічних мемпулів буде запущена в серпні цього року.
Пакетний алгоритм
На цьому шляху фонд Ethereum профінансував кілька видатних команд розробників АА. Наразі розроблено кілька клієнтів Bundler, які доступні. Серед них деякі дуже зрілі. Це Candide (Voltaire Bundler, написаний на Python), Pimlico (Alto Bundler, написаний на Type), Etherspot (Skandha Bundler, написаний на Type), Stackup (Stackup-Bundler, написаний на Go) тощо.
Тут постає питання стратегії упаковки. Наразі через невелику кількість UserOperations Bundlerи можуть застосовувати просту логіку упаковки, наприклад фіксований часовий інтервал або певну кількість UserOperations у кожному Bundle. Однак із збільшенням кількості UserOperations, особливо після впровадження загальнодоступного mempool, стратегія вибору та упаковки UserOperations стає складнішою. Причина проста: в екології АА немає механізму, подібного до протоколу консенсусу блокчейну, і група Bundler стала темним лісом.Кожен Bundler розставляє пріоритети завдань відповідно до власних інтересів і конкурує один з одним. На відміну від публічних мемпулів, приватні мемпули можуть з'явитися раніше. Оскільки пакування UserOperations із загальнодоступного mempool є нерентабельним, усе ще можна пакувати UserOperations у приватний mempool. У цьому випадку Bundler більш конкурентоспроможний, ніж інші Bundlers, коли пакує.
Крім того, з поступовим популяризацією загальнодоступного mempool, UserOperations у ньому мають різні характеристики, такі як різні очікування прибутку Gas і складність виконання в ланцюжку. Розробники групування проводитимуть симуляції поза мережею, щоб оцінити прибутковість різних комбінацій UserOperations, щоб створити відповідні стратегії групування. Упаковка більшої кількості UserOperations має потенціал для отримання більших прибутків, але також збільшує ризик помилок перевірки. Навіть якщо перевірку пройдено, ризик збою виконання в ланцюжку все одно існує. Навпаки, менш упаковані UserOperations роблять протилежне. Пакетувальники повинні встановити власні параметри газу для транзакцій, що вплине на пріоритет виробників блоків для виконання цієї транзакції. За різних розрахункових умов ціни на газ і нестабільності газу постачальники можуть мати різні стратегії упаковки. У той же час, також необхідно враховувати вартість локальних апаратних обчислювальних ресурсів і ресурсів блокчейн-вузла для цих перевірок і розрахунків політики. Крім того, Bundlers також потрібно наполегливо працювати, щоб забезпечити користувачам якісний досвід роботи та гарантувати, що користувачі не стикаються з надмірними затримками після надсилання UserOperations.
Хоча шляхи вирішення цих завдань поки що неясні, ми можемо з упевненістю сказати, що розвиток індустрії АА та спільними зусиллями розробників зрештою вирішать ці проблеми. Як розробник інфраструктури, BlockPI сподівається відігравати роль вирішувача проблем у розвитку індустрії АА, як розробник або надавати інфраструктуру, зручну для АА, для інших розробників.
Інфраструктура повинна адаптуватися до АА
AA абстрагує різні ролі, які беруть участь у транзакціях у ланцюзі, включаючи Відправника, Пакетувальників, Платників за газ, контрактні гаманці та Підписувачів, щоб користувачі мали більший ступінь свободи під час використання блокчейну. У той же час постачальники інфраструктури можуть самостійно розгортати ці послуги відповідно до власної оцінки на ринку.
Щоб адаптуватися до широкомасштабного впровадження АА, постачальникам інфраструктури спочатку потрібно надати принаймні дві основні послуги: послугу Bundler і Paymaster.
У службах Bundler постачальникам інфраструктури може знадобитися розробити приватні пам’ятні пули з Bundlerами, щоб забезпечити хорошу взаємодію з користувачем. Зокрема, постачальникам інфраструктури потрібно інтегрувати кілька клієнтів Bundler, щоб забезпечити стабільність послуг Bundler. Ці клієнти Bundler наразі надають користувачам кілька стандартних методів JSON RPC, наданих основною групою розробки ERC-4337. Передбачається, що в майбутньому користувачам буде доступно більше методів RPC. Постачальникам інфраструктурних послуг необхідно своєчасно оновити підтримку цих методів під час цього процесу.
Крім того, дуже важливо оптимізувати між API Bundler і RPC клієнта вихідного вузла. Поточні клієнти вузлів не оптимізовані для AA. Деякі методи API Bundler вимагають від вузла надання індексу даних для AA. Наприклад, коли поточний клієнт шукає UserOperation за хешем, йому потрібно сканувати журнали контрактів EntryPoint у всіх блоках. Якщо немає індексу даних, споживання апаратних ресурсів для цього одного запиту буде досить великим, а час повернення запиту також стане дуже довгим.
Крім того, для того, щоб надати користувачам досвід без газу та різноманітні послуги, постачальники інфраструктури повинні співпрацювати з різними постачальниками послуг Paymaster для інтеграції різних служб Paymaster. У той же час, відповідно до потреб ринку, постачальники інфраструктури також можуть розробляти більш зручні інтегровані рішення на основі існуючих сервісів Paymaster. Інші сервіси, такі як агреговані підписи, фабрики гаманців тощо, також є потенційними напрямками майбутнього розвитку та інтеграції інфраструктури.
Коротше кажучи, щоб адаптуватися до широкомасштабного застосування АА, постачальники інфраструктури повинні постійно вдосконалювати та розширювати свої послуги. Це включає оптимізацію послуг Bundler, співпрацю з різними постачальниками послуг Paymaster, інтеграцію різних інтерфейсів API та розробку інших потенційних послуг. Оскільки індустрія АА продовжує розвиватися, ці зусилля допоможуть забезпечити більш ефективний, безпечний і зручний досвід блокчейну.