Vor ein paar Tagen hat jemand in der Gruppe gefragt: „Worauf bezieht sich Babylons Begriff von ‚Fehlverhalten‘ genau?“ Ich wollte erst so tun, als könnte ich das locker erklären, aber gemerkt habe ich: Ich kann es selbst nicht wirklich sauber sagen. Also bin ich zurück ins Whitepaper und habe den Abschnitt zu den Voraussetzungen für Beschlagnahme/Slashing Wort für Wort durchgearbeitet.
Ehrlich gesagt hatte ich danach das Gefühl: Die Definition von „Fehlverhalten“ durch Babylon ist zwar enger als viele Leute denken, aber auch strenger als die meisten erwarten.
Im Whitepaper sind drei Arten von Handlungen aufgelistet, die sanktioniert werden. Ich übersetze sie mal in Alltagssprache.
Erstens: Doppel-Signaturen. Gleiche Höhe, gleicher Knoten, zwei widersprüchliche Blöcke. Das ist in der PoS-Welt eine eiserne Regel: Wenn man so etwas erwischt, wird gestraft – ohne Diskussion. Vergleichbar damit, dass du auf derselben Rechnung zweimal unterschreibst: einmal mit der Aussage „Ware ist angekommen“, einmal mit „Ware ist nicht angekommen“. Das ist kein Versehen, sondern Betrug.
Zweitens: Validierung ungültiger Blöcke. Der Knoten signiert einen Block, der nicht mit den Konsensregeln übereinstimmt. Das heißt: Man weiß, dass das Ledger ein Problem hat, und setzt trotzdem noch eine Signatur darunter. Das ist ein bisschen wie wenn ein Buchhalter weiß, dass die Rechnung gefälscht ist, und sie trotzdem verbucht. Wenn man erwischt wird, gibt es keine Ausreden.
Drittens – und das wird meiner Meinung nach am leichtesten übersehen – heißt „Liveness Failure“ (Ausfall der Lebendigkeit). Ein Knoten geht über längere Zeit offline und nimmt nicht mehr an Signaturen teil, wodurch die Finalität der Kette beeinträchtigt wird. Die Hürde dafür ist allerdings ziemlich hoch: Es ist nicht so, dass man nur für ein paar Minuten Offline-Zeit sofort bestraft wird. Es muss eine anhaltende Offline-Phase über ein ziemlich langes Toleranzfenster hinaus vorliegen, damit es getriggert wird. Babylon will nicht, dass man gelegentlich ausfallende Knoten gnadenlos jagt, aber wenn jemand langfristig so tut, als sei er tot, oder sich passiv aus der Verantwortung zieht, dann tut mir das leid.
Nachdem ich mir diese drei Bedingungen angesehen habe, bin ich innerlich sogar ruhiger geworden. Die Definition von Fehlverhalten ist festgeschrieben – keine verschwommene Klausel, kein „Projektbetreiber entscheidet nach Gutdünken“. Ob es Strafe gibt, wann sie kommt und wie hoch sie ist: alles wird durch Bedingungen auf der Kette ausgelöst. Der Spielraum für diejenigen, die sich falsch verhalten, ist dadurch sehr eng, und rechtschaffene Knoten werden auch nicht allein wegen Netzwerk-Schwankungen fälschlich bestraft.
Ganz ehrlich: An manchen Stellen sind diese Regeln ziemlich streng – fast schon ungewöhnlich hart. Aber gerade weil sie so klar und unverrückbar niedergeschrieben sind, finde ich, dass das Ganze tatsächlich „handfest“ umsetzbar ist.
Eine Frage: Findest du, dass „Liveness Failure“ bestraft werden sollte?
#baby $BABY @BabylonLabs_io
Ehrlich gesagt hatte ich danach das Gefühl: Die Definition von „Fehlverhalten“ durch Babylon ist zwar enger als viele Leute denken, aber auch strenger als die meisten erwarten.
Im Whitepaper sind drei Arten von Handlungen aufgelistet, die sanktioniert werden. Ich übersetze sie mal in Alltagssprache.
Erstens: Doppel-Signaturen. Gleiche Höhe, gleicher Knoten, zwei widersprüchliche Blöcke. Das ist in der PoS-Welt eine eiserne Regel: Wenn man so etwas erwischt, wird gestraft – ohne Diskussion. Vergleichbar damit, dass du auf derselben Rechnung zweimal unterschreibst: einmal mit der Aussage „Ware ist angekommen“, einmal mit „Ware ist nicht angekommen“. Das ist kein Versehen, sondern Betrug.
Zweitens: Validierung ungültiger Blöcke. Der Knoten signiert einen Block, der nicht mit den Konsensregeln übereinstimmt. Das heißt: Man weiß, dass das Ledger ein Problem hat, und setzt trotzdem noch eine Signatur darunter. Das ist ein bisschen wie wenn ein Buchhalter weiß, dass die Rechnung gefälscht ist, und sie trotzdem verbucht. Wenn man erwischt wird, gibt es keine Ausreden.
Drittens – und das wird meiner Meinung nach am leichtesten übersehen – heißt „Liveness Failure“ (Ausfall der Lebendigkeit). Ein Knoten geht über längere Zeit offline und nimmt nicht mehr an Signaturen teil, wodurch die Finalität der Kette beeinträchtigt wird. Die Hürde dafür ist allerdings ziemlich hoch: Es ist nicht so, dass man nur für ein paar Minuten Offline-Zeit sofort bestraft wird. Es muss eine anhaltende Offline-Phase über ein ziemlich langes Toleranzfenster hinaus vorliegen, damit es getriggert wird. Babylon will nicht, dass man gelegentlich ausfallende Knoten gnadenlos jagt, aber wenn jemand langfristig so tut, als sei er tot, oder sich passiv aus der Verantwortung zieht, dann tut mir das leid.
Nachdem ich mir diese drei Bedingungen angesehen habe, bin ich innerlich sogar ruhiger geworden. Die Definition von Fehlverhalten ist festgeschrieben – keine verschwommene Klausel, kein „Projektbetreiber entscheidet nach Gutdünken“. Ob es Strafe gibt, wann sie kommt und wie hoch sie ist: alles wird durch Bedingungen auf der Kette ausgelöst. Der Spielraum für diejenigen, die sich falsch verhalten, ist dadurch sehr eng, und rechtschaffene Knoten werden auch nicht allein wegen Netzwerk-Schwankungen fälschlich bestraft.
Ganz ehrlich: An manchen Stellen sind diese Regeln ziemlich streng – fast schon ungewöhnlich hart. Aber gerade weil sie so klar und unverrückbar niedergeschrieben sind, finde ich, dass das Ganze tatsächlich „handfest“ umsetzbar ist.
Eine Frage: Findest du, dass „Liveness Failure“ bestraft werden sollte?
#baby $BABY @BabylonLabs_io
A. 该罚,长期掉线就是变相耍赖,损害的是整个协议的安全性
67%
B. 不该罚太狠,节点运维本就复杂,偶尔宕机是正常现象
13%
C. 分情况,得看容忍窗口设多宽,太松了又没威慑力
20%
15 Stimmen • Abstimmung beendet
