Me oleme juba pikka aega huvitatud anonüümsuse teemast krüptovaluutades ja jälgime nende valdkonnas tehnoloogiate arengut. Oma artiklites oleme juba põhjalikult käsitlenud tööpõhimõtteid Moneros, samuti oleme teinud selles valdkonnas olemasolevatest tehnoloogiatest. Siiski kõik anonüümsed krüptovaluutad, mis tänapäeval eksisteerivad, põhinevad Bitcoiniga pakutud andmemudelil - Unspent Transaction Output (edaspidi UTXO). Account-based plokiahelate, nagu Ethereum, jaoks on olemasolevad lahendused anonüümsuse ja konfidentsiaalsuse tagamiseks (näiteks või ) püüdnud UTXO mudelit ümber teha nutilepingutes.
2019. aasta veebruaris esitas Stanfordi ülikooli ja Visa Researchi teadlaste rühm arendajad muusikateenusest Spotify. Muudetud Spotify Lite näeb välja nagu täisversioon, kuid on ilma paljusid seadeid ja ei luba salvestada lugusid kuulamiseks ilma internetiühenduseta. «Zether: Privaatluse suunas nutilepingute maailmas». Autorid tutvustasid esmakordselt lähenemist anonüümsuse tagamiseks account-based plokiahelates ja esitlesid kahte nutilepingute varianti: konfidentsiaalseid (bilansside ja ülekande summade varjamine) ja anonüümseid (saaja ja saatja varjamine) tehingute jaoks. Me leiame, et pakutud tehnoloogia on huvitav ja soovime jagada selle ülesehitust ning arutada, miks anonüümsuse probleem account-based plokiahelates on väga keeruline ja kas autorid on seda täielikult lahendada suutnud.
Nende andmemudelite ülesehitusest
UTXO mudelis koosneb tehing „sisenditest” ja „väljunditest”. Otsene analoog „väljundite” — rahad teie rahakotis: igal „väljundil” on mingi nominaal. Kui te kellelegi maksate (moodustate tehingu), siis kulutate ühe või mitu „väljundit”, samal ajal kui need muutuvad tehingu „sisenditeks” ja plokiahel märgib need kui kulutatud. Samal ajal saab teie makse saaja (või teie ise, kui vajate tagasimakset) uuesti genereeritud „väljundeid”. Skeemiliselt võib seda kujutada nii:
Account-based plokiahelad on üles ehitatud umbes nagu teie pangakonto. Need opereerivad ainult teie konto summaga ja ülekande summaga. Kui te kannate oma kontolt mõne summa, siis ei põleta te mingeid „väljundeid”, võrgu ei pea meeles pidama, millised mündid on kulutatud ja millised mitte. Kõige lihtsamal juhul piirdub tehingu kontrollimine saatja allkirja ja tema bilansi summaga:
Tehnoloogia analüüs
Jätkame rääkides sellest, kuidas Zether varjab tehingu summat, saajat ja saatjat. Kirjelduse käigus märkime erinevusi konfidentsiaalse ja anonüümse versiooni vahel. Kuna konfidentsiaalsuse tagamine account-based plokiahelates on palju lihtsam, on mõned anonüümsuse piirangud konfidentsiaalse versiooni tehnoloogia jaoks ebaolulised.
Bilansside ja ülekande summa peitmine
Zetheris bilansside ja ülekande summade krüpteerimiseks kasutatakse krüpteerimise skeemi . See töötab järgmiselt. Kui Alice soovib Bobile saata b münte aadressile (tema avalikule võtmele) Y, valib ta juhusliku arvu r ja krüpteerib summa:
kus C — krüpteeritud summa, D — abiväärtus, mis on vajalik selle summa dekodeerimiseks, G — kindel punkt eliptilisel kõveral, millele salajase võti korrutamisel saadakse avalik võti.
Kui Bob need väärtused saab, liidab ta need lihtsalt oma sama moodi krüpteeritud balansile, mis muudab selle skeemi mugavaks.
Samamoodi lahutab Alice oma balansist samasuguseid väärtusi, kasutades selleks Y oma avalikku võtit.
Saaja ja saatja peitmine
UTXO 'väljade' segamine tekkis veel krüptovaluutade algusaegadel ja aitab peita saatjat. Selleks valib saatja ülekande tegemisel juhuslikud 'väljundid' plokiahelast ja segab need enda omadega. Seejärel allkirjastab ta 'väljad' ringallkirjaga – krüptograafiline mehhanism, mis võimaldab kontrollijal veenduda, et segatud 'väljade' seas on saatja münte. Segatud münte ei kasutata, muidugi.
Kuid saaja peitmiseks ei suuda me genereerida vale 'väljundeid'. Seetõttu on igal UTXO 'väljundil' oma ainulaadne aadress, ja see on krüptograafiliselt seotud nende müntide saaja aadressiga. Praegu ei ole võimalik tuvastada seost ainulaadse 'väljundi' aadressi ja müntide saaja aadressi vahel, teadmata tema salajasi võtmeid.
Account-based mudelites ei saa me kasutada ühekordseid aadresse (vastasel juhul oleks see juba 'väljundite' mudel). Seetõttu tuleb saajat ja saatjat segada teiste kontode seas plokiahelas. Sellisel juhul eemaldatakse segatud kontodelt krüpteeritud 0 münti (või lisatakse 0 — saaja segamise korral), muutes nende tegelikku saldo tegelikult mitte.
Kuna nii saatjal kui ka saajal on alati pidev aadress, on siin vajadus kasutada sama segamisrühma, kui tehingud tehakse samadele aadressidele. Seda on lihtsam illustrida näite abil.
Oletame, et Alice otsustas teha annetuse Bob'i heategevusfondi, kuid eelistab, et see ülekande jääks kolmandate osapoolte jaoks anonüümseks. Seetõttu, et varjata oma saatja positsiooni, lisab ta ka Adam ja Adele kontod. Ja et Bob'i varjata — saaja väljale lisab veel Ben ja Bill kontod. Tehes järgmise annetuse, otsustas Alice kirjutada enda kõrvale Alexi ja Amanda, ja Bob'i kõrvale Bruce ja Benjari. Sel juhul analüüsides plokiahelat leiad neist kahest tehingust vaid ühe ühtuva osalejate paari — Alice ja Bob, mis de-anonüümib need tehingud.
Tehingute jälitamised
Nagu juba mainitud, varjab kasutaja oma saldo ja ülekande summa account-based süsteemides. Selleks peab ta tõestama, et tema kontol olev jääk jääb mitte-negatiivseks. Probleem seisneb selles, et tehingu loomisel koostab kasutaja tõendi oma konto praeguse seisundi kohta. Mis juhtub, kui Bob saadab Alicele tehingu, ja see aktsepteeritakse enne, kui Alice oma saatis? Siis loetakse Alice'i tehing kehtetuks, kuna saldo tõend koostati enne Bob'i tehingu aktsepteerimist.
Esimene lahendus, mis sellises olukorras pähe tuleb — külmutada konto tehingu tegemise ajaks. Kuid see lähenemine ei sobi, kuna lisaks sellele, et sellise ülesande lahendamine jaotatud süsteemis on keeruline, ei ole anonüümses skeemis selge, mille konto blokeerida.
Selle probleemi lahendamiseks tehnoloogia eraldab sissetulevad ja väljaminevad tehingud: vahendite kasutamine mõjub koheselt saldole, samas kui tulu - viivitusega. Selle jaoks tuuakse sisse kontseptsioon "ajastu" - fikseeritud suurusega plokkide grupp. Praegune "ajastu" määratakse ploki kõrguse jagamisega grupi suurusega. Tehingut töötledes ajakohastab võrgustik saadetaja saldo kohe, samas kui saaja vahendid kogutakse. Kogutud vahendid lähevad saaja käsutusse alles uue "ajastu" saabumisel.
Tulemuseks võib kasutaja saata tehinguid sõltumata sellest, kui sageli talle vahendeid laekub (muidugi sõltuvalt tema saldost). Ajastu suurust määratakse, lähtudes sellest, kui kiiresti plokid levivad võrgus ja kui kiiresti tehing jõuab plokki.
See lahendus töötab hästi konfidentsiaalsete ülekannete puhul, kuid anonüümsete tehingutega, nagu me hiljem näeme, tekitab see tõsiseid probleeme.
Replay-rünnakute kaitse
Account-based plokiahelates allkirjastatakse iga tehing saatja privaatvõtmega, mis veenab kontrollijat, et tehingut ei ole muudetud ja selle on loonud selle võtme omanik. Kuid mis siis, kui ründaja, kes kuulab edastuskanalit, püüab selle sõnumi kinni ja saadab täpselt samamoodi teise? Kontrollija kontrollib tehingu allkirja ja on veendunud selle autentsuses, ning võrgustik võtab saatja kontolt sama summa taas.
Seda rünnakut nimetatakse replay-rünnakuks. UTXO mudelis ei ole sellised rünnakud asjakohased, kuna ründaja püüab kasutada kulutatud sisendeid, mis iseenesest ei ole kehtivad ja võrgus lükatakse tagasi.
Selleks, et seda ei juhtuks, sisestatakse tehingusse juhuslike andmete väli, mida nimetatakse nonce'iks või lihtsalt "soolaks". Tehingu uuesti saatmisel nonce'i kontrollib kontrollija, kas see on varem kasutatud, ja kui ei, siis peab ta seda tehingut kehtivaks. Et mitte hoida plokiahelas kõiki kasutajate nonce'ide ajalugu, võetakse tavaliselt esimeses tehingus selleks null, ja seejärel suurendatakse seda ühe võrra. Võrgustik peab vaid kontrollima, et uue tehingu nonce erineb eelmise omast ühe võrra.
Anonüümsete ülekannete skeemides tekib nonce'ide valideerimise probleem. Me ei saa siduda nonce'it selgelt saatja aadressiga, kuna see deanonüümib ülekande. Samuti ei saa me kõigi osalejate konto nonce'idele ühte plussida, kuna see võib konfliktida teiste töötlevate ülekannetega.
Zetheri autorid soovitavad genereerida nonce krüptograafiliselt — sõltuvalt „ajast”. Näiteks:
Siin x — saatja salajane võti ja Gepoch — täiendav generaator ajastu jaoks, mis saadakse sellise stringi hash'imise teel, nagu 'Zether + '. Nüüd paistab probleem olevat lahendatud — me ei avalikusta saatja nonce'it ja ei sekku osalematute osalejate nonce'idesse. Kuid selline lähenemine seab tõsiseid piiranguid: üks konto ei saa saata rohkem kui ühte ülekannet „ajastu” jooksul. See probleem jääb kahjuks lahendamata ja hetkel muudab meie arvates Zetheri anonüümse versiooni kasutamiseks peaaegu sobimatuks.
Nullilähedaste tõendite keerukus
UTXO puhul peab saatja tõendama võrgule, et ta ei kuluta negatiivset summat, vastasel juhul on võimalik genereerida uusi münte õhust (miks see võimalik on, oleme kirjutanud ühes eelnevas ). Samuti peab ta allkirjastama „sisendid” ringallkirjaga, et tõendada, et segatavate müntide seas on ka tema omatud vahendid.
Anonüümse versiooni puhul account-based plokiahelas on tõendite koostamine palju keerulisem. Saatja peab tõendama, et:
- Saatmise summa on positiivne;
- Saldo jääb mitte-negatiivseks;
- Saatja on õigesti salvestanud ülekannete summad (sealhulgas nullid);
- Saldo muutub ainult saatja ja saaja puhul;
- Saatja omab oma konto salajast võtit ja ta on tõepoolest saatjate nimekirjas (segatute seas);
- Transaktsioonis kasutatud nonce on koostatud õigesti.
Selle keerulise tõendi jaoks kasutavad autorid segu (üks autoritest, muide, osales selle loomisel) ja , mida nimetatakse Sigma-bullets'iks. Sellise väite formaalne tõendamine on üsna keeruline ülesanne ja see piirab oluliselt neid, kes soovivad tehnoloogia rakendamisega tegeleda.
Kokkuvõttes?
Meie arvates võib Zetheri osa, mis toob privaatsuse account-based plokiahelatesse, juba praegu kasutada. Kuid praegu seab anonüümne versioon tehnoloogiale tõsised piirangud selle kasutamisel, ning selle keerukus - elluviimisel. Siiski ei tasu unustada, et autorid lansseerisid selle vaid mõned kuud tagasi, ja võib-olla leiab keegi teine lahenduse tänastele probleemidele. Just nii toimub teadus.
Allikas: habr.com
