This proposal recommends increasing the maximum gas limit per block from the current 120,000,000 to 240,000,000. The primary goal is to enhance the network’s capacity to process transactions, effectively doubling the number of transactions that can be included in a single block.
Background and Rationale
The existing maximum gas limit of 120,000,000 for each block has now proven to be a constraining factor for the network’s throughput. Analysis of osmosisd CPU performance profiles, upcoming state compatible improvements from IAVL v1, and precedents set by networks like LUNC suggest that our chain can efficiently handle a significantly larger transaction volume. Increasing the gas limit to 240,000,000 is an incremental step towards optimizing our network’s performance without adversely impacting the synchronization speed. Although a fivefold increase might be feasible, this proposal suggests a cautious approach by only doubling the limit at this stage. This change is expected to enhance the network’s efficiency and scalability while maintaining stability.
Ok, so that means a text proposal is the way to go for now.
And in the future it would be a parameter-change again?
On topic for the gas: if analysis shows and precedents have been set by other chains, can we share those insights in here as well to provide back-up of the statements?
Because it’s a chain parameter being adjusted, it should get a text proposal pre-approving a change. However, I suppose that a software upgrade itself might count as approval.
I support this proposal, along with another proposal that I’m about to write that reduces block size but not as much as the one I wrote earlier, here:
@JohnnyWyles are you saying that currently we cannot adjust baseapp parameters? Because I would like to do well a proposal that does exactly that.
@czarcas7ic I’m in support of increasing block gas because indeed, we can put more txns in em. At the same time I would like to reduce the maximum block size to 4mb, not the 1mb I proposed earlier.
If you have one underway, go with four megabytes please. I think that that is a safe number for contract uploads and it would prevent issues like what we recently saw on levana, which I should be clear, is a very very obvious exploit of the issues that informal systems said are not a bug in comet.
Also, I think that we should remove comet from osmosis. Really. We need to write something better and that won’t happen with the awful security posture shown by informal.
And since unfortunately it is a problem with people and they’re honesty or lack thereof, if it’s not this it’s going to be something else with comet.
Informal systems was provided:
video evidence of the efficacy of P2P storms
Code to replicate the attack
Mitigations
and chose, explicitly chose:
to downplay the issue
to label it low severity
to state, literally, that there was no bug at all
Note: I am not suggesting that we immediately remove comet from osmosis, I am instead suggesting that we collaborate on the design of something better and build it.
As @JohnnyWyles stated, its currently not changeable via a param and will be a part of the next software upgrade, along with other performance changes.
Apologies for taking this to the form without testing the param change myself, it was 1a.m after dealing with the arb spam and we didn’t want to waste time. But the changes we made in v21.1.5 buy us plenty of time to address this in the next upgrade at the beginning of the New Year.
