EIP-444 主要用于削减客户端大于1年以上的历史数据。客户端必须在p2p层停止为大于1年以上的历史区块头，区块体，和收据数据提供服务。客户端可以在本地削减历史数据。
动机
历史的数据区块和收据占据超过400GB的磁盘空间，并且在持续增长，因此为了验证链，用户必须要有至少1T的磁盘空间。
历史对于验证新的区块是非必须的，一旦客户端同步到链的最前端，历史数据只会通过JSON-RPC以显式方式获取。通过削减历史，本提案能减少用户的磁盘要求。削减历史数据同时允许用户移掉处理历史区块的代码，意味着客户不必要维护处理升级的代码路径。
同时，它也能减少网络带宽的使用，客户端会采用更加轻量级的同步策略。
规范
HISTORY_PRUNE_EPOCHES: 82125， beacon 链一年中的epochs。
客户端不应该对p2p网络上超过HISTORY_PRUNE_EPOCHES的区块头，区块体，和收据数据提供服务；
客户端可以在本地削减超过HISTORY_PRUNE_EPOCHES的区块头，区块体和收据。
本EIP 会影响到客户端的启动和同步，客户端将无法完全同步，因为历史的数据不再提供服务。
客户端必须有一个有效的WSC (Weak Subjectivity Checkpoint) 启动，即链的最新视角。为了同步，客户将WSC 作为创世块（genesis block）， 这种方法称为检查点同步 (checkpoint sync)。
为了实现本提案，我们假设客户端启动配置了的WSC。
本提案使客户端不再为历史的数据提供服务，迫使客户端从其它的来源获取历史数据。
将参数HISTORY_PRUNE_EPOCHES (82125)设为一年，这个常量足够大，可以为WSC 增长 提供充足的空间， 也时也使占据的磁盘空间足够小。
向后兼容性
保留历史数据
本提案会影响到需要用到历史数据的节点，可以通过（out-of-band）的方式获取以太坊历史数据。
历史数据可以通过IPFS 打包和分享，并且， Portal Network 或Graph 可以用来查询历史数据。
客户端允许导入和导出历史数据，客户端提供获取/验证数据的脚本，可以自动导入数据。
从genesis 完全同步
P2p网络无法进行全同步，但是可以允许感兴趣的人自己同步。
可以定制一种专门的全同步电路，客户端可以导入历史的区块，并从创世块开始验证，生成所有的历史数据 。
用户体验
本提案会影响到使用户历史数据的应用体验，因为可以建设客户端引入两个阶段的改变：
在第一阶段，客户端默认不会削减历史的数据，可以引入一个命令行可选参数--txlookuplimit , 用户可以用来削减历史数据。
在第二阶段，历史数据会默认削减，命令行可选参数移除，客户端通过out-of-band的方式导入数据。
JSON-RPC改变
在本提案实现后，一些JSON-RPC接口 (如getBlockByHash) 将无法给出一个hash 是无效的还是太老， getLogs 也无法提供请求的数据。
安全考虑
依赖weak subjectivity
在转向PoS的时候，用户有效的WSC(weak subjectivity checkpoint) 是非常必要的。
本提案依赖weak subjectivity 假设，假定客户端不会启动无效或过老的WS 检查点。
本提案假设weak subjectivity period 短于 HISTORY_PRUNE_EPOCHES， 否则将无法通过p2p获取需要的数据。
中心化/审查风险
若没有激励保存历史数据，会存在 审查/可获取性 风险。由不同的组织保留以太坊历史数据是非常必要的。
并且，由于更多dapps 依赖中心化服务获取历史数据， 也会存在风险。
