Mimblewimble-transaktioner förklaras

Översikt på hög nivå
Transaktioner förklarade
Transaktionsverifiering och spridning
Stoppa bedrägeri
Transaktionsöversikt
Referensprojekt
bidragsgivare

Översikt på hög nivå

Mimblewimble är en integritetsorienterad, kryptovalutateknologi. Det skiljer sig från Bitcoin på några nyckelområden:

Inga adresser. Begreppet Mimblewimble-adresser existerar inte.
Helt privat. Varje transaktion är konfidentiell.
Kompakt blockchain. Mimblewimble använder en annan uppsättning säkerhetsgarantier än Bitcoin, vilket leder till en mycket mer kompakt blockkedja.

Transaktioner förklarade

Konfidentiella transaktioner [1] uppfanns av Dr. Adam Back och är anställda i flera kryptovalutaprojekt, inklusive Monero och Tari - genom Mimblewimble.

Mottagare av Tari skapar de privata nycklarna för att ta emot mynt i farten. Därför måste de vara involverade i konstruktionen av en Tari-transaktion.

Detta betyder inte nödvändigtvis att mottagarna måste vara online. Men de måste kunna kommunicera, oavsett om det är via e-post, snabbmeddelanden (IM) eller brevduva.

Vi kommer att förklara hur Alice kan skicka Tari till Bob med hjälp av ett tvåpartsprotokoll för Mimblewimble. Flerpartstransaktioner liknar varandra, men informationsflödet är lite annorlunda och sker över ytterligare kommunikationsrundor.

Låt oss säga att Alice har 300 µT och hon vill skicka 200 µT till Bob.

Här är den grundläggande transaktionen:

ingångar	Utgångarna
300	200	90	10
Alices UTXO	Till Bob	byta	avgift

Om vi skriver detta som en matematisk ekvation, där utdata är positiva och ingångar är negativa, borde vi kunna balansera saker så att det inte skapas mynt ur tomma intet:

$$ -300 + 200 + 90 + 10 = 0 $$

Detta är i princip informationen som sitter i Bitcoin blockchain. Vem som helst kan granska någon annans transaktioner helt enkelt genom att inspektera den globala huvudbokens transaktionshistorik. Det här är inte bra för integriteten.

Det är här konfidentiella transaktioner kommer in. Vi kan börja med att multiplicera båda sidorna av föregående ekvation med någon generatorpunkt H på den elliptiska kurvan (för en introduktion till matematik för elliptiska kurvor, se denna presentation):

$$ 300.H = 200.H + 90.H + 10.H $$

Eftersom H är en konstant, matematiken ovan gäller fortfarande, så vi kan bekräfta att Alice inte stjäl genom att kontrollera att

$$(3.H) - (2.H) - (1.H) - (fH) \ekvivalent 0.H = 0 $$

Lägg märke till att vi se bara publika nycklar och därmed är värdena dolda. Häftigt!

Tekniskt sett är endast skalära heltalsvärden giltiga för elliptisk kurvmultiplikation. Det är därför vi använder µT i transaktionerna så att beloppen alltid är heltal.

Det finns dock en hake. Om _H_ är konstant och känd (det är den), kunde inte någon bara förberäkna $nH$ för alla rimliga värden på _n_ och skanna blockkedjan efter dessa publika nycklar?^{[^a]}

Kortfattat, ja. Så vi är inte klara än.

"Detta kallas en pre-image attack."

Blindingsfaktorer

För att förhindra att en förebildsattack avblindar alla värden i Tari-transaktioner, måste vi lägga till slumpmässighet till varje ingång och utdata. Grundidén är att göra detta genom att lägga till en andra offentlig nyckel till varje transaktionsutdata.

Så om vi skriver om ingångarna och utgångarna enligt följande:

$$ C_i = n_i.H + k_i.G $$

var G är en annan generator på samma kurva, detta helt persienner ingångarna och utgångarna så att ingen förebildsattack är möjlig. Denna formulering kallas a Pedersen engagemang [3].

De två generatorerna, _H_ och _G_ måste väljas på ett sätt så att det är omöjligt att konvertera värden från en generator till den andra [[2]]. Specifikt, om _G_ är basgeneratorn, så finns det några _k_ där $$ H = kG $$

Om någon kan lista ut detta k, faller hela säkerheten för konfidentiella transaktioner isär. Det lämnas som en övning för läsaren att ta reda på varför.

För en halv skonsam introduktion till dessa begrepp är Adam Gibsons artikel i ämnet utmärkt [5].

Alice förbereder en transaktion

Alice kan nu börja bygga en transaktion.

Typ	Formel	Namn
Ingång	$$ -300.H - k_1.G $$	C1
Ändra utgång	$$ 90.H + k_2.G $$	C2
Avgift	$$ 10,H + 0,G $$	f
Totalt spenderat	$$ 200,H + 0,G $$	C*
Sum	$$ 0.H + (k_2-k_1).G $$	X

