现在，执行层发生了变化。我已经谈到了帐户抽象、多维gas、BAL和ZK EVM。 我在这里还谈到了一个短期的EVM升级，我认为这将是非常有价值的：一个矢量化的数学预编译（基本上，同时对数字列表进行32位或潜在的64位操作；原则上，这可以加速许多哈希、STARK验证、FHE、基于晶格的量子电阻签名等，速度可达8-64x）；想想“EVM的GPU”。https://firefly.social/post/x/2027405623189803453 今天我将重点介绍两件大事：状态树更改和VM更改。状态树的变化在这个路线图中。VM更改（即EVM->RISC-V或更好的更改）是长期的，仍然没有达成共识，但我坚信，一旦状态树和长期状态路线图发生变化，它将成为“显而易见的事情”（见https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052）已经完成了，所以我会在这里为它辩护。 这两者的共同点是： *如果我们想要高效的证明，它们是我们必须解决的大瓶颈（树+虚拟机就像>80%） *对于各种客户端证明用例来说，它们基本上是强制性的 *它们是许多人回避的“深层次”变化，认为渐进主义更“务实” 我会为两者辩护。 二叉树 状态树更改（由@gballet和许多其他人完成）是https://eips.ethereum.org/EIPS/eip-7864，从当前的六进制keccak MPT切换到基于更高效哈希函数的二叉树。 这有以下好处： *更短4倍的Merkle分支（因为binance是32*log（n），六进制是512*log（n）/4），这使得客户端分支验证更可行。这使得Helios、PIR等数据带宽便宜了4倍 *证明效率。3-4x来自较短的Merkle分支。除此之外，哈希函数也发生了变化：要么是blake3[也许是3x vs keccak]，要么是Poseidon变体[100x，但还有更多的安全工作要做] *客户端证明：如果你想让ZK应用程序与以太坊状态组合，而不是像现在这样创建自己的树，那么以太坊状态树需要对证明者友好。 *相邻插槽的访问成本更低：二叉树设计将存储插槽组合成“页面”（例如64-256个插槽，因此2-8kB）。这使得存储在一次加载和编辑大量代码方面，无论是在原始执行中还是在证明器中，都能获得与代码相同的效率优势。块头和前~1-4kB的代码和存储位于同一页面中。如今，许多去中心化应用程序已经从最初的几个存储插槽中加载了大量数据，因此这可以为它们每tx节省>10k gas *减少访问深度的差异（大合同与小合同的负载） *二叉树更简单 *有机会添加状态到期所需的任何元数据位 缩小一点，二叉树是一种“综合”，它允许我们从过去十年中学到关于什么是好的状态树的所有知识，并实际应用它们。 VM更改 另请参见：https://ethereum-magicians.org/t/long-term-l1-execution-layer-proposal-replace-the-evm-with-risc-v/23617 随着时间的推移，协议在更多特殊情况下变得越来越丑陋的一个原因是人们对“使用EVM”有一定的潜在恐惧。如果钱包功能、隐私协议或其他任何东西都可以在不引入这种“可怕的EVM”的情况下完成，那么人们会明显松一口气。对我来说，这很可悲。以太坊的重点是它的通用性，如果EVM不够好，无法真正满足这种通用性的需求，那么我们应该正面解决这个问题，并制作一个更好的VM。这意味着： *在原始执行中比EVM更高效，以至于大多数预编译都变得不必要 *比EVM更有效的证明器（今天，证明器是用RISC-V编写的，因此我建议将新的VM改为RISC-V） *客户端证明友好。您应该能够在客户端进行ZK证明，例如，如果您的帐户被某条数据调用，会发生什么 *最大限度的简单。RISC-V解释器只有几百行代码，这就是区块链VM“应该有的感觉” 这仍然是更多的猜测和非共识。如果我们只做EVM+GPU，以太坊肯定会很好。但是一个更好的虚拟机可以让以太坊变得美丽和伟大。 一个可能的部署路线图是： 1.NewVM（例如RISC-V）仅适用于预编译：今天80%的预编译，加上许多新的预编译都变成了NewVM代码的blob 2.用户可以部署NewVM合约 3.EVM退役，变成用NewVM编写的智能合约 EVM用户体验到完全的向后兼容性，除了天然气成本变化（这将被未来几年的扩展工作所掩盖）。我们得到了一个更高效、更简单、更干净的协议。 https://firefly.social/post/farcaster/0x1daa0658c0d0f935cb99a2c31e32f345c6c49d4a