pull down to refresh

spaces transactions are on chain
whoever holds the key for the subspace is the owner - they prove/verify all updates with their key. We have created fabric for updating data for spaces, and it can probably also be used for subspaces: https://github.com/spacesprotocol/fabric
If you can delegate a subdomain in a zone file, why don't you just use DNS and DNSSEC for everything and avoid the need for subspaces in your protocol?
reply
how can you prove off chain that you own a subspace? Seems like without going on chain, the space owner could delegate the same subspace to more than one owner?
reply
the zk receipt is published on chain by the space owner so that subspace holders can verify their ownership
reply
is it really an off chain transaction then if there needs to be a zk receipt placed on chain? or, is it really that you get a benefit in that all off chain transactions can be aggregated into a single on chain?
reply
yes millions of subspaces can be aggregated into a single hash. Subspace ownership can then be verified off chain with things like fabric
reply
OK, so it seems like the transaction is not really done off chain, but instead, all metadata for the transaction is just not necessarily stored on chain?
for example, in the early days of spaces protocol, there won't be tons of subspaces per space, so if a subspace wants to be delegated, they aren't going to want to wait days or weeks for the space owner to have more transactions to aggregate delegation of, so each subspace transaction is practically going to require a single on chain transaction if there is no others to aggregate with?
i guess I'm trying to understand if this has a similar paradigm as zkcoins and taproot assets?
reply