Show Menu

Designing the Perfect Block Confirmation Times

There is no definitive way of choosing the optimal confirmation times for your blockchain. Developers often want longer times, while merchants and business owners often want them shorter. Both options come with their respective merits and pitfalls so ultimately it is up to the development team to decide on what they think works best, but this is far from easy.

There is a skill to choosing the perfect confirmation times. It needs to be something that satisfies users, miners (or validators), and developers. Naturally, compromises are needed, but what sort of compromises should be made?

The Argument for Short Confirmation Times

A blockchain which offers short confirmation times provides a huge number of positives for both users, merchants, and vendors. Short confirmation times mean fast transactions, making the blockchain appealing for use in physical stores and marketplaces. This is great for cryptocurrencies, but it is also helpful for private blockchains where the passing of information is time sensitive and needs to be logged as fast as possible. This could, for example, aid industries such as the law sector and the field of medical research as both require accessible data at a near instant rate.

Short confirmation times are great for miners too as it means they might not feel the financial pressure to join a mining pool. This means they can therefore reap the block rewards all for themselves. At the moment, most miners for large cryptocurrencies like Bitcoin feel forced to join mining pools simply because it takes far too long for a lone miner to find a whole block. Shorter times could eliminate this and allow for the blockchain to flourish better. This is important for DApp blockchains too as they perform more efficiently without pools. Some also argue that mining pools naturally become too powerful of a pressure-group and can leave a blockchain more open to 51% attacks.

Proof of Stake blockchains that use validators favour short confirmation times too because it means they can make more profits by validating more blocks at a time.

The Argument for Longer Confirmation Times

One huge positive of longer confirmation times is that they prevent the creation of orphan blocks. By having longer times you give the miners and validators enough time to agree upon a consensus chain, thus reducing the amount of forks which happen. This subsequently prevents double spends from happening.

This may only be one argument, but it is a huge one. Shortening confirmation times can lead to huge security flaws which make the network vulnerable. A blockchain’s immutability means that too many exploits would eventually lead it to be unstable or even untrustworthy.

Choosing the Right Confirmation Times

Let’s look at some confirmation times being used right now. On average it takes 10 minutes for one block confirmation on Bitcoin. This time was chosen by Satoshi Nakamoto as a compromise between developer demands and perceived demands of the public. The current Bitcoin developers stand by the choice of 10 minutes as they think it is necessary for security purposes. It is also quick enough to keep the blockchain flowing with new transactions.

Ethereum has a much faster confirmation time at between 10-19 seconds. This is, in part, due to the fact that miners choose the number of transactions to include into one block. Some have argued that this speed of confirmations leaves the network open to more security flaws; possibly explaining why Ethereum sees numerous updates regularly.

Litecoin confirmations are at 2 ½ minutes. This is because it has double the block size of Bitcoin, and uses Scrypt Hash rather than the SHA-256 protocol which is arguably outdated.

These three blockchains all use different confirmation times for different reasons. At the heart of them all is a desire to offer a fast service to their users, but they also fall victim to developers who require longer times for structural and security purposes. This is why no blockchain is currently as fast at handling transactions as VISA is, for example.

The best way for a private blockchain developer to find their own best confirmation time would be to look into security features first, and then choose the shortest time which does not leave the ledger open to vulnerabilities. When that has been agreed, they should use their own discretion about whether they want to lower the times. From a theoretical standpoint, a small margin of vulnerabilities is acceptable so long as the blockchain is vast enough to continue unscathed.

It is also worth noting that we are starting to see variations on the standard blockchain model, with some interesting experiments and hybrids. The Nano cryptocurrency uses a block lattice, and IOTA uses a system called the Tangle. These may be worth considering for your next cryptographic development.