geth upstream v1.16.7#1974
Conversation
Fix outdated comments
Bail out of decodeHash when the raw hex string is longer than 32 byte before actually decoding. --------- Co-authored-by: lightclient <lightclient@protonmail.com>
Decode the modified transaction and verify the value differs from original. --------- Co-authored-by: lightclient <lightclient@protonmail.com>
Fix incorrect error messages in TestVerkleTreeReadWrite and TestVerkleRollBack functions.
Introduces a new tracer which returns the preimages of evm KECCAK256 hashes. See #32570. --------- Co-authored-by: Sina M <1591639+s1na@users.noreply.github.com> Co-authored-by: Sina Mahmoodi <itz.s1na@gmail.com>
Adds Amsterdam as fork config option. Co-authored-by: lightclient <lightclient@protonmail.com>
ref https://github.com/ethereum/execution-apis/blob/main/src/engine/osaka.md#cancun-api > Client software MUST return -38005: Unsupported fork error if the Osaka fork has been activated. --------- Signed-off-by: Delweng <delweng@gmail.com> Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
Fixes an error message in TestReplication
Removes a redundant check in TestCreateAccessListWithStateOverrides
These functions were previously ignoring the error returned by both `statedb.Commit()` and the subsequent `state.New()`, which could silently fail and cause panics later when the `statedb` is used. This change adds proper error checking and panics with a descriptive error message if state creation fails. While unlikely in normal operation, this can occur if there are database corruption issues or if invalid root hashes are provided, making debugging significantly easier when such issues do occur. This issue was encountered and fixed in gballet/go-ethereum#552 where the error handling proved essential for debugging cc: @gballet as this was discussed in a call already.
Looks like we forgot to update names when copying.
- Replace outdated NewFreezer doc that referenced map[string]bool/snappy toggle with accurate description of -map[string]freezerTableConfig (noSnappy, prunable). - Fix misleading field comment on freezerTable.config that spoke as if it were a boolean (“if true”), clarifying it’s a struct and noting compression is non-retroactive.
Fixes issue #32762 where ChainConfig logging displays pointer addresses instead of actual timestamp values for fork activation times. Before: ShanghaiTime:(*uint64)(0xc000373fb0), CancunTime:(*uint64)(0xc000373fb8) After: ShanghaiTime: 1681338455, CancunTime: 1710338135, VerkleTime: nil The String() method properly dereferences timestamp pointers and handles nil values for unset fork times, making logs more readable and useful for debugging chain configuration issues. --------- Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
Extend the chain banner with blob config information. Co-authored-by: Felix Lange <fjl@twurst.com>
The TxPool.signer field was never read and each subpool (legacy/blob) maintains its own signer instance. This field remained after txpool refactoring into subpools and is dead code. Removing it reduces confusion and simplifies the constructor.
This is required for geth to compile to WASM.
… (#32800) This PR updates the `payloadVersion` function in `simulated_beacon.go` to handle additional following forks used during development and testing phases after Osaka. This change ensures that the simulated beacon correctly resolves the payload version for these forks, enabling consistent and valid execution payload handling during local testing or simulation.
Alternative to #30746, potential follow-up to #30743 . This PR makes the
stacktrie always copy incoming value buffers, and reuse them internally.
Improvement in #30743:
```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
│ derivesha.1 │ derivesha.2 │
│ sec/op │ sec/op vs base │
DeriveSha200/stack_trie-8 477.8µ ± 2% 430.0µ ± 12% -10.00% (p=0.000 n=10)
│ derivesha.1 │ derivesha.2 │
│ B/op │ B/op vs base │
DeriveSha200/stack_trie-8 45.17Ki ± 0% 25.65Ki ± 0% -43.21% (p=0.000 n=10)
│ derivesha.1 │ derivesha.2 │
│ allocs/op │ allocs/op vs base │
DeriveSha200/stack_trie-8 1259.0 ± 0% 232.0 ± 0% -81.57% (p=0.000 n=10)
```
This PR further enhances that:
```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
│ derivesha.2 │ derivesha.3 │
│ sec/op │ sec/op vs base │
DeriveSha200/stack_trie-8 430.0µ ± 12% 423.6µ ± 13% ~ (p=0.739 n=10)
│ derivesha.2 │ derivesha.3 │
│ B/op │ B/op vs base │
DeriveSha200/stack_trie-8 25.654Ki ± 0% 4.960Ki ± 0% -80.67% (p=0.000 n=10)
│ derivesha.2 │ derivesha.3 │
│ allocs/op │ allocs/op vs base │
DeriveSha200/stack_trie-8 232.00 ± 0% 37.00 ± 0% -84.05% (p=0.000 n=10)
```
So the total derivesha-improvement over *both PRS* is:
```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
│ derivesha.1 │ derivesha.3 │
│ sec/op │ sec/op vs base │
DeriveSha200/stack_trie-8 477.8µ ± 2% 423.6µ ± 13% -11.33% (p=0.015 n=10)
│ derivesha.1 │ derivesha.3 │
│ B/op │ B/op vs base │
DeriveSha200/stack_trie-8 45.171Ki ± 0% 4.960Ki ± 0% -89.02% (p=0.000 n=10)
│ derivesha.1 │ derivesha.3 │
│ allocs/op │ allocs/op vs base │
DeriveSha200/stack_trie-8 1259.00 ± 0% 37.00 ± 0% -97.06% (p=0.000 n=10)
```
Since this PR always copies the incoming value, it adds a little bit of
a penalty on the previous insert-benchmark, which copied nothing (always
passed the same empty slice as input) :
```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/trie
cpu: 12th Gen Intel(R) Core(TM) i7-1270P
│ stacktrie.7 │ stacktrie.10 │
│ sec/op │ sec/op vs base │
Insert100K-8 88.21m ± 34% 92.37m ± 31% ~ (p=0.280 n=10)
│ stacktrie.7 │ stacktrie.10 │
│ B/op │ B/op vs base │
Insert100K-8 3.424Ki ± 3% 4.581Ki ± 3% +33.80% (p=0.000 n=10)
│ stacktrie.7 │ stacktrie.10 │
│ allocs/op │ allocs/op vs base │
Insert100K-8 22.00 ± 5% 26.00 ± 4% +18.18% (p=0.000 n=10)
```
---------
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
Co-authored-by: Felix Lange <fjl@twurst.com>
Description: We found a occasionally node hang issue on BSC, I think Geth may also have the issue, so pick the fix patch here. The fix on BSC repo: bnb-chain/bsc#3347 When the hang occurs, there are two routines stuck. - routine 1: AsyncFilter(...) On node start, it will run part of the DiscoveryV4 protocol, which could take considerable time, here is its hang callstack: ``` goroutine 9711 [chan receive]: // this routine was stuck on read channel: `<-f.slots` github.com/ethereum/go-ethereum/p2p/enode.AsyncFilter.func1() github.com/ethereum/go-ethereum/p2p/enode/iter.go:206 +0x125 created by github.com/ethereum/go-ethereum/p2p/enode.AsyncFilter in goroutine 1 github.com/ethereum/go-ethereum/p2p/enode/iter.go:192 +0x205 ``` - Routine 2: Node Stop It is the main routine to shutdown the process, but it got stuck when it tries to shutdown the discovery components, as it tries to drain the channel of `<-f.slots`, but the extra 1 slot will never have chance to be resumed. ``` goroutine 11796 [chan receive]: github.com/ethereum/go-ethereum/p2p/enode.(*asyncFilterIter).Close.func1() github.com/ethereum/go-ethereum/p2p/enode/iter.go:248 +0x5c sync.(*Once).doSlow(0xc032a97cb8?, 0xc032a97d18?) sync/once.go:78 +0xab sync.(*Once).Do(...) sync/once.go:69 github.com/ethereum/go-ethereum/p2p/enode.(*asyncFilterIter).Close(0xc092ff8d00?) github.com/ethereum/go-ethereum/p2p/enode/iter.go:244 +0x36 github.com/ethereum/go-ethereum/p2p/enode.(*bufferIter).Close.func1() github.com/ethereum/go-ethereum/p2p/enode/iter.go:299 +0x24 sync.(*Once).doSlow(0x11a175f?, 0x2bfe63e?) sync/once.go:78 +0xab sync.(*Once).Do(...) sync/once.go:69 github.com/ethereum/go-ethereum/p2p/enode.(*bufferIter).Close(0x30?) github.com/ethereum/go-ethereum/p2p/enode/iter.go:298 +0x36 github.com/ethereum/go-ethereum/p2p/enode.(*FairMix).Close(0xc0004bfea0) github.com/ethereum/go-ethereum/p2p/enode/iter.go:379 +0xb7 github.com/ethereum/go-ethereum/eth.(*Ethereum).Stop(0xc000997b00) github.com/ethereum/go-ethereum/eth/backend.go:960 +0x4a github.com/ethereum/go-ethereum/node.(*Node).stopServices(0xc0001362a0, {0xc012e16330, 0x1, 0xc000111410?}) github.com/ethereum/go-ethereum/node/node.go:333 +0xb3 github.com/ethereum/go-ethereum/node.(*Node).Close(0xc0001362a0) github.com/ethereum/go-ethereum/node/node.go:263 +0x167 created by github.com/ethereum/go-ethereum/cmd/utils.StartNode.func1.1 in goroutine 9729 github.com/ethereum/go-ethereum/cmd/utils/cmd.go:101 +0x78 ``` The rootcause of the hang is caused by the extra 1 slot, which was designed to make sure the routines in `AsyncFilter(...)` can be finished. This PR fixes it by making sure the extra 1 shot can always be resumed when node shutdown.
This pr implements ethereum/go-ethereum#32733 to make StateProcessor more customisable. ## Compatibility notes This introduces a breaking change to users using geth EVM as a library. The `NewStateProcessor` function now takes one parameter which has the chainConfig embedded instead of 2 parameters.
just finisher the sentence Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
It uses the slices.Concat and slices.Clone methods available now in Go.
Adds blockTimestamp to the logs in response of eth_simulateV1. --------- Co-authored-by: Sina Mahmoodi <itz.s1na@gmail.com>
This PR does a few things: - Sets the gh actions runner sizes for lint (s) and test (l) workflows - Runs the tests on gh actions in parallel - Skips fetching the spec tests when unnecessary (on windows in appveyor) - Removes ubuntu appveyor runner since it's essentially duplicate of the gh action workflow now The gh test seems to go down from ~35min to ~13min.
fixed |
Code Review (Follow-up)Previous issue in Found 2 new issues: Issue 1: Bug in
|
|
@claude good catch, they were inherited from upstream. Fixed now. Rerun your check. |
|
Claude finished @marcello33's task in 32s —— View job Re-running Code Review
✅ All Previous Issues FixedI've verified that all three issues from my previous reviews have been addressed:
No additional bugs or CLAUDE.md violations found in the reviewed code. |
|
@claude Can you review this PR, focusing on safety and performance? Provide a summary as a comment highlighting any concerns related to these changes. |
|
Claude finished @marcello33's task in 1m 39s —— View job Review Complete: Safety and Performance Analysis
SummaryThis PR merges upstream geth v1.16.7 with significant changes across 100 files. The previous issues I identified have been fixed. Overall, the code quality is good with proper error handling throughout. Safety Findings1. Transaction Deduplication Needs Discussion (Medium Priority)Files: There are TODO comments indicating that duplicate transaction rejection needs broader team discussion: // TODO(raneet10): Discuss whether dedup is desirable here
hash := tx.Hash()
if _, exists := seen[hash]; exists {
return fmt.Errorf("Transactions: multiple copies of the same hash %v", hash)
}Concern: The review comment from @manav2401 notes that Bor is considering enabling re-broadcasting, which may conflict with this strict deduplication. This could cause issues with legitimate rebroadcast scenarios. Recommendation: Resolve this TODO before merging to production. The team should decide whether to:
2. SonarQube Security Hotspots (12 items)The SonarQube report indicates 12 security hotspots that should be reviewed. While these are likely inherited from upstream and may be acceptable, they warrant a quick review. 3. Bor-Specific Prague Fork Handling (Informational)File: if p.chainConfig().IsPrague(block.Number()) && p.chainConfig().Bor == nil {EIP-6110, EIP-7002, and EIP-7251 are explicitly disabled for Bor chains. This is intentional and correctly documented in the comment at line 136. Performance Findings1. Transaction Pool Refactoring (Positive)File: The queue management has been extracted into a separate file with cleaner separation of concerns. Key improvements:
2. Keccak Hashing Optimization (Positive)Files: Keccak functions have been refactored with proper 3. Rebroadcast Feature (New)File: New stuck transaction rebroadcast feature with configurable parameters:
Uses RLock for identifying stuck transactions to minimize contention. 4. State History Indexer (New Complex Component)Files: New trienode history storage with efficient index structures. Uses parallel processing with Previously Fixed IssuesAll issues from my previous reviews have been addressed:
Recommendations
|
|
b62e0c6
into
mardizzone/upstream-v1.16.4
Description
PR to merge upstream geth v1.16.7
Changes
Checklist
Testing