机构隐私的三种方案：Prividium、Aztec、Canton

本文完全由人类、L2BEAT 的 ZK Researcher Sergey Shemyakov 撰写。内容基于一次内部知识分享。所有观点仅代表我个人，不一定代表 L2BEAT 的立场。如果你发现任何错误或不准确之处，请在 Twitter 上联系我。

机构隐私是 Ethereum 生态中最新的流行词之一，当然，这一概念的兴起也源于希望服务拥有大量资金的大型组织。在本文中，我将分享我对面向机构用户构建私有 blockchain 的 3 种不同架构方法的理解。

计划如下：

1. 引言：机构对隐私的需求以及 ZK 的作用
2. Prividium L2 的设计
3. Aztec L2 和 Nightfall v4 L2/L3 的设计
4. Canton Network L1 的设计
5. 结论

机构对隐私的需求

Onchain 隐私是一个老话题，不过在其发展的绝大部分时间里，它都是以 cypherpunk 的方式被理解和推进的。其预期用途是保护 cryptocurrency 用户不被识别，尤其是不被强大的民族国家和执法机构识别。Monero、Zcash、Tornado cash 都是 cypherpunk 协议的例子。

大型机构面对这种类型的隐私，不仅仅存在意识形态上的问题：它往往在法律上就无法适配它们的使用场景。这些组织必须提供合规功能，例如按需共享私密数据，以及各种安全保障。它们还可能需要定义明确的隐私域，在这些域中数据不必被隐藏。Cypherpunk 隐私和机构隐私之间的区别可以用下图概括。

左：cypherpunk 隐私。右：机构隐私

像银行、基金和其他资金管理机构这样的组织，比普通 cypherpunk 更迫切地需要隐私。虽然 John Doe 可以通过 stealth addresses、不规则且无关的交易保持低调，但任何严肃的机构都不可能披露其金融交互的全部细节。虽然我并不了解机构内部如何运作，但我认为它们可能会认为以下场景中隐私至关重要：

• 购买并持有 crypto 和 RWA
• 与其他机构和公司进行交易
• 在链上交易资产
• 与零售用户交易，例如收款或发工资

在公共账本上做这些事情可能会导致：竞争对手过度了解内部运作、因暴露用户数据而带来法律风险（见 GDPR）、遭受 MEV 等等。这个清单又长又痛苦。

对于机构而言，隐私是不容妥协的。

对于机构而言，合规是不容妥协的。

对于机构而言，公共账本行不通。

根据不同的使用场景，现有应用可能会提供一种解决方案：

• Railgun、privacy pools 或 stealth addresses，用于 Ethereum L1 上相对私密的转账
• Semaphore、MACI，用于私密的链上投票
• zkPassport，用于以私密且合规的方式证明身份

我不会在本文中讨论这些，而是会聚焦于适用于更重度场景的独立私有 blockchain。

在公共 blockchain 中，状态有效性通常通过重新执行来确定，但这种方法无法用于包含私密数据的交易。验证者节点无法知道 Alice 是否有 5 个 token 可以发送给 Bob，只有 Alice（以及合规审计员）应该知道这一点。这就是为什么私有 blockchain 的架构必须不同于公共 blockchain 的设计，你不能只是把私密交易直接叠加在 L1 之上。除非你的目标比完全隐私更简单，那么你可以从 Starkware 团队的 STRK20 中获得启发。

正如下文将看到的，私有链通常需要不同的 state model、不同的 transaction validation rules，以及用于私密数据管理的新附加组件：你不能只是把数据发到公共 mempool，然后就算完事了。这些变化通常也会体现在不同的 smart contract 语言上，最终体现在链上可实现的功能上。

下面是一个没有经过充分校对的列表，列出了各种实现链上隐私的 L1 和 L2，顺序不分先后。并非所有项目都已上线（或者已经上线了？），但正如你所见，这个领域相当拥挤。

我不接受这里遗漏项目的任何投诉

