Scalability of Ethereum: Overview of Rollups & Deepening of the StarkNet Ecosystem
May 24th, 2022


After enjoying tremendous traction since its release in 2015, Ethereum Mainnet - or Ethereum Layer 1 (ETH L1) - from his succes. Its scalability is limited and the network is increasingly suffering from recurring congestion due to exponential user growth. At from his succes of high usage, large increases in transaction cost and longer validation times.

These constraints penalize the user experience of Ethereum and impact put development, adoption, and scope of possibilities.

Several solutions to overcome these limitations have been studied. This article aims to introduce you to one of them : StarkNet.

To do this, we will :

  • Briefly present the main solutions that exist to solve the scalability problem of Ethereum,
  • Focus on Rollups and present their general technical functioning,
  • Tell the story of StarkWare and the development of StarkNet,
  • Present the StarkNet ecosystem.

Authors' notes : We are not members of the project and we wanted to write this article to deepen our knowledge of the ecosystem and to share it with as many people as possible. We are not technical experts. We are not technicals experts* and therefore some elements may have been misunderstood and misrepresented. If you notice any big mistakes, we invite you to contact us by DM on Twitter @nono01022 & @cleminso.

We have consulted numerous sources available on the internet to compile this article. We have tried to appropriate as much knowledge as possible and transcribe it for you in the most comprehensible form. We have tried to follow a strict journalistic process. However, if you, the authors who read this article, feel that some of your work has been used in this article without credit & without your agreement, please let us know in DM and we will find a solution.

1. Scalability solutions

a. The other Layer 1

As Ethereum may appear to be poorly designed, one of the ideas followed was to completely rebuild a more scalable and faster Blockchain. There are many examples of such blockchains: Binance Smart Chain (BSC), Avalanche, Fantom, Harmony, Solana, etc. The so-called EVM compatible blockchains use the Ethereum virtual machine to work, otherwise, they speak the same language and so an app written in solidity can also be deployed on all other compatible EVM chains without modification.

However, according to the blockchain trilemma, these advantages are often gained through a "compromise on" (read "less of") decentralization. One sacrifices the resilience of the blockchain for speed and scalability. (This is not always the case, we do not always sacrifice decentralization, but at least one of the three components)

b. Sidechains

They are generically called SideChain, i.e. they evolve in parallel to Ethereum. These include Polygon & Gnosis Chain. They behave like Layer 1 alternatives to Ethereum, validating transactions directly on their chain.

However, they regularly send activity reports of their Chain on the Ethereum blockchain. This gives them greater resilience in the event of a problem on their network.

c. Modifying the structure of Ethereum (e.g. The Merge)

It would be relevant to have the following thought: "Ethereum is a software: just update it !”

Indeed, it is possible to update and implement new features in the Ethereum blockchain. These modifications/updates are called EIP for Ethereum Improvement Proposal. Very simply, the process is as follows:

  • The proposal is proposed and written and given a number: for example EIP1559.
  • Discussions are held by the community on this proposal: advantages, disadvantages, development, operation, implementation...
  • If a majority agrees on a consensus, it will be followed by the community: implement the proposal, rework it to improve it, or abandon the EIP.

However, to improve scalability, one would have to touch the very core of the Ethereum machine. And that's complicated. Very, very complicated.

Imagine, with the current means, repainting the entire roads of France with yellow paint. This without interfering with the usual traffic, so:

  • without stopping any vehicle,
  • or blocking any road,
  • or leaving yellow marks on the tires of road users.

We are approaching the level of difficulty of The Merge.

We have to manage to update the Ethereum blockchain, without putting the traffic on it on hold, and ensure compatibility with the entire ecosystem, which continues to develop day after day.

It is an operation that is extremely complex and takes years to organize. The Merge represents the biggest update to a blockchain ever made. Without going into detail about every change it will bring, and only on the point of scalability: it will allow improving very slightly the speed of Ethereum Mainnet (around 10%) by reducing the average time of validation of blocks from 13.5 seconds to 12 seconds. This is not enough for the current and future traffic.

