Long Live The Superbuilder!

In a world where blockspace is abundant, composability is what matters.

Let me take you back to the early 2000s: bulky desktops, dial-up ringtones, and chunky Nokia phones. Online, glittery “Under Construction” GIFs are everywhere, and personal websites showcase pixel fonts and low-res images. 

This was the web 20 years ago—quirky, loud, and unapologetically DIY. It was also fragmented. Websites were isolated, with no share buttons or embeddings, and each required separate logins. Most were static and manually updated. Building your own site? Forget the ease of modern tools like Squarespace or Wix—this was the age of barebones solutions. Don’t believe it? Just check out Nintendo’s homepage from 2001.

Blockchains today are in a similar spot to those sites. Rollups and other L2s are fighting to grow their ecosystems by attracting dApps and services. The experience of transacting across the web of existing chains, however, remains tedious even for the earliest adopters. In his post Abstracting Chains, Shilok Khomei lists 10 steps and 28 separate clicks a user needs to take in order to purchase an NFT on a separate chain. [See Appendix I for the full example]. Keep in mind, checking out on Amazon is one-click.

While many solutions, like shared sequencers, aim to solve this, their inability to guarantee atomic execution fails to fully solve the fragmentation issues. Bridges have been developed to treat symptoms of this fragmentation, allowing for assets to transfer between chains more quickly and asynchronously, but still fail to solve the root cause: a lack of composability across chains. The superbuilder, recently implemented by NodeKit’s Javelin, solves the cause of fragmentation by enabling composability across chains. Superbuilders are blockbuilders that build blocks for multiple chains at the same time. By guaranteeing the atomic execution of transactions, chains on a superbuilder can be as composable as apps on the same L1.

As crypto adoption increased in the late 2010s, Ethereum ran into a problem-- it was too popular! High usage drove on-chain gas fees higher, and as usage grew, Ethereum's pricing would have made widespread onchain activity infeasible. While users would begrudgingly endure fees for limited NFT drops, no one was going to paying $1 fee to buy a $5 cup of coffee. To enable blockchains to scale and meet the demands of the global economy, Ethereum began working towards a rollup-centric roadmap.

To achieve horizontal scaling, L2s act as independent chains that “settle” or post their state to Ethereum at intervals. Each L2 can be thought of as its own chain with a special node called the sequencer which lives onchain, accepts transactions submitted to the L2’s mempool, orders them together into a block, and broadcasts the block to other nodes in the network. The sequencer is also responsible for posting the state to Ethereum’s L1, allowing the rollup to inherit some of Ethereum’s security guarantees. This design allows multiple L2s to spin up concurrently and run in parallel, each with their own nodes and sequencers.

While this architecture enabled horizontal scaling, the tradeoff was a fragmented ecosystem. Designating one sequencer per rollup also created risks surrounding censorship and downtime. If the sequencer went down, the entire L2 was unable to produce new blocks and the chain halted. To remedy this, some L2s like Morph and Metis enable decentralized sequencers, where the task of sequencing transactions and producing a block is handled by a network of nodes. While many implementations have been explored, they all share a similar architecture with multiple sequencers for each L2. One sequencer is randomly selected in-protocol to build the next series of blocks, making censoring the chain or forcing downtime much harder for a malicious actor.

Decentralizing the sequencers addressed some of the challenges regarding downtime and censorship, but because blocks were still sequenced independently on each chain, the fragmentation problem remained. Espresso Systems led the development of shared sequencers with two objectives in mind: better decentralization for rollups and composability between chains. Shared sequencers kept the network of sequencer nodes but extended the decentralized sequencer paradigm by allowing them to build for many L2s at once.

Giving a sequencer the rights for multiple chains at once allows for cross-chain interactions. This is because the sequencer can include transactions in both blocks that are being added to their respective chains at the same time. For example, if a sequencer has the right to sequence for Chain A and Chain B, they can guarantee a transaction will be included across both chains because they are responsible for the contents of the blocks for both chains. This was a start in allowing sequencers to provide enhanced interoperability between the chains that they were sequencing. A sequencer could now include a burn transaction on Chain A and a mint transaction on Chain B to complete a bridge in a single block. Together, these two transactions are effectively bundled (see diagram below).

Shared sequencers between rollups were cheaper and easier to implement at scale compared to bootstrapping individual sequencers or sequencer networks for each L2. They addressed the question of decentralization with ease, but couldn’t on their own ensure true cross-chain composability. Why? Shared sequencers cannot guarantee the atomic execution of transactions, only atomic inclusion.

By creating these bundles, shared sequencer networks could ensure atomic inclusion—that bundled transactions will be included in the next block. Mere inclusion of transactions, however, is not a sufficient guarantee to enable true cross-chain composability since both chains will see the transactions, regardless of the validity of the transactions themselves. Shared sequencers alone cannot ensure that transactions are valid, because they are not state-aware: they only see the transactions submitted to them, but do not have a view into the current state of the chains they’re building across.

