Paradex

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.

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.

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.

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

There is no general mechanism to force the sequencer to include the transaction.

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.

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.