Перейти к содержанию
Financial Context Wiki

Безопасна ли подпись делегирования в управлении?

Узнайте, что разрешает подпись делегирования в управлении, как разделение доменов EIP-712, одноразовые номера и срок действия снижают риск повторного использования и что проверить перед подписанием.

Обновлено

Материал предназначен только для образовательных целей и не является инвестиционной рекомендацией. Транзакции и подписи с цифровыми активами могут привести к необратимым потерям.

Краткий ответ

Подпись делегирования в управлении безопасна только тогда, когда расшифрованное сообщение точно соответствует задуманному вами делегированию, а управляющий контракт обеспечивает достаточную защиту от повторного использования. В типичной модели токена для голосования делегирование меняет того, кто может распоряжаться голосами подписанта; оно не переводит баланс токенов и не дает разрешения расходовать токены. Однако окончательно действие подписи определяется развернутым контрактом.

Подпись, созданную вне блокчейна, может отправить ретранслятор, поэтому подписант может не платить газ, но при этом разрешить изменение состояния в блокчейне. Относитесь к подписи как к исполняемой инструкции, а не как к входу в систему или безобидному запросу на подключение кошелька.

Как это работает

Обычный процесс 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 делает любую подпись безопасной». Стандарт унифицирует хеширование типизированных данных и разделение доменов, но не включает защиту от повторного использования и не может подтвердить, что пользователь действительно намеревался выполнить показанное действие.
  • «Делегирование переводит мои токены». Обычное делегирование голоса передает или назначает голоса, а не право собственности на токены, но фактический результат определяют только развернутый контракт и расшифрованное сообщение.
  • «Я всегда могу отозвать подпись вне блокчейна». Универсальной транзакции отзыва подписи не существует. Срок действия, расходование или аннулирование одноразового номера и переделегирование зависят от конкретного контракта.
  • «Смена делегата стирает прежние голоса». Переделегирование меняет текущие или будущие голоса по правилам протокола; оно может не отменить уже отданные голоса и не изменить исторические снимки состояния.

Связанные темы

Источники

Навигация

Поиск по вики...