У світі блокчейну користувачам часто потрібно надавати дозволи (дозволи), які дозволяють смарт-контрактам витрачати токени від їх імені. Наприклад, при використанні децентралізованої біржі (DEX) для обміну токенів користувачу спочатку потрібно надати дозвіл контракту біржі на переказ певної кількості токенів з їх гаманця. Під традиційним ERC-20згідно зі стандартом, цей процес потребує двох окремих транзакцій on-chain: одну для схвалення і іншу для фактичного переказу токенів. Цей двоетапний процес не лише незручний, але також призводить до додаткових комісій за газ. Для покращення як користувацького досвіду, так і безпеки спільнота Ethereum ввела механізм авторизації на основі підпису.Дозвіл(такі як EIP-2612), а пізніше була розроблена розширена версія під назвою Permit2. Ці нові механізми дозволяють користувачам надавати дозволи на токени через підписи поза ланцюжком, уникнувши потреби у додаткових транзакціях на ланцюжку.

У цій статті ми розпочнемо з основ, пояснюючи, як працюють традиційні схвалення ERC-20 та їх обмеження. Потім ми заглибимося в те, як функціонують Permit та Permit2, висвітлимо їх переваги та компроміси, і обговоримо, як вони покращують як ефективність, так і безпеку. Ми також розглянемо потенційні ризики безпеки, особливо атаки на рибалку, що включають зловмисні підписиі запропонуйте поради, як залишатися в безпеці. Незалежно від того, чи ви новачок у блокчейні, чи тільки починаєте свій шлях криптоінвестицій, цей посібник має на меті допомогти вам зрозуміти ці важливі технічні інновації.

Основи моделі авторизації ERC-20

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

Як працюють традиційні схвалення ERC-20

ERC-20 - це стандарт для токенів на Ethereum. Він визначає функції, такі як approve та transferFrom, які разом дозволяють авторизацію токенів. Авторизація тут означає, що власник токенів дозволяє іншому обліковому запису, зазвичай смарт-контракту (споживачу), переносити певну кількість токенів від його імені. Основний процес виглядає наступним чином:

1. Власник токенів викликає функцію approve(споживач, кількість) контракту токенів. Це реєструє дозвіл у внутрішньому відображенні контракту, як правило, вираженому як дозвіл[власник][споживач] = кількість. Наприклад, якщо користувач А авторизує контракт Uniswap на витрату до 100 токенів, контракт збереже дозвіл[A][Uniswap] = 100. Цей крок потребує транзакції на ланцюжку та оплати газу, яку здійснює А.
2. DeleGate.iod Передача (transferFrom): Пізніше, коли Uniswap (або інша додаткова програма) потрібно витратити токени від імені A, вона викликає transferFrom(A, B, сума) на контракт токена. Контракт перевіряє, чи дозвол[A][Uniswap] є достатнім. Якщо так, контракт передає вказану суму від A до B та зменшує цю суму з дозволу.

Обмеження та виклики моделі схвалення

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

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

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

Крім того, оскільки кожен додаток dApp управляє своїми дозволами незалежно, користувачі мають мало централізованого контролю над своїми схваленнями. Деякі інструменти, такі як Revoke.cash таDeBank, дозволяють користувачам переглядати та керувати дозволами на токени, але багато користувачів про них не знають. І навіть якщо вони про них знають, скасування дозволів все ще потребує транзакцію на ланцюжку, що додає витрати. В результаті багато старих або не використаних схвалень просто забуваються.

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

Ці виклики змусили розробників шукати кращі альтернативи. Ідеально, користувачам потрібно буде підписати тільки раз (найкраще поза ланцюжком та безкоштовно) для завершення як схвалення, так і дії. Схвалення також повинно бути обмеженим за обсягом та тривалістю, щоб зменшити можливі ризики. Це мотивує впровадження ERC-20 Permit.

Дозвіл: Авторизація на основі підпису ERC-20 (EIP-2612)

Концепція дозволу була вперше представленаDAIконтракт стабільної монети, який пізніше стандартизувався як EIP-2612. Коротко кажучи, Permit дозволяє користувачам авторизувати перекази токенів за допомогою офчейн-підписів, уникнувши потребу в окремій транзакції для схвалення на ланцюжку. Давайте розглянемо детальніше, як це працює та його характерні особливості.

Як працює дозвіл

