Before we can seriously dive into an Ethereum price analysis, we have to know what the heck is going on with Ethereum first.
That’s not an issue though because we are going to cover everything going on with this specific Ethereum hard fork below.
January is the Month of Forks for Ethereum
You’ve probably whiffed some news about the numerous hard forks that are going to be initiated on Ethereum’s protocol. Undoubtedly, the wider crypto market has, as it has led to a major surge in Ethereum’s price action over the last few days:
As we can see from the charts above, Ethereum has already gained a solid 83.47%. We won’t delve into any technical analysis on that though, however, because the purposes of this piece is to look specifically at the events that are taking place on (and with) the Ethereum protocol for the month of January.
Constantinople is the name of the Ethereum hard fork that will be initiated at block height 7,080,000. Recently, an Ethereum developer posted an estimate on Twitter that the hard fork would initiate around 7 a.m. UTC on January 16th, 2019.
We are on track! Constantinople will most likely activate on Wednesday, Jan 16th, probably around 7am UTC. Current average block time is 14.48 seconds. 104407 blocks to go (6975593/7080000).
This is also the hard fork that is supported by the Ethereum core developers.
There are a number of changes to Ethereum’s protocol that will happen after the scheduled hard fork, which many in the community believe will ultimately upgrade the protocol itself.
However, the announcement, which was made by the Ethereum core team on December 6th/7th, 2018, came as a bit of a surprise because the core developers had originally decided earlier in the year (in October 2018) to delay the Constantinople hard fork due to certain technical issues during the trial of the upgraded software on a testnet.
According to the team, however, whatever issues that were associated with the protocol upgrade prior have now been alleviated. Evidence of such has been provided on their GitHub page.
Project Management: Meeting notes and agenda items – ethereum/pm
What Upgrades are Coming With Constantinople?
In this section, we’re going to look at what changes are being made to the protocol.
These changes are all being implemented in the form of ‘EIP’s. EIP stands for ‘Ethereum Improvement Proposal. These work in the same way as BIPs do (Bitcoin Improvement Proposals) on the Bitcoin protocol. They are what they appear to be — proposals. Some of the proposals that get submitted are eventually implemented, most are not.
Below is a list of the EIPs that will be activated on the protocol upon the Constantinople hard fork (they are hyperlinked to their corresponding GitHub entry pages):
- EIP-145 (Bitwise Shifting Instructions in EVM)
- EIP-1014 (Skinny CREATE2)
- EIP-1052 (EXTCODEHASH opcode)
- EIP-1283 (Net Gas Metering for SSTORE Without Dirty Maps)
- EIP-1234 (Difficulty Bomb Delay and Block Reward Adjustment)
Here’s a reliable source for the above information:
In the following segments, we are going to provide a brief summary (ELI5) for each of these EIPs.
EIP-145 (Bitwise Shifting Instructions in EVM)
As defined on the official GitHub page, this EIP-145 is purposed:
“To provide native bitwise shifting with cost on par with other arithmetic operations.”
This is an EIP that will largely impact those interacting with Ethereum on a developer-level, rather than to transfer value or access tokens (at first). Bitwise shifting specifically refers to the opcodes (scripts) that are embedded in each transaction.
For those that are not computer/tech-savvy, each transaction that you send contains scripts in the ‘input’. These scripts provide instructions/mandates for the recipient to spend the output. It is this feature of Ethereum that allows for the usage/functionality of smart contracts on the protocol. Bitcoin also has scripts/opcodes, of course, but as many have stated in the past, Bitcoin is memoryless and thus, Turing incomplete. Therefore, smart contracts with conditional (if, then) functions cannot be launched on the Bitcoin protocol.
This Should Reduce Gas Cost (In Theory)
“ EVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing
SHRusing arithmetics cost each 35 gas, while the proposed instructions take 3 gas.”
I (the author) have not taken the time to extensively review the documentation on this EIP, so I cannot confirm whether this will definitively result in a reduction in gas cost for regular users.
Based on my knowledge of blockchain, I would imagine that this would be contingent upon those (developers) that create contracts in the future. This is because solidity contracts on the protocol are irrevocable.
Slightly More Technical Explanation of EIP-145
Below, is an amazing explanatory piece on EIP145 that accurately conveys the nature of this proposal and what its impact on Ethereum will be:
This article reviews Ethereum Improvement Proposal 145: “Bitwise shifting instructions in EVM” by Alex Beregszaszi and Paweł Bylica, slated for the Constantinople release on January 19th, 2019. Bitwise shifting is nifty. Take the number 5, which is 101 in binary. Shift it once to the left: 1010 (you add a zero on the right).
Again, this will only have an impact for those that are working with Ethereum on the backend of things, rather than the frontend.
Its worth noting that the EIP-145 is not adding bitwise shifting to the protocol, but rather providing instructions on how to do so in a simpler, more efficient manner.
As noted by many others in the community, there is nothing controversial about the integration of this EIP. It is one that provides an inherent benefit, and there is no apparent, legitimate risk being introduced (that has been publicly divulged) to the protocol via this change.
Let’s move on.
EIP-1014 (Skinny CREATE2)
This EIP is unique in that the GitHub entry detailing the proposal was authored by Ethereum figurehead, Vitalik Buterin. It was created and submitted on April 20th, 2018 (could be random; maybe not…).
Below is the specification of this EIP from the GitHub page:
“Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using
keccak256( 0xff ++ address ++ salt ++ keccak256(init_code)))[12:]instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.”
In the motivations sections, Vitalik states:
“Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts.”
What the Hell Does Any of This Mean? (EIP-1014)
If you were left scratching your head after reading the above excerpts, do not worry. This is some pretty dense, technical information and it may not make sense at first, however, there is one keyword that Vitalik Buterin wrote that should tip us off:
If you’ve read the Lightning Network whitepaper (Joseph Poon & Thaddeus Dryja, 2016), then you might remember the section of that paper titled, ‘Spending from an Unsigned Transaction’.
As stated in this section of the Lightning Network Whitepaper:
“The Lightning Network uses a SIGHASH_NOINPUT transaction to spend form this 2-of-2 Funding Transaction output, as it is necessary to spend from a transaction for which the signatures are not yet exchanged. SIGHASH_NOINPUT, implemented using a soft-fork, ensures transactions can be spent from before it is signed by all parties, as transactions would need to be signed to get a transaction ID without new sighash flags.”
The reason why I posted that excerpt from the Lightning Network whitepaper is because:
A) The Lightning Network is a state channel, not a side channel (there is a difference).
B) This principle of a ‘theoretical’ payment or transaction underpins the counterfactuals that Vitalik was referencing in the ‘motivation’ section of this EIP.
What are Counterfactuals? (EIP-1014)
A pretty thorough overview on counterfactuals in Ethereum state channels was written a few months ago by state channels developer, Liam Horne:
To gain a better understanding of ‘counterfactuals’, check out the following excerpt below:
“We are able to achieve these results using what we call ‘counterfactual instantiation’. Explaining this technique requires first defining terminology.
‘Counterfactual’ means something that could be true, but is not. This is an extremely helpful concept when discussing state channels, where we spend a lot of time reasoning about things that could be happening on chain, but are not.
In state channels, we say ‘counterfactual X’ to describe a case where:
X could happen on chain, but doesn’t
Any participant can unilaterally make X happen on-chain
Participants can therefore act as though X has happened on-chain
For instance, imagine a payment channel between Alice and Bob. Alice sends 4 ETH to Bob through the channel, which in practice means that both parties sign a transaction. This transaction could be deployed on chain at any time by either party, but it is not. So we can say ‘counterfactual Alice gives Bob 4 ETH”. This allows them to act as though the transaction has already happened — it is final, within appropriate threat models.’”
EIP 1014 is Probably a Plasma Precursor
For those that have been following Ethereum’s development, specifically its scaling proposals, you probably remember a time when there was a lot of discussion about something called ‘Plasma’.
What is Plasma?
“Plasma is a proposed framework for incentivized and enforced execution of smart contracts whcih is scalable to a significant amount of state updates per second (potentially billions) enabling the blockchain to be able to represent a significant amount of decentralized financial applications worldwide.”
So, essentially, Plasma is to Ethereum what Lightning Network would be to Bitcoin.
Without coincidence, the Plasma whitepaper was authored by Vitalik Buterin and Joseph Poon. If you remember when the Lightning Network whitepaper was referenced above, Joseph Poon was also listed as an author there as well.
Explaining How/Why EIP1014 is a Plasma Precursor
The author believes this to be the case because, as a state channel, Plasma could only operate via the counterfactuals mentioned by Vitalik Buterin in his EIP-1014 documentation.
EIP-1014 seems to be a preemptive safety measure to ensure that the theoretical addresses that are created once the state channels are published remain collision resistant.
What is Collision Resistance?
In public key cryptography, which cryptocurrency (generally) uses, public keys are created from private keys.
You may have read the terms, ‘ECDSA’, ‘SHA256’, and ‘Secp256k1’ when researching Bitcoin.
SHA256, which is the most popular hash encryption type on the Bitcoin protocol, but the other two terms, ‘ECDSA’, and ‘Secp256k1’ are equally as important and must be understood in order to grasp why collision resistance is absolutely necessary for Bitcoin and/or any other cryptocurrency (such as Ethereum) to function in a secure manner.
For those that do not know:
“Bitcoin addresses are generated by hashing the public key of ECDSA using hash algorithms SHA256 and RIPEMD160.”
Its important to note the clear difference between public keys and wallet addresses. Wallet addresses are not public keys. HD wallets and corresponding improvements to the Bitcoin protocol have allowed for the hashing of public keys in order to ‘hide’ them from public domain in order to enhance security.
However, public keys can possibly be discovered if one attempts to send more than one transaction from a given address. This is why it has always been recommended to use different addresses when sending transactions.
Fortunately, most wallets (legitimate ones) have dozens of public keys that have been generated under one wallet address, and the wallet itself will automatically select another public key in order to send funds.
What Does Any of This Have to Do With Collision?
Great question. So, the beauty of ECDSA (Elliptic Curve Digital Signature Algorithms) is that they are the underpinning for how public keys are created. Specifically, for Bitcoin, secp256k1 is used. This ECDSA and the resulting process to create public keys is designed to be ‘collision resistant’.
In a nutshell, this means that a truly randomly generated private key should never hash a public key that already exists.
It also means that there should never be two private keys that hash to the same public key.
The above two statements are what cryptographers and other experts mean when they refer to ‘collision resistance’.
The Importance of EIP-1014 is Obvious if Plasma is Implemented
Since state channels occur ‘in theory’ (yes, this is confusing; but stay with us!), there are technically no addresses that have been created for the transactions.
Thus, when the state channels are settled, the EIP-1014’s purpose will be to ensure that the resulting wallets that are created do not collide with ones that already exist.
The GitHub page for EIP-1052 states that:
“This EIP specifies a new opcode, which returns the keccak256 hash of a contract’s code.”
This is another EIP that primarily impacts developers that are working with Ethereum on the backend.
For those that work with Solidity (programming language for smart contracts on Ethereum), they will need to retrieve the hash of a specific contract. However, in the past, this required hashing the code of the contract itself in order to retrieve this value.
With the addition of this new opcode into the Ethereum protocol, this will no longer be a necessity.
This has the net result of cutting on the amount of gas required to complete the task.
So, overall, this is not a major change to the protocol in any palpable way but its an upgrade nonetheless. Its worth noting that the EIP-1052 is peripherally related to the EIP-1014.
Remember, the description for EIP-1014 was:
“Adds a new opcode at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. Behaves identically to CREATE, except using
**_keccak256_**( 0xff ++ address ++ salt ++ keccak256(init_code)))[12:]instead of the usual sender-and-nonce-hash as the address where the contract is initialized at.”
Given this functionality for EIP-1014, it stands to reason that EIP-1052 will make the former much more efficient as well.
Surprisingly, this has not been discussed on Reddit, Twitter, GitHub, etc. So, perhaps the team or others that are more familiar with the authors of these EIPs will be able to shed light on the intuitive relationship between the two EIPs in the near future.
According to the GitHub page for EIP-1283, the description for the proposal is as follows:
“This EIP proposes net gas metering changes for SSTORE opcode, enabling new usages for contract storage, and reducing excessive gas costs where it doesn’t match how most implementation works.
This acts as an alternative for EIP-1087, where it tries to be friendlier to implementations that use different optimization strategies for storage change caches.”
In many regards, this EIP can be taken at face value.
Below is the ‘motivation’ for the proposal as posted on the GitHub page:
Again, this is an update that is designed with the purpose of making storage in SSTORE more efficient and lowering the overall gas cost for contract implementations.
More information about EIP-1283 can be found in the developer notes below:
all clients already have this information because they need to handle it in case a transaction reverts. That is true — but it’s not cheap, since it requires a journal rollback. And 1283 would make every SSTORE force a roll-back/iteration, whereas 1087 would only require one iteration per transaction.
EIP-1234 (Difficulty Bomb Delay and Block Reward Adjustment)
This EIP is the ‘big’ one that everyone in the crypto community has been talking about.
As the title suggests, this EIP addresses the ‘difficulty bomb’ as well as the ‘block reward adjustment’.
The description of this EIP, per the GitHub link, states:
“The average block times are increasing due to the difficulty bomb (also known as the “ice age”) slowly accelerating. This EIP proposes to delay the difficulty bomb for approximately 12 months and to reduce the block rewards with the Constantinople fork, the second part of the Metropolis fork.”
So, the text is fairly straightforward here at this portion.
There are two major changes that will be implemented on the protocol upon the Constantinople hard fork activation:
A) Delay of the difficulty bomb
B) Reduction in the block reward
What is the Difficulty Bomb?
The current block reward for Ethereum is 3 Ethereum. After the Constantinople hard fork, this will be reduced to 2 Ethereum, an approximate 33% reduction.
As stated in the EIP’s description, the difficulty bomb has been delayed an additional 12 months as well.
This is something that several others in the community have beaten into the ground at this point, so we’re not going to get too far into detail on it moving forward.
The EIPs that are being implemented by Ethereum later this month are largely uncontroversial, salient upgrades to the protocol. Therefore, one should be prone to skepticism about any and all hard forks that arise out of the Constantinople upgrade (and there are a few thus far which will be covered in separate articles).
Once the hard fork activates on the protocol, we’ll go ahead and publish a ‘post-mortem’ shortly thereafter to assess what the overall impact of these changes have been on the Ethereum mining community, developing community, and overall ecosystem.