ความล้มเหลวของ oracle ของ Aave ทำให้เกิดการชำระบัญชี 21.7 ล้านดอลลาร์ใน DeFi

เมื่อวันที่ 10 มีนาคม ความผิดพลาดทางเทคนิคในโครงสร้างพื้นฐาน oracle ของ aave นำไปสู่การบังคับชำระบัญชี ซึ่งเป็นการทดสอบความเครียดของการพึ่งพาระบบบริหารความเสี่ยงอัตโนมัติของ DeFi

เหตุการณ์ชำระบัญชี 21.7 ล้านดอลลาร์บน Aave

ผู้ใช้ Aave ประสบความสูญเสียจากการชำระบัญชีประมาณ 21.7 ล้านดอลลาร์ ในวันที่ 10 มีนาคม หลังจากข้อจำกัดบนเชนในตัวแทนความเสี่ยง Wrapped stETH (wstETH) ทำให้มูลค่าหลักประกันถูกประเมินต่ำเกินไป โดยรวมมี 34 บัญชี ถูกชำระบัญชีเนื่องจากโปรโตคอลประเมินมูลค่า wstETH ต่ำกว่าราคาตลาดจริงประมาณ 2.85%

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

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

กลไกของความล้มเหลวของ CAPO

เหตุการณ์นี้เกิดขึ้นในระบบ CAPO (Correlated Asset Price Oracle) ของ Aave ที่สร้างขึ้นเพื่อป้องกันการจัดการสินทรัพย์ที่มีราคาสัมพันธ์กัน เช่น wstETH และ stETH CAPO ดึงอัตราส่วน wstETH/stETH จาก Lido ใช้ขีดจำกัดการป้องกันผ่าน WstETHPriceCapAdapter จากนั้นคูณผลลัพธ์ด้วยราคา ETH เพื่อให้ได้มูลค่าเป็น USD

ที่เวลา 12:47 UTC ของวันที่ 10 มีนาคม เครื่องมือ Edge Risk นอกเชนของ Chaos Labs แนะนำให้อัปเดตราคาสูงสุดของ CAPO เป็น 1.1933947 wstETH/ETH ในขณะนั้น อัตราส่วนตลาดจริงอยู่ที่ 1.2285 บ่งชี้ว่าขีดจำกัดที่เสนออยู่ต่ำกว่าราคาที่มีอยู่อย่างมีนัยสำคัญแล้ว

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

ความไม่สอดคล้องกัน 2.85% ที่เกิดขึ้นทำให้โปรโตคอลประเมินมูลค่าหลักประกัน wstETH ต่ำเกินไป ผลที่ตามมาคือ บัญชีที่ควรจะปลอดภัยตามข้อมูลตลาดจริงถูกทำเครื่องหมายว่ามีหลักประกันไม่เพียงพอและถูกชำระบัญชี กระบวนการลูกโซ่ประมวลผล 10,938 wstETH ใน 34 บัญชีและสร้างโบนัสการชำระบัญชีประมาณ 512 ETH สำหรับผู้ชำระบัญชีก่อนที่ปัญหาจะถูกตรวจพบและย้อนกลับ

สาเหตุทางเทคนิคหลัก: ความไม่สอดคล้องกันของสแนปช็อต

ความล้มเหลวทางเทคนิคเกิดจากความไม่ตรงกันของพารามิเตอร์ระหว่าง snapshotRatio และ snapshotTimestamp ภายใน CAPO ตัวแทนความเสี่ยงนอกเชนของ Chaos Labs คำนวณอัตราส่วนเป้าหมายประมาณ 1.2282 ซึ่งยึดโยงกับสแนปช็อตอายุ 7 วัน อย่างไรก็ตาม ระบบบนเชนจำกัดความเร็วที่อัตราส่วนสามารถเคลื่อนไหวได้

ภายใต้กฎการป้องกันของ CAPO ค่าบนเชนก่อนหน้าที่ประมาณ 1.1572 สามารถเพิ่มขึ้นได้เพียง 3% ทุกๆ 3 วัน ในทางปฏิบัติ นั่นหมายความว่าอัตราส่วนสามารถเพิ่มขึ้นได้เพียงประมาณ 1.1919 ในการอัปเดตครั้งเดียว แม้ว่าเป้าหมายนอกเชนจะเพิ่มสูงขึ้น นอกจากนี้ การอัปเดตไม่ได้ปรับข้อจำกัดเหล่านี้ให้สอดคล้องกับตรรกะของประทับเวลา

