Starkware is a ZK-rollup company that pioneered zero-knowledge-based rollups in 2018, launched StarkEx in 2020, and recently released StarkNet in November 2021. StarkEx is a ZK-rollup with less functionality than its StarkNet successor. StarkEx supports the ability for smart contracts to run any arbitrary logic for specific use cases, such as trading and NFTs, while StarkNet enables more general use cases.

Since its creation in 2018, Starkware has raised $110+ million across three equity rounds and received a $12 million grant from the Ethereum Foundation. Not only is the project backed by heaps of money, but prominent crypto and financial figures, including Pantera Capital, Sequoia, Founders Fund, DCVC, Paradigm, ConsenSys, Multicoin, Polychain, Vitalik Buterin, Naval Ravikant, and others, have also invested in Starkware.

StarkEx is the first iteration “scalability engine” from Starkware that now supports two versions: ZK-Rollup mode and Validium mode (discussed below). Validiums can be custom-tailored to offer superior performance for specific dApps and use cases, such as DeversiFi, ImmutableX, and Sorare.

StarkNet is Starkware’s next iteration of a ZK-rollup and the first ZK-rollup to feature general smart contracts on a fully composable network in a permissionless manner. Composability refers to the ability for applications to coordinate, build on top of one another, and interconnect—something for which StarkEx isn’t designed.

Optimistic vs. Zk-rollups

Let's first discuss what optimistic rollups and ZK-rollups are before diving deep into the workings of StarkNet and StarkEx and how they’re different from other rollups. There are two rollup scaling solutions: Optimistic rollups (e.g., Optimism, Arbitrum) and ZK-rollups (e.g., StarkNet, zkSync).

Optimistic rollup

In the case of Optimistic rollups, no computation is actually done. ORs “optimistically” assume all state changes are valid and post the off-chain transactions to Ethereum’s layer 1. A challenge/dispute period is put in place for ~one week after posting to L1 to counter any potentially fraudulent transactions. During this time, any third party can publish a fraud-proof to verify the validity of the transactions across L1 and L2. If the transactions are found to be invalid, the invalid transactions and all affected transactions will be reverted.

To discuss in a bit more detail, during this dispute period, if any network participant detects an invalid state root was sent to rollup, then any participant can send a fraud-proof to rollup contract. With the help of fraud-proof and batch of transactions, the rollup contract will compute the state root that the participant claims is invalid on the Ethereum chain.

Bonded tokens belonging to the sequencer who sent the invalid batch to the rollup contract will be slashed due to the malicious behavior, and the participant will be rewarded with some tokens for good behavior. If any participant raises no such claim during the dispute period, Ethereum believes the state root to be true and allows the withdrawal of assets according to the current state root of rollup.

This is how fraud proofs are used to point the invalid transactions and incorrect state root, allowing rollup smart contract to revert the incorrect blocks on rollup.

ZK-rollup

In the case of a ZK-rollup, the operator generates a cryptographic proof called validity proofs (SNARK or STARK) for the state root, which proves the rollup smart contract on Ethereum that the received state root was the result of execution of a valid series of transaction. This makes it impossible for the operator to send an invalid state root.

Zero-Knowledge Rollups TLDR

The process works as follows:

Highly-compressed batches of transactions are combined together with the current state root
The combination is sent to an off-chain Prover
Prover computes the transactions, generating a validity proof of the results
Prover sends this to an on-chain Verifier (Ethereum nodes)
Verifier confirms the validity proof
Smart contract on Ethereum’s L1 that maintains the state of the rollup is updated to the new state

ZK-rollups use two types of validity proofs: SNARK and STARK. SNARKs are used by ZK sync, Scroll, Polygon ZkEVM, etc., while StarkNet and StarkEx use STARKs.

ZK-rollups are significantly more computationally intensive than optimistic rollups, but they can scale much greater. This is because optimistic rollups require a witness for each transaction, whereas ZK-rollups bundle transactions into a fixed-size proof. Therefore, optimistic rollups scale linearly with the number of transactions, whereas ZK-rollups scale poly-logarithmically.

