Parallel processing from an EVM

Neon EVM is the first EVM to be compatible with Solana. This gives Neon EVM a significant performance advantage over standard EVMs, because it leverages the technical advantages offered by Solana.

 

Let’s focus on just one of those innovations that Solana brings to the table, the parallel processing of transactions, and consider how that impacts your pocket.

 

The link between tx cost and throughput

 

When the mempool/transaction pool of a blockchain starts to grow, i.e. the number of pending transactions increases in the queue, the gas price of the blockchain increases. Higher gas transactions tend to be prioritized, and the lowest gas transactions may be ignored. This creates a competitive environment that causes spikes in prices.

 

Remember the CryptoKitties game where folks paid gas fees in the order of $100+ per transaction; or the Otherdeeds NFT launch that pushed fees above $450? Yeah, that competitive environment!

 

Solana’s incredible throughput means that it is far less vulnerable to such transaction pool bloat, which results in far more stable transaction costs. Solana achieves this throughput thanks to Sealevel’s parallel processing.

 

Single threading vs. Parallel processing on the blockchain

 

The EVM runtime is single-threaded, i.e. only one contract at a time modifies the blockchain state. Because the EVM executes transactions sequentially, it limits the number of transactions that may be processed and increases the time of the execution. Solana’s Sealevel provides a runtime that can process tens of thousands of contracts concurrently. Furthermore, parallel execution of transactions allows processing to be divided among all the cores available to the validators.

 

When a specific transaction or transaction batch meets Sealevel’s concurrency requirements, then Sealevel automatically processes them in parallel. And the criteria to meet such a requirement? Independence of the transaction/s. Non-overlapping transactions are those that do not attempt to update the state of the same Solana accounts. Transactions may read the same state and qualify to be processed concurrently.

 

Clearing the bottleneck

 

Because sequential sequencing of transactions by the EVM is a bottleneck to dApp performance resulting in price volatility, alternatives are being considered and have been implemented:

 

- L2s: Side chains/rollups

- Parallel processing/Sharding

 

L2s

 

L2s take the computational load off the L1, reducing the demand on the base layer. The benefit is that the settlement of the transaction outcome is recorded to the L1. There are several downsides, however. From a security perspective, the dApp must rely on the security of the L2 layer, and because nascent L2s emerge with small validator pools, they are often vulnerable to limited decentralization. Secondly, the settlement times are slower: you are now relying on the L2 to finalize first, and next, for the L1 to finalize the transactions declared by the L2. With optimistic rollups, the transaction may not even be considered final for an extended period.

 

When the L2 is not designed to handle high throughput, then the L2 itself can become a bottleneck and, therefore, a source of price volatility, as demonstrated by the demand-driven price spike in November 2023 when transaction costs reached $0.10 on the Polygon PoS network.

Parallel processing

 

Two forms of parallel processing are available, one applies multi-threading and changes the state of the L1, and the other allows fragments of the blockchain to maintain separate states, which are later reconciled; this is known as sharding.

Sharding

Sharding allows for a type of pseudo-parallel processing to increase the overall throughput of the network. Sharding partitions the blockchain into smaller, more manageable pieces. In a sharded blockchain, each shard contains its own set of smart contracts and is responsible for processing its own transactions. Instead of every node processing and validating every transaction on the network, each node is assigned to a specific shard and is responsible for processing transactions within that shard only. This reduces the risk of mempool/transaction pool bloat, and, therefore, reduces the likelihood of price fluctuations. 

 

However, as with the L2 solution, the downside is that there is no single layer: each shard must settle the transaction, and then later, the shards must coordinate with each other to agree on a universal L1 state. This means that it is no longer a simple query to access the recent history of the blockchain, and additional synchronization mechanisms may be needed – hence, the label pseudo-parallel processing that we applied above. Because of these challenges, Ethereum’s roadmap no longer promises to implement sharding by the end of 2023.

Single-base layer parallel processing

 

Discussions around how to implement parallel processing are being entertained in the Ethereum space, such as Vitalik’s 2017 EIP. This is because there are significant security and performance advantages to enabling the parallel processing of transactions on a unified L1 blockchain. 

 

Solana’s developers were determined to implement parallel processing by design. This allowed them to benefit from several crucial advantages offered by parallel execution:

 

1. Solana is positioned to benefit from the ever-expanding performance of modern hardware. We may not be aligned with Moore’s law precisely, but the principle holds true that Solana’s performance will grow with the growing performance of the hardware, which is impossible in the sequential mode of transaction execution.

 

2. The virtuous cycle: Typically, fast execution results in small block times and, therefore, fast finalizations — which means a fast UX. Solana is recognized as a high-performance L1 blockchain because it is capable of sorting millions of pending transactions into batches and scheduling those that are independent of each other to process in parallel. This capability explains Solana’s high throughput.

 

3. Coherent L1: By enabling dApps and users to work on one L1 with a universal state, the chain is able to support complex systems with many actors. Participants are able to communicate in one space without bridges and other components, which, ultimately, also improves security.

What does parallel processing mean for cost?

 

Solana’s method of charging for transactions provides a stable transaction cost. In fact, the transaction price in SOL is the same as it was a year ago. 

 

On Solana, transaction fees are calculated based on:

 

• base fee per signature, currently set at 5000 Lamports (0.00005 SOL)
• compute units required, i.e. the computational resources used during the transaction

 

Therefore, the price remains stable within the ecosystem, and only the conversion ratio of {Your token of exchange}:SOL, influences the outcome.

 

This allows dApps to operate in a much more stable environment, as well as settle to an L1 known for its high throughput and finality (see more on blockchain performance metrics).

 

But what if the demand exceeds throughput (in EVM terms, the mempool bloats)? If the system does experience such a huge demand that the mempool/que grows and settlement times slow, it is possible to offer the validator a "prioritization fee" to provide faster execution times. This has helped Solana mitigate against the bot overloads that are possible when no barriers are in place. 

 

And the cost? At the time of writing, Solana Compass shows that the average transaction fee paid by Solana’s users in the last epoch was 0.000018635 SOL, which is 0.000000028 BTC/0.001 USDC.

 

In Solana, then, we have a transaction pool that is less likely to experience bloat than Ethereum’s L1 and associated sidechains, with a transaction fee, that, even in the face of increased demand, is measured in cents or pennies — all thanks to the parallel processing model of Solana.

What does this mean for Neon EVM users?

 

For dApps that choose to build on Neon EVM, you have all the familiar tooling of the EVM ecosystem, while benefiting from the parallel execution of transactions across all Solana validator’s cores.

 

This explains why Anatoly is bullish on the potential of a parallel EVM: 


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

We are, obviously, bullish too, and will soon be taking our shiny new EVM out for a public test drive. Since Neon EVM launched on Solana Mainnet in August 2023, we have been conducting tests. And, for a little bit of alpha, we expect to be releasing data shortly to provide insights into Neon EVM's transaction speed, which we anticipate could exceed 1000 TPS, and will follow up tests that examine the relative impact of utilizing Solana’s parallel processing vs. transacting without it.
 

Are you building?

 

If you plan to raise capital via an IDO, check out the $15k grant by Poolz x Neon. If you’re interested in building on Neon EVM, reach out to us on Discord to learn more about the benefits and how Neon can support your growth. And, don’t forget to join the Twitter community for the latest updates.