So why not do more? Because we are once again confronted with the Blockchain Trilemma mentioned above. Ethereum does not seek to compromise on security and decentralization. It is one of the most resilient blockchains behind Bitcoin. Moreover, other tracks seem much more efficient, and less restrictive to implement.

d. The Rollups

  • Ethereum has a maximum number of transactions per second (TPS) that is too low for its popularity.
  • The validation system for transactions and the blocks in which they are stored is the most important thing to ensure the veracity of the information and its durability.

Why not move some of the transactions of the Ethereum Mainnet and send back only some of the most important information in a compact form on the Mainnet, without leaving the Ethereum ecosystem?


  • We remove the management/validation of these transactions from Ethereum Mainnet, which will be decongested.
  • There is no compromise on security, because :
    • We do not leave the Ethereum ecosystem,
    • We send back essential data proving the validity of these transactions to the Mainnet.

This is what rolls do. They move the computation (and state storage) off-chain but retain some data per transaction on-chain.

"In practice, smart contracts are deployed on the main chain and act as bridges between ETH and second-layer solutions. When a large number of transactions are recorded on the Rollup, these are aggregated and published on Ethereum Mainnet as a single transaction, again via smart contracts. " (source: coinacademy)

Transactions are validated outside the Ethereum blockchain (off-chain) before being aggregated and sent to ETH L1 as a single transaction.

