1kx:区块链扩容的终局是信任最小化和水平扩展

为了真正将区块链扩展到地球上的每个角落,我们需要构建信任最小化和水平可扩展的系统。

撰文:weidai.eth
编译:Luffy,Foresight News

以太坊是一种无需许可的世界计算机,在撰写本文时,它拥有最高的经济安全性,并且充当着大量资产、应用程序和服务的结算账本。以太坊也有其局限性:区块空间是以太坊主网上稀缺且昂贵的资源。L2 扩容被认为是这个问题的最佳解决方案,近年来有大量项目进入这个领域,其中大多数是 Rollup。然而,从严格意义上的术语 Rollup(数据位于以太坊 L1 上),并不能实现以太坊的无限扩展,它的上限是每秒处理几千笔交易。

首先,请了解一下两个概念:

  • 信任最小化:如果 L2 系统的功能不需要信任底层 L1 之外的部分,那么这个系统(的一个功能)就是信任最小化。

  • 水平扩展:如果可以在不造成全局瓶颈的情况下添加实例,那么系统就是水平可扩展的。

在这篇文章中,我们认为信任最小化和水平可扩展的系统是扩展区块链应用程序最有前途的方式,但这个方向目前尚未被充分探索。我们通过探讨三个问题来得出论点:

  • 为什么应用程序应该是信任最小化的?

  • 为什么要构建可水平扩展的系统?

  • 我们如何才能增强信任最小化和水平可扩展性?

声明:虽然本文重点关注以太坊作为基础 L1,但我们在这里讨论的大部分内容也适用于以太坊之外的其它去中心化结算层。

为什么应用程序应该是信任最小化的?

应用程序可以以可信的方式连接到以太坊,它们可以写入和读取以太坊区块链上的数据,但需要信任的地方在于业务逻辑会被正确执行。币安和 Coinbase 等中心化交易所是可信应用程序的绝佳示例。连接到以太坊意味着应用程序可以利用具有多种资产的全球结算网络。

受信任的链下服务存在重大风险。 2022 年主要交易所和服务商的崩溃(例如 FTX 和 Celsius)是一个很好的警示故事,讲述了当受信任的服务行为不当和失败时会发生什么。

另一方面,信任最小化的应用程序可以以可验证的方式写入和读取以太坊,例如 Uniswap 等智能合约应用程序、Arbitrum 或 zkSync 等 Rollup 以及 Lagrange 和 Axiom 等协处理器。从广义上讲,随着应用程序受到以太坊网络的保护,并且更多功能被分配给 L1,信任就会被消除。因此,可以在没有交易对手或托管人风险的情况下提供信任最小化的金融服务。

将功能外包给 L1,应用程序和服务可以获得三个关键属性:

  1. 活性(和排序):用户提交的交易应及时包含(执行和结算)。

  2. 有效性:交易按照预先指定的规则进行处理。

  3. 数据(和状态)可用性:用户可以访问历史数据以及当前应用程序状态。

对于上述每个属性,我们可以想到需要什么信任假设;特别是,以太坊 L1 是否提供该属性或是否需要外部信任。下表针对不同的架构范例进行了分类。

为什么要构建可水平扩展的系统?

水平扩展是指通过向系统添加独立或并行实例进行扩展,例如应用程序或 Rollup。这要求系统不存在全局瓶颈。水平扩展可以实现系统吞吐量的指数级增长。

垂直扩展是指通过增加整体系统(例如以太坊 L1 或数据可用性层)的吞吐量来进行扩容。当水平扩展在诸如共享资源上遇到瓶颈时,通常需要垂直扩展。

声明 1:Rollup 无法水平扩展,因为它们可能会遇到数据可用性 (DA) 的瓶颈。垂直扩展 DA 解决方案需要在去中心化方面做出妥协。

数据可用性 (DA) 仍然是 Rollup 的瓶颈。目前,每个 L1 区块的最大容量目标为 1 MB (85 KB/s)。从长远来看,EIP-4844 将额外提供约 2 MB (171 KB/s) 的可用空间。通过 Danksharding,以太坊 L1 最终可能支持高达 1.3 MB/s 的 DA 带宽。 以太坊 L1 DA 是许多应用程序和服务共同竞争的资源。因此,尽管使用 L1 作为 DA 可提供最佳的安全性,但它会成为系统潜在可扩展性的瓶颈。使用 L1 作为 DA 的系统(通常)无法水平扩展,并且存在规模不经济。替代性 DA 层,例如 Celestia 或 EigenDA,也有带宽限制(尽管较大,分别为 6.67 MB/s 和 15 MB/s)。但这是以将信任假设从以太坊转移到另一个(通常不太去中心化)网络为代价的,从而损害了安全性。

