Ethereum to PoS即将到来，本文全面了解以太坊扩容历史

审稿人：杰克逊（推特：0xOar）

标题：以太坊的扩张之路

不管你是不是区块链技术专家，只要你在加密世界呆得够久。 Ethereum expansion、layer2、Rollup 这几个词大家耳熟能详。 许多人都熟悉这些概念中的一个或多个，但它们之间有何关联？ 为什么我们需要这些技术？ 他们试图解决什么样的问题？

如果你想知道以上问题的答案，希望这篇文章对你有所帮助：

本文所有内容都是逻辑梳理的，不会涉及密码学/计算机科学方面的知识，所以相信大家只要熟悉以太坊本身，就可以基本看懂。

自从 CryotoKitty 造成以太坊链拥堵的那一天起，以太坊开发者就一直在探索提高以太坊吞吐量的方法。

原则上可以分为两类

: 就是对以太坊区块本身进行改造，姑且称之为Layer1方案，这里主要的方案是sharding。

: 就是改变我们使用以太坊的方式，把交易的执行和处理放在链下。 以太坊本身仅用于验证其交易的有效性并提供安全性。 这就是我们经常听到的Layer2。

Layer2的核心思想是在链下执行和计算大量的实际交易，然后通过以太坊上极少量的交易来验证交易的最终有效性。 无论是State Channel、Plasma还是Rollup，都遵循这个原则。

现在说到Layer2，很多人的第一反应是会和Optimistic/ZK Rollup联系起来，但是这里简单介绍一下状态通道和Plasma，有助于我们理解为什么Rollup最终胜出，成为最受关注的layer现在。 Layer2解决方案：

一：状态通道

下面是一个状态通道最原始的结构：

状态通道是一种由来已久的区块链扩容解决方案，最著名的应用就是比特币的闪电网络。

1：例子

与其描述他的原理，不如举个例子更清楚地说明什么是状态通道：

你很喜欢楼下的理发店。 每次去理发店，托尼先生总会让你在耳边办个卡。

哪天你终于决定了，办卡就行了，反正我以后会来的。 于是你转账1000元到理发店办了一张卡。

以后每次去理发，都不用再去理发店转账了。 相反，您卡中的余额将被扣除。 同时，你每次理发都完成了一次与理发店的实际交易。

一个月后，你要搬家了，但你卡里的钱还没用完。 于是你向理发店申请退卡，理发店的托尼先生给你退了200元。

这一个月里，你在理发店消费了十几次，但你和理发店实际上只互相转过两次钱。

把这个过程放到区块链上，买卡的过程其实就是把钱存入智能合约，同时在你和理发店之间打通状态通道。 退卡的过程会关闭您和理发师之间的“状态通道”。 你和理发店之间的相互转账相当于以太坊主链上的两笔交易。

想象一下，你没有卡，每次剪完头发都需要去理发店转账。

通过这个例子，我们发现通过状态通道，只有第一步和最后一步需要我们在区块链上进行交易。 在这些步骤之间，您和理发店可以向对方发送无限数量的签名消息（以完成一次消费），表示已付款。 在这种情况下，以太坊区块链仅作为结算层处理一次性支付的最终交易，大大减轻了底层区块链的负担。

2：应用场景

状态通道在流式支付等一些简单的场景中可以起到非常重要的作用。 它通过对链下消息进行签名来记录交易数据，将大量已经发生的交易从逻辑上简化到主链中。 两笔交易。

(2) 由于成本低，状态通道非常适合一些小额支付的场景，比如用ETH或者BTC购买早餐咖啡。

3：局限性

但同时，状态通道需要资金的发送方和接收方都进入这个通道，为了维护状态通道，支持比流式支付更复杂的操作，需要锁定大量的资金。 因此，开发者很快意识到状态通道不能作为可选的扩展方案之一。

二：等离子

1：原则

现在大家都知道状态通道的局限性了，为了解决这个问题。 ——等离子体应运而生。 解决了向任意目标人发送资产的问题，同时可以保证TPS的提升。 事实上，在开发者开始研究 Layer2 解决方案的很长一段时间里，Plasma 一度被认为是“那个”。

要理解 Plasma，首先要明白它不是一种实际的技术，它更像是一种设计思想或技术架构。

Plasma 通常是一条链，可以有与主链不同的共识机制，也可以有自己的矿工。 但最重要的是，Plasma 链上会有一个叫做“Operator”的角色，根据子链上的状态变迁，周期性地生成一颗 Merkle 树，并提交 Merkle 树的根哈希值验证并记录主链。 为什么 Merkle 树和它们的根哈希可以用作状态转换的验证将在 Rollup 中讨论，它也使用了这个应用程序。

