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.
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 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.
