Upgrade go-ethereum to v1.13.11
#3774
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Version `v1.13.11` is ready for the Cancun-Deneb (Dencun) upgrade and adds support of 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 See https://github.com/ethereum/go-ethereum/releases/tag/v1.13.11 for reference.
So far the `GetBlockHashByNumber` function called the `BlockByNumber` function of the RPC client. Under the hood, that resulted in an inefficient `eth_getBlockByNumber` call with `show transaction details` flag set to `true` which loaded full transaction data of the given block which is not necessary in the context of `GetBlockHashByNumber`. Here we improve that behavior by using the `HeaderByNumber` function of the RPC client. That function calls `eth_getBlockByNumber` with `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.
tomaszslabon
approved these changes
Feb 8, 2024
tomaszslabon
added a commit
that referenced
this pull request
Feb 8, 2024
Closes: #3739 Depends on: keep-network/go-electrum#5 Depends on: #3774 So far, the `GetLatestBlockHeight` function of the Electrum client was using `go-electrum`'s `SubscribeHeaders` under the hood. That caused a memory leak because `GetLatestBlockHeight` was not interested in reading from the returned `headersChan` channel. Each call to `GetLatestBlockHeight` produced a new dangling goroutine blocked on a buffered channel with one item inside. Here we replace `SubscribeHeaders` with `SubscribeHeadersSingle` which does not create a goroutine supposed to handle future headers notifications. The `SubscribeHeadersSingle` just returns the current chain tip and ignores further notifications coming from the Electrum server. See keep-network/go-electrum#5 for further reference.
lukasz-zimnoch
added a commit
that referenced
this pull request
Feb 12, 2024
This pull request backports #3774 to the `releases/mainnet/v2.0.0-m7` branch.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes: #3772
Depends on: #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.