来源：@lightclients

译者注：EIP-4444 提议把 HISTORY_PRUNE_EPOCHS 设为 82125 个 epoch (即信标链上 1 年)，使得在 PoS 以太坊里执行层客户端不再在 p2p 网络上提供超过一年的区块头、区块主体和收据的数据，客户端可以在本地修剪这些历史数据。此 EIP 的作者之一@lightclients 在推特写了简介，本文为该推文的翻译。

以太坊客户端目前存储着 275 GB 的历史数据，这些数据对于验证区块链是不必要的。这个数字正在以每年 140 GB 的速度增长。EIP-4444 提议客户端修剪超过 1 年的数据。那么，为什么我们不直接修剪数据呢？

要理解为什么数据还没被修剪，以及为什么这需要讨论，就需要理解历史数据今天是如何被使用的。有两个主要的使用类别：同步和用户通过 JSON-RPC 请求。

在同步里有两种主要方法：

• 完全同步 (Full Sync)：下载并执行从创世直到区块链顶端的每个区块

• 状态同步 (State Sync)：这里有很多方案，但主要是用工作量证明检查进行区块头同步，并下载最新区块的状态。

在这两种情况下，客户端通过 p2p 网络请求历史数据，以延长它们对链的视域 (view)。信任模型通常是信任创世状态然后验证其他所有东西——要么完全验证，要么通过工作量证明检查进行轻度验证。

权益证明改变了这点。因为它容易遭受远程攻击，我们必须依赖“弱主观性检查点 (Weak Subjectivity Checkpoint)”。这实质上是我们对权威链上一个区块的信任程度等同于对 PoW 里创世区块的信任。

弱主观性检查点使得客户端可以跳过通过 p2p 网络请求历史数据的引导步骤。当然，在检查点后它们将仍然需要同步历史数据——因此检查点应该总是在修剪边界之前。

这听上去像是安全性上的倒退。以前，我们有一个 2015 年 7 月 13 日的哈希值做验证。现在，我们有的是变动着的弱主观性检查点。但事实上，我们一直都依赖弱主观性。

你最后一次验证客户端版本间的代码差异是什么时候？大多数人没有技术背景来做这件事。因此，每次你更新你的客户端，你都依赖你的客户端团队严格地实现以太坊协议。

幸运的是，有很多人盯着像 go-ethereum 这样的软件。只需要一个吹哨者就能揭发代码里的恶意提交。同样，只需要有一个吹哨者指出一个客户端推出一个恶意的弱主观性检查点。

事实上，验证一个客户端推出正确的弱主观性检查点比确保代码正确执行协议要容易得多。

因此，从安全性的角度来看，其实是没有倒退的。这也包括同步——历史数据所需的另一个主要用途类别是为用户请求提供服务。

用户可以请求两种类型的数据：

• 当前数据，例如存储槽的数值、账户余额、最新的区块高度等

• 历史数据，例如在区块 N 的存储槽数据、区块 N 的区块头、交易收据等

当前的数据将继续可以被访问，当实现 EIP-4444 后，历史数据能否被访问取决于它是多长时间以前的。

历史数据的主要使用者是 dapp 开发者。很多 dapp 添加历史数据到它们的数据库，通过它们的前端提供给用户。对于他们来说，能够遍历所有交易和日志是很重要的。

支持这个用例有多个方法——现在最受欢迎的方法是客户端发布多路复用器，支持一定范围区块的版本会执行该范围的区块。例如，geth 版本 A 可能支持直到区块高度为 10m 的区块，而 geth 版本 B 则支持 10m 之后的区块。

多路复用器将用版本 A 执行区块高度为 0 到 10m 的区块，输出状态数据库并将其导入 geth 版本 B，然后继续执行10m 之后的区块。JSON-RPC 请求会被导向有合适信息响应的客户端。

但是，如果历史区块在 p2p 网络上不再可得——那谁来提供这些数据？预计会有很多大型、受信任的机构提供这些数据的镜像。由于数据是静态的，所以很容易就其哈希值达成共识并进行验证。这是 1-of-N 的信任模型。

新标准将是不存储历史数据并运行一个客户端多路复用器。这意味着以太坊客户端的标准内存占用会减少 275 GB——但还有最后一个问题需要提及。

当前，当请求的数据不存在时，以太坊的 JSON-RPC 会给一个空响应。假设客户端没有在同步，这会以“这个数据不存在于权威链或最近的分叉”被接受。

一旦客户端开始修剪旧数据，这种不变性就会被打破。当一个用户请求一个特定交易收据时，客户端将不知道该收据是被修剪了还是从来没有存在过。目前，我们期望 RPC 将对这两种情况返回一个空响应。

我很想得到关于这种方法的反馈。JSON-RPC 的使用者对此有什么看法？你们访问超过 1 年的历史数据的频率如何？另一种方法 (尽管更重) 是保持一个被修剪数据哈希值的索引，这样可以向用户返回更多的内容。

275 GB 这个数据是在 geth db inspect 的输出里查到的。下面是截图：

正式的 EIP-4444 (顺便提一下，读作 EIP four 4s) 规范可以在这里找到：

https://eips.ethereum.org/EIPS/eip-4444

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系eth@ecn.co进行授权。

