Libra区块链论文解析

本文由陈智罡博士撰写

摘要中的第一句话就表明了facebook做Libra区块链的目的(做什么):

建立一个能够支持稳定加密货币的区块链,从而为全世界人民提供便捷的电子支付

论文中特别强调该区块链是一个去中心化的可编程数据库。体现了Facebook满满的诚意,就是要落地应用。换成其它公司,哪敢称自己的区块链是数据库。在区块链界是存在鄙视链的,公有链鄙视联盟链,联盟链鄙视私有链,私有链只好看着数据库笑笑。

所以整个Libra技术论文紧紧围绕建立一个电子支付的区块链平台展开。

如何做呢?

为了建立该电子支付区块链平台,提出了Libra协议。该协议的目标是促进创新,降低进入门槛,改善金融服务。所以在Libra协议里,不仅包含技术,还有社区管理、生态建设等。

为了测试Libra协议,目前开发实现了一个协议原型:Libra核。“核(core)”在这里的含义是开发出了一个区块链大厦的地基,期望全世界都参与到Libra协议建设中,为其改进提高做出共同努力。

Libra协议具体功能是什么?

摘要第2段指出:Libra协议允许系统中的验证者(即记账者)共同维护这个具有可编程资源的数据库,而这些验证者们是来自于不同参与方的代表。这里有一个新名词:可编程资源。该资源由用户账户所拥有,并且遵守资源开发者所制定的规则。

具体的资源可以是币,或者其它具有可编程特性的东西。例如还可以是债券等。

验证者处理交易并且与其它验证者共同执行协议,以达到对数据库状态的共识,即账本的一致性。交易是基于系统中已经定义好的规则,在将来版本中,用户通过使用Move编程语言可以自定义智能合约来处理交易。这里引出了Libra区块链中另外一个重要的特征,就是内置了用于交易场景的编程语言Move。但是目前该编程语言还未完全成熟,没有发布正式版本。

Libra区块链中的核心机制都是通过Move定义,例如币,验证成员。这些核心机制有助于建立一种独特的治理机制,目前这种机制是建立在现有参与方的稳定性和声誉的基础上,但随着时间的推移将过渡到完全开放的系统。

以上就是摘要的全部内容。通过读论文中的摘要,可以领会论文的概貌,例如:目的,做什么,怎么做,效果。

从我们对论文摘要的解析,可以体会到Libra区块链的目的很明确,就是要建立一个全世界通用的区块链支付系统。该系统的核心是Libra协议,该协议是Libra区块链的基石。针对的对象是维护一个可编程资源的数据库。

目前Libra区块链只实现了Libra协议的原型,更多的开发留待更多的参与者共同开发。Libra协议的核心机制都是通过Move编程语言定义的,所以具有灵活性、可扩展性。但是目前为了落地与测试,用户还不能自定义规则。从摘要就能看到,Libra区块链是一个联盟链,记账者(论文中称为验证者)都是Libra区块链的参与方代表,是一个封闭的圈子。当然愿景是未来逐步开放到所有持有Libra币的参与者。

宁波格密链网络科技有限公司已经开展对Libra协议的研究与扩展,欢迎广大技术人员参与,共同推动区块链支付技术的发展与繁荣。

 

如果说摘要是对整个论文描述的一个浓缩,引言就是对论文的一个概览。横看成岭侧成峰,远近高低各不同,引言会进一步介绍论文的出发点,技术轮廓,创新点以及挑战。所以,引言一定要写好,读者或者审稿人能够通过引言对论文打出印象分,这个分数直接影响了该论文的前途。

读Libra技术论文的引言,就能够对它整个技术框架,创新点,性能等有个了解。对于一般非技术人员,读完引言就可以理解Libra区块链的特性了。

引言第1段就引出Libra区块链想解决的问题

尽管互联网极大的促进了金融服务业的发展,但是对于那些最需要金融服务的人来说,获得金融服务仍然是有限的——受成本、可靠性和跨境汇款能力的影响。

为解决上述问题,论文提出了Libra协议。该协议支持Libra生态系统,旨在解决这些挑战,扩大资本准入,并作为创新性金融服务的平台。

为了实现上述宏观目标,这个生态系统中提供了一种全新的全球货币——Libra币。那么和现实中的货币有什么关系呢?

Libra币是与一些不同国家信誉良好的央行存款和国债绑定的,而且这些货币都经历了相对较低的波动,因此Libra币天生继承了这一稳定性,以及地理上来自不同地方的资产组合的优势。

这里指出Libra币的国际性,与一些央行都挂钩,凸显了Libra币的信用。

为了发展成为全球金融基础设施,Libra协议必须能够满足大规模的交易量。除此之外,还提供实现其经济和管理政策的灵活性。

交易规模是目前区块链技术的痛,这里论文里强调需要解决该问题。不禁让人想看看是如何解决的。

Libra协议从一开始就从整体设计上解决这些需求,并建立在前人的项目和研究基础之上,结合了目前一些新颖的方法和成熟的技术。

注意,新颖和成熟是并列的,前者说明了创新,后者说明了落地应用。

读到这里,是不是感觉很像比特币的技术路线,都是采用前人已有的技术,然后进行改造,为我使用。一切围绕着落地应用为目标。

金融服务业健康竞争和创新的一个重要前提是能够依赖共同的基础设施处理交易、维持账户,以确保不同服务和组织之间能够沟通合作。这句话很关键,说出了需要为多方合作提供一个公共平台的必要性,显然该平台应该是开放、公平以及有良好信用保证的。

为了提供上述平台,Libra协议使用区块链技术,利用区块链的去中心化特性,不受某一方控制,通过降低进入壁垒和成本,使得初创企业和现有企业能够在公平竞争的环境中竞争,并尝试新的业务模式和金融应用。

上面层层递进,从宏观金融问题,引入到区块链平台。下面将说到Libra区块链中的各个角色。

提醒一下,我们解读的是Libra技术论文,而不是Libra的介绍。整个技术论文分为10部分:

1 Introduction–引言

2 Logical Data Model–逻辑数据模型

3 Executing Transactions–交易的执行

4 Authenticated Data Structures and Storage–可认证的数据结构和存储

5 Byzantine Fault Tolerant Consensus–拜占庭容错共识

6 Networking–网络

7 Libra Core Implementation– Libra 内核实现

8 Performance–性能

9 Implementing Libra Ecosystem Policies with Move–使用Move实现Libra生态系统规则

10 What’s Next for Libra?– Libra发展规划

 

引言的上一部分(引言1)讲了Libra的商业应用以及宏观目标。下面分别从项目的管理和技术方面,具体说说Libra区块链。

Libra区块链的管理

Libra区块链是去中心化的,由一些称为“验证者”的角色共同处理交易和维护区块链的账本状态。这些验证者们构成了Libra联盟成员,他们提供网络治理和Libra币的储备。

初始阶段,Libra联盟由来自不同区域的基金会会员组成。基金会会员是按照一定的标准选出,会员包括那些促使Libra生态系统发展以及注入资本的股东。以后,会员资格将逐步完全开放,Libra币持有者都可以进入。

Libra联盟已经发布了一些报告,包括发展规划愿景,管理结构,币的生态,以及朝着公链发展的路线图。

这篇技术论文是为了建立Libra区块链技术框架所迈出的第一步。发布这些早期的报告是为了对整个设计方案、发展计划以及研究方面为解决问题的挑战,征求社区的意见和反馈。为此,Libra建立了社区,以便大家参与讨论,共谋发展。下面具体说技术。

Libra协议

论文直接指出:Libra区块链是一个基于密码学认证的数据库,是通过Libra协议支持其运行。

数据库?那么区块链的账本又在哪里呢?