StarkEx

StarkEx is a framework used for creating permissioned, application-specific scaling dApps. StarkEx has been deployed on Ethereum since June 2020. Every application deployed on top of StarrkEx has its business logic.

Transactions executed on the applications built on top of StarkEx are sent to the StarkEx service, where a group of transactions is put together in a batch. This batch is then sent to SHARP, i.e., a shared proving service that generates STARK proofs that verify the validity of transactions executed on Cairo programs. The SHARP on StarkEx (as opposed to the version used in Starknet discussed later on) can only generate STARK proofs for a single type of transaction. This gives it limited scope and is why StarkEx is less flexible than Starknet, its next-generation general-purpose successor.

The original Starkware SHARP approach generated one aggregated ZKP1 for the various distinct propositions to be proved. In contrast, in the new SHARP method, the "mother" proposition is subdivided into groups where "children" proofs are generated for each group to create an accumulative ZKP2. Due to the logarithmic compression property, checking ZKP2 is considerably quicker than validating ZKP1 and requires fewer computational resources from the chain. Multiple subsidiary proofs can be computed in concurrently, hence accelerating the process of generating proofs.

A STARK proof generated from SHARP is then sent to the STARK verifier for verification purposes, and then an on-chain state update is sent to a StarkEx contract.

User data can be made available through various data availability modules:

ZK-rollup mode (vault balances are published on-chain as call data, which provides built-in trustlessness)
Validium mode (User balances are stored off-chain with well-known and trusted parties of a data availability committee. Data is accepted only if at least a quorum of the committee members sign on it.)
Volition mode (User gets a choice between ZK-rollup mode and validium mode for every transaction)

Two key differences that make StarkNet and StarkEx different from other rollups are the use of validity proofs called STARKs and the use of Cairo as the native smart contract language. To understand how they're different from other rollups, consider the differences between STARKs used by Starkware scaling solutions and SNARKs used by other ZK-rollups.

SNARKs and STARKs

Under the hood, StarkNet compresses thousands of transactions into a single validity proof called ‘STARKs’ (Scalable Transparent Argument of Knowledge), co-invented by Starkware President Eli Ben-Sasson, that's submitted to the Ethereum L1. Starkware’s STARK technology has two primary advantages over SNARKs (used by ZKR competitor ZkSync): 1) It doesn't require an initial trusted setup (like in zkSync v1), and 2) they’re ~10x faster to compute than SNARKs. Because the computational effort necessary to verify STARK proofs is significantly less than actually proving the computation, StarkNet can increase Ethereum scalability by orders of magnitude.

These are the most popular and widely used non-interactive zk proofs. They're both non-interactive zero-knowledge proofs, meaning there's little interaction between the prover and verifier. Both of these proofs are much smaller in size than an average Bitcoin transaction. They both scale the Ethereum network.

zkSNARK proof sizes are smaller. Therefore, it takes less time to verify and costs less gas. While zkSTARKS proof sizes are bigger and take more time to verify, they cost more gas than zk SNARK. zkSTARK TPS limit is higher than zkSNARK and is more scalable.

Cairo

StarkNet stands out from the numerous other zero-knowledge rollups (ZKR) projects in the space because, despite being a layer 2 project on Ethereum, it has shirked the EVM for its own development environment. This sets StarkWare apart from other ZKRs and indicates that it does not see ZKEVM as the ultimate goal. The company believes that in order to achieve high scalability, it is necessary to create languages and virtual machines that are specifically optimized for ZKRs rather than focusing on compatibility with the EVM. Additionally, they anticipate that the significance and influence of the EVM will decline in the future as more and more decentralized applications will be run on layer 2 solutions.

