Sign in

Execution Layer Shift

Suggest an edit

Solana is already extremely fast, so block speed is not a reason for choosing L2 over L1.

Unless, of course, the idea is to build a real-time game like Counter-Strike, then it could be justified.

An L2 is just another network with its own operator, often one machine that orders the transactions (called Orderer or Sequencer). It has its own rules for when a transaction is final, usually weaker than Solana's. Because of such architecture, L2s are mostly always “faster” than their master L1 chains. Of course such pros come with some disadvantages: programs on L2 are not able to call programs on Solana directly, moving funds is asymmetrical (withdrawing from L2 is often slower than depositing, because users need to wait until the L2's state can be trusted on Solana), etc.

Instead, the choice of L2 over L1 is justified in case the goal is to build a protocol with less technical constraints than on L1 (for example - the program may need to reference more accounts, or users may need to execute transactions with more instructions than allowed on L1), and at the same time, the block security / finalization trade-off doesn't matter to the project much. If it does, the alternative is to think of possible ways to optimize the program and keep it on L1.

The usual decision protocols make is to split the computation: the part that hits the limit runs on L2, everything else stays on L1 (especially money).

Examples

Zeebit is an on-chain casino. A spin has to feel instant, and a two-step random number on L1 does not. Speed was the only thing missing, so Zeebit did not leave L1. The player deposits into Zeebit's program on Solana, and the money stays there. For one round, only the state of that round is handed to an ephemeral rollup (MagicBlock), where moves are instant. When the round ends, the result is written back to Solana and the payout happens there.

Only the game leaves Solana Two lanes. The top lane is Solana, the bottom lane is an ephemeral rollup. On Solana, the player deposits into the casino's program, and the funds stay there for the whole flow. The game account is delegated to the rollup through the delegation program. On the rollup, the moves of the game happen instantly. When the game ends, its state is committed back to Solana and undelegated, and the payout happens on Solana from the funds that never left. Only the game leaves Solana Solana 1. deposit funds stay here 2. delegate game account only 4. commit final game state 5. payout from the same funds Ephemeral rollup 3. the moves of the game instant, no money here The rollup holds one game for the length of one game. The money never leaves Solana, so leaving the rollup is the normal end of every game.

Zeta went to an L2. Its cross-margin check touches every market a trader holds, and the limit on accounts per transaction capped how many that could be. That is the constraint case: it moved trading to its own L2 (Bullet), kept settlement and data on Solana, and accepted that a withdrawal to L1 takes longer than a trade. Zeebit moved one game at a time and kept the money where it was when Zeta moved the whole exchange and accepted a day-long exit.

Helium tried both ways. It had its own chain and moved onto Solana. A million devices fit as compressed NFTs, and rewards fit as per-device claims instead of daily payouts. What did not fit was reshaped, not moved (about a million hotspots became compressed NFTs, daily payouts became claims that each owner sends when they want the money). That is the default to try first, and a separate layer is what is left when reshaping fails.