Skip to content
Snippets Groups Projects
  1. Aug 09, 2024
  2. Aug 08, 2024
  3. Aug 07, 2024
  4. Aug 06, 2024
  5. Aug 05, 2024
    • Przemek Rzad's avatar
      Remove unused feature gated code from the minimal template (#5237) · 035211d7
      Przemek Rzad authored
      - Progresses https://github.com/paritytech/polkadot-sdk/issues/5226
      
      There is no actual `try-runtime` or `runtime-benchmarks` functionality
      in the minimal template at the moment.
    • Alexandru Gheorghe's avatar
      make polkadot-parachain startup errors pretty (#5214) · 0cc3e170
      Alexandru Gheorghe authored
      
      The errors on polkadot-parachain are not printed with their full display
      context(what is marked with `#[error(`) because main returns plain
      Result and the error will be shown in its Debug format, that's not
      consistent with how the polkadot binary behave and is not user friendly
      since it does not tell them why they got the error.
      
      Fix it by using `color_eyre` as polkadot already does it. 
      
      Fixes: https://github.com/paritytech/polkadot-sdk/issues/5211
      
      ## Output before
      ```
      Error: NetworkKeyNotFound("/acala/data/Collator2/chains/mandala-tc9/network/secret_ed25519")
      ```
      
      ## Output after
      ```
      Error: 
         0: Starting an authorithy without network key in /home/alexggh/.local/share/polkadot-parachain/chains/asset-hub-kusama/network/secret_ed25519.
            
             This is not a safe operation because other authorities in the network may depend on your node having a stable identity.
            
             Otherwise these other authorities may not being able to reach you.
            
             If it is the first time running your node you could use one of the following methods:
            
             1. [Preferred] Separately generate the key with: <NODE_BINARY> key generate-node-key --base-path <YOUR_BASE_PATH>
            
             2. [Preferred] Separately generate the key with: <NODE_BINARY> key generate-node-key --file <YOUR_PATH_TO_NODE_KEY>
            
             3. [Preferred] Separately generate the key with: <NODE_BINARY> key generate-node-key --default-base-path
            
             4. [Unsafe] Pass --unsafe-force-node-key-generation and make sure you remove it for subsequent node restarts
      
      ```
      
      ---------
      
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru.gheorghe@parity.io>
    • Sergej Sakac's avatar
      Coretime auto-renew (#4424) · f170af61
      Sergej Sakac authored
      
      This PR adds functionality that allows tasks to enable auto-renewal.
      Each task eligible for renewal can enable auto-renewal.
      
      A new storage value is added to track all the cores with auto-renewal
      enabled and the associated task running on the core. The `BoundedVec` is
      sorted by `CoreIndex` to make disabling auto-renewal more efficient.
      
      Cores are renewed at the start of a new bulk sale. If auto-renewal
      fails(e.g. due to the sovereign account of the task not holding
      sufficient balance), an event will be emitted, and the renewal will
      continue for the other cores.
      
      The two added extrinsics are:
      - `enable_auto_renew`: Extrinsic for enabling auto renewal.
      - `disable_auto_renew`: Extrinsic for disabling auto renewal.
      
      TODOs:
      - [x] Write benchmarks for the newly added extrinsics.
      
      Closes: #4351
      
      ---------
      
      Co-authored-by: default avatarDónal Murray <donalm@seadanda.dev>
    • Alexandru Vasile's avatar
      network/strategy: Backoff and ban overloaded peers to avoid submitting the... · 6619277b
      Alexandru Vasile authored
      network/strategy: Backoff and ban overloaded peers to avoid submitting the same request multiple times (#5029)
      
      This PR avoids submitting the same block or state request multiple times
      to the same slow peer.
      
      Previously, we submitted the same request to the same slow peer, which
      resulted in reputation bans on the slow peer side.
      Furthermore, the strategy selected the same slow peer multiple times to
      submit queries to, although a better candidate may exist.
      
      Instead, in this PR we:
      - introduce a `DisconnectedPeers` via LRU with 512 peer capacity to only
      track the state of disconnected peers with a request in flight
      - when the `DisconnectedPeers` detects a peer disconnected with a
      request in flight, the peer is backed off
        - on the first disconnection: 60 seconds
        - on second disconnection: 120 seconds
      - on the third disconnection the peer is banned, and the peer remains
      banned until the peerstore decays its reputation
        
      This PR lifts the pressure from overloaded nodes that cannot process
      requests in due time.
      And if a peer is detected to be slow after backoffs, the peer is banned.
      
      Theoretically, submitting the same request multiple times can still
      happen when:
      - (a) we backoff and ban the peer 
      - (b) the network does not discover other peers -- this may also be a
      test net
      - (c) the peer gets reconnected after the reputation decay and is still
      slow to respond
      
      
      
      Aims to improve:
      - https://github.com/paritytech/polkadot-sdk/issues/4924
      - https://github.com/paritytech/polkadot-sdk/issues/531
      
      Next Steps:
      - Investigate the network after this is deployed, possibly bumping the
      keep-alive timeout or seeing if there's something else misbehaving
      
      
      
      
      This PR builds on top of:
      - https://github.com/paritytech/polkadot-sdk/pull/4987
      
      
      ### Testing Done
      - Added a couple of unit tests where test harness were set in place
      
      - Local testnet
      
      ```bash
      13:13:25.102 DEBUG tokio-runtime-worker sync::persistent_peer_state: Added first time peer 12D3KooWHdiAxVd8uMQR1hGWXccidmfCwLqcMpGwR6QcTP6QRMuD
      
      13:14:39.102 DEBUG tokio-runtime-worker sync::persistent_peer_state: Remove known peer 12D3KooWHdiAxVd8uMQR1hGWXccidmfCwLqcMpGwR6QcTP6QRMuD state: DisconnectedPeerState { num_disconnects: 2, last_disconnect: Instant { tv_sec: 93355, tv_nsec: 942016062 } }, should ban: false
      
      13:16:49.107 DEBUG tokio-runtime-worker sync::persistent_peer_state: Remove known peer 12D3KooWHdiAxVd8uMQR1hGWXccidmfCwLqcMpGwR6QcTP6QRMuD state: DisconnectedPeerState { num_disconnects: 3, last_disconnect: Instant { tv_sec: 93485, tv_nsec: 947551051 } }, should ban: true
      
      13:16:49.108  WARN tokio-runtime-worker peerset: Report 12D3KooWHdiAxVd8uMQR1hGWXccidmfCwLqcMpGwR6QcTP6QRMuD: -2147483648 to -2147483648. Reason: Slow peer after backoffs. Banned, disconnecting.
      ```
      
      cc @paritytech/networking
      
      ---------
      
      Signed-off-by: default avatarAlexandru Vasile <alexandru.vasile@parity.io>
    • Kian Paimani's avatar
      Fix frame crate usage doc (#5222) · ad1e556e
      Kian Paimani authored
    • Sebastian Kunert's avatar
      beefy: Tolerate pruned state on runtime API call (#5197) · 2abd03ef
      Sebastian Kunert authored
      While working on #5129 I noticed that after warp sync, nodes would
      print:
      ```
      2024-07-29 17:59:23.898 ERROR ⋮beefy: 🥩 Error: ConsensusReset. Restarting voter.    
      ```
      
      After some debugging I found that we enter the following loop:
      1. Wait for beefy pallet to be available: Pallet is detected available
      directly after warp sync since we are at the tip.
      2. Wait for headers from tip to beefy genesis to be available: During
      this time we don't process finality notifications, since we later want
      to inspect all the headers for authority set changes.
      3. Gap sync finishes, route to beefy genesis is available.
      4. The worker starts acting, tries to fetch beefy genesis block. It
      fails, since we are acting on old finality notifications where the state
      is already pruned.
      5. Whole beefy subsystem is being restarted, loading the state from db
      again and iterating a lot of headers.
      
      This already happened before #5129.
  6. Aug 02, 2024
    • Alexandru Vasile's avatar
      rpc: Enable ChainSpec for polkadot-parachain (#5205) · ce6938ae
      Alexandru Vasile authored
      
      This PR enables the `chainSpec_v1` class for the polkadot-parachian. 
      The chainSpec is part of the rpc-v2 which is spec-ed at:
      https://github.com/paritytech/json-rpc-interface-spec/blob/main/src/api/chainSpec.md.
      
      This also paves the way for enabling a future `chainSpec_unstable_spec`
      on all nodes.
      
      Closes: https://github.com/paritytech/polkadot-sdk/issues/5191
      
      cc @paritytech/subxt-team
      
      ---------
      
      Signed-off-by: default avatarAlexandru Vasile <alexandru.vasile@parity.io>
    • Francisco Aguirre's avatar
      Add an adapter for configuring AssetExchanger (#5130) · 8ccb6b33
      Francisco Aguirre authored
      
      Added a new adapter to xcm-builder, the `SingleAssetExchangeAdapter`.
      This adapter makes it easy to use `pallet-asset-conversion` for
      configuring the `AssetExchanger` XCM config item.
      
      I also took the liberty of adding a new function to the `AssetExchange`
      trait, with the following signature:
      
      ```rust
      fn quote_exchange_price(give: &Assets, want: &Assets, maximal: bool) -> Option<Assets>;
      ```
      
      The signature is meant to be fairly symmetric to that of
      `exchange_asset`.
      The way they interact can be seen in the doc comment for it in the
      `AssetExchange` trait.
      
      This is a breaking change but is needed for
      https://github.com/paritytech/polkadot-sdk/pull/5131.
      Another idea is to create a new trait for this but that would require
      setting it in the XCM config which is also breaking.
      
      Old PR: https://github.com/paritytech/polkadot-sdk/pull/4375.
      
      ---------
      
      Co-authored-by: default avatarAdrian Catangiu <adrian@parity.io>
  7. Aug 01, 2024
  8. Jul 31, 2024
    • Alexandru Vasile's avatar
      litep2p/discovery: Publish authority records with external addresses only (#5176) · 7d0aa896
      Alexandru Vasile authored
      This PR reduces the occurrences for identified observed addresses.
      
      Litep2p discovers its external addresses by inspecting the
      `IdentifyInfo::ObservedAddress` field reported by other peers.
      After we get 5 confirmations of the same external observed address (the
      address the peer dialed to reach us), the address is reported through
      the network layer.
      
      The PR effectively changes this from 5 to 2.
      This has a subtle implication on freshly started nodes for the
      authority-discovery discussed below.
      
      The PR also makes the authority discovery a bit more robust by not
      publishing records if the node doesn't have addresses yet to report.
      This aims to fix a scenario where:
      - the litep2p node has started, it has some pending observed addresses
      but less than 5
      - the authorit-discovery publishes a record, but at this time the node
      doesn't have any addresses discovered and the record is published
      without addresses -> this means other nodes w...
    • thiolliere's avatar
      Run UI tests in CI for some other crates (#5167) · 39daa61e
      thiolliere authored
      
      The test name is `test-frame-ui` I don't know if I can also change it to
      `test-ui` without breaking other stuff. So I kept the name unchanged.
      
      ---------
      
      Co-authored-by: default avatarBastian Köcher <git@kchr.de>
  9. Jul 30, 2024
  10. Jul 29, 2024