From Bank Trust to Public Mempools: Understanding Ethereum, MEV, and Why Privacy Matters

Blockchains solved a hard problem: how do you move value on the internet without trusting a bank to keep the books? But in solving that problem, they created a new one. Every pending transaction sits in public view before it's confirmed, broadcasting your intent to the entire network — and to anyone looking to profit from it. This article traces that journey: from the 2008 financial crisis that motivated Bitcoin, through the mechanics of blocks, mining, and the mempool, into Ethereum's programmable "world computer," and finally into the privacy problem — Maximal Extractable Value (MEV) — that public transaction pools create.

Why Blockchains Exist: A Crisis of Trust

In 2008, the financial crisis exposed a fundamental fragility in the banking system. Institutions that seemed unbreakable failed or required bailouts, while ordinary people absorbed the losses. Banks performed three core functions: they held your money, kept the official ledger, and decided who could move value. When that system cracked, it raised an uncomfortable question — if the ledger lives inside institutions that can fail, who do you actually trust with the truth?

That question turned out to be an engineering problem, not just a grievance. In October 2008, Satoshi Nakamoto published Bitcoin: A Peer-to-Peer Electronic Cash System, proposing a ledger shared across the internet with no single company owning the official copy. The core promise was simple: send value online like email, person to person, with no bank required to approve the transfer, and with a history that everyone can verify and no one can quietly rewrite.

Bitcoin went live in 2009, not merely as a coin but as a running system of messages, computers, and a growing public history.

How a Blockchain Actually Works

A blockchain is a shared notebook of transactions, split into pages called blocks, linked together so that tampering becomes visible. Each transaction is a signed message — "I send value to you" — where the signature proves it came from the rightful owner of the funds. Each block references the one before it, forming a chain where altering history would break every link that follows.

This raises an obvious problem: who is allowed to write the next page? If anyone can write freely, bad actors invent free money and chaos ensues. If only one company can write, you've simply recreated a bank-shaped middleman. Bitcoin's answer was a race: make writing costly, but make checking easy. That race is Proof of Work (PoW).

Proof of Work and the Mining Race

Under PoW, specialized computers called miners compete to solve a computationally hard puzzle. The first miner to find a valid solution earns the right to publish the next block; every other node can verify that solution almost instantly. Cheating would require redoing an enormous amount of work, making dishonesty economically irrational.

The puzzle itself revolves around the nonce — "number used once." A candidate block contains its transactions, a link to the previous block, and a nonce field. Miners repeatedly change the nonce and hash the entire block header, searching for a hash that is "rare enough" (meaning it has enough leading zeros). This is hard to find but trivial to verify — the essential asymmetry that makes PoW work.

The Mempool: The Public Waiting Room

Before a miner picks up your transaction, it sits in the mempool (memory pool) — the set of pending transactions not yet included in a block. These transactions travel by gossip, propagating peer-to-peer across the network rather than living on a single server. There is no central mempool database; each node independently holds its own copy after gossip propagation, typically converging within seconds.

Because block space is scarce, not every pending transaction fits into the next block. This is where fees come in: you attach a tip to your transaction, and a higher tip makes it more attractive to whoever builds the next block. On Ethereum, this fee mechanism is called gas — you pay for both computation and space, and it doubles as an anti-spam mechanism that prevents infinite loops from freezing the shared computer.

The ledger updates through a four-stage process:

1. Pending — nodes independently hold copies of the mempool after gossip.
2. Sealed — a miner or validator publishes a block, and peers verify it against the consensus rules.
3. Apply — every full node re-executes the transactions locally and updates its own state.
4. Agree — because the protocol is deterministic, honest nodes following the same rules converge on identical balances.

Nodes don't share memory; they arrive at the same result because identical inputs, processed by identical rules, produce identical outputs.

This waiting room comes with a catch that becomes central later: pending usually means public. Observers can see where value is going, how much you're bidding in fees, and which application you're about to use. This visibility is the root of the privacy problem discussed later in this article.

The Missing Piece: From Digital Cash to a World Computer

Bitcoin excelled at moving money but was awkward as a general application platform. People wanted loans, exchanges, games, and organizations — programs that move value according to rules, not just simple transfers. Vitalik Buterin proposed keeping the shared-ledger idea but adding a shared place to run code, not just track balances. This became Ethereum: a network where applications and assets live in the same public state.

Ethereum's core unlock was programmability:

• Smart contracts — programs stored on-chain that the network runs identically for everyone.
• One settlement layer — tokens, exchanges, NFTs, and DAOs can all settle on the same shared computer, combining money, rules, and applications without handing control to a single company.

