Common DeFi Invariants Every Protocol Must Respect

演講者 Anton 開門見山指出，無論面對多複雜的新協議，審計員或開發者最核心的工作是識別「不變量（Invariant）」——亦即系統在任何操作前後都應成立的條件。他坦言，開發者在撰寫業務邏輯時往往只思考用戶故事與產品需求，鮮少主動定義不變量；但正因如此，不變量的缺失才成為漏洞的溫床。即便不採用形式化驗證，不變量也是模糊測試的理想輸入素材。

Anton 首先強調「償債能力（Solvency）」是最基礎的不變量。對於任何鎖定用戶資金的協議——尤其是有 LP（流動性提供者）的系統——核心問題是：合約能否在任何時間點如數償還所有存款？他建議問三個問題：一、當用戶數降為零時，系統能否正常停止？現實中常見漏洞是「最後一個用戶的資產被協議永久鎖死」。二、系統是否在每次操作中都對自身獲利？此類設計若未約束，會系統性地侵蝕留在協議內用戶的份額。三、資料完整性——合約中是否存在應同步修改卻未加以約束的關聯變數？

接著他介紹幾類更具操作性的不變量。回程不變量（Roundtrip Invariant）適用於 ERC-4626 等 Vault 協議：先 deposit 再 redeem，應回到完全相同的狀態；若舍入方向不正確，每次操作都會累積微小誤差，長期下來可被攻擊者套利。對稱性不變量（Symmetry Invariant）則指出，以「存入量」或「取出量」兩種方式指定的操作在數學上應等價，但某些協議（如演講中提到的 Bouncer 協議）在不同指定方式下走的路由不同，導致結果出現偏差。

最後他介紹組合不變量（Compositional Invariant），這也是他認為最優雅的一類。核心思想是：一個大操作拆成多個小操作後，終態應與直接執行大操作相同。更進一步，不同的路徑若在邏輯上等價，其終態也應一致——例如，「用 Token A 換 Token B」與「先用 Token A 加入流動性、再移除並取出 Token B」，對資金池的影響理論上應相同。若不一致，代表協議存在套利漏洞或狀態損壞。他特別提醒，X 與 Y 的大小可以任意組合，因此這類不變量能有效覆蓋邊界條件。