Linera: 一个用于高度可扩展的Web3应用程序的区块链基础设施

Version 1 – December 22, 2022

译者：moveworld社区-G-xbt

Abstract

    我们提出了Linera，一个区块链基础设施，旨在通过在互联网规模上提供可预测的性能、安全性和响应性来支持最重要的web3应用。为此，Linera通过引入一种新的、集成的、多链范例来解决区块空间稀缺问题，该范例建立在弹性验证器之上。 Linera将用户置于协议的中心，允许他们管理自己的链(称为微链)中的块生产以获得最佳性能。为了帮助web3开发人员充分利用Linera基础设施，我们开发了一个丰富的、与语言无关的多链编程模型。 Linera应用程序使用异步消息跨链通信。在同一个微链中，应用程序是使用同步调用和临时会话(又名资源)组成的。得益于Wasm虚拟机，Linera的初始SDK将面向 Rust程序员。Linera基础设施基于委托权益证明。它将使用最先进的经济激励措施和社区的大规模审计来确保强有力的权力下放。¹

Contents

• 1 介绍
  • 1.1 Web3 中对可预测性能和响应能力的需求
  • 1.2 区块空间稀缺问题
  • 1.3 现有方法的缺点
  • 1.4 我们的任务
  • 1.5 项目概况
    • 1.5.1 具有弹性验证器的集成多链系统
    • 1.5.2 让多链编程成为主流
    • 1.5.3 弹性验证器的稳健去中心化
• 2 Linera多链协议
  • 2.1 参与者：用户、验证者、链所有者
  • 2.2 安全模型=
  • 2.3 符号
  • 2.4 微链
  • 2.5 跨链请求
  • 2.6 链状态
  • 2.7 块执行
  • 2.8 客户端/验证器交互
  • 2.9 核心协议的扩展
• 3 多链协议分析
  • 3.1 响应能力
  • 3.2 可扩展性
  • 3.3 安全
• 4 在 Linera中构建Web3应用程序
  • 4.1 创建应用程序
  • 4.2 多链部署
  • 4.3 跨链通信
  • 4.4 本地可组合性
  • 4.5 临时链
• 5 去中心化
  • 5.1 委托权益证明
  • 5.2 可审计性
• 6 结论

1 介绍

1.1 Web3 中对可预测性能和响应能力的需求

得益于区块链技术，下一代互联网web3将为用户提供新一代资产感知应用程序，并让他们对数字经济有更民主的控制。然而，开发具有良好用户体验的web3应用程序目前是一项具有挑战性的任务。问题之一是大规模的可靠性和响应能力：当太多用户活跃时，区块链可能会停止响应或要求惩罚性费用。一般来说，应用程序开发人员希望他们的基础设施编程接口易于使用和可预测，而忽略其他应用程序引起的流量。集中式API提供者²⁵已被提议用于促进在流行区块链之上的编程，但此类提供者需要被信任并且不会提高底层区块链的性能和费用。 Linera旨在通过提供可大规模保证性能和响应能力的区块链基础设施来缩小集中式和分散式应用程序之间的差距。

1.2 区块空间稀缺问题

传统区块链在费用和延迟方面具有不可预测的最坏情况结果的主要原因可以解释为区块空间稀缺问题。即，在由单个块链组成的区块链中，用户必须竞争才能将他们的交易选择到下一个块中。然而，与此同时，区块的生产率和大小受到共识协议、网络和执行层性能的限制。因此，在流量高峰期间(例如，NFT空投)，用户可能会被其他人高估或被延迟很长时间——在此期间，他们实际上无法使用基础设¹⁸。

1.3 现有方法的缺点

不出所料，多年来已经提出了许多区块链基础设施，并考虑到了可扩展性的改进。我们在这里提供了最常见方法的高级摘要，但并未力求面面俱到。

更快的单链。单个链中块的生产速率通常受到验证器之间的数据传播延迟的限制 ¹⁶。从历史上看，块大小一直是第一个要调整的参数，以根据安全要求和网络约束 [^17、^19] 最大化交易吞吐量。由于BFT共识协议的最新进展（例如 ¹⁸），如今交易速率的新瓶颈似乎是交易的顺序执行而不是共识排序。

    预计一个区块中包含的许多交易在实践中应该是独立的，最近的几个项目已经开发了能够在几个处理单元上并行执行交易的子集的架构¹⁷。虽然这肯定会导致更高的交易率，但这种系统的特点仍然是每秒钟最大交易数在6位数以下。此外，有效的交易率在很大程度上取决于每个区块中实际独立交易的比例²²。总而言之，这使得在不对其他用户的活动进行任何假设的情况下，不可能事先为一个用户保证费用和/或延迟。

    最后，在高吞吐量链中，由于执行的CPU需求和数据同步的网络需求，审计验证器变得更加困难。具体地说，连续交易的绝对数量可能会阻止只使用普通硬件的社区成员以足够快的速度快速验证交易，从而以有意义的方式验证验证器的工作²⁰。

区块链分片。解决区块链可扩展性的另一个流行方向是将执行状态划分为固定数量的并行链，每个并行链由一组单独的验证器独立运行。这称为区块链分片。

    虽然这种方法仍在不断改进，但它在历史上一直面临着一些挑战。首先，使用不同的验证器集会产生安全权衡，因为攻击者可能会选择性地攻击系统中最弱的一组（例如，铸造硬币）。其次，重组分片，即用户帐户跨链分布的方式，是一项复杂的操作，需要广泛的网络通信²⁷。最后，当分片数量增加以支持额外流量时，需要交换的跨链消息数量也会增加²²。在每个分片都有一组独立的验证器的系统中，跨链消息会产生显着的延迟，最终抵消添加新链的影响 ²⁷。

rollups。最后，解决区块空间稀缺性的一种流行方法是rollup协议，无论是乐观的还是基于有效性证明（又名ZK rollup）¹⁰。在高层次上，乐观和有效性（“ZK”）汇总都包含一个第2层协议，该协议构建一系列大块，旨在在第 1层执行、压缩和确认。不幸的是，确认交易的过程在这两种情况下，第1层都需要很长时间。乐观汇总必须等待几天才能解决争议。有效性汇总必须一次压缩许多第 2层交易以支付第1层gas。在实践中，收集足够的第2层交易、计算有效性证明和归档交易以强制执行严格的数据可用性需要每个第2层块几个小时。

    较长的第1层确认时间可能会鼓励某些用户接受安全权衡并相信某些应用程序的第2层的最终性。一般来说，汇总必须被信任以执行协议(i.e. for liveness)并公平地选择交易（参见矿工可提取价值 ¹⁴）。在最近设计去中心化汇总协议的努力中可以看出这种担忧 ²⁴。

