本文为SVM vs EVM 技术详解 【一】 之续

我们现在在 Solana VM 中了解了并行计算，我们有确定性并行执行，我们也有其他像 Monad 这样的项目在做推测并行执行。我们认为他们并不一样，一个通过访问列表，一个是通过启发式来实现 pipelining 交易。所以这解决了所有问题吗，让以太坊或者其他新的链性能更强？答案肯定是不。看待这个问题的基本框架是这些节点有各种可以利用的不同的资源，不管是硬盘空间，I/O 开销，真实的原始计算，带宽等。这里涉及到很多瓶颈，你需要弄清楚这些瓶颈是什么以及如何解决这些问题，在了解下一个瓶颈之前。特别对于以太坊来说，并行执行的案例是什么？对于以太坊，你可以优化并行执行交易，但是这并不是所谓的瓶颈。在以太坊上，燃料费被限制从而限制状态增长，所以你可以用比以太坊现在采用的更高的燃料限制依次执行交易。所以以太坊的真正瓶颈是状态爆炸。一个非常好的案例，如果你推动的太快的话，会发生什么。去年 BNB 链分叉了 Geth, Geth 是主要的以太坊执行客户端，并且没有做任何修改，他们将燃料限制调整到几百 TPS，非常高， 而以太坊目前无法实现（十几左右）。问题是在没有优化的前提下，以很快的速度运行就等同于状态开始增长，即使是非常少的节点，非常高的硬件要求，他们仍然可以做到。但问题是，达到某个时间点后，新的节点很难去同步链，而对于某些超级电脑很难与链同步。所以他们不得不降低燃料限制，同时增加 Aragon 客户端，这个客户端以不同的方式处理状态。他们意识到这里存在的本质瓶颈，这也是 Monad 在推动的，尽管并行计算很火，但是如果不解决以太坊的状态瓶颈问题，并行计算也无法解决根本性问题。设想下，假设以太坊可以通过并行计算实现 1000TPS，可以通过顺序执行实现 100TPS。如果超过这个会扩大你的状态规模，还是无法使用这条链。那么你是否执行并行计算并不重要。你需要将这些变化全面执行从而以不同的方式处理状态。这就是他们主要做的事情，将客户端重新通过 C++ 和 Rust 写出来。所以我们如何从头开始优化，只做一件事情无法根本性解决问题。

状态爆炸

所以拓展区块链的核心瓶颈是状态增长，所以状态里到底是什么？

状态某种程度上很难描述，直观的讲，状态是目前以太坊上重要的信息的快照，这个概念相对于历史，也就是过去发生的事情。一个简单的例子，我和你来回转账 1 个以太坊 100 次，所以交易都是历史，而最后的链的状态，比如你有 1 个 ETH，而我有 0 个 ETH。这就是状态。在比特币网络中，非常简单，按照字面的意思就是 UTXO 的集合什么地址拥有什么 coin。追踪这些信息非常简单。而对于以太坊以及其他通用虚拟机来说，状态可以是任何信息，你可以通过有任意代码和数据的智能合约去追踪谁有哪些代币，以及谁被批准等等。所以状态更为复杂，同时不停增大，所以以太坊的扩展瓶颈主要原因是状态无限期增长。这是本质的资源定价问题。我改变了状态，以及更新，我支付了前置费用，但问题是我已经增加了状态大小，并且这对于网络是个外部负担，未来的节点会多执行交易。这增加了他们的成本，并且更难计算新的状态，因为我已经永久增加了链的状态，没有办法去回滚这些，所以这是基本的资源定价问题。

在我们聊这个问题之前，我想有个更直观的理解，为什么状态大小变成了问题，当我们做一笔交易时，状态是如何扮演其角色的？

