In this post, we’ll go over the different parts of the RollupKit architecture, including data availability, state derivation, the sequencer, and the wallet/frontend interface. Let’s unpack each component and see how they work together to form a lightweight, scalable rollup solution.

For those interested, the full code for RollupKit is available on GitHub. Here’s the link to the repository.

What is RollupKit?

RollupKit is a streamlined version of a Sovereign Rollup—a type of rollup that relies on Ethereum only for data availability and consensus, skipping the more complex verification mechanisms like fraud proofs or zero-knowledge proofs.

Unlike optimistic or zero-knowledge rollups, RollupKit doesn't have a trust-minimized bridge with Ethereum. Instead, it focuses on providing data availability through Ethereum's calldata, making it more accessible for developers to experiment with the core mechanics of rollups without getting into the weeds of cryptographic proofs.

Think of RollupKit as a DIY kit for building your own mini-blockchain that scales using Ethereum but doesn’t rely on it for complex validations. It’s perfect for understanding the building blocks of rollup technology.

Key Components of the RollupKit Architecture

The RollupKit project is composed of three main layers:

1. Node / Backend: Manages data availability, state transitions, and database storage.

2. Sequencer: Collects and posts transactions in batches to the Ethereum network.

3. Wallet / Frontend: Provides a user interface for interacting with the rollup.

Each component plays a critical role in ensuring that the rollup functions smoothly and efficiently.

Node / Backend

The node or backend in BYOR handles several key processes, including data availability, state derivation, and storing the current state. Let's take a closer look at each of these functionalities.

1. Data Availability

Data availability is crucial for rollups. In BYOR, this is achieved by posting transaction data as calldata to the Inputs contract on Ethereum. This contract’s purpose is to serve as a repository of data accessible by the rollup.

Imagine the Inputs contract as a public bulletin board. Anyone can post data to it, and anyone can read the data from it. This setup ensures that all participants in the rollup have access to the transaction history. Users or sequencers can send transactions to the contract, and once posted, the contract emits a BatchAppended event, making it easy to track new transactions.

Example:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Inputs {
    event BatchAppended(address sender);

    function appendBatch(bytes calldata _data) external {
        require(msg.sender == tx.origin); // Only EOA
        emit BatchAppended(msg.sender);
    }
}

When a user or sequencer calls the appendBatch function, a BatchAppended event is emitted. This event acts as a signal to the backend, telling it that new data is available for processing.

Real-World Analogy: "The Drop Box"

Think of the Inputs contract like a public drop box at a post office. Anyone can drop a letter (data) into it, and everyone knows new letters have been added by the notification (event) on the bulletin board. This ensures transparency and accessibility to all participants, who can then retrieve the data from this shared storage space.

2. State Derivation

State derivation in BYOR involves taking input data (transactions) and updating the rollup's state. The process includes defining the initial state (genesis state), fetching data, and transitioning between states.

Genesis State

The genesis state is the starting point of the rollup. It’s defined in a JSON file, genesis.json, which maps each address to an initial balance. This setup resembles a pre-funded account system, where each user has an initial balance but no ability to mint new tokens.

{
    "0x1234...abcd": 1000,
    "0xabcd...1234": 500
}

In this example, the addresses are pre-funded with tokens as their starting balances. This file represents the state of the rollup at block 0, ensuring all nodes start with the same foundational data.

Data Fetching

The BatchDownloader.ts script continuously fetches new data from the Inputs contract. It listens to BatchAppended events and retrieves transaction data, which is then passed through the State Transition Function (STF) to update the rollup’s state.

State Transition Function (STF)

The State Transition Function is the heart of the rollup. It takes inputs (transactions) and generates a new state based on them. In BYOR, batches are ordered by their appearance on L1 Ethereum; there's no additional state tracking to define the order, so the STF is simplified.

Example:

function executeTransaction(state, tx) {
    const fromAccount = state[tx.from] || { balance: 0, nonce: 0 };
    const toAccount = state[tx.to] || { balance: 0, nonce: 0 };

    fromAccount.balance -= tx.value;
    toAccount.balance += tx.value;
    fromAccount.nonce += 1;

    state[tx.from] = fromAccount;
    state[tx.to] = toAccount;
}

Real-World Analogy: "Account Ledger"

Imagine a community ledger where everyone writes down transactions in sequence. Each new entry depends on the previous one, creating a sequential history of all transactions. The STF updates the ledger (state) as new transactions are added.

3. Storing the State

BYOR uses a database to store account information, such as balances and nonces, for each address. This data is stored in an accounts table, with the following schema:

CREATE TABLE accounts (
    address TEXT PRIMARY KEY NOT NULL,
    balance INTEGER DEFAULT 0 NOT NULL,
    nonce INTEGER DEFAULT 0 NOT NULL
);

If a new user interacts with the rollup and has no previous entry in the database, they’re assigned a default balance and nonce of zero.

Sequencer

The sequencer in BYOR is responsible for gathering transactions and submitting them to the Inputs contract in batches. BYOR’s sequencer is divided into two main parts: Mempool.ts and BatchPoster.ts.

Mempool

The Mempool acts as a waiting room for transactions. Here, transactions are organized by fee, ensuring that higher-fee transactions are prioritized when forming a batch. This incentivizes users to pay higher fees for faster processing.

Batch Poster

The Batch Poster creates a batch of transactions from the mempool and posts it to the data availability layer (Ethereum). This batch-posting mechanism reduces the number of submissions to Ethereum, saving on gas costs and improving scalability.

Client / Frontend

BYOR includes a simple wallet interface for users to interact with the rollup. Built using Next.js and WalletConnect, the wallet provides an easy way for users to send tokens, view balances, and check transaction statuses.

Key Features

1. Token Transfers: Users can send tokens to other addresses within the rollup.

2. Transaction Status: Users can monitor the status of transactions, whether in the mempool or already posted to Ethereum.

3. Gas Fee Prioritization: The interface highlights the importance of gas fees, showing users how fees affect transaction processing speed.

Real-World Analogy: "Online Banking App"

Think of the BYOR wallet like an online banking app. Users can check their balances, transfer funds to others, and view the status of recent transactions.

Example Flow: Sending Tokens

1. User Initiates Transfer: Alice decides to send 100 tokens to Bob. She enters Bob’s address and specifies a gas fee.

2. Transaction Enters Mempool: The transaction is added to the mempool, where it’s sorted by fee. Alice’s higher fee puts her transaction near the top.

3. Batch Poster Submits: The sequencer posts Alice’s transaction, along with others in the batch, to the Inputs contract on Ethereum.

4. Backend Fetches Batch: The backend detects the new BatchAppended event and retrieves Alice’s transaction data.

5. State Transition Function Updates: The STF processes Alice’s transaction, updating her balance and Bob’s balance in the rollup.

6. Database Stores New State: The updated balances are saved in the accounts table, ensuring the new state is recorded.

In-Depth Code Highlights

Smart Contract

The Inputs.sol contract serves as the single point of data submission, emitting events that make it easy to query for new transaction batches.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Inputs {
    event BatchAppended(address sender);
    function appendBatch(bytes calldata) external {
        require(msg.sender == tx.origin);
        emit BatchAppended(msg.sender);
    }
}

Database Schema

BYOR uses a simple SQL database schema to store account information and transaction details.

accounts Table:

CREATE TABLE accounts (
    address TEXT PRIMARY KEY NOT NULL,
    balance INTEGER DEFAULT 0 NOT NULL,
    nonce INTEGER DEFAULT 0 NOT NULL
);

transactions Table:

CREATE TABLE transactions (
    id INTEGER,
    from TEXT NOT NULL,
    to TEXT NOT NULL,
    value INTEGER NOT NULL,
    nonce INTEGER NOT NULL,
    fee INTEGER NOT NULL,
    feeRecipient TEXT NOT NULL,
    l1SubmittedDate INTEGER NOT NULL,
    hash TEXT NOT NULL,
    PRIMARY KEY(from, nonce)
);

State Transition Function

The function executeTransaction in StateUpdater.ts updates balances and nonces for each transaction in the state.

const DEFAULT_ACCOUNT = { balance: 0, nonce: 0 };

function executeTransaction(state, tx, feeRecipient) {
    const fromAccount = getAccount(state, tx.from, DEFAULT_ACCOUNT);
    const toAccount = getAccount(state, tx.to, DEFAULT_ACCOUNT);

    fromAccount.nonce = tx.nonce;
    fromAccount.balance -= tx.value;
    toAccount.balance += tx.value;

    fromAccount.balance -= tx.fee;
    feeRecipient.balance += tx.fee;
}

Event Fetching

getNewStates fetches new BatchAppended events, extracting calldata, timestamps, and sender details, then packaging this data for further processing.

function getNewStates() {
    const lastBatchBlock = getLastBatchBlock();
    const events = getLogs(lastBatchBlock);
    const calldata = getCalldata(events);
    const timestamps = getTimestamps(events);
    const posters = getTransactionPosters(events);

    updateLastFetchedBlock(lastBatchBlock);
    return zip(posters, timestamps, calldata);
}

Mempool Fee Sorting

Transactions in the mempool are sorted by fees to prioritize higher-fee transactions.

function popNHighestFee(txPool, n) {
    txPool.sort((a, b) => b.fee - a.fee);
    return txPool.splice(0, n);
}

Limitations and Future Developments

While BYOR provides a foundational model for a Sovereign Rollup, it has limitations:

• No Fraud Proofs: Unlike optimistic rollups, BYOR doesn’t include a mechanism to challenge invalid state transitions.

