Vi fortsetter serien vår om Monero-blokkjeden, og dagens artikkel vil fokusere på RingCT (Ring Confidential Transactions)-protokollen, som introduserer konfidensielle transaksjoner og nye ringsignaturer. Dessverre er det lite informasjon på Internett om hvordan det fungerer, og vi prøvde å fylle dette gapet.
Vi vil snakke om hvordan nettverket skjuler overføringsbeløp ved hjelp av denne protokollen, hvorfor de forlot de klassiske kryptonote-ringsignaturene, og hvordan denne teknologien vil utvikle seg videre.
Siden denne protokollen er en av de mest komplekse teknologiene i Monero, vil leseren trenge en grunnleggende kunnskap om utformingen av denne blokkjeden og en bestått kunnskap om elliptisk kurvekryptografi (for å friske opp denne kunnskapen, kan du lese de første kapitlene av vår forrige artikkel om ).
RingCT-protokoll
Et av de mulige angrepene på kryptonote-valutaer er blokkjedeanalyse basert på kunnskap om beløpet og tidspunktet for den sendte transaksjonen. Dette tillater begrense søkeområdet for utganger av interesse for angriperen betydelig. For å beskytte mot slik analyse har Monero implementert en anonym transaksjonsprotokoll som fullstendig skjuler overføringsmengdene på nettverket.
Det er verdt å merke seg at ideen om å skjule beløp ikke er ny. Bitcoin Core-utvikleren Greg Maxwell var en av de første som beskrev det i sin . Den nåværende implementeringen av RingCT er dens modifikasjon med muligheten for å bruke ringsignaturer (enten uten dem), og det er slik den fikk navnet sitt - Ring Confidential Transactions.
Protokollen hjelper blant annet med å bli kvitt problemer med å blande støvutganger - utganger på en liten mengde (vanligvis mottatt i form av endring fra transaksjoner), som skapte flere problemer enn de var verdt.
I januar 2017 fant en hard fork av Monero-nettverket sted, som muliggjorde valgfri bruk av konfidensielle transaksjoner. Og allerede i september samme år, med versjon 6 hard gaffel, ble slike transaksjoner de eneste tillatt på nettverket.
RingCT bruker flere mekanismer samtidig: flerlags koblede spontane anonyme gruppesignaturer (Multilayed Linkable Spontaneous Anonymous Group Signature, heretter referert til som MLSAG), en forpliktelsesplan (Pedersen Commitments) og rekkeviddebevis (dette begrepet har ikke en etablert oversettelse til russisk) .
RingCT-protokollen introduserer to typer anonyme transaksjoner: enkle og fullstendige. Lommeboken genererer den første når en transaksjon bruker mer enn én inngang, den andre - i motsatt situasjon. De er forskjellige i valideringen av transaksjonsbeløp og dataene signert med en MLSAG-signatur (vi snakker mer om dette nedenfor). Dessuten kan transaksjoner av typen full genereres med et hvilket som helst antall innganger, det er ingen grunnleggende forskjell. I boken I denne forbindelse sies det at beslutningen om å begrense fulle transaksjoner til én inngang ble tatt i hast og kan endre seg i fremtiden.
MLSAG signatur
La oss huske hva signerte transaksjonsinnganger er. Hver transaksjon bruker og genererer noen midler. Genereringen av midler skjer ved å lage transaksjonsutganger (en direkte analogi er regninger), og utgangen som transaksjonen bruker (tross alt, i det virkelige liv bruker vi sedler) blir input (vær forsiktig, det er veldig lett å bli forvirret her).
En inngang refererer til flere utganger, men bruker bare én, og skaper dermed en "røykeskjerm" for å gjøre det vanskelig å analysere oversettelseshistorien. Hvis en transaksjon har mer enn én inngang, kan en slik struktur representeres som en matrise, der radene er inngangene og kolonnene er de blandede utgangene. For å bevise for nettverket at transaksjonen bruker nøyaktig sine utganger (kjenner deres hemmelige nøkler), er inngangene signert med en ringesignatur. En slik signatur garanterer at underskriveren kjente til de hemmelige nøklene for alle elementer i noen av kolonnene.
Konfidensielle transaksjoner bruker ikke lenger klassiske transaksjoner ringsignaturer, ble de erstattet av MLSAG - en versjon av lignende enkeltlags ringsignaturer tilpasset for flere innganger, .
De kalles flerlags fordi de signerer flere innganger på en gang, som hver er blandet med flere andre, det vil si at en matrise er signert, og ikke en rad. Som vi skal se senere, hjelper dette med å spare på signaturstørrelsen.
La oss se på hvordan en ringsignatur dannes, ved å bruke eksemplet på en transaksjon som bruker 2 reelle utganger og bruker m - 1 tilfeldige fra blokkjeden for å blande. La oss betegne de offentlige nøklene til utgangene vi bruker som
, og nøkkelbilder for dem tilsvarende: Dermed får vi en matrise av størrelse 2 x m. Først må vi beregne de såkalte utfordringene for hvert par av utganger:
Vi starter beregningene med utgangene, som vi bruker ved å bruke deres offentlige nøkler:og tilfeldige tallSom et resultat får vi følgende verdier:
, som vi bruker til å beregne utfordring
neste par utganger (for å gjøre det lettere å forstå hva vi erstatter hvor, har vi fremhevet disse verdiene i forskjellige farger). Alle følgende verdier beregnes i en sirkel ved å bruke formlene gitt i den første illustrasjonen. Den siste tingen å beregne er utfordringen for et par reelle utganger.
Som vi kan se, bruker alle kolonner unntatt den som inneholder reelle utdata tilfeldig genererte tall. Til π- kolonne vil vi også trenge dem. La oss transformerei s:
Signaturen i seg selv er en tuppel av alle disse verdiene:
Disse dataene blir så skrevet inn i en transaksjon.
Som vi kan se, inneholder MLSAG kun én utfordring c0, som lar deg spare på signaturstørrelse (som allerede krever mye plass). Videre, enhver inspektør som bruker dataene, gjenoppretter verdiene c1,..., cm og sjekker det. Dermed er ringen vår lukket og signaturen er verifisert.
For RingCT-transaksjoner av full type legges det til en linje til i matrisen med blandede utganger, men vi vil snakke om dette nedenfor.
Pedersen Forpliktelser
(det engelske begrepet commitments brukes oftere) brukes slik at den ene parten kan bevise at de kjenner en viss hemmelighet (nummer) uten å faktisk avsløre det. For eksempel kaster du et visst tall på terningen, vurderer forpliktelse og gir det videre til den verifisere parten. Således, i øyeblikket avsløringen av det hemmelige nummeret, beregner verifikatoren uavhengig forpliktelsen, og sørger dermed for at du ikke lurte ham.
Monero-forpliktelser brukes til å skjule beløpene på overføringer og bruke det vanligste alternativet - Pedersen-forpliktelser. Forresten, et interessant faktum - først foreslo utviklerne å skjule beløpene ved vanlig blanding, det vil si å legge til utganger for vilkårlige beløp for å introdusere usikkerhet, men så byttet de til forpliktelser (det er ikke et faktum at de sparte på transaksjonsstørrelsen, som vi vil se nedenfor).
Generelt ser engasjementet slik ut:
hvor C – betydningen av selve forpliktelsen, a - skjult beløp, H er et fast punkt på den elliptiske kurven (ekstra generator), og x — en slags vilkårlig maske, en skjulefaktor generert tilfeldig. Masken er nødvendig her slik at en tredjepart ikke bare kan gjette verdien av engasjement.
Når en ny utgang genereres, beregner lommeboken forpliktelse for den, og når den er brukt, tar den enten verdien som ble beregnet under genereringen, eller beregner den på nytt, avhengig av transaksjonstypen.
RingCT enkelt
I tilfelle av enkle RingCT-transaksjoner, for å sikre at transaksjonen skapte utganger i et beløp som tilsvarer mengden input (produserte ikke penger ut av løse luften), er det nødvendig at summen av forpliktelsene til den første og andre de være de samme, det vil si:
Forpliktelseskommisjoner vurderer det litt annerledes - uten maske:
Der a — provisjonsbeløpet, det er offentlig tilgjengelig.
Denne tilnærmingen lar oss bevise overfor den tillitsfulle parten at vi bruker de samme beløpene uten å avsløre dem.
For å gjøre ting klarere, la oss se på et eksempel. La oss si at en transaksjon bruker to utganger (som betyr at de blir innganger) på 10 og 5 XMR og genererer tre utganger verdt 12 XMR: 3, 4 og 5 XMR. Samtidig betaler han en provisjon på 3 XMR. Dermed er mengden penger brukt pluss det genererte beløpet og provisjonen lik 15 XMR. La oss prøve å beregne forpliktelser og se på forskjellen i beløpene deres (husk regnestykket):
Her ser vi at for at ligningen skal konvergere, trenger vi at summene av inngangs- og utgangsmaskene er de samme. For å gjøre dette, genererer lommeboken tilfeldig x1, y1, y2 og y3, og resten x2 regner slik:
Ved å bruke disse maskene kan vi bevise for enhver verifikator at vi ikke genererer mer penger enn vi bruker, uten å avsløre beløpet. Original, ikke sant?
RingCT full
I fulle RingCT-transaksjoner er det litt mer intrikat å sjekke overføringsbeløpene. I disse transaksjonene omberegner ikke lommeboken forpliktelser for innganger, men bruker de som ble beregnet da de ble generert. I dette tilfellet må vi anta at vi ikke lenger får differansen i summene lik null, men i stedet:
Her z — forskjell mellom inngangs- og utgangsmasker. Hvis vi vurderer zG som en offentlig nøkkel (som den de facto er), da z er den private nøkkelen. Dermed kjenner vi de offentlige og tilhørende private nøklene. Med disse dataene i hånden kan vi bruke dem i MLSAG-ringsignaturen sammen med de offentlige nøklene til utgangene som blandes:
Dermed vil en gyldig ringesignatur sikre at vi kjenner alle de private nøklene til en av kolonnene, og vi kan bare kjenne den private nøkkelen i siste rad dersom transaksjonen ikke genererer mer midler enn den bruker. Forresten, her er svaret på spørsmålet "hvorfor fører ikke forskjellen i mengden forpliktelser til null" - hvis zG = 0, så utvider vi kolonnen med reelle utganger.
Hvordan vet mottakeren av midlene hvor mye penger som ble sendt til ham? Alt er enkelt her - avsenderen av transaksjonen og mottakeren bytter nøkler ved hjelp av Diffie-Hellman-protokollen, bruker transaksjonsnøkkelen og mottakerens visningsnøkkel og beregner den delte hemmeligheten. Avsenderen skriver data om utgangsbeløpene, kryptert med denne delte nøkkelen, i spesielle felt for transaksjonen.
Rekkeviddebevis
Hva skjer hvis du bruker et negativt tall som beløp i forpliktelser? Dette kan føre til generering av ekstra mynter! Dette resultatet er uakseptabelt, så vi må garantere at beløpene vi bruker ikke er negative (uten å avsløre disse beløpene, selvfølgelig, ellers er det så mye arbeid og alt forgjeves). Vi må med andre ord bevise at summen er i intervallet [0, 2n - 1].
For å gjøre dette deles summen av hver utgang inn i binære sifre og forpliktelsen beregnes for hvert siffer separat. Det er bedre å se hvordan dette skjer med et eksempel.
La oss anta at mengdene våre er små og passer inn i 4 bits (i praksis er dette 64 bits), og vi lager en utgang verdt 5 XMR. Vi beregner forpliktelser for hver kategori og total forpliktelse for hele beløpet:
Deretter blandes hver forpliktelse med en surrogat (Ci-2iH) og er signert i par med Borromeo-ringsignaturen (en annen ringsignatur), foreslått av Greg Maxwell i 2015 (du kan lese mer om den ):
Til sammen kalles dette rekkeviddebevis og lar deg sikre at engasjementer bruker beløp i området [0, 2n - 1].
Hva blir det neste?
I den nåværende implementeringen tar rekkeviddeprøver mye plass - 6176 byte per utgang. Dette fører til større transaksjoner og dermed høyere gebyrer. For å redusere størrelsen på en Monero-transaksjon, introduserer utviklere skuddsikre i stedet for Borromeo-signaturer - en rekkeviddesikret mekanisme uten bitvise forpliktelser. , er de i stand til å redusere størrelsen på rekkeviddebeviset med opptil 94 %. Forresten, i midten av juli gikk teknologien fra Kudelski Security, som ikke avslørte noen vesentlige mangler verken i selve teknologien eller i implementeringen. Teknologien er allerede brukt i testnettverket, og med den nye hardgaffelen kan den trolig flytte til hovednettet.
Still spørsmålene dine, foreslå emner for nye artikler om teknologier innen kryptovaluta, og abonner også på gruppen vår i for å holde deg oppdatert med våre arrangementer og publikasjoner.
Kilde: www.habr.com