Вивчення рішень для мультичейн абстрагування акаунтів: вбудована підтримка та сумісність зі стандартом ERC-4337

Автор: Ківі Яо (Kiwi Yao), дослідник @OKX Ventures

Рішення мультичейн абстракції акаунтів (AA) — це новий інноваційний спосіб взаємодії з кількома блокчейнами. Вони дозволяють користувачам створювати акаунти та керувати ними в кількох блокчейнах, не турбуючись про базові технічні деталі, як-от наявність достатньої кількості нативних токенів для оплати газу. Це значно полегшує користувачам початок роботи з технологією блокчейн і використовувати кілька блокчейнів одночасно. Існує два основних типи мультичейн рішень АА: вбудована підтримка та сумісність з ERC-4337.

Вбудована підтримка — це коли блокчейн безпосередньо підтримує мультичейн АА. Сумісність зі стандартом ERC-4337 полягає в тому, що рішення для масштабування блокчейну або рівня 2 використовує смарт-контракт для впровадження мультичейн АА. У цій статті ми розглянемо як власну підтримку, так і сумісність ERC-4337 для мультичейн рішень АА. Ми також обговоримо переваги та недоліки кожного підходу.

Мережі, сумісні з абстракцією акаунтів за стандартом ERC-4337

Arbitrum

Arbitrum офіційно активував кінцеві точки AA на Arbitrum One і Arbitrum Nova після прийняття пропозиції AIP-2. Пропозиція вводить нову кінцеву точку RPC — eth_sendRawTransactionConditional — вона спеціально розроблена, щоб задовольнити потреби пакетувальників ERC-4337.

Polygon

Polygon сумісний зі стандартом ERC-4337 і досягає цього завдяки використанню таких рішень, як Biconomy, Gas Station Network (GSN), Infura та Gelato для мета-транзакцій. Крім того, zkEVM від Polygon підтримує AA через стандарт ERC-4337, що дозволяє користувачам платити будь-яким токеном.

Optimism

В основній мережі OPР зараз доступні різні інфраструктури АА через такі проєкти, як Alchemy, Biconomy, CyberConnect, Pimlico та Stackup, хоча детальна інформація про архітектуру ще не опублікована.

BNB

У технічному плані розвитку мережі BNB на 2023 рік команда згадує про створення інфраструктури АА. Також підтверджено сумісність з ERC-4337, а незабаром планується випустити більше деталей.

Абстракція нативного акаунту

Starknet

Starknet нативно підтримує AA, відображаючи всі акаунти як контрактні (CA) або смарт-акаунти. Цілі нативної підтримки АА включають абстракцію підпису та абстракцію платежу. Вони спрямовані на те, щоб дозволити різним контрактам акаунтів використовувати різні схеми перевірки підписів і різні моделі оплати для транзакцій. Таким чином, зручність керування акаунтом буде значно покращена, оскільки користувачі тепер мають більше можливостей щодо підтвердження підпису та платежу від третьої сторони чи смарт-контракту.

Потік транзакцій Starknet

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

Різниця між цими етапами дозволяє ОС Starknet гарантувати оплату секвенсору. Щоб запобігти атаці відмови в обслуговуванні (DoS) на пул транзакцій Starknet і заповнювати його недійсними транзакціями, Starknet вимагає, щоб вузол, який приймає транзакцію, симулював локально відомий стан, перш ніж додавати транзакцію до пулу та транслювати її іншим вузлам і секвенсорам. Після завершення моделювання транзакція може бути введена в пул і поширена в мережі.

An illustration outlining the flow of a Starknet transaction

Джерело: StarkNet

Порівняння Starknet AA з ERC-4337 AA

• Starknet усуває додаткову складність, створену пакетувальником, і призначає секвенсор для виконання ролі пакетувальника. Це не схоже на рішення AA ERC-4337, яке вимагає від пакетувальників виконувати операції користувача (user ops).

• Порівняно з рішенням AA ERC-4337, Starknet не включає протокол абстракції комісії за транзакції, подібний до paymaster

• Starknet також не розрізняє звичайні транзакції та операції користувача, і це спрощує процес

• Одна помітна відмінність полягає в розгортанні. Starknet спочатку розгортає CA, забезпечуючи подальшу можливість виклику. По суті, Starknet вимагає, щоб акаунти з балансами токенів створювали новий центр сертифікації, викликаючи спеціалізовану функцію розгортання акаунту 'deploy_account'. Цей контракт розгорнутого акаунту може оплачувати газ. Для порівняння, рішення AA ERC-4337 не вимагає попереднього розгортання. Пакетувальник розгортає центр сертифікації, виконуючи операцію користувача з ненульовим параметром initCode. Для процесу розгортаннчя не потрібен акаунт із символічним балансом, а комісію за газ може сплатити paymaster.

