[Feature]: Adjusting Block Interval Dynamically for Improved Network Scalability and TPS Through Governance in Cosmos SDK

[aansheng]

Summary

User Needs

Users of Cosmos SDK-based blockchains need the ability to adjust the block interval dynamically to optimize for network conditions and usage patterns. Initially, when the network activity is low, a longer block interval (e.g., 60 seconds) can save resources. As the network grows and transaction demand increases, the community might need to shorten the block interval (e.g., to 3 seconds) to increase transaction throughput and improve user experience.

Solution Impact

Introducing a mechanism for on-chain governance to adjust the block interval would empower network validators and stakeholders to vote on and implement changes that best fit the network's evolving needs. This flexibility could enhance network efficiency, reduce costs during low-usage periods, and increase throughput during high-usage periods, aligning network performance with actual demand.

Problem Definition

No response

Proposed Feature

Description

The proposal is to add a feature in Cosmos SDK that allows on-chain governance to dynamically adjust the block interval. This could be achieved by making the block interval a parameter that can be modified through governance proposals and votes.

• Governance-controlled Block Interval: Introduce a new parameter in the blockchain's governance module that represents the block interval. Validators and token holders can propose and vote on changes to this parameter.
• Dynamic Adjustment Mechanism: Implement a mechanism that adjusts the block creation process based on the current block interval parameter. This would require changes in the consensus module to respect the block interval set by governance decisions.
• Safety Measures: To prevent abrupt or harmful changes, introduce safeguards like minimum and maximum limits for the block interval and require a significant majority for such changes.

This feature would allow the network to adapt its performance to its operational context and community preferences, thereby enhancing its scalability and responsiveness to user needs.

[tac0turtle]

unfortunately we dont control block times, this is a local parameter to every operator. Dynamic block times is something we are working towards with other changes. There are changes we need to do in order to do correct accounting for networks. If you would like to be able to change block times via a parameter this would need to happen on comet.

Ill leave this issue open for a little and use it as a central point for dynamic block times.

[aansheng]

@tac0turtle Thank you for the clarification. To ensure a consistent block interval of 5 seconds across all nodes in the network, should we coordinate to set the timeout_commit parameter in the config.toml file of each node to 5 seconds? Understanding that dynamic block times are a work in progress, setting timeout_commit uniformly across nodes might be a temporary solution. Any guidance on this approach or recommendations for preparing for dynamic block times would be greatly appreciated.

[tac0turtle]

yes, modifying the commit_timeout is the correct approach. Are your current blocks at 5 seconds?

the commit_timeout is only on the commit phase so your blocks may be longer here

[aansheng]

@tac0turtle Thank you for confirming that timeout_commit is the right parameter to adjust. Yes, the default block time on our network is currently 3 seconds, and we aim to change it to 5 seconds to better suit our needs. Based on your advice, we will proceed to set timeout_commit to 5 seconds on all our nodes. This adjustment should help us achieve the desired block interval. Thanks again for your guidance.