Accounts, Keys, and Getting Started

On Ethereum, identity works through cryptographic keys rather than usernames:

• Private key — a secret number that signs transactions. Lose it and your funds are gone; leak it and your funds are stolen. Never screenshot or share it.
• Public address (EOA) — derived from the private key, safe to share, and used to receive funds. EOA stands for Externally Owned Account — a human-controlled key, as opposed to contract code.
• Seed phrase — a 12- or 24-word master backup that controls every account a wallet derives. Anyone with your seed phrase has everything; treat it like a combined PIN, ATM card, and house key.

To get started practically: install MetaMask, create a wallet, and write the seed phrase down offline. Switch to the Sepolia test network, use a faucet to obtain test ETH, and send a small transaction to see it appear on Sepolia Etherscan. Never put real funds on a workshop or test seed phrase.

The Life of a Transaction

A typical Ethereum transaction follows this path:

1. You choose an action — sending ETH or calling a contract.
2. Your wallet builds and signs the transaction with your private key.
3. The signed transaction is sent to a node.
4. The node gossips it across the network, and it enters the mempool.
5. A block producer includes it in a block; every node then executes it.

The EVM (Ethereum Virtual Machine) runs on every full node — there is no single central CPU. When a block producer includes a transaction, every full node independently re-executes it through the EVM and arrives at the same result.

Gas and EIP-1559

Every EVM operation ("opcode") costs gas, and complex contracts cost more to run. You pay gas used × gas price, and failed calls can still burn gas — an unbounded loop can drain a wallet before it ever succeeds.

Since EIP-1559, "gas price" splits into two components:

Total cost is approximately gas used × (base fee + tip). MetaMask surfaces this as "max fee" and "priority fee." Critically, the tip is exactly the lever that searchers use to outbid ordinary users — a mechanism explored further below.

Proof of Stake: Ethereum's Consensus Upgrade

Ethereum later moved from Proof of Work to Proof of Stake (PoS) to address the energy consumption and throughput limits of mining:

1. Validators lock ("stake") ETH as collateral.
2. The protocol selects who proposes the next block, weighted by stake.
3. Dishonest behavior can result in a validator losing their stake — honesty is enforced economically rather than computationally.

Smart Contracts: Programs the Chain Is Forced to Execute

A smart contract is a public program with public memory. Once deployed, its code sits at an address, and the network keeps running it identically for everyone — it is not a legal document, but a program the chain is obligated to execute.

Contracts are built from four core pieces:

• State variables — data stored on-chain, persisting between calls and usually readable by anyone.
• Functions — some only read data; others change state and require a real transaction plus gas.
• msg.sender — the address that signed the current call, functioning as identity for that request.
• require / conditions — checks that must pass, or the call reverts and no state changes.

A Minimal Example

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract Counter {
    uint256 public count; // on-chain memory

    function inc() public {
        count += 1; // costs gas, anyone may call
    }

    function incBy(uint256 n) public {
        require(n > 0, "n must be > 0");
        count += n;
    }
}

Here, pragma pins the compiler version family; uint256 public count stores a number and automatically generates a free getter function; inc() changes state and must be mined as a transaction; and require guards against bad input, reverting the call if the condition fails.

When a user taps "Inc" in a wallet, the wallet encodes a call to the contract's address using the function selector for inc, the user signs it, the transaction enters the mempool, gets included in a block, and every node re-runs the EVM against that bytecode — updating the storage slot for count accordingly.

Common Solidity Types

Balances as a Mapping

mapping(address => uint256) public balances;

function transfer(address to, uint256 amt) public {
    require(balances[msg.sender] >= amt, "not enough");
    balances[msg.sender] -= amt;
    balances[to] += amt;
}

Sending tokens is, at its core, a subtract-and-add operation on public storage. Exchanges swap these mappings — and this exact pattern is what sandwich bots hunt for, as explained later.

Events

event Transfer(address indexed from, address indexed to, uint256 amt);

function transfer(address to, uint256 amt) public {
    balances[msg.sender] -= amt;
    balances[to] += amt;
    emit Transfer(msg.sender, to, amt);
}

The indexed keyword lets explorers and applications filter logs efficiently (up to three indexed fields per event). Applications typically subscribe to events rather than continuously polling contract storage.

Improving UX: Account Abstraction and Paymasters

Classic Ethereum UX requires users to hold ETH just to pay gas — a harsh barrier for newcomers. Account abstraction turns an account into a contract with more flexible rules, and a paymaster can sponsor gas on a user's behalf (the app pays, or the user pays in another token). This solves the onboarding problem of requiring users to acquire ETH before they can do anything.

