Support Dencun consensus upgrade #981
Conversation
|
Nice work Ron! 🙏 |
yrong
changed the title
|
@vgeddes I would prefer to split https://linear.app/snowfork/issue/SNO-406 into multiple PRs, in this one we only focus on upgrading packages and add versioned data support in next one. |
There was a problem hiding this comment.
I've just noticed that there are a lot of unrelated changes to the E2E scripts, like making processes run in parallel etc. I vaguely recall previously reviewing such a change and saying that it makes troubleshooting harder if the E2E tests break.
The other reason for not wanting such changes is that roughly 80% of the initialization time is spent in compiling rust code. And the parallelization changes you're introducing here don't improve that. So I think the net gain is minimal.
So I'd like for you to please focus this PR on only the code relevant to the Dencun upgrades.
Yes, rust compile is the most time consuming and the gain is minimal in this case. But for the second round of start up when there is no rust code change(e.g. cases when there is only change for relayer or solidity code) parallelization will decrease startup time to almost half(from But anyway just remove unrelated changes in 28f23dd to be more focused. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #981 +/- ##
==========================================
- Coverage 76.25% 75.08% -1.17%
==========================================
Files 58 58
Lines 2400 2464 +64
Branches 72 72
==========================================
+ Hits 1830 1850 +20
- Misses 553 597 +44
Partials 17 17
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Hey @yrong! Great job, this is awesome!
I made a few comments. I would have preferred the relayer cleanup (removing the Ethereum PoW code) in a separate PR, but what's done is done.
I am not convinced adding geth and lodestar as submodules is necessary. Did we make any changes at all that warrants using forked versions? Seems like unnecessary maintenance and I would prefer we use the original projects.
scripts/init.sh
Outdated
| @@ -20,3 +20,9 @@ cargo install cargo-fuzz | |||
|
|
|||
| echo "Installing web packages" | |||
| (cd web && pnpm install) | |||
|
|
|||
| echo "Download geth to replace the nix version" | |||
| geth_package=geth-$(uname | tr '[:upper:]' '[:lower:]')-amd64-1.13.10-bc0be1b1 | |||
There was a problem hiding this comment.
I think its simpler to hardcode the source filenames based on the output of:
nix eval --impure --raw --expr 'builtins.currentSystem'also, we need to support arm/macos too, not just linux/amd64
There was a problem hiding this comment.
It seems the download page only provides the amd64 versions, and I tested the darwin-amd64 package did work in my M1.
There was a problem hiding this comment.
I think you need to look that download page a bit more - there are links to downloads for many architectures:
So depending on the value of builtins.currentSystem, which should be one of the architectures listed in flake.nix, download the appropriate binary.
There was a problem hiding this comment.
Yeah, I missed that. Fixed in fb5366f
Btw: nix eval --impure --raw --expr 'builtins.currentSystem' return aarch64-darwin in my laptop which does not match the darwin-arm64* in the download link so switch to uname -m instead.
Resolves: SNO-406, SNO-775
VersionedExecutionPayloadHeaderto support multiple versions of the beacon updatesethashproofbased on the deprecated POW consensus which can be removed).