pull down to refresh
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?
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.
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.
It's more than technical, it's everything. I had claude give me the heads up from the repo, here is where it lands for these zk subspaces.
Say one morning a security researcher discovers a critical soundness bug in the guest program circuit. Now what?
When someone asks "what's the pubkey?" for me@bitcoin the answer comes from a cert that proves the binding against an on-chain root. So okay.But the soundness bug means the attacker can produce a valid cert binding me@bitcoin to their pubkey. Resolvers can't tell which cert is legit. So future lookups of me@bitcoin become meaningless
It's unknowable if this bug has been exploited and if so how long this has been going on? If these attacker pubkeys signed important stuff that was processd based on subspace resolution, are those actions all in question now? Do we have to do a pubkey review? And if so what determines the true pubkey? If the holder rotated after the attacker minted theirs now the attacker's is older. These binding have never touched bitcoin for most subspace people. Bitcoin just knows a root that contains them, but Bitcoin can't tell you anything about who they arefor without the ZK layer working right,
This can't go on obviously.
So who presses the emergency button here? It's max decentralized by the looks of the repo and docs. so the answer is nobody presses the button because there is no button. And even if there is one what does the button do? Force everyone including these supspace level 2 domain holders to do the equivalent of exit to the L1 (have a wallet on bitcoin and an indexer and all that) so the whole thing can be replayed from day 1 and only if you can prove your ownership of the supspace on bitcoin and spend some bitcoin do you get to re-claim the subspace names you already had? By this time all trust in the system is gone anyway, and what happens if there's another soundness bug next month?
Point is for a new ZK project like this (and in this age of mythos) you have to assume there are soundness bugs in the initial circuit and that will be found over years. To assume there are none is not an option these days. But as far as I can tell this has been designed on the hope none will be found.
And that's application-level soundness bugs. This is all a guest application in Risc0 (only Risc0 as far as I can tell, not multi-prover) which itself had serious bugs last year. If risc0 buts like that happens in 2027 say, upgrading the spaces circuit doesn'tfix it,the new circuit just refuses to accept new subspace signing forgeries going forward. But old forgies are unknowable. like zcash. You need a fork-style recovery with checkpoint selection, state reconstruction, ecosystem coordination all the rest. The tooling for this isn't built in to spaces, the governance for it doesn't exist, again as far as I can tell, could be wrong but no mention claude found.
Bitcoiners tend not to be aware of how fragile ZK is because they're used to ossified code stability. But wiht this you can't even really sell subnames for the first few years because it's such high probability a soundess bug will force a restart. Unless the whole thing moves to lean4, but that woud take years of bleeding edge coding. Don't mean to dump on it, but if this is something you are really passionate about take it with a huge grain of salt and know it'll be years from now at least before you can start to feel like a subspace might be something you can trust and that won't just have its value disappear one morning.
For the OP's simple reason that for human-readable names everyone has to agree on the same protocol.
It's rarely about technical backbone. Every backbone has issues. Is whatever zk that makes this spaces thing work trustworthy? Is there a zcash-type soundness bug lurking that would make every one of the names invalid one fine morning? If names can be forged there's gonna be no clean way to say these forged names are invalid and these real ones aren't. Unless the whole thing is formally verified in lean4 or something it's almost guaranteed there's a soundness bug lurking somewhere in the circuit design that when triggered will mean a loss of uniqueness guarantees for all.
What's the recovery plan for that? You can't turnstile something like this so everyone just accepts the soundness bug means nobody's spaces domans are valid anymore and everyone just starts again?
Has trail of bits seen the circuit code? can you show me the soundness audit? Being open source doesn't help here at all, zcash soundness bug was in the open source for 4 years.
You see where this goes, tech arguments cut both ways. It's much more about agreement. we have to all agree, and we already agree on DNS, and we need these things to work now, for everyone.
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?