கையொப்பமிடப்பட்ட ரசீதுகள் மூலம் உங்கள் API தரவை மெய்ப்பித்தல் — கட்டணச் சரிபார்ப்பிற்கு அப்பால்

agent-to-agent கட்டணங்களின் புதிய உலகம்

முதன்முறையாக, AI ஏஜென்ட்களால் தன்னாட்சியாகப் பொருட்களுக்குக் கட்டணம் செலுத்த முடியும். x402 நெறிமுறை HTTP 402 Payment Required நிலை குறியீட்டை மீண்டும் பயன்படுத்தி, ஒரு கிளையண்ட் — மனிதராக இருந்தாலும் அல்லது செயற்கையானதாக இருந்தாலும் — USDC stablecoin-இல் API அழைப்புக்குக் கட்டணம் செலுத்தவும், API சாவிகளை முற்றிலுமாகத் தவிர்க்கவும், கணக்கை உருவாக்கவே தேவையில்லை என்ற நிலையையும் வழங்குகிறது.

இது உண்மையிலேயே புத்திசாலித்தனமானது. ஆனால் ஒரு ஏஜென்ட் தரவின் அடிப்படையில் செயல்படத் தொடங்கும் வரை யாரும் பேசாத ஒரு சிக்கல் இதில் உள்ளது.

30 June 2026 அன்று, நாம் ஒரு முக்கிய திருப்புமுனையில் இருக்கிறோம். பெரிய மொழி மாதிரிகள் பணிகளை ஒருங்கிணைப்பதில் புத்திசாலித்தனமாகி வருகின்றன, தன்னாட்சி ஏஜென்ட்கள் உற்பத்தியில் பயன்படுத்தப்படுகின்றன, மேலும் உடனுக்குடன் சேவைகளுக்கு கட்டணம் செலுத்தும் திறன் அத்தியாவசியமான ஒன்றாக மாறிவருகிறது. இருப்பினும், தற்போதைய கட்டணச் சான்று — பிளாக்செயினில் உள்ள பரிவர்த்தனை — ஒப்பந்தத்தின் ஒரு பாதியை மட்டுமே உறுதிப்படுத்துகிறது: பணம் கைமாறியது என்பதை மட்டும். பதிலுக்கு நீங்கள் பெற்ற தரவு உண்மையானதா அல்லது மாற்றியமைக்கப்பட்டதா என்பதைப் பற்றி அது எதுவும் கூறவில்லை.

ஒரு ஏஜென்ட் சரியாகக் கட்டணம் செலுத்தியும் போலியான தரவின் அடிப்படையில் செயல்படக்கூடும்.

கட்டணச் சான்று தரவை நிரூபிப்பதில்லை

நீங்கள் ஒரு அழைப்புக்கு 0.05 USDC வசூலிக்கும் ஒரு API-ஐ உருவாக்கியுள்ளீர்கள் என்று வைத்துக்கொள்வோம். வாடிக்கையாளரின் ஏஜென்ட் உங்கள் endpoint-ஐ அணுகுகிறது, x402 செயல்முறை நிறைவடைகிறது, USDC பரிமாற்றம் செய்யப்படுகிறது, மேலும் ஏஜென்ட் பதிலாக தரவைப் பெறுகிறது. உங்கள் கட்டண முறைமை பரிவர்த்தனை on chain-இல் நடந்ததை நிரூபிக்க முடியும்.

ஆனால் response body உண்மையில் உங்களிடமிருந்துதான் வந்தது என்று யார் சரிபார்த்தார்கள்? பிளாக்செயின் அல்ல. கட்டண ரசீது என்பது விருப்பத்தின் சான்றிதழ், உண்மையான தன்மையின் சான்றிதழ் அல்ல. நெட்வொர்க் குறுக்கீடு செய்யும் ஒரு தாக்குதலாளர் — அல்லது ஏஜென்ட்டிற்கும் உங்கள் API-க்கும் இடையே உள்ள பிழை கொண்ட proxy கூட — மாற்றியமைக்கப்பட்ட தரவைச் செருகக்கூடும், மேலும் கட்டணச் சான்றினால் எந்தப் பயனும் இல்லை.

இது ஒரு உண்மையான இடைவெளி, மேலும் இது பெரிய அளவில் அதிகரிக்கும்போது இன்னும் மோசமாகிறது. ஏஜென்ட்கள் பல API-களில் அழைப்புகளைச் சங்கிலித் தொடராகப் பயன்படுத்தி, ஒவ்வொன்றும் வெவ்வேறு வழங்குநர்களிடமிருந்து தரவை வாங்கும் போது, தாங்கள் எதற்குக் கட்டணம் செலுத்தினார்களோ அதைத்தான் பெற்றோம் என்ற கிரிப்டோகிராஃபிக் உறுதிமொழி அவற்றுக்குத் தேவைப்படுகிறது. இல்லையெனில் அவை குருட்டுத்தனமாகச் செயல்பட்டு, சரிபார்க்க முடியாத தரவின் மீது முடிவுகளை எடுக்கும்.

