സൈൻ ചെയ്ത രസീതുകൾ ഉപയോഗിച്ച് നിങ്ങളുടെ API ഡാറ്റ സാക്ഷ്യപ്പെടുത്താം — പേയ്‌മെന്റ് വെരിഫിക്കേഷന് അപ്പുറം

ഏജന്റ്-ടു-ഏജന്റ് പേയ്‌മെന്റുകളുടെ പുതിയ ലോകം

ആദ്യമായി, AI ഏജന്റുകൾക്ക് കാര്യങ്ങൾക്കായി സ്വയം പണമടയ്ക്കാൻ കഴിയും. ഒരു ക്ലയന്റിന് — മനുഷ്യനായാലും ആർട്ടിഫിഷ്യൽ ആയാലും — USDC സ്റ്റേബിൾകോയിനിൽ ഓരോ API കോളിനും പണമടയ്ക്കാനും, API കീകൾ പൂർണ്ണമായും ഒഴിവാക്കാനും, ഒരു അക്കൗണ്ടും സൃഷ്ടിക്കാതിരിക്കാനും x402 പ്രോട്ടോക്കോൾ HTTP 402 Payment Required സ്റ്റാറ്റസ് കോഡ് വീണ്ടും ഉപയോഗിക്കുന്നു.

ഇത് ശരിക്കും ബുദ്ധിപരമായ ഒന്നാണ്. എന്നാൽ ഒരു ഏജന്റ് ഡാറ്റ അനുസരിച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങുന്നത് വരെ ആരും സംസാരിക്കാത്ത ഒരു പ്രശ്നമുണ്ട്.

2026 ജൂൺ 30-ഓടെ, നാം ഒരു നിർണായക ഘട്ടത്തിലാണ്. ടാസ്ക്കുകൾ കൈകാര്യം ചെയ്യുന്നതിൽ ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ കൂടുതൽ മിടുക്കുള്ളവരായി മാറുന്നു, പ്രൊഡക്ഷനിൽ ഓട്ടോണമസ് ഏജന്റുകൾ വിന്യസിക്കപ്പെടുന്നു, തൽസമയം സേവനങ്ങൾക്കായി പണമടയ്ക്കാനുള്ള കഴിവ് അടിസ്ഥാന ആവശ്യമായി മാറുന്നു. എന്നിരുന്നാലും നിലവിലെ പേയ്‌മെന്റ് പ്രൂഫ് — ബ്ലോക്ക്‌ചെയിനിലെ ട്രാൻസാക്ഷൻ — ഇടപാടിന്റെ പകുതി മാത്രമേ സ്ഥിരീകരിക്കുന്നുള്ളൂ: പണം കൈമാറ്റം ചെയ്യപ്പെട്ടു എന്നത്. പകരം നിങ്ങൾക്ക് ലഭിച്ച ഡാറ്റ വിശ്വസനീയമാണോ അതോ കൃത്രിമം കാണിച്ചതാണോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

ഒരു ഏജന്റിന് കൃത്യമായി പണമടയ്ക്കാനും എന്നാൽ വ്യാജമായ ഡാറ്റ അനുസരിച്ച് പ്രവർത്തിക്കാനും കഴിയും.

പേയ്‌മെന്റ് പ്രൂഫ് ഡാറ്റയെ തെളിയിക്കുന്നില്ല

ഓരോ കോളിനും 0.05 USDC ഈടാക്കുന്ന ഒരു API നിങ്ങൾ നിർമ്മിച്ചിട്ടുണ്ടെന്ന് കരുതുക. ഒരു ഉപഭോക്താവിന്റെ ഏജന്റ് നിങ്ങളുടെ എൻഡ്‌പോയിന്റിൽ എത്തുമ്പോൾ, x402 ഫ്ലോ പൂർത്തിയാകുകയും USDC ട്രാൻസ്ഫർ ചെയ്യപ്പെടുകയും ഏജന്റിന് മറുപടിയായി ഡാറ്റ ലഭിക്കുകയും ചെയ്യുന്നു. ട്രാൻസാക്ഷൻ ഓൺ-ചെയിനിൽ നടന്നു എന്ന് തെളിയിക്കാൻ നിങ്ങളുടെ പേയ്‌മെന്റ് സിസ്റ്റത്തിന് കഴിയും.

