在上一篇關于以太坊1.x的文章中，我們對Eth 1.x研究的起源、利害因素以及一些可能的解決方案做了簡要回顧。在上篇文章的結尾我們提到了“無狀態”以太坊的概念，而在本文中我們將進一步詳細闡釋無狀態客戶端。

無狀態（stateless）是Eth 1.x研究的新方向，因此我們將進行一次相對深入的探析，以便對未來可能面臨的挑戰和可能性了然于胸。如果讀者有興趣進一步了解，我會盡量提供相關資源的鏈接。

什么是“狀態”？

要解釋無狀態以太坊，我們首先需要理解“狀態”（state）的概念。當我們提到“狀態”時，一般是指“事務的狀態”。

以太坊的完整“狀態”描述了所有賬戶和余額的當前狀態，以及在EVM中部署和運行的所有智能合約的集體歷史。鏈上每個最終確定的區塊，都有且只有一個狀態，這是由網絡中的所有參與者共同確認的。每當有新的區塊被添加到鏈上，狀態都會隨之改變且更新。

在Eth 1.x研究語境中，我們不僅要知道狀態是什么，還要知道它在協議（據黃皮書中的定義）和大多數客戶端實現（如geth、parity、trinity、besu等）中是如何表現的。

什么是Trie？

以太坊所使用的數據結構叫作Merkle Patricia Trie。有趣的是，‘Trie’最初截取自‘retrieval’一詞，但大多數人會將其發音為‘try’，以區別于‘tree’。回到正題，關于MPT數據結構，我們需要了解：

在trie的一端，是描述狀態（值節點）的所有特定數據片段。數據可以是特定帳戶的余額，也可以是存儲在智能合約中的變量（例如某種ERC-20通證的總供應量）。Trie的中間則是分支節點，通過哈希運算將所有值串聯在一起。分支節點是包含其子節點哈希的數組（array），每個分支節點隨后再次經過哈希并歸入其父節點的數組中。這一連串的哈希最終會到達trie另一端的一個狀態根節點。

在上面的簡化圖示中，我們可以看到一些數值，以及得到這些值的路徑。例如，為了得到V-2，我們經歷了1，3，3，4的路徑。同理，V-3可通過路徑3，2，3，3來獲取。需要注意的是，本例中的路徑長度始終為4個字符，并且要獲取某個值只有一條可用路徑。

該結構具有確定性和可加密驗證的重要特性：生成狀態根的唯一方法就是通過計算狀態的每個單獨數據段，如此一來，通過比對根哈希和前序哈希（Merkle證明），就可以輕松證明兩個狀態是相同的。反之，我們也不能用相同的根哈希創建兩個不同的狀態，任何使用不同值修改狀態的嘗試都將導致不同的狀態根哈希。

以太坊通過引入新節點類型，擴展節點（extension nodes）和葉節點（leaf nodes）來提升效率，優化trie結構。通過將路徑的一些部分編碼為節點，如此一來trie就會更加緊湊。

在這種優化后的MPT結構中，每個節點都需要在多個后續節點共享的路徑壓縮部分或值（若有必要，由路徑的其他部分前綴）之間進行選擇。其實是相同的數據和組織，但是這個trie結構只需要9個節點而非18個節點。看起來似乎更有效率，但事后看來，實際上這并不是最理想的。我們將在下一節討論原因。

要獲取狀態的特定部分（例如賬戶當前的ETH余額），需要從狀態根開始，沿著trie的路徑從一個節點到另一個節點，直到達到所需的值。在每個節點上，路徑中的字符用來決定下一個目的節點，就像是一個用于導航哈希數據結構的探測棒。

而在以太坊真正使用的版本中，路徑是長度為64個字符（256位）的地址哈希，值是RLP編碼數據［1］。分支節點是包含17個元素的數組（其中有16個是每個可能的十六進制字符，剩余一個則為值），而葉節點和擴展節點包含2個元素（一個是部分路徑，另一個是下一個子節點的值或哈希）。要了解更多細節，可以瀏覽以太坊的wiki頁面［2］，或者，如果你喜歡親自鉆研，那么這篇文章提供了一個很棒的Python DIY trie練習［3］（不幸的是這篇文章已經過時了）。

在數據庫中使用Trie

讀到這里我們應該提醒自己，trie結構只是一個抽象的概念。這是一種將以太坊狀態的整體打包成統一結構的方法。該結構需要在客戶端的代碼中實現，并存儲在磁盤上（或者分布在全球的數千個磁盤中）。這意味著要采用多維trie結構并將其嵌入到一個普通的只理解［key，value］對的數據庫中。

在大多數以太坊客戶端（turbo-geth除外）中，MPT是通過為每個節點創建不同的［key， value］對來實現的，其中value是節點本身，key是該節點的哈希。

因此穿越trie的過程，或多或少與之前描述的理論上的過程相同。要查找帳戶余額，我們將從根哈希開始，并在數據庫中查找其值以獲取第一個分支節點；使用哈希地址的第一個字符，可以找到第一個節點的哈希；在數據庫中查找哈希，然后得到第二個節點；使用哈希地址的下一個字符，我們可以找到第三個節點的哈希。如果運氣好的話，我們沿途可能會碰到一個擴展節點或葉節點，也就不需要檢查全部的64個半字節。無論如何，我們最后會找到所需的帳戶，并從數據庫中檢索其余額。

