Eth2作为数据可用性引擎

本文的原标题是“第一阶段并完成：ETH2作为数据可用性引擎”。在发表时（2019年4月），作者打算提出一个路线图来代替ETH2.0的第2阶段，即如果只使用片段来确保数据可用性，那么这样的系统是否有用，以及需要添加哪些其他部分使其有用。令人惊讶的是，一年半前，笔者意识到，对于像ZK rollup这样的系统，底层必须保证“状态转换的执行和数据的可用性必须是原子性的”，因此底层必须具备执行能力，即使是非常简单的无状态执行。而且，（笔者还通过层层推理指出）为了保证用户体验而缺失的主要部分是手续费支付协议中关于如何对数据进行切片（这两个理解点，即使现在，甚至今天）的日子里，它仍然可以称之为前线，甚至提前。第二阶段的规范中仍然缺少手续费协议。

顺便说一下，本文的作者是eca团队的成员caseyderrio，他以前也为第2阶段提供了很多想法。他还认为ETH2.0的设计核心应该是“确保ETH1的合同可以在ETH2正常执行”。他是个被低估的开发者。

目前，限制ETH1吞吐量的瓶颈是状态增长。因此，如果我们希望独立的以太坊能增加1000倍的吞吐量。

然而，从ETH1的角度来看。X的路线，ETH1。X希望对两种资源的成本进行重大调整：存储和TX数据。目前，存储价格过低，而交易数据价格过高。这将鼓励dapp开发人员在编写合同时使用存储而不是事务数据，这将导致存储成为吞吐量瓶颈。解决这一问题的方法是提高存储定价，降低交易数据定价。通过这些成本调整，开发人员将更倾向于使用事务数据而不是存储（即，他们将编写更多的无状态合同，而不是有状态的合同）。因此，在不久的将来（如果ETH1。X的路线图被广泛采用），我们希望ETH1吞吐量受到事务数据而不是存储的限制。

如果我们假设吞吐量受事务数据的限制，那么为了扩展以太坊，serenity上的碎片不需要是有状态的。如果吞吐量受到来自无状态契约的事务数据的限制，1000个无状态切片将使吞吐量增加1000倍。

这听起来不错，但需要进行分区，按计划等待第2阶段。同时，我们可以使用阶段1作为数据可用性引擎。数据可用性引擎一词似乎越来越流行。让我们想想它是如何工作的。

以ZK rollup为例，ZK rollup受数据可用性的限制。ETH1上的ZK汇总契约能否有效地将ETH2用作桥接可用性提供者？如果在执行过程中不能同时保证数据的可用性（即验证Snark、证明和更新state root），您将得到一个类似于plaa的ZK回滚系统。尽管该系统可以极大地改善TPS，但它将引入复杂的权衡，需要处理操作员的挑战和退出机制，如等离子。在可用性挑战中，任何人都可以提供数据来证明可用性，因此不清楚将数据放入桥接ETH2碎片是否会让事情变得更简单。

现在，使用另一个版本的ZK-rollup，即500tpszk-rollup，一切都变得简单多了。不再需要指定操作员，任何人都可以随时充当中继，并生成snark证书来更新状态。事实上，数据可用性保证总是伴随着状态更新，这意味着不需要处理像plaa这样的操作员挑战和退出机制。但这需要在同一事务中执行和数据可用性保证，不幸的是，我们不能用桥接的可用性引擎来做到这一点。换句话说，桥接对于ZK rollback这样的防欺诈系统来说已经足够了，但是对于ZK rollup这样的有效性证明系统来说还不够。结论是为了简化Layer2的有效性证明，第一层可用性引擎的一个重要功能是保证数据可用性和状态转换的执行原子性地同时发生。

也许我们对此并不感到惊讶。如果仅数据可用性（不执行）是有用的，没有人会说阶段1启动只是为了确保一堆非零blob（二进制大对象）的可用性，也没有人会抱怨ETH2必须等待下一个阶段才能真正工作（除了POS）。我们尝试使用阶段1作为数据可用性引擎，但它仍然不能做任何事情，因此它令人失望。（哇，我们可以建立mastERCoin 2.0！）

那么，为什么第一阶段与执行相冲突？好吧，假设有状态的执行，每个片段都保持一些局部状态。如果验证器需要保持大量的局部状态，验证器的洗牌就要复杂得多。相反，如果不执行，你不必担心当地政府。对于验证者来说，混搭起来要容易得多，所以我们可以专注于用数据块构建碎片，然后更快地开始切分。

但我们不要假设执行是有状态的。如果我们试图使用一个非常简单的无状态虚拟机来执行操作呢？

stateid中有三个字段：新的验证器shapledeoot。另外还有一个函数process-Deploy（in-process-Transfer）。一旦代码部署完成，验证器必须确保帐户余额不低于某个阈值[至少锁定1ETH。如果代码中没有自毁，那么这部分ETH相当于销毁，代码将被**部署]。

