Криптовалютаны жөнөтүүдөгү эң негизги колдонуучу тажрыйбасы көйгөйлөрүнүн бири — адамдардын узун жана ката кетирүүгө оңой блокчейн даректери менен иштөөгө мажбур болушу. Банктык которууда телефон номери же оңой таанылуучу эсеп маалыматы колдонулушу мүмкүн болсо, криптовалюта системаларында колдонуучу көп учурда туура блокчейн тармагын тандап, татаал даректи көчүрүп жана транзакция акысын төлөө үчүн тиешелүү тармактын жергиликтүү токенине ээ болушу керек.

Муну чечүүнүн эң жөнөкөй жолу электрондук почта дарегин түздөн-түз блокчейн дарегине байланыштыруу сыяктуу көрүнүшү мүмкүн. Бирок бул ыкма олуттуу купуялуулук көйгөйүн жаратат. Эгер адамдын электрондук почта дарегинен детерминисттик түрдө блокчейн дареги түзүлсө, электрондук почта дарегин билген каалаган адам ошол адамдын балансын, транзакция тарыхын жана каршы тараптар менен болгон байланыштарын ачык блокчейн аркылуу изилдей алат.

HFIPay бул көйгөйдү адамга колдонууга ыңгайлуу идентификатор менен блокчейндеги төлөм дарегин түздөн-түз бири-бирине байланыштырбоо аркылуу чечүүгө багытталган протокол архитектурасы. Система купуя идентификаторду багыттоо, жөнөтүүчү тарабынан текшериле турган сунуш, intent-ке өзгөчө blind binding жана нөлдүк-билим далили менен чынжыр үстүндөгү claim authorization катмарларын бири-биринен бөлөт.

Жөнөтүүчү алуучунун электрондук почта дареги сыяктуу идентификаторду гана көрсөтөт. Relay бул идентификаторду купуя маалымат базасында чечмелейт, ар бир төлөм үчүн кокус intentId түзөт жана чынжырга алуучунун электрондук почта дарегин же кайра колдонулуучу туруктуу алуучу белгисин эмес, ошол операцияга гана тиешелүү blinded binding мааниси болгон ρ ны жазат.

Verified-quote режиминде жөнөтүүчү акча жөнөтөрдөн мурда ρ мааниси чындап эле максатталган алуучунун жашыруун binding ачкычына таандык экенин off-chain proof аркылуу текшере алат. Каражат салынгандан кийин relay акчаны өзү каалаган башка алуучуга багыттай албайт; чыныгы алуучу ZK-ACE аркылуу ошол эле детерминисттик идентификация үй-бүлөсүнө таандык экенин нөлдүк-билим далили менен далилдеп, каражатты өзү тандаган дарекке которо алат.

Изилдөө ошондой эле HFIPay n-Vm архитектурасы менен айкалышканда ар кандай блокчейн чөйрөлөрүнүн ортосунда төлөмдү багыттоо үчүн колдонулушу мүмкүн экенин талкуулайт. Бирок архитектура азырынча end-to-end performance benchmark-тары менен текшериле элек.

Адамга ыңгайлуу крипто төлөм дареги эмне үчүн купуялуулук көйгөйүн жаратат?

Бир колдонуучунун:

alice@example.com

дареги түздөн-түз:

keccak256(identifier) → blockchain address

сыяктуу детерминисттик ыкма менен блокчейн дарегине айланат деп элестетели.

Колдонуу жагынан өтө жеңил көрүнгөн бул система блокчейндин ачыктыгынан улам тескери натыйжа берет. Alice’тин электрондук почта дарегин билген каалаган адам ошол эле эсептөөнү жүргүзүп, Alice’тин блокчейн дарегин таба алат.

Андан кийин чабуулчу ачык чынжырда:

• эсеп балансын,
• мурунку которууларды,
• кайсы токендер сакталганын,
• кайсы даректер менен транзакция жасалганын,
• транзакция убакыттарын

изилдей алат.

Ошондуктан HFIPay’дин негизги дизайн чечими “адамга ыңгайлуу идентификатор = ачык блокчейн дареги” деген теңдикти толугу менен жок кылуу болуп саналат.