StarkNet and StarkEX don’t use Solidity, the preferred Ethereum smart contracting language, because it isn’t the best language to compile to STARKs. This is because Solidity can't be efficiently encoded to STARKs and is costly in comparison. Instead, StarkNet uses a new programming language developed by the team at Starkware called ‘Cairo.’ It’s a language for programming STARKs that achieves Turing-completeness with STARKs. A breakthrough of the Cairo language is it lets just one verifier use a single proof to confirm the integrity of many different program executions. This amortizes costs across separate dApps, e.g., a single proof that includes both dYdX trades and SoRare transactions.

Initially, Cairo was designed as an assembly language and was written as a low-level language. This makes it harder to code in Cairo. After various feedback from developers, the Starkware team made Cairo more developer-friendly and continuously improved it.

Cairo is a programming language that is specifically designed to support STARK programs while also providing general computation capabilities. Programs written in Cairo can be verified using the Cairo language itself, and the composability between Cairo-based or StarkNet-based decentralized applications is exceptional. The execution of a Cairo program also produces a proof that can then be sent to a prover. This generates a STARK proof of the validity of the instruction or calculation represented by the Cairo program.

The Cairo language has a similar structure to WebAssembly (Wasm), making it easily accessible for developers who are familiar with Wasm. Additionally, Cairo offers a user-friendly development environment that includes an Integrated Development Environment (IDE) where developers can access a native compiler that converts Cairo code into bytecodes, Cairo-exclusive Virtual Machines, and debuggers all within a single program. Furthermore, Cairo eliminates the need for building new verifier contracts for each decentralized application, as it uses a general-purpose verifier contract.

Therefore, Cairo ameliorates Ethereum’s expensive computation, transmission, and storage fees. To link the Cairo code to the smart contract, a Shared Prover (SHARP) is used. This involves a prover off-chain, a smart contract verifier on-chain, and a fact-logger contract on-chain. The prover proves the code is valid and sends this proof to the verifier, which then sends an attestation of the proof’s validity in the fact register. This fact functions as a seal of approval without trust, certifying the validity of the Cairo program. Now, dApp’s smart contract just needs to verify this fact exists, and then it can rely on the computation that is performed off-chain.

However, StarkWare acknowledges the importance of the EVM developer ecosystem and has created a service called Warp, a transpiler that will seamlessly convert solidity smart contracts into Cairo to make Starkware EVM-compatible. The initial iteration of Warp demonstrated the feasibility of converting Solidity code into Cairo, laying the groundwork for developers to leverage StarkNet's capabilities without the necessity of learning Cairo. Drawing on the insights gained from Warp 1, a revamped version has been developed, offering significant enhancements in contract efficiency and user experience. In our discussion, we will delve into the upgrades implemented in Warp, illustrate the process of transpiling OpenZeppelin’s ERC20 contract using this new framework, and outline the future trajectory of the project.

Comparing Warp 2 with its predecessor, Warp 2 stands out for its ability to transpile directly from Solidity to Cairo, bypassing the intermediate step involved in Warp 1. In the earlier version, Solidity smart contracts were initially converted into YUL, Solidity's intermediate format, before being transpiled to Cairo. By eliminating the YUL intermediate phase, Warp 2 simplifies the process, focusing on transpiling the more complex Solidity code rather than dealing with numerous low-level calls. This advancement holds significant implications for users, including:

A reduction in the overall size of the code.
A decrease in the number of steps required for function calls, leading to less computational demand.
Enhanced readability of Cairo code.
Provision of specific messages indicating which Solidity features are currently unsupported by this system.

StarkNet

In the architecture of StarkNet system, various components interact to maintain the integrity and efficiency of transactions.

Externally Owned Accounts (EOAs)

At the core are Externally Owned Accounts (EOAs), which are controlled by individuals through private keys. These accounts initiate transactions by signing them with their private keys, thereby triggering smart contract operations or direct transfers.

User accounts

User accounts represent identities within the system that can hold balances and create contracts. They differ from EOAs in that they are governed by the logic of smart contracts rather than being directly controlled by users.

