1. 👤 Accounts

Two Account Types

• Externally-owned accounts (EOA): Controlled by private keys, can initiate transactions

• Contract accounts: Controlled by smart contract code, respond to transactions

🏗️ Account Structure (4 fields)

• nonce: Transaction counter (prevents replay attacks).

• balance: Amount of wei (ETH) owned.

• codeHash: Hash of the account’s code (empty for EOAs).

• storageRoot: Hash of storage contents (Merkle Patricia trie).

🔐 Key Security Points

• Private keys are 64 hex characters

• Public address = last 20 bytes of Keccak-256 hash of public key + “0x” prefix

• Account addresses are 42 characters (20 bytes + 0x prefix)

• Private keys must be kept secure — they control funds

🔑 Validator Keys

• BLS keys for proof-of-stake consensus

• Used for validator identification and signature aggregation

• Separate from regular account keys

2. 📝 Transactions

Transactions are cryptographically signed instructions from accounts. An Ethereum transaction refers to an action initiated by an externally-owned account which changes the state of the EVM(Ethereum Virtual Machine)

📦 Transaction Components

• from: Sender address (EOA only).

• to: Recipient address.

• signature: Proof of sender authorization.

• nonce: Sequential counter which indicates the transaction number

• value: ETH amount (in wei) to be transferred.

• input data: Optional arbitrary data

• gasLimit: The maximum amount of gas units that the transaction can consume. EVM specifies the units of gas required by each computational step.

• maxPriorityFeePerGas: The maximum price of the consumed gas to be included as a tip to the validator.

• maxFeePerGas: The maximum fee per unit of gas willing to be paid for the transaction. This is baseFeePerGas +maxPriorityFeePerGas

🏷️ Types of Transactions

• Regular transactions: A transaction from one account to another

• Contract deployment transactions: A transaction without a ‘to’ address, where the data field is used for the contract code

• Execution of a contract: A transaction that interacts with a deployed smart contract. In this case, ‘to’ address is the smart contract address.

🤖 Smart Contract Interactions

• data field: First 4 bytes = function selector, rest = encoded arguments

• view/pure functions: Don’t alter state, no gas is consumed when called via eth_call

• Internal contract calls do consume gas.

🏷️ Classification of transactions based on the TransactionType value

Transactions are interpreted as TransactionType || TransactionPayload

TransactionType is a number between 0 and 0x7f, for a total of 128 possible transaction types, while TransactionPayload is an arbitrary byte array defined by the transaction type. The transactions are then classified as

• Type 0 (Legacy): Original format, no EIP-1559 features. The TransactionType value is 0x0

• Type 1: Includes access lists (EIP-2930). The TransactionType value is 0x1.

• Type 2: EIP-1559 transactions with dynamic fees (current standard). The TransactionType value is 0x2.

🔄 Transaction Lifecycle

1. Transaction hash generated

2. Broadcasted to the network and added to the mempool.

3. Validator selects and includes it in the block.

4. Block becomes “justified” then “finalized”

3. 🧱 Blocks

Blocks are batches of transactions with a hash of the previous block in the chain. The hash links blocks together in a chain because hashes are cryptographically derived from the block data. Blocks are important because they ensure that all participants on the Ethereum network maintain a synchronized state and agree on the precise history of transactions. The block-assembly process is currently specified by Ethereum’s “proof-of-stake” protocol.

🔐 Proof-of-Stake Process

• Validators stake 32 ETH as collateral.

• Random selection for the block proposer in each slot.

• Other validators re-execute and verify transactions.

• Fork-choice algorithm resolves conflicts.

🏗️ Block Structure

• Slot: 12-second time unit

• Proposer_index: ID of the randomly selected validator proposing the block

• Parent root: Hash of previous block

• State root: Global state hash

• body: an object containing several fields

• Execution payload: Contains transactions

🔩 Block Components

• Header: Summary information

• Body: Detailed block data, including the transaction, which contains

a) randao_reveal:a value used to select the next block proposer

b) eth1_data:information about the deposit contract

c) graffiti:arbitrary data used to tag blocks

d) proposer_slashings:list of validators to be slashed

e)attester_slashings:List of attesters to be slashed

f) attestations:list of attestations in favor of the current block.

g) deposits:list of new deposits to the deposit contract.

h)voluntary_exits:list of validators exiting the network.

i) sync_aggregate:subset of validators used to serve light clients.

j) execution_payload:Transactions passed from the execution client

• Attestations: Validator votes on block validity contain

a) aggregation_bits:a list of which validators participated in this attestation

b) data:a container with multiple subfields, which are slot(the slot the attestation relates to), index(indices for attesting validators), beacon_block_root(the root hash of the Beacon block containing this object), source(the last justified checkpoint), target(the latest epoch boundary block).

c) signatureaggregate signature of all attesting validators

The execution_payload_header contains the following fields

a) parent_hash:hash of the parent block

b)fee_recipientaccount address for paying transaction fees to

c) state_rootroot hash for the global state after applying changes in this block.

d) receipts_root:hash of the transaction receipts trie

e) logs_bloom:data structure containing event logs

f) prev_randao:value used in random validator selection

g) block_number:the number of the current block

h) gas_limit:maximum gas allowed in this block

I) gas_used:the actual amount of gas used in this block

j) timestamp:the block time

k) extra_data:arbitrary additional data as raw bytes

l)base_fee_per_gas:the base fee value

m) block_hash:Hash of execution block

n) transactions_root:root hash of the transactions in the payload

o) withdrawal_root:root hash of the withdrawals in the payload

The execution payload contains the following
a)parent_hash:hash of the parent block

b)fee_recipient:account address for paying transaction fees to

c)state_root:root hash for the global state after applying changes in this block

d)receipts_root:hash of the transaction receipts trie

e) logs_bloom:data structure containing event logs

f) prev_randao:value used in random validator selection

g) block_number:the number of the current block

h) gas_limit:maximum gas allowed in this block

I) gas_used:the actual amount of gas used in this block

j) timestamp:the block time.

k)extra_data:arbitrary additional data as raw bytes

l)base_fee_per_gas:the base fee value

m)block_hash:Hash of execution block

n)transactions:list of transactions to be executed

o)withdrawals:list of withdrawal objects

The withdrawals list contain withdrawal objects as shown:

⏱️ Block Timing & Size

• Target time: 12 seconds per block

• Target size: 15 million gas

• Maximum size: 30 million gas (2x target) and minimum size of 15 million.

• Gas limit is adjustable by ±1/1024 per block

4. 🖥️ Ethereum Virtual Machine (EVM)

⚡ EVM Fundamentals

• Purpose: Decentralized virtual environment for smart contract execution

• Architecture: Stack machine with 1024 item depth

• Word size: 256-bit words (optimized for cryptography)

• Deterministic: Same input always produces the same output

🔄 State Transition Function

Y(S, T) = S'

Given old state (S) and transactions (T), produces new state (S’)

🏗️ EVM Components

• Stack: 1024 items, 256-bit words

• Memory: Transient, doesn’t persist between transactions

• Storage: Persistent Merkle Patricia trie per contract

• Opcodes: Instructions like ADD, SUB, ADDRESS, BALANCE

📊 From Ledger to State Machine

• Bitcoin = distributed ledger

• Ethereum = distributed state machine

• Enables smart contracts and arbitrary computation

• State includes accounts, balances, and machine state

🛠️ EVM Implementations

Multiple implementations in different languages:

• Py-EVM (Python)

• evmone (C++)

• ethereumjs-vm (JavaScript)

• revm (Rust)

5. ⛽ Gas and Fees

🔧 Gas Fundamentals

• Gas: Unit measuring computational effort

• Gas fee: Gas used × cost per gas unit

• Payment: Must be in ETH (quoted in gwei)

• Gwei: 1 gwei = 10^-9 ETH = 1 billion wei

💰 Fee Structure (EIP-1559)

• Base fee: Protocol-set minimum (burned)

• Priority fee: Tip to validator

• Max fee: User-set maximum limit

• Formula: Total fee = gas used × (base fee + priority fee)

🔥 Base Fee Mechanics

• Calculated from previous block size vs target (15M gas)

• Increases max 12.5% per block if the target is exceeded.

• Burned (removed from circulation).

• Makes fees more predictable

🏁 Gas Limits

• Standard ETH transfer: 21,000 gas

• Block limit: 30 million gas maximum

• User sets limit: Too low = transaction fails, too high = waste ETH

• Unused gas: Refunded to the user.

🛡️ Why Gas Exists

• Network security: Prevents spam attacks

• Resource allocation: Ensures fair computational usage

• Infinite loop prevention: Limits computational steps

• Economic incentives: Validators prioritize higher-paying transactions

📈 Gas Price Factors

• Network demand: High demand = higher prices

• Transaction complexity: Smart contracts use more gas

• Block space: Limited, creates competition

• Time sensitivity: Faster inclusion requires higher fees

🔗 Key Relationships

🔄 Account → Transaction → Block → EVM → Gas

1. Accounts initiate transactions

2. Transactions are batched into blocks

3. Blocks are processed by the EVM

4. EVM execution consumes gas

5. Gas fees incentivize validators

🔐 Security Model

• Cryptographic keys secure accounts

• Digital signatures authenticate transactions

• Proof-of-stake secures blocks

• Gas limits prevent resource abuse

• Base fee burning controls inflation

📈 Scalability Considerations

• Block size limits prevent centralization

• Gas limits balance throughput vs accessibility

• 12-second blocks provide consistent timing

• Layer 2 solutions address scalability

• Validator requirements (32 ETH) ensure security