52 个版本 (6 个稳定版本)

2.0.0 2024年3月26日
1.1.2 2023年11月23日
1.1.0 2023年6月20日
1.0.1 2022年12月19日
0.3.2 2020年10月28日

#1203 in 神奇豆

Download history 1780/week @ 2024-04-22 1601/week @ 2024-04-29 1489/week @ 2024-05-06 1416/week @ 2024-05-13 1848/week @ 2024-05-20 1150/week @ 2024-05-27 1611/week @ 2024-06-03 1662/week @ 2024-06-10 1640/week @ 2024-06-17 1395/week @ 2024-06-24 1772/week @ 2024-07-01 1309/week @ 2024-07-08 1725/week @ 2024-07-15 2035/week @ 2024-07-22 1822/week @ 2024-07-29 1393/week @ 2024-08-05

7,057 个月下载量
23 个crate中使用 (5 个直接使用)

Apache-2.0

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)。

这个接口应该适合这里(可能需要一些扩展,但外部使用方式应该相同)

  • 代币加权投票。人们将代币锁定在合约中以获得投票权。执行消息存在投票门槛。投票集合是动态的。这具有类似的“提议、批准、执行”流程,但我们需要支持明确的YES/NO投票和Quora,而不仅仅是绝对门槛。

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

基础

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

消息

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

如果提案人是该提案的有效投票者,则这表示提案人投赞成票,以实现更快的流程,这在例如2个3或5个多重签名中特别有用,我们不需要在一个块中提出,获取结果,然后在另一个块中进行投票。

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

许多实现将想要限制可以提出的人。可能是投票集中的每个人。可能需要与提案一起支付某些押金。这不在规范中,但留给了实现。

发出的属性

"action" "propose"
"sender" 消息发送者
"proposal_id" 提案的UID
"status" 新提案状态

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

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

发出的属性

"action" "vote"
"sender" 消息发送者
"proposal_id" 提案的UID
"status" 新提案状态

Execute{proposal_id} - 这将检查给定提案的投票条件是否已通过。如果成功,提案将被标记为 Executed,并且消息将被分发。如果消息失败(例如,超出gas),则所有这些将被撤销,可以在以后有更多gas的情况下再次尝试。

发出的属性

"action" "execute"
"sender" 消息发送者
"proposal_id" 提案的UID

Close{proposal_id} - 这将检查给定的提案是否满足投票条件失败。如果是的话(例如,时间已过期且票数不足),则该提案会被标记为 Failed。这并非绝对必要,因为只有在合同永远无法执行的情况下才会执行,但它可以被触发以提供更好的UI。

发出的属性

"action" "close"
"sender" 消息发送者
"proposal_id" 提案的UID

查询

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

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

ListProposals{start_after, limit} - 返回与 Proposal 相同的信息,但对于所有提案以及分页。从 proposal_id 1 开始,按升序。

ReverseProposals{start_before, limit} - 返回与 Proposal 相同的信息,但对于所有提案以及分页。从最新的 proposal_id 开始,按降序。(这通常是UI所需的内容)

Vote{proposal_id, voter} - 返回指定投票者(HumanAddr)对提案的投票情况。(可能为空)

ListVotes{proposal_id, start_after, limit} - 返回与 Vote 相同的信息,但对于所有投票以及分页。按投票者的地址按字典顺序排序返回。

投票者信息

可以投票的信息取决于合同。但我们将努力开发一个公共API来显示其中的一些信息。

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

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

依赖项

~3.5–7MB
~144K SLoC