LOREWORD
Ethereum learning path 18.03

第十八章 · 第三课 · Ethereum Roadmap

以太坊不保存一切，如何仍然可信？

真正的扩容，不是把负担藏起来；而是让数据可以抽样、状态可以随区块证明、历史可以分工保存， 同时保留任何人独立验证的能力。

  • 正式主题：数据可用性、无状态验证与协议简化
  • 从零起步
  • 约 55 分钟
  • 资料核对：2026-07-26

01 · Availability

承诺数据，不等于交出数据

KZG 能证明样本与承诺一致；纠删码、托管、传播、抽样与分叉选择共同回答“完整数据是否真的可取得”。

02 · Statelessness

无状态，不是世界状态消失

状态仍然存在。改变的是验证者取得状态的方式：从本地保存全部，变为接收本区块所需片段与密码学见证。

03 · Simplification

删掉负担，也要保留可验证性

历史过期与协议清理不会让责任凭空消失；它们把长期保存交给专门角色，并用承诺和规则保持可核验。

01 / 13

Orientation

先看整台机器：节点到底背着什么？

从零开始，先不要记缩写。把一个以太坊节点想成同时做“收件、复算、记账和保存档案”的独立审计员。

一笔交易进入以太坊后，节点必须知道交易和相关数据，按相同规则执行它，再确认执行后得到的状态根与区块声明一致。 如果还要回答“2021 年某个区块发生了什么”，节点或外部档案服务还要保存历史。随着使用增长，三类负担同时累积：

  • 近期数据负担：L2 把越来越多批次数据交给以太坊，网络要在有限时间内传播并确认它们可取得。
  • 当前状态负担：每个新账户、合约字节码和 storage 写入都会扩大“以太坊现在知道什么”。
  • 长期复杂度负担：旧区块格式、旧网络字段和 EVM 特殊语义会增加客户端、测试与审计分支。

Node pipeline

一个验证节点处理新区块的最小流水线

FIG 01
本课三个主题分别改造这条流水线的不同位置：PeerDAS 降低“取得全部 Blob”的带宽要求；无状态验证降低“本地保存完整状态”的要求；协议简化缩小“永久兼容所有旧路径”的要求。

全课总命题

存储和带宽不会凭空消失。以太坊要做的是把它们分工、限时、证明化，并避免任何单一保存者变成不可替代的信任点。

为什么这三件事必须一起学？

如果只提升数据吞吐，不降低单节点带宽，家庭节点会被数据中心挤出；如果验证者不再保存状态，却没人可靠地服务状态， 区块构建和 RPC 可能更集中；如果协议不断叠加例外，客户端之间发生共识差异的机会会增多。因此路线图不是“越快越好”， 而是在吞吐、验证门槛、数据保存与长期可维护性之间重新分工。

这节课的核心不是“删除多少 GB”，而是一个更难的问题：少保存、少下载之后，任何人还能否自己验证？

02 / 13

Trust model

可信不是一个按钮，而是三道不同检查

很多误解来自把“数据指纹正确”“完整数据可取得”和“执行结果正确”混成同一件事。

可信状态更新 = 输入可取得 × 状态转换符合规则 × 输出可承诺

Three independent checks

同一个区块，要分别回答三个问题

FIG 02
数据可用性主要回答 A；状态转换与见证回答 B；档案节点、历史网络和索引器主要回答 C。三者相互依赖，但安全目标不同。

承诺像“指纹”，不是“文件送达回执”

一个密码学承诺可以很小，却锁定一份很大的数据：拿到数据的人能验证它是否与承诺匹配。但如果区块生产者只公布承诺、 从未把原数据交给网络，承诺仍然可以完全正确。此时大家知道“某份唯一数据被承诺过”，却不知道那份数据是什么。

Commitment ≠ availability

小小的承诺，不能代替 128 KiB 的 Blob

FIG 03
KZG 证明可以验证“这个样本确实来自被承诺的多项式”；它不单独证明“所有样本都曾向网络发布”。后者需要传播、纠删码、托管、抽样和共识规则。

精确区分

完整性（integrity）：拿到的字节是否与承诺一致。可用性（availability）：足以重建的完整数据是否在窗口内可取得。有效性（validity）：使用这些数据执行后，状态转换是否符合规则。

