เป็นความผิดของ Vibe Coding ใช่ไหม? Moonwell ระบบทำนายล่ม 1,780,000 หนี้เสีย ใครจะเป็นคนรับผิดชอบ

Moonwell เนื่องจากการตั้งค่าระบบ Oracle ผิดพลาด ทำให้ราคาของ cbETH รายงานผิดพลาดเป็น 1 ดอลลาร์ เกิดการชำระบัญชีและหนี้เสียจำนวน 2.44 ล้านดอลลาร์ วิวาทด้านความปลอดภัยของโค้ด AI ยังคงดำเนินต่อไป

ความผิดพลาดในการตั้งค่า Oracle: ราคาของ cbETH พุ่งลงทันทีเป็น 1 ดอลลาร์

ในโลกของการเงินแบบกระจายศูนย์ (DeFi) การให้ราคาที่แม่นยำคือหัวใจสำคัญของความอยู่รอดของโปรโตคอล อย่างไรก็ตาม ความผิดพลาดทางเทคนิคระดับต่ำ กลับทำให้โปรโตคอลการกู้ยืมชื่อดัง Moonwell ต้องจ่ายราคาที่สูง

เมื่อวันที่ 15 กุมภาพันธ์ โปรโตคอล Moonwell ที่ติดตั้งบนเครือข่าย Base และ Optimism ประสบความผิดพลาดร้ายแรงในการตั้งค่า Oracle ส่งผลให้ราคาของ Coinbase ที่บรรจุ ETH สินทรัพย์ค้ำประกัน (cbETH) จากประมาณ 2,200 ดอลลาร์ ร่วงลงทันทีเหลือประมาณ 1.12 ดอลลาร์ การลดลงถึง 99.9% นี้ไม่ใช่ความผันผวนของตลาดจริง แต่เป็นผลมาจากข้อเสนอการกำกับดูแลชื่อ MIP-X43 ที่ดำเนินการไม่ถูกต้อง เมื่อระบบเข้าใจผิดว่าราคา cbETH เทียบกับ ETH (ประมาณ 1.12) เป็นราคาดอลลาร์สหรัฐโดยตรง แทนที่จะคูณอัตราแลกเปลี่ยนด้วยราคาตลาด ETH ในดอลลาร์ การเกิดหายนะจึงตามมา

แม้ว่าความคลาดเคลื่อนของราคานี้จะเกิดขึ้นเพียงช่วงเวลาสั้น ๆ แต่สำหรับบอทชำระบัญชีและนักเก็งกำไรที่ทำงานตลอด 24 ชั่วโมง ก็เพียงพอที่จะสร้างความวุ่นวายในการปล้นสะดมความมั่งคั่ง จากรายงานการสอบสวนภายหลังของ Moonwell พบว่าบอทชำระบัญชีสามารถรับรู้ได้อย่างรวดเร็วว่ามูลค่าหลักประกัน cbETH เป็นศูนย์ แล้วจึงดำเนินการชำระบัญชี โดยใช้หนี้เพียงประมาณ 1 ดอลลาร์ เพื่อรับหลักประกัน cbETH มูลค่ากว่า 2,000 ดอลลาร์

สถิติระบุว่า มีจำนวน 1,096.317 หน่วยของ cbETH ถูกชำระบัญชีโดยไม่ถูกต้องในช่วงเวลาดังกล่าว มูลค่ารวมประมาณ 2.44 ล้านดอลลาร์ การดำเนินการนี้ไม่เพียงทำให้ผู้กู้หลายรายสูญเสียหลักประกันไปหมดสิ้น แต่ยังสร้างหนี้เสียในโปรโตคอลสูงถึง 1.78 ล้านดอลลาร์ แม้ทีมบริหารความเสี่ยงของ Moonwell อย่าง Anthias Labs จะรีบลดขีดจำกัดการกู้ยืมและการให้บริการ cbETH ลงเหลือ 0.01 ในไม่กี่นาทีหลังพบความผิดปกติ เพื่อป้องกันความเสียหายที่อาจลุกลาม แต่เนื่องจากการควบคุมโดยการบริหารแบบ Timelock ซึ่งมีระยะเวลาถึง 5 วัน ทำให้โปรโตคอลไม่สามารถแก้ไขราคาผิดพลาดได้ทันที ต้องปล่อยให้กระบวนการชำระบัญชีบางส่วนดำเนินต่อไปตามเดิม

