AMA Eclipse

Eclipse is a modular Layer 2 chain-agnostic settlement layer, which enables developers to deploy customizable rollups via the Solana virtual machine, SVM. DApps are built on an L3 app chain that sits on top of Eclipse and scales horizontally. They are building optimistic rollups, a zero-knowledge virtual machine for the Solana VM, and a novel honest minority settlement layer that does not rely on the assumption that the majority of nodes are honest. They plan to support Solana, Ethereum, Aptos, and Cosmos via Inter-blockchain Communication (IBC) and have partnerships with Celestia, EigenLayer, Oasis Labs, Polygon, and NEAR.

Neel Somani, Founder of Eclipse Laboratories Inc., joined us for an AMA on December 6th.

vVv: Neel, could you share more about your background and how you became involved in the Web3 space? What was your experience like at the Citadel, and what motivated you to start Eclipse?

Neel: I previously worked in traditional finance, including a stint at Citadel hedge fund, where I was part of the commodities group and focused on power and gas research. Although my background was not in cryptocurrency, many financial structures used in the commodities market are now being applied in the crypto space. The skills and interests of those in finance often overlap with those in crypto, and the appeal of this space lies in the opportunity to redefine and build upon existing primitives.

I first got involved in the Web3 space by working on the Terra ecosystem, where I built an Ethereum Virtual Machine (EVM) to run Ethereum code on the Terra blockchain. However, when Terra depegged, I abandoned that project and began conversations with the Celestia team, which operates within the Cosmos ecosystem. I also had discussions with Solana Core and formed a vision for the future of blockchains that emphasizes the importance of rollups for scaling and onboarding millions or billions of new users rather than creating new channels.

We want to build infrastructure that enables powerful applications in Web2 but in Web3. We chose the Solana Virtual Machine (SVM) because it is the fastest VM available, and we are excited to bring innovative consumer applications to Web3. The issue with a multi-chain Web3 is that each new emergence requires re-securing the chain, which can be expensive and time-consuming. Rollups allow all users to share the same base layer, leading to more decentralized and secure networks.

vVv: What motivated you to start Eclipse? Did you have a specific use case in mind, and what was the vision behind the project?

Neel: We started Eclipse mainly due to the frequent outages on the Solana network and to provide an alternative chain for deployment. One of the initial use cases we had in mind was payments. Sam Thapaliya, one of our founding advisors, created a protocol called Zebec that allows for streaming payments on the Solana blockchain. He uses Zebec for payroll, and if there is a blockchain outage that delays payroll, it can result in significant fines. We initially started Eclipse to help Zebec scale and become more reliable while still using the Solana Virtual Machine (SVM).

vVv: Was the decision to build on the Solana Virtual Machine purely performance-driven?

Neel: The intuition is that many outages on the Solana network have been at the consensus or base layer, but the execution layer is highly optimized. One benefit of this is that if you have 10 cores, you can use all of them to run not just 10 but 50 or 100 programs simultaneously. There is also a fee market that will soon be available to address bot issues. You can write Python programs and run them on Solana using tools like Seahorse, and the Solana Virtual Machine (SVM) is continually improving. We’re excited about the potential of the SVM to run Ethereum code through Neon and Move in the future. It’s like the Swiss army knife of virtual machines. Even better, we allow users to choose their base layer, which doesn’t have to be Solana. You can select Celestia, Ethereum, or any other blockchain.

vVv: ​What is your opinion on modular and monolithic blockchains? Do you think they will be around in 5 to 10 years, or do you see one becoming dominant? 

Neel: We believe that most monolithic chains will eventually disappear. Monolithic chains offer little to no execution and only provide data availability, serving as a base layer for rollups. We are currently making proposals to several Layer 1 blockchains, including Near and Solana (for which we received a grant), to help them better support rollups. Our proposals for Ethereum are similar to Ethereum Proposal 4844, which aims to build Ethereum for rollups. We are also preparing proposals for a variety of other blockchains. In the future, most applications should live on rollups, especially as composability improves.

vVv:  There are currently a lot of discussions circling the FTX fallout and the influence it may have on Solana. What is your opinion about the future development of this ecosystem, especially compared to big competitors like Aptos or Sui?

 Neel: The investors pursuing Eclipse or Sui are the same ones who have invested in Solana, and I don’t see this as necessarily a conflict. Many projects receive large grants to move to other chains, which can lead to a lack of activity on the app. These mercenary tactics are not sustainable for growing an ecosystem. However, the remaining projects in the Solana ecosystem, of which quite a few, show a commitment to the ecosystem and make it more decentralized. It’s essential to have a diverse range of investors rather than just one significant investor funding all the projects. This allows for decentralization, which is essential for attracting and retaining the general public’s attention in the crypto space.

Another thing to consider is that the Solana Virtual Machine (VM) will continue to thrive, and we are also starting to see other Solana VM chains emerge.

vVv: Why exactly did you choose to build on Solana? Would you still build on it in the current uncertain situation?

Neel: To clarify, Eclipse is not directly built on the Solana blockchain but rather uses the Solana Virtual Machine and forked the Solana codebase. This means that Eclipse can continue to operate even if Solana experiences an outage. We chose to use the Solana codebase and VM because it is the best available option. In the future, we also plan to support other virtual machines. 

vVv: In the vVv Discord, several members have mentioned that the Eclipse site appears unprofessional.

Neel: We are launching our brand, and Kay, who is responsible for marketing and branding at Eclipse, is also in the audience. She has an excellent design that will be released soon, possibly within the next month. We have been working on this for a while and are excited to rebrand soon.

vVv: We think it’s important to provide the public as much information as possible. With Eclipse, it was difficult to find information, which is probably attributed to your early developmental stage. Can you give us a brief overview of the project’s history and a team breakdown?

Neel: To give you a brief overview, our team started working on Eclipse in June and our testnet is scheduled for Q1 of this year. Our team is small, with less than 20 people, and includes Kayla, who handles marketing and previously worked at Holaplex as a founding marketer; Kevin, a UC Berkely graduate who has experience at ChainStreet and Dropbox; Steven, who came from Optiver; and a group of researchers who previously worked on Scroll and Stockware. We also subcontract some of our work to Holaplex, who used to work on a decentralized NFT marketplace and now works on contract projects. Additionally, Seena Foroutan, a former Director of Sales at Chainlink, is leading our business development efforts.

vVv: That’s great. Are you hiring right now, and if so, for which positions?

Neel: We are always looking to hire senior protocol engineers for our team. There are several exciting projects that they will be working on at Eclipse. For example, we are starting as an optimistic rollup and are also building a zero-knowledge virtual machine for the Solana VM. In addition, our team will be working on the various components of rollups, including execution, data availability, and settlement. For data availability, we are integrating with various layers, including Polygon, Celestia, Solana, Near, Oasis Labs, and EigenLayer. For settlement, we are developing an honest minority settlement layer, which is a novel approach that does not assume the majority of nodes are honest. Currently, we can not perform on-chain settlements on an L1 because of expensive verifications on state transactions, such as elliptic curve implementations on Solana. Lastly, we were the first to implement IBC for rollups on the Solana VM, which is why we received a grant from the Solana Foundation. Kevin is currently working on this project and it should be completed by the time any new team members join us.

vVv: Can you elaborate a bit more on the integration with IBC? How is it architecturally constructed?

Neel: From an architectural point of view, there are a few key considerations. First, we had to change the Solana state representation to use a Merkelized key-value mapping instead of the original key-value mapping. Second, as an optimistic rollup, we have a challenge period during which messages are not finalized. Most transactions can be confined within Eclipse, but transactions submitted through other platforms could suffer rollbacks. As a result, we had to enable a challenge period and IBC to support transactions with other platforms, such as Osmosis, so that the potential rollback of transactions within Eclipse would not disrupt them.

vVv: Why did you launch with an optimistic settlement over a ZK Proof?

Neel: We decided to launch with an optimistic settlement instead of a ZK proof for a couple of reasons. Firstly, the optimistic go-to-market is much faster, and we wanted to launch as quickly as possible to meet the demand from projects excited to deploy and test Eclipse. Additionally, we will be fully decentralized once our settlement layer is complete. Similar to Optimism, we will be running all the nodes ourselves and will not enable fault-proofing at launch time.

vVv: In future, do you still see a place for optimistic rollups, or will ZK rollups handle everything?

Neel: In the long run, we believe that zero-knowledge roll-ups are the best version of what a cryptocurrency should be. With this technology, applications can call for their own dedicated sequencers to maximize throughput, and the virtual machine and base layer can be swapped out as needed. However, there are currently several barriers to achieving this, with the biggest being the lengthy ZK proving time, which can take hours even for a ZK EVM. The ZK SVM is currently out of reach due to its high throughput and the large number of state transitions that need to be proven. We are working towards this vision, but it will take time to overcome these challenges.

vVv: You mentioned Celestial, and a few weeks ago, we had an AMA with Fuel Labs. From a technological standpoint, do you see Fuel Labs as a competitor? What are the differences between the Fuel VM and the Solana-based VM?

