flow-go
flow-go copied to clipboard
[EFM] EpochExtensionLength Protocol Parameter
Context
While in EFM, the network remains live because sequences of view ranges for which consensus leaders are defined are periodically added to the current epoch. When should a new view range (encoded as an EpochExtension
) be added?
The first EpochExtension
is added to the Protocol State in the same block as EFM is triggered.
To determine when subsequent EpochExtension
s are added, we introduce a new protocol parameter EpochExtensionLength .
Definition Of Done
### Tasks
- [ ] Implement EpochExtensionLength protocol parameter. (This would be a good application for the [Protocol state key-value storage](https://www.notion.so/dapperlabs/Protocol-state-key-value-storage-497326ff9cf44ff4a70610a0dad329b3?pvs=4))
- [ ] Sanity checks WRT finalization safety threshold
- [ ] Make it possible to specify the value of this param when bootstrapping to create global value
- [ ] Connect `GlobalParams` to be backed by the KVStore
- [ ] (if possible) Move other `GlobalParams` into KVStore as well
Further Reading
For estimating the scope of this issue, we should align on the desired implementation approach. I see 3 options (listed in order of increasing effort):
-
~hard-coded parameter (should not be a command-line argument, as inconsistent values would break consensus liveness)~
not feasible, because we want different values for different networks (like Mainnet vs benchnet vs testnet)
-
The Epoch Setup event could also specify the number of views for possible extensions. This would be a simpler way of making the parameter configurable through governance transactions
-
separate entry in the Protocol State's Key-Value store, with dedicated service event to change it.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Last PR related to this issue: https://github.com/onflow/flow-go/pull/6272
PR merged.