Ethereum Whitepaper Summary Thread.
Today I have passed ~2 hours reading the Ethereum whitepaper.
Here is a brief summary to get an idea:
↓
Today I have passed ~2 hours reading the Ethereum whitepaper.
Here is a brief summary to get an idea:
↓
Table of Contents
What is Ethereum
Accounts
Ether
Contracts
Transactions
Messages
Message/Transactions
State Transition Function
Code Execution
Space types
EVM execution
Architectural difference
Block validation algorithm
State in the tree
Contract code exec
💯Days of Web3
↓
What is Ethereum
Accounts
Ether
Contracts
Transactions
Messages
Message/Transactions
State Transition Function
Code Execution
Space types
EVM execution
Architectural difference
Block validation algorithm
State in the tree
Contract code exec
💯Days of Web3
↓
What is Ethereum
Ethereum is a blockchain with a built-in Turing-complete programming language.
Anyone can write smart contracts and create their rules for:
- ownership
- transaction formats
- state transition functions
Ethereum is a blockchain with a built-in Turing-complete programming language.
Anyone can write smart contracts and create their rules for:
- ownership
- transaction formats
- state transition functions
Accounts
Ethereum's state is made up of accounts.
Accounts have
- a 20-byte address
- state transitions
Account's fields:
- nonce: (to make sure each transaction can only be processed once)
- current ether balance
- contract code (if present)
- storage (empty by default)
Ethereum's state is made up of accounts.
Accounts have
- a 20-byte address
- state transitions
Account's fields:
- nonce: (to make sure each transaction can only be processed once)
- current ether balance
- contract code (if present)
- storage (empty by default)
Ether
Ether is Ethereum's cryptocurrency.
It's used to pay transaction fees.
Account types:
- externally owned accounts (controlled by private keys)
- contract accounts (controlled by their contract code)
Ether is Ethereum's cryptocurrency.
It's used to pay transaction fees.
Account types:
- externally owned accounts (controlled by private keys)
- contract accounts (controlled by their contract code)
Contracts
They are autonomous agents that live inside of the execution environment.
They:
- execute a specific piece of code when poked by a message or transaction.
- have direct control over their own balance & their own key/value store to keep track of persistent variables.
They are autonomous agents that live inside of the execution environment.
They:
- execute a specific piece of code when poked by a message or transaction.
- have direct control over their own balance & their own key/value store to keep track of persistent variables.
Transactions
They are a signed data package that stores a message to be sent from an account.
They contain:
- message's recipient
- sender's signature
- ether to transfer
- data field
- STARTGAS: max steps an execution can take
- GASPRICE: fee the sender pays per step
They are a signed data package that stores a message to be sent from an account.
They contain:
- message's recipient
- sender's signature
- ether to transfer
- data field
- STARTGAS: max steps an execution can take
- GASPRICE: fee the sender pays per step
Messages
Contracts can send messages to other contracts.
They contain:
- message's sender
- recipient of the message
- ether to transfer alongside the message
- data field (optional)
- STARTGAS value
Contracts can send messages to other contracts.
They contain:
- message's sender
- recipient of the message
- ether to transfer alongside the message
- data field (optional)
- STARTGAS value
Message/Transaction
A message is produced:
- by a contract (not an external actor).
- when a contract code executes the CALL opcode.
A message leads to the recipient account running its code.
Contracts can have relationships with other contracts.
A message is produced:
- by a contract (not an external actor).
- when a contract code executes the CALL opcode.
A message leads to the recipient account running its code.
Contracts can have relationships with other contracts.
State Transition Function
In the pic below, you can see The Ethereum state transition function:
APPLY(S,TX) -> S'
Below are the 6 steps in detail:
(a whole thread should be dedicated to this).
ethereum.org/en/whitepaper/…
In the pic below, you can see The Ethereum state transition function:
APPLY(S,TX) -> S'
Below are the 6 steps in detail:
(a whole thread should be dedicated to this).
ethereum.org/en/whitepaper/…
Code Execution
EVM code: low-level, stack-based bytecode language
It's an infinite loop of:
- carrying out the operation at the current program counter
- incrementing program counter by one,
This until occurs:
- end of the code
- error
- STOP/RETURN instruction
EVM code: low-level, stack-based bytecode language
It's an infinite loop of:
- carrying out the operation at the current program counter
- incrementing program counter by one,
This until occurs:
- end of the code
- error
- STOP/RETURN instruction
Space types
Operations have access to 3 space types to store data:
- The stack: LIFO container to push/pop values.
- Memory: an infinitely expandable byte array.
- Storage: key/value store.
Stack & Memory reset after computation ends, but storage persists.
Operations have access to 3 space types to store data:
- The stack: LIFO container to push/pop values.
- Memory: an infinitely expandable byte array.
- Storage: key/value store.
Stack & Memory reset after computation ends, but storage persists.
EVM execution
While EVM is running, its state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas).
block_state: global state containing accounts, balances, storage.
A basic implementation is possible in a few hundred lines of code.
While EVM is running, its state can be defined by the tuple (block_state, transaction, message, code, memory, stack, pc, gas).
block_state: global state containing accounts, balances, storage.
A basic implementation is possible in a few hundred lines of code.
Architectural difference from Bitcoin
The main architectural difference between Ethereum and Bitcoin is that Ethereum blocks contain a copy of both:
- the transaction list
- the most recent state.
In the bloc are also stored:
- the block number
- the difficulty
The main architectural difference between Ethereum and Bitcoin is that Ethereum blocks contain a copy of both:
- the transaction list
- the most recent state.
In the bloc are also stored:
- the block number
- the difficulty
Block validation algorithm
1. Check if the previous block exists/is valid
2. Check that the block's timestamp is:
- greater previous block's one
- less than 15min into the future
3. Check the validity of:
- block number
- difficulty
- transaction root
- uncle root
- gas
↓
1. Check if the previous block exists/is valid
2. Check that the block's timestamp is:
- greater previous block's one
- less than 15min into the future
3. Check the validity of:
- block number
- difficulty
- transaction root
- uncle root
- gas
↓
4. Check that the proof-of-work on the block is valid
5. Let S[0] be the state at the end of the previous block.
↓
5. Let S[0] be the state at the end of the previous block.
↓
6. Let TX be the block's transaction list, with n transactions.
For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]).
It returns an error if:
- any app returns an error
- if the total gas consumed in the block up until this point exceeds the GASLIMIT
↓
For all i in 0...n-1, set S[i+1] = APPLY(S[i],TX[i]).
It returns an error if:
- any app returns an error
- if the total gas consumed in the block up until this point exceeds the GASLIMIT
↓
7. Let S_FINAL be S[n], but adding the block reward paid to the miner.
8. Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header:
✅If it is, the block is valid.
❌otherwise, it is not valid.
8. Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header:
✅If it is, the block is valid.
❌otherwise, it is not valid.
State in the tree
The state is stored in the tree structure.
After every block, only a small part of the tree needs to be changed.
Between two adjacent blocks, the majority of the tree is the same. The data can be:
- stored once
- referenced twice using pointers
The state is stored in the tree structure.
After every block, only a small part of the tree needs to be changed.
Between two adjacent blocks, the majority of the tree is the same. The data can be:
- stored once
- referenced twice using pointers
Contract code execution
It's part of the definition of the state transition function, which is part of the block validation algorithm:
1️⃣A transaction is added into block B
2️⃣ The code execution spawned will be executed by ALL nodes, since now, that download & validate block B
It's part of the definition of the state transition function, which is part of the block validation algorithm:
1️⃣A transaction is added into block B
2️⃣ The code execution spawned will be executed by ALL nodes, since now, that download & validate block B
💯Days of Web3
I am on the Challenge of posting one Web3 content every day for 100 Days.
Day 84
Here is a GitHub repository with all the posts, day by day.
github.com/FrancescoXX/10…
I am on the Challenge of posting one Web3 content every day for 100 Days.
Day 84
Here is a GitHub repository with all the posts, day by day.
github.com/FrancescoXX/10…
If you enjoyed this thread, follow @FrancescoCiull4 and retweet the tweet below. Thank you.
https://twitter.com/FrancescoCiull4/status/1502546837256945664
• • •
Missing some Tweet in this thread? You can try to
force a refresh
