SchellingCoin: A Minimal-Trust Universal Data Feed

One of the main applications of Ethereum that people have been interested in is financial contracts and derivatives. Although financial derivatives have acquired a reputation as a highly risky and destabilizing device with the sole function of enriching speculators, the underlying concept in fact has a number of legitimate uses, some of which actually help people protect themselves against the volatility of financial markets.

The main idea here is called “hedging”, and is best explained in the context of Bitcoin, where ordinary businesses and individuals with no desire to take massive risks end up needing to deal with high volumes of a risky asset (BTC). Hedging works as follows. Suppose that Jane is a business owner who accepts Bitcoin for payments and uses it to pay employees, and on average she expects that she will need to keep 100 BTC on hand at any time. Sometimes, this amount might change; it could be 20 BTC or it could be 160 BTC. However, she is not at all excited about the prospect of seeing her BTC drop 23% in value in a single day and losing several months worth of salary. Currently, the “standard” solution is for Jane to set up her business to accept payments via BitPay or Coinbase, paying a 1% fee to have the bitcoins instantly converted into money in her bank account. When she wants to pay BTC, she would need to buy the bitcoins back and send them out, paying 1% again (if not more).

Hedging provides a different approach. Instead of constantly trading BTC back and forth, Jane creates an account on a financial derivatives market, and enters into a contract for difference. In this CFD, Jane agrees to put in $20000 worth of BTC, and get back (in BTC) $20000 plus $100 for every dollar that the BTC price drops. If the BTC price rises, she loses $100 per dollar. Thus, if the value of one bitcoin decreases by $45, Jane would lose $4500 in the value of her bitcoins, but she would gain $4500 in the CFD. Of course, the money does not come out of nowhere; on the other side of the contract is a speculator, betting that the price of BTC will go up, and if it does then Jane will gain in the value of BTC and lose in the CFD, and the speculator would gain in the CFD.

Given this basic ingredient, Jane has three strategies for using it to manage risk:

  1. She can keep the CFD at $100 to $1 forever, and if her exposure is off by some amount then she can take that smaller risk.
  2. Jane can have a bot constantly adjust the CFD to her supply of BTC on hand, paying some fees for this but not nearly as much as with Bitpay and Coinbase.
  3. Thanks to the magic of Ethereum contracts, she can make a CFD that automatically listens to her account balance and retargets itself to her balance, forcing the speculator to assume whatever exposure she needs (within limits), and the speculator will participate in many such contracts to even out their exposure

So how do we do CFDs? In Ethereum, it’s easy; just write a contract to do what you want. Here, I provide a specialized version of a CFD that I am calling a “hedging contract”, which acts as a pure self-contained store of value: you put 1000 ether in, you get the same USD value of ether out (unless the value of ether drops so much that the entire contract doesn’t have enough to cover you, in which case you gain the right to immediately withdraw everything and enter into a new hedging contract):

if contract.storage[1000] == 0:
    if tx.value < 1000 * 10^18:
        stop
    contract.storage[1000] = 1
    contract.storage[1001] = 998 * block.contract_storage(D)[I]
    contract.storage[1002] = block.timestamp + 30 * 86400
    contract.storage[1003] = tx.sender
else:
    ethervalue = contract.storage[1001] / block.contract_storage(D)[I]
    if ethervalue >= 5000:
        mktx(contract.storage[1003],5000 * 10^18,0,0)
    else if block.timestamp > contract.storage[1002]:
        mktx(contract.storage[1003],ethervalue * 10^18,0,0)
        mktx(A,(5000 - ethervalue) * 10^18,0,0)

If you understand ETH-HLL, you can figure that example out, and if you can’t it basically does what the description says (the speculator puts up the contract with 4000 ETH, the counterparty enters into it with 1000 ETH, and there’s an expiry date after 30 days after which anyone can “ping” the contract to return $x worth of ETH to the counterparty and the rest to the speculator). We’ll release better ETH-HLL guides soon, but for now understanding the fine details of the contract is not necessary.

However, all of this has a problem: it requires some trusted source from which to grab the price of ETH/USD. This is much less of a problem than the other approach, involving trusted to create USD-backed cryptographic assets, because it requires much less infrastructure and the incentive to cheat is much smaller, but from a cryptographic purist standpoint it’s not perfect. The fundamental problem is this: cryptography alone has no way of finding out that much about the outside world. You can learn a bit about computational power through proof of work, and you can get some market data between one crypto-asset and another by having an on-chain market, but ultimately there is no term in mathematical algorithms for something like the temperature in Berlin. There is no inherent way cryptography can tell you whether the correct answer is 11’C, 17’C or 2725’C; you need human judgement for that (or thermometers, but then you need human judgement to determine which thermometers are trustworthy).

