Vitalik:Layer 1 及 layer 2 的设计权衡


区块链设计的关键权衡之一:是将更多功能构建于基层区块链自身( “layer 1” ),还是将其构建于位于区块链之上的协议中,这些协议可在不更改区块链自身的情况下,进行创建和修改( “ layer 2 ” )?

目前为止,这种权衡在扩展性相关争论中,表现最为明显,一方是提升区块大小(和 分片 );另一方是 layer-2 解决方案,如 Plasma 和 channels 。某种程度上,其还表现于区块链治理,如用以解决丢失和盗窃恢复(loss and theft recovery)的 the DAO fork  或 EIP 867 ,或 layer-2 解决方案(如 Reversible Ether (RETH))。哪种方法最终更好?那些了解我或将我视作一个中间派(dirty centrist)的人,都知道,我将不可避免地说“两者兼有一些”( “some of both”)。

然而,从更长远来看,我确实认为,随着区块链越来越成熟,layer 1 将必然稳定, layer 2 将承担越来越多的持续创新和变更的重担。

原因有几个。

首先, layer 1 解决方案,需要在基础协议层,进行持续的协议更改,基础层协议变更需要治理,但是,还没有迹象显示,高度“激进”(highly “activist”)的区块链治理,能够长期持续下去,而不会造成持续的政治不确定性或崩溃至中心化。

以另一个领域为例,考虑 Moxie Marlinspike 对信号(Signal)中心化和非联合性(non-federated nature)的维护(Moxie Marlinspike’s defense of Signal’s centralized and non-federated nature)。对于一家公司为其关键业务,维护其所依赖的生态系统的控制权,而撰写的一份文件,对其观察,当然应该有所保留,但仍可从其辩论获得一些有益之处。引用:

早先,我们对 Signal 所做的有争议事之一:把它建成一个非联合服务( unfederated service )。我们所已开发的任何协议都不需要中心化(Nothing about any of the protocols we’ve developed requires centralization);完全有可能建立一个基于联合信号协议的信使( federated Signal Protocol-based messenger ),但我不再认为,有可能建立一个有竞争力的联合信使( federated messenger )。

以及:

他们的反驳是:“这太愚蠢了,如果没有第三方所定义的互操作协议,互联网能走多远?”这我想过。我们实现 IP 的第一个生产版本 ,且在过去 20 年里,一直尝试切换到 IP 的第二个生产版本,但收效甚微。在 1997 年,我们得到了 HTTP version 1.1,目前还停留在那个版本。同样地,大约在 1990 年代末,SMTP、IRC、DNS、XMPP 等也同样被冻结了。回答他的问题,互联网能走多远?到 1990 年代末。

这已经带我们走得很远,但不可否认的是,一旦你联合( federate)你的协议,就很难做出改变。而现在,在应用层,在生态系统正在不断变动的一个世界中,停滞不前的事情并不是很好......只要联合(federation)意味着停滞,中心化意味着变动(So long as federation means stasis while centralization means movement,),在需要变动( demands movement )的软件环境中, 联合协议(federated protocols )就会存在问题,就像今天这样。

在这个时间点,以及在此之后的中期内,显而易见的是,去中心化应用平台,加密货币支付,身份系统,声誉系统,去中心化交易机制,拍卖,隐私解决方案,支持隐私解决方案的编程语言,以及大多数其他可以在区块链上完成的有趣事情,是那些将继续进行重大和持续创新的领域。去中心化应用平台,通常需要确认时间的持续减少;支付需要快速确认,低交易成本,隐私和许多其他内置功能;交易所以许多结构和规模出现,包括链上自动化做市商( on-chain automated market makers),频繁的批量拍卖组合拍卖等。

因此,将任何这些内置于一个基层区块链,都是一个坏主意,因为当平台将不得不持续的讨论、实现和协调新发现的技术改进,它将带来一个高层级的治理开销。出于同样原因,如果没有重新中心化(without re-centralizing),联合信使( federated messengers )很难起步,区块链还需要在“采取具有危害性的激进治理”,和“落后于新出现的替代方案”之间,做出选择。

