@zxcykuaile asks on slack:
What if the zone files are stolen by someone else?
The zone file’s hash is paired with your name on the blockchain, and the zone file itself has your name in it as the $ORIGIN. Only you can set your zone file hash since only you control your name. So, everyone will know that your zone file belongs to you, and no one else can claim that it is theirs since the name won’t match.
1 Like
Hey, jude, can you give me more detail about $ORIGIN? And I know the zone files are stored at the DHT database. Is it possible of losing your $ORIGIN and other copies all over the p2p network? Or in other words, if you cannot access the zone files no matter from $ORIGIN or the offline DHT peers, what you gonna do?
1 Like
I think there’s some confusion. $ORIGIN is the name of the key that specifies your name in your name’s zonefile.
Here’s the zonefile for my name larry.id:
{
"zonefile": "$ORIGIN larry.id\n$TTL 3600\n_http._tcp IN URI 10 1 \"https://blockstack.s3.amazonaws.com/larry.id\"\n"
}
You can see that the $ORIGIN key is larry.id.
Blockstack doesn’t use a DHT any more (as of 0.14), but instead the Atlas P2P network. I’m not familiar with the exact operation of Atlas, beyond that fact that every Blockstack node stores a copy of each zonefile. If your node can’t sync zonefiles from another peer, then you won’t be able to resolve the name.
1 Like
Hi @zxcykuaile, you are correct–if someone wants to look up your name’s profile, they need to be able to get your zonefile first. If they cannot get your zonefile, then they cannot look up your profile.
We give you the ability to control how durable your zonefile is. In the interest of avoiding zonefile loss, the client implements two automatic ways to share your zonefile: via a shared storage back-end like Amazon S3 or Dropbox, or via the set of Blockstack nodes.
When you replicate your zonefile (happens automatically in the client), you do both. You store the zonefile to the set of storage providers your client is configured to use, and you send your zonefile to one or more Blockstack nodes. You can choose which storage providers you want, so you can have your client make as many copies (or as few copies) as you desire.
Now, if someone needs to get your zonefile, they have two options: get it from the storage provider(s) you used, or ask the Blockstack nodes. They succeed if they can access a copy in one of your storage providers, or if they have access to a Blockstack node that has a copy. By default, your client keeps a local copy of your zonefile (so you’ll always have it), and replicates it to the Blockstack nodes and to two separate buckets in Amazon AWS.
The Blockstack nodes used to implement a DHT, but now they implement a custom protocol called Atlas that makes sure each Blockstack node has all zonefiles. Atlas is a lot like BitTorrent. Each Blockstack node treats the sequence of zonefile hashes in the blockchain like a .torrent file. The nodes try to connect to a bunch of peers and use BitTorrent’s “rarest first” chunk-fetching strategy to prioritize replicating less-durable zonefiles. Instead of using a tracker, they use a stochastic peer-sampling algorithm that is known to be good at getting a random sample of peers in a dynamic network graph. We went with this approach because random overlay networks are more resilient to node failure in practice than structured overlay networks like DHTs.
TL;DR It’s hard-by-default to lose your zonefile, and we let you make it arbitrarily hard beyond what we do.
2 Likes