Ethereum 白皮书精读

Bitcoin was the first widely adopted cryptocurrency and one of the first examples of a decentralized consensus-based system. However, another important part of the Bitcoin experiment is the underlying blockchain technology as a tool of distributed consensus. Commonly cited alternative applications of blockchain technology include using on-blockchain digital assets to represent custom currencies, financial instruments, the property of an underlying physical device, and non-fungible assets such as domain names, as well as more complex applications involving having digital assets being directly controlled by a piece of code implementing arbitrary rules, known as smart contracts.

From a technical standpoint, the ledger of a cryptocurrency such as Bitcoin can be thought of as a state transition system, where there is a "state" consisting of the ownership status of all existing bitcoins and a "state transition function" that takes a state and a transaction and outputs a new state which is the result. In a standard banking system, for example, the state is a balance sheet, a transaction is a request to move $X from A to B, and the state transition function reduces the value in A's account by $X and increases the value in B's account by $X.

In Bitcoin, the "state" is the collection of all coins (technically, "unspent transaction outputs" or UTXO) that have been minted and not yet spent, with each UTXO having a denomination and an owner (defined by a 20-byte address which is essentially a cryptographic public key). A transaction contains one or more inputs, with each input containing a reference to an existing UTXO and a cryptographic signature produced by the private key associated with the owner's address, and one or more outputs, with each output containing a new UTXO to be added to the state.

If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transition system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks." The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e., hash of) the previous block and a list of all of the transactions that have taken place since the previous block.

Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger. The algorithm for checking if a block is valid is: check if the previous block referenced by the block exists and is valid, check that the timestamp of the block is greater than that of the previous block and less than 2 hours into the future, check that the proof-of-work on the block is valid, and verify all transactions within the block. If the miner of every block gets a mining reward, a decentralized consensus becomes possible.

An important scalability feature of Bitcoin is that the block is stored in a multi-level data structure. The "hash" of a block is actually only the hash of the block header, a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data structure called the Merkle tree storing all transactions in the block. A Merkle tree is a type of binary tree, composed of a set of nodes with a large number of leaf nodes at the bottom of the tree containing the underlying data, a set of intermediate nodes where each node is the hash of its two children, and finally a single root node, also formed from the hash of its two children, representing the "top" of the tree.

The purpose of the Merkle tree is to allow the data in a block to be delivered piecemeal: a node can download only the header of a block from one source, the small part of the tree relevant to them from another source, and still be assured that all of the data is correct. The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block.

The idea of taking the underlying blockchain idea and applying it to other concepts also has a long history. In 2005, Nick Szabo came out with the concept of "secure property titles with owner authority," a document describing how "new advances in replicated database technology" will allow a blockchain-based system for storing a registry of who owns what land, creating an elaborate framework including concepts such as homesteading, adverse possession and Georgian land tax.

Namecoin, created in 2010, is best described as a decentralized name registration database. In decentralized protocols like Tor, Bitcoin and BitMessage, there needs to be some way of identifying accounts so that other people can interact with them, but in all existing solutions the only kind of identifier available is a pseudorandom hash. Namecoin, by implementing a name registration system on the Bitcoin blockchain, allows users to register names and store values associated with those names. The primary use case is for a DNS system, mapping domain names like "bitcoin.bit" to an IP address.

Even without any extensions, the Bitcoin protocol actually does facilitate a weak version of a concept of "smart contracts." UTXO in Bitcoin can be owned not just by a public key, but also by a more complicated script expressed in a simple stack-based programming language. In this paradigm, a transaction spending that UTXO must provide data that satisfies the script. Indeed, even the basic public key ownership mechanism is implemented via a script: the script takes an elliptic curve signature as input, verifies it against the transaction and the address that owns the UTXO, and returns 1 if the verification is successful and 0 otherwise.

However, the scripting language as implemented in Bitcoin has several important limitations. First, there are no loops — it is deliberately not Turing-complete. Second, value-blind — there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. Third, the scripts lack state — a UTXO is either spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers, or two-stage cryptographic commitment protocols.

In Ethereum, the state is made up of objects called "accounts," with each account having a 20-byte address. State transitions are direct transfers of value and information between accounts. An Ethereum account contains four fields: the nonce, a counter used to make sure each transaction can only be processed once; the account's current ether balance; the account's contract code, if present; and the account's storage. There are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code.

The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain the recipient of the message, a signature identifying the sender, the amount of ether to transfer, an optional data field, a STARTGAS value representing the maximum number of computational steps the transaction execution is allowed to take, and a GASPRICE value representing the fee the sender pays per computational step.

The Ethereum state transition function, APPLY(S,TX) -> S', can be defined as follows: Check if the transaction is well-formed (i.e., has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. Calculate the transaction fee as STARTGAS * GASPRICE, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance, return an error.

Initialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction. Send the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.

The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as "Ethereum virtual machine code" or "EVM code." The code consists of a series of bytes, where each byte represents an operation. In general, code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected.

The operations have access to three types of space in which to store data: the stack, a last-in-first-out container to which values can be pushed and popped; memory, an infinitely expandable byte array; and the contract's long-term storage, a key/value store. Unlike stack and memory, which reset after computation ends, storage persists for the long term. The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.

The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block.

