การดำดิ่ง: ช่องโหว่ของ Oracle และการทดสอบ DeFi มูลค่าหลายพันล้านดอลลาร์

ผู้แต่งต้นฉบับ: YQ

คำแปลต้นฉบับ: TechFlow

เมื่อวันที่ 10-11 ตุลาคม 2568 การเทขายหุ้นมูลค่า 60 ล้านดอลลาร์สหรัฐ ทำลายมูลค่าหุ้นไป 19.3 พันล้านดอลลาร์สหรัฐ เหตุการณ์นี้ไม่ได้เกิดจากภาวะตลาดตกต่ำหรือการชำระบัญชีแบบต่อเนื่องของสถานะที่เสียหายอย่างแท้จริง แต่เกิดจากความล้มเหลวของออราเคิล

นี่ไม่ใช่เรื่องใหม่ โมเดลการโจมตีแบบเดียวกันนี้ถูกนำไปใช้ประโยชน์ได้สำเร็จหลายครั้งนับตั้งแต่เดือนกุมภาพันธ์ 2020 ส่งผลให้เกิดเหตุการณ์หลายสิบครั้งทั่วทั้งอุตสาหกรรม สร้างความสูญเสียรวมหลายร้อยล้านดอลลาร์ อย่างไรก็ตาม เหตุการณ์ในเดือนตุลาคม 2025 ได้ขยายขอบเขตการโจมตี Oracle ครั้งใหญ่ที่สุดครั้งก่อนถึง 160 เท่า ไม่ใช่เพราะความซับซ้อนทางเทคนิคที่เพิ่มขึ้น แต่เป็นเพราะการขยายตัวของระบบพื้นฐาน ในขณะที่ยังคงรักษาช่องโหว่พื้นฐานเดิมเอาไว้

ในช่วงห้าปีที่ผ่านมา เราต้องจ่ายราคาแพง แต่เราก็ยังไม่ได้เรียนรู้บทเรียน บทความนี้จะวิเคราะห์สาเหตุ

ปัญหาทาง Oracle: ความอ่อนไหวเทียบกับเสถียรภาพ

แพลตฟอร์มทุกแห่งต้องเผชิญกับความท้าทายพื้นฐานเมื่อใช้ประโยชน์จากเลเวอเรจ: จะกำหนดราคาหลักประกันอย่างแม่นยำได้อย่างไรในขณะที่ป้องกันการจัดการราคา?

• อ่อนไหวเกินไป → เสี่ยงต่อการถูกโจมตีจากการจัดการ
• มั่นคงเกินไป → ไม่สามารถสะท้อนการสูญเสียที่แท้จริงได้อย่างทันท่วงที

เหตุการณ์ในเดือนตุลาคม 2025 เลือก "Sensitivity" ออราเคิลติดตามราคาตลาดสปอตอย่างแม่นยำ และเมื่อมีการขายสินทรัพย์มูลค่า 60 ล้านดอลลาร์ ออราเคิลก็ปรับราคาหลักประกันลงแบบเรียลไทม์ ส่งผลให้เกิดการชำระบัญชีครั้งใหญ่ ระบบทำงานตามที่ออกแบบไว้ทุกประการ

อย่างไรก็ตามการออกแบบนี้กลับกลายเป็นหายนะ

แบบอย่างที่ถูกละเลยมานานถึงห้าปี

ก่อนที่จะวิเคราะห์เหตุการณ์ในเดือนตุลาคม พ.ศ. 2568 เราต้องเข้าใจก่อนว่า นี่ไม่ใช่ครั้งแรกที่เกิดเหตุการณ์นี้

ระยะเวลาย้อนหลัง (2563-2565)

กุมภาพันธ์ 2020: bZx (350,000 ดอลลาร์ + ขาดทุน 630,000 ดอลลาร์) ใช้ออราเคิลแบบแหล่งเดียว สินเชื่อแบบแฟลชควบคุมราคา WBTC บน Uniswap อุปทานทั้งหมด 14.6% ถูกย้ายเพื่อควบคุมราคาข้อมูลราคาที่ bZx อ้างอิง

ตุลาคม 2020: Harvest Finance (เงิน 24 ล้านดอลลาร์ถูกขโมยไป 570 ล้านดอลลาร์ถูกขโมยไป) ปั่นราคา stablecoin ของ Curve โดยใช้เงินกู้แบบแฟลช 50 ล้านดอลลาร์ในเวลาเพียงเจ็ดนาที เหตุการณ์นี้ทำให้โครงสร้างพื้นฐานล่มสลายและเกิดการถอนสภาพคล่องจำนวนมหาศาล ส่งผลให้เกิดความสูญเสียมากกว่ามูลค่าที่ขโมยมาในตอนแรกอย่างมาก

พฤศจิกายน 2020: Compound (มูลค่า 89 ล้านดอลลาร์จากการชำระบัญชี) พบว่า DAI บน Coinbase Pro พุ่งขึ้นอย่างรวดเร็วไปที่ 1.30 ดอลลาร์ ซึ่งเป็นปรากฏการณ์ที่ไม่เคยพบเห็นมาก่อนในตลาดแลกเปลี่ยนแห่งนี้ Oracle ของ Compound ซึ่งใช้ราคาของ Coinbase เป็นเกณฑ์มาตรฐาน ส่งผลให้ผู้ใช้ถูกชำระบัญชีเนื่องจากราคาที่ผิดปกติในช่วงสั้นๆ การควบคุมราคาต้องใช้เงิน 100,000 ดอลลาร์เพื่อใช้ประโยชน์จากสมุดคำสั่งซื้อขายที่มีความลึกถึง 300,000 ดอลลาร์

