先分清吞吐、确认与节点负担
讨论区块链扩容协议时，先把三类指标分开。ethereum.org的Scaling页面把主要目标写成：提高交易速度（更快最终性）与吞吐（每秒更多交易），同时尽量不牺牲去中心化与安全；并强调节点运营门槛升高会把网络推向更中心化的算力结构。因此，“扩容成功”不能只报峰值TPS，还要写清最终性口径与谁在验证。
同一页把路线粗分为链上扩容与链下扩容。链上改动触及一层协议；链下方案在主网之外执行，再以不同方式回到主网。分类本身不证明某一具体协议已投产，只提供比较坐标，避免把侧链宣传吞吐直接写成Layer2结果。
乐观汇总如何换吞吐，又如何拉长确认
Optimistic Rollups文档说明：计算与状态存储移到链下，交易数据仍以calldata或blob发布到以太坊主网；批量压缩可摊薄固定成本。它假设批处理默认有效，不立即附有效性证明，而是依赖挑战窗口内的欺诈证明来纠正错误状态根。
因此吞吐上升往往伴随确认语义变化：批提交后仍可能被挑战；提款常需等待挑战期。文档还写到，若缺少诚实节点执行并提交欺诈证明，安全模型会变弱。读“更快”时，要同时问最终性口径是排序确认、硬最终，还是可撤回的断言，并单独记录提款路径耗时。
节点负担：不是只看交易条数
Scaling总览提醒：扩容若抬高普通节点验证成本，会削弱去中心化。乐观汇总把执行放在链下虚拟机，但仍依赖主网提供数据可用性；没有数据，挑战者无法构造欺诈证明。数据发布方式（calldata或blob）会改变存档与带宽负担，不能把“用户手续费下降”直接等同于“全网验证变便宜”。
NEAR Architectural Overview提供另一组对照：区块链层负责分片、共识与路由，运行时层处理交易与收据且默认假设账户信息局部可用；运行时甚至不知道自己是否运行在分片链上。该材料描述的是NEAR分层，不是以太坊汇总实现；这里只用它说明“节点负担”可能落在状态同步、收据路由或执行环境等不同部件，而不能用单一TPS概括。
读协议材料时的边界
ethereum.org明确：侧链、Plasma、Validium等与派生主网安全性的Layer2不同；视频里把所有链下都叫Layer2的说法，与文档分类不一致。比较扩容协议时应核对安全派生关系与数据是否在一层可用，而不是只看宣传吞吐数字。
本文未部署汇总、未测网延迟，也不把任一开源架构说明写成投资建议。归档时应记录文档版本或页面更新时间、比较的三项指标口径，以及节点角色（排序器、验证者、存档节点）分别承担什么负担，并注明对照材料是否跨链。