# Discussion on EIP-7805 Consensus Layer Specification
> *Special thanks to [Mikhail](https://x.com/mkalinin2), [Justin](https://x.com/JustinTraglia), [Medhi](https://x.com/mehdi_aouadi_) and [Eitan](https://x.com/0xUncleBill) for valuable feedback and discussions*
There has been a discussion on the EIP-7805 Consensus Layer Specification following this [PR](https://github.com/ethereum/consensus-specs/pull/4351). This article aims to outline the problems, lay out possible solutions and provide the PR author's suggestion to facilitate a productive discussion.
The following sections introduce what the [PR](https://github.com/ethereum/consensus-specs/pull/4351) suggests, the problems associated with it and potential solutions. Some sections include code snippets, each containing only the relevant parts for better readability.
## What the PR Suggests
The CL clients currently use `engine_newPayload` to pass IL transactions to the EL clients. In the same vein, the PR modifies `process_execution_payload` to retrieve IL transactions and pass them to the EL.
(Note that we will use `get_inclusion_list_transactions` for retrieving IL transactions for now, but it will be addressed in the [IL Placement](#IL-Placement) section.)
##### Modified `process_execution_payload`
```python diff
def process_execution_payload(
state: BeaconState, body: BeaconBlockBody, execution_engine: ExecutionEngine
) -> None:
...
inclusion_list_transactions = get_inclusion_list_transactions(
state, state.slot - 1
) # [New in EIP-7805]
assert execution_engine.verify_and_notify_new_payload(
NewPayloadRequest(
execution_payload=payload,
versioned_hashes=versioned_hashes,
parent_beacon_block_root=state.latest_block_header.parent_root,
execution_requests=body.execution_requests,
inclusion_list_transactions=inclusion_list_transactions, # [New in EIP-7805]
)
)
...
```
`notify_new_payload` is modified accordingly to take IL transactions and raises `AssertionError("INVALID_INCLUSION_LIST")` if the given payload fails to satisfy the IL constraints.
##### Modified `notify_new_payload`
```python
def notify_new_payload(
self: ExecutionEngine,
execution_payload: ExecutionPayload,
parent_beacon_block_root: Root,
execution_requests_list: Sequence[bytes],
inclusion_list_transactions: Sequence[Transaction],
) -> bool:
"""
Return ``True`` if and only if ``execution_payload`` and ``execution_requests_list``
are valid with respect to ``self.execution_state``, and ``execution_payload`` satisfies
the inclusion list constraints.
Raise ``AssertionError("INVALID_INCLUSION_LIST")`` if ``execution_payload`` is valid but
fails to satisfy the inclusion list constraints.
"""
...
```
Whenever an `AssertionError("INVALID_INCLUSION_LIST")` is raised, it's caught by `on_block`, and the block is added to `Store.unsatisfied_inclusion_list_blocks`. The CL clients will then attempt to reorg this block.
##### Modified `on_block`
```python
def on_block(store: Store, signed_block: SignedBeaconBlock) -> None:
"""
Run ``on_block`` upon receiving a new block.
"""
...
# [Modified in EIP-7805]
try:
state_transition(state, signed_block, True)
except AssertionError as e:
if str(e) == "INVALID_INCLUSION_LIST":
store.unsatisfied_inclusion_list_blocks.add(block_root)
else:
assert False
...
# Add proposer score boost if the block is timely and not conflicting with an existing block
# and satisfies the inclusion list constraints.
is_first_block = store.proposer_boost_root == Root()
is_inclusion_list_satisfied = (
not block_root in store.unsatisfied_inclusion_list_blocks
) # [New in EIP-7805]
if is_timely and is_first_block and is_inclusion_list_satisfied: # [Modified in EIP-7805]
store.proposer_boost_root = hash_tree_root(block)
...
```
## Problems of Current Suggestion
While this closely follows the actual implementation, it turned out that it has several problems.
#### Problem 1. It contradicts both the CL spec requirement and the original intention
[The CL spec uses Python with its own conventions](https://github.com/ethereum/consensus-specs/issues/1797). For example, it uses the `assert` statements as logical conditions that should be satisfied at runtime, sometimes omitting specific exception handling logic and compensating it with descriptions.
The CL spec clearly states that state transitions that trigger an unhandled exception should be considered invalid and that should not change the fork choice store.
> ... State transitions that trigger an unhandled exception (e.g. a failed assert or an out-of-range list access) are considered invalid.
>
> ... Invalid calls to (fork choice) handlers must not modify store.
The current PR relies on raising a specific type of exception to signal when a given payload doesn’t satisfy the IL constraints. When this exception is caught, the block is stored in `Store.unsatisfied_inclusion_list_blocks`, directly violating the requirement. Furthermore, the block should still complete processing since it’s technically valid—even though it doesn’t satisfy the IL constraints—but currently, the remainder of the state transition isn’t executed.
#### Problem 2. It makes `state_transition` stateful
`state_transition` is currently a stateless function. However, it fetches IL transactions via `get_inclusion_list_transactions` function within `process_execution_payload`, thereby transforming `state_transition` into a stateful function.
#### Problem 3. The CL spec defines how the CL should operate, not the implementation
The CL spec focuses on specifying how the CL should work. To that end, the communication between the CL and the EL is often abstracted via the `ExecutionEngine` interface for clarity. This abstraction doesn’t have to match the actual implementation, as the interaction between the CL and the EL is defined by the [Execution API Spec](https://github.com/ethereum/execution-apis).
## Potential Solutions
To summarize, we need to find a solution for specifying the IL validation. Additionally, although not explicitly mentioned above, we also need to determine where to store ILs.
### IL validation
#### Introducing a new abstract `ExecutionEngine.is_inclusion_list_satisfied` call
As mentioned above, we cannot use exception to signal when a given payload doesn’t satisfy the IL constraints. Instead, we could introduce a new abstract `ExecutionEngine.is_inclusion_list_satisfied` call.
#### `is_inclusion_list_satisfied`
```python
def is_inclusion_list_satisfied(
self: ExecutionEngine,
execution_payload: ExecutionPayload,
inclusion_list_transactions: Sequence[Transaction],
) -> bool:
"""
Return ``True`` if and only if ``execution_payload`` satisfies the inclusion list constraints with respect to ``self.inclusion_list_transactions``.
"""
...
```
In order to call this function, `on_block` is modified to receive `ExecutionEngine`.
##### Modified `on_block`
```python
def on_block(store: Store, signed_block: SignedBeaconBlock, execution_engine: ExecutionEngine) -> None:
"""
Run ``on_block`` upon receiving a new block.
"""
...
state_transition(state, signed_block, True)
# [Modified in EIP-7805]
inclusion_list_transactions = get_inclusion_list_transactions(
state, state.slot - 1
)
is_inclusion_list_satisfied = execution_engine.is_inclusion_list_satisfied(
execution_payload, inclusion_list_transactions
)
if not is_inclusion_list_satisfied:
store.unsatisfied_inclusion_list_blocks.add(block_root)
...
# Add proposer score boost if the block is timely, not conflicting with an existing block
# and satisfies the inclusion list constraints.
if is_timely and is_first_block and is_inclusion_list_satisfied: # [Modified in EIP-7805]
store.proposer_boost_root = hash_tree_root(block)
...
```
#### (Optional) Modifying `state_transition` explicitly
Now `state_transition` can either be modified or remain intact. If modified, it can remain stateless by modifying the relevant function signatures. To achieve this, `on_block` now fetches IL transactions and passes them to `state_transition`.
##### Modified `on_block`
```python
def on_block(store: Store, signed_block: SignedBeaconBlock) -> None:
"""
Run ``on_block`` upon receiving a new block.
"""
...
# [Modified in EIP-7805]
inclusion_list_transactions = get_inclusion_list_transactions(
state, state.slot - 1
)
state_transition(state, signed_block, inclusion_list_transactions, True)
is_inclusion_list_satisfied = execution_engine.is_inclusion_list_satisfied(
execution_payload, inclusion_list_transactions
)
if not is_inclusion_list_satisfied:
store.unsatisfied_inclusion_list_blocks.add(block_root)
...
# Add proposer score boost if the block is timely, not conflicting with an existing block,
# and satisfies the inclusion list constraints.
is_first_block = store.proposer_boost_root == Root()
if is_timely and is_first_block and is_inclusion_list_satisfied: # [Modified in EIP-7805]
store.proposer_boost_root = hash_tree_root(block)
...
```
`state_transition` and `process_block` pass the IL transactions down to `process_execution_payload`.
##### Modified `state_transition`
```python
def state_transition(
state: BeaconState, signed_block: SignedBeaconBlock, inclusion_list_transactions: Sequence[Transaction], validate_result: bool = True
) -> None:
...
# Process block
process_block(state, block, inclusion_list_transactions)
...
```
##### Modified `process_block`
```python
def process_block(state: BeaconState, block: BeaconBlock, inclusion_list_transactions: Sequence[Transaction]) -> None:
...
if is_execution_enabled(state, block.body):
process_execution_payload(state, block.body, inclusion_list_transactions, EXECUTION_ENGINE)
...
```
##### Modified `process_execution_payload`
```python
def process_execution_payload(
state: BeaconState, body: BeaconBlockBody, inclusion_list_transactions: Sequence[Transaction], execution_engine: ExecutionEngine
) -> None:
...
assert execution_engine.verify_and_notify_new_payload(
NewPayloadRequest(
execution_payload=payload,
versioned_hashes=versioned_hashes,
parent_beacon_block_root=state.latest_block_header.parent_root,
execution_requests=body.execution_requests,
inclusion_list_transactions=inclusion_list_transactions, # [New in EIP-7805]
)
)
...
```
`notify_new_payload` is modified to take IL transactions and may perform the IL validation, but the validation result must not affect the return value. The result will be returned via the `ExecutionEngine.is_inclusion_list_satisfied` call.
##### Modified `notify_new_payload`
```python
def notify_new_payload(
self: ExecutionEngine,
execution_payload: ExecutionPayload,
parent_beacon_block_root: Root,
execution_requests_list: Sequence[bytes],
inclusion_list_transactions: Sequence[Transaction],
) -> bool:
"""
Return ``True`` if and only if ``execution_payload`` and ``execution_requests_list``
are valid with respect to ``self.execution_state``.
``execution_payload`` may validated to check if it satisfies the inclusion list
constraints, but the validation result must not affect the return value.
"""
...
```
While this achieves its goals and reflects the fact that the CL would pass IL transactions using the `engine_newPayload` call, it introduces invasive changes. Given the goals of the CL spec, these changes don’t seem necessary.
### IL Placement
ILs are broadcast over the P2P network and have their own rules. It’s generally better to explicitly specify these rules rather than leave them unspecified, especially the equivocation handling logic and the IL timeliness handling logic. The remaining question is where to store ILs.
#### Option 1. Fork Choice Store
The first option is putting ILs into the fork choice store along with equivocators.
```python
@dataclass
class Store(object):
time: uint64
genesis_time: uint64
justified_checkpoint: Checkpoint
finalized_checkpoint: Checkpoint
unrealized_justified_checkpoint: Checkpoint
unrealized_finalized_checkpoint: Checkpoint
proposer_boost_root: Root
equivocating_indices: Set[ValidatorIndex]
blocks: Dict[Root, BeaconBlock] = field(default_factory=dict)
block_states: Dict[Root, BeaconState] = field(default_factory=dict)
block_timeliness: Dict[Root, boolean] = field(default_factory=dict)
checkpoint_states: Dict[Checkpoint, BeaconState] = field(default_factory=dict)
latest_messages: Dict[ValidatorIndex, LatestMessage] = field(default_factory=dict)
unrealized_justifications: Dict[Root, Checkpoint] = field(default_factory=dict)
# [New in EIP-7805]
inclusion_lists: Dict[Tuple[Slot, Root], Set[InclusionList]] = field(default_factory=dict)
inclusion_list_equivocators: Dict[Tuple[Slot, Root], Set[ValidatorIndex]] = field(
default_factory=dict
)
unsatisfied_inclusion_list_blocks: Set[Root] = field(default_factory=Set)
```
Accordingly, `on_inclusion_list` fork choice handler is added. `on_inclusion_list(store, inclusion_list)` is called whenever an inclusion list `inclusion_list: SignedInclusionList` is received.
```python
def on_inclusion_list(store: Store, signed_inclusion_list: SignedInclusionList) -> None:
inclusion_list = signed_inclusion_list.message
validator_index = inclusion_list.validator_index
key = (inclusion_list.slot, inclusion_list.inclusion_list_committee_root)
inclusion_lists = store.inclusion_lists.setdefault(key, set())
equivocators = store.inclusion_list_equivocators.setdefault(key, set())
if validator_index in equivocators:
return
for stored_inclusion_list in inclusion_lists:
if stored_inclusion_list.validator_index != validator_index:
continue
if stored_inclusion_list != inclusion_list:
equivocators.add(validator_index)
inclusion_lists.remove(stored_inclusion_list)
# Whether it was an equivocation or not, we have processed this `inclusion_list`.
return
time_into_slot = (store.time - store.genesis_time) % SECONDS_PER_SLOT
is_before_view_freeze_deadline = (
get_current_slot(store) == inclusion_list.slot and time_into_slot < VIEW_FREEZE_DEADLINE
)
if not is_before_view_freeze_deadline:
return
# Store this first `inclusion_list` from `validator_index`.
inclusion_lists.add(inclusion_list)
```
A new helper function `get_inclusion_list_transactions` takes state and slot, and returns a unique set of IL transactions from non-equivocating ILs.
```python
def get_inclusion_list_transactions(
store: Store,
state: BeaconState,
slot: Slot,
) -> Sequence[Transaction]:
inclusion_list_committee = get_inclusion_list_committee(state, slot)
inclusion_list_committee_root = hash_tree_root(inclusion_list_committee)
key = (slot, inclusion_list_committee_root)
inclusion_lists = store.inclusion_lists.setdefault(key, set())
equivocators = store.inclusion_list_equivocators.setdefault(key, set())
inclusion_list_transactions = {
transaction
for inclusion_list in inclusion_lists
if inclusion_list.validator_index not in equivocators
for transaction in inclusion_list.transactions
}
return list(inclusion_list_transactions)
```
Finally, `on_block` calls `get_inclusion_list_transactions` to fetch IL transactions from the fork choice store.
##### Modified `on_block`
```python
def on_block(store: Store, signed_block: SignedBeaconBlock, execution_engine: ExecutionEngine) -> None:
"""
Run ``on_block`` upon receiving a new block.
"""
...
state_transition(state, signed_block, True)
# [Modified in EIP-7805]
inclusion_list_transactions = get_inclusion_list_transactions(
store, state, block.slot - 1
)
is_inclusion_list_satisfied = execution_engine.is_inclusion_list_satisfied(
execution_payload, inclusion_list_transactions
)
if not is_inclusion_list_satisfied:
store.unsatisfied_inclusion_list_blocks.add(block_root)
...
# Add proposer score boost if the block is timely, not conflicting with an existing block
# and satisfies the inclusion list constraints.
if is_timely and is_first_block and is_inclusion_list_satisfied: # [Modified in EIP-7805]
store.proposer_boost_root = hash_tree_root(block)
...
```
#### Option 2. IL Store
Another option is introducing a dedicated store for ILs. This allows the fork choice store to focus solely on data that directly affects fork choice, and allows the CL spec specify that the placement of ILs is implementation dependent.
```python
@dataclass
class Store(object):
time: uint64
genesis_time: uint64
justified_checkpoint: Checkpoint
finalized_checkpoint: Checkpoint
unrealized_justified_checkpoint: Checkpoint
unrealized_finalized_checkpoint: Checkpoint
proposer_boost_root: Root
equivocating_indices: Set[ValidatorIndex]
blocks: Dict[Root, BeaconBlock] = field(default_factory=dict)
block_states: Dict[Root, BeaconState] = field(default_factory=dict)
block_timeliness: Dict[Root, boolean] = field(default_factory=dict)
checkpoint_states: Dict[Checkpoint, BeaconState] = field(default_factory=dict)
latest_messages: Dict[ValidatorIndex, LatestMessage] = field(default_factory=dict)
unrealized_justifications: Dict[Root, Checkpoint] = field(default_factory=dict)
# [New in EIP-7805]
unsatisfied_inclusion_list_blocks: Set[Root] = field(default_factory=Set)
```
A new `InclusionListStore` stores ILs and equivocators.
```python
@dataclass
class InclusionListStore(object):
inclusion_lists: Dict[Tuple[Slot, Root], Set[InclusionList]] = field(default_factory=dict)
equivocators: Dict[Tuple[Slot, Root], Set[ValidatorIndex]] = field(default_factory=dict)
```
`get_inclusion_list_store` returns the inclusion list store. The implementation of `get_inclusion_list_store` is left to the discretion of implementers.
```python
def get_inclusion_list_store() -> InclusionListStore:
# `cached_or_new_inclusion_list_store` is implementation and context dependent.
# It returns the cached `InclusionListStore`; if none exists,
# it initializes a new instance, caches it and returns it.
inclusion_list_store = cached_or_new_inclusion_list_store()
return inclusion_list_store
```
`store_inclusion_list` works similarly to `on_inclusion_list` except that it takes `is_before_view_freeze_deadline` as a parameter.
```python
def store_inclusion_list(
store: InclusionListStore, inclusion_list: InclusionList, is_before_view_freeze_deadline: bool
) -> None:
validator_index = inclusion_list.validator_index
key = (inclusion_list.slot, inclusion_list.inclusion_list_committee_root)
inclusion_lists = store.inclusion_lists.setdefault(key, set())
equivocators = store.equivocators.setdefault(key, set())
if validator_index in equivocators:
return
for stored_inclusion_list in inclusion_lists:
if stored_inclusion_list.validator_index != validator_index:
continue
if stored_inclusion_list != inclusion_list:
equivocators.add(validator_index)
inclusion_lists.remove(stored_inclusion_list)
# Whether it was an equivocation or not, we have processed this `inclusion_list`.
return
if not is_before_view_freeze_deadline:
return
# Store this first `inclusion_list` from `validator_index`.
inclusion_lists.add(inclusion_list)
```
A new helper function `get_inclusion_list_transactions` works the same way except that it fetches ILs from the inclusion list store.
```python
def get_inclusion_list_transactions(
store: InclusionListStore, state: BeaconState, slot: Slot
) -> Sequence[Transaction]:
inclusion_list_committee = get_inclusion_list_committee(state, slot)
inclusion_list_committee_root = hash_tree_root(inclusion_list_committee)
key = (slot, inclusion_list_committee_root)
inclusion_lists = store.inclusion_lists.setdefault(key, set())
equivocators = store.equivocators.setdefault(key, set())
inclusion_list_transactions = {
transaction
for inclusion_list in inclusion_lists
if inclusion_list.validator_index not in equivocators
for transaction in inclusion_list.transactions
}
return list(inclusion_list_transactions)
```
Similarly, `on_block` calls `get_inclusion_list_transactions` to retrieve IL transactions from the inclusion list store.
##### Modified `on_block`
```python
def on_block(store: Store, signed_block: SignedBeaconBlock, execution_engine: ExecutionEngine) -> None:
"""
Run ``on_block`` upon receiving a new block.
"""
...
state_transition(state, signed_block, True)
# [Modified in EIP-7805]
inclusion_list_store = get_inclusion_list_store()
inclusion_list_transactions = get_inclusion_list_transactions(
inclusion_list_store, state, block.slot - 1
)
is_inclusion_list_satisfied = execution_engine.is_inclusion_list_satisfied(
execution_payload, inclusion_list_transactions
)
if not is_inclusion_list_satisfied:
store.unsatisfied_inclusion_list_blocks.add(block_root)
...
# Add proposer score boost if the block is timely, not conflicting with an existing block
# and satisfies the inclusion list constraints.
if is_timely and is_first_block and is_inclusion_list_satisfied: # [Modified in EIP-7805]
store.proposer_boost_root = hash_tree_root(block)
...
```
#### Option 3. Fork Choice Store that has IL Store
The other option is letting the fork choice store have the inclusion list store. The fork choice store has a direct reference to the inclusion list store, but how ILs are handled is abstracted from the fork choice store’s perspective. Additionally, as the fork choice store is time-aware, this approach doesn’t abstract `is_before_view_freeze_deadline` unlike option 2.
```python
@dataclass
class InclusionListStore(object):
inclusion_lists: Dict[Tuple[Slot, Root], Set[InclusionList]] = field(default_factory=dict)
equivocators: Dict[Tuple[Slot, Root], Set[ValidatorIndex]] = field(default_factory=dict)
@dataclass
class Store(object):
time: uint64
genesis_time: uint64
justified_checkpoint: Checkpoint
finalized_checkpoint: Checkpoint
unrealized_justified_checkpoint: Checkpoint
unrealized_finalized_checkpoint: Checkpoint
proposer_boost_root: Root
equivocating_indices: Set[ValidatorIndex]
blocks: Dict[Root, BeaconBlock] = field(default_factory=dict)
block_states: Dict[Root, BeaconState] = field(default_factory=dict)
block_timeliness: Dict[Root, boolean] = field(default_factory=dict)
checkpoint_states: Dict[Checkpoint, BeaconState] = field(default_factory=dict)
latest_messages: Dict[ValidatorIndex, LatestMessage] = field(default_factory=dict)
unrealized_justifications: Dict[Root, Checkpoint] = field(default_factory=dict)
# [New in EIP-7805]
inclusion_list_store: InclusionListStore
unsatisfied_inclusion_list_blocks: Set[Root] = field(default_factory=Set)
```
`on_inclusion_list` works the same way except that it stores ILs inside its inclusion list store.
```python
def on_inclusion_list(store: Store, signed_inclusion_list: SignedInclusionList) -> None:
inclusion_list = signed_inclusion_list.message
validator_index = inclusion_list.validator_index
key = (inclusion_list.slot, inclusion_list.inclusion_list_committee_root)
inclusion_list_store = store.inclusion_list_store
inclusion_lists = inclusion_list_store.inclusion_lists.setdefault(key, set())
equivocators = inclusion_list_store.inclusion_list_equivocators.setdefault(key, set())
if validator_index in equivocators:
return
for stored_inclusion_list in inclusion_lists:
if stored_inclusion_list.validator_index != validator_index:
continue
if stored_inclusion_list != inclusion_list:
equivocators.add(validator_index)
inclusion_lists.remove(stored_inclusion_list)
# Whether it was an equivocation or not, we have processed this `inclusion_list`.
return
time_into_slot = (store.time - store.genesis_time) % SECONDS_PER_SLOT
is_before_view_freeze_deadline = (
get_current_slot(store) == inclusion_list.slot and time_into_slot < VIEW_FREEZE_DEADLINE
)
if not is_before_view_freeze_deadline:
return
# Store this first `inclusion_list` from `validator_index`.
inclusion_lists.add(inclusion_list)
```
Alternatively, `on_inclusion_list` can wrap the `store_inclusion_list` from option 2.
```python
def on_inclusion_list(store: Store, signed_inclusion_list: SignedInclusionList) -> None:
inclusion_list = signed_inclusion_list.message
inclusion_list_store = store.inclusion_list_store
time_into_slot = (store.time - store.genesis_time) % SECONDS_PER_SLOT
is_before_view_freeze_deadline = (
get_current_slot(store) == inclusion_list.slot and time_into_slot < VIEW_FREEZE_DEADLINE
)
store_inclusion_list(inclusion_list_store, inclusion_list, is_before_view_freeze_deadline)
```
A new helper function `get_inclusion_list_transactions` takes state and slot, and returns a unique set of IL transactions from non-equivocating ILs.
```python
def get_inclusion_list_transactions(
store: Store,
state: BeaconState,
slot: Slot,
) -> Sequence[Transaction]:
inclusion_list_committee = get_inclusion_list_committee(state, slot)
inclusion_list_committee_root = hash_tree_root(inclusion_list_committee)
key = (slot, inclusion_list_committee_root)
inclusion_list_store = store.inclusion_list_store
inclusion_lists = inclusion_list_store.inclusion_lists.setdefault(key, set())
equivocators = inclusion_list_store.inclusion_list_equivocators.setdefault(key, set())
inclusion_list_transactions = {
transaction
for inclusion_list in inclusion_lists
if inclusion_list.validator_index not in equivocators
for transaction in inclusion_list.transactions
}
return list(inclusion_list_transactions)
```
Alternatively, a call to this function can be replaced with the `get_inclusion_list_transactions` from option 2 as follows:
```python
...
get_inclusion_list_transactions(store.inclusion_list_store, state, slot - 1)
...
```
Lastly, `on_block` calls `get_inclusion_list_transactions` to retrieve IL transactions from the inclusion list store via the fork choice store.
##### Modified `on_block`
```python
def on_block(store: Store, signed_block: SignedBeaconBlock, execution_engine: ExecutionEngine) -> None:
"""
Run ``on_block`` upon receiving a new block.
"""
...
state_transition(state, signed_block, True)
# [Modified in EIP-7805]
inclusion_list_transactions = get_inclusion_list_transactions(
store, state, block.slot - 1
)
is_inclusion_list_satisfied = execution_engine.is_inclusion_list_satisfied(
execution_payload, inclusion_list_transactions
)
if not is_inclusion_list_satisfied:
store.unsatisfied_inclusion_list_blocks.add(block_root)
...
# Add proposer score boost if the block is timely, not conflicting with an existing block
# and satisfies the inclusion list constraints.
if is_timely and is_first_block and is_inclusion_list_satisfied: # [Modified in EIP-7805]
store.proposer_boost_root = hash_tree_root(block)
...
```
### Suggestions
The PR author would like to suggest using the `ExecutionEngine.is_inclusion_list_satisfied` call without modifying `state_transition` for IL validation. Modifying `state_transition` seems excessive and the CL spec can remain agnostic even if the `engine_newPayload` call is used to pass ILs. For example, `engine_newPayloadV4` takes `expectedBlobVersionedHashes` as a parameter, whereas the CL spec uses the `ExecutionEngine.is_valid_versioned_hashes` call.
Given that ILs may be pruned after their targeted slot, the PR author would like to suggest proceeding with either option 2 or option 3. Since what directly affects fork choice is `unsatisfied_inclusion_list_blocks`, it’s preferable for the fork choice store to have this, but not likely the ILs themselves. However, having a reference to the inclusion list store may improve clarity regarding IL timeliness. Whether having a reference or leaving it abstracted remains open for discussion.
Sign in with Wallet
Connect another wallet