# หลักฐานชิ้นเดียว สามการตัดสินใจ

**บันทึกออกแบบโปรโตคอล · 7 กันยายน 2026**

การเขียนว่า “ตรวจแล้ว” บนเว็บไซต์ทำง่าย แต่การใช้ให้แม่นยำยากกว่า เราตรวจลายเซ็น การคำนวณ การรวมธุรกรรม เงื่อนไขนโยบาย หรือสิทธิ์ทำขั้นตอนถัดไป?

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

## 1. ตรวจชิ้นหลักฐาน

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

สิ่งนี้ยืนยันว่าผู้ออกลงนามอะไร ไม่ได้ยืนยันอิสระว่าทุกข้อความเป็นจริง โปรโตคอลบันทึกเช่น PEAC ระบุขอบเขตคำรายงานของผู้ออกชัดเจน [1]

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

## 2. ประเมินคำกล่าวอ้างที่ระบุ

ชั้นถัดไปใช้นโยบายเฉพาะกับชุดหลักฐานที่กำหนด อาจเทียบผู้รับและจำนวนเงินกับคำสั่ง หรือคำนวณ DMT ซ้ำจากฟิลด์และกฎที่อ้างถึง

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

ชนิดหลักฐานสำคัญ คำกล่าวลงนาม ข้อสังเกต RPC ข้อพิสูจน์การรวม และสถานะตรวจอิสระใช้แทนกันไม่ได้ การห่อในรายงานร่วมต้องเก็บความต่างนี้

## 3. ใช้เกณฑ์ยอมรับของตน

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

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

## ภายนอกเรียบง่าย ภายในชัดเจน

ประสบการณ์นักพัฒนาที่ตั้งใจยังย่อได้ SDK เดียวส่งคำขอ รักษาต้นฉบับ สร้างผลตรวจ และให้ตัวตรวจฝั่งผู้รับ ความเรียบง่ายควรมาจากอินเทอร์เฟซสม่ำเสมอ ไม่ใช่ลบความไม่แน่นอน

หมุดหมายการสร้างแรกคือสองโปรเซสอิสระครบวงจร: ฝ่ายหนึ่งสร้างรายงาน อีกฝ่ายทำซ้ำการตรวจที่รองรับและปฏิเสธหลักฐานที่ถูกแก้ เอกสารปัจจุบันอธิบายเป้าหมายนี้ SDK ที่เผยแพร่ยังไม่มี

## รายงานความล้มเหลวที่แท้จริงก็เป็นหลักฐานที่มีประโยชน์

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

ในทางกลับกัน รายงานที่ไม่ถูกแก้ไขอาจมีคำกล่าวอ้างว่าสำเร็จโดยผู้จัดทำไม่มีหลักฐานรองรับ ตัวประเมินต้องไม่ยืมความแน่นอนมาจากลายเซ็น แบบจำลองข้อมูล Verifiable Credentials ของ W3C เป็นเอกสารต้นทางที่ช่วยแยกการตรวจสอบกลไกของข้อมูลรับรองออกจากการตัดสินใจไว้วางใจของผู้พึ่งพาข้อมูล Proof21 ไม่ได้อ้างว่ารูปแบบสิ่งส่งมอบฉบับร่างของตนเป็นข้อมูลรับรอง W3C โดยอัตโนมัติ [2]

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

## ต้องตกลงไบต์ให้แน่นอนก่อนลงนาม

วัตถุ JSON สองชุดอาจดูมีความหมายเท่ากันสำหรับผู้อ่าน แต่มีการเข้ารหัสต่างกัน ลายเซ็นต้องใช้ข้อความที่กำหนดอย่างแม่นยำ ไม่ใช่ภาพหน้าจอหรือการตีความของผู้อ่าน RFC 8785 กำหนดกฎ JSON Canonicalization Scheme ซึ่งรวมข้อจำกัดของข้อมูลและการซีเรียลไลซ์แบบกำหนดผลแน่นอน เป็นเอกสารออกแบบที่เกี่ยวข้อง แต่ไม่ทดแทนการเลือกและทดสอบโปรไฟล์การซีเรียลไลซ์ที่แน่นอนของระบบจริง [3]

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

ตัวแยกวิเคราะห์ควรปฏิเสธเวอร์ชันที่ไม่รองรับและฟิลด์ซ้ำหรือขัดกันตามกฎที่ประกาศไว้ จำกัดขนาดอินพุตก่อนเริ่มงานที่ใช้ทรัพยากรมาก ใช้ไลบรารีการเข้ารหัสที่เป็นที่ยอมรับพร้อมชุดทดสอบ แทนการให้โมเดลภาษาประดิษฐ์วิธีตรวจลายเซ็น RFC 8032 ให้ข้อกำหนด EdDSA และชุดทดสอบ การเลือก Ed25519 เพียงอย่างเดียวไม่ได้พิสูจน์ความเป็นเจ้าของกุญแจ สถานะการเพิกถอน หรือสิทธิ์ดำเนินการ [4]

## การยอมรับเป็นหน้าที่ของนโยบายผู้ใช้ผลที่มีชื่อชัดเจน

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

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

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

## คำถามที่พบบ่อย

### ลายเซ็นผ่านการตรวจได้ในขณะที่การจ่ายเงินไม่ผ่านได้หรือไม่?

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

### การยอมรับรายงานอนุญาตให้เอเจนต์ใช้เงินหรือไม่?

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

### หลักฐานทุกชนิดลดเหลือคะแนนความไว้วางใจเดียวได้หรือไม่?

การทำเช่นนั้นจะซ่อนความแตกต่างสำคัญ คำยืนยันที่ลงนาม การสังเกตผ่าน RPC และสถานะที่ตรวจสอบอย่างอิสระรองรับข้อกล่าวอ้างต่างกัน ซองข้อมูลร่วมควรคงชนิดหลักฐานต้นฉบับ ที่มา ข้อจำกัด และคำถามที่ยังไม่คลี่คลายไว้

## เอกสารต้นทางเพิ่มเติม

- [2: W3C Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/)
- [3: RFC 8785 — JSON Canonicalization Scheme](https://www.rfc-editor.org/rfc/rfc8785.html)
- [4: RFC 8032 — อัลกอริทึมลายเซ็นดิจิทัล Edwards-Curve](https://www.rfc-editor.org/rfc/rfc8032.html)

## อ่านต่อ

- [แบบตรวจฝั่งผู้รับ](https://proof21.xyz/th/docs/protocol/verification/)
- [ความปลอดภัยและขอบเขตความเชื่อถือ](https://proof21.xyz/th/docs/protocol/security/)
- [1: ขอบเขตหลักฐาน PEAC](https://www.peacprotocol.org/)