紧接着论文说:该数据库存储一个可编程资源的账本。可编程资源是什么东东。例如可编程资源可以是Libra币,当然也可以是其它的资源,例如债券等。资源是遵守由声明模块所制定的规则,也是存储在数据库中。

一个资源属于某个账户所有,该账户是由公钥所认证。一个账户直接代表系统的终端用户,或者某个实体,例如钱包,账户的行为代表着用户。

Libra区块链中有了两个核心角色:验证者和客户。读者要牢牢记住,Libra是一个区块链支付系统,所以一切都是以交易为中心。由于是去中心化的,所以达成共识是技术关键。

验证者的职责是维护数据库,将客户提交的交易存入数据库,然后更新数据库的状态。验证者是通过执行分布式共识算法,以达成对提交到数据库中的交易以及执行交易结果的共识。这些交易在数据库中形成一个不断增长的交易列表。

共识协议必须具有可靠性,能够抵御来自少数验证者可能的恶意行为。验证者轮流对已提交到数据库的交易进行处理。

在验证者中有一个“验证者头目”的角色,该验证者头目负责将收到的交易分发给其它验证者,这些交易可能来自于客户直接提交给验证者头目的交易,或者来自于其它验证者提交给头目的交易。

所有验证者执行头目发给自己的交易,并且形成一个可认证的数据结构,该结构包含了账本的最新状态。为了达成共识,验证者对数据结构的验证进行投票。

为了确认处于数据库状态第i版本的交易Ti,共识协议输出对第i版本下数据库整个状态的签名,包括数据库的全部历史。该签名用于响应来自客户的查询。

客户能够向验证者提出读取数据库中数据的查询,由于数据库是基于密码技术认证的,所以必须对能够保证对客户查询提供准确的响应。为此,当客户向验证者提出查询数据库时,该验证者返回他所知道的目前数据库最新状态版本认证的签名。这样就把时间和数据联系起来,已保持数据库状态的一致性。

此外,客户也可以通过验证者同步整个数据库,建立一个数据库的副本。客户通过数据库的副本能够校验验证者执行交易的正确性。这提供了系统的可审计性和透明性。客户端也可以从其他客户端中读取其保存的数据库副本。

图1显示了使用Libra协议进行交互的两种实体类型:(1)验证者(维护数据库)和(2)客户(对数据库执行查询并提交交易来更新数据库)。

图1:Libra协议的概述

至此,Libra区块链协议的轮廓介绍完了。为了大家更清楚,我们通过一个例子来说明。

例如,客户端A想要向客户端B转1个Libra币,那么客户端A就向Libra区块链提交一个交易。区块链平台收到交易,可能是验证者头目收到,也可能是其它验证者收到,无论谁收到交易都要提交给验证者头目。然后验证者头目再将交易分发给其它验证者去验证。验证者收到头目发来的交易后,执行交易并且对其验证,形成一个可认证的数据结构。注意这里我们所说的认证,就是指通过密码学手段达到的。然后验证者们对该认证进行投票。最后共识算法输出对整个数据库状态的一个签名,从而对该交易入库进行确认。

引言就此解析完毕,论文下面就是对各个方面进行详细描述。

读完引言,似乎感觉整个论文缺少技术创新点。在论文中也确实说是系统由已经存在的技术组成。所以在引言中看不到对创新点的描述。

不过通过摘要以及引言看出,Libra不在于技术创新,而在于系统落地应用的商业模式的创新。

 

在比特币里面有个很重要的概念:时间戳。通过时间戳把交易与时间绑定,时间戳还控制着整个比特币系统运行的节奏。我们在解读比特币白皮书的文章里(解析比特币白皮书之时间戳服务)详细解释了其背后的含义。

Libra区块链是一个数据库,如何把数据与时间进行挂钩,交易与时间的关系,以及历史交易如何查询(也是一个与时间有关的问题),这些都属于数据逻辑模型需要阐述的。