声明 2:水平扩展信任最小化服务的唯一方法是实现(接近)每笔交易的边际 L1 数据为零。两种已知的方法是状态差异 Rollup (SDR) 和 validiums。

状态差异 Rollup (SDR) 是将一批聚合交易中的状态差异发布到以太坊 L1 的 Rollup。对于 EVM,随着交易批次变大,发布到 L1 的每个交易数据会逼近一个常数,远小于 Rollup 的交易数据。

例如,在铭文大量涌入的压力测试事件中,zkSync 发现每笔交易的 calldata 减少至 10 字节。相比之下,对于正常流量,Arbitrum、Optimism 和 Polygon zkEVM 等 Rollup 每笔交易大约 100 字节。

validium 是一个将状态转换的有效性证明发布到以太坊的系统,无需关联的交易数据或状态。即使在低流量条件下,Validium 也具有高度水平可扩展性。而且不同 validium 可以共享结算层。

除了水平可扩展性之外,validium 还可以提供链上隐私(来自公共观察者)。具有隐私 DA 的 validium 拥有中心化和门控的数据和状态可用性,这意味着用户必须在访问数据之前进行身份验证,并且运营商可以实行良好的隐私措施。这实现了类似于传统网络或金融服务的用户体验:用户活动不受公众监督,但存在一个需要信任的用户数据托管人,在本例中为 validium 运营商。

中心化排序器与去中心化排序器呢?为了保持系统的水平可扩展性,独立排序器(无论是中心化排序器还是去中心化排序器)至关重要。值得注意的是,尽管使用共享排序器的系统具有原子性可组合性,但它们无法水平扩展,因为随着添加更多系统,排序器可能成为瓶颈。

互操作性呢?如果水平可扩展的系统都在相同的 L1 结算,则它们可以在无需额外信任的情况下实现互操作,因为消息可以通过共享结算层从一个系统发送到另一个系统。运营成本和消息传递延迟之间需要进行权衡(这可以在应用层解决)。

水平可扩展系统的信任最小化

我们能否进一步最小化水平可扩展系统中对活性、排序器和数据可用性的信任要求?

值得注意的是,以水平可扩展性为代价,我们知道如何挽救无需信任的活跃性和数据可用性。例如,L2 交易可以从 L1 发起以保证被包含。 Volition 可以为用户提供选择加入的 L1 状态可用性。

另一种解决方案是简单地去中心化(但不依赖 L1)。通过使用去中心化排序器(例如 Espresso Systems 或 Astria),而不是使用单个排序器,系统可以变得更加去中心化,从而最大限度地减少活性、排序和数据可用性所需的信任。与单个运营商的解决方案相比,这样做存在局限性:(1) 性能可能受到分布式系统性能的限制,(2) 对于具有隐私 DA 的 validiums,如果去中心化排序器网络是无许可的,则默认的隐私保护会丢失。

对于单个运营商 validiums 或 SDRs,我们还可以减少多少信任依赖?这里有几个方向。

方向 1:validiums 中信任最小化的数据可用性。 Plasma 在一定程度上解决了状态可用性问题,要么是某些特定状态模型(包括 UTXO 状态模型)的提现问题,要么要求用户定期在线(Plasma Free)。

方向 2:SDR 和 validiums 中的负责任的预确认。这里的目标是为用户提供排序器包含交易的快速预确认,并且如果包含承诺没有兑现,应该允许用户发起挑战并对排序器实施权益惩罚。这里的挑战是证明交易未被包含,这可能需要用户提供额外的数据,而排序器可以简单地保留这些数据。因此,我们可以合理假设,我们至少要求 SDR 或 validium 为其完整的 calldata 或交易历史雇用一个数据可用性委员会,委员会能够根据用户请求提供不包含(预确认交易)的证明。

方向 3:从活性故障中快速恢复。单个运营商系统可能会遇到活性故障(例如 Arbitrum 在铭文事件期间宕机)。我们能否设计出一个在类似情况下不会服务中断的系统?从某种意义上说,允许自我排序和状态提议的 L2 确实提供了防止长期活性故障的保证。对短期活性故障更具弹性的单个运营商系统目前尚未被充分探索。这里的一种潜在的解决方案是通过对活性故障进行削减来追究相关责任。另一个可能的解决方案是简单地缩短接管之前的延迟期(目前设置为一周左右)。

结论

在保持信任最小化的同时扩展全球结算账本是一个难题。在当今的 Rollup 和数据可用性领域中,垂直扩展和水平扩展之间还没有明显的区别。为了真正将信任最小化系统扩展到地球上的每个角落,我们需要构建信任最小化和水平可扩展的系统。

非常感谢 Vitalik Buterin 和 Terry Chung 的反馈和讨论,以及 Diana Biggs 的编辑评论。

Subscribe to Foresight News
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.