|
|
|
|
@ -1,14 +1,14 @@
|
|
|
|
|
# Einführung in MimbleWimble und Grin
|
|
|
|
|
|
|
|
|
|
*In anderen Sprachen lesen: [English](intro.md), [简体中文](intro.zh-cn.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語](intro.jp.md), [Deutsch](intro_DE.md).*
|
|
|
|
|
*In anderen Sprachen lesen: [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 ist ein Blockchain-Format und Protokoll, welches auf starke kryptographische Primitiven setzt und dadurch äußerst gute Skalierbarkeit, Privatssphäre und Fungibilität bietet. Es befasst sich mit Lücken, die in fast allen gegenwärtigen Blockchainimplementierungen existieren.
|
|
|
|
|
MimbleWimble ist ein Blockchain-Format und Protokoll, welches auf starke kryptographische Primitiven setzt und dadurch äußerst gute Skalierbarkeit, Privatsphäre und Fungibilität bietet. Es befasst sich mit Lücken, die in fast allen gegenwärtigen Blockchainimplementierungen existieren.
|
|
|
|
|
|
|
|
|
|
Grin ist ein Open-Source-Softwareprojekt, dass eine MimbleWimble-Blockchain implementiert und die für den Einsatz einer vollständigen Blockchain und Kryptowährung nötigen Lücken schließt.
|
|
|
|
|
|
|
|
|
|
Das Hauptziel und die Charakteristika des Grin-Projekts sind wie folgt:
|
|
|
|
|
|
|
|
|
|
* Standardmäßige Privatssphäre. Dies ermöglicht volle Fungibilität ohne die Fähigkeit auszuschließen, Informationen nach Bedarf selektiv preisgeben zu können.
|
|
|
|
|
* Standardmäßige Privatsphäre. Dies ermöglicht volle Fungibilität, ohne die Fähigkeit auszuschließen, Informationen nach Bedarf selektiv preisgeben zu können.
|
|
|
|
|
* Skaliert hauptsächlich mit der Anzahl der Nutzer und minimal mit der Anzahl an Transaktionen (<100 byte `kernel`), was zu hoher Platzsparung im Vergleich zu anderen Blockchains führt.
|
|
|
|
|
* Starke und bewährte Kryptografie. MimbleWimble setzt nur auf seit Jahrzehnten erprobte Elliptische-Kurven-Kryptografie.
|
|
|
|
|
* Einfachheit des Designs, die das dauerhafte Auditieren und Aufrechterhalten leicht gestaltet.
|
|
|
|
|
@ -16,13 +16,13 @@ Das Hauptziel und die Charakteristika des Grin-Projekts sind wie folgt:
|
|
|
|
|
|
|
|
|
|
## Tongue Tying für Jedermann
|
|
|
|
|
|
|
|
|
|
Dieses Dokument richtet sich an Leser mit einem guten Verständnis von Blockchains und grundlegender Kryptografie. Vor diesem Hintergrund sind wir bestrebt, den technischen Aufbau von MimbleWimble und dessen Einsatz in Grin zu erklären. Wir hoffen, dass dieses Dokument für die meisten technikbegeisterten Leser verständlich ist. Unser Ziel ist es, dich für Grin zu begeistern und dein Interesse zu wecken, dich in jeder möglichen Weise einzubringen.
|
|
|
|
|
Dieses Dokument richtet sich an Leser, die ein gutes Verständnis von Blockchain und grundlegender Kryptografie haben. Vor diesem Hintergrund sind wir bestrebt, den technischen Aufbau von MimbleWimble, sowie dessen Einsatz in Grin zu erklären. Wir hoffen, dass dieses Dokument für die meisten technikbegeisterten Leser verständlich ist. Unser Ziel ist es, dich für Grin zu begeistern und dein Interesse zu wecken, dich in jeder möglichen Weise einzubringen.
|
|
|
|
|
|
|
|
|
|
Um dieses Ziel zu erreichen, führen wir die für ein gutes Verständnis von Grin als MimbleWimble-Umsetzung nötigen Hauptkonzepte ein. Wir beginnen mit einer kurzen Erläutering einiger relevanter Eigenschaften der Elliptischen-Kurven-Kryptografie (ECC), um die Grundlagen für Grin zu legen und anschließend die Kernelemente von Transaktionen und Blocks im MimbleWimble-Blockchain zu beschreiben.
|
|
|
|
|
|
|
|
|
|
### Tiny Bits of Elliptic Curves
|
|
|
|
|
|
|
|
|
|
Wir beginnen mit einer kurzen Einführung in Elliptische-Kurven-Kryptografie und betrachten dabei nur die Eigenschaften die für das Verständnis dafür, wie MimbleWimble funktioniert, nötig sind, ohne dabei die Feinheiten von ECC eingehend zu vertiefen. Für Leser, die tiefer in diese Vorraussetzungen einzutauchen wünschen, gibt es weitere Möglichkeiten [mehr zu lernen](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/).
|
|
|
|
|
Wir beginnen mit einer kurzen Einführung in Elliptische-Kurven-Kryptografie, wobei wir nur die Eigenschaften betrachten, die für das Verständnis von MimbleWimbles Funktionsweise nötig sind, ohne die Feinheiten von ECC eingehend zu vertiefen. Für Leser, die tiefer in diese Vorraussetzungen einzutauchen wünschen, gibt es weitere Möglichkeiten [mehr zu lernen](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/).
|
|
|
|
|
|
|
|
|
|
Eine elliptische Kurve zum Zwecke der Kryptografie ist ein großes Set an Punkten, die wir _C_ nennen. Diese Punkte können von Integern (auch Skalare genannt) addiert, substrahiert, oder multipliziert werden. Mit einem Integer _k_ und mittels einer Operation der skalaren Multiplikation können wir `k*H` errechnen, was auch einen Punkt auf der Kurve _C_ darstellt. Mit einem weiteren Integer _j_ können wir ferner `(k+j)*H` errechnen, was `k*H + j*H` gleicht. Diese Addition- und Skalarmultiplikationsoperationen auf einer elliptischen Kurve behalten die kommutativen und assoziativen Eigenschaften der Addition und Multiplikation bei:
|
|
|
|
|
|
|
|
|
|
@ -30,18 +30,18 @@ Eine elliptische Kurve zum Zwecke der Kryptografie ist ein großes Set an Punkte
|
|
|
|
|
|
|
|
|
|
Wenn wir in ECC eine sehr große Zahl _k_ als privaten Schlüssel wählen, gilt `k*H` als der korrespondierende öffentliche Schlüssel. Selbst wenn der Wert des öffentlichen Schlüssels `k*H` bekannt ist, ist die Ableitung von _k_ nahezu unmöglich (oder anders ausgedrückt, während die Multiplikation trivial ist, ist die "Division" durch Kurvenpunkte extrem schwierig).
|
|
|
|
|
|
|
|
|
|
Die vorherige Formel `(k+j)*H = k*H + j*H`, mit jeweils _k_ und _j_ als privaten Schlüsseln, demonstriert, dass ein aus der Addition zweier privater Schlüssel (`(k+j)*H`) erhaltener öffentlicher Schlüssel identisch mit der Addition der öffentlichen Schlüssel für jeden der zwei privaten Schlüssel (`k*H + j*H`) ist. Im Bitcoin-Blockchain stützen sich Hierarchical Deterministic Wallets stark auf dieses Prinzip. Gleiches gilt auch für MimbleWimble und die Grin-Implementierung.
|
|
|
|
|
Die vorherige Formel `(k+j)*H = k*H + j*H`, mit jeweils _k_ und _j_ als privaten Schlüsseln, demonstriert, dass ein aus der Addition zweier privater Schlüssel (`(k+j)*H`) erhaltener öffentlicher Schlüssel identisch mit der Addition der öffentlichen Schlüssel für jeden der zwei privaten Schlüssel (`k*H + j*H`) ist. In der Bitcoin-Blockchain stützen sich Hierarchical Deterministic Wallets stark auf dieses Prinzip. Gleiches gilt auch für MimbleWimble und die Grin-Implementierung.
|
|
|
|
|
|
|
|
|
|
### Transaktionen mit MimbleWimble
|
|
|
|
|
|
|
|
|
|
Die Struktur von Transaktionen veranschaulicht einen wesentlichen Grundsatz von MimbleWimble: starke Privatssphäre und Garantie der Vertraulichkeit.
|
|
|
|
|
Die Struktur von Transaktionen veranschaulicht einen wesentlichen Grundsatz von MimbleWimble: starke Privatsphäre und Garantie der Vertraulichkeit.
|
|
|
|
|
|
|
|
|
|
Die Validierung von MimbleWimble-Transaktionen hängt von zwei grundlegenden Eigenschaften ab:
|
|
|
|
|
|
|
|
|
|
* **Verifizierung von Zero Sums.** Die Summe der Outputs minus Inputs ergibt immer Null, was beweist, dass die Transaktion keine neuen Gelder erschaffen hat, _ohne dabei die tatsächlichen Beträge zu enthüllen._
|
|
|
|
|
* **Besitz von privaten Schlüsseln.** Wie bei den meisten anderen Kryptowährungen ist das Eigentum der Transtaktionsoutputs durch den Besitz der ECC-Privatschlüssel garantiert. Jedoch wird der Beweis, dass eine Entität jene privaten Schlüssel besitzt, nicht durch das direkte Signieren der Transaktion erreicht.
|
|
|
|
|
|
|
|
|
|
Die folgenden Abschnitte über Kontostand, Besitz, Wechselgeld, und Beweise beschreiben ausführlich wie diese zwei grundelegenden Eigenschaften erreicht werden.
|
|
|
|
|
Die folgenden Abschnitte über Kontostand, Besitz, Wechselgeld, und Beweise, beschreiben ausführlich wie diese zwei grundelegenden Eigenschaften erreicht werden.
|
|
|
|
|
|
|
|
|
|
#### Kontostand
|
|
|
|
|
|
|
|
|
|
@ -51,7 +51,7 @@ Falls _v_ der Wert eines Transaktions-Inputs oder Outputs und _H_ eine elliptisc
|
|
|
|
|
|
|
|
|
|
v1 + v2 = v3 => v1*H + v2*H = v3*H
|
|
|
|
|
|
|
|
|
|
Diese Eigenschaft bei jeder Transaktion zu verifizieren erlaubt es dem Protokoll nachzuweisen, ohne Kenntnis über die tatsächlichen Werte zu haben, dass eine Transaktion nicht Geld aus dem Nichts erschafft. Allerdings gibt es eine endliche Zahl nutzbarer Werte, und es könnte jeder einzelne davon getestet werden, um den Wert deiner Transaktion zu schätzen. Darüber hinaus legt die Kenntnis über v1 (beispielsweise von vorherigen Transaktionen) und das daraus resultierende `v1*H` alle Outputs mit dem Wert v1 quer über die Blockchain offen. Aus diesen Gründen führen wir eine zweite elliptische Kurve _G_ ein (praktischerweise ist _G_ nur ein weiterer Generatorpunkt auf der gleichen Kurve wie _H_), sowie einen privaten Schlüssel _r_, welcher als *blinding factor* genutzt wird.
|
|
|
|
|
Diese Eigenschaft, bei jeder Transaktion zu verifizieren, erlaubt es dem Protokoll, ohne Kenntnis über die tatsächlichen Werte zu haben, nachzuweisen, dass eine Transaktion nicht Geld aus dem Nichts erschafft. Allerdings gibt es eine endliche Zahl nutzbarer Werte, und es könnte jeder einzelne davon getestet werden, um den Wert deiner Transaktion zu schätzen. Darüber hinaus legt die Kenntnis über v1 (beispielsweise von vorherigen Transaktionen) und das daraus resultierende `v1*H`, alle Outputs mit dem Wert v1 quer über die Blockchain offen. Aus diesen Gründen führen wir eine zweite elliptische Kurve _G_ ein (praktischerweise ist _G_ nur ein weiterer Generatorpunkt auf der gleichen Kurve wie _H_), sowie einen privaten Schlüssel _r_, welcher als *Blinding Factor* genutzt wird.
|
|
|
|
|
|
|
|
|
|
Ein Input- oder Outputwert in einer Transaktion kann sodann ausgedrückt werden als:
|
|
|
|
|
|
|
|
|
|
@ -59,10 +59,10 @@ Ein Input- oder Outputwert in einer Transaktion kann sodann ausgedrückt werden
|
|
|
|
|
|
|
|
|
|
Wobei:
|
|
|
|
|
|
|
|
|
|
* _r_ ein privater Schlüssel ist, der als blinding factor genutzt wird, _G_ eine elliptische Kurve, und deren Produkt `r*G` der öffentliche Schlüssel für _r_ auf _G_ ist.
|
|
|
|
|
* _r_ ein privater Schlüssel ist, der als Blinding Factor genutzt wird, _G_ eine elliptische Kurve, und deren Produkt `r*G` der öffentliche Schlüssel für _r_ auf _G_ ist.
|
|
|
|
|
* _v_ der Wert eines Inputs oder Outputs und _H_ eine weitere elliptische Kurve ist.
|
|
|
|
|
|
|
|
|
|
Weder _v_ noch _r_ können abgeleitet werden, was die grundlegenden Eigenschaften von Elliptischer-Kurven-Kryptografie wirksam zum Einsatz bringt. `r*G + v*H` wird als ein _Pedersen Commitment_ bezeichnet.
|
|
|
|
|
Weder _v_ noch _r_ können abgeleitet werden, was die grundlegenden Eigenschaften der Elliptischen-Kurven-Kryptografie wirksam zum Einsatz bringt. `r*G + v*H` wird als ein _Pedersen Commitment_ bezeichnet.
|
|
|
|
|
|
|
|
|
|
Als Beispiel nehmen wir an, dass wir eine Transaktion mit zwei Inputs und einem Output erstellen möchten. Wir haben (die Kosten ignorierend):
|
|
|
|
|
|
|
|
|
|
@ -73,7 +73,7 @@ Sodass
|
|
|
|
|
|
|
|
|
|
vi1 + vi2 = vo3
|
|
|
|
|
|
|
|
|
|
Durch die Erstellung eines privaten Schlüssels als blinding factor für jeden Inputwert und das Austauschen jedes Wertes mit den respektiven Pedersen commitments der vorherigen Gleichung, erhalten wir:
|
|
|
|
|
Durch die Erstellung eines privaten Schlüssels als Blinding Factor für jeden Inputwert und das Austauschen jedes Wertes mit den respektiven Pedersen Commitments der vorherigen Gleichung, erhalten wir:
|
|
|
|
|
|
|
|
|
|
(ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H)
|
|
|
|
|
|
|
|
|
|
@ -87,9 +87,9 @@ Zum Schluss sei erwähnt, dass diese Idee von Greg Maxwells [Confidential Transa
|
|
|
|
|
|
|
|
|
|
#### Besitz
|
|
|
|
|
|
|
|
|
|
In den vorherigen Abschnitten haben wir private Schlüssel als blinding factor, um die Transaktionswerte zu verbergen, eingeführt. Die zweite Erkenntnis von MimbleWimble ist, dass private Schlüssel zum Einsatz kommen können, um privaten Besitz des Wertes zu beweisen.
|
|
|
|
|
In den vorherigen Abschnitten haben wir private Schlüssel als Blinding Factor, um die Transaktionswerte zu verbergen, eingeführt. Die zweite Erkenntnis von MimbleWimble ist, dass private Schlüssel zum Einsatz kommen können, um den privaten Besitz des Wertes zu beweisen.
|
|
|
|
|
|
|
|
|
|
Alice schickt dir 3 Coins. Um diesen Betrag zu verbergen, wählst du 28 als binding factor (es sei angemerkt, dass der blinding factor als privater Schlüssel in der Praxis eine sehr große Zahl darstellt). Irgendwo auf der Blockchain erscheint der folgende Output, der nur von dir ausgebbar sein sollte:
|
|
|
|
|
Alice schickt dir 3 Coins. Um diesen Betrag zu verbergen, wählst du 28 als Blinding Factor (es sei angemerkt, dass der Blinding Factor als privater Schlüssel in der Praxis eine sehr große Zahl darstellt). Irgendwo auf der Blockchain erscheint der folgende Output, der nur von dir ausgebbar sein sollte:
|
|
|
|
|
|
|
|
|
|
X = 28*G + 3*H
|
|
|
|
|
|
|
|
|
|
@ -107,18 +107,18 @@ Durch Überprüfung, dass alles Null ergibt, können wir sicherstellen, dass kei
|
|
|
|
|
|
|
|
|
|
Moment! Stop! Da du nun den privaten Schlüssel in Carols Output kennst (der in diesem Fall der Gleiche wie deiner sein muss um Gleichgewicht zu schaffen). Somit könntest du das Geld von Carol zu dir zurück stehlen!
|
|
|
|
|
|
|
|
|
|
Um dies zu lösen nutzt Carol einen privaten Schlüssel ihrer Wahl. Sie wählt beispielsweise 113 aus, was davon beim Blockchain ankommt ist wie folgt:
|
|
|
|
|
Um dies zu lösen, nutzt Carol einen privaten Schlüssel ihrer Wahl. Sie wählt beispielsweise 113 aus, was davon beim Blockchain ankommt ist wie folgt:
|
|
|
|
|
|
|
|
|
|
Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H
|
|
|
|
|
|
|
|
|
|
Nun ergibt die Transaktion nicht länger Null und wir haben einen Wertüberschuss auf _G_ (85), was das Ergebnis der Summierung aller blinding factors ist. Weil aber `85*G` ein gültiger öffentlicher Schlüssel auf der elliptischen Kurve _G_, mit dem privaten Schlüssel 85, für jedes x und y, ist, gilt `x*G + y*H` nur dann als gültiger öffentlicher Schlüssel auf _G_, wenn `y = 0` ist.
|
|
|
|
|
Nun ergibt die Transaktion nicht länger Null und wir haben einen Wertüberschuss auf _G_ (85), was das Ergebnis der Summierung aller Blinding Factors ist. Weil aber `85*G` ein gültiger öffentlicher Schlüssel auf der elliptischen Kurve _G_, mit dem privaten Schlüssel 85, für jedes x und y, ist, gilt `x*G + y*H` nur dann als gültiger öffentlicher Schlüssel auf _G_, wenn `y = 0` ist.
|
|
|
|
|
|
|
|
|
|
Daher muss das Protokoll lediglich verifizieren, dass (`Y - Xi`) ein gültiger öffentlicher Schlüssel auf _G_ ist, und dass die Transaktionspartner gemeinsam den privaten Schlüssel kennen (85 in unserer Transaktion mit Carol). Der einfachste Weg dies zu tun ist eine mit dem Wertüberschuss (85) erstellte Signature zu erfordern, die dann validiert, dass:
|
|
|
|
|
|
|
|
|
|
* Die Transaktionspartner gemeinsam den privaten Schlüssel kennen, und
|
|
|
|
|
* Die Summe der Transaktionsoutputs, minus der Inputs, Null ergibt (weil nur ein gültiger öffentlicher Schlüssel, der dem privaten Schlüssel entspricht, den Abgleich mit der Signatur vollbringt).
|
|
|
|
|
* die Transaktionspartner gemeinsam den privaten Schlüssel kennen, und
|
|
|
|
|
* die Summe der Transaktionsoutputs, minus der Inputs, Null ergibt (weil nur ein gültiger öffentlicher Schlüssel, der dem privaten Schlüssel entspricht, den Abgleich mit der Signatur vollbringt).
|
|
|
|
|
|
|
|
|
|
Diese Signatur, die jeder Transaktion zusammen mit weiteren Daten (wie Mininggebühren) beigefügt ist, wird als ein _transaction kernel_ bezeichnet und von allen Validierern geprüft.
|
|
|
|
|
Diese Signatur, die jeder Transaktion zusammen mit weiteren Daten (wie Mininggebühren) beigefügt ist, wird als ein _Transaction Kernel_ bezeichnet und von allen Validierern geprüft.
|
|
|
|
|
|
|
|
|
|
#### Einige Feinheiten
|
|
|
|
|
|
|
|
|
|
@ -126,7 +126,7 @@ Dieser Abschnitt führt die Erstellung von Transaktionen weiter aus und erörter
|
|
|
|
|
|
|
|
|
|
#### Wechselgeld
|
|
|
|
|
|
|
|
|
|
Angenommen du möchtest gerne 2 der 3 von Alice empfangenen Coins an Carol schicken. Um dies zu tun, würdest du den verbleibenden einen Coin an dich selbst als Wechselgeld zurückschicken. Du generierst einen weiteren privaten Schlüssel (beispielsweise 12) als blinding factor um deinen Wechselgeldoutput zu schützen. Carol nutzt wie zuvor ihren eigenen privaten Schlüssel.
|
|
|
|
|
Angenommen, du möchtest gerne 2 der 3 von Alice empfangenen Coins an Carol schicken. Um dies zu tun, würdest du den verbleibenden 1 Coin an dich selbst als Wechselgeld zurückschicken. Du generierst einen weiteren privaten Schlüssel (beispielsweise 12) als Blinding Factor, um deinen Wechselgeldoutput zu schützen. Carol nutzt wie zuvor ihren eigenen privaten Schlüssel.
|
|
|
|
|
|
|
|
|
|
Wechselgeldoutput: 12*G + 1*H
|
|
|
|
|
Carols Output: 113*G + 2*H
|
|
|
|
|
@ -141,7 +141,7 @@ In allen obigen Berechnungen stützen wir uns darauf, dass die Transaktionswerte
|
|
|
|
|
|
|
|
|
|
Zum Beispiel könnten Transaktionen mit einem Input von 2 und Outputs von 5 und -3 erstellt werden, die trotzdem ausgeglichen sind, folgend der Definition in den vorherigen Abschnitten. Dies ist nicht einfach festzustellen, da sogar wenn _x_ Negativ ist, der korrespondierende Punkt `x.H` auf der Kurve so aussieht wie jeder andere.
|
|
|
|
|
|
|
|
|
|
Um dieses Problem zu lösen, setzt MimbleWimble ein anderes kryptographisches Konzept (ebenso stammend von Confidential Transactions) namens Range Proofs ein. Wir werden Range Proofs nicht ausführlich behandeln, du solltest nur wissen, dass wir für jedes `r.G + v.H` einen Beweis erstellen können, der zeigt, dass _v_ größer als null ist und nicht zu Overflow führt.
|
|
|
|
|
Um dieses Problem zu lösen, setzt MimbleWimble ein anderes kryptographisches Konzept (ebenso stammend von Confidential Transactions) namens Range Proofs ein. Wir werden Range Proofs nicht ausführlich behandeln, du solltest nur wissen, dass wir für jedes `r.G + v.H` einen Beweis erstellen können, der zeigt, dass _v_ größer als Null ist und nicht zu Overflow führt.
|
|
|
|
|
|
|
|
|
|
Es ist auch wichtig anzumerken, dass um einen gültigen Range Proof der obigen Beispiele zu erstellen, die beiden Werte 113 und 28, die für die Erstellung und Signierung des Wertüberschusses genutzt werden, bekannt sein müssen. Der Grund dafür, sowie eine genauere Beschreibung von Range Proofs, wird im [Range Proof Paper](https://eprint.iacr.org/2017/1066.pdf) behandelt.
|
|
|
|
|
|
|
|
|
|
@ -149,20 +149,20 @@ Es ist auch wichtig anzumerken, dass um einen gültigen Range Proof der obigen B
|
|
|
|
|
|
|
|
|
|
Eine MimbleWimble-Transaktion beinhaltet wie folgt:
|
|
|
|
|
|
|
|
|
|
* Ein Reihe von Inputs, die referenzieren und eine Reihe an vorherigen Outputs ausgeben
|
|
|
|
|
* Eine Reihe an neuen Outputs die Folgendes umfassen:
|
|
|
|
|
* einen Wert und ein blinding factor (welcher nur ein neuer privater Schlüssel ist) auf einer Kurve multipliziert und als `r.G + v.H` summiert.
|
|
|
|
|
* Eine Reihe von Inputs, die referenzieren, sowie eine Reihe an vorherigen Outputs ausgeben.
|
|
|
|
|
* Eine Reihe an neuen Outputs, die Folgendes umfassen:
|
|
|
|
|
* einen Wert und ein Blinding Factor (welcher nur ein neuer privater Schlüssel ist) auf einer Kurve multipliziert und als `r.G + v.H` summiert.
|
|
|
|
|
* Ein Range Proof der zeigt, dass v nicht negativ ist.
|
|
|
|
|
* Eine eindeutige Transaktionsgebühr.
|
|
|
|
|
* Eine Signatur, die sich dadurch berechnet, dass der überschüssige Blindingwert (die Summe aller Outputs plus der Gebühren, Minus der Inputs) genommen und als privater Schlüssel verwendet wird.
|
|
|
|
|
|
|
|
|
|
### Blocks und Chainstate
|
|
|
|
|
|
|
|
|
|
Wir haben oben beschreiben wie MimbleWimble-Transaktionen starke Anonymität gewährleisten können, während die Eigenschaften für eine gültigen Blockchain beibehalten werden, das heißt eine Transaktion erstellt kein Geld und der Eigentumsnachweis erfolgt über private Schlüssel.
|
|
|
|
|
Wir haben oben beschrieben, wie MimbleWimble-Transaktionen starke Anonymität gewährleisten können, während die Eigenschaften für eine gültigen Blockchain beibehalten werden, das heißt, dass eine Transaktion kein Geld erstellt und der Eigentumsnachweis über private Schlüssel erfolgt.
|
|
|
|
|
|
|
|
|
|
Das MimbleWimble-Blockformat baut darauf auf, indem es ein weiteres Konzept einführt: _cut-through_. Mit dieser Erweiterung erlangt eine MimbleWimble-Blockchain:
|
|
|
|
|
|
|
|
|
|
* Äußerst gute Skalierbarkeit, da die große Mehrzahl der Transaktionsdaten über Zeit entfernt werden können, ohne dabei Sicherheit zu beeinträchtigen.
|
|
|
|
|
* äußerst gute Skalierbarkeit, da die große Mehrzahl der Transaktionsdaten über Zeit entfernt werden können, ohne dabei Sicherheit zu beeinträchtigen.
|
|
|
|
|
* Weitergehende Anonymität durch das Vermischen und Löschen von Transaktionsdaten.
|
|
|
|
|
* Die Fähigkeit neuer Nodes mit dem Rest des Netzwerks sehr effizient zu synchronisieren.
|
|
|
|
|
|
|
|
|
|
@ -170,13 +170,13 @@ Das MimbleWimble-Blockformat baut darauf auf, indem es ein weiteres Konzept einf
|
|
|
|
|
|
|
|
|
|
Rufe ins Gedächtnis, dass jede Transaktion aus dem Folgenden besteht -
|
|
|
|
|
|
|
|
|
|
* Eine Reihe von Inputs, die referenzieren und eine Reihe an vorherigen Outputs ausgeben
|
|
|
|
|
* Eine Reihe an neuen Outputs (Pedersen commitments)
|
|
|
|
|
* Eine Reihe von Inputs, die referenzieren und eine Reihe an vorherigen Outputs ausgeben.
|
|
|
|
|
* Eine Reihe an neuen Outputs (Pedersen Commitments).
|
|
|
|
|
* Ein Transaktionskernel, bestehend aus
|
|
|
|
|
* kernel excess (Pedersen commitment zu Null)
|
|
|
|
|
* Transaktionssignatur (mittels kernel excess als öffentlicher Schlüssel)
|
|
|
|
|
* Kernel Excess (Pedersen Commitment zu Null).
|
|
|
|
|
* Transaktionssignatur (mittels Kernel Excess als öffentlicher Schlüssel).
|
|
|
|
|
|
|
|
|
|
Eine Transaktion wird signiert und die Signatur in einen _transaction kernel_ eingefügt. Die Signatur wird durch die Nutzung des _kernel excess_ als öffentlicher Schlüssel erstellt, womit bewiesen wird, dass die Transaktion Null ergibt.
|
|
|
|
|
Eine Transaktion wird signiert und die Signatur in einen _Transaction Kernel_ eingefügt. Die Signatur wird durch die Nutzung des _Kernel Excess_ als öffentlicher Schlüssel erstellt, womit bewiesen wird, dass die Transaktion Null ergibt.
|
|
|
|
|
|
|
|
|
|
(42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H
|
|
|
|
|
|
|
|
|
|
@ -186,7 +186,7 @@ Wir können sagen, dass das Folgende für jede beliebige Transaktion wahr ist (z
|
|
|
|
|
|
|
|
|
|
sum(outputs) - sum(inputs) = kernel_excess
|
|
|
|
|
|
|
|
|
|
Das gleiche gilt auch für Blocks, sobald wir realisieren, dass ein Block lediglich eine Reihe an aggregierten Inputs, Outputs, und Transaktionskerneln ist. Wir können die Transaktionsoutputs summieren, die Summe der Transaktionsinputs substrahieren, und das resultierende Pedersen commitment mit der Summe des kernel excess vergleichen -
|
|
|
|
|
Das gleiche gilt auch für Blocks, sobald wir realisieren, dass ein Block lediglich eine Reihe an aggregierten Inputs, Outputs, und Transaktionskerneln ist. Wir können die Transaktionsoutputs summieren, die Summe der Transaktionsinputs substrahieren, und das resultierende Pedersen Commitment mit der Summe des Kernel Excess vergleichen -
|
|
|
|
|
|
|
|
|
|
sum(outputs) - sum(inputs) = sum(kernel_excess)
|
|
|
|
|
|
|
|
|
|
@ -194,7 +194,7 @@ Leicht vereinfacht (weiterhin Transaktionsgebühren ignorierend) können wir sag
|
|
|
|
|
|
|
|
|
|
##### Kernel-Offsets
|
|
|
|
|
|
|
|
|
|
In den wie oben beschriebenen MimbleWimble-Blocks und Transaktionen gibt es ein subtiles Problem. Es ist möglich (und in manchen Fällen trivial) die konstituierende Transaktion in einem Block zu rekonstruieren. Dies ist eindeutig schlecht für die Privatsphäre. Es handelt sich um ein "subset"-Problem - bei einer gegebenen Reihe an Inputs, Outputs, und Transaktionskerneln wird ein Subset dieser eine gültige Transaktion rekombinieren.
|
|
|
|
|
In den wie oben beschriebenen MimbleWimble-Blocks und Transaktionen gibt es ein subtiles Problem. Es ist möglich (und in manchen Fällen trivial) die konstituierende Transaktion in einem Block zu rekonstruieren. Dies ist eindeutig schlecht für die Privatsphäre. Es handelt sich um ein "subset"-Problem - bei einer gegebenen Reihe an Inputs, Outputs, und Transaktionskerneln, wird ein Subset dieser Reihe eine gültige Transaktion rekombinieren.
|
|
|
|
|
|
|
|
|
|
Beispielsweise seien die folgenden beiden Transaktionen gegeben -
|
|
|
|
|
|
|
|
|
|
@ -213,7 +213,7 @@ Wir wissen auch, dass alles Übrige genutzt werden kann, um die andere gültige
|
|
|
|
|
|
|
|
|
|
(in3) -> (out2), (kern2)
|
|
|
|
|
|
|
|
|
|
Um dies einzuschränken, beziehen wir einen _kernel offset_ in jedem Transaktionskernel mit ein. Dies ist ein blinding factor (privater Schlüssel) der zurück zum kernel excess hinzugefügt werden muss um zu verifizieren, dass die Summe der Commitments Null ergibt.
|
|
|
|
|
Um dies einzuschränken, beziehen wir einen _Kernel Offset_ in jedem Transaktionskernel mit ein. Dies ist ein Blinding Factor (privater Schlüssel) der zurück zum Kernel Excess hinzugefügt werden muss um zu verifizieren, dass die Summe der Commitments Null ergibt.
|
|
|
|
|
|
|
|
|
|
sum(outputs) - sum(inputs) = kernel_excess + kernel_offset
|
|
|
|
|
|
|
|
|
|
@ -225,7 +225,7 @@ Wir "teilen" den Schlüssel `k` in `k1+k2` während des Aufbaus der Transaktion.
|
|
|
|
|
|
|
|
|
|
#### Cut-through
|
|
|
|
|
|
|
|
|
|
Blocks erlauben es Minern multiple Transaktionen in einem einzelnen Set zusammenzustellen, dass dem Chain hinzugefügt wird. In den folgenden Blockrepräsentationen, die 3 Transaktionen enthalten, zeigen wir nur Inputs und Outputs der Transaktionen. Inputs referenzieren die Outputs, die sie ausgeben.
|
|
|
|
|
Blocks erlauben es Minern multiple Transaktionen in einem einzelnen Set zusammenzustellen, welches der Chain hinzugefügt wird. In den folgenden Blockrepräsentationen, die 3 Transaktionen enthalten, zeigen wir nur Inputs und Outputs der Transaktionen. Inputs referenzieren die Outputs, die sie ausgeben.
|
|
|
|
|
|
|
|
|
|
I1(x1) --- O1
|
|
|
|
|
|- O2
|
|
|
|
|
@ -241,7 +241,7 @@ Wir beobachten die folgenden zwei Eigenschaften:
|
|
|
|
|
* Innerhalb dieses Blocks werden einige Outputs direkt von einbezogenen Inputs (I3 gibt 02 aus und I4 gibt 03 aus) ausgegeben.
|
|
|
|
|
* Die Struktur jeder Transaktion tut nichts zur Sache. Da alle Transaktionen individuell Null ergeben, muss die Summe aller Transaktions-Inputs und Outputs Null sein.
|
|
|
|
|
|
|
|
|
|
Ähnlich einer Transaktion ist alles, was in einem Block geprüft werden muss, dass der Besitz bewiesen ist (was von _transaction kernels_ kommt) und dass der gesamte Block keine Geldmenge hinzugefügt hat (außer dem, was von der coinbase erlaubt ist). Daher können übereinstimmende Inputs und Outputs entfernt werden, da sich ihre Beteiligung an der Gesamtsumme aufhebt. Dies führt zum folgenden, viel kompakteren Block:
|
|
|
|
|
Ähnlich einer Transaktion ist alles, was in einem Block geprüft werden muss, dass der Besitz bewiesen ist (was von _Transaction Kernels_ kommt) und dass der gesamte Block keine Geldmenge hinzugefügt hat (außer dem, was von der Coinbase erlaubt ist). Daher können übereinstimmende Inputs und Outputs entfernt werden, da sich ihre Beteiligung an der Gesamtsumme aufhebt. Dies führt zum folgenden, viel kompakteren Block:
|
|
|
|
|
|
|
|
|
|
I1(x1) | O1
|
|
|
|
|
I2(x2) | O4
|
|
|
|
|
@ -254,7 +254,7 @@ Ein Block ist einfach ausgebaut aus:
|
|
|
|
|
* Einem Blockheader.
|
|
|
|
|
* Der Liste an Inputs, die nach dem Cut-through übrig bleiben.
|
|
|
|
|
* Der Liste an Outputs, die nach dem Cut-through übrig bleiben.
|
|
|
|
|
* Ein einzelnes Kerneloffset um den vollständigen Block zu umfassen
|
|
|
|
|
* Ein einzelnes Kerneloffset, um den vollständigen Block zu umfassen.
|
|
|
|
|
* Die Transaktionskernel, die für jede Transaktion beinhalten:
|
|
|
|
|
* Den öffentlichen Schlüssel `r*G`, der aus der Summierung aller Commitments erhalten wird.
|
|
|
|
|
* Die Signaturen die durch die excess value generiert werden.
|
|
|
|
|
@ -262,7 +262,7 @@ Ein Block ist einfach ausgebaut aus:
|
|
|
|
|
|
|
|
|
|
Sofern so strukturiert, bietet ein MimbleWimble-Block äußerst gute Garantie der Vertraulichkeit:
|
|
|
|
|
|
|
|
|
|
* Dazwischenliegende (cut-through) Transaktionen werden nur von ihren Transaktionskerneln repräsentiert.
|
|
|
|
|
* Intermediäre (cut-through) Transaktionen werden nur von ihren Transaktionskerneln repräsentiert.
|
|
|
|
|
* Alle Outputs sehen gleich aus: nur sehr große Zahlen, die unmöglich voneinander differenzierbar sind. Um einige Outputs auszuschließen, müssten alle ausgeschlossen werden.
|
|
|
|
|
* Alle Transaktionsstrukturen wurden entfernt, was es unmöglich macht zu ermitteln, welches Output mit jedem Input verbunden wurde.
|
|
|
|
|
|
|
|
|
|
@ -278,13 +278,13 @@ Verallgemeinernd können wir schlussfolgern, dass der Chainstate (ausgenommen He
|
|
|
|
|
2. Das komplette Set nicht verwendeter Outputs.
|
|
|
|
|
3. Die Transaktionskernel für jede Transaktion.
|
|
|
|
|
|
|
|
|
|
Das erste informationsstück kann nur mittels der Blockhöhe (seiner Distanz zum Genesisblock), abgeleitet werden. Beide nicht verwendeten Outputs und die Transaktionskernel sind höchst kompakt. Dies hat 2 wichtige Konsequenzen:
|
|
|
|
|
Das erste Informationsstück kann nur mittels der Blockhöhe (seiner Distanz zum Genesisblock), abgeleitet werden. Beide nicht verwendeten Outputs und die Transaktionskernel sind höchst kompakt. Dies hat 2 wichtige Konsequenzen:
|
|
|
|
|
|
|
|
|
|
* Der Zustand den eine gegebene Node in einer MimbleWimble-Blockchain aufrechterhalten muss ist sehr klein (von etwa einigen Gigabytes für eine Blockchain in der Größe von Bitcoin, und potentiall optimierbar auf wenige hundert Megabytes).
|
|
|
|
|
* Der Zustand, den eine gegebene Node in einer MimbleWimble-Blockchain aufrechterhalten muss, ist sehr klein (von etwa einigen Gigabytes für eine Blockchain in der Größe von Bitcoin, und potentiall optimierbar auf wenige hundert Megabytes).
|
|
|
|
|
* Wenn eine neue Node einem neuen Netzwerk beitritt, dass eine MimbleWimble-Chain aufbaut, ist die Menge an Informationen, die transferiert werden müssen, ebenfalls sehr klein.
|
|
|
|
|
|
|
|
|
|
Darüber hinaus kann das vollständige Set an nicht verwendeten Outputs nicht manipuliert werden, selbst nicht durch das Hinzufügen oder Entfernen eines Outputs. Würde dies getan werden, führe es dazu, dass die Summierung aller blinding factors in den Transaktionskerneln von der Summierung der blinding factors in den Outputs abweichen würde.
|
|
|
|
|
Darüber hinaus kann das vollständige Set an nicht verwendeten Outputs nicht manipuliert werden, selbst nicht durch das Hinzufügen oder Entfernen eines Outputs. Würde dies getan werden, führe es dazu, dass die Summierung aller Blinding Factors in den Transaktionskerneln von der Summierung der Blinding Factors in den Outputs abweichen würde.
|
|
|
|
|
|
|
|
|
|
### Fazit
|
|
|
|
|
|
|
|
|
|
In diesem Dokument haben wir die grundlegenden Prinzipien abgedeckt, die einer MimbleWimble-Blockchain unterliegen. Durch die Nutzung von Additionseigenschaften der Elliptische-Kurven-Kryptografie können wir Transaktionen erstellen, die völlig undurchsichtig sind, aber dennoch korrekt validiert werden können. Durch die Verallgemeinerung dieser Eigenschaften auf Blocks, können wir große Mengen an Blockchaindaten entfernen, was hohe Skalierbarkeit und schnelle Synchronisierung neuer Peers erlaubt.
|
|
|
|
|
In diesem Dokument haben wir die grundlegenden Prinzipien abgedeckt, die einer MimbleWimble-Blockchain unterliegen. Durch die Nutzung von Additionseigenschaften der Elliptischen-Kurven-Kryptografie können wir Transaktionen erstellen, die völlig undurchsichtig sind, aber dennoch korrekt validiert werden können. Durch die Verallgemeinerung dieser Eigenschaften auf Blocks, können wir große Mengen an Blockchaindaten entfernen, was hohe Skalierbarkeit und schnelle Synchronisierung neuer Peers erlaubt.
|
|
|
|
|
|
Oliver Simon
Yeastplume