paritytech / polkadot-sdk

The Parity Polkadot Blockchain SDK
https://polkadot.network/
1.74k stars 629 forks source link

Barrier should be able to deny certain XCMs from happening explicitly #837

Open gilescope opened 2 years ago

gilescope commented 2 years ago

We currently have a set of allow rules that will let certain messages through using the ShouldExecute tuple.

The suggestion is to have a guard that ensures that any matching message is denied:

pub struct DenyThenTry<Deny, Allow>(PhantomData<Deny>, PhantomData<Allow>)
where
    Deny: ShouldExecute,
    Allow: ShouldExecute;

impl<Deny, Allow> ShouldExecute for DenyThenTry<Deny, Allow>
where
    Deny: ShouldExecute,
    Allow: ShouldExecute,
{
    fn should_execute<Call>(
        origin: &MultiLocation,
        message: &mut Xcm<Call>,
        max_weight: Weight,
        weight_credit: &mut Weight,
    ) -> Result<(), ()> {
        Deny::should_execute(origin, message, max_weight, weight_credit)?;
        Allow::should_execute(origin, message, max_weight, weight_credit)
    }
}

At the moment DenyThenTry<(),(.....)> would always deny with the empty tuple because it returns Err() on nothing matched.

Keith mentioned that returning NoRulesMatched from RejectReason that https://github.com/paritytech/polkadot/pull/5035/ is introducing might help. It might be clearer if we had an opposite of the ShouldExecute trait.

gilescope commented 2 years ago

Supporting a mechanism of this ilk should mean that we can delete code introduced in cumulus PR: https://github.com/paritytech/cumulus/pull/1169