എന്നാൽ റെസ്പോൺസ് ബോഡി യഥാർത്ഥത്തിൽ നിങ്ങളിൽ നിന്നാണ് വന്നതെന്ന് ആര് പരിശോധിച്ചു? ബ്ലോക്ക്‌ചെയിനല്ല. പേയ്‌മെന്റ് രസീത് എന്നത് താല്പര്യത്തിന്റെ ഒരു സർട്ടിഫിക്കറ്റാണ്, അല്ലാതെ വിശ്വസനീയതയുടെ സർട്ടിഫിക്കറ്റല്ല. നെറ്റ്‌വർക്ക് ഇന്റർസെപ്റ്റുള്ള ഒരു അറ്റാക്കർക്ക് — അല്ലെങ്കിൽ ഏജന്റിനും നിങ്ങളുടെ API-ക്കും ഇടയിലുള്ള തകരാറുള്ള പ്രോക്സിക്ക് പോലും — മാറ്റം വരുത്തിയ ഡാറ്റ നൽകാൻ കഴിയും, അതിലൂടെ പേയ്‌മെന്റ് പ്രൂഫ് അർത്ഥശൂന്യമായി മാറും.

ഇതൊരു വലിയ വിടവാണ്, വൻതോതിൽ ഇതെടുക്കുമ്പോൾ കൂടുതൽ വഷളാകുന്നു. ഏജന്റുകൾ വിവിധ API-കളിലുടനീളം കോളുകൾ ലിങ്ക് ചെയ്യുകയും, ഓരോന്നും വ്യത്യസ്ത പ്രൊവൈഡർമാരിൽ നിന്ന് ഡാറ്റ വാങ്ങുകയും ചെയ്യുകയാണെങ്കിൽ, അവർ പണം നൽകിയത് തന്നെയാണ് തങ്ങൾക്ക് ലഭിച്ചതെന്ന് ഉറപ്പാക്കാൻ അവർക്ക് ക്രിപ്റ്റോഗ്രാഫിക് ഉറപ്പ് ആവശ്യമാണ്. അല്ലാത്തപക്ഷം അവർക്ക് പരിശോധിക്കാൻ കഴിയാത്ത ഡാറ്റയെ അടിസ്ഥാനമാക്കി തീരുമാനങ്ങൾ എടുക്കേണ്ടി വരും.

പരിഹാരം: സൈൻ ചെയ്ത രസീതുകൾ

പേയ്‌മെന്റ് പ്രൂഫിനെ ഡാറ്റയുമായി ബന്ധിപ്പിക്കുകയാണ് ഇതിനുള്ള പരിഹാരം. പണം നൽകുന്ന ഒരു ഉപഭോക്താവിന് നിങ്ങളുടെ API ഒരു മറുപടി നൽകുമ്പോൾ, നിങ്ങളുടെ പ്രൈവറ്റ് കീ ഉപയോഗിച്ച് റെസ്പോൺസ് ബോഡിയും പേയ്‌മെന്റ് ട്രാൻസാക്ഷൻ ID-യും നിങ്ങൾ സൈൻ ചെയ്യുന്നു. ഉപഭോക്താവിന് ഇവ തിരികെ ലഭിക്കുന്നു:

1. ഡാറ്റ തന്നെ.
2. പേയ്‌മെന്റ് ഓൺ-ചെയിനിൽ നടന്നു എന്ന് തെളിയിക്കുന്ന ഒരു രസീത്.
3. ഇവ രണ്ടിനെയും തമ്മിൽ ബന്ധിപ്പിക്കുന്ന നിങ്ങളുടെ ക്രിപ്റ്റോഗ്രാഫിക് സിഗ്നേച്ചർ.

ഇപ്പോൾ ഏജന്റിന് സ്വതന്ത്രമായി പരിശോധിക്കാൻ കഴിയും: ഈ ഡാറ്റ ഈ API-യിൽ നിന്നാണ് വന്നത്, ഈ പേയ്‌മെന്റ് യഥാർത്ഥമായിരുന്നു, അവ തമ്മിൽ പൊരുത്തപ്പെടുന്നു. സെറ്റപ്പ് സമയത്ത് നിങ്ങളുടെ പബ്ലിക് കീ ഒരു തവണ പരിശോധിക്കുന്നതിന് അപ്പുറം ഒരു വിശ്വാസവും ആവശ്യമില്ല.

ഇത് വിപ്ലവകരമായ ഒന്നല്ല — സൈൻ ചെയ്ത രസീതുകൾ RSA പോലെ തന്നെ പഴയതാണ് — എന്നാൽ x402-നെ ഒരു പേയ്‌മെന്റ് പ്രിമിറ്റീവിൽ നിന്ന് ഒരു സമ്പൂർണ്ണ വെരിഫിക്കേഷൻ സിസ്റ്റമാക്കി മാറ്റുന്ന അവിഭാജ്യ ഘടകമാണിത്.

Express ഉപയോഗിച്ച് ഇത് നിർമ്മിക്കാം

ഇത് എങ്ങനെ സജ്ജീകരിക്കാമെന്ന് ഇവിടെ കാണാം. നിങ്ങൾക്ക് ഒരു കീപെയർ (Ed25519 ധാരാളം), ഒരു കോൾ പണമടച്ചതാണോ എന്ന് കണ്ടെത്തുന്നതിനുള്ള ഒരു വഴി, മറുപടി സൈൻ ചെയ്യുന്നതിനുള്ള മിഡിൽവെയർ എന്നിവ ആവശ്യമാണ്.

ആദ്യമായി, നിങ്ങളുടെ കീകളും ഡിപൻഡൻസികളും സജ്ജീകരിക്കുക:

npm install express tweetnacl base64-js axios

നിങ്ങളുടെ കീപെയർ ജനറേറ്റ് ചെയ്ത് സുരക്ഷിതമായി സൂക്ഷിക്കുക (ഒരിക്കലും 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);

അടുത്തതായി, പേയ്‌മെന്റ് പരിശോധനയ്ക്ക് ശേഷം മറുപടികൾ തടയുന്ന മിഡിൽവെയർ സൃഷ്ടിക്കുക:

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

ഇപ്പോൾ ഒരു റെസ്പോൺസ്-സൈനിംഗ് മിഡിൽവെയർ സൃഷ്ടിക്കുക:

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

പ്രൊഡക്ഷനിൽ ഇത് എന്തുകൊണ്ട് പ്രധാനമാണ്

ഈ പാറ്റേൺ പല കാര്യങ്ങൾ സാധ്യമാക്കുന്നു. ഏജന്റുകൾക്ക് മുമ്പ് കണ്ടിട്ടില്ലാത്ത API-കളിൽ നിന്ന് പോലും വിശ്വസനീയമായി ഡാറ്റ വാങ്ങാൻ ഇപ്പോൾ സാധിക്കും. തീരുമാനങ്ങളുടെ ശൃംഖല യഥാർത്ഥവും പണം നൽകി വാങ്ങിയതുമായ ഡാറ്റയെ അടിസ്ഥാനമാക്കിയുള്ളതാണെന്ന് ഓഡിറ്റർമാർക്ക് പരിശോധിക്കാം. കൂടാതെ വാഗ്ദാനം ചെയ്തത് നൽകിയെന്ന് തെളിയിക്കുന്ന വ്യക്തമായ ക്രിപ്റ്റോഗ്രാഫിക് പ്രൂഫ് API പ്രൊവൈഡർമാർക്ക് ലഭിക്കുകയും ചെയ്യുന്നു.

ഇതിന് സ്കേൽ ചെയ്യാനും സാധിക്കും. ഒരു സിഗ്നേച്ചർ ഒരു റെസ്പോൺസിനെ കവർ ചെയ്യുന്നു. ദശലക്ഷക്കണക്കിന് കോളുകളുടെ തെളിവ് ആവശ്യമുണ്ടെങ്കിൽ, നിങ്ങളുടെ പ്രൊവൈഡർ സൈഡിൽ ഒരു Merkle tree ആയി അവയെ ബാച്ച് ചെയ്യാനും ഓരോ ബാച്ചിനും ഒരു അംബ്രല്ല സിഗ്നേച്ചർ നൽകാനും കഴിയും. ഉപഭോക്താവ് ബാച്ച് റൂട്ട് ഒരു തവണ പരിശോധിക്കുകയും അതിന് കീഴിലുള്ള എല്ലാം വിശ്വസിക്കുകയും ചെയ്യുന്നു.

