libra-交易的生命周期

这篇文章主要从客户端发送一笔交易开始，到被validator打包，验证，最后存入数据库的这个完整的声明周期来介绍。看完这个，大致可以把libra中各个重要的模块给串联起来了，下一步就可以对各个模块进行源码分析了。跟上一篇一样，不是直接翻译，算是加了一些自己的理解。下面是官网的链接

Life of a Transaction · Libra​developers.libra.org

场景介绍

libra的一个客户端构造了一个raw transaction（怎么翻译比较好，原生交易？）相比普通的交易，raw transaction只有如下几个字段：

• unsigned raw transaction 这个其实是对未签名的交易数据做序列化后的二进制数据。
• sender public key 这个就是发送者的公钥
• sender signature 这个是public key对应的私钥，对unsigned raw transaction进行签名后的数据。

而普通的交易，包含的字段就是上一篇中提到过得，有什么gas price，max gas，seq等，所以unsigned raw transaction其实就是对上面字段序列化后的数据，raw transaction可以大致理解为是对普通交易的序列化后的交易。

我们用 来表示client发送的交易，该交易是Alice发送给Bob（Alice和Bob简直就是中国版的小明和小梅，密码学里出现频率最高的两位幕后大佬），该交易的seq是5，转账金额是10 libra。

下面是关于这笔交易所需要的场景假设：

• Alice和Bob在libra上都有账户了，这个地方需要注意下，对于eth来说，如果A给B转账，其实B是可以是一个不存在的地址，这里所说的不存在的地址是指第一次出现在链上。这里特意强调了Bob账户也在libra上存在，有可能是libra中账户是注册制的。
• Alice账户里有110 libra
• Alice当前的seq是5
• 当前一共有100个validators，
• Client将这笔交易 发送给
• 在这一轮共识中是leader，也就是说负责出块

场地已经布置好了，情景概要也OK了，接下来就开始介绍这笔交易的生命周期了。

Lifecycle of the Transaction

我们先用libra的官网的图

libra交易生命周期

这里的数字表示交易 在各个模块的流转过程。我们大致可以将生命周期分成5部分：接受交易（Accepting the Transaction），广播交易（Sharing the Transaction With Other Validators），打包出块（Proposing the Block），执行交易（Executing the Block and Reaching Consensus），达成共识（Committing the Block）。

下面按照上面的5个部分来讲，序号对应着上图的序号。

Accepting the Transaction

1. client将交易 发送给 ，作为唯一对外的接口，AC会处理所有client发过来的请求。具体AC是如何接受该请求的，会在AC.1中给出。（这里的AC1表示下面在介绍AC模块的时候对应序号1）
2. AC在收到请求后，需要对 进行验证，这个时候会调用VM模块，这里主要验证的有签名是否正确，Alice账户的余额是否足够，seq是否为5.（涉及的模块为：AC.2,VM.1）
3. 通过了AC的验证后，AC就会将 加入到mempool（MP）中。（AC.3,MP.1）

Sharing the Transaction With Other Validators

4. MP会将 暂存内存中，似乎是废话。。。

5. 通过shared-mempool协议，各个validator交换MP中的交易数据，具体的协议是怎么样的，得后续看源码才能知道。

Proposing the Block

6. 作为当前的leader，Consensus（CO）会主动从MP中拉取可用的交易，会将block复制给其他的validtor。这里没有明确说是P2P还是啥模式进行广播，需要后续看下源码。（MP.3 CO.1）

7. 中的CO负责协调各个validtor，让他们能按照块中的交易顺序来执行。这块是如何协调的，需要看他们的共识。（CO.2）

Executing the Block and Reaching Consensus

8. 出块后，CO会收到这个块，如何将这个块分发给Execution（EX）。这里CO模块似乎有点充当了部分P2P的功能了。（CO.3,EX.1）

9. 这个时候validator只是无脑的接受block，对于block的有效性和合法性都没有检查，如果收到的block被人修改过数据，那么我们怎么知道呢？libra的做法是，先让VM执行下block中的交易，然后将这些结果暂存起来。（EX.2, VM.3）

10. 上一步既然已经执行完了，也拿到了执行后的结果了，那么下一步肯定是要和各个validator进行比较，查看各个执行后的状态是否一致了。当然，libra为了能够快速验证结果，采用了 Merkle accumulator 这个结构，emmm，libra似乎没有说清楚这个结构是什么样的，这里还是推测类似是Merkle tree的结构。EX做法是这样的，会将当前block中执行过的交易加入到Merkle accumulator中，并且将执行后的结果返回给CO模块。（CO.3, EX.1）

11. 原文是下面这个，只是说会尝试和其他在这个共识里的validator达成一致。具体怎么做，估计CO会收集各个validator的结果，然后比较，在大部分一致的情况下，进行签名确认。（CO.3）

V1(the consensus leader) attempts to reach consensus on the block's execution result with other validators participating in the consensus.

Committing the Block

12. 看来上一步的猜测是正确的。如果 的执行结果得到了大部分的validator的确认并签名，那么EX模块就会从之前暂存下来的执行结果写入到storage中，当然也包括过程数据（交易）。(Consensus → Execution CO.4, EX.3), (Execution → Storage EX.4, ST.3)

13. 最后，反映在账户上，Alice查询的自己的账户的时候，其实就是查询storage中自己的state，由于上一步中已经将交易的执行结果写入了storage了，因此此时Alice的账户就只有100 libra了，同时被改变的状态还有Alice的seq。如果此时Bob再将 交易重新发送一次，由于交易的seq小于Alice的seq，那么该交易就会被拒绝了。

OK，交易的生命周期大致就是这样，emmmm，整个流程和ethereum基本上没什么太大的出入，算是复习了一遍。

感觉今天写的有点多了，错过了游泳的时间点，点个快乐肥宅水压压惊。明天回家摘杨梅，希望别下雨吧。