บันทึกการออกแบบโพรโทคอล · 7 กันยายน 2026 · เป้าหมายความเข้ากันได้ไม่ใช่การเชื่อมต่อที่สร้างเสร็จแล้ว
เวิร์กโฟลว์หนึ่งอาจสร้างใบแจ้งหนี้ ข้อเสนอบริการที่ลงนาม ใบรับ การสังเกตธุรกรรม และผลประเมินนโยบาย การใส่ทั้งหมดในซองรูปแบบเดียวทำให้เขียนซอฟต์แวร์ง่ายขึ้นได้ แต่ก็ทำให้หลักฐานเข้าใจยากขึ้น หากซองนั้นแอบถือว่าทุกชิ้นเป็นหลักฐานความสำเร็จที่เท่ากัน
เป้าหมายการทำงานร่วมกันของ Proof21 ควรตรงข้าม คืออินเทอร์เฟซสม่ำเสมอที่คงความหมาย ที่มา และข้อจำกัดของต้นฉบับ ใช้รูปแบบเดิมซ้ำเมื่อเหมาะ เพิ่มเฉพาะการผูกข้อมูลและผลประเมินที่เวิร์กโฟลว์ต้องการจริง ชื่อใหม่สำหรับใบรับไม่ใช่เหตุผลให้แทนระบบนิเวศที่ทำงานดีอยู่แล้ว
ระบุข้อกล่าวอ้างก่อนเลือกซอง
ส่วนขยายข้อเสนอและใบรับที่ลงนามของ x402 เกี่ยวกับสิ่งส่งมอบจากปฏิสัมพันธ์เชิงพาณิชย์ PEAC อธิบายบันทึกปฏิสัมพันธ์ที่ตรวจสอบได้พร้อมขอบเขตหลักฐานที่ผู้ออกรายงาน สิ่งเหล่านี้เป็นอินพุตหรือเป้าหมายความเข้ากันได้ที่มีประโยชน์ แต่ไม่ควรขยายป้ายใดให้เป็นหลักฐานอิสระว่าทุกงานปลายทางที่ร้องขอทำถูกต้องแล้ว [1][2]
อะแดปเตอร์ที่เสนอควรบอกข้อกล่าวอ้างแน่นอนที่รับ เช่น ผู้ออกนี้ลงนามเงื่อนไขการค้านี้ บริการนี้รายงานปฏิสัมพันธ์นี้ แหล่งนี้คืนการสังเกตธุรกรรมนี้ ตัวประเมินนี้เทียบฟิลด์เหล่านี้ตามโปรไฟล์นี้ จากนั้นผู้ใช้ผลรวมคำกล่าวได้โดยไม่แสร้งว่ามีสมมติฐานความไว้วางใจเหมือนกัน
เริ่มจากรุ่นที่ระบุชื่อหนึ่งรุ่นและรูปแบบสิ่งส่งมอบที่รองรับหนึ่งแบบ การอ้างว่า “เข้ากันได้กับทุกอย่าง” มีประโยชน์น้อยกว่าโปรไฟล์แคบที่มีเวกเตอร์ทดสอบบวก ลบ และกรณีไม่รองรับ อธิบายว่าอะแดปเตอร์แยกวิเคราะห์สิ่งส่งมอบ ตรวจกลไก ประเมินข้อกล่าวอ้าง หรือเพียงเก็บไว้ตรวจภายหลัง
เก็บต้นฉบับก่อนปรับรูปแบบ
สมมติว่าอะแดปเตอร์อ่านสิ่งส่งมอบ JSON ที่ลงนาม แล้วสร้างมุมมองรูปแบบกลางที่ใช้สะดวก มุมมองนั้นช่วยนักพัฒนาได้ แต่ต้องไม่ทิ้งตัวแทนข้อมูลต้นฉบับที่รับรอง หากเปลี่ยนชนิดข้อมูล ลบฟิลด์ เปลี่ยนการจัดการ Unicode หรือเปลี่ยนการซีเรียลไลซ์ ไบต์ที่ได้อาจไม่ใช่ข้อความที่ผู้ออกลงนามแล้ว
เก็บต้นฉบับหรือแหล่งอ้างอิงสำหรับดึงข้อมูลที่ได้รับอนุญาตและผูกความสมบูรณ์ไว้ บันทึกเวอร์ชันการแปลงและว่าฟิลด์กลางแต่ละตัวมาจากอินพุตใด แยกฟิลด์ที่ไม่มีออกจากค่าที่ระบุชัดว่าว่างหากรูปแบบต้นทางแยกเช่นนั้น ฟิลด์ที่ไม่รองรับต้องไม่หายเงียบ ๆ หากมีผลต่อการตรวจสอบหรือความหมายของข้อกล่าวอ้างต้นทาง
การทำให้เป็นรูปแบบมาตรฐานแก้ปัญหาซีเรียลไลซ์ที่กำหนด ไม่ได้แก้ทุกปัญหาการแปลง RFC 8785 เป็นเอกสารอ้างอิงของวิธีทำ JSON ให้เป็นรูปแบบมาตรฐานแบบหนึ่ง โปรไฟล์ต้องระบุว่าใช้เมื่อใด และต้นฉบับใช้กฎอื่นเมื่อใด อย่าปรับวัตถุลงนามใด ๆ แล้วคิดว่าลายเซ็นต้องตรวจผ่านกับไบต์ใหม่ [3]
รักษาตัวระบุให้แน่นอนข้ามระบบ
ชื่อเครือข่ายและสินทรัพย์เป็นสาเหตุพบบ่อยของการถือว่าเท่ากันโดยผิดพลาด สองเครือข่ายอาจแสดงสัญลักษณ์สินทรัพย์เดียวกัน เครือข่ายทดสอบกับเครือข่ายจริงอาจมีที่อยู่ดูคล้าย ตัวระบุบัญชีภายในอาจไม่มีความหมายนอกระบบที่ออกให้ รายงานรูปแบบกลางต้องคงเนมสเปซและกฎการผูก
CAIP-2 และ CAIP-19 ให้ข้อกำหนดต้นทางสำหรับระบุเชนและสินทรัพย์ มันช่วยตั้งชื่อสิ่งที่พูดถึง ไม่ได้พิสูจน์ว่าเชนภายนอกได้ฉันทามติหรือเกิดการโอนเฉพาะครั้ง ผู้ใช้ผลยังต้องมีหลักฐานการดำเนินการและนโยบายยอมรับ [4][5]
ในการทดสอบร่วมกันแบบสังเคราะห์ ให้สัญลักษณ์แสดงผลเหมือนเดิมแต่เปลี่ยนตัวระบุสินทรัพย์ที่แท้จริง จากนั้นเปลี่ยนเครือข่ายโดยให้ข้อความผู้รับยังดูคล้าย อะแดปเตอร์ควรแสดงความเปลี่ยนแปลง ไม่ใช่รวมระเบียน อินเทอร์เฟซที่ดีอธิบายความไม่ตรงได้โดยไม่เขียนตัวระบุใหม่เพื่อให้เวิร์กโฟลว์ผ่าน
แยกความสำเร็จในการรับส่งจากความสำเร็จเชิงความหมาย
คำตอบ HTTP สำเร็จหมายถึงคำขอได้รับการจัดการตามอินเทอร์เฟซเซิร์ฟเวอร์ ไม่ได้แปลว่าข้อกล่าวอ้างธุรกิจถูกประเมินเป็นบวกโดยอัตโนมัติ สิ่งส่งมอบแท้จริงอาจบรรทุกผลเชิงลบ โปรไฟล์ที่ไม่รองรับยังต้องเป็นไม่รองรับ แม้ JSON แยกวิเคราะห์ได้ ความต่างนี้ต้องอยู่ทั้งในสคีมาและการแสดงผล
ผู้ใช้ผล P21 ตามข้อเสนอควรรายงานความสมบูรณ์สิ่งส่งมอบ ผลของแต่ละการประเมินที่รองรับ และการยอมรับท้องถิ่นแยกกัน หากรูปแบบพันธมิตรมีแค่คำยืนยันผู้ออก ต้องคงประเภทหลักฐานนั้น อย่าเปลี่ยนชื่อเป็นสถานะที่ตรวจสอบอย่างอิสระเพียงเพราะอยู่ในรายงาน P21 แล้ว
เช่นกัน การเก็บลายเซ็นต่างระบบไม่ได้ยืนยันว่าผู้ใช้ผลยอมรับผู้ออกวันนี้ การค้นหากุญแจ การหมุนเวียน การเพิกถอน และอำนาจองค์กรมีนโยบายของตน การทดสอบออฟไลน์กับกุญแจที่ให้มาแสดงได้แค่ขอบเขตที่กล่าวไว้ อะแดปเตอร์ข้ามรูปแบบต้องไม่ทำให้เข้าใจว่าตรวจทะเบียนตัวตนหรือความไว้วางใจแล้วหากไม่ได้ทำ
สร้างสัญญาความเข้ากันได้ที่ล้มเหลวอย่างซื่อตรงได้
การเชื่อมต่อแรกควรบันทึกเวอร์ชันอินพุต ข้อกล่าวอ้างที่รองรับ ฟิลด์จำเป็น กลไกรับรอง โปรไฟล์เอาต์พุต ต้นฉบับที่เก็บ และเงื่อนไขยังไม่คลี่คลาย เผยแพร่ชุดตัวอย่างที่ครอบคลุมสิ่งส่งมอบครบ การแก้ไข ตัวระบุการดำเนินการผิด เวอร์ชันไม่รู้จัก ผลลบแท้จริง และหลักฐานขาด ให้ผู้จัดทำและผู้ใช้ผลทำงานอย่างอิสระ
การทดสอบไปกลับตรวจได้ว่าอะแดปเตอร์เก็บสิ่งที่สัญญาจะเก็บหรือไม่ การทดสอบเทียบต่างเปิดเผยความไม่ตรงกับการติดตั้งต้นทางได้ แต่ทั้งสองแบบไม่ยืนยันความร่วมมือหรือความพร้อมผลิตจริงด้วยตัวเอง บันทึกรุ่นแก้ไขต้นทางและวันทดสอบ เพื่อไม่ให้การเปลี่ยนภายหลังทำให้คำกล่าวความเข้ากันได้เดิมหมดอายุอย่างเงียบ ๆ
ผลนำร่องที่มีประโยชน์คือผู้ใช้ผลอิสระอธิบายผลและหาต้นฉบับได้โดยไม่ต้องให้ผู้จัดทำเล่าใหม่ เอกสาร Proof21 ปัจจุบันระบุเป้าหมายการทำงานร่วมกันและขอบเขต ไม่ได้อ้างว่ามีอะแดปเตอร์ PEAC, x402, MCP หรือ A2A ที่เผยแพร่แล้ว และเดโมออฟไลน์ไม่ใช่ชุดทดสอบความสอดคล้องของโพรโทคอลเหล่านั้น
คำถามที่พบบ่อย
Proof21 ควรแทนรูปแบบใบรับเดิมทุกชนิดหรือไม่?
ไม่ ใช้ซ้ำเป็นค่าเริ่มต้นเมื่อรูปแบบเหมาะกับข้อกล่าวอ้างที่ต้องการ อะแดปเตอร์ควรคงหลักฐานเดิมและเพิ่มการผูกเวิร์กโฟลว์หรือการประเมินอย่างชัดเจน ไม่ใช่สร้างซองซ้ำเพียงเพื่อแบรนด์
ใส่คำตอบ RPC ในรายงานลงนามแล้วกลายเป็นสถานะที่ตรวจอย่างอิสระหรือไม่?
ไม่ ลายเซ็นรับรองสิ่งที่ผู้ออกรายงานลงนามได้ แต่คำตอบ RPC ยังเป็นการสังเกตที่มีที่มาและข้อจำกัดของตน เว้นแต่มีการตรวจเพิ่มจริงและบันทึกไว้
แยกวิเคราะห์รูปแบบพันธมิตรได้พอจะอ้างว่าเข้ากันได้เต็มหรือไม่?
ไม่ ความเข้ากันได้ต้องระบุรุ่นและขอบเขต ครอบคลุมความหมายที่จำเป็น และมีทดสอบรองรับ การแยกวิเคราะห์ ตรวจลายเซ็น ประเมินข้อกล่าวอ้าง และยอมรับท้องถิ่นเป็นความสามารถแยกกัน
<!-- p21-ecosystem-payments-v09 -->
การเข้าถึงข้ามเชนและการจ่ายตามระบบนิเวศ
NAT ดั้งเดิมและ Base USDC ยังเป็นข้อกำหนดเริ่มต้น NAT ยังมีสินทรัพย์ตัวแทนที่ระบุได้บน Ethereum, Solana และ BNB Smart Chain ต้องอนุมัติสัญญาหรือ mint และการจับคู่บริดจ์แต่ละรายการก่อนรับเงิน การใช้หลายเชนไม่ได้ลบสมมติฐานความเชื่อถือของแหล่งข้อมูล
ขอบเขต Binance B402 รวม USDT, USDC, USD1 และ U บน BNB Smart Chain ตามวิธีที่แต่ละสินทรัพย์รองรับ PayAI และ Coinbase ใช้คู่เครือข่าย/สินทรัพย์ที่ทดสอบแล้ว ส่วน Virtuals ACP รักษาวงจรจ่ายงาน USDC MCP และ A2A ไม่บังคับสกุลชำระเงิน ทางเลือกการจ่ายและการแลกเงินคลังยังแยกจากการตรวจหลักฐาน Bitcoin/DMT ทั้งหมดเป็นเป้าหมายตามข้อกำหนด ไม่ใช่บริการรับเงินที่เปิดแล้ว
Binance assets and methods · Binance integration · Coinbase facilitator · PayAI assets · Virtuals ACP · NAT Ethereum listing · NAT Solana record · NAT BNB Chain contract
<!-- p21-enforcement-v10 -->
อัปเดต · interoperability ต้องมี authorization boundary ด้วย
Portable evidence มีค่ามากขึ้นเมื่อ execution authority ชัดเจน P21 แยก evidence-only verification จาก optional action-bound execution authorization หลักการเดียวกันใช้กับ TAP threshold signer, smart account, MPC/HSM หรือ API capability proxy ได้โดยไม่อ้างว่าระบบเหล่านั้นมี consensus เดียวกัน
Consumer decisions เป็น signed artifact ที่พกพาได้เช่นกัน การ reject ไม่เขียนทับ settlement/evaluation ที่เป็นอิสระ และ signed decisions ที่ขัดกันอาจกลายเป็น equivocation evidence แทนการยุบให้เป็น reputation score ที่แก้ไขได้ง่าย