Smart contract platforms vs Tor + Bitcoin for censorship-resistant online services
Which platform is better suited to host censorship-prone services?
tldr; A smart contract platform is the minimum viable product for an online service which requires a highly distributed data store. It is technologically superior to Tor hidden services in terms of censorship-resistance.
Nobody I’ve heard of thinks of smart contract platforms as extremely efficient censorship-resistant online services. Here I am going to demonstrate that they are by showing the minimum requirements of a service which provides highly distributed data storage. Smart contract platforms improve significantly on Tor hidden services and the best way to see how is to design a better system and see what comes out.
Background on censorship-resistant services
Tor hidden services with Bitcoin were the first way to offer a service in a censorship-resistant manner that scaled. In this setup, the administrator ran a database and a server as part of the hidden service. They both provided data storage and a means of executing business logic. Bitcoin was obviously the means of payment.
The weakness with this setup was that there was no real censorship-resistance in terms of data storage or executing business logic. Rather, the hidden nature of the service meant it could operate so long as it was not discovered. Once it was discovered, there was no way to protect the service from being taken down. So let’s try to improve on this by adding censorship-resistance to these core features.
Minimum requirements to offer online services, censored or not
- Data storage
- A way to implement business logic
Conventionally, data stores are provided by databases and business logic is implemented by servers. With Bitcoin we’ve solved the payments problem, so let’s figure out how we can build a system whose data and servers can’t be taken down.
What if we used a censorship-resistant means of data storage?
This would be like using a decentralized data store such as Freenet and Bitmessage, or a distributed blockchain. These are censorship-resistant because the former two are decentralized and the latter is immutable. All that we require right now is that the data is highly distributed, and everyone has a copy. The problem with using a blockchain in this case is that it requires a consensus mechanism which is a lot of overhead, so let’s avoid it unless we need it. The main issue with these options is that they only contain static content. This is to say that there’s no way to implement the actual business logic when end-users interact with these web pages. For now, we have the censorship-resistant data storage part solved. Now we just need to figure out how to execute the business logic.
How can we implement business logic on a distributed data store?
First, let’s consider how updates to data are made. Unlike a centralized data store where only the owner needs to make an update to one copy and shares it with others, this decentralized data store is distributed throughout the network and it all needs to be updated in real time by the people who possess those copies of that data.
For trust-minimization, we want to formally specify the kinds of ways service data can be altered with access rights. We can do this by having a separate static document describe how the service is to be used and by whom, which we can consider a contract. An abstract programming interface (API) in the contract can rigorously specify what instructions can be executed and how they are executed.
End-users invoke a public facing API function directly and they authenticate with a public/private key. Other users can repeat these instructions to verify that the change was legal. Since executing these changes manually is error-prone and doesn’t scale, a virtual machine can execute these instructions on behalf of the end-user.
But this leaves open one more problem — how do we know the right order to execute instructions? What if two conflicting instructions are issued at the same time? We can use a relative time stamping service like a blockchain. With a token and consensus mechanism, control of the blockchains can be decentralized, which is necessary given the critical role it plays in this system.
How to offer censorship-resistant online services
- Blockchain for immutable data storage and transaction serialization.
- A smart contract to specify the operations that can be performed on the service data and by whom, and a virtual machine to execute business logic in transactions.
- Native token for payments and transaction fees.
This is just a smart contract platform. We tried to design a service which would offer censorship-resistance at the data storage layer and somehow we ended up with something familiar that we never thought of as having incredible security properties.
Smart contract platforms are highly efficient censorship-resistant services
It turns out that if you have a highly distributed data store for an online service:
- A contract is necessary for specifying what changes can be made, who is authorized to make those changes, and how to make those changes.
- A virtual machine is necessary to execute those instructions.
- A relative time stamping service (blockchain) is necessary to order transactions for the virtual machine.
- A consensus mechanism is necessary to decentralize control of the blockchain and keep the copies in sync.
- A token is necessary to reward block producers for securing the system.
Smart contract platforms are the logical result of using a highly distributed data store to implement an online service. It’s efficient because it includes only the minimum requirements without the burden of unnecessary features. The only reasonable technology improvement would be mandatory, on-chain privacy.
Smart contract platforms are superior to Tor hidden services regarding censorship-resistance. The weakest point of hidden services is that if the servers are discovered they can be taken down. Smart contract platforms, in contrast, can’t be taken down.