[N4] Dynamic Block Interval

[ajara87]

Description

Related to #4241

• Make PolicyContract a partial class to add DynamicBlockInterval
• Add new atribute to configure an array of milliseconds per block
• Add new atribute to configure an array of maximum transactions per block
• Move MaxTransactionsPerBlock and MillisecondsPerBlock from config to Policy (read from config just when initialize)

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• Unit Testing
• Run Application
• Local Computer Tests
• No Testing

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[erikzhang]

I think we should first decouple the GAS reward from the block height. We should adopt a calculation method based on the block timestamp.

And this can be implemented on N3 first.

[vncoelho]

@erikzhang ,
That is a good start.

@ajara87, I am not sure if these parameters should indeed come here. It is still not clear to me how this will be automatically adjusted. Currently, Policy is adjusted by the committee. On the other hand, the parameter here will be more automatically (maybe signed by CNs agreed during block production).

What is the mechanism we will have here to control the updates on those values?

@shargon

[erikzhang]

Simplified Dynamic Block Time (Tiered Control)
The system automatically adjusts block time based on network load:

• High load: many pending transactions → shorten block time to produce blocks faster.

• Normal load: moderate activity → keep regular block time for balanced performance.

• Low load: few transactions → lengthen block time to reduce empty blocks.

Changes happen gradually with limits and cooldowns to avoid oscillation.
This simple three-level design is easy to implement and keeps the network adaptive and stable.

[vncoelho]

• High load: many pending transactions → shorten block time to produce blocks faster.

From our experiments it is the opposite, @erikzhang

• High load: many pending transactions → longer block time are required to avoid change views

With many pending transaction and thousands of incoming transactions per second it becomes hard to propose a block and that backups will agree on that list.

But one good question is that what is considered high load?
If high load is 5k-10k TPS then it is ok, any solution will work for now.

[shargon]

I think we should first decouple the GAS reward from the block height. We should adopt a calculation method based on the block timestamp.

And this can be implemented on N3 first.

But we can define also in N3 only one step of 15.000ms, definition and reward can be done in different prs without interfering N3 and both can be done separately

[shargon]

Simplified Dynamic Block Time (Tiered Control) The system automatically adjusts block time based on network load:

• High load: many pending transactions → shorten block time to produce blocks faster.
• Normal load: moderate activity → keep regular block time for balanced performance.
• Low load: few transactions → lengthen block time to reduce empty blocks.

Changes happen gradually with limits and cooldowns to avoid oscillation. This simple three-level design is easy to implement and keeps the network adaptive and stable.

Agree. 3 levels is more then enough

[vncoelho]

Simplified Dynamic Block Time (Tiered Control) The system automatically adjusts block time based on network load:

• High load: many pending transactions → shorten block time to produce blocks faster.
• Normal load: moderate activity → keep regular block time for balanced performance.
• Low load: few transactions → lengthen block time to reduce empty blocks.

Changes happen gradually with limits and cooldowns to avoid oscillation. This simple three-level design is easy to implement and keeps the network adaptive and stable.

Agree. 3 levels is more then enough

The 3 levels are enough, also with the idea of gradually changing the limits and cooldowns.
The question is where the parameters will stay, maybe not in Policy Contract.
We will need to adjust them by someone, perhaps the consensus. To understand where we are and which is the network current demand we need a consensus, so, perhaps this is agreed on block header as additional info.

@erikzhang

[vncoelho]

And we should enable snapshot/checkpoint in neo, to remove empty block regularly.

I think it is a good idea

to be honest, i dont think empty block will ever be an issue anymore if we can truly decouple Gas reward from block generation.

If GAS reward is decoupled it would help, but is that on our plan for now?
I see that we will now double GAS reward from index to timestamp

[vncoelho]

@shargon, is it easy that we set the levels here on Policy Contract during block Persistance?

Because one possibility is that Speaker propose the level change and backups agree. So during block persist we need to update Policy Contract.

There are other possibilities that it is deterministic based on block data, but it will also requires that we publish other additional information in the blocks.

[Wi1l-B0t]

Before submitting the code, maybe submit a design document first?