intro_DE.md

Einführung in Mimblewimble und Mugle

In anderen Sprachen lesen: English, Español, Nederlands, Русский, 日本語, Deutsch, Portuguese, Korean, 简体中文

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.

Mugle 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 Mugle-Projekts sind wie folgt:

• 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.
• Von der Gemeinschaft gelenkt, die Dezentralisierung des Minings fördernd.

Tongue Tying für Jedermann

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 Mugle zu erklären. Wir hoffen, dass dieses Dokument für die meisten technikbegeisterten Leser verständlich ist. Unser Ziel ist es, dich für Mugle 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 Mugle 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 Mugle 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, 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.

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:

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

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. In der Bitcoin-Blockchain stützen sich Hierarchical Deterministic Wallets stark auf dieses Prinzip. Gleiches gilt auch für Mimblewimble und die Mugle-Implementierung.

Transaktionen mit Mimblewimble

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.

Kontostand

Aufbauend auf die oben beschriebenen Eigenschaften von ECC, können Werte in einer Transaktion verdeckt werden.

Falls v der Wert eines Transaktions-Inputs oder Outputs und H eine elliptische Kurve ist, können wir einfach v*H statt v in einer Transaktion einbetten. Dies funktioniert, da wir durch die Benutzung der ECC-Operationen dennoch validieren können, dass die Summe der Outputs einer Transaktion der Summe der Inputs gleicht:

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

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:

r*G + v*H

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.
• 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 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):

• vi1 und vi2 als Inputwerte.
• vo3 als Outputwerte.

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:

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

Was als Konsequenz vorraussetzt, dass:

ri1 + ri2 = ro3

Dies ist der erste Grundpfeiler von Mimblewimble: die für die Validierung einer Transaktion erforderliche Arithmetik kann durchgeführt werden, ohne Kenntnis über die Werte zu haben.

Zum Schluss sei erwähnt, dass diese Idee von Greg Maxwells Confidential Transactions abgeleitet wurde, und jene wiederum von Adam Backs Vorschlag für an Bitcoin angepasste homomorphe Werte.

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 den privaten Besitz des Wertes zu beweisen.

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

X ist das Ergebnis der Addition und von jedem einsehbar. Der Wert 3 ist nur dir und Alice bekannt, und 28 ist nur dir bekannt.

Um diese 3 Coins erneut zu verschicken, ist es für das Protokoll nötig, dass 28 auf irgendeine Art bekannt ist. Um zu zeigen wie dies funktioniert, nehmen wir an, dass du 3 der gleichen Coins an Carol verschickst. Du musst dafür eine simple Transaktion wie die folgende erstellen:

Xi => Y

Wobei Xi ein Input ist, der deinen Output X ausgibt, und Y Carols Output ist. Es gibt keinen Weg eine solche Transaktion zu erstellen und zu bi­lan­zie­ren, ohne deinen privaten Schlüssel von 28 zu kennen. In der Tat ist es so, dass Carol, falls sie die Transaktion ausbilanzieren möchte, sowohl den verschickten Wert als auch den prviaten Schlüssel wissen muss, sodass:

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

Durch Überprüfung, dass alles Null ergibt, können wir sicherstellen, dass kein neues Geld erstellt wurde.

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:

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 C, 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).

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

Dieser Abschnitt führt die Erstellung von Transaktionen weiter aus und erörtert wie Wechselgeld eingeführt wird, sowie ferner die Voraussetzung von Range Proofs, sodass alle Werte nachweislich nicht negativ sind. Keines der beiden ist für das Verständnis von Mimblewimble und Mugle absolut von Nöten, falls du es also eilig hast, spring einfach gleich zur Zusammenfassung.

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 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

Was auf die Blockchain gelangt ist sehr ähnlich wie zuvor. Die Signatur wird wieder mit dem Wertüberschuss erstellt, in diesem Falle 97.

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

Range Proofs

