已完成的鏈歷史門戶子網路

已完成的鏈歷史是建立在門戶網路協議之上的子網路。其目標是提供以太坊已完成歷史資料的去中心化儲存。

它假設網路上的節點是執行層客戶端，本地儲存所有歷史區塊頭。不是執行層客戶端的節點將需要一種方法來獲取給定區塊號的區塊頭（以驗證內容）。

在附錄部分，我提供了與現有門戶歷史子網路的比較以及對建議更改的理由。

規範

距離函式

已完成的鏈歷史子網路使用在門戶網路協議規範中定義的標準異或距離度量。

內容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 個連續區塊的序列（這感覺是一個很好的平衡）。