В мире блокчейна пользователи часто должны предоставлять разрешения (разрешения), которые позволяют смарт-контрактам тратить токены от их имени. Например, при использовании децентрализованной биржи (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(получатель, сумма) контракта токена. Это записывает разрешение во внутреннем отображении контракта, обычно выраженном как разрешение[владелец][получатель] = сумма. Например, если пользователь A авторизует контракт Uniswap тратить до 100 токенов, контракт сохранит разрешение[A][Uniswap] = 100. Этот шаг требует ончейн-транзакцию и оплату газа, производимую A.
2. DeleGate.iod Transfer (transferFrom): Позже, когда Uniswap (или другое dApp) должен потратить токены от имени A, он вызывает transferFrom(A, B, amount) в контракте токена. Контракт проверяет, достаточно ли разрешения[A][Uniswap]. Если да, контракт переводит указанную сумму от A к B и вычитает эту сумму из разрешения.

Ограничения и проблемы модели утверждения

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

Нужно две транзакции, плохой пользовательский опыт
Каждый раз, когда пользователь хочет использовать новый токен на dApp, он должен сначала отправить отдельную транзакцию подтверждения, прежде чем он сможет выполнить желаемое действие (например, обмен или стейкинг). Это означает, что их кошелек запросит у них дважды подтверждение и списание дополнительных комиссий за газ. Для новичков этот дополнительный шаг может быть запутанным и неудобным.

Управление фрагментированным утверждением
Когда пользователи взаимодействуют с несколькими dAppsиспользуя тот же токен (например, торговлю на Uniswap, а затем депонирование в другой протокол DeFi), каждому dApp требуется отдельное подтверждение, даже если это один и тот же токен в одном и том же кошельке. Это приводит к повторным подтверждениям, затрачивая время и газ.

Кроме того, поскольку каждое dApp управляет своими разрешениями независимо, у пользователей мало централизованного контроля над своими одобрениями. Некоторые инструменты, такие как Revoke.cashиDeBankПозволяет пользователям просматривать и управлять разрешениями токенов, но многие пользователи не осведомлены об этом. И даже если они осведомлены, отзыв разрешений все равно требует транзакции в цепи, что увеличивает затраты. В результате многие старые или неиспользуемые разрешения просто забыты.

Риски неограниченных подтверждений
Чтобы избежать частых транзакций на подтверждение, многие dApps предлагают пользователям предоставить неограниченное подтверждение, позволяя контракту тратить всю баланс токенов пользователя без ограничения срока действия. Хотя такой подход экономит усилия в дальнейшем, он вносит серьезные риски безопасности: если dApp или контракт подвергнутся взлому, злоумышленник может выкачать все утвержденные токены.

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

Разрешение: Авторизация ERC-20 на основе подписи (EIP-2612)

Концепция Пермит была впервые введенаDAIконтракт стейблкоина и позже стандартизирован как EIP-2612. Коротко говоря, Permit позволяет пользователям авторизовывать передачу токенов с использованием оффчейн-подписей, устраняя необходимость отправки отдельной транзакции approve on-chain. Давайте ближе познакомимся с тем, как это работает и его характерными особенностями.

Как работает разрешение

Разрешение - это механизм авторизации на основе цифровых подписей. Согласно стандарту EIP-2612, контракты токенов ERC-20, поддерживающие Permit, добавляют функцию под названием permit(), которая выглядит следующим образом:

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

Здесь владелец, расходующий и значение указывают, кто дает разрешение, кто получает разрешение и разрешенную сумму. Крайний срок указывает, когда истекает срок действия подписи. Параметры v, r и s образуют ECDSAцифровая подпись. Используя Permit, пользователи обходят отдельное одобрение on-chain - просто подписывают сообщение (не платя Gas) и включают эту подпись в свою транзакцию, чтобы завершить авторизацию за один шаг.

Процесс разрешения

По сравнению с традиционным подтверждением, Permit устраняет необходимость в дополнительной онлайн-транзакции, экономя время и комиссии за газ. Он также обеспечивает тонкую настройку разрешений. Например, пользователь может подписать Permit, позволяющий тратить ровно 50 USDC, действительный только 5 минут. Даже если подпись будет обнаружена, она становится бесполезной после истечения срока, что снижает риски. Сегодня многие DeFi-протоколы, такие как децентрализованные биржи и платформы кредитования, уже поддерживают Permit. Известные примеры включают Uniswap V2/V3LP токены, DAI, иUSDC, которые реализовали стандарт EIP-2612, позволяющий одношаговые согласования на основе подписи.

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

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

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

Permit2: Универсальный контракт управления авторизацией

Поскольку механизм разрешений стал популярным, возникла новая проблема: как расширить удобство авторизации на основе подписи для токенов, которые не поддерживают разрешение? Чтобы решить эту проблему и оптимизировать опыт авторизации в различных сценариях, команда Uniswap представила Permit2 в 2022 году. В отличие от функции, специфичной для токена, Permit2 является автономным умным контрактом управления авторизацией. Он выступает в качестве посредника для авторизации токенов, обеспечивая унифицированную и расширенную функциональность разрешения. Давайте проанализируем принципы и особенности Permit2.

Как работает Permit2

Permit2 функционирует как сервис ретрансляции авторизации. Его основная концепция проста: пользователи предоставляют одноразрешение контракту Permit2, который затем управляет последующими подавторизациями для различных приложений. Вот как это работает:

1. Одноразовая авторизация Permit2: пользователи утверждают Permit2 для каждого маркера с помощью традиционного метода approve(Permit2, max_amount). Рекомендуется большое или неограниченное количество, так как это является основным одобрением. После завершения контракт Permit2 получает возможность вызывать transferFrom от имени пользователя для этого маркера. Для этого требуется транзакция в цепочке, но это нужно сделать только один раз.
2. Подпись вне цепи для подчиненной авторизации: Когда пользователи хотят взаимодействовать с DApp (например, используя Универсальный маршрутизатор Uniswap для многотокеновых обменов), они подписывают сообщение об авторизации вне цепи в соответствии с характеристиками Permit2. Эта подпись включает детали, такие как разрешенный токен, сумма, целевой потребитель (например, конкретный контракт DApp) и время истечения.
3. Запрос на передачу DApp с использованием подписи: Когда DApp получает подпись пользователя и нужно использовать токены, вместо прямого вызова контракта токена он вызывает функции Permit2 (например, permitTransferFrom). Эта функция проверяет данные подписи пользователя и подтверждает, что операция находится в предоставленных разрешениях (токен, сумма, крайний срок). После верификации Permit2 использует свое основное разрешение для вызова transferFrom, перемещая токены от пользователя к указанному получателю. Ключевой момент: сам контракт Permit2 выступает как spender, используя свои полномочия для передачи токенов, с дополнительным шагом проверки подписи.
4. Завершение операции: после успешного выполнения Permit2 средства переходят плавно от пользователя к DApp или указанному адресу. С точки зрения пользователя, он предоставляет только подпись в транзакции, в то время как контракт обрабатывает все последующие действия.

Процесс авторизации Permit2 прост: пользователям нужно предоставить максимальное разрешение для Permit2 только один раз для каждого токена. После этого, взаимодействуя с приложениями (например, Универсальным маршрутизатором Uniswap или другими протоколами), им просто нужно включить подпись 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 включает интерфейсы, такие какpermitWitnessTransferFromпозволяют включать дополнительные данные для верификации в подписях. Это поддерживает более сложные сценарии, такие как включение конкретных деталей транзакции в подписи для предотвращения повторного использования подписи в различных контекстах.

Благодаря этим функциям Permit2 не только воспроизводит все преимущества Permit, но также улучшает гибкость и контроль безопасности. Автоматическое истечение срока действия и одноразовые подписи для передачи, в частности, делают минимальную необходимую авторизацию нормой, снижая долгосрочные риски.

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

Принять и внедрить экосистему Permit2

С тех пор как Uniswap представил Permit2, множество проектов интегрировали этот механизм, ускоряя стандартизацию отрасли. Согласно последним данным из Dune Analytics, на апрель 2025 года более 3,1 миллиона адресов основной сети Ethereum предоставили разрешение на контракт Permit2, что демонстрирует его широкое распространение.

Состояние экосистемы Permit2 и реализации. Источник: Аналитика Dune

Например, Uniswap интегрировал Permit2 в свой Universal Router, позволяя множественные обмены токенов и NFT в одной транзакции. Через Universal Router пользователи могут объединить несколько операций в одной транзакции, такие как обмен трех токенов на два целевых токена и покупка NFT, все требования к авторизации обрабатываются сигнатурами Permit2. Это значительно упрощает процесс и снижает общие затраты на Gas, демонстрируя прямое влияние Permit2 на улучшение пользовательского опыта.

Более того, с открытым развертыванием Permit2 на различных цепочках все больше кошельков и инструментов DApp начали его поддерживать. Инструменты безопасности, такие как Revoke.cash, обновили свои услуги, чтобы позволить пользователям просматривать и отзывать записи разрешений Permit2. Matcha также внедрила модуль SignatureTransfer Permit2, позволяющий механизм "одноразовой авторизации".

Несмотря на этот прогресс, широкое принятие Permit2 сталкивается с вызовами. С одной стороны, разработчикам требуется дополнительное время для интеграции: в сравнении с прямым использованием ERC-20 для утверждения, реализация Permit2 требует обработки логики подписи, что увеличивает накладные расходы на разработку. Это может отпугнуть меньшие команды. С другой стороны, обучение пользователей имеет важное значение: многие DApp, использующие 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 предлагает практическое решение, которое можно внедрить немедленно, в то время как технологии, такие как Session Keys и ERC-4337, указывают на более фундаментальные и долгосрочные улучшения в обработке авторизации.

Риски безопасности, связанные с авторизацией на основе подписей

Как и с любой новой технологией, Permit и Permit2 вносят не только новые эффективности, но и новые риски, особенно в области атак на авторизацию на основе подписи.

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

1. Защита от повторения на основе номера операции

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

2. Соблюдение сроков

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

3. Точный контроль разрешений

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

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

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

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

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

Как происходят атаки фишинга с подделкой подписи?

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

1. Пользователь нажимает на поддельную версию известного веб-сайта DEX (сайт для рыбалки). Когда пользователь пытается взаимодействовать, сайт предлагает запрос на подпись кошелька, утверждая, что это для «подтверждения входа» или других кажущихся законными целей. Однако этот запрос на самом деле является разрешением на подпись Permit2, предоставляющим контракту злоумышленника неограниченное разрешение на вывод USDC жертвы с продленным сроком действия.
2. Потерпевший, лишенный бдительности, подписывает запрос напрямую. На этом этапе газ не тратится и цепная активность не происходит, не оставляя подозрительных следов.
3. Как только злоумышленник получает подпись, он немедленно вызывает функцию разрешения контракта Permit2 для ее отправки. После того как контракт Permit2 проверяет подпись, он регистрирует авторизацию для контракта злоумышленника по адресу жертвы (эквивалентно выполнению жертвой approve, но завершается злоумышленником). Эта операция все еще может остаться незамеченной для жертвы, поскольку их кошелек не показывает расходы - только их отображение разрешения на токены обновляется в блокчейне.
4. Впоследствии злоумышленник немедленно инициирует транзакцию transferFrom(victim, attacker_address, amount) со своего адреса, успешно переводя 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 теперь может преобразовывать общие сообщения о разрешениях в понятный язык. Если ваш кошелек показывает только длинные шестнадцатеричные данные при подписании, рассмотрите возможность переключения или обновления. Пользователям аппаратных кошельков также следует обновлять прошивку, чтобы поддерживать новые форматы, иначе они могут не видеть информацию правильно на экране.

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

Выработайте привычку регулярно проверять статус авторизации вашего адреса с помощью инструментов, таких как Revoke.cash, Etherscan Token Approval или встроенные функции вашего кошелька. Это включает как традиционные разрешения, так и разрешения Permit2. Если вы заметите какие-либо подозрительные или ненужные разрешения, немедленно отозвите их. Что касается разрешения Permit2, будьте внимательны к двум уровням отзыва: первый - основное разрешение (ваше разрешение на контракт Permit2, которое вы можете установить в 0, когда оно не используется); второй - подразрешения (разрешения Permit2 для различных DApps, которые обычно автоматически истекают, но могут быть прекращены досрочно, если у них длительный срок действия). Если у вас есть подозрения, что вы подписали подозрительное разрешение, самое безопасное действие - немедленно настроить значение nonce: подписать новое разрешение тому же тратильщику (даже с разрешением 0), чтобы аннулировать старую подпись, находящуюся в распоряжении злоумышленника.

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

В заключение, важно найти баланс между удобством и безопасностью. Хотя технологии Permit удобны, пользователи должны оставаться бдительными в предотвращении рисков. По мере созревания экосистемы развиваются кошельки и браузерные плагины, обеспечивающие защиту от фишинга подписей, такие как предупреждения о подписях на крупные суммы. Мы стремимся к тому, чтобы в будущем смягчить подобные атаки на Gate.io путем технических и образовательных усовершенствований.

Заключение

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