Функция Permit (EIP-2612)

Что такое функция Permit (EIP-2612)?

Функция Permit, описанная в EIP-2612, — это расширение токенов ERC-20, которое позволяет владельцу токена разрешить расходование средств третьим лицом, подписав сообщение вне блокчейна, вместо отправки отдельной ончейн-транзакции для подтверждения.

В криптоиндустрии это важно, поскольку упрощает подтверждение доступа к токенам, снижает связанные с ним расходы и облегчает объединение такого действия с другими операциями смарт-контракта.

В официальной спецификации EIP-2612 указано, что стандарт расширяет ERC-20 новой функцией

, которая изменяет структуру allowance с помощью подписанного сообщения, а не через .

Проще говоря, EIP-2612 позволяет пользователю подписать в кошельке сообщение: «Я разрешаю этому смарт-контракту потратить указанное количество моих токенов».

Затем другой аккаунт или контракт может отправить это подписанное подтверждение в блокчейн.

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

Кроме того, владельцу токенов может не понадобиться нативный токен сети для оплаты газа, чтобы разрешить расходование токенов ERC-20.

Функция Permit сама по себе не переводит токены.

Она лишь устанавливает лимит разрешенного расходования (allowance), который впоследствии может использоваться функцией

или другим сценарием смарт-контракта.

Это важное различие: разрешить третьему лицу расходовать токены — не то же самое, что отправить ему токены.

Permit следует рассматривать как подписанное разрешение, которое после отправки подписи обновляет состояние allowance токена ERC-20 в блокчейне.

Основные сведения о функции Permit

• • EIP-2612 добавляет в токены ERC-20 функции
    permit
    ,
    nonces
    и
    DOMAIN_SEPARATOR
    .
  • Функция Permit позволяет разрешать расходование токенов ERC-20 с помощью подписи вне блокчейна.
  • Подписанное сообщение соответствует правилам типизированных структурированных данных EIP-712.
  • Permit изменяет allowance, но самостоятельно не переводит токены.
  • Nonce не позволяет повторно использовать одну и ту же подпись permit.
  • Срок действия ограничивает период, в течение которого подписанный permit остается действительным.
  • Permit улучшает пользовательский опыт, но не устраняет риски подтверждения доступа и фишинга подписей.

Зачем был создан EIP-2612

Токены ERC-20 используют модель подтверждения, позволяющую одному адресу разрешить другому адресу расходовать токены от его имени.

В исходном стандарте ERC-20 определены такие функции, как

, и .

Эта модель сделала токены совместимыми с кошельками, смарт-контрактами, платежными системами, торговыми интерфейсами, протоколами кредитования, контрактами стейкинга и другими децентрализованными приложениями.

Однако стандартный процесс подтверждения ERC-20 часто требует двух ончейн-транзакций.

Первая — транзакция

.

Вторая — фактическое действие смарт-контракта, использующего подтвержденные токены.

Это создает неудобства: пользователям приходится дважды оплачивать газ, ждать двух подтверждений и разбираться с двумя отдельными запросами кошелька.

Проблема также возникает у пользователей, у которых есть токены ERC-20, но нет нативного токена, необходимого для отправки транзакции подтверждения.

EIP-2612 решает эту конкретную проблему, позволяя подтверждать доступ с помощью подписанного сообщения.

Владелец токенов подписывает permit вне блокчейна, а отправить его в блокчейн может другая сторона.

Благодаря этому подтверждение и основное действие можно эффективнее объединить в один процесс работы смарт-контракта.

Например, пользователь может подписать permit, после чего контракт использует это подтверждение и переводит токены в рамках одной транзакции.

Это не означает, что сетевые транзакции становятся бесплатными.

Кто-то по-прежнему оплачивает газ за отправку permit в блокчейн.

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

Как работает функция Permit

Основная функция EIP-2612 имеет следующий вид:

.

— владелец токенов, подписывающий подтверждение.

— адрес, которому предоставляется allowance.

— количество токенов, разрешенное к расходованию.

— крайний срок, до которого можно использовать permit.

Значения

