Nadaljujemo našo serijo o verigi blokov Monero in današnji članek se bo osredotočil na protokol RingCT (Ring Confidential Transactions), ki uvaja zaupne transakcije in nove podpise obročev. Na žalost je na internetu malo informacij o tem, kako deluje, in poskušali smo zapolniti to vrzel.
Govorili bomo o tem, kako omrežje prikriva zneske nakazil s tem protokolom, zakaj so opustili klasične obročne podpise cryptonote in kako se bo ta tehnologija razvijala naprej.
Ker je ta protokol ena najbolj zapletenih tehnologij v Monero, bo bralec potreboval osnovno znanje o zasnovi te verige blokov in prehodno znanje o kriptografiji eliptične krivulje (če želite obnoviti to znanje, lahko preberete prva poglavja našega prejšnji članek o ).
protokol RingCT
Eden od možnih napadov na valute cryptonote je blockchain analiza, ki temelji na poznavanju zneska in časa poslane transakcije. To omogoča znatno zoži območje iskanja izhodov, ki so zanimivi za napadalca. Za zaščito pred tovrstnimi analizami je Monero implementiral anonimni transakcijski protokol, ki popolnoma skrije zneske prenosov v omrežju.
Omeniti velja, da ideja o skrivanju zneskov ni nova. Razvijalec Bitcoin Core Greg Maxwell je bil eden prvih, ki ga je opisal v svoji . Trenutna izvedba RingCT je njegova modifikacija z možnostjo uporabe obročnih podpisov (bodisi brez njih), po čemer je tudi dobil ime - Ring Confidential Transactions.
Protokol med drugim pomaga odpraviti težave z mešanjem prašnih izhodov - izhodov majhne količine (običajno prejetih v obliki drobiža iz transakcij), ki so ustvarile več težav, kot so bile vredne.
Januarja 2017 je prišlo do hard forka omrežja Monero, ki je omogočilo neobvezno uporabo zaupnih transakcij. In že septembra istega leta so z različico 6 hard fork takšne transakcije postale edine dovoljene v omrežju.
RingCT uporablja več mehanizmov hkrati: večplastno povezane spontane anonimne skupinske podpise (Multilayered Linkable Spontaneous Anonymous Group Signature, v nadaljevanju MLSAG), shemo zaveze (Pedersen Commitments) in dokazila obsega (ta izraz nima uveljavljenega prevoda v ruščino) .
Protokol RingCT uvaja dve vrsti anonimnih transakcij: preprosto in polno. Denarnica ustvari prvo, ko transakcija uporablja več kot en vnos, drugo - v nasprotni situaciji. Razlikujejo se po validaciji zneskov transakcij in podatkov, podpisanih s podpisom MLSAG (o tem bomo več govorili v nadaljevanju). Poleg tega se lahko transakcije tipa full ustvarijo s poljubnim številom vnosov, ni bistvene razlike. V knjigi V zvezi s tem je rečeno, da je bila odločitev o omejitvi vseh transakcij na en vnos sprejeta v naglici in se lahko v prihodnosti spremeni.
Podpis MLSAG
Spomnimo se, kaj so podpisani vnosi transakcij. Vsaka transakcija porabi in ustvari nekaj sredstev. Generiranje sredstev se zgodi z ustvarjanjem transakcijskih izhodov (neposredna analogija so računi), in izhod, ki ga transakcija porabi (navsezadnje v resničnem življenju porabimo bankovce), postane vhod (bodite previdni, zelo lahko se zmedete tukaj).
Vnos se sklicuje na več izhodov, vendar porabi samo enega, s čimer ustvari "dimno zaveso", ki otežuje analizo zgodovine prevodov. Če ima transakcija več kot en vhod, potem lahko takšno strukturo predstavimo kot matriko, kjer so vrstice vhodi, stolpci pa mešani izhodi. Da bi omrežju dokazali, da transakcija porabi točno svoje izhode (pozna njihove skrivne ključe), so vhodi podpisani s podpisom obroča. Takšen podpis zagotavlja, da je podpisnik poznal skrivne ključe za vse elemente katerega koli od stolpcev.
Zaupni posli ne uporabljajo več klasičnih obročnih podpisov, jih je zamenjal MLSAG - različica podobnih enoslojnih obročnih podpisov, prilagojenih za več vnosov, .
Imenujejo se večplastni, ker podpišejo več vhodov hkrati, od katerih je vsak pomešan z več drugimi, tj. Podpisana je matrika in ne ena vrstica. Kot bomo videli kasneje, to pomaga prihraniti pri velikosti podpisa.
Poglejmo, kako se oblikuje obročni podpis na primeru transakcije, ki porabi 2 realna izhoda in za mešanje uporabi m - 1 naključnih iz verige blokov. Označimo javne ključe izhodov, ki jih porabimo kot
in ustrezne ključne slike zanje: Tako dobimo matriko velikosti 2 x m. Najprej moramo izračunati tako imenovane izzive za vsak par rezultatov:
Izračune začnemo z izhodi, ki jih porabimo z njihovimi javnimi ključi:in naključna številaKot rezultat dobimo naslednje vrednosti:
, ki ga uporabljamo za izračun izziva
naslednji par izhodov (da bi lažje razumeli, kaj kje nadomeščamo, smo te vrednosti označili z različnimi barvami). Vse naslednje vrednosti so izračunane v krogu z uporabo formul, navedenih na prvi ilustraciji. Zadnja stvar, ki jo je treba izračunati, je izziv za par dejanskih rezultatov.
Kot lahko vidimo, vsi stolpci razen tistega, ki vsebuje dejanske rezultate, uporabljajo naključno ustvarjena števila. Če želite π- stolpec jih bomo tudi potrebovali. Preobrazimo sev s:
Sam podpis je niz vseh teh vrednosti:
Ti podatki se nato zapišejo v transakcijo.
Kot lahko vidimo, MLSAG vsebuje le en izziv c0, ki vam omogoča prihranek pri velikosti podpisa (ki že tako zahteva veliko prostora). Nadalje, vsak inšpektor, ki uporablja podatke, obnovi vrednosti c1,…, cm in to preveri. Tako je naš obroč sklenjen in podpis verificiran.
Za transakcije polnega tipa RingCT se v matriko doda še ena vrstica z mešanimi izhodi, vendar bomo o tem govorili spodaj.
Pedersenove zaveze
(pogosteje se uporablja angleški izraz commitments) se uporabljajo zato, da lahko ena stranka dokaže, da pozna določeno skrivnost (številko), ne da bi jo dejansko razkrila. Na primer, vržete določeno število na kocki, razmislite o zavezi in jo posredujete stranki, ki preveri. Tako preveritelj v trenutku razkritja tajne številke samostojno izračuna zavezo in se tako prepriča, da ga niste prevarali.
Obveznosti Monero se uporabljajo za skrivanje zneskov nakazil in uporabljajo najpogostejšo možnost - zaveze Pedersen. Mimogrede, zanimivo dejstvo - sprva so razvijalci predlagali skrivanje zneskov z navadnim mešanjem, to je dodajanje izhodov za poljubne količine, da bi vnesli negotovost, potem pa so prešli na zaveze (ni dejstvo, da so prihranili velikost transakcije, kot bomo videli spodaj).
Na splošno je zaveza videti takole:
kjer je C — pomen same zaveze, a - skriti znesek, H je fiksna točka na eliptični krivulji (dodatni generator) in x — nekakšna poljubna maska, naključno ustvarjen skrivalni faktor. Maska je tukaj potrebna, da tretja oseba ne more preprosto uganiti vrednosti zaveze.
Ko je ustvarjen nov izhod, denarnica izračuna zavezo zanj, in ko je porabljena, vzame vrednost, izračunano med ustvarjanjem, ali jo ponovno izračuna, odvisno od vrste transakcije.
RingCT preprosto
V primeru preprostih transakcij RingCT, da bi zagotovili, da je transakcija ustvarila izhode, ki so enaki količini vložkov (ne proizvedla denarja iz nič), je potrebno, da je vsota zavez prvega in drugega enako, torej:
Obvezne komisije obravnavajo malo drugače – brez maske:
Če a — znesek provizije, je javno dostopen.
Ta pristop nam omogoča, da stranki, ki se zanaša, dokažemo, da uporabljamo enake zneske, ne da bi jih razkrili.
Da bo stvar jasnejša, si poglejmo primer. Recimo, da transakcija porabi dva izhoda (kar pomeni, da postaneta vhoda) 10 in 5 XMR in ustvari tri izhode v vrednosti 12 XMR: 3, 4 in 5 XMR. Hkrati plača provizijo 3 XMR. Tako je znesek porabljenega denarja plus ustvarjeni znesek in provizija enak 15 XMR. Poskusimo izračunati obveznosti in poglejmo razliko v njihovih zneskih (spomnite se matematike):
Tukaj vidimo, da za konvergacijo enačbe potrebujemo, da sta vsoti vhodnih in izhodnih mask enaki. Da bi to naredili, denarnica ustvari naključno x1, y1, y2 in y3, in preostali x2 računa takole:
S temi maskami lahko vsakemu preveritelju dokažemo, da ne ustvarimo več sredstev, kot jih porabimo, ne da bi razkrili znesek. Izvirno, kajne?
RingCT poln
Pri polnih transakcijah RingCT je preverjanje zneskov prenosa nekoliko bolj zapleteno. Pri teh transakcijah denarnica ne preračunava obveznosti za vložke, ampak uporablja tiste, ki so bile izračunane, ko so bile ustvarjene. V tem primeru moramo predpostaviti, da ne bomo več dobili razlike v vsotah enake nič, temveč:
Tukaj z — razlika med vhodno in izhodno masko. Če upoštevamo zG kot javni ključ (kar de facto tudi je), torej z je zasebni ključ. Tako poznamo javne in ustrezne zasebne ključe. S temi podatki v roki jih lahko uporabimo v obročnem podpisu MLSAG skupaj z javnimi ključi izhodov, ki se mešajo:
Tako bo veljaven obročni podpis zagotovil, da poznamo vse zasebne ključe enega od stolpcev, zasebni ključ v zadnji vrstici pa lahko poznamo le, če transakcija ne ustvari več sredstev, kot jih porabi. Mimogrede, tukaj je odgovor na vprašanje "zakaj razlika v zneskih obveznosti ne vodi do ničle" - če zG = 0, potem bomo razširili stolpec z dejanskimi rezultati.
Kako prejemnik sredstev ve, koliko denarja mu je bilo poslano? Tukaj je vse preprosto - pošiljatelj transakcije in prejemnik izmenjata ključa s protokolom Diffie-Hellman, z uporabo transakcijskega ključa in ključa pogleda prejemnika ter izračunata skupno skrivnost. Podatke o izhodnih zneskih, šifrirane s tem deljenim ključem, pošiljatelj zapiše v posebna polja transakcije.
Dokazila obsega
Kaj se zgodi, če kot znesek v obveznostih uporabite negativno število? To lahko povzroči ustvarjanje dodatnih kovancev! Takšen izid je nesprejemljiv, zato moramo zagotoviti, da zneski, ki jih uporabljamo, niso negativni (seveda brez razkritja teh zneskov, sicer je dela toliko in vse zaman). Z drugimi besedami, dokazati moramo, da je vsota v intervalu [0, 2n - 1].
Da bi to naredili, se vsota vsakega izhoda razdeli na binarne števke in zaveza se izračuna za vsako števko posebej. Bolje je videti, kako se to zgodi s primerom.
Predpostavimo, da so naše količine majhne in se prilegajo 4 bitom (v praksi je to 64 bitov), in ustvarimo izhod v vrednosti 5 XMR. Izračunamo obveznosti za vsako kategorijo in skupno obveznost za celoten znesek:
Nato se vsaka zaveza pomeša z nadomestkom (Ci-2iH) in je podpisan v paru z Boromejevim prstanskim podpisom (drugim prstanskim podpisom), ki ga je leta 2015 predlagal Greg Maxwell (več o tem lahko preberete ):
Skupaj se to imenuje dokazovanje obsega in vam omogoča, da zagotovite, da zaveze uporabljajo zneske v obsegu [0, 2n - 1].
Kaj sledi?
V trenutni izvedbi dokazi obsega zavzamejo veliko prostora - 6176 bajtov na izhod. To vodi do večjih transakcij in s tem višjih provizij. Da bi zmanjšali velikost transakcije Monero, razvijalci uvajajo bulletproofs namesto podpisov Borromeo – mehanizem za dokazovanje obsega brez bitnih zavez. , lahko zmanjšajo velikost dokazila dosega do 94 %. Mimogrede, sredi julija je tehnologija minila podjetja Kudelski Security, ki ni razkrilo bistvenih pomanjkljivosti ne v sami tehnologiji ne v njeni izvedbi. Tehnologija se že uporablja v testnem omrežju, z novim hard forkom pa se verjetno lahko premakne v glavno omrežje.
Postavite svoja vprašanja, predlagajte teme za nove članke o tehnologijah na področju kriptovalut in se tudi naročite na našo skupino v da boste na tekočem z našimi dogodki in publikacijami.
Vir: www.habr.com