Автор: Васа, співзасновник OpenSea Pro; Переклад: Золотий фінанс Сяоцзу
У цій статті ми коротко розглянемо різні EIP, які привели нас до сьогоднішніх абстракцій облікового запису.
! [IBi1wWpT0680RWZaqv5DB56VCs7bGvDrkaHl3Wky.png] (https://img.jinse.cn/7122936_watermarknone.png «7122936»)
**1. Навіщо потрібна абстракція облікового запису (АА)? **
Люди люблять ставити запитання на кшталт: «Як залучити наступний мільярд користувачів до Web3?». «Є багато перешкод, які потрібно подолати, але найважливіша з них – це користувацький досвід.
Наведена нижче схема є типовою взаємодією для нового користувача. Також зверніть увагу, що якщо ви втратите свою seed-фразу, немає можливості повернути власні кошти. Це величезна перешкода для нових користувачів.
! [vvFxw94g95EIvo2NuFwxQX9g5mTtJo2EvxwLJO2y.png] (https://img.jinse.cn/7122937_watermarknone.png «7122937»)
Ось кілька речей, які ми можемо зробити, щоб покращити взаємодію з користувачем. Ми можемо:
Створюйте гаманці без мнемонічних фраз.
Використовуйте гаманець, який не вимагає зберігання ETH та сплати комісії gas за допомогою ETH.
Використовуйте Social Recovery, щоб повернути свій гаманець.
Масові операції в одній угоді.
! [dE8KCPMN0cVxJwYU2lm5yt5B9g3GLhSxilFQWvfW.png] (https://img.jinse.cn/7122938_watermarknone.png «7122938»)
2、Тип абстрактного облікового запису
Існує два типи рахунків: зовнішні облікові записи (EOA) і контрактні рахунки. EOA контролюється приватним ключем, а контрактний рахунок контролюється кодом контракту.
! [64lX5U5G6sNJZBjPvNiC827QJil9Zi8BpTNMeQ8Y.png] (https://img.jinse.cn/7122939_watermarknone.png «7122939»)
EOA можуть ініціювати транзакції з іншими EOA або контрактними рахунками, які потім можуть виконувати їхній код. Контрактні акаунти також можуть надсилати угоди на інші контрактні акаунти, які можуть виконувати свій власний код.
Коли транзакція надсилається в мережу, вона проходить два етапи: перевірку та виконання. У той час як виконання логіки транзакції може бути довільним, валідаційна частина фіксована.
Верифікаційна частина виконується за єдиним фіксованим алгоритмом, який має використовувати EOA, тобто перевіркою підпису ECDSA. Але чому ми використовуємо фіксований метод перевірки дійсності транзакцій? Що робити, якщо перевірка сигнатур ECDSA більше не буде надійною в майбутньому через квантові обчислення?
Якщо залишити відкритою валідаційну частину, то можна створити транзакцію з дуже складним алгоритмом валідації, тоді майнеру/валідатору доведеться витратити багато ресурсів, щоб перевірити, чи можна включити транзакцію в блок.
Тепер зверніть увагу, що майнерам платять лише за виконання та включення транзакцій, а не за верифікацію. Отже, якщо, витративши багато ресурсів, майнери виявляють, що не можуть додавати транзакції, то вони витрачають ресурси даремно і нічого за це не отримують. Тому це можна використовувати для здійснення DDoS-атак на мережу. Ось чому Ethereum почав з фіксованого алгоритму верифікації.
Гаманець з мультипідписом – це контракт з великою кількістю власників з пороговими значеннями. Якщо ви хочете надіслати транзакцію, ви повинні отримати підписи від усіх власників, перш ніж ви зможете надіслати транзакцію.
Це підтримує такі функції, як соціальне відновлення, де ви можете мати багато друзів, які допоможуть вам відновити ваш гаманець, якщо ви втратите свої приватні ключі. З перших днів існування Ethereum цінність, яку можуть надати гаманці з мультипідписом, була очевидною. Тому команда розробників Ethereum на той час хотіла, щоб користувачі Ethereum використовували гаманці з мультипідписом. Однак цього не сталося.
Оскільки команда розробників Ethereum передбачала, що користувачі будуть використовувати гаманці з мультипідписом, вони не додали автоматичний журнал переказів ETH, оскільки очікували, що гаманець з мультипідписом буде записувати кожен переказ ETH. Біржі в той час повинні були аналізувати транзакції переказу ETH, а не реєструвати їх.
Коли хтось намагається використовувати гаманець з мультипідписом із журналами переказів ETH, біржу неможливо впізнати, оскільки біржа не аналізує журнали. Таким чином, це невелике припущення в кінцевому підсумку ускладнює прийняття гаманців з мультипідписом.
EIP 86 і 1014: Абстракція облікового запису**
EIP-86 має на меті представити концепцію гаманця смарт-контрактів під назвою «пересилання контрактів». Ці контракти призначені для отримання транзакцій лише з адрес «точки входу», які повинні дотримуватися певного формату.
Тепер, щоб створити гаманець смарт-контракту, вам потрібно заздалегідь мати трохи ETH для сплати комісії gas. Ви можете зайти на CEX і отримати трохи ETH, але оскільки ваш гаманець смарт-контракту ще не створений, ви ще не можете надсилати ETH на гаманець.
Якщо ми якимось чином можемо точно знати адресу контракту до створення смарт-контракту, ми можемо відправити ETH на цю адресу, а потім створити гаманець смарт-контракту, використовуючи ETH на цій адресі.
Це те, що представляє EIP-1014. Він вводить CREATE2 коди операцій, які дозволяють визначити адресу контракту перед створенням смарт-контракту. Це перший крок до абстракції облікового запису.
Оригінальний EIP-86 вимагав значних змін у протоколі, оскільки зміни в протоколі вимагали співпраці між командами розробників вузлів і вимагали ретельного вивчення, тому він так і не був реалізований. EIP-1014 був реалізований в хардфорку Константинополя.
Розвиток спільноти: Gnosis Safe, Argent Wallet, мережа АЗС**
Обговорюючи дослідження ЕІП, спільнота вже взялася за розробку власних рішень.
Найпомітнішим з них став реліз Gnosis Safe у 2018 році. Safe — це гаманець смарт-контрактів, який дозволяє користувачам створювати гаманці з мультипідписом, а також дозволяє користувачам об’єднувати кілька операцій в одну транзакцію. Це також дозволяє користувачам сплачувати комісію за газ за допомогою токенів ERC20.
Ще одним примітним моментом є випуск гаманця Argent у 2019 році. Argent Smart Wallet підтримує користувачів у створенні гаманців з мультипідписом, а також дозволяє користувачам сплачувати комісію gas за допомогою токенів ERC20. Це також дозволяє користувачам використовувати соціальне відновлення, щоб отримати свої гаманці.
Мережа АЗС (GSN), випущена в 2019 році, є децентралізованою мережею, яка дозволяє користувачам сплачувати комісію за газ за допомогою токенів ERC20. GSN можна використовувати з будь-яким гаманцем смарт-контрактів.
EIP 2938 – гігантський стрибок вперед
Починаючи з 2018 року, команда Ethereum звернула свою увагу на перехід на PoS (proof-of-stake), що ненавмисно призвело до зменшення уваги до оцінки та впровадження EIP дослідницькими групами та командами розробників вузлів.
Ця зміна проклала шлях для EIP-2938 у 2020 році, через два роки після впровадження EIP-1014.
Основною ідеєю пропозиції є впровадження гаманців смарт-контрактів, які призначені спеціально для отримання конкретних типів транзакцій, які можна запрограмувати на визначення газового ліміту транзакцій і розробку довільних методів перевірки.
Пропозиція вводить два нові коди операцій для обробки транзакцій, і, як зазначалося раніше, включення цих основних оновлень є складним процесом.
Крім того, є відкриті питання про те, як реалізований захист від повторного відтворення і як вузли можуть перевірити дійсність цих нових типів транзакцій. Хоча пропозиція не привернула особливої уваги, вона проклала шлях для наступної пропозиції (EIP-3074).
EIP-3074 – дуже універсальне рішення**
Пропозиція вводить два нові коди операцій: AUTH і AUTHCALL. Різниця з цією пропозицією полягає в тому, що вона підтримує зовнішні облікові записи (EOA) для делегування контролю контрактам. Ці коди операцій вказуються для контрактів “invoker”, які мають потенціал для значного розширення функціональності будь-якого EOA.
Контракт ініціює повністю довільну структуру транзакцій, що дозволяє легко впроваджувати такі рішення, як мультипідпис, пакетні закупівлі та закупівлі допомоги, відновлення ключів і більш дружні депозити CeFi. Завдяки своєму відкритому характеру пропозиція стала дуже універсальним рішенням, здатним задовольнити широкий спектр сценаріїв використання.
З іншого боку, нейтральна позиція пропозиції також створює певні безпекові виклики. Подальша дискусія пропонує більш продуманий підхід AUTHCALL для пом’якшення пов’язаних з цим ризиків. Ця дискусія привела дослідників до більш оптимізованого рішення, в результаті чого з’явився EIP-4337.
EIP-4337 – абстракція облікового запису Ethereum без зміни протоколу рівня консенсусу**
! [HQ5SxXOpxJLs0tzXo1IgTdGxAe5XHPNAIJiDKUMM.png] (https://img.jinse.cn/7122940_watermarknone.png “7122940”)
EIP-4337 пропонує механізм для перенесення абстракції облікового запису в Ethereum без зміни протоколу рівня консенсусу. Відповідно до цього EIP, користувачі по-різному взаємодіють із мережею Ethereum; Замість того, щоб відправляти транзакції, користувач відправляє об’єкт UserOperation в окремий пул пам’яті. Відправник – це контракт облікового запису, який ініціює дію користувача. Бандлер збирає ці операції та упаковує їх у транзакцію, яка запускає виклик handleOps на вказаному контракті EntryPoint для виконання упакованої операції. Paymaster є організацією, яка спонсорує транзакцію, і її реквізити включені в UserOperation для обробки комісії.
Агрегатор перевіряє агреговані підписи, підвищуючи безпеку та ефективність. Бандлер або клієнтський білий список підтримує точки входу та контракти агрегатора, контролює взаємодію та забезпечує належне виконання дій користувача в мережі Ethereum, що відповідає цілям абстракції облікового запису без зміни рівня консенсусу.
Гаманці смарт-контрактів, розгорнуті за допомогою цього процесу, автономно керують випадковими значеннями та перевіркою підпису, забезпечуючи широку гнучкість. Цей дизайн допомагає створювати гаманці смарт-контрактів, які можуть обробляти мультипідписні та пакетні транзакції, соціальне відновлення та навіть сплачувати комісії за допомогою токенів ERC20.
Певна форма абстракції облікового запису, подібна до тієї, що запропонована в EIP-4337, може бути реалізована в середньостроковому майбутньому Ethereum, спочатку з’являючись у нових рішеннях L2 і зрештою увійшовши в Ethereum L1, таким чином розширюючи сферу взаємодії користувача з Ethereum.
10、L2 - Нові рубежі
Оновлення основного протоколу є серйозною перешкодою при запровадженні будь-якого EIP, пов’язаного з абстракцією облікового запису. Розробники ядра були зайняті дорожньою картою ETH 2.0, яка довгий час була головним пріоритетом.
А як щодо L2? На відміну від Ethereum L1, який несе технічний борг, останні ланцюжки L2 мають архітектуру, яка з самого початку інтегрує абстракції облікових записів.
Наприклад, StarkNet – це ZK-ролап, який створює унікальну абстракцію облікового запису. Крім того, Argent, відомий своїм гаманцем смарт-контрактів L1, запустив ArgentX на StarkNet, вбудувавши реалізацію абстракції облікового запису, на яку сильно вплинув EIP-4337. Ці ініціативи підкреслюють важливість і застосовність абстракції облікового запису в блокчейні Ethereum.