| id | title |
|---|---|
life-of-a-transaction |
交易的生命周期 |
为了更深入的了解Libra交易的生命周期，我们将跟踪一笔交易，从提交到Libra验证器，到使用Libra区块链处理确认交易的整个过程。然后，我们将“放大”来看验证器的每个逻辑组件及与其他组件之间的交互。
由Libra 客户端构造一个原始的交易（就称它为T5raw）将10个Libra Coin从 Alice 账户转移到 Bob 账户。原始交易包含以下字段，每个字段都和词汇表定义加上了超链接关联。
- Alice的账户地址.
- 一段代表 Alice 要执行操作的程序，包含如下:
- Move语言点对点字节码交易脚本.
- 脚本输入参数列表 (例如，Bob的帐户地址和付款金额).
- Gas价格 (以 microlibra/gas 为单位) — 发送方执行交易时需要为每单位gas支付的价格。 Gas是支付的是在区块链上计算和存储的费用。Gas是一个计算量的抽象，没有具体固定的真实价值。
- Alice愿意为此次交易支付的最高Gas量 。
- 交易的到期时间 。
- 序号 — 5
- 序号为5的交易只有在帐户有5个交易是才能应用（发出交易）。
客户端使用Alice的私钥对交易T5raw进行签名。签名后的交易T5包括以下内容：
- 原始交易。
- Alice的公钥
- Alice的数字签名
为了描述交易 T5 的生命周期，我们假设：
- Alice和Bob在Libra区块链上有账户 .
- Alice的账户中有110个 Libra 币。
- Alice的帐户的当前序列号 是5（表示已经从Alice的帐户发送了5个交易）。
- 网络上总共有100个验证器 — 网络上的 V
1到 V100。 - 客户端将交易 T
5提交给验证器 V1 - 验证器 V
1本轮（共识）的提议者/领导者。
在本节中，我们将描述交易T5的生命周期，从客户端提交开始到交易在Libra区块链确认。
根据相关度和在交易生命周期中步骤的编号，我们提供链接进一步说明验证器节点及其相应组件之间的交互，熟悉了交易的生命周期中所有的步骤后，你可以进一步阅读每个步骤中相应组件之间的交互信息的链接。
注意: 本文档中所有图形中的箭头启动源自（哪一个）交互/操作的组件，并终止于（哪一个）正在执行操作的组件。 箭头不表示读取，写入或返回的数据。
图1.1交易生命周期
1 — 客户端将交易 T5 提交给验证器 V1 ，验证器V1的准入控制（AC）组件接收该交易。 (客户端 → AC AC.1)
2 — AC将使用虚拟机（VM）组件执行验证检查，例如签名验证，检查Alice的帐户是否有足够的余额，检查交易 T5 是否未被重复广播等。(AC → 虚拟机 AC.2, VM.1)
3 — 当 T5 通过验证检查时，AC将 T5 发送到V1的内存池。(AC → 存池 AC.3, MP.1)
4 — 内存池将 T5 保存在内存缓冲区中。 内存池可能已包含从Alice的地址发送的多个交易。
5 — 使用shared-内存池协议，V1 将共享其内存池中的所有交易（包括T5）给其他验证器（V2到V100）广播交易，并将从其他验证器接收的交易放入其自己的内存池中。(内存池 → 其他验证器 MP.2)
6 — 由于验证器 V1 是提议者/领导者，它将从其内存池中提取一个交易块，并通过其共识组件将此块作为提议复制到其他验证器。(共识 → 内存池 MP.3, CO.1)
7 — V1 的共识模块负责在所有验证器之间协调提议块中交易的顺序。 (共识 → 其他验证者 CO.2)。 有关我们提出的共识协议LibraBFT的详细信息，请参阅我们的Libra区块链中的状态机复制 技术论文。
8 — 作为达成协议的一部分，交易块（包含 T5 ）被传递给执行组件。 (共识 → 执行 CO.3, EX.1)
9 — 执行组件在虚拟机（VM）中管理交易的执行。 请注意，在块中的事务已经达成一致之前，这种执行是按推测进行的。 (执行 → VM EX.2, VM.3)
10 — 在执行块中的交易之后，执行组件将块中的交易（包括 T5 ）附加到Merkle累加器（分布式历史账本）。这是Merkle累加器的内存/临时版本。 这些交易（建议/推测）的结果会返回到共识组件。 (共识 → 执行 CO.3, EX.1). 从“共识”到“执行”的箭头表示执行交易的请求是由共识组件发出的。 （本文档为了箭头使用含义一致，因此不使用箭头来表示数据流）。
11 — （共识领导者）试图与参与共识的其他验证者就该块的执行结果达成共识。 (共识 → 其他验证者 CO.3)
12 — 如果块的执行结果由一组具有超过多数票数的验证器达成一致后并签名了，则验证器 V1 的执行组件从高速缓存中读取块执行的结果并提交块中的所有交易至持久存储。 (共识 → 执行 CO.4, EX.3), (执行 → 存储 EX.4, ST.3)
13 — Alice的账号现在有100个Libra 币，其序列号为6. 如果 T5 由Bob重放，它将被拒绝，因为Alice的账号（6）的序列号大于重放的交易的序列号（5）。
在上一节，我们描述了一个交易从提交到在区块链中确认的一个典型交易生命周期过程。现在让我们更深入的了解验证器组件之间的交互，验证器如何处理交易并响应查询。相信这些信息对以下人员更有用:
- 想要全面了解系统底层如何工作。
- 有兴趣为Libra Core软件做出贡献。
为了叙述方便，我们假设客户端将交易 TN 提交给验证器 VX。 对于每个验证器组件，我们将在相应组件（章节）下描述其每个组件之间交互。 请注意，描述组件间交互的子部分未严格按其执行顺序列出。 大多数交互与交易的处理相关，少数与客户端读取查询相关（查询区块链上的已知信息）。
让我们看一下验证器节点的核心逻辑组件:
在每个部分的末尾，我们提供了Libra Core 中相应说明链接
图 1.2 准入控制
准入控制组件是验证器的_唯一外部接口_。 客户端向验证器发出的任何请求都会先转到AC。
客户端将交易 VX 提交给验证器的准入控制组件。 这通过 AC::SubmitTransaction() 来完成
准入控制访问验证器的虚拟机（VM）并对交易初步检查，以便尽早拒绝格式错误的交易。 这通过
VM::ValidateTransaction() 来完成 。
一旦 VM::ValidateTransaction() 没有返回错误, AC通过 Mempool::AddTransactionWithValidation(). 将交易转发到验证器 VX 的内存池。 只有当 TN 的序列号大于或等于发送者帐户的当前序列号时，验证器 VX 的内存池才会接受来自AC的交易 TN （请注意，除非交易序号是下一个序列号，否则交易无法达成共识）
当客户端对Libra区块链执行查询时（例如，为了获得Alice帐户的余额），AC直接与存储组件交互以获取所请求的信息。
有关实现细节，请参阅准入控制文档.
图 1.3 虚拟机
Move 虚拟机 (VM) 验证并执行Move字节码编写的交易脚本。
当验证器 VX 的准入控制模块从客户端接收到交易时，它会调用VM上的 VM::ValidateTransaction() 来验证交易。
当AC或内存池通过 VM::ValidateTransaction() 请求虚拟机验证交易时，虚拟机从存储加载交易发送者的帐户并执行以下验证：
- 检查交易中的签名是否正确（如发现错误签名的交易则拒绝）
- 检查发送人的帐户身份验证key是否与其公钥（对应签署交易私钥）的哈希相同。
- 验证交易的序列号是否不小于发件人帐户的当前序列号。 执行此检查可防止针对发件人帐户重放交易。
- 验证签名交易中的程序代码有没有格式的错误，因为虚拟机无法执行格式错误的程序代码。
- 验证发件人帐户中是否有足够的余额来支付交易中指定的最大Gas量，从而确保交易可以支付资源使用费。
执行组件通过调用虚拟机的 VM::ExecuteTransaction() 执行交易。
这里重点要理解：执行交易不同于更新分布式账本的状态和将执行结果保存在存储。 交易 TN 作为在共识期间尝试达成一致的一部分先执行。 如果与其他验证节点就交易顺序及其执行结果达成了一致，那么结果就将保留在存储中，并更新分布式账本的状态。
当内存池通过共享的内存池从其他验证器接收交易时，内存池会在虚拟机上调用 VM::ValidateTransaction() 来验证交易。
详细的实现细节参考虚拟机文档.
图 1.4 内存池
内存池是一个共享缓冲区，用于保存“等待”执行的交易。 当新交易添加到内存池时，内存池与区块链系统中的其他验证器共享此交易。 为了减少“共享内存池”中的网络消耗，每个验证器负责将其自己的交易传递给其他验证器。 当一个验证器从另一个验证器的内存池接收到一个交易时，该交易将被添加到接收者验证器的内存池中。
- 执行初始验证检查后，验证器的AC将交易发送到验证器的内存池。
- 但是仅当 T
N的序列号大于或等于发件人帐户的当前序列号时，验证器 VX中的内存池才接收发送人帐户的交易 TN。
- 验证器 V
X的内存池与同一网络中的其他验证器共享交易 TN。 - 其他验证器与验证器 V
X（相互）共享内存池中的（所有）交易。
- 当验证器 V
X成为领导者时，其共识模块将从其内存池中提取一个交易块并将该块复制给其他验证器。 这样做的目的是为了将交易的排序和块中交易的执行结果达成共识。 - 请注意，因为交易 T
N包含在共识块中，它不能保证 TN最终会存储在区块链的分布式数据库中永久存储。
当内存池从其他验证器接收到交易时，内存池会在虚拟机上调用 VM::ValidateTransaction() 来验证交易。
详细的实现细节参考内存池文档.
图 1.5 共识组件
共识组件负责处理排序交易块，并通过与网络中参与[共识协议]的其他验证器一起达成一致结果。
当验证器 VX 是领导者/提议者时，验证器 VX 的共识通过 Mempool::GetBlock() 从其内存池中提取一个交易块，并发出提议。
如果 VX 是提议者/领导者，则其共识组件将提取的交易块复制给其他验证器。
- 为了一个交易块得到执行，共识与执行组件进行交互。 通过调用执行组件
Execution:ExecuteBlock()来执行交易 (参考 共识 → 执行) - 在执行完块中的所有交易之后，执行组件响应（结果返回）共识组件这些交易执行的结果。
- 共识签署执行后的结果，并尝试与参与协商的其他验证节点就此结果达成一致。
如果网络中有足够的验证器为同一执行结果投票，则验证器 VX 的共识组件通过 Execution::CommitBlock() 来通知执行组件该交易块已准备好提交。
详细的实现细节参考共识文档.
图 1.6 执行
执行组件的工作是协调交易块（区块），并维持一个可以通过共识协商投票的过渡状态。
- 共识组件通过
Execution::ExecuteBlock()来请求执行组件执行交易块。 - 执行组件维护一个“暂存器”，它将保存存储器中Merkle累加器中相关部分的副本。 此信息用于计算区块链当前状态的根哈希值。
- 当前状态的根哈希与关于块中的交易信息组合以确定Merkle累加器的新根哈希值。 这一步在保留任何数据之前就执行了，这是为了确保在足够数量的验证者达成协议之前不会存储任何状态或交易。
- 执行组件计算推测根哈希值，然后验证器 V
X的共识签署此根哈希值，并尝试与其他验证器达成对此根哈希值的协议。
当共识请求执行组件使用：Execution::ExecuteBlock() 执行交易块时，执行组件使用虚拟机来确定执行交易块的结果。
如果足够（法定）数量的验证器同意该块的执行结果，那么每个验证器调用其执行组件的 Execution::CommitBlock() 表示区块已准备提交。 该调用会包含同意验证器的签名及为证明其同意了提案。
执行组件从其“暂存器”获取值，并通过 Storage::SaveTransactions() 将它们发送到存储器以实现持久存储。 执行筛选删除 “暂存器” 中的旧值（例如，无法提交的块）。
详细的实现细节参考执行文档.
图 1.7 存储
存储组件保存共识执行后的交易块及其执行结果。 在以下情况下，一个/一组块的交易（包括交易 TN ）将通过存储组件保存：
- 只要网络中超过 2f+1 的验证者就以下所有问题通过共识协议达成共识：
- 在块中包含哪些交易。
- 交易的排序。
- 包含在块中的交易的执行结果。
有关如何将交易附加到区块链中数据结构的信息，请参阅Merkle累加器 。
当AC或内存池调用VM::ValidateTransaction()来验证交易时，VM::ValidateTransaction()从存储中加载发送人的帐户，并通过仅读方式来检查交易的有效性。
当共识组件调用 Execution::ExecuteBlock() 时，执行组件从存储中读取当前状态并结合内存中的“暂存器”数据来确定执行结果。
- 一旦达成了对交易块的共识，执行组件就会通过调用
Storage::SaveTransactions()来存储来保存交易块并永久记录它们。 同时还将存储网络中同意该交易块验证器节点的数字签名。 - 该块中“暂存器”的内存数据将更新到存储中，并保存交易。
- 更新存储时，所有被交易变更过的资源的序列号都会相应更新。
- 注意：对于来自该帐户的每个已提交交易，Libra区块链上的帐户序列号都会增加1。
客户端查询区块链中的信息，AC直接与存储组件交互以读取所请求的信息。
详细的实现细节参考存储文档.
- 来到 Libra 世界.
- Libra 协议核心概念 — 介绍Libra 协议的核心概念
- Libra上的第一笔交易 — 指导使用Libra CLI客户端在Libra区块链上执行第一笔交易。
- 了解 Move 语言 — 介绍新区块链编程语言Move。
- Libra Core 概要 — Libra Core 组件的概念和实现细节。
- CLI 命令指南 — 列出Libra CLI客户端的命令及其用法。
- Libra 术语表 — 提供Libra术语的快速参考。
- Libra区块链中的状态机复制 — 详细介绍我们的共识协议LibraBFT。