In the Blockstack diagram, I do not understand where zone files originate. If only the hash of the zone file is stored in the virtualchain, how does the actual zone file make it to the above routing layer?
Good question. So you need to have the zonefile to get the hash(zonefile). Imagine you’re on your computer and are running Blockstack, you will generate a new zonefile and announce the hash(zonefile) to the blockchain. Afterwards you will upload your newly generated zonefile to the Atlas network.
The routing layer data is handled by the Atlas network which is a peer-to-peer network. All Blockstack Core nodes participate in the Atlas network by default.
The Atlas network is designed to reject any writes to it where the hash(zonefile) was not announced on the blockchain. Meaning that you can’t just write junk data to the Atlas network. You need to register a domain (which costs money) and announce the hash(zonefile) (which also costs money) and only then you can write the zonefile to the Atlas network.
The Atlas network is a peer-to-peer network that will replicate the zonefile automatically on all nodes participating in the Atlas network. So once your zonefile propagates through the Atlast network it’s likely going to stay available on the network unless something catastrophic happens like the entire network (all nodes) going offline and losing all their data. Even if a single copy of data still exists the Atlas network can recover.
Let me know if you have other questions.
4 Likes
But suppose I want to update a zonefile, to some new zonefile’ with h’=hash(zonefile’)
When the data on this zonefile is accessed on the Atlas network, how do I know I’m getting the most recent zonefile’ with h’ instead of the old zonefile (since it’s old hash h=hash(zonefile) was earlier announced on the blockchain and so is valid)
The Blockstack node maintains a materialized view of the latest state for all names. All nodes maintain the same materialized view, since they all process the same transactions in the same order. When you query a node’s /v1/names/{your-name} endpoint, you’ll get back the latest zone file hash, and the zone file that hashes to it if it is known to the node at the time.
That’s true for nodes but how should a client verify that the data they get back is correct and the most up-to-date data? If it’s truly trust-to-trust design then it shouldn’t have to trust the nodes, but it sounds like it’s implicitly trusting the nodes in this case.