ସାଇନ୍‌ଡ୍ ରସିଦ୍ ସହିତ ଆପଣଙ୍କର API ଡାଟା ପ୍ରମାଣିତ କରିବା — ପେମେଣ୍ଟ ଯାଞ୍ଚଠାରୁ ଅଧିକ

ଏଜେଣ୍ଟ-ଟୁ-ଏଜେଣ୍ଟ ପେମେଣ୍ଟର ନୂତନ ଦୁନିଆ

ପ୍ରଥମ ଥର ପାଇଁ, AI ଏଜେଣ୍ଟମାନେ ସ୍ୱୟଂଚାଳିତ ଭାବରେ ଜିନିଷଗୁଡ଼ିକ ପାଇଁ ପେମେଣ୍ଟ କରିପାରିବେ। x402 ପ୍ରୋଟୋକଲ୍ HTTP 402 Payment Required ଷ୍ଟାଟସ୍ କୋଡ୍‌କୁ ପୁନଃବ୍ୟବହାର କରି ଗୋଟିଏ କ୍ଲାଏଣ୍ଟ — ମାନବ ହେଉ କିମ୍ବା କୃତ୍ରିମ — କୁ USDC ଷ୍ଟେବୁଲକଏନ୍‌ରେ ପ୍ରତି API କଲ୍ ପାଇଁ ପେମେଣ୍ଟ କରିବାକୁ, API keys ଗୁଡ଼ିକୁ ସମ୍ପୂର୍ଣ୍ଣ ଏଡ଼ାଇବାକୁ ଏବଂ କେବେବି ଆକାଉଣ୍ଟ ତିଆରି ନକରିବାକୁ ଅନୁମତି ଦିଏ।

ଏହା ପ୍ରକୃତରେ ଚତୁରତାପୂର୍ଣ୍ଣ। କିନ୍ତୁ ଏପରି ଗୋଟିଏ ସମସ୍ୟା ଅଛି ଯାହା ବିଷୟରେ ଜଣେ ଏଜେଣ୍ଟ ଡାଟା ଉପରେ କାର୍ଯ୍ୟ କରିବା ଆରମ୍ଭ ନକରିବା ପର୍ଯ୍ୟନ୍ତ କେହି କଥା ହୁଅନ୍ତି ନାହିଁ।

30 June 2026 ରେ, ଆମେ ଗୋଟିଏ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ମୋଡ଼ରେ ଅଛୁ। Large language models ଗୁଡ଼ିକ ଟାସ୍କଗୁଡ଼ିକୁ ସଞ୍ଚାଳନ କରିବାରେ ଅଧିକ ଚତୁର ହେଉଛନ୍ତି, ସ୍ୱୟଂଚାଳିତ ଏଜେଣ୍ଟଗୁଡ଼ିକୁ ପ୍ରୋଡକ୍ସନ୍‌ରେ ନିୟୋଜିତ କରାଯାଉଛି, ଏବଂ ତତ୍କ୍ଷଣାତ୍ ସେବାଗୁଡ଼ିକ ପାଇଁ ପେମେଣ୍ଟ କରିବାର କ୍ଷମତା ଏକ ମୌଳିକ ଆବଶ୍ୟକତା ପାଲଟିଛି। ତଥାପି ବର୍ତ୍ତମାନର ପେମେଣ୍ଟ ପ୍ରମାଣ — ବ୍ଲକ୍‌ଚେନ୍‌ରେ ହୋଇଥିବା ଟ୍ରାନ୍‌ଜାକ୍ସନ୍ — କେବଳ ଡିଲ୍‌ର ଅଧା ଅଂଶ ପୁଷ୍ଟି କରେ: ଟଙ୍କା ଆଦାନପ୍ରଦାନ ହୋଇଛି। ପ୍ରତିବଦଳରେ ଆପଣ ଗ୍ରହଣ କରିଥିବା ଡାଟା ଅସଲି ନା ସେଥିରେ କିଛି ଫେରବଦଳ କରାଯାଇଛି, ସେ ବିଷୟରେ ଏହା କିଛି କହେ ନାହିଁ।

