# The Mystery Behind Block Time. Block time defines the time it takes to… | by Prabath Siriwardena | FACILELOGIN

Block time defines the time it takes to mine a block. Both in bitcoin blockchain and ethereum blockchain, there is an expected block time, and an average block time. In bitcoin, the expected block time is 10 minutes, while in ethereum it is between 10 to 19 seconds. Both bitcoin and ethereum, at the time of this writing use a proof of work based distributed consensus algorithm (ethereum is planned to move to a proof of stake based algorithm with its **serenity** release). The expected block time is set at a constant value to make sure, miners cannot impact the security of the network by adding more computational power. The average block time of the network is evaluated after **n** number of blocks, and if it is greater than the expected block time, then the difficulty level of the proof of work algorithm will be reduced, and if it is less than the expected block time then the difficulty level will be increased. That’s the core design principle behind block time, but you will see as we proceed, how bitcoin and ethereum differentiate themselves from each other.

Table of Contents

## Level of Difficulty (Bitcoin)

The level of difficulty varies with the time, as per the following formula. It tries to evaluate the speed of the mining network and find out how much it deviates from the expected level. The expectation is to mine a block in 10 minutes. For example, if the average speed of mining the last 2016 blocks is 8 minutes — then the new difficulty factor will be greater than one, so the current difficulty level will be increased. In case — the average is above 10 minutes, then the factor will be less than 1 and the difficulty level will be decreased for the next 2016 blocks. The difficulty level is reevaluated after every 2016 blocks, that’s roughly after every 2 weeks.

**new_difficulty = old_difficulty X (2016 blocks X 10 minutes) / (the time took in minutes to mine the last 2016 blocks)**

The following figure shows how the difficulty level changed with the time from the inception of bitcoin. In other words, the difficulty level reflects how difficult the proof of work calculation with respect to the difficulty value set at the beginning — which is 1. For example, the current difficulty is 678,760,110,083 — which means if we mine the blocks at the same hash rate, which was at the time of the 1st block, then it would take more than 678 billion times to mine a block with the current difficulty. But in practice, since the computational power thrown into the bitcoin mining improved vastly, the time takes to mine a block is kept at a constant number (which is 10minutes), by increasing the level of difficulty. During the first five years of bitcoin, the difficulty level increased from 1 to 50 billion.

In each block, in the header there is a parameter called, **bits** — and in the genesis block the value of bits is **486604799**. If we represent the same in hexadecimal it would be 1D00FFFF. This is a compact format — which can be used to find the **target** hash value for this (current) block. In fact the hash of this block must be less than or equal to the target. The value of the **target** is calculated only after 2016 blocks, along with the difficulty level calculation — and once calculated the next 2016 blocks will cary the same value in its **bits** block header parameter.

**target = coefficient * 2^(8 * (exponent — 3))**

The first two digits of the above hexadecimal value is known as the **exponent**, which is 1D and the next six digits (00FFFF) are known as the **coefficient**. Now if we apply these value to above function, it will look like the following.

target = 00FFFF * 2^(8 * (1D — 3))target = 00FFFF * 2 ^ (8*1A)target = 00FFFF * 2 ^ D0

Now if we do the hexadecimal arithmetic for the above, we’ll find the value of **target** in hexadecimal. Converted that into decimal would be **2.69 * 10 ^ 67** — and in binary it would be.

11111111011011100100011100011000111100100100000001111110111000011001010100001010011011001110000000110010001011100111110010100011010110010001100111001000100000100000000000000000000000000000000000000000000000000000000000000000

To make it much clear — since the hash of the block must be in 256 bits — lets also represent the target in 256 bit by adding leading zeros.

0000000000000000000000000000000011111111011011100100011100011000111100100100000001111110111000011001010100001010011011001110000000110010001011100111110010100011010110010001100111001000100000100000000000000000000000000000000000000000000000000000000000000000

Now the hash of the genesis block must be less than or equal to the above, which is:

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001100111010110011010001001110000001000010110101111101001001010001011010100000000000000

As we explained before, the difficulty of the genesis block is 1. After every 2016 blocks, the target is recalculated in the following way.

**new_target = old_target / new_difficulty**, where the **old_target** is shown above (which is from the genesis block, in this case).

The difficulty is calculated in the following way:

**new_difficulty = old_difficulty X (2016 blocks X 10 minutes) / (the time took in minutes to mine the last 2016 blocks)**

For example, the new level of difficulty for the 2017th block is calculated in the following manner:

Let’s assume the average block time over the first 2016 blocks is 8 minutes. This is just an assumption — in reality the level of difficulty of the bitcoin blockchain remained same till the 32255th block — and only changed from 1 to 1.18 in 32256 (2016 X 16) block.

**new_difficulty = 1 X (2016 X 10 ) / (8*2016) = 1.25**The new target = (2.69 * 10 ^ 67) / 1.25 = 2.15 * 10 ^ 6711001100001001111001101011011000111011110100110100111110011001000101101110000101111101000000101110110010000110011011110000011111100101010100000001100010011001100000000000000000000000000000000000000000000000000000000000000000

Now, if we add leading zeros to make the above 256 number, then the target will be:

0000000000000000000000000000000011001100001001111001101011011000111011110100110100111110011001000101101110000101111101000000101110110010000110011011110000011111100101010100000001100010011001100000000000000000000000000000000000000000000000000000000000000000

The new target is less than the previous one — so the mining software has to find a nonce value, which makes the hash of the block less than or equal to the above. When the computational power increases, the average block time decreases — and then the difficulty level increases by having a low target value. The next 2016 blocks will carry in the block header, the value of the new target as the **bits** parameter — and the value of the new difficulty level as the **difficulty** parameter.

The manner in which the difficulty level increases and how it’s calculated are written into the mining software itself. If one miner wants to cheat the system by changing the rules in his/her own copy, of course he can do it. But that will make him/her isolated. Once you cheat and then send the copy of the mined block to others, other legitimate miners who validate the block will find its not done properly and reject it. The miner who cheats then will automatically fall into his own copy of the blockchain.

## Level of Difficulty (Ethereum)

In ethereum, **homestead** release, the level of difficulty is calculated in the following way — where** //** denotes integer division and **2**** denotes the two to the power. The **int** function returns the largest integer less than or equal to a given number.

