Snapps have (understandably) focused on permissionless zk use cases, which mandates the holder of the information runs the snapp out-of-band. This is novel, but also misses some composability that on-chain vms provide. I propose a marketplace for running snapps for other users / snapps to bring on-chain composability to Mina.
While ZK / privacy use-cases would not apply (although they could still be run OOB and then provided as input to other network SnarkRunners,) there are many use cases where privacy may not be important, or where the private data is permissioned. Whether utilizing zk features or not, having the ability for snapps to easily locate and call each other provides a foundation for emergent innovation.
Key problems that make this a protocol-level discussion include:
A way to send a transaction to a snapp account which would cause the snapp to be executed with the input provided.
A registry or mechanism for snapprunners to identify which snapps they are willing/able to process, including some information from actual processing results to create marketplace visibility.
A work pool (similar to snark work) to queue these transactions and allow snapprunners to execute them.
A mechanism to decide which snapprunner is paid for the execution.
A way to send a transaction to a snapp account from another snapp account (my understanding is that snapps can only transfer to/from standard accounts and apply the difference to the snapp account.)
A way to pay fees for the snapp execution.
This proposal enables composability similar to that available on other chains, provides a tertiary earning marketplace in addition to block production and snark work, and retains most of the benefits of the “run-once, verify everywhere” out-of-band execution model.
The fee handling and snarkrunner selection are the more interesting aspects, both of which have some precedent in the snarketplace. The snarketplace has provided evidence that a market approach is more efficient (so far) than an execution-cost approach used in other chains. Like the snarketplace, the excess transaction fees could simply be deducted from the coinbase when a block producer includes the snapp execution proof and related transfers in a block. Another solution may be a mining scheme as has been proposed for snarks. Another approach (which I prefer) is to support a hidden maximum fee that would act as a governor against exorbitant fees, with the execution fee paid directly by the caller. The benefit of separate fees for snark execution would be the ability to include fees specific to the contract - e.g. to cover off-chain, permissioned data access fees or off-chain storage, etc.
This is a very thoughtful post. I’m still a bit fuzzy about how Snapps are run, hence have questions about the composibilities. If a Snapp’s codes are open source, and its verification key is stored on chain, then it functions more or less like a smart contract on Ethereum, right? In that case the composability should similar to Ethereum SCs? Are you talking about the Snapps without open source codes?
My understanding is that the snapp code is run off chain, then a snapp transaction is submitted to the network with a proof.
From the overview: “With a Snapp on Mina, the Snapp gets executed once by its developer, after which all other nodes can just verify the associated SNARK proof.” Snapps: SNARK Powered Applications
That said, it also says “Computation runs on chain, similar to a smart contract [ready 6-12 months after mainnet]” so perhaps something like this proposal is already planned. My initial reading of that was that the verification of the proof would be on-chain, but I think I misunderstood.
I also see a double snapp transaction vs. single snapp transaction, which I had missed or forgotten about. I saw the single snap transaction which only provides for interaction between normal accounts and snapp accounts, not snapp to snapp. But it looks like the double snapp may be the required mechanism to allow snapps to “call” each other - it is not really clear (to me) that enables for composition, but it may.
If these features are already planned, and allow for snaps to call each other, then the first issue I enumerated may not be relevant. I still think there is merit to a discussion for the remainder of the mechanisms moving from off chain to on chain execution.
All good and important points but as everyone here I am also not sure how snapps going to work so I like to keep my comments till see/understand how it works. The part I didn’t make sense most is. If we are running of chain then why we can’t have high-frequency apps? Is it about the snark creation or proof’s validation time taking long? Hopefully, I can clear some of them with the upcoming bootcamp
When I asked about composability at the zk-hack session the team suggested that it was supported.
Never-the-less I have been thinking about this for a while and still see value in the solution that you describe and I am personally looking to build something of this nature. Would be good to understand if it will be implemented at the protocol level first.
I think composability is definitionally supported – i.e. it’s just javascript so I could call whatever the snapp is from my other off-chain javascript. Including app composability was probably a mistake on my part.
I thought initially of building this as well, but think it would be better if there is built-in protocol support for on-chain dispatch to run snapps. If we don’t get protocol level traction, I think it we will want to create a community working group to collaborate on the service discovery and bidding mechanisms so that we have a well-supported standard that wallets can implement to be able to support an extra-protocol standard. Wallets would surface the snapp runner offers (or auto-select the cheapest) and let the caller send a payment transaction + link to the input data needed (if any) for execution elsewhere.
It is also possible (likely?) that I’m overestimating the complexity of running snapps, maybe every wallet will just be a snapp runner and will execute them in-line for you from your phone. That probably works as long as there is open access for users to get the data needed via tls.
Even the simplest approach - wallet as snapp runner - would seem to need a registry. And of course that could simply be a service offered by the explorers.
I am looking forward to seeing snapp accounts on testnet so that we can flesh this out with a few more knowns…
So my understanding of standard snapp execution model is as follows…
I have a browser based wallet (chrome extension - think metamask) holding my funds. I want to trade some tokens on a mina dex so I visit uniswap.mina. The uniswap snapp / prover circuit is embedded into the web page as wasm. I select my desired swap and click on the “swap” button. The browser fetches the current state of the uniswap snap from the mina blockchain using rpc. This current state is provided as input to the snark circuit which then executes my swap as specified. A zkp and updated state is produced as output from this circuit which is then relayed back to the chain for validation and the on-chain snapp account is updated… snap complete.
Given that the vast majority of snapps will be executed in the browser via the wallet invocation method described above I would question if it should be integrated into the protocol layer. Having said that my objectivity may be muddied by my desire to build it
However I still see uses cases where snapp compute as a service would be valuable.
p.s. the rpc-like pattern is a bit of a weak link as it requires trust that the rpc will provide accurate current state. If the current state is invalid then the zkp and updated state will be rejected upon on-chain validation. chain safe rust implementation will alleviate this issue as it will provide compilation to wasm and therefore an in browser wasm based mina client with full security.
That’s interesting as a generalized case - sourcing execution for smart contracts in general… I don’t know much about Hermez though. Perhaps an off-chain protocol could serve a more generalized use case…
We probably need to wait till more information is released.
I’d like to see if snapp A (credit score) can call snapp B (loan) and update a state as a single proof/transaction without involving a 3rd party (sequencer).
I don’t know much about Hermez though. Perhaps an off-chain protocol could serve a more generalized use case…