Нещодавно Віталік Бутерін запропонував EIP-7702, який може бути однією з найбільш впливових змін в історії Ethereum. Ця стаття розкриє суть цього нового пропозиції та все, що потрібно знати для її впровадження.

По-перше, пропозиція EIP-7702 дивно коротка, що залишило деяких людей в розпачі щодо її функціонування. Щоб зрозуміти EIP-7702, нам потрібно розглянути три інші зазначені в ньому пропозиції:

1. EIP-4337

2. EIP-3074

3. EIP-5003

Давайте почнемо зі спільної мети цих пропозицій: «абстракція облікового запису». На Ethereum у ЕОА («звичайних» облікових записів) є серйозні недоліки — вони дуже ризиковані та мають дуже обмежену функціональність. Абстракція облікового запису дозволяє користувачам використовувати смарт-контракти як облікові записи, що додає більше функціональності та безпеки для вирішення цих проблем.

EIP-4337

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

З моменту його випуску EIP-4337 отримав широке поширення, переважно під керівництвом Polygon, зі збільшенням активності від Base в останні місяці.

Останні інновації, пов'язані з EIP-4337, походять від екосистеми Coinbase та розумного гаманця Coinbase. Цей гаманець базується на біометричній технології, що забезпечує відмінний користувацький досвід. Минулого вікенду я створив ще одну невелику демонстраційну версію на ETH Global Sydney, щоб показати це.

Так, які проблеми у EIP-4337? Чому сьогодні знову є пропозиція щодо абстракції облікового запису? Тому що EOAs залишаються найбільш поширеним типом облікового запису наразі.

Додатково, більшість рахунків розумного контракту EIP-4337 контролюються одним єдиним підписником EOA. Ось приклад фрагмента коду:

Тому, що неможливо «конвертувати» EOA користувача в обліковий запис смарт-контракту, існує це дивне тимчасове рішення. Це головним чином через відсутність вбудованої підтримки в додатках Web3 для підключення облікових записів смарт-контрактів. В наш час більшість людей все ще використовують EOA через розширення гаманців, таких як MetaMask.

EIP-3074

Це приводить нас до нашого наступного пропозиції: EIP-3074.

Фактично ця пропозиція була введена раніше, ніж EIP-4337, але вона ще не була об'єднана в основну мережу. EIP-3074 намагається надати повноваження ЕОА, дозволяючи їм делегувати контроль над своїми ЕОА умовним контрактам.

Пропозиція передбачає додавання двох нових опкодів:

1. АВТ: ЗЕА може викликати AUTH, щоб авторизувати вказаний смарт-контракт діяти від її імені.
2. AUTHCALL: Авторизований розумний контракт може використовувати AUTHCALL для виконання транзакцій від імені EOA.

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

Часта реакція на EIP-3074 полягає в тому, що «Що, якщо хтось створить зловмисний контракт і користувач делегує йому права?» В кінці кінців, делегування прав до зловмисного контракту може призвести до витоку всіх криптовалютних активів у гаманці користувача.

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

Важливою точкою щодо делегування в EIP-3074 є те, що воно не є постійним. «Делегування від EOA анулюється однією угодою, яка збільшує внутрішній номер, що призводить до скасування будь-яких невиконаних авторизацій.»

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

EIP-5003

Ми дійсно не хочемо надавати більше влади ЕОА. В кінці кінців, метою цих пропозицій є перехід користувачів з ЕОА на облікові записи у розумних контрактах. Тому чому додавати функціонал до ЕОА?

Це гарно переходить до нашого наступного пропозиція: EIP-5003. EIP-5003 вводить ще один опкод, «AUTHUSURP», який розгортає код на адресу авторизації EIP-3074.

Різниця між EIP-3074 та EIP-5003 полягає в тому, що:

EIP-3074 - це тимчасове делегування умовним контрактам, яке можна скасувати.

EIP-5003 - це постійна міграція з EOAs та «конвертація» з EOAs на облікові записи розумних контрактів.

Однією з основних проблем EIP-3074 + EIP-5003 є її несумісність з поточною схемою абстракції рахунків через EIP-4337. Деякі у громаді Ethereum висловлюють обурення тим, що ми можемо «створити дві окремі екосистеми коду» з цими двома типами абстракції рахунків.

EIP-7702

Це приводить нас до пропозиції Віталіка Бутеріна сьогодні: EIP-7702. Він пропонує змінити EIP-3074, щоб зробити його більш лаконічним і сумісним з EIP-4337, щоб ми не потрапили у дві окремі екосистеми абстракції рахунків. EIP-5003 потім розглядається як наступний крок для постійної міграції.

EIP-7702 вводить новий тип транзакції, який приймає як поля contract_code, так і підпис. Під час виконання транзакції він встановлює код контракту облікового запису підписника на contract_code. В кінці транзакції він скидає код на порожній.

Схоже з EIP-3074, це досягає тимчасового делегування ЕОА до смарт-контрактів. Однак EIP-7702 не вводить нових опкодів (що потребувало б хардфорку), а замість цього визначає функції, які мають бути викликані:

AUTH -> виклики "перевірка"

AUTHCALL -> викликає «виконати»

Конкретно, це:

Перевіряє, чи код контракту вашого облікового запису порожній.

Якщо воно порожнє, встановлює його на наданому контрактному коді.

Виконує транзакцію відповідно до того, як наданий смарт-контракт обробляє транзакції.

Відновлює код контракту облікового запису на порожній.

«Код контракту» буквальний; це місце, де зберігається код смарт-контракту. Оскільки EOA сам по собі не є контрактом, це поле зазвичай залишається порожнім. Однак геній EIP-7702 полягає в тимчасовому заповненні цього поля певним кодом смарт-контракту під час виконання транзакції.

Це спосіб надати нову поведінку (у вигляді коду) вашому EOA для виконання цієї конкретної транзакції. Наступним кроком є зробити це постійною зміною поведінки, просто вибравши «не встановлювати код у порожній після завершення транзакції».

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

Як тільки ця зміна вступить в силу, існуючі облікові записи зможуть виконувати будь-який код розумного контракту. За допомогою додаткових EIP облікові записи також можуть бути постійно оновлені для виконання конкретного коду.

З часом це може фундаментально змінити спосіб, яким ми всі взаємодіємо з додатками Web3.

Заява:

1. Ця стаття взята з [ panews], оригінальний заголовок «Дослідження пропозиції EIP-7702: остаточний рецепт Віталіка для проблеми абстракції облікового запису?», авторське право належить оригінальному автору [Foresight News], якщо у вас є які-небудь заперечення щодо перепублікації, будь ласка, зв'яжітьсяGate Learn Team, команда обробить це якнайшвидше відповідно до відповідних процедур.

2. Попередження: Погляди та думки, висловлені в цій статті, відображають лише особисті погляди автора й не становлять жодних інвестиційних порад.

3. Інші мовні версії статті перекладені командою Gate Learn, не згадано в Gate.io, перекладений матеріал не може бути відтворений, поширений або плагіатований.