1.4 我们的任务

受这些观察的启发，Linera 项目的创建是为了基于三个关键原则开发一种新型的web3基础设施：

（i.） 构建具有可预测性能和响应能力的安全基础架构——通过在一组弹性验证器中运行多个链；
（ii.） 启用可扩展 web3 应用程序的丰富生态系统——通过在新的执行层上工作，使多链编程成为主流；
（iii.） 最大化去中心化——通过确保弹性验证器得到最佳激励和社区大规模审计。

1.5 项目概况

Linera致力于为区块链社区提供以下创新。

1.5.1 具有弹性验证器的集成多链系统

为了实现我们对具有可预测性能和大规模响应能力的 web3 基础设施的愿景，我们开发了一种新的多链协议，旨在利用现代云基础设施：

（1）在 Linera 中，验证器是一种类似 web2 的弹性服务，可并行验证和执行多条链中的交易块。因为 Linera 系统中存在的链（活动和非活动）的数量是无限的，所以我们也称它们为微链。

（2）使用新区块积极扩展微链的任务与验证或执行是分开的，由每条链的所有者承担。鼓励每个 Linera 用户创建一个他们拥有的链并将他们的帐户放在那里。

（3）每个验证者都管理着所有的微链。（我们称之为集成多链方法。微链使用异步消息进行交互，否则独立运行。因此，验证者可以通过在许多内部工作人员（又名分片）之间分配他们的工作量来弹性扩展。使用每个验证器的内部网络可以有效地实现链之间的异步消息。

（4）微链在接受新区块的方式上可能有所不同。在扩展自己的链时，用户使用受可靠广播 ¹¹ 启发的低延迟、无内存池协议直接向验证器提交新块。需要用户之间更复杂交互的应用程序也可能依赖于按需创建的临时微链。在实践中，只有 Linera基础设施拥有的公共微链才需要完整的拜占庭容错共识协议¹¹。

（5）通常，验证者不进行交互——基础设施拥有的公共链除外。验证者之间的微链同步委托给链所有者。这意味着不活跃的微链（那些不创建块的）除了存储之外对验证者没有成本。

    使用弹性验证器是Linera的一个独特假设。我们打算为Linera社区支持新验证者可以选择的各种云提供商。Linera最初受到Meta⁶开发的学术低延迟支付协议FastPay的启发。 Linera通过将用户帐户转变为微链、添加智能合约以及支持链间的任意异步消息，显着推广了FastPay。 Linera多链协议的更详细描述在第 2节中给出。我们在第3节中分析了该协议。

1.5.2 让多链编程成为主流

Linera将许多链集成到一组独特的验证器中。由于每个验证器的内部网络，这极大地促进了跨链通信。第一次，各种 web3 应用程序有机会通过利用廉价高效的多链架构进行弹性扩展。为了促进多链编程的采用，我们做出了以下设计选择：

（6）Linera 的执行模型被设计为与语言无关且对开发人员友好。 Linera的初始 SD将基于Wasm并以Rust编程语言为目标。

（7）Linera应用程序是可组合的和多链的。一旦创建了应用程序，它就可以在任何链上按需运行。同一应用程序的运行实例使用异步消息和发布/订阅渠道跨链协调。在同一微链中运行的应用程序使用跨合约调用和临时会话对象进行交互。

    Linera 中的会话对象的灵感来自Move语言⁸中的资源。 Move中的静态类型资源已被提议用于帮助实现可组合性²¹。在Linera中，类资源的可组合性是通过使用会话句柄和运行时检查来实现的。例如，为了发送代币，Linera合约将能够转移包含代币的临时会话的所有权。

    一般来说，建立一个大型的开发者社区是采用区块链基础设施的一个主要因素。由于Wasm 态系统不断改进其多语言工具 ²，它为 Linera 提供了长期服务于多个开发者社区的可能性。有关 Linera 编程模型的更详细讨论，请参阅第4节。

1.5.3 弹性验证器的稳健去中心化

经典的“区块链三难困境”⁹ 断言同时实现可扩展性、安全性和去中心化是困难的。虽然这种观察对于固定容量的验证器肯定是成立的，但我们认为在定义和实施令人满意的弹性验证器去中心化概念方面还没有做出足够的努力。

（8）“区块链” ⁹断言实现扩展性，安全性去中心化是是困难困难的的。虽然虽然这种观察对于对于固定固定固定容量容量的的验证器肯定和实施令人们满意的弹性试验去中心化概念方面还没有做足足够的努力。

（9）微链被设计为可独立审计。这意味着Linera作为一个整体将由社区以分布式方式进行审计，仅使用商品硬件。

    使用大型验证器提高性能并使用社区维护去中心化区块链社区在汇总⁹的背景下讨论了驱动审计员。随着Linera项目的进展，我们将继续关注有效性（“ZK”）证明和链压缩领域的技术进步。Linera 的去中心化将在第5节中进一步讨论。

2 Linera多链协议

我们现在介绍位于Linera基础设施核心的多链协议。该技术描述旨在说明协议的主要思想，但并非详尽无遗。我们在第3节中非正式地分析协议，并在第4节中讨论编程模型。

2.1 参与者：用户、验证者、链所有者

Linera 协议旨在提供一个计算基础设施，开发人员可以在其中创建去中心化应用程序，最终用户可以安全高效地与它们进行交互。

    与区块链系统一样，Linera中应用程序的状态在多个称为验证器的部分受信任节点之间进行复制。修改应用程序的状态是通过将交易插入新块并将新块提交给验证器来完成的。

    为了支持可扩展性要求，Linera从一开始就被设计为一个集成的多链系统：块不是使用单链，而是组织在许多平行的块链中，称为微链。这意味着Linera应用程序的状态通常跨链分布。重要的是，除非正在进行重新配置（第 2.9 节），否则所有微链都使用一组验证器。

在Linera中，使用新区块扩展链的任务与区块验证是分开的。它由链的所有者承担。实际上，链的所有者可以是协议中的任何参与者。因为Linera验证器充当区块验证服务，所以链所有者也可以称为客户。链所有者的例子包括：

• 希望在不同应用程序中更好地控制其帐户的最终用户；
• 希望操作临时链（例如原子交换）的最终用户；
• 希望发布代码或管理应用程序的开发人员；
• 验证者出于基础设施目的共同运行一条链。

