off-chain persistence

[harrysolovay]

Ideally not using archive nodes.

[sam-goodwin]

In my experiments with Mina, I've found myself wanting to just host my Mina contracts in a traditional service instead of running them on the user's browser. This deviates from pure decentralization, but it does open up some interesting use-cases for open source, self-hostable services.

For example, to install a "zkservice", I can clone the repository of that service from GitHub and deploy it to my own AWS account, kubernetes cluster, cloudflare, wherever. Now I own all my data and can make use of scalable services to build apps with the performance of web 2.0. The Mina chain only needs to facilitate trustless interactions between two copies of the same service that don't share data. 99% of the app could otherwise be developed traditionally.

The use-case I am exploring is "purchase a product without revealing bank balance":

1. create a service that stores a bank balance in a web 2.0 database
2. provide an API for purchaseProduct
3. deploy 2 copies of this exact same service to 2 different servers
4. have them interact with each other, e.g. "service 1 buys product X from service 2" without ever exposing the amount of funds in service 1, only proving that it has enough to make the purchase.

Data for each balance would only be knowable by having access to the server that stores it. This seems to solve some of the problems I've read about archive servers.

[harrysolovay]

The approach you describe seems more aligned with the real-world needs of app devs. Some really interesting doors open up when contracts are placed behind a service. For instance, safeguarding against misalignment between Mina and persistent storage:

If the client is responsible for submitting tx, then it must also persist info about those transactions to the db, ostensibly but watching for inclusion and then––depending on tx success––sharing the transaction with a server, which writes it do a db. What happens if the device goes offline with a pending tx inflight? In the approach you describe, the server becomes responsible for submitting the tx, observing its status and persisting any relevant state. Much safer.

[yunus433]

Hello everyone,

As @sam-goodwin described, using ZKPs (ZK proofs) for trustless interactions between different servers is indeed very strong, and it provides 100% trustless actions as mentioned. However, this does not provide any liveness guarantees. In simpler terms, there is no solution if one of the servers is unreachable. That is the real power of using a blockchain to distribute ZKPs. I mean that the architecture you describe here is very strong, but it can be improved by including a DA (data availability) layer and a settlement ZK L1 (like Mina) without losing any Web2 advantages.

To explain the idea further, let me describe a possible architecture for the example you gave. Let’s say I have two servers, and I want to buy something from the other without revealing my balance. Instead of knowing who is the provider of the product, the fee payer can use the DA layer and ZK settlement at the same time to put a “buy request” on chain, which can then be taken by any product owner and finalized.

I first send my fund ZKP to the ZK L1 (e.g. Mina) to prove I have some funds available, and I am not doing double spending (the ZK L1 and DA layer must be integrated so that the buy purchase locks the corresponding funds fast enough to not create an attack vector through double spending). Then, I put a buy request on the DA layer through my light client. Note here that I use no RPC endpoints if I access both chains through light clients, which are possible by definition in DAs and also somewhat available in Mina. Then, any owner of the product can complete the request, get the corresponding funds, and update both chains, again through its own light clients without using RPCs. None of the servers are on chain, so both of them have the advantages of Web2 scalability. The only settlement happens when the process is complete. This system is 100% decentralized: it is always available without the need of RPCs and completely trustless as the entire process is settled by ZKPs.

I hope this gives some idea on how DA and ZK are completing the picture to create a very strong networking model. I can also try expanding this idea further for a more complex example if that would be helpful. Here, I have not mentioned other advantages that come with this modular structure, like disabling a possible MEV, as there is no need for RPCs (which is a very strong concern in most of the DEXs right now).

A final point is to mention that there is actually no architectural difference between using a browser or a server in this approach. If you need very strong performance, of course servers are much stronger than client computers, but regular users can right now easily generate simple ZKPs with o1js in an acceptable time frame in terms of UX. This is also a very strong advantage for applications that need to be compliant with GDPR.