即使是在以太坊有限层级的特定于应用的功能,预编译( application-specific functionality, precompiles)上,也看到一些这样的效应。不到一年前,以太坊采用拜占庭硬分叉,操作包括促进 ring signatures,ZK-SNARKs 及其它应用所需的 elliptic curve operations ,使用 alt-bn128 curve 。现在,Zcash 和其他区块链正在朝向 BLS-12-381 ,而以太坊需要再次分叉才能赶上。为了避免将来出现类似问题,以太坊社区正在寻求将 EVM 升级到 E-WASM,这是一种足够更有效率的虚拟机,很少需要整合特定于应用的预编译(application-specific precompiles)。

但也有支持 layer 2 解决方案的第二种观点,该观点不决定于预期技术开发速度(there is also a second argument in favor of layer 2 solutions, one that does not depend on speed of anticipated technical development ):有时存在不可避免的权衡,没有单一全局最优解决方案。这在以太坊 1.0 风格的区块链中,不太容易看见,其中某些模型具有合理普遍性(例如,以太坊的基于账户的模型就是其中之一)。然而,不存在于今天以太坊中的一类问题突然出现:如何进行跨分片(cross-shard )交易? 即,假设区块链状态具有区域 A 和区域 B,其中很少或没有节点同时处理 A 和 B 。系统如何处理“同时影响 A 和 B ”的交易?

当前解决方案涉及异步跨分片( asynchronous cross-shard )通信,这对于转移资产和其他一些应用来说,已经足够了,但是对于其他许多应用来说,还不够。同步操作(比如,解决火车和酒店问题) 可用跨分片 yanking 固定在顶部( Synchronous operations (eg. to solve the train and hotel problem) can be bolted on top with cross-shard yanking ),但这需要多轮跨分片交互,导致明显延迟。我们可以通过同步执行方案来解决这些问题,但需要一些权衡:

  • 在每个区块,系统无法为同一帐户处理多于一笔交易( The system cannot process more than one transaction for the same account per block )
  • 交易必须事先声明,它们所影响的分片和地址
  • 如果交易只被它所影响的一些分片接受,而其他分片不接受,那么,任何给定交易失败(仍然被要求支付费用!)的风险很高。

似乎很可能会开发出一个更好方案,但它可能会更复杂,并且很可能具有以上方案所没有的局限性。已知结果阻止完美( There are known results preventing perfection);至少,Amdahl’s law,严格限制了某些应用和某些类型的交互,通过并行化每秒处理更多交易的能力。

那么,我们如何创建一个环境,以此,更好方案可以得到测试和部署?答案是一个可归属于 Justin Drake 的想法:layer 2 执行引擎(layer 2 execution engines)。用户可将资产发送到一个“桥接合约”(bridge contract),为了处理区块链,这个桥接合约将使用一些替代规则,计算(使用某些间接技术,如交互式验证ZK-SNARKs )状态根(state roots)(将这个过程视为等效于 layer-two “meta-protocols”,就像 Bitcoin 上的 Mastercoin / OMNI Counterparty ,不是因为桥接合约,是因为这些协议将能够处理一些资产,这些资产的“基本分类账”在底层协议上进行确定),并且,桥接合约当且仅当替代规则集生成“撤回”请求(withdrawal request)时,才处理“撤回”。