• Limited to Data Availability: Ethereum is used only for storing data, without any form of dispute resolution.

Future improvements could involve adding fraud proofs, using zk-rollup techniques, or implementing gas-efficient data storage.

Prerequisites: Setting the Stage 🎬

1. Docker 🐳

First things first, you’ll need Docker and Docker Compose installed to run your chain smoothly.

• Install Docker: docker (opens in a new tab)

• Install Docker Compose: docker-compose (opens in a new tab)

✅ Tip: Make sure they’re up and running before you continue. If not, installing these tools is just a click away!

2. Avail Account 🏦

Before diving head-first into deploying contracts, you need an Avail account. Here’s the skinny on how to do that:

Step 1: Compatible Wallet Setup 👜 You can use wallets like SubWallet, Talisman, PolkadotJS, Nova Wallet, etc. This guide will use SubWallet as an example.

• Install SubWallet:Visit SubWallet.app and install the browser extension.Open the extension and select the option to create a new account or import an existing one.

Step 2: Set Up a Password 🔑SubWallet will prompt you to create a password, which secures access to the wallet extension itself (not the on-chain account).

Step 3: Secure Your Seed Phrase 📜Don't lose this! It’s your key to recover your account if things go sideways.

Step 4: Configure Avail Networks 🌐

• In SubWallet, open the Networks Menu.

• Search for Avail testnets and toggle the network on to connect to Avail DA mainnet or Turing testnet.

Step 5: Retrieve Your Avail Address 📬

• Go to the SubWallet homepage and click on Get Address.

• Select your network and copy your account address.

Step 2: Fund Your Account Using Avail Faucet 💧

Visit Avail Faucet, select the chain (e.g., Turing), enter your address, complete the CAPTCHA, and get some test AVAIL tokens.

3. Get AppID for Your Rollup on Avail DA

Obtain an application key (AppID) for your rollup on Avail DA by following these steps:

Step 1: Check the Next Available AppID 🆔

1. Go to the Data Availability pallet in the explorer.

2. Select the nextAppId method.

3. Click the + button to view the next available index/ID for a new AppID.

Step 2: Register a New AppID ✍️

1. Ensure your Avail DA wallet is connected to the explorer.

2. Navigate to the Extrinsics section under the Developer tab.

3. Select the dataAvailability pallet and choose the createApplicationKey method.

4. Enter a unique key for your app.

   Important Note:

   • Do Not Change the appID field for this transaction. Set it to 0, as this denotes chain-level operations.

   • Each transaction on Avail DA has a unique appID.

5. Submit the transaction, and authorize it through your wallet.

Step 3: Verify Your AppID ✅

1. Go to the Chain State section of the explorer.

2. Select the dataAvailability pallet and the appKeys method.

3. Uncheck the Include Option toggle and click + to fetch a list of registered AppIDs, confirming your AppID.

4. Arbitrum Sepolia Testnet ETH ⚡

No ETH, no fun! Make sure you have at least 1 ETH on Arbitrum Sepolia:

1. Get Testnet ETH: Visit Alchemy’s Sepolia faucet.

2. Bridge ETH to Arbitrum Sepolia: Use the Arbitrum Bridge to transfer it over.

Following these prerequisites will set you up to create and manage an AppID on Avail DA and interact with the Avail network.

Step 1: Deploy Rollup Contracts

1. Clone the Nitro Contracts Repository:

   
   git clone https://github.com/availproject/nitro-contracts.git
   cd nitro-contracts
   git checkout v2.1.0-upstream-v2.1.0
   yarn install
   yarn build
   

2. Create and Configure the .env File:

   • Copy .env.sample to .env.

   • For the ROLLUP_CREATOR_ADDRESS on any other supported chain, please find it here.

   • For the ARBISCAN_API_KEY check out https://docs.arbiscan.io/getting-started/viewing-api-usage-statistics

   • Edit the following entries:

     ROLLUP_CREATOR_ADDRESS="0xE917553b67f630C3982236B6A1d7844B1021B909"  # For Arbitrum Sepolia
     DEVNET_PRIVKEY="<--Private-key-->"
     ARBISCAN_API_KEY = ""
     

3. Edit the Configuration File:

   • Copy scripts/config.ts.example to scripts/config.ts and update with your chain’s parameters:

   • In this change only the chainId to the number you wish. then keep

     remaining unchanged.

     config = {
       rollupConfig: {
         confirmPeriodBlocks: ethers.BigNumber.from('150'),
         extraChallengeTimeBlocks: ethers.BigNumber.from('0'),
         stakeToken: ethers.constants.AddressZero,
         baseStake: ethers.utils.parseEther('0.0001'),
         wasmModuleRoot:
           '0x3f3b4da7b5c231e6faf91ff723d235728b05c9074f2ae3cc4b3e54dd5139d34f',
         owner: '0x1234123412341234123412341234123412341234',
         loserStakeEscrow: ethers.constants.AddressZero,
         chainId: ethers.BigNumber.from('20121999'),
         chainConfig:
           '{"chainId":20121999,"homesteadBlock":0,"daoForkBlock":null,"daoForkSupport":true,"eip150Block":0,"eip150Hash":"0x0000000000000000000000000000000000000000000000000000000000000000","eip155Block":0,"eip158Block":0,"byzantiumBlock":0,"constantinopleBlock":0,"petersburgBlock":0,"istanbulBlock":0,"muirGlacierBlock":0,"berlinBlock":0,"londonBlock":0,"clique":{"period":0,"epoch":0},"arbitrum":{"EnableArbOS":true,"AllowDebugPrecompiles":false,"DataAvailabilityCommittee":false,"InitialArbOSVersion":10,"InitialChainOwner":"0xd41996ED89bb5BF7dBfB181D8D93E8067446200B","GenesisBlockNum":0}}',
         genesisBlockNum: ethers.BigNumber.from('0'),
         sequencerInboxMaxTimeVariation: {
           delayBlocks: ethers.BigNumber.from('5760'),
           futureBlocks: ethers.BigNumber.from('12'),
           delaySeconds: ethers.BigNumber.from('86400'),
           futureSeconds: ethers.BigNumber.from('3600'),
         },
       },
       validators: [
         '0x1234123412341234123412341234123412341234',
       ],
       batchPosters: ['0x1234123412341234123412341234123412341234',],
       batchPosterManager: '0x1234123412341234123412341234123412341234'
     },
      
      
     

Step 2: Deploy Base Contracts on Arbitrum Sepolia

To deploy the rollup contracts on Arbitrum Sepolia, execute the following commands in sequence:

yarn build:forge:yul
yarn run deploy-eth-rollup --network arbSepolia

Heads up: ⚠️ If you see an error like No matches found: "*.sol", edit the package.json file:

"build:forge:yul": "FOUNDRY_PROFILE=yul forge build --skip \"*.sol\""

Re-run the command, and you’re good to go!

After deployment, note the addresses for the base contracts, as you will need them in the next configuration step.

Step 3: Configure and Start the Orbit Node

1. Clone the Orbit Setup Script Repository

   Begin by cloning the repository for the Orbit setup script:

   git clone https://github.com/OffchainLabs/orbit-setup-script.git
   cd orbit-setup-script
   

2. Create and Configure nodeConfig.json

   In the ./config directory, create a nodeConfig.json file. Update it with the configuration details, including base contract addresses and network-specific settings:

   • chain.chain-id - Chain ID for your network.

   • chain.chain-name - A name of your choice for the chain.

   • chain.InitialChainOwner - Builder wallet address.

   • bridge and associated fields - Contract addresses obtained in Step 2.

   • node.batch-poster.parent-chain-wallet.private-key - Private key for the builder wallet.

   • node.staker.parent-chain-wallet.private-key - Private key for the staker wallet (use a different wallet from the builder).

   • node.avail.seed - Seed phrase for the Avail wallet you created initially.

   • node.avail.app-id - App ID obtained for Avail.

   • node.avail.arbSepolia-rpc - RPC URL for Arbitrum Sepolia (obtainable from providers like Alchemy or Infura).

   Here’s an example configuration:

   {
     "chain": {
       "info-json": "[{\"chain-id\":<Insert your chain-id>,\"parent-chain-id\":421614,\"parent-chain-is-arbitrum\":true,\"chain-name\":\"<Insert chain name>\",\"chain-config\":{\"homesteadBlock\":0,\"daoForkBlock\":null,\"daoForkSupport\":true,\"eip150Block\":0,\"eip150Hash\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\"eip155Block\":0,\"eip158Block\":0,\"byzantiumBlock\":0,\"constantinopleBlock\":0,\"petersburgBlock\":0,\"istanbulBlock\":0,\"muirGlacierBlock\":0,\"berlinBlock\":0,\"londonBlock\":0,\"clique\":{\"period\":0,\"epoch\":0},\"arbitrum\":{\"EnableArbOS\":true,\"AllowDebugPrecompiles\":false,\"DataAvailabilityCommittee\":false,\"InitialArbOSVersion\":11,\"GenesisBlockNum\":0,\"MaxCodeSize\":24576,\"MaxInitCodeSize\":49152,\"InitialChainOwner\":\"<Insert chain owner address>\"},\"chainId\":<Insert chain id>},\"rollup\":{\"bridge\":\"<Bridge proxy address>\",\"inbox\":\"<Inbox address>\",\"sequencer-inbox\":\"<Sequencer inbox address>\",\"rollup\":\"<Rollup proxy address>\",\"validator-utils\":\"<Validator until address>\",\"validator-wallet-creator\":\"<Validator wallet creator address>\",\"deployed-at\":<Insert deployed-at block number>}}]",
       "name": "<Insert chain name>"
     },
     "parent-chain": {
       "connection": {
         "url": "https://sepolia-rollup.arbitrum.io/rpc"
       }
     },
     "http": {
       "addr": "0.0.0.0",
       "port": 8449,
       "vhosts": [
         "*"
       ],
       "corsdomain": [
         "*"
       ],
       "api": [
         "eth",
         "net",
         "web3",
         "arb",
         "debug"
       ]
     },
     "node": {
       "sequencer": true,
       "delayed-sequencer": {
         "enable": true,
         "use-merge-finality": false,
         "finalize-distance": 1
       },
       "batch-poster": {
         "max-size": 90000,
         "enable": true,
         "parent-chain-wallet": {
           "private-key": "<Insert your private key here>"
         }
       },
       "staker": {
         "enable": true,
         "strategy": "MakeNodes",
         "parent-chain-wallet": {
           "private-key": "<Insert your private key here>"
         }
       },
       "dangerous": {
         "no-sequencer-coordinator": true
       },
       "avail": {
         "enable": true,
         "seed": "<Enter your seed phrase here>",
         "avail-api-url": "wss://turing-rpc.avail.so/ws",
         "app-id": <Enter your avail app id>,
         "timeout":"100s",
         "vectorx": "0xA712dfec48AF3a78419A8FF90fE8f97Ae74680F0",
         "arbSepolia-rpc": "<Enter an arbSepolia wss url here>"
       }
     },
     "execution": {
       "forwarding-target": "",
       "sequencer": {
         "enable": true,
         "max-tx-data-size": 85000,
         "max-block-speed": "250ms"
       },
       "caching": {
         "archive": true
       }
     }
   }
    
   

   Fill in the required values, including private keys, app-id, and any other specified parameters.