HFIPay Электрондук Почта Дарегин Блокчейнде Ачыкка Чыгарбастан Төлөмдү Кантип Багыттайт?

HFIPay’де электрондук почта дареги, телефон номери же социалдык медиадагы колдонуучу аты блокчейнде түздөн-түз жайгаштырылбайт. Идентификатор купуя relay катмарында чечмеленет жана блокчейн тарабында ар бир төлөм үчүн жаңы түзүлгөн бир жолку маалымат колдонулат.

Протоколдо беш негизги роль бар:

Алуучунун жашыруун binding ачкычы

Алуучу B детерминисттик идентификация тамыры REVB аркылуу белгилүү бир binding epoch үчүн жашыруун handle түзөт:

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

Андан ачык сунушту текшерүүдө колдонууга боло турган binding-key commitment түзүлөт:

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

Бул жерде e binding epoch мааниси. Макала epoch белгисин алуучуга гана таандык кокус идентификатор кылбай, күнүмдүк же жумалык сыяктуу жалпы жана орой убакыт тилкесинен тандоону сунуштайт. Максат — epoch маалыматы өзүнчө кайра колдонулуучу алуучу белгисине айланып калбашы.

Эмне үчүн ар бир төлөм жаңы intentId колдонот?

Жөнөтүүчү төлөм сураганда relay криптографиялык жактан кокус 256-bit intent идентификаторун түзөт:

intentId ← {0,1}²⁵⁶

Андан соң чынжырга жөнөтүлө турган бир жолку blinded recipient binding эсептелет:

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

Ошол эле алуучуга кайра акча жөнөтүлгөндө жаңы intentId түзүлгөндүктөн, ρ да өзгөрөт.

Бул касиет HFIPay’дин pre-claim unlinkability максатынын өзөгүндө турат. Блокчейн байкоочусу эки башка intent бир эле электрондук почта дарегине тиешелүү экенин көрсөтө турган туруктуу recipient tag көрбөйт.

Baseline жана Verified-Quote эмне үчүн эки башка ишеним модели?

Baseline режиминде relay жаман ниетте болсо, төлөмгө чейин башка алуучуга таандык blinded binding түзө алат. Булак муну ачык эле ишеним божомолу катары калтырат.

Verified-quote режиминде көз карандысыз binding layer нормалдаштырылган колдонуучу идентификатору менен алуучунун binding-key commitment маанисинин ортосундагы байланышты тастыктайт.

Андан кийин relay жөнөтүүчүгө quote proof берет. Бул proof бир эле жашыруун uB,e мааниси бир убакта:

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

жана:

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

мамилелерин канааттандырарын далилдейт.

Жөнөтүүчү акчаны которо электе proof’ту жана чынжырга жазылган intent tuple’ды текшергендиктен, relay’дин кийин алуучуну алмаштыруусуна бөгөт коюу көздөлөт.

Жөнөтүүчү Акчаны Жөнөткөндөн Кийин Relay Аны Башка Дарекке Бура Алабы?

Verified-quote моделинин негизги коопсуздук максаты — муну алдын алуу.

Жөнөтүүчү каражат салуудан мурда:

1. binding attestation’ды текшерет,
2. quote proof’ту текшерет,
3. deposit дарегин intentId аркылуу өзү кайра эсептейт,
4. asset, сумма, chain, expiration жана refund талааларын текшерет,
5. блокчейнде катталган intent tuple кабыл алынган quote менен бирдей экенин текшерет.

Чынжырда, мисалы:

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

маалыматтары intent’ке байланыштырылгандан кийин relay алуучуну, token’ди, сумманы же refund семантикасын билинбей өзгөртүү үчүн жөнөтүүчүнүн текшерүүсүн же колдонулган криптографиялык түзүмдөрдү бузушу керек.

Төлөм процесси беш негизги фазадан турат

EVM үстүндө төлөм дареги кантип түзүлөт?

EVM-ылайыктуу блокчейндерде HFIPay детерминисттик deposit дарегин CREATE2 аркылуу аныктайт:

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

Мунун маанилүү өзгөчөлүгү — contract чындап deploy боло электе эле даректи эсептөөгө болот.

