On the Hedera mainnet we are currently seeing a latency of approximately 2.5 seconds for transactions. This post will break down that 2.5 seconds.
Latency is the time from when a transaction is first sent out from one node, until a node has received it and calculated its consensus order and consensus timestamp, averaged over all nodes and all transactions. All else being equal, the shorter the latency the better, as applications submitting transactions to the public ledger will have to wait less before obtaining the necessary confidence that a given transaction has been processed into consensus and will not change.
Let’s consider the full lifecycle of a typical Hedera transaction.
A client creates a transaction and submits it to a particular Hedera node – let's call it Alice. After performing a minimal validation check of the transaction, Alice adds it to an event along with other transactions that had been sent to her by both that same client and others. Alice adds her clock’s current timestamp to the event, two hashes of previous events, and signs the new event with her private key.
The clock starts. Latency for the transaction will be measured from this point.
Alice gossips the newly created event (and the client’s transaction within) to another node Bob. Bob then gossips it to another node Carol. Alice, Bob, and Carol would continue to gossip that event in their subsequent gossip syncs with other nodes. Very quickly all nodes will have received the event – all at different times.
Although the times at which each node receives the event will be different, the gossip about gossip component of the hashgraph algorithm allows all nodes to know those different times (to be precise, to know the time at which it finished the sync in which it received the event).
To assign the new event a consensus timestamp and place in consensus order, nodes follow the virtual voting component of the hashgraph algorithm. The consensus timestamp of the event will be the median of a set of the times at which a subset of all nodes received the event. To determine which nodes are in that subset, an election is held on the ‘fame’ (a measure of the gossip activity of the node that created it) of events. But, to assign Alice’s event a timestamp, votes are cast not on the fame of Alice’s event, but rather on the fame of later events (that are descendants of Alice’s event). And the mechanism for counting up those votes requires even later events.
Consequently, to assign Alice’s event a consensus timestamp, each node must wait a sufficient amount of time after receiving that event so that they can receive the later events that will allow the timestamp to be calculated. Logically, each node maintains a list of pre-consensus events and, as subsequent events are received, the node checks to see if that each newly received event will allow a consensus timestamp to be calculated for any older events in the list. If so, the timestamp is calculated and the event is removed from the pre-consensus list.
Currently on Hedera, it takes between 2 and 3 seconds for a node to be able to collect those necessary later events that allow the fame elections to be decided.
A key implication of the above is that each node will calculate the consensus timestamp for Alice’s event at a different time – this because they inevitably received the necessary subsequent events at different times. The consensus timestamp they conclude for a given event is of course all the same, but they come to that conclusion at different times.
Critically, since hashgraph delivers finality of consensus, once a node calculates the consensus timestamp for Alice’s event (whether it is the first to do so or the last), they need not be concerned about that determination changing – it is final.
Contrast this certainty with other distributed ledgers (such as Proof of Work blockchains) that do not provide finality, and instead provide to participants only a growing confidence that a transaction will not be rolled back as additional blocks are added to the chain. In such distributed ledgers, there is always a theoretical possibility that, should a longer chain be seen – all nodes will roll back any transactions in the shorter chain that had been thought as canonical. In practice, actors choose how many subsequent blocks to wait based on their assessment of the risk.
On Hedera, one node’s assessment of the latency for Alice’s event will be (slightly) different than for others. They all agree on when the clock started as the event itself carries the time when Alice first created it. But, as each node determines the consensus timestamp at a different time (when the clock stops), each nodes’ sense of the interval between the creation and their own determination of consensus will vary.
This is represented below:
After each node has calculated a timestamp for Alice’s event via virtual voting, the transactions within that event are assigned their own timestamps simply based on their place within the event.
Once the client’s transaction has been assigned a timestamp and placed in consensus order, nodes apply it to their local copy of state. For instance, if the transaction were an HBAR transfer, all nodes would decrement the payer’s balance, and increment the recipient’s. Or, if the transaction were a smart contract call, each node would execute the function.
The original client can query for the consensus status of the transaction at that point by asking any node for either a receipt (free) or a record (not free). If they send the query too soon, for instance, 1 second after first submitting it to Alice, then the response code from the node will likely be `UNKNOWN`. At that point the node to which the query was sent may have received the transaction in question but will be unlikely to have been able to assign it a consensus timestamp as the necessary subsequent descendants will not have been collected. If the client instead waits longer before sending their query (long enough for whatever node they pick for the query to have calculated consensus) then the response code will be `SUCCESS`.
When Hedera cites 2.5 seconds or similar for latency, we mean that this value is equal to the time interval between when the event containing the transaction is initially created and subsequently assigned a consensus timestamp by another node, when averaged over other transactions and all nodes. Of course, any particular transaction will likely have a latency different than this average, some lower, some higher.
This is clear in the chart below that shows the latencies for each node over a 12 hour span.
The latency of a distributed ledger is a key metric of performance. A large latency implies applications must wait after submitting a transaction before proceeding, for instance, transferring some resource. Latency is critical for payment applications – the archetypal ‘buying a coffee’ use case is impractical if the customer must wait 10 minutes or longer for their purchase to be confirmed. Currently, with its 13 nodes distributed around the globe, Hedera delivers a latency of less than 3 seconds. Additionally, and critically, on average after this length of time, a transaction will have been assigned a consensus timestamp and placed within consensus order that will not change – that is, with finality.