Comment on page
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.
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:
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.
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.
Kroma has a dispute period of 7 days. with our ZK Rollup upgrade, we plan to reduce the dispute period to 1 hour.
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.
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.
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.
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.
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:
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.
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 less.
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.
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.