Was passiert, wenn im Stellar-Netzwerk ein Fork/Netzwerk-Split auftritt?

Angenommen, ein Land beschließt, irgendwie alle ausgehenden Stellar-Verbindungen für 30 Minuten zu blockieren. Mit einem abstimmungsbasierten Konsens, dass Stellar Chains in beiden Netzwerken hat, schreiten sie mit ähnlicher Geschwindigkeit voran. Nachdem die Netzwerkaufteilung vorbei ist, wird es zwei Stellar-Netzwerke mit einer unterschiedlichen Geschichte geben.

Wie würde ein solches Ergebnis mit den neuen Konsensänderungen gelöst/vermieden werden? Gibt es eine Möglichkeit festzustellen, welcher Netzwerkstatus nach der Trennung korrekt ist? Kann das kleinere Split-Netzwerk wissen, dass es aufgeteilt ist, und die Annahme von Transaktionen pausieren?

Ich bin mir nicht sicher, ob der Konsensalgorithmus von Ripple zu Stellar wesentlich geändert wurde, aber wenn nicht, wird Ihre Frage hier beantwortet: Was ist das genaue Konsensprotokoll, das Ripple verwendet?
@Murch Ich denke schon. Ich erinnere mich, dass ich gehört habe, dass Stellar einen Beweis dafür hat, dass sich ihr Netzwerk nicht verzweigen wird. bearbeiten, hier: stellar.org/papers/stellar-consensus-protocol.pdf

Antworten (2)

Unter der Annahme, dass die Leute angemessene Quorum-Slices gewählt haben und das System eine Quorum-Schnittmenge hat (wie das System verwendet werden soll), dann wäre mit Stellars neuem Konsensprotokoll mindestens eine der beiden Partitionen nicht in der Lage, Transaktionen für die Dauer von abzuwickeln Netzwerkausfall.

Stellar ermöglicht Redundanz, da Validatoren mehrere Slices haben können. Beispielsweise kann ein Slice aus 5 von 7 Validatoren bestehen, die über Länder verteilt sind. In diesem Fall, wenn das geteilte Land nur 1 oder 2 Validatoren hat, kann der Rest der Welt weiterhin Fortschritte machen.

Ein solches Szenario ist eigentlich unvermeidlich. Sie müssen höchstens zwei aus Konsistenz, Verfügbarkeit und Partitionstoleranz auswählen. Dies wird manchmal als "Theorem von Brewer" bezeichnet, weil Eric Brewer es vermutete und Seth Gilbert und Nancy Lynch es anschließend bewiesen. Siehe: http://www.cs.luc.edu/~pld/353/gilbert_lynch_brewer_proof.pdf

