This is a note of Ethereum whitepaper published in 2013 by Vitalik Buterin. The blockchain technology used by Bitcoin is a tool of distributed consenses that can be used in digital assets, ownership of physical device, non-fungible assets, as well as more complext applications involving having digital assets being directly controlled by code implemented as smart contracts or decentralized autonomous organization (DAO). Ethereum provides a blockchain-based programming language that can be used to create “contracts” that can be used to encode arbitrary state transition funcitons, allowing users to create any applications, simply by writing up the logic in a few lines of code.

1 Bitcoin Concepts

1.1 History

In 2019, Satoshi Nakamoto created Bitcoin by combining established primitives for managing owneership through public key cryptography with a consensus algorithm for keeping track of who owns coins. The consensus algorithm uses “proof of work (PoW)” that solved two problems: first, it allows nodes in the network to collectively agree on a set of canonical updates to the state of the Bitcoin ledger. Second, it allows free entry into the consensus process and prevents sybil attacks. In proof of work approach, the weight of a node in the consensus voting process is directly proportional to the computing power that the node brings. An alternative approch is “proof of stake (PoS)": the weight of a node is propotional to its currency holdings and not computational resources. Both apparoaches can be used to serve as the backbone of a cryptocurrency.

1.2 State Transition

In Bitcoin, a “state” consisting of the ownership status of all existing bitcoins, technically called “unspent transaction outputs (UTXO)”, for all minted unspent coins. A “state transition function” takes a state and a transaction and outputs a new state. The state transition can be defined as APPLY(S, TX) -> S' or Error.

Each UTXO has a denomination and an owner. An owner is defined by a 20-byte address which is a cryptographic public key. A transaction contains one or more inputs and one or more output. An input contains a reference to an existing UTXO and a signature produced by the private key assoicated with the owner’s address. Each output contains a new UTXO to be added to the state. The state transition function verifies the UTXO validity, checks that the denominations of all input UTXO is equal or bigger than the denominations of all output UTXO. Then it returns a new state with all input UTXO removed and all output UTXO added.

1.3 Mining

To build a decentralized currency system, we need to combine the state transition system with a consensus system to ensure that everyone agrees on the order of transactions. Nodes in the Bitcoin network continuously produce packages of transactions called “blocks” at a rate of roughly one block every 10 minutes. Each block contains a timestamp, a nounce, a reference to (ie. hash of) the prevous block and a list of all of the transactions that have taken place since the previous block. Over time, this process 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 as follows:

  • check previous block
  • check timestamp is newer than that of the previous block and less than 2 hours into the future
  • check the proof of work on the block is valid
  • apply all transactions to get a new state, exit and return false if there is an error. Return true and register the new state if there is no error.

The condition for proof of work is that the double-SHA256 hash, a 256-bit number, of every block, must be less than a dynamically adjusted target. The target is approximately 2 ** 187. To meet this condition, a node repeatedly increments the nonce and see if the new hash matches. It is computationally hard. The network must take an average of 2 ** 69 tries before a valid block nonce is found. The target is recalibrated by the network every 2016 blocks so that on average a new block is produced by some node in the network every ten minutes.

To compensate miners for this computational work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere. Additionally, if any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a “transaction fee”. Incidentally, this is also the only mechanism by which BTC are issued; the genesis state contained no coins at all.

1.4 Merkle Trees

The “hash” of a block is only the hash of the block header. A block header is a roughly 200-byte piece of data that contains the timestamp, nonce, previous block hash and the root hash of a data strurcture call the “Merkle tree”. The Merkle tree stores all transactions in the block. A Merkle tree is a binary tree where leaf nodes at the bottom of the tree contain the transaction data. An intermediate node contains the hash of its two children, either two leafs or two intermediate nodes. Its root node, the tree top, has the hash of its two children. 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 Merkle tree relevant to them from another source, and still be assured that all of the data is correct.

The Merkle tree procotol is essential to long-term sustainability because a full blockchain gorws over gigabtye per month. A protocol known as “simplified payment verification” (SPV) allows “light nodes” to only download relevant partial data.

1.5 Alternative Blockchain Applications

  • Namecoin: decentralized name registration database.
  • Colored coins: a protocol to allow people to create their own digital currencies.
  • Metacoins: the idea is to create an arbitrary protocol that lives on top of Bitcoin.

There are two approaches to build a consensus protocol: building an independent network, and building a protocol on top of Bitcoin. The first approach requires bootstraping an independent blockchain, building and testing all the state transition and networking code. Vast majority of applications would be too small to warrant their own blockchain and there exists large classes of decentralized applications and autonomous organizations, that need to interact with each other. The Bitcoin-based approach doesn’t inherit the simplified payment verification feature of Bitcoin.

1.6 Scripting