Schelling time

Here, I provide a mechanism that allows you to create a decentralized data feed. The economics of it are not perfect, and if large collusions are possible then it may break down, but it is likely close to the best that we can do. In this case, we will use the price of ETH/USD as an example; the temperature in Berlin, the world GDP or even the result of a computation that does not lend itself to efficient verifiability can also be used.

The mechanism relies on a concept known as Schelling points. The way it works is at follows. Suppose you and another prisoner are kept in separate rooms, and the guards give you two identical pieces of paper with a few numbers on them. If both of you choose the same number, then you will be released; otherwise, because human rights are not particularly relevant in the land of game theory, you will be thrown in solitary confinement for the rest of your lives. The numbers are as follows:

    14237 59049 76241 81259 90215 100000 132156 157604

Which number do you pick? In theory, these are all arbitrary numbers, and you will pick a random one and have a probability of 1/8 of choosing the same one and getting out of prison. In practice, however, the probability is much higher, because most people choose 100000. Why 100000? Because each prisoner believes that the number 100000 is somehow “special”, and each prisoner believes that the other believes that 100000 is “special”, and so forth infinitely recursively – an instance of common knowledge. Thus each prisoner, believing that the other is more likely to choose 100000, will choose 100000 themselves. Obviously, this is an infinitely recursive chain of logic that’s not ultimately “backed” by anything except itself, but cryptocurrency users reading this article should by now be very comfortable with relying on such concepts.

This mechanism is how SchellingCoin works. The basic protocol is as follows:

1. During an even-numbered block, all users can submit a hash of the ETH/USD price together with their Ethereum address
2. During the block after, users can submit the value whose hash they provided in the previous block.
3. Define the “correctly submitted values” as all values N where H(N+ADDR) was submitted in the first block and N was submitted in the second block, both messages were signed/sent by the account with address ADDR and ADDR is one of the allowed participants in the system.
4. Sort the correctly submitted values (if many values are the same, have a secondary sort by H(N+PREVHASH+ADDR) where PREVHASH is the hash of the last block)
5. Every user who submitted a correctly submitted value between the 25th and 75th percentile gains a reward of N tokens (which we’ll call “schells”)

The protocol does not include a specific mechanism for preventing sybil attacks; it is assumed that proof of work, proof of stake or some other similar solution will be used.

So why does this work? Essentially, for the same reason why the prisoner example above worked; the truth is arguably the most powerful Schelling point out there. Everyone wants to provide the correct answer because everyone expects that everyone else will provide the correct answer and the protocol encourages everyone to provide what everyone else provides. Criminal investigators have been using SchellingCoin for centuries, putting prisoners into separate rooms and asking them all for their stories on what happened at a given event, relying on the fact that it’s easy to be consistent with many other people if you tell the truth but nearly impossible to coordinate on any specific lie.

Problems and Limits

What are the vulnerabilities? In general, collusion attacks. Most trivially, if any entity controls more than 50% of all votes, they can basically unilaterally set the median to whatever they want. On the other hand, if there are a near-infinite number of discrete non-communicating entities, then each individual entity has essentially zero impact on the result; realistically, there will be many entities giving the exact same value so there will not even be an opportunity to adjust the result slightly by voting falsely.

However, in the middle it gets hazy. If one entity controls 49% of votes, they can all pre-announce that they will vote for some false value, and others will also go with that value out of fear that everyone else will and if they don’t they will be left out. But here is the really fun part: even if one entity controls 1% of votes, if that entity pre-announces some false value that they will vote for and announces that they will give 0.00001 schells to whoever votes for that value, then there are now two Schelling points: the truth and the entity’s value. However, the entity’s value contains an incentive to vote for it, so theoretically that Schelling point is superior and everyone will go for it instead.

In practice, however, this is obviously absurd, in the same category as the famous result that in a prisoner’s dilemma with a preset finite number of rounds the optimal strategy is to cheat every round; the argument is that on the last round there’s no room to punish cheating, so the incentive is to cheat, on the second last round both players know that the other will cheat on the next round for that reason anyway so the incentive is to cheat, and so on recursively to the first round. In practice, people are not capable of processing arbitrary-depth recursion, and in this case in practice there is a massive coordination problem in unseating the dominant Schelling point, which only gets worse because everyone that benefits from the SchellingCoin has an incentive to attempt to censor any communication of an attempt to disrupt it. Thus, a 49% coalition will likely be able to break SchellingCoin, but a 1% coalition will not. Where is the middle ground? Perhaps only time will tell.

Another potential concern is micro-cheating. If the underlying datum is a value that frequently makes slight changes, which the price is, then if most participants in the SchellingCoin are simultaneously participants in a system that uses that SchellingCoin, they may have the incentive to slightly tweak their answers in one direction, trying to keep within the 25/75 boundary but at the same time push the median up (or down) very slightly to benefit themselves. Other users will predict the presence of micro-disruption, and will thus tweak their answers in that direction themselves to try to stay within the median. Thus, if people think that micro-cheating is possible, then micro-cheating may be possible, and if they do not think so then it will not be – a common result in Schelling point schemes.

There are two ways of dealing with the problem. First, we can try to define the value very unambiguously – eg. “the last ask price of ETH/USD on exchange XYZ at a time HH:MM:00”, so that a very large portion of answers end up exactly the same and there is no possibility to move the median at all by micro-cheating. However, this introduces centralization in the definition, so needs to be handled carefully. An alternative is to be coarse-grained, defining “the price of ETH/USD rounded to two significant digits”. Second, we can simply work hard to make the underlying system for picking users avoid biases, both by being decentralization-friendly (ie. proof-of-stake over proof-of-work) and by including users who are likely to have incentives in opposite directions.

Thus, if we combine SchellingCoin and contracts for difference, what we have is a cryptographic asset that I have previously identified as a holy grail of cryptocurrency: an asset which maintains a stable value and is simultaneously trust-free. Trust-free is of course a relative term; given the current distribution of mining pools Bitcoin’s “trust-free” voting is far from completely free of any trust, but the challenge is to make the protocol as decentralized and future-proof as we can. Many of these “holy grails” are not reachable perfectly; even the ones that we think we’ve already reached we often really haven’t (eg. decentralized sybil attack resistance), but every step toward the ultimate goal counts.

Mining for Schells

The interesting part about SchellingCoin is that it can be used for more than just price feeds. SchellingCoin can tell you the temperature in Berlin, the world’s GDP or, most interestingly of all, the result of a computation. Some computations can be efficiently verified; for example, if I wanted a number N such that the last twelve digits of 3N are 737543007707, that’s hard to compute, but if you submit the value then it’s very easy for a contract or mining algorithm to verify it and automatically provide a reward. Other computations, however, cannot be efficiently verified, and most useful computation falls into the latter category. SchellingCoin provides a way of using the network as an actual distributed cloud computing system by copying the work among N parties instead of every computer in the network and rewarding only those who provide the most common result.

For added efficiency, a more intricate multi-step protocol can have one node do the computation and only use SchellingCoin to “spot-check” only a random 1% of the work, allowing for perhaps less than 2x cryptographic overhead. A deposit requirement and harsh penalties for providing an answer that turns out not to pass scrutiny can be used to limit fraud, and another option is to let anyone redo the work and “suggest” a verification index to the network to apply SchellingCoin on if they discover any faults.

The protocol described above is not a new idea; as I mentioned earlier, it is simply a generalization of a centuries-old criminal investigation practice, and in fact Bitcoin’s mining algorithm basically is a SchellingCoin on the order of transactions. But the idea can potentially be taken much further, provided that the flaws prove to be surmountable. SchellingCoin for ETH/USD can be used to provide a decentralized dollar; SchellingCoin for computation can be used to provide distributed AWS (albeit with no privacy, but we can wait for efficient obfuscation for that).

Thanks to:

  • Neal Koblitz, for suggesting the idea of using a spot checking repeated computation approach to provide a “useful proof of work”
  • David Friedman, for introducing me to the concept of Schelling points in his “positive account of property rights”
  • Thomas Schelling, for coming up with the concept in the first place
  • An individual I talked to two months ago whose identity I unfortunately forgot for providing the idea of incorporating Schelling schemes into Ethereum

The Latest EVM: “Ethereum Is A Trust-Free Closure System”

In the past two weeks our lead C++ developer, Gavin Wood, and myself have been spending a lot of time meeting the local Ethereum community in San Francisco and Silicon Valley. We were very excited to see such a large amount of interest in our project, and the fact that after only two months we have a meetup group that comes together every week, just like the Bitcoin meetup, with over thirty people attending each time. People in the community are taking it upon themselves to make educational videos, organize events and experiment with contracts, and one person is even independently starting to write an implementation of Ethereum in node.js. At the same time, however, we had the chance to take another look at the Ethereum protocols, see where things are still imperfect, and agree on a large array of changes that will be integrated, likely with only minimal modification, into the PoC 3.5 clients.

