Nostr Web Client

Go watch what Sutton said Vprogs are. No liquidity silos. He did an interview with XXIM. Sompolinsky is saying the same thing.

JOE2o 1mo ago 💬 1

I get the gist, our team does zkapps (o1js, noir, cairo) and there's not a lot new under the zksun.

At the end of the day it's logic executed off-chain by a dedicated prover. It always is. Whether you use a sequencer and call it an L2 or use a so-called vprog and call it an extension to the L1, it's still some outside CPU taking a long time to prove something and then yeeting that proof on back.

Honestly, for ZK, my view is that you need a ZK stack top to bottom. Mina was too early but that is the right path, the entire Mina chain reduces to a 22kb recursive snark, you can verify anything proven in the entire history of the chain on a iPhone in100 milliseconds. You just need that 22kb snark and whatever zkapp state proof you got sent to you and that's it. So a super-fast ZK sequencer rolling up to a ZK-native layer like Mina, or some high speed ZKnative L1 that emerges in a few years, this stuff all makes a lot of sense.

It would be impossible for a Kaspa node to verify Vprog ZK-proofs on an iphone like a Mina mobile rust node can. For Kaspa the best you can do is an SPV kind of deal, trusting a cluster of full nodes or a centralized RPC endpoint, and anyway on an iphone an SPV will get stopped once the app goes to background.

There are projects taking the Mina learnings and coming out in the next few years that will be the future of ZK. It'll be ZKnative top to bottom. (I'm in Asia so I'm biased, but I think ZK for the next 10 years is all about mobile.)

Kaspa is just not ZK-native. You can do a similar trick to these Vprogs (minus the DAG flourish) on Solana, but Solana is not ZKnative either. And Aztek rolling up to Eth, okay Noir is nice, but Eth is not ZK-native either. All of these suffer from the same dissonance and can't be the ZK future.

Solana is for old-fashioned smart contracts. Kaspa, like Bitcoin, is for money. My thoughts anyway.

Reply to this note

Please Login to reply.

Discussion

WildBill 1mo ago 💬 1

There wasn’t a whole lot new under the sun for POW, until Kaspa. And here we are at 10bps (everybody said it couldn’t be done). I’m not sure getting “the gist” means you can create something nobody else has been able to. Clearly Sutton and YS disagree with you.

JOE2o 1mo ago 💬 1

I don't think they would disagree at all. They would agree that Kaspa is not a ZK-native layer 1 like Mina or whatever follows Mina is. Because it's not.

But they'd say there's still a use case for yeeting ZK proofs back to Kaspa, which there is.

I'm arguing that use case is quite limited in the grand scheme, and that in the end the some future ZK-native layer 1 will win. Vertical integration always wins.

JOE2o 1mo ago 💬 1

The crux here is that Zkapps are not smart contracts in the sense that all computation is executed by every node on the chain. There are an outside thing. When yeet a ZKproof to chain, the main thing people have to then be able to do is verify the proof. If not then what was it for?

If verification is hard, or slow, or clumsy, if it requires trust in an RPC call, or running a node, or an SPV, or whatever else, then it'll ultimately fail as a system, because that's all too much of an ask of the verifier.

WildBill 1mo ago 💬 1

If they can remove the issue of liquidity silos, what’s your issue with what’s being done?

JOE2o 1mo ago 💬 1

My issue is on the verification side. These are ZK proofs, create them any way you like -- but they have to be verified by random people. Or what are you doing?

One reason Kaspa team are going the ZK route is because they cannot do on-chain computation (non turing complete), so they are outsourcing to the end-user's CPU or GPU, or to dedicated proving servers. Which is fine, ZK is useful. But then random people have to verify the computation that those CUPs and GPUs did.

So verification matters, and the whole liquidity silos things doesn't touch on verification at all, that's a whole other thing.

Let's say that the proof is that a passport showing age over 18 was seen at such and such a time by such and such a website. Creating the proof is and validating it on chain is one thing. Trustless verification by random people that need to check this fact is another thing. Kaspa best you can do is old-fashioned call an RPC. Not trustless. To truly verify the state themselves, they would need to run a full Kaspa node, which is, like, big. A full Kaspa node needs to maintain the entire state of all vprogs it cares about to run and re-verify the logic locally, or at least be able to access the witness data and state commitments.

Whereas with proofs on a ZK-native layer 1 anyone can do trustless self-verification on a cheap android phone from10 years ago. This is why the ZK-native layer 1s will win out in the end.

WildBill 1mo ago 💬 1

Why do you need to access the witness data if it’s cryptographically verified? That can’t change.

JOE2o 1mo ago 💬 1

that comes after an "or". it's either or. but a single kaspa node would in any case have to maintain the state commitments of every signle vprog across the whole thing going back to the pruning point, whatever that is for kaspa. otherwise makes no sense. if the pruning point is only a few days back and that's out the window then you need an archive node, that's crazy heavy for an auditor that just needs double check in a trusted way (i.e no RPC call) that someone who visited a website last week was over 18.

so it fails on that end.

WildBill 1mo ago 💬 1

You don’t need archival nodes to verify what’s cryptographically verifiable. Nobody looks at the history and visually verifies UTXOs on a scale of any magnitude.

JOE2o 1mo ago 💬 1

Ok so let's say you're a compliance auditor. You've been sent by the team a merkle path n' leaf set relating to a website login for a user who supposedly passed an age check, and this includes some user details. You need to run that against Kaspa to see if it checks out, and an RPC call won't do. This suspicious login is from one week ago.

Explain to me how, without an archive node, you do this.

WildBill 1mo ago 💬 1

Why is the onus on Kaspa to regulate an age check? This issue is way before Kaspa. Kaspa is only settling what’s been determined/or neglected prior. That’s like saying the internet is responsible for a 15 year old getting on a porn cute.

JOE2o 1mo ago 💬 1

I don't think you're understanding what ZKproofs are. Kaspa is not regulating anything. It's just doing math.

The ZK proof in such an example would be a mathematical proof that the government-private-key-signed data from the chip inside the passport was scanned by the device (which has its own cryptographic record relating to the nfc scan and loading into memory and so on). All it is is math. The significance of the math is what humans agree on, but once that's agreed on you're gonna need to run occasional checks to make sure the math checks out (and thus that the significance of it checks out).

You can extrapolate that to anything a kaspa vprog would do. It's all the same thing, proofs of whatever math underscores whatever thing of interest (often a transaction but not always).

But end of the day, Kaspa is just not designed to do this kind of verification efficiently and trustlessly. This is all an afterthought for Kaspa. So it stands to reason it's not going to be super efficient at it.

WildBill 1mo ago 💬 1

Why would the math break? Why the occasional checks?

JOE2o 1mo ago

Because for ZK the data of "what happened" is typically off chain. It's not like an old-fashioned smart contract at all, where all of that data is on chain. So the parties will share that data with each other privately. And then the receiving party can use what is on chain (the merkle root) to determine the "mathematical truthfulness" of what they've been passed. Those are the checks.