ตุลาคม 2565: Mango Markets (ขาดทุน 117 ล้านดอลลาร์สหรัฐฯ) ได้ใช้เงินทุนเริ่มต้น 5 ล้านดอลลาร์สหรัฐฯ ผลักดันให้ราคาโทเคน MNGO เพิ่มขึ้น 2,394% ในหลายแพลตฟอร์มการซื้อขาย ต่อมา Mango Markets ได้กู้ยืมเงิน 117 ล้านดอลลาร์สหรัฐฯ โดยใช้หลักทรัพย์ค้ำประกันจำนวนมาก และใช้โทเคนการกำกับดูแลที่ถูกขโมยมาลงคะแนนเสียงให้กับตนเอง ทำให้ได้รับเงินรางวัลจาก "bug bounty" 47 ล้านดอลลาร์สหรัฐฯ นี่ถือเป็นการบังคับใช้กฎหมายครั้งแรกของคณะกรรมการกำกับการซื้อขายสินค้าโภคภัณฑ์ล่วงหน้า (CFTC) ของสหรัฐอเมริกา เพื่อต่อต้านการปั่นราคาออราเคิล

ความเหมือนกัน

การโจมตีแต่ละครั้งใช้ตรรกะเดียวกัน:

1. ระบุแหล่งข้อมูลที่ถูกจัดการซึ่ง Oracle พึ่งพา
2. การคำนวณ: ต้นทุนการจัดการ < มูลค่าที่สกัดได้
3. การดำเนินการโจมตี
4. กำไร

2563-2565: การโจมตี Oracle Manipulation 41 ครั้ง ส่งผลให้สูญเสียเงิน 403.2 ล้านดอลลาร์

การตอบสนองของภาคอุตสาหกรรม: การตอบสนองมีการกระจายตัว ล่าช้า และไม่สมบูรณ์ แพลตฟอร์มส่วนใหญ่ยังคงใช้ออราเคิลแบบอิงจุดซึ่งมีการซ้ำซ้อนไม่เพียงพอ

แล้วเหตุการณ์ในเดือนตุลาคม พ.ศ.2568 ก็เกิดขึ้น

กายวิภาคของความล้มเหลวของ Oracle: ฉบับปี 2025

10 ตุลาคม 2568 05:43 น.: มีการขาย USDe มูลค่า 60 ล้านดอลลาร์เข้าสู่ตลาดสปอต

ในโอราเคิลที่ได้รับการออกแบบอย่างเหมาะสม: แหล่งข้อมูลอิสระหลายแหล่งจะช่วยดูดซับแรงกระแทก และผลกระทบจะน้อยที่สุด

ในคำทำนายนี้: ภัยพิบัติเกิดขึ้น

การเทขายหุ้นมูลค่า 60 ล้านเหรียญสหรัฐ → Oracles ลดราคาหลักประกัน (wBETH, BNSOL, USDe) → การชำระบัญชีจำนวนมากเกิดขึ้น → โครงสร้างพื้นฐานมีภาระเกิน → สภาพคล่องขาดหาย → สินทรัพย์มูลค่า 19.3 พันล้านเหรียญสหรัฐระเหยไป

เอฟเฟกต์การขยาย

• ตลาดมะม่วง (2022) : ถูกปั่นราคา 5 ล้านเหรียญ → ถอนเงิน 117 ล้านเหรียญ (23 เท่า)
• ตุลาคม 2568 : 60 ล้านเหรียญถูกจัดการ → 19.3 พันล้านเหรียญถูกทำลาย (322 เท่า)

ซึ่งไม่ใช่เกิดจากความซับซ้อนทางเทคโนโลยีที่เพิ่มมากขึ้น แต่เกิดจากช่องโหว่ต่างๆ ที่ขยายตัวไปสู่ระดับสถาบัน

ปัญหาการกระจายน้ำหนัก

ออราเคิลนี้อาศัยราคาสปอตจากตลาดหลักทรัพย์หลักๆ เป็นหลัก เมื่อตลาดหลักทรัพย์เดียวครองปริมาณการซื้อขาย:

• ปริมาณการซื้อขายที่สูง ดูเหมือนจะบ่งชี้ถึงการค้นพบราคาที่เชื่อถือได้ (ดูสมเหตุสมผล)
• การรวมศูนย์ เพิ่มความเสี่ยงในการแทรกแซง (จุดอ่อน)
• ราคาภายในเพียงราคาเดียว ก่อให้เกิดวัฏจักรที่ดำเนินต่อไปเอง (ทำให้ปัญหารุนแรงขึ้น)

ความคิดเห็นของนักวิเคราะห์รายหนึ่งเผยให้เห็นข้อบกพร่องในตรรกะนี้: “เนื่องจาก [การแลกเปลี่ยน] มีปริมาณการซื้อขาย usde/bnsol/wbeth มากที่สุด ตามการกระจายน้ำหนักของ Oracle จึงควรอ้างอิงถึงราคาจุด”

