Safe Network Entwickler Update đŸ‡©đŸ‡Ș 29. Juli 2021

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!