{
"title": "Reduce Maximum Block Size",
"description": "This Proposal reduces the maximum block size pursuant to: https://github.com/cometbft/cometbft/security/advisories/GHSA-hq58-p9mv-338c",
"changes": [
{
"subspace": "baseapp",
"key": "BlockParams",
"value": {
"max_bytes": "1048576"
}
}
],
"deposit": "100000000uatom"
}
Forum post link
IPFS link
Governance votes
The following items summarize the voting options and what it means for this proposal:
YES - reduce maximum block size on the cosmos hub
NO - keep Gaia’s maximum block size the same
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.
I’m not even sure there’s a perfect size but let me tell you what that might be:
1mb that can go up to 5mb if users pay way more fees
Or even
500kb that can go up to 5mb if users pay way more fees, let’s say the full 5mb should be 1000x the cost of the first 500kb.
That way there’s almost always room for more transactions but the more you store, the more you pay and the more stress you put on the network, the more you pay.
1mb just seemed to be a much better and safer approach than 200kb
In relation to what was disclosed yesterday from IcyCro - what would be the suggested course of action for this proposal?
It seems that passing it would INCREASE block size rather than decrease. Some can argue that this is good for future-proofing block sizes if and when more activity happens on the Hub however, for the purpose of this proposal I think it would be misleading to pass it given the current proposal description no?