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