สัญชาตญาณนี้ ซึ่งก็คือการเชื่อมั่นในตลาดที่ใหญ่ที่สุด นำไปสู่การขาดทุนหลายพันล้านดอลลาร์ตลอดห้าปี ปริมาณการซื้อขายที่กระจุกตัวไม่ได้เป็นหลักฐานที่ยืนยันราคาที่แม่นยำ แต่เป็นสัญญาณบ่งชี้ถึงโอกาสในการปั่นราคา

หน้าต่างช่องโหว่ตามกำหนดเวลา

มีการประกาศอัปเดตเมธอด Oracle แปดวันก่อนการนำไปใช้งานจริง ซึ่งทำให้ผู้โจมตี:

• การอ้างอิงของ Oracle
• เวลาการเปลี่ยนแปลงที่คาดเดาได้
• แปดวันแห่งการเตรียมตัว

ในขณะที่การโจมตี Oracle ก่อนหน้านี้ใช้ประโยชน์จากช่องโหว่ที่มีอยู่ การโจมตีในเดือนตุลาคม พ.ศ. 2568 ได้ใช้ประโยชน์จากช่องโหว่ในระหว่างการเปลี่ยนเมธอด Oracle ซึ่งเป็นช่องโหว่ที่มีอยู่เพียงเพราะมีการประกาศการปรับปรุงล่วงหน้าเท่านั้น

การทดสอบการแยกไซต์

หลักฐานที่ชัดเจนที่สุดชี้ให้เห็นว่าเหตุการณ์นี้เกิดจากความล้มเหลวของ Oracle ไม่ใช่การสูญเสียทรัพย์สิน:

• การแลกเปลี่ยนหลัก : ราคา USDe อยู่ที่ 0.6567 ดอลลาร์ ราคา wBETH อยู่ที่ 430 ดอลลาร์
• แพลตฟอร์มการซื้อขายอื่น ๆ : ราคาเบี่ยงเบนน้อยกว่า 30 จุดพื้นฐาน
• สระสภาพคล่องบนเครือข่าย : ผลกระทบน้อยที่สุด

ตามที่ Ethena’s Guy กล่าวไว้ว่า “ในระหว่างงานนั้น มีหลักประกัน Stablecoin มูลค่ากว่า 9 พันล้านดอลลาร์ที่พร้อมสำหรับการไถ่ถอนทันที”

ราคาผันผวนอย่างรุนแรงในตลาดหลักทรัพย์ที่ Oracle ใช้เป็นแหล่งข้อมูล ในขณะที่ราคายังคงทรงตัวในที่อื่นๆ Oracle รายงานว่าราคาถูกปั่นราคา จนนำไปสู่การขายสินทรัพย์โดยอิงจากราคาที่ไม่มีอยู่ในตลาดอื่น

นี่เป็นรูปแบบเดียวกันอย่างแน่นอนกับเหตุการณ์ Compound ในปี 2020: การจัดการราคาในสถานที่ซื้อขายที่แยกตัวถูกบันทึกไว้โดยออราเคิล ส่งผลให้เกิดความเสียหายต่อระบบ

ผลกระทบระลอกคลื่นของโครงสร้างพื้นฐาน

นักวิเคราะห์ชี้ให้เห็นกลไกการขยายสัญญาณ:

การชำระบัญชีแบบต่อเนื่องทำให้เซิร์ฟเวอร์มีคำขอมากมายเกินกำลัง ผู้ดูแลตลาดไม่สามารถประมูลได้ทันเวลา ทำให้เกิดภาวะสุญญากาศทางสภาพคล่อง

นี่คือเวอร์ชันที่ขยายความของเหตุการณ์ Harvest Finance ในปี 2020 อย่างแท้จริง การโจมตีทำให้เกิดการชำระบัญชีเร็วกว่าที่โครงสร้างพื้นฐานจะประมวลผลได้ ผู้สร้างตลาดไม่สามารถตอบสนองได้ สภาพคล่องหายไป และปฏิกิริยาลูกโซ่ก็เสริมกำลังตัวเอง

หลังจากโครงสร้างพื้นฐานของ Harvest Finance ล่มสลายในเดือนตุลาคม 2020 (TVL ลดลงจาก 1 พันล้านดอลลาร์เหลือ 599 ล้านดอลลาร์เนื่องจากผู้ใช้ถอนเงินของตนออกไป) บทเรียนก็ชัดเจน: ระบบ Oracle จะต้องคำนึงถึงความจุของโครงสร้างพื้นฐานระหว่างเหตุการณ์ตึงเครียด

อย่างไรก็ตาม เหตุการณ์ที่เกิดขึ้นในเดือนตุลาคม พ.ศ. 2568 พิสูจน์ให้เห็นว่าเราไม่ได้เรียนรู้บทเรียนเลย

การแลกเปลี่ยนความอ่อนไหว: สองแนวทาง หนึ่งหายนะ

