原文：https://www.leku.blog/io/

作者：Leku

译者：Kurt Pan

这次 Devcon 7 的主要洞见就是不可区分混淆 (iO) 比我预期的要更接近。去年，在 Devconnect 上，iO 被视为处于密码技术依赖树根部的“远远未完成”的技术。 iO 可用于派生树中的任意其他原语。正因如此，它通常被视为密码学的圣杯或终局。

• https://youtu.be/lEPqwF9gPiM?si=9PLDXFzUBFhug_gz&t=428 

一年后，人们对 iO 的态度发生了变化：

• Sora 正在研究一个基于标准假设的 iO 实现：https://github.com/SoraSuegami/iOMaker
• Gauss Labs 正在致力于一个基于非标准假设的 iO 实现：https://github.com/gausslabs/obfustopia ，并已开放攻破其安全性的赏金：https://obfustopia.io/
• Barry Whitehat、 Jamajaya Mall 和 Vitalik Buterin 的进一步演示说明了可以使用 iO 构造的实际应用。
• https://www.youtube.com/live/-HAh09a5Qec?si=ki89n6nNCwgqVpd4&t=3398
• https://www.youtube.com/live/G_ey_WenFH8?si=aMMa4QtpUJ_Byhrr&t=3221
• https://app.devcon.org/schedule?text=Scalable%2520multi-party%2520FHE%2520with%2520Phantom-zone
  https://www.youtube.com/live/G_ey_WenFH8?si=-hOaRK6KbggFAJTC&t=261 
  
  

  

我在想：是否有重大科学突破让人们对 iO 重新产生了信心，或者是人们对实现这一突破的信心增强了？不管怎样，都引起了我的注意。

什么是 iO - 非形式化定义

iO 可以加密（或混淆）程序，使得混淆后的程序执行与原始程序完全相同的功能，且不会泄露有关其内部结构的任何信息。更通俗地说，你可以假设存在一个 iO 编译器，它将一个程序（表示为算术电路）作为输入并返回其混淆版本。更重要的是，混淆后的程序可以包含密钥并执行各种密码学操作（例如签名或解密）的逻辑。这些程序可以被复制并分发，且无需担心泄露被混淆的数据。

什么是 iO - 形式化定义

如果有两个程序 和 计算相同的函数（功能上等效），它们的混淆版本 和 应该是计算不可区分的。Vitalik 给了一个理解这个安全定义的直观例子:

• https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380

• : 一个包含密钥 并对 计算 的程序

• ：一个包含所有使用的个预计算的签名查找表的程序虽然 和 使用完全不同的方法，根据安全定义，它们的混淆版本应该是不可区分的。这个定义的美妙之处在于，它以一种强有力的、形式化的方式说明了"隐藏内部工作原理"的直观概念：如果你甚至无法分辨使用了两个已知实现中的哪一个, 那么你当然无法了解关于实现是如何工作的任何东西。

使用 iO 的投票应用

为了实际了解你可以使用 iO 做什么，我们分析一下如何用它来构造一个投票应用，可以使个人选票保密且仅显示最终计票结果。本节扩展了 Vitalik 在他最近的博客文章中进行的分析。计票逻辑如下：

• https://vitalik.eth.limo/general/2024/10/29/futures6.html

def vote(choice): # 选择为是 (1) 或否 (2)
    yes_votes += choice
    no_votes += (choice + 1) % 2

直观上，这可以用同态加密来设计：投票以加密形式提交，且计票yes_votes和no_votes是同态计算的，即无需首先解密投票。选举结束后，计票结果将被解密，宣布获胜者。最大的问题是解密密钥的所有权。将解密密钥的控制权外包给单个个体是最不安全的方法，因为他 / 她可以在流程结束之前悄悄解密任意部分计票，了解有关个人偏好和选举趋势的宝贵信息。谱系的另一侧的方法是，解密密钥可以被分发给个投票者，在选举结束后，每个投票者都需要做出贡献才能解密输出：这种方法保证了完全的安全性，但它也非常脆弱，因为只要单个投票者遗弃或丢失他的解密密钥份额，输出就会无法恢复。

实际中，类似的应用依赖于一个持有解密密钥份额的委员会，只需要特定阈值即可执行任意解密操作，权衡了安全性和活跃性（liveliness) 假设。尽管有人建议增加对不当行为的问责制，这种设置仍然存在委员会成员之间相互串通、暗中解密部分状态的风险。

