Utafiti huu unachunguza jinsi mawakala huru wa AI wanavyoweza kuwekwa chini ya mipaka ya matumizi na kanuni za usalama wanapofikia API zinazolipiwa bila uingiliaji wa binadamu. Watafiti walitengeneza usanifu wa marejeleo wa majaribio unaoitwa APEX, unaorekebisha mbinu ya HTTP 402 “Payment Required” kuwa mtiririko wa malipo ya sarafu ya fiat unaofanana na UPI badala ya sarafu ya kripto.

Katika APEX, wakala hujaribu kwanza kufikia API iliyolindwa.Seva hutoa jibu la HTTP 402 lenye kiasi na marejeleo ya muamala ikiwa malipo hayatapokelewa.Wakala huwasiliana na mwisho wa malipo;Kikomo cha kila ombi na sera za bajeti ya kila siku huangaliwa.Ikiwa malipo yanakubaliwa, tokeni ya ufikiaji ya muda mfupi, iliyosainiwa mara moja na HMAC-SHA256 hutolewa.Wakala anaporudia ombi la API na tokeni hii, tokeni huthibitishwa, hutiwa alama kama imetumika, na data iliyolindwa hurejeshwa.

Katika majaribio katika utafiti huu, njia bila malipo na udhibiti wa sera, njia yenye malipo lakini hakuna sera, na njia yenye malipo na sera zote mbili zililinganishwa.Katika matokeo ya muhtasari ambapo sera ilitumika, matumizi yaliyoripotiwa yalipungua kutoka dola za 550 hadi dola za 400, hivyo kufikia upunguzaji wa asilimia ya 27,3.Majaribio yote ya 20 kila moja kwa tokeni zilizotumika tena na tokeni batili yalizuiwa.Kwa upande mwingine, udhibiti wa malipo na sera uliongeza ucheleweshaji wa ombi la kawaida.

Matokeo haya hayakupatikana kutoka kwa miamala halisi ya UPI.Safu ya malipo imeigwa;benki, mtoa huduma ya malipo, KYC, kufuata sheria za kifedha, na michakato halisi ya upatanisho haijaunganishwa na mfumo.Mfumo huu unaendeshwa kwenye nodi moja yenye FastAPI na SQLite.Kwa hivyo, utafiti huu si mfumo wa malipo ya kifedha ulio tayari kwa uzalishaji;ni mfano wa utafiti unaochanganya itifaki, sera ya bajeti, usalama wa tokeni, na kipimo cha majaribio katika mfumo huo mdogo.

Baadhi ya taarifa za matokeo katika utafiti huu zinapaswa pia kutafsiriwa kwa uangalifu.Thamani ya asilimia 52,8 si tu kiwango cha mafanikio ya maombi halali;ni wastani wa uzani sawa wa hali ya kawaida, matumizi ya kupita kiasi, shambulio la marudio, tokeni batili, kuisha kwa tokeni, na hali ya idempotency.Pia, jaribio linalojulikana kama "kuisha kwa tokeni" halionyeshi kwamba tokeni ambazo zimeisha muda wake zimezuiwa.

Tatizo kuu la utafiti ni lipi?

Mawakala wa akili bandia si programu tu inayotafuta taarifa.Wanaweza kupiga mwito API, kupanga foleni mawakala wengi, kununua data, na kufanya shughuli zinazozalisha matokeo kwenye mifumo ya nje.Maendeleo haya yanazua swali la ni kiasi gani wakala anaweza kutumia kwa kila mwito ya API na ni lini anapaswa kuacha kutumia bajeti yake yote.

Bei ya kawaida ya API mara nyingi inategemea usajili wa kila mwezi, bili ya mwisho wa matumizi, au vifurushi vya mikopo vilivyofafanuliwa awali.Hata hivyo, katika soko la huduma ya wakala-kwa-wakala, malipo yanaweza kuhitajika katika kiwango cha ombi kwa ajili ya hoja moja ya data, mwito ya mfano, au operesheni ya uchambuzi.

Katika mbinu ya msingi ya misimbo ya hali ya HTTP 402, malipo yanakuwa hatua katika itifaki ya jibu la ombi, badala ya shughuli tofauti ya uhasibu inayofanywa nje ya mchakato wa API.Ombi lililosalia linafikiwa na ombi la malipo linalosomeka kwa mashine;Baada ya kulipa, mteja anarudia ombi na uthibitisho wa ufikiaji.

Swali la utafiti la utafiti linaweza kufupishwa kama ifuatavyo:

Faida za Itifaki ya mbinu ya malipo ya HTTP 402 inayozingatia fedha za cryptocurrency, inaweza kutumia sera, uthibitishaji wa tokeni na ulinzi wa kucheza tena huku inayofanana na UPI ikirekebishwa kwa mtiririko wa fiat?

Ni pengo gani katika fasihi ya kisayansi lililolengwa?

Waandishi wanasema kuwa katika mifumo ya sasa kazi tano hazijaunganishwa vya kutosha katika utekelezaji ule ule wazi na unaoweza kuzalishwa tena:

• Ombi la malipo limeundwa kama HTTP 402,
• Semantiki za malipo zinazolenga Fiat,
• Sera ya matumizi ya hiari na ya mara kwa mara,
• Tokeni ya ufikiaji iliyosainiwa, iliyoratibiwa na ya matumizi moja,
• Miundombinu ya majaribio inayoweza kupimika kwa matukio ya kawaida na ya fujo.

Dai la uvumbuzi la APEX si kuunda mtandao mpya wa malipo au algoriti mpya ya kriptografia.Mchango ni kuleta vipengele hivi pamoja katika usanifu wa marejeleo ambao ni mdogo, unaotambulika, na unaofaa kwa majaribio.

Ulinganisho kati ya APEX na x402 umewasilishwaje?

Jedwali la I katika utafiti linalinganisha x402 na APEX kwenye vipengele vinne:

Jedwali hili si tathmini huru na ya kina ya bidhaa.Hakuna vigezo vya upimaji au ulinganisho wa matoleo ya kina hutolewa kwa madarasa ya "mdogo", "sehemu" na "nguvu".Kwa hivyo, jedwali linapaswa kusomwa kama njia ya waandishi ya kuweka APEX;Haipaswi kuchukuliwa kama alama bainifu ya kiufundi inayofunika maombi yote ya x402.

Ni mambo gani ambayo hayajajumuishwa katika upeo wa utafiti?

Watafiti waliondoa kwa makusudi vipengele vifuatavyo kwenye utafiti:

• Benki halisi au ushirikiano wa mtoa huduma wa malipo,
• KYC, kupambana na utakatishaji fedha haramu na taratibu za kufuata fedha,
• Hifadhidata iliyosambazwa, uvumilivu wa makosa ya nodi nyingi na kuongeza mlalo,
• Skrini za malipo ya mtumiaji wa mwisho na uzoefu wa mtumiaji,
• Hifadhi muhimu na moduli ya usalama ya vifaa,
• Usimamizi wa siri wa kiwango cha uzalishaji na mzunguko muhimu,
• Uthibitishaji rasmi wa utekelezaji wa itifaki.

Kutokana na mapungufu haya, ni sahihi zaidi kufafanua APEX kama mazingira ya majaribio ya nodi moja ambayo yanaiga semantiki za malipo za inayofanana na UPI, badala ya kuwa mfumo wa uzalishaji unaokamilisha uhamisho halisi wa pesa.

Mfumo una vipengele gani?

APEX ina mali tano kuu:

Modeli ya vitisho katika Kielelezo 1 inaonyesha nini?

Kielelezo 1 kinaonyesha njia tatu za mashambulizi kati ya nodi ya mvamizi na sehemu ya nyuma iliyolindwa:

• A1 - Tokeni isiyo sahihi: Mshambulizi hutuma tokeni ambazo zimeharibika au zilizo na sahihi batili.
• A2 - Shambulizi la kurudia: tokeni ambayo imetumiwa kwa mafanikio hapo awali imetumwa tena.
• A3 - Matumizi kupita kiasi: Wakala au mshambuliaji anajaribu kuzidi bajeti kwa mwito za malipo zinazorudiwa.

Sehemu iliyolindwa ina seva ya API, huduma ya tokeni inayotekeleza uthibitishaji na matumizi, na injini ya sera inayotekeleza ombi la kila siku na kikomo cha kila siku.

Muundo wa tishio unachukulia kuwa mshambulizi hawezi kupata ufunguo wa faragha wa HMAC kwenye seva, kurekebisha msimbo wa seva, na kuharibu faili ya SQLite moja kwa moja.Ikiwa mojawapo ya mawazo haya yamekiukwa, hitimisho la usalama katika utafiti si sahihi moja kwa moja.

Malengo ya usalama ni yapi?

• G1 - Udhibiti wa ufikiaji: Data iliyolindwa inapaswa kurejeshwa tu baada ya uthibitisho halali wa malipo.
• G2 - Uadilifu: Tokeni zilizobadilishwa au ghushi zinapaswa kukataliwa.
• G3 - Upinzani wa kurudia: Tokeni iliyotumika haipaswi kutoa ufikiaji mara ya pili.
• G4 - Utekelezaji wa sera: Maombi ambayo yanakiuka kikomo cha matumizi yanapaswa kuzuiwa kwa kubainishwa.

Matokeo success, blocked na failed zimegawanywa katika makundi matatu. Ombi lililozuiwa si kila mara hitilafu ya kiufundi ya mfumo; utekelezaji unaotarajiwa wa sera au utaratibu wa usalama pia hutoa matokeo ya “blocked”.

Usanifu wa mfumo katika Kielelezo 2 unafanyaje kazi?

Kielelezo 2 kinaonyesha mtiririko wa data kati ya wakala wa AI, seva ya API inayozalisha HTTP 402, injini ya sera, safu ya malipo inayofanana na UPI, huduma ya tokeni, na leja ya SQLite.

Katika mtiririko wa kawaida, wakala huenda kwa seva ya API kwanza.Wakati malipo yanahitajika, wakala anaelekezwa kwenye safu ya malipo.Injini ya sera hutoa uamuzi wa idhini kabla ya malipo.Huduma ya tokeni hupanga uthibitisho wa ufikiaji na inalinganisha na hali kwenye leja.Uthibitishaji wa mwisho unapofaulu, jibu lililolindwa hurejeshwa kwa wakala.

Kifungu cha maneno "UPI-kama suluhisha" kwenye mchoro hakionyeshi suluhu halisi la UPI, lakini uondoaji wa hatua ya malipo sawa na UPI katika programu.

Mzunguko kamili wa maisha katika Kielelezo 3

Mtiririko wa APEX umegawanywa katika hatua tano:

1. Ombi la wakala: Wakala anaita rasilimali iliyolindwa.
2. Ombi la HTTP 402: Hurejesha hitaji la malipo lililo na kiasi cha seva na rejeleo.
3. Upatanisho wa malipo: Wakala /pay hutuma jaribio la malipo hadi mwisho.
4. Uzalishaji wa tokeni: Tokeni iliyotiwa sahihi itaundwa ikiwa sera inaruhusu.
5. Uthibitishaji na matumizi: Tokeni hutoa ufikiaji tu kwa matumizi halali ya kwanza.

Ndege ya udhibiti inaweka kikomo na bajeti ya kila siku kwa kila ombi, na ndege ya usalama itatumia kukataliwa kwa tokeni kwa kurudiarudia.

Tabia ya vituo vya mwisho vya API

GET /data

• no_policy Data iliyolindwa bila malipo katika hali inarejeshwa moja kwa moja.
• Ikiwa hakuna tokeni, rejeleo jipya linaundwa na jibu la HTTP 402 limetolewa.
• Ikiwa tokeni ipo, saini, muda wa mwisho wa matumizi na hali ya matumizi huangaliwa.
• Maudhui yaliyolindwa yanarejeshwa tu ikiwa ukaguzi wote umefaulu.

POST /pay

• ref_idHupata kiasi, hali ya kulinganisha, na ufunguo wa hiari wa kutoweza kujitambua.
• Hutumia udhibiti wa sera kulingana na hali iliyochaguliwa.
• Huzalisha tokeni zilizoratibiwa na zilizotiwa sahihi wakati malipo yameidhinishwa.
• Inasasisha hali ndani ya shughuli ya SQLite.
• Hurejesha tokeni na metadata ya hali kwa mteja.

POST /reset

Inafuta jedwali la leja ili kuunda mwanzo safi kati ya majaribio.Mwisho huu umetumika katika mazingira ya utafiti.Ufikiaji usioidhinishwa wa mfumo wa uzalishaji unaweza kusababisha hatari kubwa kwa rekodi za malipo na ukaguzi;Utafiti hauchunguzi idhini ya uzalishaji.

Mashine ya hali imeundwaje?

Kila kumbukumbu ya malipo inapitia majimbo manne:

Mabadiliko katika SQLiteInafanywa na BEGIN IMMEDIATE shughuli.Njia hii inaweza kupunguza baadhi ya masharti ya mbio ambayo yanaweza kutokea kutokana na majaribio ya wakati mmoja ya kuandika katika mazingira ya nodi moja.Haitoi kufuli iliyosambazwa au uthabiti thabiti katika mifumo ya nodi nyingi.

Ni taarifa gani zinazohifadhiwa katika daftari?

• ref_id: Rejea ya msingi ya mchakato,
• amount: Kiasi cha malipo kilichoombwa,
• created_at: Wakati wa uumbaji,
• state: Hali ya sasa,
• token: Tokeni ya ufikiaji imetolewa,
• token_expiry: Tarehe ya mwisho wa matumizi ya tokeni,
• consumed_at: Wakati tokeni inatumiwa,
• idempotency_key: Ufunguo unaolingana na ombi la malipo linalojirudia.

Kielezo kinatumika kwa hali na sehemu za tokeni.Athari ya ukubwa wa hifadhidata kwenye muda wa kusubiri wa hoja haikupimwa katika utafiti.

Tofauti kati ya hali tatu za ulinganisho

no_policy si toleo salama dhaifu la mfumo halisi wa malipo;ni msingi wa kusubiri muda ambao unapita njia ya malipo kabisa.Kwa hiyo, kuonyesha matumizi ya dola ya sifuri haimaanishi kuokoa, kwa sababu katika hali hii, hakuna malipo yoyote yanayofanywa.

Mpangilio wa kawaida wa malipo

1. Wakala payment_with_policy kwa kuchagua GET /data mwito.
2. Seva hurejesha jibu lenye kiasi na ref_id kupitia HTTP 402.
3. Kwa taarifa hii, wakala POST /pay mwito.
4. Kwa kila ombi na sheria za bajeti za kila siku zinatathminiwa.
5. Malipo yakikubaliwa, tokeni inatolewa na hali inakuwa SETTLED.
6. tokeni ya wakala x-payment-token Hurudia ombi la data kwa kuituma kwenye kichwa.
7. Tokeni imethibitishwa na kuhamishwa hadi hali ya CONSUMED.
8. Maudhui yaliyolindwa yanarudishwa.

Njia za kushindwa katika Kielelezo 4

Kielelezo 4 kinaonyesha mwingiliano tatu tofauti wa mfululizo:

• Shambulizi la kurudia: tokeni imetumwa tena, imedhamiriwa kuliwa katika huduma ya tokeni na ufikiaji umezuiwa.
• Tokeni isiyo sahihi: Ukaguzi wa saini au umbizo haufaulu na ombi limekataliwa kabla ya utendakazi wa hifadhidata kuendelea.
• Matumizi kupita kiasi:/pay mwito inakwenda kwa injini ya sera;Kuzidisha kwa bajeti ya kila siku kunazuiwa kabla ya malipo kutokea.

Kizuizi cha bajeti kimefafanuliwaje?

Uamuzi wa kukubali ombi la APEX:Imeonyeshwa na

\[ x_i \in \{0,1\} \]

x_i=1 ombi limekubaliwa, x_i=0 inaonyesha kukataliwa.Omba gharama c_i inapowakilishwa hivyo, katika dirisha la bajeti:

\[ \sum_{i\in A} c_i \leq B \]

hali inatumika.

• Ani seti ya maombi yaliyokubaliwa.
• c_ini gharama ya fedha ya ombi la ith.
• Bni kikomo cha juu cha dirisha la bajeti husika.

Onyesho la kila siku liko katika umbizo hili:

\[ \sum_{i\in A_d} c_i \leq B_d \]

• A_dni maombi yaliyokubaliwa katika siku maalum.
• B_dndiyo bajeti ya kila siku.

Katika usanidi wa majaribio:Ilitumika kama

\[ B_d=100 \]

Kwa kuwa matokeo ya majaribio yanaripotiwa kwa dola za Marekani, thamani hii inafasiriwa kuwa kikomo cha kila siku cha dola 100 katika muktadha wa jaribio.

Hali ya malipo ya hundi ya sera inatumika kabisa kabla ya SETTLED kufanywa.Madhumuni ya mfuatano huu ni kuzuia malipo yaliyokataliwa yasionekane kama malipo yaliyokamilika kwenye leja.

Fomula ya uboreshaji kwa kuzingatia manufaa

Utafiti unaeleza tatizo la kukubalika kinadharia kwa uboreshaji ufuatao:

\[ \max_{x_i\in\{0,1\}}\sum_{i=1}^{n}u_ix_i \quad \text{kwa sharti kwamba}\quad \sum_{i=1}^{n}c_ix_i\leq B \]

• u_ini faida au kipaumbele cha ombi.
• c_ini gharama ya ombi.
• x_ini uamuzi wa kukubalika au kukataliwa.

Utekelezaji wa APEX hausuluhishi uboreshaji huu.Haipangi maombi kulingana na thamani yao ya matumizi na haitenge bajeti kwa maombi muhimu zaidi.Mfumo hutumia sera ya "uwezekano wa kwanza", ambayo inakubali ombi tu ikiwa vikwazo vinatimizwa linapokuja kwa mpangilio.

Kwa hivyo, kupunguza matumizi kwa asilimia 27,3 katika utafiti si matokeo ya uboreshaji mahiri wa bajeti ambayo huongeza manufaa.Ni matokeo ya kusimamisha malipo yanayofuata wakati kikomo kisichobadilika kinafikiwa.

Kikomo cha malipo kwa kila ombi

Kila kiasi cha malipo a kwa:Hali

\[ a\leq M \]

inatumika. Mni kiwango cha juu kinachoruhusiwa katika ombi moja.Katika majaribio:

[ M=10 ]

imetumika.Kwa hivyo, mwito moja ya API inaweza kuwa na thamani ya hadi $10.Wakati bajeti ya kila siku ni 100, malipo ya juu zaidi ya 10 yatakubaliwa katika dirisha la majaribio ikiwa maombi yote yatajazwa na 10.

Tokeni inasainiwaje?

Mzigo wa data wa tokeni unajumuisha sehemu za ref_id, amount na exp . Baada ya saini ya HMAC-SHA256 kuzalishwa, data hufungwa katika umbizo la Base64 lililo salama kwa URL.

Masharti ya uthibitishaji wa saini:

\[ \operatorname{VerifyHMAC}(payload,signature,key)=true \]

.

