Conflux 研究院

摘要： Conflux 研究院 | 交易轉發中的帶寬優化（下）

我們先來回顧一下上一期講到的交易轉發中帶寬優化的問題。

回顧

一個節點將一筆交易轉發給另一個節點時，為了節約帶寬，可以發送這筆交易的 FID (Forwarding ID) 而不是直接發送完整的交易，由接受者根據 FID 判斷是否需要向發送者請求完整的交易。我們的目標是將 FID 的長度降低到 4 個字節。

上一期的最後部分還提到如果每筆交易的 FID 固定不變，則攻擊者可以用不高的成本阻塞特定交易的廣播。基本方法是攻擊者先構造一個覆蓋所有 232 個可能的 FID 的交易庫，當受害者發出一筆交易時，攻擊者從交易庫裡選擇具有相同 FID 的交易並搶先發送給其他節點，從而使其他節點都誤以為已經收到了受害者交易，而選擇不接收完整交易。

為了解決靜態 FID 易被攻擊阻塞的問題，我們將 FID 的取值由靜態轉變成動態的。因為 FID 只是在節點與節點之間轉發交易時的臨時取值，與共識邏輯無關也不需要被記錄在區塊鏈上，所以 FID 值沒有必要是一個不變的數值。

考慮如下方案：

每個節點在計算 FID 時，並不僅僅由交易的 ID （交易的 32 字節哈希值）計算，而是選擇一個隨機數 r，通過 ID 和 r 共同計算出一個 4 字節的 FID，並將r 與 FID一同發送。這樣，當隨機數 r 改變時，交易的 FID 也會隨之發生改變，收到 FID 和 r 的節點需要根據 r 重新計算已有交易的 FID 來完成對比，並確定需要請求哪些 FID 對應的完整交易。因為一次轉發的多筆交易可以共享同一個隨機數 r， 所以這個隨機數 r 幾乎不會在帶寬上帶來額外的負擔。

由於 r 的隨機性，攻擊者並不能預計一筆交易在每次轉發時選擇的 r 和由此算出的 FID 分別是多少，自然也就無法預先構造衝突的交易了。

這個設計的另一個好處是，即便節點 B 給節點 A 發送交易時發生了 FID 值衝突，導致某筆交易沒有成功發送給節點 A，另一個節點 C 發送這筆交易給 A 時，大概率將採用不同的隨機數 r 計算 FID，相當於增加了一次把這筆交易發給 A 的機會。

只要計算 FID 的過程足夠隨機（如使用偽隨機函數），則 B 發送成功和 C 發送成功可看作是兩個獨立的事件。根據我們之前的計算，一筆交易因為 FID 值衝突而發送失敗的概率是 0.04%，而節點 B 和 C 兩次獨立發送都失敗的概率是 0.04% × 0.04%，失敗率大大降低。

然而，從隨機數計算 FID 的設計也有一個缺點：每當節點收到一個新的隨機數 r 時，就要為所有已經收到的交易（根據上一期的假設，全節點會將過去 5 分鐘內收到的 180 萬條交易和剛剛收到的 FID 對比）重新算一遍 FID，這會帶來了極大的計算負擔。

現在我們有兩種不甚滿意的方案：

靜態的 FID 方案在一些攻擊策略下有安全性問題，而完全隨機的動態的 FID 方案又有計算負擔過大的問題。

我們選擇了一種靜態和動態相結合的方案：FID 由 3 個靜態字節和 1 個動態字節構成。其中靜態字節部分直接取交易 ID (即交易 32 字節的完整哈希值)的前 3 字節，動態字節由交易 ID 和 r 共同計算得出。

這樣，根據交易 ID 的前 3 字節，我們把所有的交易放在了 224 個“桶”裡。每次一個節點收到其他節點發來的 FID 和 r 時，先根據 FID 的前 3 字節判斷交易所在的桶，再將自己已經收到的，落在這個桶裡交易根據 r 重新計算 FID 值並比對。

簡單地計算可以發現，對於 180 萬條隨機生成的交易，平均每個桶裡只有 0.1 筆交易，即使是含有交易最多的桶裡也不會超過10 條。重新計算一個桶裡交易的 FID 所需花費的成本遠遠低於重新計算所有交易的 FID。

在上面這個 3+1 動靜結合的方案下，攻擊者其實仍然可以重複類似的攻擊策略。之前的攻擊策略中，攻擊者為每一個靜態的 FID 準備一筆交易。在這一策略中，攻擊者為每個桶預先準備一些交易。當受害者的交易出現後，攻擊者在短時間內大量廣播與受害者交易在同一個桶裡的交易，就能夠降低受害者交易被轉發到其他節點的概率。即使同一筆交易每次轉發時採用一個完全隨機的動態字節，但是這個動態字節只有 256 種可能的取值，所以一個桶中的交易越多，衝突概率也會越高。

為了應對上述攻擊，我們引入了一個額外的規則：如果一個節點收到一個 FID 時，發現這個 FID 對應的桶裡已經有不少於 10 條交易，就不再使用 FID 來判斷，而是直接請求完整的 32 字節交易哈希值來對比是否接受過這筆交易。這樣，攻擊者就不能再通過製造衝突的 FID 來阻塞交易廣播了，因為衝突過多的時候反而無法起到阻塞的作用。

這條額外的規則觸發時會讓交易轉發退化到沒有使用 FID 優化的情況。但是因為正常情況下每個桶裡期望只有 0.1 筆交易，幾乎不可能發生超過 10 筆交易落在同一個桶裡的情況，所以這條額外的規則在系統沒有遭到攻擊時並不會被觸發。而當系統真的遭到攻擊的情況下，保護系統的安全性和穩定性才是最重要的，即便為此而降低系統的吞吐量也是可以接受的妥協。

（1、 內容來自鏈得得內容開放平臺“得得號”，稿件內容僅代表作者觀點，不代表鏈得得官方立場。2、 凡“得得號”文章，原創性和內容的真實性由投稿人保證，如果稿件因抄襲、作假等行為導致的法律後果，由投稿人本人負責。3、 得得號平臺發佈文章，如有侵權、違規及其他不當言論內容，請廣大讀者監督，一經證實，平臺會立即下線。如遇文章內容問題，請發送至郵箱：[email protected]）

閱讀更多 鏈得得APP 的文章

關鍵字: 一個 額外 設計