Discussion on XCM v2->v3 support

1

Hey all,

Wanted to discuss a little bit on how the support between XCM V2 and V3 will work from now on. Currently the conversion between V2->V3 instructions inject a DEFAULT_PROOF_SIZE for those intsructions dealing with weight-related parameters. A few examples are:

  • BuyExecution: V2 BuyExecution has no notion of PoV size, and therefore only buys ref_time. The V2->V3 conversion makes sure that BuyExecution buys DEFAULT_PROOF_SIZE, which is currently 64KB.

  • Transact: The Transact instructions has a field called required_weight_at_most, which serves to cap how much weight one wants to spend on the Transaction itself. V2 Transact has no notion of PoV size, and therefore only caps ref_time. The V2->V3 conversion makes sure that Transact sets DEFAULT_PROOF_SIZE besides the ref_time capping, which again, is currently 64KB.

These are just a few instructions that deal with weight-related parameters and how they handle V2->V3 conversions. One clear problem I see with this conversion is the way usually XCM weighers weight messages. The majority of the runtimes have a barrier that makes sure that BuyExecution buys sufficient weight for the execution of the message, both in terms of ref_time and pov. Usually these weighers use benchmarked values, and in a few exceptions like Transact, they add whatever it is set in required_weight_at_most.

Right now the relay runtimes (and AFAIK, no other chain) do not account for PoV sizes in the rest of the instructions. Which means that if the any of these runtimes receives a V2 set of instructions of the form:

WithdrawAsset || BUyExecution || Transact

The total weighted PoV of the message is that dictated by the Transact instruction, which is the default 64KB. Since BuyExecution also buys 64KB by default, everything works and the barrier will pass.

Obviously this assumption is going to break as soon as WithdrawAsset and the rest of the instructions start accounting for PoV. Is there any plan for this besides expecting every chain to upgrade to V3 ASAP? One potential solution (we might do this in Moonbeam) is to make BuyExecution buy more than those 64KB by default on the V2->V3 conversion, but I was wondering if there are other ideas in the table

1 Like
2

Yeah we really need a solution. Our XCM integration tests failed when we upgraded to v0.9.40 exactly due to this. Improve XCM debuggability · Issue #7195 · paritytech/polkadot · GitHub

It is very unclear on what version works with what version. And on top of that, no one have any idea on when the new versions will be out. This is a bit too much chaos.

We really need more collaborated release planning and communication and integration tests.

1 Like