关于Facebook的Libra(目前是联盟链,以后会向公链进行过度)

Libra白皮书

  • Libra的使命: 建立一套简单的、无国界的货币和为数十亿人服务的金融基础设施。

  • 为什么选择使用Blockchain构建该金融基础设施?采用Blockchain还存在哪些问题?
  1. 区块链和加密货币具有许多独特的属性,因而具备解决金融服务可用性和信誉问题的潜力。 这些属性包括: 分布式管理,确保网络不受单一实体控制;开放访问,允许任何能连接互联网的人参与其中;以及安全加密 技术,保护资金安全无虞。
  2. 但是,现有的区块链系统尚未获得广泛采用。 现有区块链缺乏可扩展性,加密货币具有波动性,到目前为止, 这些因素导致现有的加密货币在保值和交换媒介方面均表现欠佳,因而阻碍了它们在市场上的广泛使用。
  3. 另外, 一些项目还试图破坏现有体系并绕过监管,而不是在合规和监管方面进行创新,以提高反洗钱举措的效力。

  • Libra的三个部分,这三个部分共同作用,创造一个更加普惠的金融 体系:
  1. 它建立在安全、可扩展和可靠的区块链基础上;
  2. 它以赋予其内在价值的资产储备为后盾
  3. 由独立的 Libra 协会管理,该协会的任务是促进此金融生态系统的发展。
  • 实现Libra 区块链的软件是开源的,以便所有人都可以在此基础上进行开发;从零开始构建了其所需的区块链,同时优先考虑了可扩展性安全性存储效率和处理量以及对未来的适应性
  • 货币单位被称为Libra
  1. 与大多数加密货币不同,Libra 完全由实物资产储备提供支持。
  2. 对于每个新创建的Libra 加密货币,在 Libra 储备中都有相对应价值的一篮子银行存款和短期政府债券,以此建立人们对其内在价值的信任。
  3. Libra 储备的目的是维持 Libra 加密货币的价值稳定,确保其不会随着时间剧烈波动。
  • Libra协会:
  1. Libra 协会是一个独立的非营利性成员制组织,总部设在瑞士日内瓦。
  2. 协会旨在协调和提供网络与资产储备的管理框架,并牵头进行能够产生社会影响力的资助,为普惠金融提供支持。
  3. 协会的成员系统由运作 Libra 区块链的验证者节点网络构成。
  4. 协会的成员将包括分布在不同地理区域的各种企业、非营利组织、多边组织和学术机构。

  • Libra以许可型区块链起步,以后会过渡成非许可型区块链:
  1. 区块链分为许可型区块链非许可型区块链,这根据实体是否能作为验证者节点接入区块链平台来决定。
  2. 许可型区块链中,实体通过权限授予方式运行验证者节点。在非许可型区块链中,符合技术要求的任何实体都可以运行验证者节点。从这个意义上说,Libra 将以许可型区块链的形式起步
  3. 为了确保 Libra 真正开放,始终以符合用户最佳利益的方式运作,我们的目标是让 Libra 网络成为非许可型网络。
  4. 但挑战在于,我们认为目前还没有成熟的解决方案可以通过非许可型网络,向全球数十亿人提供交易所需的规模、稳定性和安全性。过渡工作将在 Libra 区块链和生态系统公开发布后五年内开始。

  • 构建Libra区块链的三项要求:
  1. 能够扩展到数十亿帐户,这要求区块链具有极高的交易吞吐量和低延迟等特点,并拥有一个高效且高容量 的存储系统。
  2. 高度安全可靠,可保障资金和金融数据的安全。
  3. 足够灵活,可支持 Libra 生态系统的管理以及未来金融服务领域的创新。
  • Libra区块链的三项设计决策:
  1. 设计和使用 Move 编程语言。
  2. 使用拜占庭容错 (BFT) 共识机制。
  3. 采用和迭代改善已广泛采用的区块链数据结构。
  • Move是一种新的编程语言,用于在 Libra 区块链中实现自定义交易逻辑和智能合约
  • Libra 区块链采用基于 LibraBFT 共识协议的 BFT 机制,与其他一些区块链中使用的工作量证明POW)机制相比,这类共识协议还可实现高交易处理量、低延迟和更高能效的共识方法。
  • 不同于以往的区块链都将区块链视为交易区块的集合, Libra 区块链是一种单一的数据结构,可长期记录交易历史和状态。
  • Libra 区块链遵循匿名原则,允许用户持有一个或多个与他们真实身份无关的地址。
Libra官方文档的中文翻译:
https://learnblockchain.cn/docs/libra/docs/welcome-to-libra/

Libra Protocol: Key Concepts

  • 交易和状态:
  1. 在Libra的状态 S n − 1 S_{n-1} Sn1上执行交易 T n T_n Tn,产生新的状态 S n S_n Sn,即 S n = F ( S n − 1 , T n ) S_n=F(S_{n-1},T_n) Sn=F(Sn1,Tn)
  2. F F F是具有确定性的功能,只要在状态 S n − 1 S_{n-1} Sn1时执行交易 T n T_n Tn,产生新的状态 S n S_n Sn总是一致的。

