Safe Network Entwickler Update đŸ‡©đŸ‡Ș 22. September 2022

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 22 September, 2022

Diese Woche gibt es an der technischen Front nichts Wichtiges zu berichten, also bleiben wir bei einem allgemeinen Fortschrittsbericht und nicht bei dem ĂŒblichen tiefen Tauchgang. Mehr zu berichten gibt es jedoch von der Teamfront, wo wir uns freuen, ein neues Teammitglied begrĂŒĂŸen zu dĂŒrfen. Mostafa ist ein erfahrener Blockchain-Entwickler aus Malaysia.

Willkommen im Team, Mostafa!

Hi. Das ist Mostafa. Ich bin ein Softwareentwickler. Schön, dich kennenzulernen.

Als ich Student war, beschloss ich einmal, einen alten Feuertempel (ein GebĂ€ude, das mehr als 2000 Jahre alt ist) zu besuchen, der sich an einem wilden Ort befand. Es war schwierig, den Feuertempel zu finden, also bat ich einige Einheimische, mir zu helfen. Interessanterweise nannten sie es das „Teufelshaus“ und als ich sie fragte, warum, sagten sie: „Weil Menschen so etwas nicht bauen können, muss es der Teufel sein“. Daran dachte ich kĂŒrzlich, als ich die Geschichte von TeufelsbrĂŒcken in Europa las. Die BrĂŒcken, die vor Jahrhunderten gebaut wurden und noch funktionieren. Die Leute nennen sie TeufelsbrĂŒcken, weil sie nicht glauben können, dass ein Mensch sie gebaut hat, es muss der Teufel sein.

Niemand weiß, wer die TeufelsbrĂŒcke oder den Feuertempel gebaut hat, aber sie stehen noch. Lasst uns ein Teufelsnetzwerk aufbauen!

Allgemeiner Fortschritt

Die SectionTree-Arbeit ist nun erledigt :muscle:
Eine Erinnerung von @roland, warum wir einige Teile des SectionTree neu implementiert haben


Der SectionTree (frĂŒher NetworkPrefixMap) ist eine Datenstruktur, die unser aktuelles Wissen ĂŒber das Netzwerk kapselt. Man kann es sich als einen Baum vorstellen, bei dem jeder Knoten ein „SectionKey“ ist, der von seinem ĂŒbergeordneten „SectionKey“ signiert ist, mit Ausnahme des Wurzelknotens („genesis_key“). Die BlĂ€tter des Baumes halten auch den SAP des Abschnitts, wĂ€hrend sie die SAPs der NichtblĂ€tter verwerfen.

Da jeder Client/Node eine andere Netzwerkansicht haben kann, kann der SectionTree zwischen den Teilnehmern stark variieren. DarĂŒber hinaus ist es notwendig, Teile des Baums (SectionTreeUpdate, das die Beweiskette + SAP bĂŒndelt) an alle zu senden, die dies anfordern, und sich darauf verlassen zu können, dass sie ihren Baum nicht durcheinander bringen, wĂ€hrend sie versuchen, ihn zu aktualisieren.

Die „SecuredLinkedList“ wurde zuvor verwendet, um den „SectionTree“ zu erstellen, aber sie hatte einige Probleme, die zu falschen EinfĂŒgungen fĂŒhrten, und sie war nicht CRDT-konform. Daher wurde es als CRDT (insbesondere „MerkleRegister“) neu implementiert und die alte „SecuredLinkedList“ durch das neue „SectionsDAG“ ersetzt. Jetzt können wir sicher sein, dass es sich wie erwartet verhĂ€lt, unabhĂ€ngig von der Reihenfolge oder LĂ€nge des Updates!

@roland ist jetzt mit @anselme zum Testen der verteilten SchlĂŒsselgenerierung (DKG) ĂŒbergegangen. Wie in den letzten Wochen erlĂ€utert, gab es Probleme mit dem DKG-Prozess, der nicht immer beendet wurde. Nach einigen intensiven Tests sieht es jetzt ziemlich stabil aus und @anselme schreibt einige Dokumentationen fĂŒr den Testprozess.
Eine Anmerkung von Anselme zum bevorstehenden DKG


Die kommende DKG, robuster und ohne Timer

Der DKG-Prozess ist derzeit ein aktiver Prozess, der Timer verwendet, die bei starker NetzwerkaktivitĂ€t hĂ€ufig aufgrund von ZeitĂŒberschreitungen fehlschlagen. Wir haben kĂŒrzlich an einem neuen DKG gearbeitet, das keine Timer verwendet, sondern es ermöglicht, Nachrichten zu verzögern und schwere Paketverluste zu unterstĂŒtzen. Wenn Knoten fĂŒr eine Weile keine Nachrichten erhalten, klatschen sie ihr Wissen an die anderen in der Hoffnung, sie auf den neuesten Stand zu bringen oder sogar Updates von ihnen zu erhalten, wenn die gesendeten Informationen veraltet sind. Auf diese Weise erreicht schließlich jeder Knoten die DKG-Terminierung.

Wir umfassen jetzt auch gleichzeitige DKGs mit dieser neuen Implementierung. Es ist jetzt ein Wettlauf zwischen DKGs und der Gruppe der Kandidaten, die das Ende erreicht, bevor die anderen die Chance bekommen, die neue Gruppe der Ältesten zu werden. Einige DKG-Sessions könnten ins Stocken geraten oder zu spĂ€t enden, aber wir betrachten sie nicht als FehlschlĂ€ge, sie haben am Rennen teilgenommen und einfach verloren. Wir möchten, dass die nĂ€chsten Ältesten so zuverlĂ€ssig wie möglich sind, daher ist die Wahl des Gewinners in diesem DKG-Rennen fĂŒr uns auch eine Möglichkeit, die besten Knoten auszuwĂ€hlen. Nach einem Abschnittswechsel sind diese DKG-Sitzungen schließlich veraltet, und als die Kandidaten feststellen, dass sie das Rennen verloren haben, wissen sie, dass sie aufhören können.

Ein weiteres dynamisches Duo @bochaco und @chriso hat die DBC-Tests debuggt. Sie haben einen Fehler gefunden, bei dem die SAP (Liste der aktuellen Ältesten) wĂ€hrend des Client-Testprozesses versehentlich entfernt wird, was das Netzwerk destabilisiert.

Unterdessen arbeitet @bochaco im Moment weiter an dem anderen wichtigen AktivitÀtsstrom, rationalisiert die Messaging-Prozesse und verwendet nach Möglichkeit einzelne Threads.

@joshuef und @davidrusu arbeiten auch an Aspekten der Nachrichtenrationalisierung, Josh untersucht das Extrahieren des comms-Moduls aus dem node-Code, um zu sehen, ob sich das besser fĂŒr Multi-Threading eignet, wĂ€hrend David einige davon entkoppelt der Code, der von den sn_node- und network_knowledge-Crates geteilt wird, was hoffentlich einige der Knotenverbindungsfehler beseitigen wird, die wir gesehen haben.


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!