Improving Ethereum Scalability with Saga Ethlets

Designing an ideal Ethereum scaling infrastructure that provides a combination of desirable traits is an ongoing challenge in the crypto industry.

Designing an ideal Ethereum scaling infrastructure that provides a combination of desirable traits is an ongoing challenge in the crypto industry. Many approaches are underway, including Optimistic Rollups, ZK Rollups, Validium and Sidechains (which in turn encompass appchains, L1s and other modular stacks). Each of these solutions has numerous benefits as well as significant tradeoffs.

In this article, we will first get a sense of the landscape by exploring these tradeoffs. Then we will detail a new solution called “Ethlets” that uses a novel approach to resolving the challenge. A TL;DR summary of current solutions can be seen below:

Ethereum Scalability Primer and Framework

Before we can analyze the various Ethereum scalability solutions, we must first build a framework to categorize them. That begins with first understanding how Ethereum operates and scales. Let’s dive in.

Blockchains Are State Machines

Blockchains track the transition from one state to another based on a list of transactions. For example, the current state may show that I own 1ETH in my wallet, and my friend holds 0ETH. If I commit a transaction to send 1 ETH to my friend’s address, the next state will show that I own 0ETH and my friend 1ETH. The act of running the computation needed to run this transaction and update the state is called “Execution.”

Ethereum Is a Monolithic Chain

The process of updating the blockchain state machine can be divided into four sub-processes: Data Availability, Execution, Consensus and Settlement (DECS).

Data Availability describes the process of storing transactions (data) for a given blockchain in a location or locations where it may be accessed. While Data Availability defines which specific transactions are to be executed, the order of the transactions is generally not guaranteed.

Execution describes the process of running the transaction and generating a new state from those executed transactions.

Consensus describes the process of picking who gets to propose the next state. This step determines the ordering of transactions and gathers agreement that the execution is valid.

Settlement describes the process of updating the state proposed during the consensus stage to be the latest record.

In monolithic chains such as Ethereum, validators provide all of these important functions necessary to ensure the secure operation of the core blockchain. While this approach is simplest, it comes with difficult scalability issues.

Modularizing Ethereum

To scale Ethereum, we can move the execution part of state transition off of Ethereum. Generally, this is called “modularization,” and you can learn more about it here. If the execution is done outside of Ethereum, how can we verify that the execution was performed properly? We need a verification process on Ethereum itself. This happens in 3 steps.

1. Store All Transactions in a Data Availability (DA) layer

As mentioned previously, DA describes the process of securely storing a list of all transactions that was used to generate the state changes. We need to store this and have it available.

2. Store Regular State Commitments

State Commitment is the act of storing a snapshot of the states (or a hash of the states) at certain intervals.

Once we do the first two steps, we can always re-execute and rebuild every state that was committed. Every state transition is deterministic: State 1 + Transactions = State 2. The final step is to submit proof that the executed state transition is valid.

3. Submit a Proof to Validate Execution

There are two different ways we can verify that the execution is valid: Fraud Proofs and Validity Proofs.

Fraud Proofs

A Fraud Proof is a cryptographic proof that shows: State 1 + Tx =/= State 2

In a fraud proof system, when a state transition is invalid, someone submits a fraud proof that the specific state transition is invalid. Generally, this is a small proof that shows that a single sub-state transition was incorrect.

Pros: Because the proof only shows a fault in a very small subprocess, fraud proofs are usually significantly cheaper to run on Ethereum.

Cons: Note that technically, a lack of fraud proofs probably means there is no fault, but it is not guaranteed. We need some optimistic assumptions on security and tend to draw security implications due to this assumption.

Validity Proofs

A Validity Proof, on the other hand, is a cryptographic proof that shows that necessarily State 1 + Tx == State 2.

In a validity proof system, a proof is always generated and executed on Ethereum constantly.

Pros: The benefit of a validity proof system is that there are no additional security implications. Once the validity proof is generated and run on Ethereum, it is cryptographically guaranteed that the state transition is valid.

Cons: It is very expensive to generate validity proofs and run them on Ethereum.

Each of These Components Can Happen On/Off Ethereum

Depending on the type of scalability solution, the location where these 3 steps happen can vary. Data Availability, Fraud Proof and State Commitment can happen either on or off the Ethereum chain. Different scaling solutions combine different approaches in exchange for different tradeoffs.

An Analysis of Existing Solutions, Their Advantages and Disadvantages

Before we specify the design of an Ethlet, we will first take a moment to explore current approaches and analyze their shortcomings in order to illustrate the motivation for our design.

Sidechains & Appchains

Sidechains and Appchains come in different forms and typically take the shape of a sovereign blockchain that acts like its own chain. For this reason, all 3 steps outlined above are done off Ethereum.

  • Data Availability: Off Eth
  • Validity/Fraud Proof: Off Eth
  • State Commitment: Off Eth

In this Ethereum scaling strategy, Data Availability, State Commitment and Proofs are generally handled by validators running the sidechain, which are separated from Ethereum itself. Note that Saga Chainlets by default are a sidechain solution.


  • Affordable because DA, State Commitments and Proofs are all executed on the sidechain
  • For this reason, the sidechain is completely independent of Ethereum congestion
  • Can be instant finality, which makes bridging instant and cheap


  • Security is separate for the sidechain, and no Ethereum security is inherited
  • Generally hard to stand up as it requires a validator set, consensus algorithm, staking token, and economic value for the staking token

Re-staking products such as Eigenlayer can be used to borrow the security from Ethereum validators, but the sidechain only inherits partial security from the re-staked Ethereum. The sidechain does not inherit the entire security of Ethereum.

Rollups & L2s

Rollups and Layer 2’s (L2) use Ethereum for all 3 parts of the execution verification process.

  • Data Availability: On Eth
  • Validity/Fraud Proof: On Eth
  • State Commitment: On Eth

In a rollup, the Data Availability is handled by Ethereum. Every transaction that is executed by the rollup is committed into Ethereum using call data. There are two broad categories of rollup technologies: optimistic and ZK. Each of these solutions handle the State Commitment and Proofs differently.

ZK Rollups

ZK rollups leverage Zero Knowledge (ZK) proofs to show that the state committed is valid. In parallel with generating the state to be committed into Ethereum, the ZK rollup generates a ZK proof. Both the state hash and ZK proofs are submitted onto Ethereum. Ethereum runs the ZK proof and verifies that the state hash committed is valid.


  • Inherit Ethereum security (after a ZK validity proof commitment)
  • Most secure method — since Ethereum runs the ZK validity proofs to verify the state transitions, no outside parties need to be trusted


  • Currently very expensive
  • Before the execution of ZK proofs on Ethereum, there is no economic security; sequencers can be malicious without any repercussions
  • Finality time is limited by ZK proof generation and Ethereum finality, and assets cannot be bridged properly until ZK proof execution on Ethereum
  • Can add PoS-style economic security, but then (similar to appchains) the rollup becomes hard to stand up

Optimistic Rollups

Optimistic rollups batch transactions, execute them and generate state updates periodically. However, the state is not committed to Ethereum immediately. Optimistic rollups wait a few days (the challenge period) before the state is actually committed onto Ethereum. During this period, auditors are expected to challenge the state hash and submit a fraud proof if there is an issue. If there are no challenges during the challenge period, then the state is committed onto Ethereum.

This type of rollup is called “optimistic” because light nodes assume that the state is valid and continue to accept newly generated blocks during the challenge period. (Side note: this is very similar to how branch prediction works in CPUs).


  • Inherit Ethereum security (after a challenge period)
  • Cheaper than ZK — Fraud proofs are only generated and run when there is a problem detected by an auditor; do not need to be committed at regular intervals


  • Relies on auditors and challengers; if no one is watching, malicious activity can become final on Ethereum
  • Still very expensive because prior to dank sharding, streaming all transactions on Ethereum is expensive and depends on ETH gas rates
  • Single sequences are easy to stand up, but don’t have anything at risk. Before the end of the challenge period, there is no economic security; sequencers can be malicious without any repercussions
  • Very long finality — Before the end of challenge period, there is almost no economic security
  • Assets cannot be bridged properly until the end of the challenge period unless a sponsor running a full node is present
  • Can add PoS-style economic security, but then (similar to appchains) the rollup becomes hard to stand up


