Kriptovalyuta yuborishdagi eng asosiy foydalanuvchi tajribasi muammolaridan biri — odamlar uzun va xatoga moyil blokcheyn manzillari bilan ishlashga majbur boʻlishidir. Bank oʻtkazmasida telefon raqami yoki oson taniladigan hisob maʻlumotidan foydalanish mumkin boʻlsa, kriptovalyuta tizimlarida foydalanuvchi koʻpincha toʻgʻri blokcheyn tarmogʻini tanlashi, murakkab manzilni nusxalashi va tranzaksiya haqini toʻlash uchun tegishli tarmoqning mahalliy tokeniga ega boʻlishi kerak.

Buni hal qilishning eng sodda yoʻli elektron pochta manzilini toʻgʻridan-toʻgʻri blokcheyn manziliga bogʻlashdek koʻrinishi mumkin. Biroq bunday yondashuv jiddiy maxfiylik muammosini tugʻdiradi. Agar bir kishining elektron pochta manzilidan deterministik ravishda blokcheyn manzili hosil qilinsa, elektron pochta manzilini biladigan har kim oʻsha shaxsning balansi, tranzaksiya tarixi va qarshi tomonlar bilan aloqalarini ochiq blokcheyn orqali koʻrib chiqishi mumkin.

HFIPay bu muammoni odamlar uchun qulay identifikator bilan blokcheyndagi toʻlov manzilini toʻgʻridan-toʻgʻri bir-biriga bogʻlamasdan hal etishni maqsad qilgan protokol arxitekturasidir. Tizim xususiy identifikator yoʻnaltirish, joʻnatuvchi tomonidan tekshiriladigan taklif, intent-ga xos koʻrlangan bogʻlash va nol bilim isboti orqali zanjir ustidagi claim authorization qatlamlarini bir-biridan ajratadi.

Joʻnatuvchi faqat qabul qiluvchining elektron pochta manzili kabi identifikatorni koʻrsatadi. Relay bu identifikatorni xususiy maʻlumotlar bazasida yechadi, har bir toʻlov uchun tasodifiy intentId yaratadi va zanjirga qabul qiluvchining elektron pochta manzili yoki qayta ishlatiladigan doimiy qabul qiluvchi yorligʻi oʻrniga faqat shu tranzaksiyaga xos blinded binding qiymati boʻlgan ρ ni yozadi.

Verified-quote rejimida joʻnatuvchi pul yuborishdan oldin ρ qiymati haqiqatan ham moʻljallangan qabul qiluvchining maxfiy bogʻlash kalitiga tegishli ekanini off-chain proof orqali tekshirishi mumkin. Mablagʻ kiritilgandan soʻng esa relay pulni xohlagan boshqa qabul qiluvchiga yoʻnaltira olmaydi; haqiqiy qabul qiluvchi ZK-ACE orqali ayni deterministik identifikatsiya oilasiga mansubligini nol bilim isboti bilan koʻrsatib, mablagʻni oʻzi tanlagan manzilga oʻtkaza oladi.

Tadqiqot, shuningdek, HFIPay n-Vm arxitekturasi bilan birlashtirilganda turli blokcheyn muhitlari oʻrtasida toʻlovlarni yoʻnaltirish uchun ishlatilishi mumkinligini muhokama qiladi. Biroq arxitektura hali end-to-end performance benchmark-lari bilan tasdiqlanmagan.

Odamlar uchun qulay kripto toʻlov manzili nega maxfiylik muammosini keltirib chiqaradi?

Bir foydalanuvchining:

alice@example.com

manzili bevosita:

keccak256(identifier) → blockchain address

kabi deterministik usulda blokcheyn manziliga aylantirilishini tasavvur qilaylik.