Transactions as Closures

In ES1 and ES2, the MKTX opcode, which allowed contracts to send transactions triggering other contracts, had one very non-intuitive feature: although one would naturally expect MKTX to be like a function call, processing the entire transaction immediately and then continuing on with the rest of the code, in reality MKTX did not work this way. Instead, the execution of the call is deferred toward the end – when MKTX was called, a new transaction would be pushed to the front of the transaction stack of the block, and when the execution of the first transaction ends the execution of the second transaction begins. For example, this is something that you might expect to work:

    x = array()
    x[0] = "george"
    x[1] = MYPUBKEY

    mktx(NAMECOIN,10^20,x,2)

    if contract.storage(NAMECOIN)["george"] == MYPUBKEY:
        registration_successful = 1
    else:
        registration_successful = 0

    // do more stuff...

Use the namecoin contract to try to register “george”, then use the EXTRO opcode to see if the registration is successful. This seems like it should work. However, of course, it doesn’t.

In EVM3 (no longer ES3), we fix this problem. We do this by taking an idea from ES2 – creating a concept of reusable code, functions and software libraries, and an idea from ES1 – keeping it simple by keeping code as a sequential set of instructions in the state, and merging the two together into a concept of “message calls”. A message call is an operation executed from inside a contract which takes a destination address, an ether value, and some data as input and calls the contract with that ether value and data, but which also, unlike a transaction, returns data as an output. There is thus also a new RETURN opcode which allows contract execution to return data.

With this system, contracts can now be much more powerful. Contracts of the traditional sort, performing certain data upon receiving message calls, can still exist. But now, however, two other design patterns also become possible. First, one can now create a proprietary data feed contract; for example, Bloomberg can publish a contract into which they push various asset prices and other market data, and include in its contract an API that returns the internal data as long as the incoming message call sends at least 1 finney along with it. The fee can’t go too high; otherwise contracts that fetch data from the Bloomberg contract once per block and then provide a cheaper passthrough will be profitable. However, even with fees equal to the value of perhaps a quarter of a transaction fee, such a data-feeding business may end up being very viable. The EXTRO opcode is removed to facilitate this functionality, ie. contracts are now opaque from inside the system, although from the outside one can obviously simply look at the Merkle tree.

Second, it is possible to create contracts that represent functions; for example, one can have a SHA256 contract or an ECMUL contract to compute those respective functions. There is one problem with this: twenty bytes to store the address to call a particular function might be a bit much. However, this can be solved by creating one “stdlib” contract which contains a few hundred clauses for common functions, and contracts can store the address of this contract once as a variable and then access it many times simply as “x” (technically, “PUSH 0 MLOAD”). This is the EVM3 way of integrating the other major idea from ES2, the concept of standard libraries.

Ether and Gas

Another important change is this: contracts no longer pay for contract execution, transactions do. When you send a transaction, you now need to include a BASEFEE and a maximum number of steps that you’re willing to pay for. At the start of transaction execution, the BASEFEE multiplied by the maxsteps is immediately subtracted from your balance. A new counter is then instantiated, called GAS, that starts off with the number of steps that you have left. Then, transaction execution starts as before. Every step costs 1 GAS, and execution continues until either it naturally halts, at which point all remaining gas times the provided BASEFEE is returned to the sender, or the execution runs out of GAS; in that case, all execution is reverted but the entire fee is still paid.

This approach has two important benefits. First, it allows miners to know ahead of time the maximum quantity of GAS that a transaction will consume. Second, and much more importantly, it allows contract writers to spend much less time focusing on making the contract “defensible” against dummy transactions that try to sabotage the contract by forcing it to pay fees. For example, consider the old 5-line Namecoin:

    if tx.value < block.basefee * 200:
        stop
    if !contract.storage[tx.data[0]] or tx.data[0] = 100:
        contract.storage[tx.data[0]] = tx.data[1]

Two lines, no checks. Much simpler. Focus on the logic, not the protocol details. The main weakness of the approach is that it means that, if you send a transaction to a contract, you need to precalculate how long the execution will take (or at least set a reasonable upper bound you’re willing to pay), and the contract has the power to get into an infinite loop, use up all the gas, and force you to pay your fee with no effect. However, this is arguably a non-issue; when you send a transaction to someone, you are already implicitly trusting them not to throw the money into a ditch (or at least not complain if they do), and it’s up to the contract to be reasonable. Contracts may even choose to include a flag stating how much gas they expect to require (I hereby nominate prepending “PUSH 4 JMP ” to execution code as a voluntary standard)

There is one important extension to this idea, which applies to the concept of message calls: when a contract makes a message call, the contract also specifies the amount of gas that the contract on the other end of the call has to use. Just as at the top level, the receiving contract can either finish execution in time or it can run out of gas, at which point execution reverts to the start of the call but the gas is still consumed. Alternatively, contracts can put a zero in the gas fields; in that case, they are trusting the sub-contract with all remaining gas. The main reason why this is necessary is to allow automatic contracts and human-controlled contracts to interact with each other; if only the option of calling a contract with all remaining gas was available, then automatic contracts would not be able to use any human-controlled contracts without absolutely trusting their owners. This would make m-of-n data feed applications essentially nonviable. On the other hand, this does introduce the weakness that the execution engine will need to include the ability to revert to certain previous points (specifically, the start of a message call).

The New Terminology Guide

With all of the new concepts that we have introduced, we have standardized on a few new terms that we will use; hopefully, this will help clear up discussion on the various topics.

  • External Actor: A person or other entity able to interface to an Ethereum node, but external to the world of Ethereum. It can interact with Ethereum through depositing signed Transactions and inspecting the block-chain and associated state. Has one (or more) intrinsic Accounts.
  • Address: A 160-bit code used for identifying Accounts.
  • Account: Accounts have an intrinsic balance and transaction count maintained as part of the Ethereum state. They are owned either by External Actors or intrinsically (as an indentity) an Autonomous Object within Ethereum. If an Account identifies an Autonomous Object, then Ethereum will also maintain a Storage State particular to that Account. Each Account has a single Address that identifies it.
  • Transaction: A piece of data, signed by an External Actor. It represents either a Message or a new Autonomous Object. Transactions are recorded into each block of the block-chain.
  • Autonomous Object: A virtual object existant only within the hypothetical state of Ethereum. Has an intrinsic address. Incorporated only as the state of the storage component of the VM.
  • Storage State: The information particular to a given Autonomous Object that is maintained between the times that it runs.
  • Message: Data (as a set of bytes) and Value (specified as Ether) that is passed between two Accounts in a perfectly trusted way, either through the deterministic operation of an Autonomous Object or the cryptographically secure signature of the Transaction.
  • Message Call: The act of passing a message from one Account to another. If the destination account is an Autonomous Object, then the VM will be started with the state of said Object and the Message acted upon. If the message sender is an Autonomous Object, then the Call passes any data returned from the VM operation.
  • Gas: The fundamental network cost unit. Paid for exclusively by Ether (as of PoC-3.5), which is converted freely to and from Gas as required. Gas does not exist outside of the internal Ethereum computation engine; its price is set by the Transaction and miners are free to ignore Transactions whose Gas price is too low.

Long Term View

Soon, we will release a full formal spec of the above changes, including a new version of the whitepaper that takes into account all of these modifications, as well as a new version of the client that implements it. Later on, further changes to the EVM will likely be made, but the ETH-HLL will be changed as little as possible; thus, it is perfectly safe to write contracts in ETH-HLL now and they will continue to work even if the language changes.

We still do not have a final idea of how we will deal with mandatory fees; the current stop-gap approach is now to have a block limit of 1000000 operations (ie. GAS spent) per block. Economically, a mandatory fee and a mandatory block limit are essentially equivalent; however, the block limit is somewhat more generic and theoretically allows a limited number of transactions to get in for free. There will be a blog post covering our latest thoughts on the fee issue shortly. The other idea that I had, stack traces, may also be implemented later.

In the long term, maybe even beyond Ethereum 1.0, perhaps the holy grail is attack the last two “intrinsic” parts of the system, and see if we can turn them too into contracts: ether and ECDSA. In such a system, ether would still be the privileged currency in the system; the current thinking is that we will premine the ether contract into the index “1” so it takes nineteen fewer bytes to use it. However, the execution engine would become simpler since there would no longer be any concept of a currency – instead, it would all be about contracts and message calls. Another interesting benefit is that this would allow ether and ECDSA to be decoupled, making ether optionally quantum-proof; if you want, you could make an ether account using an NTRU or Lamport contract instead. A detriment, however, is that proof of stake would not be possible without a currency that is intrinsic at the protocol level; that may be a good reason not to go in this direction.