在资源方面，历史不是大问题。你可以放在硬盘上面，硬盘比较便宜。你不需要很快访问。而对于验证者来说，你需要比较快速访问状态从而进行查询。因为在区块中，验证者需要执行所有交易，并且计算最后的状态。比如我收到一笔交易，需要将我的账户余额从 0eth 更新到 1 eth。所以验证节点需要查看默克尔树，这个树是存储以太坊信息的数据结构。我查找了，发现了这个的账户，在树的最下面，所以我更新了叶子，更新了树。但问题是我需要相对实时的区块内访问这些信息，所以不能将其存储在硬盘，因为我需要快速访问。最简单的方法就是放在 RAM，可以立即获得内存的访问。如果你是超级算力，你在运行中继节点，并且你想实现最优化，你可以放在 RAM 的整个状态上，这会非常快，因为你无需去硬盘查找。但是另一方面，作为节点，如果你不想需要 1 太字节的 RAM， 你可以将他们放到 SSD, 这是作为节点需要存储状态的地方。所以瓶颈最终细化到我需要存储状态的硬盘大小，深入磁盘并且返回的 IO 成本等，这些都是比较繁重的操作。

当然如果你把所有东西都放到 RAM 上，在内存中，查询将变得非常简单，有效并且迅速。当你将东西存储到 SSD 的时候，这会变得更为计算密集。深入其中，查找某些内容，然后将其取回。这将花费更多的时间和资源, 最终的瓶颈就是状态无限增长。这是目前的架构。随着状态的增长，操作就变得更为困难。比如说仔细查看，发现这是个人账户，默克尔树变得越来越大，而每次你需要看得更为深入。当树变得更大，更难发现信息。所以伴随着状态增长，变得更有问题。

弱无状态性

我们非常善于压缩，但是压缩在这里并不重要，因为你需要不停打开才能使用。我想了解这个问题的解决方案？如果并行计算并不能帮助我们，那么消除状态增长瓶颈的设计应该是如何的？

答案是这并不是银色子弹。这里涉及了不同的权衡以及你可以做的优化。浏览清单，我认为以太坊主要专注的事情称作为弱无状态。主要的理念是目前节点的工作方式是他们本地保存了每一个验证客户端，全部状态的副本。他们保存在 SSD 中，当他们执行交易，他们查询树，这是需要我更新的状态，于是他们更新，并且执行了一切。而弱无状态性的理念是比如 验证节点，你无需再存储状态，我们会有一些 builder，这些 builder 都拥有大量资源并且创建区块，他们将区块发送给 proposer， 同时他们会附上 witness 的密码证明，主要是给验证者，这是你让我查看并且更新的状态，所以验证节点无需查找，将整个状态的整个副本保存，查询一切。Builder 只是将它们与每笔交易一起发送，比如这是一笔将 1 个 ETH 从 Alice 发送给 Bob 的交易，这是你需要更新 Alice 和 Bob 状态的信息并且你需要证明它的正确性。所以这本质是工作的转移，验证节点（proposer）不需要再做这些了，builders 需要更多工作。以太坊生态有很多这个方面的发展，比较相似的想法是关于扩展 DA 的扩容和方案 Danksharding。所以这是一个大概的理念，我们需要从验证节点身上卸载尽可能的工作，并且交给 builders。所以这是以太坊解决这个问题的主要思想，他们想要尽可能让节点去中性化，同时让 builder 有更多资源需求，因为 builder 本身已经拥有大量资源。所以最终以太坊的要求是切换状态的存储方式。目前我们认为状态存储默克尔树，MPT 的变种，你需要将其切换为 Vercal Tree，这是一种技术变化，因为利用默克尔树存储，所有证明例如 witeness 的密码证明，需要更新的状态等等，都是非常巨大且超级无效的，如果在网络上传输并且下载是无法实现的。Vercal Tree 是另外一种数据结构,以不同的方式分层数据，所以更为有效。Witness 非常小，对于带宽来说并不是非常重要的增长。所以这是以太坊主要在推动的解决方案。

所以这主要依赖 Proposer Builder Separation 问题，核心问题是你需要别人保存这个状态，问题是你想把这个负担给谁，是验证者，builder, 或者是必须知道自己本地状态的用户，或者是其他大的服务商负责存储他们，比如谁持有，谁展示。

