APP下载

The Libra Blockchain开发者档案-(三)交易生命周期

消息来源:baojiabao.com 作者: 发布时间:2024-05-09

报价宝综合消息The Libra Blockchain开发者档案-(三)交易生命周期

对应官方文件:https://developers.libra.org/docs/life-of-a-transaction

交易的生命周期

为了更深入的了解Libra交易的生命周期,我们将跟踪一笔交易,从提交到Libra验证器,到使用Libra区块链处理确认交易的整个过程。然后,我们将“放大”来看验证器的每个逻辑元件及与其他元件之间的互动。

客户提交交易

Libra客户端建立一个原始的交易(称为T~5~raw)将10个Libra Coin从Alice账户转移到Bob账户。原始交易包含以下字段,每个字段都和其词汇表定义相关联。

Alice的账户地址.程式中Alice要执行的操作,包含如下: Move点对点交易字节码指令码指令码输入列表(例如,Bob的账户地址和付款金额)Gas价格(以微Libra/Gas为单位)-传送方执行交易时所需要支付的Gas金额。Gas是支付在区块链上计算和储存的所需要的费用,这是一个抽象浮动的计量,没有具体固定的真实价值。Alice愿意为此次交易支付的最高Gas量。交易的到期时间。序号5 序号为5的交易只能应用于交易序号为5的账户。客户端使用Alice的私钥对事务T~5~raw进行签名。签名后的交易T5包括以下内容:

原始交易。Alice的公钥Alice的数字签名假设

为了描述交易T5的生命周期,我们假设:

Alice和Bob在Libra区块链上有账户。Alice的账户中有Libra Coin。Alice的账户的当前序列号是5(表示已经从Alice的账户传送了5个交易)。网络上总共有100个验证器 - 网络上的V1到V100。客户端将交易T5提交给验证器V1验证器 V1是本轮的提议者/领导者。交易的生命周期

在本节中,我们将描述交易T5的生命周期,从客户端提交开始到交易在Libra区块链确认。

根据相关的情况,并在交易生命周期中的各个步骤编号,我们提供相关验证器节点及其相应元件之间的互动连结,熟悉了交易的生命周期中所有的步骤后,你可以参考每个步骤中相应元件之间的互动资讯。

注意:本文件中所有图形中的箭头都表示元件之间的指向,终止于执行操作的元件上。 箭头不表示读取,写入或返回的资料。

图1.1交易生命周期

接收交易

1 — 客户端将交易T5提交给验证器V1,验证器V1的准入控制(AC)元件接收该交易。 (客户端→AC AC.1)

2 — AC将使用虚拟机器(VM)元件执行验证检查,例如签名验证,检查Alice的账户是否有足够的余额,检查交易T5是否未被重复广播等。(AC→VM AC.2,VM.1)

3 — 当T5通过验证检查时,AC将T5传送到V1的内存池。 (AC→内存池 AC.3,MP.1)

释出交易至其他验证器节点

4 — 内存池将T5储存在内存缓冲区中。 内存池可能已包含从Alice的地址传送的多个交易。

5 — 使用shared-mempool协议,V1将在其内存池中与其他验证器(V2到V100)广播交易(包括T5),并将从其他验证器接收的交易放入其自己的内存池中。 (内存池→其他验证者MP.2)

块提议

6 — 由于验证器V1是提议者/领导者,它将从其内存池中提取一个交易块,并通过其共识元件将此块作为提议复制到其他验证器。(共识→内存池 MP.3,CO.1)

7 — V1的共识部分负责根据提议的块中的交易顺序协调所有验证器之间的协议。 (共识→其他验证者CO.2)。 有关我们提出的共识协议LibraBFT的详细资讯,请参阅我们的Libra区块链中的状态机复制技术文章。

区块执行和达成共识

8 — 作为达成协议的一部分,交易块(包含T5)被传递给执行元件。 (共识→执行CO.3,EX.1)

9 — 执行元件管理虚拟机器(VM)中的交易的执行。 请注意,在块中的交易已经达成一致之前,这种执行是以不确定的方式进行的。 (执行→VM EX.2,VM.3)

10 — 在执行块中的交易之后,执行元件将块中的交易(包括T5)附加到Merkle累加器(分散式历史账本)。 这是Merkle累加器的内存/临时版本。 执行了这些交易的(建议/推测)结果返回到共识元件。 (共识→执行CO.3,EX.1)。 从“共识”到“执行”的箭头表示执行交易的请求是由共识元件完成的。 (为了在本文件中一致使用箭头,我们不使用箭头来表示资料流)。

11 — V1(共识领导者)试图与参与共识的其他验证者就该块的执行结果达成共识。 (共识→其他验证者CO.3)

区块提交(生成)

12 — 如果块的执行结果由一组具有超过多数票数的验证器达成一致后并签名了,则验证器V1的执行元件从快取内存中读取块执行的结果并提交块中的所有交易至持久储存。 (共识→执行CO.4,EX.3),(执行→储存EX.4,ST.3)

13 — Alice的账号现在有100个Libra Coin,其序列号为6.如果T5由Bob重播,它将被拒绝,因为Alice的账号(6)的序列号大于重放的交易的序列号(5)。.