ഉപസംഹാരം

x402 പ്രോട്ടോക്കോൾ ഓട്ടോണമസ് ഏജന്റ് API-കളുടെ പേയ്‌മെന്റ് ഭാഗം പരിഹരിച്ചു. സൈൻ ചെയ്ത രസീതുകൾ ഡാറ്റയുടെ വിശ്വസനീയത ഭാഗം പരിഹരിക്കുന്നു. ഒന്നിച്ചു പ്രവർത്തിക്കുമ്പോൾ, ഏജന്റുകൾക്ക് വിശ്വസനീയമല്ലാത്ത സ്രോതസ്സുകളിൽ നിന്ന് പോലും ഡാറ്റ വാങ്ങാനും ആത്മവിശ്വാസത്തോടെ പ്രവർത്തിക്കാനും ഇവ വഴിയൊരുക്കുന്നു.

ഗുണങ്ങൾ

• പബ്ലിക് കീക്ക് അപ്പുറം API പ്രൊവൈഡറെ വിശ്വസിക്കാതെ തന്നെ ഏജന്റുകൾക്ക് ഡാറ്റയുടെ സമഗ്രത പരിശോധിക്കാൻ കഴിയും.
• പേയ്‌മെന്റുകളും ഡാറ്റയും ക്രിപ്റ്റോഗ്രാഫിക്കലായി ബന്ധിപ്പിച്ചിരിക്കുന്നു — ഒന്നിനെ ഒഴിവാക്കി മറ്റൊന്ന് വ്യാജമായി നിർമ്മിക്കാൻ കഴിയില്ല.
• Merkle trees അല്ലെങ്കിൽ ബാച്ച് സിഗ്നേച്ചറുകൾ വഴി ഒറ്റ കോളുകളിൽ നിന്ന് ദശലക്ഷക്കണക്കിന് കോളുകളിലേക്ക് സ്കേൽ ചെയ്യുന്നു.
• പുതിയ അടിസ്ഥാന സൗകര്യങ്ങൾ ആവശ്യമില്ല — സാധാരണ ക്രിപ്റ്റോഗ്രാഫിയും നിലവിലുള്ള ബ്ലോക്ക്‌ചെയിനുകളും മാത്രം മതി.
• നിലവിലുള്ള x402 പേയ്‌മെന്റ് ഫ്ലോകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നു.

ദോഷങ്ങൾ

• ലേറ്റൻസി വർദ്ധിപ്പിക്കുന്നു: ഓരോ മറുപടിയും സൈൻ ചെയ്യേണ്ടതുണ്ട് (മിക്ക ഉപയോഗങ്ങൾക്കും ഇത് സ്വീകാര്യമാണെങ്കിലും).
• പ്രൊവൈഡർ സൈഡിൽ സുരക്ഷിതമായ കീ മാനേജ്മെന്റ് ആവശ്യമാണ് — രഹസ്യ കീകൾ ചോർന്നാൽ വിശ്വാസ്യത നഷ്ടപ്പെടും.
• ക്ലയന്റുകൾ സിഗ്നേച്ചർ വെരിഫിക്കേഷൻ നടപ്പിലാക്കണം (തുടക്കക്കാർക്ക് ഇത് ലളിതമല്ല).
• തെറ്റായ ഡാറ്റ സൈൻ ചെയ്യുന്നതിൽ നിന്ന് API പ്രൊവൈഡർമാരെ തടയില്ല (വിശ്വാസം പബ്ലിക് കീയിലാണ്, പ്രൊവൈഡറുടെ സത്യസന്ധതയിലല്ല).
• API കോൺട്രാക്റ്റിൽ സങ്കീർണ്ണത വർദ്ധിപ്പിക്കുന്നു — പേലോഡ് ഫോർമാറ്റിൽ ക്ലയന്റുകളും സെർവറുകളും ധാരണയിലെത്തണം.