请注意,任何人都可随时创建 layer 2 执行引擎,不同用户可以使用不同的执行引擎,并且,可以非常快速地从一个执行引擎,切换到任何其他执行引擎或基层协议。基层区块链,不再需要担心如何成为最佳智能合约处理引擎;它只需要是一个准图灵完备的拥有执行规则的数据可用层(a data availability layer with execution rules that are quasi-Turing-complete ),这样,任何 layer 2 桥接合约都可在其上构建,并允许基本操作在分片之间传送状态(事实上,只有跨分片可互换的 ETH 传输足够,但是仅需要花费很少力来允跨分片调用,所以我们可能也可以支持它们 in fact, only ETH transfers being fungible across shards is sufficient, but it takes very little effort to also allow cross-shard calls, so we may as well support them),但除此之外,不需要复杂性。还要注意,layer 2 执行引擎,可具有与 layer 1 不同的状态管理规则,例如:没有存储租金(not having storage rent);任何事情都会发生,因为该特定执行引擎的用户有责任确保它是可持续的,如果他们未能这样做,后果将由该特定执行引擎的用户承担(the consequences are contained to within the users of that particular execution engine)。

长期而言,layer 1 不会积极参与所有这些改进; 它只是为 layer 2 创新提供一个稳定平台。这是否意味着,比如,分片是一个坏主意,我们应该将区块链容量和状态保持在“小”,这样,即使是 10 年历史的旧电脑也能处理每个人的交易?绝对不是。

即使执行引擎部分或完全转移到 layer 2,对数据排序和可用性的共识,仍然是一个高度可通用(generalizable)和必要的功能。要了解,如果没有 layer 1 可扩展数据可用性共识,layer 2 执行引擎会有多困难;要了解 Plasma 研究中的困难,以及将其自然扩展到完全通用区块链的困难。如果人们想要将 100mb / s 的数据放入一个系统,他们需要对此系统的可用性达成共识,然后,我们需要一个 100mb / s 的数据可用性共识( if people want to throw a hundred megabytes per second of data into a system where they need consensus on availability, then we need a hundred megabytes per second of data availability consensus)。

此外,layer 1 仍然可在减少延迟方面进行改进;如果 layer 1 缓慢,那么,实现非常低延迟的唯一策略是状态通道,状态通道通常具有高资本要求(high capital requirements ),并且可能难以普及( difficult to generalize )。状态通道将总是打败处于延迟中的 layer 1 区块链,因为状态通道需要的只是一单个网络消息(state channels require only a single network message),但在状态通道不能很好工作的那些情况中,layer 1 区块链仍然可以比现在做得更好(layer 1 blockchains can still come closer than they do today)。

另一种极端观点是,区块链基础层可以真正绝对最小,并且不再遭受“使用准图灵完备的执行引擎( a quasi-Turing-complete execution engine),或超出单个节点容量的可扩展性”之扰,这个观点显然也是错误的;基础层所需要的某种最小程度的复杂性(complexity),要足够强有力,可使应用建于其上,而我们还没有达到这个水平。额外复杂性是需要的,尽管应该非常小心地选择这种复杂性,以确保它具有最大程度的通用性,而不是针对特定应用或技术——那些将在两年内因为兴趣或利益的失去(loss of interest)或更好替代品的出现而过时的特定应用或技术。

甚至在未来,基础层将需要持续进行一些升级,特别是如果新技术( 如 STARK 达到更高的成熟度),允许它们实现比以前更强的性能,尽管今天的开发者,是可小心翼翼地使基层平台,最大限度地向前兼容这些潜在改进。因此,为了继续提高可扩展性、隐私性和多功能性(versatility),需要在 layer 1 和 layer 2 的改进之间保持协调,这将继续是事实,尽管随着时间推移,layer 2 将持续占据越来越大的创新份额。

2018.08.29 更新: Justin Drake 向我指出了另一个很好理由,为什么一些功能在 layer 1 实现可能是最好的:这些功能是公共产品(public goods),因此无法通过特定功能的使用费,来对其进行有效或可靠资助,因此最好是通过补贴(subsidies)来对其进行支付,这些补贴来自发行,或烧毁的交易费(are best paid for by subsidies paid out of issuance or burned transaction fees)。其一个可能例子是安全随机数生成(secure random number generation)。

译文仅供参考。

原文:https://vitalik.ca/general/2018/08/26/layer_1.html
作者:Vitalik Buterin
编译:古拉,东林
校对:东林