Register a given remote proxy proof in the current [dispatch_context].

The registered remote proof can then be used later in the same context to execute a remote proxy call. This is for example useful when having a multisig operation. The multisig call can use [Self::remote_proxy_with_registered_proof] to get an approval by the members of the multisig. The final execution of the multisig call should be at least a batch of register_remote_proxy_proof and the multisig call that uses remote_proxy_with_registered_proof. This way the final approver can use a recent proof to prove the existence of the remote proxy. Otherwise it would require the multisig members to approve the call in [Config::MaxStorageRootsToKeep] amount of time.

It is supported to register multiple proofs, but the proofs need to be consumed in the reverse order as they were registered. Basically this means last in, first out.

The [dispatch_context] spans the entire lifetime of a transaction and every call in the transaction gets access to the same context.

Example

batch([
register_remote_proxy_proof,
as_multisig(remote_proxy_with_registered_proof(transfer))
])
Copy

As proofs can not be verified indefinitely (the time the storage roots are stored is limited) this function provides the possibility to provide a "fresh proof" at time of dispatch. As in the example above, this could be useful for multisig operation that depend on multiple members to approve a certain action, which can take multiple days.