• payloadni sehemu ya data iliyotiwa saini ya tokeni.
• signaturendio matokeo ya HMAC-SHA256.
• keyni ufunguo wa siri wa ulinganifu wa seva.

Sahihi ya sasa inatarajiwa kutolingana wakati kiasi cha malipo, marejeleo au muda wa mwisho wa matumizi kinabadilishwa.Usalama unategemea dhana kwamba ufunguo wa faragha haujaathiriwa.

Muda wa tokeni na ufikiaji wa matumizi moja

Udhibiti wa wakati:

\[ exp\geq t_{now} \]

exp tarehe ya kumalizika muda wa tokeni, t_now inawakilisha wakati wa sasa wa seva.

Hali kabla ya kutumia tokeni:

\[ state(ref\_id)=SETTLED \]

inapaswa kuwa.Baada ya ufikiaji wa kwanza uliofanikiwa:

\[ state(ref\_id)\leftarrow CONSUMED \]

mpito unafanywa.

Muundo huu unahakikisha kwamba matumizi ya pili yamekataliwa hata kama tokeni bado ni halali kisirisiri.Kuangalia saini tu haitoshi kuzuia shambulio la mchezo wa marudio;Hali ya matumizi lazima iwekwe kwenye hifadhidata.

Kwa nini idempotency inatumiwa?

Muunganisho wa mtandao unapopotea, mteja anaweza kutuma ombi lile lile la malipo kwa sababu hakupokea jibu.Ikiwa mfumo utakubali malipo mapya kwa kila ombi la kurudiwa, muamala sawa unaweza kutoa matokeo mara mbili.

sawa na APEX ref_id na inazungusha tena tokeni iliyoundwa hapo awali katika marudio ambayo inakuja na ufunguo sawa wa idempotency.Kwa njia hii malipo sawa ya kimantiki hayajaundwa mara mbili.Ikiwa rejeleo sawa litatumwa na ufunguo tofauti wa utambulisho baada ya malipo kukamilika, ombi litakataliwa.

Ulinzi huu unafunikwa na SQLite ya nodi moja.Nodi zinazosambazwa, arifa za watoa huduma za malipo zilizocheleweshwa, au matukio ya makubaliano ya wakati mmoja hayajafanyiwa utafiti kwa majaribio.

Ucheleweshaji umegawanywaje katika vipengele?

Jumla ya ucheleweshaji ni takriban:

\[ T_{total}=T_{network}+T_{payment}+T_{policy}+T_{processing} \]

imefafanuliwa kwa namna hii.

• T_networkni wakati wa mawasiliano ya mtandao.
• T_paymentni hali ya malipo na muda wa shughuli za tokeni.
• T_policyni muda wa bajeti na udhibiti wa kiasi.
• T_processingni muda wa shughuli za hifadhidata na API.

Uhusiano huu kimawazo unaelezea vyanzo vya kuchelewa badala ya kuripoti vipengele vilivyopimwa kando.Kwa kuwa hakuna UPI halisi au muunganisho wa benki, nyakati zilizopimwa hazijumuishi muda halisi wa malipo ya mtandao wa malipo.

Rundo la teknolojia

• FastAPI, kwa uelekezaji wa API na majibu ya makosa
• SQLite kwa leja ya manunuzi ya nodi moja,
• Chatu kwa saini na ufungaji hmac, hashlib na base64 moduli,
• Kwa usanifu na kurekodi json,
• Kwa muda time na datetime,
• JSON na faili za kumbukumbu za safu mlalo kwa matokeo ya majaribio

imetumika.

Sehemu ndogo ya utegemezi inaweza kufanya mfumo kusoma kwa urahisi.Kwa upande mwingine, mtoa huduma wa malipo ya aina ya uzalishaji hana SDK, usimamizi wa siri, akiba iliyosambazwa, foleni ya ujumbe na utaratibu wa uadilifu wa ukaguzi.

Kumbukumbu zilizopangwa kwa muundo

Kila tukio muhimu logs.json imeongezwa kama laini ya JSON kwenye faili.Sehemu hizo ni pamoja na wakati, aina ya tukio, sehemu ya mwisho, kitambulisho cha ombi, marejeleo, kiasi, hali, uhalalishaji, aina ya shambulio na muda wa kusubiri.

Umbizo hili hurahisisha utengenezaji wa majedwali na grafu baada ya jaribio.Hata hivyo, usemi "ambatisha-pekee" haumaanishi logi isiyoweza kubadilika kwa njia fiche.Hakuna uadilifu wa faili, mnyororo wa saini au hazina ya ukaguzi wa nje inatumika;Uharibifu wa faili wa moja kwa moja haujumuishwi kwenye mtindo wa tishio.

Mpangilio wa jaribio

Kila hali ya kulinganisha iliendeshwa katika hali sita:

Inaelezwa kuwa maombi ya 120 yanatekelezwa katika kila hali na maombi ya 360 kwa jumla yanatekelezwa kwa njia tatu.Vipimo ni kiwango cha mafanikio, idadi ya maombi yaliyozuiwa na kushindwa, wastani wa kusubiri, asilimia ya muda wa kutegemewa wa 95, muda wa kusubiri wa p95, maombi kwa sekunde na jumla ya matumizi.

Ni marudio mawili tu yalifanywa.Fomula ambayo vipindi vya kujiamini vinakokotolewa, iwapo maombi yanazingatiwa kama sampuli huru, maelezo ya maunzi, mfumo wa uendeshaji na mbegu nasibu hazijafichuliwa.

Jedwali la jumla la ulinganisho

Kiwango cha mafanikio cha asilimia 52,8 kilihesabiwaje?

Maandishi yanaelezea Jedwali II kama "matokeo ya jumla yaliyopimwa."Hata hivyo, asilimia ya thamani ya 52,8 inalingana na wastani ulio na uzito sawa wa viwango vya mafanikio vya matukio sita:

\[ \frac{0{,}500+0{,}667+0+0+1+1}{6} \approx 0{,}528 \]

Nambari za ombi za matukio si sawa.Idadi ya mafanikio katika hali ya malipo na sera inapokokotolewa moja kwa moja kutoka kwa hesabu za ombi:

• Kawaida: 20,
• Matumizi kupita kiasi: 20,
• Rudia: 0,
• tokeni batili: 0,
• Muda wa tokeni: 10,
• Idempotency: 10

jumla ni 60.Kati ya maombi yote ya 120, hii inalingana na asilimia ya kiwango cha mafanikio cha ombi la 50.

