4 个版本 (稳定版)

3.0.0 2024年7月11日
2.0.0 2024年5月1日
2.0.0-rc2024年4月25日
1.2.2 2024年1月24日

240 in 魔法豆

Download history 593/week @ 2024-04-16 522/week @ 2024-04-23 814/week @ 2024-04-30 370/week @ 2024-05-07 435/week @ 2024-05-14 634/week @ 2024-05-21 868/week @ 2024-05-28 519/week @ 2024-06-04 1182/week @ 2024-06-11 649/week @ 2024-06-18 639/week @ 2024-06-25 626/week @ 2024-07-02 953/week @ 2024-07-09 798/week @ 2024-07-16 688/week @ 2024-07-23 542/week @ 2024-07-30

3,199 每月下载量
4 个 crate 中使用 (2 个直接使用)

Apache-2.0GPL-3.0-only

75KB
1K SLoC

CW3 规范:MultiSig/Voting 合同

CW3 是基于 CosmWasm 的投票合同规范。它是 CW1 的扩展(它充当了即时 1/N 多签)。在这种情况下,没有密钥可以立即执行,但只能提出一组要执行的消息。提案、后续批准和签名聚合都在链上完成。

在这个规范中,我们至少要涵盖以下 3 种不同的情况

  • K of N 不可变的多签。一个密钥提出一组消息,经过 K-1 个其他人批准后,它可以由多签地址执行。
  • K of N 灵活可变的多签。类似于上面,但涉及多个合同。一个合同存储组,该组被多个多签合同引用(这些多签合同反过来又实现了 cw3)。一个 cw3 合同能够更新组内容(可能需要 67% 投票)。其他 cw3 合同可以持有代币、质押权等,具有各种执行阈值,所有这些都由一个组控制。(组接口和更新它们将在未来的规范中定义,可能是 cw4)。

这应该适合这个接口(可能需要一些针对部分内容的扩展,但外部使用应该看起来相同)。

  • 代币加权投票。人们将代币锁定在合约中以获得投票权。执行消息需要投票阈值。投票集是动态的。这具有类似的“提议、批准、执行”流程,但我们需要支持清晰的赞成/反对投票和投票权,而不仅仅是绝对阈值。

它们的共同点是允许您将任意的CosmosMsg提议给合约,并允许一系列的投票/批准来确定是否可以执行,以及一个最终步骤来执行任何批准的提议。

基础

以下接口必须为所有cw3合约实现。请注意,此处不包含更新投票合约成员的操作(一种方法在cw4中定义)。此外,如何更改阈值规则(如果有的话)并未标准化。这些被视为管理任务,而常见的API是为标准使用设计的,因为这是我们可以标准化最多工具的地方,而不会限制更复杂的治理控制。

消息

Propose{title, description, msgs, earliest, latest} - 这接受Vec<CosmosMsg>并创建一个新的提议。这将返回一个自动生成的ID,在Data字段(以及日志)中,可以用作以后参考该提议。

如果提议者是提议的有效投票者,这将意味着提议者对提议投赞成票,以加快工作流程,特别是在例如2个3个或5个多重签名的情况下,我们不需要在一个区块中提出,得到结果,然后在另一个区块中进行投票。

最早和最晚是可选的,可以请求尝试Execute的第一个和最后一个高度/时间。对于投票,我们可能需要至少2天的时间,但不超过7天。这是可选的,即使设置了,也可能被合约修改(覆盖或仅强制执行最小/最大/默认值)。

许多实现可能希望限制可以提出提议的人。可能只有投票集中的成员。可能需要与提议一起支付一定的押金。这不在规范中,但留给了实现。

发出的属性

"操作" "提议"
"发送者" 消息发送者
"提议ID" 提议的UID
"状态" 新提议状态

Vote{proposal_id, vote} - 给定一个提议ID,您可以投票赞成、反对、弃权或否决。每个已签名的可能有不同的“权重”在投票中,并且它们将它们的全部权重应用于投票。

许多合约(如典型的绝对阈值的典型多重签名)可能将否决权和弃权视为反对,并且仅计算赞成票。具有投票权的合约可能将弃权计入投票权,但不计入赞成或反对票。某些合约可能给予否决权比简单的反对更多的权力,但这可能只是像正常的反对票一样行动。

发出的属性

"操作" "投票"
"发送者" 消息发送者
"提议ID" 提议的UID
"状态" 新提议状态

Execute{proposal_id} - 这将检查给定提议的投票条件是否已通过。如果已成功,则提议被标记为Executed,消息被分发。如果消息失败(例如,超出gas),则所有这些都将回滚,可以在稍后使用更多gas再次尝试。

发出的属性

"操作" "执行"
"发送者" 消息发送者
"提议ID" 提议的UID

Close{proposal_id} - 这将检查给定提案的投票条件是否已失败。如果是的话(例如,时间已过和投票不足),则将提案标记为 Failed。这并非绝对必要,因为它只有在合同根本不可能被执行的情况下才会起作用,但可以触发以提供更好的用户界面。

发出的属性

"操作" "close"
"发送者" 消息发送者
"提议ID" 提议的UID

查询

Threshold{} - 这返回声明合同成功所需规则的信息。投票的百分比以及如何统计。

Proposal{proposal_id} - 返回创建提案时设置的信息,包括当前状态。

ListProposals{start_after, limit} - 返回与 Proposal 相同的信息,但包括分页的所有提案。从提案_id 1开始,按升序排列。

ReverseProposals{start_before, limit} - 返回与 Proposal 相同的信息,但包括分页的所有提案。从最新的提案_id开始,按降序排列。(这通常是用户界面所需的内容)

Vote{proposal_id, voter} - 返回给定投票者(HumanAddr)对提案的投票方式。(可能为null)

ListVotes{proposal_id, start_after, limit} - 返回与 Vote 相同的信息,但包括分页的所有投票。按投票者的地址进行字典序升序排列。

投票者信息

谁可以投票取决于合同。但我们将努力实现一个通用API来显示其中的一些信息。

Voter { address } - 返回该地址的投票权(权重),如果有

ListVoters { start_after, limit } - 列出所有有资格的投票者

依赖项

~5–17MB
~190K SLoC