Taiko BBR: The World Motherboard for Ethereum

Key Takeaways

• Ethereum, the representative world computer, sought to achieve scalability through rollups. However, as each rollup operates independently, issues such as fragmented liquidity, user inconvenience, and security risks have intensified, revealing the limitations of the existing scaling strategy.

• Taiko’s Based Booster Rollup (BBR) combines Based Rollups and Booster Rollups to offer various technical advantages, including shared state across rollups and synchronous transaction processing. This enables a more organic connection between Ethereum and rollups, improving both user experience and developer operations.

• BBR proposes a new design paradigm for diverse dApps such as DeFi, NFTs, and games, allowing for fundamental expansion of the Ethereum ecosystem. While compatibility with existing rollups and ecosystem standardization remain challenges, BBR is emerging as a key infrastructure for Ethereum’s resurgence as the world computer.

1. Introduction

1.1 Ethereum, the Aging Yet Iconic World Computer

“Ethereum is the world computer, an incredibly large and diverse on-chain economy, and an incredibly large and diverse global community…”

— Vitalik Buterin, Devcon 2024 in Bangkok

As Vitalik Buterin has repeatedly emphasized, Ethereum is the main driver of the world computer era — a time in which decentralized nodes across the globe come together to build a neutral and decentralized network that functions like a single computer through smart contracts. In particular, Ethereum is the very platform that allowed abstract questions like “What happens when developers take over finance?” to become real, tangible DeFi services.

While Ethereum led the way in introducing new blockchain narratives such as DeFi, NFTs, and the metaverse, it has gradually started to age due to inherent structural limitations like slow transaction speeds and high fees. In contrast, new and faster blockchains like Solana and Sui have emerged, offering cheaper and more efficient alternatives — these so-called “younger blockchains” are now vying for the throne of the world computer.

In response, Ethereum introduced the “Rollup Roadmap” as a solution to improve scalability and keep up with the changing times. Based on this roadmap, various rollup approaches — including Optimistic Rollups, ZK Rollups, Based Rollups, and more recently, Native Rollups — have emerged as a “fountain of youth” to enhance Ethereum’s performance and flexibility. But has quantity turned into complexity? As the number of rollups increases, so too do new layers of complexity and unforeseen issues.

1.2 Emergence of Fragmentation Issues Among Rollups

As rollups with distinct features emerged and numerous dApps were built on top of them, the rollup ecosystem experienced explosive growth. The total value locked (TVL) in rollups has steadily increased, now amounting to the equivalent of approximately 17.34 million $ETH. This is partly due to the rapid development and vibrant ecosystem of each rollup, but also because of the sheer increase in the number of rollups. While the expansion of the Ethereum ecosystem and advancements in rollup technology have helped address scalability to some extent, a new issue has come to the forefront — fragmentation among rollups.

According to l2beat, there are currently 61 rollups. While these clearly contribute to Ethereum’s scalability, the fragmentation caused by their independent operation disperses users across multiple rollup blockchains, weakening liquidity and degrading usability. For example, users must maintain separate accounts on each rollup and hold at least a small amount of assets on each for transaction fees. Moreover, token liquidity is fragmented, which can lead to undesirable slippage when trading or make it difficult to execute large-volume transactions of a specific token all at once.

If a user wants to move assets and data across different rollups, they must use a separate bridge. However, as the number of rollups increases, the number of bridges needed to interconnect them also grows exponentially. This not only amplifies centralization and security risks inherent to bridges but also complicates the overall infrastructure.

In fact, in 2023, a bridge hacking incident occurred when Multichain CEO Zhaojun went missing, resulting in the theft of approximately $126 million worth of assets. Multichain operated using a Multi-Party Computation (MPC)-based system to manage its operational keys — a method that splits keys into multiple fragments, requiring cooperation among multiple parties to execute transactions, similar to multisig wallets. However, this system can be compromised if an attacker gains control of enough MPC key fragments. In this case, it is believed that the attacker managed to obtain some of the MPC keys, demonstrating how the structural vulnerabilities of bridges can be exploited in practice. As the number of bridges increases, so too does the number of potential attack vectors.

The fragmentation issue among rollups not only causes inconvenience for users but also adds operational burdens for developers. Since each rollup is essentially an independent blockchain environment, deploying the same dApp on a different rollup requires separate deployment and management. Developers are thus forced to maintain dApps across multiple rollups to reach fragmented users and liquidity, which significantly increases operational costs and complexity.

Ultimately, if the problem of rollup fragmentation remains unresolved, Ethereum’s rollup-centric roadmap — the strategy chosen to revitalize the network — will inevitably face limitations. This could lead to a gradual shift in dominance toward other, more cohesive blockchains.

1.3 Various Discussions for Fragmented Rollups

To advance Ethereum’s rollup roadmap to the next level, it is essential to address the structural limitations of the current fragmented rollup landscape, where each rollup operates independently. Different rollups must become organically interconnected, and each must be utilized fully in terms of scalability. Various efforts are already underway within the Ethereum ecosystem to achieve this:

• Ethereum Official L2 Interoperability Hub: Ethereum operates an official L2 Interoperability Hub aimed at defining shared standards and system architectures for interoperability between L2s, with the goal of steering the Ethereum ecosystem in a unified direction.

• Vitalik Buterin’s L2 Interoperability Roadmap: To address the interoperability challenges between Ethereum L2 protocols, Vitalik proposed a two-phase roadmap. Phase 1 includes introducing EIP-3370 (address standardization), EIP-7683 (cross-chain intent standard), and EIP-3668 (off-chain data access standardization) to establish a foundation for interoperability. Phase 2 envisions all rollups transitioning to zero-knowledge-based systems, with interoperability reinforced through keystore rollups and proof aggregation.

• Native Interoperability in OP Stack: Discussions are underway regarding protocol-level message passing and the specification of Superchain ERC-20 tokens.

• Arbitrum’s Interoperability Plans: Offchain Labs, the team behind Arbitrum, is working on unifying chains within the Arbitrum ecosystem and later expanding interoperability with other Ethereum rollups.

However, no universal standard has yet been adopted, and the exact direction for achieving rollup interoperability remains unclear. In this context, Taiko is preparing to research and apply a new technical framework that could serve as the coordinating and integrating backbone among rollups — the Based Booster Rollup (BBR).

Taiko’s BBR addresses the inefficiencies and complexities of the fragmented rollup landscape by enabling shared state among rollups. This allows both developers and users to enjoy a fast and consistent experience, as if using a single, extended blockchain. While various approaches to solving rollup fragmentation are being explored, let’s take a closer look at how Taiko’s BBR aims to tackle this challenge.

2. Taiko’s Based Booster Rollup: A Technical Implementation to Reinforce the World Computer

Taiko’s Based Booster Rollup (BBR) plays the role of reinforcing Ethereum as the world computer — a function that finds its closest analogy in a component from traditional computer hardware: the motherboard.

2.1 World Computer and the World Motherboard

"A motherboard is the main printed circuit board (PCB) in a computer. The motherboard is a computer's central communications backbone connectivity point, through which all components and external computer hardware connect."

— TechTarget, What is a motherboard?

As described above, the motherboard is the central circuit board of a computer that connects RAM, hard drives, graphic cards, and other peripherals, allowing them to communicate. Even when adding new components, it must be done through the motherboard — making it the key factor in determining a computer’s scalability and flexibility.

Now you might be wondering: why bring up a motherboard? Let’s shift back to the “world computer” perspective. In Ethereum, rollups are the mechanisms that handle transactions and scale the network. In this analogy, rollups can be seen as peripherals that enhance the performance of the world computer — Ethereum.

However, what’s missing is the motherboard that can connect and manage these peripherals smoothly. That’s right — what Ethereum lacks today is a “world motherboard.” And Taiko’s BBR, currently under development, is shaping up to be the most fitting solution to serve this crucial role for Ethereum.

2.2 Based Rollup + Booster Rollup = Based Booster Rollup

To effectively fulfill its role as the “world motherboard,” Taiko’s Based Booster Rollup (BBR) is built by combining two key concepts:

Source: Taiko Mirror

The first component is the Based Rollup, which delegates the sequencer’s authority to Ethereum block proposers, maximizing censorship resistance and decentralization. Unlike conventional rollups that have their own sequencers, Based Rollups allow Ethereum’s block builders to directly take on the sequencing role. This eliminates the need for separate consensus mechanisms and avoids centralization risks, all while maintaining a consistent network state.

The second component is the Booster Rollup, a structure that connects multiple rollups in parallel around Ethereum and secures interoperability to dramatically increase throughput. In this model, each rollup operates independently—like peripherals in a computer—but also shares a synchronized state through data sourced directly from Ethereum. This enables a cohesive and interconnected system of rollups, much like a motherboard that unites and coordinates different hardware components to enhance a computer’s overall performance and scalability.

Importantly, the Booster Rollup concept is not limited to a specific type of rollup. Whether it’s an Optimistic Rollup or a ZK Rollup, any rollup can serve as a Booster Rollup if it possesses the basic capabilities required for boosting—namely, the ability to directly access Ethereum’s state and share state with other rollups. For instance, a rollup that can read from Ethereum and support state sharing across rollups can effectively function as a Booster Rollup.

Taiko’s motivation for being among the first to adopt the Booster Rollup model within a Based Rollup architecture lies in the unique synergy between the two. Running multiple Based Rollups in parallel can significantly enhance transaction throughput and efficiency without compromising Ethereum’s security guarantees. The Based Booster Rollup structure captures the strengths of Based Rollups while enabling direct, scalable expansion of Ethereum through rollup boosting — positioning it as a powerful technical solution in Ethereum’s evolution.

3. Structural Features and Technical Advantages of the BBR

Let’s now take a closer look at how BBR addresses the fragmentation issues inherent in rollups, and the specific structural and technical advantages it offers to solve them.

3.1 State Sharing in BBR That Feels Like One Unified Blockchain

In the traditional Ethereum rollup architecture, each rollup manages its state independently. This means that transferring assets or exchanging data across rollups requires the use of bridges — a process that introduces confirmation delays, high fees, and operational complexity. For users, this results in slow transfers and a fragmented, inconvenient experience. Developers also face challenges, needing to write additional logic to synchronize isolated states when building cross-rollup dApps.

BBR addresses these problems through a design where all rollups share Ethereum’s state directly. Instead of operating in isolated environments, each rollup in the BBR ecosystem functions atop a shared, common state, enabling them to interact seamlessly.

The Unified Bridge is a technology that materializes this kind of structure. Through a single smart contract, Ethereum and all rollups can share state, and assets or data can be exchanged directly between rollups without going through intermediaries. The single smart contract mentioned here is deployed on Ethereum, and the bridge logic is defined within this smart contract. All booster rollups operate the bridge using this smart contract with the same logic. Since all rollups use the same bridge structure, developers can easily implement cross-chain functionality without complex configuration, and users can enjoy services as if they were using a single blockchain.

For example, if a user wants to use a token issued on Rollup A within a dApp on Rollup B, the traditional architecture would require the user to:

1. Transfer the asset via a bridge,

2. Manually switch networks,

3. Approve the token again within the new dApp.

However, in the BBR architecture using a Unified Bridge, users and developers no longer need to manually handle these processes — asset transfers and dApp calls can be executed automatically within a single transaction. From the user's perspective, it simply feels like "using a service," while behind the scenes, cross-rollup asset transfers and state synchronization are handled in real time.

As a result, asset transfers, smart contract interactions, and data exchanges are processed instantly and seamlessly. Compared to traditional bridge-based architectures, this leads to significant improvements in speed, cost-efficiency, and overall user convenience.

BBR is more than just a tool for connecting rollups — it fundamentally reshapes how rollups operate by ensuring they all share the same state. This allows them to behave as one expanded blockchain, boosting both scalability and interoperability for Ethereum. The result is a major upgrade in both developer workflow and overall user experience across the ecosystem.

3.2 Maintaining Cross-Rollup Consistency Through Synchronous Transaction Processing

In an asynchronous transaction model, when one rollup network sends data to Ethereum or another rollup, there’s a delay before the receiving blockchain updates its state. Even if the data is transmitted successfully, the state change isn’t reflected immediately, leading to timing gaps between blockchain networks. This introduces a lack of atomicity — for example, if an action on Rollup A is meant to trigger an operation on Rollup B only if the first succeeds, any desynchronization in execution timing can disrupt the entire process. If one step fails midway, the result may be inconsistent across rollups.

To address this, BBR employs a synchronous transaction model, where multi-rollup operations are executed atomically within a single transaction. This allows one rollup to instantly access the state of another and act on it in real time. Since all operations are executed synchronously in one go, rollup-to-rollup responsiveness isn’t delayed like in asynchronous models.

For example, consider a swap transaction: a user might swap a token on Rollup A’s DEX and immediately send the output token to a service on Rollup B. In the BBR model, these linked operations can occur within a single synchronous execution. If any part of the process fails, the entire transaction is rolled back to preserve consistency.

BBR's synchronous processing architecture, which ensures both high processing speed and robust security while maintaining the consistency of entire transactions, makes it highly applicable to various domains such as DeFi protocols, Games Cross-chain exchanges.

3.3 Smart Contract Unified Deployment: Easing Developer Burden in Rollup Environments

This time, let's think from a developer's perspective rather than a user's. For dApp developers, the existence of multiple rollup environments can be quite a headache. The biggest issue is that smart contracts must be deployed separately for each rollup. Since each rollup operates independently based on its own state and data, a dApp is effectively non-existent in any rollup where the smart contract hasn't been deployed. Of course, developers can choose to operate only on a specific rollup, but doing so limits them to the user base and asset size of that single rollup, creating scalability issues.

Trying to solve this by deploying the smart contract to multiple rollups also creates challenges. Without an automated system to maintain consistency across versions, states, and error handling for each network, discrepancies in smart contract code or state may arise between rollups, requiring significantly more effort for maintenance. Furthermore, since the cost of deploying and operating dApps increases linearly with the number of rollups, developers often see expanding to additional rollups as a burden.

BBR allows developers to deploy a smart contract on Ethereum just once and use it across all rollups through an integrated deployment structure. This is made possible by the L1CALL/L1DELEGATECALL precompiles, which enable rollups to automatically “call” the contract deployed on Ethereum. The key features are as follows:

• Integrated Smart Contract Deployment: A smart contract deployed once on Ethereum can be shared across multiple rollups via call-based access, as if it were duplicated.

• L1CALL/L1DELEGATECALL: Instead of deploying new contracts on rollups, these use built-in opcodes called L1CALL and L1DELEGATECALL to access information from the Ethereum-deployed contract. L1CALL invokes specific functions of the contract, while L1DELEGATECALL executes the contract’s code itself.

• Elimination of Smart Contract Collisions: Booster rollups block the use of CREATE and CREATE2 to prevent new contract deployments and avoid address conflicts.

• State Aggregation and Reflection to L1: When users execute transactions on a rollup, the resulting state changes are batched and periodically synchronized with Ethereum.

Thanks to these features, BBR ensures that even if a contract isn't deployed on a particular rollup, users still feel as though Ethereum and the rollup are using the exact same smart contract.