Libra区块链中的所有数据都对应于数据库的某一个版本号,数据库的版本号表明了该数据库在某一段时间的状态。所以在描述Libra区块链中的交易时,必须指明是在哪一个版本状态下进行的。

一个版本号是一个无符号64位整数,与系统执行的交易数量相对应。

所以在Libra区块链中,通过一个三元组(TiOiSi) 来刻画交易的状态。其中Ti 表示当前的交易,Oi表示交易执行的结果,Si 表示账本状态。通过这三个元素刻画了交易的状态。例如对执行某个交易的操作Apply,可以用三元组来刻画,即在账本状态Si-1下执行交易Ti ,执行的结果为Oi ,新的账本状态是Si 。形式化表示为:

Libra协议通过Move语言实现区块链支付系统中对操作的执行。本节主要关注带有版本号的数据库。通过版本号控制的数据库允许验证者完成以下操作:

1. 在最新版本的账本下,执行某个交易

2. 对客户查询当前以及历史账本记录做出响应

问题来了,能够反映某个版本下的账本数据结构应该是什么样的呢?为什么要让账本的历史数据都是可查的呢?

首先从账本状态说起。

账本状态

账本状态根本上反映了Libra系统的客观状态。例如在某个时间某个用户持有多少Libra 币(当然这里时间是通过版本号来反映的)。而且为了执行交易,验证者必须知道目前账本的状态。

所以账本状态是执行操作依赖的基础,也是反映Libra系统的状态晴雨表。

Libra协议采用的是基于账户的模型。这是与比特币不同的地方,比特币采用的UTXO模型可以参考我们的比特币白皮书解析文章(解析比特币白皮书之交易)。

账本状态通过“键值对”存储在数据库中。学过数据库的人对“键值对”的概念不陌生。键值对将账户地址(key)映射到账户值(value)。账户值是由已发布的Move资源和模块构成,其中Move资源存储的是数据值,而模块存储的是代码。账户的初始状态是由创世块赋值。

下面解释账户地址。

账户地址

账户地址是一个长度为256位的值。为了建立一个账户,首先需要用户生成一个公钥私钥对(vk, sk),公钥 vk用于验证,私钥sk 用于签名。通过对公钥vk计算哈希值后产生一个账户地址a = H(vk)。

当某个账户将一笔交易发送给某个用户时,将调用create_account(a) Move指令产生一个账户,该新账户与这个用户对应。这种情况一般是发生在交易产生时,目标地址a还没有账户的情况下。

注意有了地址,还需要创建与之对应的账户

一旦账户建立后,用户就可以使用该账户下的私钥sk 对交易签名。有时为了防止密钥可能被攻击的危险,可以采用密钥替换机制,每隔一段时间采用新密钥,终止原密钥的使用。当然使用新密钥意味着需要建立新的账户地址。所以一个用户可以有多个账户。

Libra协议允许一个用户建立多个账户,而且不会把账户与现实世界的身份对应起来。属于统一用户的账户之间没有关联关系。因此Libra协议提供了一种伪匿名的特性,与比特币和以太坊类似。

资源

资源也称为资源值,是一条将字段名与数值绑定的记录,该数值可以是整数,也可以是复数,甚至可以是嵌入到资源内部的资源。

每个资源都属于一种类型,该类型由模块所定义。资源的类型由资源名称、资源所在模块的名字与地址构成。例如在图2中,Currency.T资源类型是0x56.Currency.T,其中0x56 是Currency模块所在的地址,Currency是模块的名字,Currency.T是资源的名字。

图2:一个包含四个帐户的账本状态示例。在这个图中,椭圆表示资源,矩形表示模块。从资源到模块的有向边意味着该模块声明了资源的类型。地址0x12的帐户包含一种Currency.T资源,该资源由Currency模块所定义。Currency模块的代码存储在地址0x56。在地址0x34的帐户包含Currency.T资源和StateChannel.T资源,这两个资源都是由存储在地址0x78的模块所定义。