这样无论两次提交期间子链上发生了多少笔交易，子链只需要将交易执行引起的状态信息提交给主链即可。

下面是使用 Plasma 机制的简单示意图：

用户想要进入 Plasma 链需要在以太坊主链上映射资产，当他们需要在 Plasma 链或主链上转移资产时，需要经过一段挑战期让他人使用“欺诈证明” " 确认资产转移有效性的机制。

“Fraud Proof”是指在这个挑战期限内（通常为7天或更长），任何人都可以提交一个Merkle树验证方法来证明用户资产的提取是非法的。

2：问题

但这会产生两个问题：

(1) 如果要验证本次取款的正确性，需要一个节点保存Layer 2的交易和状态信息，因为Plasma只会提交其状态转移的结果，你必须有Layer 2的信息提交欺诈证明，这将大大增加验证者角色的成本。

也就是所谓的“数据不可用”，就是说 Plasma 不会将自己链上的交易数据发送到主链上进行存储。 主链的节点无法获取这些交易数据，也无法通过主链本身的安全性。 验证它。 当然，有些方案会将这些数据提交到中心化存储或者IPFS，但这对主链来说没有任何意义以太坊转pos是利好吗，因为用户使用Layer 2的基础是信任主链本身的安全性。

三：汇总

我们可以看到 Plasma 一个很重要的问题就是它的“数据不可用”。 主链只会收到 Operator 提交的状态转移结果，它只能期望有人已经将交易和状态信息存储在链下。 证明机制用于保证子链提交的真实性。 在此过程中仅承担确认者的角色，安全级别较差。

1：详细了解“数据不可用”

以太坊将其链上发生的所有数据公开，所有人都可以查询。 但是，Plasma 并不将这些交易数据提交给主链，而只是提交执行结果，因此其效率大大提高，但这样做的代价是 Plasma 无法建立与以太坊主链同等水平的信任。

Rollup其实可以看作是原主链处理方式和Plasma方式的折衷。 它会向主链提交数据，但是会通过巧妙的编码方式最大限度的压缩这些数据，同时根据Rollup本身的特点适当删除和减少部分数据，只要最后提交任何人都可以验证。

交易数据上传到链上后，任何人都可以根据这些数据验证 Rollup 提交的结果是否正确。 因此以太坊转pos是利好吗，Rollup 比 Plasma 更安全。

综上所述，Rollup 的核心优势就是所谓的“数据可用性”，将数据提交到主链，大大增强了安全性。

那么 Rollup 到底是如何实现的呢？

2：原理

状态根

首先，Rollup 在主链上有一个（或一系列相互关联的）合约：

该合约用于维护 Rollup 层中的状态记录。 这个状态记录实际上是一个存储在 Merkle 树根节点的哈希值。 这个哈希值被称为状态根。

而这棵 Merkle 树的叶子节点就是 Rollup 中的账户状态信息。 如果你不知道 Merkle 树是什么，这里有一个简单的例子：

可以看出这是一棵二叉树，二叉树的叶子节点上记录了当前rollup层账户的状态信息。

对于每两个状态信息（比如State 1/State 2），我们可以根据一定的哈希公式计算出一个唯一的哈希值（比如：Hash(1,2)）作为这两个叶子节点的父亲节点，其中一个是一个，以此类推，最后得到一个存储在根节点的hash值：

你不需要知道如何计算散列，你只需要记住一些事情。

1 任何叶子节点的变化都会导致根节点的值发生变化（任何状态变化都会导致Root hash发生变化）

2 如果两棵树的根哈希值相同，说明它们的叶子节点存储的信息是完全一样的（所以只需要比较两个根节点的哈希值就可以确认底层状态信息的一致性）

3 根据根节点的哈希值和到某个状态信息的路径，我们可以确认这个哈希树中存在某个状态信息。

批

通过状态根，我们可以得到账户状态的键值映射：

key为账户地址，value包含balance/Nonce/contract code/storage等状态信息（针对合约账户）

当交易发生在 rollup 上时，很明显，这些账户的状态会发生变化，从而产生一个新的状态根。

虽然这可以非常准确及时地反馈 Rollup 上的最新状态变化，但是如果每次交易发生时都在主链上更新状态根，所产生的成本将高于在 Layer1 上执行这些交易的成本。

因此，为了解决这个问题，rollup中产生的交易会被分批打包聚合，并在这批交易全部执行完后，根据状态生成一个新的状态根。 无论是谁向主链上的智能合约提交交易包，都需要计算这个新的状态根，连同之前的状态根和交易数据一起提交。

这部分包装称为“一批”。 提交者将批次提交到 Rollup 合约后，主链会验证新的状态根是否正确。 如果验证通过，状态根将更新为最新提交的状态根。 并最终在一个 rollup 中完成状态转移确认。

Rollup 的本质

以下是 Optimstic Rollup 流程的简化版本。 可以看出，与 Plasma 最大的区别在于增加了交易数据提交。

因此，Rollup 的本质是将大量实际产生的交易聚合成主链上的一笔交易。 这些交易由 Rollup 链执行和计算，但数据会提交给主链，主链将作为“最高法院法官”的角色最终确认这些交易。因此，我们利用主链的共识和安全性，同时提高实际交易效率，降低交易成本。

3：怀疑

看完上面的描述，你可能会有一些疑问，别着急，我们会一步步推导讲解。

如果提交了全量的交易数据，还是很难扩容吧？ 上面提到的数据压缩是否解决了这个问题？ 你怎么做呢？

这两种技术方案都可以实现扩展，核心是交易的压缩和打包。 这是因为以太坊的 block gas limit 是有上限的。 压缩后的交易越小，一次可以提交到主链的交易就越多。 那么该怎么做呢？

下面是Vitalik在他的文章中描述的一种压缩模式，作为例子帮助我们理解

以太坊主链上的一个简单交易（比如发送 ETH）通常会消耗大约 110 个字节。 然而，在 Rollup 上发送 ETH 可以减少到大约 12 个字节。

要达到这样的压缩效果，一方面采用了更简单高级的编码方式，以太坊目前的RLP在每个值的长度上浪费了1个字节。 另一方面，有一些简洁的压缩技巧：

Nonce：在rollup中可以完全省略nonce

Gasprice：我们可以让用户以固定范围的gasprice来支付，比如2的16次方

Gas：我们还可以将gas设置为2的倍数。此外，我们还可以在batch级别设置gas limit。

To：地址可以通过Merkle树上的索引来标识

值：我们可以用科学记数法存储值。 在大多数情况下，转账只需要 1 到 3 位有效数字。

签名：我们可以使用BLS聚合签名，将多个签名合并为一个

这些压缩技术是 rollup 扩展的关键。 如果我们不对交易数据进行压缩，rollup 可能只能在主链的基础上提高 10 倍左右的效率，但是通过这些压缩技术，我们可以达到 50 倍 100 倍甚至更高的压缩效率。

同时，为了节省gas，这些压缩后的交易数据会存储在calldata参数中。 著名的EIP-4488提出降低calldata中每字节数据的gas消耗，以进一步优化主链交易可承载的roll层交易数据量。 具体的压缩效果，我们在下面比较两种不同的ZK-Rollups时会给出简单的数据。

如何验证提交的可验证信息是否正确？

由于最终的状态转移确认（也代表交易的确认）是由状态根的更新决定的，但是Rollup上的提交者似乎可以随意提交他想要的交易数据和状态根，那么如何验证他提交的信息是否正确？

对于这个问题，一般有两种解决方案，根据不同的解决方案，rollup也分为两类：

4：乐观汇总

顾名思义，这个解决方案选择乐观地相信提交者提交的批次是正确的，除非有人通过欺诈证明证明提交者实际上是提交错误批次的坏人。

(1) 下面是一个简单的欺诈证明构建示例（再次感谢 Vitalik）：

提交欺诈证明以证明提交的批次是错误的，需要下图绿色部分包含的信息：

提交者提交的批次

前一个状态根代表的Merkle树的一部分（实际代表真实账户状态信息），基于此可以构建完整的Merkle树

基于第二部分构建的Merkle树，我们模拟了批量提交交易的执行，从而得到一个新的账户状态，一个新的Merkle树，一个新的状态根。

将上一步得到的状态根与batch中的state root进行比较，验证batch是否正确

验证过程

我们从逻辑上梳理了 Optimstic 的流程，以保证状态根的真实性。 事实上，为了保证提交者能够被震慑为恶，提交者往往需要进行资金质押。 当其提交被验证为错误时，将扣除部分质押资金作为惩罚。 同时，提交相应欺诈证明的验证者在某些解决方案中会被扣除资金，以激励监控和提交欺诈证明的行为。

如果我们比较 OR 和 Plasma，我们会发现一些相似之处，例如，它们都使用防欺诈机制，并且需要验证者角色来监控 OR 向主链的提交。 但是，由于 OR 是同时向主链提交交易数据的，因此 OR 上的验证者不需要自己在 OR 上保存和记录交易。 为了对比，将上面的简单架构图放在这里，供读者对比：

