StarkEx backend architecture
The StarkEx gateway receives transactions from the application and validates them in parallel for stateless criteria, such as formatting and value ranges in API calls, and then stores them in the transaction queue.
2. Batcher: Batching and validation
The Batcher collects transactions into a batch and validates them sequentially, considering their context, as the validity of a transaction often depends upon a previous transaction. For example, a withdrawal is only valid after a deposit provides sufficient off-chain and on-chain balances.
If no errors occur, each batch is based on the preceding batch. A batch starts from the first queued transaction that was not included in the previous batch and is based on the StarkEx state that includes the previous batch. This mechanism normally results in a chain of batches. If a batch fails to update the StarkEx smart contract’s state for any reason, such as being reverted on-chain, the issue is automatically detected, and subsequent batches are based on the last valid batch.
If a transaction is found to be invalid, it is replaced using a custom strategy. It is important to validate transactions just before adding them to a batch, even if they already passed validation, because the context, such as off-chain and on-chain balances, might affect its validity, and the context can change between validations.
3. Feeder Gateway: Provides information about batches
Provides information to external parties about verified batches and lists of the transactions in those batches.
4. Availability Gateway: Change approval
A mechanism that allows custom off-chain logic to be used in order to approve the batch submission. An approving party must present a signature approving the batch, and the batch submission is allowed only if a sufficient quorum from a predefined committee approves the batch.
Ensuring state consistency with the operator
To avoid a situation in which StarkWare submits a state transition inconsistent with what the operator expects, it is also good practice for the client to approve each batch.
5. Ambassador: Proving
Once transactions have been batched together, StarkEx submits the batch to the Cairo program and sends the execution trace of the Cairo program as a job to SHARP, which recursively combines several claims into one proof.
After constructing the recursive proof, SHARP transmits it to the on-chain Verifier smart contract.
6. Dispatcher: Packaging
Responsible for sending packages to be transmitted to the blockchain. The packages contain the recipient’s Ethereum address and the payload to be sent. The packages are passed in a stream, and their order in the stream defines the order in which they are transmitted and mined on the blockchain.
7. Blockchain writer
StarkEx applies the state transition to your application’s smart contract. To ensure that SHARP verified it, the customer application’s smart contract corroborates that the transition statement is registered in the Verifier smart contract.
The Blockain writer wraps the packages with network-related data, including a gas price, a nonce, and a signature. The writer transmits the transaction to the blockchain, ensuring that the transactions are included in a block. The writer includes a custom mechanism to increase gas prices if needed.
Monitors the blockchain and reports reverted batches to the Batcher.