# \[PROPOSAL #50\]\[ACCEPTED\] Governance Proposal for block\_size Parameter Changes
**URL:** https://forum.cosmos.network/t/proposal-50-accepted-governance-proposal-for-block-size-parameter-changes/4983
**Category:** Parameter Change
**Created:** [June 24, 2021, 1:36am UTC](https://forum.cosmos.network/t/proposal-50-accepted-governance-proposal-for-block-size-parameter-changes/4983 "2021-06-24T01:36:18Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@bharvest](https://forum.cosmos.network/u/bharvest)
#### Post date: [June 24, 2021, 1:36am UTC](https://forum.cosmos.network/t/proposal-50-accepted-governance-proposal-for-block-size-parameter-changes/4983/1 "2021-06-24T01:36:18Z")
- Moderator edit to add link to on-chain proposal: [Mintscan](https://www.mintscan.io/cosmos/proposals/50)
This document is a parameter governance proposal that asks Atom delegators to allow the changes of block\_size parameter values to extend the block capacity of the Cosmos Hub so that it can mitigate reasonable amount of transactions processed within a block. The parameters will be immediately updated when this governance proposal passes.
### Introduction
With the userbase growth of Gravity DEX on Cosmos Hub, it is expected that in average, the network will face much more transactions to be processed per each block. However, the network currently does not have enough block\_size parameter values to incorporate such significant growth of number of transactions.
Therefore, it is necessary to adjust such block\_size parameters to handle enough transactions within each block. But, if we adjust too high, it will open the risk of network outage caused by average low validator server specs.
Hence, it is important to find the adequate level of the parameter values to allow good amount of transaction processed within a block, but also to limit the risk of computational burden of the validator nodes.
### Parameters
There exists two kinds of block\_size parameters:
1. max\_bytes : maximum total bytes allowed for each block(currently 200,000)
2. max\_gas : maximum total gas allowed for each block(currently 2,000,000)
### Performance Simulation
We conducted a testnet simulation to test whether normal validator nodes can handle predefined number of transactions per block. To test only the computational performance, we minimized the network to 1 validator node with 2core 8gram resource. We executed scenarios with 100,200,300,400 and 500 swap transactions per block(TPB).
### Simulation Result
We observed that for the validator node with standard resource(2core 8gram), the node can steadily handle up to 500 swap transactions per block. Result is as below.
Above results show that even in 500 TPB(Transaction Per Block) scenario, average mempool size is smaller than the number of transactions coming in every block. Also, CPU, Memory and Disk(100%=4750Mbps) usage is far away from performance burden of the tested Amazon instance M5.Large.
The result does not imply that the Cosmos Hub can handle such transactions per block. It is because the Cosmos Hub has much more complex network which results in significantly more burden on relaying transaction data each other. Our real-like testnet simulation showed that the network will suffer significant delay of transaction processing when there exists more than 300 swap transactions per block.
### Suggested Parameter Values
From above simulation results, we suggest that 500 swap transactions per each block is a conservatively safe limit for the standard validator nodes to perform such computation within a block without having significant performance burden.
It is expected that most of the transactions from Gravity DEX will be swap transactions. Therefore it is reasonable to calculate appropriate parameter values based on the bytes and gas spent for each swap transaction, which is as below:
- bytes of each swap transaction : about 400 bytes
- gas of each swap transaction : about 80,000 gas
Multiplying 500 to above bytes and gas yields:
- suggested max\_bytes : 200,000
- suggested max\_gas : 40,000,000
### Conclusion
Based on this analysis we propose to change
- max\_gas value from 2,000,000 to 40,000,000
---
### Author:  [@Zippo](https://forum.cosmos.network/u/Zippo)
#### Post date: [June 28, 2021, 10:53am UTC](https://forum.cosmos.network/t/proposal-50-accepted-governance-proposal-for-block-size-parameter-changes/4983/2 "2021-06-28T10:53:59Z")
Resource usage at 500 TPB looks good!
Given an increase in max\_gas and no increase in max\_bytes, there shouldn’t be an acceleration in state growth, right?
---
### Author:  [@bharvest](https://forum.cosmos.network/u/bharvest)
#### Post date: [June 28, 2021, 11:47am UTC](https://forum.cosmos.network/t/proposal-50-accepted-governance-proposal-for-block-size-parameter-changes/4983/3 "2021-06-28T11:47:57Z")
Orders in batches are removed when it is processed. Therefore, if node is not pruning-nothing, states will not grow significantly because the state only stores orders in current batch, which is refreshed for every batch.
Current cosmoshub uses much under the bytes limit. So even though it will not grow continuously, it should grow some.
I observe that Osmosis is experiencing lack of gas in a block(I remember the limit is only several million), which result in tx failures. Hence, it is good to be ready with larger gas limit to mitigate hundreds of swap transactions coming into a block.
Also for every message, gas is much more efficient in gravity dex than osmosis, so it should handle more txs within a block than osmosis.