Pag-uulit ng Itim na Sisne: Limang Taon ng Pag-uulit ng Kahinaan ng Oracle

Isang $60 milyong market sell-off ang nagdulot ng pagkawala ng $19.3 bilyong market value.

May-akda: YQ

Isinalin at inayos: Saoirse, Foresight News

(Ang orihinal na nilalaman ay may ilang pagbabago at pinaikli)

Noong Oktubre 10 hanggang 11, 2025, isang $60 milyong market sell-off ang nagdulot ng pagkawala ng $19.3 bilyong market value. Hindi ito nagmula sa market crash, at hindi rin dahil sa sunod-sunod na margin call na dulot ng lehitimong pagkalugi ng mga posisyon, kundi dahil sa pagkabigo ng oracle.

Hindi ito bago. Mula pa noong Pebrero 2020, ang parehong pattern ng pag-atake ay matagumpay nang nagamit, na nagdulot ng daan-daang milyong dolyar na pinsala sa industriya sa dose-dosenang insidente. Ang pag-atake noong Oktubre 2025 ay 160 beses na mas malaki kaysa sa pinakamalaking oracle attack noon — hindi dahil mas kumplikado ang teknolohiya, kundi dahil ang mga pangunahing sistema ay pinalawak nang hindi tinatanggal ang parehong pundamental na kahinaan.

Limang taon ng mapait na aral, ngunit hindi pinansin. Tatalakayin ng pagsusuring ito ang mga dahilan nito.

2020-2022: Ang “Fixed Script” ng Oracle Attacks

Bago suriin ang insidente noong Oktubre 2025, dapat linawin: may mga naunang kaso na ng ganitong pangyayari.

Pebrero 2020: bZx Incident (nawalang $350,000 + $630,000)

Gumamit ng single-source oracle, ginamit ng attacker ang flash loan upang manipulahin ang presyo ng WBTC sa Uniswap, nailipat ang 14.6% ng kabuuang supply ng token na ito, at na-manipula ang price feed data na lubos na inaasahan ng bZx platform.

Oktubre 2020: Harvest Finance Incident ($24 milyon na ninakaw, nagdulot ng $570 milyong run)

Sa loob lamang ng 7 minuto, ginamit ng attacker ang $50 milyong flash loan upang manipulahin ang presyo ng stablecoin sa Curve, hindi lang nagdulot ng pagnanakaw ng pondo, kundi nagdulot din ng pagbagsak ng imprastraktura at pag-alis ng liquidity, na ang epekto ay mas malaki pa sa inisyal na halaga ng ninakaw.

Nobyembre 2020: Compound Incident ($89 milyon na asset na na-liquidate)

Ang DAI stablecoin ay tumaas hanggang $1.30 sa Coinbase Pro, habang sa ibang platform ay hindi ito nangyari. Dahil ang oracle ng Compound ay naka-base sa Coinbase, ang mga user ay na-liquidate dahil sa abnormal na presyo sa loob lamang ng isang oras. Noon, $100,000 lang ang kailangan upang manipulahin ang order book na may $300,000 na depth.

Oktubre 2022: Mango Markets Incident (nawalang $117 milyon)

Gamit ang $5 milyong panimulang pondo, tinaas ng attacker ang presyo ng MNGO token ng 2394% sa maraming platform, pagkatapos ay umutang ng $117 milyon gamit ang overvalued collateral, at ginamit ang ninakaw na governance token upang bumoto para sa sarili, nakuha ang $47 milyong “bug bounty.” Ito ang unang pagkakataon na ang CFTC ng US ay nagsagawa ng enforcement action laban sa oracle manipulation.

Lahat ng pag-atake ay sumusunod sa parehong proseso:

1. Tukuyin ang pagdepende ng oracle sa “manipulable data source”;
2. Kalkulahin: gastos sa manipulasyon < extractable value;
3. Isagawa ang manipulasyon;
4. Kumita at umalis.

Noong 2020-2022, 41 na oracle manipulation attacks ang nagdulot ng kabuuang $403.2 milyon na pagnanakaw. Ngunit ang tugon ng industriya ay kalat-kalat, mabagal, at hindi sapat — karamihan sa mga platform ay gumagamit pa rin ng spot price-based at kulang sa redundancy na mga oracle.

Pagkatapos, dumating ang sakuna noong Oktubre 2025.

“10.11” Vulnerability Analysis

Noong Oktubre 10, 2025, 5:43 ng umaga, isang $60 milyong USDe concentrated sell-off ang nag-trigger ng fatal chain reaction:

$60 milyong spot sell-off → ibinaba ng oracle ang valuation ng collateral (wBETH, BNSOL, USDe) → malawakang forced liquidation → infrastructure overload → liquidity vacuum → $19.3 bilyong market value nawala

Hindi ito kabiguan ng isang platform lamang, kundi ibinunyag ang matagal nang kahinaan ng buong industriya — kahit limang taon nang nagbabayad ng mahal na aral, hindi pa rin ito naayos:

1. Sobrang pagdepende sa spot price

Kahit bawat malaking pag-atake mula 2020 ay gumamit ng “manipulable spot price” na kahinaan, karamihan sa mga platform ay gumagamit pa rin ng spot-based oracle design. Alam ng industriya ang panganib ng spot price manipulation, at alam din na ang “time-weighted average price (TWAP)” at “multi-source oracle” ay mas ligtas, ngunit hindi pa rin ito ganap na naipatupad.

Ang ugat ng problema: “bilis at sensitivity” ay itinuturing na advantage bago ito maging kahinaan. Ang real-time price update ay mukhang mas eksakto — hanggang may magmanipula nito.

2. Centralization risk

Ang dominanteng trading platform ay nagdudulot ng “single point of failure”: bZx ay naka-depende sa Uniswap, Compound sa Coinbase, at ang mga platform noong Enero at Oktubre 2025 ay naka-depende sa sarili nilang order book — iisa lang ang problema, nag-iiba lang ang platform.

Kapag ang isang exchange ay may dominanteng trading volume, tila makatuwiran na gamitin ito bilang pangunahing data source ng oracle. Ngunit ang centralization risk sa price feed ay katulad ng anumang system: mukhang normal ang lahat bago ito ma-exploit.

3. Infrastructure assumption bias

Ang mga system na idinisenyo para sa “normal market” ay babagsak sa ilalim ng stress. Pinatunayan na ito ng Harvest Finance noong 2020, ngunit ipinakita ng insidente noong Oktubre 2025 na ang industriya ay “nagdidisenyo pa rin ng system para sa normal na kalagayan at umaasa na hindi mangyayari ang stress event.”

Ang “pag-asa” ay hindi estratehiya.

4. Transparency paradox

Ang paglalathala ng technical improvement plan ay nagbubukas ng attack window. Ang 8-araw na pagitan mula anunsyo hanggang implementasyon ng oracle algorithm update ay nagbibigay sa mga propesyonal na attacker ng malinaw na roadmap at timetable — alam nila eksakto kung kailan at paano aatakehin ang kahinaan.

Ito ang “lumang problema sa bagong failure mode”: dati, ginagamit ng attacker ang “existing vulnerability,” ngunit noong Oktubre 2025, ginamit nila ang “transition period ng oracle algorithm switch” — ang kahinaang ito ay lumitaw lang dahil napaaga ang pag-anunsyo ng improvement plan.

Mga Solusyon

Agad na Pagpapabuti

1. Hybrid oracle design

Pagsamahin ang maraming price sources at magdagdag ng epektibong sanity check:

• Centralized exchange (CEX) prices (cross-platform volume weighted, 40%);
• Decentralized exchange (DEX) prices (piliin lang ang high-liquidity pools, 30%);
• On-chain proof of reserve (20%);
• Conversion ratio ng wrapped assets (10%).

Ang susi ay “data source independence”: kung kayang manipulahin ang lahat ng sources nang mura, ang “multi-source” ay katulad lang ng “single-source.”

2. Dynamic weight adjustment

I-adjust ang oracle sensitivity ayon sa market conditions:

• Normal volatility: standard weights;
• High volatility: palawigin ang TWAP window, bawasan ang epekto ng spot price;
• Extreme volatility: i-trigger ang circuit breaker, simulan ang sanity check.

Pinatunayan na ng Compound incident noong 2020: minsan, ang “tamang presyo” ng isang exchange ay mali para sa buong market. Dapat kayang kilalanin ng oracle ang ganitong bias.

3. Circuit breaker mechanism

I-pause ang liquidation sa matinding price volatility — hindi para pigilan ang “reasonable deleveraging,” kundi para ihiwalay ang “manipulation” sa “tunay na market condition”:

• Kung ang presyo sa maraming platform ay nagkakatulad sa loob ng ilang minuto: malamang tunay na market volatility;
• Kung abnormal lang sa isang platform: malamang manipulasyon;
• Kung overloaded ang infrastructure: i-pause ang liquidation hanggang bumalik sa normal ang kapasidad.

Ang pangunahing layunin ay hindi “ipagbawal lahat ng liquidation,” kundi “maiwasan ang chain liquidation na dulot ng price manipulation.”

4. Infrastructure scaling

Idisenyo ang system na parang “100x ng normal capacity” — dahil ang chain reaction ay nagdudulot ng exponential load:

• Gumawa ng independent infrastructure para sa price feed;
• Mag-deploy ng independent liquidation engine;
• Mag-set ng request rate limit sa bawat address;
• Magpatupad ng “graceful degradation” protocol (unahin ang core function kapag overloaded).

Kung hindi kayang tiisin ng system ang load ng chain reaction, lalo lang lalala ang sakuna. Ito ay design necessity, hindi lang optimization.

Pangmatagalang Solusyon

1. Decentralized oracle network

