FAQs

What is Kroma?

Kroma is an EVM-equivalent rollup protocol designed to scale Ethereum. It combines the benefits of Optimistic and ZK rollups to provide fast finality while maintaining EVM equivalence.

For a detailed introduction, read our medium article: "Introduction to Kroma".

What does "Kroma" mean?

Kroma, derived from the Greek word "chroma", embodies our mission to create an L2 that is vibrant, scalable, and simultaneously capable of organic operations.

Why Kroma?

Kroma offers 10x lower transaction fees compared to the Ethereum mainnet, native Ethereum security, and EVM equivalence. Our roadmap to transition from Optimistic rollup to ZK rollup sets Kroma apart from other L2 networks.

For smart contract developers:

• Contracts can be deployed with significantly less gas fees on Kroma.

For node validators:

• Everyone has the opportunity to participate as a validator. You can read our article 'The Road to Kroma's Decentralization' to learn more or follow our docs to become a validator on Kroma.

What is the current progress on Kroma?

Kroma is the first OP Stack rollup with active fault proofs using zkEVM, and we're working on optimizing ZK Proofs to transition to ZK Rollup as part of our roadmap. If you'd like to know more about Kroma's rollup stage, please refer here.

What does 'Stage' mean in Rollups?

This began with Vitalik Buterin's proposal of a rollup framework on the Ethereum Magicians' forum, suggesting a guide for the rollup system to achieve complete decentralization based on the maturity of the technology. (which Buterin likens to having "wheels")

Stage 0 - "full training wheels"

• All rollup transactions should go on-chain.

• There should exist a “rollup full node”: an independently runnable software package that can read the L1 chain, extract and the rollup chain, and compute the current state of the rollup chain. If it disagrees with a rollup state root posted into the contract, it should give an alarm.

• There should be machinery that allows users to either post rollup transactions or at least ensure a withdrawal of their assets with no cooperation from the operator. That is, the operator cannot freeze or steal users’ assets by censoring users; their only possible tool for doing so must be to post a false state root.

• It’s okay if the on-chain mechanism for posting new state roots is simply a multisig, with no active fraud proof or validity proof whatsoever.

Stage 1 - "limited training wheels"

• There must be a running fraud proof or validity proof scheme, which has the practical authority to accept or reject which state roots get accepted by the rollup contract.

• There can exist a multisig-based override mechanism (“security council”) that can override the fraud proof or validity proof system’s outputs and post state roots, to be used in case the proof system code is bugged. However, the framework also must have a strict multisig threshold requirement.

• There can exist an upgrade mechanism, but if it has a lower threshold than the multisig, upgrades must have a mandatory activation delay of at least 7 days or the maximum length of the fraud proof game, whichever is longer. The goal of this rule is to ensure that the upgrade mechanism cannot be used to intervene in real-time disputes.

Stage 2 - "no training wheels"

• In the event that code does not have bugs, there must not be any group of actors that can, even unanimously, post a state root other than the output of the code.

• The rollup uses two or more independent implementations of its state transition function (eg. two distinct fraud provers, two distinct validity provers, or one of each), and the security council can adjudicate only if they disagree - which would only happen if there is a bug.

• If someone submits a transaction or series of transactions that contains two valid proofs for two distinct state roots after processing the same data (ie. “the prover disagrees with itself”), control temporarily turns over to the security council.

• If no valid proof is submitted for >= 7 days (ie. “the prover is stuck”), control temporarily turns over to the security council.

• Upgrades are allowed, but must have a delay of >= 30 days.

How long is the withdrawal period on Kroma?

Kroma has a dispute period of 7 days. with our ZK Rollup upgrade, we plan to reduce the dispute period to 1 hour.

What is the block Time & Gas Limit on Kroma?

Kroma L2 Blocks are generated in 2-second intervals.

The difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the batch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a reference to the previous block.

The block gas limit is currently set to 30,000,000 or 30M units.

How are fees calculated in Kroma?

Kroma transaction fees include the cost to execute the transaction on L2 and the cost to submit the output root to L1 for data availability.

What is Layer 2(L2)?

In the context of Kroma, Layer 1(L1) refers to the Ethereum network, while Layer 2(L2) refers to Kroma. You can find instructions on how to set it up in the documentation.

Layer 2(L2) is a collective term used to describe a specific set of Ethereum scaling solutions. Essentially, L2 is a separate blockchain built on Ethereum that inherits the same security as Ethereum and offers lower fees.

What is a Rollup?

Rollups are currently the preferred L2 solution for scaling Ethereum. Using rollups, users can reduce gas fees by up to 10x in comparison to L1.

Rollups bundle (aka "roll up") hundreds of transactions into a single transaction on L1. This process distributes the L1 transaction fees across everyone in the rollup, making it cheaper for each user. Rollup transactions get executed outside of L1 but the transaction data gets posted to L1. By posting transaction data onto L1, rollups inherit the security of Ethereum.

There are two different approaches to rollups: Optimistic and ZK - they differ primarily on how this transaction data is posted to L1.

What is an Optimistic Rollup?

Optimistic rollups are L2 protocols designed to extend the throughput of Ethereum's base layer. They reduce the amount of computation on the main Ethereum chain by processing transactions off-chain, significantly improving processing speeds. Unlike other scaling solutions, such as, optimistic rollups are secured by the Ethereum mainnet by publishing transaction results on-chain.

For more details, we recommend reading:

• Optimism's Introduction to Optimistic Rollups.

What is a ZK Rollup?

ZK rollups are L2 scaling solutions that increase the throughput of the Ethereum mainnet by moving computation and state-storage off-chain. ZK rollups can process thousands of transactions in a single batch and only post minimal summary data to the Ethereum mainnet. This summary data defines the changes that should be made to the Ethereum state and cryptographic proof that the changes are valid.

Why is ZK Rollup the future?

According to Vitalik Buterin's opinion, ZK rollups would eventually surpass Optimistic rollups because they have these real benefits, like not needing a seven-day withdrawal period. He predicted the Rollups would be all ZK in ten years, if not

What is an Ethereum Virtual Machine (EVM)?

Ethereum Virtual Machine (EVM) is the computation engine that computes a new Ethereum state block by block, ensuring that all transactions on the blockchain are valid in one canonical state. It is a single entity powered by thousands of computers each running the Ethereum node.

What is a zkEVM?

A zkEVM is an EVM-compatible virtual machine that supports zero-knowledge proof computation. Unlike regular virtual machines, a zkEVM proves the correctness of program execution, including the validity of inputs and outputs used in the operation.

Why is zkEVM difficult to build?

Because the EVM wasn’t built with zk-proof computation in mind, it has features that are unfriendly for proving circuits. If you're interested in more, you can read here.