Vitalik谈以太坊扩容：90%交易无需动态执行
以太坊扩容讨论正在进入一个更细的阶段。
过去几年，围绕Rollup、数据可用性、并行执行等方向的讨论，很多时候都在回答同一个问题：怎样让以太坊处理更多交易。
Vitalik Buterin最近关注的却是另一个问题——这些交易真的都需要以太坊提供完整的动态执行能力吗？
在围绕EIP-8141、UTXO、Keyed Nonces以及递归STARK Mempool等交易和状态模型的讨论中，以太坊开发者正在越来越清楚地区分交易中的“动作”（Actions）与“依赖”（Dependencies）。
这个区分看起来偏底层，却可能影响未来以太坊的扩容路径。
因为如果一笔交易里只有很小一部分需要动态执行，那么让整笔交易都按照最高成本的方式处理，本身就是一种浪费。
Vitalik给出的判断更直接：按照交易数量计算，超过90%的以太坊活动实际上并不需要动态性。
这意味着，以太坊未来可能不是继续把所有交易都做得更快，而是先判断——哪些交易根本没必要这么“重”。
以太坊最强的地方，也可能成为扩容瓶颈
以太坊的执行环境之所以强大，很大程度上来自它的灵活性。
合约可以调用其他合约，账户可以改变状态，交易之间可以产生复杂依赖。开发者不需要提前把所有执行路径写死，很多逻辑可以在运行过程中动态决定。
对于开发者来说，这种设计非常方便。
但从计算机系统的角度看，灵活性意味着很难提前知道一笔交易到底会做什么，也很难确定哪些计算可以安全地并行。
这就是扩容过程中一个长期存在的矛盾。
如果所有交易都可能依赖之前的状态变化，那么节点就不能简单地把它们拆开并行处理。每一次执行都可能改变下一次执行的结果。
于是，吞吐量提升最终会碰到一个很现实的问题：不是机器算不过来，而是系统不知道哪些计算可以放心地同时算。
这也是Vitalik此次讨论中“动作”和“依赖”划分的价值所在。
不是所有依赖都需要重复执行
一笔交易可以被理解成两个层面。
“动作”是交易真正想完成的事情，比如向另一个账户发送ETH、调用某个合约功能。
“依赖”则是为了证明这个动作可以被执行而需要提供的信息，包括签名、UTXO Merkle证明等。
还有一些更复杂的场景，则会涉及ZK-SNARK、STARK等零知识证明机制。
如果这些依赖已经能够在更早的阶段被验证，或者它们之间彼此独立，那么节点就没有必要在每一次执行交易时重复处理。
部分验证可以并行。
部分依赖甚至可以在Mempool阶段一次性处理。
这看起来只是优化几个步骤，但放到以太坊这种全球节点共同维护的系统里，意义完全不同。
每减少一次重复执行，意味着节点需要承担的计算量下降；每减少一份重复数据处理，也意味着网络可以把更多资源留给真正需要执行的部分。
扩容因此不再只是“让机器跑得更快”。
而是让机器少做一些不必要的工作。
90%的交易，可能不需要以太坊最昂贵的能力
Vitalik提出的“超过90%”是整个思路里最值得关注的数字。
如果绝大多数交易都不需要动态性，那么让所有交易都享受同样的动态执行能力，就像让一辆重型卡车负责运送城市里的每一件小包裹。
问题不是卡车不够快。
是配送任务本身没有必要使用卡车。
未来的设计可以要求合约、账户和交易更明确地声明：哪些部分需要动态执行，哪些部分可以提前分析。
能够被静态分析的部分，就可以获得更低的Gas成本。
而那些真正需要动态状态、复杂调用关系的交易，则继续使用更灵活的执行模型。
这实际上是在给以太坊增加一种“分层执行”能力。
开发者不再面对一个所有功能完全相同的执行环境，而是可以根据任务性质选择不同的计算路径。
EIP-8141的意义，不只是账户抽象
这也解释了为什么Vitalik把EIP-8141放到了更大的时间尺度上。
如果实现顺利，EIP-8141并不仅仅是过去十年账户抽象工作的总结，更是在为未来几年所谓的“Hyper-scaling”铺路。
过去以太坊的账户抽象更多解决的是用户如何与链交互的问题。
智能账户、灵活的交易结构、Gas支付方式以及签名机制，本质上都是为了让账户模型更适应复杂应用。
但当账户抽象进一步和交易执行模型结合之后，问题就开始变化。
系统不仅需要知道“谁发起了交易”，还需要更明确地知道“交易到底需要哪些计算”。
这一步很关键。
因为未来的扩容空间，可能就藏在这些过去被视为理所当然的执行细节里。
UTXO、Keyed Nonces和STARK，正在拼成另一套底层框架
单独看UTXO、Keyed Nonces或者递归STARK Mempool，很容易觉得这些只是开发者圈里的技术名词。
放在一起看，它们其实都在解决同一个方向的问题：如何让以太坊更容易识别状态之间的关系，并减少不必要的串行执行。
UTXO模型天然具有更明确的状态所有权和消费关系；Keyed Nonces则能够让账户交易序列的管理更加灵活；递归STARK可以进一步把大量验证工作压缩成更容易处理的证明。
它们并不意味着以太坊要简单复制比特币的UTXO体系，也不代表零知识证明会突然取代现有执行环境。
更准确地说，以太坊正在尝试把不同模型里有利于扩展的部分吸收进来。
最终目标不是让开发者面对更多复杂概念，而是让节点面对更少的无谓计算。
这两件事并不矛盾。
真正的挑战，是别把去中心化一起扩掉
Hyper-scaling听起来很诱人。
但以太坊过去一直没有单纯追求吞吐量最大化，其中一个原因就是节点运行成本。
如果扩容方式要求普通节点使用越来越昂贵的硬件，那么网络确实可以处理更多交易，却可能同时减少能够独立验证网络的人数。
这会直接触碰以太坊最核心的去中心化结构。
因此，Vitalik把“兼顾去中心化”放在Hyper-scaling之前，并不是一句装饰性的表述。
未来的扩容必须尽可能把计算压力转移到更高效的证明、并行处理以及静态分析上，而不是简单地要求每一个节点都升级成更强的服务器。
递归STARK Mempool之类的研究，真正有意思的地方也在这里。
如果大量交易依赖可以提前处理，节点最终只需要验证一个更紧凑的结果，而不是从头到尾重新执行所有细节，那么扩容和去中心化之间的矛盾就有机会被缓和。
当然，这仍然是一个工程问题，而不是靠协议设计几句话就能解决。
以太坊下一阶段，可能是“聪明地计算”
过去十年，以太坊不断增加自己的能力。
智能合约让链能够执行复杂逻辑，Layer 2把大量计算搬到链下，零知识证明则进一步压缩验证成本。
下一阶段的变化可能更加隐蔽。
不是继续给以太坊增加更多能力，而是让系统知道什么时候不要使用全部能力。
这其实是一种很典型的基础设施思维。
复杂任务继续保持灵活，简单任务尽可能标准化；需要动态执行的部分保留动态性，可以提前证明的部分则尽量提前证明。
最终，用户看到的可能只是更低的Gas和更高的吞吐量。
但在底层，以太坊可能已经从“所有交易都进入同一种执行路径”，逐渐转向一套能够识别交易复杂度、依赖关系和验证成本的计算体系。
如果EIP-8141以及相关状态模型能够真正落地，那么以太坊的扩容故事也许会发生一个变化：
从过去不断扩大区块和执行能力，转向重新定义什么值得被计算。
这可能比单纯把TPS再提高一个数量级，更接近Hyper-scaling真正需要解决的问题。