High Level Architecture of ZX
Last updated
.svg?alt=media&token=4b04c4f7-d389-429d-bab4-71df79bed629)
Last updated
Note: We are currently in the development phase, and details may be subject to change.
ZX will have a trustless bridge component for user deposits.
Here is the process users will follow to deposit funds and trade on the ZX platform:
A user will be required to deposit collateral (i.e USDC) to the Solana Smart Contract that holds custody of funds.
Full nodes listening to Solana Block Headers will parse the transaction and generate a proof of deposit.
This proof will be submitted to the sequencer which will credit the user’s balance on the ZX rollup. This is treated as a regular rollup transaction, with the proof included in the call data. Once this is done, users will be free to make trades on ZX across all our products.
The sequencer will include the transaction in a future block when published to the DA smart contract.
When interacting with ZX such as when placing an order, users will sign a transaction with their wallet to generate a session key, to allow fluid and seamless one-click trading.
These transactions are sent to the sequencer. Here, transactions are ordered and processed through the state transition function (STF), otherwise known as the matching engine logic for user state updates. Users will receive a soft-commitment transaction receipt within milliseconds, informing them the result of their transaction.
Once transactions are ordered and executed, the sequencer produces and publishes ZX blobs onto the Solana DA Smart Contract.
Data availability fundamentally ensures that when a new block is produced, all relevant transactions within that block are published and accessible to full nodes. The ZX sequencer, which is tasked with ordering and producing blocks, will post all ZX blocks onto Solana.
We use a Solana smart contract as the core of our DA implementation which stores the rollup data in the form of data blobs which is just a batch of rollup transactions represented as a sequence of bytes.
These blobs will contain all the transactions that occurred on ZX. These bytes can be broken down into chunks and sent to a Solana smart contract.
This is an example of what a chunk could look like:
Each Solana transaction is limited to 1232 bytes, and each ZX transaction will be around 120 bytes, meaning we can fit approximately 10 ZX transactions into each Solana transaction. ZX will scale proportionally with the throughput of Solana.
The Solana program will have accounts that act as memory to store ZX blobs for full nodes to access. The DA smart contract will store these chunks for a blob in the form of a merkle tree as they arrive.
Chunks can arrive in any order as they will be inserted correctly in the on-chain space. Chunk hashes will bubble up towards the root as they arrive, allowing each transaction to perform a fraction of the compute in calculating the final merkle root for a blob.
The Solana program will track the accumulated root of all completed data blobs it has received over its lifetime; checking this will validate the inclusion of ZX blocks when calculating state attestations.
Since the $SOL paid for rent exemption for these memory accounts can be reclaimed, this cost remains constant for ZX.
Once the blocks become available from the DA component, a settlement process is initiated where full nodes execute each of these transactions to compute the latest state root. ZX leverages Solana as the settlement layer as well. Solana smart contracts will handle the finalisation of the ZX rollup state as well as the fault proving mechanisms.
The ZX settlement process is an optimistic rollup that leverages ZX fraud proofs for verification.
All full nodes will share the same state transition function (zkVM compatible exchange matching engine logic) and execute the ZX blocks as they become available on the DA component. The state machine is deterministic and state commitments should be identical across full nodes. The Sovereign SDK has made this process efficient by nearly optimal state merkelization. [3]
State commitments are built upon the old state commitment and new produced blocks.
Full nodes can then lock up capital to submit a state commitment to the settlement contract for a given block.
Alternatively, if a full node detects a disparity between submitted commitments and its internal state, they can opt to submit a fraud proof by running a prover node (a full node running inside of a zkVM) and generating a cryptographic receipt. Prover nodes perform the same process as full nodes, scanning through the DA block and processing batches in order.
Prover nodes are also required to lock up capital to challenge the fraudulent state commitment. This is verified by the settlement smart contract on-chain. If successful, the malicious full node has their capital slashed and all their state commitments discarded.
This process is trustless and permissionless; anyone can participate to secure the network.
The state commitment becomes finalised after a challenge period which is customisable and ultimately a trade off between UX and security. [4]
In the case of withdrawals, a user withdrawal transaction will be included in a block and will need to be finalised before they can withdraw from the L1 smart contract. To improve UX for the end user, external third parties running a full node can execute the transaction and verify whether a withdrawal will succeed or not and provide instant liquidity for users for a fee. [5]
