Here we bump up go-etherum version to v1.13.11. This version is ready for the Cancun-Deneb (Dencun) upgrade and adds support for the new “blob-carrying” EIP-4844 transaction type in API methods. The RPC client used in older go-ethereum versions does not recognize EIP-4844 transactions and may error out if there is a need to parse return data from transaction-related functions called against chains where the Dencun upgrade has been enabled. We observed this problem on our Sepolia testnet when calling eth_getBlockByNumber using version v1.10.19 after Jan 31th so after the date when Dencun was enabled on Sepolia
We are also taking an opportunity and optimize our GetBlockHashByNumber function. So far this function called the BlockByNumber function of the RPC client. Under the hood, that resulted in an inefficient eth_getBlockByNumber call with the show transaction details flag set to true which loaded full transaction data of the given block which is not necessary for the context of GetBlockHashByNumber. Here we improve that behavior by using the HeaderByNumber function of the RPC client. That function calls eth_getBlockByNumber with the show transaction details flag set to false which does not load transaction data and returns only data specific to the block header. This is enough to get the hash of the block.
Closes: https://github.com/keep-network/keep-core/issues/3772 Depends on: https://github.com/keep-network/keep-core/pull/3773
Here we bump up
go-etherumversion tov1.13.11. This version is ready for the Cancun-Deneb (Dencun) upgrade and adds support for the new “blob-carrying” EIP-4844 transaction type in API methods. The RPC client used in oldergo-ethereumversions does not recognize EIP-4844 transactions and may error out if there is a need to parse return data from transaction-related functions called against chains where the Dencun upgrade has been enabled. We observed this problem on our Sepolia testnet when callingeth_getBlockByNumberusing versionv1.10.19after Jan 31th so after the date when Dencun was enabled on SepoliaWe are also taking an opportunity and optimize our
GetBlockHashByNumberfunction. So far this function called theBlockByNumberfunction of the RPC client. Under the hood, that resulted in an inefficienteth_getBlockByNumbercall with theshow transaction detailsflag set totruewhich loaded full transaction data of the given block which is not necessary for the context ofGetBlockHashByNumber. Here we improve that behavior by using theHeaderByNumberfunction of the RPC client. That function callseth_getBlockByNumberwith theshow transaction detailsflag set tofalsewhich does not load transaction data and returns only data specific to the block header. This is enough to get the hash of the block.