Step 4: Configure orbitSetupScriptConfig.json

In ./config/orbitSetupScriptConfig.json, enter your chain information as outlined below:

• networkFeeReceiver - Builder wallet address.

• infrastructureFeeCollector - Builder wallet address.

• staker - Staker wallet address.

• batchPoster - Builder wallet address.

• chainOwner - Builder wallet address.

• chainId - Chain ID for your network.

• chainName - Chain name.

• minL2BaseFee - Set this to 100000000.

• parentChainId - Set to 421614.

• parent-chain-node-url - https://sepolia-rollup.arbitrum.io/rpc.

Below is an example configuration:

{
  "networkFeeReceiver": "0xd41996ED89bb5BF7dBfB181D8D93E8067446200B",
  "infrastructureFeeCollector": "0xd41996ED89bb5BF7dBfB181D8D93E8067446200B",
  "staker": "0xDF819f9Fc3c28FEDFb73374C7B60A4f9BCdE6710",
  "batchPoster": "0xB0Ad5AE0a78025613F17B7e4644CE5752487B9d6",
  "chainOwner": "0xd41996ED89bb5BF7dBfB181D8D93E8067446200B",
  "chainId": 99584959107,
  "chainName": "My Arbitrum L3 Chain",
  "minL2BaseFee": 100000000,
  "parentChainId": 421614,
  "parent-chain-node-url": "https://sepolia-rollup.arbitrum.io/rpc",
  "utils": "0xB11EB62DD2B352886A4530A9106fE427844D515f",
  "rollup": "0xd30eCcf27A6f351EfA4fc9D17e7ec20354309aE3",
  "inbox": "0x4512e40a1ec8555f9e93E3B6a06af60F13538087",
  "nativeToken": "0x0000000000000000000000000000000000000000",
  "outbox": "0x2209755fA3470ED1AFFB4407d1e3B1f7dFC13ce9",
  "rollupEventInbox": "0x1e58240B2D769de25B4811354819C901317D0894",
  "challengeManager": "0xfC5BbC40d24EcD6FcC247EfFDc87E7D074E9B67D",
  "adminProxy": "0xf488b25e6736Ed74E8d37EA434892129E4d62E3B",
  "sequencerInbox": "0xD15347309854F1290c9a382ea2719AB5462c7719",
  "bridge": "0xC83ee8e28B7b258f41aF8ef4279c02f901288029",
  "upgradeExecutor": "0x805bB07B88dDA56030eC48644E0C276e2e5E3949",
  "validatorUtils": "0xB11EB62DD2B352886A4530A9106fE427844D515f",
  "validatorWalletCreator": "0xEb9885B6c0e117D339F47585cC06a2765AaE2E0b",
  "deployedAtBlockNumber": 11274529
}

Step 5: Download the Docker Image

Retrieve the avail-nitro-node Docker image using the command below:

docker pull availj/avail-nitro-node:v2.1.0-upstream-v3.1.1

Step 6: Update the docker-compose File in orbit-setup-script

In the docker-compose file, replace the relevant image field:

nitro:
  image: availj/avail-nitro-node:v2.1.0-upstream-v3.1.1
  ports:
  ...

Step 7: Run Your Chain

You’re almost there! From the root directory of the orbit-setup-script, run:

docker-compose up -d

Visit http://localhost:8449/ for RPC access and http://localhost/ to check out your BlockScout explorer.

Wrapping Up: You Did It!

That’s it! You've built your own L3 rollup chain on Arbitrum Orbit with Avail DA. Give yourself a pat on the back—you’re now part of an elite group of blockchain pioneers. Whether you’re here for innovation, learning, or just a thrilling ride, keep pushing the boundaries. The blockchain world is your oyster! 🚀

Appendix A: Checking Your Chain Logs 📝

Keeping an eye on your chain’s logs is crucial to ensure everything is running smoothly. Here’s how you can do it with a single command:

Navigate to the root directory of your Orbit setup script and run:

docker-compose logs -f nitro

This command streams real-time logs, so you can spot any issues or just confirm your chain is running as expected.

Appendix B: Depositing ETH/Native Tokens 💸

Need to top up your Orbit chain account with ETH or native tokens? Here’s how to do it:

1. Make sure you’re in the base directory of your setup script.

2. Run the following command, but don’t forget to replace 0xYourPrivateKey with your actual private key and <AMOUNT> with the number of tokens you want to send:

PRIVATE_KEY="0xYourPrivateKey" L2_RPC_URL="https://sepolia-rollup.arbitrum.io/rpc" L3_RPC_URL="http://localhost:8449" AMOUNT="<AMOUNT>" yarn run deposit

Tip: Triple-check your private key for typos or unwanted spaces to avoid any hiccups!

Bonus: Adding Your Orbit Chain to MetaMask 🦊

What’s a new chain without the ability to manage it through MetaMask? Here’s a quick way to add your Orbit chain:

1. Open MetaMask and navigate to Settings > Networks.

2. Click Add Network and fill in the following details:

   • Network Name: My Orbit Chain (or any name you prefer)

   • New RPC URL: http://localhost:8449

   • Chain ID: 123456 (replace with your chain’s ID if different)

   • Currency Symbol: ETH

   • Block Explorer URL: (Leave empty or add if available)

3. Hit Save, and you’re ready to manage your Orbit chain seamlessly through MetaMask!

Voilà! Now you’re equipped to monitor logs, deposit ETH, and use MetaMask with your chain. It's time to see your L3 in action. 🚀

These questions bring us to the concept of Data Availability Sampling (DAS), a crucial tool for blockchain scaling and security. DAS lets nodes confirm that all necessary data in a block is present without downloading the entire thing. But how does this magic happen? Let’s dive in and explore DAS through a fun analogy that makes the process easier to understand.

Understanding DAS Through a Story

Imagine you and your friends are contributing to a huge art mural for a community event. The mural is assembled from individual square tiles that everyone decorates, and once complete, it’s set up in a gallery with a big, locked glass case over it.

People want to verify that the mural is complete and untampered, but the gallery only allows visitors to look at it through small peepholes in the glass case. These peepholes are placed randomly, so each visitor can only see a few random sections of the mural. You’re confident that if enough people check enough peepholes and verify the tiles they see, you can be sure the entire mural is intact without anyone having to see the entire mural at once. This is the same concept used in Data Availability Sampling.

How DAS Works in Blockchain Terms

In the blockchain world, a “block” of data includes all the transactions and information for a specific time period. Traditionally, for security and verification, every node on the network would need to download and store all this data. This approach, however, becomes impractical as blockchains scale up, especially with popular Layer 2 solutions like rollups. This is where DAS shines: it allows nodes to check smaller, random sections of each block to ensure all the data is available.

Breaking It Down: The Mechanics of DAS

1. Random Sampling: Instead of downloading an entire block, each node samples small, random portions of the block’s data. In our mural analogy, this is like people peeking through random peepholes to see if everything looks right.

2. Collective Assurance: If enough nodes (or “visitors” in our analogy) check enough parts of the block and confirm that their pieces are intact, then the network collectively trusts that the block’s data is complete.

3. Catching Dishonest or Missing Data: What if someone tries to cheat by hiding or tampering with data? In our story, if someone removed or altered parts of the mural, random checks by enough people would likely catch this because some peeks would reveal missing or suspicious areas. Similarly, in DAS, if data is missing, nodes checking random sections will notice it, raising an alert and preventing the block from being trusted.

Another Everyday Story: Spot Checking at Work

