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

Hub Proposals Parameter Change
1

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:

Example of some failed transactions:

Bank multi send:

IBC Ack:

unable to update fee market state: block utilization of 30000783 cannot exceed max block utilization of 30000000

You can verify current cosmoshub max_gas block params with

go install cosmossdk.io/tools/hubl/cmd/hubl@latest
hubl cosmoshub q consensus params

{
  "params": {
    "block": {
      "max_bytes": "2000000",
      "max_gas": "100000000"
    },
    "evidence": {
      "max_age_num_blocks": "1000000",
      "max_age_duration": "48h0m0s",
      "max_bytes": "50000"
    },
    "validator": {
      "pub_key_types": [
        "ed25519"
      ]
    }
  }
}

and feemarket with

gaiad q feemarket params --output=json --node=https://cosmoshub.rpc.kjnodes.com:443 | jq '.max_block_utilization'

# "30000000"

Read more about the feenmarket spec here

Parameter and new value

Update Feemarket MaxBlockUtilization / max_block_utilization to 75000000 (75 million) while leaving all other current mainnet params the same.

        {
            "@type": "/feemarket.feemarket.v1.MsgParams",
            "params": {
                "alpha": "0.000000000000000000",
                "beta": "1.000000000000000000",
                "gamma": "0.000000000000000000",
                "delta": "0.000000000000000000",
                "min_base_gas_price": "0.005000000000000000",
                "min_learning_rate": "0.125000000000000000",
                "max_learning_rate": "0.125000000000000000",
                "max_block_utilization": "75000000",
                "window": "1",
                "fee_denom": "uatom",
                "enabled": true,
                "distribute_fees": false
            },
            "authority": "cosmos10d07y265gmmuvt4z0w9aw880jnsr700j6zn9kn"
        }

Forum post link

IPFS link

Governance votes

The following items summarize the voting options and what it means for this proposal:

YES - Agree with increasing the feemarket max gas utilization.

NO - Disagree with increasing the feemarket max gas utilization.

NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.

ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal.

1 Like
2

50 million?

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

But 50 million sounds quite fine

3

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

1 Like
4

Awesome.

The 30 seemed a little bit low to me.

Thanks!

5

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 all Txs after reaching feemarket.max_block_utilization (30M).
To avoid further issues, the aforementioned chain params must be synchronized so the Txs that cannot fit into the current block would be added back to the mempool and attempted for inclusion on the next block.

Getting the data:

  • consensus.block.max_gas
gaiad q consensus params --node "https://cosmos-rpc.polkachu.com:443" -o json | jq .
{
  "params": {
    "block": {
      "max_bytes": "2000000",
      "max_gas": "100000000" // 100M
    },
    "evidence": {
      "max_age_num_blocks": "1000000",
      "max_age_duration": "48h0m0s",
      "max_bytes": "50000"
    },
    "validator": {
      "pub_key_types": [
        "ed25519"
      ]
    }
  }
}
  • feemarket.max_block_utilization
gaiad q feemarket params --node "https://cosmos-rpc.polkachu.com:443" -o json | jq .
{
  "alpha": "0.000000000000000000",
  "beta": "1.000000000000000000",
  "gamma": "0.000000000000000000",
  "delta": "0.000000000000000000",
  "min_base_gas_price": "0.005000000000000000",
  "min_learning_rate": "0.125000000000000000",
  "max_learning_rate": "0.125000000000000000",
  "max_block_utilization": "30000000",  // 30M
  "window": "1",
  "fee_denom": "uatom",
  "enabled": true,
  "distribute_fees": false
}

Plan of action:

Create the proposal

The proposal should include 2 messages:

  • change feemarket.max_block_utilization to 75M as suggested
  • change consensus.block.max_gas to match feemarket.max_block_utilization (both to 75M)

This way we can avoid sending 2 proposals and instead change these parameters using a single proposal.

If the proposal ends up being too large, we can split it into 2 proposals. In that case we would first update feemarket.max_block_utilization to 75M and then update consensus.block.max_gas to match feemarket.max_block_utilization.

Test the proposal changes

Before executing the proposal on a mainnet, we should first execute it on a testnet. We should set both testnets to the same values, but for simplicity let’s use theta-testnet-001 as a reference as it has more users.

Deploy the proposal

Upon successful testing on the testnet the proposal will be sent to mainnet (cosmoshub-4).
The proposal will be subject to the standard voting period.

Post-deployment data collection

After deployment, we should collect data on the testnet and mainnet to ensure that the changes have fulfilled their purpose and the main UX concerns have been addressed.

After some time has passed we can consider either increasing the parameters further or decreasing them to match the actual block utilization.

4 Likes
6

We’ll start testing on theta and report back :saluting_face:

1 Like
7

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:

The issue was fixed on gaia and included in the gaia v20 software upgrade:

After gaia v20 upgrade, a proposal should be submitted to the chain. The proposal will fail on execution if submitted before the gaia v20 upgrade takes place.

Proposal draft is available here.

1 Like
8

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:

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

4 Likes