状态模型

介绍

我们提出了一个基于 zkVM 的状态模型，以安全有效地处理状态转换，同时保护隐私。在我们的系统中，状态包括应用程序数据、账户、签名者、票据和票据失效器，每个都由稀疏 Merkle 树 (SMT) 或 Merkle 树表示。我们的 zkVM 执行状态转换函数，并接受签名的交易，并在将它们应用于状态之前验证它们的有效性。

路线图

• 稍后推送私有 UTXO 状态模型
• 保护用户隐私免受公共观察者侵害
• 使用单排序器 validium 模型
• 通过强制包含来实现避险
• 链上动作

目标：

• 灵活和动态的授权机制
• 高吞吐量
• 自定义应用程序逻辑的能力

状态由以下数据结构组成：

• 应用程序数据：稀疏 Merkle 树 (SMT)
• 账户：SMT
• 签名者：SMT
• 票据：Merkle 树
• 票据失效器：SMT

待办事项：

• Rust 中的 SMT
• 更详细地指定状态模型
• Rust 中的状态模型草图
• 签名者 / 账户等。

应用程序数据

应用程序数据（钱包程序用于存储可变参数的持久存储）存储在稀疏 Merkle 树中。

账户

账户存储在稀疏 Merkle 树中，其中 key 指的是账户的 ID，而 value 存储账户数据的哈希值。

账户数据

每个账户存储以下数据：

• 一系列已批准的签名者 [signer_0, ...]
• 公共资产：从资产 ID 到余额信息的映射
• 私有资产：私有资产存储为票据。关于账户的私有资产的任何信息都不会存储在账户数据中。

zkVM 中的账户管理

我们的 zkVM 具有用于账户管理的操作码，例如 create_account、add_signer、remove_signer、deposit、withdraw 和 transfer。这些操作码分别支持创建账户、签名者管理和资产管理。

方法

创建：

• create_account([signer_id]) -> account_id
  • 使用提供的已批准签名者列表创建一个新账户，并返回新的账户 id

签名者管理：

• add_signer(account_id, signer_id)
  • 将签名者添加到账户的已批准签名者列表中。
• remove_signer(account_id, signer_id)
  • 从账户的已批准签名者列表中删除签名者。

待办事项：这类函数是否应限于更高权限的签名者组？

资产管理：

• deposit(account_id, asset_id, balance)
  • 将资产余额存入用户的账户。
• withdraw()
  • 将资产余额存入用户的账户。
• transfer(from_account_id, to_account_id, asset_id, balance, expiration_date)
  • 使用提供的票据数据创建一个新票据。

签名者

字段 signer_id 确定排序器应运行的状态转换函数中的子例程。

1. 一个 ECDSA 验证密钥
2. 一个 EdDSA 验证密钥
3. 某个 Valida 程序的 zk 验证密钥，该程序将要验证的消息作为输入。

在上述任何一种情况下，都存在一种验证算法，用于检查签名者是否在某些消息上签名。

m。请注意，我们的交易电路需要实现上述每种方法的验证算法。

票据

我们将私有资产存储在 票据 中。票据存储在（仅追加）Merkle 树中。票据失效器存储在基于 epoch 的稀疏 Merkle 树中。

票据数据

每个票据存储以下数据：

• 所有者账户 ID：允许使用票据并将余额吸收回其账户数据的账户。
• 到期日期：发送者可以将票据消耗回其账户状态的日期。
• 资产 ID：此票据中表示的资产的 ID
• 数量：此票据中表示的资产数量
• 随机 nonce：一段固定的随机性，以确保此票据的承诺隐藏票据的内容。我们将单独描述如何确定此 nonce。

zkVM 中的票据管理

zkVM 中的票据管理涉及创建和管理私有资产或票据。以下是如何实现它的方法：

• create_note：此操作创建一个与所有者账户相关联的新票据。zkVM 指令将生成一个新的票据 ID，计算票据哈希（包括资产 ID、数量、所有者账户 ID、到期日期和随机 nonce），并将票据哈希存储在票据树中。
• consume_note：此操作允许票据的所有者使用该票据，并将其价值添加到其账户余额中。zkVM 将验证票据的所有权，对照票据树中的票据哈希检查票据的有效性，并更新账户的余额。
• update_note：此操作更新票据的属性，例如其到期日期或数量。zkVM 将验证请求，检查票据的有效性，更新票据数据，并计算票据树中的新票据哈希并存储它。

