Demystifying Application-specific rollups on Solana VM — An Eclipse Deep Dive

A deep dive into the Eclipse building on one of the hottest themes of “appchains”, the modular blockchains, and a sneak peek into what’s ahead for Eclipse.

2022 was a year, many ‘popular’ dApps announced to move from a general-purpose chain to an app-specific chain. It began with Defi Kingdoms, a popular game that saw $130 Million in daily volume and 400K daily transactions at peak, which decided to move from Harmony, a Layer 1 to have its own appchain on Avalanche subnet. Yuga labs also showed intent to move from Ethereum when its highly anticipated NFT sale faced scalability issues. The appchain market saw its breakthrough moment when one of the biggest decentralized derivatives exchanges on Ethereum announced that the next version would be built on its own appchain with its own set of validators using the Cosmos SDK. Think of dYdX as Binance of decentralized derivatives.

But, why are they moving to their appchain?🧐

Let’s start with a simple analogy:
Assume chains like Ethereum to be very old buildings in the heart of the city, with pros like the lively neighborhoods (liquidity), access to shopping malls and transportation (composability), and cons of clunky old infra (congestion).

Someone like dYdX has been staying in this old building for a long time, but is now doing well in life and wants to design their own house. They don’t have a very good social life (less composability), so they will obviously look to move to the city outskirts, where they can build their very own customized villa (appchain) as per their needs using a nice builder (Cosmos SDK).

Similarly, apps like dYdX also have a basic need — customization. dYdX, being a trading platform, is running with an orderbook model. To scale further, they needed more scalable systems, which wasn’t possible in their existing chain (Arbitrum) and required higher throughput i.e., Transactions per Second (TPS). While they could have moved to more performant monolithic chains like Solana, however, they have a clear vision to bring a centralized exchange-like trading experience without comprising any decentralization. Hence they decided to have their own chain to maximize customizations while leveraging composability and interoperability of Cosmos SDKs.

But, what if dYdX had the option of leveraging the speed and low gas fees of Solana all to themselves while enjoying all the customizations they needed in their design of the orderbook experience?

Would they have opted? Probably, Yes! This article is primed to help you decide that.

The project we are diving into — exactly solves this problem, so that apps like dYdX can spin off their own modular chains while leveraging virtual Machines like Solana VM or Move VM. The article will also help you understand what appchains are, why someone will launch their own appchain, Eclipse competitor’s landscape, different appchains possible on eclipse, and many more.

Ready? Let’s go🚀

Before we begin with Eclipse, it’s important to understand the existing blockchain architectures and what are the different layers in brief.

Monolithic Blockchains and their drawbacks:

At the end of the 19th century, industries had processes set up such that a single worker used to work end-to-end on a product such as a car, but it was inefficient as one worker had to learn various skills, leading to lesser quality too. However, setting up “assembly lines,” i.e. breaking down manufacturing of goods into pre-defined sequences, brought up a paradigm shift. The time required to manufacture a car was reduced significantly as these processes ran parallel.

Similarly, blockchains like Ethereum and Solana are monolithic in nature, and they do everything from start to finish, like creating blocks, consensus and storage, and smart contract execution. What if we applied the same ‘assembly line’ technique here as well, i.e break down blockchains into different modules? That’s just the modular blockchain!

Blockchains such as Bitcoin, Ethereum, and Solana have a monolithic structure and four primary functions:

1. Data availability
2. Consensus
3. Settlement
4. Execution

An illustrative representation of how Eclipse can fit into the Modular Blockchain story

As we see mass adoption coming up, transaction volumes will continue to increase, putting ever-higher pressure on validators. It can also lead to data-overload issues and throughput issues, particularly high-load periods like NFT mints, which are short but very demanding on blockchain throughput events. For instance, Bored Ape Yacht Club NFT launch on Ethereum caused huge network congestion, which also lead to Yuga Labs subsequently intending to migrate to its own high-throughput chain.

Rollups to the Rescue:

The Ethereum ecosystem has been focussing on Rollups as the way to solve these, as it delivers speed by running a separate chain, saving only zipped archives of its transactions to an L1. Primarily, there are two types of rollups:

• Optimistic rollups: They assume that all transactions are valid and they could submit batches of transactions without any computation. However, they also feature a challenging period during which anyone could challenge the authenticity of the transaction batch.
• Zk-rollups: They create cryptographic proofs, helping in proving transaction validity. Every transaction batch would feature their personal ‘validity proof,’ which must be submitted on the main chain.

