Skip to content

Conversation

pull[bot]
Copy link

@pull pull bot commented Feb 28, 2020

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot added the ⤵️ pull label Feb 28, 2020
@pull pull bot added the merge-conflict Resolve conflicts manually label Mar 27, 2020
fjl and others added 26 commits August 14, 2025 13:07
…32366)

This add some of the changes that were missing from #31634. It
introduces the `TransitionTrie`, which is a façade pattern between the
current MPT trie and the overlay tree.

---------

Signed-off-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com>
Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
This is a preparatory change for Verkle/binary trees, since they don't
support the hash-based database scheme. This has no impact on the MPT.
This changes the implementation to resolve the blob parameters according
to the current header timestamp. This matters for EIP-7918, where we
would previously resolve the UpdateFraction according to the parent
header fork, leading to a confusing situation at the fork transition
block.

---------

Co-authored-by: MariusVanDerWijden <m.vanderwijden@live.de>
As of Go 1.19, it is permitted to call Bytes() on a reflect.Value
representing an adressable byte array. So we can remove our workaround,
undoing #22924.

https://go.dev/doc/go1.19#reflectpkgreflect

> The method [Value.Bytes](https://go.dev/pkg/reflect/#Value.Bytes) now
accepts addressable arrays in addition to slices.
The order of the checks was wrong which would have allowed a call to
modexp with `baseLen == 0 && modLen == 0` post fusaka.

Also handles an edge case where base/mod/exp length >= 2**64

---------

Co-authored-by: Felix Lange <fjl@twurst.com>
Continuation of #32022

tablewriter assumes unix or windows, which may not be the case for
embedded targets.

For v0.0.5 of tablewriter, it is noted in table.go: "The protocols were
written in pure Go and works on windows and unix systems"

---------

Co-authored-by: rjl493456442 <garyrong0905@gmail.com>
Exposing the public method to setReadLimits for Websocket RPC to
prevent OOM.

Current, Geth Server is using a default 32MB max read limit (message
size) for websocket, which is prune to being attacked for OOM. Any one
can easily launch a client to send a bunch of concurrent large request
to cause the node to crash for OOM. One example of such script that can
easily crash a Geth node running websocket server is like this:

https://gist.githubusercontent.com/DeltaXV/b64d221e342e9c1ec6c99c1ab8201544/raw/ec830979ac9a707d98f40dfcc0ce918fc8fb9057/poc.go

---------

Co-authored-by: Felix Lange <fjl@twurst.com>
## Summary

This PR addresses a DoS vulnerability in the GraphQL service by
implementing a maximum query depth limit. While #26026 introduced
timeout handling, it didn't fully mitigate the attack vector where
deeply nested queries can still consume excessive CPU and memory
resources before the timeout is reached.

## Changes
- Added `maxQueryDepth` constant (set to 20) to limit the maximum
nesting depth of GraphQL queries
- Applied the depth limit using `graphql.MaxDepth()` option when parsing
the schema
- Added test case `TestGraphQLMaxDepth` to verify that queries exceeding
the depth limit are properly rejected

## Security Impact

Without query depth limits, malicious actors could craft deeply nested
queries that:
  - Consume excessive CPU cycles during query parsing and execution
  - Allocate large amounts of memory for nested result structures
- Potentially cause service degradation or outages even with timeout
protection

This fix complements the existing timeout mechanism by preventing
resource-intensive queries from being executed in the first place.

## Testing

Added `TestGraphQLMaxDepth` which verifies that queries with nesting
depth > 20 are rejected with a `MaxDepthExceeded` error.

## References
  - Original issue: #26026
- Related security best practices:
https://www.howtographql.com/advanced/4-security/

---------

Co-authored-by: Felix Lange <fjl@twurst.com>
Return the exposed methods in `ConsensusAPI` by reflection.
)

This pull introduces a `Prefetch` operation in the trie to prefetch trie
nodes in parallel. It is used by the `triePrefetcher` to accelerate state 
loading and improve overall chain processing performance.
Co-authored-by: Felix Lange <fjl@twurst.com>
Fixes #32181

Signed-off-by: kapil <kapilsareen584@gmail.com>
rjl493456442 and others added 30 commits October 10, 2025 14:51
It's a pull request based on the #32523 , implementing the structure of
trienode history.
Add `SubscribeTransactionReceipts` for ethclient. This is a complement
to #32697.
```
goos: darwin
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/types
cpu: VirtualApple @ 2.50GHz
                                 │   old.txt    │               new.txt               │
                                 │    sec/op    │   sec/op     vs base                │
CreateBloom/small-createbloom-10    1.676µ ± 4%   1.646µ ± 1%   -1.76% (p=0.000 n=10)
CreateBloom/large-createbloom-10    164.8µ ± 3%   164.3µ ± 0%        ~ (p=0.247 n=10)
CreateBloom/small-mergebloom-10    231.60n ± 0%   68.00n ± 0%  -70.64% (p=0.000 n=10)
CreateBloom/large-mergebloom-10    21.803µ ± 3%   5.107µ ± 1%  -76.58% (p=0.000 n=10)
geomean                             6.111µ        3.113µ       -49.06%

                                 │    old.txt     │                new.txt                │
                                 │      B/op      │     B/op      vs base                 │
CreateBloom/small-createbloom-10     112.0 ± 0%       112.0 ± 0%       ~ (p=1.000 n=10) ¹
CreateBloom/large-createbloom-10   10.94Ki ± 0%     10.94Ki ± 0%       ~ (p=0.474 n=10)
CreateBloom/small-mergebloom-10      0.000 ± 0%       0.000 ± 0%       ~ (p=1.000 n=10) ¹
CreateBloom/large-mergebloom-10      0.000 ± 0%       0.000 ± 0%       ~ (p=1.000 n=10) ¹
geomean                                         ²                 +0.00%                ²
¹ all samples are equal
² summaries must be >0 to compute geomean

                                 │   old.txt    │               new.txt               │
                                 │  allocs/op   │ allocs/op   vs base                 │
CreateBloom/small-createbloom-10   6.000 ± 0%     6.000 ± 0%       ~ (p=1.000 n=10) ¹
CreateBloom/large-createbloom-10   600.0 ± 0%     600.0 ± 0%       ~ (p=1.000 n=10) ¹
CreateBloom/small-mergebloom-10    0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
CreateBloom/large-mergebloom-10    0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
geomean                                       ²               +0.00%                ²
¹ all samples are equal
² summaries must be >0 to compute geomean
```
Fix #32893.