Ingawa wastani uliopimwa sawa wa viwango vya hali ya malipo lakini hakuna modi ya sera ni asilimia 66,7, mafanikio juu ya idadi ya maombi ni 90/120, yaani asilimia 75.

Kwa hivyo, thamani ya asilimia 52,8 haiwezi kufasiriwa kama "asilimia 52,8 ya maombi halali yalifanikiwa."Thamani ni wastani wa scenario-macro, ikiwa ni pamoja na matukio ya mashambulizi.

Matokeo ya hali zenye utekelezaji wa sera

Kwa nini hali ya kawaida ina mafanikio ya asilimia 50 pekee?

Katika hali ya kawaida, kila jaribio lina ombi la malipo la 20, kikomo cha dola 100 kwa siku, na kiasi cha dola 10 kwa kila ombi.Sera inaporuhusu malipo ya kwanza ya 10, bajeti hufikia $100;Ombi linalofuata la 10 limezuiwa.

Kukubali 20 ya jumla ya ombi la 40 katika majaribio mawili huleta mafanikio ya asilimia 50.Matokeo haya hayaonyeshi kuwa mfumo unapoteza maombi ya kawaida kwa nasibu, lakini unaanza baada ya nusu ya kikomo cha bajeti kilichowekwa.

Hali ya matumizi kupita kiasi

Kwa kuwa maombi ya 15 yanapatikana katika kila jaribio, malipo ya kwanza ya 10 yanakubaliwa na maombi yaliyosalia ya 5 yamezuiwa.Majaribio mawili ya kukubali 20 na kuzuia 10 hutokea:

\[ \frac{20}{30}\approx 0{,}667 \]

Matokeo haya yanaunga mkono kwamba sera inafanya kazi kwa uthabiti.Walakini, haionyeshi kuwa inaboresha maamuzi changamano ya matumizi kwa viwango tofauti na maadili ya faida.

Matokeo ya shambulio la kurudia

Majaribio yote ya 20 tena yenye tokeni sawa na iliyoisha wakati wa utekelezaji yalizuiwa.Muda wa wastani wa kusubiri unaripotiwa kama 135,1 ms.

Jaribio linahusisha kutuma tokeni sawa katika kiwango kidogo.Wizi wa tokeni, matumizi ya tokeni na mteja mwingine kabla ya matumizi, hali ya mbio za nodi nyingi, au upotevu wa hali ya hifadhidata haujajaribiwa.

Matokeo ya tokeni batili

Tokeni nzima ya 20 yenye umbizo mbovu au sahihi batili imezuiwa.Kwa wastani wa 19,6 ms, hati hii ina kasi zaidi kuliko njia zingine za malipo.Watafiti wanaelezea hili kwa kutofaulu kwa ukaguzi wa saini kabla ya upatanisho wa hifadhidata.

Thamani hii si "19,6 ms overhead" lakini jumla ya wastani wa kusubiri ulioripotiwa wa ombi batili la tokeni.

Jaribio la muda wa tokeni linaonyesha nini hasa?

Muda wa uhalali wa tokeni ni sekunde 300.Takriban sekunde mbili za kusubiri kwa ufahamu zilitumika katika jaribio, na tokeni nzima ya 10 ilitumiwa kwa mafanikio ndani ya muda wa uhalali.

Kwa hivyo jaribio:

• Inaonyesha kwamba tokeni bado inafanya kazi baada ya kusubiri kwa sekunde mbili.
• 300 haionyeshi kuwa tokeni ilikataliwa baada ya sekunde.
• Haizingatii mwendo wa saa, muda wa kikomo au shambulio la tokeni lililoisha.

Kutaja hati "token_expiry" kunaweza kutoa hisia kwamba kunyimwa muda wa matumizi kumethibitishwa.Jaribio katika utafiti lilijaribu tu uhalali baada ya muda.

Matokeo ya idempotency

Imeelezwa kuwa taarifa ya tokeni iliyotangulia inarejeshwa katika marudio yote ya 10 yaliyofanywa kwa ufunguo sawa.Hii inasaidia kuzuia athari ya upande ya malipo ya mara kwa mara.

Hata hivyo, kwa muda wa kusubiri, asilimia kubwa ya anuwai ya 95 ya ±851,9 ms imetolewa katika Jedwali III.Katika sehemu ya majadiliano, utofauti wa utambulisho unarejelewa kwa njia tofauti kama ± 434,6 ms.Thamani hizi mbili hazioani na haiwezi kubainishwa ni ipi sahihi bila matokeo ghafi ya majaribio.

Kushuka kutoka dola 550 hadi dola 400 kunapaswa kufasiriwaje?

Utafiti unabainisha kuwa utekelezaji wa sera ulipunguza matumizi yaliyoripotiwa kutoka dola za 550 hadi dola za 400, na hivyo kusababisha punguzo la asilimia 27,3 ya dola za 150:

\[ \frac{550-400}{550}\times100\approx27{,}3\% \]

Kwa kuzingatia hesabu za ombi la hali katika majedwali ya ziada, safuwima za matumizi zinaonekana kuakisi wastani wa jaribio moja au wastani wa majaribio badala ya jumla halisi ya majaribio mawili.Kwa mfano, katika hali ya kawaida, 20 inafanikiwa katika majaribio mawili. Jumla ya malipo ya dola za 10 ni dola za 200, wakati jedwali linasema dola za 100.

Kupungua kwa uwiano bado kunaweza kubaki asilimia 27,3;lakini haipaswi kutafsiriwa kama "jumla ya dola za 150 zilizohifadhiwa katika ombi zima la 360."Njia ya kukusanya gharama haijafafanuliwa wazi.

Tatizo la ufasiri katika matokeo ya ucheleweshaji

Maandishi yanaonyesha thamani ya ms 86,9 katika mtiririko wa kawaida wa sera kama "86,9 ms latency overhead" na "10,9 factor slow" ikilinganishwa na 8,0 ms thamani ya no-sera.

Kitaalamu:

• 86,9 ms ni jumla ya ucheleweshaji wa wastani wa njia ya sera.
• Ikiwa thamani ya msingi 8,0 ms inatumiwa, muda wa ziada ni 78,9 ms.
• 86,9/8,0 uwiano ni takriban mara 10,9.

Pia 8,0 ms ni thamani ya jumla ya kutokuwa na sera ya matukio yote katika Jedwali la II.Jedwali la Nyongeza la V linatoa 9,2 ms kwa hali ya kawaida, wakati Kielelezo 6 kinaonyesha 12,27 ms.Ulinganisho wa viwango tofauti vya ujumlisho huficha ufasiri kwamba "mtiririko wa kawaida ni polepole mara 10,9".