Neel: John Adler has played a significant role in Eclipse’s development and was also Celestia’s co-founder. It’s interesting to learn that you recently did an AMA with Fuel. One of the main differences between Eclipse and Fuel is that Fuel has its own virtual machine called the Fuel VM, while Eclipse utilizes the Solana VM. This means that there is already a lot of tooling and developer support available for the Solana VM, such as the ability to write Python programs using Seahorse and the Solana CLI. In contrast, Fuel must rebuild this support from scratch. However, Fuel argues that its VM has certain advantages over the Solana VM. I haven’t personally coded much in Sway, which is Fuel’s programming language. Ultimately, it’s important to choose the execution layer that best meets your needs. Currently, the Solana VM is known for being the fastest option. Fuel may eventually match its execution speed and throughput, but the Solana VM is the top choice for now.

vVv: Given that you’re deploying on Celestia, how will you compete with Fuel and the Fuel VM, as an execution layer? What advantages does SVM have over the Fuel FM? Can you compare both the advantages and disadvantages? 

Neel: One key differentiator for Eclipse is that it allows for customization of the base layer, with support for over a dozen Layer 1s. In contrast, Fuel currently uses Ethereum for settlement and Celestia for data availability. Additionally, we have the support of the Solana Foundation, which is continuously improving the SVM. The SVM also has a strong existing developer community, well-established tooling, and a fee market that is expected to be among the best in the industry. While Move may be a fair competitor, we are also considering investing in building a Move execution layer in the future.

vVv: How are fraud proofs from other languages like Move and EVM verified on the SVM?

Neel: Fraud proofs are specific to the execution layer, so it is impossible to simply take an Optimism settlement contract from Ethereum and use it for the Solana VM. However, many of the opcodes for a virtual machine, such as addition, multiplication, and register storage, are the same across different VMs. The main differences lie in the precompiles, extensions, and specific implementations of the VM. In terms of the Move VM, the specific state representation and implementation can affect how the bytecode is executed, though the resulting output should be the same. If we were to implement the Move VM on Eclipse, we would likely aim to share as much code as possible with our full Solana VM implementation.

vVv: Will you be integrating other VMs as part of Eclipse’s roadmap?

Neel: We do plan to integrate the Move VM at some point in the future. However, the timeline for this integration will depend on the needs of our customers. If a large project deployed on Eclipse requires a Move execution layer, we will prioritize its development. Currently, we are focused on the Solana VM implementation.

vVv: What are the advantages and disadvantages of implementing an honest minority settlement layer?

Neel: There are several advantages to using our honest minority settlement layer over traditional options like enshrined settlement. One major benefit is cost. With enshrined settlement, like Arbitrum’s smart contract on Ethereum, you must implement an entire virtual machine or the ability to execute any opcode or operation in the bytecode for your execution layer on the Layer 1, which can be expensive, particularly if certain extensions or precompiles, like the ones used in Solana’s BPF (Berkeley Packet Filter), do not already exist. In contrast, our honest minority settlement layer only requires you to be connected to at least one honest node in the settlement layer, allowing for greater flexibility in terms of trust assumptions. Additionally, with insurance settlements, you do not need to worry about potential risks. Overall, the honest minority settlement layer offers a more cost-effective and customizable solution for settlement.

vVv: Could you tell us the difference between full and light nodes on Eclipse’s settlement layer?

Neel: The main difference between a full node and a light node is that a full node can execute bytecode, while a light node does not need to do this. Instead, a light node can verify that a full node has correctly executed the bytecode by examining the evidence provided by the full node. However, not all light nodes have this capability. For example, Ethereum nodes only look at block headers and are unable to determine the validity of data availability proofs. On the other hand, some light nodes, such as those on the Polygon network, provide a zero-knowledge KZG polynomial commitment that can be used to confirm that a block has been stored. In contrast, others on the Celestia network use optimistic data availability proof that the light client can verify.

vVv: Do you have a close partnership with Solana, and are there any advantages for the Solana ecosystem based on the Eclipse technology?

Neel: Anatoly, the founder of Solana, is an angel investor in Eclipse, and the Solana Foundation has provided a grant to Eclipse to implement certain features for Solana. Eclipse meets regularly with the Solana Foundation and Solana Core. One of the main benefits of using Eclipse is the ability to customize functionality for applications that may not be suitable for a Layer 1 network. For example, DeFi protocols may want to recapture MEV (miner extractable value) and customize their rollups rather than relying on validators on a Layer 1 network. In addition, Eclipse offers options such as introducing a mempool or subsidizing gas fees for specific purposes, such as promoting governance or supporting high-volume applications. This allows for an unmatched level of throughput compared to any Layer 1 network.

