Scaling Problem: My application requires hundreds or thousands of transactions per second, which public chains can’t handle This is exactly the problem L2 solutions are designed to address.  Depending on the specific L2 technology and implementation, it may offer from 50x to over 1000x more throughput than L1.

On the high end: state channels, plasma, validium, side chains, and certain hybrid solutions.  On the lower end:  zk-rollups and optimistic rollups.

Speed and Latency Problem: Our CRM and ERP systems don’t need the kind of Transaction Per Second speeds of a Visa or Mastercard (and even they get those TPS rates through parallelization…can’t fool me). But long wait times for round-trip + consensus makes things I might do with the Mainnet a bad user experience. Some L2 solutions can provide “instant” transaction confirmations with an economic guarantee that your transaction will be included in the next L2 block.

Sidechains can also offer shorter block times and faster finality within the sidechain (though the transactions are not anchored to L1).

Finalizing L2 transactions on L1, to get the full benefits of L1 security, still depends on L1 block time. Whether you need to wait for L1 finality, L1 confirmation, or only for L2 confirmation will depend on the specifics of your application.

Finality Problem: Ethereum is an “eventual consistency” machine. If that’s changing with Eth2.0, I don’t understand it…something about a magical fast finality something. I dunno. What I do know is that all my systems are ones where a change to data is final the second it’s written. L2 may make this a bit more complicated, because transactions may need to be finalized on both L2 and L1.  At a minimum it’s the same level of complexity as L1.

However, Ethereum 2.0 introduces finality via its new consensus algorithm, Casper FFG.  After migration to Eth2, both L1 and L2 transactions can be considered finalized after some period of time.

Noisy Neighbor Problem: Other users and network activity must not disrupt my operations. As an enterprise conducting mission-critical operations that rely on predictable operation timing, I need to be comfortable that a “cryptokitty” event isn’t a possibility. I need to know that, even though the Mainnet is a public utility, there is reasonable assurance by some means that the reads, writes and computations I need to conduct business on the Mainnet will not be reduced to a crawl by the activities of others. The degree to which “noisy neighbors” can disrupt your operations by consuming most of the L1 capacity depends on the type of L2 technology and how it is implemented.  Some technologies such as plasma and validium write very little data to L1.  Because of this, the L2 operator can pay higher gas prices if needed to ensure that their transactions are processed on L1 in a timely manner.  These solutions are very resistant to “noisy neighbors”.

Sidechains are also relatively immune to this problem because they do not depend on the L1 chain. But transferring tokens or data to/from the L1 chain is still subject to the capacity of L1.

Rollup style L2 solutions are constrained by the available capacity of L1, and can suffer more from Mainnet congestion.  The L1 gas cost to anchor these L2 transactions on L1 is still much lower than the cost to make these transactions directly on L1, so the operator may be able to pay higher transaction fees in order to ensure timely processing.  These solutions are less resistant to noisy neighbors than the previously mentioned ones, but more resistant than applications running directly on L1.

If enterprise applications are sharing an L2 instance with other applications, depending on the implementation, the L2 operator may be able to provide some amount of guaranteed throughput or an SLA with respect to that L2 instance.  An application or company may also have its own L2 instance all to itself.

Private Data Problem: Eighty percent of our data is considered sensitive, internal or personally identifiable client, customer or user data. Encryption isn’t enough. Any data can be deanonymized and decrypted given time. And anyone with a full node has forever to crunch the bits on the ledger. So I don’t like putting even encrypted data on a public chain. Certain L2 technologies (such as validium, side chains, and Arbitrum SCSC) are able to keep all L2 data within the L2 instance and off of L1.

If multiple companies are writing data to the same shared L2 instance, they will be able to see each other’s data (like a consortium), but if a company has its own instance then the data can be kept private.

Security Issues: Encrypted data is still data. It is against our policy to store PII and client data, even encrypted, on peer to peer platforms. While rollups write all transaction data to L1, other solutions do not.  Some L2 solutions enable a company to run their own private L2 instance which keeps all L2 data to itself, on servers controlled by that company.

Ultimately, the need to place sensitive data on a blockchain should be questioned, as there are design patterns which avoid using blockchains as databases and focus on leveraging their strengths, while keeping sensitive data off-chain.

Data Locality Problem: GDPR requires that I can account for where PII data is stored, even when it is encrypted. And I need to be able to delete that data permanently upon request. If the data is sitting permanently on any number of nodes not controlled by me everywhere…yeah. With certain L2 solutions that do not write transaction data to L1, an L2 operator can provide a GDPR compliant L2 service which stores L2 data in a known location with the required level of security.  Or a company can run its own private L2 instance and have complete control over the L2 data. Responsible Party Problem: My legal structure requires that there be a responsible party handling all aspects of my data and business logic. If I put data on the Mainnet, I lose a key responsible party. Some L2 solutions are run by an operator, who can offer and be held accountable for SLAs and security in traditional fashion. Transaction Cost Problem: Ethereum gas prices have been going up. If I need to conduct millions of transactions, it’s going to be insanely expensive. This is another problem that L2 was specifically designed to address.  Because anchoring L2 transactions on L1 consumes much less gas than conducting the transactions directly on L1, L2 transaction cost is much lower.

The exact savings depends on the L2 technology.  L2s like state channels, plasma validium, and sidechains are the most economical, while L2s that store transaction data on L1, like rollups, offer less (but still substantial) savings.

Cost Unpredictability Problem: Gas prices go up and down. Crypto prices go up and down. It’s too hard to forecast how much my transactions will cost. With certain L2 implementations, there is an operator who may charge a fixed/guaranteed price per transaction.

Sidechain operators may offer flat rate pricing for variable durations of chain operation (3mo, 6mo, 12mo). Transactions within the chain would largely be gasless.

Even under variable market-based pricing, L2 greatly reduces cost per transaction.  Depending on the type of L2, L2 transaction costs may vary linearly as gas prices on L1 vary (rollups), or may be relatively decoupled because less data is stored on L1 (validium, plasma, etc.).  Given lower overall cost, the implications of variability may be reduced.

Crypto Payment Problem: I have to hold crypto and pay for transactions in crypto.  Getting my company’s treasury comfortable with buying and holding and paying in crypto is a nightmare. If the L2 instance is run by a 3rd party operator, the operator may accept payment for L2 transactions in any form of currency they choose, including traditional fiat.

This problem may also be addressed on L1 by transaction relayers (aka gas stations) who can accept payment in fiat or tokens and relay transactions to the L1 network.

Strategy Leaks Problem: Transaction metadata can be used to game the system or collect / analyze for strategic counterintelligence or corp. espionage. In the age of AI, any trace activity done on a permanent, public ledger can be used to figure out who is doing what, even if it’s just little changes to Merkle tries. L2s based on certain technologies (such as validium, side chains, Arbitrum SCSC) are able to keep L2 transaction details contained within the L2 and off of L1.  The L2 can then restrict access to authorized entities. If a company runs its own private L2 instance then the details of their transactions can be kept private (though there may be limited use cases for L2s that are used by only one entity).

It is also possible to use an approach like Baseline, wherein transactions between entities are conducted privately, and only ZK proofs of correctness (gathered in batches) are submitted to either L1 or L2.

An emerging technology called zkzk-rollup (e.g. Aztec 2.0) allows confidential transactions within the L2 so that others on the same L2 instance cannot decipher your transactions.

Also under development are data privacy and custody protocols which rely on access rights management, distributed key generation, and trusted execution environments so as to keep data private except for while inside a TEE within the Layer 2.

Confidential Code Problem: You can’t just hide the data with something like ZK-SNARKS and think that everything is ok from a corporate perspective. Many business agreements are embodied in code… business logic. If a machine can execute a smart contract, it can decompile and look at the logic, and that can leak sensitive info. Some L2s don’t support smart contracts and execution of code.

If your transactions require code execution, it may be possible to use an approach like Baseline, wherein transactions between entities are conducted privately, and only ZK proofs of correctness are submitted to either L1 or L2.

An emerging technology called zkzk-rollup (e.g. Aztec 2.0) allows confidential transactions within the L2 so that others on the same L2 instance cannot decipher your transactions.

Emotional: Bitcoin and Ethereum are for non-regulated/off book uses (i.e. criminal activity). I don’t want to be associated with that, and I’m afraid of what might happen if governments cracked down on public blockchains. As public use of Ethereum grows, it becomes more difficult for any one government to censor or block the network. While there may be global efforts to remove or reduce use by criminal actors, it is unlikely to forestall the growth of decentralized computing and public networks. The advantages of shared protocols, digital currency/tokens, trustless and automated contract execution, along with other Web3 benefits are too powerful to stop.

Running your applications on L2 can provide a degree of isolation from the public L1 blockchain.  The L2 may be operated more like traditional business IT infrastructure with security and accountability, and act as a buffer between your business and unregulated activity, but still has L1 as an umpire, plus the benefits of immutability, interoperability, and the common frame of reference that L1 provides.

Source: https://entethalliance.org/how-ethereum-layer-2-scaling-solutions-address-barriers-to-enterprises-building-on-mainnet/