Security Best Practices

Rather than writing custom access-control and safety logic from scratch, developers commonly rely on OpenZeppelin, a library of audited, battle-tested contract primitives such as Ownable, AccessControl, and ReentrancyGuard:

import "@openzeppelin/contracts/access/Ownable.sol";

Even when inheriting these patterns, it's important to actually read what you're importing.

Common Beginner Pitfalls

• There is no native decimal money type — everything uses integers and decimal conventions.
• Deployed code is difficult to patch, so contracts should be tested as if bugs will be permanent.
• Storage is public by default — assume anyone can read it.
• Failed transactions can still cost gas.
• Unbounded loops can make functions prohibitively expensive to call.

From Source Code to On-Chain Execution

Writing Solidity is only the first step. The Solidity compiler (solc) takes a human-readable .sol file and typechecks and compiles it into two distinct artifacts:

1. Bytecode — the executable body deployed on-chain.
2. ABI (Application Binary Interface) — a JSON interface describing how to call the contract.

Bytecode: The Body

Bytecode is a long hex string of EVM opcodes (PUSH, ADD, SSTORE, and so on). Deploying a contract means uploading this hex to every node at a contract address — the blockchain only stores and executes this bytecode, never the original .sol source. Without additional context, bytecode is opaque; you cannot tell set() from get() by staring at the hex.

ABI: The Language Interface

The ABI lists function names, parameter types, and return types, and defines how to pack and unpack call data. It maps human-readable function names to the 4-byte function selectors embedded in the bytecode. Applications never send set(42) as literal text — libraries use the ABI to encode it into the correct bytes before sending them to the contract address.

Example ABI for a simple storage contract:

[
  {
    "name": "get",
    "type": "function",
    "stateMutability": "view",
    "inputs": [],
    "outputs": [{ "type": "uint256" }]
  },
  {
    "name": "set",
    "type": "function",
    "stateMutability": "nonpayable",
    "inputs": [{ "name": "value", "type": "uint256" }],
    "outputs": []
  }
]

Here, get() is a read-only view function, while set(uint256) writes state and costs gas.

Talking to the Chain: RPC and Frontend Libraries

The blockchain is a peer-to-peer network, and a browser cannot join it directly. An RPC (Remote Procedure Call) URL points to a single node — your own, or a provider like Infura, Alchemy, or a local Anvil instance — that translates HTTP/JSON-RPC requests into blockchain operations. MetaMask does not run a full node in the browser; it talks to whatever RPC URL you configure.

Frontend libraries like ethers.js (or web3.js) tie the pieces together:

• Provider — a read-only RPC connection, used for balances, logs, and chain ID.
• Signer / Wallet — signs transactions (MetaMask injects a signer into the page).
• Contract — combines an address, ABI, and signer to map JavaScript method calls to on-chain functions.

const c = new Contract(addr, abi, signer);
await c.set(42);

Node Types

To summarize what each layer stores: the blockchain holds history, state holds balances and contract variables, and the mempool holds pending transactions temporarily.

The Privacy Problem: MEV and the Public Mempool

This is where the story circles back to the mempool's core weakness: pending transactions are public. Before a transaction confirms, observers can see the sender's address, the target contract (which application is being used), the calldata (such as swap amount and function called), and the gas tip (how urgently the sender wants inclusion).

Privacy, in this context, is not only about hiding your identity — it's about hiding your intent before the chain finalizes it. This exposure enables Maximal Extractable Value (MEV): profit extracted by choosing which transactions enter a block and in what order.

Who Extracts MEV

• Searchers scan mempools (and private order flow) for profitable reordering opportunities.
• Builders assemble full blocks or bundles optimized for fees and MEV.
• Proposers / validators propose the block that earns them rewards, often through builder markets.

The underlying principle: ordering is valuable because transaction intent is visible before it executes.

Anatomy of a Sandwich Attack

A sandwich attack exploits a victim's pending swap on an automated market maker (AMM). Consider a pool with 100 WETH and 1,000,000 MEME tokens, where a victim is about to swap 10 WETH for MEME:

1. Intent — The victim's pending transaction is visible in the mempool: swap 10 WETH for MEME, with a fair value of roughly 90,909 MEME and a minimum acceptable amount of 81,818 MEME (allowing 10% slippage).
2. Front-run — A searcher spends 5 WETH to buy 47,619 MEME first, pushing the price down to about 9,070 MEME per WETH.
3. Victim executes — The victim's swap still succeeds, but at the worse price, yielding only 82,815 MEME instead of the fair 90,909 — a loss of 8,093 MEME. The transaction technically succeeds, which is what makes this attack insidious rather than an outright hack.
4. Back-run — The searcher sells the MEME back, netting a profit of approximately 0.97 WETH (970,654,627,539,503,386 wei).

