現(xiàn)在有一個協(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是一個“見證者”，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)根部，并且它會成為礦工的責(zé)任來打包這些Merkle樹的分支（見證者），以及區(qū)塊，還有全節(jié)點會下載以及驗證這些擴展的區(qū)塊。對于無狀態(tài)的全節(jié)點和常規(guī)的全節(jié)點來說，在網(wǎng)絡(luò)中共存，這都是有可能的；你需要獲得擁有區(qū)塊B的翻譯區(qū)塊，附上所需要的見證者，并且在無狀態(tài)節(jié)點存在的不同網(wǎng)絡(luò)協(xié)議上廣播（B， W）；如果有礦工在這個無狀態(tài)網(wǎng)絡(luò)上挖出區(qū)塊，那么見證者可以很簡單地去除，同時區(qū)塊會在正常的網(wǎng)絡(luò)上進行重新廣播。
假設(shè)真實協(xié)議中的見證者，最簡單的方法就是把它作為RLP編碼的對象，這會被客戶端解析為｛sha3（x）： x｝關(guān)鍵價值圖譜；這個圖譜然后可以很簡單地嵌入到現(xiàn)在的以太坊中，作為“數(shù)據(jù)庫”布局。
將以上這個想法布局到以太坊上的局限在于，還是需要礦工成為存儲狀態(tài)的全節(jié)點。有人會假設(shè)這樣一個系統(tǒng)，其中轉(zhuǎn)賬發(fā)出方需要存儲全狀態(tài)Trie（甚至只有和他們相關(guān)的部分），而且礦工也是無狀態(tài)的，但是問題在于以太坊的狀態(tài)存儲入口是動態(tài)的。例如，你可以假設(shè)getcodesize（sha3（sha3（…sha3（x）…）） ％ 2**160）的合約形式，其中會有幾千個sha3’s。這就導(dǎo)致進入的賬戶代碼只有在幾百萬gas燃料的計算消耗完成后，才可能知道。因此，轉(zhuǎn)賬發(fā)出者可以創(chuàng)造一個轉(zhuǎn)賬，其中包含新賬戶的見證者，進行很多計算，然后最后嘗試進入一個沒有見證者的賬戶。這就和DAO軟分叉漏洞一樣。
其中一個的解決方案，就是讓轉(zhuǎn)賬包含這些賬戶的靜態(tài)列表；例如EIP 648，但是需要精確數(shù)字，而不是一個范圍。但是就會產(chǎn)生一個問題：到時候，轉(zhuǎn)賬會通過網(wǎng)絡(luò)，賬戶狀態(tài)，進行擴散，從而因此正確的Merkle樹分支可以作為見證者，也許會和轉(zhuǎn)賬生成時的正確數(shù)據(jù)不同。為了解決這個問題，我們把見證者放在轉(zhuǎn)賬中的簽名數(shù)據(jù)之外，并且讓包含轉(zhuǎn)賬信息的礦工在有需要地時候，在轉(zhuǎn)賬前對見證者進行調(diào)整。如果礦工擁有對所有創(chuàng)建出來的新狀態(tài)樹節(jié)點，也就是說，在過去24小時，他們已經(jīng)獲得必要的信息來更新過去24小時公開轉(zhuǎn)賬的Merkle樹分支。
這項設(shè)計有如下優(yōu)勢：
1．礦工和全節(jié)點再也不需要存儲任何狀態(tài)。這會讓“快速同步”變地非?？欤赡苤恍枰獛酌耄?/p>
2 關(guān)于狀態(tài)存儲經(jīng)濟學(xué)的問題都會導(dǎo)致例如租賃的設(shè)計，并且甚至目前復(fù)雜的SSTORE支出／回款架構(gòu)就會消失，而且區(qū)塊鏈經(jīng)濟學(xué)能夠只專注于價格帶寬和計算，這會是更加容易的問題。
3． Disk IO對于全節(jié)點和礦工來說，就不會是個問題。Disk IO是以太坊上主要的DoS攻擊來源，而且甚至現(xiàn)在它好像是最容易發(fā)生的DoS因素。
4． 對指定帳戶列表的轉(zhuǎn)賬要求附帶地增加了高度的可并行性；這在很多方面是EIP 648的高配版本。
5． 對于狀態(tài)存儲的客戶端，賬戶列表讓客戶端能夠從disk預(yù)取存儲數(shù)據(jù)，也許是并行的，大概率降低了DoS攻擊的漏洞。
6． 在分片區(qū)塊鏈中，通過在分片中對客戶端進行調(diào)整，從而增加安全性；客戶端分片調(diào)整地越快，在拜占庭容錯模型中，這個架構(gòu)就更加安全。但是，在狀態(tài)存儲的客戶端模型中，被洗牌的客戶端就會下載新分片中的全部狀態(tài)。在無狀態(tài)的客戶端中，這部分成本為零，這就讓客戶端可以在它們創(chuàng)建的每個區(qū)塊間進行調(diào)整。
但是這帶來一個問題：誰存儲了這個狀態(tài)？以太坊的關(guān)鍵優(yōu)勢就是這個平臺很容易使用，并且用戶不需要關(guān)心存儲私有狀態(tài)這類細節(jié)。因此，為了這類框架能夠很好地完成，我們需要復(fù)制類似的用戶經(jīng)驗。這是一個關(guān)于如何做到這一點的混合建議：
1．任何創(chuàng)造出來的新的狀態(tài)樹對象都會默認被全節(jié)點保存3個月。這大約有2．5GB的存儲空間，而且這就好像“福利儲存”，這是基于自愿地基礎(chǔ)上由網(wǎng)絡(luò)提供。我們知道這個層次的服務(wù)當(dāng)然能夠基于自愿的基礎(chǔ)來提供，因為目前的輕節(jié)點結(jié)構(gòu)已經(jīng)是基于利他主義了。在3個月后，客戶端可以隨機地忘記，以至于例如一個12個月前接觸到的狀態(tài)樹對象，還會被25％的節(jié)點存儲，而且60個月之前的對象還被5％的節(jié)點存儲?？蛻舳四軌驀L試使用常規(guī)的輕節(jié)點協(xié)議，來調(diào)用這些對象。
2．希望確保特定數(shù)據(jù)段的可用性客戶端可以在狀態(tài)信道中進行支付?？蛻舳丝梢栽O(shè)置支付節(jié)點的通道，而且在“我放棄0．0001美元，并且默認這筆支付會永遠丟失。但是，如果你之后給某個對象提供哈希H，然后我簽名，之后這個0．0001美元會到你手上”這種模式下進行有條件支付。這將標(biāo)志著一個可信的承諾：可能愿意為未來的對象解鎖那些資金，檔案節(jié)點可以進入數(shù)以百萬計的這樣的安排，等待數(shù)據(jù)請求出現(xiàn)，并成為收入流。
3．我們期望DAPP開發(fā)人員能夠讓他們的用戶來隨機存儲一部分的存儲秘鑰，在瀏覽器本地存儲中存儲與它們的DAPP相關(guān)的部分存儲密鑰。這甚至可以故意在Web3API中很容易做到。
事實上，我們希望能夠知道“檔案節(jié)點”的數(shù)量，可以永遠存儲任何事物，并且持續(xù)足夠高來服務(wù)網(wǎng)絡(luò)，直到在分片引入之后，整個狀態(tài)大小超過 1－10兆字節(jié)，所以以上所說的可能甚至都不需要。
下載文檔
