ERC-7779 がライブに

LeeMaimai

/2025年10月14日

キーストーン

• ERC-7779は、より安全な承認とトランザクション権限を提供します。

• ウォレットUXが向上し、ユーザーは明確なプロンプトを受け取ることができます。

• アカウント抽象化と新しいウォレットパターンが成熟し、UXが改善されます。

• 新しい標準への移行により、許可管理が簡素化されます。

• ERC-7779は、L2全体でのエクスペリエンスを均一化します。

イーサリアムの標準開発のペースは、ほとんど衰えることがありません。ERC-7779 がライブになった今、ユーザー、開発者、ウォレットプロバイダーは同じ疑問を抱えています。新しい ERC がライブになることで、日常的な仮想通貨や DeFi 体験に実際に何が変わるのでしょうか？この記事では、新しい ERC がなぜ重要なのか、どのようにプロダクションに到達するのか、承認とトランザクション UX の実際的な意味、そしてエコシステムが最新のインターフェースを採用する際に OneKey ユーザーが期待できることについて説明します。

まず、簡単な復習：ERC とは？

ERC (Ethereum Request for Comments) は、コントラクトとアプリがどのように動作すべきかを定義するコミュニティ主導のアプリケーションレベルの標準であり、それらが確実に相互運用できるようにします（ERC-20 や ERC-721 を考えてみてください）。ERC は、EIP プロセスを通じて、ドラフトから最終段階へと、オープンな議論とピアレビューを経て登場します。標準の作成方法に慣れていない場合は、EIP プロセスが公式仕様に詳細に文書化されています。イーサリアムの標準ドキュメントで EIP のライフサイクルと根拠、および EIP メタプロセスを確認してください。

公式開発者ポータルでイーサリアムの標準がどのように機能するかを学ぶ（イーサリアムの標準を参照）
EIP のライフサイクルとステータス定義を深く掘り下げる（EIP-1 を参照）

ウォレット、dapps、レイヤー 2 を連携させるために、ERC はしばしば以下のような基本的な EIP を基盤として構築されます。

EIP-712：人間が読める構造化データの署名（EIP-712 を参照）
EIP-165：インターフェース検出と互換性チェック（EIP-165 を参照）
EIP-2771：信頼できるフォワーダーを介したメタトランザクション（EIP-2771 を参照）

ERC-7779 が改善を目指すもの

新しい ERC はそれぞれユニークですが、最近の標準は 2 つの目標に向かう傾向があります。

より安全で、より詳細な承認とトランザクション権限。ユーザーは、dapp が何を実行できるか、どのくらいの期間実行できるかを正確に許可し、オンデバイスで明確なプロンプトを受け取りたいと考えています。この方向性は、ERC-20 の approve/transferFrom フローから学んだ教訓と、パーミットスタイルの署名への進化に沿ったものです。approve の落とし穴とより安全なパターンに関する背景を参照してください（OpenZeppelin approve notes を参照）。
より豊かなコンテキストによるウォレット UX の向上。標準はますますメタデータをエンコードするようになり、ウォレットは不透明なバイトコードではなく、理解可能なプロンプトを表示できるようになります。これは、人間が読める署名規約と一致しています。より安全なプロンプトのための型付き構造化データについて読んでください（EIP-712 を参照）。

実際には、ERC-7779 が「ライブになる」ということは、早期採用者（dapps、SDK、ウォレット）が、既存のトークンやプロトコルとの互換性を壊すことなく、より安全な承認、より良いデコード、そしてより少ない混乱する署名を提供するように設計されたインターフェースの統合を開始したことを意味します。

なぜ今これが重要なのか

そのタイミングは重要です。イーサリアムの最近のアップグレードにより、L2 の手数料が削減され、オンチェーンアクティビティが拡大しました。同時に、アカウント抽象化と新しいウォレットパターンが成熟しています。

メインネットでの Dencun アップグレードにより、ロールアップのデータ可用性が安価になり、L2 の採用が促進されました（Dencun announcement を参照）。
アカウント抽象化は理論から実装へと進み、プログラム可能なウォレットを可能にしています（EIP-4337 を参照）。
提案されているトランザクションモデル（EIP-7702）は、UX とセキュリティのトレードオフを改善したアクションを承認するための新しい方法を導入しています（EIP-7702 を参照）。
イーサリアムの長期的なロードマップは、スケーラビリティとセキュリティを優先し続けており、これはウォレットと標準がどのように進化するかに影響します（Ethereum roadmap を参照）。

このような背景の中で、承認の安全性を強化し、プロンプトの明瞭さを改善するあらゆる ERC は、現実世界に大きな影響を与える可能性があります。

日常的なユーザーにとって：ウォレットに何が変わるか

より明確なプロンプト、より少ないブラインド署名。ERC-7779 スタイルのメタデータを実装したウォレットは、可能な限り構造化データを使用して、コントラクトが何を求めているのか、そしてなぜ求めているのかを表示できます（EIP-712 を参照）。
より詳細な権限。エコシステムがパーミットライクなフローとベストプラクティスに収束するにつれて、関数ごとまたは金額ごとの制御がより一般的になることが予想されます（ERC-20 パーミット拡張 EIP-2612 および Permit2 パターンを参照）。
より簡単な許可管理。新しい標準への移行、特に、リスクの高い承認を特定して取り消すために、許可スキャナーを引き続き使用してください（Etherscan Token Approval Checker を参照）。
L2 全体での認知負荷の軽減。標準が統一されたインターフェースを採用するにつれて、ネットワーク全体でのエクスペリエンスがより均一になります。

