Why L2 development runs into a throughput ceiling
The throughput of any first-layer blockchain is fixed: a block holds a strictly limited amount of data, and this limit cannot be expanded administratively.
As soon as the flow of operations exceeds the threshold, transactions are not rejected — they queue up and wait for space in the next block.
Then an auction for that space kicks in. Transaction cost is calculated from current load, so under peak load — token launch, mass distribution, spike in app activity — the fee grows tens of times within minutes.
A user who yesterday sent an operation with a minimal fee today sees an increased cost and simply closes the interface.
The product breaks not at the moment of explicit failure but earlier.
Confirmation delay stretches from seconds to tens of minutes, the interface shows endless "waiting," balances do not add up, and scenarios built on fast finality — exchange, betting, game mechanics — become inoperable throughout the peak interval.
In such windows the network loses exactly those users who came for speed, and winning them back later is more expensive than retaining them would have been.
We break down how this is solved: where base layer capacity ends and what exactly an own second-layer network provides.
What an own rollup provides: speed, cost, control
Throughput stops hitting someone else's network
Transactions execute inside your layer, and only a compressed batch with the result goes to the main network. One record there carries thousands of operations, so throughput under load grows by multiples, not by percentages. When user flow spikes, the processing pace is set by your sequencer node, not by the shared queue.
You set the fee, not an auction in the main network
The fee per operation is determined by your layer's policy: a flat gas rate instead of an auction where price grows from others' activity. During peak hours the fee does not double — it can be capped for the user and kept predictable under a manifold increase in flow. Service costs become plannable rather than dependent on someone else's traffic.
Failures that no longer stop the service
An own rollup removes an entire class of failures related to main network congestion: operations do not hang waiting to be included in a block and are not lost when fees spike.
If the main network slows down, batches accumulate and confirm later, while layer state and user operations continue. The service stops depending on what happens in the shared network.
Predictable confirmation time
Confirmation time is determined by architecture, not current load: the operation is visible to the user almost immediately, and finality occurs after batch publication and verification.
In validity-proof schemes, finality arrives in one step; in challenge-window schemes, according to a clear procedure. In both cases, latency does not depend on someone else's traffic.
Comparison of approaches: optimistic rollups and ZK proofs
Second-layer architecture is chosen not by how "modern" the solution is, but by what guarantees the user gets and how long they wait for funds to be returned. Below are three options actually chosen at project start.
Optimistic and ZK schemes diverge along three axes: settlement finality, withdrawal time, and security model — who exactly proves correctness and what happens under dishonest node behavior.
A dedicated channel stands apart: it does not inherit base layer protection in full, but gives control over execution rules and throughput.
| Option | When it fits | Limitations |
|---|---|---|
| Optimistic rollup | Mass transactions, migration of existing contract logic without rewriting, fast launch | Withdrawals wait for the challenge period to end — usually days; settlement finality is delayed, observers ready to challenge an invalid block are needed |
| Zero-knowledge proofs | Fast finality and short withdrawal time are needed, high value of operations | Proof generation is computationally more expensive, some operations have to be limited; harder to assemble and maintain the proving subsystem |
| Dedicated channel | Own gas rules, predictable throughput, private operations | Its own security model: correctness is ensured by channel validators, not the base layer; exiting the channel is more complex |
In practice, the scheme is selected for the load profile: where compatibility and execution cost matter — the optimistic path wins; where fast finality is critical — zero-knowledge proofs.
L2 development: audit, network design, setup, and handover
We start L2 development not with code but with analysis of what already exists: which scenarios the network serves, who writes to it and how often, where the boundary lies between the main chain and the second layer.
This order saves weeks — redoing the design after nodes launch is more expensive than clarifying it before the first transaction.
Work order
- Scenario audit. Analyze operation flows, peak load profile, requirements for confirmation time, and who holds keys. Record which operations we move to the second layer and which we leave in the main network.
- Network design. Choose the assembly and proving model, number of validator nodes, deployment topology, gas fee rules, and access roles. Here we also determine how the network will survive a single node failure.
- Node setup. Bring up nodes, configure synchronization, network state access, monitoring, and backups. Separately verify that startup order is reproducible from scratch according to instructions.
- Integration with the main network. Configure asset transfer between layers, withdrawal delays, and rollback handling during chain reorganization.
- Load testing. Run scenarios replicating the peak profile, measure throughput and response time, deliberately shut down nodes, and observe recovery.
- Acceptance and handover. Provide documentation, access, update and incident response procedures, and train the team — the network must be operated without us.
Each stage closes with an artifact: report, diagram, configuration, or test protocol. Acceptance is based on pre-agreed metrics, not a feeling that "it seems to work."
Documentation package: network diagrams, access policies, procedures
After network launch, the team retains not only a working environment but also a document package according to which it can be operated without us. We hand it over in the form we use ourselves: no generic wording, with concrete values and procedures. Below is what the package includes.
- Node configurations — settings files for the sequencer, verifier nodes, and network access nodes with line-by-line breakdown: which values are standard, which were selected for your load, and what will happen if they deviate.
- Topology diagram — how nodes connect to each other, where the boundary with the main network lies, which channels are duplicated, and which failure points are left intentionally.
- Access policies and roles — a "role → action → key" matrix: who publishes contract updates, who manages wallets, who only reads metrics, and why the first two permissions should not belong to one person.
- Update procedure — release order for new contract and node versions: preparation, maintenance window, who approves, how the result is verified, and which rollback scenario is used.
- Instructions for the on-call shift — what counts as a deviation, which signals require action within the shift, which can wait until morning, and at what point developers are escalated.
- Key handling procedure — where signing keys are stored, how rotation is performed, and what to do in case of compromise.
- Recovery plan — what is backed up and how often, how long it takes to bring the network up from scratch on clean infrastructure, and who is responsible for the procedure.
How we removed peak load: metrics before and after
What it was before migration
The client — a service with a stream of small operations: accruals, bets, withdrawals. During peak hours, the base layer stopped accepting some transactions: the share of rejected operations reached 8–9%, and confirmation stretched to a minute or more.
Retries only increased pressure — the queue could not keep up, and the service degraded exactly when load was at its maximum.
What we changed and what we got
Deployed an own second layer on optimistic rollups: hundreds of client actions are packed into one batch, and one summary goes to Ethereum. Added a priority queue with re-enqueueing — under overload an operation waits its turn instead of failing.
Metrics before and after: share of rejected operations fell from 8–9% to 0.3%, average confirmation dropped from 60 to 2–4 seconds, peak behavior became stable.
A load run with three times normal traffic was sustained for 40 minutes — without queue growth and without manual on-call interventions.
The main thing — an entire class of failures disappeared: operations are no longer lost due to base layer block overflow. Retries returned to normal mode, and peak incidents stopped being a regular item in the on-call report.
How does an optimistic rollup differ from a ZK rollup?
Both families solve one task: execution moves off the main layer, while data and proof of state correctness go to the settlement layer (Ethereum).
The difference is in how this proof is structured — confirmation timing, requirements for the verifying side, and maintenance effort depend on it.
An optimistic rollup by default considers a batch of transactions valid and leaves a challenge window.
While the window is open, withdrawal to the main layer waits, but there is nothing to verify in real time: one honest participant is enough to publish fraud proof if there is a discrepancy.
The verifying side only needs a regular node — special equipment is not required, and verification cost is close to zero.
A ZK rollup attaches a zero-knowledge proof to each batch, and the contract changes state only after its verification. Confirmation arrives noticeably faster and does not depend on whether observers are nearby.
Verifying the proof on the main layer is cheap, but generation requires specialized equipment from the operator — this resource is the main cost item of the scheme.
Maintenance differs no less. In the optimistic model, effort goes into challenge economics, monitoring, and censorship resistance on the sequencer side.
In ZK — into proof schemes and their audit: changing logic requires reworking the scheme, re-verification, and a careful update procedure, so the team needs its own cryptographic competencies.
The scheme is chosen by priority: speed of final confirmation and independence from observers — in favor of ZK; compatibility with existing contracts and tools, predictable maintenance — in favor of the optimistic model.
Describe your scenario — we'll return with an estimate and plan for both options, indicating the bottleneck and how to close it.
Typical concerns: security, withdrawals, support
Before work starts, the client's engineers ask the same questions: how computation correctness is confirmed, what happens if the sequencer node fails, how funds are withdrawn, and who will stay with the network after launch. Below are short answers to the point.
We analyze detailed schemes, contract addresses, and the permission matrix at the design stage — for each item you retain a document, not a verbal promise.
How is computation correctness and settlement security confirmed?
In the Optimistic scheme, the result is accepted without immediate verification, but a challenge window remains: any participant recalculates the state transition and submits an error proof — a forged batch is rolled back.
In the ZK scheme, each batch is accompanied by a correctness proof, and the verifying contract discards the batch if computations do not match the state root.
What happens if the sequencer node fails?
We keep a hot standby and migrate the transaction queue — downtime is measured in minutes. If the entire group fails, participants send transactions directly through the base layer contract: confirmation latency increases, but state and funds remain in the network.
How are withdrawals arranged?
Withdrawal is two-step: initiation on the second layer, then confirmation in the base layer after the challenge window. In the ZK variant, the wait is shorter — correctness has already been confirmed by proof.
Fast withdrawal through third-party bridges is connected separately, with an assessment of their risks and limits.
Who supports the network after launch?
We hand over the procedure: node and queue monitoring, key rotation, planned updates, incident analysis. For the first weeks we are on call together with your team, then — according to an agreed level of technical support with a defined response time.
Let's discuss the task: we'll select a scheme and return with an estimate
For the estimate to be substantive rather than a rough range, we need input data from the client. It is exactly what determines the choice between an optimistic scheme and validity proofs, node configuration, and the scope of accompanying infrastructure.
- Scenarios for which the second layer is needed: payments, exchange, game logic, or internal accounting — the fee model and throughput requirements depend on this.
- Load profile: expected number of operations at peak, share of simple transfers, confirmation time acceptable to the user.
- Withdrawal requirements: what final withdrawal time is considered normal, whether a fast bridge is needed, and who holds liquidity on the main network side.
- Governance model: who owns contracts, who updates logic and how, which roles are needed for pauses and emergency stop.
- Integrations: wallets, exchanges, indexers, analytics, and existing services to which the new layer must connect.
- Constraints on timelines and stages: the date by which a working environment is needed, and what can be moved to the second phase.
- Verification requirements: whether an external audit is needed, which reports, access, and deployment scheme your team expects.
Once we receive this data, we'll return with a scope estimate, a stage-by-stage work plan, and timelines for each — from prototype environment to launch and handover to operation. Describe the task in a convenient format: correspondence, a call, or a short technical summary.