We have witnessed a tremendous amount of computational power becoming widely available, spurred to a large extent by the needs of LLM training and inference. Blockchain as a field has thus far not benefited from the availability of hardware such as new powerful GPUs and various other hardware acceleration techniques, such as FPGAs, SmartNICs, etc. At Eclipse, we are aiming to correct this oversight: these high-performance computing devices utilized effectively could increase the amount of computation the blockchain makes available by orders of magnitude, something we refer to as GigaCompute.
The Eclipse Performance Thesis focuses on building the most performant SVM Layer-2 blockchain with a new SVM client we call GSVM through a combination of software-hardware co-design, cross-layer optimizations, workload non-interference, and dynamic scaling, leveraging the unique freedoms of an L2 to depart from the typical L1 design constraints. Moreover, as an optimistic rollup, Eclipse can take advantage of the significant additional compute capacity without being unduly limited by the speed and cost of zero-knowledge proof generation.
Eclipse argues that co-designing software and hardware is crucial for modern blockchains, taking advantage of the unique position of Eclipse as an L2 to overcome the limitations of off-the-shelf hardware. Cross-layer optimizations across networking, runtime, and storage parts of the transaction execution stack, such as pre-fetching account data in storage at the time of transaction sequencing, are essential for latency reduction. The design of GSVM aims to deliver application workload non-interference and dynamic scaling to meet growing application demands.
We highlight that Eclipse’s position as a Layer-2 is fundamentally different in terms of performance constraints from Layer-1 blockchains, which tend to rely on generic hardware and prioritize optimizing consensus over transaction execution efficiency. Eclipse addresses these limitations by separating security from performance through the fraud proof mechanism, and then shifting its focus for GSVM onto validator performance.
To realize the vision of what we call GigaCompute in GSVM, Eclipse points out that while TPS is widely used it is ultimately a flawed metric, advocating for the extension of Compute Units (CUs) to account for concurrency, computational co-processors such as GPUs, and to discourage locking patterns that hinder GSVM’s design principles. Component-specific design principles include:
- Network: near line-speed processing, probabilistic execution pre-confirmations, performance-based sequencing, application-specific sequencing, and latency-optimized transaction routing.
- Runtime: self-improving runtime using reinforcement learning, computational abstraction, hybrid concurrency for resource non-interference, and hotspot-aware hardware affine scheduler.
- Database: disk access-minimizing sequencer-driven caching, hotspot-aware parallel NVMe array, hardware-accelerated SSD-aligned accounts database, and fast state commitments for light clients.
An analysis of state contention in Solana highlights some of the shortcomings of the current concurrency model. Longer-term, better concurrency for modern hardware requires exploring more parallel-friendly scheduling and data formats.
Lastly, the thesis outlines how three application domains can benefit from the extra processing capacity of the GSVM: AI, Gaming, and DePIN. In the long run, all three domains require large-scale compute and efficient concurrency, precisely what GSVM’s GigaCompute ambitions aim to deliver.
Looking forward, Eclipse aims to prototype many of these approaches, validating real-world HPC-level throughput and light-client support for next-gen L2 blockchains.
Read The Eclipse Performance Thesis in its entirety on GitHub.