03 / 13

Data availability

数据可用性：先让别人有材料复算

“不要信任，要验证”的前提，是验证材料真的拿得到。没有输入数据，再强的电脑也无法独立重放。

用一个 Rollup 例子从零推导

假设某个 L2 在链下处理 10,000 笔转账，最后只向 L1 提交一个新状态根。如果排序器隐瞒交易列表，第三方无法知道 Alice 的余额为何减少，也无法从旧状态重建新状态。Optimistic Rollup 的观察者无法构造错误证明；ZK Rollup 即使证明 状态转换正确，用户也可能无法重建自己的余额、生成退出所需信息或继续状态演进。正确性证明不能代替数据可用性。

早期 Rollup 把压缩数据放进 calldata，它进入永久链历史，可靠但昂贵。Dencun 升级于 2024-03-13 上线 EIP-4844，引入专门的 Blob 交易：Blob 数据由共识层临时保证可用，不进入 EVM 执行负载；EVM 只能访问 versioned hash 并验证指定点的 KZG 证明。[01]

Blob lifecycle

Blob 不是“链下数据”，而是限时的共识层数据

FIG 04
每个 Blob 由 4096 个 32 字节字段元素组成，即 128 KiB。EIP-4844 的最小 Blob sidecar 服务窗口是 4096 个 epoch，约 18 天；“可修剪”不等于所有副本必然消失。

可用性不是永久保存

以太坊共识最关心的是：在相关区块被接受、Rollup 观察者需要复算或挑战时，数据已经充分发布。几十年后的历史查询不是验证 下一个区块的必要条件，可以由少量档案节点、Rollup 自身、索引器或去中心化档案网络提供。取得旧数据后，仍可用链上承诺核验 它是否原封不动。

不要把限时保证说成永久存储

“Blob 上了以太坊”表示它在协议窗口内获得以太坊的数据可用性保证；不表示每个普通节点会永久保存原始字节。应用若需要多年历史，必须设计独立的归档与恢复路径。

截至本课日期，Blob 扩容走到哪里？

Dencun 先引入 Blob；Pectra 在 2025 年提高参数；Fusaka 于 2025-12-03 上线 PeerDAS，并允许通过 Blob Parameter Only（BPO）升级逐步增加容量。截至 2026-07-26，BPO2 的主网目标/上限为每区块 14 / 21 个 Blob；更高数字属于后续方向，不应写成当前配置。[02]

04 / 13

Erasure coding & sampling

为什么只抽几块，也能判断整份数据可用？

答案不是“运气好”，而是先用纠删码改变攻击者必须隐藏的数据量，再让许多节点从不同位置抽样。

第一步：把数据扩展成“缺一点仍能恢复”的形式

纠删码（erasure coding）把原始数据变成带冗余的扩展数据。PeerDAS 对每个 Blob 做一维扩展：得到足够比例的扩展列， 就能恢复原 Blob。EIP-7594 规定，取得至少 50% 的列可以重建完整数据。[03]

这一步有关键效果：攻击者不能只藏起原数据里某个“致命小片段”而让抽样几乎永远错过。若想让原数据不可恢复， 必须隐藏接近一半的扩展数据；隐藏面变大后，随机抽样更容易撞见缺口。

第二步：每个样本都要能验真

节点拿到一个 Cell 时，会验证它的 cell KZG proof，确认它确实是该 Blob 承诺在这个位置的内容。这里的分工非常清楚： 纠删码制造可恢复冗余，KZG 防止伪造样本，抽样探测隐藏，共识规则拒绝不可用区块。

Interactive model · local only

抽样侦测器：隐藏越多、抽样越多，越难蒙混过关

调整“被隐藏比例”和“单节点抽样数”。下方使用 64 格示意；读数按有限总体不放回抽样计算“至少撞见一个隐藏样本”的概率。

Detection probability

99.8%

单个教学节点几乎必然撞见至少一个隐藏格。

许多独立节点同时采样，攻击者还要对抗不同的 custody 分配、对等连接、传播与验证者的分叉选择。

