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

milestone 1 spec #20

Closed
wants to merge 5 commits into from
Closed

milestone 1 spec #20

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7daaf94
milestone 1 spec
Dec 22, 2021
a18f093
add feeRecipientDiff reference
Dec 22, 2021
b95dc8c
cleanup and use feeRecipientBalance
thegostep Jan 15, 2022
4c9cd3e
cleanup
thegostep Jan 26, 2022
977d487
update readme
thegostep Jan 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
213 changes: 19 additions & 194 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,202 +4,27 @@ A middleware server written in Go, that sits between an ethereum PoS consensus c

![block-proposal](/docs/block-proposal.png)

## Table of Contents
- [mev-boost](#mev-boost)
- [Implementation Plan](#implementation-plan)
- [milestone 1 - kintsugi testnet](#milestone-1---kintsugi-testnet)
- [milestone 2 - security, authentication & reputation](#milestone-2---security-authentication--reputation)
- [milestone 3 - privacy (optional)](#milestone-3---privacy-optional)
- [milestone 4 - configurations (optional)](#milestone-4---configurations-optional)
- [API Docs](#api-docs)
- [engine_executePayloadV1](#engine_executepayloadv1)
- [engine_forkchoiceUpdatedV1](#engine_forkchoiceupdatedv1)
- [builder_proposeBlindedBlockV1](#builder_proposeblindedblockv1)
- [builder_getPayloadHeaderV1](#builder_getpayloadheaderv1)
- [relay_getPayloadHeaderV1](#relay_getpayloadheaderv1)
- [relay_proposeBlindedBlockV1](#relay_proposeblindedblockv1)
- [Types](#types)
- [SignedMEVPayloadHeader](#signedmevpayloadheader)
- [MEVPayloadHeader](#mevpayloadheader)
- [SignedBlindedBeaconBlock](#signedblindedbeaconblock)
- [BlindedBeaconBlock](#blindedbeaconblock)
- [BlindedBeaconBlockBody](#blindedbeaconblockbody)
- [Build](#build)
- [Test](#test)
- [Lint](#lint)
- [Running with mergemock](#running-with-mergemock)

## Implementation Plan

A summary of consensus client changes can be found [here](https://hackmd.io/@paulhauner/H1XifIQ_t).

### milestone 1 - kintsugi testnet
## Implementation Milestones

1. **[minimal viable kintsugi compatibility](./docs/milestone-1.md) (mid december 2021)**
simple middleware logic with minimal consensus client changes, simple networking, no authentication, and manual safety mechanism

#### middleware behavior

- [x] middleware sends `feeRecipient` to relay with direct `engine_forkchoiceUpdatedV1` request at beginning of block
- [x] middleware fetches signed payloads from relay using unauthenticated `getPayloadHeader` request
- [x] middleware selects best payload that matches expected `payloadId` and requests signature from consensus client, this requires passing header object to the consensus client and flagging that it should be returned to the middleware once signed
- [x] middleware returns signed block + initial payload header to relay with direct request

#### required client modifications

- consensus client must implement [blind transaction signing](https://hackmd.io/@paulhauner/H1XifIQ_t#Change-1-Blind-Transaction-Signing)

### milestone 2 - security, authentication & reputation

cleanup consensus client and add security fallbacks

#### middleware behavior

- [ ] middleware requests authenticated `feeRecipient` message from consensus client and gossips over p2p at regular interval
- [ ] add middleware module for verifying previous relay payload validity and accuracy with hard or statistical blacklist (may require modifications to execution client)
- [ ] add middleware module for subscribing to 3rd party relay monitoring service

#### required client modifications

- in event of middleware crash, consensus client must be able to bypass the middleware to reach a local or remote execution client
- consensus client must implement [Proposal Promises](https://hackmd.io/@paulhauner/H1XifIQ_t#Change-2-Proposal-Promises)

### milestone 3 - privacy (optional)

add p2p comms mechanisms to prevent validator deanonymization

#### middleware behavior

- [ ] middleware gossips signed block + initial payload header over p2p

#### required client modifications

- consensus client must implement [New Gossipsub Topics](https://hackmd.io/@paulhauner/H1XifIQ_t#Change-3-New-Gossipsub-Topics)

### milestone 4 - configurations (optional)

add optional configurations to provide alternative guarantees

- [ ] consider adding direct `relay_forkchoiceUpdatedV1` call to relay for syncing state
- [ ] consider returning full payload directly to validator as optimization
- [ ] consider adding merkle proof of payment to shift verification requirements to the relay

## API Docs

Methods are prefixed using the following convention:
- `engine` prefix indicates calls made to the execution client. These methods are specified in the [execution engine APIs](https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.5/src/engine/specification.md).
- `builder` prefix indicates calls made to the mev-boost middleware.
- `relay` prefix indicates calls made to a relay.

### engine_executePayloadV1

See [engine_executePayloadV1](https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.5/src/engine/specification.md#engine_executepayloadv1).

### engine_forkchoiceUpdatedV1

See [engine_forkchoiceUpdatedV1](https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.5/src/engine/specification.md#engine_forkchoiceupdatedv1).

### builder_proposeBlindedBlockV1

#### Request

- method: `builder_proposeBlindedBlockV1`
- params:
1. [`SignedBlindedBeaconBlock`](#signedblindedbeaconblock)

#### Response

- result: [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload).
- error: code and message set in case an exception happens while proposing the payload.

Technically, this call only needs to return the `transactions` field of [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload), but we return the full payload for simplicity.

### builder_getPayloadHeaderV1

#### Request

- method: `builder_getPayloadHeaderV1`
- params:
1. `payloadId`: `DATA`, 8 Bytes - Identifier of the payload build process

#### Response

- result: [`ExecutionPayloadHeaderV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayloadheader)
- error: code and message set in case an exception happens while getting the payload.

### relay_getPayloadHeaderV1

#### Request

- method: `relay_getPayloadHeaderV1`
- params:
1. `payloadId`: `DATA`, 8 Bytes - Identifier of the payload build process

#### Response

- result: [`SignedMEVPayloadHeader`](#signedmevpayloadheader)
- error: code and message set in case an exception happens while getting the payload.

### relay_proposeBlindedBlockV1

#### Request

- method: `relay_proposeBlindedBlockV1`
- params:
1. [`SignedBlindedBeaconBlock`](#signedblindedbeaconblock)
2. [`SignedMEVPayloadHeader`](#signedmevpayloadheader)

#### Response

- result: [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload)
- error: code and message set in case an exception happens while proposing the payload.

Technically, this call only needs to return the `transactions` field of [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload), but we return the full payload for simplicity.

### Types

#### SignedMEVPayloadHeader

See [here](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/phase0/beacon-chain.md#custom-types) for the definition of fields like `BLSSignature`

- message: [MEVPayloadHeader](#mevpayloadheader)
- signature: BLSSignature

#### MEVPayloadHeader

- payloadHeader: [`ExecutionPayloadHeaderV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayloadheader)
- feeRecipientDiff: Quantity, 256 Bits - the change in balance of the feeRecipient address

#### SignedBlindedBeaconBlock

See [here](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/phase0/beacon-chain.md#custom-types) for the definition of fields like `BLSSignature`

- message: [BlindedBeaconBlock](#blindedbeaconblock)
- signature: BLSSignature

#### BlindedBeaconBlock

This is forked from [here](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/phase0/beacon-chain.md#beaconblock) with `body` replaced with `BlindedBeaconBlockBody`

- slot: Slot
- proposer_index: ValidatorIndex
- parent_root: Root
- state_root: Root
- body: BlindedBeaconBlockBody

#### BlindedBeaconBlockBody

This is forked from [here](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#beaconblockbody) with `execution_payload` replaced with [execution_payload_header](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayloadheader)

- randao_reveal: BLSSignature
- eth1_data: Eth1Data
- graffiti: Bytes32
- proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
- attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
- attestations: List[Attestation, MAX_ATTESTATIONS]
- deposits: List[Deposit, MAX_DEPOSITS]
- voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
- sync_aggregate: SyncAggregate
- execution_payload_header: ExecutionPayloadHeader
3. **[security, authentication & reputation](./docs/milestone-2.md) (end of january 2021)**
security features necessary for production use of the software, see [mev-boost milestone 2 security features](https://hackmd.io/@flashbots/r1CuVl86Y)
5. **[p2p communications](./docs/milestone-3.md) (optional / tbd)**
p2p comms mechanisms for validator IP obfuscation
7. **[optional configurations](./docs/milestone-4.md) (optional / tbd)**
optional configurations for custom distributions

| Milestone | 1 | 2 | 3 | 4 |
| ---------- |:---:|:---:|:---:|:---:|
| mev-boost | ✅ | | | |
| mergemock | ✅ | | | |
| lighthouse | ✅ | | | |
| prysm | ✅ | | | |
| teku | | | | |
| nimbus | | | | |
| lodestar | | | | |
| grandine | | | | |

## Build

Expand Down
175 changes: 175 additions & 0 deletions docs/milestone-1.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,175 @@
# Milestone 1 - kintsugi testnet

This initial milestone provides simple middleware logic with minimal consensus client changes, simple networking, no validator authentication, and manual safety mechanism

## Architecture

### Block Proposal

```sequence
come-maiz marked this conversation as resolved.
Show resolved Hide resolved
participant consensus
participant mev_boost
participant execution
participant relays
Title: Block Proposal
Note over consensus: wait for allocated slot
consensus->mev_boost: engine_forkchoiceUpdatedV1
mev_boost->execution: engine_forkchoiceUpdatedV1
mev_boost->relays: engine_forkchoiceUpdatedV1
Note over mev_boost: begin polling
mev_boost->relays: relay_getPayloadHeaderV1
consensus->mev_boost: builder_getPayloadHeaderV1
mev_boost->execution: engine_getPayloadV1
Note over mev_boost: select best payload
mev_boost-->consensus: builder_getPayloadHeaderV1 response
Note over consensus: sign the block
consensus->mev_boost: builder_proposeBlindedBlockV1
Note over mev_boost: identify payload source
mev_boost->relays: relay_proposeBlindedBlockV1
Note over relays: validate signature
relays-->mev_boost: relay_proposeBlindedBlockV1 response
mev_boost-->consensus: builder_proposeBlindedBlockV1 response
```

## Specification

1. mev-boost must be initialized with a list of (`BLSPublicKey`, `RelayURI`) pairs representing trusted relays.
2. mev-boost must intercept [`engine_forkchoiceUpdatedV1`](#engine_forkchoiceupdatedv1) call from the BN -> EC and forward it to all connected relays to communicate `feeRecipient`.
3. mev-boost must begin polling connected relays for their [`SignedMEVPayloadHeader`](#signedmevpayloadheader) using [`relay_getPayloadHeaderV1`](#relay_getpayloadheaderv1) requests.
4. mev-boost must verify the returned [`SignedMEVPayloadHeader`](#signedmevpayloadheader) signature matches the BLS key associated with the IP of the relay and has a matching `payloadId`.
5. upon receiving a [`builder_getPayloadHeaderV1`](#builder_getpayloadheaderv1) request from the BN, mev-boost must return the [`ExecutionPayloadHeaderV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayloadheader) with the highest associated `feeRecipientBalance`. If no eligible payload is received from a relay, mev-boost must request and return a payload from the local execution client using [`engine_getPayloadV1`](#engine_getpayloadv1).
come-maiz marked this conversation as resolved.
Show resolved Hide resolved
6. the BN must use the [`ExecutionPayloadHeaderV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayloadheader) received to assemble and sign a [`SignedBlindedBeaconBlock`](#signedblindedbeaconblock) and return it to mev-boost using [`builder_proposeBlindedBlockV1`](#builder_proposeblindedblockv1).
7. mev-boost must forward the [`SignedBlindedBeaconBlock`](#signedblindedbeaconblock) to all connected relays and attach the matching [`SignedMEVPayloadHeader`](#signedmevpayloadheader) using [`relay_proposeBlindedBlockV1`](#relay_proposeblindedblockv1) to inform the network of which relay created this payload.
8. if an [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload) is returned, mev-boost must verify that the root of the transaction list matches the expected transaction root from the [`SignedBlindedBeaconBlock`](#signedblindedbeaconblock) before returning it to the BN.

### required client modifications

- consensus client must implement [blind transaction signing](https://hackmd.io/@paulhauner/H1XifIQ_t#Change-1-Blind-Transaction-Signing)

## API Docs

Methods are prefixed using the following convention:
- `engine` prefix indicates calls made to the execution client. These methods are specified in the [execution engine APIs](https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.5/src/engine/specification.md).
- `builder` prefix indicates calls made to the mev-boost middleware.
- `relay` prefix indicates calls made to a relay.

### engine_forkchoiceUpdatedV1

See [engine_forkchoiceUpdatedV1](https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.5/src/engine/specification.md#engine_forkchoiceupdatedv1).

### engine_getPayloadV1

See [engine_getPayloadV1](https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.5/src/engine/specification.md#engine_getpayloadv1).

### builder_getPayloadHeaderV1

#### Request

- method: `builder_getPayloadHeaderV1`
- params:
1. `payloadId`: `DATA`, 8 Bytes - Identifier of the payload build process
come-maiz marked this conversation as resolved.
Show resolved Hide resolved

#### Response

- result: [`ExecutionPayloadHeaderV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayloadheader)
- error: code and message set in case an exception happens while getting the payload.

### builder_proposeBlindedBlockV1

#### Request

- method: `builder_proposeBlindedBlockV1`
- params:
1. [`SignedBlindedBeaconBlock`](#signedblindedbeaconblock)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is JSON-RPC serialized, while SignedBlindedBeaconBlock is only specified here as an SSZ type. Aspects of SSZ type serialization aren't otherwise specified by the engine API spec on which this builds, such as SignedBlindedBeaconBlock.signature and SignedMEVPayloadHeader.signature (both BLSSignatures), leaving room for noninteroperability across implementations.

https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.6/src/engine/specification.md#executionpayloadv1 provides an explicit mapping between a JSON-RPC-serialization of engine.ExecutionPayloadV1 and SSZ representation of bellatrix.ExecutionPayload, where both are supposed to be otherwise isomorphic.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree this should be in JSON-RPC terms.

We could fully specify blocks here, similar to how ExecutionPayloadV1 is defined by the execution API, but that might not be worth doing and maintaining because we already have blocks specified here, and I don't think we'd want to leave room for discrepancy between JSON serialization of the same type between the two APIs.

I've raised a PR here to add Bellatrix types to the beacon API as well as endpoints and types necessary for blind transaction signing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @tersec and @realbigsean. I need help here to understand the proposal of using JSON-RPC for encoding these new methods. As I understand, SSZ is the new encoding for the consensus layer. I wonder why do we want to use the old encoding for the new things. Probably this has been discussed long ago, so please be patient with me :)
The way I imagine it, these APIs will be implemented by new software in the future, so these seems like a good way to start moving the future to be more consistent and easier to read. Am I being naive or missing some part of the story?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SSZ is used as as the intra-consensus layer/inter-beacon-node serialization over the libp2p gossip network, yes.

JSON-RPC serializations appear in the REST API and related areas, e.g., validator clients mostly use JSON-RPC-type encodings to interact with beacon nodes. Both remain in use.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to #69 for tracking.


#### Response

- result: [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload)
- error: code and message set in case an exception happens while proposing the payload.

Technically, this call only needs to return the `transactions` field of [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload), but we return the full payload for simplicity.

### relay_getPayloadHeaderV1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will MEV boost forward relay_getPayloadHeaderV1/relay_proposeBlindedBlockV1 requests it receives to the relay? The format of the spec here makes it look like these are available MEV boost endpoints, but I think they might be endpoints only the relay is required to serve.

If these are only definitions for what the relay serves, I think it would make sense to have a clearer separation (in new section at the bottom here or maybe even splitting the relay API and mev-boost API into separate docs?)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, they shouldn't be forwarded. I agree, let's make a separate section to specity how the relayer is going to work.


#### Request

- method: `relay_getPayloadHeaderV1`
- params:
1. `payloadId`: `DATA`, 8 Bytes - Identifier of the payload build process

#### Response

- result: [`SignedMEVPayloadHeader`](#signedmevpayloadheader)
- error: code and message set in case an exception happens while getting the payload.

### relay_proposeBlindedBlockV1

#### Request

- method: `relay_proposeBlindedBlockV1`
- params:
1. [`SignedBlindedBeaconBlock`](#signedblindedbeaconblock)
2. [`SignedMEVPayloadHeader`](#signedmevpayloadheader)

#### Response

- result: [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload)
- error: code and message set in case an exception happens while proposing the payload.

Technically, this call only needs to return the `transactions` field of [`ExecutionPayloadV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayload), but we return the full payload for simplicity.

### Types

#### SignedMEVPayloadHeader
Copy link

@tersec tersec Feb 2, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Along the lines of the comments about SignedBlindedBeaconBlock, but here, the JSON-RPC and SSZ types are freely intermixed, with the sort-of-SSZ-type-looking SignedMEVPayloadHeader containing a MEVPayloadHeader the fields of which are a Data and Quantity (JSON-RPC serialization types), which itself contains a ExecutionPayloadHeaderV1(a consensus layer SSZ type, defined using the SSZ-serialization-defined Hash32, ExecutionAddress, Bytes32, uint64, etc types). It's not internally consistent.

Implementing this might involve drawing out, at each layer, the dual JSON-RPC form of SignedMEVPayloadHeader, the dual SSZ form of MEVPayloadHeader (because the sort-of-SSZ-defined SignedMEVPayloadHeader either has to be read as a purely JSON-RPC object, or if not, for all its component parts to have consensus layer-like definitions in addition to the purely JSON-RPC definitions here), and likewise but inverted for the nominally-natively-SSZ ExecutionPayloadHeaderV1.

For example, one might imagine the CL/SSZ MEVPayloadHeader:

class MEVPayloadHeader(Container):
    payloadHeader: ExecutionPayloadHeaderV1
    feeRecipient: ExecutionAddress
    feeRecipientBalance: uint256

https://github.com/realbigsean/lighthouse/blob/mev-lighthouse/beacon_node/execution_layer/src/engine_api/json_structures.rs fills this out with some gaps, but none of it is directly specified and there are various points of ambiguity.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh what a mess. As I said before, I would like everything to be SSZ.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to #76 for traceability and better discussion.


See [here](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/phase0/beacon-chain.md#custom-types) for the definition of fields like `BLSSignature`

- `message`: [`MEVPayloadHeader`](#mevpayloadheader)
- `signature`: `BLSSignature`

#### MEVPayloadHeader

- `payloadHeader`: [`ExecutionPayloadHeaderV1`](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayloadheader)
- `feeRecipient`: `Data`, 20 Bytes - the fee recipient address requested by the validator
- `feeRecipientBalance`: `Quantity`, 256 Bits - the ending balance of the feeRecipient address

Note: the feeRecipient must match the suggestedFeeRecipient address provided in the [`PayloadAttributesV1`](https://github.com/ethereum/execution-apis/blob/v1.0.0-alpha.5/src/engine/specification.md#payloadattributesv1) of the associated [`engine_forkchoiceUpdatedV1`](#engine_forkchoiceupdatedv1) request.

#### SignedBlindedBeaconBlock

See [here](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/phase0/beacon-chain.md#custom-types) for the definition of fields like `BLSSignature`

- `message`: [`BlindedBeaconBlock`](#blindedbeaconblock)
- `signature`: `BLSSignature`

#### BlindedBeaconBlock

This is forked from [here](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/phase0/beacon-chain.md#beaconblock) with `body` replaced with `BlindedBeaconBlockBody`
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These references to the now-Bellatrix hardfork of the CL specs don't account for, e.g., supporting multiple CL MEV-compatible CL hardforks. While I'm not sure what the role of MEV in phase 0 or Altair might be, lacking transactions and all, the next hard fork, called the sharding fork pending whatever it's renamed to, will also support transactions.

The algorithm to derive the blinded types is the same, granted -- replace the execution payload with the execution payload header in the body, then propagate that back up the dependency chain -- but this creates ambiguous naming within a single global namespace as specified. In the context of MEV boosting, is a BlindedBeaconBlock (signed, body, etc) the Bellatrix or Sharding version?

Of course, that won't be for a while, but it's an eventuality that will happen and it'll be smoother to anticipate it now than later.

Copy link
Contributor

@realbigsean realbigsean Feb 25, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK fork awareness hasn't been spec'd out in the engine API, and since this should be an extension of that repo I don't think it should be defined here. We should just roll with the precedent set upstream, which I imagine will be similar to what is used by the beacon API.


```py
class BlindedBeaconBlock(Container):
slot: Slot
proposer_index: ValidatorIndex
parent_root: Root
state_root: Root
body: BlindedBeaconBlockBody
```

#### BlindedBeaconBlockBody

This is forked from [here](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#beaconblockbody) with `execution_payload` replaced with [execution_payload_header](https://github.com/ethereum/consensus-specs/blob/v1.1.6/specs/merge/beacon-chain.md#executionpayloadheader)

```py
class BlindedBeaconBlockBody(Container):
randao_reveal: BLSSignature
eth1_data: Eth1Data
graffiti: Bytes32
proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
attestations: List[Attestation, MAX_ATTESTATIONS]
deposits: List[Deposit, MAX_DEPOSITS]
voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
sync_aggregate: SyncAggregate
execution_payload_header: ExecutionPayloadHeader
```