, и — части криптографической подписи.

При отправке permit контракт токена проверяет действительность подписи.

Он также проверяет, не истек ли срок ее действия.

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

Если все необходимые проверки пройдены, контракт устанавливает

на одобренное значение.

Затем контракт увеличивает nonce владельца, чтобы исключить повторное использование той же подписи.

Контракт также генерирует событие

, сохраняя совместимость поведения со стандартными ожиданиями ERC-20.

Так подпись в кошельке превращается в ончейн-обновление allowance.

Три основные функции EIP-2612

EIP-2612 требует, чтобы совместимые токены добавляли к ERC-20 три функции.

Первая функция —

.

Функция

проверяет подписанное подтверждение и обновляет allowance.

Вторая функция —

.

Функция

возвращает текущий nonce для адреса владельца.

Третья функция —

.

Функция

возвращает разделитель домена EIP-712, который привязывает подпись к конкретному контракту токена и контексту подписания.

Эти три функции работают вместе.

Подпись permit определяет разрешение.

Nonce предотвращает повторное воспроизведение подписи.

Разделитель домена помогает привязать подпись к правильному контракту и контексту сети.

Без этих вспомогательных механизмов подписи permit было бы гораздо проще использовать не по назначению или воспроизводить в неподходящем контексте.

Что такое allowance?

Allowance — это количество токенов ERC-20, которое владелец разрешил использовать стороннему адресу.

Например, если Alice разрешает смарт-контракту потратить 100 токенов, allowance от Alice этому смарт-контракту составит 100 токенов.

Затем получатель разрешения может вызвать

и переместить токены в пределах одобренного количества — в зависимости от контракта токена и сценария приложения.

Функция Permit не отменяет систему allowance.

Она меняет способ создания allowance.

Вместо того чтобы владельцу токенов напрямую вызывать

, EIP-2612 позволяет подписать сообщение, разрешающее обновление allowance.

Это упрощает использование и сохраняет совместимость с привычной моделью allowance ERC-20.

Пользователям все равно следует внимательно относиться к allowance: одобренный адрес может перемещать токены в пределах разрешенного количества.

Неограниченное разрешение через permit может быть удобным, но также привести к крупным потерям, если контракт получателя разрешения окажется вредоносным, скомпрометированным или неправильно понятым пользователем.

Функция Permit и функция Approve

Традиционную функцию

владелец токенов вызывает напрямую в ончейн-транзакции.

Функцию Permit владелец токенов разрешает своей подписью вне блокчейна, а позднее в блокчейн ее отправляет другая сторона.

При использовании

владелец токенов оплачивает газ за транзакцию подтверждения.

При использовании

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

При использовании

действие подтверждения непосредственно связано с .

При использовании

действие подтверждения основано на проверенной подписи владельца.

Результатом в обоих случаях может быть одинаковое обновление allowance, но пользовательский опыт отличается.

Именно поэтому EIP-2612 часто называют стандартом, обеспечивающим подтверждение без газа.

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

Для обновления состояния в блокчейне по-прежнему нужны транзакция и газ.

Почему для Permit важен EIP-712

EIP-2612 использует типизированные структурированные данные на основе EIP-712.

EIP-712 — это стандарт хеширования и подписания структурированных данных вместо непрозрачных строк байтов.

Это важно, поскольку пользователям кошельков необходимо понимать, что именно они подписывают.

Запрос на подпись необработанной шестнадцатеричной строки может быть непонятным и опасным.

В типизированной подписи могут быть более понятно отображены такие поля, как owner, spender, value, nonce и deadline.

EIP-712 также использует разделитель домена.

Он помогает отделить один контекст подписания от другого.

Для EIP-2612 разделитель обычно включает такие сведения, как название токена, версия, ID сети и адрес проверяющего контракта.

Такая структура помогает предотвратить использование подписи, предназначенной для одного токена или сети, в другом контексте.

В самом EIP-712 указано, что стандарт не обеспечивает защиту от повторного воспроизведения подписи.

EIP-2612 добавляет такую защиту с помощью отдельных nonce для каждого владельца.

