Skip to content

Commit

Permalink
introduce partial bp-xcm-bridge-hub - just LocalXcmChannelManager (#2265
Browse files Browse the repository at this point in the history
)
  • Loading branch information
svyatonik authored and bkontur committed Jun 5, 2024
1 parent cb4a826 commit a18a237
Show file tree
Hide file tree
Showing 3 changed files with 64 additions and 2 deletions.
1 change: 1 addition & 0 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

8 changes: 7 additions & 1 deletion bridges/primitives/xcm-bridge-hub/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,12 @@ workspace = true
# Substrate Dependencies
sp-std = { path = "../../../substrate/primitives/std", default-features = false }

# Polkadot Dependencies
xcm = { package = "staging-xcm", path = "../../../polkadot/xcm", default-features = false }

[features]
default = ["std"]
std = ["sp-std/std"]
std = [
"sp-std/std",
"xcm/std",
]
57 changes: 56 additions & 1 deletion bridges/primitives/xcm-bridge-hub/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,64 @@

//! Primitives of the xcm-bridge-hub pallet.

#![warn(missing_docs)]
#![cfg_attr(not(feature = "std"), no_std)]

use xcm::latest::prelude::*;

/// Encoded XCM blob. We expect the bridge messages pallet to use this blob type for both inbound
/// and outbound payloads.
pub type XcmAsPlainPayload = sp_std::vec::Vec<u8>;

/// A manager of XCM communication channels between the bridge hub and parent/sibling chains
/// that have opened bridges at this bridge hub.
///
/// We use this interface to suspend and resume channels programmatically to implement backpressure
/// mechanism for bridge queues.
#[allow(clippy::result_unit_err)] // XCM uses `Result<(), ()>` everywhere
pub trait LocalXcmChannelManager {
// TODO: https://github.com/paritytech/parity-bridges-common/issues/2255
// check following assumptions. They are important at least for following cases:
// 1) we now close the associated outbound lane when misbehavior is reported. If we'll keep
// handling inbound XCM messages after the `suspend_inbound_channel`, they will be dropped
// 2) the sender will be able to enqueue message to othe lanes if we won't stop handling inbound
// XCM immediately. He even may open additional bridges

/// Stop handling new incoming XCM messages from given bridge `owner` (parent/sibling chain).
///
/// We assume that the channel will be suspended immediately, but we don't mind if inbound
/// messages will keep piling up here for some time. Once this is communicated to the
/// `owner` chain (in any form), we expect it to stop sending messages to us and queue
/// messages at that `owner` chain instead.
///
/// This method will be called if we detect a misbehavior in one of bridges, owned by
/// the `owner`. We expect that:
///
/// - no more incoming XCM messages from the `owner` will be processed until further
/// `resume_inbound_channel` call;
///
/// - soon after the call, the channel will switch to the state when incoming messages are
/// piling up at the sending chain, not at the bridge hub.
///
/// This method shall not fail if the channel is already suspended.
fn suspend_inbound_channel(owner: Location) -> Result<(), ()>;

/// Start handling incoming messages from from given bridge `owner` (parent/sibling chain)
/// again.
///
/// This method is called when the `owner` tries to resume bridge operations after
/// resolving "misbehavior" issues. The channel is assumed to be suspended by the previous
/// `suspend_inbound_channel` call, however we don't check it anywhere.
///
/// This method shall not fail if the channel is already resumed.
fn resume_inbound_channel(owner: Location) -> Result<(), ()>;
}

impl LocalXcmChannelManager for () {
fn suspend_inbound_channel(_owner: Location) -> Result<(), ()> {
Ok(())
}

fn resume_inbound_channel(_owner: Location) -> Result<(), ()> {
Err(())
}
}

0 comments on commit a18a237

Please sign in to comment.