# MEV access on Goerli/Prater testnet

By [Ladislaus](https://paragraph.com/@ladislaus) · 2022-06-18

---

`→ updated on 09/28/2022 for long-term Goerli/Prater testnet (previously Ropsten)`

_Shoutout to_ [_realbigsean_](https://github.com/realbigsean) _from SigmaPrime for his guidance and insights and_ [_Yorick_](https://github.com/yorickdowne) _from EthStaker for feedback and review_

* * *

_This post aims to provide a quick and minimalistic setup guide on how to test accessing MEV as a validator on the Goerli/Prater testnet._

[_In a preceding guide_](https://mirror.xyz/ladislaus.eth/O5bW3rDnKITHlCXE9K_0IwiEwDrc6qw-y3MpX0EUcew) _I tried to highlight essential requirements for running an Ethereum node post-merge using Ubuntu & Docker. With_ `mev-boost` _as an optional, additional piece of software in the node stack, I try to leverage_ `docker-compose` _this time._

MEVvvhat…?!
-----------

Maximum Extractable Value is a controversial topic within the Ethereum ecosystem. As the network has experienced increased adoption and settlement value, profitable opportunities to insert TXs at particular places of a block have become more prevalent.

These practices are often referred to as _front-running_, among others, implying centralisation vectors and even chain instabilities. Hence, the ultimate goal for blockchain R&D is to minimize (or eliminate?!) such negative externalities for users and the network as a whole. A first step towards mitigating them is to democratize access to MEV.

> In essence, MEV boils down to the fundamental question of how the process of fair transaction ordering in a block is supposed to happen in the most trust-minimised fashion.

Technically, a validator -representing the proposer of a block- defaults to asking the local execution client for a particular transaction order (typically ranked by the highest paying TX fees). However, there’s also the option to ask a third-party **relay** for a pre-constructed block, e.g. [Flashbots](https://docs.flashbots.net/), a collective operating an external block builder protocol. A relay is a doubly-trusted intermediary matching specialised builders on the one hand with validators on the other hand.

src: https://github.com/flashbots/mev-boost

Node operators can access MEV with the help of a software called `mev-boost` by Flashbots. In the given case, if it’s the validator’s turn to propose a block, the CL client Lighthouse will ask both mev-boost and the EL client Besu for a block, ultimately opting for the better paying one.

> _Note:_
> 
> _In case a relay provided the validator with an invalid pre-constructed block (‘execution payload header’), which turned out to be invalid after the validator client had signed it, this does_ **_not_** _represent a slashable event (rather leads to a missed proposal)._

Read about how [Flashbots argues for running mev-boost](https://writings.flashbots.net/writings/why-run-mevboost). And feel free to dive deeper into the woods [here](https://twitter.com/lightclients/status/1533915131536605185), [here](https://youtu.be/vhxIjEnhutw) and [here](https://youtu.be/OD54WfVuDWw). There’s a bunch of open social, technical and cryptoeconomic research and design questions to be tackled.

* * *

How to access MEV on Goerli/Prater
----------------------------------

For the sake of this demo, I chose Besu by ConsenSys as an EL client. It comes with a lean new database structure called [“Bonsai tries” and offers implicit pruning functionality](https://consensys.net/blog/news/test-staking-ahead-of-the-merge-with-improved-bonsai-tries-state-storage/), lowering disk space usage and avoiding potential downtimes for manual pruning. Snap sync is also about to hit the latest release. Lighthouse by SigmaPrime serves as CL client (i.e. Beacon Node & Validator Client).

### Prerequisites

*   [Ubuntu & pre-installed docker-compose](https://eth-docker.net/docs/Usage/Prerequisites/#ubuntu-prerequisites)
    
*   [A validator keystore for Goerli/Prater](https://github.com/remyroy/ethstaker/blob/main/merge-goerli-prater.md#trying-the-goerliprater-merge-testnet)
    
*   Specify [\--suggested-fee-recipient](https://lighthouse-book.sigmaprime.io/suggested-fee-recipient.html)
    
*   _Optionally_ modify the data directories that get mounted from the host into the Besu/Lighthouse docker containers
    

### Run a complete node stack with mev-boost

**1)** Navigate to your `/home` directory. Create a project directory with subfolders:

    $ mkdir -p ETHclient/{besu,lighthouse-bn,lighthouse-vc,validator_keys,JWT}; cd ETHclient
    

**2)** Generate a [JasonWebToken (JWT)](https://launchpad.ethereum.org/en/merge-readiness/) so that the execution and consensus client can communicate securely:

    $ openssl rand -hex 32 | tr -d "\n" > "$(pwd)/JWT/jwtsecret"
    

**3)** Paste the validator keystore(s) in the host directory `./validator_keys`

**4)** [Add the validator key to Lighthouse](https://lighthouse-book.sigmaprime.io/validator-import-launchpad.html#docker)

    $ docker run -it -v $(pwd)/lighthouse-vc:/root/.lighthouse -v $(pwd)/validator_keys:/validator_keys sigp/lighthouse:latest-modern lighthouse --network prater account validator import --directory /validator_keys
    

**5)** Copy & Paste the below attached docker-compose code in a newly created file to be named `besu-lh-mevboost.yaml` in the project directory.

**6)** Start the docker-compose environment:

    $ docker-compose -f besu-lh-mevboost.yaml -p prater up -d
    

**7)** Eventually, stop the docker-compose environment:

    $ docker-compose -f besu-lh-mevboost.yaml -p prater stop
    

* * *

    version: "3.0"
    
    services:
        beacon_node:
            image: sigp/lighthouse:latest-modern
            networks:
                - ETHclient_net
            container_name: prater-bn
            restart: unless-stopped
            volumes:
                - ./lighthouse-bn:/root/.lighthouse
                - ./JWT:/JWT            
            ports:
                - 9000:9000/tcp # consensus p2p, open to internet
                - 9000:9000/udp # consensus p2p, open to internet
            command: >
              lighthouse
              --debug-level info
              --network prater
              beacon_node
              --datadir /root/.lighthouse/prater
              --http
              --http-address 0.0.0.0          
              --execution-endpoint http://goerli-besu:8551
              --execution-jwt /JWT/jwtsecret
              --checkpoint-sync-url https://goerli.beaconstate.info,https://goerli.checkpoint-sync.ethdevops.io,https://goerli.beaconstate.ethstaker.cc/
              --builder http://prater-mevboost:18550
              
        validator_client:
            image: sigp/lighthouse:latest-modern
            networks:
                - ETHclient_net
            container_name: prater-vc
            restart: unless-stopped
            volumes:
                - ./lighthouse-vc:/root/.lighthouse
            depends_on:
                - beacon_node
            command: >
              lighthouse
              --debug-level info
              --network prater
              validator
              --beacon-nodes http://prater-bn:5052
              --suggested-fee-recipient 0x0000000000000000000000000000000000000000
              --builder-proposals
            
        execution_client:
            image: hyperledger/besu:latest
            networks:
                - ETHclient_net
            container_name: goerli-besu
            restart: on-failure
            environment:
                - "JAVA_OPTS=-Xmx4g"
            volumes:
                - ./besu:/opt/besu/data
                - ./JWT:/JWT
            ports:
                - 30303:30303/tcp # consensus p2p, open to internet
                - 30303:30303/udp # consensus p2p, open to internet
            command: >
              --network goerli
              --data-path /opt/besu/data
              --data-storage-format BONSAI
              --sync-mode X_SNAP
              --rpc-http-enabled
              --rpc-http-host=0.0.0.0
              --rpc-http-api=ETH,NET,WEB3
              --rpc-http-cors-origins=*
              --host-allowlist=*
              --engine-host-allowlist=*
              --engine-jwt-secret=/JWT/jwtsecret
              --engine-rpc-port=8551
            
        mev_boost:
            image: flashbots/mev-boost:latest
            networks:
                - ETHclient_net
            container_name: prater-mevboost
            restart: on-failure
            entrypoint:
                - /app/mev-boost
                - -addr
                - 0.0.0.0:18550
                - -prater
                - -relay-check
                - -relays
                - https://0xafa4c6985aa049fb79dd37010438cfebeb0f2bd42b115b89dd678dab0670c1de38da0c4e9138c9290a398ecd9a0b3110@builder-relay-goerli.flashbots.net,https://0x821f2a65afb70e7f2e820a925a9b4c80a159620582c1766b1b09729fec178b11ea22abb3a51f07b288be815a1a2ff516@bloxroute.max-profit.builder.goerli.blxrbdn.com
                
    networks:
        ETHclient_net:
            driver: bridge
    

* * *

### Closing Remarks

Obviously, the more testnet validators you run, the higher the likelihood of being randomly selected to propose a block (i.e. you likely have to wait less long)

**Watch out for the following logs in mev-boost:**

    level=info msg="getHeader: successfully got more valuable payload header"
    
    level=info msg="getPayload: received payload from relay"
    

**And check if your block has made it on-chain:**

`https://prater.etherscan.io/block/<yourblocknumber>`

* * *

\*\*\*\*

_Please keep in mind this is a testnet guide that may contain mistakes and that takes shortcuts which come with trade-offs. It could quickly become outdated as it’s subject to ever evolving network and client changes._

\*\*\*\*

_This post was supported by a grant from a CLR funding round held by EthStaker, mainly matched by the EF._

---

*Originally published on [Ladislaus](https://paragraph.com/@ladislaus/mev-access-on-goerli-prater-testnet)*