這個過程與計算每個新區塊的哈希在很大程度上是相似的，但是是反過來的：從所有邊緣節點（賬戶）開始，通過連續的哈希來構建trie，直到最后一個新的根哈希，再與鏈中最新確認的區塊進行比較。

這就是狀態trie明顯的效率優勢所能夠施展的地方：在磁盤上重構整個trie的強度是非常大的，以太坊使用的優化版MPT結構通過折衷實現效率來提高協議效率。

這些額外的節點類型（葉節點和擴展節點）理論上節省了存儲trie所需的內存，但它們會使得用于修改常規數據庫中狀態的算法更加復雜。不過一臺功能強大的計算機設備能夠極速執行該過程。然而，純粹的處理能力也只能起這么大的效用了。

節點同步

到目前為止，我們的討論還局限在運行以太坊客戶端（如geth）的個體計算機范圍中。而以太坊是一個網絡，所有這一切的關鍵是要在全球數千臺計算機以及不同客戶端之間達到統一的狀態共識。

不斷洗牌的#Defi、cryptokitty拍賣或cheeze巫師大戰的token，以及常規的ETH交易都會碰撞在一起，給以太坊客戶端創建一個極速變化的狀態。而以太坊客戶端需要保持狀態同步，隨著以太坊越來越廣泛的應用，同步狀態就會愈難，狀態trie的結構也會愈深。

“Turbo-geth是抽薪止沸的一種實現：其將trie數據庫扁平化，并使用節點的路徑（而非其哈希）作為［key， value］對。這有效地使得檢索操作無關樹的深度，并帶來了各種酷炫的功能，使得運行全節點時性能提升且減少磁盤負載。”

以太坊的狀態非常大，并且隨每一個區塊而變化。那么狀態和改變究竟有多大？我們可以將整個以太坊的當前狀態大致定位在狀態trie的約4億個節點上。其中，大約每15秒需要添加或修改約3000個（甚至多達6000個）節點。與以太坊區塊鏈保持同步，實質上就是不斷有效地構建新的狀態trie。

“這種狀態trie數據庫操作的多步驟過程，正是以太坊客戶端占用如此龐大的磁盤I/O和內存的原因，即便是“快速同步”（fast sync）模式可能也需要長達6個多小時才能完成。而要運行一個以太坊全節點，快速SSD（而非便宜但可靠的HDD）必不可少，因為處理狀態更改對磁盤讀/寫的要求非常高。”

其中需要注意的關鍵點在于，建立一個新節點進行同步，與保持現有節點同步，這兩者之間相去甚遠。而當我們實現無狀態以太坊之后，它們之間的區別將會模糊化（希望如此）。

最直接的同步節點的方法是使用“full sync”（完全同步）方式：從創始區塊開始，將每個區塊中的每筆交易恢復成列表，并構建狀態trie。后續區塊一旦產生，狀態trie就會被修改，隨著區塊鏈完整歷史的重現對節點進行添加或修改。而從創世區塊開始下載并執行每個區塊的狀態更改，需要花費整整一個星期的時間。如果你同步時不亟待進行新的交易，那就只是時間問題。

另一種同步方式“fast-sync”（快速同步）名副其實，其同步速度更快，但也更復雜：新客戶端可以從最近受信任的“檢查點”（checkpoint）區塊請求狀態條目，而不再需要從創世區塊開始。該方式需要下載的信息量要少得多，但仍然有許多信息需要處理。快速同步目前不受帶寬限制，而是受磁盤性能的限制。

實質上，進行快速同步的節點是在與鏈的末端進行賽跑。節點需要在狀態陳腐（stale）并且全節點不再提供該狀態之前從“檢查點”（checkpoint）中獲取所有狀態（如果發生這種情況，節點可以輾轉至新的檢查點）。一旦快速同步節點克服了這種障礙，并使其狀態完全與檢查點（checkpoint）同步，就可以切換為完全同步，即從每個區塊中包含的交易生成并更新自己的狀態副本。

什么是區塊見證（witness）？

講到這里，我們可以開始探索無狀態以太坊的概念。無狀態以太坊的主要目標之一就是減少新節點同步過程的痛苦。考慮到只有0.1%的狀態是隨區塊變化的，所以似乎應該有一種方式可以減少切換為完全同步之前需要下載的所有額外信息。

但這也是以太坊采用加密安全數據結構所帶來的挑戰之一：在trie結構中，僅更改一個值就會導致全然不同的根哈希。這是一種特性，不是漏洞。這使得每個人都能確保自己和網絡中的其他節點處于同一狀態。

如果要走捷徑的話，我們需要一條關于狀態的新信息：即區塊見證（block witness）。假設此trie結構中只有一個值最近產生了改變（下圖綠色部分）：