In the previous #32794, it
only handles the pending tx filter, while there are also head and log
filters. This PR applies the patch to all filter APIs and uses `defer`
to maintain code consistency.
This PR implements the partial read functionalities in the freezer, optimizing
the state history reader by resolving less data from freezer.

---------

Signed-off-by: jsvisa <delweng@gmail.com>
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
This speeds up LogDist by 75% using 64-bit operations instead
of byte-wise XOR.

---------

Co-authored-by: Felix Lange <fjl@twurst.com>
This speeds up DistCmp by 75% through using 64-bit operations instead of
byte-wise XOR.
This PR move the queue out of the main transaction pool.
For now there should be no functional changes.
I see this as a first step to refactor the legacypool and make the queue
a fully separate concept from the main pending pool.

---------

Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
Co-authored-by: Csaba Kiraly <csaba.kiraly@gmail.com>
This PR adds a `filterfuzz` subcommand to the workload tester that
generates requests similarly to `filtergen` (though with a much smaller
block length limit) and also verifies the results by retrieving all
block receipts in the range and locally filtering out relevant results.
Unlike `filtergen` that operates on the finalized chain range only,
`filterfuzz` does check the head region, actually it seeds a new query
at every new chain head.
This ensures the node is ready to accept other nodes into the
table before it is used in a test.

Closes #32863
The limit check for `MaxUint32` is done after the cast to `int`. On 64
bits machines, that will work without a problem. On 32 bits machines,
that will always fail. The compiler catches it and refuses to build.

Note that this only fixes the compiler build. ~~If the limit is above
`MaxInt32` but strictly below `MaxUint32` then this will fail at runtime
and we have another issue.~~ I checked and this should not happen during
regular execution, although it might happen in tests.
This happens normally after a restart, so it is better to use Info level
here.

Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
This pr addresses a few issues brought by the #32270 

- Add updates to pricedList after dropping transactions.
- Remove redundant deletions in queue.evictList, since
pool.removeTx(hash, true, true) already performs the removal.
- Prevent duplicate addresses during promotion when Reset is not nil.
…32849)

This adds a temporary conversion path for blob transactions with legacy
proof sidecar. This feature will activate after Fusaka. We will phase
this out when the fork has sufficiently settled and client side
libraries have been upgraded to send the new proofs.
…peer (#32728)

Drop peer if sending the same transaction multiple times in a single message.

Fixes #32724


---------

Signed-off-by: Csaba Kiraly <csaba.kiraly@gmail.com>
Co-authored-by: Gary Rong <garyrong0905@gmail.com>
Co-authored-by: Csaba Kiraly <csaba.kiraly@gmail.com>
This fixes a regression introduced in #32518. In that PR, we removed the
slowdown logic that would throttle lookups when the table runs empty.
Said logic was originally added in #20389.

Usually it's fine, but there exist pathological cases, such as hive
tests, where the node can only discover one other node, so it can only
ever query that node and won't get any results. In cases like these, we
need to throttle the creation of lookups to avoid crazy CPU usage.
Fix logging in the verkle dump path to report the actual key being
processed.
Previously, the loop always logged keylist[0], which misled users when
expanding multiple keys and made debugging harder. This change aligns
the
log with the key passed to root.Get, improving traceability and
diagnostics.
Adds ethclient support for the eth_simulateV1 RPC method, which allows
simulating transactions on top of a base state without making changes to
the blockchain.

---------

Co-authored-by: Sina Mahmoodi <itz.s1na@gmail.com>
New RPC method eth_sendRawTransactionSync(rawTx, timeoutMs?) that
submits a signed tx and blocks until a receipt is available or a timeout
elapses.

Two CLI flags to tune server-side limits:

--rpc.txsync.defaulttimeout (default wait window)

--rpc.txsync.maxtimeout (upper bound; requests are clamped)

closes #32094

---------

Co-authored-by: aodhgan <gawnieg@gmail.com>
Co-authored-by: Sina Mahmoodi <itz.s1na@gmail.com>
This change addresses critical issues in the state object duplication
process specific to Verkle trie implementations. Without these
modifications, updates to state objects fail to propagate correctly
through the trie structure after a statedb copy operation, leading to
inaccuracies in the computation of the state root hash.

---------

Co-authored-by: Guillaume Ballet <3272758+gballet@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

⤵️ pull merge-conflict Resolve conflicts manually

Projects

None yet

Development

Successfully merging this pull request may close these issues.