Gamitin ang mga mature na oracle solution (tulad ng Chainlink, Pyth, UMA), na may built-in na anti-manipulation sa pamamagitan ng cross-data source aggregation. Hindi ito perpekto, pero mas mainam kaysa sa “spot-dependent oracle na inaatake kada 18 buwan.”

Pagkatapos gumamit ng Chainlink ang bZx matapos ang 2020 attack, hindi na ito muling na-oracle manipulate — hindi ito coincidence.

2. Proof of reserve integration

Para sa wrapped assets at stablecoins, dapat on-chain na mapatunayan ang halaga ng collateral. Halimbawa, ang presyo ng USDe ay dapat base sa “verifiable reserve,” hindi sa “order book dynamics.” May teknolohiya na para dito, ang kulang ay implementasyon.

3. Gradual liquidation

Gamitin ang phased liquidation para maiwasan ang paglala ng chain reaction:

• Unang threshold: magbigay ng warning, bigyan ng oras ang user para magdagdag ng collateral;
• Pangalawang threshold: partial liquidation (25%);
• Pangatlong threshold: mas malaking liquidation (50%);
• Final threshold: full liquidation.

Nagbibigay ito ng oras sa user at binabawasan ang impact ng “malawakang sabayang liquidation” sa system.

4. Real-time audit monitoring

Real-time na subaybayan ang oracle manipulation:

• Cross-platform price deviation;
• Abnormal trading volume sa low-liquidity pairs;
• Mabilis na paglaki ng position size bago ang oracle update;
• Pattern matching sa kilalang attack signatures.

Dapat sana ay may warning signal ang attack noong Oktubre 2025: 5:43 ng umaga, $60 milyong USDe ang naibenta — ang ganitong abnormal na transaksyon ay dapat mag-trigger ng alert. Kung hindi ito nakita ng monitoring system, may malubhang kakulangan ito.

Konklusyon: $19 bilyong babala

Ang chain liquidation noong Oktubre 10-11, 2025, ay hindi dulot ng “sobrang leverage” o “market panic,” kundi “malawakang pagkabigo ng oracle design.” Ang $60 milyong market operation ay naging $19.3 bilyong pagkalugi dahil hindi kayang ihiwalay ng price feed system ang “manipulation” sa “lehitimong price discovery.”

Ngunit hindi ito bagong problema — ang sumira sa bZx noong Pebrero 2020, Harvest noong Oktubre 2020, Compound noong Nobyembre 2020, at Mango Markets noong Oktubre 2022 ay iisang klase ng kahinaan.

Sa loob ng limang taon, limang beses nang natutunan ng industriya ang parehong aral, ngunit palaki nang palaki ang halaga ng pagkakamali:

• 2020: Ilang protocol lang ang natuto at nag-ayos;
• 2022: Pumasok na ang regulators, nagsimula ng enforcement;
• 2025: Buong market ang nagbayad ng $19.3 bilyong “tuition.”

Ngayon, ang tanging tanong: matututo na ba tayo sa wakas?

Lahat ng platform na humahawak ng leveraged positions ay dapat harapin ang mga tanong na ito:

• Kaya bang labanan ng oracle natin ang mga attack vector na nakita na noong 2020-2022?
• Kaya bang tiisin ng infrastructure natin ang chain liquidation na nangyari na?
• Nakamit ba natin ang tamang balanse ng “sensitivity” at “stability”?
• Ulit-ulit ba nating ginagawa ang mga pagkakamaling nagdulot ng daan-daang milyong dolyar na pagkalugi sa industriya?

Pinatunayan na ng limang taon ng kasaysayan: ang oracle manipulation ay hindi “hypothetical risk” o “edge case,” kundi isang “documented, repeatable, high-profit” attack strategy na lumalaki kasabay ng market.

Ipinakita ng insidente noong Oktubre 2025 na kapag binalewala ang mga aral na ito sa institutional scale, sakuna ang resulta. Ang pag-atakeng ito ay hindi komplikado o bago — iisang pamamaraan lang, sa “kilalang vulnerability window,” pero sa mas malaking system.

Ang oracle ang pundasyon ng buong sistema. Kapag nabasag ang pundasyon, lahat ay babagsak. Mula pa noong Pebrero 2020, alam na natin ito at gumastos na tayo ng bilyon-bilyong dolyar para paulit-ulit na patunayan ito. Ngayon, ang tanging tanong ay kung sapat na ba ang mahal na insidente noong Oktubre 2025 para gawing aksyon ang mga natutunang aral.

Sa ngayon na lubos na konektado ang market, ang oracle design ay hindi lang “data feed” — ito ay tungkol sa stability ng buong sistema. Kapag nagkamali ang disenyo, $60 milyon lang ang kailangan para sirain ang $19 bilyong halaga.

Kung patuloy tayong nagkakamali, hindi dahil hindi tayo natututo sa kasaysayan, kundi dahil mas mahal lang ang bawat ulit ng pagkakamali.

Ang pagsusuring ito ay batay sa public market data, platform statements, at limang taon ng pag-aaral ng mga kaso ng oracle manipulation.