Disable development eras configuration flag #4030
Conversation
Jimbo4350
requested review from
dcoutts,
erikd,
newhoggy and
JaredCorduan
as code owners
Babbage and advertise that we know about the Babbage era
Jimbo4350
force-pushed
the
jordan/remove-test-enable-development-hardfork-eras-requirement
branch
from
2ed89f7 to
6d33fa3
Compare
(cherry picked from commit f3c51b1)
| @@ -198,7 +198,7 @@ mkSomeConsensusProtocolCardano NodeByronProtocolConfiguration { | |||
| -- version that this node will declare that it understands, when it | |||
| -- is in the Alonzo era. That is, it is the version of protocol | |||
| -- /after/ Alonzo, i.e. Babbage. | |||
| alonzoProtVer = ProtVer 6 0, | |||
| alonzoProtVer = ProtVer 7 0, | |||
There was a problem hiding this comment.
why is alonzo protocol version that node sees changed here (yes, there were 2 forks in alonzo era, but changing them abruptly all of a sudden without mapping it against fork is very hacky)?? This breaks existing explorers on public testnet that do check on protocol major version in block header...(now we have blocks with different protocol_major adopted on testnet without a fork submission - randomly based on node's presumption of protocol version, if this is the aim to go on mainnet too - best to add some CIP/docs beforehand - there is already efforts done by @JaredCorduan to reduce the confusion) , this is a deviation that further confuses what's mentioned in CIP 274 from historical view
There was a problem hiding this comment.
Yes, this indeed is creating a mess checking block version for specific era
There was a problem hiding this comment.
This change looks correct to me. We want we the nodes in the Alonzo era that are prepared for the upgrade to signal that they are ready by putting major protocol number 7 in the block header (since 7 corresponds to the next ledger era, Babbage).
There was a problem hiding this comment.
The change looks correct for future (looking at version from babbage back to alonzo), but it seems to be at the expense of current (future past) - using vague version in block header that is kinda unrelated to actual protocol_major version , in case of which all the components using block header representation
of protocol_major now need to rename it to node version.
There was a problem hiding this comment.
This is actually how it was designed to work from the very beginning, going back to the Shelley ledger spec. See section 13 of https://hydra.iohk.io/job/Cardano/cardano-ledger/shelleyLedgerSpec/latest/download-by-type/doc-pdf/ledger-spec.
The version listed in the block header indicates the latest version of the protocol that the block producer is prepared to upgrade to.
There was a problem hiding this comment.
Thanks for the link, looks like some of us have been understanding the value of this block header wrong the whole time 😢 Can we add a reference to this (if not a short description) to the CIP 274?
There was a problem hiding this comment.
Can we add a reference to this (if not a short description) to the CIP 274?
That is a most excellent idea!
|
bors r+ |
|
Build succeeded: |
iohk-bors
bot
deleted the
jordan/remove-test-enable-development-hardfork-eras-requirement
branch
This lets us advertise that we know about the Babbage era and we no longer require the
"TestEnableDevelopmentHardForkEras"config flag