Scroll #1: Solayer Chain (InfiniSVM)
The Hardware-Accelerated SVM Blockchain for Solana Network Scaling
The Evolution of Blockchain Scaling: From Bitcoin to Solayer
As blockchain adoption grows, the demand for computational services across networks increases exponentially, making scaling solutions crucial. What began as Satoshi Nakamoto's peer-to-peer cash system experiment evolved into Ethereum's decentralized virtual computer, enabling applications in finance, gaming, real-world assets, communication, and governance. However, this growing usage has exposed infrastructure limitations. For instance, network congestion on Ethereum leads to higher fees through its gas auction system, while Solana experiences transaction drops or expirations, both resulting in diminished user experience compared to centralized solutions.
Different blockchains have approached scaling challenges distinctly. Ethereum implemented Optimistic and Zero-Knowledge rollups, which process transactions on independent sub-layer networks (L2s) before batching them back to the main chain for security and finality. While effective, this approach creates liquidity fragmentation across different L2 protocols, leading to high slippage and fees during cross-L2 asset transfers.
Solana took an alternative approach, focusing on high-performance software, parallel transaction execution, and powerful hardware. However, this strategy requires increasingly demanding hardware specifications for validators (3.1GHz, 500GB RAM, 2.5TB Storage), and current CPU utilization remains around 30% during heavy loads. This limitation suggests that software optimization alone cannot achieve further significant improvements.
To overcome these constraints, new acceleration methods are being explored, such as offloading tasks to reconfigurable hardware like FPGAs. However, this approach requires advanced storage protocols like NVMe-oF to maintain low latency. A key challenge is network bandwidth management, as peer-to-peer communication already consumes about 0.8Gbps per validator, approaching the 1Gbps limit of typical consumer-grade internet connections.
Enter Solayer Chain's InfiniSVM, a multi-executor, and hardware-accelerated SVM Network. This innovative design scales a single-state blockchain by distributing network workload across specialized hardware and clusters while maintaining atomic state consistency, unlike the multiple independent states of rollup solutions. Solayer achieves this through:
Decomposing critical SVM operations into infinitely scalable microservices using NVMe-oF protocol (Infini-band).
Implementing hardware acceleration via SDN Switch and FPGA protocols.
Utilizing a sharded database system for blockchain storage.
Employing a novel proof-of-authority-and-stake (PoAS) consensus protocol.
These innovations enable Solayer to target 1M+ TPS and 100Gbps+ bandwidth while offering user-friendly features like hooks, cross-chain calls, jumbo transactions, OAuth-based wallet signing, and multiple wallet support.
As we proceed into the following sections, we explore the infrastructure of the Solayer Chain and compare it to that of Solana as a highly scalable and efficient Super set of the SVM.
Definitions
Before delving deeper into our analysis of Solana and Solayer Chain's scaling mechanisms, it's important to establish a clear understanding of several technical terms that may be unfamiliar to readers without a software engineering background. To ensure comprehensive understanding, let's first provide brief definitions and explanations of key concepts that will be frequently referenced in our discussion.
Program Derived Addresses (PDAs) are special accounts in Solana that exist "off-curve," meaning they aren't associated with a traditional Ed25519 keypair but are instead derived deterministically from a program's address and additional seeds, allowing programs to securely store and manage state.
Cross Program Invocation (CPI) is a mechanism that enables one program to call another program while maintaining security and atomic execution, preserving transaction properties and permission hierarchies.
Bidirectional Bridging, as implemented in Solayer Chain, is a native bridge system integrated within the sequencer that enables secure communication and asset transfer between Solana and Solayer Chain, featuring both immediate and finality-based message relay options along with an insurance fund to handle Solana reorganizations.
Transaction Mirroring in Solayer Chain is a system where each Solayer program and account has a matching counterpart (called a PDA) on Solana's mainnet. When a program on Solayer needs to interact with Solana, it uses these mirrored accounts to execute actions across both chains in a coordinated way. This enables seamless cross-chain operations while ensuring that states remain consistent between Solayer and Solana.
Data Shredding is the process of breaking down transaction data into smaller packets called "shreds," similar to how individual frames make up a video stream.
The Effect Hash is a cryptographic digest that represents the final state after transactions are processed, essentially capturing what the transactions did to the system state.
The Shred Hash is a unique identifier for each shred, formed by combining the latest Proof of History hash with the transactions contained in that shred.
A Key-Value Store is a fundamental database model where data is stored and retrieved using unique identifiers (keys) that map to specific pieces of information (values), similar to how a dictionary matches words to their definitions.
Database Nodes are specialized components that store these key-value pairs, where each 32-byte account address (the key) maps to its corresponding state data (the value). These nodes work together in a sharded system, meaning the data is distributed across multiple nodes, with each node responsible for storing and managing its portion of the total blockchain state.
A Sequencer is a trusted entity that acts as a leader, receiving and organizing transactions into shreds (groups of transactions) before publishing them to the network. It functions as the primary coordinator for transaction processing.
Provers are participants in the network who stake tokens and verify the sequencer's work by re-executing transactions in shreds to confirm their validity. These provers vote on whether shreds should be accepted, with a shred requiring votes from 51% of selected provers to be finalized. On Solayer Chain, they both form a key part of Solayer's Proof-of-Authority-and-Stake consensus mechanism, where the sequencer handles transaction ordering while provers ensure the accuracy and validity of processed transactions.
RDMA (Remote Direct Memory Access) is the general concept of directly accessing memory across a network, while InfiniBand is a specific implementation of this technology.
InfiniBand RDMA (Remote Direct Memory Access) is a high-performance networking technology that allows computers to exchange data by directly accessing each other's memory, bypassing the operating system and CPU, resulting in extremely fast data transfers with very low latency. InfiniBand RDMA enables fast data sharing between nodes on Solayer Chain.
SDN (Software-Defined Network) Switch is a specialized network device that can be programmed to handle data routing in customizable ways. Unlike traditional switches that follow fixed rules, SDN switches can be dynamically configured through software to optimize network performance. SDN switches optimize network routing between simple and complex path transactions during the transaction Sequencing Stage of Solayer Chain.
NVMe (Non-Volatile Memory Express) is a high-speed storage protocol designed specifically for solid-state drives (SSDs), allowing for much faster data access than traditional storage protocols.
NVMe-oF (NVMe over Fabrics) extends NVMe's high-speed storage capabilities across a network, allowing computers to access remote storage devices as if they were directly attached, maintaining the same high performance. NVMe-oF provides scalable high-speed storage across Database Nodes on Solayer Chain.
FPGA (Field-Programmable Gate Array) is a type of hardware chip that can be reprogrammed to perform specific tasks extremely efficiently. Unlike general-purpose processors, FPGAs can be optimized for particular operations, making them much faster for those specific tasks. FPGAs accelerate specific Blockchain operations on Solayer Chain.
Proof of History (PoH) is Solana's unique time-tracking mechanism that acts like a cryptographic clock. It creates a historical record of when transactions happened by continuously running a sequence of computations that produce verifiable time stamps. Think of it as a way to prove that certain events happened in a specific order.
Proof of Stake (PoS) is a consensus mechanism where participants (validators) put up collateral (stake) in the form of cryptocurrency to earn the right to validate transactions. The more stake a validator has, the more likely they are to be chosen to validate transactions and earn rewards. It's like having a security deposit that ensures validators behave honestly.
Byzantine Fault Tolerance (BFT) is a property of a system that can continue operating correctly even when some components fail or act maliciously. Think of it as a group decision-making process that can reach the right conclusion even if some group members are lying or broken.
Tower BFT is Solana's specific implementation of BFT that leverages Proof of History. It's designed to be more efficient by using PoH's synchronized clock to reduce the communication needed between validators to reach consensus.
Virtual Machine/Computer is a software simulation of a computer that runs within another computer. In the blockchain context, it's the environment where smart contracts (programs) are executed. Solana's SVM (Solana Virtual Machine) provides a controlled, secure environment for running blockchain programs.
Stake-Weighted Quality of Service (SWQoS) is Solana's mechanism for prioritizing network traffic based on how much stake validators have. Those with more stake get higher priority in transmitting transactions, similar to how a premium ticket might give you priority boarding on a flight.
QUIC (Quick UDP Internet Connections) is a modern network protocol developed by Google that combines the speed of UDP with the reliability of TCP. In the blockchain context, it helps manage transaction transmission more efficiently while preventing network congestion. Think of it as an intelligent traffic management system that can handle many messages simultaneously while ensuring important ones don't get lost.
TPU (Transaction Processing Unit) is Solana's component that handles incoming transactions in validator nodes that are currently leading (creating new blocks). It's like an assembly line for transactions, with different stages: receiving transactions (Fetch), verifying signatures (SigVerify), and processing them into the blockchain (Banking stage).
TVU (Transaction Validation Unit) is the component that validates transactions in non-leader validator nodes. While TPU processes new transactions, TVU verifies that processed transactions are correct. Think of TPU as the writer and TVU as the editor - one creates while the other checks the work. They have similar stages but serve different purposes in the network.
The Shortest Makespan First (SMF) Algorithm is a scheduling strategy used in Solayer Chain to optimize transaction processing. The "makespan" refers to the total time needed to complete all tasks. This algorithm prioritizes transactions that can be completed quickly, processing them first to reduce overall processing time. Think of it like a grocery store express lane that handles quick transactions first to reduce total waiting time for everyone.
The Round-Robin Selection Algorithm is a simple, fair method of distributing tasks where each participant takes turns in a fixed order. In Solayer Chain, it's used to select provers for transaction verification - if there are 10 provers, each will be selected in turn to verify transactions, ensuring an equal distribution of work. It's similar to how a teacher might call on students one by one around the classroom to ensure everyone gets a chance to participate.
Blockchain Reorganization (or "reorg") occurs when a chain of blocks that was previously considered valid is replaced by a competing, longer chain. This can happen when multiple validators produce blocks simultaneously, or when network delays cause temporary forks. Think of it like history being briefly rewritten when new information proves a different sequence of events is more accurate. In Solayer Chain's context, the insurance fund specifically addresses reorgs by covering any potential losses that might occur during these temporary chain reorganizations.
A Dutch Auction is a price-setting method that starts with a high price that gradually decreases until a buyer accepts the price or a reserve price is reached. In Solayer Chain, this model is used in the hooks system where users bid for hook execution slots, where the price mechanism follows the Dutch auction model of starting high and decreasing until all slots are filled or minimum prices are reached. It's similar to how some NFT projects start at a high price and decrease until all items are sold.
OAuth (Open Authorization) is a widely used security protocol that enables users to grant third-party applications limited access to their accounts without sharing their passwords. Think of it like a hotel key card system - instead of giving someone the master key (your password), you give them a temporary key card (OAuth token) that provides specific, limited access. In the blockchain context, OAuth integration allows users to use their existing accounts from services like Google, X (formerly Twitter), or Reddit to interact with the blockchain. Rather than managing complex cryptographic keys, users can authenticate using familiar login methods while maintaining security.
Solana SVM Infrastructure Deep Dive
To properly appreciate Solayer’s architecture we must first understand the Network (Solana) that is trying to scale. We believe that this will give us a proper understanding of both the SVM and InfiniSVM. A complete Solana interaction has the following stages;
User-dApp Interaction Stage
When a user wants to interact with Solana, they first connect their wallet (which contains their public and private keypairs) to a decentralized application (dApp). The dApp then constructs a transaction message based on the user's intended actions - for example, if they want to swap tokens, the dApp would specify parameters like the amount to swap and acceptable slippage rates. This transaction message includes a header, a list of all account addresses that will be read from or written to, a recent block hash to prevent duplicate transactions, and the specific instructions to be executed.
Once the transaction message is constructed, it's sent to the user's wallet for signing with their private key. The wallet typically displays a popup asking the user to confirm the transaction, often including a simulation of what will happen if they approve.
After the user confirms, the wallet signs the message with their private key and returns both the message and signature to the dApp, which then forwards everything to an RPC (Remote Procedure Call) provider. These RPC providers act as intermediaries between applications and validators, handling the routing of the transaction to the current leader validator who will process it into a block.
Golf Stream Stage
In the Gulf Stream stage, all transactions are forwarded directly to the predetermined leader validator for the current slot, rather than being broadcast randomly across the network like in traditional blockchain mempools. The leader schedule is produced before each epoch (approximately every two days) and divides time into 400-millisecond slots, with validators being chosen as leaders based on their stake weight - the more stake a validator has, the more likely they are to be selected as a leader.
The Gulf Stream stage implements a Stake-Weighted Quality of Service (SWQoS) mechanism to prevent spam and enhance network security. Under this system, transactions that are proxied through staked validators get priority access to the leader, with validators having higher stake receiving proportionally higher bandwidth capacity. This creates a "priority lane" system where RPC providers can lease stake-weighted capacity from validators to ensure better transaction throughput. The entire communication process uses the QUIC networking protocol, which combines the speed of UDP with TCP-like security and flow control, allowing for rapid asynchronous communication while maintaining the ability to manage traffic and prevent network congestion.
Block Building Stage
The block-building stage is where Solana takes incoming transactions and packages them into blocks. Unlike other blockchains that wait to assemble a full block, Solana continuously builds and streams blocks during each 400-millisecond time slot. Leaders (validators chosen to build blocks) get four slots in a row, giving them 1.6 seconds total to work with.
When transactions come in, they go through three main steps. First, they're received and collected through what's called the Transaction Processing Unit (TPU). Second, all the signatures are checked to make sure the transactions are legitimate and haven't been submitted before. Third, they move to the banking stage, where the actual processing happens. Here, transactions are bundled into groups of 64 called "entries," but only transactions that don't interfere with each other can go in the same group.
What makes this interesting is how Solana can handle multiple transactions at once. Every transaction must declare upfront which accounts it's going to use - this allows Solana to process several transactions simultaneously as long as they're not trying to access the same accounts. The system uses six different processing threads to do this work - four for regular transactions and two specifically for voting transactions. While all this is happening, a special timekeeping service called Proof of History runs continuously, marking when everything happens. All the account information is kept in a database called AccountsDB, and once a block is confirmed, all changes are permanently saved this is done by flushing all the account updates from the bank to the disk (like saving data from memory to storage). The final State of the chain is the result of all confirmed transactions and can be deterministically recreated from the blockchain history. This architecture allows Solana to achieve high throughput while maintaining consistency and reliability in its state management.
The result is a very efficient system that can handle thousands of transactions quickly, much like a well-organized assembly line where multiple workers can operate independently because they know exactly what resources they need beforehand.
Here's a breakdown of all the sub-processes of the Block Building Stage:
Fetch Stage
- First point of entry in the TPU for incoming transactions
- Receives transactions via the QUIC protocol
- Acts as the initial gateway for transaction processing
SigVerify Stage
- Performs rigorous validation checks on incoming transactions
- Verifies the validity of all signatures
- Confirms the correct number of signatures are present
- Eliminates duplicate transactions
- This stage leverages parallel processing for signature verification
Banking Stage
- This is the core block-building stage where transactions are processed
- Uses "the bank" - a data structure representing state at a given block
- Processes transactions in parallel by grouping them into "entries"
- Each entry contains up to 64 non-conflicting transactions
- Parallel processing is enabled because:
Transactions must pre-declare all accounts they'll read or write to
Non-conflicting transactions (those not touching the same accounts) can be processed simultaneously
Uses six parallel processing threads: four for regular transactions, two dedicated to vote transactions
Proof of History (PoH) Service
- Runs continuously as a dedicated service within each validator
- Creates a verifiable sequence of time using SHA256 hash chains
- Receives processed entries from the banking stage
- Combines current PoH hash with transaction entry hashes
- Serves as a cryptographic timestamp for transaction ordering
- Processes 12,500 hashes per block with ticks every 6.25 milliseconds
Broadcast
- Prepares processed transactions for distribution via Turbine
- Organizes transaction data for efficient network propagation
- Ensures blocks are ready for transmission to other validators
AccountsDB
- Maintains the global state of all accounts
- Structured as a vast key-value store where:
Keys are account addresses
Values are account data
- Stores account information both in memory and on disk
- Manages hundreds of millions of accounts efficiently
- Supports parallel transaction processing by allowing multiple non-conflicting account access
Turbine Stage
Turbine is Solana's innovative method for spreading blocks across the network, inspired by BitTorrent's approach to file sharing. After blocks are built, they need to be sent to all other validators in the network. Instead of the leader trying to send the complete block to everyone at once (which would require massive bandwidth), Turbine breaks down the block data into smaller pieces called "shreds" through a process called shredding. Think of these shreds like individual frames in a video stream - when put back together, they allow validators to replay the entire block.
To handle the inevitable reality of lost or dropped data packets over the internet, the Turbine uses a clever system called erasure coding. By default, it creates batches of 64 shreds - 32 data shreds and 32 recovery shreds. This means that even if up to half the shreds in a batch are lost, the block can still be reconstructed. The distribution of these shreds follows a tree-like structure where the leader initially sends to just one root node, which then forwards to other validators. Validators are organized into layers in this "Turbine Tree," with those having more stake typically positioned closer to the top. The tree usually spans two or three hops, and for security, the order is rotated with each new batch of shreds. This whole system helps reduce the strain on the leader and ensures efficient block propagation across the entire network, similar to how BitTorrent can quickly share large files among many users.
Block Verification Stage
During the Block Verification stage, validators who received the shreds from Turbine need to verify and process them to confirm the block's validity. This happens in the Transaction Validation Unit (TVU), which works similarly to the TPU used in block building. When shreds arrive, validators first check that they received enough shreds to reconstruct the block and verify the leader's signature to ensure the shreds came from the designated leader. Once verified, validators start rebuilding and replaying the entire block.
In the Replay Stage, which is the most important part of verification, validators recreate each transaction in the same order determined by the Proof of History timestamps. They update their local copy of the bank (their version of the current state) as they process each transaction. If everything checks out - meaning all transactions are valid and the block was built correctly - validators submit votes for that block. These votes are special transactions that cost a small fee (about 0.000005 SOL) and get included in future blocks. Solana uses a system called Tower BFT for consensus, which leverages the synchronized clock provided by Proof of History. This allows validators to agree on blocks with just one round of voting instead of the multiple rounds required by other blockchains. When a block receives enough votes from validators (a supermajority), it's considered confirmed, and after more blocks are built on top of it (specifically, 31 blocks), it becomes finalized. Once finalized, those changes to account states become permanent.
Consensus & Finality Stage
In Solana's consensus stage, the network uses a custom implementation of Practical Byzantine Fault Tolerance called Tower BFT (TBFT). Unlike traditional blockchain consensus which requires multiple rounds of communication between validators to agree on transaction order, Solana's validators can leverage their synchronized Proof of History clock to achieve consensus much more efficiently. Validators submit votes for blocks they believe are valid and should be part of the canonical chain, with each successful vote earning them a credit that counts towards their rewards.
When validators vote on blocks, they sometimes encounter competing versions of the chain called forks. These forks typically happen at the boundaries where leaders rotate, but unlike other blockchains, Solana can only have forks in a "there/not-there" pattern since only one leader can propose a block for each slot. When validators choose a fork, they're locked into that choice for a set period. A block is considered "confirmed" when it receives votes from a supermajority (more than two-thirds) of the network's stake weight. After 31 more blocks are built on top of it (taking about 12.4 seconds), the block becomes "finalized," meaning its transactions are permanently recorded and their effects on account states are irreversible. This finality mechanism has proven highly reliable - in Solana's history, no confirmed block has ever failed to reach finalization.
Solayer’s infiniSVM Infrastructure Solution
The Solana Virtual Machine (SVM) competes not only with other blockchain virtual machines but also with centralized computing and storage systems. While current CPU utilization averages around 30%, software optimization alone may not be sufficient for emerging decentralized applications in gaming, AI agents, Decentralized Physical Infrastructure Networks (DePINs), Real-World Assets (RWA), and decentralized social messaging. New acceleration methods, such as offloading tasks to FPGAs, are being explored but face network bandwidth constraints. The challenge lies in achieving low latency while managing peer-to-peer communications that can utilize up to 80% of network capacity, potentially causing instability on standard 1Gbps consumer networks.
Solayer's InfiniSVM approach addresses these challenges by scaling hardware capabilities through:
1. Implementing high-speed protocols like InfiniBand and Software-Defined Networking (SDN) switches
2. Introducing improved blockchain storage through data sharding
3. Decomposing non-sequential SVM operations into scalable microservices using NVMe over Fabric (NVMe-oF) Protocol
4. Using the Proof of Authority and Stake (PoAS) consensus protocol for transaction verification and finalization through sequencers
In this section, we explain the end-to-end transaction process in the InfiniSVM architecture, from initiation to finality. We'll examine the key components that enable Solayer's scalable approach:
- Proof of Authority and Stake (PoAS) consensus mechanism
- InfiniBand high-speed networking
- Microservices pipeline architecture
- Data sharding and shredding techniques
A transaction in the Solayer chain progresses through the following stages:
User-dApp Interaction Stage (Step 1)
When users want to interact with a dApp on Solayer Chain just like in a regular Solana dApp, they can use any Solana-compatible wallet as Solayer Chain employs a wallet-agnostic approach. The dApp creates the transaction using Solayer chain's SDK - this is where the transaction structure is formed, containing a recent block hash (for replay protection) but no chain-specific ID (unlike EVM chains). Since the Solayer Chain follows the SVM model, the dApp, not the wallet, is responsible for broadcasting the transaction. Once the transaction is ready, the dApp broadcasts it to Solayer Chain's network where it first reaches an ingress point. At this ingress point, the transaction enters the initial phase of Solayer Chain's microservices pipeline, where it will undergo signature verification and local deduplication before moving to the pre-execution cluster.
Solayer’s Micro Services System
Solayer uses microservices specifically for operations that don't require sequential processing or strict ordering - namely signature verification, deduplication, and storage operations. This decomposition allows these operations to be distributed across different nodes rather than being constrained to a single node like in Solana's monolithic architecture. The system achieves infinite scaling through dynamic resource provisioning - each microservice can be independently scaled based on demand using a feedback-driven control plane that monitors transaction ingress rates and automatically adjusts processing capacity. These microservices are primarily used in the initial transaction processing phase before reaching the sequencer, where transactions first hit an ingress point for signature verification and deduplication, and then move to pre-execution clusters that conduct speculative execution. The separation of these operations into microservices, while keeping sequential operations like scheduling and banking centralized with the sequencer, allows Solayer to optimize resource utilization and scale horizontally for non-sequential operations while maintaining strict ordering where needed.
Initial Transaction Processing Stage (Step 2)
When a transaction enters Solayer Chain's network, it first goes through the initial transaction processing stage - a distributed microservices architecture that handles non-sequential operations. Unlike traditional monolithic designs, these operations are decomposed and distributed across different nodes, enabling horizontal scaling through dynamic resource provisioning. The system leverages InfiniBand RDMA (Remote Direct Memory Access) for near-microsecond inter-node communication, enabling zero-copy data transfer directly between application memory spaces across network-connected systems. This high-speed communication backbone, capable of up to 100 Gb/s per port with ultra-low latencies (as low as 600 nanoseconds end-to-end), allows the microservices to efficiently share data and scale computational capacity across nodes without traditional networking overhead.
The first sub-process is the ingress point, which serves as the initial entry point for transactions. Here, incoming transactions undergo signature verification and local deduplication to ensure validity and uniqueness. The verified transactions are then routed to the pre-execution cluster. This ingress process can be independently scaled based on transaction volume to maintain efficient processing.
The second subprocess is the pre-execution cluster, where transactions undergo speculative execution to capture their effects and create intermediate execution snapshots. This cluster employs prediction models for hot accounts and can pre-execute transactions for multiple possible future states. The results are then sent to the sequencer via InfiniBand. This design enables parallel processing of non-conflicting transactions and can scale horizontally across nodes based on computational demands, efficiently using the system's distributed architecture.
Here's a breakdown of the process of initial transaction processing we broke down the process into two sub-phases:
Ingress Point
- Receives incoming transactions
- Performs signature verification
- Conducts local deduplication
- Routes verified transactions to pre-execution cluster
- Can be scaled independently based on transaction volume
Pre-execution Cluster
- Conducts speculative execution of transactions
- Captures transaction effects and intermediate execution snapshots
- Uses prediction models for hot accounts
- Can pre-execute transactions for multiple possible future states
- Sends results to sequencer via InfiniBand
- Enables parallel processing of non-conflicting transactions
- Scales horizontally across nodes based on computational needs
SDN Switch & Transaction Path Discovery
In Solayer Chain's architecture, the SDN (Software-defined Network) switch works in conjunction with InfiniBand to facilitate efficient transaction path discovery for the sequencer. When pre-executed transactions arrive at the sequencer via InfiniBand's ultra-low latency communication (achieving near-microsecond speeds), the SDN switch, along with an FPGA, analyzes the transaction state to determine its processing path. The switch maintains a local cache and leverages InfiniBand's RDMA capabilities for rapid state access, enabling it to quickly determine if a transaction can follow the simple path (where all transaction accounts are at their latest version during pre-execution) or must take the complex path (where at least one account has a newer version). For simple path transactions, the SDN switch can facilitate direct state changes through RDMA, while complex path transactions are routed to a local mempool for additional processing. This hardware-accelerated path discovery process, enhanced by the combination of SDN's programmable forwarding capabilities and InfiniBand's high-speed data transfer (up to 100 Gb/s), enables sub-millisecond decision-making for optimal transaction routing.
Transaction Sequencing Stage (Step 3)
In Solayer Chain's design, the Transaction Sequencing Stage begins once transactions have passed through the initial processing and the SDN switch has determined their paths. The sequencer, which serves as a centralized trusted entity, processes transactions differently based on their assigned paths. For simple path transactions, where all account versions match those during pre-execution, the sequencer can directly apply state changes through RDMA to the sharded database system without additional processing.
For complex path transactions, where at least one account has a newer version than during pre-execution, the sequencer routes them to a local mempool for additional processing. Here, the sequencer employs a transaction semantic-aware scheduling algorithm called Shortest Makespan First (SMF) to optimize parallel execution while maintaining serializability. The scheduling process analyzes the temporal ordering of read-write operations within transactions and constructs an optimized locking schedule that permits concurrent execution of transactions accessing the same accounts when their actual read-write sequences don't conflict.
The sequencer also utilizes a parallel scheduler ensemble that simultaneously explores multiple scheduling strategies to achieve optimal transaction throughput. This ensemble combines Solana's original account-based partitioning algorithms with the SMF algorithm, selecting the schedule with the lowest estimated time cost. Once the scheduling is determined, the sequencer coordinates the actual execution of transactions, managing state updates through the sharded database system and ensuring atomic state transitions are maintained throughout the process.
The sequencer maintains the ordering and consistency of transactions through this stage, preparing them for subsequent verification by provers. All state changes and transaction effects are carefully tracked and prepared for the provers to verify, ensuring the integrity of the blockchain's state transitions before they can be finalized.
Solayer’s Sharded Database System
When traditional blockchain systems face scalability challenges due to ever-growing state sizes (like Ethereum's 1.1TB+ state) or impose strict account size limits (like Solana's 10MB cap), Solayer Chain addresses this through its sharded database system. When the sequencer processes transactions (whether through simple or complex paths), it interacts with this distributed storage system. The system maps 32-byte account addresses to their corresponding state data using InfiniBand RDMA for ultra-fast cross-node access. Each database node in this system consists of three primary components: a memory-resident jump table that maintains mappings between account addresses and their details (memory addresses, data length, version number), a contiguous data region that stores the actual account state data along with synchronization metadata, and an in-memory local cache using LRU (Least Recently Used) policy for frequently accessed accounts.
The system utilizes InfiniBand RDMA to enable near-microsecond latency for data access across nodes, bypassing operating system overhead and enabling zero-copy data movement. This is particularly crucial during state updates, where the sequencer needs to quickly access and modify account states. For transactions following the simple path, state changes can be applied directly via RDMA, while complex path transactions may require more sophisticated state management through the local mempool. During state changes, the system observes that most modifications don't alter the account data length, allowing for efficient updates in contiguous memory. In rare cases where state size changes occur, the account data may temporarily be stored non-contiguously and later get redistributed to contiguous memory during routine rebalancing.
The system also features dynamic load balancing through a background rebalancing mechanism that monitors access patterns and redistributes data across nodes during low network activity periods to optimize locality and minimize cross-node data fetches. This load balancing process takes into account multiple factors including access frequency, data size, network topology, node capacity constraints, and current load distribution, ensuring that frequently co-accessed data resides on the same node to optimize performance. This comprehensive approach allows Solayer Chain to support arbitrary data sizes per account while maintaining efficient access and updates across its distributed architecture.
Transaction Verification and Consensus Stage (Step 4)
In Solayer Chain's verification and consensus stage, transactions undergo a unique hybrid verification process that combines elements of Proof-of-Authority and Proof-of-Stake. After the sequencer processes transactions and batches them into shreds, it employs a round-robin method to randomly select two-thirds of the online prover set for verification. These selected provers can further distribute their verification workload across their nodes - for instance, a prover with 10 nodes would only need to handle 1/15 of all shreds, with the ability to scale elastically using cloud resources to handle increased traffic.
During verification, each selected prover checks if their local ledger contains the correct account versions. If not, they request missing shreds from the leader to build the needed state. The provers then re-execute all transactions in the shred to derive the effect hash. If this locally computed hash matches the shred's embedded effect hash, the prover votes for acceptance on Solayer Chain. A shred requires votes from 51% of the selected provers to move forward, though the system is designed so that only 4/5 of selected provers need to vote, allowing for some downtime without disrupting the network.
The sequencer, upon receiving sufficient votes, assembles a proof for the shred and marks it as finalized, provided all previous shreds are also finalized. To ensure provers actively verify rather than passively accept shreds, the sequencer periodically broadcasts intentionally invalid shreds - any prover that blindly votes for these is automatically slashed and excluded from further rounds. For finality, only minimal data (Effect Hash, Shred Hash) is published to Solana for data availability, while the bulk transaction data remains within Solayer Chain. This hybrid approach allows the system to maintain high throughput while ensuring security through both active verification and economic incentives, with Solana serving as a security backstop.
Solayer's Proof-of-Authority-and-Stake (PoAS) Consensus Protocol
In Solayer chain's Proof-of-Authority-and-Stake system, verification begins with prover selection where the sequencer uses a round-robin method to randomly select two-thirds of the online prover set. These provers, who have staked $LAYER tokens to participate, can distribute their verification workload across their nodes for efficient processing. The provers receive both transaction fees and inflationary $LAYER rewards for their participation, but face tiered slashing penalties for malicious behavior or poor performance - starting with loss of epoch fees for first violations, 1% stake slash for second violations, and 5% stake slash for subsequent violations.
The voting process requires 51% of selected provers to vote positively on a shred for it to move toward finalization, though the system is designed to function with only 4/5 of selected provers voting to accommodate downtime. Provers verify transactions by re-executing them and comparing their computed effect hash with the sequencer's embedded hash. If discrepancies are detected between expected and computed effect hashes, honest provers vote against the shreds, which can lead to flagging the sequencer as malicious if repeated offenses occur.
When a sequencer is marked as offline due to malicious behavior or repeated offenses, this triggers a failover process that occurs on Solana. The re-election process involves selecting a new sequencer from a proof-of-authority set - a predefined group of backup sequencers. During this transition, Solayer Chain temporarily halts transaction processing while all honest provers participate in voting for the new sequencer. The re-election process requires a two-thirds majority vote from provers and can be completed in seconds if this threshold of honest provers is met. Once a new sequencer is elected from the authority set, the chain resumes normal operation under the new sequencer's leadership.
Transaction Finality and State Update Stage (Step 5)
In Solayer Chain's finality and state update stage, the process begins after a shred receives the required 51% of positive votes from the selected provers. The sequencer, upon collecting these votes, assembles a proof for the shred and can only mark it as finalized if all previous shreds have also been finalized, maintaining a consistent chain of state transitions. Once finalized, the sequencer posts minimal verification data to Solana - specifically the Effect Hash and Shred Hash pair - which serves as data availability proof while keeping the bulk of transaction data within Solayer Chain's network.
During this stage, the final state updates are applied to Solayer Chain's sharded database system through RDMA, ensuring ultra-fast and atomic state transitions. For transactions involving cross-chain operations through the bi-directional bridge with Solana, the system processes any MainnetCall instructions that were placed, which are user-defined logic registered to specific programs, automatically execute after their target programs update state, enabling automated actions like arbitrage, liquidations, or real-time account indexing. Throughout this process, the system maintains consistency through its sharded database while ensuring that all state updates are properly propagated across the network, completing the transaction lifecycle from initiation to final state commitment.
Solayer's Data Shredding System
In Solayer Chain's design, shreds represent batches of transactions processed by the sequencer. According to the paper, each shred contains several key components: a slot number, a vector of transactions, version metadata for accessed accounts, and linkage hashes (such as the last shred version). The inclusion of account versions in shreds is crucial as it provides the exact state context in which the sequencer executed the transactions, enabling any node receiving the shred to reconstruct the relevant portion of the ledger and compute the resulting "effect hash."
The reason Solayer provides both Effect Hash and Shred Hash to Solana is twofold. First, it serves as a minimal data availability proof without needing to post the entire transaction data on Solana, which would be prohibitively expensive and could saturate Solana's bandwidth. As noted in the Solayer infiniSVM paper, posting 1Gb worth of data on any data availability layer or L1 is cost-prohibitive. Second, these hashes serve as a security mechanism - the Effect Hash represents the cryptographic digest of post-transaction states, while the Shred Hash helps maintain the chain of shreds, allowing verification of the transaction sequence. This minimal data posting approach allows Solayer to leverage Solana's security while keeping most of the bulk data within its own network.
This shredding system also plays a crucial role in the prover verification process, where provers can request missing shreds from the leader to build up the needed state, enabling efficient verification without requiring constant synchronization of the entire state.
Additional Features on Solayer Chain
Solayer Chain enhances its network capabilities through several innovative features designed to meet the evolving needs of developers, traders, and users. These key implementations include:
Cross-chain contract Calls in Solayer Chain operate through two main mechanisms. First, a bi-directional native bridge in the sequencer handles messages and asset relays between Solana and Solayer. This bridge includes an insurance fund that covers potential losses from Solana reorganizations, allowing immediate asset availability when the transfer value is within the insurance coverage. Second, Solayer implements account mirroring, where each Solayer program and account has a corresponding PDA on Solana's mainnet. The MainnetCall instruction type enables atomic cross-chain operations by routing instructions to these mirrored PDAs. Importantly, MainnetCall instructions can only appear at the end of transactions to maintain consistency even during Solana reorganizations.
Hooks in Solayer Chain function as an automated "back-running" mechanism that executes user-defined logic immediately after specific program interactions. They work similarly to regular transactions - users provide accounts and data, and gas is charged from a designated account. Hook registration operates through a precompile that manages a Dutch-auction-like bidding system, where the top 16 bids per program are eligible for execution in the following epoch. When a transaction touches multiple programs with registered hooks, only the top 16 hooks by bid amount are executed. The bidding rewards are split: 40% to the transaction initiator, 40% to the program owner, and 20% to the network.
Jumbo Transactions are Solayer's solution for complex transaction logic, particularly useful for hook transactions. These transactions significantly increase the standard transaction size limit, allowing for more cross-program invocations and account interactions within a single transaction. The fee structure for jumbo transactions is designed to scale exponentially with size to prevent network abuse. This feature enables users to read and write thousands of accounts, execute numerous instructions, or deploy multiple programs in one atomic transaction.
ZK-Login in Solayer Chain enables users to use their existing OAuth accounts (Google, X, Reddit, etc.) as blockchain wallets. The implementation follows a similar approach to Sui's zkLogin, using zero-knowledge proofs to verify OAuth credentials without exposing sensitive information. This makes blockchain interactions more accessible to mainstream users by allowing them to use familiar authentication methods while maintaining security and privacy. The system verifies the user's identity through the OAuth provider and creates corresponding blockchain credentials that can be used to sign transactions.
Comparative Analysis Between SVM and infiniSVM
In this comparative analysis, we examine Solana's SVM and Solayer Chain's InfiniSVM through six critical dimensions: core architecture, which addresses their fundamental design principles and state management approaches; performance characteristics, focusing on throughput, latency, and hardware requirements; technical innovations, highlighting key technological advancements; consensus and security mechanisms used by both systems; infrastructure integration capabilities; and developer experience features. These key areas provide a comprehensive framework for understanding how InfiniSVM builds upon and enhances the original SVM design while maintaining compatibility with the Solana ecosystem.
Core Architecture
Performance Characteristics
Technical Innovation
Consensus and Security
Infrastructural Integrations
Developer Experience
Conclusions
Solayer Chain's InfiniSVM represents a scalable evolution of Solana's SVM, achieved through architectural innovations in three key areas: distribution, acceleration, and enhancement. It distributes the traditional monolithic SVM across specialized microservices and hardware accelerators while maintaining atomic state transitions through RDMA and sophisticated scheduling. It accelerates performance through FPGA hardware, speculative execution, and semantic-aware transaction scheduling. Finally, it enhances the development experience with features like hooks, jumbo transactions, and OAuth support. This design allows InfiniSVM to theoretically scale beyond SVM's current limitations while maintaining full compatibility with existing Solana infrastructure, effectively serving as a scalable superset of SVM's capabilities.
References
Brian. (2021, December). What is InfiniBand Network and the Difference with Ethernet? Fibermall.com. https://www.fibermall.com/blog/what-is-infiniband-network-and-difference-with-ethernet.htm?
Celerdata. (2024, September 3). Multi-Version Concurrency Control. Celerdata.com; CelerData Inc. https://celerdata.com/glossary/multi-version-concurrency-control
Cheng, A., Kabcenell, A., Chan, J., Shi, X., Bailis, P., Crooks, N., & Stoica, I. (2024). Towards Optimal Transaction Scheduling. Proceedings of the VLDB Endowment, 17(11), 2694–2707. https://doi.org/10.14778/3681954.3681956
Coinmerce.io. (2025). What is Proof of Participation (PoP)? Coinmerce.io. https://coinmerce.io/en/learn/what-is-proof-of-participation/
Docudavit. (2023). Top Benefits & Features of Document Management Solutions for Medical Practices - Docudavit. Docudavit. https://doi.org/1056748431/FSAlCJyQw3sQj-fy9wM
Dr. Ravi Chamria. (2024, March 20). How Shared Sequencers could ensure better decentralization in L2 rollups? Zeeve. https://www.zeeve.io/blog/how-shared-sequencers-could-ensure-better-decentralization-in-l2-rollups/
Ebunker. (2023, July 14). Unveiling Sequencers: The Key to Ensuring Transaction Authenticity. Medium. https://medium.com/@ebunker.io/unveiling-sequencers-the-key-to-ensuring-transaction-authenticity-828267edbc2c
Fauna. (2021, April 14). What exactly is a key-value store? Fauna. https://fauna.com/blog/what-exactly-is-a-key-value-store
Frankenfield, J. (2019). Hash Definition. Investopedia. https://www.investopedia.com/terms/h/hash.asp
Geeksforgeeks. (2020, June 1). Remote Direct Memory Access (RDMA). GeeksforGeeks. https://www.geeksforgeeks.org/remote-direct-memory-access-rdma/
Getblock. (2020, October 8). How Does Webhook Work on Blockchain. GetBlock.io; Getblock. https://getblock.io/blog/how-does-webhook-work-on-blockchain/
Harvey. (2023, November 3). Understanding the Power of zkLogin in Sui Ecosystem. Suipiens. https://suipiens.com/blog/understanding-the-power-of-zklogin-in-sui-ecosystem/
How.dev. (2015). Multiversion Concurrency Control (MVCC). Educative. https://how.dev/answers/multiversion-concurrency-control-mvcc
Howard. (2024, March 8). InfiniBand, What Exactly Is It? FS.com; FS. https://www.fs.com/blog/infiniband-what-exactly-is-it-7714.html
IBM. (2023, October 23). NVMe. Ibm.com. https://www.ibm.com/think/topics/nvme
Kasireddy, P. (2018, February 19). What do we mean by “blockchains are trustless”? Preethikasireddy.com. https://www.preethikasireddy.com/post/what-do-we-mean-by-blockchains-are-trustless
Lark Editorial Team. (2024). NP Hardness Problem. Larksuite.com. https://www.larksuite.com/en_us/topics/ai-glossary/np-hard-definition-of-np-hardness
LCX Team. (2023, September 7). Chain Reorganization in Blockchain Technology. LCX. https://www.lcx.com/chain-reorganization-in-blockchain-technology/
Lepcha, M. (2023, November 16). Rollup. Techopedia. https://www.techopedia.com/definition/rollup
Li, J., Shou, C., Su, Q., Cui, C., & Ke, T. (2025, January 7). SOLAYER CHAIN: Infinitely Scalable Hardware-Accelerated SVM Network. Https://Whitepaper-101797961016.Us-Central1.Run.app/Variants/Solayer_infinisvm_78347264.Pdf.
Lopez, A. J. (2020, June 2). Building a Blockchain: Key Value Stores - Angel Java Lopez - Medium. Medium. https://angeljavalopez.medium.com/building-a-blockchain-key-value-stores-5103f1052dc4
Lostin. (2024, December 3). Solana Executive Overview. Helius. https://www.helius.dev/blog/solana-executive-overview
Malynka, D. (2024, November 7). RDMA: A Deep Dive into Remote Direct Memory Access. StarWind Blog. https://www.starwindsoftware.com/blog/rdma-a-deep-dive-into-remote-direct-memory-access/
Metaplex Foundation . (2024). Understanding Solana Program Derived Addresses | Guides. Metaplex.com. https://developers.metaplex.com/guides/understanding-pdas
Micheli, D. D. (2023, January 4). Blockchain Bridge: What is it, and what is it for? Scaling Parrots. https://www.scalingparrots.com/en/blockchain-bridge-what-is-it/
Moris. (2021, February 17). Unveil the Myths About SDN Switch | FS Community. Knowledge. https://community.fs.com/article/unveil-the-myths-about-sdn-switches.html
Nebius Team. (2024, June 18). InfiniBand in focus: bandwidth, speeds and high-performance networking. Nebius.com. https://nebius.com/blog/posts/what-is-infiniband
NetApp. (n.d.). What Is NVMe? - Benefits & Use Cases | NetApp. Www.netapp.com. https://www.netapp.com/data-storage/nvme/what-is-nvme/
Nightingale, C. (2024, May 20). A Guide Understanding Blockchain Rollups: ZK vs Optimistic Rollups. Cyfrin.io. https://www.cyfrin.io/blog/what-are-blockchain-rollups-a-full-guide-to-zk-and-optimistic-rollups
Pan, P., Chen, G., Wang, X., Dai, H., Li, B., Fu, B., & Tan, K. (2019). Towards Stateless RNIC for Data Center Networks. APNet ’19: Proceedings of the 3rd Asia-Pacific Workshop on Networking, 57–63. https://doi.org/10.1145/3343180.3343183
Purestorage. (2024). What Is NVMe Storage? | Pure Storage. Www.purestorage.com. https://www.purestorage.com/knowledge/what-is-nvme.html
Purestorage . (n.d.). What Is NVMe over Fabric (NVMe-oF)? | Pure Storage. Www.purestorage.com. https://www.purestorage.com/knowledge/what-is-nvme-over-fabrics-nvme-of.html
QuickNode . (2024a, September 18). Introduction to Ethereum Rollups | QuickNode Guides. Quicknode.com. https://www.quicknode.com/guides/custom-chains/introduction-to-ethereum-rollups
QuickNode . (2024b, December 27). Getting Started with Key-Value Store | QuickNode Docs. Quicknode.com. https://www.quicknode.com/docs/key-value-store/getting-started
Radecky, S. (2025). What is an FPGA? | Uses, Applications & Advantages – Digilent Blog. Digilent.com. https://digilent.com/blog/what-is-an-fpga/?srsltid=AfmBOopogDaaruyJC0xcru49P8ZDgIpizVyiY6xzqcKnDTM8A90PRuL-
Robinson, B. (2020, March 9). Crypto shredding: How it can solve modern data retention challenges. Medium. https://medium.com/@brentrobinson5/crypto-shredding-how-it-can-solve-modern-data-retention-challenges-da874b01745b
Scaling Parrots. (2023, July 18). Blockchain Hash: what is it and what is it for. Scaling Parrots. https://www.scalingparrots.com/en/blockchain-hash-what-is-it/
Schneider, J., & Smalley, I. (2024, May 10). What is a field programmable gate array (FPGA)? | IBM. Www.ibm.com; IBM. https://www.ibm.com/think/topics/field-programmable-gate-arrays
Sheldon , R., & Silwa, C. (2021, November). What is a host bus adapter (HBA)? An introduction. Storage. https://www.techtarget.com/searchstorage/definition/host-bus-adapter
Sheldon, R. (2024, November 7). What Is Remote Direct Memory Access (RDMA) Networking and How Does It Work? SearchStorage. https://www.techtarget.com/searchstorage/definition/Remote-Direct-Memory-Access
Solana Foundation . (2025). Program Derived Address (PDA). Solana.com. https://solana.com/docs/core/pda
SolarWinds. (2019, December 15). Holt-Winters Forecasting Simplified. Orange Matter. https://orangematter.solarwinds.com/2019/12/15/holt-winters-forecasting-simplified/
Solayer. (2024). Transaction Semantic Aware Scheduling - Solayer Docs V2. Solayer.org; Solayer Docs V2. https://docs.solayer.org/infinisvm/system_architecture/multi-executor/transaction_semantic_aware_scheduling
Solayer . (2024). infiniSVM Docs. Solayer.org; Solayer Docs V2. https://docs.solayer.org/infinisvm/infinisvm/overview
Stevens, R. (2022, August 18). What Are Rollups? ZK Rollups and Optimistic Rollups Explained. CoinDesk. https://www.coindesk.com/learn/what-are-rollups-zk-rollups-and-optimistic-rollups-explained
StidySmarter. (2023, March 26). NP Hard Problems: Solving, Examples, Lists | StudySmarter. StudySmarter UK. https://www.studysmarter.co.uk/explanations/computer-science/theory-of-computation/np-hard-problems/
Sui Foundation. (2023, October 10). zkLogin Demystified: Exploring Sui’s Cutting-Edge Authentication. The Sui Blog. https://blog.sui.io/zklogin-deep-dive/
Team Crypto APIs. (2022, April 14). Webhooks: Push Notifications for Blockchain Events. Cryptoapis.io. https://cryptoapis.io/blog/6-webhooks-push-notifications-for-blockchain-events
tier1. (2023, April 13). The Difference Between Data Shredding & Data Sanitisation? | tier1. Tier1. https://www.tier1.com/whats-the-difference-between-data-shredding-data-sanitisation/
Todorov, P. (2023, January 23). What is a Program Derived Address (PDA)? Alchemy. https://www.alchemy.com/overviews/program-derived-address
Twain, E. (2017, October 3). SDN Switch Vs. Non-SDN Switch. Medium. https://medium.com/@bilby_yang/sdn-switch-vs-non-sdn-switch-49decc32650
Vovchuk, A. (2024, January 25). What Is NVMe over Fabrics (NVMe-oF)? Benefits & Use Cases. StarWind Blog. https://www.starwindsoftware.com/blog/what-is-nvme-of-nvme-over-fabrics/
Watts, J. (2024, January 19). What Are Layer 2 Sequencers? The Ultimate Guide. Jarrod Watts. https://blog.jarrodwatts.com/the-ultimate-guide-to-sequencers-in-l2-blockchains
Werkheiser, B. (2022, June 21). What is a reorg? Alchemy. https://www.alchemy.com/overviews/what-is-a-reorg
Weston, G. (2022, October 14). What are Blockchain Bridges and How Do They Work? 101 Blockchains. https://101blockchains.com/blockchain-bridges/
Yakovenko, A. (2017). Solana: A new architecture for a high performance blockchain v0.8.13. https://solana.com/solana-whitepaper.pdf