Claude Opus 4.6 ช่วย? การเขียนโค้ดด้วย AI ก่อให้เกิดข้อถกเถียงด้านความปลอดภัย

เหตุการณ์นี้กลายเป็นประเด็นร้อนในชุมชน ไม่ใช่เพราะจำนวนเงินที่เสียไป แต่เป็นเพราะกระบวนการเขียนโค้ดเบื้องหลัง Pashov นักบัญชีด้านความปลอดภัยบล็อกเชน ได้ออกมาเปิดเผยบนแพลตฟอร์ม X ว่า โค้ดสำคัญที่ทำให้เกิดช่องโหว่นี้ดูเหมือนจะเป็นผลงานร่วมกันระหว่างโมเดล AI ของ Anthropic ชื่อ Claude Opus 4.6 โดยการตรวจสอบ Pull Request 578 บน GitHub พบว่ามีหลาย Commit ที่ระบุว่าเป็นผู้ร่วมเขียนโดย Claude

ภาพจาก: X/@pashov นักบัญชีด้านความปลอดภัยบล็อกเชน Pashov ชี้ให้เห็นว่า โค้ดสำคัญที่ทำให้เกิดช่องโหว่นี้ดูเหมือนจะเป็นผลงานร่วมกันระหว่างโมเดล AI ของ Anthropic ชื่อ Claude Opus 4.6

Pashov ตั้งคำถามว่า นี่อาจเป็นกรณีแรกของอุตสาหกรรม DeFi ที่เกิดจาก “Vibe Coding” (หมายถึงการพัฒนาโค้ดโดยอาศัย AI สร้างขึ้นตามสัญชาตญาณ โดยไม่ใช้ตรรกะที่รัดกุม) ซึ่งอาจนำไปสู่เหตุการณ์แฮ็กขนาดใหญ่

เขาอธิบายว่า บันทึกบน GitHub ของนักพัฒนารายนี้แสดงให้เห็นถึงประสิทธิภาพการทำงานที่น่าตกใจ โดยในสัปดาห์ที่ผ่านมา มีการ Commit มากกว่า 1,000 ครั้ง ซึ่งเป็นรูปแบบการพัฒนาที่พึ่งพา AI อย่างสูง แต่ขาดการตรวจสอบอย่างละเอียด ซึ่งเป็นความเสี่ยงด้านความปลอดภัยอย่างชัดเจน

การถกเถียงเรื่อง “Vibe Coding” นี้แพร่กระจายอย่างรวดเร็วในวงการเทคโนโลยี Fraser Edwards ผู้ร่วมก่อตั้ง cheqd เห็นว่า การพัฒนาโดย AI เป็นดาบสองคม มันสามารถช่วยนักพัฒนาที่มีประสบการณ์เร่งการสร้างโมเดลและการปรับปรุง แต่ก็อาจทำให้ผู้พัฒนาที่ขาดความรู้ลึกด้านเทคนิคพึ่งพา AI จนข้ามขั้นตอนการตรวจสอบและทดสอบหน่วย (Unit Testing) ไปได้ Pashov เสริมว่า แม้การตั้งค่าระบบ Oracle ผิดพลาดเป็นความผิดพลาดระดับต่ำที่แม้แต่วิศวกรระดับสูงก็อาจทำได้ แต่หากพึ่งพา AI มากเกินไปในกระบวนการพัฒนา โดยไม่ทำการทดสอบบูรณาการ (Integration Testing) ก็อาจเพิ่มความเสี่ยงอย่างมหาศาล ซึ่งน่าเสียดายที่แม้ Moonwell จะอ้างว่ารหัสผ่านการตรวจสอบโดย Halborn และมีเทสเคส แต่ก็ไม่พบเทสใดที่ตรวจจับ “การตรวจสอบความสมเหตุสมผลของราคา” (Price Sanity Check) ซึ่งเป็นจุดสำคัญ ทำให้โค้ดที่ AI สร้างขึ้นถูกนำไปใช้งานโดยไม่มีการตรวจสอบความถูกต้อง

วิเคราะห์รายละเอียดเทคนิค การหายไปของตัวแปรแปลงค่าและวิกฤตหนี้เสีย

ในเชิงเทคนิคของช่องโหว่นี้ ปัญหาอยู่ที่สูตรคำนวณราคาของ cbETH ที่ถูก simplified เกินไป โดยปกติแล้ว ราคาดอลลาร์ของ cbETH ควรคำนวณจาก “อัตราแลกเปลี่ยน cbETH/ETH” คูณด้วย “ราคาของ ETH เป็นดอลลาร์” แต่ในเวอร์ชันที่ได้รับผลกระทบ ระบบ Oracle กลับเรียกใช้ข้อมูลอัตราแลกเปลี่ยน cbETH/ETH เท่านั้น โดยไม่ดึงข้อมูลราคาของ ETH เป็นดอลลาร์เข้ามา

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

นอกจากการชำระบัญชีโดยไม่ได้ตั้งใจแล้ว นักเก็งกำไรบางรายยังใช้โอกาสจากราคาที่ผิดปกติในการกู้ cbETH ในปริมาณน้อย แต่มีมูลค่าหลักประกันสูง ทำให้ภาระหนี้เสียของโปรโตคอลเพิ่มขึ้น ข้อมูลจาก Anthias Labs ระบุว่า มีหนี้เสียรวม 1.77 ล้านดอลลาร์ กระจายอยู่ในตลาดของ cbETH WETH และ USDC ซึ่งไม่ใช่ครั้งแรกที่ Moonwell เจอปัญหาเรื่องราคาผิดพลาด เมื่อเดือนพฤศจิกายน 2025 ก็เคยเกิดเหตุการณ์จากการเชื่อมต่อ Oracle ของ Balancer จนทำให้เกิดหนี้เสียประมาณ 3.7 ล้านดอลลาร์

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

Moonwell เกิดช่องโหว่ Oracle ถึง 3 ครั้งในครึ่งปี

ย้อนดูช่วงครึ่งปีที่ผ่านมา Moonwell พบช่องโหว่ของ Oracle ถึง 3 ครั้ง ตั้งแต่เดือนตุลาคม 2025 ที่เกิดความผันผวนของตลาดทำให้หนี้เสีย 1.7 ล้านดอลลาร์ ไปจนถึงพฤศจิกายนที่มีหนี้เสีย 3.7 ล้านดอลลาร์ จากนั้นก็เป็นกรณี AI เขียนโค้ดผิดพลาดในครั้งนี้ที่ทำให้เกิดความเสียหาย 1.78 ล้านดอลลาร์ รวมแล้วในช่วงเวลาสั้น ๆ โปรโตคอลนี้มีหนี้เสียรวมเกิน 7 ล้านดอลลาร์

เมื่อเทียบกับมูลค่ารวมที่ถูกล็อคไว้สูงสุดในปี 2024 ที่ 380 ล้านดอลลาร์ ปัจจุบัน TVL ของ Moonwell ลดลงเหลือประมาณ 90 ล้านดอลลาร์ เหตุการณ์ด้านความปลอดภัยซ้ำซากนี้ชัดเจนว่าเป็นสาเหตุสำคัญที่ทำให้ความเชื่อมั่นของนักลงทุนลดลง แม้ทีมจะยืนยันว่า ตลาดบน Base และ Optimism ยังไม่ได้รับผลกระทบ และกำลังเตรียมการเสนอแผนแก้ไข แต่การล็อคการบริหารแบบนานหลายวันก็เป็นอีกตัวอย่างหนึ่งของความล่าช้าในการตอบสนองต่อวิกฤติใน DeFi

**กรณีของ Moonwell ยืนยันว่า AI สามารถเพิ่มผลผลิตได้ แต่ไม่สามารถรับผิดชอบทางกฎหมายและการเงินในที่สุดได้ ทีมพัฒนาจำเป็นต้องตั้งเกณฑ์การตรวจสอบที่เข้มงวดยิ่งขึ้น มองว่าโค้ดที่ AI สร้างขึ้นเป็น “ข้อมูลที่ไม่น่าเชื่อถือ” และเสริมสร้างการตรวจสอบ peer review รวมถึงการทดสอบขอบเขตของค่าที่สุดขั้ว เพื่อป้องกันความเสี่ยงในอนาคต ในป่าแห่งความมืดของ DeFi การเร่งรัดด้วยความเร็วโดยไม่คำนึงถึงความปลอดภัย อาจกลายเป็นหนี้สินที่เย็นเยือกบนบัญชีของผู้ใช้ในที่สุด