Proposal for Doubling the Max Gas Block Parameter from 120,000,000 to 240,000,000

Proposal Overview

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.

3 Likes

another todo in such case
migrate fee change point from 75m to to 3/4 of block max gas

1 Like

We could even consider making this an expedited proposal.

Strong support and should be executed asap

I think this won’t work. There’s no param for this and as far as I can see it it’s hardcoded…

It is a parameter change still:

key: BlockParams
subspace: baseapp
value: '{"max_bytes":"10485760","max_gas":"120000000"}'

Baseapp is not queryable. Where do I find these parameters?

Hmm… I queried this before the last patch fine with osmosisd q params subspace baseapp BlockParams, but the same query isn’t working for me now.

Edit: Looks like they were moved in v21… asking our chaindevs for more info.

Edit2: Confirmed. This will have to be part of a software upgrade, then going forward after that it should be a parameter again.

1 Like

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?

I personally think this effort of such proposal is dead.

Afaik, there will be an update introducing more changes to the fee mechanism and then also make the gas a parameter.

Making this a text proposal doesn’t really do anything so we should just wait for the devs to fix it.

=> “Can devs do something?” - “Yes, they are working on it”

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.

1 Like

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.

Wdyt?

Exactly, it has to be part of a software upgrade right now. Just drafting one now that also proposed reducing max bytes.

1 Like

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.

Here is my breakdown on the issues with levana:

https://twitter.com/gadikian/status/1740309681753727353

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:

  1. to downplay the issue
  2. to label it low severity
  3. 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.

The current state of affairs is unacceptable.

@ValarDragon suggested we go for 5, any issues with that?

1 Like

I have no issues at all with that :slight_smile:

It’s just shy of 80% safer than 21.

1 Like

@faddat the max gas amount is not a parameter so this proposal won’t work

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.

1 Like

Do we track how many validators and voting power has migrated to v21.1.5 with the new setting?

It is good it is included, but if no-one migrated to the new version it will only be an improvement on paper.

Dude no worries at all we have all been there. I think that’s a completely universal thing that has happened.

@ctrl-Felix – yeah we can do the gov prop and change the code in the next upgrade, nbd.

I’m just happy to see this getting taken care of.

1 Like