SL Network Architecture

Overview

Each SL node is connected to:

  1. MTX endpoint server (centralized service)
    1. for fetching UserMTX
    2. alternatively, SL node can expose its API endpoint to receive UserMTX directly
  2. a list of solvers
    1. for sharing UserMTX and receiving SolverMTX
  3. other SL nodes
    1. for establishing consensus on the state of the SL-Chain
    2. for broadcasting UserMTX and SolverMTX bundle with other SL nodes

Each SL node runs two clients:

  1. SL-Chain client (built based on Geth)
    1. for establishing the consensus on the state of the SL-Chain
  2. SL-node client (built using libp2p in Golang with TCP as the transport protocol)
    1. for retrieving UserMTX from the centralized MTX endpoint server
    2. for sharing UserMTX and receiving SolverMTX from solvers
    3. for broadcasting UserMTX and SolverMTX bundle with other SL nodes
Semantic Layer Network Architecture Semantic Layer Network Architecture

Benefits of separated clients

SL-Chain client is built based on Geth with the addition of Semantic Layer stateful precompiles SL-EVM, and the SL-Chain client handles tasks where a global consensus is required, such as selecting and executing the globally most optimal MTX bundle. Tasks where a global consensus is not required, such as selecting the locally most optimal MTX bundle, is handled by SL-node client. Separating the consensus-dependent tasks from consensus-independent tasks provides following benefits:

  1. Reduced Communication Delay: SL nodes are geographically distributed and each has a local view of connected solver and SolverMTXs. Directly connecting SL nodes to solvers with the SL-node client reduces communication delays, allowing solvers to quickly receive information and submit their SolverMTXs.
  2. Load Balancing: Each SL node connects to a limited set of solvers. The SL-node P2P network acts as a load balancer to distribute computes efficiently and prevent overloading any single node.
  3. Reduce Execution Load on SL-Chain: SL nodes perform simulations and preprocessing to reduce the load on SL-Chain. SL-node client will execute VSR locally on all SolverMTXs submitted to the node, and only locally most optimal SolverMTX will be submitted to SL-Chain.

Note that Verifiable Sequencing Rules and Verifiable Aggregation Rules are deployed to SL-Chain, and the correct execution of the VSR and VAR are cryptographically secured by SL-Chain. SL-Chain is initially secured by Proof of Authority (PoA) consensus mechanism and will later transition to Proof of Stake (PoS) consensus mechanism.

Network Configuration

Node Functionality

Each SL node is connected to multiple types of entities. SL-Chain client and SL-node client executes the following tasks:

  • UserMTX Retrieval (SL-node client)
    • SL node will retrieve UserMTX from a centralized MTX endpoint server, which exposes an API-endpoint for users to submit signed UserMTX from the front-end
    • Note that a centralized MTX endpoint server is not required for Semantic Layer network. SL node can also expose an API-endpoint for users to submit signed UserMTX from the front-end directly to the SL node
  • Provide UserMTX to solvers (SL-node client)
    • Solvers can retrieve UserMTX from connected SL nodes
  • Retrieve SolverMTX from solver (SL-node client)
    • Solvers submit SolverMTX to connected SL nodes
    • Note that each solver might be connected and submitting SolverMTX to multiple SL nodes to mitigate potential packet loss
  • Construct local best MTX bundle (SL-node client)
    • SL-node client will execute received SolverMTX with the VSR specified for the UserMTX
    • A VSR score is generated for each SolverMTX
    • The SolverMTX with the highest VSR score is regarded as the locally observed most optimal SolverMTX. This SolverMTX is combined with the UserMTX to construct a MTX bundle
  • Broadcast UserMTX and SolverMTX bundle (SL-node client)
    • This MTX bundle is broadcasted to other SL nodes
  • Reach a consensus on SL-Chain state (SL-Chain client)
    • Pack MTX bundles into SL-Chain block
      • SL-Chain block proposer adds the MTX bundles to a SL-Chain block
    • Select a MTX executor for the bundle
      • A SL-node is selected as the MTX executor
    • Execute Verifiable Sequencing Rule to select the globally most-optimal MTX bundle
      • SL-EVM executes the VSR to find globally most-optimal MTX bundle
    • Execute Verifiable Aggregation Rule to aggregate MTX bundles
      • SL-EVM executes the VAR to aggregate MTX bundles
  • Serialize and execute MTX bundle on the destination execution environment (SL-node client)
    • MTX executor (a SL node) serializes the MTX bundle and submits to the block builder or sequencer of the destination execution environment

Transport Protocols

TCP is used as the transport protocol for communication between nodes. UDP is solely used for peer discovery for its simplicity.

Peer Discovery Mechanism

The SL node network leverages a hybrid bootstrap node and DHT-based peer discovery mechanism for optimized connectivity and resilience. Bootstrap nodes serve as initial entry points, allowing SL nodes to quickly discover active peers when joining the network. Once connected, each node utilizes the DHT to dynamically expand and maintain its peer connections across the network, ensuring decentralized discovery.

By combining the stability of bootstrap nodes with the adaptability of the DHT, this approach minimizes reliance on any single entry point, enabling seamless peer discovery even if multiple bootstrap nodes go offline. This robust setup enhances both connectivity and network resilience.

Communication and Encryption

  • Data Encryption: UserMTX and SolverMTX will be encrypted using ECIES (Elliptic Curve Integrated Encryption Scheme) with asymmetric encryption using public and private key pairs
  • Secure and Encrypted Communication Channel: The client uses libp2p-noise protocol with the XX handshake pattern for secure and encrypted communication channels. The XX handshake pattern provides mutual authentication between nodes, ensuring a secure channel before any data exchange occurs.