樹圖區(qū)塊鏈Conflux研究院：樹圖區(qū)塊鏈Conflux上的輕節(jié)點設計

近日，樹圖區(qū)塊鏈Conflux研究院在介紹延遲執(zhí)行策略時提到樹圖區(qū)塊鏈Conflux的輕節(jié)點設計，并為我們點明了疑惑。

樹圖區(qū)塊鏈Conflux提出解釋道：為了節(jié)約計算資源，在轉發(fā)區(qū)塊時可以只檢查區(qū)塊的格式和引用是否合法(包括工作量證明)，而盡量少檢查區(qū)塊中所存的狀態(tài)根(State Root)。但是不強制檢查狀態(tài)根在安全性上會帶來一些隱患，例如有些礦工可能會偷懶，只打包交易而不管實際執(zhí)行交易，也不去驗證收到的區(qū)塊里的狀態(tài)根的正確性——這樣就可以省下執(zhí)行交易、維護和更新狀態(tài)的開銷。

當然，對于自己親力親為執(zhí)行所有交易的全節(jié)點來說，即使有一小撮礦工偷懶實際上也不會影響他們對于當前共識狀態(tài)的判斷。只要偷懶的礦工仍完整地執(zhí)行共識層協(xié)議，按照協(xié)議要求檢查區(qū)塊間的引用關系和選擇引用的區(qū)塊，則他們的算力依然為保證賬本中的交易順序不可篡改作出貢獻。

但是對于輕節(jié)點來說，區(qū)塊內的狀態(tài)根不對就是一個相當嚴重的問題了。這是因為輕節(jié)點自己沒有能力維護當前整個共識系統(tǒng)里所有賬戶的狀態(tài)——否則也就不是“輕節(jié)點”了——只能選擇信任全節(jié)點提供的(帶有默克爾樹證明的)狀態(tài)。如果多個全節(jié)點提供的狀態(tài)不一致，輕節(jié)點就難以判斷當前的真實狀態(tài)。

以比特幣的輕節(jié)點為例，只需要保留每個區(qū)塊的區(qū)塊頭(Block Header)就可以用 SPV(Simplified Payment Verification)的方式驗證一筆交易是否已被確認了。

比特幣的 SPV 驗證步驟如下：1)通過區(qū)塊頭中保存的默克爾樹根(Merkle Root)和全節(jié)點提供的默克爾樹證明(Merkle Proof)，可以非常容易地驗證某個區(qū)塊里包含特定的交易;2)如果包含交易的區(qū)塊后面跟了足夠多的區(qū)塊(比如說6個)就可以認為這筆交易已經(jīng)被確認了——實際上這里是區(qū)塊被確認，但因為比特幣最長鏈上的所有交易都會被執(zhí)行，所以區(qū)塊被確認等價于交易被確認。

理論上，只要能生成足夠多的比特幣區(qū)塊，配合對于網(wǎng)絡連接的日食攻擊，就可以騙過輕節(jié)點，讓其以為一筆不在真實的比特幣網(wǎng)絡最長鏈上的交易已經(jīng)被確認了，從而實現(xiàn)雙花攻擊?，F(xiàn)在比特幣的 UTXO 已經(jīng)達到了數(shù) GB 的規(guī)模，很多場合只能通過輕節(jié)點用 SPV 的方式確認交易，理論上都會受到上述攻擊的威脅。

但是事實上很少聽說因為 SPV 驗證受到這種雙花攻擊的案例，這又是為什么呢?樹圖區(qū)塊鏈Conflux研究所同樣為我們進行了解惑。

主要的原因還是在于成本。以 6 個區(qū)塊確認為例，欺騙輕節(jié)點實現(xiàn)雙花攻擊需要攻擊者至少挖到 7 個比特幣區(qū)塊，并且這些區(qū)塊都不在比特幣的最長鏈上——否則就變成真的確認交易了。

如果挖的這些區(qū)塊難度和真實的比特幣網(wǎng)絡相當，則意味著攻擊者要放棄 7 個得到比特幣區(qū)塊獎勵的機會。按照現(xiàn)在的比特幣每個區(qū)塊 12.5個比特幣的獎勵計算，除非雙花攻擊的交易價值超過 75 個比特幣，否則這樣的攻擊就是虧本的，因此自然不會有人去實施。如果再加上實施日食攻擊的成本，則上述攻擊就更加無利可圖了。

