L1 vs. L2 Nodes: What’s Different for Node Operators?

At first glance, blockchain nodes can appear to be a commodity service, where you simply work with the cheapest provider whose uptime is sufficient for your needs. However, this isn't true when we factor in L2s, which require specialized tooling and tactics to manage that can vary greatly by chain. Given that, plus the fact that the L2 landscape is quickly growing and changing, expertise is important when selecting an L2 node operator. We know this first-hand at Conduit as the primary node provider for every rollup we power, plus a few others.

There are three primary differences between L1s and L2s that impact node operation:

1. L2 blockchains vary much more in performance and configuration, creating different requirements for node operators
2. L2 nodes take a more active role in shaping activity on the blockchain, which can make node operations more complex
3. Hard forks are more complicated

We’ll look more closely at these three differences below to show you why L2 node operations are so much different – and often more difficult – than on L1.

Greater variability in performance and configuration

L1s like Ethereum have pre-set requirements for node operators that change relatively infrequently, and are intended to be accessible by a wide range of participants in order to maintain decentralization. L2s have no such mandate. They’re built to the unique requirements of the chain operator – often ultra high performance (which makes sense given their high-level role is to scale Ethereum activity) or for specific use cases that necessitate specialized nodes.

Let’s start with the performance side of things. Ethereum L1 currently has a gas limit of 36M per block. With block times of 12.5 seconds, that makes Ethereum’s maximum gas usage about 2.9 Mgas/s. And, because the gas limit is kept purposely low, gas usage rarely spikes to levels that overwhelm node operators (instead, the gas price simply increases for end users). 

L2 blockchains, on the other hand, can process 100-200 Mgas/s in throughput, which can stress hardware resources, and translates to a lot more transactions and data being processed. Spikes also tend to be more extreme. Rollups also need to communicate with the L1 to maintain functionality (i.e. L1-L2 communication and bridging). This includes nodes periodically sending batches of transaction data to the underlying L1 for archival and validation purposes, adding more computational and operational complexity. 

Overall, this means L1s and L2s have much different hardware and software requirements.

Higher performance and more activity also means L2 nodes need to store and access more transaction data, which means they need better-optimized databases and more robust caching.

The differences go beyond blockchain performance though. There are other differences in L2 configurations that change node operator requirements. For example:

• ZK rollup nodes must create cryptographic proofs of the validity of each batch of transactions posted to the L1. This is a huge computational task and often requires GPU hardware.
• Many differentiating features that rollup frameworks offer add new requirements for the nodes. For instance, Arbitrum Stylus allows developers to write smart contracts in WASM languages – nodes need special software to read and execute those contracts’ functions. Many chain operators also customize their rollup and add their own precompiles that run natively, instead of in the EVM.
• Interoperability capabilities usually necessitate new node components, such as batchers or proposers to post data back to the L1, and state proof verifiers to validate rollup chain data.

Finally, L2s have unique challenges around reliability and uptime because the role of the sequencer is given to one designated node, rather than distributed across many nodes. That’s why failover setups like high-availability sequencers are so important. L2 node operators also need mechanisms for forced inclusion – meaning, forcing the L2 to record transactions via the L1 – for emergency situations where the sequencer isn’t producing new blocks for a prolonged period of time. 

L2 nodes actively shape user experience

L2 nodes, and in particular sequencer, have a more hands-on role in shaping what happens onchain, and can mold this to improve user experience. Most of this comes down to transaction ordering.

On Ethereum L1, transaction order is decided by global consensus among the many independent validators – this is necessary for decentralization. While individual users pursuing MEV strategies can pay more to validators to place their individual transactions more advantageously, validators can’t work together to order transactions for chain-wide UX improvement.

On L2s, however, the sequencer node is solely responsible for transaction ordering. Chain operators can use the sequencer’s role to implement UX improvements – a key way they differentiate to users or run complex applications onchain. However, these improvements require specific tools and tactics. For example:

• Transaction bundling. L2s can group multiple transactions into a single user action, decreasing the friction of using an onchain app. But doing this requires a special bundler node to actually do the grouping.
• Gas sponsorship. L2s can implement gas sponsorship, allowing the chain operator or app developers to pay users’ gas in specific situations. However, this requires a specialized paymaster smart contract that the sequencer must interact with.
• MEV management. Tools like Flashbots’ Rollup-Boost outsource block building to TEEs, which gives rollups more granular control over transaction ordering, allowing them to control MEV. However, implementing this means transferring mempool access from the sequencer to the TEE.

Rollups frequently differentiate themselves on their ability to provide a better onchain UX, and doing so requires nodes to do things they don’t do on L1.

Hard fork difficulties

Network upgrades (hard forks) are essential for blockchain progress. But the process of implementing them on L2s is different from on L1s, and can add new complexities and workflows for node operators.

L1 hard forks require a great deal of coordination between many parties over a long period of time. But from the node operators’ perspective, they’re simple: Upgrade your node software before the hard fork date. 

On L2s, the process is more complicated. Individual node operators need to work directly with the core rollup framework teams to test potential upgrades and ensure they can meet the framework’s upgrade timelines. The node operators also have to work with the different rollup operators using the framework being upgraded to socialize these changes and collect feedback. This is more complex, as there are more edge cases from all the different configurations and customizations available to rollups.

L2 modularity also complicates the hard fork process. L2s have huge optionality in components like data availability, execution client, interoperability providers, and many more. Each one can react differently to a given upgrade, which adds to the amount of testing node operators need to manage. This is compounded with L1 hardforks that rollups also need to support given the chains’ interactions with the L1.

Overall, the hard fork process is more involved for L2 node operators, and compounds with the more L2s and rollup frameworks the node operator supports.

L2 nodes are a different beast

Operating nodes for L2 blockchains is much different than for L1s, and can often be more complicated and resource-intensive. Anyone building on an L2 or launching their own should be aware of this, and be sure to evaluate node providers carefully – you can’t treat them like a commodity service in the L2 environment. And crucially, don’t assume that a successful L1 node provider can meet your needs on an L2 – they may not have the experience to account for the unique complexities L2s introduce.