Skip to content
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

Upstream merge v1.14.8 #1410

Open
wants to merge 75 commits into
base: develop
Choose a base branch
from
Open

Upstream merge v1.14.8 #1410

wants to merge 75 commits into from

Conversation

kamuikatsurgi
Copy link
Member

Description

Changes

  • Bugfix (non-breaking change that solves an issue)
  • Hotfix (change that solves an urgent issue, and requires immediate attention)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (change that is not backwards-compatible and/or changes current functionality)
  • Changes only for a subset of nodes

Breaking changes

Please complete this section if any breaking changes have been made, otherwise delete it

Nodes audience

In case this PR includes changes that must be applied only to a subset of nodes, please specify how you handled it (e.g. by adding a flag with a default value...)

Checklist

  • I have added at least 2 reviewer or the whole pos-v1 team
  • I have added sufficient documentation in code
  • I will be resolving comments - if any - by pushing each fix in a separate commit and linking the commit hash in the comment reply
  • Created a task in Jira and informed the team for implementation in Erigon client (if applicable)
  • Includes RPC methods changes, and the Notion documentation has been updated

Cross repository changes

  • This PR requires changes to heimdall
    • In case link the PR here:
  • This PR requires changes to matic-cli
    • In case link the PR here:

Testing

  • I have added unit tests
  • I have added tests to CI
  • I have tested this code manually on local environment
  • I have tested this code manually on remote devnet using express-cli
  • I have tested this code manually on mumbai/amoy
  • I have created new e2e tests into express-cli

Manual tests

Please complete this section with the steps you performed if you ran manual tests for this functionality, otherwise delete it

Additional comments

Please post additional comments in this section if you have them, otherwise delete it

winniehere and others added 30 commits July 2, 2024 15:58
refactor(accounts/abi): use embed pkg to split default template to file
…#30148)

