Title: X402 വിശദീകരണം: AI ഏജന്റുകൾക്കായുള്ള HTTP നേറ്റീവ് മൈക്രോപേയ്മെന്റുകൾ
സാധാരണ ഒരു API കോളിനെ ഓൺ-ചെയിൻ (on-chain) മൈക്രോപേയ്മെന്റാക്കി മാറ്റുന്നതിനായി X402 സ്പെസിഫിക്കേഷൻ സ്റ്റാൻഡേർഡ് HTTP 402 Payment Required സ്റ്റാറ്റസിനെ പുനരുപയോഗിക്കുന്നു. AI ഏജന്റുകൾക്ക് ഇനി മനുഷ്യസഹായമില്ലാതെ തന്നെ LLM ക്വറികൾക്കോ (queries) ഡാറ്റാ ഫീഡുകൾക്കോ വേണ്ടിയുള്ള ഫീസുകൾ സെറ്റിൽ ചെയ്യാൻ കഴിയും. കൂടാതെ, പ്രൊവൈഡർമാർക്ക് ഒരു പ്രത്യേക ഇൻവോയിസിംഗ് സിസ്റ്റം നിർമ്മിക്കാതെ തന്നെ ഓരോ റിക്വസ്റ്റിനും അനുസരിച്ച് ചാർജ് ചെയ്യാൻ സാധിക്കും.
എന്തുകൊണ്ടാണ് AI ഏജന്റുകൾക്ക് ഒരു പേയ്മെന്റ് പ്രോട്ടോക്കോൾ ആവശ്യമായിരിക്കുന്നത്?
ഓട്ടോണമസ് ഏജന്റുകൾ (Autonomous agents) ലാംഗ്വേജ് മോഡലുകൾ, വെബ് സെർച്ച് ടൂളുകൾ, പ്രൊപ്രൈറ്ററി ഡാറ്റാ സ്രോതസ്സുകൾ എന്നിവയെ ഒന്നിച്ച് ചേർത്ത് പ്രവർത്തിക്കുന്നു. ഈ ഓരോ ഘട്ടത്തിനും ചിലവ് വരുന്നുണ്ട്—ഒരു മോഡലിന് വേണ്ടിയുള്ള പെർ-ടോക്കൺ ഫീസുകളോ അല്ലെങ്കിൽ ഒരു മാർക്കറ്റ് ഡാറ്റാ API-ക്ക് വേണ്ടിയുള്ള പെർ-കോൾ ചാർജുകളോ ആകാം ഇത്. ഇന്നത്തെ ബിസിനസ് മോഡലുകൾ സബ്സ്ക്രിപ്ഷൻ അക്കൗണ്ടുകളുമായി ബന്ധിപ്പിച്ച API കീകൾ, മാനുവൽ ക്രെഡിറ്റ് ടോപ്പ്-അപ്പുകൾ, അല്ലെങ്കിൽ പോസ്റ്റ്-ഹോക് ബില്ലിംഗ് (post-hoc billing) എന്നിവയെയാണ് ആശ്രയിക്കുന്നത്. ഈ രീതികൾ ഓട്ടോണമസ് ഏജന്റുകളുടെ "മനുഷ്യസഹായമില്ലാത്ത" (no-human) വാഗ്ദാനത്തിന് വിരുദ്ധമാണ്, കൂടാതെ പ്രൊവൈഡർമാർക്ക് പ്രവർത്തനപരമായ അധികഭാരം (operational overhead) വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു.
X402 ഇതിനൊരു പരിഹാരം നൽകുന്നു: ഇത് മറ്റേതൊരു HTTP കോളിനെപ്പോലെ തന്നെ തോന്നിക്കുന്ന ഒരു റിക്വസ്റ്റ്-റെസ്പോൺസ് ഫ്ലോ ആണ്, എന്നാൽ ഇതിൽ പബ്ലിക് ബ്ലോക്ക്ചെയിനിൽ രേഖപ്പെടുത്തുന്ന ഒരു ഇൻബിൽറ്റ് പേയ്മെന്റ് ഘട്ടവും ഉൾപ്പെടുന്നു. ക്ലയന്റിന് സെർവർ നിർദ്ദേശിക്കുന്ന ചെയിനിൽ ഒരു ട്രാൻസാക്ഷൻ സൈൻ ചെയ്യാനും ബ്രോഡ്കാസ്റ്റ് ചെയ്യാനും കഴിയുക എന്നത് മാത്രമാണ് ഇതിന്റെ ഏക നിബന്ധന.
X402 ഹാൻഡ്ഷേക്ക് (handshake) വിശദമായി
- ആദ്യ റിക്വസ്റ്റ് (Initial request) – ഏജന്റ് പെയ്ഡ് എൻഡ്പോയിന്റിലേക്ക് (paid endpoint) സാധാരണ രീതിയിലുള്ള ഒരു GET അല്ലെങ്കിൽ POST അയക്കുന്നു. പ്രത്യേക ഹെഡറുകൾ ആവശ്യമില്ല.
- സെർവർ 402-ലൂടെ മറുപടി നൽകുന്നു – റെസ്പോൺസിൽ 402 സ്റ്റാറ്റസും താഴെ പറയുന്നവ ഉൾക്കൊള്ളുന്ന ഒരു JSON ബോഡിയും ഉണ്ടായിരിക്കും:
amount– സെർവർ പ്രതീക്ഷിക്കുന്ന ഫീസ്, ഏറ്റവും ചെറിയ ടോക്കൺ യൂണിറ്റിൽ;token– ERC-20 (അല്ലെങ്കിൽ സമാനമായ) കോൺട്രാക്ട് അഡ്രസ്;chain– പേയ്മെന്റ് രേഖപ്പെടുത്തേണ്ട ബ്ലോക്ക്ചെയിൻ ഐഡന്റിഫയർ;- ഓപ്ഷണൽ
nonce– റീപ്ലേ അറ്റാക്കുകൾ (replay attacks) തടയാനുള്ള ഒരു യുണീക് വാല്യൂ.
- ക്ലയന്റ് പേയ്മെന്റ് തയ്യാറാക്കുന്നു – ഏജന്റ് ടോക്കൺ അഡ്രസ്സും ചെയിനും അതിന്റെ പോളിസികൾക്കനുസരിച്ച് (ഉദാഹരണത്തിന്, വിശ്വസനീയമായ ചെയിനുകൾ മാത്രം) പരിശോധിക്കുന്നു. തുടർന്ന്, ആവശ്യമായ തുക സെർവർ നൽകിയ അഡ്രസ്സിലേക്ക് മാറ്റുന്ന ഒരു ട്രാൻസാക്ഷൻ നിർമ്മിക്കുകയും, അതിന്റെ പ്രൈവറ്റ് കീ ഉപയോഗിച്ച് സൈൻ ചെയ്ത് ബ്രോഡ്കാസ്റ്റ് ചെയ്യുകയും ചെയ്യുന്നു.
- പേയ്മെന്റ് ഹാഷ് സമർപ്പിക്കുന്നു – ട്രാൻസാക്ഷൻ ഹാഷ് ലഭ്യമാകുമ്പോൾ, ക്ലയന്റ് യഥാർത്ഥ റിക്വസ്റ്റ് വീണ്ടും അയക്കുന്നു, ഇത്തവണ ഹാഷ് അടങ്ങിയ ഒരു
X-Paymentഹെഡർ കൂടി ചേർക്കുന്നു. പേലോഡ് (payload) മാറ്റമില്ലാതെ തന്നെ തുടരുന്നു. - സെർവർ ഓൺ-ചെയിനിൽ പരിശോധിക്കുന്നു – തുക, ടോക്കൺ, ചെയിൻ, നോൻസ് (nonce) എന്നിവയുമായി പൊരുത്തപ്പെടുന്ന ഒരു കൺഫേംഡ് ട്രാൻസ്ഫർ ബ്ലോക്ക്ചെയിനിൽ സെർവർ തിരയുന്നു. പൊരുത്തപ്പെടുന്ന ഒന്നുകാണുകയാണെങ്കിൽ, 200 OK സ്റ്റാറ്റസോടെ ആവശ്യപ്പെട്ട ഡാറ്റ സെർവർ തിരികെ നൽകുന്നു.
കസ്റ്റം ഹെഡറുകൾ സപ്പോർട്ട് ചെയ്യുന്നതും ഒരു ബ്ലോക്ക്ചെയിൻ SDK ഉപയോഗിക്കാൻ കഴിയുന്നതുമായ ഏത് HTTP ക്ലയന്റ് ലൈബ്രറിയും ഈ ഘട്ടങ്ങൾ പൂർത്തിയാക്കാൻ കഴിയും. ഇതിനായി പുതിയൊരു ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോലോ കസ്റ്റം സോക്കറ്റ് ലെയറോ ആവശ്യമില്ല.
ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ (Trade-offs)
- ലേറ്റൻസി (Latency) – പബ്ലിക് ചെയിൻ കൺഫർമേഷൻ കാലതാമസം ഉണ്ടാക്കിയേക്കാം.
- ഗ്യാസ് ചിലവ് (Gas costs) – കുറഞ്ഞ ചിലവുള്ള ചെയിനുകളിൽ പോലും ഗ്യാസ് ചാർജ് ഉണ്ട്; $0.001-ൽ താഴെയുള്ള പേയ്മെന്റുകൾ ലാഭകരമായിരിക്കില്ല.
- സങ്കീർണ്ണത (Complexity) – പരാജയപ്പെട്ട ട്രാൻസാക്ഷനുകളും ചെയിൻ റീഓർഗനൈസേഷനുകളും (chain reorganizations) ഏജന്റുകൾ കൈകാര്യം ചെയ്യേണ്ടതുണ്ട്; ശക്തമായ ഒരു റീട്രൈ ലോജിക് (retry logic) അത്യാവശ്യമാണ്.
- സുരക്ഷ (Security) – നോൻസ് റീപ്ലേ അറ്റാക്കുകളെ തടയുന്നു, എങ്കിലും ഏജന്റുകൾ അവരുടെ പ്രൈവറ്റ് കീകൾ സുരക്ഷിതമായി സൂക്ഷിക്കേണ്ടതുണ്ട് കൂടാതെ ബന്ധമില്ലാത്ത സേവനങ്ങളിൽ അവ വീണ്ടും ഉപയോഗിക്കുന്നത് ഒഴിവാക്കുകയും വേണം.