grin/doc/intro_SE.md

Introduktion till MimbleWimble och Grin

Läs detta på andra språk: English, 简体中文, Español, Nederlands, Русский, 日本語, Deutsch, Portuguese, Korean.

MimbleWimble är ett blockkedjeformat och protokoll som erbjuder extremt bra skalbarhet, integritet, och fungibilitet genom starka kryptografiska primitiver. Den angriper brister som existerar i nästan alla nuvarande blockkedjeimplementationer.

Grin är ett mjukvaruprojekt med öppen källkod som implementerar en MimbleWimble-blockkedja och fyller igen luckorna för att skapa en fullständig blockkedja och kryptovaluta.

Grin-projektets huvudsakliga mål och kännetecken är:

• Integritet som standard. Detta möjliggör fullkomlig fungibilitet utan att förhindra förmågan att selektivt uppdaga information efter behov.
• Växer mestadels med antal användare och minimalt med antal transaktioner (< 100 bytes transaktionskärna), vilket resulterar i stora utrymmesbesparingar i jämförelse med andra blockkedjor.
• Stark och bevisad kryptografi. MimbleWimble förlitar sig endast på kryptografi med elliptiska kurvor (ECC) vilket har beprövats i decennier.
• Simplistik design som gör det enkelt att granska och underhålla på lång sikt.
• Gemenskapsdriven, uppmuntrar mining och decentralisering.

Tungknytande för alla

Detta dokument är riktat mot läsare med en bra förståelse för blockkedjor och grundläggande kryptografi. Med det i åtanke försöker vi förklara den tekniska uppbyggnaden av MimbleWimble och hur det appliceras i Grin. Vi hoppas att detta dokument är föreståeligt för de flesta tekniskt inriktade läsare. Vårt mål är att uppmuntra er att bli intresserade i Grin och bidra på något möjligt sätt.

För att uppnå detta mål kommer vi att introducera de huvudsakliga begrepp som krävs för en bra förståelse för Grin som en MimbleWimble-implementation. Vi kommer att börja med en kort beskrivning av några av elliptiska kurvornas relevanta egenskaper för att lägga grunden som Grin är baserat på och därefter beskriva alla viktiga element i en MimbleWimble-blockkedjas transaktioner och block.

Småbitar av elliptiska kurvor

Vi börjar med en kort undervisning i kryptografi med elliptiska kurvor (ECC) där vi endast går igenom de nödvändiga egenskaper för att förstå hur MimbleWimble fungerar utan att gå djupt in på dess krångligheter. För läsare som vill fördjupa sig i detta finns andra möjligheter att lära sig mer.

En elliptisk kurva för kryptografiska är ändamål är enkelt sagt en stor mängd av punkter som vi kallar för C. Dessa punkter kan adderas, subtraheras, eller multipliceras med heltal (även kallat skalärer). Given ett heltal k kan vi beräkna k*H med skalärmultiplikation, vilket också är en punkt på kurvan C. Given ett annat heltal j kan vi också beräkna (k+j)*H, vilket är lika med k*H + j*H. Addition och skalärmultiplikation på elliptiska kurvor behåller sina kommutativa och associativa egenskaper från vanlig addition och multiplikation:

(k+j)*H = k*H + j*H

Inom ECC, om vi väljer ett väldigt stort tal k som privat nyckel så anses k*H vara dess publika nyckel. Även om man vet värdet av den publika nyckeln k*H, är det nästintill omöjligt att härleda k (sagt med andra ord, medan multiplikation är trivialt är "division" med kurvpunkter extremt svårt).

Den föregående formeln (k+j)*H = k*H + j*H, med k och j båda privata nycklar demonstrerar att en publik nyckel erhållen av att ha adderat de två privata nycklarna är identisk med de två privata nycklarnas respektive publika nycklar adderade (k*H + j*H). I Bitcoin-blockkedjan använder hierarkiska deterministiska plånböcker (HD wallets) sig flitigt av denna princip. MimbleWimble och Grin-implementationer gör det också.

Transaktioner med MimbleWimble

Transaktionernas struktur demonstrerar en av MimbleWimbles kritiska grundsatser: starka garantier av integritet och konfidentialitet.

Valideringen av MimbleWimble-transaktioner använder sig av två grundläggande egenskaper:

