---
title: "Кошелек с сеансовым ключом"
description: "Узнайте, как сеансовые ключи смарт-аккаунтов делегируют ограниченные полномочия, какие ограничения необходимо применять и как проверить, отозвать и обезвредить скомпрометированный ключ."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Кошелек с сеансовым ключом
> Материал предназначен только для обучения и не является инвестиционной рекомендацией. Утечка сеансового ключа или избыточные полномочия могут привести к необратимой потере цифровых активов.
## Краткий ответ
Сеансовый ключ кошелька обычно представляет собой дополнительный ключ подписи либо связанную с ним делегированную учетную запись, которую смарт-аккаунт принимает только по заданным правилам. Правила могут ограничивать время, целевые контракты, селекторы функций, суммы токенов, число транзакций и другие условия. Цель состоит в том, чтобы приложение могло повторять действия без подтверждения каждой операции владельцем с помощью основного подписанта.
«Сеансовый ключ» — это архитектурный шаблон, а не единый стандарт Ethereum. ERC-4337 предоставляет программируемую проверку аккаунта и ограниченную по времени проверку `UserOperation`, а модульные системы вроде ERC-7579 могут подключать валидаторы, исполнители и хуки. Возможности ключа в итоге определяет развернутый код аккаунта и модулей. Одного срока действия недостаточно для безопасности, а удаление копии из браузера не обязательно отзывает полномочие, зарегистрированное в сети или содержащееся в действующей делегации.
## Как это работает
Типичный процесс состоит из 5 этапов:
1. Владелец создает новую пару ключей на устройстве либо разрешает учетные данные, идентифицирующие сеансового подписанта. Закрытый сеансовый ключ нельзя отправлять серверу приложения, если только архитектура явно не назначает сервер доверенным хранителем.
2. Владелец основным кошельком утверждает политику. Одни системы устанавливают ключ и политику в сети; другие используют подписанную делегацию, которую аккаунт проверяет при поступлении операции.
3. Приложение формирует операцию и подписывает ее сеансовым ключом. В потоке ERC-4337 логика `validateUserOp` проверяет подпись и политику; симуляция бандлера — это проверка допуска, а не доказательство исполнения или безопасности.
4. Аккаунт обязан применить все ограничения до исполнения. Эффективные полномочия можно записать как `A_effective = K ∩ P ∩ S`: владение ключом (`K`), настроенная политика (`P`) и текущее состояние аккаунта или сети (`S`) должны одновременно разрешать действие.
5. Сеанс завершается по сроку, после исчерпания nonce или квоты, явного отзыва, удаления модуля либо иным способом, заданным реализацией. Проверьте итоговое состояние аккаунта в нужной сети.
До разрешения сеанса проверьте:
- ID сети, адрес смарт-аккаунта, реализацию аккаунта и адрес валидатора или модуля;
- открытый сеансовый ключ или идентификатор учетных данных и место хранения закрытого материала;
- каждую разрешенную цель, селектор функции, токен и правило получателя, лимит нативной стоимости и предел на вызов или суммарно;
- `validAfter`, `validUntil`, правила nonce, число использований и источник времени: отметку блока или иной источник;
- заблокированы ли без явной необходимости пакеты, вложенные вызовы, `delegatecall`, одобрения токенов, установка модулей, обновления аккаунта и подписи сообщений ERC-1271;
- кто может отозвать сеанс, сохраняется ли у владельца независимый путь восстановления и нужны ли для отзыва Gas либо работающий бандлер или paymaster.
Политика должна проверять реально исполняемое действие. Проверка только внешней цели пакета может оставить внутренние вызовы без ограничений; проверка только получателя без функции и суммы создает ту же проблему. Лимит имеет смысл лишь тогда, когда применяющий его код охватывает каждый путь исполнения.
## Пример
Игровой кошелек создает сеанс на 24 часа. Разрешены вызовы только проверенного игрового контракта, запрещены `delegatecall` и одобрения токенов, нативная стоимость ограничена `0.02 ETH` на вызов, а общие расходы — `20 USDC`. Игра может отправлять разрешенные ходы без повторных подтверждений, но запрос на перевод постороннего NFT должен не пройти проверку.
Перед использованием владелец записывает аккаунт, сеть, модуль, открытый сеансовый ключ, срок, лимиты и способ отзыва. Он проверяет одну операцию малой стоимости, декодированный вызов и событие аккаунта, а затем отдельно тестирует отзыв. Это подтверждает настроенный путь, но не доказывает отсутствие уязвимости модуля или невозможность потратить остаток лимитов со взломанного устройства.
## Риски и меры контроля
- **Слишком широкая политика:** шаблонные цели, неограниченные селекторы, безлимитные одобрения, пакеты или `delegatecall` могут дать «ограниченному» ключу почти права владельца. Используйте явные белые списки и запрещайте административные действия.
- **Кража ключа:** хранилище браузера, журналы, резервные копии, расширения, вредоносное ПО и общие устройства могут раскрыть ключ. При поддержке выбирайте аппаратно защищенное или изолированное хранение, короткий срок и низкие суммарные лимиты.
- **Ошибка применения:** аккаунт, валидатор, исполнитель или хук может неверно декодировать вызов либо пропустить иной путь. Используйте проверенные развертывания, рецензированный код, аудиты и тесты обхода.
- **Повтор и смешение контекста:** слабая обработка nonce или отсутствие привязки к нужной сети, аккаунту, модулю либо политике позволяет повторное использование. Проверяйте точный домен подписи и сетевую защиту от повтора.
- **Ошибки о сроке:** `validUntil` может ограничить одну операцию ERC-4337, не удаляя автоматически зарегистрированный ключ, одобрение токена или другую делегацию. После срока проверяйте фактическое состояние каждого разрешения.
- **Неудачный отзыв:** удаление локальных данных убирает лишь одну копию секрета. Отзывайте по документированному пути и проверяйте результат в сети; сохраняйте достаточно Gas и резервный путь под контролем владельца.
- **Обновляемые или вредоносные модули:** они могут иметь широкие права исполнения, а обновления — менять политику. Проверьте владельцев, задержку обновления, права паузы, адрес реализации и процедуру удаления.
- **Злоупотребление Gas и спонсированием:** сеанс может тратить средства аккаунта на Gas или перестать работать при отказе paymaster. По возможности ограничьте комиссии и сохраните независимый путь отправки.
При возможной утечке прекратите пользоваться приложением, сохраните идентификатор сеанса и важные хеши, затем отзовите или отключите ключ с чистого устройства владельца. Проверьте ожидающие и недавние операции, одобрения, установленные модули, обновления и балансы во всех поддерживаемых сетях. Перемещайте остаток активов лишь тогда, когда архитектура не позволяет надежно отозвать доступ; поспешный переход на непроверенный сайт «восстановления» может увеличить ущерб.
## Распространенные заблуждения
- **«Сеансовый ключ не может перемещать активы».** Он выполняет любые разрешенные политикой действия, включая переводы, обмены, одобрения и подписи.
- **«ERC-4337 определяет права сеансовых ключей».** ERC-4337 дает среду проверки и исполнения; политика зависит от кошелька или модуля.
- **«Короткий срок ограничивает максимальный убыток».** Убыток зависит также от разовых и суммарных лимитов, частоты, Gas, одобрений, цен и всех доступных путей.
- **«Выход из приложения отзывает ключ».** Он может удалить локальную копию, но не доказывает недействительность сетевой регистрации или подписанной делегации.
- **«Успешная симуляция означает безопасность».** Она может показать текущее принятие, но не доказывает намерение, будущее включение, исполнение, финальность или отсутствие уязвимостей.
## Связанные темы
- [Абстракция аккаунта](/ru/crypto/account-abstraction/)
- [Риск Paymaster в ERC-4337](/ru/crypto/erc4337-paymaster-risk/)
- [Управление закрытыми ключами](/ru/crypto/private-key-management/)
- [Симуляция транзакций](/ru/crypto/transaction-simulation/)
- [Подпись кошелька](/ru/crypto/wallet-signature/)
## Источники
- [Session Keys & Delegation](https://docs.erc4337.io/smart-accounts/session-keys-and-delegation.html) - ERC-4337 Documentation (дата обращения: 2026-08-21)
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals (дата обращения: 2026-08-21)
- [ERC-7579: Minimal Modular Smart Accounts](https://eips.ethereum.org/EIPS/eip-7579) - Ethereum Improvement Proposals (дата обращения: 2026-08-21)
- [Safe Modules](https://docs.safe.global/advanced/smart-account-modules) - Safe Docs (дата обращения: 2026-08-21)
Source: https://wiki.fcontext.com/ru/crypto/session-key-wallet/index.mdx