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.

Over 95% of internet traffic leverages the HTTPS protocol–secured by Transport Layer Security or TLS–to cryptographically ensure that communications between a client and server cannot be tampered with or snooped on. TLS is generalizable and used to secure communications protocols like SMTP (email), FTP (file transfers), and VOIP (real-time audio).

Designed for secure point-to-point communications between exactly two counterparties, TLS loses its attractive security properties when third parties are introduced. For example, third parties have a hard time verifying messages secured by TLS because both counterparties share the symmetric key and can unilaterally falsify content (more on this below). To convince a third party that a TLS transcript is correct, therefore, involves ensuring that it was not modified to fit some predetermined criteria.

If third parties could verify TLS-encrypted messages—through zkTLS solutions—opportunities would arise for open networks and new methods of trust authentication. Crucially, this could occur  without the historical reliance on and power vested in dominant web2 corporations. Business models based on hoarding private user data and aggregating proprietary social or reputation graphs would be disintermediated. Instead, a new class of business models would use cross-platform composability to enable new forms of collaboration at global scale, fundamentally disrupting the balance of powers in industries like online payments, influencer marketing, and identity verification in favor of end-users (and at the expense of centralized platforms). As on-chain ecosystems enter the mainstream, zkTLS will unlock previously unimaginable flexibility and optionality.

Perhaps most importantly, we believe that zkTLS will empower users to regain ownership of their own data, generate and transfer their own authentications for a fraction of the price, and allow companies to build upon previously inaccessible networks. The best part: this will be done without the need for an API or any buy-in from the companies themselves. zkTLS is a clear solution that disintermediates walled gardens and embodies the ownership of the web3 movement.

Given the scale of value creation by social media giants alone—not to mention gig economy apps and tech companies in health care—on top of private social/reputation graphs over the past decade, we believe such a scenario could drive hundreds of billions of value transfer to new, open networks. 

Recent advancements in cryptography and secure computation have made third-party verification of TLS-encrypted messages a possibility in the near-term, though many challenges remain. This is the heart of the issue that cryptographers at Opacity, Clique, Reclaim, and other TLS projects are working on. Let’s take a look at the opportunities, structures, and possibilities of the leading on-chain TLS projects.

When communicating with a server over the internet, it is imperative that a user can trust the validity of queries from the server. Clients use the HTTP protocol to fetch resources such as HTML documents from the server and reconstruct them on screen. SSL, or Secure Socket Layer, is an encryption-based Internet security protocol and the predecessor to modern TLS encryption used today. When a website implements SSL/TLS, it has HTTPS in the URL, which we are often advised to look for, rather than just HTTP. 

Here’s a good mental model for how SSL/TLS works. The server has a private value and the client has a private value. The client and server use these private values to arrive at a common shared secret used to derive a symmetric key that both the client and server possess. With this symmetric key, both the client and server can encrypt and decrypt each other’s messages to the exclusion of anyone else. [1] 

This setup, however, is susceptible to a man-in-the-middle attack, where a malicious third party  intercepts packets between the client and server, impersonates each party, and can fabricate messages that look legitimate. [2] To overcome this flaw, Netscape implemented the Certificate of Authority in 1999, where the public key of the server is signed by a Certificate authority—a handful of predetermined actors who validate the identity of entities, such as websites. Now, before engaging with the server to create a shared secret, the client requests the server’s certificate signature to ensure they are communicating with the right entity. 

When convincing a third party of a valid transcript, however, things get more tricky. The challenge is that since both parties have the same secret key, the user is capable of fabricating a transcript and signing the server’s responses as well, creating the appearance of a valid claim to a third party. In order to trust the provenance of a claim, then, we must complicate the normal network request.

Symmetric keys are useful for a user and server to verify each other’s claims, but because the user possesses the same key as the server, an entire transcript can be forged by the user, allowing the user to claim anything they choose. There are a few different current and proposed solutions in the space, elaborated below.

Using a trusted execution environment: Clique, a network that closed its recent $8m Series A, focuses on building out a trusted execution environment (TEE) network for blockchain networks as a whole, but one of the major offerings is a zkTLS solution that utilizes TEE. 

A TEE is a secure area in the main processor that is entirely encrypted and cannot be directly opened by even its owner. Owners interact with the TEE through designated and secure interfaces that allow the running of secure authorized applications called trusted applications. The TEE then returns a result and a signature attesting that the result comes from a particular program. Theoretically, this makes the system tamper-proof, even against those running TEEs in the network. 

