The Constantinople Hard Fork is scheduled to take place on the Ethereum Mainnet in mid-January 2019, at block 7,080,000. In this post, we discuss the upcoming changes to the protocol and describe how POA Network, Consensys, and Compound Finance are collaborating to develop Mana-Ethereum, a new open-source Ethereum client.

This week the Mana-Ethereum project celebrated a milestone — a full sync with the Ropsten testnet! This is important because Ropsten is currently running Constantinople, a new hard fork with a planned January release on the Ethereum mainnet. This sync means that Mana-Ethereum is compliant with the Constantinople specifications, and will enable us to run a fully functional node in the future on the Ethereum mainnet.

Constantinople is an intentional upgrade — it’s been a part of the Ethereum roadmap since the beginning. It is the second part of a two-part update called “Metropolis.” Part one, “Byzantium,” was integrated in October 2017.

Constantinople will introduce features to increase network efficiency, shrink the transaction costs of some smart contracts, and reduce mining rewards from 3ETH to 2ETH, further preparing the network for a transition to Proof of Stake validation that will come with the “Serenity” (also known as Casper) hard fork.

After a testing period on Ropsten, which involved some initial issues that have since been sorted, Constantinople is now scheduled for mainnet release at block 7,080,000.

Thanks to a collaborative effort from Consensys, Compound Finance and the POA Network, we are preparing for Constantinople as we develop our new Ethereum client, Mana-Ethereum.

Ethereum hard fork history — Summary including EIPs available here.

Mana-Ethereum

Mana-Ethereum is an Ethereum client written in Elixir. An Ethereum client implements the Ethereum Virtual Machine, allowing a node in the network to interact with the Ethereum blockchain. The client must precisely follow the specifications described in the Ethereum Yellow Paper in order to sync with the blockchain and verify block rewards, smart contracts, and transactions. When a hard fork happens, an Ethereum client must update its code to sync with the new chain specifications.

Every node on the network runs an Ethereum client. Geth and Parity are used by a majority of nodes, but there are additional clients that diversify the ecosystem and help verify the protocol. These clients are written in a variety of languages (such as C++, Python and even JavaScript) to take advantage of the properties and unique abilities of each language to codify the EVM.

We are choosing to implement Mana-Ethereum using Elixir for several reasons.

Speed: Elixir code runs inside lightweight, isolated processes, which allows thousands of processes to run at the same time. This concurrency creates a great deal of efficiency for all operations, including testing. Currently, we can run all state tests in less than 10 minutes. Scalability: Processes in one machine in the network are able to communicate with processes running on other machines in the network. This allows for an efficient, distributed environment that can quickly scale as needed. Elixir is known as a solution for high-traffic systems. Applications like Discord have used Elixir to handle 5 million concurrent users and process millions of events per second. Resilience: Fault-tolerance is built into Elixir. Supervisor and worker processes monitor the network for crashes to prevent system-wide failures. “Hot-swapping” allows code to be changed out without stopping the system. Time Tested: Although Elixir is fairly new, it runs on the Erlang Virtual Machine, a platform that was first developed for distributed computing and telephone networks more than 30 years ago. Efficiency: Elixir supports concise, easy-to-maintain code. Applications are highly modular, which is useful for a protocol with many different moving parts and wide-ranging functionality. Elixir is also designed to be more readable than Erlang. This creates fewer bugs and a faster ramp-up time for new developers.

We continue to make progress on Mana-Ethereum as we are passing 100% of the Ethereum Common tests and are fully synced on Ropsten. To plan for Constantinople, we implemented all of the required EIPs (Ethereum Improvement Protocols). Here’s how it went.

Preparing for Constantinople

Preparing for a planned hard fork is a challenge as each EIP included in the update must be precisely implemented. We designed Mana-Ethereum for easy branching and code modularity, which was useful when preparing for Constantinople.

Constantinople introduces 5 new EIPs to the Ethereum platform.

EIP 145: Bitwise shifting instructions in EVM: This EIP introduces new operators for shifting values on the EVM stack. Previously, bitwise shifting required the use of several arithmetic operations, which resulted in longer processing time and higher costs. For example, a shift left (SHL) process using arithmetic requires 35 gas. The new implementation only requires 3 gas to produce the same result. EIP 1014: Skinny CREATE2: EIP 1014 supports a new way to create contract addresses that do not yet exist on-chain. It allows parties to agree on an address before it is created. This improvement supports state channels, where users can conduct a series of off-chain transactions before updating the EVM state, creating opportunities for fast, low-cost transactions. EIP 1052: EXTCODEHASH Opcode: This new operation code allows contracts to retrieve the code hash of another contract rather than fetching the entire contract code. In some cases, a contract may only need to see if another contract exists, or check if it meets certain criteria, and does not need the entire code. This functionality lowers costs and improves efficiency when referencing other contracts. EIP 1283: Net gas metering for SSTORE without dirty maps: This EIP changes the gas cost for the SSTORE EVM operation, reducing the cost for multiple storage operations that occur within a transaction. Many smart contracts will see a gas reduction from this change. EIP 1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment: This EIP delays the difficulty bomb, which is meant to increase mining difficulty, for approximately 1 year. Block times will remain at approximately 15 seconds. To account for the difficulty delay, miner rewards will be reduced from 3ETH to 2ETH per block.

Most of these changes will not have large impacts on blockchain users. Smart contract developers will be able to take advantage of new functionality and lower gas costs for some operations. These incremental improvements are designed to maintain network functionality and prepare for a bigger shift when ‘Serenity (Casper)’ establishes Proof of Stake validation.

The biggest network impacts may result from all nodes updating their clients. Many nodes are currently running older versions of Ethereum clients; the Constantinople hard fork will require that all nodes update to the latest client versions. This should result in a faster and more secure network.

Our Experience

During our implementation, we found that most of the EIPs were straightforward to work with. Compared with the Byzantium update, which introduced zkSNARKs among other things, the Constantinople updates were easier to implement.

One challenge we faced was related to SSTORE, the storage operation modified by EIP-1283. Prior to this implementation, we were overwriting initial storage values during transactions because the initial value was not needed to calculate gas costs. However, this EIP introduced the need to access 3 values to calculate gas: the initial value in storage before transaction execution, the current value, and the new value.

To overcome this obstacle, we created a storage cache for use during transaction execution. We can now access the initial value from permanent storage (the Merkle Patricia trie) and the current value from the storage cache. The subsequent values are only written to permanent storage after a transaction is successful.

This caching process helped us implement EIP1283 and presented an opportunity to optimize our client. Our execution speed has increased by 30% with the addition of a storage cache!

What’s next for Mana-Ethereum

Our focus continues to be on implementing a fully-functional, production-ready client. The Constantinople sync was a major milestone, and we are now working towards JSON-RPC block processing and a warp-sync implementation.

One of our main objectives with the Mana-Ethereum project is to create an Ethereum client that is open-source, well documented, and composed of clean, modular code. We are in the process of building that client from the ground up, and we will continue to share progress as we move towards launch.

Connect with us:

Website: https://poa.network/

Twitter: https://twitter.com/poanetwork

Medium: https://medium.com/poa-network

Forum: https://forum.poa.network/

Reddit: https://reddit.com/r/poa