ERC-777 解説：フックを備えた最新トークン規格

ERC-777 は、ERC-20 の長年の制約を解消し、より豊かなトークンフローのためのプログラム可能な「フック」を導入するために設計された、より新しいイーサリアムのトークン規格です。 composability、より安全な承認、プロトコルの自動化に関する開発者の会話をフォローしてきたなら、ERC-777 はそれらのニーズの交差点に位置します。この記事では、ERC-777 の仕組み、その存在理由、その強み、注意すべきセキュリティ上のトレードオフ、そして 2025 年にユーザーと開発者がどのようにアプローチできるかを解説します。

ERC-777 が解決しようとした問題

ERC-20 はデフォルトの代替可能トークン規格となりましたが、顕著な問題点があります。

• 承認は扱いにくく、エラーが発生しやすい（例：アロゥアンスをリセットし忘れる）。
• トークンが到着しても、コントラクトは自動的に反応できません。プル型のインタラクションが必要です。
• 送金セマンティクスが限定的で、複雑なフロー（手数料、コールバック、複数ステップのワークフロー）が困難になります。

ERC-777 は、以下を提供することでこれを近代化しようとしています。

• 送金/受信フックを内蔵し、コントラクトが同じトランザクション内で送金に反応できるようにします。
• オペレーターベースの送金により、カストディアンやサービスのトークン管理が簡素化されます。
• ERC-20 インターフェースとの後方互換性により、エコシステムへの採用を促進します。

正式な仕様については、イーサリアム改善提案サイトの標準的な ERC-777 仕様を参照してください。EIP-777。より広範なトークンエコシステムに位置づけるために、トークン規格に関するイーサリアムの開発者ドキュメントは、関連する EIP 全体へのコンテキストとリンクを提供します。イーサリアム トークン規格の概要。

ERC-777 の仕組み：フックとオペレーター

ERC-777 を支える 2 つのコアアイデアがあります。

1. フック

• tokensToSend: トークンが移動する前に呼び出される送信側フック。
• tokensReceived: トークンが到着した後に呼び出される受信側フック。
• これらはオプトインであり、グローバルインターフェースレジストリ EIP-1820 を介して検出されます。

フックを使用して、コントラクトは送金中にビジネスロジックを実装できます。自動ステーキング、手数料分割、ロギング、ゲーティング、または予期しないトークンの拒否などです。フックは composability を向上させ、個別の「承認してから呼び出す」フローの必要性を減らします。

2. オペレーター

• オペレーターは、委任されたカストディアンと同様に、保有者に代わってトークンを送金する権限を与えられます。
• デフォルトのオペレーターはトークンによって設定でき、ユーザーはいつでもそれらを無効にできます。
• ERC-777 のオペレーターは、ERC-20 のアロゥアンスと比較して、より明示的で柔軟なモデルです。

実際には、ほとんどのチームは監査済みのライブラリに依存しています。OpenZeppelin は、明確な API とガードレールを備えた広く使用されている実装を提供しています。OpenZeppelin ERC-777 コントラクト。

最小限の開発者向け例

以下は、EIP-1820 を介して tokensReceived を使用する受信コントラクトの模式図です。本番コードでは、常に検証済みのライブラリを使用し、監査を実施してください。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC777/IERC777.[sol](https://onekey.so/blog/ja/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/interfaces/IERC1820Registry.[sol](https://onekey.so/blog/ja/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/ja/ecosystem/what-is-a-smart-contract/) ExampleReceiver {
    IERC1820Registry constant _ERC1820 =
        IERC1820Registry(0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24);

    bytes32 constant TOKENS_RECIPIENT_INTERFACE_HASH =
        keccak256("ERC777TokensRecipient");

    event Received(address operator, address from, uint256 amount, bytes data, bytes operatorData);

    constructor() {
        _ERC1820.setInterfaceImplementer(address(this), TOKENS_RECIPIENT_INTERFACE_HASH, address(this));
    }

    // ERC777 tokensReceived フック
    function tokensReceived(
        [address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) operator,
        [address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) from,
        [address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) /*to*/,
        uint256 amount,
        bytes calldata data,
        bytes calldata operatorData
    ) external {
        // カスタムロジック、例：デポジットの記録または内部会計のトリガー
        emit Received(operator, from, amount, data, operatorData);
    }
}