5：ZK-Rollup

Zk-rollup的核心

另一种解决方案是 ZK Rollup。 与 OR（Optimistic Rollup）不同，ZK Rollup 做出了这样的基本假设：

我不相信提交者能主动提交正确的批次，或者类似于判例中的“有罪推定”。 除了交易数据和post/previous state root，提交者在提交batch时还需要携带ZK-SNARK证书。

ZK-SNARK本质上是一个“有效性证明”，可以直接用来验证提交的batch是否正确。 将此证明提交到 Rollup 合约后，任何人都可以使用它来验证 Rollup 层中特定批次的交易。 然而，这意味着 Rollup 不再需要在提交后等待 7-14 天的验证。

有效性证明和欺诈证明的区别

那么如何通俗地理解ZK-Rollup这样的“有效性证明”和Plasma/Optimsitic Rollup使用的“欺诈证明”的区别呢？

首先，这三种解决方案都需要有人在 Layer 2 上对交易进行排序、执行和打包，我们称这个角色为“执行者”。

Plasma 的执行者只会提交执行结果。 本着别人信不信的原则，如果你不相信我，你需要发起挑战，而发起挑战需要你自己保存底层交易数据。

OR也是一样，但是执行者在提交的时候也会把交易数据放上去。 这也是信不信的问题。 不信可以根据交易数据自行验证。

但是ZK不一样，ZK说我不想等你几天让你挑战我，浪费时间，我急着确认我的交易。 所以ZK在提交的时候直接生成一个证书，把这个证书放在上面，边提交边完成校验。

同时，Plasma/OR都需要质押保证执行者作恶会赔钱，而ZK则不需要，因为它不需要别人相信，每次commit都会证明自己的清白.

除了这个区别之外，还有一点有意义的是，ZK-SNARK 可以让我们在不提交所有交易数据的情况下证明这批交易的有效性，这对于 Rollup 来说非常重要，下面我们将对此进行说明。

(3) ZK-Rollup的实现逻辑

首先，ZK-Rollup 本质上是一个 Rollup 的解决方案，所以它仍然需要做以下两件事：

打包压缩一批交易数据

生成新的状态根

唯一不同的是验证方式，ZK-Rollup 不会等待验证者发起欺诈证明过程，而是直接生成一个 ZK-SNARK 证明添加到 Batch 中提交到主链 rollup 合约。

如图所示，提交的内容相比OR增加了一个ZK-Proof，隐藏了验证者的作用。

提交到 rollup 合约后，任何人都可以验证。 验证成功后，主链 rollup 合约会将 State root 更新为最新提交的数据。

如何生成 ZK-SNARK 有效性证明？

A 什么是 ZK-SNARK？

ZK-SNARK的全称是“Zero-Knowledge Succinct Non-Interactive Argument of Knowledge”。

简洁的非交互式零知识证明。 我将尝试解释它的每个部分的含义：

Succint（简洁）：与实际证明的数据量相比，这种方法生成的证明要小得多。

例如，如果我们要证明一系列交易确实存在并发生，那么生成的证明数据量必须小于这些交易本身的数据量。

Non-interactive（无交互）：证明建立后，证明者只需向验证者发送一次简单的消息，通常允许任何人在未经许可的情况下进行验证。

这对于区块链上的ZK-Rollup或者ZK应用来说非常重要，因为有些ZK证明需要证明者和验证者进行多次交互（猜颜色问题就是一个典型的例子），放到链上就意味着发起多次交易，这在成本上是无法忍受的。

Arguments：可以抵御有限算力的证明者的攻击

这部分意味着用于生成证明的加密算法的复杂性在现有算力条件下无法在可接受的时间和经济成本下被暴力破解。

知识论：在不知道被证明的内容的情况下不可能构建证明

这一点对于 ZK-Rollup 来说也是非常重要的，因为我们不能允许任何人根据非交易数据创建一个 ZK Proof 并提交给主链合约。

最后，也是最重要的“零知识”：

零知识是指当证明者向验证者证明一个陈述（Statement）时，他不透露任何有用的信息或与被证明实体本身相关的任何信息。

B 最简单的零知识证明示例之一是这个

Alice 想向 Bob 证明她知道某个保险箱的密码。 密码是打开保险箱的唯一方法，但她不想把保险箱的密码告诉鲍勃。 我应该怎么办？

恰好鲍勃知道保险柜里有一封鲍勃前女友写的情书，上面还有鲍勃和前女友的指纹。

于是爱丽丝打开了鲍勃背后的保险箱，拿出情书交给了鲍勃。

这就证明Alice知道保险箱的密码，并且Alice没有告诉Bob密码是什么，成功！

