文章内容转自近期 Uncommon core  （Hasu vs Jon）本文主要介绍 SVM 与 EVM 的技术特色，对 Solana 感兴趣的同学可以看我们之前的文章。

Solana 的逆袭之路 - SQLANA

Solana 的技术理解、设计框架、最新产品以及生态简介 ( 一 )

Solana 的技术优化和创新

虚拟机（VM）的优化

目前以太坊上的扩展性问题，比如 single constrained DA 层以及一些不能优化的 EVM, 例如单线程，无法在优化环境中处理，高费用等问题没有得到根本性解决。而随着市场的回温以及用户需求的提升，我们看到 L2(rollup) 的使用价格也并不便宜，做一笔转账需要至少 1 美金，如果进行交易等其他操作，那么价格会更高。所以我们应该思考如何解决这些问题，比如如何进行优化，如何进一步提升 EVM 的性能，这些是根本性无法解决的问题，还是只是没有引起足够的重视。而 Solana 在过去几年进行了很多优化。 

Solana & Eclipse

我们曾经在一年多前介绍过 Eclipse,对这个项目仍然有疑问的可以关注CFG Labs 对话 Eclipse: 将 SolanaVM 引入下一代模块化堆栈。Eclipse 和 Solana 和以太坊相比有什么不同呢？既然目前的架构和系统无法支持大规模应用，比如说各种 L2 流动性，拓展性割裂，并发量也很低，而 Eclipse 的愿景是把 Solana 在扩展性上的创新带到以太坊生态。 以太坊 L2 仍然会发展的不错，毕竟现在以太坊仍然是最重要的，聚集着最强的开发者，用户，流动性等的超级社区。那么既然如此，人们又开始关注到扩展性的问题，而此时 Solana 的技术创新也一直没·有停下来，那么自然而然就又一次被大家推上了历史舞台。Eclipse 可以理解为以太坊上的 Solana L2。而这个 L2 和大部分其他 L2 一样，也是来解决扩展性问题的。但是相对于其他的 L2, 我们认为最大的一个瓶颈来源于以太坊上的 single constrained DA 问题。未来趋势我们将会用其他 DA 解决方案，比如 Celestia 等。大家都知道以太坊 4844 主要解决的是高交易手续费和低吞吐量的问题，而 Solana 可能会比 4844 更有效。当 DA 的限制被解决后，我们不希望被单线程，低吞吐量的问题所困扰，所以才有了 SVM。

Hasu: 我们讲 Solana 的虚拟机称为 SVM 或者很多人还不知道的 Sealevel Virtual Machine。 所以你的观点是吞吐量不是瓶颈，而 DA 层才是，你能说说 SVM 对于 Rollup 的重要性吗？

Jon: 在稳定状态下，带宽是 DA 层的限制。 以太坊 L2 上的稳定状态的价格要 0.4，0.5 美金，即使只是很基础的转账，即使网路并没有阻塞。而像 SVM 这样的执行环境的创新更适用于网络堵塞的时候，我们都目睹过 Arbitrum 上很堵的时候费用高达 20 美金，即使以太坊的 DA 层在带宽限制内，但是 Arbitrum 网络拥堵了，还是会造成这样的影响。所以要实现真正的扩展我们需要同时解决这两种问题。 

你认为 Rollups 对于以太而言是并行执行吗？

Jon：让我们想一下什么是以太坊，你认为他们是以太坊的延伸吗？很多人都会将它比喻为分片，还有些会讲的很技术。很明显，他们和分片不一样，但是从某方面来说，他们是一种分片的 dirty form ,那么他们可以认为是以太坊的延伸。但是他们并不是在单一可组合虚拟机内的并行执行，而 Solana 在这块做了很多创新。所以人们现在在 EVM 想办法解决，Monad 就是一个主要的代表。尽管现在以太坊单线程，低吞吐量，但是这些问题都不是不能修复的根本性问题。所以我们可以试着去做优化，进一步提升性能，有哪些问题是基本约束，你可以用 EVM 做什么，主要的瓶颈是什么？

Eclipse 和 Solana 是相互竞争还是补充？

Jon: 如果他们是竞争关系的话，那么你的想法就是未来只有一条链会统治他们，这样的情况，大家才是竞争对手。但是实际上这并不是零和游戏，除非他们对于用户而言是完全一样的设计。实际上，Solana 和 Eclipse 都采用了 SVM,但是仅此而已。 Eclipse 的架构的关键点在于他们采用了不同的架构权衡并且试水到新的市场以太坊。所以对于 Solana 来说，他更倾向于是 SVM 而不是 EVM，因为这对于你的网络效应，基础设施是叠加，同时降低了开发者平台的风险。更准确的是，这一半的区别是架构，作为 L2，Eclipse 优先考虑数据可用采用和证明。Solana 和这些 L2 核心设计理念的另外一部分区别在于什么时间需要什么样的承诺。这些 L2 可以比 Solana 更快，利用他们单个排序器或者小排序集，立即给你提供确认，因为他们不太受信任，所以他们会把你的数据发布给 DA 层，通过更多的节点集和延迟，获得完全保障而 Solana 可以通过大量的节点立即给你提供完全保障。这个是非常困难的根本性问题。Solana 过去很多的问题都来源于共识 Tower BFT,以及相关的历史。就他们有些方面仍然没有被完全解读这件事情上而言还没有完全被证明。你可以通过权衡解决复杂性和风险。但我认为他们在完全不同方向上进行实验本身是非常好的一件事情，而且我认为他们在各自的领域都能取得非常大的成功。

