At Neon Labs, we’re building the first EVM on the Solana Blockchain. Our platform, Neon EVM, consists of two parts:
- The EVM Contract: A Solana program that manages Ethereum contracts and saves data into Solana accounts.
- The Proxy Server: A proxy that converts Ethereum-like transactions into Solana transactions, and then sends them to the EVM program within Solana for processing.
In this article, we’ll explore Neon EVM’s scalability by calculating the theoretical transaction per second (TPS) limits of Neon EVM and by comparing the theoretical TPS limits against the results of a synthetic load test conducted by the team.
How Solana manages network resource consumption
Before we calculate Neon EVM’s theoretical transaction limits, it’s important to understand how Solana manages network resource consumption.
Solana users pay a small fee for each transaction based on the amount of compute resources they consume (more details here). The fee supports network stability and will always be the same for transactions that are operationally identical. It doesn’t depend on network demand. This model differs from Ethereum where users must pay a “gas” fee determined by the supply and demand of network compute capacity.
The amount of compute resources needed for a Solana transaction is measured in Compute Units (CUs). Each “slot” created by Solana is limited to the consumption of 48 million CUs. Because each “slot” is 400ms minimum, Solana can theoretically support the use of 120 million CUs per second.
Theoretical Transaction Limits on Neon EVM
A transaction that sends NEON tokens between accounts costs between 50,000 to 65,000 Compute Units. In this Neon transaction example, we can see that its associated Solana transaction required 52,127 compute units.
From the previous section, we know that Solana has a limit of 48 million CUs per slot, and each slot is 400ms minimum. With these three data points, we can calculate the theoretical TPS limits for simple transactions, like a NEON token transfer.
- 48 million CUs per slot / avg. 60,000 CUs per txn = 800 txns per slot
- 800 txns per slot = 800 txns per 400ms
- 800 txns per 400ms = 2000 txns per second
From the above, our theoretical limit is ~2000 TPS for simple token transfer transactions. In the next section, we’ll detail our synthetic load testing and compare the results against our theoretical ~2000 TPS.
Synthetic Load Testing
Our stands
First, we installed a Solana node to a dedicated server with Solana-recommended configurations. The specs are as follows: 12 cores CPU and 128 GB RAM. For the load test worker, we installed 6 servers with 8 CPUs and 32 GB RAM in the same data center as our Solana node for less ping.
Software
To create a synthetic load we used the https://locust.io framework in Python. The framework was selected because it allows for quickly creating load tests, and we already had the required libraries for our task written in Python. All code can be found here.
Preparation
Before launching the load test we took the following actions:
- We disabled the whitelist operator in EVM and increased the count of treasury accounts
- We created Ethereum and Solana sender/recipient accounts via faucet (airdrop NEON tokens to accounts)
- We prepared operator accounts (airdrop Solana and neon to each operator key)
For steps 2 and 3 above, we used this script.
Run test
We launched 8 instances of locust on each load test server because a single locust worker can create only 66 transactions per second (it uses only one core per process.)
Several environment variables were also created because we needed to split our operator’s keys and user accounts between each locust process.
After setup we ran our locust process using the following command:
Results
When we started 40+ locust processes, we observed great results in the official Solana explore inline with our theoretical calculation:
After running the load test for more than 30 minutes, we took the following performance snapshot:
In one slot we saw more than 800 transactions:
At the conclusion of our testing, we noted a maximum TPS of 2169 over the span of 30 minutes. The results are slightly higher than our theoretical calculation and are attributed to the different amounts of CUs consumed per transaction.
In the above snapshot, you can see that anywhere from 57k to 60k CUs are used in transactions.
