Constantinople Hard Fork - Block 7 280 000
Delay Reason
Auditing Company found REA vulnerabilities in the reduction in cost to the Storage opcodes.
https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9
https://github.com/ChainSecurity/constantinople-reentrancy
Forks
One set of nodes upgrade to the new software. Those that do not upgrade are sometimes compatible(Soft fork)
or there are changes in the code that cause them to no longer be compatible to the newly upgraded nodes(Hard Fork).
Need for forks (Networks need to update and upgrade)
Become a problem when the community does not come to consensus about the fork(Example DAO fix)
Why Hard Fork vs Soft Fork
Hard fork not backwards compatible
Allow introduction of updates that make a greater impact on the system as a whole.
Soft forks are typically for minor updates to the code.
What are the changes?
EIP’s
What is an EIP?
EIPis a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment.
Provides a concise technical specification of the feature and a rationale for the feature.
The EIP author is responsible for building consensus within the community and documenting dissenting opinions.
EIP’s Included
EIP 145 -
Bitwise shifting
To provide native bitwise shifting with cost on par with other arithmetic operations.
Native bitwise shifting instructions are introduced, which are more efficient processing wise on the host and are cheaper to use by a contract.
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 SHL and SHR using arithmetics cost each 35 gas, while the proposed instructions take 3 gas.
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-145.md
EIP 1014- State channels for off chain(scalability)
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.
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1014.md
EIP1052 - Large scale code optimizing
Many contracts need to perform checks on a contract's bytecode, but do not necessarily need the bytecode itself.
A contract may want to check if another contract's bytecode is one of a set of permitted implementations, or it may perform analyses on code and whitelist any contract with matching bytecode if the analysis passes.
new opcode, EXTCODEHASH returns the keccak256 hash of a contract's code.
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1052.md
EIP1283 -Gas Reduction
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.
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1283.md
EIP1234 - Difficutly bomb move
Delay in the difficulty bomb(Ice Age)
Around 12 month delay(29 million seconds)
Casper(PoS) is not ready
Moved to around 5 million blocks later than previously specified with the Homestead fork.
Block rewards for miners moved from 3 to 2.
Same difficulty to allow mined blocks @ every 15 seconds for another 12 months
This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. #ETH #HARDFORK #EIP #SOFTFORK #ETHMINERREWARDS
▶️ DTube
▶️ IPFS