xx network Ökonomische Verbesserungen - Abzüge bei Fehlschlägen in Echtzeit

Person mit einem Taschenrechner

Auf der Grundlage des Feedbacks aus der Community hat das Team einen Vorschlag für die Ökonomie erarbeitet und bittet die Community um Unterstützung bei der endgültigen Entscheidung

Ein Problem, das bei der Einführung des xx network MainNet aufgetaucht ist, ist, dass es einige weniger leistungsfähige Knotenpunkte im Netzwerk gibt.

In den früheren Versionen des Netzwerks - AlphaNet, BetaNet und ProtoNet - wurden diese Probleme vom Team gelöst, indem leistungsschwache Knotenpunkte einfach abgeschaltet wurden. Im MainNet, das von nPoS kontrolliert wird, ist das natürlich nicht möglich.  

Die Community diskutiert dieses Thema seit dem Start von MainNet (du kannst einen sehr durchdachten Thread im #MainNet-Chat-Kanal auf der diskord). Es wurden u. a. Lösungen vorgeschlagen, die eine Staffelung der Strafen vorsehen. Insgesamt ist das Team der Meinung, dass eine Verbesserung der bestehenden Lösung zusammen mit einer Änderung auf der Client-Seite der richtige Ansatz ist.

Um die aktuelle Lösung zu verstehen, müssen wir uns einige Details der Wirtschaft ansehen. In jeder Epoche (24-Stunden-Zeitraum) wird eine bestimmte Anzahl von Münzen vergeben (der Mechanismus für diese Entscheidung wird in der xx Wirtschaftszeitung) und unter allen Knotenpunkten verteilt. Der Anteil dieser Münzen, den ein bestimmter Knotenpunkt erhält, ist gleich seinem Anteil an den insgesamt verdienten Münzen. Wenn zum Beispiel in einer Epoche insgesamt 50.000xx vergeben werden und ein bestimmter Knotenpunkt 10.000 Punkte von insgesamt 10.000.000 erhalten hat, bekommt er (10.000/10.000.000)×(50.000xx) = 500xx (die zwischen dem Validator und den Nominatoren aufgeteilt werden).

Aber wie werden diese Punkte verdient?

Beim xx network gibt es für zwei Dinge Punkte: das Bilden von Blöcken und das Durchführen von cMix-Runden. Der Mechanismus für das Durchführen von cMix-Runden ist der eigentliche Anreiz.

Jedes Mal, wenn eine Runde abgeschlossen wird, erhalten alle 5 Knotenpunkte im Team 10 Punkte, während die Knotenpunkte 20 Punkte verlieren, wenn eine Runde während der Echtzeitphase scheitert. Dieser Punkteverlust soll von schlechtem Verhalten abschrecken. Auf den ersten Blick erscheint das sehr unfair - wenn eine Runde wegen eines Knotens scheitert, warum sollte dann jeder Knoten bestraft werden?

Dafür gibt es zwei Gründe:

Die erste ist, dass es unter BFT (Byzantine Fault Tolerance) nicht möglich ist, innerhalb des cMix-Protokolls zu bestimmen, wer einen Fehler gemacht hat. Das bedeutet, dass es nicht möglich ist, zu beweisen, welcher Knoten Punkte verlieren sollte.

Die zweite ist, dass andere Knoten in der Summe nicht bestraft werden. Stell dir zum Beispiel ein Netzwerk mit 15 Knoten und 5 Knotenteams vor, in dem alle Knoten bis auf einen 0% der Runden scheitern, wobei einer 50% scheitert. Bei einer ausreichenden Anzahl von Runden werden alle guten Knoten gleichmäßig mit dem schlechten Knoten zusammenarbeiten, und da die Punkte auf der Grundlage des Gesamtverhältnisses der Punkte und nicht der Gesamtpunktzahl verteilt werden, erhalten alle "guten" Knoten die gleiche Anzahl von xx coin, während der schlechte Knoten bestraft wird. Im obigen Fall befindet sich ein Knoten zu 1/3 der Zeit in einem Team mit dem schlechten Knoten. Er hat eine Ausfallrate von 50%, so dass alle Knoten insgesamt eine Ausfallrate von 16,667% haben. Wenn wir von 100.000 Runden ausgehen und jeder an 1/3 der Runden teilnimmt, bedeutet das, dass er bei der derzeitigen Wirtschaftslage 10×100.000×⅓×(1-,667) = 277.778 Punkte verdient und 20×100.000×⅓×(,667) = 111.111 Punkte verliert, also insgesamt 166.667 Punkte. Im gleichen Szenario verdient der verletzende Knotenpunkt 10×100.000×⅓×() = 166.667 und verliert 20×100.000×⅓×() = 333.333 Punkte, also insgesamt -166.667. Die Punkte können nicht ins Negative gehen, also bekommen die beleidigenden Knoten 0 Punkte, so dass alle Belohnungen gleichmäßig auf die anderen 14 guten Knoten verteilt werden - als ob der beleidigende Knoten nie da gewesen wäre.

Diese Lösung funktioniert, mit der Ausnahme, dass sie auf eine Ausfallrate abzielen muss, bei der die Knoten ihre gesamten Einnahmen verlieren. Da wir ein System mit sehr hoher Zuverlässigkeit anstreben, wollen wir eine Zahl anstreben, die viel höher ist als 50%.

Im Allgemeinen lautet die Gleichung für die angestrebte Ausfallrate und die Punkte wie folgt:

Da der Erfolg immer 10 Punkte beträgt, ergibt sich daraus:

Auch dies ist ein Näherungswert, denn er berücksichtigt weder regionale Multiplikatoren noch die Zeit, die die Knoten brauchen, um sich von fehlgeschlagenen Runden zu erholen, noch die Auswirkungen unterschiedlicher Hardware- und Internetkonfigurationen der Knoten auf die Rundenzeiten. Für die Analyse ist sie jedoch ausreichend.

Die große Frage, die sich stellt, ist, was der angemessene "Zielausfall" sein sollte. Im Allgemeinen kann er höher sein als erwartet, denn die Punkte und damit die Einnahmen sinken immer noch erheblich, wenn ein Knotenpunkt hohe Ausfallraten hat, die ihn nicht erfüllen.

In den letzten 12 Stunden waren die höchsten Ausfallraten in Echtzeit wie folgt:

27.22%, 3.79%, 3.58%, 1.64%, 1.19%

Mit einer durchschnittlichen Ausfallrate von 0,5% (Median 0,35%). 

Angesichts dieser Daten ist das Team der Meinung, dass wir von einer Ausfallrate von 33% auf 5% heruntergehen sollten, was den Punktabzug pro Echtzeitausfall auf 190 senken würde.  

Wir möchten dieses Thema in den nächsten Tagen zur Diskussion stellen und werden es auf der Grundlage der Antworten am 6. Dezember 2021 wieder aufgreifen.

Es gibt auch eine zweite Zwischenlösung, an der das Team arbeitet. Der größte Nachteil wirtschaftlicher Lösungen ist, dass sie Zeit brauchen können, was nicht gut ist, wenn Nachrichten aktiv vom xx messenger und anderen Nutzern des xxDk fallen gelassen werden. Aus diesem Grund wird das Team eine Liste mit derzeit schlecht arbeitenden Knotenbetreibern veröffentlichen, in der xxDK-Nutzer optional festlegen können, dass in Runden, die diese Knoten enthalten, keine Nachrichten gesendet werden. xxDK-Nutzer können sich auch in andere, separat erstellte Listen eintragen.

Das Team wird außerdem prüfen, ob der Team-Multiplikator von der Mindestleistung abhängig gemacht werden kann.

Beliebt