Is TPS Misleading for Rollups? Here’s Why UOPS or Gas/ Sec Are Better

Zeeve - Sep 16 - - Dev Community

TPS has long been a preferred metric for measuring blockchain performance. It may be a good option for the time when there were only alternative blockchains involved in sending transactions from one address to another. But, things have changed a lot now. Today, we have scaling solutions like rollups with innovative features like Account Abstraction, Gasless transactions, alternative DA, aggregated liquidity, and more. 

Despite this, Layer2s are still judged on the basis of TVL. To counter this, let’s learn more Rollup performance metrics that are a good alternative to TPS. We will basically understand how TPS can be misleading metrics through our own comprehension plus based on the aggregation vision of web3 experts. 

Are Layer2 rollups redundant? Busting the misconception

For some time, rollups have been challenged for not being able to serve as a feasible Layer2 scaling solution. However,  people’s analysis is mostly based on ‘TPS’. Let’s look at some of the tweets regarding this: 

https://twitter.com/stacy_muur/status/1832103234229694933

https://twitter.com/DU09BTC/status/1642451069728063489

This is obviously not a fair analysis because TPS has a different positioning in rollups. As discussed, rollups create batches of transactions and publish them on Layer1 as a single transaction. Putting it more simply, even if thousands of transactions are bundled and processed in a second, the transaction would be counted as one. Whereas, on Ethereum, TPS is mostly counted based on individual actions that external EOAs account performs. 

Image description

If we look at Ethereum’s current transaction block, most of the transactions processed are based on individual actions, e.g ‘Transfer’, ‘Approve’, ‘Deposit’, 'Register’, etc. 

Image description

On the other hand, if we look at the transactions in the StarkNet explorer, we can clearly see multiple UserOps are bundled into a single transaction, e.g approve, deposit or approve, multi_route, or multi_swap, clear.

Image description

This signifies that TPS is all about counting transactions, but the user operations are batched into it. Hence, rollups’ capabilities should not be judged based on TPS. 

But, what makes TPS a flawed performance metric for rollups?

Our data-backed insights and aggregation of thoughts suggest that TPS is a flawed metrics to determine performance or overall reliability of any rollup network. However, L2s like Xai, Base, Arbitrum One, Taiko, and WINR are already way ahead in TPS compared to Ethereum (according to L2Beat’s data). Now, let’s understand how TPS is misleading to rollups through web3 experts’ view:

Steven Goldfeder, the Co-founder at Offchain Labs (the developers behind Arbitrum) has talked earlier about the TPS. He says there shouldn’t be any comparison between Layer2s and Ethereum’s TPS because it will be like counting only the number of bills while ignoring the cost of each bill. Further, Steven Goldfeder mentions that a better performance metric for Layer2/Layer3 scaling solutions is gas-per-second. We will discuss later.

https://twitter.com/sgoldfed/status/1749678992334962850

Another statement is from Mert Mumtaz; the CEO of Helius Labs. He claims that metrics like TPS, TVL, and Users are clearly pointless because these can be easily manipulated. In his view, latency, nodes, associated startup, and similar factors may work, but these are also not perfect. Hence, qualitative metrics like UserOps and Gas per second can work instead. 

A relevant example here can be Solana, which shows a theoretical TPS of 65000, but the real TPS is somewhere around 565. However, Solana TPS is still impressive and it’s a prominent blockchain. The real concern is that new networks don’t refrain from the bold statement of offering extremely high TPS than all the existing L2/L3s as well as a surprisingly high theoretical TPS. 

Image description

Also, there is Bartek Kiepuszewski; the prominent researcher for Ethereum, DeFi, and L2 ecosystem. He says that TPS is a faulty metrics to measure the scalability/throughout in rollups. The better alternative is tracking UOPS or user operation per second, which is accommodated through account abstraction (AA). Here’s the tweet:

https://twitter.com/bkiepuszewski/status/1719441292197830928

A good example here can be Arbitrum One; Ethereum’s Layer2 scaling solution that uses native account abstraction to offer a maximum TPS of 58.97. It allows Arbitrum One to create batches of transactions containing userOps, not just individual actions. Hence, counting TPS cannot make sense. Instead, ERC20 transfer per second, userops, or gas per second can be better alternatives. 

Alternative to TPS: UserOps and Gas per second as key performance metrics

UserOps and Gas per second are the two key metrics that should be used as performance indicators in rollup networks. Let’s dive a little deeper into these: 

UserOps per second (UOPS)

UserOps is the key metrics powered by ERC-4337; Ethereum’s standard for Account Abstraction. This is essentially a ‘pseudo transaction’ that gives instructions to smart contracts about desired actions on behalf of users. UserOps per second is now becoming a solid and easily quantifiable metric to evaluate performance in rollups. 

Example: If a user wants to stake tokens on a DeFi protocol, this will require two separate actions– staking and claiming rewards. Account Abstraction bundles these two UserOps. But, TPS for these transactions would still be just one. Some of the top UserOps components are Bundlers, EntryPoint, Paymaster, Smart Contract Wallet (SCW), MemoryUserOp, and UserOpInfo. 

A range of L2s like Starknet strongly supports the initiative to measure rollup performance, hence Starknet has renamed their graph to UOPS.  From their explorer anyone can check Starknet’s peak UOPS.

Image description

Although UserOps per second is a highly feasible metric, it may face criticism due to its lack of application outside the Ethereum ecosystem. Non-Ethereum L2s still face challenges to leverage UserOps-based metrics. 

Gas per second 

Gas per second (GPS) refers to the amount of computational load a blockchain network can handle per second. Here, ‘gas’ is the unit for measuring the computational effort needed to perform specific operations like smart contract execution. Hence, standardizing any L1/L2/L3 based on gas per second is a clear reflection of showcasing their performance and efficiency. Gas per second can be easily determined by dividing per block gas usage (targeted) with block time. 

Layer2s using GPS as performance metrics will have a simple path to demonstrate their network’s comprehensive performance. The same vision was introduced by Avihu Levy; chief product manager at Starkware and Georgios Konstantopoulos; CTO at Paradigm. 

Here are top ten chains organized based on Mega Gas Per Second (MGas/sec); the total millions of gas units a network can handle per second. 

Image description

Source: rollup.wtf

Like UOPS, Gas per second has challenges too. Measuring performance based on GPS is usually difficult  since each chain has their unique computation method for has, such as Solana has ‘Compute Units’ while Aptos has ‘Gas units’. 

Wrap up!

Rollup performance metrics are nothing but the indicators designed to assist both the web3 developer and the L2 network itself. Irrespective of what metric you consider, having a high-performing chain is non-negotiable. So, if you plan to build L2/L3 rollups that could offer optimal UserOps and Gas per second, explore Zeeve RaaS. With us, you can launch rollups for all the leading frameworks like Arbitrum Orbit, OP Stack, Polygon CDK, and ZK Stack. Also, you can set-up a mainnet-ready testnet on Zeeve RaaS in minutes. Try for free or connect with our experts to learn more about our services. 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .