Title: X402 వివరణ: AI ఏజెంట్ల కోసం HTTP నేటివ్ మైక్రోపేమెంట్స్ (Micropayments)

X402 స్పెసిఫికేషన్, సాధారణ API కాల్‌ను ఆన్-చైన్ మైక్రోపేమెంట్‌గా మార్చడానికి ప్రామాణిక HTTP 402 Payment Required స్టేటస్‌ను తిరిగి ఉపయోగిస్తుంది. AI ఏజెంట్లు ఇప్పుడు మనుషుల ప్రమేయం లేకుండానే LLM క్వెరీల కోసం లేదా డేటా ఫీడ్‌ల కోసం ఫీజులను చెల్లించగలవు, మరియు సర్వీస్ ప్రొవైడర్లు ప్రత్యేకమైన ఇన్‌వాయిసింగ్ సిస్టమ్‌ను నిర్మించాల్సిన అవసరం లేకుండా ప్రతి రిక్వెస్ట్‌కు ఛార్జ్ చేయవచ్చు.

AI ఏజెంట్లకు పేమెంట్ ప్రోటోకాల్ ఎందుకు అవసరం?

స్వయంప్రతిపత్తి కలిగిన (Autonomous) ఏజెంట్లు లాంగ్వేజ్ మోడల్స్, వెబ్-సెర్చ్ టూల్స్ మరియు ప్రొప్రైటరీ డేటా సోర్స్‌లను ఒకదానితో ఒకటి అనుసంధానిస్తాయి. ప్రతి అనుసంధానానికి కొంత ఖర్చు అవుతుంది—మోడల్ కోసం పర్-టోకెన్ ఫీజులు లేదా మార్కెట్-డేటా API కోసం పర్-కాల్ ఛార్జీలు. ప్రస్తుత బిజినెస్ మోడల్స్ సబ్‌స్క్రిప్షన్ అకౌంట్‌లకు అనుసంధానించబడిన API కీలు, మాన్యువల్ క్రెడిట్ టాప్-అప్‌లు లేదా పోస్ట్-హాక్ బిల్లింగ్‌పై ఆధారపడి ఉన్నాయి. ఈ పద్ధతులు స్వయంప్రతిపత్తి కలిగిన ఏజెంట్ల యొక్క "నో-హ్యూమన్" (మనుషుల అవసరం లేని) వాగ్దానాన్ని దెబ్బతీస్తాయి మరియు ప్రొవైడర్లకు నిర్వహణ భారాన్ని (operational overhead) పెంచుతాయి.

X402 ఒక మధ్యేమార్గం предлагает: ఇది ఇతర HTTP కాల్‌ల వలె కనిపించే రిక్వెస్ట్-రెస్పాన్స్ ఫ్లో, కానీ ఇందులో పబ్లిక్ బ్లాక్‌చైన్‌లో నమోదయ్యే ఇన్-బిల్ట్ పేమెంట్ స్టెప్ ఉంటుంది. క్లయింట్ సర్వర్ సూచించిన చైన్‌పై లావాదేవీని (transaction) సైన్ చేసి బ్రాడ్‌కాస్ట్ చేయగలగడం మాత్రమే దీనికి ఏకైక అవసరం.