However, as Dr. Andrew Miller at University of Illinois has been demonstrating for years by breaking TEEs (primarily Intel SGX), they aren’t a perfect solution. Any large-scale solution relying solely on TEEs has to contend with this challenge, especially when involved with smart contracts in more high-stakes situations, like KYC (Know Your Customer) regulation. 

Using a proxy witness: Another possible solution is to use a proxy witness that acts as a middleman between the client and server and attests to the accuracy of the transcript. The Reclaim Protocol, whose white paper was published late last year, is the most popular example of this strategy.

A trivial solution is to reveal to a third party, called the attestor, the user’s TLS private key. This allows the attestor to decrypt the encrypted request, check the correctness of the request, the correctness of the corresponding response, and attest if deemed correct. The challenge, however, is that this approach also reveals private information such as authentication tokens and cookies to the attestor, which gives the attestor login access to the user’s account.

The Reclaim Protocol solves this using a three-part construction that involves a key-upgrade mechanism. With only one attestor, however, the collusion problem once again rears its ugly head. If the user and attestor collude, then anything can be signed. To overcome this, Reclaim includes a subset selection of validators to help randomize and prevent this. However, since the attestor in the Reclaim protocol is responsible for conducting parts of the TLS handshake, their IP address is known by the server. Therefore, it is possible that servers could block IP addresses associated with attestors at scale, reducing the viability of such a system.

Using multi-party computation (MPC): TLSNotary and Opacity

In MPC schemes, two or more parties jointly compute a function over their inputs while keeping the inputs private. The parties learn the result of the function at the end, but none of the participants learns anything about the other’s inputs. In the case of TLS, an MPC node and the client would jointly make the TLS request and generate the transcript such that no one knows the shared secret key until after the session is finalized. Crucially, this approach is undetectable by the target server, which, unlike the Reclaim Protocol, is not being bombarded with requests in a short timespan but only has to respond to one. It is indistinguishable from the client logging in by themselves.

A few challenges arise from the MPC-TLS approach. The Shamir Secret Sharing MPC (SSS-MPC) scheme is very effective in scaling the number of parties that are conducting the computation. Since all parties must collude to reveal the shared secret, the more parties conducting the computation, the harder it is to collude—and the greater our security guarantees can be. SSS-MPC is commonly used in MPC wallets, like those in the Lit Protocol.

SSS-MPC, however, is not a good solution for the zkTLS case because of the type of computation required for TLS. The shared secret is the result of an ECDH (Elliptic Curve Diffie-Hellman) key exchange. To hash in SSS-MPC without any party being able to reconstruct the input or output is challenging because SSS-MPC is fundamentally an algebraic scheme. To make them harder to break, however, the hash functions used in TLS are not algebraic in nature and rely on binary operations (like XOR). This discrepancy creates a prohibitively high communication overhead that scales factorially as new parties are added.

To get around this, Opacity uses garbled circuits and oblivious transfer (OT) schemes. Unlike arithmetic circuits, garbled circuits are boolean in nature and consist of gates (like AND, OR, NOT) that perform binary operations, making them much more efficient for hashing. OT is a cryptographic technique that allows one party (the sender) to send information to another party (the receiver) in such a way that the sender does not learn which specific piece of information the receiver obtained, and the receiver cannot obtain more information than they are entitled to. By using an OT scheme, parties can select and compute on data inputs without revealing which inputs they are interested in, maintaining the privacy of their choices and inputs throughout computation. For garbled circuits, OT can be used to securely transmit keys for the input wires without revealing which keys were chosen. Garbled circuits and OT schemes, however, scale poorly beyond two parties—many of the optimizations developed for two-party garbled circuit/OT computation are unavailable for MPC with more parties.

TLSNotary is the current MPC TLS solution. The scheme works as follows: the user, called the prover, and another party, called a notary, engage in an MPC together. The output is then signed by the notary, making the data portable. The user can take the signed data and disclose parts to any application-specific verifier. The challenge here is that the notary must be trusted. If the notary and the prover collude in MPC, they can reveal the shared secret key and fabricate any transcript between the user and the server. While it is possible to have the user generate multiple proofs from many notaries before trusting the result, known as proof by committee, such a system would only work if the user cannot change the value between proofs. We can use the bank example to illustrate this further. If we have a committee of five nodes, all of whom have to agree for the server transcript to be considered valid, and a recurring debit hits the account between the third and fourth nodes conducting the MPC, then the last two nodes will disagree with the first three and may be slashed even though they conducted the protocol correctly. An easy solution might be to have all of the nodes conduct the MPC at once, but most servers will flag this as fraudulent behavior since it looks like multiple login attempts to the same account, all at the same time. For a truly general zkTLS solution, proof by committee doesn’t work, since price data (a stock price for example) is changing too quickly to allow for multiple parties to conduct the MPC and determine a value without significant margin.

Opacity Network:

Opacity builds from the existing TLSNotary framework with added safeguards and provisions to reduce the trust assumptions inherent in the protocol. It does this by layering multiple security considerations that disincentivize byzantine behavior and collusion. These include an on-chain verification of a web2 account ID, a commit and reveal scheme, a random sampling of the MPC-network, an on-chain verifiable log of attempts, and a whistleblowing process.

Given that account IDs act as the primary identifiers in a web2 company’s database, it is standard practice never to change them. This enables a proof by committee to prove ownership of a web2 account, and Opacity’s framework expects users to generate ten identical proofs by different nodes in order to claim a web2 account. Because this account is now mapped to a unique wallet address, a user cannot try different wallets until they find a node willing to collude. This scheme doesn’t work for public data not associated with any account such as a weather feed or public stock price. In these cases, oracles can be limited to a trusted subset or required to put up stake, and the protocol can be engineered to be much stricter with the log of attempts (discussed below).

The commit and reveal scheme to further secure against collusion where a user cryptographically commits to a value before a notary node is selected. If a user claims to have $1 million in a bank account, they would have to commit to the $1m before a node is chosen. Combined with an on-chain record of a user’s attempts to generate a signed transcript, Opacity further disincentivizes users from trying the process repeatedly before finding a node willing to collude. For example, even if a user could find a node to collude with on the third attempt, a smart contract reading the signed transcript will still be able to read the on-chain log and see the previously failed attempts, raising red flags.

Additionally, Opacity nodes are required to run their software within Intel SGX (a TEE). Assuming the TEE is not broken, this alone makes collusion impossible. Unlike Clique, we note Opacity’s specific solution as a layering of security considerations beyond TEEs. The plan is working closely with the Eigenlayer team to use Eigenlayer’s AVS (actively validated service) whereby nodes will be required to restake 32 stETH and are slashed for improper behavior. And because Eigenlayer uses stETH for its restaking, slashing and redistribution of stake takes place immediately rather than waiting until a withdrawal cooldown period is completed. 

While we note it’s possible that the breaking of the TEE would allow a node to collude in MPC, Opacity’s team is currently focusing on implementing a whistleblowing process whereby any user that can submit proof of a notary acting improperly will receive part of the slashed stake (more on that to come).

The ability to prove TLS transcripts onchain will unlock entirely new functionality as users will have control over their own data without needing permission from large corporations. While there is work to be done, zkTLS companies promise to enable novel use cases that shift power towards the users. And Opacity's thoughtful method of layering security considerations while using MPC is a novel approach that is already being used to drive value across industries.

1. The process by which a user and server obtain symmetrical keys is a Diffie-Hellman key exchange to find a shared point on an elliptical curve. The x-coordinate of this shared secret is then HMAC’d (hash-based message authentication code) by both the client and the server to derive a symmetric key. Since both the client and the server use the SAME set of the symmetric keys, they can now both encrypt/decrypt the transcript. 

2. In a man-in-the-middle attack, the malicious party performs individual Diffie-Hellman key exchanges with the client and the server while pretending to be the other party, so that it alone can fabricate messages claiming to be the server to the client and vice versa.

3. Opacity is also adding moving to add support for vector oblivious linear evaluation (VOLE), which allows for efficiently constructing a 1 of N oblivious transfer (OT) vs 1 of 2, thereby reducing network overhead by a factor of one to two orders of magnitude.

Ethereum’s successful Dencun update in March and the recent launch of EigenLab’s data availability solution, EigenDA, has brought data availability (DA) back into the spotlight. Dencun introduced EIP4844, Ethereum’s first major leap towards a rollup-centric future that introduced data blobs. Blobs provide a dedicated space for rollup data; rather than being stored as calldata, and by having a separate data availability space for layer-2 projects (eg. rollups) that is not Ethereum Virtual Machine (EVM)-accessible, the blobs can be verified separately from a block. While data blobs serve as the native Ethereum DA solution, other non-native DA solutions—like EigenDA and the Celestia network—have become wildly successful. When examined more closely, however, there are important and nuanced differences between native and non-native DA that concern security, attribution, and ultimately should be reflected in price.