验证器元件互动

在上一节, 我们描述了一个交易从提交到在区块链分散式数据库中确认的一个典型交易生命周期。现在让我们更深入的了解验证器元件之间的互动,验证器处理交易并响应查询。相信这些资讯对以下人员最为有用:

想要全面了解系统如何在后台工作。有兴趣为Libra Core软件做出贡献。对于我们的描述,我们假设客户端将交易TN提交给验证器VX。 对于每个验证器元件,我们将在相应元件下的子元件中描述其每个元件之间互动。 请注意,描述元件间互动的子部分未严格按其执行顺序列出。 大多数互动与交易的处理相关,少数与客户端读取查询相关(查询区块链上的当前资讯)。

让我们看一下验证器节点的核心逻辑元件:

准入控制内存池共识执行虚拟机器储存在每个部分的末尾,我们提供了Libra Core相应“README”的连结。

准入控制 (AC)

)

图1.2准入控制

准入控制是验证器的唯一外部界面。 客户端向验证器发出的任何请求都会先转到AC。

客户端 → AC (AC.1)

客户端将事务提交给验证器VX的准入控制。 这可以通过以下方式完成:AC::SubmitTransaction().

AC → 虚拟机器 (AC.2)

准入控制访问验证器的虚拟机器(VM)并对交易初步检查,以便尽早拒绝格式错误的交易。 这通过以下方式完成:VM::ValidateTransaction().

AC → 内存池 (AC.3)

一旦 VM::ValidateTransaction() 没有返回错误, AC通过Mempool::AddTransactionWithValidation().将交易转发到验证器VX的内存池。 只有当TN的序列号大于或等于传送者账户的当前序列号时,验证器VX的内存池才会接受来自AC的交易TN(请注意,除非交易序号是下一个序列号,否则交易无法达成共识)

AC → 储存 (AC.4)

当客户端对Libra区块链执行查询时(例如,为了获得Alice账户的余额),AC直接与储存元件互动以获取所请求的资讯。

准入控制自述档案

有关实施细节,请参阅准入控制自述档案.

虚拟机器 (VM)

图1.3虚拟机器

Move虚拟机器(VM)验证并执行Move字节码编写的交易指令码。

AC → 虚拟机器 (VM.1)

当验证器VX的准入控制从客户端接收到交易时,它会呼叫VM上的VM::ValidateTransaction()来验证交易。

虚拟机器 → 储存 (VM.2)

当AC或内存池通过VM::ValidateTransaction()请求虚拟机器验证交易时,虚拟机器从储存载入交易到传送者的账户并执行以下验证:

检查交易中的签名是否正确(如发现错误签名的交易则拒绝)。检查传送人的账户身份资讯,验证金钥是否与其公钥的杂凑相同(对应交易中的私钥)。验证交易的序列号是否不小于发件人账户的当前序列号。 执行此检查可防止针对发件人账户重复广播同一交易。验证签名了的交易中的程式程式码有没有格式的错误,因为虚拟机器无法执行格式错误的程式程式码。验证发件人账户中是否有足够的余额来支付交易中指定的最大Gas量,从而确保交易可以支付,且使用其账户中的资源。执行 → 虚拟机器 (VM.3)

执行元件利用虚拟机器通过VM::ExecuteTransaction()执行交易。

这里重点要理解:执行交易不同于更新分散式账本的状态和将执行结果储存在储存中。 交易TN首先执行,但它作为在共识期间达成一致性共识的一部分来执行。 如果与其他验证节点就交易顺序及其执行结果达成了一致,那么结果就将保留在储存中,并更新分散式账本的状态。

内存池 → 虚拟机器 (VM.4)

当内存池通过共享的内存池从其他验证器接收交易时,内存池会在虚拟机器上呼叫VM::ValidateTransaction()来验证交易。

虚拟机器自述档案

有关实现的详细资讯,请参阅虚拟机器自述档案。

内存池

图1.4内存池

内存池是一个共享缓冲区,用于储存“等待”执行的交易。 当新交易新增到内存池时,内存池与区块链系统中的其他验证器共享此交易。 为了减少“共享内存池”中的网络消耗,每个验证器负责将其自己的交易传递给其他验证器。 当一个验证器从另一个验证器的内存池接收到一个交易时,该交易将被新增到接收者验证器的内存池中。

AC → 内存池 (MP.1)

执行初始验证检查后,验证器的AC将交易传送到验证器的内存池。但是仅当TN的序列号大于或等于发件人账户的当前序列号时,验证器VX中的内存池才接收发送人账户的交易TN。内存池 → 其余验证器 (MP.2)

验证器VX的内存池与同一网络中的其他验证器共享交易TN。其他验证器在其内存池中与验证器VX的内存池共享交易。共识 → 内存池 (MP.3)

当验证器VX成为领导者时,其共识将从其内存池中提取一块交易并将该块复制到其他验证器。 这样做的目的是为了将交易的排序和块中交易的执行结果达成共识。请注意,因为交易TN包含在共识块中,它不能保证TN最终会储存在区块链的分散式数据库中永久储存(也就是有效区块生成)。内存池 → 虚拟机器 (MP.4)