தீர்வு: கையொப்பமிடப்பட்ட ரசீதுகள்

கட்டணச் சான்றை தரவோடு பிணைப்பதே இதற்கான தீர்வாகும். கட்டணம் செலுத்தும் வாடிக்கையாளருக்கு உங்கள் API ஒரு பதிலை வழங்கும் போது, நீங்கள் response body மற்றும் payment transaction ID ஆகிய இரண்டிலும் உங்கள் private key மூலம் கையொப்பமிடுகிறீர்கள். வாடிக்கையாளருக்குத் திரும்பக் கிடைப்பது:

1. தரவு மட்டுமே.
2. பரிவர்த்தனை on chain-இல் நடந்தது என்பதை நிரூபிக்கும் ஒரு ரசீது.
3. இரண்டையும் ஒன்றாகப் பிணைக்கும் உங்கள் கிரிப்டோகிராஃபிக் கையொப்பம்.

இப்போது ஏஜென்ட் சுயாதீனமாக சரிபார்க்க முடியும்: இந்தத் தரவு இந்த API-யிலிருந்து வந்தது, இந்த கட்டணம் உண்மையானது, மேலும் அவை பொருந்துகின்றன. அமைப்பு நேரத்தில் ஒரு முறை உங்கள் public key-ஐ சரிபார்ப்பதைத் தாண்டி எந்த நம்பிக்கையும் தேவையில்லை.

இது புரட்சிகரமானது அல்ல — கையொப்பமிடப்பட்ட ரசீதுகள் RSA அளவுக்குப் பழமையானவை — ஆனால் x402-ஐ ஒரு கட்டணக் காரணியிலிருந்து ஒரு முழுமையான சரிபார்ப்பு அமைப்பாக மாற்றும் விடுபட்ட பகுதி இதுவாகும்.

Express மூலம் உருவாக்குவது

இதை எவ்வாறு இணைப்பது என்பது இங்கே. உங்களுக்கு ஒரு keypair (Ed25519 போதுமானது), ஒரு அழைப்புக் கட்டணம் செலுத்தப்படும்போது அதைக் கண்டறியும் ஒரு வழி மற்றும் பதிலில் கையொப்பமிடுவதற்கான 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();
};

இப்போது response-signing 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);

இறுதியாக, ஒரு endpoint-ஐ சேர்க்கவும்:

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);

உற்பத்தியில் இது ஏன் முக்கியமானது

இந்த முறை பல விஷயங்களைத் திறக்கிறது. ஏஜென்ட்கள் இப்போது முன்பு பார்க்காத API-களிலிருந்தும் நம்பிக்கையின்றி தரவை வாங்க முடியும். தணிக்கையாளர்கள் ஒரு முடிவுச் சங்கிலி உண்மையான, கட்டணம் செலுத்தப்பட்ட தரவின் அடிப்படையில் அமைந்தது என்பதைச் சரிபார்க்க முடியும். மேலும் API வழங்குநர்கள் தாங்கள் வாக்குறுதியளித்ததை வழங்கியதற்கான தெளிவான, கிரிப்டோகிராஃபிக் சான்றைப் பெறுகிறார்கள்.

இது அளவிடக்கூடியது. ஒரு கையொப்பம் ஒரு பதிலைக் குறிக்கிறது. லட்சக்கணக்கான அழைப்புகளுக்கான சான்று உங்களுக்குத் தேவைப்பட்டால், உங்கள் வழங்குநர் தரப்பில் அவற்றை Merkle tree-இல் தொகுத்து (batch), ஒரு தொகுதிக்கு ஒரு குடை கையொப்பத்தை (umbrella signature) வழங்கலாம். வாடிக்கையாளர் batch root-ஐ ஒரு முறை சரிபார்த்து, அதன் கீழ் உள்ள எல்லாவற்றையும் நம்பலாம்.

முடிவுரை

x402 நெறிமுறை தன்னாட்சி ஏஜென்ட் API-களின் கட்டணப் பக்கத்தைத் தீர்த்தது. கையொப்பமிடப்பட்ட ரசீதுகள் தரவு உண்மையான தன்மை பக்கத்தைத் தீர்க்கின்றன. ஒன்றாக, அவை நம்பத்தகாத மூலங்களிலிருந்தும் ஏஜென்ட்கள் நம்பகத்தன்மையுடன் தரவை வாங்கி, நம்பிக்கையுடன் செயல்படுவதை சாத்தியமாக்குகின்றன.

நன்மைகள்

