Mojawapo ya matatizo ya msingi ya uzoefu wa mtumiaji katika kutuma kriptosarafu ni kwamba watu hulazimika kushughulika na anwani ndefu za blockchain ambazo ni rahisi kukosewa. Wakati uhamisho wa benki unaweza kutumia nambari ya simu au taarifa ya akaunti inayotambulika kwa urahisi, katika mifumo ya kriptosarafu mtumiaji mara nyingi hulazimika kuchagua mtandao sahihi wa blockchain, kunakili anwani changamano na kuwa na tokeni asilia ya mtandao husika ili kulipa ada ya muamala.

Njia rahisi zaidi ya kutatua hili inaweza kuonekana kuwa kuunganisha moja kwa moja anwani ya barua pepe na anwani ya blockchain. Hata hivyo, mbinu hiyo huleta tatizo kubwa la faragha. Ikiwa anwani ya blockchain inaweza kuzalishwa kwa njia ya kubainika kutoka kwenye anwani ya barua pepe ya mtu, mtu yeyote anayejua anwani hiyo ya barua pepe anaweza kuchunguza salio, historia ya miamala na mahusiano ya mtu huyo na wahusika wengine kupitia blockchain ya umma.

HFIPay ni usanifu wa itifaki unaolenga kutatua tatizo hili bila kuunganisha moja kwa moja kitambulisho rahisi kwa binadamu na anwani ya malipo kwenye blockchain. Mfumo hutenganisha tabaka za uelekezaji wa kitambulisho kwa faragha, nukuu inayoweza kuthibitishwa na mtumaji, binding iliyofichwa mahususi kwa intent na claim authorization ya on-chain kwa uthibitisho wa maarifa sufuri.

Mtumaji hutaja tu kitambulisho kama anwani ya barua pepe ya mpokeaji. Relay hutatua kitambulisho hiki katika hifadhidata ya faragha, huzalisha intentId nasibu kwa kila malipo na huandika kwenye mnyororo si anwani ya barua pepe ya mpokeaji wala lebo ya kudumu ya mpokeaji inayoweza kutumika tena, bali tu thamani ya blinded binding ya muamala huo, ρ.

Katika hali ya Verified-quote, kabla ya kutuma fedha mtumaji anaweza kuthibitisha kwa off-chain proof kwamba thamani ya ρ kweli inahusiana na ufunguo wa siri wa binding wa mpokeaji aliyelengwa. Baada ya fedha kuwekwa, relay haiwezi kuelekeza fedha kwa mpokeaji mwingine wa hiari; mpokeaji halisi anaweza kutumia ZK-ACE kuthibitisha kwa uthibitisho wa maarifa sufuri kwamba anamiliki familia ileile ya utambulisho wa kideterministi na kuelekeza fedha kwenye anwani anayochagua.

Utafiti pia unajadili kwamba HFIPay, inapounganishwa na usanifu wa n-Vm, inaweza kutumiwa kuelekeza malipo kati ya mazingira tofauti ya blockchain. Hata hivyo, usanifu bado haujathibitishwa kwa end-to-end performance benchmark.

Kwa nini anwani ya malipo ya kripto iliyo rahisi kwa binadamu huleta tatizo la faragha?

Tuchukulie kwamba anwani ya mtumiaji:

alice@example.com

inabadilishwa moja kwa moja kuwa:

keccak256(identifier) → blockchain address

kwa njia ya kideterministi kuwa anwani ya blockchain.

Mfumo huu, ambao unaonekana rahisi sana kwa matumizi, hutoa matokeo kinyume kwa sababu ya uwazi wa blockchain. Mtu yeyote anayejua anwani ya barua pepe ya Alice anaweza kufanya hesabu hiyo hiyo na kupata anwani ya blockchain ya Alice.

Baada ya hapo mshambuliaji anaweza kuchunguza kwenye mnyororo wa umma:

• salio za akaunti,
• uhamisho wa zamani,
• ni tokeni zipi zinashikiliwa,
• ni anwani zipi zimefanya miamala pamoja,
• nyakati za miamala

.

Kwa hiyo uamuzi wa msingi wa muundo wa HFIPay ni kuondoa kabisa usawa wa “kitambulisho rahisi kwa binadamu = anwani ya blockchain ya umma”.

HFIPay Inaelekezaje Malipo Bila Kufichua Anwani ya Barua Pepe Kwenye Blockchain?

