以太坊2030愿景：计算转向密码学证明，谁来验证结果？

Vitalik Buterin 在 9 月 27 日的愿景中描述了以太坊从一个每个验证者都要重复大量工作的系统，转向一个可以对数据进行采样、并可以用简洁证明来检查执行的系统。其中一部分，PeerDAS，已经上线。更大的执行转变仍在开发中。证明可以确立某项计算遵循了指定规则，但用户仍然需要数据、一种提交交易的方式，以及一个决定谁的结果成为最终结果的协议。

标题问题有两个答案。证明者生成密码学证明；验证者，可能是任何运行相关软件的验证节点，根据规则和公共输入检查该证明。以太坊基础层 zkEVM 路线图表示，验证应该比重新执行每笔交易便宜得多。但判断一个证明是否可靠，并不能单独解决交易数据是否可用，或者运营者是否可以扣留用户交易的问题。

Buterin 的9 月 27 日文章《密码学世界计算机》将目标描述为区块链、密码学隐私与验证，以及去中心化链下组件的结合。他将旧的下载并重新执行模式，与节点采样数据并验证证明的模式进行了对比。他还描述了共识和区块构建方面其他可能的变化。这是个人技术愿景，不是所有以太坊客户端团队批准的最终升级规范。

现有内容与愿景内容之间的区别很重要。根据以太坊基金会 2026 年 2 月的协议更新，PeerDAS 随 2025 年 12 月的 Fusaka 一同到来。基金会表示，验证者现在采样 blob 数据，而不是下载全部数据。网络范围内转向验证基础层区块的简洁执行证明，并未被描述为已经部署。如果读者听到以太坊“将在 2030 年验证证明”，应该问是哪种证明、它覆盖谁的计算，以及哪些参与者可以独立测试它。

PeerDAS 检查的是数据可访问性，而不是每一次计算

已经部署的部分是 PeerDAS，即点对点数据可用性采样。Rollup 将交易数据放入以太坊 blob 空间，以便其他参与者可以检索足够的信息来重建状态，并让运营者遵守规则。让每个节点下载每个 blob 的旧方法，会使更大的数据量对普通验证者来说变得昂贵。采样要求节点根据密码学承诺检查小块数据，同时网络分发足够的编码片段以供重建。

以太坊的解释称，扩展后的 blob 数据被分成 128 列。普通节点加入至少 8 个随机选择的列子网。8 除以 128 是扩展数据的十六分之一。编码增加了冗余，因此根据文档描述，这一数量大约相当于原始数据量的八分之一。这些数字指的是默认节点的数据工作量，并不是声称一个节点可以亲自以八分之一的成本持有每个 rollup 的全部历史。

里德-所罗门式编码会生成冗余数据片段，而密码学承诺帮助节点检查被抽样的片段是否属于已公布的内容。抽样在参与节点之间提供了一种概率性的可用性保证。它并不能取代执行验证。一批完全可用的交易可能包含无效的状态转换。同样，如果重建账户状态所需的数据在可用性保证之外被扣留，那么关于状态转换的有效证明也不足以让用户重建账户状态。

以太坊基金会表示，Fusaka 使理论上的 blob 容量提升了八倍。“理论上”这个词很重要：实际持续吞吐量取决于计划中的参数提升、网络状况以及 rollup 的使用情况。Crypto.news 已经解释了 rollup 如何使用以太坊的数据层。Buterin 的新文章将 PeerDAS 视为迈向一个“验证更多、重复更少”的系统的第一个可见步骤；它不应被重新包装为最终的执行证明升级。

证明者承担繁重工作；独立节点进行检查

在基于证明的执行模型中，仍然必须有人执行交易并构建关于结果的证据。该方可能会使用昂贵的专用硬件和软件。简洁证明让验证者能够以低得多的成本检查所声称的状态变更是否遵循了协议规则下所承诺的程序和输入。数学检查并不要求验证者仅仅因为证明公司生成了证明就信任它。