Kielelezo 5 kinaonyesha nini?

Katika takwimu 5, mhimili mlalo unaonyesha matukio sita, mhimili wima unaonyesha kiwango cha mafanikio:

• Njia isiyo na sera inaonyesha mafanikio ya asilimia 100 katika hali zote;kwa sababu hundi za usalama na malipo zimepitwa.
• Kawaida, matumizi ya kupita kiasi, muda wa tokeni na asilimia ya idempotency 100 katika hali ya malipo pekee;Tena, asilimia ya tokeni isiyo sahihi ni 0.
• Katika hali ya malipo na sera, asilimia ya kawaida ni 50, matumizi makubwa ni takriban asilimia 66,7;kurudia na asilimia batili tokeni 0;muda wa tokeni na asilimia ya idempotency ni 100.

Asilimia 0 katika nakala na matukio ya tokeni batili haimaanishi kushindwa kwa mfumo lakini hakuna ombi lolote kati ya shambulio lililoweza kupata ufikiaji uliolindwa.

Kwa nini Kielelezo 6 na majedwali ya nyongeza hayalingani?

Baadhi ya lebo za ucheleweshaji katika Mchoro 6 hutofautiana na nambari zilizotolewa katika majedwali ya ziada.Kwa mfano:

• Ucheleweshaji wa kawaida bila sera ni 12,27 ms katika Kielelezo 6, 9,2 ms katika Jedwali la Kiambatisho V.
• Ucheleweshaji wa utambulisho wa malipo ni 94,43 ms kwenye Kielelezo 6, 405,0 ms katika Jedwali la Ziada VI.
• Muda wa tokeni uliolipiwa ni takriban 2.191,96 ms kwenye Kielelezo 6, 2.115,0 ms katika Jedwali la Kiambatisho VI.

Tofauti hizi haziendani na madai kwamba takwimu na majedwali ya ziada yalitolewa kutokana na matokeo sawa ya majaribio.Huenda tofauti zimetumika;lakini hakuna toleo au kitambulisho cha kukimbia kilichobainishwa.

Kielelezo 7 kinaonyesha nini?

Kielelezo 7 kinaonyesha tabia zinazoruhusiwa na zilizozuiwa katika kila modi katika grafu ndogo tofauti.Katika hali ya kutokuwa na sera, maombi yote yanaonekana kuruhusiwa.Maombi ya tokeni yanayorudiwa na batili yamezuiwa katika njia za malipo.Siasa zinapoongezwa, vikwazo vya ziada vinavyohusiana na bajeti hutokea katika hali ya kawaida hadi matumizi ya kupita kiasi.

Chati inaonyesha uzuiaji wa usalama na uzuiaji wa bajeti katika darasa sawa "lililozuiwa".Kwa hiyo, kiwango cha kuzuia jumla pekee haimaanishi ulinzi wa mashambulizi.

Kielelezo 8 kinaonyesha nini?

Kielelezo 8 kinaonyesha usawazishaji wa muda wa kusubiri wa udhibiti wa aina tatu, kwa kutumia muda wa wastani wa kusubiri kwenye mhimili mlalo na kuzuia kiwango cha ombi kwenye mhimili wima:

• Hali isiyo na sera iko katika kiwango cha chini cha kusubiri na kuzuia sifuri.
• Hali ya malipo pekee ndiyo ina kasi ya juu ya kusubiri na ya wastani ya kuzuia.
• Hali ya sera yenye malipo inaonyesha kiwango cha juu cha uzuiaji katika eneo sawa la kusubiri.

Viwianishi vya ucheleweshaji katika takwimu ni vya chini kuliko thamani za 442 na 477 ms katika Jedwali la II na huonekana karibu na wastani wa hali iliyopimwa na idadi ya maombi.Hii inaonyesha kuwa zaidi ya mbinu moja ya kujumlisha inatumika katika kifungu bila kuitofautisha wazi.

Hakikisho rasmi la kikomo cha matumizi

Kwa kuchukulia kuwa udhibiti wa sera ya kazi hufanya kazi kabla ya utumaji wa upatanisho na gharama zote si hasi:

\[ \sum_{i:x_i=1}c_i\leq B \]

inaonyesha kuwa itatokea.

Uhakikisho huu unatumika kwa rekodi zinazokubalika katika dirisha la bajeti lililoundwa.Inachukuliwa kuwa hifadhidata haiwezi kurekebishwa, njia zote za malipo hupitia injini ya sera, na shughuli za pamoja zimefungwa kwa usahihi.

Dai la uwezekano sifuri wa kufanikiwa kwa shambulio la kurudia

Katika utafiti:Usemi

\[ P(\text{replay success})=0 \]

umetolewa.

Matokeo haya yanarejelea urudufishaji wa tokeni unaofanana kidogo chini ya masharti yafuatayo:

• Uthibitishaji wa saini ni wa lazima.
• Muda wa tokeni lazima uwe halali.
• Tokeni inakubaliwa tu ikiwa katika hali ya SETTLED.
• Baada ya matumizi ya kwanza, hali inakuwa CONSUMED kabisa.

Taarifa hiyo haithibitishi kwa ujumla kwamba mashambulizi yote ya marudio au tokeni hayana uwezekano wa kufaulu.Wizi wa tokeni, matumizi ya wakati mmoja kabla ya matumizi, urejeshaji wa hifadhidata, utekaji nyara wa vitufe, na kutofautiana kwa nodi nyingi hazijajumuishwa.

Ni zipi nguvu za utafiti?

• Inaelezea malipo, sera, tokeni na mtiririko wa usajili na mabadiliko ya hali ya wazi.
• Huweka hundi ya sera kabla ya usajili wa malipo.
• Inachanganya udhibiti wa saini na hali ya matumizi.
• Hushughulikia urudiaji wa mteja kwa kutumia kitufe cha Idempotency.
• Hutathmini matukio ya mshambulizi na makosa pamoja na mtiririko wa kawaida.
• Njia tatu zinazolingana zinalenga kutenganisha gharama za malipo na sera.
• Mrundikano mdogo wa teknolojia hurahisisha kuchambua mfumo kwa usanifu.
• Kumbukumbu za JSON na faili ya matokeo huacha ufuatiliaji unaofaa kwa utengenezaji wa jedwali la utangazaji.
• Inaonyeshwa kuwa sera ya matumizi huwashwa kidhahiri wakati bajeti inapitwa.

Ni yapi mapungufu ya utafiti?

