# The epoch at which the capella/deneb/electra forks are set to occur.
capella_fork_epoch:0
deneb_fork_epoch:4
electra_fork_epoch:null
# The epoch at which the deneb/electra forks are set to occur.
deneb_fork_epoch:0
electra_fork_epoch:500
# Network sync base url for syncing public networks from a custom snapshot (mostly useful for shadowforks)
# Defaults to "https://ethpandaops-ethereum-node-snapshots.ams3.digitaloceanspaces.com/
...
...
@@ -640,7 +639,6 @@ persistent: false
# Default: "null" - no mev boost, mev builder, mev flood or relays are spun up
# "mock" - mock-builder & mev-boost are spun up
# "full" - mev-boost, relays, flooder and builder are all spun up
# Users are recommended to set network_params.capella_fork_epoch to non zero when testing MEV
# We have seen instances of multibuilder instances failing to start mev-relay-api with non zero epochs
mev_type:null
...
...
@@ -750,8 +748,7 @@ participants:
cl_type:lighthouse
cl_image:sigp/lighthouse:latest
network_params:
capella_fork_epoch:2
deneb_fork_epoch:4
deneb_fork_epoch:0
additional_services:[]
wait_for_finalization:false
wait_for_verifications:false
...
...
@@ -803,7 +800,7 @@ participants:
count:2
mev_type:full
network_params:
capella_fork_epoch:1
deneb_fork_epoch:1
additional_services:[]
```
...
...
@@ -894,8 +891,6 @@ Starting your network up with `"mev_type": "full"` will instantiate and connect
* After the 3rd epoch, the mev-relay service will begin to receive execution payloads (eth_sendPayload, which does not contain transaction content) from the mev-builder service (or mock-builder in mock-mev mode).
* Validators will start to receive validated execution payload headers from the mev-relay service (via mev-boost) after the 4th epoch. The validator selects the most valuable header, signs the payload, and returns the signed header to the relay - effectively proposing the payload of transactions to be included in the soon-to-be-proposed block. Once the relay verifies the block proposer's signature, the relay will respond with the full execution payload body (incl. the transaction contents) for the validator to use when proposing a SignedBeaconBlock to the network.
It is recommended to use non zero value for `capella_fork_epoch` by setting `network_params.capella_fork_epoch` to a non-zero value
in the arguments passed with `mev_type` set to `full`.
</details>
This package also supports a `"mev_type": "mock"` mode that will only bring up:
...
...
@@ -905,15 +900,6 @@ This package also supports a `"mev_type": "mock"` mode that will only bring up:
For more details, including a guide and architecture of the `mev-boost` infrastructure, go [here](https://docs.kurtosis.com/how-to-full-mev-with-ethereum-package/).
## MEV-Boost usage with Capella at Epoch 0
This note is from 2023-10-05
`flashbots/mev-boost-relay:0.27` and later support `capella_fork_epoch` at `0` but this seems to require a few flags enabled
on the `lighthouse` beacon client including `--always-prefer-builder-payload` and `--disable-peer-scoring`
Users are recommended to browse the example tests [`./.github/tests`](./.github/tests); as inspiration for different ways to use the package.
## Pre-funded accounts at Genesis
This package comes with [seven prefunded keys for testing](https://github.com/kurtosis-tech/ethereum-package/blob/main/src/prelaunch_data_generator/genesis_constants/genesis_constants.star).