What is Ethereum?

Introduction

Ethereum is a blockchain designed not just to move a native asset, but to run shared programs that anyone can inspect, call, and build on. That sounds like a small extension of Bitcoin’s original idea, yet it changes the character of the system completely. A ledger that only tracks balances asks whether a payment is valid. A ledger that also executes code asks whether a whole state transition is valid: not just "did Alice send Bob money," but "did this market settle, did this loan remain collateralized, did this token contract mint correctly, did this governance system update its rules according to its own procedure?"

That is the central idea behind Ethereum. It is a decentralized blockchain network and software platform powered by ether, or ETH, its native asset. ETH pays for computation through gas fees, and in today’s proof-of-stake system it is also what validators stake to help secure the network. The reason Ethereum became foundational is not only that it introduced smart contracts, but that it made programmability the default model of the chain.

If you want the shortest useful definition, here it is: Ethereum is a global state machine with built-in programmability. Everyone who runs the protocol agrees on the same evolving state, and the rules for changing that state can include user-defined programs called smart contracts. Once that clicks, the rest of Ethereum begins to make sense: the EVM, gas, tokens, DeFi, NFTs, rollups, and even Ethereum’s unusually willing attitude toward protocol change.

How does Ethereum’s account-based state and execution model work?

The easiest way to see Ethereum clearly is to contrast it with Bitcoin. Bitcoin’s design centers on ownership and transfer of coins, with a deliberately constrained scripting system around that goal. Ethereum asked a different first question: what if the chain itself were a general execution environment? Vitalik Buterin’s 2013 whitepaper argued that many blockchain applications were all trying to do the same thing in awkward ways; bolt application logic onto systems not designed for arbitrary programs. Rather than create a new chain for each feature, Ethereum proposed a single platform with a built-in programming language capable of expressing arbitrary state transitions.

That phrase, arbitrary state transitions, is the heart of the architecture. A blockchain always has some notion of state: who owns what, what transactions have happened, what the current ledger says. Ethereum generalizes this. Its state is made up of accounts, and each account can contain a balance, a nonce used to prevent replay, contract code if the account is a contract, and storage if that contract needs persistent data. Instead of merely consuming and creating outputs, as in Bitcoin’s UTXO model, Ethereum updates this account-based state directly.

This makes Ethereum feel more like a world computer than a cash ledger. A user sends a transaction. That transaction targets another account; sometimes a person-controlled account, sometimes a contract. If it targets a contract, the network executes the contract’s code in a deterministic way. Every validating node computes the same result. If execution succeeds, the global state changes accordingly. If execution fails, the state changes are reverted, though the user still pays for the computation attempted.

That last detail matters because it shows the core tradeoff. General computation is powerful, but it is also dangerous. If users can submit arbitrary code, they can also submit code that runs forever or consumes enormous resources. Ethereum’s answer is gas: computation must be metered.

What is an Ethereum smart contract and how does it enforce rules?

The phrase smart contract can mislead people because it sounds legalistic. On Ethereum, a smart contract is just a program stored onchain that runs when called. It is not smart in the human sense, and it is not necessarily a contract in the legal sense. It is closer to a public function with memory: code plus persistent storage, living at an address, available to anyone.

What makes this important is not merely automation. Ordinary software automates things too. The difference is that Ethereum contracts run in a consensus system. When a contract executes, the result is not accepted because one server says so. It is accepted because the network, through its validation rules, agrees that this execution is the valid next state. That is why people can build exchanges, lending protocols, stablecoins, NFT systems, identity primitives, and DAOs on top of Ethereum without needing a single operator to be trusted as the final arbiter.

A simple example helps. Imagine a token contract. The contract stores balances in its own storage. When you call transfer, the contract checks whether your balance is large enough, subtracts from your balance, adds to the recipient’s balance, and updates the state. That sounds mundane, and it is; but the important point is where the rules live. They live in the contract’s code, enforced by the Ethereum network. No central database admin can quietly alter them, and anyone can inspect the contract’s logic before interacting with it.

