Як зробити так, щоб абстракція облікового запису дозволила інфраструктурі обслуговувати мільярди користувачів?

Автор: Альберт Хе, головний науковий співробітник BlockPI; Упорядник: MarsBit, MK

Екосистема Ethereum постійно розбудовується та самооптимізується, незалежно від того, чи є це ринок «бик» чи ринок «ведмежа». Серед них абстракція облікового запису (AA) стала дуже важливим прогресом за останні роки та проникла в різні компоненти екосистеми Ethereum, включаючи програми, інфраструктуру, користувачів і розробників.

Ми можемо передбачити, що широке впровадження АА у світі може знизити бар’єри для входу на блокчейн, таким чином перенісши досвід користувача web2 в галузь web3. **

Щоб скористатися можливістю формування багатомільярдного ринку АА, BlockPI планує виділити ресурси для інтеграції АА у свої інфраструктурні послуги. Розвиваючи інтеграцію АА, ми прагнемо надати користувачам АА більш зручні та ефективні способи взаємодії з обліковими записами своїх контрактних гаманців у блокчейні, а також позиціонувати BlockPI як лідера галузі.

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

EOA та розумний контрактний гаманець

**Концепція AA випливає з обмежень облікових записів EOA. **Облікові записи EOA (зовнішні облікові записи) — це типові облікові записи користувачів в Ethereum, представлені відкритим ключем (блокчейн-адресою), доступним через закритий ключ. Це основний компонент екосистеми Ethereum, що дозволяє користувачам взаємодіяти зі смарт-контрактами та виконувати транзакції в мережі. Однак використання EOA може бути складним для людей, і деякі незручності можуть вплинути на взаємодію з користувачем.

**Перша незручність EOA пов’язана з використанням газу. **Кожна транзакція коштуватиме користувачеві велику суму ETH у вигляді комісії за газ (проста комісія за переказ ETH у розмірі 25 Gwei для ціни на газ становить 0,5 доларів США та більше за контрактну взаємодію або вищу ціну на газ). Це робить комісії за транзакції дуже дорогими для невеликих транзакцій, особливо в періоди пікового навантаження на мережу. Крім того, лише ETH можна використовувати для оплати газу, що означає, що користувачі повинні мати ETH у своїх гаманцях, що є значною перешкодою для входу для багатьох користувачів.

**Друга незручність EOA полягає в тому, що умовні транзакції не можуть бути здійснені, якщо певна логіка не реалізована за допомогою інших смарт-контрактів. **Наприклад, якщо користувач хоче встановити часовий цикл передачі, він повинен перенести ETH на сторонній смарт-контракт із цією функцією, щоб досягти цієї функції.

**Третя незручність EOA — це алгоритм шифрування підпису. **Мережа Ethereum використовує спеціальний алгоритм цифрового підпису під назвою secp 256 k 1 для забезпечення автентичності та безпеки транзакцій. Це жорстко закодовано в системі, і користувач не може вибрати інший алгоритм.

Тому, відштовхуючись від цих проблем, люди почали намагатися знайти рішення. Розумні контрактні гаманці, такі як MetaMask і Argent, є результатом цих зусиль, усуваючи багато обмежень EOA за допомогою смарт-контрактів Ethereum для покращення функціональності облікових записів користувачів. Однак таке рішення все ще має деякі недоліки, головним чином вимагаючи від користувачів платити комісію за газ за транзакції та популярність гаманців із розумними контрактами.

**Грунтуючись на цих викликах, Ethereum почав намагатися запровадити нову концепцію, а саме абстракцію облікового запису. Мета абстракції облікового запису — вирішити ці проблеми на рівні протоколу, а не покладатися на розумні контракти чи інше проміжне програмне забезпечення. Це те, що ми зараз називаємо абстракцією облікового запису (AA). **

У решті цієї публікації я розповім про концепцію абстракції облікового запису та про те, як ми можемо використовувати її для оптимізації інфраструктури BlockPI.

**На додаток до трьох незручностей EOA, згаданих вище, обов’язковий зв’язок між відкритим і закритим ключами також є проблемою. **Закритий ключ є єдиним способом отримати доступ до EOA, у разі втрати закритий ключ неможливо відновити. Це означає, що якщо закритий ключ буде втрачено, усі активи, пов’язані з ним, не можна буде відновити.

