Blockchain Notes

Ethereum

May 27, 20255 min read

Proof of Stake

  • In 2022, Ethereum successfully switched from a proof-of-work to an alternative consensus model called proof-of-stake
  • TODO
  • Since changes to the chain specification require a coordinted fork, the chain with the new proof-of-stake consensus model was called the beacon-chain
  • The Merge was the event when the beacon chain finally merged with the then main mainnet chain
  • Proof-of-stake uses ether to validate and propose blocks on the mainnet
  • Ethereum’s Proof of Stake consensus explained

Accounts

  • An Ethereum account is an entity with an ether (ETH) balance that can send transactions on Ethereum
  • There are 2 types of Ethereum accounts:

EOA

  • Externally-owned accounts are controlled by anyone with their ECDSA (Elliptic Curve Digital Signature Algorithm) private key

Contract Accounts

  • An Ethereum account, aside from identifying a participating node in the Ethereum network, can also be a contract account, taking the place of a single invokable contract on the Ethereum network
  • Transactions made to a contract-account expect the name of the called function and its input parameters in the data field of the transaction so that the contract may be invoked

Smart Contracts

EVM

Evm

State

  • The state of the Ethereum blockchain is its composition, consisting of all ether transactions (from an EOA to another EOA or a smart-contract) and all contract invocations, welded into a single series of blocks through consensus among the nodes in the Ethereum network
  • The state of the ethereum blockchain is encoded into a Merkle-Patricia Trie, which itself is a modified version of the Merkle Tree
  • There is a roadmap to move to a Verkle Tree structure so that Ethereum can support stateless clients (clients that can participate in the Ethereum networks without needing to store any history of the ethereum state)

Layer 2

The main ethereum blockchain (called the mainnet) can only handle ~15 transactions per second, in order to increase scalability, layer 2 solutions are required, where “layer 2” or L2 describes any solution implemented on a separate chain than the mainnet.

  • Generally speaking, transactions are submitted to these layer 2 nodes instead of being submitted directly to layer 1
  • Layer 2 Scaling
  • More on layer 2

Rollups

  • Rollups are the most obvious L2 scaling solution to offload some traffic from L1 by bundling a certain amount of transactions off-chain (not on the mainnet), and finally uploading them as a single L1 transaction instead and thus reducing network traffic as well as gas fees
  • Rollups have been criticized to decrease the decentralization factor since they are often hosted by a centralized server or a clusters of servers, though they might also be hosted by individual nodes much like L1
  • Aligned Layer: Super Scaling Ethereum with Optimistic ZK Proofs
  • Addressing common rollup misconceptions

Optimistic Rollups

  • Optimistic rollups, when sending the bundled transactions, assume that all the transactions are valid and accurate unless disputed via fraud proofs
  • Fraud Proof: A full node, upon seeing an invalid state transition being gossiped around the network, could quickly generate a small piece of data demonstrating that a proposed state transition could not possibly arise from a given set of transactions and broadcast that data to peers
  • Popular Optimistic Rollups include Arbitrum, Base & Optimism

Zero-Knowledge Rollups

  • Tying back into the concept of Zero Knowledge Proofs, these are rollups that use ZKPs to attach a proof of the consensus to the rollups which the target L1 branch can verify
  • Rollups consist of Prover nodes that generate proofs about the input transactions and the resultant change in the state, whereby a smart-contract on the beacon chain can act as a verifier to verify the proof and add the sum transaction upon successful verification
  • Ethereum Scaling: ZK Roll-Ups
  • Popular ZK Rollups include Scroll

EIPs

EIPs (Ethereum Improvement Proposals) are documents proposing improvements for the Ethereum specification and its sub-specifications. Since Ethereum is a decentralized network, these proposals are the only source of development on the Ethereum which is a specification. Developers of ethereum implementations like Geth and Erigon follow EIPs closely so that any proposals agreed upon by the community may be implemented. EIPs, once closed, are given a selected duration for all clients to implement it, usually decided by a future block-number.

Notes on various EIPs:

  • ERC-4337: Account Abstraction
  • EIP-4844: Shard Blob Transactions (Proto-danksharding)
  • EIP-225: Clique proof-of-authority consensus protocol

Bridges

Clients

Light Client

Full Client

TODO

Archive Client

TODO

Client Specifications

Execution Client

Consensus Client

Implementations

Alloy

revm

  • Rust implementation of the EVM specification
  • Docs

Helios

Helios

Graph View

Backlinks