1. Mar 04, 2024
    • Gavin Wood's avatar
      FRAME: Create `TransactionExtension` as a replacement for `SignedExtension` (#2280) · fd5f9292
      Gavin Wood authored
      Closes #2160
      
      First part of [Extrinsic
      Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415
      
      )
      
      Introduces a new trait `TransactionExtension` to replace
      `SignedExtension`. Introduce the idea of transactions which obey the
      runtime's extensions and have according Extension data (né Extra data)
      yet do not have hard-coded signatures.
      
      Deprecate the terminology of "Unsigned" when used for
      transactions/extrinsics owing to there now being "proper" unsigned
      transactions which obey the extension framework and "old-style" unsigned
      which do not. Instead we have __*General*__ for the former and
      __*Bare*__ for the latter. (Ultimately, the latter will be phased out as
      a type of transaction, and Bare will only be used for Inherents.)
      
      Types of extrinsic are now therefore:
      - Bare (no hardcoded signature, no Extra data; used to be known as
      "Unsigned")
      - Bare transactions (deprecated): Gossiped, validated with
      `ValidateUnsigned` (deprecated) and the `_bare_compat` bits of
      `TransactionExtension` (deprecated).
        - Inherents: Not gossiped, validated with `ProvideInherent`.
      - Extended (Extra data): Gossiped, validated via `TransactionExtension`.
        - Signed transactions (with a hardcoded signature).
        - General transactions (without a hardcoded signature).
      
      `TransactionExtension` differs from `SignedExtension` because:
      - A signature on the underlying transaction may validly not be present.
      - It may alter the origin during validation.
      - `pre_dispatch` is renamed to `prepare` and need not contain the checks
      present in `validate`.
      - `validate` and `prepare` is passed an `Origin` rather than a
      `AccountId`.
      - `validate` may pass arbitrary information into `prepare` via a new
      user-specifiable type `Val`.
      - `AdditionalSigned`/`additional_signed` is renamed to
      `Implicit`/`implicit`. It is encoded *for the entire transaction* and
      passed in to each extension as a new argument to `validate`. This
      facilitates the ability of extensions to acts as underlying crypto.
      
      There is a new `DispatchTransaction` trait which contains only default
      function impls and is impl'ed for any `TransactionExtension` impler. It
      provides several utility functions which reduce some of the tedium from
      using `TransactionExtension` (indeed, none of its regular functions
      should now need to be called directly).
      
      Three transaction version discriminator ("versions") are now
      permissible:
      - 0b000000100: Bare (used to be called "Unsigned"): contains Signature
      or Extra (extension data). After bare transactions are no longer
      supported, this will strictly identify an Inherents only.
      - 0b100000100: Old-school "Signed" Transaction: contains Signature and
      Extra (extension data).
      - 0b010000100: New-school "General" Transaction: contains Extra
      (extension data), but no Signature.
      
      For the New-school General Transaction, it becomes trivial for authors
      to publish extensions to the mechanism for authorizing an Origin, e.g.
      through new kinds of key-signing schemes, ZK proofs, pallet state,
      mutations over pre-authenticated origins or any combination of the
      above.
      
      ## Code Migration
      
      ### NOW: Getting it to build
      
      Wrap your `SignedExtension`s in `AsTransactionExtension`. This should be
      accompanied by renaming your aggregate type in line with the new
      terminology. E.g. Before:
      
      ```rust
      /// The SignedExtension to the basic transaction logic.
      pub type SignedExtra = (
      	/* snip */
      	MySpecialSignedExtension,
      );
      /// Unchecked extrinsic type as expected by this runtime.
      pub type UncheckedExtrinsic =
      	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;
      ```
      
      After:
      
      ```rust
      /// The extension to the basic transaction logic.
      pub type TxExtension = (
      	/* snip */
      	AsTransactionExtension<MySpecialSignedExtension>,
      );
      /// Unchecked extrinsic type as expected by this runtime.
      pub type UncheckedExtrinsic =
      	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;
      ```
      
      You'll also need to alter any transaction building logic to add a
      `.into()` to make the conversion happen. E.g. Before:
      
      ```rust
      fn construct_extrinsic(
      		/* snip */
      ) -> UncheckedExtrinsic {
      	let extra: SignedExtra = (
      		/* snip */
      		MySpecialSignedExtension::new(/* snip */),
      	);
      	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
      	let signature = payload.using_encoded(|e| sender.sign(e));
      	UncheckedExtrinsic::new_signed(
      		/* snip */
      		Signature::Sr25519(signature),
      		extra,
      	)
      }
      ```
      
      After:
      
      ```rust
      fn construct_extrinsic(
      		/* snip */
      ) -> UncheckedExtrinsic {
      	let tx_ext: TxExtension = (
      		/* snip */
      		MySpecialSignedExtension::new(/* snip */).into(),
      	);
      	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
      	let signature = payload.using_encoded(|e| sender.sign(e));
      	UncheckedExtrinsic::new_signed(
      		/* snip */
      		Signature::Sr25519(signature),
      		tx_ext,
      	)
      }
      ```
      
      ### SOON: Migrating to `TransactionExtension`
      
      Most `SignedExtension`s can be trivially converted to become a
      `TransactionExtension`. There are a few things to know.
      
      - Instead of a single trait like `SignedExtension`, you should now
      implement two traits individually: `TransactionExtensionBase` and
      `TransactionExtension`.
      - Weights are now a thing and must be provided via the new function `fn
      weight`.
      
      #### `TransactionExtensionBase`
      
      This trait takes care of anything which is not dependent on types
      specific to your runtime, most notably `Call`.
      
      - `AdditionalSigned`/`additional_signed` is renamed to
      `Implicit`/`implicit`.
      - Weight must be returned by implementing the `weight` function. If your
      extension is associated with a pallet, you'll probably want to do this
      via the pallet's existing benchmarking infrastructure.
      
      #### `TransactionExtension`
      
      Generally:
      - `pre_dispatch` is now `prepare` and you *should not reexecute the
      `validate` functionality in there*!
      - You don't get an account ID any more; you get an origin instead. If
      you need to presume an account ID, then you can use the trait function
      `AsSystemOriginSigner::as_system_origin_signer`.
      - You get an additional ticket, similar to `Pre`, called `Val`. This
      defines data which is passed from `validate` into `prepare`. This is
      important since you should not be duplicating logic from `validate` to
      `prepare`, you need a way of passing your working from the former into
      the latter. This is it.
      - This trait takes two type parameters: `Call` and `Context`. `Call` is
      the runtime call type which used to be an associated type; you can just
      move it to become a type parameter for your trait impl. `Context` is not
      currently used and you can safely implement over it as an unbounded
      type.
      - There's no `AccountId` associated type any more. Just remove it.
      
      Regarding `validate`:
      - You get three new parameters in `validate`; all can be ignored when
      migrating from `SignedExtension`.
      - `validate` returns a tuple on success; the second item in the tuple is
      the new ticket type `Self::Val` which gets passed in to `prepare`. If
      you use any information extracted during `validate` (off-chain and
      on-chain, non-mutating) in `prepare` (on-chain, mutating) then you can
      pass it through with this. For the tuple's last item, just return the
      `origin` argument.
      
      Regarding `prepare`:
      - This is renamed from `pre_dispatch`, but there is one change:
      - FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM
      `validate`!!
      - (This is different to `SignedExtension` which was required to run the
      same checks in `pre_dispatch` as in `validate`.)
      
      Regarding `post_dispatch`:
      - Since there are no unsigned transactions handled by
      `TransactionExtension`, `Pre` is always defined, so the first parameter
      is `Self::Pre` rather than `Option<Self::Pre>`.
      
      If you make use of `SignedExtension::validate_unsigned` or
      `SignedExtension::pre_dispatch_unsigned`, then:
      - Just use the regular versions of these functions instead.
      - Have your logic execute in the case that the `origin` is `None`.
      - Ensure your transaction creation logic creates a General Transaction
      rather than a Bare Transaction; this means having to include all
      `TransactionExtension`s' data.
      - `ValidateUnsigned` can still be used (for now) if you need to be able
      to construct transactions which contain none of the extension data,
      however these will be phased out in stage 2 of the Transactions Horizon,
      so you should consider moving to an extension-centric design.
      
      ## TODO
      
      - [x] Introduce `CheckSignature` impl of `TransactionExtension` to
      ensure it's possible to have crypto be done wholly in a
      `TransactionExtension`.
      - [x] Deprecate `SignedExtension` and move all uses in codebase to
      `TransactionExtension`.
        - [x] `ChargeTransactionPayment`
        - [x] `DummyExtension`
        - [x] `ChargeAssetTxPayment` (asset-tx-payment)
        - [x] `ChargeAssetTxPayment` (asset-conversion-tx-payment)
        - [x] `CheckWeight`
        - [x] `CheckTxVersion`
        - [x] `CheckSpecVersion`
        - [x] `CheckNonce`
        - [x] `CheckNonZeroSender`
        - [x] `CheckMortality`
        - [x] `CheckGenesis`
        - [x] `CheckOnlySudoAccount`
        - [x] `WatchDummy`
        - [x] `PrevalidateAttests`
        - [x] `GenericSignedExtension`
        - [x] `SignedExtension` (chain-polkadot-bulletin)
        - [x] `RefundSignedExtensionAdapter`
      - [x] Implement `fn weight` across the board.
      - [ ] Go through all pre-existing extensions which assume an account
      signer and explicitly handle the possibility of another kind of origin.
      - [x] `CheckNonce` should probably succeed in the case of a non-account
      origin.
      - [x] `CheckNonZeroSender` should succeed in the case of a non-account
      origin.
      - [x] `ChargeTransactionPayment` and family should fail in the case of a
      non-account origin.
        - [ ] 
      - [x] Fix any broken tests.
      
      ---------
      
      Signed-off-by: default avatargeorgepisaltu <[email protected]>
      Signed-off-by: default avatarAlexandru Vasile <[email protected]>
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      Signed-off-by: default avatarAlexandru Gheorghe <[email protected]>
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarNikhil Gupta <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: default avatarChevdor <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarMaciej <[email protected]>
      Co-authored-by: default avatarJavier Viola <[email protected]>
      Co-authored-by: default avatarMarcin S. <[email protected]>
      Co-authored-by: default avatarTsvetomir Dimitrov <[email protected]>
      Co-authored-by: default avatarJavier Bullrich <[email protected]>
      Co-authored-by: default avatarKoute <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: Vladimir Istyufeev's avatarVladimir Istyufeev <[email protected]>
      Co-authored-by: default avatarRoss Bulat <[email protected]>
      Co-authored-by: default avatarGonçalo Pestana <[email protected]>
      Co-authored-by: default avatarLiam Aharon <[email protected]>
      Co-authored-by: default avatarSvyatoslav Nikolsky <[email protected]>
      Co-authored-by: default avatarAndré Silva <[email protected]>
      Co-authored-by: default avatarOliver Tale-Yazdi <[email protected]>
      Co-authored-by: default avatars0me0ne-unkn0wn <[email protected]>
      Co-authored-by: default avatarordian <[email protected]>
      Co-authored-by: default avatarSebastian Kunert <[email protected]>
      Co-authored-by: default avatarAaro Altonen <[email protected]>
      Co-authored-by: default avatarDmitry Markin <[email protected]>
      Co-authored-by: default avatarAlexandru Vasile <[email protected]>
      Co-authored-by: default avatarAlexander Samusev <[email protected]>
      Co-authored-by: default avatarJulian Eager <[email protected]>
      Co-authored-by: default avatarMichal Kucharczyk <[email protected]>
      Co-authored-by: default avatarDavide Galassi <[email protected]>
      Co-authored-by: default avatarDónal Murray <[email protected]>
      Co-authored-by: default avataryjh <[email protected]>
      Co-authored-by: default avatarTom Mi <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      Co-authored-by: default avatarWill | Paradox | ParaNodes.io <[email protected]>
      Co-authored-by: default avatarBastian Köcher <[email protected]>
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      Co-authored-by: default avatarJoshy Orndorff <[email protected]>
      Co-authored-by: default avatarPG Herveou <[email protected]>
      Co-authored-by: default avatarAlexander Theißen <[email protected]>
      Co-authored-by: default avatarKian Paimani <[email protected]>
      Co-authored-by: default avatarJuan Girini <[email protected]>
      Co-authored-by: default avatarbader y <[email protected]>
      Co-authored-by: default avatarJames Wilson <[email protected]>
      Co-authored-by: default avatarjoe petrowski <[email protected]>
      Co-authored-by: default avatarasynchronous rob <[email protected]>
      Co-authored-by: default avatarParth <[email protected]>
      Co-authored-by: default avatarAndrew Jones <[email protected]>
      Co-authored-by: default avatarJonathan Udd <[email protected]>
      Co-authored-by: default avatarSerban Iorga <[email protected]>
      Co-authored-by: default avatarEgor_P <[email protected]>
      Co-authored-by: default avatarBranislav Kontur <[email protected]>
      Co-authored-by: default avatarEvgeny Snitko <[email protected]>
      Co-authored-by: default avatarJust van Stam <[email protected]>
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      Co-authored-by: default avatargupnik <[email protected]>
      Co-authored-by: default avatardzmitry-lahoda <[email protected]>
      Co-authored-by: default avatarzhiqiangxu <[email protected]>
      Co-authored-by: default avatarNazar Mokrynskyi <[email protected]>
      Co-authored-by: default avatarAnwesh <[email protected]>
      Co-authored-by: default avatarcheme <[email protected]>
      Co-authored-by: default avatarSam Johnson <[email protected]>
      Co-authored-by: default avatarkianenigma <[email protected]>
      Co-authored-by: default avatarJegor Sidorenko <[email protected]>
      Co-authored-by: default avatarMuharem <[email protected]>
      Co-authored-by: default avatarjoepetrowski <[email protected]>
      Co-authored-by: default avatarAlexandru Gheorghe <[email protected]>
      Co-authored-by: default avatarGabriel Facco de Arruda <[email protected]>
      Co-authored-by: default avatarSquirrel <[email protected]>
      Co-authored-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatargeorgepisaltu <[email protected]>
      Co-authored-by: command-bot <>
      fd5f9292
  2. Feb 20, 2024
    • Oliver Tale-Yazdi's avatar
      Lift dependencies to the workspace (Part 2/x) (#3366) · e89d0fca
      Oliver Tale-Yazdi authored
      
      
      Lifting some more dependencies to the workspace. Just using the
      most-often updated ones for now.
      It can be reproduced locally.
      
      ```sh
      # First you can check if there would be semver incompatible bumps (looks good in this case):
      $ zepter transpose dependency lift-to-workspace --ignore-errors syn quote thiserror "regex:^serde.*"
      
      # Then apply the changes:
      $ zepter transpose dependency lift-to-workspace --version-resolver=highest syn quote thiserror "regex:^serde.*" --fix
      
      # And format the changes:
      $ taplo format --config .config/taplo.toml
      ```
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      e89d0fca
  3. Feb 12, 2024
  4. Feb 06, 2024
  5. Feb 02, 2024
  6. Jan 26, 2024
  7. Jan 19, 2024
  8. Dec 21, 2023
  9. Dec 20, 2023
  10. Dec 18, 2023
  11. Dec 14, 2023
    • Svyatoslav Nikolsky's avatar
      Add Rococo People <> Rococo Bulletin bridge support to Rococo Bridge Hub (#2540) · 097308e3
      Svyatoslav Nikolsky authored
      This PR adds [Rococo
      People](https://github.com/paritytech/polkadot-sdk/pull/2281) <> [Rococo
      Bulletin](https://github.com/zdave-parity/polkadot-bulletin-chain) to
      the Rococo Bridge Hub code. There's a couple of things left to do here:
      - [x] add remaining tests - it'd need some refactoring in the
      `bridge-hub-test-utils` - will do in a separate PR;
      - [x] actually run benchmarks for new messaging pallet (do we have bot
      nowadays?).
      
      The reason why I'm opening it before this ^^^ is ready, is that I'd like
      to hear others opinion on how to deal with hacks with that bridge.
      Initially I was assuming that Rococo Bulletin will be the 1:1 copy of
      the Polkadot Bulletin (to avoid maintaining multiple
      runtimes/releases/...), so you can see many `PolkadotBulletin` mentions
      in this PR, even though we are going to bridge with the parallel chain
      (`RococoBulletin`). That's because e.g. pallet names from
      `construct_runtime` are affecting runtime storage keys and bridges are
      using runtime storage proofs => it is important to use names that the
      Bulletin chain expects.
      
      But in the end, this hack won't work - we can't use Polkadot Bulletin
      runtime to bridge with Rococo Bridge Hub, because Polkadot Bulletin
      expects Polkadot Bridge hub to use `1002` parachain id and Rococo Bridge
      Hub seats on the `1013`. This also affects storage keys using in
      bridging, so I had to add the [`rococo`
      feature](https://github.com/svyatonik/polkadot-bulletin-chain/blob/add-bridge-pallets/runtime/Cargo.toml#L198)
      to the Bulletin chain. So now we can actually alter its runtime and
      adapt it for Rococo.
      
      So the question here is - what's better for us here
      - to leave everything as is (seems hacky and non-trivial);
      - change Bulletin chain runtime when `rococo` feature is used - e.g. use
      proper names there (`WithPolkadotGrandpa` -> `WithRococoGrandpa`, ...)
      - add another set of pallets to the Bulletin chain runtime to bridge
      with Rococo and never use them in production. Similar to hack that we
      had in Rococo/Wococo
      
      cc @acatangiu @bkontur @serban300 
      
      also cc @joepetrowski
      
       as the main "client" of this bridge
      
      ---
      
      A couple words on how this bridge is different from the Rococo <>
      Westend bridge:
      - it is a bridge with a chain that uses GRANDPA finality, not the
      parachain finality (hence the tests needs to be changed);
      - it is a fee-free bridge. So
      `AllowExplicitUnpaidExecutionFrom<Equals<SiblingPeople>>` + we are not
      paying any rewards to relayers (apart from compensating transaction
      costs).
      
      ---------
      
      Signed-off-by: default avatardependabot[bot] <[email protected]>
      Signed-off-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarAdrian Catangiu <[email protected]>
      Co-authored-by: default avatardependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
      Co-authored-by: default avatarAndrei Sandu <[email protected]>
      Co-authored-by: default avatarEgor_P <[email protected]>
      Co-authored-by: command-bot <>
      097308e3
  12. Dec 13, 2023
  13. Dec 06, 2023
  14. Dec 05, 2023
  15. Dec 01, 2023
  16. Nov 15, 2023
  17. Nov 03, 2023
    • Svyatoslav Nikolsky's avatar
      [testnet] Allow governance to control fees for Rococo <> Westend bridge (#2139) · 0d3c67d9
      Svyatoslav Nikolsky authored
      Right now governance could only control byte-fee component of Rococo <>
      Westend message fees (paid at Asset Hubs). This PR changes it a bit:
      1) governance now allowed to control both fee components - byte fee and
      base fee;
      2) base fee now includes cost of "default" delivery and confirmation
      transactions, in addition to `ExportMessage` instruction cost.
      0d3c67d9
  18. Nov 01, 2023
  19. Oct 24, 2023
    • Oliver Tale-Yazdi's avatar
      Improve features dev-ex (#1831) · 4a443567
      Oliver Tale-Yazdi authored
      Adds a config file that allows to run `zepter` without any arguments in
      the workspace to address all issues.
      A secondary workflow for the CI is provided as `zepter run check`. Both
      the formatting and linting are now in one check for efficiancy.
      
      The latest version also detects some more things that `featalign` was
      already showing.
      
      Error message [in the
      CI](https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3916205)
      now looks like this:
      ```pre
      ...
      crate 'test-parachains' (/Users/vados/Documents/work/polkadot-sdk/polkadot/parachain/test-parachains/Cargo.toml)
        feature 'std'
          must propagate to:
            parity-scale-codec
      Found 55 issues (run with --fix to fix).
      Error: Command 'lint propagate-feature' failed with exit code 1
      
      Polkadot-SDK uses the Zepter CLI to detect abnormalities in the feature configuration.
      It looks like one more more checks failed; please check the console output. You can try to automatically address them by running `zepter`.
      Otherwise please ask directly in the Merge Request, GitHub Discussions or on Matrix Chat, thank you.
      
      For more information, see:
        - https://github.com/paritytech/polkadot-sdk/issues/1831
        - https://github.com/ggwpez/zepter
      
      
      ```
      
      TODO:
      - [x] Check that CI fails correctly
      
      ---------
      
      Signed-off-by: default avatarOliver Tale-Yazdi <[email protected]>
      4a443567
  20. Oct 23, 2023
    • Branislav Kontur's avatar
      [testnet] BridgeHubRococo nits (#1972) · e0620fd9
      Branislav Kontur authored
      This PR does not introduce any functional changes to the existing code,
      it merely addresses several minor refactors:
      - Moving bridging pallets to separate files.
      - Improving the readability and naming of weight files for bridging
      pallets and bridging pallet instances.
      
      The reason for this refactor is to facilitate easier plugin integration
      for the upcoming bridge between Rococo and Westend.
      
      ---------
      
      Co-authored-by: command-bot <>
      e0620fd9
  21. Oct 20, 2023
    • Bastian Köcher's avatar
      `xcm`: Change `TypeInfo::path` to not include `staging` (#1948) · f3bf5c1a
      Bastian Köcher authored
      The `xcm` crate was renamed to `staging-xcm` to be able to publish it to
      crates.io as someone as squatted `xcm`. The problem with this rename is
      that the `TypeInfo` includes the crate name which ultimately lands in
      the metadata. The metadata is consumed by downstream users like
      `polkadot-js` or people building on top of `polkadot-js`. These people
      are using the entire `path` to find the type in the type registry. Thus,
      their code would break as the type path would now be [`staging_xcm`,
      `VersionedXcm`] instead of [`xcm`, `VersionedXcm`]. This pull request
      fixes this by renaming the path segment `staging_xcm` to `xcm`.
      
      This requires: https://github.com/paritytech/scale-info/pull/197
      
      
      
      ---------
      
      Co-authored-by: default avatarFrancisco Aguirre <[email protected]>
      f3bf5c1a
  22. Oct 19, 2023
  23. Oct 18, 2023
  24. Oct 17, 2023
  25. Oct 03, 2023
  26. Sep 27, 2023
  27. Sep 15, 2023
  28. Sep 13, 2023
  29. Sep 11, 2023
    • Lulu's avatar
      Set bridge crates to no-publish (#1488) · 00259b1c
      Lulu authored
      00259b1c
    • Serban Iorga's avatar
      Update bridges subtree (#1392) · 142a11ad
      Serban Iorga authored
      * Move the bridges subtree under root
      
      * Squashed 'bridges/' changes from 277f0d5496..e50398d1c5
      
      e50398d1c5 bridges subtree fixes (#2528)
      99af07522d Markdown linter (#1309) (#2526)
      733ff0fe7a `polkadot-staging` branch: Use polkadot-sdk dependencies (#2524)
      e8a59f141e Fix benchmark with new XCM::V3 `MAX_INSTRUCTIONS_TO_DECODE` (#2514)
      62b185de15 Backport `polkadot-sdk` changes to `polkadot-staging` (#2518)
      d9658f4d5b Fix equivocation detection containers startup (#2516) (#2517)
      d65db28a8f Backport: building images from locally built binaries (#2513)
      5fdbaf45f6 Start the equivocation detection loop from the complex relayer (#2507) (#2512)
      7fbb67de46 Backport: Implement basic equivocations detection loop (#2375)
      cb7efe245c Manually update deps in polkadot staging (#2371)
      d17981fc33 #2351 to polkadot-staging (#2359)
      
      git-subtree-dir: bridges
      git-subtree-split: e50398d1c594e4e96df70b0bd376e565d17e8558
      
      * Reapply diener workspacify
      
      * Fix Cargo.toml
      
      * Fix test
      
      * Adjustments
      142a11ad