Екосистема Ethereum постійно розвивається та самооптимізується, незалежно від того, чи є це ринок «бичачий» чи «ведмежий». Серед них, абстракція облікових записів (AA) досягла значного прогресу за останні роки та проникла в усі частини екосистеми Ethereum, включаючи програми, інфраструктуру, користувачів і розробників. Ми можемо передбачити, що широкомасштабне впровадження АА знизить поріг використання блокчейну в цілому та впровадить користувальницький досвід web2 у галузь web3.
Щоб скористатися можливістю потенційно багатомільярдного ринку АА, BlockPI планує інтегрувати АА у свої інфраструктурні послуги. Завдяки інтеграції та інноваціям у сфері АА BlockPI прагне надати користувачам АА більш зручний і ефективний спосіб взаємодії з обліковими записами гаманців із контрактами на блокчейні та сподівається стати лідером у цій галузі.
У цій статті команда 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 також має обмеження при виконанні окремих лінійних завдань. Наприклад, якщо користувач бажає схвалити (approve), обміняти (swap) і скасувати схвалення токенів (unapprove token) за одну операцію, потрібно виконати три окремі транзакції, що є неефективним і трудомістким.
Хороша новина полягає в тому, що контрактні гаманці можуть вирішити всі перераховані вище проблеми. Контрактний гаманець — це, по суті, певний тип розумного контрактного облікового запису, який реалізує 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 для упаковки разом з іншими UserOperations як пакет. Потім пакет надсилається в мережу як одна транзакція.
Sender—контрактний обліковий запис, який надсилає UserOperation. Договір гаманця має відповідати стандарту ERC-4337 для налаштування інтерфейсу IAaccount.
EntryPoint - глобальний єдиний контракт, який виконує пакет UserOperations. Підтримувані EntryPoints у білому списку пакетувальників/клієнтів. Контракт перевірено та схвалено для розгортання командою Infinitism, яка відповідає за обробку всіх операцій користувача та підключення контрактів з іншими ролями, зокрема Wallet Factory, Aggregator та Paymaster. Уся угода знаходиться за тією самою адресою в ланцюжку, сумісному з EVM.
Bundler — вузол, який пакує кілька UserOperations з mempool і створює транзакцію EntryPoint.handleOps() (поточний вузол виробника блоків). Служба Bundler може працювати незалежно від вузлів блокчейну та надсилати запаковані UserOperations через RPC.
Агрегатор — допоміжний контракт, якому облікові записи довіряють для перевірки агрегованих підписів. Підтримувані агрегатори підписів у білому списку групувальників/клієнтів. Агрегатори повинні налаштувати інтерфейс IAggregator відповідно до стандарту ERC-4337.
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, стягуватиметься комісія за газ. Гаманець смарт-контракту може сплачувати комісію Bundlers Gas із власного балансу рахунку або вимагати оплати за контракт 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 Account Abstraction], у ланцюжку було виконано лише понад 65 тисяч операцій користувача, 90% з яких надходили з Polygon. Таким чином, кількість UserOperations, які зараз виконуються, все ще дуже мала, більшість з яких є тестами розробників, і лише невелика частина надходить від реальних користувачів. Зауважимо, що продукти з інтегрованим АА все ще знаходяться на ранніх стадіях. Наразі ми можемо спостерігати, що Bundlers в цілому все ще перебуває в збитковому стані, і поточні втрати становлять приблизно понад 700 MATIC. Це в основному спричинено тим, що деякі Bundlers на Polygon неправильно оцінюють необхідний газ, у результаті чого газ, який повертає EntryPoint, є меншим, ніж газ, спожитий поданим Bundle. Цю проблему потрібно вирішити на рівні клієнта Bundler.
Окрім цього, є кілька проблем, які потрібно вирішити. Однією з таких проблем є те, як Bundler обробляє помилки транзакцій.
Після пакетування кількох UserOperations разом Bundlerи спочатку змоделюють транзакцію, виявлять, чи буде збій у виконанні контракту, і розрахують, чи буде комісія за газ, яку повертає відправник або платіжник, більша за сплачену комісію за газ.
Якщо це прибутково, Bundler надсилає цю партію UserOperations на вузол блоку як транзакцію. Однак транзакція все ще може статися невдалою, в результаті чого Покупець сплатить комісію за газ, але не отримає відшкодування за газ від EntryPoint. Наприклад, користувач може надсилати дії до різних Bundlers. Якщо є можливість отримати прибуток і симуляція пройшла успішно, Bundlers передає це в мережу. У цьому випадку, якщо UserOperation надсилається на вузол блоку різними Bundler-ами одночасно, лише одна транзакція буде виконана успішно, що означає, що лише один Bundler отримає комісію за газ, повернуту EntryPoint, а всі інші Bundler-и не вдасться виконати через до ланцюга і втратити газ. Хоча хтось може стверджувати, що таку поведінку слід вважати зловмисною атакою, і стверджувати, що Bundler може заборонити адресу відправника та відхилити будь-які майбутні запити з цієї адреси, це не є розумним рішенням, оскільки користувачі можуть вжити таку дію ненавмисно. Цю проблему потрібно належним чином вирішити в коді, можливо, через публічну мережу mempool, яка знаходиться на стадії розробки. Крім того, бандлери можуть зазнати збитків через раптові коливання газу, навіть якщо транзакцію успішно подано, а результати моделювання показують, що є можливість для прибутку.
Іншою проблемою є максимальне видобуте значення (MEV), яке можна отримати від AA. У контексті Ethereum MEV зазвичай відноситься до значення, яке майнери або інші процесори транзакцій витягують шляхом маніпулювання порядком транзакцій у блоці або вставлення власних транзакцій у блок. Можна помітити, що логіка MEV також може бути застосована до AA. Це пов’язано з тим, що в AA Bundlers можуть вільно замовляти UserOps, що дає їм можливість придбати MEV. Однак те, чи зможе Bundler отримати MEV, залежить від того, чи можна об’єднати достатню кількість UserOperations. Зараз весь ринок АА все ще знаходиться в зародковому стані, тому Bundler MEV також можна вважати зародковим. Можна побачити, що MEV AA може розвиватися в двох напрямках: один подібний до основної мережі Ethereum, за участю таких учасників, як Flashbots, Ultra Sound і BloXroute; інший напрямок полягає в формуванні консенсусу Bundler для реалізації справедливого сортування. Останнє повністю виключало б можливість вилучення MEV в AA.
майбутній розвиток
публічний 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 постачальнику інфраструктури може знадобитися розробити приватний mempool разом із Bundlerами, щоб забезпечити хорошу взаємодію з користувачем. Зокрема, постачальники інфраструктури повинні інтегрувати різні клієнти Bundler, щоб забезпечити стабільність послуг Bundler. Ці клієнти Bundler наразі надають користувачам кілька стандартних методів JSON RPC, наданих основною групою розробки ERC-4337. Передбачається, що в майбутньому користувачам буде доступно більше методів RPC. Постачальникам інфраструктурних послуг необхідно своєчасно оновити підтримку цих методів під час цього процесу.
Крім того, важливо оптимізувати між Bundler API і RPC клієнта вихідного вузла. Поточний клієнт вузла не оптимізований для AA. Деякі методи API Bundler вимагають індексування даних, наданих для AA. Наприклад, коли поточний клієнт шукає UserOperation за хешем, йому потрібно сканувати журнали контрактів EntryPoint у всіх блоках. Якщо немає індексу даних, споживання апаратних ресурсів для цього одного запиту буде досить великим, а час повернення запиту також стане дуже довгим.
Крім того, для того, щоб надати користувачам досвід без газу та різноманітні послуги, постачальники інфраструктури повинні співпрацювати з різними постачальниками послуг Paymaster для інтеграції різних служб Paymaster. У той же час, відповідно до потреб ринку, постачальники інфраструктури також можуть розробляти більш зручні інтегровані рішення на основі існуючих сервісів Paymaster. Інші сервіси, такі як агреговані підписи, фабрики гаманців тощо, також є потенційними напрямками майбутнього розвитку та інтеграції інфраструктури.
Коротше кажучи, щоб адаптуватися до широкомасштабного застосування АА, постачальники інфраструктури повинні постійно вдосконалювати та розширювати свої послуги. Це включає оптимізацію послуг Bundler, співпрацю з різними постачальниками послуг Paymaster, інтеграцію різних інтерфейсів API та розробку інших потенційних послуг. Оскільки індустрія АА продовжує розвиватися, ці зусилля допоможуть забезпечити більш ефективний, безпечний і зручний досвід блокчейну.
Зараз BlockPI наполегливо працює над досягненням вищезазначених цілей. Мало того, ми спілкувалися майже з усіма клієнтами Bundler і постачальниками послуг Paymaster у спільноті та плануємо інтегрувати AA в мережу BlockPI як наше головне завдання розробки. У той же час ми також провели поглиблене спілкування з розробниками гаманців AA, щоб зрозуміти потреби користувачів. Ми щиро вітаємо всіх пакетників, платників і гаманців спілкуватися та співпрацювати з нами.
Мета BlockPI — будувати та розвивати екосистему АА разом із спільнотою та робити все можливе для сприяння прогресу та процвітанню екосистеми АА. Ми сподіваємося, що завдяки співпраці зі спільнотою ми зробимо внесок у всю індустрію АА як лідер галузі та підтримаємо процес її подальшого розвитку, щоб користувачі Web2 могли безперешкодно випробувати технологію блокчейн.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Як інфраструктура підтримує мільярди користувачів через абстракцію облікових записів?
Екосистема Ethereum постійно розвивається та самооптимізується, незалежно від того, чи є це ринок «бичачий» чи «ведмежий». Серед них, абстракція облікових записів (AA) досягла значного прогресу за останні роки та проникла в усі частини екосистеми Ethereum, включаючи програми, інфраструктуру, користувачів і розробників. Ми можемо передбачити, що широкомасштабне впровадження АА знизить поріг використання блокчейну в цілому та впровадить користувальницький досвід web2 у галузь web3.
Щоб скористатися можливістю потенційно багатомільярдного ринку АА, BlockPI планує інтегрувати АА у свої інфраструктурні послуги. Завдяки інтеграції та інноваціям у сфері АА BlockPI прагне надати користувачам АА більш зручний і ефективний спосіб взаємодії з обліковими записами гаманців із контрактами на блокчейні та сподівається стати лідером у цій галузі.
У цій статті команда 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 також має обмеження при виконанні окремих лінійних завдань. Наприклад, якщо користувач бажає схвалити (approve), обміняти (swap) і скасувати схвалення токенів (unapprove token) за одну операцію, потрібно виконати три окремі транзакції, що є неефективним і трудомістким.
Хороша новина полягає в тому, що контрактні гаманці можуть вирішити всі перераховані вище проблеми. Контрактний гаманець — це, по суті, певний тип розумного контрактного облікового запису, який реалізує 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 для упаковки разом з іншими UserOperations як пакет. Потім пакет надсилається в мережу як одна транзакція.
Sender—контрактний обліковий запис, який надсилає UserOperation. Договір гаманця має відповідати стандарту ERC-4337 для налаштування інтерфейсу IAaccount.
EntryPoint - глобальний єдиний контракт, який виконує пакет UserOperations. Підтримувані EntryPoints у білому списку пакетувальників/клієнтів. Контракт перевірено та схвалено для розгортання командою Infinitism, яка відповідає за обробку всіх операцій користувача та підключення контрактів з іншими ролями, зокрема Wallet Factory, Aggregator та Paymaster. Уся угода знаходиться за тією самою адресою в ланцюжку, сумісному з EVM.
Bundler — вузол, який пакує кілька UserOperations з mempool і створює транзакцію EntryPoint.handleOps() (поточний вузол виробника блоків). Служба Bundler може працювати незалежно від вузлів блокчейну та надсилати запаковані UserOperations через RPC.
Агрегатор — допоміжний контракт, якому облікові записи довіряють для перевірки агрегованих підписів. Підтримувані агрегатори підписів у білому списку групувальників/клієнтів. Агрегатори повинні налаштувати інтерфейс IAggregator відповідно до стандарту ERC-4337.
Paymaster — розумний контракт, який може оплачувати газ від вашого імені. Якщо він вносить достатню кількість ETH у контракт EntryPoint, він може сплатити відправнику смарт-контракт за комісію UserOperation за газ, ефективно реалізуючи відбір газу. Paymaster має дотримуватися стандарту ERC-4337, щоб налаштувати інтерфейс Paymaster. Платіжник може домовитися з Відправником. Наприклад, відправник платить USDC Paymaster, а Paymaster використовує ETH для оплати газу UserOperations, які він надсилає. Насправді Paymaster може вибрати підтримку будь-якого
Токен
, включаючи ERC-20
Токен
навіть інші ланцюги
Токен
.
На діаграмі нижче пояснюється, як контракт EntryPoint взаємодіє з іншими учасниками.
Пакетувальники викликають функцію handleOps контракту EntryPoint, яка приймає UserOperation як вхідні дані.
handleOps перевірить UserOperation у ланцюжку, перевірить, чи він підписаний вказаною адресою гаманця смарт-контракту, і підтвердить, чи гаманець має достатньо газу для компенсації Bundler.
Якщо перевірку пройдено, handleOps виконає функцію гаманця смарт-контракту відповідно до функції та вхідних параметрів, визначених у calldata UserOperation.
З іншого боку, коли Bundler використовує EOA для запуску функції handleOps, стягуватиметься комісія за газ. Гаманець смарт-контракту може сплачувати комісію Bundlers Gas із власного балансу рахунку або вимагати оплати за контракт 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 Account Abstraction], у ланцюжку було виконано лише понад 65 тисяч операцій користувача, 90% з яких надходили з Polygon. Таким чином, кількість UserOperations, які зараз виконуються, все ще дуже мала, більшість з яких є тестами розробників, і лише невелика частина надходить від реальних користувачів. Зауважимо, що продукти з інтегрованим АА все ще знаходяться на ранніх стадіях. Наразі ми можемо спостерігати, що Bundlers в цілому все ще перебуває в збитковому стані, і поточні втрати становлять приблизно понад 700 MATIC. Це в основному спричинено тим, що деякі Bundlers на Polygon неправильно оцінюють необхідний газ, у результаті чого газ, який повертає EntryPoint, є меншим, ніж газ, спожитий поданим Bundle. Цю проблему потрібно вирішити на рівні клієнта Bundler.
Окрім цього, є кілька проблем, які потрібно вирішити. Однією з таких проблем є те, як Bundler обробляє помилки транзакцій.
Після пакетування кількох UserOperations разом Bundlerи спочатку змоделюють транзакцію, виявлять, чи буде збій у виконанні контракту, і розрахують, чи буде комісія за газ, яку повертає відправник або платіжник, більша за сплачену комісію за газ.
Якщо це прибутково, Bundler надсилає цю партію UserOperations на вузол блоку як транзакцію. Однак транзакція все ще може статися невдалою, в результаті чого Покупець сплатить комісію за газ, але не отримає відшкодування за газ від EntryPoint. Наприклад, користувач може надсилати дії до різних Bundlers. Якщо є можливість отримати прибуток і симуляція пройшла успішно, Bundlers передає це в мережу. У цьому випадку, якщо UserOperation надсилається на вузол блоку різними Bundler-ами одночасно, лише одна транзакція буде виконана успішно, що означає, що лише один Bundler отримає комісію за газ, повернуту EntryPoint, а всі інші Bundler-и не вдасться виконати через до ланцюга і втратити газ. Хоча хтось може стверджувати, що таку поведінку слід вважати зловмисною атакою, і стверджувати, що Bundler може заборонити адресу відправника та відхилити будь-які майбутні запити з цієї адреси, це не є розумним рішенням, оскільки користувачі можуть вжити таку дію ненавмисно. Цю проблему потрібно належним чином вирішити в коді, можливо, через публічну мережу mempool, яка знаходиться на стадії розробки. Крім того, бандлери можуть зазнати збитків через раптові коливання газу, навіть якщо транзакцію успішно подано, а результати моделювання показують, що є можливість для прибутку.
Іншою проблемою є максимальне видобуте значення (MEV), яке можна отримати від AA. У контексті Ethereum MEV зазвичай відноситься до значення, яке майнери або інші процесори транзакцій витягують шляхом маніпулювання порядком транзакцій у блоці або вставлення власних транзакцій у блок. Можна помітити, що логіка MEV також може бути застосована до AA. Це пов’язано з тим, що в AA Bundlers можуть вільно замовляти UserOps, що дає їм можливість придбати MEV. Однак те, чи зможе Bundler отримати MEV, залежить від того, чи можна об’єднати достатню кількість UserOperations. Зараз весь ринок АА все ще знаходиться в зародковому стані, тому Bundler MEV також можна вважати зародковим. Можна побачити, що MEV AA може розвиватися в двох напрямках: один подібний до основної мережі Ethereum, за участю таких учасників, як Flashbots, Ultra Sound і BloXroute; інший напрямок полягає в формуванні консенсусу Bundler для реалізації справедливого сортування. Останнє повністю виключало б можливість вилучення MEV в AA.
майбутній розвиток
публічний 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 постачальнику інфраструктури може знадобитися розробити приватний mempool разом із Bundlerами, щоб забезпечити хорошу взаємодію з користувачем. Зокрема, постачальники інфраструктури повинні інтегрувати різні клієнти Bundler, щоб забезпечити стабільність послуг Bundler. Ці клієнти Bundler наразі надають користувачам кілька стандартних методів JSON RPC, наданих основною групою розробки ERC-4337. Передбачається, що в майбутньому користувачам буде доступно більше методів RPC. Постачальникам інфраструктурних послуг необхідно своєчасно оновити підтримку цих методів під час цього процесу.
Крім того, важливо оптимізувати між Bundler API і RPC клієнта вихідного вузла. Поточний клієнт вузла не оптимізований для AA. Деякі методи API Bundler вимагають індексування даних, наданих для AA. Наприклад, коли поточний клієнт шукає UserOperation за хешем, йому потрібно сканувати журнали контрактів EntryPoint у всіх блоках. Якщо немає індексу даних, споживання апаратних ресурсів для цього одного запиту буде досить великим, а час повернення запиту також стане дуже довгим.
Крім того, для того, щоб надати користувачам досвід без газу та різноманітні послуги, постачальники інфраструктури повинні співпрацювати з різними постачальниками послуг Paymaster для інтеграції різних служб Paymaster. У той же час, відповідно до потреб ринку, постачальники інфраструктури також можуть розробляти більш зручні інтегровані рішення на основі існуючих сервісів Paymaster. Інші сервіси, такі як агреговані підписи, фабрики гаманців тощо, також є потенційними напрямками майбутнього розвитку та інтеграції інфраструктури.
Коротше кажучи, щоб адаптуватися до широкомасштабного застосування АА, постачальники інфраструктури повинні постійно вдосконалювати та розширювати свої послуги. Це включає оптимізацію послуг Bundler, співпрацю з різними постачальниками послуг Paymaster, інтеграцію різних інтерфейсів API та розробку інших потенційних послуг. Оскільки індустрія АА продовжує розвиватися, ці зусилля допоможуть забезпечити більш ефективний, безпечний і зручний досвід блокчейну.
Зараз BlockPI наполегливо працює над досягненням вищезазначених цілей. Мало того, ми спілкувалися майже з усіма клієнтами Bundler і постачальниками послуг Paymaster у спільноті та плануємо інтегрувати AA в мережу BlockPI як наше головне завдання розробки. У той же час ми також провели поглиблене спілкування з розробниками гаманців AA, щоб зрозуміти потреби користувачів. Ми щиро вітаємо всіх пакетників, платників і гаманців спілкуватися та співпрацювати з нами.
Мета BlockPI — будувати та розвивати екосистему АА разом із спільнотою та робити все можливе для сприяння прогресу та процвітанню екосистеми АА. Ми сподіваємося, що завдяки співпраці зі спільнотою ми зробимо внесок у всю індустрію АА як лідер галузі та підтримаємо процес її подальшого розвитку, щоб користувачі Web2 могли безперешкодно випробувати технологію блокчейн.