Bitcoin has a weak version smart contracts. UTXO can be owned by scripts. The Bitcoin scripting language has several limitations:

  • lack of Turing-completness: It has no loop support.
  • value-blindness: UTXO is all-or-nothing, has no control over the amount.
  • lack of state: UTXO only has two states: spent or unspent. There are no internal states beyond the two.
  • Blockchain-blindness: UTXO are blind to blockchain data such as nonce, the timestamp and previous block hash.

Using a strong scripting language to build advanced applications is easy to implement and standardize.

2 Ethereum

The goal of Ethereum is to create a protocol for building decentralized applications. The objectives are rapid development time, security for small and rarely used applications, and easy interaction of different applications.

Ethereum creates a blockchain with a built-in Turing-complete programming language, allowing one to write smart contracts and decentralized applications with arbitrary rules of onwership, transaction format and state transition functions.

For example, a simple Namecoin can be written in two lines of code, currencies and reputation systems can be built in under twenty. Smart contracts can have arbitrary logics.

2.1 Accounts

The Ethereum state is made up of objects called “account”, with each account having a 20-byte address and state transition being direct transfers of value and information between accounts. An account has four fields:

  • nonce: a counter used to make sure each transaction can only be processed once.
  • ether balance: the account’s current balance. Ether is the crypto-fuel of Ethereum that is used to pay transaction fees.
  • contract code: the state transition function if present.
  • storage: internal data, empty by default.

There are two types of account:

  • externally owned accounts: controlled by private keys. No code present. One can send meesages by creating and signing a transaction.
  • contract accounts: controlled by contract code. Every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.

The “contracts” in Ethereum are not something that should be fulfilled or compiled with. They are autonomous agents that react on a message or a transaction and have direct control over their own ether balance and their key/value storage to keep track of persistent variables.

2.2 Messages and Transactions

A transaction is a signed data package that stores a message to be sent from an externally owned account. A transaction contains:

  • The recipient of the message
  • A signature identifying the sender
  • The amount of ether to be transferred from the sender to the recipient
  • An optional data field
  • A STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take
  • A GASPRICE value, representing the fee the sender pays per computational step

The STARTGAS set a limit of steps to prevent infinite loops. The fundamental unit of computation is gas, usually a computational step costs 1 gas, but some operations cost higher amounts of gas. There is a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay propotionately for every resource that they consume, including computation, bandwdith and storage.

2.3 Messages

Contracts send messages to other contracts. A message is a virtual object existing only in the Ethereum execution environment. It contains:

  • The sender (implicit)
  • The recipient
  • The amount of ether to transfer
  • An optional data filed
  • A STARTGAS value

A message is produced when a contract executes the CALL opcode, which produces and executes a message. Like a transaction, a message leads to the recipient account running its code.

The gas allowance is the total gas consumed by all sub-executions.

2.4 State Transition Function

The APPLY(S, TX) -> S' is defined as follows:

  • Validate the transaction
  • Calculate the fee as STARTGAS * GASPRICE, subtract the fee from sender’s account and increment the sender’s nonce.
  • Initialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction.
  • Transfer 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 there is an error, 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.

2.5 Code Execution

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 has 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.
  • 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 formal execution model of EVM code is simple.

2.6 Blockchain and Mining

The Ethereum blockchain is similar to the Bitcoin blockchain with some changes. Ethereum blocks contain a copy of both the transaction list and the most recent state. The block number and the difficulty, are also stored in the block.

A special kind of tree known as a “Patricia tree” is used to make the storage efficient. Because all of the state information is part of the last block, there is no need to store the entire blockchain history. The process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm

3 Applications

There are three types of applications: financial, semi-financial and non-financial such as online voting and decentralized governance.

3.1 Token Systems

A currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) 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.

It allows paying transaction fees directly in its currency.

3.2 Financial Derivatives and Stable-Value Currencies

The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker. The simplest way to do this is through a “data feed” contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.

A hedging contract would look as follows:

  1. Wait for party A to input 1000 ether.
  2. Wait for party B to input 1000 ether.
  3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x.
  4. After 30 days, allow A or B to “reactivate” the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B.

Such a contract would have significant potential in crypto-commerce because one of the main problems cited about cryptocurrency is the fact that it’s volatile. A decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays the trusted issuer role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow.

3.3 Identity and Reputation Systems

Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:

def register(name, value):
    if ![name]:[name] = value

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. One can even add reputation and web-of-trust functionality on top.

3.4 Decentralized File Storage


3.5 DAO

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.


3.6 Further Applicaitons

  • Saving wallets: rule of withdraw limit
  • Crop insurance: payment when wheater matches.
  • A decentralized data feed
  • Smart multisignature escrow.
  • Cloud computing
  • Peer-to-peer gambling: near-zero fees and impossible to cheat
  • Prediction markets
  • On-chain decentralized marketplaces using the identity and reputation system as a base.

4 Miscellanea and Concerns