The Ethereum scaling landscape has expanded rapidly in recent years; introducing rollups that repurpose the L1 as a settlement layer. Traditionally featuring Optimistic L2s including Arbitrum and Optimism, and zkEVMs such as Scroll and Taiko; rollups today have enabled a surge in economic and network activity across the Ethereum landscape.

While L2s enable complete modularity on all elements of the stack, most rollups operate as near-identical-EVMs. This approach does have merits: it ensures a consistent user experience, allowing rollups to feel "native" to the L1, and the reuse of Solidity contracts and EVM wallets allows a seamless transition for developers and users.

However, these benefits come at a significant cost. Such an architecture is constrained by the inherent limitations of EVMs, effectively carrying forward the very constraints L2s were meant to overcome. This ultimately undermines the core purpose and flexibility of L2s, which were intended to be a platform for innovation rather than mere scaled copies of existing systems.

This results in the carrying forward of EVMs’ ZK-unfriendly elements, such as the Keccak Opcode, which is exponentially more expensive to prove, and the Solidity programming language, whose shortcomings have often been critiqued.

Observing the limitations an EVM-identical rollup would suffer, Starknet chose an alternate approach with its ZK-focused Cairo VM.

Starknet's vision was to reinvent an L2 from first principles. Starting with a clean slate allowed Starknet to make unconstrained decisions across all aspects of its chain.

For instance, Native Account Abstraction is standard for all Starknet wallets, yet account abstraction is still unseen in most other rollups. Similarly, Starknet developed Cairo, a new smart contract language designed specifically for ZK proofs, rather than adapting Solidity for ZK compatibility.

This redesign allowed Starknet to build a rollup without inheriting the technical debt of EVMs.

The Cairo programming language was invented by StarkWare to resolve the flaws of Solidity that were discovered through a decade of experimentation. Cairo is the result of a vision to create a “better Smart Contract Programming Language” that is “innately ZK-Friendly”.

The Cairo programming language, invented by StarkWare, resolves the flaws of Solidity discovered through a decade of experimentation. Cairo is designed to be "innately ZK-Friendly", unlike Solidity, which was solely focused on smart contract development and includes several ZK-unfriendly components, such as the Keccak hash and its version of the Merkle Patricia Tree.

Cairo addresses Solidity’s limitations, including stack management, linear type system, and function imports, while being tailored for provability. For example, Cairo is not constrained by the limitations imposed by the EVM, such as the Keccak Opcode, which is approximately 1000x larger in circuit size compared to ZK-friendly hash functions like Poseidon.

By addressing Solidity's limitations and optimizing for ZK-proving, Cairo positions itself as a future-ready smart contract development language, particularly for ZK apps.

Another example of a shortcoming rooted in the EVM-identical approach is the lack of Account Abstraction across the rollup space.

Account abstraction enables the use of smart contracts instead of traditional Externally Owned Accounts. EIP-4337 has been on the Ethereum roadmap for years now, with Vitalik himself admitting its absence in Ethereum as an architectural regret.

EIP-4337 enables complex transaction logic to be executed through smart contract wallets without requiring direct user management of private keys. This enhances security and usability, whilst also supporting advanced authentication methods.

While Ethereum’s changes are understandably slow, the dearth of innovation in L2s is reflected in the reluctance to “go beyond” the EVMs spec. Despite the demand for it, bar zkSync no other ZK-Rollup has implemented native account abstraction.

On Starknet, Smart Contract Accounts are the norm with the likes of Argent and Braavos continuously innovating and demonstrating the benefits of native account abstraction.

The Starknet stack comprises a robust suite built on aggregated proving, Cairo as a Domain Specific Language, and an industry-leading ZK Prover. These components collectively enable Starknet to function as a high-performance, secure network.

Building on the Starknet Stack, Starknet’s roadmap over the next six months focuses on “continuous improvement” in the chain’s UX and DevX; allowing ALL Cairo chains to be faster and more efficient. Key areas of development include Parallelisation, Cairo Native, Stwo & SHARP.

Starknet’s latest upgrade includes optimistic parallelisation, an approach that allows the sequencer to process multiple transactions simultaneously, achieving significantly lower confirmation times.

