Что такое Delegation Toolkit и что с его помощью можно создать?

Управление аккаунтами в Ethereum традиционно было жёстко ограничено. Externally Owned Accounts (EOA) просты и широко распространены, однако имеют существенные ограничения по функциональности. Smart Contract Accounts (SCA) предлагают значительно большую гибкость, но до недавнего времени не могли работать самостоятельно. Для инициирования и оплаты каждой транзакции по-прежнему требовался EOA.

Ситуацию изменил ERC-4337: теперь SCA нативно поддерживают такие возможности, как спонсирование газа, пакетирование транзакций (объединение нескольких транзакций в одну), session keys и chain abstraction, что обеспечивает более высокий уровень безопасности, гибкости и контроля со стороны пользователя.

Тем не менее EOA никуда не исчезли — и на то есть веские причины: далеко не каждому пользователю нужен аккаунт с поддержкой произвольной логики верификации. Зачем переходить на SCA прямо сейчас?

Но тогда как гарантировать, что когда пользователи будут готовы к переходу — или захотят временно воспользоваться одной или несколькими функциями аккаунта ERC-4337 — им не придётся создавать новый тип аккаунта с нуля? Как дать EOA возможность задействовать функции SCA для конкретных транзакций, не отказываясь от привычной конфигурации?

Именно здесь в игру вступает EIP-7702 (Set-EOA-account-code).

В рамках предстоящего обновления Pectra EIP-7702 позволит EOA временно вести себя как SCA, делегируя управление коду смарт-контракта, который выполняется непосредственно с их адресов. Это означает, что пользователям не придётся мигрировать на новые аккаунты ради доступа к расширенным функциям. Решение обеспечивает обратную совместимость и одновременно продвигает Ethereum вперёд.

Несмотря на эти улучшения, для достижения полноценного опыта, сопоставимого с web2, остаётся один важный нерешённый вопрос в области UX. Речь идёт о гибкой и детализированной системе разрешений, при которой пользователь может легко передать другому пользователю право совершать определённые действия от его имени. Это реализуется контролируемым образом — с чёткими ограничениями и возможностью отзыва разрешений при необходимости.

Именно эту задачу призван решить Delegation Toolkit. Но прежде чем разобраться, что это такое и как работает, давайте подробнее рассмотрим два ERC, которые движут следующим этапом развития UX аккаунтов Ethereum.

ERC 7710: делегирование смарт-контрактов

ERC-7710 — это предложение по стандартизации механизма делегирования конкретных разрешений от аккаунтов смарт-контрактов другим аккаунтам Ethereum. Оно вводит общий интерфейс, позволяющий делегаторам предоставлять полномочия делегатам на основе чётких и исполнимых правил.

С помощью ERC-7710 разработчики могут создавать системы, в которых один аккаунт безопасно разрешает другому действовать от своего имени при определённых условиях — например, с ограничениями по сумме расходов, временными ограничениями или разрешениями для конкретных задач. Всё это реализуется через безопасный и предсказуемый процесс делегирования.

Что же означает «делегирование» в данном контексте?

На высоком уровне речь идёт о разделении владения аккаунтом и его исполнения. Делегатор по-прежнему владеет активами или логикой, но может временно или постоянно передать конкретные полномочия другому лицу, не утрачивая полного контроля.

С точки зрения сети ERC-7710 привносит ясность и компонуемость в механизм передачи разрешений между аккаунтами. Вместо того чтобы каждое приложение реализовывало собственную логику делегирования, теперь существует общая основа, на которой могут строиться контракты и инструменты.

ERC 7715: запрос разрешений у кошельков

ERC-7715 — это предложение по упрощению механизма запроса разрешений dapp'ами у пользовательских кошельков. Оно вводит модель разрешений, позволяющую dapp'ам запрашивать чётко ограниченный, предварительно одобренный доступ к аккаунту пользователя без необходимости повторного подтверждения при каждом взаимодействии.

Сегодня типичный процесс взаимодействия неудобен: dapp запрашивает отправку транзакции или взаимодействие с контрактом, а кошелёк каждый раз запрашивает подтверждение у пользователя. Нет возможности задать лимиты, сроки действия или ограничить область действий dapp'а, а также нет стандартного способа для пользователей просматривать или отзывать эти одобрения в дальнейшем.

ERC-7715 меняет это. Он вводит новый метод — wallet_grantPermissions, — который позволяет dapp'у заранее запросить конкретные возможности. Например, он может запросить разрешение потратить до 10 USDC в течение следующего часа или взаимодействовать с одним смарт-контрактом в течение нескольких следующих сессий. Пользователь заранее ознакомится с этим запросом и одобрит или отклонит его с полным пониманием ситуации.

С точки зрения dapp'а это упрощает онбординг и открывает возможность для сессионных или автоматизированных сценариев, которые не прерывают пользователя на каждом шагу. Для кошельков это обеспечивает чистую и прозрачную структуру управления разрешениями и контроля над выданными правами. Для пользователей — лучшую видимость, больший контроль и меньше раздражающих всплывающих окон, и всё это без ущерба для безопасности.

Итак, что разработчики могут создавать с помощью этих стандартов?

Вот некоторые возможности, которые открываются при совместном использовании ERC-7710 и ERC-7715:

• Установка дневных лимитов расходов из защищённого кошелька: с помощью ERC-7710 делегируется фиксированный лимит более часто используемому кошельку, при этом основная часть средств остаётся в безопасности в офлайн-режиме.

• Упрощение онбординга: пользователи могут выполнять такие действия, как минтинг или получение наград, без предварительной настройки кошелька или подтверждения транзакций — с помощью предварительно ограниченных делегирований, автоматически предоставляющих ограниченные разрешения.

• Торговля через AI-агентов от вашего имени: назначение ограниченных прав на исполнение через ERC-7710, при этом ERC-7715 упрощает одобрение этих разрешений через ваш кошелёк.

• Покрытие комиссий за газ для пользователей dapp'ом: назначение прав спонсирования SCA с использованием делегирования ERC-7710, что позволяет проводить конкретные транзакции без необходимости иметь ETH у пользователя.

• Безопасный отзыв одобрений токенов: делегирование разрешения вспомогательному контракту, который вызывает approve(0) от вашего имени, с использованием ERC-7710 для жёсткого ограничения его возможностей и обеспечения совместимости с любым стандартным токеном ERC-20.

И многое другое.

Что такое Delegation Toolkit

Проще всего описать Delegation Toolkit как набор инструментов, включающий два основных пакета:

1. Delegation Core SDK — пакет, позволяющий разработчикам создавать совместимые с ERC-4337 аккаунты смарт-контрактов (аккаунты-делегаторы), которые используют все возможности, введённые абстракцией аккаунтов ERC-4337.

2. Delegation Framework — система, позволяющая аккаунтам смарт-контрактов делегировать разрешения другим аккаунтам Ethereum через стандарт ERC-7710, а также дающая возможность веб-сайтам, dapp'ам или в перспективе любым сущностям запрашивать разрешения у вашего аккаунта через ERC-7715 (скоро).

Иными словами, Delegation Toolkit позволяет создавать dapp'ы с поддержкой аккаунтов смарт-контрактов ERC-4337 (SCA), делегировать разрешения другим SCA или EOA, а также давать dapp'ам возможность запрашивать эти разрешения — как у смарт-аккаунтов, так и, после обновления Pectra, у EOA.

Если вы знакомы с принципами работы аккаунтов смарт-контрактов, вы уже знаете, чего ожидать от пакета Delegation Core VIEM. Если нет — ознакомьтесь с официальной документацией для более глубокого погружения. В оставшейся части статьи мы сосредоточимся непосредственно на Delegation Framework и выделим ключевые принципы, которые делают его таким мощным инструментом.

Офчейн-делегирование

