Top_Header

Metropolis: Byzantine, the First Part of Ethereum’s Planned Hard Fork, Activates October 17



A calendar with the date october 17, 2017 is circled and marked with Metropolis, Ethereum's planned hard fork occurs on this date, making some important changes to the Ethereum blockchainRecently the first part of the Metropolis hard fork launched on Ethereum’s Ropsten testnet. On October 17, the hard fork is scheduled to go live on main net. To stay part of the network, every user has to update their client. But what does Metropolis actually change? Is the hard fork a big hit – or does it disappoint against the high expectations?

On October 17, Ethereum will reach the third stage of its life cycle. After passing Frontier and Homestead, another hard fork will ring in the Metropolis era. The first part of the hard fork will activate some changes, which are not as fundamental as expected, but will significantly change Ethereum nevertheless.


On the Ropsten testnet, the hard fork already happened on September 25. On main net, the upgrade is scheduled to activate at block 4,370,000. When this happens – anticipated during the morning of October 17 – every client must have upgraded. Those which haven’t will be cut off from the network.

The original plan was to transform Ethereum from proof of work to proof of stake. Such a transition would have fired the miners with their graphic cards and replaced them with investors, which “stake” with their coins. A radical transformation of the basic design of Ethereum will not happen with Metropolis. The developers postponed it to the fourth and last phase of Ethereum, Serenity, to keep the Metropolis hard fork closer to the ground.

To coordinate the fork better, it was split in two parts; Byzantine and Constantinople. The first part, Byzantine, is what is in line. But what will it have inside? We will take a look at the changes, one by one, and try to decrypt them.

EIP 649: The Ice Age ends

Currently the “Ice Age algorithm” still increases the mining difficulty exponentially. This can be seen in the statistics of the network; the minting of new ether decreases, while the interval between the blocks increases. Soon, Ethereum will reach a state of slowness, and then it will happens relatively quickly that it will become unusable (see Ethereum: Winter is Coming).

The Ice Age algorithm had only one purpose – to force a hard fork. So, the least the upcoming Byzantine hard fork has to do, is to deactivate the difficulty bomb. This happens with EIP 649. To be more concrete, EIP 649 postpones the Ice Age for 18 months and reduces the block reward from five to three ether. This aims to prepare the system for the upcoming transformation to proof of stake which will further reduce the reward.

But, of course, EIP 649 is not the most prominent part of the hard fork. There are seven important changes, which are the result of long discussions of the Ethereum developers. They are very technical and it is not obvious what benefit Ethereum and its users get from them.

The Byzantine hard fork touches five areas of Ethereum; Performance, Light Clients, Mining, Privacy, and Contracts.

Performance

EIP 98: More parallelization with less state root calculation

In Ethereum, you have a so-called ‘state root’; a special kind of Merkle tree which builds some kind of proof of the whole state. The state of Ethereum contains all active accounts and contracts. With the state root, you can validate entries of the state. The state root is usually recalculated after each transaction.

EIP 98 eliminates the calculation of the state root after each transaction. This allows to parallelize the calculation of the state root and to reduce the number of Merkle roots calculations. This will help to reduce the required computer power of Ethereum. In the future, EIP 98 can help to not just parallelize the state root calculation, but also the processing of transactions. Which will further reduce the required computer power.

The disadvantage of EIP 98 is that fraud proofs, with which light clients can validate transactions, need to consist of a whole block. Since blocks in Ethereum are relatively small, this problem seems to be manageable.

Light Clients

EIP 658: Light Clients can check if a contract was executed

With EIP 98 transactions need no longer to contain a state root field. EIP 658 replaces it with another field, which stores information regarding whether a contract was executed completely and correctly. This allows for light clients, which do not sync the whole blockchain or load the whole state, to be able to detect if a operation with a contract they deployed or interact with was successful. As it stands at the moment, light client are not able to do this independently without help.