Nonce и защита от повторного воспроизведения

Nonce — это число, которое используется один раз.

В EIP-2612 контракт токена отслеживает nonce для каждого адреса владельца.

Подписывая permit, пользователь включает в подписываемые данные текущий nonce владельца.

После успешного использования permit контракт токена увеличивает nonce.

Если кто-то попытается отправить тот же permit повторно, nonce уже не совпадет.

В результате повторно использованная подпись будет отклонена.

Защита с помощью nonce необходима, поскольку подписи можно скопировать.

Без нее получатель разрешения или злоумышленник мог бы использовать одну и ту же подпись permit несколько раз.

Надлежащая реализация permit должна включать nonce в подписываемое сообщение и обновлять его только после успешного выполнения permit.

Для пользователей практический смысл прост.

Действительная подпись permit должна использоваться один раз, а не оставаться действительной навсегда.

Сроки действия и истечение подписи

Параметр

ограничивает период, в течение которого можно использовать подпись permit.

Если временная метка текущего блока позже указанного срока, permit должен быть отклонен.

Это защищает пользователей от отправки старых подписей спустя долгое время после того, как предполагалось их использовать.

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

Длительный срок действия может быть удобнее: подпись остается пригодной к использованию дольше.

Неограниченный или очень отдаленный срок может быть рискованным: подписанное разрешение может оставаться действительным долгое время, если его не использовать, не аннулировать или не заменить с учетом механизма nonce.

Если кошелек отображает типизированные данные permit, пользователям следует обращать внимание на срок действия.

Разработчикам не следует задавать чрезмерно длительный срок без веской причины.

Приложениям следует объяснять пользователям значение срока действия понятным языком.

Разделитель домена и контекст сети

Разделитель домена — важная часть подписания по EIP-712.

В EIP-2612 он помогает привязать permit к конкретному контракту токена и домену.

Обычно домен включает название токена, версию токена, ID сети и адрес проверяющего контракта.

Это снижает риск того, что permit, подписанный для одного контракта, можно будет повторно использовать для другого.

Это также снижает риск повторного использования подписи, созданной в одной сети, в другой сети.

Однако безопасность разделителя домена зависит от правильности реализации.

Если контракт токена использует неполный разделитель домена, риск повторного воспроизведения подписи может возрасти.

Если меняется ID сети или контракт развернут в нескольких сетях, разработчикам следует тщательно продумать разделение подписей.

Для пользователей разделитель домена обычно скрыт интерфейсом кошелька.

Для разработчиков это одна из важнейших деталей безопасной реализации permit.

Как работает подтверждение без газа

Выражение «подтверждение без газа» может вводить в заблуждение.

EIP-2612 не делает транзакции Ethereum или EVM бесплатными.

Он позволяет владельцу токенов разрешить их расходование, подписав сообщение вместо отправки транзакции.

Затем релейер, приложение, смарт-контракт или получатель разрешения может отправить подписанный permit в блокчейн и оплатить газ.

Это может помочь пользователям, у которых есть токены ERC-20, но недостаточно нативного токена для оплаты отдельного подтверждения.

Это также помогает приложениям создавать более простой процесс взаимодействия в один шаг.

Например, пользователь может подписать permit, а затем внести депозит, выполнить платеж или совершить другое действие с токеном, не отправляя вручную отдельное подтверждение заранее.

Пользовательский процесс становится проще, но блокчейн по-прежнему фиксирует изменение состояния ончейн-транзакцией.

Разработчикам важно ясно объяснять это, иначе пользователи могут решить, что у подписанных сообщений нет последствий.

После отправки подпись permit может привести к реальным последствиям в блокчейне.

Распространенные сценарии использования EIP-2612 в криптоиндустрии

EIP-2612 часто используется в децентрализованных финансах и приложениях на основе токенов.

Протокол кредитования может использовать permit, чтобы пользователь мог одним действием разрешить использование залога и внести его.

Контракт стейкинга может использовать permit, чтобы пользователь мог разрешить стейкинг токенов без отдельной транзакции подтверждения.