In allen obigen Berechnungen stützen wir uns darauf, dass die Transaktionswerte immer positiv sind. Die Einführung von negativen Beträgen wäre extrem problematisch, da in jeder Transaktion neue Gelder erstellt werden könnten.

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.

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 behandelt.

Zusammenfassung

Eine Mimblewimble-Transaktion beinhaltet wie folgt:

• 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 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.
• 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.

Transaktions-Aggregation

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).
• Ein Transaktionskernel, bestehend aus
  • 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.

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

Der öffentliche Schlüssel in diesem Beispiel ist 28*G.

Wir können sagen, dass das Folgende für jede beliebige Transaktion wahr ist (zwecks Einfachheit ungeachtet von Gebühren) -

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 -

sum(outputs) - sum(inputs) = sum(kernel_excess)

Leicht vereinfacht (weiterhin Transaktionsgebühren ignorierend) können wir sagen, dass Mimblewimble-Blocks genau wie Mimblewimble-Transaktionen behandelt werden können.

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 Reihe eine gültige Transaktion rekombinieren.

Beispielsweise seien die folgenden beiden Transaktionen gegeben -

(in1, in2) -> (out1), (kern1)
(in3) -> (out2), (kern2)

Wir können diese im folgenden Block zusammenfassen (oder aggregierte Transaktion) -

(in1, in2, in3) -> (out1, out2), (kern1, kern2)

Es ist trivial einfach, alle möglichen Permuationen auszuprobieren, um eine der Transaktionen (die erfolgreich zu Null summiert) wiederherzustellen:

(in1, in2) -> (out1), (kern1)

Wir wissen auch, dass alles Übrige genutzt werden kann, um die andere gültige Transaktion zu rekonstruieren -

(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.

sum(outputs) - sum(inputs) = kernel_excess + kernel_offset

Wenn wir Transaktionen in einem Block aggregieren, speichern wir ein einzeln aggregiertes Offset im Blockheader. Nun haben wir ein einzelnes Offset, welches nicht in seine individuellen Transaktionskernel-Offsets zerlegt werden kann, und womit Transaktionen nicht mehr rekonstruierbar sein können -

sum(outputs) - sum(inputs) = sum(kernel_excess) + kernel_offset

Wir "teilen" den Schlüssel k in k1+k2 während des Aufbaus der Transaktion. Für einen Transaktionskernel (k1+k2)*G veröffentlichen wir k1*G (den Überschuss) und k2 (das Offset), und signieren die Transaktion mit k1*G wie zuvor. Während des Blockaufbaus können wir einfach die k2-Offsets summieren um ein einzeln zusammengefasstes k2-Offset zu generieren, das alle Transaktionen in einem Block abdeckt.

Cut-through

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

I2(x2) --- O3
I3(O2) -|

I4(O3) --- O4
        |- O5

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:

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

Vermerke, dass alle Transaktionsstrukturen entfernt wurden und die Anordnung von Inputs und Outputs nicht mehr wichtig ist. Die Summe aller Outputs in diesem Block, minus der Inputs, ist jedoch noch immer garantiert Null.

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.
• 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.
  • Die Mininggebühr.

Sofern so strukturiert, bietet ein Mimblewimble-Block äußerst gute Garantie der Vertraulichkeit:

• 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.

Und doch validiert es alles noch immer!

Cut-through All The Way

Bezug nehmend auf den vorherigen Beispielblock, müssen die Outputs x1 und x2, ausgegeben von I1 und I2, zuvor auf der Blockchain aufgetreten sein. Nach der Addition dieses Blocks können jene Outputs, sowie I1 und I2, auch vom gesamten Chain entfernt werden, da sie nicht zur Gesamtsumme beitragen.

Verallgemeinernd können wir schlussfolgern, dass der Chainstate (ausgenommen Header) zu jedem Zeitpunkt durch lediglich die folgenden Informationsstücke zusammengefasst werden kann:

1. Die Gesamtanzahl an Coins, die durch Mining in der Chain erstellt wurden.
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:

• 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.

Fazit

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.