Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 02 September, 2021
Wir haben in den letzten Wochen die Aussicht auf ein Update zur Safe Economy in Aussicht gestellt und freuen uns, Ihnen einen Überblick über unsere aktuelle Meinung zu digitalen Inhaberzertifikaten (DBCs) geben zu können. Es liegen noch ein paar Bälle in der Luft mit der Aufschrift „Einmalschlüssel“ und „Werte“, aber wir arbeiten definitiv an einer praktikablen Lösung, die schnell, privat und sicher sein wird.
Wie bei vielen anderen Safe-Innovationen sind die Ziele von DBCs Einfachheit und der Kunde soll die Arbeit tun, wo immer es möglich ist - was normalerweise auf dasselbe hinausläuft. Wir möchten vermeiden, dass Zustände (z. B. Kontostände) im Netzwerk gespeichert werden oder auf bedingte Logik zurückgegriffen werden muss, was beides zu Komplexität führt. Stattdessen führen wir Anti-Entropie in vielen Kommunikationen ein, wo der Fluss ist: versuchen -> Erfolg (weiter) | fail (retry), während die Verfolgung des Status die Aufgabe des Clients ist.
Wir wissen, dass es Sie alle juckt, sich mit einem neuen Testnetz wieder die Hände schmutzig zu machen, aber damit es sich lohnt, möchten wir sicherstellen, dass das Netzwerk mit mehreren Abschnitten stabil ist und AE auf der ganzen Linie ordnungsgemäß funktioniert.
Allgemeiner Fortschritt
Wir versuchen, ein zeitweiliges Problem zu beheben, bei dem verschiedene Älteste in einem Abschnitt unterschiedliche Nachrichten von demselben Knoten erhalten (dies sollte nicht passieren) und / oder verschiedene Erwachsene auswählen, um denselben Block zu speichern. Auch Älteste schreiben manchmal Daten, was die Aufgabe der Erwachsenen ist. @Qi_Ma und @lionel.faber haben sich diese Messaging-Anomalien angesehen.
Wir hatten einen Drang, die Implementierung von AE auf dem Client abzuschließen, wobei @bochaco und @yogesh die Verantwortung führten. Es gibt immer noch einige knifflige Probleme und @lionel.faber hat beim Debuggen von Client AE geholfen und bereits eine der Ursachen für das anomale Verhalten identifiziert, da Älteste unterschiedliche Abschnittsschlüssel haben.
@oetyng hat seinen Refactor der Selbstverschlüsselung (der jetzt in main zusammengeführt wurde) abgeschlossen und hat auch daran gearbeitet, den Umgang mit Chunks zu refaktorisieren.
Und @danda hat sich mit der Frage der Denominationen von DBCs beschäftigt: Welche Werte sollten wir bei der Auswahl der Denominationen für unsere Währung wählen und warum? Was eine einfache Frage zu sein scheint, beinhaltet tatsächlich einige interessante Kompromisse zwischen der Netzwerkeffizienz und der Benutzerfreundlichkeit.
Eine Übersicht über DBCs
Ein DBC ist ein einzigartiger „digitaler Gutschein“, der einen Wert hat, da er nachweislich von einer vertrauenswürdigen Münzstätte als Teil eines Wirtschaftssystems ausgestellt wurde. Um einen DBC auszugeben, müssen Sie ihn von einer Münzstätte neu auflegen lassen. Die Münzstätte kann Ihren DBC nehmen und ihn auf Wunsch als zwei oder mehr neue DBCs neu ausgeben (z.
Wichtig für uns ist, dass DBCs eine schnelle, sichere und flexible Zahlungsmethode bieten, die mit der Multisig/Threshold-Signatur-Kryptographie kompatibel ist und online und offline verwendet werden kann. Sie vereinfachen viele Aspekte der Safe Network Economy.
Der aktuelle Stand der Dinge
Derzeit umfasst unser DBC-System Folgendes:
Sharding: Die Mint wird zwischen Abschnitten aufgeteilt, sodass jeder Abschnitt nur für die Neuausgabe bestimmter DBCs verantwortlich ist, die durch den DBC-Namen/die DBC-ID bestimmt werden.
Dezentrale Münzknotenpunkte: Innerhalb einer Sektion arbeiten einzelne Münzknotenpunkte (Älteste) autonom, ohne Koordination. Ein Client, der eine Neuausstellungsoperation durchführt, muss einen ReissueShare von einer übergroßen Mehrheit von Mint-Knoten (mindestens 5 von 7) erhalten. Jeder ReissueShare enthält einen BLS SignatureShare. Der Client kombiniert diese SignatureShare, um eine vollständige Signatur zu erhalten. Der Kunde fügt diese Signatur dem DBC-Inhalt hinzu, um einen vollständigen DBC zu bilden, der zur Ausgabe bereit ist.
DBC-Besitz: Jeder DBC hat einen Besitzer, der durch einen PublicKey identifiziert wird. Dadurch können DBCs im Klartext gespeichert und übertragen werden, ohne dass sie jemand stehlen kann. Die Münzprägeanstalt überprüft, ob der Besitzer jeden eingegebenen DBC ordnungsgemäß signiert hat, wenn er ausgegeben (neu ausgestellt) wird.
Ausblenden von Beträgen: DBC-Beträge werden ausgeblendet, sodass nur der Sender und der Empfänger sie erkennen können. Nicht einmal die Münzknoten können die Menge sehen. Dennoch kann die Münzstätte durch die Verwendung von Pedersen-Verpflichtungen und Reichweitennachweisen (Bulletproofs) überprüfen, ob die Summe der Eingabe-DBCs mit der Summe der Ausgabe-DBCs übereinstimmt.
Spentbook: Jeder Mint-Knoten schreibt in ein Spentbook. Bei jeder Neuausgabe überprüft der Mint-Knoten zuerst, ob sich nicht alle Eingabe-DBCs bereits im Spentbook befinden (nicht ausgegeben wurden) und dass alle Signaturen und Ausgaben korrekt sind. Es zeichnet dann jede Eingabe auf, wie sie im Spentbook ausgegeben wurde. Idealerweise möchten wir dies auf den Client verschieben, siehe unten.
Zukünftige Verbesserungen
Wir prüfen noch, wo wir Verbesserungen am DBC-System vornehmen können, und die folgenden werden alle in Betracht gezogen:
Einmalige Schlüssel: Die Mint-Knoten würden erzwingen, dass jeder öffentliche Schlüssel nur in einer einzigen Neuausstellungstransaktion verwendet werden kann. Dies kann beim Datenschutz helfen, da es verhindert, dass Schlüssel in mehreren Transaktionen verwendet werden.
Client schreibt an Spentbook: Bei dieser Konfiguration schreibt der Client Spentbook-Einträge, bevor er den . kontaktiertMinze. Dies hat den Vorteil, dass der Neuausstellungsaufruf idempotent wird, was bedeutet, dass ein Client denselben Neuausstellungsaufruf viele Male tätigen und jedes Mal dieselbe Antwort erhalten kann.
Blinde Unterschriften: Dies würde uns ein wirklich eigentümerloses „Inhaber“-Zertifikat bringen. Eine reine Form von unauffindbarem digitalem Bargeld, wenn Sie so wollen.
Public Spentbook: Die Veröffentlichung des Spentbooks wird als wünschenswert/notwendig angesehen, damit die Öffentlichkeit die Geldmenge prüfen kann, d. h. um zu überprüfen, dass weder durch Betrug/Diebstahl noch durch Bugs/Fehler zusätzliches Geld geschaffen wurde.
Für alle, die tiefer eintauchen möchten, befindet sich unser DBC-Code in der sn_dbc-Kiste.
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!