Share Price Manipulation Attack

份額價格操縱攻擊是什麼，跟前面介紹過的預言機操縱攻擊有什麼不同？

前面文章介紹過的預言機操縱攻擊，鎖定的是外部價格來源——攻擊者操縱某個資產在市場上的即時報價,讓依賴這個報價的協議做出錯誤判斷。份額價格操縱攻擊鎖定的則是完全不同的層面：多數金庫類產品（例如採用 ERC-4626 這套標準化介面的代幣化金庫）,內部會維護一套會計邏輯,持續計算「金庫目前總共管理多少底層資產」跟「目前總共發行了多少份額」,再用這兩個數字的比例,算出「一份額目前值多少錢」。份額價格操縱攻擊,就是直接針對這套內部會計邏輯本身動手腳,不需要碰觸任何外部價格來源。

跟預言機操縱攻擊最大的不同在於「攻擊對象是誰的帳本」：預言機操縱攻擊入侵的是協議外部依賴的市場資料;份額價格操縱攻擊入侵的則是協議自己內部的資產記帳邏輯,某種程度上更接近直接竄改協議「自己家裡的帳本」,而不是欺騙協議去相信一個錯誤的外部資訊來源。這兩種攻擊在防禦策略上也完全不同——前面文章介紹過的、透過多節點聚合去中心化的預言機網路,能有效防禦第一種攻擊,但對第二種攻擊完全沒有幫助,因為問題根本不在外部資料來源。

份額價格操縱攻擊為什麼會出現，這個漏洞的技術根源是什麼？

多數金庫合約計算份額價值的公式,本質上是一個比例分配的數學運算——用金庫目前實際持有的總資產,除以目前流通的總份額數量,得出每份額對應多少資產。這套邏輯在正常情境下運作良好,但存在一個關鍵假設：金庫的總資產數字,必須完全準確反映實際狀況。這個假設之所以可能被打破,是因為部分金庫設計,沒有嚴格區分「透過正常存款流程進入金庫的資產」跟「透過其他管道（例如直接轉帳）進入金庫的資產」,兩者都會被計入總資產,但只有前者會同步增加對應的份額數量。

攻擊者利用的正是這個落差：如果金庫剛好處於總份額規模很小（例如金庫剛啟用、還沒有真實用戶存款)的狀態,攻擊者可以先存入極小額資金取得少量份額,再直接把一大筆資產轉帳進金庫（不透過正常存款流程,不換取任何份額),這筆單方面挹注的資產,會被算進總資產,卻沒有對應增加份額數量,瞬間把「每份額對應的資產價值」推高到一個極端數字。接下來,如果有其他不知情的用戶依照正常流程存入資金,計算下來很可能只能分配到零份額（因為除法運算後無條件捨去),等於這筆存款憑空消失,全數落入攻擊者手上的份額裡。這套技術根源,某種程度上是一個「除法運算在極端比例下產生的邊界情況漏洞」,不是程式碼邏輯明顯寫錯,而是設計時沒有考慮到這種極端情境。

份額價格操縱攻擊具體怎麼運作，一次完整的攻擊流程是什麼樣子？

典型的份額價格操縱攻擊，最經典的變體（常被稱為「首存款人攻擊」）包含幾個環節：

1. 鎖定攻擊時機：攻擊者持續監控目標金庫,鎖定金庫總份額規模極小（最理想的情境是金庫剛部署、還沒有任何真實用戶存款)的時間點,這個時機是整起攻擊能成立的必要前提
2. 建立初始部位：攻擊者存入一筆極小額資金（技術文件裡常見的示範金額甚至小到 1 個最小計價單位),取得對應的、同樣是最小單位的份額,這一步的目的單純是讓攻擊者自己持有金庫裡唯一存在的份額
3. 直接捐贈拉高份額價值：攻擊者接著把一大筆資產,不透過金庫的正常存款函式,而是直接轉帳進金庫合約位址,這筆資產會被計入金庫的總資產,卻不會鑄造任何新份額,瞬間讓「每份額對應的資產價值」暴增
4. 等待受害者存款：一旦有其他用戶依照正常流程,對這個金庫執行存款操作,金庫依照被扭曲的比例計算這筆新存款該分配多少份額,如果新存款金額不夠大,計算結果可能直接捨去為零份額——受害者的資產進了金庫,卻沒有拿到任何對應的份額憑證
5. 贖回套利：攻擊者手上持有的份額（雖然數量極少,但因為總資產被人為推高,每份額對應的價值極高),此時贖回,能拿回原本自己捐贈進去的資產,加上受害者存進來、卻沒有分配到份額的那筆資產,完成套利

除了這種「首存款人」變體,前面文章介紹過的、Summer.fi Lazy Summer Protocol 遭遇的攻擊,則是另一種變體——鎖定的不是空金庫,而是運作中金庫的份額定價會計邏輯本身,搭配閃電貸的巨額資金,在單一交易裡完成操縱與套利,技術細節不完全相同,但核心原理都是攻擊金庫計算份額價值的內部邏輯。

份額價格操縱攻擊對一般用戶有什麼實際影響，該怎麼評估自己使用的金庫是否有防禦這類攻擊？

對一般用戶而言，這類攻擊最直接的風險是——你依照正常流程把資產存進一個金庫,卻可能因為金庫本身的內部會計漏洞,拿不到任何對應的份額憑證,你的存款某種程度上憑空消失,全數落入攻擊者手上。這個風險在「金庫剛啟用、規模還很小」的階段特別顯著,如果你考慮成為一個新金庫的早期存款人,值得特別留意這一層風險。

評估自己使用的金庫是否有針對這類攻擊做防禦時,幾個具體值得查證的面向：查證這個金庫是否採用業界公認的防禦機制,常見做法包括在金庫部署時,由開發團隊自己先存入一筆「死份額」（永久鎖定、不會被贖回的初始份額),確保後續即使有人想利用低總份額規模發動攻擊,也會因為這批死份額的存在,讓攻擊在經濟上變得不划算;查證金庫合約是否對「直接轉帳進金庫、不透過正常存款函式」這種資產,做了額外的偵測或限制,不讓這類單方面挹注的資產,直接被計入用來計算份額價值的總資產數字裡;以及,如果你考慮成為某個金庫的早期存款人,查證這個金庫在你存入之前,是不是已經有其他真實用戶存款、累積了一定的總份額規模,規模越大,首存款人攻擊這類針對空金庫或極小規模金庫的攻擊,可行性理論上就越低。