Почему обычного подключения кошелька недостаточно
Подключение кошелька к сайту само по себе обычно открывает приложению адрес и позволяет запрашивать подписи, но не означает, что пользователь осознанно разрешил любое последующее действие. В привычной модели каждую операцию приходится подтверждать отдельно. Это понятно и контролируемо, однако мешает сценариям, где приложение должно повторять заранее ограниченное действие: например, оплачивать небольшие расходы игрового аккаунта или выполнять серию операций по заданным правилам. ERC-7715 описывает способ запросить у кошелька такие разрешения в стандартизированной форме. Это черновой стандарт Ethereum, а не обязательная функция каждого кошелька или гарантия поддержки всеми приложениями.
Важно различать разрешение на действие и передачу контроля над кошельком. Идея состоит в том, чтобы пользователь заранее обозначил допустимые условия, а кошелёк сам решал, поддерживает ли он этот тип разрешения и как безопасно его представить. Это продолжает разговор о подписях смарт-кошелька ERC-1271 и о управлении token approval. Новая модель не отменяет проверки транзакций и не превращает dApp в доверенную сторону.
Как устроен запрос разрешения
В черновике описан вызов кошелька wallet_requestExecutionPermissions: приложение передаёт массив описаний разрешений, среди которых задаются тип разрешения, правила, целевая сеть и адрес контракта или получателя. Кошелёк может показать пользователю сводку условий, запросить подтверждение, изменить или отклонить набор. Если доступ выдан, приложение получает структурированное описание разрешения и может использовать его в предусмотренном механизме выполнения. Конкретные типы разрешений определяются отдельно, поэтому нельзя считать, что любой кошелёк уже одинаково понимает произвольную структуру из запроса.
Практический смысл стандарта – договориться о форме общения между приложением и кошельком, а не навязать интерфейс. Для разработчика это означает, что запрос должен быть узким и объяснимым: конкретная сеть, конкретный адрес, понятный лимит, срок и назначение. Для пользователя важно увидеть, какое действие покрывает доступ, какие активы или контракты затронуты и как его прекратить. Если интерфейс показывает только длинный JSON или просит без объяснения дать широкое полномочие, безопаснее отказаться и выяснить, что именно запросил сайт.
Где проходит граница между приложением и кошельком
ERC-7715 предполагает, что приложение просит, а кошелёк решает. Именно кошелёк должен проверять поддержку запрошенного типа и применять политику подтверждения. Поэтому разрешение, возвращённое одним кошельком, нельзя автоматически трактовать как доказательство одинаковой реализации в другом. Если кошелёк не поддерживает формат или конкретный тип правила, он может отклонить запрос. Совместимость требует участия и кошелька, и приложения, и компонента, который затем исполняет действие.
В архитектуре также важна связь с исполнением. Одно разрешение – это не универсальный токен доступа, который можно использовать где угодно. Его смысл определяется условиями и механизмом исполнения, а повторное использование должно проверяться контрактной логикой. Черновик ссылается на отдельный стандарт для выполнения действий по выданным разрешениям, поэтому читателю полезно оценивать всю цепочку: кто запросил доступ, где он сохранён, кто проверяет его условия и какой контракт фактически двигает активы. Подобную дисциплину полезно применять и к обычной EVM-операции, разбирая её трассировку и причины revert.
Как читать ограничения, а не только кнопку подтверждения
Перед выдачей доступа проверьте область действия: сеть, контракт, актив, максимальный объём, частоту использования и срок, если эти параметры присутствуют в конкретном типе. Не все ограничения доступны для каждого действия, а формулировки чернового стандарта и реализация кошелька могут меняться. Название приложения не заменяет проверку адреса и параметров. Если запрос просит действие, которое не соответствует сценарию – например, неограниченный объём ради разовой операции, – отмените его. Отдельно оцените, сохраняется ли доступ между сессиями и где в кошельке отображается его отзыв.
Для разработчиков хорошая практика – просить минимально необходимое полномочие и пояснять его обычным языком до вызова кошелька. Не надо полагаться на то, что пользователь разберёт техническую структуру сам. Покажите ожидаемый сценарий, максимально возможный объём и последствия прекращения доступа. Если функция необязательна, оставьте путь ручного подтверждения. Так пользователь может отказаться от автоматизации, не теряя возможности воспользоваться основным продуктом.
Какие риски остаются
Ограниченное разрешение уменьшает число повторных подтверждений, но создаёт новый риск: пользователь может выдать доступ, забыть о нём или неверно понять его границы. Скомпрометированный сайт способен попытаться использовать допустимую область нежелательным способом. Ошибка в контракте исполнения или в правилах проверки может привести к последствиям, которые интерфейс не объясняет. Наконец, стандарт находится в статусе Draft, а поддержка и детали реализации могут отличаться. Перед использованием проверьте актуальную версию документации кошелька, тестируйте новую функцию на малой сумме и не храните в разрешении больше полномочий, чем требует конкретная задача.
Полезно помнить, что привычные проверки остаются важны. Проверяйте домен приложения, адрес контракта, сеть, запрошенный объём и наличие возможности отозвать доступ. Для обычных allowance разрешения важно отдельно понимать, кто является spender и как отменить устаревшее одобрение – этому посвящена инструкция как найти spender и allowance токена. ERC-7715 может сделать пользовательские сценарии удобнее, но не устраняет фишинг, уязвимости кошелька и риск ошибки самого пользователя.
Кому следить за развитием ERC-7715
Разработчикам кошельков стандарт интересен как интерфейс для запрашиваемых разрешений и более гибкого подтверждения действий. Разработчикам dApp – как возможная основа для сценариев, где повторное ручное подписание ухудшает опыт. Пользователям пока стоит воспринимать его как направление развития, а не как включённую по умолчанию функцию. Перед интеграцией нужно проверить статус EIP, актуальную схему, поддерживаемые типы разрешений и механизм исполнения в конкретных кошельках.
Хороший критерий зрелости – не число проектов, которые упоминают ERC-7715, а качество пользовательского объяснения и независимые проверки реализации. Важны конкретные ограничения, ясный список действующих разрешений, простое прекращение доступа и предсказуемое поведение при ошибке. До появления такой практики выдавайте только те разрешения, последствия которых вы можете объяснить своими словами.
