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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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