最后一个用例是Linera如何管理当前的一组验证器，也称为委员会。 Liner的编程模型在第4节中介绍。审计员的额外角色在第 5 节中讨论。

2.2 安全模型

Linera被设计为拜占庭容错(BFT)¹²。 所有参与者生成一个密钥对，由一个私有签名密钥和对应的公共验证密钥组成。 Linera使用委托权益证明(DPoS)模型²³，其中每个验证者的投票权与其权益和用户委托给它的权益绑定。

假设。 我们提出了总投票权为N的Linera协议。拜占庭（又名不诚实）验证者的一个固定的、未知的子集可能会偏离该协议。 假设他们控制至多f的投票权对于某个值f使得 0 ≤ f < \frac{N}{3}。 这类似于许多拜占庭容错协议[6,12]。 在实践中，人们选择f的最大可能值，即 f = \frac{N−1}{3}。

    当涉及到安全属性时，我们不会对用户、链所有者或网络层做出任何假设。 除非另有说明，否则活动属性不依赖于网络延迟或消息顺序。 换句话说，网络是异步的¹²。

    我们使用“法定人数”一词来指代由验证者发布的一组签名，这些签名的组合投票权至少为 N-f。 群体的一个重要属性，称为群体交集，是对于任何两个群体，都存在一个诚实的验证者α。 当数据类型（通常是一个块）被法定人数的验证者签名时，它被称为被认证。 认证区块也简称为证书。

目标。 Linera 旨在保证以下安全属性：

• 安全：对于任何微链，每个验证者都会看到相同的块链（的前缀），因此它对链的执行状态应用相同的修改序列，并最终将相同的消息集传递给其他链。
• 链的最终一致性：如果在一个诚实的验证者上用一个新的认证块扩展一条微链，任何用户都可以采取一系列步骤来确保这个块被添加到每个诚实验证者上的链中。
• 异步消息的最终一致性：如果一条微链在一个诚实的验证者上收到一条跨链消息，任何用户都可以采取一系列步骤来确保这条消息在每个诚实的验证者上都被链接收到。
• 真实性：只有微链的所有者才能扩展他们的微链。
• 分段可审计性：有足够的公共加密证据来证明的状态可以以分布式的方式对Linera的正确性进行审计，一次一个链。

对于单一所有者的链（第2.4节），Linera也保证以下属性：

• 单调块验证：在单所有者链中，如果一个区块提案是第一个由所有者在给定区块高度签署的，并且被诚实的验证者接受，那么通过适当的行动，链所有者最终总能成功收集到足够的选票 出示证书。
• 最坏情况下的效率：在单一所有者链中，拜占庭验证器不能显着延迟正确用户的区块提议和区块确认。

2.3 符号

我们假设一个抗冲突的散列函数，记为 hash(·)，以及一个安全的公钥签名方案 sign[.]。 区块 B 上的法定人数签名形成了一个证书，记为 C = cert[B]。 在本报告的其余部分，我们在同一块 B 上识别证书，当 C 是 B 上的任何证书时，只需写 C = cert[B]。

     Linera系统的状态在所有验证器之间复制。 对于给定的验证器，记为 α，我们使用符号 X(α) 来表示 α 关于某些复制数据 X 的当前视图。数据类型 D = ⟨Tag, arg₁, . . . , arg_n⟩ 是一个值序列，以不同的标记标签开始，并打算通过网络发送。 我们使用大写的名称来区分数据类型标记与数学函数（例如 hash）或数据字段（例如 ownerid(α)），并简单地为数据类型编写 Tag(arg₁, . . . . , arg_n)。 我们为一系列数据类型 (D₁,...D_n) 编写D̃。

2.4 微链

Linera基础设施的主要构建块是它的微链。 微链（或简称为链）类似于常规区块链，因为它由一系列块组成，每个块都包含一系列操作。 重要的是,Linera将提议新区块的角色（链所有者的角色）与验证它们的角色（验证者的角色）分开了。 扩展链的协议是可配置的，取决于链的类型。

链标识符。 微链由设计为不可重放的标识符id表示。 具体来说，唯一标识符（或简称标识符）是一个非空数字序列，写为 id = [n₁,...,n_k] 对于某些 1 ≤ k ≤ k_max。 我们使用 :: 表示序列末尾一个数字的串联：[n1, . . . , nk+1] = [n1, . . . , nk] :: n_k+1 (k < k_MAX)。 在这个例子中，我们说 id = [n_{1,...,nk] 是 id::nk+1 的父级。}

    Linera系统从创世配置中定义的一组固定微链开始。 要创建新链，现有链的所有者必须执行链创建操作。 新标识符被计算为父标识符和创建新链的操作索引的串联。

链类型。 Linera 支持三种类型的微链：

(i) 单一所有者链，其中只有一个用户（由其公钥标识）被授权提议区块；
(ii) 许可链，其中只有一组明确定义的合作用户被授权提议区块；
(iii) 任何用户都可以提议将操作包含在验证器的下一个块中的公共链。

    在所有这三种情况下，验证者之间关于链的下一个区块B的协议都由证书 C = cert[B] 很好地表示。 在单所有者链的情况下，证书C的产生受到可靠广播 [6,11] 的启发，将在第 2.8 节中详细描述。 在公共链的情况下，证书 C 是由验证者之间的经典 BFT 共识协议产生的提交证明。 第 2.9 节概述了许可链和公共链的情况。 为简单起见，除非另有说明，否则本报告的其余部分将重点关注单一所有者链。

    每个链都包含一个字段 owner^id(α) 以验证其所有者（如果有）。 当链有一个由公钥 pk 验证的所有者时，我们写 owner^id(α) = pk。 许可链有 owner^id(α) = {pk₁,...,pk_n} 和公共链 owner_id(α) = ⋆。 当 owner_id(α) = ⊥ 时，链被认为是不活跃的。

链生命周期。 任何现有的链都可以为另一个用户创建一个新的微链，并使用区块证书 C 作为创建证明。 一旦创建，新的微链就独立于其父微链工作。 Linera将提供一条专用的公共链，以允许新用户轻松创建他们的第一个链。

    Linera还可以通过执行改变密钥owner^id(α)的操作，将链的控制权安全且可验证地转移给其他用户。设置owner^id(α)= ⊥可以有效地永久停用该链。

    使用唯一标识符很重要，这样可以安全地删除已停用的微链的状态并将其存档在冷库中，同时防止区块链被重放。

区块。 块是由以下数据组成的数据类型 B = Block(id, n, h, \widetilde{O})：

• 扩展id的链的唯一标识符，
• 区块高度 n ≥ 0，
• 前一个区块的哈希 h（如果 n=0 则为 ⊥），
• 一系列操作 \widetilde{O}。
  操作 O 是在链 ID 上执行一次的指令，可能对可选的接收者链 ID' 产生影响。 操作可能例如 创建链、执行用户交易或从其他链接收消息。

    当验证者收到包含 id 和下一个预期区块高度 n+1 的认证请求 C = cert[B] 时，具有当前区块链 ⊥ → B₀ → ... → B_n 的微链 id 被区块 B 成功扩展。 验证者跟踪每个链 id 的当前状态，并且仅在验证正确的链接和 B 的正确执行后投票赞成添加块 B。在 BFT 假设下，这确保验证者最终在每个链上执行相同的块序列， 因此同意执行状态。

    块 B 的执行包括按给定顺序解释 B 中列出的操作 \widetilde{O}。 操作可能会为其他链生成传出消息并消耗传入消息。 实际上，出于审计目的，块 B 还包括执行块后状态的哈希值，以及操作产生的传出消息。

2.5 跨链请求

Linera应用程序的状态通常分布在许多链中以实现可扩展性。为了跨链协调，应用程序依赖于异步通信（另请参阅第 4.3 节关于可编程性）。

    在协议层面，链与链之间的异步通信依赖于一种称为跨链请求的重要机制。 具体而言，验证者α在链id上的块中执行操作有时可能会触发一次性异步交互，这将修改另一个链id'的状态。（有关跨链请求的伪代码示例，请参见算法 1。）跨链请求在每个验证器的内部网络中使用远程过程调用（RPC）廉价地实现：实现只需要确保每个请求恰好执行一次。

    重要的是，通常不可能通过跨链请求任意修改目标链的执行状态，因为验证者不同意跨链请求的执行顺序——换句话说，这会破坏安全属性。 FastPay⁶仅使用跨链请求进行支付，而Linera使用此机制创建新链并将消息传递到现有链的收件箱。

    收件箱允许 Linera 支持任意消息，因为修改不会立即应用于目标链。 相反，消息被放置在目标链的收件箱中，实现为第 2.6 节中描述的可交换数据结构（即插入顺序无关紧要）。 接收链的所有者然后执行从收件箱中挑选消息并将其影响应用于链状态的操作（第 2.7 节）。

2.6 链状态

我们现在描述验证者和客户看到的 Linera 链的状态。 每个验证器都存储一个映射，其中包含所有链的状态，由它们的标识符索引。 客户对链有类似的表示，除了它们仅作为与其相关的一小部分链的全节点（即跟踪块链和执行状态）。 接下来，我们关注给定验证器的状态，记为 α。

链状态。 验证者 α 看到的链 id 的状态可以分为 (i) 一致的部分，它是块链的确定性函数 ⊥ → B0 → 。 . . → B_n 已经被 α 执行； (ii) 验证者可能不同意的本地化部分。 链状态的一致部分包括以下数据：

• 如前所述，控制 id 中块生产的字段 owner^id(α)。
• 一个整数值，写成 next-height^id(α)，跟踪预期的区块高度下一个 id 块。 （此处为 n + 1。最初为 0。）
• 前一个区块的哈希 block-hash^id(α)（初始为⊥。）
• 执行状态，记为 state^id(α)。

链状态的本地化部分包括以下内容：

• pending^id(α)，一个可选值，表示 id 上的块正在等待确认（初始值为⊥）。
• 证书列表，写成received^id(α)，跟踪所有已经被接收的证书由 α 确认并涉及 id 作为接收链。
• 称为收件箱的数据结构，用 inbox^id(α) 表示（见下一段）。

pending^id(α) 字段特定于单一所有者链，并在第 2.8 节中进行了解释。 在许可链和公共链的情况下，它由附加数据完成received^id(α) 证书列表对于活性至关重要（第 3.3 节）。

收件箱状态。 收件箱 I = inbox_id(α) 是一种特殊的数据结构，用于跟踪 id 收到并等待操作消费的跨链消息。 在最简单的实现中，可以将收件箱视为两组不相交的消息 I = (I₊, I₋)：

• I₊ 跟踪 id 已经收到并等待在下一个块中被消费的消息 m，
• I_- 跟踪尚未被 id 接收的消息 m（从 α 的角度来看），但由于在认证块中的操作而被预期消耗。