3.4 Smart Wallets: Smoother User Experience

In the current multi-rollup environment, users are burdened with having to interact directly with various rollups. To move assets, users must use bridges, manually switch blockchain networks in their wallets, and adapt to different interfaces and address systems across rollups.

For example, suppose a user wants to transfer USDC from Arbitrum to Optimism using MetaMask. The steps involved would be:

1. Add both the Arbitrum and Optimism networks to MetaMask.

2. Register the USDC smart contract address for both Arbitrum and Optimism in MetaMask.

3. Use a bridge to transfer USDC from Arbitrum to Optimism. (This step involves understanding bridge fees, waiting times, and withdrawal delays.)

4. Confirm visually in MetaMask that the USDC has been successfully transferred.

This process is complex and prone to user error, negatively affecting the overall user experience.

Additionally, cross-chain calls between rollups are difficult to support unless explicitly implemented within the dApp’s smart contracts. Even if a dApp works across multiple rollups, if the user experience does not match that flexibility, real-world usability will inevitably be limited.

Smart wallets offer a solution to these issues by automatically handling complex inter-rollup operations on behalf of users. For instance, in a booster rollup environment, a smart wallet can navigate between Ethereum and various rollups to process composite transactions:

1. The user sends a execution request (tx) to a key store on Ethereum.

2. The rollup’s smart wallet references Ethereum to verify the signature.

3. Upon verification, it sequentially executes token transfers and token swap calls within the same rollup.

4. The token swap contract then sends a message to another rollup, where the final token transfer is completed.

As a result, users don’t have to be aware of these complex steps and can use dApps across all rollups through a familiar interface, naturally and seamlessly.

Ultimately, the user experience provided by BBR makes the use of rollups nearly invisible to the end user. By offering an interface as smooth and intuitive as Web2 applications, BBR lowers the entry barrier and accelerates the mainstream adoption of dApps.

3.5 Booster Block: One Block, One Proof

In a fragmented rollup environment, each rollup independently produces its own blocks, submits separate proofs to Ethereum, and settles transactions individually. This approach assumes completely isolated execution environments across rollups, which leads to several structural limitations:

• Since each rollup submits its own proof, the verification process is duplicated, increasing network costs.

• Transactions are processed at different times across rollups, making global transaction ordering and management difficult and delaying synchronization when interaction is needed.

• The efficiency of parallel execution across rollups is reduced.

• Independent execution in each rollup causes operations that should be processed together to be divided, limiting overall system responsiveness and scalability.

To address these issues, the booster block mechanism integrates transactions from multiple rollups into a single block and validates them through a single proof. The process works as follows:

1. Transactions from multiple rollups are aggregated into a unified, continuous transaction list (super block) formatted like “3 | tx, 1 | tx, 4 | tx …”.

2. A builder processes this list sequentially to construct the super block, and a prover generates a single proof covering all included transactions.

3. Each transaction includes a list of blockchains it is associated with. If a transaction refers to a blockchain it’s not linked to, it is designed to be rejected.

4. From the perspective of a rollup node, any transaction unrelated to its own rollup is simply skipped, and only the relevant transactions are synchronized and processed.

While this requires the builder to have visibility into the state of all rollups in advance, it enables efficient handling and verification of a super block that spans multiple rollups using a single proof. The key advantage is that this ensures natural synchronization across the entire system. Since all transactions are coordinated within one booster block, issues related to state mismatches or ordering across rollups are eliminated. Additionally, submitting just one proof greatly reduces network costs and simplifies execution parallelization. Each rollup node only processes transactions relevant to itself within the unified block, minimizing unnecessary computation and network load, thereby operating more efficiently.

4. Additional Research Advancing the BBR

Active research is underway to realize and expand the concept of BBR. In particular, the Taiko and Ethereum communities are conducting various studies to establish the technical foundation that supports BBR’s core ideas. Among the most prominent efforts are Ethereum-native coprocessors and Ultra Transactions (Ultra Tx).

