Співпраця між Base та Ethereum Account Abstraction провалюється, розробники розходяться шляхами

iconThe Defiant
Поділитися
AI summary iconКороткий зміст
Цього тижня з’явилися новини про ethereum, коли Base і ethereum розійшлися у питанні абстракції акаунтів. За словами Дерека Чжана з Ethlabs, зусилля щодо згідження EIP-8130 Base з EIP-8141 ethereum провалилося минулого тижня. Обидві команди зараз працюють над окремими стандартами. Цей розкол може ускладнити розробку для гаманців і додатків. Новини екосистеми ethereum підкреслюють зростаючу фрагментацію правил перевірки транзакцій між ланцюгами. Розробникам доведеться працювати з несумісними форматами у майбутньому.

Етхлабс’ Derek Chiang, засновник ZeroDev, сказав, що співпраця щодо згідження Base-ланцюгового EIP-8130 з Ethereum-ланцюговим EIP-8141 Frame Transactions завершилася минулого тижня, залишивши обидві сторони з різними власними стандартами абстракції акаунтів.

Офіційний реєстр пропозицій щодо покращення ethereum перелічує EIP-8130 та EIP-8141 як проекти. Ethlabs підтримує Frame Transactions для Hegotá, який вона описує як майбутній ethereum форк, і заявляє про намір працювати з Layer 2 та гаманцями під час запуску.

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

Як відрізняються дизайни

Абстрагування акаунтів дозволяє контрактним акаунтам визначати власну логіку перевірки, а не полагоджуватися лише на фіксовані правила для зовнішньо власних акаунтів. Остаточний ERC-4337 standard забезпечує абстрагування акаунтів без зміни правил консенсусу Ethereum: користувачі надсилають об’єкти `UserOperation` до окремого mempool, а бандлери упаковують їх у транзакції для контракту EntryPoint.

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

EIP-8130 поєднує новий тип транзакції з ончейн-хранилищем ключів та системою конфігурації акаунтів. Він підтримує користувацьку аутентифікацію, пакетні виклики та спонсорування газу. Оскільки кожна транзакція вказує свій аутентифікатор, ноди можуть визначити необхідний обсяг роботи з перевірки та відхилити невідомі аутентифікатори до виконання довільного коду гаманця.

Проект 8130 визначає профіль L1 з дозвільним прийняттям аутентифікаторів та профіль L2, який обмежує його нативний шлях транзакцій до канонічного набору аутентифікаторів. Така структура призначена для забезпечення передбачуваних витрат на валідацію для ланцюгів з високою пропускною здатністю при збереженні загальної базової основи для гаманців.

EIP-8141 замість цього розбиває транзакцію на послідовність «фреймів» або викликів контрактів, які перевіряють транзакцію, схвалюють оплату газу та виконують користувацькі операції. Його дизайн дозволяє акаунтам використовувати EVM-код для визначення правил перевірки та оплати газу, підтримуючи функції, такі як зміна ключів, пакетні виклики та альтернативні способи оплати комісій.

Ethlabs описав центральний компроміс: дозвільна, EVM-на основі валидація надає Frame Transactions гнучкість для конфіденційності та майбутніх систем підписів, але динамічні витрати на валидацію можуть створювати виклики для високопродуктивних Layer 2. EIP-8130 надає перевагу більш передбачуваній валидації, роблячи аутентифікатор явним до виконання.

Переносимість рухається вище по стеку

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

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

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

Відмова від відповідальності: Інформація на цій сторінці може бути отримана від третіх осіб і не обов'язково відображає погляди або думки KuCoin. Цей контент надається лише для загального інформування, без будь-яких запевнень або гарантій, а також не може розглядатися як фінансова або інвестиційна порада. KuCoin не несе відповідальності за будь-які помилки або упущення, а також за будь-які результати, отримані в результаті використання цієї інформації. Інвестиції в цифрові активи можуть бути ризикованими. Будь ласка, ретельно оцініть ризики продукту та свою толерантність до ризику, виходячи з ваших власних фінансових обставин. Для отримання додаткової інформації, будь ласка, зверніться до наших Умов використання та Розкриття інформації про ризики.