收件箱的一个重要属性是添加或使用不同的消息是可交换的。 在这个简化的演示文稿中，我们假设消息永远不会完全相同地重放，比方说，多亏了计数器。 （否则，我必须是从消息到有符号整数的映射。）Linera 的当前实现使用更复杂的数据结构，强制对每对 (id',id) 和每个应用程序的消息进行排序。

2.7 块执行

我们现在描述如何执行块链中包含的操作序列。 Linera部署支持的操作通常包括以下内容：

• OpenChain(id',pk') 使用新的标识符 id' 和公钥 pk' 激活一条新链——可能代表拥有 pk' 的另一个用户；
• Execute(t) 在智能合约应用程序的上下文中执行用户交易 t；
• Receive(m) 消费并执行来自收件箱的消息 m；
• ChangeKey(pk′) 转移链的所有权；
• CloseChain 停用链 ID。

为简单起见，我们省略了多所有者链和重新配置所需的交易费用和附加逻辑（第 2.9 节）。 为了执行交易t，我们假设一个方法 ExecuteTransaction(id, t) 尝试修改 state^id并且在成功的情况下可能返回 ⊥ 或 (m,id')，后一种情况是请求将消息 m 发送到 链号'。 我们还假设了一种通过执行跨链消息 m 来修改 state^id 的方法，记为 ExecuteMessage(id, m)。

    此描述转化为算法 1 中的伪代码。块的执行上面建议的 B = Block(id,n,h, \widetilde{O}) 对应于函数 ExecuteBlock。函数 BlockIsValid 对块的验证类似于 ExecuteBlock除了不会持久化对状态的更改，忽略跨链查询和消息不能按预期执行，也就是说，如果 inbox^id 在以下位置不为空，则验证失败 -通话结束。

2.8 客户端/验证器交互

我们现在可以描述 Linera 系统中客户端（又名链所有者）和验证器之间的交互。 Linera 协议的客户端运行一个本地节点，标记为 β，该节点跟踪与他们相关的一小部分链。这些相关链通常包括客户拥有的链以及直接依赖链，特别是负责跟踪验证器及其网络地址的特殊管理链（第 2.9 节）。

    与验证器的网络交互总是由客户端发起。 客户可能希望 (i) 用新区块扩展他们自己的一条链，或者 (ii) 向滞后的验证者提供客户感兴趣的链中缺少的证书。

    为了支持这两个用例，验证器提供算法 2 中描述的两个服务处理程序，称为 HandleRequest 和 HandleCertificate。 为简单起见，我们省略了客户端用来查询链状态或从验证器下载区块链的服务处理程序。

    我们从旨在更新滞后验证器的交互开始。

将丢失的证书上传到验证器。 任何客户端都可以使用 HandleCertificate 入口点将 B = Block(id,n,h, \widetilde{O}) 的新证书 C = cert[B] 上传到验证器 α，前提是链 id 是活动的并且 n 是下一个 从 α 的角度来看的预期区块高度（即形式上的 owner^id(α) \neq ⊥ 和 next-height^id(α) = n）。

    如果验证者 α 还没有创建链 ID，或者它滞后了一个以上的区块，具体来说，客户端应该上传一系列以 C = cert[B] 结尾的多个缺失证书。 如有必要，序列可以从祖先链 id' 的块开始（即，id' = parent(parent(... id))）。 在这种情况下，序列将继续，直到到达创建链 ID 的父链的块，然后以 C 结尾的块链结束。

    在实践中，上传这样一系列证书的需要证明本地节点 β 可以首先跟踪链 ID。 客户端可以通过查看记录在列表 received^id(β) 中的第一个块来快速找到创建 id 的确切块。

扩展单一所有者链。 在验证器足够新的常见场景中，Linera 客户端可以使用图 1 所示的可靠广播 [6,11] 的变体使用新区块 B 扩展他们的链，并按如下方式进行。

• 客户端使用 HandleRequest 入口点α(1) 将通过其签名验证的块 B 广播到每个验证器，并等待响应的法定人数。
• 验证器通过发回 B 上的签名（称为投票）作为确认（3）来响应预期高度的有效请求 R = auth[B]。 在收到来自法定人数的验证者的投票后，客户端形成证书 C = cert[B]。
• 当上传具有预期下一个块高度的证书 C = cert[B] 时（4），这将触发块 B 的一次性执行（5）。

    如果某些验证者 α 无法立即投票给其他情况下有效的提案 B = Block(id,n,h, \widetilde{O})，则有时首先需要同步步骤 (0)。 这可能有两个原因：

1. 链 ID 尚未激活或 α 缺少较早的块（即正式的 owner^id(α) = ⊥ 或 next-height^id(α) < n）；
2. α缺少跨链消息，即：I_= inbox_^id在Õ阶段执行结束时不为空。

在第一种情况下，Linera 客户端必须如前一段所述在链 ID（可能还有其祖先）中上传缺失的证书，直到 next-heightid(α) > n。 在第二种情况下，客户端必须在已将消息 m ∈ I₋ 发送到 id 的链中上传丢失的证书。 当 B 已被正确构建时（即不尝试接收从未发送过的消息），集合 I₋ 必然被并集 \cup_βreceived_id(β) 中列出的证书覆盖，其中 β 的范围超过验证器的任何法定人数。

    重要的是，将丢失的块上传到验证器对所有客户端都有好处。 为了最大限度地提高活跃度并减少其未来操作的延迟，在实践中，预计用户会在涉及到自己的链时主动更新所有验证器，从而最大限度地减少其他客户端同步的需要。 然而，每个人同步的可能性对于活跃度很重要。 它还允许证书充当已认证块的最终证明。

    实际上，客户端应该在每个验证器的单独线程上执行可选的同步步骤 (0) 和投票步骤 (1)。 为了防止来自恶意验证器的拒绝服务攻击，客户端可能会在收集到足够的选票后立即停止同步验证器 (2)。

    用于在单一所有者链中决定一个新块的步骤 1) 2) 3)构成了一个 1.5 往返协议。 受可靠广播的启发，该协议没有“视图更改”[11] 的概念来支持重试。 换句话说，一旦一些验证者投票支持 B，已经开始提交（有效的）区块提议 B 的链所有者不能中断提议不同区块的过程。这样做会有阻塞他们的链的风险。 出于这个原因，Linera 还支持具有额外往返行程的变体（第 2.9 节）。

2.9 核心协议的扩展

我们现在勾勒出一些对核心 Linera 多链协议的重要扩展。

许可链。 2.8 节中介绍的协议允许在 1.5 客户端-验证器往返中乐观地扩展单所有者微链。 Linera 还支持具有 2.5 次往返的更复杂的协议来解决以下用例：

• 单个链所有者希望能够在进行中时安全地中断正在进行的区块提议。
• 块中的操作依赖于外部预言机（例如 Unix 时间），并且包括在有效后可能变为无效的条件。
• 多个所有者希望操作链（假设链下协调最少）。
• 单个链所有者希望委托与验证器相关的维护操作重新配置。

    为简洁起见，我们省略了 2.5 往返协议的细节。 它可以被看作是一个简化的部分同步 BFT 共识协议 ¹¹，具有视图更改（也称为回合）但没有领导者选举或超时。 在没有领导者选举的情况下，不同的所有者可能会尝试同时提议不同的块（即在相同的块高度和轮次中）导致当前轮次失败并需要另一轮。 因此，这种操作模式假设同一链的所有者保持足够水平的（链下）合作，以便最终只有其中一个人提出一个区块并成功。

公链。 其余用例使用公共链：当链自己不断产生新块时，可以接受来自任何用户的交易。 应用示例包括：

• 在一个地方管理验证器和权益（参见下面的重新配置）。
• 运行并非旨在利用多链方法的传统区块链算法（例如 AMM）；
• 促进为新用户创建微链。

     Linera中的公共链将基于完整的拜占庭容错共识协议。 这是 Linera 基础设施中 Linera 验证者在区块提案中发挥积极作用的唯一案例。 我们计划依靠用户链和跨链消息而不是传统的内存池来将用户交易收集到新的区块中。

发布/订阅频道。 跨链异步消息的一个常见用例是链 ID 上的应用程序实例创建一个通道并维护一个订阅者列表。 具体来说，一个频道的运作方式如下：

