Vi fortsætter vores serie om Monero blockchain, og dagens artikel vil fokusere på RingCT (Ring Confidential Transactions) protokollen, som introducerer fortrolige transaktioner og nye ringsignaturer. Desværre er der lidt information på internettet om, hvordan det fungerer, og vi forsøgte at udfylde dette hul.
Vi vil tale om, hvordan netværket skjuler overførselsbeløb ved hjælp af denne protokol, hvorfor de forlod de klassiske cryptonote-ringsignaturer, og hvordan denne teknologi vil udvikle sig yderligere.
Da denne protokol er en af de mest komplekse teknologier i Monero, vil læseren have brug for en grundlæggende viden om designet af denne blockchain og et forbigående kendskab til elliptisk kurvekryptografi (for at opfriske denne viden kan du læse de første kapitler af vores tidligere artikel om ).
RingCT protokol
Et af de mulige angreb på kryptonote-valutaer er blockchain-analyse baseret på viden om mængden og tidspunktet for den sendte transaktion. Dette tillader indsnævre søgeområdet væsentligt for udgange af interesse for angriberen. For at beskytte mod en sådan analyse har Monero implementeret en anonym transaktionsprotokol, der fuldstændigt skjuler mængderne af overførsler på netværket.
Det er værd at bemærke, at ideen om at skjule beløb ikke er ny. Bitcoin Core-udvikler Greg Maxwell var en af de første, der beskrev det i sin . Den nuværende implementering af RingCT er dens modifikation med mulighed for at bruge ringsignaturer (uanset om det er uden dem), og det er sådan, det har fået sit navn - Ring Confidential Transactions.
Protokollen hjælper blandt andet med at slippe af med problemer med at blande støvoutput - output på en lille mængde (normalt modtaget i form af ændring fra transaktioner), som skabte flere problemer, end de var værd.
I januar 2017 fandt en hård forgrening af Monero-netværket sted, hvilket muliggjorde valgfri brug af fortrolige transaktioner. Og allerede i september samme år, med version 6 hard fork, blev sådanne transaktioner de eneste tilladte på netværket.
RingCT bruger flere mekanismer på én gang: flerlagsforbundne spontane anonyme gruppesignaturer (Multilayered Linkable Spontaneous Anonymous Group Signature, i det følgende benævnt MLSAG), en forpligtelsesordning (Pedersen Commitments) og rækkeviddebeviser (dette udtryk har ikke en etableret oversættelse til russisk) .
RingCT-protokollen introducerer to typer anonyme transaktioner: enkle og fulde. Tegnebogen genererer den første, når en transaktion bruger mere end én input, den anden - i den modsatte situation. De adskiller sig i valideringen af transaktionsbeløb og de data, der er underskrevet med en MLSAG-signatur (vi vil tale mere om dette nedenfor). Desuden kan transaktioner af typen fuld genereres med et hvilket som helst antal input, der er ingen grundlæggende forskel. I bogen I denne forbindelse siges det, at beslutningen om at begrænse hele transaktioner til ét input blev truffet i hast og kan ændre sig i fremtiden.
MLSAG underskrift
Lad os huske, hvad signerede transaktionsinput er. Hver transaktion bruger og genererer nogle midler. Genereringen af midler sker ved at skabe transaktionsoutput (en direkte analogi er regninger), og det output, som transaktionen bruger (trods alt, i det virkelige liv bruger vi pengesedler) bliver input (vær forsigtig, det er meget nemt at blive forvirret her).
Et input refererer til flere output, men bruger kun ét, hvilket skaber et "røgglas", der gør det vanskeligt at analysere oversættelseshistorien. Hvis en transaktion har mere end én input, så kan en sådan struktur repræsenteres som en matrix, hvor rækkerne er input, og kolonnerne er de blandede output. For at bevise over for netværket, at transaktionen bruger nøjagtigt sine output (kender deres hemmelige nøgler), er inputs signeret med en ringesignatur. En sådan signatur garanterer, at underskriveren kendte de hemmelige nøgler til alle elementer i nogen af kolonnerne.
Fortrolige transaktioner bruger ikke længere klassiske transaktioner ringsignaturer, blev de erstattet af MLSAG - en version af lignende enkeltlags ringsignaturer tilpasset til flere input, .
De kaldes multilayer, fordi de signerer flere input på én gang, som hver er blandet med flere andre, dvs. en matrix er underskrevet, og ikke en række. Som vi vil se senere, hjælper dette med at spare på signaturstørrelsen.
Lad os se på, hvordan en ringsignatur dannes ved at bruge eksemplet på en transaktion, der bruger 2 reelle output og bruger m - 1 tilfældige fra blockchain til blanding. Lad os betegne de offentlige nøgler til de output, vi bruger som
, og nøglebilleder til dem i overensstemmelse hermed: Således får vi en matrix af størrelse 2 x m. Først skal vi beregne de såkaldte udfordringer for hvert par af output:
Vi starter beregningerne med output, som vi bruger på deres offentlige nøgler:og tilfældige talSom et resultat får vi følgende værdier:
, som vi bruger til at beregne udfordring
det næste par output (for at gøre det lettere at forstå, hvad vi erstatter hvor, har vi fremhævet disse værdier i forskellige farver). Alle følgende værdier beregnes i en cirkel ved hjælp af formlerne givet i den første illustration. Den sidste ting at beregne er udfordringen for et par rigtige output.
Som vi kan se, bruger alle kolonner undtagen den, der indeholder reelle output, tilfældigt genererede tal. Til π- kolonne får vi også brug for dem. Lad os transformerei s:
Signaturen i sig selv er en tupel af alle disse værdier:
Disse data skrives derefter ind i en transaktion.
Som vi kan se, indeholder MLSAG kun én udfordring c0, som giver dig mulighed for at spare på signaturstørrelsen (som i forvejen kræver meget plads). Yderligere, enhver inspektør, der bruger dataene, gendanner værdierne c1,..., cm og tjekker det. Dermed er vores ring lukket og signaturen er verificeret.
For RingCT-transaktioner af den fulde type tilføjes en linje mere til matrixen med blandede output, men vi vil tale om dette nedenfor.
Pedersen Forpligtelser
(det engelske udtryk commitments bruges oftere) bruges, så den ene part kan bevise, at de kender en bestemt hemmelighed (nummer) uden egentlig at afsløre den. For eksempel kaster du et bestemt tal på terningerne, overvejer engagement og giver det videre til den verificerende part. I det øjeblik, hvor det hemmelige nummer afsløres, beregner verifikatoren således uafhængigt forpligtelsen og sikrer sig derved, at du ikke har bedraget ham.
Monero-tilsagn bruges til at skjule beløbene for overførsler og bruge den mest almindelige mulighed - Pedersen-tilsagn. Forresten et interessant faktum - først foreslog udviklerne at skjule beløbene ved almindelig blanding, det vil sige at tilføje output for vilkårlige beløb for at indføre usikkerhed, men så skiftede de til forpligtelser (det er ikke et faktum, at de sparede på transaktionsstørrelsen, som vi vil se nedenfor).
Generelt ser engagementet således ud:
hvor C — betydningen af selve forpligtelsen a - skjult beløb, H er et fast punkt på den elliptiske kurve (ekstra generator), og x — en slags vilkårlig maske, en skjulefaktor genereret tilfældigt. Masken er nødvendig her, så en tredjepart ikke bare kan gætte værdien af engagement.
Når et nyt output genereres, beregner tegnebogen engagement for det, og når det er brugt, tager det enten værdien beregnet under genereringen eller genberegner den, afhængigt af transaktionstypen.
RingCT enkel
I tilfælde af simple RingCT-transaktioner, for at sikre, at transaktionen skabte output svarende til mængden af input (ikke producerede penge ud af den blå luft), er det nødvendigt, at summen af forpligtelserne for den første og anden er samme, det vil sige:
Forpligtelseskommissioner vurderer det lidt anderledes - uden maske:
Hvor a — provisionsbeløbet, det er offentligt tilgængeligt.
Denne tilgang giver os mulighed for at bevise over for den afhængige part, at vi bruger de samme beløb uden at oplyse dem.
For at gøre tingene klarere, lad os se på et eksempel. Lad os sige, at en transaktion bruger to output (hvilket betyder, at de bliver input) på 10 og 5 XMR og genererer tre output til en værdi af 12 XMR: 3, 4 og 5 XMR. Samtidig betaler han en kommission på 3 XMR. Således er mængden af brugte penge plus det genererede beløb og provision lig med 15 XMR. Lad os prøve at beregne forpligtelser og se på forskellen i deres beløb (husk regnestykket):
Her ser vi, at for at ligningen kan konvergere, skal summen af input- og outputmaskerne være de samme. For at gøre dette genererer tegnebogen tilfældigt x1, y1, y2 og y3, og de resterende x2 beregner sådan:
Ved at bruge disse masker kan vi bevise over for enhver verifikator, at vi ikke genererer flere midler, end vi bruger, uden at oplyse beløbet. Original, ikke?
RingCT fuld
I fulde RingCT-transaktioner er det lidt mere indviklet at kontrollere overførselsbeløbene. I disse transaktioner genberegner tegnebogen ikke forpligtelser for input, men bruger dem, der blev beregnet, da de blev genereret. I dette tilfælde må vi antage, at vi ikke længere får forskellen i summerne lig med nul, men i stedet:
Her z — forskel mellem input- og outputmasker. Hvis vi overvejer zG som en offentlig nøgle (hvilket den de facto er), så z er den private nøgle. Således kender vi de offentlige og tilhørende private nøgler. Med disse data i hånden kan vi bruge dem i MLSAG-ringsignaturen sammen med de offentlige nøgler til de output, der blandes:
En gyldig ringesignatur vil således sikre, at vi kender alle de private nøgler i en af kolonnerne, og vi kan kun kende den private nøgle i sidste række, hvis transaktionen ikke genererer flere midler, end den bruger. Her er i øvrigt svaret på spørgsmålet "hvorfor fører forskellen i mængderne af forpligtelser ikke til nul" - hvis zG = 0, så udvider vi kolonnen med rigtige output.
Hvordan ved modtageren af midlerne, hvor mange penge der blev sendt til ham? Alt er enkelt her - afsenderen af transaktionen og modtageren udveksler nøgler ved hjælp af Diffie-Hellman-protokollen, ved hjælp af transaktionsnøglen og modtagerens visningsnøgle og beregner den delte hemmelighed. Afsenderen skriver data om outputmængderne, krypteret med denne delte nøgle, i særlige felter for transaktionen.
Rækkevidde beviser
Hvad sker der, hvis du bruger et negativt tal som beløb i forpligtelser? Dette kan føre til generering af yderligere mønter! Dette resultat er uacceptabelt, så vi skal garantere, at de beløb, vi bruger, ikke er negative (uden at oplyse disse beløb, selvfølgelig, ellers er der så meget arbejde og alt forgæves). Vi skal med andre ord bevise, at summen er i intervallet [0, 2n - 1].
For at gøre dette opdeles summen af hvert output i binære cifre, og forpligtelsen beregnes for hvert ciffer separat. Det er bedre at se, hvordan dette sker med et eksempel.
Lad os antage, at vores mængder er små og passer ind i 4 bit (i praksis er dette 64 bit), og vi skaber et output, der er værd 5 XMR. Vi beregner forpligtelser for hver kategori og det samlede engagement for hele beløbet:
Dernæst blandes hver forpligtelse med en surrogat (Ci-2iH) og er signeret i par med Borromeo-ringsignaturen (en anden ringsignatur), foreslået af Greg Maxwell i 2015 (du kan læse mere om den ):
Samlet kaldes dette for range proof og giver dig mulighed for at sikre, at engagementer bruger beløb i intervallet [0, 2n - 1].
Hvad er det næste?
I den nuværende implementering fylder afstandsbeviser meget - 6176 bytes pr. output. Dette fører til større transaktioner og derfor højere gebyrer. For at reducere størrelsen af en Monero-transaktion introducerer udviklere skudsikre i stedet for Borromeo-signaturer - en rækkesikker mekanisme uden bitvise forpligtelser. , er de i stand til at reducere størrelsen af rækkevidde med op til 94 %. I midten af juli gik teknologien forresten forbi fra Kudelski Security, som ikke afslørede væsentlige mangler hverken i selve teknologien eller i dens implementering. Teknologien bruges allerede i testnetværket, og med den nye hårde gaffel kan den formentlig flytte til hovednettet.
Stil dine spørgsmål, foreslå emner til nye artikler om teknologier inden for kryptovaluta, og abonner også på vores gruppe i at holde sig ajour med vores arrangementer og publikationer.
Kilde: www.habr.com