Yes 👍
Would bring privacy because you can compute over encrypted data
> AFAIK it's well understood that rollups actually do a poor job of actually scaling though they have undeniable utility advancements.
What ? ZK rollups using state diffs (as opposed to sending compressed tx data) scale extremely well! It's the opposite, the more traffic you have on them the more efficient they are.
> Using Bitcoin as a DA will make tx onchain strictly more expensive than on Bitcoin today the moment any sort of scale usage shows up.
Yes but in this scenario you assume that most of the traffic will still happen on L1 directly ? Assuming most of the traffic move to L2s then it's not the case.
> All of the gadgets you refer to are underexplored and add new layers of complexity that I don't think are fully appreciate because they've never been tested in real world environment.
Fair enough.
> What we know of rollups is that they are permissioned, likely very expensive to operate and consolidate into few service providers that can capture network effect. (observations from ETH).
Yes this is the current state of affairs today, I wont deny it. Everything is about the credibility of the path to decentralisation and to fix those aspects.
> Precisely, yes. It's just another blockchain. Blockchain decentralization doesn't manifest in and of itself and every attempt other than Bitcoin are looking like failure so I don't see why it would be different here.
With validity proofs it's trustless. You're only giving up censorship resistance (up to L2 consensus), but gaining: scale (like lightning) and functionality. In fact, the latter also gives more security because you can do DeFi and self-custodial applications.
> Too expensive
It's less expensive than Bitcoin today. Bitcoin stores all tx on chain. This will store state diffs in the worst case which is much cheaper.
> That's an option but I'm not sure how it would play out in practice. Overall it just seems overarchitectured. Another example is I have no reason to believe at the moment that fraud proof economic games are actually sustainable. They seem quite capital inefficient and I've read pretty serious concerns around the long term game theory.
Validium prevents escape hatches, but it's not related to fraud proofs. Unlike fraud proofs, validiums make it imposible for operators to steal funds.
There is also the option of self-DA like Adamantium (it needs users to be live, but IMO, it should still be strictly better than Lightning).
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.
Gotcha, i get your points.
> I just don't believe in decentralized sequencing.
What bother you the most about this is the need of having a consensus and hence economic security needs ? Or accessibility of running a sequencer ?
> Nor do I believe you can trust DA layers.
And you don't believe that Bitcoin could be used as DA layer ? And what about Validium ? You said that you are willing to concede trust where needed, wouldn't it be the same in the context of a Validium ? (assuming you can force exit the system at a reasonable cost)
> fragmentation is my biggest concern
Fragmentation of liquidity ? Fragmentation of UX (i.e interop) ?
Thank you sir!
> DVMs and zero-knowledge computation seems like a match made in heaven.
100% man! The more I think about it the more obvious to me.
> I'm personally not a big fan of ZK as a scaling solution for Bitcoin.
Could you give a TL;DR on why ? I haven't seen you expand on the reasons why. You can point me to existing content where you expressed your sentiment on this topic if you prefer.
Let say it's possible to completely remove trust assumptions and have decentralised sequencers and provers, fully permissionless, with escape hatches etc. Even in this scenario you would not be fan ?
What are your concerns ? Security ? Garbage usage of Bitcoin ?
Powering Verifiable Computation for the Nostr Revolution:
https://hackmd.io/@abdelhamid/nostr-dvm-verifiable-computation
#Nostr #FreedomOfSpeech #Integrity
Verifiable computation for Nostr Data Vending Machines.
Nostr DVMs are the future:
- free market
- censorship resistant
- standardised
What if we could bring ZKPs to make the computations of DVMs provable ?
Here you, with Askeladd :
- NIP-90 compliant.
- Uses STWO prover to generate Circle STARK proofs.
- In-browser proof verification using Web assembly STWO verifier.
For the user it's very simple:
- Submit the job via a web page signing a Nostr message (with any NIP-07 compatible extension)
- Get the result and verify the proof in the browser directly
Try it yourself: https://askeladd.org
Have Fun Staying Censored ?
Bonus side effect of building this POC: I was able to catch and report a bug in the Nostr Rust SDK. Shout ouf to the maintainers who fixed it few hours later.
I may be the one who implemented the first NIP-90 compatible DVM in Rust 😜
https://github.com/rust-nostr/nostr/issues/512
nostr:note15yu3yzmldlmqskuekevr9q0fj723skx3lwfmfvw9f87cartpjl7s3wd7ws
- client side proving
- ZK rollups that need to decentralize provers without a blockchain consensus
- offchain ZK use cases (could be generating and gossiping proofs for ZeroSync to improve IBD process on Bitcoin)
ZK Proof Generation Data Vending Machine.
My POC is now NIP-90 compatible.
Check out demo video.
- Running Nostr relayer
- Running the Prover Agent DVM service provider
- Running the DVM customer, requesting the ZK proof generation
Customer gets the STARK proof as part of the payload of the DVM job result, verifies it, voila!
Nostr is amazing. Simple, elegant, powerful.
nostr:note1hu6kwr72625w349gatj0pv58qp3z7fksqx92unp96fvfyuth553s9tr0k2
Yeah that’s a wonderful idea! Let’s work on it together?
Yes indeed. I discovered NIP-90 thanks to some folks mentioning DVM. You are absolutely right.
Yes STARKs can be used completely offchain.
No specific use case in mind for now but I feel that the demand for decentralized proving will constantly increase in the future.
AI might be a big vertical needing this.