首頁

Partnered With:

ETH Research：利用The Graph保留歷史資料並啟用EIP-4444

閱讀本文需 27 分鐘

The Graph的核心元件索引器在EIP-4444實施後，必須調整區塊鏈資料擷取流程，而Firehose和Substreams技術將解決這個問題。

原文標題：《Using The Graph to Preserve Historical Data and Enable EIP-4444》

原文作者：Seve 2、 Eray 4、Semiotic Labs 2 的Lichu 3和Tatu 3、The Graph 的核心開發人員

原文編譯：Luccy，BlockBeats

< /p>

編按：

EIP-4444 提議把HISTORY_PRUNE_EPOCHS 設為82125 個epoch (即信標鏈上1 年)，使得在PoS 以太坊裡執行層客戶端不再在p2p 網路上提供超過一年的區塊頭、區塊主體和收據的數據，客戶端可以在本地修剪這些歷史數據。

相關閱讀：《引介EIP-4444：對執行層客戶端的歷史資料限制》

The Graph 是一種可在以太在坊和IPFS 等網路上進行查詢的索引協定。任何人都可以建立和發布被稱為子圖（subgraphs）的開放 API，從而使數據更加易於獲取，其中核心組件是索引器。

索引器需要存取區塊鏈的歷史資料來完成任務，而 Firehose 是一個用於從區塊鏈中提取資料的開源工具。目前，區塊鏈資料是透過執行完整的歸檔同步從啟用 Firehose 的完整節點中提取的，但在 EIP-4444 實施後，The Graph 的索引器需要調整其區塊鏈資料提取流程。

在本文中，Semiotic Labs 分享瞭如何利用 The Graph 協議上的技術開發來解決更廣泛社區的問題。最初，Semiotic Labs 為了提高The Graph 協議的性能和可驗證性開發了Firehose 和Substreams，而這一工具和技術恰好能夠應對EIP-4444 問題，並基於此為索引器專門創建了一個採用這種技術的新索引管道。

在這個管道中，Firehose 首先從區塊鏈中提取資料並將其儲存在平面檔案中，並為區塊提供了一個gRPC 介面進行串流傳輸，這個流在The Graph 中可以被多個端點消費。其中，平面文件作為可共享的以太坊檔案，它們包含了所有必要的歷史資料。這些文件是可共享、可驗證的。

此外，本文比較了平面文件格式和era1/era 格式的結構細微差別和用例，並指出，在The Graph 中，新的索引器在運行Firehose 時必須執行一個完整的歸檔節點同步，以提取用於索引的所需歷史區塊鏈數據，同時解釋瞭如何透過共享、可驗證的平面文件與The Graph 的激勵市場解決這些問題。

Semiotic Labs 是 The Graph 協定的核心開發者之一。本文的作者所在的團隊致力於開發和實施驗證 The Graph 提供的來自各個索引區塊鏈上資料的機制。本文所介紹的工作內容是 Semiotic Labs 持續不懈努力的成果。 Severiano Sisneros 將這篇文章發表在以太坊研究論壇中，BlockBeats 將原文編譯如下：

The Graph 簡介

The Graph 是一個去中心化的區塊鏈資料索引和查詢協議。索引器是 The Graph 的核心，為特定事件索引區塊鏈的歷史，並使資料可供消費者查詢，索引器需要存取歷史區塊鏈資料以完成他們的工作。未來，The Graph 的索引器將使用作為 Firehose 資料抽取過程一部分的特殊工具化的區塊鏈完整節點從區塊鏈中提取資料。

Firehose 是由 The Graph 的核心開發者 StreamingFast 所建立的開源工具。 Firehose 為處理區塊鏈資料提供了基於平面檔案（Flat File）和流優先（streaming-first）的方法。 Semiotic Labs 是 The Graph 的另一個核心開發團隊，專注於人工智慧和密碼學領域的研究和開發。

目前，區塊鏈資料是透過執行完整的歸檔同步從啟用Firehose 的完整節點中提取的，這依賴於區塊鏈的P2P 網路中的對等方提供完整的歷史資料。然而，在 EIP-4444 實施後，由於完整節點將不再提供超過一年的歷史數據，The Graph 的索引器需要調整其區塊鏈數據提取流程，以確保繼續獲取所需數據。

