# Introduction ## Introduction to Modulus With Modulus, our vision is to build upon the most innovative blockchain tech, which is why we have opted to build Modulus as a zkEVM Layer 2. Our primary goal is to implement an opt in/out on chain privacy, opt in/out block explorer, custom bridge and a decentralised zkEVM. Building a Layer 2 on top of the Ethereum Mainnet foundation gives us the reliance of security and decentralisation, while improving on the scalability issue native to Ethereum L1. **Welcome to the Modulus Builders Portal.** Modulus is a decentralised Ethereum Layer 2 scalability solution that uses cryptographic zero-knowledge proofs to offer validity and quick finality to off-chain transaction computation, also known as a **ZK-Rollup**. The ZK-Rollup executes smart contracts transparently, by publishing zero-knowledge validity proofs, while maintaining opcode compatibility with the Ethereum Virtual Machine. These docs will represent a growing knowledge database on all things Modulus, and will be updated as we move further down our projected roadmap. ### Key links Modulus Eye Explorer: Bridge: Faucet: ### Scaling Ethereum with zkEVM[​](https://zkevm.polygon.technology/introduction/#scaling-ethereum-with-zkevm) Given that Ethereum is subject to[ the DLT (distributed ledger technology) trilemma](https://medium.com/certik/the-blockchain-trilemma-decentralized-scalable-and-secure-e9d8c41a87b3), it cannot scale beyond its transaction threshold without sacrificing decentralisation or security. This is where the zkEVM comes into play. Modulus is a zkEVM. It is designed and developed to emulate the Ethereum Virtual Machine (EVM) by recreating all existing EVM opcodes for transparent deployment of existing Ethereum smart contracts. This means Modulus is built to run on top of the Ethereum Mainnet, allowing increased throughput/scalability, and reduced fees when making transactions. As Modulus is based on the architecture developed with the Polygon zkEVM, instead of reinventing the wheel, we have cited some references on how zkEVMs work from the Polygon documentation below. *In order to prove that the off-chain computations are correct, Modulus zkEVM employs verifiable zero-knowledge proofs as validity proofs. Although the Layer 2 zero-knowledge proofs are based on complex polynomial computations to provide validation and finality to off-chain transactions, the validity proofs are quick and easy to verify.* *As a state machine, zkEVM carries out state changes, which come from executions of Ethereum’s Layer 2 transactions that users send to the network, and subsequently produces validity proofs attesting to the correctness of the state change computations carried out off-chain.* ### Why zkEVM[​](https://zkevm.polygon.technology/introduction/#benefits-of-polygon-zkevm)? There are 3 main benefits to using zkEVM architecture: **EVM equivalence.** As an EVM chain, the core language and contract structure used on all EVM chains is compatible with the zkEVM architecture. This means that any developer familiar with deployment on other EVM chains such as Polygon, Avalanche, or Ethereum itself will be able to use the same tools to develop and deploy on Modulus. **Ethereum security.** The zkEVM sits on top of Ethereum Mainnet, so the underlying security of the mainnet is assured and at the base of every part of the zkEVM. **Scalability.** Ethereum Mainnet is limited in that it is not currently scalable to the same degree as Layer 2’s. The ability to scale by compressing transaction data and taking computation off-chain means that throughput is much higher, processing more transactions per block. ZK also takes it further than Optimistic rollups, as they don’t need to post all the data to validate every transaction. If you wish to learn more about zero knowledge and its benefits to the Ethereum ecosystem, you can find expanded information on the Ethereum website here:
# Building on Modulus Modulus is **completely EVM-compatible**. Contracts built for other EVM chains will be able to be deployed without further development other than targeting the correct network on deployment. Simply switch to the Modulus Network in your wallet or deployment tool, and start building. ### Connecting to Modulus In order to add the **Modulus** network to your wallet, you will need to enter the following details : | Network | RPC URL | ChainID | Block Explorer URL | | --------------- | -------------------------- | ------- | -------------------------- | | Modulus Testnet | | `6666` | `https://eye.moduluszk.io` | **Additional Details**[**​**](https://zkevm.polygon.technology/develop/#additional-details) * **Currency Symbol**: CULT You can also add Modulus Testnet to your wallet automatically by clicking the Quick Connect button in the footer of the Modulus Eye explorer here: `https://eye.moduluszk.io` ### Faucet and test CULT tokens To receive some test CULT, RVLT, and TRG tokens, you can utilise our faucet service. The faucet service is limited to one distribution of 10 tokens per address each day.\ \ The faucet is available here: `https://faucet.moduluszk.io` To start using the Modulus Testnet, you can bridge your test CULT and ETH from the Bridge here: `https://bridge.moduluszk.io` Please note that the L1 testnet used to bridge to Modulus Testnet is Sepolia (NOT Goerli). You will need Sepolia ETH to be able to bridge. You can get that at ### Support[​](https://zkevm.polygon.technology/develop/#zkevm-support) If you need help with anything related to the Modulus zkEVM, you can raise a ticket on CultDAO Discord server (). You will find the **#modulus-support** channel on the left under the **Communication** category. [
](https://zkevm.polygon.technology/bridge-to-zkevm) # Bridge Assets to Modulus Below is a guide through the process of bridging from Sepolia to Modulus Testnet. If you have experience moving cross chain from Ethereum to Polygon or Arbitrum, or vice versa, this should be a very familiar process. ### Step-by-Step Guide[​](https://zkevm.polygon.technology/bridge-to-zkevm#step-by-step-guide) Firstly, you need to add Modulus Testnet to your wallet. You can either use the Quick Connect button at the bottom of the Modulus Eye Explorer to populate the information automatically, or manually add it to your wallet with the details below on the previous page. Enter the Modulus Bridge website from Modulus Landing/Eye or directly using the link: `https://bridge.moduluszk.io`
Click on the **Asset** to pick an asset that you would like to move from Sepolia to Modulus Testnet.
On the right hand side of the page, you can view the recent transactions, including transactions that are pending. After you proceed with transaction on the bridge, Metamask will ask you to confirm it.
Please allow a few moments for your transaction to be processed. Once completed, you can view all of your past and pending transactions by clicking on the "Transactions" button located in the top menu.
That's it. Your assets should be bridged now and you can use them on the Modulus Testnet. # Contracts Key contract addresses for use of the testnet. ### On Sepolia CULT - 0x48467B3F5AEd3bEB322D0D9fE1Bf3754d72BEc03 RVLT - 0x77FBEC542f27DfDD78Fb1e0917f9634DdD762b53 TRG - 0x8D13346dcBd90dB153a50977b17c45a75dd4B590 ### On Modulus CULT is like ETH, it has no contract address Wrapped CULT - to be deployed RVLT - 0xDD161001230a59F15F61b37EE997F77C15753E7c TRG - 0xe99dc079Ce831DEe0097877D6B21796434125a04 # 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. # Glossary #### Layer 1[​](https://zkevm.polygon.technology/glossary#layer-1) Layer 1 or the base blockchain is where the rollup smart contracts are installed. It's Ethereum or a testnet of Ethereum, but it could be any EVM-compatible blockchain. #### Layer 2[​](https://zkevm.polygon.technology/glossary#layer-2) Layer 2 refers to the rollup network; in our case, the Modulus network. #### Consensus Contract[​](https://zkevm.polygon.technology/glossary#consensus-contract-polygonzkevmsol) Consensus mechanism utilized by the zkEVM network. It is enforced by the smart contracts deployed on Layer 1 (in this case, Ethereum). #### Batch[​](https://zkevm.polygon.technology/glossary#batch) A group of transactions that are executed / proved, using the zkProver and sent to/synchronized from L1. #### Sequencer[​](https://zkevm.polygon.technology/glossary#sequencer) zkEVM participant who is responsible for selecting transactions, putting them in a specific order, and sending them to L1 in batches. #### Trusted Sequencer[​](https://zkevm.polygon.technology/glossary#trusted-sequencer) A sequencer with special privileges. There can be **only one** trusted sequencer. The privileges granted to the trusted sequencer allow it to forecast batches that will be applied to L1. In this way, it can commit to a specific sequence before interacting with L1. This is done in order to achieve **fast finality** and **reduce costs** associated with using the network (lower gas fees). #### Permissionless Sequencers[​](https://zkevm.polygon.technology/glossary#permissionless-sequencers) A sequencer role that can be performed by anyone on the network. Although it has competitive disadvantages compared to the trusted sequencer (like slow finality, or MEV attacks), its main purpose is to enforce **decentralisation** and **censorship resistance** to the network. #### Sequence[​](https://zkevm.polygon.technology/glossary#sequence) Group of **batches and other metadata** that the trusted sequencer sends to L1 in order to update the state. #### Forced Batch[​](https://zkevm.polygon.technology/glossary#forced-batch) A batch that is sent by permissionless sequencers to L1 in order to update the state. #### L2 Block[​](https://zkevm.polygon.technology/glossary#l2-block) Same as an L1 block, but for L2. It is mostly used by the JSON-RPC interface. Currently, all L2 Blocks are set to only include one transaction. This is done to achieve instant finality. Therefore, it's not necessary to close a batch to allow the JSON-RPC to expose results of already processed transactions. #### Trusted State[​](https://zkevm.polygon.technology/glossary#trusted-state) L2 state committed by the trusted sequencer. #### Virtual State[​](https://zkevm.polygon.technology/glossary#virtual-state) State reached after processing transactions that have already been submitted to L1. These transactions are sent in batches by either trusted or permissionless sequencers. Those batches are also called **virtual batches**. This state is trustless as it relies on L1 (here Ethereum) for security. #### Consolidated State[​](https://zkevm.polygon.technology/glossary#consolidated-state) State which is proven on-chain by submitting a **ZKP (Zero Knowledge Proof)** that proves the execution of a sequence of the last virtual batch. #### Invalid Transaction[​](https://zkevm.polygon.technology/glossary#invalid-transaction) A transaction that can't be processed and doesn't affect the network state. Such a transaction could be included in a virtual batch. The reason for a transaction to be invalid could be related to: * Ethereum protocol: invalid nonce, not enough balance, etc * limitations introduced by zkEVM: each batch can utilize a limited amount of resources such as the total amount of keccak hashes that can be computed. #### Reverted Transaction[​](https://zkevm.polygon.technology/glossary#reverted-transaction) A transaction that is executed, but is reverted (because of smart contract logic). The main difference between invalid and reverted transaction is that **reverted transaction modifies the state**, at least to increment the nonce of the sender.