.png)
https://docs.starkware.co/starkex-v4/overview
StarkEx is an Ethereum Layer 2 (L2) scalability solution that is based on validity proofs. It can operate in either ZK-Rollup 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.
StarkEx是基于有效性证明的以太坊L2可扩展性解决方案。 它可以在zkRollup或Validium数据可用性模式下运行。
每个在StarkEx之上架构的应用程序都会定义自己的业务运行逻辑，并在StarkEx服务上运行。 该系统具有链上组件和链下组件。 链下组件持有状态，命令执行系统中的交易，并将状态更新发送到链上组件。 链上组件持有状态承诺，持有系统资产，并负责执行状态转换的有效性。
系统中的所有交易都通过应用程序执行，并发送到StarkEx服务。 StarkEx服务对交易进行批处理，并将批处理发送到SHARP（共享证明服务），生成一份证明来表明批处理的有效性。SHARP将STARK证明发送给STARK验证器进行验证。服务随后发送一份链上状态更新交易到StarkEx合约，仅在证明被验证器验证有效时，交易才会被接受。
用户以两种方式与系统交互-通过发送链上交易到StarkEx合约和发送链下交易到应用程序。
当用户想要使用该系统时，他们首先将starkKey注册到StarkEx合约中的以太坊地址。starkKey用于验证用户的链下交易。 然后，用户将其资金存入StarkEx合约。 在应用程序接受存款后，用户可以在链下使用其资金。
用户将由starkKey签名的转账或限价单直接提交给应用程序。限价单被匹配在一起，并作为结算发送给StarkEx服务。转账行为照原样发送。不同类型的转账交易可以由额外的逻辑来执行。
为提取资金，用户应向应用程序提交链下提款请求。此请求被发送到StarkEx服务，一旦包含提款的状态更新被接受，用户就可以在链上获取其资金。
为了防止审查，如果用户的提款请求没有得到实现，他们可以使用强制操作来强制执行。
StarkEx系统包含以下组件：
● 应用程序- 系统的操作员。 接收用户交易的链下组件，定义业务运行逻辑和执行的顺序。最终，它将交易发送到StarkEx服务。
● StarkEx服务-一个链下组件，负责批处理一组操作，根据这些操作更新系统状态。针对每一批，StarkEx服务将发送此批的操作(作为Cairo执行痕迹)到SHARP进行有效性证明，一旦证明被验证，它将新状态发布在链上。 状态由 Merkle tree呈现，其叶子是保险库。每个保险库的结构和内容根据所实施的特定业务逻辑而有所不同。更多详细信息，请参见此处。Merkle tree的根是未被提交到链上的状态承诺。
● SHARP- Cairo程序的共享证明服务。 它接收来自不同应用程序的证明请求，并输出证明以证明Cairo执行的有效性。输出的证明可以在多个证明请求之间共享。
● **STARK验证器-**这是一个链上组件，用于接收状态更新有效性证明并验证该证明是否有效。
● StarkEx合约-该合约有两个主要功能。 第一个是在确认有效性条件得以满足后更新系统状态。第二个功能是以自主托管方式管理在StarkEx中的进出资金，这意味着在任何情况下，用户都可以提取其资金。