search

paritytech / polkadot-sdk

The Parity Polkadot Blockchain SDK
https://polkadot.network/
1.84k stars 668 forks source link

XCM Runtime API fee estimation UX improvement #6126

Open mrshiposha opened 2 hours ago

mrshiposha commented 2 hours ago

We (Unique Network's team) have been building a JS package to estimate XCM fees. Although it kind of works, the estimation process is very inconvinient. Moreover, we can only accurately estimate the execution fees. To estimate the delivery fees, we'd need to analyze each program and find the instructions that forward new programs. This requires constant maintenance of the library since, with new XCM versions, there could be new such instructions (e.g., InitiateAssetsTransfer in XCM v5). It would be good to have a future-proof universal solution backed by a generic Runtime API. Also, new kinds of fees can be introduced in the future, which could require special handling similar to delivery fees (see this discussion).

The current implementation of dry-running doesn't help here since if there are not enough fees inside the dry-running extrinsic/xcm-program, it will just fail without telling us how much fee asset we'd need. The current design of calling XcmPaymentApi first and then DryRunApi has proven inconvenient.

Suggestion

Make the XCM executor participate in the dry-running process directly instead of relying on the different parts of its configuration, such as its Routers.

The XCM executor could record all the taken fees directly (inside the take_fee function). It should not fail if there are not enough fees during the dry-running; it should just set a flag about that and report an error at the very end of the program execution.

There is an issue with the Trader, though. It just returns an error if something goes wrong inside the buy_weight. It doesn't tell us the fee amount required. Also, there could be an error if a user provided a wrong fee asset, which can't be used to cover the execution fees.

If we make the XCM executor do this, we don't need to reimplement the fee calculation logic separately in the Runtime API. Instead, the DryRunApi should be able to read this info from the XCM executor after a program dry-running.

Also, the XCM executor should record the forwarded programs directly (inside the send function). This will eliminate the #5878 instantly.

DryRunApi should then collect all the info it currently provides and also report all the required fees that the XCM executor tried to collect. This way, we don't need to think about different kinds of fees. It's the XCM executor's business. Users want to ensure they pay enough for everything to get their XCM program through all the chains.

In the end, the DryRunApi would just take the needed info from the XCM executor. This means the DryRunApi would need exactly one implementation, and any chain team that already configured the XCM executor could just plug the DryRunApi in their Runtime.

If implemented, we can remove most of the XcmPaymentApi methods. We'd need to preserve the queryAcceptablePaymentAssets method only.

mrshiposha commented 2 hours ago

I could implement a PoC. However, due to other current tasks, I won't be able to anytime soon (beginning of 2025, it seems).

Please tag me if someone finds the suggestion sound and wants to implement a PoC themselves. I'd like to look at it.

CC @franciscoaguirre