Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 16 September, 2021
Diese Woche gehen wir etwas genauer auf Distributed/Sharded Mints ein, wie sie mit DBCs und Datenschutz zusammenpassen und was sie sowohl für das Netzwerk als auch für die Benutzererfahrung bedeuten.
Allgemeiner Fortschritt
David Rusu und @danda experimentierten damit, ihrer Arbeit an blinden Signaturen erzwungene Einmalschlüssel hinzuzufügen und den Client auch dazu zu bringen, in das Spendbook zu schreiben. Noch in Arbeit, sieht aber bisher gut aus.
Viele Bugfixes diese Woche. Wir haben mit einem weiteren Node-Speicherproblem im Zusammenhang mit File-Puts zu kämpfen. Diese Speicherspitzen wurden durch ein Nachrichtenverstärkungsproblem verursacht, das durch die AE-Flüsse beim Client sowie von Erwachsenen zurück zu den Clients verursacht wurde. Fixes für diese wurden jetzt zusammengeführt und der Speicherverbrauch wurde erheblich reduziert.
Aus diesem Grund haben wir damit begonnen, mehr Zusammenfassungen zum Messaging im Netzwerk zu erhalten, wobei die Knoten so eingestellt sind, dass sie diese Statistiken zusammen mit ihrer Ressourcennutzung in den Protokollen ausgeben. Sobald wir dies eingerichtet haben, werden wir versuchen, all diese Informationen in unseren Testsystemen zu verwenden, um sicherzustellen, dass sich keine weiteren Verstärkungsfehler einschleichen können.
In diesem Zusammenhang hat sich @chris.connelly in qp2p vertieft und einige der nicht mehr benötigten Verbindungspooling-Funktionen entfernt.
@oetyng implementiert den Umgang mit Gegendruck (Widerstand oder Kraft, die dem gewünschten Datenfluss durch Software entgegensteht). Die Idee ist, dass ein Knoten seine CPU-Last überprüft, wenn er Anfragen entgegennimmt. Wenn es über einem bestimmten Niveau liegt, wird eine Nachricht mit der CPU-Last zurückgegeben. Der empfangende Knoten kann dann seine Kommunikation basierend auf diesen Informationen regulieren. Nach einer Weile kehren sie zu den Standardeinstellungen zurück.
Es ist nicht erforderlich, diese Informationen zu synchronisieren oder eine Vereinbarung zu treffen. Der Umgang mit Gegendruck ist wie Verkehrsrichtlinien. Wenn die meisten Fahrer die Verkehrsrichtlinien befolgen, fließt der Verkehr reibungsloser, auch wenn es einige verrückte Fahrer gibt 
Das heißt, obwohl ein fehlerhafter Knoten die Richtlinien nicht befolgen könnte, da die meisten Knoten im Netzwerk korrekt funktionieren und die Richtlinien befolgen, der Verkehr wird im Vergleich zum Fehlen dieser Richtlinien verbessert.
Das ist zumindest die Idee, und das werden wir jetzt noch einige Zeit ausprobieren. Es ist eine neue Dimension der Netzwerkkommunikation, ähnlich wie es AE war, und es wird Zeit brauchen, um sich einzugewöhnen.
Der Fehler der Wahl von @Anselme war der Selbstverschlüsselungsprozess, der einige verwirrende Fehler aussendete, die einige Komponententests zum Absturz brachten. Er überlegt nun, das NRS zu refaktorisieren, um es zu vereinfachen.
Inzwischen hat @Lionel.faber die Art und Weise verbessert, wie GitHub Actions funktioniert, um die Bereitstellung von Testnetzen auf Digital Ocean zu automatisieren, was beim Team sehr gut ankommt, und @Qi_Ma hat einige anomale Verhalten mit AE herausgefunden. Mit jedem zerquetschten Bug kommen wir ein bisschen näher.
Oh und wir haben uns sehr über eine PR von @davidpbrown gefreut. Toll, dass Community-Mitglieder beteiligt sind. Wenn jemand etwas beitragen möchte, müssen Sie zuerst das Repo abspalten - mehr hier.
DBC-Mints
DBC Mints gibt es seit den 90er Jahren, aber sie wurden nie sehr beliebt.
Ein schwerwiegendes Problem, das die Einführung verhindert, besteht darin, dass sie in der Regel zentralisiert wurden und daher erfordern, dass Benutzer des Systems (Tokeninhaber) dem Münzbetreiber vollständig vertrauen. Ein gieriger Münzbetreiber könnte die Geldmenge aufblähen, ohne dass jemand etwas davon mitbekommt, und so allen Benutzern den Wert stehlen. Außerdem könnte der Münzbetreiber einfach verschwinden und alle Token werden über Nacht wertlos. Man muss dem Münzbetreiber also nicht nur heute, sondern auch morgen vertrauen und auch darauf, dass kein Dritter, Hacker, Insider oder Regierung Einfluss auf seinen Betrieb nehmen kann.
Die Dezentralisierung über Sektionen (Sharding) ist ein zentrales Merkmal des Safe Network Designs. Das SN DBC-Design nutzt und baut darauf auf, um eine Mint zu erstellen, die sowohl dezentral als auch skalierbar ist. Bis heute hat keine eingesetzte Kryptowährung[1] dezentralisierte DBC-Mints integriert, die uns bekannt sind. Dies ist also eine neue Entwicklung. Unser Ziel ist es, mit sofortigen (und privaten) Transaktionsabwicklungen auf die weltweite Nutzung zu skalieren.
Die Dezentralisierungsfunktionalität kann in einige Hauptbereiche unterteilt werden:
- MintNode-Peers innerhalb eines Abschnitts.
- Sharding: Jede Sektion ist für eine Untermenge von DBCs verantwortlich.
- Kundenaggregation
- Vom Kunden geschriebenes Distributed Spentbook
Schauen wir uns jeden von ihnen an.
MintNode-Peers innerhalb eines Abschnitts.
Innerhalb eines Abschnitts wird jeder Elder auch als MintNode bezeichnet. Somit gibt es 7 Knoten, während andere bereit sind und darauf warten, jeden ausgefallenen Knoten zu ersetzen. Wenn der Abschnitt gebildet wird oder sich die Mitgliedschaft ändert, führen die Knoten eine Runde der Distributed-Key-Generation (DKG) durch, um einen gemeinsamen BLS-Schlüssel zu erstellen. Dies ist ein Multi-Sig-Schlüssel, sodass 5 der 7 (Supermehrheits-)Knoten ein Datenelement signieren müssen, damit es als gültig gilt. Bei DBCs werden die signierten Daten als ReissueShare bezeichnet. DieseReissueShares müssen von einer Super-Mehrheit von Knoten in einem Abschnitt gesammelt werden, um die Neuausgabe der von diesem Abschnitt verwalteten DBCs abzuschließen.
Nehmen wir an, einer der Knoten ist bösartig. Vielleicht hat sich ein Client mit einem Knoten zusammengetan, um einen seiner DBCs zu verdoppeln. Der bösartige Knoten könnte mit einem betrügerischen ReissueShare für die doppelte Ausgabe reagieren, aber diese Freigabe allein ist nutzlos.
Außerdem ist es in Bezug auf Zeit und Ressourcen schwierig, überhaupt ein Mint Node (Sektionsältester) zu werden. Das sichere Netzwerk hat ein Konzept des Knotenalters, bei dem sich erwachsene Knoten im Laufe der Zeit als zuverlässig und ehrlich erweisen müssen. Nur der dienstälteste Erwachsene wird als Ältester ausgewählt, wenn ein bestehender Ältester verschwindet. Darüber hinaus kann ein Knoten nicht auswählen, in welchem Abschnitt er sich befindet. All diese Strategien machen es einem Angreifer schwer, mehrere bösartige Knoten in einem Abschnitt zu erreichen, der für seine DBC-Aktivität relevant ist.
Sharding: Jeder Abschnitt ist für eine Untermenge von DBCs verantwortlich.
Sharding ist ein allgemeiner Begriff, der das Aufbrechen von Daten bedeutet, damit verschiedene Server Teilmengen der Daten verarbeiten.
Unser Sharding-Ansatz ist eigentlich ganz einfach. Der Ausgabeschlüssel der DBCs (ein universell eindeutiger Einmalschlüssel) bestimmt, welcher Abschnitt für die Handhabung verantwortlich ist. Die Client-Software ist dafür verantwortlich, eine identische ReissueRequest an alle Mint-Knoten in allen Abschnitten zu senden, die den DBC-Eingaben in der ReissueRequest entsprechen.
Im folgenden Beispiel haben wir 3 Eingaben, von denen jeder von verschiedenen Sektionen behandelt wird, jede Sektion antwortet mit einer Super-Mehrheit (5 von 7) der Wiederausgabe von Aktien.
Während ein MintNode die Eingabe-DBCs durchläuft, prüft er für jeden, ob er verantwortlich ist oder nicht. Wenn ein MintNode für einen DBC verantwortlich ist, wird das Spentbook konsultiert, ob dieser DBC bereits ausgegeben wurde. Ein MintNode ReissueShare bietet also nur SignatureShare für die DBCs, für die eine bestimmte Sektion autorisiert ist.
Client-Aggregation
Wenn ein Benutzer einen DBC neu ausgeben möchte, kontaktiert die Client-Software des Benutzers jeden der 7 MintNodes für die Sektion(en), die für die Eingabe-DBC(s) verantwortlich sind, und sendet eine ReissueRequest. Jeder Knoten validiert die Anfrage, und wenn alles richtig ist, antwortet er mit einem ReissueShare, der ein BLS SignatureShare enthält.
Die Client-Software sammelt die ReissueShare-Antworten von allen kontaktierten MintNodes und prüft sie. Wenn mindestens 5 Knoten in einem bestimmten Abschnitt richtig geantwortet haben, kann der Client ihre SignatureShare kombinieren, um eine endgültige Mint-Signature für jeden Ausgabe-DBC zu bilden. Mit der Signatur in der Hand konstruiert der Client dann die tatsächlichen DBC(s), die später als Eingabe für eine weitere Neuausgabe gesendet werden können.
Distributed Spentbook vom Kunden geschrieben
Dies ist eine Funktion in der Entwicklung. Die Grundidee besteht darin, dass der Client eine bestimmte ReissueTransaction festlegt und diese Commitment, identifiziert durch den Ausgabeschlüssel der DBC (oder einen Hash des Schlüssels), im sicheren Netzwerk veröffentlicht, bevor er eine ReissueRequest macht. Jeder MintNode muss dann nur noch den Spentbook-Eintrag für jeden DBC lesen und überprüfen, ob der Eintrag vom DBC-Besitzer korrekt signiert ist. Dies vereinfacht die Operationen für den MintNode, der keine Daten mehr schreiben muss, und hält die Reissue-API des MintNodes idempotent. Mit anderen Worten, der Client kann reissue viele Male mit demselben ReissueRequest aufrufen und erhält immer dieselbe Antwort.
Wir planen, in einem späteren Update näher auf das Spentbook einzugehen.
[1] Im Jahr 2019 wurde ein Whitepaper veröffentlicht, das ein dezentralisiertes DBC-Mint-System namens Scrit beschreibt. Das Design von Scrit unterscheidet sich wesentlich von unserem und scheint zum Zeitpunkt dieses Schreibens noch nicht öffentlich eingesetzt worden zu sein.
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!