FC-GUARD, ni muundo wa mfumo wa ubadilishaji unaolinda faragha unaolenga kuzuia utambulisho halisi wa mtumiaji, akaunti yake ya benki na anwani yake ya kripto kuhusishwa kupitia rekodi moja ya muamala katika miamala ambamo fedha za kawaida za fiat hubadilishwa kuwa sarafu za kripto; mfumo huu hutumia vitambulisho vinavyoweza kuthibitishwa (Verifiable Credentials, VC), mawasilisho yanayoweza kuthibitishwa (Verifiable Presentations, VP) na uthibitisho wa maarifa-sifuri (Zero-Knowledge Proofs, ZKP). Utafiti uliotengenezwa na Shaoyu Li, Hexuan Yu, Md Mohaimin Al Barat, Yang Xiao, Y. Thomas Hou na Wenjing Lou unalenga kuunganisha uanonimu pamoja na mahitaji ya Mfahamu Mteja Wako (Know Your Customer, KYC) na ukaguzi wa kodi ndani ya miundombinu ileile ya miamala.

Hoja ya kuanzia ya utafiti ni kwamba majukwaa ya jadi ya ununuzi wa sarafu za kripto yanaweza kuhifadhi taarifa binafsi zinazoweza kumtambulisha mtumiaji (Personally Identifiable Information, PII), akaunti za benki na anwani za kripto kwa namna inayowezesha kuhusishwa kwa taarifa hizo. Kuvamiwa kwa hazina kama hiyo ya data hakuleti tu uvujaji wa jina au nambari ya akaunti; pia huleta hatari ya kulinganisha historia ya miamala ya mtumiaji kutoka rekodi za blokcheni zilizo wazi kwa umma na utambulisho wake halisi. FC-GUARD hutumia mifumo ya uthibitishaji wa kikriptografia badala ya kufichua moja kwa moja taarifa nyeti ili kupunguza uhusiano huu wakati wa muamala.

Mfumo uliopendekezwa una hatua kuu tatu: kuthibitisha utambulisho wa mtumiaji mara moja na kutoa kitambulisho, kutekeleza ubadilishaji unaofuata wa fiat–kripto kwa uthibitishaji wa utambulisho usiotaja mtu, na kuwezesha mamlaka yenye uwezo kufanya ukaguzi kwa kutumia utambulisho uliosimbwa inapohitajika. Hatua ya kwanza ya usajili si ya uanonimu; mtumiaji huwasilisha taarifa zake za PII kwa jukwaa. Ulinzi wa faragha umeundwa kwa miamala ya ubadilishaji inayofanyika baada ya usajili. Tofauti hii ni muhimu ili kuelewa kwa usahihi dai la usalama la mfumo.

Watafiti walitekeleza mfano wa FC-GUARD katika mazingira ya kompyuta ya mezani na Android. Seva zilitumia matukio ya Amazon EC2 c5.large, upande wa mteja ukatumia kituo cha kazi cha Intel Xeon na Google Pixel 8a; shughuli za kikriptografia ziliungwa mkono na Hyperledger AnonCreds, Hyperledger Indy na usimbaji wa ElGamal wa 2048 bit. Uhamishaji wa sarafu za kripto ulitathminiwa kwenye mtandao wa majaribio wa Bitcoin wa ndani.

Kulingana na matokeo ya chanzo, usajili wa mtumiaji wa mara moja kwenye kompyuta ya mezani ulichukua 156,95 ms kwa FC-GUARD na 5,11 ms kwa mfumo wa msingi wa kulinganisha. Katika muamala wa ubadilishaji, hatua ya uthibitishaji wa utambulisho iliripotiwa kuwa 464,87 ms kwa FC-GUARD ya mezani na sekunde 3,40 katika programu ya simu. Katika mwingiliano na benki, FC-GUARD ya mezani ilipimwa kwa 363,27 ms na toleo la simu kwa 298,32 ms. Muda wa jumla wa ukaguzi uliripotiwa kuwa 2,65 ms katika mfumo wa msingi na 362,52 ms katika FC-GUARD.

Vipimo hivi vinaonyesha kwamba shughuli za ziada za kikriptografia zina gharama inayoonekana, lakini pia kwamba programu za mezani na simu ziliweza kutekelezwa katika mazingira ya majaribio ya utafiti. Hata hivyo, utafiti haujathibitisha usambazaji mkubwa wa uzalishaji katika taasisi halisi ya fedha, utiifu kwa sheria za nchi zote, au usalama dhidi ya miungano yote ya pande zenye nia ovu. Katika nchi zenye miundombinu tofauti ya benki na uthibitishaji wa utambulisho, kama Türkiye, utekelezaji pia ungehitaji marekebisho ya kiufundi, kisheria na kiutendaji.

Tatizo la msingi la faragha katika mpito kati ya fedha za fiat na sarafu za kripto

Fedha ya fiat (fiat currency), ni sarafu ya jadi ambayo thamani yake inategemea kukubalika na serikali na mfumo wa fedha. Fedha za fiat kama dola ya Marekani zinaweza kutumika katika mfumo wa benki kupitia salio la akaunti na uhamishaji wa kielektroniki. Sarafu za kripto, kwa upande mwingine, ni mali za kidijitali zinazowakilishwa kwenye daftari lililosambazwa au blokcheni. Majukwaa yanayofanya ubadilishaji wa fedha kati ya maeneo haya mawili ya kifedha yanaweza kuchukua fedha ya mtumiaji kutoka benki na kutuma mali ya kidijitali kwa anwani ya kripto iliyobainishwa kwa thamani inayolingana.

Katika muamala wa jadi, jukwaa kwa kawaida hujifunza utambulisho halisi wa mtumiaji, taarifa za akaunti ya benki, akaunti ya jukwaa na anwani ya kripto. Sehemu ya hili inatokana na uthibitishaji wa utambulisho, kuzuia udanganyifu na wajibu wa kisheria. Hata hivyo, kuwepo kwa taarifa hizi zote pamoja katika taasisi moja huleta tatizo kubwa la faragha.

Ingawa anwani za blokcheni hazina jina la mtu moja kwa moja, miamala katika blokcheni nyingi za umma inaweza kuchunguzwa na kila mtu. Uhusiano kati ya utambulisho halisi na anwani ya kripto ukishafichuka mara moja, inaweza kuwa rahisi kuhusisha mienendo ya zamani na ya baadaye inayohusiana na anwani hiyo na mtumiaji. Chanzo kinajadili tatizo hili kama uondoaji wa uanonimu au upotevu wa uanonimu ambao ni vigumu kuugeuza.

Mkabala mkuu wa FC-GUARD ni kuliondoa jukwaa katika nafasi ya kuwa hazina kuu ya data inayoweza kuona taarifa zote. Jukwaa lazima liweze kuthibitisha kwamba muamala ni halali na kutuma sarafu ya kripto; lakini kufanya hivyo hakupaswi kulazimisha jukwaa kujua nambari ya wazi ya akaunti ya benki ya mtumiaji au utambulisho wake halisi wakati wa muamala.

