您的位置 首页 资讯

DAOrayaki |MACI 中的匿名化

感谢@vbuterin 提出这个想法,感谢@barryWhiteHat 的合作。本文所描述的是向 MACI 添加匿名化的无 MPC 替代方案。

MACI简介

Mkey_change-用户希望更改与其状态关联的当前密钥。具体来说他们发布:

其中密钥 ki 是用户的私钥, i是他们在注册表 R 中的索引,NewKi 是他们的新公钥。运营商按消息发布的顺序处理消息,如下所示:

对于无效消息 – 解密失败、未知类型或格式错误的消息 – 不进行操作。

证明:

处理按顺序对所有已发布的消息进行。每条处理过的消息要么无效,要么签名未验证——不会导致状态发生变化,或者消息是 Maction类型或Mkey_change类型之一并且对状态应用了适当的更新。

匿名问题

一切都隐藏在链上——用户只发布密文。但是,运营商会看到每个密钥执行的所有操作,因为它们必须更新状态并在最后生成正确性证明。

理想情况下,我们希望运营商只负责对抗共谋,而不知道哪个用户采取了什么行动。

解决方案—重新随机化解决方案

协议

设 H 是一个密码哈希函数。运营商发布一个 ElGamal 公钥 Ew 和私钥 ew。

运营商管理以下两组集合:

2. Mnew_key_from_deactivated – 用户希望注册一个新密钥,前提是他们之前停用了一个密钥。

简要分析

链上数据:

效率问题 – 证明一个元素在(nullifier)集合中不存在是线性复杂度的,或者更新它为是线性复杂度的。这会影响证明时间,不过它仍然实用。

热门文章

发表评论

您的电子邮箱地址不会被公开。