dry run transactions prior to execution

[Moliholy]

This PR adds dry run check prior to extrinsic submission and prints an alert if the extrinsic would fail in its execution. Useful to warn the user before needlessly spending network fees.

Screenshots:

[Moliholy]

@TarikGul any feedback for the PR? do you think it's a good idea?

[TarikGul]

I would ensure we also bring up that it failed via the dry run.

So something like: The transaction did not successfully pass a dry run, something something

[Moliholy]

I just changed it to The transaction did not pass a dry run and would likely not be successfully executed. Is that OK?

[TarikGul]

Apologies on the delay, I haven't gotten around to truly running this yet. I do think it is a good idea though, i just need to test it locally as well!

[Moliholy]

No worries! I just updated the text and rebased to the latest master branch.

[TarikGul]

I haven't forgotten about this PR :), I'll have a response soon but there was some internal discussion on our team on some potential problems that this can introduce.

It's definitely a wanted feature so I would love to see this get in, but we just need to ensure the edge cases are resolved (to be written out soon)

[Moliholy]

Thanks for the update. This is actually a small part of a bigger task that I had in mind. In a real-world production scenario a user would not have the private key accessible in the browser and instead would likely be using wallets like Talisman. In such case the account will very likely be locked and hence the feature implemented here would be useless, as it would not prevent real funds from being spent.

For that case I thought to implement a Dry run button near the Sign and submit one that would require the user to unlock the account and execute the dry run operation on demand. But before that I wanted to see how was the reception of this PR, as I supposed it could bring some friction.

[IkerAlus]

Important to note that this feature implies calling an unsafe RPC method and most likely won't be available in any public provider.

[Moliholy]

Which is, since we're on it, a huge disadvantage IMO comparing to Ethereum. See here:

Executes a message call transaction, which is directly executed in the VM of the node, but never mined into the blockchain.

If you can query the chain state like in Ethereum while spending computational resources, why can't you dry-run a transaction also spending computational resources?

Actually, I hoped implementing this feature (and others that might be coming) could make some pressure to the community so that by default there exists a way for any client to perform dry-runs of their transactions.

Anyhow... the hasDryRun boolean value is supposed to indicate whether this method is allowed or not. Also please take into account that in most (all?) cases it will work if using zombienet.

[IkerAlus]

@Moliholy Good points, it may be worth it to revive this old issue in Polkadot-SDK.

[xlc]

Note that the dry run RPC isn't that useful. See this for more details paritytech/polkadot-sdk#341
Once we have the new dry run runtime API, we should use it instead paritytech/polkadot-sdk#4432
Otherwise should use Chopsticks to dry run locally. However it can take up to a few minutes so can't be enabled by default.