The cLabs team would like to discuss about the increment of block gas limit to 35 million gas.
The block gas limit is one of the key metrics that govern a network. It has direct impact on the network throughput but also on how the gasPrice is regulated under high-demand circumstances. As part of celo network growth, keeping the gasPrice low while increasing the transaction throughput is one of the key metrics.
During the last months there were multiple improvements on the celo-blockchain client that bring performance improvements. Particularly the snapshots and the blockcontext improvement, activated in Espresso Hardfork, are important performance boosters that change the throughput of the network using the same resource dependencies.
We run simulations and performance tests to measure and validate this claim and check the viability of the proposal. In the CGP there are a summury of the key metrics for these tests, and happy to provide more context about those tests or the results observed.
As summary of it we concluded that increasing the network gas limit to 35 million is safe and let the network to be better ready to manage any incoming load increment while keeping tx fees low.
I’ve proposed 35M gas block size limit as a balance between a increment in current TPS, and trying to keep the hardware requirement low enough to keep the network decentralization for the different components (not only validators, but also fullnodes). Based on the tests we’ve run, with the current spec recommendations we do for validators, proxies, and fullnodes, a 50M constant block load should be run without performance problem. Though, the current load test I’ve run do not represent such a wide variety of load as we have in mainnet (current tests relays on celo txs and interactions with some of the core contracts). Because of this I’d like to keep a more cautious position and not try to pump the gas limit more that what we could expect in the short term. We are working on improving the tests so it can give a clearer picture of current mainnet, but up to that moment I’d vote for staying a bit more conservative on the numbers.
I’m suggesting that even 50M is still a conservative gas limit because your benchmarks that showed feasibility were done on N2 instance whereas validator / proxies / fullnodes should be upgraded to the T2D instance type instead. (or the T2D equivalent on AWS / Azure)
N2 vs T2D price difference is ~5 or 6% but T2D has double the performance because each vCore on T2D is a true core vs a hyper-thread. If N2 stats from your benchmark can handle the ~50M gas blocks, then T2D can handle a LOT more.
As for keeping the hardware requirements low enough for decentralization:
elected validators already run beefy hardware (and get paid a lot that infra cost is trivial compared to rewards)
public RPC operators like Figment & Anchr also already run beefy hardware (or can upgrade to the latest gen cloud instances with negligible extra cost) Anchor for instance already deploy on extremely beefy hardware in Hetzner Finland
professional players on the network (like myself) are in the same category as #2, we’re always running the latest gen hardware for the lowest latency
at home hobby dev can run full node on any Ryzen or Intel laptop from within the last 5 years and have just as much single threaded perf (even consumer laptop CPUs clock very high compared to high core count server cloud CPUs, e.g. Intel 9th/10th/11th/12th gen, or Ryzen 3xxx series+)
I feel like the only type of CPU that will struggle with 50M block would be something from like the Intel Sandy/Ivy Bridge era, but that’s a whole decade ago…
Validator.Capital mainnet nodes should be fine with this increase on our current infrastructure. We’ve built-in extra capacity to handle surges and have not seen any issues.
Hi @diwu1989 ! On Alfajores a proposal (id=55) was submitted and accepted on Wednesday at block 11143972 that increased the blockSize to 35M. I can also make a proposal for Baklava if we find that useful (although load is low compared to mainnet).
To update on the issue, one of the things I’m considering is increasing to a higher blockSize as you suggested (like those 50 Million), but combining the proposal with a new value for target_density to introduce a bigger economical incentive to reduce the number of consecutive blocks with >80% of gas used. This would allow the network to handle higher TPS under high-demand periods but with an incentive on not keeping that pressure for long time.