Leveraging parallel transactions on Neon EVM

Hello, Web3 community! Welcome to Neon EVM — the original parallelized EVM. As the first parallelized Ethereum Virtual Machine (EVM) built on the Solana blockchain, Neon EVM presents a transformative approach to transaction execution, ushering in much-needed blockchain efficiency and scalability.

This article explains what parallel transactions are, why Neon EVM parallel execution is top-notch, and how to leverage it for your dApp. Let’s dive right in!

What are parallel transactions?

In many computing systems, operations are executed sequentially. This means that a second operation will only start after the first one is completed, and so on. 

In blockchain transactions, this means processing each transaction in a block one after the other, known as sequential execution. Each transaction necessitates validation from the entire network, resulting in substantial energy consumption and a heightened workload for validators. 

This sequential execution of transactions is one of the main bottlenecks to the Ethereum Virtual Machine (EVM) engine’s throughput. Sequential execution bloats the mempool resulting in high transaction costs, mooning gas fees, and a fractured user experience. It impedes the creation of scalable and cost-efficient dApps. 

Parallel execution breaks from this sequential model enabling multiple operations to co-occur. It permits the simultaneous processing of multiple transactions allowing the network to achieve increased throughput — reducing the likelihood of congestion during periods of high demand. This enhances the network’s efficiency and scalability for blockchain dApps, significantly improving the user experience. 

This is where Neon EVM parallel processing steps in. Let’s examine how you can build your dApp to use Solana’s parallel execution architecture with Neon EVM.

Parallel transactions on Neon EVM

Neon EVM is built on Solana and allows developers to scale Ethereum dApps using Solana as the settlement layer. Neon EVM’s parallel execution maximizes the network’s efficiency, improving transaction speeds and lowering associated expenses, all the while, maintaining compatibility with the EVM environment.  

Solana’s Sealevel technology allows us to execute transactions across multiple nodes concurrently. This means that, like Solana, Neon EVM is designed to simultaneously execute various dApps built on top of it — DeFi, gaming, DAOs, DEXs, and swaps — each generating numerous transactions, allowing the network to support massive activity generated by these dApps without clogging. 

However, the capacity to use Neon EVM’s full potential of parallel processing instead of the EVM’s traditional sequential processing depends on how smart contracts utilize data structures.

Therefore, it is crucial for developers to understand designing applications and smart contracts with a parallelized architecture in mind from the beginning. This will allow them to leverage the benefits of parallel transaction processing for their dApp. 

How can developers unlock the full potential of Neon EVM parallel processing?

Parallel transactions cannot be executed when a smart contract uses the same data structure for different transactions.

Let’s understand this better with some examples:

Use case A*  in DeFi: Token swaps

1. Activity: A user utilizes their account to interact with 10 decentralized exchanges. 
       Result: Transactions will run sequentially.
2. Activity: 10 users swap different tokens from different accounts.

    Result: Transactions will be parallelized.

3. Activity: 10 users conduct 10 swaps between USDC and SOL. 
    Result: Transactions will depend on the logic of the smart contract used
4. Activity: 10 users use 10 different applications from 10 accounts while using the same 

    native SPL token (ie, USDC). 
    Result: Transactions will be parallelized. 
 

In example A3, using SPL tokens with wrapped ERC-20, or Neon’s ERC-20-for-SPL tokens, allows Neon EVM to execute transactions in parallel. Whereas using native ERC-20 tokens results in sequential processing. 

*Note: All numbers and scenarios are hypothetical and intended for reader education. 

Use case B* in GameFi: Buy/sell in-game assets 

1. Activity: A user tries to sell 10 game assets from one account on the game marketplace. 
      Result: Transactions will run sequentially.
2. Activity: Player A exchanges an in-game item with Player B, and simultaneously, Player 
3.    C exchanges an in-game item with Player D.

   Result: Transactions will be parallelized. 

4. Activity: 10 players use 10 different wallets and use the same SPL token to buy different 
5.    in-game assets. 

   Result: Transactions will be parallelized. 

6. Activity: 2 teams of players are playing 2 distinct multi-player games on the platform. 

   Result: Transactions will be parallelized. 

*Note: All numbers and scenarios are hypothetical and intended for reader education.

Want to learn more?

In our forthcoming article, we will unveil a detailed framework to guide developers through designing applications that leverage the power of parallel execution. 

Meanwhile, join the buzz with Neon EVM community on Discord and stay tuned for all the EVM alpha on our Twitter. 

Are you building?

If you plan to build your dApp, check out the grants program supported by Poolz x Neon EVM. Complete the form to apply for a co-grant from Poolz Finance and Neon EVM. Don’t miss a beat: join Neon EVM on Discord and Twitter for the latest updates.