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 
Eine Erinnerung von @roland, warum wir einige Teile des SectionTree neu implementiert haben…
Der
SectionTree(früherNetworkPrefixMap) 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/Nodeeine andere Netzwerkansicht haben kann, kann derSectionTreezwischen 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!