libra-交易的生命周期

最新推荐文章于 2024-07-08 09:00:00 发布

原创最新推荐文章于 2024-07-08 09:00:00 发布 · 212 阅读

CC 4.0 BY-SA版权

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

Life of a Transaction · Libradevelopers.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可以大致理解为是对普通交易的序列化后的交易。

我们用 $T_{5Raw}$ 来表示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， $V_{1}-V_{100}$
Client将这笔交易 $T_{5}$ 发送给 $V_{1}$
$V_{1}$ 在这一轮共识中是leader，也就是说负责出块

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

Lifecycle of the Transaction

我们先用libra的官网的图

这里的数字表示交易 $T_{5}$ 在各个模块的流转过程。我们大致可以将生命周期分成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

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

Sharing the Transaction With Other Validators

4. MP会将 $T_{5}$ 暂存内存中，似乎是废话。。。

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

Proposing the Block

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

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

Executing the Block and Reaching Consensus

8. $V_{1}$ 出块后，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. 看来上一步的猜测是正确的。如果 $V_{1}$ 的执行结果得到了大部分的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再将 $T_{5}$ 交易重新发送一次，由于交易的seq小于Alice的seq，那么该交易就会被拒绝了。

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

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