IntersectMBO / IntersectMBO/ouroboros-consensus
Schedule chain selection for blocks from future in volatile DB on startup
- Dominant language
- Haskell
- Stars
- 67
- Forks
- 43
- Avg merge
- 5d 13h
- Merged PRs (30d)
- 43
Description
At the moment, when a block comes in from the (near) future, we don't reject it, but store it in the volatile DB and schedule a chain selection for that block when it becomes present. The reason we do this is that if the node's clock is behind the real time, _every_ block that comes in will be slightly ahead, so and if we merely stored them but never triggered chain selection, we would never grow our chain at all. On startup, we don't bother scheduling chain selection from any blocks we find on disk that are still in the future; we will consider them when the next block comes in (which may itself be in the future, in which case we'd schedule a chain selection for it later). This is not problematic, but it just means that the state before and after a restart is not the same, which feels a bit inconsistent, and leads to some accidental complexity in the tests.
Contributor guide
Assessment
This issue has not been assessed yet.