libra技术初窥

这两天Facebook出了一个libra，作为码农自然比较好奇这是个什么技术，是如何实现的。因为时间仓促，这篇暂时按照libra官网的资料来简要介绍libra的整体逻辑（并不是严格的翻译，加了自己一些不成熟的理解），后续文章将分别分析其中的各个子模块。

Libra Protocol: Key Concepts · Libra​developers.libra.org

在看完官网的介绍后，给我一个感觉就是，这味道像极了ethereum。

基本概念

与ethereum这种公链不同的是，libra是一个联盟链，联盟链与公链的最大区别在于，加入联盟链是有个准入的，公链则可以随意的退出加入。因此，表象上，联盟链的节点会比公链少很多，同时由于有了准入的过程，联盟链的节点相对稳定，而且在共识也会做出一定的妥协。

OK，接下来简单介绍libra的一些基本概念。

Transactions and States

交易和状态是libra中两个非常重要的概念，什么是state？因为libra可以理解为是一个分布式账本，状态就是账本中某人有多少余额，当然由于libra还加入了Move虚拟机，也就是说可以支持智能合约，自然状态也会包括某个用户在某个合约（这个是按照eth的说法来解释）中的数据状态。简而言之，state就是一个结果值。既然state是一个结果值，那么如何得到这个结果，或者说流水账是什么，transaction其实就是这个流水账。这里套用官网的图例来解释。

上面这个图很好的介绍了（这里不得不说Facebook的文档写的相当好，图例还有关键过程都解释的非常棒，相比之下，eos还有币圈一大堆链简直就是一窝屎=。=） 表示区块链第N个状态，其实这里的N可以理解为交易数，也就是说一个交易对应一个状态，这是因为state的更改是通过执行transaction来触发的。

我们假设 这个状态下A账户有110块，B账户有52块，这个有一笔交易 表示从A账户转10块给B，那么在执行完这笔交易后，状态就从 变成了 。这里需要注意一点，由于这笔交易会被所有的验证节点（validator）执行，如果这里执行过程不是确定性的，那么就存在不同的验证节点最终执行的结果不一样，从而导致状态 不一致，那么就没法共识了。所以这里的执行器F必定是一个确定性的，即在相同的状态下，给定同样的参数，和执行逻辑，结果必然是相等的。

下面我们介绍下Transaction中的关键字段。这块和ethereum简直一模一样。

• Sender address 就是发送这笔交易的用户的地址
• Sender public key 发送交易需要发送者利用私钥对这笔交易进行签名，这里的public key就是签名所用的私钥对应的公钥了。一般来说，如果libra账户地址是由某个私钥对应的公钥生成的话，这里不应该再增加这么一个字段。因为验证的时候，可以通过签名还原出公钥，从而获得地址，从而来验证是否和这个sender address一致。既然libra还增加了这么一个字段，那么libra的账户体系有可能类似eos这种，一个账户下可以挂多个权限的公钥，只是猜测。
• Program 这个可以理解为是ethereum上的智能合约，只不过libra是用Move语言实现的，比较好奇会有哪些特性，后续会好好研究下。
• Maximum gas amount 因为libra支持program，通俗的说你可以写一段代码丢给libra，让他替你执行。如果你在里面写个while（true）循环，那libra岂不是一直执行你的代码了，所以为了防止这种恶意代码，每个交易都会设定一个gas最大值。这个表示，当你这个交易被VM执行的时候，最多可以消耗这么多Gas，通过gas来防止恶意代码。
• Gas price 上面说了，每个交易执行都会消耗gas，那么当有很多交易的时候，validator出块会有个优先级，他的优先级就是gas price，这个意思gas的单价，比如说你一个交易在VM执行需要消耗20Gas，然后你的Gas price是0.001 libra，那么你为了执行这个交易会付出0.02 libra。
• Sequence number 这个和ethereum的nonce一样。主要是用于防止双花的，他的原理是这样的，每个账户初始的seq是0，接下来这个账户每次发送一笔交易都需要带上这个seq，这个seq是严格自增的，seq可以理解为该账户成功发送交易的笔数。比如说，A账户的seq是10，那么如果此时他发送了一笔交易，这个交易的seq只能是10才会被validator采纳，如果是大于10的，也会被validtor采纳，但是只会加入到mempool中，并不会被打包。那么他是如何防止双花的呢，比如A同时构造了两笔一模一样的交易并且seq都是10，那么validtor在收到其中一笔交易后，就会对其账户的seq自增（这个过程还没写到storage，只是在内存中），当该validtor收到另外一笔seq=10的交易后自然就拒绝了，这样就防止了双花。
• Expiration time 这个是过期时间，ethereum是没有的，不过btc有。很好理解，比如说你有一笔交易，设置的过期时间是10 min，由于这个交易的gas price比较低，所以大家都不愿意打包他，如果超过10 min还没有被打包，那么这笔交易就被作废了。
• Signature 签名，很好理解，用于证明是你发送的，而且通过这个来判断原文是否被篡改。

