I'm just creating this thread to briefly document some ideas I had about creating an efficient decentralized DNS system and encrypted internet layer on top of it. It's been known for some time that the
mini-blockchain scheme is an ideal system for implementing a decentralized DNS database, because of the way balances are stored in the "account tree".
Cryptonite, the first mini-blockchain implementation, has "withdrawal limits" which can be set by the owner of an address. Both the balance and the withdrawal limit of all non-empty addresses are stored in the account tree. To update the withdrawal limit, the address owner will create a special transaction which modifies the withdrawal limit value stored in the account tree. It is easy to see how the account tree can be adapted to store and update IP addresses instead of withdrawal limit values, and it would be much more scalable than a system like Namecoin.
Now I'm not very familiar with the way Namecoin works, and the rest of my post may be reinventing the wheel, but I have some interesting ideas for how to achieve perfectly secure communication between client and server without any centralized certificate authority, and how static files like images can be distributed among peers in a simple and efficient manner which allows for fast website load times and could even reward the nodes who distribute such files. So the first step, as mentioned earlier, is to map domain names to IP addresses using the account tree. If we actually use the public key hashes (aka addresses) as the domain names, then it's possible to use public key cryptography for encrypted communication between clients and servers. We could also add another field to each account in the account tree which maps the public key to a human readable domain to make it user friendly.
Steps for establishing secure communication channel with a server:
1) client uses account tree to lookup IP of a domain
2) client sends hello message containing own public key to server
3) server signs the clients public key and sends it back
4) client reconstructs full public key of server from signed message and:
a) ensures the public key hash matches value in account tree
b) ensures the response is signed by that public key
c) ensures contents of response is their own public key
Now both the client and the server have each others public keys and they can communicate securely, and the client knows it's talking with the correct server because only that server can sign messages with the public key listed in the account tree. Now personally I think this approach is far superior to onion routing, because it allows direct connections to remote servers, you don't need to go through any type of peer circuit or exit nodes which can see what you are doing. And it's completely encrypted end to end, so even your own ISP cannot see what you are requesting from any given server. However they can see with what servers you are communicating, and that may pose a problem for websites wishing to avoid censorship. I think this problem can be best solved by decentralizing the static content among peers, so that the server only needs to hold scripts and databases (eg user database).
My first thoughts on this issue were to work on top of a system like storj, but we really need our web content to be delivered at the fastest speeds possible, and I don't think a system like storj can do that because you need to do tedious blockchain lookups to locate files on the network (correct me if I'm wrong). A much simpler, and faster solution, is this: the client wants a file, so it makes a request to the server, the server has a list of IP's for nodes which it believes are in possession of the files. The first time a new file becomes available, the server may allow peers to download the file directly until it is well enough seeded, but a more secure method would be to anonymously upload the file some where and redirect clients that place. For example some HTML code supplied by the server may look like this:
<img src="p2presource:108f07b8382412612c048d07d13f814118445acd" />The p2presource part indicates we have a distributed file stored by peers, and after ":" is the file hash obviously. To acquire the image in this case, the client would send a request to the server for that resource just as they normally would, and the server may directly serve the file to the client, or it may point to another peer it thinks has the file, or it may redirect to else where, for example an image located on the normal internet. If we wanted to make it even more robust we could allow the server to respond with torrent hashes and then locate the file using DHT and seamlessly download it in the background, however this would only be necessary until enough nodes had the file. Nodes willing to redistribute the file could inform the server of their intentions, and the server will redirect clients to those nodes when ever it receives a request for a file those nodes claimed to have.
Once again this approach should be quite fast, since the files can be downloaded directly from peers, but there isn't any incentive for anyone to redistribute files, but before I get to explaining how that might work, I want to briefly discuss the anonymity implications of the distributed file system I just described. Since the client and server will be communicating securely, it's not possible to eavesdrop and learn what files were requested by the client, but if the client is pointed to other nodes who have the file, when the client makes a request to those nodes it will be in clear text unless we establish some sort of encryption protocol. Now since the client doesn't care about what peers have the file, it doesn't need to validate the identity of peers like it does when it first connects to the main server, all it cares about is getting the correct file with the hash specified by the server, like so:
1) client sends hello message containing own public key to peer
2) peer responds with its own public key, encrypted with client pubkey
3) client verifies response by decrypting message with its private key
4) client sends hash of needed file to peer (encrypted with peer pubkey)
5) peer decrypts hash and sends back requested file (encrypted with clients pubkey)
6) client decrypts file and verifies that the unencrypted file hash is correct
What we basically have now is a system where only the server and/or redistribution peers know what files the client has requested. As mentioned earlier though, there is still no incentive for nodes to share files, what we need is some type of reward system for redistributing files. This should be quite easy since the system I've described is already built on top of the mini-blockchain scheme, a cryptocurrency scheme which is particularly good at handling micro-transactions, which is very helpful in solving this problem. Now I must admit I haven't really thought about the fine details of how this could work, which is why I left it for the end, but basically I imagine a reward system working via some sort of micro-transaction approach where the file is downloaded in small pieces. Or alternatively, another good approach may be to have the server some how pay nodes who redistribute their files.
The interesting thing about this overall system is that domains can have a coin balance associated with them, since the domains are addresses, or they map to addresses. So if servers pay nodes who redistribute their files, then it's much like paying for normal server bandwidth, and if the balance of the server address reaches 0 it will be removed from the account tree, meaning it will be removed from the DNS database. However I don't think we need a protocol for forcing servers to pay nodes who redistribute their files, because if a server stops paying fairly people will simply stop sharing their files and look else where for a better profit. The main issue with this approach however is that nodes must be able to prove they are sharing the files, and we can't use recent innovations related to proof-of-storage because holding the files on disk is simply not enough, they must be shared.
Anyway I wanted to keep this post brief, so I'll leave it there and await some thoughts and feedback on what I have presented so far. Hopefully I have presented some original ideas, and hopefully some of you guys will have some interesting expansions and modifications of these ideas, especially in relation to the reward system for redistribution nodes, because I haven't really done much thinking on that topic. I wont be able to work on implementing any of these ideas since I am already focused on Cryptonite right now, I'm mainly just posting this because a few people on the Cryptonite IRC were interested in it and I thought it was worth sharing. But I do think this system could work very well and I highly encourage any interested parties to give it a shot, I will help however I can. A fast and secure decentralized internet layer would be extremely popular and it's something we really need in my opinion.
Show Posts
