[Feature Request] Add Event to Show DMP XCMHash After Enqueued/Attempted

[mkchungs]

Background

Matching XCM transfers in XCMv2 has not been easy due to the lack of XCMHash in events for DMP and UMP cases.

To compensate for this, multi-chain indexer/dApp developers are required to call state_traceBlock on every chain, decode it, and look for state changes like Dmp:DownwardMessagesQueues.

At the same time, the state_traceBlock solution is no longer practical as many parachains now consider this call "unsafe" and have gradually locked away this RPC method.

Current Status (As of Runtime 9382)

XCMv3 (#697) partially solves this annoyance with the addition of the "parachainSystem:UpwardMessageSent" event (#1228)

• UMP transfers initiated via "PolkadotXcm" pallet (e.g., XCMv3 Statemine -> Kusama for 1KSM) can now be easily matched without any trace dependency.
• DMP transfers initiated via "XcmPallet" pallet continue to require trace (e.g., XCMv3 Kusama -> Statemine for 0.2KSM) as it only emits xcmPallet:Attempted and still missing the XCMHash associated with it.

Feature Request

To improve its usability and fully eliminate the trace dependency for dApp developers, I would like to see an event showing DMP XCMHash when it has been attempted or enqueued (e.g., xcmPallet:DownwardMessageEnqueued) right before the xcmPallet:Attempted. Can we see this getting implemented soon?

• Additional question:
  Should {xcmPallet:DownwardMessageEnqueued, xcmpQueue:XcmpMessageSent, parasystem:UpwardMessageSent} be augmented to include xcmContext besides xcmHash?

[bkontur]

Hey @mkchungs

Can we see this getting implemented soon?

I did some investigation around and I will try to fix this next week.

Should {xcmPallet:DownwardMessageEnqueued, xcmpQueue:XcmpMessageSent, parasystem:UpwardMessageSent} be augmented to include xcmContext besides xcmHash?

I guess no, at least for UpwardMessageSent / XcmpMessageSent, they are fired from impl SendXcm where there is no XcmContext (probably this would require bigger change, maybe in xcm-v4), and also ump/dmp/hrmp are transport layers (should be xcm agnostic)

[mkchungs]

@bkontur thanks for digging into this. I'm looking forward for your fix!

I guess no, at least for UpwardMessageSent / XcmpMessageSent, they are fired from impl SendXcm where there is no XcmContext (probably this would require bigger change, maybe in xcm-v4), and also ump/dmp/hrmp are transport layers (should be xcm agnostic)

Also thanks for providing more insights to my question.

Reason why I asked for XcmContext (specifically, the topic portion of it) is because XCMHash itself is NOT necessarily unique - take xcmHash 0x8bdf5ac5e0dffb8c99db1f28146021f6d20c6ff5cf4717164235defb477ee253 for example, same DMP xcmHash has been executed for 394 time:

We came up some fingerprinting technique to match the non-unique XCMHash. But again, it's not easy and has non-zero possibility of typeI & typeII errors, plus it requires state_traceBlock access.

So how can sender/dapps developer disambiguate these seemingly identical xcmMsgs when using xcmV3's xcmPallet:limitedReserveTransferAssets? I don't see setTopic as a possible input. If topic is not available, can extrinsic also emit uniquely identifiable events (maybe something like "destination_para_id + intermediate_mcqHead" or ...) before the xcmPallet:Attempted ?

[bkontur]

@mkchungs
thanks for more information, the same hash means the same message, I will also think about that

[bkontur]

@mkchungs
ok, I started paritytech/polkadot#7161 and #2504 as a first step, so lets see where it goes