At Eclipse, we are committed to building the most performant and cost-effective SVM-based chain possible. This aligns with our concept of GigaCompute—our term for the vastly increased computational capacity we plan to deliver on Eclipse.

This is the first in a series of blog posts about performance. In the following sections and future posts, we'll explore all aspects of SVM technology. Our primary focus is introducing GigaCompute—a concept we first outlined in our roadmap—and explaining how we're using it to build GSVM (GigaCompute SVM), our faster, more efficient Solana client specifically designed for the L2 context.

Platform-level performance improvements create a powerful cycle of innovation and adoption. Developers can build more sophisticated and computationally intensive applications that were previously impractical, while users benefit from better experiences, faster response times, and reduced transaction fees.

For instance, the growing demand for on-chain AI agents and complex computational tasks creates drastically expanded requirements for blockchain computational capacity, pushing the boundaries of what can be processed on-chain. AI agents that can run their computation such as training or re-training of trustless models on-chain, combined with the autonomy that comes from transaction on-chain create a potent mix. One of the the reasons that you do not see blockchains executing server-side game logic or extensive amounts of storing player data is because it is too expensive for even low-gas chains, or because the latency is too high.

These emerging use cases and enhanced capabilities naturally attract a broader user base to the ecosystem, which in turn provides stronger incentives for developers to continue innovating and expanding the technical frontiers of blockchain technology, representing one of the most significant opportunities we've identified at Eclipse.

This virtuous cycle for us culminates in the development of GSVM, a more sophisticated, adaptable, and universally accessible blockchain infrastructure, one that's specifically engineered to support and facilitate an ever-expanding array of increasingly complex and computationally intensive use cases.

The Inaugural Memecoin Incident

The inauguration of the 47th president of the United States marked several unprecedented developments for the Solana blockchain ecosystem. Trump, leveraging his extensive social media presence and understanding of digital engagement, made the notable decision to mint his own meme token. The cryptocurrency was specifically created on the Solana blockchain platform, utilizing the sophisticated Meteora DLMM (Dynamic Liquidity Market Maker) protocol for its initial distribution and trading mechanisms.

As can be seen in Figure 1, the token's launch triggered a remarkable series of market movements characterized by extreme volatility. Multiple contributing factors led to an extraordinary surge in price, which was followed by a dramatic and precipitous decline - the token's value experienced a stunning roller-coaster ride, climbing to almost 80 USD before plummeting to approximately 32 USD within a matter of minutes. The trading frenzy surrounding this event catapulted Moonshot, the primary platform facilitating the purchase of TRUMP tokens, to unprecedented popularity.

The platform experienced a massive influx of new users, with 400,000 individuals joining specifically to participate in this trading phenomenon. Such was the intensity of interest that Moonshot achieved a remarkable milestone, temporarily securing the position of most downloaded financial application on the Apple App Store.

This memecoin launch and subsequent trading activity set a number of records:

• The Real Economic Value (REV) of Solana reached its highest value to date.
• The number of active and returning users on Solana grew by a significant margin (Figure 2).
• The stablecoin liquidity, i.e. the amount of real money that is attached to stablecoins  grew at the highest pace to date (Figure 3).

However, the incident lead to some serious drawbacks. As TRUMP and MELANIA tokens gained popularity on Solana, the SOL price fell, which triggered arbitrage bots to flood the main network with transactions, resulting in what is effectively a cascading failure.

The resulting network congestion had severe consequences. The median priority fees surged 5,000x, non-vote transaction count dropped 66%, and compute units per block decreased 50%. Paradoxically, instead of scaling up to meet demand, the network operated at half its normal productivity.

This, of course, created a poor first impression for nearly half a million new Solana users. However, similar incidents have occurred on both Solana and other chains during inscription-related surges.

Where Did All the Parallelism Go?

How this all came about has a deceptively simple explanation. Anza, the spiritual successor of the Solana foundation have identified that the embarrassingly-parallel agave validator is not parallel enough in practice. As you can see in the figure below, the non-vote transaction-processing threads, the ones that actually execute transactions, are mostly idle, not exactly what we’d want expect to happen.

Our own smaller-scale internal investigation into parallelism has confirmed these findings and revealed that the newer DAG scheduler struggles to fully utilize worker threads. While Solana remains an impressive piece of engineering, much of its potential remains untapped when it comes to parallelism.

We are continuing this analysis as we speak: we have identified the top most contentious programs on Solana, and we have analysed their concurrency logic to a significant extent. Our preliminary results, which we intend to refine and publicise, indicate that the problem lies in the gap between state that is potentially contentious, and state that practically cannot be written to from different threads. Solving this problem is not simple, in fact we’re unsure it can be solved in a general enough case, while retaining backwards compatibility with mainstream Solana.

One possibility is to fix the apps themselves; for example, one could rewrite DLMM programs to be multithreaded with fine-grained locking of state. While risky, if done right, this will eliminate contention.

Why GigaCompute?