Katika HFIPay, anwani ya barua pepe, nambari ya simu au jina la mtumiaji wa mitandao ya kijamii haliwekwi moja kwa moja kwenye blockchain. Kitambulisho hutatuliwa katika tabaka la relay la faragha, na upande wa blockchain hutumia taarifa mpya ya matumizi ya mara moja kwa kila malipo.

Itifaki ina majukumu matano ya msingi:

Ufunguo wa siri wa binding wa mpokeaji

Mpokeaji B huzalisha handle ya siri kwa binding epoch fulani kutoka kwenye mzizi wa utambulisho wa kideterministi REVB:

u_B,e = H(Derive(REV_B, Ctx_bind || e))

Kutokana na hiyo huundwa binding-key commitment inayoweza kutumiwa katika uthibitishaji wa nukuu ya umma:

K_B,e = H("hfipay:bind-key" || u_B,e)

Hapa e ni thamani ya binding epoch. Makala inapendekeza kwamba lebo ya epoch ichaguliwe kutoka ratiba pana na ya pamoja ya muda, kama ya kila siku au kila wiki, badala ya kuwa kitambulisho nasibu kinachomhusu mpokeaji mmoja pekee. Lengo ni kuzuia taarifa ya epoch yenyewe isigeuke kuwa lebo ya mpokeaji inayoweza kutumiwa tena.

Kwa nini kila malipo hutumia intentId mpya?

Mtumaji anapotaka kufanya malipo, relay huzalisha kitambulisho cha intent cha 256-bit kilicho nasibu kikriptografia:

intentId ← {0,1}²⁵⁶

Kisha blinded recipient binding ya matumizi ya mara moja itakayotumwa kwenye mnyororo huhesabiwa:

ρ = H("hfipay:bind" || u_B,e || intentId)

Fedha zinapotumwa tena kwa mpokeaji yuleyule, intentId mpya huzalishwa na kwa hiyo ρ pia hubadilika.

Sifa hii ndiyo kiini cha lengo la HFIPay la pre-claim unlinkability. Mtazamaji wa blockchain haoni recipient tag ya kudumu inayoweza kuonyesha kwamba intent mbili tofauti zinahusiana na anwani ileile ya barua pepe.

Kwa nini Baseline na Verified-Quote ni miundo miwili tofauti ya uaminifu?

Katika hali ya Baseline, relay ikiwa na nia mbaya inaweza kutengeneza blinded binding inayomhusu mpokeaji mwingine kabla ya malipo. Chanzo huacha hili wazi kama dhana ya uaminifu.

Katika hali ya Verified-quote, binding layer huru huthibitisha uhusiano kati ya kitambulisho cha mtumiaji kilichonormalishwa na binding-key commitment ya mpokeaji.

Kisha relay humpa mtumaji quote proof. Proof hii huthibitisha kwamba thamani ileile ya siri uB,e inatimiza:

K_B,e = H("hfipay:bind-key" || u_B,e)

na pia:

ρ = H("hfipay:bind" || u_B,e || intentId)

.

Kwa sababu mtumaji huthibitisha proof na intent tuple iliyorekodiwa kwenye mnyororo kabla ya kuhamisha fedha, mfumo unalenga kuzuia relay kubadilisha mpokeaji baadaye.

Baada ya Mtumaji Kutuma Fedha, Relay Inaweza Kuzielekeza kwa Anwani Nyingine?

Lengo kuu la usalama la modeli ya Verified-quote ni kuzuia hilo.

Kabla ya kufadhili, mtumaji:

1. huthibitisha binding attestation,
2. huthibitisha quote proof,
3. huhesabu upya deposit address kutoka kwenye intentId,
4. hukagua asset, kiasi, chain, expiration na sehemu za refund,
5. huthibitisha kwamba intent tuple iliyorekodiwa kwenye blockchain ni sawa na quote iliyokubaliwa.

Mara taarifa kama:

(ρ, a, v, e, Texp, γA, href)

zinapofungwa na intent kwenye mnyororo, ili relay ibadilishe kimyakimya mpokeaji, tokeni, kiasi au semantiki ya refund, italazimika kuvunja uthibitishaji wa mtumaji au miundo ya kriptografia iliyotumiwa.

Mchakato wa malipo una hatua kuu tano

Anwani ya malipo huundwaje kwenye EVM?

Katika blockchain zinazooana na EVM, HFIPay hufafanua deposit address ya kideterministi kupitia CREATE2:

α_EVM = CREATE2(factory, intentId, keccak256(initcode))

