EIP-3074

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

EIP-3074 дозволяє EOA (Outternally Owned Accounts) передавати контроль за певним контрактом, тим самим отримуючи такі ж багаті можливості виконання, як і контракт. До EIP-3074 EOA міг виконувати лише одну операцію за транзакцію, наприклад, затверджувати ERC20 або своп на Uniswap. Після EIP-3074 EOA може виконувати кілька операцій одночасно або навіть виконувати раніше немислимі завдання. Простіше кажучи, EIP-3074 значно покращує користувацький досвід, а звичний метод авторизації токенів буде змінено, підвищуючи безпеку без зміни користувацького досвіду.

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

Контракт Invoker Контракт

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

Зміст підпису EOA чітко визначає, який контракт Invoker (адреса виклику) і дозволяє операції цього контракту Invoker (коміт)

Фактичний процес виконання, ймовірно, виглядатиме так:

1. Аліса підписує підпис своїм закритим ключем EOA, а потім передає зміст підпису та підпис Relayer
2. Relayer переводить ланцюжок до виконання контракту Invoker
3. Invoker перевіряє підпис. Пройшовши верифікацію, він може виконувати операції як EOA, наприклад, схвалювати USDC, потім переходити на Uniswap до біржа і, нарешті, передавати частину USDC Relayer як плату за обробку.

Примітка 1: Повторне шарування не потрібне. Аліса також може принести в ланцюжок свій фірмовий контент і печатку.

Після того, як Invoker перевірить підпис і почне виконувати операцію, він буде виконаний як Alice EOA, що схоже на отримання (обмеженого) контролю над EOA.

Однак, слід зазначити, що значення nonce EOA не буде збільшено після виконання, тому один і той же підпис може бути використаний повторно (лонг також nonce EOA залишається незмінним), тому Invoker повинен впровадити власний механізм nonce, щоб уникнути повторного відтворення.

Якщо контракт Invoker не захищений від повторного відтворення, один і той самий дозвіл може виконуватися весь час.

Для ознайомлення з фактичним механізмом роботи EIP-3074, будь ласка, зверніться до: Вступ до EIP3074

Application

Batchcall

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

Примітка: Для цього потрібно, щоб dApp також підтримка функцію Batchcall, наприклад EIP-5792, яку зараз просуває спільнота. В іншому випадку dApp запропонує користувачеві підписатися лише один раз для кожної операції, якщо він розглядає користувача як звичайний EOA.

Ключ сеансу

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

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

Native ETH Permit

лонг Оскільки умови виконані (тобто підпис Дозволу є законним), передача ETH може бути здійснена як EOA авторизатора, досягаючи ефекту рідного дозволу ETH

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

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

Коли Аліса завершує ордер, вона одночасно виконує схвалення, усуваючи необхідність попереднього схвалення.

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

Якщо лонг виконується умова Наміру, будь-хто може ініціювати виконання від імені EOA користувача

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

Коли користувач втрачає приватний ключ EOA, він (Аліса) може використовувати підписаний нею дозвіл EIP-3074 разом із підписами своєї уповноваженої особи (чоловіка та довірчого агента) для передачі всіх активів EOA. Насправді те, що повертається, є активами, які можна передавати, а не рахунок контролем. Після втрати закритого ключа EOA його не можна лонгуючий використовувати.

Коли користувач втрачає закритий ключ EOA, інші уповноважені особи можуть підписати та санкціонувати передачу активів EOA.

Вплив EIP-3074

Покращення методів авторизації токенів та потенційна заміна схвалення/дозволу?

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

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

Але також необхідно довіряти dApp або уникати схвалення підробленого dApp, а також мати можливість негайно видалити схвалення

Режими дозволів, які з'явилися пізніше, такі як нативний токен EIP-2612 або нерідний Permit2, призначені для покращення досвіду використання та безпеки режиму схвалення: користувачам не лонгуючий потрібно схвалювати велику суму грошей на кожен контракт dApp (і кожен токен має бути схвалений один раз). Замість цього користувачеві потрібно лише «підписати ім'я», щоб уповноважити контракт dApp «вивести зазначену суму» протягом «зазначеного часу». Це не тільки значно зменшує поверхню атаки, але й значно покращує користувацький досвід.

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

Але насправді, режим дозволу не тільки схвалюють, але й часто використовують як метод шахрайської атаки (1,2,3): жертви помилково підписували те, що вони вважали дозволом на dApp, але насправді було надано зловмиснику.

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

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

