Alert Source Discuss
⚠️ Draft Standards Track: ERC

ERC-1202: 投票接口

用于链上投票的通用接口

Authors Zainan Victor Zhou (@xinbenlv), Evan (@evbots), Yin Xu (@yingogobot)
Created 2018-07-08
Discussion Link https://ethereum-magicians.org/t/eip-1202-voting-interface/11484
Requires EIP-5269

摘要

此 EIP 是一个使用智能合约实现投票的 API。此标准提供投票功能,以及查看投票结果和设置投票状态。

动机

投票是 EVM 编程的最早示例之一,也是 DAO/组织治理流程的关键。我们预见到许多 DAO 最终需要利用投票作为其治理的重要组成部分。通过为智能合约/代币创建投票标准,我们可以获得以下好处

拥有标准的好处

  1. 允许构建在标准化投票之上的通用 UI 和应用程序,以允许更多普通用户参与,并鼓励更多 DApp 和 DAO 考虑其治理
  2. 允许委托投票/智能合约投票、自动投票
  3. 允许以标准方式将投票结果记录在链上,并允许 DAO 和 DApp 以编程方式遵守投票结果。
  4. 允许与 ERC-20 等代币标准或其他新标准(ERC-777)以及 ERC-721 等物品标准兼容
  5. 为以太坊生态系统和其他系统内的互操作性创造巨大的潜力。
  6. 允许设置投票截止日期,允许确定单项或多项选择。允许要求投票顺序。(权衡是接口复杂性,我们可能需要 ERC-20 方法,稍后需要 ERC-777 进行高级投票)
  7. 记录具有代币数量权重的投票。
  8. 可能允许值得信赖的隐私安全投票和匿名投票(选民地址与他们所投的票无关,给定一个随机/混淆的投票选项列表)。
  9. 可能允许通过投票参与或投票结果获得奖励。

非目标/超出范围

  1. 委托:我们有意将委托排除在范围之外。可以提出一个单独的 EIP 来解决这个特定用例。
  2. 资格或权重:一些实施者希望投票的权重或资格是可配置的。例如,OpenZeppelin 的 GovernorBravo 实现使用快照。此外,诸如二次投票之类的权重计算不在此 EIP 的范围内。此 EIP 旨在灵活适用于 任何当前和新的投票权重计算。
  3. 提议:我们有意将提议排除在范围之外。提议将由 proposalId 标识,但提议包含哪些信息, 无论它们是在链上还是链下,以及它们是否可执行,都从本提案中删除。可以提出一个单独的 EIP 来解决这个特定用例。请参阅此类提案之一 ERC-5247
  4. 签名聚合/背书:当实现合约想要允许用户离线提交他们的投票或投票批准,并让其他 帐户生成交易时,签名聚合或背书不在此 EIP 的范围内。可以提出一个单独的 EIP 来解决这个特定用例。请参阅此处的此类提案之一 ERC-5453

用例

  1. 确定发行新代币、发行更多代币或发行子代币
  2. 确定在 ERC-721 下创建新项目
  3. 确定选举某人或智能合约作为项目或子项目的委托领导
  4. 确定审计结果所有权,允许迁移智能合约代理地址

规范

  1. 兼容合约必须实现下面的 IERC1202Core
interface IERC1202Core {
    event VoteCast(
        address indexed voter,
        uint256 indexed proposalId,
        uint8 support,
        uint256 weight,
        string reason,
        bytes extraParams
    );

    function castVote(
        uint256 proposalId,
        uint8 support,
        uint256 weight,
        string calldata reasonUri,
        bytes calldata extraParams
    ) external payable returns;

    function castVoteFrom(
        address from,
        uint256 proposalId,
        uint8 support,
        uint256 weight,
        string calldata reasonUri,
        bytes calldata extraParams
    ) external payable returns;

    function execute(uint256 proposalId, bytes memory extraParams) payable external;
}
  1. 兼容合约可以实现 IERC1202MultiVote 接口。如果目的是支持多选项,例如用于排名选择 或变体权重投票,则兼容合约必须实现 IERC1202MultiVote 接口。
