问题
背景定义
区块历史（Block History）：指自创世区块以来创建的所有区块。
状态历史（State History）：指从创世区块开始，每个区块应用于前一个状态之后的所有状态的集合。
例如：在创世区块时，状态为
S0，在区块 1 应用后，状态变为
S1。状态历史指的是所有
Sn∀n 的集合。
全节点（Full nodes）：存储最新的状态和区块历史。
归档节点（Archives nodes）：存储状态历史和区块历史。
关于定义的澄清
如果我们在区块 500，我要求一个全节点给我区块 100 的余额。它无法做到，因为它不知道我在区块 100 的状态是什么，只知道我在区块 500 的状态。这是因为它没有状态历史。
如果我要求同一个全节点提供区块 100，它能够给我，因为它有区块历史。
归档节点能够给我任何我想要的过去区块的状态（余额等），以及过去的区块，因为它们既有状态历史，也有区块历史。
问题定义
区块历史占用大量空间，并且一旦该区块被 finality 确认，它仅用于非共识关键的有限用例。我们将详细说明这些用例是什么。
TLDR 解决方案 (44444)
区块历史将不再由全节点永久存储。经过一段时间后，它将从节点中移除，需要它的实体将需要从其他地方查询。
附注：它不会立即移除，因为我们希望根据弱主观性时间段保留历史。这个时间段大约是三个月。
历史的用户
归档节点
归档节点需要区块历史来计算状态历史。然后，状态历史可以用于执行诸如“我在区块 1 的余额是多少”之类的查询。
Erigon3 将通过 torrent 分发状态历史，而不是计算它。
现状是归档节点向网络请求区块，因为全节点和归档节点都在存储区块历史。
我们得出的解决方案可能也可以用于解决状态历史问题，但是我们只解决区块历史问题，因此我们不会在本文中对此进行进一步阐述。
另一点需要注意的是，最终用户可以仅仅依赖一组利他的归档节点，但是运行归档节点的要求会变得很高（目前 Erigon 和 Reth 需要 2TB），这将类似于拥有中心化的历史提供商。
应用程序和终端用户
应用程序和终端用户需要区块历史来回答诸如“与给定交易哈希对应的交易是什么”之类的查询。
现状是应用程序向全节点或归档节点请求，因为它们有区块历史，或者它们向像 infura 这样的中心化提供商请求。
注意：这些类型的查询依赖于区块历史，而不是状态历史。查询状态历史不在本文的范围之内。在这方面，现状没有改变。
TLDR：归档节点需要区块历史。应用程序和终端用户需要能够有效地查询部分区块历史。
要求
- 我们希望从全节点中删除区块历史。根据定义，归档节点仍然会有它。
- 我们希望确保一旦全节点删除区块历史，它仍然可用，而不需要中心化实体。
- 可选地：我们理想情况下希望有一种策略，让归档节点能够快速下载区块历史，因为它们将下载数百 GB 的数据。
解决方案
解决方案是使用简化版的 Portal Network (Portal History Network)。
Portal Network 可以被看作是具有可验证点查询的去中心化 CDN。
BitTorrent 不起作用，因为当客户端请求具有相应区块哈希的区块时，他们可能会收到一个与该区块哈希不对应的 BitTorrent 链接。
然而，44444 可以用更简单的 Portal 版本来完成。
Portal Network 的主要缺点是它被设计为允许对区块历史进行细粒度查询，例如“给我与此交易哈希对应的交易”，但是它不擅长范围查询，即“给我区块 2000 到 3000 之间的所有区块”。
我们将使用 torrent 文件和一个用于归档节点的特殊 P2P 网络层（Ahmad EIP）来解决这个问题。这些对于 44444 来说不是关键的。
关键行动项
关键指的是这些行动项对 44444 来说是阻塞性的。
- 弄清楚我们需要 Portal 规范中的什么
- 历史区块同步到 Portal History Network 的频率如何？
- 例如：如果我是区块 2000 万，并且说过去六个月是区块 1500 万。这意味着在初始启动时，我保留 1500 万到 2000 万之间的区块。0 到 1500 万被认为在 Portal 上。
- 一天过去了，我是否过期一天的区块并将它们推送到 Portal，还是等待更长时间？
- 我们应该先写入 Portal Network，然后等待几天让它被播种到 Portal Network，然后从以太坊中过期它吗？我们应该等待多久？
- 编写并最终确定这些简化的 Portal 规范
- 弄清楚对（简化版）Portal Network 的最坏情况攻击是什么样的，以及它对以太坊意味着什么。
- 客户端将为这些简化的 Portal 规范编写自己的实现，并集成到他们的客户端中。客户端可以参考名为 fluffy 的参考实现。
- Nethermind (ahmad@nethermind.io)
- Nimbus (github: @kdeme)
- github issue: #2147 (status-im/nimbus-eth1)
- Geth (Felix*)
- Reth (Georgios)
- Erigon (Andrew)
- Besu (Justin Florentine*)
- 全节点需要设置一个最低要求，即作为他们对 Portal Network 贡献的一部分，将存储多少区块历史。
- 在每个步骤都与安全团队保持更新 (Fredrik)
非关键行动项
- 弄清楚归档节点 torrent 大范围区块的策略。(jacek@status.im)
- 这引发了关于数据格式的对话，这些对话目前尚未解决。
- 弄清楚归档节点仍然可以通过 P2P 网络请求历史区块的策略。
- 大致的想法是，归档节点现在将通过一个用于历史区块的特殊 wire 协议进行同步。(ahmad@nethermind.io)
- (Georgios) - 如果 44444 节点没有历史数据，归档节点不应惩罚它
