🔬Architecture
Last updated
Last updated
The management of state modifications resulting from the execution of BNB Chain Layer 2 transactions transmitted by users to the network is the responsibility of zkSHIELD. The correctness of these off-chain state changes is subsequently verified using validation proofs that are generated using zero-knowledge characteristics.
The program required to run a zkSHIELD node is known as a Node. The network needs a client to carry out the synchronization and control the participants' (Sequencers or Aggregators') respective duties. Participants in zkSHIELD will select their mode of participation:
Knowing the status of the network as a node, or
As a participant in the batch production process in one of the two roles: Aggregator or Sequencer
The zero-knowledge Assembly (zkSHIELD Assembly) used to more abstractly define the processor's ROM is called. This ROM gives the Executor instructions on how to interpret various kinds of transactions that it could encounter. With this knowledge, the Executor can produce a set of polynomials that describe the state transition, which the STARK generator will use to produce evidence of the transition's accuracy.
We have started work on a virtual machine that mimics the operations of the Ethereum Virtual Machine (EVM) and runs according to zero-knowledge principles.
In zkSHIELD, the Prover, a zero-knowledge prover component, handles both transaction proof and verification. The Prover implements and upholds each requirement for a transaction to be legitimate.
The Prover does intricate mathematical operations using polynomials and assembly language, and then a smart contract verifies the results.
The Node and the Database (DB) are the two components with which the Prover primarily communicates. We must thus comprehend the control flow between the Prover, the Node, and the Database before delving further into other components. For a clearer explanation of the procedure, see this diagram.