$ k_i $-värdena, $k_1, k_2$ är utgiftsnycklarna för dessa utdata.

Den _enda informationen du behöver för att spendera Tari-utdata_ är utgiftsnyckeln (även kallad en bländande faktor) och dess tillhörande värde.

Därför för denna transaktion skulle Alices plånbok, som spårar alla hennes outnyttjade Tari-utdata, ha gett den bländande faktorn och värdet "300" för att fullborda åtagandet C1.

Lägg märke till att när alla ingångar och utgångar summeras (inklusive avgiften), avbryts alla värden till noll, som de borde. Lägg också märke till att den enda termen som är kvar multipliceras med punkten G. Alla H villkor är borta. Vi kallar denna summa för offentligt överskott för Alices del av transaktionen.

Vi definierar överskott av transaktionen

$$ x_s = k_2 - k_1 $$

Ett enkelt sätt för Alice att beräkna sitt överskott (och hur Tari-plånboken gör det) är att summera sina blindningsfaktorer för produktionen och minus summan av hennes inmatade blindningsfaktorer.

Låt oss säga att Alice försökte skapa lite pengar åt sig själv och gjorde ändringen 100 µT istället för 90. I det här fallet skulle summan av utdata och ingångar inte avbrytas på H och det skulle vi ha

$$X^* = 10.H + x_s.G$$

Vi får se om en stund hur Mimblewimble-protokollet fångar Alice ut om hon försöker dra på sig såna här sken.

Alice förbereder faktiskt också ett avståndsbevis för varje utgång, vilket är ett bevis på att värdet på utgången är mellan noll och 2^64 µT. Utan räckviddsbevis kunde Alice skicka negativa belopp till människor, berika sig själv och inte bryta någon av Taris bokföring.

I Tari och Grin är övervärdet faktiskt uppdelat i två värden för ökad integritet. Grin-laget har en bra förklaring till varför detta "offset"-värde är nödvändigt [[4]]. Vi lämnar detta steg för att hålla förklaringen enkel(r).

Alice väljer också en slumpmässig nuncio,

$$ r_a $$

och beräknar motsvarande offentliga nonce,

$$ R_a = r_a.G $$

Alice skickar sedan följande information till Bob:

Fält	Värde
ingångar	C1
Utgångarna	C2
Avgift	10
Belopp som betalats till Bob	200
Offentlig nonce	$$ R_a $$
Offentligt överskott	X
metadata	m

Meddelandets metadata är några extra bitar av information som hänför sig till transaktionen (t.ex. när utdata kan spenderas).

Bob förbereder sitt svar

Bob får denna information och börjar sedan slutföra sin del av transaktionen.

Först kan han verifiera att Alice har skickat över korrekt information genom att kontrollera att det offentliga överskottet, X, är korrekt genom att följa samma procedur som Alice använde för att beräkna det ovan. Detta steg är inte strikt nödvändigt, eftersom han inte har tillräckligt med information för att upptäcka något bedrägeri vid denna tidpunkt.

Han bygger sedan ett engagemang från amount fält som Alice skickar till honom:

$$ C_b = 200.H + k_b.G $$

där $k_b$ är Bobs privata utgiftsnyckel. Han räknar

$$P_b = k_b.G$$

och genererar ett räckviddsbevis för engagemanget.

Bob måste sedan skriva under på att han är glad över att allt är komplett till hans belåtenhet. Han skapar en partiell Schnorr signatur med utmaningen,

$$ e = H(R_a + R_b \Vert X + P_b \Vert f \Vert m) $$

och signaturen ges av

$$ s_b = r_b + ek_b $$

Bob skickar tillbaka

Fält	Värde
Output (åtagande och räckviddssäker)	$$C_b$$
Offentlig nonce	$$R_b$$
namnteckning	$$s_b$$
Offentlig nyckel	$$P_b$$

Alice slutför och sänder transaktionen

Efter att ha hört tillbaka från Bob kan Alice avsluta saker.

För det första kan hon nu använda Bobs offentliga nonce och offentliga nyckel för att självständigt beräkna samma utmaning som Bob signerade:

$$ e = H(R_a + R_b \Vert X + P_b \Vert f \Vert m) $$

Alice skapar sedan både sin egen partiella signatur,

$$ s_a = r_a + e.x_s $$

och den kombinerade aggregatsignaturen, $$ s = s_a + s_b, R = R_a + R_b $$.

Alice kan nu sända denna transaktion till nätverket. Den slutliga transaktionen ser ut som följer:

Transaktionskärna
Offentligt överskott	$$ X + P_b $$
namnteckning	$$ (s, R) $$
Avgift	10
Transaktionsmetadata	m