Dies scheint jedoch vermeidbar. Sie könnten beiden Seiten erlauben, während des Splits Fortschritte zu machen, wie es Ripple tut, und danach entscheiden, welche Seite „authentisch“ war. Indem Sie während des Splits keine Fortschritte machen, sammeln Sie während des Splits einen massiven Rückstand gültiger Transaktionen an. Dies scheint störender als nötig zu sein.
Der Satz von Brewer ist unvermeidlich. Sie befürworten Verfügbarkeit und Partitionstoleranz gegenüber Konsistenz, im Gegensatz zu herausragender Priorisierung von Konsistenz und Partitionstoleranz gegenüber Verfügbarkeit. Klingt nach Ripple und stellar gehen einfach unterschiedliche Kompromisse ein.
Nicht genau. Ich sage, dass Stellar die Verfügbarkeit hier ohne ersichtlichen Grund opfert. Es gibt keinen erkennbaren entsprechenden Vorteil, weder bei der Konsistenz noch bei der Partitionstoleranz. Die Folgen können erheblich sein, je nachdem, welcher Anteil der Transaktionen bei Verzögerungen freiwillig abgebrochen wird. Wenn das hoch ist, spielt es keine Rolle. Wenn das niedrig ist, könnte eine Partition zu einem dauerhaften Rückstand führen. (Mein Bauchgefühl sagt, dass es wahrscheinlich ziemlich hoch ist. Die meisten Transaktionen werden, wenn sie zu lange dauern, wahrscheinlich einfach abgebrochen. Es macht also möglicherweise keinen großen Unterschied.)
Ich bin mir nicht sicher, ob ich deinen Punkt verstehe. Glauben Sie Brewers Vermutung nicht? Unter der Annahme einer Quorum-Schnittmenge guter Nodes hat Stellars Algorithmus mathematisch bewiesen, dass er Konsistenz (oder „Sicherheit“) bietet, unabhängig von Netzwerkpartitionen. Die Konsistenz und Partitionstoleranz sind also so gut, wie man es sich nur wünschen kann. Diese Garantien gehen zu Lasten der Verfügbarkeit, in dem Sinne, dass zumindest eine der Partitionen keine Transaktionen ohne Zustimmung des Rests der Welt abwickeln kann, aber für Brewer ist dies unvermeidlich, nicht ohne ersichtlichen Grund.
Ich glaube, ich verstehe, wo du mich missverstehst. Sie haben zwei Möglichkeiten, wenn Sie partitioniert sind. Sie können auf keiner Seite Fortschritte machen. Oder Sie können auf beiden Seiten Fortschritte machen, wissen aber erst später, welche Seite Sie behalten werden (und werfen die andere Seite weg). Sie können Transaktionen zwar nicht auf beiden Seiten abwickeln , aber das bedeutet nicht, dass Sie überhaupt keine Fortschritte machen müssen. Sellar entscheidet sich dafür, auf keiner Seite Fortschritte zu machen, nur weil er sich auf keiner Seite niederlassen kann. Dies wird von Brewer nicht verlangt, es ist nur eine Auswahl.
In der Tat, das muss das Missverständnis sein. Ich verstehe nicht, was "Fortschritt" in einem Konsenssystem ist. Ich denke, Sie sprechen vielleicht von einer Optimierung, bei der einige der Datenstrukturen vorberechnet wurden, bevor das Hauptbuch heilt, aber dies ist eine Optimierung, die auf einer anderen Abstraktionsebene als das Konsensprotokoll erfolgen sollte. Stellar würde die Dinge wahrscheinlich mit einem einzigen Hauptbuch heilen, das viele Transaktionen enthält. Das scheint nicht unbedingt besser oder schlechter zu sein, als ich denke, dass Sie Ripple beschreiben, es sei denn, es erschwert den Korrektheitsnachweis.
Sicherlich wird es eine Obergrenze für die Anzahl der Transaktionen pro Sekunde geben, bei denen Sie Fortschritte machen können. Wenn Sie während der Teilung auf keiner Seite Fortschritte machen, bedeutet eine Teilung verlorene Kapazität. Wenn Sie auf beiden Seiten eines Splits Fortschritte machen, müssen Sie sich nur entscheiden, welcher "gewinnt", wenn Sie wieder beitreten, und Sie können Tausende von Transaktionen abwickeln. Auf diese Weise wird die aufgewendete Zeit nicht als Abrechnungskapazität verloren. Dies ist nur eine Auswahl – es wird von Bewer nicht verlangt.
(Mit „Vorwärtsfortschritt“ meine ich die Bestimmung der möglichen Ergebnisse von Transaktionen. Mit „Abrechnung“ meine ich die Bestimmung der Ergebnisse, auf die sich die Menschen verlassen können.)
Nun, in Stellar kann das Konsensprotokoll über eine beliebige Anzahl von Transaktionen abgeschrieben werden, sodass der Konsens selbst nicht auf dem kritischen Pfad für den Transaktionsdurchsatz liegt, sondern nur die Abwicklungslatenz. Nachdem eine Partition geheilt ist, muss die andere Hälfte sowieso alle Transaktionen überprüfen, daher ist unklar, wie viel Vorberechnung helfen kann. Aber das ist wirklich ein anderes Thema als das Konsensprotokoll – ich vermute, dass entweder das Konsensprotokoll von Ripple oder Stellar mit oder ohne Vorberechnung verwendet werden könnte.

Ich denke, Ihre Frage basiert auf der fehlerhaften Prämisse, dass dies ein Problem ist. Während das Netzwerk aufgeteilt ist, hat höchstens eine Seite genügend Validatoren, um Ledger vollständig zu validieren, obwohl beide Seiten Fortschritte machen. Es ist auch möglich, dass keine Seite eine Supermehrheit haben wird, und daher werden beide Seiten zwar Fortschritte machen, aber keine Seite wird alle Ledger vollständig validieren.

Sobald die beiden Seiten wieder zusammenkommen, wird die eine oder andere Kette aufgrund der Lawine der Validierer beim Wiederbeitritt des Netzwerks eine Supermehrheit erlangen. Dies ist besser, als während der Teilung keinen Fortschritt zu machen, da keine Netzwerktransaktionskapazität verloren geht.

Während der Wiederverbindung ist eine große Anzahl ansonsten kostspieliger Überprüfungen nicht erforderlich. Es besteht keine Notwendigkeit, Transaktionen zweimal auszuführen (einmal, um zu entscheiden, wie darüber abgestimmt werden soll, und dann noch einmal, um ihre tatsächlichen Ergebnisse zu bestimmen). Es ist nicht erforderlich, Transaktionen erneut zu versuchen (da Sie die Reihenfolge kennen, in der sie ausgeführt wurden). Usw. Alles, was Sie tun müssen, ist, jedes Ledger im abschließenden Annahmeprozess zu erstellen, was Sie sowieso tun müssen, weil Sie Ihre Datenbanken aktualisieren, Transaktionsergebnisse an Kunden weiterleiten müssen und so weiter.

Was passiert, wenn im Stellar-Netzwerk ein Fork/Netzwerk-Split auftritt?
AntwortenHierDatenschutz-Bestimmungen1y, 0v