Foydalanish nuqtai nazaridan juda oson koʻringan bu tizim blokcheynning shaffofligi sababli teskari taʻsir koʻrsatadi. Aliceʻning elektron pochta manzilini bilgan har qanday kishi ayni jarayonni takrorlab, Aliceʻning blokcheyn manzilini hisoblab chiqishi mumkin.

Shundan soʻng hujumchi ochiq zanjirda:

• hisob balanslarini,
• oldingi oʻtkazmalarni,
• qaysi tokenlar saqlanayotganini,
• qaysi manzillar bilan tranzaksiya qilinganini,
• tranzaksiya vaqtlarini

koʻrib chiqishi mumkin.

Shu sababli HFIPayʻning asosiy dizayn qarori “odamlar uchun qulay identifikator = ochiq blokcheyn manzili” tengligini butunlay yoʻq qilishdir.

HFIPay Elektron Pochta Manzilini Blokcheynda Oshkor Qilmasdan Toʻlovni Qanday Yoʻnaltiradi?

HFIPayʻda elektron pochta manzili, telefon raqami yoki ijtimoiy tarmoq foydalanuvchi nomi blokcheynda toʻgʻridan-toʻgʻri joylashtirilmaydi. Identifikator xususiy relay qatlamida yechiladi va blokcheyn tomonida har bir toʻlov uchun yangidan yaratilgan bir martalik maʻlumotlardan foydalaniladi.

Protokolda beshta asosiy rol mavjud:

Qabul qiluvchining maxfiy bogʻlash kaliti

Qabul qiluvchi B deterministik identifikatsiya ildizi REVB orqali muayyan binding epoch uchun maxfiy handle hosil qiladi:

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

Shundan ochiq taklifni tekshirishda ishlatilishi mumkin boʻlgan binding-key commitment yaratiladi:

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

Bu yerda e binding epoch qiymatidir. Maqola epoch yorligʻini qabul qiluvchiga xos tasodifiy identifikator oʻrniga kunlik yoki haftalik kabi qoʻpol va umumiy vaqt jadvalidan tanlashni tavsiya qiladi. Maqsad epoch maʻlumotining oʻzi qayta ishlatiladigan qabul qiluvchi yorligʻiga aylanib qolishining oldini olishdir.

Nega har bir toʻlov yangi intentId ishlatadi?

Joʻnatuvchi toʻlov soʻraganda relay kriptografik jihatdan tasodifiy 256-bit intent identifikatorini yaratadi:

intentId ← {0,1}²⁵⁶

Soʻng zanjirga yuboriladigan bir martalik blinded recipient binding hisoblanadi:

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

Ayni qabul qiluvchiga yana pul yuborilganda yangi intentId yaratilgani uchun ρ ham oʻzgaradi.

Bu xususiyat HFIPayʻning pre-claim unlinkability maqsadining markazidadir. Blokcheyn kuzatuvchisi ikki xil intent bir xil elektron pochta manziliga tegishli ekanini koʻrsatadigan doimiy recipient tag-ni koʻrmaydi.

Baseline va Verified-Quote nega ikki xil ishonch modeli?

Baseline rejimida relay yomon niyatli boʻlsa, toʻlovdan oldin boshqa qabul qiluvchiga tegishli blinded binding yaratishi mumkin. Manba buni ochiq ravishda ishonch farazi sifatida qoldiradi.

Verified-quote rejimida esa mustaqil binding layer normallashtirilgan foydalanuvchi identifikatori bilan qabul qiluvchining binding-key commitment qiymati oʻrtasidagi aloqani tasdiqlaydi.

Relay keyin joʻnatuvchiga quote proof beradi. Bu proof ayni maxfiy uB,e qiymati bir vaqtning oʻzida:

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

hamda:

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

munosabatlarini qanoatlantirishini isbotlaydi.

Joʻnatuvchi pulni oʻtkazishdan oldin proof va zanjirga yozilgan intent tupleʻni tekshirganligi sababli relayʻning keyinchalik qabul qiluvchini almashtirishiga toʻsqinlik qilish koʻzda tutiladi.