DA’s sampling reminded me of how I used to check inventory at a previous job. We had so much stock that it was impossible to check every item. Instead, we’d do random spot checks to confirm that everything matched our records. If a few random samples were accurate, we trusted the whole inventory was in good shape.

This is essentially what DA does for rollups. It’s about verifying just enough data to trust the whole dataset. If nodes can confirm a small portion of the data, the blockchain assumes all the data is there, which allows for scalability and efficiency that I used to think wasn’t even possible in blockchain.

Why DAS is Essential for Scalable Blockchains

Blockchains need to be efficient and secure to accommodate growing transaction volumes. DAS is a game-changer because it tackles two big challenges simultaneously:

• Efficiency: By allowing nodes to check only small portions of a block’s data, DAS dramatically reduces the amount of storage and computation each node needs. This means more lightweight and resource-limited devices can participate in the network.

• Security with Scale: DAS maintains the network’s security even as the blockchain scales. Instead of every node needing to verify every bit of data, random sampling allows us to trust that all data is available. This lets the network expand without becoming overloaded.

Another Real-World Example: The Community Recipe Book

Consider a community where each member contributes recipes to a giant recipe book, but no one can see the entire book. Instead, randomly selected “reviewers” each receive a few pages to check for authenticity. If all reviewers report that their sections are intact and well-formatted, the community can trust the entire book without anyone seeing it all. If, however, any reviewer finds a missing or incorrect page, they’ll raise a flag, and others can check that specific area.

In DAS, every node plays the role of the reviewer, checking random parts of the “recipe book” (the data block) and collectively confirming its completeness.

The Technical Side of DAS

In blockchains, nodes use cryptographic tools to handle the random sampling efficiently. Here’s how it typically works in practice:

1. Data Splitting and Sampling: When a block is created, it’s split into smaller pieces. Each node in the network is responsible for checking a few random pieces.

2. Cross-Node Verification: Because nodes independently check random pieces, a large enough number of nodes performing these random checks can verify the full data’s availability. Even if some nodes are dishonest or malfunctioning, the majority’s consensus will ensure the data’s validity.

3. Error Detection and Recovery: If missing or corrupted data is found in a sample, the network can respond by either rejecting the block or requiring further checks.

The Role of DAS in Layer 2 Solutions Like Rollups

Layer 2 solutions, such as rollups, bundle transactions into batches to be processed more efficiently off the main blockchain (Layer 1). These batches are then anchored to Layer 1, maintaining security without overloading the primary chain.

DAS is essential here because it ensures data availability for these batches without requiring Layer 1 to handle all the data. By relying on DAS, Layer 2 solutions can confirm that the data they send to Layer 1 is intact, scalable, and secure without needing to process everything on-chain.

Looking Ahead: DAS for the Future of Blockchain

As blockchains continue to grow, especially with advancements in Layer 2 technologies, DAS will be a cornerstone of efficient, secure, and scalable blockchain systems. It allows blockchain networks to onboard more users and handle higher transaction volumes without compromising on security or accessibility.

Through techniques like DAS, we’re building a blockchain future that’s lighter, faster, and still as reliable as ever. This means that as blockchains continue to scale, we can be confident in their data integrity without weighing down every participant with endless storage and computational needs.

So, the next time you hear about blockchain scalability, remember DAS and the power of sampling. With a little teamwork and a lot of clever design, we’re making sure that even the largest data can be verified, one sample at a time.

Starting with a Question: Why Does Data Matter?

Imagine you’re part of a group project in school or at work. Everyone has specific tasks, but at the end of the day, for the project to make sense, everyone needs to have access to the same information. If someone decides to keep their part of the project to themselves, the whole thing falls apart. You can’t present an incomplete project to your teacher or boss, right?

In the blockchain world, "data" works a bit like that. Every transaction on a blockchain is part of a bigger project (the full record of transactions) that needs to be accessible to everyone to ensure that the system is working correctly. This is where Data Availability (DA) comes in. It's about making sure everyone in the system has access to the necessary data to validate transactions and keep everything transparent.

So, What’s the Role of DA in Rollups?

Okay, but what does this mean for rollups? Well, rollups, as you may know, are a way to scale blockchains by bundling (or “rolling up”) transactions off the main chain. Imagine a theme park where instead of each person going through the entrance gate one by one, you gather groups together to speed things up (we’ve talked about rollups like this before, right?). Now, after rolling up these transactions, you still need to “publish” them somewhere so everyone knows they happened. And this is where DA steps in.

In short, DA ensures that the data behind those bundled transactions is available for everyone to check if they want to. Without reliable DA, the whole rollup idea wouldn’t work—because how could anyone trust that the transactions in those rollups are valid if they can’t see the data behind them?

A Real-Life Analogy: The Public Notice Board

Think of DA like a public notice board in a town square. Imagine there's a rule that every group project (our rollup, in this case) needs to be pinned to this board for everyone to see. If someone has doubts about whether the work was done correctly, they can walk up to the board, check the details, and verify it.

In blockchain terms, DA is that "public board" where transaction data is posted so that anyone can verify it later if needed. It’s a way of saying, “Hey, here’s the proof of what we’ve done, in case anyone wants to double-check.”

Why Does DA Matter So Much?

Now, you might be thinking, "But why can’t we just assume things are fine if the rollup says so?" Well, let’s go back to our project analogy.

Imagine if, one day, someone in the group decided to submit work without sharing their part with anyone else, assuming “Trust me, I did my part.” Now, even if they’re telling the truth, it’s risky to trust without verification. In blockchain, trust is built on transparency, and DA is a key part of that transparency.

If the data isn’t available for everyone to see, it opens the door to potential fraud. Someone could sneak in false information, and there would be no way to verify it without DA. With DA, however, you have that safety net: everyone can see, check, and verify the data, maintaining trust across the network.

Is DA Just an Off-Chain Database Like AWS or Cloud Storage? How Is DA Different from IPFS and Filecoin?

You’re right that DA solutions have some similarities to off-chain databases or cloud storage, but there are some key differences. Let’s break it down:

Data Availability (DA) Layers vs. Traditional Cloud Storage (AWS, Google Cloud, etc.)

• Purpose: DA layers are designed specifically for the needs of blockchains, focusing on making data publicly accessible and verifiable. In contrast, AWS or Google Cloud are general-purpose storage solutions that don’t have built-in transparency or immutability features.

• Trust Model: DA layers are usually decentralized, meaning there isn’t a single company or central authority controlling access. They’re designed so that data is verifiable and accessible to all participants on the blockchain. With AWS or Google Cloud, you rely on the cloud provider to manage your data, which isn’t ideal for decentralized applications.

How DA Layers Compare to Decentralized Storage like IPFS and Filecoin

• Purpose and Design: DA layers (like Celestia) are built specifically to store transaction data or proofs that are essential for verifying rollup transactions on the blockchain. They are not meant for storing large files or arbitrary data like documents or videos. Instead, they are optimized to make transaction data available quickly for verification purposes.

• Data Verification: In DA layers, the emphasis is on making sure that specific blockchain-related data is always accessible and verifiable. With IPFS or Filecoin, the focus is on storing large files in a decentralized way, where content is referenced by a hash (content addressable). While IPFS makes it possible to find and retrieve data, it doesn’t guarantee that data will be available unless it’s "pinned" or specifically hosted by nodes.

• Economic Model: DA layers and IPFS/Filecoin differ in how they incentivize data availability. Filecoin, for example, uses a proof mechanism where miners are incentivized to store and make data available. In contrast, DA layers often integrate more directly with rollup protocols, ensuring that essential blockchain data remains available for validation.

To Summarize: DA Layers vs. IPFS/Filecoin

• DA Layers: Designed specifically for blockchain transaction data, to make it available and verifiable. They work closely with rollups to publish transaction data in a way that can be checked by the main blockchain.

• IPFS/Filecoin: Primarily designed to store general-purpose files in a decentralized way. Filecoin provides incentives for long-term data storage but doesn’t focus on transaction-level data verification for blockchains.

Why Not Just Use IPFS or Filecoin as DA?

While IPFS and Filecoin are great for decentralized file storage, they don’t meet all the requirements needed for rollup DA:

1. Immediate Availability: Rollups need data to be available quickly and reliably so that it can be verified by anyone, anytime. DA solutions for rollups ensure that data is accessible as soon as it’s published.

2. Data Integrity and Verification: Rollups rely on DA layers to ensure data integrity and that transaction data is available for auditing and dispute resolution if needed. IPFS and Filecoin focus on file storage rather than specific transaction-level verification.

3. Optimized for Transaction Data: DA layers like Celestia are built specifically for blockchain transaction data, which makes them lightweight and efficient for verifying rollups, whereas IPFS/Filecoin are not optimized for such use cases.

Different Ways Rollups Handle Data Availability

So, how do different rollups ensure DA? There are a couple of ways, each with its own pros and cons.

1. On-Chain DA (Layer 1): This is the most straightforward way—publish all the data directly on the blockchain. It’s like pinning your project on the main notice board where everyone can see it. It’s reliable, but can be expensive because storing data on-chain is costly.

2. Off-Chain DA Solutions: Some rollups publish their data off-chain, using specialized DA layers or committees. Imagine a side notice board managed by a trusted group in town, with rules to ensure they keep things transparent. It’s usually cheaper but can introduce some trust assumptions.

3. DA Layers (like Celestia): New solutions are being developed that specialize only in DA, like Celestia. These are like dedicated public notice boards only for data availability, designed to store data reliably and make it accessible to anyone who wants to verify it. This could be a game-changer for rollups in terms of scalability and efficiency.

