Update Babe Specification in Consensus Chapter

[drskalman]

Resources

• Current Research Write Up

To be done

• Specify NextEpochDescriptor (Investigate epoch descriptor #173)
• Update relative time algorithm (Update BABE specification (Relative Time, Consensus Message Digest, etc.) #168)
• Specify NextConfigDescriptor (babe: support online configuration upgrades paritytech/substrate#5514)
• Review Update BABE to the latest changes from pull 3611 #50, Spec Slot-number for given time #54, Define authority directory for each epoch #55, Spec Threshold calculation for babe #56

Beyond current scope

• Specify SecondarySlot (Specify Babe's secondary slots #233)
• Specify Lateness (support: add lateness trait paritytech/substrate#5519)
• Check Equivocations change (babe: report equivocations paritytech/substrate#6362)

[rphmeier]

A small write-up here to assist a bit (I had offline conversations with Al & Jeff about this in Zug)

1. The "configuration" of the chain is drawn by querying BabeApi::configuration with the state of the genesis block. The result of this function at any other block is unimportant for now (but may become more important as we move into designing things like swappable consensus). The struct is babe_primitives::BabeConfiguration - that should be a minimal set of things to get the chain started.
2. At the first block of every epoch, we're expecting a Consensus digest item containing the authorities, weights, and randomness for the next epoch. The definition of this can also be found in the primitives crate as NextEpochDescriptor.
3. The first epoch (epoch #0) is special-cased. The genesis block is said to have slot 0. The slot of the first block defines the actual slot where epoch 0 starts. Thus any block with number 1 is the first block of the first epoch, and should have a NextEpochDescriptor digest to describe epoch 1. This is expected to be the same randomness and authorities as the genesis configuration -- we aren't really worried about byzantine attacks that happen on the first block. The client code should have a mechanism for ensuring that a block with number 1 has a specific hash that is added to the chain-spec once the chain is launched.

[rphmeier]

about secondary-slots (i.e. aurababous):
The configuration contains a flag secondary_slots (previously, this could change from epoch to epoch, but that doesn't really make sense without the ability to change the slot duration).

If secondary_slots is enabled for the chain, then a block at slot slot_number can also be sealed round-robin leader based on i = blake2_256(encode((epoch_randomness, slot_number)) % epoch_authorities.len(); epoch_authorities[i], where epoch_randomness and epoch_authorities are determined based on the parent chain and slot number.

[drskalman]

Waiting for the illustration to be converted from illustrator to eps by @iggyweb3.

[drskalman]

@FlorianFranzen will update the spec according the discussion with @hndnklnc.

[rphmeier]

cc @sorpaas A couple things have changes with your recent PRs, right?

[sorpaas]

Yeah. About online upgrades and secondary VRF. paritytech/substrate#5501 and paritytech/substrate#5514

Summary of the changes are as follows:

• A new pre-digest type -- secondary VRF slot is introduced. It's exactly the same as secondary slot, except that it also generates a VRF. Secondary VRF is not included in randomness.
• The BabeApi is slightly changed. The method configuration still returns the genesis configuration, but the struct is slightly modified. The last parameter secondary_slots: bool is changed to allowed_slots: AllowedSlots to add a third variant "using primary slot and secondary VRF slot".
• A new post-digest type NextConfigDescriptor is added. This descriptor can only be used at epoch transition, on the same block as NextEpochDescriptor. NextConfigDescriptor is optional, and modifies the config value of c and allowed_slots of the next upcoming epoch (same as the block NextEpochDescriptor points to).

[drskalman]

@hndnklnc is busy now so we move it to blocked till she can review it.

[drskalman]

@FlorianFranzen doesn't think much needed to updated. Should be done by next research sync.

[drskalman]

Let spec enough so we can close the research internal ticket then we can discuss with the research team how much of the extras need to be specced.

[drskalman]

We do number 1 and 3 and submit to @hndnklnc for review then we do the rest later. 1 and 3 should be ready for review by July 15.

[drskalman]

We need to do also spec fast join which comes out of the discussion of @FlorianFranzen and @hndnklnc.

[drskalman]

The pull request #168 is still open and under review. The discussion resulted in more questions like how to keep the clock after client update, etc.

[FlorianFranzen]

Everything that needed to be done is now part of #168. I will open another issue for "fast-joining", which is not part of the spec yet, due to some open discussion points.