X-Confirmation

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

Wait for a sufficient number of blocks as confirmations to ensure that a transaction added into blockchain is immutable with high probability.

Context

Due to forking, the immutability of a blockchain using Nakamoto consensus is probabilistic. Due to the longest chain wins rule of the Nakamoto consensus, the current longest chain of blocks could be overtaken by another branch of blocks with non-zero probability. Then the transactions included in the current chain of blocks is no longer considered valid. Hence, there is always a chance that the most recent blocks are replaced by a competing chain fork. The transactions that were included in those blocks are discarded and eventually go back to the transaction pool and are considered for inclusion in a later block.

Problem

When a fork occurs, it is uncertain as to which branch will be permanently kept in the blockchain and which branch(es) will be discarded. Therefore, the inclusion of a transaction in a block is insufficient to declare it as confirmed (or durable in terms of ACID properties). How can we ensure that a transaction is permanently included in a block?

Forces

  • Forking – Soft forks may occur on blockchains like Bitcoin and Ethereum which are based on Nakamoto consensus.
  • Frequency of forks – Transaction handling and inter-block time differs significantly from one blockchain platform to another. A shorter inter-block time would lead to an increased frequency of soft forks.

Solution

While the immutability of a blockchain using Nakamoto consensus is probabilistic, the probability rapidly increases as the chain of blocks grow (please refer to Bitcoin whitepaper for proof). Therefore, once a transaction is included in a block, we could wait for subsequent blocks to be built along the same chain of blocks. If the chain of blocks containing the block with our transaction grows sufficiently long, it is safe to assume that the transaction is included in the longest chain with very high probability. Therefore, we could adopt a strategy where we wait for a certain number of blocks x to be generated after the transaction is included in a block. After x blocks, we can consider the transaction to be committed and thus perceived as immutable. In case the block containing the transaction is no longer in the longest chain while we wait for x blocks, the process needs to restart. That is, we have to wait till the transaction gets included in another block, and then start counting for another x blocks.

X-confirmation pattern

The value of x can be decided by the developers of blockchain-based applications. However, it should be decided based on the latency and immutability tradeoff. For example, in Bitcoin typically 6-block conformation is assumed which results in about one hour of latency given 10-min inter-block time. Whereas in Ethereum 10-12 block confirmation is assumed which is about 2.5 to 3 minutes given 15 – 17 sec inter-block time.

Benefits

  • Immutability – Higher values of x (i.e., more blocks generated after including the transaction in a block) results in higher probability of immutability of the transaction.

Drawbacks

  • Latency – The latency between the submission and confirmation of a transaction once included on a blockchain is affected by the consensus protocol and x value. The larger value of the x, the longer the latency.

Related Patterns

N/A

Known uses

  • In Bitcoin typically 6-confirmation is used. The value 6 was chosen based on the assumption that an attacker is unlikely to amass more than 10% of the total amount of computing power within the Bitcoin network (measured by hash rate) such that a negligible risk of less than 0.1% is acceptable
  • Ethereum recommends waiting for 10 confirmations after block inclusion before assuming that a transaction is committed permanently with high probability.