pull down to refresh
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.
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
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.
Proving that some alien creature created us is hard enough, let alone one that is all-knowing, all-loving, and all-powerful
It depends on what you mean by "en masse." If you’re referring to the average user who doesn’t want to run their own Bitcoin full node, etc., then...
Spaces uses DNS, so you could easily leverage solutions like Fabric behind a mainstream resolver (e.g., 1.1.1.1) to benefit from its massive caching layer. Implementing this isn’t difficult, for example, by using SIP-02 (see: https://github.com/spacesprotocol/sips/blob/main/sip-0002.mediawiki).
Users don’t need to trust 1.1.1.1; they can verify the entire protocol state with a small zk-proof.
Spaces guarantees name ownership in a permissionless way, functioning somewhat like a certificate authority—but that’s where its role ends. Solutions like Fabric manage the records off-chain.
since the inception of the internet no email addresses have been defined directly on the tld so practically no collisions sip-02 also attempts to make this as painless as possible to integrate even into mainstream resolvers
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.
exactly same as patching a vuln with any software