ERC-777 詳解：具備勾子的現代代幣標準

ERC-777 是一個較新的以太坊代幣標準，旨在解決 ERC-20 長期存在的限制，同時引入可程式化的「勾子」（hooks），以實現更豐富的代幣流動。如果您一直關注開發者之間關於組合性、更安全的授權以及協定自動化的討論，那麼 ERC-777 正是這些需求的交匯點。本文將解釋 ERC-777 的運作方式、為何存在、其優勢、需要注意的安全權衡，以及用戶和建構者在 2025 年應如何看待它。

ERC-777 旨在解決的問題

ERC-20 已成為預設的可替代代幣標準，但它存在一些明顯的痛點：

• 授權（Approvals）操作笨拙且容易出錯（例如，忘記重置授權額度）。
• 合約無法在代幣抵達時自動作出反應；它們需要拉取式互動。
• 轉帳語義有限，使得複雜的流程（費用、回呼、多步驟工作流程）更難實現。

ERC-777 試圖透過提供以下功能來實現現代化：

• 內建的發送/接收勾子，以便合約可以在同一筆交易內對轉帳作出反應。
• 操作員（Operator）式的轉帳，簡化了託管方和服務的代幣管理。
• 向後相容 ERC-20 介面，以簡化生態系統的採用。

如需正式規格，請參閱以太坊改進提案網站上的標準 ERC-777 規格：EIP-777。若要將其置於更廣泛的代幣生態系統中，以太坊開發者文件中的代幣標準概述提供了相關背景和連結：以太坊代幣標準概述。

ERC-777 的運作方式：勾子與操作員

兩個核心概念驅動了 ERC-777。

1. 勾子 (Hooks)

• tokensToSend：在代幣轉移前調用的發送方勾子。
• tokensReceived：在代幣抵達後調用的接收方勾子。
• 這些是選擇性加入的，並透過全域介面註冊表 EIP-1820 進行發現。

透過勾子，合約可以在轉帳期間實施業務邏輯：自動質押、費用分配、記錄、閘控或拒絕意外的代幣。勾子增加了組合性，並減少了對獨立「授權後呼叫」流程的需求。

2. 操作員 (Operators)

