[PROPOSAL #970] [ACCEPTED] Update feemarket max_block_utilization to 75m gas

Change log • 2024-08-05 Created initial post • 2024-08-08 Added JSON param message • 2024-08-10 Updated to 75m Summary In v18 the hub added a new “feemarket” module from the Skip team. In the feemarket params, the max block utilization was set to just 30 million gas while the network allows up to 100 million gas per block. This recently has led to many users questioning why their transactions have failed, at no fault to them. Leading to a desegregated user experience on the hub for interacting. This proposal, if passed, updates the current feemarket max gas utilization to 75m (from 30m) per block, allowing for a buffer with current max gas of the network consensus params (100m). Details CosmosHub Upgrade handler setting to default max to 30m gas: github.com/cosmos/gaia v18.1.x/app/upgrades/v18/upgrades.go `release` ``` func ConfigureFeeMarketModule(ctx sdk.Context, keepers *keepers.AppKeepers) error { params, err := keepers.FeeMarketKeeper.GetParams(ctx) if err != nil { return err } params.Enabled = true params.FeeDenom = types.UAtomDenom…

Excerpt (1197 of 5844 characters). Read the whole post on the forum ↗

50 million?

My understanding is that there’s a little bit of overhead from the fee market itself.

But 50 million sounds quite fine

Talked with Matija, probably targeting 60-80m. 50 isn’t enough % wise from current block fill rates.

Awesome.

The 30 seemed a little bit low to me.

Thanks!

Thank you for raising this! After some data collection, it was made apparent that there are legitimate use cases for transactions with large gas usage. Namely, these transactions are: • various ICA transactions • various authz transactions • governance proposals • governance proposals for deploying permissioned CosmWasm contracts As stated above, the current gas limit may be problematic for above use cases where the gas usage was found to be in the 15M - 60M range. Additional context: The on-chain `consensus.block.max_gas` parameter must be changed to match the `feemarket.max_block_utilization`. The current mismatch is problematic because valid Txs would be rejected if their inclusion would exceed the `feemarket.max_block_utilization`. The transactions would not get added back to the mempool because they were marked as invalid by the app. This means the user would have to re-initiate the transaction manually. This degrades UX, as evidenced by issues that were opened on the Gaia repo. When you check under the hood, this happens because Comet would reap and send to the app up to `consensus.block.max_gas` (100M) worth of transactions, but the app would reject…

Excerpt (1196 of 3853 characters). Read the whole post on the forum ↗

We’ll start testing on theta and report back

After testing on localnets and testnets it was made apparent that there is a small discrepancy in chain state between new chains and chains that have upgraded from cosmos-sdk v0.47 to v0.50. On a local chain starting from block 1, all consensus params are correctly initialized with their zero-values. On testnet chains that were upgraded from v0.47 it was observed that `MsgUpdateParams` on the consensus keeper fails with a panic. The cause was identified and the issue pertains to consensus params keeper migration that only partially initialized the consensus param fields during a cosmos-sdk migration operation. This issue does not impede the normal day-to-day network operation. However, the issue prevents consensus params upgrades at this time. The issue was fixed on cosmos-sdk: • Issue: [Bug]: Consensus Params fail to update via MsgUpdateParams · Issue #21483 · cosmos/cosmos-sdk · GitHub • Fix: fix(x/consensus)!: update cons params parsing checks by MSalopek · Pull Request #21484 · cosmos/cosmos-sdk · GitHub The issue was fixed on gaia and included in the gaia v20 software upgrade: • Fix: fix!: initialize ConsensusParams Version field by MSalopek · Pull…

Excerpt (1192 of 1430 characters). Read the whole post on the forum ↗

The proposal to update the consensus and feemarket params was posted on chain. You can find the proposal link here (prop #970).

If this proposal does not execute correctly (in case it is approved), there is a backup plan to submit param changes as 2 separate proposals. The backup plan would be executed the same as on testnet:

• Ping Dashboard - Cosmos Blockchain Explorer And Web Wallet
• Ping Dashboard - Cosmos Blockchain Explorer And Web Wallet

@lexa Can we update the title of this post to reflect the current status?