下面我将深入介绍 Prividium（不过还有其他几个类似设计，包括 Cloak）、Nightfall v4 和 Aztec 这一类方案（我还会把 Miden 和 Payy 算进去），以及 Canton（与 Paladin 的 Pente domains 有相似之处）。目标不是聚焦某个具体产品，而是介绍链上隐私的不同架构方法。

重要免责声明：基于 FHE 和 MPC 的隐私解决方案（Fhenix、Zama、COTI v2）没有出现在我的文章中。它们代表了另一种不同的隐私方法，非常值得深入探讨，不过我认为这项技术还稍显不成熟，而且在性能方面也更受限制。

关于 ZK 角色的一点说明

围绕隐私保护 blockchain 的工作推动了许多 ZK 和 SNARK 研究，包括 Halo2 库、Noir 语言以及许多理论成果。然而，“ZK” 这个流行词已经失去了它最初的含义，经常被用来指代 SNARK，即一种可以高效向验证者证明某个特定计算正确性的 proving system，但不一定能够隐藏该计算的私密细节。L2BEAT 也难辞其咎，出现在 ZK Catalog 中的大多数 proving system，实际上都没有进行必要修改，无法阻止验证者获知 prover 的 secret witness 的部分信息。

L2BEAT 的 “ZK” Catalog

加入真正的 ZK 属性是有成本的，它需要额外的开发工作和 prover 成本。根据 Giacomo Fenzi 的说法，给 zkVM 增加 ZK 属性大约会让其性能降低 2 倍，而像 validity rollup 之类的大多数应用并不严格需要它。SNARK 要变成 ZK SNARK 需要做的一些修改包括：

• 为输入添加 blinding randomness
• 为 circuits 添加 dummy variables 和 constraints
• 将 polynomial commitment schemes 修改为可 blinding

不过，如果实现得当，ZK 可以让用户把数据保存在本地，并基于这些数据向 blockchain 证明交易的正确性。以这种方式，ZK 是用于链上隐私的一种自然技术。

ZK 不是唯一可用的工具。其他值得注意的方法包括：

• 基于 MPC 的解决方案，其中用户的私有输入被分割给一个节点网络，后者在没有任何单个节点能够访问私密数据的情况下共同进行计算。
• 基于 FHE 的解决方案，其中 blockchain 节点在由用户自己加密的 ciphertext 上进行计算。
• 其他密码学设计，例如 Monero 最初基于 Ring signatures 和 ringCT 的设计。
• 纯粹的数据访问管理，精细地规定谁能看到什么（如 Canton Network）。

Prividium

架构概览

Validium 是一种 L2，它不是把交易数据发布到 Ethereum L1，而是发布到别的地方。它可以是 Celestia blockchain，也可以是德意志银行某栋高层办公楼地下室里的某个地方。Prividium 是私有 validium，意味着数据不会被发布到任何地方，而是保持私密。这是在当前技术状态下构建私有 L2 最简单、最直接的方法。

Prividium 是一种 L2，这意味着它在规范上连接到 Ethereum L1（或 Gateway 中间结算层），与同一技术栈上的其他 L2（例如 ZKsync Era）完全等价，并支持所有标准 EVM 工具。与推出一个 L2 相比，运营者面临的变化最小，而如今推出一个 L2 已经相当简单。Prividium 会定期在 Ethereum L1 上发布 state root，提供一个防篡改的数据锚点，同时附带一个证明 L2 正确状态转换的 validity STARK proof。该证明保证了在给定 EVM logic 和 smart contract code 的情况下，state 会按照预定规则变化。

隐私来自于这样一个事实：只有 Prividium operator 持有全部交易和 state。这是一种银行级中心化，但却有着 L2 即插即用的体验。根据 Prividium paper：

Users interact with Prividiums through an Remote Procedure Call (RPC) interface, which filters transactions so that only those with explicit permissions or assigned roles can conduct on-chain activities and get access only to data they’re allowed to view

这意味着用户只能通过由 Prividium operator 运行、带有 OAuth2 门控的 RPC 来提交交易。此外，只有在被授权的情况下，用户才可以查询 Prividium L2 data。完全控制权仍掌握在 Prividium operator 手中，唯一显著的例外是无许可的 L1 -> L2 forced transactions，它们作为 ZK stack 的一部分提供。下图对此进行了说明。