• https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf
• https://penumbra.zone/
• https://eprint.iacr.org/2023/1724

（来源：https://speakerdeck.com/sorasuegami/ideal-obfuscation-io，其中 x 轴表示程序基于活跃性假设成功的概率）

iO 使我们能够打破这种权衡状态，获得最大的安全性，同时无需任何使协议成功结束的活跃性假设。因此，可以按如下方式构造一个所需投票应用的（非常低效的）版本：

1. 运行一个向所有人开放的公开可信设置，其中各方将贡献一些随机性来生成 FHE 密钥对，加密（公开）密钥 和底层的解密（秘密）密钥 。作为可信设置的一部分，随机性也将有助于生成混淆程序 。程序逻辑如下:

if verify(r, ct) == true:
    return decrypt(ct, s_k)
else:
    return 0

实际中，混淆程序的输入是要解密的密文 和一个区块链共识的证明 ，证明存在授权解密密文的智能合约应用逻辑。 被嵌入到这个混淆程序中, 这样只有当证明验证正确时, 它才会执行所提供的解密 。 和 是设置阶段的公开输出，而解密密钥 从未被任何人见过。

• https://docs.telepathy.xyz/telepathy-protocol/proof-of-consensus

2. 如之前所定义，投票应用的逻辑被编码到智能合约中。投票过程在区块 999 时结束。人们必须对他们的投票在 下进行加密，并将他们的密文连同对明文的知识证明一起提交给智能合约。合约按照之前定义的逻辑同态地更新计票。

• https://eprint.iacr.org/2024/594

3. 块 999 之后 ，不再接受投票；计票已冻结，现在应该可以解密了。混淆电路 的输入是加密后计票 和一个证明 ，证明根据区块链共识, 密文可以被解密（即选举已经结束）。如果证据验证通过， 以加密后的格式返回选举计票结果。由于混淆电路是公开的，任何人都可以在本地重新运行求值 并检查计票是否正确。

这种设计有效地消除了解密阶段所需的任何交互。安全假设是，可信设置中的至少一个参与者是诚实的，且在仪式贡献后丢弃了他们的随机输入。此外，任何想要解密任何部分计票状态的攻击者都将失败，因为他们无法生成授权其解密的区块链共识证明，因此将被混淆程序 拒绝 。

这样的构造安全吗？

攻击者可能有兴趣在选举结束前了解部分计票结果以影响选举或了解特定个体的投票。由于这个信息是以加密形式公开的，因此攻击者可以获取它并试图欺骗混淆程序  来解密它。为此，他们需要区块链共识的有效证明  。

一个“简单”的攻击是创建一个新的智能合约，对特定的投票密文执行同态恒等函数并授权对输出进行解密。避免这种攻击的一种方法是强制密文背后的任何明文知识的证明要包含被授权使用此密文的智能合约的地址。

进一步的攻击需要大多数验证者串通并签署一个状态，允许根据智能合约中定义的规则解密密文。这种攻击可能会悄无声息地发生，且可能无法削减恶意验证者。我对此没有有效的解决方案。

进一步的应用

先前的构造可以扩展到许多其他应用。整套多方应用都可以（在可信设置假设下）防共谋，同时提供非交互式解密。例如拍卖、加密内存池、人工智能模型训练或多边贸易信贷抵销。另一个有趣的应用涉及 zkSNARK 的进一步的简洁化：iO 混淆电路可以设计为用来验证证明  并当且仅当证明验证通过时签署证明的声明。这种情况下，验证证明相当于验证签名，这使得它其极其省 gas。由于 iO 基本上允许区块链程序持有秘密了，因此“公共区块链可以保守秘密吗？”论文第 5 节中列出的所有用例（例如无信任跨链代币桥）均已被解锁。

• https://eprint.iacr.org/2020/464.pdf

Conclusions 结论

如果 iO 对你来说是一个新概念，就像对我一样，那么你在阅读本文后可能会感到非常兴奋。但专家们表示，现实情况是这样的 iO 构造还远远无法在实践中使用。我很好奇看到 Sora 工作的具体结果，基于标准的安全假设，因此可能会非常非常慢，而 Gauss Labs 的工作基于非标准（较少经过实践测试）的安全假设，但可能更快。就我而言，我将在接下来的几个月里尝试揭开这个话题的神秘面纱，并在这个博客上发布我学到的东西。