[PROPOSAL #50][ACCEPTED] Governance Proposal for block_size Parameter Changes

Hub Proposals Parameter Change
1

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.

image
image838×220 49 KB

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
5 Likes
2

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?

3

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.

1 Like