Ethereum’s journey began with Bitcoin's introduction as a 'peer-to-peer electronic cash system,' but it truly took shape when Vitalik Buterin envisioned Ethereum as a platform for developing decentralized applications, allowing anyone to create custom smart contracts, define rules for ownership, and establish unique transaction formats, leading to ecosystem of applications built on Ethereum. However, as we embraced blockchain for quick transaction settlements and on-chain asset management, the most critical challenge became clear: scaling Ethereum. This challenge is encapsulated in the Blockchain Trilemma, a concept coined by Vitalik, which highlights the delicate balance between decentralization, security, and scalability—three pillars that are essential yet often difficult to optimize simultaneously.

Blockchain infrastructure is the base of all the dApps that are being built in space and even for future consumer adoption when there would be multiple users on specific applications. We can’t fully blame Ethereum for high gas fees and delay in time-to-finality when the blockchain is congested. Rollups are the ideal solution for builders and users as it allows to take the computations off-chain and only post the calldata to Ethereum which basically allows you to scale and secure at the same time. Now, there are multiple different types of Rollups or L2s that exist in space but most of them are not ‘truly decentralized’.

In this blog, we will be introducing Morph - the L2 consumer blockchain which is solving the blockchain trilemma and bringing the architecture for dApps which will allow builders to develop true real-world applications - highly scalable, secure and decentralized by its technical ethos.

What is Morph ?

Morph is a Layer 2 rollup solution built on Ethereum that combines the strengths of both optimistic rollups and zero-knowledge (zk) technology. The vision behind Morph is to create a blockchain ecosystem that prioritizes consumer-centric applications, ensuring a seamless and user-friendly experience. To achieve this, Morph adopts a decentralized architecture that includes decentralized sequencers, which enhance security and reduce reliance on a single point of failure. Additionally, it utilizes Optimistic zkEVM Rollups to provide scalability and faster transaction finality, while the modular infrastructure allows for flexibility and adaptability of different layers.

Let’s break down how decentralized sequencers, hybrid zk optimistic rollup models with modular architecture work together to make Morph a blockchain focused on consumer-centric adoption.

Modular Architecture of Morph L2

To grasp how Morph’s modular architecture works, let's compare it with traditional monolithic blockchains like Ethereum and Bitcoin. In these blockchains, each node handles everything: execution, settlement, consensus, and data availability, all within a tightly integrated system. While this approach is secure, it limits scalability.

For a brief knowledge, let's see how execution, settlement, consensus and DA work together.

1. Execution: In this process blockchain nodes process transactions for state transitions. Consider that you execute smart contracts, sign transactions and message and transfer assets.

2. Consensus: During consensus, you are supposed to come to a shared agreement for the transactions and state transitions.

3. Settlement: During settlement of transactions, you are making sure that all transactions go to an immutable statement, which can’t be reverted and achieves “actual finality”.

4. Data Availability: The transaction data should be available on the blockchain in case anyone wants to access, block producers publish the transaction data and store it on-chain.

Morph, on the other hand, breaks down these responsibilities across different layers with a modular approach:

1. Decentralized Sequencers: These handle both execution and consensus, ensuring that transactions are processed and validated without relying on a single point of control.

2. Hybrid Optimistic zkEVM: This serves as the settlement layer, combining the efficiency of optimistic rollups with the security of zero-knowledge proofs for state verification using RVP (Responsive Validity Proof)

3. Rollup Contracts: These contracts serve as data availability by submitting Layer 2 transactions and states to Layer 1 Ethereum. By utilizing zk-proofs to compress block content, they ensure that data is managed efficiently and securely.

Since proto-danksharing was introduced to Ethereum, posting calldata of rollups have become even more efficient. You can read more about EIP 4884 here.

Decentralized sequencers - true decentralization for rollup technology

Sequencers, as the term suggests, are responsible for ordering and processing transactions for Layer 2 before they are submitted to layer 1.

• Transaction Ordering: The sequencer determines the order in which transactions are included in a block. This ensures that all participants in the network agree on the sequence of transactions, which is crucial for maintaining consistency and avoiding double-spending.

• Block Creation: After ordering the transactions, the sequencer groups them into a block. This block is then processed and prepared for submission to the Layer 1 blockchain.