本文將介紹The Graph 索引器如何利用Firehose 從區塊鏈中抽取數據，並將其儲存在稱為平面檔案的Google protobuf 序列化對象儲存中。當 Firehose 從創世區塊進行同步時，這些平面檔案會儲存區塊鏈中儲存資料的完整歷史所需的所有資訊（具體來說是區塊體和收據）。我們建議將這些平面檔案作為存檔資料格式，與 era 和 era1 檔案類似，並示範如何驗證儲存在平面檔案中的資料屬於權威區塊鏈。

對於 The Graph，一旦 EIP-4444 實作生效，索引器便可以共用這些平面檔案以取得所需的歷史資料進行索引和查詢。在以太坊的情況下，The Graph 的激勵型索引器網路共同確保了歷史資料的保存和可用性，為 EIP-4444 提供了可驗證、去中心化且獨立的解決方案。

有趣的是，我們最初的目標並不是為 EIP-4444 設計解決方案。這裡討論的工具和技術是為了提高 The Graph 協定的效能和可驗證性而開發的。然而，在這個過程中，我們意外地發現了一個解決 EIP-4444 的方案。我們的願景是讓這個解決方案與其他 EIP-4444 解決方案共存，就像以太坊執行客戶端的多種實作一樣，而不會導致區塊資料的異質分佈。

The Graph Firehose 管道概述

The Graph 是一個不斷發展的動態協議，旨在滿足快速存取區塊鏈數據的需求。為此，開發了一種名為 Firehose 和 Substreams 的新技術，並為索引器專門創建了一個採用這種技術的新索引管道。

在這個管道中，Firehose 是第一步處理過程。它從區塊鏈中提取數據並將其儲存在平面文件中（將在下一節詳細介紹）。接著，Firehose 為儲存在平面檔案中的區塊提供了一個 gRPC 介面進行串流傳輸。在 The Graph 中，這個流可以被多個端點消費。例如，Substreams 服務可以過濾感興趣的特定事件，並對過濾後的資料執行任何指定的轉換。處理後的結果將被路由到一個端點匯集處，並提供給消費者。

圖1 提供了關於Firehose 和Substreams 管道視圖，說明如何從區塊鏈中提取數據、處理數據，並透過各種端點使數據可供消費者使用。

圖1：Firehose + Substreams

在EIP-4444 背景下，我們特別關注如何將區塊鏈資料提取並儲存到平面檔案中。我們觀察到平面文件包含了保留區塊鏈歷史所需的所有數據，同時可以透過簡單的技術手段驗證這些數據是否真實地包含在區塊鏈的規範歷史中。作為一種去中心化的區塊鏈資料索引和查詢協議，The Graph 具有確保整個區塊鏈歷史可用性的天然優勢。

平面檔案作為可共享的以太坊檔案

Firehose 透過運用專用的完整節點2 從區塊鏈中提取數據。以太坊 Firehose 採用的是官方 Geth 1 實現的儀表化版本，需要注意的是，Firehose 支援多個鏈，包括非 EVM 鏈，使用的完整節點會因鏈的不同而有所不同。具體而言，Firehose 在執行完整的歸檔同步時，會從完整節點的追蹤 API 中讀取資料。請參閱圖 2 以取得這些步驟的詳細描述。

圖2：提取Firehose 數據

追蹤API 的輸出內容儲存在平面檔案中。需要注意的是，追蹤 API 可以根據需要配置，以提供不同程度的 EVM 執行內省。例如，可以將其配置為callTracer，用於追蹤交易過程中執行的呼叫幀（包括頂級交易呼叫和交易內部的呼叫），或將追蹤API 配置為結構/操作碼記錄器，在交易執行的每一步中輸出操作碼和執行上下文。為了驗證 Firehose 平面檔案作為以太坊歷史存檔的可行性，我們專注於保留頂級交易呼叫和收據，因為這些是提交到區塊鏈並可以在區塊鏈中驗證的資料。在這種情況下，Firehose 儲存了與區塊鏈中交易執行相關的所有交易資料（區塊體）和收據。

雖然 Firehose 平面檔案並未專門設計用於匯出歷史以太坊存檔數據，但它們包含了所有必要的歷史資料。這些文件是可共享的，並且如我們所見，是可驗證的，這使得它們成為存檔格式的有力候選。

可驗證的平面檔案

平面檔案儲存了所有頂級交易資料（區塊體）以及與交易執行相關的收據。例如，如圖 3 所示，使用 Semiotic 的 flat-files-decoder 解碼的 1500 萬區塊的平面檔案（JSON 格式）。我們可以看到所儲存的區塊頭資訊以及頂級交易的交易追踪，如下面的交易 0x7ecdee...e3222 所示。透過 Firehose 提取的以太坊區塊鏈資料以這種模式儲存在平面檔案中。

圖3：來自平面文件的區塊15,000,000 的解碼區塊鏈資料

平面檔案儲存了用於重建交易和收據Merkle 樹的所有必要資訊。這些 Merkle 樹會被提交到規範區塊鏈的每個區塊中。要驗證這些資料屬於規範區塊鏈，我們只需確保重建的 Merkle 樹的根與儲存在規範區塊頭中的根相符。合併後，我們可以利用共識層提供的資訊。例如，以太坊提供了一個同步委員會子協議，用於驗證來自規範區塊鏈的區塊頭。為了驗證儲存在合併後平面文件中的資料是否正確，我們只需為平面文件中的區塊重建收據和交易 Merkle 樹，然後將這些根與有效的同步委員會簽署的區塊頭進行比較。我們可以從共識輕客戶端取得有效的區塊頭。

有關如何實現此操作的範例，請參閱我們的概念驗證程式碼。根據我們的基準測試，M1 Mac 上一個區塊的資料提取和 Merkle 樹構建大約需要 5 毫秒。

在合併前，我們需要完成更多工作。幸運的是，我們並不孤單。以太坊社群一直在尋求解決此問題的方案。具體來說，入口網站網路利用 Header Accumulator 來驗證區塊頭是否已包含在規範鏈中。值得注意的是，這些累加器對存檔資料的儲存格式是無關的，因此我們可以與此方法保持一致，並從平面檔案中儲存的資料計算相同的 Header Accumulator 值。當索引器共享包含合併前區塊的平面檔案時，它們還需要為包含收據和交易 Merkle 樹根的區塊頭提供證明。

平面檔案、Era 檔案

針對The Graph 的Firehose 平面檔案所提出的存檔數據格式和驗證機制與現有的資料格式方法相容，例如這裡描述的era/era1 資料格式。一個關鍵的差異在於儲存了哪些區塊鏈資料。具體來說，era 檔案格式要求每個 era 檔案都包含一個 Beacon 鏈狀態的快照，以便在從該檔案開始處理鏈時取得狀態資料。然而，Firehose 平面檔案故意不包含任何 Beacon 鏈狀態數據，因為其目的只是集中儲存執行層的歷史交易資料和收據。

由於 Firehose 平面檔案並非為引導實際的以太坊節點而設計，因此保留狀態資料是超出其範圍的。 The Graph 產品主要專注於索引事件資料以進行查詢，而非以太坊節點的有狀態執行。

表 1 比較了平面檔案格式和 era1/era 格式的結構細微差別和用例。

表1：平面檔案與Era1 屬性的對比

激勵平面檔案的可檢索性

如我們所看到的，在The Graph 中，新的索引器在運行Firehose 時必須執行一個完整的歸檔節點同步，以提取用於索引的所需歷史區塊鏈資料。這個過程引入了兩個挑戰，我們將解釋如何透過共享、可驗證的平面文件與 The Graph 的激勵市場解決這些問題。

挑戰 1：執行完整歸檔同步可能耗時較長，取決於檔案系統和索引器硬體。在 Semiotic Labs，同步一個 Firehose 節點（Geth + Firehose）需要大約兩個月的時間。

解決方案1：如果在同步過程中平面檔案受損（就像我們經歷的兩個月後那樣），可以透過從其他索引器下載平面檔案並引導Firehose 使用它們來完成Firehose 同步。利用上述工具，索引器可以驗證從對等方下載的平面檔案屬於規範區塊鏈。索引器將使用從對等方下載並根據規範區塊鏈驗證的平面檔案為 Firehose 提供種子，而不是執行完整歸檔同步。瓶頸變成了下載速度，例如，從創世紀開始下載整個歸檔的約 2TB 需要幾天，而不是完整歸檔同步所需的幾個月。

