# ทำงานร่วมกันโดยไม่ลบความหมายของหลักฐาน **บันทึกการออกแบบโพรโทคอล · 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 ยังเป็นการสังเกตที่มีที่มาและข้อจำกัดของตน เว้นแต่มีการตรวจเพิ่มจริงและบันทึกไว้ ### แยกวิเคราะห์รูปแบบพันธมิตรได้พอจะอ้างว่าเข้ากันได้เต็มหรือไม่? ไม่ ความเข้ากันได้ต้องระบุรุ่นและขอบเขต ครอบคลุมความหมายที่จำเป็น และมีทดสอบรองรับ การแยกวิเคราะห์ ตรวจลายเซ็น ประเมินข้อกล่าวอ้าง และยอมรับท้องถิ่นเป็นความสามารถแยกกัน ## การเข้าถึงข้ามเชนและการจ่ายตามระบบนิเวศ 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](https://developers.binance.com/en/docs/products/onchainpay-x402/basics/9.supported-payment-methods) · [Binance integration](https://developers.binance.com/en/docs/products/onchainpay-x402/introduction) · [Coinbase facilitator](https://docs.cdp.coinbase.com/x402/seller/facilitator) · [PayAI assets](https://docs.payai.network/x402/reference) · [Virtuals ACP](https://os.virtuals.io/acp/concepts) · [NAT Ethereum listing](https://www.bitmart.com/en-US/support/articles/7923014477723/360001026214/49446319153179) · [NAT Solana record](https://solscan.io/token/FbKRaqBzupLry3V7QujpNghwrHgxutB4MY11M8aeyVa1) · [NAT BNB Chain contract](https://bscscan.com/token/0x600e3b55d5368c32a94f9372563318adb6a3f882) ## อัปเดต · 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 ที่แก้ไขได้ง่าย ## เอกสารต้นทางและอ่านต่อ - [1: x402 — ข้อเสนอและใบรับที่ลงนาม](https://docs.x402.org/extensions/offer-receipt) - [2: PEAC — บันทึกปฏิสัมพันธ์และขอบเขตหลักฐาน](https://www.peacprotocol.org/) - [3: RFC 8785 — JSON Canonicalization Scheme](https://www.rfc-editor.org/rfc/rfc8785.html) - [4: CAIP-2 — ข้อกำหนดตัวระบุบล็อกเชน](https://standards.chainagnostic.org/CAIPs/caip-2) - [5: CAIP-19 — ข้อกำหนดประเภทและตัวระบุสินทรัพย์](https://standards.chainagnostic.org/CAIPs/caip-19) - [ขอบเขตการเชื่อมต่อการชำระเงิน Proof21](https://proof21.xyz/th/docs/integrations/payments/)