#dusk $DUSK
Heute schaue ich weiter auf die Boreas-Updates von @Dusk . Was mich am meisten beschäftigt, ist nicht, dass Phoenix ausgemustert wird, und auch nicht, dass es wieder ein paar weitere Fork-Regeln gibt.
Vielmehr geht es um ein tieferes, grundlegendere Problem:
Warum behält eine frühere Transaktion nach einem Protokoll-Upgrade dauerhaft dieselbe Bedeutung?
Das klingt wie eine Binsenweisheit.
Aber nach einer Hard Fork laufen die Nodes bereits nach den neuen Regeln.
Gleichzeitig liegen in den historischen Blöcken jedoch noch alte Versionen von Transaction, altes Verifier und alte Execution-Semantics herum.
Wenn heutige Nodes die jetzt gültigen Regeln verwenden, um frühere Bytes neu zu interpretieren, könnte das beim historischen Replay schiefgehen.
Deshalb zieht Boreas in diesem Fall die Version- und Regelgrenze für die Transaktionsbehandlung noch klarer.
Live-Ingress läuft nach den aktuellen Protokollregeln.
Alte Envelopes können beim Eintritt identifiziert und normalisiert werden.
Bevor sie ins Ledger eingehen, werden sie zu einer kanonischen Transaktion.
Historische Blöcke hingegen werden weiterhin nach den Regeln von damals dekodiert und repliziert.
Ich finde, das Entscheidende hier ist nicht „einheitliches Format“.
Sondern:
Transaktionen haben neben ihrem Inhalt auch eine Zugehörigkeit zu einer bestimmten Protokoll-Ära.
Aegis ist Aegis’ Regeln.
Boreas ist Boreas’ Regeln.
Eine Hard Fork kann die Zukunft verändern, aber sie darf nicht nebenbei dazu führen, dass die Vergangenheit neu interpretiert wird.
Darum schaue ich mir bei Ketten-Upgrades heute nicht nur an, „was neu hinzukommt“.
Mich interessiert vor allem:
Können die Nodes nach dem Rollout der neuen Version noch immer korrekt verstehen, was vor Jahren auf jener Kette tatsächlich passiert ist?
Für ein Netzwerk, das eine regulierte Marktinfrastruktur bereitstellen will, ist diese historische Kontinuität im Grunde genommen essenziell.
Man kann das Konto upgraden.
Aber die Vergangenheit im Konto darf nicht mit dem Upgrade mitwandern.
Heute schaue ich weiter auf die Boreas-Updates von @Dusk . Was mich am meisten beschäftigt, ist nicht, dass Phoenix ausgemustert wird, und auch nicht, dass es wieder ein paar weitere Fork-Regeln gibt.
Vielmehr geht es um ein tieferes, grundlegendere Problem:
Warum behält eine frühere Transaktion nach einem Protokoll-Upgrade dauerhaft dieselbe Bedeutung?
Das klingt wie eine Binsenweisheit.
Aber nach einer Hard Fork laufen die Nodes bereits nach den neuen Regeln.
Gleichzeitig liegen in den historischen Blöcken jedoch noch alte Versionen von Transaction, altes Verifier und alte Execution-Semantics herum.
Wenn heutige Nodes die jetzt gültigen Regeln verwenden, um frühere Bytes neu zu interpretieren, könnte das beim historischen Replay schiefgehen.
Deshalb zieht Boreas in diesem Fall die Version- und Regelgrenze für die Transaktionsbehandlung noch klarer.
Live-Ingress läuft nach den aktuellen Protokollregeln.
Alte Envelopes können beim Eintritt identifiziert und normalisiert werden.
Bevor sie ins Ledger eingehen, werden sie zu einer kanonischen Transaktion.
Historische Blöcke hingegen werden weiterhin nach den Regeln von damals dekodiert und repliziert.
Ich finde, das Entscheidende hier ist nicht „einheitliches Format“.
Sondern:
Transaktionen haben neben ihrem Inhalt auch eine Zugehörigkeit zu einer bestimmten Protokoll-Ära.
Aegis ist Aegis’ Regeln.
Boreas ist Boreas’ Regeln.
Eine Hard Fork kann die Zukunft verändern, aber sie darf nicht nebenbei dazu führen, dass die Vergangenheit neu interpretiert wird.
Darum schaue ich mir bei Ketten-Upgrades heute nicht nur an, „was neu hinzukommt“.
Mich interessiert vor allem:
Können die Nodes nach dem Rollout der neuen Version noch immer korrekt verstehen, was vor Jahren auf jener Kette tatsächlich passiert ist?
Für ein Netzwerk, das eine regulierte Marktinfrastruktur bereitstellen will, ist diese historische Kontinuität im Grunde genommen essenziell.
Man kann das Konto upgraden.
Aber die Vergangenheit im Konto darf nicht mit dem Upgrade mitwandern.