• Kontroll av nollsummor. Summan av utmatningar minus inmatningar är alltid lika med noll, vilket bevisar—utan att avslöja beloppen—att transaktionen inte skapade nya pengar.
• Innehav av privata nycklar. Som med de flesta andra kryptovalutar garanteras ägandet av transaktionsutmatningar med innehavet av privata nycklar. Dock bevisas inte ägandet av dem genom en direkt signering av transaktionen.

De följande styckena angående saldo, ägande, växel, och bevis klarlägger hur de två grundläggande egenskaperna uppnås.

Saldo

Bygger vi på ECC-egenskaperna vi förklarade ovan kan vi beslöja beloppen i en transaktion.

Om v är beloppet av en inmatning eller utmatning i en transaktion och H en elliptisk kurva, kan vi enkelt bädda in v*H i stället för v i en transaktion. Detta fungerar eftersom vi fortfarande kan bekräfta att summan av utmatningarna är lika med summan av inmatningarna i en transaktion med hjälp av ECC-operationer:

v1 + v2 = v3 => v1*H + v2*H = v3*H

Bekräftandet av denna egenskap på alla transaktioner låter protokollet bekräfta att en transaktion inte skapar pengar ur tomma intet utan att veta vad beloppen är. Dock finns det ett begränsat antal av användbara belopp och man skulle kunna prova varenda en för att gissa beloppet på din transaktion. Dessutom, om man känner till v1 (till exempel från en föregående transaktion) och det resulterande v1*H avslöjar man alla utmatningar med beloppet v1 över hela blockkedjan. Av dessa anledningar introducerar vi en till elliptisk kurva G (i praktiken är G endast en annan generatorpunkt på samma kurvgrupp som H) och en privat nyckel r som används som en bländande faktor.

Ett inmatnings- eller utmatningsbelopp i en transaktion kan uttryckas som:

r*G + v*H

Där:

• r är en privat nyckel använd som en bländande faktor, G är en elliptisk kurva, och deras produkt r*G är den publika nyckeln för r på G.
• v är ett inmatnings- eller utmatningsbelopp och H är en annan elliptisk kurva.

Varken v eller r kan härledas på grund av ECC:s grundläggande egenskaper. r*G + v*H kallas för ett Pedersen Commitment.

Som ett exempel, låt oss anta att vi vill skapa en transaktion med två inmatningar och en utmatning. Vi har (utan hänsyn till avgifter):

• vi1 och vi2 som inmatningsbelopp.
• vo3 som utmatningsbelopp.

Sådana att:

vi1 + vi2 = vo3

Vi genererar en privat nyckel som en bländande faktor för varje inmatningsbelopp och ersätter alla belopp med deras respektive Pedersen Commitment och ekvationen blir därmed:

(ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vi3*H)

Vilket som följd kräver att:

ri1 + ri2 = ro3

Detta är MimbleWimbles första pelare: de beräkningar som är nödvändiga för att validera en transaktion kan göras utan att veta några belopp.

Denna idé härstammar faktiskt från Greg Maxwells Confidential Transactions, som i sin tur härstammar från ett förslag av Adam Back för homomorfiska belopp applicerade på Bitcoin.

Ägande

I föregående stycke introducerade vi en privat nyckel som en bländande faktor för att dölja transaktionens belopp. MimbleWimbles andra insikt är att denna privata nyckel kan användas för att bevisa ägande av beloppet.

Alice skickar 3 mynt till dig och för att dölja beloppet väljer du 28 som din bländande faktor (notera att i praktiken är den bländande faktorn ett extremt stort tal). Någonstans i blockkedjan dyker följande utmatning upp och ska endast vara spenderbar av dig:

X = 28*G + 3*H

X som är resultatet av additionen är synlig för alla. Beloppet 3 är endast känt av dig och Alice, och 28 är endast känt av dig.

För att skicka dessa 3 mynt igen kräver protokollet att 28 ska vara känt. För att demonstrera hur detta fungerar, låt oss säga att du vill skicka samma 3 mynt till Carol. Du behöver skapa en simpel transaktion sådan att:

Xi => Y