4.1 Coprocessorization of Rollups

A core idea behind BBR is to treat rollups not as independent auxiliary blockchains, but as supplementary devices that enhance Ethereum itself. The goal is to offload complex and computation-heavy tasks to rollups while reflecting only the results back to Ethereum—this increases overall performance and scalability, while Ethereum still retains responsibility for security and state integrity.

Taking this concept a step further, current research is exploring the idea of making rollups even more computation-focused and purpose-specific—essentially turning them into coprocessors. A coprocessor is a specially designed secondary processor that assists the main CPU, typically handling specific tasks (e.g., mathematical operations, graphics rendering, signal processing) more efficiently. For example, in older computers, floating-point operations were offloaded to a floating-point unit (FPU) to improve performance.

Conceptually, this coprocessor model is similar to BBR—both aim to enhance blockchain performance and scalability by adding rollups when necessary. However, there are important differences between the two. In BBR, rollups execute transactions and retain the resulting state locally (though this state is also shared with Ethereum to maintain a globally consistent state).

In contrast, the coprocessor model assigns rollups purely computational tasks, without storing state. Only the execution result is submitted to Ethereum, where the actual state update takes place. As a result, rollups under this model have no storage burden, which maximizes execution performance. However, this also means that dApps requiring persistent state or complex state references may face limitations.

This architecture is currently being actively discussed through projects like Taiko's Gwyneth and within the broader Ethereum community. If successfully adopted, users would no longer need to interact with rollups as endpoints. Instead, they could send transactions directly to Ethereum and benefit from dramatically improved throughput and lower fees compared to the current experience. The notion of "dealing with rollups" would fade, replaced by the perception of a "high-performance Ethereum." Developers, too, would enjoy a simplified experience, focusing solely on Ethereum mainnet development while gaining access to a powerful execution environment.

4.2 Ultra Transaction: Treating a Block as a Single Program

Source: ethresearch

Ultra Transaction (Ultra TX), proposed by Brecht and researchers at Taiko in early 2025, introduces a novel block architecture that reimagines Ethereum blocks not as bundles of multiple transactions, but as one massive "Ultra Transaction." Unlike the traditional structure where each transaction is processed independently in sequence, Ultra TX unifies all transactions—including rollup transaction bundles—into a single transaction unit. Essentially, the entire block is executed like one program.

This structure drastically enhances composability between Ethereum and rollups. Previously, linking operations across Ethereum and rollups required inter-chain messaging, which was slow, expensive, and detrimental to user experience. Ultra TX solves this by allowing multiple operations across Ethereum and rollups to be executed and verified together within one transaction. For example, a user can perform computations on two different rollups and merge the results—executed seamlessly in a single Ultra TX.

This approach simplifies the transaction process for both users and developers. It modularizes and standardizes extensibility features that can be shared across all rollups, enabling unified interoperability and improving the overall developer and user experience.

The operation process of Ultra Transactions is as follows:

1. Initial State Preparation: The block states of Ethereum and each rollup are prepared in advance. This is to treat Ethereum and rollup transactions within a single, unified execution environment without distinguishing between them.

2. Arbitrary Order Execution: A builder executes all the prepared transactions off-chain in any desired order. During this step, Ethereum-to-rollup calls are processed as well.

3. Direct Calls to Rollups: When an Ethereum transaction needs to invoke a rollup, control is passed directly to the rollup, where the execution is carried out and the output is recorded.

4. State Change Recording and Application: Any state changes resulting from rollup executions are compressed into minimal data and recorded. When applying changes on-chain, the builder applies Ethereum transactions and rollup state updates in the same order as executed off-chain.

5. Single Proof Generation and Submission: The entire transaction execution and state application process is bundled into a single proof to form the Ultra Transaction. If the proof fails verification, the entire process is rolled back, ensuring atomicity.

