<\/p>\n
The Ethereum network is set to undergo a planned upgrade at block number 7,280,000<\/strong>, anticipated to happen on Thursday, February 28, 2019<\/strong>. The precise date may vary based on block times from now until then and could be enacted 1-2 days earlier or later. A countdown timer can be accessed at https:\/\/amberdata.io\/blocks\/7280000<\/a>. You can track the network upgrade in real time at http:\/\/forkmon.ethdevops.io\/<\/a>.<\/p>\n <\/p>\n <\/p>\n Constantinople and St. Petersburg refer to the nomenclature of this network upgrade. Earlier network upgrades have been designated different titles such as Spurious Dragon<\/a> and Byzantium<\/a>. The reason there are two names for this upgrade is that the original Constantinople network upgrade was delayed<\/a>, and two protocol upgrades are required to happen on the same block number to resolve issues across various Ethereum test networks, like Ropsten.<\/p>\n <\/p>\n <\/p>\n If you utilize an exchange (such as Coinbase, Kraken, or Binance), a web wallet service (like Metamask, MyCrypto, or MyEtherWallet), a mobile wallet service (like Coinbase Wallet, Status.im, or Trust Wallet), or a hardware wallet (such as Ledger, Trezor, or KeepKey), you do not need to take any action unless instructed to do so by your exchange or wallet provider.<\/p>\n <\/p>\n <\/p>\n Install the latest version of your Ethereum client:<\/p>\n <\/p>\n If you are running an Ethereum client that has not been updated to the latest version (as noted earlier), your client will synchronize with the pre-upgrade blockchain once the upgrade takes place. You will find yourself on an incompatible chain adhering to the old rules, which will prohibit you from sending ether or functioning on the upgraded Ethereum network.<\/p>\n <\/p>\n <\/p>\n A network upgrade signifies a modification to the foundational Ethereum protocol, establishing new rules to enhance the system. The decentralized nature of blockchain systems complicates a network upgrade. Such upgrades require collaboration and communication with the community, along with coordination with developers of various Ethereum clients to ensure a seamless transition.<\/p>\n <\/p>\n <\/p>\n Once the community reaches a consensus on the modifications to be included in the upgrade, these alterations to the protocol are coded into the various Ethereum clients, including geth, Parity, and Harmony. The protocol modifications are activated at a specified block number. Any nodes that have not transitioned to the new ruleset will be left behind on the old chain where the previous rules continue to apply.<\/p>\n <\/p>\n <\/p>\n Modifications slated for inclusion in Constantinople are outlined using EIPs. Ethereum Improvement Proposals (EIPs) stipulate standards for the Ethereum platform, encompassing core protocol specifications, client APIs, and contract standards. The following EIPs will be incorporated 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 supports other logical and arithmetic operators. Shift operations can be achieved through arithmetic operators, though this incurs a greater cost and requires additional processing time. Implementing SHL and SHR using arithmetic costs each 35 gas, whereas these suggested instructions take merely 3 gas.<\/p>\n <\/li>\n In summary: This EIP introduces native capabilities to the protocol, making it cheaper & simpler to perform certain operations on-chain.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n Introduces a new opcode at 0xf5, which accepts 4 stack parameters: endowment, memory_start, memory_length, salt. Functions identically to CREATE, except utilizing keccak256( 0xff ++ address ++ salt ++ keccak256(init_code)))[12:] instead of keccak256(RLP(sender_address, nonce))[12:] as the address where the contract is instantiated.<\/p>\n <\/li>\n This enables interactions with addresses that do not currently exist on-chain but can be expected to eventually hold code produced by a specific piece of initialization code.<\/p>\n <\/li>\n Crucial for state-channel applications involving counterfactual dealings with contracts.<\/p>\n <\/li>\n In essence: This EIP allows for interaction with addresses that have yet to be generated.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n This EIP outlines a new opcode, which returns the keccak256 hash of a contract’s“`html <\/li>\n Numerous agreements require validation of a contract’s bytecode, yet do not necessarily need the bytecode itself. For example, a contract might want to verify if another contract’s bytecode is part of a collection of authorized implementations, or it could conduct evaluations on code and whitelist any contract with corresponding bytecode if the evaluation succeeds.<\/p>\n <\/li>\n Currently, contracts can achieve this through the EXTCODECOPY opcode, but this is costly, particularly for larger contracts, in instances where only the hash is needed. Consequently, a new opcode is being introduced named EXTCODEHASH which provides the keccak256 hash of a contract’s bytecode.<\/p>\n <\/li>\n In summary: This EIP reduces the cost (less gas is required) for performing specific actions on chain.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n The average block durations are rising as a consequence of the difficulty bomb (often referred to as the “ice age”) gradually intensifying. This EIP suggests postponing the difficulty bomb for around 12 months and decreasing the block rewards to compensate for the ice age delay.<\/p>\n <\/li>\n In conclusion: This EIP ensures that we do not freeze the blockchain prior to the readiness and implementation of proof of stake.<\/p>\n <\/li>\n<\/ul>\n <\/p>\n <\/p>\n Before Ethereum implements network upgrades in the main network, test networks, like Ropsten, are upgraded to evaluate the changes. The initial Constantinople modifications, detailed in this blog entry, were made to test networks before the delay and necessitate a second network upgrade to reverse the original Constantinople alterations. This is designated as St. Petersburg and occurs concurrently with the block number of Constantinople.<\/p>\n <\/p>\n The following EIP was eliminated from test networks via the St. Petersburg network upgrade:<\/p>\n <\/p>\n <\/p>\n <\/p>\n A heartfelt appreciation to the Ethereum community, and to all Ethereum developers from various clients and platforms who collaborated to provide insights, perspectives, 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 are Constantinople and St. Petersburg?<\/h2>\n
As an Ethereum user or ether holder, is there anything I should do?<\/h2>\n
As a node operator or miner, what actions must I take?<\/h2>\n
\n<\/p>\nWhat occurs if I am a miner or node operator and do not partake in the upgrade?<\/h2>\n
What constitutes a network upgrade in Ethereum-land?<\/h2>\n
What transpires during a network upgrade?<\/h2>\n
What alterations 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
\n<\/p>\nEIP 1234: Constantinople Difficulty Bomb Delay and Block Reward Adjustment<\/a><\/h3>\n
\n
What modifications are being integrated into St. Petersburg?<\/h2>\n
REMOVING EIP 1283: Net gas metering for SSTORE without dirty maps<\/a><\/h3>\n
Thank You!<\/h2>\n