The change of EIP 658 can help to allow light clients to better interoperate with contracts without the need for trusted third parties.

Mining

EIP 100: Adjustment of the reward to uncles

Beside the reduction of the reward by EIP 649, the EIP 100 also affects mining. Its topic revolves around the so-called ‘uncles.’ Like with Bitcoin, two miners on the Ethereum network can find a block nearly at the same time. In this case, two blocks exist for a short time, before the network sorts out one block as invalid. Then the chain with this block dies. These blocks are called “orphans” with Bitcoin and “uncles” with Ethereum. Other than with Bitcoin, with Ethereum the ‘uncles’ get a little block reward. This aims to make mining more equitable.

However, the reward of the uncles had an unwanted side effect. In some situations, it was possible that due to many uncles the actual block reward has been higher than the planned five ether. A new formula for the adjustment of the difficulty, which now also takes uncles into account, fixes this bug.

Privacy

EIP 198, 212, 213: zk-SNARKs are coming to Ethereum!

Maybe the most important and prominent part of the Metropolis hard fork is a bundle of three EIPs; 198, 212 and 213. These EIPs will allow some complex cryptographic operations inside of a contact, like RSA, and the deployment of precompiled contracts on certain elliptic curves. These changes will enable without other things zk-SNARK zero knowledge proofs.

Zk-SNARK proofs have been developed by the Zcash team. They allow to hide transaction details as well as other state changes by contracts. The recipient of a transaction can still validate if it was correct. But the content of the transaction does not need to be made public. A transaction with zk-SNARKs will cost much more gas than the traditional transactions. But it will bring the long-needed privacy to Ethereum.

Contracts

Most changes of the Byzantine hard fork affect contracts. Since contracts are the most important unit of operations for Ethereum, these changes might have a large effect on the ecosystem.

EIP 214: More secure call of other contracts in a contract

It can happen that a smart contract calls another contract while working through its tasks. For example when it wants to receive some data managed by another contract. Until now the inner contract which is called has priority. It is even possible that this contract changes the state of the outer contract. This makes the interaction of contracts complicated and sometimes insecure. For example, it was the cause of the infamous DAO hack.

With the introduction of a new opcode STATICCALL EIP 214 will prevent these problems. The new code allows a contract to call another contract without allowing it to change the state. This will make the construction of more complex smart contracts more secure.

EIP 211: Better return of arbitrary data in a contract

Another problem of contracts right now is the return of data. It is ok if the contract knows the size of the data. Arbitrary data however is a problem which makes things very complicated and expensive. With the introduction of the new opcodes RETURNDATASIZE und RETURNDATACOPY EIP 211 allows to flexibly return arbitrary data.

EIP 206: Cheaper revert of a state

EIP 206 also introduces a new op code. This one is called REVERT. It provides a method to stop the execution of a contract and to revert a state change. Without this code you need to do complex and expensive hacks to stop the execution of a contract. With the new code it is not just cheaper, but it is also possible to return a reason.

EIP 206 is the last change of our overview on the Byzantine hard fork. The changes seem to be very technical and hard to assess for a layman. It is about the detail.

While zk-SNARKs might be technically the most complex area, it is relatively easy to understand what you can do with it. Ethereum can achieve the same privacy as Zcash, and not just for transactions, but also for contracts and tokens. That’s huge news. Further, it might be able that the state root is calculated faster after the fork, that light wallets can interact better with contracts, and the new op codes might allow to securely build more complex contracts on Ethereum.

A dirty hard fork, which results in a permanent split of the chains and the communities, is rather unlikely with Metropolis. Other than the DAO hard fork, which ended with the birth of Ethereum Classic, the community seems to fully consent to Metropolis. At least because this hard fork is not a reaction to make bad things unhappen, but it has been planned from the beginning. The ‘Ice Age,’ which is still active, makes the hard fork inevitable anyway.



Source

Comments

Bottom_Header
Bottom_Header

Related posts

error: Content is protected !!