הסבר על X402: מיקרו-תשלומים מובני HTTP עבור סוכני AI

מפרט X402 משתמש מחדש בסטטוס HTTP 402 Payment Required הסטנדרטי כדי להפוך קריאת API רגילה למיקרו-תשלום על הרשת (on-chain). סוכני AI יכולים כעת להסדיר עמלות עבור שאילתות LLM או הזנות נתונים (data feeds) ללא צורך בבני אדם, וספקים יכולים לחייב עבור כל בקשה מבלי לבנות מערכת חשבוניות מותאמת אישית.

מדוע סוכני AI זקוקים לפרוטוקול תשלום

סוכנים אוטונומיים מחברים יחד מודלי שפה, כלי חיפוש באינטרנט ומקורות נתונים קנייניים. כל חיבור כזה כרוך בעלות – עמלות לפי טוקן עבור מודל או חיוב לפי קריאה עבור API של נתוני שוק. המודלים העסקיים של היום מסתמכים על מפתחות API הקשורים לחשבונות מנוי, טעינת קרדיט ידנית או חיוב בדיעבד (post-hoc billing). שיטות אלו שוברות את הבטחת ה-"ללא אדם" (no-human) של סוכנים אוטונומיים ומוסיפות עומס תפעולי לספקים.

X402 מציע פתרון ביניים: זרימת בקשה-תגובה (request-response flow) שנראית כמו כל קריאת HTTP אחרת, אך עם שלב תשלום מובנה המתועד בבלוקצ'יין ציבורי. הדרישה היחידה היא שהלקוח (client) יוכל לחתום ולשדר עסקה על הרשת (chain) שהשרת מציין.

תהליך ה-handshake של X402 בפירוט

  1. בקשה ראשונית – הסוכן שולח בקשת GET או POST רגילה לנקודת קצה (endpoint) בתשלום. אין צורך בכותרות (headers) מיוחדות.
  2. השרת משיב ב-402 – התגובה נושאת סטטוס 402 וגוף JSON המפרט:
    • amount – העמלה שהשרת מצפה לקבל, ביחידת הטוקן הקטנה ביותר;
    • token – כתובת החוזה של ה-ERC-20 (או מקביל לו);
    • chain – מזהה הבלוקצ'יין שבו יש לתעד את התשלום;
    • nonce אופציונלי – ערך ייחודי שמונע התקפות חזרה (replay attacks).
  3. הלקוח מכין את התשלום – הסוכן בודק את כתובת הטוקן ואת הרשת אל מול המדיניות שלו (למשל, רשתות מהימנות בלבד). לאחר מכן הוא יוצר עסקה המעבירה את הסכום הנדרש לכתובת שסיפק השרת, חותם עליה עם המפתח הפרטי שלו ומשדר אותה.
  4. שליחת ה-payment hash – כאשר ה-transaction hash זמין, הלקוח חוזר על הבקשה המקורית, והפעם מוסיף כותרת X-Payment המכילה את ה-hash. ה-payload נשאר ללא שינוי.
  5. השרת מאמת על הרשת – השרת מחפש בבלוקצ'יין העברה מאושרת התואמת את הסכום, הטוקן, הרשת וה-nonce. אם הוא מוצא התאמה, הוא מחזיר את הנתונים המבוקשים עם סטטוס 200 OK.

כל ספריית HTTP client התומכת בכותרות מותאמות אישית ויכולה לקרוא ל-blockchain SDK יכולה לבצע את השלבים הללו. אין צורך בפרוטוקול תעבורה (transport protocol) חדש או בשכבת socket מותאמת אישית.

פשרות (Trade-offs) שיש לקחת בחשבון

  • Latency – אישור על רשת ציבורית מוסיף עיכוב.
  • Gas costs – גם רשתות זולות גובות gas; תשלומים מתחת ל-$0.001 עשויים שלא להיות כלכליים.
  • Complexity – סוכנים חייבים לטפל בעסקאות שנכשלו ובשינויים במבנה הרשת (chain reorganizations); לוגיקת ניסיונות חוזרים (retry logic) חזקה היא הכרח.
  • Security – ה-nonce מונע התקפות חזרה, אך סוכנים עדיין צריכים להגן על מפתחות פרטיים ולהימנע משימוש חוזר בהם בשירותים שאינם קשורים.