• 在链id上执行的用户交易可能会向通道推送新消息；
• 发生这种情况时，当前订阅者会在他们的收件箱中收到一条跨链消息；
• 通过接收和执行来自订阅者 id' 的消息 Subscribe(id') 和 Unsubscribe(id')，在链 id 上管理订阅者集。

     我们发现在对 Linera 应用程序进行编程时，发布/订阅通道是一种有用的抽象（另请参见第 4 节）。 Linera 协议本身支持发布/订阅频道，以实现特定的优化。 例如，新接受的订阅者当前接收频道的最后一条消息，而无需频道所有者的额外工作。

重新配置。 能够更改线性验证器（也称为委员会）的集合对于系统的安全性至关重要（请参阅第 5 节）。

    为此，Linera 部署了一个专用的 Admin 公共链，运行该应用程序以进行系统管理。 该系统应用程序负责跟踪连续的验证者集，也就是委员会，包括他们的股份和网络地址。 此应用程序生成的连续配置由它们的纪元编号标识。

    为了安全地传播验证者集正在更改的信息，管理员将新配置发布到一个特殊频道，每个 Linera 微链在创建时都会订阅该频道。2 新创建的微链会自动接收当前验证者集（即最后一条消息在 管理频道）并设置其当前纪元号字段。

    创建新委员会时，每个微链都会在其收件箱中收到一条消息。 重要的是，微链所有者必须将传入的消息包含在新块中，以明确地将他们的链迁移到新的验证器集。 这必须在两组验证器仍在运行时，在前一组验证器停止之前完成。

    由于 Linera 的可扩展性，只要有足够多的客户端处于活动状态，就可以在短时间内将大量链并行迁移到新配置。 为了促进这一过程并允许链所有者长时间离线，我们设想许多用户将授权第三方代表他们创建迁移块。 然而，这将需要将链配置为在授权期间使用上述 2.5 往返协议

    为了防止远程攻击，管理员还会定期建议弃用旧委员会。 接受此类更新后，微链将忽略仅由弃用委员会认证的块中的消息。 旧消息只有在包含在以可信配置结尾的区块链中（因此重新认证）后才会被再次接受。

3 多链协议分析

在本节中，我们分析了Linera区块链设定的设计目标，包括响应能力、可扩展性和安全保证。

3.1 响应能力

与经典区块链交互时的一个常见问题是缺乏性能保证。提交到mempool的交易可能会立即、过一会儿或永远不会被挑选，这取决于大约同时发布的其他用户交易。取消待处理的交易通常需要提交另一笔具有更高汽油费的交易。此外，经典区块链具有固定且有限的吞吐量：足够大的提交交易突发（例如由于流行的空投）最终必须导致积压和/或交易费用激增。 Mempool系统还通过矿工可提取价值 (MEV) 技术向用户公开价值流失。

    Linera允许用户管理自己的链并解决这些问题，这要归功于受基于客户端的可靠广播启发的轻量级块扩展协议（第 2.8 节）。这种方法不需要内存池，因为用户直接将交易提交给验证器并完全控制处理时间。与验证器的并行通信意味着唯一的处理延迟是由客户端和验证器之间的网络往返时间（RTT）强加的（通常是几百毫秒）。 Linera可以轻松构建对延迟敏感的应用程序，并提供可靠且可预测的处理时间。最后，移除内存池和减少延迟大大减少了MEV机会。

3.2 可扩展性

微链的方法（第 2.4 节）允许Linera验证器在多个工作者之间有效地分片。具体来说，验证器中的每个工作人员负责特定的微链子集。客户端与每个验证器的负载均衡器通信，验证器在内部将查询分派给适当的工作者（图 2）。

    这种设计使得Linera可以随着系统负载的增加而水平扩展：每个验证者只需要添加worker机器来应对流量。重要的是，分片是内部的：工人的数量和微链分配给工人的数量不需要在验证者之间保持一致。

    单个验证器中的工作者属于一个实体，因此彼此信任。这使得工作人员之间的通信-以及Linera的跨链请求（第 2.5 节)-快速且廉价。

    Linera的分片模型不同于称为区块链分片的方法 [29,31]。在后者中，跨链消息在互不信任的节点组（即负责每个分片的验证器）之间交换，通常分布在 Internet 上。这会产生很大的开销。 Linera在相互信任且需要更少资源的同地工作者之间使用点对点通信。同时，想要控制其操作的客户可以有效地审计更大的验证器。我们在第 5 节中描述了审计操作。

    Linera的弹性架构允许验证器适应流量波动。当提交的交易数量增加时，很容易增加处理交易的基于云的工作人员的数量。当不再需要降低成本时，可以快速关闭相同的工作者。

    Linera的公共链需要完整的拜占庭容错共识协议来对多个客户端提交的区块进行排序（第 2.9 节）。然而，共识协议在每个公共微链上实例化一次，而不是为整个系统实例化一次。这有很多好处。首先，来自不同公共微链的用户不能降低彼此的体验。其次，单个微链的交易率不是整个系统的限制因素。最终，Linera 的吞吐量总是可以通过创建额外的微链和增加验证者的规模来增加。

3.3 安全

在本节中，我们提供了Linera多链协议的非正式安全分析。按照第2节中的描述，我们关注单一所有者链。在未来的报告中，分析将扩展到其他类型的账户（第 2.9 节）。

