弥合链上治理的隐私差距

链上治理已经成为主流 - 但每一次公开投票都是一个可以被购买和胁迫的信号。在决策方式上仍然存在巨大的隐私缺口。Shutter 旨在通过链上 Shielded Voting 来帮助弥合这一差距。

在过去的两年里，链上治理已经从利基实验跃升为许多最大的加密网络和 DAO 的事实控制层。虽然这种透明性赋予了社区权力，但它也创造了一个新的攻击面：每一次投票都是一个公开信号——一个可以被购买、胁迫、抢先交易，甚至受到社会惩罚的信号。这导致人们提出这样的问题：我们能否在不暴露个人投票选择的情况下保持可验证性？

Vitalik 说得最好：治理需要隐私

自从 Vitalik Buterin 在 5 月 21 日发布推文，提醒生态系统 “正如我们在金融和通信中需要隐私一样，我们在治理中也需要隐私” 以来，这个问题变得尤为紧迫。他的观点很简单但深刻：金融和通信已经是治理的形式。如果我们想要可信的机构，那么保护治理层本身是不可谈判的。

Twitter 嵌入

MACI 等团队的工作，以及 https://t.co/Wy6p7Wftsz, https://t.co/hO2b3653mu 等等，非常重要。

除了金融和通信中的隐私外，我们还需要治理中的隐私。

（事实上，我们需要前两者，部分原因是金融和通信是治理）https://t.co/74ySRzxPIW

— vitalik.eth (@VitalikButerin) 2025 年 5 月 21 日

回应呼吁：链上 Shielded Voting

这篇博文概述了一个实用的架构，以填补治理中的这个隐私缺口：一个完全基于链上的 Shielded Voting 系统，该系统围绕 Shutter 的阈值加密轨道构建。

这种方法借鉴了 Shutter 类似流程的实际应用——Snapshot 的链下 Shielded Voting 已经帮助超过 600 个 DAO 保护了他们的投票过程。在这里，我们将展示如何将相同的隐私保证直接带到以太坊（和 EVM 链）上，只需对现有的 Governor 框架进行最小的更改。

为此，我们将逐步介绍：

• 为链上 Shielded Voting 选择正确的加密体系结构
• 阈值加密设计的要求、组件和交易流程
• 架构和交易流程
• 阈值加密方法的问题与解决方案
• 如何将该架构调整到未来的加密组件

为链上 Shielded Voting 选择正确的加密体系结构

设计一个保护隐私的投票系统意味着要平衡安全性、去中心化和用户体验。下面我们概述了六种常见方法及其权衡。

• 链上解密： 今天是不可能的，因为智能合约无法保密。
• 全同态加密 (FHE)： 功能强大，但目前对于实时链上使用来说过于繁重。
• 自定义投票专用同态方案： 比 FHE 轻，但属于定制且仍然难以集成。
• 基于用户的加密： 用户稍后透露自己的投票 - 用户体验差且容易错过截止日期。
• 中心化密钥加密： 简单，但引入了单点信任和失败。
• VDF + 同态加密： 信任最小化，但硬件繁重且复杂。
• 阈值加密（我们的重点）： 一个去中心化的委员会共同管理密钥，在投票期结束后自动揭示结果，并避免了投票者的额外步骤，同时保持较小的信任假设。

因此，对于当今的生产 DAO 来说，阈值加密提供了去中心化、可用性和安全性的最佳组合。值得注意的是，仅凭零知识证明无法提供机密性；它们只能证明正确性。

使用阈值加密的链上 Shielded Voting

使用 Shutter 的阈值加密，提议者从 Shutter API 请求一个新的公共加密密钥，并将其存储在 Governor 合约中。选民使用该密钥加密他们的选择，并在投票窗口期间提交密文。一旦窗口关闭，Shutter Keypers 释放解密密钥份额；之后任何人都可以重建完整的密钥，解密选票，并将明文计数发布在链上。

要求

将链下 Shielded Voting 机制（例如 Snapshot 使用的那些）引入区块链会带来几个挑战：

• 架构： 链上 Shielded Voting 机制需要设计一种解决方案，该解决方案可在保持投票的可验证性和完整性的同时，保护投票的隐私，并防止过早泄露投票。
• 实施复杂性： 主要的限制是降低实施复杂性，并避免对现有治理框架（如 Governor Alpha）进行重大修改。
• 安全性和信任最小化： 必须确保防止过早泄露受保护的投票。这意味着一方面必须通过安全加密方案（IND-CCA 安全性）对投票进行加密，并且任何一方都不应持有解密密钥，因为这会引入主要的信任假设。

组件

修改后的 Governor 智能合约： 该合约管理整个投票过程。也就是说，它存储投票元数据（例如投票期、选民人数、选民身份、Shutter 身份、eon 公钥）、加密的投票以及相应的解密投票。它还实现了一个函数，该函数检查提交的解密投票是否是提交的加密投票的正确解密。