同步狀態（包括該筆交易）的全節點將采用傳統的方式：獲取所有狀態片段，并對它們全部進行哈希運算，以創建新的根哈希。如此就可以輕松驗證自己的狀態是否與其他所有人的狀態相同（因為節點掌握了相同的哈希以及相同的交易歷史）。

那對于新加入進來的節點呢？新節點要進行驗證所需的最小信息量是多少，以保證至少在其觀察時段內的觀察結果與其它節點是一致的？

一個新的節點需要更早的全節點提供證明，證明所觀測到的交易符合迄今為止的狀態。

用抽象的術語來說，一個區塊見證（witness）證明提供了狀態trie中所有丟失的哈希，并結合了一些位置“結構”信息，表示這些哈希在狀態trie中位于何處。這使得新節點能夠將新交易包含在其狀態中，并在本地計算新的根哈希，而不需要下載狀態trie的完整副本。

簡言之，這就是beam同步（ beam sync）［4］蘊含的原理。Beam同步方案不再收集檢查點trie中的每個節點，而是開始監測并嘗試在交易發生時就執行交易，從全節點請求每個區塊的見證（witness）內容，以獲取沒有掌握的信息。隨著越來越多的狀態被新交易影響，通過beam同步逐漸填充信息，直到最終切換到完全同步，客戶端可以更信任自己的狀態副本。

不同程度的“無狀態”

隨著區塊見證（witness）的引入，“完全無狀態”概念的定義逐漸清晰。與此同時，這也是我們開始遇到瓶頸和問題的地方，并且沒有明顯可行的解決方案。

與beam同步方案不同，真正的無狀態客戶端自始至終不會保留狀態副本，而是只與區塊見證（witness）一同獲取最新的交易，只需要包含執行下一個區塊所需的一切信息。

所以我們幾乎可以預見如果整個網絡都是無狀態的，那么實際上是可以達到永動狀態的。新區塊的見證從上一個區塊產生，然后依次傳遞見證！至少可以持續到最后確認的“事務狀態”，以及該狀態產生的第一個見證。而這對于以太坊來說將是一個富有戲劇性的巨變，所以不太可能會獲得廣泛的支持。

有一種不那么激進的方法：適應不同程度的“無狀態”。在這種網絡中，會有一些節點保存完整的狀態副本，也能為其它所有節點提供最新的見證（witness）。

· 完整狀態節點會像往常一樣工作，但需要額外計算一個見證（witness）并將其添加到新區塊，或通過輔助網絡子協議廣播；

· 部分狀態節點可以只在少量區塊生成期間保留完整的狀態，或者只“監測”其相關的狀態部分，然后從見證中獲取驗證區塊所需的其余數據。這對需要運行基礎設施的DApp開發者而言大有裨益；

· 根據定義，零狀態節點想要在運行客戶端時盡可能輕巧，可以完全依賴區塊見證來驗證新的區塊。

要啟用這個方案，可能需要類似于bittorrent采用的分塊（chunking）和群集（swarming）行為，其中見證（witness）片段根據其需要進行廣播，并與具有（互補）部分狀態的其他節點建立最佳連接。或者，這可能需要制定一個狀態trie的替代實現方案，使得更適宜見證（witness）的生成。這都是我們需要研究和實驗的內容！

如若想要更深入地探析狀態節點與無狀態節點之間的權衡，可參見Alexey Akhunov的《The shades of statefulness》［5］。

這種半-無狀態方式的一個重要特點在于這些改變不一定要訴諸硬分叉形式。通過微小的并且可測試的漸進方式，就可以將以太坊的無狀態組件構建成一個輔助型子協議，或者劃分為一系列不具爭議的EIPs，而無需進行大型“信念飛躍式”的升級。

無狀態客戶端路線圖

我們在研究中遇到的一個明顯問題就是區塊見證（witness）的大小。普通區塊包含一個區塊頭和交易列表，其大小約為100 kB。相對于網絡延遲及15秒的區塊時間，這種大小可以使得區塊廣播速度較快。

然而，見證（witness）需要包含狀態trie的邊緣和深層節點的哈希。這意味著其大小要大得多：早期數據顯示大約為1 MB。因此，與網絡延遲和區塊時間相比，同步見證要慢得多，這可能會是一個障礙。

這種兩難境地類似于電影下載和流媒體之間的區別：如果網絡過慢導致流媒體無法順暢加載，那么下載完整電影就是唯一可行的選擇。如果網絡速度快，那就可以流暢播放電影。如果實際情況是網絡速度不上不下，那么我們就需要更多的數據來作出決定。那些標準之下的互聯網服務提供商，會在需求過高時認識到低速網絡的局限性。

很大程度上，這就是Eth 1.x工作組正在著手解決的為具體問題。目前，我們對假想見證網絡的了解，還不足以確定其是否能正常或理想運行，難點就在于細節（以及數據）。

一種方法是通過改變trie本身的結構（如二進制trie），考慮如何壓縮和減少見證（witness）數量，以使其在實現時更高效。另一種方法則是原型化網絡原語（例如bittorrent的swarming），使得見證能夠有效地在網絡中不同節點之間傳遞。而這兩個方案，都能受益于形式化見證規范（目前該規范還不存在）。
責任編輯；zl