Now extend that mechanism. A lending protocol can store collateral positions and debt balances, check collateral ratios, accrue interest, and liquidate unsafe positions according to explicit rules. An NFT contract can define unique token IDs and ownership transfers. A DAO contract can count votes and execute treasury actions if a quorum is reached. These are all variations on the same idea: the chain is not just recording activity; it is executing application logic as part of consensus.

This was a major departure from Bitcoin’s more limited scripting model. Bitcoin’s restraint is a design choice aimed at minimizing complexity and attack surface. Ethereum accepted more complexity in exchange for broader expressive power. That decision created an enormous design space; and also a larger security surface. Many of Ethereum’s greatest successes and worst failures both come from that same choice.

What is the Ethereum Virtual Machine (EVM) and why do nodes use it?

If smart contracts are programs, where do they run? They run in the Ethereum Virtual Machine, or EVM. The EVM is the execution environment that handles computation on the Ethereum network. You can think of it as an abstract computer specified by the protocol. Every Ethereum execution client implements this machine, and when a transaction triggers contract code, each client runs the same instructions and must arrive at the same result.

The reason for a virtual machine is determinism. A blockchain cannot simply let contracts run directly on whatever hardware and operating system each node happens to use; that would produce inconsistent behavior. Instead, Ethereum defines a common execution model with specific opcodes, memory behavior, storage access rules, and gas costs. In effect, the protocol says: here is the exact computational world in which contracts live.

This execution environment is deliberately constrained even while being expressive. The whitepaper described Ethereum as providing a fully fledged, Turing-complete programming language, but that does not mean contracts run with unconstrained access to the outside world. They cannot fetch arbitrary web pages on their own or read a server clock directly. They can only use data available inside the protocol unless outside information is brought in through some oracle mechanism. That limitation is not an accident; it is part of what makes deterministic consensus possible.

A worked example makes the mechanism concrete. Suppose you use a decentralized exchange on Ethereum to swap one token for another. Your wallet sends a transaction to the exchange contract. The transaction includes data describing which function to call and with what parameters. Every node executes that contract call in the EVM. The contract reads its storage to see the current pool reserves, computes the exchange rate according to its formula, checks that the trade meets slippage constraints, updates token balances, and emits logs describing what happened. If any check fails (perhaps your minimum output amount is no longer achievable) execution reverts and the state remains unchanged. The network then records the transaction result in a block. No single exchange operator is deciding whether your swap went through. The protocol is.

This is why the EVM became bigger than Ethereum itself. Many other chains chose EVM compatibility because the EVM is not just a runtime; it is an ecosystem standard. If you support EVM semantics, you inherit languages, tooling, wallets, libraries, and a developer mental model already familiar to Ethereum builders.

Why does Ethereum charge gas and what happens when a transaction runs out of gas?

Ethereum’s programmability would be unusable without a way to meter computation. If contracts could loop forever at no cost, the network would be easy to attack and impossible to keep synchronized. Gas is Ethereum’s solution. Gas measures the computational resources a transaction consumes, and transaction senders pay for that gas in ETH.

The underlying logic is simple. Every EVM operation has a gas cost. Cheap operations cost little; operations that touch storage or perform more work cost more. When you submit a transaction, you specify how much gas you are willing to let it consume. If execution uses less, the unused portion is not spent. If execution runs out of gas, the computation stops, state changes revert, and the fees for work attempted are still paid.

This does two jobs at once. First, it prevents denial-of-service through unbounded computation. Second, it allocates scarce block space and execution capacity to the users who value it most. Ethereum is a shared computer with finite throughput. Gas is the pricing mechanism for that finite resource.

For users, this means fees vary not just with congestion, but with what they are asking the network to do. Sending ETH is usually cheaper than executing a complicated contract path because the latter requires more computation and storage access. For developers, gas is also a design constraint. A contract can be logically correct and still be poorly designed if it is too expensive to use.

How does EIP‑1559 change transaction fees and affect ETH supply?

Originally, Ethereum’s fee market looked more like a first-price auction: users bid gas prices, and block producers tended to include the highest-paying transactions. That worked, but it was often noisy and inefficient. Users overpaid to avoid being stuck, wallets struggled to estimate the right fee, and fee spikes were chaotic.

