以太坊的可能未来：The Purge

以太坊面临的挑战之一是,默认情况下,任何区块链协议的膨胀和复杂性都会随着时间的推移而增加。这发生在两个地方:历史数据和协议功能。为了使以太坊能够长期维持下去,我们需要对这两种趋势施加强大的反压力,随着时间的推移降低复杂性和膨胀。但与此同时,我们需要保留使区块链变得伟大的关键属性之一:持久性。

The Purge的主要目标:

• 通过减少或消除每个节点永久存储所有历史记录甚至最终状态的需要来降低客户端存储要求。
• 通过消除不需要的功能来降低协议复杂性。

History expiry

解决什么问题?

截至撰写本文时,完全同步的以太坊节点需要大约 1.1 TB的磁盘空间用于执行客户端,另外还需要数百 GB 的磁盘空间用于共识客户端。其中绝大多数是历史:有关历史区块、交易和收据的数据,其中大部分已有多年历史。这意味着即使 Gas 限制根本没有增加,节点的大小每年也会持续增加数百 GB。

它是什么,它是如何工作的?

历史存储问题的一个关键简化特征是,因为每个块通过哈希链接(和其他结构)指向前一个块,所以对当前达成共识就足以对历史达成共识。只要网络对最新区块达成共识,任何历史区块或交易或状态(账户余额、随机数、代码、存储)都可以由任何单个参与者提供以及 Merkle 证明,并且该证明允许其他任何人验证它的正确性。共识是 N/2-of-N 信任模型,而历史是N-of-N 信任模型。

这为我们如何存储历史记录提供了很多选择。一种自然的选择是每个节点仅存储一小部分数据的网络。这就是种子网络几十年来的运作方式:虽然网络总共存储和分发了数百万个文件,但每个参与者仅存储和分发其中的几个文件。也许与直觉相反,这种方法甚至不一定会降低数据的稳健性。如果通过让节点运行更加经济实惠,我们可以建立一个拥有 100,000 个节点的网络,其中每个节点存储随机 10% 的历史记录,那么每条数据将被复制 10,000 次 - 与 10,000 个节点的复制因子完全相同-节点网络,每个节点都存储所有内容。

如今,以太坊已经开始摆脱所有节点永久存储所有历史的模型。共识区块(即与权益证明共识相关的部分)仅存储约 6 个月。 Blob 仅存储约 18 天。EIP-4444旨在为历史区块和收据引入一年的存储期。长期目标是建立一个统一的时期(可能约为 18 天),在此期间每个节点负责存储所有内容,然后建立一个由以太坊节点组成的点对点网络,将旧数据存储在分布式网络方式。

Erasure codes可用于提高robustness,同时保持复制因子相同。事实上,Blob 已经进行了纠删码,以支持数据可用性采样。最简单的解决方案很可能是重新使用这种Erasure codes,并将执行和共识块数据也放入 blob 中。

还需要做什么,需要权衡什么?

剩下的主要工作包括构建和集成一个具体的分布式解决方案来存储历史记录------至少是执行历史记录,但最终还包括共识和 blob。最简单的解决方案是 (i) 简单地引入现有的 torrent 库,以及 (ii) 称为Portal 网络的以太坊原生解决方案。一旦引入其中任何一个,我们就可以打开 EIP-4444。 EIP-4444 本身不需要硬分叉,但它确实需要新的网络协议版本。因此,同时为所有客户端启用它是有价值的,否则存在客户端因连接到其他节点期望下载完整历史记录但实际上并未获取而发生故障的风险。

主要的权衡涉及我们如何努力提供"古代"历史数据。最简单的解决方案是明天停止存储古代历史,并依赖现有的存档节点和各种集中式提供程序进行复制。这很容易,但这削弱了以太坊作为永久记录场所的地位。更困难但更安全的途径是首先构建并集成 torrent 网络,以分布式方式存储历史记录。在这里,"我们有多努力"有两个维度:

1. 我们如何努力确保最大的节点集确实存储了所有数据?

2. 我们将历史存储集成到协议中的深度有多深?

对于(1)的一种极端偏执的方法将涉及托管证明:实际上要求每个权益证明验证器存储一定比例的历史记录,并定期以加密方式检查它们是否这样做。更温和的方法是为每个客户端存储的历史百分比设置一个自愿标准。

对于 (2),基本实现只涉及今天已经完成的工作:Portal 已经存储了包含整个以太坊历史的 ERA 文件。更彻底的实现将涉及实际将其连接到同步过程,这样,如果有人想要同步完整历史记录存储节点或存档节点,即使没有其他存档节点在线存在,他们也可以通过直接同步来实现来自门户网络。

它如何与路线图的其他部分交互?