ଜଣେ ଏଜେଣ୍ଟ ସଠିକ୍ ଭାବରେ ପେମେଣ୍ଟ କରିପାରେ ଏବଂ ତଥାପି ନକଲି (spoofed) ଡାଟା ଆଧାରରେ କାର୍ଯ୍ୟ କରିପାରେ।

ପେମେଣ୍ଟ ପ୍ରମାଣ ଡାଟାକୁ ପ୍ରମାଣିତ କରେ ନାହିଁ

ଧରାଯାଉ ଆପଣ ଏକ API ତିଆରି କରିଛନ୍ତି ଯାହା ପ୍ରତି କଲ୍ ପାଇଁ 0.05 USDC ଚାର୍ଜ କରେ। ଜଣେ ଗ୍ରାହକଙ୍କ ଏଜେଣ୍ଟ ଆପଣଙ୍କ endpoint କୁ ହିଟ୍ କରେ, x402 ଫ୍ଲୋ ସମ୍ପୂର୍ଣ୍ଣ ହୁଏ, USDC ଟ୍ରାନ୍ସଫର ହୁଏ, ଏବଂ ଏଜେଣ୍ଟ ରେସପନ୍ସରେ ଡାଟା ଗ୍ରହଣ କରେ। ଆପଣଙ୍କ ପେମେଣ୍ଟ ସିଷ୍ଟମ୍ ପ୍ରମାଣ କରିପାରିବ ଯେ ଟ୍ରାନ୍‌ଜାକ୍ସନ୍ on chain ରେ ହୋଇଛି।

କିନ୍ତୁ response body ପ୍ରକୃତରେ ଆପଣଙ୍କ ପାଖରୁ ଆସିଛି ବୋଲି କିଏ ଯାଞ୍ଚ କଲା? ବ୍ଲକ୍‌ଚେନ୍ ତ ନୁହେଁ। ପେମେଣ୍ଟ ରସିଦ୍ ହେଉଛି ଉଦ୍ଦେଶ୍ୟର ପ୍ରମାଣପତ୍ର, ପ୍ରାମାଣିକତାର ପ୍ରମାଣପତ୍ର ନୁହେଁ। ନେଟୱର୍କ ଇଣ୍ଟରସେପ୍ଟ ଥିବା କୌଣସି ଆକ୍ରମଣକାରୀ — କିମ୍ବା ଏଜେଣ୍ଟ ଏବଂ ଆପଣଙ୍କ API ମଧ୍ୟରେ ଥିବା ଏକ buggy proxy — ପରିବର୍ତ୍ତିତ ଡାଟା ଗୋପନରେ ପଠାଇପାରେ ଏବଂ ପେମେଣ୍ଟ ପ୍ରମାଣର କୌଣସି ମୂଲ୍ୟ ରହେନାହିଁ।

ଏହା ଏକ ବାସ୍ତବ ବ୍ୟବଧାନ, ଏବଂ ବଡ଼ ସ୍କେଲ୍‌ରେ ଏହା ଆହୁରି ଖରାପ ହୋଇଯାଏ। ଯଦି ଏଜେଣ୍ଟମାନେ API ଗୁଡ଼ିକରେ କଲ୍‌ଗୁଡ଼ିକୁ chaining କରୁଛନ୍ତି, ପ୍ରତ୍ୟେକ ବିଭିନ୍ନ ପ୍ରୋଭାଇଡର୍‌ଙ୍କଠାରୁ ଡାଟା କିଣୁଛନ୍ତି, ତେବେ ସେମାନେ ଯାହା ପାଇଁ ପେମେଣ୍ଟ କରିଛନ୍ତି ତାହା ଗ୍ରହଣ କରିଛନ୍ତି ବୋଲି ସେମାନଙ୍କୁ କ୍ରିପ୍ଟୋଗ୍ରାଫିକ୍ ଆଶ୍ୱାସନା ଆବଶ୍ୟକ। ନଚେତ୍ ସେମାନେ ଅନ୍ଧ ଭାବରେ କାମ କରୁଛନ୍ତି, ଯାଞ୍ଚ କରିପାରୁ ନଥିବା ଡାଟା ଉପରେ ନିଷ୍ପତ୍ତି ନେଉଛନ୍ତି।

