Ethereum Ice Age

Ethereum Ice Age is considered to be an external factor that can affect decision making on other application on Ethereum like ZoE (Zerocash Over Ethereum) and several others. Basically, there is a feature in the protocol that makes Ethereum blockchain blow up after some amount of time. This was introduced in Ethereum because in Bitcoin, it was observed that in due course of time, huge pressure is developed towards the default protocol. Learning by the example, Ethereum team decided to avoid ending up into similar situation of getting default pressure in absence of change in protocol. So, it was decided to make the protocol such that, the Ethereum blockchain blows up on its own after 2.5 years.

Ethereum Ice Age is a difficulty adjustment process that was put into place (in November, 2015) to ensure that everyone has incentive to move to the new blockchain. It is programmed to raise difficulty level exponentially. It will be difficult for miners to keep up with the increase of difficulty level. Block time will be increased and will lead to blockchain freeze. This is why it is named as Ice Age.

However, the blockchain is not going to blow up literally. The reason to consider this feature was to ensure that the community must coordinate on some change after certain period. It means, Ethereum blockchain community don't have to take decision on whether to change or not (as change is a must) but they should take decision on what to change 'A' or 'B'?

At present, Ethereum works on 'Proof of Work' concept. It means to perform any transaction or produce a new coin, computational work is needed. It keeps the entire ecosystem moving. Engineers of Ethereum are planning to change the present 'Proof of Work' concept to 'Proof of Stake' (Casper) believing it will make decentralized system more reliable and secure. Work on Casper is still in progress while Ethereum blockchain is moving closer to difficulty time bomb. It’s high time for Ethereum to take a decision on change in the system else we should expect 'Ethereum Ice Age' to start in next 3-6 months. At present, block time is about 14.45 seconds and after three months it can be about 15.8 seconds and after six months it can be about 28 seconds and keep going up (corrections in data are welcome). So, to delay the Ice Age, Metropolis hard fork is a must.

Metropolis

In Jan 2017, DigixGlobal, Singapore organised a meetup on Ethereum. Vitalik Buterin gave a keynote presentation on Metropolis, the upcoming planned protocol improvements for Ethereum. Metropolis was in top of roadmap for Ethereum for quite some time but because of distraction created by DOS (Denial Of Service) attack in June 2016, engineers had to detour their priorities towards improving core client efficiency, focus on securities and making sure all of the holes of the clients are fixed. Since then, Ethereum Virtual Machine (EVM) improved by 40%, and it's in most efficient state reading, fast synching improvements etc. Now, overall Ethereum clients are working fine and they are moving forward on implementing the Metropolis hard fork.

Vitalik, tabled few major goals to be achieved with Metropolis through his presentation. Possible list of Ethereum Improvement Proposal (EIP) that would be rolled out in a Metropolis release are:

EIP 86 (Principle of abstraction)

Goal: Try to make the protocol itself as simple as possible and to make Ethereum Virtual Machine (EVM) do most of the work.
Allows sending unsigned transactions from a special “entry point address”.
Contract address based on code hash (allows sending to not-yet-existent contracts)
Any account in the call execution chain can pay for gas instead of only the account that sent the transaction. A recipient, or middle account, could pay the gas cost. It helps anonymization, instead of needing to use only one account to pay for gas.
It has privacy benefits.

EIP 98 (removal of intermediate state roots)

Goal: Make it easier to process transactions in parallel.
Reduces light client functionality to a slight extent.

EIP 96 (EVM-ification)

Goal: Try to make light clients more secure.
Moves block hashes and state roots into the state.
Allows for some client simplifications
Direct hash-links between distant blocks allow for much more secure light clients.

EIP 100 (target block time including uncles)

Goal: Security upgrades
Reduces incentive for large mining pools to deliberately mine uncles.

EIP 101 (big integer precompiles)

Goal: Make it easier to verify certain types of cryptography. Currently supported Cryptography in Ethereum is elliptic curve cryptography. But other applications use RSA which is currently computationally inefficient to verify in Ethereum. Introducing various optimization to try make that work faster.
Useful for verifying RSA
Likely only modular exponentiation required.

EIP 116 (STATIC_CALL)

Idea: A way of calling a contract to get just information without changing state or any other security measures. It is special kind of opcode to ensure that it is just for information extraction and not changing anything. It's still under consideration.
The caller and descendants can only read state, not write to state.
Useful for functional programming features.
Increases safety.

EIP 195 (Pure call)

Idea: It is even more static version of STATIC CALL. It can’t either read or write.
Takes two memory slices as arguments
code
input data
Performs the computation and returns. No sub-calling, state reading or state writing is allowed.
Useful for Casper validation code and functional programming feature.

EIP 140 (throw opcode)

It's more efficient and cleaner way of doing exceptions.
It throws an exception without consuming all remaining gas.
Possible extension: pushes an error code onto the stack.

EIP 141 (invalid opcode)

Not a protocol change.

EIP (Ethereum Improvement Proposal)

Ethereum is an open source project. It has a defined system of 'Ethereum Improvement Proposal' (EIP) at Github to track and discusses new ideas for the protocol. Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.

EIP has four status:

Draft - an EIP that is open for consideration

Accepted - an EIP that is planned for immediate adoption, i.e. expected to be included in the next hard fork (for Core/Consensus layer EIPs).

Final - an EIP that has been adopted in a previous hard fork (for Core/Consensus layer EIPs).

Deferred - an EIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.

After all, Metropolis release has its own timeline but the uncertain variable is the number of features to be included in the release. If there is a time crunch, Metropolis may be released with only the most important features in the list. Rest of them may be considered for fork after that or may be six months after the Metropolis release. It is evident Metropolis upgrade will bring some aspects to Ethereum that the community has been looking for a while now.

If you like the article, please follow us @ether_world (Twitter) and Ethereum Blockchain Technology (Facebook) for more updates, technical blogs and general discussion on Ethereum and blockchain technology.