Try Quests to earn FLOWChart 10 compares the execution rate of successful (bars) and failed (black line) transactions per minute.
The most rate of execution of correct transactions per minute belongs to the Cosmos network and the lowest to the Avalanche network. In this respect, the Flow network is in the third place after Ethereum.
The highest execution rate of the number of failed transactions per minute belongs to the Avalanche network, and the Flow network ranks second.
Flow Network
Flow is a fast, decentralized, and developer-friendly blockchain, designed as the foundation for a new generation of games, apps, and the digital assets that power them. It is based on a unique, multi-role architecture, and designed to scale without sharding, allowing for massive improvements in speed and throughput while preserving a developer-friendly, ACID-compliant environment.
Transaction Speed
Transaction speed is the rate at which data is transferred from one account to another. The faster a transaction is confirmed, the better the transaction speed is said to be. Transaction speed of a blockchain is one of the prime parameters through which viability of a blockchain is gauged.
Transaction speed in turn hinges upon numerous other factors like block size, block time, traffic on the network, transaction fees, etc.
The common indicator for determining the speed of transactions in a blockchain is the number of transactions performed (Succeeded and Failed) per minute. This research is based on the definition.
In this Study
Flow is fast, but how fast?
-
How has Flow increased its speed in transaction per minute since? Compare Flow and other L1 blockchains in terms of speed: identify the monthly average for transactions per minute.
-
How that's improved or worsened since the beginning of 2022.
-
What types of events have raised or decreased the blockchain's performance over that time period?
-
Are there bursts of transaction volume or interest on the chain? Compare Flow's speed to at least two other blockchains.
Methodology
A. Segmentation of Study Period
Given that the report was presented about 6 months ago, so we decided to consider the period of study from the beginning of this year to the date of 2022-12-13 (the date of the report of this report) as the study period. The length of this period from the beginning of the current year (i.e. 2022-01-01) is 346 days. We divided this period into two equal halves (under the first half and half of the study period). The following table shows the segmentation of these periods clearly.
Reference:
B. Monthly Average for Number of Transactions per Minute
In order to extract the average number of transactions performed in one minute on a monthly basis, it was necessary to first extract the number of transactions executed in one minute from the Flow database transactions table. In the second step, we calculated the average number of transactions executed in one minute (extracted in the first step) during a thirty-day period (Sample code below).
--First Step
sub_all_tran as (
select
time_slice(block_timestamp, {{Sub_Granularity_in_Minute}}, 'minute', 'start') as start_slice,
time_slice(block_timestamp, {{Sub_Granularity_in_Minute}}, 'minute', 'end') as end_slice,
count(*) number_of_txs_per_Sub_Granularity_in_Minute
from flow.core.fact_transactions
where (block_timestamp >= '2022-01-01' and block_timestamp<='2022-06-23')
group by 1,2
),
--Second Step
all_tran as (
select
time_slice(start_slice,{{Top_Granularity_in_Day}},'day','start') as date,
time_slice(start_slice,{{Top_Granularity_in_Day}},'day','end') as end_day_slice,
sum(number_of_txs_per_Sub_Granularity_in_Minute) total_tran,
avg(number_of_txs_per_Sub_Granularity_in_Minute) total_avg
from sub_first_all_tran
group by 1,2
),
The report uses two parameters Sub_Granularity_in_Minute and Top_Granularity_in_Day to increase the performance of this report. You can see the sample used these parameters in the sample of the code above. The fist parameter causes to count number of transactions in the specified granularity in minute and the second parameter causes to calculate the average of the previous stage based on the granularity in day (one day, 7 days for one week, 14 days for two weeks and 30 days for one month). You can generate the results in this report by selecting the desired parameter. Note that the interpretations in this report are based on the granularity of 1 minute for the first parameter and 30 days for the second parameter. You need to log in to apply your favorite parameters.
C. Performance of Events Type
We used Table flow.core.fact_events to determine the performance of different events types in the Flow Network and for this purpose:
- We calculated the interval between consecutive blocks created in this network in milliseconds. In this step, we determined how much time took to create a block. At this point, we also drew the total number of events executed per block.
- In the next step, we calculated the number of
event_typeimplemented in each block with theevent_typegrouping. We divided the number of each event by the total number of events implemented in a block and calculated its ratio to the total number of events. We multiply this ratio at the time spent to create that block to calculate the time consumed to execute that event. - In the third step, we arranged the events based on the time consumed to execute them and identified the top 10 events based on this metric. The following code shows how to implement three previous steps:
RAW_DATA AS (
SELECT BLOCK_HEIGHT, BLOCK_TIMESTAMP, COUNT(*) total_events --total number of events each BLOCK_HEIGHT
FROM flow.core.fact_events
where (block_timestamp >= '2022-01-01' and block_timestamp<='2022-12-13')
GROUP BY BLOCK_HEIGHT,BLOCK_TIMESTAMP
),
DIFF_TIME AS (
SELECT *, LAG(BLOCK_TIMESTAMP,1) OVER (ORDER BY BLOCK_HEIGHT ASC) LAG_DATE,
DATEDIFF('millisecond',LAG_DATE,BLOCK_TIMESTAMP) DIFF_DATE
FROM RAW_DATA
),
DATA_CLEANUP AS (
SELECT * FROM DIFF_TIME WHERE LAG_DATE= '2022-01-01' and block_timestamp<='2022-12-13')
GROUP BY 1,2,3
),
Event_Performance as (
select
e.BLOCK_HEIGHT,
e.block_timestamp,
event_type,
number_of_events,
total_events,
number_of_events/total_events as ratio,
DIFF_DATE,
ratio*DIFF_DATE as event_time
from event_count e inner join DATA_CLEANUP d
on e.BLOCK_HEIGHT=d.BLOCK_HEIGHT and e.block_timestamp=d.block_timestamp
)
--tops
select
event_type,
sum(event_time)/(1000*60) Consumed_time_in_Minute,
from event_performance
GROUP by 1
order by Consumed_time_in_Minute desc
limit 10
Results
A. What is going on in Flow network transactions?
Table 2 shows that the Flow Network in the second half of the study has been able to improve the total number of transactions and the total average transactions per minute. But by referring to succeeded and failed transactions to total transactions, we find that their rates are almost equal in the studies period (Succeeded rate is about 88 and Failed rate is about 12).
The following donations visually compare the values listed in Table 1.
Chart 1-1 shows the total number of transactions separated by successful and failed transactions on a monthly basis. The increasing trend of the number of transactions executed in the Flow network is well known. Chart 1-2 is the same as Chart 1-1, with the difference that it is drawn on a daily basis. This graph shows that the number of transactions in the Flow network peaked on June 25th, July 29th, September 2nd, November 1st and 25th during the study period.
Charts 2-1 and 2-2 compare the rates of successful and failed transactions. The first in the monthly period and the second in the daily period. On May 30th, we have seen a sharp drop in the execution of successful transactions.
Chart 3-1 shows the average number of transactions executed per minute on a monthly basis for first and second half of study period. This graph shows that the average transactions per minute increased after May and reached its peak in October. Chart 3-2 also displays chart 3-1 in the daily time frame. The days of the peaks created in this chart correspond to chart 1-2.
You can see the monthly and daily average for the number of successful transactions executed in one minute in charts 4-1 and 4-2. The black line shows the ratio of this average to the total average. In August, we see a high volume of the monthly average number for correct transactions executed in one minute (about 93% of all transactions), while in October, this rate has reached 73%, while the monthly average for succeeded transaction per minute is lower than November.
Notice the October bar in Chart 5-1. About 27% of the monthly average for all transactions executed in October were unsuccessful. This month's dense bars on the 5-2 daily chart confirm this. As we said in graph 2-2, May 30th in graph 5-2 shows the most volume of daily average for failed transactions per minute (About 79% of total average for transactions executed in one minute on a daily basis).
Charts 6-1 (on a monthly basis) and 6-2 (on a daily basis) related to all charts from 3-1 to 5-2 are displayed together.
In chart 7 shows the x-axis as Date, the y-axis as the total number of transactions, the size of the circles as the number of true transactions, and the color of the circles as the study period. This chart is on a daily basis. By comparing the two halves of the study period, we can see that along with the increase in the total number of transactions, the total number of correct transactions per day has also increased in the second half.
Diagram 8 shows that despite the increase in the number of transactions in the second half of the study period (increase in the number of orange circles), the rate of correct transactions did not differ significantly.
Although with the increase in the number of transactions (x-axis), the daily average for the number of transactions executed per minute increases (large circles) and their correct execution rate increases (color spectrum changes from blue to orange), but We can see that the rate of correct execution of transactions (Y axis) is constant in most cases.
The pie below shows the most number of transactions executed on the Ethereum network.
The graph below shows that the average number of transactions executed in one minute in the Ethereum network is more than the other networks studied in this research.
The two diagrams below show that the most number of successful transactions as well as the average number of succeeded transactions executed in one minute occurred in Ethereum, Flow, Avalanche and Cosmos networks respectively.
The two diagrams below show that the most number of failed transactions as well as the average number of failed transactions executed per minute occurred in the Flow, Avalanche, Ethereum and Cosmos networks, respectively.
Chart 11 shows the monthly average for the number of transactions executed in one minute for the four studied networks. As I have seen before, the trend of executing the average number of transactions per minute in the monthly period has gradually increased in flow network, so that in some months this average is not only almost equal to the Ethereum network (May and August), but also In October, it is more than that.
This average in the Flow network was even lower than the Avalanche network until May, but in this month and after that, the Flow network was able to improve this average and not only surpass the Avalanche network, but also compete with the Ethereum network.
Chart 12-1 compares the monthly average number of successful transactions executed per minute in four networks. The results of this graph are similar to graph 11. With the difference that the average number of successful transactions per minute in the Flow network has not yet surpassed the Ethereum network.
When we compare the monthly average rate of true transactions executed per minute with total pf this metric in the four studied networks (chart 12-2), we see that the Flow network is competing with the Avalanche network. And at no time during this study period could it exceed the Ethereum and Cosmos networks. In all months of the study period (except March), the first rank of this rate belongs to Cosmos network.
Chart 13-1 shows that in 5 of the 12 months of the study period, the monthly average number of failed transactions per minute in the Flow network (especially in October) was more than the other studied networks.
In Figure 13-2, we can see again that the Flow network has not been able to reach the level of Ethereum and Cosmos networks in removing failed transactions. Although, in some months of the study period, it has been able to reduce this rate compared to the Avalanche network.
Charts 14-1 to 16-2 show a one-by-one comparison of Flow network with Ethereum, Cosmos and Avalanche networks. There are two graphs in each comparison. The first graph shows the comparison of the total number and rate of successful transactions in the Flow network with the second network, and the second graph shows the comparison of the monthly average of the total number and rate of successful transactions executed in one minute. Apart from the graphs related to the Avalanche network, we can see in other networks that the rate of successful transactions of Flow network is lower than other networks, which we mentioned earlier.
Daily time frame is not provided in this section. You can change this interval by changing the parameter (Total_Granularity_in_Day) and view smaller intervals as well.
Chart 17-1 shows the performance trend of the first 5 of the top ten events in terms of time taken to execute in the daily time frame and during the study period.
The reason for separating 10 events into two graphs with 5 events is to optimize the graph visually.
It seems that the execution time of the TokenDeposited event has been optimized and reduced after August 5. The rest of the days, these five events are normal and fluctuate in a certain range.
Figure 17-2 shows that the AccountKeyAdded event is not optimal on some days and wastes a lot of time to run from the Flow network. To some extent, this issue can also be extended to the Deposit event. The rest of the days, these five events are normal and fluctuate in a certain range.
Conclusion
In this report, we have examined the status of the Flow network transactions in different time frames (monthly and daily). The most important metric that was investigated in this research was the average monthly and daily number of transactions (total, successful and unsuccessful) in one minute.
Due to the fact that about 6 months ago, there was a research about the speed of the Flow network in Flipsidecrypto.xyz, we thought it better to divide the studied time period (from the beginning of the current year to December 13) into two equal parts.
When we compared the total number of executed transactions (total number and per minute) in these two intervals (first half and second half), we found that the number of executed transactions (total transactions, successful transactions and even unsuccessful transactions) in the second half The study has been more than the first half. However, the rate of successful (88%) and unsuccessful (12%) transactions was equal in both halves.
The increase in the number of transactions in the Flow network has been to such an extent that the total number of transactions executed in it has approached the total number of transactions executed in the Ethereum network (somewhat) and in some months of the year it has been equal or even more. But still, the succeeded transaction rate in this network has not been able to reach the Ethereum and Cosmos networks, and it is still competing with the Avalanche network, However, since May, the number of transactions executed on the Flow network (of any type) has surpassed the Avalanche network. Still, the total number of failed transactions of Flow network is more than other networks examined in this report, and the lowest transaction failure rate belongs to Cosmos network.
We have come to the conclusion that the best metric to measure the efficiency of event types can be time. In order to distribute the time consumption of each event, we divided the number of occurrences of each event in each block (which can include one to several transactions and events) by the total number of events in the block, and the obtained rate in time ,and then We multiplied the amount taken time to complete the block (Called block number or height). In this way, we were able to calculate the average time spent by each event and compare them. With this trick, we were able to find the first ten events that wasted the most time to execute from the Flow network, and finally we drew their graphs on a daily basis and during the study period (graphs 17). In these graphs, we found that the Flow network was able to optimize the largest time-consuming event (TokenDeposited) from August 5th, although some other events in some periods took a lot of time to run from the Flow system (AccountKeyAdded and Deposit events).