-
Notifications
You must be signed in to change notification settings - Fork 12
Bsp-geth-DTM-RC:v2.3.0 #256
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
Closed
Conversation
This file contains hidden or 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
goos: darwin
goarch: arm64
pkg: github.com/ethereum/go-ethereum/rlp
cpu: Apple M4
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Intsize 2.175n ± 5% 1.050n ± 4% -51.76% (p=0.000 n=10)
**Problem:** Including full account code in prestateTracer response significantly increases response payload size. **Solution:** Add codeHash field to the response. This will allow client-side bytecode caching and is a non-breaking change. **Note:** codeHash for EoAs is excluded to save space. --------- Co-authored-by: Sina Mahmoodi <[email protected]>
avaibale -> available
…(#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 <[email protected]> Co-authored-by: rjl493456442 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Continuation of ethereum/go-ethereum#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 <[email protected]>
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 <[email protected]>
## 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 <[email protected]>
Return the exposed methods in `ConsensusAPI` by reflection.
…134) 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 <[email protected]>
Fixes #32181 Signed-off-by: kapil <[email protected]>
invalidTxMeter was counting txs, while validTxMeter was counting accounts. Better make the two comparable. --------- Signed-off-by: Csaba Kiraly <[email protected]>
It's a pull request based on the #32523 , implementing the structure of trienode history.
Add `SubscribeTransactionReceipts` for ethclient. This is a complement to ethereum/go-ethereum#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 ethereum/go-ethereum#32893. In the previous ethereum/go-ethereum#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 <[email protected]> Co-authored-by: Gary Rong <[email protected]>
This speeds up LogDist by 75% using 64-bit operations instead of byte-wise XOR. --------- Co-authored-by: Felix Lange <[email protected]>
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 <[email protected]> Co-authored-by: Csaba Kiraly <[email protected]>
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 <[email protected]>
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.
…oceeding with transfer (#32374) remove todo
…#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 ethereum/go-ethereum#32724 --------- Signed-off-by: Csaba Kiraly <[email protected]> Co-authored-by: Gary Rong <[email protected]> Co-authored-by: Csaba Kiraly <[email protected]>
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.
Signed-off-by: Pranay Valson <[email protected]>
Member
Author
|
Closing in favor of #258 |
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.
Migrate to geth v1.16.7 with cherry-picked BSP v2.3.0 patches