使用 Portal 网络协议进行历史记录过期

本文为机器翻译
展示原文

已完成的链历史门户子网络

已完成的链历史是建立在门户网络协议之上的子网络。其目标是提供以太坊已完成历史数据的去中心化存储。

它假设网络上的节点是执行层客户端,本地存储所有历史区块头。不是执行层客户端的节点将需要一种方法来获取给定区块号的区块头(以验证内容)。

在附录部分,我提供了与现有门户历史子网络的比较以及对建议更改的理由。

规范


距离函数

已完成的链历史子网络使用在门户网络协议规范中定义的标准异或距离度量。

内容ID推导函数

内容密钥(稍后描述)使用区块号。内容ID的计算方式如下:

[后续内容保持不变,只翻译了开头部分]

这个想法的可视化如下图所示。

我们通过操作 block_number (uint64) 的位来实现这一点:

  1. 交换16个最低有效位(循环位)和48个最高有效位(偏移位
  2. 通过反转 偏移位 的顺序,以期望的方式偏移不同周期的区块
  3. 最后,追加零以获得域空间的值(uint256

下图展示了区块号 12'345'678 的这个过程。

与距离函数(XOR)的交互

因为我们使用 XOR 作为距离函数,所以半径可能无法覆盖域空间的连续区段(导致存储范围出现"空洞")。但这不是一个大问题,因为:

  • 保证至少半径的一半是连续的
    • 这个连续区段将包括 NodeId
  • 如果半径是2的幂,则整个存储范围是连续的
    • 如果假设客户端使用固定半径,则他们可以强制执行此规则

选择 CYCLE_BITS

CYCLE_BITS 的选择有两个需要平衡的权衡:

  • 较大的值意味着每个节点将存储较少的连续区块长序列,而不是许多较短的序列
  • 较大的值还意味着如果对某个区块范围(例如靠近链头)的需求更高,相同的节点将长时间承担服务这些请求的负担

选择 CYCLE_BITS=16 是因为它简化了大多数语言中的函数实现(字节级而非位级操作),并且如果假设每个节点存储至少 1/256 (≈0.4%) 的所有内容,则他们还将存储至少 256 个连续区块的序列(这感觉是一个很好的平衡)。


来源
免责声明:以上内容仅为作者观点,不代表Followin的任何立场,不构成与Followin相关的任何投资建议。
喜欢
收藏
评论