吞吐量
单位时间完成多少“可验证工作”。对通用计算链,Gas/s 往往比一个孤立的 TPS 数字更诚实。
从0到深入理解以太坊
第十六章 · 第二课
第十一篇 · 扩容与 Layer 2 · Ethereum 16.02
十万人在同一秒点击“确认”,并不会让十万笔交易同时落入链上。 它们在争夺一份有限的可验证资源预算。本课从零拆开这份预算, 看懂吞吐量、确认时间与使用成本为何彼此牵动。
系统瓶颈不只在“能不能算”,还在“能否及时传播、被普通节点复核,并在攻击下保持共识”。
单位时间完成多少“可验证工作”。对通用计算链,Gas/s 往往比一个孤立的 TPS 数字更诚实。
从广播、进入区块、成为规范链头,到经济最终性,是四种不同置信等级,不是一只秒表。
用户付出的 Gas 费只是表面;硬件、带宽、状态增长、等待和新增信任同样是成本。
Core thesis
真正的扩容,不是让一台机器跑得更快,而是让系统在不抬高独立验证门槛的前提下,承载更多有用工作。
00 · Orientation
先不谈 Rollup、分片或零知识证明。只要五个部件,就能推导出扩容问题为什么存在。
假设你在钱包里签下一笔交易。交易是一份带签名的状态变更请求:它可能转移 ETH,也可能让智能合约执行一串逻辑。钱包把它广播给节点;各节点有自己的待处理交易池;某个 Slot 的区块提议者从可用交易中构造区块;其他节点再独立执行并校验区块。
关键在最后一句:不是某台中心服务器算完就宣布结果。为了让任何人都能自行验证,许多彼此不必信任的节点要及时收到数据、重放执行、验证签名与状态转换,并跟上后续区块。
它声明发送者想做什么、愿意消耗多少 Gas、愿意支付怎样的费用,并用签名授权。
不同操作消耗不同 Gas。它不是时间,也不是 ETH;它把异构计算和存储操作映射成协议计量单位。
每个区块能容纳的总 Gas 有上限。简单转账与复杂 DeFi 调用占用的“空间”并不相同。
PoS 以太坊每 12 秒有一个 Slot;它是提议区块的机会,不保证你的交易一定在 12 秒内被选中。
全节点下载并验证区块与交易。能有多少普通人持续跟上,直接影响网络的可验证性与去中心化。
验证正确执行还不够,网络还要就规范链头和最终检查点形成一致意见。
01 · Three metrics
“这条链很快”可能在说四件完全不同的事。先把指标拆开,才能比较。
持续处理多少 Gas、字节或某类交易。回答“整条路一次能过多少车”。
从广播到进入某个区块要多久。回答“我的车何时驶上路”。
到何时推翻结果会付出极高经济代价。回答“这趟路何时几乎不可逆”。
TPS 是每秒交易数,但“交易”没有统一大小。一次 21,000 Gas 的普通 ETH 转账,和一次消耗 300,000 Gas 的复杂合约调用,都被 TPS 记作“1”。如果只报 TPS,系统只要把测试负载换成更简单的交易,数字就能大幅变好。
对于以太坊这样的通用计算平台,更稳妥的第一层指标是每秒可用 Gas,然后再说明工作负载:平均每笔多少 Gas、写入多少状态、携带多少数据、是否触发最坏路径。
持续等价吞吐量
等价 TPS ≈ 每区块目标 Gas ÷ 平均每笔 Gas ÷ 平均 Slot 时间
“目标 Gas”描述 EIP-1559 费用稳定点附近的长期容量;区块可以短时达到 2 倍目标,但持续满载会推动 Base Fee 上升。
| 教学工作负载 | 假设平均 Gas | 30M 目标 / 12 秒 | 这个数字不代表什么 |
|---|---|---|---|
| 普通 ETH 转账 | 21,000 | ≈ 119 tx/s | 不代表真实区块全由普通转账组成 |
| 中等合约交互 | 120,000 | ≈ 20.8 tx/s | 不代表所有 DEX 或代币操作成本相同 |
| 复杂合约调用 | 300,000 | ≈ 8.3 tx/s | 不含状态热点、失败重试与数据侧瓶颈 |
02 · Capacity
Gas Limit 不是随手调大的网页配置。它是一份对全网节点“下一轮必须及时完成多少工作”的共同承诺。
把区块 Gas 上限提高,最直接的收益是一次能装入更多执行工作。但区块到达每个节点后,节点要在有限时间内完成一串任务:接收区块、校验签名、执行交易、读取和写入状态、计算新状态根,再参与下一轮共识。
任何一步长期跟不上,较慢节点都会落后。若只有昂贵服务器和优质数据中心能稳定参与,“名义吞吐量”增加的同时,独立验证者的集合可能缩小。
区块与交易需要跨 P2P 网络及时到达其他节点;数据越多,带宽与延迟压力越大。
执行客户端逐笔运行 EVM;某些操作比另一些操作更消耗 CPU 或磁盘 I/O。
账户和合约存储被读取、修改并承诺进新的状态根;永久状态增长会累积。
独立节点必须在下一 Slot 前检查区块有效性,不能只相信提议者。
共识客户端传播区块和证明,跟踪分叉选择与检查点投票。
EIP-1559 允许区块在需求突然升高时超过目标、最高到 Gas Limit,给系统一个吸收突发流量的缓冲区。
若连续区块都高于目标,Base Fee 会逐块上升,把需求压回可持续容量附近。
Rollup 把大量执行移到 L2 后,L1 的稀缺资源会更明显地转向数据可用性:为了让任何人能重建和验证 L2 状态,交易数据必须在足够长的窗口内可获得。EIP-4844 引入 Blob,就是为这类数据建立单独、较便宜的容量与费用市场。
因此,“以太坊每秒能处理多少”至少要拆成两条预算:L1 执行 Gas 与 Blob 数据容量。它们服务不同负载,也有不同的价格反馈。
03 · Congestion
不是链突然“算不动”,而是同一时间愿意进入区块的有效交易,超过了目标容量。
每个区块都有协议计算的 baseFeePerGas。父区块 Gas 使用量高于目标,下一区块 Base Fee 上升;低于目标,则下降。达到区块上限时,下一块的 Base Fee 最多上升 12.5%;空块时最多下降 12.5%。
Base Fee 被销毁;用户还可以给出 Priority Fee,激励区块构建者纳入交易。钱包通常再用 maxFeePerGas 设一个总价上限。
EIP-1559 连续近似
下一块 Base Fee ≈ 当前 Base Fee × [1 + (Gas 使用率 ÷ 目标 − 1) ÷ 8]
当使用量等于目标,Base Fee 不变;等于上限(目标的 200%)时约 +12.5%;为空时约 −12.5%。协议实现包含整数取整等细节。
Base Fee 下降,让更多支付意愿较低的需求进入。
需求与长期容量相近,Base Fee 的变化幅度较小。
Base Fee 上升,低紧迫度需求等待、取消或转向其他执行层。
04 · Confirmation
钱包里一个绿色对勾,可能只表示“我看见它被某个区块包含”,不一定表示协议最终性。
在分布式网络里,不同节点可能短暂看到不同链头。网络会通过分叉选择规则收敛;验证者还会对检查点投票,使较早历史被证明为 Justified,随后成为 Finalized。
因此“确认时间”必须带上置信等级。日常小额操作可能在纳入区块后就给用户反馈;交易所大额入账、跨链桥结算或不可逆治理动作,通常需要更强的确认策略。
部分节点见到交易。它还可能因为费用、nonce、余额或替换而不被纳入。
执行结果出现在当前链头附近;短程重组仍可能改变链头。
更多验证者证明和后续区块累积。应用可按风险设定自己的“已确认”门槛。
检查点被 Finalized;若要推翻,攻击者必须付出大规模罚没等极高经济代价。
你的交易何时出现在某个区块。受广播、有效费用、nonce、需求和构建策略影响。
区块何时获得协议层经济不可逆性。受共识投票和网络参与度影响,不靠多付 Priority Fee 缩短。
更短 Slot 可以降低理想情况下的首次纳入等待,但也压缩了区块传播、执行、验证和证明聚合的时间窗口。更多节点会因为网络距离或硬件性能错过截止点,增加空 Slot、迟到区块或共识开销。
最终性也不是简单地把倒计时变短。要在更短时间内汇总足够多验证者的证明,节点需要处理更多消息、更快传播,并维持安全阈值。官方单 Slot 最终性说明明确把它描述为去中心化、时间与处理开销之间的权衡。
05 · Cost
交易费下降可能是真正的效率提升,也可能只是把成本从用户账单移到了节点、运营者或信任假设上。
用户看到的执行费
实际执行费 = Gas Used × Effective Gas Price
对 EIP-1559 类型交易,Effective Gas Price 由 Base Fee 与实际 Priority Fee 组成,并受用户设置的 Max Fee 上限约束。
Base Fee、Priority Fee、L2 执行费、L1 数据费,以及桥或服务可能收取的额外费用。
排队等待、价格滑点、交易失败仍消耗 Gas、跨层结算和提现等待。
CPU、内存、SSD、带宽、同步时间、运维与长期状态增长,由节点运营者承担。
排序器、数据委员会、桥、多签、证明系统或退出机制,可能以更低费用换取新的依赖。
在需求不变时,提高可用容量通常缓解竞争,Base Fee 可能下降。但长期费用取决于供给与需求共同变化:更便宜的区块空间也会吸引新的应用和交易。若需求增长重新填满容量,费用压力会回来。
这并不意味着扩容无效。扩容的成果应看相同安全模型下能服务多少有用需求,而不是承诺费用永远为零。
06 · The trade-off
“去中心化、安全、可扩展性”不是数学定理式的三选二按钮,而是一套帮助追问成本转移到哪里的设计框架。
去中心化不是节点数量截图,而是独立运行节点、验证历史、生产区块、发布证明和退出系统的门槛是否可承受。安全性不是“用了区块链”,而是无效状态能否被发现、数据是否可得、攻击需要控制什么资源、故障如何恢复。可扩展性也不只是峰值 TPS,而是持续负载、尾延迟、费用曲线和最坏情况。
执行容量增加;节点 CPU、I/O、传播和最坏区块验证压力也增加。
理想纳入更快;传播和共识截止时间更紧,对网络条件更敏感。
客户端优化、并行化与更精确 Gas 定价能扩大安全容量,但实现复杂度和新攻击面需要审计。
批量摊薄结算成本;要重新检查数据可用性、证明、排序、升级和退出假设。
吞吐和延迟可能非常漂亮,但独立验证、抗审查和故障恢复能力发生了本质变化。
07 · Scaling strategies
扩容没有魔法,只有压缩、并行、摊薄、分层与更精确的资源计价。
提高 Gas Limit、扩大 Blob 目标,前提是客户端与网络在最坏负载下仍有余量。
客户端优化、Gas 重定价、并行执行、状态访问清单与协议简化。
Rollup 在 L2 执行许多交易,再把数据和状态承诺或证明发布到 L1。
状态通道、应用链或专用执行环境只为特定交互优化。
如果每个 L1 全节点都逐笔执行全球所有用户操作,吞吐越高,验证门槛越容易上升。Rollup 把大量执行移到链下,把结果、足够的数据和证明机制锚定到以太坊,从而让许多用户共同购买一份 L1 安全结算。
但“继承以太坊安全”不是一句自动成立的广告语。不同 L2 在数据可用性、证明系统、排序器、治理升级、跨链桥和强制退出上仍可能有差异。第 17 章会把这些差异逐一拆开。
08 · Interactive labs
亲手拨动容量、负载与风险等级。所有数值都是本地教学模型,不连接主网,也不预测市场。
Lab 01 · Gas budget
固定 12 秒 Slot,改变目标 Gas 与平均工作量,观察“等价 TPS”为何高度依赖交易复杂度。
每个目标区块约可容纳 250 笔平均 120,000 Gas 的交易。
假设区块只含一种工作负载,忽略打包碎片、系统操作、空 Slot 和最坏状态访问;结果不能当作主网实测 TPS。
Lab 02 · EIP-1559
改变父区块相对目标的使用率,观察下一块 Base Fee 的方向与单笔执行费。
父区块高于目标 50%,所以下一块 Base Fee 约上升 6.25%。
使用 EIP-1559 连续近似;忽略整数取整、Max Fee 约束、交易实际 Gas 差异与区块构建策略。不是费用预测器。
Lab 03 · Confidence
选择动作性质,比较界面反馈、区块纳入与协议最终性分别能证明什么。
可补救的小额动作常在进入规范链头后先给反馈,但仍应向用户显示“待最终确认”。
真实门槛应由应用依据金额、可逆性、攻击模型、合规要求和当前网络状态制定;本实验不是安全保证。
Lab 04 · Trade-off
选择策略,观察相对收益与新增压力。分数仅用于比较方向,不代表真实协议测量。
直接增加持续执行容量;但所有全节点都要更快传播和验证更重的区块,状态增长也可能加速。
相对分数是教学编码,不是以太坊基金会数据,不应用于协议选择或投资比较。
09 · Cases
没有脱离场景的“最佳确认时间”或“足够 TPS”。负载形状和失败代价决定你真正关心哪一项。
工作量低、状态变化简单。用户先关心能否尽快纳入;金额越高,越应区分界面确认与协议最终性。
纳入延迟会改变价格和滑点;高 Priority Fee 可能改善纳入机会,却无法保证成交价格或最终性。
短时需求峰值远高于平时,竞争推高费用。弹性区块吸收突发流量,但持续满载会触发 Base Fee 反馈。
吞吐比单笔低延迟更重要。批处理能摊薄固定成本,但合约失败模式与单笔隔离要一起设计。
需要高吞吐、低费用和即时反馈,通常不适合把每次点击都直接写入 L1,可采用 L2、批处理或本地乐观交互。
界面可能很快显示“已发送”,但安全完成取决于源链最终性、数据与证明可用性、桥合约和目标链处理。
10 · Evaluation checklist
以后看到“10 万 TPS”“秒级确认”“近乎免费”,先不要相信或反驳,按顺序问。
普通转账、复杂合约、批内子交易,还是只改变链下数据库的一条记录?
持续时间多长?是否包含空闲期?最坏负载下还能维持吗?
排序器收件、预确认、进入区块、L1 纳入,还是协议最终性?
任何人能否取得重建状态所需数据?数据不可用时会怎样?
单一运营者、许可集合、任何全节点,还是通过欺诈/有效性证明验证?
CPU、内存、SSD、带宽、同步时间与长期状态增长分别怎样变化?
“平均便宜”是否只发生在低负载?需求超过目标后由价格、排队还是配额分配?
排序器停机、证明延迟、桥暂停或治理作恶时,用户能否强制退出或自助恢复?
多签、委员会、中心化排序器、可升级代理、证明设置分别能改变什么?
同时计算执行费、数据费、桥费、等待、失败、资本占用与安全折价。
11 · Self-check
每题只有一个最佳答案。答错不可怕,把混用的概念重新分开即可。
答案 B。同一条链上的交易复杂度差异很大;Gas/s 加上明确工作负载,才更接近可比较的计算容量。
答案 C。12 秒是一个 Slot 的出块机会;交易可能排队或未被选中,而协议最终性当前通常约需 15 分钟。
答案 A。区块高于目标时 Base Fee 上升,低于目标时下降;它分配稀缺容量,但不会创造额外执行容量。
答案 B。更重区块要求所有验证节点更快传播、执行和验证,并可能加速状态增长;安全提高需要客户端测试与资源余量。
答案 C。费用可能由应用补贴或在另一层结算;排序、数据、证明、硬件与安全成本仍然存在。
答案 A。批处理让许多用户共同摊薄 L1 结算与数据成本;但不同 L2 的数据、证明、排序器、升级与退出机制仍需单独评估。
12 · Primary sources
本课只引用 ethereum.org、Ethereum Foundation、EIP 与共识规范等一手资料。协议参数以链接中的当前版本为准。
扩容目标、L1/L2 分类、Rollup-centric 路线与保持去中心化验证门槛的原则。
12 秒 Slot、当前 30M Gas 目标与 60M Gas 上限,以及区块大小为何受限。
Gas、Base Fee、Priority Fee、Max Fee、目标容量与每块最多 12.5% 调节。
费用市场的正式规范、弹性乘数与 Base Fee 更新算法。
Slot、Epoch、验证者证明、Justification 与 Finality 的工作方式。
每个 Slot 的区块提议者、执行负载与共识客户端协作。
当前约 15 分钟最终性,以及时间、处理开销与去中心化之间的权衡。
PoS 共识的稳定规范、设计目标与当前分叉版本。
全节点如何独立验证,以及节点多样性为什么支撑抗审查与可靠性。
执行与共识客户端、CPU、内存、SSD 和带宽的当前运行要求。
为 Rollup 数据建立 Blob 交易与独立费用市场的协议基础。
Proto-Danksharding、Blob、数据可用性与未来数据采样扩容。
Fusaka 将默认 Gas Limit 提高到 60M 的动机、测试与安全考量。
在更高区块容量下限制单笔最坏负载、状态增长与验证延迟。
L1 扩容、Blob 扩容、协议加固与当年 60M Gas 容量快照。
通过数据可用性采样扩大 Blob 吞吐,同时限制单个验证者的带宽负担。
现在你已经能把“快、稳、便宜”拆成可测量的问题。下一章会继续追问:Rollup 怎样把执行移到链下,又如何把正确性与数据可用性带回以太坊。
先复查一手资料 ↑