How does the Ethereum layer 2 scaling solution solve the obstacles to establishing a business on the Mainnet

Scaling problem: My application requires hundreds or thousands of transactions per second, which cannot be handled by the public chain This is exactly the problem that the L2 solution aims to solve. Depending on the specific L2 technology and implementation, it may provide throughput that is 50 times to 1000 times higher than that of L1.

At the high end: state channels, plasma, validium, side chains and certain hybrid solutions. At the lower end: zk aggregation and optimistic aggregation.

Speed ​​and latency issues: Our CRM and ERP systems do not need the transaction processing speeds per second of Visa or Mastercard (even they get those TPS rates through parallelization…and they won’t lie to me). However, the long waiting time of round trip + consensus makes me may encounter a bad user experience when using Mainnet. Some L2 solutions can provide “instant” transaction confirmation and have an economic guarantee that your transaction will be included in the next L2 block.

Side chains can also provide shorter block times and faster certainty within the side chains (although transactions are not fixed on L1).

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

The finality problem: Ethereum is an “eventually consistent” machine. If Eth2.0 changes this situation, I don’t understand…about the magical fast finality. I do not know. What I know is that all of my systems are systems that complete data changes within the second second of writing data. L2 may make this more complicated, as transactions may need to be completed on both L2 and L1 at the same time. At least its complexity is the same as L1.

However, Ethereum 2.0 introduced finality through its new consensus algorithm Casper FFG. After migrating to Eth2, it can be considered that both L1 and L2 transactions have been completed after a period of time.

Noisy neighbor problem: Other users and network activities must not disturb my operation. As a company that relies on predictable operating times to perform mission-critical operations, I need to be satisfied that “hidden” events are unlikely to occur. I need to know that even if the Mainnet is a public utility, it can be reasonably guaranteed in some way that the reading, writing and calculation required for my business on the Mainnet will not be reduced by other people’s activities. The extent to which “noisy neighbors” disrupt your operations by consuming most of the L1 capacity depends on the type of L2 technology and how it is implemented. Certain technologies, such as Plasma and Validium, rarely write data to L1. Therefore, if needed, L2 operators can pay higher gasoline prices to ensure that their transactions are processed on L1 in a timely manner. These solutions are very resistant to “noisy neighbors”.

Side chains are also relatively unaffected by this problem because they do not depend on the L1 chain. However, the transfer of tokens or data to/from the L1 chain is still limited by the capacity of L1.

Aggregate L2 solutions are limited by the available capacity of L1 and may suffer more from Mainnet congestion. The L1 gas cost of anchoring these L2 transactions to L1 is still far lower than the cost of conducting these transactions directly on L1. Therefore, operators can pay higher transaction fees to ensure timely processing. Compared with the previously mentioned solutions, these solutions are less resistant to noisy neighbors, but more resistant than applications running directly on L1.

If an enterprise application is sharing an L2 instance with other applications, depending on the implementation, the L2 operator may be able to provide a certain amount of guaranteed throughput or SLA for the L2 instance. The application or company may also have its own L2 instance.

Private data issues: Eighty percent of our data is considered sensitive, internal or personally identifiable customer, customer or user data. Encryption is not enough. Any data can be anonymized and decrypted at a given time. Anyone with a full node will always have to tighten the position on the ledger. Therefore, I don’t even like to put encrypted data on a public chain. Certain L2 technologies (such as Validium, Sidechain, and Arbitrum SCSC) are able to keep all L2 data in the L2 instance and not in L1.

If multiple companies write data to the same shared L2 instance, they will be able to see each other’s data (such as a consortium), but if the company has its own instance, the data can be kept confidential.

Security issue: The encrypted data is still data. Storing PII and client data on a peer-to-peer platform, even if it is encrypted, violates our policy. When summarizing all transaction data into L1, other solutions do not. Some L2 solutions allow companies to run their own private L2 instances, which keep all L2 data on servers controlled by the company.

Ultimately, the need to place sensitive data on the blockchain should be questioned, because some design patterns avoid using the blockchain as a database and instead focus on leveraging its advantages while keeping sensitive data off-chain.