如果我们想让节点运行或启动变得极其容易,那么减少历史存储需求可以说比无状态性更重要:在节点需要的 1.1 TB 中,约 300 GB 是状态,剩余的约 800 GB GB 已成为历史。只有实现无状态性和 EIP-4444,才能实现在智能手表上运行以太坊节点并且只需几分钟即可设置的愿景。

限制历史存储还使得较新的以太坊节点实现更可行,仅支持协议的最新版本,这使它们变得更加简单。例如,现在可以安全地删除许多代码行,因为 2016 年 DoS 攻击期间创建的空存储槽已全部删除。既然转向权益证明已经成为历史,客户可以安全地删除所有与工作量证明相关的代码。

State expiry

解决什么问题?

即使我们消除了客户端存储历史记录的需要,客户端的存储需求也将继续增长,每年约 50 GB,因为状态持续增长:账户余额和随机数、合约代码和合约存储。用户可以支付一次性费用,从而永远给现在和未来的以太坊客户带来负担。

状态比历史更难"过期",因为 EVM 从根本上来说是围绕这样一个假设而设计的:一旦创建了状态对象,它就会始终存在,并且可以随时被任何事务读取。如果我们引入无状态性,有人认为这个问题也许并没有那么糟糕:只有专门的区块构建器类需要实际存储状态,而所有其他节点(甚至包含列表生成!)都可以无状态运行。然而,有一种观点认为,我们不想过多依赖无状态性,最终我们可能希望使状态过期以保持以太坊的去中心化。

它是什么,它是如何工作的

今天,当您创建一个新的状态对象时(可以通过以下三种方式之一发生:(i)将 ETH 发送到新帐户,(ii)使用代码创建新帐户,(iii)设置以前未触及的存储槽) ,该状态对象永远处于该状态。相反,我们想要的是对象随着时间的推移自动过期。关键的挑战是以实现三个目标的方式做到这一点:

• 效率:不需要大量的额外计算来运行到期过程。

• 用户友好性:如果有人进入洞穴五年并回来,他们不应该失去对 ETH、ERC20、NFT、CDP 头寸的访问权......

• 开发人员友好性:开发人员不必切换到完全不熟悉的思维模型。此外,目前已经僵化且不更新的应用程序应该可以继续正常运行。

不满足这些目标就很容易解决问题。例如,您可以让每个状态对象还存储一个过期日期计数器(可以通过燃烧 ETH 来延长过期日期,这可能在任何时候读取或写入时自动发生),并有一个循环遍历状态以删除过期日期的过程状态对象。然而,这引入了额外的计算(甚至存储需求),并且它肯定不能满足用户友好性的要求。开发人员也很难推理涉及存储值有时重置为零的边缘情况。如果你在合同范围内设置到期计时器,这在技术上会让开发者的生活变得更容易,但它会让经济变得更加困难:开发者必须考虑如何将持续的存储成本"转嫁"给用户。

这些都是以太坊核心开发社区多年来一直在努力解决的问题,包括"区块链租金"和"再生"等提案。最终,我们结合了提案中最好的部分,并集中在两类"已知最不糟糕的解决方案"上:

• 部分状态过期解决方案
• 基于地址周期的状态到期建议。

Partial state expiry部分状态到期

部分状态到期提案都遵循相同的原则。我们将状态分成块。每个人都永久存储"顶级映射",其中块为空或非空。仅当最近访问过该数据时才会存储每个块中的数据。有一种"复活"机制,如果不再存储

这些提案之间的主要区别是:(i)我们如何定义"最近",以及(ii)我们如何定义"块"?一个具体的提案是EIP-7736,它建立在为 Verkle 树引入的"茎叶"设计之上(尽管与任何形式的无状态状态兼容,例如二叉树)。在这种设计中,彼此相邻的标头、代码和存储槽存储在同一个"主干"下。一个茎下存储的数据最多可以是256 * 31 = 7,936字节。在许多情况下,帐户的整个标头和代码以及许多密钥存储槽都将存储在同一个主干下。如果给定主干下的数据在 6 个月内没有被读取或写入,则不再存储该数据,而是仅存储该数据的 32 字节承诺("存根")。未来访问该数据的交易将需要"复活"数据,并提供根据存根进行检查的证明。

还有其他方法可以实现类似的想法。例如,如果帐户级别的粒度不够,我们可以制定一个方案,其中树的每个 1/232部分都由类似的茎叶机制控制。

由于激励因素,这变得更加棘手:攻击者可以通过将大量数据放入单个子树并每年发送单个交易来"更新树",从而迫使客户端永久存储大量状态。如果您使续订成本与树大小成正比(或续订持续时间成反比),那么有人可能会通过将大量数据放入与他们相同的子树中来伤害其他用户。人们可以尝试通过根据子树大小使粒度动态化来限制这两个问题:例如,每个连续的 216= 65536 个状态对象可以被视为一个"组"。然而,这些想法更为复杂;基于茎的方法很简单,并且可以调整激励措施,因为通常茎