# การชำระบัญชีไม่ใช่ทั้งเวิร์กโฟลว์ **บันทึกการออกแบบ · 7 กันยายน 2026** ลองนึกถึงเอเจนต์ที่จ้างบริการให้จ่ายเงิน เรื่องนี้มีการจ่ายอย่างน้อยสองครั้ง: ค่าจ้างบริการ และเงินที่บริการถูกสั่งให้จ่าย ใบรับรองของครั้งแรกไม่ใช่หลักฐานโดยอัตโนมัติว่าครั้งที่สองสำเร็จ ความแตกต่างนี้เป็นจุดเริ่มต้นของโปรไฟล์ตรวจการเงิน Proof21 ไม่ใช่คำกล่าวว่าบล็อกเชนต้องการอีกชั้นมาบอกว่ามีการโอนดั้งเดิมหรือไม่ คุณค่าที่เสนอคือเชื่อมหลักฐานข้ามเวิร์กโฟลว์ครบถ้วนที่ตกลงไว้ ## คำถามสามข้อที่ต่างกัน **ขอให้ทำอะไร?** คำสั่งระบุงาน เครือข่าย สินทรัพย์แน่นอน ผู้รับ จำนวน และข้อจำกัด ระบบรอบข้างต้องยืนยันความแท้และอำนาจที่ใช้ได้ รายงาน P21 ห้ามสร้างทั้งสองสิ่งเอง **จ่ายเงินเพื่ออะไร?** หลักฐานทางพาณิชย์ระบุการใช้บริการและการชำระเพื่อจ้างผู้ให้บริการ ส่วนขยายข้อเสนอและใบรับรองที่ลงนามของ x402 เป็นแหล่งหนึ่ง กฎตรวจของมันยังมีผล [1] **เกิดการดำเนินการอะไรจริง?** ต้องประเมินธุรกรรมในบริบทเชนที่ถูกต้อง ธุรกรรมล้มเหลว สัญลักษณ์เหมือนกันแต่คนละสัญญาโทเคน ผู้รับผิด หรือความสิ้นสุดไม่พอ ห้ามถูกเปลี่ยนเป็นความสำเร็จเงียบๆ กระเป๋าเดียวอาจปรากฏในหลายบันทึก แต่ไม่ได้ทำให้บันทึกเท่ากันหรือพิสูจน์ว่าเป็นงานเดียวกัน ## รายงานที่มีประโยชน์ต้องเจาะจง ผล P21 ที่เสนอไม่บอกว่า “เอเจนต์นี้ปลอดภัย” แต่บอกว่าหลักฐานที่ให้มารองรับคำกล่าวอ้างเฉพาะภายใต้โปรไฟล์ตรวจที่ระบุหรือไม่ รายงานควรแสดงต้นฉบับ สิ่งที่คาดว่าจะผูกกัน เวอร์ชันการประเมิน และสมมติฐานแหล่งข้อมูล ลายเซ็นรับรองรายงานที่มีผลล้มเหลวได้ ข้อสังเกต RPC จากผู้ให้บริการไม่เหมือนการตรวจเชนด้วยตนเอง ข้อมูลที่ขาดควรคงสถานะสรุปไม่ได้ ไม่ใช่ให้ LLM เติม ความต่างเหล่านี้มีประโยชน์แม้เวิร์กโฟลว์ไม่แตะ Bitcoin การรองรับ Bitcoin/DMT เป็นความสามารถหลัก ไม่ใช่ทางอ้อมภาคบังคับสำหรับทุกคำขอ ## เริ่มข้างการควบคุมเดิม การทดลองแรกควรใช้โหมดเงา ขีดจำกัดกระเป๋า กฎลงนาม และการควบคุมชำระบัญชียังคงอยู่ P21 ให้ผลตรวจควบคู่และผู้รับอิสระทำซ้ำการตรวจที่รองรับ การทดลองสำเร็จเมื่อตรวจพบความไม่ตรงกันสำคัญ ลดงานกระทบยอด หรือให้หลักฐานที่คู่สัญญาใช้ได้ ไม่ใช่แค่ลงนามวัตถุ JSON ใหม่ ข้อมูลทดสอบชุดแรกที่วางแผนครอบคลุมเครือข่ายผิด สินทรัพย์และผู้รับผิด คำสั่งถูกแก้ หลักฐาน replay ธุรกรรมล้มเหลว ข้อสังเกตเก่า และข้อมูลไม่พร้อม นี่คือข้อกำหนดสร้างระบบ เว็บไซต์ไม่ได้อ้างว่ามีตัวตรวจที่เผยแพร่ผ่านทั้งหมดแล้ว ## ตัวอย่างการผูกข้อมูลอย่างเป็นรูปธรรม สมมติว่าคำสั่งสังเคราะห์กำหนดให้โอนหน่วยสาธิต 100 หน่วยไปยังซัพพลายเออร์ A หากมีทศนิยมหกตำแหน่ง จำนวนที่คาดหวังคือสตริงจำนวนเต็ม `100000000` ผู้ให้บริการเรียกเก็บค่าบริการอีกส่วนหนึ่ง ตัวเลขเหล่านี้ใช้แสดงความสัมพันธ์ทางบัญชีเท่านั้น ไม่ใช่โทเคนจริง ธุรกรรมบนเครือข่าย หรือราคาที่เสนอขาย ต่อมาผู้ให้บริการส่งใบรับค่าบริการที่มีลายเซ็นถูกต้อง พร้อมบันทึกธุรกรรมที่โอน 100 หน่วยไปยังซัพพลายเออร์ B การใช้บริการอาจเกิดขึ้นจริง แต่เงื่อนไขการจ่ายเงินยังไม่ผ่าน หากเปลี่ยนบันทึกเป็นซัพพลายเออร์ A แต่ใช้สินทรัพย์อีกชนิดที่มีสัญลักษณ์แสดงผลเหมือนกัน ก็ยังไม่ผ่านเช่นกัน ชื่อที่มนุษย์อ่านแล้วคล้ายกันไม่ทดแทนการผูกข้อมูลให้ตรงอย่างแน่นอน ตัวระบุเชนและตัวระบุสินทรัพย์แก้ปัญหาการตั้งชื่อคนละส่วน CAIP-2 และ CAIP-19 เป็นเอกสารต้นทางที่มีประโยชน์ แต่ไม่ใช่เครื่องมือตรวจสอบธุรกรรม [2][3] โปรไฟล์การตรวจสอบที่เสนอควรผูกตัวระบุการดำเนินการ ไดเจสต์ของคำสั่ง เครือข่ายที่คาดหวัง สินทรัพย์ที่แน่นอน ผู้รับ จำนวนเต็ม ผลการดำเนินการ จุดที่สังเกต และเวอร์ชันนโยบาย โดยเก็บใบรับบริการและหลักฐานการดำเนินการพื้นฐานแยกกัน คำอธิบายของเอเจนต์อาจช่วยให้มนุษย์เข้าใจความไม่ตรงกัน แต่ต้องไม่สร้างธุรกรรมที่ไม่มีหลักฐานขึ้นเอง หรือแก้ผู้รับที่ไม่ได้รับอนุญาตอย่างเงียบ ๆ ## ความล้มเหลวกับหลักฐานที่หายไปต้องมีเส้นทางต่างกัน บันทึกที่อยู่ในขอบเขตการรองรับและยืนยันได้เพียงพอว่าผู้รับผิดคน สามารถสนับสนุนผล `FAIL` ได้ แต่หากเรียกดูบันทึกไม่ได้ โดยปกติควรได้ `INDETERMINATE` ไม่ใช่สรุปว่าการจ่ายเงินไม่เคยเกิดขึ้น ความต่างนี้สำคัญต่อการปฏิบัติงาน เพราะการจ่ายซ้ำอัตโนมัติหลังหมดเวลาอาจทำให้จ่ายสองครั้ง บริการตรวจสอบควรแสดงขอบเขตของหลักฐาน แล้วให้ตัวควบคุมอีกส่วนที่ได้รับอนุญาตตัดสินใจว่าจะรอ ตรวจสอบเพิ่มเติม หรือทำซ้ำตามนโยบายป้องกันการดำเนินการซ้ำของแอปพลิเคชัน ความใหม่ของหลักฐานเป็นส่วนหนึ่งของคำถาม ไม่ใช่เพียงเวลาประทับตกแต่ง บันทึกที่สังเกตก่อนเหตุการณ์ที่เกี่ยวข้องยืนยันไม่ได้ว่าเหตุการณ์สำเร็จในภายหลัง เช่นเดียวกัน ธุรกรรมที่เคยผ่านนโยบายจำนวนการยืนยัน ณ จุดหนึ่งอาจต้องประเมินใหม่เมื่อพบการจัดระเบียบเชนใหม่ ควรเก็บการสังเกตทั้งสองครั้งพร้อมเหตุผล ไม่ใช่ทับผลเดิมด้วยสัญลักษณ์สีเขียวที่ไม่มีคำอธิบาย ## ผู้ใช้ผลอย่างอิสระควรทำซ้ำอะไรได้บ้าง โครงการนำร่องที่มีประโยชน์ควรให้ผู้ใช้ผลเข้าถึงคำสั่งต้นฉบับ เวอร์ชันโปรไฟล์ที่เลือก ไบต์หลักฐานที่แน่นอนหรือแหล่งอ้างอิงที่ได้รับอนุญาตให้เรียกดู และผลจากผู้จัดทำรายงาน ผู้ใช้ผลเริ่มจากระบุไบต์และผู้ลงนามที่กำลังตรวจสอบ จากนั้นทำการเปรียบเทียบที่รองรับซ้ำ แล้วจึงใช้นโยบายยอมรับของตนเอง ทั้งสองฝ่ายควรเห็นต่างเรื่องการยอมรับได้ โดยไม่ต้องอ้างว่าลายเซ็นของผู้จัดทำรายงานเสียหาย ชุดทดสอบนำร่องควรเปลี่ยนเงื่อนไขการผูกข้อมูลครั้งละหนึ่งอย่าง และบันทึกเหตุผลที่คาดหวัง เริ่มจากกรณีสังเคราะห์ที่ทราบว่าตรงกัน แล้วเปลี่ยนผู้รับ สินทรัพย์ เครือข่าย และจำนวนตามลำดับ แยกทดสอบข้อมูลเก่า การดำเนินการล้มเหลว การนำการดำเนินการเดิมมาใช้ซ้ำ และแหล่งหลักฐานที่หายไป รวมรายงานที่ลายเซ็นถูกต้องแต่ผลไม่ผ่านด้วย เพราะการปฏิเสธรายงานเชิงลบทุกฉบับขัดกับจุดประสงค์ของระบบ ต้องบอกให้ชัดว่าตรวจอะไรจริงแล้วและอะไรยังเป็นข้อกำหนดการออกแบบ วัดงานที่ลดลง ไม่ใช่แค่นับใบรับที่สร้างขึ้น ตัวชี้วัดที่มีประโยชน์คือผู้ปฏิบัติงานอีกคนค้นหาหลักฐานและอธิบายความไม่ตรงกันได้หรือไม่ โดยไม่ต้องให้เอเจนต์เดิมเล่าเหตุการณ์ใหม่ ห้ามนับชุดข้อมูลสังเคราะห์เป็นรายได้จากลูกค้าหรือการจ่ายเงินจริงที่สำเร็จ เดโมออฟไลน์ที่ดาวน์โหลดได้ของ Proof21 แสดงเพียงส่วนจำกัดของความแตกต่างเหล่านี้ ไม่ใช่อะแดปเตอร์ทางการเงินสำหรับใช้งานจริงที่เสนอไว้ ## คำถามที่พบบ่อย ### ใบรับบริการที่ถูกต้องพิสูจน์ว่าจ่ายเงินตามคำสั่งสำเร็จหรือไม่? ไม่ ใบรับอาจสนับสนุนว่ามีการใช้บริการตามกฎลายเซ็นและการตรวจสอบของใบรับนั้น แต่การจ่ายเงินตามคำสั่งเป็นอีกข้อกล่าวอ้างที่ต้องมีหลักฐานการดำเนินการผูกกับคำสั่ง ควรเก็บหลักฐานทั้งสองชิ้นแทนการขยายความหมายของใบรับเพียงชิ้นเดียว ### ผลที่ยังระบุไม่ได้ควรทำให้จ่ายเงินใหม่โดยอัตโนมัติหรือไม่? ไม่ควร หลักฐานที่ขาดกับการดำเนินการที่ล้มเหลวเป็นคนละสถานการณ์ การทำซ้ำต้องอยู่ภายใต้ตัวควบคุมที่ได้รับอนุญาตชัดเจนและมีมาตรการป้องกันการจ่ายซ้ำ ไม่ใช่ให้โมเดลภาษาอนุมานว่าหมดเวลาเท่ากับไม่มีอะไรเกิดขึ้น ### ทุกการตรวจสอบต้องใช้ Bitcoin หรือโทเคนใหม่หรือไม่? ไม่ การออกแบบตรวจสอบทางการเงินสามารถประเมินเวิร์กโฟลว์ที่รองรับโดยไม่เขียนข้อมูลใหม่ลง Bitcoin การผูกมัดข้อมูลแบบเลือกใช้และความสามารถ Bitcoin/DMT มีหน้าที่แยกกัน P21 ในที่นี้เป็นชื่อย่อของโครงการ ไม่ใช่โทเคนชำระเงินที่พร้อมใช้แล้ว ## เอกสารต้นทางเพิ่มเติม - [2: CAIP-2 — ข้อกำหนดตัวระบุบล็อกเชน](https://standards.chainagnostic.org/CAIPs/caip-2) - [3: CAIP-19 — ข้อกำหนดประเภทและตัวระบุสินทรัพย์](https://standards.chainagnostic.org/CAIPs/caip-19) ## สเตเบิลคอยน์ให้ตรงกับแต่ละการเชื่อมต่อ ขอบเขตหลักเริ่มต้นต้องมี NAT ดั้งเดิมและ USDC บน Base การเชื่อมต่อเชิงพาณิชย์เพิ่มเติมต้องเปิดพร้อมรายการอนุญาตสินทรัพย์ เครือข่าย และวิธีชำระเงินที่ชัดเจน ไม่สมมติว่าทุกระบบใช้สเตเบิลคอยน์เดียวกัน เอกสารผู้ให้บริการที่ตรวจเมื่อ 9 กันยายน 2026 ระบุเป้าหมายต่อไปนี้ ไม่ได้ยืนยันว่า P21 เปิดบริการเหล่านี้แล้ว | การเชื่อมต่อ | ขอบเขตการชำระเงิน | ขอบเขตวิธีการ | | --- | --- | --- | | Coinbase CDP / x402 | USDC บน Base ก่อน เครือข่ายอื่นต้องผ่านการทดสอบอะแดปเตอร์ | รักษารูปแบบที่รองรับและเครือข่าย/สัญญาที่แน่นอน | | Binance B402 / BNB Smart Chain | USDT, USDC, USD1 และ U ในขอบเขตเปิดตัว B402 | USDT/USDC ใช้ Permit2 ส่วน USD1/U รองรับ EIP-3009 ด้วย | | PayAI | USDC บน Solana และ EVM ที่อนุมัติ สินทรัพย์อื่นต้องตรวจความสามารถ | การรองรับเครือข่ายไม่เท่ากับรองรับทุกโทเคน | | Virtuals ACP | ค่าบริการ USDC ตามวงจรงาน | รักษาความหมายงาน เงินทุน และการชำระบัญชี ไม่แทนด้วย x402 ทั่วไป | | MCP / A2A | โปรโตคอลไม่บังคับเหรียญชำระเงิน | การสื่อสารและค้นพบบริการไม่เลือกหรืออนุญาตการจ่ายเงิน | สินทรัพย์ BSC mainnet ที่ Binance ระบุใช้ 18 ทศนิยม รวม USDC และ USDT ขณะที่ USDC บน Base ใช้อีกสัญญาและ 6 ทศนิยม ห้ามคัดลอกสมมติฐานทศนิยมข้ามเครือข่ายหรือสับสน testnet กับ mainnet อย่าเพิ่ม FDUSD หรือเหรียญอื่นเพียงเพราะเกี่ยวข้องกับตลาดนั้น ต้องตรวจผลิตภัณฑ์การชำระเงินจริง ก่อนประกาศว่าจ่ายได้ ให้ใช้เฉพาะส่วนที่ตรงกันระหว่างรายการอนุญาตของเจ้าของกับความสามารถปัจจุบันของผู้ให้บริการที่ตั้งค่าไว้ ตรึงเครือข่าย โทเคน ทศนิยม วิธี และผู้รับ ตรวจที่อยู่ spender/signer ที่อนุญาต และรักษาข้อมูลการอนุญาตที่จำเป็น การรีเฟรชข้อมูลต้องไม่ขยายสิทธิ์เงียบ ๆ การใช้ B402 production ต้องผ่านการรับเข้าโดยผู้ให้บริการ ทุกช่องทางของ P21 ยังปิดจนกว่าจะพัฒนา ทดสอบการชำระบัญชี และอนุมัติครบ [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) ## อัปเดต · signed rejection ไม่เขียนทับ settlement `REJECT` ของเอเจนต์ผู้รับไม่ใช่คำตัดสินของ ledger Proof21 แยก integrity, deterministic evaluation, settlement และ consumer decision ธุรกรรมยังคง `CONFIRMED` ได้แม้ผู้รับลงนาม `REJECT` ตาม policy ของตน ถ้าต้องการ accountability ที่ตรวจซ้ำได้ ผู้รับ commit acceptance-policy digest/version ก่อน action แล้วลงนาม decision receipt ภายหลัง ถ้า deterministic policy ให้ PASS จากหลักฐานครบแต่ decision ขัดกัน ผู้ตรวจอิสระเก็บ contradiction ได้; ถ้าพึ่ง private input ที่หาไม่ได้ ต้องเป็น `UNRESOLVED` ## อ่านต่อ - [แบบการตรวจการเงิน P21](https://proof21.xyz/th/docs/capabilities/check/) - [ตรวจ ประเมิน ยอมรับ](https://proof21.xyz/th/docs/protocol/verification/) - [คู่มือทดลองกับพันธมิตร](https://proof21.xyz/th/docs/partners/pilot/) - [1: ข้อเสนอและใบรับรอง x402 ที่ลงนาม](https://docs.x402.org/extensions/offer-receipt)