Joʻnatuvchi Pulni Yuborgandan Soʻng Relay Uni Boshqa Manzilga Burishi Mumkinmi?

Verified-quote modelining asosiy xavfsizlik maqsadi aynan shuni oldini olishdir.

Joʻnatuvchi mablagʻ kiritishdan oldin:

1. binding attestationʻni tekshiradi,
2. quote proofʻni tekshiradi,
3. deposit manzilini intentId orqali oʻzi qayta hisoblaydi,
4. asset, miqdor, chain, expiration va refund maydonlarini tekshiradi,
5. blokcheynda qayd etilgan intent tuple qabul qilgan quote bilan bir xil ekanini tekshiradi.

Zanjirda masalan:

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

maʻlumotlari intentʻga bogʻlangandan keyin relay qabul qiluvchi, token, miqdor yoki refund semantikasini yashirincha oʻzgartirishi uchun joʻnatuvchi tekshiruvini yoki ishlatilgan kriptografik tuzilmalarni chetlab oʻtishi kerak.

Toʻlov jarayoni besh asosiy bosqichdan iborat

EVMʻda toʻlov manzili qanday yaratiladi?

EVM-mos blokcheynlarda HFIPay deterministik deposit manzilini CREATE2 orqali belgilaydi:

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

Buning muhim xususiyati — contract hali amalda deploy qilinmagan boʻlsa ham manzil oldindan hisoblanishi mumkin.

Factory contract, shuningdek, intentʻga tegishli ρ, asset, miqdor, epoch, expiration va refund maʻlumotlarini saqlashi mumkin.

Solanaʻda qanday amalga oshiriladi?

Solana tomonida mos tuzilma Program Derived Addressʻdan foydalanadi:

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

Intent state PDA ichida:

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

saqlanadi.

SPL token ishlatilganda dastur qoʻshimcha ravishda intentʻga tegishli PDA-controlled token vault yaratishi mumkin.

Claim vaqtida qabul qiluvchi nimani isbotlaydi?

Qabul qiluvchi zanjirga toʻgʻridan-toʻgʻri “Men mana shu elektron pochta manziliman” demaydi.

Buning oʻrniga ZK-ACEʻdan foydalanib, deterministik identifikatsiyasi intentʻdagi blinded binding bilan mos ekanini nol bilim isboti orqali koʻrsatadi.

Claim xabari manbada quyidagi tuzilma bilan belgilanadi:

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

Bu yerda β — qabul qiluvchining mablagʻni olishni istagan destination addressʻi; n esa replay hujumlariga qarshi nonce.

Claim proof quyidagi aloqalarni birgalikda bogʻlaydi:

deterministik identifikatsiya → epoch handle → ρ → intentId → asset → miqdor → destination

Shuning uchun mempool kuzatuvchisi claim transactionʻni nusxalab, uni oldinroq yuborishga urinayotgan boʻlsa ham, proof mablagʻni hujumchi tanlagan boshqa destination addressʻga oʻtkazishni ruxsat bermaydi.

Intent hayotiy sikli

Har bir intentId faqat bir marta ishlatiladi.

CREATED → FUNDED → CLAIMED

yoki:

FUNDED → EXPIRED → REFUNDED

yoʻllaridan biri kuzatiladi.

Refund jarayoni ham relayʻning bir tomonlama qaroriga qoldirilmagan. Manba modelida joʻnatuvchi intent yaratilayotganda refund destination uchun oldindan authorization berishi mumkin.

HFIPay Qaysi Maxfiylik Xususiyatlarini Maqsad Qiladi?

1. Enumeration Resistance

Hujumchi Aliceʻning elektron pochta manzilini bilsa ham, faqat blokcheyn maʻlumotlarini koʻrib chiqib qaysi intentʻlar Aliceʻga tegishli ekanini aniqlay olmasligi kerak.