**Крім того, EOA також стикається з обмеженнями під час виконання лінійних завдань в одній транзакції. **Наприклад, якщо користувач хоче затвердити, обміняти та скасувати затвердження маркерів однією дією, йому потрібно виконати три окремі транзакції, що неефективно та забирає багато часу.

Хороша новина полягає в тому, що усі перераховані вище проблеми можна вирішити за допомогою гаманців зі смарт-контрактами. Гаманець смарт-контракту — це особливий тип смарт-контракту, який реалізує АА. Він розроблений, щоб діяти як гаманець користувача в мережі Ethereum і надавати більш адаптивний та персоналізований спосіб управління їхніми коштами. Поки логіка смарт-контракту Ethereum може бути реалізована, гаманець смарт-контракту може забезпечувати необхідні функції.

Зокрема, транзакції гаманця смарт-контрактів можна об’єднати в транзакцію в ланцюжку для розподілу вартості газу.Якщо третя сторона готова платити, витрат на газ може навіть не бути. Операція може сприяти виконанню послідовних завдань у своєму гаманці смарт-контрактів. Гаманець смарт-контрактів може підтримувати будь-який алгоритм шифрування підпису, встановлювати коди відновлення тощо.

Попри всі розмови про переваги гаманців із розумними контрактами, спільнота Ethereum фактично працює над гаманцями з контрактами з самого початку. Хоча було запропоновано багато EIP для вивчення абстракції облікового запису, до 2021 року не було встановлено єдиного стандарту. Нижче наведено деякі з найбільш репрезентативних пропозицій.

EIP-86

Створено у 2017 році Віталіком Бутеріним. Реалізовано низку змін до «абстрактних» служб перевірки підпису та одноразової перевірки, дозволяючи користувачам створювати «контракти облікових записів», які виконують будь-які бажані перевірки підписів/одноразових перевірок.

EIP-2938

Створено в 2020 році. Назва цього EIP – Абстракція облікового запису. Цей EIP деталізує концепцію АА. Він вводить новий тип транзакцій, транзакцію AA. Ця транзакція буде ініціалізована адресою EntryPoint і викличе контракт гаманця AA. Таким чином, він забезпечує уніфіковану специфікацію та вводить АА в консенсус Ethereum. Більш конкретно, він додає два нові коди операцій, три глобальні змінні та іншу структуру корисного навантаження до консенсусу Ethereum.

EIP-3074

Створено в 2020 році. Цей EIP представляє дві інструкції EVM, AUTH і AUTHCALL. AUTH встановлює контекстну змінну під назвою авторизований на основі підпису ECDSA. AUTHCALL надсилає виклик від імені авторизованого облікового запису. Це дозволяє розумному контракту надсилати транзакції від імені EOA. Але це не ідеальне рішення для АА. EIP-3074 накладає певні обмеження на передачу рідної вартості під час трансакцій спонсорства. Якщо ви втратите доступ до EOA, ви не зможете відновити свої активи, а в разі викрадення всі активи потрібно буде перенести на новий обліковий запис.

Жодна з наведених вище ідей не була офіційно прийнята в протокол Ethereum через серйозні причини, такі як необхідність внесення змін на консенсусному рівні або відсутність вичерпності. Тому спільнота Ethereum продовжувала досліджувати, як ввести AA в протокол Ethereum без зміни консенсусу, і нарешті створила EIP 4337.

ERC — 4337

EIP-4337 спочатку було запропоновано у вересні 2021 року та затверджено як ERC-4337 у березні 2023 року. Його авторами є Віталік Бутерін, Йоав Вайс, Крістоф Газсо, Намра Пател, Дрор Тірош, Шахаф Наксон і Тьяден Гесс.

EIP-4337 — це кардинальна пропозиція, яка вводить AA без внесення змін до основного протоколу Ethereum. EIP-4337 керує стандартом ERC-4337, який розробники можуть використовувати для реалізації своїх власних гаманців із смарт-контрактами, і включає деяку додаткову інфраструктуру, включаючи пули пам’яті «Bundlers» і UserOperation. Роблячи це, він, по суті, повторює функціональність пам’ятного пулу транзакцій у більш вдосконаленій системі. Замість надсилання транзакцій користувачі надсилають об’єкти UserOperation, які потім можуть бути упаковані в одну транзакцію та включені в ланцюжок Ethereum.

Нижче наведено більш конкретне технічне пояснення ERC-4337 з офіційної документації, а також деякі коментарі для кращого розуміння.

Визначення та ключові ролі ERC-4337

UserOperation — структура, що описує транзакції, відправлені від імені користувача. Щоб уникнути плутанини, це не називається "транзакція". Він надсилається до Bundler для упаковки з іншими UserOperations. Потім пакет надсилається творцю блоку як одна транзакція.

Відправник — договірний обліковий запис, який надсилає нову UserOperation. Розумний контрактний гаманець повинен реалізовувати інтерфейс IAaccount ERC-4337.

EntryPoint — єдиний контракт, який реалізує пакет UserOperations. Підтримувані EntryPoints у білому списку пакетів/клієнтів. Цей контракт схвалено та перевірено командою Infinitism, яка відповідає за обробку всіх операцій користувача та підключення інших контрактів, зокрема Wallet Factory, Aggregator, Paymaster. Він матиме однакову адресу в більшості EVM-сумісних мереж.

Bundler — вузол (конструктор блоків), який об’єднує кілька UserOperations із мемпулу та створює транзакції EntryPoint.handleOps(). Усі валідатори на рівні протоколу не обов’язково мають бути об’єднувачами. Служба Bundler може працювати незалежно від конструктора блоків і використовує RPC для надсилання об’єднаних UserOperations.

Агрегатор — допоміжний контракт, якому облікові записи довіряють для перевірки агрегованих підписів. Підтримувані агрегатори в білому списку групувальників/клієнтів. Агрегатори повинні реалізувати інтерфейс ERC-4337 IAggregator.

Paymaster — Контракт, який може сплачувати комісію UserOperation за газ для Відправника, якщо достатньо ETH внесено в контракт EntryPoint. Paymaster реалізує ефективний відбір газу. Paymaster має реалізувати інтерфейс Paymaster ERC-4337. Paymaster може мати власну логіку для укладання угоди з Sender. Наприклад, відправник платить USDC Paymaster, а Paymaster спонсорує свої UserOperations за допомогою ETH. Насправді будь-який токен ERC 20 або навіть токени в інших мережах можуть підтримуватися, якщо Paymaster погоджується і це технічно можливо.

Wallet Factory — контракт, який можна викликати для створення смарт-контрактних гаманців для користувачів ERC-4337. Розгортання фабрики гаманців не має дозволу. Як компонент мережі, він відкритий для публічного аудиту та прозорого контролю. Фабрика Wallet Factory, що широко використовується, повинна бути повністю перевірена професіоналами.

На діаграмі нижче пояснюється, як контракт EntryPoint взаємодіє з іншими учасниками.

Пакетувальники викликають функцію handleOps контракту EntryPoint, яка приймає UserOperation як вхідні дані.

handleOps перевіряє UserOperation у ланцюжку, перевіряє, чи підписано його вказаною адресою гаманця смарт-контракту та чи має гаманець достатньо Gas для компенсації Bundler.

Якщо перевірка пройшла успішно, handleOps виконає функцію гаманця смарт-контракту відповідно до підпису функції та вхідних параметрів, визначених у даних виклику UserOperation.

З іншого боку, коли Bundler використовує EOA для запуску функції handleOps, стягуватиметься комісія за газ. Розумний контрактний гаманець може сплачувати комісію за газ Bundler-ам зі свого власного балансу рахунку або вимагати від Paymaster контракту оплатити від його імені. UserOperations, які не мають достатньо газу, не можуть пройти процес перевірки в цільовому гаманці смарт-контрактів і, таким чином, виходять з ладу перед виконанням. Навіть якщо газу достатньо, під час виконання UserOperations може виникнути збій, наприклад, через помилки виконання. Незалежно від того, успішно чи ні виконання, контракт EntryPoint сплатить комісію за газ групувальнику, який запускає функцію handleOps.