Factory contract ошол эле учурда intent’ке тиешелүү ρ, asset, сумма, epoch, expiration жана refund маалыматтарын сактай алат.

Solana’да кантип ишке ашырылат?

Solana тарабындагы тиешелүү түзүм Program Derived Address колдонот:

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

Intent state PDA ичинде:

• ρ,
• asset descriptor,
• сумма,
• epoch,
• expiration,
• refund metadata

сакталат.

SPL token колдонулганда программа intent’ке тиешелүү PDA-controlled token vault да түзө алат.

Claim учурунда алуучу эмнени далилдейт?

Алуучу чынжырга түздөн-түз “Мен ушул электрондук почта дарегимин” дебейт.

Анын ордуна ZK-ACE колдонуп, өзүнүн детерминисттик идентификациясы intent үстүндөгү blinded binding менен шайкеш экенин нөлдүк-билим далили аркылуу көрсөтөт.

Claim билдирүүсү булакта төмөнкү түзүм менен аныкталат:

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

Бул жердеги β — алуучу каражатты алгысы келген destination address; n болсо replay чабуулдарына каршы nonce.

Claim proof төмөнкү байланыштарды бирге байлайт:

детерминисттик идентификация → epoch handle → ρ → intentId → asset → сумма → destination

Ошондуктан mempool байкоочусу claim transaction’ды көчүрүп алып аны биринчи жөнөтүүгө аракет кылса да, proof каражатты чабуулчу тандаган башка destination address’ке которууга уруксат бербейт.

Intent жашоо цикли

Ар бир intentId бир гана жолу колдонулат.

CREATED → FUNDED → CLAIMED

же:

FUNDED → EXPIRED → REFUNDED

жолдорунун бири колдонулат.

Refund процесси да relay’дин бир тараптуу чечимине берилбейт. Булак моделинде жөнөтүүчү intent түзүлгөндө refund destination үчүн алдын ала authorization бере алат.

HFIPay Кайсы Купуялуулук Өзгөчөлүктөрүн Көздөйт?

1. Enumeration Resistance

Чабуулчу Alice’тин электрондук почта дарегин билсе да, блокчейн маалыматтарын гана карап, кайсы intent’тер Alice’ке таандык экенин аныктай албашы керек.

Чынжырда көрүнгөн негизги маалыматтар төмөнкүлөр:

Булак купуялуулук дооматы asset түрүн, сумманы, убакытты же chain маалыматын жашырат деп айтпайт. Enumeration resistance талдоосу ушул ачык metadata теңдештирилген шартта жүргүзүлөт.

2. Pre-Claim Unlinkability

Ошол эле колдонуучуга claim боло электе эки башка төлөм жасалганда, тышкы байкоочу бул эки intent бир эле адамга таандык экенин on-chain түзүмдүн өзүнөн гана түшүнө албашы керек.

Мунун негизги себеби ар бир intent өз алдынча кокус intentId колдонуп, blinded binding:

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

түрүндө ар жолу кайра түзүлүшү.

Claim аткарылгандан кийин анонимдүүлүк ошол бойдон калабы?

Жок. Макала бул чекти ачык кабыл алат.

Алуучу улам-улам бир эле public destination address β колдонсо, бул claim’дер бир эле көзөмөлгө таандык катары байланыштырылышы мүмкүн.

Ошондой эле verifier interface ар бир claim учурунда бир эле IDcomB commitment’ты ачык көрсөтсө, ошол commitment кайра колдонулган бардык транзакциялар чынжыр деңгээлинде бир-бирине байланышы мүмкүн.

Ошондуктан булак post-claim купуялуулугу маанилүү deployment’тарда identity commitment’ты verifier interface артында жашырууну же commitment ротациясын сунуштайт.

Verified-quote моделинде ар башка жөнөтүүчүлөр бири-бирин кыйыр түрдө байкай алабы?

Ооба. Бул булактын маанилүү деталдарынын бири.

Бир эле binding epoch ичинде бир алуучуга төлөм кылгысы келген ар башка жөнөтүүчүлөр quote ичинде бир эле KB,e commitment’ты көрүшөт.

