Cautions regarding the hard fork

The new version is expected to affect Klaytn DApps currently in service, so if you are a service operator or a developer, we recommend you also read the series Toward Ethereum Equivalence #1 #2 #3 #4 along with the instructions below.

For DApp Services Providers

You may experience Out of Gas errors with old smart contracts

The IstanbulEVM hard fork EVM includes changes in the gas cost for the opcode (Please refer to “Protocol Upgrade Features” in the Klaytn v1.7.0 Release Notes). If your contract had a lot of functions that require limited gas cost like fallback, this change in gas cost may cause an Out of Gas. So far we have determined problems for cases when upgradeable contracts that inherited OpenZeppelin’s BaseAdminUpgradeabilityProxy.sol and BaseUpgradeabilityProxy.sol implement a fallback function identical to Proxy.sol. Please check if the function is implemented in a similar way. Also keep in mind that gas costs are subject to constant change, so please refrain from using actions with heavy loads in the fallback except for printing logs. (reference).

Some Precompiled Contract addresses will be changed

The addresses vmLog(0x09), feePayer(0x0a), validateSender(0x0b) will be transferred to ensure compatibility with Ethereum’s precompiled contracts. It only applies to contracts deployed after the hard fork; contracts deployed before that will remain usable. For more details, please refer to Toward Ethereum Equivalence #2 — Changes in Precompiled Contract Addresses.

Update your caver to v1.8.0 or higher to support the new transaction types

You will be able to use the new transaction types with the EthTxType hard fork. If you need the new transaction formats for a service that requires accessing the transactions of other accounts, make sure to update your caver to v1.8.0 (js, java) or higher. For more details on the new types, please refer to Toward Ethereum Equivalence #4 — Ethereum transaction types.

For EN Operators

New return values for eth andklay APIs

Before, you could make an API call using the eth namespace and it worked the same as klay namespace. But starting with v1.8.0, the eth namespace APIs will adopt Ethereum API return formats. You can find out more in Toward Ethereum Equivalence #3 — Supporting Ethereum API formats. If you want to stick to the behaviors of the old version and use eth like klay, just add the --rpc.eth.noncompatible init option.

Add eth in the EN’s default allowed API list

eth namespace APIs are supported for ENs, and eth has been added to the default allowed list. You need to add eth to the configurations pf RPC_API and WS_API in the kend.conf file in order to use eth APIs. net, web3 APIs used with Ethereum tools like hardhat have also been added to the list. To sum up, the default API white list in v1.8.0 includes: RPC_API="klay,net,eth,web3", WS_API="klay,net,eth,web3"