Researched and written by our awesome engineering team - Aashutosh Rathi, Prudhvi Rampey, zk_cat and Kautuk during their time at Succinct’s ZK-Residency program that took place in October 2024.

The goal of this article is to not only provide objective performance metrics but also talk about the subjective experience while we were building using this toolkit -

1. Developer Experience

   1. Docs

   2. Support / Community

   3. Code / API

   4. Happiness Quotient

2. Features

3. Performance

General-purpose zkVMs have become a powerful force in quickly building scalable and privacy-preserving applications. Builders no longer need to master low-level circuit construction or complex zk mathematics. By supporting popular languages like Rust and its vast ecosystem, zkVMs help builders reduce development time by orders of magnitude. The idea is simple but potent: Write once in Rust, prove anywhere.

But with the number of zkVMs out there, choosing the right one can be a challenge. We sought to answer some critical questions:

• What zkVMs are available to use, and how do they perform under real-world conditions?

• What is the developer experience like for each one?

• What nuances arise in working with different zkVMs?

• Can we prove arbitrary Wasm logic inside a zkVM? (spoiler: Yes!)

This is why we conducted yet-another detailed benchmarking exercise, focusing on not only performance but also the practicality and developer experience of each zkVM. We selected 8 real-world cryptographic algorithms that are computationally expensive to directly run on-chain and ran them inside 6 zkVMs: SP1, RISC0, Jolt, Nexus, Delphinus and Powdr. You can view the algorithms and benchmark numbers here.

Ready, Set, Bench

We conducted our benchmarking on the following zkVMs with some commonly used operations with varying complexities and input sizes.

• SP1

• RISC Zero

• Jolt

• Delphinus

• Nexus VM

• Powdr (late addition, results in spreadsheet)

We initially planned to include Valida, but its toolchain wasn’t functional when we began this project. Now that Valida has released an improved Rust toolchain, we’ll revisit it and may follow up with a future article.

We chose the following algorithms to benchmark against:

• nth Prime

• ECDSA Verification

• BLS Verification

• BLS Aggregation

• Keccak

• Poseidon

• Merklization

• Merkle Inclusion Proof

To provide a roughly fair comparison, all measures of performance are based on clock cycle counts - each cycle representing a single iteration of a virtual RISC-V processor loop. Clock cycle counts remain consistent across runs on similar hardware, so higher cycle counts generally indicate longer proving times. Except for Delphinus, all the zkVMs here are based on the RISC-V ISA.

To help visualize our results, we've plotted the data on logarithmic scales. The y-axis in each graph shows cycle counts, while the x-axis corresponds to input size (n). In all comparisons, a lower number is better.

Algorithm 1: nth Prime

This deceptively simple algorithm challenges zkVMs, especially when calculating large primes like the 100,000th prime number.

Most of them performed similarly, however, the Nexus VM requires significantly more cycles than other zkVMs, indicating a substantial performance gap while Jolt OOMs (out of memory, read: our archenemy) out earlier. Other zkVMs cluster much closer together in terms of performance, but all zkVMs show increasing cycle counts as input size grows—a trend that will continue across other algorithms.

Algorithm 2: Keccak hashing

Precompiles / Accelerators

Precompiles (SP1) and accelerators (R0) are built-in functions within a virtual machine that execute specialized operations more efficiently than executing the same logic as a standard contract or bytecode, thereby reducing computational overhead and cycle counts. Both SP1 and RISC-0 have a lot of prebuilt libraries for common operations

The presence of precompiles for keccak clearly provides a performance advantage, as seen with SP1 (orange line). While the Nexus VM (purple line) remains inefficient compared to other zkVMs, and RISC0 lags as input size increases, SP1’s implementation with precompiles significantly reduces cycle counts. Among zkVMs without precompiles, SP1, Jolt, Powdr, and Delphinus perform similarly, further highlighting the impact of precompiles in enhancing efficiency.

Algorithm 3: Merklization

Once again, Nexus VM consistently shows the highest cycle counts. Without precompiles, the other zkVMs cluster together in mid-range performance. For larger inputs, cryptographic accelerators provide significant improvements—particularly with SHA-2 precompiles in SP1 and RISC0.

Algorithm 4: BLS Signature verification

BLS signature verification plays a crucial role in various on-chain operations, from light client verification to account abstraction.

In these benchmarks, Nexus demonstrates higher cycle counts, while Jolt struggles with Out-of-Memory errors and fails to execute.

Among the remaining VMs, performance is tightly matched, with Delphinus creeping higher with significantly higher cycle usage. Notably, SP1 with precompiles again provides a remarkable performance boost, highlighting the effectiveness of precompiles.

Other Benchmarks

We’ve also gathered performance data on additional algorithms, including Poseidon hashing and BLS signature aggregation. Due to the volume and complexity of these results, we can’t include them all within this blog post. To provide comprehensive access to these metrics, we’ve made a separate spreadsheet available, ensuring interested readers can explore the full breadth of our findings.

Find it here.

Wasm is awsm?

The ability to prove arbitrary Wasm logic opens up zkVMs to a range of languages that compile to WebAssembly, such as Go, Python, and JavaScript. We conducted a benchmark to evaluate the feasibility of proving Wasm and to quantify the cycle count required.

To achieve this, we compiled Rust code to WebAssembly and tested two approaches:

• Using wasmi, we interpreted WebAssembly within the zkVM

• Leveraging Delphinus’s zkWASM VM to trace and prove Wasm instructions

This graph illustrates the performance differences between native Rust, Wasmi and zkWASM for various algorithms.

Key insights include:

• Performance Gap: Across all algorithms, native Rust outperforms both wasm competitors.

• Impact of Cryptographic Complexity: For simpler algorithms like nth prime, the performance gap is about an order of magnitude. However, for complex cryptographic tasks like BLS verification, this gap expands to two orders of magnitude.

• zkWASM Advantage: Delphinus’s zkWASM achieves cycle counts that are relatively closer to native Rust compared to running Wasmi within a general-purpose zkVM, making it the leading option for proving Wasm applications.

• Performance Trade-Off in Intensive Tasks: Wasm's flexibility comes at a cost, with significant overhead in cryptographic and complex operations compared to native execution.

To mitigate these costs, optimizations could include compiling Wasm directly to RISC-V assembly rather than interpreting it and integrating precompiles through the Wasm Component model.

Letting devs cook

Building within a zkVM is much like working with an embedded system: keeping dependencies minimal is crucial. We prioritized lean crate setups by setting default-features = false and incrementally enabling only necessary features. Additionally, we had to be cautious with serialization/deserialization for complex inputs and carefully manage memory, particularly for heavy tasks.

Given these constraints, its important to have a smooth setup process, thorough documentation, and responsive developer support to capitalize on the productivity gains that zkVMs promise. Here are some key insights on developer experience, from a month of working with various zkVMs:

• Reliability: SP1 and RISC0 provided the most reliable experiences—everything simply worked. Other VMs sometimes crashed or encountered out-of-memory (OOM) issues when handling larger input sizes.

• Documentation: RISC0 excelled with clear, well-structured documentation, including concept explanations and detailed diagrams. SP1 and Jolt also provided solid resources, while other VMs fell short in this area.

• SDK: Jolt had the most intuitive SDK, allowing us to annotate provable functions with a simple macro. The other zkVMs followed a similar SDK pattern, making them relatively easy to adapt to. Also, most of the developments across other SDKs are following the same path as Jolt’s in terms of exposing guest program APIs. However, Delphinus’s initial setup was less straightforward, requiring us to dig into the codebase, which added complexity to the onboarding process.

• Support: Delphinus led the way in developer support, with their team going above and beyond to resolve issues. SP1, RISC0 and Jolt also offered active community forums for troubleshooting. Even Nexus had good support. (Fun fact, Nexus and Succinct teams are literally 1 block away from each other in SF)

Overall, we had a lot of fun working with different VMs! We even reported multiple bugs and contributed to the development of these zkVMs throughout our project! (One inconvenience at a time 🕺🏻)

Scores

All the scores are based on the testing results of October-November 2024, All the teams are exceptionally fast in shipping updates and

Summary

SP1

SP1 provides a smooth development experience with strong documentation, good APIs, and extensive precompile support. Its prover network is reliable, and the inclusion of standard library support and compatibility with multiple Rust crates simplifies development. Its default recursive STARK proof system can be slow, but the significantly lower cycle counts due to precompiles highlight its efficiency advantages.

• Offers the most extensive set of precompiles.

• Default proof system is a recursive STARK, groth16 takes longer than RISC0

• Better cycle tracking features than most.

• Highly compatible with Rust crates, easing integration.

• On-chain proving toolkit is available

• No direct WASM interface.

RISC0

RISC0 offers a smooth development experience, solid tooling, and decent documentation. Some precompiles and standard library support exist, but there are fewer than SP1. While it lacks a polished GUI for its prover network and can be memory-heavy, RISC0 can produce Groth16 proofs more quickly. Its support is adequate, though not exceptional, and on-chain proving is possible.

• Less precompiles compared to SP1.

• Uses Groth16 for proofs, smaller proofs

• Memory-heavy execution can lead to OOM issues.

• No prover network web interface/GUI, though a network exists.

• STARK-to-SNARK bridging only runs on x86.

• On-chain proving supported but less polished.

Jolt

Jolt provides good developer experience and community support, but it faces severe memory issues leading to OOM errors. While it supports WASM verification and has tooling for stack configuration, the lack of precompiles and poor cycle tracing limit its efficiency. Despite some promise and ongoing fixes, its performance and reliability are currently lacking.

• No precompiles, leading to higher cycle counts.

• No Groth16 recursion, no on-chain verification.

• Current fix proposals exist but are unmerged.

Nexus

Nexus has good support and pluggable guest options but lacks a prover network, standard library, and efficient proof systems. Its Nova-based approach is slow, with large proofs and frequent OOM issues. The developer experience is subpar, and no precompiles or on-chain tooling are available. Parallel processing helps slightly, but overall it remains inefficient.

• Uses Nova proofs, slow and large.

• No prover network, all proving is manual.

• No standard library support.

• Parallel processing on multiple CPUs is possible.

• Pluggable guest approach but poor DX.

• Lacks any form of precompile optimizations.

Valida

Valida uses plonky3 proofs and can achieve high speed on its own operations, but the developer experience is complex. Its Rust SDK is immature, arithmetic operations are limited, and it only runs on Linux. Documentation exists but doesn’t translate into smooth usage. It lacks community support, features, and mod operations, restricting its utility.

• Runs only on Linux.

• Immature Rust SDK, limiting integration. (Nov 24, Update available, need to test)

• No mod operations.

• Plonky3-based, can be very fast under constrained conditions.

• Reading/writing IO is overly complex.

Delphinus

Delphinus uses direct Wasm and a GPU-based approach for proofs, resulting in very fast Wasm proving. However, circuit building is slow, and the developer experience requires custom Wasm development with limited documentation. While it supports importing Rust crates and comes with good customer support, proof generation is extremely slow, and certain features remain inaccessible. It provides standard library support but demands extensive setup and dedicated hardware.

• Requires GPU for proof generation.

• Direct Wasm approach for proving is fast but circuit building is slow.

• Standard library supported.

• Decent Rust crate integration.

• Setup overhead is significant.

• Has a “pro” plan for enhanced features and support

Takeaways

• Precompiles are essential: They significantly reduce cycle counts, and in turn, proving times. In this area, SP1 stands out as a clear leader.

• Client-side proving isn’t quite there yet: zkVMs today are not ready for efficient client-side proving. This can change with modular VMs like Powdr providing swappable backends like the STWO prover.

• SP1 and RISC0 stand out: As of November 2024, SP1 and RISC0 are the most mature zkVMs, offering dev tooling, access to prover networks, different proof types and much more. Other zkVMs are catching up though.

• zkVMs are making zero-knowledge mainstream: We rapidly generated proofs for multiple complex algorithms, showing how zkVMs can tackle real-world challenges swiftly and securely.

• Not a silver bullet: While zkVMs lower the barrier to entry, custom circuits will likely still yield better performance than general-purpose solutions.

• Proving is still tough: Efficient proving often requires expensive, specialized hardware, presenting a resource challenge for many developers.

• Prover networks have trade-offs: They can help scale proving but may introduce privacy considerations and complexity in implementation.

Final verdict

Both SP1 and RISC0 emerge as top-tier solutions. RISC0 offers strong documentation, a smooth developer experience, and efficient proof generation. However, SP1’s advantage lies in its broad precompile support and superior APIs, enabling lower cycle counts and a more streamlined workflow. This efficiency edge—alongside robust tooling, reliable prover networks, and compatibility with standard Rust crates—positions SP1 slightly ahead in the race, making it the standout choice for those prioritizing performance and developer convenience.

But…

While there are currently more zkVM projects than actual zk applications, this abundance of infrastructure initiatives serves as a foundational catalyst. As these zkVMs mature, they will lower the barriers to entry for developers, ultimately enabling a broader range of builders to leverage zero-knowledge proofs in their products and services. Over time, this will foster a thriving ecosystem, encouraging innovation and accelerating the adoption of zero-knowledge technologies across the industry.

Ultimately, general-purpose zkVMs are poised to lead the upcoming ZK revolution, setting new standards for efficiency, scalability, and accessibility!

What’s Next?

Succinct has released a whitepaper outlining a new, fully permissionless prover network protocol designed to enable anyone to contribute computational resources without centralized oversight.

Around the same time, RISC0 unveiled “Boundless,” its own prover network solution aiming to streamline distributed proving and verification at scale.

Additionally, Valida introduced a new Rust-based toolchain claiming significant performance improvements and better developer ergonomics.

We will be taking a closer look at these developments soon, as they promise to advance both efficiency and usability in zero-knowledge proof ecosystems.

Glossary

Benchmark detailed numbers - Spreadsheet

ZK Residency final presentation - Recording, Slides

You can find all the code used for benchmarking here - GitHub

Update: August 5, 2024 The mentioned issues had been “somewhat” fixed by the concerned team. The game is still not on-chain.

Disclaimer: This piece is meant to be a fun and spicy callout on the current situation and does not mean any harm, the devs in Stackr team are actually coinbase fanboys and would infact love to work with them on fixing the issues highlighted here to onboard users to crypto “properly”.

A few weeks ago, Coinbase (Base) announced a partnership with Atari, the gaming giant, bringing arcade classics like Asteroids and Breakout “onchain” as part of their ongoing “Onchain Summer” campaign. Much like everyone else, we found this move quite based, paid the minting fees, and proceeded to play Asteroids. Few games in, one of our engineers got bored and started wondering the obvious question: “where’s the onchain?”.

This blog post serves as a case study, uncovering the lack of “onchain” in the onchain arcade, how we were able to spoof a high score, and how this led us to build an Asteroids-clone as a Micro-Rollup (live at Comets). The aim here is not only to be spicy but also propose a better approach. So, we’d be introducing the concept of Proof of Gameplay and, get this - how we actually put the game on the fkn chain with Stackr.

Proof of Off-chain: Spoofing a High Score on Base’s On-chain Arcade

The psyops of the on-chain gaming world is that many games actually run entirely off-chain, only submitting final scores to the blockchain. This approach, while efficient, has a significant flaw: there’s no way to ascertain if a player genuinely played the game to achieve their high score or if they merely spoofed an inflated score. This lack of verification undermines the game's integrity, making it impossible to distinguish between genuine skill and fraudulent activity.

