Bitcoin and Cryptocurrency Technologies

y all miners (so they can check that the contract was executed correctly) but shouldn’t be
predictable to either player (or else they might refuse to join if they know they will have to play
second).
This is the problem of randomness beacons. As we discussed in Section 9.4, the contract might hash
the value of the next block in the blockchain after both players have joined. For our specific
application, the problem is a bit easier, since only Alice and Bob need to be convinced that the coin
flip is random, not the whole world. So they might use the approach from Section 9.3: they both
submit the hash of a random value, then both reveal the inputs, and derive the random bit from the
inputs. Both approaches have been seen in practice.
Other applications.​Playing chess might be fun, but the real excitement for Ethereum is about
financial applications. Many of the applications we’ve discussed in the text so far, including prediction
markets, smart property, escrowed payments, micropayment channels, and mixing services, can all be
implemented in Ethereum. There are subtleties to all of these applications, but they are all possible
and in most cases are much simpler to implement than the types of bolt‐on protocols we’ve seen with
Bitcoin. There are also a host of other applications, like auctions and order books, that we haven’t
talked about but which people are enthusiastic about using Ethereum to implement.
State and account balances in Ethereum. ​In Chapter 3, we discussed two ways to design a ledger:
account‐based and transaction‐based. In a transaction‐based ledger like Bitcoin, the blockchain stores
only transactions (plus a small amount of metadata in the block headers). To make it easier to validate
transactions, Bitcoin treats coins as immutable, and transaction outputs must be spent in their
entirety, with change addresses used if necessary. Effectively, transactions operate on a global state
which is a list of UTXOs, but this state is never made explicit in the Bitcoin protocol and is simply
something miners create on their own to speed up verification.
Ethereum, on the other hand, uses an account‐based model. Since Ethereum already stores a data
structure mapping contract addresses to state, it is natural to also store the account balance of every
regular address (also called an owned address) in the system. This means that instead of representing
payments using an acyclic transaction graph where each transaction spends some inputs and creates
some outputs, Ethereum just stores a balance for each address like a traditional bank might store the
balance of each account number.
Data structures in Ethereum. ​In Chapter 3, we said that an account‐based ledger would necessitate
fancy data structures for record‐keeping. Ethereum has just such data structures. Specifically, every
block contains a digest of the current state (balance and transaction count) of every address as well as
the state (balance and storage) of every contract. Each contract’s storage tree maps arbitrary 256‐bit
addresses to 256‐bit words, making for a whopping 2​ 256 ​ ⨉ 256 = 2​ 264​ bytes of storage! Of course, you
could never fill up all of this storage, but that’s the theoretical space. The digest makes it easy to
prove that a given address has a given balance or storage state. For example, Alice can prove to Bob
what her balance is without Bob having to scan the entire block chain to verify the proof.
290