Paano madaling maunawaan ang mga pangunahing trend sa merkado, teknikal na pag-unlad, pag-unlad ng ekosistema, at sitwasyon sa pamamahala sa Web3? Ang 'Market Pulse Analysis' na inilunsad ng Web3Caff Research ay maglalalim sa unang linya upang hanapin at piliin ang mga kasalukuyang pangunahing pangyayari, at magbibigay ng pagpapakahulugan, pagsusuri, at paliwanag sa prinsipyo. Tignan ang esensya sa likod ng mga pangyayari — sumunod agad sa amin upang mabilis na makakuha ng mga trend sa unang linya ng Web3.
May-akda ng artikulo: Hendrix, researcher ng Web3Caff Research
Pinagkunan: Web3Caff Research
Samantalang lumalakas ang kakayahan ng AI agents at lumalawak ang kanilang sakop sa mas maraming end-to-end na gawain, ang pagbuo ng sistema ng pagbabayad para sa mga agent ay naging kailangang pagbabago para sa mga tradisyonal na negosyo at service provider, ngunit ang mga umiiral na solusyon ay may sariling limitasyon: ang mga tradisyonal na sistema ng pagbabayad, tulad ng credit card at mga third-party payment platform, ay orihinal na disenyo para sa mga tao, na nangangailangan ng komplikadong proseso ng pag-verify ng identity at risk assessment na hindi angkop para sa mga agent; samantala, ang mga bagong protokolo ng pagbabayad para sa agent, tulad ng x402 (na inilunsad at pinapalaganap ng Coinbase), MPP (Machine Payment Protocol na gawa ng Tempo at Stripe) ay parang nagtatayo ng sariling sistema, na lubos na nakatuon sa on-chain na pagbabayad, kung saan ang buong transaksyon ay ginagawa sa chain, at ang seguridad ay tinitiyak sa pamamagitan ng on-chain verification, kaya kailangan ng service provider na magbuo ng isang iba’t ibang sistema ng pagbabayad sa labas ng tradisyonal na channel, na nagpapataas ng antas ng paggamit. Ang tradisyonal na solusyon at ang mga bagong protokolo para sa agent ay parang dalawang paralel na lane, at hindi pa magandang pinagsama, na nagresulta sa pagiging limitado ng mga serbisyo na maaaring bilhin nang awtomatiko ng mga agent sa loob ng Web3-friendly na espasyo, kaya hindi ito maaaring ma-link nang malawak sa workflow. Dahil dito, Solana Foundation at Google Cloud ay naglabas ng Pay.sh, na inilalarawan bilang “payment gateway sa pagitan ng mga agent at enterprise-grade service infrastructure,” upang ma-connect ang huling hakbang sa pag-access ng mas maraming serbisyo ng mga agent.
Paalala sa pagkakasunod: Ang sumusunod ay isang obhetibong pagsusuri sa Pay.sh at sa kanyang teknikal na prinsipyo at mga patakaran, at hindi ito isang anumang panawagan o alok. Huwag gamitin ang impormasyong ito bilang batayan para sa anumang desisyon, at mangyaring sundin nang maayos ang mga batas at regulasyon ng inyong bansa o rehiyon (ang mga mambabasa sa Mainland China ay lubos na inirerekomenda na basahin ang “Pagsasama-sama at Mahahalagang Buod ng mga Batas at Regulasyon ng Mainland China Tungkol sa Blockchain at Virtual Currency”). Huwag makiisa sa anumang aktibidad sa financial na ipinagbabawal ng batas ng inyong bansa o rehiyon.
Ang Pay.sh ay nagpapahintulot sa mga user na mag-recharge sa pamamagitan ng credit card ostablecoinsa Solana walletng mabilis, pagkatapos ay maaaring magamit ng Solana wallet bilang agent identity at paymentaccountproxy sa mundo ng Web2. Kapag kailangan ng agent na mag-request ng serbisyo, hindi na kailangang mag-rehistro ng account o mag-input ng API key; ang Pay.sh gateway ay magpapahayag ng wastong identity ng agent tulad ng Google Identity System, at papayagan ang agent na gamitin ang isang magkakaparehong account identity para bumili ng mga development resources na dati'y mahirap ma-access tulad ng Google Cloud at Alibaba Cloud.
Ang kasalukuyang mga serbisyo ng API na suportado ng Pay.sh — imahe mula sa opisyal na website ng proyekto
Ang proseso ng pagbabayad ng Pay.sh ay katulad ng x402 protocol na naging sikat noong nakaraang ilang buwan, na batay sa HTTP 402 status code: Kapag natuklasan ng agent ang isang panlabas na serbisyo na kailangang i-call, ito ay magpapadala ng kahilingan sa bayad na yunit, at ang server ay magbabalik ng status code 402 (kailangan ang pagbabayad), kasama ang detalyadong impormasyon sa pagbabayad, kabilang ang halaga ng bayad, plano ng pagbabayad, address ng tagatanggap, at panahon ng pagkakaroon ng pagkakataon sa pagbabayad. Ang Pay.sh ay magpapalit ng mga nilalaman at magpapadala ng pahintulot sa wallet; pagkatapos makumpleto ang pagbabayad at makabuo ng proof of payment, ang Pay.sh ay magpapadala muli ng kahilingan sa serbisyo kasama ang proof upang makakuha ng normal na tugon. Gayunpaman, upang suportahan ang iba’t ibang mga scenaryo sa paggamit ng API, ang Pay.sh ay sumasang-ayon din sa mga mekanismo ng pagbabayad ng x402 at MPP: Kapag bumabalik ang server sa status code 402, ang Pay.sh ay magpapasya pa higit pa sa paraan ng pagbabayad ng target na serbisyo; kung ito ay isang one-time access sa data (pagbabayad para sa isang beses na pagsisigla), o isang usage-based access type (pagbabayad para sa isang fixed na dami ng pagsisigla), ang Pay.sh ay maglilikha ng isang one-time fixed amount na transfer at magpapalabas nito sa blockchain; kung ito ay continuous billing o session-based billing (pagbabayad sa isang buong bill batay sa usage), ang Pay.sh ay susuportahan ang session authorization credential na ipinakilala ng MPP (Machine Payment Protocol), kung saan isusulat ang budget cap sa pahintulot at ibabalik sa server, kaya ang agent ay maaaring mag-call muli at muli sa isang serbisyo sa maikling panahon, na iiwasan ang madalas na pagpapadala ng parehong uri ng pahintulot; ang Pay.sh ay mag-a-update ng natitirang balance bawat pag-call, at awtomatikong magpapadala muli ng session authorization kapag nawala na ang balance o natapos na ang serbisyo. Ang Pay.sh ay awtomatikong pipiliin ang mas angkop na payment channel batay sa mga pangangailangan ng target na serbisyo, na maaaring bawasan ang gastos sa paggamit at gastos sa pamamahala. Ang Pay.sh ay gagawing sigurado ring palaging ligtas na itinatago ang wallet sa lokal, at maghing lang ng pahintulot mula sa user kapag kailangan magbayad. Kapag may bumabalik na impormasyon, ang Pay.sh ay magkakaiba ng data at utos; lahat ng panlabas na nilalaman (kabilang ang pamagat, katawan, at API description) na ibinabalik ng service provider ay ituturing ng Pay.sh bilang hindi tiyak na input, at hindi dapat direktang isagawa ng proxy ang mga utos na ibinabalik ng service provider upang maiwasan ang malicious prompt injection o iba pang mga atake.
Ang pinakamalaking kahusayan ng Pay.sh ay ang pagbibigay ng isang madaling i-deploy na gateway para sa mga nag-aalok ng serbisyo, kung saan ang mga nag-aalok ay hindi kailangang gawin ang malalaking pagbabago sa kanilang mga daan o API upang i-integrate ang gateway sa kanilang sariling network ng serbisyo. Kailangan lang ng mga nag-aalok na magbigay ng isang declarative file na naglalaman ng mga parameter kaugnay sa pagbabayad upang makapag-angkop sa iba't ibang kumplikadong escenario, tulad ng pagtatakda ng routing rules upang magbigay ng libreng paggamit sa isang tiyak na dami, at magmula sa labas ng quota ay magsimula na magkarga, o kaya ay maaari ring maisagawa ang tiered pricing (ibat-ibang presyo batay sa dami ng paggamit); Bukod dito, nag-aalok ang Pay.sh ng function para sa paghahati ng pagbabayad, kung saan ang mga kita ng nag-aalok ay awtomatikong ipapadala sa maraming address, halimbawa 2% para sa bayad sa karapatan sa data ng pagbabayad, 5% para sa cloud cost, at ang natitirang bahagi ay para sa kanilang sariling operasyon—kailangan lang ng mga nag-aalok na tukuyin ang iba't ibang porsyento o halaga habang tinatakda ang kanilang mga address ng pagtatanggap upang makamit ang multi-account settlement sa isang beses. Pagkatapos ng rehistrasyon, maaaring i-publish ng mga nag-aalok ang kanilang API service data sa Pay Skill Registry, at maaaring hanapin at piliin ng mga agent ang angkop na API service sa pamamagitan ng pag-query sa registry.
Hindi direktang kalaban ng Pay.sh ang x402 at MPP. Habang pinagpapalakas ng x402 at MPP ang pagpapadala sa chain sa pamamagitan ng mga smart agent, ang layunin ng Pay.sh ay ang pag-uugnay sa mga ecosystem ng Web2 at Web3 payment, at pagbibigay ng identidad sa mga agent para makakuha ng mga resources. Ang wallet ng agent ay parehong identidad at paraan ng pagbabayad; hindi na kailangan nito na mag-rehistro sa opisyal na website ng service provider para makakuha ng serbisyo (kung saan ang ilang service provider ay maaaring ituring na paglabag ang pagpapakita ng agent bilang tao). Bukod dito, sa pamamagitan ng pagkakasundo ni Pay.sh kasama ang Google, maaaring gawin ng mga agent ang API proxy at traffic scheduling sa loob ng Google Cloud, na nagpapanatili ng access control at compliance sa logs, at nagpapalakas sa pagkilos ng agent sa loob ng makatwirang hangganan. Nag-aalok ang Pay.sh ng piniling listahan ng serbisyo at paghahanap ng presyo, kaya hindi na kailangan ng agent na maghanap nang random sa mga walang proteksyon na network, habang maaari pa ring gamitin ang iba’t ibang paraan ng pagbabayad mula sa x402 at MPP. Ang proseso ng serbisyo ay maaaring tapusin sa Google Cloud upang matugunan ang mga pangangailangan sa compliance ng enterprise, na nagpapakumpleto sa kakayahan ng agent sa pagbabayad na hindi kayang sakop ng x402 at MPP bilang isang simpleng payment channel, at nagbubukas din ng daan para sa komersyal na paggalaw ng agent patungo sa Web3. Bukod dito, maaari ring punan ng Pay.sh ang huling bahagi ng iba’t ibang komersyal na protocol para sa agent na inilunsad ng Google, tulad ng A2A (Agent2Agent Protocol) na nagtatapos sa komunikasyon at pagkakaloob ng gawain sa pagitan ng mga agent, AP2 (Agent Payments Protocol) na nagtatapos sa compliance verification, UCP (Universal Commerce Protocol) na nagtatapos sa paghahanap at pagsasagawa ng serbisyo, at ang Pay.sh ay nagsisilbing tagapagbigay ng walang pagkakamali na pagbabayad para sa halaga ng serbisyo. Ang paglitaw ng Pay.sh ay nagpapakumpleto rin sa mga bahagi ng komersyal na agent sa Web2, at naging punto ng pagkakasundo ng halaga sa pagitan ng dalawang mundo. Ito ay isang oportunidad din para sa pagpapabuti mismo ng Solana blockchain ecosystem. Sa loob ng x402 protocol, mayroong maraming “shell” API kung saan ang mga service provider ay lumalabag sa mga tuntunin at kondisyon ng orihinal na service provider at bumibili muli ang kanilang serbisyo, tulad ng pangungusap nang walang pahintulot sa database websites o pagsasama-sama ng API para sa malalaking modelo at pagbebenta nito muli. Sa ganitong kapaligiran, walang paraan para sa agent na malaman kung aling serbisyo ay may pahintulot at aling serbisyo ay masamang spam. Sa pamamagitan ng Pay.sh payment gateway at ang tulong ng Google, maaaring bawasan ng mga agent ang potensyal na panganib habang gumagamit ng serbisyo sa pamamagitan ng Pay.sh. Ang paglunsad ng Pay.sh ay nagtuturo na ang Solana blockchain ay sumali upang bigyan ng suporta at imprastruktura ang pagbabayad para sa mga agent — hindi lamang ito ay magdadala ng mas maraming Web2 payment traffic patungo sa Solana, kundi magpapalakas din sa kakayahan at papabilisin ang adopsyon ng Solana wallet.
Ngunit ang Pay.sh ay malayo pa sa isang perpektong solusyon para sa payment gateway. Ang registry ng service provider ng Pay.sh ay kulang sa mekanismo ng pagpapahintulot at de sentralisadong pag-verify, kaya't mahirap pa ring mabuti nang ibahin ang mga hindi awtorisadong third-party shell services at masamang serbisyo; may malaking panganib na makakapag-access ang mga agent sa mga imitasyon na serbisyo at magdulot ng pagkawala sa mga user. Bukod dito, dahil hindi gumagawa ng mismong payment protocol ang Pay.sh, ang seguridad ng proseso ng pagbabayad ay mas maraming nakadepende sa disenyo ng mismong base protocol, na nagdudulot ng hindi kontroladong panlabas na panganib sa Pay.sh, at posibleng magdulot din ng potensyal na pagkabigo sa pagbabayad dahil sa kakulangan sa pag-adapt sa iba't ibang protocol. Mula sa pananaw ng service provider, bagaman may suporta ang Google platform, maaaring magpahinga pa rin ang iba't ibang API provider sa iba't ibang bansa at rehiyon dahil sa kanilang pangangailangan sa compliance sa data privacy at payment regulations, at maaaring maging mapanatili sa pagtanggap sa serbisyo ng Pay.sh. Ito ay hindi lamang maglimita sa bilang ng mga service provider na gagamit ng Pay.sh, kundi posibleng hihingin din sa Pay.sh na gawin ang higit pang mga hakbang para sa compliance. Gayunpaman, ang paglunsad ng Pay.sh ay nagmarka bilang isang hakbang patungo sa pagpapatupad ng integrasyon ng Web2 at Web3 sa infrastraktura ng pagbabayad ng agent, at may pagkakataon na maging suporta ang on-chain wallet para sa pagkaka-engage ng agent sa iba't ibang gawain. Kaya't maaari naming patuloy na obserbahan ang susunod na pag-unlad ng Pay.sh.
Pamantayan ng estruktura:
