devnet-2 interop: Faster process in order to test, but the changes included will now have to use ACD process to be officially included in Fusaka.
Fusaka Devnet-1 still live, will go down in ~1 day, and clients using it will have to move all testing to devnet-2
Gas Limit tests
Benchmarking to find bottlenecks and optimizing performance
Clients agreed to 45m but there are many client fixes in every client that need to go into branches before making it the new default gas limit.
45 Million Gas Limit Requirements
Geth: Single fix that needs to get to master branch, but stance is that going above 45m is not possible without reprices (biggest reprice is modexp that is going into fusaka), but 45m would be ok (according to marius personal opinion)
Nethermind: Ok with 45m, and need to put out a new release, but confortable with current release, and could just instead signal that 45m gas limit is ok for nethermind users
Erigon: Ready for 45m
Benchmarking
Marcin: For fusaka, modexp is still the main bottleneck
More testcases for EC_PAIRING and EC_MUL are needed.
EC_ADD there’s going to be an EIP next week.
EIPs for ECMUL/ECPAIRING is still TBD.
EVM logs are a potential issue due to devp2p constrains (10mb limit)
Ben: Issue only kicks at 65M, so we should be ok until Fusaka.
Create a block full of logs scenario to help decide which approach we need.
We require some benchmarks for logs in order to make a more informed decision.
Deep trie issues
Sstore with deep trie, not a big issue for 45m but moving forward it will be.
Jochem: The Xen contract is creating a lot of small proxy contracts which delegate call into something else.
During the tx itself (28m gas) 67 (CREATE2) small contracts, with a lot of stores too
Nothing else fancy/complex seems to be happening.
Seems like caching mechanism of clients is not predicting this correctly.
There’s a state test now that creates a lot of stores and contract creations, but execution time of this state test is very quick, but on mainnet this same test is taking a long time due to the size of the mainnet db.
We should run this same state test in a very large state size to see if this is reproducible.
It’s also possible that there’s extra logging in the mainnet tx that could be making matters worse.
Ben: Ran this block (but could not trace it) and it took this block (and 20+ other blocks) only 600ms to execute, which is not significant.
Geth: Cache of a 256MB buffer (state tree buffer) that sometimes overflows and it happens from time to time during runtime and which takes 2.5 seconds, so this could be the culprit.
It’s bad timing, plus the complexity of the block that included the tx, which adds to the cache more than a regular block.
Fix would be to do this process async (flushing of this cache).
Will try this on a shadowfork to see how it behaves.
History Expiry
Matt: Discussions about history expiry happened last week in the interop
Path forward: All clients needs to polish features to allow to run without pre-merge history.
Releases will come out in the following weeks that drop pre-merge history at each client’s convience.
EF will publish a block post that informs the general public that clients can run without pre-merge history.
We need to modify the approach with the Era file format.
Originally ERA1 → pre-merge, ERA2 → post-merge.
ERA-E will be execution layer, and ERA-C will be consensus layer.
This will unlock the ability for clients to start prunning history.
We have a backstop to access the history, depending on whether we want to do a rolling history-prunning or by stages (e.g. forks).
Will continue discussions for the next month and a half.
ERA files is not the only solution: Portal implementations is one of the alternatives.
Clients will analyze whether they can bring some of the portal features to each client.
Will pick apart the sections of the portal protocol that are usable to each client/layer and implement those.
The rest of the features from portal will be implemented as they seem useful.