The major components of X1 are:
X1 is built with Polygon CDK, an advanced open-source framework designed for the rapid deployment of zk-powered layer 2 (L2) blockchains on Ethereum.
X1 adopts the validium mode, and implements a dedicated committee of sequencers, to maintain seamless interoperability with all other Polygon chains, delivering a high performance L2 scaling solution.
Since transaction data is not stored on the Ethereum mainnet, it is both executed and stored off-chain, which can lead to a massive enhancement in scalability. In the premise of ensuring security, Validium can reduce L1 gas storage costs, hence reducing transaction costs for users on L2, with a prominent enhancement in user privacy and user experience.
Similar to zero-knowledge rollups (ZK-rollups), X1 confirms off-chain transactions on the Ethereum network. This approach prevents incorrect state changes and boosts the security of the X1 network.
zkValidiums differ from rollups and sidechains because they only share the proof of validity, which confirms the results of the transactions with Ethereum, not the actual transaction data of the executed transactions. Here is how it operates: a verifier smart contract is deployed on Ethereum, and validium submits proof of validity to this contract. These proofs are zero knowledge in nature and contain transaction outcomes but not the specific transaction data.
The verifier smart contract assesses the validity of the proof. If it is found to be invalid, any batch submitted by the validium is rejected and not stored on Ethereum.
ZkEVM.sol is the underlying protocol that guarantees the correctness of state changes through the use of validity proof. To confirm that specific predefined rules have been adhered to for permitting state transitions, the Consensus contract (
ZkEVM.sol, deployed on Ethereum layer 1) comes into play.
ZkEVM.sol is responsible for verifying validity proofs to confirm that each transition has been executed correctly, utilizing zk-SNARK circuits for verification. To make this system work, two key processes are involved: transaction batching and transaction validation.
To perform these procedures, X1 involves two types of participants: sequencers and aggregators.
Sequencer: it is responsible for proposing transaction batches to the network, essentially grouping transaction requests and adding them to the
Aggregator: it is responsible for reviewing the transaction batches' validity and providing the necessary proofs of validity. Any permissionless aggregator can submit these proofs to demonstrate the accuracy of the state transition computation.
X1 operates in validium mode, where it integrates a secure data availability layer managed by a DAC. Below are the functionalities of DAC:
The DAC primarily provides:
zkNode is a client used to sync with the state of X1. Trusted sequencer and trusted aggregator are responsible for managing the L2 state and its finality on L1. The following zkNode architecture shows the flow of state updates.
As an Ethereum scaling solution, X1 simulates the Ethereum Virtual Machine to provide users with the same Ethereum experience while inheriting the security of the Ethereum mainnet.
X1 employs a zero-knowledge prover component called zkProver to generate validity proofs for zkRollup. The zkProver is expected to leverage accelerators such as GPU, FPGA, and ASIC to reduce proof time and cost significantly.
The general operational process is as follows: zkProver receives a batch of many transactions from nodes and generates a concise zero-knowledge proof using state-of-the-art zk tools and technology. This not only substantially reduces the time for final transaction confirmation but also significantly lowers users' Gas consumption costs. The specific interaction flow can be referred to in the following diagram:
There are two main actors on X1 that earn OKB as reward and pay OKB token as Gas fee for transactions at the same time.
Before making any transactions on L2, users need to have some OKB token on X1 to perform any L2 transaction. To get OKB on L2, users need to transfer some OKB from L1 to L2 through X1 bridge.
To get a sense of the complete transaction life cycle on X1, we recommend you to take a look at the Transactions and data flow document.