Optimistic rollups have been here for while with projects like Arbitrum and Optimism running well for almost a year now, serving a huge chunk of users. zk-rollups are yet to be battle-tested. However, these types of rollups has a weakness as they aren’t upgradable, and can only be upgraded by hard forking the L1, as they aren’t sovereign.

L: How zk works | R: How Eclipse would work

Enter Eclipse: The Customisable Rollups on Solana VM

Eclipse in a unique project building the first Sealevel VM rollup, which will give a Rollup-as-a-Service with a customizable base layer. It will be an IBC-enabled rollup on Celestia, which is the data availability layer. Eclipse is simply a fork of Solana’s existing codebase, redesigned in the modular vision. The way it works is simple — instead of fitting all apps on the same chain, Eclipse lets you spin up your own modular rollup with the powerful Sealevel virtual machine. This allows anyone to run programs written for Solana, but Eclipse isn’t using Solana for security. The base layer instead can be customized as per the needs, it can be either CelestiaOrg , Polygon Avail , or Eigen Layer.

What eclipse provides is a settlement layer, which acts as a bridging hub and a dispute resolution board for fraud proofs. This settlement layer is IBC-enabled, which allows anyone to pass IBC messages.

Representation of Eclipse layers by the team

But you might be wondering why they aren’t simply using EVM (Ethereum Virtual Machine) for this?🤔

Why start with Solana VM?

Simple answer — Speed! The Solana (Sealevel) virtual machine has a highly parallelized runtime as compared to EVM chains such as Ethereum, where there is only a single program running (single-threaded). The Solana VM has multiple cores, which enables it to run several programs at the exact same time, substantially increasing throughput. The Execution layer is continuously improving as:

1. Seahorse Lang lets you write Solana VM programs in Python.
2. Soon, Solana VM will support Move, a rising programming language
3. Solana VM has successfully implemented a local fee market.

The best part is they get a ready-made Solana developer community and supported token standards as well. Eclipse can also leverage Solana’s current TPS, which counts both voting as well as non-voting transactions and make it all the TPS as true TPS, which has no voting transactions.

Benefits of Solana VM

Although the Eclipse team is right now betting big on Solana VM, the plan is to support other VM as well. One of the most exciting ones is Move VM used by shiny projects like Aptos and Sui which can support high performance as well.

Okay, now we get Solana VM, but why are they being IBC-enabled?

IBC-enabled: Solving for Interoperability

Launched in April 2021, IBC or Inter-Blockchain Communication is the cosmos standard for blockchain interoperability, which enables independent blockchains to connect, transact, exchange tokens and other data, scale, and thrive in an interconnected network. This is similar to a cross-chain bridge, where you can communicate arbitrary data between arbitrary state machines, but much more decentralized than bridges.

By enabling IBC, Eclipse can make use of the IBC application layer to build a wide range of cross-chain applications, including but not limited to asset token transfers, interchain accounts (delegate calls between two chains), NFT transfers, and price oracle data feeds. IBC is already connected to 50+ cosmos appchains. Simply, being IBC-enabled will help appchains on Eclipse to leverage the interoperability of the cosmos ecosystem as well.

Okay, enough of understanding the tech and architecture of Eclipse, let’s now dive deeper into “What’s possible”

Why would anyone launch using Eclipse?

The concept of launching an “appchain” will be more clear in later parts, but particularly, Eclipse has the following advantages:

1. Maximum customizability: Any dApp can adjust its block times, subsidize gas, or restrict who can use your blockchain.
2. Shared security: dApps don’t have to worry about managing infrastructure or bootstrapping validators, because it borrows security from the underlying Layer 1.
3. Scale horizontally: This means that dApps can always spin up another execution layer, giving the power of Solana all to themselves.
4. Cheaper running costs: The data availability layer doesn’t need to support execution, and therefore the cost of running a node is cheaper promoting decentralization.

User Experience: On-boarding and taking Appchain Cross-chain

Let’s suppose some Decentralised Exchange like dYdX, which plans to make its own appchain, comes and asks Eclipse Foundation on what the user experience could look like. Be it trading use-case or any other, a user shouldn’t feel like migrating to an appchain, the user experience should be superior.

Here are a few infrastructure pieces, which the Eclipse Foundation should keep in mind for enabling the best user experience for appchains:

1. On-Ramps and Off-ramps: This is the most critical need for any first-time web3 user — how will they convert their fiat into crypto in order to use the dApp? While listing on exchanges like Binance or Coinbase can solve this problem, it isn’t easy for a new chain. Integrating solutions like Stripe, Moonpay, Wyre, Kado can be another way to solve this problem. However, it all requires working with partners in order to make them support your chain and assets.
2. Gas fees: While some chains may launch their own token and accept that as gas fees to make transactions and few might accept more universal assets like USDC as gas fees. To enhance user experience, appchains can also make the entire chain gasless by either subsidizing gas fees for the user or just taking in-app transaction fees which also include gas fees.
3. Wallets: One of the reasons why many dApps choose to launch on EVM-compatible chains is that the network can be added to a popular wallet like Metamask and be used by the user. To ensure an optimal user experience, Eclipse appchain can either create its own wallet, if it’s geared towards first-time web3 users, or integrate with existing popular wallets like Phantom. The UX should be similar to switching between networks in metamask, where a user will select the eclipse network.
4. Cross-chain Bridges: This is the most critical piece for any dApp, which is primarily targeting crypto-native users. If, let’s say, your user is using Solana; they should easily bridge an asset from Solana to your chain. Beyond assets, bridges can also be used to send arbitrary messages to and from the appchain. For instance, someone can stake their collateral assets on Ethereum and borrow assets from the appchain, and the appchain needs to make sure the messages are passed securely from the source chain. Integrating with existing bridge solutions like Nomad, Axelar, and LayerZero will be the smoothest way to achieve bridging to ensure maximum coverage of target chains.
5. Base asset: Just like Ethereum has ETH, Solana has SOL, and all chains have a native asset that is independent of any external entity and is native to the chain. For an appchain, this will be a critical challenge as having a wrapped asset pose many external risks. To understand this, Polygon, one of the fastest-growing chains, still doesn’t have a native USDC! The USDC that’s being used on Polygon is just the wrapped version of USDC by Polygon PoS bridge. This means this isn’t the official USDC, and Circle has no liability to ensure redemption of them.

While these are major nuances, there can be others as well, like blockexplorer, exchange of assets, and much more. It’s necessary for the Eclipse Foundation to provide these appchains with ready-to-integration solutions of these or partner with relevant bridges, wallets, and on/off-ramps to ensure smooth integration with each appchain.

Few recommendations for Eclipse to build:

To build an ecosystem around Eclipse, the foundation can build several projects to catalyze faster deployments:

• Easy-to-use, low-code framework: This will attract numerous Web2 enterprises to spin off their own application-dedicated execution layers that remain highly customizable. This can be achieved via an intuitive dashboard, which any company can use to customize its blockchain and deploy via simple clicks or minimal coding.
• Embedded Orderbook integrated into the settlement hub for concentrated and easy liquidity access for the applications.

Use-cases: Applications possible on Eclipse

Just like any dApps, application-specific rollups can be of any type, be it, gaming, DeFi, or payments. Recently, Zebec, which is one of the biggest multi-sig and token streaming platforms on Solana, also announced that they would be launching their own app chain using Eclipse’s modular rollups.

The way, Zebec will work is as follows:

1. It will be a payment chain capable of verifying the user’s payment information, authorizing transactions, transferring funds between accounts, updating account balances, etc.
2. The eclipse will power its rollout to the Cosmos network as well, where the payment chain can be used for payment streaming, trading of real-world assets (RWAs), and real-time messaging, among other things.

But why would Zebec make its own chain using Eclipse?

Payment is a use-case that requires high throughput to process more transactions than Visa; deploying their own roll-up gives them a much higher transaction per second and also allows other dApps to build on them by deploying their own roll-up. Another reason is interoperability, as the modular chain setup will allow it to tap into numerous ecosystems.

Yama Finance, an omnichannel stablecoin, has also announced that they will be launching on eclipse.

Payment is one such use-case; there can be numerous other applications that can be built using Eclipse, but not limited to:

DeFi:

Each DeFi on Solana can potentially be its own appchain. Let’s understand this with an example: Serum, which was built by FTX, was the backbone of Solana DeFi, as many DeFi protocols used Serum’s central limit orderbook (CLOB) to tap into aggregate liquidity and match their trades. After the FTX collapse, it was forked by the community, and now everyone has pointed out limitations on them, which also included relying on Solana’s execution layer. A simple solution can be to move to Eclipse, where the orderbook can be customized further per DeFi community needs while also leveraging the speed of Solana.

Sei, which is a cosmos-based appchain, has already done somewhat similar, where they have a native orderbook for their blockchains, allowing other DeFi apps to build on.

Building a Binance-like Decentralised Exchange: After the FTX crash, Decentralised Exchanges have been hot, but they have very limited features as compared to a centralized exchange like Binance. A promising idea can be to spin off a DEX-chain on Solana, just like dYdX, which offers all advanced features. The best part is the users can not just have complete proof of reserves/assets but also proof of liabilities, as everything is on-chain and completely non-custodial. To enable KYC for on-ramps and off-ramps, they can also turn on permissioned rollups, which only allow verified users to use the DEX. dApps such as Drift can potentially spin off their own appchain.

Oracles:

Pyth is one of the top oracle providers, currently deployed on Solana, which provides 80+ price feeds by aggregating data from over 65+ data providers, resulting in over 700 price update operations per second. They have been occupying more than 10% of Solana’s transactions. Hence, to scale further, they will soon be launching their own chain using Solana’s codebase, which will essentially give all of Solana’s TPS to themselves. But it wouldn’t be easy to implement completely on their own. Here, Pyth can potentially use eclipse to spin off their own roll-up and achieve all customizations they need.

Gaming:

At the beginning of 2022, every big game explored moving to their own appchain as they have high requirements for throughput and finality. An example can be: StepN, a Web3 running app, is one of the biggest dApp on Solana, which single-handedly caused Solana’s activity to rise, and was seeing ~500K monthly active users. They can potentially be an Eclipse appchain, with all the Solana TPS for themselves.

Web2 Enterprises:

Hate or love it; big Web2 giants love to have their own customizations to enhance user experience and retain control. We all know, how crucial is to attract Web2 giants as they can enable mass adoption at a much faster pace. One of the value propositions for them can be to roll out their own sovereign chain using Eclipse. For instance, if banks like JP Morgan want to launch their own array of currency-based stablecoins, they can spin off their own chain, and build their ecosystem of applications. They don’t have to worry about infrastructure and can just on power use cases like remittances, synthetic real-world assets, and more. Another reason for enterprises launching their tokens can be to avoid regulatory hurdles of launching their tokens and just paying the base layer for the data.

The case for Permissioned Appchains:

Permissionless is one of the core ethos of Web3, but not everyone prefers permissionless, particularly central banks and financial institutions, as they would want only verified individuals to enter.

Let’s say a Central bank wants to launch its own Central Bank Digital Currency (CBDC) on a public blockchain to have transparency but also wants to have full control as it can’t afford to anyone manipulate its national currency. They would want to leverage existing Virtual machines like Solana VM while having customizability like:

• On-chain KYC for ensuring only citizens of the country hold the CBDC
• Freezing of CBDCs in the case of terrorist financing or monitoring and limiting the activity of suspicious individuals or withdrawing CBDC from a wallet, in case of a hack or wallet compromise
• Allows banks and financial institutions to become the set of permissioned validators, which ensures decentralization

All these controls would be very difficult to be deployed on a monolithic blockchain, and hence spinning off their rollups using Eclipse would be an ideal solution.

Competitive Landscape: First Mover Advantage

With great market opportunity, comes great competition as well. While many ecosystems have been developing their own appchain module, the most famous being the Cosmos SDKs, which has been advocating appchains since 2016. But, Eclipse is uniquely positioned, let’s see why by first looking at the competitors:

1. Appchain Enablers: These are ecosystems, which aren’t necessarily modular in nature, but are offered by well-established ecosystems like Cosmos, Avalanche, and Polkadot. They have been very well advocating the appchain thesis, with many popular dApps already deploying on their appchains or intended to deploy.
2. SVM Compatible: There is another interesting project, called Nitro which is building “Solana VM for Cosmos ecosystem”. It can be thought of as an L2 for the cosmos, which will enable any Solana project to launch on Cosmos easily. Just like Avalanche, and BNB is EVM compatible, it will bring SVM compatibility to Cosmos instantly access the broader IBC ecosystem. Apps built on Nitro can leverage the SVM for high performance while gaining interoperability native to IBC. It also has eclipse-like rollups on its roadmap.
   Having the first-mover advantage will be crucial to attracting Solana-based projects, however, the bigger game lies in tapping into Web2 Enterprises and bringing dApps from other Ecosystems along with becoming the first choice for a new project.
3. Modular Rollups: There are a good number of projects building on modular blockchains theme, but most of them are still not in the mainnet and are either building or have deployed their devnet/testnet. A few interesting ones are:

• Dymension: This enables anyone to launch their consensus-free blockchain ie. “RollApps”, and are connected to the mainchain via Dymension Hub, just like Cosmos. It utilizes Cosmwasm VM, where RollApp developers can choose DA (Data Availability) providers which are supported by the Dymension protocol according to their cost and security preferences.
• Altlayer: This also enables anyone to launch their own rollups and supports multi-VM like EVM/WASM with low gas fees and fast transaction finality.

