Ne kemi qenë të interesuar për temën e anonimitetit në kriptovalutat për një kohë të gjatë dhe përpiqemi të ndjekim zhvillimin e teknologjive në këtë fushë. Në artikujt tanë ne kemi diskutuar tashmë në detaje parimet e funksionimit në Monero, dhe gjithashtu u krye teknologjitë ekzistuese në këtë fushë. Megjithatë, të gjitha kriptovalutat anonime sot janë ndërtuar mbi modelin e të dhënave të propozuar nga Bitcoin - Output Transaction Unspent (në tekstin e mëtejmë UTXO). Për blockchains të bazuara në llogari si Ethereum, zgjidhjet ekzistuese për zbatimin e anonimitetit dhe konfidencialitetit (për shembull, ose ) u përpoq të përsëriste modelin UTXO në kontratat inteligjente.
Në shkurt 2019, një grup studiuesish nga Universiteti Stanford dhe Visa Research lëshuar "Zether: Drejt privatësisë në botën e kontratave inteligjente." Autorët ishin të parët që propozuan një qasje për të siguruar anonimitetin në zinxhirët bllokues të bazuar në llogari dhe paraqitën dy versione të një kontrate inteligjente: për transaksione konfidenciale (fshehja e bilanceve dhe shumave të transferimit) dhe anonime (fshehja e marrësit dhe dërguesit). Ne e shohim interesante teknologjinë e propozuar dhe dëshirojmë të ndajmë dizajnin e saj, si dhe të flasim për arsyen pse problemi i anonimitetit në bllokun e bazuar në llogari konsiderohet shumë i vështirë dhe nëse autorët arritën ta zgjidhin atë plotësisht.
Rreth strukturës së këtyre modeleve të të dhënave
Në modelin UTXO, një transaksion përbëhet nga "inpute" dhe "outpute". Një analog i drejtpërdrejtë i "outputeve" janë faturat në portofolin tuaj: çdo "output" ka një emërtim. Kur paguani dikë (formon një transaksion) ju shpenzoni një ose më shumë "outpute", në këtë rast ata bëhen "inpute" të transaksionit dhe blockchain i shënon ato si të shpenzuara. Në këtë rast, marrësi i pagesës suaj (ose ju vetë, nëse keni nevojë për ndryshim) merr "outputet" e krijuara rishtazi. Kjo mund të paraqitet skematikisht si kjo:
Blockchain-et e bazuara në llogari janë të strukturuara shumë si llogaria juaj bankare. Ata merren vetëm me shumën në llogarinë tuaj dhe shumën e transferimit. Kur transferoni një shumë nga llogaria juaj, nuk digjni asnjë "dalje", rrjeti nuk ka nevojë të kujtojë se cilat monedha janë shpenzuar dhe cilat jo. Në rastin më të thjeshtë, verifikimi i transaksionit zbret në kontrollimin e nënshkrimit të dërguesit dhe shumës në bilancin e tij:
Analiza e teknologjisë
Më pas, do të flasim për mënyrën se si Zether fsheh shumën e transaksionit, marrësin dhe dërguesin. Ndërsa përshkruajmë parimet e funksionimit të tij, do të vërejmë ndryshimet në versionet konfidenciale dhe anonime. Meqenëse është shumë më e lehtë të sigurohet konfidencialiteti në blloqe të bazuara në llogari, disa nga kufizimet e vendosura nga anonimizimi nuk do të jenë të rëndësishme për versionin konfidencial të teknologjisë.
Fshehja e bilanceve dhe shumave të transfertave
Një skemë enkriptimi përdoret për të kriptuar bilancet dhe transferimin e shumave në Zether . Ajo funksionon si më poshtë. Kur Alice dëshiron të dërgojë Bob b monedha sipas adresës (çelësi i tij publik) Y, ajo zgjedh një numër të rastësishëm r dhe kodon shumën:
ku C - sasia e koduar, D - vlera ndihmëse e nevojshme për të deshifruar këtë shumë, G - një pikë fikse në lakoren eliptike, kur shumëzohet me çelësin sekret, fitohet çelësi publik.
Kur Bob i merr këto vlera, ai thjesht i shton ato në balancën e tij të koduar në të njëjtën mënyrë, prandaj kjo skemë është e përshtatshme.
Në mënyrë të ngjashme, Alice zbret të njëjtat vlera nga bilanci i saj, vetëm si Y përdor çelësin tuaj publik.
Fshehja e marrësit dhe dërguesit
Përzierja e "daljeve" në UTXO daton që në ditët e para të kriptomonedhave dhe ndihmon në fshehjen e dërguesit. Për ta bërë këtë, vetë dërguesi, kur bën një transferim, mbledh "dalje" të rastësishme në blockchain dhe i përzien ato me të tijat. Më pas, ai nënshkruan "daljet" me një nënshkrim unazë - një mekanizëm kriptografik që e lejon atë të bindë verifikuesin se monedhat e dërguesit janë të pranishme midis "daljeve" të përfshira. Vetë monedhat e përziera, natyrisht, nuk shpenzohen.
Megjithatë, ne nuk do të jemi në gjendje të gjenerojmë rezultate të rreme për të fshehur marrësin. Prandaj, në UTXO, çdo "dalje" ka adresën e vet unike dhe është e lidhur kriptografikisht me adresën e marrësit të këtyre monedhave. Për momentin, nuk ka asnjë mënyrë për të identifikuar marrëdhënien midis adresës unike të daljes dhe adresës së marrësit pa i ditur çelësat e saj sekretë.
Në modelin e bazuar në llogari, ne nuk mund të përdorim adresa një herë (përndryshe do të jetë tashmë një model "dalje"). Prandaj, marrësi dhe dërguesi duhet të përzihen midis llogarive të tjera në blockchain. Në këtë rast, një monedhë 0 e koduar debitohet nga llogaritë e përziera (ose 0 shtohet nëse marrësi është i përzier), pa ndryshuar realisht bilancin e tyre real.
Meqenëse si dërguesi ashtu edhe marrësi kanë gjithmonë një adresë të përhershme, bëhet e nevojshme të përdoren të njëjtat grupe për përzierje kur transferohen në të njëjtat adresa. Është më e lehtë ta shikosh këtë me një shembull.
Le të themi se Alice vendos të japë një kontribut në bamirësinë e Bobit, por preferon që transferimi të mbetet anonim për një vëzhgues të jashtëm. Më pas, për t'u maskuar në fushën e dërguesit, ajo hyn edhe në llogaritë e Adamit dhe Adelës. Dhe për të fshehur Bobin, shtoni llogaritë e Ben dhe Bill në fushën e marrësit. Duke dhënë kontributin e radhës, Alice vendosi të shkruante Alex dhe Amanda pranë saj, dhe Bruce dhe Benjen pranë Bobit. Në këtë rast, kur analizohet blockchain, në këto dy transaksione ka vetëm një palë pjesëmarrësish të kryqëzuar - Alice dhe Bob, i cili i de-anonimizon këto transaksione.
Garat e transaksioneve
Siç e kemi përmendur tashmë, për të fshehur gjendjen tuaj në sistemet e bazuara në llogari, përdoruesi kodon bilancin e tij dhe shumën e transferimit. Në të njëjtën kohë, ai duhet të provojë se gjendja në llogarinë e tij mbetet jo negative. Problemi është se kur krijon një transaksion, përdoruesi ndërton një provë në lidhje me statusin e llogarisë së tij aktuale. Çfarë ndodh nëse Bob dërgon një transaksion te Alice, dhe ai pranohet përpara atij të dërguar nga Alice? Atëherë transaksioni i Alice-s do të konsiderohet i pavlefshëm, pasi prova e bilancit është ndërtuar përpara se transaksioni i Bobit të pranohej.
Vendimi i parë që vjen në një situatë të tillë është ngrirja e llogarisë derisa të kryhet transaksioni. Por kjo qasje nuk është e përshtatshme, sepse përveç kompleksitetit të zgjidhjes së një problemi të tillë në një sistem të shpërndarë, në një skemë anonime nuk do të jetë e qartë se llogaria e kujt të bllokohet.
Për të zgjidhur këtë problem, teknologjia ndan transaksionet hyrëse dhe dalëse: shpenzimet kanë një efekt të menjëhershëm në bilanc, ndërsa arkëtimet kanë një efekt të vonuar. Për ta bërë këtë, prezantohet koncepti i "epokës" - një grup blloqesh me një madhësi fikse. "Epoka" aktuale përcaktohet duke ndarë lartësinë e bllokut me madhësinë e grupit. Kur përpunon një transaksion, rrjeti përditëson menjëherë bilancin e dërguesit dhe ruan fondet e marrësit në një rezervuar magazinimi. Fondet e grumbulluara vihen në dispozicion të përfituesit vetëm kur fillon një "epokë" e re.
Si rezultat, përdoruesi mund të dërgojë transaksione pavarësisht se sa shpesh merren fondet (sigurisht për aq sa e lejon bilanci i tij). Madhësia e epokës përcaktohet bazuar në shpejtësinë e përhapjes së blloqeve në rrjet dhe sa shpejt një transaksion hyn në një bllok.
Kjo zgjidhje funksionon mirë për transfertat konfidenciale, por me transaksione anonime, siç do ta shohim më vonë, krijon probleme serioze.
Mbrojtje kundër sulmeve të përsëritura
Në blockchains të bazuara në llogari, çdo transaksion nënshkruhet nga çelësi privat i dërguesit, i cili bind verifikuesin se transaksioni nuk është modifikuar dhe është krijuar nga pronari i këtij çelësi. Por, çka nëse një sulmues që po dëgjonte kanalin e transmetimit e përgjon këtë mesazh dhe dërgon saktësisht të njëjtin mesazh? Verifikuesi do të verifikojë nënshkrimin e transaksionit dhe do të bindet për autorësinë e tij, dhe rrjeti do të fshijë përsëri të njëjtën shumë nga bilanci i dërguesit.
Ky sulm quhet sulm i përsëritur. Në modelin UTXO, sulme të tilla nuk janë relevante, pasi sulmuesi do të përpiqet të përdorë rezultatet e shpenzuara, të cilat në vetvete nuk janë të vlefshme dhe refuzohen nga rrjeti.
Për të parandaluar që kjo të ndodhë, një fushë me të dhëna të rastësishme ndërtohet në transaksion, e cila quhet nonce ose thjesht "kripë". Kur ridorëzon një transaksion me një kripë, verifikuesi shikon nëse nonce është përdorur më parë dhe, nëse jo, e konsideron transaksionin të vlefshëm. Për të mos ruajtur të gjithë historinë e nonces të përdoruesve në blockchain, zakonisht në transaksionin e parë ai vendoset i barabartë me zero, dhe më pas rritet me një. Rrjeti mund të kontrollojë vetëm nëse mospërputhja e transaksionit të ri ndryshon nga ai i mëparshmi.
Në skemën e transfertave anonime, lind problemi i vërtetimit të nonces të transaksioneve. Ne nuk mund ta lidhim në mënyrë eksplicite nonce-në me adresën e dërguesit, pasi, padyshim, kjo e çanonimizon transferimin. Ne gjithashtu nuk mund të shtojmë një në numrat e të gjitha llogarive pjesëmarrëse, pasi kjo mund të bie ndesh me transfertat e tjera që po përpunohen.
Autorët e Zether propozojnë të gjenerohet nonce në mënyrë kriptografike, në varësi të "epokës". Për shembull:
Këtu x është çelësi sekret i dërguesit, dhe Gepoch — një gjenerator shtesë për epokën, i marrë duke hashuar një varg të formës 'Zether +'. Tani problemi duket se është zgjidhur - ne nuk e zbulojmë noncen e dërguesit dhe nuk ndërhyjmë në mospërfshirjen e pjesëmarrësve të papërfshirë. Por kjo qasje imponon një kufizim serioz: një llogari mund të dërgojë jo më shumë se një transaksion për "epokë". Ky problem, për fat të keq, mbetet i pazgjidhur dhe aktualisht e bën versionin anonim të Zether, për mendimin tonë, vështirë se është i përshtatshëm për përdorim.
Kompleksiteti i provave të njohurive zero
Në UTXO, dërguesi duhet t'i dëshmojë rrjetit se nuk po shpenzon një shumë negative, përndryshe bëhet e mundur të gjenerohen monedha të reja nga ajri (pse është e mundur, kemi shkruar në një nga të mëparshmet ). Dhe gjithashtu nënshkruani "inputet" me një nënshkrim unazë për të vërtetuar se midis monedhave që po përzihen ka fonde që i përkasin atij.
Në versionin anonim të blockchain-it të bazuar në llogari, shprehjet për provë janë shumë më komplekse. Dërguesi vërteton se:
- Shuma e dërguar është pozitive;
- Bilanci mbetet jonegativ;
- Dërguesi ka koduar saktë shumat e transferimit (përfshirë zero);
- Bilanci në bilanc ndryshon vetëm për dërguesin dhe marrësin;
- Dërguesi zotëron çelësin privat të llogarisë së tij dhe ai është në të vërtetë në listën e dërguesve (ndër të përfshirëve);
- Nonce e përdorur në transaksion është kompozuar saktë.
Për një provë kaq komplekse, autorët përdorin një përzierje (një nga autorët, nga rruga, mori pjesë në krijimin e tij) dhe , të cilat quhen plumba Sigma. Prova formale e një deklarate të tillë është një detyrë mjaft e vështirë dhe kufizon në masë të madhe numrin e njerëzve të gatshëm për të zbatuar teknologjinë.
Rezultati?
Sipas mendimit tonë, pjesa e Zether që sjell privatësi në blloqe të bazuara në llogari mund të përdoret që tani. Por për momentin, versioni anonim i teknologjisë imponon kufizime serioze në përdorimin e saj dhe kompleksitetin e tij në zbatimin e saj. Megjithatë, nuk duhet zbritur fakti që autorët e kanë nxjerrë vetëm pak muaj më parë dhe ndoshta dikush tjetër do t'i gjejë një zgjidhje problemeve që ekzistojnë sot. Në fund të fundit, kështu bëhet shkenca.
Burimi: www.habr.com