साइन की गई रसीदों के साथ अपने API डेटा को प्रमाणित करना — भुगतान सत्यापन से परे

एजेंट-टू-एजेंट भुगतानों की नई दुनिया

पहली बार, AI एजेंट स्वायत्त रूप से चीजों के लिए भुगतान कर सकते हैं। x402 प्रोटोकॉल HTTP 402 Payment Required स्टेटस कोड का पुनः उपयोग करता है ताकि किसी क्लाइंट — चाहे मानव हो या कृत्रिम — को USDC स्टेबलकॉइन में प्रति API कॉल भुगतान करने, API keys को पूरी तरह से छोड़ने और कभी खाता न बनाने की अनुमति मिल सके।

यह वास्तव में चतुराई भरा है। लेकिन एक ऐसी समस्या है जिसके बारे में कोई तब तक बात नहीं करता जब तक कि कोई एजेंट डेटा पर कार्रवाई करना शुरू नहीं कर देता।

30 जून 2026 तक, हम एक मोड़ पर हैं। Large language models कार्यों को व्यवस्थित करने में अधिक समझदार हो रहे हैं, स्वायत्त एजेंटों को प्रोडक्शन में तैनात किया जा रहा है, और तुरंत सेवाओं के लिए भुगतान करने की क्षमता अनिवार्य होती जा रही है। फिर भी वर्तमान भुगतान प्रमाण — ब्लॉकचेन पर ट्रांजैक्शन — सौदे के केवल एक हिस्से की पुष्टि करता है: कि पैसे का लेनदेन हुआ। यह इस बारे में कुछ नहीं कहता कि बदले में आपको प्राप्त डेटा प्रामाणिक है या उसके साथ छेड़छाड़ की गई है।

एक एजेंट सही तरीके से भुगतान कर सकता है और फिर भी स्पूफ़ किए गए डेटा पर कार्रवाई कर सकता है।

भुगतान का प्रमाण डेटा को साबित नहीं करता है

मान लीजिए कि आपने एक ऐसा API बनाया है जो प्रति कॉल 0.05 USDC चार्ज करता है। ग्राहक का एजेंट आपके एंडपॉइंट को हिट करता है, x402 फ़्लो पूरा होता है, USDC ट्रांसफर होता है, और एजेंट को प्रतिक्रिया में डेटा मिलता है। आपका भुगतान सिस्टम यह साबित कर सकता है कि ट्रांजैक्शन ऑन-चेन हुआ था।

लेकिन किसने सत्यापित किया कि response body वास्तव में आपकी तरफ से आई है? ब्लॉकचेन ने नहीं। भुगतान रसीद इरादे का प्रमाण पत्र है, प्रामाणिकता का प्रमाण पत्र नहीं। नेटवर्क इंटरसेप्ट वाला हमलावर — या एजेंट और आपके API के बीच एक बग वाला प्रॉक्सी भी — संशोधित डेटा डाल सकता है और भुगतान प्रमाण का कोई मतलब नहीं रह जाता।

यह एक वास्तविक अंतर है, और बड़े पैमाने पर यह और भी बदतर हो जाता है। यदि एजेंट APIs में कॉल को श्रृंखला में जोड़ रहे हैं, और प्रत्येक विभिन्न प्रदाताओं से डेटा खरीद रहा है, तो उन्हें क्रिप्टोग्राफ़िक आश्वासन की आवश्यकता होती है कि जिसके लिए उन्होंने भुगतान किया है वही उन्हें मिला है। अन्यथा वे अंधेरे में तीर चला रहे हैं, ऐसे डेटा पर निर्णय ले रहे हैं जिसे वे सत्यापित नहीं कर सकते।

समाधान: साइन की गई रसीदें

इसका उपाय भुगतान प्रमाण को स्वयं डेटा से बाँधना है। जब आपका API भुगतान करने वाले ग्राहक को प्रतिक्रिया जारी करता है, तो आप अपनी private key से response body और पेमेंट transaction ID दोनों को साइन करते हैं। ग्राहक को वापस मिलता है:

1. स्वयं डेटा।
2. एक रसीद जो साबित करती है कि भुगतान ऑन-चेन हुआ।
3. आपका cryptographic सिग्नेचर जो दोनों को एक साथ बाँधता है।

अब एजेंट स्वतंत्र रूप से सत्यापित कर सकता है: यह डेटा इस API से आया है, यह भुगतान वास्तविक था, और वे मेल खाते हैं। सेटअप समय पर एक बार आपकी public key को सत्यापित करने के अलावा किसी अन्य विश्वास की आवश्यकता नहीं है।

यह कोई क्रांतिकारी नहीं है — signed receipts उतनी ही पुरानी हैं जितना कि RSA — लेकिन यह वह लापता टुकड़ा है जो x402 को एक भुगतान प्रिमिटिव से एक संपूर्ण सत्यापन प्रणाली में बदल देता है।

