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

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

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

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

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

將以上這個(gè)想法布局到以太坊上的局限在于，還是需要礦工成為存儲(chǔ)狀態(tài)的全節(jié)點(diǎn)。有人會(huì)假設(shè)這樣一個(gè)系統(tǒng)，其中轉(zhuǎn)賬發(fā)出方需要存儲(chǔ)全狀態(tài)Trie（甚至只有和他們相關(guān)的部分），而且礦工也是無(wú)狀態(tài)的，但是問題在于以太坊的狀態(tài)存儲(chǔ)入口是動(dòng)態(tài)的。例如，你可以假設(shè)getcodesize（sha3（sha3（…sha3（x）…）） ％ 2**160）的合約形式，其中會(huì)有幾千個(gè)sha3’s。這就導(dǎo)致進(jìn)入的賬戶代碼只有在幾百萬(wà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ì)通過(guò)網(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)賬前對(duì)見證者進(jìn)行調(diào)整。如果礦工擁有對(duì)所有創(chuàng)建出來(lái)的新狀態(tài)樹節(jié)點(diǎn)，也就是說(shuō)，在過(guò)去24小時(shí)，他們已經(jīng)獲得必要的信息來(lái)更新過(guò)去24小時(shí)公開轉(zhuǎn)賬的Merkle樹分支。

這項(xiàng)設(shè)計(jì)有如下優(yōu)勢(shì)：

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

2 關(guān)于狀態(tài)存儲(chǔ)經(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對(duì)于全節(jié)點(diǎn)和礦工來(lái)說(shuō)，就不會(huì)是個(gè)問題。Disk IO是以太坊上主要的DoS攻擊來(lái)源，而且甚至現(xiàn)在它好像是最容易發(fā)生的DoS因素。

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

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

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

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

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

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

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

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