Sifa muhimu ni kwamba anwani inaweza kuhesabiwa kabla contract haija-deploy kweli.

Factory contract pia inaweza kuhifadhi ρ, asset, kiasi, epoch, expiration na taarifa za refund zinazohusiana na intent.

Inatekelezwaje kwenye Solana?

Upande wa Solana hutumia Program Derived Address:

α_SOL = FindPDA(programId, ["hfipay" || intentId])

Katika Intent state PDA huhifadhiwa:

• ρ,
• asset descriptor,
• kiasi,
• epoch,
• expiration,
• refund metadata

.

Ikiwa SPL token inatumika, programu inaweza pia kuunda PDA-controlled token vault inayohusiana na intent.

Mpokeaji huthibitisha nini wakati wa claim?

Mpokeaji hasemi moja kwa moja kwenye mnyororo, “Mimi ndiye anwani hii ya barua pepe.”

Badala yake, kwa kutumia ZK-ACE, huthibitisha kwa uthibitisho wa maarifa sufuri kwamba utambulisho wake wa kideterministi unalingana na blinded binding iliyo kwenye intent.

Claim message imefafanuliwa katika chanzo kwa muundo huu:

m_i = H("hfipay:claim" || d_dep || c_i || a_i || e_i || intentId_i || ρ_i || v_i || β_i || Texp || n_i)

Hapa β ni destination address ambako mpokeaji anataka kupokea fedha; n ni nonce dhidi ya replay attacks.

Claim proof hufunga pamoja mahusiano yafuatayo:

utambulisho wa kideterministi → epoch handle → ρ → intentId → asset → kiasi → destination

Kwa hiyo hata mtazamaji wa mempool akinakili claim transaction na kujaribu kuituma kwanza, proof hairuhusu fedha kuhamishwa kwenda destination address nyingine iliyochaguliwa na mshambuliaji.

Mzunguko wa maisha ya intent

Kila intentId hutumiwa mara moja tu.

CREATED → FUNDED → CLAIMED

au:

FUNDED → EXPIRED → REFUNDED

moja ya njia hizi hufuata.

Refund pia haijaachwa kwa uamuzi wa upande mmoja wa relay. Katika modeli ya chanzo, mtumaji anaweza kutoa authorization mapema kwa refund destination wakati intent inaundwa.

HFIPay Inalenga Vipengele Gani vya Faragha?

1. Enumeration Resistance

Hata kama mshambuliaji anajua anwani ya barua pepe ya Alice, hapaswi kuwa na uwezo wa kubainisha ni intent zipi zinamhusu Alice kwa kuchunguza tu data ya blockchain.

Taarifa kuu zinazoonekana kwenye mnyororo ni hizi:

Chanzo hakidai kwamba dai la faragha linaficha aina ya asset, kiasi, muda au taarifa ya chain. Uchambuzi wa enumeration resistance hufanywa kwa kusawazisha metadata hii ya wazi.

2. Pre-Claim Unlinkability

Malipo mawili tofauti yanapofanywa kwa mtumiaji yuleyule kabla ya claim kutokea, mtazamaji wa nje hapaswi kuweza kujua kwa kutazama tu muundo wa on-chain kwamba intent hizo mbili zinamhusu mtu yuleyule.

Sababu kuu ni kwamba kila intent hutumia intentId huru iliyo nasibu na blinded binding hutengenezwa upya kila mara kama:

ρ_i = H("hfipay:bind" || u_B,e || intentId_i)

.

Je, kutotambulika hubaki vilevile baada ya claim?

Hapana. Makala inakubali kikomo hiki wazi.

Ikiwa mpokeaji anatumia tena na tena public destination address β ileile, claim hizi zinaweza kuhusishwa kama zikiwa chini ya udhibiti mmoja.

Pia, ikiwa verifier interface inaonyesha hadharani IDcomB commitment ileile katika kila claim, miamala yote inayotumia commitment hiyo tena inaweza kuunganishwa katika kiwango cha mnyororo.

Kwa hiyo chanzo kinapendekeza kuficha identity commitment nyuma ya verifier interface au kutumia commitment rotation katika deployment ambazo post-claim privacy ni muhimu.

Katika modeli ya Verified-quote, je, watumaji tofauti wanaweza kutambuana kwa njia isiyo ya moja kwa moja?

Ndiyo. Hii ni mojawapo ya maelezo muhimu ya chanzo.

