#dusk $DUSK
Today, I continue looking at the Boreas update of @Dusk . What concerns me most isn’t that Phoenix has been retired, or that a few more fork rules have been added.
It’s a deeper, underlying issue:
After the protocol upgrade, why can an old transaction from the past keep the same meaning forever?
This sounds like a pointless question.
But after a hard fork, nodes are already running the new rules, while the history blocks still contain the old version of the transaction, the old verifier, and the old execution semantics.
If a node today takes the current rules and reinterprets the bytes from the past, then historical replay could go wrong.
So in this release, Boreas makes the transaction-handling version boundaries much more explicit.
Live ingress follows the current protocol rules.
The old envelope can be identified and normalized at the entry.
Before entering the ledger, it is converted into the canonical transaction.
And for historical blocks, they continue to be decoded and replayed according to the rules from when they were originally produced.
I think what’s truly important here isn’t “format standardization.”
It’s this:
A transaction has not only content, but also the protocol era it belongs to.
Aegis has Aegis’s rules.
Boreas has Boreas’s rules.
A hard fork can change the future, but it can’t casually reinterpret the past all over again.
That’s also why, when I look at chain upgrades now, I don’t only focus on “what’s new.”
What I care about more is:
After the new version goes live, can today’s nodes still accurately understand what actually happened on that chain a few years ago?
For a network meant to serve regulated market infrastructure, this kind of historical continuity is actually fundamental.
You can upgrade the ledger.
But the past inside the ledger cannot be upgraded along with it.
Today, I continue looking at the Boreas update of @Dusk . What concerns me most isn’t that Phoenix has been retired, or that a few more fork rules have been added.
It’s a deeper, underlying issue:
After the protocol upgrade, why can an old transaction from the past keep the same meaning forever?
This sounds like a pointless question.
But after a hard fork, nodes are already running the new rules, while the history blocks still contain the old version of the transaction, the old verifier, and the old execution semantics.
If a node today takes the current rules and reinterprets the bytes from the past, then historical replay could go wrong.
So in this release, Boreas makes the transaction-handling version boundaries much more explicit.
Live ingress follows the current protocol rules.
The old envelope can be identified and normalized at the entry.
Before entering the ledger, it is converted into the canonical transaction.
And for historical blocks, they continue to be decoded and replayed according to the rules from when they were originally produced.
I think what’s truly important here isn’t “format standardization.”
It’s this:
A transaction has not only content, but also the protocol era it belongs to.
Aegis has Aegis’s rules.
Boreas has Boreas’s rules.
A hard fork can change the future, but it can’t casually reinterpret the past all over again.
That’s also why, when I look at chain upgrades now, I don’t only focus on “what’s new.”
What I care about more is:
After the new version goes live, can today’s nodes still accurately understand what actually happened on that chain a few years ago?
For a network meant to serve regulated market infrastructure, this kind of historical continuity is actually fundamental.
You can upgrade the ledger.
But the past inside the ledger cannot be upgraded along with it.
