Special thanks to Toghrul for reviewing this FAQ.

We've all heard Toly say Solana is an Ethereum L2 via the Wormhole Eigenlayer bridge. But is that really true?

Does the bridge define the rollup? Do rollups even scale the base layer?

Your answers to some of the frequently asked rollup questions:

Rollups are blockchains, separate ones from the base layer on which they are “deployed”. They are businesses that make a deal with the base layer to use the base layer consensus as their default consensus (hence, “merged consensus”).

Since they are separate blockchains they can choose to walk (fork) away from this business deal at any time, and pivot to being a self-sufficient business with an in-house consensus, or even make a business deal with another base layer and borrow their consensus.

Rollups get to reduce their security costs by outsourcing security*, to the parent chain (more on how this works later). They also get to access the liquidity of the base layer in a trust-minimized manner.

*Traditional rollups outsource safety + eventual liveness, and based rollups outsource complete security = safety + real-time liveness

The parent layer, (e.g., Ethereum), gets to scale its native assets. Users can use these assets across the rollup businesses deployed on the parent layer without any additional safety assumptions. The parent layer also charges some rent to provide security to these businesses.

There are 2 steps involved in this deal:

1. Bridge: Building a trust-minimized bridge from the rollup to the parent layer

2. Agreement: A social consensus on the rollup to agree to this deal and outsource security to the parent layer

Together, these 2 steps complete the rollup setup and allow the rollup to outsource consensus (safety & eventual liveness) to the base layer.

Trust-minimized means infinitesimally small trust assumptions over running a full node for the network.

A trust-minimized bridge is nothing but a smart contract on the base layer that maintains a view of the canonical head of the rollup. This bridge contract keeps updating this view with new rollup blocks as they are produced.

It is ‘trust-minimized’ because the bridge relies only on cryptographic/fault proofs to verify the validity of these new blocks. (Note that this is different from ‘trustless’ which would be the guarantees provided by running a rollup full node).

In general, the security of any ‘view’ of any blockchain can be categorized across 5 confirmation rules, as explained by Sreeram in this thread:

https://x.com/sreeramkannan/status/1683735050897207296

1. Ledger Growth

2. Censorship Resistance

3. Data Availability

4. Reorg Resistance

5. Validity

The first two are liveness properties.

Real-time liveness is provided by the rollup itself - either by decentralizing the sequencer or/and having a robust sequencer replacement protocol. Sequencers periodically post new batches of transactions and the updated state root to the base layer. The bridge contract verifies the validity of these transactions and updates its view.

(Note that in based rollups L1 validators are the sequencers so real-time liveness is provided by the base layer as well)

Eventual liveness is provided by forced inclusion mechanisms on the base layer. If the rollup sequencer is inactive for a delayed period or is censoring users, users can send transactions directly to the bridge contract. The bridge verifies these transactions and includes them in its view of the rollup.

The last 3 are safety properties.

Rollup sequencers post all their transaction data to the base layer.

• Since the bridge contract lives on the base layer, it can directly verify that this data is available

• Reorg resistance is provided by the irreversibility of the base layer. On Ethereum, for example, finalized transactions can never be reversed.

• Finally, the bridge contract verifies the STF of the rollup using cryptographic proofs and the posted data.

Combined with the forced inclusion mechanism, the safety properties make the bridge contract view trust-minimized since the only security assumptions added over running a rollup full node are infinitesimally small cryptographic trust assumptions.

By agreeing to the business deal of being a rollup on a base layer, social consensus for rollups decides that the "default setting" for the rollup is to follow the view of the bridge as the canonical state of the rollup.

This social consensus to follow the bridge view is what allows rollup users to “inherit” the safety and eventual liveness guarantees of the base layer.

Rollup users have broadly 2 ways of verifying the rollup STF or accessing the rollup state root:

1. Running a rollup full node: Trustless view of the rollup

2. Relying on the L1 contract: Trust-minimized view of the rollup

BECAUSE the social consensus is to follow the bridge, users can safely assume that the L1 contract view is the canonical view of the rollup.

Imagine if this wasn’t the case:

A rollup builds a 'trust-minimized' bridge to the base layer but relies on the rollup validators for the canonical head of the rollup. The trust-minimized bridge means that the rollup still posts all transaction data to the base layer and the bridge still verifies the cryptographic proofs of STF validity.

Technically, this feels like a rollup.

Say the validators are now censoring a rollup user. Through the trust-minimized bridge, the user would be able to force include this transaction into the base layer. This is because the bridge will consider any directly sent transactions similar to any other transactions sent by the validators and include them in its view of the rollup.

However, the validators would continue censoring that transaction and not include it in their copy of the rollup blockchain.

The validator view of the rollup chain and the view on the parent layer will immediately diverge.