Versioned Database

整个区块链其实就是个带版本的分布式数据库，这里的版本号就是交易数，数据库存了状态值，而触发状态变更的是交易，所以交易数就是版本号，很好理解。

Account

libra的账户结构基本和ethereum的差不多，除了包含基本的余额和seq信息外，还包含了Move modules， Move resources。

• Move modules 其实可以类比ethereum的中用户的code域，大致可以理解为是代码段。比如说某个用户上传了一段script，那么这段script就会被加载到Move modules中。
• Move resources 就是数据段，不多解释了。
• Account Address libra的地址是64字节的，是用户user的验证公钥的hash，原话如下。考虑到libra不会是匿名的，最多也是台前匿名，台后实名，同时结合transaction中多了一个public key字段，我们可以推测出，用户需要申请libra user，一旦你申请到了一个libra user，你可以创建任意多个account address。当然，这个只是猜测，具体要后面细看。

The account address is a cryptographic hash of a user’s public verification key.

Proof

上面说了，libra可以看做是带版本号的分布式数据库，这个数据库会存储区块数据（包含了交易）以及执行交易后的结果（状态值），但是我们知道libra中是会存在作恶节点的，也就是说没法完全信任其他节点传过来的数据，那么这个就要求libra需要证明数据是可信的。在libra中主要依赖 Merkle tree，这棵树会随着交易的增加而不断增长。在ethereum中，其实是通过MPT，通过字典树作为查询索引，不知道libra中是如何做查询的。可能要到后续看源码的时候才能知道答案。

Validator Node

libra是联盟链，所以对节点有个准入的过程，一旦被准入了，那么这个节点就将成为Validator。validtor一般的套路就是，根据共识确定出块顺序，以及验证块。所以，validtor的职责一般会有：1. 出块。2. 验证。3. 与client交互。具体的需要结合libra的共识算法才能确定。对了，libra的共识是基于hotstuff，这篇paper是上交的学生写的，现在在Cornell读博，牛逼牛逼。

HotStuff: BFT Consensus in the Lens of Blockchain​arxiv.org

那么对于一个validator节点来说，主要有以下模块

下面一个个介绍：

Client

就是客户端，比如钱包或者集成了libra功能的app，负责生成交易，签名，发送交易给validator。

Admission Control (AC)

AC是validator中唯一一个暴露给外部的模块，client的所有请求会先经过AC。这里有个题外话，不知道validator是如何暴露给client的，是否存在validator被DDoS或者其他攻击的可能？EOS这块似乎做的比较好。

AC主要的目的就是将一些无效的请求拦截掉。具体的做法么，会先请求VM::ValidateTransaction()来验证交易的合法性和有效性，如果OK的话，会将其加入到mempool中。具体在下一篇文章会解释。

Mempool

这个是用来暂存待出块的交易，当client的交易或者其他validator的交易被AC过了后，就会存到这里，等出块。

When a new transaction is added to a validator node’s mempool, this validator node’s mempool shares this transaction with the mempools of other validators in the system.

这里描述的似乎mempool是一个共享的，我的理解应该不是共享内存那种方式，应该还是通过P2P协议进行共享，否则不安全，具体得再往下看看。

Consensus

当交易被存到mempool后，那么consensus就可以用来确定哪个validator出块了，以及如何让各个validator对于block执行后的结果达成一致。具体后面会结合hotstuff进行分析。

Execution

当出块后，出块节点和其他validator会接受区块，这个时候就会由执行模块执行交易，他使用VM来执行交易，需要注意的是，这个只是一个中间状态，所有的结果都是在memory中的，只有达成共识后才会写到数据库中。

Virtual Machine

主要功能就是执行交易，AC和Execution模块会调用他。需要注意的是，VM是确定性的，不能存在随机性。

Storage

当Execution执行完block中的交易后，并且达成一致后，会将Execution中存储在memory的结果写入到storage中，这里主要包括过程性数据（transaction）和结果（state）

OK，基本概念介绍完了，下一篇介绍下libra中transaction的生命周期，以及各个模块的交互过程。

二狗二狗我是二狗：libra-交易的生命周期​zhuanlan.zhihu.com