Zanjirda koʻrinadigan asosiy maʻlumotlar quyidagilar:

Manba maxfiylik daʻvosi asset turi, miqdor, vaqt yoki chain maʻlumotlarini yashiradi, deb aytmaydi. Enumeration resistance tahlili ushbu ochiq metadata tenglashtirilgan holda amalga oshiriladi.

2. Pre-Claim Unlinkability

Ayni foydalanuvchiga claim sodir boʻlishidan oldin ikki xil toʻlov qilinganda, tashqi kuzatuvchi bu ikki intent bir xil shaxsga tegishli ekanini faqat on-chain tuzilma orqali anglay olmasligi kerak.

Buning asosiy sababi har bir intent mustaqil tasodifiy intentId ishlatishi va blinded binding:

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

koʻrinishida har safar yangidan hosil boʻlishidir.

Claim amalga oshirilgandan keyin anonimlik oʻsha holatda qoladimi?

Yoʻq. Maqola bu chegarani aniq tan oladi.

Qabul qiluvchi qayta-qayta bir xil public destination address β dan foydalansa, ushbu claimʻlar umumiy nazorat ostida deb bogʻlanishi mumkin.

Bundan tashqari, verifier interface har bir claim paytida bir xil IDcomB commitmentʻni ochiq koʻrsatsa, shu commitment qayta ishlatilgan barcha tranzaksiyalar zanjir darajasida oʻzaro bogʻlanishi mumkin.

Shu sababli manba post-claim maxfiyligi muhim boʻlgan deploymentʻlarda identity commitmentʻni verifier interface ortida yashirish yoki commitment rotatsiyasidan foydalanishni tavsiya qiladi.

Verified-quote modelida turli joʻnatuvchilar bir-birini bilvosita payqashi mumkinmi?

Ha. Bu manbaning muhim tafsilotlaridan biridir.

Ayni binding epoch ichida bir xil qabul qiluvchiga toʻlov qilmoqchi boʻlgan turli joʻnatuvchilar quote ichida bir xil KB,e commitmentʻni koʻradilar.

Agar bu joʻnatuvchilar hamkorlik qilsa, bir xil qabul qiluvchiga toʻlov qilayotganlarini anglab olishlari mumkin.

Bu maʻlumot blokcheynga yozilmagani uchun G1 va G2 doirasidagi umumiy on-chain observer maxfiyligini bevosita buzmaydi; biroq manba buni cross-sender linkability sifatida ochiq cheklov deb belgilaydi.

Relay Maʻlumotlar Bazasi Qoʻlga Kiritilsa Nima Boʻladi?

HFIPay zanjirdagi identifier maʻlumotini yashiradi, biroq relayʻning xususiy directoryʻsi muhim maxfiylik qatlamidir.

Agar hujumchi relay maʻlumotlar bazasini qoʻlga kiritsa:

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

mosliklarini va identifier-to-intent yozuvlarini bilib olishi mumkin.

Eng muhimi, eski epoch handleʻlar saqlangan boʻlsa, hujumchi blokcheyndagi avvalgi intentId qiymatlari uchun:

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

ni hisoblab, tegishli vaqt oraligʻidagi oldingi tranzaksiyalarni retrospektiv tarzda de-anonimlashtirishi mumkin.

Shu sababli manba hujum taʻsiri faqat faol intentʻlar bilan cheklanmasligini, balki qoʻlga kiritilgan va hanuz saqlanayotgan epochʻlarga tegishli butun tarixga yoyilishi mumkinligini taʻkidlaydi.

Tavsiya qilingan yumshatish choralariga encrypted-at-rest directory, hardware-backed keys, epoch rotatsiyasi, tugallangan epoch handleʻlarini oʻchirish, eski intent/quote yozuvlarini tozalash va kelajakda relay xizmatini bir nechta mustaqil operator oʻrtasida taqsimlash kiradi.