教学模型：总体 N=64，隐藏 W 格，不放回抽 s 格，侦测概率为 1 - C(N-W, s) / C(N, s)。真实 PeerDAS 安全性还涉及 128 列、确定性 custody、网络拓扑、对等节点多样性与攻击模型；本数值不是协议安全参数。

抽样的边界

如果节点被恶意对等节点完全包围（eclipse）、样本选择可被操控、数据列没有足够独立托管，直觉概率就不再代表真实安全性。PeerDAS 是网络协议与共识规则，不是一条孤立公式。

05 / 13

PeerDAS · shipped

PeerDAS：把“人人下载全部”改成可验证的分工

PeerDAS 已随 Fusaka 上线主网。它不只是抽样算法，而是一整套数据列、托管子网、请求、重建与分叉选择规则。

在 EIP-4844 的初始设计中，每个共识节点仍下载每个 Blob。Blob 数量提高多少，单节点下载量大致就增加多少，这会把带宽较低的 家庭节点推向边缘。PeerDAS（EIP-7594）把每个扩展 Blob 切成 128 列，再让节点按 node ID 确定性地加入若干列子网并托管相应数据。节点每个 slot 从多个对等节点请求和验证列，而不是下载全部 Blob。

Custody & sampling

同一份扩展数据，由不同节点覆盖不同列

FIG 05
图只画 12 列以便阅读，实际 PeerDAS 使用 128 列。普通节点当前至少托管 8 个 custody group；聚合验证者余额达到 4096 ETH 的节点须作为 supernode 托管全部列。参数属于协议配置，未来可以调整。

一次成功的数据可用性检查，发生了什么？

  1. 发送者准备证明：Blob 交易发送者为扩展后的每个 Cell 计算 KZG proof，避免所有区块生产者重复做昂贵计算。
  2. 网络按列传播：一列包含本区块各个 Blob 在同一索引位置的 Cells，并映射到一个 gossip subnet。
  3. 节点履行 custody：节点由自身 ID 决定必须订阅和保存哪些列，不能只挑“最轻松”的部分。
  4. 节点从 peers 抽样：收到 Cell 后验证它与 Blob commitment 一致，并判断所需列能否及时取得。
  5. 可用性进入共识：验证者只有在数据可用性检查通过后才支持区块；缺数据不是“稍后补”，而会影响分叉选择。

当前下载比例的直觉

普通节点托管 128 列中的 8 列，即扩展数据的 1/16；因为纠删码把原 Blob 扩展为约两倍，这相当于原始 Blob 数据量约 1/8。EIP-7594 把它描述为“下载一小个常数比例”，未来可通过更多列进一步降低单节点比例。

PeerDAS 还不是完整 Danksharding

PeerDAS 使用逐 Blob 的一维纠删码，是已经交付的扩容步骤。完整 DAS / Danksharding 设想在更大的二维数据矩阵上 编码、抽样与重建，以继续提高数据容量；它仍属于未来工作。路线图名称表达方向，不等于某个固定规格或交付日期。

组件解决的问题单独做不到什么
纠删码增加冗余，让足够比例的列可以重建原数据不能证明收到的 Cell 没被篡改
KZG / Cell proof证明某个 Cell 与已承诺 Blob 一致不能证明其他列已发布
Custody + P2P把列分配给许多节点托管和服务不能替代本地验证
Sampling + fork choice发现数据隐藏，并拒绝不可用区块不能提供永久历史档案
06 / 13

Stateless verification

无状态验证：不带整座图书馆，也能核对这一页

“Stateless” 是一个容易误导的名字。世界状态没有消失；只是多数验证节点不必在本地保存完整状态数据库。

先把 State、History 与 Blob 分开

数据它回答什么验证下一个区块是否直接需要典型保存方式
State / 状态“现在是什么”：余额、nonce、字节码、合约 storage需要本区块触及的状态值当前完整节点保存本地状态数据库
History / 历史“过去发生过什么”：旧区块体、交易、收据通常不需要普通节点保留一段；档案服务长期保留
Blob / DA 数据“L2 批次能否被重建”在协议可用性窗口内需要共识层限时托管，之后可由外部归档