Validiums are similar to ZK rollups but only use Ethereum for State Commitment and Validity Proofs and keep Data Availability off chain. Usually, the DA is handled by some committee in the validium or an external DA solution like Celestia.

  • Data Availability: Off Eth
  • Validity/Fraud Proof: On Eth
  • State Commitment: On Eth


  • Inherit Ethereum security (after a ZK validity proof commitment)
  • No longer need to pay for Ethereum Data Availability


  • Data Availability needs to rely on off chain availability, introducing potential complexity
  • It is incredibly expensive to generate ZK proofs and also to run the validity proof on Ethereum regularly
  • Before the execution of ZK proof on Ethereum, there is no economic security
  • Finality time is limited by ZK proof generation and Ethereum finality, and assets cannot be bridged properly until ZK proof commitment on Ethereum
  • Can add PoS-style economic security, but then (similar to appchains), the validium becomes hard to stand up

What are Saga Chainlets?

Now that we have revisited the basics of Ethereum scaling strategies and their tradeoffs, before we dive into Ethlets, we will take a moment to introduce Saga Chainlets. Saga is a chain that launches other chains (an L1 to launch other L1s).

The Saga Mainnet automatically and permissionlessly launches fully decentralized PoS appchains called Chainlets. Each Chainlet is fully secured by Saga Mainnet validators using Cross-Chain Validation (i.e., validators are shared across many chains).

Each Saga Chainlet is equivalent to an Ethereum sidechain, so the verification methods are all off Ethereum.

  • Data Availability: Off Eth by Saga Validator
  • Validity/Fraud Proof: Off Eth by Saga Validator
  • State Commitment: Off Eth by Saga Validator

However, the one-click deployment makes it trivial to launch a Saga chainlet vs. a traditional appchain or sidechain.


  • Affordable
  • Scalability is completely independent of Ethereum
  • Instant Finality, making bridging instant and cheap
  • Extremely efficient and easy to launch (one click deployment, 3 minutes or less)


  • No Ethereum security

To learn more about Saga Chainlets, visit here.

Introducing Saga Ethlets

We can (in fact) configure Chainlets to inherit Ethereum security like any other rollup. Because we start from a fully decentralized Chainlet, many of the solutions can co-exist in the Saga ecosystem.

We have reviewed the entire landscape of Ethereum scalability solutions and have discussed the pros and cons of each. In an ideal world, we can instantly, and cheaply, generate ZK validity proofs and execute them cheaply on Ethereum. In this hypothetical scenario, ZK is (without question) the best solution.

In practice, there are real limitations as have already been highlighted in this article, especially the non-trivial expense associated with ZK rollups today. Given those limitations, the first Ethlet configuration we will support is Optimistic Ethlets.

Combining the best parts of Appchains, Rollups and Validiums

Optimistic Ethlets combine the configurability, speed and cost advantages of Saga Chainlets with Ethereum security for the best Ethereum scalability solution. The goal of an Optimistic Ethlet is to make Ethereum scaling as cheap as possible with instant bridging.

Data Availability

Generally an optimistic rollup requires a DA layer because it needs an avenue to collect user transactions and block proposals for a rollup in a censorship-resistant, available and safe way. Without an external DA layer tracking the canonical list of transactions that will be executed in the rollup, a sequencer may censor transactions without anyone knowing.

On the other hand, Saga Ethlets already have a decentralized set of validators to handle this part. Our system does not require Ethereum or an external DA source. We rely upon the Saga validators and Saga security for our DA. An external DA is only used for archiving purposes for redundancy. Due to this, Ethlets can use Filecoin, an external DA solution like Celestia, or 3rd party service providers with Amazon S3 instances to archive the transaction data.

State Commitment and Fraud Proofs

Our approach inherits Ethereum Security through an optimistic fraud proof (either optimistic ZK or interactive proof) mechanism with the following method:

  • At the end of each epoch (1 day if it matches Saga’s base Epoch), the transactions are batched, and the challenge period begins
  • At the end of the next Epoch (end of Challenge period), if there is no fraud proof challenge, the state hash from the previous epoch is committed onto Ethereum
  • At this point, every transaction from the prior epoch inherits Ethereum security
  • The blocks that are currently in the challenge period do not inherit Ethereum
    security, but have Saga security

