ETH Research: Detailed explanation of Rollup’s Snap Sync concept and mechanism

2023-10-26 18:29

Read this article in 9 Minutes

Snap Sync is critical to mitigating centralization vectors for infrastructure providers.

Original Title: "RFC: Deep dive into snap sync for rollups"

Original Author: George Spasov, Blockchain Architect and Co-founder of LimeChain

Translation: Sharon, BlockBeats

Editor's note: With the increasing number of Rollups, problems have also emerged. Performing Snap Sync on Rollup allows nodes to synchronize by obtaining pre-processing information from other participants in the system, while also being able to verify it appropriately. This is also a way to "reduce the centralization vector of infrastructure providers."

Overview

The exploration of various ideas and concepts below is related to the time it takes to synchronize the initial state of a Rollup node to the latest Rollup that improves it. In the following text, this improvement process can be referred to as "Snap Sync" for Rollup, inspired by a similar naming process for L1. This document outlines the overall idea of how Snap Sync is used for Rollup and delves into the roles and requirements of various Rollup participants.

Rollup node's Snap Sync is an important concept, because rollup is expected to achieve throughput several orders of magnitude higher than L1.

Although Rollup promises that anyone with observability of the data availability layer will have all the data to re-execute and synchronize Rollup, in reality this will quickly become very slow. This slowness may lead to centralization by consolidating data into a few specialized entities that continuously synchronize with L1.

The purpose of Snap Sync is to enable nodes to synchronize by obtaining pre-processing information from other participants in the system, but verifying it appropriately themselves.

Conceptual Viewpoint

Below is a conceptual idea consisting of 4 steps that can be used for Snap Sync in Rollup. It outlines how new Rollup nodes synchronize with the tip of Rollup.

1. Synchronize node records from Rollup of the most recent (ideally not the last) final confirmed block of L1 smart contracts and their block hash/state root.

2. The node connects to one or more peers and downloads the state of the specified final block.

3. Nodes verify the block hash/state root recorded in L1 in step 1 against the block hash/state root.

4. Nodes continue to synchronize subsequent finalization (if applicable) and virtual state from L1.

Deep Explanation

The above concept seems simple, but as usual, the details determine success or failure. When you start considering the goals and motivations of each participant in the Rollup system, the Rollup-specific features of Snap Sync begin to emerge. Here are several important considerations in the design of Snap Sync, which provide more input for proposing more complete conceptual solutions.

The role of follower nodes

The main participants in Rollup are the Sorter and the Prover (in Optimistic Rollup, the Verifier can be considered as the Prover).

The job of a sorter is to (in some way) take user transactions and sort them into L1. They are rewarded by providing a service of publishing Rollup (ideally effective) sequences. Validators obtain data and generate proofs of the given sequence's validity. Validators are rewarded for submitting valid proofs in L1.

Ultimately, both participants will be rewarded for their specific actions. The sequencer will be rewarded for sorting L2 state modification transactions.

To enable the sorter to perform its job, it only needs the latest virtual state and a version of the memory pool (privatized or publicized). It does not need to concern itself with (read storage) past validated or unvalidated states.

Proofers are rewarded for providing proofs. They only need sequence information from the L1 DA layer. They also do not need to concern themselves with (read store) past states.

This leaves a considerable void for end users - there are no participants working to serve RPC requests for reading current or historical states. While Rollup designers often view follower nodes as a "simplified" version of the sequencer, in reality, one could argue that they are a completely independent participant with a separate goal - to serve network users.

From the L1 node's reasoning, you should request to read the state of your own "full node". It can be inferred that "your own full node" is equivalent to "your own follower node". The follower node needs to save part or all of the historical state of Rollup in order to provide services for RPC requests of (your) historical data.

Some very common historical operations are - "give me the event sent from contract X" and "give me the transaction receipt of my transaction hash". Currently, no other actors need to serve either of them.

Follower node types and sync types

The simple method for syncing follower nodes is to download the L2 sequences from the L1 DA layer and re-execute them until caught up with the prompt. As previously mentioned, this quickly becomes impractically slow as the only sync mode.

Therefore, this is a possible but not sufficient follower node version. In the following text, we will refer to a node that fully synchronizes and stores the complete state from L1 DA as an archival follower node.

It can be inferred that the synchronization speed of nodes is much faster than what can be provided by archival follower nodes for multiple use cases. These are actual requirements that can be triggered from the normal operation of Rollup, its cryptographic economics, or purely for quickly capturing (MEV?) opportunities. Such nodes can connect to archival follower nodes and use the "conceptual perspective" outlined above to synchronize with Rollup hints.