当前执行层节点从本地状态数据库读取区块涉及的账户和 storage，执行所有交易，然后计算新状态根。 设旧状态为 Sₙ、区块交易为 Bₙ、以太坊状态转换函数为 Υ：

Sₙ₊₁ = Υ(Sₙ, Bₙ)；验证通过 ⇔ root(Sₙ₊₁) = 区块声明的 stateRoot

问题是，为了读取本区块可能触及的少量键，每个节点今天仍准备着巨大的完整状态。状态只增不减时，磁盘容量、随机 I/O、 同步时间与数据库维护都会逐渐成为参与门槛。

Local state vs witness

今天带着整棵树；无状态验证只带本区块的枝条

FIG 06
Witness（见证）包含执行本区块所需的状态值、代码、存在或不存在证明，以及把这些片段连接到旧状态根的认证路径。验证者先核对见证属于 Sₙ，再执行交易并算出 Sₙ₊₁。

弱无状态与强无状态

Weak statelessness

生产者保存全状态，验证者只用见证

区块构建者读取完整状态并生成 Witness；大量普通验证节点接收区块和 Witness，无需本地完整状态数据库。这是更现实的路线方向。

Builder
full stateValidators
block + witness

Strong statelessness

交易自己携带见证，不要求单一完整保存者

用户或交易附带访问清单与 Witness，生产者再聚合。它把更多状态责任推给用户和应用，复杂合约交互会更难；当前不被视为近期主线。

Users
tx + witnessBuilder
aggregate

去中心化的反直觉风险

无状态化降低“验证”门槛，却可能让“保存和服务状态”集中到少数 builders、RPC、搜索者与浏览器。若被审查交易所需状态拿不到，连强制包含机制也可能失去材料。谁保存、谁服务、谁能证明自己愿意服务，是一级安全问题。

07 / 13

Witness anatomy

见证到底装什么？让一笔交易自己回答

见证不是“新状态的截图”，也不必是零知识证明。它是让验证者从旧状态根出发完成本区块执行所需的最小状态材料与认证路径。

假设 Alice 向 Bob 转账。执行需要读取 Alice 的余额和 nonce、Bob 的余额，并验证这些值属于旧状态根。若调用代币合约， 还要提供合约字节码、相应 storage 槽及证明；若经过 AMM，再加入池子储备、费用参数和相关代码。 交易碰到的状态越广，Witness 通常越大。

Interactive witness builder

选择一次执行，看看验证者需要哪些状态片段

实验只在本页内切换预设教学案例，不读取钱包、不连接网络，也不保存数据。

Execution request

FROMAlice
TOBob
ACTION发送 1 ETH
READ2 个账户
WRITE余额 × 2，nonce × 1

Required witness

4 类材料

  • Alice accountvalue + proof
  • Bob accountvalue + proof
  • non-existence / empty slotswhen needed
  • authentication siblings→ old root

这里数的是“材料类别”，不是实际字节数。真实 Witness 会合并重复证明路径、包含协议规定的代码与访问事件，并受所选状态树和编码方式影响。

验证者拿到 Witness 后做五步

  1. 用证明路径确认每个值或“不存在”声明属于旧状态根 Sₙ。
  2. 按区块顺序执行所有交易，不能只相信生产者给出的结果。
  3. 检查访问未超出 Witness 覆盖范围；缺少所需值时不能完成验证。
  4. 对更新后的叶子和认证路径重新承诺，计算新状态根。
  5. 比较计算结果与区块头声明的 stateRoot；不一致则拒绝区块。

Witness 与 ZK proof 的区别

普通状态 Witness 提供“你自己复算所需的输入和成员证明”；ZK validity proof 则让验证者检查一个证明，确认某次计算满足约束。未来 L1 zkEVM 可以与无状态 Witness 互补，但二者不是同一个概念。

见证不是免费午餐

本地磁盘读取变少，网络要传输 Witness；生产者要生成它；状态树要支持足够小、足够快的多证明；Gas 还必须准确反映“触及多少独立状态” 的资源成本。无状态化是在磁盘、带宽、证明生成和生产者专业化之间重新分配成本。

08 / 13

State tree roadmap

Verkle 还是二叉树？先抓住目标，再看方案演化

