在前幾期文章中，我們由淺入深地介紹了 GHAST 共識協(xié)議的設(shè)計(jì)思想。

但，對于一個(gè)公有鏈來說，保證所有節(jié)點(diǎn)對交易排序達(dá)成共識只能算是邁出了第一步，距離成功還相當(dāng)遙遠(yuǎn)。

之后的幾期文章將著重討論有了一個(gè)好的共識協(xié)議之后，在提高 TPS 的這條道路上還有哪些問題需要解決。

社區(qū)朋友們經(jīng)常提到這樣一個(gè)問題：Conflux 把 TPS 大幅度提高以后，數(shù)據(jù)怎么存？

以現(xiàn)在 Conflux 的網(wǎng)絡(luò)參數(shù)為例，平均每秒生成 4 個(gè)區(qū)塊，每個(gè)區(qū)塊大小約為 300KB。那么在滿載的情況下，一秒的吞吐量為 1.2MB，一天約 100GB，每年新增的交易歷史數(shù)據(jù)可達(dá) 30TB。

在企業(yè)級和工業(yè)級的應(yīng)用中存儲 30TB 數(shù)據(jù)并不是一件特別困難的事情，按照現(xiàn)在的市場價(jià) 3 塊 10TB 硬盤只需 5000-7000 元。但是不同于 Hashgraph 那樣的“企業(yè)級聯(lián)盟鏈”，Conflux 要最大程度地保證去中心化，因此就必須盡可能地降低參與共識的成本。

為了降低參與共識的門檻，Conflux在開發(fā)時(shí)把全節(jié)點(diǎn)的最低運(yùn)行配置限制在 2019 年主流家用臺式機(jī)的水平。包括同步交易、執(zhí)行交易、驗(yàn)證交易、維護(hù)樹圖結(jié)構(gòu)等操作在內(nèi)，全節(jié)點(diǎn)消耗的CPU、硬盤、內(nèi)存等計(jì)算資源受到了非常嚴(yán)格的控制。因此，通過要求礦工增加新硬盤以存儲新增數(shù)據(jù)的“簡單解決方案”從一開始就不在考慮范圍之內(nèi)。

高吞吐量還帶來另外一個(gè)問題：新節(jié)點(diǎn)加入的時(shí)候，需要花多長時(shí)間來同步已有的數(shù)據(jù)？

為了解決高吞吐量帶來的存儲和同步的問題，Conflux 采用了如下方案：對于足夠老的區(qū)塊，全節(jié)點(diǎn)只需存儲區(qū)塊頭而不用存儲區(qū)塊內(nèi)的具體交易信息。Conflux 未來會(huì)提供“檔案節(jié)點(diǎn)”（Archive Node）的代碼，允許任何人運(yùn)行一個(gè)檔案節(jié)點(diǎn)，存儲所有歷史數(shù)據(jù)。

上述設(shè)計(jì)可能與大家直覺中認(rèn)識的區(qū)塊鏈有些出入，所以下面我們解釋一下，為什么這樣的設(shè)計(jì)沒有丟失區(qū)塊鏈基本的屬性。

讓我們一起來看一下 Conflux的區(qū)塊頭里都包含哪些信息：

首先，區(qū)塊頭包含所有區(qū)塊引用的信息。這意味著 Conflux 的樹圖結(jié)構(gòu)是在每個(gè)全節(jié)點(diǎn)都完整保存的。

其次，工作量證明要求每個(gè)區(qū)塊頭的哈希值足夠小，需要有足夠多的“前導(dǎo)0”。即使不保存區(qū)塊內(nèi)的交易，僅從區(qū)塊頭也足以判斷區(qū)塊生成時(shí)是否付出了足夠的工作量。也就是說，區(qū)塊頭中還保留了工作量證明的信息。

因此，區(qū)塊之間的結(jié)構(gòu)和區(qū)塊頭中的信息，都是以去中心化和不可篡改的方式，在每一個(gè)全節(jié)點(diǎn)那里被存下來的。攻擊者如果想改寫歷史，就必須付出與“歷史累計(jì)工作量”相當(dāng)?shù)拇鷥r(jià)。