这一说法附带有条件。验证者必须运行一个健全的证明系统，并使用正确的验证密钥、公开输入和商定的执行规则。一个有缺陷的电路可能完美地证明错误的陈述。客户端实现中的漏洞可能接受本应拒绝的证明。一个能够在缺乏稳健控制的情况下更改验证者代码的升级密钥可能会削弱这一保证。在一个运行中的协议里，独立实现和审查与快速生成证明同样重要。

以太坊的L1 zkEVM 路线图页面描述了一个未来：节点检查区块执行的证明，而不是重复每一笔交易。其既定目标是降低验证的资源成本。如果证明验证在可获得的硬件上仍然切实可行，这将使更多人更容易检查区块。这并不意味着每个家庭都能生成区块证明，也不意味着证明生成将均匀分布。

Crypto.news 报道了围绕证明生成的硬件竞争。有用的区分在于：谁能够及时为链生成证明，以及谁能够廉价地验证证明。证明生成可能会集中在拥有专用硬件的公司手中，但这并不会自动让这些公司能够伪造有效的状态转换。它仍可能引入一种活性依赖：如果能够足够快地生成证明的参与方太少，那么即使证明系统在数学上仍然健全，区块或最终性也可能变慢。这与无效证明被接受是另一种不同的风险。

因此，验证问题既有数学上的答案，也有人类层面的答案。开发者设定电路，研究人员审计它，客户端团队实现它，节点运营者运行验证者，参与者决定是否接受协议升级。Buterin 可以提出一个方向。但他无法单凭自己让未来的验证者对网络变得安全或强制。

“证明”一词常常糅合了三个承诺

假设一个用户通过 rollup 发送一笔支付。该交易必须被包含在一个有序批次中。该批次的数据必须按照 rollup 所选择的模型变得可用。最后，由此产生的状态变更必须遵循其规则。排序、可用性和正确性是彼此独立的承诺。正确性证明针对指定的计算解决了最后一个问题。PeerDAS 解决了以太坊 blob 数据的可用性问题。排序器或区块构建机制则影响哪些交易被包含以及以何种顺序被包含。

Crypto.news 将排序器视为一个独立的控制点进行了审视。一个完全有效的证明可以证明某个批次是按照规则处理的，即使其运营者排除了某个特定客户的交易。根据该 rollup 的设计，用户可能拥有逃生通道或强制包含路径，但证明本身并不能强制实现公平访问。排序器还可以在仍产生有效状态转换的同时对交易重新排序。所证明的陈述不应被误认为是用户希望从市场获得的所有属性。

数据方面同样容易被模糊。以太坊的validium 文档描述了使用有效性证明但不将交易数据发布到以太坊主网的系统。根据验证者的判断，它们的执行可能是正确的，但数据可用性故障可能会阻止用户按预期重建状态或提款。在以太坊上发布足够数据的以太坊 rollup 具有不同的可用性模型。将两者简单地称为“ZK”掩盖了用户在没有运营者的情况下恢复账户状态能力方面的关键差异。

最简单的测试是一个三列的心理清单。问谁将交易放入批次。问重建余额所需的数据可以从哪里获取。问哪个合约或节点验证状态正确性的证明。如果一个项目只回答了第三个问题，它就没有回答前两个问题。这就是为什么 Buterin 的文章在讨论密码学的同时还讨论了区块构建和网络数据分发，而不是用一个神奇的证明取代整个系统。

基础层无法从现有 rollup 借用所有属性

ZK rollup 已经根据各自的合约和规则向以太坊提交有效性证明。关于 ZK rollup 的以太坊文档描述了运营者为批次创建证明，以及验证者合约仅在验证后才接受新的状态根。这是证明计算的有用先例。这并不意味着以太坊的基础层已经将所有执行验证转移到此类证明上。

范围不同。rollup 在其自己的虚拟机和合约下证明自己的状态转换，而以太坊的基础层验证者则必须以客户端团队接受的方式检查协议的区块执行。rollup 的自定义逻辑与以太坊主网执行规则之间的不匹配，并不是更快的证明器可以凭空消除的细节。证明系统还必须在协议升级、新交易类型和对抗性输入中保持稳健。

