链下投票、链上延迟执行：ERC-3000 乐观治理的排程、质疑与否决

DAO 在链下投完票，金库怎么按结果转账？最省 Gas 的做法不是把每票搬上链，而是只把“将要执行的那串调用”挂上链，给所有人一段时间挑毛病，没人反对就照办。ERC-3000 给这种乐观执行模式定了接口，文件头记录创建于 2020 年 9 月 24 日，仓库记录状态为 Stagnant。作者的定位说得很清楚：标准只框定六个入口函数，仲裁机制那部分刻意开放。

先认数据结构

规范用 Solidity 的 ABI 编码器定义了几层结构。最外层 Container 装着 Payload 和 Config 两部分。Payload 里有 nonce、执行时间 executionTime、提交者 submitter、执行合约 executor、一组 Action 和一个 proof 字段；每个 Action 就是经典的一笔调用三件套——目标地址 to、金额 value、数据 data。Config 里放延迟时长 executionDelay、三笔押金（排程保证金 scheduleDeposit、质疑押金 challengeDeposit、否决押金 vetoDeposit，各自都是“代币地址加数量”的 Collateral 结构）、仲裁合约 resolver 地址，以及一段规则文本 rules。

这套结构透露出整个机制的形状：一笔链下决定被压成“若干笔 EVM 调用加一个到期时间”，连同治理参数一起上链，等待被质疑或生效。

四个必选函数、两个可选函数

schedule(Container) 把一个容器挂上排程，返回容器哈希，成功时发 Scheduled 事件并收取排程方押金。execute(Container) 在延迟期满且状态没被质疑或否决改动过时执行，规范用 MUST 措辞要求它必须落到对 executor 那组 Action 的执行上，发 Executed 事件。challenge(Container, reason) 由任何人发起质疑，从发起方拉押金和争议费进合约，返回一个 resolverId 指向仲裁系统里的案子，发 Challenged 事件。resolve(Container, resolverId) 在仲裁出最终裁决后由任何人应用，执行或回滚对应容器，发 Resolved 事件，事件里带一个布尔 approved。

可选的两个：veto 允许持有者凭押金直接否决某个载荷哈希，发 Vetoed 事件；configure 更新后续新排程的治理参数，规范规定第一次 Configured 事件必须发出。所有函数统一遵循“条件不满足就失败回滚、成功则恰好发一次对应事件”的模式。

仲裁被刻意留活

规范在多处强调同一件事：质疑怎么裁决，不属于本标准硬性规定。作者自述当前倾向主观预言机式的仲裁（并点名了对应实践），但设计上保证换成确定性裁决器——比如乐观汇总方案那种——同样兼容，甚至可以在同一个线上实例里热切换。安全考量部分给了两种路线各自的代价：主观预言机的安全系于系统的加密经济属性，需要看质押者的激励设计；确定性裁决器则复杂度高、易藏漏洞，还依赖链下协议版本，而协议在标准成熟前可能快速演化。

对读治理页面的人，这意味着一个具体动作：看到 ERC-3000 形状的治理合约时，去 Config 里读 resolver 地址是谁、rules 那段文本写的什么、三笔押金数量——延迟多久、质疑一次押多少、谁能 veto，全部在链上可读，不需要听转述。

读者最常问的三个问题

第一个问题：这种治理比每笔投票都上链安全吗？两者风险形状不同——链上直执的失误当场可见，乐观模式的失误藏在延迟窗口里，窗口内有人盯着才有纠错；把链下投票的结果当成“已通过审计”是理解偏差，排程进容器的只是调用序列本身。第二个问题：错过质疑期还能补救吗？标准提供的补救只有执行前路径——质疑、否决、仲裁改判都在执行之前；execute 一旦发出且条件满足，规范要求它必须执行那组 Action，事后追悔没有接口。第三个问题：押金去哪了？规范只写明发起质疑时要把押金和争议费从发起方拉进合约，并在 Challenged 事件里记录这笔 Collateral；最终怎么判给谁，规范刻意不写死，交给 resolver 与 rules 文本处理——这正是读配置时最该看的一段。三个问题的答案要么在合约参数里，要么在规则文本里，不在任何治理平台的宣传页里。

这套模式的风险常识

乐观执行的通用弱点在这份标准的结构里都有对应物：延迟窗口是纠错的唯一窗口，错过质疑期的容器会照常执行；押金额度决定质疑成本，太高的质疑押金本身就是一种审查；veto 权若归属不透明，可能变成少数人的急刹车。标准把这些都做成了可配置参数，也等于承认配置不当的同类接口在文字上仍然合规。仓库状态 Stagnant 提示这套接口没有大规模部署背书，读它时把它当作理解“先挂起、后生效”这一治理模式的技术样本，比当作选型清单更合适。本文为机制说明，不构成任何投资建议。