主なポイント：フックにより、コントラクトは個別の関数呼び出しなしでトークン移動を「リッスン」でき、摩擦を減らし、複雑なフローをネイティブに感じさせます。

セキュリティに関する考慮事項：リエントランシーとプロトコル設計

フックは強力ですが、コントラクトが防御的に設計されていない場合、リエントランシーのリスクを導入します。DeFi の初期には、一連のインシデントにより、トークンコールバックが ERC-20 のような動作を想定していたプロトコルと予期せず相互作用する方法が浮き彫りになりました。それらの教訓は、今日でも関連性のあるベストプラクティスを推進しました。

• 状態変更関数では、チェック・エフェクト・インタラクションを優先します。
• 外部呼び出しパスにリエントランシーガードを使用します。
• コールバック実行中に、プール/会計ロジックを、送金中に堅牢になるように慎重に設計します。
• 可能な場合は、機密性の高い操作には「プル」モデルを検討します。
• 送金に副作用がないと仮定しないでください。

Uniswap v1 時代の特定の悪用は歴史になりましたが、原則はそのままです。フックはトークン送金をアクティブにし、パッシブではなくします。最新の監査とライブラリはそれに応じて進化しました。標準とそのセキュリティノートに関する基本的な参照については、EIP-777 を参照してください。よく維持されたパターンとガードレールを研究するには、OpenZeppelin の ERC-777 ドキュメントを参照してください。

ERC-20 との相互運用性と移行

ERC-777 トークンは、一般的に ERC-20 インターフェースとの後方互換性がありますが、仮定は異なります。

• 送金はフックをトリガーする可能性があり、副作用がある場合があります。
• オペレーターはアロゥアンスを置き換えたり補完したりし、サービスが相互作用する方法を変更します。
• ウォレットと dApp は、メタデータとフックベースのフローを正しく処理する必要があります。

一部のチームは、EIP-2612 permit（ガスレス承認）などの改善を備えた ERC-20 に留まっています。これは、エコシステム全体での幅広い親しみやすさのためです。他のチームは、プログラム可能な受信またはオペレーターのセマンティクスがユーザーエクスペリエンスまたはプロトコルロジックを大幅に改善する場所で ERC-777 を採用しています。

2025 年の展望：フックの配置場所

ERC-20 は依然として代替可能トークンを支配していますが、フックは他の場所のデザインに影響を与えています。明確な例は、Uniswap v4 のアーキテクチャです。これは、流動性プールレベルでプログラム可能な「フック」を採用して、動的な手数料やカスタムロジックなどの機能を有効にし、設計上プロトコルをより composable にします。この進化のコンテキストについては、Uniswap v4 の概要とフックに関する議論を参照してください。Uniswap v4 発表とフック。

トークンレベルでは、ERC-777 の採用は選択的です。特に、自動コールバックとオペレーターのセマンティクスが具体的な価値を提供するコンテキストでは、例えば次のとおりです。

• オペレーター送金から恩恵を受けるカストディアルまたはサービスプロバイダーフロー。
• 受信時に反応するオンチェーンロイヤルティプログラムまたはストリーミング支払い。
• 会計または手数料徴収のためにトークンネイティブなコールバックを必要とするインフラストラクチャレイヤー。

一方、レイヤー 2 ネットワークは、スループットとコストプロファイルを改善し続けており、より複雑なトークンライフサイクルロジックを実用的なものにしています。この環境により、ERC-777 のプログラム可能性は、よりリッチな送金セマンティクスを必要としながらも、堅牢なセキュリティエンジニアリングに投資できるチームにとって、タイムリーなオプションとなります。

