ERC 草案：外部可執行賞金 — 無許可任務自動化的標準介面

本提案定義了一個標準介面 (IExternallyExecutableBounty)，用於公開需要由外部第三方執行的任務之智慧合約。實作此介面的合約會發布可執行的任務，任何成功執行任務的呼叫者都將獲得 ETH 獎金作為報酬。這建立了一個無許可、激勵驅動的自動化層，無需中心化營運網路、無需質押要求，也無需訂閱。

動機

智慧合約無法自我呼叫。任何與時間相關的邏輯——如定期付款、歸屬釋放、清算、治理執行、遺囑開關（Dead man’s switches）——都需要外部交易來觸發。

目前，專案通常透過以下方式解決此問題：

運行自己的基礎設施 — 伺服器、私鑰、監控、DevOps 維運成本。

訂閱中心化自動化服務 (Chainlink Automation, Gelato) — 供應商鎖定、訂閱費用、信任假設、審核流程。

這兩種方法都不具備可組合性、無許可性或標準化。通用執行者（executor）無法發現並服務於需要自動化的任意合約。

缺口

如果你現在正在開發一個需要「在區塊 X 之後呼叫此函數」的合約，你的選擇有：

自己運行節點（基礎設施負擔）。

支付 Chainlink Automation 費用（訂閱制、供應商依賴）。

希望有人會呼叫你的函數（缺乏激勵）。

目前缺失的是一個標準介面，讓任何合約都能宣告：「我有工作需要完成，我會為此支付 ETH。」

這正是 ERC-20 對代幣所做的貢獻——在它出現之前，每個代幣都有自己的轉帳機制；在 ERC-20 出現後，錢包、DEX 和工具都能使用相同的介面與任何代幣互動。我們希望在任務執行方面實現同樣的目標。

規範

此介面刻意保持極簡——包含 4 個函數和 3 個事件：

interface IExternallyExecutableBounty {
    event TaskCreated(uint256 indexed taskId, uint256 executeAfterBlock, uint256 bountyAmount);
    event TaskExecuted(uint256 indexed taskId, address indexed executor, uint256 bountyAmount);
    event TaskCancelled(uint256 indexed taskId);

    function getExecutableTasks() external view returns (uint256[] memory taskIds);
    function executeTask(uint256 taskId) external;
    function taskBounty(uint256 taskId) external view returns (uint256 amount);
    function taskCount() external view returns (uint256);
}

運作方式

合約開發者實作 IExternallyExecutableBounty 並為合約注入 ETH 作為獎金。

執行者（任何運行機器人的人）呼叫 getExecutableTasks()（view 函數，免費）來發現已就緒的任務。

執行者透過 eth_call 模擬 executeTask(taskId) —— 如果實作有誤，模擬會失敗，執行者將跳過該任務。

當有利可圖時，執行者提交 executeTask(taskId) —— 合約邏輯運行，執行者透過 msg.sender 接收 ETH。

為何僅限 ETH 獎金？

這是一個深思熟慮的設計選擇：

模擬友善：執行者透過 eth_call 模擬執行並檢查其 ETH 餘額變化。錯誤的實作會立即失敗，執行者永遠不會浪費 Gas。

無代幣邊際案例：沒有轉帳手續費代幣（fee-on-transfer）、沒有重置餘額（rebasing）、沒有授權模式（approval patterns）、沒有非標準的返回值。

通用性：ETH 存在於每個 EVM 鏈上。不依賴於特定的代幣部署。

Gas 效率：原生 ETH 轉帳比 ERC-20 轉帳更便宜。

想要提供 ERC-20 獎金的合約可以進行封裝：持有 ETH 作為獎金，並在任務邏輯中處理代幣分配。

關鍵設計決策

公平競速執行：沒有提交-揭露（commit-reveal）機制，也沒有抽獎。第一個有效的交易獲勝。這反映了 MEV 的運作方式，並確保任務得到及時執行。

合約設定獎金：部署合約方決定獎金金額。執行者決定是否值得花費 Gas。這是市場定價，而非訂閱定價。