Base’s On-chain Arcade suffers with the exact same flaw. When a game session ends, the browser simply submits the high score to Stack.so’s point system to record it (via another API hop). The issue is worsened by the fact that since it’s the browser submitting the score directly, the system’s API key is left exposed. So, a little bit of reverse engineering (fancy term for opening the “Network” tab) and we were able to recreate the API request in Postman:

This means anyone can submit a custom high score for any address without any authentication. As the obvious next step, we reported this issue to the Base team. It took them a long time (over 2 weeks) to work on the issue.

So, in light of transparency and to simply make the summer more entertaining, we made a webpage - [redacted] - where anyone can go and get their desired high score! After all, Web3 is all about giving control back in the hands of users, amirite?

As of August 5, 2024, this method does not work anymore. The teams changed the API format but the fix is still (it seems at the time of publshing this article) on the frontend side of things with a JWT token session. The gameplay is still not recorded or has any link with final scores being submitted. If the frontend wants, it can send whatever score to the point system. (infact even legit games are not getting submitted on the leaderboard, a bug perhaps?)

How can we do better?

Our team having discovered this issue combined with our general curiosity to explore interesting problems, we thought how can we do better, decided to put on our builder hats and got to work.

Proof of Gameplay 🥁

Let's revisit the basics by examining how traditional games function. In a typical client-server game setup, the client (player's device) and the game server collaborate to deliver a seamless experience. The client is responsible for rendering the game world and user interface, capturing player inputs, and sending them to the server. Both the server and clients run their own game loops where the server is authoritative, meaning it resolves conflicts and discrepancies in the game state. Since the server stores and validates all the player’s inputs and actions in real-time, manipulation of the game state, such as forging scores, is prevented.

In contrast, the underlying issue with the On-chain Arcade game is that the server relies solely on the score submitted by the client, which could easily be spoofed.

To address this issue, we need Proof of Gameplay.

The core idea behind Proof of Gameplay is to ensure that every recorded score is backed by verifiable evidence of actual gameplay. For example, similar to traditional game designs, a record of all the moves made by the player can serve as a proof for the server (or anyone) to be able to verify the submitted score by replaying the sequence of moves.

Implementations of Proof of Gameplay can preserve the fairness and competitiveness of games and also reinforce trust in the on-chain gaming ecosystem.

Proof of gameplay for Turn-based/shared world games

This is just one of the approaches which is possible with this construct where the user starts a session, records all the moves and sends the proof of gameplay to the micro-rollup for verification. This works in this particular category of games but might not be the best one as it requires a large list of moves that gets signed on in a single packet. The packet size can grow by a lot which may not be practical to sign as a message.

Moreover, in case there are multiple players involved, for example, turn based games or shared world games, the moves from each player would be dependent on each other. In this case, each move must be a standalone user action to the micro-rollup which will be sequenced and executed on the world state.

Micro-rollups, thanks to their insanely fast block times can support both modes. We will discuss this in a later blog post ;)

Off-chain Game + Proof of Gameplay = On-chain Game

As noted above, in the traditional setup, full control lies with the game server, and ultimately, the game developer, who could arbitrarily change the game logic or state, potentially cheating their users. This is where the importance of “on-chain games” comes into play. By implementing all or parts of the game logic on-chain as (immutable) smart contracts, games can become more transparent and permanent.

However, this is much easier said than done. Game logic can be extremely complex to write in EVM, and game servers are among the most demanding systems, while blockchains are terrible for compute-heavy tasks. Fortunately, we have this technology called rollups which supercharge blockchains with just that - perform a lot of heavy computation off-chain and submit a small proof of correctness on-chain. However, even most rollups today are general-purpose blockchains themselves and inherit the same limitations.

The quintessential thing to note here is that the game’s state machine needs to duplicated on both client and server side to enforce the rules. At the same time, an off-chain server requires trust while an on-chain server is impractical. But what if we had verifiable off-chain servers — only submit a Proof of Gameplay on-chain without requiring the game logic to be on-chain?

Micro-rollups, with their verifiable and fast off-chain compute, are perfectly suited for this problem.

Proof of Gameplay ∈ Verifiable Compute ∈ Micro-Rollup

1. Micro-rollups are simply backend services

   Micro-rollups, being indistinguishable from backend services, offer the same developer experience as traditional backend frameworks. Combined with the fact that the Stackr SDK is written in TypeScript, this enables code reuse between the frontend and backend. This is a big unlock for browser-based games, as developers don’t need to duplicate the game logic.

2. Micro-rollups enable specialized minimal runtimes

   Micro-rollups lets you selectively expose only necessary functionality through deterministic and rigid State Transition Functions (STFs) tailored to the state of the rollup. This allows for highly optimised minimal runtimes dedicated to the game logic offering extremely fast execution.

3. Micro-rollups enable verifiable off-chain compute

   Micro-rollups require no overhead in bootstrapping a network since they leverage Stackr’s verification layer (aka Vulcan) for correctness. Once the state machines are deployed, the STF logic cannot be mutated. This enables the users to have an assurance that the provider has not arbitrarily changed the rules of the system.

The following sections cover the gameplay experience of the game we built and also the developer experience of building it, detailing various engineering tidbits.

Comets: Actually “Onchain” Asteroids-clone with Stackr

because comets have a streak which makes it’s path “predictable” ;)

After a bunch of research (and meme-ing), it was now time to bring this to life. We started by carefully listing down the core properties and features our game should offer:

1. The game should incorporate Proof of Gameplay without sacrificing UX. That is, the game should provide the same web2-like experience familiar to users.

2. The Proof of Gameplay will guarantee Verifiable Replays for each game session. That is, the server (read: micro-rollup) will verify the Proof of Gameplay from the client, keeping it in check.

3. The ultimate source of truth should be the underlying blockchain. That is, the server will also relay the proof to be verified on the parent chain.

With this in place, we could design the end-to-end user story of a player’s interactions with the game, clearly demarcating what needs to be off-chain vs on-chain.

Gameplay Experience: Off-chain Game meets Proof of Gameplay

Breaking this down:

0. The player visits the webpage — comets.stf.xyz — and connects their wallet. They can also choose to create an embedded wallet.

1. The player presses ENTER to start the game. At this point, their wallet pops-up, requesting them to sign an action and submit it to the micro-rollup.

2. The micro-rollup executes the player’s action, records a new game in the state, and returns a pseudorandomly generated game ID.

3. The game world is now rendered, and the player experiences traditional web2-style gameplay with no wallet pop-ups or on-chain transactions during the gameplay. The client keeps track of each move made by the player at each tick of the game loop.

4. At the end of the game, the player is prompted with another request to sign an action to submit their score and Proof of Gameplay (their list of moves) to the micro-rollup for validation and storage.

5. The micro-rollup executes the player’s action and re-runs the game loop, replaying all the moves. If the simulated score matches the submitted score, it is recorded in the state. Otherwise, if the scores don’t match, the action’s execution fails with no state update.

6. Finally, the player is notified of success or error with their updated standing in the leaderboard.

Try out the game here -

The entire game codebase can be found here

GitHub - stackrlabs/comets: Comets: Remake of the arcade classic Asteroids as a Micro-rollup

Comets: Remake of the arcade classic Asteroids as a Micro-rollup - stackrlabs/comets

https://github.com

Developer Experience: Off-chain Game Server meets Micro-Rollup

Now that we have talked about the UI/UX of the game, let’s delve deep into the DevEx of building this game’s server-side logic as a micro-rollup.

Note: Before proceeding further, if you are not familiar with how Stackr Micro-Rollups work, please refer to Quick Primer on Micro-Rollups.

When developing a micro-rollup, it's crucial to conceptualize your logic in terms of a state machine. This involves carefully considering the state of the micro-rollup - that is, the data it will hold - and the actions that will dictate the behavior of the state transition function, which in turn operates on this state.

With the above in mind, we start by designing the state of the micro-rollup.

The Design

1. Game sessions are stored off-chain inside a state machine

2. Player sends actions which trigger a state transition function inside the state machine

3. Player can send action to start or end a game.

4. After each set epoch a block is generated which contains state root and action inputs

5. The block is sent to Vulcan network for verification

6. If the block conforms the rules of the state machine it is approved

7. The block data is split between Ethereum and DA for settlement.

The Code

The Stackr SDK, written in TypeScript, lets you inject the application logic directly into the blockchain. The developer only needs to define their state and state transition functions without worrying about any of the protocol heavy lifting of building a blockchain. Let’s see how:

Defining the base state

Our micro-rollup state only needs to keep track of game sessions with basic information, such as the player's address, the score, and whether the game has ended.

1. So as a starting point, we defined the rollup state as types in TypeScript.

The Stackr SDK adopts a schema-first design paradigm familiar to application developers. It allows complete freedom in terms of state design, allowing developers to simply think in terms of individual entities and how to compose them together to form the full application state.

You may be wondering how we are able to get away with only storing the score and not the list of moves in our rollup state — this is covered in the next section.

Adding handlers for state update

After we have defined our rollup’s state, we need to define State Transition Functions (STFs) that update the state.

2. We defined two functions, startGame and endGame to manage a game’s lifecycle.

By having only two actions for each game and performing validation in a single step at the end, the on-chain footprint is kept minimal, making this approach cost-effective.

Start Game

Breaking down the startGame state transition,

• The player can submit an action to start a game.

• The STF deterministically generates a new game ID to uniquely identify a game session, records it in the state and emits the same in execution logs.

What may seem like just a couple of lines of general TypeScript code is actually supercharged by the Stackr SDK adding some interesting properties, such as:

• Verifiable Randomness is added to the game based on the game ID and used as a seed for generating randomness in the game world. It ensures each game session is unique and prevents cheating, such as using the same list of moves from a previous game.

• Emitting logs allows linking side effects to a particular action’s execution. Since micro-rollups execute actions instantly upon arrival (within milliseconds), these logs can be returned in response to the very same request. This enables a familiar Web2-style request-response flow, facilitating easier implementation on the frontend.

End Game

Breaking down the endGame state transition

• After a player completes a session on the client, aka “plays the game”, an action is sent to the micro-rollup to end the game, referencing the related gameId. The request also includes the score, and all their recorded keystrokes as a serialized list (gameInputs) according to a custom action schema.

• The STF locates the specified game within the state and performs basic checks, such as verifying the player's address.

• The STF then initiates the game world, passing the gameId and applying the player's inputs to it.

• Finally, if the simulated score matches the submitted score, it is recorded in the state. Otherwise, if the scores don’t match, the action’s execution fails with no state update.

An interesting detail to note here is that the implementation of GameWorld is independent of the STF. It's a common package shared between the frontend and backend. The core idea is that as long as it's deterministic TypeScript/JavaScript code, it can be imported and used within the micro-rollup’s state machine. This is super cool because it unlocks access to npm, the world's largest software registry, making most (if not all) of your favorite existing libraries now available for building decentralized apps.

Implementation of the Game Logic (spoiler: we didn’t write it ourselves)

This superpower of Stackr SDK became really useful for us because we are not game developers. With some diligent scrounging on GitHub, we were able to find a repository with a JavaScript implementation of Asteroids. Fun fact: it only took us a single day of work to have an initial Proof of Concept implementation where we were able to simply port this package inside the micro-rollup.

Overall, we were able to re-purpose the package as-is with only a few modifications to make it work with the Stackr SDK:

1. We modified the GameWorld class to initialize with a game ID and the screen dimensions. The randomness seed is derived from the game ID. This seed, along with the screen dimensions, affects all operations in rendering the game world, such as the position and size of objects like the spaceship, rocks, aliens, etc. Since the game ID is deterministically generated inside the startGame STF, each game session is verifiably unique.

2. At the end of the game session, we need to send the entire list of all recorded keystrokes as a signed payload to the micro-rollup. Generating a signature on the raw payload and then sending it over to the network could be very slow. Therefore, we came up with a basic serialization technique to convert the list of all input objects into a single compressed string. This string represents the list of all inputs with comma-separated base 10 numbers whose binary representation represents bit-strings, where each position of the bit maps to a particular action. For example, a list of inputs that originally looks like [{ isThrust: true}, { isFire: true }, ...] gets serialized into a string like "32,2,..."

3. Some effort was spent in decoupling the game business logic from pixel rendering logic. This was necessary to keep the WASM minimal and allow for clean re-execution. This, as mentioned above, also allowed us to share this code between the client and server.

Off-chain Game + Micro-Rollup = Endless Possibilities ✨

Verifiable Replays

The beauty of this system is that it allows Verifiable Replays of the game without requiring either of the game state or logic to be on-chain.

As mentioned above, micro-rollup’s state root is settled on L1 (typically, Ethereum). It is interesting to note that the developer can chose what part of the state settles on L1 vs what part can go on DA as metadata, thereby, unlocking hybrid security assumptions.

In this case, we extract the games list from the state and settle it’s merklized root on L1, thereby opening up the possibility of direct inclusion proofs of games in the merkle tree.

Without any extra effort on the developer’s part, the Stackr framework ensures that the micro-rollup’s state machine binary (Wasm) and all the actions to it get published to the DA. The hashes of the Wasm and the genesis state are stored in the AppInbox contract.

This approach allows anyone to verify the entire pipeline in a fully trustless manner. Anyone can retrieve the Wasm and the actions (game inputs) from the DA, replay these actions, catch up to the latest state, and verify a Merkle proof of the score against the state roots on L1.

Incentivization using Points or Referral Programs

Base’s Onchain Arcade makes use of Stack.so for loyalty points and leaderboard. However, as mentioned, the client is making a mere insecure API call to record the scores. So, again — how can we do better?

Recently, we published an article, Micro-Rollups for Points Systems, which details a micro-rollup implementation of a loyalty points platform. An exciting feature of Stackr is its built-in cross micro-rollup interoperability. This means we can spin up a points micro-rollup and seamlessly bridge users scores from our Comets micro-rollup. This approach would keep the game logic decoupled from the points system, enabling it to be used across multiple games and campaigns, and extended with its own features. In fact, anyone has the freedom to launch their own micro-rollups that interoperate with these two; an example could be a referral system.

The end result would be a set of modular but integrated systems, avoiding ecosystem silos and fostering permissionless innovation.

Btw, we have our own points system in beta → try it out pointy.stackrlabs.xyz, and stay tuned for more announcements on this front! 👀

Scale using ZK Proofs

Currently, Vulcan employs a pessimistic re-execution model to verify incoming blocks from micro-rollups. This leads to a trust centralization vector on Vulcan. To mitigate this, Stackr is actively exploring the potential of zkWASM-based verification, enabling Vulcan to execute application WASM binaries within a zkVM and generate STARK proofs for final verification on the parent chain.

In the context of Comets micro-rollup, this could be implemented in a way that allows the client to generate a ZK-Proof of Gameplay locally on the user’s device. The underlying layers would then only need to verify this proof, providing greater scalability and cost-efficiency.

How to think about Proof of Gameplay for your next game?

While this blog post specifically focuses on the Asteroids game, the concept and implementation of Proof of Gameplay (PoG) using Stackr demonstrated here can be extended to any single-player or even multi-player turn-based games.

By integrating PoG with features like loyalty points and referral systems, developers can create new opportunities for rewards and incentives, backed by verified gameplay achievements. This can enhance player engagement and trust in the game's fairness.