如何找到某个资源呢?

例如在账户0x12下,为了检索到0x56.Currency.T资源,客户端通过如下地址提出请求:

0x12/resources/0x56.Currency.T

这样设计的目的使得每个账户使用相同的路径存储0x56.Currency.T资源,让模块为账户值定义一个使用上方便,而且是可提前预知的使用方法。因此对于每个类型,每个账户至多存储一个资源。但是这个限制并不是一个硬性条件,程序员可以自定义一个封装资源,例如resource TwoCoin { c1: 0x56.Currency.T, c2: 0x56.Currency.T }。

资源的建立以及资源类型的定义都是在模块中进行,对于建立好的资源进行转换、删除以及发布的这些规则都被编码在模块里。Move的安全和校验规则阻止了其它代码对资源的修改。

模块

模块也称为模块值,它包含由Move对资源类型和过程的字节编码。如何标识模块呢?是通过在该模块中的账户地址来标识模块。例如图2中,Currency模块被标识为0x56.Currency,其中0x56是账户的地址。

模块在一个账户中的命名是唯一的,即每个名字只能被每个账户使用一次用于定义一个模块。例如0x56账户不能再将其它模块命名为Currency,但是其它账户,例如0x34,可以给属于它的模块命名为Currency,例如命名为0x34.Currency。注意,0x56.Currency.T 和 0x34.Currency.T属于不同的类型,不能混淆使用。

目前版本的Libra协议不允许对模块修改,即模块具有不可篡改性。一旦一个模块在账户中被创建,就不允许对其修改、删除,除非进行分叉。

对模块进行安全更新是Libra协议将来扩展的功能,目前正处于研究中,也算是一个挑战。

交易

Libra区块链的客户提交一个交易后,账本的状态将会被更新。这和现在的银行是一个道理,产生一笔交易后,我们的账户的余额会发生变化。

总体上来说,一个交易是由交易脚本和输入该脚本的参数构成,其中脚本是通过Move字节编码写成,参数可以是接收账户的地址或是发送Libra币的数量。

交易的执行是通过验证者运行脚本程序来实现的,脚本参数和账本状态作为程序的输入,产生一个完全确定的输出结果。

交易发生后,账本状态就被更新了吗?不是的,就像比特币系统中,交易经过6个块的确认后账本才被更新确认。在Libra区块链中,经过共识算法对交易输出结果达成一致确认后,将确认与交易结果绑定,账本状态才被更新。交易的结构与执行将在第3节详细讨论。

交易输出

执行一个交易Ti会产生一个新的账本状态Si 以及执行状态代码、gas使用量、事件列表,这些内容都集中放到输出Oi 中。执行状态代码记录了执行交易的结果,例如执行成功、因某个错误退出、gas使用量耗尽等。gas使用量记录了执行交易所使用的gas数量,具体细节看3.1节。事件是什么呢?

事件列表

事件列表是在执行交易过程中产生的“副产品”,类似于以太坊中日志和事件的概念,但是使用目的完全不同。

Move代码通过事件结构体触发事件。每个事件与唯一一个公钥关联,该公钥通过已触发的事件及其支付金额来标识事件结构体,从而提供事件的详细信息。

一旦交易被共识协议所确认,由该交易产生的事件就被记录在账本历史中,为交易成功执行所产生的结果提供证明。例如,某个支付交易触发了一个事件,允许接收者对支付到账的确认以及支付金额的确认。

乍一看,事件概念似乎是多余的,客户可以通过查询交易是否已经存储在区块链中,来代替对该交易触发的事件的查询。但是如果这样代替,极容易产生错误,因为交易存放在区块链中并不意味着交易已经成功执行,很可能由于执行过程中gas耗尽而中断执行。因此在一个交易可能执行失败的系统中,事件不仅能够对交易的执行提供证明,还可以对交易成功的执行并且与预期相符提供证明。