For example Celestia:

• Data availability is a core scaling bottleneck for crypto applications and is the vast majority of costs that rollups and Layer 2s pay.

• Data availability is about proving that data was published by allowing anyone to download it for a short period of time.

• A DA layer is a blockchain that rollups and L2s publish their transaction data to.

• Celestia’s DA layer eliminates data availability as a core scaling bottleneck, dropping costs for developers by ~95% and enabling them to build fully-onchain apps.

• This celestia also uses new technology called DAS(data availability sampling ). We will explore more detail about it in my next blogs.

Why DA and Rollups are the Perfect Team for Blockchain Scaling

The beauty of rollups is that they allow blockchains to scale by moving transactions off the main chain while still ensuring security. But without DA, rollups would lose this trustworthiness. DA provides a check to ensure that off-chain transactions are still verifiable. It’s like combining the speed of using shortcuts with the safety of public oversight.

In Simple Terms: DA Makes Rollups Trustworthy

If I were to put it simply: DA is like a safeguard that makes sure all transactions processed by rollups are available for public verification. Without DA, we’d have faster transactions, but we’d lose the transparency that blockchains rely on.

So, next time you hear about DA and rollups, think about that public notice board in the town square. It’s there to keep things fair, transparent, and trustworthy, allowing us to scale blockchains while preserving the core principle of transparency.

Final Thoughts: A Must-Have for Scaling

Data Availability might seem like a technical detail, but it's essential for the future of scalable and secure blockchain technology. It’s what makes it possible for rollups to thrive, providing faster, cheaper transactions while keeping the trust that blockchains are known for. DA is not just a feature; it’s a foundational piece of how blockchains can scale effectively.

So, in the quest for scaling blockchains, remember: DA is like the unsung hero behind the scenes, quietly ensuring that everything we do remains transparent, accessible, and verifiable for everyone involved.

What is Stackr Labs?

Stackr Labs gives your dapp a turbo boost! With Micro-Rollups (MRUs), helps developers build fast, scalable apps. Think of it like preparing food at home for a trip—most of the work happens off-chain, ensuring a smoother experience on the blockchain!

Table of Contents

1. Prerequisites

2. Setting Up Your Project

3. Creating the State Machine

4. Implementing the Game Logic

5. Frontend Integration

6. Testing Your Game

7. Conclusion

Prerequisites

Before we dive in, make sure you have the following tools installed:

• Node.js: Download and install from Node.js

• Git: Download and install from Git

• Bun: Installation guide can be found here

• Stackr CLI: Install globally using:

  bun install -g @stackr/cli
  

Create a New Directory:

mkdir tic-tac-toe
cd tic-tac-toe

Initialize a New Stackr Project:

bunx @stackr/cli@latest init

Setting Up Your Project

You can use the following .env values:

# PRIVATE_KEY is the hex-encoded private key of the Ethereum address that will act as the rollup operator.
PRIVATE_KEY= --YOUR DEVELOPMENT PRIVATE KEY--

# L1_RPC is the RPC endpoint of the L1 chain. Can be found in the network config docs above.
L1_RPC=https://rpc2.sepolia.org/

# VULCAN_RPC is the RPC endpoint of the Vulcan network. Can be found in the network config docs above.
VULCAN_RPC=https://sepolia.vulcan.stf.xyz/

# REGISTRY_CONTRACT is the address of the Stackr registry contract on the L1 chain. Can be found in the network config docs above.
REGISTRY_CONTRACT=0x985bAfb3cAf7F4BD13a21290d1736b93D07A1760

# DATABASE_URI is the connection URI of the SQL database.
DATABASE_URI=./db.sqlite

# NODE_ENV is the current environment (production or development). Relevant for express.js server.
NODE_ENV=development

Creating the state machine

In this section, we’ll define the game state using Stackr’s state management.

src/stackr/state.ts

import { BytesLike, solidityPackedKeccak256 } from "ethers";
import { State } from "@stackr/sdk/machine";

// Define the structure of a Tic Tac Toe game
interface Game {
  gameId: string;
  owner: string; // Player X's address
  playerO: string; // Player O's address
  board: string[]; // 9 cells represented as a string array
  currentPlayer: "X" | "O";
  winner: "X" | "O" | "Draw" | null;
  startedAt: number;
  endedAt: number | null;
}

// Define the overall application state
export interface AppState {
  games: Record<string, Game>;
}

// Initial state of the application
export const initialState: AppState = {
  games: {},
};

// TicTacToeState class extends the State class from @stackr/sdk
export class TicTacToeState extends State<AppState> {
  constructor(state: AppState) {
    super(state);
  }

  // Generate a root hash of the current state
  // This is used for state verification and integrity checks
  getRootHash(): BytesLike {
    return solidityPackedKeccak256(
      ["string"],
      [JSON.stringify(this.state.games)]
    );
  }
}

Explanation:

• We define an interface Game to represent the state of the Tic Tac Toe game.

• The initialState sets up the initial conditions, including an empty board and the starting player.

• A State instance is created to manage the game state.

Implementing the Game Logic

Next, we’ll add the logic to handle player moves and check for wins.

src/stackr/machine.ts

import { StateMachine } from "@stackr/sdk/machine";
import { TicTacToeState, initialState } from "./state";
import { transitions } from "./transitions";

// Define the State Machine for Tic Tac Toe
const machine = new StateMachine({
  id: "tic-tac-toe", // Unique identifier for this state machine
  stateClass: TicTacToeState, // The state class used by this machine
  initialState, // Initial state
  on: transitions, // Transitions that can be applied to the state
});

