Blockchain can't scale: at least not yet, but there is hope (3)
This article comes fromBlue Fox NotesThis article comes from
(ID: lanhubiji), author: Preethi Kasireddy, translation: Xinxin, reproduced with authorization.Blockchain Can’t Scale: At least not yet, but there’s hope (1)》、《Continuing from the previous article "》
Blockchain Can’t Scale: At least not yet, but there’s hope (1)
Blockchain Can’t Scale: At least not yet, but there’s hope (Part 2)
Scenario #5: Plasma
Plasma was recently introduced and is one of the more promising solutions to the blockchain's scalable computing problem. Plasma is essentially a series of smart contracts running on the root chain (that is, the Ethereum main chain). The root chain guarantees the validity of the state of the Plasma chain through a mechanism called "fraud proofs". (Note: Fraud proof is a mechanism to determine the validity of blocks through mathematical proof)
Source: Plasma white paper
The blockchain is organized into a tree-like hierarchical structure, and each branch is a sub-chain that contains its own blockchain history and map-reducable calculation information. We call these child chains "Plasma blockchains", and they all belong to a certain blockchain.
Source: Plasma white paper
The Plasma blockchain does not expose the content of the chain to the root chain (such as Ethereum). Instead, only the hash of the block header is committed to the root chain, which is sufficient for validating the block. If a fraud proof is committed to the root chain, the block will be rolled back and the block creator will be penalized. In other words, we only commit data to the root chain under Byzantine conditions. Therefore, the root chain only processes a small number of submissions from the child chains, thereby reducing the amount of data transmitted to the root chain and making a larger number of calculations possible.
Source: Plasma white paper
Additionally, data will only be propagated to nodes that wish to verify a particular state. This removes the requirement for every node to monitor every chain, making contract execution more scalable. They only need to monitor chains that affect their economic interests, thereby enforcing correct behavior and punishing fraud. Fraud proofs allow any party to report illegal blocks, ensuring that all state transitions are verified. Furthermore, if an attack occurs on a particular chain, participants can quickly and cheaply exit this unreliable subchain.
Source: Plasma white paper
Plasma may be somewhat similar to state channel implementations (such as the Lightning Network) in handling off-chain transactions. The main difference between state channels and Plasma is that in Plasma not all participants have to be online to update state. In addition, participants do not need to submit data to the root chain to execute and confirm transactions. The ingenious part of Plasma is that state channel-type schemes like the Lightning Network can become the main interface layer for fast payments, and Plasma maintains state updates through the submission of the minimum root chain state.
Source: Plasma white paper
There are many complex details of this scheme, which I hope to continue to dig in the following articles.
first level title
Scenario #6: Off-chain computation (like TrueBit)
An example of Truebit's solution, using off-chain computation to implement scalable transactions in Ethereum smart contracts. Essentially, like state channels, TrueBit uses a layer outside the blockchain to perform intensive computations.
That is, in this system, expensive transactions previously executed on-chain will be executed off-chain in a verifiable manner. Its workflow is as follows: instead of every node participating, a special participant in the network called a "solver" executes the calculation of the smart contract, submits the result of the problem and pays a certain deposit.
The verification game is played as follows: there are some participants in the network called "validators" who check the solver's work off-chain. If no validator issues an error notification, then the system accepts the result. If a verifier challenges the correctness of the solver's results, the game will run many rounds on the blockchain to mediate the challenge, and "referees" with limited computing resources in the network will rule on all challenges. The system architecture ensures that the work done by referees on-chain is trivial compared to the tasks actually performed off-chain.
image description
Source: Plasma white paper
A rough block diagram of the off-chain computing framework proposed by TrueBit
text
To sum up, the protocol allows anyone to submit a computing task, and anyone else can receive a reward when completing the task, and the incentive structure of the system can guarantee the correctness of the returned results. By moving the calculation and verification process from Ethereum to a separate protocol, the system's ability to handle large amounts of calculations can be scaled without being constrained by Ethereum's gas limit.
text
Other Blockchain Scaling Solutions
There are a few other interesting schemes surfacing in the cryptocurrency community. These solutions are not directly aimed at solving scalability, but they can easily solve some scalability problems indirectly. Proof of Stake: Similar to Proof of Work, Proof of Stake is a consensus mechanism that supports blockchain security by preventing double spending. In traditional proof-of-work-based blockchains, miners maintain the integrity of the blockchain data by competing to solve computationally intensive problems, and are rewarded for solving proof-of-work mathematical puzzles.
At this point, they use CPU computing power to verify transactions, and the higher the CPU computing power, the greater the percentage of your ability to influence the entire network. In proof-of-stake, stake holders vote using their "dollars" (ether in Ethereum) rather than computing power.
How exactly does this work?
The blockchain keeps track of certain validating nodes, called "validators," who must provide security collateral (called "staking") in order to be able to participate in validating blocks. If a validator produces anything that is cryptographically proven "illegal" by the protocol, their stake and privilege to participate in the consensus process is forfeited. If they bet on the consensus result, they can earn back their collateral as well as transaction fees.
In fact, validators can make money betting on the final consensus correctly, and lose money if they bet wrong. An analogy to Proof of Work is that each miner is betting their hash power on the blocks that will be accepted. If they choose to bet wrong in order to cheat the system, any blocks they produce will be orphaned, causing them to lose money.
There are many different types of proof-of-stake consensus algorithms and different mechanisms for distributing rewards to validators, which will not be discussed in depth in this article.
How does proof of stake improve scalability?
One example is use with sharding. Sharding and Proof-of-Work together are difficult to guarantee security. Recall that with sharding, we spread the responsibility of validators across multiple nodes, so each node does not need to handle all the work.
However, proof-of-work is implemented to be completely anonymous, which creates a problem that even if a single shard contains only a small fraction of the miner's hash power and is thus secure, an attacker can use all of their hash power to attack the Shard and challenge the entire network. For example, we have two shards, A and B.
A has 90% of the hashing power and B has 10%. A only needs to use 5.1% of its total hashing power to attack B (by virtue of the majority 51% attack). Ethereum's current proof-of-stake proposal would change all of this, because by its design validators would have certain identities (i.e. Ethereum addresses).
Knowing their identities we can solve this type of targeted attack by randomly selecting some nodes from the entire set of validators to process any given set of transactions on a shard, making it impossible for an attacker to target any particular shard attack.
Another reason Proof-of-Stake can improve scalability (especially Ethereum) is that, unlike Proof-of-Work, which issues new tokens to miners who validate blocks, in Proof-of-Stake, validators are likely to only earn transaction fees. Therefore, they have an incentive to increase the block "gas limit" (since more transactions can be included in each block to earn more transaction fees), if their validating servers can bear the corresponding load.
Note that validators can only increase the gas limit up to a point that other validators can afford, otherwise their rewards will shrink as other slower validators abort synchronization.
Blockchain Leasing
Another Ethereum-specific solution is "blockchain leasing". Blockchain leasing is a solution that helps speed up the number of transactions by reducing the amount of data stored on the network. On Ethereum, users pay for computing steps, memory, transaction logs, and persistent storage. Most of these resources are paid for with a reasonable incentive, but storage is not.
In the current system, users only pay for the number of bytes stored. In reality, however, we can argue that storage is different from other resources because it is permanently persisted into blocks. Instead, blockchain leasing proposals define storage consumption as "bytes x time". In this way, an incentive is built into the protocol to keep the network lightweight and reduce the number of transactions.
Another way to keep the network lightweight is to use a decentralized storage service like Swarm. Swarm is a peer-to-peer file sharing protocol on Ethereum. You can move application code and data from the main chain to Swarm nodes. These nodes are connected to the main chain of Ethereum, and then exchange these data with the main chain.
The basic premise here is that nodes do not store everything on the blockchain, they only store data that is often requested locally, and put other data in the "cloud" through Swarm.
Source: Plasma white paper
in conclusion
There are many more options, but for the sake of brevity (this article is already very long), I will not discuss them here.
in conclusion
-----
This topic is extremely complex, but I hope this article has given you a panoramic view of why blockchain scalability matters, and how it can be addressed. This is by no means a complete list, and I will continue to follow up on this topic as my research progresses. Personally, I am very skeptical that there is a perfect answer to scalability... but I believe that some combination of approaches can finally solve this problem and allow blockchain applications to move forward.
As always, feel free to correct me if I'm wrong, or start a (reasonable) discussion in the comments. Have fun with blockchain!
