# Testnet guide: extract MEV with Prysm post-merge This documents the necessary steps to run [Prysm](https://github.com/prysmaticlabs/prysm) beacon client and validator client for MEV extraction. It's important to keep in mind that these are prototypes so expect [breakages and bugs](https://github.com/prysmaticlabs/prysm/issues?q=is%3Aissue+is%3Aopen+label%3ABuilder). The instructions will likely change later and we'll update them along the way. With that said, we are months away from the merge, and **now** is a crucial time to begin testing MEV as an end-to-end product from validator to beacon node to mev-boost to relayer and to a builder. ## Optional readings on the why what and how https://writings.flashbots.net/writings/beginners-guide-mevboost/ https://writings.flashbots.net/writings/why-run-mevboost/ [lightclient - Extracting MEV After the Merge](https://www.youtube.com/watch?v=ci7pLez8eDk) [Bulder API spec](https://github.com/ethereum/builder-specs/tree/main/apis/builder) ## Prysm images To build from source. Please use latest [develop](https://github.com/prysmaticlabs/prysm/tree/develop) branch To use dockers. Here are the docker images: Beacon client: gcr.io/prysmaticlabs/prysm/beacon-chain:v2.1.4-rc.2 Validator client: gcr.io/prysmaticlabs/prysm/validator:v2.1.4-rc.2 ## Instructions on how to run testnets [Installation guide](https://docs.prylabs.network/docs/install/install-with-script/) [Fee recipient guide](https://docs.prylabs.network/docs/execution-node/fee-recipient/) There are two ways to set up your fee recipient. One way is `--suggested-fee-recipient` with `--enable-builder`. This means every validator will use that fee recipient. Another way is through a config file. This enables customization. Example: ``` { "proposer_config": { "0xa057816155ad77931185101128655c0191bd0214c201ca48ed887f6c4c6adf334070efcd75140eada5ac83a92506dd7a": { "fee_recipient": "0x50155530FCE8a85ec7055A5F8b2bE214B3DaeFd3", "builder": { "enabled": true, "gas_limit": 30000000 } }, "default_config": { "fee_recipient": "0x6e35733c5af9B61374A128e6F85f553aF09ff89A", "builder": { "enabled": true, "gas_limit": 30000000 } } } ``` ## ⚠️ Additional flags For your testnet beacon client, you will want to point them to the existing relays. Flashbots has kindly provided us with these relays for testing. Kiln: https://builder-relay-kiln.flashbots.net Ropsten: https://builder-relay-ropsten.flashbots.net Sepolia: https://builder-relay-sepolia.flashbots.net On your testnet beacon client. Add the `--http-mev-relay` flag Example for Sepolia: `--http-mev-relay=https://builder-relay-sepolia.flashbots.net --sepolia` On your testnet validator . Add the `--enable-builder` flag Example for Sepolia: `--suggested-fee-recipient=0xD9A5179F091d85051d3C982785Efd1455CEc8699 --sepolia --enable-builder` ## Running your own mev-boost The `above section` utilizes direct connection to relay. This is not intended for production. In production, beacon node should connect the `mev-boost`. Visit [mev-boost](https://github.com/flashbots/mev-boost) on further details on how to connect those twos. ## Validations Now you have set up your beacon client and validators. You launched them and they are working. How do you know that MEV extraction is working as intended? On validator client. We want to see the following log. It should occur during start-up and every epoch ``` Submitted builder validator registration settings for custom builders ``` Examples: ```json= {"backend":null,"duration":9487420858,"message":"gRPC request finished.","method":"/ethereum.eth.v1alpha1.BeaconNodeValidator/SubmitValidatorRegistration","severity":"DEBUG"} {"message":"Submitted builder validator registration settings for custom builders","prefix":"validator","severity":"INFO"} ``` On beacon client. We want to see the following logs when your validator proposes a block. ``` Retrieved header from builder Retrieved full payload from builder ``` Examples: ```json {"blockHash":"0x24fed5a50492d0592bdc974943931cd53ba713c35ec749baeb2dd75d10a0fb33","feeRecipient":"0xd9a5179f091d85051d3c982785efd1455cec8699","gasUsed":0,"message":"Retrieved header from builder","prefix":"rpc/validator","severity":"INFO","slot":875293} {"beaconStateRoot":"0xb91ad0e06759435225b9369de656282c43ef5e0b8a15f6cb7dec93431575412c","message":"Computed state root","prefix":"rpc/validator","severity":"DEBUG"} {"blockHash":"0x24fed5a50492d0592bdc974943931cd53ba713c35ec749baeb2dd75d10a0fb33","feeRecipient":"0xd9a5179f091d85051d3c982785efd1455cec8699","gasUsed":0,"message":"Retrieved full payload from builder","prefix":"rpc/validator","severity":"INFO","slot":875293,"txs":0} {"blockRoot":"69124129eafae6d5b01aa43c8b7934e8d8ad79b0fbbdd0378f5808520c2d2642","message":"Broadcasting block","prefix":"rpc/validator","severity":"DEBUG"} ``` Congrats! With those logs, you have successfully tested MEV extraction with Prysm prototype. This is not the final product, we have many enhacements on the pipeline. We'll give periodic updates along the way. If you run into any issues or have any questions. Please ping me @terencechain on TG or terence#0083 on Discord. With issues and questions. Please open issues in respected repos: Prysm issue: https://github.com/prysmaticlabs/prysm/issues MEV-boost issue https://github.com/flashbots/mev-boost/issues Builder issue: https://github.com/ethereum/builder-specs/issues
Last changed by  
 
