LibraryConsensus1978Design paperCorpus record
Time, Clocks, and the Ordering of Events in a Distributed System
Lamport clocks. Leslie Lamport.
Lamport clocks number events so that if A happened before B, A's number is smaller. The converse is not true. That one direction is the whole idea.
A reading of the public paper. Not a copy, not a benchmark, and not a claim about any later network.
A protocol that says 'we timestamp it' should say whether the timestamp respects happened-before or only records a wall clock.
The five-minute read
The defect
A distributed system has no shared clock. 'Happened before' still has to be a partial order if you want to talk about causality.
The proposal
Lamport clocks number events so that if A happened before B, A's number is smaller. The converse is not true. That one direction is the whole idea.
The relation is potential causality, not wall time.
A total order can be built by breaking ties with process identities.
The bound
Equal numbers do not mean the events were concurrent. The converse failure is the point.
One action, walked through
- Each process increments a counter on its own events.
- On a message, the receiver jumps ahead of the timestamp it received.
- Comparing numbers respects sends-before-receives.
- Can two events have the same number?
The argument, unpacked
What the paper is for
A protocol that says 'we timestamp it' should say whether the timestamp respects happened-before or only records a wall clock.
What happened after
Vector clocks, consensus logs and every chain's notion of causal history sit downstream of this paper.
What has to be true
- Equal numbers do not mean the events were concurrent. The converse failure is the point.
- The paper does not elect a leader.
- Physical clock synchronisation in the second half is a different construction.
What happened after the paper
Vector clocks, consensus logs and every chain's notion of causal history sit downstream of this paper.
What to check before you use the idea
- Does the clock respect send before receive?
- Can two events have the same number?
- Is a total order required, or is the partial order enough?
Terms
- Happened-before
- The partial order of events that could have influenced each other.
- Logical clock
- A counter that tracks that order, not a wristwatch.
The problem the paper names
A distributed system has no shared clock. 'Happened before' still has to be a partial order if you want to talk about causality.
What the design proposes
- The relation is potential causality, not wall time.
- A total order can be built by breaking ties with process identities.
- The paper is not a consensus protocol. It is the language consensus uses.
How the mechanism is specified
- Each process increments a counter on its own events.
- On a message, the receiver jumps ahead of the timestamp it received.
- Comparing numbers respects sends-before-receives.
What this page does not treat as proven
- Equal numbers do not mean the events were concurrent. The converse failure is the point.
- The paper does not elect a leader.
- Physical clock synchronisation in the second half is a different construction.
Why a venture studio still reads it
A protocol that says 'we timestamp it' should say whether the timestamp respects happened-before or only records a wall clock.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.