Appearance
21 · Layer 层级模型
LESSON 21 / 公开整理
Layer 不是楼层数量竞赛，而是职责分工框架。安全、去中心化、扩展性、低费用和应用定制往往彼此牵制；分层把不同工作交给不同系统，再通过结算、证明或通信建立关系。
学习目标
读完本节，你应能：
- 解释不可能三角为什么推动分层设计。
- 区分 L0、L1、L2、L3 的典型职责，而不是只看项目自称。
- 判断一条网络的安全是否真正锚定在另一条链上。
- 识别“越往上越快便宜、越往下越安全可信”只是记忆框架，不是无条件定律。
课程正文
为什么需要分层
区块链同时追求去中心化、安全性和可扩展性时，区块空间与验证成本会成为约束。分层的一种工程思路是让 L1 保留安全与结算，让 L2 承担更多计算和交易，再把结果提交回 L1。这样做并不自动消除风险，而是重新安排计算、数据、证明和信任的位置。
“主路与辅路”“总部与分店”等类比有助于入门，但技术判断必须回到实际的节点、共识、数据和提款机制。
L0：土壤与管道
L0 通常指更底层的物理节点、P2P 通信、验证者基础设施和跨链互操作环境。Polkadot 的中继链与平行链、Cosmos 的 IBC 是常见的说明案例。
L0 不是每条链都必须单独依赖的组件。比特币和以太坊也拥有自己的底层网络。这个标签更适合用来讨论多链如何共享通信、验证或安全资源。
L1：规则与最终结算
L1 拥有自己的共识、账本、原生资产和安全体系，并承担最终结算。UTXO 模型以简洁、可验证为优势，账户模型更适合通用合约与复杂应用；这不是高低排序，而是状态表达和执行方式的不同。
判断一个系统是否是 L1，可以问：它的区块由谁验证？账本安全由谁提供？它是否拥有独立的共识和最终性？不要只依据品牌名称或营销页面判断。
L2：扩容执行层
L2 在另一条链之上执行交易，将批量结果、数据或证明提交给 L1。典型路线包括 Optimistic Rollup 和 ZK Rollup。前者通常允许在挑战窗口内提出欺诈证明，后者提交有效性证明；两者都需要进一步核对数据可用性、排序权和升级权限。
L2 的关键不是“更快”这一个结果，而是安全假设是否继承、数据是否可获得、状态是否能被独立重建，以及发生故障时用户如何退出。
L3：应用专用链
L3 常被用于描述建立在 L2 之上的应用专用网络，为游戏、高频交互或特定生态提供更低延迟和更强定制性。Arbitrum Orbit、OP Stack 等基础设施常被放入这一讨论。
L3、AppChain 和其他层级术语仍在演化。某个项目究竟属于哪一层，要看其结算位置、安全来源、数据发布方式和运行机制，而不是只看标签。
概念结构
用三问检查层级归属：
- 安全最终由谁保障？ 是本链节点，还是另一条链的共识？
- 数据与证明在哪里？ 能否获取必要数据并重建状态？
- 这个标签描述技术，还是服务于叙事？ 同一项目在不同语境下可能被分类不同。
可把典型职责记为：L0 负责网络与互操作，L1 负责共识与结算，L2 负责扩容执行，L3 负责应用定制。但真实系统常把职责组合在一起。
可验证问题
- 为什么分层能缓解主链拥堵，却不能自动消除信任和数据风险？
- 侧链与 L2 的结构性区别是什么？
- L2 的安全继承需要检查哪些证据？
- 一个应用专用链的结算和数据可用性分别在哪里？
- 哪些“层级”说法是技术分类，哪些只是产品叙事？
练习与复盘
选择一个熟悉的网络，画出从节点通信到应用执行的职责图。对每一层写下：运行谁的代码、保存什么数据、由谁验证、故障时用户依赖谁。最后用一段话解释：层数增加后，新增的不是“先进等级”，而是新的接口与信任边界。
来源与时效提醒
本页公开整理自课程 21 的 preview、mindmap 与 notes。页面不复述课程原始长文中的生态数量、Gas、TVL 或项目排名；项目层级归属、技术路线、挑战期、数据发布方式和升级状态会变化，需要以当前技术文档核验。
层级模型用于学习和比较，不构成对某条链、某种扩容方案或任何资产的推荐。