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

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

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

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

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

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

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

2 關(guān)于狀態(tài)存儲經(jīng)濟(jì)學(xué)的問題都會(huì)導(dǎo)致例如租賃的設(shè)計(jì)，并且甚至目前復(fù)雜的SSTORE支出／回款架構(gòu)就會(huì)消失，而且區(qū)塊鏈經(jīng)濟(jì)學(xué)能夠只專注于價(jià)格帶寬和計(jì)算，這會(huì)是更加容易的問題。

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

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

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

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

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

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

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

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

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

審核編輯：符乾江