状态树是“状态根”和 Witness 的底层结构。2026 年路线正在演化，不能把任何候选写成已经确定上线。

以太坊当前执行状态使用 Merkle Patricia Trie（MPT）：账户、合约 storage 和代码通过多层结构组织，并以 state root 承诺。它适合今天的完整状态验证，却不适合给成千上万个分散访问生成很小的区块级 Witness；RLP、十六叉结构、树中树和特殊编码 也增加了证明与客户端复杂度。

Roadmap, not a promise

三代状态树思路：当前、旧主线候选与 2026 新方向

FIG 07
ethereum.org 仍保留 Verkle 教学资料，但 EIP-6800 当前为 Stagnant；以太坊基金会 2026 协议优先级写的是长期转向 binary trees 与 statelessness，EIP-7864 仍为 Draft。目标稳定，具体机制仍可能变化。

为什么树的形状会影响 Witness？

要证明某个叶子属于根，通常要附带路径上每一层的“兄弟承诺”。分叉数、深度、承诺算法、多个访问能否共享路径，都会影响证明大小。 Verkle 依赖向量承诺，可高效聚合很多叶子；统一二叉树用更简单的二叉 Merkle 结构，普通分支较规整，并可选择更适合 有效性证明的哈希。两者的安全假设、后量子属性、客户端迁移和 ZK 成本不同。

方向主要优势主要代价截至 2026-07-26
MPT主网成熟、客户端长期运行多证明大、结构与编码复杂、ZK 不友好当前主网
Verkle聚合 Witness 很小新椭圆曲线密码栈、迁移复杂、非后量子EIP-6800 Stagnant，未上线
统一二叉树结构更简单、普通证明与 ZK 方向兼容哈希、Witness、迁移仍需定案EIP-7864 Draft，未上线

如何阅读路线图

把“无状态验证”当作目标，把 Verkle、二叉树、区块级访问列表、zkEVM 等当作可替换或互补的实现路径。路线图是当前最佳假设，不是不可变的产品排期。

一个已上线的铺路例子：EIP-2935

Pectra 把最近 8191 个区块哈希放进系统合约维护的环形缓冲区。这样未来无状态执行遇到 BLOCKHASH 时， 相关哈希可以作为显式状态和 Witness 提供，而不必依赖节点私下保留的历史数据库。它展示了简化的一个原则： 把隐式依赖变成可承诺、可携带、可验证的显式状态。

09 / 13

Expiry & archival

Blob、历史、状态都能“过期”，但过期的不是同一件东西

最危险的误解是听到“修剪”就以为余额或合约被删除。先问：删的是临时载荷、过去记录，还是当前活跃状态？

Three different lifecycles

三条时间轴：限时可用、历史归档与状态复活

FIG 08
只有前两条已经有部分主网实践；状态过期仍是研究方向。无论哪条，“普通节点不再默认保存”都不等于“不可恢复地销毁”。

历史过期：删的是旧区块体与收据，不是当前余额

验证下一个区块通常不需要保存创世以来所有旧交易和收据。PoS 节点可以从可信的弱主观性检查点启动，再验证近期链。 2025 年 7 月起，主流执行客户端开始支持部分历史过期，可移除 The Merge 之前的历史；Fusaka 的 EIP-7642 让节点声明自己最早服务到哪个区块，并清理不再需要的网络字段。[08]

这不等于 EIP-4444 设想的“滚动一年窗口”已完整交付。EIP-4444 当前为 Stagnant，完整历史服务、同步、JSON-RPC 体验、 激励与抗审查仍需生态协调。过去数据可以由档案节点、机构镜像、种子文件、Portal 类网络或专门客户端保留；取得后可用区块头 和承诺验证。

历史保存的信任变化

从“几乎每个完整节点都顺手保存”变为“至少有一些独立来源愿意长期保存并提供”，会降低普通节点磁盘负担，也会引入可服务性、审查和提供者集中风险。可验证不等于一定有人在线提供。

状态过期：让冷状态退出活跃集合，不是烧掉资产

状态过期（state expiry）针对久未使用的账户、合约 storage 和代码。研究思路包括： 为状态标记并在一段时间后休眠，或按年份等“era”冻结旧状态树。以后再次访问时，调用者附上旧状态存在证明，把它复活进当前活跃集合。 资金与合约逻辑并没有被销毁，只是普通节点不再把冷状态放在快速数据库中。

