Ethereum

History of Ethereum
• Vitalik Buterin
• Russian-Canadian programmer
• Co-founded Ethereum when he
was 19 years old

2
History of Ethereum -
Timeline

3
Introduction
• The intent of Ethereum is to create an alternative protocol for building
decentralized applications, providing a different set of tradeoffs that we believe
will be very useful for a large class of decentralized applications, with particular
emphasis on situations where rapid development time, security for small and
rarely used applications, and the ability of different applications to very
efficiently interact, are important.
• Ethereum does this by building what is essentially the ultimate 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 for ownership,
transaction formats and state transition functions.
Introduction
• The Ethereum blockchain is essentially a transaction-based state machine. In
computer science, a state machine refers to something that will read a series of
inputs and, based on those inputs, will transition to a new state.
Introduction
• With Ethereum’s state machine, we begin with a “genesis state.” This is
analogous to a blank slate, before any transactions have happened on the
network. When transactions are executed, this genesis state transitions into
some final state. At any point in time, this final state represents the current
state of Ethereum.

• The state of Ethereum has millions of transactions. These transactions are

grouped into “blocks.” A block contains a series of transactions, and each block
is chained together with its previous block.
Introduction
• To cause a transition from one state to the next, a transaction must be valid. For a
transaction to be considered valid, it must go through a validation process known
as mining. Mining is when a group of nodes (i.e. computers) expend their compute
resources to create a block of valid transactions.
• Any node on the network that declares itself as a miner can attempt to create and
validate a block. Lots of miners from around the world try to create and validate
blocks at the same time. Each miner provides a mathematical “proof” when
submitting a block to the blockchain, and this proof acts as a guarantee: if the
proof exists, the block must be valid.
• For a block to be added to the main blockchain, the miner must prove it faster
than any other competitor miner. The process of validating each block by having a
miner provide a mathematical proof is known as a “proof of work.”
• A miner who validates a new block is rewarded with a certain amount of value for
doing this work. The Ethereum blockchain uses an intrinsic digital token called
“Ether.” Every time a miner proves a block, new Ether tokens are generated and
Ethereum Network
• In the Ethereum universe, there is a single, canonical computer (called the
Ethereum Virtual Machine, or EVM) whose state everyone on the Ethereum
network agrees on.
• Everyone who participates in the Ethereum network (every Ethereum node)
keeps a copy of the state of this computer. Additionally, any participant can
broadcast a request for this computer to perform arbitrary computation.
• Whenever such a request is broadcast, other participants on the network verify,
validate, and carry out ("execute") the computation. This execution causes a
state change in the EVM, which is committed and propagated throughout the
entire network.
• Requests for computation are called transaction requests; the record of all
transactions and the EVM's present state gets stored on the blockchain, which in
turn is stored and agreed upon by all nodes.
Terminologies
EVM
• The Ethereum Virtual Machine is the global virtual computer whose state every participant on the Ethereum network stores and agrees on. Any
participant can request the execution of arbitrary code on the EVM; code execution changes the state of the EVM.
Nodes
• The real-life machines which are storing the EVM state. Nodes communicate with each other to propagate information about the EVM state and new
state changes. Any user can also request the execution of code by broadcasting a code execution request from a node. The Ethereum network itself is
the aggregate of all Ethereum nodes and their communications.
Accounts
• Where ether is stored. Users can initialize accounts, deposit ether into the accounts, and transfer ether from their accounts to other users. Accounts
and account balances are stored in a big table in the EVM; they are a part of the overall EVM state.
Transactions
• A "transaction request" is the formal term for a request for code execution on the EVM, and a "transaction" is a fulfilled transaction request and the
associated change in the EVM state.
Blocks
• The volume of transactions is very high, so transactions are "committed" in batches, or blocks. Blocks generally contain dozens to hundreds of
transactions.
State
• In the context of Ethereum, the state is an enormous data structure called a modified Merkle Patricia Trie, which keeps all accounts linked by hashes
and reducible to a single root hash stored on the blockchain.
Smart contracts
• A reusable snippet of code (a program) which a developer publishes into EVM state. Anyone can request that the smart contract code be executed by
making a transaction request.
EVM
• Ethereum is a distributed state machine. Ethereum's state is a large data
structure which holds not only all accounts and balances, but a machine state,
which can change from block to block according to a pre-defined set of rules,
and which can execute arbitrary machine code. The specific rules of changing
state from block to block are defined by the EVM.
Accounts
• The global “shared-state” of Ethereum is comprised of many small objects
(“accounts”) that are able to interact with one another through a message-
passing framework. Each account has a state associated with it and a 20-
byte address. An address in Ethereum is a 160-bit identifier that is used to
identify any account.
• There are two types of accounts:
• Externally owned accounts, which are controlled by private keys and have no
code associated with them.
• Contract accounts, which are controlled by their contract code and have code
associated with them.
Externally owned accounts vs. contract accounts
• An externally owned account can send messages to other externally owned
accounts OR to other contract accounts by creating and signing a transaction
using its private key.
• A message between two externally owned accounts is simply a value transfer. But a
message from an externally owned account to a contract account activates the contract
account’s code, allowing it to perform various actions (e.g. transfer tokens, write to
internal storage, mint new tokens, perform some calculation, create new contracts, etc.).
• Unlike externally owned accounts, contract accounts can’t initiate new
transactions on their own. Instead, contract accounts can only fire transactions
in response to other transactions they have received (from an externally owned
account or from another contract account)
Therefore, any action that occurs on the Ethereum
blockchain is always set in motion by transactions fired
from externally controlled accounts.
Account state
• The account state consists of four components, which are present regardless of
the type of account:
• nonce: If the account is an externally owned account, this number represents the number of transactions
sent from the account’s address. If the account is a contract account, the nonce is the number of contracts
created by the account.
• balance: The number of Wei owned by this address. There are 1e+18 Wei per Ether.
• storageRoot: A hash of the root node of a Merkle Patricia tree. This tree encodes the hash of the storage
contents of this account, and is empty by default.
• codeHash: The hash of the EVM (Ethereum Virtual Machine — more on this later) code of this account. For
contract accounts, this is the code that gets hashed and stored as the codeHash. For externally owned
accounts, the codeHash field is the hash of the empty string.
World state
• we know that Ethereum’s global state consists of a mapping between account
addresses and the account states. This mapping is stored in a data structure
known as a Merkle Patricia tree.
• A Merkle tree (or also referred as “Merkle trie”) is a type of binary tree
composed of a set of nodes with:
• a large number of leaf nodes at the bottom of the tree that contain the underlying data
• a set of intermediate nodes, where each node is the hash of its two child nodes
• a single root node, also formed from the hash of its two child node, representing the top
of the tree
Gas and payment
• One very important concept in Ethereum is the concept of fees. Every
computation that occurs as a result of a transaction on the Ethereum network
incurs a fee — there’s no free lunch! This fee is paid in a denomination called
“gas.”
• Gas is the unit used to measure the fees required for a particular
computation. Gas price is the amount of Ether you are willing to spend on every
unit of gas, and is measured in “gwei.” “Wei” is the smallest unit of Ether, where
10¹⁸ Wei represents 1 Ether. One gwei is 1,000,000,000 Wei.
• With every transaction, a sender sets a gas limit and gas price. The product
of gas price and gas limit represents the maximum amount of Wei that the
sender is willing to pay for executing a transaction.
Gas and payment
• For example, let’s say the sender sets the gas limit to 50,000 and a gas price to 20 gwei. This
implies that the sender is willing to spend at most 50,000 x 20 gwei = 1,000,000,000,000,000
Wei = 0.001 Ether to execute that transaction.

