作者：Siam Hussain

用户可以使用DECO来证明数据及其主张的真实性，而无需披露数据本身。本文中所提到的”真实数据”，是指通过TLS协议从特定的web服务器获取的数据。比如，用户可以证明自己从银行官网上获取了账户的财务报告，并且报告中的账户余额超过某一阈值。不过，她并不需要透露报告中的任何其他信息，比如账号或具体余额。

DECO不需要服务器端配合就可以运行。TLS服务器不需要做任何修改，甚至都不会意识到自己加入了DECO协议。这极大降低了DECO的采用门槛。

本文是DECO系列文章的开篇，该系列将详细阐述DECO开发过程中遇到的种种挑战，它如何从一篇名为《ZMMG+20》的学术论文落地成具体的产品，如何在底层采用交互式零知识证明技术，以及针对实际部署进行了哪些优化。如果你对于DECO技术背后的开发逻辑及其用例感兴趣，那么可以先从这篇文章看起。作为开篇，本文会对DECO及其核心技术——零知识证明做一个简单的介绍。

快速了解交互式零知识证明（Interactive Zero-Knowledge Proofs）

零知识证明是DECO的核心技术，其作用是保障隐私。在TLS协议中，客户端在每个session中都会创建新的身份验证质询，以验证服务器的身份。因此，TLS和DECO协议都具有交互属性。在这个基础上，我们采用了基于VOLE的零知识证明技术，其特色是交互式的“提交并证明”模式（commit-and-prove），以提升速度、减少数据存储压力并实现更高的可扩展性。我们对DECO协议做了简单的总结，请阅读关于交互式零知识证明的系列博客文章（https://blog.chain.link/tag/zkseries/）。

承诺（commitment）是一个密码学的概念，我们可以把它想象成一个上了锁的盒子。证明者（prover）对变量x作出承诺，这就相当于把x放到一个上锁的盒子里，然后把盒子发送给验证者（verifier）。验证者虽然无法看到这个数值，但可以确定证明者一旦将数值发送出去就无法再篡改。然后，证明者将密钥发给验证者，验证者用密钥来“打开”这个承诺（注：也就是盒子）。我们把对x的承诺表示为[x]。

由于对逻辑门 (AND/XOR) 的输入作出了承诺，因此证明者和验证者可以对输出的承诺进行计算。证明者可以通过以下几个步骤来证明组成这些逻辑门的电路是否计算正确：

1）证明者对电路的输入作出承诺。

2）证明者和验证者一起，基于拓扑排序来计算对逻辑门输出作出的承诺。

3）证明者打开对电路输出作出的承诺。

DECO零知识证明底层的承诺机制采用了加法同态加密算法（additively homomorphic）。也就是说，对XOR逻辑门输出作出的承诺可以在本地计算，无需任何通信或计算成本。采用零知识证明协议来评估电路，所需的成本与AND逻辑门的数量成正比。

敬请期待后续文章

• 证明数据的真实性：DECO协议的第一步，就是证明者需要说服验证者相信TLS响应是从某个特定服务器发送的。整个过程跟TLS协议非常相似。首先，证明者和服务器会生成一组对称密钥，用于加密TLS请求和响应。然后，证明者会将来自服务器的密文解密。验证者既看不到密钥，也看不到响应的内容。但是验证者会积极参与到协议中，以保障证明者正确计算密钥、响应以及零知识证明承诺。这篇文章探讨了验证者如何参与TLS协议，并验证响应的真实性。
• 解析响应：验证者确认响应的真实性后，下一步就是解析响应，以获取相关信息。这一步的主要挑战就是要验证解析过程的正确性，同时还要避免响应中的敏感信息泄露。
• 隐藏敏感数据的长度：DECO底层所采用的零知识证明技术，以及大多数其他零知识证明协议，都会隐藏隐私数据，但不会隐藏数据长度。这篇文章阐述了DECO如何做到隐藏TLS交互中隐私数据的长度。
• 生成主张：这篇文章探讨了如何以明确的方式生成主张。另外，文章还探讨了验证者如何在不看到响应内容的情况下对适当的响应输入作出承诺。
• 证明多个响应：在一些DECO用例中，主张会从多个响应中获取信息，可能会涵盖来自多个服务器的多个TLS会话。这篇文章探讨了DECO如何将这些响应归集到同一个证明中。