(Джерело: Офіційна документація:

Після набуття чинності ERC-4337 у користувачів тепер є два способи ініціювати транзакції блокчейну. Один — оригінальний спосіб, коли EOA ініціює транзакцію. Інший полягає у використанні стандарту ERC-4337 для запуску UserOperation через Bundler, а потім Bundler запакує його в інші UserOperations та ініціює його в ланцюжку. Наступна блок-схема ілюструє різницю між звичайною транзакцією надсилання EOA та надсиланням UserOperation контрактного гаманця ERC-4337.

Дорога асфальтована, але пасажирів небагато

ERC-4337 забезпечує потужну структуру для користувачів і розробників для використання та створення АА на платформі Ethereum. Незважаючи на те, що ця структура є важливим кроком вперед, ще потрібно розглянути та вирішити кілька проблем і невизначеностей.

**Прийняття АА знаходиться в зародковому стані. **Згідно з панеллю аналізу Dune ERC-4337 (ERC-4337 Абстракція облікового запису з @niftytable), лише 65 k+ UserOperations виконуються в ланцюжку, 90% з яких з Polygon. Таким чином, кількість UserOperations, які виконуються в цей час, все ще дуже мала, більшість з яких є тестами розробників, і лише мала частина приписується користувачам. Зауважимо, що продукти з інтегрованим АА все ще знаходяться на ранніх стадіях. У той же час ви бачите, що прибуток Bundler негативний (-700 в термінах MATIC). Це пов’язано з тим, що деякі постачальники пакетів на Polygon неправильно розраховують газ для попередньої перевірки. Цей алгоритм перевірки ще потребує оптимізації.

**Крім цього, є кілька недоліків, які потрібно вирішити. Однією з таких проблем є те, як Bundler обробляє помилки транзакцій. **Після того, як Bundler пакетує кілька UserOperations разом, Bundler спочатку симулює транзакцію, щоб перевірити, чи буде її відкат, а потім обчислює, чи є комісія за газ, яку повертає відправник або платіжник, більшою за комісію за газ, сплачену транзакцією. Якщо це вигідно, Bundler надсилає цю групу UserOperations разом як транзакцію конструктору блоків. Однак транзакція все одно може бути невдалою, в результаті чого Покупець сплатить комісію за газ, але не отримає газ назад від EntryPoint. Наприклад, користувач може надсилати дії до різних Bundlers. Пакетувальники готові виконувати будь-які операції в ланцюжку, якщо вони приносять прибуток і їхнє моделювання є успішним. Це означає, що якщо UserOperation надсилається різними Bundler-ами одночасно. Лише одна трансакція буде успішною, лише один Bundler отримає комісію за газ від EntryPoint, усі інші Bundlerи втратять газ через збій у мережі. Хоча можна стверджувати, що користувачі не повинні цього робити, така поведінка вважатиметься зловмисною атакою, і що Bundler може заборонити адресу відправника та відхилити будь-які майбутні запити з цієї адреси, це нерозумний підхід, оскільки користувачі Ця операція може мати було подано ненавмисно. Такі проблеми необхідно належним чином вирішити в кодексі, можливо, розробивши незавершену публічну мережу mempool. Крім того, через раптові коливання газу Bundlers можуть зіткнутися з втратами, навіть якщо транзакції були успішно подані та змодельовані як прибуткові.

**Інша річ — максимальне витягуване значення (MEV), яке можна отримати з AA. **У контексті Ethereum MEV зазвичай означає значення, яке майнери або інші процесори транзакцій можуть отримати, маніпулюючи порядком транзакцій у блоці або включаючи власні транзакції в блок. Хтось помітив, що логіку MEV також можна застосувати до AA, оскільки Bundlerи можуть вільно замовляти UserOperations? Однак це умовно, потрібно об’єднати достатню кількість UserOperations, щоб Bundler міг отримати MEV. Зараз весь ринок АА все ще знаходиться в зародковому стані, тому Bundler MEV також можна вважати зародковим. Загалом індустрія **AA може розвиватися у двох напрямках: один схожий на основну мережу Ethereum з такими учасниками, як Flashbots, Ultra Sound і BloXroute, а інший — формування консенсусу Bundler для забезпечення справедливого сортування. Останній підхід повністю виключає можливість MEV при AA. **

майбутній розвиток

публічний mempool

Хоча екосистема АА вже функціонує, попереду ще багато роботи над розробкою. Дивлячись на всю екосистему АА, найбільшою прогалиною на даний момент є публічний mempool. Команда Etherspot, розробники клієнта Skandha Bundler, зараз розробляє p2p-мережу з публічним mempool. Очікується, що p2p-мережа публічного mempool стане доступною в серпні цього року.

Алгоритм упаковки

Попутно фонд Ethereum профінансував кілька команд розробників АА, які складалися з відданих і працьовитих розробників. На сьогоднішній день розроблено кілька версій клієнта Bundler, які доступні. Деякі з них є високорозвиненими щодо зрілості продукції. Це Candide (Voltaire Bundler, написаний на Python), Pimlico (Alto Bundler, написаний на Type), Etherspot (Skandha Bundler, написаний на Type), Stackup (Stackup-Bundler, написаний на Go) та багато інших.

Тепер давайте детальніше зануримося в алгоритм упаковки. Наразі через низьку кількість UserOperations Bundlers можуть використовувати просту та зрозумілу логіку упаковки, таку як фіксовані часові інтервали або кількість UserOperations у кожному пакеті. Однак із збільшенням кількості UserOperations, особливо після впровадження загальнодоступного mempool, стратегія вибору та упаковки UserOperations стає складнішою. Причина проста: без консенсусного протоколу, такого як блокчейн, Bundlers утворюють темний ліс, кожен з яких визначає пріоритетність роботи відповідно до власних інтересів і конкурує один з одним. Приватні мемпули, відповідно відповідні публічним мемпулам, швидше за все, будуть першими. Тому що, коли невигідно пакувати UserOperations із загальнодоступного mempool, може стати вигідно пакувати UserOperations разом у приватний mempool. Таким чином, Bundler має конкурентну перевагу, коли мова заходить про упаковку.

Крім того, у міру того, як публічний mempool буде поступово прийнятий, UserOperations у ньому матимуть різні характеристики, наприклад різні очікувані прибутки від Gas та складність виконання в ланцюжку. Розробники групування проводитимуть симуляції поза мережею, щоб оцінити прибутковість різних комбінацій UserOperations, щоб створити свої унікальні стратегії групування. Упаковка більшої кількості UserOperations потенційно може принести більший прибуток, але також збільшує ризик помилок перевірки. Навіть якщо перевірку пройдено, ризик збою виконання в ланцюжку все одно існує. Менш запаковані UserOperations роблять навпаки. Пакетувальники повинні встановлювати власні параметри газу транзакцій, що впливатиме на пріоритет виконання транзакцій конструкторами блоків. За різних ринкових цін на газ і умов нестабільності газу постачальники можуть мати різні стратегії упаковки. У той же час ці перевірки та обчислення політики потребують використання локальних обчислювальних ресурсів апаратного забезпечення та ресурсів вузла блокчейну. Групувальники також повинні переконатися, що користувачі мають хороший досвід і що користувачі не стикаються з надмірними затримками після надсилання UserOperation.

Хоча рішення цих проблем залишаються невизначеними, ми можемо бути впевнені, що розвиток індустрії АА та об’єднані зусилля розробників зрештою знайдуть рішення. Як розробник інфраструктури, BlockPI сподівається вирішити проблеми розвитку індустрії АА як розробник, так і для забезпечення зручної інфраструктури АА для інших розробників.

Інфраструктура повинна адаптуватися

AA абстрагує різні ролі в поведінці транзакцій у ланцюжку, включаючи відправників, групувальників, платників газу, контрактних гаманців і підписувачів, що дозволяє користувачам мати більший ступінь свободи при використанні блокчейну. Крім того, служби в рамках АА можна розгортати окремо.

**Щоб забезпечити широкомасштабне впровадження АА, постачальники інфраструктури спочатку повинні надати принаймні дві основні послуги, а саме послугу Bundler і Paymaster. **

У службі Bundler постачальнику інфраструктури може знадобитися розробити приватний mempool з Bundlerами, щоб забезпечити хорошу взаємодію з користувачем. Зокрема, постачальники інфраструктури повинні інтегрувати різні клієнти Bundler, щоб забезпечити надійність послуг Bundler. Ці клієнти Bundler розроблені на різних мовах програмування, але всі вони надають стандартний набір методів JSON RPC, визначених основною командою ERC-4337. Наразі доступних методів небагато, але в майбутньому буде додано більше методів. Постачальники інфраструктурних послуг повинні забезпечити постійну та повну підтримку цих API.

Крім того, важливо оптимізувати та адаптувати зв’язок між API Bundler і клієнтським RPC вузла джерела. Ми знаємо, що поточний клієнт вузла недостатньо оптимізований для чутливості та адаптивності AA. Для роботи деяких методів Bundler API потрібен індекс даних AA. Наприклад, пошук UserOperation за хешем вимагає індексації всіх UserOperations. Інакше споживання апаратного забезпечення для цього єдиного запиту буде дуже високим, і для повернення запиту знадобиться багато часу.

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

Наразі BlockPI фактично намагається досягти всіх перерахованих вище цілей. Мало того, ми спілкуємося майже з усіма клієнтами Bundler і постачальниками послуг Paymaster у спільноті, і зробили інтеграцію служби AA в мережу BlockPI нашим головним пріоритетом. Ми також проводимо поглиблені обговорення з розробниками гаманців AA, щоб зрозуміти потреби користувачів. Тому ми щиро вітаємо співпрацю та обміни з усіма Пакетувальниками, Платжниками та гаманцями, коли ми просуваємося вперед. Наша загальна мета — будувати та розвивати екосистему АА разом з іншими, сприяючи її зростанню та розвитку якнайкраще від наших можливостей. Працюючи разом, ми сподіваємося зробити вагомий внесок у галузь АА загалом і підтримати її подальший розвиток. Тому що, зрештою, наша головна місія — бути піонером у галузі та сприяти розвитку екосистеми АА, щоб користувачі web2 могли насолоджуватися своїм досвідом блокчейну без перешкод.

Підведіть підсумки

З точки зору АА, ми перебуваємо в новому історичному моменті. Хоч у нас на бульварі дороги з твердим покриттям, але райдерів поки небагато. Наразі застосування АА все ще перебуває в зародковому стані. ERC-4337 надає користувачам і розробникам потужну структуру для використання та створення АА на платформі Ethereum. Проте існує ще багато проблем і невизначеностей, які потрібно вирішити.

**Постачальник інфраструктури AA повинен надавати послуги Bundler і Paymaster для своїх користувачів, а також інтегрувати різних клієнтів Bundler і постачальників послуг Paymaster, щоб забезпечити надійність послуги. **Щоб оптимізувати швидкість реагування між клієнтами API та вузлами, може знадобитися індексувати дані AA, щоб зменшити споживання обладнання для одного запиту. Щоб забезпечити кращий досвід користувачів, постачальники інфраструктури також повинні надавати користувачам більше можливостей обслуговування.

**У майбутньому, оскільки екосистема AA продовжує розвиватися та з’являються загальнодоступні мемпули, стратегія вибору та упаковки UserOperations стане складнішою. **Кожен бандлер визначає пріоритети своєї роботи на основі власних інтересів і конкурує з іншими бандлерами. Збірники повинні встановлювати власні параметри газу транзакцій, які впливають на пріоритет виконання транзакцій конструкторами блоків. За різних ринкових цін на газ і умов нестабільності газу постачальники можуть мати різні стратегії упаковки.

Незважаючи на те, що вирішення цих проблем невідомо, ми можемо бути впевнені, що розвиток індустрії АА та об’єднані зусилля розробників зрештою знайдуть рішення. Як розробник інфраструктури BlockPI сподівається вирішувати проблеми в розвитку індустрії АА як розробник або надаючи дружню інфраструктуру АА для інших розробників. Наша місія полягає в тому, щоб сприяти розвитку екосистеми АА, щоб користувачі Web2 могли насолоджуватися користуванням блокчейном без перешкод.