AI จะช่วยเพิ่มความปลอดภัยให้กับสัญญาอัจฉริยะได้อย่างไร? แชร์ประสบการณ์การปฏิบัติจากโมเดลทั่วไปสู่รูปแบบการตรวจสอบสามขั้น

แหล่งที่มาของต้นฉบับ: Beosin

ในปีที่ผ่านมา แบบจำลองภาษาขนาดใหญ่ (LLM) เช่น GPT-4, Claude, Gemini ได้พัฒนาความสามารถในการทำความเข้าใจโค้ดในระดับที่แข็งแกร่งขึ้น สามารถอ่านภาษา smart contract เช่น Solidity, Rust, Go ได้ดีพอสมควร และยังสามารถระบุช่องโหว่คลาสสิกที่มีลักษณะโค้ดเด่นชัด เช่น การโจมตีแบบ reentrancy และ integer overflow สิ่งนี้ทำให้อุตสาหกรรมเริ่มตั้งคำถาม: เราสามารถใช้ LLM เพื่อช่วยเหลือหรือแม้แต่แทนที่การตรวจสอบ smart contract ด้วยมนุษย์ได้หรือไม่?

เนื่องจากโมเดลทั่วไปมีความเข้าใจไม่เพียงพอเกี่ยวกับตรรกะธุรกิจของโปรเจกต์เฉพาะเจาะจง เมื่อต้องเผชิญกับโปรโตคอล DeFi ที่ซับซ้อน อัตราการแจ้งเตือนผิดพลาด (false positive) จึงค่อนข้างสูง และยังมีแนวโน้มที่จะพลาดช่องโหว่ที่ต้องอาศัยการทำความเข้าใจการโต้ตอบข้ามสัญญาหรือโมเดลทางเศรษฐกิจ (economic model) ต่อมา อุตสาหกรรมได้เสนอแนวทางในการเพิ่มกลไก "Skill" — โดยการฉีดความรู้เฉพาะทางสำหรับความปลอดภัยของ smart contract กฎการตรวจจับ และบริบทธุรกิจลงบนพื้นฐานของ LLM ทั่วไป ทำให้โมเดลมีเกณฑ์การตัดสินที่ชัดเจนยิ่งขึ้นในการตรวจสอบ แทนที่จะอาศัยเพียงความสามารถทั่วไปในการตัดสินว่าโค้ดมีปัญหาหรือไม่

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

1. ขอบเขตความสามารถในการตรวจสอบของโมเดล AI ทั่วไป: การทดสอบเปรียบเทียบภายใต้การควบคุมและการวิเคราะห์กรณีศึกษา

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

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

กรณีศึกษา A · สัญญาโทเค็นมาตรฐาน (BSC-USDT / BEP20USDT.sol)

สำหรับการทดสอบชุดแรก เราเลือกสัญญาโทเค็น BEP-20 มาตรฐาน ซึ่งเขียนด้วย Solidity เวอร์ชัน 0.5.16 ตรรกะของมันค่อนข้างเป็นอิสระ ขอบเขตหน้าที่ชัดเจน ไม่เกี่ยวข้องกับการโต้ตอบข้ามสัญญาใดๆ ความเสี่ยงด้านความปลอดภัยหลักจะรวมศูนย์อยู่ที่รูปแบบช่องโหว่ที่รู้จักและพบเห็นบ่อยๆ สัญญาประเภทนี้ในทางทฤษฎีคือสถานการณ์ที่ AI ได้เปรียบมากที่สุดในการตรวจสอบในปัจจุบัน — มีข้อมูลฝึกอบรมสัญญาโทเค็นมาตรฐานประเภทนี้จำนวนมาก และลักษณะของช่องโหว่ที่เป็นไปตามกฎก็ค่อนข้างชัดเจน

AI ส่งออกการแจ้งเตือนทั้งหมด 6 รายการ (ระดับสูง 2 รายการ ระดับกลาง 1 รายการ ระดับต่ำ/ข้อเสนอแนะ 3 รายการ) เมื่อดูจากจำนวนแล้วถือว่าค่อนข้างมาก รายการระดับต่ำและข้อเสนอแนะมีความถูกต้องเป็นส่วนใหญ่ ครอบคลุมปัญหามาตรฐานโค้ดทั่วไป เช่น เวอร์ชัน Solidity ที่เก่าเกินไป วิธีการเปิดเผยตัวแปรสถานะ (state variable) ซึ่งมีคุณค่าอ้างอิงในระดับหนึ่ง อย่างไรก็ตาม การแจ้งเตือนระดับ "สูง" สองรายการที่ AI ส่งออกล้วนเป็นการตัดสินที่ผิดพลาด (false positive) AI ทำเครื่องหมายสิทธิ์ในการ mint ของ owner และการรวมศูนย์อำนาจเป็นช่องโหว่ระดับสูง — ในความเป็นจริงสำหรับ stablecoin ที่รวมศูนย์ (ประเภท USDT) การที่ owner มีสิทธิ์ในการ mint เป็นส่วนหนึ่งของการออกแบบที่ตั้งใจไว้ การประเมินความเสี่ยงควรพิจารณาร่วมกับกลไกควบคุมแบบ multi-signature กลไกการกำกับดูแลอำนาจ (governance) และกลยุทธ์การอัปเกรดสัญญา ความสมเหตุสมผลของโครงสร้างสิทธิ์ประเภทนี้ขึ้นอยู่กับโมเดลธุรกิจของโปรเจกต์เป็นหลัก ไม่ใช่โค้ดเอง AI ขาดบริบทในระดับนี้ และสามารถตัดสินได้เพียงจากการจับคู่รูปแบบ (pattern matching)

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

