-
Notifications
You must be signed in to change notification settings - Fork 141
[build-295] Improve Builder submission rate #70
Conversation
… limit, update submit logic such that submissions happen near end of slot
| args.limiter = rate.NewLimiter(rate.Every(RateLimitIntervalDefault), RateLimitBurstDefault) | ||
| } | ||
|
|
||
| if args.builderBlockResubmitInterval == 0 { |
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 wonder if this shouldn't be the caller's responsibility (same for the above)
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 wonder if this shouldn't be the caller's responsibility (same for the above)
I have it in both places. In general I agree with you re: caller's responsibility. However I would want to return an error for invalid inputs but the function signature would need to be updated. I didn't want to do that work in this PR - happy to discuss
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'd make it the responsibility of the caller still, since you don't really validate the value
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'd make it the responsibility of the caller still, since you don't really validate the value
For now what's wrong with having it in both places? I'm worried that without the defensive check in the receiver, we can easily have a resubmit interval of 0. A resubmit interval of 0 could cause some very strange and difficult to debug behavior since we're using it for retry loop. My preference would rather be to refactor the function signature in the future such that a 0 value returns an error.
| args.limiter = rate.NewLimiter(rate.Every(RateLimitIntervalDefault), RateLimitBurstDefault) | ||
| } | ||
|
|
||
| if args.builderBlockResubmitInterval == 0 { |
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'd make it the responsibility of the caller still, since you don't really validate the value
| if parentBlock == nil { | ||
| log.Warn("Block hash not found in blocktree", "head block hash", attrs.HeadHash) | ||
| return errors.New("parent block not found in blocktree") | ||
| return fmt.Errorf("parent block hash not found in block tree given head block hash %s", attrs.HeadHash) |
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.
Is HeadHash a string? Same for vd.Pubkey couple lines above
builder/builder.go
Outdated
| // Avoid submitting early into a given slot. For example if slots have 12 second interval, submissions should | ||
| // not begin until 8 seconds into the slot. | ||
| slotTime := time.Unix(int64(attrs.Timestamp), 0).UTC() | ||
| submitTime := slotTime.Add(-SubmissionDelaySecondsDefault) |
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 find this a bit strange
I'm not sure if the semantics work out, since we don't actually know what's the submit time - here it's defined as slot time - submission delay, which could use a different name. Maybe slot sumission start time? Also the time is not really a delay, it's actually the other way around - its something like a ramp up time
I'd also add a sanity check for attrs.Timestamp < SubmissionDelaySecondsDefault.
| waitUntilSubmitTime = func(waitUntil time.Time) (ok bool) { | ||
| now := time.Now().UTC() | ||
| if waitUntil.UTC().Before(now) { | ||
| waitUntil = now |
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.
shouldn't this just be return true?
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.
not necessarily i think - in the time the function is invoked i want to make sure the context hasn't been cancelled
- Prior to change, builder submissions happened roughly between ~t-11 to ~t+3 where t is the time of slot s - After change, builder submissions happen roughly between ~t-4 to ~t+3, which is desired * Add bug fix for rate limit * Expose environment variables that adjust builder rate limit and burst limit, update submit logic such that submissions happen near end of slot * Update submit loop function * Update conditional in resubmit loop * Update rate limit variable name * Create constant for default burst on builder rate limit * Use CLI flags instead of bespoke environment variables for builder rate limit settings * Fix typo * Update logs for more data analysis * Expose builder block resubmit interval as CLI flag and environment variable * Update variable name for default builder block resubmit interval * Fix wait time when timestamp is not passed in to address failures in unit tests * Update README * Update comments * Fix when error log occurs * Update log * Update check * Update go mod
📝 Summary
FLASHBOTS_BUILDER_RATE_LIMIT_DURATIONandFLASHBOTS_BUILDER_BURST_LIMITenvironment variables🧪 Testing
Without builder submission change
With builder submission change
TL;DR
📚 References
CONTRIBUTING.md