EIP-3074

Кращий, безпечніший користувацький досвід

EIP-3074 дозволяє ЕОА делегувати контроль за вказаними контрактами, тим самим отримуючи розширені можливості виконання, схожі на контракти. До EIP-3074 ЕОА могло виконувати лише одну операцію на транзакцію, таку як схвалення токена ERC20 або здійснення обміну на Uniswap. Після EIP-3074 ЕОА може завершити кілька операцій у одній транзакції, що дозволяє раніше неможливі використання. У суті, EIP-3074 значно покращує користувацький досвід та перетворює звичайні методи авторизації, підвищуючи безпеку.

Крім того, завдяки EIP-3074 ЕОА вже не потрібно відправляти транзакції на ланцюжку самостійно, тим самим усуваючи потребу спочатку отримати ETH для оплати комісій за транзакції.

Контракти Invoker

Контракти, які можуть отримати контроль над ЕОА, називаються контрактами Invoker. Не будь-який контракт може отримати контроль; ЕОА повинен підписати його за допомогою свого приватного ключа, вказавши, який контракт Invoker та які операції він авторизує Invoker виконувати.

Зазвичай процес включає в себе:

Alice підписує своїм приватним ключем EOA, вказуючи контракт Invoker та авторизовані операції.

Еліс подає підписаний вміст та підпис до Релеєра.

Relayer подає транзакцію on-chain до контракту Invoker.

Інвокер перевіряє підпис і, після підтвердження, виконує операції як EOA Еліс, такі як схвалення USDC, обмін активами на Uniswap та використання деяких USDC для оплати ретранслятора як комісії.

Примітка: Релеєр є необов'язковим; Аліса може самостійно надіслати підписаний вміст та підпис на ланцюжок.

Уникнення повторних атак

Ініціатор виконує операції так, ніби він має обмежену контроль над EOA Еліс. Проте номер EOA не збільшується після виконання, що означає, що та сама підпис може бути потенційно використаний знову, поки номер EOA залишається незмінним. Тому Ініціатор повинен реалізувати свій власний механізм номера, щоб запобігти атакам повторного відтворення.

Дізнатися більше

Для детального опису роботи EIP-3074 дивіться:https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

Застосування EIP-3074

Пакетний виклик

Batchcall дозволяє користувачам об'єднувати кілька операцій в одну, що зберігає процес множинних авторизаційних підписів та деякі витрати на газ. Зверніть увагу, що для цього потрібна підтримка функціональності Batchcall від DApps, як от поки що пропагований EIP-5792. Без такої підтримки DApps будуть пропонувати окрему операцію для кожної операції, розглядаючи користувача як звичайний EOA.

Для отримання додаткової інформації щодо EIP-5792, будь ласка, звертайтеся до: EIP-5792.

Ключ сесії

Користувачі можуть делегувати операції третій стороні за певних умов, використовуючи сеансовий ключ. У наведеному нижче прикладі ключ делегата представляє уповноважену третю сторону, тоді як політика доступу визначає операційні обмеження, такі як обмеження дій на Uniswap, обмеження трансферів до 1 ETH на день або встановлення терміну дії авторизації. Ці умови розроблені та перевірені в межах контракту Invoker. Після проходження перевірок третя сторона може виконувати операції як EOA користувача.

Наприклад, Telegram Bot може бути наданий конкретні дозволи для виконання операцій від імені користувача EOA.

Місцевий дозвіл ETH

Якщо умови виконані (тобто підпис дозволу є дійсним), операції можуть бути виконані як авторизована EOA, що дозволяє використовувати функціональність місцевого дозволу ETH.

Лімітний ордер

Користувачі можуть встановлювати умови лімітних замовлень, які, коли вони виконані, дозволяють виконувати операції в якості EOA користувача. Це включає затвердження відповідних цифрових активів для DEX та обмін активами на DEX. Порівняно з функціональністю лімітних замовлень, яку надають самі DEX, користувачам не потрібно попередньо затверджувати активи для DEX.

Наприклад, коли Еліс завершує лімітний ордер, схвалення виконується одночасно, усуваючи потребу у попередньому схваленні.

Проектуючи умови більш загально, можна створити контракт наміру: якщо виконані вказані умови, будь-хто може виконати намір від імені користувача EOA.

Соціальне відновлення

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

Покращення методів авторизації активів

EIP-3074 має потенціал покращити або навіть замінити поточні методи схвалення/дозволу. DApps в даний час працюють в умові, що користувачі є EOAs: користувачі повинні передчасно схвалити достатню кількість активів у контракт DApp, щоб уникнути постійного перебування в мережі та повторного схвалення транзакцій. Це значно покращує досвід користувача.

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

Проте це вимагає від користувачів довіри до DApp або уникання схвалення фальшивих DApp, і вони повинні мати можливість видаляти схвалення в реальному часі.

Недавні моделі дозволів, такі як EIP-2612 або неіноземний Permit2, спрямовані на поліпшення досвіду користувача та безпеки у моделі затвердження. Користувачам не потрібно схвалювати великі суми активів для кожного контракту DApp; замість цього вони можуть авторизувати DApps на зняття певної суми активів протягом вказаного часу, підписавши один раз. Це значно зменшує площу атаки та підвищує досвід користувача.

△ Користувачам потрібно лише підписати оффчейн, і вони можуть вказати суму активу та строк дії, що забезпечує кращий досвід користувача та безпеку, ніж затвердження.

Однак, насправді, не лише схвалювати, режим дозволу часто використовується як шахрайський метод. Жертви помилково підписують дозволи, які, на їхню думку, призначені для використання DApp, а насправді надають дозвіл зловмисникам.

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

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

