leaf

What is Ethereum? Ethereum is a brand new open blockchain platform that allows anyone to build and use decentralized applications running on blockchain technology. Like Bitcoin, Ethereum is not controlled by anyone and is not owned by anyone—it is an open-source project created collaboratively by many people around the world. Unlike the Bitcoin protocol, Ethereum's design is very flexible and highly adaptable. Creating new applications on the Ethereum platform is very straightforward, and with the release of Homestead, anyone can safely use the applications on the platform.

The Ethereum DApp practical development course uses a decentralized voting application (Voting DApp) as the course project, providing detailed explanations of the iterative development process without online practice, and integrating the concepts of blockchain and decentralization throughout the course practice, offering an efficient learning and value enhancement path for developers who wish to quickly get started with blockchain development. "Introduction to Ethereum DApp Development" will be written later.

The tutorial comes with a pre-configured development environment. After entering the tutorial, you can immediately practice each knowledge point synchronously without wasting time on setting up the development environment:

In the Chinese version of the Ethereum white paper, when Satoshi Nakamoto launched the Bitcoin blockchain in January 2009, he introduced two revolutionary new concepts that had not been tested. The first is Bitcoin, a decentralized peer-to-peer online currency that maintains value without any asset backing, intrinsic value, or central issuer. So far, Bitcoin has attracted a lot of public attention; politically, it is a currency without a central bank and has extreme price volatility. However, Satoshi Nakamoto's great experiment has another equally important part: the concept of a blockchain based on proof of work allows people to reach consensus on the order of transactions. As an application, Bitcoin can be described as a first-to-file system: if someone has 50 BTC and simultaneously sends this 50 BTC to A and B, only the transaction that is confirmed first will take effect. There is no inherent way to determine which of the two transactions arrives first, and this issue has hindered the development of decentralized digital currency for many years. Satoshi Nakamoto's blockchain is the first reliable decentralized solution. Now, developers' attention is rapidly shifting to the second part of Bitcoin technology: how blockchain can be applied to areas beyond currency. Commonly mentioned applications include using on-chain digital assets to represent customized currencies and financial instruments (colored coins), ownership of certain physical devices (smart assets), non-fungible assets like domain names (name coins), and more advanced applications such as decentralized exchanges, financial derivatives, peer-to-peer gambling, and on-chain identity and reputation systems. Another important area often inquired about is "smart contracts"—systems that automatically transfer digital assets based on arbitrarily predetermined rules. For example, a person might have a storage contract in the form of "A can withdraw up to X coins per day, B can withdraw up to Y coins per day, A and B can withdraw at will together, and A can revoke B's withdrawal rights." A logical extension of such contracts is decentralized autonomous organizations (DAOs)—long-term smart contracts that include an organization's assets and encode the organization's rules. The goal of Ethereum is to provide a blockchain with a built-in mature Turing-complete language, allowing contracts to be created that encode any state transition function, enabling users to implement logic with just a few lines of code to create all the systems mentioned above and many others we have yet to imagine.

Historical Development The concept of decentralized digital currency, like alternative applications such as property registration, was proposed decades ago.

In the 1980s and 1990s, anonymous electronic cash protocols were mostly based on Chaumian blinding technology. These electronic cash protocols provided highly private currency, but none of them became popular because they all relied on a centralized intermediary. In 1998, Wei Dai's b-money first introduced the idea of creating currency through solving computational puzzles and decentralized consensus, but the proposal did not provide specific methods for achieving decentralized consensus.

In 2005, Hal Finney introduced the concept of "reusable proofs of work," which simultaneously used the ideas of b-money and the computationally difficult Hashcash problem proposed by Adam Back to create cryptographic currency. However, this concept again lost its way in idealism because it relied on trusted computation as a backend. Because currency is a first-to-file application, the order of transactions is crucial, so decentralized currency needs to find a way to achieve decentralized consensus. The main obstacle encountered by all previous electronic currency protocols before Bitcoin was that, despite years of research on how to create a secure Byzantine-fault-tolerant multi-party consensus system, the aforementioned protocols only solved half of the problem. These protocols assumed that all participants in the system were known and produced security boundaries in the form of "if N parties participate in the system, then the system can tolerate N/4 malicious participants." However, the problem with this assumption is that, in anonymity, the security boundaries set by the system are vulnerable to Sybil attacks, as an attacker can create thousands of nodes on a single server or botnet, thereby ensuring they have a majority share unilaterally. Satoshi Nakamoto's innovation was to introduce the idea of combining a very simple node-based decentralized consensus protocol with a proof-of-work mechanism. Nodes gain the right to participate in the system through the proof-of-work mechanism, packaging transactions into "blocks" every ten minutes, thus creating a continuously growing blockchain. Nodes with a large amount of computing power have more influence, but obtaining more computing power than the entire network is much more difficult than creating a million nodes. Although the Bitcoin blockchain model is very rudimentary, it has proven to be good enough, and in the next five years, it will become the cornerstone of more than two hundred currencies and protocols worldwide.

Bitcoin as a State Transition System

From a technical perspective, the Bitcoin ledger can be considered a state transition system that includes all existing Bitcoin ownership states and "state transition functions." The state transition function takes the current state and transactions as input and outputs a new state. For example, in a standard banking system, the state is a balance sheet, and a request to transfer X dollars from account A to account B is a transaction; the state transition function subtracts X dollars from account A and adds X dollars to account B. If the balance of account A is less than X dollars, the state transition function will return an error. Thus, we can define the state transition function as follows:

APPLY(S,TX) > S’ or ERROR

In the aforementioned banking system, the state transition function is as follows:

APPLY({ Alice: $50, Bob: $50 },”send $20 from Alice to Bob”) = { Alice: $30,Bob: $70 }

However:

APPLY({ Alice: $50, Bob: $50 },”send $70 from Alice to Bob”) = ERROR

The "state" of the Bitcoin system is the collection of all mined, unspent bitcoins (technically referred to as "unspent transaction outputs" or UTXOs). Each UTXO has a value and an owner (defined by a 20-byte address that is essentially a cryptographic public key). A transaction consists of one or more inputs and one or more outputs. Each input contains a reference to an existing UTXO and a cryptographic signature created by the private key corresponding to the owner's address. Each output contains a new UTXO added to the state. In the Bitcoin system, the state transition function APPLY(S,TX)->S’ can generally be defined as follows:

1. For each input of the transaction:

• If the referenced UTXO does not exist in the current state (S), return an error.

• If the signature does not match the UTXO owner's signature, return an error.

1. If the total value of all UTXO inputs is less than the total value of all UTXO outputs, return an error.

2. Return the new state S’, where all input UTXOs are removed and all output UTXOs are added. The first part of the first step prevents the transaction sender from spending non-existent bitcoins, and the second part prevents the transaction sender from spending someone else's bitcoins. The second step ensures value conservation. The payment protocol for Bitcoin is as follows. Suppose Alice wants to send Bob 11.7 BTC. In fact, Alice cannot have exactly 11.7 BTC. Suppose the smallest amount of bitcoins she can get is: 6+4+2=12. So, she can create a transaction with 3 inputs and 2 outputs. The first output has a value of 11.7 BTC, owned by Bob (Bob's Bitcoin address), and the second output has a value of 0.3 BTC, owned by Alice herself, which is the change.

Mining#

If we have a trusted centralized service, the state transition system can be easily implemented by simply accurately coding the above functions. However, we want to build the Bitcoin system as a decentralized currency system, and to ensure that everyone agrees on the order of transactions, we need to combine the state transition system with a consensus system. The decentralized consensus process of Bitcoin requires nodes in the network to continuously attempt to package transactions into "blocks." The network is designed to produce a block approximately every ten minutes, with each block containing a timestamp, a random number, a reference (i.e., hash) to the previous block, and a list of all transactions that occurred since the last block was generated. This creates a continuously growing blockchain over time, which is constantly updated to represent the latest state of the Bitcoin ledger. According to this paradigm, the algorithm for checking whether a block is valid is as follows:

1. Check whether the previous block referenced by the block exists and is valid.

2. Check whether the timestamp of the block is later than the timestamp of the previous block and earlier than two hours in the future.

3. Check whether the proof of work of the block is valid.

4. Assign the final state of the previous block to S[0].

5. Assume TX is the transaction list of the block, containing n transactions. For all i belonging to 0...n-1, perform the state transition S[i+1] = APPLY(S[i],TX[i]). If any transaction i encounters an error during the state transition, exit the program and return an error.

6. Return success; the state S[n] is the final state of this block.

Essentially, each transaction in the block must provide a correct state transition. It should be noted that the "state" is not encoded into the block. It is purely an abstract concept remembered by the validating nodes, and for any block, the current state can be calculated (accurately) from the genesis state by sequentially adding each transaction of each block. Additionally, it is important to note the order in which miners include transactions in blocks. If a block contains transactions A and B, and B spends a UTXO created by A, if A appears before B, this block is valid; otherwise, this block is invalid. The interesting part of the block validation algorithm is the concept of "proof of work": performing SHA256 hashing on each block, treating the resulting hash as a 256-bit value that must be less than a continuously dynamically adjusted target value; at the time of writing this book, the target value is approximately 2^190. The purpose of proof of work is to make block creation difficult, thereby preventing Sybil attackers from maliciously regenerating the blockchain. Because SHA256 is a completely unpredictable pseudorandom function, the only way to create a valid block is simply to try repeatedly, continuously increasing the value of the random number and checking whether the new hash value is less than the target value. If the current target value is 2^192, it means that on average, it takes 2^64 attempts to generate a valid block. Generally, the Bitcoin network resets the target value every 2016 blocks to ensure that a block is generated approximately every ten minutes. To reward miners for their computational work, each miner who successfully generates a block has the right to include a transaction that gives them 25 BTC out of thin air. Additionally, if the inputs of a transaction exceed the outputs, the difference is paid to the miner as a "transaction fee." By the way, the reward for miners is the only mechanism for Bitcoin issuance; there are no bitcoins in the genesis state.

To better understand the purpose of mining, let’s analyze what happens when malicious attackers appear in the Bitcoin network. Because the cryptographic foundation of Bitcoin is very secure, attackers will choose to attack parts that are not directly protected by cryptography: the order of transactions. The attacker's strategy is very simple:

1. Send the seller 100 BTC to purchase goods (especially digital goods that do not require shipping).

2. Wait until the goods are shipped.

3. Create another transaction sending the same 100 BTC to their own account.

4. Make the Bitcoin network believe that the transaction sent to their own account is the first one sent. Once step (1) occurs, a few minutes later, miners will package this transaction into a block, assuming it is the 270,000th block. About an hour later, there will be five blocks behind this block, each indirectly pointing to this transaction, thus confirming it. At this point, the seller receives the payment and ships the goods to the buyer. Since we assume this is a digital product, the attacker can receive the goods instantly. Now, the attacker creates another transaction sending the same 100 BTC to their own account. If the attacker simply broadcasts this message to the entire network, this transaction will not be processed. Miners will run the state transition function APPLY(S,TX), discovering that this transaction will spend a UTXO that is no longer in the state. Therefore, the attacker will fork the blockchain, taking the 269,999th block as the parent block and regenerating the 270,000th block, replacing the old transaction with the new transaction. Since the block data is different, this requires redoing the proof of work. Additionally, because the new 270,000th block generated by the attacker has a different hash, the original blocks 270,001 to 270,005 do not point to it, thus the original blockchain and the attacker's new block are completely separate. In the event of a blockchain fork, the longer branch of the blockchain is considered the honest blockchain, and legitimate miners will continue mining along the original block 270,005, while only the attacker mines on the new 270,000th block. To make their blockchain the longest, the attacker needs to have more computing power than the rest of the network combined (i.e., a 51% attack).

Merkle Tree

Left: Providing only a small number of nodes on the Merkle tree is sufficient to give a legitimate proof of the branch. Right: Any attempt to change any part of the Merkle tree will ultimately lead to an inconsistency somewhere on the chain. An important scalability feature of the Bitcoin system is that its blocks are stored in a multi-layered data structure. The hash of a block is actually just the hash of the block header, which is a segment of data about 200 bytes long that includes a timestamp, a random number, a hash of the previous block, and the root hash of the Merkle tree that stores all the transactions of the block.

A Merkle tree is a binary tree consisting of a set of leaf nodes, a set of intermediate nodes, and a root node. The numerous leaf nodes at the bottom contain the base data, each intermediate node is the hash of its two child nodes, and the root node is also the hash of its two child nodes, representing the top of the Merkle tree.

The purpose of the Merkle tree is to allow the data of the block to be transmitted in a scattered manner: nodes can download the block header from one source and download other parts of the tree related to it from another source while still being able to confirm that all the data is correct. This is because of the upward diffusion of hashes: if a malicious user tries to add a forged transaction at the bottom of the tree, the changes will cause changes in the upper nodes of the tree, and even higher nodes, ultimately leading to changes in the root node and the block hash, causing the protocol to record it as a completely different block (almost certainly with incorrect proof of work). The Merkle tree protocol is crucial for the long-term sustainability of Bitcoin.

In April 2014, a full node in the Bitcoin network—one that stores and processes all the data of all blocks—needed to occupy 15GB of memory space and was growing at a rate of over 1GB per month. Currently, this storage space is still acceptable for desktop computers, but smartphones cannot handle such large data. In the future, only commercial institutions and enthusiasts will act as full nodes. The Simplified Payment Verification (SPV) protocol allows for another type of node to exist, known as "light nodes," which download block headers, use the block headers to confirm proof of work, and then only download the relevant branches of the Merkle tree related to their transactions. This allows light nodes to safely determine the status of any Bitcoin transaction and the current balance of accounts by downloading only a small portion of the entire blockchain. Other Blockchain Applications The idea of applying blockchain concepts to other fields has long been proposed.

In 2005, Nick Szabo introduced the concept of "naming property with ownership," describing how the development of replicated database technology could enable blockchain-based systems to be used for registering land ownership, creating a detailed framework that includes concepts such as property rights, illegal occupation, and Georgia land tax. Unfortunately, at that time, there were no practical replicated database systems, so this protocol was not put into practice. However, since the successful development of decentralized consensus in the Bitcoin system in 2009, many other blockchain applications have begun to emerge rapidly.

• Namecoin - Created in 2010, known as a decentralized name registration database.

Decentralized protocols like Tor, Bitcoin, and BitMessage require some method of confirming accounts so that others can interact with users. However, among all existing solutions, the only available identity identifiers are pseudorandom hashes like 1LW79wp5ZBqaHW1jL5TciBCrhQYtHagUWy. Ideally, people would like to have an account with a name like "george." However, the problem is that if someone can create an account "george," then others can also create an account "george" to impersonate. The only solution is the first-to-file principle, where only the first registrant can successfully register, and the second cannot register the same account again. This issue can be addressed using Bitcoin's consensus protocol.

Namecoin is the earliest and most successful system to implement a name registration system using blockchain. - Colored Coins - The purpose of colored coins is to allow people to create their own digital currencies on the Bitcoin blockchain, or, in a more general sense, to provide digital tokens. According to the colored coins protocol, people can issue new currencies by designating a color for a specific Bitcoin UTXO. The protocol recursively defines other UTXOs as the same color as the transaction input UTXO. This allows users to maintain UTXOs that only contain a specific color, and sending these UTXOs is like sending regular bitcoins, determining the color of the received UTXOs by tracing back through the entire blockchain.

