Coordinated Start Time Intervals

[cmwaters]

This post is to discuss the CIP on Coordinated Start Time Intervals as can be described here

[ismail]

I think it might still be good to sync with the cometBFT team on the status and plans regarding Proposer Based Timestamps (albeit being much more complex than this CIP).

[ValarDragon]

Nice writeup, this is a good idea! I think ADR-115 is much simpler for the same solution for today’s problem right now though.

My understanding of the problem & new idea:

• We are targetting a blocktime interval
• There is a lot of natural variance in many components of blocktime.

We only control the start time of:

• When honest validators prevote† (new idea)
• When honest proposers propose

So we want to use the terms we control to get close to our constant blocktime interval target

ADR 115 proposes making the Timeout Commit being variable by the app, which controls Time until honest proposers propose. The other thing we should do is extend this to minimum time until honest validators prevote for increased reliability / removing the ability for proposers to be adversarial.

I think this is a good idea! But if I’m framing this correctly, relative to ADR-115 this just solves for protecting against adversarial proposers proposing too early. This is a good thing to do, but seems low on our issue list. (The bigger economics concern is proposers proposing too late “latency games”)

I think everything regarding PBTS/not PBTS is entirely separate to this discussion?

If theres a claim that this is simpler, I think that would only be due to enshrining Constant blocktime interval as the target within cometBFT, rather than having it more generically come from the application. (Its very easy logic in either case) The more general case from the app seems useful, but we could definitely start with this just being comet side with this as a default. (And then change if the app overrides)

† technically also time until precommit, but that seems kinda useless

[cmwaters]

@ValarDragon

The other thing we should do is extend this to minimum time until honest validators prevote for increased reliability / removing the ability for proposers to be adversarial.

I think it is likely that we will also do that here as non honest validators can still propose early and receive votes/commit which would shift times and make them inconsistent.

@ValarDragon

I think everything regarding PBTS/not PBTS is entirely separate to this discussion?

Yes, although this mechanism does alter the way that block time is calculated

---

ADR115 just passes the responsibility to the application to set the time. I’m curious, what algorithm would the application write if it wanted to get consistent times?

[adizere]

Neat design!

@cmwaters

ADR115 just passes the responsibility to the application to set the time. I’m curious, what algorithm would the application write if it wanted to get consistent times?

The application would likely use something very similar to the design in CIP-23 as:

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 .

But instead of weighted vote time, the application could alternatively use time field in PrepareProposalRequest , ProcessProposalRequest or in FinalizeBlockRequest (useful when PBTS enabled). The app uses one of these to calculate next_block_delay.

Re: PBTS I see as orthogonal. Potentially the protocol in this CIP could be improved by using PBTS instead of stake-weighted median from precommit votes. The main benefit is increased correlation/reliability of time, but since the underlying problem this CIP is solving is predictable block times, I suspect the increased in reliability is minor.

@ValarDragon

If theres a claim that this is simpler, I think that would only be due to enshrining Constant blocktime interval as the target within cometBFT, rather than having it more generically come from the application. (Its very easy logic in either case) The more general case from the app seems useful, but we could definitely start with this just being comet side with this as a default. (And then change if the app overrides)

Agree. The CIP design is easier for app-side, while ADR 115 has the advantage that it can implement the same behavior as the CIP (and other behaviors, eg dynamic block time adjustments based on activity) in exchange for more app-side lifting and footguns.

In any case, will reach out for a sync to cover PBTS and/or ADR115 in more detail, would be glad to help make a decision here or get a fuller understanding of the tradeoffs.

[cmwaters]

@adizere

Re: PBTS I see as orthogonal. Potentially the protocol in this CIP could be improved by using PBTS instead of stake-weighted median from precommit votes.

Yeah I think regardless of the timing mechanism here we will eventually want PBTS (when it’s delivered)

@adizere

But instead of weighted vote time, the application could alternatively use time field in PrepareProposalRequest , ProcessProposalRequest or in FinalizeBlockRequest (useful when PBTS enabled). The app uses one of these to calculate next_block_delay.

I see, yeah afaics, the application needs to know the round start time. So having it given in PrepareProposalRequest makes sense.

I think there’s also discussion about an alternative solution which would be to always wait the full TimeoutProposal length before prevoting since it’s the block propagation mechanism that has the greatest variance in time. That way, regardless of the block size, so long as nodes had a similar start time we would see a relatively consistent commit time