This does not change the behavior here as the nonce in the argument is
tx.Nonce(). This commit helps to make the function easier to read and avoid
capturing the tx in the function.
… (#30105)

* core, triedb/pathdb, cmd: define verkle state ancient store

* core/rawdb, triedb: add verkle namespace in pathdb
The pubkey type was moved to package v4wire a long time ago. Remaining uses of
encPubkey were probably left in due to laziness.
* eth/gasprice: remove default from config

* eth/gasprice: sanitize startPrice
This makes the test resilient to changes of types.Header -- otherwise the test needs to be
updated each time the header structure is modified.
Icarus9913 and others added 29 commits August 1, 2024 16:25
The package `github.com/golang/protobuf/proto` is deprecated in favor
`google.golang.org/protobuf/proto`. We should update the codes to
recommended package.

Signed-off-by: Icarus Wu <[email protected]>
Adding the correct accessList parameter when calling a contract can
reduce gas consumption. However, the current version only allows adding
the accessList manually when constructing the transaction. This PR can
provide convenience for saving gas.
Removing because memsize will very likely be broken by Go 1.23. See
fjl/memsize#4
Fixes #30254 

It seems like the removed CreateAccount call is very old and not needed anymore.
After removing it, setting a sender that does not exist in the state doesn't seem to cause
an issue.
…sed (#30267)

Seems it is checked with the wrong argument

Signed-off-by: jsvisa <[email protected]>
The struct-based tracing added in #29189 seems to have caused an issue
with the benchmark `BenchmarkTracerStepVsCallFrame`. On master we see
the following panic:

```console
BenchmarkTracerStepVsCallFrame
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x40 pc=0x1019782f0]

goroutine 37 [running]:
github.com/ethereum/go-ethereum/eth/tracers/js.(*jsTracer).OnOpcode(0x140004c4000, 0x0, 0x10?, 0x989680, 0x1, {0x101ea2298, 0x1400000e258}, {0x1400000e258?, 0x14000155928?, 0x10173020c?}, ...)
        /Users/matt/dev/go-ethereum/eth/tracers/js/goja.go:328 +0x140
github.com/ethereum/go-ethereum/core/vm.(*EVMInterpreter).Run(0x14000307da0, 0x140003cc0d0, {0x0, 0x0, 0x0}, 0x0)
 ...
FAIL    github.com/ethereum/go-ethereum/core/vm/runtime 0.420s
FAIL
```

The issue seems to be that `OnOpcode` expects that `OnTxStart` has
already been called to initialize the `env` value in the tracer. The JS
tracer uses it in `OnOpcode` for the `GetRefund()` method.

This patch resolves the issue by reusing the `Call` method already
defined in `runtime_test.go` which correctly calls `OnTxStart`.
Some chains’ network IDs use hexadecimal such as Optimism ("0xa" instead
of "10"), so when converting the string to big.Int, we cannot specify
base 10; otherwise, it will encounter errors with hexadecimal network
IDs.
This PR adds the methods `Stack.swap1..16()` that faster than `Stack.swap(1..16)`. 

Co-authored-by: lmittmann <[email protected]>
…0274) (#30277)

Precomputes valid primitive types into a map to use for validation, thus removing sprintf.
Consistently use `uint64` for indices in `Memory` and drop lots of type
conversions from `uint64` to `int64`.

---------

Co-authored-by: lmittmann <[email protected]>
Due to https://github.com/ethereum/tests/releases/tag/v10.1, the format
of the TransactionTest changed, but it was not properly addressed, causing the test
to pass unexpectedly.

---------

Co-authored-by: Martin Holst Swende <[email protected]>
…nloader queue (#30276)

Fixes a slight miscalculation in the downloader queue, which was not accurately taking block withdrawals into account when calculating the size of the items in the queue
fixes #30279 -- previously we did not use the basefee from the genesis, and instead the defaults were used from `runtime.go/setDefaults`-function
…ead of hard-coded value (#29721)


Co-authored-by: Felix Lange <[email protected]>
Co-authored-by: Marius van der Wijden <[email protected]>
Co-authored-by: lightclient <[email protected]>
Looking at the history of these packages over the past several years, there
haven't been any meaningful contributions or usages:
https://github.com/ethereum/go-ethereum/commits/master/p2p/simulations?before=de6d5976794a9ed3b626d4eba57bf7f0806fb970+35

Almost all of the commits are part of larger refactors or low-hanging-fruit contributions.
Seems like it's not providing much value and taking up team + contributor time.
…lete storage (#30258)

This pull request fixes #30229.
 
During snap sync, large storage will be split into several pieces and
synchronized concurrently. Unfortunately, the tradeoff is that the respective
merkle trie of each storage chunk will be incomplete due to the incomplete
boundaries. The trie nodes on these boundaries will be discarded, and any
dangling nodes on disk will also be removed if they fall on these paths,
ensuring the state healer won't be blocked.

However, the dangling account trie nodes on the path from the root to the
associated account are left untouched. This means the dangling account trie
nodes could potentially stop the state healing and break the assumption that the
entire subtrie should exist if the subtrie root exists. We should consider the
account trie node as the ancestor of the corresponding storage trie node.

In the scenarios described in the above ticket, the state corruption could occur
if there is a dangling account trie node while some storage trie nodes are
removed due to synchronization redo.

The fixing idea is pretty straightforward, the trie nodes on the path from root
to account should all be explicitly removed if an incomplete storage trie
occurs. Therefore, a `delete` operation has been added into `gentrie` to
explicitly clear the account along with all nodes on this path. The special
thing is that it's a cross-trie clearing. In theory, there may be a dangling
node at any position on this account key and we have to clear all of them.
Port changes from develop to upstream_merge
Copy link
Contributor

@manav2401 manav2401 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, except a minor nit.

@@ -463,25 +461,6 @@ func startNode(ctx *cli.Context, stack *node.Node, backend ethapi.Backend, isCon
}
}()
}

// Start auxiliary services if enabled
if ctx.Bool(utils.MiningEnabledFlag.Name) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't we add a log here on why this is deleted?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I removed the commented code, cause it will again cause the future upstream merge to have conflicts instead of a clean merge. I will add the logs/comments above the function, does that seem alright?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.