Prysmatic Labs eth2 development team
6342

Read more

Generating an HTTP Server for Beacon APIs

Introduction One of our current OKRs is to implement Beacon API endpoints using an HTTP server. This will remove a lot of complexity, because currently we have to transform HTTP requests/responses, which conform to OpenApi specification, into gRPC-compliant structures. This results in complex middleware code that we have to maintain. To make this task easier, it would be nice to be able to automatically generate server code from the Beacon API specification. I spent some time searching for the right tool and unfortunately couldn't find anything suitable. Tool overview https://github.com/go-swagger/go-swagger go-swagger does not support OpenApi 3.0. It provides a flatten utility, which I hoped to use before applying another tool, but unfortunately flattening a 3.0 spec does not produce a valid format. https://github.com/deepmap/oapi-codegen

1/17/2023
Blockchain Integration Test Harness

Background In Prysm, we have two main kinds of tests: e2e and unit tests. For the most part, unit tests have a very complex setup especially in critical files such as the state transition, forkchoice, and the sync service. Even these complex examples tend to mock a lot of the blockchain's functionality by populating the database themselves or using mock versions of services for simplicity. Most recently, we had a situation where we had a bug at runtime in one of the caches used during block processing here, and the resolution was pretty simple but actually almost impossible to test with our current testing suite. This triggered a discussion about why it was hard to test this code and if we could do anything about it. It turns out we don't have test harnesses powerful enough to give us a meaningful test aside from our end-to-end suite, and that immediately triggered some concerns. This document designs a new test harness for testing chain functionality in Prysm with minimal mocking, and helps us test different behaviors of block processing that are hard to set up otherwise outside of e2e. Existing blockchain test harnesses When testing blockchain behavior, we care about the following situations:

10/28/2022
Blob Sidecar handling in Prysm

Background In EIP4844, BlobsSidecar was introduced to accept "blobs" of data to be persisted in the beacon node for period of time. These blobs bring rollup fees down by magnitude and enable Ethereum to remain competitive without sacrificing decentralization. Blobs are pruned after ~1 month. Available long enough for all actors of a L2 to retrieve it. The blobs are persisted in beacon nodes, not in the execution engine. Alongside these blobs, BeaconBlockBody contains a new field blob_kzg_commitments. It's important that these kzg commitments match blob contents. Note that on the CL, the blobs are only referenced in the BeaconBlockBody, and not encoded in the BeaconBlockBody. Instead of embedding the full contents, the contents are propagated separately in BlobsSidecar above. The CL must do these three things correctly: Beacon chain: process updated beacon blocks and ensure blobs are available P2P network: gossip and sync updated beacon block types and new blobs sidecars Honest validator: produce beacon blocks with blobs, publish the blobs sidecars In this doc, we explore the spec dependencies between BlobsSidecar and BeaconBlockBody loosely coupled and implementation complexity due to them being loosely coupled.

8/17/2022
Aug 8, 2022 Payload Reconstruction Bug

Background Terence first notifies us of an interesting bug he observes with the --enable-only-blinded-beacon-blocks feature flag Prater node, v2.1.4.rc1 No EL client Post bellatrix, but before the merge {"error":"could not fetch execution block with txs by hash 0x0000000000000000000000000000000000000000000000000000000000000000: timeout from http.Client","message":"Could not get reconstruct full bellatrix block from blinded body","prefix":"sync","severity":"ERROR"} hash=0 does not mean empty payload. We check with two means: TTD (which we don't have due to the EL being unavaibale) and empty payload (which we don't have due to the block being blind)

8/8/2022
Read more from Prysmatic Labs
Published on HackMD