Safe Network Entwickler Update đŸ‡©đŸ‡Ș 25. November 2021

Dies ist eine maschinelle Übersetzung. Das Original in Englisch ist hier: Update 25 November 2021

Wir sind uns alle einig, dass diese Woche ein guter Zeitpunkt wĂ€re, um zu sehen, was Safe in Bezug auf den verteilten Konsens auf den Tisch bringt. Eigentlich dachten ein paar von uns, es sei eine dumme Idee, aber eine Supermehrheit stimmte dafĂŒr, voranzukommen, und das ist alles, was zĂ€hlt :stuck_out_tongue_winking_eye:. In dieser Woche erklĂ€ren wir, wie Safe die LĂŒcke zwischen Blockchain und den Protokollen schließt, die verteilten Datenbanken wie Cassandra und AWS DynamoDB zugrunde liegen.

Allgemeiner Fortschritt

@ChrisO hat die Aufgabe der kontinuierlichen Freigabe von sn und sn_api im safe_network-Repository abgeschlossen. Dies bedeutet, dass wir wieder an einem Ort sind, an dem wir Commits frei zusammenfĂŒhren und auf die nachfolgende Veröffentlichung vertrauen können. Nachdem dies geschehen ist, untersucht @chrisO die CLI und stabilisiert sie, bevor sie in Releases aufgenommen wird.

David Rusu hat eine Demo zu Ringsignaturen und Safe zusammengestellt. Erwarten Sie in KĂŒrze ein Update (Achtung: es wird „schwer in der Mathematik“). :laufender Mann:

@qi_ma , @yogesh und @lionel.faber haben die DKG-Kiste und das safe_network (unsere Hauptquelle fĂŒr Kopfkratzer, da die Beförderungen Ă€lterer Menschen vor sieben aufhören) umgestaltet, um die Anzahl der zu sendenden Nachrichten zu reduzieren und zu erhöhen StabilitĂ€t des Abschnittsstarts und -splits. Die Arbeit geht dort weiter, aber wir erreichen definitiv die zugrunde liegenden Probleme.

Es wurde auch daran gearbeitet, die PrioritĂ€t der Nachrichtenbehandlung fĂŒr Knoten zu aktivieren, obwohl dies noch evaluiert wird. Dies sollte uns dabei helfen sicherzustellen, dass grĂ¶ĂŸere Änderungen energischer behandelt werden als weniger wichtige Nachrichten. Diese Blockierung von Nachrichten mit niedriger PrioritĂ€t war in der weniger gleichzeitigen Codebasis unbeabsichtigt vorhanden, ging jedoch verloren, als wir Knoten freisetzten, um mehr CPU-Leistung zu nutzen. Dies sollte also hoffentlich wieder etwas Ordnung in die Operationen von Node bringen.

Verteilter Konsens und wie Safe die LĂŒcke schließt

Der Kern von Safe Network und das, was es fĂŒr eine Vielzahl von Zwecken einzigartig macht, besteht darin, wie es eine Übereinstimmung zwischen verteilten Knoten erreicht, die möglicherweise unzuverlĂ€ssig sind.

In den 1980er Jahren hielt man eine dezentrale Vereinbarung ohne Bezug auf ein zentrales Orakel fĂŒr unmöglich, aber dann kam Leslie Lamport, um allen das Gegenteil zu beweisen. TatsĂ€chlich versuchte er zu beweisen, dass es tatsĂ€chlich unmöglich war, Konsistenz und Fehlertoleranz zu haben, aber dann stolperte er ĂŒber eine Antwort, die darin bestand, vorĂŒbergehende FĂŒhrungskrĂ€fte zu fördern und eine systemweite Ordnung zu gewĂ€hrleisten.

Der resultierende Algorithmus war Paxos, fĂŒr den Lamport schließlich einen Turing-Preis gewann. Paxos garantiert die letztendliche Konsistenz in einem verteilten Netzwerk, in dem einige Maschinen möglicherweise unzuverlĂ€ssig sind. Dies bedeutet, dass Netzwerke einen Single Point of Failure vermeiden können – jeder Knoten, sogar ein Leader, kann ausfallen und das System funktioniert weiterhin.

