Ethereum

High level info

Basics

Like any crypto: P2P network, any transaction with the blockchain costs gas, each transaction goes into a transaction pool

Ethereum specific:

• every slot (12 seconds), the network randomly selects a node in the network which must group transactions into a block (called "validator" or "block proposer"). Note: ETH Blocks are constant time! They don't depend on mining difficulty or whatever.
• the validator propagates the block to the network
• each node verifies the block (by reexecuting the transactions inside the block). If valid, the block is added to the database. If verifications are divergent, the validator resolves conflicts and chooses the node which has the most staked ETH.

Client account types

There are two types of client accounts: Externally Owned Account (EOA) (a person) and Contract account

	Externally Owned Account	Contract account
Has a balance	yes	yes
Has a private key	yes	no
Can store EVM code	no	yes
Can compile to EVM code	no	yes
Can store data	no	yes
When transaction received	update balance	execute code

Transactions

Two types of transactions:

• message call (standard transactions with values)
• smart contract transaction (value = 0), example transaction

Costs/Rewards

TODO

https://ethereum.org/en/developers/docs/mev/

• Each validator node must stake 32 ETH

Node architecture

sources

• Ethereum docs JSON-RPC methods
• Solidity Smart Contracts: Build Dapps in Ethereum Blockchain
• Ethereum EVM Illustrated
• geth documentation

The main component of an Ethereum node is the Ethereum client. The official client is geth. A node can also be simulated with ganache-cli.

The client provides:

• a JSON-RPC 2.0 API on port 8545. Used to interact with third parties program (example: web3.js)
• a websocket server
• IPC capabilities: full access to the API, but must be on the same host as the geth node
• blockchain state storage on the local filesystem via a sync mechanism

The client needs:

• a consensus client (connected via the api)
• a account management tool: single responsibility principle, user identity (public & private key) is stored in this tool, and not in the node
• a network id to connect to

Internals

Block

Can be addressed by:

• height (= absolute number)
• contents hash

properties/methods:

• fixed reward (3 ETH)
• proof of work data (target condition, seed hash etc)
• contains a variable (?) number transactions
• note: uncles can be addressed with their own methods

EVM

EVM is a stack-based machine which can store in memory or in the account storage. EVM dosen't contain registers!

EVM Code = assembly-like code.

Arguments/Return values are passed using memory.

Example EVM instructions

• SSTORE: store in the account storage
• MSTORE: store in the memory
• PUSH: push new operation on the stack

EVM code is the generated product of Solidity / Viper / LLL compilation.

Storage

synchronization: when two P2P clients synchronize themselves (ex: one miner mined one block and another mined another block)

• Sync status (start block, current block, highest block)

Utilities/Misc

• web3_clientVersion
• eth_protocolVersion
• net_version: get the network id (1 for Ethereum, 56 for BSC)
• Filters (provides notifications when a pending transaction arrive, or when a certain block arrives). Filters must be uninstalled manually or timeout after a period of time.
• Logs (attached to filters only)
• Direct calls: eth_call can call directly an object
• Whisper protocol (shh_version etc): a messaging system available for dapps. Can also have filters.

Swarm

source

P2P storage / content delivery service embedded into Ethereum. IPFS/Zeronet alternative. Contains an incentive layer to guarantee its use and decentralization.

protocol: bzz://

EVM Bytecode

Solidity -> EVM Bytecode

Symboles remplacés par constantes numériques Difficile à décompiler / récupérer le flow original Pas de struct, classes, objects ou methodes le bytecode est untyped

Vandal decompiler Gigahorse decompiler

Scaling

Basics

Gas

Gas = transaction fee Each block has a gas limit.

Blocks

• Parent -> Child graph
• multiple children can be created but 1 can be accepted in the blockchain

Corollary

• If we increase the gas limit, we can fit more transaction in a block ==> faster processing time but more used resources.
• If the blocks are too fast, multiple children will be created by different miners and become stale. There are "uncle blocks" (or orphaned/stale blocks).
• note: uncle blocks give rewards to the unlucky miners

All these factors combined gives the Ethereum community a sense of how well the network is handling the load we’re putting on it. If the uncle rate is low and congestion is high, it might be time to consider increasing the gas limit. If the uncle rate is skyrocketing and nodes are falling off the network, the gas limit may be too high, affecting the security of the network.

Ethgasstation.info