Der Sommer geht endlich langsam zu Ende, und auch die Temperaturen sinken allmählich. Letzte Woche bin ich mit meiner Familie Auto gefahren, um etwas zu unternehmen. Als wir auf der Autobahn fuhren, passierte plötzlich ein Unfall direkt vor uns. Das Navigationssystem hat mir daraufhin kurzfristig eine Ausweichroute über eine Nebenstraße vorgeschlagen – aber die Fahrzeuge hinter mir sind nicht umgestiegen und sind auf der ursprünglichen Strecke weitergefahren. Zwei Routen liefen dann fast zehn Minuten parallel. Später wurde der Unfall geräumt, und erst dann hat das System alle wieder auf die Hauptstraße umgeleitet. In dieser Zeit wusste niemand, welche der beiden Wege wirklich der „endgültige“ ist, den man nehmen sollte.
Auch im Konsensmechanismus von Dusk gibt es ein ähnliches „Abzweigungs“-Szenario: fallback (Rückfall/Zurücksetzen). Da das Netzwerk asynchron ist, können Nachrichten sich verzögern oder verloren gehen. In derselben Runde kann es daher gelegentlich vorkommen, dass mehr als ein Kandidatenblock gleichzeitig Konsens erreicht – das ist die Fork (Abzweigung). Die Regel ist dabei recht eindeutig: Es wird der Block akzeptiert, der in einer niedrigeren Iterationsrunde (iteration) einen Konsens erreicht hat. Blöcke aus höheren Runden werden von den niedrigen Iterationen ersetzt; die Kette geht auf den Block zurück, der vor der Fork existierte, und hängt dann die bereits früher konsensfähigen Blöcke an. Die ursprüngliche Kette, die ersetzt wird, ist danach nicht mehr gültig – und zwar samt sämtlicher Blöcke, die später daran angeschlossen wurden.
Ein Detail, das leicht übersehen wird: Der Block, der in iteration 0 Konsens erreicht, ist der einzige, der nicht „ersetzt“ wird, weil es keine niedrigere Runde gibt. Aber selbst er gilt nicht als absolut sicher: Wenn der eigene „Vaterblock“ später zurückgesetzt wird, muss er ebenfalls zurückgesetzt werden – nicht absolut, aber im Vergleich deutlich stabiler.
Diese Mechanik löst das Problem von „temporären Forks, die durch verzögerte Netzwerkmeldungen entstehen“, aber mit dem Preis, dass auf der Kette kurzzeitig Unsicherheit herrschen kann – frisch erzeugte Blöcke, besonders solche aus höheren Runden, haben theoretisch die Möglichkeit, ersetzt zu werden. Man muss abwarten, bis die nachfolgenden Blöcke ihn „fest verschweißen“, damit man wirklich beruhigt sein kann.
$DUSK
#dusk @Dusk
Auch im Konsensmechanismus von Dusk gibt es ein ähnliches „Abzweigungs“-Szenario: fallback (Rückfall/Zurücksetzen). Da das Netzwerk asynchron ist, können Nachrichten sich verzögern oder verloren gehen. In derselben Runde kann es daher gelegentlich vorkommen, dass mehr als ein Kandidatenblock gleichzeitig Konsens erreicht – das ist die Fork (Abzweigung). Die Regel ist dabei recht eindeutig: Es wird der Block akzeptiert, der in einer niedrigeren Iterationsrunde (iteration) einen Konsens erreicht hat. Blöcke aus höheren Runden werden von den niedrigen Iterationen ersetzt; die Kette geht auf den Block zurück, der vor der Fork existierte, und hängt dann die bereits früher konsensfähigen Blöcke an. Die ursprüngliche Kette, die ersetzt wird, ist danach nicht mehr gültig – und zwar samt sämtlicher Blöcke, die später daran angeschlossen wurden.
Ein Detail, das leicht übersehen wird: Der Block, der in iteration 0 Konsens erreicht, ist der einzige, der nicht „ersetzt“ wird, weil es keine niedrigere Runde gibt. Aber selbst er gilt nicht als absolut sicher: Wenn der eigene „Vaterblock“ später zurückgesetzt wird, muss er ebenfalls zurückgesetzt werden – nicht absolut, aber im Vergleich deutlich stabiler.
Diese Mechanik löst das Problem von „temporären Forks, die durch verzögerte Netzwerkmeldungen entstehen“, aber mit dem Preis, dass auf der Kette kurzzeitig Unsicherheit herrschen kann – frisch erzeugte Blöcke, besonders solche aus höheren Runden, haben theoretisch die Möglichkeit, ersetzt zu werden. Man muss abwarten, bis die nachfolgenden Blöcke ihn „fest verschweißen“, damit man wirklich beruhigt sein kann.
$DUSK
#dusk @Dusk