Concordium / Concordium/concordium-node
New Consensus: Optimisations
- Dominant language
- Haskell
- Stars
- 108
- Forks
- 24
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 9
Description
This issue is for optimisations in the consensus implementation that were passed over initially (e.g. for simplicity).
- [ ] Cache the status of the baker as a member of the finalization committee.
- [ ] Snapshot payday length when `nextPayday == currentEpoch +1` (together with bakers and finalizers, finalization params) such that bakers and finalizers does not have to be recomputed in the case where a block arrives with an epoch `e` and `e > currentEpoch + 1` , ` nextPayday == currentEpoch + 1` and `e` is in the same payday as `currentEpoch + 1`.
https://github.com/Concordium/concordium-node/pull/751#discussion_r1174790310 https://github.com/Concordium/concordium-node/pull/751#discussion_r1175367174
Note. this might not be worth doing as it's a rather niche case that is probably not going to be hit much. In order for this case to matter then epochs would have to pass without blocks (except for the ones triggering the epoch transition) and then the peer catching up will carry out these re-computations as it is not seeing the quorum messages "live".
- [ ] Accumulate the timeout weights https://github.com/Concordium/concordium-node/pull/751#discussion_r1191205935
- [ ] TC validity: By enforcing `maxRound (tcFinalizerQCRoundsFirstEpoch tc) < minRound (tcFinalizerQCRoundsSecondEpoch tc)` when checking a TC we can omit some computations some places https://github.com/Concordium/concordium-node/pull/751#discussion_r1184792412
- [ ] Remove `PendingBlock` functionality and let the catchup mechanism handle the case where a parent is unknown. This happens under rare occurrences (unless the node is already catching up), so it doesn't seem like the complexity is worth the trouble of managing the pending blocks.
- [ ] Consider keeping a copy of the leadership election nonce in the treestate and update it when advancing epoch. This can avoid some computations at different places. On the other hand I'm not sure that there will be much gain from this as compared to the complexity of having more complex invariants in the code.
Contributor guide
Research direction
Start by reading the consensus implementation and the linked discussions from pull request #751 to understand which optimization is still relevant. Choose and scope one unchecked item; done should include preserving consensus behavior and confirming the optimization's benefit, but the issue does not name files or tests to run.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- haskell
- Domain
- blockchain, distributed-systems
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100