The most publicized changes of Ethereum 2.0 are staking and sharding, but there are a whole plethora of changes it consists of that were inspired from improving Ethereum.

What we’ve learned since Bitcoin & Ethereum

Bitcoin launched over 11 years ago, since its genesis block it has inspired so many people to learn more and research further into blockchain design and cryptoeconomics to see how they can be improved.

Starting with PoW, we’ve learned that protocol security is of paramount importance in a cryptocurrency. Incentivizing people to have more skin in the game (with expensive hardware) works incredibly well. While there is some elbow room for “selfish mining”, for securing Bitcoin’s network PoW has been performing exceptionally well.

When Ethereum launched in 2015, it introduced the concept of a “general-purpose” blockchain that allows anyone to build applications on the network that interact with ETH and various tokens. These applications opened the door for decentralized finance (DeFi) to mature and grow to hold over $1 billion in collateralized assets. I have another blog post about how DeFi has grown to really be a real, useful service on Ethereum.

Issues Preventing ETH1.X from Scaling

Now that Ethereum has been released into the wild for almost 5 years, the phenomenal growth it has gone through has helped the industry notice what its bottlenecks are and what can be improved.

When Ethereum was having trouble with its sudden growth in 2017, several “Ethereum killers” rose up to “beat” ETH. But these “killers” mainly sacrificed weaker security for higher transactions per second, or advertise no transaction fees when it was clearly misleading (and confusing). But none of these were “solutions” to the flaws that Ethereum needed to improve on.

For Ethereum to be truly improved, everyone involved needed to take a step back from the existing system and start from a clean slate. We can take the best parts of Ethereum while clearing out a lot of its flaws as well.

Note: For future reference, when I mention “state”, I refer to the global, persistent data Ethereum holds forever, such as account information, transactions and smart contract state like token balances.

Enter Ethereum 2.0

Ethereum 2.0 is the largest open source effort ever in the cryptocurrency space, aiming to deliver a brand new system that can fulfill the intended goals of Ethereum and more. You may have heard of Casper (proof of stake) and Sharding, but there is so much that encompasses the goals that Ethereum 2.0 will consist of.

Since a lot of the improvements going into Ethereum 2.0 (Eth2) would definitely be breaking changes for the existing Ethereum chain, these changes will be built out on the Eth2 chain, with the existing Ethereum chain being “plugged” (into a shard) in the new system. This way Eth2 will not need to be complicated by upgrading the existing network, while the Ethereum network will operate normally with all the benefits the new system intends to bring.

This post will go over what are the major changes being made with Eth2 that people might not know about and how they were all inspired from the common grounds of helping Ethereum be ready for when the world gets in on the (decentralized) fun.

Monetary Policy (Security Funding)

The monetary policy of a cryptocurrency is more important than most people think! For coins that use issuance (minting new supply in block rewards) to attract miners and hashrate, the less issuance it takes to fund its security, the better. We can already see this with BTC having the most secure chain while also maintaining the lowest issuance rate out of the top 20 coins. Currently, BTC has 3.8% yearly issuance, which is pretty low considering Ethereum has ~4.5% issuance (if ETH mirrored BTC’s halving policy it would be much higher).

While a lot of Ethereum holders think ETH is overpaying for security, lowering the supply issuance might cause a drop in hashrate and security, due to miners not being as profitable. This makes it difficult to lower issuance in PoW as there may be unintended side effects to the chains security. Bitcoin doesn’t have this problem (for the most part) since most of its mining reward changes are predictable in the long term.

One of the largest goals of Ethereum 2.0 is to transition to Proof of Stake (PoS), which means the removal of expensive mining hardware like ASICs or GPU rigs. This intense computation and power usage will be replaced with much cheaper standard computers that just handle what the Eth2 node processes like block propagation and syncing. Much cheaper cost for those who secure the network! Besides having to stake 32 ETH to join as a staker.

With this overall security cost reduction, issuance can now lowered to between 0%-1%, depending on how many people are part of the network. This way, the issuance scales to exactly how much it needs to pay for optimal security!

The amount of issuance and rewards scale with how much security funding is needed.

On top of this issuance reduction, Eth2 intends to replace the fee auction market and gas prices from transaction fees with a different strategy called EIP1559. You don’t need to understand how it works, but just know the majority of fees spent will be burned in this model. While users will generally pay less fees with EIP1559, there will be multiple shards in Ethereum 2.0 so overall fee usage/burning in Eth2 might be greater than the fee usage in current Ethereum.

Combined with an extremely low issuance rate (<1.0%), fee burning might cause Ethereum 2.0 to have a net negative issuance, meaning more supply would be burned than what is being created! This would lead to ETH becoming more scarce, making the cost to attack the PoS network more expensive.

The goal of a consensus algorithm (like PoW or PoS) is to keep the chain secure and decentralized, and the incentive to secure the network is what separates a cryptocurrency from a simple ledger. That incentive makes sure miners/stakers provide security to the network. What Ethereum 2.0 is seeking to do here in terms of funding miners is Minimum Viable Issuance (MVI).

