Comment on page
Architecture
ZK Chain handles state transitions caused by Binance Chain Layer 2 transaction executions (transactions that users send to the network). Following that, it creates validity proofs that attest to the accuracy of these off-chain state change calculations by utilising zero-knowledge features.
The major components of ZK Chain are:
- Consensus Contract (ZKChain.sol)
- zkNode
o Synchronizer
o Sequencers & Aggregators
o RPC
- zkProver
- ZK Chain Bridge
The skeletal architecture of ZK Chain is shown below:
.png?alt=media&token=dce97719-c864-471a-a55b-8e4aa64d36d3)
A Full ZK-Rollup schema requires the publication of both the data (which users need to reconstruct the full state) and the validity proofs (zero-knowledge proofs) on-chain. However, given the Binance Chain configuration, publishing data on-chain incurs gas prices, which is an issue with Layer 1. This makes deciding between a Full ZK-Rollup configuration and a Hybrid configuration challenging.
Under a Hybrid schema, either of the following is possible:
- Validium: Data is stored off-chain and only the validity proofs are published on-chain.
- Volition: For some transactions, both the data and the validity proofs remain on-chain while for the remaining ones, only proofs go on-chain.
Unless, among other things, the proving module can be highly accelerated to mitigate costs for the validators, a Hybrid schema remains viable.
ZKChain.sol
The underlying protocol in ZK Chain ensures that the state transitions are correct by employing a validity proof. To ensure that a set of pre-determined rules have been followed for allowing state transitions, the Consensus Contract (ZKChain.sol, deployed on L1) is utilized.
A smart contract verifies the validity proofs to ensure that each transition is completed correctly. This is accomplished by employing zk-SNARK circuits. A system of this type requires two processes: transaction batching and transaction validation.
To carry out these procedures, ZK Chain employs two sorts of participants: Sequencers and Aggregators. Under this two-layer model:
- Sequencers→ propose transaction batches to the network, i.e. they roll-up the transaction requests in batches and add them to the Consensus Contract.
- Aggregators→ check the validity of the transaction batches and provide validity proofs. Any permissionless Aggregator can submit the proof to demonstrate the correctness of the state transition computation.
The Smart Contract, therefore, makes two calls: One to receive batches from Sequencers, and another to Aggregators, requesting batches to be validated.
.png?alt=media&token=5e267e4c-9d28-43d1-b0ad-7d4fabb589e9)
Last modified 7mo ago