Ethereum 的架构史至少有两条并行线：执行规则怎样变化，谁选择/最终确认承载执行结果的历史。区块链（17）：执行、共识客户端与验证者怎样拼成一个节点的 EL/CL 分工是后期产物，不能把早期 PoW 客户端图标成今日完整节点。PoW 时 EVM 执行与区块挖掘在同一链路中；Beacon Chain 引入 PoS 验证者与信标共识路径；The Merge 改变执行载荷进入共识链的方式，旧 EVM 业务逻辑没有因为换共识就消失。

flowchart LR
  P[早期: PoW + EVM 执行] --> B[Beacon: 验证者/共识状态]
  B --> M[The Merge: CL 选择 EL 的执行载荷]
  M --> W[提款能力的网络升级]
  W --> D[Dencun: blob 承载扩容数据]
  D --> X[Pectra/Fusaka: 各提案及激活状态需独立核验]
  D --> L[rollup 路线: 执行/排序/数据与结算再分层]

提款类升级改变验证者资产退出的某些操作范围，不能与“执行账户可随时取款”混同。Dencun 的 blob 是扩容数据发布机制，并非把所有 L2 历史永久保存在每台节点磁盘。Pectra、Fusaka 涉及的账户/验证者或数据扩容路线须逐 EIP、逐网络查主网激活记录；本环境无法联网核验，因此这里仅保留名称和必须验证的层，不声称 2026-10-05 的激活状态、日期、默认客户端行为。同样，合并前白皮书不能证明当前 fee 或终局规则。

把订单映射到执行和最终性两个状态机

付款人向执行客户端发送签名交易，EL 检查 nonce、账户余额、gas 与执行结果；提议块中的执行载荷再由 CL 走提议、投票和链头选择。EL 认定某载荷有效，不等于 CL 已将它确定为最终历史；CL 看见载荷标识，也不能免除 EL 的状态转移检查。Engine API 是两层客户端交互的协议边界而非普通公开订单 RPC：验收时必须成对冻结 EL/CL 版本、认证配置与 fork 配置，再保存交易、载荷所在块、执行回执、CL 的终局检查点。这套路径与早期 PoW 挖矿选择历史的部署假设不同。

rollup 把订单执行搬到另一域时，L1 上的 settlement 合约不直接拥有每一笔 L2 业务调用的实时执行视图。它依赖数据发布、批次声明和争议或有效性协议；L2 RPC 回执、L1 数据可用性、跨域消息和强制退出分别有自己的最早可验证时间。blob 数据为 rollup 提供不同于普通执行 calldata 的发布路径，但不代表永不消失的公共归档。业务如果要求独立重放旧状态，须自行记录可用历史与索引恢复方式。

变化解决的旧问题并不总是免费：独立 EL/CL 增加双进程协作与故障定位；blob 让执行和数据费用路径不同，也要求历史重建者负起数据保留责任；验证者账户能力的扩展会改变钱包和运营者迁移约束。部署升级前须确认 genesis/fork、EL-CL 兼容性、钱包签名域和提款凭证。

练习一：一笔交易在 EL 执行成功，CL 尚无新 finalized checkpoint，是否能声称强终局？答案：不能。练习二：看到开发网已支持某 EIP，是否足以在主网后端按新能力入账？答案：不能；要拿到主网激活和真实客户端证据。各 fork 时态、客户端 SHA、私网终局 NOT_VERIFIED / NOT_RUN。

可迁移原则：架构演进应逐层标出保留职责、迁移约束与未上线提案。参考：Ethereum 历史、Ethereum roadmap、EIP 索引（当前状态未取得）；导航：区块链（40）：Bitcoin 的软分叉、钱包协作与链外支付分层 · 41 · 区块链（42）：Solana 的 PoH、账户并行与共识升级各做什么。