vVv: According to Solana’s roadmap, they are also working on horizontal scalability. Is this a possible threat to Eclipse and making rollups obsolete?

Neel: Solana originally intended to optimize horizontal scalability by implementing proof-of-history, but this was never implemented. Instead, Solana currently relies on a single leader for proof-of-stake consensus. While this may be sufficient for dedicated throughput, it does not allow for customized sequencer behavior, which is a focus of Eclipse. Another distinction between Solana and Eclipse is that applications built on Solana as a Layer 1 are subject to the same outages as the Solana network. At the same time, rollups on Eclipse can continue to execute even if the underlying Layer 1 experiences an outage. These differences will always exist, regardless of the potential for infinite scalability.

vVv: Eclipse claims that its platform can help developer teams save significant time and effort. Can you provide an example of how this time and effort savings are quantified?

Neel: Eclipse can be compared to Ignite CLI in the Cosmos ecosystem, which allows users to create their own Layer 1 network that is connected through Inter-Blockchain Communication (IBC). However, Eclipse is a “CLI for customizable rollups” that can be connected through IBC, rather than a Layer 1 network. One downside of using Ignite is that it requires decentralizing the validator set, which can be time-consuming and require coordinating upgrades with multiple parties. In contrast, rollups like Eclipse do not require decentralizing sequencers unless there is a specific need to do so, such as to address censorship concerns. Decentralization of sequencers is optional to ensure proper state transitions.

 One of the main advantages of using a rollup like Eclipse is that it can reduce the costs and complexity associated with managing validators on a proof-of-stake network. With a rollup, there are no issues with the collective cost of running and maintaining a network of validators or the potential for validators to leave the network due to low token prices or insufficient transaction fees. This helps avoid centralization of the network and reduces the economic opportunity cost of staking, as the stakes do not need to be locked up in a proof-of-stake system. Rollups can also provide more clarity around security than proof-of-stake networks, as you do not have to consider the potential for liquid staking and its impact on security.

vVv: Do you have security audits on your code?

Neel: There’s no real economic value in a security audit of our code for the testnet. Exploits on the test net are beneficial and essentially a free audit; thus, we’re not concerned at the moment.

vVv: Can you give us some insights on the testnet phases and if it is open to the public?

Neel: We plan to have three testnet chains for Eclipse: one focused on DeFi, one targeted towards consumers and gaming, and the last designed for token-incentivized physical infrastructure networks. If your project is interested in using Eclipse but does not fit within these categories, please contact us, and we would be happy to discuss potential options. For larger projects, we can set up a separate testnet chain for larger projects specifically for your needs. These three testnet chains will be available for public use, allowing individuals and organizations to test their transactions and deploy their applications. If you need assistance, you can reach out to us through Discord or Telegram for support.

vVv: Have you implemented patents to protect your intellectual property, or is there a risk that someone could fork your application?

Neel: We have chosen to make our application open source because we believe in the importance of community and want to showcase our work. Additionally, we do not believe that vampire attacks, or the fork and use of our protocol by others, will be a significant issue. From our perspective, individuals and organizations are willing to pay reasonable fees for services but not excessive or unreasonable fees. For example, the high gas costs on Ethereum have driven some users to switch to other blockchain networks. Therefore, we are committed to being open source and avoiding exorbitant fees to retain our users.

vVv: If people are interested in learning more about your protocol, can you direct them to a place where they can find a white paper or more detailed documentation?

Neel: To stay updated on our progress, we recommend following us on Twitter, where we share important information. When we officially launch our brand in a few weeks, we will have a comprehensive FAQ section and additional documentation available on our website.

vVv: Are you using EigenLayer’s availability to integrate Eclipse with Ethereum?

Neel: Ultimately, we plan to integrate our platform with Ethereum through sharding. However, this process may take some time to implement. In the meantime, EigenDA is a strong solution for our needs and is a great way for us to bring EigenLayer to market. We are also fans of the EigenLayer team and appreciate the support of Sreeram, a pre-seed investor in Eclipse. We are excited to work with EigenDA as one of our options for the foreseeable future.

vVv: How is transaction data protected in rollups, and are there any disadvantages of operating rollups?