The victim is the filling; the bot is the bread on both sides.

Why Sandwich Attacks Work

Three ingredients combine to make this possible:

1. Public mempool — the bot can see the victim's pending swap, including amount, trading pair, and slippage tolerance.
2. AMM math — the bot's own trade moves the pool price according to the constant-product formula (x × y = k).
3. Slippage tolerance — the victim's acceptable price deviation defines the bot's exact profit budget.

Hands-On: Two Labs That Prove the Concept

Two companion labs demonstrate these mechanics concretely using Foundry and a local Anvil test node.

Prerequisites

• Git installed
• Foundry installed via: curl -L https://foundry.paradigm.xyz | bash then foundryup
• Verify with forge --version and anvil --version
• Two or three terminal windows

Lab 1: Mempool Fee-Race (mempool-mev)

This lab proves that pending transactions are public and that higher gas tips win block inclusion. It deploys a minimal Ping.sol counter contract, then sends two ping() calls from different accounts — one with a gas price of 1 gwei, the other at 50 gwei. Both sit in Anvil's txpool, inspectable via txpool_content, and the higher tip is ordered first.

git clone https://github.com/suyash101101/mempool-mev.git
cd mempool-mev
forge install foundry-rs/forge-std
forge test -vv

# Terminal A -- slow blocks (time to peek)
anvil --block-time 8 --port 8545

# Terminal B -- recommended live demo
chmod +x demo.sh && ./demo.sh

# Terminal C (when demo.sh pauses!)
cast rpc txpool_content --rpc-url http://127.0.0.1:8545

Expected output shows two pending ping() transactions to the same contract address, with gasPrice values of 0x3b9aca00 (1 gwei) and 0xba43b7400 (50 gwei). After the block mines, the higher-tip transaction is confirmed first — though note that lastCaller reflects whoever pinged most recently, which may not always be the high-tip account if both transactions land in the same block.

Lab 2: Sandwich Attack (sandwich-attack)

This lab proves that bots exploit the same public pool for profit. It deploys a SimpleAMM contract with a 100 WETH / 1,000,000 MEME pool, then runs through the front-run, victim swap, and back-run sequence described above.

git clone https://github.com/suyash101101/sandwich-attack.git
cd sandwich-attack
forge install foundry-rs/forge-std
forge test -vv

# Terminal A
anvil --port 8545

# Terminal B
forge script script/Sandwich.s.sol:SandwichScript \
  --broadcast --rpc-url http://127.0.0.1:8545 -vv

Expected output:

=== VICTIM INTENT (PUBLIC in mempool) ===
Swap 10 WETH -> MEME, minOut 81818

=== FRONT-RUN ===
Searcher bought MEME 47619

=== VICTIM EXECUTES ===
Victim got MEME 82815
Fair would have been 90909
Victim lost MEME 8093

=== BACK-RUN ===
Searcher profit (wei) 970654627539503386 (~0.97 WETH)

The victim's transaction succeeds — they simply get out-traded, because their swap intent was public while pending.

Key Takeaways

• Blockchains emerged from a crisis of trust in centralized ledgers, replacing a single trusted party with a shared, verifiable, gossiped history.
• Proof of Work secures Bitcoin's ledger by making block production costly (via nonce-grinding) but verification cheap; Ethereum has since moved to the more energy-efficient Proof of Stake.
• The mempool is a necessary staging area for pending transactions, but because it's public, it leaks user intent — sender, target, amount, and urgency — before transactions confirm.
• Ethereum extended Bitcoin's model with smart contracts, turning the shared ledger into a general-purpose, programmable settlement layer governed by bytecode and described by an ABI.
• Gas and EIP-1559's base fee/tip split meter computation and create a fee auction, but that same auction is what searchers exploit to win priority.
• MEV — and specifically sandwich attacks — arise directly from the combination of public mempools, AMM pricing mechanics, and user-set slippage tolerance. The victim's transaction succeeds; they're simply out-traded.
• Solving this problem requires more than obscuring identity — it requires hiding transactional intent until execution, a challenge that leads directly into privacy-preserving techniques like zero-knowledge proofs.

Resources

• Road to Devcon — deck and labs
• Mempool fee-race lab (mempool-mev)
• Sandwich attack lab (sandwich-attack)
• Foundry installation
• OpenZeppelin Contracts