Moreover, having Proof of Gameplay on-chain opens up new possibilities for integrating in-game assets and currencies onto the blockchain. By backing in-game asset and currency acquisitions with verified gameplay, developers can prevent fraud and maintain the integrity of virtual economies. This approach naturally supports the development of a thriving secondary market where in-game assets and currencies can be freely traded, with their value determined by the free market rather than the game developers. The result is a system that not only incentivizes players by allowing them to capitalize on their in-game achievements but also fosters a dynamic environment where both developers and players can innovate and create new economic opportunities.

What’s next?

1. Coinbase if you are reading this…

We’d love to explore collaboration with Base and be the choice of game development toolkit for builders in the base ecosystem. Together, we can help developers build authentic on-chain games with genuine “Proof of Gameplay” and unlock a new paradigm in game development with actually on-chain verifiable games. Please reach out to someone from our team :D

2. Proof of Gameplay grants

We’d soon be launching a grants program for builders to use the micro-rollup SDK to build and launch games with proof of gameplay mechanics. Game developers would get a toolkit and additional resources alongside core integration APIs to build some cool shit with our SDK.

Come build with us!

At Stackr Labs, we’re building the toolkit and the necessary infrastructure to build app-specific micro-rollups to supercharge and unlock the DevEx around building apps that bridge the gap between Web2 and Web3. If you’re someone who’s looking to build Web3 apps or games, we’d love to talk to you and find ways to collaborate.

Join our Telegram Community to stay updated with the latest news, or reach out to us on Twitter (X).

FYI

Our SDK is live in open beta for anyone to try out!

This blog post serves as a case study introducing the concept of ephemeral rollups, exploring their use cases across Web2 and Web3, detailing the user experience and engineering of the application we developed with the Stackr SDK, and shares some fun tidbits and challenges faced during the tournament.

What is an Ephemeral Rollup?

“Ephemeral” and “Rollup” - let’s break down the two words individually.

• Ephemeral: as in transient or short lived.

• Rollup: a system (often a blockchain) that executes transactions off-chain and then submit a single, aggregated proof back to the parent chain, preserving integrity and verifiability of such executions. In this context, the parent chain and the rollup are termed as layer 1 and layer 2 respectively.

Therefore, Ephemeral Rollups (ERs) can be defined as a special form of rollups that are "short-lived". For example, a rollup (read: application) can be spun up at the start of an event, process rapid transactions off-chain during the event, and then be spun down at the end. At this point, the rollup data, including state roots and transaction inputs, can be settled onto the parent chain for permanent storage. This approach ensures the retraceability and verifiability of event data at any point in the future, even after the application’s lifetime.

What Applications Make Sense as an Ephemeral Rollup?

Consider the following list of use cases across various domains (non-exhaustive):

• Financial Markets: Rapid transactions in financial markets can be processed off-chain, ensuring quick execution and minimal latency. At the end of the session, only essential summary data, such as final positions and balances, could be committed on-chain, reducing costs and maintaining market integrity. Examples: promotional flash sales and auctions.

• Ticketing and Events: Process ticket sales and event results in real-time with final data, such as ticket ownership and event results, committed on-chain for a tamper-proof record. Examples: hackathons, concerts and seasonal sports tournaments.

• Gaming: For in-game events where every click could be a transaction, a fast and dedicated runtime can be off-chain but only user’s game state or final scores can be preserved on-chain. Examples: competitive esports or gaming tournaments.

• Privacy: Situations where users want to transact without leaving a permanent trace so only the final balances can be settled on-chain. Examples: private auctions, confidential fundraising campaigns and surveys.

• Data Aggregation: Collect and process high-volume data streams from sensors like IoT devices in real-time, with summary data settled on-chain for transparency. Examples: seasonal agriculture and environmental studies.

• Temporary chains for an Airdrop or NFT mint, and more.

Distilling these examples, we see that applications requiring a combination of high-frequency transaction processing, real-time responsiveness, privacy, and verifiable final outcomes can benefit from being implemented as ephemeral rollups. This approach allows applications to borrow the essential Web3 properties of transparency and verifiability without needing to be entirely on-chain which could be too costly or complex.

In short, if your application needs to provide the core guarantees of verifiable checkpoints and final state, even after its lifecycle, then an ephemeral rollup may be the ideal solution for you.

Ephemeral Rollups 🤝 Stackr SDK

We know by now that rollups provide scalability and cost efficiency by reducing the load on the parent chain. However, most rollups today are general-purpose blockchains themselves. If your application requires rapid transactions, you are still bottlenecked by the block time and competing for the limited block space shared among all other smart contracts on the rollup.

Ephemeral rollups are inherently application-specific since the core idea behind them being “short lived” is that many applications don’t need to exist indefinitely, unlike smart contracts on a general purpose blockchain. Therefore, they borrow all the advantages of a micro-rollup built with Stackr SDK, such as:

1. Micro-rollups are simply backend services

   Micro-rollups, being indistinguishable from backend services, offer the same DevEx as traditional backend frameworks. In context of ephemeral rollups, this means they can be easily spun up and down while assuring all rollup data was published to the DA and settled on L1.

2. Micro-rollups enable specialized minimal runtimes

   Micro-rollups lets you selectively expose only necessary functionality through deterministic and rigid State Transition Functions (STFs) tailored to the state of the rollup. This allows for highly optimised minimal runtimes dedicated to your application offering extremely fast execution.

3. Micro-rollups enable instant interaction alike web2 apps

   Micro-rollups execute transactions instantly upon arrival. This reduces friction for developers, enabling them to deliver an instant, interactive, and responsive UI that users expect from Web2 applications.

4. Micro-rollups enable verifiable off-chain compute

   Micro-rollups require no overhead in bootstrapping a network since they leverage Stackr’s verification layer (aka Vulcan) for correctness. Once the state machines are deployed, the STF logic cannot be mutated. This enables the users to have an assurance that the provider has not arbitrarily changed the rules of the system.

5. Micro-rollups can compose with on-chain apps

   Micro-rollups settle the state root (read: merkle root) of the app to the L1 allowing other apps to provably access the state of the rollup, even after the app’s lifecycle.

Bringing an Ephemeral Micro-Rollup to life for Avail Unification Cup

An interesting fact is that the Stackr team had been researching and exploring Ephemeral Rollups since some time already. For example, we previously built and showcased on twitter, a Scoring System as an Ephemeral Micro-Rollup that can be used for games like Capture the Flag. Hence, partnering with Avail to build an Ephemeral Rollup for their event was the perfect opportunity to showcase simply how delightful of a developer experience (DevEx) it is to build a real-world application with Stackr SDK.

The goal (pun intended) was to create an application that would allow both onsite attendees and remote followers to track scores, leaderboards, fixtures, rosters, and team information in one place. This app provided a web2-like experience with the added benefit of on-chain traceability, as all match events were recorded in real-time by the Avail team and could be verified by onlookers instantly.

App Experience: Web2-style UX meets On-chain Verifiability

This section details the various design and engineering decisions that went into building this application’s UI to enable a Web2-style UX but with on-chain verifiability.

Embedded Wallets

One of our main goals was to abstract the complexities of chain interactions for the users.

We had two choices:

1. Traditional Wallet Connection: This would require users to connect their wallet and sign transactions manually. However, this approach often creates friction, especially if users need to access the application from a device without their wallet signed in.

2. Embedded Wallets: We chose this option. By using Privy as our OAuth provider, we enabled automatic embedded wallet generation during user signup. This method ensures that the private key is distributed between the client and server, making it impossible to retrieve the private key without the user’s consent.

For administrators of the Micro-Rollup, we implemented an authentication system where only the embedded wallets of authorized admins can sign actions. This approach enhances security and ensures a seamless user experience by reducing the need for repetitive manual interactions with the wallet.

Better Transaction UX with EIP712 Type-Based Signing

As discussed later, the backend exposes an API endpoint that returns all the STFs with their preferred schema and EIP-712 types. Based on this information, the frontend dynamically renders the appropriate form, allowing admins to sign and submit the payload without any ambiguity in what action they are authorizing. This is a much more secure and user-friendly approach than traditional DApps where wallets often require users to sign cryptic string of bytes (calldata).

Transactions Page: Inbuilt Block Explorer

One of the key features we implemented is a transactions page, which functions as an inbuilt block explorer. This page lists all actions on the Micro-rollup along with their on-chain pointers, such as transaction links to explorers of both Ethereum and Avail DA. This ensures that all transactions are open and verifiable, maintaining transparency and trust in the application.

Serving Stale Content While Revalidating

To enhance the user experience on the end-user (viewer) side, we built a suite of regular REST APIs. These APIs provide access to various data points from the rollup state such as match fixtures, match events, leaderboards for players and teams, micro-rollup transactions, and more.

All of these APIs serve regular JSON content, which can be updated through frontend polling. To optimize performance, we used the swr (stale-while-revalidate) technique to cache the transformed responses in a format compatible with our components.

Native-Like Feel with Optimistic UI Updates

To make the app feel more native, we chose to develop a mobile-optimized Progressive Web App (PWA) instead of a regular web app. This approach, combined with the embedded wallet, completely abstracts away the chain aspects and provides a seamless, mobile application-like experience.

Overall, both admins and viewers perceive the application as having a seamless UX similar to traditional apps, despite being backed by the security of Ethereum. We achieve this by updating content immediately upon receiving soft confirmation (C1) from the micro-rollup, which typically occurs within milliseconds. This approach settles transactions on-chain in the background while providing a responsive and regular web2-style application UX.

Feel free to take the application for a spin by visiting https://unify.stf.xyz or you can watch the demo video linked below as well :)

Developer Experience: Rollup meets REST API

Now that we have talked about the UI/UX of the application, let’s delve deep into the DevEx of building this application’s server-side logic as a micro-rollup.

Note: Before proceeding further, if you are not familiar with how Stackr Micro-Rollups work, please refer to Quick Primer on Micro-Rollups.

When developing a micro-rollup, it's crucial to conceptualize your logic in terms of a state machine. This involves carefully considering the state of the micro-rollup - that is, the data it will hold - and the actions that will dictate the behavior of the state transition function, which in turn operates on this state.

With the above in mind, we start by designing the state of the micro-rollup.

The Design

1. Tournament data is stored off-chain inside a state machine as a JSON object

2. User sends actions which trigger a state transition function inside the state machine

3. User can send action to start the tournament, start or end a match, record goals, etc.

4. After each set epoch a block is generated which contains state root and action inputs

5. The block is sent to Vulcan network for verification

6. If the block conforms the rules of the state machine it is approved

7. The block data is split between Ethereum and Avail DA for settlement.

The Code

The Stackr SDK, written in TypeScript, lets you inject the application logic directly into the blockchain. The developer only needs to define their state and state transition functions without worrying about any of the protocol heavy lifting of building a blockchain. Let’s see how:

• Defining the base state

Since the purpose of our application was to manage a football tournament, the app state needed to keep track of players, matches, events during a match, along with some other basic information about the tournament.

1. So as a starting point, we defined all entities as types in TypeScript.

The Stackr SDK adopts a schema-first design paradigm familiar to application developers. It allows complete freedom in terms of state design, allowing developers to simply think in terms of individual entities and how to compose them together to form the full application state.

• Adding handlers for state update

After we have defined our app’s state, we need to define State Transition Functions (STFs) that update the state. For our app, we could simply define one STF each for actions such as to start or end a match, record a goal or penalty, add or remove a player, etc.

2. We defined two functions, startMatch which sets the start time for a match, and logGoal which records a goal event in a match

Breaking down the startMatch function,

• The admin can submit an action to start a match providing the matchId.

• The STF verifies that the match is not already started and sets the startTime of the match to that of the current block timestamp.

Breaking down the logGoal function,

• The admin can submit an action to record a goal, referencing the related matchId and playerId.

• The STF verifies the inputs, updates the match’s score and records a new entry of type Log with action GOAL in the state.

Note: The actual implementation contains more state handlers than only the above two but are intentionally left out to keep this blogpost short and concise.

We’ve reached the point where our micro-rollup is ready (you: already!?).

• Interfacing with the micro-rollup using REST APIs

Another great DevEx unlock here is that the developers have complete freedom in how they wrap the micro-rollup, whether it’s through REST API, GraphQL, RPC, or any other method to expose interaction with the micro-rollup.

3. Ultimately, we exposed certain functionalities of the micro-rollup, such as submitting actions and retrieving its state, through simple REST APIs with Express.js:

Despite our rollup having many STFs, we consolidated them into a single POST endpoint to facilitate easier implementation on the frontend. Additionally, we implemented several GET endpoints that provide access to the micro-rollup’s state and meta information, including lists of STFs with their preferred schema and EIP-712 types. Hence, clients can make HTTP requests to these APIs to interact with the micro-rollup in a familiar manner. This greatly simplified the frontend integration while enhancing flexibility in leveraging the micro-rollup's capabilities.

Overall, our micro-rollup builds, feels and behaves like a regular web2 backend server. And yes, with Stackr, it is that easy to give on-chain superpowers to a backend server. Indeed, rollups are the new web servers.

Challenges faced during the tournament: Real-Time “Fork”

Things never seem to go smoothly in production, do they? Well, yes and no. On the bright side, the micro-rollup worked flawlessly with no bugs or errors. On the not-so-bright side, we totally missed the memo on having to manually manipulate state in a decentralized app. Classic. Well, story time!

Although it hasn't been discussed in the implementation above, there is a computeMatchFixtures function called at the start of the tournament and after each match to determine the next fixtures among the qualifying teams. When the tournament reached the semi-finals, the fixtures were computed, but two qualifying teams were not ready to play. This required reconfiguring the fixtures so the two teams already present could play each other first.

Given the immutable nature of a blockchain, this is an impossible task since the fixtures were already updated in the state with commitments settled on Ethereum and Avail DA.

Wat to do? We ended up performing a "Squash Fork," where we shut down the rollup and deployed a new instance, taking the latest state but with modified fixtures as the new genesis state. Since all involved parties agreed that the fixtures needed to be reconfigured and given that (again) micro-rollups are just backend services, it took only a few minutes for us to perform the Squash Fork, ensuring the tournament proceeded smoothly.

This incident highlights the importance of flexibility and sovereignty of micro-rollups in adapting to real-world scenarios. The sovereign nature of micro-rollups ensures that control over the rollup lies with the specific application, enabling quick decision-making and implementations. This flexibility is one of the key advantages of using micro-rollups, especially in dynamic environments where unforeseen changes may occur.

Full code for the MRU can be found here -

GitHub - stackrlabs/unification-cup: Micro-rollup for Unification Cup

Micro-rollup for Unification Cup. Contribute to stackrlabs/unification-cup development by creating an account on GitHub.

https://github.com

Questions & considerations

• Why does this application need to have any on-chain component at all in the first place — why require strict global consensus on who won a football tournament among a bunch of crypto degens?

  • A: You (may) have a valid point. However, consider the importance of having such solutions available for recording extremely high-stake historical or political events that affect the larger human civilization. Because in scenarios, when our institutions fail or a totalitarian state attempts to rewrite history, yes, the superpower of public blockchains like Ethereum is to provide strict global consensus and to serve as a reliable source of hardness enabling human coordination at scale.

