Konfidentiella transaktioner i Monero, eller hur man överför okänt till okänt ställe

Vi fortsätter vår serie om hur Moneros blockkedja fungerar, och dagens artikel kommer att handla om protokollet RingCT (Ring Confidential Transactions), där konfidentiella transaktioner och nya ring-signaturer presenteras. Tyvärr finns det lite information på internet om hur det fungerar, och vi har försökt fylla detta gap.

Vi kommer att diskutera hur detta protokoll gör att nätverket döljer överföringsbeloppen, varför man avstod från de klassiska ring-signaturerna för cryptonote och hur denna teknik kommer att utvecklas i framtiden.

Eftersom detta protokoll är en av de mest komplexa teknologierna inom Monero, behöver läsaren grundläggande kunskaper om hur denna blockkedja fungerar samt ytlig kunskap inom kryptografi baserat på elliptiska kurvor (för att fräscha upp dessa kunskaper kan man läsa de första kapitlen i vår tidigare artikel om multisignaturer).

RingCT-protokollet

En möjlig attack mot cryptonote-valutor är blockkedjeanalys baserat på kunskap om beloppet och tidpunkten för den skickade transaktionen. Detta gör att man kan snäva in området för de utgångar som intresserar angriparen betydligt. För att skydda mot sådan analys har Monero implementerat ett protokoll för anonyma transaktioner som helt döljer överföringsbeloppen inom nätverket.

Det är värt att notera att idén om att dölja belopp inte är ny. En av de första som beskrev den var Bitcoin Core-utvecklaren Greg Maxwell i sin artikel Confidential Transactions. Den nuvarande implementationen av RingCT är en modifiering av denna med möjlighet att använda ring-signaturer (hur kan man klara sig utan dem), och den fick sitt namn — Ring Confidential Transactions.

Dessutom hjälper protokollet till att lösa problem med blandning av små utgångar — utgångar med en liten summa (vilket ofta uppstår i form av växel från transaktioner) som har skapat fler problem än de har varit värda.

I januari 2017 skedde en hård gaffel inom Monero-nätverket som möjliggör valfri användning av konfidentiella transaktioner. Redan i september samma år blev sådana transaktioner de enda tillåtna i nätverket efter hårdgaffeln av version 6.

RingCT använder flera mekanismer: multilayered linkable spontaneous anonymous group signatures (Multilayered Linkable Spontaneous Anonymous Group Signature, nedan — MLSAG), en åtagandeskema (Pedersen Commitments) och range proofs (det finns inget etablerat svenskt översättning av denna term).

RingCT-protokollet introducerar två typer av anonyma transaktioner: simple och full. Den första genereras av plånboken när en transaktion använder mer än en ingång, medan den andra görs i motsatt situation. De skiljer sig åt i validering av transaktionsbelopp och de data som signeras med MLSAG-signatur (mer om detta diskuteras nedan). Fulltransaktioner kan genereras med valfritt antal ingångar, det spelar ingen verklig roll. I boken «Zero to Monero» nämns att beslutet att begränsa fulltransaktioner till en ingång togs hastigt och kan komma att ändras i framtiden.

MLSAG-signatur

Låt oss påminna oss om vad de signerade ingångarna till transaktionen representerar. Varje transaktion spenderar vissa medel och genererar. Genereringen av medel sker genom att skapa utgångar från transaktionen (en direkt analogi — sedlar), och den utgång som transaktionen spenderar (eftersom vi i verkliga livet spenderar just sedlar) blir en ingång (var försiktig, här är det mycket lätt att bli förvirrad).

En ingång refererar till flera utgångar men spenderar endast en, vilket skapar en "rökdimma" för att komplicera analysen av överföringshistoriken. Om transaktionen har mer än en ingång kan denna struktur representeras i form av en matris, där raderna är ingångar och kolumnerna är involverade utgångar. För att bevisa för nätverket att transaktionen faktiskt spenderar sina egna utgångar (känner till deras hemliga nycklar) signeras ingångarna med en ring-signatur. Denna signatur garanterar att den signerande kände till de hemliga nycklarna för alla element i någon kolumn.

Konfidentiella transaktioner använder inte längre de klassiska för cryptonote ringsignaturerna, istället kom MLSAG — en anpassad version av liknande enfaldiga ringsignaturer för flera ingångar. LSAG.