Där Xi är en inmatning som spenderar din X-utmatning och Y är Carols utmatning. Det finns inget sätt att skapa en sådan transaktion utan att känna till din privata nyckel 28. Om Carol ska balansera denna transaktion behöver hon både känna till det skickade beloppet och din privata nyckel så att:

Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H

Genom att kontrollera att allt har nollställts kan vi återigen försäkra oss om att inga nya pengar har skapats.

Vänta! Stopp! Nu känner du till den privata nyckeln i Carols utmatning (vilket i detta fall måste vara samma som ditt för att balansera in- och utmatningarna) så du skulle kunna stjäla tillbaka pengarna från Carol!

För att lösa detta problem använder Carol en privat nyckel som hon väljer själv. Låt oss säga att hon väljer 113. Det som hamnar i blockkedjan är:

Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H

Nu summeras transaktionen inte längre till noll och vi har ett överskottsbelopp på G (85), vilket är resultatet av summeringen av alla bländande faktorer. Men eftersom 85*G är en giltig publik nyckel på elliptiska kurvan G vet vi att in- och utmatningarna har subtraheras till noll och transaktionen är därmed giltig.

Så allt protokollet behöver göra är att kontrollera att (Y - Xi) är en giltig publik nyckel på G och att de två parter som utför transaktionen tillsammans kan producera den privata nyckeln (85 i exemplet ovan). Det enklaste sättet att göra det är att kräva en signatur med överskottsbeloppet (85), vilket bekräftar att:

• De parter som utför transaktionen känner till den privata nyckeln, och
• Summan av utmatningarna minus inmatningarna i transaktionen är noll (eftersom överskottsbeloppet måste vara en publik nyckel).

Denna signatur som tillsammans med lite annan information (som exempelvis mining-avgifter) bifogas till transaktionen kallas för transaktionskärna och kontrolleras av alla validerare.

Några finare punkter

Detta stycke detaljerar byggandet av transaktioner genom att diskutera hur växel införs och kravet för "range proofs" så att alla belopp är bevisade att vara icke-negativa. Inget av detta är absolut nödvändigt för att förstå MimbleWimble och Grin, så om du har bråttom känn dig fri att hoppa direkt till Sammanställningen av allt.

Växel

Låt oss säga att du endast vill skicka 2 mynt till Carol av de 3 mynt du mottog från Alice. För att göra detta behöver du skicka det återstående myntet tillbaka till dig själv som växel. Du genererar en annan privat nyckel (t ex 12) som en bländande faktor för att skydda ditt växel-utmatningsbelopp. Carol använder sin egen privata nyckel som tidigare.

Växel-utmatning:   12*G + 1*H
Carols utmatning:  113*G + 2*H

Det som hamnar i blockkedjan är något väldigt likt det vi hade tidigare, och signaturen är återigen skapat med överskottsbeloppet, 97 i detta exempel.

