Libra教程之:Transaction的生命周期

Transaction的生命周期

本文会以一个提交到Libra validator的transaction为例，来讲解Transaction和其他组件的交互，和具体的状态变化过程。

这里我们举个例子，还是上篇文章的例子，A拥有110LBR，B拥有52LBR。接下来会构建一个原始交易Tn，将A拥有的10LBR转给B。

这个原始交易将包含如下字段：

有了这个原始交易之后，我们会使用A的私钥对这个原始交易进行签名，签名后的交易包含如下内容：

我们假设这个Libra区块链上面有100个validators，我们用V1到V100来表示。客户将这个Transaction提交到了V1。V1是这一轮共识的发起者。

我们先用一张图来表示这个Transaction入链的过程：

Transaction的入链过程可以分为五大步：

客户端将transaction提交给V1，V1的admission Control(AC)模块将会接收这个transaction。

AC是验证器的唯一外部接口。客户端对验证器的任何请求都将首先转到AC。
AC调用虚拟机（VM）的接口来验证该交易的正确性，包括：签名认证，判断账户是否有足够的金额，Tn不是一个重放交易等等信息。用以防止恶意节点。

这里虚拟机是用来执行Move脚本，也是Libra业务逻辑运行的地方。
如果Tn通过了VM的验证，那么进入下一步，AC将会把Transaction送到MemPool中。

Mempool是一个共享缓冲区，用于保存“等待”执行的事务。将新事务添加到内存池后，内存池将与系统中的其他验证程序共享此事务。为了减少“共享内存池”中的网络消耗，每个验证器负责将自己的事务传递给其他验证器。当验证者从另一个验证者的内存池接收到事务时，该事务将添加到接收者验证者的内存池中。

我们假设V1是Proposing节点，那么它会将自己mempool的交易打包成一个Block，然后通过共识模块向其他验证节点提交一个Proposal。

共识模块负责通过与网络中的其他验证者一起参与共识协议来对交易块进行排序并就执行结果达成一致。
V1的共识模块负责协调所有验证者之间对拟议区块中交易顺序的协议。

为了达成共识，在第六步生成的Block会被传递到执行模块。执行的工作是协调一组事务的执行，并保持一个可以通过共识投票的临时状态。
执行模块管理虚拟机（VM）中事务的执行。请注意，这里的执行是在区块中的交易达成一致之前进行的推测性执行。
将Block中的Transaction执行完成后，执行模块将Block中的Transaction追加到Libra区块链的Merkle累加器。这是Merkle累加器的内存/临时版本。执行这些事务的（提议/推测）结果将返回到共识组件。从“共识”到“执行”的箭头表示执行交易的请求是由共识组件发出的。
V1（共识领导者）试图与参与该共识的其他验证者就块的执行结果达成共识。

更多教程请参考 flydean的博客