A Solana Rollup on Ethereum? An Interview With Eclipse

I recently interviewed Neel Somani from Eclipse: An upcoming L2 on Ethereum utilizing the Solana Virtual Machine.

A Solana Rollup on Ethereum? An Interview With Eclipse

Last week I had the pleasure of interviewing Neel Somani, the founder of an upcoming Ethereum layer-2 by the name of Eclipse. Eclipse is different from other Ethereum rollups as it embraces modularity from top to bottom. I asked Neel about  these design choices as well as various other subjects such as the mainnet release, fee structure/value-accrual, a native token and more.

Before diving into the interesting conversation with Neel, here’s a quick primer on the composition of blockchains. A blockchain consists of 4 layers:

  • Execution layer - Processes the transactions from users and provides an environment for dapps
  • Data-availability layer - Nodes receive a block from a block producer and checks if the data is publicly available
  • Consensus layer - Determines the sequence of transactions
  • Settlement layer - Decides the state of the blockchain (finality)

A monolithic blockchain handles all of these components itself i.e is comprised of all four layers.

A modular blockchain is defined by only making up one or a few (but not all) of these layers. Below are some examples of these different architectures.

Eclipse utilizes

  • The Solana Virtual Machine (SVM) for the execution layer
  • Celestia for the data-availability layer
  • Ethereum mainnet for settlement and consensus

Let’s dive into the interview👇

Thanks for reading DeFi Frameworks! Subscribe for free to receive new posts and support my work.

Interview🎙

Let's first talk about the execution layer. What made you choose to run the Solana virtual machine rather than the EVM for the Execution environment? On your website, concepts such as parallelism and local fee markets are mentioned - are these the main advantages?

“That's definitely the biggest benefits. The way to think about it is if you have 100 people all sending transactions to an EVM chain, all of those transactions have to get in a single filed line and each transaction served one at a time, no way around it. Whereas on Solana for the Solana virtual machine, they can actually all get in different lines and they can all be served at once. So obviously you're limited by how many cores the main executor is running and there's some hardware constraints, but the throughput is much higher than for an EVM chain. And they've also additionally had optimizations to reduce the block time and to make the execution even for a single thread very quick. So that's the primary reason why we chose it.“

Are there any trade offs here?

“The downside is, well, how do you figure out what line each person should get in? If you have 100 people that are in line and they're all trying to get their transactions served, that means that they have to specify some additional information upfront. So they have to say, I want to read this part of the state or I want to write to this other part. They have to say what they're going to do in advance. For EVM transactions, that's not how it works. You can just say, I want to run this transaction, and it just gets to do whatever it wants. that's part of what slows down the EVM. But it's also very convenient.“

Can you comment on the composability of Eclipse? I imagine it's easier for Solana/Rust developers to build on the SVM. Can solidity developers or protocols on Ethereum mainnet or other L2’s easily integrate with Eclipse?

“So these are actually new features, but yeah, we can support solidity via a project called Solang. And there's also a product called Neon which lets you use your MetaMask wallet. Drift also built MetaMask Snap, which is a new extension to MetaMask which lets you use your wallet with the SVM code. With Rust contracts, developers can use Seahorse and they can write their smart contracts in Python and even Python can work with Eclipse. So there's all sorts of different languages that we support at this point. Ultimately it all gets compiled down to the same bytecode, to the same zeros and ones. It's just a difference of what language the developer is writing in. “

In regards to the data availability (DA) layer, why you have gone with Celestia rather than Ethereum?

“So we're always going to pick whatever's best for the users and the apps. We're not tribal at all, even though we're obviously an Ethereum L2. We're not going to try to force Ethereum for DA to work if it's just not functional from a cost or from a bandwidth perspective at this point. But we're always watching it. We're ready to migrate to ETH DA as soon as it's ready. But right now, Celestia provides larger blocks. The block spaces presumably will be empty as soon as they launch their main net. So we're going to have a lot of bandwidth and they can increase that bandwidth too. So they're able to increase the block size via governance. And I expect that they will do that a few times, especially once we're deployed there. “

Eclipse will utilize Risc Zero for proving on the rollup. How does this differentiate itself from other types of rollups?

“We did a methodology that's quite different from Optimism or Arbitrum. And the reason for that is because the virtual machine we use, because it's parallelized, doesn't have some of those same primitives, it doesn't have some of the same pieces, like a merkel tree, for example, that's not a part of our rollup. Merkel trees are used in the fault-proof process. So instead we have to do fault proofs in a different way and it ended up requiring risk zero in order to do this in an efficient way. So that's effectively why risk zero is there in the stack and that's going to be an essential part of our fault proofs.”

Image

The next thing I wanted to ask about is value accrual. In the case of Arbitrum, when users conduct transactions, they pay fees to the roll up, and these rollups then have to pay a percent to Ethereum Validators as a settlement cost but essentially get to keep the rest. How does this work on Eclipse? Which parts of this modular stack will accrue these fees? And will there be something left over for Eclipse in the end?

“So right now, we haven't decided on whether there would be some amount allocated back to Eclipse and how much that would be. If there were some amount, it would just be compensating for risk. Meaning that the way we calculate the fee is we look at the layer one, we say, what's the cost of posting Ethereum and how much do we have to post there? Then we look at Celestia, we do the same thing and then we add it all up and that's the fee that we're going to pass on to the user. But the risk is that when the user pays the fee, then there's like a couple of seconds that go through, right? And then we're going to post to the layer one. Perhaps this fee has increased. So as a result, maybe it's wise for us to charge a little bit more just to protect against that risk. So that's the reason for it.

Those are the two players that are involved. It's really Ethereum Celestia in terms of the regular cost that's paid. Celestia gets paid for every single transaction that's posted to Eclipse. If you write a transaction, we have to post about 200 bytes to Celestia, whereas Ethereum gets paid every hour. Or it could even be less frequent.

And then there's some other players that we do need to pay every so often every week (Risk Zero). Even if nothing wrong has happened, we still run the Risk Zero fault proof. Just to show that it still works, basically. And that's why the fee might not be exactly equal to the cost of posting a slash plus the cost of Ethereum, and that's where that margin is paying for.”

What’s the strategy for attracting applications and growing the ecosystem early on?

“So we have a handful of DApps coming from Solana who are going multi chain, so they will be additionally deploying to Eclipse. We've incubated a handful of projects. We've supported some projects through our solar accelerator program. We do these grants for developers and we can give them guidance, break it down into milestones and give them all the resources they need. Right now we're still continuing to talk with Solana DApps. We're going to expand into solidity DApps soon. “

Will there be an Eclipse token in the future with the purpose of decentralizing the rollup and introducing governance?

“Perhaps, it's something we haven't really thought enough about to have an opinion on because we're so focused on building this mainnet, and there's so many things that go into mainnet that in order to even consider something like a token, we'd have to understand how we think about governance and what's the complete governance framework. And this would be months and months of effort to really think about. So we haven't really considered it.“

When is Eclipse going live on mainnet?

So we have a devnet already and that's what people have been actively developing on right now for the mainnet. Once we code freeze an audit, then we'll make it source available so folks can look at the code themselves, they can play around with it. And that's the plan for the Eclipse mainnet. Basically by end of year we're going to be making these steps and ideally, assuming Celestia is stable and assuming nothing else, no other piece of infrastructure is missing, then we'll go ahead and make that live.


That’s all for today! For more information on Eclipse: https://www.eclipse.builders/

If you enjoy this type of content, don’t forget to subscribe for more coming in the near future⚡️

Thanks for reading DeFi Frameworks! Subscribe for free to receive new posts and support my work.