Guy จาก Ethena ได้อธิบายความท้าทายในการออกแบบหลักไว้อย่างชัดเจน: การคาดการณ์จะต้องแยกแยะระหว่างการเบี่ยงเบนชั่วคราวในระยะสั้น (สัญญาณรบกวนทางการตลาด) และการด้อยค่าของสินทรัพย์ในระยะยาว (การสูญเสียที่แท้จริง)

เดือนตุลาคม พ.ศ. 2568 แสดงคำตอบที่เป็นไปได้สองแบบ:

วิธีการที่มีความไวสูง (การแลกเปลี่ยนล้มเหลว)

• ติดตามราคาจุดแบบเรียลไทม์
• ตอบสนองต่อการเปลี่ยนแปลงของตลาดได้อย่างรวดเร็ว
• ผลลัพธ์ : ผลกระทบระลอกคลื่นมูลค่า 19.3 พันล้านเหรียญสหรัฐ

นี่คือแนวทาง bZx/Harvest: ไว้วางใจตลาดสปอต แต่กลับถูกทำลายด้วยการจัดการ

วิธีการที่มีความเสถียรสูง (แพลตฟอร์ม DeFi ที่รอดมาได้)

• USDe ที่เขียนแบบฮาร์ด = USDT
• ไม่สนใจเสียงรบกวนจากตลาดในระยะสั้น
• ผลลัพธ์ : ไม่มีการชำระบัญชี

นี่คือการแก้ไขที่มากเกินไป ซึ่งดีกว่าความล้มเหลว แต่ก็ยังไม่เหมาะสมที่สุด

อุตสาหกรรมมีเวลาห้าปีในการพัฒนาโซลูชันที่ละเอียดซับซ้อน เราไม่พบโซลูชันที่เหมาะสมที่สุดหรือโซลูชันที่ยอมรับได้ เราตกอยู่ในสถานการณ์สุดขั้วสองทาง และในท้ายที่สุด สถาบันขนาดใหญ่ก็เลือกโซลูชันที่ก่อให้เกิดหายนะ

ทฤษฎีบทการโจมตีของ Oracle: ได้รับการพิสูจน์แล้วในเชิงทดลอง

ทฤษฎีบท : ในระบบคันโยกใดๆ หากเป็นไปตามเงื่อนไขต่อไปนี้:

1. ราคาของ Oracle พึ่งพาตลาดสปอตที่สามารถจัดการได้อย่างมาก
2. เงื่อนไขการกระตุ้นการชำระบัญชีนั้นกำหนดได้
3. โครงสร้างพื้นฐานมีข้อจำกัดด้านความจุ

จากนั้น: ต้นทุนการจัดการ < มูลค่าที่สามารถสกัดได้ผ่านปฏิกิริยาลูกโซ่

พิสูจน์ด้วยการปฏิบัติซ้ำๆ:

• bZx (กุมภาพันธ์ 2020) : การจัดการ Uniswap → $350,000 + $630,000 ที่ถูกถอนออก
• การเก็บเกี่ยว (ตุลาคม 2020) : การจัดการเส้นโค้ง → ขโมยเงิน 24 ล้านเหรียญ + ทำให้เกิดการแห่ถอนเงินจากธนาคาร 570 ล้านเหรียญ
• Compound (พฤศจิกายน 2020) : การจัดการ Coinbase → ชำระบัญชี 89 ล้านดอลลาร์
• Mango (ตุลาคม 2022) : การจัดการหลายแพลตฟอร์ม → การถอนเงิน 117 ล้านดอลลาร์
• ตุลาคม 2568 : การจัดการอัตราแลกเปลี่ยนครั้งใหญ่ → สูญเสีย 19.3 พันล้านเหรียญสหรัฐ

เมื่อระบบขยายตัวแบบเชิงเส้น ขนาดของความเสียหายจะเพิ่มขึ้นแบบทวีคูณ ต้นทุนการจัดการยังคงเท่าเดิม (กำหนดโดยสภาพคล่อง) แต่มูลค่าที่สกัดได้จะเพิ่มขึ้นเมื่อปริมาณเลเวอเรจรวมในระบบเพิ่มขึ้น

เดือนตุลาคม พ.ศ. 2568 ได้พิสูจน์ทฤษฎีบทนี้ในระดับที่ไม่เคยมีมาก่อน

หลักการออกแบบ Oracle: บทเรียนที่เราควรเรียนรู้

1. การตรวจสอบหลายแหล่ง

อย่าพึ่งพาราคาแลกเปลี่ยนเพียงราคาเดียว โดยเฉพาะราคาจากสมุดคำสั่งซื้อขายของมันเอง นี่คือบทเรียนจากเหตุการณ์ bZx ในเดือนกุมภาพันธ์ 2020 การออกแบบออราเคิลที่ดีต้องอาศัย:

ราคา Oracle = ค่าเฉลี่ยถ่วงน้ำหนักของแหล่งข้อมูลต่างๆ:

• ราคาจากการแลกเปลี่ยนหลายรายการ (40%)
• สระสภาพคล่องบนเครือข่าย (30%)
• อัตราการแปลงสินทรัพย์บรรจุภัณฑ์ (20%)
• ราคาทางประวัติศาสตร์ถ่วงน้ำหนักตามเวลา (10%)

