Enhance the runtime API dry_run to eliminate the need for signatures and SignedExtra

[sekisamu]

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 and SignedExtra 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.

[bkchr]

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())
         }
    }
}

[acatangiu]

This is already covered by #3872 (ignore the xcm bits, you can dry run any extrinsic)

Right?

[bkchr]

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

[franciscoaguirre]

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?

[bkchr]

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?

[franciscoaguirre]

Yeah change the XCM dry run to just take in a call.

[bkchr]

We should change the DrynRunApi. This is not really a XCM specific API.

[franciscoaguirre]

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.

[bkchr]

Yeah changing both sounds about right or maybe having one for call and one extrinsic.

[acatangiu]

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

[franciscoaguirre]

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 😁

[acatangiu]

This is done, available in the SDK, and also integrated in system chains.