• Ethereum roadmap includes history expiry and state expiry. Also, Data Availability layers do not guarantee that historical data will be permanently stored. Does this not defeat the purpose of ERs?

  • A: It is increasingly the view in the community that blockchains are not meant for storing data but rather for storing data commitments. As long as there is global consensus on the hash or digest of the data, it doesn't matter where this data is obtained from. This concept is central to rollups. In other words, there is clear incentive for centralized providers such as block explorers to provide access to archival data. Since rollups settle their state root to Ethereum (EVM state), which becomes part of the block header, you will always be able to verify whether the data obtained from a centralized provider is correct, maintaining the verifiability of data.

• Could ERs be useful for protocol workload balancing?

  • A: That’s an intriguing idea — using Ephemeral Rollups as a load-balancing mechanism, spinning them up on demand to manage traffic. To draw an analogy, just as micro-rollups function as micro-services for Web3 and Kubernetes provides auto-scaling for micro-services, exploring this concept for multi-nodal micro-rollups is certainly worth considering, though it may come with many challenges.

Conclusion

The implementation of the tournament application as an ephemeral rollup for use at the Avail Unification Cup during EthCC Brussels 2024 demonstrated their potential in being perfectly suited for efficient real-time real-world applications that offer the core guarantee of some summary or outcome being inscribed on-chain. With the state roots and transaction inputs set in stone on Ethereum (and Avail DA), anyone at any point in the future can verify the historical accuracy of this tournament’s events and outcome. Through this event, we were able to showcase how applications can be built as micro-rollups, providing a UX and DevEx comparable to traditional web2 apps while maintaining on-chain verifiability.

By combining the scalability and efficiency of off-chain execution runtimes with the security and immutability of on-chain data permanence, we foresee the applications of ephemeral rollups expanding across various domains, providing robust solutions for temporary yet critical use cases.

Interested in building your own Ephemeral Micro-Rollup?

At Stackr Labs, we’re building the toolkit and the necessary infrastructure to build app-specific micro-rollups to supercharge and unlock the DevEx around building apps that bridge the gap between Web2 and Web3. If you’re someone who’s looking to build a web3 application, we’d love to talk to you and find ways to collaborate.

Contact us on Discord (preferable), Twitter or shoot an email at gm[at]stackrlabs.xyz

The aim of this blogpost is to provide a high-level yet detailed deep dive into the concept of a Keystore Rollup, what problems does it solve, an example implementation of a Keystore Micro-Rollup while covering both the advantages and disadvantages of such an approach.

Why is a Keystore Rollup needed?

As part of the two of "The Three Transitions", the Ethereum ecosystem is encouraging users to migrate to rollups (L2s) for cheaper transactions and promoting the use of Smart Contract Wallets (SCW) for better security. As a result, a user is now required to deploy a smart contract account on every rollup they wish to transact on. Unlike Externally Owned Accounts (EOAs), which are stateless and function similarly on L1 and all L2s, a smart contract account holds state enabling features like key rotation, recovery, multi-sigs and more.

This is where lies the root of the problem: each rollup’s state is isolated from other rollups. If a user wishes to update her account state, such as adding or removing a signer from a multi-sig, this change needs to be synchronized across all her SCWs on all networks. This complexity is why many wallet providers are heavily tied to one network, leaving the user with no choice but to use separate wallets. Although some providers are developing modules to synchronize these changes to all networks for the user, but even that has significant difficulties in practice:

• Complexity: Building and submitting transactions, handling transaction failure, settlement or re-orgs across all networks is intricate.

• Cost: If rollups provide 10-100x cost savings compared to Ethereum, but a permission change needs propagation to 10-100 networks, we haven’t really saved anything on fees.

• Security: Urgent permission revoking changes, such as incase of a key becoming leaked, need to applied immediately but different networks have different block times, time to finality, censorship guarantees therefore leaving users vulnerable if changes are not applied promptly or left unapplied altogether.

Essentially, in an increasingly modular world where a user’s assets are spread across many rollups, using smart wallets becomes more challenging, and their advantages over EOAs, such as better UX and security, start to fade. Wat to do?

Keystore Rollup: A solution for cross-chain smart accounts

The fundamental idea behind a Keystore rollup is to concentrate account state in one rollup, the Keystore rollup, which can serve as the source of truth for all other rollups. All accounts, regardless of what other networks they need to transact on, refer to the Keystore Rollup to authenticate users. Instead of storing mutable permissions in the account smart contract on each rollup, an immutable link to a “virtual account” id is stored which points to the actual permission data on the Keystore Rollup. Hence, by providing a global repository for account permissions, Keystore Rollups can streamline account management for users.

Drawing an analogy to OAuth, a standard widely used in Web2 systems, the Keystore rollup functions as the Identity Provider (IdP), while all other rollups serve as Service Providers (SPs).

We can compare how such a construction addresses the shortcomings of current systems:

• Complexity: is reduced by removing the need to manage state across multiple networks and propagate duplicate transactions to make permission changes.

• Cost: is reduced by removing these duplicated transaction fees.

• Security: is improved by guaranteeing immediate application of removed permissions which automatically (implicitly) gets applied to all networks.

While this sounds promising, the subsequent sections delve into the existing approaches, implementation, and user stories of the Keystore Rollup revealing various drawbacks and considerations, which are discussed in depth at the end of this article.

Basic architecture of a Keystore Rollup

The basic architecture of a Keystore Rollup comprises several components:

1. Rollup node

2. Keystore Rollup Contract on L1

3. Keystore Contract on each L2

4. Keystore Account Factory on each L2

5. Validator Library and State Verification Library

Let’s briefly go over each of these one-by-one:

1. Rollup node

   The Keystore Rollup node maintains the state, has functionality for registering and updating accounts and generating proof for an account. It periodically rolls down its state root to the L1.

2. Keystore Rollup Contract on L1

   The Keystore Rollup Contract on L1 stores the state root and sends messages to L2 contracts to update their state root variable.

3. Keystore Contract on each L2

   The Keystore Contract on each L2 also stores the state root for direct read-access by Smart Contract Wallets (SCWs) on that L2.

4. Keystore Account Factory on each L2

   The Keystore Account Factory on each L2 is responsible for creating SCWs deterministically. These SCWs point to the unique key of the Keystore Rollup, allowing users to authenticate across all networks with the same key.

5. Validator Library and the State Verification Library

   These are included with the SCW on each L2. Validator Library verifies the validity of transaction signature against the SCW config, while the State Verification Library verifies the user-provided proof against the state root of the Keystore Rollup.

Existing approaches

While the basic architecture discussed above remains the same across different approaches, deciding on a proof scheme is a crucial detail that impacts the complexity of implementation and costs for users in how data (and its proofs) are communicated cross-chain.

The following is a comparative analysis of a figure taken from Vitalik’s blog on Deeper dive on cross-L2 reading for wallets and other use cases which mentions different approaches for proof schemes:

While the merkle tree model is not the most cost effective for the user, they are widely used everywhere in Web3 with a large amount of available tooling. For the sake of simplicity, we will implement a merkle tree model since that is the default proofing mechanism employed by Stackr Micro-Rollups as well.

Quick Primer on Micro-Rollups

In oversimplification, micro-rollups are essentially state machines at the core.

• The state machine has a defined shape of the state & the genesis state.

• The state machine has actions(read: transaction types) which when invoked trigger a state transition function on the machine.

• The State Transition Function(STF) in effect performs computation and mutates the state of the machine.

After the STF execution, the actions are rolled together in a block & shipped to Vulcan(Stackr’s Verification Middleware).

Finally, Vulcan —

1. Pessimistically re-executes the actions in the block to check for validity of the STF.

2. Settles on L1 & DA.

   1. Micro-Rollup’s updated state is sent to the DA.

   2. The metadata of the verified block & the updated state root is settled to the micro-rollup’s inbox contract on L1.

The above pipeline collectively forms Stackr’s Micro-Rollup Framework.

Keystore 🤝 Micro-Rollup

So, why are micro-rollups uniquely suited to build a keystore?

1. Micro-rollups enable specialized minimal VMs

   In the original proposal for a dedicated minimal rollup for keystores, Vitalik advocates for a simple implementation without a full EVM for reduced security risk. Micro-Rollups lets you selectively expose only necessary functionality through deterministic and rigid State Transition Functions (STFs) tailored to the state of the rollup, significantly reducing the attack surface area.

2. Micro-rollups are flexible sovereign systems

   Since micro-rollups break free from the shackles of the EVM, it’s trivial to add support for different signature schemes for sending transactions to the micro-rollup. In context of a keystore rollup, this could translate to supporting transactions signed using passkeys, multi-sigs, etc.

Let’s build a Keystore Micro-Rollup

Disclaimer: This demonstration showcases the framework's capabilities and represents a preliminary proof of concept.

When developing a micro-rollup, it's crucial to conceptualize your logic in terms of a state machine. This involves carefully considering the state of the micro-rollup - that is, the data it will hold - and the actions that will dictate the behavior of the state transition function, which in turn operates on this state.

With the above in mind, we start by designing the state of the micro-rollup using Stackr’s SDK.

The Design

1. Accounts are stored off-chain inside a state machine as a key-value map

2. User sends actions which trigger a state transition function inside the state machine

3. User can send action to register a new account or update an account

4. After each set epoch a block is generated which contains details of accounts state

5. The block is sent to Vulcan network for verification

6. If the block conforms the rules of the state machine it is approved

7. The block data is split between L1 and DA for settlement.

Quick Demo before diving into the implementation details

Implementation using the Stackr SDK

The Stackr SDK, written in TypeScript, lets you inject the application logic directly into the blockchain. This environment delivers a developer experience akin to traditional server-side or backend application development. Let’s see how:

1. As a starting point, let’s define accounts in our state.

Bear with us, these fields are explained in the next section.

After we setup our minimum viable state, we need to define state transition functions that update the state.

2. Let’s define two functions, register which is responsible for registering a new account with the keystore, and update which is responsible for updating an existing account entry.

Breaking down the register function,

• The user submits an action to register a new account, providing two fields (ideally generated by the user’s wallet):

  • codeHash: hash of the smart contract’s bytecode of the validation library

  • configHash: hash of the SCW config (could be a public key or in the case of a multisig a concatenation of multiple public keys)

• Together this makes up the data i.e.,data = hash([codeHash, configHash])

• vk: verification key that specifies instructions for changing the data and vk. In this case, it’s the address who initiates the action but it could be different depending on the type of approach.

• key = hash([data,vk]): this key serves as the unique “virtual account” id and returned to the user.

• Finally, the new account entry is added to the state against this key, accounts[key] = (data, vk).

Breaking down the update function,

• The user submits an action to update an existing account, referencing the related key among other fields they wish to update. While it may not be immediately obvious, update functionality is crucial to enable security-critical features like recovery or changing signers.

• The address initiating the action must match the current vk.

• Finally, account entry at accounts[key] is updated with the new values.

3. Ultimately, we define how the state root is computed for L1 settlement.

As mentioned at the beginning, micro-rollup’s state root is settled on L1. It is interesting to note that the developer can chose what part of the state settles on L1 vs what part can go on DA as metadata, thereby, unlocking hybrid security assumptions.

In this case, we extract the accounts and settle it’s merklized root on L1, thereby opening up the possibility of direct inclusion proofs of accounts in the merkle tree.

We’ve reached the point where the minimum viable system works. Surprisingly easy to give on-chain superpowers to a backend server, no?

Note: The contracts side of code is intentionally omitted as out of scope for this article. It is well discussed in Conner’s Solidity Account circuits blog post. Although that is an approach for ZK-SNARK based proof scheme, the Validator Library and State Verification Library remains similar for this type of system too.

What does using this Keystore Micro-Rollup look like?

There are two primary user stories here:

1. User registering a keystore account

2. User sending a transaction on an L2 referencing their keystore account

Breaking these down,

1. User can register an account with the Keystore Micro-Rollup. As described in the previous section, this would involve their wallet provider generating the codeHash and configHash and passing it onto the keystore. The wallet provider also deploys a new SCW KeyStoreAccount (bundled with the Validator Library and State Verification Library) using the KeystoreAccountFactory on each L2 the user wishes to transact on. This SCW simply stores a pointer to the immutable account key returned by the Keystore micro-rollup, which can be later used for lookups in the keystore during verification.

2. When submitting a transaction on any L2, the user would first need to obtain a proof (in this case, a merkle proof) for their account from the Keystore Micro-Rollup. The wallet provider would essentially need to construct a User Operation, baking in the merkleProof, SCW config, and codeHash into its signature, like so: userOp.signature = abi.encode(codeHash, userOpSig, config, merkleProof). This will later be decoded inside the SCW at which point it will leverage the Validator Library to verify the validity of transaction signature against the SCW config, and the State Verification Library to verify the user-provided merkle proof against the state root stored in the Keystore Contract on that L2. If both checks pass, the user’s transaction is authenticated.

An interesting thing to note here is that since each (data, vk) pair corresponds to a unique key in the Keystore, the SCW need not be deployed immediately on all L2s but the user can still obtain a counterfactual address. This is a deterministic address for a smart contract that hasn't been deployed yet, but can still be used to receive funds on any chain at the same address

Questions & considerations

• Can I migrate my existing SCW to a keystore rollup?

  • A: There is no spec that enables an existing SCW to “register” with the keystore. In all the approaches, user will deploy new SCW after registering a key with the keystore first. This is an essential feature to have though and requires further discussions within the community.

• What does it mean that the L2 “requires” a proof?

  • A: Since the user’s account state is no longer on the L2s they may be transacting with but externalized on the keystore rollup, the L2 requires the relevant account state to be submitted alongside that account key’s inclusion proof for verifying the integrity of a transaction.

• Aren’t the transactions going to be more expensive as there is more metadata?

  • A: Yes. With a keystore rollup, each user-op is packed with extra metadata (config, codeHash, proof) while also requiring extra on-chain compute for the verification of the proof. This incurs additional gas fees in both calldata and computation. As Merkle Tree of accounts grows, the size of the proof becomes larger and will cost more gas fees.

• What about latency between the proof creation and proof verification?

  • A: Yes, latency issues persists for all approaches and in both directions. It’s possible that the proof obtained by the user is no longer valid by the time it is verified onchain as the state root stored in the keystore contract got updated in the meantime. On the other hand, the user might have obtained a proof for a state which is not yet synced with the L1 and all L2s.

• What about the cost of syncing the state root across all L2s?

  • A: Yes, in this approach one transaction is required for message transfer to each L2 which could incur significant cost. This is because we rely on the messaging protocol of each L2 since there is no standardized way to read L1 state on L2s.

• What if the keystore rollup censors me?

  • A: We see two paths here. Firstly, the rollup should allow force-inclusion of transactions directly from the L1 so the user can always update their account. Secondly, as long as the rollup guarantees publishing all its data to a Data Availability (DA) layer the user should be able to construct a proof without relying on the rollup operator.

• What if the keystore rollup re-orgs?

  • A: Ideally the keystore rollup would keep an appropriate buffer of block confirmations to hang back before solidfying a state root as official and generating proofs against it. This feeds back into the latency issues and depletes UX.

• What kinds of wallet configurations and signing methods can it support?

  • A: The general idea is to support all and any kind of signing methods as long as it can be implemented in the EVM. That is why the keystore rollup doesn’t assume anything and accepts arbitrary variables, namely, codeHash and configHash, which lets the developer write unique and custom signature verifications methods in the Validator Library. The possibilites are endless: multisigs, passkeys, rotating session keys, signing methods with aggregation like BLS or EdDSA, ZK Email, ZK-SNARKs, Quantum safe signing method like Winternitz Signatures, and more.

Conclusion

Keystore Rollups offer a promising solution for managing smart contract wallets across networks by centralizing account states on a dedicated rollup. At first glance, they seem to simplify permission management, reduce complexity, cut costs, and enhance security. However, as we delve deeper, we see that they are not without their own challenges, particularly related to costs and latency issues.

Being a complimentary feature to a more Chain Abstracted future of seamless cross-chain interaction, ideas like Keystore Rollup play a crucial role in paving a path to a more scalable, secure, and user-friendly Ethereum ecosystem. As developers and researchers, we must strive to explore and experiment with such ideas.

References

• https://vitalik.eth.limo/general/2023/06/09/three_transitions.html

• https://vitalik.eth.limo/general/2023/06/20/deeperdive.html

• https://notes.ethereum.org/@vbuterin/minimal_keystore_rollup

• https://hackmd.io/@mdehoog/mksr#Account-circuit

• https://hackmd.io/@ilikesymmetry/intro-keystore-rollup

• https://hackmd.io/@ilikesymmetry/solidity-account-circuits

• https://hackmd.io/@haichen/keystore#Wallet-Example

Interested in building your own Keystore?

We will soon be sharing a more “complete” version of the above mentioned experiment. Until then, if you’re someone who’s looking to build a Keystore Rollup for your protocol, we’d love to talk to you and find ways to collaborate.

Meanwhile - beta access to our SDK is still open, head over to the application form and sign-up. We are letting developers in on a rolling basis.

Contact us on Discord (preferable), Twitter or shoot an email at gm[at]stackrlabs.xyz

And, that’s how the Micro-Rollup Playground was birthed!

The Playground is primarily a dev tool, which provides a full-featured interface to interact with your MRU, view actions processed, blocks formed, granular finality of each action, and enables action-by-action state rewind, all inside the developers’ browser.

Feature Highlight

The team at Stackr has put together the Playground with a lot of passion and love. We’d like to showcase a few features that we think are a stand-out compared to the other dev tooling available in the ecosystem

MRU Interface

Developers can directly interact with their micro-rollup and send actions through the Playground interface.

The Playground picks up all the defined state transition functions and the action schemas and provides a visual way to interact with your Rollup after connecting your favorite wallet to it.

This feature solves a major pain point of developers building micro-rollups around interacting with the rollup for testing and significantly improves the feedback loop between implementing the business logic and checking that it’s working as it’s supposed to.

Tiered Confirmation Levels

At the heart of micro-rollups is the concept of tiered confirmations. Through the lifecycle of an action, you have several different confirmation levels which the developers can utilise to build flexible experiences, optimised for their use-case.

The smooth animation on the Playground depicts the confirmation level of an action in real time

State Rewind

As micro-rollups have a state machine at its core, each action sent to the micro-rollup effects a state transition function which may produce a new state for the machine. It’s only logical that developers are able to inspect the state of the state machine, action-by-action.

And many other cool features…

Fun fact!

Playground is the first plugin in the Stackr ecosystem! More useful tools are expected to be added to Stackr’s Plugin suite in the future. 🤝

How to set it up?

Head over to the docs for instructions on how to setup the Playground Plugin with your micro-rollup.

Conclusion

The Playground is only the beginning of making micro-rollup development as intuitive as possible. It provides a glimpse into the future of blockchain app development. With the Stackr SDK and the Playground, developers have robust tools to build innovative use-cases for single-app rollups and push the boundaries of the crypto ecosystem.

The Future

This is just step 1 into our vision of redesigning block explorers in a app-specific world. The Playground is just a developer tool and helps ease the micro-rollup development process. In world of multiple micro-rollups we would need a much bigger and a more versatile explorer that can not only display data per MRU but also provide ways to interact with it.

Stay tuned as we have big plans for that as well

If you're interested in trying out the Playground, apply for beta access to the Stackr SDK through the sign-up form!

So let’s try to define it. Attestations, in essence, are statements or claims made about some piece of information. They serve as evidence or confirmation provided by a trusted party, validating the truthfulness of a particular claim. The credibility of an attestation hinges on the reputation of the entity making it. In the world of Web3, attestations carry digital signatures ensuring authenticity and immutability.

Let's take a look at examples of attestations — in the real world as well as in crypto — that you may not have even realized are basically attestations in one of its many forms.

Attestations in Web3: Enter Ethereum Attestation Service

Ethereum Attestation Service (EAS) is one of the leading projects enabling attestation use-cases in Web3. EAS is an open-source infrastructure public good for making attestations on-chain or off-chain. It works on a simple primitive — you simply register a schema (or use an existing one) about any topic and make attestations referencing that schema.

Limitations

While EAS provides a solid foundation for reasoning about and utilizing attestations in Web3, it is not without its limitations. Using EAS for on-chain attestations can be cost-prohibitive and requires writing EVM smart contracts for any custom logic. For off-chain attestations, the schema still needs to be on-chain, and developers often store these attestations in private databases, compromising user verifiability.

This situation underscores how micro-rollups built using the Stackr SDK can be used to supercharge the capabilities of EAS or attestations, in general.

Quick Primer on Micro-Rollups

Micro-rollups are essentially state machines that executes certain logic off-chain and then outsource the verification of the execution to another layer, which we call “Vulcan” that verifies the state updates and pushes the compute data on-chain.

• The state machine has a defined shape of the state and is initialized with a genesis condition.

• The state machine has actions(read: transaction types) which when invoked trigger a state transition function on the machine.

• The State Transition Function(STF) in effect performs computation and mutates the state of the machine.

After the STF execution, the actions are rolled together in a block & shipped to Vulcan.

Finally, Vulcan —

1. Pessimistically re-executes the actions in the block to check for validity of the STF

2. Generates metadata for the verified block

3. Settles on L1 & DA.

   1. Micro-Rollup’s updated state is sent to the DA.

   2. The metadata of the verified block & the updated state root is settled to the micro-rollup’s inbox contract on L1.

The above pipeline collectively forms Stackr’s Micro-Rollup Framework.

Attestations System 🤝 Micro-Rollup

So, why are micro-rollups uniquely suited to build attestation systems?

1. Micro-rollups enable verifiable off-chain compute

   Micro-rollups are indistinguishable from backend services but adds a layer of verifiability to the state of the app and the compute.

2. Micro-rollups make the state auditable

   Once the state machines are deployed, the STF logic cannot be mutated. This enables the users to have an assurance that the provider has not arbitrarily changed the rules of the system.

3. Micro-rollups can compose with on-chain apps!

   Micro-rollups settle the state root of the app to the L1. This state root could be a Merkle Root and can be used by other apps to provably access the state of the rollup.

Three ways in which Micro-rollups can be used for Attestations

1. Verifiable Storage for EAS off-chain attestations

As highlighted above, an EAS off-chain attestation is just a JSON of attestation data plus a signature. This is not stored on-chain but in private databases or decentralized storage solutions.

In a fashion very similar to the “Verifiable Data Ledger by Ceramic Network” recommended by EAS, a micro-rollup is an ideal solution to store these off-chain attestations. Essentially, a micro-rollup is a verifiable data ledger since:

• verifiable compute ensures correct state transitions.

• the state is “rolled-up” into a hash (read: merkelized) which is posted on Ethereum L1 after each set epoch.

• all data is made available to the underlying DA layer.

Such a system would be a generalized micro-rollup designed to store attestations against any schema already registered on EAS without compromising ease-of-verifiability for the end user.

2. Micro-rollup for schema-specific attestations

At its core, a micro-rollup is simply a state machine comprising of a state and state transition functions. When examining this framework through the lens of schema and attestations, parallels emerge. The state, akin to a schema, defines the data structure, while attestations, akin to state transitions, serve as verified updates that adhere to the schema. This comparison highlights the true potential of micro-rollups: individual micro-rollups can be built tailoring attestations to specific schemas, granting developers the flexibility to incorporate custom logic into transition functions, similar to Resolver contracts in EAS. What makes such a construction even better is that the user making the attestation would incur no gas costs since the computation is done completely off-chain outside the EVM.

Our recent article on Micro Rollups for Points Systems, which talked about points being employed as an incentivization mechanism by applications, is a direct example of such a system as points are essentially attestations bestowed by an application to its users.

Someone could also write a wrapper built on Stackr’s SDK to easily launch a new micro-rollup with custom schema and resolver logic while keeping the same API for cross micro-rollups interoperability.

3. Micro-Rollup as an improvement to EAS

Since micro-rollups abstract away most complexities of building decentralized applications, a near feature-complete alternative to EAS can be implemented as a micro-rollup pretty quickly. This alternative can provide the same three core functions:

• A schema registry for storing all schemas.

• The ability to create an attestation against a schema.

• The option to revoke an existing attestation.

In the following section, we'll delve deeper into how to build this.

Let’s build EAS as a Micro-Rollup

Disclaimer: This demonstration showcases the framework's capabilities and represents an incomplete build not intended for production use. Please regard the content as illustrative and not as a finalized product.

When developing a micro-rollup, it's crucial to conceptualize your logic in terms of a state machine. This involves carefully considering the state of the micro-rollup - that is, the data it will hold - and the actions that will dictate the behavior of the state transition function, which in turn operates on this state.

With the above in mind, we start by designing the state of the micro-rollup using Stackr’s SDK.

The Design

• Schemas and attestations are stored off-chain inside a state machine

• User sends actions which trigger a state transition function inside the state machine

• User can send action to register a schema, make attestation referencing any of the stored schemas, or revoke an existing attestation

• After each set epoch a block is generated which contains details of schemas and attestations state

• The block is sent to Vulcan network for verification

• If the block conforms the rules of the state machine it is approved

• The block data is split between L1 and DA for settlement.

Defining the base state

Similar to EAS, we need to store a list of schemas and attestations. To illustrate this clearly and provide a stark comparison, we're using the same struct definitions used by EAS.

1.As a starting point, let’s define schemas and attestations in our state.

Breaking this down,

• schemas: stores a mapping of schema UID to SchemaRecord structs where SchemaRecord corresponds to an attestation schema submitted by a user.

• attestations: stores a mapping of attestation UID to Attestation structs where Attestation corresponds to an individual attestation made referencing a schema.

Adding handlers for state update

After we setup our minimum viable state, we need to define state transition functions that update the state.

2. Let’s define two functions, registerSchema which is responsible for creating a schema entry, and attest which is responsible for creating an attestation entry.

Breaking down the registerSchema function,

• The user submits an action to register a new attestation schema, providing two fields: schema (the ABI) and revocable (whether the schema explicitly allows revocations).

• The user who initiates the action is recorded as the schema registerer.

• The state transition function calculates a unique identifier for this schema entry based on the provided values.

• Finally, the new schema entry is added to the state.

Breaking down the attest function,

• The user submits an action to create a new attestation, referencing the related schemaUID among other fields.

• The user who initiates the action is recorded as the attester.

• The state transition function calculates a unique identifier for this attestation entry based on the provided values.

• The state transition function verifies the incoming attestation data against the related schema’s ABI (out of scope for this article).

• Finally, the new attestation entry is added to the state.

We’ve reached the point where the minimum viable system works.

Smart Contracts vs Micro-rollup

To get all the attestations made to a schema or sent by one address, we would need to iterate over all the attestation entries and this has to be repeated each time we want to perform such lookups.

To mitigate this, EAS implements an Indexer.sol smart contract specifically to index the values in several mapping variables. However, this incurs extra gas costs as storage is extremely expensive inside the EVM compared to a micro-rollup.

But since we’re building a micro-rollup, we can be more liberal with the state and compute to prioritise user experience over cost.

Adding index fields for efficient lookups

3. Adding schemaAttestations to the state.

It’ll be tasked to maintain a mapping between a schema and its attestations.

Accordingly, we update the attest function also to update the mapping for the schema when a new attestation is added.

Voila!

And it’s that simple to build an attestations system akin to Ethereum Attestation Service with on-chain traceability! Surprisingly easy to give on-chain superpowers to a backend server, no?

Off-chain Attestations brought on-chain → Real-world use-cases and more ✨

In the world of Web3, attestations are essential for enabling most real-world use cases. They bridge the gap between Web2 and real-life identity to Web3, preserving distributed trust.

The beauty of the above system is that it allows attestations to seamlessly be used on-chain without severe overhead.

As mentioned at the beginning, micro-rollup’s state root is settled on L1. It is interesting to note that the developer can chose what part of the state settles on L1 vs what part can go on DA as metadata, thereby, unlocking hybrid security assumptions.

In this case, if we extract the attestations and settle it’s merklized root on L1, we open up the possibility of direct inclusion proofs of attestations in the merkle tree.

This property unlocks on-chain verification of identity, proof of ownership, and access to various services and benefits. For instance, JP Morgan recently used Verifiable Credential, a form of attestation, to execute its first DeFi transaction on a public blockchain. When attestation data is brought on-chain with inclusion proofs, the potential for on-chain real-world use-cases explode.

This approach brings attestations on-chain without the attestations having to be strictly on-chain! (And for significantly cheaper with superior user experience)

Conclusion

Though attestations may seem like a new primitive in Web3, they have always been a part of what we perceive as Trust Experience. They are crucial in bringing real-world identities and assets on-chain, which contributes directly to the legitimacy of blockchains. Essentially, attestations are just another tool for human coordination. With this mental model in place, only one question remains: how do we coordinate at webscale?

Micro-rollups, with their verifiable and fast off-chain compute, auditable state, and ability to compose with on-chain apps, provide an ideal framework for building robust attestation systems and, in turn, coordination mechanisms.

We are only just getting started bridging the gap between Web2 and Web3.

Interested in building your own Attestations Infra?

We will soon be sharing a more “complete” version of the above mentioned experiment. Until then, if you’re someone who’s looking to build an Attestations System for your protocol or building tooling for attestations, we’d love to talk to you and find ways to collaborate.

Contact us on Discord (preferable), Twitter or shoot an email at gm[at]stackrlabs.xyz

This Private Beta is a significant step towards achieving our vision of making blockchain app development simpler by providing the necessary tools and introducing the paradigm of building your apps as rollups, or “single-app rollups” in other words. During this phase, we will be giving access to a select group of developers, allowing them to explore the world of micro-rollups and test the limits of the Stackr SDK.

We aim to gather feedback, encourage users to identify issues, and suggest improvements to refine and enhance the platform.

At the end of this post, we’ve added instructions on how you can apply for access to the Stackr SDK. For now, let’s dive into what you can build with micro-rollups!

Building with the Stackr SDK ⚒️

Disclaimer: The SDK currently is highly experimental and we do not recommend it for production use as of this phase of Private Beta.

The SDK lets developers easily build micro-rollups using TypeScript. Micro-Rollups are self-hosted off-chain services that maintain their state, accept actions to generate a new state based on incoming requests, and transmit blocks to Stackr’s Verification Layer for checking correctness and eventually settlement and data availability on parent chain. This aligns with what you would want out of a crypto-powered backend framework.

What to build on micro-rollups?