所以这是一部分。另一部主要总结为 L2 的 UX 和网络效应。不管怎么说, Blast 都是非常好的例子，如果你能够获得以太坊社区的注意，那么你就会获得用户和流动性。用户在脑子里就能形成映射，这是以太坊的一部分。这是原生的以太坊 token，我可以用作 gas。我不需要在这条链上去处理不同版本的 token，比如我需要用那个桥，或者我需要用哪个新钱包，获得 ga 等等。这样会给用户带来很多复杂性，L2 的用户也会逃离。所以像 FriendTech 这样的产品我认为很有价值，因为门槛相对较低，我只需要放几个 ETH 在哪里就可以了。

Hasu: 我认为在以太坊上还是有很多人在搭建，只不过大家更多把以太坊当做一种分发策略，而不是技术，更多关于试水到以太坊社区，网络效应。同时，其实 Blast 桥未必比从以太坊到 Solana 的中心化桥更安全。所以他们完全不受益于成为以太坊的无信任验证桥的 L2。在我们进一步了解 SVM 和 EVM 之前，聊聊什么是 VM 虚拟机？

Jon: 从更高维度去谈论这个问题，在区块链的世界中，虚拟机就是一个节点运行的软件，可以执行代码并且计算链的最新状态。虚拟机负责运行链上部署的智能合约代码是什么，同时给交易喂相关信息比如我获得的最新状态是什么。当然，操作的方式有很多，有的更为高效，比如如何给不同交易并行执行代码。总而言之，虚拟机就是一个节点运行，可以执行只是并且更新链上状态的软件。（实际上你也可以把它想成一个软件电脑，硬件电脑通常有一个 CPU，利用的晶体管和 gates）拥有短期内存和长期内存。而对于软件也是一样的，拥有同样的组件。一个硬盘给短期内存，一个硬盘（硬件，之后我们会讲到 Solana 的 SSD）给到长期内存，而电脑就像是整个系统的超级大脑，你可以将其做成软件组成成分，那这就是虚拟机，他拥有和硬件电脑完全一样的功能。

并行计算和访问表

我们看到最受欢迎的 Solana VM 和 EVM，他们的主要区别在哪里？

Jon: 最引入瞩目的就是 SVM 搭建的目的是用于支持并行计算，这是核心理念，并且其支持不同的软件。所以目标是能够并行计算工作量，这就像电脑的工作方法以及处理方式。电脑有很多不同的核，每个核可以实现顺序计算，而我们的目标是实现并行计算，执行不同线程的顺序计算。当然问题是大部分的逐年的性能进步主要是在核个数的增加，而并非让单个核变得更为快速。如果你有单线程的虚拟机，比如以太坊虚拟机的工作方式，那么你无法进行并行计算。这意味着你的核被闲置，并且你无法利用每年添加更多核心的优势，并且这样做会变得越来越便宜。

而我们如何让 SVM 可以实现并行计算呢？这可以帮助提升速度，并且更有效地处理交易。Solana 主要做的事情预先强制，所有的交易必须能够预先指定。当发送一笔交易，这是所有交易将要读并且写的状态和账户，所以如果你是节点，并且你获得了所有的交易，他们实现声明这是他们要读写的状态，所以你可以看到哪些交易并不冲突，因此可以合理安排，并且将不冲突的交易执行并行计算。

而在以太坊中，你无需做这些，当你获得交易，你并不知道交易将触达哪些状态和存储槽。所以每个客户端只能按照顺序进行计算，否则你无法判别这些交易是否冲突。以太坊以及很多其他的 EVM 链都是这样工作的，你只需要将这些交易按照顺序进行计算，因为以太坊并没有强制加入访问表，你可以事先设定，但是这样做会给生态带来巨大改变，影响兼容性。

那么我们现在谈谈到底是否应该使用访问表，这个更像是标配的 table stakes, 而是包含了很多的权衡？

Jon: 我认为并行计算应该算是标配，但我不确定需要访问表是否会变成标配，我并不这么认为。如果你想要并行 EVM 或者其他虚拟机，你可以最优化处理。你可以用发现法去判断这些交易并不冲突，我可以并行执行。如果我运行并且获得了错误指示，这个交易和其他交易冲突，我可以选择重新执行。在最好的和正常情况下，大部分交易都不会超越并且冲突。在最坏的情况下，这些交易冲突并且有顺序，那么我必须再执行一次。这个就是权衡，因为你不知道这些交易最后是基于顺序的。但是如果设计合理，最差的情况也没有想象的那么糟糕，因为最差的情况下，你需要再次执行，但是重新执行的计算成本对于验证者来说并不是最 tough 的，并不是主要的限制。重新执行是一个相对简单的工作，并不是主要瓶颈。所以这里面有很多权衡。预先声明状态访问权限的权衡主要是给开发者增加了很多门槛，对于每笔交易必须预先制定，如果可以用发现法那就简单多了。

在这种情况下，Solana 开发者相对于以太坊开发者来说工作量要大多了。当他们设计应用的时候，设计的思路是当用户这么想，交易就应该这样形成。所以 Solana 开发者的工作量更多。访问表的另外一个问题 ( 可以通过更好的资源定价解决）是在 Solana 上，你可以主动通过交易锁住（write block）一些你不用的状态，比如我可以锁住最上面 60 个状态。打个比方，比如我可以发送一笔交易表明我将会用到最高交易量的 50 个池子，当节点准备运行的时候，他看到了访问表，看到了将要访问的状态，于是锁住相应的状态，并且不能并行执行。所以这是一个问题, 非常琐碎而且免费。这样的结果就是交易池子的使用变得效率低下。我可以发送一笔免费的交易，并且锁住我不用的状态，这个特定问题可以通过更好的资源定价来解决。Solana 有很多古怪的资源定价问题。和以太坊最基本的差别就是他们是按照交易的签名收取固定费用的。所以 Solana 的计算单元相较于以太坊 gas 的换算不重要，无论你一笔交易消耗了 2 万个计算单元，还是 100 万个计算单元，如果是一笔签名，那么收费仍然一致。应该引入根据你实际使用计算单元收费的机制，如果你锁住其他状态，你应该有对于我访问不同状态收费的态度，而不是免费发送一个超大交易去锁住那些我不用的状态。如果大家都这样做，那么就会变得效率低下。

本地费率市场

可以讲讲什么是本地费率市场吗？

Jon: 有很多关于理论和实践的讨论。主要的思想是对于以太坊和其他链而言，你有一个全球费率市场，所有人都在竞争内存池。比如你发送了一个优先费率，每个人都在和其他人竞争。在 Solana 上，这变得更为容易，如果有个状态很火，比如 NFT 铸造，那么这会带动整条链的价格，并且每个人都会出价更高，即使带宽并不饱和，区块并没有被填满。所以在经历过几次活性失败后，Solana 意识到这点，如何将这个状态定价更高，而其他状态不受影响呢？这就是本地费率市场。你要付更高的优先费率给这个状态，因为这是很火的状态。其他的状态，价格不变。因为他们并不冲突，所以交易都能被执行。（而以太坊无法实现，因为当计算开始，客户端并不知道哪个状态受到影响，所以他们不能这样做）。但是目前来讲，虽然想法很有道理，但是在实践方面还停留在表面，仍然没有引入在协议层，而是在客户端。

同时，我们发现由于 Solana 创建区块的方式，本地费率市场也不能确定并且保证有效。Solana 是连续不断的出块，而不是等待几秒，最后出块。所以本质上是一种连续区块创建和分发的过程。所以这就引发了以下问题：你将交易分发到不同线程，同时提高优先费率，希望可以获得你想要状态的概率，但是当你意识到这些交易会在不同线程上执行，并且分发到不同线程，可能出现的情况就是一个被随意分发的人可能会抢先于你，即使你付了很高的费率。所以这个 latency race 带来了很大的可能。也就是说，拥有低延迟的快速搜索者优先于出价更高的玩家。所以这仍然是一个不完美的解决方案。如何改变？如何让其实践于协议层，你可以试着引入类似于以太坊 1559 的机制。比如，上个区块链有 100 多万笔交易试图 touch 这个区块，你知道下个区块改变，所以你做了一些变动，这个仍然是一个不完美的方案。即使你可以让这些交易在下个区块仍然出现在这个状态，但是在下一个时间轴，仍然没有人在乎这些。所以这关于是否进步和有帮助。

活性失败

我认为会有不同程度的活性失败，不仅仅是 Solana, 如果你对于 Solana 观察的时间足够长，同样的事情也发生在 rollups 和其他链上。我们发现在在这些不同的 rollups 的排序器，不管是 L2 base 或者 Arbitrum,当排序器被 DDOS 或者宕机的，并且你无法进行交易。所以我们需要不断去迭代并且修复，毕竟这是非常早期的技术。如果你不是比特币或者以太坊，我们应该思考如何扩展上限，让技术更为可行，更为优化。所以我认为如果能由于外部一些可笑的原因，在同一时间, 这些链都出现活性失败，那是非常好的。Solana 和 Rollup 以及众多其他链宕机，那么我们都能意识到这些仍然是非常早期的技术。而且当我们精心计划，并且如何拓展上线的时候，就能实现大规模应用。

youtube 链接  https://www.youtube.com/watch?v=fbppZY8V0LI