For a rollup to settle its state on L1, the L1 has to be convinced that the rollup executed its transactions correctly. The L1 nodes could run all of the transactions to verify that the claimed state is correct, but that would prevent any real scaling. In practice, a rollup will post state differences and transaction data to the L1 and then rely on either a fault proof or a zk (zero-knowledge) proof to convince the L1 that the state is correct.

A fault proof operates as follows—the L2 sequencer posts an updated state root along with a bond, any network participant can download the transaction data and run the transactions, and if a party (verifier) detects a mismatch between the rollup state referenced in the state root on the L1 chain then the verifier can challenge this state transition and prove its invalidity. The verifier does this by computing a machine trace, which captures the step-by-step execution of the EVM, including opcode execution, memory and storage modifications, and any other relevant state changes. The verifier and sequencer use essentially a binary search algorithm to determine where the initial disagreement lies. That step is then run on chain, and if the new state differs from the sequencer’s claim, then the sequencer’s bond is given to the verifier and the rollup state is reversed. Because of this process, fault proofs have a seven-day settlement period. Interestingly, when analyzed game theoretically, any sequencer that attempts to deceive the L1 will be caught due to the economic incentive for the verifier and the ability to rerun the transactions. Crucial to this process, however, is the universal availability of rollup transaction data. If the data is not available, no party can rerun the transactions and challenge a sequencer’s claims, allowing a sequencer to commit fraud and lie about the rollup state without reproach.

While a validity proof operates differently, data availability is still crucial. In a validity proof, the sequencer posts a zk proof that the transactions and therefore new state root have been executed correctly. A zk-validity proof is a succinct cryptographic proof that the state transition followed the rules of the system. The zero-knowledge nature of the proof indisputably proves that the transactions and the state change are valid but reveals no information about the transactions themselves. In this case, transaction data is not needed for full nodes to verify that the transactions were run correctly and compute new state roots. If the data is not made available, however, nodes on the L1 cannot open the cryptographic commitment to the state and determine account balances, which is applicable only to certain scenarios. For example, if the data is not available and the rollup operator ceases operations, rollup users would be unable to withdraw to the main chain because nodes have no way of calculating their current balance. In addition, if a malicious sequencer did any transactions, it would drastically change the state root—without the data being made available, no one can withdraw their funds.

To understand why, it is imperative to delve into what the state root is. The state root is a cryptographic commitment that can be opened, usually a Merkle Patricia trie, but it can also be a standard binary merkle trie or verkle tree. The most basic Merkle tree is a tree where leaf nodes carry the state data—think account balances and smart contracts. Each leaf node is hashed with its neighbors, creating a parent node. Then the parent node neighbors are hashed together to determine the subsequent parent node. This process continues until the root of the tree is reached and a single hash—the state root—is produced. Changing even a single leaf node will affect each parent hash and propagate up the tree, thereby drastically changing the values of the intermediate nodes and the state root. Because of this property of hash functions, the state root is a commitment to the state of the tree, since any change or disagreement between nodes will result in a different state root. When a user wants to withdraw their funds from the L2 to the L1, the L1 nodes “open” the commitment by checking an inclusion proof that requires the L1 receiving log(n) of the sibling node hashes. If a byzantine sequencer conducted a single transaction without making the data available, the state root will be radically changed, and the L1 will be unable to construct a Merkle inclusion proof. Since account balances aren’t known, this renders any funds inaccessible. Therefore, a malicious sequencer could extort accounts and successfully launch a ransom attack. It is important to note that the sequencer can’t steal users’ funds due to the incorruptibility of the proof system, but without making the data available, they can hold users’ balances at ransom.

By now, the importance of data availability should be clear, and we can properly define the DA problem—how to prove that transaction records exist and are available to download without each node actually downloading the data. EIP4844—the Dencun upgrade—was the implementation of proto-danksharding (shoutout Vitalik, Protolambda and Dankrad Feist), the first step in Ethereum’s DA solution. Currently, all blob data is stored by all of the nodes, but with the future implementation of PeerDAS, which enables full danksharding, the blob data will be “sharded” amongst many nodes. L1 nodes will then use data-availability sampling (DAS) to ensure the data has been made available.