A similar optimisation is implemented in Solana, albeit through the use of access lists, which require each transaction to declare the storage slots it’ll access before execution. This enables Solana to identify non-conflicting transactions that can be processed in parallel.

In contrast, Starknet’s approach is based on optimistic parallelization, where transactions are initially executed concurrently under the assumption that they are independent. The sequencer then checks for conflicts. If it finds that one transaction needs to read storage slots modified by another transaction, it re-executes the affected transaction.

Starknet will be the only L2 to support parallelisation.

Starknet hence relies on a dynamically constructed dependency graph that tracks conflicts between transactions allowing Optimistic Parallelisation without access lists. The feature is live on Starknet’s Sepolia Testnet and is due to be on the Mainnet by late August.

A detailed piece on Starknet’s parallelisation is in the works by the Karnot team and will be released shortly.

While Starknet's architecture is complex and multi-layered, simplifying it helps us focus on Starknet’s two major upgrades: Cairo Native and Stwo. However to appreciate these optimisations, we must discuss two components of the Starknet architecture: The Sequencer and The Prover.

The Sequencer has two core tasks, sequencing and execution.

• Sequencing: Ordering transactions and appending new blocks.

• Execution: Executing transactions and updating the system’s state

  • The sequencer, hence is able to provide “soft confirmations” based on the result of its execution, however finality is only achieved with the chain’s settlement on L1.

  • Soft confirmations can be used by dApps to provide real time responsiveness on the premise that the Starknet sequencers’ execution is correct.

The Prover provides a mathematical guarantee that the transactions in a block are executed correctly.

• The prover re-executes the transactions in a “Provable Environment” and generates

  • An Execution Trace: A log of how each transaction was executed

  • A State Diff: A record of how the Starknet state changed after processing the block

• The prover then processes the execution trace, taking random samples to mathematically guarantee the executions validity

• Together “The Proof and State Diff” encapsulate thousands of transactions and their validity

• As dApps operate with Soft Confirmations from the sequencer, the prover is free to operate asynchronously and be scaled horizontally allowing Proof Submission to happen on “a rolling basis”.

Cairo code today undergoes a multi-step compilation process, namely going from a Cairo program to an intermediate representation called Sierra (Safe Intermediate Representation), to finally Cairo Assembly (CASM) that is executed on the Cairo VM.

The presence of the Sierra step ensures safety and prevents runtime errors, guaranteeing that all transactions that reach the Cairo VM are eventually provable. Overall this prevents DDOS and reduces the likeliness of failing transactions reaching execution. Read more here.

Cairo Native significantly boosts performance, allowing up to 1700 swaps per second.

The LambdaClass team has been leading the development of Cairo Native, a compilation optimisation that converts Sierra code to native object code. Cairo Native’s optimised compilation enables significantly faster execution without the need for a Cairo VM. To get a brief idea of Cairo Native, we must understand two key compiler frameworks used in Cairo Native

• LLVM: Assembly Code Abstraction

  • LLVM IR is an intermediate representation that simplifies various CPU instruction sets (like x86 and ARM).

  • It allows for cross-architecture compatibility by using a generic language instead of specific assembly code.

  • LLVM IR maintains a linear instruction sequence, focusing on CPU instruction abstraction.

• MLIR: Abstraction over Intermediate Representation/Computation

  • MLIR builds upon LLVM by using flexible operations that represent a wider range of computations than simple CPU instructions.

• MLIR can convert its representations to LLVM IR, allowing it to benefit from LLVM's optimizations and generate efficient machine code.

How Cairo Native uses both:

• Cairo code is first compiled to Sierra.

• Cairo Native translates Sierra to MLIR operations.

• These MLIR operations are then lowered to LLVM IR.

• LLVM optimizes this IR and generates native machine code.

This approach allows Cairo Native to handle Cairo’s functionality in MLIR, then leverage LLVM's ecosystem for final optimization and code generation.

A detailed piece by the Karnot team on Cairo Native and it’s intricacies is in the works, meanwhile read more here.

As discussed in the Architecture section; it is the role of a Prover to create mathematically sound proofs that attest to a transaction executing correctly. While computationally expensive, provers run “off-chain” and return a ZK-Proof to the Verifier contract; which is lightweight and sufficient to guarantee correct execution.

However, as ZK-Rollups scale, their biggest expenses steer towards being cloud costs incurred by running these provers. Consequently, any improvements in Provers has a amplified impact across the ecosystems expenses. Thus, a faster and more efficient Prover reduces proving costs, latency and potentially increases throughput.

StarkWare’s latest breakthrough titled Circle STARKs introduces major optimisations to STARK calculation (the math behind Starknet’s ZK-Proofs). By working over smaller 31-bit fields instead of 256-bit fields. Computing circle STARKs over 31-bit fields fully utilises 32-bit registers, reducing wasted space and leading to more efficient hardware design. Circle STARKs thus can represent information much more efficiently, making proof creation significantly more hardware friendly.

Stwo has achieved record breaking results, and has benchmarked 1000x the hash rate of its predecessor, Stone.

Read more about Circle STARKs here.

StarkWare shattered the world proving record with over 500,000 hashes proved per second

Starkware’s SHARP is an industry first innovation, enabling Cross Chain Proof Aggregation. In simpler terms, SHARP reduces verification costs by generating recursive STARKs, accepting proofs from ALL Cairo chains.

SHARP’s cross-chain proof aggregation capability has been Mainnet ready since early 2023

By recursively aggregating multiple proofs from the Starknet chain, Paradex, DyDx and other Cairo chains, SHARP effectively spreads the cost of L1 verification across thousands of transactions, creating network effects across the ecosystem.

Stwo, scheduled for release in Q1 2025, is expected to significantly reduce proving costs. With SHARP as an aggregator wrapped atop Stwo, Starknet and all Cairo chains are expected to witness major savings in proving costs.

While we strongly believe Cairo is an efficient proving and advanced smart contract language, there are reasons to deploy on the EVM:

1. Reusing audited smart contracts

2. Leveraging existing Solidity experience for faster shipping

3. Staying with the improving EVM ecosystem

If you choose to build on the EVM, today's ZK-rollup ecosystem includes Scroll, zkSync and Polygon, each using a "low-level circuit" approach for EVM provability.

Kakarot zkEVM is an EVM implementation written in Cairo. It combines Starknet Stack advancements (Stwo, SHARP, Parallelisation, Cairo Native) with EVM ecosystem’s network effects.

Kakarot's intermediate language approach results in a 90% lighter codebase than circuit-based rollups, enabling faster adoption of EVM upgrades and fewer potential vulnerabilities.

Kakarot’s approach significantly simplifies introducing custom precompiles, allowing you to implement builtin functions that would be computationally expensive if executed in EVM bytecode be natively integrated into the Kakarot client; optimized for better performance.

Kakarot zkEVM is expected to achieve 100% EVM compatibility soon. Moreover Kakarot’s bytecode compatibility enables full reuse of Solidity contracts while running your appchain with the security guarantees and proving architecture of all Cairo chains.

The Starknet Stack hence comprises of powerful innovations in the ZK and blockchain space. However till date, the only way to run a custom Starknet chain, alike Paradex and DyDx was through StarkEx, Starkware’s appchain-as-a-service offering. And whilst StarkEx has been in production on Mainnet since June 2020, StarkEx was closed source and had limited access.

With Madara we bring the same stack that powers over $1B TVL to everyone.

Inspired by the StarkEx, Madara is a performant and open-source implementation of the Starknet Stack. Madara is developed with a focus on fractal scaling—the use of L2s and L3s to exponentially scale Ethereum, whilst benefitting from all upgrades to ANY components of the Starknet Stack.

Madara's architecture enables integrating app-level customizations deep into the protocol layer, allowing fine-tuning of block times, gas costs, provers, and data availability layer according to the app's requirements.

With Madara, any app can be an appchain.

Read more about Madara here.

At Karnot, we're proud to be core contributors to the Madara project and the leading RaaS provider for Madara app chains. Our team brings years of experience in building scalable, fault-tolearnt systems. Through successfully running multiple devnets and testnets, we've continuously refined our services, ensuring robust and battle-tested solutions. We continue to actively contribute to Madara's development while strengthening our infrastructure to offer "Appchains as a Service". This dual focus puts Karnot in a unique position to build AND provide exceptional scaling solutions to appchains across the ecosystem.

Whether you're looking to build EVM app chains or Starknet app chains, we're here to support your project. We invite you to connect with us and explore how our expertise can accelerate your appchain journey.

The Ethereum scaling landscape has expanded rapidly in recent years; introducing rollups that repurpose the L1 as a settlement layer. Traditionally featuring Optimistic L2s including Arbitrum and Optimism, and zkEVMs such as Scroll and Taiko; rollups today have enabled a surge in economic and network activity across the Ethereum landscape.

While L2s enable complete modularity on all elements of the stack, most rollups operate as near-identical-EVMs. This approach does have merits: it ensures a consistent user experience, allowing rollups to feel "native" to the L1, and the reuse of Solidity contracts and EVM wallets allows a seamless transition for developers and users.

However, these benefits come at a significant cost. Such an architecture is constrained by the inherent limitations of EVMs, effectively carrying forward the very constraints L2s were meant to overcome. This ultimately undermines the core purpose and flexibility of L2s, which were intended to be a platform for innovation rather than mere scaled copies of existing systems.

This results in the carrying forward of EVMs’ ZK-unfriendly elements, such as the Keccak Opcode, which is exponentially more expensive to prove, and the Solidity programming language, whose shortcomings have often been critiqued.

Observing the limitations an EVM-identical rollup would suffer, Starknet chose an alternate approach with its ZK-focused Cairo VM.

Starknet's vision was to reinvent an L2 from first principles. Starting with a clean slate allowed Starknet to make unconstrained decisions across all aspects of its chain.

For instance, Native Account Abstraction is standard for all Starknet wallets, yet account abstraction is still unseen in most other rollups. Similarly, Starknet developed Cairo, a new smart contract language designed specifically for ZK proofs, rather than adapting Solidity for ZK compatibility.

This redesign allowed Starknet to build a rollup without inheriting the technical debt of EVMs.

The Cairo programming language was invented by StarkWare to resolve the flaws of Solidity that were discovered through a decade of experimentation. Cairo is the result of a vision to create a “better Smart Contract Programming Language” that is “innately ZK-Friendly”.

The Cairo programming language, invented by StarkWare, resolves the flaws of Solidity discovered through a decade of experimentation. Cairo is designed to be "innately ZK-Friendly", unlike Solidity, which was solely focused on smart contract development and includes several ZK-unfriendly components, such as the Keccak hash and its version of the Merkle Patricia Tree.

Cairo addresses Solidity’s limitations, including stack management, linear type system, and function imports, while being tailored for provability. For example, Cairo is not constrained by the limitations imposed by the EVM, such as the Keccak Opcode, which is approximately 1000x larger in circuit size compared to ZK-friendly hash functions like Poseidon.

By addressing Solidity's limitations and optimizing for ZK-proving, Cairo positions itself as a future-ready smart contract development language, particularly for ZK apps.

Another example of a shortcoming rooted in the EVM-identical approach is the lack of Account Abstraction across the rollup space.

Account abstraction enables the use of smart contracts instead of traditional Externally Owned Accounts. EIP-4337 has been on the Ethereum roadmap for years now, with Vitalik himself admitting its absence in Ethereum as an architectural regret.

EIP-4337 enables complex transaction logic to be executed through smart contract wallets without requiring direct user management of private keys. This enhances security and usability, whilst also supporting advanced authentication methods.

While Ethereum’s changes are understandably slow, the dearth of innovation in L2s is reflected in the reluctance to “go beyond” the EVMs spec. Despite the demand for it, bar zkSync no other ZK-Rollup has implemented native account abstraction.

On Starknet, Smart Contract Accounts are the norm with the likes of Argent and Braavos continuously innovating and demonstrating the benefits of native account abstraction.

The Starknet stack comprises a robust suite built on aggregated proving, Cairo as a Domain Specific Language, and an industry-leading ZK Prover. These components collectively enable Starknet to function as a high-performance, secure network.

Building on the Starknet Stack, Starknet’s roadmap over the next six months focuses on “continuous improvement” in the chain’s UX and DevX; allowing ALL Cairo chains to be faster and more efficient. Key areas of development include Parallelisation, Cairo Native, Stwo & SHARP.

Starknet’s latest upgrade includes optimistic parallelisation, an approach that allows the sequencer to process multiple transactions simultaneously, achieving significantly lower confirmation times.

A similar optimisation is implemented in Solana, albeit through the use of access lists, which require each transaction to declare the storage slots it’ll access before execution. This enables Solana to identify non-conflicting transactions that can be processed in parallel.

In contrast, Starknet’s approach is based on optimistic parallelization, where transactions are initially executed concurrently under the assumption that they are independent. The sequencer then checks for conflicts. If it finds that one transaction needs to read storage slots modified by another transaction, it re-executes the affected transaction.

Starknet will be the only L2 to support parallelisation.

Starknet hence relies on a dynamically constructed dependency graph that tracks conflicts between transactions allowing Optimistic Parallelisation without access lists. The feature is live on Starknet’s Sepolia Testnet and is due to be on the Mainnet by late August.

A detailed piece on Starknet’s parallelisation is in the works by the Karnot team and will be released shortly.

While Starknet's architecture is complex and multi-layered, simplifying it helps us focus on Starknet’s two major upgrades: Cairo Native and Stwo. However to appreciate these optimisations, we must discuss two components of the Starknet architecture: The Sequencer and The Prover.

The Sequencer has two core tasks, sequencing and execution.

• Sequencing: Ordering transactions and appending new blocks.

• Execution: Executing transactions and updating the system’s state

  • The sequencer, hence is able to provide “soft confirmations” based on the result of its execution, however finality is only achieved with the chain’s settlement on L1.

  • Soft confirmations can be used by dApps to provide real time responsiveness on the premise that the Starknet sequencers’ execution is correct.

The Prover provides a mathematical guarantee that the transactions in a block are executed correctly.

• The prover re-executes the transactions in a “Provable Environment” and generates

  • An Execution Trace: A log of how each transaction was executed

  • A State Diff: A record of how the Starknet state changed after processing the block

• The prover then processes the execution trace, taking random samples to mathematically guarantee the executions validity

• Together “The Proof and State Diff” encapsulate thousands of transactions and their validity

• As dApps operate with Soft Confirmations from the sequencer, the prover is free to operate asynchronously and be scaled horizontally allowing Proof Submission to happen on “a rolling basis”.

Cairo code today undergoes a multi-step compilation process, namely going from a Cairo program to an intermediate representation called Sierra (Safe Intermediate Representation), to finally Cairo Assembly (CASM) that is executed on the Cairo VM.

The presence of the Sierra step ensures safety and prevents runtime errors, guaranteeing that all transactions that reach the Cairo VM are eventually provable. Overall this prevents DDOS and reduces the likeliness of failing transactions reaching execution. Read more here.

Cairo Native significantly boosts performance, allowing up to 1700 swaps per second.

The LambdaClass team has been leading the development of Cairo Native, a compilation optimisation that converts Sierra code to native object code. Cairo Native’s optimised compilation enables significantly faster execution without the need for a Cairo VM. To get a brief idea of Cairo Native, we must understand two key compiler frameworks used in Cairo Native

• LLVM: Assembly Code Abstraction

  • LLVM IR is an intermediate representation that simplifies various CPU instruction sets (like x86 and ARM).

  • It allows for cross-architecture compatibility by using a generic language instead of specific assembly code.

  • LLVM IR maintains a linear instruction sequence, focusing on CPU instruction abstraction.

• MLIR: Abstraction over Intermediate Representation/Computation

  • MLIR builds upon LLVM by using flexible operations that represent a wider range of computations than simple CPU instructions.

• MLIR can convert its representations to LLVM IR, allowing it to benefit from LLVM's optimizations and generate efficient machine code.

How Cairo Native uses both:

• Cairo code is first compiled to Sierra.

• Cairo Native translates Sierra to MLIR operations.

• These MLIR operations are then lowered to LLVM IR.

• LLVM optimizes this IR and generates native machine code.

This approach allows Cairo Native to handle Cairo’s functionality in MLIR, then leverage LLVM's ecosystem for final optimization and code generation.

A detailed piece by the Karnot team on Cairo Native and it’s intricacies is in the works, meanwhile read more here.

As discussed in the Architecture section; it is the role of a Prover to create mathematically sound proofs that attest to a transaction executing correctly. While computationally expensive, provers run “off-chain” and return a ZK-Proof to the Verifier contract; which is lightweight and sufficient to guarantee correct execution.

However, as ZK-Rollups scale, their biggest expenses steer towards being cloud costs incurred by running these provers. Consequently, any improvements in Provers has a amplified impact across the ecosystems expenses. Thus, a faster and more efficient Prover reduces proving costs, latency and potentially increases throughput.

StarkWare’s latest breakthrough titled Circle STARKs introduces major optimisations to STARK calculation (the math behind Starknet’s ZK-Proofs). By working over smaller 31-bit fields instead of 256-bit fields. Computing circle STARKs over 31-bit fields fully utilises 32-bit registers, reducing wasted space and leading to more efficient hardware design. Circle STARKs thus can represent information much more efficiently, making proof creation significantly more hardware friendly.

Stwo has achieved record breaking results, and has benchmarked 1000x the hash rate of its predecessor, Stone.

Read more about Circle STARKs here.

StarkWare shattered the world proving record with over 500,000 hashes proved per second

Starkware’s SHARP is an industry first innovation, enabling Cross Chain Proof Aggregation. In simpler terms, SHARP reduces verification costs by generating recursive STARKs, accepting proofs from ALL Cairo chains.

SHARP’s cross-chain proof aggregation capability has been Mainnet ready since early 2023

By recursively aggregating multiple proofs from the Starknet chain, Paradex, DyDx and other Cairo chains, SHARP effectively spreads the cost of L1 verification across thousands of transactions, creating network effects across the ecosystem.

Stwo, scheduled for release in Q1 2025, is expected to significantly reduce proving costs. With SHARP as an aggregator wrapped atop Stwo, Starknet and all Cairo chains are expected to witness major savings in proving costs.

While we strongly believe Cairo is an efficient proving and advanced smart contract language, there are reasons to deploy on the EVM:

1. Reusing audited smart contracts

2. Leveraging existing Solidity experience for faster shipping

3. Staying with the improving EVM ecosystem

If you choose to build on the EVM, today's ZK-rollup ecosystem includes Scroll, zkSync and Polygon, each using a "low-level circuit" approach for EVM provability.

Kakarot zkEVM is an EVM implementation written in Cairo. It combines Starknet Stack advancements (Stwo, SHARP, Parallelisation, Cairo Native) with EVM ecosystem’s network effects.

Kakarot's intermediate language approach results in a 90% lighter codebase than circuit-based rollups, enabling faster adoption of EVM upgrades and fewer potential vulnerabilities.

Kakarot’s approach significantly simplifies introducing custom precompiles, allowing you to implement builtin functions that would be computationally expensive if executed in EVM bytecode be natively integrated into the Kakarot client; optimized for better performance.

Kakarot zkEVM is expected to achieve 100% EVM compatibility soon. Moreover Kakarot’s bytecode compatibility enables full reuse of Solidity contracts while running your appchain with the security guarantees and proving architecture of all Cairo chains.

The Starknet Stack hence comprises of powerful innovations in the ZK and blockchain space. However till date, the only way to run a custom Starknet chain, alike Paradex and DyDx was through StarkEx, Starkware’s appchain-as-a-service offering. And whilst StarkEx has been in production on Mainnet since June 2020, StarkEx was closed source and had limited access.

With Madara we bring the same stack that powers over $1B TVL to everyone.

Inspired by the StarkEx, Madara is a performant and open-source implementation of the Starknet Stack. Madara is developed with a focus on fractal scaling—the use of L2s and L3s to exponentially scale Ethereum, whilst benefitting from all upgrades to ANY components of the Starknet Stack.

Madara's architecture enables integrating app-level customizations deep into the protocol layer, allowing fine-tuning of block times, gas costs, provers, and data availability layer according to the app's requirements.

With Madara, any app can be an appchain.

Read more about Madara here.

At Karnot, we're proud to be core contributors to the Madara project and the leading RaaS provider for Madara app chains. Our team brings years of experience in building scalable, fault-tolearnt systems. Through successfully running multiple devnets and testnets, we've continuously refined our services, ensuring robust and battle-tested solutions. We continue to actively contribute to Madara's development while strengthening our infrastructure to offer "Appchains as a Service". This dual focus puts Karnot in a unique position to build AND provide exceptional scaling solutions to appchains across the ecosystem.

Whether you're looking to build EVM app chains or Starknet app chains, we're here to support your project. We invite you to connect with us and explore how our expertise can accelerate your appchain journey.