• public key-ஐத் தாண்டி API வழங்குநரை நம்பாமல் ஏஜென்ட்களால் தரவு ஒருமைப்பாட்டைச் சரிபார்க்க முடியும்.
• கட்டணங்களும் தரவும் கிரிப்டோகிராஃபிக் முறையில் பிணைக்கப்பட்டுள்ளன — ஒன்றை விட்டு மற்றொன்றைப் போலியாக உருவாக்க முடியாது.
• Merkle trees அல்லது தொகுதி கையொப்பங்கள் மூலம் ஒற்றை அழைப்புகளிலிருந்து லட்சக்கணக்கான அழைப்புகள் வரை அளவிடப்படுகிறது.
• புதிய உள்கட்டமைப்பு எதுவும் தேவையில்லை — நிலையான கிரிப்டோகிராஃபி மற்றும் இருக்கும் பிளாக்செயின்கள் மட்டுமே போதுமானது.
• இருக்கும் x402 கட்டண வழிமுறைகளுடன் இயங்குகிறது.

குறைபாடுகள்

• தாமதத்தை அதிகரிக்கிறது: ஒவ்வொரு பதிலிலும் கையொப்பமிடப்பட வேண்டும் (பெரும்பாலான பயன்பாடுகளுக்கு இது ஏற்கத்தக்கது என்றாலும்).
• வழங்குநர் தரப்பில் பாதுகாப்பான சாவி மேலாண்மை தேவைப்படுகிறது — கசிந்த secret keys நம்பிக்கையைச் செல்லாததாக்குகின்றன.
• கிளையண்டுகள் கையொப்பச் சரிபார்ப்பை நடைமுறைப்படுத்த வேண்டும் (தொடக்கநிலையாளர்களுக்கு இது எளிதானதல்ல).
• API வழங்குநர்கள் தவறான தரவில் கையொப்பமிடுவதைத் தடுப்பதில்லை (நம்பிக்கை public key-இல் உள்ளது, வழங்குநரின் நேர்மையில் அல்ல).
• API ஒப்பந்தத்தில் சிக்கலைச் சேர்க்கிறது — கிளையண்டுகளும் சர்வர்களும் payload வடிவத்தில் உடன்பட வேண்டும்.

எச்சரிக்கை

பெயர்கள் app.example.com, REPLACE_WITH_VAULT_REFERENCE, REPLACE_WITH_YOUR_PUBLIC_KEY, மற்றும் இங்கு காட்டப்பட்டுள்ள அனைத்து transaction ID-களும் பிளேஸ்ஹோல்டர்கள் ஆகும். உங்கள் குறியீட்டில் secret keys, API secrets அல்லது உண்மையான சான்றுகளை ஒருபோதும் ஹார்ட்கோட் செய்ய வேண்டாம். உற்பத்தியில் பயன்படுத்துவதற்கு முன் எப்போதும் உள்ளூர் சோதனை சூழலில் கையொப்பச் சரிபார்ப்பைச் சோதிக்கவும். private keys-ஐ ஒரு ரகசிய பெட்டகத்தில் (HashiCorp Vault, AWS Secrets Manager அல்லது அது போன்ற) சேமிக்கவும், ஒருபோதும் சூழல் மாறிகளில் (environment variables) அல்லது மூலக் கட்டுப்பாட்டில் (source control) சேமிக்க வேண்டாம். உங்கள் சொந்த ஆபத்தில் தொடரவும், உண்மையான கட்டணங்களை ஏற்கும் முன் ஒரு testnet சூழலில் செயலாக்கத்தை முழுமையாகச் சரிபார்க்கவும்.

அடிக்கடி கேட்கப்படும் கேள்விகள்

• ஒரு API வழங்குநரின் private key கசிந்தால் என்ன நடக்கும்?
• பல API அழைப்புகளை ஒரே கையொப்பமிடப்பட்ட ரசீதாகத் தொகுக்க முடியுமா?
• JavaScript அல்லாத பிற மொழிகளில் கையொப்பத்தை எவ்வாறு சரிபார்ப்பது?
• பதிலில் உள்ள ஒவ்வொரு புலத்திலும் கையொப்பமிட வேண்டுமா அல்லது தரவில் மட்டுமா?
• கையொப்பமிடுதல் மற்றும் கையொப்பங்களைச் சரிபார்ப்பதன் செயல்திறன் சுமை என்ன?
• அழைப்புக்குக் கட்டணம் என்பதற்குப் பதிலாக நிலையான சந்தா வசூலிக்கும் API-களுடன் இது செயல்படுமா?
• உற்பத்தியில் கையொப்பச் சரிபார்ப்புத் தோல்விகளை ஏஜென்ட்கள் எவ்வாறு கையாள்கின்றன?
• Ed25519 மட்டுமே நான் பயன்படுத்த வேண்டிய கையொப்பமிடும் வழிமுறையா, அல்லது மற்றவைகளும் ஏற்கத்தக்கவையா?

குறிச்சொற்கள்

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