声明 1(安全）。对于任何微链，每个验证者都会看到相同的块链（的前缀），因此它对链的执行状态应用相同的修改序列，并最终将相同的消息集传递给其他链。

    事实上，根据算法 2，每个诚实的验证者在每个微链的给定高度最多投票给一个有效区块。 根据法定人数交集属性（第 2.2 节），在拜占庭容错假设下，每条链的每个高度只能有一个区块由法定人数的验证者认证。 来自链的传出消息集（算法 1 中的交叉请求）是当前块链的确定性函数。

    重要的是，异步跨链消息在计划后恰好传递一次。 这允许应用程序安全地转移资产。

声明 2(链最终一致性）。如果在一个诚实的验证者上用一个新的认证块扩展一条微链，任何用户都可以采取一系列步骤来确保这个块被添加到每个诚实验证者上的链中。

    事实上，任何用户都可以从诚实的验证者那里检索新证书及其前身，并将其传递给尚未收到它的验证者。 块可以上传到验证器的确切顺序在第 2.8 节中讨论。

声明 3(异步消息的最终一致性）。如果一条微链在一个诚实的验证者上收到一条跨链消息，任何用户都可以采取一系列步骤来确保这条消息在每个诚实的验证者上都被链接收到。

    只有在包含触发消息的事务的块由法定人数签名并添加到发送方的链之后，链才会在特定验证器上接收异步消息。 发生这种情况时，接收链的状态将更新以跟踪消息的来源（请参阅第 2.6 节中的 received^id(α)）。 这允许客户端在需要时从同一验证器下载相应的块。 任何诚实的验证者第一次添加相同的区块都会将相同的消息添加到收件人的收件箱中。

声明 4(真实性)。只有微链的所有者才能扩展他们的微链。

    诚实的验证者只有在所有者验证后才接受区块提议（算法 2）。 这确保没有其他人可以向微链添加块。 其他类型的微链（第 2.9 节）实现类似的验证。

声明 5(分段可审计性)。有足够的公共加密证据证明 Linera 的状态可以以分布式方式审计正确性，一次一条链。

    任何 Linera 客户端都可以请求任何微链的副本并重新执行经过认证的块。 这允许验证连续的执行状态和来自链的传出消息集。 执行状态通常通过在块中包含执行哈希来跨验证器进行比较。 一条链接收到的消息应该与来自其他链的传出消息进行比较（第 5.2 节）。

声明 6(最坏情况下的效率)。在单一所有者链中，拜占庭验证器不能显着延迟正确用户的区块提议和区块确认。

    线性客户端并行联系所有验证器，并在收到法定验证器的部分签名后立即认为操作已完成（第 2.8 节）。

声明 7(单调块验证)。在单所有者链中，如果一个区块提案是第一个由所有者在给定区块高度签署的，并且被诚实的验证者接受，那么通过适当的行动，链所有者最终总能成功收集到足够的选票 出示证书。

    如果针对某个链ID的区块提案B被验证者接受并且是第一个在此高度签名的提案，这意味着所有其他验证者α已经接受了该提案（即 pending^id(α) = B）或尚未投票然而（即 pending^id(α) = ⊥）。 在后一种情况下，如果缺少一些较早的块或消息，块验证可能会暂时失败 α：这可以通过使用丢失的块更新验证器来解决（参见第 2.8 节）。在适当的同步之后，在没有外部预言机和非确定性行为的情况下，将提案B提交给验证者最终会产生对B的预期投票。

4 在 Linera中构建Web3应用程序

Linera的编程模型旨在为应用程序开发人员提供丰富的、与语言无关的可组合性，同时利用微链进行扩展。

4.1 创建应用程序

Linera使用WebAssembly(Wasm)虚拟机¹⁹作为用户应用程序的主要执行引擎。用于开发Linera应用程序的SDK最初将以Rust语言为目标。

    一个应用程序是通过几个步骤创建的(图3)。首先，Rust中的软件模块(又名智能合约)被编译为Wasm字节码。然后字节码由其作者在其选择的微链上发布，并接收一个唯一的字节码标识符。接下来，使用字节码标识符和特定应用程序参数（一个应用程序是通过几个步骤创建的（图 3）。首先，Rust 中的软件模块（又名智能合约）被编译为 Wasm 字节码。然后字节码由其作者在其选择的微链上发布，并接收一个唯一的字节码标识符。接下来，使用字节码标识符和特定应用程序参数（例如代币名称、代币供应等）实例化字节码。此操作创建一个新的应用程序标识符（图3中的“app 1”）并初始化应用程序的本地状态（“app instance 1B”）。这个初始本地状态可能包含特定参数，以帮助管理未来的新应用程序。例如代币名称、代币供应等）实例化字节码。此操作创建一个新的应用程序标识符（图 3 中的“app 1”）并初始化应用程序的本地状态（“app instance 1B”）。这个初始本地状态可能包含特定参数，以帮助管理未来的新应用程序。

    单个字节码标识符可以跨共享相同代码但不共享相同配置的多个独立应用程序产生（图3中的“应用程序 1”和“应用程序 2”）。

4.2 多链部署

Linera应用程序默认是多链的，因为它们的全局状态通常分布在多个链上。换句话说，给定链上应用程序的本地实例只保存位于那里的应用程序状态的子集。例如，在类似 ERC-20 的令牌管理应用程序中，单一所有者链的所有者可能希望在她拥有的链上持有他们的个人账户。

    当微链的所有者第一次接受来自应用程序的传入消息(第2.5节）（图3中的“应用程序实例 1C”）时，会自动下载应用程序的字节码并启动应用程序。

4.3 跨链通信

应用之间的跨链通信是通过异步调用实现的，让微链独立运行。 Linera应用程序之间跨链协调的编程风格受到参与者模型⁵的启发。该实现依赖于第2.5节中描述的跨链请求。基本点是每个参与者都可以独占访问自己的内部状态，并且参与者不能直接相互调用。

跨链信息 跨链消息允许应用程序将任意数据从一条链异步传输到另一条链(图 4）。为了理解数据，同一个应用程序必须位于跨链消息的发送端和接收端。在实践中，应用程序的本地实例为实例与之通信的每个来源维护一个收件箱。当应用程序想要将消息发送到目的地时，它们会返回一个包含消息的值，以便运行时可以执行适当的跨链请求。

    与FastPay⁶和Zef⁷相反，Linera不限于支付请求，可以传递用户应用程序定义的任意跨链消息。跨链消息的影响通常不会相互交换，因此在Linera中，接收传入消息然后由接收者链执行的顺序很重要。我们通过依赖区块提议者在从链收件箱中挑选消息时指定传入消息的顺序来解决这个问题。

    通常，不能保证消息在接收方被拾取。如果是，当前的实现会强制按顺序挑选消息。这一一般政策可能会在未来得到完善，以解决特定的用例，特别是对于块生产永不停止的公共链（第 2.9 节)。

Pub/sub 通道. 除了一对一通信之外，Linera 还支持使用通道进行一对多通信。用户可以在一个应用程序中创建一个通道，而驻留在其他微链上的相同应用程序实例可以通过发送带有发布者应用程序和链标识符的订阅消息来订阅它。重要的是，只有当发布者通过将注册消息添加到其链中来接受订阅时，订阅者才会被添加到频道中。在引擎盖下，通道充当一组一对一的连接。发送到频道的消息会传送到订阅该频道的所有收件箱，并且可以由订阅者接收。按照设计，迟到的订阅者一旦被发布者接受，就会收到发送到通道的最后一条消息，而不是消息的整个历史记录。

4.4 本地可组合性

同步调用。 在同一条微链上，不同的Linera应用程序可以使用类似于经典区块链（如以太坊 ²⁶）中的智能合约调用的同步调用来组合（参见图 4 的顶部）。由一系列应用程序调用产生并源自单个用户交易的状态修改是原子的。换句话说，要么所有调用都成功，要么全部失败。调用应用程序会创建其内部状态的虚拟副本，并对缓存状态执行调用。此时，新状态尚未写入存储。如果任何交易失败，所有分阶段的修改都将被丢弃。

会话。 在某些情况下，希望将状态片段的管理从一个应用程序委托给另一个应用程序。我们将管理这种分离状态的临时对象称为会话。用例的典型示例如下： (i) 应用程序B调用令牌管理应用程序 A； (ii)部分代币从A的账本中取出，放入新的session； (iii)B获得会话的所有权； (iv)B调用会话将代币移回A的分类帐，例如，在另一个帐户下；这有效地消耗并终止了会话。

会话保证由单个应用程序拥有（无重复）。消费会话不是可选的：必须在当前交易结束之前正确消费会话，否则事务将失败。因此，除了资产之外，会话还适用于管理临时义务，例如，偿还快速贷款的义务 ²¹。

4.5 临时链

Linera编程模型的另一个特点是能够创建短期许可链（第 2.9 节），用于少数松散协调的用户之间的短期交互。

    例如，两个用户可以创建一个微链来原子地交换两个资产。共享微链将有（最多）两个所有者，其参数将适应交换过程。要使用这条链，两个用户都必须将他们想要交换的资产从他们的主微链转移到共享链，然后其中一个用户必须创建一个块来确认或取消交换。重要的是，一旦交换结束，共享微链就会被停用。这可以防止临时链的任何进一步扩展，并允许在将来对其进行归档。

    为了在临时许可链的情况下优化活跃度（第 2.9 节），操作可以与用户许可交互以提议块，如共识协议所见。例如，在用于原子交换的临时链的情况下，希望将提议块的能力限制给那些已经锁定其资产的所有者。另一个例子是专门用于两个用户之间的国际象棋游戏的临时微链。在这里，应用程序可以确定哪个玩家需要移动并更新微链共识层以仅接受来自所选用户的下一个区块。一个更现实的国际象棋应用程序还可能包括裁判作为临时链的所有者来强制进步。

5 去中心化

Linera鼓励验证者使用云基础设施来解锁弹性扩展并从标准生产环境中受益。为了最大化去中心化，Linera依赖于两个关键特性：委托权益证明 (DPoS) 和社区审计。

5.1 委托权益证明

为了确保系统的长期安全，Linera依赖于委托权益证明 (DPoS)：验证者的投票权是他们在系统中的权益以及最终用户委托给他们的权益的函数。为了使DPo 正常运行，用户必须能够更改他们的委托偏好，并且验证者必须有一个自动程序来加入和离开系统。这两种操作都需要一个公共链，任何用户都可以在其中提交交易。重新配置验证器还需要为每条链精心设计迁移协议。这两种机制都在第2.9节中进行了概述。

    代币授权和经济学将在单独的文件中更加精确。为了解决远程攻击——旧委员会变得腐败¹⁵——，Linera 允许微链拒绝来自不再受信任的委员会的跨链消息（例如支付）（参见第 2.9 节）。

5.2 可审计性

审计区块链传统上需要运行一个完整的节点，该节点在本地保存整个交易历史的副本。但是，在高吞吐量系统的情况下，这可能需要大量的磁盘空间和CPU资源。当普通用户（使用商品硬件的用户）需要数天或数周时间来全面审核去中心化系统时，社区可能无法可靠地阻止流氓验证者联盟更改协议。轻客户端 ¹³ 减少资源使用，但只检查块头，不提供相同级别的验证。

    相比之下，微链方法使社区可以持续审计 Linera验证器。在Linera中，审计员类似于客户端（第 2.8 节），因为它只需要跟踪一小部分微链。因为 Linera 的可扩展性依赖于拥有许多链而不是更大的块，所以在商品硬件上实时重放单个链的执行总是可行的。

    为了让Linera社区持续验证所有链，可以在共享分布式存储（例如 IPFS ³之上放置一个分布式协议，如下所示。执行链中的块允许验证执行状态和传出消息。通常应将块标记为已审核，并将传出消息在分布式存储中建立索引。要完成链的验证，客户端还必须验证每个传入消息确实是由其发送者链产生的。这可以通过在共享存储中查找传入消息以查看它们是否已经过验证来完成，否则，安排它们的验证。最后,Linera微链的分布式验证类似于经典的图索引算法，例如 PageRank ⁴。

6 结论

Linera旨在提供首个在互联网规模上具有可预测性能、响应能力和安全性的多链基础设施。为此，Linera引入了在同一组验证器中运行许多称为微链的平行链的想法，并使用每个验证器的内部网络在链之间快速传递异步消息。这种架构有很多优点：

• 弹性缩放。 在Linera中，可扩展性是通过添加链而不是通过增加块的大小或速率来获得的。每个验证者都可以随时添加和删除容量（也称为内部工作人员），以维持多链应用程序的标称性能。
• 响应能力。 当微链由单个用户操作时，Linera使用受可靠广播¹¹ 启发的简化的无内存池共识协议。这减少了块延迟并最终使Web3应用程序更具响应性。
• 可组合性。 与其他多链系统相比，低块延迟也有助于可组合性：它允许来自另一个链的异步消息的接收者通过添加新块来快速响应。
• 链安全。 与传统的多链系统相比，在同一组验证器中运行所有微链的一个好处是创建链不会影响Linera的安全模型。
• 去中性化。 Linera 依靠委托权益证明 (DPoS) 来确保安全。每个微链都可以在商品硬件上单独执行。这允许客户和审计员持续运行他们自己的验证并让验证者负责。
• 语言无关。 Linera的编程模型不依赖于特定的编程语言。经过深思熟虑，我们决定在Linera的初始执行层集中精力在Wasm和Rust上。

在未来的报告中，我们将正式化协议以支持多所有者链以及第2.9节中提到的其他扩展。特别是，我们计划利用跨链消息在我们现有的多链基础设施之上整合最新的基于DAG的共识机制¹⁸。我们还计划分别描述验证者公平报酬和用户激励的经济模型。Linera停用和存档微链的能力提供了一个优雅的场所来控制未来验证器的存储成本。总的来说，我们预计Linera的集成架构和验证器交互的最小化在优化大规模运行验证器的成本方面将非常有帮助。