The basic block validation algorithm in Ethereum works as follows: check if the previous block referenced exists and is valid; check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future; check that the block number, difficulty, transaction root, uncle root and gas limit are valid; check that the proof-of-work on the block is valid; let S[0] be the state at the end of the previous block, and let TX be the block's transaction list. For each transaction, apply it to the state and add the gas fee to the miner. If any application returns an error, or if the total gas consumed exceeds the GASLIMIT, return an error. Let S_FINAL be the resulting state, add the block reward to the miner, and the resulting state is S_FINAL.

In general, there are three types of applications on top of Ethereum. The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, and wills. The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side; a perfect example is self-enforcing bounties for solutions to computational problems. Finally, there are applications such as online voting and decentralized governance that are not financial at all.

On-blockchain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization.

Token systems are surprisingly easy to implement in Ethereum. The key point to understand is that all a currency, or token system, fundamentally is, is a database with one operation: subtract X units from A and give X units to B, with the proviso that (1) A had at least X units before the transaction and (2) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a contract.

Financial derivatives are the most common application of a "smart contract," and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar.

The contract would take the form of: Party A puts in 1000 ether, then Party B puts in 1000 ether. After 30 days, A gets the dollar value of 1000 ether at the time the contract was made, and B gets whatever is left. This requires an oracle — a contract or entity that provides external data to the blockchain. To make this work, someone needs to be incentivized to maintain a data feed of the ETH/USD price. The "decentralized oracle" problem is one of the most important unsolved challenges in the DeFi ecosystem.

The earliest alternative cryptocurrency of all, Namecoin, attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data. The major cited use case is for a DNS system, mapping domain names like "bitcoin.bit" to an IP address. Other use cases include email authentication and potentially more advanced reputation systems. Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:

The contract is very simple; all it is, is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" of a name (i.e., the first registerer) to change the data or transfer ownership.

Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that the prices of mainstream cloud storage are above the marginal cost of storage.

The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract." This contract works as follows: first, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree, and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree.

The general concept of a "decentralized autonomous organization" (DAO) is that of a virtual entity that has a certain set of members or shareholders which, perhaps with a 67% majority, have the right to spend the entity's funds and modify its code. The members would collectively decide on how the organization should allocate its funds. Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work.

This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement. The "decentralized autonomous organization" concept takes the same concept of a DAO, but with the additional caveat that it would have artificial intelligence-like decision making, or perhaps use liquid democracy — a form of voting where everyone can vote directly on issues or delegate their vote to someone else, with delegation being transitive.

The "Greedy Heaviest Observed Subtree" (GHOST) protocol is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013. The motivation behind GHOST is that blockchains with fast confirmation times currently suffer from reduced security due to a high stale rate — because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security.

Ethereum implements a simplified version of GHOST which only goes down seven levels. Specifically, stale blocks (known as "uncles" in Ethereum) can be included by subsequent blocks and their miners receive a partial reward. This incentivizes miners to include stale blocks and not only build on the longest chain. The net effect is that the blockchain achieves higher throughput and faster block times while maintaining security properties equivalent to a blockchain with slower block times.

Because every transaction published into the blockchain imposes on the network the cost of needing to download and verify it, there is a need for some regulatory mechanism, typically involving transaction fees, to prevent abuse. The default approach, used in Bitcoin, is to have purely voluntary fees, relying on miners to act as the gatekeepers and set dynamic minimums.

However, because the miner does not need to pay for the cost of including the transaction — other nodes do — there is an inherent market failure. Furthermore, there is an important issue that the Ethereum network, unlike Bitcoin, needs to deal with: because Ethereum has Turing-complete computation, a transaction's gas consumption is not predictable in advance. This means the cost of a transaction cannot be known before it is executed. The solution in Ethereum is that the sender specifies a gas limit and gas price; if the execution uses less gas than specified, the difference is refunded.

An important note is that the Ethereum virtual machine is Turing-complete; this means that EVM code can encode any computation that can be conceivably carried out, including infinite loops. EVM code allows looping in two ways. First, there is a JUMP instruction that allows the program to jump back to a previous spot in the code, and a JUMPI instruction to do conditional jumping, allowing for statements like while x < 27: x = x * 2.

But how can this work if computations can potentially loop forever? The answer is the gas mechanism: every computational step costs gas. Looping is permitted, but running infinite loops is made financially infeasible because it would cost an unbounded amount of gas. Thus, a malicious or poorly written contract cannot cause the network to grind to a halt — the execution simply stops when it runs out of gas, and the miner collects the fee. This is the key insight that allows Ethereum to have a Turing-complete language while still being secure against denial-of-service attacks.

The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument, the denominations will be pre-labelled: 1 wei, 10^12 wei = 1 szabo, 10^15 wei = 1 finney, and 10^18 wei = 1 ether.

The issuance model will be as follows: Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, with a portion of the ether used to fund the development organization and pay for development. 0.099x of the total amount sold will be allocated to early contributors, and another 0.099x will be allocated to long-term research. From that point on there will be a permanent annual linear increase in the currency, giving miners an incentive to secure the network. Over time, the currency supply growth rate tends to zero even though the absolute amount continues to increase linearly.

The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets, and the like via a highly generalized programming language. The Ethereum protocol would not "support" any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can be theoretically created for any transaction type or application. What is more interesting about Ethereum is that the protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation, and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry.