ช่องโหว่ Notional Finance V1 ทำให้หนี้ 2^128 ถูกนับเป็นศูนย์ได้อย่างไร

รายงานเกี่ยวกับเหตุการณ์ของ Notional Finance ไม่ได้ชี้ไปที่ปัญหาหลักประกันขาดแบบทั่วไป แต่เป็นความคลาดเคลื่อนทางบัญชีในสัญญา escrow รุ่น V1: มีการสร้างหนี้ fCash ขนาดมหาศาลที่ขอบเขต 2^128 แล้วหนี้ดังกล่าวกลับถูกลดค่าเป็นศูนย์เมื่อโปรโตคอลแปลงค่าให้เป็น uint128 ระหว่างคำนวณหลักประกันคงเหลือ (free collateral) ผลคือ ณ จุดตรวจสำคัญ บัญชีอาจดูเหมือนไม่มีหนี้และมีสถานะเพียงพอสำหรับถอนสินทรัพย์ ทั้งที่ตามจริงไม่ควรถอนได้ 416

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

หนี้มหาศาลที่ถูกคำนวณเป็นศูนย์

Notional V1 ใช้ fCash เพื่อแทนภาระเงินสดในอนาคต ตามสัญญาณเตือนสาธารณะของ CertiK ผู้โจมตีใช้ mintfCashPair() สองครั้งเพื่อสร้างหนี้ -2^128 จากนั้น ในขั้นตอนประเมิน free collateral มีรายงานว่าการแปลงค่าแบบไม่ปลอดภัยเป็น uint128 ตัดทอนค่านี้จนเหลือ 0 16

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

ลำดับการโจมตีที่นักวิจัยรายงานมีดังนี้

1. สร้างสถานะ fCash ติดลบขนาดสุดขอบ — ผู้โจมตีสร้างหนี้ที่มีขนาดพอดีกับจุดที่การลดขนาดชนิดข้อมูลเป็นจำนวนเต็มไม่ติดลบ 128 บิตอาจทิ้งข้อมูลของหนี้ไป 416
2. กระตุ้นการประเมินหลักประกัน — มีรายงานว่าระบบบัญชีของ escrow แปลงมูลค่าหนี้ผ่านการ downcast เป็น uint128 ที่ไม่ปลอดภัย
3. ทำให้หนี้หายไปจากการตรวจ — แทนที่จะสะท้อนภาระติดลบมหาศาล การคำนวณกลับมองค่าเป็นศูนย์ 46
4. ผ่านเงื่อนไขการถอน — เมื่อหนี้ไม่ถูกนับในการคำนวณ free collateral บัญชีจึงอาจผ่านเงื่อนไขสำหรับถอน stablecoin สภาพคล่องใน escrow ได้ 46

ด้วยเหตุนี้ ควรเข้าใจประเด็นนี้ว่าเป็นความล้มเหลวของ การแปลงชนิดข้อมูลให้แคบลงและ invariant ทางบัญชี มากกว่าจะเรียกว่า “integer overflow” แบบกว้าง ๆ ผลสำคัญตามที่รายงานคือ หนี้ติดลบถูกทำให้เป็นศูนย์พอดีในเส้นทางประเมินมูลค่าที่ควรป้องกันการถอนเงินของบัญชีที่มีหลักประกันไม่พอ 416

สินทรัพย์ที่มีรายงานว่าถูกถอนออก

การติดตามบนเชนระบุความเสียหายราว 69,257 DAI และ 1,650,824 USDC หรือรวมประมาณ 1.728 ล้านดอลลาร์สหรัฐ โดยสินทรัพย์ถูกแลกเป็นราว 689.2 ETH ก่อนถูกฝากเข้า Tornado Cash 215

สัญญาที่ถูกระบุในรายงานคือ Notional Finance escrow ที่ адрес 0x9abd0b8868546105F6F48298eaDC1D9c82f7f683 รายงานหนึ่งระบุว่ามีธุรกรรมเตรียมการจากแอดเดรสที่ลงท้าย Ce38 เวลา 23:58:47 น. UTC ของวันที่ 3 กันยายน 2026 และตามด้วยธุรกรรมถอนสินทรัพย์ราว 3 นาทีต่อมา ในช่วงต้นวันที่ 4 กันยายน 1723

นักวิจัยเชื่อมโยง Ethereum address สองรายการเข้ากับการเคลื่อนย้ายสินทรัพย์ ได้แก่

• 0xC954…De69
• 0xDaCC…Ce38

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

เหตุใดการเปลี่ยนเป็น ETH และใช้ Tornado Cash จึงทำให้การติดตามยากขึ้น

การแลก DAI และ USDC เป็น ETH เปลี่ยนลักษณะของการติดตามเงินที่ถูกนำออกไป ธุรกรรม stablecoin เดิมติดตามได้อย่างชัดเจนบน Ethereum แต่หลังแปลงเป็น ETH สินทรัพย์จะเคลื่อนผ่านเส้นทางใหม่ และการฝากเข้า Tornado Cash เพิ่มชั้นความเป็นส่วนตัวเพื่อทำให้ความเชื่อมโยงระหว่างต้นทาง ปลายทาง และคู่ธุรกรรมคลุมเครือขึ้น 229

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

สิ่งที่ยังไม่มีคำตอบอย่างเป็นทางการ

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

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

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

บทเรียนสำหรับสัญญา DeFi รุ่นเก่า

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

สำหรับทีมพัฒนาโปรโตคอล เหตุการณ์ที่รายงานเกี่ยวกับ Notional V1 ชี้ให้เห็นการควบคุมที่ควรตรวจสอบร่วมกัน ได้แก่

• ใช้การแปลงชนิดข้อมูลแบบมีการตรวจสอบ และปฏิเสธค่าที่แทนอย่างปลอดภัยไม่ได้
• ทดสอบการคำนวณหนี้มีเครื่องหมาย การชำระบัญชี และหลักประกันที่ขอบเขตตัวเลข เช่น 2^128
• เขียนกฎ solvency และการอนุรักษ์มูลค่าเป็น invariant แล้วทดสอบกับลำดับการเรียกหลายครั้ง
• ตรวจสอบว่าเส้นทางเรียกฟังก์ชันที่มีสิทธิ์พิเศษหรือไม่ปกติสามารถเชื่อมการ mint การชำระบัญชี และการถอนได้ในลำดับที่ไม่ตั้งใจหรือไม่
• จำกัดผู้เรียกและรูปแบบการเรียกในกรณีที่ฟังก์ชันปลอดภัยเฉพาะในบริบทที่ออกแบบไว้

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