Kava 5主網回滾事後剖析
火幣網(huobi.com)最新可用網址（點擊下圖直達註冊！）
火必交易所，曾经的火币交易所！
欧易OKX三大交易所，稳定好用！
币安全球第一大交易所！安全！
作者：Kevin Davis，Kava技術開發主管
北京時間3月4日晚，Kava 5主網成功上線，但在啟動幾分鐘後，Kava核心開發團隊在HARD Protocol發現瞭一個bug，於是決定回滾。在這篇事後剖析中，Kava Labs技術開發主管Kevin Davis將公佈事件發生的原委和根本原因，並從技術角度闡述Kava作為一個項目和社區，為避免未來再度發生類似事件所正在采取的措施。
事件發生時間表
註：事件發生時間為北京時間2021年3月4日-3月5日。
21:00
Kava-4主鏈按計劃停止運行，開始向Kava-5主鏈遷移。
23:05
Kava-5主鏈啟動時，2/3的Staking驗證者上線。
23:40
在對新啟動的主鏈進行QA測試時，Kava工程師觀察到部分用戶HARD獎勵申領出現瞭意外的數值。
00:00
在尋找根本原因時，Kava工程師觀察到部分用戶的HARD獎勵申領對象出現異常。
00:05
在查看可用方案，確認所有用戶資金安全後，團隊決定報告安全委員會申請關閉主鏈。
00:20
安全委員會提出軟件升級方案，Kava-5主鏈停用。
1:00
確定Bug的根本原因。團隊決定回滾到Kava-4功能集，工程師開始正式制定計劃，以恢復主鏈運行。
2:30
公佈推薦的回滾計劃。團隊正式發佈帶有回滾指令的新版本Kava鏈。
14:30
Kava 6主網上線（搭載原Kava 4功能集但以新的鏈ID命名）
事件根源
Kava開發團隊已對HARD Protocol進行部分內部審計，這篇審計報告說明瞭本次事件是為瞭修復HARD Protocol清算的核算邏輯中的一個bug。
HARD審計鏈接：https://github.com/Kava-Labs/kava/pull/823
在代碼審核過程中，技術團隊曾指出應該使用安全差集來避免代幣數量為負數，進而導致cosmos-sdk sdk.Coins對象的panic。這個問題的修復是不正確的。
代碼鏈接：https://gist.githubusercontent.com/karzak/aeee0e02831d912398e0470aeb15d233/raw/c7a4f0c6ac32befdf6f6b736652358f82c90c041/DecrementBorrwedCoins.go
這種對代幣集結果進行差集處理導致瞭借出的代幣的不相交元素被完全從計算中剔除。然後，這種對借幣和供幣總量的計算錯誤就產生瞭下遊效應，即產生瞭HARD Protocol申領對象的獎勵計算不準確，這個問題在Kava 5推出後立即被發現。
Bug 獎金
所有在Kava 5上線期間曾申領HARD獎勵的地址，無論領取成功與否，都將分配到250個HARD作為Bug獎金。
技術分析
由於Kava擁有獨特的流動性激勵架構，所以我們值得分析一下“HARD申領”的定義以及代表含義。在HARD Protocol中，用戶會根據自己提供的流動性按比例獲得HARD代幣的申領資格。待申領獎勵表示用戶選擇最長鎖定期（1年）申領時有權獲得的HARD代幣餘額。
在任何時候，用戶都可以使用MsgClaimReward交易申領他們的HARD獎勵。申領時，用戶聲明HARD代幣的鎖倉時間，可以是1個月，也可以是1年，代幣會從HARD模塊賬戶轉到用戶的vesting鎖定賬戶。因為所有申領的HARD申領都是鎖定的，所以用戶不能立即將代幣從MsgClaimRewards中轉移出去。
以下為一些技術意見：
該bug並沒有導致通脹的HARD代幣被鑄造或可能被鑄造。用戶如果在HARD模塊賬戶餘額上出現瞭異常的申領，但由於HARD模塊賬戶餘額是鎖定的，所以沒有任何錯誤的申領獎勵被轉移出去。
用戶如成功申領瞭異常HARD代幣，也無法消耗。從設計上看，獎勵鎖倉機制可以防止獎勵計算出現bug時用戶立刻提現獎勵的情況。
Kava安全委員會的職能如期運行。安全委員會的目標是為Kava提供一個“安全門”，用於處理非常嚴重、主動攻擊型、以及可能會威脅用戶資金及主鏈安全的bug。安全委員會幾乎隻有在升級過程或觀察到漏洞後才會啟用。最重要的是，雖然安全委員會提供瞭一種方法來暫停主鏈運行，但並不具備重新上線主鏈的功能。Kava主鏈的運行取決於驗證者，並與所有Kava治理參與者協調完成。Kava Labs以及更強大的Kava治理將在決策過程中始終保持透明，並隨時歡迎社區及用戶對完善平臺管理的意見和反饋。
改進方向
在審計過程中如果一個簡單的算術錯誤逃過瞭代碼審查，我們首先想到的是審計過程很倉促。鑒於這是我們第一次將外部團隊成員的審計過程（與交付給外部審計公司形成對比）納入我們的發佈周期，看來我們很可能在審計過程中對審計代碼修復的預估時間不足，今後我們將通過前期分配更多的時間來緩解這一問題，同時也將審計完成檢查納入到我們的審計排期過程中。在這種情況下，我認為我們過於嚴格地遵守我們的時間表，應該多花一周時間來處理審計檢查和PR。
第二點也是我們從以往開發過程中吸取的經驗是，保證代碼凍結期限非常關鍵，以及如果核心狀態機代碼因為任何原因而被“解凍”，那麼發佈排期的更新也至為重要。在這種情況下，我們有一個激勵性的測試網與審計同時進行。在審計和修復合並後，額外的激勵測試網大概率會發現這個錯誤，這也是我們將在未來的開發過程中加入的部分。
此外，這次發佈凸顯瞭事先溝通、精心規劃的發佈重啟程序的重要性。雖然在故障期間的溝通也是有效的，但如果有一個更好的預先規劃過程，就可以避免在規劃重啟的確切順序時產生的一些額外的故障時間。今後，我們將為每一次發佈制定一個“回滾”手冊並進行內部溝通，以便參與節點在發佈回滾的情況下有一個例行程序可循。
反思
構建去中心化的金融應用會帶來許多開發上的挑戰，我們將不斷地從錯誤中學習，不斷地發展最佳實踐，並研究行業領先應用的經驗，思考有無改進空間。Kava是一個不斷成長的團隊，也在根據產品及開發需求不斷發展新的技術運營力量。
雖然這次發佈最終沒有成功，但我們在產品開發和發佈過程上做瞭很多改進，我們將對此保持始終學習的態度，也非常感謝社區和驗證者們的理解和支持。失敗並不會讓我們退縮：我們將從錯誤中吸取教訓，並一如既往地繼續打造DeFi的未來。
作者：Kava Labs，來源：Kava中文社區