通过全员投票来攻击DAO合约的可能性

[lurenpluto]

1. 修改委员会的操作接口

addCommitteeMember
removeCommitteeMember
setCommittees

最后生成依赖的params列表基本都是一个或者多个number address，加上一个字符串，表示此次的proposal的目的
比如:

setCommittees([addr1, addr2, addr3])

那么生成的params列表如下：

params: [addr1, addr2, addr3, "setCommittees"]

但这个参数列表是可以直接通过其它的投票purposal来直接生成的，比如全员投票

2. 全员投票
   发起全员投票的接口如下

function fullPropose(
        uint duration,
        bytes32[] memory params,
        uint threshold
    ) external override returns (uint proposalId) 

由于params是外部可以完全指定，那么可以指定成上面的setCommittees的参数列表，然后生成一个proposal
只要这个proposal被投票通过了，那么直接拿这个proposalId，来调用setCommittees，一样可以通过其中_takeResult的检查，因为参数一致，并且结果也是Accept

3. 基于上述的情况，几乎所有的操作，包括修改委员会，合约升级，都可以通过全员投票来生成提案并通过，然后基于这个accept的提案，进行对应的操作

4. 问题在于，现在全员投票的门槛极低，看fullPropose的接口：

• duration 没有任何限制，所以可以设计一个极短的时间间隔
• params 可以是任意参数列表，包括最后一个操作类型的字符串(很多操作都有附加)
• threshold 最低可以设置10，这个是最大的问题所在

所以基于这个假设，只要有一个人掌握了大约10%的已释放token，就几乎获得了对合约所有的操作权：
可以创建一个duration极小，threshold=10的全员投票，指定好攻击参数，那么就可以自己立刻投票并结算，然后进行目标的攻击操作

通过上述操作，可以升级合约，把所有token都释放到自己名下，从而进一步控制整个DAO组织

5. 所以上述的核心，就是需要改进全员投票的设计：

• duration必须增加最短时间间隔
  对于全员投票这种重大事情，时间最少应该是一到两周

• params 内部需要强制在后面追加一个字符串参数，用作操作类型
  也可以强制发起者最后一个字符串参数，并且不可以是特定的敏感操作比如升级合约之类

• threshold 这个不可以小于50
  任何全员投票，都应该满足半数原则，避免类似区块链的50%攻击

[waterflier]

duration最小肯定是需要一周的
我们是否可以让duration的最小值与threshold 相关？ 门槛值越低，duration的最小值越大
而且，threshold 的最小值也应该是一个DAO的变量（和Devtoken的N类似），这个变量从10%开始，只允许变大。

[lurenpluto]

threshold

”10%的人同意就通过“ 我觉得这个失去了全员投票的意义了， 占比太少了，如果不能做到半数，那么至少也要三分之一

[weiqiushi]

• threshold的基数是什么？如果是总token数，可以设置成最小34%。如果是当前已释放数，可以设置成最小51%
• duration可以加一个最小7天的限制
• 组织以后是否会有"链下"提案？即不和任何链上逻辑绑定，链下"执行"，链下"监督"？如果确保没有链下提案的话，可以限制只有dao的合约可以调用fullPropose接口，确保提案一定和一个实际动作绑定

[lurenpluto]

• threshold的基数是什么？如果是总token数，可以设置成最小34%。如果是当前已释放数，可以设置成最小51%
• duration可以加一个最小7天的限制
• 组织以后是否会有"链下"提案？即不和任何链上逻辑绑定，链下"执行"，链下"监督"？如果确保没有链下提案的话，可以限制只有dao的合约可以调用fullPropose接口，确保提案一定和一个实际动作绑定

threshold应该都是以“当前已经释放的token”作为基数的，如果按照总数，那不确定因素太多了，而且随着释放这个投票通过率也在不断变化也不合理的

fullPropose这个如果只有特定的提案可以使用，那么就要确保fullPropose创建的提案只有能应用于这个场景，可以增加额外的参数来保证

[weiqiushi]

代码已更新，增加几个限制逻辑：

• 只有DAO合约才能调用propose和fullpropose接口创建提案。这保证了提案一定和某个具体合约逻辑相关联。不允许外部用户随意创建提案
• fullPropose的duration最小为7天，threshold最小为34
• threshold的基数为结算时已释放的token
• setCommittees的duration为7天，threshold为51

[weiqiushi]

而且，threshold 的最小值也应该是一个DAO的变量（和Devtoken的N类似），这个变量从10%开始，只允许变大。

这个逻辑其实没有什么必要。我们可以设定一个所有fullpropose都必须遵守的最小值(比如34)。可以认为小于这个值的投票都没有"全员"的意义。在这个基础上，再为每一个具体事项设定一个它自己的threshold。比如设置委员会的threshold，就必须是51.....

但是否要考虑以下情况？如果拥有token最多，第二多的人私钥丢失，是否有永远不能通过任何全员投票的风险？

[weiqiushi]

而且，threshold 的最小值也应该是一个DAO的变量（和Devtoken的N类似），这个变量从10%开始，只允许变大。

这个逻辑其实没有什么必要。我们可以设定一个所有fullpropose都必须遵守的最小值(比如34)。可以认为小于这个值的投票都没有"全员"的意义。在这个基础上，再为每一个具体事项设定一个它自己的threshold。比如设置委员会的threshold，就必须是51.....

但是否要考虑以下情况？如果拥有token最多，第二多的人私钥丢失，是否有永远不能通过任何全员投票的风险？

[weiqiushi]

代码已更新，增加几个限制逻辑：

• 只有DAO合约才能调用propose和fullpropose接口创建提案。这保证了提案一定和某个具体合约逻辑相关联。不允许外部用户随意创建提案
• fullPropose的duration最小为7天，threshold最小为34
• threshold的基数为结算时已释放的token
• setCommittees的duration为7天，threshold为51

• fullPropose接口本身的threshold限制改回为> 10
• setCommittees在全员投票的情况下，threshold改为40
• 目前只有DAO的子合约可以调用propose和fullpropose接口