Платежное приложение может использовать permit, чтобы плательщик мог разрешить перевод токенов в более удобном процессе оплаты.

Кошелек может использовать permit, чтобы сократить число шагов при стандартных операциях с ERC-20.

Сервис релейера может оплатить газ от имени пользователя и компенсировать расходы другим способом.

Смарт-контракт может объединить permit с

, чтобы подтверждение доступа и перемещение токенов выполнялись в рамках одной транзакции.

Такой подход может сократить количество неудачных пользовательских сценариев: не нужно отдельно ждать включения подтверждения в блок перед выполнением основного действия.

Он также может уменьшить путаницу, поскольку приложение проводит пользователя через единый процесс.

Главное преимущество заключается не только в экономии на газе.

Оно также состоит в том, что упрощается предоставление разрешения на использование токенов.

Функция Permit и абстракция аккаунтов

Функцию Permit иногда обсуждают в контексте абстракции аккаунтов, поскольку обе концепции улучшают пользовательский опыт работы с кошельком.

Permit позволяет владельцу токенов ERC-20 разрешать изменение allowance с помощью подписи.

Абстракция аккаунтов призвана сделать криптоаккаунты более программируемыми и гибкими.

Это разные инструменты, но их цели схожи.

Оба подхода помогают упростить взаимодействие с блокчейном.

Permit предназначен для подтверждения доступа к токенам.

Абстракция аккаунтов касается более широких возможностей аккаунта подтверждать действия и оплачивать их.

Криптоприложение может использовать оба подхода в одном продукте.

Например, кошелек или система смарт-аккаунтов могут поддерживать оплату транзакций спонсором и одновременно использовать совместимые с permit подтверждения токенов.

Пользователям необязательно разбираться во всех технических слоях, но разработчики должны корректно реализовать каждый из них.

Риски безопасности функции Permit

Главный риск для пользователей — фишинг подписей.

Вредоносный сайт может попросить пользователя подписать permit, предоставляющий опасному получателю широкие права на расходование токенов.

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

Это опасное заблуждение.

Permit может разрешить третьему лицу перемещать токены позднее.

Перед подписанием пользователям следует проверять адрес получателя разрешения, количество токенов, название токена и срок действия.

Не подписывайте непонятные или неожиданные запросы, а также запросы с незнакомых сайтов.

Еще один риск — неограниченное разрешение.

Если пользователь подписывает permit с очень большим значением, получатель может получить широкие полномочия на расходование соответствующего количества токенов.

Третий риск — неправильная реализация.

Если контракт токена некорректно обрабатывает nonce, разделение доменов, восстановление подписи или срок действия, подписи могут быть воспроизведены повторно или приняты, хотя должны быть отклонены.

Четвертый риск — непонятный интерфейс пользователя.

Если кошелек нечетко отображает типизированные данные, пользователь может подписать разрешение, не понимая его содержания.

Permit повышает удобство, но одновременно делает обучение пользователей работе с подписями еще важнее.

Permit не устраняет риски подтверждения доступа

EIP-2612 меняет способ подтверждения разрешения, но не меняет базовый риск, связанный с предоставлением прав на расходование средств.

Если получатель разрешения окажется вредоносным или скомпрометированным либо получит слишком большой allowance, пользователь все равно может потерять токены.

Разрешение через permit может быть столь же широким, как и разрешение в обычной транзакции

.

Разница в том, что разрешение начинается с подписи, а не с транзакции владельца токенов.

Поэтому пользователям следует относиться к подписям permit так же осторожно, как к транзакциям подтверждения.

Не подписывайте неограниченные разрешения, если вы полностью не доверяете получателю и не понимаете связанные с этим риски.

Отзывайте неиспользуемые allowance, когда они больше не нужны.

Для взаимодействия с более рискованными dApp и хранения активов в долгосрочной перспективе используйте разные кошельки.

Перед предоставлением доступа к ценным токенам проверяйте адреса контрактов по надежным источникам.

Permit и опережающие транзакции

Подпись permit может отправить любой, у кого есть подписанное сообщение.