**block_time=current_block_timestamp — parent_block_timestamp****current_block_difficulty = parent_block_difficulty +** **(parent_block_difficulty // 2048) * max(1 — (block_time// 10), -99) **+ **int(2**((current_block_number // 100000) — 2))**

If you look at the above formula, it has two main parts. The first part to determine how much the block time deviates from the expected block time ( 10 to 19 seconds). This will find a factor of the **parent_block_difficulty**, based on how much time it took to mine the current block. If current block is mined faster, in less than 10 seconds, then this factor will be positive number, which will increase the difficulty. If the block time is between 10 and 19 seconds (inclusive) then there won’t be any changes to the difficulty. It will result in a minus value when the block time is greater than or equal to 20 seconds, and the difficulty will be decreased (but still will have the impact of the difficulty bomb, which we will talk later).

Let’s look into each of the above cases in detail, and see how the above formula will get reduced.

If the block_time is less than 10 seconds, then the above equation will be reduced to (e.g: block_time// 10 → 8//10 → 0):

current_block_difficulty = parent_block_difficulty + (parent_block_difficulty // 2048) * max(1 – **0**, -99**) **+ int**(**2**((current_block_number // 100000) — 2)**)****current_block_difficulty = parent_block_difficulty + (parent_block_difficulty // 2048) *1 + int(2**((current_block_number // 100000) — 2))**

If the block_time is between 10 and 19 seconds, then the above equation will be reduced to (e.g: block_time// 10 → 12//10 → 1):

current_block_difficulty = parent_block_difficulty + (parent_block_difficulty // 2048) * max(1- **1**, -99**) **+ int**(**2**((current_block_number // 100000) — 2))**current_block_difficulty = parent_block_difficulty + int(2**((current_block_number // 100000) — 2))**

If the block_time is greater than or equal to 20 seconds, then the above equation will be reduced to (assuming it is less than 30 seconds, e.g: block_time// 10 → 22//10 → 2):

current_block_difficulty = parent_block_difficulty + (parent_block_difficulty // 2048) * max(1 — **2**, -99**) **+ int**(**2**((current_block_number // 100000) — 2))**current_block_difficulty = parent_block_difficulty — (parent_block_difficulty // 2048) + int(2**((current_block_number // 100000) — 2))**

The maximum downward value happens in this case, when the block_time is equal to or greater than 1000 second, which is (e.g: block_time// 10 → 1000//10 → 100):

current_block_difficulty = parent_block_difficulty + (parent_block_difficulty // 2048) * max(1-**100**, -99**) **+ int**(**2**((current_block_number // 100000) — 2))**current_block_difficulty = parent_block_difficulty — 99*(parent_block_difficulty // 2048) + int(2**((current_block_number // 100000) — 2))**

The second part of the above formula is known as the **difficulty bomb**.

**int(2**((current_block_number // 100000) — 2))**

When the **current_block_number** is less than 100000 the value of the above will be **int(2**(0 — 2)) or int(2**-2) or int (1/4) **which is 0— so there won’t be any impact on the difficulty level. When the current_block_number is less than 200000 but greater than 100000, the value of the above will be **int(2**-2) or or int (1/2) **which is again 0 — so no impact. This will only impact if the block number is greater than 200000. Let’s say the block number is greater than 200000 but less than 300000, then **current_block_number // 100000 — **will be 2 — so the value of the above will be **int(2**0) or int (1) **which is 1. So, the total difficulty will be.

**current_block_difficulty = parent_block_difficulty + (parent_block_difficulty // 2048) *1 + 1.**

For the current block number at the time of this writing, which is 4356873, this second factor is, **int(2**41), **which is 2199023255552, where **(4356873 // 100000-2) → (43-2) →41**.

Note: Frontier, the initial release of the ethereum, pushed live in July 2015, was targeting to keep the ethereum block time around 12 seconds.The above discussion is related to thehomesteadethereum release — not thefrontier. Following shows the difficulty calculation used infrontier.current_block_difficulty = parent_block_difficulty + (parent_block_difficulty // 2048) * (1 if current_block_timestamp — parent_block_timestamp < 13 else -1) + int(2**((block.number // 100000) — 2))

The main difference between bitcoin’s level of difficulty and the ethereum’s is, in bitcoin, the difficulty adjustment is done after 2016 blocks to maintain the block time at a constant value (even though the computational power increases), but in ethereum, based on the computational power, the block time will increase (or decrease) due to the difficulty bomb impact (not trying to keep it at a constant value) — and the adjustment is done in each block. So, to keep ethereum block time at a considerable level, the computational power also must increase with the time (to match the difficulty bomb) — if not, it will be hard to mine ethereum, which will result in a ethereum blockchain freeze — also known as **ice age**.

## The Ethereum Difficulty Bomb

The ethereum difficulty bomb, which makes mining harder with an exponentially increasing difficulty level over the time was introduced to discourage the miners to continue mining with proof of work mining, when the ethereum **serenity** release in the future introduces proof of stake mining. The difficulty level was introduced with the first patch to the ethereum **frontier**. Frontier was the initial release of ethereum, pushed live in July 2015.

As we discussed in the previous section, following is the change (**bold**) introduced to ethereum difficulty algorithm to support the difficulty bomb:

current_block_difficulty = parent_block_difficulty + (parent_block_difficulty // 2048) *1** + int(2**((current_block_number // 100000) — 2))**

Note that, the above algorithm is based on the ethereum

homesteadrelease, not from thefrontierrelease, where the difficulty bomb was introduced. Anyway, between these two releases, even though the difficulty algorithm got changed, there was no change to the difficulty bomb part.

With the changes to the ethereum difficulty algorithm to support the difficulty bomb, starting from block 200,000 (around Sept, 2015), the difficulty increased exponentially, but only became noticeable in about a year later. At that point onwards there is a significant increase in difficulty which started pushing the block resolution time upwards. As we go on like this, due to the harder mining targets the network will continue to be useful for roughly few months, but eventually will reach an **ice age, **wherethe difficulty will simply be too high for anyone to find a block. The plan was to introduce proof of stake at that point with the ethereum **serenity** release.

As the plans for the **serenity** release got delayed, there is a hard fork expecting with the **byzantium** release (still with proof of work), in the ethereum network, in couple of days time between 12:00 UTC and 13:00 UTC on Monday, October 16, 2017, at the block number 4,370,000. Byzantium is part of the **metropolis** ethereum development phase that includes two hard forks: **byzantium** and **constantinople**. Constantinople does not currently have a release date, but is expected in 2018. With the EIP 649 proposal, which includes in **byzantium, **the ethereum difficulty bomb is further delayed. Now, the average block time is 17.49 seconds and slowly increasing due to the difficulty bomb. That makes users/miners discouraged. This EIP (Ethereum Improvement Proposal) is suggesting to delay the difficulty bomb significantly, to reduce the average block time below 15 seconds, and to allow more time for **serenity** development.

## Why Bitcoin Block Time Is 10 Minutes ?

Bitcoin tries to maintain its block time to be around 10 minutes with its difficulty algorithm. Why it is 10 minutes? Why not 2 or 20 minutes? The very first reference of having 10 minutes as the bitcoin block time comes from the original research paper, which introduced bitcoin in 2008, by Satoshi Nakamoto. It has only one reference, and 10 minutes is not a concrete suggestion, but takes as an example.

A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore’s Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

Let’s say block time is 2 minutes — and the average network latency to reach that block to other miners in the bitcoin network is 1 minute (this is just an example, in practice it’s quite less than this). This value of latency is independent of the block time. All the miners in the network mine simultaneously and independently. Let’s say everyone is mining the 3500th block (assume all start mining at time **t0**) — and the miner **tom** solves the puzzle first and broadcasts the block to the rest of the miners at time** t0 + t, **where** t** is the time taken by **tom** to mine the 3500th block. Now **peter**, another average miner finds **tom’s** block at (**t0 + t)+ 1, **due to the network latency of 1 minute. Peter and every other miner, who complete mining the same block with **(delta_t)i **times lagging, where ; (**t0 + t)< (t0 +t) + (delta_t)i < **(**t0 + t) + 1 **or can be reduced to **0< (delta_t)i< 1, **succeed in solving the puzzle, but waste all their energy — and all those blocks will be orphan blocks with no mining rewards. The total wastage of hashes in the complete network due to the orphan blocks would be:

**sum of { (t+ (delta_t)i ) * (hr)i } for every i**

where **(delta_t)i** is the additional time from **t,** the miner **i**th took before noticing the block mined by **tom — **and **(hr)i** is the number of hashes per minute the **i**th miner generates.

If we increase, the difficulty by **p%**, then both **t** and **(delta_t)i** will increase in, let’s say the same **p1%**. Since this makes **(delta_t)i** increases, the number of miners who complete mining where **(t0 +t) + (delta_t)i < **(**t0 + t) + 1 **will go down. So, in the above function of wastage, the number of **i**s will go down — so the wastage. Let’s go through few examples with concrete values.

- If the value of
**t**is 2 minutes, and then every miner who completes mining a block before 3 minutes time period (with 1 minute network latency) will only contribute to the waste (except the miner who finishes very first and gets the reward). Here you can see, there is a 50% of time gap where a miner can fall into this time period. [ 50% = (3-2)/2 * 100] - If the value of
**t**is 4 minutes, and then every miner who completes mining a block before 5 minutes time period (with 1 minute network latency) will only contribute to the waste. Here you can see, there is a 25% of time gap where a miner can fall into this time period. [ 25% = (5-4)/4 * 100] - If the value of
**t**is 8 minutes, and then every miner who completes mining a block before 9 minutes time period (with 1 minute network latency) will only contribute to the waste. Here you can see, there is a 12.5% of time gap where a miner can fall into this time period. [ 12.5% = (9-8)/8 * 100] - If the value of
**t**is 10 minutes, and then every miner who completes mining a block before 11 minutes time period (with 1 minute network latency) will only contribute to the waste. Here you can see, there is a 10% of time gap where a miner can fall into this time period. [ 10% = (11-10)/10 * 100]

Now you can see, as the block time increases, the percentage of wastage goes down. Considering all the other factors, Satoshi Nakamoto thinks the wastage at the 10minutes block time is acceptable. Along with the wastage, if multiple nodes start generating the same block simultaneously or within a short period of time, this will lead into multiple and more frequent bitcoin forks. Frequent folks, will make the bitcoin network less healthy, and the transaction confirmation time will increase, as everyone has to wait till the bitcoin network becomes eventually consistent.

**Note**: In the above calculation 1 minute of network latency was taken just as an example to make the math easier. A 2013 paper by Decker and Wattenhofer in Zurich measures bitcoin network latency, and determines that 12.6 seconds is the time it takes for a new block to propagate to 95% of nodes.

## Why Ethereum’s Block Time Drastically Less Than Bitcoin’s ?

Ethereum’s average block time at the time of this writing is around 17 seconds. If the the story we built in the previous section is true, how would ethereum reduce the wastage with such a low block time — and also reduce the chance of multiple, frequent forks. This is solved by the modified version of the **Greedy Heaviest Observed Subtree (GHOST) **protocol followed by ethereum. The GHOST is an innovation first introduced by Yonatan Sompolinsky and Aviv Zohar in December 2013, and is the first serious attempt at solving the issues preventing much faster block times.

As discussed in the previous section, the main challenge in shorter block time is, there will more miners producing the same block, and end up with no economic incentives — and waste a lot of computational power with no impact towards the stability of the network. Further, this will result in more frequent forks. When a fork happens, the network proceeds by finding the longest blockchain and every miner will switch to it. GHOST solves this problem by including these stale/orphan blocks in the calculation of finding which chain is the longest chain — and also rewarding them. In ethereum these blocks are known as **uncle** blocks. An uncle block receives some percentage of the normal block reward — so the computational power spent on mining the stale blocks are not wasted with no economic incentives. Then the question is, why it is not 1 second?

Ethereum picks the block time be between 10 to 19 seconds because that is as fast as possible, but is at the same time substantially longer than network latency. A 2013 paper by Decker and Wattenhofer in Zurich measures bitcoin network latency, and determines that 12.6 seconds is the time it takes for a new block to propagate to 95% of nodes; however, the paper also points out that the bulk of the propagation time is proportional to block size.

Another reason is, in ethereum not all uncle blocks are rewarded — and the block time should not encourage more uncle blocks than what can be rewarded. One block can include up to two uncles. If a block references two uncles, each uncle will earn 7/8th of 5 ETH to whoever mined that uncle. Each uncle being referenced will also earn a small reward per uncle (1/32 of 5 ETH) to the miner who references the uncles in his / her block. As you can see in the way referencing works, it can go to an unlimited number of levels — one block refers two uncle blocks — and one of those uncle blocks refers another two uncle blocks — and one of those uncle blocks refers another two uncle blocks, like wise. In ethereum, a stale block can only be included as an uncle by up to the seventh-generation descendant of one of its direct siblings, and not any block with a more distant relation. This was done for several reasons [ref].

- Unlimited GHOST would include too many complications into the calculation of which uncles for a given block are valid.
- Unlimited uncle incentivization as used in ethereum removes the incentive for a miner to mine on the main chain and not the chain of a public attacker.
- Calculations show that restricting to seven levels provides most of the desired effect without many of the negative consequences.

## Summary

Block time defines the time it takes to mine a block. Both in bitcoin blockchain and ethereum blockchain, there is an expected block time, and an average block time. In bitcoin, the expected block time is 10 minutes, while in ethereum it is between 10 to 20 seconds. The block time is adjusted based on the level of difficulty. The main difference between bitcoin’s level of difficulty and the ethereum’s is, in bitcoin, the difficulty adjustment is done after 2016 blocks to maintain the block time at a constant value (even though the computational power increases), but in ethereum, based on the computational power, the block time will increase (or decrease) due to the difficulty bomb (not trying to keep it at a constant value) — and the adjustment is done in each block.