Anything that could be built with smart-contracts could be built better with a combination of smart contracts and micro-rollups. The idea that micro-rollups enable verifiable off-chain compute unlocks a multitude of use-cases that were not possible or were too unoptimized to be done fully on-chain.

The team has curated and categorised a list of ideas and verticals where we think interesting use-cases of micro-rollups are waiting to be discovered and built!

Peruse the list and reach out to us if you’re exploring a similar use-case.

1. On-chain apps

   1. Payments

      1. Transfers

      2. Streaming

      3. Micro-payments (smol money)

   2. Frames

      • Games

      • P2P Swaps

      • Verifiable Polls

      • Token Distribution

      • Prediction Market

   3. Games

      1. Simulation Engines

      2. Autonomous worlds

      3. In-game assets

   4. DeFi protocols

      1. Lending/Borrowing

      2. DEX / Orderbooks

      3. LST

      4. Airdrops

      5. Prediction Markets

   5. NFT protocols

   6. DAOs and Governance

2. On-chain Infrastructure

   1. Identity

   2. Programmable VMs

   3. AVS frameworks

   4. Oracles

   5. Shared Sequencers

   6. Account Abstraction and Intents

      • Solver Marketplace

      • Decentralised Bundler

      • Unified Mem-pool

   7. Attestations

      • Reputation Systems

      • Points Systems

      • Engagement score on social graphs.

      • Credit score for DeFi

   8. Two sided Marketplaces

   9. Social graphs

   10. Reputation Engine

   11. Social Media Protocols

   12. On-chain Agents

   13. AI/ML use-cases

3. DePIN

   1. dRPC

   2. Storage

   3. Compute

   4. IoT

   5. Indexers

The only limit is your imagination 💭

How to get access?

Developers can apply for access to the SDK through the link below

👉🏻 Beta Access Form

The team will periodically review all requests and approve access for the selected few developers. The approved developers will have to mint the Beta Access Pass on Sepolia to be able to create a micro-rollup.

In the meantime, we recommend developers to go through the docs and understand the system.

Conclusion

We’re thrilled to be kicking-off the Private Beta! The team has worked incredibly hard, seven days a week, to bring this to life and get the SDK in to the hands of the developers. The Stackr Stack is a work in progress and we’re continuously making improvements and thinking through the next steps of what’s required to make it the best tooling in the ecosystem to build applications.

For any queries, join the community on Discord, Telegram or Twitter or shoot an email at gm[at]stackrlabs.xyz

Many protocols employ points as an initial step before introducing the protocol's governance token, indicating that the distribution of tokens will be based on the number of points a user accumulates. This strategy allows protocols and teams to gain valuable time before they need to unveil the specifics of their token, also delaying the inevitable scrutiny in case they mess up. Accumulating points functions similarly to yield farming but without the direct financial incentive, offering a more generalized approach to user engagement and reward.

It has now become the latest meta to incentivise users & grow the protocol. And the fun part is, points are theoretically infinite supply, adding a twist to the conventional airdrop mechanism and differentiating it with actual tokens.

Problems with Points

PMF should not stand for Points Market Fit. If a product isn't getting used without points, it's pointless to slap a point system on top of it and call it PMF. Points should not serve as the decisive factor for choosing product X over Y; rather, both products X and Y should offer inherent value to the user.

The next biggest problem is the fact that most point systems are black boxes, and specifically black boxes with unpredictable computation properties over time. This opacity has its advantages and disadvantages - it grants teams greater flexibility to adjust the system's rules, yet it simultaneously strips users of any sense of control or influence.

The rules of the game to accrue XP (read: points) should be clear and predictable!

What if points were auditable, transparent, and predictable — while still being flexible for teams to design campaigns around?

On-Chain Points

The idea of implementing points on-chain presents an intriguing concept, yet it should not merely serve as a facade for another ERC-20 token. There have been instances where protocols introduced a pre-release token, promising its eventual conversion into a different token (basically points in disguise) but littering the ecosystem with redundant tokens.

Envisioning on-chain points as distinct from ERC-20 tokens opens up the possibility for unique experiences through the composability of different point systems. However, the reality that both Layer-1 and Layer-2 solutions are cost-prohibitive for implementing an on-chain points tracking system raises a critical question: why not simply use an ERC-20 token to represent points?

This situation underscores why an on-chain points system is an ideal candidate for development as a micro-rollup on Stackr.

Looking at the problems with the current infra used to run point systems, the team pulled a night long internal research sprint and what has emerged is a specialised VM to track & manage points for your protocol.

Quick Primer on Micro-Rollups

Micro-rollups are essentially state machines that executes certain logic off-chain and then outsource the verification of the execution to another layer, which we call “Vulcan” that verifies the state updates and pushes the compute data on-chain.

• The state machine has a defined shape of the state and is initialized with a genesis condition.

• The state machine has actions(read: transaction types) which when invoked trigger a state transition function on the machine.

• The State Transition Function(STF) in effect performs computation and mutates the state of the machine.

After the STF execution, the actions are rolled together in a block & shipped to Vulcan.

Finally, Vulcan —

1. Pessimistically re-executes the actions in the block to check for validity of the STF

2. Generates metadata for the verified block

3. Settles on L1 & DA.

   1. Micro-Rollup’s updated state is sent to the DA.

   2. The metadata of the verified block & the updated state root is settled to the micro-rollup’s inbox contract on L1.

The above pipeline collectively forms Stackr’s Micro-Rollup Framework.

Points System 🤝 Micro-Rollup

So, why are micro-rollups uniquely suited to build point systems?

1. Micro-rollups are fast, flexible, self-hosted execution environments

   This ensures that the delivery of points does not incur “on-chain” overhead and all the state updates happen as fast as possible.

2. Micro-rollups enable verifiable off-chain compute

   Despite being self hosted, the framework ensures that any data that enters the system and mutates the state can be fully verified before the data settles on L1. This ensures that the system is running predictably and not being tampered with.

3. Micro-rollups make the state auditable

   Once the state machines are deployed, the STF logic cannot be mutated. This enables the users to have an assurance that the provider has not arbitrarily changed the rules of the system.

4. Micro-rollups can directly settle on L1

   Since micro-rollups can settle directly on an L1, the state proofs can be consumed directly inside contracts to take on-chain actions. The verifier layer ensures that the settlement period is greatly reduced by providing pre-settlement guarantees.

Lets build the Points System

Disclaimer: This demonstration showcases the framework's capabilities and represents a highly unoptimized build not intended for production use. Please regard the content as illustrative and not as a finalized product.

When developing a micro-rollup, it's crucial to conceptualize your logic in terms of a state machine. This involves carefully considering the state of the micro-rollup - that is, the data it will hold - and the actions that will dictate the behavior of the state transition function, which in turn operates on this state.

With the above in mind, we start by designing the state of the micro-rollup using Stackr’s SDK

The Design

• Events are triggered when a user performs an off-chain or on-chain action on a platform. Events can also be assigned to a user by the admin

• Points are stored off-chain inside a state machine

• The system holds a state transition function that determines when and how much points are granted to the user

• Events trigger the state transition functions and the state is updated with the user’s new points

• After every set epoch a block is generated which contains details of user events and updated points table state

• The block is sent to Vulcan network for verification

• If the block conforms the rules of the state machine it is approved

• The block data is split between L1 and DA for settlement

Defining the base state

1. As a starting point, we add admins and an eventRegistry

• admins : Addresses which can register an event entity and also assign points for users

• event : Any kind of entity that the user can receive points for. It could be an on-chain event or a custom manually added entity. eg : “sign-up” (custom) can give them 200 points, “swap” (on-chain) can give them 500 points and so on.

2. Next up, we need a way to track the events of the users which they are eligible for points.

So a user may have 1 sign-up and 5 swaps. Each event is an entry in the eventLog

We added an eventLog to the state to keep track of all the on-chain events that have been tracked for a user and the max points corresponding to them for each. We at the moment do not need the points subfield as it can be fetched from the eventRegistry, but we add it nonetheless to keep the system flexible for further development.

Adding a handler for state update

After we setup our minimum viable state, we need to define reducers that update the state.

3. Let’s add a logEventReducer which is responsible for creating a log entry for an event for a user

Breaking down the above

• Admin calls a logEvent action (out of scope for this article) with the name of the event and identifier of the user.

• The action hits the stateMachine and triggers logEventReducer

• The reducer then →

  • Finds the points corresponding to the event.

  • Updates the event log for the user with the event and the corresponding points.

For example —

• Admin calls logEvent({user: mg-labs.eth, event: "deposit"})

• The reducer would then find the deposit action in the eventRegistry and log the event for mg-labs.eth along with the points corresponding to the deposit event.

We’ve reached the point where the minimum viable system works.

Smart Contracts vs Micro-rollup

To calculate the total points of a user, we would need to iterate over the event logs for the user and this has to be repeated each time we want to fetch the total points of the user.

Now, that could be a viable approach if you were building a points system as a smart contract because storage is extremely expensive inside the EVM compared to a micro-rollup.

But since we’re building a micro-rollup, we can be more liberal with the state and compute to prioritise user experience over cost.

Storing the computed points

4. Adding userPoints to the state.

It’ll be tasked to keep the sum of the points allocated to a user.

We update the logEventReducer to also update the points for the user when an event is logged.

Done!

And it’s that simple to build an event-driven point system with on-chain traceability! Surprisingly easy to give on-chain superpowers to a backend server no?

Off-chain Points brought on-chain → Airdrops and more ✨

The beauty of this system is that it allows points to seamlessly be used on-chain without severe overhead.

As mentioned at the beginning, micro-rollup’s state root is settled on L1, It is interesting to note that the developer can chose what part of the state settles on L1 vs what part can go on DA as metadata, thereby, unlocking hybrid security assumptions.

In this case, if we extract the userPoints and settle it’s merklized root on L1, we open up the possibility of direct inclusion proofs of users in the merkle tree.

This property would let us seamlessly build on-chain experiences for trust-less token redemptions, rewards against points, on-chain secondary market for points, etc. By getting user points data on-chain with inclusion proofs the possibility of on-chain experiences explode

This approach brings points on-chain without the points having to be strictly on-chain! (And for significantly cheaper with superior user experience)

Musings

The Point System we’ve built so far in this post is just the tip of the iceberg and can be significantly expanded to build a wealth of features. Some of them could be as follows:

Multipliers

Teams love to play with time-bound multipliers on the baseline points for certain events or campaigns as it’s a beautiful mechanism to collaborate with other projects, increase activity in the community and the protocol, etc.

With this version of the Points System, it’s trivial to iterate and implement multipliers as we were already storing the points that are to be allocated for the event at that specific time.

First, we update the EventRegistry to hold a list of multipliers for each event.

As you’ll notice above, it’s a list of multipliers per event which can be activated and deactivated by the team to achieve interesting campaign design.

To take the above state update into account, we update logEventReducer to apply active multipliers.

The above logic not only applies a multiplier but also stacks multiple multipliers for the event when calculating the amount of points to allocate.

Referrals

Similar to multipliers, referrals are key to several point systems. Referral systems are hard to build completely on-chain as they can get quite complex in their structure.

For example, MarginFi has a multi-level referral system —

Building points system as micro-rollup gives you the freedom to implement the above mechanisms, as complicated as they maybe, in your own sovereign execution environment.

Points Automation

The system discussed above allows for a lot of flexibility, but also requires additional infra as overhead on the admin (or bots) to update the user points.

One could increase the autonomy of the system by piping in all the user events from selected contracts to the micro-rollup through the L1Syncer (Inbuilt module inside the SDK) and the state transition function of the rollup being purely the algorithm to compute the points for the users with transparency on how the points are calculated.

Points as Reputation

Points can easily be thought of as XP or reputation points in a social economy.

They serve as a form of recognition for contributing value to a protocol or product. The potential for creating on-chain experiences using the Points System as a reputation tracker in a social economy is vast and filled with exciting possibilities for engagement and innovation.

For example, Reddit’s Karma Points built on a micro-rollup could instantly make the “useless internet points,” as they like to call it, useable on-chain.

Using this framework, it is probably a few days of work to port over the existing karma point system to bring it on-chain.

Conclusion

The Points System represents a compelling use case situated at the crossroads of Web2 and Web3, warranting a novel hybrid architecture. This is precisely the opportunity provided by micro-rollups.

Micro-rollups offer the flexibility to choose your position on the decentralization spectrum. They empower builders to construct applications according to their preferences, whether that entails full decentralization, sufficient decentralization, or a secret third thing yet to be unlocked.

Interested in building your own Points Infra?

We will soon be sharing a more “complete” version of the above mentioned experiment. Until then, if you’re someone who’s looking to build a Points System for your protocol or building tooling for points, we’d love to talk to you and find ways to collaborate.

Contact us on Discord (preferable), Twitter or shoot an email at gm[at]stackrlabs.xyz

However, an overemphasis on these ideals without considering the practical limitations can lead to the formation of erroneous mental models about how and why this technology should be adopted. As more and more mainstream users come in, these mental models can be hard to dislodge.

One such mental model is the belief that all centralized apps should be completely decentralized and migrated to blockchains in their entirety.

Decentralize everything as fast as you can! Or in simpler words - “Onchain good, offchain bad”

Decentralization is not an On-Off Switch

Crypto holds dear the values of decentralisation but it’s often overlooked that decentralisation is a spectrum and not an on-off switch.

Truth be told, not all applications need to fall on the decentralised end of the spectrum.

And in reality, a lot of well-adopted use-cases in crypto currently also function on the back of heavily centralised architectures.

• The current narrative of loyalty programs(read: points) are mostly done with off-chain and opaque infra.

• Perpetual DEXes like Aevo often have their orderbook and matching engine running entirely off-chain.

• Several niche DeFi protocols end up relying on centralised single-signer oracles for price feeds.

• And how can you forget the state of the Layer-2s where everybody is in the process of decentralising 😛

But the lesson is, centralisation vectors are fine if that is the trade-off you need to take for the experience of your app. As mentioned, decentralisation is a spectrum and as long as you’re able to provide your users with certain security guarantees that are appropriate for your app, it is more than enough.

Determining your app's level of decentralization involves carefully weighing the importance of security against the desired user experience.

For example - A DeFi app that holds users’ funds should be as bullet-proof as possible whereas a game that’s augmented with crypto features most probably doesn’t need extremely secure decentralisation guarantees.

Similarly, A social media app, doesn't really need to put frequent and low-value actions such as likes and votes onchain since these actions don't require as much security Instead, they can just put the essential components (say registration, account recovery, etc. for social media apps) onchain while keeping the other components centralized.

Blockchain apps provide transparency, security, censorship-resistance, and immutability. Centralized apps provide speed, efficiency, and scalability but aren’t as secure. Apps that blend both onchain and offchain components can thus be referred to as “hybrid apps” which provides the best of both worlds.

*Obviously, not everyone gets this wrong, so excuse the clickbait title. But that is often the dominating way of thinking about blockchain apps and it’s a mental model that we try to break with this blog post. Vitalik also brought up hybrid apps in his recent article, calling them “halfway-house” level decentralized apps and even other chad builders in the space are talking about it

All of the above leads us to the fact that for a plethora of use-cases, halfway-house security is sufficient while prioritising for the user experience.

Oh Baby, Why dont you just meet me in the middle?

Enabling developers to progressively decentralize their apps allows for some fantastic web3 usecases that so far have been thought of as too difficult to build onchain.

Of course, there can be variations of which part stays onchain based on what each app tries to achieve. “Halfway-house” apps don’t have to be exactly halfway decentralized. They can instead reside anywhere on a spectrum of decentralization based on the desired characteristics (for instance, apps looking for a high level of security can put more components onchain).

(drum roll) Halfway-house security with verifiable compute

Verifiable Compute refers to being able to provably demonstrate that a piece of computation has happened exactly how it was supposed to without any interference or tampering.

Verifiable compute coupled with suitable security guarantees around the trust assumptions of the infrastructure enabling it, is the most ideal outcome that apps should desire rather than decentralisation-maxxing.

Thinking through apps in terms of halfway-house security enables the developers to build apps that can power smooth Web2-like user experience while borrowing the best of crypto and the security guarantees if affords.

Show, don’t tell

Social “Sufficiently Decentralised” Media

Looking at Farcaster, it’s a social protocol that took the stance of being sufficiently decentralised.

For a social protocol, sufficient decentralisation is achieved “if two users can find each other and communicate, even if the rest of the network wants to prevent it.”

Farcaster achieves “sufficient decentralisation” with a clever mix of on-chain & off-chain infrastructure.

• On-Chain: ID registry & critical actions are provably processed and stored on Optimism.

• Off-Chain: Actions like posting a public message, or liking a message are processed and stored on a P2P Network — Hubs.

Farcaster is a prime example of leveraging the on-chain infrastructure for what it’s good at — solid security guarantees. And at the same time, not requiring the users to sign a transaction every single time they want to post “gm” on their feed — good UX.

On top of all that, with the registry being on-chain and Hubs making the data available: developers can build their own clients on top of Farcaster, effectively reaching sufficient decentralisation. If one client decides to censor you, move to another.

These are the kind of trade-offs between security and the envisioned user experience that are highlighted throughout the article.

Micro-Payments

Well if it isn’t the most commonly touted yet not fully realised vision of crypto.

And the vision won’t be fully realised until the UX of micro-payments with crypto isn’t as smooth as Apple Pay. Which is quite possible to build when you think about designing a micro-payments app with halfway-house security.

And to think of it, we’ve had experiments along the similar lines. For example, Lightning Network on top of Bitcoin is a protocol with halfway-house security which tried to offer a better experience for small BTC transfers between the users.

Celo is another case to look at where they’re transitioning from being an independent L1 to a validium on Ethereum with the renewed vision of being THE chain for micro-payments.

(Bonus: Soon, dropping an article on how Celo could be built as a set of micro-rollups using Stackr.)

Two-sided Marketplaces (Matching Engines)

The value of verifiable compute can be applied to any use-case that requires a matching engine to make the market between the supply and demand, and do so efficiently.

Think Uber but they leave an on-chain paper trail that proves your “intent” to go from A to B with your constraints has been matched as efficiently as possible with a driver.

And for a crypto-native use-case, think orderbooks.

In current Perp DEXes, the matching engine that connects buyers and sellers on the orderbook operates off-chain. While the DEX is motivated to make the market efficient, there is limited visibility on whether your orders are being effectively matched or not.

Imagine a rollup that is highly optimised for the matching engine. It reads the state from the orderbook and provably makes the market efficient right in the state transition function of the rollup. 🤯

Games

Building games while leveraging the decentralised stack can look very similar to how Farcaster leverages the decentralised ledger, halfway-house security.

Games usually need to be high throughput and that’s often a constraint when building on-chain both in terms of cost and user experience.

But, when thinking in a combination of on-chain & off-chain architecture, the design space opens up and that is also the trend we’re slowly seeing gaining steam where the games are just normal games with a few crypto-native features.

And in addition to that —

• Simulation/Strategy based games can leverage verifiable compute to build a trust-minimised simulation engine.

• PvP games can leverage the blockchain rails to add native “financialisation” with wagers.

• Games can leverage the decentralised ledger to store a paper-trail of in-game assets.

And many other use-cases…

The road to building hybrid apps & more ➡️

We strongly believe building apps with halfway-house security in mind can lead to both — a more robust crypto-native ecosystem & use-cases that lead to mass adoption.

At Stackr, we’re building the toolkit and the necessary infrastructure to build app-specific micro-rollups to supercharge and unlock the DevEx around building apps with halfway-house apps and much more with the languages you already know.

It’s not just a new tool, it’s a new paradigm on how to think about building blockchain-powered applications that are also secure.

If that piques your interest, come say hi and keep an eye out for the wish list of experiments dropping soon ✨

Thanks JD for review and Shivanshu Madan and Benjamin Funk for inputs

Stackr is a comprehensive and modular framework designed to enable developers to seamlessly build micro-rollups using general-purpose programming languages.

Our Mission: Empower every developer to build scalable web3 apps

Building applications for the blockchain has always been a niche field with a steep learning curve. Many non-web3 teams shy away from the complexities, even though decentralization could significantly enhance their offerings.

Stackr provides the simplest route to building web3 applications, offering developers a "web2 way for building web3 applications." With our powerful developer tooling, new teams and existing enterprises with web2 applications can seamlessly transition to decentralized solutions.

We call the apps built using Stackr, Micro-rollups.

Redefining (blockchain) app development through Micro-rollups

Rollups are applications that perform off-chain execution and post the execution data on a host blockchain. By doing so, they derive the security properties of the host chain.

Conceptualized as a solution to the scaling problems of blockchains, rollups were conceived amidst the skyrocketing network fees on Ethereum. The initial EVM-based general-purpose rollups were designed to provide a quick fix, preserving the ‘Ethereum developer experience’ while minimizing transaction costs. They served as an immediate remedy for the blockspace crisis. However, this initial approach to rollups has its own set of limitations.

One of them being the single-threaded nature and the global shared state of the EVM execution environment. A notable incident occurred when Arbitrum, one of the largest rollups, witnessed gas prices far surpassing those of Ethereum during its Odyssey event in July 2022, causing network congestion and impacting all apps on the rollup. This is because all applications were competing for the same, congested blockspace!

The solution to such predicaments lies in building isolated execution environments for each app, a.k.a., App-specific rollups.

App-specific rollups are chains that provide a customized and/or optimized execution environment to support specific use cases. These customizations could be protocol level - such as block times or gas measurement or even application level like custom cryptography or pre-compiles. They can be shared by similar applications or could serve just a single one.

However, while app rollups provide an optimized solution to the block space crisis, “constructing new architectures” for these app rollups is still quite difficult! It requires the management of various components, including establishing a state machine, the intricacies of data transport, and the implementation of verification mechanisms.

This is where Stackr comes in. The Stackr SDK offers pre-packaged modules that can be tailored to specific needs allowing developers to easily build bespoke rollups from scratch each with their own unique designs.

However, Stackr transcends traditional VM-based rollups, taking the concept of app rollups to a new level where execution doesn't necessarily rely on a VM but can instead employ custom logic written in nearly any programming language. We proudly introduce Micro-rollups, ushering in a new era of logic-specificity alongside app-specificity.

Introducing Micro-rollups (MRUs): A Paradigm Shift in App-specific Rollups

Micro-rollups are neo execution environments with primary objective of empowering developers by providing them with the necessary tools to create a broader range of web3 applications. This is achieved by offering developers a toolkit that aligns seamlessly with their existing knowledge and expertise, simplifying the complexities associated with building native web3 applications.

At the heart of the micro-rollup concept lies the principle of separation of execution and proving. The executor’s primary duty is to execute transactions, while the burden of ensuring the accuracy of the execution results is shifted to an external entity or auditor. This approach allows the executor to implement the core business logic in an unconstrained flexible manner and focus on throughput while the slower and costlier process of generating proofs or attestations is delegated away.

Unlike traditional blockchains, while MRUs can be used to build full rollups, they do not place the same emphasis on the highest levels of security or complete permissionless-ness. Instead, their focus is on achieving “Sufficient Decentralization”, striking a balance between the familiarity of Web2 development and the security inherent in Web3. Some examples of the kind of apps that this approach is suitable for include (as also noted by Vitalik himself in his post “Different types of layer 2s“):

1. For current app-chains who want to strip off some weight off of their protocols by piggy backing on Ethereum’s or other chain’s security models

2. Centralized projects seeking to enhance security assurances for their users through blockchain-based solutions

3. Current-gen centralized financial applications like CEXs who would want to provide users more visibility into their systems like proofs of solvency.

4. Non-financial applications, such as games or social media platforms, that aspire to be decentralized but require a “halfway-house” level of security

5. Systems that require additional co-processing and want to get trusted input inside Ethereum

6. and many more…

In essence, Micro-rollups offer a blend of accessibility, user-friendliness, and a certain degree of decentralization, making them a valuable tool for the expansion of the web3 ecosystem.

A web2 way for building web3 applications

Much like conventional Web2 apps, micro-rollups can be self-hosted on various cloud infrastructures. The Stackr SDK delivers a developer experience akin to traditional server-side or web2 backend application development. Additionally, Stackr’s roadmap includes plans to offer a mechanism for hosting these MRUs on behalf of developers in the future.

Stackr will provide its core framework in multiple languages along with an aptly named verification layer - Vulcan committee, starting with JavaScript, as it is the most commonly used language for building web apps. Eventually, the SDK will also be made available in other languages like Python, Golang, Rust, C#, and more. The aim is to provide tooling support for use-case-specific builds. For example, having a toolkit in C# will allow Unity game developers to leverage micro-rollups in their projects, and with Golang developers can build multi-nodal micro-rollup networks.

In addition to the core library, Stackr will offer pre-built state machine wrappers for specific use cases, such as token transfers. We intend to extend these wrappers to basic applications like exchanges, marketplaces, and social networking apps, among others so that developers don't have to bootstrap their applications from scratch.

Stackr aims at expanding its base toolkit via first and third party plugins for Sequencing, Data Availability adapters, Account Abstraction, Indexing, Hosting and multitude of other services and is open to collaboration on the development of these plugins and wrappers.

Next steps on the road to the moon 🚀🌕

The raised capital will be allocated towards several key objectives, including team expansion, preparation for the imminent launch of the platform's v1 version, and the growth of Stackr's developer ecosystem. Our overarching goal is to engage with a diverse community of independent developers and enterprise teams that are actively involved in developing applications for both Web2 and Web3.

Soon, we will also be launching our developer preview for a select few developers to give the Stackr SDK a spin. As a private beta tester, you will have early access to the various modules and direct support from the team. We will also be hosting a Hacker House Bootcamp in the build-up to ETH India later this year. If you're interested in participating, keep an eye out on our Twitter for an upcoming announcement.

Decentralized app development is currently constrained to a niche subset of crypto-natives. With Stackr, we aim to make it accessible for all. We want to break down the barriers between web2 and web3 by making it easy to build and operate rollups by providing a web2 like developer experience and abstracting away the on-chain complexities.

A truly permissionless on-chain world will be built when developers can innovate without restrictions. That is the vision that guides us at Stackr. #onwards

Stay tuned for Stackr Whitepaper dropping soon!

• Follow us on Twitter

• Drop an email at gm[at]stackrlabs.xyz

• Join the conversation - Discord

If the future consists of an onchain economy of thousands of rollups, we’re definitely on the right timeline in the present. From the Optimism stack and Polygon chain development kit to Caldera and Stackr, recent months have seen a variety of Rollup frameworks and Rollups-as-a-Service (RaaS) providers hit the market. These frameworks offer modular (often open-source) codebases for the different components of a rollup, allowing developers to pick and choose from a variety of custom options for each layer of the stack.

But how do these providers accrue value? Or, do they accrue any value at all? as argued by Neel Somani recently in his talk “RaaS solutions are going to zero” at Modular Summit.

In this blog post, we analyze some of his arguments and also explore the intricate dynamics of value accrual for rollup frameworks and RaaS providers. From the individual layers to Superchains, we unravel the hidden mechanisms behind the value creation and capture by rollup frameworks and RaaS providers.

Rollups vs Rollup Framework vs RaaS

Rollups are applications that perform offchain execution and post the execution data on another (host) blockchain. By doing so, they derive the security properties of the host chain. The rollup application itself could be just a single State transition function, or it could be a separate Blockchain for which canonical state is maintained by a group of nodes

A rollup framework is a pre-built codebase that implements the essential components of a rollup. Instead of building a rollup from scratch, developers can use these existing codebases (often packaged as SDKs) and customize them to their specific needs. Examples of open-source rollup frameworks include OP Stack and Arbitrum Orbit.

Rollups-as-a-Service, or RaaS protocols, are no-code wrappers built on top of existing rollup frameworks. They enable developers to quickly deploy a rollup from scratch by selecting custom features from drop-down menus. RaaS companies often handle the sequencing of the deployed rollups and offer additional consulting services.

Where the money goes

To understand how the value flows in and out of the entire stack, it is important to first understand the architecture of a rollup and how the different layers interact with each other. There are broadly 3 layers that constitute a rollup stack:

1. Execution - This layer executes the transactions by applying the State Transition Function (STF) on the existing state of the rollup. Depending on how ‘centralized’ the rollup is, an execution node could own a range of responsibilities from ordering transactions and executing them to posting them on L1 and creating fraud/validity proofs.

The execution layer is the ‘user-facing’ layer, where the money enters the rollup stack. Users are charged a transaction fee (gas) which is usually a margin over the various costs that the execution layer has to pay (more on this later). This layer can also extract additional value from the users by ordering transactions in certain ways (also known as MEV: Maximal Extractable Value).

2. Settlement - This includes verifying the validity/fraud proofs and ‘defining’ the canonical state of the rollup (in the case of smart contract rollups). Settlement is usually managed by a unified, high-security layer like Ethereum. Rollup frameworks can build their own settlement layer as well.

Settlement isn’t a very high-value-capture layer of the stack as verification costs are usually meager. Optimism only pays ~$5 a day to Ethereum for settlement. A competitive settlement layer would cost even less. (as also highlighted in Rollups-as-a-Service Are Going To Zero)

3. Data Availability - DA includes broadcasting the ordered transaction data to the rest of the network (also sometimes called Data Publishing). It ensures that anyone can permissionlessly reconstruct the rollup state by simply applying the broadcasted transaction data to some previously finalized state.

DA costs form a major portion of all rollup costs. Posting data on a highly-secure layer like Ethereum can be quite expensive. Cheaper and faster DA alternatives are being actively developed by protocols like Celestia, Avail, and EigenDA. Rollup frameworks could also consider building their own DA layer, but a fragmented DA has high bootstrapping costs and makes interoperability more complex.

It might help to think of the Execution layer as a B2C model and Settlement and DA layers as B2B models:

• Execution layer buys block space from the DA layer and sells its execution services directly to the end user (customer). It also buys verification & bridging services from the Settlement layer

• DA layer sells block space to another business - the Execution layer

• Settlement layer provides settlement services to another business - the Execution layer

In such a setup in competitive markets, the majority of value capture happens directly from the end user in the execution layer of the stack, so it makes sense to break it down further and analyze its value flows independently.

Execution layer: A B2C economic model

The execution layer generates revenue by charging users for each transaction and pays operational costs to the other businesses (layers) in the stack.

Revenue: The incoming value can be categorized as follows:

• Gas costs paid by end users per transaction

• Intra domain MEV

• Cross-domain MEV* (*If the framework provides sequencing for multiple rollups on the same DA layer. Could be tough to extract otherwise)

MEV depends on the transaction flow (the “extractable” value will be different for each set of transactions) and is often hard to predict in advance. The gas costs charged to the users are then usually a margin over the combined predictable costs.

Costs: The value outflows from the execution layer are the following:

• Node operational overhead

• Execution (compute) costs

• Proving (validity/fraud proofs) costs

• Data posting costs (variable based on congestion on the DA layer)

Often, all the execution layer responsibilities are borne by one centralized sequencer node. This single node accrues all the revenue from the users and is responsible for paying the DA and Settlement costs. At other times, the setup can have different nodes for different responsibilities:

• Sequencers order transactions and post data on the DA layer. They ‘earn’ the transaction fees paid by users and pay sequencing overhead and data posting costs. Sequencing can also be done by a pre-selected set of sequencers or decentralized sequencers like Espresso. Sequencers are also responsible for posting state changes to the Settlement layer and paying the settlement costs

• Prover nodes are responsible for generating proofs. It can be a central prover or a decentralized set of proving nodes. Their costs comprise the proof-generation overhead. Depending on the setup, provers either ‘sell’ the proofs to the sequencer, or post it to the settlement layer directly

• Rollups can also have other full nodes (or full-verifying light nodes) that execute all transaction batches and maintain the canonical state of the rollup. These full nodes don’t necessarily accrue any direct revenue but indirectly capture value by holding the rollup’s native gas token

The above is a broad differentiation of the responsibilities of different nodes. Which node takes up which tasks can differ based on how the rollup team architectures their setup. For the sake of simplicity in this blog, we will stick to a centralized sequencer setup where one node performs all the required execution tasks.

The question then is: If the execution layer drives the most value, which participant in the stack is best positioned to capture it?

Anyone who runs the sequencing node and performs the various activities associated with it!

This can be the rollup team themselves. Or, as mentioned at the beginning of the article, RaaS providers often handle the sequencing for the rollups deployed using them. In fact, this is the majority portion of revenue for the RaaS providers.

(How) does RaaS make money?

There are 3 major areas a RaaS can capture value:

• Sequencer Hosting: The RaaS provider runs the sequencer and associated activities for the rollup. It's a division of labor where the rollup team brings the innovation (the app they are building) and the RaaS provider does everything else. The sequencer orders transactions, posts data on L1, and creates proofs if/when required

• Additional Infra: Block explorers, bridges, etc.

• Dedicated Support: Consulting and partnering on infra decisions (how to sequence, MEV, etc.) + other technical support

RaaS is similar to a traditional B2B SaaS business where the business can charge their customers a flat fee or a hybrid-tiered fee based on the services bought and the usage (number of end-user transactions for a rollup, for example).

RaaS could also provide an integration with a shared sequencer like Espresso. However, in this case, they would lose out on the sequencer revenue, which makes up a major portion of RaaS’s profits. These partnerships therefore require contractual profit sharing between the shared sequencer and RaaS provider.

But if RaaS is a wrapper built on top of an existing rollup framework, it must share revenue with them as well, right?

Well, not necessarily.

Most of the rollup frameworks released so far have been open-source and permissionless to build upon. RaaS providers can use the framework permissionlessly to build a no-code wrapper on top of it and aren’t obligated to share any profits with the underlying framework.

Can they have a contractual agreement with the rollup framework to share profits?

They can, but if they do so:

1. They lose out on some of their own profits

2. Another competitor RaaS could choose not to share profits with the rollup framework and would be economically dominant in the long term

Therefore, game theoretically, for RaaS provider to survive, the rational decision is to NOT share profits with the underlying framework.

So if RaaS providers don’t share profits, how does a rollup framework accrue any value?

If anyone can permissionlessly build a rollup using the open-source framework, is it even an economically viable decision to develop an open-source rollup framework in the first place?

The answer is not so straightforward. For a rollup framework to be ‘economically viable’, it needs to generate sustainable, long-term value. Idan Levin shared a good mental model to think about how this can be done. Let’s expand on that model here. There are 3 major ways rollup frameworks can accrue value:

1. Indirect value accrual: If the framework is good, more and more teams will use it. This will attract developer eyes and more mindshare to the ecosystem. Attracting mindshare is always a net positive as it will help the framework team in developing the tools further. Any enhancements that any of the teams make can be incorporated into the OG framework. This creates a positive reinforcement loop for the entire system.

2. Semi-direct value accrual: Some rollups building on top of the framework might be incentivized to share revenue with the framework network. For example, Base currently has an agreement with OP Stack where they share part of the sequencing fee with Optimism.

   Why are they incentivized to do so?

   Because Base doesn’t have the necessary developer ecosystem to keep up with the growth and development of the OP framework. Imagine if the OP framework changes one of the modules completely, they could choose not to provide the developer support to Base to keep up with the changes.

   In addition, being a part of the ‘Superchain’ provides network effects like cross-rollup composability that chains like Base could find useful (and this could have a requirement to share revenue with Optimism)

One important caveat here is that the incentives of rollups and rollup frameworks might not always be aligned. At any point, the rollup could choose to follow its own path by customizing the framework and scrapping any revenue share agreements.

3. Direct value accrual: Through the framework’s own rollup (e.g., Optimism mainnet) built using the same framework (e.g., OP Stack). The gas could be in the native token (e.g., OP) and all the MEV from this rollup would accrue to the framework team. In addition, the team could also ‘extract’ some supplementary direct value:

1. Building their own RaaS - The framework could choose to compete in the RaaS space and provide its own Sequencer hosting + consulting services. If a lot of frameworks start doing this, this could make the RaaS business model unsustainable in the long term. This is because the framework could leverage its credibility and position in the market to outcompete any external RaaS providers built on top of it.

2. Inter-rollup composability as leverage: Anyone can build a rollup by using the framework as it is or modifying it. However, to gain network effects and interoperability with other rollups built on the same framework, the framework may require adherence to certain defined standards.

   This is what OP Stack does with the Law of Chains. To be a part of the Superchain, you have to follow certain rules. These rules are defined by the OP governance. For example, one of these rules could be that all rollups in Superchain have to use OP as the gas token. This could also evolve to include MEV share laws, for e.g., X% of cross-chain MEV revenue would go back to the OP treasury.

The rollup framework teams can play with the above 3 segments to tailor their ‘value capture’ mechanism to their goals and ambitions. For them to accrue any direct value, a few (non-exhaustive) options could be:

• Deploying own rollup

• Deploying own RaaS

• Leveraging composability to govern standards for the framework

Conclusion

The rapid development of rollup frameworks and Rollups-as-a-Service (RaaS) providers in the blockchain space has sparked questions about their value accrual. While the execution layer captures the lion's share of value, rollup frameworks can gain indirect value through adoption and enhancements. Some rollups may even share revenue, creating a semi-direct value accrual. Furthermore, by deploying their own rollups and leveraging inter-rollup composability, frameworks can directly capture value. As the ecosystem evolves, striking the right balance between competition and collaboration will be vital for the sustainable growth of rollup frameworks and RaaS providers.

At Stackr, we're exploring the best ways to build a transparent and sustainable business that opens the gates of crypto to the Web2 world. As we grind towards shipping our rollup framework, we are also experimenting and evaluating the various ways of accruing value to our customers and partners. If you have ideas, thoughts, or arguments, we would love to hear from you!

Reach out to us via Twitter or drop an email at gm[at]stackrlabs.xyz.

Today, decentralized app development is constrained to a niche subset of crypto-natives. Our goal is to make it accessible for all - to break down the barriers between web2 and web3 by making it easy to build and operate rollups.

As our first step towards this goal, we are introducing the Stackr SDK - a framework to build app-specific micro-rollups in web2 programming languages. In the rest of this post, we’ll walk through these concepts and our thinking behind the SDK, our long-term vision and near-term focus.

Appchains, meet rollups

Ethereum and Cosmos visions are colliding.

The Ethereum ecosystem has recognized the value of app-specific blockspace for customizability, performance and value capture. Meanwhile, the Cosmos ecosystem has recognized the value of shared security for trust-minimization and easier chain operations. App-specific rollups realize the best of both worlds and are quickly gaining mindshare.

However, it’s still very hard to build rollups, let alone app-specific rollups. Most existing rollups are general purpose, take a long time to build, require deep crypto expertise and use custom software.

Stackr solves this problem with an SDK for building app-specific rollups. We let developers easily customize execution environments to fit their use cases.

How we think about rollups

Before further illustrating our approach, let’s take a step back. The rollup design space is large, complex and dynamic, so it’s important that we first establish a fundamental understanding of the technology.

Rollups are often misunderstood - they simply compute over transactions off-chain and store the results and input data on-chain. Kelvin from Optimism recently offered a great mental model in his ETHGlobal presentation. A rollup is “a function over an input array”. We agree, and through this lens, any finite state machine that computes over an on-chain input array can be considered a rollup. Rollups are not limited to the EVM, SVM, Move VM, or any crypto-native VMs!

Break up the monoliths

One thing web2 got very right was the micro-services architecture. The design philosophy involves breaking down a larger system or application into smaller components, each responsible for specific functions. For example, a given application might have authentication, data storage, and messaging functions built as separate micro-services. This approach brings many benefits to developers - agility, flexibility, upgradability, efficiency, reusability, etc.

For similar reasons, web3 is also adopting this design philosophy. It underlies the shift towards modular blockchains and app-specificity.

Here come the micro-rollups

Stackr is going a step further - from app-specificity to logic-specificity. We are introducing the concept of micro-rollups, where individual functions within a decentralized app are developed, optimized and maintained as independent state machines. Referencing the micro-services analog, you can think about regular rollups —> micro-rollups similar to monoliths —> micro-services or VMs —> containers.

Here are two ways to visualize the differences:

Developers can use the Stackr SDK to define data structures for their application’s state and state transition function. Under the hood Stackr will do the heavy lifting, providing an API to interact with the app, connect it to the aggregator network (more on this later) and finalize on L1.

As an example application, let’s say you write a merkle tree with leaves that hold account addresses and token balances. You have just built yourself an account-book rollup. Now replace ECDSA with BLS and you have a working version of Hubble, the most efficient ERC-20 transfer rollup as well as (fun fact!) the first ever app-specific rollup!

Program in languages you already love

The Stackr SDK is very flexible and allows developers to use programming languages of their choice. We believe that to truly make web3 app development widely accessible, we must meet developers where they are. Python, JavaScript, Go, C, etc. - these are the languages that millions of developers worldwide already know and love.

Stackr Labs is also developing pre-built state machine and bridging modules that make it easy for micro-rollups of different languages to interact. Imagine an app that uses one Python-based micro-rollup and another JavaScript-based micro-rollup, both optimized for the task at hand.

Here’s a way to visualize composable micro-rollups leveraging different languages and an aggregator network:

Sufficiently decentralized apps

There are many exciting apps in the space, but one we find worth highlighting is Farcaster, a “sufficiently decentralized social network”. The Farcaster team detailed their thinking behind “sufficient decentralization” in this post, but the core idea is that sometimes putting entire apps on-chain is “unnecessary and undesirable”.

Their POV is that “a social network achieves sufficient decentralization if two users can find each other and communicate, even if the rest of the network wants to prevent it” and that “achieving this only requires three decentralized features: the ability to claim a unique username, post messages under that name, and read messages from any valid name.”

To be very clear - we at Stackr Labs believe in open and permissionless innovation. Build anything you want and put any of it on-chain. However, we do find the Farcaster design approach (and social network use case) interesting and a fantastic match for micro-rollups and the Stackr SDK. We aim to make it easy for developers to decentralize the bits that matter.

Example use cases and applications

The capacity of rollups to validate any off-chain computation represents a remarkable superpower that can be harnessed to create highly efficient use cases for distributed computing. Here are some examples to get the juices flowing:

• Games. Build immersive, interactive games in JS or Unity by converting each user action into an L2 transaction. Rollups provide exciting new opportunities for the development of sophisticated gaming applications with unprecedented levels of interactivity.

• Databases and cloud services. Build a full-fledged database system and index structured and unstructured data within L2 nodes or build entire cloud service stacks like Lambda or identity management tools.

• Oracles and real world data. Have seamless integration of off-chain data sources such as social graphs, user credit scores, KYC and identity systems. Build attestation applications or run an entire DAO as a rollup with advanced access control and grants processes.

• Off-chain multi-nodal networks. Develop comprehensive distributed applications. Provide novel on-chain services to users by enabling nodes to interact with each other through a rollup network.

• Social algorithms. Build a trending algorithm micro-rollup to power the news feed of your Farcaster client.

• Machine learning. Deploy models for inference as Python micro-rollups. Let users verify it’s truly GPT-2 and not GPT or some other flavor.

• DeFi and NFTs. Build an AMM DEX in Python or C++ using composable micro-rollups for token transfer + token pool + oracle + AMM logic.

• Enterprise applications. Build private and semi-private applications with robust data access controls. For example, an end-to-end supply chain management system with view permissions for the public but write permissions reserved for authorized parties.

• No limits! We are only starting to unlock the full potential of rollups for distributed computing. Build secure and reliable communication infrastructure, multi-party compute systems like folding@home, distributed video transcoding systems like Livepeer, privacy-focused transaction ledgers like Aztec or a massive open world game like Minecraft. Build anything from middleware for wallets to entire cloud services like AWS - there’s a huge design space for verifiable compute.

Product vision

Now let’s talk about our vision for Stackr Labs and the technologies we are building.

Modular and agnostic SDK

The Stackr SDK will support many web2 programming languages such as Python, JavaScript, Go, C, Rust and more - our goal is to be language agnostic. The SDK will also be as flexible as possible regarding proofs (fraud and validity), rollup types (classic and sovereign), ordering (centralized and decentralized) and base layers.

Decentralized aggregator network

Stackr Labs is also building an aggregator network that receives interaction data from applications (along with new states and metadata), bundles the data and submits it on-chain. You can think of the aggregator network like bundlers in EIP-4337, except with rollup data.

We will be sharing much more information about this layer over the coming months!

Near-term focus

To start, the Stackr SDK will focus on Python and JavaScript programming languages. It will support sovereign rollup mode and ordering will be done by the applications. The initial version will be released without proofs enabled, while we build out the aggregator network, and focus on Ethereum as a base layer.

Where to find us

The Stackr Labs mission is to empower every developer to build scalable web3 apps. It’s an ambitious goal and there’s plenty of work ahead. If the mission resonates with you as a builder or potential team member, please reach out!

• We’re hiring! Join our team

• Eager to build with us? Join the waitlist

Whether you’re looking to deploy an existing project as a rollup, starting a new project or still in the idea maze, we’d love to collaborate with you.

We plan to build in public and will be releasing much more information over the coming months. Excited to have you on this journey with us - let’s “roll” homies 🚀

• Twitter

• Discord

• Website

• Mirror

Special thanks

Shoutout to our advisors, investors and everyone helping out along the way: @litocoen @RHLSTHRM @anuragarjun @arjunbhuptani @norswap @NoahCitron @musalbas @DannySursock @AshAEgan @stonecoldpat0 @sunnydece @VirtualElena @guywuolletjr @ljxie @sanjaypshah @nuss_eli @jacobkxyz @jadbc0x @sjors_lemniscap @jessziyuezhang @devfolio and many others