0xResearch - Eclipse and the Next Generation of Rollups - Revelo Intel

0xResearch – Eclipse and the Next Generation of Rollups

In this episode of 0xResearch which took place on July 5, 2024, Boccaccio and Ryan Connor hosted Ren and Terry from Eclipse to discuss bringing the Solana Virtual Machine (SVM) to Ethereum (EVM), Eclipse’s unique features, future development, strategies for attracting developers and users, and more! Read our notes below to learn more.

Background

Boccaccio (Host) – Research at Blockworks and Host at 0xResearch

Ryan Connor (Host) – Research at Blockworks

Ren (Guest) – Growth Marketing at Eclipse

Terry (Guest) – Head of Strategy at Eclipse

Eclipse – an Ethereum Layer 2, powered by the Solana Virtual Machine (SVM)

Bringing Solana’s Performance to Ethereum: Eclipse on SVM L2 Integration

  • Terry explains that Eclipse is an SVM L2, bringing the Solana virtual machine as a layer-2 on Ethereum.
  • Boccaccio asks why they decided to bring the Solana Virtual Machine to Ethereum.
  • Terry answers that they wanted to create something different and considered the execution environment’s organic traction, large ecosystem of dApps, and strong developers. They chose SVM over EVM due to its higher production transactions per second, innovative dApps, and familiarity with Rust among developers.
  • Ren adds that current roll-ups and L2s are not very performant, with even the best achieving only 30 TPS. He compares this to Solana’s SVM, which achieves around a thousand TPS daily, making it one of the most battle-hardened execution environments.
  • Terry agrees, noting that TPS is only a flawed metric if misused. He emphasizes that benchmarking should be done based on actual user transactions.
  • Boccaccio inquires about the differences between SVM and EVM, both in terms of specifications and execution environments.
  • Terry explains that the key differences involve parallelism. He states that SVM uses pessimistic parallelism, where all state access and accounts locked during execution are specified upfront, while EVM uses optimistic methods, running transactions as if there is no contention and re-executing if needed.
  • Terry also notes that in the SVM execution environment, an account can only occupy 25% of a block and that there are dynamic fee mechanisms for writing to specific accounts, unlike EVM’s global priority fee auction. These differences impact how users interact with dApps and the execution stack.

Exploring Eclipse: Enhancing Performance and Accessibility in the Blockchain Ecosystem

  • Boccaccio asks why the platform chose to be more than Solana and what “more” means in this context. 
  • Terry explains that as an L2, they can achieve higher performance from the execution environment than an L1 because L1s are encumbered by consensus, which involves communication and latency. He says that a single sequencer or rotating sequencers streamline transaction ordering, reducing latency and computation.
  • Terry mentions that L2s rely on verifiability of execution rather than consensus over the post-execution state route. This allows them to increase hardware requirements on the sequencer side while keeping verifier hardware requirements low. He notes that they want to push hardware optimization at the block producer level, which hasn’t been widely pursued yet.
  • Ren adds that building an L2 allows access to Ethereum’s liquidity while benefiting from the performance improvements of the SVM. He emphasizes that this enables cheaper and higher throughput roll-ups than existing Ethereum L2s.
  • Boccaccio inquires about the stack components beyond SVM for execution. Terry responds that they use SVM for the execution layer, Ethereum for trustless liquidity and bridging, and Celestia for the DA layer due to its higher performance. He mentions they hope to use risk zero for fraud-proof mechanisms.
  • Boccaccio asks if they will post on multiple DA layers. Terry says they will only use Celestia, as it remains cheap and can increase block sizes while maintaining verifiability.
  • Boccaccio questions the choice of Ethereum as the settlement layer. Terry explains that Ethereum’s liquidity is a significant factor, providing trustless access to extensive liquidity.
  • Boccaccio asks about user differences between SVM L2 and EVM L2. Ren states that user experience won’t differ much except for the types of wallets integrated. He points out that the dApp ecosystem will be optimized for scalable applications within an ecosystem, rather than moving to an appchain upon finding product-market fit.
  • Ren also mentions that users will benefit from the intersection of various ecosystems, with access to $ETH and Solana assets, as well as assets bridged using Hyperlane and IBC. He concludes that the user experience will resemble Solana’s, with a mix of Solana native and Eclipse native developers focusing on games, NFTs, and other consumer applications.
  • Terry says that the only reason for Eclipse to exist is if they can significantly improve the experience for the average user by reducing latency, lowering costs, and increasing transactions per second (TPS) by an order of magnitude or more.

