Ethereum is a decentralized computing platform that does something Bitcoin was never designed to do: run programs. While Bitcoin functions primarily as a digital ledger for tracking who owns what, Ethereum extends that idea by letting developers deploy small programs called smart contracts that execute automatically when certain conditions are met. Every transaction, every contract call, and every piece of stored data is processed and verified by a global network of computers that collectively maintain a single, shared record of the system’s state. Understanding how those pieces fit together reveals a system that is equal parts financial infrastructure and distributed computer.
Accounts and How Transactions Flow
Ethereum has two kinds of accounts. The first is the kind you control directly: an externally owned account, secured by a private cryptographic key. When you install a wallet app and create an Ethereum address, you are creating one of these. The second type is a contract account, which holds code rather than being controlled by a person. Contract accounts do not have private keys. They only act when triggered by a transaction or a message from another contract. Both types of accounts can hold ether (ETH), the network’s native currency, and both have a running transaction count that prevents the same transaction from being processed twice.
A transaction on Ethereum is a signed message sent from an externally owned account. It can transfer ETH to another address, or it can call a function in a smart contract. Every transaction includes the amount of ETH to send, a fee budget, and any data the smart contract needs as input. The network processes these transactions in bundles called blocks, roughly every twelve seconds. Each block updates Ethereum’s global state: which accounts hold how much ETH, what data each contract stores, and so on. The history of all blocks, chained together cryptographically, forms the permanent record of everything that has ever happened on the network.
A newer concept called account abstraction is gradually blurring the line between these two account types. The idea is to let smart contracts themselves serve as wallets, enabling features that externally owned accounts cannot support on their own, like recovering access without a private key or paying fees in tokens other than ETH.1arXiv. Account Abstraction, Analysed It is still an evolving area, but it signals a shift toward making Ethereum accounts more flexible and user-friendly.
Smart Contracts and the Ethereum Virtual Machine
Smart contracts are what make Ethereum programmable. A developer writes a contract in a high-level language, most commonly Solidity, and then compiles it down to bytecode that the Ethereum Virtual Machine (EVM) can execute. The EVM is essentially a sandboxed computer that exists identically on every node in the network. When a transaction triggers a contract, every node runs the same bytecode with the same inputs and arrives at the same result. That deterministic quality is what makes the system trustworthy without needing a central authority: if even one node gets a different result, the network rejects it. A large-scale dataset of compiled Solidity contracts deployed on the Ethereum mainnet has catalogued roughly 135,000 unique contracts, giving a sense of how extensive the ecosystem of real-world applications has become.2arXiv. Dataset of Yul Contracts to Support Solidity Compiler Research
The types of things smart contracts can do range from the simple to the extraordinarily complex. A basic contract might act as an escrow, holding funds until both parties confirm a deal. More sophisticated contracts power decentralized exchanges where people trade tokens without an intermediary, lending platforms where loans are issued and liquidated by code, and governance systems where token holders vote on proposals. Once deployed, a contract’s code cannot be altered unless the developer built in an upgrade mechanism ahead of time. That immutability is both a strength and a vulnerability, a point we will return to.
Gas and How Fees Work
Every computation on the EVM costs gas, which is Ethereum’s way of metering how much work the network has to do. Sending a simple ETH transfer costs a fixed amount of gas. Calling a complex contract function that reads and writes lots of data costs much more. You pay for gas in ETH, and the price you pay per unit of gas fluctuates with demand.
Before 2021, Ethereum used a simple auction model: users bid whatever they were willing to pay per unit of gas, and miners picked the highest bids first. This was unpredictable and often wasteful, since users routinely overpaid to avoid being stuck in a queue. A major upgrade known as EIP-1559 overhauled the system by introducing a base fee that the protocol itself sets according to how full recent blocks are. When blocks are more than half full, the base fee rises; when they are less than half full, it falls. Crucially, the base fee is burned, meaning it is permanently removed from circulation rather than paid to validators.3arXiv. Transaction Fee Mechanism Design for the Ethereum Blockchain: An Economic Analysis of EIP-1559 Users can still add a priority tip on top of the base fee to incentivize faster inclusion, but the base fee mechanism gives everyone a much clearer sense of what a fair price is at any given moment.
EIP-1559 also introduced variable-size blocks. Instead of a fixed capacity, blocks can temporarily expand to absorb demand spikes, then contract as the rising base fee discourages lower-priority transactions. The burning mechanism has broader economic implications too: during periods of heavy network use, more ETH is burned than is issued as staking rewards, making the total supply of ETH deflationary.
Proof of Stake and How the Network Agrees
For its first seven years, Ethereum used the same consensus mechanism as Bitcoin: proof of work, where miners competed to solve computational puzzles for the right to add the next block. This was effective but enormously energy-intensive. In September 2022, Ethereum completed a long-anticipated switch to proof of stake, a transition known as “The Merge.” Under proof of stake, the network selects validators to propose and attest to new blocks based on how much ETH they have staked as collateral, rather than how much electricity they can burn.4arXiv. Mitigating Challenges in Ethereum’s Proof-of-Stake Consensus: Evaluating the Impact of EigenLayer and Lido
To become a solo validator, you need to deposit 32 ETH, which at most price levels represents a substantial financial commitment. Your node then participates in two roles: occasionally it is chosen to propose a block, and frequently it attests that other proposed blocks are valid. Honest behavior is rewarded with newly issued ETH plus tips from transactions. Dishonest or negligent behavior is punished through slashing, where a portion of the validator’s staked ETH is destroyed. The protocol can slash a validator for actions like proposing two conflicting blocks at the same height or making contradictory attestations.5Proceedings of the ChainScience 2024 Conference. Towards an Optimal Staking Design: Balancing Security, User Growth, and Token Appreciation
The shift to proof of stake brought a dramatic reduction in energy consumption, but it introduced its own challenges. The 32 ETH barrier prices most people out of solo validation. Liquid staking services arose to solve this, letting users pool smaller amounts of ETH together while receiving a tradeable token representing their stake. The trade-off is that a few large staking pools now control a significant fraction of all staked ETH, which raises questions about whether the network’s validator set is as decentralized as it should be.
How Ethereum Stores and Verifies Data
Ethereum needs to keep track of a vast amount of state: every account balance, every piece of data stored in every contract, every line of contract code. It organizes this information using a data structure called a Merkle-Patricia trie, which is a tree-like structure where every piece of data can be verified by following a path from the root of the tree down to the specific entry. The root hash of this trie is included in every block header, which means anyone can prove that a particular account had a particular balance at a particular block just by providing the path through the tree.6arXiv. Historical and Multichain Storage Proofs
This design is elegant, but it creates a practical problem: the state grows constantly. Every new contract, every new token, every abandoned account all add to the trie. Nodes have to store and traverse this ever-expanding structure. Various proposals aim to address state growth, including “state expiry” schemes that would prune data that has not been accessed in a long time while still letting users prove and restore old data if they need it. For now, running a full Ethereum node requires several hundred gigabytes of storage and fast disk access, which is manageable for enthusiasts and businesses but not trivial.
Scaling with Rollups and Blobs
Ethereum’s base layer processes around 15 to 30 transactions per second, which is nowhere near enough for mass adoption. Rather than trying to make the base layer faster (which risks sacrificing decentralization or security), the Ethereum community has converged on a scaling strategy centered on rollups. A rollup is a separate chain that executes transactions off the main Ethereum chain but posts compressed summaries and proof data back to Ethereum for verification. Users get fast, cheap transactions on the rollup, and Ethereum provides the security guarantee that the rollup’s data is correct and available.
There are two main flavors. Optimistic rollups assume transactions are valid unless someone challenges them within a dispute window, usually about a week. Zero-knowledge rollups generate a cryptographic proof that the batch of transactions was executed correctly, and the proof is verified on Ethereum’s base layer. Both approaches need to post enough data to Ethereum so that anyone can reconstruct the rollup’s state independently. This data posting used to be expensive because it occupied the same block space as regular transactions.
A March 2024 upgrade known as EIP-4844, or “Proto-Danksharding,” addressed this by introducing a new type of transaction called a blob-carrying transaction. Blobs are large chunks of data that are referenced and verified on-chain but stored temporarily off-chain, making them much cheaper than embedding the same data directly into a transaction’s call data.7arXiv. Delay Analysis of EIP-4844 Blobs have their own separate fee market and are automatically pruned after a few weeks, since they are only needed long enough for anyone who wants to verify the rollup’s state to download them. The concern, as researchers have pointed out, is that storing transactions entirely off-chain introduces a data availability risk: if rollup nodes disappear or act dishonestly, data could be lost.8arXiv. Data Availability and Decentralization: New Techniques for zk-Rollups in Layer 2 Blockchain Networks Blob transactions represent an intermediate step. Full “Danksharding,” a future upgrade, aims to increase blob capacity substantially while integrating stronger data availability sampling techniques.
Maximal Extractable Value
One of the less visible but economically significant aspects of how Ethereum works is something called maximal extractable value, or MEV. Validators (and the specialized “builders” who assemble blocks for them) can extract extra profit by reordering, inserting, or excluding transactions within a block. A common example is sandwich attacks: a bot spots your pending trade on a decentralized exchange, places its own buy order right before yours to push the price up, then sells right after your trade executes at the inflated price, pocketing the difference. Other MEV strategies include arbitrage between exchanges and liquidating under-collateralized loans.
The MEV economy has led to a separation of roles between block proposers and block builders. Today, most Ethereum blocks are constructed by specialized builders who compete in an auction to produce the most profitable block, then pay the proposer (the validator selected by the protocol) for the right to have their block included. Research into enshrining this proposer-builder separation directly into the protocol (known as ePBS) has found that it concentrates profits sharply: one study measured a Gini coefficient for builder profits of 0.83 under ePBS, meaning a small number of efficient builders would capture the vast majority of value.9arXiv. Enshrined Proposer Builder Separation in the presence of Maximal Extractable Value For regular users, the practical takeaway is that the order your transaction appears in a block is not neutral, and using private transaction submission tools or MEV-aware wallets can help minimize the value extracted from your trades.
Security Risks in Smart Contracts
Because smart contract code is immutable once deployed and often controls large sums of money, bugs can be catastrophic. The most infamous class of vulnerability is reentrancy, where a malicious contract tricks another contract into calling back into it before the first call has finished, allowing funds to be drained in a loop. The very first high-profile attack on Ethereum exploited exactly this flaw. In June 2016, an attacker drained roughly 3.7 million ETH, worth about $60 million at the time, from a project called The DAO.10Frontiers in Human Dynamics. The Dissensus Protocol: Governing Differences in Online Peer Communities That crisis split the Ethereum community into those who believed the code should stand as written and those who wanted to reverse the theft. The latter group won, and Ethereum performed a “hard fork” to restore the stolen funds, while the original unaltered chain continued as Ethereum Classic.
Reentrancy attacks have not gone away. By the end of 2023, cumulative losses from reentrancy exploits across the Ethereum ecosystem had reached an estimated $350 million across 58 reported incidents, averaging about $5.9 million per attack.11ScienceDirect. Welcome back: A systematic literature review of smart contract reentrancy and countermeasures – Section: 5.3. RQ3: Is reentrancy countered in practice? Which tools exist? Automated detection tools have improved, particularly those using machine learning, but they remain only partially effective against novel attack variants. Other vulnerability classes include integer overflows, access-control mistakes, and logic errors, all of which underscore why smart contract auditing is a serious (and expensive) industry.
Bridges and Cross-Chain Risks
As the blockchain landscape has expanded, users frequently want to move assets between Ethereum and other chains. Cross-chain bridges handle this by locking tokens on one chain and issuing equivalent tokens on the other. The problem is that bridges are architecturally complex and represent high-value targets. Since May 2021, bridge exploits have caused an estimated $3.2 billion in losses across the industry. Two of the largest incidents involved the Ronin bridge, which lost $611 million, and the Nomad bridge, which lost $190 million.12arXiv. XChainWatcher: Monitoring and Identifying Attacks in Cross-Chain Bridges
These numbers dwarf most individual smart contract exploits, and they highlight a structural challenge. A bridge has to be trusted by users on both chains, yet it operates in a gray zone between two different security models. Vulnerabilities can arise in the bridge’s smart contracts, in its off-chain relay infrastructure, or in the consensus mechanism it uses to verify cross-chain messages. For users, the practical advice is straightforward: bridges carry significant risk, and the amount you move through any single bridge should reflect your tolerance for the possibility that those funds could be lost.
The DAO Fork and What It Revealed About Governance
The 2016 DAO incident was not just a security event; it became a defining moment in Ethereum’s approach to governance. Two philosophical camps emerged. One argued that “code is law” and that the outcome of the exploit, however painful, should stand because the whole point of a decentralized system is that no central authority can reverse transactions. The other argued that the community’s social consensus was the real authority, and that fixing an obvious exploit was the right thing to do. The decision to hard fork and restore the stolen funds set a precedent: Ethereum’s governance ultimately rests on rough social consensus among its stakeholders, not on rigid code determinism.13Frontiers in Human Dynamics. The Dissensus Protocol: Governing Differences in Online Peer Communities
In practice, Ethereum’s governance today operates through a process of Ethereum Improvement Proposals (EIPs). Anyone can write one, but getting an EIP into a network upgrade requires persuading core developers, client teams, and the broader community. There is no formal voting mechanism for protocol changes. Instead, decisions are hashed out in public calls, forum posts, and conferences. It is slow and sometimes contentious, but it has so far avoided the kind of capture by a single company or foundation that critics of centralized systems worry about. The DAO crisis also catalyzed a wave of governance-focused projects, as teams began exploring how blockchain tools themselves could be used to manage collective decision-making in decentralized organizations.
What Running the Network Actually Looks Like
At the infrastructure level, Ethereum is sustained by thousands of nodes running client software. There are two pieces of software every node needs: an execution client, which processes transactions and runs the EVM, and a consensus client, which handles proof-of-stake duties like attestation and block proposal. The two most popular execution clients are Geth and Nethermind, and on the consensus side, Prysm and Lighthouse. Running multiple client implementations is a deliberate design choice: if a bug exists in one client, nodes running a different client will reject the bad blocks, preventing a single software flaw from corrupting the entire network.
A full node downloads and verifies every block from the genesis block onward, maintaining a complete copy of the current state. An archive node goes further, retaining every historical state, which is useful for developers querying what an account looked like at block 5,000,000 but requires multiple terabytes of storage. Light clients, by contrast, download only block headers and request specific data on demand, relying on full nodes to supply it. The Merkle-Patricia trie structure makes this feasible because a light client can verify any piece of data against the block header’s root hash without storing the full state.
For the average user interacting through a wallet like MetaMask, none of this infrastructure is visible. Your wallet connects to a node (often operated by a provider like Infura or Alchemy), signs transactions with your private key, and submits them. But the decentralization properties that make Ethereum trustworthy depend on enough independent people running their own nodes. The ongoing work to reduce hardware requirements for node operators, through statelessness research, history expiry, and more efficient data structures, is arguably as important to Ethereum’s long-term health as any flashy new feature.