Tofauti kati ya mfumo wa jadi na FC-GUARD

Katika mchakato wa jadi, jukwaa linaweza kulinganisha akaunti ya mtumiaji na akaunti ya benki na anwani ya kripto; katika ujumbe wa muamala wa FC-GUARD, badala ya utambulisho halisi wa mtumiaji kuna uthibitisho wa utambulisho usiotaja mtu, taarifa ya akaunti iliyosimbwa ambayo benki inaweza kufungua, na anwani ya kripto.

Muundo huu hauzuii benki kumjua mteja na akaunti yake. Benki lazima ijue akaunti halisi ili kutekeleza uhamishaji wa fedha za fiat. Vivyo hivyo, jukwaa lazima lijue anwani lengwa ili kutekeleza uhamishaji wa kripto. Lengo ni kuzuia kila upande kujua taarifa zote na kuzuia upande mmoja kuweza kuhusisha kwa kujitegemea utambulisho na historia ya miamala ya kripto.

FC-GUARD Hutoa Uanonimu Vipi Bila Kuondoa Uthibitishaji wa Utambulisho?

FC-GUARD humthibitisha mtumiaji kwa utambulisho wake halisi wakati wa usajili wa kwanza, kisha hutumia mawasilisho yanayoweza kuthibitishwa yanayotokana na uthibitishaji huo na yaliyokusudiwa kutoweza kuhusishwa na kila moja. Kwa njia hii, jukwaa linaweza kuthibitisha kwamba mtu anayefanya muamala ana kitambulisho halali; lakini katika hatua ya ubadilishaji halilazimiki kujua moja kwa moja ni mtu gani aliyesajiliwa anayefanya muamala huo.

Pande tano za mfumo

Katika modeli ya tishio na muamala ya utafiti kuna pande tano kuu:

Hapa SSA inamaanisha Utawala wa Usalama wa Jamii wa Marekani (Social Security Administration), na SSN inamaanisha Nambari ya Usalama wa Jamii (Social Security Number). Hivi ni vipengele mahususi kwa hali ya uthibitishaji wa utambulisho ya utafiti inayolenga Marekani. Haiwezi kudhaniwa kwamba katika nchi nyingine vitakuwa na taasisi na nambari zilezile moja kwa moja.

Kitambulisho kinachoweza kuthibitishwa ni nini?

Verifiable Credential (VC), ni kitambulisho cha kidijitali ambacho usahihi wa sifa fulani umethibitishwa kikriptografia na mtoaji. Mtoaji (issuer) husaini sifa za mtumiaji. Mtumiaji (holder) huhifadhi taarifa hiyo na, inapohitajika, humwasilishia mthibitishaji (verifier) ushahidi kwamba sifa hizo ni halali.

Kwa mfano, katika FC-GUARD kitambulisho kinachotolewa na jukwaa kina jina, tarehe ya kuzaliwa na SSN, ilhali kitambulisho kinachotolewa na benki kinahusisha jina la benki, nambari ya akaunti na SSN. Vitambulisho hivi viwili vinaweza kusainiwa na taasisi tofauti. Mtumiaji anaweza kuunda uwasilisho unaowezesha kuvithibitisha bila kufichua sehemu fulani za taarifa hizo.

Tofauti kati ya VC na VP

VC ni kielelezo cha kikriptografia cha hati ya msingi ya utambulisho. Verifiable Presentation (VP) ni uwasilisho uliotayarishwa kutoka hati hiyo kwa uthibitishaji fulani. VC inaweza kubaki halali kwa muda mrefu, huku matokeo tofauti ya VP yakiweza kuundwa katika miamala tofauti. Hivyo, hata kama kitambulisho kilekile kinatumika, lengo ni jukwaa lisiweze kuunganisha mawasilisho hayo moja kwa moja.

Chanzo kinaeleza kwamba kipengele hiki kinaungwa mkono na urandomishaji wa saini na uthibitisho wa maarifa-sifuri. Kuweza kuthibitisha uwasilisho hakulazimishi jina halisi la mtumiaji au thamani ya SSN kuonyeshwa kwa mthibitishaji.

Uthibitisho wa maarifa-sifuri ni nini?

Zero-Knowledge Proof (ZKP), ni familia ya mbinu za kikriptografia zinazomwezesha upande mmoja kuthibitisha kwamba anajua taarifa fulani au kwamba sharti fulani ni kweli bila kufichua taarifa ya siri inayohusika.

Katika FC-GUARD mkabala huu hutumiwa mahali kadhaa. Mtumiaji anaweza kuthibitisha kwamba ana VC halali, kwamba sifa ya siri ya utambulisho inayohusishwa na akaunti ya benki inalingana na kitambulisho cha jukwaa, au kwamba akaunti iliyosimbwa inahusiana na taarifa iliyothibitishwa. Jukwaa hukagua uthibitisho huo; lakini halilazimiki kupokea kwa maandishi wazi thamani ya siri inayothibitishwa na uthibitisho.

Utaratibu huu haumaanishi kwamba uthibitisho wenyewe ni namba iliyokisiwa kwa nasibu. Uthibitisho huthibitisha mahusiano ya kihisabati kati ya kitambulisho halali, saini na sifa za siri zinazohusika. Usalama wa mbinu unategemea dhana za miundo ya kikriptografia inayotumika.

Ufichuaji teule na uthibitishaji wa umri

Chanzo kinajadili mawasilisho yanayoweza kuthibitishwa ambayo yanaweza kufichua tu sifa zinazohitajika za kitambulisho. Kwa mfano, bila kushiriki moja kwa moja tarehe yake ya kuzaliwa, mtumiaji anaweza kuonyesha kwa uthibitisho wa masafa kwamba umri wake ni mkubwa kuliko thamani fulani ya kizingiti \(x\).

Katika matumizi haya, kitu ambacho mthibitishaji anahitaji kujua si tarehe nzima ya kuzaliwa bali kama sharti la umri linalohitajika limetimizwa. Katika chanzo, uthibitishaji wa umri umetolewa kama mfano wa sharti la ziada la utambulisho; vipimo vya utendaji vya FC-GUARD havisemi kwamba miamala yote ilitumia kizingiti fulani cha umri.

Kwa nini usajili wa mara moja si wa uanonimu?

Wakati wa usajili wa kwanza, jukwaa lazima lifanye uthibitishaji wa utambulisho halisi. Mtumiaji huwasilisha taarifa za PII; jukwaa hufanya uthibitishaji wa SSA na, ukifaulu, humtolea mtumiaji VC iliyosainiwa. Mtumiaji huhifadhi kitambulisho hiki katika pochi yake binafsi ya siri.

