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?
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
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