Polygon Block Performance

> In the race for scalability it's all about transactions per second with Visa (the credit card processor) doing around 1,700 transactions per second on average [source.)]. Let’s examine Polygon’s block performance and see how it stacks up!

Purpose:

What is the average time between blocks on Polygon?
What was the maximum and minimum recorded time between two blocks?
How many transactions are done in a block on average?
How do these numbers compare to L1 such as Flow or Solana, or other L2 such as Arbitrum or Optimism?

🔗 Links:

➡️ Visit Polygon

📜 Read the Docs

🐦 @0xPolygon

Flipside provides two tables which we can use to analyse block activity: ‘polygon flipside_prod_db.polygon.transactions’ & ‘polygon.core.fact_blocks’. The two tables contain different amounts of data and our aim is to work with as much data as possible. To begin, we will first check if we have sequential data, which is required to determine time between blocks. To do this we will find the min and max block numbers and the number of unique blocks; where the result should be equivalent if the blocks are sequential.

We note that in both tables the difference between the max and min blocks is not equivalent to the count of unique blocks indicating that our data is not sequential.
We also observe that polygon.transactions has significantly more data available, so we will use this table.
To resolve the issue of missing block numbers we will use a case statement in our SQL query to only consider the difference in block times when the preceding block number is equivalent to the current block number - 1. Doing this we will only perform our calculations over sequential blocks.

In our first pass using the technique above, and measuring in seconds, we find results that indicate there could be an issue with the underlying data. Thus a manual analysis was performed with the aid of Polyscan. Values below zero and in excess of 200 were examined. We will briefly examine values over 200 in the table below.

Verifying the results manually in Polyscan, we find that the data is inaccurate until block 25342912 with a time difference of 217 seconds, thus we will manually cap our results at this number. Manually checking results below 0, incorrect data was also discovered. With a bit of research it is determined that our minimum number should start at 2. Thus we will manually apply a minimum of 2 and maximum of 217 seconds to our SQL query with the results below.

💡 As the timestamp issue does not affect our transaction count, the results are provided over all available data.

Given our statistics based upon a manual review of the underlying data, a random sample of 5000 blocks was taken from the filtered TIME_DIFF results and transaction counts were calculated. The scatter plot above indicates that the number of block transactions has no effect on time between blocks; it does not take longer to process more transactions.

Given our results for Polygon we can now turn our attention to comparing these metrics with L1s including Solana & Flow, and other L2s such including Optimism & Arbitrum.

Given our prior issue with block sequences, a quick verification of these chains reveals the same issue in the underlying data. Thus we will apply the same methodology to the data to determine our performance indicators. For these chains, the minimum Time_DIFF will be hard coded to 1 second.

Summary:

Solana outperforms with respect to block times and transactions, almost on par with Visa.
However Polygon is indeed performant with respect to Flow; while time between blocks is almost double 2.24 vs 1.43, the average transactions processed is 82.6 vs 12.8.
In comparison with other L2s Polygon outperforms in terms of speed and transactions.