C 如何为 ZK-Rollup 生成 ZK-SNARK 证明！

简而言之，生成一个ZK-SNARK证明分为以下几个步骤：

确定问题的逻辑验证规则（比如检查balance和nonce是否满足要求等）

将逻辑验证规则转化为门电路圈问题

将Gate Circuit Circle问题转化为R1CS（rank-1 constraint system，一阶约束系统）形式

将 R1CS 转换为 QAP（二次算术程序）

经过以上转换，我们可以得到一组ZK-SNARK证明，可以根据逻辑验证规则，通过固定的验证方式进行验证。 具体转换过程可以参考这篇文章：

如果您认为这部分比之前的所有部分都更复杂，那您是对的。 同样复杂的是目前的ZK-Rollup解决方案提供商，这也是目前ZK-Rollup研发进度和实际应用比Optimstic Rollup慢的原因之一。 如果您不是数学/密码学专家，也不是 Matter Labs 开发人员，那么您需要了解以下几点：

与验证 Merkle 树相比，生成 ZK-SNARK 证明的计算量和耗时要多得多

并非任何语言、编译环境、虚拟机、指令集都可以无缝支持上述过程的完成，还需要额外的适配。

对于第一点，这是目前各大ZK解决方案提供商正在努力的方向。 首先是时间成本。 如果生成可用的 ZK-Proof 需要一个小时，间接用户提现时间也会更长。 计算成本包括两部分，一是生成的 ZK-Proof 的数据量，二是验证 Proof 所需的算力。 这两部分越大，以太坊上需要消耗的Gas越多，进而影响ZK-Rollup的优化性能。

对于第二点，这是目前限制ZK-Rollup发展的一大原因。 在EVM设计之初，开发者完全没有想到后面会用到ZK技术。 因此，几乎不可能为 EVM 操作生成可用的零知识证明，从而产生了对 ZK-EVM 的需求。

D 为什么ZK很难兼容EVM？

打开DeFillama，你会发现TVL中最顶层的Layer 2方案都是OR。 这是因为这些 OR 解决方案已经拥有自己的网络，并且这些网络与 EVM 兼容。 开发者可以无缝地将以太坊上的智能合约移植到自己的网络中，用户也可以在自己的网络上进行互换、抵押、提供流动性。

然而，ZK-Rollup 仍然很难做到这一点，现有的许多解决方案只能支持简单的支付和交换场景。

为什么会这样？ 首先我们要明确一点，在Layer 1，部署的智能合约的字节码都存储在以太坊存储（存储项）中。 然后交易将在点对点网络中传播。 对于每笔交易，每个全节点都需要加载相应的字节码并在EVM上执行，以获得相同的状态（交易将作为输入数据）。

在Layer 2，虽然智能合约的字节码也存储在存储项中，但用户的操作方式也是一样的。 但它的交易会被发送到链下一个中心化的 zkEVM 节点。 同时，zkEVM 不仅需要执行字节码，还必须生成一个 Proof 来表明交易完成后状态已经被正确更新。 最后，Layer 1 合约可以验证证明并更新状态，此时不需要重新执行 Layer 2 上的交易。

也就是说，在zk-Rollup上执行交易是完全不同的逻辑和路径。 同时，zkEVM 也适用于在执行交易的同时生成 zk 电路证明。 现有的 EVM 生成 ZK-SNARK 证明如下问题：

不支持 ZK-SNARK 需要的一些椭圆曲线操作

与传统虚拟机相比，EVM有很多独特的操作码，这对电路设计来说是困难的

EVM 在 256 位整数上运行（就像大多数常见的虚拟机在 32-64 位整数上运行一样），零知识证明“自然地”在质数域上运行。

这些只是在 EVM 中生成 ZK 证明的一些问题。 虽然OR也需要搭建一个虚拟机来进行EVM操作，但是由于它只需要在执行交易的基础上完成交易打包等功能，所以需要构建。 简单多了。 对于 ZK-Rollup，除了在兼容 EVM 的同时难以生成 ZK-Proof 之外，在 Layer1 上验证这个证明也不容易。

如果想了解更多ZK-EVM的难度，可以阅读这篇文章：@yezhang/S1_KMMbGt

看完以上内容，不可否认zk-Rollup的实现技术难度很高，那我们为什么不直接使用更“简单”的Optimistic Rollup技术呢？

下面我们对这两种 Rollup 技术做一个简单的比较。

6：乐观VS ZK

(1) 效率优化（TPS/交易手续费）

以下是目前市面上几种不同方案在特定以太坊环境下的成本和TPS对比：