• Metacoins - The idea of metacoins is to create new protocols on the Bitcoin blockchain, using Bitcoin transactions to preserve metacoin transactions but employing a different state transition function APPLY’. Because metacoin protocols cannot prevent invalid metacoin transactions on the Bitcoin blockchain, an additional rule is added: if APPLY’(S,TX) returns an error, this protocol will default to APPLY’(S,TX) = S. This provides a simple solution for creating any advanced cryptographic currency protocols that cannot be implemented in the Bitcoin system, and the development cost is very low because mining and network issues have already been handled by the Bitcoin protocol.

Therefore, in general, there are two ways to establish consensus protocols: establishing an independent network and establishing protocols on the Bitcoin network. While applications like Namecoin have succeeded using the first method, the implementation of this method is very difficult because each application needs to create an independent blockchain and establish and test all state transition and network code. Additionally, we predict that the application of decentralized consensus technology will follow a power-law distribution, with most applications being too small to ensure the security of a free blockchain. We also note that many decentralized applications, especially decentralized autonomous organizations, require interaction between applications. On the other hand, the Bitcoin-based approach has drawbacks; it does not inherit the feature of simplified payment verification (SPV) that Bitcoin can achieve. Bitcoin can achieve simplified payment verification because it can use blockchain depth as a validity confirmation proxy. At some point, once the ancestors of a transaction are far enough from the present, they can be considered part of a legitimate state. In contrast, metacoin protocols based on the Bitcoin blockchain cannot force the blockchain to exclude transactions that do not conform to the metacoin protocol. Therefore, secure metacoin protocols require backward scanning of all blocks to confirm whether a transaction is valid. Currently, all "light" implementations of metacoin protocols based on Bitcoin rely on trusted servers to provide data, which is a rather suboptimal result for one of the main purposes of cryptographic currency, which is to eliminate trust.

Scripts#

Even without extending the Bitcoin protocol, it can achieve a certain degree of "smart contracts." Bitcoin's UTXOs can be owned by more than one public key and can also be owned by more complex scripts written in a stack-based programming language. In this model, spending such UTXOs requires providing data that satisfies the script. In fact, the basic public key ownership mechanism is also implemented through scripts: the script takes the elliptic curve signature as input, verifies the transaction and the address of the UTXO owner, and if the verification is successful, returns 1; otherwise, it returns 0. More complex scripts are used for other different application scenarios. For example, people can create scripts that require two out of three private keys to confirm a transaction (multisignature), which is very useful for corporate accounts, savings accounts, and certain business agents. Scripts can also be used to reward users who solve computational problems. People can even create scripts like "If you can provide proof of simplified payment verification that you have sent a certain amount of dogecoin to me, this Bitcoin UTXO is yours."

Essentially, the Bitcoin system allows for decentralized exchange of different cryptographic currencies. However, the script language of the Bitcoin system has some serious limitations:

• Lack of Turing completeness – This means that although the Bitcoin script language can support various computations, it cannot support all computations. The main missing feature is loop statements.

The purpose of not supporting loop statements is to avoid infinite loops during transaction confirmations. Theoretically, this is an obstacle that can be overcome for script programmers, as any loop can be simulated by repeating if statements multiple times, but doing so leads to inefficiency in script space utilization; for example, implementing an alternative elliptic curve signature algorithm may require 256 repeated multiplications, each needing to be encoded separately.

• Value blindness.

UTXO scripts cannot provide fine control over the withdrawal limits of accounts.

For example, a powerful application of oracle contracts is hedging contracts, where A and B each send Bitcoin worth $1000 to the hedging contract, and after 30 days, the script sends Bitcoin worth $1000 to A and sends the remaining Bitcoin to B. While implementing a hedging contract requires an oracle to determine how much one Bitcoin is worth in dollars, this mechanism has made significant progress in reducing trust and infrastructure compared to the currently fully centralized solutions. However, because UTXOs are indivisible, the only way to implement this contract is to inefficiently use many UTXOs with different values (for example, for each k up to a maximum of 30, there is a UTXO of 2^k) and have the oracle pick out the correct UTXO to send to A and B.

• Lack of state – UTXOs can only be in spent or unspent states, which leaves no room for multi-stage contracts or scripts that require any other internal state. This makes it very difficult to implement multi-stage option contracts, decentralized exchange offers, or two-phase encryption commitment protocols (which are very necessary for ensuring computational rewards). This also means that UTXOs can only be used to establish simple, one-time contracts, rather than contracts with more complex states like decentralized organizations, making metaprotocols difficult to implement. The binary state combined with value blindness means that another important application—withdrawal limits—is impossible to implement.

• Blockchain blindness – UTXOs cannot see blockchain data, such as random numbers and the hash of the previous block. This flaw deprives the script language of the potential value based on randomness, severely limiting applications in areas such as gambling. We have examined three methods for building advanced applications on cryptographic currencies: establishing a new blockchain, using scripts on the Bitcoin blockchain, and establishing metacoin protocols on the Bitcoin blockchain. The method of establishing a new blockchain can freely implement any features, at the cost of development time and nurturing effort. The method of using scripts is very easy to implement and standardize, but its capabilities are limited. Although metacoin protocols are very easy to implement, they have the drawback of poor scalability. In the Ethereum system, our goal is to establish a universal framework that simultaneously possesses all the advantages of these three modes.

Ethereum#

The purpose of Ethereum is to integrate and enhance the concepts of scripts, competitive coins, and on-chain meta-protocols, enabling developers to create any consensus-based, scalable, standardized, feature-complete, easy-to-develop, and collaborative applications. Ethereum achieves this by establishing the ultimate abstract foundational layer—a blockchain with a built-in Turing-complete programming language—allowing anyone to create contracts and decentralized applications, and to set all ownership rules, transaction methods, and state transition functions they freely define within them.

The main framework of Namecoin can be implemented in just two lines of code, while other protocols such as currency and reputation systems can be implemented in less than twenty lines of code. Smart contracts—encrypted boxes containing value that can only be opened if certain conditions are met—can also be created on our platform, and due to Turing completeness, value awareness, blockchain awareness, and the power added by multi-state, they are much more powerful than the smart contracts that Bitcoin scripts can provide.

Ethereum Accounts#

In the Ethereum system, the state consists of objects known as "accounts" (each account is identified by a 20-byte address) and state transitions that transfer value and information between two accounts. Ethereum accounts contain four parts:

• A nonce, used as a counter to ensure that each transaction can only be processed once.
• The current Ether balance of the account.
• The contract code of the account, if any.
• The account's storage (default is empty).

Ether is the main cryptographic fuel within Ethereum, used to pay transaction fees. Generally, there are two types of accounts in Ethereum:

Externally owned accounts (controlled by private keys) and contract accounts (controlled by contract code). Externally owned accounts have no code, and people can send messages from an external account by creating and signing a transaction. Whenever a contract account receives a message, the internal code of the contract is activated, allowing it to read and write to its internal storage, send other messages, or create contracts.

Messages and Transactions Ethereum messages are somewhat similar to Bitcoin transactions, but there are three important differences between the two.

First, Ethereum messages can be created by external entities or contracts, while Bitcoin transactions can only be created externally.

Second, Ethereum messages can optionally include data.

Third, if the recipient of an Ethereum message is a contract account, it can choose to respond, which means that Ethereum messages also include the concept of functions.

In Ethereum, a "transaction" refers to a signed data packet that stores messages sent from external accounts. Transactions include the recipient of the message, a signature to confirm the sender, the Ether account balance, the data to be sent, and two values known as STARTGAS and GASPRICE.

