We vervolgen onze serie over de Monero-blockchain en het artikel van vandaag zal zich richten op het RingCT-protocol (Ring Confidential Transactions), dat vertrouwelijke transacties en nieuwe ringhandtekeningen introduceert. Helaas is er op internet weinig informatie te vinden over hoe het werkt, en we hebben geprobeerd deze leemte op te vullen.
We zullen praten over hoe het netwerk overdrachtsbedragen verbergt met behulp van dit protocol, waarom ze de klassieke cryptonote-ringhandtekeningen hebben verlaten en hoe deze technologie zich verder zal ontwikkelen.
Omdat dit protocol een van de meest complexe technologieën in Monero is, heeft de lezer een basiskennis nodig van het ontwerp van deze blockchain en een voorbijgaande kennis van elliptische curve-cryptografie (om deze kennis op te frissen, kun je de eerste hoofdstukken van onze vorig artikel over ).
RingCT-protocol
Een van de mogelijke aanvallen op cryptonote-valuta's is blockchain-analyse op basis van kennis van het bedrag en het tijdstip van de verzonden transactie. Dit maakt het mogelijk het zoekgebied aanzienlijk verkleinen naar uitgangen die van belang zijn voor de aanvaller. Ter bescherming tegen dergelijke analyses heeft Monero een anoniem transactieprotocol geïmplementeerd dat de hoeveelheden overdrachten op het netwerk volledig verbergt.
Het is vermeldenswaard dat het idee om bedragen te verbergen niet nieuw is. Bitcoin Core-ontwikkelaar Greg Maxwell was een van de eersten die het in zijn zijn beschreef . De huidige implementatie van RingCT is de aanpassing ervan met de mogelijkheid om ringhandtekeningen te gebruiken (al dan niet zonder), en zo kreeg het zijn naam: Ring Confidential Transactions.
Het protocol helpt onder andere bij het wegwerken van problemen met het mengen van stofuitvoer - uitvoer van een kleine hoeveelheid (meestal ontvangen in de vorm van wisselgeld uit transacties), die meer problemen veroorzaakte dan ze waard waren.
In januari 2017 vond een hard fork van het Monero-netwerk plaats, waardoor het optionele gebruik van vertrouwelijke transacties mogelijk werd. En al in september van hetzelfde jaar, met de hard fork versie 6, werden dergelijke transacties de enige transacties die op het netwerk waren toegestaan.
RingCT gebruikt verschillende mechanismen tegelijk: meerlaagse gekoppelde spontane anonieme groepshandtekeningen (Multilayered Linkable Spontaneous Anonymous Group Signature, hierna MLSAG genoemd), een commitment-schema (Pedersen Commitments) en bereikbewijzen (deze term heeft geen vaste vertaling in het Russisch) .
Het RingCT-protocol introduceert twee soorten anonieme transacties: eenvoudig en volledig. De portemonnee genereert de eerste wanneer een transactie meer dan één invoer gebruikt, de tweede - in de tegenovergestelde situatie. Ze verschillen in de validatie van transactiebedragen en de gegevens ondertekend met een MLSAG-handtekening (hierover zullen we hieronder meer over praten). Bovendien kunnen transacties van het type Full met een willekeurig aantal invoer worden gegenereerd, er is geen fundamenteel verschil. In het boek In dit verband wordt gezegd dat de beslissing om volledige transacties tot één input te beperken in haast is genomen en in de toekomst kan veranderen.
MLSAG-handtekening
Laten we onthouden wat ondertekende transactie-invoer is. Elke transactie besteedt en genereert wat geld. Het genereren van geld vindt plaats door het creëren van transactie-outputs (een directe analogie is rekeningen), en de output die de transactie uitgeeft (in het echte leven geven we immers bankbiljetten uit) wordt de input (wees voorzichtig, het is heel gemakkelijk om in de war te raken hier).
Een input verwijst naar meerdere outputs, maar besteedt er slechts één, waardoor een ‘rookgordijn’ ontstaat dat het moeilijk maakt om de vertaalgeschiedenis te analyseren. Als een transactie meer dan één invoer heeft, kan een dergelijke structuur worden weergegeven als een matrix, waarbij de rijen de invoer zijn en de kolommen de gemengde uitvoer. Om aan het netwerk te bewijzen dat de transactie precies de outputs besteedt (de geheime sleutels kent), worden de inputs ondertekend met een ringhandtekening. Een dergelijke handtekening garandeert dat de ondertekenaar de geheime sleutels voor alle elementen van een van de kolommen kende.
Bij vertrouwelijke transacties wordt niet langer gebruik gemaakt van klassieke transacties ringhandtekeningen, ze werden vervangen door MLSAG - een versie van vergelijkbare enkellaagse ringhandtekeningen aangepast voor meerdere invoer, .
Ze worden meerlagen genoemd omdat ze meerdere invoer tegelijk ondertekenen, die elk met verschillende andere worden gemengd, d.w.z. er wordt een matrix ondertekend en niet één rij. Zoals we later zullen zien, helpt dit bij het besparen op de handtekeninggrootte.
Laten we eens kijken hoe een ringsignatuur wordt gevormd, met behulp van het voorbeeld van een transactie die 2 echte outputs uitgeeft en m - 1 willekeurige outputs uit de blockchain gebruikt voor het mixen. Laten we de publieke sleutels aanduiden van de outputs die we uitgeven
, en de belangrijkste afbeeldingen daarvoor: We krijgen dus een matrix van grootte 2 x m. Eerst moeten we de zogenaamde uitdagingen voor elk paar outputs berekenen:
We beginnen de berekeningen met de outputs, die we uitgeven met behulp van hun publieke sleutels:en willekeurige getallenAls resultaat krijgen we de volgende waarden:
, die we gebruiken om de uitdaging te berekenen
het volgende paar uitgangen (om het gemakkelijker te maken te begrijpen wat we waar vervangen, hebben we deze waarden in verschillende kleuren gemarkeerd). Alle volgende waarden worden in een cirkel berekend met behulp van de formules in de eerste afbeelding. Het laatste dat moet worden berekend, is de uitdaging voor een paar reële outputs.
Zoals we kunnen zien, gebruiken alle kolommen behalve die met echte uitvoer willekeurig gegenereerde getallen. Voor π- kolom, we hebben ze ook nodig. Laten we transformerenin s:
De handtekening zelf is een tupel van al deze waarden:
Deze gegevens worden vervolgens in een transactie geschreven.
Zoals we kunnen zien, bevat MLSAG slechts één uitdaging c0, waarmee u kunt besparen op de handtekeninggrootte (wat al veel ruimte in beslag neemt). Verder kan elke inspecteur gebruik maken van de gegevens, herstelt de waarden c1,…, cm en controleert dat. Zo is onze ring gesloten en is de handtekening geverifieerd.
Voor RingCT-transacties van het volledige type wordt nog een regel aan de matrix toegevoegd met gemengde output, maar daar zullen we hieronder over praten.
Pedersen toezeggingen
(de Engelse term commitments wordt vaker gebruikt) worden gebruikt zodat één partij kan bewijzen dat hij een bepaald geheim (nummer) kent zonder dit daadwerkelijk prijs te geven. Je gooit bijvoorbeeld een bepaald getal met de dobbelstenen, overweegt inzet en geeft dit door aan de verifiërende partij. Dus op het moment dat het geheime nummer wordt bekendgemaakt, berekent de verificateur onafhankelijk de verplichting, waardoor hij ervoor zorgt dat u hem niet hebt bedrogen.
Monero-toezeggingen worden gebruikt om de bedragen van de overdrachten te verbergen en gebruiken de meest gebruikelijke optie: Pedersen-toezeggingen. Trouwens, een interessant feit - in eerste instantie stelden de ontwikkelaars voor om de bedragen te verbergen door gewoon te mengen, dat wil zeggen door outputs voor willekeurige bedragen toe te voegen om onzekerheid te introduceren, maar daarna schakelden ze over op verplichtingen (het is geen feit dat ze bespaarden op de transactiegrootte, zoals we hieronder zullen zien).
Over het algemeen ziet commitment er als volgt uit:
Где C – de betekenis van toewijding zelf, a - verborgen bedrag, H is een vast punt op de elliptische curve (extra generator), en x – een soort willekeurig masker, een willekeurig gegenereerde verbergfactor. Het masker is hier nodig, zodat een derde de waarde van commitment niet zomaar kan raden.
Wanneer er nieuwe output wordt gegenereerd, berekent de portemonnee de inzet daarvoor, en wanneer deze wordt uitgegeven, wordt de waarde gebruikt die tijdens het genereren is berekend of wordt deze opnieuw berekend, afhankelijk van het type transactie.
RingCT eenvoudig
In het geval van eenvoudige RingCT-transacties is het, om ervoor te zorgen dat de transactie een output creëerde die gelijk is aan de hoeveelheid input (geen geld uit het niets opleverde), noodzakelijk dat de som van de verplichtingen van de eerste en tweede transactie dezelfde zijn, dat wil zeggen:
Commitmentcommissies zien het net iets anders – zonder masker:
Waar a — het bedrag van de commissie, dit is openbaar beschikbaar.
Met deze aanpak kunnen wij aan de vertrouwende partij bewijzen dat wij dezelfde bedragen gebruiken, zonder deze openbaar te maken.
Laten we, om het duidelijker te maken, eens naar een voorbeeld kijken. Laten we zeggen dat een transactie twee outputs uitgeeft (wat betekent dat ze inputs worden) van 10 en 5 XMR en drie outputs genereert ter waarde van 12 XMR: 3, 4 en 5 XMR. Tegelijkertijd betaalt hij een commissie van 3 XMR. Het uitgegeven geldbedrag plus het gegenereerde bedrag en de commissie zijn dus gelijk aan 15 XMR. Laten we proberen de verplichtingen te berekenen en naar het verschil in hun bedragen te kijken (onthoud de wiskunde):
Hier zien we dat we, om de vergelijking te laten convergeren, nodig hebben dat de sommen van de invoer- en uitvoermaskers hetzelfde zijn. Om dit te doen, genereert de portemonnee willekeurig x1, y1, y2 en y3, en de overige x2 berekent als volgt:
Met behulp van deze maskers kunnen we aan elke verificateur bewijzen dat we niet meer geld genereren dan we uitgeven, zonder het bedrag bekend te maken. Origineel toch?
RingCT vol
Bij volledige RingCT-transacties is het controleren van de overdrachtsbedragen iets ingewikkelder. Bij deze transacties herberekent de portemonnee de toezeggingen voor invoer niet, maar gebruikt hij de gegevens die zijn berekend toen deze werden gegenereerd. In dit geval moeten we aannemen dat we niet langer het verschil krijgen in de sommen gelijk aan nul, maar in plaats daarvan:
Hier z — verschil tussen invoer- en uitvoermaskers. Als we overwegen zG als een publieke sleutel (wat het de facto is), dan z is de privésleutel. We kennen dus de openbare en bijbehorende privésleutels. Met deze gegevens in de hand kunnen we deze gebruiken in de MLSAG-ringhandtekening, samen met de openbare sleutels van de uitvoer die worden gemengd:
Een geldige ringhandtekening zorgt er dus voor dat we alle privésleutels van een van de kolommen kennen, en we kunnen de privésleutel in de laatste rij alleen kennen als de transactie niet meer geld oplevert dan er wordt uitgegeven. Trouwens, hier is het antwoord op de vraag “waarom leidt het verschil in de bedragen van de vastleggingen niet tot nul” – als zG = 0, dan zullen we de kolom uitbreiden met echte outputs.
Maar hoe weet de ontvanger van het geld hoeveel geld er naar hem is gestuurd? Alles is hier eenvoudig: de afzender van de transactie en de ontvanger wisselen sleutels uit met behulp van het Diffie-Hellman-protocol, gebruiken de transactiesleutel en de weergavesleutel van de ontvanger en berekenen het gedeelde geheim. De afzender schrijft gegevens over de uitvoerbedragen, gecodeerd met deze gedeelde sleutel, in speciale velden van de transactie.
Bereikbewijzen
Wat gebeurt er als u een negatief getal gebruikt als bedrag aan verplichtingen? Dit kan leiden tot het genereren van extra munten! Deze uitkomst is onaanvaardbaar, dus we moeten garanderen dat de bedragen die we gebruiken niet negatief zijn (zonder deze bedragen uiteraard openbaar te maken, anders is er zoveel werk en alles tevergeefs). Met andere woorden: we moeten bewijzen dat de som in het interval ligt [0, 2n - 1].
Om dit te doen, wordt de som van elke output verdeeld in binaire cijfers en wordt de verplichting voor elk cijfer afzonderlijk berekend. Het is beter om te zien hoe dit gebeurt met een voorbeeld.
Laten we aannemen dat onze hoeveelheden klein zijn en in 4 bits passen (in de praktijk is dit 64 bits), en we creëren een uitvoer ter waarde van 5 XMR. We berekenen de verplichtingen per categorie en de totale verplichting voor het gehele bedrag:
Vervolgens wordt elke toezegging gemengd met een surrogaat (Ci-2iH) en is in paren gesigneerd met de Borromeo ringsignatuur (een andere ringsignatuur), voorgesteld door Greg Maxwell in 2015 (je kunt er meer over lezen ):
Alles bij elkaar genomen wordt dit bereikbewijs genoemd en kunt u ervoor zorgen dat toezeggingen bedragen binnen het bereik gebruiken [0, 2n - 1].
Wat is het volgende?
In de huidige implementatie nemen bereikbewijzen veel ruimte in beslag: 6176 bytes per uitvoer. Dit leidt tot grotere transacties en dus hogere kosten. Om de omvang van een Monero-transactie te verkleinen, introduceren ontwikkelaars bulletproofs in plaats van Borromeo-handtekeningen - een bereikbestendig mechanisme zonder bitsgewijze verplichtingen. , kunnen ze de omvang van het bereikbewijs tot 94% verkleinen. Trouwens, half juli ging de technologie voorbij van Kudelski Security, die geen significante tekortkomingen aan het licht bracht, noch in de technologie zelf, noch in de implementatie ervan. De technologie wordt al gebruikt in het testnetwerk en kan met de nieuwe hard fork waarschijnlijk naar het hoofdnetwerk worden verplaatst.
Stel uw vragen, stel onderwerpen voor voor nieuwe artikelen over technologieën op het gebied van cryptocurrency en abonneer u ook op onze groep om op de hoogte te blijven van onze evenementen en publicaties.
Bron: www.habr.com