Thanks for this enjoyable exposition! I agree on the reasons for calling the whole shielding business exotic. Also I love when efforts are made to move it to milder climates.
On the crypto efficiency side of things: I’m optimistic that the onchain verification cost will go down eventually as optimizations are becoming possibile (e.g see zkVerify with its modular precompiles).
As for provers, I can only guess why client-side proving has not seen the tremendous improvements we all hoped for (except maybe for the recent Stwo from StarkWare?), but clearly large compute economies have an edge in development.
When you talked about dApp integration, I think “transition” mindset for building solutions like the one you propose is always the most sensible and aligned with the historical technological progress. Still, I have doubts about relying on a third party to safeguard my financial privacy.
The main tradeoff seems to be that you relax some of the privacy and availability guarantees. The holder of the “proving_key”, the delegatee, has to be treated as at least honest-but-curious, meaning the delegator’s history is no longer completely private (even with aggressive key rotation this mainly limits the damage if the key gets compromised later, no?).
Okay, what if the delegatee and delegator are the same entity? Then of course this is no longer an issue, and the dApp still keeps the advantage of not having to manage key material, it just asks for an eip712 signature. But then you asked, how to manage the proving/view key? I guess you implied two possible ways, each with different implications for how much the dApp has to act like a wallet:
- Store the proving/ view key in the device’s secure enclave via webauthn. This improves how the key is stored but now the sdk has to handle webauthn setup, recovery and all the ux flows, which may end up being quite dapp-specific again.
- Use wallet plugins or sandboxed environments like metamask snaps. This is not a new wallet derivation standard (and as you pointed out, who knows when and if that will happen), but it does at least push everything into the wallet layer so the dapp doesn’t manage key material directly. The tradeoff is ecosystem fragmentation and having to wait for wallet support, since not all wallets expose these kinds of extension environments.
Regardless, in either case, we bring back the old pain point of limited compute for proving.
One possible way to mitigate this is to keep the proving/view key local and use it only to derive the witness (which includes the note secrets), then encrypt the statement and witness and send those ciphertexts to a proving service. This paper (https ://eprint.iacr.org/2024/1684) shows that the prover can, in principle, be performed homomorphically over such ciphertexts, and that this is practical (at least based on their model) for computations roughly up to the scale of typical shielded pool circuits. The client would “only” need to i) derive and encrypt once, ii) decrypt the resulting proof (if needed, generate a short proof-of-decryption), and then iii) attach the proof with public inputs to the spend authorization tx, while the untrusted server does all of the proving work without seeing the client’s plaintext. Even if this works, though, it mainly improves the client ux around proving but makes things worse w.r.t key management since the user now has to manage also the keypair for homomorphic encryption.
A slightly different approach would be to run a co-snark protocol at the cost of adding some extra network assumptions. The nice thing is that there are already usable tools (https ://github.com/TaceoLabs/co-snarks) in this direction. In this model, the prover runs as an MPC between the user and a committee of provers. Then an sdk (embedded in the wallet client or dapp frontend) keeps the proving/view key local, builds the extended witness, secret shares it across the committee, and then collects the normal proof as output. This does add integration work but with your keys separation it means the dapp never has to hold the control key and no single proving service ever sees the full witness.
So, in short, I believe there might soon be ways for a dapp to behave a bit like a wallet purely for orchestrating proof generation, yet with far less responsibility, so long as the exotic key and sensitive state remain confined to secure local environments.