The troublesome issue of assessing blockchain performance

It’s notoriously difficult to compare the performance of the various blockchain ecosystems, which is why the community tends to fall back on easily-verifiable yet shallow metrics such as transactions per second (TPS). So, let’s take a look at why it is such a challenge to meaningfully discuss blockchain performance — a key consideration when you have a new use case or dApp. 

We delve into what measurements of performance may be most informative. We also look at the alternative strategies that blockchain ecosystems are applying to solve the scalability issue. And we ask you, the community, what metrics do you consider most valuable? Never fear, if this all sounds too technical for your liking, head over to our Medium for a lighter take.

Common performance metrics

In a pre-sharded Ethereum, the L1 is capable of approximately 15 TPS, with a time to finality (TTF) of about 15 minutes. When you compare this with a centralized entity such as Visa, which can handle 15,000 TPS, it quickly becomes apparent that scalability is a pressing issue. Before we consider how the various solutions attempt to overcome this challenge, let’s first critique those metrics used to measure the performance of a blockchain.

TPS is a quantitative metric that lacks essential, qualitative details. Within blockchain networks that support smart contracts, such as Ethereum and Solana, it is possible to place a computationally demanding task on the chain. This means that a simple transfer of a token counts as a transaction, and so too does deploying a smart contract — even though the amount of gas they consume differs due to their computational demands.

This is why throughput is a better metric of comparison. Throughput is correlated with how fast a new block can be added and how many units of computation can be processed in that block. Ultimately, throughput is an outcome of a balance between several factors, including CPU, bandwidth, and storage requirements. However, as throughput increases, the number of nodes on the network tends to decrease, pushing the network toward centralization.

So, even though throughput is arguably a better metric to measure a blockchain’s performance, it needs to be considered alongside the number of available nodes. That is, we have encountered the often-cited blockchain trilemma: the challenge of balancing security, decentralization, and scalability in blockchain platforms. Where attempts to increase scalability (throughput) often result in reduced decentralization.

The L2 solution

In the Ethereum ecosystem, Layer 2s (L2s) have arrived to take computation off the Ethereum network, share transaction costs, and instead use Ethereum L1 as a secure settlement layer — providing transparency over the outcome of transactions. This means that L2s either fully or partially derive their security from layer one Ethereum, meaning that users do not have to rely on the honesty of L2 validators for the security of their funds.

That “fully or partially” qualifier used to define L2s matters. By sending transactions to be executed off the L1, L2s tend to sacrifice security due to their inherent trust assumptions required to achieve their improved performance. That is, additional/external entities and mechanisms are required for transaction verification. Also, it’s difficult to maintain agreement around state when transaction events occur off the L1.

Alternative approaches to L2s

There are alternatives to creating an L2 state that must be reconciled with the L1 state, and that is to create a blockchain L1 that is performant to the load demands of multiple dApps. This is Solana’s approach. Solana’s Sealevel executes transactions in parallel (as long as those transactions are for unique accounts). This is probably why Visa selected Solana to carry the potential load created by a Solana:Visa collaboration.

https://twitter.com/aeyakovenko/status/1699082678509965686

However, to take advantage of Solana’s performance, developers must first understand the very different program, memory, and compute models that Solana offers compared to that of Ethereum. That was until Solana had its own EVM.

Neon EVM: evading the L2 compromises  

Neon EVM, the first EVM on Solana, allows users to take advantage of Solana’s parallel execution capabilities without having to refactor their entire dApp to fit with the different architectural and computational models of Solana.

This means that for the first time, Ethereum-native dApps can discover what performance it’s possible to squeeze out of the EVM while relying on the Solana transaction layer.

Ready to come deeper down the rabbit hole?

So, we have an L1 that is highly performant and an EVM that is compatible with that. The world is your oyster; everyone is happy, right? Ha, not so!

As Starkware so eloquently put it, scalability is the most misrepresented term in the blockchain space. We have already dismissed TPS as a fun but shallow metric (we will, of course, be bringing you our future TPS figures, as they are genuinely, and verifiably, awesome). We covered why throughput must be discussed alongside decentralization. But, down this rabbit hole, there is an additional argument that hardware costs must also be factored in.

Solana accepts the tradeoff that to increase throughput, hardware costs to run a node and process transactions also increase. Purists may argue that anyone should be able to download the database history and run a node. It is an attractive idea to a Web3 native that anyone can be a validator using simple hardware, ensuring the stability of their favorite decentralized network.

The counterargument to that is, well, how many validators are actually required for everyone to be able to trust in the blockchain? Solana has over 3,000. Ethereum scales this by more than 100x. However, such numbers offer no discernible advantage to the Ethereum network. In fact, having so many validators places a massive messaging load-carrying demand on the network, which is why the community is discussing increasing the validator stake and reducing that validator pool.

So, what do you consider when you ponder blockchain performance? Do you have a favorite Web app where you take a look at the various chains’ TPS? After all, it gives you an idea of user activity that day. Do you go deeper? If so, what is it that matters to you in terms of performance?

Want to get involved?

Come and join the Neon EVM community on Discord and share your opinion on what metrics matter to you and your dApp.