ସମାଧାନ: ସାଇନ୍‌ଡ୍ ରସିଦ୍

ଏହାର ସମାଧାନ ହେଉଛି ପେମେଣ୍ଟ ପ୍ରମାଣକୁ ଡାଟା ସହିତ ବାନ୍ଧିବା। ଯେତେବେଳେ ଆପଣଙ୍କ API ଜଣେ ପେମେଣ୍ଟ କରୁଥିବା ଗ୍ରାହକଙ୍କୁ ରେସପନ୍ସ ଦିଏ, ଆପଣ ଆପଣଙ୍କର private key ସହିତ response body ଏବଂ ପେମେଣ୍ଟ transaction ID ଉଭୟକୁ ସାଇନ୍ କରନ୍ତି। ଗ୍ରାହକ ଫେରସ୍ତ ପାଆନ୍ତି:

1. ନିଜେ ଡାଟା।
2. ଗୋଟିଏ ରସିଦ୍ ଯାହା ପ୍ରମାଣ କରେ ଯେ ପେମେଣ୍ଟ on chain ରେ ହୋଇଛି।
3. ଉଭୟକୁ ଏକାଠି ବାନ୍ଧୁଥିବା ଆପଣଙ୍କର କ୍ରିପ୍ଟୋଗ୍ରାଫିକ୍ ସିଗ୍ନେଚର୍।

ବର୍ତ୍ତମାନ ଏଜେଣ୍ଟ ସ୍ୱାଧୀନ ଭାବରେ ଯାଞ୍ଚ କରିପାରିବ: ଏହି ଡାଟା ଏହି API ରୁ ଆସିଛି, ଏହି ପେମେଣ୍ଟ ଅସଲି ଥିଲା, ଏବଂ ସେଗୁଡ଼ିକ ମେଳ ଖାଉଛନ୍ତି। ସେଟ୍‌ଅପ୍ ସମୟରେ ଥରେ ଆପଣଙ୍କ public key ଯାଞ୍ଚ କରିବା ବ୍ୟତୀତ ଅନ୍ୟ କୌଣସି ବିଶ୍ୱାସର ଆବଶ୍ୟକତା ନାହିଁ।

ଏହା କୌଣସି କ୍ରାନ୍ତିକାରୀ ନୁହେଁ — ସାଇନ୍‌ଡ୍ ରସିଦ୍ RSA ଯେତିକି ପୁରୁଣା ସେତିକି ପୁରୁଣା — କିନ୍ତୁ ଏହା ହେଉଛି ସେହି ହଜିଯାଇଥିବା ଅଂଶ ଯାହା x402 କୁ ଗୋଟିଏ ପେମେଣ୍ଟ ପ୍ରିମିଟିଭ୍‌ରୁ ଏକ ସମ୍ପୂର୍ଣ୍ଣ ଯାଞ୍ଚ ସିଷ୍ଟମ୍‌ରେ ପରିଣତ କରେ।

Express ସହିତ ଏହାକୁ ନିର୍ମାଣ କରିବା

ଏହାକୁ କିପରି ସଂଯୋଗ କରିବେ ତାହା ଏଠାରେ ଦିଆଗଲା। ଆପଣଙ୍କୁ ଗୋଟିଏ keypair (Ed25519 ଠିକ୍ ଅଛି), କଲ୍ ପାଇଁ ପେମେଣ୍ଟ ହୋଇଛି କି ନାହିଁ ଚିହ୍ନଟ କରିବାର ଏକ ଉପାୟ, ଏବଂ ରେସପନ୍ସ ସାଇନ୍ କରିବାକୁ middleware ଆବଶ୍ୟକ ହେବ।

ପ୍ରଥମେ, ଆପଣଙ୍କର keys ଏବଂ dependencies ସେଟ୍‌ଅପ୍ କରନ୍ତୁ:

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

ପରବର୍ତ୍ତୀ ସମୟରେ, ପେମେଣ୍ଟ ଯାଞ୍ଚ ପରେ ରେସପନ୍ସଗୁଡ଼ିକୁ intercept କରୁଥିବା 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'));

କ୍ଲାଏଣ୍ଟ ସାଇଡ୍‌ରେ, ଡାଟା ଉପରେ କାର୍ଯ୍ୟ କରିବା ପୂର୍ବରୁ signature ଯାଞ୍ଚ କରନ୍ତୁ:

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 ଗୁଡ଼ିକରୁ trustlessly ଡାଟା କିଣିପାରିବେ। ଅଡିଟରମାନେ ଯାଞ୍ଚ କରିପାରିବେ ଯେ ନିଷ୍ପତ୍ତି ଶୃଙ୍ଖଳା ପ୍ରାମାଣିକ, ପେମେଣ୍ଟ କରାଯାଇଥିବା ଡାଟା ଉପରେ ଆଧାରିତ ଥିଲା। ଏବଂ API ପ୍ରୋଭାଇଡର୍‌ମାନେ ସେମାନେ ପ୍ରତିଶ୍ରୁତି ଦେଇଥିବା ଜିନିଷ ପ୍ରଦାନ କରିଛନ୍ତି ବୋଲି ଏକ ସ୍ପଷ୍ଟ, କ୍ରିପ୍ଟୋଗ୍ରାଫିକ୍ ପ୍ରମାଣ ପାଆନ୍ତି।

ଏହା scale ମଧ୍ୟ କରେ। ଗୋଟିଏ signature ଗୋଟିଏ response କୁ କଭର୍ କରେ। ଯଦି ଆପଣଙ୍କୁ ଲକ୍ଷ ଲକ୍ଷ କଲ୍‌ର ପ୍ରମାଣ ଦରକାର, ଆପଣ ଆପଣଙ୍କର provider side ରେ ସେଗୁଡ଼ିକୁ Merkle tree ରେ batch କରିପାରିବେ ଏବଂ ପ୍ରତି batch ରେ ଗୋଟିଏ umbrella signature ଜାରି କରିପାରିବେ। ଗ୍ରାହକ batch root କୁ ଥରେ ଯାଞ୍ଚ କରନ୍ତି ଏବଂ ତା' ଅଧୀନରେ ଥିବା ସବୁକିଛିକୁ ବିଶ୍ୱାସ କରନ୍ତି।

ନିଷ୍କର୍ଷ

x402 ପ୍ରୋଟୋକଲ୍ ସ୍ୱୟଂଚାଳିତ ଏଜେଣ୍ଟ API ଗୁଡ଼ିକର ପେମେଣ୍ଟ ପକ୍ଷକୁ ସମାଧାନ କରିଛି। ସାଇନ୍‌ଡ୍ ରସିଦ୍ ଡାଟା ପ୍ରାମାଣିକତା ପକ୍ଷକୁ ସମାଧାନ କରେ। ଉଭୟ ମିଶି ଏଜେଣ୍ଟମାନଙ୍କ ପାଇଁ ଅବିଶ୍ୱସ୍ତ ଉତ୍ସରୁ ନିର୍ଭରଯୋଗ୍ୟ ଭାବରେ ଡାଟା କିଣିବା ଏବଂ ଆତ୍ମବିଶ୍ୱାସର ସହିତ ତା' ଉପରେ କାର୍ଯ୍ୟ କରିବା ସମ୍ଭବ କରନ୍ତି।