Paxos hat sich als Ă€ußerst erfolgreich erwiesen und Hunderte von Nachahmern und Varianten hervorgebracht. Es wird hauptsĂ€chlich fĂŒr die zuverlĂ€ssige Replikation von Daten zwischen verteilten Maschinen verwendet und ist die Grundlage fĂŒr Cloud-Datenbanken wie AWS DynamoDB und Google Chubby.

Es tut dies, indem es versucht, eine Gesamtreihenfolge von Operationen zu bestimmen. Es gibt zwei Phasen in einer Paxos-Operation – versprechen und verpflichten. Ein Versprechen ist eine Vereinbarung, etwas zu tun, und ein Commit ist die Handlung, dies zu tun. Die meisten Knoten mĂŒssen zustimmen, bevor sie versprechen, den Status zu Ă€ndern oder Berechtigungen zu Ă€ndern. Eine Mehrheit ist auch erforderlich, um von einem Versprechen zu einem Commit ĂŒberzugehen, beispielsweise einem Write oder einem EigentĂŒmerwechsel.

Da verteilte Netzwerke asynchron sind, wird die Ordnung aufrechterhalten, indem jeder Operation eine numerische ID zugewiesen und die IDs im Laufe der Zeit erhöht werden. Im Falle eines Konflikts um ein Versprechen gewinnt in der Regel die neueste (höchste ID).

In Paxos gibt es immer einen Leader-Knoten. Bei einem Commit hĂ€ngt der Leader jede Op an sein Log an und fordert die anderen Server auf, dasselbe zu tun. Sobald es von einem Großteil der Server in seinem Cluster gehört hat, ĂŒbernimmt es die Änderung.

Ein neuer Leiter wird gewĂ€hlt, wenn der aktuelle nicht innerhalb einer bestimmten Zeit antwortet. Wenn dies geschieht, kann sich jeder Knoten selbst nach vorne stellen. Um FĂŒhrer zu werden, muss ein neuer Kandidat die Mehrheit der Stimmen erhalten. Es muss dann seine Protokolle aktualisieren, indem es mit anderen Knoten synchronisiert wird. Die Abstimmungsknoten senden ihre Protokolle mit ihren Stimmen, um dies zu vereinfachen, aber die Aktualisierung kann immer noch lange dauern. WĂ€hrend dieser Zeit ist der Cluster inaktiv, was problematisch sein kann.

Raft (2014), das auf Paxos (oder genauer Multi-Paxos, der aktualisierten Version) basiert, vereinfacht den Abstimmungsprozess und andere Operationen, ist aber im Wesentlichen eine Modifikation von Paxos. Raft hat Paxos in Bezug auf die ProjektaktivitĂ€t inzwischen ĂŒberholt.

Soweit so gut, aber obwohl Paxos/Raft elegante Lösungen fĂŒr den verteilten Konsens sind, erfordert ihre Implementierung viele Extras, damit sie wie geplant funktionieren.

Cloudflare basiert auf Raft und im Jahr 2020 hatte einen großen Ausfall, da der AnfĂŒhrerwahlprozess in eine endless-Schleife. Um die Lebendigkeit zu gewĂ€hrleisten, sind auch PreVote- und CheckQuorum-Optimierungen erforderlich und vieles mehr. Jetzt nicht mehr so ​​einfach.

Die Erweiterung der FunktionalitĂ€t von Paxos und Raft und anderen Varianten macht sie komplex, was in der Technologiebranche bedeutet, dass sie proprietĂ€r werden. Wenn nur Amazon weiß, wie man DynamoDB zuverlĂ€ssig einrichtet, wird Amazon dieses Geheimnis nicht so schnell preisgeben.