Gas 是執行者的問題：執行者在執行前計算「獎金 > Gas 成本」。簡單，且不依賴預言機。

CEI 模式：全程在外部呼叫前更新狀態。任務狀態在 _onTaskExecuted() 運行前以及獎金支付前即完成更新。

單次與循環任務：兩者皆支援。循環任務在執行後會重新啟動。單次任務則標記為已執行。

介面中無取消函數：取消邏輯因實作而異。TaskCancelled 事件已標準化，以便執行者追蹤。

ERC-165

合規的合約必須實作 ERC-165，並針對介面 ID 0x0dd141a0 返回 true。

範例應用場景

遺囑開關 (Dead Man’s Switch)：擁有者必須定期簽到。如果沒有簽到，任何人都可以觸發開關（將資金轉移給受益人）並領取獎金。

定期付款：薪資發放、訂閱費、在達到區塊閾值後變為可執行的定期轉帳。

治理執行：在時間鎖到期後執行已通過的提案。

歸屬釋放 (Vesting Release)：代幣歸屬計劃，任何人皆可在達到特定階段（cliff）時觸發釋放。

預言機更新：由獎金激勵的定期價格餵價更新。

與現有解決方案的區別

特性	Chainlink Automation	Gelato	EXB (本提案)
無許可	否 (需節點許可)	否 (需質押)	是
標準介面	私有	私有	ERC 標準
訂閱制	是	是	否
執行者網路	Chainlink 節點	Gelato 節點	任何人
供應商鎖定	是	是	否
鏈上激勵	否	否	是 (ETH 獎金)
模擬安全	N/A	N/A	是 (eth_call)

核心觀點在於這是一個介面標準，而非協議。沒有中間件，沒有代幣，無需加入網路。合約實作介面，執行者呼叫函數，ETH 獎金流動。

參考實作

完整的參考實作已部署在 Ethereum、Base 和 Arbitrum（透過 CREATE2 實現相同地址）：

TaskRegistry: 0x4B094F689e3edeDd04C439f1BeCDE8b4C800482B

無擁有者，無手續費 —— 無許可的公共財。

原始碼已在所有區塊瀏覽器上驗證。

Etherscan · Basescan · Arbiscan

程式碼庫包含：

ScheduledTaskBase.sol — 具有任務生命週期、CEI 模式、重入保護（ReentrancyGuard）和 ETH 獎金的抽象基底合約。

TaskRegistry.sol — 無許可的鏈上發現機制（無管理員，具備重入安全的註冊）。

DeadMansSwitch.sol — 範例：帶有受益人的遺囑開關。

ScheduledPayment.sol — 範例：單次與循環 ETH 支付。

executor/bot.ts — 參考執行者機器人 (TypeScript)。

執行者機器人已成功在測試網上發現並執行任務，並從中獲利領取獎金。

原始碼: github.com/yashutanna/externally-executable-bounty

安全考量

所有執行路徑均設有 ReentrancyGuard。

CEI 模式 — 在任何外部呼叫（任務狀態、循環重啟）之前更新狀態。

註冊表重入保護 — 在 taskCount() 驗證呼叫前預留註冊位。

模擬友善 — 執行者透過 eth_call 進行預演，以便在花費 Gas 前檢測錯誤的實作。

分頁功能 — 提供 getExecutableTasksPaginated() 和 getActiveContractsPaginated() 以支援大規模擴展。

已記錄實作者誤區 — 如果 _onTaskExecuted() 耗盡了所有 ETH，獎金支付將失敗且任務會卡住。

歡迎回饋

徵求以下方面的回饋：

介面設計 — 是否足夠簡潔？還是太過簡略？

我們可能遺漏的安全考量。

ETH 獎金支付模式中的邊際案例。

現有自動化專案採用此標準的意願。

ERC-165 應該是「必須 (MUST)」還是「應該 (SHOULD)」。

        1 則貼文 - 1 位參與者

        [閱讀完整主題](https://ethereum-magicians.org/t/draft-erc-externally-executable-bounty-a-standard-interface-for-permissionless-task-automation/28002)