# Security Assesment Proposal - Mevboost

As per your request in our previous meeting, I created this document outlining the details of a proposal to match expectations and the value that I can provide in this engagement.

## Details of the engagement

The objectives for this engagement will be to:

1. Security review of mev-boost, go-boost-utils and boost-geth-builder codebase and documentation:
* Automated and manual static analysis of the codebase
* Dynamic testing looking for common vulnerabilities and unique logic test cases based on the expected functionality of the system.
3. Identification of discrepancies from specifications.

### Planning

##### Scope

* https://github.com/flashbots/mev-boost
* cmd/mev-boost
* main.go
* server/
* backend.go
* relay_entry.go
* service.go
* utils.go

* https://github.com/flashbots/go-boost-utils
* bls/
* bls.go
* types/
* builder.go
* common.go
* signing_encoding.go
* signing.go
* utils.go
* https://github.com/flashbots/boost-geth-builder/commit/ed2fe0bbbf7b059abc97caa6c7a1add0d8d7968a
* builder/
* backend.go
* beacon_client.go
* index.go
* service.go
* validator.go
* eth/
* backend.go
* catalyst/
* api.go
* queue.go
* miner/
* miner.go
* worker.go

#### Analysis

The analysis will be based on several criteria:
- Line by line security review of the codebase.
- Outline centralization risks and worst-case scenarios.
- Identify fuzzing and property-based targets.

#### Deliverable

This engagement will be divided in two phases: in the first place a complete security analysis of mev-boost, including the go-boost-utils library will be provided in the form of a written document to Flashbots. For the final phase, another document will be crafted by analyzing the boost geth-block-builder.

The project schedule and scope will remain flexible through the engagement to be able to suit the initial planitification Flashbot’s needs. Additionally, you can expect open communication channels to ensure that the output of the engagement is as useful as possible and to provide follow ups and changes to the final report.

#### Cost breakdown

The analysis cost estimation is based on the number of lines of code to be reviewed, dividing them into “core” functionality of the project, libraries being used by the core functionality or minor complexity code which makes use of the core functionality.

The “core” part of the project is divided by 18 which is the amount of lines per hour that I will be reviewing. As libraries are often reused from sources and the most important thing to cover is how they work in tandem to the core of the source code, an estimate of 300 lines per hour fits better for libraries.

Finally, 8 hours were included for the creation of the written report.

You can find the detail and budget of each phase below:

#### Phase 1: mev-boost/go-boost-utils

566 lines of code, “core” / 18 lines per hour = 32 hs
873 lines of code, libraries / 36 lines per hour = 24 hs
Analysis of documentation, ETHResearch posts and related content / 6 hs
Identification of fuzzing/property-based testing targets / 6 hs - **optional**
Written report 8 hs

#### Phase 2: boost-geth-builder

793 lines of code, “core” / 18 lines per hour = 44 hs
131 lines of code, minor complexity code / 36 lines per hour = 3.5 hs
Identification of fuzzing/property-based testing targets / 6 hs - **optional**
Written report 8 hs

### Questions

These are the different questions I came up with while reviewing the current state of the systems:

* What are the current state of the escrow and relay systems ? Is there an example implementation I can look at ?
* Is https://hackmd.io/@paulhauner/H1XifIQ_t the most updated documentation on how the system should work ?
* Should we keep the [builder_encoding.go](https://github.com/flashbots/go-boost-utils/blob/main/types/builder_encoding.go) file of the go-boost-utils repository out of scope as it is created by the "fastssz" library ?
* How does the infrastructure looks like from the mev-boost side ? Are these instances going to be running behind a WAF or load-balancer ?