Der Hauptnachteil dieser Algorithmen ist jedoch ihre Annahme, dass Knoten nicht kollidieren, lĂŒgen oder auf andere Weise versuchen, das Protokoll zu unterlaufen, d. h. es treten keine byzantinischen Fehler auf. Wenn Sie Amazon sind, können Sie dies möglicherweise garantieren, da Sie Ihre eigene Hardware und Software kontrollieren, aber fĂŒr gemischte öffentliche Netzwerke gibt es keine Möglichkeit, dies zu tun. Aus diesem Grund hört man in der Kryptowelt nicht viel ĂŒber Paxos et al, obwohl es die Tech-Goliaths untermauert.

Geben Sie Satoshi ein

Byzantinische fehlertolerante (BFT), dezentralisierte Algorithmen werden von der Blockchain dominiert, die dieses schwierige Problem dank des Genies von Satoshi gelöst hat. Blockchains sind hochgeordnet und BFT. Aber die totale Ordnung ist wichtig, und das blockiert oder verlangsamt den Mehrfachzugriff und die ParallelitĂ€t. Blockchains sind keine Allzwecksysteme, sondern solche, die speziell fĂŒr den Wertaustausch entwickelt wurden. Blockchains können Paxos und seine Derivate nicht ersetzen, da sie fĂŒr die Sicherung und gemeinsame Nutzung von Transaktionen optimiert sind, nicht fĂŒr Datenoperationen.

Tritt beiseite, Satoshi, Safe Network ist da

Sicher ist anders. Es schließt die LĂŒcke zwischen den Store-forever-Transaktionen von Blockchains und dem verteilten Datenmanagement von Paxos und Raft.

Daten werden ohne schweres PoW fĂŒr immer gespeichert.

Es gibt keinen GesamtanfĂŒhrer, der angegriffen werden könnte, nicht einmal einen vorĂŒbergehenden (wie den PoW-Gewinner in einer Blockchain). Stattdessen wird die Verantwortlichkeit zwischen den Sektions-Supermehrheiten verteilt und diese bestehen aus sich stĂ€ndig Ă€ndernden (aber vereinbarten) Gruppen.

Dann haben wir das Problem der Fehlertoleranz. Paxos und Raft verwenden das Konzept der „Crash“-Fehlertoleranz (CFT). Aber öffentliche Netzwerke erfordern byzantinische Fehlertoleranz. Der Unterschied scheint subtil, ist es aber nicht. Die Crash-Fehlertoleranz umfasst, wie viele Knoten zwischen WartungslĂ€ufen ausfallen können, wĂ€hrend die byzantinische Fehlertoleranz beschreibt, wie viele Knoten zu einem beliebigen Zeitpunkt ausfallen können. CFT ist berechenbar, BFT nicht.

Safe ist BFT und wurde entwickelt, um fĂŒr reale Bedingungen gerĂŒstet zu sein, in denen Dinge scheitern und UnglĂŒckliche herumlaufen. Das Knotenalter stellt sicher, dass byzantinische Knoten schnell entmachtet werden. Im Gegensatz dazu werden Paxos/Raft leicht angegriffen, wenn ein AnfĂŒhrer befördert wird, der nicht oder zu schnell antwortet. Sie verlassen sich auch in gewissem Maße auf Serveruhren, um den Konsens zu verwalten. Sie scheinen einfach zu sein (wie Kademlia-Netzwerke), aber sie brauchen viele Vorbedingungen, damit sie funktionieren, einschließlich vertrauenswĂŒrdiger Hardware und Software, kein NAT-Traversal usw.

Safe ist vollstĂ€ndig dezentralisiert. AE, BRB und CRDTs machen eine netzweite Vereinbarung ĂŒberflĂŒssig, um Konsistenz zu erreichen, und es besteht keine Notwendigkeit fĂŒr eine Gesamtbestellung. Selbst Amazon rĂ€umt ein, dass bei großen verteilten Systemen das Spiel letztendlich Konsistenz und keine totale Ordnung ist (Lichtgeschwindigkeit ist eine harte Grenze). Der Versuch, in großem Maßstab eine Gesamtordnung zu erreichen, fĂŒhrt unweigerlich zu geringer Leistung.

Safe ĂŒberschreitet also viele Grenzen: Eventuell starke ParallelitĂ€t in einem öffentlichen Netzwerk, Allzweck-BFT und permanente Daten.


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!