Watumaji tofauti wanaotaka kumlipa mpokeaji yuleyule ndani ya binding epoch ileile huona KB,e commitment ileile ndani ya quote.

Ikiwa watumaji hawa watashirikiana, wanaweza kugundua kwamba wote wanamlipa mpokeaji yuleyule.

Kwa kuwa taarifa hii haiandikwi kwenye blockchain, haivunji moja kwa moja faragha ya on-chain observer katika upeo wa G1 na G2; hata hivyo, chanzo kinaitaja wazi kama kikomo cha cross-sender linkability.

Nini Hutokea Hifadhidata ya Relay Ikichukuliwa?

HFIPay huficha taarifa ya identifier kwenye mnyororo, lakini directory ya faragha ya relay ni tabaka muhimu la faragha.

Ikiwa mshambuliaji atapata hifadhidata ya relay, anaweza kujifunza ulinganisho wa:

Norm(e_B) → (IDcom_B, u_B,e, K_B,e, ...)

pamoja na rekodi za identifier-to-intent.

Muhimu zaidi, ikiwa epoch handle za zamani zimehifadhiwa, mshambuliaji anaweza kuhesabu kwa intentId za zamani kwenye blockchain:

H("hfipay:bind" || u_B,e || intentId)

na hivyo ku-de-anonymize kwa njia ya kurejea nyuma miamala ya kipindi husika.

Kwa hiyo chanzo kinasisitiza kwamba athari ya shambulio haiishii kwenye intent hai pekee, bali inaweza kuenea hadi historia yote ya epoch zilizochukuliwa na ambazo bado zimehifadhiwa.

Njia zinazopendekezwa za kupunguza hatari ni pamoja na encrypted-at-rest directory, hardware-backed keys, epoch rotation, kufuta epoch handle zilizokamilika, kusafisha rekodi za zamani za intent/quote na, siku zijazo, kusambaza huduma ya relay kwa waendeshaji kadhaa huru.

Hata hivyo, kuchukuliwa kwa relay pekee hakupaswi kumruhusu mshambuliaji kufanya claim ya intent iliyorekodiwa awali kwenye mnyororo kwa blinded binding sahihi kwenda kwenye anwani yake mwenyewe; claim bado lazima itimize uhusiano wa ZK-ACE.

Je, HFIPay Ni Mfumo Uliogatuliwa Kweli?

Usanifu wa utafiti si mfumo usio na relay kabisa. Mwandishi anauita muundo wa relay-assisted but non-custodial.

Relay:

• huhifadhi identifier directory,
• hulinganisha mtumiaji na payment intent,
• hutuma arifa,
• inaweza kufanya transaction relaying,
• inaweza kulipa gas au rent kwa niaba ya mtumiaji.

Kwa hiyo relay hubaki privacy dependency na availability dependency.

Lakini katika hali ya verified-quote, mamlaka ya relay ni finyu zaidi kuliko huduma ya kawaida ya custodial “send to email”. Relay haihifadhi fedha chini ya custody na haiwezi kubadilisha mpokeaji baada ya intent kufadhiliwa bila proof sahihi.

Usanifu wa uaminifu wa tabaka tatu

Malipo ya Mnyororo kwa Mnyororo Hufanyaje Kazi?

Mekanizimu kuu ya claim ya HFIPay inaweza kufanya kazi kwenye blockchain ileile na pia, katika chanzo, hupanuliwa kwa malipo ya cross-chain kupitia usanifu wa mashine nyingi pepe uitwao n-Vm.

n-Vm inaelezwa kama mbinu ya Layer-1 ambayo VM nyingi hufanya kazi chini ya identity layer ya pamoja.

Kutoka identity commitment moja, anwani zinaweza kutolewa kwa mazingira tofauti:

α_EVM = SHA-256("evm:" || id_com)[12:32]

α_SVM = SHA-256("svm:" || id_com)

α_BVM = SHA-256("bvm:" || id_com)

α_native = id_com

Mfano wa mtiririko wa cross-chain

Chanzo kinaweka kikomo muhimu sana: kutumia n-Vm hakuondoi tatizo la external-chain deposit verification.

Mfumo bado lazima uthibitishe kwamba malipo yalifanywa kweli kwenye mnyororo chanzo. Hili lazima lifanywe kwa light-client proof, validator attestation au mbinu yenye nguvu sawa.

Kwa hiyo usanifu hauondoi kabisa uaminifu wa bridge; unalenga kuuingiza ndani ya mpaka wa makubaliano ya n-Vm.

