Oleme juba pikka aega huvitatud anonüümsusest krüptovaluutades ja püüame jälgida selle valdkonna tehnoloogia arengut. Oma artiklites oleme juba põhjalikult käsitlenud toimimisprintsiipide Moneros, samuti oleme teinud sellel alal olemasolevatest tehnoloogiatest. Kuid kõik anonüümsed krüptovaluutad on tänapäeval rajatud andmemudelile, mille pakkus välja Bitcoin — Unspent Transaction Output (edaspidi UTXO). Account-based plokiahelate, nagu Ethereum, olemasolevad lahendused anonüümsuse ja konfidentsiaalsuse rakendamiseks (näiteks või ) on püüdnud UTXO mudelit kordustada nutilepingutes.
2019. aasta veebruaris avaldas Stanfordi ülikooli ja Visa Researchi teadlaste grupp välja andsid «Zether: Koos kõikehõlmava privaatsuse suunas nutilepingute maailmas». Autorid pakkusid esmakordselt lähenemist, kuidas tagada anonüümsus account-based plokiahelates, esitades kaks tüüpi nutilepingut: konfidentsiaalsete (bilansside ja ülekandemäärade varjamine) ja anonüümsete (saaja ja saatja varjamine) tehingute jaoks. Leiame, et pakutud tehnoloogia on huvitav, ja soovime jagada selle toimimist ning arutada, miks anonüümsuse probleem account-based plokiahelates on väga keeruline ning kas autoritel õnnestus see täielikult lahendada.
Nende andmemudelite toimimisest
UTXO mudelis koosneb tehing 'sisenditest' ja 'väljunditest'. Otsene analoog 'väljunditele' on rahatähed teie rahakotis: igal 'väljundil' on mingi nominaal. Kui maksate kellegagi (kujundate tehingu), kulutate ühe või mitu 'väljundit', muutes need tehingu 'sisenditeks', ning plokiahel märgib need kulutatuteks. Samuti saab teie makse saaja (või teie ise, kui vajate vahetust) uue genereeritud 'väljundi'. Skeemiliselt on seda võimalik kujutada nii:
Kontopõhised plokiahelad on korraldatud umbes nagu teie pangakonto. Need opereerivad ainult teie konto summaga ja ülekande summaga. Kui te kandite summat oma kontolt, ei hävita te mingeid 'välju', võrk ei pea meeles, millised mündid on kulutatud ja millised mitte. Lihtsaimal juhul koondub tehingu kontroll saatja allkirja ja tema saldode kontrollimisele:
Tehnoloogia analüüs
Järgnevalt räägime sellest, kuidas Zether varjab tehingute summat, saajat ja saatjat. Kirjeldades selle tööpõhimõtteid, märkime ära erinevused konfidentsiaalse ja anonüümse variandi vahel. Kuna konfidentsiaalsuse tagamine kontopõhistes plokiahelates on oluliselt lihtsam, on mõned anonüümimisega seotud piirangud konfidentsiaalse versiooni jaoks ebaolulised.
Saldo ja ülekande summade varjamine
Saldo ja ülekande summade šifreerimiseks Zetheris kasutatakse šifreerimissüsteemi . See töötab järgmiselt. Kui Alice soovib saata Bobile b münte aadressile (tema avalikule võtmele) Y, valib ta juhusliku arvu r ja šifreerib summa:
kus C — šifreeritud summa, D — abistav väärtus, mis on vajalik selle summa dešifreerimiseks, G — fikseeritud punkt elliptilisel kõveral, millel salajase võtme korrutamisel saadakse avalik võti.
Kui Bob need väärtused saab, liidab ta need lihtsalt enda krüpteeritud tasemele, mis teeb selle skeemi mugavaks.
Sarnasel viisil lahutab Alice oma tasemest samad väärtused, kuid kasutab Y oma avalikku võtit.
Saaja ja saatja varjamine
UTXO-s «väljundite» segamine tekkis juba krüptovaluutade alguses ja aitab varjata saatjat. Selleks valib saatja tehingu sooritamisel juhuslikud «väljundid» plokiahelast ja segab need enda omadega. Seejärel allkirjastab ta «väljundid» ringallkirjaga — krüptograafiline mehhanism, mis lubab kontrollijal veenduda, et segatud «väljundite» seas on saatja münte. Segatud münte, muidugi, ei kasutata.
Siiski ei saa me peitmise eesmärgil genereerida vale „väljundeid”. Seetõttu on igal UTXO „väljundil” ainulaadne aadress, mille krüptograafiline seos on märke saaja aadressiga. Praegu ei ole võimalust tuvastada seost ainulaadse „väljundi” aadressi ja märke saaja aadressi vahel, ilma et oleks teada selle salajasi võti.
Account-based mudelis ei saa me kasutada ühekordseid aadresse (vastasel juhul oleks see juba „väljundite” mudel). Seetõttu tuleb märke saaja ja saatja segada teiste kontodega plokiahelas. Sellisel juhul arvatakse segatud kontodelt maha krüptitud 0 märke (või lisatakse 0 – märke saaja segamisel), muutes nende tegelikku tasakaalu sisuliselt mitte.
Kuna nii saatjal kui ka saajal on alati püsiv aadress, tekib vajadus sama aadressi jaoks ülekannete tegemisel kasutada samu segamisgruppe. Seda on lihtsam selgitada näite abil.
Kujutame ette, et Alice otsustas teha annetuse Bobi heategevusfondile, kuid eelistab, et see ülekandmine jääks välistest vaatlejatega anonüümseks. Seetõttu, et end saatja väljal maskeerida, kirjutab ta lisaks Adam ja Adele konto. Ja et Bobi varjata - lisab ta saaja väljal veel Benji ja Billi kontod. Järgmisel annetusel otsustas Alice enda kõrvale kirjutada Alexi ja Amanda ning Bobi kõrvale - Bruce'i ja Benjami. Sel juhul, kui analüüsida plokiahelat nende kahe tehingu puhul, leitakse vaid üks kattuv osalejate paar - Alice ja Bob, mis deanonüümib need tehingud.
Tehingute võidud
Nagu juba mainisime, varjab kasutaja konto põhjal põhinevates süsteemides oma saldo ja ülekande summa krüpteerimise teel. Sellega peab ta tõestama, et tema konto jääk jääb mittetäielikuks. Probleem seisneb selles, et tehingu loomisel koostab kasutaja tõendi oma konto praeguse oleku kohta. Kuid mis juhtub, kui Bob saadab Alice'ile tehingu ja see aktsepteeritakse enne, kui Alice on oma saatnud? Siis loetakse Alice'i tehing kehtetuks, kuna saldo tõend anti enne Bob'i tehingu vastuvõtmist.
Esimene lahendus, mis sellises olukorras pähe tuleb, on konto külmutamine tehingu läbiviimiseni. Kuid see lähenemine ei sobi, kuna lisaks sellele, et selle ülesande lahendamine jaotatud süsteemis on keeruline, ei oleks anonüümses skeemis selge, kelle kontot blokeerida.
Selle probleemi lahendamiseks jagab tehnoloogia sissetulevad ja väljaminevad tehingud: rahade kulutamine mõjutab koheselt kontojääki, samas kui tulud on viivitusega. Selleks tutvustatakse mõistet „epohh“ — fikseeritud suurusega blokigruppe. Praegune „epohh“ määratakse ploki kõrguse jagamisega grupi suurusega. Tehingut töötledes uuendab võrgustik saatja kontojääki kohe, samas kui saaja vahendid kogutakse talletusse. Kogutud vahendid saavad makse saajale kätte alles uue „epohhi“ saabumisel.
Tulemuseks on see, et kasutaja saab saata tehinguid sõltumata sellest, kui tihti talle vahendeid laekub (ilmselt selle, mida tema saldo võimaldab). Epohhi suurus määratakse selle põhjal, kui kiiresti blokid võrgus levivad 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, tekib tõsiseid probleeme.
Replay-rünnakute kaitse
Account-based plokiahelites on igas tehingus allkirjastab saatja erapärane võti, mis kinnitab kontrollijale, et tehingut ei ole muudetud ja selle on loonud selle võti omanik. Kuid mis juhtub, kui pahatahtlik isik, kes jälgib edastuskanalit, püüab selle sõnumi ja saadab täpselt sama teise? Kontrollija kontrollib tehingu allkirja ja on veendunud selle autorluses, ning võrk kustutab saaja kontolt sama summa uuesti.
Seda rünnakut nimetatakse kordusrünnakuks. UTXO mudelis ei ole sellised rünnakud asjakohased, kuna pahatahtlik isik üritab kasutada kulutatud väljundeid, mis iseenesest ei ole kehtivad ja võrgu poolt tagasi lükatakse.
Kuna sellist olukorda vältida, lisatakse tehingusse juhuslike andmete väli, mida nimetatakse nonce'iks või lihtsalt „soolaks“. Kui tehing saadetakse uuesti koos „soolaga“, kontrollib valideerija, kas seda nonce'i on varem kasutatud ja kui ei, siis peab ta selle tehingu kehtivaks. Et mitte salvestada kogu kasutajate nonce'ide ajalugu plokiahelasse, võetakse tavaliselt esimeses tehingus see nulliks ja suurendatakse seejärel ühe võrra. Võrgule jääb vaid kontrollida, et uue tehingu nonce erineb varasemast ühe võrra.
Anonüümsete ülekannete skeemis tekib nonce'ide tehingute valideerimise probleem. Me ei saa siduda nonce'it otseselt saatja aadressiga, et vältida ülekande deanonüümimist. Samuti ei saa me kõigi osalevate kontode nonce'idele ühte juurde lisada, kuna see võib konfliktida teiste töötlemisel olevate ülekannetega.
Zetheri autorid pakuvad nonce'i genereerimist krüptograafiliselt, sõltuvalt „ajastust“. Näiteks:
Siit x — saatja salajane võti ja Gepoch — täiendav generaator ajastu jaoks, mis saadakse stringi «Zether +» hashiproovimise teel. Nüüd näib probleem olevat lahendatud — me ei paljasta saatja nonce'i ja ei sekkume teiste osaliste nonce'idesse. Kuid selline lähenemine seab tõsised piirangud: üks konto saab saata mitte rohkem kui ühe tehingu «ajastu» jooksul. Kahjuks jääb see probleem lahendamata ja praegu muudab anonüümse Zether'i versiooni kasutamise meie arvates vaevaliseks.
Nulliga paljastamise tõendite keerukus
UTXO-s peab saatja tõendama võrgule, et ta ei kuluta negatiivset summa, vastasel juhul on võimalik genereerida uusi münte õhust (miks see on võimalik, oleme kirjutanud ühes varasemas ). Samuti peab ta allkirjastama «sisendid» ringallkirjaga, et tõendada, et segatud müntide seas on vahendeid, mis kuuluvad talle.
Anonüümse versiooniga konto-põhises plokiahelas on tõendite avaldused palju keerukamad. Saatja tõendab, et:
- Saadetav summa on positiivne;
- Saldo jääb mittetäielikuks;
- Saaja on õigesti krüpteerinud ülekande summad (sealhulgas null);
- Saldo muutub ainult saatjal ja saajal;
- Saatja omab oma konto salajast võtit ja see on tõepoolest saatjate loendis (kaasatud);
- Tehingus kasutatud nonce on õigesti koostatud.
Sellise keerulise tõestuse jaoks kasutavad autorid segu (üks autoritest, muide, osales selle loomisel) ja , mida nimetatakse Sigma-padruniteks. Sellise väite formaalne tõestamine on üsna keeruline ülesanne ja see piirab oluliselt neid, kes soovivad tehnoloogia rakendamisega tegeleda.
Mis on lõpptulemus?
Meie arvates võib Zetheri osa, mis toob privaatsuse account-based plokiahelatesse, olla täiesti kasutatav juba praegu. Kuid hetkel seab anonüümne versioon tehnoloogia kasutusele tõsised piirangud ja selle keerukus - rakendamisele. Kuid ärge alahindage, et autorid avaldasid selle alles paar kuud tagasi ja võib-olla leiab keegi teine lahenduse olemasolevatele probleemidele. Just nii teadust tehakse.
Allikas: habr.com
