# What does blockchain infrastructure mean?
At Archetype, the first question we ask ourselves when evaluating a potential new investment into a crypto project is where that project is situated within the blockchain infrastructure stack. This stack comprises all of the components underlying your favorite dApps.

We have a shared belief in how the infrastructure stack will evolve over time and where value should accrue within the stack. The goal of this article is to share this mental model and explain each of its components.

The technical stack has evolved a lot since 2017 when there were isolated blockchains connected primarily through centralized exchange hubs.


Blockchain infrastructure in 2023 is characterized by:
- Layer 2 ("L2") blockchains that derive their security from Layer 1 ("L1") blockchains and offer a very fast and cheap user experience
- most new user-facing applications deployed on L2's rather than L1's
- "Fast Bridges" that offer communication between L2 apps.

There are essentially many more blockchain networks today that are connected to most of the other networks, which is a big step from the state of blockchain infrastructure five years ago where there were a handful of blockchains that were only connected by CEX's. The decentralized web has definitively become more decentralized.

The number of connections between blockchains has created a lot more obscurity for people who want to understand better how it all works. How do my tokens transfer from L2 to L2? Who is securing my data and who am I implicitly trusting to keep my data safe? To answer these questions, we need to understand the blockchain stack at a high level. Here's where we're going:


With a shared model for the blockchain stack we can more easily understand how L2 and Bridge security works and also see where value and revenue should accrue.

# Structure of this Article

This article can be read like a normal article and by the end of it you should have a full understanding of blockchain infrastructure in 2023, or you can read it as a set of FAQ's and jump directly to the questions that you have.

Roughly, the order of contents is:
- Explaining how an L2 blockchain can be so fast and cheap and how it is secured
- The relationship between L2 and Ethereum (L1)
- The relationship between L2's and Data Availability (DA) layers
- Sequencers
- Shared Sequencers
- Fraud proofs, validity proofs, and proof of authority
- Bridges
- Sequencers versus bridges
- Types of bridges
- Intent-based Architecture and its relationship to Arbitrary Message Bridges

## The User journey begins at the dApp

Users interact with dApps. Today most of those dApps are deployed on L2's like Polygon, Arbitrum, and Optimism. Users demand that those dApps are fast and cheap, which is why these dApps are deployed on L2s and not on Ethereum.

### What makes an L2 different from an L1?

L2s process transactions off-chain and periodically publish batches of finalized transactions to some data storage layer. The reason why L2s can be so fast is that they are recording user interactions off-chain on a private server as opposed to recording user interactions on a blockchain. Blockchains are inherently slower than private databases.

### How does the L2 choose which data storage layer to publish transaction history to?