การกระจายน้ำหนักไม่สำคัญเท่ากับความเป็นอิสระของแหล่งข้อมูล หากแหล่งข้อมูลทั้งหมดสามารถจัดการได้พร้อมกันด้วยเงินทุนที่สมเหตุสมผล แสดงว่าคุณมีแหล่งข้อมูลเพียงแหล่งเดียว ไม่ใช่หลายแหล่ง

1. ความไวในการปรับตัว

Oracle ควรปรับความอ่อนไหวตามสภาวะตลาด:

• ตลาดปกติ : ไวต่อการเปลี่ยนแปลงราคามากขึ้น
• ตลาดผันผวน : เพิ่มเสถียรภาพผ่านการถ่วงน้ำหนักเวลา
• ความผันผวนรุนแรง: เบรกเกอร์วงจรและการตรวจสอบความถูกต้อง

ออราเคิลราคาเฉลี่ยถ่วงน้ำหนักตามเวลา (TWAP) ถูกนำมาใช้อย่างแพร่หลายหลังจากการโจมตีแบบแฟลชโลนในปี 2020 โดยเฉพาะอย่างยิ่งเพื่อป้องกันการปั่นราคาธุรกรรมเดียว อย่างไรก็ตาม ในเดือนตุลาคม 2025 ออราเคิลได้ตอบสนองต่อราคาสปอตแบบเรียลไทม์ ราวกับว่าไม่มีเหตุการณ์เช่นนี้เกิดขึ้นในช่วงห้าปีที่ผ่านมา

1. ความยืดหยุ่นของโครงสร้างพื้นฐาน

ระบบโอราเคิลจะต้องยังคงทำงานได้ในทุกเหตุการณ์ที่เกิดขึ้น:

• โครงสร้างพื้นฐานข้อมูลราคาอิสระ
• ความสามารถในการรองรับการสอบถามพร้อมกันนับล้านรายการ
• กลไกการย่อยสลายอย่างนุ่มนวลภายใต้ภาระหนัก

การล่มสลายของโครงสร้างพื้นฐาน Harvest Finance ในเดือนตุลาคม 2020 เน้นย้ำถึงความสำคัญของขีดความสามารถของระบบภายใต้สภาวะกดดัน ปฏิกิริยาลูกโซ่ของการชำระบัญชีก่อให้เกิดภาระที่เพิ่มขึ้นอย่างทวีคูณ โครงสร้างพื้นฐานของคุณต้องรองรับไม่เพียงแต่การชำระบัญชีครั้งแรกเท่านั้น แต่ยังรวมถึงการชำระบัญชีครั้งที่ 1,000 เมื่อผู้ดูแลตลาดไม่สามารถรับมือกับสถานการณ์ได้ทันและผู้ใช้เกิดความตื่นตระหนก

1. โปร่งใสแต่ไร้ช่องโหว่

ระยะเวลา 8 วันระหว่างการประกาศและการนำไปใช้งาน ก่อให้เกิดช่องทางการโจมตีที่ทราบอยู่แล้ว แนวทางที่ดีกว่าประกอบด้วย:

• ดำเนินการเปลี่ยนแปลงทันทีหลังจากการเผยแพร่
• ใช้การอัปเดตแบบต่อเนื่องโดยไม่มีวันที่แน่นอน
• เก็บบันทึกการตรวจสอบแต่หลีกเลี่ยงช่วงเวลาดูตัวอย่าง

นี่เป็นบทเรียนใหม่ แต่เป็นบทเรียนที่สมเหตุสมผลจากมุมมองของทฤษฎีเกม: อย่าประกาศการเปลี่ยนแปลงที่สามารถใช้ประโยชน์ได้ล่วงหน้า ผู้โจมตีมีเวลาแปดวันในการวางแผน วางแผน และเตรียมการ พวกเขารู้ดีว่าช่องโหว่จะเปิดขึ้นเมื่อใด

ผลกระทบเชิงระบบ: บทเรียนที่ไม่ได้เรียนรู้

นี่ไม่ใช่แค่ความล้มเหลวของแพลตฟอร์มเดียวเท่านั้น แต่ยังเผยให้เห็นช่องโหว่ที่แพร่หลายซึ่งอุตสาหกรรมทั้งหมดไม่ได้แก้ไขแม้จะต้องเรียนรู้ราคาแพงมาเป็นเวลาถึงห้าปีแล้วก็ตาม:

1. การพึ่งพาราคาจุดมากเกินไป

แม้จะใช้ประโยชน์จากช่องโหว่นี้ในการโจมตีครั้งใหญ่ทุกครั้งนับตั้งแต่ปี 2020 แต่แพลตฟอร์มส่วนใหญ่ยังคงใช้การออกแบบ Oracle ที่มุ่งเน้นไปที่ราคาสปอตเป็นหลัก อุตสาหกรรมนี้ทราบดีว่าราคาสปอตนั้นมีความเสี่ยงต่อการถูกปั่นราคา และราคาเฉลี่ยถ่วงน้ำหนักตามเวลา (TWAP) และ Oracle หลายแหล่งให้การป้องกันที่ดีกว่า แต่การใช้งานจริงยังไม่สมบูรณ์

ความเร็วและความไวเป็นข้อได้เปรียบในสถานการณ์ปกติ แต่กลับกลายเป็นจุดอ่อนร้ายแรงเมื่อถูกควบคุมราคา การอัปเดตราคาแบบเรียลไทม์จะแม่นยำยิ่งขึ้นจนกว่าจะมีคนควบคุมราคา

1. ความเสี่ยงจากการกระจุกตัว

แพลตฟอร์มซื้อขายหลักกลายเป็นจุดล้มเหลวเพียงจุดเดียว เห็นได้ชัดจากการที่ bZx พึ่งพา Uniswap, Compound พึ่งพา Coinbase และในเดือนตุลาคม 2568 การที่แพลตฟอร์มพึ่งพาสมุดคำสั่งซื้อขายของตนเอง ตลาดแลกเปลี่ยนอาจแตกต่างกันไป แต่ช่องโหว่ยังคงเหมือนเดิม

เมื่อตลาดแลกเปลี่ยนเดียวมีปริมาณการซื้อขายมากที่สุด การใช้ตลาดแลกเปลี่ยนนั้นเป็นแหล่งข้อมูลหลักสำหรับ Oracle ก็ดูสมเหตุสมผล อย่างไรก็ตาม ความเสี่ยงจากการกระจุกตัวของข้อมูลราคาก็เหมือนกับความเสี่ยงจากการกระจุกตัวในระบบใดๆ ก็ตาม อาจดูเหมือนไม่เป็นอันตรายจนกว่าจะถูกนำไปใช้ประโยชน์ แต่เมื่อนำไปใช้ประโยชน์แล้ว ผลที่ตามมาอาจร้ายแรง

1. สมมติฐานโครงสร้างพื้นฐาน

ระบบที่ออกแบบมาเพื่อตลาดปกติจะพังทลายลงอย่างสิ้นเชิงเมื่อต้องเผชิญกับแรงกดดัน Harvest Finance ได้พิสูจน์สิ่งนี้แล้วในปี 2020 และเดือนตุลาคม 2025 ก็พิสูจน์อีกครั้ง เรายังคงออกแบบระบบสำหรับสภาวะปกติ และหวังว่าแรงกดดันจะไม่เกิดขึ้น

ความหวังมิใช่กลยุทธ์

1. ความขัดแย้งเรื่องความโปร่งใส

การเผยแพร่ข้อมูลการปรับปรุงต่างๆ ก่อให้เกิดช่องทางการโจมตี ช่วงเวลาแปดวันระหว่างการประกาศและการนำการเปลี่ยนแปลง Oracle ไปใช้ ทำให้ผู้โจมตีมีโรดแมปและกรอบเวลาที่ชัดเจน พวกเขารู้แน่ชัดว่าควรเริ่มการโจมตีเมื่อใดและจะใช้ประโยชน์จากช่องโหว่นี้อย่างไร

นี่เป็นรูปแบบความล้มเหลวใหม่ แต่ปัญหายังคงไม่ได้รับการแก้ไขอย่างแท้จริง แม้ว่าการโจมตี Oracle ก่อนหน้านี้จะใช้ประโยชน์จากช่องโหว่ที่มีอยู่ แต่การโจมตีในเดือนตุลาคม 2025 กลับใช้ประโยชน์จากช่องโหว่ระหว่างการเปลี่ยนเมธอด Oracle ซึ่งเป็นช่องโหว่ที่มีอยู่เพียงเพราะมีการประกาศการเปลี่ยนแปลงดังกล่าวล่วงหน้า

ก้าวไปข้างหน้า: เราได้เรียนรู้บทเรียนในครั้งนี้แล้วจริงหรือ?

ปรับปรุงตอนนี้

1. การออกแบบออราเคิลแบบไฮบริด ผสมผสานแหล่งราคาหลายแหล่งเข้ากับการตรวจสอบความสมเหตุสมผลที่มีประสิทธิภาพและใช้งานได้จริง:

• ราคาแลกเปลี่ยนรวมศูนย์ (ถ่วงน้ำหนักตามปริมาณการซื้อขายแลกเปลี่ยน)
• ราคาแลกเปลี่ยนแบบกระจายอำนาจ (เฉพาะกลุ่มที่มีสภาพคล่องสูงเท่านั้น)
• หลักฐานสำรองบนเครือข่าย
• ขีดจำกัดการเบี่ยงเบนของการแลกเปลี่ยนข้าม

แต่ละแหล่งข้อมูลควรเป็นอิสระจากกัน หากการจัดการแหล่งข้อมูลหนึ่งส่งผลกระทบต่อแหล่งข้อมูลอื่น ก็จะไม่มีความซ้ำซ้อน

1. การปรับน้ำหนักแบบไดนามิก จะปรับความไวของออราเคิลตามสภาวะตลาด:

• ความผันผวนปกติ: น้ำหนักมาตรฐาน
• ความผันผวนสูง: เพิ่มหน้าต่าง TWAP เพื่อลดผลกระทบจากจุด
• ความผันผวนรุนแรง: การชำระบัญชีถูกระงับระหว่างการสอบสวนและการดำเนินการที่ตามมา

การโจมตีแบบ Compound แสดงให้เห็นว่าบางครั้งราคาที่ "ถูกต้อง" ในตลาดแลกเปลี่ยนเดียวอาจผิดพลาดสำหรับตลาดทั้งหมด ออราเคิลของคุณควรฉลาดพอที่จะรับรู้ถึงสิ่งนี้