Дозвіл є механізмом авторизації на основі цифрових підписів. Згідно зі стандартом EIP-2612, контракти токенів ERC-20, які підтримують Permit, додають функцію під назвою permit(), яка виглядає так:

функція дозволу(
власник адреси, витратник адреси,
uint256 значення, uint256 крайній термін,
uint8 v, bytes32 r, bytes32 s
) зовнішній;

Тут власник, витратник та значення вказують, хто дає дозвіл, хто отримує дозвіл та яка сума дозволена. Кінцевий термін вказує, коли підпис закінчується. Параметри v, r та s утворюють ECDSAцифровий підпис. Використовуючи Permit, користувачі обходять окреме схвалення on-chain — вони просто підписують повідомлення (без виплати Gas) та включають цей підпис до своєї транзакції, щоб завершити авторизацію за один крок.

Дозвільний процес

У порівнянні з традиційним схваленням, Permit вилучає необхідність в додатковій транзакції on-chain, що дозволяє заощадити як час, так і комісію Gas. Він також надає можливість деталізованого контролю над схваленнями. Наприклад, користувач може підписати Permit, який дозволяє витрачати рівно 50 USDC, дійсний лише протягом 5 хвилин. Навіть якщо підпис стає відомим, він стає непридатним після закінчення терміну, що зменшує ризик. Сьогодні багато DeFi протоколів, таких як децентралізовані біржі та платформи кредитування, вже підтримують Permit. До відомих прикладів входятьUniswap V2/V3Токени LP, DAI, таUSDC, які впровадили стандарт EIP-2612, що дозволяє затвердження в один крок на основі підпису.

Проте найбільшою обмеженням Permit є те, що його необхідно виконувати безпосередньо в контракті токенів. Якщо розробник токена не додав метод permit(), що означає, що він не підтримує EIP-2612, то Permit просто не може бути використаний. Оскільки EIP-2612 був введений лише в 2020 році, багато старих токенів не містять його, і навіть нові токени не завжди його використовують. Це обмежує застосування Permit: непідтримувані токени все ще потребують традиційного потоку схвалення.

Інша проблема полягає в тому, що програмне забезпечення гаманця має належним чином обробляти та відображати підписи дозволів, які зазвичай форматуються за допомогою EIP-712. Більшість основних гаманців зараз підтримують це, але деякі все ще показують необроблені дані замість повідомлень, які може прочитати людина, що ускладнює користувачам розуміння того, що вони підписують. Без чіткого інтерфейсу для EIP-2612 гаманці можуть перешкоджати розумінню користувачами схвалення на основі підпису. Крім того, у випадках паралельного розгортання (наприклад, контракти з ідентичними адресами в різних ланцюгах) сигнатури потенційно можуть бути повторно використані в інших середовищах. Тому користувачі повинні перевірити, чи ідентифікатор ланцюга та адреса контракту в їхніх підписах відповідають їхньому поточному середовищу, щоб запобігти неправомірному використанню дозволів, наданих для токенів у ланцюжку A, ідентичними адресами контрактів у ланцюжку B.

У суті, Дозвіл значно покращує ефективність та гнучкість схвалень ERC-20, що є важливим кроком у механізмах схвалення без газу. Однак це не є ідеальним рішенням: воно потребує підтримки на рівні токенів та вносить нові ризики. Далі ми розглянемо, як Permit2 від Uniswap будує на та розширює фундамент, закладений Permit.

Дозвіль2: Універсальний Контракт управління авторизацією

По мірі зростання популярності механізму Дозволу з'явилася нова проблема: як розширити зручність авторизації на основі підпису для токенів, які не підтримують Дозвіл? Для вирішення цієї проблеми та оптимізації досвіду авторизації в різних сценаріях команда Uniswap представила Permit2 в 2022 році. На відміну від функції, специфічної для токенів, Permit2 є автономним смарт-контрактом управління авторизацією. Він діє як посередник для авторизації токенів, надаючи єдинообразні та покращені можливості дозволів. Давайте проаналізуємо принципи та функції Permit2.

Як працює Permit2

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

1. Дозвіл на авторизацію одного разу: Користувачі схвалюють Дозвіл2 для кожного токена, використовуючи традиційний метод схвалення (Дозвіл2, максимальна_сума). Рекомендується велика або необмежена сума, оскільки це майстерне схвалення. Після завершення Дозвіл2 контракт отримує можливість викликати transferFrom від імені користувача для цього токена. Це вимагає транзакції на ланцюжку, але потрібно зробити це лише один раз.
2. Підпис поза ланцюжком для підповноваження: Коли користувачі хочуть взаємодіяти з DApp (наприклад, використовуючи Універсальний маршрутизатор Uniswap для мульти-токенових обмінів), вони підписують повідомлення про поза ланцюжкове підтвердження відповідно до специфікацій Permit2. Цей підпис включає деталі, такі як дозволений токен, сума, цільовий розпорядник (наприклад, конкретний договір DApp) та час закінчення дії.
3. Запит на передачу DApp за допомогою підпису: Коли DApp отримує підпис користувача і потребує використання токенів, замість прямого виклику контракту токенів, він викликає функції Permit2 (наприклад, permitTransferFrom). Ця функція перевіряє дані підпису користувача та підтверджує, що операція відбувається в межах наданих дозволів (токен, сума, термін дії). Після перевірки Permit2 використовує своє майстер-схвалення для виклику transferFrom, переміщаючи токени від користувача до вказаного одержувача. Ключовий момент: сам контракт Permit2 діє як витратник, використовуючи власні повноваження для передачі токенів, з додатковим кроком перевірки підпису.
4. Завершення операції: Після того, як Permit2 успішно виконує transferFrom, кошти плавно переміщуються від користувача до DApp або вказаної адреси. З точки зору користувача, вони лише надають підпис у транзакції, тоді як контракт обробляє всі подальші дії.

Поток авторизації Permit2 простий: користувачам потрібно лише надати максимальне схвалення Permit2 один раз на токен. Після цього, при взаємодії з додатками (такими як Uniswap Universal Router або інші протоколи), вони просто включають підпис Permit2 у свою транзакцію, щоб завершити авторизацію та передачу без додаткових схвалень на ланцюжку. Контракт Permit2 перевіряє підпис та виконує передачу, використовуючи своє майстер-схвалення. (Джерело:Представляємо Permit2 & Universal Router)

За допомогою цієї моделі Permit2 розширює концепцію авторизації на основі підпису EIP-2612 на всі токени ERC-20, незалежно від того, чи реалізують вони метод permit(). Поки користувачі початково авторизують контракт Permit2, вони можуть використовувати підписи для подальших операцій. Зокрема, Uniswap розробив Permit2 як контракт без власника, який не може бути оновлений, розгорнутий за тією ж адресою на головній мережі Ethereum та кількох мережах Layer 2. Це означає, що всі додатки фактично використовують той самий екземпляр Permit2, досягаючи справжню функціональність "один раз схвалити, використовувати скрізь".

Ключові особливості Permit2

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

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

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

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

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

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

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

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

Прийняття та впровадження екосистеми Permit2

Одразу після введення Uniswap Permit2 численні проекти інтегрували цей механізм, що прискорило стандартизацію промисловості. Згідно з останніми даними з Аналітика дюн, на квітень 2025 року понад 3,1 мільйона адрес основної мережі Ethereum надали авторизацію контракту Permit2, що свідчить про його широке поширення.

Екосистема Permit2 та статус впровадження. Джерело:Dune Analytics

Наприклад, Uniswap інтегрував Permit2 у свій Universal Router, що дозволяє проводити обмін багатьох токенів та NFT у одній угоді. За допомогою Universal Router користувачі можуть ланцюгувати кілька операцій у одній угоді, наприклад, обмін трьох токенів на два цільові токени та покупку NFT, при цьому всі вимоги до авторизації обробляються підписами Permit2. Це значно спрощує процес та зменшує загальні витрати на Газ, демонструючи прямий вплив Permit2 на покращення користувацького досвіду.

Крім того, завдяки можливості відкритого розгортання Permit2 на різних ланцюжках, збільшується кількість гаманців та інструментів DApp, які почали його підтримувати. Інструменти безпеки, такі як Revoke.cash, оновили свої послуги, щоб дозволити користувачам переглядати та відкликати записи дозволів Permit2. Matcha також реалізував модуль SignatureTransfer Permit2, що дозволяє механізм «одноразової авторизації».

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

Порівняння дозволу2 з новими рішеннями: сеансовими ключами та ERC-4337

За останні 8 років механізми авторизації ERC-20 еволюціонували від множинних транзакцій до безгазових підписів, а тепер і до смарт-рахунків. Кожне вдосконалення було спрямоване на оптимізацію балансу між користувацьким досвідом (зниження вимог до транзакцій і підписів) і витратами на газ. Ось порівняння цих технологій:

Крім Permit2, варто відзначити два нові рішення авторизації - Session Keys таERC-4337 Обліковий абстракція, кожен пропонує відмінні підходи до проблеми.

Ключі сесії є особливо унікальними, оскільки вони не є строгою моделлю авторизації, а скоріше тимчасовим механізмом ключа на рівні гаманця або облікового запису. Замість модифікації токенних контрактів вони дозволяють гаманцям генерувати тимчасові приватні ключі з обмеженим часом та сумою для конкретних операцій. Це дозволяє їм ідеально підходити для покупок предметів для гри та одноразових мікроплатежів. Їхня увага спрямована на зменшення ризиків одноразової авторизації, спеціально розроблена для тимчасових користувацьких взаємодій, на відміну від підходу до модифікації контрактів Permit/Permit2.

ERC-4337 відрізняється тим, що вбудовує логіку авторизації безпосередньо в розумні облікові записи, дозволяючи користувачам настроювати умови авторизації та, можливо, уникати традиційних кроків підтвердження. За допомогою гнучких механізмів UserOperation та Paymaster досягається підвищений рівень безпеки та зручності для користувачів.

Глядачи на майбутні тенденції, ці різні рішення ймовірно будуть існувати поруч. У короткостроковій перспективі Permit2 продовжить бути стандартом для нових DApps, поліпшуючи досвід користувача за допомогою одноразових авторизацій, сприяючи навчанню з питань безпеки та підтримці інструментів для зменшення ризиків фішингу. У середньостроковій перспективі, коли ERC-4337 та абстракція облікового запису стають більш поширеними серед Layer 2s та mainnets, користувачі матимуть змогу визволитися від традиційних обмежень затвердження ERC-20, керуючи авторизаціями більш точно та розумно, що потенційно зменшить потребу в Permit2.

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

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

Безпекові ризики авторизації на основі підпису

Як із будь-якою новою технологією, Permit та Permit2 вводять не лише нові ефективності, але й нові ризики, особливо щодо атак на авторизацію на основі підпису.

У схемах, заснованих на сигнатурах, таких як Permit2 і EIP-2612 Permit, основні проекти контрактів включають кілька рівнів захисту від неправильного використання та повторних атак:

1. Захист від повторного відтворення на основі Nonce

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

2. Забезпечення дотримання строки

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

3. Контроль дозволів дрібного зерна

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

4. Одноразові та партійні режими

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

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

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

Як відбуваються атаки фішингу з підписом?

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

1. Жертва натискає на фальшиву версію відомого веб-сайту DEX (сайту-фішингу). Коли користувач намагається взаємодіяти, сайт вимагає підпис гаманця, стверджуючи, що це для "підтвердження входу" або інших, на перший погляд, законних цілей. Однак цей запит фактично є підписом дозволу Permit2, що надає контракту атакувача необмежений дозвіл на зняття USDC жертви з розширеним терміном дії.
2. Потерпілий, не виявляючи бджільності, підписує запит безпосередньо. На цьому етапі не витрачається газ і не відбувається жодна дія на ланцюжку, не залишаючи підозрілих слідів.
3. Як тільки зловмисник отримує підпис, він негайно викликає функцію permit() контракту Permit2, щоб подати його. Після того, як контракт Permit2 перевіряє підпис, він реєструє авторизацію для контракту зловмисника під адресою жертви (еквівалентно здійсненню жертвою approve, але завершується зловмисником). Ця операція може залишитися непоміченою жертвою, оскільки їх гаманець не показує витрат - лише їхнє відображення дозволу токенів оновлюється в блокчейні.
4. Після цього злочинець негайно ініціює трансфер (від жертви, адреса злочинця, сума) транзакцію зі своєї адреси, успішно переказуючи USDC жертви, використовуючи недавню авторизацію Permit2. Жертва реалізує крадіжку лише тоді, коли вже занадто пізно.

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

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

Більшість останніх випадків шахрайства у криптосвіті включають авторизацію підпису. Наприклад, Scam Sniffer’sстатистиказ початку 2024 року показують, що протягом всього одного місяця було викрадено понад $55 мільйонів активів за допомогою фішингу підписів. Після активації Permit2 атакувальники стали більш агресивними в спонуканні користувачів підписувати дозволи Permit/Permit2, що призвело до численних жертв за короткий період часу. Очевидно, що коли використовується зловживання підписом, це може бути руйнівним і важким для виявлення.

