4 个版本 (稳定版)
3.0.0 | 2024年7月11日 |
---|---|
2.0.0 | 2024年5月1日 |
2.0.0-rc | 2024年4月25日 |
1.2.2 | 2024年1月24日 |
240 in 魔法豆
3,199 每月下载量
在 4 个 crate 中使用 (2 个直接使用)
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