同样自称 zkEVM 的项目，内部路线差异很大。2022 年 8 月 Vitalik Buterin 的一篇分类文章给出 Type 1 到 Type 4 的坐标系：Type 1 对以太坊不做任何改动，Type 2 换掉区块结构与状态树，Type 3 删改个别特性，Type 4 直接从高级语言编译。编号越低越兼容越慢，越高越快越要付迁移成本。本文按这份分类讲清每一型的改动位置、受益者与代价，并说明类型本身会随时间移动。
检查点同步让新节点从一个近期已最终化的状态快照起步，先快进到链头，再回头补历史区块，把上线时间从数天压到更短，并把信任锚从「逐块重放全部历史」交给一个近期检查点。本文以 Lighthouse 公开文档为主源，讲清它为什么比从创世同步更快也更安全、弱主观性在其中起什么作用、回填限速如何工作，以及哪些场合仍需完整历史。
区块和投票要传遍全网，逐边重复转发会让带宽先崩。Gossipsub 让每个节点只在随机组成的网格里直接转发，再以定期传话消息把「最近见过什么」讲给网格外的邻居，缺货的邻居再点名取货。本文讲这张网格怎么组建、怎么靠心跳维持、坏邻居如何被降分，以及以太坊共识层为什么把广播流量交给它处理。
2025 年 1 月发布于 ethresear.ch 的一篇提案提出 EXECUTE 预编译：让 L1 验证者直接裁决一批交易的状态转换，把 EVM 等价 Rollup 的验证合约塌缩成极少代码，从而摆脱安全委员会。它与把排序交给 L1 的基于 Rollup 是两个正交概念。本文按提案原文讲清动机、与基于 Rollup 和执行分片的边界，以及 gas 定价与回退担保等尚未收敛的分歧。
以太坊轻客户端分别接收optimistic update与finality update：前者追踪更近的已证明头，后者携带最终化头与证明分支。本文从对象字段、验证步骤和业务放行门槛对照两者。
Beacon API返回blob sidecars时，HTTP成功和条目数量都不足以证明数据完整。本文按index、signed block header、commitment inclusion proof与KZG proof建立三层校验流程。
乐观与 ZK 的二分法装不下 Validium、Optimium、Volition。本文把二层方案拆到两条独立轴上——交易数据放在哪里、状态正确性由谁担保——再解释四个格子对应的提款路径、等待时间与信任假设差异。
二层链的桥和验证逻辑都可能被替换，替换动作全部发生在链上。本文说明如何从代理地址、实现槽位、角色函数、多签阈值与时间锁延时一路查下去，把“这条链谁说了算”变成可复核的链上证据。
算力翻倍为什么不会让以太坊更快，比特币又为什么要每 2016 个块重算一次目标值。本文对比难度调节回路、权益证明的固定时隙与投票门槛、以及领导者排班加跳过计数三条路径，并说明它们如何影响确认等待。
钱包说成功、浏览器说入库、交易所说到账，常发生在三个时刻。本文拆解二层交易的三层时间尺度，给出判断卡在哪一层的链上查询顺序，并解释挑战窗口与证明延迟为何让入账策略显得更慢。