snapshotTimestamp ถูกตั้งค่าราวกับว่าจุดยึดบนเชนสะท้อนอัตราส่วนนอกเชนอายุ 7 วันที่ 1.2282 แล้ว สิ่งนี้สร้างความไม่สอดคล้องกันที่สำคัญระหว่างการอ้างอิงเวลาและราคา ดังนั้น CAPO จึงคำนวณอัตราแลกเปลี่ยนสูงสุดประมาณ 1.1939 ซึ่งต่ำกว่าอัตราตลาดจริงที่ 1.2285 ประมาณ 2.85%

เหตุการณ์นี้เป็นการอัปเดตอัตโนมัติครั้งแรกที่ถูกผลักขึ้นบนเชนโดย CAPO Risk Agent ของ Chaos Labs นับตั้งแต่การปรับใช้ กล่าวคือ ข้อเท็จจริงที่การดำเนินการครั้งแรกสร้างการชำระบัญชีผู้ใช้ทำให้การกำหนดค่าที่ผิดพลาดน่าตกใจเป็นพิเศษสำหรับทั้งการกำกับดูแลและผู้ใช้

ห่วงโซ่การดำเนินการอัตโนมัติจาก Edge Risk ถึง AgentHub

Edge Risk เป็นเครื่องมือบริหารความเสี่ยงนอกเชนที่เป็นกรรมสิทธิ์ของ Chaos Labs ที่เตรียมและผลักดันการเปลี่ยนแปลงพารามิเตอร์จากที่อยู่ที่กำหนด AgentHub ที่พัฒนาโดย BGD รับฟังการเปลี่ยนแปลงเหล่านี้โดยใช้ Oracle Automation และจากนั้นเผยแพร่ไปยังโปรโตคอล

การเปลี่ยนแปลงพารามิเตอร์ที่ผิดพลาดเคลื่อนผ่านสแต็คความเสี่ยงอัตโนมัติของ Chaos Labs ในลำดับสองธุรกรรม ขั้นแรก เครื่องมือ Edge Risk แนะนำให้เปลี่ยนขีดจำกัดเป็น 1.191926 wstETH/ETH ในธุรกรรม 0xfbafeaa8c58dd6d79f88cdf5604bd25760964bc8fc0e834fe381bb1d96d3db95 จากนั้น AgentHub ดำเนินการเปลี่ยนแปลงหนึ่งบลอกถัดมาผ่านธุรกรรม 0x32c64151469cf2202cbc9581139c6de7b34dae2012eba9daf49311265dfe5a1e

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

พฤติกรรมนี้เสริมข้อสรุปว่าปัญหาการกำหนดราคา wstETH เป็นความล้มเหลวในการกำหนดค่าที่แยกออกมา มันไม่ใช่อาการของคุณภาพหลักประกันที่เสื่อมโทรม ปัญหาสภาพคล่อง หรือการลดอัตราเลเวอเรจที่เป็นระบบภายในระบบนิเวศ Aave

การตรวจจับ การบรรเทา และแผนชดเชยการชำระบัญชี

การกำหนดค่าที่ผิดพลาดถูกตรวจพบภายในไม่กี่นาที กระตุ้นให้เกิดการตอบสนองเหตุการณ์ที่เร่งรีบจากทีม Aave และผู้ให้บริการความเสี่ยง เพื่อป้องกันความเสี่ยงเพิ่มเติม ขีดจำกัดการยืม wstETH ทั้งใน Aave Core และ Aave Prime ถูกลดลงเหลือ 1 ทันที ซึ่งระงับกิจกรรมการยืมใหม่เทียบกับสินทรัพย์นั้นอย่างมีประสิทธิภาพ