• 提议者： 发起投票的一方。也就是说，它在修改后的 Governor 智能合约中注册投票元数据。
• 选民： 从修改后的 Governor 智能合约中检索投票元数据，并在投票期结束前提交加密的投票。
• Shutter Keypers： 持有 eon 解密密钥的份额。当投票期结束时，Keypers 派生出相应的 epoch 解密密钥的份额并发布它们。

执行者/解密者： 从修改后的 Governor 智能合约中检索加密的投票，以及从 Keypers 那里发布的密钥份额。重建完整的解密密钥，解密投票，并将解密的投票提交给修改后的 Governor 智能合约。

架构和交易流程

从发起新的 Shielded Voting 提案到解决它的一般架构和交易流程如下：

图 1. 使用 Shutter API 的链上 Shielded Voting 过程的架构。投票提议者首先从 Shutter API 获取一些加密所需的数据，然后向修改后的 Governor 智能合约注册投票提案。然后，选民从合约中检索投票详细信息，并在投票期结束前提交他们加密的投票。投票期结束后，执行者从合约中获取所有加密的投票，并从 Shutter API 接收解密密钥。然后，执行者解密所有投票，生成零知识证明以证明解密的正确性，并将解密的投票和 zk 证明提交给合约。合约检查 zk 证明并计算所有有效投票。

• 提议者创建新的 shielded 提案（图 1 中的步骤 1+2）
  • 检索加密数据（步骤 1）
  • 使用解密时间注册新的 Shutter 身份，即投票期结束时间（步骤 2）
  • 包含投票详细信息、Shutter 身份和 Shutter 加密密钥（Epoch 密钥）的链上交易（步骤 2）
• 选民从修改后的 Governor 智能合约中检索投票详细信息/身份/加密密钥（步骤 3）
• 选民投票（步骤 4）
  • 使用 eon 加密密钥和 Shutter 身份加密投票选择
  • 将加密的投票提交给修改后的 Governor 智能合约（选择已加密，其他详细信息以明文形式显示）
• 投票期结束
• 执行者解密投票并解决提案（步骤 5+6）
  • 检索 Shutter 身份和加密的投票
  • 从 Shutter API 检索 epoch 解密密钥（步骤 5）
  • 解密所有投票
  • 对于每个投票，生成一个 zk 证明，以证明解密的正确性
  • 将所有内容在链上提交给修改后的 Governor 智能合约：所有明文投票、所有 zk 证明、解决交易（步骤 6）
• 修改后的 Governor 智能合约验证 zk 证明（步骤 7）
  • 如果某个 zk 证明未通过密文的验证，则必须由另一方重复该密文的解密
  • 如果解密的投票无效但相应的 zk 证明有效，则合约不计算该投票

阈值加密方法的问题与解决方案

子问题 1：链上解密在今天不可行

由于以太坊缺乏必要的预编译，因此必须在链下进行解密，并在链上进行有效性检查。四种备选解决方案：

1. 按解密者证明（首选）。 执行者发布正确解密的 zk 证明。
2. 按选民证明。 选民证明他们的密文格式良好；执行者揭示随机性。
3. 哈希承诺。 选民在链上承诺 salted 哈希；稍后揭示以进行验证。
4. Keyper 端解密。 Keyper 本身解密并以阈值签名结果（没有新的信任假设）。

子问题 2：Keyper 阈值信任假设

风险 A：如果太多 Keyper 处于脱机状态，则无法解密。风险 B：通过勾结进行早期解密。

缓解措施：

• 通用加密接口。 可插入的后端（时间锁、FHE、TEE 等）。
• 备份路径。 双重加密：阈值 + VDF。
• ShutterTEE。 Keyper 在 TEE 内部运行以防止勾结。
• 用户端回退。 在最坏的情况下，选民可以发布明文投票。

子问题 3：投票期间的法定人数可见性

由于在加密时“是”和“否”无法区分，因此在解密投票之前，你无法知道是否已达到法定人数。选项包括使用同态计数 + zk，或将“否”投票计入法定人数。

广义架构

两种能力定义了一个加密后端：

1. 提供初始加密数据。 公钥或等效项，以便提案者可以开始投票。
2. 准时发布解密材料。 或者 - 在时间锁的情况下 - 一旦延迟过去，无需秘密即可启用解密。

满足这些Hook的任何技术（TEE、VDF、FHE、MPC、iO）都可以插入到相同的流程中，从而保留大部分的实现。

展望与后续步骤

本文描述的阈值加密设计为当今的链上治理提供了实用、信任最小化的隐私，并且通用的Hook确保未来的加密组件可以轻松插入。从长远来看，诸如不可区分性混淆之类的突破甚至可以使合约直接解密而不会泄漏秘密 - 从而消除最终的链下步骤。

我们已经在为基于 OpenZeppelin Governor 和基于 Safe 的治理框架制定详细的实施指南 - 请继续关注！

如果你是一个治理平台，或者你的 DAO 正在使用一个，请与我们联系。我们很乐意与你合作实施链上 Shielded Voting！

• 原文链接： blog.shutter.network/clo...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～