Делегирования не обязаны существовать в блокчейне, чтобы быть действительными. После того как аккаунт A подписывает делегирование для аккаунта B, оно может храниться где угодно — в IPFS, кэше браузера, облачном хранилище или даже локально, — поскольку оно криптографически защищено и может быть использовано только предполагаемым делегатом. Это делает всю систему более масштабируемой и гибкой.

Например, B может получить подписанное делегирование при необходимости и использовать его в транзакции без какого-либо хранения в блокчейне или предварительных затрат на газ.

Отзываемые разрешения

Делегирования не являются бессрочными. Исходный делегатор — например, аккаунт A — может отозвать любое активное делегирование, которое он выдал, даже если оно уже было передано дальше через транзитивное делегирование (см. раздел о транзитивном или цепочечном делегировании ниже). После отзыва менеджер делегирований будет отклонять любые попытки его использования, включая все суб-делегирования, зависящие от него. Это критически важно для безопасности.

Если аккаунт A подозревает компрометацию или хочет обновить разрешения, он может мгновенно отрезать доступ, делая всю цепочку доверия недействительной. Это как возможность в любой момент «выдернуть вилку из розетки», не отслеживая всех причастных.

Ограниченные делегирования

В Delegation Toolkit делегирования, как правило, привязаны к конкретному делегату. Это означает, что если аккаунт A подписывает делегирование для аккаунта B, только B может его использовать. Даже если кто-то другой получит подписанное делегирование, оно будет для него бесполезным, поскольку криптографически привязано к B.

Однако существует также поддержка открытых делегирований. Это делегирования, которые не указывают делегата заранее и могут быть использованы любым аккаунтом. Открытые делегирования полезны, когда делегат ещё неизвестен, однако их следует использовать с осторожностью во избежание злоупотреблений. Создать такое делегирование можно, установив в поле delegate специальную константу ANY_BENEFICIARY (0x0000000000000000000000000000000000000a11).

Если аккаунт B впоследствии захочет передать ограниченное разрешение аккаунту C, он должен явно создать новое делегирование от B к C. Это гарантирует, что границы разрешений остаются чёткими и намеренными, даже при использовании открытых или транзитивных схем.

Caveats

Caveats — это правила, определяющие порядок использования делегирования. Думайте о них как о пользовательских условиях, которые делегатор может прикрепить к делегированию. Например, если аккаунт A делегирует полномочия аккаунту B, он может включить caveat, указывающий, что B вправе переводить не более 1 ETH или взаимодействовать только с конкретным контрактом в течение следующих 24 часов.

Caveats применяются во время выполнения с помощью специальных контрактов-исполнителей caveat enforcer, которые проверяют соблюдение правил перед выполнением любого действия. Таким образом, даже если B имеет право действовать, он всё равно работает в чётко определённых рамках, установленных A. Полный список поддерживаемых caveats доступен здесь, а также вы можете узнать, как создать собственный custom caveat.

Транзитивное или цепочечное делегирование

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

Каждое звено цепочки криптографически подписано и ограничено собственными caveats, то есть разрешения могут сужаться или переопределяться на каждом уровне. Иными словами, суб-делегирования могут быть подмножеством исходного делегирования с более строгими ограничениями или сниженными возможностями.

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

Что дальше?

Delegation Toolkit предоставляет инструменты для создания более безопасных, интеллектуальных и гибких систем разрешений в ваших dapp'ах. Будь то делегированные расходы, спонсирование газа, автоматизированные рабочие процессы или бесшовный онбординг — всё это теперь возможно без необходимости изобретать велосипед.

В следующих публикациях мы перейдём к практике, начав с руководства по созданию функции «Пригласить друга» — наглядного примера делегирования в действии. Следите за продолжением серии, в которой мы рассмотрим другие функции, доступные для реализации уже сегодня.

Если вы хотите глубже изучить эти идеи, следите за анонсом предстоящего апрельского Gator Hackathon, где у вас будет возможность создавать проекты с использованием Delegation Toolkit вместе с другими разработчиками.