(12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H

Range Proofs

I alla beräkningar ovan förlitar vi oss på att alla belopp är positiva. Introduktionen av negativa belopp skulle vara extremt problematiskt då man skulle kunna skapa nya pengar i varje transaktion.

Till exempel skulle man kunna skapa en transaktion med inmatningen 2 och utmatningar 5 och -3 och fortfarande ha en balanserad transaktion. Detta kan inte upptäcklas enkelt eftersom punkten x*H ser ut som vilken annan punkt som helst på kurvan även om x är negativt.

För att lösa detta problem använder MimbleWimble sig av ett kryptografiskt koncept som kallas "range proofs" (som också härstammar från Confidential Transactions): ett bevis på att ett tal befinner sig inom ett visst intervall utan att avsölja talet. Vi kommer inte att förklara range proofs; du behöver endast veta att för varje r*G + v*H kan vi skapa ett bevis som visar att v är större än noll och inte orsakar overflow.

Det är även viktigt att notera att både värdet 113 och värdet 28 måste vara kända för att kunna skapa ett giltigt range proof. Anledningen till detta och en mer utförlig beskrivning av range proofs är förklarat i range proof-pappret.

Sammanställningen av allt

En MimbleWimble-transaktion inkluderar följande:

• En mängd inmatningar som refererar till och spenderar en mängd föregående utmatningar.
• En mängd nya utmatningar som inkluderar:
  • Ett belopp och en bländande faktor (vilket bara är en ny privat nyckel) multiplicerade på en kurva och adderade till att bli r*G + v*H.
  • Ett range proof som visar att v är icke-negativt.
• En tydlig transaktionsavgift i klartext.
• En signatur vars privata nyckel beräknas genom att ta överskottsbeloppet (summan av alla utmatningar och avgiften minus inmatningarna).

Block och kedjetillstånd

Vi förklarade ovan hur MimbleWimble-transaktioner kan erbjuda starka anonymitetsgarantier samtidigt som de upprätthåller egenskaperna för en giltig blockkedja, d.v.s en transaktion skapar inte pengar och ägandebevis är fastställt med privata nycklar.

MimbleWimble-blockformatet bygger på detta genom att introducera ett till koncept: genomskärning. Med detta får en MimbleWimble-kedja:

• Extremt bra skalbarhet då den stora majoriteten av transaktionsinformation kan elimineras på lång sikt utan att kompromissa säkerhet.
• Ytterligare anonymitet genom att blanda och ta bort transaktionsinformation.
• Förmågan att effektivt synkronisera sig med resten av nätverket för nya noder.

Transaktionsaggregation

Kom igåg att en transaktion består av följande:

• En mängd inmatningar som refererar till och spenderar en mängd föregående utmatningar
• En mängd nya utmatningar (Pedersen commitments)
• En transaktionskärna som består av:
  • överskottsbelopp
  • transaktionssignatur

En transaktion signeras och signaturen inkluderas i en transaktionskärna. Signaturen genereras genom att använda överskottsbeloppet som en publik nyckel för att bevisa att beloppen summeras till 0:

(42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H

Den publika nyckeln i detta exempel är 28*G.

Vi kan säga att följande är sant för alla giltiga transaktioner (vi ignorerar avgifter för enkelhetens skull):

summa(utmatningar) - summa(inmatningar) = överskottsbelopp

Detsamma gäller för blocken själva när vi inser att ett block helt enkelt är en mängd aggregerade inmatningar, utmatningar, och transaktionskärnor. Vi kan summera transaktionsutmatningarna, subtrahera summan av transaktionsinmatningarna, och jämföra det resulterande Pedersen commitment med summan av överskottsbeloppen:

summa(utmatningar) - summa(inmatningar) = summa(överskottsbelopp)

Något förenklat, (återigen ignorerar vi transaktionsavgifter) kan vi säga att MimbleWimble-block kan betraktas precis som MimbleWimble-transaktioner.

Kärn-offset

Det finns ett subtilt problem med MimbleWimble-block och transaktioner som beskrivet ovan. Det är möjligt (och i vissa fall trivialt) att rekonstruera de konstituerande transaktionerna i ett block. Detta är naturligtvis dåligt för integriteten. Detta är "delmängdsproblemet": given en mängd inmatningar, utmatningar, och transaktionskärnor kommer någon delmängd av detta kunna kombineras för att rekonstruera en giltig transaktion.

Till exempel, vi har följande två transaktioner:

(inmatning1, inmatning2) -> (utmatning1), (kärna1)
(inmatning3) -> (utmatning2), (kärna2)

Vi kan aggregera dem till följande block:

(inmatning1, inmatning2, inmatning3) -> (utmatning1, utmatning2), (kärna1, kärna2)

Det är trivialt att testa alla möjliga kombinationer och återskapa en av transaktionerna (där summan lyckas bli noll).

(inmatning1, inmatning2) -> (utmatning1), (kärna1)

Vi vet också att allt som kvarstår kan användas för att rekonstruera den andra giltiga transaktionen:

(inmatning3) -> (utmatning2), (kärna2)

För att mildra detta inkluderar vi ett kärn-offset med varje överskottsbelopp. Detta är en bländande faktor som måste tilläggas överskottsbeloppet för att verifiera att det summeras till noll:

summa(utmatningar) - summa(inmatningar) = överskottsbelopp + kärn-offset

Vi "separerar" nyckeln k till k1 + k2 under transaktionsbyggandet. För ett överskottsbelopp (k1+k2)*G publicerar vi k1*G (överskottet) och k2 (offset) och signerar transaktionen med k1*G som tidigare. Under block-konstruktionen kan vi enkelt summera alla k2-offset för att generera ett aggregat-offset för alla transaktioner i blocket. k2-offsetet för en individuell transaktion är omöjlig att få fram.

Genomskärning

Blocks låter miners sätta ihop flera transaktioner till en enstaka mängd som läggs till på kedjan. I följande block-representationer som innerhåller tre transaktioner visar vi endast in- och utmatningarna. Inmatningar refererar till föregående utmatningar som de spenderar. Föregående utmatningar markeras med x.

I1(x1) --- O1
        |- O2
        
I2(x2) --- O3
I3(O2) -|

I4(O3) --- O4
        |- O5

Vi lägger märke till följande två egenskaper:

• Inom detta block är vissa utmatningar spenderade direkt av inkluderade inmatningar (I3 spenderar O2, och I4 spenderar O3).
• Transaktionernas struktur spelar faktiskt ingen roll. Eftersom alla transaktioner individuellt summeras till noll måste summan av alla transaktionsinmatningar och utmatningar summera till noll.

Liknande en transaktion, allt som behöver kontrolleras i ett block är att ägandebevis (vilket kommer från transaktionskärnorna) och att blocket i helhet inte skapade pengar ur tomma intet. Således kan matchande inmatningar och utmatningar elimineras, då deras sammansatta påverkan är noll. Detta leder till följande, mycket mer kompakta block:

I1(x1) | O1
I2(x2) | O4
       | O5

Notera att all transaktionsstruktur har eliminerats och att ordningen av in- och utmatningar inte längre spelar någon roll. Summan av alla in- och utmatningar garanteras fortfarande vara noll.

Ett block består av:

• En block-header.
• En lista av alla inmatningar som kvarstår efter genomskärning.
• En lista av alla utmatningar som kvarstår efter genomskärning.
• Ett enstaka kärn-offset som skyddar hela blocket.
• Transaktionskärnor för varje transaktion som innehåller:
  • Publika nyckeln r*G erhållen genom summation av alla commitments.
  • Signaturerna genererade genom överskottsbeloppet.
  • Mining-avgiften

Med denna struktur erbjuder ett MimbleWimble-block extremt bra integritetsgarantier:

• Mellanliggande transaktioner är endast representerade av sina transaktionskärnor.
• Alla utmatningar ser likadana ut: väldigt stora tal som inte går att skilja åt på något meningsfullt sätt. Om någon vill exkludera en specifik utmatning är de tvungna att exkludera alla.
• All transaktionsstruktur har borttagits vilket gör det omöjligt att se vilka in- och utmatningar som passar ihop.

Men ändå kan allting valideras!

Genomskärning hela vägen

Vi går tillbaka till blocket i föregående exempel. Utmatningarna x1 och x2 som spenderades av I1 och I2 måste ha dykt upp tidigare i blockkedjan. Efter att detta block adderas till blockkedjan kan de utmatningarna tillsammans med I1 och I2 alla tas bort från blockkedjan eftersom de nu är mellanliggande transaktioner.

Vi slutleder att kedjetillståndet kan (bortsett från block-headers) vid varje tidspunkt sammanfattas med endast dessa tre ting:

1. Den totala mängden mynt skapade genom mining.
2. Den kompletta mängden av oförbrukade utmatningar (UTXO).
3. Transaktionskärnorna för varje transaktion.

Det första kan härledas genom att endast observera block-höjden.

Både mängden av oförbrukade utmatningar och transaktionskärnorna är extremt kompakta. Detta har två följder:

• En nod i en MimbleWimble-blockkedja får en väldigt liten kedja att behöva ta vara på.
• När en ny nod ansluter sig till närverket krävs det väldigt lite information för att den ska bygga kedjan.

Dessutom kan man inte manipulera mängden av de oförbrukade utmatningarna. Tar man bort ett element ändras summan av de bländande faktorerna och in- och utmatningarna matchar inte längre varandra.

Slutsats

I detta dokument gick vi igenom de grundläggande principerna för en MimbleWimble-blockkedja. Genom att använda egenskaperna för addition i kryptografi med elliptiska kurvor kan vi skapa fullständigt förmörkade transaktioner som ändå kan valideras. Genom att generalisera dessa egenskaper till block kan vi eliminera en stor mängd blockkedjeinformation vilket medför väldigt bra skalbarhet.