• Hali ya uchapishaji wa awali: Haijathibitishwa kama kukaguliwa na rika.
• Utambulisho wa Shirika: Taasisi za Waandishi hazipewi.
• Kutokuwepo kwa msimbo wazi: Nambari na data zinapatikana tu kwa ombi katika sajili rasmi.
• Hakuna UPI halisi: Mtiririko wa malipo unaigwa.
• Ukosefu wa kufuata fedha: KYC, AML, kurejesha pesa, kurejesha malipo na michakato ya upatanisho haijajumuishwa.
• Nodi Moja: SQLite haiwakilishi ubadilishaji wa nodi nyingi na uvumilivu wa makosa.
• Sampuli ndogo: Jumla ya maombi ya 10-40 kwa kila hali na marudio mawili pekee ndiyo yaliyotumika.
• Ufunguzi wa Takwimu: Mbinu ya muda wa kujiamini, dhana ya uhuru na ugawaji ghafi haujatolewa.
• Maoni ya kiwango cha mafanikio: Asilimia 52,8 ni wastani wa hali ya jumla;Sio kiwango cha mafanikio cha moja kwa moja cha maombi halali.
• Jaribio la muda wa tokeni: Uzuiaji wa tokeni ulioisha muda wake haujajaribiwa.
• Ulinganisho wa muda wa kusubiri: Maadili ya kawaida na ya wingi yanachanganywa.
• Kutolingana kwa jedwali la takwimu: Baadhi ya thamani za ucheleweshaji hazithibitishani.
• Jumla ya matumizi: Safu ya "Jumla" inaonekana kuwa wastani wa majaribio badala ya jumla halisi ya majaribio mawili.
• Tofauti ya idempotency: Thamani mbili tofauti za kubadilika zimetolewa katika sehemu tofauti za maandishi.
• Wizi wa tokeni: Matumizi ya kwanza ya tokeni halali na wakala asiyeidhinishwa hayajatathminiwa.
• Kitambulisho cha Wakala: Hakuna kitambulisho cha wakala au hati ya idhini ya mtumiaji katika upakiaji wa tokeni.
• Uadilifu wa kumbukumbu: Faili ya kumbukumbu haiwezi kubadilika kificho.
• Hali halisi ya kusubiri ya mtandao: UPI au muda wa upatanisho wa benki haujajumuishwa kwenye matokeo ya mtihani.

Utafiti unaunga mkono nini?

• Ombi la malipo linalofanana na HTTP 402 linaweza kuunganishwa katika kiwango cha programu na mtiririko unaoigwa wa fiat.
• Kwa kila ombi na kikomo cha kila siku kinaweza kutumika kwa kubainishwa kabla ya usajili wa malipo.
• Wakati sahihi ya HMAC inatumiwa pamoja na hali ya matumizi katika hifadhidata, marudio ya tokeni sawa yanaweza kuzuiwa.
• Tokeni zisizo sahihi zinaweza kukataliwa mapema kabla hazijafika njia ya malipo na hifadhidata.
• Swichi ya kutokuwepo uwezo inaweza kuzuia ombi sawa la malipo kutokana na kutoa athari za pili katika mazingira ya majaribio ya nodi moja.
• Sera inasitisha matumizi baada ya bajeti iliyopangwa kujaa.
• Vidhibiti vya malipo na usalama vinaleta ucheleweshaji zaidi ikilinganishwa na ufikiaji wa moja kwa moja.

Utafiti hauthibitishi nini?

• Haithibitishi kwamba APEX inafanya kazi na UPI halisi au mfumo wa benki.
• Haionyeshi kuwa ni salama, inayoendana, au inayostahimili makosa katika kiwango cha uzalishaji.
• Haithibitishi kwamba mashambulizi yote ya marudio au aina za wizi wa tokeni hazina uwezekano wa kufaulu.
• 300 haionyeshi kuwa tokeni zinazozidi sekunde zilizuiwa kwa ufanisi katika jaribio.
• Haionyeshi kuwa sera huongeza manufaa ya mtumiaji au thamani ya biashara.
• Haithibitishi kwamba asilimia ya kupunguza matumizi ya 27,3 itatokea kwa njia sawa katika mazingira halisi ya biashara.
• Asilimia 52,8 haionyeshi kuwa thamani ni kiwango cha jumla cha mafanikio ya huduma kwa maombi halali.
• Haionyeshi kuwa muda sawa utadumishwa kwenye seva tofauti, watoa huduma za malipo, au trafiki kubwa kwa wakati mmoja.
• Haidhibitishi dai la waandishi la "uzalishaji wa hali ya juu" bila msimbo wazi na data ghafi.

Umuhimu wake kwa maisha ya kila siku na teknolojia

Iwapo wakala wa AI anatumia data ya hali ya hewa iliyolipiwa, uchanganuzi wa fedha, ramani, tafsiri au kompyuta ya API, kitanzi kisichosimamiwa kinaweza kurudia mwito ile ile mara mamia.Safu ya sera ya kigeni inayofanana na APEX inaweza kuangalia kikomo kabla ya malipo kufanywa, hata kama wakala atatoa mahitaji.

Jambo muhimu kuhusu mbinu hii ni kwamba sheria ya matumizi haiishi tu ndani ya utashi wa wakala mwenyewe.Sheria inatumika katika sehemu ya uamuzi ya upande wa seva ya API ya malipo.Kwa njia hii, wakala mpotovu au mkosaji hawezi kupita kwa urahisi kikomo chake cha bajeti.

Kwa matumizi halisi, APEX lazima iongezwe kwa kitambulisho cha wakala, idhini ya mtumiaji, maoni ya mtoa malipo, upatanisho wa benki, usimamizi muhimu, njia ya ukaguzi, kurejesha pesa, na utatuzi wa migogoro.

Utafiti wa baadaye

Watafiti wanapendekeza maboresho yafuatayo:

• Hifadhidata iliyoigwa ya shughuli badala ya SQLite,
• Kuunganishwa na mazingira halisi ya majaribio ya mtoaji malipo,
• Sera tofauti kulingana na wakala, mwisho na kiwango cha hatari,
• Mzunguko muhimu na wepesi wa algorithm,
• Wizi wa tokeni, hali ya mbio na majaribio mbovu ya data,
• Uzalishaji wa jedwali la kutolewa kiotomatiki kutoka kwa matokeo ya JSON.

Mbinu na Matokeo ya Utafiti

Muhtasari wa mbinu ya kiufundi

Matokeo makuu