挑戰 2：一旦 EIP-4444 生效，需要保留歷史資料的機制。

解決方案 2：我們注意到平面檔案既可以共享，也可以驗證，因此索引器可以建立一個共享平面檔案的激勵市場。 The Graph 的消費者指定事件和所需的歷史範圍，事先不知道這個歷史範圍。希望未來證明自己的索引器將確保他們擁有整個區塊鏈歷史的數據。目前，在 The Graph 生態系統內正在努力建立這個市場作為一項數據服務，這是由 The Graph 支持的「平面檔案共享數據服務」。關於 EIP-4444，我們回答了兩個問題：「誰將儲存資料？」和「資料將如何提供？」。 The Graph 的索引器將以平面文件的形式儲存歷史數據，數據將透過 The Graph 協議中的子圖/子流和目前正在開發的平面文件共享數據服務提供。

結論

The Graph 的Firehose 產生的平面檔案格式為實作EIP-4444 後保留以太坊歷史資料提供了一個去中心化且可驗證的解決方案。我們已經證明了這種平面文件包含了所有必要的區塊鏈數據，並且可以與規範鏈進行驗證。

我們正在努力完善我們的開源平面檔案驗證程式碼，以便可用於驗證下載的平面檔案。我們預期 The Graph 協定中的索引器將利用這段程式碼在資料服務市場中分發和獲利平面文件，而不是透過以太坊的 p2p 網路同步完整節點。

The Graph 網路自然地支持並激勵了一種獨特的 EIP-4444 解決方案。特別是，由索引器產生和使用的平面檔案還可以作為一種可共享、可驗證的歸檔格式。我們已經證明了這種平面文件包含了所有必要的區塊鏈數據，並且可以進行驗證，同時提供了概念驗證程式碼。我們提出的方法與現有的努力（如Portal Network 的頭部累加器和era/era1 檔案格式）保持一致，提供了一個專注於執行層資料的互補解決方案，可以與其他EIP-4444 解決方案並存，而不會導致區塊資料的異質分佈。我們正在努力完善我們的開源驗證工具，以便索引器可以輕鬆驗證下載的平面檔案。在不久的將來，The Graph 將推出一個扁平 p2p 檔案共享資料服務，為獲取歷史資料提供替代方法。

這種去中心化、可驗證的平面文件解決方案不需要協議層面的更改，並且可以幫助像The Graph 這樣的協議在EIP-4444之後繼續正常運作。我們提供這種方法作為一種可行的途徑來保留以太坊的歷史，造福整個生態系統。

行動號召

回饋：在本文中，我們將分享如何利用The Graph 協議上的技術開發來解決更廣泛社區的問題。我們非常希望收到您的回饋，所以如果您有任何問題、建議等，請隨時與我們聯繫。

平面檔案的分發與可訪問性：我們對於Firehose 產生的平面檔案（從創世紀開始同步的啟用Firehose 的節點產生）包含了保留整個區塊鏈歷史所需的所有資訊的說法充滿信心。這些平面文件中的資料可以透過上述機制進行驗證。那麼如何管理平面文件的分發並確保歷史資料易於檢索呢？我們給出了兩個激勵分發和可檢索性的論點：一是索引器將維護完整的歷史數據，以便在未來The Graph 協議中為子圖/子流提供最大程度的支持；二是未來的平面文件共享數據服務將確保一個激勵索引器銷售這些數據的市場。

整合全節點的 Firehose 功能：我們目前正在進行的一個專案是將 Firehose 整合到全節點中。如同在 The Graph 中用於實現高效能索引的應用場景所證明的那樣，Firehose 為與區塊鏈資料的互動提供了一種新穎的方法。如本文所示，Firehose 輸出的平面檔案也可以作為歷史區塊鏈資料的可共享和可驗證儲存格式。這進一步證實了將 Firehose 作為全節點功能能夠為全節點操作員解鎖新的效用維度。值得注意的是，Firehose 支援多個鏈，而這個清單還在不斷擴大，為各個鏈提供了一個通用介面。

參考閱讀：

1.EIP-4444: Bound Historical Data in Execution Clients 1;

2.Example flat files;

3.Example era files;

4.< a href="https://firehose.streamingfast.io/architecture/data-storage" rel="noopener noreferrer" target="_blank">StreamingFast Firehose data storage;