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
编译：古拉，东林
校对：东林