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

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 :slight_smile: 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:

  1. MintNode-Peers innerhalb eines Abschnitts.
  2. Sharding: Jede Sektion ist f├╝r eine Untermenge von DBCs verantwortlich.
  3. Kundenaggregation
  4. 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!