电路

电路确保状态更新正确完成。我们这里使用术语电路，但它们可以在像 Valida 这样的虚拟机中实现。

私人花费 ("JoinSplit")

私人花费电路声明一个元组 (asset_id, value)，以及一系列失效器 nf_0, ...，它们代表私人花费中花费的票据，以及一系列新的票据承诺。

私有花费电路在客户端证明。

zkVM 方法

zkVM 中的状态转换使用特定指令来处理状态更改。这些状态转换可能包括私有花费、公共花费、账户创建、账户更新等等。以下是 zkVM 如何处理应用程序逻辑的详细视图：

1. 输入验证：zkVM 将提议的状态转换作为输入，并对照当前状态验证它。它验证交易的签名者、数据的完整性以及操作的余额充足性。
2. 交易处理：zkVM 使用其指令集执行状态转换。这可能涉及创建账户、添加签名者、存入或提取资产、转移资产或创建和管理票据。
3. 状态更新：一旦状态转换经过验证和处理，zkVM 就会更新状态。这可能涉及更新应用程序数据树、账户树、签名者树、票据树或票据失效器树。
4. 输出生成：在处理交易并更新状态后，zkVM 会生成新状态，并输出要执行的任何外部操作（如资产提取或外部合约调用）。

私人花费

当从这种基于电路的方法切换到基于 zkVM 的方法时，这种交易的执行将会改变。在 zkVM 中，操作封装在指令中，而不是电路中。JoinSplit 交易的验证将在 VM 中使用一系列 zkVM 指令进行，这些指令将取代之前的电路。

在 zkVM 的上下文中，对私有花费的特定处理可能如下所示：

• 失效器检查：zkVM 将包括用于对照状态中维护的一组未花费的票据检查失效器的指令。此步骤确保花费的票据确实未花费并且属于花费者。
• 价值守恒：zkVM 将强制执行一条规则，即花费的票据的总价值必须等于正在创建的新票据的总价值。这可以通过将花费的票据和新创建的票据的价值相加，比较它们是否相等来实现。
• 证明验证：zkVM 将包含用于验证零知识证明的指令，确保花费者了解花费的票据的秘密价值（这证明了所有权）而不透露它们。
• 状态更新：验证后，zkVM 将执行指令来更新未花费的票据集，方法是删除花费的票据（由其失效器引用）并添加新票据。

我们需要 Valida 支持这些操作并存储必要的数据（如未花费的票据集）。此外，虽然原始文档提到私有花费证明是在客户端生成的，但在基于 zkVM 的方法中，VM 本身将负责生成和验证这些证明。客户端只需要提供必要的输入即可。

应用程序逻辑

应用程序逻辑电路负责更新状态。

公共输入：

• prior_state：表示先前状态中的所有树（应用程序数据、账户、签名者、票据、票据失效器）。它用于验证转换的正确性。
• external_actions：与影响状态的外部环境的一系列交互。这包括资产提取和对外部合约的调用等操作。

功能：

• validate_transactions：此函数验证状态转换中包含的所有交易的正确性。这包括检查交易签名、确保足够的账户余额以及验证转账。
• apply_transactions：将所有有效的交易应用于 prior_state。此函数更新账户余额，生成新票据，并根据交易修改签名者。
• handle_external_actions：处理 external_actions 对状态的影响。这可能包括根据资产提取或由于对外部合约的调用而产生的任何影响来更新状态。
• generate_new_state：通过将 apply_transactions 和 handle_external_actions 的结果应用于 prior_state 来生成 new_state。

输出：

• new_state：更新后的状态，由应用交易和处理外部操作产生。它包括所有树的更新版本（应用程序数据、账户、签名者、票据、票据失效器）。
• transaction_receipts：每个已处理交易的收据列表。这些收据可能包括诸如更新后的账户余额、生成的新票据以及签名者的任何更改之类的信息。
• external_action_receipts：每个已处理外部操作的收据列表。这些收据记录了外部操作对状态的影响。

通过以这种方式组织应用程序逻辑，我们可以确保以受控和可预测的方式处理每个状态转换，这对于维护我们系统的完整性至关重要。

• 原文链接： hackmd.io/@ggo37zhVSB6nc...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～