Sequencer

The Sequencer plays a crucial role in ordering transactions before batch processing. It collects multiple transactions off-chain and arranges them sequentially to facilitate group processing. This batching is essential for leveraging the scalability benefits provided by zero-knowledge proofs.

Prover

The Prover is responsible for generating cryptographic proofs that validate the correctness of transactions processed by the sequencer. These proofs ensure that despite off-chain processing, all transactions adhere strictly to blockchain protocol rules without revealing any specific transaction details.

Full nodes

Lastly, Full nodes act as the backbone of on-chain operations in ZKR systems. They verify the cryptographic proofs submitted by provers, maintain a record of the state, and execute smart contract code when necessary. Full nodes provide an additional layer of security and decentralization by independently verifying each proof's accuracy before updating the blockchain's state.

These components collectively ensure a harmonious balance between maintaining privacy through zero-knowledge proofs and sustaining high throughput for the network.

By clearly delineating roles and responsibilities among different elements within zkEVM systems, developers can construct robust platforms where users enjoy both enhanced performance and strengthened privacy measures. Such advanced infrastructure positions zkEVMs at the forefront of Ethereum scaling solutions, offering an enticing proposition to those looking to build and use decentralized applications at scale.

StarkNet Tech

StarkNet uses Zero-Knowledge Proofs to achieve fast transaction times and hyper-scaling without compromising security. An alpha version of StarkNet was launched in November 2021 with limited capabilities to allow developers to begin building on top of the protocol. It fully launched in February of 2022 and is now fully functional for transactions and for building applications. StarkNet is designed so that it benefits from economies of scale, i.e., the greater the number of transactions in a batch, the less gas each participant in the batch must pay.

As we know, ZK-rollups enable provable computation, i.e., it allows programs to prove they’ve been executed by providing SNARK or STARK proofs without having to re-run/re-execute the transactions. This leads to tremendous scalability improvements. StarkNet is designed to benefit from economies of scale, i.e., the greater the number of transactions in a batch, the less gas each participant in the batch pays.

The use of zk-STARK in StarkNet introduces several advantages:

Transaction Correctness: The proof system ensures the accurate execution of smart contracts by confirming the validity of each transaction within the bundled package submitted to the main chain.
Privacy Preservation: User details remain confidential as zk-STARK demonstrates proof's validity without disclosing transaction specifics.
Scalability: The protocol's ability to batch multiple transactions into a single proof optimizes data processing, enhancing the network's capacity to handle high transaction volumes.

StarkNet transactions sent by users are batched and delivered to the STARK prover. This STARK prover has the accurate ledger state prior to and following the processing of these new transactions. The prover generates a STARK proof attesting to the veracity of the new state of the ledger. The new state and STARK proof are relayed to the STARK verifier on Ethereum mainnet where the proof is verified autonomously by a smart contract.

The Starknet L2 node (sequencer) will execute every transaction and periodically update the state to the Ethereum mainnet. StarkNet transaction finality is tied to L1, meaning the L2 node must simultaneously validate StarkNet and Ethereum. StarkNet introduces a solution involving checkpoints to the Ethereum mainnet, enabling it to quickly achieve finality on the rollup side. Therefore, all L2 nodes incorporate an L1 full node.

STARKs improves scalability and privacy since developers can move computations and storage off-chain. Off-chain services can generate STARK proofs, attesting to the integrity of off-chain computations. These proofs are then returned to the chain for any interested party to validate the computation. Moving the bulk of the off-chain computations using STARK allows the blockchain infrastructure to scale exponentially while maintaining the integrity of the computations.

eth cost of rollup txs june 2023 — Source

Additionally, since the state transitions are "STARK-approved" by the sequencer, it's mathematically/cryptographically impossible for fraudulent transactions to be accepted on mainnet Ethereum. This removes the need for any "challenge" period that exists in ORs. All data needed to reconstruct the full StarkNet state is published on-chain.