State Expiry & State Rent

下一个问题并不是以太坊核心待解决的问题，但是我们可以看到在 Rollup 或者其他链上人们开始关注。相较于弱无状态更多关于将问题转接给别人，State Expiry &Rent 更为直接。State Expiry & Rent 更多是用来专门解决我之前提到的基础资源定价问题。当我增加了状态大小，随之而来的就是引发的网络外部成本。核心的思想是比如说我们有一年的时间轴，一年之后每个客户端说，超过一年的状态我们需要将其从树上修建，去除掉。这并不意味着数据丢失，我们无法恢复，或者钱没了。而是比方我的钱包已经两年没用了，我现在想用，我发送一笔交易去更新状态，因为如果不这样做，他们就会去除旧有的状态。只要我有数据证明我拥有这个钱包，这只是并不活跃，你可以发送另一笔交易表示这是我的状态，请把他重新添加到树上。

所以这关于存储要求，肯定需要有人能够更新这些，你没有必要强制这些，客户端不需要这些，作为网路上的节点，也不需要存储这些，你需要依赖中心化的节点，可以是 PRC 提供商，可以是区块链浏览器，可以是用户自己保存，理论上，也可以有些去中心化的解决方案去存储链和数据。

这里的想法主要是你可以 expire state based on 我们持续收取费用去维护账户。这里有很多方法，但是实际上可以从账户持续收取余额,使得其活跃，如果余额被用完了，那么账户也就不活跃了。如果要更新，方式也是一样的。我需要发送证明，交易，支付费用，我需要重新用我的账户。所以通过某些方式收费保证账户的活跃性，当然这样更为复杂，并且还要考虑 UX 的问题。你需要持续收费，并且使得其更为复杂。

目前, 你可以在以太坊上做这些吗，或者说它会破坏所有的东西？

这个问题和 MEV 问题有些类似，当你推出一条新链，这些只是很普通的事情，你并没有动力去解决。当他成为问题时，你才会解决，比如我们有足够多的链上活动，所以才有了 MEV，比如我们有足够多的活动，我们才有了状态爆炸。但是当你从头开始时，你并没有真正遇到这些问题，当问题变得重要，你才会思考。MEV 你可以马上解决，而状态爆炸并不能。

Solana un-merklizes State

Solana 用了一种完全不一样的方法，你可以拥有完全不同的模型，你如何要求别人存储状态，Solana 并没有要求节点活跃存储拥有全部状态的默克尔树，所以他们可以每个区块都更新默克尔树。他们只是很少将其默克尔化。所以 Solana 将这个问题变得更为简单。当然这里涉及到很多权益，比如使得其成为轻客户端，并且通过某些方式证明变得更为困难。总之，有很多完全不同的模型。

客户端优化

最后讲下很多团队都在做的客户端的问题，比如 Geth,Aragon，以及很多以太坊客户端的团队在做的事情。Monad 团队也是，当他们从 0 到 1 搭建，涉及到很多不同的优化。比如作为以太坊客户端，我们刚才提到如果深入硬盘，并且查找不同的状态会是非常昂贵的操作。所以不同的客户端可以尝试的比较有效的方法是，不用将所有状态放进 RAM，可以将一部分状态放进去，这些是最有可能用的状态，并且是我要持续更新的。将他们放入 RAM，更新就很简单。但是问题是当状态不成比例地增长，你无法放入 RAM, SSD 持续增长你更多渗入 SSD，而不是从 RAM 中取出。将你尽可能放的状态放入 RAM,这本身就是一种优化。而 Monad 团队他们重新写了客户端，并且用了完全不一样的他们称为 Monad DB 的数据库，可以存储默克尔树中的所有数据，并且更适用于快速查找信息。

新链 vs 旧链的优化

