销毁旧ETH，生成新ETH：V神提出以太坊2.0第二阶段方案

区块链大本营

发布于 2019-05-23 18:47:16

1.2K0

发布于 2019-05-23 18:47:16

文章被收录于专栏：区块链大本营

作者 | Will Villanueva

编译 | Jhonny

来源 | Unitimes

出品 | 区块链大本营（blockchain_camp）

最近，Vitalik Buterin围绕以太坊2.0第2阶段提出了他的第一个公开提案[1]，紧接着又提出了一个简化提案[2]：

[1]https://ethresear.ch/t/a-layer-1-minimizing-phase-2-state-execution-proposal/5397/4
[2]https://ethresear.ch/t/proposed-further-simplifications-abstraction-for-phase-2/5445

下文，作者将尝试总结提案中的内容，使读者能够及时了解这一领域的最新进展。

首先需要指出的是，阶段0到阶段2的工作并不需要按照顺序进行，每个阶段的大部分工作都可以并行进行。

本文将假定读者对以太坊2.0有一定的了解。作为起点，作者建议读者先深入了解一下以下资料：

以太坊2.0各阶段简要阐述： https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/
《谈谈以太坊 2.0 的设计目标》
《以太坊协议状态：信标链》
《以太坊2.0：什么是区块验证者？》
Sharding 发展路线图： https://github.com/ethereum/wiki/wiki/Sharding-roadmap
Justin Drake 视频解释： https://www.youtube.com/watch?v=S262StTwkmo

当前以太坊2.0起步阶段的开发分为三个阶段进行：

阶段0：主要关注信标链和构建其他阶段的基础 (如networking、签名方案、随机性等) 所需的核心部分。
阶段1：重点是独立运行1024条分片链的结构。
阶段2：重点是围绕执行引擎 (execution engine)、帐户模模式 (account model) 等。本质上，阶段2将为以太坊2.0注入活力，并开启状态执行 (state execution) 和计算 (computation)。

在Vitalik Buterin的第一个提议中，他提出了一种不同于人们最初设想的方式。他的方式是构建一个轻量级Layer 1(第一层) 协议，该协议更侧重于分片链中的Layer 2(第二层)。这里的Layer 2并不是表示Plasma或者State Channel(状态通道) 等第二层解决方案，而是侧重于以更为通用/开放的形式运行的分片链 (shard chains)。

这种方式是一种一般的范式转换，可能需要一点时间来真正理解和消化。然而，它的优势在于它提供了高度的灵活性。随着研究的继续，在未来引入系统变化应该会变得更简单。这与以太坊1.0的方式形成了对比，因为以太坊1.0将整个系统锁定在一个模式中，因此以太坊1.0系统需要在协议范围内进行重大更新才能对系统进行更改。

为了描述所有修改的部分，作者将带读者一起来了解如何将资金转移至分片链中并开始进行交易。

将 ETH 从以太坊1.0链转移至以太坊2.0链

为了将你的 ETH 从以太坊1.0旧链转移至以太坊2.0新链，你需要将你的 ETH 存储在旧链上的一个合约中。在这个合约中，你的 ETH 将被销毁。新链中有一个协议和投票周期，用于识别你的存储情况并将你的 ETH 持有情况展现在信标链上。

除了需要将你的 ETH 存入旧链上的合约中之外，你不需要做任何其他事情。当前，新链协议的投票系统会自动地将你的资金从旧链带到信标链中。随着时间的推移，即随着旧链变得越来越不活跃，这个系统可能会被另一个系统代替。但是，目前仍在讨论这种从旧链转移至新链将会是什么样。

根据现有的以太坊2.0规定，如果你在旧链的一个合约中存储了至少 32 个ETH，那你将自动成为新链中的验证者/质押者 (Validator/Staker)。

但是，可能大多数人想要的是将他们的 ETH 转移到分片链中，这样他们就可以在许多应用程序、合约或钱包中使用这些 ETH 了。在 Vitalik 的提案中，你可以通过一系列步骤来加以实现。但我们首先需要理解的是，在任何分片链之中都不存在“原生 ETH”的概念，这是很重要的。在深入讲解有关“如何将你的 ETH 转移到分片链上”的步骤之前，我们首先来了解一些背景知识。

信标链合约

信标链存储着称为信标链合约 (beacon chain contracts) 的智能合约。这些信标链合约与我们通常在以太坊1.0链上部署的智能合约不同。这些信标链合约将活跃于分片链 (shard chains) 之中。

相比于以太坊1.0中的智能合约，信标链合约将代表整个执行环境 (execution environment) 或交易框架 (transaction frameworks)。