Однак EIP-3074 приносить можливість для змін: коли розробники dApp знають, що EOA може виконувати різні складні операції через Invoker, дизайн взаємодії з dApp лонгуючий не повинен жертвувати безпекою в ордер для покращення користувацького досвіду, наприклад, «користувачі попередньо схвалюють велику суму грошей» і «користувачі підписують повідомлення про дозвіл, щоб авторизувати виведення коштів». Замість цього користувачі пов'язують операції dApp для затвердження та виконання атомарного виконання через Invoker: або операції approve і dApp успішно виконуються разом, або вони зазнають невдачі разом. Лише для схвалення немає можливості успіху, тому користувачі можуть бути впевнені, що це схвалення призначене для цієї операції. А користувачі використовують поза блокчейном авторизацію підпису, тому користувацький досвід такий самий, як і у permit! Це означає, що dApp не лонгуючий знадобиться режим дозволу! У майбутньому гаманці можуть безпосередньо забороняти або проводити суворіші перевірки запитів на підпис дозволів, не турбуючись про те, чи не призведе це до того, що користувачі не використовуватимуть деякі dApps (але, у свою чергу, будуть використані для шахрайства).

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

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

Як Гаманець обробляє нонсеси EOA

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

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

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

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

Session Key і Social Recovery, швидше за все, доведеться почекати, поки EIP-3074 не змінить правила, щоб видалити nonce EOA зі змісту підпису, перш ніж їх можна буде прийняти у великих масштабах. Таким чином, гаманцю потрібно зосередитися лише на випадку використання "операцій, авторизованих користувачем" і розглядати підпис EIP-3074 як транзакцію. Не потрібно турбуватися про те, щоб уникнути надсилання транзакцій EOA або змінити nonce EOA.

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

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

Оскільки ланцюжок спочатку додасть 1 до nonce EOA, перевірка підпису EIP-3074 не вдасться через невідповідність nonce EOA.

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

Підсумок та основні моменти

• EIP-3074 дозволяє EOA отримати такі ж багаті можливості виконання, як і контракти, відкриваючи багато нових сценаріїв застосування.
• Це не тільки значно покращить взаємодію з користувачем, але й змінить поточний метод авторизації токена, зробивши його безпечнішим, зберігши при цьому той самий користувацький досвід.
• Крім того, EIP-3074 є простим підписом, і користувачам не обов'язково приносити підпис у ланцюжок для виконання, тому не потрібно турбуватися про збір ETH для сплати комісії за транзакцію.
• Використання EIP-3074 включає пакетний дзвінок, ключ сеансу, власний дозвіл ETH, Лімітний ордер та соціальне відновлення. Багато з них раніше були неможливими для EOA, а деякі, як Лімітний ордер, вимагали використання небезпечних методів попередньої авторизації.
• EIP-3074 також змінить поточний метод авторизації токена. Метод схвалення безпосередньо уповноважує конкретну адресу мати право виводити токени на невизначений термін, і він вимагає, щоб EOA користувача надіслав транзакцію для виконання схвалення, тому користувацький досвід і безпека не є хорошими; Метод дозволу вимагає лише від користувача підпису, і кожен підпис вказуватиме суму та термін дії, що значно покращує взаємодію з користувачем та безпеку порівняно з approve.
• Однак дозвіл все ще часто використовується в шахрайстві. При підписанні користувачі можуть знати тільки кого, скільки і термін дії, але вони не знають, для чого потрібна ця авторизація. «Для чого це потрібно» буде іншим підписом (або транзакцією). Звичайні dApps дозволять користувачам підписувати дозвіл і «для чого він потрібен», але це все одно будуть два різні підписи, тому на прохання підписати дозвіл ні користувач, ні гаманець не можуть знати, для чого цей дозвіл буде використовуватися.
• З EIP-3074 користувачам (1) не потрібно заздалегідь схвалювати велику суму грошей для dApp, а потрібно лише схвалювати операцію, яка має такий самий ефект, як і дозвіл; (2) це просто простий підпис, і йому не потрібно турбуватися про збір ETH для сплати комісії за транзакцію, яка така сама, як і дозвіл; (3) Кожне схвалення прив'язане до конкретної операції та підписане разом, тому користувачі можуть чітко знати, для чого це схвалення, що буде безпечнішим за дозвіл!
• Є надія, що EIP-3074 зможе успішно замінити поточні режими схвалення та дозволу та надати користувачам безпечніший метод авторизації.

Відмова від відповідальності:

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