A virtual machine is a piece of software that can run programs. Specifically, the virtual machine executes smart contracts for a blockchain.

The Solana (Sealevel) virtual machine is a highly parallelized runtime that is constantly improving. For EVM blockchains such as Ethereum or Optimism, at any given point there is only a single program running. (This is called "single-threaded.") For the Solana VM, if you have multiple cores, you can run several programs at the exact same time, substantially increasing throughput. Moreover, the execution layer continues to improve:

• Seahorse Lang lets you write Solana VM programs in Python.
• Soon the Solana VM will support Move bytecode: https://docs.solana.com/proposals/embedding-move
• The Solana VM has a best-in-class fee market coming: https://twitter.com/aeyakovenko/status/1537270721570824192?s=20&t=uOV108no_nYGnkTPnizUMA

For comparison, a Layer 1 blockchain is a blockchain that does not depend on any other chain for security. Layer 1 blockchains require that the majority of voting power is honest. A rollup is a type of scaling solution that executes transactions outside of any Layer 1 and later posts the data to a Layer 1 retroactively.

For an optimistic rollup, a "sequencer" executes transactions and posts the result to a Layer 1 along with a bounty. A "verifier" can re-execute the transactions, and if it disagrees on the result, the verifier can challenge the sequencer via a "settlement layer." If the verifier is correct, the sequencer loses their bounty and the bounty is awarded to the verifier.

For a zero-knowledge rollup, sequencers execute transactions and generate a "validity proof" (evidence) that they executed the transactions correctly. Sequencers must provide this validity proof to the settlement layer for their work to be accepted. The validity proof is typically expensive to generate.

Eclipse is deploying as an optimistic rollup, but we are working on a zero-knowledge rollup in parallel.

A normal rollup executes transactions off-chain but uses the same base layer for settlement, consensus, and data availability. That's a simple design, but it's not good because that base layer is likely not the right choice for all of those functions.

A modular rollup separates the functions of a blockchain: (i) execution, (ii) settlement, and (iii) consensus & data availability. In Eclipse's vision for the future of rollups, you could pick any execution layer (ex: EVM, SVM, or Move), choose the right data availability layer for your needs (ex: Ethereum, Celestia, or Amazon Web Services), and settlement could occur somewhere else entirely.

This question requires some additional context. A full node in a blockchain network downloads all blocks (transactions) and executes them. A light node doesn't do that, but a data availability layer enables the light node to efficiently verify that blocks are available to all full nodes on the network.

Data availability is important because storing huge amounts of data limits how decentralized and scalable a blockchain can get. It would not be possible to build a decentralized Solana VM rollup without this critical feature. Most chains today don't provide data availability because they aren't designed for rollups. Celestia, Polygon Avail, and EigenLayer are all data availability layers, and danksharding will bring data availability sampling to Ethereum in the future.

Full nodes re-execute every transaction and determine the current state of the blockchain. What happens when these full nodes disagree? In general, the blockchain will fork.

For a blockchain where the majority of nodes are honest, the "fork choice rule" will dictate that the correct chain is whatever the honest nodes decide. For a rollup that does not make the assumption that the majority of nodes are honest, the majority of actors might be lying. As a blockchain user (light node), how do we determine which is the correct fork?

A settlement layer is a hub to verify proofs and resolve fraud disputes to determine the "correct" chain. The settlement layer also lets you move tokens between the execution chains (a bridge).

The Eclipse testnet will be available Q1 2023, and the Eclipse mainnet is targeted for Q2 2023. If you're a major protocol interested in getting early access to Eclipse, reach out to team@eclipse.builders or DM us on Twitter.