-
Notifications
You must be signed in to change notification settings - Fork 768
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
MEV Boost compatibility #2987
MEV Boost compatibility #2987
Conversation
- `PrivateBeaconBlock` - `PrivateBeaconBlockBody` - `SignedPrivateBeaconBlock`
- GET lighthouse/validator/blocks_private endpoint
This reverts commit 5982466.
…neric-transactions � Conflicts: � Cargo.lock � consensus/state_processing/src/per_block_processing.rs � consensus/state_processing/src/per_block_processing/block_signature_verifier.rs � consensus/types/src/beacon_block.rs � consensus/types/src/beacon_block_body.rs � consensus/types/src/execution_payload.rs � testing/ef_tests/src/cases/operations.rs
…neric-transactions
…neric-transactions � Conflicts: � beacon_node/http_api/src/lib.rs � consensus/types/Cargo.toml
Regarding our chat this morning about the merge transition and payload builders. I'm tempted to say that we don't try to produce blocks with a payload builder until the justified block is post-transition. The transition is a sensitive and complex time, I think it would be nice to keep things simple until 2/3rds of validators are agreeing up on the execution chain. I realise it will be lost profit for some stakers, but in the best case we'll see justification of the transition block in 2-3 epochs (~15mins). As I see it (and I might be missing things) I think being cautious around the transition is worth the costs. |
I'm going to close this branch but won't delete it because this is compatible with kintsugi. #3062 will be the kiln v2 target. |
## Issue Addressed MEV boost compatibility ## Proposed Changes See #2987 ## Additional Info This is blocked on the stabilization of a couple specs, [here](ethereum/beacon-APIs#194) and [here](flashbots/mev-boost#20). Additional TODO's and outstanding questions - [ ] MEV boost JWT Auth - [ ] Will `builder_proposeBlindedBlock` return the revealed payload for the BN to propogate - [ ] Should we remove `private-tx-proposals` flag and communicate BN <> VC with blinded blocks by default once these endpoints enter the beacon-API's repo? This simplifies merge transition logic. Co-authored-by: realbigsean <[email protected]> Co-authored-by: realbigsean <[email protected]>
## Issue Addressed MEV boost compatibility ## Proposed Changes See sigp#2987 ## Additional Info This is blocked on the stabilization of a couple specs, [here](ethereum/beacon-APIs#194) and [here](flashbots/mev-boost#20). Additional TODO's and outstanding questions - [ ] MEV boost JWT Auth - [ ] Will `builder_proposeBlindedBlock` return the revealed payload for the BN to propogate - [ ] Should we remove `private-tx-proposals` flag and communicate BN <> VC with blinded blocks by default once these endpoints enter the beacon-API's repo? This simplifies merge transition logic. Co-authored-by: realbigsean <[email protected]> Co-authored-by: realbigsean <[email protected]>
## Issue Addressed MEV boost compatibility ## Proposed Changes See sigp#2987 ## Additional Info This is blocked on the stabilization of a couple specs, [here](ethereum/beacon-APIs#194) and [here](flashbots/mev-boost#20). Additional TODO's and outstanding questions - [ ] MEV boost JWT Auth - [ ] Will `builder_proposeBlindedBlock` return the revealed payload for the BN to propogate - [ ] Should we remove `private-tx-proposals` flag and communicate BN <> VC with blinded blocks by default once these endpoints enter the beacon-API's repo? This simplifies merge transition logic. Co-authored-by: realbigsean <[email protected]> Co-authored-by: realbigsean <[email protected]>
Issue Addressed
MEV-boost compatibility
Proposed Changes
--private-tx-proposals
flag for the VC--payload-builders
BN flag for use with one or more MEV-boost like servicesAdditional Info
WIP