開発者向けのベストプラクティス

• 監査済みのライブラリを使用し、よく知られた実装にデフォルト設定します。まず OpenZeppelin の ERC-777 から始めます。
• 障害モードのためのフックロジックを設計します。予期しないトークンを拒否し、送信元を検証し、不変条件チェックを維持します。
• デフォルトのオペレーターを明確に文書化します。ユーザーのために簡単な無効化パスを提供します。
• リエントランシー保護を適用します。特に tokensReceived の周りで、厳密に必要でない限り、重要な会計ステップ中に外部呼び出しを回避します。
• フックが本当に必要かどうかを検討します。そうでない場合は、ERC-20 に EIP-2612 permit を追加することで、統合とユーザーの期待を簡素化できる可能性があります。
• ERC-777 を異なる方法で扱う可能性のあるウォレットや dApp 全体でテストします。実装者を登録するために EIP-1820 レジストリ を正しく使用します。

ユーザー向けの実際的なヒント

• ERC-777 トークンは、特定のコントラクトに到達したときにロジックをトリガーできることを理解してください。これは通常有益ですが、「パッシブ」な ERC-20 送金と比較して仮定を変更します。
• 承認しているものと、誰に承認しているかを確認してください。トークンがオペレーターまたはコールバックを使用している場合は、受信コントラクトのコードと評判を信頼していることを確認してください。
• 単なる「転送」または「送信」ではなく、明確なコントラクトメソッドの詳細を表示するウォレットを優先してください。見慣れないものや、任意のデータフィールドが含まれているように見える場合は、一時停止して確認してください。

ERC-777 を検討する時期

ERC-777 は、次のような場合に意味があります。

• 送金時にイベント駆動型のトークン動作が必要な場合（例：自動デポジット、手数料ルーティング、カスタムゲーティング）。
• オペレーターがサービスまたはカストディアルモデルを大幅に簡素化する場合。
• コールバックベースのセマンティクスを安全に処理するために、厳格なセキュリティエンジニアリングと監査にコミットしている場合。

ERC-777 は、次のような場合にはあまり理想的ではないかもしれません。

• シンプルさと広範なエコシステム互換性が最優先される場合。
• ERC-20 に permit を追加するか、より高レベルのプロトコルメカニズム（例：トークンフックなしのアプリケーション固有のコントローラー）で目標を達成できる場合。

ハードウェアウォレットの視点

よりリッチな動作と潜在的な副作用を持つトークン規格の場合、明確なトランザクションイントロスペクションとオフライン署名は非常に価値があります。OneKey は、透明なオンデバイス確認と広範な EVM トークンサポートを重視するオープンソースのハードウェアウォレットです。高度なトークン規格やコールバックを利用する DeFi プロトコルを日常的に利用している場合は、ハードウェアウォレットを使用することで、署名しているものを正確に確認し、悪意のあるコントラクトへの露出を減らすことができます。つまり、ERC-777 の洗練度により、安全なキー管理と明確で人間が読める確認がさらに重要になります。これは、OneKey のようなデバイスが意味のある安心感を提供できる分野です。

結論

ERC-777 は、イーサリアムおよび EVM チェーンで、よりリッチで composable なトークンフローを解除する最新のトークン機能（フックとオペレーター）を導入します。その力には責任が伴います。フックはアクティブであり、パッシブではなく、防御的なプログラミングと慎重なユーザーエクスペリエンスを要求します。2025 年には、Uniswap v4 で見られるように、フックの概念はトークンを超えたプロトコル設計に影響を与えましたが、ERC-777 自体は、プログラム可能な受信とオペレーターのセマンティクスから真に恩恵を受けるチームにとって、ターゲットを絞った選択肢であり続けます。ERC-777 を採用する場合でも、改善された ERC-20 パターンに留まる場合でも、優れたエンジニアリングプラクティスと安全なユーザーワークフローを組み合わせてください。また、ハードウェアベースの署名を検討してください。これにより、トークンロジックは強力かつ安全になります。