Shunga qaramay, relayʻning buzilishi oʻz-oʻzidan oldindan zanjirga toʻgʻri blinded binding bilan qayd etilgan intentʻni hujumchi oʻz manziliga claim qilishiga imkon bermasligi kerak; claim baribir ZK-ACE munosabatini qanoatlantirishi lozim.

HFIPay Haqiqatan Ham Markazsizmi?

Tadqiqot arxitekturasi butunlay relayʻsiz emas. Muallif uni relay-assisted but non-custodial tuzilma deb ataydi.

Relay:

• identifier directory saqlaydi,
• foydalanuvchini payment intent bilan bogʻlaydi,
• bildirishnoma yuboradi,
• transaction relaying qilishi mumkin,
• foydalanuvchi nomidan gas yoki rent toʻlashi mumkin.

Shunday qilib, relay privacy dependency va availability dependency boʻlib qoladi.

Biroq verified-quote rejimida relay vakolati klassik custodial “send to email” xizmatiga qaraganda cheklanganroq. Relay mablagʻlarni custodyʻda saqlamaydi va intent moliyalashtirilgandan keyin toʻgʻri proof boʻlmasdan qabul qiluvchini oʻzgartira olmaydi.

Uch qatlamli ishonch arxitekturasi

Zanjirlararo Toʻlov Qanday Ishlaydi?

HFIPayʻning asosiy claim mexanizmi bir blokcheyn ichida ishlashi bilan birga, manbada n-Vm deb ataluvchi koʻp virtual mashinali arxitektura bilan zanjirlararo toʻlovga kengaytiriladi.

n-Vm umumiy identity layer ostida bir nechta VM ishlaydigan Layer-1 yondashuvi sifatida taʻriflanadi.

Bitta identity commitmentʻdan turli muhitlar uchun manzillar hosil qilish mumkin:

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

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

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

α_native = id_com

Misol zanjirlararo oqim

Manba alohida muhim cheklovni belgilaydi: n-Vmʻdan foydalanish external-chain deposit verification muammosini yoʻq qilmaydi.

Tizim baribir manba zanjirda haqiqatan toʻlov qilinganini tekshirishi kerak. Bu light-client proof, validator attestation yoki teng kuchli usul orqali bajarilishi lozim.

Demak, arxitektura bridge ishonchini butunlay yoʻq qilmaydi; uni n-Vm konsensus chegarasiga kiritishni maqsad qiladi.

Bitcoin ham qamrab olinadimi?

Tadqiqot n-Vm ichida BVM modulini faraz qilib, Bitcoin uchun ham konseptual oqimni taʻriflaydi.

BTC avval n-Vm deposit manziliga oʻtkaziladi, keyin wBTC yaratiladi va intentʻga bogʻlanadi. Qabul qiluvchi claimʻdan keyin BTC, EVM yoki SVM kabi maqsadni tanlashi mumkin.

Biroq manba BVM Bitcoin sidechain, optimistic rollup yoki ZK Bitcoin Script verifikatsiyasi orqali aniq qanday amalga oshirilishini belgilamaydi. Bu masala kelgusi ishlarga qoldirilgan.

HFIPay ENS va Stealth Address Tizimlaridan Qanday Farq Qiladi?

Tadqiqot Usuli va Natijalari

Tadqiqot nima qildi?

Tadqiqot laboratoriya eksperimenti yoki production benchmark oʻtkazmagan. Asosiy usul:

1. identifier asosidagi kripto toʻlovlarda maxfiylik muammosini threat model bilan taʻriflash,
2. relay, deterministic identity, blinded binding va ZK authorization komponentlarini bitta protokolda birlashtirish,
3. baseline va verified-quote ishonch modellarini ajratish,
4. enumeration resistance va pre-claim unlinkability uchun xavfsizlik tajribalari va proof sketchʻlarni taʻriflash,
5. EVM va Solana uchun amalga oshirish eskizlarini yaratish,
6. n-Vm orqali zanjirlararo kengaytmani tushuntirishdir.