export { machine 

Explanation:

• StateMachine: Initializes the state machine with an ID, state class, initial state, and available transitions.

Implementing Transitions

src/stackr/transitions.ts

Define the possible actions/transitions in the game.

// src/stackr/transitions.ts

import { Transitions, SolidityType } from "@stackr/sdk/machine";
import { TicTacToeState } from "./state";
import { hashMessage } from "ethers";

const winningCombinations: number[][] = [
  [0, 1, 2],
  [3, 4, 5],
  [6, 7, 8],
  [0, 3, 6],
  [1, 4, 7],
  [2, 5, 8],
  [0, 4, 8],
  [2, 4, 6],
];

// Define the createGame transition
const createGame = TicTacToeState.STF({
  schema: {
    owner: SolidityType.ADDRESS,
    playerO: SolidityType.ADDRESS,
    startedAt: SolidityType.UINT,
  },
  handler: ({ state, inputs, msgSender, block, emit }) => {
    // Ensure that msgSender matches inputs.owner
    if (msgSender.toLowerCase() !== inputs.owner.toLowerCase()) {
      emit({
        name: "InvalidSigner",
        value: `${msgSender} is not authorized to create a game.`,
      });
      return state;
    }

    // Generate a unique game ID
    const gameId = hashMessage(
      `${msgSender}::${block.timestamp}::${Object.keys(state.games).length}`
    );

    // Initialize the new game
    state.games[gameId] = {
      gameId,
      owner: inputs.owner,
      playerO: inputs.playerO,
      board: Array(9).fill(""),
      currentPlayer: "X",
      winner: null,
      startedAt: inputs.startedAt,
      endedAt: null,
    };

    // Emit an event for game creation
    emit({
      name: "GameCreated",
      value: gameId,
    });

    return state;
  },
});

// Define the makeMove transition
const makeMove = TicTacToeState.STF({
  schema: {
    gameId: SolidityType.STRING,
    index: SolidityType.UINT,
    player: SolidityType.STRING, // "X" or "O"
  },
  handler: ({ state, inputs, msgSender, block, emit }) => {
    const { gameId, index, player } = inputs;
    const game = state.games[gameId];

    if (!game) {
      emit({
        name: "GameNotFound",
        value: gameId,
      });
      return state;
    }

    // Validate player
    if (player !== game.currentPlayer) {
      emit({
        name: "InvalidPlayer",
        value: `${player} attempted to move.`,
      });
      return state;
    }

    // Validate move
    if (game.board[index] !== "") {
      emit({
        name: "InvalidMove",
        value: `${index} is already occupied.`,
      });
      return state;
    }

    // Make the move
    game.board[index] = player;

    // Check for a winner
    let winner: "X" | "O" | "Draw" | null = null;
    for (const combination of winningCombinations) {
      const [a, b, c] = combination;
      if (
        game.board[a] &&
        game.board[a] === game.board[b] &&
        game.board[a] === game.board[c]
      ) {
        winner = game.board[a] as "X" | "O";
        break;
      }
    }

    // Check for draw
    if (!winner && game.board.every((cell) => cell !== "")) {
      winner = "Draw";
    }

    if (winner) {
      game.winner = winner;
      game.endedAt = block.timestamp;
      emit({
        name: "GameEnded",
        value: `${gameId}::${winner}`,
      });
    } else {
      // Switch player
      game.currentPlayer = player === "X" ? "O" : "X";
      emit({
        name: "MoveMade",
        value: `${gameId}::${player}::${index}`,
      });
    }

    return state;
  },
});

// Define the resetGame transition
const resetGame = TicTacToeState.STF({
  schema: {
    gameId: SolidityType.STRING,
  },
  handler: ({ state, inputs, msgSender, block, emit }) => {
    const { gameId } = inputs;
    const game = state.games[gameId];

    if (!game) {
      emit({
        name: "GameNotFound",
        value: gameId,
      });
      return state;
    }

    // Only the game owner can reset the game
    if (msgSender.toLowerCase() !== game.owner.toLowerCase()) {
      emit({
        name: "UnauthorizedReset",
        value: `${msgSender} is not authorized to reset the game.`,
      });
      return state;
    }

    // Reset the game
    state.games[gameId] = {
      ...game,
      board: Array(9).fill(""),
      currentPlayer: "X",
      winner: null,
      endedAt: null,
    };

    emit({
      name: "GameReset",
      value: gameId,
    });

    return state;
  },
});

// Export the transitions
export const transitions: Transitions<TicTacToeState> = {
  createGame,
  makeMove,
  resetGame,
};

Explanation:

• createGame Transition: Initializes a new Tic Tac Toe game with two players.

• makeMove Transition: Processes a player's move, updates the board, checks for a winner or draw, and switches the current player.

• resetGame Transition: Resets an existing game to its initial state.

Stackr Labs Integration

src/stackr/mru.ts

Initialize and configure the Stackr Micro-Rollup (MRU) instance.

import { MicroRollup } from "@stackr/sdk";
import { stackrConfig } from "../../stackr.config";
import { machine } from "./machine";

// Create a new MRU instance
const mru = await MicroRollup({
  config: stackrConfig, // Configuration for the MRU
  stateMachines: [machine], // State machines used by the MRU
});

export { mru };

Explanation:

• MicroRollup: Represents the Stackr MRU instance.

• stateMachines: Array of state machines the MRU will manage.

Main Application Logic

src/index.ts

Set up the Express server, define API endpoints, and integrate with Stackr.

import { ActionConfirmationStatus, MicroRollup } from "@stackr/sdk";
import { machine } from "./stackr/machine";
import { Playground } from "@stackr/sdk/plugins";
import express, { Request, Response } from "express";
import { mru } from "./stackr/mru";
import path from "path";
import dotenv from "dotenv";
import { verifyTypedData } from "ethers";

dotenv.config();

/**
 * Main function to set up and run the Stackr micro rollup server
 */
const main = async () => {
  // Initialize the MRU instance
  await mru.init();

  // Initialize the Playground plugin for debugging and testing
  Playground.init(mru);

  // Set up Express server
  const app = express();
  const PORT = process.env.PORT || 3012;

  app.use(express.json());

  // Serve static files from the "public" directory
  app.use(express.static(path.join(__dirname, "public")));

  // Enable CORS for all routes
  app.use((_req, res, next) => {
    res.header("Access-Control-Allow-Origin", "*");
    res.header(
      "Access-Control-Allow-Headers",
      "Origin, X-Requested-With, Content-Type, Accept"
    );
    next();
  });

  // Serve the HTML file for the Tic Tac Toe game
  app.get("/", (req: Request, res: Response) => {
    res.sendFile(path.join(__dirname, "public", "tic_tac_toe.html"));
  });

  /**
   * GET /info - Retrieve information about the MicroRollup instance
   * Returns domain information and schema map for action reducers
   */
  app.get("/info", (req: Request, res: Response) => {
    const schemas = mru.getStfSchemaMap();
    const { name, version, chainId, verifyingContract, salt } =
      mru.config.domain;
    res.send({
      signingInstructions: "signTypedData(domain, schema.types, inputs)",
      domain: {
        name,
        version,
        chainId,
        verifyingContract,
        salt,
      },
      schemas,
    });
  });

  /**
   * POST /createGame - Submit a createGame action
   */
  app.post("/createGame", async (req: Request, res: Response) => {
    const reducerName = "createGame";
    const actionReducer = mru.getStfSchemaMap()[reducerName];

    if (!actionReducer) {
      res.status(400).send({ message: "NO_REDUCER_FOR_ACTION" });
      return;
    }

    try {
      const { msgSender, signature, inputs } = req.body;

      // Log received data for debugging
      console.log(`Received createGame action from: ${msgSender}`);
      console.log(`Inputs:`, inputs);
      console.log(`Signature: ${signature}`);

      const schemaTypes = {
        createGame: [
          { name: "owner", type: "address" },
          { name: "playerO", type: "address" },
          { name: "startedAt", type: "uint256" },
        ],
        Action: [
          { name: "name", type: "string" },
          { name: "inputs", type: "createGame" },
        ],
      };

      const createGameAction = {
        name: "createGame",
        inputs: inputs,
      };


      const actionParams = {
        name: reducerName,
        inputs,
        signature,
        msgSender,
      };

      // Submit the action to the MicroRollup instance
      const ack = await mru.submitAction(actionParams);

      // Wait for the action to be confirmed (C1 status)
      const { errors, logs } = await ack.waitFor(ActionConfirmationStatus.C1);

      if (errors?.length) {
        console.error("Action errors:", errors);
        throw new Error(errors[0].message);
      }

      res.status(201).send({ logs });
    } catch (e: any) {
      console.error("Error processing action:", e.message);
      res.status(400).send({ error: e.message });
    }

    return;
  });

  /**
   * POST /makeMove - Submit a makeMove action
   */
  app.post("/makeMove", async (req: Request, res: Response) => {
    const reducerName = "makeMove";
    const actionReducer = mru.getStfSchemaMap()[reducerName];

    if (!actionReducer) {
      res.status(400).send({ message: "NO_REDUCER_FOR_ACTION" });
      return;
    }

    try {
      const { msgSender, signature, inputs } = req.body;

      // Log received data for debugging
      console.log(`Received makeMove action from: ${msgSender}`);
      console.log(`Inputs:`, inputs);
      console.log(`Signature: ${signature}`);

      const actionParams = {
        name: reducerName,
        inputs,
        signature,
        msgSender,
      };

      // Submit the action to the MicroRollup instance
      const ack = await mru.submitAction(actionParams);

      // Wait for the action to be confirmed (C1 status)
      const { errors, logs } = await ack.waitFor(ActionConfirmationStatus.C1);

      if (errors?.length) {
        console.error("Action errors:", errors);
        throw new Error(errors[0].message);
      }

      res.status(201).send({ logs });
    } catch (e: any) {
      console.error("Error processing action:", e.message);
      res.status(400).send({ error: e.message });
    }

    return;
  });

  /**
   * POST /resetGame - Submit a resetGame action
   */
  app.post("/resetGame", async (req: Request, res: Response) => {
    const reducerName = "resetGame";
    const actionReducer = mru.getStfSchemaMap()[reducerName];

    if (!actionReducer) {
      res.status(400).send({ message: "NO_REDUCER_FOR_ACTION" });
      return;
    }

    try {
      const { msgSender, signature, inputs } = req.body;

      // Log received data for debugging
      console.log(`Received resetGame action from: ${msgSender}`);
      console.log(`Inputs:`, inputs);
      console.log(`Signature: ${signature}`);

      const actionParams = {
        name: reducerName,
        inputs,
        signature,
        msgSender,
      };

      // Submit the action to the MicroRollup instance
      const ack = await mru.submitAction(actionParams);

      // Wait for the action to be confirmed (C1 status)
      const { errors, logs } = await ack.waitFor(ActionConfirmationStatus.C1);

      if (errors?.length) {
        console.error("Action errors:", errors);
        throw new Error(errors[0].message);
      }

      res.status(201).send({ logs });
    } catch (e: any) {
      console.error("Error processing action:", e.message);
      res.status(400).send({ error: e.message });
    }

    return;
  });

  /**
   * GET /games - Retrieve all games from the state machine
   */
  app.get("/games", async (req: Request, res: Response) => {
    const { games } = machine.state;
    res.json(games);
  });

  /**
   * GET /games/:gameId - Retrieve a specific game by ID
   */
  app.get("/games/:gameId", async (req: Request, res: Response) => {
    const { gameId } = req.params;
    const { games } = machine.state;

    const game = games[gameId];

    if (!game) {
      res.status(404).send({ message: "GAME_NOT_FOUND" });
      return;
    }

    res.json(game);
  });

  // Start the server
  app.listen(PORT, () => {
    console.log(`Server running on http://localhost:${PORT}`);
  });
};

// Run the main function
main().catch((error) => {
  console.error("Error starting the server:", error);
});

Explanation:

• /info Endpoint: Provides information about the MRU's domain and schemas.

• /:reducerName Endpoint: Accepts actions to perform state transitions (e.g., createGame, makeMove, resetGame).

• /games & /games/:gameId Endpoints: Retrieve all games or a specific game respectively.

• CORS: Enabled for all routes to allow cross-origin requests.

• Static Files: Serves the frontend from the public directory.

Frontend Implementation

A. Create the Frontend Directory

Create a public directory inside your project root to store frontend files.

mkdir src/public
touch src/public/tic-tac-toe.html

B. src/public/tic-tac-toe.html

Create the HTML and JavaScript frontend for the Tic Tac Toe game.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Tic Tac Toe - Stackr Labs</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            text-align: center;
            margin-top: 50px;
        }
        #board {
            display: grid;
            grid-template-columns: repeat(3, 100px);
            grid-gap: 5px;
            justify-content: center;
            margin: 20px auto;
        }
        .cell {
            width: 100px;
            height: 100px;
            border: 2px solid #333;
            display: flex;
            align-items: center;
            justify-content: center;
            font-size: 48px;
            cursor: pointer;
        }
        #message {
            margin-top: 20px;
            font-size: 24px;
        }
        #controls {
            margin-top: 30px;
        }
        button {
            padding: 10px 20px;
            font-size: 16px;
            margin: 0 10px;
            cursor: pointer;
        }
    </style>
</head>
<body>

<h1>Tic Tac Toe</h1>