X402 హ్యాండ్‌షేక్ (handshake) వివరంగా

  1. ప్రారంభ రిక్వెస్ట్ (Initial request) – ఏజెంట్ పెయిడ్ ఎండ్‌పాయింట్‌కు సాధారణ GET లేదా POST రిక్వెస్ట్‌ను పంపుతుంది. ఎటువంటి ప్రత్యేక హెడర్‌లు అవసరం లేదు.
  2. సర్వర్ 402తో సమాధానం ఇస్తుంది – రెస్పాన్స్‌లో స్టేటస్ 402 మరియు ఈ క్రింది వాటిని జాబితా చేసే JSON బాడీ ఉంటుంది:
    • amount – సర్వర్ ఆశించే ఫీజు, అతి చిన్న టోకెన్ యూనిట్‌లో;
    • token – ERC-20 (లేదా సమానమైన) కాంట్రాక్ట్ అడ్రస్;
    • chain – పేమెంట్ నమోదు చేయవలసిన బ్లాక్‌చైన్ ఐడెంటిఫైయర్;
    • ఆప్షనల్ nonce – రీప్లే అటాక్స్‌ను నిరోధించే ఒక ప్రత్యేక విలువ.
  3. క్లయింట్ పేమెంట్‌ను సిద్ధం చేస్తుంది – ఏజెంట్ తన పాలసీని (ఉదాహరణకు, కేవలం నమ్మదగిన చైన్‌లు మాత్రమే) బట్టి టోకెన్ అడ్రస్ మరియు చైన్‌ను తనిఖీ చేస్తుంది. ఆ తర్వాత సర్వర్ అందించిన అడ్రస్‌కు అవసరమైన మొత్తాన్ని బదిలీ చేసే లావాదేవీని (transaction) సృష్టించి, దానిని తన ప్రైవేట్ కీతో సైన్ చేసి, బ్రాడ్‌కాస్ట్ చేస్తుంది.
  4. పేమెంట్ హాష్ సబ్మిషన్ – ట్రాన్సాక్షన్ హాష్ అందుబాటులోకి వచ్చినప్పుడు, క్లయింట్ అసలు రిక్వెస్ట్‌ను మళ్ళీ పంపుతుంది, ఈసారి హాష్‌ను కలిగి ఉన్న X-Payment హెడర్‌ను జోడిస్తుంది. పేలోడ్ (payload) మారదు.
  5. సర్వర్ ఆన్-చైన్‌లో వెరిఫై చేస్తుంది – సర్వర్ అమౌంట్, టోకెన్, చైన్ మరియు నాన్స్ (nonce) కు సరిపోయే కన్ఫర్మ్డ్ ట్రాన్స్‌ఫర్‌ కోసం బ్లాక్‌చైన్‌లో వెతుకుతుంది. ఒకవేళ సరిపోలిక దొరికితే, అది 200 OK స్టేటస్‌తో కోరిన డేటాను తిరిగి పంపుతుంది.

కస్టమ్ హెడర్‌లను సపోర్ట్ చేసే మరియు బ్లాక్‌చైన్ SDKని కాల్ చేయగల ఏ HTTP క్లయింట్ లైబ్రరీ అయినా ఈ దశలను నిర్వహించగలదు. దీనికి కొత్త ట్రాన్స్‌పోర్ట్ ప్రోటోకాల్ లేదా కస్టమ్ సాకెట్ లేయర్ అవసరం లేదు.

గుర్తుంచుకోవలసిన అంశాలు (Trade-offs)

  • లేటెన్సీ (Latency) – పబ్లిక్-చైన్ కన్ఫర్మేషన్ వల్ల ఆలస్యం జరుగుతుంది.
  • గ్యాస్ ఖర్చులు (Gas costs) – చౌకైన చైన్‌లు కూడా గ్యాస్ ఛార్జ్ చేస్తాయి; $0.001 కంటే తక్కువ పేమెంట్లు ఆర్థికంగా లాభదాయకం కాకపోవచ్చు.
  • సంక్లిష్టత (Complexity) – ఏజెంట్లు విఫలమైన లావాదేవీలు మరియు చైన్ రీఆర్గనైజేషన్‌లను (chain reorganizations) హ్యాండిల్ చేయాలి; బలమైన రీట్రై లాజిక్ (retry logic) తప్పనిసరి.
  • భద్రత (Security) – నాన్స్ (nonce) రీప్లే అటాక్స్‌ను నిరోధిస్తుంది, కానీ ఏజెంట్లు ఇప్పటికీ ప్రైవేట్ కీలను సురక్షితంగా ఉంచుకోవాలి మరియు సంబంధం లేని సర్వీసుల కోసం వాటిని మళ్ళీ మళ్ళీ ఉపయోగించకుండా జాగ్రత్త వహించాలి.