区块链机密计算七大要点

本文链接：https://blog.csdn.net/mutourend/article/details/144795616

1. 引言

本文将介绍区块链中机密计算的相关内容。
隐私问题一直是一个需要解决的关键领域，但目前无法宣称已经取得了明显的胜利（详情见之前关于解决一些长期存在的问题的文章——如2023年11月博客Reviving Transaction Privacy: Approaches to combat compliance and usage challenges）。技术问题是真实存在的。然而，业界经常将不同的解决方案混为一谈，这让问题变得更加困难。

本文试图分解广泛用于机密计算的 ZKP、MPC 和 FHE 原语的差异化属性。还将介绍上述加密原语在系统和 dapp 级别上的实现方式。通过消除误解，可以开辟一条更直接的解决方案之路。

来源：Greenfield

2. 要点#1 - 要点#3：探索密码原语之间的差异和联系

2.1 要点#1：密码原语提供不同的隐私效用

在这种情况下，实用性是指广大用户群可以同时享受隐私的程度。可以同时共享隐私的用户数量越多，系统的实用性就越高。这个概念至关重要，因为它强调了不同底层加密原语（如零知识证明（ZKP）、完全同态加密（FHE）和多方计算（MPC））之间的核心区别之一：

ZKP：证明对秘密的了解而不以可验证的方式泄露秘密
FHE：允许在加密数据上进行任意计算；结果与在纯文本上运行相同
MPC：允许多方联合计算他们的输入的函数，同时对这些输入保持私密。

ZKP 和 MPC 专注于在 MPC 环境中保护单个用户或一组特定用户的隐私。这种方法限制了可以共享私人信息的参与者数量。相比之下，FHE 可以在加密的全局数据之上进行操作，而且可以使用这些数据（加密形式）开放无权限创新的访问，从而提供更广泛的灵活性和应用。

2.2 要点#2：密码原语具有不同的信任假设

信任假设决定了事情可能出错的方式，以便用户可以注意他们能容忍系统带来多大的风险。要破解 ZK（具体来说是 ZKSnarks）系统，必须伪造一个假的零知识证明。

一种方法是规定设置阶段，该阶段发生在程序部署时。使设置阶段尽可能减少信任的方法是让尽可能多的参与者参与进来。
当今大多数系统都使用通用设置，这意味着该过程不需要在每个程序部署时发生，而只在创世时发生。

MPC 的信任假设类似于阈值 FHE 方案。

两者都将“解密权”分配给多方，从而确保没有任何一个人有权破坏系统。
- 在阈值密码学中，有一个阈值委员会控制密钥共享，在通过阈值时通过组合密钥共享进行集体解密。
- 在 MPC 中，最常用的信任方案是诚实多数或 2 ⁄ 3 诚实多数，这意味着超过一半或超过 2/3 的参与者诚实行事。

2.3 要点#3：密码原语是可组合/可编程的

在许多情况下，没有一刀切的解决方案，上述技术通常捆绑在一起以方便使用。如，FHE 系统正在探索的一个开放研究领域是找到一种实用的方法来验证计算的完整性（即检查计算是否正确完成）。 有几种可能的探索方法：

在 TEE（可信执行环境）中运行 FHE
在 ZK 中运行 FHE
将 FHE 计算包装在乐观证明中或通过经济共识包装，或者运行冗余计算。

此外，如上所述，MPC 在解密 FHE 计算的输出时运行。MPC 的问题在于它容易受到串谋的影响，参见前身的案例——multichain（所有密钥份额都由一个人持有）。当这种情况发生时，它容易受到单点故障的影响，用户的资金将被保管。dwallet labs的 2pc-mpc 等新兴解决方案可能提供可行的解决方案，但用户活跃度是使其实用的假设。 或者，可以尝试探索在TEE中运行 MPC ，并添加一些经济特性。此外，其他系统经常使用一种称为范围证明的 ZK 证明来防止超支等情况，如Arcium 的情况。

这样的例子不胜枚举，如果将生成过程委托给强大的服务器，ZKP 的运行效率会更高，而且可以通过协作 ZKP在几台机器上运行计算来缓解潜在的隐私问题，这样任何一台机器都无法访问整个秘密。

另一个值得探索的有趣领域是可编程性，即见证加密（witness encryption），它允许使用程序而不是密钥对statements进行加密/解密。它解锁了令人兴奋的应用程序，如Fairblocks 的 Cowswap 加密订单，其中可以将意图指定为解密标准。

