---
title: "Безопасна ли подпись делегирования в управлении?"
description: "Узнайте, что разрешает подпись делегирования в управлении, как разделение доменов EIP-712, одноразовые номера и срок действия снижают риск повторного использования и что проверить перед подписанием."
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.
# Безопасна ли подпись делегирования в управлении?
> Материал предназначен только для образовательных целей и не является инвестиционной рекомендацией. Транзакции и подписи с цифровыми активами могут привести к необратимым потерям.
## Краткий ответ
Подпись делегирования в управлении безопасна только тогда, когда расшифрованное сообщение точно соответствует задуманному вами делегированию, а управляющий контракт обеспечивает достаточную защиту от повторного использования. В типичной модели токена для голосования делегирование меняет того, кто может распоряжаться голосами подписанта; оно **не** переводит баланс токенов и не дает разрешения расходовать токены. Однако окончательно действие подписи определяется развернутым контрактом.
Подпись, созданную вне блокчейна, может отправить ретранслятор, поэтому подписант может не платить газ, но при этом разрешить изменение состояния в блокчейне. Относитесь к подписи как к исполняемой инструкции, а не как к входу в систему или безобидному запросу на подключение кошелька.
## Как это работает
Обычный процесс `delegateBySig` состоит из четырех шагов:
1. Приложение подготавливает типизированные данные EIP-712 с адресом делегата, одноразовым номером и сроком действия.
2. Кошелек подписывает дайджест, связанный с типизированным сообщением и доменом EIP-712.
3. Любая учетная запись может передать подпись контракту токена или управления.
4. Контракт восстанавливает или проверяет подписанта, сверяет одноразовый номер и срок действия и записывает нового делегата.
Домен EIP-712 может включать поля `name`, `version`, `chainId` и `verifyingContract`. Эти поля разграничивают в остальном одинаковые сообщения между приложениями, версиями, сетями и контрактами. Сам EIP-712 прямо **не** обеспечивает защиту от повторного использования: контракт должен израсходовать одноразовый номер или иным способом сделать каждое разрешение одноразовым, а срок действия ограничивает временное окно только в том случае, если контракт действительно его проверяет.
Перед подписанием проверьте все перечисленное ниже через официальный интерфейс управления, документацию или независимо подтвержденные данные контракта:
- `primaryType` и названия полей должны описывать делегирование, а не разрешение, перевод токенов, ордер или полномочия на управление учетной записью.
- `verifyingContract` должен быть нужным контрактом токена или управления в активной сети `chainId`.
- `delegatee` должен совпадать с адресом выбранного вами представителя; проверяйте адрес целиком, а не отображаемое имя.
- `nonce` должен совпадать с текущим одноразовым номером подписанта в контракте, а `expiry` должен быть достаточно коротким для задуманной операции.
- Кошелек должен показывать типизированные данные целиком. Отклоняйте запросы на слепую подпись и необработанные хеши, смысл которых вы не можете независимо воспроизвести.
Реализации различаются. Например, контракт COMP от Compound хеширует делегата, одноразовый номер и срок действия, требует совпадения номера с сохраненным номером подписанта, увеличивает его и отклоняет просроченную подпись. Интерфейс `Votes` от OpenZeppelin также предоставляет `delegateBySig`, работу с одноразовыми номерами и проверку срока действия. Не предполагайте, что одноименная функция в другом контракте имеет те же средства защиты.
## Пример
Мира хочет делегировать 10,000 голосов адресу `0xAB...1234`. Ее кошелек показывает `primaryType: Delegation`, проверенный контракт токена для голосования, идентификатор активной сети, `delegatee: 0xAB...1234`, текущий одноразовый номер и срок действия через 20 минут. Сверив адрес со вторым надежным источником, она подписывает сообщение; ретранслятор отправляет его, и контракт создает событие делегирования. Баланс токенов остается в ее кошельке, а представитель получает соответствующие голоса по правилам этого протокола.
Теперь изменим одну деталь: страница запрашивает `primaryType: Permit` и указывает получателя разрешения на расходование токенов либо `verifyingContract` оказывается посторонним контрактом. Это уже не та же инструкция делегирования. Она может разрешить расходование токенов, даже если кнопка на странице подписана «Делегировать», а подписант не платит газ. Мире следует отклонить запрос.
## Риски и меры защиты
- **Неверный делегат:** отравление адресов, личные сообщения и скопированные отображаемые имена могут подменить `delegatee` адресом злоумышленника. Проверьте полный адрес в официальном предложении или профиле делегата.
- **Неверное действие:** вредоносный интерфейс может запросить другой тип EIP-712, например разрешение. Прочитайте `primaryType`, каждое поле и проверяющий контракт; надпись на кнопке не обеспечивает безопасности.
- **Повторное использование:** слабая или отсутствующая проверка одноразового номера может позволить использовать подпись снова. Домен без привязки к нужной сети или контракту также может допустить использование в непредусмотренном контексте. Проверяйте фактический код верификации: EIP-712 сам по себе не защищает от повторного использования.
- **Долгоживущая подпись:** неиспользованное подписанное сообщение может оставаться исполнимым, пока не истечет срок его действия или не станет недействительным одноразовый номер. Выбирайте короткий срок, не публикуйте подпись и при необходимости отмены используйте только документированный протоколом способ аннулирования.
- **Обманчивое отображение в кошельке:** усеченные поля, неизвестный домен или слепая подпись не позволяют дать осознанное согласие. Отмените операцию и изучите запрос типизированных данных в кошельке или декодере, который показывает сообщение целиком.
- **Особенности контрактных учетных записей:** кошельки-смарт-контракты могут проверять подписи через ERC-1271, где действительность зависит от состояния кошелька и политики полномочий. Убедитесь, что эту схему поддерживают и кошелек, и управляющий контракт, а не рассчитывайте на восстановление адреса как для внешней учетной записи.
- **Последствия для управления:** делегирование может сконцентрировать голоса или позволить ненадежному делегату голосовать против ваших интересов. Изучите личность делегата, историю голосований, конфликты интересов и порядок переделегирования в протоколе.
После отправки проверьте транзакцию в правильной сети: контракт назначения, декодированную функцию, восстановленного подписанта или подписанта из события, нового делегата и одноразовый номер. Успешная транзакция ретранслятора доказывает только то, что контракт принял вызов; она не доказывает безопасность подписанного намерения.
Если вы подписали сообщение, но еще не видите его отправки, прекратите делиться подписью и обратитесь к документированному протоколом способу отмены или аннулирования одноразового номера. Если нежелательное делегирование уже выполнено, переделегируйте голоса через официальный контракт и проверьте новое состояние. Само делегирование обычно не создает разрешение на расходование токенов, поэтому не путайте переделегирование с отзывом разрешений. Если вы также подписали разрешение либо раскрыли сид-фразу или закрытый ключ, рассматривайте это как отдельный, более серьезный инцидент с кошельком.
## Распространенные заблуждения
- **«Нет газа — нет полномочий».** Ретранслятор может оплатить газ, а подпись при этом предоставляет полномочия подписанта.
- **«EIP-712 делает любую подпись безопасной».** Стандарт унифицирует хеширование типизированных данных и разделение доменов, но не включает защиту от повторного использования и не может подтвердить, что пользователь действительно намеревался выполнить показанное действие.
- **«Делегирование переводит мои токены».** Обычное делегирование голоса передает или назначает голоса, а не право собственности на токены, но фактический результат определяют только развернутый контракт и расшифрованное сообщение.
- **«Я всегда могу отозвать подпись вне блокчейна».** Универсальной транзакции отзыва подписи не существует. Срок действия, расходование или аннулирование одноразового номера и переделегирование зависят от конкретного контракта.
- **«Смена делегата стирает прежние голоса».** Переделегирование меняет текущие или будущие голоса по правилам протокола; оно может не отменить уже отданные голоса и не изменить исторические снимки состояния.
## Связанные темы
- [Структурированная подпись EIP-712](/ru/crypto/eip712-typed-signature/)
- [DAO](/ru/crypto/dao/)
- [Атака на управление](/ru/crypto/governance-attack/)
- [Разрешения кошелька](/ru/crypto/wallet-approval/)
- [Подпись кошелька](/ru/crypto/wallet-signature/)
## Источники
- [EIP-712: хеширование и подписание типизированных структурированных данных](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (дата обращения: 2026-08-20)
- [Comp.sol](https://github.com/compound-finance/compound-protocol/blob/master/contracts/Governance/Comp.sol) - Compound Finance (дата обращения: 2026-08-20)
- [API управления](https://docs.openzeppelin.com/contracts/5.x/api/governance) - OpenZeppelin (дата обращения: 2026-08-20)
- [ERC-1271: стандартный метод проверки подписей для контрактов](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (дата обращения: 2026-08-20)
Source: https://wiki.fcontext.com/ru/crypto/governance-delegation-signature-risk/index.mdx