在这里插入图片描述

  • 版本数据库:
  1. Libra区块链中的数据被持久化在单版本的数据库中,版本号是64位无符号整数
  2. 版本号对应对应系统中已执行的交易数,疑问: 为什么版本号对应的是已执行的交易数?需要由具体的示例
  3. 用户查询账本历史时,响应中应该包含当前和之前的版本。
  • Libra的账户: 账户的构成、申请账户需要付费是special feature
  1. Libra账户由Move modulesMove resources构成,前者只包含代码(类型和步骤的定义),后者值包含数据(资源对应的类型在module中定义)。
  2. 一个Libra账户可以包含任意数量的Move modulesMove resources
  3. 账户地址是用户公钥的加密哈希,是一个256 bit的值。
  4. 用户以该账户发起交易时,必须使用账户地址对应的私钥对交易进行签名。
  5. 每个Libra用户可以拥有任意数量的账户,但是申请账户时,该交易必须由一个有足够Libra币以支付账户创建费的账户发起。
  • 区块链的结构: 使用Merkle Tree表示区块链是special feature
  1. 使用日益增长的Merkle交易树表示区块链,区块链中的交易被执行,一片叶子就被添加到树中,
  2. 与其他Merkle树一样,账本历史为特定交易对象的证明可以提供时间复杂度为 O ( l o g n ) O(log^n) O(logn)的效率,其中 n n n是已执行交易的总数。
  • Validator Node(Validator): validator身兼peer和orderer的功能、validator中Admission Control组件是special feature
  1. validator运行共识协议(与其他validator一起)、执行交易、在区块链中存储交易和交易的执行结果。
  2. validator决定什么交易将被加入区块链以及以何种顺序加入区块链。
  3. 一个validator应该包含Admission ControlMempoolConsensusExecutionVMStorage组件。
  4. 其中Admission Control是一个相对较新的概念,每个组件的具体功能见 Validator Node (Validator)

Life of a Transaction

  • Alice向validator提交一个交易: 从Alice的账户向Bob的账户转10 LBR
  1. 未使用client私钥签名的交易叫做原始交易(raw transaction),签名后才能将其提交给validator
  2. 签名后的交易包含:原始交易、Alice的公钥、Alice的签名。

1. 该交易叫做 T 5 T_5 T5,序号5表示已经从Alice的账户发送了5个交易了。
2. 序号就像一个打单调递增的计数器,表示从当前账户向validator发送了多少个交易。只有当交易正确执行,计数器才会加一?
3. 交易中的Sequence number就是Alice账户中的序号,可以防止其他用户重放交易。因为,此时Alice账户中的序号已经变为6。


交易的生命周期

  • 箭头不代表数据的流向,箭头起点表示交互或操作源于某个组件,终点表示操作被执行的组件。
  • 接收交易:
  1. client将交易 T 5 T_5 T5提交给validator V 1 V_1 V1 V 1 V_1 V1的AC组件接收该交易。
  2. AC使用VM组件对交易进行验证检查,比如签名验证、检查Alice的账户是否有足够的余额、检查交易 T 5 T_5 T5是否被重放等。
  3. 交易 T 5 T_5 T5通过了验证检查,AC将交易 T 5 T_5 T5发送到 V 1 V_1 V1mempool组件。
  • 与其他validator分享交易:
  1. mempool将交易 T 5 T_5 T5保存在内存缓存中,此时mempool可能已经包含了来自Alice地址的多个交易。
  2. 使用shared-mempool协议, V 1 V_1 V1将和其他validator分享自己内存池中的交易,并从其他validator中接收交易放到自己的内存池中。
  • 提议交一个块:
  1. 假设 V 1 V_1 V1proposer/leader,它将内存池中的交易打包成块(包含交易 T 5 T_5 T5),通过它的共识组件将块作为提案复制给其他validator。
  2. V 1 V_1 V1的共识组件负责就已提议块的交易顺序,在所有的validator中达成一致。
  • 执行块并达成共识:
  1. 作为达成协议的一部分,交易块(包含交易 T 5 T_5 T5)被传递给执行组件。
  2. 执行组件负责在VM中执行交易,注意: 此执行是在区块中的交易达成一致之前进行的推测性执行

最后的一致是对交易顺序和执行结果都要达成一致,作为其中一部分可以先执行。

  1. 块中交易被执行后,执行组件将块中交易添加到Merkle accumulator中。这是一个在内存中的、暂时的Merkle accumulator版本,没有真正更改账本! 执行这些交易的proposedspeculative结果被返回给共识组件。

