We are happy to announce that Klaytn v1.10.0 has been released.
Klaytn v1.10.0 contains a hardfork upgrade that results in backward incompatible changes. All Baobab/Cypress nodes would thus have to be upgraded to v1.10.0 or higher before the target block number. The name of the hardfork is ‘Kore’. The hardfork contains an implementation of the on-chain governance voting method (KIP-81), a new GC reward structure (KIP-82), and EVM changes.
The planned hardfork schedule is as follows:
Kore hardfork block number & estimated date
– Baobab: 111,736,800 block height (estimated time: 10 Jan, 10:00 AM UTC+9)
– Cypress: March 2023, to be announced with the next release (v1.10.x)
# Cautions regarding the v1.10.0 upgrade and Kore hardfork
Following are some important cautions for Klaytn ecosystem participants. Please read this before applying v1.10.0 upgrade and Kore hardfork.
For block explorers (Scope, Finder) and Governance Analysis tools
- After the Kore hardfork, governance voting will be processed in a smart contract according to KIP-81. The existing block header voting mechanism will be used only as a fallback for the contract-based voting mechanism. The finalized governance data can be retrieved from `governance_chainConfigAt(num)` or `klay_chainConfigAt(num)` API. More detailed documentation for voting data analysis will be published later after deploying governance contracts.
- After Kore hardfork, block reward will be distributed to all valid stakers (CNs) as well as block proposers according to KIP-82. The Gini coefficient will be disregarded for the proposer selection, thus enabling a fairer distribution of rewards among proposers. Reward distribution details including the burn amount can be retrieved via the new `klay_getRewards(num)` API.
For node operators
- All nodes should update their version to v1.10.0 before the Kore hardfork block number. The cypress hardfork block number will be specified in the next Klaytn version after confirming the safety of the hardfork in Baobab network.
- After the v1.10.0 upgrade, NTP time synchronization will be essential by default. If your node has difficulty synchronizing with the NTP server, add the `–ntp.disable` flag in your node configuration.
- After the v1.10.0 upgrade, node operators can restrict some features of debug APIs with the `rpc.unsafe-debug.disable` flag. Although debug APIs are supposed to be open to trusted users, some APIs can cause a critical issue when they are exposed to malicious users. Check the details about the restriction in the “Further comments” section of this PR.
- After v1.10.0 upgrade, new node flags will be introduced: `–snapshot`, `–ntp.disable`, `–ntp.server`, `–rpc.evmtimeout`. Read below for more details.
For dApp developers
- After the v1.10.0 upgrade, node operators can restrict some features of debug APIs if they set a special configuration. Check the details about the restriction in the “Further comments” section of this PR. After the Kore hardfork, `opDifficulty` will be replaced with `opRandom` with the adoption of EIP-4399. It means that opcode 0x44 will return the previous blockhash of this block instead of the difficulty of the block.
- After Kore hardfork, `opDifficulty` will be replaced with `opRandom` with the adoption of EIP-4399. It means that opcode 0x44 will return the previous blockhash of this block instead of the difficulty of the block.
- After Kore hardfork, gas costs of `SLOAD`, `*CALL`, `BALANCE`, `EXT*` and `SELFDESTRUCT` will increase when they are used for the first time in a transaction, and decrease after the second time with the adoption of EIP-2929. And the gas cost of `ModExp` precompiled contract will be defined with the adoption of EIP-2565.
- After Kore hardfork, the gas refund for `SELFDESTRUCT` and `SSTORE` will be reduced with the adoption of EIP-3529.
- After Kore hardfork, a new contract starting with 0xEF byte will fail to be deployed with the adoption of EIP-3541.
For ecosystem participants,
- After v1.10.0 upgrade, gini-coefficient will be disabled in block proposer selection. It means that all CN will generate blocks with even probability. The reward will be distributed in another way according to KIP-82. A portion of the block minting amount is allocated to stakers, which is proportional to the KLAY staking amount of each CN.
## Kore Hardfork Features
The new features of the Kore hardfork will be applied to the Baobab and Cypress networks according to their respective hardfork block numbers.
– All committee members have an equal chance of being elected block proposers (#1655)
– Upgrades to support contract-based on-chain governance mechanism
– Stores the governance configuration on either block headers or a governance parameter contract
– Splits the block proposing reward into minting reward and staking reward
– Distributes staking rewards for valid stakers for every block generation as well as block proproser reward
– Introduces `klay_getRewards` API that returns reward distribution details including the burn amount of a specific block
– Made `client.Client` to be able to set new HTTP headers (#1632)
– Added asynchronous snapshot data generation feature introducing `–snapshot` flag (#1634)
– Reduced memory usage of RPC server (#1650)
– Added blockHash filter option to
klay_getLogs API (#1653)
– Accepted decimal block number for
debug_setHead API (#1697)
– Added `snapshot` sub-command to verify state database (#1701)
– Supported `getStakingInfo`, `nodeAddress`, `chainConfig`, and `chainConfigAt`, `govParamsAt` APIs in `klay` namespace as well as `governance` namespace. (#1731)- Introduced EVM execution timeout flag, `–rpc.evmtimeout` to manage node resource by node operators (#1736)
– Mitigated unintended gas exhaustion of ServiceChain bridge operators during ERC721 transfer (#1445)
– Fixed nil access issues of non-WeightedRandom proposer selection (#1600)
– Fixed rare database corruption issues caused by forced process termination via backup additional block (#1630)
– Flushed storage snapshot data into database after processing (#1635)
– Fixed to verify CommittedSeals always in istanbul consensus engine (#1678)
– Resolved `gov.changeSet` corruption issue caused by `debug.traceBlock` API call (#1706)
– Fixed unapplied block range filter issue in `klay_getLogs` API (#1715)
– Fixed to use EmptyRootHashOriginal always in eth_getProof API (#1726)
– Added Klaytn binary version information into Prometheus metric (#1488)
– Enhanced Homi to generate reward account keystores having `reward#` file name (#1605)
– Added nil checking logic for MagmaHeader verification (#1608)
– Modified Dockerfile to support TLS connection in golang (#1616)
– Lowered the log level of “Returning since the addr is not a program account” to debug level (#1643)
– Increased the size limit of P2P messaging protocol from 10MB to 12MB (#1658)
– Updated Homi to allocate more balance for ServiceChain genesis (#1683)
– Generated genesis.json, keys, and others from yaml configuration in homi (#1661)
Special thanks to Theori for reporting vulnerabilities using debug namespace APIs. Theori reported possible attack scenario abusing some debug APIs, and gave basic idea to mitigate it for #GHSA-4vx6-m7jv-g2ch Special thanks to ChainLight for reporting vulnerabilities using debug namespace APIs. They reported possible attack scenario abusing some debug APIs, and gave basic idea to mitigate it for #GHSA-4vx6-m7jv-g2ch #1722 #1746 PRs.