.Research and deep dive into .
@movementlabsxyz
The new Paradigm of Scaling solution Powered by Bringing Move to the Ethereum Ecosystem with Move-based Zk-rollup
Appreciate to MovementLabs team :
.
@andygmove
.@Move__jay
.
@franciskthomas
.
@bhenhsi
.
@sh1sh1nk
.
@mer_q_tio
.
@0xPrimata
.
@livingwithwill
.
@torabyou
.
@coopsmoves
.
@rushimanche
________________________________________
#Introduction
Move has been adopted as the primary language for highly efficient blockchains like Sui, Aptos, and the 0L network. Developed by the Diem project (formerly known as Facebook’s blockchain), Move is a smart contract programming language designed to ensure safety and flexibility. It is a strongly typed, resource-oriented language that guarantees resources can only be “moved” and not copied or removed. This approach addresses security issues found in Solidity, such as reentrancy attacks. However, Move-based blockchains face challenges in growth due to their lack of liquidity, developers, and users compared to the vast Ethereum ecosystem.
Movement Labs aims to bridge this gap by facilitating the seamless integration of Move-based blockchains with the broader blockchain landscape and introducing Move execution to other ecosystems. The product that Movement Labs is currently building is a Move-based Zk-rollup. This solution leverages its flagship products, M1 and M2, where M1 serves as a shared sequencer layer, and M2 functions as the rollup. M2 not only supports smart contracts written in Move, it also contains Fractal, an EVM bytecode interpreter. This feature enables Solidity developers to deploy their Solidity smart contracts, thus opening doors for broader developer engagement.
In this article, we will begin with an overview of the basic design principles of modular blockchains. Armed with this understanding, we will explore the architecture of Movement’s Zk-rollup in detail.
_________________________________________
#Key takeaways :
1️⃣From Monolithic to Modular Design
2️⃣General Architecture of Zk-Rollups
3️⃣M2 - The Move-based Zk-rollup from Movement Labs
4️⃣M1 - Decentralized Sequencers
5️⃣Movement SDK
6️⃣Prover Marketplace
7️⃣Separate Data Availability Layer
8️⃣Putting It All Together
9️⃣Summary
🔟Ecosystem of Movement Labs
_________________________________________
1️⃣From Monolithic to Modular Design
So, why rollups? Ethereum is recognized as one of the most decentralized blockchains, especially when compared to other Layer 1 (L1) blockchains, which may only contain tens to hundreds of validators. However, this very decentralization complicates Ethereum's scalability. Increasing throughput could diminish the ability of individuals to run their own nodes, potentially reducing the network's decentralization.
The core issue lies in the responsibilities shouldered by Ethereum's nodes. They are tasked with managing all the functions a Layer 1 blockchain must perform:
1. Execution - Executing and verifying the correctness of every transaction on Ethereum.
2. Data Availability - Ensuring that data or the history of the blockchain is accessible for anyone wishing to verify the chain's history.
3. Consensus - Achieving agreement among validators in the network on the transaction order.
And this is why Ethereum is called a monolithic blockchain.
In response, alternative solutions like rollups have been proposed. These are designed to offload the execution workload off-chain, subsequently submitting proof of correctness back to the base chain. Moreover, new projects like Celestia and Avail are developing a Layer 1 design focused on data availability. This approach enables rollups to submit and record data more cost-effectively than direct submissions on Layer 1. Such strategies introduce modular blockchain design, decoupling the core functions of monolithic blockchains into separate, specialized layers. This modularization allows each layer to operate in parallel, optimizing their specific functions without burdening a single base chain as seen in monolithic designs.
2️⃣General Architecture of Zk-Rollups
The essence of rollups is to alleviate the execution burden from Layer 1 by handling these tasks off-chain. However, this process isn't as straightforward as directly offloading tasks. Instead, rollups must produce proofs that verify the accuracy of off-chain computations. These proofs are then published on their underlying Layer 1 blockchains, which act as the foundational layer of security and decentralization for the rollups. Additionally, the rollup data must be made available on Layer 1 so that, should the rollup operators go offline, a new set of honest operators can step in to replace them and keep the rollup operational.
Once the proofs are submitted, they are handled based on their type of rollups:
1.For Zk-rollups: Validators on Layer 1 can use the proofs to verify that executions and state transitions have been correctly performed. The verification process is much more efficient than re-executing all transactions on the rollups, thanks to zero-knowledge technology.
2.For Optimistic rollups: Validators do not need to verify the proofs directly. Instead, there is a challenge time window during which honest actors can submit fraud proofs if they detect malicious behavior in the rollups.
From this point onward, we will focus mainly on the design of Zk-rollups. In the modular design, Layer 1 takes on an additional task as a settlement layer for rollups. Simply put, it verifies proofs and ensures correctness for rollups. This means that Layer 1 offloads execution to rollups in exchange for taking on verification tasks. Fortunately, proof verifications are more efficient than executing transactions. The simple architecture of the rollup design is illustrated in the following figure.
Let’s delve further into how Zk-rollups generally operate. Since a rollup is an off-chain component that runs parallel to and executes incoming transactions independently from Layer 1, it requires an operator responsible for rollup maintenance, known as a sequencer. Sequencers facilitate interactions between independent components in the rollup stack. They keep the base Layer 1 in sync with its rollups by publishing rollup data on Layer 1 and collaborating with third parties like provers to generate validity proofs, so Layer 1 can verify that rollups are operating correctly.
Here is a general flow of a zk-rollup’s transaction lifecycle:
1. A rollup user initiates a transaction by signing and submitting it to a rollup sequencer. The sequencer may execute and respond back to the user with their expected state transition, but it is not yet finalized.
2.Periodically, the sequencer aggregates transactions and sequences them to create a batch of transactions.
3. To commit the rollup transactions, the sequencer submits this batch to a Layer 1 smart contract, which we will refer to as “Commit Batch.” This smart contract ensures data availability for the rollup. Once Layer 1 accepts the batch of transactions, these transactions achieve transaction finality, meaning that their order cannot be reversed (unless a malicious actor can change Layer 1 history), but they have not yet achieved settlement finality (i.e., they cannot be used yet by Layer 1).
4.Simultaneously, the sequencer collaborates with a prover to generate proof, showing that the state transition of the rollup occurs correctly. Note that the prover might be a separate third party or could be the sequencer itself.
5.The prover then submits the proof to another Layer 1 smart contract, referred to as “Finalize Batch.” This smart contract is responsible for validating the proof's correctness.
6.Once the proof is submitted and executed by Layer 1, if the proof is valid, the transactions in the batch achieve “settlement finality.” At this point, users can be confident that the expected state transition they received from step (1) is correct. Now, all data in the batch is secure and can be utilized by any Layer 1 contracts.
Let’s analyze the fees that users have to pay for using a rollup, and we will see that some components can be optimized further, leading to alternative data availability layers. In general, a ZK-rollup fee is composed of three parts:
1.Base Rollup Fee: The fee that users pay to the rollup, which is used to incentivize rollup operators to perform their jobs.
2.DA (Data Availability) Fee: Since storing data on Layer 1 requires a gas fee, a DA fee needs to be paid because the rollup’s data needs to be published on its base Layer 1.
3.Settlement Fee: Since a proof has to be verified by Layer 1, ZK-rollups incur costs for posting proofs on Layer 1 and also for the cost of verifying the proof.
The majority of the rollup's cost comes from the DA cost because it scales with the number of transactions in a batch. Fortunately, alternative DA layers like Celestia and Avail offer a lower DA fee compared to posting it directly on the base Layer 1.
M2 - The Move-based Zk-rollup from Movement Labs
Now that we understand how ZK-rollups operate in general, let’s explore the ZK-rollup architecture of Movement Labs, M2, which uses Ethereum as its base Layer 1, and dive into each of its components.
3️⃣M2 - The Move-based Zk-rollup from Movement Labs
Now that we understand how ZK-rollups operate in general, let’s explore the ZK-rollup architecture of Movement Labs, M2, which uses Ethereum as its base Layer 1, and dive into each of its components.
As illustrated in the figure above, the architecture of M2 slightly differs from the general ZK-rollup architecture. M2 is a Move-based ZK-rollup developed to support both MoveVM and EVM, with several modifications aimed at improving the rollup's robustness and efficiency. These modifications are made as follows.
4️⃣M1 - Decentralized Sequencers
Most existing rollups today utilize a centralized sequencer, meaning the owner of a project is the sole entity maintaining the rollup. Instead, Movement opts for decentralized sequencers to maintain its rollup, offering several advantages:
1.Resilience & Censorship Resistance: In traditional rollups, the project owner, responsible for maintaining the rollup, ensures efficiency in terms of upgradability, low complexity, and ease of control. However, a centralized sequencer is vulnerable to a single point of failure. This means that if the sole sequencer goes offline, whether intentionally or not, the rollup will lose its liveness until a new sequencer takes over. With decentralized sequencers, since there are multiple operators collaborating to maintain the rollup, if one goes down, users can still interact with the others, ensuring the rollup remains live. This setup also enhances censorship resistance, giving users more options to interact with the rollup rather than being limited to a single operator, as is the case with traditional models.
2.Soft Transaction Finality: Decentralized sequencers act like a mini-consensus layer, needing to reach a consensus on the order of transactions and state transitions before posting user transactions to Ethereum. This increases confidence that the intermediate state responded by the set of sequencers is correct with a high probability, compared to responses from a single operator.
3.Better MEV Resistance: With a single sequencer, there's a risk of having full knowledge of all user transactions and the power to control transaction ordering, potentially leading to large-scale Miner Extractable Value (MEV) issues. In a decentralized setup, some MEV risks can be alleviated as many operators collaborate to sequence transactions, preventing any single entity from having full control over transaction order. In a leader-based consensus, at most, a particular sequencer would have full control over MEV for only one block at a time.
Movement Labs has developed its decentralized sequencer network, called M1, which is utilized in the ZK-rollup stack mentioned above. M1 operates on a proof-of-stake model and uses the Snowman protocol (employed in Avalanche's C-chain) as its consensus algorithm, ensuring efficient and high sequencing throughput.
5️⃣Movement SDK
Coming with M2 is the execution engine called Movement SDK. The Movement SDK contains Fractal and MoveVM. With Movement’s MoveVM, the M2 execution engine can support both Sui and Aptos versions of Move languages. Moreover, Fractal allows developers to write and deploy Solidity smart contracts on M2. This unique feature enables both developers and users, whether they are EVM-based or Move-based, to coexist in the same system. This will help bridge Move ecosystems, like Sui and Aptos, with the EVM ecosystem together allowing liquidity to flow into Move ecosystems and introducing many new use cases and opportunities to both EVM and Move-compatible chains.
On top of Fractal, M2 also incorporates Block-STM into its execution engine. Block-STM is a greedy algorithm optimized for parallel execution without the need for developers to explicitly encode dependencies into their programs.
6️⃣Prover Marketplace
Similar to decentralized sequencers, Movement replaces a single prover with prover marketplaces, enabling a separate market for any participant that has enough computational resources to join as a prover. According to the Movement whitepaper, the economic model of the marketplace is still in development, so let’s discuss the opportunities that can be leveraged within the marketplace.
Movement utilizes a zero-knowledge proof scheme called Plonky2, developed by Polygon Zero. What is interesting about Plonky2 is that it fine-tunes and combines the advantages of efficient proof generation from STARK and the fixed small size from SNARK. This helps make proofs generated using Plonky2 very fast and of a small fixed size. Furthermore, with the Plonky2 architecture, it allows proof generation to be broken down into several fragments, where each fragment can be processed in parallel using STARK. It then uses SNARK to recursively aggregate the proofs of these fragments into one. Therefore, the prover marketplace might help enable parallel ZK proof generations.
The separate marketplace of provers also helps encourage provers to compete with others to provide lower prices for proof generations, which might help further reduce proof generation costs and the development of some techniques to enable faster proof generations.
7️⃣Separate Data Availability Layer
To optimize costs from recording data and making it public, M2 will post data on alternative data availability layers like Celestia and Avail. This approach will help reduce costs much more effectively than posting on Ethereum.
8️⃣Putting It All Together
Let's summarize a transaction's lifecycle of M2:
1.A user signs and submits a transaction to the M2 decentralized sequencer network, M1, either in EVM or Move formats.
2.The sequencer network interacts with the Movement SDK and reaches a consensus on the order of transactions, creating a batch of transactions. At this point, the user-submitted transaction achieves soft finality from the sequencer consensus, which is called sequencer finality.
3.The transaction batch is then forwarded and recorded on a data availability layer, leading to transaction finality, or called DA finality in Movement.
4.Once the batch achieves DA finality, a prover in the marketplace can generate a zero-knowledge proof for that batch.
5.After the proof is successfully generated, it can then be submitted to Ethereum, which acts as a settlement layer. Once Ethereum accepts the proof and the proof passes the validation process, all transactions associated with the proof are finalized, leading to settlement finality or total finality in Movement.
9️⃣Summary
Move is an alternative smart contract language developed to improve upon Solidity in terms of security and flexibility. It has been adopted as the main language on smart contract platforms like Sui and Aptos. However, since Move is a relatively new language, attracting developers to build on it has been challenging. To bring liquidity and developers to the Move-based ecosystem, Movement Labs aims to bring Move to EVM ecosystems. To achieve this, Movement is developing a Move-based ZK-rollup to be hosted on Ethereum, leveraging its two main products: M1 and M2. M1 is a decentralized sequencer layer that utilizes Snowman consensus, offering efficient and high sequencing throughput. M2 provides several components essential for the ZK-rollup execution stack. With M2, both Solidity and Move developers can deploy their contracts on the rollup, while users can enjoy high throughput from parallel executions and low-affordable fees due to an efficient prove generation algorithm and alternative data availability (DA) layer.
#movement #Gmove #movementlabs
Check 🔟Ecosystem of Movement Labs the below the next thread.