-
Notifications
You must be signed in to change notification settings - Fork 60
[proxyd]: Add block range rate limiting, and max block range to non-consensus mode #114
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
base: main
Are you sure you want to change the base?
Changes from all commits
21ccfbb
7e5a2e7
fb1ec6c
f6502d2
8b675dd
c50ca8b
46a357c
b8e377f
c1c75fa
6b0fd49
3f1e55c
d854e76
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
package proxyd | ||
|
||
import ( | ||
"encoding/json" | ||
|
||
"github.com/ethereum/go-ethereum/common/hexutil" | ||
) | ||
|
||
type BlockRange struct { | ||
FromBlock uint64 | ||
ToBlock uint64 | ||
} | ||
|
||
type BlockNumberTracker interface { | ||
GetLatestBlockNumber() (uint64, bool) | ||
GetSafeBlockNumber() (uint64, bool) | ||
GetFinalizedBlockNumber() (uint64, bool) | ||
} | ||
|
||
func ExtractBlockRange(req *RPCReq, tracker BlockNumberTracker) *BlockRange { | ||
switch req.Method { | ||
case "eth_getLogs", "eth_newFilter": | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. eth_newFilter is only appended to a single backend, so it quite difficult to get the results from the requesting the filter through proxyd. We typically don't expose it on proxyd on our end. Curious your experience with it A while ago there was a PR for similar functionality: #105, but I didn't see any interest in at the time. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i guess eth_newFilter is used for overwriting the reqeust parameters, so it makes sense to keep it in here, but still I don't think that method works perfectly |
||
var p []map[string]interface{} | ||
if err := json.Unmarshal(req.Params, &p); err != nil { | ||
return nil | ||
} | ||
fromBlock, hasFrom := p[0]["fromBlock"].(string) | ||
toBlock, hasTo := p[0]["toBlock"].(string) | ||
if !hasFrom && !hasTo { | ||
return nil | ||
} | ||
// if either fromBlock or toBlock is defined, default the other to "latest" if unset | ||
if hasFrom && !hasTo { | ||
toBlock = "latest" | ||
} else if hasTo && !hasFrom { | ||
fromBlock = "latest" | ||
} | ||
from, fromOk := stringToBlockNumber(fromBlock, tracker) | ||
to, toOk := stringToBlockNumber(toBlock, tracker) | ||
if !fromOk || !toOk { | ||
return nil | ||
} | ||
return &BlockRange{ | ||
FromBlock: from, | ||
ToBlock: to, | ||
} | ||
default: | ||
return nil | ||
} | ||
} | ||
|
||
func stringToBlockNumber(tag string, tracker BlockNumberTracker) (uint64, bool) { | ||
switch tag { | ||
case "latest": | ||
return tracker.GetLatestBlockNumber() | ||
case "safe": | ||
return tracker.GetSafeBlockNumber() | ||
case "finalized": | ||
return tracker.GetFinalizedBlockNumber() | ||
case "earliest": | ||
return 0, true | ||
case "pending": | ||
latest, ok := tracker.GetLatestBlockNumber() | ||
return latest + 1, ok | ||
} | ||
d, err := hexutil.DecodeUint64(tag) | ||
return d, err == nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The alternative to this is to disable the non-consensus poller in more tests by setting the
nonconsensus_poller_interval
negative... what do you think? To me it feels like we shouldn't be counting polling towards error rates, but I don't feel strongly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the sliding network requests sliding window should be counted. IRRC, its counted for the consensus_poller, I think it would be odd if it was counted for one strategy but not the other
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally if the poll fails that helps proxyd determine if the backend is unstable at the moment, which is why I'd lean toward tracking the intermittent sliding window error as well