[Consensus] Enforce MinBlockTime at the replicas level

[red-0ne]

Objective

Enforce MinBlockTime at the replicas level instead of giving full powers to the leader

We could leverage replicas NewRound message delaying to reduce leader's power to delay block production.

Origin Document

Currently a leader of a given round has full control over block production delay. There's nothing enforcing it not to propose a block earlier than what the network agreed on.

If we place the delay at the new round message emission point. All (honest) replicas will delay their new round messages so that the leader could not reach the consensus and build the block earlier. This would mean that each block proposal time is enforced by the whole network instead of by its leader only. We could floor the delay imposed by replicas (eg. -10%) and let the leader that window to fine grain the timer.

A possible issue with this approach, is that it makes reaching NewRound quorum will always a hurry task. As NewRound are released late, there may be problems reaching quorum on time.

An adjustable offset could do the trick and even be dynamic. Also choreographing the replicas to distribute their deadlines over the MinBlockTime period of time may also be worth digging.

This should not be that much of a change. Since at the new round construction level, any node knows if it's the leader of that round or not:

• If it is a leader
  • Registers the timer at that exact moment (the earliest a node knows there's a new round and that it's the leader)
  • Sends the new round to itself (acts like a replica)
  • If it reaches new round quorum it prepares the block by applying the delay logic according to its local timer
• If it's a replica
  • Registers the timer at that exact moment (the earliest that replica commits for the new round --should be same as leader)
  • Delays broadcasting new round message to the leader by MinBockTime - AdjustableOffset ± (Randomness or distribution function)

This way, for a 15minutes block time the whole network could eg. enforce that a block is proposed no earlier than 14minutes, and leader makes sure it lands at the 15minutes mark

Goals

• Make block time production (MinBlockTime) enforced by the replicas instead of the leader only

Deliverable

• [ ] Move (rename if needed) DelayBlockPreparation to pacemaker.NewHeight() with checks to delay it only for replicas
• [ ] Add a configurable option or function/strategy to adjust delay to have an overall 15minutes min block delay

Testing Methodology

• [ ] Task specific tests or benchmarks: make ...
• [ ] New tests or benchmarks: make ...
• [ ] All tests: make test_all
• [ ] LocalNet: verify a LocalNet is still functioning correctly by following the instructions at docs/development/README.md
• [ ] k8s LocalNet: verify a k8s LocalNet is still functioning correctly by following the instructions here

---

Creator: @red-0ne

[red-0ne]

cc @Olshansk

[Olshansk]

@red-0ne Unlreated to the details of the issue:

1. Please make sure to update issue (& PR) metadata in the future

2. If there's an opportunity to use diagrams to explain the problem statement / issue. Please do so!

Will follow up with thoughts / ideas related to this below...

[Olshansk]

tl;dr I strongly believe we SHOULD NOT pursue this task.

---

Currently a leader of a given round has full control over block production delay. There's nothing enforcing it not to propose a block earlier than what the network agreed on.

I would say this is not true.

We have heights/steps/rounds. A new Round starts when 2/3+ NewRound messages are propagated and seen by that portion of the network.

An adjustable offset could do the trick and even be dynamic. Also choreographing the replicas to distribute their deadlines over the MinBlockTime period of time may also be worth digging.

Sounds like you're proposing to make MinBlockTIme a governance parameters (see utility/types/gov.go).

I am open to this idea, but it still makes "managing time" hard; see below.

This should not be that much of a change. Since at the new round construction level, any node knows if it's the leader of that round or not:

Time (in the human world) & blockchains "don't really work well together."

At its core, the [bitcoin whitepaper] outlined an expensive Timestamping server that guarantees time through hash power which is why there's having complexity. We can go into a lot of edges cases and this will go down a rabbit hole that will deter us from our current goal: parity with v0. I've done this before ;)

On the topic of parity with v0, if you run pocket query params on v0, you'll see that pos/BlocksPerSession is a governance parameter, but 15min is achieved through social consensus.

The only way "time" is actually enforced in blockchains is enforced in blockchains is using Verifiable Delay Functions. See how Chia does Proof of Time.

I WOULD LOVE to revisit this after MainNet launch, but believe it is out scope for the foreseeable future.

[Olshansk]

cc @adshmh who might find this conversion interesting (no action necessary).