Frequently Asked Questions (FAQs)
Find answers to some of the most frequently asked questions about Eclipse.
We've compiled a list of the most commonly asked questions about integrating with Eclipse. If you can't find what you're looking for here, please don't hesitate to reach out via Discord.
A virtual machine is a piece of software that can run programs. Specifically, the virtual machine executes smart contracts for a blockchain.
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.
Modular blockchains separate the functions of a blockchain: (i) execution, (ii) settlement, and (iii) consensus & data availability. In Eclipse's vision for customizable 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, 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).
Eclipse currently runs all the hardware for rollups, which is actually hosted on Google Cloud. However, our eventual goal is to enable anyone to deploy an Eclipse rollup and run the hardware themselves. One option is for everyone to run the hardware on Google Cloud, but that is not truly decentralized as it is still hosted in a data center.
This is where sequencers-as-a-service (ex: Espresso, Astria, and at one point Saga) come in – they allow anyone to provide their compute resources or pay someone else for their compute resources to run Eclipse nodes. The official term for running the nodes is "container orchestration," and when people buy or sell compute resources like this, it is referred to as an "interchain security fee market."
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.
The virtual machine (VM) is a crucial part of the execution layer for blockchains. Everything in the execution layer is built around the VM. This includes block times, gas payments, and wallet connections. The VM determines the programming language used to code for the blockchain. All processing for smart contracts occurs within the VM.
The formal way we define security is the dollar value to rearrange the history of a blockchain.
Layer 1 blockchains typically include on some honest majority assumption, and the higher the dollar value required to undermine this assumption, the better the security of the blockchain.
Low-fee blockchains do not have the same dollar value for security as Ethereum, as lower fees result in fewer validators or honest participants joining the network, making it easier to overpower. Transactions are tied to security, as in the case of Solana, where a penny per transaction is required for validation, and hundreds of thousands of dollars are needed to run a node. In contrast, it is cheaper to run an Ethereum node, but fees are fairly high, incentivizing more people to run the network.
- Throughput is not something that can be easily compared apples to apples across chains
- Transactions can be soft confirmed in 400ms
- We can handle up to 100,000 transactions per second, assuming that the transactions have non-overlapping states
- Dedicated data availability layers like Celestia are specifically designed to scale blockspace
- We can assist in architecting virtually any application, including web2 applications, to work on Eclipse
There are several components of a blockchain where centralization can occur, and the impact of this centralization can vary. Specifically, for a rollup like Eclipse, there are four components to consider:
- a sequencer, which proposes the order of transactions and which transactions get executed
- a verifier, which can challenge the correctness of a transaction’s execution
- a settlement layer, which mediates these challenges
- the base layer, where the block of transactions is stored.
To keep things simple, we will ignore other potentially centralized actors that are not unique to Eclipse/rollups/app chains, such as wallets, RPCs, indexers, and oracles.
Sequencer: By default, the Eclipse sequencer is centralized. A centralized sequencer cannot execute transactions incorrectly or falsify transactions. However, it can capture all of the MEV for itself by ordering transactions in a way that is favorable, and it can also censor transactions. We have several reasonable options for decentralizing the sequencer in the coming quarters.
Verifier: Currently, Eclipse runs the verifiers, but we are happy to set your team up with a verifier as well. The consequence of a centralized verifier is that it might not catch malicious behavior from the sequencer. The verifier ensures the correctness of the sequencer's behavior. In the future, this can be fully decentralized by allowing the community to run verifiers.
Settlement layer + base layer: Both of these components are decentralized for Eclipse by default.
Eclipse mainnets are targeted for Q4 2023.
We have spun up a number of private testnets for our early partners which we charge at-cost. Schedule a call with your engineers here: Run Your Own Testnet Chain
The mainnet revenue model for Eclipse is yet to be defined, but you can expect transaction fees to be in line with or cheaper than the cheapest blockchains such as Solana. An alternative revenue model for Eclipse involves the token for the purpose of decentralizing the sequencer.
It is much easier to spin up an Eclipse chain, but for now, the Eclipse team will manually spin up each chain until we decentralize this process.
- MEV auctions
- Block times
- Gas subsidies or penalties
- KYC chains, OFAC-compliant chains
- Modular mempools: prioritize different types of transactions to force inclusion
- Custom token for gas
- Verifiable randomness
- Automatic smart contract execution
- Frequent batch auctions (FBAs) to mitigate frontrunning
For the most trust-minimized bridging, yes. However, for most situations, this is not necessary, and you can bridge instantly.
In the same way that Polygon captures native Ethereum users because they can use people's ETH addresses as well as denominations in ETH-based assets, all Eclipse chains can do the same thing. You can use ETH addresses, nominate ETH assets, and bridge assets to Eclipse-based chains to any L1 or L2. We use the same tools!
We offer a variety of custodial, MPC, and non-custodial options. The experience is identical to using the Ethereum or Solana L1.
- Ponzinomics: P2E and other mechanics surrounding fungible tokens have led to a plummeting token price. We will assist in ensuring that your token and game mechanics have a sustainable source of yield.
- Security: Bridges are the most vulnerable parts of any blockchain architecture, and Axie Infinity suffered one of the worst bridge hacks in history after attempting to roll out their own solution. Benefit from the shared security and infrastructure expertise of Eclipse, so you can focus solely on your application logic.
Last modified 24d ago