Эгер бул жөнөтүүчүлөр кызматташса, бир эле алуучуга төлөп жатканын түшүнө алышат.

Бул маалымат блокчейнге жазылбагандыктан, G1 жана G2 алкагындагы жалпы on-chain observer купуялуулугун түз бузбайт; бирок булак муну cross-sender linkability деген ачык чектөө катары аныктайт.

Relay Маалымат Базасы Колго Түшсө Эмне Болот?

HFIPay чынжырдагы identifier маалыматын жашырат, бирок relay’дин купуя directory’си маанилүү купуялуулук катмары.

Эгер чабуулчу relay маалымат базасын колго түшүрсө:

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

дал келүүлөрүн жана identifier-to-intent жазууларын билип алышы мүмкүн.

Андан да маанилүүсү, мурдагы epoch handle’дар сакталса, чабуулчу блокчейндеги эски intentId маанилери үчүн:

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

эсептеп, тиешелүү убакыттагы мурдагы транзакцияларды артка карай де-анонимдештире алат.

Ошондуктан булак чабуулдун таасири активдүү intent’тер менен гана чектелбей, колго түшкөн жана дагы эле сакталган epoch’тарга тиешелүү бүт тарыхка жайылышы мүмкүн экенин баса белгилейт.

Сунушталган азайтуу чараларына encrypted-at-rest directory, hardware-backed keys, epoch ротациясы, бүткөн epoch handle’дарын өчүрүү, эски intent/quote жазууларын тазалоо жана келечекте relay кызматын бир нече көз карандысыз операторго бөлүштүрүү кирет.

Ошентсе да relay’дин компрометациясы өзү эле мурда чынжырга туура blinded binding менен жазылган intent’ти чабуулчунун өз дарегине claim кылууга жол бербеши керек; claim дагы эле ZK-ACE байланышын канааттандырышы зарыл.

HFIPay Чындап Децентралдашканбы?

Изилдөөнүн архитектурасы толугу менен relay’сиз эмес. Автор муну relay-assisted but non-custodial түзүм деп сүрөттөйт.

Relay:

• identifier directory сактайт,
• колдонуучуну payment intent менен шайкеш келтирет,
• билдирүү жөнөтөт,
• transaction relaying жасай алат,
• колдонуучунун атынан gas же rent төлөй алат.

Демек relay privacy dependency жана availability dependency бойдон калат.

Бирок verified-quote режиминде relay’дин ыйгарым укугу классикалык custodial “send to email” кызматынан чектелүү. Relay каражатты custody алдында кармабайт жана intent каржылангандан кийин туура proof жок болсо алуучуну өзгөртө албайт.

Үч катмарлуу ишеним архитектурасы

Чынжырлар Арасындагы Төлөм Кантип Иштейт?

HFIPay’дин негизги claim механизми бир блокчейндин ичинде иштей алгандай эле, булакта n-Vm деп аталган көп виртуалдык машина архитектурасы аркылуу чынжырлар аралык төлөмгө да кеңейтилет.

n-Vm жалпы identity layer астында бир нече VM иштеген Layer-1 ыкмасы катары аныкталат.

Бир identity commitment’тан ар башка чөйрөлөр үчүн даректер чыгарылышы мүмкүн:

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

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

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

α_native = id_com

Чынжырлар аралык агымдын мисалы

Булак өзгөчө маанилүү чек коёт: n-Vm колдонуу external-chain deposit verification көйгөйүн жок кылбайт.

Система булак чынжырда төлөм чындап жасалганын баары бир текшериши керек. Бул light-client proof, validator attestation же теңдеш ыкма менен аткарылышы зарыл.

Демек архитектура bridge ишенимин толук жок кылбайт; аны n-Vm консенсус чегине киргизүүнү көздөйт.

Bitcoin да камтылабы?

Изилдөө n-Vm ичинде BVM модулун болжолдоп, Bitcoin үчүн да концептуалдык агым берет.

BTC адегенде n-Vm deposit дарегине которулат, андан кийин wBTC түзүлүп intent’ке байланыштырылат. Алуучу claim’ден кийин BTC, EVM же SVM сыяктуу максатты тандай алат.

Бирок булак BVM Bitcoin sidechain, optimistic rollup же ZK Bitcoin Script текшерүүсү аркылуу так кантип ишке ашарын аныктабайт. Бул маселе келечектеги ишке калтырылган.

HFIPay ENS жана Stealth Address Системаларынан Кантип Айырмаланат?

Изилдөөнүн Ыкмасы жана Жыйынтыктары

Изилдөө эмне кылды?

Изилдөө лабораториялык эксперимент же production benchmark жүргүзгөн эмес. Негизги ыкма:

1. identifier негизиндеги крипто төлөмдөрдө купуялуулук көйгөйүн threat model аркылуу аныктоо,
2. relay, deterministic identity, blinded binding жана ZK authorization компоненттерин бир протоколго бириктирүү,
3. baseline жана verified-quote ишеним моделдерин бөлүү,
4. enumeration resistance жана pre-claim unlinkability үчүн коопсуздук эксперименттерин жана proof sketch’терди аныктоо,
5. EVM жана Solana үчүн ишке ашыруу эскиздерин түзүү,
6. n-Vm аркылуу чынжырлар аралык кеңейтүүнү түшүндүрүү.

G1: Enumeration Resistance

Булакта G1 эксперименти чабуулчуга максат identifier жана теңдеш public metadata шартында жаңы intent tuple берүү менен аныкталат.

Автордун сунушуна ылайык, relay directory колго түшпөсө, активдүү же сакталган epoch handle’дар public маалыматтан алынбаса жана колдонулган hash тиешелүү domain separation менен коопсуз болсо, polynomial-time on-chain байкоочунун target recipient менен comparison recipient’ти айырмалоо артыкчылыгы жокко эсе бойдон калышы керек.

Бул натыйжа протокол аныктаган байкоочу модели астындагы proof sketch болуп саналат; изилдөө аны жалпы жана толук formal verification жыйынтыгы катары бербейт.

G2: Pre-Claim Unlinkability

Экинчи коопсуздук эксперименти эки pre-claim intent бир эле алуучугабы же эки башка алуучугабы таандык экенин байкоочу айырмалай алабы деген маселени карайт.

Ар бир intent үчүн өз алдынча кокус intentId колдонулуп, ρ жашыруун handle жана жаңы intentId’ден чыгарылгандыктан, public metadata теңдештирилгенде on-chain байкоочу үчүн same recipient/two recipients абалдарын айырмалай турган кайра колдонулуучу public түзүм жок деп айтылат.

Quote-to-Claim Composition

Изилдөөнүн Lemma 3.1 бөлүгү verified-quote менен claim proof ортосундагы байланышты түзөт.

Quote proof:

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

жана:

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

мамилелерин канааттандырган жашыруун u бар экенин далилдейт.

Claim proof болсо детерминисттик идентификациядан алынган u' мааниси ошол эле ρ ны түзөрүн көрсөтөт.

Автор колдонулган hash collision resistance божомолун канааттандырса, ар башка u жана u' маанилеринин бир эле түзүмдөлгөн ρ ны жаратышы hash collision талап кылат деп жүйө келтирет. Ошондуктан ийгиликтүү quote жана claim бир эле epoch-scoped hidden handle’га байланыштырылат деген жыйынтык чыгарылат.

Өлчөнгөн өндүрүмдүүлүк жыйынтыктары барбы?

Жок.

Макала төмөнкү өлчөөлөрдү азырынча билдирбей турганын ачык көрсөтөт:

• end-to-end prototype benchmark,
• quote proof өлчөмү,
• ZK verification latency,
• gas cost,
• relay API latency,
• throughput,
• жүк астындагы scalability.

Ошондуктан HFIPay практикада классикалык которуудан канча миллисекунд жайыраак экени, бир транзакцияга канча чыгым кетери же секундасына канча төлөм иштете алары бул макаладан аныкталбайт.

Verified-quote’тун кошумча чыгымы

Булак сандык benchmark бербесе да, архитектуранын кошумча жүгүн сапаттык түрдө сүрөттөйт.

Baseline HFIPay:

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

талап кылат.

Verified-quote версиясы мындан тышкары:

relay тарабынан quote proof generation + жөнөтүүчү тарабынан quote verification