However, Starkware is in control of the sequencer, and all of the transactions are verified by Starkware cloud servers. However, Starkware aims to create a decentralized sequencer set in the future. It's not a fully permissionless system. For example, to deploy a smart contract on StarkNet, you must fill out a form and send it to the Starkware team.

New StarkNet Client

In January 2023, StarkWare introduced a new full node client, known as Papyrus, for StarkNet. Written in the Rust programming language, the implementation of this new client will enable a more diverse range of integrations while also improving the protocol's security and decentralization. The team has stated that the new node, Papyrus, will augment the project's transaction throughput capabilities and will join Pathfinder as the second Rust-coded full-node client.

Additionally, StarkNet already has another full-node client, Juno, that is being coded in the Golang programming language. Furthermore, the Papyrus will reportedly enhance the capabilities of the StarkNet Sequencer, which is responsible for ordering and executing transactions on the network. It will provide an efficient storage layer that will help to improve the Sequencer's throughput. This move is part of the wider efforts to open-source the entire technology stack of the project.

ZK-rollup or “Validity” rollup?

The Starkware team doesn’t use the term “ZK-rollup” but rather refers to their solution as a validity rollup. Below is the definitional difference between the different terms.

Validity Proof: a cryptographic proof confirming that the computation was done correctly
ZK Proof: a validity proof that also conceals information about the computation
Succinct Proof: a cryptographic proof that is fast to verify, thereby helping with scalability

The team explained their position in their Discord the following way:

“Let's start with proofs of computational integrity; one side proves to another that a certain computation was done correctly (validity proof).

An optional additional feature is zero-knowledge, which means there's a mathematical reason why you can't learn any information from the proof except for the fact that the computation was done correctly (zero-knowledge proof). Most of the STARKs we’re building (the one in StarkNet included) don't have this feature (but it's going to be extremely hard, if not impossible, to extract information from the proof, nevertheless). We've decided to focus on scalability for now rather than privacy.

Another important thing is that a ZK proof is not enough for privacy. It doesn't help if you have a ZK proof, but you tell your secret inputs to the sequencer as part of the protocol... So the protocol must be adapted to make sure no information is leaked. One good example of such a protocol (which uses a ZK proof) is Zcash.”

Role of StarkNet Foundation and StarkNet Token

On July 13th, 2022, Starkware announced in a Medium post that StarkNet would have its native token and a StarkNet foundation would be set up. The StarkNet Foundation will be a non-profit organization, and StarkNet tokens will be allocated to it to help achieve its goals. Its primary goal will be to maintain StarkNet as a public good. The Foundation will also maintain ongoing protocol development, testing, documentation, and software publication.

The StarkNet Foundation and its native token will play a key role in decentralizing the StarkNet network. The StarkNet Foundation will follow these four principles to maintain StarkNet’s decentralization: Livness, Censorship resistance, Transparency, and Creativity.

The Starknet Foundation has recently announced an ambitious strategy to enhance network engagement by allocating over 1.8 billion STRK tokens. A key element of this initiative is the establishment of a Provisions Committee, tasked with the phased distribution of 900 million STRK. This committee's mandate is to recognize and reward both past and future contributions from users and the community at large. In addition to this, the Foundation is implementing a user rebate program designed to offset or completely reimburse transaction costs. This effort will be facilitated by a second committee, which has been assigned 900 million STRK to manage the reimbursement of user transaction fees. Moreover, the Foundation is taking a targeted approach towards the decentralized finance (DeFi) sector by forming a 'DeFi Committee'. This committee is allocated an initial sum of 50 million STRK, with the objective of stimulating activity and enhancing liquidity within DeFi protocols. This comprehensive plan underscores the Foundation's commitment to fostering a more active and engaged user base, while simultaneously supporting the growth and development of DeFi projects within its ecosystem.