当内存池从其他验证器接收到交易时,内存池会在虚拟机器上呼叫VM::ValidateTransaction()来验证交易。

内存池自述档案

有关实现的详细资讯,请参阅Mempool自述档案。

共识

图1.5共识

共识元件负责处理排序交易块,并通过与网络中的其他验证器一起参与共识协议来达成一致结果。

共识 → 内存池 (CO.1)

当验证器VX是领导者/提议者时,验证器VX的共识通过该方式Mempool::GetBlock()从其内存池中提取一个交易块,并发出提议。

共识 → 其他验证器 (CO.2)

如果VX是提议者/领导者,则其共识将提取的交易块复制到其他验证器。

共识 → 执行, 共识 → 其他验证器 (CO.3)

共识与执行元件互动来执行一个交易块。 共识通过执行元件来执行一个交易块:Execution:ExecuteBlock()(参见共识→执行)在执行块中的交易之后,执行元件响应这些交易执行后的一个结果。共识出示执行后的结果,并试图与参与协商的其他验证节点就此结果达成一致。共识 → 执行 (CO.4)

如果网络中有足够的验证器为同一执行结果来投票,则验证器VX的共识元件通过Execution::CommitBlock()通知执行元件该交易块已准备好提交。

共识自述档案

有关实施细节,请参阅共识自述档案.

执行

图1.6执行

执行元件的工作是协调交易块(区块),并维持一个通过共识协商投票的过渡状态。

共识 → 执行 (EX.1)

共识请求执行元件通过以下方式来执行交易块: Execution::ExecuteBlock().执行元件维护一个“暂存器”,它将储存储存器中Merkle累加器中相关部分的副本。 此资讯用于计算区块链当前状态的根杂凑值。将当前状态的根杂凑与关于块中的交易资讯组合以确定Merkle累加器的新根杂凑值。 这一步在保留任何资料之前就执行了,这是为了确保在足够数量的验证者达成协议之前不会储存任何状态或交易。执行计算推测根杂凑值,然后验证器VX的共识签署此根杂凑值,并尝试与其他验证器达成对此根杂凑值的协议。执行 → 虚拟机器 (EX.2)

当共识请求执行元件使用:Execution::ExecuteBlock()执行交易块时,执行元件使用虚拟机器来确定执行交易块的结果。

共识 → 执行 (EX.3)

如果足够(法定)数量的验证器同意该块的执行结果,那么每个验证器会一致性通过执行Execution::CommitBlock()该执行包括了:通知其执行元件该块已准备好提交, 对执行元件的进行包括同意的签名,及为其协议提供证明。

执行 → 储存 (EX.4)

执行元件从其“暂存器”获取值,并通过Storage::SaveTransactions()将它们传送到储存器以实现持久储存。 执行筛选删除“暂存器”中的旧值(例如,无法提交的块)。

执行自述档案

有关实现的详细资讯,请参阅执行自述档案.

储存

图1.7储存

储存储存共识执行后的交易块及其执行结果。 在以下情况下,将通过储存一个/一组交易(包括交易TN):

以下所有问题,只要网络中超过2f + 1的验证者就能通过共识协议达成共识: 包含在块中的交易。交易的排序。包含在块中的交易的执行结果。有关如何将交易附加到区块链中资料结构的资讯,请参阅[Merkle累加器](https://developers.libra.org/docs/reference/glossary#merkle-accumulators)。

虚拟机器 → 储存 (ST.1)

当AC或内存池呼叫VM::ValidateTransaction()来验证交易时,VM::ValidateTransaction()从储存中载入传送人的账户,并通过只读许可权来检查交易的有效性。

执行 → 储存 (ST.2)

当共识元件呼叫Execution::ExecuteBlock()时,执行元件从储存中读取当前状态并结合内存中的“暂存器”资料来确定执行结果。

执行 → 储存 (ST.3)

一旦达成了对交易块的共识,执行元件就会通过呼叫 Storage::SaveTransactions()来储存来储存交易块并永久记录它们。 同时还将储存网络中同意该交易块验证器节点的数字签名。该块中“暂存器”的内存资料将更新到储存中,并记录交易。更新储存时,每个交易变更后的所有资源的序列号都会相应更新。注意:对于来自该账户的每个已提交交易,Libra区块链上的账户序列号增加1。AC → 储存 (ST.4)

客户端查询区块链中的资讯,AC直接与储存互动以读取所请求的资讯。

储存自述档案

有关实现的详细资讯,请参阅储存自述档案.

参考

欢迎页我的第一笔交易 - 指导您使用Libra CLI客户端在Libra区块链上执行您的第一笔交易。Move入门 - Move新区块链程式语言。交易的生命周期 - 提供交易提交和执行时“幕后”发生的事情。Libra核心概述 - Libra核心元件的概念和实现细节。CLI指南 - 列出Libra CLI客户端的命令及其用法。Libra 词汇表 - 提供Libra术语的快速参考。Libra区块链中的状态机复制 — 详细介绍我们的共识协议LibraBFT

2019-09-04 06:50:00

相关文章