Eclipse’s Strategy for Attracting Developers: Bridging Ethereum Liquidity and Solana Efficiency

  • Ryan asks about the go-to-market strategy for getting developers to build on Eclipse, especially considering the increased competition from Solana. He wants to know the value proposition for a developer to build on Eclipse instead of Solana.
  • Ren explains there are two perspectives. First, he mentions that ETH mainnet’s TVL is still significantly higher than Solana’s, though Solana has higher capital efficiency. For Solana developers, Eclipse offers access to Ethereum’s liquidity while maintaining Solana’s performance benefits. For Ethereum-based developers, Eclipse provides low fees, parallel execution, and a solution to avoid the noisy neighbor problem, ensuring a smooth user experience.
  • Ren continues by addressing why a developer might not opt for an appchain. He notes that builders often go for appchains due to lack of dedicated block space and the need for sticky paying customers. Eclipse aims to aggregate roll-ups into an interoperable ecosystem where the collective value surpasses the need for individual appchains.
  • Ryan asks about Eclipse’s roadmap in the context of Solana’s roadmap, specifically mentioning Firedancer and its association with Jump.
  • Terry says that Eclipse will adopt the Firedancer architecture when it becomes available on mainnet. Firedancer’s modular design scales linearly with more cores, and its signature verification stack uses an FPGA. Eclipse plans to use a more sophisticated FPGA and solve memory issues to allocate more threads in execution. They aim to be fully mainnet compatible.
  • Ryan clarifies if being mainnet compatible means that a developer can easily transfer their SVM application to Eclipse. Terry confirms this.
  • Ren adds that while Eclipse will utilize developments from Solana, they also aim to contribute back to Solana. Eclipse plans to conduct significant research, particularly in core validator optimization and transaction fee markets, to inform their own roadmap and enhance the SVM performance for both Eclipse and Solana.
  • Ryan asks if there are any design decisions that the team is considering which would differ from the current roadmap.
  • Terry explains that they are strongly considering adopting multidimensional fees to handle network congestion better than Solana, noting that their current configuration is cheaper but anticipates more spam. He highlights the benefits of synchronous composability within an L2 ecosystem, emphasizing the importance of value accrual back to dApps, local fee markets, and scalable L2s.
  • Boccaccio asks about the steps they will take to onboard dApps given the fierce competition and mentions the CSR concept’s limited success for Canto.
  • Terry responds that the chain must provide reasons for developers to deploy on it, such as increased revenue. He mentions exploring various mechanisms, including MEV redistribution, which hasn’t been deeply considered in L2s yet.
  • Ren adds from a go-to-market perspective that driving demand for block space involves not just DeFi primitives but also creating standout, high-retention dApps that uniquely utilize SVM as an Ethereum L2. He believes that exceptional dApps will draw users to the chain.
  • Terry adds that chains often make mistakes by being highly opinionated with capital allocation, citing the example of Arbitrum’s gaming fund. He argues for a more agnostic approach that supports novel ideas rather than replicating past successes.
  • Ren highlights the importance of distribution for builders, noting that their ecosystem introductions and go-to-market-focused podcasts aim to provide practical insights and support for creating successful dApps. He stresses the need for standout dApps and avoiding recency bias in driving ecosystem success.

Exploring MEV Attribution and Sequencer Design: Challenges and Strategies in Blockchain Development

  • Boccaccio asks about MEV returns to sequences, noting that there’s no decision yet on how it will work, and asks what choices are being considered.
  • Terry explains that they have talked to various people about the problem, focusing on the attribution issue. They consider an auction mechanism at the sequencer level, as they control block proposals. He mentions that it’s crucial to ensure that the MEV generated is properly attributed to the dApps instead of users and references Flashbots’ MEVshare product as an example.
  • Terry continues, saying they are still figuring out the exact construction, but it mostly revolves around the attribution issue, which might not be solvable. He highlights that dApps want to accrue value and avoid competition from other MEV events or token mints on the base layer. If these issues are resolved, dApps would stay on the chain without moving to appchains.
  • Boccaccio thanks them and shifts the topic to attracting users to the chain. He points out issues with metamask snaps and Salmon Wallet limitations and asks about the roadmap for onboarding Solana wallets.
  • Ren says that currently, users can only use Metamask Snaps or Salmon Wallet on Testnet and DevNet. He identifies a phishing risk with SVM chains due to chain IDs, where a malicious snap can exploit the system. Ren mentions that they plan to propose a solution for this issue and assure Solana users that they have other wallet partners lined up.
  • Boccaccio asks Terry about their sequencer design, mentioning recent discussions about sequencing.
  • Terry articulates his strong opinions on the matter, discussing the centralization risk with pre-confirmations and the fragmentation introduced by rollups. He adds that shared sequencing is more a social issue than a technical one, referencing Justin Drake’s viewpoint.
  • Terry further expounds that chains like Arbitrum have incentives to build their shared sequencers, leading to isolated systems. He critiques the idea of having Ethereum L1 proposers act as shared sequencers due to performance constraints and centralization risks, referencing Vitalik’s post.
  • Terry says that their goal is to be super scalable, solve the noisy neighbor problem with local fee markets, and return value to dApps. If successful, dApps would not need to build their own appchains, thus avoiding the need for a shared sequencer mechanism.

Exploring Eclipse’s Vision: DeFi, NFTs, and the Future of Roll-Ups and Scalability

  • Boccaccio asks about the apps that Eclipse envisions, considering its high performance and attraction of certain apps due to the SVM and liquidity.
  • Ren mentions that there is a good mix of apps, including DeFi, consumer NFTs, and native Eclipse dApps. He notes that most current developers do not need high throughput but anticipate future scalability issues. He also highlights an upcoming hackathon with five different verticals, aiming to attract more developers.
  • Ren explains that they want to remain agnostic and enable builders to create value for users. He finds ideas like parallel execution environments interesting, citing the example of sharded AMMs that can offer higher throughput. He also expresses interest in more consumer breakout dApps, noting that current DeFi applications are limited and consumer apps are gradually taking off.
  • Boccaccio asks Terry about fragmentation and the evolution of roll-ups over the next few years.
  • Terry predicts that more roll-ups will acknowledge the downsides of fragmentation and aim to become the central point for all dApps. This requires elements like local fee markets and fee redistribution. He believes it is naive to think one chain will dominate the L2 landscape entirely, as there will always be reasons for unique app chains.
  • Ryan asks about the possibility of multiple leaders on the Solana roadmap and its comparison to Eclipse.
  • Terry explains that multiple leaders reduce monopolistic games, enhancing fairness. He mentions that Eclipse aims to differentiate on execution and prefers a trusted sequencer with strong censorship resistance and verifiability.
  • Ren mentions an upcoming hackathon at the end of July, 2024.

Check out these important links

Show Information

Medium: YouTube (Video)

Show: 0xResearch

Show Title: Eclipse and the Next Generation of Rollups | Terry & Ren

Show Date: July 5, 2024