There are distinct advantages to this type of verification process:

  • If there is a 66% attack on the Saga validators, all the honest validators will have a consensus fault
  • The fault can be used to automatically trigger an event to generate fraud proofs
  • Those who were honest need to submit a fraud proof will be rewarded with the
    slashed tokens from the attackers
  • We can set the economics, so every validator that submits a valid fraud proof is rewarded (not just the first one)

The Ethlet verification system does not require explicit auditors; if there is a single honest Saga validator (or full node operator), they will catch any fraud in the Saga consensus layer and submit a fraud proof. Conversely, an attacker needs to control 100% of the validators and every full node to successfully attack the network.

Saga Ethlet is the Best Ethereum Scaling Solution

Saga Ethlets combine the best qualities from every scaling solution into an easy-to-use product:

Saga Ethlets are the most affordable solution compared to alternative scaling strategies

  • Fraud proofs are only generated and run optimistically, enabling lower costs and speedups
  • Self-contained DA — do not need to pay Ethereum for DA
  • State commitments to Ethereum only happen once per epoch
  • Ethlets feature commodity pricing through our Chainlet auction mechanism

Saga Ethlets have the best security tradeoffs

  • Prior to the challenge period, there is still significant economic security with Saga
  • After the challenge period, the Ethlet inherits full Ethereum security
  • Most secure because it does not rely on single sequencers
  • No need for external auditors — Due to PoS, there is always an automatic set of auditors (other validators) who verify state hashes

Saga Ethlets have instant finality and therefore fast bridging. As long as the bridge operators and the counterparty chain trust Saga security, the bridges can have instant finality. Finally, Saga Ethlets are incredibly easy to provision with one-click deployment.

To review:

Bringing Security Flexibility to Developers

By designing every Ethlet to start as a Chainlet, we can give flexibility to developers in a single system. Not every developer needs full Ethereum security from the beginning. With Saga, a developer can launch a Chainlet with Saga security. Then, when they are ready, they can convert Chainlets to Ethlets and inherit Ethereum security. Finally, when ZK technology is ready and cheap enough, we can also create ZK Ethlets to submit state hash and run ZK proofs on Ethereum periodically instead of optimistically. Saga will be able to automatically launch sidechains, optimistic rollups and ZK rollups depending on the needs of the developer.

Next Steps

As mentioned, ZK is a very attractive solution because it offers the best security out of all configurations. Some additional research needs to be done regarding ZK before Saga can prioritize ZK Ethlets:

  • ZK proofs for non-EVM state changes: there are many features such as Inter Blockchain Communication (IBC) and pre-compiles that do not affect the EVM state directly. There needs to be more R&D on a ZK solution that can encompass these interactions.
  • Before ZK becomes affordable, we can explore using ZK technology for fraud proofs similar to interactive games in optimistic rollups. This way, there can be an optimistic ZK fraud proof system until a full ZK solution is made more affordable.
  • Making ZK proof generation faster and cheaper is required before it is usable in appchain solutions such as Saga.

Because Ethlets are Chainlets with extra components on top, the Ethlet development roadmap is directly aligned with our existing Chainlet development roadmap. Developers can experience Ethlets in our existing testnet. If you are interested, come build on Saga. Our testnet is live and freely available for your deployment if you join our Innovator Program. Apply here.


There are various Ethereum scalability solutions, each with their own tradeoffs. Rollup solutions have multi-year technical roadmaps to gain the same advantages that are offered by Ethlets today. Significant research and development are needed to implement decentralized sequencers as well as execute fraud and validity proofs cheaply on Ethereum.

However, by starting with a fully decentralized Chainlet, Ethlets can leapfrog these research hurdles and provide significant benefits compared to other scalability solutions. Ethlets can be an order of magnitude cheaper than other rollup solutions. At the same time, Ethlets can have an order of magnitude faster finality and bridging speed. Ethlets always maintain a baseline security through the Saga validators, but eventually inherit the full Ethereum security.

We believe Ethlets offer the best tradeoff compared to any other Ethereum scalability solution.

Join Us!

If you are building a cool game, entertainment or DeFi project, we’d love to hear from you! Please fill out the information in this form, and we’ll be in touch.

Be sure to join Saga’s Discord and Telegram and follow Saga on Twitter for the latest news and updates.

Journey On!

Saga Team