应用程序可以将其算术外包给协处理器，并提供带有证明的结果，但基础链仍然决定是否接受公共输入、存储承诺并结算最终状态。应用程序或许能够选择自己的证明器设计；而基础层规则需要跨客户端和验证者的广泛协调。Buterin 的“密码学世界计算机”这一说法作为架构方向是有用的，但并不是承诺单个证明服务将运行整个以太坊。

有一个明显的矛盾值得解决。如果节点停止重新执行，那么任何人如何发现被证明的计算中的错误？一个答案是，开发者可以在开发和部署后运行独立的完整执行，并将其与证明结果进行比较。另一个答案是多个证明实现和电路的形式化检查。确切的以太坊设计尚未最终确定。一个减少所需重新执行的协议并不禁止人们执行额外的检查；它改变的是每个普通验证节点为达成共识必须做的事情。

基金会的九月协议优先级更新将 L1 zkEVM 和形式化验证视为主要工作流。这是活跃工程开发的证据，而不是确定的启动日期。安全标准很高，因为基础层证明系统中的错误将影响其他应用程序所依赖的基础。

证明可能改进验证，而状态问题却在增长

Buterin 将访问非常大的共享状态列为一个特别困难且未解决的问题。Crypto.news 审视了他关于基于证明的 mempool 扩展的单独提案，该提案针对的是与最终状态执行不同的瓶颈。证明可以证明计算，但证明器必须获取该计算所依赖的信息：余额、合约存储和其他账户状态。如果许多交易同时触及同一状态，将计算拆分到多台机器上就会变得更加困难。来自一个账户的支付和触及流动性池的交换无法从不一致的快照中同时最终确定。

这篇文章表明，应用程序可以将排序和非交换状态变更放在链上，同时在纳入之前聚合其他计算。这是一种架构上的激励，而不是当今对开发者的约束性规则。“非交换”意味着改变顺序会改变结果。两个人从同一个稀薄池中购买，可能会因处理顺序不同而得到不同的价格。没有任何证明能使这两个订单在经济上等价。

这是对简单化的免费扩展承诺的有益制衡。当任务能够被安全分离时，并行工作会更容易。共享状态会产生依赖关系。证明者可以快速执行许多独立计算，却仍要等待对争议状态的访问或区块构建者的排序选择。仅提高证明速度并不能解决数据库争用、审查或使足够信息对其他参与者可用的成本问题。

在Buterin看来，一个更强大的去中心化中间层可以并行处理工作，并在某些情况下保护关于请求来源的元数据。这样的基础设施可能会改善性能或隐私，但它必须明确数据如何分发、谁可以加入，以及哪些故障有逃生路径。用户支付的隐私并不是使用有效性证明的自动结果。除非系统也保护这些部分，否则公共输入、钱包活动和网络元数据仍可能泄露信息。

独立性可以在最终分叉之前被衡量

“任何人都可以验证”是有实际条件的。一个普通节点需要验证者代码、相关的公共输入、与链上已接受状态的连接，以及足够的处理能力，以便在协议时限内完成检查。如果一份证明在一台普通机器上需要几秒钟来检查，但在昂贵硬件上需要数小时来生成，那么该系统可能实现广泛的验证，却只有狭窄的生产。只要生产者的故障不会成为结算的永久障碍，这对于正确性来说可能是一种可接受的工程权衡。

这个实验在概要上很直接。用来自多个客户端团队的验证者软件针对同一个有效区块证明运行，并确认它们接受该证明。提供被篡改的公共输入，并确认其被拒绝。询问不同的证明团队是否能为同一规则生成被接受的证明、他们能多快做到这一点，以及各自需要什么硬件。在公共测试网络上于高负载下重复这一点，会比在实验室中演示一个快速证明更能说明准备情况。以太坊的确切接受标准仍取决于协议工作；这些是可观察的问题，而不是官方的通过阈值。