กรณีศึกษา B · สัญญาธุรกิจที่ซับซ้อน (IPC Protocol / 2025-02-recall)

การทดสอบชุดที่สองเลือกโปรเจกต์ IPC Protocol จากรายงานสาธารณะของแพลตฟอร์ม Code4rena (ลิงก์รายงาน: code4rena.com/reports/2025-02-recall) โปรเจกต์นี้ประกอบด้วยคอมโพเนนต์หลักหลายส่วนที่พึ่งพาซึ่งกันและกัน เช่น Gateway, SubnetActor, โมเดลพร็อกซี่แบบ Diamond ความปลอดภัยขึ้นอยู่กับการทำความเข้าใจอย่างลึกซึ้งเกี่ยวกับสถาปัตยกรรมโปรโตคอลโดยรวมและตรรกะการโต้ตอบข้ามคอมโพเนนต์ นี่คือสถานการณ์ทั่วไปที่การโจมตีมูลค่าสูงเกิดขึ้นในระบบนิเวศ DeFi ต่อไปนี้คือผลการตรวจสอบด้วย AI:

สำหรับสัญญาที่ซับซ้อน การตรวจสอบด้วย AI สร้างการแจ้งเตือนระดับสูง 3 รายการ และระดับกลาง 6 รายการ เมื่อดูจากปริมาณการส่งออกแล้วไม่ด้อยไปกว่ากัน แต่สัดส่วนที่ค่อนข้างมากถูกผู้ตรวจสอบตัดสินว่าเป็นการแจ้งเตือนผิดพลาด — AI ตัดสินความเสี่ยงผิดพลาดสำหรับส่วนโค้ดที่ขาดบริบท ในขณะเดียวกัน จากช่องโหว่ระดับ High ทั้ง 9 รายการที่ผู้ตรวจสอบยืนยัน AI ครอบคลุมเพียง 1 รายการอย่างสมบูรณ์ อีก 2 รายการถูกพบแต่มีการจัดระดับที่ต่ำกว่าความเป็นจริงอย่างชัดเจน (จริงๆ แล้วเป็น High แต่ AI รายงานเป็น Medium) ส่วนที่เหลืออีก 6 รายการไม่ถูกค้นพบเลย จากช่องโหว่ระดับ Medium 4 รายการ AI ครอบคลุม 1 รายการ และขาดหายไป 3 รายการ

ลักษณะร่วมของช่องโหว่เหล่านี้คือ: ล้วนต้องอาศัยการให้เหตุผลแบบสมบูรณ์เกี่ยวกับเส้นทางเปลี่ยนสถานะข้ามคอมโพเนนต์ของโปรโตคอล ไม่ใช่การจับคู่รูปแบบของฟังก์ชันเดียว ตัวอย่างเช่น H-01 (signature replay) ในรายงานการตรวจสอบโดยมนุษย์ เส้นทางใช้ประโยชน์ช่องโหว่ต้องเข้าใจความตั้งใจในการออกแบบการตรวจสอบหลายลายเซ็น (multi-signature verification) ผู้โจมตีจะสร้างชุดลายเซ็นซ้ำได้อย่างไร และพฤติกรรมนี้จะหลีกเลี่ยงเกณฑ์น้ำหนัก (weight threshold) ได้อย่างไร H-06 (การโจมตีแบบ reentrancy ในฟังก์ชัน leave()) ก็เช่นกัน: ช่องโหว่มีอยู่เฉพาะในสถานะวิกฤติ bootstrap ของเครือข่ายย่อย (subnet) ซึ่งต้องเข้าใจการพึ่งพาซึ่งกันและกันระหว่างการไหลเวียนของการ staking เงื่อนไขการกระตุ้น bootstrap และลำดับเวลาของการเรียกข้ามสัญญา (external call) ช่องโหว่เชิงลึกที่คล้ายกันเช่นนี้ไม่มีบันทึกใดๆ ในรายการแจ้งเตือนของ AI

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