Дізнатися більше:

Щоб дізнатися більше про випадки, коли режим дозволу використовувався як шахрайський метод, скопіюйте наступні посилання у ваш браузер для отримання додаткової інформації:

• Посилання 1

• Посилання 2

• Посилання 3

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

Замість цього користувачі пов'язують операцію DApp з дією схвалення, виконуючи їх атомарно через Invoker: або обидві дії схвалення та операції DApp вдаються разом, або зазнають невдачі разом. Немає можливості, що дія схвалення вдається самостійно, тому користувачі можуть бути впевнені, що ця дія схвалення специфічно для поточної операції.

Крім того, користувачі надають дозвіл на використання оффчейн підписів, тому користувацький досвід такий же, як з дозволом! Це означає, що DApps більше не потребуватимуть режиму дозволу! У майбутньому гаманці можуть безпосередньо блокувати або суворіше перевіряти запити на підпис дозволу без страху перешкоджати користувачам у доступі до певних DApps (а скоріше бути використаним шахраями).

△ Користувачі більше не будуть лише авторизовувати певну адресу, але також вказуватимуть, які дії можна виконати, і навіть можуть бачити симульовані результати виконання.

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

Як Гаманці Обробляють Номери EOA

Наразі дизайн EIP-3074 включає значення EOA nonce в вміст підпису. Тому, як тільки EOA подає транзакцію on-chain, яка змінює значення nonce, всі існуючі авторизації EIP-3074 стають недійсними.

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

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

Примітка:Сам контракт Invoker повинен мати окремий механізм nonce, тому кожен підпис повинен бути оновлений незалежно від змін у nonce EOA.

Ключ сеансу та соціальне відновлення ймовірно будуть широко використовуватися лише після того, як EIP-3074 змінить правила, щоб видалити EOA nonce з вмісту підпису. Тому гаманці повинні зосередитися на сценарії, де «користувачі авторизують себе на роботу» та обробляти підписи EIP-3074 так, як вони робили б транзакції, уникнення стурбовань щодо того, що транзакції EOA змінюють nonce.

Однак, якщо користувачі хочуть надіслати свій підпис EIP-3074 на ланцюжок самостійно, є дві недоліки:

1. Користувачам потрібно підписати двічі: один раз для підпису EIP-3074 і один раз для підпису транзакції в ланцюжку.

2. Оскільки онлайн-транзакція збільшить EOA nonce перед виконанням, EOA nonce підпису EIP-3074 повинен бути попередньо збільшений, щоб відповідати зміні nonce, спричиненій онлайн-транзакцією.

△ Оскільки онлайн-транзакція збільшує EOA nonce, перевірка підпису EIP-3074 не вдасться, якщо nonce не відповідає.

△ Користувачам потрібно передбачити попереднє інкрементування EOA nonce в підписі EIP-3074 для успішної перевірки.

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

Огляд та основні моменти

• EIP-3074 надає ЕОА (Зовнішні Облікові записи) ті ж багаті можливості виконання, що і контракти, розблоковуючи численні нові сценарії застосування.
• Це не лише значно покращує користувацький досвід, але й трансформує поточні методи авторизації, зробивши їх безпечнішими, не жертвуючи зручністю.
• Крім того, EIP-3074 передбачає прості підписи, тому користувачам не обов'язково виконувати ці підписи на ланцюжку самостійно, що усуває потребу у зборі ETH для оплати комісій за транзакції.
• Використання EIP-3074 включає в себе пакетний виклик, ключ сесії, дозвіл на природний ETH, лімітоване замовлення та соціальне відновлення. Багато з них спочатку неможливо досягнути з EOA, а деякі, наприклад, лімітоване замовлення, потребують попередньої авторизації та інших менш безпечних методів.
• Раніше це було неможливо для ЕОА. Наприклад, використання Лімітного ордера вимагало менш безпечних методів, таких як попередня авторизація.
• EIP-3074 також змінить поточні методи авторизації. Метод approve безпосередньо авторизує вказану адресу на необмежене вилучення цифрових активів назавжди, вимагаючи від EOA користувача відправити транзакцію для виконання схвалення, що призводить до поганого досвіду користувача та безпеки. Метод permit вимагає лише підпис користувача, причому кожен підпис вказує суму активів та термін дії, що значно покращує досвід користувача та безпеку порівняно з методом approve.
• Однак метод дозволу все ще часто використовується в шахрайствах. Під час підписання користувачі можуть бачити лише адресу, кількість активів та строк дії, які вони авторизують, але не мету авторизації. Мета визначалася б у іншому підписі (або транзакції). Легітимний DApp потребував би від користувача підписати як дозвіл, так і мету, але це два окремі підписи. Тому, коли запрошують підписати дозвіл, користувачі та гаманці не можуть визначити призначення дозволу.
• За EIP-3074 користувачам (1) не потрібно передчасно схвалювати велику кількість активів до DApp, а лише схвалювати під час операції, і ефект такий самий, як у permit; (2) просто підписуйте, і не потрібно перейматися збором ETH для оплати процедури. Оплата така ж, як у permit; (3) Кожен approve пов'язаний з певною операцією і підписаний разом. Користувач може чітко знати, "для чого використовується approve" цього разу. Це буде безпечніше, ніж permit!
• Сподіваються, що EIP-3074 успішно замінить поточні методи затвердження та дозволу, забезпечуючи користувачів більш безпечним методом авторизації.

Disclaimer：

1. Ця стаття перепечатана з [ imToken Labs]. Усі авторські права належать оригінальному автору [Nic]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Навчаннякоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, хто їх висловлює, і не становлять жодних інвестиційних порад.
3. Переклад статті на інші мови здійснюється командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.