The standard metrics—TPS, latency, and gas—remain vital, but they tell only part of the story. For users, consistent and predictable latency often matters more than raw throughput — one of the reasons to make pre-confirmation part of many rollup designs. Traditional metrics fall short: gas costs do not reflect mempool waiting times, and TPS figures can be quite misleading when they disregard transaction complexity or real-world network conditions. Performance metrics must directly more directly reflect user experience.

TPS?

Talking about just TPS can be misleading. Even so, one should talk about things like steady state TPS, and percentiles under load. We do not. We also forget about latency in such contexts. The reality is, that during the $TRUMP memecoin incident, the average and the 99th percentile latency told two very different stories. More importantly, while the latency of the transactions is indicated that the average case took longer to process, it did not reflect the sheer magnitude of the price one needs to pay to get included. A good metric would reflect that fact.

This hints at another issue. The problem with $TRUMP was not purely related to software performance. If SOL hadn’t dropped, the arbitrage bots would not have initiated the trades, and there would be 50,000-100,000 fewer transactions per second to process. At the end of the day, all the user will see is a working system, it doesn’t matter if the stability is the result of clever coding or clever design.

We are not alone in this thinking. Optimism and Monad, both have argued that TPS is not an optimal metric for measuring validator performance. We advocate for a holistic approach, where performance under stress is measured separately from steady state throughput. Each stage has an optimal metric,

On-chain Compute

Lets consider how much computation is actually done on chain. At the present moment it is actually surprisingly little. Running game play logic on-chain is fairly uncommon; most Web 3 games use the blockchain to record player information: what kinds of NFTs they own, how far they have progressed and what they have achieved. But as far as we know, no project, not even Multisynq, uses Solana for anything more ambitious.

A key reason is that most blockchains offer a minuscule amount of useful computation per block.

Indeed, as of writing, each Solana block is limited to 48 million CUs. Pending SIMD 0207 maybe some increases will follow, but even so, consider the scale of this number. Solana can handle up to 100k transactions in that time, and would produce five blocks, so the overall budget per transaction is 2400 CUs per transaction. That’s not enough to convert your account’s address into a human readable form, known as base58. If you preserved the intermediate computations it would take you approximately five seconds to do that once. To put that into perspective, when you open SolScan on your iPhone, that operation is done in less than 16 milliseconds, so the blockchain is approximately 32 thousand times slower than your iPhone.

// 11962 CU !!
compute_fn! { "Log a pubkey to account info" =>
    msg!("A string {0}", ctx.accounts.counter.to_account_info().key());
}

‍Raising CU limits, making blocks larger, or reducing block times have all been proposed both in the Solana context and elsewhere. However, while these measures may provide a certain level of improved user experience, fundamentally, our aim at Eclipse is to make more compute available.

Designing Eclipse for Performance

Below we list three principles we will be using to bring the best level of performance to GSVM, Eclipse’s blockchain client for the SVM.

1. Profile-Guided Optimizations

Profile-guided Optimizations refer to a set of techniques used in compiler design and performance tuning, where the optimization process is guided by data collected from profiling the application's runtime behavior. Profiling involves gathering detailed information about how the program executes, such as which functions are called most frequently, which branches are taken, and where the majority of execution time is spent.

One specific principle for GSVM is specializing execution for frequently-occurring patterns, optimizing for the hot path, so to speak. This may be used to decide which functions to JIT and which to interpret, for instance.

We identified that the batching pattern in the new DAG is similar to what was described by Faleiro et al [1]. Specifically we found that because the effects of applying a batch can only be visible in a later batch, that we can leverage the innovation of finer-grained locking to allow earlier visibility and thus execute more per batch.

This also means that we can apply simple transactions earlier. Approximately 25% of transactions do not require more than the regular SPL token and a few system programs. In effect, they can be pre-applied before they even reach the OS, using specialised hardware [9].

2. Self-Improving Runtime

One key advantage of blockchain runtimes is that their workloads are easily observable. This makes it straightforward to build predictive models for upcoming transaction patterns and adjust the runtime accordingly. This aligns well with the ideas of reinforcement learning. We can train predictors on months worth of data and update them as workloads change.

GSVM aims to continuously adapt to changing workloads by analyzing transaction patterns and adjusting execution parameters in real-time. As the system processes more workloads, it records runtime performance. Machine learning models update with each execution, creating a self-improving runtime system. This is a specific case of what’s called feedback-directed optimizations in runtimes and VMs.

These principles of continuous improvement apply to caching, pre-execution, contention resolution, and transaction reordering, to name just a few areas of optimization [2, 3, 8].

3. Hardware-Software Co-design

In an L1, which needs decentralisation for security and censorship resistance, usually only specify capacity requirements for the underlying hardware, such as the about of RAM and disk storage. The situation is radically different for a rollup such as Eclipse—so long as our “security measures” such as chain derivation and fraud proofs work, we can build a very specialized GSVM client.

Below we list some example of software-hardware co-design and the improvements it can bring.