• Execution: The sequencer may also execute the transactions within the block, updating the Layer 2 state accordingly. This involves applying the transaction's effects to the Layer 2 ledger, such as updating balances or contract states.

• Submission to Layer 1: Once a block is finalized, the sequencer submits it to the Layer 1 blockchain. This may also include posting a compressed version of the transactions or a cryptographic proof (such as a zk-proof or validity proof) to Layer 1.

• Optimizing Throughput: By processing and ordering transactions off-chain, sequencers help reduce the load on the Layer 1 blockchain, thereby increasing the overall throughput and scalability of the network.

Currently, most rollups use centralized sequencers, which handle the ordering and processing of transactions. However, this centralization creates a single point of control, making the system vulnerable to censorship, transaction manipulation, and reduced network resilience, which undermines the core principles of decentralization. Also, in a centralized system, the sequencer has significant power to prioritize certain transactions over others based on potential profit, leading to unfair advantages and higher fees for users. We are talking about Miner Extractable Value (MEV) here. This not only increases the risk of censorship and manipulation but also introduces economic inefficiencies, as the sequencer might prioritize their own gains over the network's health. Consequently, the centralization of sequencers raises concerns about trust, transparency, and the long-term security of rollup solutions.

Morph heavily utilizes a decentralized sequencer network as part of execution and consensus both. To understand the flow of how a decentralized sequencer works, let's take a look at a quick flow.

Collecting Transactions:

• As a sequencer, your first task is to gather transactions that users submit. These transactions are placed in the TX Pool of the L2 Node you operate. The TX Pool acts as a holding area where all incoming transactions are queued for processing.

Proposing a Block:

• Once a sufficient number of transactions are collected, or when it’s time to propose a new block, you (as the sequencer) create a block. This block is a collection of transactions that you’ve ordered according to the protocol’s rules.

• Your L2 Geth instance helps in forming this block, including all the transactions you’ve selected.

Submitting the Block for Consensus:

• After creating the block, you propose it to the other sequencers in the Sequencer Set. This set consists of multiple sequencers (like yourself), each running a Consensus Tendermint Client.

• Your proposed block is now up for consensus. The Tendermint Clients within your sequencer and others communicate to agree on whether this block should be finalized.

Reaching Consensus:

• Your sequencer (along with the others in the set) goes through a consensus process. You exchange messages with other sequencers, and if a majority agrees, the block is committed.

• This step ensures that no single sequencer can unilaterally decide the order of transactions, reducing the potential for MEV (Maximal Extractable Value) exploitation.

Finalizing the Block:

• Once consensus is reached among the sequencers, the block is considered finalized. It’s now marked as Block (Consensus), meaning it has been agreed upon by the majority.

• You then sync this finalized block with other nodes, ensuring that the entire network is aware of the new state.

Batching and Signature:

• As part of ongoing operations, your sequencer checks whether a predefined Batch Point has been reached. The Batch Point is a threshold that determines when it’s time to bundle up the transactions and finalize them at a higher level.

• If the Batch Point is reached, you forward the block to the Staking Contract to add a BLS signature. This signature provides cryptographic security to the batch, ensuring its integrity when interacting with the L1 Rollup Contract.

Interaction with L1 Rollup Contract:

• After the block is finalized and signed, it’s sent to the Rollup Contract on Layer 1 (L1). This contract keeps the Layer 2 rollup state synchronized with the main Ethereum chain (L1).

Fraud Proofs are not enough for L2s

Layer 2 state verification generally falls into two categories: fraud proofs and validity proofs. Fraud proofs assume transactions are valid unless contested, allowing users to challenge any suspicious activity.Validity proofs require cryptographic verification for each transaction before finalization, ensuring accuracy upfront. While validity proofs form the basis of zk-Rollups, fraud proofs are used in Optimistic Rollups.

Fraud proofs in optimistic rollups introduce several challenges due to their inherent interactivity, which requires ongoing communication between multiple parties to verify state transitions. This interactivity increases complexity, latency, and costs, making the system more cumbersome and less efficient. While fraud proofs are designed to conserve computational resources by only verifying incorrect state transitions, they still incur overhead from these necessary interactions, which can reduce scalability, especially in environments where scalability is already a constraint. Fraud proofs pose significant security risks, as they allow invalid blocks to be temporarily accepted. In the event of a 51% attack on the Layer 1 (L1) chain, attackers could exploit the Optimistic Rollup (OR) mechanism to introduce fraudulent blocks and secure their confirmation within the dispute period. The interactive nature of fraud proofs also expands the attack surface, giving malicious actors more opportunities to exploit communication channels and manipulate the system. Additionally, despite their resource-saving design, fraud proofs demand significant computational power and bandwidth for the interactions involved, posing challenges in resource-constrained environments.

