以太坊無狀態(tài)客戶端是什么

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：符乾江