• We can use GPUs to accelerate the database operations in Solana [7], as an L2, we can leverage greater computational power.
• Modern FPGAs (Field Programmable Gate Arrays) can reduce latency of specific computations, such as signature verification operations [5, 6]. There’s promising work on packet capture as well [4].
• Specialised key-value stores with hardware support, including custom memory hierarchies and dedicated near-data processing units [9, 10], can significantly reduce the latency of account database operations by minimising data access times and optimising storage patterns.

Our goal is to strike the optimal balance between software and hardware capabilities. However, in building GSVM, we're taking a bolder approach to specialized hardware than any other blockchain project to date.

Conclusions

Performance improvements serve a much broader purpose than just preventing technical issues like the recent $TRUMP incident. While preventing such problems is important, the real long-term value capture lies in expanding what's possible on-chain. By achieving faster processing speeds and reducing usage fees, Eclipse will unlock an entirely new realm of possibilities for blockchain applications.

These improvements create a virtuous cycle — developers gain the ability to build more sophisticated and resource-intensive applications that were previously impractical, while users benefit from smoother experiences and lower fees. This enhanced capability attracts more users to the ecosystem, which in turn encourages more developers to innovate and push the boundaries of what blockchain technology can achieve — one of the biggest unlocks we have at Eclipse. The end result is a more robust, versatile, and accessible blockchain infrastructure that can support increasingly complex and demanding use cases.

We're taking a direct approach: combining efficient software with powerful hardware that  L1s can't use. While Solana gives us a strong starting point, being an L2 lets us do more — through a combination of profile-drive optimizations, a self-improving runtime, and software-hardware co-design. We can use specialized equipment and make design choices that L1s cannot, since requiring specialized hardware significantly restricts participation. This helps us better serve high-performance applications.

References

https://kelvinfichter.com/pages/thoughts/tps-is-dumb/

https://www.monad.xyz/wtf-is-tps

[1] J. M. Faleiro, D. J. Abadi, and J. M. Hellerstein, ‘High performance transactions via early write visibility’, Proc. VLDB Endow., vol. 10, no. 5, pp. 613–624, Jan. 2017, doi: 10.14778/3055540.3055553.

[2] C. Yan and A. Cheung, ‘Leveraging lock contention to improve OLTP application performance’, Proc. VLDB Endow., vol. 9, no. 5, pp. 444–455, Jan. 2016, doi: 10.14778/2876473.2876479.

[3] N. Zhou, X. Zhou, X. Zhang, X. Du, and S. Wang, ‘Reordering Transaction Execution to Boost High-Frequency Trading Applications’, Data Sci. Eng., vol. 2, no. 4, pp. 301–315, Dec. 2017, doi: 10.1007/s41019-017-0054-0.

[4] J. Duchniewicz, ‘FPGA accelerated packet capture with eBPF: Performance considerations of using SoC FPGA accelerators for packet capturing.’, 2022.

[5] A. Boutros, E. Nurvitadhi, and V. Betz, ‘Architecture and Application Co-Design for Beyond-FPGA Reconfigurable Acceleration Devices’, IEEE Access, vol. 10, pp. 95067–95082, 2022, doi: 10.1109/ACCESS.2022.3204664.

[6] H. Yang, Z. Li, J. Wang, S. Yin, S. Wei, and L. Liu, ‘HeteroKV: A Scalable Line-rate Key-Value Store on Heterogeneous CPU-FPGA Platforms’, in 2021 Design, Automation & Test in Europe Conference & Exhibition (DATE), Grenoble, France: IEEE, Feb. 2021, pp. 834–837. doi: 10.23919/DATE51398.2021.9474088.

[7] H. Sharma and A. Sharma, ‘A Comprehensive Overview of GPU Accelerated Databases’, Jun. 19, 2024, arXiv: arXiv:2406.13831. doi: 10.48550/arXiv.2406.13831.

[8] J. He, Y. Liu, J. Chen, S. Peng, Y. Wang, and M. Zhang, ‘MoryFabric : Reducing Transaction Abort by Actual Validity Verification and Reordering’, in 2023 IEEE 29th International Conference on Parallel and Distributed Systems (ICPADS), Ocean Flower Island, China: IEEE, Dec. 2023, pp. 691–698. doi: 10.1109/ICPADS60453.2023.00106.

[9] H. Yang, Z. Li, J. Wang, S. Yin, S. Wei, and L. Liu, ‘HeteroKV: A Scalable Line-rate Key-Value Store on Heterogeneous CPU-FPGA Platforms’, in 2021 Design, Automation & Test in Europe Conference & Exhibition (DATE), Grenoble, France: IEEE, Feb. 2021, pp. 834–837. doi: 10.23919/DATE51398.2021.9474088.

[10] S. Xi et al., ‘Cora: Accelerating Stateful Network Applications with SmartNICs’, Oct. 29, 2024, arXiv: arXiv:2410.22229. doi: 10.48550/arXiv.2410.22229.

‍