EIP-1559 changed this by splitting fees into two parts. Each block now has a protocol-level base fee per gas, which adjusts up or down depending on how full recent blocks have been. If demand is above a target level, the base fee rises. If demand is below target, it falls. Users can also add a priority fee, or tip, to encourage inclusion. Importantly, the base fee is burned, while validators receive the priority fee.

That mechanism matters for three different reasons. First, it improves usability because wallets can estimate fees more reliably. Users no longer need to guess the entire market-clearing price in a pure auction. Second, it changes validator incentives by separating the unavoidable part of the fee from the discretionary tip. Third, it affects ETH’s supply because the burned base fee removes ETH from circulation.

This does not mean ETH has a fixed supply guarantee. In fact, EIP-1559 explicitly gave that up. ETH supply now depends on the balance between issuance and burning. On high-demand days, enough ETH may be burned to offset new issuance or exceed it. On low-demand days, issuance may dominate. That is a demand-linked monetary dynamic, not a fixed cap.

There is also a subtle conceptual point here. Burning the base fee ties usage of Ethereum to ETH’s monetary behavior. The more people use block space, the more base fee can be burned. That is not merely a tokenomic flourish; it is a way of making network demand feed back into the asset that secures and pays for the network.

What is ETH used for; fees, staking, and network security?

ETH is Ethereum’s native asset, but calling it just a cryptocurrency understates its role. ETH is the only asset accepted for paying gas on mainnet. That alone gives it persistent functional demand. After the move to proof of stake, ETH also became the asset validators lock up to participate in consensus. So ETH sits at the center of two different mechanisms: payment for computation and economic security.

This dual role explains why ETH is not best understood as merely a speculative token. It is closer to the system’s internal commodity. You need it to buy execution, and validators need to post it as economic collateral. The protocol can mint new ETH as validator rewards, and it can destroy ETH through fee burning. Those flows together determine net issuance.

In everyday use, ETH also serves as a base asset across the ecosystem. It is common collateral in decentralized finance and a common trading pair across markets. But the fundamental part is still simpler: ETH is what the protocol asks for when you want something from the chain, and what the protocol puts at risk when it wants honest behavior from validators.

How did the Merge switch Ethereum from proof of work to proof of stake?

Ethereum did not begin with proof of stake. It launched in 2015 using proof of work, like Bitcoin, and for years miners produced blocks by expending computation. The long-term plan, however, was always to move toward proof of stake, where validators lock ETH as a security deposit and are rewarded or penalized according to behavior.

That transition finally happened in 2022 in an upgrade called the Merge. Mechanically, the Merge joined Ethereum’s original execution environment with the Beacon Chain, the proof-of-stake consensus chain that had been running in parallel since 2020. After the Merge, execution-layer proof-of-work issuance dropped to zero, and Ethereum’s consensus began relying on staked ETH rather than mining hardware.

This was one of the most consequential upgrades ever performed on a live blockchain. It changed Ethereum’s energy profile dramatically, reduced annual ETH issuance substantially, and reshaped the network’s security model around validators rather than miners. Post-Merge, new ETH issuance comes from the consensus layer, and the exact amount depends on how much ETH is staked and how validators perform.

The Merge also reveals something important about Ethereum’s culture. Ethereum is willing to make deep protocol changes if it believes they improve the system’s long-term design. That is not universally admired. Some see it as adaptability; others see it as willingness to tamper with core assumptions. Either way, it distinguishes Ethereum from Bitcoin’s much more conservative governance ethos.

Which events shaped Ethereum’s governance and upgrade culture?

Ethereum’s history is not just a sequence of upgrades. It is a record of what the community is willing to optimize for and what kinds of change it considers legitimate.

Vitalik Buterin published the Ethereum whitepaper in late 2013 after concluding that blockchains needed a more general programming model than existing systems provided. In 2014, Ethereum held a crowdfund to support development. The project’s early pitch was unusually expansive: not a single application, but a platform on which many applications could be built. That ambition attracted developers precisely because it offered a shared substrate rather than a narrow product.

