Storage Proofs Done Wrong: a Case Study

這個漏洞的根源在於一個跨 L1/L2 的效率設計模式。許多協議希望在便宜的 L2 上運行，但又需要保持 L1 上的核心帳本（如 oracle 參數、投票權重）作為可信來源。為了避免將 L1 上的每一個 storage slot 都逐一橋接，工程師採用了 Merkle Patricia Tree（MPT）的方式：只橋接一個 L1 的 state root，再讓 L2 合約透過 Merkle proof 驗證任意 L1 storage slot 的值。這個設計節省了 gas，也是 Ethereum 原生支援的驗證機制，理論上十分優雅。

然而，這個函式庫的 proof 驗證函式存在一個致命的隱患。函式的核心是一個 for 迴圈，逐節點（extension node、leaf node、branch node）走訪傳入的 proof path，並在每個分支內部以 return 或 revert 結束——要嘛成功回傳 storage 值（inclusion），要嘛回傳空 bytes（exclusion，表示該 slot 未初始化），要嘛因 proof 格式錯誤而 revert。開發者的隱含假設是：迴圈一定會在內部結束，不可能把所有節點跑完後自然退出。

這個假設是致命的。攻擊者只需要截斷一個完整有效的 inclusion proof——例如把原本 5 個節點的 proof 截成 3 個——for 迴圈就會在處理完最後一個節點後沒有觸發任何 return，讓控制流落到函式末尾。Solidity 對於宣告回傳 `bytes memory` 但沒有顯式 return 語句的情況，會隱性回傳空 bytes。而呼叫這個函式的合約，遵循函式的語義約定，將空 bytes 解讀為 exclusion proof——也就是「這個 storage slot 的值是零」。

後果直接且嚴重。如果被橋接的值是 oracle 價格參數，攻擊者可以讓協議認為任意資產的價格為零，藉此大規模操縱價格；如果被橋接的是治理投票權重，攻擊者可以將任何人的投票權清空為零，或讓自己的權重不受 L1 實際狀態約束，進而奪取 L2 的治理控制權。估計潛在損失達數百萬美元等級，且這個漏洞在生產環境中沉睡了數年。幸運的是，它最終被 Curve 的一名白帽開發者發現，並完整走過了 responsible disclosure → patch → 公開披露的正規流程。

演講者最後提出了一個值得深思的問題：這類漏洞無法被現有自動化工具捕捉。Fuzzing 難以自動產生「截斷有效 proof」這種語義上精心構造的惡意輸入；SMT solver 則受限於對 hash function、動態長度迴圈與 assembly 記憶體操作的建模困難。這個案例再次說明，對於高度複雜的密碼學原語與 EVM 底層語義交織的程式碼，人工審計目前仍是不可替代的最後防線。