Flash Loan Attack

閃電貸攻擊是什麼，跟一般理解的「借錢炒作」有什麼不同？

閃電貸（flash loan）是一種只存在於區塊鏈上的特殊借貸形式，核心特徵是「原子性」——整筆借款、運用資金、還款這三個動作,必須在同一筆交易裡完成,如果交易結束前借款沒有被全額歸還,整筆交易會被鏈上機制自動撤銷,就像這筆借貸從未發生過一樣。這個設計讓借款人完全不需要提供任何抵押品,因為程式碼本身就保證了「還不出來就等於沒借過」,這也是 Aave、dYdX 等協議推出這項服務時原本設想的正當用途:套利、清算、資產置換,讓沒有大筆本金的使用者,也能在同一筆交易裡完成需要臨時大量資金才能做到的操作。

閃電貸攻擊利用的正是這個機制,但目的不是套利,而是把這筆臨時取得的巨額資金,拿去衝擊某個協議原本就存在、但單靠正常規模資金無法觸發的弱點——例如把某個交易池的價格在極短時間內劇烈推高或壓低,讓仰賴這個價格的其他合約做出錯誤判斷。這跟「借錢炒作」的本質差異在於:炒作是拿真實資金承擔真實的市場風險,期望價格朝對自己有利的方向變動;閃電貸攻擊裡,攻擊者從頭到尾沒有承擔任何資金風險,因為資金必須在同一筆交易內全數歸還,攻擊者利用的是協議程式碼裡的邏輯漏洞,而不是市場本身的不確定性。

為什麼「閃電貸不是漏洞本身，只是放大器」這句話很重要，它想釐清什麼常見的誤解？

這句話想釐清的誤解是:如果把注意力全部放在「有人借了一大筆錢」這個表面現象上,防禦的思路很容易走偏,誤以為只要限制或關閉閃電貸功能,就能解決問題。但實際上,閃電貸攻擊之所以能得逞,永遠是因為協議本身已經存在一個更深層的設計弱點——最常見的是仰賴單一資料來源（例如某個去中心化交易所某一瞬間的即時價格）作為合約邏輯判斷的依據,而這個即時價格在正常交易規模下很難被顯著操縱,一旦攻擊者能取得遠超正常規模的臨時資金,這個原本「不太可能被操縱」的假設就會瞬間失效。

這個區分之所以重要,在於它決定了正確的防禦方向:如果誤以為問題出在「借貸」這個環節,防禦重點會錯放在限制借貸規模或速度;但如果理解問題出在「協議相信了一個可以被瞬間扭曲的狀態變數」,防禦重點就會正確地放在強化價格來源的穩定性、增加多重驗證、或限制單一交易能造成的狀態改變幅度。多份針對真實攻擊案例的研究都指出,絕大多數閃電貸攻擊案例裡,閃電貸功能本身完全按照設計正常運作,真正被攻破的是協議自己的商業邏輯或預言機設計。

閃電貸攻擊實際上是怎麼發生的，主要有哪幾種攻擊手法？

典型攻擊流程分幾步:攻擊者先鎖定一個仰賴脆弱狀態變數的協議,向 Aave、dYdX 等提供閃電貸服務的協議借入一筆巨額資金（可能高達數千萬甚至數億美元,規模完全不受攻擊者自身資產限制）;接著在同一筆交易裡,利用這筆資金對目標協議發動操縱——最常見的是預言機操縱（Oracle Manipulation）:透過在某個流動性較淺的交易池裡進行大額交易,短暫地把某代幣的價格推向極端,如果目標協議直接讀取這個被操縱的即時價格作為抵押品估值或清算判斷的依據,就會做出錯誤的判斷（例如允許攻擊者用被高估的抵押品借出遠超實際價值的資產）;攻擊者拿到不當得利後,反手把價格推回原位、償還閃電貸,整個過程在單一區塊、幾秒鐘內完成。

除了預言機操縱,另外幾種常見手法包括:治理操縱（governance manipulation）——利用閃電貸取得的巨量代幣,在一筆交易裡臨時取得協議治理投票的多數席位,通過原本不會過關的惡意提案;帳目與捨入誤差利用（accounting and rounding exploitation）——2026 年一起真實案例裡,攻擊者利用某個協議池子帳目對極小數值捨入處理不當的瑕疵,先用閃電貸把池子推向一個帳目異常的狀態,再透過一連串精密設計的交換操作,從這個異常狀態裡萃取價值;流動性抽乾（liquidity draining）——利用閃電貸的資金規模優勢,一次性清空某個流動性不足的資金池,讓其他使用者的正常提領請求無法被滿足。

閃電貸攻擊對我這種一般使用者的資產有什麼影響，我該怎麼評估風險？

閃電貸攻擊鎖定的是協議本身的資金池或治理機制,不是個別使用者的錢包,這代表它跟重入攻擊一樣,是使用者無法透過自身操作習慣直接防範的一種風險——你的資產是否安全,完全取決於你存入資金的協議,在設計上有沒有正確處理價格來源、帳目邏輯、以及治理權限這幾個環節,而這是純粹的技術實作問題。這也是為什麼閃電貸攻擊經常跟重入攻擊被放在同一個統計類別「生態系層級攻擊」裡討論——兩者都不是使用者判斷力能介入的環節。

對一般使用者來說,能做的具體事情包括:優先選擇仰賴多重、去中心化預言機（例如 Chainlink 這類整合多方資料來源、並採用時間加權平均價格 TWAP 而非單一即時價格的機制）而非單一資料來源的協議、留意協議是否設有斷路器（在極端價格波動時暫停功能的機制）、以及理解「有審計」不保證能完全排除這類攻擊——正如本站另一篇文章討論過的,審計能證明程式碼邏輯本身寫得正確,但無法完全保證協議所仰賴的外部資料來源假設是可靠的,而這正好是絕大多數閃電貸攻擊真正的破口所在。分散資金、避免把大部位集中在單一依賴少數資料來源的協議,是使用者端能實質降低風險曝險的做法。