ଗୁଣସମୂହ

• public key ବ୍ୟତୀତ API ପ୍ରୋଭାଇଡର୍‌କୁ ବିଶ୍ୱାସ ନକରି ଏଜେଣ୍ଟମାନେ ଡାଟା ସତ୍ୟତା (data integrity) ଯାଞ୍ଚ କରିପାରିବେ।
• ପେମେଣ୍ଟ ଏବଂ ଡାଟା କ୍ରିପ୍ଟୋଗ୍ରାଫିକାଲି ବନ୍ଧା (cryptographically bound) — ଆପଣ ଅନ୍ୟଟି ବିନା ଗୋଟିଏକୁ ନକଲି (forge) କରିପାରିବେ ନାହିଁ।
• Merkle trees କିମ୍ବା batch signatures ମାଧ୍ୟମରେ ଏକକ କଲ୍‌ରୁ ଲକ୍ଷ ଲକ୍ଷ କଲ୍ ପର୍ଯ୍ୟନ୍ତ scale ହୋଇପାରିବ।
• କୌଣସି ନୂତନ ଇନ୍‌ଫ୍ରାଷ୍ଟ୍ରକ୍ଚର୍‌ର ଆବଶ୍ୟକତା ନାହିଁ — କେବଳ ମାନକ କ୍ରିପ୍ଟୋଗ୍ରାଫି ଏବଂ ବିଦ୍ୟମାନ ବ୍ଲକ୍‌ଚେନ୍।
• ବିଦ୍ୟମାନ x402 ପେମେଣ୍ଟ ଫ୍ଲୋ ସହିତ କାମ କରେ।

ଦୁର୍ବଳତାସମୂହ

• Latency ବଢ଼ାଏ: ପ୍ରତ୍ୟେକ ରେସପନ୍ସ ସାଇନ୍ ହେବା ଆବଶ୍ୟକ (ଯଦିଓ ଅଧିକାଂଶ ବ୍ୟବହାର କ୍ଷେତ୍ର ପାଇଁ ଗ୍ରହଣଯୋଗ୍ୟ)।
• ପ୍ରୋଭାଇଡର୍ ସାଇଡ୍‌ରେ ସୁରକ୍ଷିତ key management ଆବଶ୍ୟକ — ଲିକ୍ ହୋଇଥିବା secret keys ଗୁଡ଼ିକ ବିଶ୍ୱାସକୁ ଅସିଦ୍ଧ କରିଦିଏ।
• କ୍ଲାଏଣ୍ଟମାନେ signature verification କାର୍ଯ୍ୟକାରୀ କରିବା ଆବଶ୍ୟକ (ଆରମ୍ଭ କରୁଥିବା ଲୋକଙ୍କ ପାଇଁ ଏହା ସହଜ ନୁହେଁ)।
• API ପ୍ରୋଭାଇଡର୍‌ମାନଙ୍କୁ ଭୁଲ ଡାଟା ସାଇନ୍ କରିବାରୁ ରୋକିପାରିବ ନାହିଁ (ବିଶ୍ୱାସ public key ଉପରେ ଅଛି, ପ୍ରୋଭାଇଡର୍‌ଙ୍କ ସାଧୁତା ଉପରେ ନୁହେଁ)।
• API contract ରେ ଜଟିଳତା ଯୋଡ଼େ — କ୍ଲାଏଣ୍ଟ ଏବଂ ସର୍ଭର୍ payload format ଉପରେ ସହମତ ହେବା ଆବଶ୍ୟକ।

ସାବଧାନତା