Neel: Transaction data is not private in a rollup, even for a zero-knowledge (ZK) rollup. While ZK protocols such as Elusiv on Solana and Tornado Cash on Ethereum can provide some level of privacy, they are primarily used to enable verifiable compute more efficiently. One disadvantage of using a rollup is that it can be more expensive for the protocol developer to operate than an existing Layer 1 blockchain. This is because someone needs to run the rollup and collect sequencer and transaction fees. However, the end user may benefit from lower costs due to the fixed cost of posting transactions in batches, which is averaged across all transactions.

In contrast, every transaction on a base Layer 1 blockchain must be secured individually. Another disadvantage of using a rollup is the added complexity of implementing wallets and bridges if you want to fork a project like Optimism Bedrock. Eclipse aims to solve these challenges, but doing so can be difficult.

vVv: What happens if IBC messages are sent, and an optimistic rollup is challenged and rolled back?

Neel: One solution to the issue with Inter-Blockchain Communication (IBC) is simply waiting until the challenge period is over before accepting and acting on IBC messages. This ensures that there is a guaranteed level of finality for transactions. However, there may be better solutions in some cases. Another possibility is for the receiving chain to challenge the possibility of rolling back the transaction itself. However, this would require the receiving chain relinquishing some of its sovereignty. Eclipse also implements full-node bridges such as Hyperlane, which allow for fast finality and immediate cross-chain invocation and bridging of funds. However, they still have the challenge period when using IBC.

vVv: What are the applications you’d like to see built on top of Eclipse?

Neel: There are several potential areas where Eclipse’s architecture could be useful, including:

1. Games: The high transaction volume and reliability needs of games make them well-suited for the Eclipse architecture.
2. Protocols with customized infrastructure needs: Protocols that require bespoke infrastructures, such as a large DeFi protocol on Solana that wants to implement MEV recapture or governance modifications, could benefit from Eclipse.
3. Web2 enterprises: Companies with large user bases, such as Disney or Spotify, that need to stream content and handle payments could potentially use Eclipse to scale beyond the limitations of the current crypto infrastructure.

Overall, Eclipse is looking to support projects with high transaction volume and reliability needs or require customized infrastructure to scale effectively.

vVv: We are very excited about the potential for Eclipse to drive mass adoption of blockchain technology. Could you provide more details about your development timeline, including when you plan to launch the mainnet?

Neel: Our testnet will launch in February of 2023 and mainnet at the end of Q2 2023. We will also enable people to start validating or start operating their own sequencers or acting verifiers in Q2.

vVv: What are the requirements to run an Eclipse node or validator?

Neel: You have to be able to verify or reflect the requirements of running a Solana validator. The most expensive way would be through a Google Cloud engine, and a home validator or verifier’s running costs are between $3,000-$4,000.

vVv: What is your plan for bootstrapping the network? Do you have any incentives in place for marketing efforts at the outset?

Neel: Eclipse does not need to bootstrap sequencers or verifiers since it is a rollup, which does not require many of these elements. Instead, the focus is on bootstrapping the developer community and liquidity. To achieve this, Eclipse has partnered with big funds interested in deploying capital into the Eclipse ecosystem and is tapping into the Solana and Cosmos communities, which are adjacent to and interested in Eclipse’s work. In addition, Eclipse is working to build infrastructure that can enable projects that previously couldn’t enter the crypto space to do so. This includes projects that may have been too large or complex to be supported by existing crypto infrastructure.

vVv: Do you already have some Web2 partnerships in place that you could share?

Neel: We have signed non-disclosure agreements with all of our partnerships and cannot disclose any information now. We plan to share updates as our partners begin deploying on Eclipse, as this is the most appropriate way to share information with the community. Sharing details beforehand may lead to speculation and misunderstandings.

vVv: Are you planning to start developer grant programs?

Neel: Currently, Eclipse does not offer grants as it wants projects to choose Eclipse only if it is the right solution. In the future, Eclipse plans to raise an ecosystem round and invest in projects in a more capital-efficient manner. Eclipse’s backers from the last investment round are actively looking for projects in the Eclipse ecosystem to fund, and many have already been backed. If a project is looking for funding and has a solid idea, Eclipse can connect them with its backers and support its efforts. Funding should not be a concern for projects within the Eclipse ecosystem.

vVv: Did we miss any crucial topics?

Neel: If you are building a high-throughput application, DeFi protocol, or consumer-facing protocol that could benefit from Eclipse’s architecture, we encourage you to reach out to us. You can contact us through Twitter by DMing NeelSalami or the Eclipse account. Be sure to follow us on Twitter for updates and to stay connected with our community.

We look forward to hearing from you and discussing how Eclipse can support your project.

Listen to the Spotify recording below for the full Eclipse AMA.