StarkEx is an Ethereum Layer 2 (L2) scalability solution that is based on validity proofs. It can operate in either zkRollup or Validium data-availability modes.
Every application built on top of StarkEx defines its own business logic and runs on the StarkEx Service. The system has an off-chain component and an on-chain component. The off-chain component holds the state of orders, performs transaction executions in the system, and sends state updates to the on-chain component.
The on-chain component holds the state commitments and the system assets; and is responsible for enforcing the validity of state transition. In the case of StarkEx for spot trading, it also manages the on-chain accounts, which are useful in the context of Layer 1 (L1) dApp interoperability and DeFi pooling.
All the transactions in the system are executed by the Application and sent to the StarkEx Service. The StarkEx Service batches transactions and sends the batch to SHARP, a shared proving service, to generate a proof attesting to the validity of the batch. SHARP sends the STARK proof to the STARK Verifier for verification. The service then sends an on-chain state update transaction to the StarkEx Contract, which will be accepted only if the verifier finds the proof valid.
Users interact with the system in two ways: by sending on-chain transactions to the StarkEx Contract and off-chain transactions to the Application.
For an off-chain account, users first register their
starkKey to their Ethereum Address in the StarkEx Contract. The
starkKey is used to authenticate the user's off-chain transactions. The user then deposits their funds to the StarkEx Contract. After the Application accepts the deposit, the user can use their funds off-chain.
Users submit Transfers or Limit Orders, signed by their
starkKey, directly to the Application. Limit orders are matched together and sent as a Settlement to the StarkEx Service. Transfers are sent as-is. Additional logic can be enforced on different types of Transfers.
To withdraw their funds, users submit an off-chain withdrawal request to the Application. This request is sent to the StarkEx Service, and the user can access their funds on-chain once the state update containing the withdrawal is accepted.
To prevent censorship, if the user's withdrawal requests are not fulfilled, they can force the execution with forced transactions.
The StarkEx system consists of the following components:
Application – system operator
This off-chain component receives user transactions and defines the business logic and order of execution. It passes transactions to the StarkEx Service.
StarkEx Service – batching and coordination
An off-chain component responsible for batching a set of operations and updating the state of the system according to the operations. For each batch, it sends the batch of operations (as a Cairo execution trace) to SHARP in order to prove its validity. Once the proof is verified, it publishes the new state on-chain. The state is represented by a Merkle tree in which "leaves" are vaults. The structure and content of each vault vary according to the specific business logic implemented. See here for more details. The Merkle tree root represents the state commitment to be submitted on-chain.
SHARP – proving
A shared proving service for Cairo programs. It receives proof requests from different applications and outputs proofs to attest to the validity of Cairo executions. The output proof can be shared among multiple proof requests.
STARK Verifier – verification
An on-chain component that receives a state update validity proof and verifies that the proof is valid.
StarkEx Contract - state updates, deposits, and withdrawals
This contract has two main functionalities. The first is to update the state of the system after verifying that the validity conditions are met. The second functionality is to manage deposits and withdrawals to and from StarkEx in a non-custodial manner – meaning that in any scenario, the user is able to withdraw their funds.