We gaan verder met onze cyclus over de werking van de Monero-blockchain, en het artikel van vandaag is gewijd aan het RingCT-protocol (Ring Confidential Transactions), waarin vertrouwelijke transacties en nieuwe ringhandtekeningen worden gepresenteerd. Helaas is er weinig informatie op het internet over hoe het werkt, en we hebben geprobeerd deze leemte te vullen.
We zullen bespreken hoe dit protocol het netwerk in staat stelt om bedragen van overmakingen te verhullen, waarom men afstand heeft gedaan van de klassieke ringhandtekeningen die voor cryptonote worden gebruikt, en hoe deze technologie zich in de toekomst zal ontwikkelen.
Aangezien dit protocol een van de meest gecompliceerde technologieën in Monero is, heeft de lezer basiskennis over de werking van deze blockchain en oppervlakkige kennis van cryptografie met elliptische krommen nodig (om deze kennis op te frissen, kan men de eerste hoofdstukken van ons voorgaande artikel over ).
RingCT-protocol
Een van de mogelijke aanvallen op cryptonote-valuta's is blockchain-analyse, gebaseerd op de kennis van het bedrag en de tijd van de verzonden transactie. Dit stelt de aanvallers in staat om aanzienlijk het gebied te verkleinen van de ‘outputs’ die hen interesseren. Om dergelijke analyses tegen te gaan, is in Monero het protocol voor anonieme transacties geïntroduceerd, dat de bedragen van overmakingen in het netwerk volledig verbergt.
Het is de moeite waard op te merken dat het idee om bedragen te verbergen niet nieuw is. Een van de eersten die dit beschreef was Bitcoin Core-ontwikkelaar Greg Maxwell in zijn . De huidige implementatie van RingCT is een modificatie hiervan met de mogelijkheid om ringhandtekeningen te gebruiken (hoe kan het ook anders), en kreeg zo zijn naam — Ring Confidential Transactions.
Bovendien helpt het protocol om problemen met het mengen van dust-outputs — outputs met een klein bedrag (die meestal ontstaan als wisselgeld van transacties) — op te lossen, die meer problemen veroorzaakten dan ze waard waren.
In januari 2017 vond er een hard fork plaats van het Monero-netwerk, waarmee het optioneel mogelijk werd om vertrouwelijke transacties te gebruiken. En al in september van dat jaar werden met de hard fork van versie 6 dergelijke transacties de enige toegestane in het netwerk.
RingCT gebruikt verschillende mechanisms: meelaagbare gerelateerde spontane anonieme groepshandtekeningen (Multilayered Linkable Spontaneous Anonymous Group Signature, hierna — MLSAG), een belofte-schema (Pedersen Commitments) en range proofs (er is geen gevestigde vertaling voor deze term naar het Nederlands).
Het RingCT-protocol introduceert twee soorten anonieme transacties: simple en full. De eerste wordt door de portemonnee gegenereerd wanneer de transactie meer dan één invoer gebruikt, de tweede in het tegenovergestelde geval. Ze verschillen in de validatie van transactiesommen en de gegevens die met een MLSAG-handtekening zijn ondertekend (hierover later meer). Bovendien kunnen full-transacties met een willekeurig aantal ingangen worden gegenereerd, er is geen fundamenteel verschil. stelt hierover dat de beslissing om full-transacties tot één invoer te beperken snel is genomen en in de toekomst kan worden gewijzigd.
MLSAG-handtekening
Laten we ons herinneren wat de ondertekende ingangen van een transactie zijn. Elke transactie uitgeeft bepaalde fondsen en genereert. De creatie van fondsen vindt plaats door uitvoeringen van de transactie te creëren (een directe analogie — bankbiljetten), en de uitgave die de transactie uitgeeft (want in het echte leven besteden we precies geldbiljetten), wordt een invoer (let op, hier kan het heel gemakkelijk verwarrend worden).
Een invoer verwijst naar meerdere uitvoeringen, maar besteedt er slechts één, waardoor er een 'rookgordijn' ontstaat om de analyse van de transactiegeschiedenis te bemoeilijken. Als een transactie meer dan één invoer heeft, kan deze structuur worden voorgesteld als een matrix, waarbij de rijen invoeren zijn en de kolommen de betrokken uitvoeringen. Om het netwerk te bewijzen dat de transactie precies zijn eigen uitvoeringen uitgeeft (weet de geheime sleutels), ondertekenen de ingangen met een ringhandtekening. Deze handtekening garandeert dat de ondertekenaar op de hoogte was van de geheime sleutels van alle elementen in een van de kolommen.
Privacy-transacties maken geen gebruik meer van de klassieke ringhandtekeningen, maar zijn vervangen door MLSAG — een versie van vergelijkbare enkele laag ringhandtekeningen, aangepast voor meerdere ingangen. .
Ze worden multilayer genoemd omdat ze meerdere ingangen tegelijk ondertekenen, elk hiervan is vermengd met verschillende anderen, dat wil zeggen, een matrix wordt ondertekend in plaats van één rij. Zoals we later zullen zien, helpt dit om de handtekening kleiner te maken.
Laten we eens bekijken hoe een ringhandtekening wordt gevormd, met de voorbeeldtransactie die 2 echte uitvoeringen uitgeeft en m — 1 willekeurige invoeren uit de blockchain gebruikt voor vermenging. We duiden de openbare sleutels van de uitvoeringen die we uitgeven aan als
, en de key images voor hen respectievelijk: 
Op deze manier krijgen we een matrix van 2 x m. We moeten eerst de zogenaamde challenges voor elk paar uitgangen berekenen:
De berekeningen beginnen met de uitgangen die we gebruiken, met hun publieke sleutels:
en willekeurige getallen
Uiteindelijk krijgen we de waarden:
, die we gebruiken voor de berekening van de challenge
van het volgende paar uitgangen (om het gemakkelijker te maken te begrijpen waar we wat invullen, hebben we deze waarden in verschillende kleuren gemarkeerd). Alle volgende waarden worden cirkelvormig berekend volgens de formules die in de eerste illustratie zijn gegeven. De laatste challenge wordt berekend voor het paar echte uitgangen.
Zoals we zien, worden in alle kolommen, behalve die met echte uitgangen, willekeurig gegenereerde getallen gebruikt.
in te stellen. Voor π-de kolom hebben we ook nodig. We transformeren
in s:
De handtekening zelf bestaat uit een tuple van al deze waarden:
Vervolgens worden deze gegevens in de transactie geschreven.
Zoals we zien, bevat MLSAG maar één challenge c0, wat helpt om de grootte van de handtekening te besparen (die al veel ruimte vereist). Vervolgens herstelt elke verifier, met behulp van de gegevens
, de waarden c1,…, cm en controleert of
. Op deze manier is onze ring gesloten en is de handtekening geslaagd voor de controle.
Voor RingCT-transacties van het type full wordt er nog een regel aan de matrix toegevoegd met de gemengde uitgangen, maar daarover vertellen we later.
Pedersen Commitments
(de Engelstalige term - commitments - wordt vaker gebruikt) worden gebruikt zodat één partij kan bewijzen dat ze een bepaald geheim (getal) kent, zonder dit feitelijk te onthullen. Bijvoorbeeld, je gooit met een dobbelsteen een bepaald getal, berekent de commitment en geeft deze aan de verifier. Op het moment dat het geheime getal wordt onthuld, berekent de verifier zelf de commitment en vergewist zich zo ervan dat je niet hebt gelogen.
In Monero worden commitments gebruikt om de bedragen van overboekingen te verbergen en wordt de meest gangbare optie gebruikt - Pedersen commitments. Overigens is het een interessant feit - aanvankelijk stelden de ontwikkelaars voor om de bedragen te verbergen door gewone mengingen, dat wil zeggen, door uitgangen van willekeurige bedragen toe te voegen om onzekerheid te creëren, maar later zijn ze overgestapt op commitments (het is daarbij niet zeker dat ze de transactiegrootte hebben bespaard, zoals we later zullen zien).
Over het algemeen ziet een commitment er als volgt uit:
Waarbij C - de waarde van de commitment zelf, a - het verborgen bedrag, H — een vaste punt op een elliptische curve (extra generator), en x — een willekeurige masker, een verborgen factor, die willekeurig wordt gegenereerd. De masker is hier nodig zodat een derde partij de waarde van commitment niet eenvoudig kan raden door te proberen.
Bij het genereren van een nieuwe output berekent de portemonnee de commitment, en bij het uitgeven neemt het ofwel de waarde die bij generatie is berekend, of het herberekent deze opnieuw — afhankelijk van het type transactie.
RingCT simple
In het geval van simple RingCT-transacties, om te garanderen dat de transactie outputs creëert van een totaal dat gelijk is aan de som van de inputs (geen geld uit lucht genereert), moeten de totalen van de commitments van de eerste en tweede gelijk zijn, dat wil zeggen:
De commitment van de commissie wordt iets anders berekend — zonder masker:
, waar a — de som van de commissie, deze is publiek beschikbaar.
Deze benadering maakt het mogelijk om de controleur te bewijzen dat we dezelfde bedragen gebruiken, zonder ze openbaar te maken.
Om het duidelijker te maken, laten we een voorbeeld bekijken. Stel dat de transactie twee outputs uitgeeft (dus deze worden inputs) van 10 en 5 XMR en genereert drie outputs van in totaal 12 XMR: 3, 4 en 5 XMR. Daarbij betaalt het een commissie van 3 XMR. Dus de som van het uitgegeven geld plus de gegenereerde som en de commissie is gelijk aan 15 XMR. Laten we proberen de commitments te berekenen en kijken naar het verschil van hun totalen (laten we de wiskunde herinneren):
Hier zien we dat om de vergelijking kloppend te maken — de som van de maskers van de inputs en outputs gelijk moeten zijn. Daarom genereert de portemonnee willekeurig x1, y1, y2 en y3, terwijl het resterende x2 zo wordt berekend:
Met deze maskers kunnen we aan elke controleur bewijzen dat we niet meer middelen genereren dan we uitgeven, zonder de sommen openbaar te maken. Origineel, toch?
RingCT full
In full RingCT-transacties gaat de controle van de sommen van de overboekingen iets complexer. In deze transacties herberekent de portemonnee de commitments voor inputs niet, maar gebruikt de waarden die bij hun generatie zijn berekend. Hierbij moeten we aannemen dat het verschil van de totalen nu niet gelijk aan nul zal zijn, maar in plaats daarvan:
Hier z — het verschil van de maskers van inputs en outputs. Als we zG beschouwen als een publieke sleutel (wat deze in feite is), dan z — dit is de privé-sleutel. Dus, we kennen de publieke en de bijbehorende privésleutels. Met deze gegevens kunnen we ze gebruiken in de ringhandtekening MLSAG samen met de publieke sleutels van de menguitgangen:
Zo zal een geldige ringhandtekening garanderen dat we alle privésleutels van een van de kolommen kennen, en de privésleutel in de laatste rij kunnen we alleen kennen als de transactie geen middelen genereert die groter zijn dan wat er wordt uitgegeven. Trouwens, hier is ook het antwoord op de vraag "waarom het verschil in de sommen van de commitments niet naar nul leidt" — als zG = 0, dan onthullen we de kolom met de echte uitkomsten.
En hoe weet de ontvanger van de middelen hoeveel geld hem is gestuurd? Dit is eenvoudig — de verzender van de transactie en de ontvanger wisselen sleutels uit via het Diffie-Hellman-protocol, gebruikmakend van de transactiesleutel en de view-sleutel van de ontvanger om een gemeenschappelijk geheim te berekenen. De verzender noteert in speciale velden van de transactie gegevens over de bedragen uitgangen, versleuteld met deze gemeenschappelijke sleutel.
Range proofs
Wat gebeurt er als we een negatief getal gebruiken als bedrag in de commitments? Dit kan leiden tot het genereren van extra munten! Een dergelijke uitkomst is onaanvaardbaar, dus we hebben de garantie nodig dat de bedragen die we gebruiken niet negatief zijn (zonder deze bedragen te onthullen, uiteraard, anders was al dat werk voor niets). Met andere woorden, we moeten bewijzen dat het bedrag in het interval ligt [0, 2n — 1].
Daartoe wordt het bedrag van elke uitgang opgedeeld in binaire cijfers en wordt er een commitment voor elk cijfer afzonderlijk berekend. Hoe dit werkt, kunnen we het beste aan de hand van een voorbeeld bekijken.
Stel dat we kleine bedragen hebben die in 4 bits passen (in de praktijk zijn dat 64 bits), en we creëren een uitgang voor een bedrag van 5 XMR. We berekenen de commitments voor elk cijfer en de totale commitment voor het volledige bedrag:
Vervolgens wordt elke commitment gemengd met de surrogaat (Ci-2iH) en wordt elk paar getekend met een Borromeaanse ringhandtekening (nog een soort ringhandtekening), voorgesteld door Greg Maxwell in 2015 (meer hierover kan worden gelezen ):
Alles samen wordt een range proof genoemd en garandeert dat de bedragen in de commitments binnen het interval liggen. [0, 2n — 1].
Wat nu?
In de huidige implementatie nemen range proofs veel ruimte in — 6176 bytes per uitkomst. Dit leidt tot grote transacties en dus hogere kosten. Om de grootte van de Monero-transacties te verminderen, introduceren de ontwikkelaars in plaats van de Borromeo-handtekeningen bulletproofs — een range proof-mechanisme zonder bit-commitments. , zijn ze in staat om de grootte van range proofs tot 94% te verkleinen. Ter informatie, in het midden van juli heeft de technologie een ondergaan door Kudelski Security, die geen significante tekortkomingen heeft gevonden in zowel de technologie zelf als de implementatie ervan. De technologie wordt al toegepast in het testnetwerk en kan met de nieuwe hard fork waarschijnlijk ook naar het hoofdnetwerk migreren.
Stel je vragen, doe suggesties voor nieuwe artikelen over technologieën op het gebied van cryptocurrency en abonneer je op onze groep in , om op de hoogte te blijven van onze evenementen en publicaties.
Bron: habr.com
