LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 新闻观点 > 详解最小化反共谋基础设施MACI:链上治理中的抗勾结框架

详解最小化反共谋基础设施MACI:链上治理中的抗勾结框架

2021-11-15 DAOrayaki 来源:区块链网络

作者:Eric Zhang

Architect @DoraFactory @DoraHacks

关于这篇文章的背景,请参考《二次方投票和二次方资助》。在这篇文章发布后的一个月,BSC基金会在DoraHacks开发者平台HackerLink上运行了BSC生态第一轮二次方资助?,并在其后的15天中收到了全球超过60个开发者团队提交的项目。

在《二次方投票和二次方资助》中,我介绍了Vitalik的博客《Quadratic Payments》所提到的三个问题:身份伪造攻击(Identity Bribery)、勾结(Collusion)、理性忽视问题(Rational Ignorance)。这三个问题其实不限于二次方投票,而是链上治理机制所遇到的通用问题。因此,这些问题的解决方案不仅可以使得二次方投票更规模化和更安全,还可以惠及更多链上治理的机制。

这篇文章的目标是为设计一种“非合作二次方投票”,或“抗勾结二次方投票”的机制做准备。在这种场景下,投票者无法相互之间合作,因此就没有了勾结的可能性。这种机制一个基础框架是,Vitalik Buterin在Ethresear上发表的文章《Minimal anti-collusion infrastructure》[1] (MACI)。因此,我们先解释MACI的机制,从而为进一步探讨如何使用MACI改进二次方投票,消除勾结(Collusion)的可能性。

MACI: Minimal Anti-Collusion Infrastructure

MACI是“最小化抗勾结框架”。背景材料参考Vitalik Buterin 的博客https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413 ,以及《On Collusion》 https://vitalik.ca/general/2019/04/03/collusion.html

很多的链上治理应用需要“抗勾结”这个特性,但同时又需要区块链对交易执行以及抗审查、保护隐私的保证。投票是有这种需求的一个重要场景,因为很明显在投票中,抗勾结是必须的,同时对执行结果的正确性的要求是很高的,需要保护计票过程,最后,还需要防止对投票者的审查。

设置

假设有一个智能合约\(R\),包含一个公钥的列表 \(K_1 ... K_n\), 以及一些必要的函数,可以把这些公钥注册到智能合约中。另外,只有符合以下两个条件验证身份的参与者的公钥可以进入到R中:

账户属于一个“合法”的参与者(一个独立的人,某个社区的成员,比如拥有某个国家的国籍、在一个论坛上有足够高的声誉、持有不少于某个数量的Token…)

账户持有人个人控制密钥(例如,如果需要的话,可以打印出来以证明)

每一个用户需要stake一笔钱: 如果任何人泄漏了自己的私钥,那么得到私钥的人可以直接取走这笔钱,从而这个账户就会从列表中被移除。这个机制抑制了任何人把私钥交给别人。

另外,假设有一个操作员(\(operator\)),他有一个私钥\(k_\omega\), 和一个对应的公钥\(K_\omega\).

最后,假设有一个机制 \(M\), 它是一个函数 \(action^n \rightarrow Outputs\), 其中,函数的输入是\(n\)个参与者的行为,输出是这个函数定义的某种输出结果。例如,一个简单的投票机制是一个函数,根据输入的值,输出出现次数最多的那个值。

执行

在起始时间\(T_{start}\),\(operator\)开始一个其实状态\(S_{start} = {i: (key=K_i, action = \phi)}, i \in 1...n\).

在起始时间\(T_{start}\)和结束时间\(T_{end}\)之间,任何注册的参与者可以向R发送消息,消息用参与者自己的私钥\(k\)加密。有两种消息:

约定行为: 例如投票。参与者需要发送加密过的消息 \(enc(msg = (i, sign(msg = action, key = k_i)), pubkey = K_\omega)\), 其中\(k_i\)是这个参与者当前的私钥,\(i\)是参与者在\(R\)中的id

更新密钥: 参与者需要发送加密过的消息\(enc(msg = (i, sign(msg = NewK_i, key = k_i)), pubkey = K_\omega)\), 其中\(NewK_i\)是参与者要变更的公钥, \(k_i\)是这个参与者当前的私钥

这时,操作员的工作是按照消息上链的先后顺序处理每一个消息。具体的处理过程:

使用操作员私钥解密消息。如果解密失败,或者解密对应的信息无法解码成为以上的两类信息,则直接跳过这条信息

使用\(state[i].key\)验证消息的签名

如果解码后的消息是约定的行为(\(action\)),那么设置\(state[i] = action\), 如果解码后的消息是一个新的公钥,那么设置\(state[i].key = NewK_i\)

在\(T_{end}\)之后,操作员必须公布输出状态 \(M(state[1].action, ... , state[n].action)\), 同时给出一个ZK-SNARK,证明这个输出是正确的结果。

为什么这个机制是抗勾结的

假设一个参与者想要证明他做过什么,例如做过\(action\) \(A\),他可以引用一个链上的交易\(enc(msg = (i, sign(msg = A, key = k_i)), pubkey = K_\omega)\),并且提供一个零知识证明,验证这笔交易的确是包含\(A\)的加密信息。但是,他无法证明他没有发出别的交易,例如他可能发出过一笔更早的交易,把公钥换成了一个新的\(NewK_i\),因此前面的证明也就变得没有意义了,因为如果他更换过密钥的话,他可能已经做了别的动作。

参与者还可能把私钥给其他人,但是这样做的话那个人拿到私钥后就可以立即试图修改密钥。这样的话 1) 有50%的成功率,2) 会导致拿到密钥的人直接拿走之前stake的存款。

MACI未解决的问题

接收方在可信硬件环境中,或者接收方在可信多签的情况下,卖出私钥

原有的私钥在一个可信的硬件环境中的攻击,这个环境可以防止私钥变更为任何攻击者们不事先知道的私钥

第一种情况,可以通过特别设计的复杂签名机制,而这种设计对可信硬件和多签不友好。不过这种设计需要确保验证函数对ZKP友好。

第二种情况可以通过“面对面零知识证明”解决,例如,参与者可以把私钥拆解为\(x + y = k_i\),公布\(X = x*G\) 和 \(Y = y*G\), 并且给验证者展示两个信封,分别包含\(x\)和\(y\); 验证者打开一个,检查公布的\(Y\)是正确的,然后检查\(X + Y = K_i\)。

非合作二次方投票

这种机制可以用来改进包括投票在内的多种链上治理机制。在二次方资助中,当资金池规模非常大的时候,或者当二次方资助被用于更大的场景时(例如大选、国会审批预算等场景),勾结就会成为一个必须被解决的问题。因此,设计一个抗勾结二次方投票(Anti-collusion quadratic funding)机制,可以规模化二次方资助。

[1]Vitalik Buterin, Minimal anti-collusion infrastructure,

https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413

—-

编译者/作者:DAOrayaki

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

知识 链上治理
LOADING...
LOADING...