The Question of Mining

There are a lot of interesting changes to the Ethereum protocol that are in the works, which will hopefully improve the power of the system, add further features such as light-client friendliness and a higher degree of extensibility, and make Ethereum contracts easier to code. Theoretically, none of these changes are necessary; the Ethereum protocol is fine as it stands today, and can theoretically be released as is once the clients are further built up somewhat; rather, the changes are there to make Ethereum better. However, there is one design objective of Ethereum where the light at the end of the tunnel is a bit further: mining decentralization. Although we always have the backup option of simply sticking with Dagger, Slasher or SHA3, it is entirely unclear that any of those algorithms can truly remain decentralized and mining pool and ASIC-resistant in the long term (Slasher is guaranteed to be decentralized because it’s proof of stake, but has its own moderately problematic flaws).

The basic idea behind the mining algorithm that we want to use is essentially in place; however, as in many cases, the devil is in the details.

This version of the Ethereum mining algorithm is a Hashcash-based implementation, similar to Bitcoin’s SHA256 and Litecoin’s scrypt; the idea is for the miner to repeatedly compute a pseudorandom function on a block and a nonce, trying a different nonce each time, until eventually some nonce produces a result which starts with a large number of zeroes. The only room to innovate in this kind of implementation is changing the function; in Ethereum’s case, the rough outline of the function, taking the blockchain state (defined as the header, the current state tree, and all the data of the last 16 blocks), is as follows:

1. Let `h[i] = sha3(sha3(block_header) ++ nonce ++ i)` for `0 <= i <= 15`
2. Let `S` be the blockchain state 16 blocks ago.
3. Let `C[i]` be the transaction count of the block `i` blocks ago. Let `T[i]` be the `(h[i] mod C[i])`th transaction from the block `i` blocks ago.
4. Apply `T[0]`, `T[1]` … `T[15]` sequentially to `S`. However, every time the transaction leads to processing a contract, (pseudo-)randomly make minor modifications to the code of all contracts affected.
5. Let `S'` be the resulting state. Let `r` be the sha3 of the root of `S'`.

If `r <= 2^256 / diff`, then `nonce` is a valid nonce.

To summarize in non-programmatic language, the mining algorithm requires the miner to grab a few random transactions from the last 16 blocks, run the computation of applying them to the state 16 blocks ago with a few random modifications, and then take the hash of the result. Every new nonce that the miner tries, the miner would have to repeat this process over again, with a new set of random transactions and modifications each time.

The benefits of this are:

1. It requires the entire blockchain state to mine, essentially requiring every miner to be a full node. This helps with network decentralization, because a larger number of full nodes exist.
2. Because every miner is now required to be a full node, mining pools become much less useful. In the Bitcoin world, mining pools serve two key purposes. First, pools even out the mining reward; instead of every block providing a miner with a 0.0001% chance of mining a $16,000 block, a miner can mine into the pool and the pool gives the miner a 1% chance of receiving a payout of $1.60. Second, however, pools also provide centralized block validation. Instead of having to run a full Bitcoin client themselves, a miner can simply grab block header data from the pool and mine using that data without actually verifying the block for themselves. With this algorithm, the second argument is moot, and the first concern can be adequately met by peer-to-peer pools that do not give control of a significant portion of network hashpower to a centralized service.
3. It's ASIC-resistant almost by definition. Because the EVM language is Turing-complete, any kind of computation that can be done in a normal programming language can be encoded into EVM code. Therefore, an ASIC that can run all of EVM is by necessity an ASIC for generalized computation – in other words, a CPU. This also has a Primecoin-like social benefit: effort spent toward building EVM ASICs also havs the side benefit of building hardware to make the network faster.
4. The algorithm is relatively computationally quick to verify, although there is no “nice” verification formula that can be run inside EVM code.

However, there are still several major challenges that remain. First, it is not entirely clear that the system of picking random transactions actually ends up requiring the miner to use the entire blockchain. Ideally, the blockchain accesses would be random; in such a setup, a miner with half the blockchain would succeed only on about 1 in 216 nonces. In reality, however, 95% of all transactions will likely use 5% of the blockchain; in such a system, a node with 5% of the memory will only take a slowdown penalty of about 2x.

