The Distance Between Action and Certainty
A blockchain never exists in a single present.
In the previous articles, I explored how distributed systems evolved into blockchains [1], why and how blockchain architectures eventually became modular [2], how the access layer quietly shapes decentralization [3, 4], and how each generation of protocols inherits the constraints of the one before it [5]. Though with these discussions we approached the ecosystem from different view points, they all revolved around a common idea: blockchain architecture is about managing constraints rather than eliminating them.
One constraint, however, remained in the background and we only slightly mentioned it: time.
We usually encounter it as latency, block times, confirmation or settlement delays, and RPC response times. These metrics are often treated as isolated performance indicators, optimized independently and used to compare one blockchain with another. Yet they all describe the same underlying phenomenon. So, before asking why one blockchain is faster than another, we should first ask a more fundamental question.
Can a decentralized system ever have a single present, or is latency simply the price of many participants trying to share the same reality?
One Network, Many Presents
Raphael’s The School of Athens portrays dozens of philosophers gathered in the same hall, discussing the same ideas, yet no two figures occupy the same position. Some argue, others observe, a few teach, while several remain immersed in their own thoughts. Knowledge emerges because independent viewpoints gradually converge through dialogue.
A blockchain network behaves in a remarkably similar way: When we describe a blockchain, we usually imagine it as a single system progressing through time. A transaction is submitted, a block is produced, and everyone observes the same new state. But no one really experiences that moment simultaneously.
A validator proposing a block observes the transaction before another validator on the other side of the world.
An RPC node may already serve the updated state while an indexer is still reconstructing it.
A wallet continues displaying an old balance even though the transaction has already been finalized.
A blockchain explorer may report confirmation seconds before another explorer catches up.
Everyone interacting with the blockchain temporarily lives in a different version of the network’s present. The further information (the new state) has to travel across the nodes, the longer these differences mentioned above persist. Unlike The School of Athens, where independent perspectives eventually converge through discussion, blockchain networks converge through protocol.
Latency is the observable consequence of this reality. At that point, the challenge is not just making systems faster but understanding that decentralized systems cannot make every participant share the same present at the same moment.
Consensus Does Not Synchronize the Present
You may ask that consensus protocols are mechanisms that allow validators to agree on the state of the blockchain, so why is the present not synchronized? While you are technically correct, this description does not necessarily answer what consensus protocols accomplish.
Consensus protocols were never constructed to synchronize the present, they have been here for synchronizing the past.
When validators exchange votes, propagate blocks, or verify signatures, they are not attempting to make every participant observe events simultaneously. Such a goal is physically impossible in a globally distributed network. Instead, consensus establishes a common history after enough information has propagated throughout the system. This distinction matters because the network is always in motion while consensus takes place. Messages arrive at different times, packets follow different routes, and validators observe slightly different versions of the world for brief periods. Consensus gradually resolves these differences into a shared history that everyone can later agree upon. And this is why confirmation / settlement periods are introduced in blockchains.
In other words, a blockchain does not maintain one universal “now.” It continuously transforms many local observations into one globally accepted “then.”
The Present Moves Further Away
Even after consensus has been reached, a finalized block does not immediately become visible to users. RPC nodes update their internal state, databases process new information, indexers reconstruct events, caches refresh their contents, and applications request the latest data before a wallet finally displays an updated balance.
This difference explains why users often perceive blockchain performance very differently from protocol metrics. A network may produce blocks in milliseconds and finalize transactions fast and efficiently while applications still appear slow because the surrounding infrastructure has not yet reflected the new state.
Yet, we should not perceive it as a failure of decentralization. Every additional layer that separates users from consensus introduces another interval during which information continues to travel: this is an architectural reality. The protocol reaches certainty first, the user reaches it later.
How Do We Encounter It in Real Life?
This distinction becomes much more visible in financial systems.
Imagine an automated trading strategy reacting to a sudden price movement. The algorithm decides to buy because the latest market data indicates an opportunity. Yet, both the price update and the order itself need time to travel through the network before they become part of the system’s shared state. And by the time the transaction is executed and the rest of the network observes it, the conditions that motivated the trade may already have changed. The algorithm was reacting to the latest present it could observe.
Traditional software too experiences delay, but the architecture is fundamentally different:
A centralized trading platform maintains a single authoritative database, meaning there is only one version of reality. Participants can reduce latency simply by moving closer to that authority.
High-frequency trading firms, for example, colocate their servers inside exchange data centers because every microsecond between their systems and the exchange’s matching engine matters. The closer they are to the source of truth, the earlier they observe new information and the sooner they can react.
Blockchains deliberately reject this model. There is no single server to stand next to and no database that instantly defines reality for everyone else. Every validator must first receive the same information before agreement can emerge, and every participant waits for that agreement to propagate throughout the network. Latency therefore becomes a shared architectural constraint rather than a private competitive advantage.
Can We Eliminate Time?
Modern blockchain architecture dedicates enormous effort to reducing latency. These designs are usually referred to as real-time blockchains and some of the ways they achieve it are as follows:
Consensus algorithms reduce communication rounds.
Peer-to-peer protocols optimize block propagation.
Validators improve network connectivity.
RPC providers deploy regional infrastructure closer to applications.
Layer 2 systems execute transactions before settlement.
Indexers continuously optimize how quickly the new state becomes queryable.
Each of these improvements shortens a particular delay but none is enough to remove time itself. Even the fastest blockchain cannot escape the physical reality that information cannot exist everywhere simultaneously. Messages still traverse continents and requests travel through networks, participants still receive events in different orders. Every optimization reduces waiting somewhere while preserving the underlying relationship between distance and time. Even though through these improvements the constraint becomes smaller, it remains still.
Conclusion
Distributed systems taught us that information cannot exist everywhere at once. Blockchains inherited this limitation while removing the trusted operator capable of resolving disagreement externally. As a result, decentralized systems exchange a single universal present for something more subtle: many local presents that gradually converge into one shared history. Latency is basically the name we give to that convergence time.
Perhaps this is why blockchain architecture has never truly been about making systems faster. Every generation of protocols has attempted to shorten the interval between action and certainty, yet none has succeeded in eliminating it entirely. Time remains embedded within every consensus round, every propagated block, every RPC request, and every application waiting for the latest state.
The blockchain, then, is not a machine that moves through one shared moment but a network continuously negotiating its own present.