Bitcoin was revolutionary because it was the first digital asset with no backing, intrinsic value, centralized issuer or controller. Most important, it used blockchain, a tool of distributed consensus. The Ethereum protocol was originally conceived as an upgraded version of a cryptocurrency, but its Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application. Thus, its applications extend far beyond the economic realm to areas that have nothing to do with money at all.
The idea of decentralized digital currency has been around for a while, but there are three major ideas that enabled its implementation: 1. The concept of creating money by solving computational puzzles that are verified through decentralized consensus (Wei Dei's b-money, 1998) 2. reusable proofs of work as a system of implementing decentralized consensus (Hal Finney, 2005) 3. Proof of work, which combines ideas 1 and 2 (Satoshi Nakomoto's Bitcoin, 2009) 4. Proof of stake, an alternative to idea 3 that calculates the weight of a node as proportional to its currency holdings and not computational resources
Adds a simple+effective consensus algorithm to the public key cryptography in order for the nodes in the network to agree on a set of canonical updates to the state of the ledger: - Double-SHA256 hash of every block must be less than a target (~2^187, at the time of writing) - Only way to create a valid block is by trial and error: repeatedly incrementing the nonce and seeing if the new hash matches - Block creation is computationally hard - Prevents sybil attackers from remaking the entire blockchain in their favor - Weight of a node in consensus voting is proportional to its computing power - Network recalibrates the target every 2016 blocks (a new block is produced by some node in the network every ~10 min)
Any cryptocurrency ledger such as Bitcoin can be formulated as a state transition system, where a “state” (S) consists of ownership status of all existing bitcoins, or the UTXO (unspent transaction outputs). A “state transition function” takes a state and a transaction and outputs a new state as the result. We can define the state transition function APPLY(S, TX) —> S’ as: 1. For each input in TX, return an error if the referenced UTXO is not in S, or if the provided signature does not match the owner of the UTXO 2. If the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO, return an error 3. Return S’ with all input UTXO removed and all output UTXO added
Bitcoin’s decentralized consensus process requires all the nodes in the network continuously attempting to produce packages of transactions called “blocks”. Each block contains: - Timestamp - Nonce - Reference (i.e. hash of) the previous block - List of all the transactions that have taken place since the previous block. The block validation algorithm ensures that each transaction in the block provides a valid state transition from the canonical state before the transaction was executed to some new state: - Miner of every block is entitled to include a transaction giving themselves 12.5 BTC out of nowhere - Any transaction with more inputs than outputs, the difference goes to the miner as a “transaction fee” - State is not encoded in the block, but can be computed for any block starting from the genesis state - Order in which the miner includes transactions into the block matters - Only mechanism by which new BTC are issued; the genesis state contained no coins at all
A malicious attacker would target the one part of the system that doesn’t fall under direct protection of bitcoin’s cryptography (which is known to be secure). As a rule, the longest blockchain in a fork is taken as the truth, so the legitimate miners on the chain would usually outweigh the malicious fork. In order for an attacker to make his blockchain the longest he would need to have more computational power than the rest of the network combined, hence the 51%.
A type of binary tree where each node is the hash of its two children. It allows for the data in a block to be delivered piece by piece. This is because hashes propagate upward, so malicious users cannot swap in fake transactions at the bottom. This protocol is essential to long-term sustainability because of the sheer size of the data stored in one node alone. The tree is composed of: - Set of nodes with a large number of leaf nodes at the bottom of the tree, containing underlying data - Set of intermediate nodes - Single root node at the top
An alternative way to own UTXO in Bitcoin is via a script expressed in a simple stack-based programming language. Its uses include but aren’t limited to: - Transactions spending the UTXO - Basic public key ownership mechanisms are implemented via a script - Corporate accounts - Secure savings accounts - Pay bounties for solutions to computational problems - Cross-cryptocurrency exchange However, scripting language as implemented in bitcoin has some important limitations: - Lack of Turing-completeness --> doesn’t support all computation, namely loops - Value-blindness --> cannot provide fine-grained control over what amount gets withdrawn - Lack of state --> cannot have multi-stage contracts or scripts which have UTXO in a state other than spent or unspent - Blockchain-blindness --> UTXO are blind to blockchain data such as nonce, the timestamp, and previous block hash
Motivation: create an alternative protocol for building decentralized applications, with an emphasis on situations where it is important to have: - rapid development time - security for small and rarely used apps - Efficient interaction between different applications This is done via an abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own: - Arbitrary rules of ownership - Transaction formats - State transition functions This also allows for smart contracts, cryptographic “boxes” that contain value and only unlock it if certain conditions are met.
The state is made up of objects called “accounts”: - Each account has a 20-byte address and state transitions are direct transfers of value/information between account - An account has four fields: nonce (counter to verify each transaction is processed once), current ether balance, contract code (if present), storage (empty by default) - “Ether” is the main internal crypto-fuel of Ethereum used to pay transaction fees - “Contracts” are autonomous agents that live inside of the Ethereum execution environment, always executing a specific piece of code when “poked” by a message or transaction and have direct control over their own ether balance and their own key/value store to keep track of persistent variables There are two types of accounts: 1. Externally owned accounts (controlled by private keys, have no code, can send messages from these by creating and signing a transaction) 2. Contract accounts (controlled by their contract code, code activates every time the account receives a message, which enables it to read/write to internal storage and send other messages to create contracts in return)
A “Transaction” refers to the signed data package that stores a message to be sent from an externally owned account. Transactions contain: - Message recipient - Signature identifying sender - Optional data field - STARTGAS value (represents maximum number of computational steps the transaction execution is allowed to take) - GASPRICE value (represents the fee the sender pays per computational step)
Contracts can send messages to other contracts. Messages are virtual objects that are never serialized and exist only in the Ethereum execution environment. A message contains: - Message sender (implicit) - Message recipient - Amount of ether to transfer - Optional data field - STARTGAS value They are produced when a contract currently executing code executes the CALL opcode, which produces and executes a message. It leads to the recipient account running its code.
The Ethereum state transition function APPLY(S, TX) —> S’ is defined as follows: 1. Check validity of transaction fee 2. Calculate the transaction fee as STARTGAS * GASPRICE, update sender's account balance 3. Initialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction. 4. Transfer the transaction value from sender to reciever 5. Reset everything if there is an error 6. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.
Code in Ethereum contracts is written in a low-level, stack-based byte code language, referred to as “Ethereum virtual machine code” or “EVM code”. It consists of series of bytes, each representing an operation. Operations can store data in: 1. The stack: a last-in-first-out container to which values can be pushed and popped 2. Memory: an infinitely expandable byte array 3. Contract’s long-term storage: a key/value store
Ethereum blocks, unlike Bitcoin, contain: - Copy of the transaction list - Copy of the most recent state - Block number - Difficulty The basic block validation algorithm in Ethereum has: - Efficiency is comparable to Bitcoin - The process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm
There are three types of applications on top of Ethereum: 1. Financial applications —> provide users with more powerful ways of managing and entering into contracts using their money 2. Semi-financial applications —> money involved but there is also a heavy non-monetary side to what is being done 3. Non-financial applications —> e.g. online voting, decentralized governance, etc. Some notable applications of Ethereum are: - Token Systems - Financial derivatives and stable-value currencies - Identity and Reputation systems - Decentralized file storage - Decentralized autonomous organizations (DAO) - Savings wallets - Crop insurance - Decentralized data feed - Smart multi signature escrow - Cloud computing - Peer-to-peer gambling - Prediction markets - On-chain decentralized marketplaces
The Bitcoin mining algorithm is vulnerable to two forms of centralization: 1. Computer chips (ASICs) designed for the specific task of Bitcoin mining —> mining requires millions of dollars of capital to participate in 2. Most miners rely on a centralized mining pool to provide the block headers —> the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network Ethereum uses a mining algorithm where: - Miners fetch random data from the state - Compute randomly selected transactions from the last N blocks in the blockchain - Return a hash of the result This has the benefits: 1. Ethereum contracts can include any kind of computation (i.e. a better CPU) 2. Removes the need for centralized mining pools