Delegation Toolkitとは何か、またそれで何を構築できるか？

EthereumのアカウントコントロールはこれまでずっとEOA（Externally Owned Account）中心で硬直していました。EOAはシンプルで広く使われていますが、できることに限りがあります。一方、スマートコントラクトアカウント（SCA）はより高い柔軟性を持ちますが、つい最近まで単独では動作できませんでした。すべてのトランザクションの開始と手数料の支払いには、依然としてEOAが必要でした。

その状況を変えたのがERC-4337です。SCAはネイティブでガスのスポンサーシップ、トランザクションのバッチ処理（複数のトランザクションを1つにまとめる）、セッションキー、チェーン抽象化などの機能をサポートできるようになり、セキュリティ・柔軟性・ユーザーコントロールの向上につながっています。

それでも、EOAはなくなっていません。それには理由があります。すべてのユーザーが任意の検証ロジックをサポートするアカウントを必要としているわけではないからです。今すぐSCAに切り替える意味はあるのでしょうか？

では、ユーザーが切り替えの準備ができたとき、あるいはERC-4337のアカウント機能を一時的に活用したいときに、ゼロから新しいアカウントタイプを作ることを強いられないようにするにはどうすればよいでしょうか？使い慣れた環境を手放さずに、特定のトランザクションに限ってSCAの機能をEOAで利用できるようにするにはどうすればよいでしょうか？

ここで登場するのがEIP-7702（Set-EOA-account-code）です。

来たるPectraアップグレードの一環として、EIP-7702はEOAがスマートコントラクトコードに制御を委任することで、一時的にSCAのように振る舞えるようにします。このコードはEOAのアドレスから直接実行されます。つまり、ユーザーは高度な機能を利用するために新しいアカウントに移行する必要がなくなります。後方互換性を確保しながら、Ethereumを前進させる仕組みです。

これらの改善があっても、Web2に近い体験を完全に実現するためには、まだ解決すべき重要なUX上の課題があります。それは、きめ細かく柔軟なパーミッション管理です。ユーザーが特定のアクションを自分の代わりに実行する権限を他のユーザーと簡単に共有でき、厳格なガードレールと必要に応じてパーミッションを取り消せる仕組みが必要です。

これこそがDelegation Toolkitが解決しようとしている課題です。その内容と仕組みを詳しく説明する前に、Ethereumアカウントの次のUXフェーズを牽引する2つのERCをより深く見ていきましょう。

ERC-7710：スマートコントラクトによる委任

ERC-7710は、スマートコントラクトアカウントが特定のパーミッションを他のEthereumアカウントに委任する方法を標準化するための提案です。委任者（delegator）が明確で強制力のあるルールのもとで代理人（delegate）に権限を付与するための共通インターフェースを導入します。

ERC-7710を使えば、開発者は一定の条件（支出上限、時間制限、タスク固有のパーミッションなど）のもとで、あるアカウントが別のアカウントに安全に代理行動を許可するシステムを構築できます。これらはすべて、安全で予測可能な委任フローによって処理されます。

では、このコンテキストにおける「委任」とはどういう意味でしょうか？

大まかに言えば、アカウントの所有権と実行権を分離することです。委任者は資産やロジックを所有したまま、完全なコントロールを手放すことなく、特定の権限を一時的または永続的に他者に渡すことができます。

ネットワークの観点から見ると、ERC-7710はアカウント間でパーミッションが受け渡される方法に明確さとコンポーザビリティをもたらします。各アプリが独自の委任ロジックを実装する代わりに、コントラクトやツールが構築できる共通の基盤が生まれます。

ERC-7715：ウォレットからのパーミッション付与

ERC-7715は、dappがユーザーのウォレットにパーミッションをリクエストする方法を合理化するための提案です。dappがユーザーのアカウントへの明確にスコープされた事前承認済みアクセスを要求できるパーミッションモデルを導入し、インタラクションのたびに繰り返し確認を求める必要がなくなります。

現在の一般的なインタラクションフローは煩雑です。dappがトランザクションの送信やコントラクトとのインタラクションを要求するたびに、ウォレットがユーザーに承認を求めます。上限・期間・dappが実行できる範囲を指定する方法がなく、ユーザーが後からこれらの承認を確認・取り消すための標準的な手段もありません。

ERC-7715はこれを変えます。新しいメソッドwallet_grantPermissionsを導入し、dappが特定の権限を事前にリクエストできるようにします。たとえば、次の1時間で最大10USDCを使う許可や、次の数セッションで特定のスマートコントラクトとインタラクションする許可をリクエストできます。ユーザーはこれを事前に確認し、完全な透明性のもとで承認または拒否できます。

