現在是2021 年，以太坊區塊鏈已經運行5 年多了。但目前還沒有不使用中心化提供者就能與以太坊協議交互的可靠的輕量級方式。各種研究表明，只要你能夠訪問必要的數據，就可以構建這一功能。在本文中，我們將介紹什麼是區塊鏈歷史記錄，以及需要解決哪些問題才能讓輕量級客戶端輕鬆獲得這些歷史記錄。

區塊鏈歷史記錄

“區塊鏈歷史記錄” 指的是所有區塊頭、區塊體和收據的歷史記錄。在當前所有以太坊客戶端用來通信的以太坊協議中，節點可以使用以下消息對來互相請求區塊鏈歷史記錄：

GetBlockHeaders > BlockHeadersGetBlockBodies > BlockBodiesGetReceipts > Receipts

點擊此處，查看以太坊協議的完整規範。

區塊鏈歷史記錄是一個相對簡單的數據集。你可以把它當成是一個只能添加的文件。礦工每挖出一個新的區塊，這個區塊的區塊頭、交易、叔塊和收據都會被添加到文件中。

以太坊協議已經為這部分需要而優化過，所以一個新加入網絡的節點可以高效地檢索區塊鏈的所有歷史記錄。一旦客戶端實現完全同步，除了響應JSON-RPC 請求之外無需使用這些數據。客戶端自己也不會頻繁用到這些數據，因為它們會通過gossip 消息獲取新的區塊和區塊頭。作為區塊執行的一部分，收據會在本地生成。儘管如此，協議還是強迫客戶端要保留完整的歷史記錄。

因此，我們需要的數據在以太坊節點所組成的網絡中其實都有，只不過網絡的架構沒有考慮過我們的用例。在以太坊協議上構建輕量級客戶端需要解決三大問題：

A：我們需要對正統鏈有一個簡明的了解B：我們需要使用索引，便於按區塊號查找區塊，並按哈希值查找交易C：我們需要減少單個節點存儲的總數據量

A：正統區塊頭鏈

要找到區塊鏈最新區塊，最免信任的方式是從頭開始構建一條完整的區塊頭鏈（由區塊頭組成的鏈條）。為此，我們需要獲取大約1100 萬個區塊頭，並為其提供大約6GB 的存儲空間。

如果沒有完整的區塊頭鏈，客戶端就無法辨別區塊頭是屬於正統鏈還是叔塊的。對於手機和樹莓派等低資源設備來說，6GB 的存儲成本過於高昂。如果用戶要先獲得1100 萬個區塊頭才能發出第一個請求的話，那就違反了客戶端無需同步的要求。

幸好我們可以藉鑑信標鏈的機制來解決這一問題。我們只需在以太坊協議上添加一個“雙倍批量默克爾log 累加器（double-batched merkle log accumulator）”，就可以構建一個簡單易懂的機制來提供某個區塊頭是否包含在正統鏈上的證明。客戶端只需準確掌握最新區塊頭的信息，並通過累加器生成的簡單默克爾證明來證明歷史區塊頭包含在正統鏈上。

同步問題是一個可以在客戶端層面解決的用戶體驗問題。有兩種解決方案：1. 設置區塊頭“檢查點”；2. 信任觀察到的鏈首塊，並執行實際的工作來獲取該鏈首塊，然後對其進行異步驗證。我們可以將這些作為功能標誌（feature flag）提供給用戶，讓用戶在安全性和便捷性方面自行權衡取捨。

B：數據索引

有一些RPC 端點很難直接構建在現有網絡架構上。客戶端目前可以通過在區塊鏈歷史記錄上創建索引來服務這些端點。存在問題的端點主要有：

eth_getBlockByNumbereth_getTransactionByHash

eth_getBlockByNumber

端點的難點在於叔塊。任意區塊高度都有可能出現無限個有效區塊，但是只有其中一個區塊在正統鏈上。因此，客戶端在拼湊正統鏈時也會構建自己的索引來將block_number 映射到block_hash 上。當客戶端通過JSON-RPC 請求某個區塊號的區塊時，該索引會將這一請求轉化為請求某個哈希值的區塊。

eth_getTransactionByHash

也存在同樣的問題。如果我們將叔塊納入考慮，一筆交易可能存在於多個不同的區塊中。但是，單就正統鏈而言，一筆交易只存在於一個區塊內。客戶端在處理正統鏈時會創建一個索引來將transaction_hash 映射到(block_hash, transaction_index) 上。當客戶端收到對某筆交易的數據請求時，該索引會將這一請求轉化為允許查找該交易以及包含該交易的正統區塊。交易和區塊都必須包含在JSON-RPC 響應內。

因此，我們需要一個機制來顯示這些索引。

區塊頭累加器為我們提供了一種機制，可以讓索引數據成為正統鏈的一部分。

C：降低個體存儲要求

以太坊協議自設計之始，就將DevP2P 以太坊網絡中的節點設想為能夠響應任何關於查找區塊鏈歷史記錄的請求—— 無論是最新的區塊、很老的區塊還是介於二者之間的區塊。以太坊網絡沒有機制可以讓節點僅存儲區塊鏈歷史記錄的子集。從根本上來說，整個網絡都依賴於所有節點都存儲所有數據這一假設。網絡本身無法強制節點存儲所有數據，但是客戶端會與無法響應其請求數據的對等節點斷開連接。這在一定程度上保障了安全性，因為無法響應請求的客戶端不太可能會維護健康的對等連接。

因此，首先需要解決的問題是，創建一種機制讓單個節點可以僅存儲區塊鏈歷史記錄的子集，同時讓網絡為節點提供一種機制，以便節點快速找到擁有它們所需數據的節點。

事實證明，這是Kademlia DHT 網絡的新興屬性。該網絡拓撲自身的系統就可以在任意大的密鑰集中進行

O(log(N))

查找。假設我們要查找區塊哈希和交易哈希之類的數據。我們可以通過DHT 查找它們，使用對應區塊頭對其進行驗證，並使用區塊頭累加器來證明它們在正統鏈上。

Alexandria DHT

“Alexandria” 是Kademlia DHT 網絡的暫定名稱。該網絡旨在按需提供區塊鏈歷史記錄的訪問權限。該網絡本身構建在Discovery v5 協議上（信標鍊和以太坊網絡也是基於該協議構建的）。這就意味著，絕大部分（乃至所有）語言編寫的客戶端都會有可用的實現。

雖然我們沒有嚴格要求修改核心協議來添加區塊頭累加器，但是這樣做確實可以大幅改善這一情況。即使沒有Alexandria，使用累加器也會讓核心協議如虎添翼。

我們還需要解決可擴展性問題。將區塊號映射到的正統區塊哈希值的正統區塊頭索引相對較小，僅包含一個條目（每個區塊頭對應一個條目）。然而，交易索引很大，包含近十億個條目（每發送一筆交易都會有一個條目）。相比之下，廣泛使用的BitTorrent DHT 包含大約2600 萬個不同的種子。以太坊主網需要在我們的DHT 上存儲大約50 倍的數據。

構建Alexandria DHT 並為其製定規範是一個持續性的研究主題，目前已經有了一個還在不斷完善中的大致規範和概念證明客戶端。我們還在繼續進行開發，之後會公佈新的進展。

（未完）

原文鏈接:https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients-part-2/

作者: Piper Merriam

翻譯&校對: 閔敏&阿劍