The “Blockstack: A New Decentralized Internet” paper as well as previous papers give an overview explanation of SNV protocol for Blockchain Name System (BNS). These papers all have a reference to the page that does not exists on this web-site: http://blockstack.org/docs/light-clients so currently there is no place where this protocol is explained in detail.
Regarding the explanation provided in paper, I cannot quite get this part:
For fast queries, application users obtain CH(n) from a trusted node, such as one running on the same host. A user can then use this trusted CH(n) to query previous state transitions from untrusted nodes in a logarithmic amount of time and space.
How is that a lightweight, if to obtain an initial consensus hash CH(n) for further query I need a trusted full node running on the same host? Or do I misunderstand something?
From my perspective a SNV protocol should give a user who does not maintain a blockchain and a respective virtualchain a possibility to look up and resolve a zone file for the specific name. Does Blockstack provide this functionality?
If you have a trusted CH(n), you can use it to query prior state transitions in blocks n - 1 and lower from an untrusted full node. The full node will be unable to lie to you, short of forcing a cryptographic hash collision.
SNV is used to prove that specific state transitions occurred in the past. For example, if I want to convince you that I sent a NAME_UPDATE transaction at block 400000, and you have the consensus hash of block 460000, you can use SNV to verify my claim.
We’re still working on updating SNV to prove name ownership. If Alice wanted to prove to Bob that she transferred her name to Charlie at block 430000, Bob can use CH(460000) to verify that the transfer happened. However, he cannot yet prove that it was the last name operation (i.e. he can’t prove that Charlie did not transfer the name again). Bob would also need a trusted UTXO source to prove that Charlie did not issue any subsequent transaction that consumed the “name ownership” UTXO embedded within the NAME_TRANSFER transaction.
We’re still working on an efficient way to rely only on the consensus hash to prove who owns which name at each block, so users won’t need to build a full UTXO index to use SNV.
How a lightweight node would acquire a consensus hash? Real-world usage case: a mobile browser has embedded BNS and wants to resolve blockstack.id.
And another off-top question: when we update a registered name to include a hash(zonefile), how does that look like in op_return? Are name and hash(zonefile) live in the same op_return? I’d read how these operations processed in more detail without diving into codebase but I cannot find a documentation.
The reason for this encoding is because at the time it was written, OP_RETURNs could only be 40 bytes long. We had to be creative in how we encoded this operation.
@jude I am starting feeling uncomfortable bothering you with these fast queries / lightweight node / snv questions though it seems like without access to blockchain real-world lightweight nodes (like smartphones) would need to trust someone to get a consensus hash for the current virtualchain block for further queries (correct me if I am wrong).
It would be great to have /docs/light-clients page up one day. Two published papers have a reference to it.
@vsund thanks for the link! That is the same info already provided in white papers. I cannot say that it lacks explanation and that is more likely me experiencing troubles understanding SNV and light-nodes concepts.
As @jude explained:
If you have a trusted CH(n), you can use it to query prior state transitions in blocks n - 1 and lower from an untrusted full node.
During the talk @muneeb Ali pointed out that we (still?) need a database of state transitions (aka virtualchain but built (downloaded) without underlining blockchain), however, it can be untrusted if we have a trusted consensus hash that guarantees it’s validness.
That said, I cannot understand how can we resolve a name:value pair only having a trusted CH without any heavy databases (on a mobile phone). And a trusted CH is too more like problem if a light-node is a smartphone in a jungle (probably the same level of security that we have with hot bitcoin wallets like Copay?).
Your not resolving the name:value pair but verifying that the information you got from a public Blockstack node is correct. The steps would look like:
a) Perform a lookup using a untrusted and/or public server (because you can’t run a full node on your mobile device).
b) Using a current consensus hash that you trust, follow the SNV protocol to verify that the state returned by the untrusted server is part of the state transition history that results in the consensus hash that you’re trusting.
b) is the problem. Bitcoin’s spv works without any “trusted hash” and so would Namecoin’s. Adding a concept of trust in such a way makes the whole idea of decentralized dns useless.
