Session key – это дополнительный ключ с ограниченными полномочиями, который смарт-кошелёк может разрешить для определённых действий. До настройки выясните, поддерживает ли конкретный аккаунт такую функцию и какие именно ограничения проверяет его код. Сам термин не гарантирует временный доступ: реализация может требовать ручного отзыва, не поддерживать лимит суммы или разрешать более широкий набор вызовов. Если кошелёк не показывает понятные границы прав и способ отключения, не выдавайте приложению доступ к активам.
Что проверить до создания ключа
Session key отличается от основного ключа владельца. Владелец обычно сохраняет возможность управлять аккаунтом, а сессионный ключ получает узкий набор прав для игры, приложения или повторяющихся действий. В разных smart account это может быть отдельный signer, plugin, validator module или иная логика. ERC-4337 предоставляет инфраструктуру для smart account, но session keys не являются одинаково реализованной универсальной функцией каждого кошелька. Общее устройство аккаунтов и user operation разобрано в статье о ERC-4337.
Откройте официальную документацию именно вашего кошелька и проверьте, какие параметры можно задать: срок окончания, сеть, целевой контракт, методы, токены и максимальный расход. Важна не только подпись ключа, но и то, где исполняются проверки ограничений. Если поле срока отображается в интерфейсе, убедитесь, что код аккаунта действительно применяет его при проверке операции. Для незнакомого модуля проверьте разработчика, адрес и аудит; само наличие в каталоге кошелька не доказывает безопасность.
Определите отдельную цель сессии до подключения. Например, если ключ нужен только для взаимодействия с одной игрой в одной сети, ему не нужны права вызывать произвольные контракты на всех сетях. Для действия, которое не должно переводить средства, проверьте, можно ли полностью запретить transfer и approve. Если приложение требует разрешение на неограниченный перевод токена, это не узкий session key, даже если подпись называется временной.
Порядок настройки в совместимом кошельке
- Проверьте сеть, адрес смарт-аккаунта и официальный адрес приложения. Не открывайте страницу подключения из случайного рекламного сообщения.
- Найдите раздел управления сессионными ключами, делегированием или разрешениями. Названия и расположение отличаются у разных кошельков.
- Создайте новый отдельный ключ или выберите предусмотренный приложением signer. Не используйте seed-фразу основного кошелька для генерации сессионного ключа.
- Выберите минимальный срок, одну необходимую сеть и конкретный контракт или набор методов, если эти ограничения поддерживаются.
- Задайте наименьший полезный лимит расходов и запретите вызовы, без которых сценарий работает.
- До подтверждения прочитайте подпись и проверьте адрес аккаунта, модуль, целевой контракт и срок. Если интерфейс не показывает параметры, остановитесь.
- Подтвердите выдачу прав основным способом подтверждения smart account и дождитесь включения операции.
- Проведите небольшой тест разрешённого действия, затем проверьте, что запрещённое действие блокируется, если интерфейс кошелька позволяет такую проверку.
Смарт-кошелёк может объединить включение модуля и другие вызовы в одну операцию. Поэтому просмотрите всё содержимое пакетного запроса, а не только его заголовок. Симуляция показывает ожидаемый результат при конкретном состоянии, но не заменяет проверку после включения и не гарантирует отсутствие изменений до исполнения. Порядок проверки состояния и квитанции описан в материале о receipt транзакции.
Как сузить полномочия
Практическое правило – ограничивать каждый измеримый параметр отдельно. Срок действия отвечает на вопрос, когда разрешение перестаёт работать. Список контрактов ограничивает, с кем взаимодействует ключ. Перечень методов ограничивает возможные вызовы. Максимальная сумма или лимит на период уменьшает возможный ущерб. Список токенов и сеть не дают приложению автоматически распространить разрешение на другие активы и цепочки. Не каждая реализация поддерживает все эти поля.
Если кошелёк предлагает только постоянное делегирование, считайте его действующим до явного отзыва. Если разрешённые функции описаны абстрактно, не выводите из этого конкретный предел. Ограничения могут быть реализованы сторонним модулем, поэтому проверьте, кто может его обновить и отключить. В модели Safe модули способны исполнять операции от имени аккаунта и требуют такой же осторожности, как остальные ключевые компоненты.
Выдачу session key не следует путать с одобрением токена. Token allowance может сохраниться после завершения сессии, если только его не ограничили или не отозвали отдельной транзакцией. Аналогично, отмена ключа не всегда удаляет все выданные контрактам разрешения. Пересмотрите allowances и модульные разрешения отдельно, а затем убедитесь, что код и сеть совпадают с тем, что вы ожидаете.
Как проверить и отозвать доступ
После включения найдите запись о signer, сроке и модуле в самом аккаунте или в обозревателе. Сравните событие с адресом, который кошелёк показывал до подтверждения. Проверьте, что действие разрешённого типа проходит только от указанного аккаунта, а произвольный адрес или другой метод не получает доступа. Для теста используйте минимальную сумму и не храните крупный баланс в аккаунте только потому, что приложение работает без повторных подтверждений.
Когда задача завершена, откройте управление ключами и выполните штатную операцию отзыва или отключения модуля. Если функция не отключается автоматически по истечении срока, не ждите автоматического сброса. Дождитесь подтверждения транзакции, повторно проверьте список активных ключей и удалите локальный ключ из ненужной среды. При потере устройства или подозрительной активности сначала отключите делегирование и отдельные approvals, затем проверьте недавние вызовы контракта.
Ведите список выданных разрешений: приложение, сеть, адрес аккаунта, параметры, дата включения и дата отзыва. Это помогает не забыть долгоживущий ключ. Не включайте в заметку секретную часть ключа. Если нужно разобраться в адресе целевого контракта или разрешённом вызове, проверяйте его сеть и chain ID – подробнее об этом написано в статье о Chain ID и разделении сетей.
Типовые ошибки
- Считать session key стандартом с одинаковым поведением во всех кошельках.
- Выдавать права на любой контракт ради одного действия в dApp.
- Путать срок действия с автоматической отменой всех разрешений.
- Подтверждать несколько вызовов в пакете, не просмотрев каждый адрес.
- Оставлять большой баланс на аккаунте без необходимости.
- Не сохранять подтверждение включения и отзыва для последующей проверки.
Session key удобен, если его возможности действительно меньше полномочий основного владельца, а пользователь может увидеть и отозвать эти возможности. Настройка имеет смысл только после проверки реализации конкретного смарт-кошелька; если ограничения непрозрачны, безопаснее продолжать подтверждать действия вручную.
