Ripple Consensus - mathematische Gewissheit für alle Unl-Graphen?

Es wurde festgestellt, dass die Welligkeit mit mathematischer Sicherheit einen Konsens erreicht. Wenn wir das Konsensprotokoll analysieren, können wir sehen, dass ein bestimmter Validator eine sehr enge Sicht auf den Zustand der übrigen Validatoren haben kann. Mindestens 80 % seiner Liste müssen vorgeschlagen haben, die Transaktion aufzunehmen. Jeder von ihnen erhielt von 70% seiner Liste einen solchen Vorschlag usw....

Wenn nicht alle diese Knoten die 80 % der Unl-Liste eines Validators darstellen, kann man nicht davon ausgehen, dass der ursprüngliche Validator weiß, dass es einen globalen Konsens über das neue Ledger gegeben hat.

Ein problematisches Beispiel ist ein unl-Graph, dessen gerichteter Abstand größer als 6 ist und der eine geringe Konnektivität aufweist.

Ist das richtig? Wenn wahr, was sind die Annahmen, die Ripple auf dem unl-Diagramm macht, damit das oben Gesagte passiert?

Bearbeiten: Würden 2 getrennte Netzwerke nicht 2 verschiedene Konsens erreichen und somit das volle Glück haben, den zweiten Konsens zu kennen? Nehmen wir einen Graphen und 2 Teilgraphen an, die verbunden sind, aber einen Kern haben, der weit von ihrer Grenze entfernt ist. Ein Validator, der sich innerhalb dieses Kerns befindet, wird davon ausgehen, dass ein Konsens erreicht wurde, und nur die Validatoren an der Grenze wissen, dass es keinen Konsens gibt. Mit anderen Worten, sollte die Unl-Liste nicht durch eine einheitliche zufällige Auswahl aller vertrauenswürdigen Validatoren erstellt werden, oder besteht die Möglichkeit, dass der fehlende Konsens nicht erkannt werden kann?

Antworten (1)

Die Schlussfolgerung, dass kein Konsens erreicht wurde, ist eine gültige Schlussfolgerung und kann aufgrund einer schlechten Topologie oder eines byzantinischen Versagens resultieren. Gewissheit bezieht sich immer auf etwas, das in der Vergangenheit geschehen ist. Es ist nicht möglich, den gegenwärtigen Zustand mit Sicherheit zu kennen, ohne an mehr Punkten zu beobachten, als dies normalerweise möglich ist.

Jeder Server läuft also dem voraus, was er sicher weiß, wendet Transaktionen an und versucht, einen Konsens darüber zu erzielen. Wann und ob tatsächlich ein Konsens zustande kommt, stellt der Server später mit Sicherheit fest und kann so sein sicheres Wissen weitergeben.

Im Wesentlichen produziert der Konsensprozess einen Strom von signierten Nachrichten, die als „Validierungen“ bezeichnet werden, anhand derer mit Sicherheit festgestellt werden kann, ob tatsächlich irgendwann in der Vergangenheit ein Konsens erzielt wurde.

Es ist möglich, UNL-Topologien zu erstellen, die häufig keinen Konsens erzielen. Der Plan ist, dass Ripple-Server ihre UNLs mit einem Algorithmus erstellen, der solche Topologien äußerst unwahrscheinlich macht.

Selbst bei einer perfekten Topologie sind zwei Arten von byzantinischen Fehlern möglich.

Einer, der nicht so ungewöhnlich ist (etwa einer von 200 Runden), ist ein lokaler Fehler. Damit jemals ein Konsens entstehen kann, muss jemand einen Konsens erklären. Und damit dies geschieht, muss zuerst jemand einen Konsens erklären. Wenn dies geschieht, kann derjenige, der diese Erklärung abgibt, nicht mit Sicherheit wissen, dass andere denselben Konsens erklären werden (oder sie hätten dies bereits getan, und daher wäre er nicht der Erste). Es ist also immer möglich, dass er den falschen Konsens erklärt.

In diesem Fall entdeckt der Server, der den byzantinischen Fehler erlitten hat, schnell, dass die anderen Validatoren ein anderes Ledger erstellt haben als er und beginnt mit seinem Resynchronisierungsprozess. Andere Server werden immer noch anhand der Validierungen feststellen, welches Hauptbuch das Hauptbuch war.

Eine viel seltenere Art des Versagens ist das vollständige byzantinische Versagen. In diesem Fall erklären mehrere Server unterschiedliche Konsense und es gibt kein klares Mehrheitsregister. In diesem seltenen Fall muss das Netzwerk als Ganzes wieder konvergieren, bevor ein echter Konsens entsteht. Ripple hat einen Algorithmus, um genau das zu tun. Server sehen die widersprüchlichen Validierungen und wissen mit Sicherheit, dass es keinen tatsächlichen Konsens gab.