3. 要点#4 - 要点#5：实现密码原语

3.1 要点#4：在实现时，面向隐私的环境不会共享相同的隐私设置。

一个常见的误解是，在使用隐私保护的区块链时，隐私设置（即“工作流”的哪一部分实际上是私有的）应该相同。

在解释为什么情况并非如此之前，先讨论一下私有分布式系统中嵌入的几个概念：

private input/output
private/public function
private/public address

可以进一步将它们分为两类：

1）机密性与输入/函数有关，描述交易的价值或流程是否被隐藏。
2）匿名性与私人/公共地址有关，表示发起交易的身份是否被隐藏。

私有输入：

表示用户指示智能合约执行的隐藏值，如，将多少 USDC 兑换成另一种代币。

私有输出：

表示更新后的状态，它也是隐藏的，但可验证。

私有输入/输出：

是每个隐私保护区块链都提供的基本机密性功能。

最上面是输入所调用的函数（即智能合约）。当今区块链中使用的几乎所有函数都是公共函数，即执行轨迹透明地记录在链上。私有函数的概念在ZEXE论文中首次提到，它允许在用户端本地完成执行轨迹（而不是由验证者或其他非用户方透明地执行的公共函数），从而保护隐私。
有趣的是，公共函数和私有函数之间的交互使私有本地状态和公共全局状态能够同时存在（如，使用私有余额与 uniswap 上的公共流动性池交互）。这也带来了巨大的工程挑战。

可看到像Aleo这样的团队已经做出了权衡，通过暂时禁用私有函数来优先考虑性能。到目前为止， Aztec是唯一一个启用私有函数的协议。

相比之下，基于 FHE 的网络只有公共函数，原因是由于计算extensiveness广泛性，FHE 计算被委托给验证者。私有函数可能也不太适合 FHE 网络。

最后，函数是否应该公开或私有取决于用户想要的隐私程度和具体用例。如，当使用私有 uniswap 时，散户可能更关心隐藏其头寸规模，而不是他们正在与哪个特定池进行交互。但机构/专业交易员会关心为他们的策略保留完全的隐私。
Equilibrium的博客Overview of Privacy Blockchains & Deep Dive Of Aleo中分享了许多关于不同设置的技术权衡的深刻见解。

3.2 要点#5：目前还没有完美的私人交易场所

之前讨论了构建分布式隐私保护系统的复杂性，但实现私有 dapp 也并不容易。DeFi 是迄今为止最具活力的应用生态系统，但大多数活动都是以完全透明的方式进行的（如2023年11月博客Reviving Transaction Privacy: Approaches to combat compliance and usage challenges 中所述），链上交易场所主要有两种设计：

AMM
和订单簿。

它们的私有版本是私有 AMM 和链上暗池，交易者可以在其中保留交易属性的隐私（即交易者身份、资产对、订单规模等）。