ജാഗ്രത

പേരുകൾ app.example.com, REPLACE_WITH_VAULT_REFERENCE, REPLACE_WITH_YOUR_PUBLIC_KEY, ഇവിടെ കാണിച്ചിരിക്കുന്ന എല്ലാ ട്രാൻസാക്ഷൻ ID-കളും പ്ലേസ്‌ഹോൾഡറുകളാണ്. നിങ്ങളുടെ കോഡിൽ രഹസ്യ കീകൾ, API രഹസ്യങ്ങൾ അല്ലെങ്കിൽ യഥാർത്ഥ ക്രെഡൻഷ്യലുകൾ ഒരിക്കലും ഹാർഡ്‌കോഡ് ചെയ്യരുത്. പ്രൊഡക്ഷനിലേക്ക് ഡിപ്ലോയ് ചെയ്യുന്നതിന് മുമ്പ് എല്ലായ്പ്പോഴും ലോക്കൽ ടെസ്റ്റ് എൻവയോൺമെന്റിൽ സിഗ്നേച്ചർ വെരിഫിക്കേഷൻ പരിശോധിക്കുക. പ്രൈവറ്റ് കീകൾ ഒരു സീക്രട്ട്സ് വോൾട്ടിൽ (HashiCorp Vault, AWS Secrets Manager അല്ലെങ്കിൽ സമാനമായവ) സൂക്ഷിക്കുക, ഒരിക്കലും എൻവയോൺമെന്റ് വേരിയബിളുകളിലോ സോഴ്‌സ് കൺട്രോളിലോ സൂക്ഷിക്കരുത്. സ്വന്തം ഉത്തരവാദിത്തത്തിൽ മുന്നോട്ട് പോകുക, യഥാർത്ഥ പേയ്‌മെന്റുകൾ സ്വീകരിക്കുന്നതിന് മുമ്പ് ഒരു ടെസ്റ്റ്നെറ്റ് എൻവയോൺമെന്റിൽ ഇംപ്ലിമെന്റേഷൻ നന്നായി പരിശോധിച്ച് ഉറപ്പാക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

• ഒരു API പ്രൊവൈഡറുടെ പ്രൈവറ്റ് കീ ചോർന്നാൽ എന്ത് സംഭവിക്കും?
• എനിക്ക് ഒന്നിലധികം API കോളുകൾ ഒരൊറ്റ സൈൻ ചെയ്ത രസീതാക്കി മാറ്റാൻ കഴിയുമോ?
• JavaScript അല്ലാത്ത മറ്റ് ഭാഷകളിൽ ഞാൻ എങ്ങനെയാണ് ഒരു സിഗ്നേച്ചർ പരിശോധിക്കുന്നത്?
• മറുപടിയിലെ ഓരോ ഫീൽഡും ഞാൻ സൈൻ ചെയ്യേണ്ടതുണ്ടോ അതോ ഡാറ്റ മാത്രം മതിയോ?
• സിഗ്നേച്ചറുകൾ സൈൻ ചെയ്യുന്നതിനും പരിശോധിക്കുന്നതിനുമുള്ള പെർഫോമൻസ് ഓവർഹെഡ് എന്താണ്?
• ഓരോ കോളിനും പകരം നിശ്ചിത സബ്‌സ്‌ക്രിപ്‌ഷൻ ഈടാക്കുന്ന API-കളിൽ ഇത് പ്രവർത്തിക്കുമോ?
• പ്രൊഡക്ഷനിൽ സിഗ്നേച്ചർ വെരിഫിക്കേഷൻ പരാജയപ്പെടുമ്പോൾ ഏജന്റുകൾ എങ്ങനെയാണ് അത് കൈകാര്യം ചെയ്യുന്നത്?
• ഞാൻ ഉപയോഗിക്കേണ്ട ഒരേയൊരു സൈനിംഗ് അൽഗോരിതം Ed25519 ആണോ, അതോ മറ്റുള്ളവ സ്വീകാര്യമാണോ?

ടാഗുകൾ

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