证明生成还有另一种失效模式，有效性检查本身无法捕捉。证明者可能拒绝为一个被提议的区块生成证明。验证者无法接受一份尚未到达的证明。设计可以通过允许多个独立证明者、回退执行路径、调整时序或其他机制来解决这一点。这一选择将影响复杂性、成本和最终确定时间。不应仅仅因为路线图说证明验证是一个目标，就把以太坊当前的基础层规则描述为已经选择了这些未来解决方案之一。

独立性还意味着用户可以获取验证其自身资产主张所需的信息。一份证明某个状态根遵循代码的证明很强大，但如果用户无法从其账户数据重建到该状态根的路径，那么在实际余额检查中仍要依赖中介。PeerDAS降低了对每个节点的blob数据可用性要求，同时依赖网络中的分发和采样。保存在其他地方的应用程序数据需要有自己的可用性保证。链上的证明验证者无法强迫外部运营者发布被扣留的记录。

最后，被验证的程序必须是用户所认为的那个程序。验证者代码的公开哈希、有文档记录的升级流程，以及对电路行为的独立测试，让外部人员能够将宣传的规则与节点实际执行的规则进行比较。形式化验证可以缩小逻辑错误的机会，但它同样始于人类编写的规范。可检查的结果并不是“密码学解决了信任”。而是当某个特定主张的证据无效时，该主张可以被独立拒绝，而无需每个节点都支付生成它的全部成本。

Hegota 是一个标记，而非 2030 年发布的保证

Buterin 提到 Hegota——一个计划于 2027 年进行的分叉——可能是最后一个其组成部分对 2015 年的以太坊观察者来说仍属熟悉的升级。在他的叙述中，后续工作将涉及递归 STARKs、形式化验证、优化共识和量子安全。Crypto.news 报道了单独的 2029 年量子目标，将其作为一个规划目标。无论是这篇文章还是某个目标日期，都不能证明每个提议的组成部分都会如期准备就绪并被采用。

以太坊升级需要规范、客户端实现、测试网络、安全审查以及参与者之间的协调。路线草图是一份研究和候选里程碑的地图，而非链上实施。人们可以通过查看 Fusaka 版本和当前节点规则来验证 PeerDAS 已部署。人们无法通过查看一篇文章中蓝色的 2030 年栏目来验证未来的通用基础层 zkEVM。证据将首先出现在公开规范和测试中，然后是具体的分叉计划和生产激活。

支持 Buterin 方法的论据很有力。如果验证变得廉价，且数据可以被安全采样，那么更多用户就可以独立检查一个更大的系统，而无需购买与其全部计算和数据相称的机器。挑战同样真实：证明堆栈必须安全、具有竞争力地生产，并且足够快以保持系统运行，同时数据和排序仍可访问。一个验证廉价但依赖单一不可或缺的证明者或排序者的网络，可能仍然脆弱。

这篇文章并未解决谁将构建每一个证明，或哪种证明系统会胜出。它确实指出了一个对用户至关重要的测试：一个普通的独立参与者能否拒绝一个坏结果、恢复了解自身状态所需的数据，并在任何单一运营者存在的情况下提交交易？每个答案都需要单独的机制。密码学检查之所以强大，恰恰是因为它可以被那些没有做繁重工作的人重复执行。

值得关注的内容

• L1 zkEVM 规范。关注一个具体的验证器、公开输入格式以及各客户端普遍接受的执行规则。
• 证明者多样性。多个独立实现以及实测的硬件需求，将检验证明生成是否存在单一瓶颈。
• PeerDAS 测量数据。在 2025 年 12 月上线后，随着参数提升，检查 blob 吞吐量和节点带宽。
• Hegota 决策。在路线图草案中，最终的分叉范围比候选功能更重要。
• 数据与排序保障。检查 rollup 和未来基础层设计是否保留了独立重建和交易纳入能力。

常见问题