Коротко: owner key обычно означает основной способ управлять смарт-кошельком, а delegated key – дополнительный ключ с ограниченными правами. Однако это не единые термины одного обязательного стандарта: конкретная модель определяется кодом кошелька, валидатором, сессией и настройками пользователя. Делегированный ключ может быть ограничен временем, суммой, приложениями или типами вызовов, но эти ограничения существуют лишь если их реально проверяет контракт. Нельзя считать ключ безопасным только потому, что интерфейс назвал его временным или вторичным.
Как устроено управление смарт-кошельком
Обычный внешний аккаунт Ethereum непосредственно связывает адрес со своей подписью. Смарт-кошелёк может проверять подписи по произвольным правилам: нескольких владельцев, аппаратных ключей, модулей, социальных восстановителей или специальных сессионных разрешений. Поэтому сам адрес кошелька не раскрывает, кто именно вправе отправлять операции. Нужно понимать политику проверки, которая закодирована в аккаунте и его модулях.
Слова owner key и delegated key используются проектами и разработчиками по-разному. В одной системе владелец может быть единственным корнем управления, а делегат – временной подписью для выбранного приложения. В другой owner обозначает только административный ключ, а отдельный validator-модуль разрешает широкий набор подписей. Некоторые кошельки вообще не используют эти термины. Не переносите словарь одного продукта на другой и проверяйте документацию конкретного аккаунта.
Стандарты модульных аккаунтов, например ERC-7579, описывают интерфейсы модулей, включая валидаторы и исполнители, но не устанавливают универсальную семантику «owner» и «delegate». Аналогично, ERC-4337 задаёт инфраструктуру для UserOperation, а правила подписи и проверки могут зависеть от реализации аккаунта. Чтобы лучше понять риск вызовов, изучите разбор транзакции смарт-кошелька и проверку подписи контракта ERC-1271.
Что должен ограничивать delegated key
Делегирование обычно нужно для удобства: приложение может выполнять заранее разрешённые действия без повторного ввода основного ключа. Полезное ограничение должно быть проверяемым и достаточно узким. Например, кошелёк может разрешить делегату обращаться к одному контракту, вызывать конкретные функции, тратить не больше лимита или действовать только до указанного времени. Это уменьшает последствия утечки делегированного секрета, но не отменяет проверку реализации и параметров.
Обратите внимание на адрес назначения и calldata. Разрешение «взаимодействовать с DeFi» слишком широко, если оно допускает произвольный контракт или опасные функции. Даже корректный адрес может обновить прокси-реализацию. Дополнительно проверьте разрешённые токены, максимальную сумму, количество операций, область действия лимита и то, расходуется ли лимит по фактическому результату либо только по вызову. Подпись может открывать разрешение, а дальнейшие операции – менять активы в зависимости от состояния протокола.
Временное ограничение должно использовать время сети и механизм отзыва, а не только обещание интерфейса. Уточните, как считается срок, что случится при задержке транзакции и можно ли отозвать делегата раньше. Если делегирование создано в стороннем модуле, проверьте владельца модуля, его код, аудит и возможность обновления. Попросите интерфейс показать конкретные адреса, функции и лимиты, а не только общий текст «безопасный доступ».
Owner key остаётся критическим полномочием
Основной ключ часто может менять настройки кошелька: добавлять или удалять валидаторы, устанавливать новые модули, менять владельцев, восстанавливать доступ или отзывать делегатов. Из-за этого его компрометация обычно опаснее утечки ограниченного делегата. Но в некоторых аккаунтах административное действие разделено между несколькими владельцами или защищено задержкой. Изучите именно текущую конфигурацию, а не типовое описание продукта.
Не храните основной ключ в том же браузерном профиле и на том же устройстве, где постоянно подключены приложения, если система позволяет разделить роли. Используйте отдельный аппаратный или иначе изолированный ключ для управления, проверяйте сетевые домены и не подписывайте запросы на «повторное подключение», если они на самом деле меняют владельцев или модули. Сначала изучите перечень транзакций. Если кошелёк позволяет установить delay, лимиты вывода или подтверждение несколькими ключами, сравните эти возможности с вашей моделью угроз.
Разделение ролей полезно только при независимости ключей и проверках. Если основной ключ и делегат импортированы из одной резервной фразы на одном заражённом устройстве, риск может почти не измениться. Если делегат имеет право устанавливать модули или бесконтрольно выдавать allowances, ограничение перестаёт быть узким. Убедитесь, что аккаунт не считает делегированную подпись достаточной для изменения своих же правил.
Как проверить разрешение до использования
Начните с безопасного режима чтения: найдите адрес смарт-кошелька в обозревателе, изучите его код и конфигурацию, а затем сопоставьте найденные модули с документацией. Проверьте, какой validator принимает делегированную подпись, как он декодирует параметры и где устанавливается срок действия. Для обновляемого контракта найдите текущую реализацию и роль, которая может заменить её. Если код не верифицирован, не делайте выводы по одному названию модуля.
Затем изучите транзакцию создания делегата. Проверьте, какие полномочия включены, кому они выданы, какие токены доступны, лимиты и срок. Если делегат уже создан, найдите транзакцию отзыва и убедитесь в её успешном выполнении. Состояние интерфейса может запаздывать, поэтому сверяйте onchain-состояние. Разрешения токенов ERC-20 – отдельная часть риска: сессионная подпись и allowance могут сохраняться независимо друг от друга. При ненужном одобрении отзовите его через проверенный контракт, используя руководство по поиску spender и allowance.
Перед первым использованием нового delegated key проведите тест с небольшой суммой на известной сети, если это безопасно и доступно. Сначала проверьте одну разрешённую операцию, затем убедитесь, что запрещённая функция отклоняется. Но тест не доказывает корректность всех ветвей кода, не заменяет аудит и не защищает от последующих обновлений контракта. Повторите проверку после смены сети, модуля, версии приложения или параметров делегирования.
Когда стоит отзывать делегирование
Отзовите ключ, если срок закончился, устройство утрачено, вы больше не используете приложение, адрес модуля изменился или политика аккаунта непонятна. После отправки транзакции дождитесь подтверждения и проверьте, что запись о делегате удалена либо помечена как неактивная. Если интерфейс отзыва недоступен, официальный маршрут может требовать управления через другой интерфейс или прямой контрактный вызов; не используйте непроверенные ссылки из личных сообщений.
В итоге owner key и delegated key – не уровни гарантии сами по себе, а названия разных полномочий. Надёжность определяется проверяемой логикой кошелька, объёмом разрешённых действий, независимостью секретов и возможностью своевременного отзыва. Перед подписью задайте практический вопрос: какой именно код выполнится и какой наибольший ущерб возможен при утечке этого ключа? Если ответ неясен, сократите разрешения или не создавайте делегирование.
