ชั้นตรวจสอบที่พิสูจน์ได้สำหรับ AI.

แบบจำลองภัยคุกคาม

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

ทุกทางเลือกด้านล่างทำด้วยวิธีเดียวกัน เราไม่อ้างว่าพรีมิทีฟหนึ่งดีที่สุด แต่เทียบกับทางเลือกที่น่าเชื่อถือบนเครื่องเดียวกันและคอมมิตข้อมูลดิบ เพื่อให้ตัวเลขใด ๆ ที่นี่ทำซ้ำได้ด้วยคำสั่งเดียว เวลาที่รายงานคือค่าที่เร็วที่สุดจากหลายการรันหลังตัดช่วงอุ่นเครื่องออก โดยเก็บค่าเฉลี่ยและส่วนเบี่ยงเบนมาตรฐานไว้เพื่อให้การวัดที่ไม่นิ่งถูกทำเครื่องหมายแทนที่จะถูกซ่อน ตัวเลขมาจากโฮสต์ AMD64 เดียวบน CPython 3.14 และมีความหมายในฐานะอัตราส่วน ไม่ใช่ค่าสัมบูรณ์

การทดลองและผลลัพธ์

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

หมุดหมาย	ทดสอบกับ	ผลลัพธ์
รูปแบบบัญญัติ	JSON แบบง่าย, CBOR	JCS, เหมือนกันทุกไบต์, ~3x ต้นทุน
การแฮช	SHA-256, BLAKE3, keccak-256	keccak เนทีฟ 17x, ไบต์เดียวกัน
แกนเนทีฟ	แบ็กเอนด์ pip กับ Rust	ผนึก 6x, รากเหมือนกันทุกไบต์
ลายเซ็น	ECDSA, BLS, ML-DSA	Ed25519, 64 B, กำหนดได้แน่นอน
หลังควอนตัม	ML-DSA 44 / 65 / 87	เป็นระยะ, พิสูจน์ทัดเทียม, 38x ขนาด
ร่องรอยต่อการรัน	8 การโจมตีปลอมแปลง, ค่าใช้จ่ายเพิ่ม	จับได้ทั้งหมด, ~121 us / เหตุการณ์
ล็อกข้ามการรัน	สร้าง Merkle ใหม่แบบง่าย	MMR, ต่อท้ายแบบราบ, 483x

การทำอนุกรมแบบบัญญัติ

แคปซูลต้องแฮชเป็นไบต์เดียวกันในแกน Python ของเรา ในไคลเอนต์ TypeScript ของเรา และในเครื่องมือของผู้ตรวจสอบเอง มิฉะนั้นบันทึกที่ถูกต้องจะพิสูจน์ไม่ผ่าน เราใช้ RFC 8785 (JSON Canonicalization Scheme) ซึ่งตรึงการจัดรูปตัวเลข ลำดับคีย์ตามหน่วยรหัส UTF-16 และการปฏิเสธค่าที่ไม่จำกัด เราทดสอบกับ JSON ที่เรียงคีย์แบบง่ายและกับ CBOR

แนวทาง	Python กับ Node	ต้นทุน
JSON เรียงแบบง่าย	เบี่ยงเบนที่ Unicode และตัวเลข	เส้นฐาน
RFC 8785 JCS	เหมือนกันทุกไบต์	ราว 3x ตอนทำอนุกรม
CBOR	ไบนารี ต้องมีตัวถอดรหัสจึงอ่านได้	กระชับ

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

การแฮชและแกนเนทีฟ

ใบไม้แฮชด้วย BLAKE3 และโหนด Merkle ด้วย keccak-256 ทั้งคู่ใช้การแยกโดเมนตาม RFC 6962 (คำนำหน้าต่างกันสำหรับใบไม้และโหนดภายใน) เพื่อปิดคลาสพรีอิมเมจที่สองซึ่งโหนดภายในถูกเสนอเป็นใบไม้ keccak-256 ไม่ใช่ SHA3-256 ทั้งสองใช้เพอร์มิวเทชันร่วมกันแต่ต่างกันที่ไบต์แพดดิงหนึ่งไบต์ และตัวพิสูจน์ออนเชนพูด keccak การแทนที่อย่างเงียบ ๆ จึงทำให้ทุกรากล้มเหลวออนเชน ชั้นการแฮชจึงคำนวณอัลกอริทึมที่ร้องขอหรือโยนข้อผิดพลาด ไม่เคยให้ตัวปลอมที่คล้ายกัน และบันทึกอัลกอริทึมในทุกแคปซูลเพื่อให้ตัวพิสูจน์สร้างฟังก์ชันที่ถูกต้องซ้ำแทนที่จะอนุมานจากสิ่งที่ติดตั้งไว้ในเครื่อง