Je, Bitcoin pia imejumuishwa?

Utafiti unafafanua pia mtiririko wa dhana kwa Bitcoin kwa kudhani kuwepo kwa moduli ya BVM ndani ya n-Vm.

BTC huhamishwa kwanza kwenda n-Vm deposit address, kisha wBTC huundwa na kufungwa kwa intent. Baada ya claim, mpokeaji anaweza kuchagua BTC, EVM au SVM kama lengwa.

Hata hivyo, chanzo hakibainishi hasa jinsi BVM itakavyotekelezwa kupitia Bitcoin sidechain, optimistic rollup au ZK Bitcoin Script verification. Suala hili limeachwa kwa kazi ya baadaye.

HFIPay Inatofautianaje na ENS na Mifumo ya Stealth Address?

Mbinu na Matokeo ya Utafiti

Utafiti ulifanya nini?

Utafiti haukufanya jaribio la maabara wala production benchmark. Mbinu kuu ni:

1. kufafanua tatizo la faragha katika malipo ya kripto yanayotegemea identifier kwa threat model,
2. kuunganisha vipengele vya relay, deterministic identity, blinded binding na ZK authorization katika itifaki moja,
3. kutenganisha miundo ya uaminifu ya baseline na verified-quote,
4. kufafanua majaribio ya usalama na proof sketch kwa enumeration resistance na pre-claim unlinkability,
5. kuunda rasimu za utekelezaji kwa EVM na Solana,
6. kueleza upanuzi wa cross-chain kupitia n-Vm.

G1: Enumeration Resistance

Katika chanzo, jaribio la G1 linafafanuliwa kwa kumpa mshambuliaji intent tuple mpya chini ya target identifier na public metadata iliyolinganishwa.

Kulingana na pendekezo la mwandishi, ikiwa relay directory haijachukuliwa, active au stored epoch handles haziwezi kutolewa kutoka kwenye public data, na hash inayotumika ni salama kwa domain separation inayofaa, faida ya polynomial-time on-chain observer katika kutofautisha target recipient na comparison recipient inapaswa kubaki ndogo sana.

Matokeo haya ni proof sketch chini ya modeli ya mtazamaji iliyofafanuliwa na itifaki; utafiti hauyatoi kama matokeo ya jumla na kamili ya formal verification.

G2: Pre-Claim Unlinkability

Jaribio la pili la usalama linachunguza ikiwa mtazamaji anaweza kutofautisha kama pre-claim intent mbili zinamhusu mpokeaji mmoja au wapokeaji wawili tofauti.

Kwa sababu kila intent hutumia intentId huru iliyo nasibu na ρ hutokana na handle ya siri pamoja na intentId hiyo mpya, inadaiwa kwamba public metadata inapolinganishwa hakuna muundo wa public unaoweza kutumiwa tena ambao unamruhusu on-chain observer kutofautisha hali za same recipient/two recipients.

Quote-to-Claim Composition

Lemma 3.1 ya utafiti huunda uhusiano kati ya verified-quote na claim proof.

Quote proof:

K = H("hfipay:bind-key" || u)

na:

ρ = H("hfipay:bind" || u || intentId)

huthibitisha kuwepo kwa u ya siri inayotimiza mahusiano yote mawili.

Claim proof huonyesha kwamba thamani u' inayotolewa kutoka kwenye utambulisho wa kideterministi huzalisha ρ ileile.

Mwandishi anahoji kwamba chini ya dhana ya collision resistance ya hash inayotumiwa, u na u' tofauti kuzalisha ρ ileile iliyopangwa kungehitaji hash collision. Kwa hiyo anafikia hitimisho kwamba quote na claim zilizofanikiwa zimefungwa kwenye epoch-scoped hidden handle ileile.

Je, kuna matokeo ya utendaji yaliyopimwa?

Hapana.

Makala inasema wazi kwamba bado hairipoti vipimo vifuatavyo:

• end-to-end prototype benchmark,
• ukubwa wa quote proof,
• ZK verification latency,
• gas cost,
• relay API latency,
• throughput,
• scalability chini ya mzigo.

Kwa hiyo, haiwezekani kubaini kutoka kwenye makala hii HFIPay ni milisekunde ngapi polepole kuliko uhamisho wa kawaida, gharama ya kila muamala ni kiasi gani au inaweza kushughulikia malipo mangapi kwa sekunde.

Gharama ya ziada ya Verified-quote