Without knowing the existing state of each chain that they’re building across, the shared sequencer cannot run the transactions to guarantee their validity before including them in the block. While invalid transactions onchain can be rectified (more on this later), in situations where physical assets are exchanged as part of an onchain transaction, repossessing the asset might be impossible—it’s pretty challenging to give back a muffin after it’s been eaten. The potential for security exploits becomes clear when considering a concrete example and each outcome on a case-by-case basis. 

Let’s say I’m in a rush and frantically ordering a coffee online at my local crypto-enabled coffee shop. The coffee shop transacts on Rollup A and my USDC is on Rollup B. The shared sequencer includes two transactions in its bundle. One sends my USDC to a smart contract owned by the coffee shop (burn) and another to mint a receipt allowing me to pick up my coffee.

When both transactions are valid the sale is executed successfully. If neither is valid (a user lacks sufficient funds and they’re sold out of coffee for example), then the sale is unsuccessful and the funds remain untouched. However, if the mint transaction is successful, but the burn transaction fails then I receive my receipt and can pick up the coffee but my funds stay untouched; I just got a free cup of coffee. On the other hand, if a burn transaction is valid but the mint isn’t because the last coffee had just been bought on the previous block, I’ll end up paying without receiving anything; my money is stolen.

In that case where one transaction is valid while the other is invalid, the safety of the user’s and chain’s funds is put in jeopardy. To resolve potential issues caused by these invalid bundles, shared sequencer networks like Espresso include provisions to reorganize or “reorg” the involved chains to return to a state that was known to be valid. This is cumbersome at best for chains and users. Users may not know that their transactions have officially landed until many blocks after they make their submission, and chains need to spend time and resources returning to valid state. The problem is sufficiently large when applied to two chains, but compounds as more chains are added to the network, with reorgs having cascading effects that can lead to an unacceptable user and developer experience. Further issues arise from the complexity of allocating the sequencing rights between chains as the number of chains in the network scales. In this design [See Appendix II for further explanation], users cannot communicate with all other chains in the network in every block, but must wait for a sequencer to have overlap between the chain they are on and the chain they wish to transact on.

In lieu of atomic synchronous communication, fast interoperability solutions have developed to attempt to provide some of the sought out functionality. Solutions, like intents-based bridges, provide fast, asynchronous bridging of assets between chains. For users who want to bridge between chains quickly with no immediate use on the other chain, this is a fine solution. It falls short, however, for apps or users that desire more functionality than token transfers. General message passing, calling of state, and synchronous asset transfers are not enabled, greatly limiting the cross-chain design space. Ethereum didn’t succeed because of users’ ability to quickly move assets between apps, but because all data could be passed and seen anywhere on the L1, making for a seamless user experience across the board.

To reap the benefits of true L1 composability while using rollups to provide scale requires atomic execution. Simply put, atomic execution guarantees that both transactions will not only be included but also execute simultaneously. 

The only way to enable this is to have a way of knowing the prior state of multiple chains, and control over the transactions and orderings in the next block. Enter, the superbuilder. Superbuilders are specialized block builders that build blocks for multiple chains at the same time, and chains that leverage a superbuilder can guaranteeing atomic inclusion as well as atomic execution of transactions because they share the same state-aware block producer.

NodeKit is leading the development of superbuilders with their solution Javelin. Javelin improves upon the cross-chain composability that shared sequencers sought, fulfilling the initial promise of shared sequencers. With Javelin, two chains on NodeKit are as composable and can communicate as seamlessly as two apps on the same L1.

Superbuilders still face technical challenges due to their complexity. A superbuilder requires an understanding of the lifecycle of transactions on rollups, MEV, and block building, all while optimizing for speed and latency. However, this is also accompanied by a commensurately large benefit to chains, apps, and users of composable systems. 

With a superbuilder, chains unlock the ability to access all the liquidity, users, and apps across all chains on the composable network instantly. Because of a superbuilder’s ability to provide cross-chain composability and not just fast asset bridging, ecosystems can be bootstrapped overnight without the need to provide initial liquidity on a chain. Developers can access users and activity while also benefiting from lower costs and customizations of running their own L2 without needing liquidity pools, thereby enabling easy deployment and rapid scaling of ecosystems.

A further benefit provided to chains by integrating with a Superbuilder is their ability to increase revenue by expanding the amount of maximal extractable value (MEV) captured. [See Appendix III for an explanation and further discussion about MEV.] These opportunities, however, are not currently accessible due to the inability for builders to order transactions across chains. A recent study by Flashbots estimated the market for MEV on L2s to be over $3.6 Billion in the past year, representing a substantial opportunity to expand the profitability of running a L2. In fact, in its current design, Nodekit’s Superbuilder returns 50% of the MEV capture back to the L2. 

Applications benefit from the ability to aggregate all users and liquidity across all their instances across chains in a composable network. DeFi applications benefit from improved execution quality on their platform—as all trades are placed against a larger, unified pool—and consumer applications benefit from having a single account to represent all activities across all chains in the network. 

