> For the complete documentation index, see [llms.txt](https://gushi10546.gitbook.io/aptos-kai-fa-zhe-wen-dang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gushi10546.gitbook.io/aptos-kai-fa-zhe-wen-dang/guides-zhi-nan/jiao-yi-de-sheng-ming-zhou-qi.md). # 交易的生命周期 为了更深入地了解 Aptos 交易的生命周期（从操作的角度），我们将跟踪交易从提交到 Aptos 全节点到提交上 Aptos 区块链的整个过程。然后我们将放大关于 Aptos 节点的逻辑组件，看看交易如何与这些组件交互。 ## 假设 出于本文档的目的，我们将假设： * Alice 和 Bob 是两个用户，他们各自在 Aptos 区块链上拥有一个帐户 * Alice 的帐户有 110 个 Aptos * Alice 正在向 Bob 发送 10 个 Aptos * Alice 帐户的当前序列号为 5（表示 Alice 的帐户已经发送了 5 笔交易） * 网络上共有 100 个验证节点——V1 到 V100 * Aptos 客户端将 Alice 的交易提交到 Aptos 全节点上的 REST 服务。 全节点将此交易转发给验证器全节点，后者又将其转发给验证器 V1 * Validator V1 是当前轮次的提议者/领导者 ## **客户端提交交易** Aptos **客户端构建原始交易**（我们称之为 Traw5）将 10 个 Aptos 代币从 Alice 的账户转移到 Bob 的账户。 Aptos 客户端使用 Alice 的私钥签署交易。签署的交易 T5 包括以下内容： * 原始交易 * Alice 的公钥 * Alice 的签名 原始交易包括以下字段： | 字段 | 描述 | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------- | | Account address | Alice 的账户地址 | | Move Module |

指示要代表 Alice 执行的操作的模块（或程序）。在这种情况下，它包含：

| | Maximum gas amount | Alice 愿意为此交易支付的最大 gas 量。 Gas 是一种支付计算和存储费用的方式。gas 单位是计算的抽象度量。 | | Gas Price | Alice 愿意为每单位 gas 支付的金额（以 Aptos 币计）来执行交易。 | | Expiration time | 交易的到期时间 | | Sequence number | 账户的序列号（在本例中为 5）表示已从该账户提交并在链上提交的交易数量。在这种情况下，已经从 Alice 的账户提交了 5 笔交易，包括 Traw5。注意：序列号为 5 的交易只有在账户序列号为 5 的情况下才能在链上提交。 | | Chain ID | 区分 Aptos 网络部署的标识符（以防止跨网络攻击）。 | ## 交易**的生命周期** 在本节中，我们将描述交易 T5 的生命周期，从客户端提交到提交到 Aptos 区块链。 对于相关步骤，我们已经包含了指向验证器节点的相应组件间交互的链接。在您熟悉了事务生命周期中的所有步骤之后，您可能需要参考每个步骤对应的组件间交互的信息。

图 1.0 交易的周期

> 本文中所有视觉效果中的箭头源自发起交互/动作的组件，并终止于正在执行该动作的组件。箭头不代表读取、写入或返回的数据。 交易的周期有五个阶段： * **接受：**接受交易 * **共享：**与其他验证节点共享交易 * **提议：**提议区块 * **执行和共识：**执行区块并达成共识 * **提交：**提交区块 我们已经描述了以下每个阶段发生的情况，以及指向相应 Aptos 节点组件交互的链接。 ### **接受转账** | 描述 | Aptos 节点组件交互 | | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- | | 1、客户端→ REST 服务：客户端将交易 T5 提交给 Aptos 全节点的 REST 服务。 全节点使用 REST 服务将事务转发到自己的内存池，然后由内存池将事务转发到网络中其他节点上运行的内存池。交易最终将被转发到在验证器全节点上运行的内存池，该内存池会将其发送到验证器节点（在本例中为 V1） | 1. REST服务 | | 2. REST 服务 → 内存池：全节点的 REST 服务将交易 T5 传输到验证者 V1 的内存池。 | 2. REST 服务，1. 内存池 | | 3. Mempool → 虚拟机（VM）：Mempool 将使用虚拟机（VM）组件进行交易验证，如签名验证、账户余额验证和使用序列号的重放阻力。 | 4.内存池，3.虚拟机 | ### **与其他验证节点共享交易** | 描述 | Aptos 节点组件交互 | | ---------------------------------------------------------------------------- | ------------ | | 4. 内存池：内存池将 T5 保存在内存缓冲区中。 Mempool 可能已经包含从 Alice 的地址发送的多个交易。 | 内存池 | | 5. 内存池 → 其他验证者：使用共享内存池协议，V1 将与其他验证者节点共享其内存池中的交易（包括 T5），并将接收到的交易放入自己的（V1）内存池中 | 2. 内存池 | ### **提议区块** | 描述 | Aptos 节点组件交互 | | ------------------------------------------------------------------------------- | ------------ | | 6. 共识 → 内存池： — 由于验证者 V1 是该交易的提议者/领导者，它将从其内存池中提取一个交易块，并通过其共识组件将该块作为提议复制到其他验证者节点。 | 1. 共识，3. 内存池 | | 7. 共识 → 其他验证者：V1 的共识组件负责协调所有验证者之间就提议区块中的交易顺序达成一致。 | 2. 共识 | ### **执行区块并达成共识** | 描述 | Aptos 节点组件交互 | | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | | 8. 共识→执行：作为达成协议的一部分，交易块（包含 T5）与执行组件共享。 | 3.共识，1.执行 | | 9.执行→虚拟机：执行组件管理VM中事务的执行。请注意，此执行是在区块中的交易达成一致之前推测性地发生的。 | 2.执行，3.虚拟机 | | 10. 共识 → 执行：执行组件在执行区块中的交易后，将区块（包括 T5）中的交易附加到（账本历史的）默克尔累加器中。这是 Merkle 累加器的内存/临时版本。执行这些交易的提议/推测结果的必要部分返回给共识组件以达成一致。从“共识”到“执行”的箭头表示执行交易的请求是由共识组件发出的。 | 3.共识，1.执行 | | 11. 共识 → 其他验证者：V1（共识领导者）尝试与参与共识的其他验证者节点就提议区块的执行结果达成共识。 | 3. 共识 | ### **执行区块** | 描述 | Aptos 节点组件交互 | | ------------------------------------------------------------------------------------------------------------ | ------------------- | | 12. 共识 → 执行，执行 → 存储：如果提议区块的执行结果由一组具有法定票数的验证者达成一致并签名，验证者 V1 的执行组件从推测执行中读取提议区块执行的完整结果缓存并将提议块中的所有事务及其结果提交到持久存储。 | 4.共识，3.执行，4.执行，3.存储 | **Alice 的账户现在将有 100 Aptos，其序列号为 6。如果 Bob 重放 T5，它将被拒绝，因为 Alice 账户的序列号 (6) 大于重放交易的序列号 (5 )。** ### ### **Aptos 节点组件交互** 在上一节中，我们描述了转账的典型生命周期（从转账提交到转账执行）。现在让我们看看 Aptos 节点在区块链处理交易和响应查询时的组件间交互。此信息对以下人员最有用： * 想了解系统如何在幕后工作。 * 有兴趣最终为 Aptos 区块链做出贡献。 您可以在此处了解有关不同类型 Aptos 节点的更多信息： * 验证节点 * 全节点 对于我们的叙述，我们将假设客户将交易 TN 提交给验证者 VX。对于每个验证器组件，我们将在相应组件部分下的小节中描述其每个组件间交互。请注意，描述组件间交互的小节并未严格按照它们的执行顺序列出。大多数交互与交易处理相关，有些与客户查询区块链相关（查询区块链上的现有信息）。 以下是转账生命周期中使用的 Aptos 节点的核心组件： 全节点 * REST服务 验证节点 * 内存池 * 共识 * 执行 * 虚拟机 * 贮存 ### REST服务

图 1.1 REST 服务

客户端发出的任何请求都会首先发送到 FullNode 的 REST 服务。然后，提交的交易被转发到验证者 FullNode，然后将其发送到验证者节点 VX。 1. 客户端 → REST 服务 客户端向 Aptos FullNode 的 REST 服务提交事务。 2. REST 服务 → 内存池 REST 服务将交易转发到验证器 FullNode，然后将其发送到验证器节点 VX 的内存池。仅当 TN 的序列号大于或等于发送者账户的当前序列号时，mempool 才会接受交易 TN（注意，只有序列号与发送者的序列号匹配后，该交易才会传递给共识。帐户）。 3. REST 服务 → 存储 当客户端在 Aptos Blockchain 上执行读取查询（例如，获取 Alice 的账户余额）时，REST 服务直接与存储组件交互以获取请求的信息。 **虚拟机 (VM)**

图 1.2 虚拟机

Move VM 验证并执行用 Move 字节码编写的事务脚本 **1.虚拟机→存储** 当 mempool 通过 VM::ValidateTransaction() 请求 VM 验证交易时，VM 从存储中加载交易发送者的帐户并执行验证，其中一些已在下面的列表中描述。在此处查看完整的验证列表。 * 检查签名交易的输入签名是否正确（拒绝错误签名的交易）。 * 检查发送者的账户认证密钥是否与公钥的哈希值相同（对应于用于签署交易的私钥）。 * 验证交易的序列号是否大于或等于发送者账户的当前序列号。完成此检查可防止针对发件人帐户重播同一交易。 * 验证签名交易中的程序没有格式错误，因为格式错误的程序无法由 VM 执行。 * 验证发送者的账户余额至少包含最大gas量乘以交易中指定的gas价格，这确保了交易可以支付其使用的资源。 **2.执行→虚拟机** 执行组件利用 VM 通过`VM::ExecuteTransaction()` 执行事务。 重要的是要理解执行交易不同于更新分类帐的状态并将结果保存在存储中。交易 TN 作为尝试在共识期间就区块达成协议的一部分首先被执行。如果与其他验证者就交易的顺序及其执行结果达成一致，则结果将保存在存储中并更新分类帐的状态。 **3. 内存池 → 虚拟机** 当 mempool 通过共享 mempool 或 REST 服务接收到来自其他验证器的事务时，mempool 在 VM 上调用 VM::ValidateTransaction() 来验证事务。 有关实施详情，请参阅 [Virtual Machine README](https://github.com/move-language/move/tree/main/language/move-vm). ### **内存池**

图 1.3 内存池

Mempool 是一个共享缓冲区，用于保存“等待”执行的事务。当新交易添加到内存池时，内存池会与系统中的其他验证者节点共享此交易。为了减少“共享内存池”中的网络消耗，每个验证者负责将自己的交易交付给其他验证者。当一个验证者从另一个验证者的内存池中接收到一笔交易时，该交易就会被添加到接收方验证者的内存池中。 #### 1. REST 服务 → 内存池 * 从客户端接收到交易后，REST 服务将交易代理到验证器 FullNode。然后将交易发送到验证节点的内存池。 * 只有当 TN 的序列号大于或等于发送者账户的当前序列号时，验证者节点 Vx 的内存池才接受发送者账户的交易 TN。 2. Mempool → 其他验证节点 * 验证者节点 Vx 的内存池与同一网络上的其他验证者共享交易 TN。 * 其他验证者与 Vx 的内存池共享各自内存池中的交易。 3. 共识 → 内存池 * 当交易被转发到验证者节点并且一旦验证者节点成为领导者，其共识组件将从其内存池中提取一个交易块并将提议的块复制到其他验证者。这样做是为了就提议区块中的交易顺序和交易的执行结果达成共识。 * 请注意，仅仅因为交易 TN 包含在提议的共识块中，并不能保证 TN 最终会持久保存在 Aptos 区块链的分布式数据库中。 4. 内存池 → VM 当 mempool 收到来自其他验证者的交易时，mempool 会在 VM 上调用 VM::ValidateTransaction() 来验证交易。 有关实施详情，请参阅内存池自述文件。 ### **共识**

图 1.4 共识

共识组件负责通过与网络中的其他验证者参与共识协议来对交易块进行排序并就执行结果达成一致 1. 共识 → 内存池 当验证者 VX 是领导者/提议者时，VX 的共识组件通过：`Mempool::GetBlock()` 从其内存池中提取一个交易块，并形成一个提议的交易块。 2. 共识 → 其他验证者 如果 VX 是提议者/领导者，其共识组件会将提议的交易块复制到其他验证者。 3. 共识→执行，共识→其他验证器 * 为了执行一个交易块，共识与执行组件交互。共识通过`Execution:ExecuteBlock()`执行一个交易块（参考共识→执行） * 在提议的区块中执行交易后，执行组件以执行这些交易的结果响应共识组件。 * 共识组件签署执行结果并尝试与其他验证者就该结果达成一致。 4. 共识 → 执行 如果有足够多的验证者投票支持相同的执行结果，VX 的共识组件会通过 `Execution::CommitBlock()` 通知执行该块已准备好提交。 有关实施详情，请参阅共识自述文件。 ### **执行**

图 1.5 执行

执行组件协调一个交易块的执行，并维持一个可以通过共识投票的瞬态状态。如果这些事务成功，它们将被提交到存储。 1. 共识→执行 * 共识请求执行以通过：`Execution::ExecuteBlock()` 执行一个交易块。 * 执行维护一个“便签本”，它保存 Merkle 累加器相关部分的内存副本。此信息用于计算 Aptos 区块链当前状态的根哈希。 * 当前状态的根哈希与提议区块中的交易信息相结合，以确定累加器的新根哈希。这是在持久化任何数据之前完成的，并确保在达到法定人数的验证者达成一致之前不存储任何状态或交易。 * 执行计算推测的根哈希，然后 Vx 的共识组件签署这个根哈希，并尝试与其他验证器就这个根哈希达成一致。 2. 执行 → VM 当共识通过 `Execution::ExecuteBlock()` 请求执行以执行一个事务块时，执行使用 VM 来确定执行该事务块的结果。 3. 共识 → 执行 如果验证者的法定人数就区块执行结果达成一致，则每个验证者的共识组件通过 `Execution::CommitBlock()` 通知其执行组件该区块已准备好提交。对执行组件的调用将包括验证者的签名，以提供他们同意的证明。 4. 执行 → 存储 执行从它的“暂存器”中获取值，并通过`Storage::SaveTransactions()`将它们发送到存储以进行持久化。然后执行从“暂存器”中删除不再需要的旧值（例如，无法提交的并行块）。有关实施详情，请参阅执行自述文件。 ### **存储**

图 1.6 存储

存储组件将商定的交易块及其执行结果保存到 Aptos 区块链。当参与共识的验证者超过法定人数 (2f+1) 时，将通过存储保存一个交易块（包括交易 TN）。协议必须包括以下所有内容： -要包含在块中的交易 -交易顺序 -区块内交易的执行结果 有关如何将交易附加到表示 Aptos 区块链的数据结构的信息，请参阅 Merkle 累加器。 1. 虚拟机 → 存储 当内存池调用`VM::ValidateTransaction()` 来验证交易时，`VM::ValidateTransaction()` 从存储中加载发送者的帐户并对交易执行只读有效性检查。 2. 执行 → 存储 当共识组件调用`Execution::ExecuteBlock()`时，执行从存储中读取当前状态并结合内存中的“暂存器”数据来确定执行结果。 3. 执行 → 存储 一旦对交易块达成共识，执行通过 Storage::SaveTransactions() 调用存储以保存交易块并永久记录它们。这还将存储同意此交易块的验证节点的签名。此块的“暂存器”中的内存数据被传递以更新存储并持久化事务。当存储更新时，被这些事务修改的每个帐户的序列号都将加一。 注意：Aptos 区块链上的账户的序列号对于源自该账户的每个已提交交易递增一。 4. REST 服务 → 存储 对于从区块链读取信息的客户端查询，REST 服务直接与存储交互以读取请求的信息。 有关实施详情，请参阅存储自述文件。