xx Netzwerk wirtschaftliche Optimierungen – Fehlerabzüge in Echtzeit

Person mit einem Taschenrechner

Basierend auf dem Feedback der Community hat das Team einen Vorschlag für die Wirtschaftswissenschaften und sucht nach Unterstützung der Community bei der endgültigen Entscheidung

Ein Problem, das mit der Einführung des xx-Netzwerks MainNet ans Licht gekommen ist, besteht darin, dass einige Knoten mit geringerer Leistung im Netzwerk laufen.

In den vorherigen Inkarnationen des Netzwerks – AlphaNet, BetaNet und ProtoNet – wurden diese Probleme vom Team durch einfaches Deaktivieren von leistungsschwachen Knoten gelöst. Dies ist im MainNet, das von nPoS gesteuert wird, offensichtlich nicht möglich.  

Die Community diskutiert dieses Problem seit dem Start von MainNet (Sie finden einen sehr nachdenklichen Thread im #MainNet-Chatkanal auf der Zwietracht). Es wurden unter anderem Lösungen mit gleitenden Strafmaßstäben vorgeschlagen. Insgesamt ist das Team der Meinung, dass eine Anpassung der bestehenden Lösung zusammen mit einer Änderung auf der Clientseite der richtige Ansatz ist.

Um die aktuelle Lösung zu verstehen, müssen einige Details der Ökonomie überprüft werden. In jeder Epoche (24-Stunden-Periode) wird eine Menge Münzen vergeben (der Mechanismus für diese Entscheidung ist in der xx wirtschaftswissenschaftliche arbeit) und auf alle Knoten verteilt. Der Anteil dieser Münzen, der einem bestimmten Knoten zuerkannt wird, entspricht ihrem Anteil an den insgesamt verdienten Münzen. Wenn zum Beispiel in einer Epoche die Auszeichnung insgesamt 50.000xx beträgt und ein bestimmter Knoten 10.000 Punkte von insgesamt 10.000.000 Punkten erhalten hat, erhält er (10.000/10.000.000) × (50.000xx) = 500xx (aufzuteilen zwischen dem Validator und den Nominatoren) .

Aber wie werden diese Punkte verdient?

Punkte werden für zwei Dinge innerhalb des xx-Netzwerks verdient: Blöcke bilden und cMix-Runden laufen. Das Anreizschema liegt im Mechanismus zum Ausführen von cMix-Runden.

Immer wenn eine Runde abgeschlossen ist, erhalten alle 5 Knoten im Team 10 Punkte, während die Knoten in der Echtzeitphase 20 Punkte verlieren, wenn eine Runde fehlschlägt. Dieser Punktverlust soll schlechtes Verhalten abschrecken. Dies erscheint zunächst sehr unfair – wenn eine Runde an einem Knoten scheitert, warum sollte dann jeder Knoten bestraft werden?

Es gibt zwei Gründe:

Der erste ist, dass es unter BFT (Byzantine Fault Tolerance) nicht möglich ist, innerhalb des cMix-Protokolls festzustellen, wer schuld ist. Somit kann nicht nachgewiesen werden, welcher Knoten Punkte verlieren soll.

The second is that in the aggregate, other nodes are not penalized. For example, imagine a network with 15 nodes and 5 node teams where all nodes except for one cause 0% of rounds to fail, with one failing 50%.  What will happen is that given enough rounds, all good nodes will work with the bad node equally and because points are distributed based upon the total ratio of points, not total points, all “good” nodes will get the same number of xx coins, while the bad node will be penalized. In the above case, a node will be in a team with the bad node 1/3rd of the time. It has a 50% failure rate, so all nodes will have an aggregate 16.667% failure rate. Assuming 100,000 rounds, and each participates in 1/3rd, that means that with the current economics, they will earn 10×100,000×⅓×(1-%16.667) =  277,778 points, and lose 20×100,000×⅓×(%16.667) = 111,111 points, making a total of 166,667 points. While in the same scenario, the offending node will earn 10×100,000×⅓×(%50) = 166,667 and lose 20×100,000×⅓×(%50) = 333,333 points, making a total of -166,667. Points cannot go negative, so the offending nodes get 0 points, and as a result all rewards are split between the other 14 good nodes evenly – as if the offending node was never there.

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

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

Da der Punkterfolg immer 10 beträgt, erhalten wir:

Dies ist auch eine Näherung, da regionale Multiplikatoren nicht berücksichtigt werden, wie lange es dauert, bis sich Knoten von fehlgeschlagenen Runden erholen, oder wie sich unterschiedliche Hardware- und Internetkonfigurationen der Knoten auf die Rundenzeiten auswirken können. Aber es reicht für die Analyse zu diesem Zeitpunkt aus.

Die große Frage, die bleibt, ist, was das angemessene „gezielte Scheitern“ sein sollte. Im Allgemeinen kann sie höher sein als erwartet, da die Punkte und damit die Einnahmen immer noch erheblich sinken, wenn ein Knoten hohe Ausfallraten aufweist, die sie nicht erfüllen.

In den letzten 12 Stunden waren die höchsten Echtzeit-Fehlerraten 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 Ansicht, dass wir von einer Ausfallrate von 33% auf 5% absenken sollten, was den Punktabzug pro Echtzeitfehler auf 190 bringen würde.  

Wir möchten dieses Thema in den nächsten Tagen für die Community-Diskussion öffnen und werden es basierend auf der Antwort vom 6. Dezember 2021 erneut aufgreifen

Es gibt auch eine sekundäre Zwischenlösung, an der das Team arbeitet. Der ultimative Mangel an wirtschaftlichen Lösungen besteht darin, dass sie Zeit in Anspruch nehmen können, was nicht so toll ist, wenn Nachrichten vom xx-Messenger und anderen Benutzern des xxDk aktiv verworfen werden. Als Ergebnis wird das Team eine Liste mit derzeit leistungsschwachen Knotenbetreibern veröffentlichen, die xxDK-Benutzer optional gegen das Senden von Nachrichten in Runden mit diesen Knoten entscheiden können. Es wird auch für xxDK-Benutzer möglich sein, sich für andere, separat kuratierte Listen anzumelden.

Das Team wird auch prüfen, ob der Team-Multiplikator von der Mindestleistung abhängig ist. Weitere Informationen folgen in Kürze.

Beliebt