Skip to content
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

Reduce the window in which endorsements are counted #1288

Closed
edsko opened this issue Mar 11, 2020 · 1 comment
Closed

Reduce the window in which endorsements are counted #1288

edsko opened this issue Mar 11, 2020 · 1 comment
Assignees
Labels
🤝 consensus Tickets that the fine folks over at ouroboros-consensus want to keep track of priority high

Comments

@edsko
Copy link
Contributor

edsko commented Mar 11, 2020

At the moment, new protocol versions take effect at the first epoch boundary after the last required endorsement of the corresponding proposal has become stable.

Talking in terms of a hard fork (aka update of the major version number of the protocol), this means that there is basically no window at all between "we are now certain of the point of the hard fork" (that is, the last endorsement has become stable) and it actually happening (which could be the very next slot). This makes it very difficult indeed for ouroboros-consensus to make any kinds of statements about the future. In particular, consensus assumes that as long as the hard fork point is not yet known, there is a "safe zone" in which we are guaranteed no hard fork will take place and so we are justified in doing things like slot-to-time or slot-to-epoch translations in that period (remember that the hard fork can change both the SlotLength and the EpochSize, so such conversions cannot be done for slots arbitrarily far into the future). However, as things stand, the ledger can basically switch from 'we're not sure yet when it will take place" to "it will take place in the the next slot" with no safe zone at all, which means that the safe zone assumed by consensus can extend much too far into the future:

                 safe zone (2k slots)
              (because not yet certain)
  /-----------------------------------------------------------------------\
  A       B       C  
  ^       ^       ^
  |       |       |
  |       |       |
  \-- Tip of the ledger
      Last required endorsement not yet stable
      And so, transition point not yet certain 
          |       | 
          |       |
          \-- Next slot: last required endorsement now stable
                  |
                  |
                  \-- Epoch boundary: hard fork kicks in

What should happen instead is that not only should the last endorsement be stable, we should have an additional period of stability before the hard fork is allowed to kick in. Put another way, the proposal must be "stably endorsed" 2k slots before end of epoch.

This should be a relatively minor change to the rules. If the change is not compatible with the existing chain, we could insist on this longer period only for bumps in the major version, which would not be unreasonable anyway.

@edsko edsko added priority high shelley mainnet 🤝 consensus Tickets that the fine folks over at ouroboros-consensus want to keep track of labels Mar 11, 2020
@edsko
Copy link
Contributor Author

edsko commented Mar 11, 2020

Marking this as high priority since the hard fork combinator will rely on this.

nc6 added a commit that referenced this issue Mar 16, 2020
Addresses #743, and prepares the way for adressing #1288 in Byron
nc6 added a commit that referenced this issue Mar 18, 2020
Addresses #1288. This is needed for the Shelley hard fork.

This commit makes changes in the formal specification - a further commit
will make the corresponding changes to the executable spec. There will
also be a cardano-ledger PR making the implementation changes.
nc6 added a commit that referenced this issue Mar 18, 2020
@nc6 nc6 closed this as completed Mar 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🤝 consensus Tickets that the fine folks over at ouroboros-consensus want to keep track of priority high
Projects
None yet
Development

No branches or pull requests

2 participants