K 是由 Prividium operator 管理的 authentication key。Settlement layer 可以是 Ethereum L1 或 Gateway，从而提供快速且无需信任的 Prividium-Prividium interop

优点和缺点

从机构角度看，Prividium 可能会给人一种很熟悉的感觉。我能想象，整个业务基本上就变成了为用户、其他机构和监管机构开发一个与私有账本交互的 API；从 cypherpunk 的视角看，这和传统银行并没有太大不同。如果这个私有账本由几个穿西装的人运营，它本质上就成了一个 consortium blockchain，而这也是一种广为人知的形态。

Prividium 有几个不错的特点。

1. 合规已被解决。 通过管理读写 blockchain state 的 access keys，operator 可以有选择地向审计方披露 state 的任何部分，在任何时刻因任何原因阻止任何用户访问 Prividium，并按法律框架可能要求的任何合规需求进行编程。
2. 已接入 Ethereum L1。 作为一种 L2，Prividium 继承了与 Ethereum L1 之间最经受实战考验、原生无需信任且易于使用的连接；它只是披着数据隐藏外衣的 L2。所有 liquidity 都可以进出 Prividium，任何 Solidity smart contract 都可以轻松部署到 Prividium 上。

不过，我认为 Prividium 设计有一个关键缺陷，也欢迎 Prividium 开发者对这一点作出澄清。

1. 联盟链式的隐私模型。 Prividium 之外的所有数据都被隐藏，而内部的所有数据都是公开的。如果 Prividium 希望通过 Gateway settlement 与 L1 或其他 Prividium 交互，它必须通过公共 blockchain 进行交易，从而例如暴露所有资金流入和流出。从隐私角度看，Prividium 作为一个接入 Ethereum 的 consortium chain 运行：所有 operator 都能访问所有数据，而与外部世界的任何交互都是公开的。尽管有一种 私有 Prividium-Prividium token transfers 的设计，这可能会减少数据泄露。

我认为 Prividium 设计可以帮助 neobank、链上 payroll 方案，或任何希望将其内部运作搬到链上的机构。Prividium 之间的私有 token 转移也可以用于跨机构结算。

Aztec、Nightfall v4：本地 ZK-proving

下一类隐私链在很大程度上偏向 cypherpunk。Nightfall v4、Aztec 和 Miden 的设计将具有隐藏属性的 ZK proofs 作为核心。因此它们在技术上既可以支持机构用例，也可以支持隐私导向的用户 dApps。值得注意的是，Aztec 并未面向机构用例进行营销，而 Miden 确实强调合规是 programmable privacy 的一个特性，且 Nightfall 是由 EY 自己开发的。

我将先解释 Nightfall v4 的架构，作为 Aztec 的前身。前者只支持私有 token transfers，而后者支持更复杂的用例，但隐私架构是相似的。

Nightfall v4

Nightfall v4 是一个开源的 validity L2，用于私有 token transfers。它目前以 L3 的形式部署在多个链上：Plume、Celo 和 Starknet。它有一个用于 ERC20、ERC721、ERC1155 和 ERC3525 token 的桥，这个桥由 X.509 certificates 门控，只允许白名单用户进入或离开 rollup。一旦进入 L2，用户就可以私密地交换 token，并再退出到 settlement layer。rollup 本身不支持 smart contracts 或其他自定义逻辑。

Remember me for faster sign in

简而言之，L2 上的隐私是通过用户在本地生成转账的 ZK proofs 实现的，诸如金额、发送方和接收方之类的转账细节不会离开用户设备。作为参考，在一台相对强大的机器上，生成单个转账 proof 需要 24 秒和 900 MiB 内存：速度较慢，但可行。用户交易由 proposer（proposers）收集，并在验证每笔交易的 ZK proof 有效后打包进区块。Proposers 为整个区块的正确性生成 SNARKs，据称其硬件要求为 144 核和 750 GiB RAM，proving 时间约为 15 分钟。