Here’s a good mental model to understand DAS, what it tries to solve, and why it works. PeerDAS, the system invented by the Ethereum Foundation (another shoutout to Vitalik, Dankrad, and Protolambda) to be used in data blob sampling, is a more complicated two-dimensional Reed-Solomon erasure encoding scheme, but the fundamental tenets are the same. For anyone interested, I encourage you to read their paper.

Let’s start with n data points that we wish to shard amongst a committee of nodes. To make numbers simple, let n = 1000 and our committee have a size of 10. We can plot our data on a Cartesian system where the first data point (n = 1) has an x-value of 1 and a y-value corresponding to the data value. Similarly, the second data point (n = 2) will have an x-value of 2 and a y-value corresponding with that second data value. With all 1000 data points now plotted, we can fit a polynomial of degree n-1 (in this case 999-degree) to the data. And given that our polynomial is a continuous function, we can now extend the polynomial by another 1000 values (eg. until x = 2000). While our data is encoded in the first 1000 points, it’s crucial to note that recovering any 1000 of the 2000 points is sufficient to recreate the polynomial and then calculate those first 1000 points. Now we split up our 2000 points amongst the 10 nodes in our committee such that they have 200 points each.

Trivially, we could sample all 10 nodes for all 2000 points and recreate our original data as such. However, this would quickly overwhelm our network and not result in a substantial bandwidth increase. So our task is as follows: how can we be convinced that the data is available without having to sample it all? The key is that while we expect all of the nodes to each carry 200 data points, in reality we only need them to make 100 points available for our initial data to be recoverable. If we sample a point at random and the node has stored 0 points, then clearly we won’t get a response, and if the node has saved all 200 points, we’ll always get a response. 

But what if the node has stored 99 of the 200 points? Well, if all the nodes we sample only store 99 out of the 200 points then we won’t have enough values to recreate our original data (since 99*10 = 990 is less than 1000) and we encounter the issues discussed earlier. If we sample a node that has stored only 99 out of the 200 points at random, then there’s about a 50% chance we’ll get a response. That’s not enough for us to trust. But what if we sample the node 20 times? The chances the node can answer each query is (99/200)^20 or approximately 1 in 1.2 million. That seems like a pretty safe assumption. By only sampling 20 out of the 200 points, we have a 0.000083% chance that our data isn’t available and we’re being played the fool. Interestingly, this scales quite well since if each node stores 2000 points instead of 200, we still only need to sample 20 points for a similar guarantee.

The astute among you may have an enduring question that I have avoided answering until now— what prevents a node that is being sampled from just making up some response. After all, the whole ethos of the crypto space is to minimize trust and it seems like we’re putting a lot of faith that Joe-Schmo’s node won’t send us a random value just to stop our pesky inquiries. The short answer is that the initial data is committed to using a KZG commitment which makes it impossible for the node to answer a query falsely without our knowing. The longer answer is that when encoding the data into chunks, the block proposer will use a KZG commitment scheme to commit to the polynomial, which is published to all the nodes along with the data availability root (DAR) which is the Merkle root of the data chunks. The network nodes will then download the chunks they receive and use the DAR to verify that the chunks are consistent and check the KZG commitment to ensure that the chunks came from the right polynomial. When nodes want to check DA and sample a random fraction of the data points, they use the KZG commitment to ensure that the node being sampled isn’t lying. The longest answer— for those of you who, like me, continually and perhaps annoyingly ask “why?”— will require a deeper-dive into commitment schemes, which is a piece that I am currently working on and will be linked here when completed.

In practice, our system would ensure redundancy by having a few different nodes store each part of the sharded data. It’s also important to note that this is a mental model for one-dimensional Reed-Solomon erasure coding. Ethereum, and its PeerDAS scheme, uses a two-dimensional model which is more complicated to explain—however, I might take a crack at that sometime in the future.

The interesting critique of Ethereum’s native DA is that you can deceive a handful of nodes into believing that a blob that does not exist might get finalized. This may initially seem like a glaring security concern, but we can be certain that this false block will never be finalized. Let’s see why.

