记录纳米内核的想法是ZEXE的核心，并启用了一种称为去中心化私有计算(DPC)的新加密原语。DPC 是一个应用程序就绪的框架，任何开发人员都可以使用它来构建自定义应用程序。DPC 方案中的交易按照 RNK 执行。这些根据定义是去中心化的，因为 RNK 让用户可以控制通过自定义出生/死亡谓词来确定可以使用其资产的条件。
继续解开 ZEXE 的设计，下一个设计步骤是在上述两个极端设计之间取得平衡。即支持任意函数，使用标签来标识函数。
回想一下，ZEXE 的目标是让并发进程共享一个分类帐，而不会侵犯彼此的完整性或机密性。因此需要某种操作系统来管理用户定义的功能。这种管理需要
提供进程隔离
确定数据所有权
处理进程间通信。
ZEXE 的作者决定制定一个简约的共享执行环境，该环境对记录的交互方式施加了简单但富有表现力的规则。也就是说，管理记录的“纳米内核”，因此称为记录纳米内核(RNK)。RNK 通过允许用户定义特殊功能来检查正在使用或创建的记录的合法性和有效性，从而实现对记录的管理。因此，只有满足这些功能的记录才能参与交易。
因此，记录比平常包含更多信息。它包含一个数据有效负载，以及两个称为predicates的用户定义函数，一个在创建 r 时执行的出生谓词，以及一个在消耗 r 时执行的死亡谓词。
通过适当地对这两个谓词进行编程，用户可以完全指定创建或使用记录 r 的条件。事务中涉及的所有记录的谓词被赋予事务的本地数据，作为公共输入。交易的本地数据包含；每条记录的内容、交易备忘录（即公开披露的共享内存）、辅助输入（即隐藏的内存）以及任何其他特定于构造的数据。
因此，每个谓词可以根据自己的逻辑独立检查本地数据是否有效。这样，记录可以防止可能包含“坏”出生或死亡谓词的其他记录，因为考虑到用于其他功能的本地数据，这些记录应该评估为“假”。
和以前一样，零知识证明保证消费记录的死亡谓词和创建记录的出生谓词都得到满足。
下一个示例说明了如何使用 RNK 来设计应用程序，例如自定义资产和条件交换。
示例 1：自定义“代币”或数字资产
考虑自定义数字资产的用例。在这种情况下，我们希望创建资产并随后保存它们。因此，我们可以使用带有有效载荷的记录，这些有效载荷编码资产标识符 id、初始资产供应量v和值 v。也就是说，有效载荷 =（id，v，v= v）。
我们将所有此类记录中的出生谓词固定为mint-or-conserve函数 MoC。这意味着 MoC 负责创建新资产的新供应并随后保存价值。具有资产标识符 id 的记录要么创建新资产的初始供应（“铸币”），要么确保流通中资产的总供应在各方之间转移期间不会增加（“保存”）。这里的重点是记录不会创建资产，但在某种程度上它本身就是资产！
示例 2：有条件的交换
除了创建自定义资产外，用户还可以对记录的死亡谓词进行编程，以强制执行有关如何使用资产的条件，从而实现与其他方的有条件交换。
如果 Alice 希望将 100 单位的 id_1 资产换成等价的 50 单位 id_2 资产，她会创建一个包含 100 单位 id_1 的记录 r，其死亡谓词规定任何消耗 r 的交易 tx 还必须创建另一条记录，只能由以下人员消费拥有 50 单位资产 id_2 的 Alice。
然后，她发布关于 r 的带外信息，以便任何人随后通过创建进行交换的事务来声明它。
通过设计，死亡谓词是任意的，因此可以实现各种访问策略。例如，用户可以强制执行兑换记录的交易
必须由三个公钥中的两个授权（即，使用一些多方计算），
仅在自创建后经过给定时间后才有效（使用时间锁），或
必须揭示散列函数的原像。
在 ZEXE 中，生成交易涉及创建对新记录的承诺以及计算已消费记录的唯一序列号（类似于 ZCash）。重要的是，对记录的每个承诺都需要记录所有者的地址公钥“apk”和序列号 nonce。类似地，如果没有序列号 nonce r 和所有者的地址密钥“ask”，则无法创建消费记录 r 的序列号。r 的序列号 nonce 实际上是一个抗冲突哈希函数的输出，该函数采用一些创建 r 的唯一交易信息。
请注意，在生成地址公钥“apk”时，始终将地址密钥“ask”作为输入。例如，比特币或 Zcash 交易只允许用户在拥有密钥的情况下花费硬币。在 ZEXE 中，想法大致相同。RNK 为支出记录添加的相同条件是，必须同时满足由创建要支出记录的用户设置的所有相关谓词。
同样的条件也适用于零知识证明的创建，该证明证明在提供的本地数据上计算出生和死亡谓词的正确性。因此，如果用户知道要消费的记录的密钥并且满足所有相关谓词，则用户可以生成零知识证明以附加到交易中。
图 4：更详细地说明了上述描述。
RNK 不是像比特币那样的脚本机制，而是一个支持任意程序的框架。这些程序可以作为单个事务的一部分运行，也可以跨多个事务运行——通过将适当的中间状态或消息数据存储在记录有效负载中，或者通过在事务备忘录中发布该数据（根据需要以明文或密文形式）。
因此，事务可以实现任何状态转换，将消费记录作为从区块链读取的数据，将新创建的记录作为数据写回区块链。
对于某些应用程序来说，繁重的计算是不可避免的，这可能会给计算能力有限的设备带来问题。为了解决这个问题，ZEXE 为 DPC 方案提供了另一种模式：可委托 DPC（或 DDPC）方案。这允许将耗时的计算委托给不受信任的第三方。这些第三方被赋予了产生交易所需的秘密，并将交易提交给用户，因为用户不会泄露授权交易所需的秘密。DDPC 的权衡是它不再提供功能隐私。但是，运营商不能以任何方式窃取资产或偏离用户的签名意图。因此，DDPC 提供了一个额外的选项来加快证明生成和计算时间，以换取略微减少的隐私。
ZEXE 旨在为任意程序在公共分类账上启用私有计算。本系列文章重点介绍了在基于账本的系统中引入 ZEXE 的背景、传统上如何在此类系统中处理交易信息、困扰基于隐私保护的账本系统的技术问题的数量、设计技术作者采取措施消除这些问题，以及如何实施这些技术以实现具有真正去中心化、完全隐私以及简洁验证的应用程序。
去中心化私有计算的范式不仅保证数据，而且保证功能隐私。执行完全离线，并且发布的交易增加了零知识证明，根据出生/死亡谓词证明计算的正确性。由于用户定义的谓词包含在被证明的语句中，在零知识协议下，函数调用是隐藏的，从而实现了函数隐私。由于这些零知识证明简洁且验证成本低廉，ZEXE 也消除了验证者的困境。
除了隐私之外，与虚拟机完全在链上的其他基于分类帐的系统相比，ZEXE 的方法还提供了更大的可扩展性。更重要的是，递归证明组合等较新的加密技术可能会将 ZEXE 的可扩展性提高几个数量级。
ZEXE 旨在成为支持完全私有应用程序的最小、优雅的协议。它扩展了先前的想法以实现迄今为止仅由单一应用系统单独实现的隐私和可编程性。因此，它为去中心化应用程序（如去中心化金融、游戏、身份验证等）提供了一个理想的平台。这就是为什么我们选择将 ZEXE 作为 Aleo 的基础。