High-Level Overview

StarkEx is an Ethereum L2 scalability solution that is based on validity proofs. It can operate in either a zkRollup or Validium data-availability modes.​

Every application built on top of StarkEx defines its own business logic and runs on top of the StarkEx Service. The system has an off-chain component and an on-chain component. The off-chain component holds the state, orders transaction execution in the system, and sends state updates to the on-chain component. The on-chain component holds the state commitments, holds the system assets, and is responsible for enforcing the validity of state transition.

All the transactions in the system are executed by the Application and are 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 to verify it. 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.

When a user wants to use the system, they 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 get their funds on-chain once the state update containing the withdrawal is accepted.

To prevent censorship, if the user's requests are not fulfilled, they can force the execution by using forced transactions.

System Components

The StarkEx system consists of the following components:

  • Application - The operator of the system. An off-chain component that receives user transactions, defines the business logic and order of execution. Eventually, it sends the transactions to the StarkEx Service.

  • StarkEx Service - An off-chain component, responsible for the batching of a set of operations and to update 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 it's validity. Once to proof is verified, it publishes the new state on-chain. The state is represented by a Merkle tree, with leaves which are vaults. The structure and content of each vault varies according to the specific business logic implemented. See here for more details. The Merkle tree root is the state commitment to be submitted on-chain.

  • SHARP - 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 - This is an on-chain component that receives a state update validity proof and verifies that the proof is valid.

  • StarkEx Contract - This contract has two main functionalities. The first one 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 will be able to withdraw their funds.

Edit on GitHub