The combination of the benefits for apps and chains empowers more apps to launch chains to improve their value capture. Whereas apps once needed to launch on a chain with existing users or bootstrap liquidity, composability across chains now frees apps to forge their own path. Developers can capture more value and improve sovereignty with a chain of their own, all while retaining access to users and liquidity on a composable network.

In the future, users will engage with a unified experience bringing together everything they do or own across many different chains. Much like people today have a bank balance that is used to buy goods at many stores without holding a balance at each store, users will be able to hold their assets on a single chain but utilize and spend on chains and apps across a composable network. Simplifications like these, enabled by cross-chain composability, will help to onboard and maintain new users into web3.

Composability across chains will unlock the next phase of blockchains, transforming them from the fragmented experience of the internet two decades ago to the internet of today. Where there is proliferation but poor integration, there will be a seamless experience between apps on a network– a UX designed not only to attract new users but one that encourages them to stay. 

NodeKit is spearheading this charge with the first production-ready superbuilder, Javelin. By enabling users to access their liquidity on all chains in the composable network and allowing for single-block cross-chain transactions, NodeKit is not only poised to generate significant value from MEV capture, but power the future of blockchain communication, enabling blockchains to achieve internet-level scale and seamless user experience.

I. From Abstracting Chains by Shlok Khemani.

​​”Consider this scenario: Martin is new to crypto, and his favorite artist has just released new artwork as an NFT on Optimism for 0.1 ETH (~$250). Martin asks his crypto-native friend Joel to send him some funds. However, Joel only has USDC on Base. Because Martin is in a rush (it is a limited-edition mint), he asks Joel to send him the funds, and he’ll figure out how to make the purchase. Martin might not be very familiar with crypto yet, but he is tech-savvy. How hard could it be?

Deceivingly hard, as it turns out. Here are the steps he will have to follow.

There are at least 10 steps and 28 separate clicks. And I’m being liberal here by assuming Martin already has a wallet set up, can use the same wallet for both chains and finds the information he’s looking for (how to fund gas, the right bridge, the right DEX) in one go. This also does not count miscellaneous steps like signatures and transaction confirmations in the wallet. For an absolute beginner, this would be a nightmare. Buying an NFT on one chain using funds from another–one of the most basic user flows in crypto–should not be rocket science.

II. Broadly, chains can sell the right to sequence their blocks on the Espresso Marketplace. Independent sequencers can then buy the right to sequence for individual chains or multiple chains at once. Think about it like this— sequencers bid on a fixed number of blocks for each chain they’re choosing to build across. Tickets are auctioned, and while they guarantee that the holder has the right to build a block, they don’t specify which specific block in the ticket itself. 

For a concrete example, let’s assume there are 10 chains (1-10) being sequenced by the Espresso Network and that tickets are sold for the next 10 blocks. If I, as a sequencer node, hope to build across chains 1, 3, and 5 and want to secure two blocks per chain, I would bid to purchase 2 tickets on each of the chains. While these two tickets guarantee me the ability to build two of the next ten blocks on each rollup, purchasing them alone gives me no color on which blocks I’ll be building.

The Espresso network then uses this information to determine the optimal block production: one that optimizes overlaps between sequencer blocks. In our example, I would get the right to build the block at the same block height for each rollup—if tasked to build block 6, for example, I would have the ability to build block 6 for chains 1, 3, and 5, in the ideal case. In practice, given that there are many other chains and multiple actors, a perfect solution is never found, but this mechanism enables Espresso to create a robust sequencer network that resists centralization or coercion.

III. MEV

Similar to the Ethereum L1, there is significant value to be captured from how blocks are built. In EIP-1559, Ethereum introduced a dual-fee structure where each transaction’s base fee is burned and a priority fee is given to the validator who builds the block. The sequencer (whether part of a network or a single actor) is analogous to the validator. The strategy to maximize revenue seems deceptively simple: pick  the transactions with the largest fees. However, due to the sequencer’s ability to choose and order transactions, there exists an additional source of revenue dependent on the selection and ordering of transactions. For example, a validator may execute a sandwich attack, where they strategically place their own transactions before and after an order to arbitrage known changes in price, or trade a price discrepancy between centralized and decentralized exchanges in a CEX/DEX arbitrage. Together with the priority fee, these comprise maximal extractive value or MEV, which describes the total amount of profit a block proposer can gain from building a block.

Given the time constraint to build a block and the number of transactions available to choose from, the economic optimization of MEV has led rise to highly specialized actors known as block builders using significant computational power to solve combinatorially complex equations, something most nodes are ill-equipped to handle. Optimizing MEV capture is synonymous with the multi-dimensional knapsack problem, a known NP-Hard problem. Like many of the mathematical problems that underlie tools used by billions–Google Maps finding the shortest route home for example–the best solutions use fine-tuned heuristics and enable the capture of significant value. In Ethereum, a market arose where specialized block-builders bid validators for the ability to create each block. For a more in-depth understanding of the current landscape and MEV, see the Ethereum developer docs as well as some of the work being done by the Ethereum foundation and Blockchain Capital’s Jonah Burian to model MEV.