ಸಹಿ ಮಾಡಿದ ರಸೀದಿಗಳೊಂದಿಗೆ ನಿಮ್ಮ API ಡೇಟಾವನ್ನು ಸಾಬೀತುಪಡಿಸುವುದು — ಪಾವತಿ ಪರಿಶೀಲನೆಯನ್ನು ಮೀರಿದ್ದು

ಏಜೆಂಟ್-ಟು-ಏಜೆಂಟ್ ಪಾವತಿಗಳ ಹೊಸ ಪ್ರಪಂಚ

ಮೊದಲ ಬಾರಿಗೆ, ಎಐ ಏಜೆಂಟ್‌ಗಳು ಸ್ವಾಯತ್ತವಾಗಿ ವಸ್ತುಗಳಿಗೆ ಪಾವತಿಸಬಹುದು. x402 ಪ್ರೋಟೋಕಾಲ್ HTTP 402 Payment Required ಸ್ಟೇಟಸ್ ಕೋಡ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಿ, ಕ್ಲೈಂಟ್‌ಗೆ — ಮಾನವನಾಗಿರಲಿ ಅಥವಾ ಕೃತಕವಾಗಿರಲಿ — USDC ಸ್ಟೇಬಲ್‌ಕಾಯಿನ್‌ನಲ್ಲಿ ಪ್ರತಿ API ಕರೆಗೆ ಪಾವತಿಸಲು, API ಕೀಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡಲು ಮತ್ತು ಎಂದಿಗೂ ಖಾತೆಯನ್ನು ರಚಿಸದಿರಲು ಅನುಮತಿಸುತ್ತದೆ.

ಇದು ನಿಜವಾಗಿಯೂ ಜಾಣತನದ್ದಾಗಿದೆ. ಆದರೆ ಏಜೆಂಟ್ ಡೇಟಾದ ಆಧಾರದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸುವವರೆಗೆ ಯಾರೂ ಮಾತನಾಡದ ಒಂದು ಸಮಸ್ಯೆಯಿದೆ.

30 ಜೂನ್ 2026 ರ ಹೊತ್ತಿಗೆ, ನಾವು ಒಂದು ನಿರ್ಣಾಯಕ ಘಟ್ಟದಲ್ಲಿದ್ದೇವೆ. ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್‌ಗಳು ಕಾರ್ಯಗಳನ್ನು ಸಂಯೋಜಿಸುವಲ್ಲಿ ಹೆಚ್ಚು ಜಾಣವಾಗುತ್ತಿವೆ, ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್‌ಗಳನ್ನು ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು ಸದ್ಯದಲ್ಲಿಯೇ ಸೇವೆಗಳಿಗೆ ಪಾವತಿಸುವ ಸಾಮರ್ಥ್ಯವು ಅತ್ಯಗತ್ಯವಾಗುತ್ತಿದೆ. ಆದರೂ ಪ್ರಸ್ತುತ ಪಾವತಿ ಸಾಕ್ಷಿ — ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿನ ವಹಿವಾಟು — ಒಪ್ಪಂದದ ಅರ್ಧದಷ್ಟು ಭಾಗವನ್ನು ಮಾತ್ರ ದೃಢೀಕರಿಸುತ್ತದೆ: ಅಂದರೆ ಹಣದ ಕೈಬದಲಾವಣೆಯಾಗಿದೆ ಎಂದು. ಪ್ರತಿಯಾಗಿ ನೀವು ಸ್ವೀಕರಿಸಿದ ಡೇಟಾ ನೈಜವಾಗಿದೆಯೇ ಅಥವಾ ತಿದ್ದಲ್ಪಟ್ಟಿದೆಯೇ ಎಂಬುದರ ಕುರಿತು ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಏಜೆಂಟ್ ಸರಿಯಾಗಿ ಪಾವತಿಸಬಹುದು ಮತ್ತು ಆದರೂ ನಕಲಿ ಡೇಟಾದ ಆಧಾರದ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು.

ಪಾವತಿ ಸಾಕ್ಷಿಯು ಡೇಟಾವನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ

ಪ್ರತಿ ಕರೆಗೆ 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 ಪೂರೈಕೆದಾರರ ಪ್ರೈವೇಟ್ ಕೀ ರಾಜಿಗೊಳಗಾದರೆ (compromised) ಏನಾಗುತ್ತದೆ?
• ನಾನು ಬಹು API ಕರೆಗಳನ್ನು ಒಂದೇ ಸಹಿ ಮಾಡಿದ ರಸೀದಿಯಾಗಿ ಬ್ಯಾಚ್ ಮಾಡಬಹುದೇ?
• JavaScript ಹೊರತುಪಡಿಸಿ ಇತರ ಭಾಷೆಗಳಲ್ಲಿ ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದು ಹೇಗೆ?
• ನಾನು ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಫೀಲ್ಡ್‌ಗೆ ಸಹಿ ಮಾಡಬೇಕೇ ಅಥವಾ ಕೇವಲ ಡೇಟಾಗೆ ಮಾತ್ರವೇ?
• ಸಹಿ ಮಾಡುವುದು ಮತ್ತು ಸಹಿಗಳನ್ನು ಪರಿಶೀಲಿಸುವುದರ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಓವರ್‌ಹೆಡ್ ಎಷ್ಟು?
• ಪ್ರತಿ ಕರೆಯ ಬದಲು ಸ್ಥಿರ ಚಂದಾದಾರಿಕೆಯನ್ನು ವಿಧಿಸುವ API ಗಳೊಂದಿಗೆ ಇದು ಕೆಲಸ ಮಾಡಬಹುದೇ?
• ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಸಹಿ ಪರಿಶೀಲನೆ ವಿಫಲವಾದಾಗ ಏಜೆಂಟ್‌ಗಳು ಅದನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತವೆ?
• ನಾನು ಬಳಸಬೇಕಾದ ಏಕೈಕ ಸೈನಿಂಗ್ ಆಲ್ಗರಿದಮ್ Ed25519 ಮಾತ್ರವೇ, ಅಥವಾ ಇತರವುಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದೇ?

ಟ್ಯಾಗ್‌ಗಳು

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