Skip to content
Snippets Groups Projects
  1. Jul 05, 2024
    • 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 <>
  2. Mar 31, 2023