Without a central server,how does everyone keep the same ledger?

A traditional bank ledger has a natural center: whatever the bank’s database says you own is the authoritative business record. A distributed ledger removes that single authoritative machine, yet it must still let strangers answer: Who submitted what, in what order, and what is the valid state now?

A distributed ledger therefore cannot be merely a static table. It is closer to a replicated state machine maintained collectively by many computers: nodes store protocol data, receive inputs, validate and execute them under the same rules, then use consensus to decide which ordered history is canonical.

In Ethereum, “ledger” is also an incomplete but useful introductory metaphor. It records more than ETH transfers: it maintains accounts, contract code, and contract storage. The official EVM documentation describes Ethereum as a state transition machine: given an old state and a set of valid transactions, the rules produce a new state.^[1]

“Distributed” describes deployment; “ledger” describes shared facts

Distributed means data and computation exist across multiple interconnected machines; it does not automatically imply decentralization. A company can run a hundred database servers around the world and still place them all under one administrator. A blockchain must additionally handle open participation, mutual distrust, adversarial behavior, and authority over rule changes.

A more precise definition is therefore: a distributed ledger is a record-keeping system whose replicas are held or verified by multiple independent participants, with a shared protocol determining valid updates and canonical history. Ethereum extends this record-keeping system into a programmable shared state machine.

Suppose Alice sends two conflicting requests at nearly the same time: one transfers the same funds to Bob, the other to Carol. A node in New York may see the first request before the second, while a node in Singapore may see the second first. Neither machine is broken; they simply have different views of the network.

Consistency does not mean “every replica is identical every millisecond”

Distributed systems generally distinguish safety from liveness. Safety asks whether the system avoids finalizing conflicting histories; liveness asks whether it can continue making progress and eventually finalizing new checkpoints once network conditions return to normal. A design may temporarily halt finalization to avoid conflicting finalization, or accept weaker certainty in exchange for faster progress.

Ethereum allows nodes to see different candidate blocks near the chain head briefly, then converge through the fork-choice rule. For checkpoints that have reached finality, it offers a stronger guarantee against reversal. Thus “transaction seen,” “included in a block,” “on the current chain head,” and “finalized” are four distinct states.

Imagine Alice’s wallet submitting a transfer. Any node may hear the request, but no node changes a balance simply because “the wallet said so.” Each receiving node first checks basic conditions such as encoding and signature. Once the transaction enters a candidate block, other fully validating nodes re-execute the entire block to verify the resulting state.

Consensus is not majority rule over computation

This boundary is crucial. If a block contains a forged signature or an incorrect state transition, your node can declare it invalid directly under the rules; even if many nodes claim it is valid, your node should not accept it. Fork choice uses attestation weight to select a current head among multiple valid candidates; it cannot vote 2 + 2 into equaling 5.

This is the engineering meaning of “don’t trust, verify”: a node relies on the public specification and the checks it performs itself, not on the reputation of an API, block explorer, block proposer, or neighboring node. One value of running a full node is precisely the ability to verify transactions and blocks yourself. ^[2]

Since The Merge, Ethereum has split transaction and state computation from proof-of-stake consensus across two tightly coordinated clients. These layers are not two separate chains; they divide responsibilities inside one Ethereum node. The official node documentation is explicit: a node needs both an execution client and a consensus client.^[2]

The proposer supplies a candidate; other nodes still recompute it

Each slot selects one validator as block proposer. A local execution client or an external builder through the Builder API may assemble a candidate execution payload; the proposer incorporates the selected candidate into its Beacon-block proposal. When other full Ethereum nodes receive the resulting block, they pass its execution payload to their own execution clients for re-execution. Only after it passes do they treat it as a valid candidate. Of these nodes, only validators running validator software and assigned a duty for that slot publish attestations.

A validator is therefore not a “central bookkeeper” in the traditional sense. It may propose what goes on the next page, but it cannot rewrite the validation rules unilaterally. If it includes an invalid transaction or incorrect state root, protocol-compliant nodes reject the block.

Gasper: chain-head selection plus checkpoint finality

Ethereum’s consensus mechanism today is commonly called Gasper. It combines LMD-GHOST for chain-head selection with Casper FFG for checkpoint finality. When several valid branches exist near the head, fork choice considers the stake weight represented by validators’ latest attestations. When a valid source → target checkpoint link from a justified source receives attestation weight from at least two-thirds of active validators’ total effective balance, the target becomes justified. Only after a later link satisfies Casper FFG’s conditions does an earlier justified checkpoint become finalized. ^[4]

