<\/p>\n
<\/p>\n
The Ethereum blockchain will be undergoing a planned enhancement at block number 7,080,000<\/strong>, expected to occur on Wednesday, January 16, 2019<\/strong>. The precise date might vary depending on block generation times leading up to that point, and activation could happen 1-2 days prior or later. A countdown clock is available at https:\/\/amberdata.io\/blocks\/7080000<\/a>. You can track the network update in real-time at http:\/\/forkmon.ethdevops.io\/<\/a>.<\/p>\n <\/p>\n <\/p>\n Constantinople refers to the designation given to this network upgrade. Earlier network enhancements have received other titles such as Spurious Dragon<\/a> and Byzantium<\/a>.<\/p>\n <\/p>\n <\/p>\n If you utilize an exchange (like Coinbase, Kraken, or Binance), a web wallet service (such as Metamask, MyCrypto, or MyEtherWallet), a mobile wallet service (like Coinbase Wallet, Status.im, or Trust Wallet), or a hardware wallet (like Ledger, Trezor, or KeepKey), you do not need to take any action unless instructed otherwise by your exchange or wallet service.<\/p>\n <\/p>\n <\/p>\n Obtain the latest version of your Ethereum client:<\/p>\n <\/p>\n If you are utilizing an Ethereum client that has not been updated to the current version (as noted above), your client will synchronize with the pre-fork blockchain once the upgrade is implemented. You will remain on an incompatible chain observing the old rules, rendering you unable to send ether or operate within the post-upgrade Ethereum network.<\/p>\n <\/p>\n <\/p>\n A network upgrade involves modifications to the foundational Ethereum protocol, establishing new guidelines to enhance the system. The decentralized nature of blockchain systems complicates a network upgrade. Such upgrades necessitate collaboration and communication with the community, alongside developers of the various Ethereum clients, to ensure a smooth transition.<\/p>\n <\/p>\n <\/p>\n Once the community reaches a consensus on which modifications to incorporate into the upgrade, protocol changes are encoded into the different Ethereum clients, including geth, Parity, and Harmony. The protocol changes will be enacted at a pre-defined block number. Nodes that have not transitioned to the new ruleset will be left behind on the previous chain where earlier rules persist.<\/p>\n <\/p>\n <\/p>\n Modifications introduced in Constantinople are articulated via EIPs. Ethereum Improvement Proposals (EIPs) outline the standards for the Ethereum network, encompassing core protocol specifications, client APIs, and contract standards. The subsequent EIPs will be enacted in Constantinople.<\/p>\n <\/p>\n <\/p>\n Facilitates native bitwise shifting at a cost comparable to other arithmetic operations.<\/p>\n <\/li>\n The EVM currently lacks bitwise shifting operators but accommodates various logical and arithmetic operators. Bitwise operations can be conducted using arithmetic operators; however, this incurs greater costs and demands more processing time. Utilizing SHL and SHR via arithmetic costs 35 gas each, whereas the proposed instructions will require just 3 gas.<\/p>\n <\/li>\n In summary: This EIP introduces built-in capabilities to the protocol, making certain on-chain processes cheaper and simpler.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n Introduces a new opcode at 0xf5, which requires 4 stack arguments: endowment, memory_start, memory_length, and salt. Functions identically to CREATE but uses keccak256( 0xff ++ sender_address ++ salt ++ keccak256(init_code)))[12:] instead of keccak256(RLP(sender_address, nonce))[12:] to establish the address where the contract is initialized.<\/p>\n <\/li>\n This permits engagements with addresses that are not yet present on-chain but are expected to eventually host code generated by specific init code.<\/p>\n <\/li>\n Crucial for state-channel scenarios that involve counterfactual interactions with contracts.<\/p>\n <\/li>\n In summary: This EIP allows interaction with addresses that have not yet been created.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n This EIP outlines a new opcode,which provides the keccak256 hash of a contract’s code.<\/p>\n <\/li>\n Numerous contracts must execute validations on a contract’s bytecode, yet do not necessarily require the bytecode itself. For example, a contract might want to verify if another contract’s bytecode belongs to a predefined set of authorized implementations, or it could analyze code and approve any contract with matching bytecode if the evaluation is successful.<\/p>\n <\/li>\n Contracts can currently achieve this with the EXTCODECOPY opcode, but this method is costly, particularly for sizable contracts, especially when only the hash is essential. Consequently, a new opcode named EXTCODEHASH is being introduced which returns the keccak256 hash of a contract’s bytecode.<\/p>\n <\/li>\n In summary: This EIP reduces costs (less gas is required) for specific operations on the blockchain.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n This EIP suggests modifications to net gas metering for the SSTORE opcode, facilitating new applications for contract storage, while decreasing exorbitant gas fees where the process does not conform to the majority of implementations.<\/p>\n <\/li>\n In summary: This EIP lowers costs (reducing gas requirements) for certain operations on the blockchain, particularly those deemed currently “excessively” costly.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n Average block intervals are rising due to the difficulty bomb (often referred to as the “ice age”) gradually accelerating. This EIP proposes postponing the difficulty bomb for about 12 months and reducing block rewards to account for the delay in the ice age.<\/p>\n <\/li>\n In summary: This EIP ensures that the blockchain does not become stagnant before proof of stake is developed and applied.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n Heartfelt gratitude to the Ethereum community, and to all Ethereum developers across various clients and platforms who collaborated to provide insights, thoughts, and contributions. Special acknowledgment to Reddit user cartercarlson who permitted us to utilize his Reddit post<\/a> and the MyCrypto<\/a> team for allowing us to reference their “Ethereum Constantinople: Everything You Need To Know<\/a>” Medium article.<\/strong><\/p>\n <\/p>\nWhat is Constantinople?<\/h2>\n
As an Ethereum user or ether holder, is there any action required from me?<\/h2>\n
As a node operator or miner, what steps should I take?<\/h2>\n
\n<\/p>\nWhat occurs if I am a miner or node operator and I opt-out of the upgrade?<\/h2>\n
What is a network upgrade in Ethereum terminology?<\/h2>\n
What transpires during a network upgrade?<\/h2>\n
What modifications are included in Constantinople?<\/h2>\n
EIP 145: Bitwise shifting instructions in EVM<\/a><\/h3>\n
\n
EIP 1014: Skinny CREATE2<\/a><\/h3>\n
\n
EIP 1052: EXTCODEHASH opcode<\/a><\/h3>\n
\n
EIP 1283: Net gas metering for SSTORE without dirty maps<\/a><\/h3>\n
\n
EIP 1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment<\/a><\/h3>\n
\n
Thank You!<\/h2>\n