Brine's Docupaper
AboutTrade
  • ABOUT
    • ๐Ÿ“’Brine Docupaper
    • ๐Ÿช™Tokenomics
  • ๐Ÿ—ž๏ธBrine Bytes
    • ๐ŸงตOctober Edition
  • TECH
    • ๐Ÿ‘ฉโ€๐Ÿ’ปTech Docupaper
      • ๐ŸจHigh level architecture
      • ๐Ÿค”Starkware logic
      • ๐ŸŒŠTransactional flow
        • Off-chain accounts
        • The deposit flow
        • The withdrawal flow
        • The trade flow
        • The transfer flow
        • Full withdrawal
    • ๐Ÿ”ŒAPI Documentation
      • ๐Ÿ˜‹Getting started
        • Test connectivity
      • ๐Ÿ“ˆMarket
        • 24hr Tickers Price
        • K-line/Candlestick data
        • Orderbook
        • Recent trades
      • โ†”๏ธTrading
        • Create order
        • Get order
        • List orders
        • Cancel order
        • List trades
      • ๐Ÿ”Account
        • Login
        • Profile Information
        • Balance details
        • Profit and loss details
      • ๐ŸŒWeb-socket stream
        • ๐Ÿ—๏ธPrivate web-socket connection
        • ๐Ÿ‘ฅPublic websocket connection
      • โœจInternal Transfer
        • Create Internal Transfer
        • Get Internal Transfer
        • Check User Existence
        • List Internal Transfers
      • ๐ŸงชSDK Reference
        • NodeJS SDK
  • FOR USERS
    • ๐Ÿ“’User Docuguide
      • ๐Ÿ’ปWeb App
        • Sign up through Metamask
        • Sign up through Wallet Connect
        • Place a Market Order Trade
        • Place a Limit Order Trade
        • Refer Brine to a Friend
        • Deposit with Metamask
        • Withdraw to Metamask
  • LEGAL
    • โ€ผ๏ธDisclaimer
Powered by GitBook
On this page
  • 1. Gateway
  • 2. Batching & Validation
  • 3. Batches Info. (Feeder Gateway)
  • 4. Changes Approval Gateway (Availability Gateway)
  • 5. Proving (Ambassador)
  • 6. Packing (Dispatcher)
  • 7. Blockchain Writer
  • 8. Catcher

Was this helpful?

  1. TECH
  2. Tech Docupaper

Starkware logic

Tech Docupaper ( Part II ): Covers an overview of Starkware logic used by Brine.

PreviousHigh level architectureNextTransactional flow

Last updated 1 year ago

Was this helpful?

1. Gateway

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).

2. Batching & Validation

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.

In this case batch 3 is found to be invalid.

3. Batches Info. (Feeder Gateway)

Provides information about the batches created by the system (lists of transactions and batch are they based on) to external spectators.

4. Changes Approval Gateway (Availability Gateway)

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.

5. Proving (Ambassador)

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.

6. Packing (Dispatcher)

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.

7. Blockchain Writer

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.

8. Catcher

Monitors the blockchain and reports reverted batches to the batcher.

๐Ÿ‘ฉโ€๐Ÿ’ป
๐Ÿค”