Karak – L2BEAT

Website	karak.network
App	karak.network/karak-xp
Docs	docs.karak.network/karak/general/karak-overview
Explorer	explorer.karak.network
Social	@Karak_Network Karak_Network

Karak Network Early Access Launch

2024 Feb 27th

Karak Network is live on mainnet.

Fraud proof system is currently under development. Users need to trust the block proposer to submit correct L1 state roots.

Fraud proof system is currently under development. Users need to trust the block proposer to submit correct L1 state roots.

Sequencer failureState validationData availabilityExit windowProposer failure

State validation

In development

Currently the system permits invalid state roots. More details in project overview.

Data availability

External

Proof construction and state derivation fully rely on data that is posted on Celestia. Sequencer tx roots are not checked against the Blobstream bridge data roots onchain, but L2 nodes can verify data availability by running a Celestia light client.

Exit window

None

There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

Sequencer failure

Self sequence

In the event of a sequencer failure, users can force transactions to be included in the project’s chain by sending them to L1. There is a 12h delay on this operation.

Proposer failure

Cannot withdraw

Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.

6

Technology

Fraud proofs are in development

Ultimately, OP stack chains will use interactive fraud proofs to enforce state correctness. This feature is currently in development and the system permits invalid state roots.

Funds can be stolen if an invalid state root is submitted to the system (CRITICAL).

L2OutputOracle.sol - Etherscan source code, deleteL2Outputs function

Data is stored on Celestia

Transactions roots are posted onchain and the full data is posted on Celestia. Since the Blobstream bridge is not used, availability of the data is not verified against Celestia validators, meaning that the Sequencer can single-handedly publish unavailable roots.

Funds can be lost if the sequencer posts an unavailable transaction root (CRITICAL).
Funds can be lost if the data is not available on the external provider (CRITICAL).

7

Operator

The system has a centralized operator

The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.

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-chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract directly.

8

Withdrawals

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 3d to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

Funds can be frozen if the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production (CRITICAL).

Forced exit

If the user experiences censorship from the operator with regular exit they can submit their withdrawal requests directly on L1. The system is then obliged to service this request or halt all withdrawals, including forced withdrawals from L1 and regular withdrawals initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular exit.

Forced withdrawal from an OP Stack blockchain

9

Other considerations

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.

Introducing EVM Equivalence

10

Permissions

The system uses the following set of permissioned addresses:

ProxyAdmin 0x1612…065C

Owner of AddressManager. Admin of OptimismPortal, SystemConfig, L2OutputOracle, L1ERC721Bridge, OptimismMintableERC20Factory, L1StandardBridge.

Sequencer 0x84Bd…1e4E

Central actor allowed to commit L2 transactions to L1.

Proposer 0x4179…729e

Central actor allowed to post new L2 state roots to L1.

Challenger 0x28A2…b920

Central actor allowed to delete L2 state roots proposed by a Proposer.

Guardian 0x28A2…b920

Central actor allowed to pause deposits and withdrawals.

KarakMultisig 0x28A2…b920

This address is the owner of the following contracts: ProxyAdmin, SystemConfig. It is also designated as a Challenger and Guardian of the OptimismPortal, meaning it can halt withdrawals and change incorrect state roots. It can upgrade the bridge implementation potentially gaining access to all funds, and change the sequencer, state root proposer or any other system component (unlimited upgrade power). This is a Gnosis Safe with 3 / 5 threshold.

KarakMultisig participants 0xAb86…2cac 0x7E97…8Cd0 0xBcB3…28d3 0x9883…A4f2 0x282D…D117

Those are the participants of the KarakMultisig.

11

Smart contracts

The system consists of the following smart contracts:

L2OutputOracle 0x0a23…1637 Implementation (Upgradable)Admin

The L2OutputOracle contract contains a list of proposed state roots which Proposers assert to be a result of block execution. Currently only the PROPOSER address can submit new state roots.