This is the most important choice for an L2 to determine its security level. If an L2 is an "Ethereum Rollup", then it chooses to publish its list of transactions to Ethereum. The reason to choose Ethereum is that it is the "most immutable" blockchain; it is the most difficult network to try to overwrite already published data. So, L2s can publish their state to Ethereum and have a very high degree of confidence (following Ethereum's [finality](https://hackmd.io/@prysmaticlabs/finality) period of ~13 minutes or 2 epochs of 32 slots taking 12 seconds each) that whatever they published will not disappear. This also should give users a high degree of confidence that once the L2 publishes its state to Ethereum and includes their transaction, that their transaction will not be reverted.

Its important to note that using Ethereum as a data storage layer is notoriously expensive. This is because Ethereum offers the highest security of any potential data storage layer and wasn't optimized to just store data. Ethereum has the dual goal of offering a generalized computing machine and until [EIP4844](https://www.eip4844.com/) is implemented, there isn't a way to request blockspace-only and not have to pay the same gas as everyone else trying to send normal transactions on Ethereum. So if an L2 chooses to publish state on Ethereum its picking the blue chip option but its paying for the luxury of top security.

What options are available to an L2 that wants to pay less to store state? This is where "Data Availability" (DA) layers like Celestia enter into the story. DA layers are optimized to only offer a place for users to store data and they see a lot less traffic than Ethereum, so demand for block space is not only less on non-Ethereum DA layers but the block space itself is priced cheaper. The downside is naturally that these DA layers are relative upstarts and less secure than Ethereum. So when sending a transaction on an L2, you should be asking: which DA layer does this L2 publish its state to and do I trust it?


### Why do L2's pay to store data?

Why incur this cost at all to store state on an external DA layer? The answer is that it offers certain assurances to users and its a requirement for an L2 to remove its centralization vector. Like Ethereum, an L2 is in charge of storing a canonical history of transactions. Users don't want to see their transactions reversed or modified and they don't want to see their wallet balances suddenly drop. If a user is interacting with a blockchain, then they want to know that they have control over their own data.

If an L2 never published its state publicly, then it would just be a private server. Users would be at the complete mercy of the L2 operator. They would also need to assume that the L2 operator never went offline.

If the L2 publishes its state to a chain that was relatively insecure, then the users would be at the mercy of that chain. For example, if L2's posted their history snapshots to Tron, then Justin Sun would have the ability to change the L2's history.

This is why most L2's pick highly secure and proven chains like Ethereum to publish their state.

So a key point worth repeating: An L2 is only as secure as the L1 that it publishes state to.

*If an L2 publishes its state/ "rolls down" to a DA layer then it is secured by that DA layer. It is not an "Ethereum Rollup", instead it it is essentially a side chain, or an Alt L1*

However, we need to distinguish between data availablity and data validity.

### Does that mean that DA layers are competitive with Ethereum?

They compete for storing blobs of data; post EIP4844 these DA layers will compete directly with the Ethereum "Blob" market.

For other types of transactions like sending tokens or interacting with DeFi apps, Ethereum competes with other turing-complete blockchains like Solana, BSC, and Avalanche that don't publish their state to Ethereum.

### Does that mean that a rollup that uses a non-Ethereum DA layer is an "Alt L1"?

Yeah basically. The rollup+non-Ethereum-DA stack is equivalent to Solana, BSC, and Avalanche, for example.

## Who are Sequencers?

Who actually publishes L2 state to DA layers?

These actors are usually called "Sequencers". Sequencers are in charge of deciding on a canonical history of transactions that took place on an L2 and publishing snapshots of that history to a DA layer. Sequencers pay the DA layer fees to store the data, and they earn revenue by collecting all fees paid by users who send transactions on the L2s.

Sequencers can be single, whitelisted parties, or they can be a competitive market of sequencers vying to publish the next set of L2 state to L1.

### What does it take to run a sequencer?

A sequencer needs to be aware of state on the DA layer so that it can publish data to it and also state on the L2 layer so that it can sequence L2 transactions.

### What is a "Shared Sequencer"

A shared sequencer is a sequencer that sequences L2 data for multiple L2s. This type of sequencer will typically publish all the L2 data that it sequences to the same L1. Shared sequencers are economically viable insofar as there are multiple L2's that have similar mechanisms for processing transactions and that desire to (and can) publish their state to the same DA layer. The Shared Sequencer can therefore leverage a single technology stack to interpret transactions on multiple L2s and publish them to a single L1.

Shared sequencing would not exist in a world where each L2 wanted to publish its state to a different L1 or where each L2 processed transactions very differently. This is why shared sequencing neccessarily followed the phenomenon where Ethereum gained a critical amount of marketshare in the blockspace industry. This caused many of its competitors to decide to evolve into L2's that used Ethereum as their DA layer, because Ethereum's security was so much higher than their own.

In addition to Ethereum cornering the blockspace market, the second catalyst for shared sequencing was the open source [rollup infrastructure offered by Optimism labs](https://stack.optimism.io/#the-op-stack-powers-optimism) which made it easy to deploy a new L2. These L2's can be easily sequenced by the same sequencer because they're all running the same software.

*The "Eth-centric" roadmap emerged in '21-22 where by new blockchains preferred to publish state to Ethereum instead of competing for its blockspace*

#### Challenges of Shared Sequencing

Shared sequencing allows transactions from multiple L2s to have a canonical, cross-chain ordering. However, these transactions cannot be conditional upon each other until they are confirmed. If the L2 transactions are all validated by a fraud proof mechanism, then they are not "confirmed" until the fraud challenge window has passed (e.g. 7 days).

Cross-chain conditional transactions are clearly a feature that users will demand (i.e. user wants to send tokens from Optimism to Arbitrum and then swap 100% of those tokens into this other token on Arbitrum, but user doesn't want only one half of this order to succeed). This conditionality feature will require a system contract on each of these L2s that want to participate that allows the sequencer to store other L2 state on it. The shared sequencer will also have to tweak its behavior and more tightly couple the L2 state that it publishes to L1. No longer will the L2 state from each L2 be independent of the other L2s. This creates a concept of "shared fraud proofs", whereby a shared sequencer post state to L1 from multiple L2s in the same transaction and if any of the L2 states are invalid, then a shared fraud proof can be submitted.

[This is an interesting proposal](https://www.umbraresearch.xyz/writings/shared-validity-sequencing) introducing the concept of "shared fraud proofs".

*Prediction: If shared sequencing becomes the dominant paradigm over single sequencing, then state validity between L2s using a shared sequencer will be interdependent*

### How do we know that the L2 published the correct L2 transaction history to the DA layer

We've established that an L2 should post its data somewhere transparent that users can verify for themselves and reference if they ever run into disputes. But, how can users trust that what the L2 is posting to the DA layer is an accurate representation of the L2 state?

If whatever the L2 sequencer publishes to L1 is considered valid L2 history, then what prevents the L2 sequencer from posting an incorrect snapshot of the L2 history? Couldn't the sequencer pay themselves a little bit extra ETH out of user wallets?

Users demand assurance not only that the L2 state is published periodically to an immutable ledger, but also that the L2 state is a valid snapshot of the L2 transaction history at the time.

#### Fraud Proofs vs Validity Proofs vs Proof of Authority

In Optimistic Rollups, the L2 state is published optimistically and is not considered valid history until it passes through a challenge window (e.g. a 7 day challenge window). In this challenge window, anyone can dispute an L2 state commitment if they believe that the commitment is missing the correct transaction history. To submit a dispute, one must publish a "fraud proof" that needs to be used in an interactive process to resolve the dispute.

The main advantage of fraud proofs is that they only need to be created whenever something breaks down and an invalid L2 state is published. This will incur signficantly lower costs over the long run versus validity proofs.

Validity proofs are the other way to validate whatever L2 state is published to L1. A validity proof claims that the L2 state is valid and proves it at the time of publishing. There is no dispute window; if the proof is verified by an L1 contract designedto verify such proofs, then the L2 state is valid.

Since validity proofs need to be generated and proved each time an L2 publishes state, it is clear that they are much more expensive than fraud proof systems.

The main advantage of proving L2 state via validity proofs is that the L2 state published to L1 can be immediately finalized. This means that L1 contracts can take the L2 state as "final" and act upon it. This is why L2 to L1 withdrawals for ZK Rollups are very fast (~24 hours), compared to the seven day challenge window for ORUs.

The last way of validating L2 state is proof of authority. This is when the sequencer publishing the L2 state claims: this is valid because I am publishing it. This is in practice how many rollups work today. There are no challenge windows, there are no proofs. Users are trusting sequencers not to modify the L2 state.

### How do Fraud and Validity proofs work?

These are very hard to implement and expensive to verify. They essentially require simulating the L2 VM execution for a set of alleged L2 transactions and an initial state. If the resultant state that is produced following those alleged transactions on the initial state differs from what the sequencer published to L1, then the sequencer's state is disputable.

These proofs must be verified on the same network that the L2 state is published to, the Data Availability layer, which makes their verification expensive to run.

The main tradeoff between fraud and validity proofs boil down to:
- cost to validate proof: validity proofs are much more expensive, while fraud proofs are cheap
- time to validate proof: fraud proofs are cheap in part because they are interactive between disputer and defendant, so the actual on-chain cost is kept low but it requires that both parties stay online. Validity proofs are verified in a single transaction.
- implementation complexity: both types of proof verification contracts are very hard to to build. Validity proofs rely more on the succinctness property of cryptographic tools so that they can simulate L2 state in a single transaction. Fraud proofs are interactive and therefore require fewer cryptographic tools but more off-chain infrastructure needed to support an interactive proving system.
- L2 VM implementation complexity: L2 state that is validated via validity proofs usually requires a modification to the EVM in order to make the validity proof verification cheaper. L2 state validated by fraud proofs can more easily mirror the EVM exactly.
- running cost for sequencer: validity proofs require the sequencer to pay for each submission to L1 while fraud proofs only impose costs when fraud is detected
- upper limit on funds at risk: if a fraudulent sequencer is not disputed, all L2 funds are at risk. If a sequencer cannot submit a valid validity proof, then the L2 state is effectively frozen but no funds are lost.
- operating cost for validators: in a fraud proof system, there should always be at least one honest validator watching the sequencer's submissions. In a validity proof system, there is no need for external validators assuming the validity proof is submitted

There is a lot more to dive into on this topic. We find these resources particularly helpful:
- https://medium.com/starkware/validity-proofs-vs-fraud-proofs-strike-back-4d0bf90eed15
- https://medium.com/infinitism/optimistic-time-travel-6680567f1864

## Sequencers versus Bridges

Users often demand to move funds between different layer 2's. The safest albeit slowest way to do this is to withdraw via the L2's canonical token bridge to the L1 and then deposit from L1 to another L2 via that second L2's canonical token bridge.

A "canonical token bridge" is essentially just working directly with the sequencer to transfer capital. Depositing to an L2 via the canonical token bridge is locking up funds on a contract on L1 and requesting that the L2 sequencer mint it an equivalent amount of funds on the L2. Withdrawing from an L2 is destroying funds on an L2 and waiting for the L1 to publish proof of this burn to L1, and once that proof is confirmed an L1 contract can release tokens to the user.

However this is a slow process as its usually a slow time to withdraw from an L2 to L1.

A faster way is to go through a "fast bridge". A fast bridge temporarily custodies your information or capital and then credits it to you on the destination chain. This means that the user is temporarily placing trust in the fast bridge to not modify its information or steal it funds.

*How fast bridges work:*

participant Canonical Origin Bridge
participant User on Origin
participant Bridge
participant User on Destination
Note left of Bridge: Origin chain
Note right of Bridge: Destination Chain
User on Origin->Bridge: 10 ETH
Bridge-->Canonical Origin Bridge: 10 ETH
Note over Bridge,User on Destination: Wait for Origin finality period
Bridge->>User on Destination: 9.9 ETH
User on Destination ->Bridge: Looks good, thanks!
Note over Bridge,Canonical Origin Bridge: 7 days later
Canonical Origin Bridge-->Bridge: 10 ETH

Fast bridges credit users their bridged amount minus fees on a desired destination chain, and then wait for the deposit to bridge via the canonical bridge. Once the canonical bridge withdrawal hits the bridge, it has ended up with a fee surplus. In exchange for getting paid for this service, the bridge assumes the finality risk of the user deposit. If the user deposit is reverted by the origin chain's sequencer but the bridge has already credited user funds on the destination chain, the bridge loses these funds.

### Are Fast Bridges safe?
How can users assure themselves that if they deposit 10 ETH on the origin chain that they'll receive 10 ETH on the destination chain minus an appropriate amount of fees? This boils down to the Bridge's security mechanism, which we'll see looks eerily similarto a Sequencer's security mechanism.

When the bridge credits the funds to the user on the destination chain, the user needs a way to verify that the bridged funds were correctly received and ideally the bridge offers a recourse option in the case of an error. One way the bridge can offer this assurance is to allow the user to challenge the bridge in a challenge window. Much like the fraud proof process, this allows users to take their security into their own hands and bring proof of fraud in the worst case that they never received their funds as expected.

#### When a user challenges a bridge, what are they challenging?

This is why its important that the bridge publish its transaction history to an immutable DA layer. This is to offer transparency to users and assure them that if they do ever challenge the bridge, that the bridge cannot modify its history.

So it should be apparent now that both fast bridges and sequencers require DA layers in order to give users confidence that they are processing transactions honestly.


*A bridge is only as secure as the DA layer that it posts state to and its dispute mechanism*
*Can you spot Multichain in this picture?*

### Are there other ways for bridges to offer security assurances to their users?

Bridges can also offer validity proofs. These types of bridges are called "ZK Bridges". ZK bridges publish messages to the destination chain and accompany them with something called a "validity proof". The destination chain requires a contract to be deployed that can simulate the origin chain's virtual machine and can verify that something happened as claimed on the origin chain. The validity proof is used as input into this verification contract to prove to the contract that the message sent to the destination chain is an accurate representation of the request sent on the origin chain.

Of course, bridges can also use proof of authority if they don't want to publish their data anywhere transparently and immutably.

## What is the relationship between Token Bridges and Message Bridges

A message bridge is a protocol that keeps track of cross-chain state. This state can be arbitrary and can include token transfers, data storage, and anything else that the message bridge is able to categorize and store. It fundamentally orders history on one chain relative to history on another chain. Therefore, the message bridge requires a universal language that can be used to identify transactions on all chains it supports. This complexity of defining a shared language is why message bridges might narrow their scope and be "EVM message bridges" where they only store trnasactions for chains that implement the Ethereum Virtual Machine. Any chain that implements the EVM processes transactions that roughly look the same so they are easy to store together.

As an example, a fast message bridge makes claims like: transaction A happened on Optimism before transaction B on Arbitrum.

A token bridge is therefore an application of a message bridge that uses the cross-chain state to "transfer" capital between chains. For example, if it sees that transaction A, a 10 ETH "burn" has happened on Optimism, then it instructs a contract on Arbitrum to release 10 ETH to the user. If the 10 ETH burn gets wiped from history, then the token bridge is likely held liable for this loss. A token bridge is built on top of a message bridge because it needs to be aware of the state onboth origin and destination chain and also needs to know when transactions get finalized on the origin chain before it acts on the destination chain.

## Where do Intents fit in?

An intent is a set of preferences that the user wants fulfilled including the destination chain(s) that it wants those preferences fulfilled.

A marketplace for intents offers to store a canonical history of intents across one or more chains. An intent marketplace allows users to signal their preferences, relayers to fulfill those preferences, and offers validation for the fulfillment of those preferences. If a user feels that a relayer did not correctly fulfill their intent, then the intent marketplace should offer a way for the user to dispute or challenge the relayer. *This is starting to sound a lot like a bridge.*

Intents are innovative because they are described in a different language than the blockchain language typically used to send intructions. They're essentially meant to be described in a more user-friendly language, but the end result should still be a blockchain transaction affecting the user. Therefore, intent-based architecture must define a universal language that can be understood by all applications using the same market. An intent market does not have to be cross-chain but its naturally well-positioned to be because its already solving the hard problems of defining a new language expressing preferences and storing a canonical history of intents.

Cross-chain intent marketplaces are therefore a more specific form of general message bridging. *Arbitrary Message Bridging (AMB's) may have died so that Intents could fly.*

*SUAVE is one example of an intents marketplace: https://writings.flashbots.net/the-future-of-mev-is-suave/#iv-suave-in-the-blockchain-stack*

## Where do Centralized Exchanges and DEX's fit in?

Centralized Exchanges function like both Apps and Token bridges. You can use them as a way to transfer tokens from one network to another. The exchange offers little recoure for users in the case that it steals your funds. The main recourse is to challenge the CEX legally, in person. good luck have fun. CEX's are Proof of Authority bridges.

DEX's that exist on a single chain are dApps. Cross-chain DEX's are token bridges plus dApps.

# Conclusion

## Where does value accrue? And who earns revenue?

Let's revisit the full diagram of the model that we've built:

*Where do you see fat protocols on here?*

### General observations:
- Users interacting on L2s pay L2 sequencers.
- Users looking to jump across chains pay Fast Bridges (and L2 sequencers)
- Bridges pay sequencers on the destination chain to carry out bridge activity
- L2 sequencers pay DA layers to store data. The more L2 activity, the more they pay DA layers.
- Shared sequencers get first stab at extracting MEV between L2s that they sequence. Shared sequencers also get paid by multiple L2s and can reduce their costs by publishing both of the L2 states in a single, batched transaction to the DA layer

#### If you subscribe to fat protocol or aggregation theory, then you might want to start at the top:
- Which L2 is the App deployed on? +1 for the app.
- Which L2 does the app interact with? +1 for that sequencer. +1 if that sequencer could be a shared sequencer and can extract cross-chain MEV.
- Which DA layer does the L2 use? +1 for that DA layer
- If the user interacts with a bridge, which DA layer does the bridge use? +1 for that DA layer

## Closing comments

- Bridges and Sequencers that are serious about their security commitments to users must publish data to a DA layer
- Sequencers, Bridges, and Cross-Chain Intent marketplaces will have similar software stacks because they require the same things: posting data to a transparent and immutable DA layer, offering validity or fraud proof mechanisms for the data they post, software to parse transactions from multiple chains and order them canonically.
- "Alt L1's" and "Sidechains" have not disappeared, they are just disguised as "Data Availability" networks.
- If you want to understand a bridge's security, understand where and how it posts its data (i.e. optimistically and disputable via fraud proof, or accompanied with validity proof).