zkSync

zkSync підтримує власний AA та забезпечує сумісність із віртуальною машиною Ethereum (EVM). Подібно до Starknet, zkSync спрямований на абстракцію підпису та платежу, підтримуючи різні схеми перевірки підпису для різних контрактів акаунту та різноманітні платіжні моделі та форми токенів для транзакцій.

Потік транзакцій zkSync

Потік транзакцій zkSync полягає в тому, що особа надсилає оператору підписану транзакцію, яка потім надсилається завантажувачу для перевірки. Після перевірки та отримання комісії завантажувач викликає CA для виконання транзакції.

Порівняння zkSync AA з ERC-4337 AA

• На відміну від рішення AA ERC-4337, zkSync не розрізняє акаунти, що належать зовнішнім користувачам (EOA), і CA.

• zkSync дозволяє функції validateTransaction викликати розгорнуті зовнішні контракти. Це функція, доступ до якої обмежено мережею Ethereum оскільки це може призвести до зміни стану, що спричинить проходження перевірки транзакції та збій аспекту виконання транзакції.

• Ще одна відмінність полягає в тому, що zkSync дозволяє функції validateTransaction і paymaster викликати зовнішнє сховище контрактних акаунтів (CA), які випустили цю транзакцію. Наприклад, баланс токенів CA за зовнішнім контрактом можна переглянути завдяки paymaster і функції validateTransaction. На противагу цьому, Ethereum забороняє таку функцію.

Порівняння рішень AA між мережами, сумісними з zkSync, Starknet і ERC-4337

Подібності

• Мережі, сумісні з zkSync, Starknet і ERC-4337, використовують схожі процеси AA. До них належать фаза перевірки, механізм комісії (оплачується контрактом акаунта або paymaster) і фаза виконання. Крім того, інтерфейси гаманця смарт-контрактів поділяються на функції validateTransaction і executeTransaction.

• zkSync, Starknet і ERC-4337 аналогічно обробляють DoS-атаки. Контрактній логіці zkSync дозволено торкатися лише власних слотів, а її контрактній логіці заборонено використовувати глобальні змінні. Подібним чином секвенсор Starknet вимагає локальної емуляції перед додаванням транзакцій до пулу пам’яті та їх трансляцією. Нарешті, операція користувача ERC-4337 накладає обмеження на газ для кроку validateUserOp і вимагає від paymaster внести токени.

Відмінності

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

• Що стосується споживання газу ончейн, zkSync і StarkNet є рішеннями рівня 2 для масштабування, які повинні враховувати витрати на ролап.

• Існують різні ролі щодо виконання АА. В архітектурі zkSync оператор і завантажувач (системний контракт) працюють разом для виконання операцій користувача. Для StarkNet секвенсор обробляє операції користувача без механізмів пакетувальника та paymaster. Нарешті, мережі, сумісні з ERC-4337, мають різні архітектури, що включають пакетувальники та контракти точки входу

• Інша ключова відмінність полягає в тому, чи можна надсилати транзакції до розгортання CA. І в StarkNet, і в zkSync контракт точки входу не має поля initCode, яке дозволяє розгортати CA для окремої особи. Це означає, що жоден з них не може надсилати транзакції до розгортання екаунту.

• Нарешті, є різниця у виклику зовнішніх контрактів. zkSync дозволяє функції validateTransaction викликати розгорнуті зовнішні контракти. Однак мережі, сумісні зі сиандартом ERC-4337, а також Starknet не дозволяють цього.

Різниця в paymaster

• Starknet не має інтерфейсу paymaster

• Для мереж, сумісних з ERC-4337, інтерфейс платника визначає validatePaymasterOp. Це визначає логіку paymaster для оплати транзакції. Інтерфейс також використовує функцію postOp, яка гарантує, що paymaster може отримати компенсацію плати за газ після виконання транзакції. Paymaster повинен внести Ethereum на акаунт контракту в точці входу в якості оплати за газ і зобов’язує Ethereum на контракті в точці входу запобігти створенню ботами шкідливих пакетів.

• zkSync подібний до мереж, сумісних зі стандартом ERC-4337, у якому інтерфейс визначає функції validatePaymasterOp і postOp. Визначення подібні до стандарту ERC-4337, але ця частина функції ще не реалізована. На відміну від paymaster стандарту ERC-4337, paymaster zkSync не почне виконання, доки не викличе postTransaction, коли буде достатньо газу. З іншого боку, paymaster ERC-4337 не викличе postOp, якщо validatePaymasterUserOp не повертає контекст.

Порівняльна таблиця

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

Підсумок

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

Мультичейн абстракція акаунтів (АА) викликала у вас інтерес до вивчення простору Web3 разом з нами? Дізнайтеся, як OKX інтегрує AA у наш мультичейн гаманець.