Introduction: Ethereum 2.0 is inspired by the upgrade of Ethereum 1.0
Editor's Note: This article is from:Ethereum enthusiasts (ID: ethfans)Editor's Note: This article is from:
Ethereum enthusiasts (ID: ethfans)
Ethereum enthusiasts (ID: ethfans)
, Author: Ivan Martinez, translation: A Jian, reproduced by Odaily with authorization.
Introduction | Overview Ethereum account abstraction
Compared with Ethereum 1.0, the most significant changes in Ethereum 2.0 are the proof-of-stake consensus and sharding architecture, but in fact, there are still many innovations inspired by the process of improving Ethereum.
What we've seen since the creation of Bitcoin and Ethereum
The Bitcoin blockchain has been in operation for 11 years, and its creation has inspired countless people with lofty ideals to study and even study the design and cryptoeconomics of the blockchain to discover what can be improved.
From PoW, we already know that the security of the protocol is always the most important for cryptocurrency. Using expensive hardware to incentivize people to get more skin in the game works surprisingly well. While there is still room for loopholes (so-called "selfish mining"), PoW has done a fantastic job of protecting Bitcoin's network security.
The Ethereum blockchain was launched in 2015, and its birth marked the emergence of a "universal" blockchain: everyone can build applications on the network that can interact with ETH and other tokens. These applications opened the door to decentralized finance, and today more than $1 billion is deposited as collateral for decentralized financial operations. I have another article about how DeFi (decentralized finance) has grown into a real service on Ethereum step by step.
Factors Limiting Eth1.X Expansion Throughput
In 2017, when the development of Ethereum was in trouble, multiple "Ethereum terminators" rose up and claimed to "defeat" Ethereum. But these "terminators" are mainly sacrificing security in exchange for higher throughput (TPS, transaction processing per second), and they are completely misleading (or intentionally confusing) advertising that transactions do not need to pay fees. In fact, none of them is a “solution” to the problems Ethereum is facing.
Ethereum 2.0
To truly upgrade Ethereum, everyone has to break out of the existing system and start over. We can take the best of Ethereum and discard its many dross.
Note: In the following, I use "state" to refer to global permanent data stored on the Ethereum blockchain, such as account information, transaction data, and smart contract states (such as token balances).
Ethereum 2.0
Ethereum 2.0 is the largest open-source project in the cryptocurrency space to date, aiming to develop a new system that achieves Ethereum's original goals and beyond. You may have heard of Casper (a consensus algorithm under proof-of-stake) and sharding, but the goal of Ethereum 2.0 does not stop there.
Because many improvements are too radical for the existing Ethereum blockchain, these improvements may be made on the Ethereum 2.0 chain, and then the existing Ethereum chain will be "plugged in" to the new system (becoming one of the sub-chains). piece). In this way, Ethereum 2.0 will not become too complicated to upgrade the existing network, and the Ethereum network can continue to operate as usual, and then reap all the benefits of the new system.
This article wants to talk about the lesser known changes in Ethereum 2.0, and how these changes were inspired by helping Ethereum move towards the beautiful world of decentralization.
Monetary Policy (Security Cost)
Although many Ethereum hoarders feel that the cost of the Ethereum blockchain is too high for security; however, if this reduces the rate of issuance, it may lead to a sharp drop in mining computing power and security, because miners Can't make that much money anymore. Therefore, it is difficult to reduce the issuance rate under PoW, because the reduction will have unexpected side effects on the security of the chain. Bitcoin doesn't have this problem (largely) because changes in its mining rewards are largely predictable in the long run.
Well, one of the biggest goals of Ethereum 2.0 is to switch to the proof-of-stake (PoS) consensus mechanism, that is, to remove the role of expensive mining hardware (whether it is ASIC or GPU), intensive calculation and power consumption, will be replaced by Instead, cheap ordinary computers are sufficient to handle only Eth2 node processes such as block transmission and synchronization. In this way, the cost of protecting network security is much lower! However, users need to lock 32ETH to join.
The overall security cost is reduced, and the issuance rate can be reduced to less than 1%, depending on how many users participate in the network to become verifiers. In this way, the issuance rate can scale with how much it has to pay for security.
image description
- The number of additional issuances (reward scale) scales with the actual need to pay for security -
In addition to the reduction in the issuance rate, Ethereum 2.0 also aims to replace the current auction market model used when paying Gas fees, and replace it with a slightly different model, namely "EIP1559". You don't need to know how it works, just know that in this mode, most of the fees paid by users will be destroyed. Although in this mode, users will pay less fees, but because Ethereum 2.0 has many shards, the total fee scale will be larger than the current Ethereum, so the amount destroyed will be more many.
On the one hand, the issuance rate is very low, and on the other hand, part of the transaction fee is destroyed. The net issuance rate of Ethereum 2.0 may be negative, that is, the amount burned will be more than the amount issued! Then ETH will become more scarce, making it more expensive to attack the PoS system.
stateless
You may have heard the term "state explosion", which is often mentioned when talking about Ethereum and the size of its state data. The essence of this problem is that a one-time payment of Gas fees allows your data to stay on the Ethereum blockchain forever, which leads to an unlimited growth of state data, and a lot of data may never be used again . The "explosion" of state data on the storage scale means that the storage space and hardware conditions of Ethereum nodes must increase linearly as the network continues to survive. In the long run, this limits the size of the population that can run an Ethereum node, and the state data growth problem gets worse every time the block gas limit is raised.
Then, the solution to this problem in Ethereum 2.0 (and ETH1 in the future) is statelessness, which means that nodes can verify all transactions and all parts of the state without saving any state. After statelessness is achieved, the modes of nodes can form a spectrum from stateful to stateless, each mode has different specifications. If you have better hardware and it is more than enough to run a stateless node, but you still cannot run a fully state-saved node, then you can take a compromise and run a "quasi-stateful" node. To learn more, watch this talk from the ETHDenver event!
image description
- Network topology under the stateless paradigm -
This is critical for sharding! Because each shard has its own unique state, and Eth2 validators need to perform state changes (process transactions) according to the state on the shards they verify. The stateless protocol eliminates the need for validators to download the full state of a shard, only the binary Merkle tree representing the data (which is much smaller than the state data).
The more shards, the more endless the growth of state data. Although there will definitely be services such as exchanges or block browsers, there will be incentives to save all shard state data/historical data, and it will be accurate regardless of cost. deliver. Then there is the possibility of "state provider" software that provides validators with the state part of a transaction to change, enabling the latter to execute the state change. The state provider can completely eliminate the need for hard disk read and write and intensive storage during the verification process. Not only does this open up the possibility for new, state-specific incentives, but it also greatly helps validators, who no longer need to keep the full shard state. Of course, they can still verify the correctness of the state received from the state relay, since this data can be compared with the synchronized state tree.
account abstraction
In the current Ethereum protocol, there are two types of accounts, externally controlled accounts (that is, accounts controlled by people using private keys) and smart contract accounts. Only externally controlled accounts can initiate transactions, and only transactions initiated by users who control the private key can change the state of their own accounts. Although there is a meta transaction now, it needs to rely on a relayer network (such as GSN) to pay the Gas fee.
For Ethereum 2.0, the goal is to abstract these two accounts into one account, so that there is no difference between user accounts and contract accounts in the network. Contracts will continue to exist, of course, but then the Ethereum network itself will be able to act as a relay for meta-transactions. Signing a transaction and broadcasting it yourself will no longer be the only way you interact with the network.
At that time, you can make your account like a smart contract. For example, if someone sends you ETH, your main account will automatically forward it to your cold wallet, or, automatically sell all the ETH sent to you Become DAI to hold.
Being able to put functional modules directly into the account will produce many, many interesting dApp designs and functions! The operations of user management accounts will become various, instead of the allowed operations being fixed like the current Ethereum protocol.
An interesting possibility of account abstraction is that contracts can pay Gas fees and initiate transactions by themselves. But it's a complex problem, still under development, but once developed, the possibilities are plentiful.
Execution Environments
Developers who do Ethereum application development, the preferred programming language is Solidity or Vyper, both of which have their own strange features, but in terms of practicality, their development ecology is still very good. In current usage, code written in these languages is compiled into more general, lower-level operations for easy interpretation by the Ethereum Virtual Machine (EVM). If you want to understand EVM in depth, you can read this article. Although it's not necessary.
The opcodes (OPCODEs) used by the EVM allow Ethereum nodes to produce the same computation regardless of the computer running the node (this is where the "virtual machine" part comes in). It also makes it easier to customize complex operations such as verifying signatures and obtaining account balances, with just one line of code. Functionality would not be possible without the EVM accurately reading out state and executing state changes.
