Summary (tl;dr)
- Open Source guarantees trust and freedom, until it's run as a service
- "Open Execution" is a guarantee that a service will run according to the published source code
- Ethereum built an Open Execution solution, inspired by Bitcoin's Blockchain
- Expect service clients to demand Open Execution in high-trust services
Open Source
Open Source dominates the web. When developers choose which tools to use, we prefer the trust and freedom delivered by projects like GNU/Linux and Apache, the most used software in their category. We gain trust in open source projects through community inspection of the source. Freedom derives from the ability to fork at any time; developers never need to be afraid of being locked in to a vendor's choices. Unfortunately, these attributes are lost when libraries running locally are converted into web services. Developers can't build on top of those services with the trust and freedom they expect and deserve.
Trust is especially important in a few verticals, like financial services. If you want to offer a financial product today, you need to 1) use only tools and services you trust supremely and 2) slowly and expensively build trust in your brand. If another developer wants to build on top of yours, they need to go through the same long, slow process. Government services also demand a lot of trust. When the government counts your electronically submitted votes, you need to know it was not manipulated. The engineering community can help solve these problems, using the concept of Open Execution.
Open Execution
Open Execution is the guarantee that a caller of a service can know the exact outcome of a service, given its state and inputs. Further, the caller should understand the constraints of a service - what a service provider has restricted themselves from doing.
For example, let's say that someone wants to write a generic vote counting service. Users would want to know that their vote is counted, and that no one's vote is counted twice. They would also want to know that the service owner couldn't manually manipulate the vote totals. They would want to know that access to voting is only granted to those who are authorized to vote. Open Execution could make these guarantees, assuming that the user is code literate enough to validate the source of the service.
In another example, imagine a tiny escrow service that receives digital ownership of cash and stock certificates. After both arrive, the service swaps the stock and cash, then halts. Users want to know that the cash and stock are either ultimately refunded or swapped, with no possible alternative outcomes, like the service owner running off with both. Again, by reading the source of an Open Execution service, these things can be guaranteed.
The difficulty comes in actually building a system that could host these services. One possible implementation is a network that: provides the full source of a service, runs the service locally to the client, broadcasts the new service state for all other clients, achieves consensus among clients, and guarantees that the source of the service won't change.¹
If we succeed at building this vision, a wide variety of services enabled by Open Execution will become possible. It will affect how we buy, sell, and borrow goods like cars, stocks, houses, movie tickets, gift certificates. How we govern business and people will change, where the right to vote in private and public elections is secured by an Open Execution service.
Bitcoin validates an Open Execution mechanism
Perhaps surprisingly, the tools needed to build Open Execution have been around for years. In 2009, they were used to build Bitcoin, which is a special-case version of Open Execution. For Bitcoin to work, it's critical that the Open Execution guarantees hold: the service owners can't run away with your bitcoin, no one else can send your bitcoin to a third party, users can't invent bitcoin from thin air, and they cannot spend the same bitcoin twice.
For those interested in the mechanics, check out the whitepaper. Here is a shallow introduction, but it takes many readings for most people to grok the concept. Feel free to skip this paragraph for now. Bitcoin keeps track of which private key has ownership of which bitcoin. The protocol allows that key, and no other, to transfer bitcoin ownership to another account. It is open source and cannot change without shared agreement of the Bitcoin validators (known as "miners" in the community). All full Bitcoin clients run every transaction locally. Bitcoin miners sign a series of batched transactions known as the Blockchain. The block at the tip of the chain represents the latest state as proposed by one miner. A block deep in the chain shows broad consensus across miners that the transactions in that block followed the Bitcoin protocol.
Bitcoin was a fascinating breakthrough experiment. The Blockchain is the most important invention to be validated by it. People have entrusted billions of dollars worth of bitcoin to the Blockchain. Bitcoin has proven itself as an excellent solution for guaranteeing the execution of a predefined service: digital currency transfer. It is not ideal for broader use as an Open Execution system, though. Creation of new services on top of the protocol is cumbersome, and often practically impossible.
Ethereum
Only recently, a compelling way has become available to run generalized Open Execution. The best known example is Ethereum. "Best" known is relative of course; many software engineers have never heard of it. It just went production-ready, on Pi Day 2016. Ethereum is a single, worldwide state machine, replicated across many computers. It achieves consensus using a Blockchain mechanism, much like the one pioneered by Bitcoin. Anyone can write and publish a service² to the Ethereum network, using a language with easy primitives for authentication and financial transfer. At its core is a cryptocurrency called ether, which is used to incentivize the replicating machines to run your service. You can also send ether directly in a contract, with a line of code: receiving_address.send(1 ether). The fee paid for running a service is scaled to the number and type of instructions run. You can think of it like Amazon Web Services, but instead of paying by the hour for a server, you pay per arithmetic operation and disk store. To write a voting or escrow service on Ethereum as described above would be trivial, perhaps tens of lines of code.³
There is a downside to Open Execution - it is expensive. We can expect the cost to push businesses to "open execute" only the components that require the most trust and freedom, leaving the rest of the product on traditional web services. Products will look mostly the same to end users, except they have to run a modified browser⁴ to get the Open Execution guarantees. The expense of Open Execution is both computational and financial. Computationally, each instruction is run by every miner in order to build the Blockchain. The Blockchain is not a good place to run a 3D graphics engine. Financially, each instruction costs a marginal amount, much more than the electricity cost of executing local code. For now, monolithic products that fully embrace Ethereum, like Augur and EtherEx, are fascinating showcases. But the computational and financial constraints will push us towards microservices. Don't expect to replace Ubuntu with an Ethereum solution. Do expect Venmo to integrate Ethereum services for deposits, withdrawals, and shared fund management.
The Future of Open Execution
Today, we surrender to the inability to personally validate services. When users realize that it's possible to get a guarantee that services will run as promised, we will demand it. Why would we settle for a financial transaction that could be stolen or a voting mechanism that could be manipulated? Technically sophisticated people know to verify a website is using https before submitting a credit card. In the future, they'll know to verify that a service is Open Execution before they send money or vote.
Ethereum is new enough that I'm hesitant to say that it is the answer to Open Execution that we'll be using in 10-20 years. It certainly could be. Right now, it is fascinating to play with and understand. I am working on a future article to dive into the mechanics of how Ethereum delivers on the promises of Open Execution.
Thanks to Shira Carver, Cesar Toscano, Robert Toscano, Nicolas Toscano, and Gordon Wintrob for your thoughtful feedback on early drafts!
Footnotes:
- Okay - we need to do a few more things, like harden our compiler against malware, but that takes much longer than a single post to cover.
- I'm playing fast and loose with terminology here in order to not distract from the point. In Ethereum, a service is known as a "contract". The fee used to pay for running a service is known as "gas".
- Although the code is simple, it won't look simple until you understand the Ethereum system more deeply. A great place to start is the tutorial for the primary Ethereum language, Solidity.
- The Ethereum Foundation provides the Mist browser. Among other things, it runs a local Ethereum client connected to the Ethereum network, and signs requests locally before initiating a service.