Although the appchain space is heating up lately though, I personally believe BD and Partnerships will play a very crucial role to attract dApps. Leveraging first mover advantage to become the go-to choice for anyone launching their own chain will become the key for the eclipse foundation!

Backers and Partnerships:

Eclipse is still not out for any public testnet, however, they have started to be highly collaborative in nature, given their modular ethos. They have started partnering with relevant stakeholders like Saga to integrate their interchain security fee market to enable developers to easily deploy sequencers for Eclipse’s app-specific rollups. Interestingly, eclipse foundation has also participated in the $3 Million seed round of loyalty tooling, Kalder, which also hints that it can be one of the early projects to launch on eclipse.

The founder, Neel Somani has a strong background with work experience in Citadel, one of the most prestigious trading firms, and was previously developing a protocol, connecting the algorithmic Terra stablecoin with Ethereum, which would have allowed anyone to run EVM code on Terra. Although Terra’s crash, left the project unfruitful, the concept of Eclipse was somewhat drawn from there.

The founder advisor, Sam Thapaliya has previously built the streaming payments protocol Zebec on Solana, and zebec is a perfect use case for the Eclipse architecture (one of the inspirations for building Zebec). To kickstart the project, it received a Solana Foundation grant for building optimistic rollups over Solana VM and connecting to IBC. It’s part of Celestia’s Modular Fellows program, along with other leading modular-themed players.

The $15 Million funding by one of the top investors like Polychain and Tribe, that too in a bear market is definitely bullish for the project. They now have enough gunpowder to not just build a top-notch team, but also build a solid ecosystem of projects.

Roadmap: What’s on the horizon for 2023 and beyond

While there’s no official roadmap from the Eclipse team, however, let’s construct a rough roadmap from the team’s appearances in podcasts and what generally modular projects go through:

Testnet:

It’s expected to launch in Q1 2023, where they will be stress-testing Eclipse’s Tech by running various versions of Testnets. For instance, they can run three testnets specific to the use cases, as at the end these blockchains will be application-specific:

• DeFi Testnet: This can be to majorly test high throughputs and orderbooks are one of the perfect ways to test throughputs. Eclipse can launch a dYdX-like DEX, where a cohort of incentivized traders can connect their wallets and place orders.
• Consumer Testnet: This can be either a gaming or social or NFT-based testnet. For example, they can launch a game-dedicated execution layer, and it can have an incentivized cohort of 300–500 gamers, where they play games for 2–3 days and test out if the testnet can handle 1,00,000+ transactions per day.
• Physical Infrastructure Testnet: This is a unique case, which Eclipse is particularly focusing on, where wireless networks like Helium, can launch their own chain.

Early access should be given priority to either unique use cases or big enough enterprises with ambitious plans via appchains.

Mainnet:

By the end of Q2 2023, Eclipse might look to launch their product and start getting existing chains on Solana and also attract Web2 enterprises to spin up their own chain. Initially, the eclipse will be looking to launch like optimism, where they run all of the nodes themselves to enable faster launch and sufficiently decentralize from there on.

Ecosystem:

At the end of the day, it’s all about adoption and how well not just existing Web3 dApps adopt Eclipse, but also big Web2 giants like FinTechs, and Social Media launch on Eclipse. Business Development, Community, and Partnerships will play a crucial role.

Decentralization:

Initially, Eclipse might take the Optimism-style launch route, where they run all of the nodes themselves and don’t enable settlement. This way, anyone can immediately start using an Eclipse chain. However, the vision would be to decentralize and further build out our novel honest minority settlement layer. This also includes having a broad set of validators, who can take part in the decentralization of any chain.

Will the next wave of appchains be powered by Eclipse?

The appchain is a compelling theme, and I am particularly bullish on them. This is definitely on my lookout theme for 2023. It’s all on Eclipse on how well they build an ecosystem around them. The risks are many, including liquidity risk, technology risk, and cross-chain bridging risks, but tackling these risks and building a trust-minimized system will be key.

The ultimate aim of Eclipse should be to catalyze the adoption of Web3 with scalability, security, and decentralization features with a focus on ease of integration, fast deployments, and user experience.

Feel free to hit me up on Twitter, would love to chat and help in any way. If you found this insighful, sharing always helps :)
Thanks Sitesh Kumar Sahoo for the wonderful cover image.🙂

References:

1. Eclipse Website
2. dYdX’s appchain by IOSG ventures
3. Market Opportunity of Modular Blockchains
4. Application-specific rollups by Cartesi
5. Application-specific blockchains
6. Zebec on Eclipse Announcement
7. Optimistic vs Zk rollups