| The WhitePaper Reading Club Singapore [26] | 11 Feb 2025 |
|---|---|
| Solayer - Hardware Accelerated SVM | |
| Hardware innovation or VC mumbo jumbo |
Summary
A Chain that scales a single, global state machine through hardware acceleration, microservices, and RDMA-based networking, achieving 1M+ transactions per second.
Background
Blockchain scalability faces bottlenecks in throughput, latency, and state management. Rollups and sharding fragment composability, while monolithic chains hit hardware limits. Existing Solutions: (i) Ethereum L2s (Optimistic & ZK Rollups): Improve throughput but fragment state, making atomic swaps and composability difficult. (ii) Solana (SVM): Uses parallel execution but hardware scaling reaches bottlenecks due to CPU and RAM constraints. (iii) Modular Chains (Celestia, EigenLayer): Offload data availability and execution but increase complexity in cross-chain coordination.
Market & Industry Need
(i) DeFi applications require atomic transactions across large liquidity pools. (ii) High-throughput apps (NFTs, GameFi) need low fees & fast finality. (iii) AI & on-chain data services need scalable storage & processing.
Historical Evolution
Bitcoin → Ethereum (Smart Contracts) → Solana (Parallel Execution) → SOLAYER (Hardware-accelerated atomic scaling).
Key Innovation
Using InfiniBand RDMA (Remote Direct Memory Access, a technology that enables ultra-fast communication between servers without CPU interference), FPGA (Field-Programmable Gate Arrays, reconfigurable hardware used for task-specific acceleration) acceleration, and speculative execution (running transactions in advance based on predictions to save time), it achieves low-latency (minimal time delay), high-performance blockchain processing beyond Solana’s software-optimized limits. Its hybrid PoA+PoS (Proof-of-Authority combined with Proof-of-Stake, where both trusted entities and staked validators secure the network) ensures fast finalization while preventing centralization, and native MEV-resistant (Miner Extractable Value, strategies to protect users from unfair transaction manipulation) Hooks reduce exploitative trading. With Solana compatibility (able to support applications built on the Solana network), built-in cross-chain calls (direct interactions between contracts on different networks), and support for AI compute (on-chain execution of artificial intelligence tasks), SOLAYER CHAIN sets a new standard for high-throughput decentralized applications (apps running on blockchain infrastructure).
| Feature | Solana (Sealevel) | SOLAYER CHAIN (Multi-Executor) |
|---|---|---|
| Parallel Execution | Yes, but limited to transactions that do not modify the same accounts. | Yes, with additional pre-execution and speculative execution to reduce conflicts. |
| Conflict Resolution | Transactions declare account access upfront, preventing conflicts but sometimes leading to delays. | Uses predictive execution to estimate outcomes and reduce re-execution. |
| Transaction Scheduling | Executes transactions based on declared read/write dependencies. | Uses dynamic scheduling to optimize execution order and avoid bottlenecks. |
| Hardware Acceleration | Relies on high-performance CPUs for execution. | Uses FPGA/GPU acceleration to offload intensive processing. |
| State Storage | Validators must store and manage large state data in memory. | Uses RDMA & shared-nothing sharded storage to scale efficiently. |
Current Status
Research & Development phase. No real-world deployment yet.
Team
Solayer is an advanced restaking protocol built on Solana, enhancing network bandwidth and Layer 1 security. The project is led by Rachel Chu and Jason Li, with Ryan Clark overseeing strategy and growth. In August 2024, Solayer raised $12M in a seed round led by Polychain Capital, with participation from Binance Labs, Hack VC, and Nomad Capital. UC Berkeley has driven distributed systems and database innovation: Apache Spark (AMPLab), Ray (RISELab), and Anna (autoscaling key-value store)—core to Web3 scalability. Blockchain projects like Oasis Labs (privacy) and StarkWare (ZK-rollups) stem from Berkeley’s research. DataBrick
Opinions
(To be added)
Scaling Transaction Architecture
| Microservices-Piepline | Unlike Solana’s monolithic transaction pipeline, SOLAYER CHAIN decomposes execution into independent microservices (signature verification, deduplication, storage), allowing dynamic scaling based on transaction load. (ii) Speculative Execution & Pre-Processing for Efficiency: Transactions are pre-executed before finalization, reducing conflicts and eliminating unnecessary re-execution. Only 2% of transactions need to be retried, even under heavy load (under test). (iii) Predictive Modeling for Conflict Reduction: For high-traffic accounts, predictive models estimate future values, allowing transactions to be simulated across multiple possible states, significantly reducing bottlenecks in execution.Questions: Dirty reads? |
|---|---|
| Transaction Semantic Aware Scheduling | (i) Optimized Parallel Execution: Unlike Solana’s batch-based scheduling, SOLAYER CHAIN predicts transaction sequences to allow more concurrent execution, reducing unnecessary locking. (ii) Dynamic Scheduling: Uses simulated execution traces to determine the best order for transactions, minimizing conflicts while ensuring correctness. (iii) Fast & Adaptive Scheduling: Implements Shortest Makespan First (SMF) algorithm alongside multiple scheduling strategies, selecting the most efficient in sub-millisecond time. Questions: How does simulation work? Won’t there be huge amounts of over head? How can you simulate for less energy and content? Note: goal is to find a lock free schedule, but lock is still used during execution as the schedule is based on estimation. |
| Sharding Database with RDMA | (i) Scalable State Storage: Unlike Solana’s 10MB per-account limit, SOLAYER CHAIN supports arbitrary data sizes per account using a distributed key-value store to manage blockchain state efficiently. (ii) RDMA-Accelerated Data Access: Uses InfiniBand RDMA for ultra-fast, direct memory access between nodes, bypassing traditional bottlenecks and reducing CPU overhead. (iii) Dynamic Load Balancing: Continuously rebalances data across nodes based on access patterns, ensuring frequently used accounts stay local and reducing cross-node latency. Note: Generally around efficient caching and data-transfer between CPU and memories? |
| Scaling Consensus | (i) Efficient Data Verification with Hybrid Consensus: Uses a Proof-of-Authority-and-Stake (PoA + PoS) model, where a (trusted) sequencer batches transactions, and staked validators (provers) verify them, reducing reliance on expensive L1 verification. Questions: How does the replacement for this sequencer work?(ii) Shredded Transactions & Effect Hashing – Transactions are broken into shreds with embedded state versioning, allowing fast reconstruction and validation while minimizing on-chain data load. (iii) Fraud Prevention & Censorship Resistance: Malicious sequencers are detected via effect hash mismatches, triggering automatic failover to backup sequencers and slashing dishonest provers. (iv) Scalable Validation with Load Distributiob:– Randomized round-robin prover selection ensures equitable workload distribution, allowing validators to scale via cloud infrastructure while maintaining decentralization. |
References
Whitepaper: https://github.com/solayer-labs/solayer-improvement-proposal/blob/main/solayer_infinisvm_litepaper.pdf
Solana: https://github.com/solana-labs/whitepaper/blob/master/solana-whitepaper-en.pdf
Notes
Let me provide concise summaries for each major point:
TPS: (i) Raw TPS numbers misleading - need context (i) Visa: 4K peak vs 1K reality as Failed tx and retries inflate numbers (iii) Chain comparisons complex due to different tx types (iv) Multiple operations within single tx
Prediction System (i) Winter-Holt DESP model for byte-level account prediction (ii) Pre-execution simulation with variable account data (ii) Prediction reduces required account locks vs Solana approach (iii) Similar to transaction prediction scoring for fraud detection
Technical Architecture: (i) NP-hard scheduling solved via greedy algorithm to distribute tasks (ii) Background rebalancing across shards using LRU (iii) Trade-off between storage and caching optimization
Centralization: (i) Increased centralization concerns: ASIC/FPGA + InfiniBand requirements
Project Assessment (i) Multiple small innovations vs single breakthrough + too many jargons. (ii) L2 implementation or L1 (iii) FPV improvements attractive to Solana ecosystem - as it increase price of Sol (iv) Single global highway insufficient for congestion - distributed approach needed
Real Applications: (i) Solayer primarily targets GameFi narrative? (ii) Existing Solana project docus on ticketing industry disruption / Potential Ticketmaster competitors
Each section highlights key concepts while maintaining technical accuracy. Would you like me to expand on any particular section?