ERC-865: トークンでのガス料金支払い

キーストーン
• ERC-865はトークンでのガス料金支払いを可能にするアイデアを導入しました。
• ユーザーはETHを保有せずに、既存のトークンでトランザクションを実行できます。
• アカウント抽象化とメタトランザクションが進化し、2025年には実用化される見込みです。
• リレイヤーやペマスターがトランザクションのコストとリスクを管理します。
• 新規ユーザーのオンボーディングが容易になり、dAppの利用が促進されます。
イーサリアムにおいて、ガス料金をETHで支払うことは、新規ユーザーにとって長年の課題でした。ERC-865の背後にあるアイデアは、シンプルかつ魅力的です。ユーザーが既に保有しているトークン(例: USDCやDAI)でトランザクション料金を支払えるようにし、リレイヤーまたはペマスターが裏側でETHガスを処理します。ERC-865自体は標準化されていませんが、その中核となる概念(誰が、どの通貨で支払うかを抽象化する)は、メタトランザクションとアカウント抽象化を通じて進化し、2025年には実用的になります。
ERC-865が解決しようとしたこと
ERC-865は、ユーザーがオフチェーンでトランザクションに署名し、その中に選択したERC-20トークンで表示された手数料を含めるパターンを提案しました。リレイヤーは、このトランザクションをオンチェーンに送信し、ETHガスを支払い、スマートコントラクトを通じてトークンでその費用を回収します。これにより、ユーザーはガス料金を支払うためだけにETHを保有する必要がなくなり、オンボーディングが改善され、よりスムーズなdApp体験が可能になります。
ERC-865は公式な標準にはなりませんでしたが、現代のメタトランザクションやアカウント抽象化のようなメカニズムの基盤を築き、「トークンでのガス支払い」を今日可能にしています。元のトークン標準の文脈については、ERC-20仕様と、トークンアロワンスがパーミットスタイルの承認を介してスマートコントラクトでこれらのフローをどのように可能にするかを参照してください(EIP-20、EIP-2612)。
コンセプトの実践的な仕組み
概要は以下の通りです。
- ユーザーはオフチェーンで意図(アクションとトークン建ての手数料を指定)に署名します(多くの場合、型付けデータを使用)。
- リレイヤーまたはペマスターがトランザクションを送信し、ETHでガスを支払います。
- スマートコントラクトがユーザーのトークンを転送し、リレイヤー/ペマスターに補償します。
- リプレイ保護、手数料上限、ドメイン分離により、不正利用を防ぎます。
型付けデータ署名と堅牢なドメイン分離は、安全性とUXにとって重要です(EIP-712を参照)。
モダンスタック:メタトランザクションとアカウント抽象化
2つの主要なアプローチが成熟しました。
-
信頼できるフォワーダーによるメタトランザクション
- ユーザーはメッセージに署名し、リレイヤーがフォワーダーを通じてオンチェーンに送信します。フォワーダーは署名を検証し、ユーザーの代わりにコールを実行します。
- EIP-2771で標準化され、OpenGSNのGas Station Networkのようなツールで広く採用されています。そのドキュメントでは、スポンサーシップパターンやリレイヤー市場について説明しています(OpenGSNドキュメント)。
-
アカウント抽象化(EIP-4337)
- 「ユーザーオペレーション」の概念をレガシー・トランザクションから分離します。バンダーがユーザーオペレーションを収集して送信し、ペマスターが代替手数料支払いポリシーを定義します。例えば、USDC手数料を許可したり、特定のdAppアクションをスポンサーしたりします。
- このモデルはEIP-4337によって形式化され、Ethereum Foundationのブログでその展開が発表されました(EIP-4337によるアカウント抽象化)。
- 開発者は、Ethereumのドキュメントでアカウント抽象化の概念、ユーザーオペレーション、ペマスターを探索できます(アカウント抽象化の概要)。
これらのパターンは、元のERC-865の目的を一般化します。エンドユーザーはETH for gasを気にすることなくトランザクションを実行でき、リレイヤー/バンダーとペマスターはコストとリスクを管理します。
トークンでのガス支払いという意義
- オンボーディング:新規ユーザーはdAppの利用を開始するためにETHを必要としません。彼らは既に保有している資産でトランザクションを実行できます。
- UXの一貫性:手数料はステーブルコインで表示でき、コストを予測可能にします。
- ビジネスロジック:dAppは、ペマスターまたはメタトランザクションリレイヤーを統合することで、特定のアクションをスポンサーしたり、ユーザーを獲得したり、手数料ポリシーを調整したりできます。
リスクと設計上の考慮事項
- リレイヤーの信頼と市場:嫌がらせに対する保護を設計し、リレイヤーのインセンティブが公正であることを保証する必要があります。OpenGSNのようなシステムは、リレイヤーのインセンティブと評判に対処します(OpenGSNドキュメント)。
- 価格設定とオラクル:手数料にトークンを使用するには、公平な換算レートと安全なオラクル統合が必要であり、過少支払いまたは悪用を防ぎます。
- 署名の安全性:フィッシングやリプレイを軽減するには、型付けデータ(EIP-712)と明示的なドメイン分離が不可欠です。
- トークン承認:無制限の承認よりもパーミットフロー(EIP-2612)を優先し、影響範囲を減らすために上限を設定することを推奨します(EIP-2612)。
- スマートコントラクト監査:フォワーダー、ペマスター、償還ロジックは、トークンの枯渇やMEVエクスプロイトを可能にするのを避けるために、慎重に監査する必要があります。
2025年の状況と今後の展望
2025年までに、アカウント抽象化はウォレット、SDK、バンダーインフラストラクチャによって広くサポートされ、ペマスターは「トークンでのガス支払い」を実装する事実上の方法になりつつあります。外部所有アカウントの機能を改善するための議論は続いており、EIP-3074やEIP-7702のような提案は、抽象化ベースのデザインを補完する、より安全な承認とUXの改善を探求しています。ERC-865自体はライブ標準ではありませんが、エコシステムは、その中核となる約束を実現する堅牢な代替手段に収束しています。
開発者向けの導入ガイド
-
dApp向け:
-
セキュリティ向け:
- 手数料上限とレートソースを制限し、送信前にオフチェーンでトランザクションをシミュレートします。
- 悪用を防ぐために、スポンサーポリシーを特定のコントラクトメソッドと呼び出し元に制限します。
- リレイヤーのパフォーマンスを監視し、フォールバック戦略を維持します。
ユーザーが期待すべきこと
より多くのウォレットとdAppがアカウント抽象化とメタトランザクションを採用するにつれて、ETHを保有することなくトランザクションを実行できるようになる機会が増えるでしょう。手数料はステーブルコインで支払われたり、特定のアクションについてはdAppが完全にスポンサーしたりする可能性があります。署名する内容を常に確認してください(型付けデータは意図を明確にします)。より強力なキー保護のためにハードウェアウォレットを使用してください。
ウォレットに関する実用的な注意点
ペマスターやメタトランザクションを使用する場合、ウォレットは構造化されたメッセージに安全かつ一貫して署名する必要があります。OneKeyハードウェアウォレットはEIP-712型付けデータ署名をサポートしており、プライベートキーをオフラインに保ちながら、最新のdAppフローとシームレスに統合するように設計されています。アカウント抽象化またはメタトランザクション機能を定期的に使用する予定がある場合は、複雑な署名を処理しながらキーを保護できるハードウェアウォレットは、日常業務におけるリスクを大幅に軽減できます。
結論
ERC-865はトークンでのガス料金支払いのアイデアを導入しました。アカウント抽象化とメタトランザクションは、そのアイデアを現実のものにしました。2025年までに、ペマスター、バンダー、信頼できるフォワーダーは、ガス抽象化のための本番グレードのパスを提供し、よりスムーズなオンボーディングと優れたUXを可能にします。これらのパターンがEIP-7702のような提案とともに進化するにつれて、エコシステムは、ユーザーがETHを事前に準備することなく、保有する資産でトランザクションを実行できる未来へと着実に前進しています。
参照:
- EIP-4337: Account Abstraction
- Ethereum Foundation blog: Account Abstraction with EIP-4337
- EIP-2771: Trusted Forwarder for Meta-Transactions
- EIP-712: Typed Structured Data Signatures
- EIP-2612: permit for ERC-20 approvals
- EIP-3074: AUTH and AUTHCALL for EOAs
- EIP-7702: Controlled Account Code proposal
- OpenGSN: Gas Station Network docs
- Ethereum docs: Account abstraction overview






