Token Burning Wrong = Pool Drained | AMM Reserve Crisis
三句話摘要
燒毀邏輯漏洞導致代幣操縱 AMM 價格並掏空流動性池的原理與防禦。 代幣的燒毀和轉賬邏輯必須只操作交易發起者的餘額，永遠不能直接接觸流動性池或調用其內部函數，否則攻擊者可通過人為縮小儲備來操縱價格並掏空資金。 AMM 的價格由儲備比例決定，sync 函數使池信任其真實餘額。這個設計在正常情況下是安全的，但前提是沒有人能隨意改變池內代幣數量。
重點整理
重點- 1
AMM 的價格由儲備比例決定，sync 函數使池信任其真實餘額。這個設計在正常情況下是安全的，但前提是沒有人能隨意改變池內代幣數量。
- 2
代幣的燒毀邏輯漏洞在於一行代碼的方向錯誤：應該從賣家（msg.sender）扣除，但實際從流動性池扣除。這讓攻擊者能無償地減少池中的代幣供應，進而操縱價格。
- 3
價格操縱的機制是物理的而非抽象的：當池中代幣數量劇減，比例失衡，池會過度補償用來維持常數乘積，導致虛假定價。攻擊者因此能用小額輸入換取超額輸出。
- 4
防禦的核心原則是：燒毀和轉賬邏輯只能涉及交易的實際參與方（發送者和接收者），永遠不能接觸第三方如流動性池，也不能調用其 sync 函數。
實用技巧與重點
乾貨- 具體攻擊案例數據：
- 初始池狀態：100 WBNB : 1,000,000 ADC
- 攻擊者燒毀 990,000 ADC（來自池本身）
- sync 後 ADC 儲備從 1,000,000 降至 10,000
- ADC 價格被人為提升約 100 倍
- 攻擊者輸入 10,000 ADC，獲得 50 WBNB（正常應得 ~1 WBNB）
- 實際事件：從 PancakeSwap 池中掏空約 220 WBNB
- 技術實現：
- 漏洞位置：代幣合約的 burn 函數
- 錯誤邏輯：`burn(pool, amount)` 而非 `burn(sender, amount)`
- 觸發機制：調用 sync 更新儲備記錄
- 測試網絡：Sepolia（已驗證部署）
- 修複方案：
- burn 函數只操作 `msg.sender` 的餘額
- 永不調用流動性池的任何內部函數
- 燒毀的前置條件：用戶實際持有足夠代幣
結論
結論“代幣的燒毀和轉賬邏輯必須只操作交易發起者的餘額，永遠不能直接接觸流動性池或調用其內部函數，否則攻擊者可通過人為縮小儲備來操縱價格並掏空資金。”
完整解析
詳細在自動做市商（AMM）的設計中，價格由兩種代幣儲備的比例決定，就像一個天秤的兩端各放著不同重量的硬幣堆。池內有一個 sync 函數負責更新內部記錄的儲備量，使其與實際餘額匹配。這個設計通常是安全的，因為假設沒有人能隨意改變池內代幣數量。
但在這個案例中，有問題的代幣合約包含一個費用轉賬機制，進行轉賬時會自動燒毀一部分代幣。問題在於燒毀邏輯：開發者本應從賣家的賬戶中扣除代幣，卻錯誤地寫成從流動性池本身扣除。這一行代碼的方向錯誤讓攻擊者找到了操縱價格的入口。
攻擊流程極其簡單。攻擊者呼叫燒毀函數，從池中摧毀大量代幣（比如 990 萬中的 99 萬個），然後立即調用 sync。由於池內的代幣數量確實減少了，sync 信任這個新的真實狀態並更新記錄。結果是代幣的儲備從 100 萬崩潰到 1 萬，使其相對於另一種代幣顯得極其稀缺。根據 AMM 的常數乘積公式，代幣價格會虛假上升約 100 倍。此時攻擊者只需投入少量代幣，就能換取遠超公平價值的另一種資產，完整掏空池中的流動性。在實際事件中，攻擊者從一個 PancakeSwap 池中成功提取了約 220 個 WBNB。
防禦思路非常清晰：燒毀邏輯必須嚴格限制在交易的實際參與方。當修改後的合約執行燒毀時，它從發送者（攻擊者）自己的餘額中扣除，而不是從池中。由於攻擊者持有的代幣遠少於需要燒毀的數量，操作會直接回滾，池的儲備保持完整。因此任何後續的交換都會按公平價格執行，攻擊無法進行。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