私有 AMM：类似 uniswap 的“透明 AMM”之所以被广泛使用，主要是因为它真正利用了区块链的优势——拥有一个共享的全局账本，任何人都可以同时跟踪流动性状态和交换资产。对于私有 AMM，维护（即跟踪和更改）私有全局状态非常困难。
- 几年前，Barry就已经解释过为什么在以太坊类型的账户模型中“不可能”使用 ZK——ZK 用于证明特定于用户（即单个人）的状态，并且无法生成 ZKP 来证明多个用户的状态（如果是这样，隐私就会受到损害）。
- 此外，front-running抢先交易问题（基本上是一种恶意保持发送者状态变化的方式）也会使用户的交易过时。Tarun也谈到了这个问题（详情见2022年论文Differential Privacy in Constant Function Market Makers），并建议我们可以尝试添加差异隐私或使用批量订单来减轻信息泄露。
- 这里应该提到 ZEXE ，因为它率先采用了公共和私有状态，其中公共状态维护有关池的公共信息，而私有状态以 UTXO 的形式允许用户匿名与池交互，从而绕过了纯基于账户模型的区块链所存在的问题。
- DeFi adapter（见RAILGUN SDKs）也是类似的东西。
- Penumbra采用的批量订单解决方案Batch Swaps避开了并发问题并在用户之间创建了共享的私有状态，但也有自己的权衡，如交易者的体验不理想。
- 基于 FHE 的 AMM 更为优雅，因为它原生允许共享私有状态，因此它可以同时管理并发和隐私，而它们中的大多数都存在性能问题。
链上暗池：当前还看到了构建链上暗池的探索——renegade、enclave、singularity。暗池的核心机制是撮合，它不需要像AMM那样同步更新全局状态。
- MPC和FHE是解决这个难题最合适的技术。
- tFHE是FHE方案的最新一代，利用其在数值比较方面的优势，非常适合暗池这样的金融用例。 但目前性能开销是一个巨大的挑战。
- MPC还允许对一组其他参与者不知道的分布式值公平地运行函数。除了合谋之外，另一个缺点是MPC网络的参与者必须在线直到找到匹配项。这显然降低了交易者的体验，限价单等订单类型无法自动执行。
- 有些人使用中继器（即交易者发送订单给中继器）来帮助促进撮合过程，但这会损害交易者的隐私，尽管资金是安全的。
- 总体而言，链上暗池的采用也面临一些挑战，如引导问题（即如果只有一组已知的参与者，匿名性可能会受到损害）、性能（即协议是否满足基本的 HFT 延迟要求）、信任假设等……此外，许多设计细节也有待确定，如执行价格、结算（定期拍卖与连续拍卖），其中大部分已在Sunscreen团队2024年2月博客 Building a truly dark dark pool中提及。还建议阅读 Delphi 2023年10月博客 Diving Into Dark Pools，了解一些暗池细节。
- 摩根大通的暗池中还有一个非常酷的实现，目前正在运行。它使用特定于应用程序的 MPC，并且只匹配数量。详情见J.P. Morgan团队2023年论文《Prime Match: A Privacy-Preserving Inventory Matching System》

4. 要点#6 - 要点#7：（误）使用术语和措辞

4.1 要点#6：行话随处可见，在深入了解之前，不要太在意它们

许多协议同时使用多个密码原语，因此宣传这一事实是合乎逻辑的。如，基于 ZK 的系统通常使用同态来聚合值，FHE 还使用 ZKP 来证明用户对明文的了解，以验证用户的完整性。因此，“我们使用 ZK 和同态加密 (HE)”或“我们使用 FHE 和 ZK”之类的说法是准确的，但也可能令人困惑，因为不清楚什么是基础技术，什么技术是支持功能。

这些技术的具体实现细节很少提前提及，通常需要深入审查文档。
重要的是，使用更多技术并不一定意味着更大的系统复杂性或本身更大的价值（取决于具体用例，有时一种技术可以实现目的）。
此外，即使使用相同的技术，复杂性也会有很大差异。如，开发 zkEVM 比创建 ZK dApp 更具挑战性。
此外，协议如Mind Network也开始将它们宣传为私人重新质押层，因为围绕质押的一些炒作显然被采纳了。它具有误导性，因为人们很自然地会认为它是以私人的方式进行重新质押，但事实显然并非如此。

隐私也是 MEV 中一个被广泛讨论的话题。隐私有两种形式：

私人订单流（交易不公开，如在公共内存池中）
和用户隐私（交易详细信息不会暴露给搜索者）。

应该明确一点，隐私是在执行前的背景下得到保护的，执行后的一切都是公开的（在公共区块链中）。

4.2 要点#7：隐私是情境化的，首先要定义谁是观察者

在 web3 中，总是提到隐私，却不提及任何背景，这有时会使“对谁保密”一词令人困惑。应该明确说明隐私是针对哪些方保留的。如：

在某些暗池设计中，隐私得到尊重，外部人员无法查看协议中发生的事情，而中继器仍然可以访问某些信息。
在 Tornado Cash 的案例中，在提款时，中继器可能会将某人的 IP 地址与他们的钱包关联起来（这就是NYM这样的私人 VPN 提供商至关重要的原因）。中继器不能保管客户的资金，但如果他们变得恶意，隐私就会受到损害。

5. 结论

隐私，尤其是机密计算仍然是一个复杂的挑战。鉴于不同的、部分重叠的密码学方法和技术，用户甚至开发人员很容易感到困惑并错过一些细节。
希望本文有助于更全面的对话，并减少摩擦和错位。这非常关键，因为作为一个社区继续前进，拥有共同的愿景和知识，以解决区块链中最复杂和最关键的问题之一。绝不声称自己是完整的。但如果未来的辩论者在谈论机密计算时更加关注他们到底在谈论什么，那么这篇文章就达到了它的目的。