Second, and more importantly, however, it is difficult to say how much an EVM miner could be optimized. The algorithm definition above asks the miner to “randomly make minor modifications” to the contract. This part is crucial. The reason is this: most transactions have results that are independent of each other; the transactions might be of the form “A sends to B”, “C sends to D”, “E sends to contract F that affects G and H”, etc, with no overlap. Hence, without random modification there would be little need for an EVM miner to actually do much computation; the computation would happen once, and then the miner would just precompute and store the deltas and apply them immediately. The random modifications mean that the miner has to actually make new EVM computations each time the algorithm is run. However, this solution is itself imperfect in two ways. First of all, random modifications can potentially easily result in what would otherwise be very complex and intricate calculations simply ending early, or at least calulations for which the optimizations are very different from the optimizations applied to standard transactions. Second, mining algorithms may deliberately skip complex contracts in favor of simple or easily optimizable ones. There are heuristic tricks for battling both problems, but it is entirely unclear exactly what those heuristics would be.

Another interesting point in favor of this kind of mining is that even if optimized hardware miners emerge, the community has the ability to work together to essentially change the mining algorithm by “poisoning” the transaction pool. Engineers can analyze existing ASICs, determine what their optimizations are, and dump transactions into the blockchain that such optimizations simply do not work with. If 5% of all transactions are effectively poisoned, then ASICs cannot possibly have a speedup of more than 20x. The nice thing is that there is a reason why people would pay the transaction fees to do this: each individual ASIC company has the incentive to poison the well for its competitors.

These are all challenges that we will be working on heavily in the next few months.

DAOs Are Not Scary, Part 2: Reducing Barriers

In the last installment of this series, we talked about what “smart contracts” (or, perhaps more accurately, “self-enforcing contracts”) are, and discussed in detail the two main mechanisms through which these contracts can have “force”: smart property and “factum” currencies. We also discussed the limits of smart contracts, and how a smart contract-enabled legal system might use a combination of human judgement and automatic execution to achieve the best possible outcomes. But what is the point of these contracts? Why automate? Why is it better to have our relationships regulated and controlled by algorithms rather than humans? These are the tough questions that this article, and the next, intends to tackle.

A Tale of Two Industries

The first, and most obvious, benefit of using internet-driven technology to automate anything is the exact same that we have seen the internet, and Bitcoin, already provide in the spheres of communications and commerce: it increases efficiency and reduces barriers to entry. One very good example of this effect providing meaningful benefits in the traditional world is the publishing industry. In the 1970s, if you wanted to write a book, there was a large number of opaque, centralized intermediaries that you would need to go through before your book would get to a consumer. First, you would need a publishing company, which would also handle editing and marketing for you and provide a quality control function to the consumer. Second, the book would need to be distributed, and then finally it would be sold at each individual bookstore. Each part of the chain would take a large cut; at the end, you would be lucky to get more than ten percent of the revenue from each copy as a royalty. Notice the use of the term “royalty”, implying that you the author of the book are simply just another extraneous part of the chain that deserves a few percent as a cut rather than, well, the single most important person without whom the book would not even exist in the first place. Now, the situation is greatly improved. We now have distinct printing companies, marketing companies and bookstores, with a clear and defined role for each one and plenty of competition in each industry – and if you’re okay with keeping it purely digital, you can just publish on Kindle and get 70%.

Now, let’s consider a very similar example, but with a completely different industry: consumer protection, or more specifically escrow. Escrow is a very important function in commerce, and especially commerce online; when you buy a product from a small online store or from a merchant on Ebay, you are participating in a transaction where neither side has a substantial reputation, and so when you send the money by default there is no way to be sure that you will actually get anything to show for it. Escrow provides the solution: instead of sending the money to the merchant directly, you first send the money to an escrow agent, and the escrow agent then waits for you to confirm that you received the item. If you confirm, then the escrow agent sends the money along, and if the merchant confirms that they can’t send the item then the escrow agent gives you your money back. If there’s a dispute, an adjudication process begins, and the escrow agent decides which side has the better case.

The way it’s implemented today, however, escrow is handled by centralized entities, and is thrown in together with a large number of other functions. On the online marketplace Ebay, for example, Ebay serves the role of providing a server for the seller to host their product page on, a search and price comparison function for products, and a rating system for buyers and sellers. Ebay also owns Paypal, which actually moves the money from the seller to the buyer and serves as the escrow agent. Essentially, this is exactly the same situation that book publishing was in in the 1970s, although in fairness to Ebay sellers do get quite a bit more than 10% of their money. So how can we make an ideal marketplace with cryptocurrencies and smart contracts? If we wanted to be extreme about it, we could make the marketplace decentralized, using a Diaspora-like model to allow a seller to host their products on a specialized site, on their own server or on a Decentralized Dropbox implementation, use a Namecoin-like system for sellers to store their identities and keep a web of trust on the blockchain. However, what we’re looking at now is a more moderate and simple goal: separating out the function of the escrow agent from the payment system. Fortunately, Bitcoin offers a solution: multisignature transactions.