Express के साथ इसे बनाना

इसे कैसे सेट करें, यहाँ बताया गया है। आपको एक keypair (Ed25519 ठीक है), यह पता लगाने का एक तरीका कि कॉल का भुगतान कब किया गया है, और response पर हस्ताक्षर करने के लिए middleware की आवश्यकता होगी।

सबसे पहले, अपनी कुंजियाँ और निर्भरताएँ सेट करें:

npm install express tweetnacl base64-js axios

अपना keypair जनरेट करें और इसे सुरक्षित रूप से स्टोर करें (git में कभी नहीं):

const nacl = require('tweetnacl');
const base64js = require('base64-js');

const keyPair = nacl.sign.keyPair();
const publicKey = base64js.fromByteArray(keyPair.publicKey);
const secretKey = base64js.fromByteArray(keyPair.secretKey);

console.log('Public Key:', publicKey);
console.log('Secret Key:', secretKey);

इसके बाद, ऐसा middleware बनाएं जो पेमेंट चेक के बाद रिस्पॉन्स को इंटरसेप्ट करे:

const express = require('express');
const app = express();

const verifyPayment = async (req, res, next) => {
  const paymentTxId = req.headers['x-payment-tx-id'];
  
  if (!paymentTxId) {
    return res.status(402).json({
      error: 'Payment Required',
      message: 'Provide a payment transaction ID'
    });
  }
  
  // Verify the tx on chain (sketch version)
  const txValid = await verifyTransactionOnChain(paymentTxId, 'REPLACE_WITH_VAULT_REFERENCE');
  
  if (!txValid) {
    return res.status(402).json({ error: 'Invalid payment' });
  }
  
  req.paymentTxId = paymentTxId;
  next();
};

अब रिस्पॉन्स-साइनिंग middleware बनाएं:

const nacl = require('tweetnacl');
const base64js = require('base64-js');

const secretKey = base64js.toByteArray(process.env.API_SECRET_KEY);

const signResponse = (req, res, next) => {
  const originalJson = res.json.bind(res);
  
  res.json = function(data) {
    const payload = JSON.stringify({
      data: data,
      txId: req.paymentTxId,
      timestamp: Date.now()
    });
    
    const message = Buffer.from(payload);
    const signature = nacl.sign.detached(message, secretKey);
    const signatureBase64 = base64js.fromByteArray(signature);
    
    res.setHeader('X-Signature', signatureBase64);
    res.setHeader('X-Payload-Hash', payload);
    
    return originalJson({ data, receipt: { txId: req.paymentTxId, signature: signatureBase64 } });
  };
  
  next();
};

app.use(verifyPayment);
app.use(signResponse);

अंत में, एक एंडपॉइंट जोड़ें:

app.get('/data/:id', (req, res) => {
  const result = { userId: req.params.id, balance: 42, updated: '2026-06-30' };
  res.json(result);
});

app.listen(3000, () => console.log('Listening on :3000'));

क्लाइंट साइड पर, डेटा पर कार्रवाई करने से पहले सिग्नेचर सत्यापित करें:

const nacl = require('tweetnacl');
const base64js = require('base64-js');

const publicKey = base64js.toByteArray('REPLACE_WITH_YOUR_PUBLIC_KEY');

function verifyReceipt(response) {
  const signature = base64js.toByteArray(response.headers['x-signature']);
  const payload = response.headers['x-payload-hash'];
  const message = Buffer.from(payload);
  
  const isValid = nacl.sign.detached.verify(
    message,
    signature,
    publicKey
  );
  
  if (!isValid) throw new Error('Signature verification failed');
  return response.data;
}

const response = await fetch('http://app.example.com/data/user123', {
  headers: { 'X-Payment-Tx-Id': 'USDC_TXN_ABC123' }
});

const verified = verifyReceipt(response);
console.log('Trusted data:', verified);

प्रोडक्शन में यह क्यों मायने रखता है

यह पैटर्न कई चीजों का द्वार खोलता है। एजेंट अब उन APIs से विश्वासयोग्य तरीके से डेटा खरीद सकते हैं जिन्हें उन्होंने पहले कभी नहीं देखा है। ऑडिटर्स सत्यापित कर सकते हैं कि एक निर्णय श्रृंखला प्रामाणिक, भुगतान किए गए डेटा पर आधारित थी। और API प्रदाताओं को एक स्पष्ट, cryptographic प्रमाण मिलता है कि उन्होंने वह दिया जिसका उन्होंने वादा किया था।

