Safe Network Entwicker Update 05. November 2020

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Safe Network Dev Update - November 05, 2020

Zusammenfassung
Hier sind einige der wichtigsten Dinge, die seit dem letzten Dev-Update 5 hervorzuheben sind:

Unsere Einführung von Proptesting 6 hat Früchte getragen, wobei diese Woche einige wichtige Probleme identifiziert wurden.
Signifikante Leistungsverbesserungen des Netzwerk-Startvorgangs wurden hier zusammengeführt 5, weitere Verbesserungsvorschläge sind hier in Arbeit 6.
Unser CRDT-Berater hat diese Woche wieder mit uns gearbeitet und sich direkt in die Verbesserung von Deterministic Secure Broadcast (DSB) mit Unterstützung für dynamische Mitgliedschaft gestürzt.
Hut ab vor dem Forumsmitglied @treslumen für seinen Beitrag zu sn_api hier 15. :clap:

Sicherer Client, Knoten und qp2p
Sichere Netzwerkübertragungen Projektplan 6
Sicherer Client Projektplan 3
Sicherer Netzwerkknoten Projektplan 1

Wir haben in dieser Woche unsere Sequenzdaten auf Vordermann gebracht, beginnend mit verschiedenen Tests, um sicherzustellen, dass die CRDT-Daten unter verschiedenen Umständen wie erwartet konvergieren. Wir haben einen möglichen Fehler in der Anwendung von Berechtigungsrichtlinien entdeckt und arbeiten an einem Fix sowie an spezifischeren Tests für diesen speziellen Bereich.

Außerdem haben wir begonnen zu untersuchen, wie wir das Berechtigungssystem der Sequence Data für Map-Daten nutzen können, mit dem Ziel, es CRDT-fähig zu machen. Erste Untersuchungen deuten darauf hin, dass es so aussieht, als könnten wir das im großen Stil anwenden, also richten wir im Moment die Grundlagen dafür ein und, vorausgesetzt, es gibt keine Blocker, werden wir danach mit Tests beginnen.

Bei sn_node haben wir diese Woche einen Fehler in der Nachrichtenübermittlung zwischen den Abschnitten gefunden, der zeitweise verhindert, dass Clients Daten in das Netzwerk hochladen können, was durch fehlgeschlagene Datentests in unserem internen Testnetz deutlich wurde. Alle Nachrichten des Netzwerks führen eine Liste von Entitäten/Behörden, die sie durchquert haben, um ihr Ziel zu erreichen, die nicht korrekt aktualisiert wurde, damit ihre Antwort zurückkommt. Ein Refactor und ein Fix für dieses Problem sind in Arbeit und sobald es beseitigt ist, sollten wir wieder auf dem richtigen Weg sein, um das Testnet weiter voranzutreiben.

Wir haben auch gerne einen PR 15 von Forumsmitglied @treslumen angenommen, der einige veraltete Codes nach den letzten sn_client Updates entfernt hat. Vielen Dank dafür, @treslumen, wir wissen das sehr zu schätzen :+1:

Übertragungen
In Fortsetzung der letzten Woche wurde weiter an der Verbesserung der Anonymität und Konsistenz gearbeitet.
Wir sind auch zurückgekehrt, um Digital Bearer Certificates (DBCs) genauer zu betrachten und zu sehen, wie wir sie verwenden können, nachdem wir mit CRDTs und AT2 große Fortschritte gemacht haben.

Ein DBC ist ein Mechanismus, mit dem ein Token oder Zertifikat gehalten und dann verwendet werden kann. Was DBCs uns geben können, wenn wir es schaffen, ein paar Dinge zu lösen, ist volle Anonymität und Offline-Transaktionen.

CRDTs
Diese Woche hat unser CRDT-Berater mit der Arbeit begonnen, um Deterministic Secure Broadcast (DSB) mit Unterstützung für dynamische Mitgliedschaft zu erweitern. Dynamische Mitgliedschaft ist der Prozess, durch den neue Peers sicher einer Peer-Gruppe (Sektion) beitreten oder diese verlassen können, indem die bestehenden Mitglieder darüber abstimmen bzw. zustimmen.

Der Austrittsfall ist am interessantesten, weil er die Erkennung beinhaltet, wenn ein Peer fehlerhaft ist und dann andere Mitglieder darüber abstimmen, den fehlerhaften Peer auszuschließen. Ein Peer kann aus vielen Gründen als fehlerhaft angesehen werden, z. B. wenn er nicht mehr reagiert, das falsche Protokoll verwendet, schlechte Daten sendet oder ungültige Signaturen sendet.

Zur Erinnerung: DSB ist ein byzantinisches fehlertolerantes (BFT) Protokoll, das derzeit zur Sicherung von AT2-Übertragungen verwendet wird. Es ist auch für die Sicherung von CRDT-Algorithmen nützlich.

Es wird erwartet, dass DSB mit dynamischer Mitgliedschaft eine solide Grundlage für zukünftige Routing-Verbesserungen bildet, da sich die Abschnitte regelmäßig über das Hinzufügen und Entfernen von Ältesten und anderen Knoten einigen müssen.

Routing
Projektplan 6

Um sicherzustellen, dass die Tests auf Routing-Ebene dieselbe Netzwerkkonfiguration wie die geplante Testnetzkonfiguration verwenden, haben wir uns entschieden, NetworkParams zu entfernen und const-Wert für Testnetz 2 zu verwenden. Dies erzwingt die Verwendung der gleichen konstanten Werte für die Größe eines Abschnitts und die elder_size eines Abschnitts in den Tests auf Routing- und Knotenebene.

Diese Woche haben wir auch den Netzwerk-Startvorgang 5 überarbeitet, um die Startleistung zu verbessern. Wir haben den DKG unknown message bounce-back durch einen einfachen Backlog während des Starts ersetzt, wodurch die Zeit, die eine erste Sektion benötigt, um sich vollständig mit all ihren Elders zu bilden, von Minuten auf Sekunden reduziert wurde. Außerdem wurde ein Proptest für DKG hinzugefügt, um die Codequalität und die Zuverlässigkeit des Netzwerks weiter zu gewährleisten.

Weitere Verbesserungen für die Startphase des Netzwerks wurden ebenfalls in diesem PR 6 vorgeschlagen, der sich derzeit in der Testphase und im Peer Review befindet. Während der Startphase wird jedes Kleinkind, das beitritt, sofort in denselben Abschnitt zurückversetzt, allerdings mit erhöhtem Alter. Dadurch wird der Prozess leicht verändert, so dass das neue Alter pseudozufällig aus einem gegebenen Altersbereich generiert wird, wodurch verhindert wird, dass die Peers das gleiche Alter haben, was dazu führen würde, dass sie zur gleichen Zeit verschoben werden. Außerdem wird die Verlagerungsberechnung aktualisiert, so dass nur die ältesten Knoten verlagert werden.

Wie bereits im Abschnitt „Knoten“ erwähnt, wurde in einem internen Testnetz ein Problem gefunden, bei dem die Nutzlast von Abschnitt-zu-Abschnitt-Nachrichten von Knoten zum Routing nicht immer identisch zwischen Ältesten und Clients war. Ursprünglich wurde angenommen, dass es sich um einen Fehler in der Routing-Schicht handelte, aber nach einigen Untersuchungen haben wir das Problem zu den Knoten zurückverfolgt und es liegt nun in deren Händen.

Nützliche Links
Safe Network-Website 3
Safe Network Fibel 1
Netzwerk-Grundlagen
Fahrplan 19
Glossar