Lack of Turing-Completeness

○ Bitcoin Script is not Turing-complete, meaning it lacks the ability to perform

arbitrary computation like general-purpose programming languages (e.g., Python,
Solidity).

No Loops Allowed

○ This prevents denial-of-service (DoS) attacks where a transaction could get stuck
in an infinite computation, clogging the network.

Value Blindness

○ Bitcoin scripts operate at a transaction level but do not have direct access to input
or output values.
○ Imagine you want to create a script that allows a transaction to be valid only if the
output amount is exactly 1 BTC. In Bitcoin Script, this is not possible because the
script cannot check or enforce the transaction amount.
Lack of State

○ Bitcoin transactions do not maintain persistent state between transactions.

Blockchain Blindness

Bitcoin Script cannot check previous transaction details beyond the UTXOs being spent.

Example: You cannot write a script that says, “Only allow spending if this address has
received BTC 10 times before.”

You cannot create a Bitcoin contract that releases BTC if the price of gold crosses
$2,000.

No Source of Randomness (No Gambling)

○ Bitcoin Script lacks built-in randomness or entropy, making it unsuitable for

applications requiring unpredictability, such as gambling or lottery systems.
○ In contrast, Ethereum can generate pseudo-random numbers using techniques like
querying oracle, VRF
○ Unpredictable, Not Random:
i. The outcome of PoW is unpredictable because it depends on
the computational power of miners and the speed at which
they can iterate through nonces.
ii. However, the process itself is governed by deterministic rules,
so it’s not truly random.

○ No Source of Randomness in Protocol:

i. Bitcoin’s protocol does not rely on any external or internal
source of randomness. The unpredictability arises from the
difficulty of reversing cryptographic hashes, not from
randomness.
Ethereum
Ethereum is a deterministic but practically bounded state machine, consisting of a
globally accessible singleton state and a virtual machine that applies changes to that
state.
Ethereum as a State Machine:

Ethereum is a global state machine:

● States: The global state of the Ethereum blockchain, which includes account
balances, smart contract code, and storage.
● Transitions: Changes to the state caused by transactions (e.g., sending ETH, calling
a smart contract).
● Inputs: Transactions submitted by users.
● Rules: The Ethereum Virtual Machine (EVM) executes transactions and smart
contracts according to predefined rules, ensuring deterministic state transitions.
● Unbounded refers to the fact that Ethereum's state is not limited in size. The
state can grow as more accounts, contracts, and data are added to the
blockchain.
● However, it is practically bounded because the growth of the state is
constrained by real-world factors like storage costs, gas fees, and block size
limits. These factors prevent the state from growing infinitely in practice

● Ethereum maintains a singleton state, meaning there is only one global

state shared by all participants in the network. This state includes account
balances, contract code, and contract storage.
● The state is globally accessible, meaning anyone can read or interact
with it by sending transactions or querying data. This openness is a key
feature of Ethereum's design.
Virtual Machine (EVM)
● The Ethereum Virtual Machine (EVM) is the runtime environment for executing
smart contracts. It processes transactions and applies changes to the global state.
● The EVM ensures that all nodes in the network execute the same computations and
reach the same state, maintaining consistency across the decentralized network.
A Runtime Virtual Machine (VM) is a software environment that allows you to execute code in
a platform-independent manner. It abstracts the underlying hardware and operating system,
providing a consistent execution environment for programs. Runtime VMs are commonly used
for languages like Java, Python, and C# to ensure that code can run on any device or operating
system without modification.

Key Features of a Runtime Virtual Machine

Platform Independence:

○ Code is compiled into an intermediate format (e.g., bytecode) that the VM can
execute, making it portable across different platforms.

Memory Management:

○ The VM handles memory allocation and garbage collection, reducing the risk of
memory leaks and other common errors.
Standardized Environment

○ The EVM provides a standardized runtime environment with its own stack,
memory, and storage systems.
○ This ensures that smart contracts behave the same way, regardless of the
underlying platform.

Deterministic Execution:

○ The EVM is designed to produce the same output for the same input and initial
state, no matter where it is executed.
○ This determinism is crucial for maintaining consensus across the decentralized
network.
Summarizing!

Ethereum is an open source, globally decentralized computing infrastructure

that executes programs called smart contracts.

It uses a blockchain to synchronize and store the system’s state changes, along
with a cryptocurrency called ether to meter and constrain execution resource costs.

○ Account-based blockchain
○ Transactions == state transaction function

The Ethereum platform enables developers to build powerful decentralized applications

with built-in economic functions.

While providing high availability, auditability, transparency, and neutrality, it also reduces
or eliminates censorship and reduces certain counterparty risks.
 Layers in Ethereum