• Base layer funds: The user will be able to escape with any base layer (L1)-issued funds, but that version of the rollup is now old and the rest of the community is following whatever the validators are doing.

• RWAs: The RWA issuers on the rollup chain could use any fork, and will probably want to follow whatever is decided by the social consensus

• L2 native assets: the L2 governance will choose the new fork version of native assets as canonical.

So for both RWAs and L2 native assets, the value eventually goes to zero for the user.

Compare this to rollups where social consensus has agreed to follow the canonical head determined by the bridge:

• All the execution layer clients etc. are all following the bridge.

• This “immediate” divergence because of rollup validator dishonesty/censorship is not possible because everyone follows the bridge, not the copy of the L2 validators.

• Yes, the social consensus of a rollup can agree to fork away as well and either become its own L1 or become a rollup on some other blockchain. But that is completely different from validators randomly censoring a transaction leading to an immediate divergence.

• Prior to any social consensus upgrade, all rollup client teams still follow the state on the base layer bridge while booting up their validator. All asset issuers still consider the bridge contract view as canonical.

Let’s drive this point home through a hyperbolic example.

Take Solana as it is today. Everyone thinks of Solana as a sovereign L1 chain and considers Solana validators as the source of truth for the canonical head. Imagine the validators on Solana are trying to censor me. So I make a trust-minimized bridge from Solana to Ethereum, dumping all Solana data on Ethereum and proving the validity of transactions to the bridge through cryptographic proofs.

Now this bridge technically provides a trust-minimized view into the Solana blockchain and by that logic, Solana should be called a rollup on Ethereum at this point.

However, if a tree fell in a forest and no one heard it, did the tree really fall?

• I’ve told no one else about this bridge so everyone else still considers Solana as the sovereign L1 blockchain.

• If I try to force include my transaction, the view of the bridge will get updated with this transaction, but the Solana L1 will diverge.

• Technically the bridge is still looking at the “L2_Solana” version, but the native assets and the RWAs on that bridge aren’t valuable because everyone else thinks of Solana as the L1 (fork).

It is also not necessary that everyone will agree to follow one specific fork. Some Solana native asset issuers might choose my L2 as the canonical version, while others might choose the L1 fork. Assets will remain valuable on the canonical version chosen by these asset issuers and will lose value on the other fork.

The social consensus to follow the bridge is a crucial prerequisite for trust-minimization. Because the rollup users can send transactions directly to the bridge contract and the contract updates its view with these transactions, this allows the base layer funds to flow to the rollup and back safely, enabling scaling of the base layer assets since the rollup can provide much cheaper transactions.

If the social consensus was to follow the rollup validators instead, then we rely on an honest majority of the validators to include transactions in their fork - this is NOT trust minimization.

This construction is a Sovereign Rollup! The chain relies on an external validity mechanism (its own validators in the Solana example), and not on the smart contract enshrined on the base layer.

All the discussion above was in the context of Smart Contract Rollups - these are all the current rollups deployed on Ethereum - Arbitrum, Optimism, etc.

“Scaling” is a nuanced word that has multiple meanings in the context of blockchains.

1. Scaling base asset: bridging the asset to different chains, CEXs, etc.

2. Scaling the tech: Using base tech in other chains, e.g., Eclipse using SVM scales Solana's tech

3. Scaling L1 compute: Increasing throughput for faster/cheaper transactions on L1

Rollups specifically allow the base layer assets to access additional compute resources without additional safety assumptions. As we learned, the minimum requirements for this are a trust-minimized bridge - that allows funds to flow safely from the base layer to the rollup, and social consensus to follow that bridge as the canonical view of the rollup.

Smart Contract L2s

• Rollups: Scale the base layer assets in a trust-minimized manner

• Validiums: Scale the base layer assets but with additional trust assumptions (since there is no trust-minimized bridge). The base layer needs to trust the external DA source (the bridge contract only verifies the attestation that data is available)

• Volitions: Can scale the base layer assets in a trust-minimized manner iff there’s a trust-minimized bridge from the base layer to the rollup. In this construction, the data of base layer <> rollup transfers would be published on the base layer.

Sovereign L2s

• Rollups: can scale the base assets but add an honest majority assumption on the rollup’s external source of truth. Not trust minimized.

Absolutely*.