De kallas flerskiktade eftersom de signerar flera ingångar samtidigt, var och en som mixas med flera andra, dvs. en matris signeras och inte bara en rad. Som vi kommer att se senare hjälper detta att spara på storleken av signaturen.

Låt oss titta på hur en ringsignatur bildas, med ett exempel på en transaktion som spenderar 2 verkliga utgångar och använder m — 1 slumpmässiga från blockkedjan för mixning. Vi betecknar de offentliga nycklarna för utgångarna vi spenderar som
, och key images för dem motsvarande: Således får vi en matris av storlek 2 x m. För att börja måste vi beräkna de så kallade utmaningarna för varje par av utgångar:

Beräkningarna inleds med utgångarna som vi spenderar, genom att använda deras publika nycklar:och slumpmässiga talTill slut får vi värden:
, som vi använder för att beräkna utmaningen
för nästa par av utgångar (för att göra det enklare att förstå vad vi sätter var, har vi markerat dessa värden med olika färger). Alla följande värden beräknas cykliskt enligt formlerna som ges i den första illustrationen. Den sista utmaningen beräknas för paret av verkliga utgångar.

Som vi ser används i alla kolumner utom den som innehåller verkliga utgångar slumpmässigt genererade tal.. För π-te kolumn behöver vi också. Vi omvandlartill s:
Själva signaturen utgörs av en körtel av alla dessa värden:

Därefter skrivs dessa data in i en transaktion.

Som vi ser innehåller MLSAG endast en utmaning c0, vilket gör att vi kan spara på storleken av signaturen (som redan kräver mycket plats). Därefter återställer varje verifierare, genom att använda data, värdena c1,…, cm och kontrollerar att. Således har vår ring slutit sig och signaturen har passerat verifieringen.

För RingCT-transaktioner av typen full läggs en extra rad till matrisen med blandade utgångar, men vi kommer att berätta mer om det senare.

Pedersen Commitments

Commitments-schema (den engelska termen — commitments används oftare) används för att en part ska kunna bevisa att den känner till en viss hemlighet (nummer), utan att avslöja den. Till exempel kastar du ett visst nummer med tärningen, beräknar commitment och överlämnar det till den verifierande parten. Därmed, vid tidpunkten för avslöjandet av det hemliga numret, beräknar den verifierande parten själv commitment och försäkrar sig om att du inte har lurat dem.

I Monero används commitments för att dölja summor av överföringar och tillämpar den mest vedertagna varianten — Pedersen commitments. För övrigt en intressant detalj — initialt föreslog utvecklarna att dölja summor genom vanlig blandning, det vill säga att lägga till utgångar på slumpmässiga summor för att introducera osäkerhet, men de övergick sedan till commitments (utan att det är säkert att de sparade på storleken av transaktionen, som vi kommer att se nedan).
I allmänhet ser en commitment ut på följande sätt:
Där C — värdet av själva commitmenten, a — den dolda summan, H — en fast punkt på en elliptisk kurva (en ytterligare generator), och x — någon slags godtycklig mask, en dolda faktorn som genereras slumpmässigt. Masken behövs här för att en tredje part inte enkelt ska kunna gissa värdet av commitment genom att pröva olika alternativ.

Vid generering av en ny utgång beräknar plånboken commitment för den, och vid utgifter antingen använder det beräknade värdet eller omberäknar det — beroende på typ av transaktion.

RingCT simple

I fallet med simple RingCT-transaktioner måste vi för att garantera att transaktionen skapar utgångar som summerar till ingångarnas summa (inte skapar pengar ur intet) se till att summan av commitments för den första och andra är densamma, det vill säga:

Commitment av avgifter beräknas lite annorlunda — utan mask:
, där a — summan av avgiften är offentligt tillgänglig.

Denna metod gör det möjligt att bevisa för den kontrollerande parten att vi använder samma summor utan att avslöja dem.

För att göra allt tydligare, låt oss titta på ett exempel. Anta att transaktionen använder två utgångar (det vill säga de blir ingångar) på 10 och 5 XMR och generar tre utgångar på totalt 12 XMR: 3, 4 och 5 XMR. Under tiden betalar den en avgift på 3 XMR. Således är summan av använda medel plus summan av genererade medel och avgiften lika med 15 XMR. Låt oss försöka beräkna commitments och titta på skillnaden i deras summor (låt oss minnas matematiken):