พรีมิทีฟ, อินพุต 64 B	ปริมาณงาน	หมายเหตุ
SHA-256 (stdlib)	1.50M ops/s	เส้นฐาน มีอยู่เสมอ
BLAKE3 (pip)	1.44M ops/s	ทัดเทียมกับ SHA-256
keccak-256 (pip)	99k ops/s	ช้ากว่า 15x จุดคอขวด
keccak-256 (แกน Rust)	1.69M ops/s	เร็วกว่า pip 17x

keccak ไม่มีการนำไปใช้ในไลบรารีมาตรฐาน ซึ่งเป็นเหตุให้โมดูลเนทีฟคุ้มที่จะสร้าง ช่องว่างกว้างที่สุดที่อินพุตขนาดเหตุการณ์ เพราะต้นทุนของ pycryptodome ตรงนั้นคือการจองอ็อบเจกต์ต่อการเรียก ไม่ใช่การแฮช ซึ่งเป็นขนาดที่ร่องรอยการตรวจสอบแฮชบ่อยที่สุดพอดี ตั้งแต่ต้นจนจบ แกนเนทีฟยกการผนึกของการรัน 1000 เหตุการณ์จาก 78 เป็น 491 การผนึกต่อวินาที ราว 6x สิ่งสำคัญ: การเปิดตัวเร่งความเร็วไม่อาจเปลี่ยนผลลัพธ์ การผนึกการรันเดียวกันโดยมีและไม่มี crate ให้รากที่เหมือนกันทุกบิต ชุดทดสอบความสอดคล้องตรวจทั้งสองเส้นทางกับเวกเตอร์ที่ผู้เขียนอัลกอริทึมเผยแพร่ และ CI สร้าง wheel แบบ ABI เสถียร (abi3) เพียงอันเดียวและพิสูจน์อาร์ติแฟกต์เดียวนั้นบน Python ทุกเวอร์ชันตั้งแต่ 3.10 ถึง 3.14 การติดตั้งมันเปลี่ยนความเร็วเท่านั้น ไม่มีอย่างอื่น

ลายเซ็นสำหรับบันทึกที่ยาวนานหนึ่งทศวรรษ

ลายเซ็นบนบันทึกการตรวจสอบต้องคงอยู่ตราบเท่าที่บันทึกยังโต้แย้งได้ และภาระการบันทึกล็อกของ AI ตอนนี้มุ่งไปสู่หนึ่งทศวรรษ หากสคีมแตกในขณะที่บันทึกยังอยู่ในหน้าต่างเก็บรักษา ผู้ไม่หวังดีสามารถปลอมและลงวันที่ย้อนหลังได้ ทั้งคลังจึงล้มลงพร้อมกัน เราวัดสมรรถนะ Ed25519 เทียบกับ ECDSA, BLS และตระกูลหลังควอนตัมของ NIST คือ ML-DSA ในด้านปริมาณงานและขนาด

สคีม	การพิสูจน์ (ops/s)	ขนาดลายเซ็น
ECDSA P-256	16,887	~72 B
ML-DSA-44 (หลังควอนตัม)	10,725	2,420 B
Ed25519	10,375	64 B
BLS12-381	การนำไปใช้อ้างอิงเท่านั้น	96 B, รวมได้

สองผลลัพธ์พลิกสมมติฐานที่เราแบกมา และเราเก็บทั้งสองไว้ในบันทึก Ed25519 ไม่ใช่ตัวที่พิสูจน์เร็วที่สุด ECDSA P-256 วัดได้เร็วกว่าราว 1.6x บนแอสเซมบลีไลบรารีที่ปรับให้เหมาะ Ed25519 ยังเป็นค่าตั้งต้นด้วยขนาดลายเซ็นและความกำหนดได้แน่นอน (RFC 8032) ซึ่งขจัดความล้มเหลวจากการใช้ nonce ซ้ำของ ECDSA ที่รั่วกุญแจส่วนตัวขณะที่ลายเซ็นยังพิสูจน์ได้ และลายเซ็นหลังควอนตัมพิสูจน์ไม่ช้า ML-DSA-44 เฉือน Ed25519 เล็กน้อย โดยต้นทุนอยู่ที่การเซ็น (ช้ากว่าราว 13x) และขนาด (ราว 38x ไบต์) เพราะร่องรอยเซ็นครั้งเดียวและพิสูจน์เป็นปี ด้านที่แพงจึงเป็นด้านที่เราทำน้อยที่สุด BLS ถูกปฏิเสธด้วยข้อกำหนด ไม่ใช่ด้วยตัวเลข การรวมยุบลายเซ็นจำนวนมากเหลือ 96 ไบต์ แต่ตัวรวมพิสูจน์แบบทั้งหมดหรือไม่มีเลยและต้องใช้ทุกกุญแจและทุกข้อความ ซึ่งเข้ากันไม่ได้กับการเปิดเผยกิ่งหนึ่งของการตัดสินใจโดยไม่เผยส่วนที่เหลือ

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

