公链性能讨论里，TPS 常被当成唯一标尺。但若追问「为什么以太坊主网长期只能维持十几笔每秒量级的吞吐」，答案很少是「硬件不够」，而是执行模型本身：以太坊虚拟机按设计一次只跑完一笔交易，再进入下一笔。这个约束保证了全网确定性重放，也把吞吐钉在了单线程的物理边界上。
理解这条边界，比记住某个瞬时 TPS 数字更重要。后面几篇会分别谈扩容地图、并行路线与乐观并发控制；本稿先把问题钉死——单线程 EVM 为什么会卡住 TPS，历史上的拥堵如何反复证实这一点，以及为什么提高 Gas 上限或引入 EIP-1559 都治不了执行模型本身。
串行执行不是疏漏，是确定性的代价
EVM 的执行语义要求：同一区块内的交易按规范顺序依次执行。一笔交易的完整状态写回完成后，下一笔才能开始读状态。这样设计的直接好处是：任意诚实节点重放同一交易序列，都会得到同一状态根。共识层只需就「交易顺序与区块内容」达成一致，不必再争论「并行交错后谁先写谁」。
代价同样直接。现代服务器有几十个逻辑核，但经典 EVM 节点在执行热路径上仍近似「一核干活、其余核旁观」。两笔互不相关的转账——例如 A 付给 B、C 付给 D——在串行模型里也不能同时推进，因为调度器默认假定任意交易都可能触碰全局状态树的任意角落。Merkle Patricia Trie 把账户与存储槽挂在同一棵巨大结构上，进一步强化了「没有先验依赖信息就不敢并行」的工程习惯。
于是出现一种结构性落差：网络带宽与磁盘 I/O 可以纵向扩展，执行吞吐却被「一次一笔」卡住。当需求低于这个硬上限时，用户感觉不到；一旦需求越过上限，多余交易只能进内存池排队，价格机制开始起作用——这就是拥堵的技术定义。
历史拥堵：同一病因的不同症状
2017 年 CryptoKitties 是第一次被广泛记录的大规模拥堵。养猫游戏在高峰期占据了可观比例的链上交易，待处理队列膨胀，普通转账确认从秒级拉到小时级，Gas 价格被推到数百 gwei。事后复盘里，社区往往把责任归到「游戏太火」，但更准确的说法是：热点应用只是把本已存在的容量天花板暴露出来。
此后剧本反复重演。2020–2021 年 DeFi 组合调用密集时，Gas 长期高位；2022 年 Otherside 等地契类 NFT 铸造中，短时竞价把费用推到极端水平，甚至出现小额转账被报出天文数字手续费的案例。触发器不同——游戏、流动性挖矿、NFT 抢购——但排队逻辑相同：执行引擎每秒能消化的「有效计算」有上限，超额需求只能用更高出价挤掉低价交易。
这些事件还暴露了优先级 Gas 拍卖的放大效应。在早期一价拍卖模型下，稀缺机会（铸造名额、套利窗口）会诱发连环加价，费用水位被整网抬高，普通用户被迫为别人的热点买单。拥堵不仅是「慢」，也是「贵」，而「贵」往往比「慢」更早把边缘用户挤出链上活动。
Gas 上限：在同一条车道上加宽，而不是改车道数
以太坊社区持续通过提高区块 Gas 上限来挤出更多容量。更大的 Gas 上限意味着每个区块可以容纳更多计算，短期看 TPS 会随之上移。但这仍然发生在串行执行框架之内：你是在加宽单车道，而不是把公路改成多车道并行通行。
这条路径有清晰的边际递减与外部成本。Gas 上限越高，全节点在单位时间内需要执行、校验与存储的状态变更越多，同步与硬件门槛随之上升。若把「扩容」等同于「无限抬高 Gas 上限」，最终会把去中心化验证能力挤出普通人可及的范围。因此，Gas 上限调整是有用的运营旋钮，却不是执行模型的替代品。它回答的是「在单线程约束下多塞一点工作」，而不是「如何让多笔无冲突交易同时推进」。
公开监测站点上常见的以太坊主网 TPS 数字——日常十几、短时峰值更高、理论峰值再高一些——也应放在同一语境理解：即便理论峰值，也远低于信用卡网络量级的吞吐预期，且日常运行与理论值之间常有数倍差距。这些数字会随时间与测量窗口变化，关键不在精确小数，而在数量级：单线程模型把上限钉在一个对「全球结算层」叙事偏紧的区间。
EIP-1559：改的是费用形成，不是执行宽度
2021 年上线的 EIP-1559 重构了费用市场。基础费用随区块利用率动态调整并被销毁，用户另付优先费争取更快打包。研究动机包括：减少一价拍卖下的系统性超额支付、降低同区块内报价剧烈抖动、削弱矿工/验证者从基础费用中攫取操纵空间的动机。
实践中，EIP-1559 确实改善了费用可预测性，也让「平时也按拥堵价出价」的现象有所缓解。但它从不承诺提高串行执行的物理吞吐。当区块持续打满，基础费用会上调，把超额需求挤出市场——这是价格发现，不是产能扩张。把 EIP-1559 理解成「扩容方案」是常见误读；更准确的定位是「在固定执行产能下更干净的排队与计价规则」。
同理，优先级费与后来的 MEV 相关机制，讨论的是交易如何排序与如何捕获排序价值，仍然默认执行阶段按序串行完成。排序层再精巧，只要执行层一次只能消化一笔，容量硬顶就还在。
确认延迟：另一条被 TPS 掩盖的轴线
TPS 描述的是单位时间完成多少笔；确认延迟描述的是用户从广播到「足够可信地认为不可逆」要等多久。两者相关但不等价。即使平均 TPS 看起来尚可，若内存池堆积，单笔交易的等待时间仍可能拉长到用户无法接受。
以太坊还叠了共识确认语义：出块间隔、最终性 gadget、重组风险等，都会进入「用户体验上的确认」。执行层拥堵时，交易可能长时间停留在 pending，应用层超时、桥接窗口与做市商库存风险一并放大。对支付与高频交互而言，延迟尖刺往往比平均 TPS 更伤产品。
因此，单线程瓶颈的完整图景是：吞吐上限决定「系统能吃多少」；排队与费用决定「谁吃得上」；确认延迟决定「吃上之后要等多久」。三者同源——执行宽度不够——表现却不同，评估任何「扩容」叙事时都应分开看。
结论：要动的是执行模型
把历史拥堵、Gas 上限与 EIP-1559 放在一起，结论会变得很清楚：费用市场与区块参数可以管理稀缺，但不能消灭稀缺的根源。只要 EVM 保持「全局状态 + 逐笔串行」的经典形态，TPS 就会有硬天花板，热点应用会周期性把整网拖进高费高延迟状态。
突破这条天花板，行业转向了另一类问题：如何在保留可验证确定性的前提下，让无冲突交易并行执行？答案并不唯一——确定性预声明、乐观并发控制、对象模型等路线各有假设。对仍想兼容以太坊字节码与工具链的项目而言，可选空间会被进一步收窄。这些问题属于扩容地图与并行路线的讨论范围；本稿只需确立前提：治本对象是执行模型，而不是再拧一圈 Gas 旋钮。