Här ser vi att för att ekvationen ska gå ihop behövs summorna av maskerna för ingångarna och utgångarna vara lika. För detta genererar plånboken slumpmässigt x1, y1, y2 och y3, medan den återstående x2 beräknas så här:

Genom att använda dessa masker kan vi bevisa för någon kontrollerande att vi inte genererar mer medel än vi spenderar, utan att avslöja summorna. Originalt, eller hur?

RingCT full

I full RingCT-transaktioner är kontrollen av överföringsbeloppen något mer invecklad. I dessa transaktioner omberäknar plånboken inte commitments för ingångarna, utan använder de som beräknades vid deras generering. Här måste vi räkna med att skillnaden mellan summorna inte längre blir noll, utan istället:

Här z — skillnaden mellan maskerna för ingångar och utgångar. Om vi ser på zG som en offentlig nyckel (vilket det de facto är), så z — detta är den privata nyckeln. Således känner vi till den offentliga och motsvarande privata nycklarna. Med dessa uppgifter kan vi använda dem i MLSAG-ringunderteckningen tillsammans med de offentliga nycklarna för de blandade utgångarna:

Därför kommer en giltig ringunderteckning att garantera att vi känner till alla privata nycklar för en av kolumnerna, och den privata nyckeln i den sista raden kan vi endast känna till om transaktionen inte genererar mer medel än den spenderar. Förresten, här är svaret på frågan «varför här skillnaden mellan summorna commitments inte ger noll» — om zG = 0, så kommer vi att avslöja kolumnen med verkliga utgångar.

Men hur kommer mottagaren av medlen att veta hur mycket pengar de har fått? Här är allt enkelt — avsändaren av transaktionen och mottagaren utbyter nycklar enligt Diffie-Hellman-protokollet, använder transaktionsnyckeln och mottagarens view-nyckel och beräknar en gemensam hemlighet. Avsändaren skriver in uppgifter om utgångssummorna i särskilda fält i transaktionen, krypterade med denna gemensamma nyckel.

Intervallbevis

Vad händer om vi använder ett negativt tal som summa i commitments? Det kan leda till generering av ytterligare mynt! Denna utgång är oacceptabel, så vi behöver en garanti för att de summor vi använder inte är negativa (utan att avslöja dessa summor, naturligtvis, annars skulle all den här ansträngningen vara förgäves). Med andra ord, vi måste bevisa att summan ligger inom intervallet [0, 2n — 1].

För detta delas summan av varje utgång upp i binära siffror och en commitment beräknas för varje siffra separat. Hur detta går till är bäst att betrakta i ett exempel.

Anta att våra summor är små och får plats i 4 bitar (i praktiken är det 64 bitar), och vi skapar en utgång på 5 XMR. Vi beräknar commitments för varje siffra och total commitment för hela summan:
Därefter blandas varje commitment med en surrogat- (Ci-2iH) och undertecknas parvis med en Borromeo-ringunderteckning (ännu en ringunderteckning), föreslagen av Greg Maxwell 2015 (mer om den kan läsas här):
Allt detta kallas intervallbevis och möjliggör en garanti för att summorna i commitments ligger inom intervallet [0, 2n — 1].

Vad händer härnäst?

I den nuvarande implementeringen tar range proofs upp väldigt mycket utrymme — 6176 byte per utgång. Detta leder till stora transaktioner och därmed högre avgifter. För att minska storleken på transaktionen inför Monero-utvecklarna istället för Borromeo-signaturer bulletproofs — en mekanism för range proof utan bitvisa commitments. Enligt vissa uppskattningar, kan de minska storleken på range proof med upp till 94%. Som en notis, i mitten av juli genomgick teknologin revision av företaget Kudelski Security, som inte påvisade några betydande brister varken i teknologin eller dess implementation. Teknologin används redan i testnätet och kan, med den nya hårdgaffeln, troligtvis flyttas över till huvudnätet.

Ställ dina frågor, föreslå ämnen för nya artiklar om teknologi inom kryptovalutor och följ vår grupp på Facebook, för att hålla dig uppdaterad om våra evenemang och publikationer.

Källa: habr.com