Merge pull request #2497 from rsoltanzadeh/patch-1

Create intro_SE.md

doc/intro_SE.md

@@ -0,0 +1,388 @@
+# Introduktion till MimbleWimble och Grin
+
+*Läs detta på andra språk: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md).*
+
+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](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/).
+
+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](https://elementsproject.org/features/confidential-transactions/investigation),
+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](#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](https://eprint.iacr.org/2017/1066.pdf).
+
+#### 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.