Это создает особый риск опережающей отправки транзакций (front-running).

Если пользователь подписывает permit и отправляет его приложению, другая сторона, увидевшая подпись, может отправить permit первой.

Во многих случаях это лишь использует permit и устанавливает тот же allowance, который намеревался задать пользователь.

Однако если приложение рассчитывает выполнить permit одновременно с другим действием, опережающая отправка permit может привести к сбою последующей объединенной транзакции: nonce уже изменился.

Разработчикам следует проектировать процессы так, чтобы корректно обрабатывать такую ситуацию.

Часто смарт-контракт может проверить, доступен ли уже ожидаемый allowance, и продолжить выполнение вместо ненужного отказа.

Интерфейсы также должны понятно объяснять, почему не удалось выполнить сценарий с permit.

Пользователям важно помнить: подписанный permit можно передавать и использовать до момента его применения или истечения срока действия.

Не передавайте подписанные данные permit, если не доверяете сценарию их использования.

Особенности реализации для разработчиков

Разработчикам следует строго соблюдать спецификацию EIP-2612.

Хеш типа permit должен соответствовать ожидаемой структуре подписываемых данных.

Для дайджеста следует использовать кодирование EIP-712 с разделителем домена и хешем структуры permit.

Контракт должен отклонять просроченные permit.

Контракт должен отклонять недействительные подписи.

Контракт должен отклонять permit, если восстановленный подписант не является владельцем.

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

После успешного выполнения permit контракт должен увеличить nonce владельца.

После изменения allowance контракт должен генерировать стандартное событие

.

По возможности разработчикам следует использовать хорошо проверенные библиотеки.

В документации OpenZeppelin по ERC20Permit приведен широко используемый шаблон реализации для проектов на Solidity.

OpenZeppelin также описывает использование ERC-20 Permit в других средах, например ERC-20 Permit для Stylus.

Даже при использовании библиотеки разработчикам следует тщательно тестировать фактическое поведение токена.

Функция Permit и метатранзакции

Метатранзакция — более широкий подход, при котором пользователь подписывает сообщение, а другая сторона отправляет транзакцию от его имени.

EIP-2612 можно рассматривать как специализированный способ подтверждения доступа с помощью подписи.

Он не превращает все действия с токенами в действия, подтверждаемые подписью.

Он стандартизирует только подтверждения allowance ERC-20, подписанные владельцем.

Такое ограничение области действия задано намеренно.

Минимальный стандарт проще внедрять и интегрировать в кошельки, контракты и приложения.

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

Permit эффективен, поскольку решает распространенную проблему, не меняя всю модель ERC-20.

Он дополняет системы метатранзакций, а не заменяет их целиком.

Функция Permit и перевод токенов

Permit — это не перевод.

Перевод перемещает токены с одного адреса на другой.

Permit обновляет allowance, который один адрес предоставляет другому.

Таким образом, пользователь может подписать permit, но токены останутся в том же кошельке, пока получатель разрешения не использует allowance.

Фактическое перемещение токенов обычно выполняется с помощью

.

Это различие важно для безопасности кошелька.

После подписания permit пользователь может не увидеть немедленного изменения баланса токенов.

Это не означает, что подпись безвредна.

Получатель разрешения все еще может получить право переместить токены позднее.

После взаимодействия с dApp проверяйте активные allowance и отзывайте больше не нужные разрешения.

Функция Permit и Permit2

EIP-2612 — стандарт на уровне токена.

Чтобы токен поддерживал EIP-2612, контракт самого токена должен реализовать функцию permit.

Другие системы подтверждения могут обеспечивать похожие возможности через внешние контракты.

Такие системы не равнозначны встроенной поддержке EIP-2612.

Это различие важно, поскольку запросы кошелька, адреса получателей разрешения, механизмы nonce, область действия подтверждения и способы отзыва могут различаться.

Подписывая разрешение, похожее на permit, проверяйте, какому контракту предоставляются полномочия.

Разработчикам при интеграции permit следует выяснить, поддерживает ли токен непосредственно EIP-2612 или требуется другой механизм подтверждения.