来源：@lightclients

译者注：EIP-4444 提议把 HISTORY_PRUNE_EPOCHS 设为 82125 个 epoch (即信标链上 1 年)，使得在 PoS 以太坊里执行层客户端不再在 p2p 网络上提供超过一年的区块头、区块主体和收据的数据，客户端可以在本地修剪这些历史数据。此 EIP 的作者之一@lightclients 在推特写了简介，本文为该推文的翻译。

以太坊客户端目前存储着 275 GB 的历史数据，这些数据对于验证区块链是不必要的。这个数字正在以每年 140 GB 的速度增长。EIP-4444 提议客户端修剪超过 1 年的数据。那么，为什么我们不直接修剪数据呢？

要理解为什么数据还没被修剪，以及为什么这需要讨论，就需要理解历史数据今天是如何被使用的。有两个主要的使用类别：同步和用户通过 JSON-RPC 请求。

在同步里有两种主要方法：

• 完全同步 (Full Sync)：下载并执行从创世直到区块链顶端的每个区块

• 状态同步 (State Sync)：这里有很多方案，但主要是用工作量证明检查进行区块头同步，并下载最新区块的状态。

在这两种情况下，客户端通过 p2p 网络请求历史数据，以延长它们对链的视域 (view)。信任模型通常是信任创世状态然后验证其他所有东西——要么完全验证，要么通过工作量证明检查进行轻度验证。

权益证明改变了这点。因为它容易遭受远程攻击，我们必须依赖“弱主观性检查点 (Weak Subjectivity Checkpoint)”。这实质上是我们对权威链上一个区块的信任程度等同于对 PoW 里创世区块的信任。

弱主观性检查点使得客户端可以跳过通过 p2p 网络请求历史数据的引导步骤。当然，在检查点后它们将仍然需要同步历史数据——因此检查点应该总是在修剪边界之前。

这听上去像是安全性上的倒退。以前，我们有一个 2015 年 7 月 13 日的哈希值做验证。现在，我们有的是变动着的弱主观性检查点。但事实上，我们一直都依赖弱主观性。

你最后一次验证客户端版本间的代码差异是什么时候？大多数人没有技术背景来做这件事。因此，每次你更新你的客户端，你都依赖你的客户端团队严格地实现以太坊协议。

幸运的是，有很多人盯着像 go-ethereum 这样的软件。只需要一个吹哨者就能揭发代码里的恶意提交。同样，只需要有一个吹哨者指出一个客户端推出一个恶意的弱主观性检查点。

事实上，验证一个客户端推出正确的弱主观性检查点比确保代码正确执行协议要容易得多。

因此，从安全性的角度来看，其实是没有倒退的。这也包括同步——历史数据所需的另一个主要用途类别是为用户请求提供服务。

用户可以请求两种类型的数据：

• 当前数据，例如存储槽的数值、账户余额、最新的区块高度等

• 历史数据，例如在区块 N 的存储槽数据、区块 N 的区块头、交易收据等

当前的数据将继续可以被访问，当实现 EIP-4444 后，历史数据能否被访问取决于它是多长时间以前的。

历史数据的主要使用者是 dapp 开发者。很多 dapp 添加历史数据到它们的数据库，通过它们的前端提供给用户。对于他们来说，能够遍历所有交易和日志是很重要的。

支持这个用例有多个方法——现在最受欢迎的方法是客户端发布多路复用器，支持一定范围区块的版本会执行该范围的区块。例如，geth 版本 A 可能支持直到区块高度为 10m 的区块，而 geth 版本 B 则支持 10m 之后的区块。

多路复用器将用版本 A 执行区块高度为 0 到 10m 的区块，输出状态数据库并将其导入 geth 版本 B，然后继续执行10m 之后的区块。JSON-RPC 请求会被导向有合适信息响应的客户端。

但是，如果历史区块在 p2p 网络上不再可得——那谁来提供这些数据？预计会有很多大型、受信任的机构提供这些数据的镜像。由于数据是静态的，所以很容易就其哈希值达成共识并进行验证。这是 1-of-N 的信任模型。

新标准将是不存储历史数据并运行一个客户端多路复用器。这意味着以太坊客户端的标准内存占用会减少 275 GB——但还有最后一个问题需要提及。

当前，当请求的数据不存在时，以太坊的 JSON-RPC 会给一个空响应。假设客户端没有在同步，这会以“这个数据不存在于权威链或最近的分叉”被接受。

一旦客户端开始修剪旧数据，这种不变性就会被打破。当一个用户请求一个特定交易收据时，客户端将不知道该收据是被修剪了还是从来没有存在过。目前，我们期望 RPC 将对这两种情况返回一个空响应。

我很想得到关于这种方法的反馈。JSON-RPC 的使用者对此有什么看法？你们访问超过 1 年的历史数据的频率如何？另一种方法 (尽管更重) 是保持一个被修剪数据哈希值的索引，这样可以向用户返回更多的内容。

275 GB 这个数据是在 geth db inspect 的输出里查到的。下面是截图：

正式的 EIP-4444 (顺便提一下，读作 EIP four 4s) 规范可以在这里找到：

https://eips.ethereum.org/EIPS/eip-4444

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系eth@ecn.co进行授权。