Ethereum’s consensus mechanism relies on votes (called attestations) by nodes that the block at the head of the chain is correct. Nodes will only vote on that block if, among other things, the node can sample the data and is convinced that the data has been made available. Now, what happens if node A is sampling only node B to ensure that B has made the data available (we’ll come back to this), and B only responds to A’s queries? In this event, node A would be convinced that the data was available. However, node B could then decide not to respond to any other node’s queries, effectively rendering the data unavailable. Since node A believes the data to be made available, A will attest to this block at the head of the chain and amend its internal ledger. However, since Ethereum’s finality mechanism requires a supermajority of votes and we assume an honest majority (if we don’t have an honest majority, this becomes the least of our worries), the other nodes to which node B doesn’t respond will refuse to attest to the block, it won’t become finalized, and the chain will be reorged. In fact, not only will the nodes refuse to attest to the block, they will not even consider it a valid block. This means that even if two-thirds of the nodes are deceived or malicious, an attacker still cannot mount a DA withholding attack since the honest minority will fork off. Note: if node B responds to enough of the data sampling queries, then the other nodes can effectively recreate the data and it would have been made available, so this “attack” only works on a few nodes.

The other challenge for this specific attack is the P2P Gossip network that underlies the Ethereum network. Nodes aren’t just talking to one other node but rather multiple, so an attacker would have to surround the node it’s attacking on the network to either block communications with other nodes or intercept the data packet responses before they arrive. This is prohibitively hard to pull off but does merit mentioning. Also, this issue does not arise with traditional L1 transactions since all transactions are executed by the nodes, and any block that includes invalid transactions won’t be attested to.

While data-blob is the native Ethereum solution, non-native solutions have been increasingly gaining popularity. Celestia and EigenDA are two prominent solutions currently in the spotlight. As stated on Celestia’s website, “rollups and L2s use Celestia as a network for publishing and making transaction data available for anyone to download.” Similarly, EigenDA is a solution built atop the popular Ethereum restaking protocol Eigenlayer, which launched on main net earlier this month.  

Let’s look further at how both operate, beginning with EigenDA. Fundamentally, EigenDA is an honest majority protocol—the EigenDA nodes check to ensure that the data is available and sign that it is. An L1 smart contract tallies the signatures, and if a supermajority (greater than 66%) attest that the data has been made available, then it is considered available. The reliance on an honest majority—which opens up a more unique avenue of attack—isn’t the only challenge of EigenDA, since the data unavailability is not uniquely attributable. This simply means that you can’t prove that a DA node is not making the data available. While the Eigen-nodes may attest that the data has been made available, nothing prevents a DA node from not answering your query specifically. In this event, there’s nothing you can submit to a slashing contract to prove that the data hasn’t been made available. EigenDA, and other non-native solutions, pawns this off to governance. Since slashing is handled by a governance layer, the only way for a byzantine DA node to be slashed is by a vote from the governance members, which leaves you at the whim of those governance nodes. So theoretically, if a node refuses to make data available, it would be put up to a vote to slash their stake, and if the governance nodes choose, they can collude or exclude individuals at whim. It’s important to note this is not a problem for Ethereum’s native DA, since each L1 node will sample the data and refuse to attest to or even accept the block as valid since they won’t be convinced the data has been made available. 

At first glance, one might wonder why anyone would choose a non-native DA solution. The real benefit of non-native DA solutions is that they are cheaper than L1 DA because the EVM isn’t sampling these off-chain DA solutions. An additional challenge of EigenDA, however, is that the economic security of EigenDA comes from restaked ETH, and in the event of a compromise, the Ethereum validators are incredibly unlikely to fork the entire chain to secure EigenDA (see “Don’t Overload Ethereum’s Consensus” by Vitalik Buterin). 

Furthermore, because Eigenlayer and EigenDA rely on restaked ETH, it is easier for a malicious actor to launch a 51% attack on the network. As of early last month, Eigenlayer’s total-value locked (TVL) is above 14 billion dollars, which represents less than 5% of the total ETH in circulation. An attacker could lock up enough ETH in the Eigenlayer smart contract to gain a majority of the stake. While trying to suddenly acquire 15 billion dollars worth of ETH would undoubtedly drive prices up, Ether’s market capitalization of around 400 billion dollars would soften the price impact. Compared to trying to launch a similar attack on the EVM, assuming a well-enough capitalized malicious actor, any attempt to seize a majority of the stake could drive the price of ETH prohibitively high—many parties may refuse to sell out of principle and such a large action would immediately be cause for caution. And, as we’ve discussed, in the worst-case scenario if the entire network is compromised, the Ethereum foundation in conjunction with the 10 biggest client teams would be able to execute a hard-fork— rewrite the software and reset balances—to save the network. EigenDA can’t rely on that nuclear option—known as social slashing—to save its network.

