Give this guy a follow Nostriches I'm personally not a big fan of ZK as a scaling solution for Bitcoin but DVMs and zero-knowledge computation seems like a match made in heaven. View quoted note →

I couldn't understand how this magic works. Imagine that I send to a DVM a list of numbers and it performs the sum and returns the result along with a "hash" proving that the computation was correct. I'm a developer, so I ask you to make a post explaining this simple case in detail.

So in this case you would need a way to prove that the computation was done correctly. A hash is not the correct way to think about it, since a hash is about integrity of data but not integrity of computation. What you need to generate is a Zero Knowledge Proof, there are many different type of proofs (SNARKs, STARKs, and many variants in each family etc). You have multiple approaches to prove a computation. either you build specific circuits / AIR for the computation you prove, or you are able to prove a higher level language, where you use a VM that is provable, and then you dont have to write custom circuits for each computation. This is the approach i am proposing here. Basically you can write your computation in Cairo language, which is a language that enable you to build provable program. So in your example the flow would like this: - write a program in Cairo that performs the sum and return the result - run the program with the Cairo VM to generate the execution trace (something needed to generate the proof) - run a prover (like STWO) to generate the STARK proof - then on the client side you verify the proof instead of re doing the computation yourself Of course on small programs like this example it does not really make sense because you would just do a naive re execution and compare the result. But on complex programs it makes sense because the verification is exponentially faster and cheaper as the program complexity grows.

Couple it with homomorphic encryption and you get a trustless computation market, the future is cyberpunk af

Yes agreed! Definitely FHE will play a big role in this future of decentralised trustless computation!

👀

Could this be used to improve decentralized exchanges? Could this be used to improve the state of art of relays?

Yes, homomorphic encryption could complement verified computation to provide the privacy aspect, am I right

Yes 👍 Would bring privacy because you can compute over encrypted data

Hi Abdel, thank you for giving showcase on using ZK Proofs as verifiable DVM. It is interesting case and love your work. I have no experince yet integrate ZK Proofs in practical application. Given these following function:

GitHub

sentiment-analysis-api/app.py at 2f16b2ebbec2d2ded723cf00dccf4ef86a0367b3 · atrifat/sentiment-analysis-api

A Simple PoC (Proof of Concept) of Sentiment Analysis API Server. A core dependency of nostr-filter-relay. - atrifat/sentiment-analysis-api

How do we implement ZK proofs in those "predict" function?

Is there any VM that runs webassembly and generates zk proofs? Any modified version of Wasmtime?

Thank you. In general I would say there are 3 options to generate a ZK proof for a specific computation: - build custom circuits: this is a very low level task that requires deep knowledge of moon math and cryptography, super hard to maintain. - use a general purpose ZK VM like Risc Zero and prove the execution of your existing code you want to prove. The benefit is that you don’t have to rewrite the code you can use it directly as is. However there is a big performance overhead - rewrite the code you want to prove with a specialized high level ZK DSL like Cairo (this is the technique I am using). Maximal efficiency.

Webassembly directly I don’t think so. However there are RISC Zero, SP1 or Jolt that enable to prove risc-v instructions (and so any language that can compile to risc v target, i.e directly)

Oh, I think many devs who are not familiar with ZK proof might choose second aproach due to minimum modification of the original code or they just can't due to all dependencies which hard to be rewriten all over. 😅 > However there is big overhead Does it slow down much to generate the proof along the code? More than 1000ms?

Yes the overhead can be very big depending of the size of the computation. Possibly it can be 2 order of magnitudes slower and more expensive.

I see, it is quite hard for critical computation that need fast processing (< 100 ms) especially if the implementation can't be rewritten totally. Based on your experiences, is it possible to generate zk proof for external API request? Examples: 1. We provide DVM that gives weather data that were processed from external weather Red API service

I see, it is quite hard for critical computation that need fast processing (< 100 ms) especially if the implementation can't be rewritten totally. Based on your experiences, is it possible to generate zk proof for external API request? Or is it limited to computation that was calculated directly on host machine? Examples: 1. We provide DVM that gives weather data that were processed from external weather Rest API service 2. Text Summary DVM that gives summary after request them into external AI service (GPT4, Lllama3.1 405, etc) due to can't self host it Both cases need external service

Btw, if you are using a new kind, please define and PR it to the repo, so it is known it's reserved. 🤙

GitHub

GitHub - nostr-protocol/data-vending-machines: DVM documentation and kind registry

DVM documentation and kind registry. Contribute to nostr-protocol/data-vending-machines development by creating an account on GitHub.

Yep mate you are right. I had this in mind. The reason i did not do it yet is because for my POC the Job request kind is very specific to a single example which is the proving of a Fibonacci sequence. The parameters don't really make sense for a generic scheme. I need to think about how to make a standard format for a Job kind that would be `ZK_GENERATE_PROOF` or something like this. Or maybe it's better to have different kinds depending on the type of proof and implementation, so for my case it would be more: `ZK_GENERATE_CIRCLE_STARK_PROOF`. Anyway, i am open to feedback and advise on this question.

GitHub

feat: Implement NIP-89 for DVM to Advertise ZK Proof Generation Services · Issue #11 · starkware-bitcoin/askeladd

Description We need to implement NIP-89 (Recommended Application Handlers) for our Data Vending Machine (DVM) to advertise its Zero-Knowledge (ZK) ...

No stress about it, just a general hint once you feel it's ready. I guess it could make sense to have single kinds for each proof, but it's also not my expertise. Would still be nice to see an example in markdown so it's easy for other implements (like my python framework) to communicate with your DVMs in a meaningful way :)

Totally makes sense yes. I will work on documentation and examples.