所以在比特幣網(wǎng)絡中，輕節(jié)點只需大致知道正確的挖礦難度值，就不用擔心在金額不太大的交易中因為采用 SPV 確認規(guī)則而被騙。通過 SPV 方式確認交易，至少在比特幣的區(qū)塊獎勵再減半幾次之前都還是相當安全的。當然，如果真的是大額比特幣交易的話，就需要增加等待的區(qū)塊數(shù)或者用全節(jié)點驗證了。

以太坊的輕節(jié)點也可以通過類似的方式驗證交易執(zhí)行的結果或查詢賬戶的狀態(tài)，只需全節(jié)點根據(jù)節(jié)點中對應交易收據(jù)和賬戶狀態(tài)的默克爾樹根提供相應的證明即可。

與比特幣這樣“一根筋”的區(qū)塊鏈系統(tǒng)不同，樹圖區(qū)塊鏈Conflux 為了更高的系統(tǒng)性能采用了并發(fā)出塊的樹圖結構以及更快的出塊速度(平均每秒4塊)，并且減少了非必要情況下對于狀態(tài)根的驗證。這些改動不會影響全節(jié)點對于共識的判斷，卻可能為輕節(jié)點驗證當前狀態(tài)帶來困難。

為此，樹圖區(qū)塊鏈Conflux 引入了 Blaming 機制來幫助輕節(jié)點快速地確認當前賬戶狀態(tài)和每筆交易執(zhí)行的結果。

簡單來說，每個區(qū)塊自己區(qū)塊頭的 Blaming 域指出自己認可的上一個“正確的主鏈區(qū)塊”，這里的“正確”指區(qū)塊的狀態(tài)根和 Blaming 域都是正確的。例如如果一個區(qū)塊認為自己的父區(qū)塊就是完全正確的，則 Blaming 域就填 0;如果認為父區(qū)塊不正確，但是祖父區(qū)塊正確，則填 1;以此類推，如果認為祖父區(qū)塊也不正確則相應地要填一個大于1的整數(shù)用來指示最后一個正確區(qū)塊的位置，即落在中間的所有區(qū)塊都會被指為“狀態(tài)不正確的區(qū)塊”。

對于狀態(tài)根的判斷比較容易理解：打包新區(qū)塊的礦工節(jié)點需要沿著樞軸鏈執(zhí)行每個 Epoch 中的交易，在這個過程中自然會知道每個處在樞軸鏈上的“主鏈區(qū)塊”應該有什么樣的狀態(tài)根，因此就可以判斷出實際處在樞軸鏈上的區(qū)塊是否填對了這一項。而且因為按照樞軸鏈指定的順序執(zhí)行所有交易本來就是每個全節(jié)點都應該做的，所以上述檢查并不帶來額外的負擔。檢查過后，就已經(jīng)可以確定哪些主鏈區(qū)塊的狀態(tài)根是正確的了。但是由于主鏈上有很多區(qū)塊，顯然不可能每次都一一羅列出哪些區(qū)塊的狀態(tài)根是對的，哪些是錯的。這就用到了 Blaming 機制的第二部分——關于之前區(qū)塊 Blaming 域的 Blame。

每個區(qū)塊 A 在 Blaming 域都會指明它認為的主鏈上最后一個正確的區(qū)塊 B，這表示區(qū)塊 A 認可區(qū)塊 B 的所有觀點：除了認為區(qū)塊 B 的狀態(tài)根正確以外，還認可區(qū)塊 B 的 Blaming 域是正確的。這就意味著區(qū)塊 A 也認可了區(qū)塊 B 所指示的在 B 之前的最后一個正確的主鏈區(qū)塊 C，從而進一步認可了區(qū)塊 C 所指的 C 之前最后一個正確區(qū)塊 D，……直至創(chuàng)世塊位置。

因為創(chuàng)世塊總是對的，所以上述 Blaming 的過程是有限的，每個區(qū)塊在 Blaming 域填的數(shù)也不會超過該區(qū)塊的高度。

通過這種方式，就可以把每個區(qū)塊 Blaming 域存的一個數(shù)字擴展到一組狀態(tài)根得到當前區(qū)塊認可的主鏈區(qū)塊。下圖的例子即說明了如何通過 Blaming 機制擴展對于“正確區(qū)塊”的判斷。

由于 Blaming 域是在每個區(qū)塊的區(qū)塊頭部分的，所以輕節(jié)點也可以很容易看到礦工們對于其它區(qū)塊的狀態(tài)根是否正確的看法。根據(jù)這些信息，輕節(jié)點就可以比較容易地判斷哪些區(qū)塊的狀態(tài)根是值得信任的，哪些區(qū)塊的狀態(tài)根有問題了。然后只需選擇相信基于值得信任的狀態(tài)根做出的證明即可。

生成海報

免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產(chǎn)權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。