陪儿子写作业写到十一点，他一句"电脑死机了会怎样"，把我问住了
Ich spürte kurz die Lust, zu antworten: „Dann einfach neu starten“, doch dann fiel mir ein Abschnitt aus dem Dusk-Whitepaper ein, den ich die letzten Tage herausgezogen hatte – sie nennen das „Notfallmodus“.
Normalerweise läuft der Prozess in drei Schritten: Vorschlag, Verifikation, Freigabe; wenn 2/3 der Leute nicken, ist das erledigt. Aber falls ein Großteil der Knoten ausfällt oder hängen bleibt, bei 16 aufeinanderfolgenden Fehlschlägen schaltet das System automatisch in den Notfallmodus. Die Timeout-Mechanik wird dann direkt abgeschaltet und es läuft weiter, bis tatsächlich ein Block erzeugt wurde. Kurz gesagt: Es ist kein „Crash und dann Neustart“, sondern ein Wechsel der Vorgehensweise, um bis zum Ende hart durchzuziehen.
Diese Mechanismen interessieren im Alltag kaum jemanden – solange die Chain online „gesund“ ist, fragt niemand groß nach, ob der Konsensmechanismus noch so streng ist. Im Finanzbereich ist das anders: Institutionen wollen genau „selbst im Extremfall darf es nicht stoppen“. Das ist viel wichtiger als TPS.
Auch die Block-Rewards sind ziemlich fein designt: 80 % für den, der den Block erzeugt, 10 % für die Abstimmenden, 10 % gehen an das Protokoll selbst. Das ist gezielt dagegen gerichtet, dass jemand absichtlich die ersten Runden scheitern lässt, um sich die Belohnung zu sichern.
Solche Details schreibe ich normalerweise nicht auf. Aber je tiefer ich grabe, desto mehr merke ich: Ob ein Projekt wirklich klar erklärt, was es im schlimmsten Fall tut, ist wertvoller als jede noch so hübsche Werbebroschüre.
Zurzeit ist DuskEVM noch im Testnet. Wie gut dieser Konsens echte extreme Marktphasen durchhält, wurde noch nicht in großem Maßstab verifiziert.
Ob es klappt, weiß ich nicht. Aber bei Projekten, die Notfallpläne offen auf den Tisch legen, schaue ich gern noch ein bisschen genauer hin.
@Dusk $DUSK

#dusk