Methodology

The solana.blocks and the solana_votes_block_agg tables provide the number of total transacions and voting transactions per block respectively. I joined these two tables by block_id for all blocks created since February 1st to obtain the raw data table of all blocks with number of vote transactions and total transactions.

The number of non voting transactions can be calculated with total_transactions-voting_transactions.
And the ratio vote to non-vote transactions will be calculated as the sum of vote transactions per hour divided by the sum of non-vote transactions per hour.

Since the raw data table contains over 1.8M blocks, visualization is not feasible, so alternative tables with the average transaction types per block aggregated by day and hour will be used to present the data in a better way. These tables will contain the following parameters:

• Total blocks per timeframe
• Total vote transactions per timeframe
• Total non-vote transactions per timeframe
• Total transactions per timeframe
• Average vote transactions per block per timeframe
• Average non-vote transactions per block per timeframe
• Average transactions per block per timeframe

Results

Conclusion

The most important conclusion I draw from this bounty is that choosing a timeframe is crucial to understand the data. A too big timeframe can hide trends or relationships between variables.

Around 80% of total transactions on the Solana blockchain are vote transactions, meaning validators are using this transactions to reach a consensus on the valid ledger. This vote transactions are strongly correlated to the network volume (blocks per hour) which on a conceptual level makes sense since more volume on the network would need more validations to make sure the ledger is secure and avoid a wrong ledger to be chosen. I feel that somehow this might be incentivized from the network's operation, just not sure how it works due to a lack of technical understanding of Solana.

The non-vote transactions seem less correlated to network volumen, giving a hint that non-validator users will transact randomly and not volume dependant.

All in all, a very interesting bounty that has triggered a need to understand Solana more deeply!

Introduction

A Solana validator is a full participant in the network cluster that produces new blocks and validates the transactions added to the ledger. A validator votes on a PoH hash for two purposes. First, the vote indicates it believes the ledger is valid up until that point in time. Second, since many valid forks may exist at a given height, the vote also indicates exclusive support for the fork.

Solana has a block time of 400 ms or 2,5 blocks per second, giving 216.000 blocks per day. Compared to other blockchains like Ethereum and Bitcoin, Solana has a much bigger amount of blocks. This creates the need to aggregate the results per day or hour to be able to visualize the trends.

On a daily timeframe, the number of non-vote transactions to vote transactions per block looks relatively stable specially since February 3rd.

To further analyze the relation of transaction type to network volume, I created three scatter charts to see how strong these variables are correlated:

Seeing the last two charts, one can confirm that the vote transactions are strongly correlated to the blocks per hour and hence the network volume, while the non-vote transactions are not so strongly correlated. Since the sum of vote and non-vote is equal to the total transactions, this effect can be seen as well on the first graph, but taking into account that the vote transactions account for around 80% of all transactions, their weight is bigger therefore the correlation is again stronger for the total transactions.

By aggregating on an hourly timeframe, the average values per block fluctuate more. Instead of a single downward spike between February 1st and 2nd, we see a decrease to a local low (February 1st 21.00) and an increase to max levels (Febraury 2nd 10.00), followed by another local low 12 hours later (February 2nd 22.00) and a recovery 5 hours later (February 3rd 3.00).

On a second visualization adding the total transactions per block and the block per hour, we can see an interesting decrease of blocks per hour on February 6th 16.00 which has little to no impact on the average transaction types. If this blocks per hour decrease is not a data corruption issue, one can argue that the distribution of transaction types is independant from network volume.

Notable fluctutations of the ratio vote to non-vote transactions appear on:

• February 1st between 19.00 and 22.00
• February 2nd 23.00 until February 3rd 6.00
• February 6th 22.00 until February 7th 20.00
• February 11th 17.00 until February 12th 5.00

Another way to look at the ratio vote to non-vote transactions is calculating the percentage of vote and non-vote transaction per block. These percentages fluctuate between around 75%-80%. Here the fluctuations are less clear.