役立つツールと参照資料：

Etherscan Token Approval Checker（取り消しと監視用）
最新の DEX で採用されているパーミットスタイルのフローと取り消しパターン（Permit2 overview を参照）
ERC-20 承認と安全上の注意に関する OpenZeppelin のガイダンス（OpenZeppelin approve notes を参照）

開発者にとって：統合プレイブック

まず後方互換性を維持。ERC-20 との互換性を維持しながら、EIP-165 検出の背後に新しいインターフェースを配置して、古いウォレットが壊れないようにします（EIP-165 を参照）。
生バイトよりも型付きデータを優先。可能な場合は、ユーザー向けの署名を EIP-712 に移行して、ハードウェアウォレットでの明確な署名を可能にし、リスクプロンプトを改善します（EIP-712 を参照）。
パーミットフローを検討。ユースケースが支出許可を付与する場合は、パーミットスタイルのパターン（EIP-2612）または承認攻撃対象領域を削減する実証済みのライブラリを採用します（EIP-2612 および Permit2 overview を参照）。
適切な場合はメタトランザクションをサポート。EIP-2771 を使用して、リプレイ保護とドメイン分離を維持しながら、ガススポンサー付きフローを許可します（EIP-2771 を参照）。
監査済みのライブラリを使用。自分で作成するのではなく、維持されているプリミティブとインターフェースに依存します（OpenZeppelin Contracts を参照）。
新しいコードパスの脅威モデリング。あらゆる新しいフックまたは許可サーフェスは、潜在的な再入可能攻撃と承認の悪用リスクを導入します。それらを既知の SWC カテゴリにマッピングし、徹底的にテストします（SWC Registry を参照）。

開発者向け参照資料：

EIP-2612（ERC-20 のパーミット）
Permit2 の概要と承認に関するベストプラクティス
OpenZeppelin Contracts 5.x（標準に準拠した実装用）
SWC Registry（脆弱性クラス用）

ウォレット統合とハードウェアの考慮事項

新しい ERC が展開されるとき、実際のユーザーの安全はウォレットがそれをどのように実装するかにかかっています。

正確なメソッドデコード：ウォレットは、該当する場合は EIP-165 を介してインターフェースをデコードし、関数セレクターではなく人間が読める意図を表示する必要があります。
デバイス上での明確な署名：構造化データが利用可能な場合、ハードウェアウォレットは人間が読めるフィールドを表示して、ユーザーが署名している内容を確認できるようにする必要があります（EIP-712 を参照）。
シミュレーションとリスクキュー：署名前のシミュレーション、許可差分、コントラクトの出所を示すキューは、悪意のある承認がオンチェーンに着地する前に検出するのに役立ちます。

OneKey ユーザーが期待できること：

標準優先の署名：OneKey は、構造化データ署名を含む主要なイーサリアム標準をサポートしており、曖昧なバイトコードプロンプトを回避するのに役立ちます（EIP-712 を参照）。
透明なトランザクションレビュー：OneKey アプリは、デバイス上で確認する前に、メソッド、資産、金額の詳細を表示します。
オープンソースの精神：オープンなコードベースにより、独立したレビュー担当者とコミュニティは、新しい標準がどのように統合されているかを精査できます。これは、ERC が新しい許可パスを導入する際に不可欠です。

ERC-7779 の採用が拡大するにつれて、OneKey は、厳格なセキュリティプラクティスを維持しながら、L1 および L2 ネットワーク全体での明確な署名と互換性を優先し続けます。

セキュリティ衛生：本質は変わらない

可能な限り、dapp ごとに最小限の許可を使用してください。厳密に必要な場合を除き、無制限の承認は避けてください。
特に新しい dapp を試したり、新しい標準に移行したりした後は、定期的に期限切れの承認を取り消してください（Etherscan Token Approval Checker を使用）。
新しいフローを新しい攻撃サーフェスのように扱ってください。フィッシングキットは、新しいウォレットプロンプトを模倣するように進化します。ドメイン、コントラクトアドレス、チェーン ID を確認してください。
監査済みで適切に保守されているコントラクトとライブラリを優先し（OpenZeppelin Contracts を参照）、一般的なスマートコントラクトの弱点クラスを理解してください（SWC Registry を参照）。

今後の展望

ERC-7779 は、アカウント抽象化（EIP-4337 を参照）、提案されているトランザクション承認モデル（EIP-7702 を参照）、およびイーサリアムのロードマップにおけるネットワーク改善の着実なペースにまたがる、より広範なウォレットと UX のアップグレードサイクルの一部です。標準が成熟し、収束するにつれて、ユーザーは、より少ない混乱するプロンプト、デフォルトでより安全な承認、そして L2 全体でより一貫したエクスペリエンスを期待できるようになるはずです。

かなりのオンチェーン価値を管理している場合は、好みのソフトウェアウォレットとハードウェアウォレットをペアにすることを検討してください。OneKey は、EIP-712 のような標準のための明確な署名、オープンソースの透明性、およびマルチチェーンの互換性を重視しています。これらは、新しい ERC が展開され、トランザクションサーフェスが進化するにつれて、実用的なガードレールとなります。

参考文献および参考資料：