注意,交易仅仅能够生成事件,并不能读取事件。这种设计仅仅允许交易的执行基于当前状态,而不是基于历史信息,例如读取以往产生的事件是不允许的。

账本历史

账本历史保存了交易的提交和执行的顺序过程,以及它们所触发的事件。账本历史的目的是记录最近账本状态形成的过程。在账本历史中没有“块”的概念。

共识协议将交易打包成块,只是作为一种优化来驱动共识的执行。但是在逻辑数据模型中,交易是按顺序产生,并不需要区分哪个块包含了哪个交易。

尽管验证者执行新的交易时并不需要知道账本的历史,但是账本的历史可以用于客户审计交易的执行,例如客户可以对交易的历史提出认证查询。

客户查询响应

验证者是通过账本的历史来响应客户对以往账本状态、交易以及输出的查询。例如:一个客户可能会查询在某一版本号下的账本状态,例如:在版本30下,地址为x的账户余额是多少? 客户还可能会查询某一特定类型的历史事件,例如:地址为y的账户在最近20分钟内接收了哪些支付?

交易执行的审计

客户对账本状态的验证,是通过重新执行以往的每一笔交易Ti,将执行结果与相应版本数据库中对应的账本状态Si、交易输出Oi进行比较。

这一机制允许客户对验证者进行审计,从而确保交易的正确执行。

本节分析完毕。本节中,区块链本是存储在某一个版本的数据库中。而账本的历史状态是很重要的,因为交易是有顺序的。当前交易是基于前一个交易,否则就会乱套。现在要把银行帮我们记账搬到区块链上记账。因此账本的历史状态、当前状态都是需要刻画的。

此外,客户可以对账本审计,优点是透明,缺点是隐私无法保护。

 

本节第一话就开宗明义的指出:在Libra协议中,改变区块链状态的唯一方式就是执行交易。千万别忘了Libra是一个支付系统,是基于区块链的支付系统,所有的内容都是围绕着这个主题在转

本节概括了交易的执行条件,定义了交易的结构,解释了Move虚拟机如何执行一个交易,描述了Move 语言的核心概念。

在Libra 协议的最初版本里,只对用户提供了很小一部分Move语言功能。事实上,Move语言通常用来定义系统的核心概念,例如Libra币。用户是不允许发布模块来声明自己的资源类型。这种设计理念让Move语言在构建Libra 核心系统中逐步成熟,而且也回避了在智能合约中,执行交易与数据存储所带来的扩展性问题的挑战。

可见,在Libra 系统构建中,采用的是逐步求精的原则,尽量简单实用,不断进化。采取的很务实的态度。

至于Move语言的全部功能特性,将在第10节展开描述。如果你着急知道,可以跳到第10节,不过是英文的。

由于最近比较忙,我会坚持更新。写作和跑步对于我来说,都是一种放松和愉悦。

3.1交易执行之前的规则制定

比特币里有创世块的概念,即区块链中第一个块(称为创世块)是如何形成的呢?在Libra 系统中,系统一开始就设置好了创世状态,所有验证者默认即可,非常方便。

在Libra创世状态里,通过“模块”定义了系统的核心对象,例如:账户间的逻辑关系、交易验证、验证者的选择、Libra币等。在Libra创世状态中,必须考虑周全,例如至少有一个账户,能够支付得起第一笔交易产生的费用;必须要有一些验证者,能够对交易的认证进行签名确认。

账本的初始状态是什么?创世状态如何产生呢?注意,初始状态是系统原始状态,而创世状态是系统开始第一笔交易的状态,也就是启动系统的状态。

为了简化设计,系统的初始状态通过“空状态”表示。而创世状态是通过一个特殊的交易T0所创建,并且定义了所需要的模块与资源。注意,这里并没有通过正常的交易过程来建立创世状态,系统直接默认的设置执行特殊交易T0。因此,客户和验证者也被设置为只接受T0开始的账本记录,可以通过密码学的哈希技术标识T0的开始。

