เมื่อ AI Agent ได้สิทธิ์ดำเนินการบนเชน: ใครจะตรวจสอบข้อมูลที่มันเห็นและคำสั่งที่มันส่ง?

AI Agent จำนวนมากขึ้นเรื่อยๆ เริ่มมีความสามารถในการดำเนินการธุรกรรมบนเชนผ่านบัญชีอัจฉริยะ กระเป๋าเงินเชิงกลยุทธ์ หรือบริการลงนามแบบจำกัดสิทธิ์

หนึ่ง เหตุการณ์ KelpDAO เปิดเผยอะไร

เมื่อวันที่ 18 เมษายน 2026 สะพานข้ามเชน rsETH ของ KelpDAO ถูกโจมตี มีการปล่อย rsETH จำนวน 116,500 เหรียญอย่างผิดปกติ มูลค่าในขณะนั้นประมาณ 292 ล้านดอลลาร์สหรัฐ รายงานเหตุการณ์ของ LayerZero แสดงให้เห็นว่าผู้โจมตีใช้วิศวกรรมสังคมเพื่อให้ได้คีย์เซสชันของนักพัฒนา ปนเปื้อน RPC ภายในที่ LayerZero Labs DVN พึ่งพา และใช้การโจมตีแบบปฏิเสธการให้บริการเพื่อกดดัน RPC ภายนอก ทำให้บริการลงนามออกหลักฐานสำหรับข้อความปลอมตามข้อมูลที่ผิดพลาด ในตอนนั้น KelpDAO ได้เปลี่ยนเส้นทางการตรวจสอบจาก 2-of-2 เป็น 1-of-1 DVN เมื่อ DVN ที่ถูกกำหนดเพียงรายเดียวออกหลักฐานที่ผิดพลาด ระบบก็ไม่จำเป็นต้องมี DVN อิสระรายที่สองมาตรวจสอบข้ามข้อความเดียวกันอีกต่อไป CrowdStrike และ Mandiant ระบุด้วยความเชื่อมั่นสูงว่าเหตุการณ์นี้เกี่ยวข้องกับ TraderTraitor (UNC4899) ที่เชื่อมโยงกับเกาหลีเหนือ

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

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

สอง โซลูชันที่มีอยู่แก้ปัญหาอะไร และเหลืออะไรไว้

โซลูชันที่มีอยู่หลายชุดแก้ปัญหาความเชื่อมั่นได้บางส่วน และแต่ละชุดก็ฝากความเชื่อมั่นที่เหลือไว้กับบทบาทที่แตกต่างกัน:

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

มัลติซิกของสะพานข้ามเชนและ DVN: ทั้งสองมีวิธีการทำงานที่แตกต่างกัน แต่ต่างก็ต้องการให้ฝ่ายแอปพลิเคชันกำหนดชุดผู้ตรวจสอบและเกณฑ์ขั้นต่ำอย่างชัดเจน หลังจาก KelpDAO กำหนดเส้นทางเป็น 1-of-1 DVN เส้นทางการตรวจสอบทั้งหมดก็ขึ้นอยู่กับบริการตรวจสอบเพียงรายเดียว และแหล่งข้อมูลและกลไกการรับมือความผิดพลาดที่บริการนั้นพึ่งพา ก็อาจกลายเป็นจุดล้มเหลวเดียวในระดับถัดไป

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

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

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

สาม CRVA: ออกแบบการจัดสรรสิทธิ์การตรวจสอบใหม่

DeepSafe เปลี่ยนชื่อมาจาก Bool Network ในปี 2025 CRVA สานต่อแนวคิดทางเทคนิคที่นักวิจัยที่เกี่ยวข้องกับ Bool Network เสนอไว้ในปี 2022 บทความที่เกี่ยวข้องตีพิมพ์ใน IEEE Transactions on Information Forensics and Security (IEEE TIFS, Document ID 9903072) เสนอแพลตฟอร์มการรับรองข้ามเชนที่อิงจาก "คณะกรรมการซ่อนเร้นที่วิวัฒนาการ" (evolving hidden committee)

