Nastavljamo našu seriju o Monero blockchainu, a današnji članak će se fokusirati na RingCT (Ring Confidential Transactions) protokol, koji uvodi povjerljive transakcije i nove prstenaste potpise. Nažalost, na internetu postoji malo informacija o tome kako to funkcionira, a mi smo pokušali popuniti ovu prazninu.
Govorit ćemo o tome kako mreža skriva iznose prijenosa koristeći ovaj protokol, zašto su napustili klasične cryptonote prstenaste potpise i kako će se ova tehnologija dalje razvijati.
Budući da je ovaj protokol jedna od najsloženijih tehnologija u Moneru, čitatelju će biti potrebno osnovno znanje o dizajnu ovog blockchaina i prolazno znanje o kriptografiji eliptičke krivulje (da biste nadopunili ovo znanje, možete pročitati prva poglavlja našeg prethodni članak o
RingCT protokol
Jedan od mogućih napada na cryptonote valute je blockchain analiza zasnovana na znanju o količini i vremenu poslane transakcije. Ovo dozvoljava
Vrijedi napomenuti da ideja skrivanja iznosa nije nova. Bitcoin Core programer Greg Maxwell bio je jedan od prvih koji je to opisao u svom
Između ostalog, protokol pomaže da se riješite problema s miješanjem izlaza prašine - izlaza male količine (obično primljenih u obliku promjene iz transakcija), koji su stvorili više problema nego što su vrijedili.
U januaru 2017. dogodio se hard fork mreže Monero, koji je omogućio opcionu upotrebu povjerljivih transakcija. I već u septembru iste godine, sa hard forkom verzije 6, takve transakcije su postale jedine dozvoljene na mreži.
RingCT koristi nekoliko mehanizama odjednom: višeslojne povezane spontane anonimne grupne potpise (višeslojni povezivi spontani anonimni grupni potpis, u daljem tekstu MLSAG), šemu obaveze (Pedersenove obaveze) i dokaze opsega (ovaj termin nema utvrđeni prijevod na ruski) .
RingCT protokol uvodi dvije vrste anonimnih transakcija: jednostavne i pune. Novčanik generiše prvi kada transakcija koristi više od jednog unosa, drugi - u suprotnoj situaciji. Razlikuju se u validaciji iznosa transakcija i podataka potpisanih MLSAG potpisom (o tome ćemo više govoriti u nastavku). Štaviše, transakcije tipa full mogu se generisati sa bilo kojim brojem ulaza, nema fundamentalne razlike. U knjizi
Potpis MLSAG-a
Prisjetimo se šta su to potpisani unos transakcije. Svaka transakcija troši i generiše određena sredstva. Generiranje sredstava se događa kreiranjem izlaza transakcije (direktna analogija su računi), a izlaz koji transakcija potroši (na kraju krajeva, u stvarnom životu trošimo novčanice) postaje ulaz (pazite, vrlo se lako možete zbuniti ovdje).
Ulaz se poziva na više izlaza, ali troši samo jedan, stvarajući tako „dimnu zavjesu“ koja otežava analizu povijesti prijevoda. Ako transakcija ima više od jednog ulaza, onda se takva struktura može predstaviti kao matrica, gdje su redovi ulazi, a stupci mješoviti izlazi. Da bi se dokazalo mreži da transakcija troši tačno svoje izlaze (zna njihove tajne ključeve), ulazi se potpisuju prstenastim potpisom. Takav potpis garantuje da je potpisnik znao tajne ključeve za sve elemente bilo koje kolone.
Povjerljive transakcije više ne koriste klasične
Zovu se višeslojni jer potpisuju nekoliko ulaza odjednom, od kojih je svaki pomiješan s nekoliko drugih, odnosno potpisuje se matrica, a ne jedan red. Kao što ćemo kasnije vidjeti, ovo pomaže u uštedi na veličini potpisa.
Pogledajmo kako se formira prstenasti potpis, koristeći primjer transakcije koja troši 2 stvarna izlaza i koristi m - 1 slučajnih iz blockchaina za miješanje. Označimo javne ključeve izlaza koje trošimo
, i ključne slike za njih u skladu s tim: Tako dobijamo matricu veličine 2 x m. Prvo, moramo izračunati takozvane izazove za svaki par izlaza:
Počinjemo kalkulacije sa izlazima koje trošimo koristeći njihove javne ključeve:i nasumične brojeveKao rezultat, dobijamo sljedeće vrijednosti:
, koji koristimo za izračunavanje izazova
sljedeći par izlaza (da bismo lakše razumjeli šta gdje zamjenjujemo, ove vrijednosti smo istakli različitim bojama). Sve sljedeće vrijednosti izračunate su u krugu koristeći formule date na prvoj slici. Posljednja stvar koju treba izračunati je izazov za par stvarnih izlaza.
Kao što vidimo, sve kolone osim one koja sadrži stvarne izlaze koriste nasumično generirane brojeve. za π- kolona će nam takođe trebati. Hajde da se transformišemou s:
Sam potpis je skup svih ovih vrijednosti:
Ovi podaci se zatim upisuju u transakciju.
Kao što vidimo, MLSAG sadrži samo jedan izazov c0, što vam omogućava da uštedite na veličini potpisa (koja već zahtijeva puno prostora). Dalje, bilo koji inspektor, koristeći podatke, vraća vrijednosti c1,…, cm i to provjerava. Dakle, naš prsten je zatvoren i potpis je ovjeren.
Za RingCT transakcije punog tipa, u matricu se dodaje još jedan red s mješovitim izlazima, ali o tome ćemo govoriti u nastavku.
Pedersen Commitments
Monero obaveze se koriste za skrivanje iznosa transfera i koriste se najčešća opcija - Pedersen obaveze. Usput, zanimljiva činjenica - programeri su prvo predlagali skrivanje iznosa običnim miješanjem, odnosno dodavanjem izlaza za proizvoljne količine kako bi unijeli neizvjesnost, ali su onda prešli na obaveze (nije činjenica da su štedjeli na veličina transakcije, kao što ćemo vidjeti u nastavku).
Generalno, obaveza izgleda ovako:
Gde C — značenje same obaveze, a - skriveni iznos, H je fiksna tačka na eliptičkoj krivulji (dodatni generator), i x — neka vrsta proizvoljne maske, faktor skrivanja generiran nasumično. Maska je ovdje potrebna tako da treća strana ne može jednostavno pogoditi vrijednost predanosti.
Kada se generiše novi izlaz, novčanik izračunava obavezu za njega, a kada se potroši, uzima ili vrednost izračunatu tokom generisanja ili je ponovo izračunava, u zavisnosti od vrste transakcije.
RingCT jednostavan
U slučaju jednostavnih RingCT transakcija, kako bi se osiguralo da je transakcija stvorila izlaze u iznosu jednakom iznosu inputa (nije proizvela novac iz zraka), potrebno je da zbir obaveza prvog i drugog biti isti, tj.
Komisije za obaveze to smatraju malo drugačije - bez maske:
gde a — iznos provizije, javno je dostupan.
Ovaj pristup nam omogućava da dokažemo pouzdanoj strani da koristimo iste iznose bez da ih otkrivamo.
Da stvari budu jasnije, pogledajmo primjer. Recimo da transakcija troši dva izlaza (što znači da oni postaju inputi) od 10 i 5 XMR i generiše tri izlaza vrijedna 12 XMR: 3, 4 i 5 XMR. Istovremeno plaća proviziju od 3 XMR. Dakle, iznos potrošenog novca plus generirani iznos i provizija je jednak 15 XMR. Pokušajmo izračunati obaveze i pogledati razliku u njihovim iznosima (sjetite se matematike):
Ovdje vidimo da nam je potrebno da zbroji ulazne i izlazne maske budu isti da bi jednačina konvergirala. Da biste to učinili, novčanik generiše nasumično x1, y1, y2 i y3, i preostali x2 izračunava ovako:
Koristeći ove maske, možemo dokazati bilo kojem verifikatoru da ne generišemo više sredstava nego što trošimo, bez otkrivanja iznosa. Original, zar ne?
RingCT pun
U potpunim RingCT transakcijama, provjera iznosa transfera je malo složenija. U ovim transakcijama, novčanik ne preračunava obaveze za ulaze, već koristi one izračunate kada su generisane. U ovom slučaju, moramo pretpostaviti da više nećemo dobiti razliku u zbrojima jednaku nuli, već:
to je z — razlika između ulaznih i izlaznih maski. Ako uzmemo u obzir zG kao javni ključ (što de facto i jeste). z je privatni ključ. Dakle, znamo javne i odgovarajuće privatne ključeve. Sa ovim podacima u ruci, možemo ih koristiti u MLSAG prstenastom potpisu zajedno s javnim ključevima izlaza koji se miješaju:
Dakle, važeći prstenasti potpis će osigurati da znamo sve privatne ključeve jedne od kolona, a privatni ključ u posljednjem redu možemo znati samo ako transakcija ne generiše više sredstava nego što troši. Usput, evo odgovora na pitanje "zašto razlika u iznosima obaveza ne dovede do nule" - ako zG = 0, tada ćemo kolonu proširiti stvarnim izlazima.
Kako primalac sredstava zna koliko mu je novca poslato? Ovdje je sve jednostavno - pošiljalac transakcije i primalac razmjenjuju ključeve koristeći Diffie-Hellman protokol, koristeći transakcijski ključ i primaočev ključ za pregled i izračunavaju zajedničku tajnu. Pošiljalac upisuje podatke o izlaznim iznosima, šifrovane ovim zajedničkim ključem, u posebna polja transakcije.
Dokaz dometa
Šta se dešava ako koristite negativan broj kao iznos u obavezama? To može dovesti do stvaranja dodatnih novčića! Ovakav ishod je neprihvatljiv, pa moramo garantirati da iznosi koje koristimo nisu negativni (naravno, bez otkrivanja ovih iznosa, inače ima toliko posla i sve uzalud). Drugim riječima, moramo dokazati da je zbir u intervalu [0, 2n - 1].
Da bi se to postiglo, zbir svakog izlaza se dijeli na binarne znamenke i obaveza se izračunava za svaku cifru posebno. Bolje je vidjeti kako se to događa na primjeru.
Pretpostavimo da su naši iznosi mali i uklapaju se u 4 bita (u praksi je to 64 bita) i kreiramo izlaz vrijedan 5 XMR. Izračunavamo obaveze za svaku kategoriju i ukupnu obavezu za ceo iznos:
Zatim, svaka obaveza je pomiješana sa surogat (Ci-2iH) i potpisan je u paru s Boromeovim prstenastim potpisom (još jedan prstenasti potpis), koji je predložio Greg Maxwell 2015. (više o tome možete pročitati
Uzeto zajedno, ovo se zove dokaz raspona i omogućava vam da osigurate da obaveze koriste iznose u rasponu [0, 2n - 1].
Što je sljedeće?
U trenutnoj implementaciji, dokazi opsega zauzimaju puno prostora - 6176 bajtova po izlazu. To dovodi do većih transakcija, a time i do viših naknada. Da bi smanjili veličinu Monero transakcije, programeri uvode otpornost na metke umjesto Borromeo potpisa - mehanizam za dokaz opsega bez bitnih obaveza.
Postavite svoja pitanja, predložite teme za nove članke o tehnologijama u području kriptovaluta, a također se pretplatite na našu grupu u
izvor: www.habr.com