<div id="gameControls">
    <button id="createGame">Create New Game</button>
</div>

<div id="board"></div>

<div id="message"></div>

<div id="controls">
    <button id="resetGame">Reset Game</button>
</div>

<script src="https://cdn.jsdelivr.net/npm/ethers@5.7.0/dist/ethers.umd.min.js"></script>
<script>
    const provider = new ethers.providers.Web3Provider(window.ethereum);
    let signer;
    let gameId = null;
    let gameState = null;

    const messageElement = document.getElementById("message"); // Properly defined

    // Initialize the app
    async function init() {
        try {
            // Request account access if needed
            await provider.send("eth_requestAccounts", []);
            signer = provider.getSigner();
            console.log("Wallet connected:", await signer.getAddress());

            // Event listeners
            document.getElementById("createGame").addEventListener("click", createGame);
            document.getElementById("resetGame").addEventListener("click", resetGame);
        } catch (error) {
            console.error("Error connecting wallet:", error);
            messageElement.textContent = "Please connect your wallet.";
        }
    }

    // Function to create a new game
    async function createGame() {
        try {
            const msgSender = await signer.getAddress(); // Use the connected wallet's address

            // Define domain and schema types for signing data
            const domain = {
                    name: "Stackr MVP v0",
                    version: "1",
                    chainId: 11155111, // Sepolia Testnet
                    verifyingContract: "0x0000000000000000000000000000000000000000",
                    salt: "0x0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
                };

            const schemaTypes = {
                CreateGame: [
                    { name: "owner", type: "address" },
                    { name: "playerO", type: "address" },
                    { name: "startedAt", type: "uint256" },
                ],
                Action: [
                    { name: "name", type: "string" },
                    { name: "inputs", type: "CreateGame" },
                ],
            };

            const playerO = prompt("Enter Player O's Ethereum Address:");
            if (!playerO || !ethers.utils.isAddress(playerO)) {
                messageElement.textContent = "Invalid Player O address.";
                return;
            }

            const createGameInputs = {
                owner: msgSender,
                playerO: playerO,
                startedAt: Math.floor(Date.now() / 1000),
            };

            const createGameAction = {
                name: "createGame",
                inputs: createGameInputs,
            };

            // Sign the data using the connected wallet's signer
            const signature = await signer._signTypedData(
                domain,
                schemaTypes,
                createGameAction
            );

            // Submit the createGame action to the backend
            const response = await fetch("/createGame", { // Ensure backend has '/createGame' route
                method: "POST",
                headers: {
                    "Content-Type": "application/json",
                },
                body: JSON.stringify({
                    msgSender,
                    inputs: createGameInputs,
                    signature,
                }),
            });

            if (!response.ok) {
                const errorData = await response.json();
                console.error("Backend Error:", errorData);
                messageElement.textContent = `Error: ${errorData.error || "Unknown error."}`;
                return;
            }

            const result = await response.json();
            console.log("Game created with logs:", result.logs);

            // Extract gameId from logs
            const gameCreatedLog = result.logs.find(log => log.name === "GameCreated");
            if (gameCreatedLog) {
                gameId = gameCreatedLog.value;
                messageElement.textContent = `Game created! Game ID: ${gameId}`;
                fetchGameState();
            } else {
                messageElement.textContent = "Failed to create game.";
            }
        } catch (error) {
            console.error("Error creating game:", error);
            messageElement.textContent = "Error creating game.";
        }
    }

    // Function to make a move
    async function makeMove(index) {
        if (!gameId) {
            messageElement.textContent = "Please create a game first.";
            return;
        }

        try {
            const msgSender = await signer.getAddress();

            // Define domain and schema types for signing data
            const domain = {
                    name: "Stackr MVP v0",
                    version: "1",
                    chainId: 11155111, // Sepolia Testnet
                    verifyingContract: "0x0000000000000000000000000000000000000000",
                    salt: "0x0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
                };

            const schemaTypes = {
                MakeMove: [
                    { name: "gameId", type: "string" },
                    { name: "index", type: "uint256" },
                    { name: "player", type: "string" }, // "X" or "O"
                ],
                Action: [
                    { name: "name", type: "string" },
                    { name: "inputs", type: "MakeMove" },
                ],
            };

            const player = gameState.currentPlayer;

            const makeMoveInputs = {
                gameId,
                index,
                player,
            };

            const makeMoveAction = {
                name: "makeMove",
                inputs: makeMoveInputs,
            };

            // Sign the data using the connected wallet's signer
            const signature = await signer._signTypedData(
                domain,
                schemaTypes,
                makeMoveAction
            );

            // Submit the makeMove action to the backend
            const response = await fetch("/makeMove", { // Ensure backend has '/makeMove' route
                method: "POST",
                headers: {
                    "Content-Type": "application/json",
                },
                body: JSON.stringify({
                    msgSender,
                    inputs: makeMoveInputs,
                    signature,
                }),
            });

            if (!response.ok) {
                const errorData = await response.json();
                console.error("Backend Error:", errorData);
                messageElement.textContent = `Error: ${errorData.error || "Unknown error."}`;
                return;
            }

            const result = await response.json();
            console.log("Move made with logs:", result.logs);

            // Handle logs to update the UI
            const moveMadeLog = result.logs.find(log => log.name === "MoveMade");
            const gameEndedLog = result.logs.find(log => log.name === "GameEnded");

            if (moveMadeLog) {
                messageElement.textContent = `Move made by ${makeMoveInputs.player}.`;
                fetchGameState();
            } else if (gameEndedLog) {
                const [endedGameId, winner] = gameEndedLog.value.split("::");
                messageElement.textContent = winner === "Draw" ? "Game ended in a draw!" : `Player ${winner} wins!`;
                fetchGameState();
            } else {
                messageElement.textContent = "Failed to make move.";
            }
        } catch (error) {
            console.error("Error making move:", error);
            messageElement.textContent = "Error making move.";
        }
    }

    // Function to reset the game
    async function resetGame() {
        if (!gameId) {
            messageElement.textContent = "No game to reset.";
            return;
        }

        try {
            const msgSender = await signer.getAddress();

            // Define domain and schema types for signing data
            const domain = {
                    name: "Stackr MVP v0",
                    version: "1",
                    chainId: 11155111, // Sepolia Testnet
                    verifyingContract: "0x0000000000000000000000000000000000000000",
                    salt: "0x0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
                };
            const schemaTypes = {
                ResetGame: [
                    { name: "gameId", type: "string" },
                ],
                Action: [
                    { name: "name", type: "string" },
                    { name: "inputs", type: "ResetGame" },
                ],
            };

            const resetGameInputs = {
                gameId,
            };

            const resetGameAction = {
                name: "resetGame",
                inputs: resetGameInputs,
            };

            // Sign the data using the connected wallet's signer
            const signature = await signer._signTypedData(
                domain,
                schemaTypes,
                resetGameAction
            );

            // Submit the resetGame action to the backend
            const response = await fetch("/resetGame", { // Ensure backend has '/resetGame' route
                method: "POST",
                headers: {
                    "Content-Type": "application/json",
                },
                body: JSON.stringify({
                    msgSender,
                    inputs: resetGameInputs,
                    signature,
                }),
            });

            if (!response.ok) {
                const errorData = await response.json();
                console.error("Backend Error:", errorData);
                messageElement.textContent = `Error: ${errorData.error || "Unknown error."}`;
                return;
            }

            const result = await response.json();
            console.log("Game reset with logs:", result.logs);

            const gameResetLog = result.logs.find(log => log.name === "GameReset");

            if (gameResetLog) {
                messageElement.textContent = "Game has been reset!";
                fetchGameState();
            } else {
                messageElement.textContent = "Failed to reset game.";
            }
        } catch (error) {
            console.error("Error resetting game:", error);
            messageElement.textContent = "Error resetting game.";
        }
    }

    // Function to fetch the current game state
    async function fetchGameState() {
        try {
            const response = await fetch(`/games/${gameId}`);
            if (!response.ok) {
                const errorData = await response.json();
                console.error("Backend Error:", errorData);
                messageElement.textContent = `Error: ${errorData.message || "Failed to fetch game state."}`;
                return;
            }
            const data = await response.json();
            gameState = data;
            updateBoard();
            if (gameState.winner) {
                messageElement.textContent = gameState.winner === "Draw" ? "Game ended in a draw!" : `Player ${gameState.winner} wins!`;
            } else {
                messageElement.textContent = `Player ${gameState.currentPlayer}'s turn.`;
            }
        } catch (error) {
            console.error("Error fetching game state:", error);
            messageElement.textContent = "Error fetching game state.";
        }
    }

    // Function to update the board UI
    function updateBoard() {
        const boardElement = document.getElementById("board");
        boardElement.innerHTML = "";
        gameState.board.forEach((cell, index) => {
            const cellDiv = document.createElement("div");
            cellDiv.classList.add("cell");
            cellDiv.textContent = cell;
            if (cell === "") {
                cellDiv.addEventListener("click", () => makeMove(index));
            }
            boardElement.appendChild(cellDiv);
        });
    }

    // Initialize the app on page load
    window.onload = init;
</script>

</body>
</html>

Explanation:

• Connect to MetaMask: Requests the user to connect their wallet.

• Deterministic Wallet: Generates a deterministic wallet based on the user's signature to avoid signing every transaction.

• Create Game: Allows the user to create a new game by specifying Player O's Ethereum address.

• Make Move: Enables players to make moves on the board by clicking on empty cells.

