What is Eclipse?
Your fully-configurable, composable infrastructure platform supporting a blockchain designed just for you — with no compromise on security, reliability, or convenience. Time to build your own rollup!
As a smart contract developer, you’re probably not often thinking about how blockchains work under the hood.
Luckily, that’s what we think about every day at Eclipse. While so-called monolithic chains handle all functions of a blockchain internally, modular rollups break these functions up so you can mix-and-match your favorite parts.
Let’s break down the functions of a blockchain so you can figure out how to assemble the perfect chain for your application.
The virtual machine is the part of a blockchain that executes machine instructions. When a transaction reaches a blockchain, it is processed by the virtual machine. Every language, whether Solidity, Rust, or Move, is ultimately converted (compiled) to bytecode which is executed by a blockchain’s virtual machine.
Different languages support compilation to different bytecodes. For example, Solidity is typically compiled to Ethereum Virtual Machine (EVM) bytecode, but the Solang project enables you to compile Solidity to other bytecodes such as WebAssembly (wasm) or Berkeley Packet Filter (BPF).
With Eclipse, you get to pick the virtual machine for your blockchain. How should you decide?
- Performance: Some virtual machines are designed to enable greater parallelism across transactions, such as the Sealevel (Solana) VM, MoveVM, and FuelVM. Others typically do not support parallelism such as the EVM.
- Security: Languages such as Rust and Move can protect against many bugs that Solidity does not. For example, Ethereum smart contracts are vulnerable to so-called reentrancy attacks.
- Community: Popular blockchains like Ethereum and Solana have fostered thriving developer communities around the EVM and SVM respectively. This means better tooling and developer support compared to newer virtual machines like the Move VM or Fuel VM.
- Ease-of-use: Languages such as Solidity are easier to code in, and not all bytecodes support compilation from Solidity. On the other hand, Rust is typically considered more difficult to code in.
Right now, Eclipse supports the Ethereum Virtual Machine and the Solana Virtual Machine. We will add other virtual machines in the future as dApps request them.
Our implementation of the EVM is 10 times faster than Optimism by leveraging the parallelism in the Eclipse virtual machine.
A node is a computer participating in running a blockchain protocol. There are two types of nodes: full nodes, which download full blocks and replay transactions, and light nodes, which do not. Light nodes just download block headers and see if the majority of the Ethereum network votes that the header represents a valid block.
Pop quiz: If the majority of the Ethereum network is compromised and you are running a full node, can you still determine what is the “correct” Ethereum chain?
The answer is yes, assuming you can connect to at least one other honest full node. This is because if you ever see an invalid state transition or bad signature, then you can just ignore it.
How about the case where you’re running a light node? Light nodes clearly rely on the majority of the network to say whether a block is valid. How can we modify this setup so light nodes don’t rely on an honest majority?
A sovereign rollup allows a light client to pass the last header it saw to all of the full nodes that it is connected to. This way, if an honest full node disagrees with the header, it can pass back some evidence that the header is invalid.
Light clients can relax their trust assumption by sending block headers to multiple full nodes.
For such a setup to work, the honest full nodes need access to the blocks of transaction data to generate the required proofs in case of an invalid block header. Data availabilitylayers take in blocks of transaction data and provide this assurance via data availability (DA) proofs.
Data availability layers are not yet live, though many have testnets. Your options include:
- Celestia, which invented the concept of modular blockchains and enables probabilistic sampling to provide proof of data availability
- Avail, which provides KZG commitments as the data availability proof — longer to generate but can provide stronger guarantees on DA
- EigenLayer (Eigen DA), which leverages the existing stake used on Ethereum
- Ethereum, which will eventually support data availability sampling (DAS) via various upcoming improvements
Eclipse supports Celestia, Eigen DA, and Avail, and we will offer additional options as applications make requests.
We define trust-minimization as an honest minority assumption (or better, such as a 1-of-N assumption) on top of an existing Layer 1 blockchain's assumptions. For a trust-minimized Eclipse chain, you need to run a Celestia light client, an Eclipse settlement layer light client, and the light client (if one exists) for the data availability layer of your choice. These are all lightweight operations.
Note that Eigen DA has no light client and instead is a data availability committee of the validators opting into Eigen DA. This means that you're adding an additional assumption which is stronger than an honest minority. Instead, Eigen DA provides economic guarantees, meaning that the validators participating in Eigen DA can get slashed if they misbehave. Similarly, if you pick Ethereum for DA, you have to run an Ethereum full node until Ethereum offers DAS.
We define security as the dollar value required to alter the history of the blockchain. Since we (solely) use the Layer 1 blockchain to define the ordering of transactions, the security of an Eclipse chain is the amount of stake required to re-org the underlying Layer 1. We will defer to existing analyses of proof-of-stake (POS) blockchains, but in general for POS blockchains, there is some dollar value that can be used to execute a long range attack, with the typical solution requiring an additional assumption called weak subjectivity.
So a transaction is processed by the virtual machine, then a block of data is produced and sent to the data availability layer. But how do we ensure that the transaction was executed correctly? What if the dApp was run incorrectly by a malicious operator?
This is what the settlement process prevents. There are two types of settlement: optimistic vs. zero-knowledge. An optimistic rollup lets the executor specify the result for each block of transactions, and it is the duty of verifiers to challenge results that are incorrect. A zero-knowledge rollup requires that the executor provide strong evidence that a result is correct.
The simplest form of settlement is to enshrine Ethereum, in which case a smart contract exists on Ethereum to handle fraud proofs or zero-knowledge proofs. This is how traditional rollups like Arbitrum and Optimism are constructed. A downside is that these rollups are tied to Ethereum.
Another option is to create a separate honest majority chain to handle settlement — bridging and passing proofs.
Just as the whole point of data availability is to enable an honest minority assumption for light clients, we would prefer to never impose an honest majority assumption on any part of the Eclipse architecture. As a result, we’ve architected Eclipse in a way to do settlement without relying on any Layer 1 blockchain, but while still maintaining an honest minority assumption. Specifically, our settlement process reflects the architecture in "Prerequisite: What is Data Availability?".
The Eclipse settlement layer is essentially a Celestia sovereign rollup without the capability to execute arbitrary smart contracts, and instead it is only used for bridging and passing proofs. All arbitrary execution occurs on separate execution chains. This is called a settlement rollup.
Currently, Eclipse offers optimistic settlement, but we are working on a zero-knowledge virtual machine leveraging RISC Zero.
While the most critical choice about your execution layer is the virtual machine, you can add various other customizations to your Eclipse execution layer to increase your protocol’s value accrual or add additional functionality. Below are examples of the kinds of customizations we have already built or which we can support in theory. For the time being, you should reach out to the Eclipse team if you have customization needs that are not specified below.
Technically, “gas” fees refer to coins paid to the Layer 1 blockchain. For your Eclipse chain, you can charge your users “sequencer” fees to pay for the costs of running your chain.
The first choice you can make is how much you want to charge your users:
- 1.Charge nothing at all and fully subsidize the cost of running the chain
- 2.Charge at-cost
- 3.Charge a premium
The second choice is what token to charge for sequencer fees:
- 1.The default token for your virtual machine: $ETH or $SOL
- 2.$USDC
- 3.Your protocol’s native token
By default, we charge at-cost using the default token for your virtual machine.
Other gas-related customizations include subsidizing or penalizing different actions by adjusting the gas cost, such as enabling completely gasless governance participation or reducing fees for KYC’d users who represent non-toxic order flow.
It’s your blockchain, so you can choose who you want to participate. This means that you can restrict who can operate your blockchain infrastructure, who can deploy smart contracts, and who can run transactions on your chain, enabling OFAC-compliant chains. You can geographically gate interactions with some applications on your chain or add age restrictions.
By default, your Eclipse chain is permissionless.
We have an engagement with Skip Protocol to offer MEV auctions for Eclipse chains. This means that arbitrage opportunities can be returned to your chain’s users, your chain’s applications, or your token holders.
If you have multiple chains, Eclipse can support cross-chain flash loans where collateral on one Eclipse chain can be used to pay for transactions on another chain.
Related: you can adjust block times for your app chain.
By default, we do no MEV redistribution.
We can support custom system programs for your execution chain. This means supporting new elliptic curve implementations that you might want to use on-chain, verifiable random functions (VRFs), or operations as sophisticated as matrix multiplication. By default, we add no custom opcodes.
You can create modular mempools where a valid block must include some subset of transactions, for example transactions that protect the security of an on-chain AMM. You can enforce royalties on NFTs. By default, we enforce no additional constraints on blocks.
Since Eclipse shares a virtual machine with Ethereum or Solana, you can deploy any smart contracts that are already written for the EVM or SVM.
You can even use existing tooling for the EVM such as Truffle or Remix or tooling for the SVM such as the Solana CLI or Seahorse Lang.
Just like how Metamask can easily connect to non-Ethereum networks such as Polygon or Binance, Eclipse is immediately compatible with any EVM wallets.
Eclipse chains implement the Solana JSON-RPC, meaning that you can paste your Eclipse chain’s RPC endpoint to other Solana protocols like Solscan. We are in the process of publishing a standard to more conveniently switch Solana wallets to Eclipse networks.
We have an engagement with Celestia Scan (Modular Cloud) to deploy modular block explorers for Eclipse chains. We support Etherscan for our EVM chains and Solscan for our SVM chains, but these block explorers don’t pull data from the data availability layer, so they add an additional trust assumption that the Eclipse sequencer is honest.
Hyperlane Bridge
The Hyperlane bridge is a full node bridge, meaning that it will pull data from your data availability layer of choice and replay the transactions on your Eclipse chain to independently verify correctness. This means that the Hyperlane bridge is able to provide fast finality bridging to and from Eclipse chains. The Eclipse team worked with Hyperlane to deploy their mailbox contracts for the SVM.
Inter-Blockchain Communication (IBC)
IBC is the standard bridge between Cosmos chains. Between Eclipse chains, we can support fast finality IBC bridging without any challenge period, because any misbehavior will trigger a challenge on our settlement layer and all execution chains will be rolled back.
To support trust-minimized IBC bridging to non-Eclipse chains, we impose a challenge period on IBC messages. We pass state roots as soon as they are generated by Eclipse chains, but they cannot be used for IBC state proofs until after a specified number of blocks (the challenge period). If a correct fraud proof is passed to the light client on the receiving chain within the challenge period, then all IBC messages after that point are removed.
Eclipse is not yet public. We have spun up a number of private testnets for our early partners which we charge at-cost.
The process:
- 1.Meet with a member of the Eclipse team to discuss your project
- 2.Meet with a Solutions Engineer to scope out a proposal for your application
- 3.Eclipse team spins up a customized chain for your project
- 4.Deployment & testing
At this time, we are particularly interested in partners who are willing to give feedback on their experience using Eclipse chains. We provide substantial Solutions Engineering resources for each partner so we can only support a small number of teams for now. If you think this is you, you should reach out to us via Twitter or email.
Last modified 14d ago