讨论 区块链 以太坊为何不满足于 ZK-EVM + PIR 带来的无需信任与隐私?

以太坊为何不满足于 ZK-EVM + PIR 带来的无需信任与隐私?

Joe 发表于    阅读:42    回复:0

除了对网络安全性的担忧外,提高以太坊 L1 Gas 限制最常见的批评是:它会增加运行全节点的难度。

特别是在当前聚焦于“解耦全节点功能”(unbundling the full node)的扩容路线图背景下,要应对这一问题,首先需要理解全节点存在的根本目的。

传统观点认为,全节点的作用是验证区块链;我此前也曾阐述过,如果普通用户无法自行验证链,可能会引发哪些风险。如果这确实是唯一的问题,那么通过 ZK-EVM 即可解锁 L1 扩容——唯一的限制在于确保区块构建和零知识证明的成本足够低,从而维持“1-of-n”的抗审查性,并形成一个具有竞争力的市场。

然而,现实中这并非唯一的关切点。另一个重大问题是:拥有一个全节点的价值在于,你可以运行一个本地的 RPC 服务器,以一种无需信任、抗审查且保护隐私的方式读取链上数据。本文将讨论对当前 L1 扩容路线图的一些调整,以更好地支持这一目标。

为何不满足于 ZK-EVM + PIR 带来的无需信任与隐私?

我上个月发布的隐私路线图提出:短期内采用 TEE(可信执行环境)+ ORAM(不经意随机存取机)作为补丁方案,长期则依赖 PIR(私有信息检索)。结合 Helios 轻客户端和 ZK-EVM 验证,用户即使连接外部 RPC 服务,也能完全确信:

  1. 所获取的链数据是正确的;

  2. 自身的数据隐私得到保护。

那么值得追问的是:既然如此,为何还要继续支持自托管节点?这些先进的密码学方案是否已让自建节点成为过时的“遗迹”?

对此,我有几点回应:

  1. 完全无需信任的密码学方案(例如单服务器 PIR)成本高昂。目前其开销高到不切实际,即便经过大量效率优化,未来仍可能保持较高成本。

  2. 元数据隐私问题:请求的 IP 地址、时间戳以及访问模式本身,就足以泄露大量用户信息。

  3. 审查脆弱性:若 RPC 服务市场被少数提供商主导,它们将面临强大的去平台化或审查压力。事实上,许多 RPC 提供商已经屏蔽了某些国家的用户。

正因如此,继续降低个人运行节点的门槛仍然具有重要价值

短期优先事项

  1. 优先全面实施 EIP-4444,直至最终状态——每个节点仅存储约 36 天的历史数据。这将大幅降低磁盘空间需求,而磁盘占用正是阻碍更多人运行节点的主要瓶颈。此后,节点的存储需求将仅包括:

  • 状态(state)大小

  • 状态默克尔分支(Merkle branches)

  • 最近 36 天的历史数据

构建分布式历史数据存储方案:每个节点只需存储截止日期之前的一小部分历史数据,并通过纠删码(erasure coding)实现最大鲁棒性。这能在不依赖中心化服务商、也不给节点运营者带来沉重负担的前提下,确保“区块链永存”的特性。

调整 Gas 定价机制:提高存储成本,降低执行成本。尤其应优先提高以下操作的 Gas 消耗:

  • 为新存储槽(storage slot)执行 SSTORE

  • 创建合约代码

  • 向尚无余额或 nonce 的账户转账 ETH

中期重点:无状态验证(Stateless Verification)

一旦实现无状态验证,就可以运行具备 RPC 功能的节点(即能响应查询的节点),而无需存储状态默克尔分支。这将进一步减少约 50% 的存储需求。

一种新型节点:部分无状态节点(Partially Stateless Nodes)

这是本文提出的新构想,也是在 L1 Gas 限制提升 10–100 倍的情况下,仍能支持个人运行节点的关键。

我们引入一种新型节点,它:

  • 以无状态方式验证区块;

  • 通过无状态验证或 ZK-EVM 验证整条链;

  • 仅维护状态的一个子集,并保持该子集实时更新



只要用户的 RPC 请求所需的数据落在该子集内,节点就能正常响应;否则请求将失败(或可选择回退到外部托管的密码学解决方案——是否启用此回退应由用户自主决定)。

用户可通过配置文件自定义所保留的状态范围。例如:

  • 除已知垃圾合约外的所有状态;

  • 所有外部账户(EOA)、智能合约钱包(SCW),以及常用 ERC20/ERC721 代币和应用的状态;

  • 过去两年内被访问过的所有 EOA 和 SCW、部分主流 ERC20 代币,以及一组精选的 Swap、DeFi 和隐私类应用的状态。

该配置可由链上合约管理:用户启动节点时指定 --save_state_by_config 0x12345...67890,该地址将以某种语言描述需保存和同步的状态范围(如地址列表、存储槽或过滤规则)。注意:用户无需保存默克尔分支,只需保存原始值即可

这种节点既能提供对用户关心状态的本地直接访问,又能实现对该状态访问的最大隐私保障

此方案在保持以太坊去中心化精神的同时,为未来高吞吐量 L1 与个人可运行节点之间的平衡提供了可行路径。




Special thanks to Micah Zoltu, Toni Wahrstätter, Justin Traglia and pcaversaccio for discussion

作者:vbuterin

来源:https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368

免责声明:本文为c2e Labs的第三方内容,仅供信息分享与传播之目的,不代表我们的立场或观点且不构成任何投资及应用建议。版权归原作者或来源方所有,如内容或素材有所争议请和我们取得联系。

我来评论