细节仍未定：谁保存冷状态？复活证明由谁构造？用户忘记保存自己的数据怎么办？复杂合约跨多个 era 读写如何收费？ 2025 年底以太坊基金会状态团队仍在比较 mark-expire-revive、多 era、状态档案与 partial-state 节点等方向。 因此页面把状态过期标为研究，不承诺升级名称或日期。[10]

概念普通节点不再默认保存仍然保留当前状态
Blob 修剪超过协议窗口的原始 Blob链上承诺；外部可保存原数据已运行
部分历史过期Merge 前区块体、收据等当前状态与可验证的链头客户端已支持
滚动历史过期超过滚动窗口的旧历史外部档案与承诺EIP-4444 未完整交付
状态过期久未访问的活跃状态副本休眠状态及复活证明路径研究中
10 / 13

Protocol simplification · The Purge

协议简化：安全也来自更少的特殊情况

The Purge 不是某天发生的一次硬分叉，而是跨许多升级持续删除技术债、限制极端输入、显式化历史依赖的工作主题。

共识协议最怕“两个正确实现对边缘情况得出不同结果”。每个旧字段、无限输入、历史语义和特殊 opcode 都扩大测试空间； 多客户端必须在每条分支上精确一致，否则可能分叉。简化的安全价值来自更小的状态机、更有限的输入域、更少的兼容代码和更容易 被形式化、审计与证明的规则。

Complexity funnel

不是“一键删除”，而是逐项收敛协议表面

FIG 09
右侧并不全是未来计划：其中多项已分别随 Dencun、Fusaka 和客户端更新交付。简化是一组具体变更，不是营销式的“代码变少”。

四个具体例子

EIP-6780 · shipped

收敛 SELFDESTRUCT

Dencun 后，除非合约在同一笔交易内刚创建，调用不再删除代码、storage 与账户，只转移余额。opcode 尚未完全移除，特殊同交易情形仍存在。

EIP-7642 · shipped

eth/69 清理与历史范围

删除 Merge 后失去意义的 total difficulty，节点声明最早服务区块，并从 P2P 收据传输移除可重算的 Bloom，降低旧字段和同步负担。

EIP-7823 · shipped

给 MODEXP 极端输入设上限

无限测试表面曾造成多次共识 bug。限制输入长度后，客户端能穷尽更多边界测试，也更容易规划最坏执行成本。

EIP-7864 · draft

统一二叉状态树

把账户头、代码与 storage 放到一个逻辑树，去掉部分 MPT 特殊结构，并为普通证明、ZK 与未来无状态规则提供更简单底座。

为什么不能粗暴删除？

协议规则是既有合约和基础设施的公共接口。修改 SELFDESTRUCT 可能破坏依赖 CREATE2 反复部署的旧模式； 历史过期会让旧 eth_getLogs 查询依赖专门服务；新状态树需要迁移数亿状态项并确保所有客户端在同一根上收敛。 每次“清理”都必须同时处理向后兼容、数据恢复、多客户端一致、网络过渡与用户退出路径。

Purge 的判断标准

真正的简化不是让规范文字更短，而是让诚实节点要实现、测试、存储和传播的共识关键表面更小，同时不把不可验证的信任转移给少数外部服务。

11 / 13

Synthesis & status

三条路线最后汇合：从“人人保存全部”到“人人都能验证”

数据、状态和历史的保存职责被拆开，但密码学承诺、可用性规则与独立执行仍把它们连接成一套可验证系统。

减少单节点负担 = 分工保存 + 有限窗口 + 可验证承诺 + 独立恢复路径
原始瓶颈路线普通节点少做什么系统必须补上的保证
Rollup 数据增长Blob + PeerDAS不再下载所有 Blob 全部字节纠删码、Cell proof、custody、抽样、fork choice
世界状态增长Witness + 新状态树 + 无状态验证不再本地保存完整活跃状态状态提供者、认证路径、可执行 Witness、抗审查服务
古老历史增长历史过期 + 档案分工不再保存并服务全部旧区块体和收据独立档案来源、可发现性、可验证下载、同步路径
协议技术债增长语义收敛 + 字段清理 + 输入上限不再维护无意义或无限的旧分支兼容迁移、测试、明确替代接口