Kwa hiyo, kauli kwamba “FC-GUARD haikusanyi PII katika hatua yoyote” ingekuwa si sahihi. Utafiti unatenganisha usajili wa kwanza na miamala ya ubadilishaji inayofuata. Faida ya faragha inalenga kuzuia uhusiano wa moja kwa moja kati ya mtumiaji aliyesajiliwa na miamala mipya ya kripto kuanzishwa wakati wa muamala.

Hisabati ya mfumo wa kuunda kitambulisho

Katika kueleza msingi wa kikriptografia wa vitambulisho vinavyoweza kuthibitishwa, chanzo kinatoa maelezo ya kuunda ufunguo yanayohusu muundo wa saini wa Camenisch–Lysyanskaya (CL). Katika muundo huu, mwanzoni huchaguliwa namba mbili za kwanza \(p'\) na \(q'\) zenye takriban 1536 bit; kisha \(p\) na \(q\) huundwa kwa mahusiano yafuatayo:

\[ p=2p'+1,\qquad q=2q'+1 \]

Chanzo kinaweka sharti kwamba namba hizi mpya pia ziwe namba za kwanza. Kisha:

\[ n=pq \]

hukokotolewa. Hapa \(n\) ni moduli changamano inayotumika katika shughuli za baadaye za arithmetiki ya moduli. Kwa kuwa hutumika zao la namba mbili kubwa za kwanza, muundo wa kihisabati wa mfumo ni tofauti na hesabu ya kawaida ya namba ndogo kamili.

Chanzo kinaeleza kwamba chini ya moduli \(n\), salio la mraba \(S\) huchaguliwa kwa nasibu na eksponenti zifuatazo huzalishwa:

\[ x_Z,x_{R_1},\ldots,x_{R_l}\in[2,p'q'-1] \]

Kisha thamani zifuatazo hukokotolewa:

\[ Z=S^{x_Z}\pmod n \]

\[ R_i=S^{x_{R_i}}\pmod n \qquad (1\le i\le l) \]

kwa namna hii. Alama \(\pmod n\) inaonyesha kwamba matokeo ya operesheni ya kuinua kwa nguvu yanatathminiwa kwa moduli \(n\). \(l\) inawakilisha muundo wa faharasa za namba wa sifa husika katika skimu ya kitambulisho.

Mwishoni mwa maelezo haya, chanzo kinaonyesha ufunguo wa umma kama:

\[ pk=(n,S,Z,\{R_i\}_{1\le i\le l}) \]

na ufunguo binafsi kama:

\[ sk=(p,q) \]

.

Dokezo muhimu la mbinu: Milango hii inawakilisha usuli wa kihisabati wa miundombinu ya kitambulisho iliyowasilishwa katika chanzo. Katika sehemu ya baadaye, chanzo kinataja uthibitisho unaotegemea saini za BBS+ kwa NIZK na matumizi ya Hyperledger AnonCreds katika utekelezaji. Kwa kuwa miundo tofauti ya saini haikupunguzwa katika chanzo kuwa algoriti moja ya pamoja ya uthibitisho yenye maelezo kamili, milinganyo ya ufunguo wa CL haipaswi kuwasilishwa kana kwamba ndiyo algoriti kamili ya kutengeneza uthibitisho wote wa FC-GUARD.

Mlolongo wa utoaji wa kitambulisho

Katika Kielelezo 3, chanzo kinaonyesha miamala kati ya mtoaji, daftari la umma, mwenye kitambulisho na mthibitishaji. Katika mchakato wa msingi, skimu na ufafanuzi wa kitambulisho huchapishwa, mtumiaji hupokea taarifa za skimu, njia salama ya mawasiliano hufunguliwa, ombi la kitambulisho hutumwa, mtoaji hukagua ombi hilo na kitambulisho kilichosainiwa huwasilishwa kwa mtumiaji. Wakati wa uthibitishaji mtumiaji huunda VP kutoka kwenye kitambulisho; mthibitishaji hukagua uwasilisho na uthibitisho unaohitajika.

Chanzo pia kinaeleza kwamba mwenye kitambulisho huunda siri ya kiungo ya faragha na kwamba toleo lililofichwa la siri hii hutumiwa katika ombi la kitambulisho. Utaratibu huu unalenga kusaidia kuunganisha vitambulisho vingi kwa mwenyewe huku ukizuia thamani ya siri inayohusika kufichuliwa moja kwa moja.

VC iliyoundwa na jukwaa na VC iliyoundwa na benki

Utafiti unatumia vitambulisho vinavyotolewa na taasisi mbili tofauti. Kitambulisho kinachotolewa na jukwaa kinawakilisha kwamba utambulisho halisi wa mtumiaji umethibitishwa. Kitambulisho kinachotolewa na benki, kwa upande mwingine, huanzisha uhusiano unaoweza kuthibitishwa kati ya jina la benki, akaunti ya mtumiaji na sifa husika ya utambulisho.

Katika chanzo, kitambulisho kinachotolewa na benki kinaonyeshwa kwa namna ifuatayo:

\[ VC_{bu}=(name_b,AccNum_{bu},SSN_u,\sigma_{bu}) \]

\(name_b\) inawakilisha jina la benki, \(AccNum_{bu}\) nambari ya akaunti ya benki ya mtumiaji, \(SSN_u\) thamani ya SSN ya mtumiaji, na \(\sigma_{bu}\) saini ya kitambulisho.

Kitambulisho kinachotolewa na jukwaa, kwa upande mwingine, ni:

\[ VC_{pu}=(name,birthday,SSN_u,\sigma_{pu}) \]

kwa namna hii. Jina la mtumiaji, tarehe ya kuzaliwa na taarifa ya SSN hufanywa kuwa zinazoweza kuthibitishwa kwa saini ya jukwaa. Kuwepo kwa taarifa hizi katika taasisi mbili tofauti huruhusu kufaa kwa utambulisho na akaunti ya benki kuthibitishwa kila kimoja kivyake katika hatua ya ubadilishaji wa uanonimu inayofuata.

Hatua ya kwanza ya muamala wa ubadilishaji wa kripto: uthibitishaji wa jukwaa

Mtumiaji huanzisha ombi la ubadilishaji kwa kiasi cha fedha za fiat anachotaka kubadilisha, aina ya sarafu ya kripto na anwani lengwa ya kripto. Badala ya kuomba utambulisho halisi wa wazi wa mtumiaji, jukwaa hukagua uwasilisho unaoweza kuthibitishwa ulioundwa kutoka VC ya jukwaa.

Chanzo kinaonyesha uwasilisho huo kwa namna ifuatayo:

\[ VP_{pu}=(name',birthday',SSN'_u,Proof_{pu}) \]

Alama za mkato zilizo juu zinawakilisha sifa zilizofichwa; uwakilishi huu haumaanishi kwamba jina la mtumiaji au tarehe ya kuzaliwa imebadilishwa kuwa thamani mpya. \(Proof_{pu}\) ni uthibitisho wa maarifa-sifuri unaothibitisha kwamba mtumiaji ana kitambulisho halali cha jukwaa.

Uthibitishaji wa jukwaa ukifaulu, jukwaa huunda agizo lenye kitambulisho cha muamala (Order ID) na kiasi kinachohitajika cha fedha za fiat. Kisha mtumiaji huunda VP tofauti kutoka kwenye kitambulisho kilichotolewa na benki kwa ajili ya miamala ya upande wa benki.

Hatua ya pili: kuthibitisha akaunti ya benki bila kuifichua

Lengo la uthibitishaji wa benki ni kuonyesha kwamba mtumiaji kweli ana akaunti halali ya benki, lakini bila kutuma nambari ya akaunti kwa maandishi wazi kwa jukwaa. Mtumiaji husimba nambari ya akaunti kwa ufunguo wa umma wa benki:

\[ Enc_{pk_b}(AccNum_{bu}) \]

Hapa \(Enc\) inawakilisha operesheni ya usimbaji, \(pk_b\) ufunguo wa umma wa benki, na \(AccNum_{bu}\) nambari ya akaunti ya benki ya mtumiaji.

Taarifa iliyosimbwa inaweza kuhamishwa kwenda benki kupitia jukwaa. Jukwaa hubeba data iliyosimbwa, lakini kwa kuwa halina ufunguo binafsi wa benki halitarajiwi kuweza kufungua nambari ya akaunti moja kwa moja. Benki, kwa upande wake, hurejesha akaunti kwa ufunguo wake binafsi:

\[ AccNum_{bu}=Dec_{sk_b}(Enc_{pk_b}(AccNum_{bu})) \]

\(Dec\) inawakilisha kufungua usimbaji, na \(sk_b\) ufunguo binafsi wa benki. Mlinganyo huu unaonyesha kwamba usimbaji hufanywa kwa ufunguo wa umma wa benki na ufunguaji hufanywa kwa ufunguo binafsi unaolingana.

VP ya benki na usawa wa utambulisho wa siri

Chanzo kinatoa uwasilisho unaoweza kuthibitishwa wa benki kwa namna ifuatayo:

\[ VP_{bu}=(name_b,AccNum'_{bu},SSN'_u,Proof_{bu}) \]

Katika uwasilisho huu jina la benki hufichuliwa huku nambari ya akaunti na SSN zikifichwa. \(Proof_{bu}\) inawakilisha uthibitisho kuhusu uhalali wa kitambulisho cha benki na masharti yanayohitajika yanayohusiana na akaunti iliyosimbwa.

Utafiti pia unafafanua uthibitisho wa usawa ili kuonyesha kwamba sifa ya siri ya SSN katika kitambulisho cha jukwaa na sifa ya siri ya SSN katika kitambulisho cha benki zinamhusu mtu yuleyule:

\[ Proof_{eq}(SSN'_u\text{ in }VP_{pu}=SSN'_u\text{ in }VP_{bu}) \]

Lengo la uwakilishi huu si kufichua thamani ya SSN kwa kila mtu, bali kuthibitisha kwamba sifa ya utambulisho iliyofichwa katika mawasilisho mawili tofauti yanayoweza kuthibitishwa ni thabiti. Wakati jukwaa linathibitisha kwamba mawasilisho hayo mawili ni ya mtumiaji yuleyule anayestahili, halilazimiki kujua thamani halisi ya SSN katika hatua ya muamala.

Hatua ya tatu: uhamishaji wa fedha za fiat na sarafu za kripto

Jukwaa huwasiliana na benki husika kwa kutumia jina la benki na kupeleka kwa benki taarifa za akaunti yake pamoja na taarifa iliyosimbwa ya akaunti ya mtumiaji. Benki hufungua taarifa ya akaunti, hufanya taratibu za uthibitishaji na kutekeleza uhamishaji wa fedha. Chanzo pia kinaeleza kwamba, dhidi ya hatari ya udanganyifu, benki inaweza kutumia mbinu za uthibitishaji wa vipengele vingi kama msimbo wa matumizi moja kupitia SMS.

Baada ya uhamishaji wa fiat kufanikiwa, benki humjulisha mtumiaji na jukwaa kuhusu hali ya muamala. Kisha jukwaa hutuma mali ya kidijitali kutoka anwani yake ya kripto kwenda anwani ya kripto iliyobainishwa na mtumiaji.

Mfuatano huu unalenga kuongeza tabaka la faragha bila kubadilisha kabisa mtiririko wa kazi uliopo wa ubadilishaji wa benki na kripto. Hata hivyo, chanzo kinadhania kwamba pande zinafuata itifaki iliyokusudiwa na hazisitishi muamala mapema; kwa hiyo haiwezi kuhitimishwa kwamba itifaki mpya ya atomiki imethibitishwa kwa hali zote zinazowezekana za kushindwa kiutendaji.

Kwa nini usimbaji wa kiuwezekano ni muhimu?

Ikiwa nambari ileile ya akaunti ya benki ingezalisha kila mara matokeo yale yale yaliyosimbwa katika kila muamala, jukwaa lingeweza kuona kwamba thamani ileile iliyosimbwa imetumiwa tena hata bila kujua maandishi wazi. Kurudiwa kama huko kungeweza kuacha alama ya kuhusisha miamala tofauti na mtumiaji yuleyule.

Ili kupunguza hatari hii, utafiti unajadili matumizi ya usimbaji wa ufunguo wa umma wa kiuwezekano . Katika mbinu kama ElGamal na Paillier, nasibu hutumiwa kubadilisha data ileile iliyo wazi kuwa matokeo tofauti yaliyosimbwa katika miamala tofauti. Hivyo, matumizi ya tena ya akaunti ileile ya benki hayalazimiki kuonekana kwa jukwaa kama mfuatano uleule wa baiti.

Hata hivyo, kubadilika kwa matokeo yaliyosimbwa peke yake hakuondoi viungo vyote vya metadata. Vyanzo tofauti vya taarifa kama anwani ya IP, muda wa muamala, kufanana kwa kiasi au mienendo ya blokcheni vinaweza kuleta hatari tofauti za uhusishaji. Chanzo kinashughulikia baadhi ya hatari hizi kwa hatua za ziada za kiutendaji, huku uondoaji wa uanonimu katika tabaka la mtandao na programu ukiwekwa nje ya upeo.

Kwa nini uhusishaji wa anwani kwenye blokcheni unashughulikiwa tofauti?

Benki kujua utambulisho wa mtumiaji na muda wa uhamishaji wa fiat kunaweza kuleta hatari isiyo ya moja kwa moja ya kuhusisha muamala na matukio kwenye blokcheni ya umma hata kama benki haipokei anwani ya kripto moja kwa moja. Kwa hiyo, watafiti wanajadili hatua kama jukwaa kutumia anwani nyingi za kripto na kuzibadilisha kwa vipindi fulani.

Chanzo pia kinapendekeza watumiaji watumie anwani tofauti za kupokea kwa miamala tofauti ya ubadilishaji na kuongeza ucheleweshaji wa muda wa nasibu kwenye miamala. Hatua hizi zinalenga kupunguza hatari ya kulinganisha anwani moja kwa moja; lakini katika PDF iliyotolewa mchango wa kiasi wa kila hatua katika uanonimu haujapimwa kwa jaribio tofauti.

Katika FC-GUARD Mamlaka ya Ukaguzi Inawezaje Kutambua Utambulisho wa Mtumiaji?

Katika kila muamala, FC-GUARD huunda toleo la taarifa ya SSN ya mtumiaji lililosimbwa kwa ufunguo wa umma wa mamlaka ya ukaguzi na uthibitisho unaoonyesha kwamba utambulisho huo uliosimbwa unaendana na kitambulisho kinachoweza kuthibitishwa. Jukwaa hupeleka utambulisho uliosimbwa pamoja na rekodi ya muamala kwa mamlaka ya ukaguzi. Mtumiaji asipotoa taarifa inayohitajika kuhusu wajibu wa kodi, mamlaka ya ukaguzi inaweza kutumia ufunguo wake binafsi kufungua utambulisho; kipengele hiki kinalenga kuunganisha uanonimu na uwajibikaji katika itifaki ileile.

SSN iliyosimbwa kwa ajili ya ukaguzi

Chanzo kinaeleza kwamba utambulisho wa mtumiaji unasimbwa kwa ajili ya mamlaka ya ukaguzi kwa namna ifuatayo:

\[ Enc_{pk_{aa}}(SSN_u) \]

Hapa \(pk_{aa}\) ni ufunguo wa umma wa mamlaka ya ukaguzi; \(SSN_u\) ni sifa ya utambulisho ya mtumiaji. Zaidi ya hayo, mtumiaji huunda uthibitisho unaoonyesha kwamba thamani ya SSN iliyosimbwa ni thabiti na SSN iliyofichwa katika VC ya jukwaa.

Jukwaa huthibitisha uthibitisho huu na kuongeza taarifa ya SSN iliyosimbwa kwenye rekodi ya muamala. Hivyo, lengo ni jukwaa liweze kuthibitisha kwamba muamala unahusishwa na utambulisho halali unaoweza kukaguliwa bila kujua thamani halisi ya SSN.

Mlinganyo wa kufungua utambulisho katika ukaguzi

Mamlaka ya ukaguzi hufungua utambulisho kwa ufunguo wake binafsi inapohitajika:

\[ SSN_u=Dec_{sk_{aa}}(Enc_{pk_{aa}}(SSN_u)) \]

\(sk_{aa}\) inawakilisha ufunguo binafsi wa mamlaka ya ukaguzi. Kupitia utaratibu huu, lengo ni mamlaka iliyoidhinishwa iweze kutambua utambulisho kwa miamala maalumu bila jukwaa kuhitaji kuhifadhi SSN wazi wakati wa miamala.

Mpaka muhimu wa mamlaka ya kufungua utambulisho

Katika utafiti, kufungua utambulisho kumeundwa kufanyika pale ambapo kuna kutokufuata masharti katika taarifa ya kodi. Hata hivyo, kwa kuwa mamlaka ya ukaguzi ina ufunguo wake binafsi, ina uwezo wa kikriptografia wa kufungua utambulisho ikiwa inaweza kufikia rekodi husika iliyosimbwa.

Kwa hiyo, kauli ya moja kwa moja kwamba “mamlaka ya ukaguzi inaweza kiufundi kufungua utambulisho wa watumiaji wenye hatia pekee” si sahihi. Katika modeli ya chanzo, mamlaka ya ukaguzi inachukuliwa kuwa ya kuaminika na inadhaniwa kwamba mamlaka hii itatumika katika masharti yaliyobainishwa ya ukaguzi. Hii ndiyo tofauti kati ya uwezo wa kikriptografia na uidhinishaji wa kisheria au kitaasisi.

Kwa nini rekodi za ukaguzi zinatenganishwa na anwani ya kripto?

Kulingana na chanzo, katika rekodi ya muamala itakayotumwa kwa mamlaka ya ukaguzi, jukwaa huficha au hutenganisha anwani ya kripto ya mtumiaji na maelezo ya uhamishaji wa kripto. Lengo ni kuzuia mamlaka ya ukaguzi kupata kiotomatiki shughuli zote za blokcheni za mtumiaji wakati inafanya ukaguzi wa utambulisho.

Mamlaka ya ukaguzi inaweza kulinganisha taarifa ya muamala iliyotumwa kwake na tamko la mtumiaji. Katika hali ya chanzo, kutowasilisha taarifa au kugunduliwa kwa tamko lisilo sahihi kunakuwa sababu ya kufungua utambulisho. Matumizi ya mfumo kwa namna hii katika nchi halisi yanategemea sheria za nchi husika kuhusu ulinzi wa data, taarifa za kifedha na mamlaka ya ukaguzi.

Malengo ya usalama ya mfumo

Modeli ya tishio inaamini pande zipi?

Watafiti wanafanya modeli ya jukwaa na benki kama honest-but-curious, yaani kama pande zinazofuata itifaki lakini zinazoweza kujaribu kutoa hitimisho la ziada kutokana na taarifa wanazoweza kufikia. Inadhaniwa kwamba pande hizi zinatekeleza miamala kwa usahihi, hazibadilishi itifaki kiholela na hazisitishi mchakato kabla ya muda.

SSA na mamlaka ya ukaguzi zinachukuliwa kuwa za kuaminika. Hali za mashambulizi ambamo jukwaa na benki hushirikiana na kuunganisha taarifa ziko nje ya upeo wa utafiti. Inadhaniwa kwamba njia za mawasiliano kati ya pande zote zinalindwa kwa TLS.

Chanzo pia kinaweka nje ya upeo uondoaji wa uanonimu unaoweza kutokana na tabaka la mtandao na tabaka la programu. Kwa hiyo dai la uanonimu la FC-GUARD haliwezi kusomwa kama uanonimu usio na masharti dhidi ya anwani ya IP ya mtumiaji, alama ya kipekee ya kifaa, programu hasidi, uvujaji wa mfumo wa uendeshaji au korelasheni zote za metadata.

Tofauti na mifumo iliyopo ya faragha

Katika ulinganisho wa fasihi, utafiti unazingatia Chaumian e-cash, Zcash, Zether, Anonymous Zether, Bolt, PriBank, LDSP, TumbleBit, mbinu za coin mixing, Pisces na mifumo inayolenga CBDC. Chanzo kinaeleza kwamba sehemu muhimu ya kazi hizi inalenga faragha ya uhamishaji ndani ya kripto au mpangilio wa malipo wa asili ya kripto, ilhali FC-GUARD inalenga uhusiano wa utambulisho–benki–anwani unaotokea wakati fedha za fiat kwenye akaunti ya benki zinabadilishwa kwenda kwenye anwani ya kripto iliyo chini ya udhibiti wa mtumiaji.

Kwa mfano, Pisces inajadiliwa kama mkabala wa ubadilishaji wa kripto-kwa-kripto wenye uanonimu na unaokidhi kanuni. FC-GUARD, kwa upande mwingine, huchukulia mtiririko wa fiat-to-cryptocurrency, ambamo benki inahitaji taarifa wazi za akaunti, kama tatizo kuu. Tofauti hii inaonyesha kwamba mchango wa utafiti si kuchukua nafasi ya mifumo yote ya faragha ya kripto, bali kubuni suluhisho kwa tatizo maalumu la uhusishaji wa data katika modeli iliyopo ya ubadilishaji iliyounganishwa na benki.

Mpaka wa kubadilishwa kulingana na nchi

Utafiti unategemea uthibitishaji wa utambulisho unaotumia SSA nchini Marekani na modeli ya uhamishaji wa benki inayoongozwa na jukwaa. Watafiti wanaeleza wazi kwamba mbinu za uhamishaji wa benki zinaweza kutofautiana kati ya nchi na kwamba itifaki inaweza kuhitaji kurekebishwa.

Kwa upande wa Türkiye, wazo la msingi la mfumo — kuthibitisha utambulisho katika hatua ya kwanza na kuthibitisha uhalali wake wakati wa muamala bila kuufichua — linaweza kuwa mada ya utafiti wa kiufundi. Hata hivyo, mifumo ya uthibitishaji wa utambulisho nchini Türkiye, michakato ya uhamishaji wa fedha ya benki, mahitaji ya kumjua mteja, wajibu wa data binafsi na sheria zinazohusu watoa huduma za mali za kripto si sawa na za Marekani. PDF hii haionyeshi kwamba programu tayari ya FC-GUARD inayotii sheria za Türkiye imethibitishwa.

Mbinu na Matokeo ya Utafiti

Muundo wa utafiti wa majaribio

FC-GUARD haikuwasilishwa tu kama usanifu wa dhana. Ndani ya utafiti, mfano unaojumuisha wateja wa kompyuta ya mezani na simu ulitekelezwa, na pia mfumo wa msingi wa kulinganisha unaowakilisha mtiririko wa kazi wa jadi usio na ulinzi wa faragha uliandaliwa.

Lengo la ulinganisho ni kutathmini gharama ambayo shughuli za VC, VP, ZKP, usimbaji na ufunguaji katika FC-GUARD zinaongeza kwenye ucheleweshaji wa usajili, mwingiliano na benki, ubadilishaji na ukaguzi. Katika chanzo, uhamishaji wa Bitcoin ulifanywa kwenye testnet ya ndani na baadhi ya shughuli za benki zilipimwa chini ya hali za simuleringi.

Mazingira ya majaribio na vipengele vya programu

Ingawa chanzo kina uchanganuzi wa kina wa utendaji wa mazingira ya muamala, hakiripoti jaribio kubwa la uzalishaji kwenye taasisi halisi za benki na mtandao mkuu wa Bitcoin ulio hai. Kwa hiyo matokeo ya majaribio yanawakilisha utendaji wa mfano na hali za majaribio zilizobainishwa.

Matokeo ya hatua ya usajili

Kwa usajili wa mtumiaji wa mara moja, mfumo wa msingi uliripotiwa kuwa 5,11 ms na FC-GUARD 156,95 ms. Kwenye mteja wa simu, usajili ulichukua sekunde 3,35. Wakati wa usajili wa simu, wastani wa matumizi ya CPU ulitolewa kuwa %65,2 na matumizi ya kumbukumbu 11,45 MB.

Sababu ya tofauti hii ni kwamba FC-GUARD haifanyi tu ukaguzi wa utambulisho wa maandishi wazi; pia huandaa kitambulisho kinachoweza kuthibitishwa na kutekeleza shughuli husika za kikriptografia. Chanzo kinaeleza kwamba mchakato wa usajili haufanywi upya katika kila ubadilishaji na kwa hiyo gharama ya usajili wa kwanza haiongezwi moja kwa moja kwenye ucheleweshaji wa kila muamala.

Shughuli za mwanzo za mara moja kama kuunda skimu na ufafanuzi wa kitambulisho na kuzipakia kwenye daftari la umma hazikujumuishwa katika muda wa usajili uliopimwa. Kwa hiyo thamani ya 156,95 ms si muda wa kukamilisha usanidi wote wa mfumo.

Muda wa hatua za muamala

Katika chanzo, uthibitishaji wa utambulisho wa mfumo wa msingi unajumuisha ukaguzi wa taarifa wazi za akaunti, na mwingiliano na benki unajumuisha uhamishaji wa data moja kwa moja. Katika FC-GUARD, hatua hizo hizo zinajumuisha gharama za ziada kama shughuli za VP/ZKP na kufungua na kuthibitisha data iliyosimbwa.

Muda wa uhamishaji wa benki si muda wa mwisho hadi mwisho wa kukamilika kwa malipo kwenye mtandao halisi wa benki. Chanzo kinatathmini muda huo katika hali iliyosimuliwa ya ucheleweshaji unaofanana na VISA. Muda wa uhamishaji wa Bitcoin, kwa upande mwingine, ulipimwa kutoka kuundwa kwa muamala hadi ulipopokelewa mara ya kwanza na wenzao kwenye testnet; si sahihi kuulinganisha muda huu na muda wa uthibitisho wa block au kukamilika kusikoweza kurudishwa.

Matokeo ya mezani na simu yanapaswa kutafsiriwaje?

Uthibitishaji wa utambulisho wa FC-GUARD ya mezani uliripotiwa kuwa 464,87 ms, ilhali katika toleo la simu ulikuwa sekunde 3,40. Matokeo haya yanaonyesha kwamba shughuli za kikriptografia za utambulisho zinaweza kuchukua muda zaidi kwenye kifaa cha simu. Hata hivyo, mwingiliano wa simu na benki ulikuwa 298,32 ms, chini ya 363,27 ms iliyoripotiwa kwa kompyuta ya mezani. Kwa hiyo matokeo ya utafiti hayapaswi kujumlishwa kuwa kila shughuli lazima iwe polepole zaidi kwenye kifaa cha simu.

Katika hatua ya ubadilishaji wa simu, chanzo kinatoa wastani wa matumizi ya CPU wa %80 na matumizi ya kumbukumbu ya 97 MB. Muda wa kuunda VP na ZKP umetajwa kuwa sekunde 2,50. Vipimo hivi vinaonyesha kwamba mteja wa simu hubeba sehemu muhimu ya gharama ya ziada ya hesabu ya kikriptografia.

Gharama ya ukaguzi

Katika mfumo wa msingi, muda wa jumla wa ukaguzi ulipimwa kuwa 2,65 ms. Katika ukaguzi wa FC-GUARD, mtumiaji huunda utambulisho uliosimbwa na uthibitisho, jukwaa hukagua na kupeleka vitu hivyo, na mamlaka ya ukaguzi hufungua utambulisho uliosimbwa inapohitajika. Chanzo kinaripoti muda wa jumla wa mchakato huu kuwa 362,52 ms.

Kuongezeka kwa ucheleweshaji upande wa ukaguzi ni gharama ya shughuli za usimbaji na uthibitisho zilizoongezwa kwa ajili ya faragha na uwajibikaji. Hata hivyo, haiwezi kusemwa kwamba kila muamala wa mtumiaji lazima uhitaji kufungua utambulisho kwa namna ileile wakati wa ukaguzi; katika chanzo uanonimu umeundwa kuwa chaguo la kawaida, na kufungua utambulisho ni operesheni inayotegemea sababu ya ukaguzi.

Ulinganisho wa kuona wa utendaji

Chanzo cha kuona cha vipimo vya simu

Kielelezo 6 cha chanzo kina picha za skrini za programu ya simu zinazohusiana na hatua za usajili na ubadilishaji kwenye Google Pixel 8a. Picha zinaonyesha matokeo ya ujumbe wa programu na rekodi za vipimo. Maandishi ya chanzo yanatoa sekunde 3,35 kwa usajili, %65,2 CPU na 11,45 MB ya kumbukumbu; na kwa ubadilishaji takriban %80 CPU na 97 MB ya kumbukumbu.

Ingawa neno “baseline” linaonekana katika maelezo ya Kielelezo 6, maandishi ya vipimo yanayolizunguka yanaeleza mteja wa simu wa FC-GUARD. Kwa hiyo data za namba zimehifadhiwa hapa pamoja na maelezo ya chanzo, na neno katika maelezo ya kielelezo halijachukuliwa moja kwa moja kuwa ushahidi wa jaribio tofauti la simu la mfumo wa msingi.

Upeo wa matokeo ya utendaji

Matokeo ya utafiti yanaonyesha kwamba FC-GUARD iliweza kufanya kazi katika mazingira ya mfano yaliyobainishwa licha ya shughuli za ziada za kikriptografia. Kwa upande mwingine, haijathibitishwa kwamba matokeo yaleyale ya utendaji na usalama yanatumika kwa uwezo wa miamala sambamba chini ya mzigo mkubwa wa watumiaji, usambazaji mkubwa, uhamishaji wa wakati halisi katika mifumo tofauti ya benki, ucheleweshaji mkubwa wa mtandao na michanganyiko yote ya pande zenye nia ovu.

Chanzo pia kinakubali kwamba itifaki inaweza kuhitaji kuendelezwa zaidi ili kukidhi mahitaji mapana zaidi ya udhibiti na miundombinu ya malipo ya nchi tofauti.

Matokeo makuu yanayoungwa mkono na utafiti

• Kwa kutumia VC na ZKP, uthibitishaji wa ustahiki katika ubadilishaji wa fiat–kripto unaweza kubuniwa bila kufichua moja kwa moja utambulisho wa mtumiaji wakati wa muamala.
• Taarifa za akaunti ya benki zinaweza kusimbwa kwa ufunguo wa umma wa benki ili kuzuia ufikiaji wa jukwaa kwa nambari ya akaunti iliyo wazi.
• Kutumia mawasilisho yaliyofanywa nasibu na thamani zilizosimbwa katika miamala tofauti kunaweza kusaidia kutoweza kuhusishwa.
• Kwa utaratibu tofauti wa utambulisho uliosimbwa kwa ajili ya mamlaka ya ukaguzi, uwezekano wa kufungua utambulisho kwa ajili ya uwajibikaji unaweza kubuniwa.
• Mfano ulitekelezwa katika mazingira ya kompyuta ya mezani na Android na kutathminiwa kwa vipimo vya ucheleweshaji vilivyotolewa katika chanzo.
• Mifumo ya faragha ilileta gharama za ziada za uchakataji ikilinganishwa na mfumo wa msingi; hata hivyo, majaribio ya chanzo yanaunga mkono uwezekano wa utekelezaji.

Majumlisho ambayo utafiti hauungi mkono

• FC-GUARD haionyeshi kwamba taarifa ya utambulisho haifichuliwi kwa taasisi yoyote katika hatua zote.
• Haiungi mkono hitimisho kwamba uwezo wa kiufundi wa mamlaka ya ukaguzi kufungua utambulisho umewekewa kikomo kikriptografia kwa watumiaji maalumu pekee.
• Haitoi uthibitisho kamili wa usalama dhidi ya mashambulizi ambamo jukwaa na benki hushirikiana.
• Haionyeshi kwamba uanonimu katika tabaka la mtandao na tabaka la programu umehakikishwa.
• Haithibitishi kwamba ucheleweshaji uleule utapatikana katika mazingira ya benki halisi na mtandao mkuu ulio hai.
• Haiungi mkono kutafsiri ucheleweshaji uliopimwa wa Bitcoin testnet kama muda wa uthibitisho wa mnyororo au kukamilika.
• Haiungi mkono dai la utiifu wa kiotomatiki kwa KYC, kodi na sheria za data binafsi za nchi zote.
• Haiwezi kudhaniwa kwamba chanzo kina uthibitisho tofauti, kamili na rasmi wa usalama kwa kila utaratibu wa kikriptografia.

Hitimisho la jumla la utafiti

Utafiti wa FC-GUARD unawasilisha muundo wa mfumo unaolenga kuonyesha kwamba faragha katika matumizi ya sarafu za kripto na utiifu wa udhibiti wa fedha si lazima vitengane. Ubunifu wa mkabala ni kuweka vitambulisho vinavyoweza kuthibitishwa na uthibitisho wa maarifa-sifuri katika uhusiano wa mtumiaji–jukwaa–benki–mamlaka ya ukaguzi bila kuondoa kabisa miundombinu ya benki.

Matokeo ya utekelezaji yaliyotolewa na chanzo yanaunga mkono kwamba mkabala huu unaweza kukokotolewa katika mifano ya mezani na simu iliyojaribiwa. Hata hivyo, katika kuhamia kwenye mfumo halisi wa kifedha, pamoja na utendaji wa kiufundi, modeli ya uaminifu, mamlaka za ukaguzi, masharti ya ulinzi wa data, hatari za ushirikiano kati ya pande na sheria mahususi za nchi lazima zitathminiwe pia.

Maelezo ya Chanzo na Mbinu

Utafiti asili: FC-GUARD: Enabling Anonymous yet Compliant Fiat-to-Cryptocurrency Exchanges

Waandishi: Shaoyu Li; Hexuan Yu; Md Mohaimin Al Barat; Yang Xiao; Y. Thomas Hou; Wenjing Lou.

Mpangilio wa waandishi: Umehifadhiwa kama ulivyotolewa katika chanzo asili.

Uhusiano wa taasisi: Virginia Tech, Virginia, Marekani (Shaoyu Li, Hexuan Yu, Md Mohaimin Al Barat, Y. Thomas Hou, Wenjing Lou); University of Kentucky, Kentucky, Marekani (Yang Xiao).

Mchango sawa: Hakuna taarifa tofauti ya mchango sawa iliyotambuliwa katika PDF ya chanzo.

Mwandishi wa mawasiliano: Hakuna alama tofauti ya corresponding author iliyobainishwa katika PDF.

Toleo la chanzo: arXiv:2601.16298v1.

Tarehe ya kuwasilishwa kwa arXiv: 22 Januari 2026.

Eneo la arXiv: Computer Science – Cryptography and Security (cs.CR).

DOI ya arXiv: 10.48550/arXiv.2601.16298.

Kiungo rasmi cha arXiv: https://arxiv.org/abs/2601.16298

Utafiti uliochapishwa: IEEE INFOCOM 2026 – IEEE Conference on Computer Communications.

Mkutano: Tokyo, Japani, 18–21 Mei 2026.

DOI ya toleo lililochapishwa: 10.1109/INFOCOM59046.2026.11571719.

Mchapishaji: IEEE.

Mwaka wa uchapishaji: 2026.

Mapitio ya wenzao: Rekodi ya IEEE INFOCOM 2026 ni mchango wa mkutano uliopitiwa na wenzao. PDF iliyopakiwa ina alama ya arXiv v1; toleo hili halijachukuliwa moja kwa moja kuwa maandishi ya mwisho ya IEEE ambayo mchakato wa mapitio ya wenzao umekamilika.

Leseni: Rekodi ya arXiv inaonyesha sharti la non-exclusive license to distribute. Leseni hii si ruhusa ya jumla ya Creative Commons inayowaruhusu wahusika wengine kubadilisha kwa uhuru maandishi na vielelezo vinavyolindwa. Masharti ya hakimiliki ya toleo la IEEE lililochapishwa yanapaswa kutathminiwa kando.

Aina ya chanzo: Muundo wa mfumo/itifaki na tathmini ya mfano wa majaribio katika usalama wa kompyuta na kriptografia tumizi.

Mada ya utafiti: Uanonimu, kutoweza kuhusishwa, faragha ya akaunti ya benki, KYC ya uanonimu, ubadilishaji wa fiat–kripto na ukaguzi teule.

Mbinu kuu: Verifiable Credentials, Verifiable Presentations, Zero-Knowledge Proofs, Non-Interactive Zero-Knowledge Proofs, probabilistic public-key encryption, ElGamal, Hyperledger AnonCreds na Hyperledger Indy.

Miundombinu ya majaribio: Amazon EC2 c5.large, Ubuntu 22.04, kituo cha kazi cha Intel Xeon, Google Pixel 8a, Android 14, Python na Bitcoin testnet ya ndani.

Data kuu za utendaji: Usajili: mfumo wa msingi 5,11 ms, FC-GUARD ya mezani 156,95 ms; uthibitishaji wa utambulisho wa muamala: mfumo wa msingi 2,63 ms, FC-GUARD ya mezani 464,87 ms na simu 3,40 s; ukaguzi: mfumo wa msingi 2,65 ms na FC-GUARD 362,52 ms.

Dhana za usalama: Jukwaa na benki zimefanyiwa modeli kama honest-but-curious. SSA na mamlaka ya ukaguzi zimechukuliwa kuwa za kuaminika. Ushirikiano wa jukwaa–benki, uondoaji wa uanonimu katika tabaka la mtandao na tabaka la programu ziko nje ya upeo wa usalama wa utafiti.

Mpaka wa tafsiri ya kikriptografia: Chanzo kinajumuisha milinganyo inayohusu miundombinu ya kitambulisho ya aina ya CL, maelezo ya NIZK yanayotegemea BBS+ na utekelezaji wa Hyperledger AnonCreds. Maelezo haya hayajaunganishwa kuwa uthibitisho kamili wa primitive moja mpya ya kikriptografia.

Kizuizi cha kimbinu: Ucheleweshaji wa benki na vipimo vya Bitcoin testnet haviwakilishi moja kwa moja muda wa kukamilika katika mazingira hai ya uzalishaji. Tathmini za ziada zinahitajika kwa utiifu halisi wa udhibiti wa kifedha na ustahimilivu dhidi ya mashambulizi.

Chanzo cha vielelezo: Kielelezo 1 cha chanzo kinaonyesha mtiririko wa ubadilishaji wa jadi na FC-GUARD; Kielelezo 2 usanifu; Kielelezo 3 utoaji/uthibitishaji wa kitambulisho; Kielelezo 4 mchakato wa usajili; Kielelezo 5 mchakato wa ubadilishaji; na Kielelezo 6 vipimo vya programu ya simu. Michoro ndani ya Verianla imeundwa kwa kujitegemea kutokana na mahusiano ya kisayansi.

Dokezo la Kielelezo 6: Neno “baseline” linalotumika katika maelezo ya kielelezo halipatani kikamilifu na maelezo ya matokeo ya simu ya FC-GUARD yanayolizunguka. Verianla imewasilisha matokeo ya namba kwa kuyahusisha na aya husika ya chanzo.

Ufadhili: Utafiti uliungwa mkono kwa sehemu na National Science Foundation ya Marekani kupitia ruzuku nambari 2154929, 2247560, 2247561, 2331936, 2433904 na 2433905, na Virginia Commonwealth Cyber Initiative (CCI).

Mgongano wa maslahi: Hakuna tamko tofauti na la wazi la mgongano wa maslahi lililotambuliwa katika PDF ya chanzo.

Upatikanaji wa data na msimbo: PDF inaeleza miundombinu na zana za programu zilizotumika; hata hivyo, hakuna kiungo cha hazina rasmi tofauti ya data/msimbo kilichotambuliwa ambacho kina msimbo mzima wa chanzo wa mfano wa FC-GUARD na vipimo ghafi vya marudio ya majaribio.

CRediT / mchango wa waandishi: Hakuna matriksi tofauti ya kina ya michango ya CRediT iliyotambuliwa; viwango vya mchango wa waandishi havikugawanywa kwa kudhani.

Mpaka wa hitimisho la kisayansi: Imeripotiwa kwamba muundo wa FC-GUARD unaounganisha malengo ya faragha na utiifu unaweza kutekelezwa katika mazingira ya mfano. Matokeo hayatoi dhamana ya uanonimu kamili katika hali zote, ustahimilivu dhidi ya mashambulizi yote, au utiifu wa kiotomatiki kwa kila mfumo wa udhibiti.