A seven-member board will govern the StarkNet Foundation, whose members come from diverse backgrounds and bring a multidisciplinary range of skills.

The board members are Andrew McLaughlin, Prof. Eli Ben-Sasson, Eric Wall, Heather Meeker, Prof Shubhangi Saraf, Tomasz Stanczak, and Uri Kolodny.

StarkNet Token

The StarkNet token, STRK, is used for three purposes (payment, staking, governance):

1) Network payment - Paying network transaction fees. For a good user experience, users will also have the choice to pay in ETH.

2) Staking - Various services will require staking StarkNet tokens. As for reaching a temporary consensus on the validity of layer 2 transactions before L1 finality’s reached, data availability service, a permissionless Proof-of-Stake leader election mechanism, will be implemented for sequencing and proving STARK-compressed transactions.

3) Governance - Governance decisions regarding Starknet operations and updates will be taken by token holders. A minimum voting threshold will be required to pass a governance proposal. Token holders will be able to vote directly or via delegation.

The StarkNet token’s design was made considering the needs of:

1. Users of the network.

2. Operators providing computing resources for various operations, such as sequencing transactions, STARK proof generation, and storage for data availability services.

3. Developers building and maintaining software for the infrastructure of the network and dApps built on top of it.

Starkware minted 10 billion tokens off-chain in 2022 and ultimately launched the STRK token in February 2024 with its first airdrop. However, the StarkNet protocol may automatically distribute a portion of fees and new minting of tokens to smart contract developers according to the value their smart contracts provide to users. The exact mechanism for distribution has yet to be confirmed.

Initial allocation of StarkNet token

32% - Core contributors (Starkware employees and consultants and StarkNet software developer partners)

17% - StarkNet investors, such as Sequoia Capital, Tiger Global Management, Pantera Capital, IOSG ventures, etc.

50.1% of the token allocation for the StarkNet Foundation will be distributed as follows:

Community Provisions (9%)

To people who performed work for StarkNet and developed its underlying technology and infrastructure and to past StarkEx users. Allocations will be done based on verifiable usage of StarkEx’s technology before June 1, 2022.

To prevent gamification, snapshots from before the announcement date of the token rewards will be referred to distribute tokens, and additional network usage filtering will be done so that airdrop Sybil hunters don’t receive rewards.

Community Rebates (9%)

Rebates in StarkNet Tokens will be done to partially cover the costs of onboarding users to StarkNet from Ethereum. To prevent gamification, community rebates will apply to transactions after the rebate mechanism is announced by the StarkNet Foundation.

12% — Grants for research and work done to develop and maintain the StarkNet protocol.

10% — Strategic reserve will be distributed as ecosystem rewards for the activities that align with the foundation’s mission.

2% — Donations to highly regarded institutions and organizations, such as universities, NGOs, etc., will be decided by StarkNet token holders and the foundation through governance.

8.1% — Unallocated – Foundation’s unallocated treasury tokens will be distributed through governance for the purpose of supporting the StarkNet community.

Vesting Schedule Controversy

Starkware, in response to significant community feedback, has announced a revision to the token release schedule for Starknet's native token, STRK. This adjustment aims to moderate the initial influx of tokens to the market, addressing concerns from the community and early investors about potential market impacts.

Key Changes to the STRK Token Release Plan

Initial Unlock Reduction: Starkware has significantly reduced the proportion of tokens to be released in the initial batch. Originally set at 13.4% of the total supply, this figure has been adjusted to a mere 0.64%. This adjustment translates to a decrease from an initial unlock of 1.3 billion tokens, valued at approximately $2.7 billion, to just 64 million tokens, with an estimated value of around $131 million.
Gradual Monthly Unlocks: Following the initial release, Starkware has planned for an additional 64 million tokens to be unlocked each month. This approach will continue until March 2025, at which point the monthly unlock rate will increase to 127 million tokens. This escalated release rate is scheduled to persist for two years, concluding in 2027.
Long-Term Impact on Token Circulation: The revised token release structure is projected to significantly curtail the number of tokens in circulation by the end of 2024. Specifically, the total circulating supply is expected to be reduced by 71%, from an anticipated 2 billion tokens to 580 million tokens.

