-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Proposer builds block in parallel. (Consensus vs Execution) #12297
Conversation
Could you put this into a new method and use a feature flag? Seems like a risky change to not be able to opt out. |
Could you add any benchmarks or data to help us understand how significant of a reduction in the processing time? |
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.
Requesting changes until we have more data to support the claim of significant reduction in block creation. #12302 will help with this data collection for builder routes.
Co-authored-by: Preston Van Loon <preston@prysmaticlabs.com>
idx, err := helpers.BeaconProposerIndex(ctx, head) | ||
if err != nil { | ||
return nil, fmt.Errorf("could not calculate proposer index %v", err) | ||
} | ||
sBlk.SetProposerIndex(idx) |
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.
Note to the reviewer. The position of setting proposer index has moved up. It was originally after setting attestation, now it's moved up to after setting parent root. It makes the refactoring cleaner
Since this PR, we've added more data collection to our cluster to show that setExecutionData takes 200ms when using builder. The other operations of the block construction consist of about 110ms worth of work. Therefore, this PR should give block construction an average savings of approximately 100ms when using builder route. When using a local block construction, setExecutionData takes only 14ms due to eager caching from the EL. Could we apply some form of eager caching from the builder? |
@prestonvanloon It is the earliest we can get the header, anything earlier will probably result in an error from the relayer |
Supersedes #12251
This pull request adds the functionality of constructing consensus and execution parts of blocks in parallel using work groups. The goal is for the process of constructing blocks to be faster and more efficient. By utilizing work groups, different parts of the block can be constructed simultaneously, significantly reducing processing time