кошот.

Жөнөтүүчү көргөн quote материалынын өлчөмү:

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

ал эми claim transaction өлчөмү:

O(|π_i|)

түрүндө берилет.

Негизги чектөөлөр

1. Relay толугу менен жок болбойт: купуялуулук, notification жана availability жагынан relay көз карандылыгы бар.
2. Baseline режиминде recipient substitution коркунучу ишеним божомолу болуп саналат.
3. Binding issuer туура эмес attestation бере же жеткиликсиз болуп калышы мүмкүн.
4. Relay directory compromise мурдагы intent’терди артка карай де-анонимдештириши мүмкүн.
5. Post-claim privacy алсызыраак: бир эле destination же public ID commitment кайра колдонулса байланыш түзүлүшү мүмкүн.
6. Verified-quote ичинде бир epoch’тагы sender’лер K_B,e аркылуу бир эле алуучуга төлөп жатканын түшүнө алышат.
7. Network-layer traffic analysis камтылбайт.
8. Электрондук почта/OIDC account takeover баштапкы enrollment коопсуздугун бузушу мүмкүн.
9. Cross-chain deposit verification өзүнчө ишеним маселеси.
10. Production benchmark азырынча жок.

Келечектеги иш багыттары

Булак төрт негизги өнүктүрүү багытын сунуштайт:

• Quote-proof optimization: sender-verifiable proof’тарды кысуу же агрегаттоо.
• Private directory federation: бир relay’деги compromise коркунучун азайтуу үчүн directory’ни көз карандысыз операторлорго бөлүштүрүү.
• Proof aggregation: жогорку транзакция көлөмү үчүн ZK-ACE claim proof’тарын batch же recursive verification менен бириктирүү.
• Lazy first-receipt onboarding: буга чейин катталбаган алуучуну биринчи төлөм учурунда күчтүү жана коопсуз түрдө системага кошуу.

Булак жана Ыкма Жөнүндө Эскертүү

Түпнуска аталышы: HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers

Автор: Jian Sheng Wang.

Уюмдук байланышы: Yeah LLC.

Дата: 27 Март 2026.

Булак: arXiv.

ArXiv идентификатору: arXiv:2603.26970v1 [cs.CR].

Изилдөөнүн түрү: Криптографиялык протокол жана төлөм системасынын архитектурасы.

Негизги сунуш: Адамга ыңгайлуу identifier’ларга купуя relay чечими, intent-specific blinded recipient binding жана нөлдүк-билим далили бар claim authorization аркылуу крипто төлөм.

Негизги купуялуулук максаттары: Enumeration resistance жана pre-claim unlinkability.

Authorization инфраструктурасы: ZK-ACE.

Детерминисттик identity recovery компоненти: Va-Dar.

Cross-chain кеңейтүүсү: n-Vm.

Каралган колдонмо чөйрөлөрү: EVM-compatible chains жана Solana; Bitcoin/n-Vm BVM үчүн концептуалдык кеңейтүү.

Маанилүү техникалык компоненттер: random 256-bit intentId, blinded binding ρ, binding-key commitment K_B,e, verified quote, CREATE2, Solana PDA, ZK claim proof, sender-authorized refund.

Рецензия абалы: Булак arXiv версиясы; жүктөлгөн документ рецензияланган журналга же конференцияга кабыл алуу маалыматын бербейт.

Эксперименттик абал: Булак end-to-end production prototype benchmark же сандык өндүрүмдүүлүк баалоосун бербейт.

Формалдык коопсуздук чеги: G1 жана G2 жыйынтыктары аныкталган observer модели астында proof sketch мүнөзүндө; изилдөө аларды толук game-based cryptographic reduction катары бербейт.

Илимий чечмелөө чеги: HFIPay архитектурасы адамга ыңгайлуу identifier менен крипто төлөмдө колдонууга ыңгайлуулук жана купуялуулук ортосунда жаңы дизайн чекитин сунуштайт. Булак системанын практикалык өндүрүш чөйрөсүндө чыгым, кечигүү, жогорку жүктөгү өндүрүмдүүлүк же коопсуздук операциялары боюнча текшерилгенин көрсөтпөйт.