If we look at Celestia, we see similar problems arise. Take the example of a roll-up using Celestia for DA. The rollup would build a Celestia light client as a smart contract on Ethereum, and if a supermajority of Celestia nodes have attested that the data has been made available, the L2 will consider that correct. But what if the EVM wanted to sample Celestia? It might seem trivial to have the EVM sample the Celestia nodes, but when looking at possible solutions, we see it’s not nearly as simple.

Let’s take the base case—the smart contract uses some form of randomness (let’s assume a random oracle) to produce checks that someone can then do and send over to the smart contract. Here, with the random checks made public, Celestia would know which nodes are Ethereum’s and could easily lie—keep in mind the L1 nodes are on an entirely different network and have no capacity to sample themselves, since they’re not running the Celestia software and plugged into the Celestia network themselves. One may think it’s trivial to restrict who can be a sampler, but then we end up with another trust assumption and arguably a more tenuous one than before.

We could also tell the samplers to go sample, and then Ethereum uses a random oracle to select a subset of samplers at random. Now, Celestia is in a position where it doesn’t know which samples are Ethereum’s since at the time of sampling it hasn’t been decided yet. To understand the challenge, we must look at how sampling works—a reasonable option is that all samplers submit their public keys to the smart contract, a subset is selected at random, and the smart contract checks that the sample is signed by the correct corresponding private key. However, public-private key generation is trivially cheap—your phone can generate 10 billion public-private key pairs without breaking a sweat. And here we have our second problem: nothing prevents Celestia or one malicious actor from signing up for ten million samplers. Even if the honest samplers are 10,000, with overwhelming probability Celestia’s nodes will be chosen. And in this case, the malicious samplers won’t answer the query until the smart contract opens up which queries it is sampling, at which point only those queries will be answered. Since the smart contract is only sampling a subset of the data, answering those queries will not be enough to recreate the data. In fact, this type of attack, called a sybil attack, is the reason that blockchains employ proof-of-work or proof-of-stake schemes. But if we require the samplers to lock up stake in the smart contract, then we have to assume that a majority of the stake is by honest samplers, and we’re back to our honest majority assumption. Even if an attacker doesn’t control the majority of the samplers or the majority of the stake, in the time when the queries are released by the smart contract, nothing prevents a malicious actor from bribing the chosen samplers. 

A reasonable solution to get beyond this bribery issue would be to have the Ethereum smart contract require not only the sample but also the solution to a special type of function called a Verifiable-Delay Function (VDF). A VDF is a type of function that theoretically takes a fixed amount of time to solve regardless of the compute power used—the function is extremely non-parallelizable, so larger compute doesn’t help solve it faster. By sampling and then using that sample in conjunction with the VDF, we could be sure that in the interim period no tampering occurred, since the sampler would be occupied solving the VDF. The tricky thing here is that VDFs are relatively new to the space, and computer scientists are still unsure about how much they can be accelerated. A well-capitalized malicious actor could possibly even build specialized circuits to help speed up the process. In addition, we have to contend with the issue of sybils checking every data point, running the VDF, and then selectively disclosing only the samples requested. This again reverts back to the honest majority assumption.

It seems, that for now at least, we’re stuck with an honest majority assumption for non-native DA solutions.

While we’ve seen that native DA doesn’t rely on an honest majority assumption, there is one scenario where an honest majority assumption is required. Full data blobs are stored only for eighteen days—a time frame deemed long enough for all interested parties to download the data and take appropriate actions, like playing the fault proof game to challenge a malicious sequencer. A node that goes offline, however, and comes back online over eighteen days later, has no choice but to trust the majority of Ethereum that the data was made available, since there is no way for the node to sample the data itself. This is a reasonable assumption, but important to note nonetheless.

There are important tradeoffs and nuance to consider when comparing different DA solutions. Ethereum blobs are more expensive than non-native DA since each L1 node samples the data to ensure it has been made available, and developers will have to conscientiously weigh the pros and cons. Given Ethereum's rollup-centric future, however, it is imperative that we understand how DA works, the various security assumptions, and possible solutions. Stay tuned for more deep-dives and a follow-up about how blockchain solutions should think about the different considerations!