This strategic alteration in the token release schedule by Starkware is a direct response to community input, underscoring the company's commitment to maintaining a stable and sustainable market for STRK. By staggering the release of tokens more gradually, Starkware aims to mitigate potential market volatility and provide a more predictable environment for investors and users alike.

The decision to adjust the token release schedule reflects a broader trend in the cryptocurrency industry, where project teams are increasingly prioritizing long-term stability and community trust over short-term gains. This approach not only benefits early investors and the broader community by reducing the risk of market saturation but also enhances the overall credibility and viability of the project.

As Starkware moves forward with this revised token release plan, the focus on gradual distribution is expected to foster a healthier ecosystem for STRK. This strategy allows for more measured market absorption of new tokens, potentially leading to more stable price dynamics and encouraging sustained growth and development within the Starknet ecosystem.

Helpful Starknet Links and Wallets

Presently, users can choose between two StarkNet wallet options, with a third option soon to be available:

Argent X: The pioneer StarkNet wallet
Braavos: A self-custodial solution
MetaMask: The popular wallet set to support StarkNet in the near future

Argent X was the inaugural DeFi wallet for StarkNet, boasting over 3.5 million transactions. The wallet offers vaults, allowing users to earn yields on their crypto assets and serves as a custody solution. Argent X is backed by prominent investors, including Paradigm and Index Ventures.

As a native StarkNet DeFi wallet, Braavos features a multimedia NFT reader and self-custodial capabilities. Users can manage their crypto tokens and NFTs in one convenient location.

MetaMask recently announced a strategic partnership with StarkWare, which will make it the first zk-L2 wallet to be supported by the widely used web wallet. This collaboration aims to provide enhanced scalability, trading experiences, perpetual swaps, and derivatives to all StarkNet and Ethereum users through a decentralized node network.

If you liked Layer 2, then you’ll love Layer 3

Layer 2s increase the scalability of Ethereum while getting the benefits of decentralization and security guarantees from Ethereum. However, some dApps have specific needs or can perform better if dApp developers have more control over the execution layer.

Enter Layer 3s, where dApp developers get more control over the execution layer while still getting the benefits of decentralization and security guarantees from Ethereum. Layer 3 can function using validity proofs as long as layer 2 has a verifier smart contract, which can verify the validity proofs sent by layer 3. This setup becomes an elegant recursive structure where the compression benefits of layer 2 proofs are multiplied by the compression benefits of layer 3 proofs.

Recursive zk proofs are constructed by combining many proofs into a single proof. The single proof is only true if all underlying proofs are correct, and it is significantly simpler and less expensive to check. This is particularly advantageous when proofs are checked on-chain. Thousands of proofs can be condensed into a single proof, significantly reducing costs associated with the verification process. This is due to the fact that a recursive zk proof demonstrates the existence of an earlier valid proof.

Layer 3 fees get reduced by multiples compared to layer 2 while still getting the same benefits from layer 1, which are received by layer 2. StarkEx, which is currently used as a layer 2 solution, will be moved to Layer 3, and several instances of StarkNet will also be available as Layer 3.

Layer 3 Architecture

Benefits of layer 3:

1. Higher scalability than layer 2 from the recursive structure

2. More control over the underlying technology stack

3. Privacy-based applications over a public layer 2

4. Cheaper interoperability between layer 3 to layer 3 and layer 3 to layer 2

5. Layer 3 can be used as a testnet. After a successful run of a dApp over layer 3, it can be made available to the public layer 2 networks

StarkNet 2024 Updates

Starknet, a leading ZK-rollup on Ethereum, continues to differentiate itself through its use of zero-knowledge proofs for transaction verification, as opposed to the fraud proofs employed by optimistic rollups. The recent v0.13.3 upgrade introduces significant enhancements aimed at addressing the rising demand for efficient data handling on Ethereum Layer 2 solutions.