Ingawa chanzo hakitoi benchmark ya kiasi, kinaeleza mzigo wa ziada wa usanifu kwa ubora.

Baseline HFIPay inahitaji:

directory lookup + intent registration + recipient claim proof + on-chain proof verification

.

Toleo la Verified-quote huongeza:

quote proof generation na relay + quote verification na mtumaji

.

Ukubwa wa nyenzo ya quote anayoiona mtumaji unaelezwa kama:

O(|τ_B| + |π^quote|)

na ukubwa wa claim transaction kama:

O(|π_i|)

.

Vikomo vikuu

1. Relay haiondoki kabisa: kuna utegemezi wa relay kwa faragha, notification na availability.
2. Katika Baseline, hatari ya recipient substitution ni dhana ya uaminifu.
3. Binding issuer inaweza kutoa attestation isiyo sahihi au kukosa kupatikana.
4. Relay directory compromise inaweza de-anonymize intent za zamani kwa kurejea nyuma.
5. Post-claim privacy ni dhaifu zaidi: destination ileile au public ID commitment ikitumiwa tena, uhusiano unaweza kujengwa.
6. Katika Verified-quote, sender walio katika epoch ileile wanaweza kupitia K_B,e kutambua kuwa wanamlipa mpokeaji yuleyule.
7. Network-layer traffic analysis iko nje ya upeo.
8. Account takeover ya barua pepe/OIDC inaweza kuvunja usalama wa enrollment ya awali.
9. Cross-chain deposit verification ni tatizo tofauti la uaminifu.
10. Production benchmark bado haipo.

Mada za kazi ya baadaye

Chanzo kinapendekeza mwelekeo minne mikuu ya maendeleo:

• Quote-proof optimization: kubana au ku-aggregate sender-verifiable proof.
• Private directory federation: kusambaza directory kwa waendeshaji huru ili kupunguza hatari ya compromise ya relay moja.
• Proof aggregation: kuunganisha ZK-ACE claim proof kwa batch au recursive verification kwa kiasi kikubwa cha miamala.
• Lazy first-receipt onboarding: kumwingiza mpokeaji ambaye hajawahi kusajiliwa kwa nguvu na usalama wakati wa malipo ya kwanza.

Maelezo ya Chanzo na Mbinu

Kichwa asili: HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers

Mwandishi: Jian Sheng Wang.

Uhusiano wa taasisi: Yeah LLC.

Tarehe: 27 Machi 2026.

Chanzo: arXiv.

Kitambulisho cha ArXiv: arXiv:2603.26970v1 [cs.CR].

Aina ya utafiti: Itifaki ya kriptografia na usanifu wa mfumo wa malipo.

Pendekezo kuu: Malipo ya kripto kwa identifier rahisi kwa binadamu kupitia utatuzi wa relay wa faragha, intent-specific blinded recipient binding na claim authorization yenye uthibitisho wa maarifa sufuri.

Malengo makuu ya faragha: Enumeration resistance na pre-claim unlinkability.

Miundombinu ya Authorization: ZK-ACE.

Sehemu ya deterministic identity recovery: Va-Dar.

Upanuzi wa Cross-chain: n-Vm.

Mazingira ya utekelezaji yaliyotazamwa: EVM-compatible chains na Solana; upanuzi wa dhana kwa Bitcoin/n-Vm BVM.

Vipengele muhimu vya kiufundi: random 256-bit intentId, blinded binding ρ, binding-key commitment K_B,e, verified quote, CREATE2, Solana PDA, ZK claim proof, sender-authorized refund.

Hali ya mapitio: Chanzo ni toleo la arXiv; hati iliyopakiwa haitoi taarifa ya kukubaliwa na jarida au mkutano uliopitiwa na wenzao.

Hali ya majaribio: Chanzo hakiripoti end-to-end production prototype benchmark wala quantitative performance evaluation.

Kikomo rasmi cha usalama: Matokeo ya G1 na G2 ni proof sketch chini ya observer model iliyofafanuliwa; utafiti hauyatoi kama game-based cryptographic reduction kamili.

Kikomo cha tafsiri ya kisayansi: Usanifu wa HFIPay unapendekeza sehemu mpya ya muundo kati ya urahisi wa matumizi na faragha katika malipo ya kripto kwa identifier rahisi kwa binadamu. Chanzo hakionyeshi kwamba mfumo umethibitishwa katika mazingira halisi ya production kwa gharama, ucheleweshaji, utendaji chini ya mzigo mkubwa au operesheni za usalama.