• Remember that the gas limit represents the maximum gas the sender is willing to spend
money on. If they have enough Ether in their account balance to cover this maximum, they’re
good to go. The sender is refunded for any unused gas at the end of the transaction,
exchanged at the original rate.
Gas and payment
• In the case that the sender does not provide the necessary gas to execute the transaction,
the transaction runs “out of gas” and is considered invalid. In this case, the transaction
processing aborts and any state changes that occurred are reversed, such that we end up
back at the state of Ethereum prior to the transaction. Additionally, a record of the
transaction failing gets recorded, showing what transaction was attempted and where it
failed. And since the machine already expended effort to run the calculations before running
out of gas, logically, none of the gas is refunded to the sender.
Gas and payment
• Where exactly does this gas money go? All the money spent on gas by the sender is sent to
the “beneficiary” address, which is typically the miner’s address. Since miners are
expending the effort to run computations and validate transactions, miners receive the gas
fee as a reward.

Typically, the higher the gas price the sender is willing to pay, the greater the value the miner
derives from the transaction. Thus, the more likely miners will be to select it. In this way, miners are
free to choose which transactions they want to validate or ignore. In order to guide senders
on what gas price to set, miners have the option of advertising the minimum gas price for
Transaction and messages
• We noted earlier that Ethereum is a transaction-based state machine. In other words,
transactions occurring between different accounts are what move the global state of
Ethereum from one state to the next.
• In the most basic sense, a transaction is a cryptographically signed piece of instruction that
is generated by an externally owned account, serialized, and then submitted to the
blockchain.
• There are two types of transactions: message calls and contract creations (i.e. transactions
that create new Ethereum contracts).
Transaction and messages
All transactions contain the following components, regardless of their type:
• nonce: a count of the number of transactions sent by the sender.
• gasPrice: the number of Wei that the sender is willing to pay per unit of gas required to execute the
transaction.
• gasLimit: the maximum amount of gas that the sender is willing to pay for executing this transaction.
This amount is set and paid upfront, before any computation is done.
• to: the address of the recipient. In a contract-creating transaction, the contract account address does
not yet exist, and so an empty value is used.
• value: the amount of Wei to be transferred from the sender to the recipient. In a contract-creating
transaction, this value serves as the starting balance within the newly created contract account.
• v, r, s: used to generate the signature that identifies the sender of the transaction.
• init (only exists for contract-creating transactions): An EVM code fragment that is used to initialize
the new contract account. init is run only once, and then is discarded. When init is first run, it returns
the body of the account code, which is the piece of code that is permanently associated with the
contract account.
• data (optional field that only exists for message calls): the input data (i.e. parameters) of the message
call. For example, if a smart contract serves as a domain registration service, a call to that contract
Transaction and messages
Block header
A block header is a portion of the block consisting of:
• parentHash: a hash of the parent block’s header (this is what makes the block set a “chain”)
• ommersHash: a hash of the current block’s list of ommers
• beneficiary: the account address that receives the fees for mining this block
• stateRoot: the hash of the root node of the state trie (recall how we learned that the state trie is stored in the
header and makes it easy for light clients to verify anything about the state)
• transactionsRoot: the hash of the root node of the trie that contains all transactions listed in this block
• receiptsRoot: the hash of the root node of the trie that contains the receipts of all transactions listed in this block
• logsBloom: a Bloom filter (data structure) that consists of log information
• difficulty: the difficulty level of this block
• number: the count of current block (the genesis block has a block number of zero; the block number increases by 1
for each each subsequent block)
• gasLimit: the current gas limit per block
• gasUsed: the sum of the total gas used by transactions in this block
• timestamp: the unix timestamp of this block’s inception
• extraData: extra data related to this block
• mixHash: a hash that, when combined with the nonce, proves that this block has carried out enough computation
Block header
Transaction Execution
We’ve come to one of the most complex parts of the Ethereum protocol: the execution of a transaction. Say you send
a transaction off into the Ethereum network to be processed. What happens to transition the state of Ethereum to
include your transaction?
• First, all transactions must meet an initial set of requirements in order to be executed. These
include:
• The transaction must be a properly formatted RLP. “RLP” stands for “Recursive Length Prefix”
and is a data format used to encode nested arrays of binary data. RLP is the format Ethereum
uses to serialize objects.
• Valid transaction signature.
• Valid transaction nonce. Recall that the nonce of an account is the count of transactions sent
from that account. To be valid, a transaction nonce must be equal to the sender account’s nonce.
• The transaction’s gas limit must be equal to or greater than the intrinsic gas used by the
transaction. The intrinsic gas includes:
• 1) a predefined cost of 21,000 gas for executing the transaction
• 2) a gas fee for data sent with the transaction (4 gas for every byte of data or code that equals zero, and 68 gas
for every non-zero byte of data or code)
• 3) if the transaction is a contract-creating transaction, an additional 32,000 gas
• 4) gas cost of each operation performed by transaction
Transaction Execution