比如，你可以通过使不同的信标链合约来代表不同的以太坊实现或框架：某个信标链合约可以代表一个基于账户的以太坊交易/存储模式，另一个信标链合约则可以代表一个基于 UTXO (未使用交易输出) 的以太坊模式。但在实践中，不应该存在过多的信标链合约，应该只有少数的几个，尤其是在前期阶段。

在上文的解释中，你可能会认为每个信标链合约都代表一个不同的虚拟机。但这种想法是不正确的。相反，信标链合约将定义/强制执行状态和纯函数 (pure functions)，这些状态和纯函数类似于在当前以太坊1.0上的预编译。

在当前的许多相关讨论中，执行者 (executor) 和执行环境 (execution environment) 也可以作为一个整体来引用信标链合约。

在以上背景知识的基础上，让我们继续下文的详解。

假设我们决定将我们的 ETH 转移到基于账户的以太坊模型，假设这个模型是在【信标链合约0】中定义的。同时，我们已经将 ETH 从以太坊1.0转移至信标链上。这样这些 ETH 就存储在验证者/staking 账户中，但我们选择不成为活跃验证者。相反，我们想让这些 ETH 出现在某条特定的分片链中。在本例中，假设我们想要在【分片链5】之中使用这些 ETH 。

为了将这些 ETH 转移至【分片链5】之中，我们需要将信标链中的 ETH 转移至【信标链合约0】中。幸运的是，信标链中引入一种称为 withdrawToContract 的全新交易类型。我们可以在这个调用中增加额外的数据。在我们的例子中，除了设置分片链号为【5】之外，我们还将账户地址包含在我们发送 ETH 的那条【分片链5】之中。我们需要发送的数据将在【信标链合约0】中定义。见下图：

实际上，这些数据会被发送到信标链中的一个收据 (receipt) 中，并由区块提议者 (block proposer) 将数据打包进入信标链区块数据中。本质上来说，信标链会在每个区块中存储一份收据清单。

现在，这些 ETH 就被锁定了，我们可以在【分片链5】中使用这些 ETH 了。在深入讲解如何索回这些 ETH 之前，让我们先深入了解一些背景信息，进一步了解分片链和信标链合约之间的关系。

信标链合约 & 状态执行

如上文所述，分片链中不存在原生 ETH 的概念。相反，你将 ETH 锁定到一个信标链合约中，就可以在分片链上使用它。为了理解这一过程，理解分片链和信标链合约之间的联系是很有必要的。本质上说，分片链及其状态执行函数 (state execution functions) 将反映和集成信标链合约中定义的框架。

在分片链的每个区块中都会生成一个全局状态 (global state)。某条分片链中的状态总是会直接映射到某个信标链合约。我们先从 Vitalik 使用的例子开始进行说明：

上图中的对象 (objects) 中的每个索引都映射到信标链合约的每个索引。如果有两个信标链合约，那么对象 (objects) 中将只有两个条目。如果基于账户的以太坊是【信标链合约0】，基于 UTXO 的是【信标链合约1】，那索引0和索引1将各自反映这两个信标链合约的状态。在每个索引中有 [StateObject, 2**256]，这只是一个具有256个字节的密钥选项的密钥-价值存储。每个 StateObject 都包含了以下字段：

随后我们再讲解 ttl，它代表了状态到期 (state expiration)，这涉及到有关租金 (rent) 的讨论。存储只是一个任意字节数组，它将由信标链合约中列出的框架来进行构造/定义。但是，最近的研究提出了一种新的方法，我们甚至可以根本不需要节点来存储状态，这意味着不需要在协议层定义严格的 ttl。对此，我们稍后会详细介绍。现在让我们先来讲解如何将 ETH 转移至分片链中！

将 ETH 转移至分片链中

信标链合约中有一个称为 depositToShard 的函数：

对上方的代码进行注释需要提供背景数据，这里不需要太深入讲解。实际上，我们只是提交了那份已经印刻在信标链之上的原始取款收据 (original withdraw receipt)。depositToShard 函数在分片中执行，并进行默克尔证明 (Merkle proof) 以确保收据的有效性。如果收据有效，那你就设置好了，新的存储状态就写入了你的账户数据中：

资金转移

现在我们在这条分片链上有了一个账户，我们就能够将一部分资金转移到另一个账户了。这很简单，只需要在这个信标链合约中添加另一个函数：

同样，这里没有必要讲解得太深入。这个函数只是减少了我们账户的余额，同时增加了收款账户的余额。需要记住的是，这些函数都是在分片的共识层中执行的。这里我们使用 BLSSignature 图解来与信标链上的当前工作保持一致。但是，这里可以使用其他签名模式。实际上，如果接收账户的存储不存在，这里应该有额外的代码来创建新账户。此时，我们图解结构得到了小小的更新：

