From 0fc7dff0d64f4e9c5a49032441e22b3e86860a19 Mon Sep 17 00:00:00 2001 From: Ramin Soltanzadeh <36580473+rsoltanzadeh@users.noreply.github.com> Date: Thu, 31 Jan 2019 00:37:41 +0100 Subject: [PATCH] Create intro_SE.md --- doc/intro_SE.md | 388 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 388 insertions(+) create mode 100644 doc/intro_SE.md diff --git a/doc/intro_SE.md b/doc/intro_SE.md new file mode 100644 index 000000000..6947420b5 --- /dev/null +++ b/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.