• Katika jedwali la muhtasari wa sera iliyotumika, matumizi yalipungua kutoka dola 550 hadi dola 400 kwa asilimia 27,3.
• Majaribio ya kushambulia tena 20/20 yamezuiwa.
• Majaribio batili ya tokeni 20/20 yamezuiwa.
• Wastani wa kuchelewa kukataliwa kwa tokeni zisizo sahihi ni 19,6 ms.
• Muda wa kusubiri wastani wa mtiririko wa kawaida na sera inayotumika unaripotiwa kama 86,9 ms.
• Katika hali ya kawaida, kutokana na bajeti ya kila siku, 20 ya ombi la 40 ilikubaliwa na kiwango cha kufaulu kilikuwa asilimia 50.
• Katika hali ya matumizi kupita kiasi, maombi 20 kati ya 30 yalikubaliwa na kiwango kilikuwa asilimia 66,7.
• Majaribio yote ya Idempotency yalirudisha tokeni iliyotangulia na ufunguo sawa.
• Katika hali ya muda wa tokeni, mafanikio ya 10/10 yalipatikana kwani tokeni zote zilitumika ndani ya kipindi hicho.

Ufasiri wa tahadhari wa matokeo

Matokeo yanayoungwa mkono zaidi ya APEX ni kwamba sera rahisi ya bajeti ya upande wa seva inaweza kuanza na kusimamisha maombi yanayofuata kabla ya malipo kufanywa.Hii inatoa mfano wazi wa usanifu wa kuzuia uharibifu wa kifedha katika loops za wakala zisizosimamiwa na kikomo kilichopangwa.

Hali ya tokeni ya matumizi moja ilifaulu kuzuia mashambulizi ya kurudiwa kwa tokeni sawa katika utafiti.Hata hivyo, tathmini ya usalama inategemea seti ndogo ya mashambulizi, nodi moja, na dhana kwamba ufunguo wa siri unabaki salama.

Taarifa za majaribio zinapaswa kusomwa kwa tahadhari kutokana na kutofautiana kwa idadi katika majedwali na takwimu tofauti.JSON ghafi kwa kila uendeshaji, toleo la msimbo, na hazina ya chanzo huria zinahitajika kwa ajili ya uzalishaji huru wa matokeo ya mafanikio, matumizi na muda wa kusubiri.

Dokezo la Chanzo na Mbinu

Jina kamili la asili la kazi: APEX: Agent Payment Execution with Policy for Autonomous Agent API Access

Waandishi na mpangilio wao: Mohd Safwan Uddin;Mohammed Mouzam;Mohammed Imran;Syed Badar Uddin Faizan.

Habari ya mwandishi mwenza wa kwanza: Hakuna mchango mwenza au taarifa ya mwandishi mwenza wa kwanza katika PDF.

Maelezo ya mwandishi yanayolingana: Mwandishi anayehusika hajasemwa tofauti katika PDF.Anwani za barua pepe za waandishi wanne zimetolewa.

Viungo vya ushirika: Chuo kikuu cha Waandishi, kituo cha utafiti au uhusiano wa kampuni haujaelezwa katika PDF na rekodi rasmi ya arXiv.

Aina ya rasilimali: Nakala ya utafiti iliyochapishwa mapema ikijumuisha utekelezaji wa mfumo wa majaribio na uchanganuzi wa hali.

Mwaka wa kuchapishwa: 2026.

Jukwaa la uchapishaji: arXiv.

arXiv ID: arXiv:2604.02023v1.

Aina za ArXiv: Cryptography na Usalama (cs.CR) na Artificial Intelligence (cs.AI).

DOI: 10.48550/arXiv.2604.02023.Hii ni DOI iliyochapishwa mapema na arXiv juu ya DataCite;Si jarida lililopitiwa na marika DOI.

Hali ya mwamuzi: Haijathibitishwa kama kukaguliwa na rika.

Jarida au mkutano: Hakuna machapisho ya jarida yaliyothibitishwa au kukubalika kwa mkutano.

Nyumba halisi ya uchapishaji: Jarida iliyopitiwa na rika au mchapishaji wa mkutano haikuweza kuthibitishwa.Jukwaa rasmi la uchapishaji wa mapema ni arXiv.

Kiungo rasmi cha utangazaji:Rekodi Rasmi ya arXiv ya APEX

kiungo cha DOI:Rekodi ya ArXiv DOI

Msimbo na hali ya data: Maelezo ya ArXiv yanasema kwamba nambari na data zinapatikana kwa ombi.Hakuna kiunga cha hazina rasmi ya msimbo wa chanzo kinachopatikana kwa umma kinachotolewa.Kwa hiyo, matokeo ya utafiti hayakuweza kuthibitishwa kwa kuiendesha kwa kujitegemea.

Ingawa maelezo rasmi ya arXiv yanasema "takwimu ya 4 na jedwali la 8", PDF iliyopakiwa ina Kielelezo 1-8 na Jedwali I-VII.Kuna tofauti ya nambari kati ya maelezo haya ya biblia na maudhui ya PDF.

Makala haya ya Verianla yalitayarishwa kwa kukagua maandishi, usemi wa hisabati, majedwali, mtindo wa vitisho, michoro ya usanifu, michoro ya majaribio, majedwali ya ziada na mifano ya mwisho ya ukurasa wa 13 PDF uliopakiwa.Hakuna matokeo mapya ya kisayansi yameongezwa kutoka nje ya PDF.Chanzo cha nje kilitumika tu kuthibitisha kichwa, mfuatano wa mwandishi, Kitambulisho cha arXiv, DOI, kategoria, hali ya uchapishaji, na tamko la ufikiaji wa msimbo/data.

Mapungufu makuu ya utafiti;ukosefu wa muunganisho wa kweli wa UPI, usanifu wa nodi moja ya SQLite, idadi ndogo ya majaribio, marudio mawili tu, seti ndogo ya mashambulizi, hakuna hazina ya msimbo wazi, hakuna majaribio ya tokeni iliyoisha muda wake, tafsiri ya kupotosha ya kiwango cha mafanikio, na maadili ya jedwali la takwimu kutolingana kikamilifu.

APEX haithibitishi kwamba mawakala wanaojitegemea wanaweza kufanya malipo kwa usalama na kisheria kutoka kwa akaunti halisi za benki.Kile ambacho utafiti unaonyesha ni kwamba ombi la malipo linalotegemea HTTP 402, sera rahisi za bajeti, na ufikiaji wa tokeni za matumizi moja zinaweza kutekelezwa pamoja katika mfano wa utafiti unaodhibitiwa.