“Two-thirds” means effective-balance weight, not node count

Beginners often read “66% agreement” as 66% of computers on the internet clicking yes. The formal denominator is active validators’ total effective balance. Full nodes that do not operate validators do not produce stake-weighted attestations, but they still validate blocks independently. A validator is a role that adds proposing and attesting duties on top of full-node capabilities; the validator’s node must validate blocks too.

To create conflicting finalized histories, at least one-third of active effective balance must violate accountable-safety conditions by issuing slashable conflicting attestations. Those validators face slashing, and actually reverting history that clients have already finalized may also require social-layer coordination. This is “cryptoeconomic finality”: it does not claim that no failure is physically possible. It makes a finality violation provable, attributable, and extremely costly. ^[6]

Why can different teams implement clients in different languages?

Ethereum has multiple execution-client and consensus-client implementations. Their internal database structures, performance strategies, and programming languages may differ, but every implementation must follow the same protocol specification. Multiple implementations reduce the risk of the entire network depending on one codebase. They also impose a stricter requirement: the specification must be precise, and different implementations must reach the same result at consensus boundaries.

If one client produces an incorrect result because of a bug, independent implementations do not accept it merely because it is “well-known software.” Client diversity is therefore both an engineering ecosystem and part of removing single points of failure.

Suppose Alice has 3 ETH and her account nonce is 7. She signs two conflicting transactions that both use nonce 7: X sends 2 ETH to Bob; Y sends 2 ETH to Carol. To isolate the nonce conflict, this example omits transaction fees.

Both signatures may be genuine authorization, and either transaction may satisfy the balance requirement on its own; but an account can use a given nonce only once in canonical history. Whichever transaction is included in the valid block that becomes canonical updates Alice’s nonce from 7 to 8. The other has a stale nonce on descendants of that branch and cannot be included there. If both are forced into one execution sequence, the block becomes invalid at the second transaction. The network must therefore agree on both the set of valid transactions and their deterministic order.

A block provides a “batch”; the chain orders the batches

A block organizes transactions and metadata into a verifiable unit. Each block points to its parent, creating an ordered history. The next lesson will unpack block headers, timestamps, transaction data, and hashes. For now, hold on to the most important point: blocks are not file-compression bundles; they let a distributed network share a reference for the boundary and order of a batch of state transitions.

Near the chain head, a proposer may make two proposals, or proposers in different slots may build on different parents because of network delay, creating a temporary fork. Nodes use fork choice to select the current head, while additional attestations and eventual finality strengthen certainty over time. Applications therefore distinguish “broadcast,” “included,” “confirmed,” and “finalized.”

A company’s distributed database normally knows the identities of its servers and has administrators, access controls, and a legal chain of responsibility. A public blockchain operates in an open environment: anyone may submit a transaction, while nodes and validators are run by unrelated parties. The system cannot treat one administrator’s word as the final answer.

Keep three terms distinct: a distributed database emphasizes storing and coordinating data across multiple machines; a distributed ledger emphasizes multiple parties maintaining a verifiable record under a shared protocol; a blockchain is one distributed-ledger structure that organizes records into blocks and links them in a chain. Not every distributed database is decentralized, and not every distributed ledger must be a blockchain. Ethereum has features of all three, but its trust model is that of an open public blockchain.

Why does a blockchain look “redundant and expensive”?

Because redundancy is part of the security model. Many nodes propagating the same data, re-executing the same transactions, and retaining verifiable commitments is slower and more resource-intensive than letting one trusted server write directly to a database. Ethereum does not optimize for single-machine efficiency; it optimizes for any participant being able to verify the result without a shared administrator.

This also explains the enduring trade-offs among decentralization, security, and throughput, and why Ethereum needs Layer 2. Later scaling chapters will examine how much execution can move off-chain or to Layer 2 while settlement and data-availability security remain anchored to Ethereum.

Different nodes need not store the same amount of data

Full nodes validate blocks and transactions but may prune older state data to save disk space. Archive nodes retain queryable historical states; light clients verify key commitments with less data. It is therefore inaccurate to say that “every node permanently stores every detail since genesis.” What matters is that each node type reaches protocol-based, verifiable conclusions appropriate to its security model. ^[2]

Consensus cannot decide whether something is worthwhile

The network can agree that a contract executed successfully, but that says nothing about whether the contract is well designed, a token has value, lending risk is manageable, or you understood an authorization when you signed it. A distributed ledger guarantees verifiable agreement within the protocol’s scope, not investment quality, legal validity, or real-world truth.