除了樹圖結(jié)構(gòu)和工作量證明外，區(qū)塊頭還包含有這個(gè)區(qū)塊交易和交易執(zhí)行結(jié)果的默克爾樹根（Merkle Root）。這里的默克爾樹根實(shí)際上就是一個(gè)代表了當(dāng)前的數(shù)據(jù)內(nèi)容的哈希值。Conflux 的每個(gè)區(qū)塊頭包含 3 個(gè)這樣哈希值：

· 交易哈希根 （Transaction Root）：對應(yīng)于區(qū)塊內(nèi)所有交易內(nèi)容。

· 狀態(tài)哈希根 （State Root）：對應(yīng)于交易執(zhí)行后的“世界狀態(tài)”，包括每個(gè)賬戶地址的余額和所有智能合約的狀態(tài)。（由于采用了延遲執(zhí)行的策略，在 Conflux 里區(qū)塊頭里的狀態(tài)根對應(yīng)的是執(zhí)行了之前區(qū)塊里的交易后的狀態(tài)，該區(qū)塊內(nèi)的交易將延遲到更晚的區(qū)塊才會(huì)執(zhí)行。）

· 交易收據(jù)哈希根 （Receipt Root）：對應(yīng)于合約執(zhí)行過程中產(chǎn)生的收據(jù)。包括執(zhí)行是否成功，執(zhí)行過程中是否觸發(fā)了轉(zhuǎn)賬等。

如果某個(gè)用戶想要獲得較早的交易數(shù)據(jù)和執(zhí)行結(jié)果，則他可以從“檔案節(jié)點(diǎn)”那里查詢，并通過比對區(qū)塊頭中的哈希值來判斷檔案節(jié)點(diǎn)提供的數(shù)據(jù)是否正確。（這里每一個(gè)哈希值本質(zhì)上都是一個(gè) Merkle Tree 的 Root Hash，所以檔案節(jié)點(diǎn)只需提供被查詢數(shù)據(jù)的默克爾證明 Merkle Proof 就可以了，而不用傳輸整個(gè)區(qū)塊。）由于哈希函數(shù)可以抗碰撞的特點(diǎn)，檔案節(jié)點(diǎn)無法為一筆不存在的交易偽造一個(gè)能通過檢測的證明。

對于檔案節(jié)點(diǎn)來說，唯一的攻擊方式是拒絕提供交易數(shù)據(jù)，由此帶來的后果至多也只是影響到歷史交易的可查詢性。即使沒有任何一個(gè)誠實(shí)的節(jié)點(diǎn)保存較早的歷史交易，那些交易也只會(huì)被遺忘而不會(huì)被篡改，交易的不可篡改性依然可以得到保證。

由于檔案節(jié)點(diǎn)的“作惡”方式非常有限，所以檔案節(jié)點(diǎn)本身對去中心化要求也沒那么高，完全可以由 Conflux 基金會(huì)和社區(qū)共同維護(hù)若干個(gè)檔案節(jié)點(diǎn)。

實(shí)際上，因?yàn)檫\(yùn)行檔案節(jié)點(diǎn)并不需要任何審核或許可，所以大用戶也可以根據(jù)業(yè)務(wù)需要自己運(yùn)行或委托他人運(yùn)行檔案節(jié)點(diǎn)，以此確保查詢歷史交易數(shù)據(jù)的性能和可靠性。

對于在 Conflux 上運(yùn)行的 DApp 來說，如果其本身需要保存和隨時(shí)訪問的數(shù)據(jù)量不是很大 —— 比如說每年新增 1MB 數(shù)據(jù)，則這些業(yè)務(wù)數(shù)據(jù)完全可以存儲在智能合約的內(nèi)部狀態(tài)里。存儲于合約內(nèi)部狀態(tài)的數(shù)據(jù)會(huì)作為世界狀態(tài)的一部分被每一個(gè)全節(jié)點(diǎn)保存和同步，無需自己運(yùn)行檔案節(jié)點(diǎn)也可以保證最高程度的可用性。

責(zé)任編輯：ct