步骤10的箭头从共识组件指向执行组件,表明执行交易的请求是由共识组件发起的。

  1. V 1 V_1 V1试图和其他参与共识的validator就block的执行结果打成一致。
  • 提交块:
  1. 如果块的执行结果由一组具有超过多数票数的validator达成一致后并签名了,则 V 1 V_1 V1的执行组件从缓存的推测执行中读取块的执行结果,并将块中所有交易提交至持久存储中。
  2. Alice的账户余额变为100 LBR,账户的序号将变为6。如果交易 T 5 T_5 T5被Bob重放,该交易将会被拒绝。因为Alice账户的序号6比重放交易的序号5更大。

  • AC是validator唯一的外部接口,client向validator发送的任何请求需要先转给AC。
  • 只有当 T n T_n Tn的序列号大于或等于发送者帐户的当前序列号时,内存池才会接受来自AC的交易 T n T_n Tn注意: 除非交易序号是下一个序列号,否则交易无法达成共识)

The Libra Blockchain

① Introduction
  • 重点信息:
  1. Libra协议的概述:client和validator两种实体的介绍,Libra协议的工作流程
    在这里插入图片描述
  2. client可以向validator发起查询,也可以从validator处同步完整的交易历史以创建区块链数据库副本,cleint之间可以分享副本。
② 逻辑数据模型
  • 版本数据库: 数据库中的元组 ( T i , O i , S i ) (T_i, O_i, S_i) (Ti,Oi,Si),确定性执行函数 A p p l y ( S i − 1 , T i ) → ( O i , S i ) Apply(S_{i-1}, T_i) \rightarrow (O_i, S_i) Apply(Si1,Ti)(Oi,Si)
  • 账本状态:
  1. 账户地址:用户公钥的散列、create_account(a)指令、更改私钥而不改变地址、账户的匿名性
  2. 资源:将命名字段绑定到简单值的记,资源类型在module中定义、资源标识符0x56.Currency.T的可预测性、包裹的资源TwoCoin { c1: 0x56.Currency.T, c2: 0x56.Currency.T })、不可通过其他module修改资源。
  3. 模块:定义了资源类型和程序的Move字节码,模块标识符0x56.Currency、同一个账户中模块不可重名、模块不可变(今后打算支持模块更新)。
  • 交易:
  1. 交易包含交易脚本和交易脚本的参数,只有当对交易输出有约束力的承诺达成一致时,账本状态才能被更改。
  2. 交易输出:对交易执行状态码、gas使用量、事件列表的整合
  3. 事件(event):执行交易产生的一组副作用。

1. 一旦按照共识协议提交了交易,交易生成的事件将添加到商定的账本历史中,并提供成功执行交易产生特定影响的证据。
2. 在交易可能失败的系统中,事件不仅能证明特定交易是否已被执行,还能证明交易是否以预期的效果成功完成。
3. 交易只能产生event,不能读取event,使得交易执行是基于当前状态的一个功能。

  • 账本历史:
  1. 账本历史存储了一系列的已提交和执行的交易,同时包含交易产生的event。
  2. 在账本历史中没有交易块的概念,因为在逻辑数据模型中,交易顺序执行而不需要区分哪个块包含每个交易
  3. 执行新交易不需要知道账本历史,client可以通过账本历史审计交易的执行。
  4. 账本历史的用途:① 响应用户查询;② 审计交易执行
③ 交易
  • 向用户开放一部分Move功能好处:
  1. 这种方式可以使Move语言和工具链在暴露给用户之前成熟,这是从实现核心系统组件的经验得来;
  2. 这种方式也推迟了通用智能合约平台固有的在交易执行和数据存储上的可扩展性挑战。
  • 执行要求:
  1. genesis state必须对核心组件有足够的实例化,以保证交易可以被处理。
  2. genesis state由特殊交易T0创建,这个状态不能通过共识,只能通过配置添加到账本中。client和validator只能接受以特殊交易T0开始的账本历史。
  3. 确定性: 交易的输出在给定交易信息和当前账本转态下是可预测的;密封性: 交易执行不会有外部效果(如打印终端、与网络通信)。
  4. 可测量: 为了管理对计算能力的需求,交易需要收取费用,费用的多少由油价和油耗决定。收取交易费的原因: 在系统负载高于系统所提供承载能力时减少需求
  5. 资产语义: 资产不重复、丢失、无授权的转移
对Facebook Libra的总结
类型 多通道 智能合约 共识协议 内置货币 国密 性能
目前为联盟链,会过渡成公链 Move,可执行的字节码语言 BFT共识,基于HotStuffLibraBFT Libra coin 不支持 10s内,1000TPS

官方文档:https://developers.libra.org/docs/welcome-to-libra
官方文档的中文翻译:https://learnblockchain.cn/docs/libra/docs/welcome-to-libra/
白皮书:https://libra.org/zh-CN/white-paper/
Libra区块链paper中文翻译:Facebook Libra区块链技术白皮书(中文版)
关于Libra的智能合约:Libra深度剖析:智能合约并非生而平等

猜你喜欢

转载自blog.csdn.net/u014454538/article/details/103702728