Kroma
Badges
About
Kroma aims to develop an universal ZK Rollup based on the Optimism Bedrock architecture. Currently, Kroma operates as an Optimistic Rollup with ZK fault proofs, utilizing a zkEVM based on Scroll.
Badges
About
Kroma aims to develop an universal ZK Rollup based on the Optimism Bedrock architecture. Currently, Kroma operates as an Optimistic Rollup with ZK fault proofs, utilizing a zkEVM based on Scroll.
Ecotone upgrade
2024 Apr 25th
Introduces EIP-4844 data blobs for L1 data availability and more L2 opcodes.
Chain fork #2 - Output root replaced
2024 Apr 5th
The chain forked and an L2 output on Ethereum has to be replaced by the Security Council.
Funds can be stolen if
Funds can be lost if
MEV can be extracted if
Sequencer failure
Self sequenceState validation
Fraud proofs (INT, ZK)Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve. ZK proofs are used to adjudicate the correctness of the last step. The challenge protocol can be subject to delay attacks and can fail under certain conditions. The current system doesn’t use posted L2 txs batches on L1 as inputs to prove a fault, meaning that DA is not enforced.
Exit window
NoneThere is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Kroma is a Fraud Proofs ensure state correctness
Kroma uses an interactive fraud proof system to find a single block of disagreement, which is then ZK proven. The zkEVM used is based on Scroll. Once the single block of disagreement is found, the challenger is required to present a ZK proof of the fraud. If the proof is validated, the incorrect state output is deleted. The Security Council can always override the result of the challenge, it can also delete any L2 state root at any time. If the malicious attester and challenger collude and are willing to spend bonds, they can perform a delay attack by engaging in continuous challenges resulting in a lack of finalization of the L2 state root on L1. The protocol can also fail under certain conditions.
Withdrawals can be delayed if the fraud proof system is under a delay attack.
Funds can be lost if the cryptography is broken or implemented incorrectly.
All transaction data is recorded on chain
Kroma nodes source code, including full node, proposer and validator, can be found here. Also, the geth server, source maintained here, is a fork of go-ethereum. For more details on how they are different from the Optimism implementation, see here. The instructions to run the proposer (called validator) and the ZK prover, are documented here.
Data batches are compressed using the zlib algorithm with best compression level.
The genesis file can be found here.
The system has a centralized sequencer
While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can force any transaction
Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.
Regular exit
The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. The process of block finalization takes a challenge period of 7d to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.
Autonomous exit
Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.
EVM compatible smart contracts are supported
OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.
The system uses the following set of permissioned addresses:
Can upgrade all Spectrum-related contracts and potentially gain access to all escrowed weETH.
MultiSig (currently 8 / 10) that is a guardian of KromaPortal, privileged Validator that does not need a bond and privileged actor in Colosseum contract that can remove any L2Output state root regardless of the outcome of the challenge.
Members of the SecurityCouncil.
Actor allowed to pause withdrawals. Currently set to the Security Council.
This is a Gnosis Safe with 3 / 5 threshold. Escrows a pool of KRO used as validator rewards by the AssetManager.
Those are the participants of the KromaRewardVaultMultisig.
The system consists of the following smart contracts on the host chain (Ethereum):
The L2OutputOracle contract contains a list of proposed state roots which Proposers assert to be a result of block execution. Anyone can participate as a Proposer by depositing in the ValidatorPool. A root can be proposed every 1h.
Upgrade delay: 0s delay
Upgrade delay: 0s delay
The L1 Cross Domain Messenger contract sends messages from L1 to L2, and relays messages from L2 onto L1. In the event that a message sent from L1 to L2 is rejected for exceeding the L2 epoch gas limit, it can be resubmitted via this contract’s replay function.
Upgrade delay: 0s delay
Timelock contract behind which the ProxyAdmin is. There is a 0s delay.
Contract allowed to start upgrades, dismiss challenges and delete roots. It is also designated as a guardian, meaning it can pause withdrawals.
Upgrade delay: 0s delay
Controls the Timelock. It is governed using a Soulbound NFT.
Admin of the L2OutputOracle, Timelock, KromaPortal, SystemConfig, SecurityCouncil, L1CrossDomainMessenger, L1ERC721Bridge, ZKVerifier, Colosseum, L1StandardBridge, UpgradeGovernor, SecurityCouncilToken, ValidatorPool proxies. It’s effectively controlled by the Security Council. The proxy is behind a Timelock.
Contract used to challenge state roots and prove fraud. The SecurityCouncil can interfere by deleting challenges and roots.
Upgrade delay: 0s delay
Contract used to manage the Proposers. Anyone can submit a deposit and bond to a state root, or create a challenge. It also manages the Proposer rotation for each submittable block using a random selection. If the selected proposer fails to publish a root within 30m, then the submission becomes open to everyone.
Upgrade delay: 0s delay
Manages the set of Proposers (Validators in Kroma) and selects the next proposer with the window to submit the output root within 30m, after which anyone propose for them. It is also the entry point for other contracts, such as the L2OutputOracle and the Colosseum, which distribute output rewards and slash challenge losers. It makes successive calls to the AssetManager to apply changes to the proposers’ assets.
Upgrade delay: 0s delay
Manages the delegation and undelegation of KRO tokens and Kroma Guardian House (KGH) NFTs for Proposers (Kroma Validators) and distributes rewards.
Upgrade delay: 0s delay
Trie contract used to prove withdrawals.
ZK verifier used to verify the last step of a fraud proof, which corresponds to a block.
Upgrade delay: 0s delay
Contract used to compute hashes. It is used by the ZKMerkeTrie. The contract has been generated using the circomlibjs library.
Value Locked is calculated based on these smart contracts and tokens:
Main entry point for users depositing ERC20 token that do not require custom gateway.
Main entry point for users depositing ETH.
Main entry point for users depositing USDC.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is a 0s delay on code upgrades.
