X402 चे स्पष्टीकरण: AI एजंट्ससाठी HTTP नेटिव्ह मायक्रोपेमेंट्स (Micropayments)
X402 स्पेसिफिकेशन (spec) मानक HTTP 402 Payment Required स्टेटसचा वापर करून एका सामान्य API कॉलचे ऑन-चेन मायक्रोपेमेंटमध्ये रूपांतर करते. AI एजंट्स आता मानवी हस्तक्षेपाशिवाय LLM क्वेरीज किंवा डेटा फीड्ससाठी शुल्क भरू शकतात आणि प्रदाते (providers) स्वतःची कस्टमाइझ्ड इनव्हॉइसिंग सिस्टम न बनवता प्रत्येक विनंतीसाठी (per request) शुल्क आकारू शकतात.
AI एजंट्सना पेमेंट प्रोटोकॉलची गरज का आहे?
स्वायत्त एजंट्स (Autonomous agents) लँग्वेज मॉडेल्स, वेब-सर्च टूल्स आणि प्रोप्रायटरी डेटा सोर्सेस एकत्र जोडतात. यातील प्रत्येक प्रक्रियेचा खर्च येतो—उदा. मॉडेलसाठी प्रति-टोकन शुल्क किंवा मार्केट-डेटा API साठी प्रति-कॉल शुल्क. आजचे बिझनेस मॉडेल्स सबस्क्रिप्शन अकाउंट्सशी जोडलेल्या API कीज, मॅन्युअल क्रेडिट टॉप-अप्स किंवा नंतर येणाऱ्या बिलांवर (post-hoc billing) अवलंबून आहेत. या पद्धती स्वायत्त एजंट्सच्या "मानवी हस्तक्षेपाशिवाय" (no-human) चालण्याच्या आश्वासनाला बाधा आणतात आणि प्रदात्यांसाठी कार्यात्मक ओझे (operational overhead) वाढवतात.
X402 एक मध्यम मार्ग प्रदान करते: एक रिक्वेस्ट-रिस्पॉन्स फ्लो जो इतर कोणत्याही HTTP कॉलसारखाच दिसतो, परंतु त्यामध्ये पब्लिक ब्लॉकचेनवर नोंदवलेला एक इन-बिल्ट पेमेंट टप्पा असतो. यासाठी फक्त एकच अट आहे की क्लायंट सर्व्हरने निर्दिष्ट केलेल्या चेनवर ट्रान्झॅक्शन साइन (sign) आणि ब्रॉडकास्ट (broadcast) करू शकला पाहिजे.
X402 हँडशेक (handshake) तपशीलवार
- सुरुवातीची विनंती (Initial request) – एजंट पेड एंडपॉइंटवर सामान्य GET किंवा POST पाठवतो. यासाठी कोणत्याही विशेष हेडर्सची गरज नसते.
- सर्व्हर 402 सह उत्तर देतो – प्रतिसादात (response) स्टेटस 402 आणि एक JSON बॉडी असते ज्यामध्ये खालील गोष्टींची यादी असते:
amount– सर्व्हर अपेक्षित असलेले शुल्क, सर्वात लहान टोकन युनिटमध्ये;token– ERC-20 (किंवा समकक्ष) कॉन्ट्रॅक्ट ॲड्रेस;chain– ज्या ब्लॉकचेनवर पेमेंट नोंदवले जाणे आवश्यक आहे त्याचा आयडेंटिफायर;- पर्यायी
nonce– एक युनिक व्हॅल्यू जी रिप्ले अटॅक्स (replay attacks) रोखते.
- क्लायंट पेमेंटची तयारी करतो – एजंट त्याच्या पॉलिसीनुसार (उदा. फक्त विश्वसनीय चेन्स) टोकन ॲड्रेस आणि चेन तपासतो. त्यानंतर तो सर्व्हरने दिलेल्या ॲड्रेसवर आवश्यक रक्कम हस्तांतरित करणारा एक ट्रान्झॅक्शन तयार करतो, त्याला त्याच्या प्रायव्हेट कीने (private key) साइन करतो आणि तो ब्रॉडकास्ट करतो.
- पेमेंट हॅश सबमिशन (Payment hash submission) – जेव्हा ट्रान्झॅक्शन हॅश उपलब्ध होतो, तेव्हा क्लायंट मूळ विनंती पुन्हा करतो, यावेळी
X-Paymentहेडर जोडतो ज्यामध्ये तो हॅश असतो. पेलोड (payload) तसाच राहतो. - सर्व्हर ऑन-चेन पडताळणी करतो – सर्व्हर ब्लॉकचेनवर रक्कम, टोकन, चेन आणि नॉनस (nonce) यांच्याशी जुळणारा कन्फर्म ट्रान्सफर शोधतो. जर त्याला मॅच सापडली, तर तो 200 OK स्टेटससह विनंती केलेला डेटा परत करतो.
कस्टम हेडर्सना सपोर्ट करणारी आणि ब्लॉकचेन SDK कॉल करू शकणारी कोणतीही HTTP क्लायंट लायब्ररी हे टप्पे पूर्ण करू शकते. यासाठी कोणत्याही नवीन ट्रान्सपोर्ट प्रोटोकॉल किंवा कस्टम सॉकेट लेयरची आवश्यकता नाही.
लक्षात ठेवण्यासारखे ट्रेड-ऑफ्स (Trade-offs)
- लॅटन्सी (Latency) – पब्लिक-चेन कन्फर्मेशनमुळे विलंब होतो.
- गॅस खर्च (Gas costs) – स्वस्त चेन्स देखील गॅस आकारतात; $0.001 पेक्षा कमी पेमेंट आर्थिकदृष्ट्या परवडणारे नसू शकते.
- जटिलता (Complexity) – एजंट्सना अयशस्वी ट्रान्झॅक्शन्स आणि चेन रिऑर्गनायझेशन (chain reorganizations) हाताळावे लागतील; यासाठी मजबूत 'रिट्राय लॉजिक' (retry logic) असणे आवश्यक आहे.
- सुरक्षा (Security) – नॉनस (nonce) रिप्ले अटॅक्स रोखतो, परंतु एजंट्सना तरीही प्रायव्हेट की सुरक्षित ठेवणे आणि त्यांचा असंबद्ध सेवांसाठी पुनर्वापर करणे टाळणे आवश्यक आहे.
