Bootstrapping An Autonomous Decentralized Corporation, Part 2: Interacting With the World
Bootstrapping An Autonomous Decentralized Corporation, Part 2: Interacting With The World
As we discussed in the first part of this series, the internet allows us to create decentralized corporations, automatons that exist entirely as decentralized networks over the internet, carrying out the computations that keep them “alive” over thousands of servers. These networks can even maintain a Bitcoin balance, and send and receive transactions. However, one major challenge still remains: how to actually interact with the world around them.
Getting Data
The first of the two major challenges in this regard is that of input – how can a decentralized corporation learn any facts about the real world? It is certainly possible for a decentralized corporation to exist without facts, at least in theory; a computing network might have the Zermelo-Fraenkel set theory axioms embedded into it right from the start and then embark upon an infinite loop proving all possible mathematical theorems – although in practice even such a system would need to somehow know what kinds of theorems the world finds interesting; otherwise, we may simply learn that a+b=b+a, a+b+c=c+b+a,a+b+c+d=d+c+b+a and so on.
On the other hand, a corporation that has some data about what people want, and what resources are available to obtain it, would be much more useful to the world at large. Here we must make a distinction between two kinds of data: self-verifying data, and non-self-verifying data. Self-verifying data is data which, once computed on in a certain way, in some sense “proves” its own validity. For example, if a given decentralized corporation is looking for prime numbers containing the sequence ’123456789′, then one can simply feed in ’12345678909631′ and the corporation can computationally verify that the number is indeed prime.
The current temperature in Berlin, on the other hand, is not self-verifying at all; it could be 11′C, but it could also just as easily be 17′C, or even 231′C; without outside data, all three values seem equally legitimate. Bitcoin is an interesting case to look at. In the Bitcoin system, transactions are partially self-verifying. The concept of a “correctly signed” transaction is entirely self-verifying; if the transaction’s signature passes the elliptic curve digital signature verification algorithm, then the transaction is valid.
However, there is something that is not self-verifying: time. A transaction cannot spend money before that money was received and, even more crucially, a transaction cannot spend money that has already been spent. Given two transactions spending the same money, either one could have theoretically come first; there is no way to self-verify the validity of one history over the other.
Solving The Time Problem
Bitcoin essentially solves the time problem with a computational democracy. If the majority of the network agrees that events happened in a certain order, then that order is taken as truth, and the incentive is for every participant in this democratic process to participate honestly; if any participant does not, then unless the rogue participant has more computing power than the rest of the network put together his own version of the history will always be a minority opinion, and thus rejected, depriving the miscreant of their block revenue.
In a more general case, the fundamental idea that we can gleam from the blockchain concept is this: we can use some kind of resource-democracy mechanism to vote on the correct value of some fact, and ensure that people are incentivized to provide accurate estimates by depriving everyone whose report does not match the “mainstream view” of the monetary reward.
Capturing Accurate Prices
The question is, can this same concept be applied elsewhere as well? One improvement to Bitcoin that many would like to see, for example, is a form of price stabilization; if Bitcoin could track its own price in terms of other currencies or commodities, for example, the algorithm could release more bitcoins if the price is high and fewer if the price is low – naturally stabilizing the price and reducing the massive spikes that the current system experiences.
However, so far, no one has yet figured out a practical way of accomplishing such a thing. But why not? The answer is one of precision. It is certainly possible to design such a protocol in theory: miners can put their own view of what the Bitcoin price is in each block, and an algorithm using that data could fetch it by taking the median of the last thousand blocks. Miners that are not within some margin of the median would be penalized.
However, the problem is that the miners have every incentive, and substantial wiggle room, to commit fraud. The argument is this: suppose that the actual Bitcoin price is 114 USD, and you, being a miner with some substantial percentage of network power (eg. 5%), know that there is a 99.99% chance that 113 to 115 USD will be inside the safe margin, so if you report a number within that range your blocks will not get rejected. What should you say that the Bitcoin price is? The answer is, something like 115 USD.
The reason is that if you put your estimate higher, the median that the network provides might end up being 114.05 BTC instead of 114 BTC, and the Bitcoin network will use this information to print more money – increasing your own future revenue in the process at the expense of existing savers. Once everyone does this, even honest miners will feel the need to adjust their estimates upwards to protect their own blocks from being rejected for having price reports that are too low.
At that point, the cycle repeats: the price is 114 USD, you are 99.99% sure that 114 to 116 USD will be within the safe margin, so you put down the answer of 116 USD. One cycle after that, 117 USD, then 118 USD, and before you know it the entire network collapses in a fit of hyperinflation.
Acting On The World
With some kind of democratic voting protocol, we reasoned above, it’s possible for a decentralized corporation to learn facts about the world. However, is it also possible to do the opposite? Is it possible for a corporation to actually influence its environment in ways more substantial than just sitting there and waiting for people to assign value to its database entries as Bitcoin does?
The answer is yes, and there are several ways to accomplish the goal. The first, and most obvious, is to use APIs. An API, or application programming interface, is an interface specifically designed to allow computer programs to interact with a particular website or other software program.
For example, sending an HTTP GET request tohttp://blockchain.info/address/1AEZyM6pXy1gxiqVsRLFENJLhDjbCj4FJz?format=json sends an instruction to blockchain.info’s servers, which then give you back a file containing the latest transactions to and from the Bitcoin address 1AEZyM6pXy1gxiqVsRLFENJLhDjbCj4FJz in a computer-friendly format.
Over the past ten years, as business has increasingly migrated onto the internet, the number of services that are accessible by API has been rapidly increasing. We have internet search, weather, online forums, stock trading, and more APIs are being created every year.
With Bitcoin, we have one of the most critical pieces of all: an API for money. However, there still remains one critical, and surprisingly mundane, problem: it is currently impossible to send an HTTP request in a decentralized way. The request must eventually be sent to the server all in one piece, and that means that it must be assembled in its entirety, somewhere.
For requests whose only purpose is to retrieve public data, like the blockchain query described above, this is not a serious concern; the problem can be solved with a voting protocol. However, if the API requires a private API key to access, as all APIs that automate activities like purchasing resources necessarily do, having the private key appear in its entirety, in plaintext, anywhere but at the final recipient, immediately compromises the private key’s privacy.
Requiring requests to be signed alleviates this problem; signatures, as we saw above, can be done in a decentralized way, and signed requests cannot be tampered with. However, this requires additional effort on the part of API developers to accomplish, and so far we are nowhere near adopting signed API requests as a standard.
Interacting With APIs
Even with that issue solved, another issue still remains. Interacting with an API is no challenge for a computer program to do; however, how does the program learn about that API in the first place? How does it handle the API changing? What about the corporation running a particular API going down outright, and others coming in to take its place? What if the API is removed, and nothing exists to replace it? Finally, what if the decentralized corporation needs to change its own source code?
These are problems that are much more difficult for computers to solve. To this, there is only one answer: rely on humans for support. Bitcoin heavily relies on humans to keep it alive; we saw in March 2013 how a blockchain fork required active intervention from the Bitcoin community to fix, and Bitcoin is one of the most stable decentralized computing protocols that can possibly be designed.
Even if a 51% attack happens, a blockchain fork splits the network into three, and a DDoS takes down the five major mining pools all at the same time, once the smoke clears some blockchain is bound to come out ahead, the miners will organize around it, and the network will simply keep on going from there. More complex corporations are going to be much more fragile; if a money-holding network somehow leaks its private keys, the result is that it goes bankrupt.
Hostile Takeovers
Alongside the “future proofing” problem, there is also another issue that needs to be dealt with: that of “hostile takeovers”. This is the equivalent of a 51% attack in the case of Bitcoin, but the stakes are higher. A hostile takeover of a corporation handling money means that the attacker gains the ability to drain the corporation’s entire wallet.
A hostile takeover of Decentralized Dropbox, Inc means that the attacker can read everyone’s files (although hopefully the files are encrypted, although in the case the attacker can still deny everyone their files). A hostile takeover of a decentralized web hosting company can lead to massive losses not just for those who have websites hosted, but also their customers, as the attacker gains the ability to modify web pages to also send off customers’ private data to the attacker’s own server as soon as each customer logs in.
How might a hostile takeover be accomplished? In the case of the 501-out-of-1000 private key situation, the answer is simple: pretend to be a few thousand different servers at the same time, and join the corporation with all of them. By forwarding communications through millions of computers infected by a botnet, this is easy to accomplish without being detected.
Then, once you have more than half of the servers in the network, you can immediately proceed to cash out. Fortunately, the presence of Bitcoin has created a number of solutions, of which the proof of work used by Bitcoin itself is only one.
Because Bitcoin is a perfect API for money, any kind of protocol involving monetary scarcity and incentives is now available for computer networks to use. Proof of stake, requiring each participating node to show proof that it controls, say, 100 BTC is one possible solution; if that is done, then implementing a hostile takeover would require more resources than all of the legitimate nodes committed together.
The 100 BTC could even be moved to a multisignature address partially controlled by the network as a surety bond, both discouraging nodes from cheating and giving their owners a great incentive to act and even get together to keep the corporation alive.
Conclusion
In conclusion, we have seen that very significant challenges still remain before any kind of decentralized corporation can be viable. The problem will likely be solved in layers. First, with the advent of Bitcoin, a self-support
