🤔Starkware logic
Tech Docupaper ( Part II ): Covers an overview of Starkware logic used by Brine.
Last updated
Tech Docupaper ( Part II ): Covers an overview of Starkware logic used by Brine.
Last updated
Receives transactions from the Customer Exchange and stores them in the transaction stream. It also, implements context-free validation of transactions (e.g., requests format and value range checks).
Responsible for batching transactions together and ensures the (context-full) validity of each transaction execution (e.g., sufficient balances, both off-chain and on-chain (in the case of deposits, for example).
If no errors occur, each batch is based on the one produced just before it (a batch starts from the first transaction not included in the previous batch and is based on the state the previous batch transits to). This results (normally) in a chain of batches. In case one of the batches fails to update the StarkEx smart contract's state (e.g., is reverted on-chain), the issue is automatically detected, and the following 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 the transactions just before adding them to a batch (even if they passed validation before) because the context might affect its validity (e.g., off-chain and on-chain balances), and the context can change between validations.
Provides information about the batches created by the system (lists of transactions and batch are they based on) to external spectators.
A mechanism allowing custom off-chain logic to be used in order to approve the batch submission. An approving party needs to present a signature approving the batch, and the batch submission is allowed only if a sufficient quorum from a predefined committee approved the batch.
Ensuring state consistency with the Exchange To avoid the situation where StarkWare submits a state transition inconsistent with the customer Exchange's expectation, it is also good practice for the client to approve each batch.
Ensuring off-chain data-availability Supports custom validators to ensure that all the data required to ensure traders' self custody, after a requested state transition, is accessible.
Responsible for the generation of a state transition proof (via an external proving service) and ensuring the corresponding fact is registered on the on-chain Verifier fact registry.
Responsible for sending packages to be transmitted to the blockchain. The packages contain the recipient Ethereum address and the payload to be sent there. The packages are passed by a stream, and their order in the stream defines the order they will be transmitted (and mined) on the blockchain.
Wraps the packages with network-related data (i.e., adds gas price, nonce, signature, etc.) and transmits the transaction to the blockchain. It makes sure the transactions are mined and includes a custom mechanism to increase gas prices if needed.
Monitors the blockchain and reports reverted batches to the batcher.