To prevent exponential code explosion and infinite loops, each transaction needs to impose limits on the computational steps triggered by executing the code—including the initial message and all messages triggered during execution. STARTGAS is the limit, and GASPRICE is the fee paid to miners for each computational step. If the execution of the transaction runs out of fuel, all state changes revert to the original state, but the transaction fees already paid are non-refundable. If there is still fuel left when the execution of the transaction halts, that fuel will be refunded to the sender. Creating contracts has a separate transaction type and corresponding message type; the address of the contract is calculated based on the account nonce and the hash of the transaction data.

An important consequence of the messaging mechanism is that Ethereum's "first-class citizen" property—contracts and external accounts have the same rights, including the rights to send messages and create other contracts. This allows contracts to simultaneously serve multiple different roles; for example, a member of a decentralized organization (a contract) can become an intermediary account (another contract), providing intermediary services for a paranoid user who has customized quantum-proof Lamport signatures (a third contract) and a self-secured account (a fourth contract) secured by five private keys. The power of the Ethereum platform lies in the fact that decentralized organizations and proxy contracts do not need to care about what type of account each participant in the contract is.

Ethereum State Transition Function

The Ethereum state transition function: APPLY(S,TX) -> S’ can be defined as follows:

1. Check whether the format of the transaction is correct (i.e., has the correct values), whether the signature is valid, and whether the nonce matches the sender's account nonce. If not, return an error.

2. Calculate the transaction fee: fee=STARTGAS * GASPRICE, and determine the sender's address from the signature. Subtract the transaction fee from the sender's account and increase the sender's nonce. If the account balance is insufficient, return an error.

3. Set the initial value GAS = STARTGAS, and subtract a certain amount of fuel based on the number of bytes in the transaction.

4. Transfer value from the sender's account to the recipient's account. If the recipient account does not exist yet, create this account. If the recipient account is a contract, run the contract's code until the code execution ends or the fuel runs out.

5. If the value transfer fails due to the sender's account not having enough money or the code execution exhausting the fuel, revert to the original state, but the transaction fee still needs to be paid, and the transaction fee is added to the miner's account.

6. Otherwise, return all remaining fuel to the sender, and the consumed fuel is sent to the miner as transaction fees. For example, suppose the contract code is as follows:

It should be noted that in reality, contract code is written in low-level Ethereum Virtual Machine (EVM) code. The above contract is written in our high-level Serpent language, which can be compiled into EVM code. Suppose the contract storage starts empty, with a value of 10 Ether, fuel of 2000, and two data fields with values [2, 'CHARLIE'][3]; after sending the transaction, the processing of the state transition function is as follows:

1. Check whether the transaction is valid and whether the format is correct.

2. Check whether the sender has at least 2000*0.001=2 Ether. If so, subtract 2 Ether from the sender's account.

3. Initially set gas=2000; assume the transaction length is 170 bytes, with a cost of 5 per byte, subtracting 850, leaving 1150.

4. Subtract 10 Ether from the sender's account, adding 10 Ether to the contract account.

5. Run the code. In this contract, running the code is simple: it checks whether the contract storage index at 2 has been used, notices that it has not been used, and then sets its value to CHARLIE. Suppose this consumes 187 units of fuel, leaving 1150 – 187 = 963 remaining.

6. Add 963*0.001=0.963 Ether to the sender's account, returning the final state. If there is no contract receiving the transaction, then all transaction fees equal GASPRICE multiplied by the transaction's byte length, and the transaction data is independent of the transaction fees. Additionally, it should be noted that messages initiated by contracts can allocate fuel limits to their computations; if the fuel for the sub-computation runs out, it only reverts to the state at the time the message was sent. Therefore, like transactions, contracts can also set strict limits on the sub-computations they generate to protect their computational resources.

Code Execution#

The code of Ethereum contracts is written in a low-level stack-based bytecode language known as "Ethereum Virtual Machine code" or "EVM code."

The code consists of a series of bytes, each representing an operation. Generally, code execution is an infinite loop, with the program counter executing an operation each time it increments by one (initially zero) until the code execution completes or encounters an error, such as STOP or RETURN. Operations can access three types of storage data:

• Stack, a last-in-first-out data storage where 32-byte values can be pushed and popped.
• Memory, an infinitely expandable byte queue.
• The contract's long-term storage, a key/value storage where both keys and values are 32 bytes in size; unlike the stack and memory, which reset upon computation completion, the storage contents persist long-term. The code can access values like it accesses block header data, data in the sender and received messages, and can also return a byte queue of data as output. The formal execution model of EVM code is surprisingly simple.

When the Ethereum Virtual Machine runs, its complete computational state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas), where block_state is the global state containing all account balances and storage. Each round of execution finds the current instruction by pulling the byte at the pc (program counter) of the code, and each instruction has its own definition of how it affects the tuple.

For example, ADD pops two elements from the stack and pushes their sum onto the stack, reduces gas (fuel) by one, and increments pc by one; SSTORE pops the top two elements from the stack and inserts the second element into the storage location defined by the first element, similarly reducing gas by up to 200 and incrementing pc by one. While there are many ways to optimize Ethereum through just-in-time compilation, Ethereum's foundational implementation can be achieved in just a few hundred lines of code.

Blockchain and Mining#

Although there are some differences, the Ethereum blockchain is similar to the Bitcoin blockchain in many ways. The difference in their blockchain architecture is that Ethereum blocks not only contain transaction records and the latest state but also include block numbers and difficulty values. The block confirmation algorithm in Ethereum is as follows:

1. Check whether the previous block referenced by the block exists and is valid.

2. Check whether the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes.

3. Check whether the block number, difficulty value, transaction root, uncle root, and gas limit (many underlying concepts unique to Ethereum) are valid.

4. Check whether the proof of work of the block is valid.

5. Assign S[0] to the STATE_ROOT of the previous block.

6. Assign TX to the transaction list of the block, which contains n transactions. For all i belonging to 0...n-1, perform the state transition S[i+1] = APPLY(S[i],TX[i]). If any transition encounters an error, or if the fuel (gas) spent to execute the program exceeds GASLIMIT, return an error.

7. Assign S[n] to S_FINAL and pay the block reward to the miner.

8. Check whether S_FINAL is the same as STATE_ROOT. If they are the same, the block is valid; otherwise, the block is invalid.

This confirmation method may seem inefficient at first glance because it requires storing all states of each block, but in fact, the confirmation efficiency of Ethereum can be comparable to that of Bitcoin. The reason is that the state is stored in a tree structure, and with each additional block, only a small part of the tree structure needs to change. Therefore, generally speaking, most of the tree structure of two adjacent blocks should be the same, allowing for data to be stored once and referenced twice using pointers (i.e., subtree hashes). A tree structure known as the "Patricia Tree" can achieve this, which includes modifications to the Merkle tree concept, allowing not only for node changes but also for the insertion and deletion of nodes. Additionally, because all state information is part of the last block, there is no need to store the entire block history—this method, if applicable to the Bitcoin system, could save storage space by a factor of 10-20.

Applications Generally speaking, there are three types of applications on Ethereum. The first type is financial applications, providing users with more powerful ways to manage their money and participate in contracts. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and even some types of comprehensive employment contracts. The second type is semi-financial applications, where money exists but there are also significant non-monetary aspects; a perfect example is self-enforced bounties set to solve computational problems. Finally, there are completely non-financial applications such as online voting and decentralized governance.

Token Systems On-chain token systems have many applications, from representing sub-currencies like dollars or gold to company stocks, unique tokens representing smart assets, secure and non-falsifiable coupons, and even token systems used for point rewards that have no connection to traditional value. Implementing a token system in Ethereum is surprisingly easy.

The key point is to understand that all currencies or token systems fundamentally operate as a database with the following operations: subtract X units from A and add X units to B, provided that (1) A has at least X units before the transaction and (2) the transaction is approved by A.

Implementing a token system is about implementing such logic into a contract. The basic code for implementing a token system using the Serpent language is as follows:

This is essentially a minimal implementation of the "banking system" state transition function that this article will further describe. Additional code needs to be added to provide functionality for distributing currency in initial and other edge cases, ideally adding a function for other contracts to query the balance of an address. That would be sufficient.

Theoretically, token systems acting as sub-currencies based on Ethereum may include an important feature that the on-chain metacoins based on Bitcoin lack: the ability to directly pay transaction fees with this currency. The way to implement this capability is to maintain an Ether account in the contract to pay for the transaction fees of the sender, by collecting the internal currency used as transaction fees and auctioning them off in an ongoing auction, continuously funding that Ether account. Thus, users need to "activate" their accounts with Ether, but once there is Ether in the account, it will be reused because each contract will recharge it.

Financial Derivatives and Stable Value Currencies Financial derivatives are the most common application of "smart contracts" and one of the easiest to implement with code. The main challenge of implementing financial contracts is that most of them need to reference an external price oracle; for example, a highly demanded application is a smart contract used to hedge against the price fluctuations of Ether (or other cryptographic currencies) relative to the dollar, but that contract needs to know the price of Ether relative to the dollar. The simplest method is through a "data provider" contract maintained by a specific institution (such as NASDAQ), designed to allow that institution to update the contract as needed and provide an interface for other contracts to obtain price information by sending a message to that contract.

When these key elements are in place, a hedging contract might look like this: Wait for A to input 1000 Ether. Wait for B to input 1000 Ether.

By querying the data provider contract, record the dollar value of 1000 Ether, for example, x dollars, into storage. After 30 days, allow A or B to "reactivate" the contract to send Ether worth x dollars (re-query the data provider contract for the new price and calculate) to A and send the remaining Ether to B. Such contracts have extraordinary potential in cryptographic commerce. One problem often criticized about cryptographic currencies is their price volatility; while many users and merchants may need the security and convenience offered by cryptographic assets, they are unlikely to be willing to face a situation where their assets lose 23% of their value in a single day. Until now, the most common recommendation has been for issuers to back the assets; the idea is that the issuer creates a sub-currency for which they have the right to issue and redeem, giving a unit of the specific related asset (such as gold or dollars) to someone who provides them with one unit of the sub-currency.

The issuer promises to return one unit of the related asset when anyone returns one unit of the cryptographic asset. This mechanism allows any non-cryptographic asset to be "upgraded" to a cryptographic asset, provided the issuer is trustworthy. However, in practice, issuers are not always trustworthy, and in some cases, the banking system is too fragile or not honest enough to allow such services to exist.

Financial derivatives provide an alternative. Here, there will no longer be a separate issuer providing reserves to back an asset; instead, there will be a decentralized market composed of speculators betting that the price of a cryptographic asset will rise. Unlike issuers, the speculator side has no bargaining power because the hedging contracts freeze their reserves in the contract. Note that this approach is not completely decentralized, as a trusted data source for price information is still needed; however, it is still a significant improvement in reducing infrastructure needs (unlike issuers, a price oracle does not need a license and seems to fall under the category of free speech) and reducing potential fraud risks.

Identity and Reputation Systems#

The earliest alternative token, Namecoin, attempted to provide a name registration system using a Bitcoin-like blockchain, where users could register their names and other data in a public database. The most common application case maps domain names like "bitcoin.org" (or in Namecoin, "bitcoin.bit") to an IP address in the domain name system. Other application cases include email verification systems and potentially more advanced reputation systems. Here is the basic contract for providing a name registration system similar to Namecoin in Ethereum:

The contract is very simple; it is a database that can be added to but not modified or removed in the Ethereum network. Anyone can register a name as a value that remains unchanged forever. A more complex name registration contract would include "function clauses" that allow other contracts to query, as well as a mechanism for the "owner" of a name (i.e., the "first registrant") to modify data or transfer ownership. Reputation and trust network functions could even be added on top of it.

Decentralized Storage In recent years, several popular online file storage startups have emerged, the most prominent being Dropbox, which seeks to allow users to upload their hard drive backups, provide backup storage services, and allow users to access them, charging users monthly.

However, at this point, the file storage market is sometimes relatively inefficient; a rough observation of existing services indicates that especially at the "uncanny valley" level of 20-200GB, where there is neither free space nor enterprise-level user discounts, mainstream file storage costs mean paying the cost of an entire hard drive in a month. Ethereum contracts allow for the development of a decentralized storage ecosystem, enabling users to reduce file storage costs by renting out their own hard drives or unused network space for a small profit. The fundamental component of such a facility is what we call a "decentralized Dropbox contract."

This contract works as follows.

First, someone splits the data that needs to be uploaded into chunks, encrypts each chunk to protect privacy, and builds a Merkle tree from this. Then, a contract is created with the following rules: for every N chunks, the contract will draw a random index from the Merkle tree (using the hash of the previous chunk accessible to the contract code to provide randomness), and then give the first entity X Ether to support proof of ownership of a chunk at a specific index in the tree, similar to simplified payment verification (SPV). When a user wants to re-download their file, they can use a micropayment channel protocol (for example, paying 1 Satoshi for every 32k bytes) to restore the file; from a cost perspective, the most efficient way is for the payer not to publish the transaction until the very end but to replace the original transaction with a slightly more cost-effective one with the same random number after every 32k bytes. An important feature of this protocol is that, while it seems like a person is trusting many random nodes that are not prepared to lose files, they can secret share the file into many small chunks and then monitor the contract to know that each small chunk is still being stored by some node. If a contract is still in payment, it provides evidence that someone is still storing the file.

Decentralized Autonomous Organizations (DAOs)#

In a general sense, the concept of a "Decentralized Autonomous Organization (DAO)" refers to a virtual entity with a certain number of members or shareholders, relying on a majority of, say, 67% to decide on spending and modifying code. Members collectively decide how the organization allocates funds. The methods of allocating funds may include bounties, salaries, or more attractive mechanisms such as rewarding work with internal currency. This fundamentally replicates the legal meaning of traditional companies or non-profit organizations for enforcement using cryptographic blockchain technology. So far, much of the discussion around DAOs has revolved around a "Decentralized Autonomous Corporation (DAC)" model with shareholders who receive dividends and tradable shares; as an alternative, an entity described as a "Decentralized Autonomous Community" would give all members equal rights in decision-making and require a 67% majority agreement when adding or removing members. The rule that everyone can only have one membership needs to be enforced by the group.

Below is an outline of how to implement a DAO with code. The simplest design is a piece of code that can self-modify if two-thirds of the members agree. Although theoretically, the code is immutable, it can still be easily circumvented by placing the main code in a separate contract and pointing the address of the contract call to a modifiable storage. In a simple implementation of such a DAO contract, there are three transaction types distinguished by the data provided by the transaction:

• [0,i,K,V] Register a proposal to change the content at storage address indexed by K to v, indexed by i.
• [0,i] Register a vote on proposal i.
• [2,i] Confirm proposal i if there are enough votes.