Чому ризики фішингу на основі підпису вищі, ніж традиційні методи?

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

Крім того, різні гаманці відображають повідомлення EIP-712 по-різному. Деякі сучасні гаманці (наприклад, останніMetaMask ) розберіть та відобразіть поля чітко, показуючи повідомлення типу "дозвольте контракту витратити X кількість ваших токенів". Однак багато гаманців показують лише шістнадцяткові дані або прості описи, що робить складним перевірку автентичності для середніх користувачів. Злоумисники використовують це, вбудовуючи обманливі описи в повідомлення (наприклад, претендуючи на підписи монет NFT), щоб обдурити користувачів у підписанні.

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

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

Як користувачі можуть захистити себе від атак з підписами?

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

Переконайтеся, що ваше програмне забезпечення гаманця підтримує відображення даних EIP-712. Основні гаманці, такі як MetaMask,TrustWallet, таLedger Liveпокращують відображення вмісту свого підпису. Наприклад, тепер MetaMask може розбирати звичайні повідомлення про дозволи на звичну мову. Якщо ваш гаманець показує лише довгі шістнадцяткові дані при підписанні, подумайте про зміну або оновлення. Користувачі апаратних гаманців також повинні оновлювати прошивку, щоб підтримувати нові формати, інакше вони можуть не правильно бачити інформацію на екрані.

Незалежно від того, чи використовуються підписи дозволу або Permit2, ви зазвичай можете налаштувати параметри авторизації. Не підписуйте необмежену кількість (значення = 2^256-1) без крайньої необхідності - замість цього авторизуйте лише потрібну суму плюс невеликий буфер. Крім того, не встановлюйте занадто далеко дедлайни в майбутньому. Таким чином, навіть якщо ваш підпис потрапить у чужі руки, потенційні втрати обмежені, і термін дії підпису зрештою закінчиться.

Виробіть звичку регулярно перевіряти статус авторизації вашої адреси за допомогою таких інструментів, як Revoke.cash, Etherscan Token Approval або вбудованих функцій вашого гаманця. Це стосується як традиційних дозволів, так і надбавок Permit2. Якщо ви помітили будь-які підозрілі або непотрібні дозволи, негайно відкликайте їх. Для Permit2 пам'ятайте про два рівні відкликання: по-перше, майстер-авторизація (ви погоджуєтеся з самим договором Permit2, який ви можете встановити на 0, коли він не використовується); по-друге, субавторизація (надбавки Permit2 до різних DApps, термін дії яких зазвичай закінчується автоматично, але може бути достроково припинений, якщо вони мають тривалі терміни дії). Якщо ви підозрюєте, що підписали підозрілий Дозвіл, найбезпечнішою дією буде негайно виправити недійсність: підписати новий дозвіл тому ж марнотрату (навіть з 0 дозволом), щоб визнати недійсним старий підпис у зловмисника.

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

Підсумовуючи, дотримання балансу між зручністю та безпекою має вирішальне значення. Незважаючи на те, що дозвільні технології зручні, користувачі повинні залишатися пильними щодо запобігання ризикам. У міру розвитку екосистеми продукти гаманців і плагіни для браузерів розробляють захист від фішингу підписів, наприклад, попередження про підписи, пов'язані з великими сумами. Ми прагнемо mitiGate.io таких атак за допомогою як технічних, так і освітніх удосконалень у майбутньому.

Висновок

Від обмежень традиційних моделей авторизації ERC-20 до народження Permit, а потім до інноваційного Permit2 від Uniswap, ми бачили зусилля екосистеми Ethereum щодо поліпшення зручності користувачів та безпеки. Permit2 значно спрощує процес авторизації токенів за допомогою підписів поза ланцюжком, зменшуючи ризики повторних схвалень та необмежених дозволів, водночас вводячи корисні функції, такі як механізми закінчення терміну дії та пакетні операції. Однак ці нові механізми приносять нові відповідальності - користувачам потрібно підвищити свідомість про безпеку, тоді як гаманці та додатки повинні співпрацювати для захисту користувачів від атак на підписи. Передбачається, що з подальшим розвитком технологій, таких як абстракція рахунку, управління авторизацією токенів стане більш безшовним та безпечним.