tl;dr - Decentralization of large service providers is impractical in many contexts, and prohibitively expensive with current technologies. I think we can do better.
I think that systems which allow people to independently verify that a specific service is operating correctly are extremely important. Certificate Transparency allows us to trust what is being served by a website. CONIKS and similar systems might allow us to trust that we're talking to the right person when we open a chat. Bitcoin allows us to trust that money is handled correctly. Ethereum allows us to trust that a specific smart contract is running properly. So on and so forth. Systems like this may allow us to build an internet ecosystem that is more accountable. But they aren't being adopted very quickly. Companies aren't making the switch and there are some obvious reasons for this which I think can be addressed. I'd like to discuss these reasons and how we could make adoption of distributed verification more practical. The first few paragraphs are just going over the limitations of current systems, if you're familiar with this subject just skip past i-v.
i. Switching to a decentralized network is not competitive. People don't care if they can verify transactions on MasterCard, if MasterCard fucks up they'll get reimbursed. There's no serious competition for most big corporations that is using verifiable databases, so why bother?
ii. Decentralized networks are extremely expensive for large datasets. Suppose instead of storing money, your database needs to store every instance of a person viewing an advertisement so that people trust your affiliate or advertising network. Paying even half a penny for every database mutation is absurd, no one is going to do it.
iii. There are hard limits to computing capacity - decentralized networks make everyone verify every transaction, leading to transaction limits. For Bitcoin I believe it's something like 7 transactions per second, for Ethereum around 15 and for EOS a few thousand. Switching from POW to POS helps, but as shown by EOS the limits are still prohibitive to adoption by massive corporations. If you're a Visa or Google executive and someone proposes that you switch to a system which costs around a penny for every modification to your database and you can only have a few thousand modifications a second, you're going to laugh that person out of the room.
iv. Some data is and always will be private. You don't want all your emails stored on a blockchain, nor do you want your name linked to every payment you've ever made in a public database. There are systems that get around this, such as Monero, but nonetheless anonymity is extremely important and I don't think that the vast majority of data is going to be stored publicly for a very long time, if ever.
v. Moving a database over to a verifiable model is
hard. Very few people understand how to do it. If you want to do something that is beyond the scope of a smart contract you're going to need a bunch of research papers or RFCs.
So essentially my argument is that current decentralized systems are inefficient, expensive, hard to use and not practical for most applications. I think something like the model for Certificate Transparency is a much more plausible solution for moving services over to a more verifiable model. Essentially Certificate Transparency works like this: a central service provider stores a key-value map of domains to public keys and a log of all mutations to the map; auditors can check the validity of the map by recreating it from the mutation log based on some defined rules for how mutations are executed; clients can check values they receive from the service provider against auditors. This allows for a central authority to maintain a database, clients to retrieve values from that database and auditors to verify the validity of it. It is obviously not as secure as a decentralized network where there is no such service provider, but it is extremely efficient at providing some level of verification of correctness.
Systems like this can be extremely useful in many applications. Take CONIKS for instance. CONIKS is an instant messaging service where communications are encrypted end-to-end. It uses verifiable maps and logs with an auditing network so clients can ensure that they are receiving correct public keys when they want to begin a conversation. I believe something similar could be useful for advertising networks. If you wanted to make sure adsense is showing you the correct number of ad hits, you could just go to the website a couple of times and make sure the ad id shows up in the public map. If signatures are provided with ad displays, any time you notice an ad hit not showing up you can show an auditor or anyone else the signature and say "Look, they failed to log this!". I believe other systems could benefit from this as well, such as casinos, forums, possibly even banks.
If you look for implementations of verifiable maps and logs, you will be sorely disappointed. There's basically two options: trillian and continusec. Both of them require that you run their specific software, set up your database in a specific way, etc. I think if there was an easier way to make specific parts of your database auditable we could solve a number of problems.
I think the internet as a whole but more particularly services which require a large degree of trust from their customers could benefit from easier implementations of verifiable datasets. If you could add a few functions or attribute decorators to your code and allow anyone to verify that you're operating your service correctly you won't need to figure out how to use trillian or continusec or redesign huge portions of your software. New end-to-end encrypted chat services are constantly having to either reinvent the wheel, use poorly fitting software or entirely ignore the issue of proving public key identitites.
I'm thinking about building a set of software libraries that could make this easier, either through attribute decorators (which could be problematic in a lot of software) or just class libraries that are simple to implement.
I'd love to hear your feedback or comments, even if you're just going to tell me I wasted several paragraphs