• 操作員被授權代表持有者轉移代幣，類似於委託的託管方。
• 預設操作員可由代幣設定，用戶可隨時撤銷。
• 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/zh-HK/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/interfaces/IERC1820Registry.[sol](https://onekey.so/blog/zh-HK/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/zh-HK/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 hook
    function tokensReceived(
        [address](https://onekey.so/blog/zh-HK/ecosystem/what-is-a-crypto-wallet-address/) operator,
        [address](https://onekey.so/blog/zh-HK/ecosystem/what-is-a-crypto-wallet-address/) from,
        [address](https://onekey.so/blog/zh-HK/ecosystem/what-is-a-crypto-wallet-address/) /*to*/,
        uint256 amount,
        bytes calldata data,
        bytes calldata operatorData
    ) external {
        // Custom logic, e.g., record deposit or trigger internal accounting
        emit Received(operator, from, amount, data, operatorData);
    }
}

關鍵重點：勾子允許合約在無需額外函數呼叫的情況下「監聽」代幣移動，從而減少摩擦，並使複雜的流程感覺像是原生功能。

安全考量：重入攻擊與協定設計

勾子功能強大，但如果合約設計不夠完善，它們會引入重入攻擊（reentrancy）風險。在早期 DeFi 中，一系列事件凸顯了代幣回呼如何能意外地與假設 ERC-20 式行為的協定互動。這些經驗教訓推動了至今仍適用的最佳實踐：

• 在狀態變更函數中，優先考慮「檢查-效果-互動」（checks-effects-interactions）模式。
• 在外部呼叫路徑上使用重入防護（reentrancy guards）。
• 仔細設計資金池/會計邏輯，使其能夠穩健地應對轉帳期間的回呼執行。
• 可能的情況下，考慮為敏感操作採用「拉取」（pull）模式。
• 避免假設轉帳是沒有副作用的。

儘管 Uniswap v1 時期的特定利用漏洞已成為歷史，但其原則依然適用：勾子使代幣轉帳變得活躍，而不是被動。現代審計和函式庫也隨之演進。有關該標準及其安全注意事項的基礎參考資料，請參閱 EIP-777。若要研究維護良好的模式和保護措施，請參閱 OpenZeppelin 的 ERC-777 文件。

互通性與從 ERC-20 遷移

ERC-777 代幣通常向後相容 ERC-20 介面，但其假設不同：

• 轉帳可能觸發勾子，這可能產生副作用。
• 操作員取代或補充了授權，改變了服務的互動方式。
• 錢包和去中心化應用程式（dApps）必須正確處理元數據和基於勾子的流程。

鑑於生態系統的廣泛熟悉度，一些團隊仍堅持使用 ERC-20 加上諸如 EIP-2612 permit（免 gas 授權）等改進。另一些團隊則在可程式化接收或操作員語義能實質上改善用戶體驗或協定邏輯的場景下採用 ERC-777。

2025 年的格局：勾子在哪裡適用

雖然 ERC-20 在可替代代幣領域仍佔主導地位，但勾子的概念已影響了其他領域的設計。一個明顯的例子是 Uniswap v4 的架構，它在流動性資金池層級採用了可程式化的「勾子」，以實現動態費用和客製化邏輯等功能，從設計上使協定更具組合性。有關這種演變的背景，請參閱 Uniswap v4 概述和勾子討論：Uniswap v4 宣布與勾子。

在代幣層面，ERC-777 的採用仍然是選擇性的——特別是在自動回呼和操作員語義能提供切實價值的場合，例如：

• 受益於操作員轉帳的託管或服務提供者流程。
• 接收時作出反應的鏈上忠誠度計畫或串流支付。
• 希望透過代幣原生回呼進行會計或費用收取的基础層。

同時，第二層（Layer 2）網路持續改善吞吐量和成本效益，使得更複雜的代幣生命週期邏輯變得可行。這種環境使得 ERC-777 的可程式性成為需要更豐富轉帳語義但又能投入嚴謹安全工程的團隊的及時選擇。

建構者的最佳實踐

• 使用經過審計的函式庫，並預設使用知名實作。從 OpenZeppelin 的 ERC-777 開始。
• 設計勾子邏輯以應對失敗模式：拒絕意外代幣、驗證來源，並維護不變式檢查。
• 清楚記錄預設操作員；為用戶提供簡單的撤銷路徑。
• 應用重入防護，特別是圍繞 tokensReceived，並避免在關鍵會計步驟中進行外部呼叫，除非絕對必要。
• 考慮您是否真正需要勾子。如果不需要，ERC-20 加上 EIP-2612 permit 可能會簡化整合和用戶預期。
• 在可能對 ERC-777 處理方式不同的錢包和去中心化應用程式中進行測試。正確使用 EIP-1820 註冊表 來註冊實作者。

使用者的實用提示

• 請理解 ERC-777 代幣在到達特定合約時可能會觸發邏輯。這通常是有益的，但與「被動」的 ERC-20 轉帳相比，它改變了原有的假設。
• 審查您正在授權什麼以及向誰授權。如果代幣使用操作員或回呼，請確保您信任接收合約的程式碼和聲譽。
• 偏好提供清晰合約方法詳細資訊的錢包，而不僅僅是「轉帳」或「發送」。如果某個內容看起來不熟悉或包含任意數據欄位，請暫停並驗證。

何時考慮 ERC-777

當出現以下情況時，ERC-777 是合理的選擇：

• 您需要在轉帳時實現事件驅動的代幣行為（例如，自動存款、費用路由、自訂閘控）。
• 操作員能為您的服務或託管模式帶來實質簡化。
• 您致力於嚴格的安全工程和審計，以安全地處理基於回呼的語義。

當出現以下情況時，ERC-777 可能不是最佳選擇：

• 簡潔性和廣泛的生態系統相容性是首要考量。
• 您可以透過 ERC-20 加上 permit，或更高級別的協定機制（例如，無代幣勾子的應用程式特定控制器）來實現您的目標。

硬體錢包的觀點

對於行為更豐富且可能產生副作用的代幣標準，清晰的交易內省和離線簽署是無價的。OneKey 是一款開源的硬體錢包，強調裝置上的透明確認和廣泛的 EVM 代幣支援。如果您經常與利用回呼的高級代幣標準或 DeFi 協定互動，使用硬體錢包有助於確保您準確驗證正在簽署的內容，並降低遭受惡意合約攻擊的風險。換句話說，ERC-777 的複雜性使得安全的金鑰管理和明確、人類可讀的確認變得更加重要——像 OneKey 這樣的裝置可以在這些方面提供切實的安心。

結論

ERC-777 引入了現代代幣功能—勾子和操作員—為以太坊和 EVM 鏈解鎖了更豐富、更具組合性的代幣流動。它的力量伴隨著責任：勾子是主動的，而不是被動的，需要防禦性程式設計和謹慎的用戶體驗。在 2025 年，勾子的概念已經影響了代幣以外的協定設計，正如 Uniswap v4 中所見，而 ERC-777 本身仍然是那些真正受益於可程式化接收和操作員語義的團隊的目標選擇。無論您採用 ERC-777 還是堅持使用改進的 ERC-20 模式，都要將良好的工程實踐與安全的用戶工作流程相結合——並考慮硬體支援的簽署——這樣您的代幣邏輯才能既強大又安全。