MVI means the chain continuously maintains the least amount of issuance required for security to be guaranteed. The low issuance combined with the burning of fees gradually makes the attacks more expensive (since ETH becomes more scarce), reducing the chances of a mass attack on the network.

Statelessness

You may have heard of “state bloat” when people have been speaking about Ethereum and its state size. This refers to an issue that a one-time gas fee payment lets your data have permanent residence on the Ethereum blockchain, leading to an unbounded, ever growing state where a good chunk of the data might not even be used. The state “bloats” in storage size, meaning Ethereum nodes require more storage or better hardware linearly as the network ages. Over the long run this restricts who is capable of running an Ethereum node and the state growing becomes more of a problem every time the block gas limit is increased.

For ETH2 (and soon ETH1), the goal is go stateless, meaning that light (stateless) nodes will have the capability to verify all transactions and verify all parts of the state, without actually holding any of the state. Going stateless allows for light clients to exist in a spectrum of stateful/statelessness that each require differing specs, making nodes more accessible in general. If you have more resources than what a stateless node needs, but not enough for a full stateful node, then you can run an in-between semi-stateful node.

If you want to understand statelessness further, watch this talk from ETHDenver!

Network topography with a stateless paradigm.

This is incredibly important for sharding! With each shard having its own unique state, validators in ETH2 will be expected to perform state changes (transactions) on the state of the shard they validate for. A stateless protocol makes it so validators don’t have to download the entire state of a shard whenever they switch between shards, just the binary merkle tree that represents the data (which is much smaller). The more shards, the more endless state growth, and there will always be services like exchanges or block explorers that are incentivized to keep all the shard chain state/data, and delivery it accurately, regardless of the costs.

This opens the door for software that serves as “state providers” that provide the parts of state that a transaction changes to validators, so they can perform state changes easily. State relayers help move the disk I/O and storage intensive parts of validating to a different entity entirely. This opens up the door to interesting incentivization schemes (for state, which has been an issue for Ethereum) and benefits validators greatly as they no longer need to hold onto the entire shard state. Yet, they can still verify the state they receive from the relayers is correct since they can compare the info they receive with their synced state tree.

Account Abstraction

Currently within the Ethereum protocol there are 2 types of accounts, external accounts (users) and contract accounts. Only external accounts are capable of starting a transaction, and only a user making a transaction under their own name is allowed to modify the state of their account. Currently, there are meta-transactions, but these rely on a relayer network to pay gas like the GSN.

For Ethereum 2.0 the goal is to abstract these 2 account types into 1, making user accounts and contract accounts indistinguishable from the network. Contracts will still exist of course but this will open up the door for Ethereum to serve as the relayer itself for meta-transactions. You signing a transaction for yourself and broadcasting it won’t be the only way to interact with the network.

You could also have your normal account operate as a smart contract would, maybe sending ETH that your main account receives straight to your cold storage wallet as an example, or even having any ETH sent to your account auto-sell for DAI.

Functionality could be built into accounts, and this opens up so much more for dapp design and functionality! The handling of user managed accounts would no longer be a clearly defined set of operations like they are currently in Ethereum.

One interesting possibility with account abstraction is that contracts would be able to pay for their own gas, or be the origin address who sent a transaction. It’s a complicated problem so there is still work being done towards it, but the possibilities of what can be built after this change flourish!

Execution Environments

For anyone developing on Ethereum, their main choices of language are Solidity or Vyper which have their quirks but they serve the development ecosystem very well for what it needs. Currently, these languages are compiled down to more general, lower level operations for the Ethereum Virtual Machine (EVM) to understand. If you want to get a deeper understanding of the EVM, read here. You shouldn’t need to though.

These operation codes (OPCODEs) are used by the EVM to help Ethereum nodes generate the same computational result regardless of what computer is running it (hence the “virtual machine” part). It also makes it easy for custom complex operations like verifying signatures or getting an accounts balance to be one line of code away. Features that normally wouldn’t be possible without the EVM there to read from and assign the changes to the state properly.

While the EVM has served as a great foundation for the entire smart contract ecosystem, even on other chains, it would be great if any application on Ethereum had the ability to use any run-time it’d like. The chain shouldn’t force its own state transition rules (like the EVM) onto everyone else, execution should be more open-ended. This is where Execution Environments come in.

Execution Environments (EEs) allow any kind of state transition to be built into the protocol directly (using WASM), this allows us to entirely abstract the way a transaction is processed from the rest of the system. There could be an EE specifically made for handling ZK rollup or private transactions, or an EE for UTXO modeled transactions (like BTC). There could even be a token specific EE that can be used for all tokens, instead of having to upload the same code for every token in existence. And of course, the existing EVM will be replicated into an EE called eWASM to maintain support for the current ecosystem.

Every dapp on ETH1 needs to be designed with the EVM being taken into large consideration, all of the limitations of Ethereum’s state transition function (the EVM) bottleneck the entire system with it. With EEs, this bottleneck will be no more and entirely new types of dapps could be built that take great advantage of open-ended their reliance on the protocol becomes. If you’d like to learn more, here’s a great podcast from EthHub and Will Villanueva. Here’s the latest updates on progress as well.