Называть любое подписанное разрешение «EIP-2612» может быть ошибочно.

У EIP-2612 есть конкретный интерфейс и структура подписи.

Как пользователям читать запрос на подпись permit

Сначала проверьте название токена.

Затем проверьте адрес получателя разрешения или приложение, запрашивающее доступ.

Проверьте одобренное количество.

Убедитесь, что значение ограничено, а не фактически неограниченно.

Проверьте срок действия.

Убедитесь, что запрос появился после намеренно выполненного вами действия.

Отклоните запрос, если он появился неожиданно.

Будьте особенно осторожны, если сайт последовательно запрашивает множество подписей.

Не подписывайте сообщения permit по ссылкам из личных сообщений, поддельных чатов поддержки, подозрительной рекламы или неизвестных страниц токенов.

Помните: подпись permit может предоставить другому адресу право расходовать ваши токены.

Надежный запрос кошелька должен четко отображать эти поля, но не полагайтесь только на дизайн интерфейса.

Почему Permit улучшает пользовательский опыт

Permit улучшает пользовательский опыт, сокращая количество необходимых ончейн-транзакций.

Во многих сценариях взаимодействия с dApp он позволяет отказаться от отдельного шага подтверждения.

Он помогает пользователям взаимодействовать с токенами ERC-20, даже если у них недостаточно нативного токена для оплаты отдельного подтверждения.

Он позволяет приложениям оплачивать газ за пользователя или объединять подтверждение с другим действием.

Он может сократить число неудачных сценариев, когда пользователь подтвердил использование токена, но забыл отправить вторую транзакцию.

Он может упростить подключение новых пользователей, которые только начинают работать с ончейн-приложениями.

Эти преимущества особенно важны, поскольку подтверждения ERC-20 — один из самых распространенных источников неудобств в криптоиндустрии.

Однако более простое подтверждение не означает, что оно автоматически становится безопаснее.

Удобный пользовательский опыт должен сочетаться с понятными запросами на подпись, продуманной работой получателей разрешения и простым управлением allowance.

Распространенные ошибки при работе с EIP-2612

Одна из распространенных ошибок — считать, что permit сразу переводит токены.

Permit лишь обновляет allowance.

Другая ошибка — считать, что подтверждение без газа означает, что никто не платит за газ.

Для обновления состояния контракта permit по-прежнему нужна ончейн-транзакция.

Третья ошибка — подписывать неограниченные разрешения, не понимая рисков, связанных с получателем.

Четвертая — игнорировать поле срока действия.

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

Шестая — считать, что все токены ERC-20 поддерживают EIP-2612.

Седьмая — интегрировать permit без проверки ID сети, разделителя домена и поведения nonce при развертывании в разных сетях.

Восьмая — считать все похожие на permit системы идентичными EIP-2612.

Девятая — не предусмотреть обработку опережающей отправки permit в комбинированных сценариях смарт-контрактов.

Десятая — отображать запросы permit так, что пользователи не могут их понять.

Рекомендации для пользователей

Подписывайте сообщения permit только на сайтах и в приложениях, которым доверяете.

Перед подписанием проверяйте токен, получателя разрешения, количество и срок действия.

Не выдавайте неограниченные разрешения без веской причины.

По возможности используйте небольшие значения разрешений.

Отзывайте старые allowance, которые больше не нужны.

Не подписывайте permit по случайным ссылкам, сообщениям от поддельной службы поддержки или страницам неизвестных эйрдропов.

Используйте отдельный кошелек для экспериментальных dApp, а другой — для долгосрочного хранения активов.

Внимательно читайте предупреждения кошелька.

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

Помните: до истечения срока действия кто-то другой может отправить подписанный permit.

Рекомендации для разработчиков

По возможности используйте проверенные аудитом и поддерживаемые реализации permit.

Если заявлена поддержка EIP-2612, точно соблюдайте официальный интерфейс стандарта.

Используйте типизированные данные EIP-712, чтобы кошельки могли понятно отображать сведения о подписи.

Корректно реализуйте разделение доменов.