(*if Solana's social consensus agrees)

Solana can build a trust-minimized bridge to Ethereum, and have all clients, asset issuers, etc. agree that the Ethereum L1 bridge defines the canonical head of the Solana chain, and the existing consensus is either booted out or used only for sequencing the Solana transactions, and voila, we have Solana as an Ethereum rollup.

If we just build a trust-minimized bridge and don’t get the social consensus to consider this as the canonical view of the chain, then this version of Solana would be a sovereign rollup, not a smart contract rollup that scales Ethereum in a trust-minimized manner.

Special thanks to Toghrul for reviewing this FAQ.

We've all heard Toly say Solana is an Ethereum L2 via the Wormhole Eigenlayer bridge. But is that really true?

Does the bridge define the rollup? Do rollups even scale the base layer?

Your answers to some of the frequently asked rollup questions:

Rollups are blockchains, separate ones from the base layer on which they are “deployed”. They are businesses that make a deal with the base layer to use the base layer consensus as their default consensus (hence, “merged consensus”).

Since they are separate blockchains they can choose to walk (fork) away from this business deal at any time, and pivot to being a self-sufficient business with an in-house consensus, or even make a business deal with another base layer and borrow their consensus.

Rollups get to reduce their security costs by outsourcing security*, to the parent chain (more on how this works later). They also get to access the liquidity of the base layer in a trust-minimized manner.

*Traditional rollups outsource safety + eventual liveness, and based rollups outsource complete security = safety + real-time liveness

The parent layer, (e.g., Ethereum), gets to scale its native assets. Users can use these assets across the rollup businesses deployed on the parent layer without any additional safety assumptions. The parent layer also charges some rent to provide security to these businesses.

There are 2 steps involved in this deal:

1. Bridge: Building a trust-minimized bridge from the rollup to the parent layer

2. Agreement: A social consensus on the rollup to agree to this deal and outsource security to the parent layer

Together, these 2 steps complete the rollup setup and allow the rollup to outsource consensus (safety & eventual liveness) to the base layer.

Trust-minimized means infinitesimally small trust assumptions over running a full node for the network.

A trust-minimized bridge is nothing but a smart contract on the base layer that maintains a view of the canonical head of the rollup. This bridge contract keeps updating this view with new rollup blocks as they are produced.

It is ‘trust-minimized’ because the bridge relies only on cryptographic/fault proofs to verify the validity of these new blocks. (Note that this is different from ‘trustless’ which would be the guarantees provided by running a rollup full node).

In general, the security of any ‘view’ of any blockchain can be categorized across 5 confirmation rules, as explained by Sreeram in this thread:

https://x.com/sreeramkannan/status/1683735050897207296

1. Ledger Growth

2. Censorship Resistance

3. Data Availability

4. Reorg Resistance

5. Validity

The first two are liveness properties.

Real-time liveness is provided by the rollup itself - either by decentralizing the sequencer or/and having a robust sequencer replacement protocol. Sequencers periodically post new batches of transactions and the updated state root to the base layer. The bridge contract verifies the validity of these transactions and updates its view.

(Note that in based rollups L1 validators are the sequencers so real-time liveness is provided by the base layer as well)

Eventual liveness is provided by forced inclusion mechanisms on the base layer. If the rollup sequencer is inactive for a delayed period or is censoring users, users can send transactions directly to the bridge contract. The bridge verifies these transactions and includes them in its view of the rollup.

The last 3 are safety properties.

Rollup sequencers post all their transaction data to the base layer.

• Since the bridge contract lives on the base layer, it can directly verify that this data is available

• Reorg resistance is provided by the irreversibility of the base layer. On Ethereum, for example, finalized transactions can never be reversed.

• Finally, the bridge contract verifies the STF of the rollup using cryptographic proofs and the posted data.

Combined with the forced inclusion mechanism, the safety properties make the bridge contract view trust-minimized since the only security assumptions added over running a rollup full node are infinitesimally small cryptographic trust assumptions.

By agreeing to the business deal of being a rollup on a base layer, social consensus for rollups decides that the "default setting" for the rollup is to follow the view of the bridge as the canonical state of the rollup.

This social consensus to follow the bridge view is what allows rollup users to “inherit” the safety and eventual liveness guarantees of the base layer.

Rollup users have broadly 2 ways of verifying the rollup STF or accessing the rollup state root:

1. Running a rollup full node: Trustless view of the rollup

2. Relying on the L1 contract: Trust-minimized view of the rollup

BECAUSE the social consensus is to follow the bridge, users can safely assume that the L1 contract view is the canonical view of the rollup.

Imagine if this wasn’t the case:

A rollup builds a 'trust-minimized' bridge to the base layer but relies on the rollup validators for the canonical head of the rollup. The trust-minimized bridge means that the rollup still posts all transaction data to the base layer and the bridge still verifies the cryptographic proofs of STF validity.

Technically, this feels like a rollup.

Say the validators are now censoring a rollup user. Through the trust-minimized bridge, the user would be able to force include this transaction into the base layer. This is because the bridge will consider any directly sent transactions similar to any other transactions sent by the validators and include them in its view of the rollup.

However, the validators would continue censoring that transaction and not include it in their copy of the rollup blockchain.

The validator view of the rollup chain and the view on the parent layer will immediately diverge.

• Base layer funds: The user will be able to escape with any base layer (L1)-issued funds, but that version of the rollup is now old and the rest of the community is following whatever the validators are doing.

• RWAs: The RWA issuers on the rollup chain could use any fork, and will probably want to follow whatever is decided by the social consensus

• L2 native assets: the L2 governance will choose the new fork version of native assets as canonical.

So for both RWAs and L2 native assets, the value eventually goes to zero for the user.

Compare this to rollups where social consensus has agreed to follow the canonical head determined by the bridge:

• All the execution layer clients etc. are all following the bridge.

• This “immediate” divergence because of rollup validator dishonesty/censorship is not possible because everyone follows the bridge, not the copy of the L2 validators.

• Yes, the social consensus of a rollup can agree to fork away as well and either become its own L1 or become a rollup on some other blockchain. But that is completely different from validators randomly censoring a transaction leading to an immediate divergence.

• Prior to any social consensus upgrade, all rollup client teams still follow the state on the base layer bridge while booting up their validator. All asset issuers still consider the bridge contract view as canonical.

Let’s drive this point home through a hyperbolic example.

Take Solana as it is today. Everyone thinks of Solana as a sovereign L1 chain and considers Solana validators as the source of truth for the canonical head. Imagine the validators on Solana are trying to censor me. So I make a trust-minimized bridge from Solana to Ethereum, dumping all Solana data on Ethereum and proving the validity of transactions to the bridge through cryptographic proofs.

Now this bridge technically provides a trust-minimized view into the Solana blockchain and by that logic, Solana should be called a rollup on Ethereum at this point.

However, if a tree fell in a forest and no one heard it, did the tree really fall?

• I’ve told no one else about this bridge so everyone else still considers Solana as the sovereign L1 blockchain.

• If I try to force include my transaction, the view of the bridge will get updated with this transaction, but the Solana L1 will diverge.

• Technically the bridge is still looking at the “L2_Solana” version, but the native assets and the RWAs on that bridge aren’t valuable because everyone else thinks of Solana as the L1 (fork).

It is also not necessary that everyone will agree to follow one specific fork. Some Solana native asset issuers might choose my L2 as the canonical version, while others might choose the L1 fork. Assets will remain valuable on the canonical version chosen by these asset issuers and will lose value on the other fork.

The social consensus to follow the bridge is a crucial prerequisite for trust-minimization. Because the rollup users can send transactions directly to the bridge contract and the contract updates its view with these transactions, this allows the base layer funds to flow to the rollup and back safely, enabling scaling of the base layer assets since the rollup can provide much cheaper transactions.

If the social consensus was to follow the rollup validators instead, then we rely on an honest majority of the validators to include transactions in their fork - this is NOT trust minimization.

This construction is a Sovereign Rollup! The chain relies on an external validity mechanism (its own validators in the Solana example), and not on the smart contract enshrined on the base layer.

All the discussion above was in the context of Smart Contract Rollups - these are all the current rollups deployed on Ethereum - Arbitrum, Optimism, etc.

“Scaling” is a nuanced word that has multiple meanings in the context of blockchains.

1. Scaling base asset: bridging the asset to different chains, CEXs, etc.

2. Scaling the tech: Using base tech in other chains, e.g., Eclipse using SVM scales Solana's tech

3. Scaling L1 compute: Increasing throughput for faster/cheaper transactions on L1

Rollups specifically allow the base layer assets to access additional compute resources without additional safety assumptions. As we learned, the minimum requirements for this are a trust-minimized bridge - that allows funds to flow safely from the base layer to the rollup, and social consensus to follow that bridge as the canonical view of the rollup.

Smart Contract L2s

• Rollups: Scale the base layer assets in a trust-minimized manner

• Validiums: Scale the base layer assets but with additional trust assumptions (since there is no trust-minimized bridge). The base layer needs to trust the external DA source (the bridge contract only verifies the attestation that data is available)

• Volitions: Can scale the base layer assets in a trust-minimized manner iff there’s a trust-minimized bridge from the base layer to the rollup. In this construction, the data of base layer <> rollup transfers would be published on the base layer.

Sovereign L2s

• Rollups: can scale the base assets but add an honest majority assumption on the rollup’s external source of truth. Not trust minimized.

Absolutely*.

(*if Solana's social consensus agrees)

Solana can build a trust-minimized bridge to Ethereum, and have all clients, asset issuers, etc. agree that the Ethereum L1 bridge defines the canonical head of the Solana chain, and the existing consensus is either booted out or used only for sequencing the Solana transactions, and voila, we have Solana as an Ethereum rollup.

If we just build a trust-minimized bridge and don’t get the social consensus to consider this as the canonical view of the chain, then this version of Solana would be a sovereign rollup, not a smart contract rollup that scales Ethereum in a trust-minimized manner.