ନାମଗୁଡ଼ିକ app.example.com, REPLACE_WITH_VAULT_REFERENCE, REPLACE_WITH_YOUR_PUBLIC_KEY, ଏବଂ ଏଠାରେ ଦେଖାଯାଇଥିବା ସମସ୍ତ transaction ID ଗୁଡ଼ିକ placeholders ଅଟନ୍ତି। ଆପଣଙ୍କ କୋଡ୍‌ରେ କେବେବି secret keys, API secrets, କିମ୍ବା ବାସ୍ତବ credentials ଗୁଡ଼ିକୁ ହାର୍ଡକୋଡ୍ କରନ୍ତୁ ନାହିଁ। ପ୍ରୋଡକ୍ସନ୍‌ରେ ନିୟୋଜିତ କରିବା ପୂର୍ବରୁ ସର୍ବଦା ଗୋଟିଏ ଲୋକାଲ୍ ଟେଷ୍ଟ ଏନ୍‌ଭାଇରନ୍‌ମେଣ୍ଟ ସହିତ signature verification ପରୀକ୍ଷା କରନ୍ତୁ। Private keys ଗୁଡ଼ିକୁ secrets vault (HashiCorp Vault, AWS Secrets Manager, କିମ୍ବା ସଦୃଶ) ରେ ଷ୍ଟୋର୍ କରନ୍ତୁ, environment variables କିମ୍ବା source control ରେ କେବେବି ନୁହେଁ। ନିଜ ବିପଦରେ ଆଗକୁ ବଢ଼ନ୍ତୁ ଏବଂ ବାସ୍ତବ ପେମେଣ୍ଟ ଗ୍ରହଣ କରିବା ପୂର୍ବରୁ testnet ଏନ୍‌ଭାଇରନ୍‌ମେଣ୍ଟରେ କାର୍ଯ୍ୟକାରିତାକୁ ସମ୍ପୂର୍ଣ୍ଣ ଭାବରେ ଯାଞ୍ଚ କରନ୍ତୁ।

ବାରମ୍ବାର ପଚରାଯାଉଥିବା ପ୍ରଶ୍ନଗୁଡ଼ିକ

• ଯଦି ଜଣେ API ପ୍ରୋଭାଇଡର୍‌ଙ୍କ private key compromised ହୋଇଯାଏ ତେବେ କ’ଣ ହେବ?
• ମୁଁ ଏକାଧିକ API କଲ୍‌କୁ ଗୋଟିଏ ସାଇନ୍‌ଡ୍ ରସିଦ୍‌ରେ batch କରିପାରିବି କି?
• ମୁଁ JavaScript ବ୍ୟତୀତ ଅନ୍ୟ ଭାଷାଗୁଡ଼ିକରେ କିପରି signature ଯାଞ୍ଚ କରିବି?
• ମୋତେ ରେସପନ୍ସର ପ୍ରତ୍ୟେକ field କୁ ସାଇନ୍ କରିବାକୁ ପଡ଼ିବ ନା କେବଳ ଡାଟାକୁ?
• ସିଗ୍ନେଚର୍ ସାଇନ୍ ଏବଂ ଯାଞ୍ଚ କରିବାର performance overhead କେତେ?
• ପ୍ରତି-କଲ୍ ପରିବର୍ତ୍ତେ ନିର୍ଦ୍ଦିଷ୍ଟ ସବ୍‌ସ୍କ୍ରିପସନ୍ ଚାର୍ଜ କରୁଥିବା API ଗୁଡ଼ିକ ସହିତ ଏହା କାମ କରିପାରିବ କି?
• ପ୍ରୋଡକ୍ସନ୍‌ରେ ଏଜେଣ୍ଟମାନେ signature verification ବିଫଳତାକୁ କିପରି ସମ୍ଭାଳନ୍ତି?
• Ed25519 ହେଉଛି କେବଳ ସାଇନିଂ ଆଲଗୋରିଦମ୍ ଯାହା ମୁଁ ବ୍ୟବହାର କରିବା ଉଚିତ୍, ନା ଅନ୍ୟଗୁଡ଼ିକ ଗ୍ରହଣଯୋଗ୍ୟ?

ଟ୍ୟାଗ୍‌ଗୁଡ଼ିକ

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