Param Change: Addressing Bandwidth Consumption

Param Change Proposal: Addressing Bandwidth Consumption

Now that storage is running on main-net, thank you to everyone involved in the launch. Things are going really well, however, some RPC nodes and validators are getting overwhelmed by the sheer volume of file-storage proofs being sent to them.

The Problem

It is clear that the current storage module parameters were focused on ensuring uptime when relying on many smaller less reliable machines proving storage. This is overwhelmingly not the case anymore as there are many high-end providers involved. Uptime is much less of a concern than RPC load is now. From the time on test-net, nowhere near as many files were pushed to the volume of providers currently on main-net. The current proving window is 20 minutes, this is far too short to reasonably space out proofs. It is also clear that some providers race to get their transactions included in the very first block they can prove so that they don’t miss any more time.

The Solution

Increasing this window is a clear solution, there are going to be bottlenecks down the road but this is the first clear step in becoming a much more sustainable network for both providers & validators. This will happen in two separate parameter changes in one proposal, the proof window itself will go from 50 blocks to 600, bringing the window from 5 minutes to 1 hour. Then the proposal changes the maximum window misses from 3 to 2 which means that it will now take 3 full windows to kill a deal instead of 4. This aligns with the mission to bring the window from 20 minutes to 3 hours. This will also coincide with a provider update to change the default timings, any provider wishing to not upgrade can already adjust these with a flag.

The Proposal

This proposal has gone live first on test-net and then it’ll go on main-net with the 5-day voting period. By voting yes to this proposal, the chain will change the parameters. Voting no means you disagree with the method of reducing bandwidth or disagree with a need to scale. Voting no-with-veto means you deem this proposal harmful to the Jackal Ecosystem.


Sounds like sound planning to me. I expect it may help improve user experience as well.