Then came the event that still defines Ethereum’s governance debates: the DAO hack in 2016. The DAO was a smart-contract-based investment vehicle that accumulated a huge amount of ETH, and a vulnerability in its contract logic was exploited. In response, the Ethereum community adopted a contentious hard fork that executed what the Ethereum Foundation later described as an irregular state change, transferring roughly 12 million ETH into a recovery contract. Many supported the fork as an extraordinary but justified response. Others opposed it on principle, arguing that immutability should not bend even for a catastrophic exploit.

That disagreement did not remain philosophical. It created a chain split. The forked chain continued as Ethereum, while the unforked chain continued as Ethereum Classic. This is one of the clearest case studies in blockchain governance because it shows that “the chain” is not just code or cryptography. It is also a social consensus about which rules, history, and interventions count as legitimate.

Years later, the Merge replayed that same Ethereum character in a different form. Moving from proof of work to proof of stake was not a rescue operation like the DAO fork, but it was still a fundamental redesign enacted through broad coordination among client teams, researchers, validators, developers, and the wider community. Ethereum again showed that it treats the protocol as something that can evolve significantly if enough of the ecosystem accepts the case for change.

How are protocol changes proposed and decided on Ethereum?

Ethereum is often described as having no CEO or central authority, and at the protocol level that is true in an important sense. No one can unilaterally change the rules for everyone. But it would be a mistake to infer from this that Ethereum has no governance. It has a great deal of governance; it is simply distributed, messy, and public.

The formal artifact of protocol change is the Ethereum Improvement Proposal, or EIP. EIPs describe proposed standards or changes to the Ethereum platform, including core protocol changes, client APIs, and contract standards. They move through a defined lifecycle and are discussed in public. But an EIP is not law by itself. It is a coordination document. The actual adoption of a protocol change still requires broad ecosystem agreement and implementation across clients.

This is where Ethereum differs from both a company and a purely spontaneous network mythology. The Ethereum Foundation plays an important role in funding research, supporting ecosystem work, and convening discussion, but it does not simply decree upgrades into existence. Client teams, researchers, validators, application developers, infrastructure providers, and users all matter. The execution-specs and consensus-specs repositories, upgrade manifests, client releases, and public coordination processes all reflect this multi-actor structure.

The DAO fork shows the sharp edge of that governance model. When values collide (immutability versus intervention, continuity versus repair) there is no algorithm that decides the answer. The network resolves the dispute socially, and if disagreement is deep enough, it can produce a chain split. Bitcoin tends to treat such events as evidence that protocol norms should be extremely conservative. Ethereum tends to treat them as evidence that social governance is unavoidable and should be engaged openly.

Why are rollups making Ethereum a settlement layer and how do they work?

Ethereum’s success created its own problem. If many applications want to use the same highly decentralized base layer, fees rise and throughput becomes constrained. Ethereum’s response has increasingly been rollup-centric scaling: keep the base layer highly secure and decentralized, and move most transaction execution to Layer 2 systems that settle back to Ethereum.

A rollup executes transactions outside Ethereum mainnet, then posts transaction data or commitments back to Ethereum so the rollup can inherit Ethereum’s security properties. The basic idea is straightforward: don’t ask the base layer to execute every single user action directly if it can instead verify or anchor the results of many actions batched together.

There are two main rollup security models. Optimistic rollups assume posted state transitions are valid unless challenged. They rely on fault or fraud proofs and a challenge window during which someone can dispute an invalid batch. This is why withdrawing from an optimistic rollup to mainnet typically involves a delay: the system must leave time for disputes. ZK-rollups, by contrast, submit a cryptographic validity proof showing that the offchain computation was correct. Because the proof attests correctness directly, exits can settle without the same optimistic challenge delay once the proof is verified.

The difference is not merely academic. Optimistic rollups tend to be more straightforward in EVM compatibility, which helped early adoption. ZK-rollups offer stronger immediate correctness guarantees and faster withdrawal finality, but proof generation is computationally intensive and historically made EVM equivalence harder. Both approaches are ways of buying scale by moving most work off the base chain while still leaning on Ethereum for settlement and data availability.

