Technology and protocol overview

trees

Dappy is a protocol for files and web applications distribution, it also includes a name system. This protocol can be deployed in various ways, and replace various layers. The Dappy protocol and network can be used as an alternative way to reference a server with a name (alternative to the DNS), a SSL certificate issuer (alternative to certificate authorities), and also as a storage and file distribution service.

The goal of this document is to describe the Dappy protocol generally, explain the motivations for it, and how it achieves higher levels of trust and robustness.

 DNS and certificate authorities

Today, the DNS system and certificate authorities are an essential layer of the web (2020).

The DNS system allows anyone to own an expression, and link it to an IP address, likely it will be the IP address of one's server exposed to the public internet network. Clients who want to connect to a service/server will use this expression (example: service.com) instead of the raw IP address. The DNS is architectured in a top-down fashion, a root server is responsible for referencing the second level servers (ex: .com, .fr, .us etc…). The DNS is decentralized in that distincts agents in various countries are co-responsible for this service. Nevertheless, each second level server is a vital link of the chain, if the DNS server responsible for .fr falls, or is hacked, millions of websites disappear quasi instantly. If the server is hacked, the hacker will be free to redirect the requests, or simply destroy this name - IP relation. The organization or company that maintains this DNS infrastructure has a life and death power over all the .fr names.

The certificate authorities system is an addition to the DNS, introduced in the 2000's. Certificate authorities distribute SSL certificates, which are linked to a domain name. Then, clients (web browser, or even servers communicating one with another) use this SSL certificate to encrypt the traffic. Operating systems and web browsers include a pre-established list of certificate authorities. Just like the DNS, if a client wishes to browse https://service.com, one or many certificate authorities will be queried to get the corresponding certificate. The owner of the domain name likely will have registered the certificate to a certificate authority. We fall back to a similar schema to the DNS, any arbitrary certificate authority can be hacked, and corrupt the security of millions of websites and web services. The client has no choice but to give full authority to a certificate authority.

The Dappy paradigm

The Dappy system includes a service which does the job of the DNS and certificate authorities, in other words name reference and SSL certificates issuance. The philosophy is therefore different from those legacy services. Rather than unavoidable agents, each of them being a point of weakness that can bring the entire system down, the Dappy system introduces the notion of co-responsability and co-authority. Each agent does the same job as the others, from the client perspective, they are considered the same way. Those agents are co-responsible and co-authoritarian regarding any arbitrary service they provide, like name distribution, SSL certificate distribution or file distribution.

The client does not want to consider this or that server as authoritarian, he always queries multiple servers, and expects to receive the same responses from each one of them. If it is not the case (the client receives A A A B for example), it means there is an anomaly, which can be due to malicious behaviour, hack, or server breakdown. The client has the power to flag irregular behaviour because he does not depend on any agent particularly, he relies on the health and honesty of a significant part of a network of agents which are independant one with another.

Let's consider synchronization criteria of 100%, in the case of failure of a single agent, the client won't be able to synchronize and use the service provided by the Dappy network. Now let's consider synchronization criteria of 80%, for a 5 members network A B C D and E, a server/agent can fail to deliver, or be hacked for a short period of time, the client will still be able to synchronize, he will receive 4/5 of identical answers, which is 80%. Expanding the network to a 20 or 40 members network, we obtain a decentralized service, because of the independance of each agent, and also a very much robust service thanks to the absence of single weakness point.

 Blockchain as a shared and authoritative database

This paradigm we just described should raise concerns, how is it possible to effectivly have n members (12, 40, 100) agreeing on the IP address a name is linked to, or a SSL certificate value for a name ? Where should a website administrator reference his server and purchase a name ? How do members technically maintain a replicated file storage platform ?

The members agree simply by being participants (active or read-only) of the same blockchain platform, therefore by sharing the same sum of data internally. The record of names, SSL certificates and files must be exclusively handled by this blockchain platform. The Dappy network is a subset of this blockchain platform (proof of work or proof of stake).

On the blockchain, the ownership of a resource (name in our case) is expressed by the possibility of signing transaction with a private key matching a public key which is known by everyone. If mr A wants to own the name service which is available, he will issue a transaction, including the payment (in cryptocurrency of course), the name service will then belong to him by being associated to his public key. He will be the only one to be able to update it (link it to another IP address for example), resell or renew it.

Why do we add a file storage capability on top of this system ? Simply because we can do it, and because this capability unlocks very cool possibilities. Dappy network members are part of a blockchain platform which can store anything that can be encoded digitally. By not limiting the Dappy network to being a name registrar, and allowing clients also to recover files in a decentralized fashion, we greatly extend the capabilities. We must keep in mind that the capabilities of the blockchain platform will always be capped by the pricing policy which might evolve over time, large files likely are to be put away.

 Economic incentive for network members

