Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 29nd July, 2021
Diese Woche werfen wir einen tieferen Blick auf DBCs, die das Potenzial haben, Online-Zahlungen zu revolutionieren und viele Aspekte der Safe Network-Wirtschaft zu vereinfachen. Sie sind wirklich so eine große Sache, aber in ihrer Standardform haben sie ein paar Nachteile, wenn es um private Transaktionen geht.
Ein Problem besteht darin, dass eine Münzprägeanstalt die Transaktionen sehen kann, die sie durchlaufen, und diese Transaktionen im Falle einer Kompromittierung veröffentlichen könnte. Diese Woche werfen wir einen Blick auf eine Möglichkeit, Transaktionen vor einer Münzstätte zu verbergen - Pedersen-Verpflichtungen - und auch eine Möglichkeit zu verhindern, dass Pedersen-Verpflichtungen von schlechten Schauspielern gespielt werden - Reichweitennachweise.
Allgemeiner Fortschritt
@danda und David Rusu leiten das Design von vertraulichen Transaktionen und passen DBCs an, um Einmalschlüssel zu erzwingen. @danda geht in diesem Beitrag näher darauf ein.
Auf der Client-Seite hat @yogesh am Code herumgehämmert, um es Clients zu ermöglichen, direkt mit Abschnitten zu kommunizieren, in denen sich Chunks befinden, was viel effizienter ist, als alles durch einen Abschnitt zu leiten.
Routing: @lionel.faber hat sich mit dem Quinn-Team in Verbindung gesetzt, das einige Vorschläge gemacht hat, was einige der Timeout- / Reset-Probleme verursacht, die Testnet-Benutzer erfahren haben. Wir verlagern auch Aspekte der Routing-Funktionalität auf qp2p, um die Komplexität zu reduzieren.
Die große Messaging-Rationalisierung geht weiter, mit einer gnadenlosen Ausmerzung wenig genutzter Messaging-Typen, die Fehler reduzieren und zu saubererem Code führen. Wie im Update von letzter Woche erwähnt, muss das Messaging aus Effizienzgründen auf ein Minimum beschränkt werden, und dasselbe gilt für den Inhalt der Nachrichten. Die Verwendung von CRDTs und das Sammeln von Signaturen durch Clients ermöglicht es uns, einen Großteil der Unordnung zu beseitigen und die vom Netzwerk durchgeführte Eselarbeit zu reduzieren.
Einer der neueren MaidSafer, der beim Refactoring von Nachrichten bis zum Äußersten ist, ist @Chris.Connelly. Hier ist ein Intro von Chris:
Ich bin Software-Ingenieur mit Sitz in Edinburgh und habe einen Hintergrund in der Entwicklung von Web-Service-Back-Ends und der Automatisierung von Cloud-Infrastrukturen, aber ich möchte jetzt meinen Horizont in Richtung verteilter und dezentraler Systeme erweitern. Ich interessiere mich leidenschaftlich für ganzheitliches Engineering (betrachte das gesamte System und vermeide Spezialistenrollen) und schreibe zuverlässige Software mit Rust (und manchmal Elm nebenbei), und ich bin begeistert, dies hier bei MaidSafe zu tun!
Pedersen-Verpflichtungen und Reichweitennachweise
Pedersen-Verpflichtungen sind eine Form des Zero-Knowledge-Beweises, die darauf abzielt, die Werte in Transaktionen zu verbergen. Sie ermöglichen dem Empfänger zu überprüfen, ob die Summe aller in die Verpflichtung eingegebenen Zahlen gleich der Summe aller in der Transaktion ausgegebenen Zahlen ist, ohne die Zahlen selbst preiszugeben.
Wenn ich also 30 Token habe, Ihnen 20 und jemand anderem 10 bezahle, kann diese Transaktion von einem Dritten verifiziert werden (addieren sich die Eingabe- und Ausgabewerte, „wahr“ oder „falsch“?), ohne dass sie die beteiligten Werte kennen.
Damit DBCs ausgegeben werden können, müssen sie von einer Münzstätte autorisiert werden. Pedersen-Verpflichtungen ermöglichen es Mint, zu überprüfen, ob sich Ein- und Ausgabewerte des DBC summieren (d. h. gültig sind) und die Transaktion zu unterzeichnen, ohne die getätigten Beträge zu kennen.
Eine Schwäche von Pedersen-Verpflichtungen bei der Validierung von Transaktionen besteht darin, dass sie durch negative Zahlen getäuscht werden können. Eine Transaktion mit einer Eingabe von 20 und einer Ausgabe von 30 und -10 wäre gültig, aber da „negatives Geld“ nicht als Token existieren kann, hat der Zahler effektiv 20 Token in 30 Token verwandelt. Magie! (Aber nicht für die Wirtschaft.)
Bereichsbeweise machen es kryptographisch unmöglich, dass ein Ausgabewert außerhalb eines bestimmten Bereichs liegt, sagen wir 0 - 2^32. Wir erzwingen dies, indem wir sagen, dass eine Transaktion nur dann gültig ist, wenn jede Ausgabe auch einen Bereichsbeweis enthält.
Wenn ich also einen DBC für 30 Token habe und Alice 20 und Bob 10 bezahlen möchte, läuft der Vorgang wie folgt ab:
Ich reiche meine DBC zusammen mit einer Pedersen-Zusage bei der Münzprägeanstalt ein, wobei die (verschlüsselte) Eingabe als ‚30‘ und die (verschlüsselten) Ausgaben als ‚20 + ein Reichweitenbeweis‘ und „10 + ein Reichweitenbeweis“ angegeben sind. Die Mint überprüft, ob sich die Eingabe- und Ausgabewerte addieren und dass jede Ausgabe einen gültigen Bereichsnachweis hat, signiert die Transaktion und gibt die DBCs erneut an die (verschleierten) öffentlichen Schlüssel von Alice und Bob aus.
Nützliche Links
Fühlen Sie sich frei, unten mit Links zu Übersetzungen dieses Entwicklungsupdates zu antworten, und die Moderatoren werden sie hier hinzufügen.
Als Open Source-Projekt sind wir immer auf der Suche nach Feedback, Kommentaren und Community-Beiträgen. Seien Sie also nicht schüchtern, machen Sie mit und lassen Sie uns gemeinsam das sichere Netzwerk erstellen!