-
Notifications
You must be signed in to change notification settings - Fork 732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transactional processing for XCM #1222
Conversation
reduce_ticket.enact()?; | ||
Config::XcmSender::deliver(ticket)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pretty sure these two are guaranteed to succeed as long as the tickets were created recently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks broadly ok except for the comment.
No problem with rolling back if BuyExecution
fails. An attacker can do nothing worse than at present. As long as barriers and trapping filters are secure then it'll bail on the Err
without the possibility of doing any work other than the asset withdrawal and failed buy (which we cannot avoid in the general case).
polkadot/xcm/xcm-executor/src/lib.rs
Outdated
for asset in assets.assets_iter() { | ||
Config::AssetTransactor::check_out(&dest, &asset, &self.context); | ||
} | ||
// Note that we pass `None` as `maybe_failed_bin` and drop any assets which | ||
// cannot be reanchored because we have already checked all assets out. | ||
let assets = Self::reanchored(assets, &dest, None); | ||
let mut message = vec![ReceiveTeleportedAsset(assets), ClearOrigin]; | ||
message.extend(xcm.0.into_iter()); | ||
self.send(dest, Xcm(message), FeeReason::InitiateTeleport)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once all the can_check_out
calls pass, then the only thing which can fail is send
. Therefore if that is done prior to the check_out
calls, then this can avoid the need for transactionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do want to keep the rollback of the holding register, correct?
I think with careful review there's still an opportunity to remove a bit of transactionality. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Little syntax nits, but should be good to go after addressing Gav's comments.
The CI pipeline was cancelled due to failure one of the required jobs. |
_ => TransactionOutcome::Rollback(Ok(output)), | ||
} | ||
}) | ||
.map_err(|_| XcmError::ExceedsStackLimit)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we got shoot by .map_err(|_|
too many times so please add a comment to explain why it is acceptable to ignore the error here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only place that can throw an error is within the processing of with_transaction
, NOT the closure that is being passed in as a parameter -- if you look closely above, there's no possible way that the closure can return an Err
.
Moved from: paritytech/polkadot#6951 closes #490 - [x] update cumulus --- This PR introduces transactional processing of certain xcm instructions. For the list of instructions checkout #490. The transactional processing is implemented as an xcm-executor config item. The two implementations in this PR are `FrameTransactionalProcessor` and `()`. The `()` implementation does no transactional processing. Each implementation of the `ProcessTransaction` trait has an `IS_TRANSACTIONAL` const that tells the XCVM if transactional processing is actually implemented. If Transactional processing is implemented, changes to touched registers should also be rolled back to prevent inconsistencies. Note for reviewers: Check out the following safety assumption: https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30 --------- Co-authored-by: Keith Yeung <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: command-bot <>
Moved from: paritytech/polkadot#6951 closes #490 - [x] update cumulus --- This PR introduces transactional processing of certain xcm instructions. For the list of instructions checkout #490. The transactional processing is implemented as an xcm-executor config item. The two implementations in this PR are `FrameTransactionalProcessor` and `()`. The `()` implementation does no transactional processing. Each implementation of the `ProcessTransaction` trait has an `IS_TRANSACTIONAL` const that tells the XCVM if transactional processing is actually implemented. If Transactional processing is implemented, changes to touched registers should also be rolled back to prevent inconsistencies. Note for reviewers: Check out the following safety assumption: https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30 --------- Co-authored-by: Keith Yeung <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: command-bot <>
Moved from: paritytech/polkadot#6951 closes #490 - [x] update cumulus --- This PR introduces transactional processing of certain xcm instructions. For the list of instructions checkout #490. The transactional processing is implemented as an xcm-executor config item. The two implementations in this PR are `FrameTransactionalProcessor` and `()`. The `()` implementation does no transactional processing. Each implementation of the `ProcessTransaction` trait has an `IS_TRANSACTIONAL` const that tells the XCVM if transactional processing is actually implemented. If Transactional processing is implemented, changes to touched registers should also be rolled back to prevent inconsistencies. Note for reviewers: Check out the following safety assumption: https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30 --------- Co-authored-by: Keith Yeung <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: command-bot <>
Moved from: paritytech/polkadot#6951 closes paritytech#490 - [x] update cumulus --- This PR introduces transactional processing of certain xcm instructions. For the list of instructions checkout paritytech#490. The transactional processing is implemented as an xcm-executor config item. The two implementations in this PR are `FrameTransactionalProcessor` and `()`. The `()` implementation does no transactional processing. Each implementation of the `ProcessTransaction` trait has an `IS_TRANSACTIONAL` const that tells the XCVM if transactional processing is actually implemented. If Transactional processing is implemented, changes to touched registers should also be rolled back to prevent inconsistencies. Note for reviewers: Check out the following safety assumption: https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30 --------- Co-authored-by: Keith Yeung <[email protected]> Co-authored-by: Francisco Aguirre <[email protected]> Co-authored-by: command-bot <>
* Setup deps * Remove Koi from account migration test * paritytech/polkadot-sdk#1495 * Bump * paritytech/polkadot-sdk#1524 * !! paritytech/polkadot-sdk#1363 * paritytech/polkadot-sdk#1492 * paritytech/polkadot-sdk#1911 * paritytech/polkadot-sdk#1900 Signed-off-by: Xavier Lau <[email protected]> * paritytech/polkadot-sdk#1661 * paritytech/polkadot-sdk#2144 * paritytech/polkadot-sdk#2048 * paritytech/polkadot-sdk#1672 * paritytech/polkadot-sdk#2303 * paritytech/polkadot-sdk#1256 * Remove identity and vesting * Fixes * paritytech/polkadot-sdk#2657 * paritytech/polkadot-sdk#1313 * paritytech/polkadot-sdk#2331 * paritytech/polkadot-sdk#2409 part.1 * paritytech/polkadot-sdk#2767 * paritytech/polkadot-sdk#2521 Signed-off-by: Xavier Lau <[email protected]> * paritytech/polkadot-sdk#1222 * paritytech/polkadot-sdk#1234 part.1 * Satisfy compiler * XCM V4 part.1 * paritytech/polkadot-sdk#1246 * Remove pallet-democracy part.1 * paritytech/polkadot-sdk#2142 * paritytech/polkadot-sdk#2428 * paritytech/polkadot-sdk#3228 * XCM V4 part.2 * Bump * Build all runtimes * Build node * Remove pallet-democracy Signed-off-by: Xavier Lau <[email protected]> * Format * Fix pallet tests * Fix precompile tests * Format * Fixes * Async, remove council, common pallet config * Fix `ethtx-forward` test case (#1519) * Fix ethtx-forward tests * Format * Fix following the review * Fixes * Fixes * Use default impl * Benchmark helper * Bench part.1 * Bench part.2 * Bench part.3 * Fix all tests * Typo * Feat * Fix EVM tracing build * Reuse upstream `proof_size_base_cost()` (#1521) * Format issue * Fixes * Fix CI --------- Signed-off-by: Xavier Lau <[email protected]> Co-authored-by: Bear Wang <[email protected]>
Moved from: paritytech/polkadot#6951
closes #490
This PR introduces transactional processing of certain xcm instructions. For the list of instructions checkout #490. The transactional processing is implemented as an xcm-executor config item. The two implementations in this PR are
FrameTransactionalProcessor
and()
. The()
implementation does no transactional processing. Each implementation of theProcessTransaction
trait has anIS_TRANSACTIONAL
const that tells the XCVM if transactional processing is actually implemented. If Transactional processing is implemented, changes to touched registers should also be rolled back to prevent inconsistencies.Note for reviewers:
Check out the following safety assumption: https://github.com/paritytech/polkadot-sdk/pull/1222/files#diff-4effad7d8c1c9de19fd27e18661cbf2128c8718f3b2420a27d2f816e0749ea53R30