區塊鏈抵抗重放攻擊的幾種方法

重放攻擊，指攻擊者重放一個在網絡上竊聽到的或在區塊鏈中看到的消息。

 重放攻擊是一個很嚴重的問題。在以太坊 Ethereum 區塊中，重放攻擊一筆交易會導致源賬戶中的餘額反覆減少，目標賬戶中的餘額反覆增多，若目標賬戶是一個合約賬戶，會反覆調用目標賬戶中的合約代碼，導致目標賬戶中 storageRoot 的改變，這一切都會導致 World State 的改變；在 Hyperledger fabric 中，重放攻擊能使驗證實體重複做計算上敏感的過程 (鏈上編碼喚醒操作) 或影響相應鏈上編碼的狀態，然而卻不需要消耗攻擊者的計算資源或者說很小的計算資源。

更糟糕的是，如果該交易是一筆付款交易，重放攻擊能導致多次付款，卻不需要來自付款者的同意。現有的系統使用以下方法阻止重放攻擊：

• 在系統中記錄交易的哈希值。這個解決方案需要驗證節點維護一個已經執行過的每筆交易哈希值的日誌，然後接收到或執行一筆新交易的時候，將其與他們本地存儲的交易記錄進行比對。很明顯，這種解決辦法不能適應大型網絡的需要，很容易就導致驗證者花費大量時間去檢查一筆交易是否被重放，比執行交易的時間都要長。
• 利用每個用戶實體維護的狀態 (Ethereum)。Ethereum 中，每一個賬戶都有一個 nonce，該值等於從該賬戶中發出的交易。如果該賬戶是一個合約賬戶，該值等於由該合約賬戶創建的新合約賬戶的數量。當一筆交易被礦工驗證是否有效的時候，礦工會比對交易中的 nonce 與該交易的發送者賬戶中的 nonce是否相等，交易其它驗證通過和執行完成後，發送者賬戶中的 nonce 會自增 1，因此當有重複交易過來的時候，會直接被判為無效，從而阻止了重放攻擊。這種方法對於存在有限實體賬戶的系統來說工作地很好，但是對於用戶的每筆交易使用不同標識的系統來說 (fabric 中的 Tcert 交易證書)，這種方法從根本上擴展性也不高，因為將有與交易數量成比例的大量用戶筆名 (一個用戶對應著很多 Tcert 即筆名)。
• 其它的資產管理管理系統，例如，比特幣，儘管沒有直接地去處理重放攻擊，它們卻能抵抗重放攻擊。在這些管理數字資產的系統中，採取了 UTXO 模型，交易的串聯構成了系統中用戶的狀態。這樣的系統對重放攻擊是天生免疫的，因為每一筆交易的輸入指定它前面出現過的交易的未花費輸出 (UTXO)，併產生新的 UTXO。交易重放攻擊會直接失敗，因為再次執行的交易的輸入指向的 UTXO 已經不存在了。但是這種方法卻不適用於更加通用的區塊鏈系統。
• Hyperledger fabric 中，採用了一種混合式解決辦法。那就是，用戶在交易中加入 nonce 值，該 nonce 值的生成方法根據該交易是否保持匿名有關，交易匿名指交易被 Tcert 簽名，非匿名指交易被 Ecert 簽名。更具體的：
• 用戶使用他們的 Ecert 提交一筆交易的時候，在交易中包含的 nonce 值，是他們用相同 Ecert 提交的上一筆交易中使用的 nonce 值經過函數 (哈希函數或者計數器函數) 的變換得到的。相同 Ecert 提交的第一筆交易中的 nonce 值要麼是系統中提前設置好的 (例，包含在創世區塊中) 要麼是被用戶自己選擇的。在第一種情況中，創世區塊需要包含 nonceall，例如，假定用戶的實體標識 IDA，則他使用 Ecert 簽名的第一筆交易中的 nonce 值為 nonce(round[0]IDA)
• a). 用戶這方：僅僅需要存儲最近使用的 nonce 值；
• b). 驗證節點這方：O(n)，n 是用戶的數量。

• 用戶使用他們的 Tcert 提交一筆交易的時候，在交易中應該包含一個隨機的 nonce 值，這將會保證兩筆交易不會形成相同的哈希值。驗證節點將哈希值存儲在本地數據庫中，如果該筆交易使用的 Tcert 沒有過期的話。所以，驗證節點在 Tcert 當前或未來的有效期內保持該 Tcert 簽名的交易哈希的更新記錄。存儲開銷： 僅僅對於驗證節點有意義：O(m)，m 是 Tcerts 有效期內大約交易的數量。