Transaktionskropp
Ingångar med räckviddsbevis	$$[C_1]$$
Utgångar med räckviddsbevis	$$[C_2, C_B]$$

Transaktionsverifiering och spridning

När en full nod tar emot Alices transaktion måste den verifiera att den är på nivån innan den skickas vidare till sina kamrater. Noden vill kontrollera följande:

Alla ingångar kommer från den aktuella UTXO-uppsättningen

Alla fullständiga noder håller reda på mängden outnyttjade utdata, så noden kommer att kontrollera det C1 finns i den listan.
Alla utgångar har ett giltigt räckviddsbevis

Räckviddsbeviset verifieras mot dess matchande åtagande.
Värdena balanserar

I denna kontroll vill noden se till att inga mynt skapas eller förstörs i transaktionen. Men hur kan den göra detta om värdena är förblindade?

Kom ihåg att i en ärlig transaktion, alla värden (som multipliceras med H) avbryt, och du är kvar med summan av de publika nycklarna för utgångarna minus de publika nycklarna för ingångarna. Detta råkar av en slump vara samma värde som lagras i kärnan som det offentliga överskottet.

De sammanfattade offentliga meddelandena, R lagras också i kärnan, så detta tillåter noden att verifiera signaturen genom att kontrollera följande, där utmaningen e beräknas som tidigare:

$$ sG \stackrel{?}{=} R + e(X + P_b) $$

Signaturen i kärnan är giltig

Genom att validera kärnsignaturen bevisar vi därför också för oss själva att transaktionsredovisningen är korrekt.
Diverse andra konsensuskontroller

Som till exempel om avgiften är högre än minimibeloppet.

Om alla dessa kontroller passerar, kommer noden att vidarebefordra transaktionen till sina kamrater och den kommer så småningom att brytas och läggas till blockkedjan.

Stoppa bedrägeri

Låt oss nu säga att Alice försökte vara lömsk och använde $ X^* $ som sitt överskott; den där hon gav sig själv 100 µT förändring istället för 90 µT. Nu balanserar inte värdena. Summan av utdata, indata och avgifter kommer att se ut ungefär så här:

$$ 10.H + (x_s + k_b).G $$

Så nu när en full nod kontrollerar signaturen:

$$ \begin{align} R + e(X^* + P_b) &\stackrel{?}{=} sG \\ R + e(10.H + x_s.G + P_b) &\stackrel{?}{ =} (r_a + r_b + e(x_s + k_b)).G \\ R + e(10.H + X + P_b) &\stackrel{?}{=} (r_a + r_b).G + e(x_s) + k_b).G \\ \mathbf{10e.H} + R + e(X + P_b) &\stackrel{?}{=} R + e(X + P_b) \\ \end{align} $$

Signaturen verifierar inte! Noden kan inte säga exakt vad som är fel med transaktionen, men den vet att något är på gång, och därför kommer den bara att släppa transaktionen tyst och fortsätta med sitt liv.

Transaktionsöversikt

Sammanfattningsvis: en Tari/MimbleWimble-transaktion inkluderar följande:

Från Alice, en uppsättning ingångar som refererar och spenderar en uppsättning tidigare utgångar.
Från Alice och Bob, en uppsättning nya utgångar, inklusive:
- Ett värde och en bländande faktor (som bara är en ny privat nyckel).
- Ett intervallbevis som visar att värdet är icke-negativt.
Transaktionsavgiften, i klartext,
Det offentliga överskottet, som är summan av alla bländande faktorer som används i transaktionen.
Transaktionsmetadata.
Det överskjutande blindningsvärdet som används som den privata nyckeln för att signera ett meddelande som intygar transaktionens metadata, och det offentliga överskottet.

Referensprojekt

[1] "Vad är konfidentiella Bitcoin-transaktioner?" [Online.] Tillgängligt: https://www.mycryptopedia.com/what-are-confidential-transactions/ Åtkomstdatum: 2019‑04‑09.

[2] "Nothing-Up-My_Sleeve Number" [online].
Lagerstatus https://en.wikipedia.org/w/index.php?title=Nothing-up-my-sleeve_number&oldid=889582749. Åtkomstdatum: 2019‑04‑09.

[3] Wikipedia: "Commitment Scheme" [online]. Tillgängliga: https://en.wikipedia.org/wiki/Commitment_scheme. Åtkomstdatum: 2019‑04‑09.

[4] "Kernel Offsets, in Introduction to MimbleWimble and Grin" [online]. Tillgängliga: https://github.com/mimblewimble/grin/blob/master/doc/intro.md#kernel-offsets. Åtkomstdatum: 2019‑04‑09.

[5] A. Gibson, "From Zero (Knowledge) to BulletProofs" [online]. Tillgängliga: https://joinmarket.me/static/FromZK2BPs_v1.pdf. Åtkomstdatum: 2019‑04‑10.