Architecture
As a zkEVM Layer 2 blockchain, the Modulus Network consists of 4 main components.
Consensus Contract
Modulus uses the Polygon zkEVM technology as a foundation. The first implementation of this technology was Polygon Hermez 1.0, which was based on the Proof of Donation (PoD) consensus mechanism.
The next iteration was to add support of permissionless participation of multiple coordinators to produce batches in L2.
The current, and latest version of the zkEVM Consensus Contract uses Proof of Efficiency (PoE). Proof of Efficiency works so that the batches proposed by the Sequencers in L1 are sorted by their appearing position in the L1, and contain the transaction data. The PoE smart contract will accept as valid the first validity proof that updates to a new valid state including one or more of the proposed batches.
zkNode
zkNode is the software needed to run any zkEVM node. It is a client that the network requires to implement the Synchronization and govern the roles of the participants (Sequencers or Aggregators). You can either run a Node passively, so you can read the state of the network at any time, or through participation as a Sequencer or Aggregator.
Incentivisation Model
The two permissionless participants of the zkEVM network are: Sequencers and Aggregators. Proper incentive structures have been devised to keep the zkEVM network fast and secure. Below is a summary of the fee structure for Sequencers and Aggregators:
Sequencer
Collect transactions and publish them in a batch
Receive fees from the published transactions
Pay L1 transaction fees + CULT
CULT goes to Aggregators
Profitable if:
txs fees
>L1 call
+CULT
fee
Aggregator
Process transactions published by Sequencers
Build zkProof
Receive CULT from Sequencer
Static Cost: L1 call cost + Server cost (to build a proof)
Profitable if:
CULT fee
>L1 call
+Server cost
zkProver
zkEVM employs advanced zero-knowledge technology to create validity proofs. It uses a zero-knowledge prover (zkProver), which is intended to run on any server and is being engineered to be compatible with most consumer hardware. Every Aggregator will use this zkProver to validate batches and provide Validity Proofs.
It consists of a Main State Machine Executor, a collection of secondary State Machines (each with its own executor), a STARK-proof builder, and a SNARK-proof builder.
In a nutshell, the zkEVM expresses state changes in a polynomial form. As a result, the constraints that each proposed batch must meet are polynomial constraints or polynomial identities. To put it another way, all valid batches must satisfy specific polynomial constraints.
Bridge
The Bridge contract is the link between Layer 1 and Layer 2, and it is deployed on both networks, with an identical contract. It provides a permissionless method for users to move their assets between L1 Mainnet and Modulus. You can read more about the Bridge in our guide on the previous pages.
Last updated