Introducing Multisig

Multisignature transactions allow a user to send funds to an address with three private keys, such that you need two of those keys to unlock the funds (multisigs can also be 1-of-3, 6-of-9, or anything else, but in practice 2-of-3 is the most useful). The way to apply this to escrow is simple: create a 2-of-3 escrow between the buyer, the seller and the escrow agent, have the buyer send funds into it and when a transaction is complete the buyer and the seller sign a transaction to complete the escrow. If there is a dispute, the escrow agent picks which side has the more convincing case, and signs a transaction with them to send them the funds. On a technological level, this is slightly complicated, but fortunately Bitrated has come up with a site that makes the process quite easy for the average user.

Of course, in its current form, Bitrated is not perfect, and we do not see that much Bitcoin commerce using it. The interface is arguably not as easy as it could be, especially since most people are not used to the idea of storing specific per-transaction links for a few weeks, and it would be much more powerful if it was integrated into a fully-fledged merchant package. One design might be a KryptoKit-like web app, showing each user a list of “open” buys and sells and providing a “finalize”, “accept”, “cancel” and “dispute” button for each one; users would then be able to interact with the multisig system just as if it was a standard payment processor, but then get a notification to finalize or dispute their purchases after a few weeks.

But if Bitrated does get its interface right and starts to see mass adoption, what will that accomplish? Once again, the answer is reduced barriers to entry. Currently, getting into the consumer escrow and arbitration business is hard. In order to be an escrow service, you essentially need to build an entire platform and an ecosystem, so that consumers and merchants operate through you. You also can’t just be the one escrowing the money – you also need to be the one transferring the money in the first place. Ebay needs to have, and control, Paypal, in order for half of its consumer protection to work. With Bitrated, this all changes. Anyone can become an escrow agent and arbitrator, and an Ebay-like marketplace (perhaps CryptoThrift or the upcoming Egora) can have a rating system for arbitrators as well as buyers and sellers. Alternatively, the system could handle arbitration in the background similarly to how Uber handles taxi drivers: anyone could become an arbitrator after a vetting process, and the system would automatically reward arbitrators with good ratings and fire those with bad ratings. Fees would drop, likely substantially below even the 2.9% charged by Paypal alone.

Smart Contracts

Smart contracts in general take this same basic idea, and push it much further. Instead of relying on a platform like Bitfinex to hedge one’s Bitcoin holdings or speculate in either direction at high leverage, one can use a blockchain-based financial derivatives contract with a decentralized order book, leaving no central party to take any fees. The ongoing cost of maintaining an exchange, complete with operational security, server management, DDoS protection, marketing and legal expenses, could be replaced with a one-time effort to write the contract, likely in less than 100 lines of code, and another one-time effort to make a pretty interface. From that point on, the entire system would be free except for network fees. File storage platforms like Dropbox could be similarly replaced; although, since hard disk space costs money, the system would not be free, it would likely be substantially cheaper than it is today. It would also help equalize the market by making it easy to participate on the supply side: anyone with a big hard drive, or even a small hard drive with some extra space, can simply install the app and start earning money renting out their unused space.

Instead of relying on legal contracts using expensive (and often, especially in international circumstances and poor countries, ineffective) court systems, or even moderately expensive private arbitration services, business relationships can be governed by smart contracts where those parts of the contract that do need human interpretation can be segregated into many specialized parts. There might be judges specializing in determining whether or not a product shipped (ideally, this would be the postal system itself), judges specializing in determining whether web application designs meet specifications, judges specializing in adjudicating certain classes of property insurance claims with a $0.75 fee by examining satellite images, and there would be contract writers skilled in intelligently integrating each one. Specialization has its advantages, and is the reason why society moved beyond running after bears with stone clubs and picking berries, but one of its weaknesses has always been the fact that it requires intermediaries to manage and function, including intermediaries specifically to manage the relationship between the intermediaries. Smart contracts can remove the latter category almost completely, allowing for an even greater degree of specialization, along with lower barriers to entry within each now shrunken category.

However, this increase in efficiency is only one part of the puzzle. The other part, and perhaps the more important one, has to do with a topic that many cryptocurrency advocates hold dear: reducing trust. We will cover that in the next installment of this series.