dappの観点からは、オンボーディングがスムーズになり、ユーザーを常に中断させないセッションベースまたは自動化された体験が可能になります。ウォレットにとっては、パーミッションの処理と付与済み内容の管理に、クリーンで監査可能な構造がもたらされます。ユーザーにとっては、セキュリティを犠牲にすることなく、より高い可視性、より多くのコントロール、そして煩わしいポップアップの削減が実現します。

では、開発者はこれらの標準を使って何を構築できるのでしょうか？

ERC-7710とERC-7715を組み合わせることで実現できる機能の例を紹介します：

• ERC-7710を使って固定の許容額をより頻繁に使用するウォレットに委任し、ほとんどの資金をオフラインで安全に保管することで、セキュアなウォレットから日次支出上限を設定する。

• 限定的なパーミッションを自動的に付与する事前スコープ済みの委任を使用し、ウォレットの事前設定やトランザクション承認なしにミントやリワードの受け取りなどのアクションをユーザーが実行できるようにすることで、オンボーディングを簡素化する。

• ERC-7710で限定的な実行パーミッションを割り当て、ERC-7715でウォレットを通じてそれらのパーミッションを簡単に承認できるようにすることで、AIエージェントに代わりにトレードさせる。

• ERC-7710の委任を活用するSCAにスポンサーシップ権を割り当てることで、ユーザーがETHを必要とせずに特定のトランザクションを通過させ、dappがユーザーのガス代をカバーできるようにする。

• ERC-7710を使って実行できる内容を厳密にスコープし、標準的なERC-20トークンとの互換性を確保しながら、代わりにapprove(0)を呼び出すヘルパーコントラクトにパーミッションを委任することで、トークン承認を安全に取り消す。

他にも多くの可能性があります。

Delegation Toolkitとは

Delegation Toolkitを最もわかりやすく説明すると、2つの主要パッケージを含むツールスイートです：

1. Delegation Core SDK – ERC-4337準拠のスマートコントラクトアカウント（委任者アカウント）を作成し、ERC-4337アカウント抽象化によって導入されたすべての機能を活用できるようにする開発者向けパッケージ。

2. Delegation Framework – スマートコントラクトアカウントがERC-7710標準を通じて他のEthereumアカウントにパーミッションを委任し、ウェブサイト・dapp・あるいは将来的にはあらゆるものがERC-7715を通じてアカウントにパーミッションをリクエストできるようにするシステム（近日公開予定）。

つまり簡単に言えば、Delegation ToolkitはERC-4337スマートコントラクトアカウント（SCA）をサポートするdappの構築、他のSCAやEOAへのパーミッション委任、そしてスマートアカウントから、またはPectraアップグレード後はEOAからもdappがそれらのパーミッションをリクエストできるようにすることを可能にします。

スマートコントラクトアカウントの仕組みをご存知であれば、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に委任する場合、Bは最大1 ETHしか転送できない、または次の24時間以内に特定のコントラクトとしかインタラクションできないというcaveatを含めることができます。

Caveatsは実行時に特別なcaveat enforcerコントラクトによって強制され、アクションが実行される前にルールが守られているかどうかを確認します。つまり、Bが行動する権利を持っていても、Aが設定した明確に定義された範囲内で動作することになります。サポートされているcaveatsの完全なリストはこちらを参照するか、独自のカスタムcaveatの作成方法を学んでください。

推移的または連鎖的委任

Delegation Frameworkのより強力な機能の1つは、委任が単一の引き渡しで終わる必要がないことです。推移的委任では、パーミッションを受け取ったアカウント（アカウントBとします）が、その権限の全部または一部を別のアカウントにさらに委任し、1つのアカウントを起点とする委任チェーンを形成できます。

チェーンの各リンクは暗号学的に署名され、独自のcaveatsでスコープされています。つまり、パーミッションはすべてのレベルで絞り込んだり再定義したりできます。言い換えれば、これらのサブ委任は元の委任のサブセットであり、より厳格な制約または限定された権限を持つことができます。

重要なのは、元の委任者が完全なコントロールを維持し、いつでも最初の委任を取り消すことができ、それによってチェーン内のすべての下流委任が自動的に無効になることです。これにより、DAOや共有ウォレットのような複雑なパーミッション設定に理想的な、柔軟かつ安全な信頼チェーンが生まれます。

次のステップ

Delegation Toolkitは、dappにより安全で、よりスマートで、より柔軟なパーミッションシステムをもたらすためのツールを提供します。委任された支出、ガスのスポンサーシップ、自動化されたワークフロー、シームレスなオンボーディングなど、何を実現したいにしても、今やゼロから作り直すことなくすべてが可能です。

次の投稿では実践的な内容に入り、委任の実際の例として「友達を招待する」機能を構築するチュートリアルから始めます。今日から実装できるさらなる機能を取り上げるシリーズの続きをお楽しみに。

これらのアイデアをさらに探求することに興奮しているなら、4月に開催予定のGator Hackathonにご注目ください。他の開発者とともにDelegation Toolkitを使って構築する機会が得られます。