-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mark upstream go-ethereum v1.14.0 as merged #374
Merged
Merged
Conversation
This file contains 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
…106) * core, triedb/pathdb: calculate the size for batch pre-allocation * triedb/pathdb: address comment
* triedb/pathdb: fix panic in recoverable * triedb/pathdb: add todo * triedb/pathdb: rename * triedb/pathdb: rename
Co-authored-by: Sina Mahmoodi <[email protected]>
…rms for bad fcu payload (#29115)
Signed-off-by: cui fliter <[email protected]>
* cmd: parseDumpConfig should not return closed db * fix lint
…126) replace-fmt-errorf Co-authored-by: [email protected] <[email protected]>
* cmd/utils, core/rawdb, triedb/pathdb: flip hash to path scheme * graphql: run tests in hash mode as the chain maker needs it
* eth/catalyst: update simulated beacon for cancun * validate blob hashes * compute hashes from commitment * fix beacon root and payload version * check commitment conversion * fix random attr * flip dev to cancun
…(#29034) * eth: make transaction propagation paths in the network deterministic * eth: avoid potential division by 0 * eth: make tx propagation dependent on local node id too * eth: fix review comments
…9150) Co-authored-by: this-is-iron <[email protected]>
It got broken in some update of the cli library, and thus bootnodes weren't being configured automatically for some of the discovery commands.
* core: use finalized block as the chain freeze indicator * core/rawdb: use max(finality, head-90k) as chain freezing threshold * core/rawdb: fix tests * core/rawdb: fix lint * core/rawdb: address comments from peter * core/rawdb: fix typo
The prestateTracer was reporting an inaccurate nonce for the contract being created in post EIP-158 transactions. Correct nonce is 0, due to the issue nonce was being reported as 1.
* core/types: reuse signtx * core/types: inline signtx
initialize gasRemaining with = instead of +=
As SELF-DESTRUCT opcode is disabled in the cancun fork(unless the account is created within the same transaction, nothing to delete in this case). The account will only be deleted in the following cases: - The account is created within the same transaction. In this case the original storage was empty. - The account is empty(zero nonce, zero balance, zero code) and is touched within the transaction. Fortunately this kind of accounts are not-existent on ethereum-mainnet. All in all, after cancun, we are pretty sure there is no large contract deletion and we don't need this mechanism for oom protection.
* accounts/usbwallet: use updated hid (only) library * deps: update karalabe/hid
* internal/jsre: format receipt.{blobGasPrice,blobGasUsed} to int Signed-off-by: jsvisa <[email protected]> * internal/jsre: format tx.maxFeePerBlobGas to int Signed-off-by: jsvisa <[email protected]> * internal/jsre: format blob* in block Signed-off-by: jsvisa <[email protected]> --------- Signed-off-by: jsvisa <[email protected]>
tests: add cancun->prague config
This change removes support for subscribing to pending logs. "Pending logs" were always an odd feature, because it can never be fully reliable. When support for it was added many years ago, the intention was for this to be used by wallet apps to show the 'potential future token balance' of accounts, i.e. as a way of notifying the user of incoming transfers before they were mined. In order to generate the pending logs, the node must pick a subset of all public mempool transactions, execute them in the EVM, and then dispatch the resulting logs to API consumers.
Co-authored-by: lightclient <[email protected]> Co-authored-by: Felix Lange <[email protected]>
…532) Co-authored-by: Felix Lange <[email protected]>
This change fixes three flaky tests `TestEth2AssembleBlock`,`TestEth2NewBlock`, `TestEth2PrepareAndGetPayload` and `TestDisable`. --------- Co-authored-by: Gary Rong <[email protected]>
* core: fix typo * rpc: fix typo * snap: fix typo * trie: fix typo * main: fix typo * abi: fix typo * main: fix field comment for basicOp
This PR adds an extra mechanism to sync.HeadSync that tries to retrieve the latest finality update from every server each time it sends an optimistic update in a new epoch (unless we already have a validated finality update attested in the same epoch). Note that this is not necessary and does not happen if the new finality update is delivered before the optimistic update. The spec only mandates light_client_finality_update events when a new epoch is finalized. If the chain does not finalize for a while then we might need an explicit request that returns a finality proof that proves the same finality epoch from the latest attested epoch.
core/vm: fix prague contracts
…29573) renames the yaml config field VMTraceConfig to VMTraceJsonConfig, in order to be consistent with the renaming of the CLI flag.
The OnClose trace hook is being triggered on blockchain Stop, so as tracers can release any resources.
The beacon root when applied in `state_processor.go` is performed right before executing transaction. That means that contract reliying on this value would query the same value found in the block header. In that spirit, it means that any tracing/operation relying on state data which touches transaction must have updated the beacon root before any transaction processing.
… (#29358) This change adds a testcase and fixes a corner-case in the skeleton sync. With this change, when doing the skeleton cleanup, we check if the filled header is acually within the range of what we were meant to backfill. If not, it means the backfill was a noop (possibly because we started and stopped it so quickly that it didn't have time to do any meaningful work). In that case, just don't clean up anything. --------- Co-authored-by: Péter Szilágyi <[email protected]>
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: yzb.
|
tsahee
approved these changes
Nov 8, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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.
The v1.14.0 merge #345 accidentally didn't include the v1.14.0 upstream commit as a parent to the commit, perhaps because the commit was squashed or amended, so git doesn't think v1.14.0 has been merged in and creates conflicts when it's attempted to be merged. To fix this, this PR has a commit produced by
git merge --strategy=ours v1.14.0
which marks v1.14.0 as merged to git without actually changing anything.