Distributed Systems

A distributed system consists of computers that coordinate over a network. Each machine has local memory and learns about other machines through messages. Messages take time, can arrive out of order, can be duplicated, or can fail to arrive. A machine can fail while others continue running.

The practical consequence is that “the system state” may not be known identically by every participant at the same instant. Distributed algorithms are designed around that uncertainty.

A crash-faulty node stops responding or loses connectivity. A Byzantine node can behave arbitrarily: sending inconsistent messages, lying about state, or selectively responding to different peers. Algorithms that tolerate only crashes can be much simpler than those designed to tolerate malicious behavior.

Public blockchains assume some participants can be economically motivated attackers, so their consensus models include adversarial behavior rather than only accidental outages.

Keeping copies of data on many machines protects against one server failure and places data near users. But every update must somehow be ordered and reconciled across replicas. Strong consistency tries to make reads behave as if there were one agreed order; eventual consistency allows replicas to differ temporarily while converging later.

Blockchains deliberately accept propagation delay and use consensus to define an authoritative order for state-changing transactions.

During a partition, one group of nodes cannot communicate with another. A system can halt updates to preserve one consistent history, or allow both sides to continue and reconcile later. Consensus protocols choose their behavior through safety and liveness assumptions.

This is why “decentralized” does not mean “always available.” A protocol may intentionally stop finalizing rather than risk two finalized histories.

Machine clocks drift and network latency varies, so a timestamp from one node is not absolute proof of global ordering. Distributed systems often use logical sequence numbers, consensus rounds, slots, epochs, or bounded timestamp rules instead of trusting wall-clock time alone.

Blockchains that include timestamps constrain their use carefully because malicious or inaccurate clocks can otherwise affect consensus.

A distributed system replaces shared local memory with message passing among independent computers. That simple architectural change creates hard problems: messages can be delayed, duplicated, reordered, or lost; one machine can fail while others continue; clocks can disagree; and two correct nodes can temporarily observe different events. A blockchain inherits all of those conditions before adding cryptographic authorization and consensus.

This explains why blockchain state cannot be treated as if every node updates at the same instant. Nodes learn about transactions and blocks at different times. Consensus rules define which observations ultimately become canonical under the protocol assumptions, while signatures identify authorized actions and hashes commit to data.

The distributed-systems distinction between safety and liveness is useful. Safety asks whether bad outcomes—such as two conflicting states both being finalized—can occur. Liveness asks whether the system continues making progress. A protocol may preserve safety by refusing to finalize when communication is badly disrupted, sacrificing liveness until the network recovers.

Replication also has costs. More copies improve fault tolerance and independent verification, but increase network, storage, and coordination requirements. Blockchain design is therefore a trade-off among consistency, availability, throughput, fault tolerance, and decentralization rather than a magical removal of distributed-systems constraints.

1. Why is message passing fundamentally different from one machine reading shared memory?

2. List three failures or timing problems a distributed system must handle.

3. Distinguish safety from liveness with a blockchain example.

4. Why can two honest nodes temporarily disagree about the latest chain tip?

5. What does cryptography add to a distributed ledger that ordinary replication alone does not?

6. Correct this statement: “A blockchain avoids distributed-systems problems because every node has the same database.”