pull down to refresh
haven't read the full discussion but just to be clear... zk is used to compress the proofs i.e. clients can verify by downloading a small compact proof.
you can make the full proofs available (the off-chain tree itself) and verify the chain of commitments is sound without any zk. tradeoff just larger proofs. they are just merkle trees.
anyone can do this if they are paranoid about the zk circuit ...
if someone builds a bitcoin zk light client, you can't argue that bitcoin is zk and everyone will get rugged. same idea here. the zk enables lightweight verifiability.
It's a cool concept. I'm just going by the repo here, so if there is stuff not published fair enough. But the repo does raise concerns.
Let's say there's a risc0 soudnness bug, or something in the groth16 wrap.
my take is there are a number of these waiting to be found in risc0. Zcash are pretty cracked and 4 years went by with that soundness bug in their main pool. A risc0 zkVM plus a Groth16 wrap is a much larger and younger attack surface than a single payment circuit like Zcash. One day there will be formal verification for all of the zkvms but that day is still far off. Basically there will be more soundness bugs in risc0. (I didn't look at the guest program, but just go on risc0 or the wrap for now).
So play it out. One is found.
I terms of this L2 subsapce signing, anyone can then impersonate anyone, against the verifiers who didn't keep the full data or who don't verify each time against it. Far as I can tell these L1 space operators are responsible for the data, since I don't see any sort of master DA layer or anything. In a system like this the data can't be counted on so have to assume the data is corrupt or gone. People just lose stuff, and trying to get normies to understand why zk data is important not to lose is a non-starter.
Or maybe a savvy l1 space giver-outer person deleted it themselves because they're the one that wants to exploit the risc0 bug by impersonating some of the subspaces under it that the already sold.
This is different to zcash becauase all coins are the same, i can't impersonate your coins. yes it sucks in terms of potential supply inflation, but there is no impersonation risk. Here there is.
Also this on-chain pointer thing defeats a malicious operator. minting NumId::from_spk is pure bitcoin, so that's independent of the ZK layer. But it does not defeat a circuit bug since the leg of the exit that attributes your pointer to the name is the cert. And the cert verifies against a root which is what the bug lets the attacker forge a competitor for. So under such a soundness bug you and the impersonator both hold cert-backed claims and then it collapses back onto data, and as above we have to assume the data will be missing. classic zk data issue.
Remedies seem to only protect going forward. And that's not helpful with these l2 subspace names imo, since things you've signed are atomic and everywhere.
Could be a misread on my part here or there but looks that way from the repos, happy to be corrected.
One day there will be formal verification for all of the zkvms but that day is still far off. Basically there will be more soundness bugs in risc0. (I didn't look at the guest program, but just go on risc0 or the wrap for now).
i wouldn't say formal verification is that far off. They have already formally verified parts of the circuit, but let's assume that all zk is broken for the sake of it.
As a subspace holder, you can have a more verbose certificate that's merkle exclusion proofs from past roots and an inclusion proof of the root you're included in. That's a provenance proof of your name regardless of what happens to zk. Data availablity is just, you, the holder, keeping that proof to yourself.
The zk is swappable with a resolver update. The core protocol itself does not care about zk at all. it only lives at the resolver layer. the zk part is libveritas. Just like openssl might have a bug now or in the future same goes for libveritas.
see libveritas: https://github.com/spacesprotocol/libveritas
Let's say we discover a bug, then what you need to do is compress your verbose plain merkle proofs certificate into the new patched zk circuit then re-publish to certrelay. Still, you won't be rug pulled even if all zk is nonsense so its very different from zk cash
That part makes sense as to why no DA layer, I was thinking the cert was all the L2 subspace person had and why no DA layer, but if they get the provenance too (and don't lose it) then got you there.
But relying parties still transact against the drifting current root yes? which the operator controls (and which a bug lets be forged)? From what it looks like routine resolution doesn't rederive ownership from holder provenance, which would kind of defeat the whole purpose I guess if it did.
So isn't it still the same shape? soundness bug forces an emergency circuit swap, then recovery (recompress provenance into patched circuit, republish, allthat) requires the L1 space operator to anchor a new commitment that includes your binding under the new circuit?
If the operator refuses then even thouh your provenance proves you owned it historically there's no live commitment that includes you going forward? The name is over as a usable thing? Again due to the circuit swap, under the old circuit you're impersonated, so that binding can't gon on, but you can't get under the new circuit cause that requires authority you don't have? bug-forced swap hands operator a consent veto over your continued existence?
Other words you exit to an on-chain pointer you run, but then you can't take over operation of the off-chain tree unless you control or are delegated to by that persons UTXO and so you can't reallocate yourself?
Or is there some adversarial way to pull your subspace from under the UTXO without any action on the UTXO holder's part? Like pull it off altogether?
No it doesn't require the L1 space operator to do anything. The roots published on-chain are just plain merkle roots independent of the zk circuit.
So new a circuit/zk arch, does not require changes to anything that's on-chain.
The zk circuit is just a compression of the verbose proof. that's all.
Ah, much cleaner.
So is this right in terms of soundness bug impact/mitigation?
Bug means bad operator can forge rebindings of the subspaces they themselves sold, these will resolve under normal (compact) resolution until a patch.
Mitigation for subspace holder: Stop trusting compact resolution for anything high-value. Firefight past forged actions where known. Wait for the circuit patch, then the forged commitment stops validating.
Someone has to detect the bug, author the new circuit, and the whole resolver/wallet ecosystem has to upgrade. Right now presume that's like a small team but in future idea is to have it percolate.
Sound right?
Bug means bad operator can forge rebindings of the subspaces they themselves sold, these will resolve under normal (compact) resolution until a patch.
correct but there's an important point. the attacker is necessarily the operator betraying their own customers and it comes at a huge cost. If they submit an invalid commitment hash on-chain (since even an invalid compact proof needs an on-chain anchor) and later it was patched. They permanently lose the ability to sell new subspaces under that L1 space because they broke the chain of commitments.
Someone has to detect the bug, author the new circuit, and the whole resolver/wallet ecosystem has to upgrade. Right now presume that's like a small team but in future idea is to have it percolate.
exactly same as patching a vuln with any software
Same as with every ZK project, either formal verification or anticipate soundness bugs and have some way to mitigate them. And people who buy/sell/use these supspaces (are they even live?) have to go into it with the mindset that they will one day get rugged.
Or just get rid of these subspaces altogether.
But then you're left with the on-chain ones only, and there really isn't anything special about a bunch of clients agreeing on deterministic derivation from auction history.