Title: อธิบาย X402: การชำระเงินรายย่อยแบบ Native บน HTTP สำหรับ AI Agents

ข้อกำหนด (spec) ของ X402 นำสถานะ HTTP 402 Payment Required มาตรฐานมาใช้ใหม่ เพื่อเปลี่ยนการเรียก API ปกติให้เป็นการชำระเงินรายย่อย (micropayment) บนเชน (on-chain) ตอนนี้ AI agents สามารถชำระค่าธรรมเนียมสำหรับการสอบถาม LLM หรือข้อมูลฟีด (data feeds) ได้โดยไม่ต้องผ่านมนุษย์ และผู้ให้บริการสามารถเรียกเก็บเงินตามจำนวนการเรียกใช้งาน (per request) ได้โดยไม่ต้องสร้างระบบออกใบแจ้งหนี้ขึ้นมาเอง

ทำไม AI agents จึงต้องการโปรโตคอลการชำระเงิน

Autonomous agents ทำงานโดยการเชื่อมโยงโมเดลภาษา (language models), เครื่องมือค้นหาเว็บ (web-search tools) และแหล่งข้อมูลที่เป็นกรรมสิทธิ์ (proprietary data sources) เข้าด้วยกัน ซึ่งการเชื่อมโยงแต่ละครั้งมีต้นทุน ไม่ว่าจะเป็นค่าธรรมเนียมต่อโทเคน (per-token fees) สำหรับโมเดล หรือค่าบริการต่อการเรียกใช้งาน (per-call charges) สำหรับ market-data API โมเดลธุรกิจในปัจจุบันยังคงพึ่งพา API keys ที่ผูกกับบัญชีสมาชิก (subscription accounts), การเติมเครดิตด้วยตนเอง หรือการเรียกเก็บเงินย้อนหลัง ซึ่งวิธีการเหล่านี้ขัดกับคำมั่นสัญญาเรื่อง "การทำงานโดยไม่ต้องมีมนุษย์" (no-human) ของ autonomous agents และเป็นการเพิ่มภาระด้านการดำเนินงาน (operational overhead) ให้กับผู้ให้บริการ

X402 นำเสนอทางออกสายกลาง นั่นคือกระบวนการ request-response ที่ดูเหมือนการเรียก HTTP ทั่วไป แต่มีขั้นตอนการชำระเงินที่ติดตั้งมาในตัวและบันทึกไว้บนบล็อกเชนสาธารณะ (public blockchain) ข้อกำหนดเพียงอย่างเดียวคือ client ต้องสามารถลงนาม (sign) และประกาศ (broadcast) รายการธุรกรรมบนเชนที่เซิร์ฟเวอร์ระบุได้

รายละเอียดขั้นตอนการทำ Handshake ของ X402

  1. Initial request – agent ส่งคำขอ GET หรือ POST ปกติไปยัง endpoint ที่ต้องชำระเงิน โดยไม่จำเป็นต้องใช้ header พิเศษใดๆ
  2. Server replies with 402 – การตอบกลับจะมาพร้อมกับสถานะ 402 และ JSON body ที่ระบุรายการดังนี้:
    • amount – ค่าธรรมเนียมที่เซิร์ฟเวอร์ต้องการ โดยระบุเป็นหน่วยย่อยที่สุดของโทเคน;
    • token – ที่อยู่สัญญา (contract address) ของ ERC-20 (หรือเทียบเท่า);
    • chain – ตัวระบุบล็อกเชนที่ต้องบันทึกการชำระเงิน;
    • optional nonce – ค่าที่ไม่ซ้ำกันเพื่อป้องกันการโจมตีแบบ replay attacks.
  3. Client prepares payment – agent ตรวจสอบที่อยู่โทเคนและเชนตามนโยบายของตน (เช่น เฉพาะเชนที่เชื่อถือได้เท่านั้น) จากนั้นจึงสร้างธุรกรรมเพื่อโอนจำนวนเงินที่กำหนดไปยังที่อยู่ที่เซิร์ฟเวอร์ระบุ ลงนามด้วย private key ของตนเอง และทำการ broadcast ธุรกรรมนั้น
  4. Payment hash submission – เมื่อได้ transaction hash แล้ว client จะส่งคำขอเดิมซ้ำอีกครั้ง โดยครั้งนี้จะเพิ่ม header X-Payment ที่บรรจุ hash ลงไป ส่วน payload ยังคงเดิมไม่เปลี่ยนแปลง
  5. Server verifies on-chain – เซิร์ฟเวอร์จะตรวจสอบบนบล็อกเชนเพื่อหาการโอนเงินที่ได้รับการยืนยันแล้ว ซึ่งต้องตรงกับ amount, token, chain และ nonce หากพบข้อมูลที่ตรงกัน เซิร์ฟเวอร์จะส่งข้อมูลที่ร้องขอคืนกลับมาพร้อมสถานะ 200 OK

HTTP client library ใดๆ ที่รองรับ custom headers และสามารถเรียกใช้งาน blockchain SDK ได้ ก็สามารถดำเนินการตามขั้นตอนเหล่านี้ได้ โดยไม่จำเป็นต้องใช้โปรโตคอลการรับส่งข้อมูล (transport protocol) ใหม่ หรือเลเยอร์ socket แบบกำหนดเอง

ข้อควรพิจารณา (Trade-offs)

  • Latency – การยืนยันธุรกรรมบนเชนสาธารณะทำให้เกิดความล่าช้า
  • Gas costs – แม้แต่เชนราคาถูกก็ยังมีค่า gas; การชำระเงินที่ต่ำกว่า $0.001 อาจไม่คุ้มค่าในเชิงเศรษฐกิจ
  • Complexity – agent ต้องจัดการกับธุรกรรมที่ล้มเหลวและการจัดเรียงบล็อกใหม่ของเชน (chain reorganizations); จึงจำเป็นต้องมีตรรกะการลองใหม่ (retry logic) ที่แข็งแกร่ง
  • Security – nonce ช่วยป้องกัน replay attacks แต่ agent ยังคงต้องรักษาความปลอดภัยของ private keys และหลีกเลี่ยงการนำไปใช้ซ้ำกับบริการอื่นๆ ที่ไม่เกี่ยวข้องกัน