Draft release v1.5.5 #2876
Merged
Draft release v1.5.5 #2876
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
In this pull request, the state iterator is implemented. It's mostly a copy-paste
from the original state snapshot package, but still has some important changes
to highlight here:
(a) The iterator for the disk layer consists of a diff iterator and a disk iterator.
Originally, the disk layer in the state snapshot was a wrapper around the disk,
and its corresponding iterator was also a wrapper around the disk iterator.
However, due to structural differences, the disk layer iterator is divided into
two parts:
- The disk iterator, which traverses the content stored on disk.
- The diff iterator, which traverses the aggregated state buffer.
Checkout `BinaryIterator` and `FastIterator` for more details.
(b) The staleness management is improved in the diffAccountIterator and
diffStorageIterator
Originally, in the `diffAccountIterator`, the layer’s staleness had to be checked
within the Next function to ensure the iterator remained usable. Additionally,
a read lock on the associated diff layer was required to first retrieve the account
blob. This read lock protection is essential to prevent concurrent map read/write.
Afterward, a staleness check was performed to ensure the retrieved data was
not outdated.
The entire logic can be simplified as follows: a loadAccount callback is provided
to retrieve account data. If the corresponding state is immutable (e.g., diff layers
in the path database), the staleness check can be skipped, and a single account
data retrieval is sufficient. However, if the corresponding state is mutable (e.g.,
the disk layer in the path database), the callback can operate as follows:
```go
func(hash common.Hash) ([]byte, error) {
dl.lock.RLock()
defer dl.lock.RUnlock()
if dl.stale {
return nil, errSnapshotStale
}
return dl.buffer.states.mustAccount(hash)
}
```
The callback solution can eliminate the complexity for managing
concurrency with the read lock for atomic operation.
…ory (#30868) Updates geth to use the latest uint256, and use faster memory-writer
This change adds methods which makes it possible for to wait for a transaction with a specific hash when deploying contracts during abi bind interaction. --------- Co-authored-by: Marius van der Wijden <[email protected]>
Adding some missing functionality I noticed while updating the hivechain tool for the Prague fork: - we forgot to process the parent block hash - added `ConsensusLayerRequests` to get the requests list of the block
Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.26.0 to 0.31.0. Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Noticed this omission while doing some work on goevmlab. We don't properly type some of the opcodes, but apparently implicit casting works in all the internal usecases.
Fixing some issues I found while regenerating RPC tests for Prague: - Authorization signature values were not encoded as hex - `requestsRoot` in block should be `requestsHash` - `authorizationList` should work for `eth_call`
This fixes a regression introduced recently. Without this fix, it's not possible to use statetests without `.json` suffix. This is problematic for goevmlab `minimizer`, which appends the suffix `.min` during processing.
Here I am proposing two small changes to the exported API for EIP-7702: (1) `Authorization` has a very generic name, but it is in fact only used for one niche use case: authorizing code in a `SetCodeTx`. So I propose calling it `SetCodeAuthorization` instead. The signing function is renamed to `SignSetCode` instead of `SignAuth`. (2) The signing function for authorizations should take key as the first parameter, and the authorization second. The key will almost always be in a variable, while the authorization can be given as a literal.
The API spec requires the name yParity.
…#30936) Fixing a regression introduced by 73a4ecf, which I accidentally pushed to the master branch directly.
As a follow-up to #30933, I propose to also use the SetCode prefix in our internal APIs for the authorization list.
The `a` parameter should be used in the `MulScalar` function. The upstream cloudflare and google repos have already merged fixes. Reference: * https://cs.opensource.google/go/x/crypto/+/8d7daa0c54b357f3071e11eaef7efc4e19a417e2 * cloudflare/bn256#33
This commit makes it so that the struct logger will not emit logs while system calls are being executed. This will make it consistent with the JSON and MD loggers. It is as it stands hard to distinguish when system calls are being processed vs when a tx is being processed. --------- Co-authored-by: Sina Mahmoodi <[email protected]>
…(#30981) Update the default timestamp increment to 12s for `eth_simulate` endpoint
Fixes an issue where the node panics when an LStat fails with something other than os.ErrNotExist closes ethereum/go-ethereum#30968
This PR attempts to fix a strange test-failure (timeout) observed on a windows-32 platform. https://ci.appveyor.com/project/ethereum/go-ethereum/builds/51174391/job/d8ascanwwltrlqd5 A goroutine is stuck trying to deliver a response: ``` goroutine 9632 [select, 29 minutes]: github.com/ethereum/go-ethereum/eth/protocols/eth.(*Peer).dispatchResponse(0x314f100, 0x3e5f6d0, 0x3acbb84) C:/projects/go-ethereum/eth/protocols/eth/dispatcher.go:172 +0x2a5 github.com/ethereum/go-ethereum/eth/protocols/eth.handleBlockHeaders({0x12abe68, 0x30021b8}, {0x12a815c, 0x40b41c0}, 0x314f100) C:/projects/go-ethereum/eth/protocols/eth/handlers.go:301 +0x173 github.com/ethereum/go-ethereum/eth/protocols/eth.handleMessage({0x12abe68, 0x30021b8}, 0x314f100) C:/projects/go-ethereum/eth/protocols/eth/handler.go:205 +0x4f6 github.com/ethereum/go-ethereum/eth/protocols/eth.Handle({0x12abe68, 0x30021b8}, 0x314f100) C:/projects/go-ethereum/eth/protocols/eth/handler.go:149 +0x33 github.com/ethereum/go-ethereum/eth.testSnapSyncDisabling.func1(0x314f100) C:/projects/go-ethereum/eth/sync_test.go:65 +0x33 github.com/ethereum/go-ethereum/eth.(*handler).runEthPeer(0x30021b8, 0x314f100, 0x427f648) C:/projects/go-ethereum/eth/handler.go:355 +0xe65 created by github.com/ethereum/go-ethereum/eth.testSnapSyncDisabling in goroutine 11 C:/projects/go-ethereum/eth/sync_test.go:64 +0x54f FAIL github.com/ethereum/go-ethereum/eth 1800.138s ``` --------- Co-authored-by: Gary Rong <[email protected]>
Fixes a couple of js-flaws in the docs
This change fixes is a rare bug in test generator: If the run is very unlucky it can use `modifyAccountOp` / `deleteAccountOp` without creating any account, leading to have a trie root same as the parent. This change makes the first operation always be a creation.
Passing `*tracing.Hooks` makes the intent clearer and ensure the `applyTransaction` controls the creationg of the `vm.Config`.
As the node hash scheme in verkle and merkle are totally different, the original default node hasher in pathdb is no longer suitable. Therefore, this pull request configures different node hasher respectively.
This PR upgrades `golangci-lint` to v1.63.4 and fixes a warn message
which is reported by v1.63.4:
```text
WARN [config_reader] The configuration option `run.skip-dirs-use-default` is deprecated, please use `issues.exclude-dirs-use-default`.
```
Also fixes 2 warnings which are reported by v1.63.4:
```text
core/txpool/blobpool/blobpool.go:1754:12: S1005: unnecessary assignment to the blank identifier (gosimple)
for acct, _ := range p.index {
^
core/txpool/legacypool/legacypool.go:1989:19: S1005: unnecessary assignment to the blank identifier (gosimple)
for localSender, _ := range pool.locals.accounts {
^
```
Fix the error comparison in tracer to prevent dropping revert reason data --------- Co-authored-by: Martin <[email protected]> Co-authored-by: rjl493456442 <[email protected]>
This PR builds on #29040 and updates it to the new version of the spec. I filled the EEST tests and they pass. Link to spec: https://eips.ethereum.org/EIPS/eip-7623 --------- Co-authored-by: Marius van der Wijden <[email protected]> Co-authored-by: lightclient <[email protected]> Co-authored-by: lightclient <[email protected]>
Finalize Prague system contract addresses. Reference: * ethereum/EIPs#9287 * ethereum/EIPs#9288 * ethereum/EIPs#9289
I caught this error on Hive. It was introduced by ethereum/go-ethereum#31071 because after adding the equality check the request type 0 will be rejected.
Removes duplicate code in the interpreter loop.
Fixes a typo in the error message within the `fuzzCrossG2Add` function. The panic message incorrectly references "G1 point addition mismatch" when it should be "G2 point addition mismatch," as the function deals with G2 points. This doesn't affect functionality but could cause confusion during debugging. I've updated the message to reflect the correct curve.
This is a follow-up PR to #29792 to get rid of the data file sync. **This is a non-backward compatible change, which increments the database version from 8 to 9**. We introduce a flushOffset for each freezer table, which tracks the position of the most recently fsync’d item in the index file. When this offset moves forward, it indicates that all index entries below it, along with their corresponding data items, have been properly persisted to disk. The offset can also be moved backward when truncating from either the head or tail of the file. Previously, the data file required an explicit fsync after every mutation, which was highly inefficient. With the introduction of the flush offset, the synchronization strategy becomes more flexible, allowing the freezer to sync every 30 seconds instead. The data items above the flush offset are regarded volatile and callers must ensure they are recoverable after the unclean shutdown, or explicitly sync the freezer before any proceeding operations. --------- Co-authored-by: Felix Lange <[email protected]>
This PR fixes a data race in SetupGenesisWithOverride.
This PR defines the Osaka fork. An easy first step to start our work on the next hardfork (This is needed for EOF testing as well) --------- Co-authored-by: lightclient <[email protected]>
Implements [EIP-7840](ethereum/EIPs#9129) and [EIP-7691](https://github.com/ethereum/EIPs/blob/d96625a4dcbbe2572fa006f062bd02b4582eefd5/EIPS/eip-7691.md). --------- Co-authored-by: Marius van der Wijden <[email protected]> Co-authored-by: Felix Lange <[email protected]>
…067) I hit this case while trying something with the simulated backend. The EVM only enables instruction set forks after the merge when 'Random' is set. In the simulated backend, the random value will be set via the engine API for all blocks after genesis. But for the genesis block itself, the random value will not be assigned in the vm.BlockContext because the genesis has a non-zero difficulty. For my case, this meant that estimateGas did not work for the first transaction sent on the simulated chain, since the contract contained a PUSH0 instruction. This could also be fixed by explicitly configuring a zero difficulty in the simulated backend. However, I think that zero difficulty is a better default these days. --------- Co-authored-by: lightclient <[email protected]>
Replaces #29297, descendant from #27535 --------- This PR removes `locals` as a concept from transaction pools. Therefore, the pool now acts as very a good simulation/approximation of how our peers' pools behave. What this PR does instead, is implement a locals-tracker, which basically is a little thing which, from time to time, asks the pool "did you forget this transaction?". If it did, the tracker resubmits it. If the txpool _had_ forgotten it, chances are that the peers had also forgotten it. It will be propagated again. Doing this change means that we can simplify the pool internals, quite a lot. ### The semantics of `local` Historically, there has been two features, or usecases, that has been combined into the concept of `locals`. 1. "I want my local node to remember this transaction indefinitely, and resubmit to the network occasionally" 2. "I want this (valid) transaction included to be top-prio for my miner" This PR splits these features up, let's call it `1: local` and `2: prio`. The `prio` is not actually individual transaction, but rather a set of `address`es to prioritize. The attribute `local` means it will be tracked, and `prio` means it will be prioritized by miner. For `local`: anything transaction received via the RPC is marked as `local`, and tracked by the tracker. For `prio`: any transactions from this sender is included first, when building a block. The existing commandline-flag `--txpool.locals` sets the set of `prio` addresses. --------- Co-authored-by: Gary Rong <[email protected]>
Fixes the linter on master which was broken by ethereum/go-ethereum#30559
A clarification was made to EIP-7691 stating that at the fork boundary it is required to use the target blob count associated with the head block, rather than the parent as implemented here. See for more: ethereum/EIPs#9249
merge v1.5.4-beta back to develop branch
upstream: merge geth date 0205
galaio
approved these changes
Feb 7, 2025
buddh0
approved these changes
Feb 7, 2025
zlacfzy
approved these changes
Feb 7, 2025
unclezoro
approved these changes
Feb 7, 2025
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.
Description
It is another maintenance release to support Pascal hard fork.
Changes
v1.5.5 mainly did a upstream code sync, it catches up to Geth of date around 5th-Feb-2025 to sync the latest Praque hard fork changes, see: #2856
Besides the code sync, there are a few improvement PRs of BSC:
IMPROVEMENT