• Reset Game: Resets the game to its initial state.

• Fetch Game State: Retrieves the current state of the game to update the UI accordingly.

Testing Your Game

After setting up the backend and frontend, you can start your development server:

bun start

Open your browser and navigate to http://localhost:3012 to see your Tic Tac Toe game in action!

Conclusion

Congratulations! 🎉 You’ve successfully built a decentralized Tic Tac Toe game using Stackr Labs and Micro Rollups. This project showcases how to manage game state on the blockchain while providing a simple and engaging user interface.

Feel free to extend the game further, add features like multiplayer support, or improve the UI. Happy coding! If you have any questions or need further assistance, please feel free to contact me. You can connect with me on X / Twitter or LinkedIn.

Today, I want to dive into something that I believe is one of the key building blocks for scaling blockchain technology — bridges. Specifically, I want to talk about how Layer 1 (like Ethereum) connects with rollups, and why this connection matters so much for making blockchain usable for everyone.

Think of this as a journey — like getting from one island to another. Let’s explore how these “bridges” work and why we need them!

Why Do We Need Bridges?

So, you might be wondering, why do we even need these bridges? Imagine this: you have two islands. One is Island Ethereum (Layer 1), and the other is Island Rollup (it could be Optimism, Arbitrum, zkSync, etc.). Island Ethereum is the main island, it’s big, popular, and everyone wants to live there. But because it’s so popular, it’s crowded and expensive — you have to pay high fees (like paying for an expensive ferry ride). 😅

Now, Island Rollup is a new, smaller island. It’s a lot cheaper and has fewer people on it, but it still needs to connect with the main island because that’s where most of the action is. So we build a bridge between Island Ethereum and Island Rollup to make life easier.

In simple terms, bridges let us move money and information between Ethereum and rollups without getting stuck with high fees. They help people save time and cost, allowing us to get the best of both worlds — security from Ethereum and low fees from rollups.

How Do Bridges Work?

Okay, so how do these bridges actually work? Let’s break it down step by step:

1. Locking Your Assets on Ethereum: Imagine you want to send 1 ETH from Island Ethereum to Island Rollup. The first step is to “lock” that ETH on Ethereum. It’s like putting your money in a safe before taking a copy of it to the other island. This locked ETH stays safe on Layer 1.

2. Creating a Representation on Rollup: Once your ETH is locked, a “copy” or representation of your ETH is created on the rollup. This isn’t real ETH; it’s more like a receipt that shows you own ETH on Ethereum, but you’re allowed to use it on the rollup. This allows you to start using the cheaper, faster services on Island Rollup.

3. Using and Bringing It Back: Now you can do things like make transactions or use dApps on the rollup at a lower cost. And when you’re done, you use the bridge again to move your assets back to Ethereum. The ETH on the rollup gets “burned” (destroyed), and your original ETH on Ethereum gets unlocked, ready for use!

Let’s take an everyday example. If you’ve ever used a gift card, you know the card isn’t cash, but it represents money you can spend at a particular store. When you move from Layer 1 to a rollup, the bridge gives you something similar to a gift card to use there. You’re free to spend it however you like, and you can exchange it back into cash when you’re ready.

Why Does Bridging Matter So Much?

Let me tell you why bridging is a game-changer. Here are a few reasons:

1. Lower Costs for Everyone 💸 I’ve been there myself — trying to make a simple transaction on Ethereum, and boom! There’s a crazy gas fee that’s just too high. Bridging to a rollup helps cut down these costs, which is a big deal, especially if you’re just trying to send a few dollars worth of crypto or use a dApp without burning a hole in your pocket.

2. Unlocking New Possibilities 🚀 When you bridge assets to a rollup, suddenly, you have the freedom to interact with many applications without worrying about the cost. Think of playing a blockchain game or trading tokens in DeFi without paying $20 in fees each time. The bridge gives us access to affordable blockchain experiences that many users, especially newcomers, really need.

3. Security Backed by Ethereum 🛡️ Rollups are like lightweight, cheaper versions of Ethereum, but they’re still connected to the main chain. This means that you get the security of Ethereum (which has been tested over many years) while still enjoying the lower costs and faster speeds of a rollup. This connection is what makes bridging so important.

Types of Bridges

Not all bridges are created equal. You might hear people talking about different types of bridges, so let me quickly explain:

• Centralized Bridges: These are run by a single entity, like a company or a group of people. They’re easier to use but have a higher trust risk. It’s like trusting a bank to hold your money.

• Decentralized Bridges: These use smart contracts and are more “trustless.” They rely on code instead of people, and that makes them more secure in theory. It’s like using a locker with an automated lock that only you can open.

For example, the Arbitrum Bridge and Optimism Bridge are specific to those rollups, while tools like Hop Protocol allow you to move assets between different rollups and Ethereum with less friction.

My Experience Using Bridges

I remember the first time I tried bridging from Ethereum to a rollup. I wanted to try out some new DeFi projects, but the Ethereum fees were just too high for my small transactions. So, I decided to use the Arbitrum Bridge. It was surprisingly simple — I just locked my ETH on Ethereum, waited a few minutes, and suddenly I had ETH available on Arbitrum to play around with.

The experience was like going from paying tolls on a busy highway to cruising down a quiet, free country road. Everything was faster, smoother, and cheaper, and it made me realize how powerful these scaling solutions can be.

Security Considerations

One thing to note, though, is that bridges do have some risk. When you lock your assets on Layer 1, you’re trusting the bridge’s smart contract to keep them safe. If the contract has a bug or is hacked, those assets could be at risk. So always use well-known bridges with a good track record, and never bridge more than you’re willing to lose.

Final Thoughts

In the end, bridging between Layer 1 and rollups is a crucial piece of the puzzle for making blockchain scalable and affordable for everyone. Just like building bridges between islands helps people travel and do business more easily, these blockchain bridges are key to creating a world where blockchain isn’t just for the wealthy or tech-savvy — it’s for everyone.

So if you haven’t tried bridging yet, give it a shot! Whether it’s moving assets to Arbitrum, Optimism, or zkSync, you’ll see firsthand just how powerful these tools can be in making blockchain more accessible.

Thanks for reading! If you found this helpful, feel free to share it or drop a comment below about your own experience with bridges. Let’s keep exploring and making blockchain technology easier for everyone! 🚀

When I started learning about the blockchain in 2022, one of the main concepts that came into my learning is layer 2 and rollups. What is L2 ? What is a Rollup ? Is every L2 a Rollup ?

To answer all these questions first let us understand what is L2 ?

What is L2 (layer 2) ?

Layer 2 is another layer below the main blockchain (L1) which is created to process all the transactions more faster and cheaper.

At the end of this blog, you might have some interesting thoughts about rollups.

What Are Rollups?

Imagine you’re at a crowded theme park, and there’s a long line for every ride. Wouldn't it be nice if you could group people together, so instead of 50 individuals waiting in line, you send them in one big group? That's what rollups do for blockchains. Instead of handling every transaction one by one, rollups bundle multiple transactions together, process them off-chain, and then submit a summary of these transactions back to the main blockchain.

How Do Rollups Work?

There are two important parts of a rollup:

1. Off-chain processing: Transactions happen off-chain, meaning they are processed outside the main blockchain. This reduces the load on the main chain, making everything faster.

2. On-chain verification: After transactions are processed off-chain.A rollup submits the compressed data or a proof back to the main blockchain, which acts as the final validator and security layer.

This way, rollups increase transaction speed and reduce costs still maintaining the security of the main blockchain.

Types of Rollups

There are two main types of rollups: Optimistic Rollups and Zero-Knowledge (ZK) Rollups. Both improve blockchain scalability, but they do it in different ways.

1. Optimistic Rollups

• Optimistic Rollups transactions are initially processed off-chain by a operator. This operator bundles the transactions into a batched block and submits the batched block to the main chain, asserting the validity of the multiple transactions. The principal blockchain then confirms the validity proof and publishes the block, finalizing the transactions.

• There will be a challenging period for this. If any disputes arise regarding the validity of transactions, The validator will submit a fraud proof to challenge the result. The blockchain will then re-check that transaction.

Example: Arbitrum, Optimism etc

2. Zero-Knowledge (ZK) Rollups

• ZK-rollups uses advanced cryptographic techniques known as zero-knowledge proofs to ensure transaction validity without revealing sensitive data. In this model, all transaction data is aggregated off-chain, and only succinct validity proofs are submitted to the main blockchain.

• This approach provides enhanced privacy and scalability while maintaining the security and privacy of the underlying blockchain.

Example: zkSync, Starkware.

Why Are Rollups Important?

1. Speed and Scalability: At a crowded theme park, if each person waited individually, lines would move slowly. But grouping 50 people together speeds things up. Similarly, rollups bundle transactions, processing them in one go, which boosts blockchain speed and scalability.

2. Lower Fees: When the theme park is crowded, the wait is longer and more expensive (like paying extra for a fast pass). Rollups group people (or transactions) into one "group ticket," reducing the cost, just as rollups lower gas fees on the blockchain.

3. Security: Even when you group everyone together for the ride, the theme park still checks the group ticket to ensure safety. Similarly, with rollups, the main blockchain (eg Ethereum) verifies that all bundled transactions are correct, providing strong security while being faster and cheaper.

Summary

Blockchain Rollups are a Layer 2 solution designed to improve transaction speed with lower gas costs by bundling multiple off-chain transactions**.** This article would have given you a basic understanding of rollups, and their types.

Follow me for to learn more about rollups!!