在前幾期文章中，我們由淺入深地介紹了 GHAST 共識協議的設計思想。
但，對于一個公有鏈來說，保證所有節(jié)點對交易排序達成共識只能算是邁出了第一步，距離成功還相當遙遠。
之后的幾期文章將著重討論有了一個好的共識協議之后，在提高 TPS 的這條道路上還有哪些問題需要解決。
社區(qū)朋友們經常提到這樣一個問題：Conflux 把 TPS 大幅度提高以后，數據怎么存？
以現在 Conflux 的網絡參數為例，平均每秒生成 4 個區(qū)塊，每個區(qū)塊大小約為 300KB。那么在滿載的情況下，一秒的吞吐量為 1.2MB，一天約 100GB，每年新增的交易歷史數據可達 30TB。
在企業(yè)級和工業(yè)級的應用中存儲 30TB 數據并不是一件特別困難的事情，按照現在的市場價 3 塊 10TB 硬盤只需 5000-7000 元。但是不同于 Hashgraph 那樣的“企業(yè)級聯盟鏈”，Conflux 要最大程度地保證去中心化，因此就必須盡可能地降低參與共識的成本。
為了降低參與共識的門檻，Conflux在開發(fā)時把全節(jié)點的最低運行配置限制在 2019 年主流家用臺式機的水平。包括同步交易、執(zhí)行交易、驗證交易、維護樹圖結構等操作在內，全節(jié)點消耗的CPU、硬盤、內存等計算資源受到了非常嚴格的控制。因此，通過要求礦工增加新硬盤以存儲新增數據的“簡單解決方案”從一開始就不在考慮范圍之內。
高吞吐量還帶來另外一個問題：新節(jié)點加入的時候，需要花多長時間來同步已有的數據？
為了解決高吞吐量帶來的存儲和同步的問題，Conflux 采用了如下方案：對于足夠老的區(qū)塊，全節(jié)點只需存儲區(qū)塊頭而不用存儲區(qū)塊內的具體交易信息。Conflux 未來會提供“檔案節(jié)點”（Archive Node）的代碼，允許任何人運行一個檔案節(jié)點，存儲所有歷史數據。
上述設計可能與大家直覺中認識的區(qū)塊鏈有些出入，所以下面我們解釋一下，為什么這樣的設計沒有丟失區(qū)塊鏈基本的屬性。
讓我們一起來看一下 Conflux的區(qū)塊頭里都包含哪些信息：
首先，區(qū)塊頭包含所有區(qū)塊引用的信息。這意味著 Conflux 的樹圖結構是在每個全節(jié)點都完整保存的。
其次，工作量證明要求每個區(qū)塊頭的哈希值足夠小，需要有足夠多的“前導0”。即使不保存區(qū)塊內的交易，僅從區(qū)塊頭也足以判斷區(qū)塊生成時是否付出了足夠的工作量。也就是說，區(qū)塊頭中還保留了工作量證明的信息。
因此，區(qū)塊之間的結構和區(qū)塊頭中的信息，都是以去中心化和不可篡改的方式，在每一個全節(jié)點那里被存下來的。攻擊者如果想改寫歷史，就必須付出與“歷史累計工作量”相當的代價。
除了樹圖結構和工作量證明外，區(qū)塊頭還包含有這個區(qū)塊交易和交易執(zhí)行結果的默克爾樹根（Merkle Root）。這里的默克爾樹根實際上就是一個代表了當前的數據內容的哈希值。Conflux 的每個區(qū)塊頭包含 3 個這樣哈希值：
· 交易哈希根 （Transaction Root）：對應于區(qū)塊內所有交易內容。
· 狀態(tài)哈希根 （State Root）：對應于交易執(zhí)行后的“世界狀態(tài)”，包括每個賬戶地址的余額和所有智能合約的狀態(tài)。（由于采用了延遲執(zhí)行的策略，在 Conflux 里區(qū)塊頭里的狀態(tài)根對應的是執(zhí)行了之前區(qū)塊里的交易后的狀態(tài)，該區(qū)塊內的交易將延遲到更晚的區(qū)塊才會執(zhí)行。）
· 交易收據哈希根 （Receipt Root）：對應于合約執(zhí)行過程中產生的收據。包括執(zhí)行是否成功，執(zhí)行過程中是否觸發(fā)了轉賬等。
如果某個用戶想要獲得較早的交易數據和執(zhí)行結果，則他可以從“檔案節(jié)點”那里查詢，并通過比對區(qū)塊頭中的哈希值來判斷檔案節(jié)點提供的數據是否正確。（這里每一個哈希值本質上都是一個 Merkle Tree 的 Root Hash，所以檔案節(jié)點只需提供被查詢數據的默克爾證明 Merkle Proof 就可以了，而不用傳輸整個區(qū)塊。）由于哈希函數可以抗碰撞的特點，檔案節(jié)點無法為一筆不存在的交易偽造一個能通過檢測的證明。
對于檔案節(jié)點來說，唯一的攻擊方式是拒絕提供交易數據，由此帶來的后果至多也只是影響到歷史交易的可查詢性。即使沒有任何一個誠實的節(jié)點保存較早的歷史交易，那些交易也只會被遺忘而不會被篡改，交易的不可篡改性依然可以得到保證。
由于檔案節(jié)點的“作惡”方式非常有限，所以檔案節(jié)點本身對去中心化要求也沒那么高，完全可以由 Conflux 基金會和社區(qū)共同維護若干個檔案節(jié)點。
實際上，因為運行檔案節(jié)點并不需要任何審核或許可，所以大用戶也可以根據業(yè)務需要自己運行或委托他人運行檔案節(jié)點，以此確保查詢歷史交易數據的性能和可靠性。
對于在 Conflux 上運行的 DApp 來說，如果其本身需要保存和隨時訪問的數據量不是很大 —— 比如說每年新增 1MB 數據，則這些業(yè)務數據完全可以存儲在智能合約的內部狀態(tài)里。存儲于合約內部狀態(tài)的數據會作為世界狀態(tài)的一部分被每一個全節(jié)點保存和同步，無需自己運行檔案節(jié)點也可以保證最高程度的可用性。
下載文檔