Through this process, cross-chain calls between Ethereum and multiple rollups can be performed nearly in real-time, sequentially and atomically. It enables different blockchains to interact as if they were a single blockchain.

Taiko is considering a gradual adoption of this concept. Even if an entire block isn’t composed of a single Ultra Transaction, practical alternatives are being discussed—such as placing it at the beginning of the block or mixing it into the block structure. These approaches are being designed to be compatible with Ethereum’s Proposer-Builder Separation (PBS) model and the MEV supply chain. If the Ultra Transaction model is successfully implemented, it could also have positive effects on MEV management and the unification of Ethereum and rollup transactions.

5. Designing New dApps Based on the BBR

So, what new possibilities emerge when the World Motherboard—BBR—is combined with Ethereum, the World Computer?

5.1 DeFi

Looking at the DeFi sector first, traditionally developers needed to deploy DeFi service contracts separately on Ethereum and each rollup, which led to fragmented liquidity. However, in a BBR environment, a DeFi smart contract only needs to be deployed once on Ethereum, and it can automatically be used across all booster rollups. For example, if a developer deploys a smart contract with swap functionality on Ethereum, the same contract can be automatically deployed to all booster rollups.

Through this, each rollup can process certain DeFi transactions in parallel, significantly boosting overall throughput. Developers don’t need to rewrite contract code extensively—just designate which functions should be parallelized. For example, the state of liquidity pools can be distributed across different rollups, while information requiring global consistency—such as the total pool size or global settings—is maintained on Ethereum. This enables flexible architectures, such as assigning specific rollups to individual liquidity pools or distributing high-volume trades across multiple rollups. As a result, a new model emerges where a single massive DEX operates in an integrated fashion across many parallel blockchains.

The result is a new form of unified decentralized exchange (DEX) that operates seamlessly across multiple parallel blockchains.

Lending protocols can also be redesigned more efficiently under the BBR structure. In the case of protocols like Aave, separate markets had to be maintained on each rollup in the past. But with BBR, global states—such as total deposits or liquidation mechanisms—can remain on Ethereum, while user-specific operations—like interest calculations or loan executions—can be processed in parallel on rollups. This maintains the overall protocol’s security and consistency while enabling scaling of computation and responsiveness with the number of rollups.

Users can also leverage assets with a single account across multiple rollups. For example, a user could deposit collateral on Rollup A and take out a loan on Rollup B—all handled within a single transaction.

5.2 NFTs and Gaming

The NFT and gaming sectors can also benefit significantly from the BBR architecture. If an NFT marketplace is built on top of BBR, the original NFT smart contracts can reside on Ethereum, while all rollups can directly access and interact with them. Users no longer need to bridge NFTs between rollups—they can trade them directly on any rollup of their choice. For instance, if one user lists an NFT for sale on Rollup A and another user purchases it on Rollup B, the transaction can be processed atomically in a single step thanks to BBR’s shared state and atomic transaction model. Final ownership is then reflected directly on Ethereum. This eliminates NFT liquidity fragmentation and unifies users across rollups into a single, seamless market.

A similar structure can be applied to games. The world state and core assets of a game—such as characters and items—can be stored on Ethereum, while computation-heavy components like battles or mini-games are offloaded to rollups for parallel processing. For example, in a large-scale game with a vast map, different regions can be assigned to different booster rollups. Thousands of players could then operate in different areas simultaneously without interference, maintaining smooth gameplay.

Character data being stored on Ethereum allows seamless movement between regions (and rollups), creating a user experience that feels like a single, unified server. This structure enhances both performance and scalability while keeping gameplay cohesive and immersive.

5.3 Social Networks