让我们来回顾一下到目前为止上文讲到的内容。

目前的历程回顾

截至目前，我们已经将 ETH 从以太坊1.0链转移至以太坊2.0信标链中了，同时我们也将这些 ETH 锁定在一个信标链合约 (beacon chain contract) 中，该合约允许我们在【分片链5】这条分片链中使用这些 ETH。

到目前为止，我们都是简单进行阐述的。当前的框架只代表了一个有余额的基本账户模型。当然我们可以讲解的更复杂一点，并开始包含智能合约和复杂的状态执行的讲解。

在此之前，我们先了解一些基础背景，之后将讨论更为复杂的交易模型。

费用市场

在上文中，我们已经阐明了分片链没有任何原生 ETH 的概念。实际上，你的 ETH 将会根据你选择的信标链合约或框架的不同而以不同的方式出现的分片链中。这可能会让你产生几个疑问。比如，如果分片链中没有原生的 ETH，那如何向区块生产者 (block producer) 支付交易费用呢？

在上述例子中，系统会以1:1的比例来锚定信标链中的 ETH (也即用户转移至信标链中的 ETH 会以1:1的比例来出现在分片链中)。因此，区块生产者可能不会介意接受信标链合约中定义的 ETH 或者货币。

但是，这带来了更多的问题……

这是否意味着区块生产者需要使用已经建立好的每个执行环境或框架呢？区块生产者是否需要在每个信标链合约框架上确认验证、转换和安全分析，从而确保某笔交易值得去确认？对于块生产者来说，这可能会变得非常繁重，而且也完全没有效率。

