# 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