Отслеживайте nonce для каждого адреса владельца.

Отклоняйте подписи с истекшим сроком действия.

Отклоняйте подписи недействительных подписантов и случаи с нулевым адресом владельца.

После успешного обновления allowance генерируйте событие

.

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

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

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

Тестируйте подписи с разными ID сетей, форками, обновлениями и провайдерами кошельков.

Функция Permit в одном предложении

Функция Permit в EIP-2612 позволяет владельцу токенов ERC-20 разрешить расходование токенов с помощью подписи EIP-712 и обновить allowance в блокчейне, не отправляя отдельную транзакцию подтверждения.

FAQ

Что такое функция Permit в EIP-2612?

Функция Permit — это расширение ERC-20, позволяющее владельцу токенов разрешить их расходование с помощью подписи вне блокчейна, которую позднее можно отправить в блокчейн.

Переводит ли permit токены?

Нет. Permit только устанавливает allowance и сам по себе не переводит токены.

Чем полезен EIP-2612?

EIP-2612 упрощает подтверждение доступа, обеспечивает возможность подтверждения без газа для пользователя и позволяет объединять подтверждение с другими действиями смарт-контракта.

Платит ли владелец токенов за газ при использовании permit?

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

В чем разница между approve и permit?

Approve — ончейн-транзакция, отправляемая владельцем токенов; permit — подпись вне блокчейна, которую в блокчейн может отправить другая сторона.

Как EIP-712 связан с permit?

EIP-712 обеспечивает подписание типизированных структурированных данных, благодаря чему кошельки могут понятнее отображать сведения permit, а подписи привязываются к определенному домену.

Что такое nonce в EIP-2612?

Nonce — это значение для каждого владельца, которое не позволяет повторно использовать одну и ту же подпись permit.

Что означает срок действия permit?

Это момент истечения срока, после которого подпись permit больше не должна быть действительной.

Безопасен ли EIP-2612?

EIP-2612 может быть безопасным при правильной реализации и использовании, но пользователям все равно следует остерегаться фишинга подписей, неограниченных разрешений, вредоносных получателей и непонятных запросов кошелька.

Все ли токены ERC-20 поддерживают permit?

Нет. Стандартную функцию Permit поддерживают только токены ERC-20, реализующие расширение EIP-2612.

Может ли подпись permit подвергнуться опережающей отправке?

Да. Любой, у кого есть действительная подпись permit, может отправить ее раньше другой транзакции, поэтому разработчикам следует учитывать такую возможность при проектировании сценариев.

Как пользователям снизить риски permit?

Проверяйте получателя разрешения, ограничивайте одобренное количество, задавайте короткий срок действия, избегайте подозрительных сайтов и отзывайте неиспользуемые allowance.

Заключение

Функция Permit в EIP-2612 — одно из наиболее полезных улучшений процесса подтверждения доступа к токенам ERC-20.

Она позволяет пользователям подтверждать allowance подписью вместо отправки отдельной транзакции.

Это может снизить неудобства, связанные с оплатой газа, упростить подключение к dApp, поддержать сценарии со спонсированием транзакций и облегчить объединение операций с ERC-20 в единый пользовательский процесс.

Для повышения специфичности и безопасности подписанных подтверждений стандарт использует типизированные структурированные данные EIP-712, разделение доменов, nonce и сроки действия.

Однако permit не устраняет базовый риск allowance токенов.

Подписанный permit по-прежнему может предоставить получателю разрешения реальные полномочия распоряжаться токенами пользователя.

Пользователям следует относиться к подписям permit так же серьезно, как к транзакциям подтверждения.

Разработчикам следует тщательно реализовывать стандарт, понятно отображать сведения о подписании и учитывать такие особые случаи, как защита от повторного воспроизведения, истекшие подписи и опережающая отправка permit.

При правильном использовании EIP-2612 упрощает работу с токенами ERC-20, не меняя основной принцип расходования токенов на основе allowance.

Это небольшой, но важный стандарт, который повышает практическое удобство криптоприложений и сохраняет совместимость с более широкой экосистемой ERC-20.