Nightfall 的 state 更像 Bitcoin，而不是 Ethereum。L2 上的 token balances 由 UTXOs 表示，即代表某个特定用户对某一特定数量 token 所有权的原子状态片段。我将把它们称为 UTXOs，以呼应 Bitcoin 的设计；它们在 Nightfall codebase 中有不同的名字。UTXO objects 由用户本地存储，只有 UTXO 的 commitments 被发布到链上的 append-only commitment tree 中。该树的 root 会由 proposers 定期发布到 settlement layer。

Nightfall commitment tree 的一个稍微简化的图示。UTXO objects 的哈希被放入一个公共的 append-only tree

每个 UTXO 都可以通过向不同所有者发送部分或全部金额来花费。为了保护隐私，这不是通过从 UTXO commitment tree 中移除元素来完成的，而是通过 nullifiers。Nullifiers 表示已经花费过、因此不能再使用的无效 UTXO commitments。一个 nullifier 无法与某个特定 UTXO 关联。Nullifiers 存储在另一个 append-only 的 nullifier sparse Merkle tree 中，这使得可以证明 nullifier 不存在。该树的 root 会发布到 L1。

Nightfall nullifier tree 的一个稍微简化的图示。Nullifiers 不会暴露其 UTXOs，并存储在一个公共的 append-only sparse Merkle tree 中

让我们详细看看 Nightfall v4 上一次私有转账是如何工作的。User 1 有 10 个 token，由 UTXO 1 表示，他们想向 user 2 发送 5 个 token。两个用户都通过 ZK spending keys 进行标识，这些 key 可以解锁用户拥有的 UTXOs。初始状态如下：

User 1 在自己的机器上本地生成一笔交易。这需要：

• 生成 UTXO 2，包含 5 个 token，可由 key 1 花费；以及 UTXO 3，包含 5 个 token，可由 key 2 花费
• 生成 nullifier 1，使 UTXO 1 失效，从而花费它
• 生成一个 ZK proof，证明 UTXOs 和 nullifiers 生成正确：user 1 知道 ZK key 1 的私有部分，UTXO 1 尚未被 nullified，UTXO 2 和 3 的金额正确地加起来等于 10 个 token，以及其他一些技术细节。

交易和 ZK proof 被发送给 proposer，若 proof 正确，proposer 会更新 state。此时它看起来是这样的：

当然，在这个简化示例中，nullifier 1 对应花费 UTXO 1 是显而易见的，但一般来说，添加新的 nullifier 并不会透露正在花费的是哪一枚 coin。

Nightfall v4 的优点和缺点

Nightfall 是作为一款服务于大型组织需求的工具而开发的，因此它可以开箱即用地提供几个不错的特性：

1. 只有白名单用户可以进入或退出 rollup。 虽然 L2 上的 token 所有权不限于白名单实体，但与 L1 的连接会检查是否存在有效的 X.509 certificate。
2. 与 Ethereum 生态的原生连接。 作为一种 L2（或 L3）设计，Nightfall 原生支持 ERC20/721/1155/3525 assets 的无需信任桥接。
3. Consortium 风格的 sequencing。 不同于许多现代 L2，Nightfall 允许由一组 proposers 对 L2 进行去中心化运营，这些 proposers 以轮转方式在 L1 上发布 root。这降低了 Nightfall 用户群体的运营风险，同时不牺牲隐私属性。

Nightfall v4 的主要弱点是：

1. L2 上只有 token transfers。 组织无法在私有层之上实现自定义逻辑，只允许简单的 token transfers。

Aztec（新的那个）

Aztec 团队无疑是 ZK 和链上隐私世界的 OG，背后有 Plonk paper、Aztec Ignition trusted setup ceremony 以及多个隐私链迭代。事实上，有人可能会说 Nightfall v4 在很大程度上受到了 zk.money 设计和架构的启发。因此，Aztec L2 的下一次迭代可以被理解为 Nightfall v4 加上更多附加到 UTXOs（在新术语中称为 notes）的私有逻辑，以及 L2 上更多的公开逻辑。哦，而且它们还有 Honk。

它叫 Honk。希望 Aztec 团队不会因为我把这个酷家伙放在这里而起诉我

Aztec L2 将由 Aztec VM 管理的 public state，与由用户本地管理并通过 UTXO 和 nullifier trees 链上提交的 private state 结合在一起，其公共部分的处理方式与 Ethereum 非常相似。Aztec L2 上的 smart contracts 既有 private functions 也有 public functions，它们之间的交互非常有限，因为它们是在 根本不同的时间执行的：private functions 由用户本地执行，而 public functions 则在 sequencer 构建区块时执行。Private functions 可以排队一个 public call，以便稍后在构建区块时执行，但基本上也就仅此而已。私有逻辑和公开逻辑都使用 Noir 语言编写，从而可以进行 ZK proving。客户端侧的 proofs 由 Chonk 生成，public functions 的 proofs 由 UltraHonk 生成。

Aztec 的 state model。绿色与红色之间的交互受到限制

Aztec notes 是 Nightfall 示例中 UTXOs 的泛化版本。开发者可以编程定义 notes 中存储什么信息、它们如何被创建以及如何被 nullified。让我们通过一个 approved send 的例子加入一些可编程性：user 1 想向 user 3 发送 10 个 token，但必须先由 user 2 批准该转账。

首先，user 1 在本地为 user 2 生成一个 approve request，以将 10 个 token 转给 user 3。这可以通过创建一个包含必要信息的新 note 来实现，为了防止双花，之前的 note 必须被 nullified。注意，这段逻辑必须事先编写并部署到 L2 上的 smart contract 中。

将这笔私有交易提交到链上，需要一个有效的 ZK proof，证明：

• User 1 的 app key 可以 nullify note 1
• Note 1 尚未被 nullified
• Note 2 和 nullifier 1 根据 smart contract logic 被正确生成

一旦提交，更新后的 state 就变成：

接下来就轮到 user 2 批准这笔转账。在 Aztec 上，私有 notes 可以以加密方式在链上共享，也可以离链共享，以尽量减少可检测的痕迹。User 2 按照 smart contract logic 处理 note 2（在我们的例子里，就是批准转账），再次将其 nullify，并生成一份正确执行的 ZK proof。最终 state 将如下所示：

User 3 可能并不知道他的 10 个 token 经过了怎样的审批流程，也不知道 user 1 和 user 2 的身份。这就是基于 UTXO 和 client-proving 的隐私力量。

Aztec 的优点和缺点

优点：

1. 可编程隐私。 Aztec 实现的隐私模型看起来是目前所有可用方案中最通用的（我们看看 Miden 上线后会如何变化！）。它的主要优势在于可编程性，允许开发者实现自定义私有流程，但 private state 的 UTXO 架构限制了可实现的内容。例如，Aztec 不支持标准 DEX 设计所需的共享私有 state，这个问题未来可能会通过像 TACEO 这样的基于 MPC 的方法来解决。
2. 去中心化且稳健的 L2。 Aztec L2 consensus 已经作为一个去中心化 L2 上线，具有可信中立的运营方式，execution layer 也将很快全面上线。

缺点：

1. 没有内置合规。 Aztec 并不是为机构而营销的，因此所有合规功能都必须从零开始开发。
2. 新的工具栈。 除了新的 smart contract language Noir 之外，Aztec 还有一种不寻常的 private state model。这使得 dApp 的设计和开发充满挑战，而且能够胜任这些工作的人并不多。

Canton

Canton network 与前面提到的项目在几个方面不同。首先，它与 Ethereum 生态无关，是一个独立的 L1 network。其次，它确实已经在运行到某种程度了，因为它有一个 explorer。它也远非标准的、带有去中心化 state replication 的 blockchain design，更多细节请参阅白皮书。

Canton network 由 “L2s” 组成，这些 L2s 被称为 cantons 或 domains，以及被称为 Global Synchronizer 的 “L1”；用户通过连接到 Cantons 的节点进行交易。Canton sequencers 和 Global Synchronizer 的职责仅限于 transaction ordering、基本 validation 和管理 data flow；它们无法访问实际的 business logic 或 transaction data，以保持隐私。Private logic 和 data 由所有相关方本地存储，只有这些相关方才能验证 state transitions。

