Notes below are for a POC / demo of the relay monitor with expanded features deployed on Sepolia. Short recorded demo of what the Relay Monitor Website looks like, deployed on Sepolia and monitoring the Flashbots Sepolia Relay and a Faulty Relay -- https://share.cleanshot.com/Lr7YD2Sc URLs Relay Monitor Websitehttps://sepolia.rm.mev.software Relay Monitor API https://sepolia.api.rm.mev.software

Recording: https://www.youtube.com/watch?v=-sNlISQF_ow Work is in progress for 4844 readiness. There are a few pieces to coordinate to add new types that support blobs while keeping the current flow working.Next steps:About two weeks away from participating in a testnet. When ready to test, relays should watch for latency spikes on API calls since more data will be passed around. Various improvements have been implemented into MEV-Boost relay, most optimizing for simulating as little bid submissions as possible. Optimistic Relaying is proving to be a challenge from the operational end. Work on V2 is progressing, but data explorations hint at potentially serious issues with in-time payload delivery by builders. Next steps:More data exploration and thinking through colocation incentives.

The following is a mini-report of my EPF project work on expanding the feature set of relay monitor. This can also be used as a paired read along with this PR that implements the actual changes to the functionality. This report assumes some familiarity with the MEV supply chain, PBS, and mev-boost. In terms of background reading on MEV, I made a page with all my notes, roughly organized / tagged as part of my reading-up during the first few weeks of EPF. It can be found here: https://hackmd.io/@andriidski/Hkl6Jh_nBn There are also slides from my short presentation / demo to the EPF fellows, which can be found here: https://docs.google.com/presentation/d/1OjwVr5jGSGLKNj3u3h7ijw8hU49DX16b4SoI2Y5DEck/edit?usp=share_link

General Notes on Proposer-Builder Separation (PBS) https://barnabe.substack.com/p/pbs Suggestion to look at PBS from two separate lenses: Market structure Allocation mechanism Market structure is what I think of as the protocol acting out a role of an "enforcer". The protocol ensures certain guarantees / protections for the proposers and for third-parties, i.e. builders. Example of protections can be "proposer is paid a bid no matter what" or "builder given guarantee of bid acceptance, via say, blind signed block header".

Recording: https://www.youtube.com/watch?v=oxb_-4z1Sr8 Summary Sepolia Capella hard fork went well with Goerli coming up a few days after the call. Ultrasound Optimistic Relay running smoothly on Goerli and preparing for mainnet launch. Still some questions around upstreaming the changes into Flashbots MEV-Boost relay repository. Some builders and relays have expressed concern around added operational overhead of running in OR mode. Relay sustainability is an open question. Want to make sure that running the relay is accessible and sustainable while enshrined PBS research and development is in progress. Capella Sepolia recap First topic is the upcoming hard fork readiness for Capella. Sepolia hard fork went pretty well. (Chris from Flashbots gives an update on their side). Went well, on relay repo main branch everything is working and MEV-Boost has an alpha release. Had an issue setting the correct Shanghai override, so everything only worked a few hours later. But all is in order after config issues were fixed and everything is working fine. Investigating updating to the newest Geth version.

Recording: https://www.youtube.com/watch?v=9LTP6rC-HNA Summary First MEV-Boost Community Call. Goal of these is to discuss MEV-Boost, relays, builders, upcoming hard fork (Capella), and broadly where all of this is heading. Future calls will be likely supply driven. Changes to the builder-specs and relay-specs are in progress for Capella. Main change is the updated types to support new formats, e.g. added withdrawals. Testing MEV-Boost software stack is an involved process, especially around hard forks and the fork boundary. Some ideas are proposed where automated testing can integrate relevant binaries to reduce the load on the operators. Discussed the Optimistic Relay proposal from Ultrasound relay. Rollout is first on Goerli and then on mainnet with a handful of select builders who have expressed interest in being early testers / adopters. Capella Specs

Recording: https://www.youtube.com/watch?v=KmmLQRYWGmc Summary Capella fork is coming up on mainnet. Builders and relays need to make sure they are running up-to-date software Ultrasound Optimistic Relay seeing good adoption as well as some interest from more relays. In-progress work happening on a V2 and in the meantime exploring changes that can produce even more latency optimizations Ultrasound Relay interested in more analysis on missed slots and overall network health Capella Goerli Capella is coming up on mainnet (two weeks or so from call). Goerli went well, albeit some confusion around which software to run. Eventually everyone shifted over to the right code. Blocknative had an issue on their Dreamboat relay related to an infrastructure misconfiguration of Prysm vs. Lighthouse nodes. Once resolved, Dreamboat handled the change on Goerli. Generally went well for everyone.

Recording: https://www.youtube.com/watch?v=U3ncYq60A2U Summary Things generally went well with the Capella hard fork. There was an issue with Prysm where all Prysm validators using MEV-Boost failed to propose blocks.Next steps:More end-to-end testing with hive for future upgrades A validator performed an unbundling attack abusing a missing validation on the MEV-Boost relay. A bug in the relay, but points to the idea of unbundling. Next steps:More research on timing games / attestation races in the generic unbundling attack scenario Continue + increase alerting