There are two main categories of Rollup, with different operations and performances:

  • Optimistic Rollups (Arbtirum, Optimism, (etc.)
  • Zero-Knowledge Rollup* or ZK-Rollup. (Loopring Zk-Sync, StarkNet, etc.).

2. Rollups

a. Common operating principles.

The operation of Rollup uses the notion of a Merkle Tree.

A smart contract deployed on the Ethereum mainnet will maintain a state root, which corresponds to the state of the data contained inside the rollup (account balance, contract code, etc.). This state will evolve as a result of interactions performed in the rollup (transactions, interactions with smart contracts, etc.). These changes are aggregated together with the old state root and are highly compressed via a whole system of compression tricks. This is called Batch Release.

The contract will then check that the previous state root of the Batch matches its current state root, and if it does, the new state root takes the place of the previous one in the Roll-up contract.

New interactions can take place, leading to the publication of a new Batch, etc.

b. Validity of transactions

The previous paragraph describes how a batch is validated against his previous state.

But nothing prevents a fraudulent author from passing a transaction in which he would transfer the entire contents of the Rollup's wallets to his own wallet ? **

  • In other words: How are the transactions in a batch considered valid and not fraudulent?

This mechanism for verifying transactions - and thus securing funds - has led to discrepancies between the various rollups.

c. Optimistic Roll-up

Optimistic Roll-ups use a Proof of Fraud.

The users of the roll-up will, through their activities, make transfers and publish their interactions on the network. They will therefore modify the state of the roll-up. They are called transmitters.

Then, the aggregators aggregate the transactions into batches and publish the change of state on the Ethereum Mainnet.

The rules for selecting who qualifies for this position differ depending on the characteristics of the roll-ups, but in general, to submit a batch, they must deposit a substantial amount of money to guarantee their bona fides. If they are found to have engaged in fraudulent behaviour: this deposit will be partly burnt or given as a reward to the one who has proved the fraud.

The Rollup contract keeps a trace of all its history, its state roots over time and the cryptographic borrowing of each Lot. And anyone can verify that each cryptographic fingerprint of a batch matches its associated state root. Each Batch can be verified for 7 days after publication, before it is final.

In real life: This is why when a withdrawal of funds is made from an Optimistic Roll-up to the Ethereum Mainnet, there is a 7 day waiting period.

During these 7 days, verifiers - anyone who can calculate the state root and check if it is correct - will come and perform checks between a batch's cryptographic fingerprint & state roots. Now, if it turns out that a batch had an incorrect post-state root, the verifier can publish a proof (the valid state root) of this on-chain error, proving that the batch was miscalculated. The contract verifies the proof and returns this and all subsequent batches.

The verifier will thus be rewarded and the fraudulent aggregator punished, the former getting back part of the collateral deposited by the latter.

d. zk-Rollup

The zk-rollup uses Proofs of Validity.

As with Optimistic Rollups, we will find the senders and the relayers (=aggregators). The latter is in charge of collecting & aggregating the transactions. The aggregators will then publish the transactions in a Rollup and generate a proof, which represents the difference in status of the accounts before and after the Rollup.

i. Principle of technical operation - Allegory of the cave

  • Imagine a ring-shaped cave with a single entrance and a magic door that separates two side paths. To get through the magic door, you have to whisper the appropriate secret words. Imagine that Alice wants to prove to Bob that she knows the secret words - while keeping them secret. To this end, Bob agrees to wait outside, while she enters the cave and walks to the end of one of the two possible paths. In this example, she decides to take path 1.
  • After a while, Bob walks past the entrance and shouts out which way he wants Alice to appear (path 2 in this case). If Alice knows the secret, she will probably show up on the path Bob choose. This whole process can be repeated several times (*potentially an infinite number) *to confirm that Alice is not choosing the right path by chance.
  • Zero-knowledge proofs allow one individual to prove to another that a statement is true, without disclosing any information other than the validity of the statement. The parties involved are commonly referred to as "provers" and "verifiers", and the certificate they hold in secret is called a "witness". The main objective of such evidence is to reveal as little information as possible between the two parties. In other words, zero disclosure evidence of knowledge can be used to prove that one possesses certain knowledge without revealing any information about the nature of the knowledge itself. (source)


The acronym stands for Zero-Knowledge Succinct Non-interactive ARgument of Knowledge. (source)

If we break down the acronym on an English basis, we have this:

  • Zero-Knowledge: Ensures confidentiality of transactions.
  • Succinct: means that the evidence is small and can be quickly verified.
  • Non-interactive: There is little or no interaction between the "prover" and the "verifier" (this used to be the case on older systems). So there is little risk of collusion between the two.
  • Argument: is considered computationally sound, which means that a dishonest prover is very unlikely to cheat successfully. This property is called soundness. The Argument could be falsified if an actor had excessive computing power, which is why some consider quantum computers a threat to zk-SNARK.
  • of Knowledge: It is not possible for the prover to construct proof without actually having the information (or witness) to back up his statement.

These proofs are created cryptographically, to prove that the post-state root is the correct result of the batch execution.

zk-SNARK allows, via the generation of this proof of validity, to reduce the amount of information contained in a roll-up and thus to be even more scalable than Optimistic.


  • Argument: The strength of the argument assumes that the prover has limited computing power. Theoretically, a prover with enough computing power could create false proofs (risk quantum computer mentioned above).
  • Non-iterative: Although there is little or no interaction between a prover and a verifier, zk-SNARK proofs depend on an initial secure configuration between a prover and a verifier, which means that a set of public parameters is required to construct zero-knowledge disclosure proofs and, hence, private transactions. These parameters are similar to a game rule, they are encoded in the protocol and are one of the factors needed to prove the validity of a transaction. However, this creates a potential point of centralization, as the parameters are often developed by a very small group.

In real life: If someone had access to the randomness that generated the initial configuration parameters, they could create false evidence that would look valid to the verifier.

Generation of the Validity Proof: It requires more effort and computation, which may limit the scalability of the system, compared to an Optimistic roll-up.

iii. zk-STARK

The zk-STARKs were created as an alternative version of the zk-SNARKs proof with the following improvements: It does not require an initial trust configuration. The T, therefore, stands for Transparent. It replaces the N (Non-iterative).

In fact, to do without this initial trust configuration, zk-STARKs rely on cryptographic methods that are resistant to collusion between prover and verifier. And this has the consequence of :

  • eliminate the risk of expensive zk-SNARKs.
  • eliminate the risk of attack by very powerful computers (of the quantum type)

Indeed, with zk-SNARKs, the number of exchanges between provider and verifier is correlated to the difficulty of calculation. This is no longer the case with zk-STARK, where the number of communication rounds remains stable between the parties. The data size is, therefore, smaller on zk-STARK, which allows for a less expensive and faster implementation of the technology.

Weak point:

It allows Turing Completeness, which makes it difficult to support the Ethereum Virtual Machine (EVM).

Explanation of the term:

Scalability (S): means that two efficiency properties hold simultaneously (ref) here is taken into account that the prover and the verifier

Transparency (T) : means that there is no need for trust configuration, there is no use of secrets in the implementation of the system, unlike SNARKs.

Benefits: Eliminates the parameter configuration generation procedure which is a potential weakness

e. Comparison & performance

In order to better visualize the numerical advantages of a roll-up, here are some comparisons between different actions executed on a roll-up and on L1. This information comes from the Ethereum-France website and is taken from an article by Vitalik Butterin.

f. Decentralization plan

In practice, roll-ups are not yet decentralized. As part of their development and in order to ensure the responsiveness and efficiency of corrections applied to these newer systems, many centralization points remain. However, the long-term vision of all roll-ups is decentralization.

StarkNet has chosen to focus its development in the following order: Use → Performance → Decentralization.

After having developed the Usage part (with StarkEx in particular), the Performance part will arrive during 2022 with the release of StarkNet on the Mainnet. The start of Ddecentralization is expected to begin later (probably 2023). The decentralization plan is expected to be finalized in the coming months, which is currently being discussed at the Governance Forum. This will concern:

  • Full-node development: Anyone will be able to check and keep a copy of the network locally. 3 teams developing full nodes (Erigon, Nethermind & Equilibrium)

  • The opening of the sequencing and proving of transactions, with the release of a software to the public: anyone can participate in sequencing and proving on StarkNet.

  • A reward structure will be developed for those involved, including monetary rewards. The fees generated by Starknet will be redistributed in part to the sequencers and proofers.

  • In the medium term the sequencer developed by StarkWare will be available to third parties, and in the long term they hope to see new teams building dedicated sequencers on SartkNet.

    A whole program that won't happen in one day!

g. Data availability

Data availability is one of the big levers for rollups.

It consists of whether or not to return the information of the transactions carried out and validated on the rollups. This allows in one case:

  • Ensure the security of transactions on Ethereum Mainnet, but increase and the amount of data to be returned on the L1 at the expense of gas charges.
  • To be able to carry out transactions at an extremely low cost, keeping their data on the Rollup. Thus, in the event of failure of the Rollup, it would not (theoretically) be possible to trace the transactions.

On Optimistic: Data Availability or DA is available on L1.

On the zk-roll-up: the systems differ and alternatives are studied:

  • On StarkNet: Thanks to Volition, it will be possible independently, for each transaction, to send the data back to the L1. This will affect the price of Tx’s fees, and the unreported data will be kept by a Data Availability Committee, which is deemed secure but centralized.

  • On zkSync: It will be possible thanks to zkPorter to create sub-accounts where the Tx Data will not be brought back to the L1, in order to increase scalability. The data will be backed up by a network of “Guardians” who will be rewarded by the native ZkSync Token.

    3. StarkNet

    StarkNet is a zk-STARK developed by the company StarkWare.

    a. Story of StarkWare

    The company StarkWare was founded in 2018 by an experienced team of more than 70 people today, here is the presentation of the co-founders:

    • Eli Ben-Sasson, president and co-founder

    He received his Ph.D. in Theoretical Computer Science from Hebrew University in 2001. He conducts research in cryptography, specifically on zero-knowledge proofs. Known as the co-inventor of STARKS and the Zerocash protocol, he is one of the founding scientists of Zcash. Eli will hold research positions in mathematics at the Institute for Advanced Study at Princeton, as well as at Havard and MIT.

    Linkedin | Twitter

    • Uri Kolodny, co-founder and CEO

    He holds a B.Sc. (Magna cum Laude) in Computer Science from Hebrew University and an MBA from MIT Sloan. He has also co-founded other technology companies such as OmniGuide and Mondra. He also worked as an EIR for two Israeli VCs and as an analyst at McKinzey.

    Linkedin | Twitter

    • Michael Riabzev, co-founder and Chief Architect

    With a PhD in Computer Science from Technion Israel Institute, Michael focused on developing practical systems for computational integrity in zero-knowledge leading to the implementation of the zk-Stark system. He has 14 years of experience in software development, including at Intel and IBM Research Labs.

    Linkedin | Twitter

    • Alessandro Chiesa, co-founder and Chief Scientist

    He is a professor of computer science at the University of Berkeley, researching areas such as complexity theory, cryptography, and security, as well as the practical applications of zero-knowledge proof.

    Like Eli, he is co-inventor of the Zerocash protocol and co-founder of the Zcash company, he is also the author of Libsnark (an open-source library for short zero-knowledge proof demonstrations).

    Linkedin | Github

    StarkWare raised $161 million from various “Ventures Capital”* such as: Paradigm; Pantera (The list is available on official website and details are available on Cypherhunter

    In addition, they received a $12 million grant from the Ethereum Foundation. Among the leading investors are big names such as Vitalik Buterin - co-founder d’Ethereum - and Naval Ravikant - known for being one of the founders of AngelList and CoinList and an investor in many web2 and web3 projects.

    Details of fundraising:

StarkWare co-founder
StarkWare co-founder

b. StarkEx – First product of StarkWare

StarkEx launched in June 2020 is the engine dedicated to the scalability of the secondary layer of Ethereum. Already deployed on the mainboard, it allows you to perform complex operations:

  • Creation of financial products & derivatives,
  • Tokens & NFT Trading Applications,
  • Games using NFT.

This technology has been used to build DeversiFi, dYdX, Immutable, and Sorare applications.

StarkEx allowed the Starkware team to test its tools and gain a better understanding of the ecosystem’s needs. It incorporates price oracles such as Chainlink.

A strength of StarkEx is to be available in several modes of data availability, we find it 3:

  • Rollup, data is stored on-chain. Thus, transactions are recorded as call data.

  • Validium, data is stored off-chain. This is a more scalable solution that consumes a relatively fixed amount of blockchain resources, regardless of the volume of activity. This mode has the advantage of not requiring an on-chain payment. Only the cost in gas proof verification is required to update the state of the blockchain.

  • Volition, on-chain/off-chain hybrid solution allowing users to choose themselves at any time to choose or wish to store their data.

    c. StarkNet - Ethereum's scalability solution

    StarkNet is a decentralized, permissionless, censorship-resistant Zero-Knowledge Rollup (ZK-Rollup) that supports general computing on Ethereum. It is based on the Turing-complete language Cairo, different from Solidity.

    The scalability solution involves three network players:

    • developers. They can create applications, implement their own Business Logic and deploy them on StarkNet.
    • users. They can send transactions to StarkNet for execution, just as they interact with Ethereum today.
    • StarkNet nodes. They will receive crypto-economical incentives to ensure that the network functions efficiently and fairly.

    Its objective is to achieve the same security and permissionless properties as those of Ethereum.

    d. The Ecosystem

    This second part focuses on the projects developed on StarkEx and Starknet, which were launched in 2020 and late 2021 respectively for Starknet’s Alpha Mainnet.

    (Non-exhaustive list, to find out more about the project please visit StarkNet Ecosystem)


    StarkGate, the Official StarkNet bridge (currently available on mainnet and testnet)

    Orbiter Finance, a bridge specialising in asset transfers on Ethereum Mainnet, its Sidechains, and Rollups (Optimistic & Zk).


    Alpha Road Finance is a decentralized non-custodial platform that will in the future offer different services such as AMM as well as return strategies on personal assets.

    They also received a grant from StarkWare.

    Based in Switzerland, the team has previous experience on web2 & Web3 projects.

    SithSwap: AMM which seems to have a dynamic team with a veTokenomics, and having a Grant obtained by StarkWare.

    Starkswap, a classic WMA offering liquidity pools. Currently undergoing testing, the project has also received a grant from StarkWare.

    ZKX is a permissionless protocol for trading derivative assets with an order book, built over a year ago. Here is their presentation at the Amsterdam Hackathon by Eduard its founder:

    They also received a Grant from StarkNet

    Asset Lending & Borrowing Protocol

    zkLend is an asset lending and borrowing protocol built on StarkNet.

    The team wants to develop two solutions:

    • Armetis: permissionless service for DeFi users
    • Appollo: a permission-based service for institutional clients. Thus, it will be necessary to undergo a legal compliance check (such as KYC, KYB etc) in order to be registered on a Whitelist.
Figure 4. Comparison between Artemis and Apollo according to their proposed features. (WP p.9)
Figure 4. Comparison between Artemis and Apollo according to their proposed features. (WP p.9)

Magnety is an asset management protocol that proposes the construction of Vaults using different strategies deployed by users to optimize returns (like a Yearn with the possibility for anyone to deploy their own Vault).


Phi is a metaverse created from ENS domains and powered by the on-chain activity of participants. They propose to generate virtual plots of land for anyone with an ENS address to fill with objects representing their on-chain activities. A terrain is linked to its address, so if the address changes ownership, the terrain also changes, providing a new use case for ENS addresses.

Topology has a mission to combine cutting-edge research on zk-Proof systems to develop an on-chain metaverse with permissionless interoperability and composability.

The first game is Isaac, a cooperative game combined with physical and metaphysical laws such as the N-body problem and Factorio game mechanics, all on-chain.

Players play "Factorio" on the surface of a cuboid planet to direct the fate of their planet

The team consists of Guiltygyoza | Kunho, with more here.

Special mention:

With different products, OnlyDust wants to change the way we work by getting closer to the promises of Web3 with better incentives.

As a first step, the idea is to integrate and accompany developers wishing to learn the Cairo programming language (proposed to StarkNet), all with a playful approach and Gamification. Secondly, to identify the needs of the ecosystem and put them in touch with potential contributors.

A French team of 10 members co-founded by AbdelHamid, Paco and Grégoire

A little nod to Briq built by a French team (Sylve & Lancelot)

Briq is a construction game mixing Minecraft and LEGOs allowing to build universes that can be mined in NFT and translated on marketplaces such as PlayOasis but also be used in other games. Let your imagination run wild and create whatever comes to mind.

BlueChip rolling out on StarkNet:

Maker has announced, without further details, that it is rolling out on StarkNet. As a reminder, this DeFi dinosaur is the originator of $DAI, one of the oldest stablecoin dollars in DeFi. The protocol is currently only deployed on Ethereum mainnet.

Their arrival will go through several stages explained in this Tweet.

Aave has also seen the publication of a proposal suggesting the deployment of the protocol on StarkNet on February 1, 2022. The deployment of the protocol will be done jointly with StarkNet, with a shared deployment fee.

Acknowledgement !

Hopefully, this overview will give you a better idea of the potential of StarkNet and make you want to take part in this ecosystem that looks promising for the future of Ethereum.

Special mention to Nyfan and Reborn for his good advice, many thanks !

Ecosystem accounts to follow:

Odin / Louis Guthmann / Henri Lieutaud / Swagtimus

StarkWare / StarkNet Intern

Credit: @nono01022 & @cleminso

Arweave TX
Ethereum Address
Content Digest