Non-Interactive Fraud Proofs simplify the process by having Layer 1 (L1) re-execute all relevant Layer 2 (L2) transactions during a challenge, but this approach leads to high gas costs and potential discrepancies between L1 and L2. While this method avoids complex interactions, it is resource-intensive and can result in incorrect state validations. On the other hand, Interactive Fraud Proofs aim to reduce computational costs by involving multiple rounds of interaction between the sequencer and the challenger to identify and resolve disputes. However, this added complexity lengthens challenge periods.

Bringing zkProofs to optimistic rollups with Responsive Validity Proof (RVP)

The Responsive Validity Proof (RVP) mechanism builds upon traditional validity proofs, particularly those used in zero-knowledge rollups (zk-Rollups), to enhance the process of ensuring the validity of summarized data on the Layer 1 (L1) chain.

• Efficiency: RVP minimizes the need for Layer 2 (L2) to include most transaction data, making the system more accessible and manageable for challengers. This reduces the burden on L2, allowing for a more streamlined and scalable solution.

• Challenger’s Role: In RVP, the challenger's role is simplified to initiating a challenge through staking. The challenger doesn't need to generate or verify proofs, which reduces the complexity and technical requirements for participating in the validation process. I

• Sequencer’s Responsibility: The sequencer, on the other hand, is tasked with generating and verifying proofs that demonstrate the validity of the challenged data.

• Logic-Based Validity: RVP operates on the principle of logical validity. This means that the sequencer’s proof ensures the validity of the challenged data based on the conclusion that the data cannot be false if the premises are true.

• Contrast with Traditional Fraud Proofs: Traditional fraud proofs in optimistic rollups assume that most summarized L2 transactions are valid and allow for a fraud proof to be submitted within a specified timeframe (typically 7 days) to challenge and potentially reverse a false transaction. In contrast, RVP is designed to be more responsive and efficient, reducing the challenge period to 1-3 days.

How does RVP work ?

1. zkProof Generation: The sequencer generates a validity proof (zkProof) for the state update on Layer 2.

2. Submission to State Verification Contract: The proof is submitted to the state verification contract on Layer 1.

3. Initial Challenge: A challenge can still be initiated, but it primarily involves validators staking to question the validity.

4. Verification: The state verification contract checks the zkProof provided by the sequencer to validate the state update.

5. Validators: Validators play a less active role, primarily staking to initiate challenges.

You can check out the Morph docs to understand more about RVP and the challenge period compared with Fraud proofs.

Morph will bring crypto consumerism on blockchain level

Morph’s vision is aligned to bring dApps which are real world and use-case based. The modular architecture along with Responsive validity proofs enables the L2 solution to become a consumer centric chain. By utilizing ZK-proofs, Morph compresses transaction data, which minimizes the volume of information that needs to be submitted to Layer 1. This approach lowers costs and benefits users with reduced fees. RVP streamlines data submission by avoiding detailed transaction replays required by traditional rollups, leading to further cost savings and faster transactions. The selective generation of ZK-proofs only when necessary ensures that Morph remains cost-effective, providing a more affordable and efficient blockchain experience for consumers. Morph testnet is already live, if you are a developer who is planning to build out dApp, you can follow this piece of documentation to learn how to build on Morph.

Morph’s ecosystem is constantly growing. Apart from the technical stack, Morph also has a community focused approach to what they are building. They are extremely transparent with the community, creating multiple programs to bring the consumer blockchain to masses. To check out the apps and different programs that are currently being supported within the Morph community, you can check these out.

• https://www.morphl2.io/apps

• https://www.morphl2.io/ambassadors

• https://www.morphl2.io/programs/

• https://www.morphl2.io/about

  If you are a developer, do check out the example repositories :

  https://github.com/morph-l2/morph-examples

• https://github.com/morph-l2/morph_starter_kit

• https://github.com/morph-l2/awesome-morph?tab=readme-ov-file

Thanks for reading !