值得注意的是像T0 这样的特殊交易,只能通过设置的方式加入账本记录,而不能通过正常的共识算法加入账本记录。

这种方式的好处是处理简单,例如通过设置一个特殊交易来定义分叉的开始。像客户也可以设置一个特殊交易对模块和资源进行改变。这种特殊交易的执行都是在正常交易执行之外进行的,增加了系统对特殊事件的响应处理能力。当然,中心化的色彩就很浓了。不过,凡事都通过共识来完成,效率也太低。

●确定性

交易的执行具有确定性和封闭性。这意味着交易的输出结果完全是可以预计的,仅依赖于交易包含的信息和账本的当前状态。而且交易的执行不受外部的影响。

对于相同的交易序列号,确定性和封闭性使得不同验证者产生相同的验证结果。所以从创世块开始执行交易,一直到当前账本状态,可以重复获得相同的区块链的交易历史记录。

●可度量的

为了管理对计算资源的需求,Libra协议对每一笔交易收取交易费,通过Libra 币支付该费用。该方法遵循了以太坊的Gas理念。

在Libra系统中,选择具有充分计算资源的验证者,以满足Libra系统的正常运行。收取交易费用的唯一目的,是为了当资源需求超过系统所能提供的资源时,降低系统资源的需求量,从而保证系统正常的运行。

系统正常运行时,对于正常的操作只收取较低的费用。这与目前一些区块链的思路不同,有些区块链选取不具有充分计算资源的验证者。当资源需求变高的时候,交易费急剧增加,对于验证者能得到可观的回报,但是对于客户就是成本。

一笔交易的执行是以消耗的Gas成本来表示所消耗的计算资源的多少,该成本是动态的,因每个用户而不同。验证者会优先选择价格更高的交易执行,当系统繁忙时可能会漏掉价格低的交易。

交易中包含一个Gas的最大值,该值说明了在某个具体Gas价格下,发送者愿意支付的最大数量Gas。

在交易执行期间,虚拟机会跟踪Gas使用数量。如果在执行完成前,最大Gas数量用完,则虚拟机立刻终止。该交易不会对当前账本状态有任何影响,但是交易任然会出现在交易历史中,并且会对发送者收取交易费。

在这节我们看到,区块链中的核心逻辑的许多部分都是使用Move进行定义的,包括Gas费的扣除。为了避免循环扣除费用,虚拟机禁止在核心组件执行期间对扣Gas费。这些核心组件都是在创世状态下定义的,而且具有写保护以防止恶意交易触发的高额交易费用的代码执行。执行核心组件的费用将包含在后面对交易的收费中,是一项基础费用。

●资产语义

账本状态直接通过现实世界的数值对数字资产进行编码。交易执行中必须保证Libra币不能够被复制、丢失以及非授权转移。Libra协议只用Move虚拟机来实现交易和客户资产具有这些安全属性。

3.2交易的结构

一个交易是通过数字签名认证的信息,其内容如下:

发送者的地址:就是交易发送者的账户地址。虚拟机通过存储在发送者地址下的LibraAccount.T资源,来读取序列号、认证公钥、余额等内容。

发送者的公钥:该公钥对应于该交易数字签名所使用的私钥。公钥的哈希值与存储在LibraAccount.T资源中的认证公钥相匹配。

程序:包括用于执行交易脚本的Move字节编码,脚本所需的输入参数列表,所需发布的Move字节编码模块列表。

Gas价格:执行交易是需要掏钱的,和我们用的银行转账不一样。为了执行交易,发送者需要给出愿意支付每一Gas单元的Libra币数量。

Gas数量的最大值:执行交易允许被消耗的最大Gas数量值。

序列号:是一个无符号型整数,与在发送者在LibraAccount.T resource下的序列号相同。交易执行完后,序列号加1。由于每个交易有唯一一个序列号,所以不能重复交易。

发表评论

电子邮件地址不会被公开。 必填项已用*标注