A core feature of this update is the improved handling of blobs—dedicated data storage units used by rollups to post information to Ethereum's Layer 1. Blobs are critical for Ethereum’s scalability, but growing usage has led to rising costs, as the blob fee market, established through EIP-4844, enters a phase of price discovery. While blob fees were initially negligible, recent spikes in on-chain activity have pushed costs as high as $30 per megabyte, underscoring the need for more efficient blob management.

To tackle this, Starknet’s upgrade introduces two key innovations: state-diff compression and transaction squashing. These techniques minimize the amount of data uploaded to Layer 1 by compressing state changes and aggregating multiple transactions into fewer blocks. This not only reduces blob gas costs by five times but also ensures fairer cost distribution by charging users based on their actual data usage.

By enhancing blob efficiency and reducing transaction costs, Starknet aligns with Ethereum's broader goals of increasing scalability and promoting sustainable rollup economics. This upgrade strengthens Starknet’s position as a competitive Layer 2 solution while benefiting developers and users through lower fees and improved network performance.

StarkNet Bridge

In general, there are two types of bridges: trusted and trust-minimized. Trusted bridges depend on a counterparty consensus, usually an external validator set, while a single complete node can secure trust-minimized bridges.

Chains require two things to construct trust-minimized bridges: the same data availability (DA) guarantees and a mechanism to read each other's fraud or validity proofs. Because L1s don't meet the previous requirement of shared DA, they can't create trust-minimized bridges with each other. They rely on each other's agreement to communicate, significantly reducing security.

In contrast, rollups connect with Ethereum in a manner that minimizes the need for trust. They are “trust-minimized” because the smart contract on the L1 acts as a light client receiving block headers and validating by fraud/validity proofs. Ethereum has access to a rollup's data and conducts its on-chain fraud and validity proofs. This access and proof process are why rollups can have as little as one node but still maintain the same trust assumptions as the Ethereum base layer.

Rollups don't require validators; instead, a set of sequencers to produce blocks. The base layer provides the secure validator set, circumventing the security bootstrapping problem.

Additionally, rollups that share a settlement layer can build trust-minimized bridges between them because their state transitions can be easily verified through the settlement layer via full nodes.

StarkNet is currently the only general-purpose, composable ZKR on Ethereum, but comes with several limitations as the project is still in its infancy. There is no StarkNet node operating on the Ethereum bridge of StarkNet. Instead, it runs a verifier. To ensure that people are receiving the truth, it examines a mathematical demonstration. The bridge of StarkNet is a MESSAGE bridge. It allows you pass data.

StarkGate is the StarkWare-built Ethereum-StarkNet token bridge. It's comprised of L1 and L2 token bridge contracts that are communicating via StarkNet's messaging mechanism.

The first version of StarkNet Bridge, StarkGate Alpha, is live on Mainnet as of May 2022. The only bridgeable assets are ETH, DAI, WBTC, USDC, and USDT. There's a TVL limit for each token type on StarkNet. There's a limit to the maximum amount sent from layer 1 to layer 2. The team continues to raise the limit from time to time.

To bridge from Ethereum to StarkNet via Starkgate:

Users can send ETH, DAI, USDC, WBTC, and USDT to recipient addresses on StarkNet
The smart contract emits a deposit event on L1, a recipient address on L2, and the amount
The StarkNet sequencer ensures the deposit's valid, processes the transaction and constructs the block
StarkNet’s provers then verify the block’s validity and submit a state update to L1
Once proven valid, transferred funds are now part of the finalized state of StarkNet

Users can use Layerswap to send ETH from centralized exchanges to StarkNet by paying low fees and can use Orbiter to bridge ETH and DAI from StarkNet to other layer 2s, Ethereum, Polygon, and BNB.

Loading...