Safe Network Entwickler Update ­čçę­čç¬ 2. September 2021

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!