● First layer – the physical network. This is a distributed collection of

computers, called nodes, running Ethereum software. Some of the nodes mine
the cryptocurrency and
some broadcast the blockchain and transactions around the World.

● Second layer – the Ethereum Virtual Machine. This is a decentralized

computing environment allows developers to upload smart contracts to the
blockchain and allows external accounts (users) to interact with the smart
contracts. External accounts are controlled by a private key (password).
 ● Third layer – the smart contract. Smart contracts are programs that receive
instructions and can send messages or instructions to other
accounts or other smart contracts. A smart contract might do
something like change a variable or send a cryptocurrency to
another address.

● Fourth layer – the decentralized application (dapp). Dapps are collections

of smart contracts that perform complicated tasks, such as exchanging one
token for another or lending a token using another token as collateral. They are
accessed through websites that allow users to connect their “Web 3” wallets to
the Ethereum network.
Ethereum started as a way to make a general-purpose blockchain that could be programmed for
a variety of uses. But very quickly, Ethereum’s vision expanded to become a platform for
programming DApps (Decentralized Applications).

DApps represent a broader perspective than smart contracts. A DApp is, at the very least,
a smart contract and a web user interface. More broadly, a DApp is a web application that
is built on top of open, decentralized, peer-to-peer infrastructure services.

A DApp is composed of at least:

● Smart contracts on a blockchain

● A web frontend user interface

In addition, many DApps include other decentralized components, such as:

● A decentralized (P2P) storage protocol and platform

● A decentralized (P2P) messaging protocol and platform

What is the Account Model?
The Account Model, popularized by Ethereum in 2015, serves as a simpler
alternative to the UTXO model. Instead of tracking unspent outputs, it maintains a
single balance for each account. Transactions in this model directly update
balances by subtracting from the sender's account and adding to the recipient's.

How the Account Model works

For example, if Alice wants to send Bob 3 tokens, her account balance is reduced
by 3, while Bob's balance increases by the same amount. This direct balance
management simplifies the handling and tracking of funds as users don’t have to
juggle multiple outputs. Because of this simplicity, the Account Model is better
suited for smart contracts and programmability as it allows for more straightforward
state management.
Comparing UTXO and Account Models
Both the UTXO and Account models facilitate transaction tracking within blockchain
systems, but they operate fundamentally differently. The UTXO model’s discrete
units make tracing fund flows challenging, but not impossible. In contrast, the
Account Model simplifies balance management by maintaining a single balance per
account, but is inherently more open due to identifiable accounts.
The benefits of UTXOs are:

1. Higher degree of privacy: if a user uses a new address for each transaction
that they receive then it will often be difficult to link accounts to each other. This
applies greatly to currency, but less to arbitrary dapps, as arbitrary dapps often
necessarily involve keeping track of complex bundled state of users and there
may not exist such an easy user state partitioning scheme as in currency.
2. Potential scalability paradigms: UTXOs are more theoretically compatible
with certain kinds of scalability paradigms, as we can rely on only the owner of
some coins maintaining a Merkle proof of ownership, and even if everyone
including the owner decides to forget that data then only the owner is harmed.
In an account paradigm, everyone losing the portion of a Merkle tree
corresponding to an account would make it impossible to process messages
that affect that account at all in any way, including sending to it. However,
non-UTXO-dependent scalability paradigms do exist.
The benefits of accounts are:

1. Large space savings: for example, if an account has 5 UTXO, then switching from a UTXO model to an
account model would reduce the space requirements from (20 + 32 + 8) * 5 = 300 bytes (20 for the address,
32 for the txid and 8 for the value) to 20 + 8 + 2 = 30 bytes (20 for the address, 8 for the value, 2 for a
nonce(see below)). In reality savings are not nearly this massive because accounts need to be stored in a
Patricia tree (see below) but they are nevertheless large. Additionally, transactions can be smaller (eg. 100
bytes in Ethereum vs. 200-250 bytes in Bitcoin) because every transaction need only make one reference
and one signature and produces one output.

2. Simplicity: easier to code and understand, especially once more complex scripts become involved.
Although it is possible to shoehorn arbitrary decentralized applications into a UTXO paradigm, essentially
by giving scripts the ability to restrict what kinds of UTXO a given UTXO can be spent to, and requiring
spends to include Merkle tree proofs of change-of-application-state-root that scripts evaluate, such a
paradigm is much more complicated and ugly than just using accounts.

3. Constant light client reference: light clients can at any point access all data related to an account by
scanning down the state tree in a specific direction. In a UTXO paradigm, the references change with each
transaction, a particularly burdensome problem for long-running dapps that try to use the above mentioned
state-root-in-UTXO propagation mechanism.
 From the developers

