During the EthCC 2024 week in Brussels, the Avail team hosted the Unification Cup, bringing together many people from the ecosystem to participate in a football tournament. We, at Stackr Labs, partnered with the Avail team to develop an application-specific ephemeral rollup on top of Avail DA for the tournament.

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.

“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.

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.

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.

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.

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 :)

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.

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

• 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

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.

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

During the EthCC 2024 week in Brussels, the Avail team hosted the Unification Cup, bringing together many people from the ecosystem to participate in a football tournament. We, at Stackr Labs, partnered with the Avail team to develop an application-specific ephemeral rollup on top of Avail DA for the tournament.

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.

“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.

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.

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.

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.

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 :)

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.

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

• 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

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.

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