截至 2026-07-26 的交付状态

Shipped

Blob、PeerDAS 与 BPO2

Dencun 引入 EIP-4844；Fusaka 上线 PeerDAS；BPO2 后主网 Blob target/max 为 14/21。

Shipped

部分历史过期与多项简化

客户端支持移除 Merge 前历史；EIP-6780、7642、7823 等已收敛语义、网络字段和极端输入。

Active design

统一二叉树、访问列表与 L1 证明

长期方向是 binary trees 与 statelessness；相关 EIP 和 zkEVM 验证仍在设计、实现或测试。

Research

状态过期、完整 DAS 与强无状态

安全目标清晰，机制与顺序仍可变化；不能据路线图名称推断已上线功能或确定日期。

最后做一次安全审计式追问

  • 谁能隐藏数据？抽样节点是否有足够多样的 peers，custody 是否广泛覆盖，缺列会不会及时影响投票？
  • 谁生成 Witness？若少数 builders 垄断完整状态，普通验证便宜是否换来了构建与审查集中？
  • 谁保存过去？档案是否多源、可发现、可验证，还是所有应用最终都依赖同一家 RPC？
  • 谁承担迁移风险？状态树与 EVM 语义改变时，客户端、合约和工具是否有明确兼容与退出方案？

最重要的反直觉

“所有人不必保存”降低了参与成本；“总得有人保存”又可能制造专业化与集中。优秀路线不是消灭这一矛盾，而是让保存者可替换、数据可证明、验证者足够多、用户在保存者失灵时仍有恢复路径。

12 / 13

Recap & self-check

先拆掉六个误区，再做六题自检

如果能把下面每个错误说法改写准确，你已经掌握了本课真正的安全边界。

“有 KZG 承诺，数据就一定可用。”

KZG 证明样本与承诺一致；可用性还需要纠删码、传播、custody、抽样与 fork choice。

“Blob 是放在以太坊外面的数据。”

Blob 由以太坊共识层保证限时可用，只是不进入 EVM、也不要求普通节点永久保存。

“无状态客户端没有状态。”

状态仍在系统中；验证者以 Witness 取得本区块所需片段，不必本地持有完整副本。

“Verkle 已确定是下一代主网状态树。”

EIP-6800 为 Stagnant；统一二叉树 EIP-7864 为 Draft，具体路线仍在演化。

“历史过期会清掉休眠账户和余额。”

历史修剪处理旧区块体、交易和收据；当前世界状态是另一类数据。

“The Purge 是未来某次单独硬分叉。”

它是持续的简化主题；限制 SELFDESTRUCT、部分历史过期与 eth/69 清理都已分批发生。

一句话复述本课：以太坊把“每个人保存全部”拆成“不同角色保存不同部分”，再用承诺、证明、抽样和共识规则维持任何人的独立验证能力。

六题自检

1. 某节点成功验证一个 Cell 的 KZG proof，能否据此独自断定完整 Blob 已发布？

答案 B：承诺与样本证明解决完整性，不单独解决全体数据可用性。

2. 为什么 DAS 先做纠删码，而不是直接从原始文件随机抽几个字节？

答案 C：冗余既支持恢复，也把“小片段隐藏”变成更容易被抽样发现的大面积隐藏。

3. “无状态验证”最准确的含义是什么？

答案 A：状态仍存在，验证者通过 Witness 取得所需片段和证明。

4. 弱无状态模式下，谁通常仍需要完整状态来构建区块和 Witness？

答案 B：弱无状态降低验证门槛，但没有消除完整状态持有角色。

5. 客户端修剪 Merge 前执行历史，会发生什么？

答案 C：历史与当前状态是不同数据面。

6. 协议简化为什么也是安全工作？

答案 A：简化降低实现、测试、审计和证明复杂度，但仍必须妥善处理兼容与数据可恢复性。

13 / 13

Glossary & primary sources

术语与一手资料

