How well does Blockstack scale when it comes to - for example - replacing the current DNS system as whole?
And how could this be improved? Is it at all that scalable?
Or does some of the performance (in contrast to DNS) get lost because of Blockstack solving Zooko’s triangle?
Blockstack’s scalability bottleneck is in the rate at which zone files can be added and modified. This is constrained by the underlying blockchain itself.
However, we have a plan to overcome this. After we have 0.14.1 out and local applications working, we’re going to introduce “sub-names” into zone files. These will be a lot like sub-domains in DNS, but they will have separate owners enforced by separate key pairs. For example, @ryan might own blockstack.id but I could own jude.blockstack.id and you could own vsund.blockstack.id, and @ryan would be unable to take them away from us or change them without our signatures. We will use sub-names to scale up the rate at which names can be added and modified, since they allow a single Bitcoin transaction to carry out many non-conflicting name operations at once. They will also be much cheaper than names like blockstack.id, since their cost is amortized across the single Bitcoin transaction that creates or modifies them.
Important to add that while this is Blockstack’s write scalability bottleneck, Blockstack’s read scalability constraint is different and much better than legacy DNS.
Reads are much more common in legacy DNS - orders of magnitudes more people are visiting websites and resolving names to IPs than are updating zonefiles.
In typical usage of Iegacy DNS, end users talk to their ISP’s DNS servers which are responsible for answering requests for all of their customers. These ISP DNS servers perform recursive lookups to authoritative name servers for any data that isn’t cached locally. The result is that authorative name servers for popular domains are tasked with serving huge numbers of requests. Billions per month or more for some domains. This is why there’s a market for managed DNS services that compete on metrics like capacity, resistance to DDOS, uptime and latency.
With Blockstack we deploy a full Blockstack node with the Blockstack Browser. This essentially puts an authoritative DNS server on every device. With Blockstack, we can do authoritative lookups constrainted only by the processing power of the device. These zonefile queries are done entirely on device and never hit the network or another server.
The implications of this are huge. This means you can register a Blockstack name for mere fractions of a bitcoin and I can perform trillions and trillions of lookups on your name’s zone file and have no impact on network resources, a service you have to pay for and most importantly your pocketbook.
Blockstack’s incredible read scalability - far superior to legacy DNS - delivers better performance and experience to end users: faster, more secure, more reliable lookup at much lower cost to name owners. It makes a number of attacks: DNS poisoning, DDOS of name servers, etc things of the past.
The trade off is that the user needs to spend some of their disk space storing zone files and their CPU time & network bandwidth syncing and verifying those files.
The equivalent in conventional DNS would be, that a fully featured DNS server would run on every device, right?
Assuming that Blockstack completely replaced conventional DNS (as of the first post here), is this still possible on a normal device (with all that much data)?
How does that scale on small devices like smartphones or a Raspberry Pi (thinking of one local resolver for a home network)?
Are there some stats or data for these comparisons? Would be a great point for you to advertise with them, I guess 
One of the main advantages of Blockstack over traditional DNS servers is that we can heavily cache responses. In fact, in the current resolver code almost everything is in memcache. We don’t need to worry about stale responses because we don’t have the cache invalidation problem. New updates to records can only come in new blockchain blocks. So Blockstack nodes passively listen to the blockchain channel and update the cache when a relevant event occurs. DNS servers, in general, have to proactively check for cache invalidation and it’s an expensive check that scales poorly. That’s why DNS info typically takes time to propagate (caches get updated anywhere from a few minutes to 24+ hours around the world).
@vsund you may be interested in reading this discussion on GitHub:
I particularly like the idea of operation packing using a protocol like Chainpoint. Blockstack nodes would then be able to interpret both on-chain operations and packed operations. The packed operations could be stored off-chain using a protocol like StorJ to preserve the data.
The equivalent in conventional DNS would be, that a fully featured DNS server would run on every device, right?
Yup.
Assuming that Blockstack completely replaced conventional DNS (as of the first post here), is this still possible on a normal device (with all that much data)?
Surprisingly, yes. There’s not that much static state in the DNS system by today’s standards. If there are 50 billion DNS names, and each name’s DNS records take up 4K, then you only need 204 TB of space to store a full replica. That may sound like a lot of space, but if you consider that spinning rust disks today go for about $30 / TB, you could afford to host a full copy for the cost of two high-end Macbook Pros. Your ISP could easily afford this.
Blockstack’s name state is far smaller than that. You only need a few GB to hold Blockstack’s name database and zone file replica. If host the entire blockchain and its transaction indexes alongside your Blockstack node, you only need ~350 GB (i.e. Bitcoin’s blockchain dominates the storage cost).
Are there some stats or data for these comparisons? Would be a great point for you to advertise with them, I guess
Look-ups against a local replica are basically free. There’s no network traffic on read.
If ISPs had taken this strategy of holding a replica of the static DNS state on their networks, instead of routing DNS lookups upstream to providers like Dyn, then DNS-based DDoS attacks would be fruitless. There’s nothing to attack anymore, short of going after all the ISPs’ replicas one by one (and even then, users who run a full replica downstream of the ISP would be unaffected).
In this scenario both solutions have to store 50 billion names. Why does Blockstack needs that less space than normal DNS servers? The name pairs should be quite similar (storing a domain -> ip pair).
In this scenario both solutions have to store 50 billion names. Why does Blockstack needs that less space than normal DNS servers? The name pairs should be quite similar (storing a domain -> ip pair).
Sorry for the confusion. Blockstack only requires less space today because it has less names than DNS at this time You are right that Blockstack will need to store the equivalent amount of state if it had 50 billion names. However, it will be some time before this happens, since the Bitcoin blockchain grows at a constant rate. This is why adding sub-names is so important–it lets us increase the rate at which names can be added.
It’s hard to point to this as being equivalent. In conventional DNS, only a small set of name servers are authoritative for any given name. In Blockstack, a Blockstack node is authoritative for all names in all Blockstack namespaces.
That is to say, in the current system, it’s impossible to for every device to host a full copy of all DNS information and for that copy to also be authoritative. At most, one could cache all DNS information locally, but you would still need to query authoritative servers for each name periodically (when the TTL expires).
@jude A question: How can Blockstack enforce separate keypairs? If Ryan owns blockstack.id, then he owns the zonefile corresponding to that domain, right? And I imagine that there is a reference to jude.blockstack.id in this zonefile somewhere. Can’t Ryan change the zonefile since he owns the keys used to create it, and remove jude.blockstack.id?
The high-level way to think about this is that each sub-name has its own “virtual virtual blockchain” that lives in the name suffix’s history of zone files. Just as with Blockstack’s virtual blockchain, there can be valid and invalid transactions. The blockstack client would need to know how to parse the sequence of zone files for blockstack.id and use only the RRs for jude.blockstack.id that I have signed.
Given blockstack.id, I can look up the sequence of prior zone files and the current zone file (with blockstack list_zonefile_history blockstack.id). The Atlas network never discards zone files, so this will always be possible as long as the Atlas node has a full zone file set replica.
Using the sequence of zone files, I can see the history of edits to each sub-name and validate them independently of the owner of blockstack.id. So, if Ryan updated the blockstack.id zone file to say that jude.blockstack.id had a new public key, and I didn’t include my signature in the zone file, then your blockstack client would simply ignore that zone file’s RRs for jude.blockstack.id (since they are invalid).
@jude and how a sub-name will be registered? To register a name I broadcast two consecutive transactions (pre-order -> order) in the underling blockchain using any wallet (I only need to specify a specific data in OP_RETURN). But I can’t understand how a sub-name will be registered.
We’re going to have to introduce a hard-fork to implement this properly. The idea would be to modify NAME_REGISTRATION to include the list of public keys that own sub-names in the name’s stem (e.g. as additional transaction outputs). Each private key owner would then be able to broadcast a valid NAME_UPDATE independently of one another.
The zone file format would be updated to store a list of sub-names as TXT records, where each TXT field would include a payload, a monotonically-increasing version number, and a signature from the name’s owner. A set of name owners can broadcast a single NAME_UPDATE that includes updates to everyone’s sub-names. In the event that one name owner could not get in contact with the other owners, then (s)he could send a NAME_UPDATE with a zone file that updated only his/her own name.
The current state of a sub-name would be calculated by finding its latest TXT record from all of its name stem’s zone files.
@jude to register a new sub-name to a domain name that already has some sub-names the domain name owner would broadcast a NAME_UPDATE that includes all previous address outputs + a new one?
also, whats the size limit of zone files after hard-fork? signatures would add weight to it and not so much names could be added in 4KB zone-file.