Introduce transactional processing for xcm instructions #6951
Conversation
vstam1
added
A3-in_progress
jakoblell
added
the
D9-needsaudit 👮
Merge branch 'master' into vstam1/xcm-transactional-processing
|
bot rebase |
|
Rebased |
|
bot rebase |
|
Rebased |
|
bot rebase |
|
Rebased |
xcm/xcm-executor/src/lib.rs
Outdated
| @@ -314,6 +336,7 @@ impl<Config: config::Config> XcmExecutor<Config> { | |||
| for (i, instr) in xcm.0.into_iter().enumerate() { | |||
| match &mut result { | |||
| r @ Ok(()) => { | |||
| let vm_clone = self.clone(); | |||
There was a problem hiding this comment.
This is a bit dangerous and makes correct weighing rather difficult.
There was a problem hiding this comment.
Not that many instructions make sense to make transactional. In fact the need for transactional processing is limited to just a few. I would suggest we instead target transactionalism to those instructions and contain potentially costly state-cloning and transactional overhead to just the few instructions which actually need it.
For what it's worth, I already wrote this in the issue which this PR references but it seems to have been disregarded.
When rewriting this PR, do ensure there are no unnecessary self.clone()s. In particular cloning the Error Handler and Appendix is totally unnecessary since the only instructions which alter them are infallible after the point they get altered.
Also pay close attention to the whether a particular instruction's implementation actually needs transactionalism. It's entirely possible that some of the instructions detailed in the issue are infallible after the point any state changes are made. The only time we need transactive storage is when an instruction can fail after (possibly) making changes in storage.
|
The CI pipeline was cancelled due to failure one of the required jobs. |
|
@gavofyork I updated the PR to only update the necessary registers. I also checks the instructions for infallibility after state changes. |
closes paritytech/polkadot-sdk#490
Cumulus companion: paritytech/cumulus#2969