扩容的目标是让更多有用操作在可接受的时延和成本内完成，同时维持所需的验证与安全条件。提高一个实验里的 TPS，不能单独说明系统在更大负载下仍可靠。
判断归属：AI 候选整合。 分类依据以太坊扩容文档，以下成本链是据机制形成的工程解释。
链上扩容改变共同处理的成本#
增大处理容量可以使单批容纳更多操作，但更多节点可能要下载、执行或保存更多数据。若资源要求上升，运行验证节点的门槛也可能改变。因此区块大小、传播时间、执行复杂度与参与条件应一同考察，不能把区块变大当成无代价的容量增长。
链上协议修改也不等于只有一种分片路线。以太坊当前文档强调围绕 rollup 的扩容及相应数据支持；不能把早期“执行分片”规划直接当作已经部署的现状。
链下执行仍要回答谁来验证#
Rollup 把大量执行移出 L1，并将相应数据与验证机制关联到主链。Optimistic 路线涉及可被挑战的结果与纠错机制；ZK 路线提交有效性证明。两者对验证成本、争议过程和结果确认方式的安排不同。
侧链则使用自己的共识。它与主链相连，不意味着自动继承主链同样的安全性。状态通道减少参与者反复上链的需求，但适用交互形式、参与者在线要求与退出路径仍需具体分析。分类应按实际安全依赖，而不能只按项目宣传中的“Layer 2”名称。
为什么证明之外还需要数据#
**工程推理：**知道一个状态转换满足规则，与能够取到重建或继续使用该状态所需的数据，是两个问题。评估扩容方案时，至少应追踪谁提供交易数据、用户怎样独立验证、关键服务离线时怎样恢复，以及管理员或排序者有什么权限。具体方案可能采取不同设计，必须逐一核查。
比较性能还应统一负载与统计口径：提交速率不是成功完成速率，出块间隔不等于最终性时间，平均响应也不能替代尾部响应。增加吞吐量后，如果队列积压或恢复成本恶化，用户体验仍可能下降。