Data locality issue: GDPR requires me to be able to specify the storage location of PII data, even if it is encrypted. And I need to be able to delete the data permanently upon request. If the data is permanently located on any number of nodes out of my control…yes. Using certain L2 solutions that do not write transaction data to L1, L2 operators can provide GDPR-compliant L2 services that store L2 data in a known location with the required level of security. Alternatively, the company can run its own private L2 instance and have complete control over the L2 data. Responsible party issue: My legal structure requires that there must be a responsible party to handle all aspects of my data and business logic. If I put the data on the Mainnet, I will lose the key responsible party. Some L2 solutions are run by operators, who can provide SLA and security in the traditional way and are responsible for them. Transaction cost issue: Ethereum gasoline prices have been rising. If I need to make millions of transactions, it would be too expensive. This is another problem specifically addressed by L2. Because anchoring L2 transactions on L1 consumes much less gas than doing transactions directly on L1, the cost of L2 transactions is much lower.

The exact savings depends on the L2 technology. L2 such as state channels, plasma verification areas, and side chains are the most economical, while L2 (such as aggregation) that stores transaction data on L1 offers less savings (but still considerable).

Cost unpredictability problem: gasoline prices rise and fall. Cryptocurrency prices fluctuate up and down. It is difficult to predict how much my transaction will cost. In some L2 implementations, an operator may charge a fixed/guaranteed price for each transaction.

Side chain operators may provide flat rate pricing for the variable duration of chain operations (3mo, 6mo, 12mo). To a large extent, transactions in the chain will be non-transactional.

Even with market-based variable prices, L2 will greatly reduce the cost of each transaction. Depending on the type of L2, the transaction cost of L2 may change linearly as the gasoline price on L1 changes (cumulative), or it may be relatively decoupled due to less data stored on L1 (validation, plasma, etc.). Considering the lower overall cost, the impact of variability can be reduced.

Encrypted payment problem: I must hold encryption and pay transaction fees in an encrypted way. It is a nightmare to adapt our company’s treasury to buying, holding and paying for cryptocurrency. If the L2 instance is run by a third-party operator, the operator can accept any form of currency of their choice (including traditional legal tender) as payment for the L2 transaction.

Transaction repeaters (aka gas stations) can also solve this problem on L1, they can accept fiat or token payments and relay transactions to the L1 network.

Strategy leakage problem: Transaction metadata can be used in game systems or to collect/analyze strategic counterintelligence or companies. spy. In the AI ​​era, even if the changes made to Merkle’s attempts are small, any tracking activity performed on the permanent public ledger can be used to determine who is doing what. L2 based on certain technologies (for example, validium, sidechain, Arbitrum SCSC) can keep L2 transaction details inside L2 and outside L1. Then, L2 can restrict access to authorized entities. If a company runs its own private L2 instance, it can keep its transaction details private (although for L2 used by only one entity, usage may be limited).

A similar “baseline” approach can also be used, in which transactions between entities are carried out privately, and only the ZK correctness certificate (collected in batches) is submitted to L1 or L2.

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

Still under development is a data confidentiality and escrow protocol that relies on access rights management, distributed key generation, and a trusted execution environment to keep data private (except inside the TEE in layer 2).

Confidential code issue: You can’t just use ZK-SNARKS and the like to hide data and think that everything is normal from the company’s point of view. Many business agreements are embodied in code…business logic. If the machine can execute the smart contract, it can decompile and view the logic, which may leak sensitive information. Some L2 does not support smart contracts and code execution.

If your transaction requires code execution, you can use a method similar to “baseline”, where transactions between entities are conducted privately, and only the ZK correctness certificate will be submitted to L1 or L2.

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

Emotional aspect: Bitcoin and Ethereum are used for non-regulated/non-ledger purposes (ie criminal activities). I don’t want to be related to this, and I am worried about what will happen if the government cracks down on public blockchains. As the public use of Ethereum grows, it will become more difficult for any government to censor or block the network. Although it may be possible to eliminate or reduce the use of criminals on a global scale, it is impossible to prevent the growth of decentralized computing and public networks. The advantages of sharing agreements, digital currencies/tokens, untrusted and automated contract execution, and other advantages of Web3 are too powerful to be prevented.

Running your application on L2 can provide a certain degree of isolation from the public L1 blockchain. L2 can operate more like a traditional business IT infrastructure with security and accountability, and act as a buffer between your business and unregulated activities, but L1 is still a referee, with immutability, interoperability and The advantages of a universal reference frame provided by L1.

Source link

You May Also Like

Leave a Reply

Your email address will not be published.