XCM: Transactional Processing #490
Labels
Comments
|
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/how-to-handle-not-withdrawable-assets-properly-with-xcm/2270/4 |
the-right-joyce
added
I5-enhancement
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 24, 2024
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 <>
franciscoaguirre
added a commit
to paritytech/xcm
that referenced
this issue
Jan 25, 2024
Moved from: paritytech/polkadot#6951 closes paritytech/polkadot-sdk#490 - [x] update cumulus --- This PR introduces transactional processing of certain xcm instructions. For the list of instructions checkout paritytech/polkadot-sdk#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 <>
ggwpez
pushed a commit
that referenced
this issue
Jan 29, 2024
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 <>
franciscoaguirre
added a commit
that referenced
this issue
Feb 1, 2024
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 <>
franciscoaguirre
added a commit
that referenced
this issue
Feb 5, 2024
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 <>
bgallois
pushed a commit
to duniter/duniter-polkadot-sdk
that referenced
this issue
Mar 25, 2024
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 <>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For XCM instructions which are unable to avoid any state changes on an error, use a storage transaction to ensure that changes are rolled back in the case of an error after changes have been made. Instructions which need this are:
WithdrawAssetReserveAssetDepositedTransferAssetTransferReserveAssetReceiveTeleportedAssetDepositAssetDepositReserveAssetInitiateReserveWithdrawInitiateTeleportBuyExecutionClaimAssetExportMessageLockAssetUnlockAssetRequestUnlockEach should have their implementations in
XcmExecutor::process_instructionbe wrapped in a storage transaction which reverts any changes in case anErrvalue is returned.The text was updated successfully, but these errors were encountered: