Delegated proving

[igamigo]

In the future, it would be desirable for proving to be delegated in order to enable weak clients to easily submit proofs for their transactions. The client could then look something like this:

pub struct Client<S: Store, P: TxProver, N: NodeRpc, A: Authenticator, R: Rng> {
    store: S,
    node_rpc: N,
    tx_executor: TransactionExecutor,
    tx_prover: P,
    authenticator: A,
    rng: R,
}

Where the trait TxProver provides a simple interface that defines how the proving is performed before being submitted and then returns a ProvenTransaction. All the other traits are already implemented (https://github.com/0xPolygonMiden/miden-client/issues/128)

[bobbinth]

Having these many type parameters is not ideal - so, I'm wondering if we can convert some (or all) of these into dynamic objects. For example, we could define the Client struct as follows:

pub struct Client {
    store: Arc<dyn Store>,
    rng: Arc<dyn FeltRng>,
    rpc_api: Arc<dyn NodeRpcClient>,
    tx_prover: Arc<dyn TransactionProver>,
    tx_executor: TransactionExecutor,
}

This will also require refactoring of TransactionExecutor in miden-base to use objects as well. Maybe something like:

pub struct TransactionExecutor {
    data_store: Arc<dyn DataStore>,
    mast_store: Arc<TransactionMastStore>,
    authenticator: Option<Arc<dyn TransactionAuthenticator>>,
    exec_options: ExecutionOptions,
}

The biggest complication with the above is that traits with native async are not object-safe (and so cannot be used as dyn Trait). We could switch from native async to async-trait-based async - but I'm not sure how well will it work with our maybe_async macros.

[SantiagoPittella]

I'm making a couple tests and trying out stuff. Seems like to make this work, the prove method no longer can receive impl Into<TransactionWitness> and should receive TransactionWitness instead.

[bobbinth]

Seems like to make this work, the prove method no longer can receive impl Into<TransactionWitness> and should receive TransactionWitness instead.

That should be fine (i.e., we can change the interface to take TransactionWitness struct). My bigger concern is how it will work with maybe_async macro.