IntersectMBO / IntersectMBO/ouroboros-consensus

Reconsider requiring era transition knowledge to not be subject to rollback ("double stability")

Open
#419 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
Haskell
Stars
67
Forks
43
Avg merge
5d 13h
Merged PRs (30d)
43

Description

Right now, the Consensus layer is written under the assumption that once an era transition is known, it will definitely happen, even in the presence of rollbacks (but still assuming a max rollback of $k$)[^1]. In particular, this means that using different ledger states to translate a slot to a wall-clock time will always give the same result if defined (see Property 17.3 in the report for a precise statement).

For example, this means that the result (if defined) of time conversions using local ledger state queries is independent of the concrete ledger state that was acquired, which is a desirable property. However, it seems that this property could also be fulfilled via other means (eg only answering such queries using the immutable ledger state).

Currently, this stability property is enforced by

1. requiring the ledger to only consider on-chain information that could influence an era transition at an epoch boundary before a deadline that is at least *two* stability windows before that boundary (this is what "double stability" refers to), and
2. only reporting an era transition once we can no longer roll back before that deadline[^2].

The goal of this ticket is to determine whether we want to stop requiring this stability property, as it might simplify certain parts of the implementation and/or simplify certain reasoning.

Extra context: See the dimensions DSR and QSR in #346.

[^1]: See #385 for a slight caveat.
[^2]: Right now, for Cardano, this is done using block counting, see #389; it could be enforced by a slot threshold (which would require #413), but would then have different behavior in case of a chain growth violation in the first `3k/f` slots after the voting deadline.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.