Starknet
Badges
About
Starknet is a general purpose ZK Rollup based on STARKs and the Cairo VM.
Badges
About
Starknet is a general purpose ZK Rollup based on STARKs and the Cairo VM.
2024 Feb 23 — 2025 Feb 22
2024 Feb 23 — 2025 Feb 21
The section shows the operating costs that L2s pay to Ethereum.
2024 Feb 22 — 2025 Feb 21
Starknet Provisions
2024 Feb 14th
Starknet begins allocating $STRK to early contributors and users.
Funds can be stolen if
Funds can be lost if
Funds can be frozen if
Users can be censored if
MEV can be extracted if
Sequencer failure
No mechanismThere is no mechanism to have transactions be included if the sequencer is down or censoring.
State validation
ZK proofs (ST)STARKs are zero knowledge proofs that ensure state correctness.
Data availability
Onchain (SD)All of the data (SD = state diffs) needed for proof construction is published onchain.
Exit window
NoneThere is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.
Proposer failure
Cannot withdrawOnly the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.
The information in the section might be incomplete or outdated.
The L2BEAT Team is working to research & validate the content before publishing.
Starknet is currentlyValidity proofs ensure state correctness
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
Zero knowledge STARK cryptography is used
Despite their production use zkSTARKs proof systems are still relatively new, complex and they rely on the proper implementation of the polynomial constraints used to check validity of the Execution Trace.
Funds can be lost if the proof system is implemented incorrectly.
All data required to reconstruct rollup state is published on chain
State diffs are publish onchain as blob or calldata on every state update. The state diffs contain information on every contact whose storage was updated, and additional information on contract deployments. From diffs full system state can be recovered. Contracts’ code is not published on L1, but can be trustlessly verified if available elsewhere.
EthereumStarknet doesn’t use any compression scheme.
There is no non-empty genesis state.
The data format has been updated with different versions, and the full specification can be found here.
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
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. Typically, the Operator is the hot wallet of the Starknet service submitting state updates for which proofs have been already submitted and verified.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Users can't force any transaction
There is no general mechanism to force the sequencer to include the transaction.
Users can be censored if the operator refuses to include their transactions.
Regular messaging
The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks. Note that the message request can be censored by the Sequencer.
Funds can be frozen if the operator censors withdrawal transaction.
Emergency exit
There is no generic escape hatch mechanism as Starknet cannot be forced by users into a frozen state. Note that a freezing mechanism on L2, to be secure, requires anti-censorship protection.
Ethereum
Actors:
A Multisig with 9 / 12 threshold. Can upgrade the central Starknet constract, potentially potentially allowing fraudulent state to be posted and gaining access to all funds stored in the bridge. Can also appoint operators, change the programHash, configHash, or message cancellation delay without upgrading the contract.Currently there is 0s delay before the upgrade.
Can upgrade implementation of SHARP Verifier, potentially with code approving fraudulent state. Currently there is 0s delay before the upgrade.
Used in:
A Multisig with 2 / 4 threshold. SHARP Verifier Governor.
Used in:
A Multisig with 2 / 4 threshold. Can upgrade most of the Starkgate bridge escrows including the Starkgate Multibridge. Can also configure the flowlimits of the existing Starkgate escrows or add new deployments.
Allowed to post state updates. When all operators are down the state cannot be updated.
A Multisig with 3 / 12 threshold. An Operator. Allowed to post state updates. This minority multisig with the SecurityCouncil members is the only fallback in case of censorship by other operators.
A Multisig with 1 / 3 threshold. Can enable withdrawal limits for tokens in some Starkgate bridge Escrows.
Can upgrade implementation of the LUSD escrow, potentially gaining access to all funds stored in the bridge. Currently there is 0s delay before the upgrade.
Can remove and blacklist tokens from the Starkgate bridge.
Ethereum
CallProxy for GpsStatementVerifier.
Proxy used in:
Starkware SHARP verifier used collectively by Starknet, Sorare, ImmutableX, Apex, Myria, rhino.fi and Canvas Connect. It receives STARK proofs from the Prover attesting to the integrity of the Execution Trace of these Programs including correctly computed state root which is part of the Program Output.
Implementation used in:
MemoryPageFactRegistry is one of the many contracts used by SHARP verifier. This one is important as it registers all necessary onchain data.
Implementation used in:
Same as MemoryPageFactRegistry but stores facts proved by the old SHARP Verifier, used as a fallback.
Implementation used in:
This contract allows the permissionless creation and configuration of StarkGate token escrows. Tokens can also be blacklisted for creation, and already actively bridged tokens can be deactivated from depositing by a designated TokenAdmin.
A central registry contract to map token addresses to their StarkGate bridge contract.
Value Secured is calculated based on these smart contracts and tokens:
DAI Vault for custom DAI Gateway managed by MakerDAO. The current bridge cap is 5.00 M DAI.
StarkGate bridge for LORDS.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).
