In a recent blog post to GavinTech, Gavin Andresen admitted that he has recently been thinking about ethereum “a bit.” Ethereum is a Bitcoin 2.0 project that is creating “a revolutionary new platform for applications.” Vitalik Buterin, one of ethereum’s founders, was recently awarded the Thiel Fellowship, a $100,000 fellowship awarded to 20 bright entrepreneurs around the world under the age of 20. Gavin revealed that he thinks some parts of ethereum, such as the new proof-of-work and new currency, are needlessly re-engineered while admitting particular interest in the development of smart contracts. However, Gavin Andresen doesn’t believe that Bitcoin 2.0 needs to be as complicated as ethereum is making it out to be. He went as far as to predict that ethereum would either radically reduce their scope or forever play whack-a-mole with security, something Gavin has years of first-hand experience with. Gavin believes that Bitcoin 2.0 can be built on Bitcoin, not elsewhere:
“Bitcoin already provides a global currency and distributed ledger– there is no need to re-invent those wheels. Combining real-world information with Bitcoin is where things start to get really interesting.”
Smart contracts are “a contract that has funds associated with it, arbitrary code and state. Verified by the network instead of a central authority. And with transactions as a pseudo-anonymous way of triggering evaluation of the contract, paying funds held in escrow with the contract, and updating its state.” The creation of a decentralized, or at least a distributed, and reliable system to execute and keep track of contracts is the holy grail of our time. Contracts of this nature would be crucial in the creation and operations of a Distributed Autonomous Corporation (DAC). In an interview with The Economist earlier this year, Bitcoin developer Mike Hearn posited that there are not currently any DACs in existence, though some think that Bitcoin might be viewed as the closest thing. Furthermore, he went on to speculate that the first DAC would be some sort of “distributed Dropbox,” something many groups are trying to do with varying degrees of success.
One issue that blockchain-enforced contracts runs into is requiring non-blockchain data from an outside (read: centralized) source. Ethereum’s whitepaper acknowledges this flaw of requiring “data outside the blockchain” and they admit that “a trusted source is still needed to provide the price ticker.” Even before the manifestation of smart trustless contracts, it seems that trust in a centralized source of data is again haunting developers. One solution that has been presented again and again, most recently by Gavin himself, is to move “from one trusted source to M-of-N semi-trusted sources.” M-of-N trusted sources avoids the issues that could arise if one centralized source of information that the blockchain-enforced contract required stopped being broadcasted. Other potential solutions to this issue that are currently under development include Truthcoin or Reality Keys. Furthering on this concept, Gavin believes that the distributed semi-trust M-of-N system can be extended to create actual enforcers of the contracts that would then interface with the Bitcoin blockchain via multi-sig transactions to create Bitcoin 2.0 without ethereum.
…imagine that there are semi-trusted ‘oracles‘ that compete to be the most reliable and trustworthy verifiers of contracts. People involved in contracts choose N of them, and then require that contract conditions be validated by one or more of them before the contract pays out. Pick more than one so no single oracle can steal the contract’s funds, but less than N in case some of them go out of business or just aren’t around to validate contracts when it is time for the contract to pay out.
“These oracles need an agreed-upon, machine-readable contract language, but that shouldn’t be hard.” Copying most of the ethereum contract language design (and maybe re-using lots of their code) might be a good way to go.
Gavin goes on:
They also need a way to store some value in escrow, associated with the contract, so that M-of-N of them must agree to any release of funds. Bitcoin multi-signature transactions could be used for that:
1. Whoever is involved in the contract gives the contract code to each of the N oracles and gets back N public keys.
2. The oracles would store the contract code and the private key, and should be willing to give out the public key to anybody who knows the contract code.
3. Anybody can then add funds to the contract by sending bitcoins into the M-of-N multisig made up of the public keys. And maybe associate some data with the escrowed funds by hashing it and include a prune-able OP_RETURN output with the hash.
Additional security and anti-spam measures should be taken to reduce the efficacy of denial-of-service-attacks against semi-trusted oracles. Gavin posits that “oracles could require a small up-front payment to establish a contract.” Also, requiring that escrow disbursements send a small payment to the oracle’s public key will both provide security and a business model for oracles. Conceivably, for some contracts, even a large cost to attempt such an attack on X amount of oracles might not be enough. All the steps that an oracle takes in verification and execution should be independently verifiable by an observer with knowledge of the contract code. Gavin himself admits that his outline is “cheating” when compared to the ultimate goal of actual decentralization; however, it is an improvement.