यह स्केल भी करता है। एक सिग्नेचर एक रिस्पॉन्स को कवर करता है। यदि आपको लाखों कॉल के प्रमाण की आवश्यकता है, तो आप उन्हें अपने प्रदाता की ओर से एक Merkle tree में बैच कर सकते हैं और प्रति बैच एक अम्ब्रेला सिग्नेचर जारी कर सकते हैं। ग्राहक एक बार बैच रूट को सत्यापित करता है और उसके तहत हर चीज पर भरोसा करता है।

निष्कर्ष

x402 प्रोटोकॉल ने स्वायत्त एजेंट APIs के भुगतान पक्ष को हल कर दिया। साइन की गई रसीदें डेटा प्रामाणिकता पक्ष को हल करती हैं। साथ में, वे एजेंटों के लिए अविश्वासी स्रोतों से मजबूती से डेटा खरीदना और आत्मविश्वास के साथ उस पर कार्रवाई करना संभव बनाते हैं।

गुण

• एजेंट public key से परे API प्रदाता पर भरोसा किए बिना डेटा अखंडता की पुष्टि कर सकते हैं।
• भुगतान और डेटा क्रिप्टोग्राफ़िक रूप से बंधे हैं — आप एक के बिना दूसरे की जालसाजी नहीं कर सकते।
• Merkle trees या बैच सिग्नेचर के माध्यम से एकल कॉल से लेकर लाखों तक स्केल करता है।
• किसी नए इंफ्रास्ट्रक्चर की आवश्यकता नहीं है — केवल मानक क्रिप्टोग्राफी और मौजूदा ब्लॉकचेन।
• मौजूदा x402 भुगतान प्रवाह के साथ काम करता है।

दोष

• विलंबता जोड़ता है: प्रत्येक रिस्पॉन्स पर हस्ताक्षर होने चाहिए (हालांकि अधिकांश उपयोग के मामलों के लिए स्वीकार्य है)।
• प्रदाता पक्ष पर सुरक्षित कुंजी प्रबंधन की आवश्यकता होती है — लीक हुई secret keys विश्वास को अमान्य कर देती हैं।
• क्लाइंट्स को सिग्नेचर वेरिफिकेशन लागू करना होगा (शुरुआती लोगों के लिए मामूली नहीं है)।
• API प्रदाताओं को झूठे डेटा पर हस्ताक्षर करने से नहीं रोकता है (विश्वास public key में है, प्रदाता की ईमानदारी में नहीं)।
• API अनुबंध में जटिलता जोड़ता है — क्लाइंट और सर्वर को पेलोड प्रारूप पर सहमत होना होगा।

सावधानी

नाम app.example.com, REPLACE_WITH_VAULT_REFERENCE, REPLACE_WITH_YOUR_PUBLIC_KEY, और यहाँ दिखाए गए सभी transaction IDs प्लेसहोल्डर हैं। अपने कोड में secret keys, API secrets या वास्तविक क्रेडेंशियल्स को कभी भी हार्डकोड न करें। प्रोडक्शन में तैनात करने से पहले हमेशा स्थानीय टेस्ट वातावरण के साथ सिग्नेचर वेरिफिकेशन का परीक्षण करें। Private keys को सीक्रेट्स वॉल्ट (HashiCorp Vault, AWS Secrets Manager, या समान) में स्टोर करें, एनवायरनमेंट वेरिएबल्स या सोर्स कंट्रोल में कभी नहीं। अपने जोखिम पर आगे बढ़ें और वास्तविक भुगतानों को स्वीकार करने से पहले टेस्टनेट वातावरण में कार्यान्वयन को पूरी तरह से सत्यापित करें।

अक्सर पूछे जाने वाले प्रश्न

• क्या होगा यदि किसी API प्रदाता की private key के साथ समझौता हो जाता है?
• क्या मैं एक ही signed receipt में कई API कॉल को बैच कर सकता हूँ?
• मैं JavaScript के अलावा अन्य भाषाओं में सिग्नेचर को कैसे सत्यापित करूँ?
• क्या मुझे रिस्पॉन्स के हर फ़ील्ड पर हस्ताक्षर करने की आवश्यकता है या केवल डेटा पर?
• हस्ताक्षर करने और सिग्नेचर को सत्यापित करने का प्रदर्शन ओवरहेड क्या है?
• क्या यह उन APIs के साथ काम कर सकता है जो प्रति-कॉल के बजाय एक निश्चित सब्सक्रिप्शन चार्ज करते हैं?
• एजेंट प्रोडक्शन में सिग्नेचर वेरिफिकेशन विफलताओं को कैसे संभालते हैं?
• क्या Ed25519 एकमात्र साइनिंग एल्गोरिदम है जिसका मुझे उपयोग करना चाहिए, या अन्य भी स्वीकार्य हैं?

टैग्स

#x402 #web3 #api #usdc #cryptography #agents #authentication #blockchain