“We have decided that, particularly because we are dealing with dapps containing arbitrary state
and code, the benefits of accounts massively outweigh the alternatives. Additionally, in the
spirit of the We Have No Features principle, we note that if people really do care about privacy
then mixers and coinjoin can be built via signed-data-packet protocols inside of contracts.”

One weakness of the account paradigm is that in order to prevent replay attacks, every transaction
must have a "nonce", such that the account keeps track of the nonces used and only accepts a
transaction if its nonce is 1 after the last nonce used. This means that even no-longer-used accounts
can never be pruned from the account state.
“Imagine buying an asset for 10 ETH - you pay the seller but want assurance they won't resend the
same transaction to drain your account. This is where nonces come in.

A nonce is a number that can only be used once in cryptographic communication. In Ethereum,
nonces are per-account transaction sequence numbers.

When you send that first 10 ETH, your account's nonce increments to 1. The transaction also
includes this nonce value. For any subsequent transactions, the nonce must increment (2, 3, etc)
properly, or nodes will reject it.

This prevents the seller from merely re-broadcasting the original nonce 1 transaction. The network
will see that the nonce is no longer valid for your account and drop the fraudulent transaction.”

As such, nonces uniquely sequence transactions from each account, ensuring external ownership
and thwarting replay attacks. By systematically incorporating nonces, Ethereum guarantees
transaction integrity across the decentralized network.

“An account's balance can be spent in multiple transactions, but each transaction must have
a unique nonce to ensure it is processed correctly.”
● Alice sends 10 ETH to Bob with nonce 0.
● The network processes the transaction and updates Alice’s nonce to 1.
● If Alice tries to send another 10 ETH to Bob with the same nonce 0, the network will

reject it because nonce 0 has already been used.

This ensures that the same transaction cannot be processed twice,

preventing double-spending.
 Ethereum Wallet

We will use the term "wallet" to mean a software application that helps you manage
your Ethereum account.
In short, an Ethereum wallet is your gateway to the Ethereum system.
It holds your keys and can create and broadcast transactions on your behalf.
 Ethereum Wallet

MetaMask - MetaMask is a browser extension wallet that runs in your browser

(Chrome, Firefox, Opera, or Brave Browser). It is easy to use and convenient for
testing, as it is able to connect to a variety of Ethereum nodes and test blockchains.
MetaMask is a web-based wallet that also includes mobile apps for both iOS and
Android.

Jaxx - Jaxx is a multiplatform and multicurrency wallet that runs on a variety of

operating systems, including Android, iOS, Windows, macOS, and Linux. It is often a
good choice for new users as it is designed for simplicity and ease of use. Jaxx is
either a mobile or a desktop wallet, depending on where you install it.
 Exercise
Refer https://github.com/ethereumbook/ethereumbook/blob/develop/02intro.asciidoc#block_explorer_account_history
1. Install Metamask wallet extension https://metamask.io/download
2. Once wallet installed, create accounts and note the address
3. The testnet mentioned in the github link does not exist anymore. Tryout sepolia testnet. Once account is created
fund your account using sepolia faucet or linea sepolia faucet
https://cloud.google.com/application/web3/faucet/ethereum/sepolia (limited to one trial)
4. Send coins from one Account 1 to Account 2. Note the fee needed and check the transaction in sepolia explorer as
well https://sepolia.etherscan.io/
For the transaction check the nonce and position of transaction in the block.
5. Do another transaction from Account 1 to Account 2,
Note the fee needed and check the transaction in sepolia explorer as well https://sepolia.etherscan.io/
For the transaction check the nonce and position of transaction in the block.
6. Do a transaction from Account 2 to Account 1 and now check the nonce.
7. Instead of creating Account 2, you may ask your friend to share their account address and send coins to their
account as well.
Ethereum Wallet

https://github.com/ethereumbook/ethereumbook/bl
ob/develop/02intro.asciidoc#metamask_password
Which networks does
MetaMask support? https://github.com/ethereumbook/ethereumbook/bl
MetaMask supports Ethereum (including all
ob/develop/02intro.asciidoc#metamask_password
ERC-20 tokens) and both layer one and two
EVM-compatible blockchains, including:

● BNB Smart Chain (formerly Binance

Smart Chain/BSC)
● Polygon
● Avalanche
● Fantom
● Harmony
● Aurora
● Optimism (Optimistic Ethereum)
● Arbitrum
● Palm
● Celo
Goerli and Rinkeby testnets were deprecated to ensure a viable, stable, and
safe path forward for the Ethereum ecosystem, with the transition to Sepolia
offering improved efficiency, scalability, and lower transaction fees.
Here's a more detailed explanation:

● Why Deprecation?

The Ethereum Foundation decided to deprecate Goerli and Rinkeby

(and previously Kovan and Ropsten) to ensure the Ethereum
ecosystem has a stable and safe path forward.

The transition to Sepolia is intended to improve efficiency, scalability, and

lower transaction fees.

Goerli and Rinkeby no longer receive updates or maintenance, making them

incompatible with the latest Ethereum Virtual Machine (EVM) change. Sepolia
is a proof-of-authority testnet that offers higher efficiency, improved scalability,
and lower transaction fees compared to Goerli and Rinkeby.
Intro to Secret Recovery Phrases
One of the key (you'll see what I did there) technologies underlying MetaMask, and most
user account-related tools in the crypto space is the seed phrase, or as it's referred to in
MetaMask, your Secret Recovery Phrase.

Seed phrases as we know them today were codified for usage in Bitcoin, according to a standard
referred to as Bitcoin Improvement Proposal 39, or BIP-39. In simple terms, a series of words are
selected with a high level of randomness from a specific list of words. In MetaMask and many
other Ethereum-compatible technologies, there are 12 words in a seed phrase
Creating an HD Wallet from the Seed

HD wallets are created from a single root seed, which is a 128-, 256-, or 512-bit
random number. Most commonly, this seed is generated from a mnemonic as
detailed in the previous section.

Every key in the HD wallet is deterministically derived from this root seed, which
makes it possible to recreate the entire HD wallet from that seed in any compatible
HD wallet. This makes it easy to export, back up, restore, and import HD wallets
containing thousands or even millions of keys by transferring just the mnemonic
from which the root seed is derived.
 Ethereum Address

Ethereum addresses are unique identifiers that are derived from public keys or contracts using the Keccak-256 one-way hash
function.

If Public key K:

K = 6e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444683bae07b83b5c38e5e...

We use SHA-256 to calculate the hash of this public key:

SHA-256(K) = 2a5bc342ed616b5ba5732269001d3f1ef827552ae1114027bd3ecf1f086ba0f9

Then we keep only the last 20 bytes (least significant bytes), which is our Ethereum address:

001d3f1ef827552ae1114027bd3ecf1f086ba0f9

It has hexadecimal encoding: 0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9

● StorageRoot is a critical field in an account's state that represents the root hash of a Merkle
Patricia Trie (MPT) containing all the contract's storage data.
● For Contract Accounts:
○ Contracts can store persistent data in a key-value storage (like a database).
○ The StorageRoot is the root hash of a Merkle Patricia Trie that encodes all the contract’s
storage slots (slot → value pairs).
○ This allows Ethereum to efficiently verify the integrity of a contract’s storage without storing
the entire data on-chain explicitly.
● For Externally Owned Accounts (EOAs):
○ EOAs have no storage, so their StorageRoot is always empty:
 ● Storage Structure:
○ A contract’s storage is a key-value store where each 256-bit key maps to
a 256-bit value (e.g., slot 0 → value 42).
○ Example: In Solidity, a state variable like uint256 public x = 42;
occupies a storage slot (e.g., slot 0).
● Merkle Patricia Trie (MPT):
○ The storage data is organized in a trie (tree-like structure), where each
leaf node contains a key-value pair.
○ The root hash (StorageRoot) is a cryptographic fingerprint of the entire
storage state.
○ Changing any storage value recalculates the trie and updates the
StorageRoot.

Let’s say a contract has:

● Slot 0: 42
● Slot 1: 100

Initially, its StorageRoot is Hash_A.

If we update Slot 1 from 100 to 200, the trie

is recalculated, and the StorageRoot
becomes Hash_B.
Why is StorageRoot Important?

● Data Integrity:
○ The StorageRoot ensures that contract storage cannot be tampered with. Any change to
storage modifies the root hash.
○ Ethereum nodes can verify storage values without downloading the entire state (using
Merkle proofs).
● Efficiency:
○ Instead of storing all storage data in the account, Ethereum only keeps the root hash,
saving space.
○ Full storage data is maintained by execution clients (e.g., Geth, Erigon).
● State Proofs:
○ Light clients can verify specific storage values by checking Merkle proofs against the
StorageRoot.
● Every Ethereum account (whether an Externally Owned Account (EOA) or a
Contract Account) has a CodeHash field in its state.
● For Contract Accounts, this is the Keccak-256 hash of the EVM (Ethereum
Virtual Machine) bytecode stored on the blockchain.
● For EOAs (user-controlled accounts), CodeHash is always keccak256("") (the
hash of an empty string), because EOAs have no code.
● When a contract is deployed, its runtime bytecode is stored on-chain, and its CodeHash is
computed and saved in the account state.
● When executing a transaction, Ethereum nodes can verify a contract’s integrity by:
○ Fetching the bytecode from the network.
○ Computing its Keccak-256 hash.
○ Comparing it with the stored CodeHash to ensure no tampering occurred.

Why is CodeHash Important?

● Security: Ensures that contract code hasn’t been altered (since changing the code would
change the hash).
● Efficiency: Allows lightweight verification without storing full bytecode in the state trie.
● Differentiation: Helps distinguish between EOAs (no code) and contracts (with code).
Two types of Ethereum Account

● Externally owned accounts: controlled by private keys. It can

create and send a message to another account by signing a transaction
Contains address and Ether balance.

● Contract accounts: controlled by a contract code. It gets activated when

receiving a message, the smart contract code executes, can read and write
from storage and send messages to other accounts
Contains address, associated contract code and persistent storage
Contracts have addresses, just like EOAs. Contracts can also send and receive ether, just like
EOAs. However, when a transaction destination is a contract address, it causes that contract to run
in the EVM, using the transaction, and the transaction’s data, as its input.

In addition to ether, transactions can contain data indicating which specific function in the
contract to run and what parameters to pass to that function. In this way, transactions can
call functions within contracts.

Note that because a contract account does not have a private key, it cannot initiate a
transaction.

Only EOAs can initiate transactions, but contracts can react to transactions by calling other
contracts, building complex execution paths. One typical use of this is an EOA sending a request
transaction to a multisignature smart contract wallet to send some ETH on to another address. A
typical DApp programming pattern is to have Contract A calling Contract B in order to
maintain a shared state across users of Contract A.
Example
The Solidity compiler comes as a standalone executable, as part of various frameworks, and bundled in
Integrated Development Environments (IDEs). To keep things simple, we will use one of the more popular IDEs,
called Remix.

Use your Chrome browser (with the MetaMask wallet you installed earlier) to navigate to the Remix IDE at
https://remix.ethereum.org.
Example
Example
Example
Example
 Fee Discussion (EIP - 1559)

Instead of a singular Gas Price, you now have to pay attention to three separate values:

● The Base Fee, which is determined by the network itself and is subsequently burned.
● A Max Priority Fee, which is optional, determined by the user, and is paid directly to miners.
● The Max Fee Per Gas, which is the absolute maximum you are willing to pay per unit of gas to get
your transaction included in a block. For brevity and clarity, we will refer to this as the Max Fee.

The Base Fee is determined by the Ethereum network rather than being set by end-users looking to transact or miners
seeking to validate transactions. The Base Fee targets 50% full blocks and is based upon the contents of the most recent
confirmed block. Depending on how full that new block is, the Base Fee is automatically increased or decreased.

For example:

● If the last block was exactly 50% full (15 M), the Base Fee will remain unchanged.
● If the last block was 100% full, the Base Fee will increase by the maximum 12.5% for the next block.
● If the last block was more than 50% full but less than 100% full, the Base Fee will increase by less than 12.5%.
● If the last block was 0% full – that is, empty – the Base Fee will decrease the maximum 12.5% for the next block.
● If the last block was more than 0% full but less than 50% full, the Base Fee will decrease by less than 12.5%.
 Fee Discussion
The Base Fee is algorithmically adjusted block-by-block based on how full the previous
block was. This mechanism, introduced in EIP-1559, aims to:

1. Keep block sizes stable (targeting ~15M GAS units per block, max hard cap 30 M
Gas unit, so 15 M means half full).
2. Automatically adjust fees to match network demand.
3. Prevent fee spikes during congestion (unlike the old auction system - First Price
Auction).
Fee Discussion

● Transactions in the same block share the same base fee, but across
different blocks, the base fee differs because:
○ Network activity fluctuates (e.g., NFT mints, DeFi liquidations cause
spikes).
○ The base fee adjusts every approx 15 seconds (avg. block time).
Problem with previous fee mechanism

Unpredictable and Volatile Fees

● Users had to guess the right gas price to get their transactions included.
● During congestion (e.g., ICO craze, DeFi boom), fees spiked exponentially due to bidding wars.
● Example: Fees could jump from 50 Gwei to 500 Gwei in minutes, forcing users to overpay.
● Wasted ETH: Users often overpaid (e.g., bidding 200 Gwei when 100 Gwei would have sufficed).
● Bribe Miners: Users had to bribe miners (via higher gas prices) for priority.
● Delayed Transactions: If you underbid, your TX could sit unconfirmed for hours.
● No Refunds: Even if blocks had extra space, excess fees went to miners (not users).
● No block size flexibility: Blocks had a fixed gas limit (e.g., 15M gas), leading to:
a. Backlogs: Thousands of stuck transactions during peak demand.
b. Gas Price Wars: Users constantly resubmitted TXs with higher fees.
● All fees went to miners, contributing to ETH inflation. No mechanism to remove ETH from circulation (unlike
EIP-1559’s base fee burn)
Problem with previous fee mechanism

1. The user set a fixed Gas Price of

0.004437715 Gwei (standard for legacy TXs).
2. The miner received 100% of the fee:
Fee=Gas Used×Gas
Price=28,325×0.004437715=0.00000009545751
6 ETHFee=Gas Used×Gas
Price=28,325×0.004437715=0.00000009545751
6 ETH
3. The Base Fee and Burnt values are
misleading:
○ A block explorer bug (e.g., reusing
EIP-1559 UI elements)
○
Fee Discussion

● Users set their own Max Fee per transaction (it's a user-defined parameter).
● Validators (block proposers) then select transactions based on these fees.
● The network auto-calculates the Base Fee using a deterministic formula.

Why Users Set Max Fee

● It’s a spending cap to prevent overpaying if the Base Fee spikes.

● Wallets (like MetaMask) often suggest Max Fee based on network conditions.

Validators (block proposers) prioritize transactions with:

1. Highest Priority Fee (their tip).

2. Sufficient Max Fee to cover the current Base Fee.
The Max Priority Fee — also often referred to as the miner tip — is an 'optional' additional fee that is paid directly
to miners in order to incentivize them to include your transaction in a block. While the Max Priority Fee is
technically optional, at the moment most network participants estimate that transactions generally require a minimum
2.0 GWEI tip to be candidates for inclusion. With that said, specific mining pools may choose to set alternative
minimums for inclusion.

For 'typical' transactions that are submitted under normal, not-congested network conditions, the Max Priority Fee
will need to be close to 2.0 GWEI. But, for transactions where order or inclusion in the next block is important, or when
the network is highly congested, a higher Max Priority Fee may be necessary to prioritize your transaction.

A somewhat subtle nuance to the Max Priority Fee is that it represents the maximum tip you are willing to pay to
a miner. However, if the Base Fee plus the Max Priority Fee exceeds the Max Fee, the Max Priority Fee
will be reduced in order to maintain the upper bound of the Max Fee. This means the actual tip may need to be
smaller than your Max Priority Fee and, under such circumstances, your transaction may become less attractive
to miners.
The Max Priority Fee — also often referred to as the miner tip — is an 'optional' additional fee that is paid directly
to miners in order to incentivize them to include your transaction in a block. While the Max Priority Fee is
technically optional, at the moment most network participants estimate that transactions generally require a minimum
2.0 GWEI tip to be candidates for inclusion. With that said, specific mining pools may choose to set alternative
minimums for inclusion.

For 'typical' transactions that are submitted under normal, not-congested network conditions, the Max Priority Fee
will need to be close to 2.0 GWEI. But, for transactions where order or inclusion in the next block is important, or when
the network is highly congested, a higher Max Priority Fee may be necessary to prioritize your transaction.

A somewhat subtle nuance to the Max Priority Fee is that it represents the maximum tip you are willing to pay to
a miner. However, if the Base Fee plus the Max Priority Fee exceeds the Max Fee, the Max Priority Fee
will be reduced in order to maintain the upper bound of the Max Fee. This means the actual tip may need to be
smaller than your Max Priority Fee and, under such circumstances, your transaction may become less attractive
to miners.
The base fee is burned (permanently removed from circulation) as part of Ethereum’s EIP-1559 upgrade for three key
reasons:

1. Economic Sustainability
○ Burning the base fee reduces ETH supply over time, making Ethereum more deflationary.
○ This counterbalances ETH issuance (new ETH created as block rewards) and can increase scarcity.
2. Fairer Fee Market
○ Before EIP-1559, miners/validators earned all transaction fees, leading to volatile gas wars.
○ Burning the base fee removes their incentive to artificially congest the network for higher profits.
3. Security & Predictability
○ Since the base fee is algorithmically set (not controlled by miners), burning it ensures no single party
benefits from manipulating fees

What Does "Burning" the Base Fee Mean?

● Burning means sending ETH to an unspendable address (0x000...dead),

permanently removing it from circulation.
● This is done automatically by the protocol—no one can access burned ETH.
Why Not Give the Base Fee to Miners/Validators?

● Prevents Manipulation: If miners earned the base fee, they could spam the network
to drive up fees.
● Better ETH Economics: Burning ETH reduces supply, potentially increasing its
value long-term.
● Fairer for Users: Users pay only what’s necessary (base fee + tip), not inflated
auction prices.

Real-World Impact of Burning

● Since EIP-1559 (August 2021), over 4 million ETH (~$10B+) has been burned.
● Burning offsets ~60-80% of new ETH issuance, making Ethereum net deflationary
during high activity.
● If burning > issuance: ETH supply shrinks (deflationary).
● If burning < issuance: ETH supply grows (inflationary).
Example
Example

0x665E796Bb3Aa5136ccdDA419C044979B251C87Ca
Example
Example
Internal Transaction also called as Message
 GAS

Gas is the fuel of Ethereum. Gas is not ether—it’s a separate virtual currency with its own exchange rate
against ether. Ethereum uses gas to control the amount of resources that a transaction can use, since it
will be processed on thousands of computers around the world.

Gas is separate from ether in order to protect the system from the volatility that might arise along with rapid
changes in the value of ether, and also as a way to manage the important and sensitive ratios between the
costs of the various resources that gas pays for (namely, computation, memory, and storage).

The gasPrice field in a transaction allows the transaction originator to set the price they are willing to pay in
exchange for gas. The price is measured in wei per gas unit.

“The higher the gasPrice, the faster

the transaction is likely to be
confirmed. Conversely,
lower-priority transactions can carry
a reduced price, resulting in slower
confirmation.”
The Transaction Nonce

The nonce is one of the most important and least understood components of a
transaction.

nonce: A scalar value equal to the number of transactions sent from this address or, in
the case of accounts with associated code, the number of contract-creations made by
this account.

Strictly speaking, the nonce is an attribute of the originating address; that is, it only has
meaning in the context of the sending address. However, the nonce is not stored
explicitly as part of an account’s state on the blockchain. Instead, it is calculated
dynamically, by counting the number of confirmed transactions that have
originated from an address.
Gaps in Nonces, Duplicate Nonces, and Confirmation

The Ethereum network processes transactions sequentially, based on the nonce.

That means that if you transmit a transaction with nonce 0 and then transmit a
transaction with nonce 2, the second transaction will not be included in any blocks. It
will be stored in the mempool, while the Ethereum network waits for the missing
nonce to appear. All nodes will assume that the missing nonce has simply been
delayed and that the transaction with nonce 2 was received out of sequence.

If you then transmit a transaction with the missing nonce 1, both transactions
(nonces 1 and 2) will be processed and included (if valid, of course). Once you fill
the gap, the network can mine the out-of-sequence transaction that it held in the
mempool.
Message contains
- Sender
- Recipient
- Amount of ether
- Start gas
An important consequence of the message mechanism is the "first class citizen" property
of Ethereum -
The idea that contracts have equivalent powers to external accounts, including the
ability to send message and create other contracts.

This allows contracts to simultaneously serve many different roles: for example, one
might have a member of a decentralized organization (a contract) be an escrow account
(another contract) between an paranoid individual employing quantum-proof Lamport
signatures (a third contract) and a co-signing entity which itself uses an account with five
keys for security (a fourth contract). The strength of the Ethereum platform is that the
decentralized organization and the escrow contract do not need to care
about what kind of account each party to the contract is
● The "strength" mentioned is that contracts don’t need to know or care
whether the other parties they interact with are EOAs or other contracts.
This abstraction simplifies design and enables composability (like Lego pieces
snapping together).
● For example, the DAO and escrow don’t need special logic to handle whether
a user is a person, a multisig, or another contract—they just send/receive
messages.
Transaction Propagation

The Ethereum network uses a "flood routing" protocol. Each Ethereum client acts as a node in a peer-to-peer (P2P)
network, which (ideally) forms a mesh network. No network node is special: they all act as equal peers.

Transaction propagation starts with the originating Ethereum node creating (or receiving from offline) a signed
transaction. The transaction is validated and then transmitted to all the other Ethereum nodes that are directly connected
to the originating node. On average, each Ethereum node maintains connections to at least 13 other nodes, called its
neighbors.

Each neighbor node validates the transaction as soon as they receive it. If they agree that it is valid, they store a copy
and propagate it to all their neighbors (except the one it came from). As a result, the transaction ripples outwards from
the originating node, flooding across the network, until all nodes in the network have a copy of the transaction. Nodes
can filter the messages they propagate, but the default is to propagate all valid transaction messages they receive.

Within just a few seconds, an Ethereum transaction propagates to all the Ethereum nodes around the globe. To be able
to track the origins of transactions, or interfere with propagation, an attacker would have to control a significant
percentage of all nodes.
Verifier’s dilemma
Expressive transaction scripts in emerging cryptocurrencies can require significant
computational work to verify.

These expressions create a new dilemma for miners —

whether the miners should verify the validity of scripted
transactions or accept them without verification.

Miners are incentivized to verify all scripted transactions for the “common good” of the cryptocurrency so to
speak.
However, verifying scripts consumes computation resources and therefore delays
honest miners in the race to mine the next block.

No direct gas loss, but indirect costs:

○ Hardware Costs: Running a full node requires high RAM/CPU (state storage is ~TB-scale).
○ Opportunity Cost: Time spent verifying = less time proposing blocks.

Solution: Some incentivization mechanism for verifiers.(?)

Recording on the Blockchain

Valid transactions will eventually be included in a block of transactions and, thus, recorded in the Ethereum blockchain. Once mined
into a block, transactions also modify the state of the Ethereum singleton, either by modifying the balance of an account (in the
case of a simple payment) or by invoking contracts that change their internal state. These changes are recorded alongside the
transaction, in the form of a transaction receipt, which may also include events.

Lifecycle of Transaction

User Creates TX → Signs TX → Broadcast to Network → Mempool → Miner Picks TX →

Executes in EVM → Block Mined → Network Validates → State Updated → Confirmed
● When a miner/validator includes a transaction in a block, the EVM computes:
○ Gas consumption
○ Smart contract logic (if applicable)
○ Temporary state changes (e.g., balance updates, storage changes)
● However, these changes are not yet final—they are pending validation by the network.

After execution, the consensus layer ensures correctness:

1. Block Proposer (Miner/Validator)

○ After executing all transactions, the proposer computes:
■ New State Root (Merkle root of all accounts/storage).
■ Receipts Root (logs, gas used, success/fail status).
○ These roots are included in the block header.
2. Network Validation
○ Other nodes re-execute the transactions independently.
○ They verify:
■ The computed state root matches the one in the block.
■ No invalid transactions (double spends, wrong nonces, etc.).
○ If >⅔ of validators agree, the block is finalized (in PoS).
3. Global State Update
○ Once the block is confirmed, all nodes update their local copy of the state trie.
○ The new state becomes canonical (official).
1. A transaction has:
a. Gas Limit: 50,000
b. Base Fee: 10 gwei
c. Priority Fee: 2 gwei

Calculate the total gas fee paid by the user

2. A smart contract call consumes:

a. 21,000 gas (base)
b. 2 SLOAD ops (800 gas each)
c. 1 SSTORE op (5,000 gas)

Current Base Fee = 15 gwei, Priority Fee = 1 gwei

Calculate the total transaction cost

3. Interpret the following in an Ethereum Transaction:

Transaction Fee: 0.00001691603342 ETH

Gas Price: 0.00437008 Gwei (0.00000000000437008 ETH)

Gas Limit & Usage by Txn: 3,934,653 | 3,870,875 (98.38%)

Gas Fees: Base: 0.00337008 Gwei |Max: 0.005174646 Gwei |Max Priority: 0.001 Gwei

Burnt & Txn Savings Fees:

Burnt: 0.00001304515842 ETH

Txn Savings: 0.00000311437441525 ETH (Base fee over-estimated)

 Component Calculation Amount (ETH)

Base Fee (Burnt) 3,870,875 × 0.00337008 Gwei 0.000013045

Priority Fee (Validator Tip) 3,870,875 × 0.001 Gwei 0.000003870

Total Paid Base + Priority 0.000016916

Savings Your Buffer = Max Fee - Max Priority Savings per gas:
0.005174646 - 0.001 = 0.004174646 Gwei 0.004174646 -
0.00337008 =
Base Fee was lower than buffer: 0.000804566 Gwei
0.00337008 (Base) < 0.004174646 (Buffer)
Total Savings:
3,870,875 gas ×
0.000804566 Gwei =
0.000003114 ETH
 1. Max Priority Fee is a cap on your tip, not the tip itself
2. Actual tip is the smaller of:
○ Your Max Priority Fee
○ What's left after base fee (Max Fee - Base Fee)
3. Savings only occur when:
○ You have room between Max Fee and Max Priority Fee (Max Fee - Max Priority > 0)
○ AND the base fee is lower than this buffer

Transaction savings happen when:

1. You set Max Fee > Max Priority Fee (creating a buffer for base fee changes)
2. The actual Base Fee ends up lower than your buffer (Max Fee - Max Priority Fee)
Interpret