interface IERC1202MultiVote {
    event MultiVoteCast(
        address indexed voter,
        uint256 indexed proposalId,
        uint8[] support,
        uint256[] weight,
        string reason,
        bytes extraParams
    );

    function castMultiVote(
        uint256 proposalId,
        uint8[] support,
        uint256[] weight,
        string calldata reasonUri,
        bytes calldata extraParams
    ) external payable;
}
  1. 兼容合约应实现 ERC-5269 接口。

获取信息:投票期、资格、权重

interface IERC1202Info {
    function votingPeriodFor(uint256 proposalId) external view returns (uint256 startPointOfTime, uint256 endPointOfTime);
    function eligibleVotingWeight(uint256 proposalId, address voter) external view returns (uint256);
}

原理

我们做出了以下设计决策,以下是原理。

粒度和匿名性

我们创建了一个 view 函数 ballotOf,主要目的是让人们更容易检查来自某个地址的投票。 这有以下假设:

  • 可以直接通过地址检查某人的投票。如果实施者不想使其如此容易,他们可以简单地拒绝所有对此函数的调用。我们想确保我们支持匿名投票和非匿名投票。但是,由于对智能合约的所有调用都记录在区块历史记录中,因此除非使用密码学技巧,否则实际上没有保密性。我没有足够的密码学知识来评论这种可能性。 请参阅“2018 年第二次反馈问题”以了解相关主题。

  • 它假设对于每个单独的地址,他们只能为一个决定投票。他们可以将他们可用的投票权分配到更精细的级别。如果实施者想要允许这样做,他们会要求用户创建另一个钱包地址,并授予新地址一定的权力。例如,基于代币的投票,其中投票权重由选民持有的代币数量决定,想要将其投票权分配到两个不同选项(选项集)中的选民可以将一些代币转移到新帐户,并从两个帐户投出选票。

权重

我们假设投票存在weight,并且可以通过调用eligibleVotingWeight(proposalId, address voter)来检查,并且权重分配要么由内部决定,要么由构造函数决定。

向后兼容性

  1. 选择 support 选项为 uint8 的目的是为了向后兼容 GovernorBravo。将来可以增加

安全考虑

我们希望投票标准与其他合约结合使用,例如代币分配、以共识方式或代表实体执行操作、多重签名钱包等。

主要的安全性考虑是确保仅使用标准接口来执行下游操作或接收上游输入(投票)。 我们希望未来的审计工具基于标准接口。

同样重要的是要注意,正如本标准中所讨论的那样,为了简单起见,此 EIP 保持在非常基本的形式。 它可以扩展以支持许多不同的实现变体。 这种变体可能包含对行为和操作解释的不同假设。 一个例子是:如果有人通过 vote 多次投票,这意味着什么?

  • 这是否意味着选民正在增加他们的权重,或者
  • 同时投票多个选项,或者
  • 后一次投票是否会覆盖前一次投票?

由于投票的灵活性,我们预计需要创建许多后续标准作为此 EIP 的扩展。 我们建议在将此标准的任何扩展或实现包含在大型或高资产量应用程序中之前进行彻底审核。

第三个考虑因素是非平凡性。 一些投票应用程序假设匿名性随机性基于时间的截止日期排序等,已知这些要求在以太坊中不容易实现。 我们建议当需要在其应用程序中强制执行这些要求时,任何依赖经过审计和经过时间考验的共享库的应用程序或组织。

第四个考虑因素是潜在的滥用。 当投票标准化并放入合约中时,可以编写另一个合约来奖励选民以某种方式投票。 这会产生以前难以实施的贿赂和利益冲突滥用的潜在问题。

版权

CC0 下放弃版权和相关权利。

Citation

Please cite this document as:

Zainan Victor Zhou (@xinbenlv), Evan (@evbots), Yin Xu (@yingogobot), "ERC-1202: 投票接口 [DRAFT]," Ethereum Improvement Proposals, no. 1202, July 2018. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1202.