common: Parse post-merge hardfork config in parseGethParams and handle post-merge genesis block #2427
Conversation
g11tech
added
PR state: WIP
type: enhancement
package: common
target: master
Codecov Report
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. |
g11tech
changed the title
packages/common/src/utils.ts
Outdated
| nonzeroIndex !== -1 | ||
| ) { | ||
| // find index where block > 0 | ||
| params.hardforks.splice(nonzeroIndex, 0, mergeConfig) |
There was a problem hiding this comment.
I don't think it's safe to assume the first nonzero hardfork will always be where the merge should go. We could very easily have an earlier hardfork (like ArrowGlacier/GrayGlacier which isn't even in this list) be the first nonzero one. Unless I'm not thinking clearly, we should always put Merge after London (if ArrowGlacier/GrayGlacier aren't specified), right?
There was a problem hiding this comment.
ummm, doesn't actually matter in scheme of things if those are all at 0
the issue is when terminalTotalDifficultyPassed is false or not present, then where should we place Merge?
The order we assume is the order they showup in the config section, and it would have been nice to also have mergeBlock there even if its block is null
So that there is no confusion about the order, may be we can give this feedback to the geth guys and if the mergeBlock is not present in the config (like it doesn't for now) we can use this logic to place merge
There was a problem hiding this comment.
K, this is the PR where they add it. I'm honestly not sure how to handle this one. The main place they reference this new parameter is here where the sync type is being decided (so akin to how we differentiate between full sync and beacon sync). Can you do beaconsync forward before the merge block or does the client have to continue with full sync till it hits the merge block? If the latter, I still think we should explicitly look for the london fork block number and insert this one after it. I can't think of a reason we should have GrayGlacier or ArrowGlacier in a custom network so we shouldn't need to check for them.
There was a problem hiding this comment.
but the PoS or PoW consensus actually has nothing to do with pre/post london, it can be placed anywhere
There was a problem hiding this comment.
ok, looking at the geths PR has got me confused about this flag, but we defintely need post merge hardforks differentiation which certainly needs merge, like withdrawals, and 4844. I am not clear if thats the way to go especially with mergeForkID confusion of it bein pre/post merge.
But since kiln, no network has had mergeForkId before merge so may be i am over thinking it?
There was a problem hiding this comment.
ok i have tried to make this thing a bit more intelligenct, placing merge before the first postmerge hardfork, and is still dynamic with respect to mergeForkId block
There was a problem hiding this comment.
Why is Geth not just giving a block number for the Merge?
There was a problem hiding this comment.
All this dynamic handling and wild-guessing for this one time Merge event which has now passed seems totally overblown to me and doesn't really solve any problems any more (right?).
There was a problem hiding this comment.
correct, may be they haven't had yet added handling for merge block
Also the genesis file seems weird, so the genesis block has difficulty and extraData belonging to PoA consensus, but shanghai is also at 0 for withdrawals so obviously merge hf has passed
There was a problem hiding this comment.
@holgerd77 i think the latest implementation is logical:
place the merge hardfork before any merge dependent hardforks specified on non zero block as genesis can't be a PoS block.
Our dynamic handling of hardfork sequences and hardfork changes can handle the rest.
g11tech
force-pushed
the
g11tech/fix-geth-genesis-parse
branch
2 times, most recently
from
055c9fb to
3aa4ad6
Compare
g11tech
changed the title
g11tech
force-pushed
the
g11tech/fix-geth-genesis-parse
branch
from
b1d4a79 to
e54b1f7
Compare
|
Some general notes here: I generally find/found this Geth genesis file format only half-thought-through from the beginning, that was actually one main motivation why I introduced our own format within Common at the time. So, my overall fear is always a bit that we are bringing in some clutter in our main (Common, partly other) code logic by trying to cope with this semi-defined structure from Geth genesis, particularly when new things are added there. So in this case the (Merge) HF order should somewhat be extractable/readable from the Geth config file itself, since this is just some basic structural information piece one would need to build upon. Apparently it is not though, with these Merge-parameters extracted/separated from the other HF definitions. Just some context/thinking from my side. Otherwise, long story short: since this PR only touches the Geth import logic in Common, I would be ok with merging. Have I otherwise forgotten or overlooked something in my summary above or is there still some outstanding question which needs to be adressed? 🤔 |
Yes very valid points @holgerd77 , hopefully with this PR the merge hardfork placement is now very deterministic and is based on these factors:
Have added the same in the comment in parseGeth.. |
Ok, nice 🙂, I am also ok with merging here! |
In order to get the geth genesis working for 4844 work, the sharding block needs to be configured post merge which is configured post block 0 (Currently merge if present is the last hf configured)
Similar setup is required to have ethereumjs shandong branch start off withdrawals at non zero block number after the merge.
This PR enhances the same
Geth genesis now carries a flag
terminalTotalDifficultyPassedfor this which indicates that the merge is before any other hardforks configured on non zero block number