1. เบรกเกอร์วงจร จะระงับการชำระบัญชีในช่วงที่มีความผันผวนของราคาอย่างรุนแรง ไม่ใช่เพื่อป้องกันการลดหนี้ที่ถูกต้องตามกฎหมาย แต่เพื่อแยกแยะการจัดการจากความเป็นจริงของตลาด:

• หากราคามาบรรจบกันในสถานที่ต่างๆ ภายในเวลาไม่กี่นาที อาจเป็นเรื่องจริง
• หากความผันผวนของราคาจำกัดอยู่ที่สถานที่เดียว: การจัดการที่เป็นไปได้
• หากโครงสร้างพื้นฐานมีภาระเกิน: ระงับการชำระบัญชีจนกว่าจะสามารถคืนกำลังการผลิตได้

เป้าหมายไม่ใช่เพื่อป้องกันการชำระบัญชีทั้งหมด แต่เพื่อป้องกันการชำระบัญชีแบบต่อเนื่องที่เกิดจากการจัดการราคา

1. การขยายโครงสร้างพื้นฐาน ได้รับการออกแบบมาเพื่อรองรับความจุของระบบที่มากกว่าปกติถึง 100 เท่า เนื่องจากปฏิกิริยาลูกโซ่จะสร้างภาระในระดับนี้:

• โครงสร้างพื้นฐานข้อมูลราคาอิสระ
• เครื่องชำระบัญชีอิสระ
• การจำกัดอัตราสำหรับที่อยู่เดียว
• โปรโตคอลการย่อยสลายอย่างสง่างาม

หากระบบของคุณไม่สามารถรองรับโหลดที่เกิดขึ้นระหว่างปฏิกิริยาลูกโซ่ได้ ระบบจะขยายปฏิกิริยาลูกโซ่ให้กว้างขึ้น นี่เป็นข้อกำหนดด้านการออกแบบ ไม่ใช่ตัวเลือกในการปรับปรุงประสิทธิภาพ

การแก้ปัญหาในระยะยาว

1. เครือข่ายออราเคิลแบบกระจายศูนย์ ใช้โซลูชันออราเคิลที่ครบวงจร เช่น Chainlink, Python หรือ UMA ซึ่งรวบรวมแหล่งข้อมูลหลายแหล่งและมีความสามารถในการป้องกันการจัดการในตัว โซลูชันเหล่านี้อาจไม่สมบูรณ์แบบ แต่ก็ดีกว่าการพึ่งพาออราเคิลแบบ Spot ที่ถูกนำไปใช้ประโยชน์ทุก 18 เดือน

bZx ได้ผสานรวม Chainlink เข้ากับระบบหลังการโจมตีในปี 2020 ทำให้พวกเขาไม่เสี่ยงต่อการถูกโจมตีแบบ Oracle Manipulation อีกต่อไป นี่ไม่ใช่เรื่องบังเอิญ

1. การบูรณาการหลักฐานสำรอง: สำหรับสินทรัพย์ที่ห่อหุ้มและสกุลเงินดิจิทัลที่มีเสถียรภาพ มูลค่าหลักประกันจะได้รับการตรวจสอบบนเครือข่าย USDE ควรกำหนดราคาโดยอิงจากปริมาณสำรองที่ตรวจสอบได้ ไม่ใช่การเปลี่ยนแปลงของสมุดคำสั่งซื้อขาย เทคโนโลยีนี้มีอยู่จริง แต่การใช้งานยังล่าช้า
2. การชำระบัญชีแบบค่อยเป็นค่อยไป จะป้องกันไม่ให้ปฏิกิริยาลูกโซ่ขยายตัวโดยการชำระบัญชีเป็นขั้นตอน:

• ระยะที่ 1: การเตือนและเวลาในการเพิ่มหลักประกัน
• ระยะที่ 2: การชำระบัญชีบางส่วน (25%)
• ระยะที่ 3: การชำระบัญชีครั้งใหญ่ (50%)
• ขั้นตอนสุดท้าย: การชำระบัญชีเสร็จสมบูรณ์

วิธีนี้ช่วยให้ผู้ใช้มีเวลาในการตอบสนองและลดผลกระทบจากการชำระบัญชีพร้อมกันจำนวนมากต่อระบบ

1. การ ตรวจสอบแบบเรียลไทม์ ของพฤติกรรมการจัดการ Oracle:

• ความเบี่ยงเบนของราคาการแลกเปลี่ยนข้าม
• ปริมาณการซื้อขายที่ผิดปกติในคู่การซื้อขายที่มีสภาพคล่องต่ำ
• เพิ่มขนาดตำแหน่งอย่างรวดเร็วก่อนการอัปเดต Oracle
• การจับคู่รูปแบบกับลายเซ็นการโจมตีที่รู้จัก

การโจมตีในเดือนตุลาคม 2025 น่าจะมีสัญญาณเตือนออกมา มีคนขาย USDe มูลค่า 60 ล้านดอลลาร์สหรัฐ เวลา 5:43 น. น่าจะส่งสัญญาณเตือนไปแล้ว หากระบบตรวจสอบของคุณไม่สามารถตรวจจับสัญญาณเหล่านี้ได้ แสดงว่าระบบตรวจสอบของคุณยังไม่เพียงพอ

