--- title: "无状态、状态过期与历史数据过期" description: "历史数据过期与无状态以太坊的解释" lang: zh template: roadmap --- 在普通硬件上运行[以太坊](/)节点的能力对于真正的去中心化至关重要。这是因为运行节点使用户能够通过独立执行密码学检查来验证信息，而不是信任第三方为他们提供数据。运行节点允许用户直接向以太坊点对点网络提交交易，而无需信任中介。如果这些好处只提供给拥有昂贵硬件的用户，去中心化是不可能的。相反，节点应该能够在极低的处理和内存要求下运行，以便它们可以在手机、微型计算机上运行，或者在家庭计算机上无感运行。 如今，高磁盘空间要求是阻碍节点普及的主要障碍。这主要是由于需要存储大量以太坊的状态数据。这些状态数据包含正确处理新区块和交易所需的关键信息。在撰写本文时，建议使用快速的 2TB 固态硬盘来运行完整的以太坊节点。对于不修剪任何旧数据的节点，存储需求以每周约 14GB 的速度增长，而存储自创世区块以来所有数据的归档节点正接近 12 TB（在撰写本文时，即 2023 年 2 月）。 可以使用更便宜的硬盘来存储旧数据，但它们的速度太慢，无法跟上新区块的产生。保持客户端当前的存储模型，同时使数据更便宜、更容易存储，只是解决该问题的临时和部分方案，因为以太坊的状态增长是“无界的”，这意味着存储需求只会不断增加，而技术改进将始终必须跟上状态的持续增长。相反，客户端必须找到验证区块和交易的新方法，这些方法不依赖于从本地数据库中查找数据。 ## 减少节点的存储需求 {#reducing-storage-for-nodes} 有几种方法可以减少每个节点必须存储的数据量，每种方法都要求在不同程度上更新以太坊的核心协议： - **历史数据过期**：使节点能够丢弃早于 X 个区块的状态数据，但不改变以太坊客户端处理状态数据的方式。 - **状态过期**：允许不经常使用的状态数据变为非活跃状态。非活跃数据可以被客户端忽略，直到它被恢复。 - **弱无状态**：只有区块生产者需要访问完整的状态数据，其他节点可以在没有本地状态数据库的情况下验证区块。 - **强无状态**：没有任何节点需要访问完整的状态数据。 ## 数据过期 {#data-expiry} ### 历史数据过期 {#history-expiry} 历史数据过期是指客户端修剪掉它们不太可能需要的旧数据，以便它们只存储少量的历史数据，并在新数据到达时丢弃旧数据。客户端需要历史数据有两个原因：同步和提供数据请求服务。最初，客户端必须从创世区块开始同步，验证每个连续的区块是否正确，一直到链的头部。如今，客户端使用“弱主观性检查点”来引导它们到达链的头部。这些检查点是受信任的起点，就像拥有一个接近现在的创世区块，而不是以太坊的最开始。这意味着客户端可以丢弃最近的弱主观性检查点之前的所有信息，而不会失去同步到链头部的能力。客户端目前通过从其本地数据库中获取历史数据来服务（通过 JSON-RPC 到达的）历史数据请求。然而，随着历史数据过期，如果请求的数据已被修剪，这将是不可能的。提供这些历史数据正是需要一些创新解决方案的地方。 一种选择是客户端使用诸如波特尔网络之类的解决方案从对等节点请求历史数据。波特尔网络是一个正在开发中的点对点网络，用于提供历史数据，其中每个节点存储以太坊历史的一小部分，从而使整个历史分布式地存在于网络中。通过寻找存储相关数据的对等节点并向它们请求数据来服务请求。或者，由于通常是应用程序需要访问历史数据，因此存储历史数据可以成为它们的责任。在以太坊领域中也可能有足够多的利他主义者愿意维护历史档案。它可以是一个为了管理历史数据存储而成立的去中心化自治组织 (DAO)，或者理想情况下，它将是所有这些选项的组合。这些提供商可以通过多种方式提供数据，例如通过 torrent、FTP、Filecoin 或 IPFS。 历史数据过期在某种程度上是有争议的，因为到目前为止，以太坊一直隐式地保证任何历史数据的可用性。从创世区块进行完全同步一直作为标准是可能的，即使它依赖于从快照重建一些旧数据。历史数据过期将提供这种保证的责任移到了以太坊核心协议之外。如果最终由中心化组织介入提供历史数据，这可能会引入新的审查风险。 EIP-4444 尚未准备好发布，但正在积极讨论中。有趣的是，EIP-4444 面临的挑战与其说是技术上的，不如说是社区管理上的。为了发布它，需要社区的认可，这不仅包括达成一致，还包括受信任实体对存储和提供历史数据的承诺。 此次升级并没有从根本上改变以太坊节点处理状态数据的方式，它只是改变了访问历史数据的方式。 ### 状态过期 {#state-expiry} 状态过期是指如果状态最近没有被访问过，则将其从各个节点中移除。有几种方法可以实现这一点，包括： - **按租金过期**：向账户收取“租金”，并在其租金降至零时使其过期 - **按时间过期**：如果在一段时间内没有对该账户进行读/写操作，则使账户变为非活跃状态 按租金过期可能是直接向账户收取租金，以使其保留在活跃状态数据库中。按时间过期可以是从最后一次账户交互开始倒计时，也可以是所有账户的定期过期。也可以有结合基于时间和基于租金模型元素的机制，例如，如果个人账户在基于时间的过期之前支付少量费用，则它们将保留在活跃状态。对于状态过期，需要注意的是，非活跃状态**并未被删除**，它只是与活跃状态分开存储。非活跃状态可以恢复为活跃状态。 这种工作方式可能是为特定时间段（可能约 1 年）建立一个状态树。每当一个新时期开始时，就会产生一个全新的状态树。只有当前的状态树可以被修改，所有其他的都是不可变的。以太坊节点只需保留当前状态树和最近的一个状态树。这需要一种方法来为地址打上其存在时期的带有时间戳的标记。有[几种可能的方法](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607)可以做到这一点，但主要的选择要求[延长地址](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485)以容纳额外的信息，其额外的好处是更长的地址要安全得多。执行此操作的路线图项目称为[地址空间扩展](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485)。 与历史数据过期类似，在状态过期下，存储旧状态数据的责任从个人用户身上移除，并推给其他实体，例如中心化提供商、利他主义的社区成员或更具未来感的去中心化的解决方案（如波特尔网络）。 状态过期仍处于研究阶段，尚未准备好发布。状态过期很可能在无状态客户端和历史数据过期之后发生，因为这些升级使大多数验证者能够轻松管理庞大的状态规模。 ## 无状态 {#statelessness-2} 无状态这个词有点用词不当，因为它并不意味着“状态”的概念被消除，但它确实涉及以太坊节点处理状态数据方式的改变。无状态本身有两种形式：弱无状态和强无状态。弱无状态通过将状态存储的责任交给少数节点，使大多数节点能够实现无状态。强无状态完全消除了任何节点存储完整状态数据的需要。弱无状态和强无状态都为普通验证者提供以下好处： - 几乎即时的同步 - 能够乱序验证区块 - 节点能够在极低的硬件要求下运行（例如，在手机上） - 节点可以在便宜的硬盘上运行，因为不需要磁盘读/写 - 兼容以太坊密码学的未来升级 ### 弱无状态 {#weak-statelessness} 弱无状态确实涉及以太坊节点验证状态变化方式的改变，但它并没有完全消除网络上所有节点对状态存储的需求。相反，弱无状态将状态存储的责任交给了区块提议者，而网络上的所有其他节点在不存储完整状态数据的情况下验证区块。 **在弱无状态中，提议区块需要访问完整的状态数据，但验证区块不需要状态数据** 为此，必须已经在以太坊客户端中实现了[沃克尔树](/roadmap/verkle-trees/)。沃克尔树是用于存储以太坊状态数据的替代数据结构，它允许在对等节点之间传递数据的固定大小的小型“见证数据”，并用于验证区块，而不是针对本地数据库验证区块。还需要[提议者-构建者分离 (PBS)](/roadmap/pbs/)，因为这允许区块构建者成为拥有更强大硬件的专用节点，而这些节点正是需要访问完整状态数据的节点。 无状态依赖于区块构建者维护完整状态数据的副本，以便他们可以生成可用于验证区块的见证数据。其他节点不需要访问状态数据，验证区块所需的所有信息都可以在见证数据中获得。这造成了一种情况：提议区块的成本很高，但验证区块的成本很低，这意味着更少的运营者将运行区块提议节点。然而，只要尽可能多的参与者能够独立验证他们提议的区块是否有效，区块提议者的去中心化就不是至关重要的。 阅读 Dankrad 笔记的更多内容 区块提议者使用状态数据来创建“见证数据”——证明区块中交易正在更改的状态值的最小数据集。其他验证者不持有状态，他们只存储状态根（整个状态的哈希）。他们接收一个区块和见证数据，并使用它们来更新其状态根。这使得验证节点极其轻量级。 弱无状态处于高级研究阶段，但它依赖于提议者-构建者分离和沃克尔树的实现，以便可以在对等节点之间传递小型见证数据。这意味着弱无状态可能距离以太坊主网还有几年的时间。 [用于一层网络 (l1) 验证的 zkEVM](/roadmap/zkevm/) 是一项补充技术，可以进一步增强无状态验证。验证者不仅可以检查见证数据，还可以验证整个区块被正确执行的零知识证明——在不重新执行交易的情况下提供密码学确定性。 ### 强无状态 {#strong-statelessness} 强无状态消除了任何节点存储状态数据的需要。相反，发送的交易带有可由区块生产者聚合的见证数据。然后，区块生产者仅负责存储为相关账户生成见证数据所需的状态。状态的责任几乎完全转移给了用户，因为他们发送见证数据和“访问列表”来声明他们正在与哪些账户和存储键进行交互。这将实现极其轻量级的节点，但也存在权衡，包括使与智能合约的交易变得更加困难。 研究人员已经对强无状态进行了调查，但目前预计它不会成为以太坊路线图的一部分——弱无状态更有可能足以满足以太坊的扩容需求。 ## 当前进展 {#current-progress} 弱无状态、历史数据过期和状态过期都处于研究阶段，预计将在几年后发布。无法保证所有这些提案都会被实施，例如，如果首先实施状态过期，则可能不需要再实施历史数据过期。还有其他路线图项目，例如[沃克尔树](/roadmap/verkle-trees)和[提议者-构建者分离 (PBS)](/roadmap/pbs)，需要首先完成。 ## 延伸阅读 {#further-reading} - [什么是无状态以太坊？](https://stateless.fyi/) - [Vitalik 关于无状态的 AMA](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) - [状态规模管理理论](https://hackmd.io/@vbuterin/state_size_management) - [最小化恢复冲突的状态边界](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) - [通往无状态和状态过期的路径](https://hackmd.io/@vbuterin/state_expiry_paths) - [EIP-4444 规范](https://eips.ethereum.org/EIPS/eip-4444) - [Alex Stokes 谈 EIP-4444](https://youtu.be/SfDC_qUZaos) - [为什么实现无状态如此重要](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) - [最初的无状态客户端概念笔记](https://ethresear.ch/t/the-stateless-client-concept/172) - [更多关于状态过期的信息](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) - [关于状态过期的更多信息](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) - [无状态以太坊信息页面](https://stateless.fyi)