This is also where Ethereum’s roadmap differs from Bitcoin’s Lightning strategy. Lightning is a network of payment channels optimized for high-frequency transfers between participants who can open and close channel relationships. Rollups are closer to general-purpose execution environments that batch whole application activity and settle to L1. Lightning scales payments especially well; rollups aim to scale a programmable application platform.

Recent protocol work reinforces this direction. Ethereum’s scaling documentation explicitly frames the ecosystem as favoring rollup-centric scaling, supported by cheaper data publication mechanisms for rollups. The broad picture is that Ethereum mainnet is becoming less the place where every user action happens and more the place where many systems settle, prove, and anchor their state.

What are common Ethereum use cases: DeFi, NFTs, and DAOs?

Once the programmable-state model is clear, Ethereum’s applications stop looking like unrelated hype cycles and start looking like different expressions of the same machine. Tokens are balances governed by contract code. Stablecoins are tokens whose issuance and redemption logic connect onchain state to offchain reserves or collateral systems. DeFi protocols are financial state machines: exchanges, lending markets, derivatives, and collateral engines encoded as contracts. NFTs are uniqueness and ownership rules enforced by contracts. DAOs are treasury and voting rules enforced by contracts.

This does not mean all of these applications are equally durable or equally decentralized. Some depend heavily on external infrastructure, offchain governance, or trusted data sources. Oracles remain a central dependency for many financial uses. Wallet UX remains a major safety bottleneck. Infrastructure providers, RPC services, L2 operators, and cloud dependencies can become concentrations of power or operational risk. Ethereum’s own security work increasingly emphasizes that the base protocol may be robust while surrounding layers remain fragile.

Still, the common mechanism is the same: Ethereum gives applications a shared execution and settlement environment where the rules are public and composable. A lending protocol can integrate a price oracle, hold ERC-20 tokens, accept NFT collateral wrappers, and settle through stablecoins because all of these are built in interoperable contract form on the same platform. That composability is one of Ethereum’s strongest economic properties.

What are the main limitations and risks of building on Ethereum?

Ethereum solves a specific problem well: coordinating shared state and programmable rules without a central operator. But that does not mean it is a good fit for every kind of software.

It is expensive compared with normal databases. It is slow compared with centralized systems. Smart contracts are hard to upgrade safely. Bugs can be catastrophic because funds are often directly controlled by code. Contracts cannot natively access external facts without oracles. Governance disputes can be resolved only socially, not mechanically. And scaling through rollups introduces new layers of complexity around bridges, sequencers, challenge windows, data availability, and operational trust assumptions.

Even Ethereum’s strengths create pressures. The richer the execution environment, the larger the attack surface. The more value the ecosystem holds, the more important client diversity, operational resilience, and incident response become. The more activity migrates to L2s, the more Ethereum must ensure those systems still inherit meaningful security rather than merely borrowing its brand.

So Ethereum is best thought of neither as an all-purpose computer nor as a finished monetary protocol. It is a carefully constrained consensus computer whose usefulness depends on what assumptions you are willing to make about cost, latency, and trust at each layer.

Conclusion

Ethereum is best understood as a programmable blockchain that maintains a shared global state. Smart contracts make that state useful, the EVM makes execution deterministic, gas makes computation governable, ETH ties usage to security, and rollups are Ethereum’s answer to scaling that system without giving up the base layer’s decentralization.

Its history shows the same pattern as its design: Ethereum is ambitious, adaptable, and willing to change. That willingness created the EVM, DeFi, NFTs, and the rollup ecosystem. It also produced contentious moments like the DAO fork and ongoing debates about governance, security, and what decentralization should mean in practice.

If you remember one thing tomorrow, remember this: Bitcoin asked how to make digital money without a central authority. Ethereum asked how to make shared computation work the same way. Everything distinctive about Ethereum follows from that second question.

How do you buy Ethereum?

Buy ETH on Cube by trading the ETH/USDC market; you can use a fiat on‑ramp or deposit USDC and execute a market or limit order in a few steps. The workflow below shows the concrete actions to fund, place, and confirm a trade on Cube.