BBR architecture also holds great promise for decentralized social networks. In a service akin to a decentralized Twitter, core information such as user IDs, profiles, and friend relationships can be stored on Ethereum and accessed consistently across all rollups. Meanwhile, high-frequency user activities—like posts, comments, likes—can be processed on booster rollups in a distributed manner. This allows users on different rollups to interact seamlessly with each other. If a particular person or topic suddenly generates high traffic, the system can dynamically add new rollups to handle the load, enabling elastic scalability.

5.4 Coprocessor-Based dApps

BBR also enables the design of coprocessor-type dApps. One example would be AI dApps that use on-chain machine learning models. Normally, these dApps would function through simple Ethereum smart contracts, but when large-scale computation (e.g., model inference) is required, they can offload the task to a booster rollup acting as a coprocessor. The result is then submitted back to Ethereum using a zero-knowledge proof.

This concept ties in with Taiko’s zkEVM coprocessor proposal and represents an efficient way to distribute complex computations while only recording the final, verified result on-chain.

5.5 A New dApp Paradigm Driven by BBR

Ultimately, dApps in the BBR environment are fundamentally anchored to Ethereum, while their execution is distributed and parallelized across multiple rollups. Developers only need to design their applications with parallelizable logic and shared state in mind—BBR handles the complexities of multi-chain deployment and bridging automatically.

This shift not only enhances performance and scalability but also transforms the very way dApps are architected across all sectors—DeFi, gaming, social, AI, and beyond. BBR introduces a new design paradigm where Ethereum remains the secure root, and rollups act as seamlessly integrated, high-performance extensions of the world computer.

6. Why We Should Pay Attention to Taiko's Vision of the “World Motherboard”

Source: Taiko Mirror

Until now, rollups have been viewed as a promising solution to Ethereum's scalability challenges. However, in practice, rollups have evolved to function independently, leading to issues like fragmentation, dispersed liquidity, complex bridge structures, and asynchronous communication between blockchains. These challenges have negatively impacted both usability and developer experience, ultimately falling short of making Ethereum a truly "scaled world computer." Rather than solving the problem, rollups have become isolated environments of their own.

Now, it’s time for rollups to return to their original purpose—not just as tools to increase throughput, but as components that horizontally and vertically extend Ethereum, functioning in a unified, interconnected structure. Taiko’s Based Booster Rollup (BBR) architecture is bringing this vision to life.

However, BBR must confront several real-world hurdles. Most rollups currently in operation are not based rollups, making them inherently incompatible with BBR’s unified state model. Even rollups that are designed with a based structure would require substantial additional development to integrate into the BBR framework—such as enabling Ethereum state access, implementing booster block architecture, and migrating to a unified bridging model. This isn’t a simple plug-and-play process; it demands significant developer resources and architectural transitions.

Worse yet, if BBR fails to gain ecosystem-wide adoption and standardization, it could unintentionally reinforce the very fragmentation it aims to solve. If only some rollups adopt BBR while others stick to legacy designs, issues like state inconsistency, liquidity silos, and incompatibility between chains would persist—holding back the broader rollup ecosystem. No matter how technically superior BBR may be, without widespread buy-in, its unifying potential remains limited.

Despite these challenges, if BBR gains traction, Ethereum could function as a true world computer—not a loose federation of rollups and bridges, but a cohesive system with native scalability. Users would be able to move freely across rollups as if they were using a single blockchain, without worrying about network switching, address confusion, or asset transfer delays. Developers could build high-performance, secure, and consistent on-chain applications without dealing with the complexity of multi-chain infrastructure.

Ultimately, for Ethereum to reclaim and revitalize its role as the “World Computer,” simply expanding the number of rollups isn’t enough. What’s needed is the architectural glue—a "World Motherboard"—to unify and coordinate these rollups. From this perspective, Taiko’s BBR stands out as a compelling technological answer to that need.

It’s time to look past Ethereum’s past glory and focus on what could make it youthful again. If BBR succeeds, Ethereum may finally drink from the “Fountain of Youth” and emerge as the truly unified, scalable, and accessible platform it was always meant to be.