-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Consensus] Enforce MinBlockTime at the replicas level #953
Comments
cc @Olshansk |
@red-0ne Unlreated to the details of the issue:
Will follow up with thoughts / ideas related to this below... |
tl;dr I strongly believe we SHOULD NOT pursue this task.
I would say this is not true. We have heights/steps/rounds. A new
Sounds like you're proposing to make I am open to this idea, but it still makes "managing time" hard; see below.
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
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. |
cc @adshmh who might find this conversion interesting (no action necessary). |
Objective
Enforce
MinBlockTime
at the replicas level instead of giving full powers to the leaderWe 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. AsNewRound
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:
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
MinBlockTime
) enforced by the replicas instead of the leader onlyDeliverable
DelayBlockPreparation
topacemaker.NewHeight()
with checks to delay it only for replicasTesting Methodology
make ...
make ...
make test_all
LocalNet
is still functioning correctly by following the instructions at docs/development/README.mdk8s LocalNet
is still functioning correctly by following the instructions hereCreator: @red-0ne
The text was updated successfully, but these errors were encountered: