現在有一個協議轉換現象，從理論上來說，它可以轉換成很多其他不同的協議，從數學上來看，它就像如下情況。假設我們使用狀態轉移，STF（S， B） －＞ S’，其中S和S’是狀態，B是區塊（或者說它是轉賬T），并且STF是狀態轉移函數。那么，我們可以轉換為：

S －＞ S的根狀態（也就是說，Merkle樹所包含S的32位）。B －＞ （B， W），其中W是一個“見證者”，Merkle樹的分支會提供所有數據的價值，可以執行讓B進入STF－＞ STF’，這可以作為狀態根部的輸入，以及區塊鏈上的見證者，使用見證者作為“數據庫”，任何時候區塊的執行都需要閱讀任何賬戶，存儲秘鑰或者其他狀態數據【如果見證者沒有包含一些需要被請求的數據】，并且輸出新的狀態根部。

這就是，全節點只會存儲狀態根部，并且它會成為礦工的責任來打包這些Merkle樹的分支（見證者），以及區塊，還有全節點會下載以及驗證這些擴展的區塊。對于無狀態的全節點和常規的全節點來說，在網絡中共存，這都是有可能的；你需要獲得擁有區塊B的翻譯區塊，附上所需要的見證者，并且在無狀態節點存在的不同網絡協議上廣播（B， W）；如果有礦工在這個無狀態網絡上挖出區塊，那么見證者可以很簡單地去除，同時區塊會在正常的網絡上進行重新廣播。

假設真實協議中的見證者，最簡單的方法就是把它作為RLP編碼的對象，這會被客戶端解析為｛sha3（x）： x｝關鍵價值圖譜；這個圖譜然后可以很簡單地嵌入到現在的以太坊中，作為“數據庫”布局。

將以上這個想法布局到以太坊上的局限在于，還是需要礦工成為存儲狀態的全節點。有人會假設這樣一個系統，其中轉賬發出方需要存儲全狀態Trie（甚至只有和他們相關的部分），而且礦工也是無狀態的，但是問題在于以太坊的狀態存儲入口是動態的。例如，你可以假設getcodesize（sha3（sha3（…sha3（x）…）） ％ 2**160）的合約形式，其中會有幾千個sha3’s。這就導致進入的賬戶代碼只有在幾百萬gas燃料的計算消耗完成后，才可能知道。因此，轉賬發出者可以創造一個轉賬，其中包含新賬戶的見證者，進行很多計算，然后最后嘗試進入一個沒有見證者的賬戶。這就和DAO軟分叉漏洞一樣。

其中一個的解決方案，就是讓轉賬包含這些賬戶的靜態列表；例如EIP 648，但是需要精確數字，而不是一個范圍。但是就會產生一個問題：到時候，轉賬會通過網絡，賬戶狀態，進行擴散，從而因此正確的Merkle樹分支可以作為見證者，也許會和轉賬生成時的正確數據不同。為了解決這個問題，我們把見證者放在轉賬中的簽名數據之外，并且讓包含轉賬信息的礦工在有需要地時候，在轉賬前對見證者進行調整。如果礦工擁有對所有創建出來的新狀態樹節點，也就是說，在過去24小時，他們已經獲得必要的信息來更新過去24小時公開轉賬的Merkle樹分支。
這項設計有如下優勢：

1．礦工和全節點再也不需要存儲任何狀態。這會讓“快速同步”變地非?？欤赡苤恍枰獛酌耄?。

2 關于狀態存儲經濟學的問題都會導致例如租賃的設計，并且甚至目前復雜的SSTORE支出／回款架構就會消失，而且區塊鏈經濟學能夠只專注于價格帶寬和計算，這會是更加容易的問題。

3． Disk IO對于全節點和礦工來說，就不會是個問題。Disk IO是以太坊上主要的DoS攻擊來源，而且甚至現在它好像是最容易發生的DoS因素。

4． 對指定帳戶列表的轉賬要求附帶地增加了高度的可并行性；這在很多方面是EIP 648的高配版本。

5． 對于狀態存儲的客戶端，賬戶列表讓客戶端能夠從disk預取存儲數據，也許是并行的，大概率降低了DoS攻擊的漏洞。

6． 在分片區塊鏈中，通過在分片中對客戶端進行調整，從而增加安全性；客戶端分片調整地越快，在拜占庭容錯模型中，這個架構就更加安全。但是，在狀態存儲的客戶端模型中，被洗牌的客戶端就會下載新分片中的全部狀態。在無狀態的客戶端中，這部分成本為零，這就讓客戶端可以在它們創建的每個區塊間進行調整。

但是這帶來一個問題：誰存儲了這個狀態？以太坊的關鍵優勢就是這個平臺很容易使用，并且用戶不需要關心存儲私有狀態這類細節。因此，為了這類框架能夠很好地完成，我們需要復制類似的用戶經驗。這是一個關于如何做到這一點的混合建議：

1．任何創造出來的新的狀態樹對象都會默認被全節點保存3個月。這大約有2．5GB的存儲空間，而且這就好像“福利儲存”，這是基于自愿地基礎上由網絡提供。我們知道這個層次的服務當然能夠基于自愿的基礎來提供，因為目前的輕節點結構已經是基于利他主義了。在3個月后，客戶端可以隨機地忘記，以至于例如一個12個月前接觸到的狀態樹對象，還會被25％的節點存儲，而且60個月之前的對象還被5％的節點存儲。客戶端能夠嘗試使用常規的輕節點協議，來調用這些對象。

2．希望確保特定數據段的可用性客戶端可以在狀態信道中進行支付。客戶端可以設置支付節點的通道，而且在“我放棄0．0001美元，并且默認這筆支付會永遠丟失。但是，如果你之后給某個對象提供哈希H，然后我簽名，之后這個0．0001美元會到你手上”這種模式下進行有條件支付。這將標志著一個可信的承諾：可能愿意為未來的對象解鎖那些資金，檔案節點可以進入數以百萬計的這樣的安排，等待數據請求出現，并成為收入流。

3．我們期望DAPP開發人員能夠讓他們的用戶來隨機存儲一部分的存儲秘鑰，在瀏覽器本地存儲中存儲與它們的DAPP相關的部分存儲密鑰。這甚至可以故意在Web3API中很容易做到。

事實上，我們希望能夠知道“檔案節點”的數量，可以永遠存儲任何事物，并且持續足夠高來服務網絡，直到在分片引入之后，整個狀態大小超過 1－10兆字節，所以以上所說的可能甚至都不需要。

審核編輯：符乾江