How good Ethereum is is a big deal, and there is nothing wrong with grapefruit. The question is how long do we have to wait?
This article is from:This article is from:Vernacular Blockchain (ID: hellobtc)
, author: Josh Stark, translation: Li Lishi, with deletions, forwarded with authorization.
For Ethereum, 2018 was a year of focusing on infrastructure. During the year, we tested the limitations of the network and refocused our energy on expansion technology.
Ethereum is still in its infancy. Today, it's not robust enough, nor scalable. Anyone who understands this technology is well aware of this. But over the past year, the speculatively driven hype has greatly exaggerated the capabilities of blockchain. Ethereum is still far from Web 3.0 (a secure, easy-to-use distributed network governed by a set of consensus mechanisms and used by billions of people), and it will not be realized until the key infrastructure is complete.
In this article, I will discuss one of the scaling solutions in depth: "off-chain" or "Layer 2" scaling, hoping to give you a comprehensive and detailed understanding of how Layer 2 works.
secondary title
Scaling Challenges of Public Chains
"Scaling" is not a single, specific problem. It is a problem that Ethereum must solve before it can serve billions of users around the world.
First of all, in terms of transaction throughput. Currently, Ethereum can process 15 transactions per second, compared to Visa's 45,000 transactions per second.
A public chain like Ethereum requires every node in the network to participate in processing every transaction, and this is its main limitation. Every operation on Ethereum must be executed by every node in the network, ensuring sufficient authority of the public chain.
secondary title
solution
solution
We need a solution that can handle more transactions without increasing the load on a single node.
In theory, we can take two approaches to solve this problem:
1. What if every node doesn't have to process every operation in parallel?
What if we could build a blockchain where nodes don't have to be involved in processing every transaction, and the network is split into two parts that can operate semi-independently?
After being separated, Zone A can process a batch of transactions, and Zone B can also process a part, which can double the transaction throughput of the blockchain. If we divide the blockchain into many, many different regions, the throughput can be increased many times.
This is the idea behind "Sharding", proposed by Ethereum Vitalik and other researchers. A blockchain is divided into many different "slices", each of which can process transactions independently. Fragmentation generally refers to the "Layer 1" expansion solution, because it is implemented on the underlying protocol of Ethereum.
2. What if a protocol layer network is built for Ethereum?
The second option is the exact opposite of the first: rather than adding to Ethereum’s own capabilities, it’s better to build on it. With the same throughput of the basic layer of the Ethereum blockchain, more operations can be performed, such as transactions, state updates or simple calculations.
This is also called "Layer 2" because it is built on top of the Ethereum main chain and does not require changes at the base layer, instead it exists only as smart contracts that interact with off-chain software.
secondary title
Layer 2 is a digital economy solution
Before detailing the Layer 2 solution, let's first understand the principles behind it.
The authority of the public chain comes from consensus. Through incentives and combining them with cryptography, consensus is achieved from within the system.
The digital economy consensus gives us certainty—unless such an extreme event as a 51% attack, all operations (including payment and smart contracts) will be executed according to the previously designed procedures.
The principle behind Layer 2 is that we can use this certainty as an anchor and attach other mechanisms on top of it. Layer 2 can extend the utility of the public chain outside the chain, making it possible for us to interact outside the chain, and these interactions can still return to the main chain when needed.
Because these layers are built on the main chain of Ethereum, it is not as safe as the operation on the main chain, but it can still ensure that they are safe and practical, especially by sacrificing a little operation authority, which can improve operational efficiency and reduce handling costs.
Here's an introduction to the technology I'm trying to apply:
1. State Channels
A state channel, which refers to a technology for processing transactions and other operations "off-chain", has a high level of security: if something goes wrong, we still have the option to go back to the on-chain transaction.
Many readers are aware of payment channels, which have been around for many years and were recently implemented on Bitcoin via the Lightning Network. State channels are a much more general form than payment channels — they can handle not only payments, but also “state updates” to the blockchain, such as smart contract changes.
In 2015, Jeff Coleman first proposed state channels. Let's first look at an example to better explain how state channels work.
Imagine that Joe and Joe play a game of three in a row, and the winner can get 1 ETH as a reward. The easiest way is to create a smart contract on Ethereum, write the rules of three-connected chess into the smart contract, and track the choices of Zhang San and Li Si. Sent to the contract every time a player makes a choice. When a player wins, according to the rules, the smart contract will pay 1 ETH to the winner.
This works, but is inefficient and slow. Because each step of the game needs to be confirmed by all nodes, resulting in a waste of resources. Every time they play a game, they have to pay a fee, and they have to wait for the miner to complete the verification before proceeding to the next game.
At this time, we can design a system so that the interaction between Zhang San and Li Si can be done off-chain as much as possible. They can update state off-chain and, when needed, go back to on-chain transactions. We call this system a "state channel".
First, we create a smart contract as a "judge" on the main chain of Ethereum, write the game rules into the contract, and recognize that Zhang San and Li Si are the two players of this game, and then set a Rewards in ETH.
Immediately afterwards, Zhang San and Li Si began to interact. Zhang San started to take the first step, signed and sent it to Li Si, Li Si would also sign, send back the signed version, and keep a copy for himself. Then Li Si took a step, signed and sent it to Zhang San, Zhang San also signed and sent it back, and kept the copy himself. Each time, they update their status. Each interaction contains a "random number", which allows each interaction to be timed.
So far, all operations are not happening on the chain. If the game ends, say Johnny wins, they can upload the final state (transaction list) and close the channel. This way, you only need to pay the transaction fee once. The contract can ensure that the "final state" is signed by both parties, and wait for a period of time to ensure that the result is reliable, and finally pay the bonus of 1 ETH to Zhang San.
Why is this waiting time required?
Suppose that what Li Si uploaded is not the final version, but the version that he won against Zhang San, but the contract will only execute the instructions, and it is impossible to know which one is the final version. At this time, setting a waiting period allows Zhang San to provide evidence to prove that what he provided is the final version.
Zhang San submits a copy of the transaction signed by both parties, and the contract determines that what Zhang San submitted is the final version through the random number of the transaction, and rejects Li Si's request.
2、Plasma
State channels are suitable for many applications and offer many upgrades to traditional on-chain operations.
On August 11, 2017, V God and Joseph Poon published a paper titled "Plasma: Autonomous Smart Contracts". This post introduces a brand new technique that can improve the processing efficiency of Ethereum.
Like the state channel, Plasma is a technology for processing off-chain transactions, which needs to rely on the underlying technology of Ethereum to guarantee its security. But the entry point of Plasma is different. It allows the creation of "sub-chains" on the Ethereum main chain. These "sub-chains", in turn, can create "sub-chains" of their own, and so on.
As a result, we can perform many complex operations on child chains, run applications with thousands of users, and require only minimal interaction with the Ethereum main chain. Plasma runs fast and charges lower transaction fees because the entire process does not need to happen on the Ethereum main chain.
Let's first look at an example to understand how Plasma works.
Imagine you are creating a trading card game on Ethereum. These cards are ERC-721 tokens (such as ether cats), but they have certain characteristics and properties that allow users to play games. Performing these complex operations on-chain is expensive, so using Plasma is a good choice.
First, we create a set of smart contracts on the Ethereum main chain as the "Root" serving our Plasma sub-chain. The Plasma Root contains the "state transition rules" of our subchains (such as "no double spending"), records the hash of the subchain's state, and acts as a kind of "bridge" that allows users to interact between the Ethereum main chain and the subchains.
Then, we create our sub-chain, which can have its own set of consensus mechanisms. In this case, Proof of Authority (PoA), a consensus mechanism that relies on trusted block producers.
Once the sub-chain is created or activated, the block producer makes a commitment to the Root contract, which is equivalent to "I testify that the latest block in the sub-chain is X." These commitments will be recorded in Plasma Root to prove that the sub-chain transactions that occurred in .
Once the child chains are ready, we can create the basic building blocks of the trading card game. The card is based on the ERC-721 of the Ethereum main chain, and is transferred to the sub-chain through Plasma Root. This brings up a key point: Plasma allows us to interact with Ethereum-based digital assets at scale.
3、Truebit
Then, we deploy the smart contract of the game application on the child chain, and write the game logic and rules into the contract. Game users, in fact, just interact with our sub-chain. They can hold assets (ERC-721 tokens) to play games with other users without directly interacting with the main chain. Because only a small number of nodes need to process transactions, transaction fees will be much lower and operations will be faster.
Unlike state channels and Plasma to expand throughput, Truebit is an off-chain technology that helps Ethereum complete heavy calculations. Truebit will not increase transaction throughput, but will allow Ethereum-based applications to do more complex things.
Some operations are too computationally expensive to perform on-chain. For example, verifying "Simple Payment Verification (SPV)" proofs from other blockchains, allowing Ethereum smart contracts to "check" whether a transaction occurred on another chain (such as the Bitcoin network).
All calculations done on Ethereum are expensive, because all nodes always need to participate in the calculation.
However, you can pay someone (the solver) a small fee to do the computation off-chain.
First, the solver deposits a fee into the smart contract, and then you inform the solver of the requirement. He does the calculations and feeds back the results to you. If the calculation is correct, his deposit is returned; if the calculation is wrong (he makes a mistake or cheats), he loses his deposit.
secondary title
in conclusion
in conclusion
"State channel" and Plasma, which will increase the throughput of the platform; Truebit, which will make more difficult calculations as part of the smart contract, thus opening up new application examples.
These three examples represent only a fraction of the scaling scenarios.