เมื่อพิจารณารวมทั้งสองกรณีศึกษาแล้ว การตรวจสอบด้วย AI ไม่ได้ไร้ค่า — มันมีส่วนช่วยอย่างเป็นรูปธรรมในการครอบคลุมรูปแบบช่องโหว่ที่รู้จัก การตรวจสอบมาตรฐานโค้ด และการค้นพบบางส่วนจากมุมมองที่เป็นอิสระ แต่ขอบเขตคุณค่าของมันชัดเจนมาก: สามารถใช้เป็นเครื่องมือสแกนพื้นฐาน (baseline scan) ได้ แต่ไม่สามารถใช้เป็นข้อสรุปด้านความปลอดภัยโดยตรงได้ สำหรับโปรโตคอลที่ซับซ้อน การพึ่งพาเพียงรายงาน AI เพื่อตัดสินด้านความปลอดภัย ไม่เพียงแต่จะพลาดช่องโหว่ที่มีความเสี่ยงสูง แต่ยังทำให้ทีมงานต้องใช้เวลาในการคัดกรองจำนวนมากเนื่องจากมีการแจ้งเตือนคุณภาพต่ำจำนวนมาก นี่คือเหตุผลหลักที่ Beosin สร้างคลังความรู้ Skill เฉพาะทาง และนำกลไกโหมดการตรวจสอบสามชั้นเข้ามาในกระบวนการตรวจสอบ

2. คลังความรู้ Skill เฉพาะทาง: เส้นทางทางวิศวกรรมเพื่อยกระดับการตรวจสอบพื้นฐานด้วย AI

เพื่อที่จะนำการตรวจสอบด้วย AI เข้ามาในกระบวนการตรวจสอบเป็นขั้นตอนพื้นฐาน (baseline check) จำเป็นต้องแก้ไขปัญหาอัตราการแจ้งเตือนผิดพลาด (false positive) และการพลาดแจ้งเตือน (false negative) ที่ค่อนข้างสูงเมื่อตรวจสอบโปรโตคอล DeFi จริง ไม่ว่าจะเป็น การจัดการสิทธิ์ กลไกสภาพคล่องของ AMM การตรวจสอบข้อความของสะพานข้ามเชน (cross-chain bridge) หรือตรรกะการชำระบัญชี (liquidation) ของโปรโตคอลการให้ยืม ปัจจุบัน AI สามารถจับคู่ตามลักษณะพื้นผิวของโค้ดได้เท่านั้น และยากที่จะตัดสินว่าบล็อกโค้ดมีปัญหาหรือไม่โดยพิจารณาร่วมกับสถานการณ์ธุรกิจเฉพาะและตรรกะการโจมตี-ป้องกัน แกนกลางของการแก้ไขปัญหานี้คือการฉีดประสบการณ์ที่ผู้เชี่ยวชาญการตรวจสอบสะสมมาหลายปีในรูปแบบที่มีโครงสร้างเข้าสู่กระบวนการตัดสินใจของ AI ทำให้มันมีความสามารถในการเข้าใจธุรกิจในระดับหนึ่ง

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

2.1 การกลั่นกรองจากการตรวจสอบจริง: กลไกการสร้างกฎ Skill

คลังความรู้ Skill ของ Beosin มาจากโปรเจกต์ smart contract มากกว่า 4,000 โปรเจกต์ที่ผ่านการตรวจสอบโดยมนุษย์แล้ว โดยผู้เชี่ยวชาญการตรวจสอบได้ทำการสรุปและจัดหมวดหมู่จำนวนมาก และกลั่นกรอง ตรวจสอบ และจัดระเบียบทีละข้อ กฎแต่ละข้อเกิดขึ้นโดยผ่านกระบวนการทั้งหมดตั้งแต่การค้นพบช่องโหว่จนถึงการนำกฎไปใช้: หลังจากที่ผู้ตรวจสอบพบปัญหาด้านความปลอดภัยในโปรเจกต์จริง พวกเขาจะสร้างเส้นทางการโจมตีขึ้นใหม่อย่างสมบูรณ์ วิเคราะห์สาเหตุรากเหง้าอย่างลึกซึ้ง ตรวจสอบว่าวิธีการแก้ไขมีประสิทธิภาพหรือไม่ และสุดท้ายจัดระเบียบความรู้ความเข้าใจเกี่ยวกับการโจมตี-ป้องกันทั้งหมดนี้เป็นรายการกฎที่มีเงื่อนไขการตัดสินใจตามบริบท นำเข้าสู่คลัง Skill เพื่อเรียกใช้ในการตรวจสอบครั้งต่อๆ ไป

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

[Beosin-AMM_Skill-1] การตรวจสอบการเพิ่มสภาพคล่องถูกหลีกเลี่ยงผ่านลำดับการโอน

รูปแบบช่องโหว่: สัญญาตรวจสอบว่ายอดคงเหลือ WBNB ในคู่ (Pair) เกินปริมาณสำรองหรือไม่ (balanceOf >= reserve + required) เพื่อตัดสินว่าเป็นการดำเนินการเพิ่มสภาพคล่องหรือไม่ การตรวจสอบนี้พึ่งพาสมมติฐานที่ว่า WBNB