ร่องรอยการตรวจสอบต่อการรัน

แต่ละการรันเป็นลำดับเหตุการณ์แบบต่อท้ายอย่างเดียวและร้อยด้วยแฮช (การเรียก LLM, การเรียกเครื่องมือ, การเรียกค้น, การสร้างเอเจนต์ย่อย, การอนุมัติของมนุษย์, การตัดสินของราวกันตก) พร้อมราก Merkle เหนือทั้งหมดและลายเซ็น DSSE เหนือราก จัดเก็บเฉพาะแฮชของอินพุตและเอาต์พุต ไม่เคยเก็บเพย์โหลด ร่องรอยจึงรักษาความเป็นส่วนตัวโดยปริยาย ตัวพิสูจน์ไม่เพียงคืนค่าว่าถูกต้องหรือไม่ แต่ระบุชื่อการรับประกันที่แตก

การดำเนินการ (การรัน 102 เหตุการณ์)	ต้นทุน	การขยายขนาด
บันทึกหนึ่งเหตุการณ์	~121 us	ราบ, ต่ำกว่า 0.01% ของหนึ่งขั้น
ผนึก, สร้างราก	0.15 ms	เชิงเส้นตามเหตุการณ์
พิสูจน์, คำนวณทุกใบไม้ใหม่	9.2 ms	เชิงเส้น, ราว 60x ของการผนึก

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

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

ล็อกความโปร่งใสข้ามการรัน

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

เราใช้ Merkle Mountain Range แทนต้นไม้ Merkle แบบง่าย เพราะการต่อท้ายเพียงเพิ่มโหนดและไม่เคยเขียนโหนดใดใหม่ ซึ่งให้ล็อกอยู่บนที่จัดเก็บแบบเขียนครั้งเดียวหรือแบบอ็อบเจกต์ และคงการพิสูจน์การรวมเก่าให้ใช้ได้ขณะที่ล็อกโต คุณสมบัตินั้นเกือบเหมาะที่สุด ไม่ใช่เพียงสะดวก ePrint 2025/234 พิสูจน์ว่าคำมั่นแบบต่อท้ายอย่างเดียวที่กระชับใด ๆ ต้องเหนี่ยวนำจำนวนการอัปเดตพยานแบบซูเปอร์เชิงเส้น และตัวแปร MMR ที่ใกล้เคียงบรรลุขอบเขตนั้นโดยพื้นฐาน

ขนาดล็อก	สร้าง MMR	สร้างใหม่แบบง่าย
500	1.3 ms	158 ms (120x)
1,000	2.6 ms	618 ms (237x)
2,000	5.2 ms	2,491 ms (483x)

การต่อท้ายคงราบขณะที่ล็อกโต (ราว 390k การต่อท้ายต่อวินาทีทั้งที่ 100 และ 10,000 รายการ) ขณะที่การสร้างต้นไม้แบบง่ายใหม่ลดจาก 8,176 เหลือ 84 รากต่อวินาทีในช่วงเดียวกัน อันเป็นลายเซ็นกำลังสองเทียบกับเชิงเส้น-ลอการิทึม ที่จัดเก็บนิ่งอยู่ที่ 2.00 แฮชที่เก็บต่อรายการ และการพิสูจน์การรวมโตเพียงจาก 7 เป็น 17 ขั้นระหว่าง 100 ถึง 100,000 รายการ จุดที่เราเสีย: การพิสูจน์ความสอดคล้องของเราเป็น O(log^2 n) โดยแบกหนึ่งเส้นทางต่อยอดของล็อกเก่าแทน O(log n) ที่ทำได้ ไม่กี่กิโลไบต์ที่ 100,000 รายการ และเป็นการแลกโดยตั้งใจเพื่อโครงสร้างที่ผู้ทบทวนตรวจได้ด้วยการอ่าน

ขอบเขตที่เราไม่ข้าม

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

ความสามารถในการทำซ้ำ

ทุกตัวเลขที่นี่มาจากการวัดสมรรถนะที่คอมมิตไว้ซึ่งรันซ้ำได้ด้วยคำสั่งเดียว เคียงข้างชุดทดสอบ ชุดความสอดคล้องข้ามภาษาและข้ามการนำไปใช้ และเมทริกซ์ CI ที่รัน Python 3.10 ถึง 3.14 ทั้งที่มีและไม่มีแกนเนทีฟ ระเบียบวิธี, JSON ดิบ และบันทึกการตัดสินใจ (รวมถึงมิติที่แต่ละทางเลือกแพ้) อยู่ในที่เก็บโค้ด เพราะชั้นที่ทำให้ AI ตรวจสอบได้ต้องตรวจสอบตัวเองได้ด้วย