วิธีการเฉพาะคือ: โหนดเข้าร่วมการสุ่มเลือกผ่าน Ring-VRF ผู้ที่ถูกเลือกจะส่งหลักฐานและคีย์สาธารณะชั่วคราว ผู้สังเกตการณ์ภายนอกสามารถตรวจสอบคุณสมบัติได้ แต่ยากที่จะระบุตัวตนระยะยาวได้ คณะกรรมการชั่วคราวที่ถูกเลือกจะร่วมลงนามผ่าน threshold MPC โดยไม่มีโหนดใดโหนดหนึ่งสามารถสร้างผลลัพธ์ได้อย่างอิสระ กระบวนการสำคัญเช่นการจัดการคีย์ทำงานใน TEE (เช่น Intel SGX) ตามการออกแบบในบทความ เพื่อลดความเป็นไปได้ที่ผู้ดำเนินการโฮสต์จะอ่านหรือแก้ไขส่วนแบ่งคีย์ คณะกรรมการยังหมุนเวียนตาม epoch คณะกรรมการชุดใหม่จะได้รับส่วนแบ่งใหม่ผ่านการส่งมอบคีย์ที่ตรวจสอบได้ ส่วนแบ่งเก่าจะหมดอายุทันที รอบการหมุนเวียนที่แน่นอนขึ้นอยู่กับพารามิเตอร์เครือข่ายจริง

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

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

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

สี่ พื้นฐานทางเทคนิคและความคืบหน้าในการนำไปใช้

สายธารทางเทคนิคของ CRVA สามารถย้อนกลับไปถึงบทความ Bool Network ที่ตีพิมพ์ใน IEEE TIFS เล่มที่ 17 (2022) DOI คือ 10.1109/TIFS.2022.3209546 แบบจำลองโปรโตคอล การพิสูจน์ความปลอดภัย และการประเมินต้นแบบในบทความผ่านการทบทวนโดยผู้เชี่ยวชาญ ซึ่งให้พื้นฐานทางวิชาการสำหรับการออกแบบ เช่น คณะกรรมการซ่อนเร้นแบบไดนามิก Ring-VRF การจัดการคีย์แบบ threshold และการป้องกันด้วย TEE สิ่งที่ต้องแยกแยะคือ การทบทวนโดยผู้เชี่ยวชาญมุ่งเป้าไปที่แบบจำลองและการนำไปใช้ในบทความ ส่วน CRVA ที่ DeepSafe ใช้งานอยู่ในปัจจุบันสอดคล้องกับโซลูชันในบทความอย่างไร ยังต้องพิจารณาจากข้อกำหนดทางเทคนิคฉบับปัจจุบัน การตรวจสอบโค้ด และพารามิเตอร์เครือข่าย

ตามที่ DeepSafe เปิดเผยในเดือนตุลาคม 2025 เครือข่ายได้ประมวลผลการตรวจสอบสะสมเกือบ 120 ล้านครั้ง และมีบัญชีที่ใช้งานอยู่มากกว่า 2.65 ล้านบัญชี ฝ่ายโครงการยังระบุว่ามีความสัมพันธ์ทางระบบนิเวศมากกว่า 70 รายการ ครอบคลุมประเภทต่างๆ เช่น ความเข้ากันได้ของกระเป๋าเงิน การบูรณาการทางเทคนิค การลงทุน และความร่วมมือทางการตลาด

ในเดือนตุลาคม 2025 DeepSafe ประกาศปิดรอบ Seed Round มูลค่า 3 ล้านดอลลาร์สหรัฐ นักลงทุนรวมถึง Antalpha Global, ViaBTC Capital และ Gate เป็นต้น 1 เมื่อพิจารณาจากไทม์ไลน์ การระดมทุนรอบนี้สอดคล้องกับการวิจัยและพัฒนาทางเทคนิคและการขยายระบบนิเวศหลังการเปลี่ยนชื่อแบรนด์เป็นหลัก

ห้า จากโซลูชันการตรวจสอบสู่โครงสร้างพื้นฐานทั่วไป

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

DeepSafe หวังที่จะยกระดับความสามารถในการตรวจสอบจากโมดูลเสริมภายในแอปพลิเคชันเดียว ไปสู่โครงสร้างพื้นฐานที่โปรโตคอลและ AI Agent ต่างๆ สามารถเรียกใช้ได้ — "Proof, Not Promises" ใช้หลักฐานที่ตรวจสอบได้แทนคำสัญญาของผู้ดำเนินการ CRVA ได้รวมการสุ่มเลือกแบบไม่ระบุตัวตน การทำงานร่วมกันแบบ threshold และ TEE เข้าเป็นเส้นทางเทคนิคชุดหนึ่งแล้ว การที่มันจะสามารถครอบคลุมสถานการณ์ต่างๆ เช่น ออราเคิล ข้ามเชน และ AI Agent ได้ต่อไป และพัฒนาเป็นโครงสร้างพื้นฐานการตรวจสอบทั่วไปหรือไม่ จะขึ้นอยู่กับความสามารถของเครือข่ายปัจจุบัน การตรวจสอบอิสระ และการสะสมการบูรณาการจริงอย่างต่อเนื่อง