-
-
Published
Linked with GitHub
# `FOCIL` prototype
## engine API
### `engine_getInclusionListV1`
* parameters:
* `parent_hash`
* 32-byte hex-encoded string
* response:
* `transactions`
* array
* item: hex-encoded string
```
{
"id": 1,
"jsonrpc": "2.0",
"method": "engine_getInclusionListV1",
"params": [
"0x00.."
]
}
{
"id":1
"jsonrpc":"2.0"
"result": [
"0x00..",
]
```
## EL
### `alloy`
the changes of the fork are available [here](https://github.com/alloy-rs/alloy/compare/main...jacobkaufmann:alloy:prague-focil).
the crate(s) had to be modified to represent the IL in the engine API.
### `reth`
the changes of the fork are available [here](https://github.com/paradigmxyz/reth/compare/main...jacobkaufmann:reth:prague-focil).
summary
* engine API
* add `getInclusionListV1`
* add IL to payload attributes
* payload attributes verification
* add IL to new payload request
* block execution/validation
* IL validation upon block execution
* block construction
* application of IL transactions to execution payload output of pre-existing payload build process
`TODO`
* testing
* more comprehensive error handling
* more comprehensive tracing/metrics
* add max IL size to global config
* block construction optimizations
* i.e. be more clever about which IL transactions can(not) be (in)validated by other transactions
* constrain IL transactions returned via engine API by parent hash
`NOTE`
* currently, there is no `engine_updateInclusionListV1` endpoint to update an existing payload with IL(s), and instead we rely on `engine_forkChoiceUpdated`
* currently, the return type of `engine_getInclusionListV1` is an array of byte arrays
## CL
### `lighthouse`
the changes of the fork are available [here](https://github.com/sigp/lighthouse/compare/stable...jacobkaufmann:lighthouse:electra-focil).
summary
* beacon chain
* `get_inclusion_list_committee`
* engine
* check for `getInclusionListV1` engine capability
* make RPC request for `getInclusionListV1`
* beacon
* endpoint to retrieve IL duties
* validator client
* poll beacon node for IL duties
* keep track of IL duties
* p2p
* most of the gossip verifications
* IL gossip-sub topic
`TODO`
* testing
* more comprehensive error handling
* more comprehensive tracing/metrics
* fork choice
* p2p
* finish gossip verifications
* keep track of equivocations
* handle IL gossip message
* beacon API
* support requests for historical IL duties
* endpoint to retrieve IL corresponding to IL duty
* endpoint to broadcast signed IL
* engine API
* add IL to new payload request
* beacon node
* query IL from EL
* validator client
* query IL from beacon node to sign and broadcast
`NOTE`
* able to reuse pre-existing logic for attestation shuffling
* `POST validator/duties/inclusion_list/{epoch}`
* request data: list of validator indices
* response data: array of items containing validator index, public key, slot
## testing
build docker images for the modified CL and EL clients, and deploy a devnet via the [`ethereum-package`](https://github.com/ethpandaops/ethereum-package) kurtosis package.
deploy some percentage of ethereum nodes with a modified `reth` EL, such that we can reliably censor certain transactions.
for example, we can censor any transaction whose input (call)data is equal to some pre-determined ASCII string (e.g. "censorship").
we would modify the [`Pool`](https://reth.rs/docs/reth_transaction_pool/struct.Pool.html) to replace the stock [`TransactionValidator`](https://reth.rs/docs/reth_transaction_pool/validate/trait.TransactionValidator.html).