Canton network 引入了一种名为 Daml 的新 smart contract 语言。它是一种函数式、类似 Haskell 的语言，明确规定谁有权查看数据并批准 state transitions。每个 smart contract 都表示为一个可以创建和消耗的 UTXO。关于 Daml 的更多信息请看这里。

交易的 validation 通过要求所有相关方在本地执行交易并确认成功执行来实现，而协调则由 Global Synchronizer 完成。让我们考虑一个跨 canton 的 token 原子交换示例，涉及两个实体（黄色和绿色），另一个实体（蓝色）在某个 canton 上充当 token guardian。

Sequencer 可以是中心化的，也可以是 consortium-operated。蓝色人物必须在 Canton 1 上批准 tx

交易从一个节点向 sequencer 发送请求开始。Private data 不是交易的一部分，它由 Daml smart contract 定义的所有相关方本地保存。交易本身被加密，只有所有相关方能够解密。Sequencer 在自己的 Canton 上本地对交易排序，然后将其传递给 Global Synchronizer。GS 对加密交易进行全局排序，并将其传递给所有相关方，可能跨越多个 Cantons。

现在所有参与方都可以通过解密并重新执行交易来验证它：他们既知道必要的 Daml logic，也知道 private data。一旦他们向 Global Synchronizer 发送签名的批准消息，交易就最终确定。

Canton state 并不真正以类似 Ethereum state 的方式存在。State 的各个部分存储在相关节点本地，只要所有节点都同意它们有效，它们就被视为有效。从某种意义上说，这是一种 “Trust me bro” 模型，但所有 bros 都必须达成一致。对于一个面向机构营销的产品来说，这似乎已经足够好了。

Canton 的优点和缺点

我承认我并没有完全理解 Canton 的设计或使用场景，但以下是我认为它的强项：

1. 没有 ZK。 正如我在与 ZKsync 的 Alex 的一场 Twitter 争论中提到的那样，Canton CEO 认为 ZK 技术 还过于不成熟，不足以被大型机构信任，而他也许是对的。Canton 在不使用任何 ZK 的情况下实现了链上隐私，这使它脱颖而出。
2. 面向机构的营销。 Canton 的架构就是围绕机构使用场景设计的，所以它大概非常贴合这些组织的需求。

有几个弱点：

1. 新的 toolchain。 与 Aztec 类似，Canton 需要独特的技能才能开发 dApps。独特架构 + 新语言通常意味着糟糕的开发体验。
2. 并非原生连接到 Ethereum liquidity。 尽管 Ethereum tokens 可以通过最近推出的 Zenith bridge桥接到 Canton，但信任假设和用户体验很可能比 L2 bridges 更差。

结论

看到机构隐私从一个流行词变成一个已实现的功能，还是很令人欣喜的。组织已经有几个技术上各不相同的解决方案可供选择，所以希望每个人都能找到适合自己的东西。

我认为合规是首先需要定义、然后解决的最大问题，因为在阅读了上面所有项目之后，我仍然不太明白它们分别面向哪些使用场景。提供隐私与保持合法之间的相互作用非常复杂，它高度依赖当地法律和监管者的态度，以及预期的使用场景。监管要求的一个小变化，可能就意味着私有 blockchain 的整体架构重构。

在深入机构隐私解决方案之前，我原本以为它和用户导向的隐私（例如 PSE 推动的那种）并没有太大不同。但在上面这些项目中，只有 Aztec / Nightfall v4 现实中才有可能支持 cypherpunk 应用。Prividiums 仍然需要一个 Big Brother 来运营，而 Canton 由于通过 Global Synchronizer 这个瓶颈把交易传递给所有相关方时带来的 P2P 负载，无法扩展（而且严格说来也未必算是真正的 blockchain）。FHE 和 MPC 解决方案在这里也值得再提一次，作为 cypherpunk 原语。我有点天真地以为，机构隐私领域的发展也会给我们带来个人隐私的技术基础，但这其实是两条在架构上不同的路线。

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