The upstream libray has removed the assembly-based implementation of
keccak. We need to maintain our own library to avoid a peformance
regression.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
Co-authored-by: lightclient <lightclient@protonmail.com>
The `decodeRef` function used `size > hashLen` to reject oversized
embedded nodes, but this incorrectly allowed nodes of exactly 32 bytes
through. The encoding side (hasher.go, stacktrie.go) consistently uses
`len(enc) < 32` to decide whether to embed a node inline, meaning nodes
of 32+ bytes are always hash-referenced. The error message itself
already stated `want size < 32`, confirming the intended threshold.
Changed `size > hashLen` to `size >= hashLen` in `decodeRef` to align
the decoding validation with the encoding logic, the Yellow Paper spec,
and the surrounding comments.
Co-authored-by: sashass1315 <sashass1315@gmail.com>
This adds a new type wrapper that decodes as a list, but does not
actually decode the contents of the list. The type parameter exists as a
marker, and enables decoding the elements lazily. RawList can also be
used for building a list incrementally.
Co-authored-by: Felix Lange <fjl@twurst.com>
Follow-up to https://github.com/ethereum/go-ethereum/pull/33748
Same issue - ResettingTimer can be registered via loadOrRegister() but
GetAll() silently drops it during JSON export. The prometheus exporter
handles it fine (collector.go:70), so this is just an oversight in the
JSON path.
Note: ResettingTimer.Snapshot() resets the timer by design, which is
consistent with how the prometheus exporter uses it.
Co-authored-by: vickkkkkyy <vickyaviles847@gmail.com>
* use signer pubkey to check for unique signatures and optimize performance
* change waitgroup to errgroup
* optimize
* fix typo
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* format files
* after rebase new commits, refactor from snap.NextEpochCandidates to epochInfo.Masternodes
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* revert: use masternodes from snapshot to verify vote
* fix underflow during chain initialization
* add previously removed test
* rename snapshot > snap for consistency
traceBlockParallel replays transactions from the parent state to build per-tx prestate for tracers. In the previous flow, Prague's parent-hash system contract processing was not applied before replay, so the prepared state could diverge from canonical block execution semantics.
This commit keeps the parallel tracing path consistent with block processing rules by applying ProcessParentBlockHash before tx replay when Prague is active.
The regression test TestTraceBlockParallelPragueParentHashSystemCall is strengthened to assert the actual EIP-2935 history slot value (ring-buffer key for block-1) equals block.ParentHash(), instead of relying on an indirect EXTCODESIZE side effect. This makes the test deterministic and directly tied to the bug.
Validation: go test ./eth/tracers -run TestTraceBlockParallelPragueParentHashSystemCall
The TestCountdownShouldBeAbleToStop test was failing intermittently due to
a race condition in the StopTimer() implementation. Previously, the goroutine
used defer to set initilised=false, which executed after close(q) signaled
completion to StopTimer(). This allowed StopTimer() to return before the
state was properly cleaned up, causing isInitilised() checks to occasionally
see stale true values.
Fixed by explicitly calling setInitilised(false) before close(q), ensuring
the state is updated atomically before StopTimer() returns. This eliminates
the race condition and makes the test pass consistently.
Verified by running the test 30 times consecutively with no failures.
This fixes a data race when accessing the `httpConfig.prefix` field.
This field can be modified while the server is running through
`enableRPC`. The fix is storing the prefix in the handler, which is
accessed through the atomic pointer.
alternative to #32035
fixes https://github.com/ethereum/go-ethereum/issues/32019
Co-authored-by: Felix Lange <fjl@twurst.com>
This PR fixes a flaky jwt-test.
The test is a jwt "from one second in the future". The test passes; the
reason for this is that the CI-system is slow, and by the time the jwt
is actually evaluated, that second has passed, and it's no longer
future.
Alternative to #30380
Co-authored-by: Martin HS <martin@swende.se>
