ERC-3000: 乐观执行治理标准
Authors | Jorge Izquierdo (@izqui), Fabien Marino (@bonustrack) |
---|---|
Created | 2020-09-24 |
Discussion Link | https://github.com/ethereum/EIPs/issues/3042 |
简单总结
用于基于链下批准来安排、执行和挑战合约执行的接口
摘要
ERC-3000 提出了一个基本的链上规范,供合约乐观地执行链下做出的治理决策。
该标准在定义支持该标准的合约的 6 个入口点函数方面具有主观性。但它允许用于乐观合约的挑战/响应博弈的任何类型的解析器机制。
虽然作者目前认为使用主观预言机解决挑战是正确的权衡,但该标准的设计使得更改为另一种机制是可能的(像 Optimism’s OVM 使用的确定性解析器),甚至允许在同一实时实例中热插拔它。
规范
数据结构
定义了一些数据结构,这些数据结构稍后将在标准接口中使用:
library ERC3000Data {
struct Container {
Payload payload;
Config config;
}
struct Payload {
uint256 nonce;
uint256 executionTime;
address submitter;
IERC3000Executor executor;
Action[] actions;
bytes proof;
}
struct Action {
address to;
uint256 value;
bytes data;
}
struct Config {
uint256 executionDelay;
Collateral scheduleDeposit;
Collateral challengeDeposit;
Collateral vetoDeposit;
address resolver;
bytes rules;
}
struct Collateral {
address token;
uint256 amount;
}
}
接口和事件
给定上述数据结构,通过利用 Solidity ABI encoder v2,我们将四个必需函数和两个可选函数定义为合约符合 ERC-3000 的接口。
当不满足前提条件或发生意外错误时,所有标准函数都应恢复(是否将错误消息/恢复原因作为标准的一部分包含在内还有待确定)。成功后,每个函数必须有且只有一个地发出其关联的事件。
abstract contract IERC3000 {
/**
* @notice 安排一个操作以供执行,允许在定义的时间窗口内进行挑战和否决
* @param container 一个 Container 结构体,包含计划执行的 paylaod 和
系统的当前配置
*/
function schedule(ERC3000Data.Container memory container) virtual public returns (bytes32 containerHash);
event Scheduled(bytes32 indexed containerHash, ERC3000Data.Payload payload, ERC3000Data.Collateral collateral);
/**
* @notice 在其执行延迟过去后执行一个操作,并且其状态未被挑战或否决修改
* @param container 一个 ERC3000Data.Container 结构体,包含计划执行的 paylaod 和
系统的当前配置
* 应该是 MUST payload.executor.exec(payload.actions)
*/
function execute(ERC3000Data.Container memory container) virtual public returns (bytes[] memory execResults);
event Executed(bytes32 indexed containerHash, address indexed actor, bytes[] execResults);
/**
* @notice 如果容器的调度根据 Config.rules 是非法的,则挑战容器。将抵押品和争议费用从发送者提取到合约中
* @param container 一个 ERC3000Data.Container 结构体,包含计划执行的 paylaod 和
系统的当前配置
* @param reason 提示案例审查员为什么计划的容器是非法的
*/
function challenge(ERC3000Data.Container memory container, bytes memory reason) virtual public returns (uint256 resolverId);
event Challenged(bytes32 indexed containerHash, address indexed actor, bytes reason, uint256 resolverId, ERC3000Data.Collateral collateral);
/**
* @notice 一旦仲裁员做出最终裁决,就可以对挑战应用仲裁员的裁决
* @param container 一个 ERC3000Data.Container 结构体,包含计划执行的 paylaod 和
系统的当前配置
* @param resolverId 仲裁员中创建的container争议中的 disputeId
*/
function resolve(ERC3000Data.Container memory container, uint256 resolverId) virtual public returns (bytes[] memory execResults);
event Resolved(bytes32 indexed containerHash, address indexed actor, bool approved);
/**
* @dev 可选
* @notice 一旦仲裁员做出最终裁决,就可以对挑战应用仲裁员的裁决
* @param payloadHash 被否决的 payload 的哈希值
* @param config 一个 ERC3000Data.Config 结构体,它保存附加到被否决的 payload 的配置
*/
function veto(bytes32 payloadHash, ERC3000Data.Config memory config, bytes memory reason) virtual public;
event Vetoed(bytes32 indexed containerHash, address indexed actor, bytes reason, ERC3000Data.Collateral collateral);
/**
* @dev 可选:实现者可以选择不实现(必须发出初始的 Configured 事件)
* @notice 为所有*新的* 计划容器应用新的配置
* @param config 一个 ERC3000Data.Config 结构体,包含将控制队列的所有新参数
*/
function configure(ERC3000Data.Config memory config) virtual public returns (bytes32 configHash);
event Configured(bytes32 indexed containerHash, address indexed actor, ERC3000Data.Config config);
}
理由
作者认为,对于此标准而言,最重要的是让其他标准可以实现和采用任何解析器机制。
这就是为什么许多函数和变量名称都被故意保留为虚假名称,以便与未来的解析器兼容,而无需更改标准。
ERC-3000 应该被视为一种公共产品,公共基础设施将在其之上构建,这比任何特定的实现或特定公司或项目的利益都重要得多。
安全考虑
该标准允许配置挑战的解析器,甚至允许为共存的计划负载配置不同的解析器。选择正确的解析器需要在安全性、最终确定时间、实现复杂性和外部依赖性之间做出正确的权衡。
使用主观预言机作为解析器存在风险,因为安全性取决于系统的加密经济特性。有关 Aragon Court 加密经济考虑因素的分析,您可以查看以下文档。
另一方面,由于其复杂性,实现确定性解析器容易出现危险的错误,并且将依赖于特定版本的链下协议,该协议可能会在标准成熟并被采用时迅速发展。
实现
1. Aragon Govern
版权
版权及相关权利通过 CC0 放弃。
Citation
Please cite this document as:
Jorge Izquierdo (@izqui), Fabien Marino (@bonustrack), "ERC-3000: 乐观执行治理标准 [DRAFT]," Ethereum Improvement Proposals, no. 3000, September 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-3000.