Skip to content
Snippets Groups Projects
  • Sebastian Kunert's avatar
    Introduce basic slot-based collator (#4097) · e44f61af
    Sebastian Kunert authored
    
    Part of #3168 
    On top of #3568
    
    ### Changes Overview
    - Introduces a new collator variant in
    `cumulus/client/consensus/aura/src/collators/slot_based/mod.rs`
    - Two tasks are part of that module, one for block building and one for
    collation building and submission.
    - Introduces a new variant of `cumulus-test-runtime` which has 2s slot
    duration, used for zombienet testing
    - Zombienet tests for the new collator
    
    **Note:** This collator is considered experimental and should only be
    used for testing and exploration for now.
    
    ### Comparison with `lookahead` collator
    - The new variant is slot based, meaning it waits for the next slot of
    the parachain, then starts authoring
    - The search for potential parents remains mostly unchanged from
    lookahead
    - As anchor, we use the current best relay parent
    - In general, the new collator tends to be anchored to one relay parent
    earlier. `lookahead` generally waits for a new relay block to arrive
    before it attempts to build a block. This means the actual timing of
    parachain blocks depends on when the relay block has been authored and
    imported. With the slot-triggered approach we are authoring directly on
    the slot boundary, were a new relay chain block has probably not yet
    arrived.
    
    ### Limitations
    - Overall, the current implementation focuses on the "happy path"
    - We assume that we want to collate close to the tip of the relay chain.
    It would be useful however to have some kind of configurable drift, so
    that we could lag behind a bit.
    https://github.com/paritytech/polkadot-sdk/issues/3965
    - The collation task is pretty dumb currently. It checks if we have
    cores scheduled and if yes, submits all the messages we have received
    from the block builder until we have something submitted for every core.
    Ideally we should do some extra checks, i.e. we do not need to submit if
    the built block is already too old (build on a out of range relay
    parent) or was authored with a relay parent that is not an ancestor of
    the relay block we are submitting at.
    https://github.com/paritytech/polkadot-sdk/issues/3966
    - There is no throttling, we assume that we can submit _velocity_ blocks
    every relay chain block. There should be communication between the
    collator task and block-builder task.
    - The parent search and ConsensusHook are not yet properly adjusted. The
    parent search makes assumptions about the pending candidate which no
    longer hold. https://github.com/paritytech/polkadot-sdk/issues/3967
    - Custom triggers for block building not implemented.
    
    ---------
    
    Co-authored-by: default avatarDavide Galassi <davxy@datawok.net>
    Co-authored-by: default avatarAndrei Sandu <54316454+sandreim@users.noreply.github.com>
    Co-authored-by: default avatarBastian Köcher <git@kchr.de>
    Co-authored-by: default avatarJavier Viola <363911+pepoviola@users.noreply.github.com>
    Co-authored-by: command-bot <>
    Unverified
    e44f61af
Code owners
Assign users and groups as approvers for specific file changes. Learn more.