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.
The section shows the operating costs that L2s pay to Ethereum.
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.
Starknet is a Validity 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.
The Starknet ZK Rollup shares its SHARP verifier with other StarkEx and SN Stack Layer 2s. Governance of the system is currently split between three major Multisig admins with instant upgrade capability and one ops Multisig that can tweak central configurations.
The 2 / 6 StarknetAdminMultisig can upgrade the Starknet contract, while the 2 / 5 StarknetOpsMultisig is permissioned to tweak its configuration. Starkgate bridge contracts can be upgraded (and configured) by the StarknetEscrowMultisig without delay.
The shared SHARPVerifier contract is governed by the 2 / 4 SHARPVerifierAdminMultisig, who can upgrade it without delay, affecting all StarkEx and SN stack chains that are using it.
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.
A Multisig with 2 / 6 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.Currently there is 0s delay before the upgrade.
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.
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 / 5 threshold. Can appoint operators, change the programHash, configHash, or message cancellation delay.
Allowed to post state updates. When the operator is down the state cannot be updated.
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 3 / 12 threshold. Allowed to post state updates. When the operator is down the state cannot be updated.
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).
