Eth2.0 revolutionizes Eth1.0 road: monetary policy, stateless and account abstraction, etc.
Editor's Note: This article comes fromCrypto Valley Live (ID: cryptovalley)Editor's Note: This article comes from
Crypto Valley Live (ID: cryptovalley)
, Author: Ivan Martinez, reprinted with authorization by Odaily.
The most well-known changes brought by Eth2.0 are PoS (proof of stake) and sharding, but it also has many other changes that are inspired by improving the current Ethereum.
secondary title
Since the first genesis block of BTC was born 11 years ago, it has inspired many people to further study and study blockchain and cryptoeconomics to understand how to optimize and improve.
Starting with PoW (Proof of Work), we have learned that protocol security is crucial for cryptocurrencies. Incentivizing people to have more "skins" (expensive mining hardware) in the game works really well. Despite the possibility of "selfish mining," PoW does an exceptional job of securing the BTC network.
When Ethereum launched in 2015, it introduced the concept of a "universal" blockchain, which allowed anyone to build applications on the network that interacted with ETH and various tokens. These applications opened the door for the development of decentralized finance (DeFi) and grew into financial products with more than $1 billion in collateral assets.
secondary title
The problem of ETH1.X expansion
Today, Ethereum has experienced 5 years of development, and its amazing growth rate has helped the industry realize its bottlenecks and areas that can be improved.
When Ethereum encountered difficulties in its rapid growth in 2017, several so-called "Ethereum Killer" blockchain platforms began to rise and try to "beat" ETH. However, these "killers" all focus on increasing transactions per second by sacrificing weak security, or removing transaction fees in a patently misleading (and confusing) way. But none of these are “solutions” to Ethereum’s flaws.
In order for Ethereum to truly improve, everyone involved needs to take a step back from the existing system and think from a fresh start. We can take full advantage of Ethereum’s strengths while eliminating many of its weaknesses.
Note: In the following, when I refer to "state", I mean the global, persistent data that Ethereum keeps forever, such as account information, transactions, and smart contract state (such as token balances).
Enter Eth2.0
Since many improvements in Ethereum 2.0 (Eth2.0) will inevitably break the existing Ethereum chain (Eth1.0), these changes will be built on the Eth2.0 chain while "plugging" the existing Ethereum chain into 1 shard of the new system. In this way, Eth2.0 will not need to be complicated by upgrading the existing Eth1.0 network, and the current Eth1.0 network will also function normally while benefiting from the improvements of the new system.
Monetary Policy
This article will explore the major changes that Eth2.0 brings that people may not know about, and how these changes make Ethereum the universal platform for the (decentralized) world.
And how they drew inspiration from the common ground of helping Ethereum get ready for (decentralized) fun.
Monetary Policy
While many ETH holders believe that Ethereum is overpaying for network security, lowering issuance could lead to a decrease in hashrate and security as miners are not very profitable. So reducing the issuance of a PoW blockchain is difficult because it may have unintended side effects on blockchain security. Bitcoin (for the most part) doesn't have this problem because most of its mining reward changes are predictable over the long term.
One of the biggest goals of Eth2.0 is to transition to Proof of Stake (PoS), which means doing away with expensive ASIC or GPU miners. Such a huge amount of calculation and power consumption will be replaced by low-cost standard computers that only handle the basic functions of Eth2.0 nodes, such as block propagation and synchronization. When it comes to maintaining network security, the cost is much lower! In addition to investing 32 ETH before becoming a validator.
By reducing the overall security cost, token issuance can be reduced to between 0%-1%, depending on how many validators there are in the network (that is, how much ETH assets are pledged in the network). This way, the distribution can be precisely designed for optimal security!
image description
Circulation and validator rewards depend on how much security funds are required
In addition to reducing issuance, Eth2.0 also intends to use a strategy called EIP1559 to redefine the gas price in the fee auction market and transaction fees. You don't need to understand how it works, just know that most of the fees will be burned in this model. Although through EIP 1559, users pay lower fees, but there will be multiple shards in Eth2.0, so the overall fee usage/destruction in Eth2.0 will be greater than the current Ethereum fee.
Coupled with the extremely low issuance rate (<1.0%), the burning of fees may cause Eth2.0 to have a net negative asset issuance, which means that the assets destroyed will exceed the new issuance! This will make ETH more scarce and the cost of attacking PoS networks will be higher.
The goal of consensus algorithms such as PoW or PoS is to keep blockchains secure and decentralized, and the incentives for maintaining network security differentiate cryptocurrencies from simple ledgers. This incentive attracts miners/validators to provide security to the network. Eth2.0 tries to achieve minimum viable issuance (MVI) in terms of miner funding incentives.
Statelessness
When people talk about Ethereum and its state size, you've probably heard of "state bloat". This means that paying a gas fee once will make your data permanently stored on the Ethereum blockchain, resulting in an infinite, ever-growing state with even a lot of useless data. The state is "inflated" in storage space, which means that Ethereum nodes require more storage or higher performance hardware as the network is used. In the long run, this increases the barrier to entry for an Ethereum node to run, and whenever the block gas limit increases, state growth becomes a bigger problem.
Eth2.0 (and in the future Eth1.x) will move towards being stateless, meaning light (stateless) nodes will be able to verify all transactions and all parts of the state without actually storing any state. Statelessness allows light clients to exist in various states/statelessness, each requiring a different specification, making nodes more accessible. When the node resources are more than stateless mode but less than full state mode, it can run in half state mode.
image description
Network topology diagram under the stateless paradigm
This is very important for sharding! Since each shard has its own unique state, validators in Eth2.0 will need to perform state changes (transactions) on the state of the shard they validate. The stateless protocol allows the verifier to switch the shard that needs to be verified (because the verifier will be randomly assigned to a shard for verification), without downloading the entire state of the shard, but only downloading the representative binary merkle tree (much smaller in size). The more shards, the more endless state growth, there will always be exchanges or blockchain browsers that maintain all shard chain states/data regardless of cost to provide accurate distribution services, and are therefore incentivized.
This opens the door to software "state providers" that provide the state portion of transaction modifications to validators so they can easily complete state changes. State relayers help move the storage-intensive parts of disk I/O and validation to another entity entirely. This opens the door to interesting incentive schemes (state-based incentives, which used to be a research problem in Ethereum), and benefits validators since they no longer need to hold the state of the entire shard. However, they can still verify that the state received from the relayer is correct because they can compare the received information with the synchronized state tree.
account abstraction
There are currently two types of accounts in the Ethereum protocol: external accounts (users) and contract accounts. Only external accounts can initiate transactions, and only the owner of the account is allowed to modify their account state. Currently, meta transactions exist, but these rely on relay networks to pay for gas, such as GSN.
Eth2.0 tries to abstract these two account types into one, so that user accounts and contract accounts cannot be distinguished in the network. Of course smart contracts still exist, but this opens the door for Ethereum to act as a relayer for meta transactions itself. Signing transactions yourself and broadcasting them will no longer be the only way to interact with the network.
You can also operate ordinary accounts like smart contracts, for example, send ETH received in the main account directly to the cold wallet, or even send arbitrary ETH to your account, which will automatically sell ETH to buy DAI.
Building functionality into accounts opens up even more room for DApp design! The handling of user-managed accounts will no longer resemble a well-defined set of operations currently defined in Ethereum.
An interesting possibility of the account abstraction is that smart contracts will be able to pay their own gas fees, or be the origin address from which transactions are sent. This is a complex problem that still needs to be worked out, but new creative possibilities will emerge after this change!
execution environment
For Ethereum developers, the main language they use is Solidity or Vyper, each of which has its own characteristics, but both can well meet the needs of the development ecosystem. Currently, these languages are compiled into more general low-level operations that the Ethereum Virtual Machine (EVM) can understand. If you want to know more about EVM, you can refer here. But not required.
EVM uses operation code (OPCODE) to help Ethereum nodes generate the same calculation results, regardless of the computer running the operation code (hence the name "virtual machine"). It also customizes complex operations (such as verifying signatures or querying account balances) with just one line of code. The ability to read and modify state normally would not be possible without the EVM.


