復盤Arbitrum排序器Bug事件：爲何這次沒有用戶資金損失？

作者：金色財經Jason.                                            

金色財經 區塊鏈6月10日訊 本周Arbitrum的排序器代碼中的一個Bug，導致該網絡批量提交交易的功能短暫中斷，交易無法在主鏈上得到確認。隨後漏洞已被修復，交易批量提交功能已恢復。6月10日，Arbitrum基金會發布了Arbitrum排序器Bug事後分析報告，接下來就讓我們復盤看看，爲什么這次Bug事件沒有造成用戶資金損失吧。

Arbitrum排序器Bug事件時間軸

1. 2023年6月7日06:04:53，由於Arbitrum排序器L1節點暫時性問題，批量發布者未能更新其L1狀態視圖。 由於根本原因問題，Arbitrum排序器繼續嘗試查詢其先前 L1 視圖塊編號的、狀態。 這意味着即使在臨時 L1 節點問題自行解決後，批處理發布者仍會繼續嘗試查詢舊 L1 塊編號的狀態，而 L1 節點不再具有其狀態，因爲它不是存檔節點。

2. 2023年6月7日09:38:28，Arbitrum的batch poster停止發布交易，因爲它達到了配置的最大排隊交易限制（256個），排隊交易限制和mempool限制數是一樣的。如果未達到此限制，批量過帳將照常繼續。

3. 2023年6月7日上午11點09分，由於未發布批次，觸發了檢查新批次的Sequencer Inbox智能合約警報，並向Slack頻道發送了警告。

4. 上午11點10分，由於缺乏最近批量發布，觸發了基於日志警報，並且向Slack頻道發送了一個臨界級別警報。

5. 上午11點13分，社區團隊的一名成員向SRE團隊成員發起了PagerDuty，後者迅速確認了事件並开始響應。

6. 上午11:19:02，SRE團隊重啓batch poster，但由於此前提及的最大排隊交易限制，阻止了batch poster發布交易。SRE團隊注意到這個問題並开始切換到第三方L1 RPC提供商以試圖緩解這個問題。

7. 上午11:24:16，batch poster啓動5分鐘後，更新了L1狀態視圖並發布了第一批交易。

8. 上午11:25:09，batch poster配置更改爲使用第三方L1 RPC提供程序並重新啓動，因爲 SRE團隊已經开始進行此更改並且沒有注意到批處理。重啓後，繼續發生批處理交易。

9. 上午11:30:21，batch poster啓動5分鐘後，L1狀態視圖被更新，結果觸發L1狀態不同步，這也是問題的根本原因。 L1狀態更新爲最終區塊編號17428199，但卻使用了最新的隨機數178078，對應於當時的最新區塊，而不是存儲在其狀態中的最終區塊，結果導致Redis中所有排隊的交易被擦除，因爲Redis認爲這些交易已經被確認。

10. 上午11:30:26，batch poster發布了新批次。Redis依賴於L1狀態視圖來確定要發布的內容，但此時Redis隊列是空的，如前所述，L1 狀態是不正確的，而且在狀態178078中使用隨機數發布了一個批次，但爲了確定要發布的批次，使用了不相關的塊號17428199，導致一個序列號爲229209的舊批次被發布，該批次其實已經在之前11:24:16時發布過了，然後batch poster重新啓動。 因爲229209舊批次已經發布過，所以批量提交的L1交易被回滾。

11. 上午11:36:35，batch poster地址由於沒有退還Gas費用而用完了Ether，因此停止發布，這是一種有意爲之的機制，以防止batch poster消耗所有存儲在恢復批次中的gas費用。

12. 上午11點46分，Nitro團隊一名成員接到電話，要求解決批次恢復的軟件問題。

13. 上午11:58左右，Arbitrum开始收到報告，稱某些用戶發現排序器存在問題（將新排序的交易廣播到RPC 節點），這是因爲越來越多的有序交易由於batch poster問題而沒有發布到鏈上，此問題主要影響互聯網連接不良或內存分配不足的Feed客戶端，因爲它們更有可能掉线並遇到重新連接問題。Arbitrum建議運行多個RPC節點的用戶運行本地提要中繼器，以減少所需的外部帶寬。

l   中午12:03，Arbitrum取消了Cloudflare的Feed速率限制，以緩解客戶端在因互聯網連接而斷开連接後嘗試重新連接時達到速率限制的問題。

l   中午12:05，Arbitrum取消了所有Cloudflare速率限制，以允許那些節點在與提要保持連接時出現問題的人提高公共RPC利用率。

14. 下午12:12:09，故障batch poster被關閉，Redis隊列存儲清除以消除不良狀態。

15、下午12:12:40，batch poster在老版本v2.0.14上啓動，沒有root問題。

16. 下午12:21:56，新开的batch poster第一批成功，之後一直保持不間斷運行。

Arbitrum排序器Bug事件經驗教訓

本次故障是batch poster中的一個錯誤導致，排序器本身沒有受到影響或中斷，並在整個過程中繼續處理交易，有報道稱排序器資金用完是不正確的。Arbitrum資金機制由兩個錢包組成，分別是：“排序器”錢包和“gas-refunder”錢包，只有當排序器可以成功發布批次時才會被退款，Arbitrum網絡沒有就此故障向排序器退款，相關問題也不是因爲排序器資金耗盡所致，因此用戶資金沒有面臨任何風險。

Arbitrum將清理在臨時解決方案中已添加的配置選項，後續擬重新評估排序器客戶端和服務器超時問題，以提升交易積壓情況下的網絡可靠性，目前已創建了一個新的“v2.1.0-beta.2”測試版。此外，Arbitrum還將創建一個公开的網絡狀態頁面，以減少服務出現問題時造成的混亂。

本文參考自Arbitrum基金會官網

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

標題：復盤Arbitrum排序器Bug事件：爲何這次沒有用戶資金損失？

地址：https://www.torrentbusiness.com/article/43281.html

標籤：