现在，假设已经有一些帐户的代码处于全局状态。

接下来，我们尝试将一个特定的数据块打包到碎片中，但是我们该怎么做呢？据我所知，对于阶段1的片段验证器来说，决定将哪些blob打包到块中仍然是一个悬而未决的问题。假设第1阶段规范中没有指定这一点。那么，对于用户来说，如果他们想将自己的数据块打包到shard上，他们只能通过两种方式来实现：（1）联系验证者并通过协议外的方式（例如ETH1支付渠道）支付费用；（2）如果他们自己成为验证者，他们可以（当他们被随机选为块的支持者时）把它打包成碎片。两种方式都不好。

一个更好的方法是把事情摆在桌面上，允许验证者通过交易协议向当前的区块提议者支付费用。作为交换，块建议者将验证器的数据块打包到片段链上。但是，如果信标链块操作（如验证器传输）具有最小容量要求，则该方法将不起作用。如果没有允许验证者确定数据blob打包优先级的事务协议，“使用phase 1作为数据可用性引擎”的用例将无法实现（无论是通过网桥连接到信标链的ETH1合同，还是truebit、mastERCoin 2.0或我听说的其他数据可用性用例）大约在之前）。在任何情况下，我们假设无论片段支持者如何在“无执行的数据可用性引擎”模式中打包数据块，他们都可以在“简单无状态执行数据可用性引擎”中执行相同的操作。

好的，假设一个特定的数据块可以打包成块。每个块将执行限制为一个事务（例如，整个数据块必须是一个事务）。我们还没有明确表示交易是用密钥（有交易协议）还是没有（没有交易协议）。假设是后者，代码实现了自己的签名检查（类似于账户提取；有一个区块天然气上限，但没有费用转移机制，因此没有天然气价格和gaspy操作码）。如果blob可以成功地解码为一个事务，那么目标帐户代码将以数据和当前状态根作为输入执行。如果执行成功，则返回的数据是新的状态根。

如何更新验证器帐户的stateroot？我们不能更新每个块的信标状态中的状态根（因为信标链操作的数量是严格限制的）。但是，信标链状态中的片段字段将使用交叉链接进行更新。获取同一分区中所有帐户的更新后的状态根，并假设它们经过哈希处理以获得shard_ustate_uroot（fragment state Root）。shard_ustate_uRoot似乎与第一阶段设计中的现有交叉连接兼容，而data_uroot几乎相同（两者都取决于之前块内容的哈希值）。

不可否认的是，不是每次一个信标链块被挖矿时，所有的碎片状态根都会被更新，因此存在一些局部状态。但是，如果帐户是全局的，则状态根数据将最小化。这类似于在清洗过程中需要在验证器之间传输的数据。

当然，这里忽略了很多细节。我想表达的是，无状态执行的大多数需求似乎在第一阶段就得到了满足。在我看来，**的问题是不清楚用户如何将他们的blob打包到链上（如果这个问题不解决，第一阶段就不会是一个桥接可用性引擎）。也许这只是第一个问题。我忽视了其他严重的问题。我错过了什么？如果您想让用户在第一阶段以某种方式将blob打包到链上，最困难的部分是什么（如果您愿意，也可以称为阶段1.1）？

这个执行模比第2阶段的建议更简单，因为合同帐户是全局的，就像验证器帐户一样。这意味着合同帐户的数量必须有一个上限，并且部署代码的成本与作为验证器的成本一样高（而且可能低于）。但如果这允许我们更快地将执行引入ETH2，我们能接受这种折衷吗？部署代码后，无法更改协定存储区。因此，可以说，我们试图在不扩展合同存储的情况下为阶段1提供执行功能。这是另一个重要的用例：具有数据可用性的超高吞吐量（将事务吞吐量提高1000倍）。

即使是基本的无状态执行，用户也可以将一个契约的状态证明作为事务数据发送给另一个契约，从而实现跨分区的契约调用。同样，收据也可以在“收据”字段中实现自己的“收据”功能。开发人员的体验不是很好，因为协议没有帮助。然而，现有的第2阶段方案似乎缺乏促进跨分片合同交互的实用功能（这些麻烦留给了DAPP开发者，他们必须实现从不同碎片获取收据的逻辑，并确保收据中没有双花等）。因此，从开发人员的经验来看，基本的第一阶段无状态执行听起来并不比“简单”的第二阶段的想法差多少。基本的无状态执行也足以实现信标链上的BETH和主链上的ETH之间的双向锚定。

第2阶段的建议和我们这里的建议**的区别是，第2阶段的目标是扩展合同的存储。但是存储以及相应的有状态执行似乎也是大部分复杂性的来源，这就是为什么我们没有希望在第一阶段引入执行。