บทสรุป: เตือนใจมูลค่า 19 พันล้านเหรียญสหรัฐ

ปฏิกิริยาลูกโซ่การชำระบัญชีในวันที่ 10-11 ตุลาคม พ.ศ. 2568 ไม่ได้เกิดจากการกู้ยืมที่มากเกินไปหรือความตื่นตระหนกของตลาด แต่เกิดจากความล้มเหลวในการออกแบบ Oracle ครั้งใหญ่ มูลค่าการดำเนินการในตลาด 60 ล้านดอลลาร์ถูกขยายให้กลายเป็นความเสียหาย 19,300 ล้านดอลลาร์ เนื่องจากระบบข้อมูลราคาไม่สามารถแยกแยะระหว่างการจัดการกับการค้นพบราคาที่แท้จริงได้

แต่นี่ไม่ใช่ความล้มเหลวแบบใหม่ แต่เป็นความล้มเหลวแบบเดียวกับที่ทำลาย bZx ในเดือนกุมภาพันธ์ 2020, Harvest ในเดือนตุลาคม 2020, Compound ในเดือนพฤศจิกายน 2020 และ Mango ในเดือนตุลาคม 2022

อุตสาหกรรมได้เรียนรู้บทเรียนนี้ห้าครั้งโดยมีต้นทุนที่เพิ่มขึ้น:

• 2020 : โปรโตคอลแต่ละอันเรียนรู้บทเรียนและนำการแก้ไขไปใช้
• 2022 : หน่วยงานกำกับดูแลเรียนรู้บทเรียนและเริ่มบังคับใช้
• 2025 : ตลาดทั้งหมดได้เรียนรู้บทเรียนและจ่ายค่าเล่าเรียนไปแล้ว 19.3 พันล้านเหรียญสหรัฐ

คำถามเดียวคือเราได้เรียนรู้บทเรียนนี้ในที่สุดหรือไม่

ทุกแพลตฟอร์มที่จัดการตำแหน่งที่มีการเลเวอเรจจะต้องถามว่า:

• ออราเคิลของเรามีความแข็งแกร่งเพียงพอที่จะปกป้องจากเวกเตอร์การโจมตีที่ทราบในปี 2020-2022 หรือไม่
• โครงสร้างพื้นฐานของเราสามารถรับมือกับผลกระทบที่เกิดขึ้นแล้วได้หรือไม่
• เราได้บรรลุความสมดุลที่เหมาะสมระหว่างความอ่อนไหวและความเสถียรแล้วหรือยัง?
• เรากำลังทำผิดซ้ำแบบที่ทำให้สูญเสียเงินหลายร้อยล้านดอลลาร์ในอุตสาหกรรมหรือไม่?

ประวัติศาสตร์ห้าปีที่ผ่านมาได้พิสูจน์แล้วว่าการจัดการของ Oracle ไม่ใช่ความเสี่ยงในเชิงสมมติฐานหรือกรณีที่ไม่แน่นอน แต่เป็นกลยุทธ์การโจมตีที่ได้รับการบันทึกไว้ ทำซ้ำได้ และสร้างกำไรได้สูง ซึ่งยังคงขยายตัวอย่างต่อเนื่องในขณะที่ตลาดเติบโต

เดือนตุลาคม พ.ศ. 2568 แสดงให้เห็นถึงสิ่งที่เกิดขึ้นหากบทเรียนเหล่านี้ไม่ได้ถูกเรียนรู้ในระดับสถาบัน การโจมตีครั้งนี้ไม่ได้ซับซ้อนหรือแปลกใหม่ เพียงแต่เป็นเพียงแค่แผนการเดิมๆ ที่ถูกนำมาใช้ซ้ำบนระบบที่ใหญ่กว่า โดยใช้ประโยชน์จากช่องโหว่ที่รู้จัก

พยากรณ์คือรากฐานสำคัญของระบบ เมื่อมันแตกร้าว โครงสร้างส่วนบนทั้งหมดก็จะพังทลาย

ในตลาดการเชื่อมต่อสมัยใหม่ การออกแบบออราเคิลไม่เพียงแต่เกี่ยวกับการส่งข้อมูลเท่านั้น แต่ยังเกี่ยวกับเสถียรภาพของระบบด้วย

ข้อผิดพลาดในการออกแบบเพียง 60 ล้านดอลลาร์ อาจทำลายเงินได้ถึง 19.3 พันล้านดอลลาร์

หากคุณทำผิดซ้ำแล้วซ้ำเล่า คุณไม่ได้เรียนรู้จากมัน แต่กลับทำผิดซ้ำอีกโดยแลกมาด้วยต้นทุนที่สูงกว่า

การวิเคราะห์อ้างอิงจากข้อมูลตลาดสาธารณะ คำชี้แจงเกี่ยวกับแพลตฟอร์ม และกรณีศึกษาการจัดการ Oracle กว่าห้าปี ความคิดเห็นที่แสดงเป็นความคิดเห็นส่วนตัวของฉัน และไม่เป็นตัวแทนของหน่วยงานใดๆ