原文：Anthony Matlala
翻译：Kurt Pan
自加密货币出现，分布式账本系统变得流行起来。典型的分布式账本方案建立在区块链技术上，其特点是特定的数据结构，以区块的形式保存交易信息的记录。这些数据块通过称为哈希的密码学计算数“链接”或连在一起，并且该哈希值唯一地标识给定块。
尽管越来越受欢迎，分布式账本系统方案通常只提供有限的隐私。此外，确实提供隐私的方案通常在其支持的程序的表达能力方面受到限制。
正是这个问题促使隐私研究人员（包括几位 ZCash 创始科学家）提出了一个他们称为 ZEXE或零知识执行的方案。ZEXE 是第一个基于账本的方案，在该方案中应用程序可以在无信任、私密和可扩展的情况下执行。
虽然 Aleo 是由 ZEXE 的几位作者创立的，并且该研究是其计算模型的关键部分，但 Aleo 不仅仅是 ZEXE，其额外提供了用于编写私有应用程序的完整系列方法。
尽管如此，ZEXE 是 Aleo 中的核心组件。然而在研究圈之外，它仍然相对不为人知。本系列文章的目的是提供 ZEXE 设计策略背后的额外背景、它支持的功能以及可以使用它构建的真实世界应用的描述。
预备知识
为了欣赏 ZEXE 的设计，先了解更多关于加密货币底层是如何工作是至很重要的。我们首先从一些额外的内容开始，并解释使 ZEXE 成为可能的底层密码原语。
因此，在下一节中我们将讨论有关加密货币隐私的一些关键概念，以及作为 ZEXE 和其他隐私模型的关键部分的两个加密原语：承诺方案和零知识证明。
数据隐私和功能隐私
在加密货币中，交易是某种价值交换的记录，以数字资产的形式，从一个钱包地址到另一个钱包地址。例如，比特币交易由三部分组成：输入 ，输出和发送的金额 ，尽管金额实际上反映为输出的一部分。
因此，如果 Bob 向 Alice 发送 50 BTC，那么
- 输入是 Bob 最初从中收到 50 BTC的旧 BTC 地址、上一笔交易的哈希值以及将这些币给Bob 的人的签名
- 金额 是 Bob 发送的 50 BTC
- 输出 通常包括上述金额 、 Alice 的地址、当前交易的哈希值和 Bob 的签名。
任何查看比特币账本的人都可以看到此交易信息。尽管没有明确记录比特币所有者的姓名，但对于具有适度计算能力的坚定攻击者来说，最终将地址与真实所有者相关联并不难。出于这个原因，比特币只是伪名的，实际上并不提供真正的隐私。
为了解决这个问题，像门罗币这样的隐私加密货币使用了隐形地址。也就是说，对于每笔交易，币的发送者 A 为接收者 B 选择一个随机的一次性地址。通过使用隐形地址，只有发送者和接收者才能确定支付在哪里发生。这是引入比比特币更好的隐私的一种方式。
以太坊等基于帐户的系统具有更差的隐私属性，因为每个公钥都被重复用作地址。然而，以太坊确实提供了其他隐私方案在很大程度上缺乏的额外可编程性。
承诺方案
承诺方案有以下三个步骤：
- 密钥生成：( pk , vk )←key。密钥生成算法输出一对密钥，证明者的密钥 pk 和验证者的密钥 vk，分别发送给证明者 P 和验证者 V。
- 承诺阶段：( com , d )←Com( pk , m )。Com 算法将证明者的密钥和要承诺的消息作为输入。然后它输出承诺 com 以及一个打开值 d，仅会在验证阶段发送给 V。承诺 com 被发送到 V。
- 验证阶段： b ←Ver( vk , com , m , d )。算法 Ver 将验证密钥 vk、承诺 com、原始消息 m 和开放值 d 作为输入。它输出一个布尔值 b，即 成功 或 失败。
零知识证明
零知识证明涉及两方，证明者 P 和验证者 V。验证者 V 挑战证明者 P 以解决给定的数学难题。然后，证明者 P 解决了这个难题，但她不是将解决方案w发送给 V，而是创建了一个证明 π ，该证明 π 应该让 V 相信她已经正确解决了这个难题，但不会透露任何关于她解决方案的信息。
零知识证明的主要目的是使 V 能够轻松确定 P 的证明 π的真实性， 从而进行交易。
对于像比特币这样的支付用例，为了在两方之间发生任何交易，发送方需要承诺向接收方支付一定的价值。因此，需要一个承诺方案来做出对发送者具有约束力的承诺。但是该方案还需要对接收者隐藏，以便正确地实现零知识。也就是说，除非发送者公开它（即向接收者发送密钥以显示数额），否则接收者应该无法确定所承诺价值的确切数量。
因此，为了让 Alice 隐私地向 Bob 发币，她需要做两件事：
- 首先，她使用承诺方案来“加密”她想要发送给 Bob 的币的价值。承诺值不仅是隐藏的，而且还绑定到 A。
- 其次，Alice创建一个零知识证明 π，证明Alice拥有她想发送给Bob的币这一事实，但不透露任何有关交易的信息。
然后 Alice 将她的承诺连同相应的零知识证明 π一起发布。
请注意，通过实现如上所述的承诺方案和零知识证明，可以成功隐藏状态转换的输入和输出，但不能隐藏哪个转换函数正在被执行。这达到了数据隐私，因为发送者、接收者和发送的金额都是隐藏的。
ZEXE 设计策略
ZEXE 是为了隐私保护的去中心化应用程序（如去中心化交易所）的一种方案。它旨在利用基于账本的系统，并支持多种功能，包括用户定义的可替代资产、跨应用通信和公共可审计。当然，所有这些都需要以零知识的方式来实现。
为了实现上述目标，ZEXE 以多种方式打破了现有的隐私区块链。
- ZEXE 提供了一个共享执行环境，多个应用在同一个账本上交互。
- 交易的内容不再局限于价值转移，而是代表了一种更通用的数据单元，称为记录。此外，用户可以使用相关谓词定义自己的函数，这些谓词规定了可以使用资产的条件，而无需请求许可。
- ZEXE 不是链上执行环境，而是选择离线计算来生成交易并为每笔交易附加一个零知识证明，以证明其正确执行。
- 结果得到了一种新的加密原语协议，称为去中心化隐私计算 （DPC）。
Zerocash 交易
第一个使用承诺方案和零知识证明来提供隐私的现实世界系统是 Zerocash。Zerocash 交易 tx 是一种“操作”，它使用旧的对币的承诺作为输入，并输出新创建币的承诺以及证明交易计算正确的零知识证明。
在账本上，每笔交易包括：
- 消费的币的序号，{sn₁, sn₂, ... , snₘ},
- 已创建币的承诺，{ com₁, com₂, ... , comₙ } 和
- 证明两个事实的零知识证明 π ，
(i) 消费的序列号属于过去创造的币（不去识别具体是哪些，从而确保交易各方的隐私），
(ii) 承诺包含与消耗的币总价值相同的新币（确保系统的整体经济完整性）。
这就是 Zerocash 系统如何使用零知识证明来确保币的一次性消费，从而防止双花的。
注意上面图 1 中的币承诺的索引没有重复。这三个新的承诺被标记为 4、5 和 6，而不是 1、2 和 3，以表示承诺的唯一性。同样，每个币都有一个唯一的序列号sn，没有两个币可以共享一个序列号。
Zerocash 交易是私密的，因为它只显示消耗了多少币以及创造了多少币，但币的价值是保密的。如前所述，这提供了数据隐私。而且，在 Zerocash 是单一功能协议的情况下，默认情况下是实现了功能隐私的，因为并不需要区分一个功能与另一个功能。
扩展 Zerocash 计算模型
Zerocash 是分布式账本系统隐私方面的一项突破。但不幸的是，该方案提供的功能有限。如果我们想做的不仅仅是简单的隐私资产转移怎么办？
以以太坊为例，它支持数千个独立的 ERC-20 “代币”合约，每个合约都代表以太坊账本上的一个不同的货币。在处理所有不同的跨币种交易时，涉及到许多函数调用，这些函数调用都嵌入到特定的应用程序中。但是由于每个应用程序的内部状态都是公开的，与每个应用程序相关的函数调用历史也就都是公开的。
即使这些合约中的每一个都将单独采用诸如 Zerocash 之类的零知识协议来隐藏有关代币支付的详细信息，相应的交易仍将揭示正在交换的代币。因此，虽然状态转换的输入和输出是隐藏的并因此实现了数据隐私，但正在执行的转换函数是公开的。因此，在以太坊模型中实现功能隐私是不可能的。
ZEXE 正是受到这个问题的启发。在 ZEXE 中，目标不仅是提供数据隐私（如 Zerocash），而且也要提供功能隐私。区块链的被动观察者对正在运行的应用程序应该一无所知，也无法识别相关方。因此，ZEXE 模型可以支持私有 dApp、暗池、私有稳定币等丰富的应用。该编程模型还允许多个应用程序在同一个账本上进行交互，并促进用户定义的功能，以实现完全去中心化的系统。
验证者的困境
基于账本的系统的另一个吸引人的属性是可审计性。无论是监管者还是区块链的新用户，轻松验证历史交易真实性的能力都至关重要。
不幸的是，许多基于账本的系统通过直接验证状态转换来实现公共可审计性。遗憾的是这种交易验证方法涉及重新执行相关计算。这种方法的问题是大型计算需要很长时间才能完成，从而使网络容易受到拒绝服务 (DoS) 攻击。
以太坊等早期的智能合约区块链通过 gas机制解决了这个问题，让用户为更长的计算付费，起到了对 DoS 攻击的威慑作用。这种方法的缺点是验证仍然很昂贵。此外，与解决工作量证明难题以找到下一个区块不同，验证交易是无利可图的。这就是所谓的验证者困境。在过去，这个问题导致了比特币和以太坊等著名区块链的分叉。
与其他区块链不同，ZEXE 中的程序执行发生在链下。此外，通过使用 zk-SNARKs，证明验证对于链上矿工或验证者来说是便宜的。因此，ZEXE 是验证者困境的有效解决方案。
实现零知识执行
我们从 Zerocash 开始，这是一种为具有单一功能的应用设计的协议，即在同一种币内进行价值转移。Zcash 是使用 Zerocash 协议的加密货币系统的一个例子。它使用零知识证明（zk-SNARKs）来实现隐私。ZEXE 的目标是将该协议从单个应用扩展到任何任意程序。
作为数据单元的记录
第一步是从币转换为以记录作为数据单元。也就是说，记录不仅存储了一个整数值，还存储了一些任意数据负载。因此，与 Zerocash 中的简单价值转移 不同，ZEXE 可以使用任意函数，只要每个人都事先知道它们。
这项更改使 ZEXE 能够支持任意程序。但是隐私呢？
在公众眼中，一笔交易又可以想象成一个消耗旧的记录承诺，并输出新创建的记录承诺和零知识证明的操作。
在创建记录时，其承诺会在账本上发布，并且只有在记录被消费后才会发布其序列号。这一次，零知识证明证明在旧记录上应用该函数产生了新记录。
与 Zerocash 案例一样，账本上的每笔交易都包括：
- 消费记录的序号，{ sn_(old₁), sn_(old₂), ... , sn_(oldₘ) },
- 创建记录的承诺，{ com_(new₁), com_(new₂), ... , com_(newₙ) } 和
- 证明如下两个事实的零知识证明 π ，
(i) 首先，序列号属于过去创建的记录（不披露记录本身），
(ii) 其次，承诺包含与所消耗记录的等值总价值的新记录。
支持任意功能
第二步，让多个用户可以自由定义自己的功能，并允许功能交互，无需任何规则。这可以通过上一步中概述的相同方法来实现。也就是说，通过允许用户固定一个通用的功能 Φ，然后将数据有效载荷 dpᵢ 解释为用户定义的功能 Φ = dpᵢ，作为 Φ 的输入提供。
使用 Zerocash 中的零知识证明将确保功能隐私。然而，仅仅允许用户定义他们的功能本身并不能带来任何有用的功能。
在这种情况下，功能隐私会产生问题，因为用户无法确定给定记录是否是根据任何给定函数以合法方式创建的。鉴于恶意用户不可避免地存在，诚实用户因此无法免受各种欺诈。
这种特殊的设计方法，用户自由定义功能的无拘无束的自由，当然是一种极端。缺乏管理用户定义功能如何交互的规则是其失败的根源。但是这个想法可以挽救吗？答案是肯定的，我们将在下一节中看到。
使用标签识别功能
设计的第三步是为每个用户定义功能 Φ 引入唯一标识符。也就是说，我们在每条记录中包含一个功能-标识标签，并使用 id-tag作为确定使用哪个功能创建记录的方法。这可以以零知识的方式完成。也许 id-tag 被定义为在给定值 vᵢ 处估值的函数 Φ 的哈希值。也就是说，idᵢ = H(Φ (vᵢ))。因此，如果哈希函数是抗碰撞的，每个函数 Φ 将有一个唯一的 id-tag id_iᵢ。
由于“没有规则”是上述欺诈问题的根本问题，因此在这种情况下可以强制执行一条规则。也就是说，只有具有相同 id-tag 的记录才被允许在同一交易中合作。
零知识证明可以保证参与同一交易的记录确实具有相同的功能 id-tag。这将保证只有同一功能创建的记录参与同一交易。
尽管这种类型的系统提供了合理的功能，但它受到完全的过程隔离的影响。结果其即使是简单的代币交换也无法实现。但是，它代表了朝着正确方向迈出的一步。
记录纳米核心（RNK）
下一个设计步骤是在上述两个极端设计之间取得平衡。即支持任意功能，使用标签来标识功能。
回想一下，ZEXE 的目标是让并发进程们共享一个账本，而不会违反彼此的完整性或机密性。因此需要某种操作系统来管理用户定义功能。这种管理需要
- 提供进程隔离
- 确定数据所有权
- 处理进程间通信。
ZEXE 的作者决定制定一个最简的共享执行环境，该环境对记录的交互方式赋予了简单但富有表现力的规则。也就是说，一个管理记录的“纳米核心”，因此称为记录纳米核心（RNK)。RNK 通过允许用户定义特殊功能来检查正在使用或创建的记录的合法性和有效性，从而实现对记录的管理。因此，只有满足这些功能的记录才能参与交易。
因此，记录比平常包含更多信息。它包含一个数据负载，以及两个称为谓词的用户定义函数，一个在创建 r 时执行的出生谓词，以及一个在消耗 r 时执行的死亡谓词。
通过适当地对这两个谓词进行编程，用户可以完全指定创建或使用记录 r 的条件。事务中涉及的所有记录的谓词被赋予事务的本地数据，作为公共输入。交易的本地数据包含；每条记录的内容、交易备忘录（即公开披露的共享内存）、辅助输入（即隐藏的内存）以及任何其他特定于构造的数据。
因此，每个谓词都可以根据自己的逻辑独立检查本地数据是否有效。这样，记录可以防止其他可能包含“坏”出生或死亡谓词的记录，因为考虑到用于其他功能的本地数据，这些记录会被评估为“假”。
和以前一样，零知识证明保证消费记录的死亡谓词和创建记录的出生谓词都得到满足。
RNK 下的谓词示例
下一个示例说明了如何使用 RNK 来设计应用程序，例如自定义资产和条件交换。
- 示例 1：自定义“代币”或数字资产
考虑自定义数字资产的用例。在这种情况下，我们希望创建资产并随后保存它们。因此，我们可以使用带有有效负载的记录，这些有效负载编码资产标识符 id、初始资产供应量v和值 v。也就是说，有效负载 =（id，v，v= v）。
我们将所有此类记录中的出生谓词固定为mint-or-conserve 函数 MoC。这意味着 MoC 负责创建新资产的新供应并随后保存价值。具有资产标识符 id 的记录要么创建新资产的初始供应（“mint”），要么确保流通中资产的总供应在各方之间转移期间不会增加（“conserve”）。这里的重点是记录不会创建资产，但在某种程度上它本身就是资产！
- 示例 2：有条件的交换
除了创建自定义资产外，用户还可以对记录的死亡谓词进行编程，以强制执行有关如何消费资产的条件，从而实现与其他方的有条件交换。
如果 Alice 希望将 100 单位的 id_1 资产换成等价的 50 单位 id_2 资产，她会创建一个包含 100 单位 id_1 的记录 r，其死亡谓词规定任何消耗 r 的交易 tx 还必须创建另一条记录，只能由拥有 50 单位资产 id_2 的 Alice消费。
然后，她发布关于 r 的带外信息，以便任何人随后通过创建进行交换的事务来声明它。
通过设计，死亡谓词是任意的，因此可以实现各种访问策略。例如，用户可以强制执行兑换记录的交易
- 必须由三个公钥中的两个授权（即，使用一些多方计算），
- 仅在自创建后经过给定时间后才有效（使用时间锁），
- 必须揭示哈希函数的原像。
RNK 下的交易
在 ZEXE 中，生成交易涉及创建对新记录的承诺以及计算已消费记录的唯一序列号（类似于 ZCash）。重要的是，对记录的每个承诺都需要记录所有者的地址公钥“apk”和序列号 nonce。类似地，如果没有序列号 nonce r 和所有者的地址密钥“ask”，则无法创建已消费记录 r 的序列号。r 的序列号 nonce 实际上是一个抗碰撞哈希函数的输出，该函数采用一些创建 r 的唯一交易信息。
请注意，在生成地址公钥“apk”时，始终将地址密钥“ask”作为输入。例如，比特币或 Zcash 交易只允许用户在拥有密钥的情况下花费币。在 ZEXE 中，想法大致相同。RNK 为支出记录添加的相同条件是，必须同时满足由创建要支出记录的用户设置的所有相关谓词。
同样的条件也适用于零知识证明的创建，该证明证明在提供的本地数据上计算出生和死亡谓词的正确性。因此，如果用户知道要消费的记录的密钥并且满足所有相关谓词，则用户可以生成零知识证明以附加到交易中。
关于 RNK 的说明
RNK 不是像比特币那样的脚本机制，而是一个支持任意程序的框架。这些程序可以作为单个交易的一部分运行，也可以跨多个交易运行——通过将适当的中间状态或消息数据存储在记录有效负载中，或者通过在事务备忘录中发布该数据（根据需要以明文或密文形式）。
因此，交易可以实现任何状态转换，将消费记录作为从区块链读取的数据，将新创建的记录作为数据写回区块链。
代理 DPC
对于某些应用程序来说，繁重的计算是不可避免的，这可能会给计算能力有限的设备带来问题。为了解决这个问题，ZEXE 为 DPC 方案提供了另一种模式：可代理 DPC（或 DDPC）方案。这允许将耗时的计算委托给不受信任的第三方。这些第三方被赋予了产生交易所需的秘密，并将交易提交回给用户，因为用户不会泄露授权交易所需的秘密。DDPC 的权衡是它不再提供功能隐私。但是，运营商不能以任何方式窃取资产或偏离用户的签名意图。因此，DDPC 提供了一个额外的选项来加速证明生成和计算时间，以略微减少的隐私为代价。
结论
ZEXE 旨在为任意程序在公共账本上进行隐私计算。本文重点介绍了在基于账本的系统中引入 ZEXE 的背景、传统上如何在此类系统中处理交易信息、困扰基于隐私保护的账本系统的技术问题、采取的消除这些问题的技术措施，以及如何实现这些技术以实现具有真正去中心化、完全隐私以及简洁验证的应用程序。
去中心化隐私计算的范式不仅保证数据，而且保证功能隐私。执行完全发生在线下，并且已发布的交易增加了零知识证明，以根据出生/死亡谓词证明计算的正确性。由于用户定义的谓词包含在被证明的语句中，在零知识协议下，函数调用是隐藏的，从而实现了功能隐私。由于这些零知识证明简洁且验证成本低廉，ZEXE 也消除了验证者的困境。
除了隐私之外，与虚拟机完全在链上的其他账本系统相比，ZEXE 的方法还提供了更大的可扩展性。更重要的是，递归证明组合等较新的密码学技术可能会将 ZEXE 的可扩展性提高几个数量级。
ZEXE 旨在成为支持完全隐私应用程序的最小、优雅的协议。它扩展了先前的想法以实现迄今为止仅由单一应用系统单独实现的隐私和可编程性。因此，它为去中心化应用程序（如去中心化金融、游戏、身份认证等）提供了一个理想的平台。这就是为什么我们选择将 ZEXE 作为 Aleo 的基础。