•The sender’s account balance must have enough Ether to cover the “upfront” gas costs that the
sender must pay. The calculation for the upfront gas cost is simple: First, the transaction’s gas limit is
multiplied by the transaction’s gas price to determine the maximum gas cost. Then, this maximum
cost is added to the total value being transferred from the sender to the recipient.

If the transaction meets all of the above requirements for validity, then we move onto the next step.
First, we deduct the upfront cost of execution from the sender’s balance, and increase the nonce of
the sender’s account by 1 to account for the current transaction. At this point, we can calculate the
gas remaining as the total gas limit for the transaction minus the intrinsic gas used.
Transaction Execution
• Next, the transaction starts executing. Throughout the execution of a transaction, Ethereum keeps track
of the “substate.” This substate is a way to record information accrued during the transaction that will
be needed immediately after the transaction completes. Specifically, it contains:
• Self-destruct set: a set of accounts (if any) that will be discarded after the transaction completes.
• Log series: archived and indexable checkpoints of the virtual machine’s code execution.
• Refund balance: the amount to be refunded to the sender account after the transaction. Remember how we
mentioned that storage in Ethereum costs money, and that a sender is refunded for clearing up storage? Ethereum
keeps track of this using a refund counter. The refund counter starts at zero and increments every time the contract
deletes something in storage.
• Next, the various computations required by the transaction are processed.
• Once all the steps required by the transaction have been processed, and assuming there is no invalid
state, the state is finalized by determining the amount of unused gas to be refunded to the sender. In
addition to the unused gas, the sender is also refunded some allowance from the “refund balance” that
we described above.
• Once the sender is refunded:
• the Ether for the gas is given to the miner
• the gas used by the transaction is added to the block gas counter (which keeps track of the total gas used by all
transactions in the block, and is useful when validating a block)
• all accounts in the self-destruct set (if any) are deleted
Ethereum State Transition
Function
Ethereum State Transition
Function
The Ethereum state transition function, APPLY(S,TX) -> S' can be defined as
follows:
• Check if the transaction is well-formed (ie. has the right number of values), the signature
is valid, and the nonce matches the nonce in the sender's account. If not, return an error.
• Calculate the transaction fee as STARTGAS * GASPRICE, and determine the sending
address from the signature. Subtract the fee from the sender's account balance and
increment the sender's nonce. If there is not enough balance to spend, return an error.
• 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 the value transfer failed because the sender did not have enough money, or the code
execution ran out of gas, revert all state changes except the payment of the fees, and add
the fees to the miner's account.
• Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for
gas consumed to the miner.
Execution model
Before executing a particular computation, the processor (EVM) makes sure that
the following information is available and valid:
• System state
• Remaining gas for computation
• Address of the account that owns the code that is executing
• Address of the sender of the transaction that originated this execution
• Address of the account that caused the code to execute (could be different from the
original sender)
• Gas price of the transaction that originated this execution
• Input data for this execution
• Value (in Wei) passed to this account as part of the current execution
• Machine code to be executed
• Block header of the current block
• Depth of the present message call or contract creation stack