Closed sekisamu closed 1 month ago
Would you be interested on working on this? Generally it should not be that complicated, we mainly need some runtime api and implement it:
decl_runtime_apis! {
trait DryRunCall<Call, Origin, Event> {
fn dry_run_call(call: Call, origin: Origin) -> (DispatchResultWithInfo, Vec<Event>);
}
}
impl_runtime_apis! {
impl DryRunCall<RuntimeCall, PalletsOriginOf<Runtime>, RuntimeEvent> for Runtime {
fn dry_run_call(call: RuntimeCall, origin: PalletsOriginOf<Runtime>) -> (DispatchResultWithInfo, Vec<RuntimeEvent>) {
let res = call.dispatch(origin);
(res, System::read_events_no_consensus().collect())
}
}
}
This is already covered by https://github.com/paritytech/polkadot-sdk/pull/3872 (ignore the xcm bits, you can dry run any extrinsic)
Right?
No is it not. This is also only supports to execute either an extrinsic
or a XCM
. I mean yes, you could send a XCM
that is only a Transact
, but that only sounds shitty :P
You mean the issue is you have to pass an extrinsic, not a call, right? Should we just change that to take a call instead of an extrinsic? If it's more useful I don't see a reason why we shouldn't do it. Do we gain anything from it being an extrinsic instead of a call?
You mean the issue is you have to pass an extrinsic, not a call, right?
Yes.
Should we just change that to take a call instead of an extrinsic?
Change what? The XCM dry run?
Yeah change the XCM dry run to just take in a call.
We should change the DrynRunApi
. This is not really a XCM specific API.
We can change both if it's more useful to take in a call. I think we'd like to have the same API so it's easier for UIs to use one or the other.
Yeah changing both sounds about right or maybe having one for call and one extrinsic.
You mean the issue is you have to pass an extrinsic, not a call, right? Should we just change that to take a call instead of an extrinsic? If it's more useful I don't see a reason why we shouldn't do it. Do we gain anything from it being an extrinsic instead of a call?
you should check which (call vs extrinsic) is easily integrated in PJS and PAPI
the majority of usage will go through one of those two
The DryRunApi
on XCM now takes a call instead of an extrinsic, checked with PAPI and now there's no need to double-sign or use SignedExtra 😁
This is done, available in the SDK, and also integrated in system chains.
As an application developer, it's essential to have simulation execution functionalities like
eth_call
that don't require accompanying signatures. This helps apps better protect user security and save on gas fees.However, the
system_dryRun
provided by Substrate requires signatures andSignedExtra
information, which can be disastrous for some apps, especially multi-signature apps.I initially came across this issue which proposed a great idea: executing without signatures and being able to return events generated during simulation execution. However, it's unclear why this hasn't been implemented.
Do you have any plans to provide a dryRun API method that doesn't require signatures or
SignedExtra
. It would be even better if it could return events.