Network Design
Last updated
Last updated
As described in the Mission, Sphinx is a modular protocol that consists of three node types that make up the composite architecture, in response to the design Challenges & Tradeoffs for building high-throughput exchange applications.
Our blockchain is a state machine made up of the following core modules:
Accounts - Each account on Sphinx has a unique public/private key pair, which can in turn generate multiple wallet addresses as well as additional sub-accounts on Coprocessor nodes.
Consensus - Sphinx is powered by a derivation of the CometBFT consensus engine, optimized by leveraging parallel transaction execution and an optimistic scheduler.
DA - The purpose of the DA layer is to ensure that block level data is probably published to Coprocessor nodes. This will sync the state of the chain and ensure deterministic storage between nodes.
Staking - Our network is secured via a delegated proof-of-stake mechanism. By engaging in staking, validators and delegators ensure Sphinx is secure, stable and performant.
SVM - The Sphinx Virtual Machine allows developers to write both EVM and CosmWasm style contracts, allowing for native interoperability
Governance - Participating stakers are allowed to vote on proposed changes to the network, with submissions put forth by the ecosystem.
Coprocessor's are secondary execution environments for developer use cases that require dedicated computing resources. These can be single computers, side chains, clusters or other networked topologies that suit upstream needs, so long as they obey specification and interface rules defined by the SVM when communicating with the main chain.
Sub-accounts - Dedicated coprocessor accounts seeded and managed by a parent account using the on-chain keypair. Parent accounts can allocate and deallocate fund to/from sub-accounts.
Sequencer - A verification, ordering and compression bus for transactions sent to the blockchain.
Order book - FIFO limit order book and matching engine.
In addition to the modules provided, users can write their own modules.
Relayer nodes act as gateways to the network, handling communications from a diverse set of application interfaces into unified communication scheme for the rest of the network to consume. This reduces I/O burden and optimizing intra-protocol traffic.
Interpreter - Defines RPC access protocols and endpoints.
Encoder - Encodes queued intra-chain communications.
Router - Routes encoded traffic to nodes based on RPC primitives.