Members of the Dappy network can generate revenues with their participation in the blockchain, but this is independant of being part of a Dappy network or not. Obviously there are additional costs for maintaining the proper infrastructure for availability and efficiency that is necessary for being part of the Dappy network (great additional load of blockchain requests from clients), therefore Dappy must provide additional revenues.

The Dappy system includes a name system on the blockchain, one of the tasks of a member is to simply reflect and communicate those names to the clients. Just like legacy DNS, Dappy names must be purchased, and renewed every year. Revenues generated by purchases are equally divided between the members of the Dappy network. For a 10 members network, if name purchases represent 1 million dollars per year, each member gets 100 000 dollars per year. This behaviour must be handled by the smart contract that manages names booking, because no single member must be responsible for it. It implies that every network member is identified in the blockchain, and each one's public key or address made public.

Name purchase

The policy around name purchase is crucial, at what price should name be available ? Which characters must be authorized ? Should some name cost more than some others ? How can we express the popularity of a name (ex: chair vs abfdc) ? Should some names (ex: amazon) be pre-booked to avoid unecessary litigations ? Those are implementation concerns. On the technical side, this logic is expressed in a smart contract, and therefore handled at blockchain level without human mediation. Human mediation is possible, but it is collective, the Dappy network must agree on the rules that eventually change over time. Without agreement clients will start receiving different answers and therefore loose network synchronization (just like a blockchain fork).

Members of the Dappy network are co-authoritarian, they can decide to change the rules for name purchase, prices etc… Nevertheless their goal must be to keep the confidence and trust the users have in the platform, this trust is the source of revenues.

Unlike the DNS, Dappy network members are equal with one another and perform the same task. There is not one member responsible for .com, and another responsible for .fr, and another responsible for files etc… Members have all the same task to perform, which is reflecting the blockchain. Without this we would fall back on a unavoidable path/server schema. The split of tasks has no sense under the Dappy paradigm, extensions (.fr, .com etc…) disappear, or we could say that every member is responsible for every extensions, which is the same thing. DNS allows the name service to be the property of 150 parties, each one owning a particular extension. Under Dappy the service name is a single resource, which can be owned only by a single entity. Porting legacy domain names to a name system without extensions will inevitably bring collision issues.

An obvious proposition for price policy is to have low prices for long names, and high price for short names (ex: a, or hi). It is purely mathematical and very easy to code.

Resell mechanism can eventually be added. There could be a small fee taken by the Dappy network each time a resell takes place, this way it limits abusive behaviour. But this is to be decided for each implementation.

Engineer or organization who which to deployed a Dappy network must have those concerns in mind. Those issues are still implementation issues so we will not go further.

Capacity limitations and elasticity of the network

Possible applications of the protocol we are discribing can require enourmous storage, and network capabilities. Let's say 1000 high traffic web applications run on Dappy (name system + file storage), it is probable that 5 members won't be enough.

Members of the Dappy network are self-governed, they can decide, if the circumstances require it, to add one, two, to double the size of the network. They have strictly no interest in limiting the network size, if the usage requires it to grow. More members means greater resistance to DDOS attacks (It is harder for DDOS attacks to target an entire network), so the higher the size of the network is, the greater it is for general robustness and availability, but also it means revenus go down, because the share is less important.

The technical issue is that Dappy network members are identified by the IP address (ex 12.13.14.15) at which they can be reached. Clients, depending on the implementation, will require 100% or 80% or 67% of the network to be synced.

The update of the sources of authority (network members) is subjected to the same multi-request mechanism, and therefore to the paradigm of co-authority. If a Dappy network is constituted of 4 members A B C and D, and that members A B and C agree to get D out. All the clients (browsers which implement the Dappy protocol, and eventually other applications) will be able to sync with this "new" network only if they have synchronization criteria inferior to 75%, because D will probably keep sending his version of the network, which is a 4 members network (he does not want to be out of it). D can also cooperate, and send the A B C list to its client, in this configuration even clients with 100% criteria will be synced with the network.

The elasticity of the network is a very political, and technically sensible issue. Dappy removes the need for a unique source of authority. The sources of authority (network) are subjected to change (network expansion for example), how should a client know the new version of it ? The client must rely on this very network to describe itself, hoping the members agree with one another, and that he does not have to bring his sync criterias down to much (this is synonym to choosing between two forks).

Conclusion

This paper is not at all definitive, it will probably be updated in the future. The goal is still to build roots for the general behaviour and paradigm of Dappy. The beta network which will be deployed in 2020 will serve this purpose.

If you wish to participate in any way, please join the discord chat group. https://discord.gg/8Cu5UFV