The contract will maintain a record of all changes to open storage and a table of who voted. There will also be a table of all members. When any change to storage content receives two-thirds majority approval, a final transaction will execute that change. A more complex framework would add built-in election features to implement functions such as sending transactions, adding or removing members, or even providing delegated democracy-like voting representatives (i.e., anyone can delegate another person to vote on their behalf, and this delegation can be passed on, so if A delegates to B and B delegates to C, then C will decide A's vote).

This design will allow the DAO to organically grow as a decentralized community, enabling people to ultimately delegate the task of selecting suitable candidates to experts. Unlike the current system, as community members continuously change their positions, experts will easily emerge and disappear over time. An alternative model is a decentralized company, where any account can own 0 or more shares, and decisions require two-thirds majority approval of the shares.

A complete framework would include asset management functions—capable of submitting buy and sell orders for shares and accepting such orders (provided there is an order matching mechanism in the contract).

Representatives still exist in a delegated democracy manner, giving rise to the concept of a "board of directors." More advanced organizational governance mechanisms may be realized in the future; for now, a decentralized organization (DO) can be described starting from a decentralized autonomous organization (DAO). The distinction between DO and DAO is vague; a rough dividing line is whether governance can be achieved through a political-like process or an "automatic" process. A good intuitive test is the "no common language" standard: if two members do not speak the same language, can the organization still function normally?

Clearly, a simple traditional stock-based company would fail, while something like the Bitcoin protocol is likely to succeed. Robin Hanson's "futarchy," a mechanism for organizational governance achieved through prediction markets, is a real illustration of what "autonomous" governance might look like. Note that one does not need to assume that all DAOs are superior to all DOs; autonomy is simply a paradigm that has significant advantages in some specific scenarios but may not be feasible elsewhere, and many semi-DAOs may exist. Further Applications

1. Savings Wallet. Suppose Alice wants to ensure her funds are secure, but she is worried about losing or having her private key stolen. She puts her Ether into a contract with Bob, which acts as a bank:

Alice can withdraw up to 1% of the funds per day on her own. Bob can withdraw up to 1% of the funds per day on his own, but Alice can use her private key to create a transaction that cancels Bob's withdrawal rights. Alice and Bob can withdraw funds together at will. Generally, 1% per day is sufficient for Alice; if she wants to withdraw more, she can contact Bob for assistance. If Alice's private key is stolen, she can immediately find Bob to transfer her funds to a new contract. If she loses her private key, Bob can slowly withdraw the money. If Bob acts maliciously, she can revoke his withdrawal rights.

2. Crop Insurance. A person can easily create a financial derivative contract based on weather conditions rather than any price index. If a farmer in Iowa purchases a financial derivative that pays out based on Iowa's rainfall, then in the event of a drought, that farmer will automatically receive payout funds, and if there is sufficient rainfall, he will be happy because his crop yield will be good.

3. A Decentralized Data Publisher. For financial contracts based on differences, it is indeed possible to decentralize data publishers through a "Schelling Point" protocol. The way the Schelling Point works is as follows: N parties provide input values to the system for a specified data (e.g., ETH/USD price), all values are sorted, and nodes providing values between 25% and 75% will receive rewards; everyone has an incentive to provide answers that others will provide, and the answer that a large number of players can genuinely agree on is implicitly the correct answer, constructing a decentralized protocol that can theoretically provide many values, including ETH/USD prices, the temperature in Berlin, or even the result of a particularly difficult computation.

4. Multisignature Smart Contracts. Bitcoin allows for transaction contracts based on multisignatures; for example, gathering 3 out of 5 private keys can use the funds. Ethereum can do this more granularly; for example, gathering 4 out of 5 private keys can spend all funds, if only 3 keys are gathered, a maximum of 10% of the funds can be spent per day, and if only 2 keys are gathered, only 0.5% of the funds can be spent per day. Additionally, multisignatures in Ethereum are asynchronous, meaning that both parties can register their signatures on the blockchain at different times, and once the last signature is in place, the transaction will be automatically sent.

5. Cloud Computing. EVM technology can also be used to create a verifiable computing environment, allowing users to invite others to compute and selectively require evidence that the computation was completed correctly at certain randomly chosen checkpoints. This makes it possible to create a cloud computing market where any user can participate using their desktop, laptop, or dedicated server, with on-site checks and security deposits used to ensure the system is trustworthy (i.e., no node can profit from cheating). While such a system may not be suitable for all tasks; for example, tasks requiring advanced inter-process communication are not easy to complete on a large node cloud. However, some other tasks can be easily parallelized; projects like SETI@home, folding@home, and genetic algorithms can easily be conducted on such a platform.

6. Peer-to-Peer Gambling. Any number of peer-to-peer gambling protocols can be moved to the Ethereum blockchain, such as Frank Stajano and Richard Clayton's Cyberdice. The simplest gambling protocol is actually a simple contract that bets on the difference between the hash value of the next block and the guessed value, thus creating more complex gambling protocols to achieve near-zero fees and fraud-free gambling services.

7. Prediction Markets. Whether with oracles or Schelling coins, prediction markets will be easy to implement, and prediction markets with Schelling coins may prove to be the first mainstream application of "futarchy" as a decentralized organization management protocol.

8. On-chain decentralized markets, based on identity and reputation systems.

Miscellaneous and Concerns#

Implementation of the Improved Ghost Protocol The "Ghost" protocol (Greedy Heaviest Observed Subtree) was introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013. The motivation for the Ghost protocol is that the current fast-confirmation blockchain suffers from low security due to the high abandonment rate of blocks; because blocks take a certain time (set as t) to propagate throughout the network, if miner A mines a block and then miner B happens to mine another block before A's block propagates to B, B's block will be abandoned and contribute nothing to network security. Additionally, there is a centralization problem: if A is a mining pool with 30% of the network's computing power and B has 10%, A will face a 70% risk of producing abandoned blocks while B will face a 90% risk of producing abandoned blocks. Therefore, if the abandonment rate is high, A will simply be more efficient due to its higher share of computing power, and combining these two factors, a blockchain that produces blocks quickly is likely to lead to a mining pool that effectively controls the mining process.

As Sompolinsky and Zohar described, by including abandoned blocks in the calculation of which chain is "longest," the Ghost protocol solves the first problem of reducing network security; that is, not only the parent block of a block and earlier ancestor blocks, but also the abandoned descendant blocks of ancestor blocks (referred to as "uncle blocks" in Ethereum terminology) are included in the calculation of which block has the most proof of work supporting it. We have gone beyond the protocol described by Sompolinsky and Zohar to solve the second problem—centralization tendency—by rewarding abandoned blocks that contribute to confirming new blocks with 87.5% of the reward, while those included in the calculation as "nephew blocks" will receive a reward of 12.5%, although transaction fees are not rewarded to uncle blocks. Ethereum has implemented a simplified version of the Ghost protocol that only goes down to the fifth layer.

The characteristic is that abandoned blocks can only be included in the calculations as uncle blocks by their parent blocks' second to fifth generation descendant blocks, and not by descendant blocks of further relationships (for example, the sixth generation descendant blocks of the parent block, or the third generation descendant blocks of the grandparent block). This is done for several reasons. First, unconditional Ghost protocols would introduce excessive complexity in calculating which uncle block is legitimate for a given block. Second, the unconditional Ghost protocol with the compensation used by Ethereum deprives miners of the incentive to mine on the main chain rather than on a publicly attacked chain. Finally, calculations show that incentivized five-layer Ghost protocols achieve over 95% efficiency even with a block time of 15 seconds, while miners with 25% of the computing power gain less than 3% from centralization.

Fees#

Because each transaction published to the blockchain incurs costs for downloading and verification, there needs to be a normative mechanism that includes transaction fees to prevent the abuse of transactions. The default method used by Bitcoin is purely voluntary transaction fees, relying on miners to act as gatekeepers and set dynamic minimum fees. Because this method is "market-based," allowing miners and transaction senders to determine prices based on supply and demand, it has been smoothly accepted by the Bitcoin community. However, the logical problem with this is that transaction processing is not a market; while intuitively explaining transaction processing as a service provided by miners to senders is appealing, in fact, a transaction included by a miner requires processing by every node in the network, so the majority of the costs of transaction processing are borne by third parties rather than the miners deciding whether to include the transaction. Thus, a tragedy of the commons is very likely to occur. However, when given a specific imprecise simplified assumption, the flaws of this market-based mechanism miraculously eliminate their impact. The argument is as follows. Assume:

1. A transaction brings k operations, providing a reward of kR to any miner that includes that transaction, where R is set by the transaction publisher, and k and R are roughly visible to miners in advance.

2. Each node incurs a cost of C for processing each operation (i.e., all nodes are equally efficient).

3. There are N mining nodes, each with equal computing power (i.e., 1/N of the total network's computing power).

4. There are no non-mining full nodes.

When the expected reward exceeds the cost, miners are willing to mine. Thus, because miners have a 1/N chance of processing the next block, the expected profit is kR/N, and the miners' processing cost is simply kC. Therefore, when kR/N > kC, that is, R > NC, miners are willing to include the transaction. Note that R is the per-step fee provided by the transaction sender, which is the lower limit of the profit miners gain from processing the transaction. NC is the cost of the entire network processing an operation. Therefore, miners only have the motivation to include those transactions where the profit exceeds the cost.

However, these assumptions deviate from reality in several important ways:

1. The additional verification time delays the broadcast of blocks, thereby increasing the chance of blocks becoming abandoned; thus, the miners processing transactions incur higher costs than other validating nodes.
2. Non-mining full nodes do exist.
3. In practice, the distribution of computing power may ultimately be extremely uneven.
4. There are indeed speculators, political enemies, and madmen whose goal is to disrupt the network, and they can cleverly set up contracts that allow their costs to be much lower than those of other validating nodes.

The first point drives miners to include fewer transactions, and the second point increases NC; thus, the effects of these two points partially offset each other. The third and fourth points are the main issues; as a solution, we simply establish a floating upper limit: no block can contain more operations than BLK_LIMIT_FACTOR times the long-term exponentially moving average. Specifically:

Calculations and Turing Completeness It is important to emphasize that the Ethereum Virtual Machine is Turing complete; this means that EVM code can implement any imaginable computation, including infinite loops.

EVM code can implement loops in two ways.

First, the JUMP instruction allows the program to jump back to some point earlier in the code, and the JUMPI instruction allows for conditional jumps, enabling statements like while x < 27: x = x * 2. Second, contracts can call other contracts, potentially allowing for loops through recursion. This naturally leads to a question: can malicious users force miners and full nodes into infinite loops, causing them to shut down? This question arises from a problem in computer science known as the halting problem: in general, there is no way to know whether a given program will terminate in a finite amount of time.

As described in the state transition section, our solution is to set a maximum number of computational steps for each transaction; if exceeded, the computation is reverted to the original state but fees are still paid.

Messages work in the same way. To illustrate the motivation behind this solution, consider the following example: An attacker creates a contract that runs an infinite loop and then sends a transaction to miners to activate the loop, causing miners to process the transaction and run the infinite loop until the fuel runs out.

Even if the fuel runs out and the transaction halts midway, the transaction is still correct (reverting to the original state), and the miner still earns fees for each computational step from the attacker. An attacker creates a very long infinite loop intending to force miners to compute for a long time, causing several blocks to be produced before the computation ends, thus preventing miners from including transactions to earn fees. However, the attacker needs to publish a STARTGAS value to limit the executable steps, so miners will know in advance that the computation will consume too many steps.

An attacker sees a contract containing something like send(A,contract.storage[A]); contract.storage[A] = 0 and then sends a transaction with just enough fees to execute the first step but not enough to execute the second step (i.e., withdraw but not reduce the account balance).

The contract author need not worry about defending against such attacks because if execution halts midway, all changes are reverted. A financial contract relies on extracting the median from nine dedicated data publishers to minimize risk; an attacker takes over one of the data providers and then designs a variable address calling mechanism as described in the DAO section to turn the data provider into a running infinite loop, attempting to force any attempts to request funds from this financial contract to halt due to fuel exhaustion. However, the financial contract can set fuel limits in messages to guard against such issues. The alternative to Turing completeness is Turing incompleteness, where the JUMP and JUMPI instructions do not exist, and only one copy of each contract is allowed in the call stack at any given time.

In such a system, the aforementioned fee system and the uncertainty around the efficiency of our solution may be unnecessary because the cost of executing a contract would be determined by its size. Additionally, Turing incompleteness is not even a significant limitation; among all the contract examples we have internally envisioned, only one has required a loop, and even that loop could be replaced by repeating 26 single-line code segments. Considering the serious troubles and limited benefits that Turing completeness brings, why not simply use a Turing-incomplete language? In fact, Turing incompleteness is far from a concise solution.

Why? Consider the following contract:

Now, sending a transaction like this to A means that in 51 transactions, we have a contract that requires 250 computational steps, and miners might try to maintain a maximum executable step for each contract and calculate the possible execution steps for contracts that recursively call other contracts to preemptively detect such logic bombs, but this would prevent miners from creating contracts for others (because the creation and execution of the above 26 contracts can easily be placed into a single contract). Another problem is that the address field of a message is a variable, so generally speaking, it may not even be possible to know in advance which other contract a contract will call.

Thus, we ultimately arrive at a surprising conclusion:

Managing Turing completeness is astonishingly easy, while managing Turing incompleteness without the same controls is astonishingly difficult—so why not let the protocol be Turing complete? Currency and Issuance The Ethereum network includes its own built-in currency, Ether, which serves a dual role: providing primary liquidity for various digital asset transactions and, more importantly, providing a mechanism for paying transaction fees. To facilitate and avoid future disputes (see the current debates over mBTC/uBTC/satoshi), different denominations will be preset:

• 1: Wei
• 10^12: Gwei
• 10^15: Finney
• 10^18: Ether

This should be seen as an extension of the concepts of "dollars" and "cents" or "bitcoins" and "satoshis." In the near future, we expect "Ether" to be used for ordinary transactions, "Finney" for micropayments, and "Gwei" and "Wei" for discussions about fees and protocol implementations.

The issuance model is as follows:

• Ether will be sold at a price of 1337-2000 Ether per BTC through a sale event, a mechanism aimed at raising funds for the Ethereum organization and compensating developers has been successfully used on other cryptographic currency platforms. Early buyers will enjoy significant discounts, and the proceeds from the sale will be used entirely to pay salaries and bounties for developers and researchers, as well as to invest in projects within the cryptographic currency ecosystem.

• 0.099x (where x is the total amount sold) will be allocated to early contributors who participated in development before BTC funding or other deterministic funding success, and another 0.099x will be allocated to long-term research projects.

Starting from the launch, there will be 0.26x (where x is the total amount sold) mined by miners each year.

The issuance breakdown of the permanent linear growth model reduces the risk of wealth concentration that appears in Bitcoin and gives people living now and in the future a fair opportunity to acquire currency while maintaining incentives for acquiring and holding Ether, as the "currency supply growth rate" tends toward zero in the long term. We also infer that over time, there will always be losses of coins due to carelessness and death; assuming that the loss of coins is a fixed proportion of the currency supply each year, the total circulating currency supply will eventually stabilize at a value equal to the annual currency issuance divided by the loss rate (for example, when the loss rate is 1%, when the supply reaches 30x, 0.3x will be mined each year while 0.3x will be lost, reaching an equilibrium).

In addition to the linear issuance method, like Bitcoin, the growth rate of Ether's supply tends toward zero in the long term.

Centralization of Mining The Bitcoin mining algorithm essentially allows miners to make millions of slight modifications to the block header until the hash of a particular node's modified version is less than the target value (currently about 2^190). However, this mining algorithm is susceptible to two forms of centralization attacks.

The first is that the mining ecosystem is controlled by ASICs (Application-Specific Integrated Circuits) and computer chips specifically designed to improve efficiency in Bitcoin mining by thousands of times. This means that Bitcoin mining is no longer highly decentralized and egalitarian, but requires significant capital for effective participation.

The second is that most Bitcoin miners no longer complete block validation locally; instead, they rely on centralized mining pools to provide block headers. This issue can be said to be serious: at the time of writing this article, the two largest mining pools indirectly control about 50% of the total network's computing power, although the fact that miners can switch to other pools when a pool or consortium attempts a 51% attack mitigates the severity of the problem.

Ethereum's current goal is to use a mining algorithm based on randomly generating unique hashes for every 1000 random numbers, using a sufficiently wide computational domain to eliminate the advantages of specialized hardware. This strategy will not reduce centralization gains to zero, but it does not need to. Note that each individual user can almost freely complete a certain amount of mining activity using their personal laptop or desktop, but once they reach 100% CPU usage, more mining will require them to pay for electricity and hardware costs.

ASIC mining companies need to pay for electricity and hardware costs from the very first hash. Therefore, if centralization gains can be kept below (E + H)/E, then even if ASICs are produced, ordinary miners will still have room to survive. Additionally, we plan to design the mining algorithm so that mining requires access to the entire blockchain, forcing miners to store the complete blockchain or at least be able to verify each transaction. This removes the need for centralized mining pools; although pools can still play a role in smoothing out the distribution of rewards, this function can be accomplished just as well by P2P mining pools without centralized control. Thus, even if most ordinary users still tend to choose light clients, increasing the number of full nodes in the network also helps resist centralization.

Scalability Scalability issues are a common concern for Ethereum, and like Bitcoin, Ethereum suffers from the dilemma that each transaction needs to be processed by every node in the network.

The current size of the Bitcoin blockchain is about 20GB, growing at a rate of 1MB per hour. If the Bitcoin network processes Visa-level transactions of 2000 tps, it will grow at a rate of 1MB every three seconds (1GB per hour, 8TB per year). Ethereum may also experience similar or even worse growth patterns, as there are many applications on the Ethereum blockchain, rather than just simple currency like Bitcoin, but the fact that Ethereum full nodes only need to store the state rather than the complete blockchain history improves the situation.

The problem with large blockchains is the risk of centralization. If the blockchain size increases to, say, 100TB, a possible scenario would be that only a very small number of large merchants would run full nodes, while regular users would use light SPV nodes. This would increase concerns about collusion among full node partners to defraud (for example, changing block rewards to give themselves BTC). Light nodes would have no way to immediately detect such fraud. Of course, there may at least be one honest full node, and information about the fraud would leak through channels like Reddit several hours later, but by then it would be too late: no matter how much effort ordinary users make to invalidate the blocks that have already been produced, they will face a huge coordination problem on the scale of launching a successful 51% attack. In Bitcoin, this is currently a problem, but a modification suggested by Peter Todd could alleviate this issue.

In the near future, Ethereum will use two additional strategies to address this issue.

First, because of the blockchain-based mining algorithm, at least every miner will be forced to be a full node, ensuring a certain number of full nodes. Second, and more importantly, after processing each transaction, we will include the root of an intermediate state tree in the blockchain. Even if block validation is centralized, as long as there is one honest validating node, the centralization problem can be avoided through a validation protocol. If a miner publishes an incorrect block, that block will either be incorrectly formatted or the state S[n] will be incorrect.

Since S[0] is correct, there must be a first erroneous state S[i] but S[i-1] is correct; the validating node will provide index i along with a subset of the Patricia tree nodes required to process APPLY(S[i-1],TX[i]) to see whether the resulting S[i] matches the previously provided value.

Additionally, it is more complex if a malicious miner publishes incomplete blocks to attack, resulting in insufficient information to determine whether the block is correct. The solution is a challenge-response protocol:

The validating node challenges the target transaction index, and the light nodes receiving the challenge will distrust the corresponding block until another miner or validator provides a subset of Patricia nodes as correct evidence.

Summary: Decentralized Applications The aforementioned contract mechanisms allow anyone to establish command-line applications running through global consensus on a virtual machine (fundamentally speaking), capable of changing a globally accessible state as its "hard drive." However, for most people, the command-line interface used as a transaction sending mechanism lacks sufficient user-friendliness to make decentralization an attractive alternative. Ultimately, a complete "decentralized application" should include underlying business logic components (whether fully implemented in Ethereum, using a combination of Ethereum and other systems (such as a P2P messaging layer, which is planned to be integrated into the Ethereum client), or only other systems) and upper-layer graphical user interface components. The Ethereum client is designed to function as a web browser but includes support for the "eth" JavaScript API object, which can be used by specific web pages visible in the client to interact with the Ethereum blockchain. From the perspective of "traditional" web pages, these pages are completely static content, as the blockchain and other decentralized protocols will completely replace servers to handle user-initiated requests.

Finally, decentralized protocols have the hope of utilizing Ethereum in some way to store web pages. Conclusion The Ethereum protocol was initially conceived as an upgraded cryptographic currency providing advanced features such as on-chain contracts, withdrawal limits, financial derivatives, gambling markets, etc., through a highly general language. The Ethereum protocol will not directly "support" any applications, but the existence of a Turing-complete programming language means that, theoretically, any contract can be created for any type of transaction and application.

However, what is more interesting about Ethereum is that the Ethereum protocol goes further than mere currency, establishing protocols and decentralized applications built around decentralized storage, decentralized computing, decentralized prediction markets, and dozens of similar concepts, with the potential to fundamentally enhance the efficiency of the computing industry and provide strong support for other P2P protocols by adding an economic layer for the first time. Ultimately, there will also be a large number of applications that have nothing to do with money.

The concept of arbitrary state transitions enabled by the Ethereum protocol provides a platform with unique potential; unlike closed protocols designed for single purposes such as data storage, gambling, or finance, Ethereum is inherently open, and we believe it is extremely suitable as a foundational layer to serve the vast number of financial and non-financial protocols that will emerge in the coming years.

Annotations and Further Reading
Annotations

1. An experienced reader will note that Bitcoin addresses are actually hashes of elliptic curve public keys, not the public keys themselves; however, it is entirely reasonable to refer to the public key hash as the public key from a cryptographic perspective. This is because Bitcoin cryptography can be viewed as a customized digital signature algorithm, where the public key consists of the hash of the elliptic curve public key, and the signature is connected to the elliptic curve public key, while the verification algorithm includes checking the elliptic curve public key using the elliptic curve public key hash provided as the public key, followed by verifying the elliptic curve signature with the elliptic curve public key.

2. Technically speaking, the median of the first 11 blocks.

3. Internally, 2 and "CHARLIE" are both numbers, with the latter having a huge base256 encoding format, and numbers can range from 0 to 2^256-1.

Further Reading

4. Intrinsic value: https://tinyurl.com/BitcoinMag-IntrinsicValue

5. Smart property: https://en.bitcoin.it/wiki/Smart_Property

6. Smart contracts: https://en.bitcoin.it/wiki/Contracts

7. B-money: http://www.weidai.com/bmoney.txt

8. Reusable proofs of work: http://www.finney.org/~hal/rpow/

9. Secure property titles with owner authority: http://szabo.best.vwh.net/securetitle.html

10. Bitcoin whitepaper: http://bitcoin.org/bitcoin.pdf

11. Namecoin: https://namecoin.org/

12. Zooko's triangle: http://en.wikipedia.org/wiki/Zookos_triangle

13. Colored coins whitepaper: https://tinyurl.com/coloredcoin-whitepaper

14. Mastercoin whitepaper: https://github.com/mastercoin-MSC/spec

15. Decentralized autonomous corporations, Bitcoin Magazine: https://tinyurl.com/Bootstrapping-DACs

16. Simplified payment verification: https://en.bitcoin.it/wiki/Scalability#Simplifiedpaymentverification

17. Merkle trees: http://en.wikipedia.org/wiki/Merkle_tree

18. Patricia trees: http://en.wikipedia.org/wiki/Patricia_tree

19. GHOST: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf

20. Hubwiz.com Ethereum white paper Chinese version

21. StorJ and Autonomous Agents, eff Garzik: https://tinyurl.com/storj-agents

22. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y

23. Ethereum RLP: <https://github.com/ethereum/wiki