Alert Source Discuss
🚧 Stagnant Standards Track: ERC

ERC-2767: 合约所有权治理

Authors Soham Zemse (@zemse), Nick Mudge (@mudgen)
Created 2020-07-04
Discussion Link https://github.com/ethereum/EIPs/issues/2766
Requires EIP-20, EIP-165, EIP-173

简单概要

一个治理合约的标准,该合约持有其他智能合约的管理所有权,投票权分配为 ERC-20 代币。

摘要

以下标准定义了基于 ERC-20 的治理智能合约的标准 API 的实现。 现有的与 ERC-173 兼容的合约可以从私钥钱包所有权升级到治理智能合约。 遵守标准 API 使通用工具能够填充各种项目的治理信息,从而提高透明度。

动机

传统上,许多要求以某种方式拥有或控制的合约都使用 ERC-173,它标准化了智能合约中所有权的使用。 例如,提取资金或执行管理操作。

contract dApp {
  function doSomethingAdministrative() external onlyOwner {
    // admin logic that can be performed by a single wallet
    // 可以由单个钱包执行的管理逻辑
  }
}

通常,合约的此类管理权限是为了维护目的而编写的,但用户需要信任所有者。 所有者的救援操作引发了对项目去中心化性质的质疑。 此外,所有者的私钥也可能被泄露。

目前,许多雄心勃勃的项目的治理实现都需要用户访问特定的 UI 才能查看其项目的治理信息。 一些具有不同 API 的实时实现执行相同的操作,例如 Compound Governance, Uniswap GovernanceSushiswap Governance。 这就像 ERC-20 标准尚未最终确定一样,那么代币项目将拥有自己的区块浏览器。 遵守标准 API 将使通用工具(如 Etherscan)能够填充治理信息,从而提高用户透明度。 使用广泛流行的 ERC-20 代币作为治理代币,为 ERC-20 构建的现有工具已经可以显示选民。 与基于私钥的所有权相比,这可能会导致合约治理的广泛采用。

规范

符合 ERC-2767 的治理合约应实现以下接口:

/// @title ERC-2767 Governance
/// @dev ERC-165 InterfaceID: 0xd8b04e0e
interface ERC2767 is ERC165 {
    /// @notice Gets number votes required for achieving consensus
    // 获取达成共识所需的票数
    /// @dev Should cost less than 30000 gas
    // 应花费少于 30000 gas
    /// @return Required number of votes for achieving consensus
    // 达成共识所需的票数
    function quorumVotes() external view returns (uint256);

    /// @notice The address of the Governance ERC20 token
    // 治理 ERC20 代币的地址
    function token() external view returns (address);
}

ERC-20 治理代币

ERC-2767 治理合约应该通过 token() 引用实现 ERC-20 接口的地址。 如果 ERC-20 功能在同一合约中实现,则允许 token() 返回自身地址 (address(this))(可以考虑查看 Diamond Standard ERC-2535 以优化合约大小)。

允许实现具有不同的 ERC-20totalSupply()(通过任何标准铸造或销毁)。 但是在这种情况下,具有固定的 quorumVotes() 返回值会导致相对于 totalSupply()% 中所需的投票共识发生变化。 为了自动解决这个问题,允许 quorumVotes() 下的任何自定义逻辑返回例如 totalSupply()51%

ERC-165 接口识别

ERC-2767 治理合约也应该实现 ERC-165。 这有助于通用工具识别合约是否为 ERC-2767 治理合约。

interface ERC165 {
    /// @notice Query if a contract implements an interface
    // 查询合约是否实现了接口
    /// @param interfaceID The interface identifier, as specified in ERC-165
    // 接口标识符,如 ERC-165 中指定
    /// @dev Interface identification is specified in ERC-165. This function
    // 接口标识在 ERC-165 中指定。 此函数
    ///  uses less than 30,000 gas.
    // 使用少于 30,000 gas。
    /// @return `true` if the contract implements `interfaceID` and
    // 如果合约实现了 `interfaceID` 并且
    ///  `interfaceID` is not 0xffffffff, `false` otherwise
    // `interfaceID` 不是 0xffffffff,否则为 `false`
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

理由

本 EIP 的目标如下:

  • 标准化治理合约的 API,以便轻松构建分析工具。
  • 鼓励使用基于 ERC-20 的加权治理,而不是现有的大型项目的多重签名(通常限制为最多 50 个所有者)。
  • 通过消除为其项目托管自定义 UI 所需的努力,鼓励现有的 ERC-173 所有权智能合约/项目迁移到基于治理的所有权。
  • 鼓励公开审计的治理合约的可用性,就像任何人都可以使用的 ERC-20 一样。
  • 使利用现有的 ERC-20 工具进行治理代币所有者分析成为可能。
  • 使需要与多个项目的治理互动的未来协议成为可能。
  • 保持此 EIP 的最小化,并允许其他 EIP 标准化任何特定功能。

向后兼容性

符合 ERC-173 的智能合约可以将其所有权转让给治理合约。 这使此类合约与 ERC-2767 治理兼容。

但是,有一些现有的具有治理实施的项目,并且它们中的大多数都具有自定义 API (Compound Governance, Uniswap GovernanceSushiswap Governance),因为不存在标准。 不使用兼容 ERC-2767 的治理合约仅意味着通用工具可能无法填充其治理信息,而无需为该项目包含一些特殊代码。

为了使现有的治理合约与 ERC-2767 兼容:

  1. 项目可以部署新的治理合约并将所有权转移到该合约以使其与 ERC-2767 兼容。 这适用于那些使用多重签名钱包进行治理的人。
  2. 据了解,重新部署治理合约将是一项麻烦的任务,并且已经具有类似于基于 ERC-20 的(加权投票)功能的合约,有一种更高级的方法可以避免这种情况。 基本上,他们可以创建一个转发器合约来实现 ERC-2767 并将所有调用转发到实际的非标准方法。 项目可以列出转发器合约以显示项目治理信息,而无需分析工具中的任何自定义代码,但这可能有一些限制,具体取决于项目现有的治理实施。 转发器合约的规范不在本 EIP 的范围内,如果需要,可以在另一个 EIP 中解决。

实现

参考实现可以在这个 repository 中找到。 公开审计的实现将在未来包含在内。

安全考虑

实施者可以自由选择链上和链下共识。 确切的规范不在本标准的范围内(开放供其他 EIP 标准化)。 但是,本节介绍了实施者可以考虑的要点。

链上

在此类实现中,社区可以创建交易提案并通过发送链上交易对其进行投票。

  • OpenZeppelin Snapshots 可用于防止重复投票。

链下

  • 链下治理实施中的签名可以遵循 ERC-191ERC-712 的建议。
  • 为了防止重放签名,最好要求执行者根据增加的地址对签名进行排序。

版权

版权及相关权利通过 CC0 放弃。

Citation

Please cite this document as:

Soham Zemse (@zemse), Nick Mudge (@mudgen), "ERC-2767: 合约所有权治理 [DRAFT]," Ethereum Improvement Proposals, no. 2767, July 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2767.