G1: Enumeration Resistance

Manbada G1 tajribasi hujumchiga maqsad identifier va moslashtirilgan public metadata sharoitida yangi intent tuple berilishi bilan taʻriflanadi.

Muallif taklifiga koʻra, relay directory buzilmagan boʻlsa, faol yoki saqlangan epoch handleʻlarni public maʻlumotdan olish mumkin boʻlmasa va ishlatilgan hash tegishli domain separation bilan xavfsiz boʻlsa, polynomial-time on-chain kuzatuvchining target recipient bilan comparison recipientʻni ajratish ustunligi ahamiyatsiz darajada qolishi kerak.

Bu natija protokol belgilagan kuzatuvchi modeli ostidagi proof sketch boʻlib, tadqiqot uni umumiy va toʻliq formal verification natijasi sifatida taqdim etmaydi.

G2: Pre-Claim Unlinkability

Ikkinchi xavfsizlik tajribasi ikki pre-claim intent bir xil qabul qiluvchiga yoki ikki turli qabul qiluvchiga tegishli ekanini kuzatuvchi ajrata oladimi, degan savolni koʻrib chiqadi.

Har bir intent uchun mustaqil tasodifiy intentId ishlatilishi va ρ maxfiy handle hamda yangi intentIdʻdan hosil qilinishi tufayli, public metadata tenglashtirilganda on-chain kuzatuvchi nuqtai nazaridan same recipient/two recipients holatlarini ajratishga xizmat qiladigan qayta ishlatiluvchi public tuzilma yoʻqligi taʻkidlanadi.

Quote-to-Claim Composition

Tadqiqotning Lemma 3.1 qismi verified-quote bilan claim proof oʻrtasidagi aloqani oʻrnatadi.

Quote proof:

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

va:

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

munosabatlarini qanoatlantiradigan maxfiy u mavjudligini isbotlaydi.

Claim proof esa deterministik identifikatsiyadan hosil qilingan u' qiymati ayni ρ ni yaratishini koʻrsatadi.

Muallif ishlatilgan hash collision resistance faraziga ega boʻlsa, turli u va u' qiymatlarining ayni strukturali ρ ni hosil qilishi hash collision talab qilishini taʻkidlaydi. Shu bois muvaffaqiyatli quote va claim bir xil epoch-scoped hidden handleʻga bogʻlangan degan xulosaga kelinadi.

Oʻlchangan ishlash natijalari bormi?

Yoʻq.

Maqola ochiq ravishda quyidagi oʻlchovlarni hali hisobot qilmaydi:

• end-to-end prototype benchmark,
• quote proof hajmi,
• ZK verification latency,
• gas cost,
• relay API latency,
• throughput,
• yuk ostida scalability.

Shu sababli HFIPay amalda klassik transferdan necha millisekund sekinroq ekani, har bir tranzaksiya qancha xarajat keltirishi yoki soniyasiga nechta toʻlovni qayta ishlashi bu maqoladan aniqlab boʻlmaydi.

Verified-quoteʻning qoʻshimcha xarajati

Manba miqdoriy benchmark bermasa ham, arxitekturaning qoʻshimcha yukini sifat jihatdan tavsiflaydi.

Baseline HFIPay:

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

talab qiladi.

Verified-quote versiyasi ularga qoʻshimcha ravishda:

relay tomonidan quote proof generation + joʻnatuvchi tomonidan quote verification

qoʻshadi.

Joʻnatuvchi koʻradigan quote materialining hajmi:

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

claim transaction hajmi esa:

O(|π_i|)

koʻrinishida ifodalanadi.

Asosiy cheklovlar