本课把“已上线”“客户端已支持”“EIP 草案”和“研究方向”分开标注。路线与参数会继续变化，核对日期为 2026-07-26。

核心术语

Data availability / 数据可用性
足以独立验证或重建状态的数据，确实在协议所需时间窗口内向网络参与者发布的保证。
Data retrievability / 数据可检索性
在未来某时还能取得历史数据的能力；它是档案目标，不等同于新区块当下的可用性。
Blob
EIP-4844 引入的 128 KiB 临时数据对象，面向 Rollup 数据发布；由共识层而非 EVM 负责可用性。
KZG commitment
对 Blob 所表示多项式的简洁承诺；可验证某点或 Cell 与承诺一致，但本身不携带完整数据。
Erasure coding / 纠删码
把原数据扩展为带冗余的数据，使取得足够子集即可重建，并让不可恢复攻击必须隐藏较大比例。
DAS / 数据可用性抽样
节点只下载少量样本，以高置信度判断足以恢复的完整数据是否已发布。
PeerDAS
EIP-7594 定义的一维 DAS 网络协议，包含列、Cell proof、custody 子网、对等请求与可用性检查。
Custody
节点按协议对特定数据列承担保存与服务责任；它把可用性从临时抽查扩展为网络分工。
State / 世界状态
以太坊“现在知道什么”：账户余额、nonce、合约代码和 storage，经状态根统一承诺。
Witness / 见证
执行某区块所需的状态片段、代码、存在或不存在证明及连接到旧状态根的认证路径。
Weak statelessness / 弱无状态
生产者或构建者仍持有完整状态，多数验证节点只用区块、Witness 与状态根完成验证。
State expiry / 状态过期
把久未使用状态移出活跃集合，并允许以后用旧状态证明复活；它不是销毁余额。
History expiry / 历史过期
普通执行节点停止默认保存或服务较旧区块体、交易与收据，不影响当前世界状态。
The Purge
跨多个升级持续减少历史负担、旧字段、危险语义和协议技术债的路线主题，不是单次分叉。

官方规范、路线与研究原文

01 · EIP-4844

Shard Blob Transactions

Blob 格式、4096 × 32 字节、EVM 只访问承诺、共识层可用性与 4096 epoch 服务窗口。

03 · EIP-7594

PeerDAS

一维纠删扩展、Cell、列、custody、对等抽样、50% 重建阈值与安全考虑。

04 · CONSENSUS SPECS

Fulu DAS core specification

PeerDAS 在共识层的正式数据列、托管、采样、恢复与验证规则。

05 · ETHEREUM.ORG

PeerDAS explainer

128 列、普通节点 custody、4096 ETH supernode、fork choice 与未来 FullDAS 的解释。

06 · EIP-8135

Blob Parameter Only 2

BPO2 的主网 target 14、max 21 参数及 2026-01-07 激活信息。

07 · ETHEREUM.ORG

Data availability

DAS、纠删码、Rollup 数据需求，以及 availability 与 retrievability 的区别。

08 · EF PROTOCOL

Partial history expiry

执行客户端移除 Merge 前历史的支持、预计磁盘节省与后续滚动历史过期工作。

09 · EIP-4444

Bound Historical Data

滚动一年历史服务窗口的原始方案、检查点同步、档案责任和集中风险；当前状态为 Stagnant。

10 · EF RESEARCH

The Future of Ethereum’s State

无状态化后的状态服务集中风险，以及 state expiry、archive 与 partial-state 节点方向。

12 · ETHEREUM.ORG

Verkle trees

MPT Witness 问题、向量承诺与 Verkle 多证明为何曾适合无状态路线。

资料核对日期：2026-07-26。EIP 的 Final、Draft、Stagnant 等状态和升级纳入范围会变化；运行节点、开发基础设施或据此做产品决策前，请再次核对官方升级公告、EIP 状态与客户端发布说明。

Lesson complete · 18.03

少保存，不等于少验证。

PeerDAS 把近期数据分给网络抽样和托管；Witness 把执行所需状态随区块带来；历史过期与协议清理把旧负担移出普通节点。 三者共同追求的不是“什么都不存”，而是让保存职责可分工、数据可恢复、承诺可核对、验证仍然属于每个人。