Analysis of Blockchain AvailabilityBased on Block Lag

Screenshot 2023-05-17 174356

By Aleksey Studnev,, 16 May, 2023

This analysis focuses on examining the on-chain block lag of four blockchain networks: Bitcoin, Ethereum, Solana, and Binance Smart Chain. The aim is to calculate various statistics related to the block time.

To conduct this analysis, data sets were obtained and processed using Pandas tools within a Jupyter Notebook environment. The resulting findings and insights are documented in a GitHub project. By exploring the block lag statistics, we can gain a better understanding of the performance and efficiency of these blockchain networks.

Why Block Lags Matter?

The goal for this analysis is to measure how well blockhain networks of different kind meet client expectations on availability and speed. This is not just defined by the mean statistics, as average block time and transactions per second. The distribution of these parameters is also important, and especially the corner cases of unexpectedly long lags in block times.

When the blockchain network does not add the new block for a long time, all applications that are elying on that network, efffectively stalled. It is equivallent to the program hangs on your computer. Blockchain clients, as wallets or DApps, can not execute transactions, make transfers or smart contract calls.

Too long time lag between the blocks is equivalent to the service outage of the blockchain network. Here we tried to measure how often this happens and how severe it is in different blockchains.

Here we consider outage when the next block does not appear in 10x time interval from the average block period. For example, if average period in Ethereum is 14 seconds, we consider 140 seconds as outage. This is calculated relative to the average values, because the expectations of the clients ( both humans and applications ) are adapted to the average block times, which are very different across blockchain networks


Aggregated Statistics on Block Times

Here is the agregated statistics of the 4 blockchain networks under consideration:

Ethereum can be divided into two periods: before the Proof of Stake (POS) fork and after it, as statistics show notable differences.The table clearly indicates that the maximum time can greatly surpass the average figures, sometimes even extending to hours or even days. We will now examine each chain individually and then return to analyze the SLA figures as a whole.

Ethereum Before POS

The distribution of the block time in Ethereum Before POS ( logarithmic frequency scale ):


The hystogram in logarithmic scale looks very smooth and has almost linear slope for a range of 10..120 seconds per block.
It can be approximately modeled as of exponential decay:

Freq ~ A * exp ( -t * B )

Proof of work requires the guessing of crypto puzzle, which is a random guessing, which must follow the Binomial distribution. We see here the trail of this distribution with t >> average(t), average is approximately 14 seconds.

It means, that any POW consensys by-design assumes the outages, when the block time due to probabalistic reasons exceed some pre-defined value.

On this diagram, the 140 seconds ( 14 sec avg x 10 factor) lies in the middle, showing quite a lot of blocks, which took more time than that to mine.


There are also several blocks with the lag exceeding 300 sec

ethereum[(ethereum[‘lag’]>300) & (ethereum[‘block’]<15537393)]


gives us the blocks with extreme block times:


Good news, that all of them well in the past!

Ethereum After POS

The distribution of the block time in Ethereum After POS ( logarithmic frequency scale ):


Here we see very discrete histogram, with block times of multiples of 6 and 12 seconds. The maximum time is 96 = 12 * 8, minimum is 6 seconds.


The distribution of the block time in Bitcoin ( logarithmic frequency scale ):


Bitcoin and Ethereum both employ Proof of Work (PoW) for block mining, which contributes to their similar trends towards larger values. Notably, there is a noteworthy negative range of block times. This arises from utilizing the block mining time as a timestamp, rather than the actual time when the block was added to the blockchain. In practice, mining times can be established well before the block’s inclusion in the chain, resulting in a considerable number of blocks with negative time lags.

However, these negative lags should not significantly impact the measurement of block lags in the positive range. This is because their distribution declines much more rapidly than that of positive lags. Among the blocks, there are 151 instances where mining took more than 2 hours, with some taking more than 10 hours.


Note that these are all at the very beginning of the network… good times!

Binance Smart Chain

The distribution of the block time in Binance Smart Chain ( logarithmic frequency scale ):


BSC distribution falls pretty fast, and there are no much extremely long block times here.


The distribution of the block time in Solana ( logarithmic frequency scale ):


Solana is famous for the very fast block times… and long outages! These are blocks that took over 10 minutes:


And you see, they are sometimes close to the whole day (!) when the network effectively stalled.

Aggregated Availability Figures

The aggregated figures from the distributions are collected in the following table:


Binance Smart Chain and Ethereum, particularly after the introduction of Proof of Stake (PoS), are highly favored for their exceptional availability, approaching nearly 100%. This level of availability ensures a high degree of predictability in application performance.

On the other hand, Solana, while being one of the fastest networks, exhibits slightly lower availability at 97%. This level of availability is considered inadequate, even for centralized non-redundant systems such as a single-server website.

Data Sets

The data for inter-block lags in seconds versus the block number are quieried from Bitquery datasets for 4 blockchains.

They are available in S3 public :

Binance Smart Chain

 Ethereum Mainnet 


Solana Mainnnet

Jupyter Notebook

Jupyter notebook is in the github project. To run the code, you will need standard Jupyter labs installation, and download the datasets in data folder inside the prject
After that run
% jupyter-lab
and load notebook BlockhainTimes.ipynb
Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

The Ultimate Guide to NFT Analytics

Bitquery provides NFT APIs as-a-Service with access to a wide range of data, including sales data, ownership data, and transfer data. In this article, let’s focus on a breakdown of the analytics that are possible with the Bitquery NFT APIs.

Read More »