Monad 他们也会在状态爆炸问题上有所创新吗？我们刚才聊了一些东西，我现在做个总结 1）并行执行将非常重要，这是对于虚拟机的本质提升，每个人都可以用 2）链扩展的主要瓶颈是状态爆炸，并且如何管理（状态）3）每条新链有不一样的特质相互区别，到底是生命周期五年或者十年的链。状态爆炸就是五年 + 的问题，而 Monad 是一条生命周期为 0 的链。你认为对于新链来说，您认为对于一条新链来说，从理论上讲，解决方案是否已经足够到位，可以立即发挥并行化的优势？或者我们可以预料到，当我们到达那时，或者我们处于一个新的链条中，我们可以做一些事情，但空间本身也会成熟，到时候就会有新的解决方案等。

Jon：所以并行执行本身并不能真正帮助任何改变。任何 evm 更改。如果你看看 Arbitrum 和 Optimism 或以太坊或其中任何一个的 Gas 限制，你会发现它们现在实际上并不是执行的瓶颈。这本质是状态的问题，尤其是随着时间的推移。所以它将首先处理这个问题。这就是为什么 Monad 一起做这两个事情就是为了解决这个问题。但我的意思是，就你的观点而言，Monad 我认为他们将重点关注的是与绩效相关的客户端级别的事。例如我们如何将其存储在不同的数据库中，保证超级高效，而不是如何考虑正确的过期状态，以保持检查状态，因为这不是您需要优先考虑的，坦率地说，至少对于新链来说， 这是你几年后需要思考的。而且，更多的以太坊研究人员在做这个， Monad 无需在这方面带头。我们如何实现弱无状态性，或者以太坊已经在这样做了。因此，老链更有动力去做这些事情。他们也做了很多这样的工作。虽然你仍然知道其中很多内容是重叠的，但他们会关注它。

所以你会说并行化并没有真正帮助你，但是如果你将它与其他一些东西捆绑在一起，比如重新思考整个客户端架构和状态管理等等，那么作为新链你也可以产生一些直接的好处。这些基本上就是更高的 TPS、更低的延迟。

Jon：如果你有一个效率极低的数据库，你无法快速查找人员来更新状态并快速检索数据，那么并行执行对你没有帮助。它们是齐头并进的。

大家会合并吗？

这些是否会汇聚到同一个最终游戏中？或者我们正在转向这里永久的差异化地方

我的意思是，有些事情是基本的，不会改变，我想说的是，其中大部分会越来越趋同，就像某些事情不会改变一样。像以太坊和 evm 链, 强制访问列表，只是不会被添加这一点，因为它只会破坏兼容性，但是我们可以以非常相似的方式执行并行交易，并且该方式在足够长的时间范围内似乎是合理， 并且实现大致相同的结果吗？  因此，它的确切机制就是有些东西是基本的，你无法更改他们。理论上 Facebook 明天可能会成为谷歌，只需对公司进行所有更改，但就像它们不会这么做，原因很明显。这里的想法是一样的，就像对于你可以改变的东西有一些合理的限制，因为它会破坏一切，所以并不会被完成，但方向上每个人都是相同的想法，比如 1) 我们如何以更有效的方式处理状态 2) 我们如何尝试更准确地定价，从长远来看 3) 我们如何更有效地访问它 4) 我们如何并行执行交易以利用这一点，这都是相同的概念。就像我们有验证器，有资源节点，我们如何尽可能有效地使用它们，它正在解决一个又一个瓶颈，就像大多数想法一样。它们甚至不仅仅是区块链特定的东西，就像你所知道的那样，利用多个核心，并且拥有可以并行执行东西的软件，这就像你在软件开发中尝试做的一些事情，就像你不想要单线程的流程，因为它是一个瓶颈。所以它借鉴了很多传统事物。

是的，我认为工程中的很多设计理念正在将无法扩展的东西转变为可扩展的东西，你知道这方面的一个很好的例子是什么，也许就像是 IO 无法扩展，但计算却达到了一定程度 你可以并行化它，所以你可以尝试用更多的计算来替换更多的 IO，因为你知道计算的扩展成本无限便宜。同时它也受到摩尔定律和所有这些因素的影响。[完]