bLatency and finality in different cryptocurrencies

How long does it take for a transaction to be confirmed for the first time and does it ever reach an irreversible state?

During the past 9 years we’ve seen several approaches to solving the general problem of distributed ledgers. When it comes to analysing these consensus protocols, there are many metrics to consider, but in this article I will focus on two of them:

• Latency — the time it takes from the creation of a transaction until the initial confirmation of it being accepted by the network (and how the confidence of acceptance increases over time);
• Finality —the property that once a transaction is completed, there is no way to revert it (or alter it). Basically, it’s the moment when the parties involved in the transfer can consider the deal done. Finality can be deterministic or probabilistic.

Having low latency is crucial when designing a real life payments system. You don’t really want to wait 10 minutes when you’re buying that Starbucks coffee using crypto. For small payments, merchants would probably accept a payment the moment the transaction is initially confirmed, provided that they have a reasonably high confidence the payment will be accepted eventually.

However, for large money transfers, the receiver of the funds would probably want to wait for the transaction to become irreversible. Or at least, enough time should pass until a probabilistic finality is reached.

In the financial industry, institutions need to know, preferably as quickly as possible, whether they truly own certain assets. If a public distributed ledger technology (DLT) is used to store the ownership information, the institutions also need to be sure it will not be possible to revert a certain transaction, making them lose the ownership rights.

Next, I will present some of the most popular consensus protocols, analyse their latency, and check if they reach finality and how this affects their security.

Bitcoin

The Bitcoin protocol is designed such that a new block is added roughly every 10 minutes. When a new transaction is created, there’s no way to confirm it until it is included in a block. So Bitcoin’s latency is quite huge and even withdrawing money from a Bitcoin ATM is a time consuming process for the end user.

Regarding finality, it may sound surprising, but most blockchain based protocols (including Bitcoin) do not have a deterministic finality. For any given block, there is a theoretical possibility that a longer chain that starts before that block will be propagated through the network. As the protocol dictates that nodes should always accept the longest chain as being the valid one, it means all the blocks from the initial chain that are not part of the second, longer chain, will be discarded.

In practice though, there is a very simple way of probabilistically considering a transaction to be final: just wait for 6 confirmation blocks. It’s interesting to see what’s the logic behind this number.

Let’s assume we have an attacker that controls a third of the total mining power. This assumption is quite realistic if we take a look at the current mining pools, where we can see that we have a pool controlling almost 30% of the hashing power almost constantly. If the attacker wants to target a certain transaction, the moment that particular transaction is created, the attacker starts to mine an alternative chain.

I ran the code presented in the end of the Bitcoin white paper and written by Satoshi himself. I got the following results regarding the probability of a transaction not being reversed by the attacker:

• ~30.3% after waiting for 1 confirmation block
• ~77.6% after waiting for 6 confirmation blocks
• ~90.2% after waiting for 10 confirmation blocks
• ~99.99% after waiting for 45 confirmation blocks

Considering the widespread belief that 6 confirmation blocks are enough to consider a transaction final, here are a few numbers that show the security level according to the percentage of hash power controlled by the attacker, once the 6 confirmation blocks are added to the honest chain:

• ~99.99% if the attacker controls 8% of the hashing power
• ~95% if the attacker controls 25% of the hashing power
• ~78.68% if the attacker controls 33% of the hashing power
• ~49.6% if the attacker controls 40% of the hashing power
• ~4.06% if the attacker controls 49% of the hashing power

As you can see from the two charts above, the probability approaches 1 as more confirmation blocks are added to the chain, and the rate increases as the honest parties control more of the network’s hashing power. Transacting parties can choose their own number of confirmation blocks in order to feel comfortable the transaction will never get reverted, but the common value accepted by most is 6 (approx. 1 hour of waiting time).

Stellar

In blockchain based protocols, transactions enter a pool and when a miner manages to solve the hashing puzzle it gets to choose which transactions are going to be accepted by the network in the next block.

Instead of having a pool of unconfirmed transactions, in the Stellar protocol the nodes of the network vote for each transaction independently. Of course, having each node communicate with every other single node whenever a transaction happens doesn’t really scale.

In order to address potential scalability issues, Stellar allows every node to select subsets of other nodes that it trusts, and consult only those about a new transaction. As long as there is enough trust in the network, consensus will be reached and votes will be final.

Latency and finality happen simultaneously, but the protocol’s reliance on trust means they are actually solving a different, weaker problem than Bitcoin. And their network currently has only ~30 nodes, so scalability is still an issue to be proved in the future, when the network grows. Right now, a vote takes around 5 seconds.

IOTA

IOTA was one of the first projects to challenge the entire idea of blockchain, by coming up with the Tangle — their own distributed ledger technology.

IOTA’s Tangle is a Directed Acyclic Graph (DAG)

The promises of their project are:

• Scalability: it should be able to achieve high transaction throughput thanks to parallelised validation of transactions
• Decentralisation: it has no miners, instead every transaction is used to confirm and validate two of the previous transactions.
• No transaction fees: instead IOTA requires some light proof-of-work for each transaction

The way the protocol is designed, there is no actual finality, but a transaction becomes increasingly more confirmed as other transactions are created on top of it. So somewhat similar to blockchain, as time passes the probability of a transaction being rejected decreases.

The big issue surrounding the IOTA project and their Tangle is that they actually rely on a single node owned by their foundation called the “Coordinator”. The need for the Coordinator comes from the fact that it’s pretty easy for an attacker to gain more than a third of the total hashing power.

The team claims this is in no way centralised, but I beg to differ. If there is just one step with a single point of failure, then the system is not decentralised, even though all the other steps of the protocol are. IOTA currently works only if the Coordinator is trusted by all the other nodes in the network.

Nano (formerly RaiBlocks)

Nano is another interesting project that uses a new approach to maintain a distributed ledger — they call it a block-lattice.

Basically, each account has its own chain that maintains an ordered list of transactions that were applied on that particular account.

A transfer of money involves the creation of two transactions: one for the sender’s account and another one for the receiver’s account. The transfer is completed only when both transactions are acknowledged and accepted by the network.

Because there is no explicit voting for a transaction, Nano doesn’t have any kind of finality system in place. Whenever a double spend is detected, a voting procedure is initiated. There’s nothing stopping the network to modify account chains any time using their voting power, so you may lose your money weeks after the transfer was initiated.

There are several other security issues with the Nano protocol (some of them are even mentioned in their white paper), but for the scope of this article, I just wanted to focus on their lack of finality. Unlike Bitcoin or IOTA, the passage of time doesn’t guarantee the irreversibility of a transaction, making it one of the weakest protocols when it comes to finality.

Blink

At Blink, we tried to learn from all the other protocols’ weak points and came up with our own consensus protocol that is highly scalable and has low latency, while staying decentralised and secure.

One of the main underlying ideas of the protocol is that transactions that are independent can be applied independently on the ledger. Each account has a supervisor node called the locker, responsible for maintaining an order of transactions for that account.

Initially, only two lockers (for the two affected accounts) accept and sign the transaction. So the initial confirmation of a transaction comes after 300–600 milliseconds. Having high throughput (our current prototype supports 20 000 transactions per second) means transaction fees will be low — probably equal to 0 if the maximum throughput is not reached.

Low latency, coupled with low fees, enables real life payments and micro transactions.

After a transaction is initially signed by two nodes, it is gossiped through the network as the nodes sync up. The more time passes, the higher the percentage of nodes that receive and apply a past transaction. After a certain amount of time, the network votes on the entire state some time in the past. A transaction that managed to reach a majority of the nodes will be included in the vote, thus reaching finality. In our current prototype implementation this happens in less than 5 seconds.

Thanks for taking the time to read this article. If you are interested in our work at Blink, check out our official Medium page, where you can find more posts about the inner workings of our protocol.