这篇文章(https://ethresear.ch/t/an-optimistic-generic-gas-market-executor-for-phase-2/5429/5) 以及之后Vitalik的跟进文章(https://ethresear.ch/t/proposed-further-simplifications-abstraction-for-phase-2/5445) 对这一主题进行了深入探讨。

总的来说，这里引入了一些范式转换，这里并不是由节点来管理内存池网络，这一责任转移到许多中继者 (relayer，也称为运营者 (operator)) 之上。

如果你想要某笔交易被打包，需要将你的交易广播至一个由中继者组成的网络中，这与当前向运营内存池的节点广播交易的过程不同。这些中继者 (relayers) 将承担组织、排序和验证他们接收到的交易。他们可能会一起去组织那些最有利可图的交易，因为这些交易包含了最高的手续费。

在将一些交易组织进入一个初暂定区块 (tentative block) 中之后，中继者将预估该区块的 gas支出。在这种情况下，如果区块生产者将这些交易打包，那中继者将提供一笔他愿意支付给区块生产者的固定费用。如果这些交易被打包了，那该区块生产者就可以直接从中继者那里收取这笔费用了。

这里有很多的实现细节，我们将不深入讲解。比如，这里可能需要一个 staking 机制以确保中继者将会支付给区块生产者一笔费用。同样，可能也需要在以太坊信标链主合约或分片链合约中增加一个函数用以偿还区块生产者。当前我们还不需要担心这些，而是可以通过一个例子来简化基本过程。

我们假定某笔来自用户的交易非常简单，该用户使用【信标链合约0】：

我们假定中继者提交了一个 BlockProposal 函数 (包含了该中继者组织的一系列交易)：

依照顺序，我们将在该信标链合约中增加一个额外的函数：

其中的 process_transfer函数如下：

由于当前围绕费用和gas支付的实际账户提取模式还处于发展阶段，为了简单起见，我们只表述基本的费用，TRANSFER_GAS。

之后我们将进一步讨论如何扩展这个模型来处理实际的代码执行和账户提取 (account abstraction)。此外，上文跳过了一个小细节——作者没有描述 process_transfer 函数是如何正确执行的 (即在合约中运行额外的 wasm 代码的过程)。

我们将稍后对此进行论述，但首先让我们再增加一些复杂性，我们将讨论如何从分片链中完全移除状态的概念。

分片链不需要状态

为了更深入地了解这一概念，不妨看看Vitalik的这项简化提议 (https://ethresear.ch/t/proposed-further-simplifications-abstraction-for-phase-2/5445)。在他的文章中介绍了几个想法:

之前提及的状态或者对象 (objects) 字段并不需要在分片节点中进行维护。这一概念可能依然存在，但它存在于应用层，而不是共识层，那些对“接入到”这个特定的执行环境不感兴趣的节点并不需要注意该状态。
信标链上的交联 (crosslinks) 或登记 (checkins) 会获取压缩的状态登记 (即默克尔哈希)。

这个概念实际上可以使关于存储 ttl、poking 和 expiration 的最初讨论无效。由于没有存储状态，所以可能没有必要让协议考虑 expiration 的情况。但是，为了减少中继者网络上的存储需求，这个概念仍然可以包括在内。

本文将不会深入探讨有关无状态客户端 (stateless clients) 的概念，因为这一领域将需要大篇幅进行论述。但是本文将尽可能地进行简要总结。

在上文的例子中，你可能注意到了我们使用了一个 get_storage 函数，该函数将可能映射到一个运行时间函数 (EEI)，此函数将 ewasm (web assembly) 环境与存储在一个运行节点的本地数据库中的某个值连接起来。这将按照 EVM 操作码 SLOAD 进行操作。

无状态系统意味着你实际上不需要维护节点中的存储或状态。相反，你可以仅将见证数据 (witness data) 包含在交易中，交易中包含了所有这些函数需要获取的存储。本质上，该笔交易提交其自身的数据库，并包含交易的证明。比如，假设连接到我们的【信标链合约0】的执行环境有着以下的存储：

我们可以假设有过多的条目，并且可以对这个存储列表进行默克尔化 (merkelize)。其结果是，我们将能够从数据库中生成一个默克尔根哈希 (Merkle root hash)。我们可以只存储 Merkle 根，而不是在每个分片区块中存储整个状态。

我将在自己的交易中包含 witness_data 函数，而不仅仅只是签名。见证数据 (witness data) 将包括我的签名以及 Merkle branches，它们将用于证明在交易中我的账户当前的状态以及收款账户的状态。在交易中，这将仅仅涉及到我的账户状态和收款账户的状态。

在这种情况下，节点不再需要保存包含当前活跃存储的大型数据库，而是可以在每笔交易中使用见证数据来作为数据库。

无状态客户端是很棒的，作者建议感兴趣的读者阅读此文进行更深入的了解：

https://ethresear.ch/t/the-stateless-client-concept/172

你也许会问了，如果节点不再追踪存储状态，那用户需要自己去追踪吗？也许用户需要将之保存在本地存储中？如果用户丢失了这些数据，无法再提供 witness_data, 那会发生什么事情呢？这是否意味着他们将无法再获取自己的资金或访问自己的账户了？

这些是很棒的问题，答案也很简单。实际上，那些向区块生产者提交被提议的区块的中继者将被激励去追踪存储状态。其他类型的节点可能也会作为可供选择的第三方而存在。

此外，用户可以在本地存储自己的状态，且只有当用户丢失了自己的存储状态时才需要向第三方或者中继者寻求帮助。第三方市场或者中继者们可以通过提供这种服务收取一定的费用。本质来说，存储状态和存储费用完全可以从核心协议中移除出去。

核心协议需要的只是一个默克尔哈希 (Merkle hash) 或是其他压缩值。见证格式可以根据执行环境或信标链合约进行定义。我们依旧继续拥有灵活性。

信标链交联

每隔6分钟，每条分片链的当前区块哈希都会被检查进入信标链中。这些数据检查登记被称为交联 (crosslink)。通过交联可以确立最终性 (finality)。本质上，当独立的分片之间需要进行跨分片通信，或者信标链需要验证某条特定分片上的一个收据时，需要等待信标链上出现交联并确立最终性。此时总是可以生成一个默克尔证明，用于表明在该分片上的任何收据或交易确实发生了。我们将讨论一些关于跨分片通信的细节。

在全新的无状态模式中，我们可以使阶段0和阶段1中的实现 (implementations) 变得更加高效。我们不再需要对委员会成员 (committees) 进行单独的打乱操作 (shuffling)。

为了更深入地解释，最初的阶段0规范创建了一个长期委员会 (persistent committee) 和一个由证明者 (attester) 组成的 epoch 委员会。作为一名验证者或质押者，你将有两项任务：你将作为 epoch 委员会的一员来验证信标链中的 slots，同时你将作为长期委员会的成员来验证信标链中的 slots。

长期委员会将会在一个较长的时间段内 (约1-2周) 管理分片链上的证明、投票和验证，直到被打乱到另一个分片。另一方面，epoch 委员会将只会在一个 epoch 的一个 slot 期间对交联和某条特定分片的最终性进行投票。该委员会将每隔约6分钟进行打乱，每次打乱之后将验证一次独立的分片链交联。

现在由于我们不需要维护分片链上的存储状态(storage)，我们可以合并这两个委员会。在无状态客户端模式中，验证的时间将显著减少。现在我们可以每个1-2小时打乱一次委员会。这将带来一些额外的益处：