FIP12: Double Fuse Network’s Block Gas Limit

Summary of the proposal. Increase Fuse Network’s block gas limit from the current 10,000,000 to 20,000,000.

Background. Fuse Network is an Ethereum Virtual Machine-compatible blockchain that relies on its version of the EVM. The EVM can be thought of as an isolated virtual computer within which transactions on smart contract blockchains are executed. The EVM is run by the network’s full nodes, a subset of which are validator nodes.

The EVM’s capacity to process transactions is not infinite, and, in practice, for chains like Fuse Network it is the EVM’s transaction processing capacity that currently determines the blockchain throughput, and not the consensus speed.

All EVM chains implement a limit on the amount of computation that can go into each block added to the chain - a block gas limit. This is done to ensure that it does not become too computationally expensive for community members to run full nodes and cause excessive network centralization. The existence of a significant number of independent network full nodes is arguably the most important pillar of public blockchains’ robustness.

Currently, our chain’s block gas limit is set at 10 million, which is substantially below those of most other major EVM chains. The current block gas limits for selected chains are as follows:

Ethereum - around 30 million

BNB Chain - 99-100 million

Polygon PoS Chain - 30 million

Avalanche c-Chain - 8 million

Cronos - 20 million

Celo - 20 million

So far, having block gas limits higher than 10 million has not caused any obvious issues for the blockchains opting for them. Hence, we at the Fuse core team believe that, while figures in excess of 30 million may entail too much node concentration risk, the block gas limit on Fuse Network can safely be increased to 20 million.

Benefits for the Fuse ecosystem. Implementing FIP12 effectively doubles the transaction throughput of the Fuse Network blockchain. With the current block gas limit, Fuse Network can process almost 200 FUSE transfers per second but with FIP12 getting implemented, this figure will rise to almost 400.

Implementation details. After the discussion on this Forum, if the overall sentiment around this Proposal turns out to be positive, it will be submitted to a vote by the Fuse Network validators using the Snapshot mechanism. If the proposal passes the validator vote, it will be included in the next Fuse node software release.

FIP12 has been running on Spark (fuse testnet) for the past 3 month. There has been no apparent issues with nodes running on spark with the larger blocks.

5 Likes

Do we really need to increase block gas limit though? If you exclude that one person that has been spamming the blockchain in the last few months (Contract 0xBCDFC165740C52e51F5356a15CA5dBdB5987502f - Fuse Explorer , over 38M transactions, and over 90% of current new transactions), then you’ll see that the blocks are mostly empty.

Wouldn’t it be a better option to increase the minimum gas price instead?

1 Like

i support this proposal, FIP12, and will be voting yes as one of the validators currently on fuse

2 Likes

I support the proposal FIP12

1 Like

Hey Tom,

Currently over the last 28days the average gas usage per block is 3.32million and we have hit the 10million limit ~1000 times (0.2% of blocks)

(Image above from march-april)

Upping the limit obviously give us more headroom for growth.

FIP13 is also in the works, this is for gas price increase this requires more thought as it affects everything built on fuse. We need to give develops ample notice to avoid stuck transactions.

1 Like

I also support this proposal. I think this will help us for growth.

I mostly understand the proposal, I am not a dev just an average user so I am expectant to read some more opinions of members of the fuse community to build my own opinion based on them.
I found this topic really important.

I was initially concerned that 5 second block times wouldn’t be enough for 20M gas blocks on fuse, but it looks like Gnosis chain is running the same consensus mechanism with the same block time (5 seconds) but with a 30M gas limit.

So, 20M should be fine. It might be helpful to stress-test the spark network to make sure things work out with contract code which has a high {execution time/gas consumed} ratio

1 Like

stress testing on spark chain have been going on for some time

1 Like

I saw there’s been some testing, but i’m specifically suggesting to test the network by creating blocks with the highest possible propagation times allowable with 20M gas, and doing so for long periods (100+ blocks in a row). Like simulating an attack on the network. I’m not sure if the current testing has done this yet

i believe that testing such as this has been done, i was running a validator on testnet, during such testing, i was told that my validator was having issues handling it, didn’t have time to look into what the issue was with the validator, so i took it off line till i have time to look into it further. this took place over a month ago.

1 Like

We support this proposal (Amamu validator)

3 Likes

I agree with this suggestion.

I agree with this as well