Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Builder API Tracking #3091

Closed
14 tasks done
realbigsean opened this issue Mar 15, 2022 · 1 comment
Closed
14 tasks done

Builder API Tracking #3091

realbigsean opened this issue Mar 15, 2022 · 1 comment
Labels
bellatrix Required to support the Bellatrix Upgrade

Comments

@realbigsean
Copy link
Member

realbigsean commented Mar 15, 2022 •
edited
Loading

Description

This issue is meant to track outstanding work related to the Lighthouse implementation of the builder spec.

The goal is to make the https://github.com/sigp/lighthouse/tree/builder-api branch available for users, and for outstanding work here will be marked complete as it is merged into that branch. #3134 will remain open because it's already in use by some users and I'll do my best to keep it up to date with the builder-api branch.

  • MEV boost JWT Auth not actually necessary, see the linked issue for discussion JWT Auth flashbots/mev-boost#52
  • pre-Bellatrix block support on blinded endpoints [Merged by Bors] - Builder Specs v0.2.0 #3134
  • support the normal proposal flow using the blinded blocks endpoints [Merged by Bors] - Builder Specs v0.2.0 #3134
  • Add a local testnet setup to CI for the blinded block proposal flow without mev-boost
  • Add a local testnet setup to CI for the blinded block proposal flow with mev-boost The purpose of this would have been to test lighthouse <> mev-boost compatibility, but because the mock_builder includes the mev-rs implementation of the builder API I don't actually think this adds much. Feels like we would end up testing mev-boost moreso than lighthouse
  • Separate the engine api from the builder api because mev-boost no longer forwards engine - work started here [Merged by Bors] - Remove builder redundancy #3294

Issues
@realbigsean realbigsean added the bellatrix Required to support the Bellatrix Upgrade label Mar 15, 2022
@realbigsean realbigsean mentioned this issue Mar 15, 2022
Closed
3 tasks
@realbigsean realbigsean mentioned this issue Mar 30, 2022
Closed
5 tasks
@come-maiz come-maiz mentioned this issue Jun 19, 2022
Closed
@realbigsean realbigsean changed the title Blinded blocks / MEV-boost Tracking Builder API Tracking Jun 29, 2022
bors bot pushed a commit that referenced this issue Jul 29, 2022
@realbigsean @macladson
Builder Specs v0.2.0 (#3134)
75e0152 
## Issue Addressed

#3091

Extends #3062, adding pre-bellatrix block support on blinded endpoints and allowing the normal proposal flow (local payload construction) on blinded endpoints. This resulted in better fallback logic because the VC will not have to switch endpoints on failure in the BN <> Builder API, the BN can just fallback immediately and without repeating block processing that it shouldn't need to. We can also keep VC fallback from the VC<>BN API's blinded endpoint to full endpoint.

## Proposed Changes

- Pre-bellatrix blocks on blinded endpoints
- Add a new `PayloadCache` to the execution layer
- Better fallback-from-builder logic

## Todos

- [x] Remove VC transition logic
- [x] Add logic to only enable builder flow after Merge transition finalization
- [x] Tests
- [x] Fix metrics
- [x] Rustdocs


Co-authored-by: Mac L <[email protected]>
Co-authored-by: realbigsean <[email protected]>
bors bot pushed a commit that referenced this issue Jul 30, 2022
@realbigsean @macladson
Builder Specs v0.2.0 (#3134)
ca4b588 
## Issue Addressed

#3091

Extends #3062, adding pre-bellatrix block support on blinded endpoints and allowing the normal proposal flow (local payload construction) on blinded endpoints. This resulted in better fallback logic because the VC will not have to switch endpoints on failure in the BN <> Builder API, the BN can just fallback immediately and without repeating block processing that it shouldn't need to. We can also keep VC fallback from the VC<>BN API's blinded endpoint to full endpoint.

## Proposed Changes

- Pre-bellatrix blocks on blinded endpoints
- Add a new `PayloadCache` to the execution layer
- Better fallback-from-builder logic

## Todos

- [x] Remove VC transition logic
- [x] Add logic to only enable builder flow after Merge transition finalization
- [x] Tests
- [x] Fix metrics
- [x] Rustdocs


Co-authored-by: Mac L <[email protected]>
Co-authored-by: realbigsean <[email protected]>
bors bot pushed a commit that referenced this issue Jul 30, 2022
@realbigsean @macladson
Builder Specs v0.2.0 (#3134)
6c2d8b2 
## Issue Addressed

#3091

Extends #3062, adding pre-bellatrix block support on blinded endpoints and allowing the normal proposal flow (local payload construction) on blinded endpoints. This resulted in better fallback logic because the VC will not have to switch endpoints on failure in the BN <> Builder API, the BN can just fallback immediately and without repeating block processing that it shouldn't need to. We can also keep VC fallback from the VC<>BN API's blinded endpoint to full endpoint.

## Proposed Changes

- Pre-bellatrix blocks on blinded endpoints
- Add a new `PayloadCache` to the execution layer
- Better fallback-from-builder logic

## Todos

- [x] Remove VC transition logic
- [x] Add logic to only enable builder flow after Merge transition finalization
- [x] Tests
- [x] Fix metrics
- [x] Rustdocs


Co-authored-by: Mac L <[email protected]>
Co-authored-by: realbigsean <[email protected]>
@realbigsean
Copy link
Member Author

Completed in #3134

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bellatrix Required to support the Bellatrix Upgrade
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@realbigsean