CIP: Coordinated Start Time Intervals #164
Conversation
There was a problem hiding this comment.
I think this can be assigned CIP-23.
How does this compare to https://informal.systems/blog/introducing-proposer-based-timestamps-pbts-in-cometbft?
| - In the case, that `cs.StartTime` is after the locked or proposal block time, the validator will pick a time that is 1 millisecond later to satisfy the property of increasing block times. | ||
| - In the case of the first block, the start time will be the current time. | ||
| - Upon receiving 2f + 1 PRECOMMIT votes, each validator calculates the **local** stake-weighted median start time from those votes. It sets the new start time of the next height to be the aforementioned calculated time plus the `TargetInterval`. | ||
| - If the nodes local time is after the new start time, then the node will start immediately. This will be the case for heights that require multiple rounds to come to consensus. |
There was a problem hiding this comment.
Does it mean there will be cases that the timeout_commit is disregarded? for example, the current time of the node is after the calculated start time of the next block, yet the node has not waited the entire timeout_commit since observing the 2f+1 PRECOMMIT votes, in such cases, the timeout_commit needs to be discarded?
There was a problem hiding this comment.
When this mechanism is active, TimeoutCommit is completely disregarded. I've added a line below
|
|
||
| ## Security Considerations | ||
|
|
||
| This modification changes the time located in the block to be the stake-weighted median of the start times of 2f + 1 validators from the previous block. `TargetInterval` is added to this as an approximation of when the current block was actually started. This is different from the how the current block time is calculated, however, this shift in the times is not expected to have any downstream impact. |
There was a problem hiding this comment.
Could you please elaborate, in the CIP, on the guarantees that the proposal will provide? Specifically, will the new design assure a specific range of block time?
There was a problem hiding this comment.
I've added a sentence in the Specifications section about the intuition behind achieving consistent start time intervals
|
|
||
| This modification changes the time located in the block to be the stake-weighted median of the start times of 2f + 1 validators from the previous block. `TargetInterval` is added to this as an approximation of when the current block was actually started. This is different from the how the current block time is calculated, however, this shift in the times is not expected to have any downstream impact. | ||
|
|
||
| Similar with traditional BFT time, a malicious cabal greater than 1/3 can manipulate the block time to be any time in the future. |
There was a problem hiding this comment.
[Question to understand more]
how far can 1/3rd of the network push time in the future? Indefinitely or there is an upper bound related to the target interval mechanism
|
|
||
| | Parameter | Proposed value | Description | Changeable via Governance | | ||
| |---------------|---------|------------------------------------------------------------------------------------------------------------------------|---------------------------| | ||
| | BlockParams.TargetIntervalMS | 12000 milliseconds (12 seconds) | The target interval between start times in milliseconds | false | |
There was a problem hiding this comment.
would it make sense to mention that we're confident that this mechanism will allow 12 seconds for blocks <=8mb or whatever the upper bound is?
The upper bound can be defined as the biggest block the network can process in 12 sec if they start processing it right away.
|
Closing this solution in favour of #165 |
This CIP outlines protocol changes to support more consistent average block times regardless of the size of the blocks (to a point).