ผ่านการแทรกแซงด้วยตนเองของ Risk Steward ทีมได้จัดตำแหน่ง snapshotRatio ให้สอดคล้องกับ snapshotTimestamp แบบสด เพื่อคืนค่าฟีด oracle ให้ถูกต้อง การแก้ไข oracle ถูกผลักดันผ่านธุรกรรม 0xb883ad2f1101df8d48f014ba308550f3251c2e0a401e7fc9cf09f9c2a158259d ในขณะที่การเปลี่ยนแปลงขีดจำกัดการยืมเพื่อตั้งค่าความจุการยืม wstETH เป็น 1 wstETH ถูกดำเนินการผ่านธุรกรรม 0x34f568b28dbcaf6a8272038ea441cbc864c8608fe044c590f9f03d0dac9cf7f8

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

เพื่อชดเชยบัญชีที่ได้รับผลกระทบ Aave จับคืนโบนัสการชำระบัญชี 141.5 ETH ผ่านการคืนเงินของ BuilderNet จากนั้น คลัง DAO ครอบคลุมช่องว่างที่เหลือ โดยการชดเชยผู้ใช้ทั้งหมดมีขีดจำกัดที่ 358 ETH ที่สำคัญคือ แผนนี้ถูกดำเนินการผ่าน Aave Improvement Proposal (AIP) โดยตรง เพื่อให้มั่นใจว่าผู้ใช้ที่ได้รับผลกระทบได้รับการชดเชยเต็มจำนวนแม้ว่าข้อผิดพลาดจะเกิดขึ้นในโครงสร้างพื้นฐาน

บริบทตลาดรอบเหตุการณ์วันที่ 10 มีนาคม

กิจกรรมข้ามเชนบน Aave แสดงการเติบโตของผู้ใช้ที่แข็งแกร่งในช่วงกุมภาพันธ์–มีนาคม ตอนอย่างเช่น Avalanche บันทึกผู้ใช้ฝาก 38,445 คนในวันที่ 10 กุมภาพันธ์ ในขณะที่ Base บันทึกผู้ใช้ฝาก 31,763 คนในวันที่ 6 มีนาคม เพียงสี่วันก่อนเหตุการณ์ชำระบัญชีที่ขับเคลื่อนโดย oracle

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

ความมีเสถียรภาพของเงินฝาก รวมกับการกลับสู่ปกติของการชำระบัญชีอย่างรวดเร็ว เน้นย้ำว่าการกำหนดราคา wstETH ที่ผิดพลาดเกิดจากปัญหาการกำหนดค่า ไม่ใช่จากความเครียดพื้นฐานในตลาดหลักประกัน กล่าวคือ ความเสี่ยงจากการกระจุกตัวในผู้ให้บริการระบบอัตโนมัติและเส้นทาง oracle ยังคงเป็นความกังวลเชิงโครงสร้างสำหรับแพลตฟอร์ม DeFi ในระดับของ Aave

การกำกับดูแล ความโปร่งใส และอนาคตของการดำเนินการ oracle อัตโนมัติ

เหตุการณ์วันที่ 10 มีนาคมแสดงให้เห็นการแลกเปลี่ยนการกำกับดูแลที่สร้างขึ้นโดย การดำเนินการ oracle อัตโนมัติ ในโปรโตคอลการให้กู้ยืม DeFi หลัก Edge Risk ของ Chaos Labs แนะนำขีดจำกัดต่ำกว่าตลาด AgentHub ของ BGD ดำเนินการหนึ่งบลอกถัดมา และการชำระบัญชีตามมาภายในไม่กี่นาที โดยแทบไม่มีเวลาสำหรับการแทรกแซงของมนุษย์

Aave ตอบสนองด้วยการตรวจจับที่รวดเร็ว การดำเนินการแก้ไขที่เด็ดขาด และการชดเชยผู้ใช้เต็มจำนวนที่ได้รับทุนบางส่วนจากคลัง DAO อย่างไรก็ตาม เหตุการณ์เผยให้เห็นข้อบกพร่องในการตรวจสอบความถูกต้องก่อนการดำเนินการและเน้นความเสี่ยงของการพึ่งพามากเกินไปในเครื่องมือบริหารความเสี่ยงที่เป็นกรรมสิทธิ์เดียว โดยเฉพาะ ลักษณะปิดของการคำนวณ Chaos Labs Edge Risk จำกัดการตรวจสอบอิสระและวางการควบคุมการดำเนินงานที่สำคัญไว้ในมือของผู้ให้บริการภายนอก

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

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