การชำระบัญชีไม่ใช่ทั้งเวิร์กโฟลว์

บันทึกการออกแบบ · 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 — ข้อกำหนดตัวระบุบล็อกเชน
• 3: CAIP-19 — ข้อกำหนดประเภทและตัวระบุสินทรัพย์

<!-- p21-ecosystem-payments-v09 -->

สเตเบิลคอยน์ให้ตรงกับแต่ละการเชื่อมต่อ

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

สินทรัพย์ BSC mainnet ที่ Binance ระบุใช้ 18 ทศนิยม รวม USDC และ USDT ขณะที่ USDC บน Base ใช้อีกสัญญาและ 6 ทศนิยม ห้ามคัดลอกสมมติฐานทศนิยมข้ามเครือข่ายหรือสับสน testnet กับ mainnet อย่าเพิ่ม FDUSD หรือเหรียญอื่นเพียงเพราะเกี่ยวข้องกับตลาดนั้น ต้องตรวจผลิตภัณฑ์การชำระเงินจริง

ก่อนประกาศว่าจ่ายได้ ให้ใช้เฉพาะส่วนที่ตรงกันระหว่างรายการอนุญาตของเจ้าของกับความสามารถปัจจุบันของผู้ให้บริการที่ตั้งค่าไว้ ตรึงเครือข่าย โทเคน ทศนิยม วิธี และผู้รับ ตรวจที่อยู่ spender/signer ที่อนุญาต และรักษาข้อมูลการอนุญาตที่จำเป็น การรีเฟรชข้อมูลต้องไม่ขยายสิทธิ์เงียบ ๆ การใช้ B402 production ต้องผ่านการรับเข้าโดยผู้ให้บริการ ทุกช่องทางของ P21 ยังปิดจนกว่าจะพัฒนา ทดสอบการชำระบัญชี และอนุมัติครบ

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 -->

อัปเดต · 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
• ตรวจ ประเมิน ยอมรับ
• คู่มือทดลองกับพันธมิตร
• 1: ข้อเสนอและใบรับรอง x402 ที่ลงนาม