回天乏術，一開始就注定失敗的YAM投票拯救行動
36小時內，眼看他起高樓，幾分鐘內，眼看他樓塌了。
北京時間08月13日上午03時整，備受矚目的DeFi 項目YAM Finance 宣布啟動流動性挖礦，僅僅一天時間鎖倉資產價值就超過了6億美元，其鎖定資產增量和增速都達到了近乎癲狂狀態。且照此發展，一些早期給池子注入流動性的羊毛黨年利率甚至可逼近200倍，其瘋狂程度可見一斑。
二級標題
二級標題
該如何拯救我們的YAM 小紅薯呢？
在發現漏洞後，YAM 團隊發起了“拯救行動”，稱他們需要16萬委託投票才能提交治理提案，於是向社區發起呼籲投票。很快，這場轟轟烈烈的社區投票行動就完成了。
然而，就在大家以為只是虛驚一場的時候，北京時間08月13日下午16時01分，YAM 創始人Brock Elmore 卻發推特稱，對不起大家，我失敗了。這究竟是怎麼回事呢？
PeckShield 安全人員介入分析後，迅速定位到問題的本質在於：彈性供應機制（rebase）存在一個代碼公式的錯誤，致使第二次rebase 觸發時系統會自動增發10 ^ 18個新代幣，如果行情一直保持高位的話，那麼以後的每次rebase 觸發時都會進行指數級的增發，這將使小紅薯YAM 的數量變成一個可怕的天文級數字。這意味著，無論後期社區怎樣委託投票，都無法獲得足夠的投票量對系統進行控制，整個系統將陷入失控無主狀態。
原因有二：
原因有二：
1）時間來不及： YAM 官方或許忽略了一點，在其提案投票拯救行動準備工作完成後，也需要至少12.5個小時才能被執行生效，而按照現在的時間節奏，當其執行生效時，第二次rebase 早已觸發。
2）二級標題
二級標題
技術概要
首先介紹下YAM 智能合約的彈性供應機制（rebase）：
1）系統會根據市場價格浮動來動態調整代幣的供應量，當市價上漲時則按比例增發代幣，以降低單位代幣的價值，直至降至1美元。
2）每天分別執行兩次rebase，每次rebase 會改變代幣供應量，根據市場現價增發或銷毀一定量的代幣。
再說一個實施提案的關鍵因素：持有者進行委託投票，投票數超過總量的1%，則提案才可以進行執行排列，且按合約約定執行排列時長需要等待12.5小時，而提案執行時，則投票需要超過總量的4%。如此新治理合約才能執行生效，項目才能繼續正常運轉。
有了以上幾個技術要點的鋪墊，我們再來看一下，YAM 官方的跟進時間表，就能明白此次拯救行動為什麼注定會失敗。
如下圖時間線所示：
②是第一次rebase 觸發的時間，由於合約的bug 導致totalsupply 資產發生異常暴漲，官方發現BUG 存在並進行了披露。
③是官方宣布提議部署新治理合約的時間，在此之後社區開始啟動投票。
④是投票目標初步完成，新治理合約進入執行排列的時間，自此等待執行12.5小時合約正式執行。
⑤是第二次rebase 的觸發時間。
⑦是其新治理合約投票通過後正式執行的時間。
⑥ 在第二次rebase 觸發後的第31分鐘時，或許是項目方發現了已經無力回天了，提案取消成功，項目方正式宣布YAM 失敗。
①之後的綠色區域是投票和提案拯救行動可以成功的“黃金急救期”，需要整個拯救行動準備工作在第一次rebase 觸發之前半小時內完成。 （即藍色虛線應提前到綠色區域內）。
這意味著，YAM 官方應在第一次rebase（北京時間08月13日凌晨04:08)之前就應該發現這個漏洞，並且留有足夠的時間完成新治理合約部署和投票。
可是事與願違，官方發現漏洞並披露呼籲投票的時間還是太晚了，錯過了唯一能夠成功的黃金急救期。而更糟糕的是，按照官方的時間節奏，當新治理合約到了⑦執行的時間後，投票數要超過總量的4%才行，而此刻的總量已經擴大了10^18*10^18 ，此前累積的投票數已然杯水車薪，根本無濟於事。
所以，這次拯救行動一開始就注定了會失敗。
下面我們會對此次事件做下詳細分析：（項目方github地址https://github.com/yam-finance/yam-protocol）
圖片描述
圖片描述
圖1. 第一次rebase 資產變化
如上面鏈上信息（https://oko.palkeo.com/）所示，當第一次rebase 之後，totalSupply從3,500,000* 10^18暴漲到一個極大值。
圖片描述
圖片描述
圖2. YAMToken::rebase() 得到一個異常大的totalSupply值
圖片描述https://oko.palkeo.com/圖片描述
圖片描述
圖片描述
二級標題
二級標題
圖片描述
圖片描述
圖5. GovernorAlpha::queue() 函數設置eta（生效時間）
圖片描述
圖片描述
圖片描述
圖片描述
圖片描述
圖片描述
總結
圖片描述
圖片描述
總結
總結
此次YAM 漏洞事件，最終造成治理合約中75萬枚yCRV 被永久鎖定，而且短時間內的急速暴跌和無力回天的局面，不知道有多少人被埋在了價格高點，其瘋狂程度成瞭如今DeFi 流動性挖礦的最真實寫照，其殘酷魔幻程度何嘗又不是？倘若項目方在部署合約之前但凡測試過一次rebase 流程，必定能捕捉到漏洞的存在。足以見得，DeFi 項目做安全審計的重要性。
綜上分析，PeckShield（派盾） 想藉此勸誡諸君，在區塊鏈世界裡，務必要對每一行合約代碼保持敬畏，因為任何細微的疏漏都可能造成無法挽回的局面。畢竟，代碼是人寫的，漏洞也很難被徹底避免，因此需要項目方在合約部署上線前就做好充分的測試和第三方安全審計工作，這會幫助其更早發現並排查合約代碼潛在的安全漏洞，不至於等到，漏洞發生後，亡羊補牢，為時已晚