1. Relay butunlay yoʻqolmaydi: maxfiylik, notification va availability uchun relayʻga bogʻliqlik mavjud.
2. Baseline rejimida recipient substitution xavfi ishonch farazidir.
3. Binding issuer notoʻgʻri attestation berishi yoki ishlamay qolishi mumkin.
4. Relay directory compromise oldingi intentʻlarni retrospektiv de-anonimlashtirishi mumkin.
5. Post-claim privacy zaifroq: ayni destination yoki public ID commitment qayta ishlatilsa bogʻlanish mumkin.
6. Verified-quote ichida bir epochʻdagi senderʻlar K_B,e orqali bir qabul qiluvchiga toʻlov qilayotganlarini anglab olishlari mumkin.
7. Network-layer traffic analysis doiradan tashqarida.
8. Elektron pochta/OIDC account takeover boshlangʻich enrollment xavfsizligini buzishi mumkin.
9. Cross-chain deposit verification alohida ishonch muammosidir.
10. Production benchmark hali mavjud emas.

Kelgusi ish yoʻnalishlari

Manba toʻrtta asosiy rivojlantirish yoʻnalishini taklif qiladi:

• Quote-proof optimization: sender-verifiable proofʻlarni siqish yoki agregatsiyalash.
• Private directory federation: bitta relayʻdagi compromise xavfini kamaytirish uchun directoryʻni mustaqil operatorlarga taqsimlash.
• Proof aggregation: yuqori tranzaksiya hajmi uchun ZK-ACE claim proofʻlarni batch yoki recursive verification orqali birlashtirish.
• Lazy first-receipt onboarding: ilgari roʻyxatdan oʻtmagan qabul qiluvchini birinchi toʻlov paytida kuchli va xavfsiz tarzda tizimga kiritish.

Manba va Usul Haqida Izoh

Asl sarlavha: HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers

Muallif: Jian Sheng Wang.

Institutsional aloqasi: Yeah LLC.

Sana: 27 Mart 2026.

Manba: arXiv.

ArXiv identifikatori: arXiv:2603.26970v1 [cs.CR].

Tadqiqot turi: Kriptografik protokol va toʻlov tizimi arxitekturasi.

Asosiy taklif: Odamlar uchun qulay identifierʻlarga xususiy relay yechimi, intent-specific blinded recipient binding va nol bilim isbotli claim authorization orqali kripto toʻlov.

Asosiy maxfiylik maqsadlari: Enumeration resistance va pre-claim unlinkability.

Authorization infratuzilmasi: ZK-ACE.

Deterministik identity recovery komponenti: Va-Dar.

Cross-chain kengaytmasi: n-Vm.

Koʻrib chiqilgan qoʻllash muhitlari: EVM-compatible chains va Solana; Bitcoin/n-Vm BVM uchun konseptual kengaytma.

Muhim texnik komponentlar: random 256-bit intentId, blinded binding ρ, binding-key commitment K_B,e, verified quote, CREATE2, Solana PDA, ZK claim proof, sender-authorized refund.

Taqriz holati: Manba arXiv versiyasidir; yuklangan hujjat taqrizli jurnal yoki konferensiya qabul maʻlumotini taqdim etmaydi.

Eksperimental holat: Manba end-to-end production prototype benchmark yoki miqdoriy performance evaluation hisobot qilmaydi.

Formal xavfsizlik chegarasi: G1 va G2 natijalari taʻriflangan observer modeli ostida proof sketch xususiyatiga ega; tadqiqot ularni toʻliq game-based cryptographic reduction sifatida taqdim etmaydi.

Ilmiy talqin chegarasi: HFIPay arxitekturasi odamlar uchun qulay identifier bilan kripto toʻlovda qulaylik va maxfiylik oʻrtasida yangi dizayn nuqtasini taklif qiladi. Manba tizim amaliy ishlab chiqarish muhitida xarajat, kechikish, yuqori yuk ostidagi ishlash yoki xavfsizlik operatsiyalari boʻyicha tasdiqlanganini koʻrsatmaydi.