(Some old notes on consistency models). A consistency model is a set of histories of operations Read Uncommitted https://jepsen.io/consistency/models/read-uncommitted Prohibits dirty writes where two transactions modify the same data, but allows all other behavior, including$w_1(x) … r_2(x)$ - dirty read $r_1(x) … w_2(x)$ - fuzzy read (read by tx1 then write by tx2) Read Committed https://jepsen.io/consistency/models/read-committed

TLDR / Main Updates Postgres DB backend for bid analysis API endpoints for analysis stats Dev Update for 01/23/2023 Last week's update mentioned WIP work on persisting bid analysis data, and now that the patch is done, this week's update contains some notes on how it works and some useful things coming with it. So, last week I worked on the logic to persist bid analysis data in a flexible way and implemented an initial query layer on top of the DB store to get bid analysis data. I committed the cleaned-up patch here. The reason for this work was two-fold. First, so far bid analysis have been stored in-memory as a mapping of analysis type -> count of those analysis events, so persistence was needed. Second, because of having to store analysis in-memory, you couldn't really query for results in a flexible way, e.g. for slot ranges or filter by category. Bid Analysis

TLDR / Main Updates Postgres DB backend store is integrated and eveything is saved into a DB, analysis stats are also being saved into a table, but this patch is still partially a WIP Refactored parts of the relay monitor "collector" to support re-tries. This can be customized to specify a delay and max number of retries. The idea is to re-use this in any code path that might benefit from requesting data per-slot Dev Update for 01/16/2023 This update is shorter, as last week led to a few WIP patches that are still in progress and will be ready by next update: rewritten bid analysis functions (rules of "validity" of bid received via getHeader()), completed flow of pushing all analysis + faults into a DB, and report generation from the DB (and even turning this into a stream). I also got started playing around with some initial work on refactoring handling validator registrations by the relay monitor, but I'm focusing on the existing WIPs first. Retry logic

TLDR / Main Updates For the last few weeks I have been working on designing a detailed data model for storing arbitrary amounts of data by a relay-monitor. I think an interesting re-usable feature of a relay monitor is being able to independently collect as much data as possible and at smallest granularities possible, with "analysis" processes then independently / in parallel reducing these into stats. The key is that the analyzers can be different, for instance I think it's interesting to be able to build independent analyzers for scoring correctness, or censorship, or latency. While the "scores" measure different metrics of reputation, the relay monitor can be used as a minimally stateful / un-opinionated data collector. Last week I've hacked together two proof-of-concepts with Postgres and MongoDB (since both have pretty solid Go libraries) to store validator registartions and bid submissions. Technical recap from early weeks For posterity, since early updates eluded to the initial work I was doing on the relay monitor but weren't very in-depth. Exposing relay domain -- intro ticket that implemented a way to include metadata along with a transcript. This is used now to include the domain for the relay, which could be useful for verification or in case it updates. There is room to add other metadata under the meta field in the response

TLDR / Main Updates Week of 11/07/2022 ✅ research into in-protocol PBS and writing summaries for prominent ethresear.ch posts Notes are written up in my WIP doc in notion main goal here was to get a good sense of what in-protocol PBS gives us and why Week of 11/14/2022

Execution (geth) geth --sepolia --http --http.api eth,net,engine,admin --authrpc.jwtsecret /home/ubuntu/ethereum/consensus/prysm/jwt.hex --override.terminaltotaldifficulty 17000000000000000 --bootnodes enode://ec66ddcf1a974950bd4c782789a7e04f8aa7110a72569b6e65fcd51e937e74eed303b1ea734e4d19cfaec9fbff9b6ee65bf31dcb50ba79acce9dd63a6aca61c7@52.14.151.177:30303 --http.port 8545 --http.addr 0.0.0.0 Consensus Beacon chain checkpoint sync endpoints -- https://eth-clients.github.io/checkpoint-sync-endpoints/#sepolia Prysm Follow the getting started directions from Prysm -- https://docs.prylabs.network/docs/install/install-with-script ./prysm.sh beacon-chain --execution-endpoint=http://localhost:8551 --sepolia --suggested-fee-recipient=0x01234567722E6b0000012BFEBf6177F1D2e9758D9 --jwt-secret=jwt.hex --genesis-state=genesis.ssz --checkpoint-sync-url=https://sepolia.checkpoint-sync.ethdevops.io --genesis-beacon-api-url=https://sepolia.checkpoint-sync.ethdevops.io --rpc-host=0.0.0.0 --grpc-gateway-host=0.0.0.0

I'm interested in researching dynamics of MEV in PoS Ethereum and effects of centralization pressure, among other things. I'm also interested in mitigations of risks as part of immediate efforts of out-of-protocol PBS built by Flashbots in mev-boost and ways to achieve resilient relays. EPF Week 1 & 2 TLDR: Deep-dive into MEV from the lens of Ethereum PoS security, ways mev-boost helps, ways mev-boost adds centralization and safety & liveness fault risks Started exploration of exported bulk data from Flashbots MEV-Boost Relay. Initial deep-dives into mev-boost repo and relay-monitor repo & design doc