初识libra

libra

资料

• 这是一份用于演示功能的初版代码
• 白皮书
• 文档
• Move语言
• HotStuff
• 共识机制
• Verifiable_Random_Functions
• DKG

是什么？

Libra’s mission is to enable a simple global currency and financial infrastructure that empowers billions of people.

Libra Core implements a decentralized, programmable database which provides a financial infrastructure that can empower billions of people.

• 一个分布式可编程数据库，旨在为数十亿人提供支持的金融基础设施
• 发行稳定的全球性数字货币的联盟链项目
• 以此为技术凭借，将创造一个建立在安全，可扩展且可靠的区块链之上、有一个资产储备，旨在赋予其内在价值、由负责发展生态系统的独立天秤座协会管理的金融体系
• 发布后的五年内将开始从permissioned blockchain过渡到permissionless blockchain

有什么特点？

• 不破坏现有系统和绕过监管，在合规和监管方面进行创新，以提高反洗钱的有效性
• 使用Move语言为智能合约语言（为数字资产而生的智能合约平台型语言，由facebook发布）
• 基于LibraBFT共识协议（基于HotStuff共识协议）的bft机制
• 改进区块链数据结构————默克尔树
• 身份匿名
• 币值稳定，通过低波动性的资产来保证，比如：银行存款和政府证券保证。币值变动取决于外汇波动（安全区、授权经销商）
• 交易即时，安全和低成本

BFT共识

• 基于HotStuff共识协议的变种协议————LibraBFT协议
• 部分同步模型：在满足提交条件提交交易后，诚实验证者之间的所有消息会在最大网络延迟时间内传递到其他诚实验证者
• 目标是支持100个验证者，经过发展需要支持500到1000个验证者
• 每秒达到1000笔交易
• 两个模块：safety (voting and commit rules) and liveness (pacemaker)
• 所有的块签名会到达leader，leader出具仲裁证书，分发给所有的验证者
• 第k个块提交成功的条件：有仲裁证书、第k+1个块和第k+2个块的证明
• 对HotStuff做出的该进：
  • 验证者对结果状态和交易顺序签名而不只是交易顺序
  • 设计了一个pacemaker来发出明确超时或者收到仲裁证书的信息，让所有验证者收到足够的数量后进入下一轮投票进程，而不使用同步时钟
  • 计划设计一种无法预测的leader选举机制，由最近的提交提案的proposer使用一个可验证的随机函数来确定leader
  • 使用聚合签名来保留签署仲裁证书的验证者身份，签署仲裁证书的验证者可以获得激励

加密

• 使用SHA-3哈希算法
• 使用X25519进行密钥交换，用于在验证者之间通信
• 使用Ed25519对共识和交易签名
• 使用HKDF根据盐值、应用信息、种子生成密钥

数据结构

• 交易。包含以下内容：
  • Sender (account address)
  • Transaction script
  • Gas price
  • Maximum gas amount
  • Sequence number
  • Expiration time
• 账本状态
• 账户：包括Move modules、 Move resources（代码和资源数据）
• 默克尔树：交易、状态、事件（结构）
• 使用protobuf编码的grpc通信
• 块是作为批处理的一种结构，不在存储中体现，交易就是区块链上的一个结点，版本就是链的高度

网络方案

• 提供RPC和DirectSend两种对外的接口，DirectSend用于发送后不期待响应的情况
• Multiaddr scheme for peer addressing.
• TCP for reliable transport.
• Noise for authentication and full end-to-end encryption.
• Yamux for multiplexing substreams over a single connection; and
• Push-style gossip for peer discovery.

验证节点

• Admission Control(AC)：验证签名、验证交易，通过向Storage查询账户余额与序列号加上客户端请求发到Mempool；如果是查询请求，访问Storage查询并直接返回；它是验证者的唯一外部接口

• Mempool：保存待执行交易，与其他验证节点共享（只发送自己的交易，不转发来自其他验证者的交易）并接收其他验证节点的交易（需要验证交易）；数据模型是账户地址——>交易的HashMap，其上各种索引；主索引包含有序的交易队列，准备包含在下一个块中

• Consensus：与其他验证节点共同决定一个块是否通过，经过两步共识，一次顺序一次结果；只有proposer/leader才能发起块（从自己的Mempool拉取）

• Execution：暂存Merkle累加器的相关部分的副本，用于计算根哈希值；执行交易中包含的脚本（Execution:ExecuteBlock()），计算根哈希值，维持结果的过渡状态，待执行结果被共识插件通过后存入分布式数据库（Execution::CommitBlock()）并更新暂存器内容

• Storage：存储交易、输出、签名（Storage::SaveTransactions()）；为查询请求提供经过默克尔树验证的响应；使用RocksDB作为物理存储引擎

• VirtualMachine：AC和Mempool验证交易（VM::ValidateTransaction()）、Execution执行交易（VM::ExecuteTransaction()）

账户

• 每个账户就是一个包含了任意模块和资源的容器，存储在状态merkle树中

智能合约

• 在Libra中，智能合约叫做module
• LibraCoin.T只是Move语言中的一个资源，和每个账户定义的资源相比没有特殊的地位
• 交易脚本（不是模块；一次性使用；不可以被调用）通过调用一个或多个模块的过程来实现资源的交互

Move语言

• an executable bytecode language
• 用于实现自定义交易和智能合约、能保证资源不被复制或隐式丢弃（resource types）
• 模块中声明资源类型和过程，编译器会把代码根据模块或者脚本编译成CompiledModule喝CompiledScript两种字节码
• Move IR是Move语言的语法层，目前很简单，对开发人员不友好

问题

1. 如果Mempool中存在同一个账户的多笔交易会怎么处理？即，一笔交易未确认，用户又发起另一笔交易。

   • 基于同一序列号的多个交易根据gas大小排序，决定谁先上链
   • 基于不同序列化号的则会根据序列化号排序，需要特别注意的是，这个排序必须是连续的，不连续的交易无法提交，会等待直至超时

2. 基于pdf如何提高吞吐量？

   • HotStuff协议
   • 基于HotStuff协议改进的Libra协议

3. leader如何选举？

   • 参照HotStuff

4. 有智能合约语言那是否可以发行自己的币？

   • 文档无明确说明，但是从可编程的智能合约和LibraCoin.T只是Move语言中的一个资源可以看出，应该是可以的

5. 当新节点加入时块怎么同步？

6. 如何激励验证者？

7. 具体的对merkle树怎么构造？怎么查找？

8. 是否可以撤回交易？

   • 不可以

9. 监管方面的创新是什么？

   • 文档无读到

10. 如何防止重放攻击？

    • 一个账户唯一的一个64位序列化值来代表该账户的转出次数，如果使用同一个交易提交因为序列化号小于当前账户的序列化号，则会失败

VM：

• Checks that the input signature on the signed transaction is correct (to reject incorrectly signed transactions).
• Checks that the sender's account authentication key is the same as the hash of the public key (corresponding to the private key used to sign the transaction).
• Verifies that the sequence number for the transaction is not less than the current sequence number for the sender's account. Doing this check prevents the replay of the same transaction against the sender's account.
• Verifies that the program in the signed transaction is not malformed, as a malformed program cannot be executed by the VM.
• Verifies that there is sufficient balance in the sender's account to support the max gas amount specified in the transaction, which ensures that the transaction can pay for the resources it uses.

转载于:https://my.oschina.net/u/3628490/blog/3067137