Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 10 November, 2022
Ein kleiner Vorgeschmack auf die kommenden Wochen. Wie Sie wissen, sind Konsensmechanismen das Herzstück fast aller dezentralisierten Netzwerke, einschließlich Bitcoin. Tatsächlich ist die Hauptinnovation von Bitcoin wohl der Konsensmechanismus der Blockchain. Aber es gibt immer einen Kompromiss. In Bitcoin und anderen Blockchains ist es der Fork-Handling-Mechanismus, was bedeutet, dass zwei Versionen für lange Zeit (theoretisch für immer) existieren können und über PoW, die Achillesferse von Bitcoin, gelöst werden müssen.
Daher waren wir bestrebt, Konsensalgorithmen (wie sie allgemein verstanden werden) nach Möglichkeit zu vermeiden – verwenden Ameisen sie? Aber es gibt Fälle, in denen sie bei Computernetzwerken wahrscheinlich notwendig sind. Dies ist, was Mostafa untersucht hat, und wir werden uns in den kommenden Wochen eingehender damit befassen.
Allgemeiner Fortschritt
Im Moment überarbeiten wir den CI-Maschinenprozess, um ihn etwas schlanker und sicherer zu machen. Das ist sehr viel @chrisos Baby und er hat daran gearbeitet, alle Elemente an Ort und Stelle zu bringen, einschließlich der APIs, EC2-Instanzen, serverlosen Funktionen und des DDoS-Schutzes. Jetzt fast da.
Wir arbeiten daran, während der Datenreplikation so viele Lese-/Schreibsperren wie möglich zu entfernen. Dies ist hauptsächlich die Domain von @joshuef. Josh und @bochaco haben auch den „sn_node“-Refactor so gut wie abgeschlossen, um bidirektionale Kommunikation wieder in den Code einzuführen. Das hatten wir schon einmal, aber es wurde sehr komplex. Die Vereinfachung der Codebasis bedeutet, dass wir sie zurückbringen können. Wir testen noch, aber wir sehen bereits Stabilitätsverbesserungen.
@roland entfernt die Traceroute-Funktion. Es verursacht Blähungen, es hat sich nicht als nützlich erwiesen (und noch weniger bei bidirektionalen Streams), also werden wir es los.
Konsensmechanismen
In der Informatik gibt es viele Konsensmechanismen. Einige sind einfache binäre Angelegenheiten, andere sind komplexe Mechanismen mit mehreren Varianten. Es ist jedoch wichtig zu verstehen, dass sie alle nur Werkzeuge für einen Job sind und nicht mehr. Diese Aufgabe besteht darin, die Vereinbarung zwischen den Entitäten für eine bestimmte Zeit sicherzustellen. Aber so wie sich die Menschen auf bestimmte Regeln einigen müssen, um miteinander auszukommen, wie zum Beispiel auf welcher Straßenseite sie fahren sollen, müssen sie sich nicht auf alles einigen, um Seite an Seite zu leben. Im Gegensatz zu Blockchains brauchen Menschen keine systemweite Bestellung, und Safe auch nicht. Wir müssen also das richtige Werkzeug für die Aufgabe auswählen, dies nur tun, wenn es notwendig ist, und vor allem sicherstellen, dass wir nicht durch diese Wahl eingeschränkt werden.
Safe ist ein asynchrones dezentrales Netzwerk. Die Dinge ändern sich ständig; „Zustand“, also eine Momentaufnahme unseres aktuellen Weltverständnisses, ist aus Sicht jedes einzelnen Knotens fast immer unterschiedlich. Und doch müssen sich diese Knoten zumindest für kurze Zeit einigen.
Konsens ist im Grunde ein Wort, das besagt, dass zu einem bestimmten Zeitpunkt jeder, der wichtig ist, denselben Zustand sehen muss, damit eine Aktion stattfinden kann.
Wie erreichen Knoten also eine Einigung über den Zustand? Nun, das hängt von den Umständen, der Aktion und dem Umfang ab.
Auf Safe können wir oft durch Anti-Entropie (AE) eine Einigung erzielen. Dies ist ein einfacher Informationsaustausch, um sicherzustellen, dass wir mit den derzeitigen Ältesten in einer Sektion sprechen. Als solches könnte AE als einfacher, binärer, lokaler Konsensmechanismus angesehen werden, obwohl wir es nur als eine Überprüfung betrachten, dass Parteien, die synchron sein müssen, alle auf derselben Seite stehen. Sicherlich ist es weit entfernt von der gesamten systemweiten Ordnung von Bitcoin.
Wenn Älteste eine Vereinbarung über eine Vorgehensweise treffen, verwenden wir die verteilte Schlüsselgenerierung (DKG), um sicherzustellen, dass eine große Mehrheit der Ältesten zustimmt. Auch das ist eine Art lokaler, binärer (ja/nein) Konsens, obwohl wir dieses Wort eher nicht verwenden.
Dann haben wir konfliktfrei replizierte Datentypen (CRDTs), die wir für veränderliche Daten verwenden. Diese haben eine logische Uhr, ermöglichen gleichzeitigen Zugriff und lösen Gabelungen schließlich in einen Zustand auf. Das alles geschieht ohne jeden Konsens. Gabeln sind in Ordnung und selbstauflösend.
Aber dann gibt es andere Situationen, in denen wir einen Fork nicht einmal für eine Nanosekunde tolerieren können, und da brauchen wir als asynchrones dezentrales Netzwerk definitiv einen Konsens.
Und es gibt Grauzonen, in denen wir Forks für eine gewisse Zeit tolerieren können, sie aber irgendwann lösen müssen. Diese erfordern möglicherweise einen formellen Konsensmechanismus.
Wo brauchen die Ameisen also technische Hilfe? Man rekrutiert neue Nodes aus einer Liste von vielleicht Hunderten von Kandidaten, alle mit einem Node-Alter von null – welchen wählen wir aus? Hier müssen wir uns möglicherweise auf eine höhere Intelligenz verlassen, die die Gruppe bereitstellen kann.
Eine andere ist die Mitgliedschaft – die Verwaltung, welche Knoten sich in einem Abschnitt befinden. DKG ist ein stumpfes Instrument und bewältigt Randfälle wie mehrere gleichzeitige Joins und Leaves nicht sehr gut.
Und wir brauchen möglicherweise ein höheres Maß an Konsens, um DBCs bereichsübergreifend zu verwalten und doppelte Ausgaben zu vermeiden.
Darauf konzentriert sich das Team – insbesondere Mostafa und @davidrusu – im Moment: das richtige Protokoll zur richtigen Zeit am richtigen Ort zu implementieren. Mehr bald Leute!
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!