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

อ่านบทความนี้ใน 32 นาที

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

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

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

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

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

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

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

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

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

การดูแลทรัพย์สินแบบ MPC: จุดขายของลายเซ็นแบบเกณฑ์ขั้นต่ำคือคีย์จะไม่มีอยู่ครบในที่เดียว แต่การแบ่งส่วนเชิงวิทยาการเข้ารหัสไม่ได้นำมาซึ่งการกระจายอำนาจในระดับองค์กรโดยอัตโนมัติ ตามที่ทีม Multichain เปิดเผยในขณะนั้น หลังจากผู้ก่อตั้งถูกตำรวจจีนควบคุมตัว ทีมงานก็สูญเสียการเข้าถึงเซิร์ฟเวอร์โหนด MPC ที่เกี่ยวข้องทันที ซึ่งเซิร์ฟเวอร์เหล่านี้ทำงานภายใต้บัญชีคลาวด์ส่วนตัวของผู้ก่อตั้ง เมื่อบัญชีคลาวด์ สิทธิ์การปฏิบัติการ และการตอบสนองเหตุฉุกเฉินกระจุกตัวอยู่ที่บุคคลเพียงคนเดียว การออกแบบเกณฑ์ขั้นต่ำของ 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 ผู้ที่ได้รับเลือกจะส่งหลักฐานและคีย์สาธารณะชั่วคราว ผู้สังเกตการณ์ภายนอกสามารถตรวจสอบคุณสมบัติของพวกเขาได้ แต่ยากที่จะระบุตัวตนระยะยาว คณะกรรมการชั่วคราวที่ได้รับเลือกจะร่วมกันลงนามผ่าน MPC แบบเกณฑ์ขั้นต่ำ โดยไม่มีโหนดเดียวใดสามารถสร้างผลลัพธ์ได้อย่างอิสระ กระบวนการสำคัญ เช่น การจัดการคีย์ จะทำงานใน TEE (เช่น Intel SGX) ตามการออกแบบในบทความ เพื่อลดความเป็นไปได้ที่ผู้ให้บริการโฮสต์จะอ่านหรือแก้ไขส่วนแบ่งคีย์ คณะกรรมการจะหมุนเวียนตาม epoch โดยคณะกรรมการชุดใหม่จะได้รับส่วนแบ่งใหม่ผ่านการส่งมอบคีย์ที่ตรวจสอบได้ และส่วนแบ่งเก่าจะหมดอายุลง ระยะเวลาการหมุนเวียนที่แน่นอนขึ้นอยู่กับพารามิเตอร์เครือข่ายจริง

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

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

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

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

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

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

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

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

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

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