This link in the README is not publicly accessible and should be removed in preparation for open-sourceification:

• https://www.notion.so/flashbots/Relay-Design-Infra-APIs-cf5edd57360140668c6d6b78fd04f312

https://github.com/flashbots/boost-relay/blob/ce2c361eb4601ea0ea59b96c83599a6799fd7932/README.md?plain=1#L11

I'm prompted with a sign-in page:

Then:

I want this project to be called mev-boost-relay, and the main binary to also be mev-boost-relay.

Any thoughts?

The simplest way would be to grab the full HTML from JavaScript and to apply the diff.

Context: https://collective.flashbots.net/t/privacy-concerns-with-data-api/568

We'll update the API for getting validators (https://boost-relay.flashbots.net/relay/v1/data/validator_registration?pubkey=) to make it more private, and to allow bulk queries.

Changes:

1. Instead of only providing pubkey for the request, it will also require fee_recipient (and optionally gas_limit). This is to maintain privacy for proposers (you can only query them if you know the fee_recipient).
2. Allow single queries (like currently), as well as bulk queries with POST requests.
3. Return a response only for active proposers (currently the API returns the result if a proposer registered at any time in the past)

Single query:

https://boost-relay.flashbots.net/relay/v1/data/validator_registration
    ?pubkey=<pubkey>
    ?fee_recipient=<feeRecipient>
    [?gas_limit=<gasLimit>]

Bulk query:

[
  {
    "pubkey": "<a_pubkey>",
    "fee_recipient": "<a_fee_recipient>"
  },
  {
    "pubkey": "<b_pubkey>",
    "fee_recipient": "<b_fee_recipient>",
    "gas_limit": "<b_gas_limit>"
  }
]

Response includes a list of found entries:

[
  "<a_pubkey>",
  "<b_pubkey>"
]

Possible extensions (please comment if you have a need for that, could be added now or in the future):

1. return not only the pubkey but also fee_recipient and gas_limit (enable this response format with another query arg?)
2. return not the found entries, but those that are not found (could also be enabled with another query arg).

Please comment with any remaining thoughts. Will start implementation soon 🙏

This are the error messages:

time="2022-09-23T10:30:47Z" level=warning msg="error calling registerValidator on relay" error="HTTP error response: 403 / error code: 1020" method=registerValidator module=service numRegistrations=25 ua=Go-http-client/1.1 url="https://boost-relay.flashbots.net/eth/v1/builder/validators"
time="2022-09-23T10:30:47Z" level=info msg="http: POST /eth/v1/builder/validators 502" duration=0.017662955 method=POST module=service path=/eth/v1/builder/validators status=502
time="2022-09-23T10:30:59Z" level=debug msg="Checking relay status" module=service url="https://boost-relay.flashbots.net/eth/v1/builder/status"
time="2022-09-23T10:30:59Z" level=error msg="failed to retrieve relay status" error="HTTP error response: 403 / error code: 1020" module=service url="https://boost-relay.flashbots.net/eth/v1/builder/status"
time="2022-09-23T10:30:59Z" level=info msg="http: GET /eth/v1/builder/status 503" duration=0.011533301 method=GET module=service path=/eth/v1/builder/status status=503

Attestant / @mcdee has up-to-date types with a lot of tests: https://github.com/attestantio/go-eth2-client/tree/master/spec

Switching to the attestandtio types and deprecate the go-boost-utils types would reduce maintenance for future spec upgrades (e.g. upcoming Capella fork).

Thoughts on restricting /relay/v1/data/bidtraces/builder_blocks_received to past slots?

I think a builder could:

1. Wait as long as it can before submitting a bid
2. Use the data API to grab all of the bids for that slot
3. Submit a bid that just slightly beats the highest bid

This should be a blind auction, right?

Hello,

I am trying to build a custom implementation in Python of a block builder but I am facing an expected behaviour with the endpoint

https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net/relay/v1/builder/blocks

I receive an empty response with status code 200, what does this mean?

New release coming up: mev-boost-relay v0.16.0

Latest alpha release

• Tag: v0.16.0-alpha1
• Docker image: flashbots/mev-boost-relay:0.16.0-alpha1

Notable changes

• Capella upgrades
• #301 (database migration)
• Various refactorings
• more details

Important: this Capella-ready version of the relay requires a custom Prysm fork as CL client (the develop-boost-capella branch of github.com/flashbots/prysm), which includes a new getWithdrawals endpoint the relay needs to verify withdrawals of block builder submissions. This is expected to be a temporary requirement, as there is a new ethereum/beacon-APIs#244 (comment) specified to provide all the required details, and once that is implemented in CL clients we will update the relay accordingly.

See this writeup for more information about the Capella changes across the MEV-Boost ecosystem.

https://github.com/flashbots/boost-relay/blob/main/server/service.go#L122

For now: benchmark only the signature validation

A validator could bypass the timestamp checks and potentially DoS the relay. The problem lies with this check:

https://github.com/flashbots/boost-relay/blob/2137374990edeafcdb18776d1acf40c60f26cefc/services/api/service.go#L450-L454

Actually, there are two ways of exploiting this, both the same root issue:

Timestamps less than startTimestamp

The check above will not throw an error if the time difference (td) is negative. With a new validator that has not previously registered with the relay, it could send a billion+ registrations to the relay and it would update the datastore for all of them.

for t in range(0, now()):
    send(registration_with_timestamp(t))

Timestamps greater than math.MaxInt64

In the check above, it will cast the registration timestamp from uint64 to int64. If the timestamp is greater than math.MaxInt64 the result will be negative. Similarly to the previous method of exploiting this, a validator could send virtually unlimited number of registrations (9,223,372,036,854,775,808+) to the relay and it would accept all of them.

The solution

Check that the time difference (td) isn't negative. But it might not be quite that simple. If the validator uses the current time when constructing the registration, the timestamp could be less than startTimestamp if the time between constructing the registration and its processing is greater than 1 second. Could happen with slower internet speeds. With this in mind, I believe the better solution is to check that the registration is within 10 seconds of the start time in either direction.

Something like:

 td := int64(registration.Message.Timestamp) - startTimestamp 
 if td > 10 { 
 	respondError(http.StatusBadRequest, "timestamp too far in the future") 
 	return 
 } else if td < -10 { 
 	respondError(http.StatusBadRequest, "timestamp too old") 
 	return 
 }

This would be a hotfix for flashbots/mev-boost#245 although the beacon nodes should actually implement this.

Would need to add the exited status here https://github.com/flashbots/boost-relay/blob/main/beaconclient/prod_beacon_client.go#L84

Currently redis is used as source of truth, and validator registrations are only saved to the database, but not read.

Housekeeper should probably periodically write these from DB to Redis.

Hi,

1. I was curious where the censorship is implemented? Is it here or the flashbots rpc?

II think i heard the relay publish was rushed due to censorship concerns?
But at the same time, afaik, the actual centralization and tx blocking occured at the rpc layer here:
https://github.com/chimera-defi/flashbots-rpc-endpoint
code ptr: MicahZoltu/rpc-endpoint@f1f1b23

So does one actually need to spin up the relay? Or is a modified flashbots rpc all thats needed?

Hello, does someone know from where to take that field?

If I propose for slot X should I take the randao of slot X -1?

Start adding tests for the service

The --redis-uri command line option, used by all three relay programs, only supports begin given the hostname and port of the redis server. Given a Redis server with TLS and a password, using the full URL rediss://<user>:<pass>@<host>:<port> as the argument to --redis-uri produces the following (with details e.g. hostname and password edited out):

time="2022-11-19T21:26:12Z" level=fatal msg="Failed to connect to Redis at rediss://<user>:<pass>@<host>:<port>" error="dial tcp: address rediss://<user>:<pass>@<host>:<port>: too many colons in address" service=relay/website

Passing in only the Redis hostname and port, excluding the protocol and credentials, also expectedly fails:

time="2022-11-19T21:23:09Z" level=fatal msg="Failed to connect to Redis at <host>:<port>" error="write: broken pipe" service=relay/website

This happens because the provided URL is passed as the Addr in redis.Options without parsing out the various pieces.

The solution I propose uses redis.ParseURL to populate the options for creating a new client. ParseURL enforces that a protocol be present, so to ensure backwards-compatability, addresses provided without a protocol are prepended with redis:// to maintain the same behavior as before.

Prysm is a consensus client software written in Golang: https://github.com/prysmaticlabs/prysm

We have a private prysm fork here: https://github.com/flashbots/prysm-private/

The relay and the builder will use Prysm to get data from the beacon chain.

There's a couple of tasks and goals inside:

1. Update our local Prysm fork with the recent upstream changes
2. Run a local Sepolia setup (because it syncs very fast, geth in ~10 minutes) with geth + Prysm
3. The relay needs to know the current slot. CL clients send this to the validator with an API call named forkchoiceUpdated (fcU). The goal here is to update Prysm to send every single forkchoiceUpdated event to a redis pubsub channel, so the relay can pick that up.

Document every step along the way in a Notion document. Here's instructions for running geth on Sepolia:

geth \
    --sepolia \
    --http \
    --http.addr "0.0.0.0" \
    --http.api="engine,eth,web3,net,debug" \
    --http.corsdomain "*" \
    --ws \
    --ws.api="engine,eth,web3,net,debug" \
    --override.terminaltotaldifficulty 17000000000000000 \
    --bootnodes "enode://9246d00bc8fd1742e5ad2428b80fc4dc45d786283e05ef6edbd9002cbc335d40998444732fbe921cb88e1d2c73d1b1de53bae6a2237996e9bfe14f871baf7066@18.168.182.86:30303,enode://ec66ddcf1a974950bd4c782789a7e04f8aa7110a72569b6e65fcd51e937e74eed303b1ea734e4d19cfaec9fbff9b6ee65bf31dcb50ba79acce9dd63a6aca61c7@52.14.151.177:30303"

• Apache Parquet: https://parquet.apache.org/docs/file-format/
• Changes would need to be done around here: https://github.com/flashbots/mev-boost-relay/blob/main/cmd/tool/export-data-api-payloads-bids.go#L83-L94

Context:

Currently, the relay/v1/data/bidtraces/proposer_payload_delivered endpoint returns a BidTraceV2 object that does not include a timestamp. This becomes a problem when one tries to analyze the impact of time on block proposals. As discussed in [1] and [2], time impacts proposers' incentives, and correct analysis can help us better understand how the game is played.

I'm currently working on finding the unrealized value (UNREV) in payloads delivered through mev-boost. Since it is not always the case that proposers pick the (latest-delivered -> as only the latest submitted block of each builder matters) most valuable block available in any relay, UNREV emerges.

Although one reason for UNREV can be a proposer being irrational (in the sense that not always aiming to maximize his utility, e.g., because he only wants to work with a specific relay), another reason is the timing/availability of blocks. It is highly possible that a proposer had accepted a block too early, exposing UNREV. For example, in slot 4,849,684, the delivered payload paid 0.06 ETH. One second later, a block offered 465 ETH (0x18ce78328850d8de2f9d4c6f3fbafdd3ae143b97a9860f8b8b78ad5ac7606167).

With the current endpoints (proposer_payload_delivered and builder_blocks_received), one cannot do a complete UNREV analysis for each block as:

• builder_blocks_received only returns a subset of blocks received. If every relay offers their complete block data like Flashbots does, then this issue can be resolved.
• proposer_payload_delivered returns a BidTraceV2 object that does not include a timestamp (unlike BidTraceV2WithTimestamp). One can try to find the same block through builder_blocks_received endpoint and use the timestamp there but I'm not sure if the timestamp of the delivered payload would be the same as the submitted builder block's.

Changes:

1. Introduces BidTraceV3 which inherits from BidTraceV2WithTimestamp and adds an extra_data field as proposed by @metachris .
2. relay/v1/data/bidtraces/proposer_payload_delivered and relay/v1/data/bidtraces/builder_blocks_received endpoints both return a BidTraceV3 now. However, it is open to discussion whether both should return the same timestamp for a given block.

Hello,

I'm opening this issue because of how ProposerPayloadsDelivered data API is implemented. Currently, in the Data API specs of notion this is how the cursor parameter is described:

cursor: a slot cursor, where limit number of entries up until the cursor slot is returned (note only slot or cursor can be used)

So, this means that delivered payloads are returned up until the cursor, meaning that the cursor is the upper limit. Therefore, the returned entries should start at the bottom and go up until the cursor is hit or we reach limit amount of entries. But, in the current implementation the entries start at cursor, and go downwards until limit amount of entries are found.

So, is this a bug in the relay code or a change in the spec? Thank you!

A docstring or README should explain the scripts and available env vars for the scripts in https://github.com/flashbots/mev-boost-relay/tree/main/scripts

Description

I wanted to have your opinion on the following : should we enable dependabot to manage golang dependencies automatically ?

If yes:

• What should be the interval ? Daily or weekly ?
• Who should be assigned as a reviewer for the dependabot PRs ? I'm thinking @metachris and @Ruteri but I don't know who else is working / responsible for the development of this project on Flashbot's side.

Note: I've already created a branch and the configuration locally.

We want to have database migrations.

One consideration is that the base table name is configurable (with env var), and this doesn't seem to be supported by existing migration tooling (i.e. go-migrate).

What's the easiest and best way to add migrations?

• We could just manually add migrations as golang files
• These could be manually applied, without needing to store the migration status in the database itself

The upcoming Capella fork introduces withdrawals to the ExecutionPayload in the block body, which requires changes to various parts of the MEV-Boost infrastructure:

A Capella-compatible release of mev-boost-relay is already out.

See also:

• #305
• flashbots/mev-boost#451

Here's a full documentation our relay/MEV-Boost changes for Capella: https://flashbots.notion.site/MEV-Boost-Capella-Upgrades-00cea01704794f6eb4f792c55b69c441

• all config/consts should be together
• in particular which can be set through env vars
• the config should be printed on startup

We want to do an initial audit before the merge.

I suggest we use the AGPL:

https://www.gnu.org/licenses/agpl-3.0.en.html

If there is no clear and immediate consensus on this, then let's go with the MIT License:

https://opensource.org/licenses/MIT

As it stands now, block validation requires the to field of the payout transaction to be that of the fee recipient.

This is problematic as reorgs still do happen in eth PoS. The payout tx can make its way into the mempool, and into a future block. Even though one would set a max priority of 0 it can still be picked up by clients who've configured their nodes min priority to be zero.

A builder would be especially prone to this if they're seldomly building blocks. That payout tx won't be invalidated until their nonce is bumped (i.e. until they get another block in and perform another payout) so it can sit in the pool for e.g. hours. waiting for a builder with their configured max priority = 0 to pick it up.

This isn't theoretical, I've seen it happen a few times already.

One workaround is to do a 2-step payout. Step 1 - create a tx that funds a contract; step 2 - have this contract address pay the fee recipient with a block number and/or base fee check (to catch re-org).

However, my suggestion is to change the validation rules to remove the to == fee_recipient check, and instead validate that the total payout to the fee recipient is >= bid.value.

See this section of your CLA:

https://github.com/flashbots/mev-boost-relay/blob/main/CONTRIBUTING.md#:~:text=Grant%20of%20Copyright,litigation%20is%20filed.

Grant of Patent License. and Grant of Copyright License

See also: at what level should cancellations be allowed, if at all? #113

📝 Summary

I ran semgrep (static analysis tool) on the relay and it pointed out one thing that I think is a valid issue:

services/api/service.go
  trailofbits.go.anonymous-race-condition.anonymous-race-condition
     Possible race condition due to memory aliasing of variable `registration`
     Details: https://sg.run/BL22

     458┆ for _, registration := range payload {
     459┆ 	if registration.Message == nil {
     460┆ 		respondError(http.StatusBadRequest, "registration without message")
     461┆ 		return
     462┆ 	}
     463┆
     464┆ 	pubkey := registration.Message.Pubkey.PubkeyHex()
     465┆ 	regLog := api.log.WithFields(logrus.Fields{
     466┆ 		"pubkey": pubkey,
     467┆ 	})
        [hid 54 additional lines, adjust with --max-lines-per-finding]

This is a big loop, but this is the important section of the loop:

This is in a go func and we're referencing the aliased variable, it may not be saving the registration that we think it is.

📚 References

• https://semgrep.dev
• https://husni.dev/beware-of-implicit-memory-aliasing-in-go-foor-loop/
• https://github.com/trailofbits/semgrep-rules/blob/main/go/anonymous-race-condition.yml

I believe I've identified a potential SQL injection vulnerability in the Data API (proposer_payload_delivered). The problem is with the block_hash filter. The value provided in the request is directly copied into the filters structure without any checks.

Then an argument map is created.

As long as it's not empty, the value will be in the query string.

And then it's executed.

These two values have been repeatedly requested by the community, and would be useful to have in the BidTrace for various reasons (i.e. that we don't need to pull the number of transactions from the execution payload).

These values should be exposed in the data API too: https://boost-relay.flashbots.net/relay/v1/data/bidtraces/proposer_payload_delivered?slot=4902798

the Submit block function returns http.StatusOK in most cases regardless of what happened in the handler

be good gentlemen and return some actual text and proper http status codes to notify the builder what actually happened

This is in regards to this clause of the CLA agreement that is required to contribute back to mev-boost-relay:

https://github.com/flashbots/mev-boost-relay/blob/main/CONTRIBUTING.md#:~:text=that%20your%20employer%20has%20executed%20a%20separate%20corporate%20cla%20with%20flashbots.

Describe the bug

GetForkSchedule encountered some error on the beacon node, but didn't return an error, just success with 0s as fork schedule epochs!

Seems the error handling is not correctly implemented in:

https://github.com/flashbots/mev-boost-relay/blob/main/beaconclient/util.go#L14

Create new datastore backends for (a) Redis and (b) Postgres, and accompanying Docker compose setup.

See also https://github.com/flashbots/private-tx-bundler/blob/master/server/state.go as reference for how we used Redis in Golang previously.

I think it would be really cool if we showed some type of hash on the relay's website that could be used to verify the relay matches what is found in this repository. For example, the sha256sum of the mev-boost-relay binary. This would only work if the build is reproducible though. Reproducible Builds is a good resource for getting that setup. Thoughts?

Ideally the housekeeper could run as cronjob.

Currently the housekeeper runs as single instance, and syncs a lot of state from database to Redis. It also keeps some state around to not perform the expensive operations multiple times if not necessary.

The expensive operations are mostly

1. writing all validators from the beacon node to redis
2. writing all validator registrations from the database to redis

These are currently a redis command per entry, but could possibly be made batch requests.

Currently we overwrite validator registrations but to create historic metrics (such as "how many blocks on mainnet were validated by validators registered with the relay?") that can also be backfilled, we need to add the history of all known fee_recipients instead of overwriting the entries in the validator registrations table

We will allow builders to cancel previous block submissions. This will work by always using the latest submission of a builder, even if it's less valuable.

Currently it works like this:

• Once a builder submissions is validated and the highest bid for a slot+parent_hash combination, a new getHeader response is generated and saved to Redis, which will be used for the next getHeader responses:

  mev-boost-relay/services/api/service.go

  Lines 957 to 1001 in 016449f

  	// Check if there's already a bid
  	prevBid, err := api.datastore.GetGetHeaderResponse(payload.Message.Slot, payload.Message.ParentHash.String(), payload.Message.ProposerPubkey.String())
  	if err != nil {
  	log.WithError(err).Error("error getting previous bid")
  	api.RespondError(w, http.StatusInternalServerError, err.Error())
  	return
  	}
  	// Only proceed if this bid is higher than previous one
  	isMostProfitableBlock = prevBid == nil || payload.Message.Value.Cmp(&prevBid.Data.Message.Value) == 1
  	if !isMostProfitableBlock {
  	log.Debug("block submission with same or lower value")
  	w.WriteHeader(http.StatusOK)
  	return
  	}
  	// Prepare the response data
  	signedBuilderBid, err := BuilderSubmitBlockRequestToSignedBuilderBid(payload, api.blsSk, api.publicKey, api.opts.EthNetDetails.DomainBuilder)
  	if err != nil {
  	log.WithError(err).Error("could not sign builder bid")
  	api.RespondError(w, http.StatusBadRequest, err.Error())
  	return
  	}
  	getHeaderResponse := types.GetHeaderResponse{
  	Version: VersionBellatrix,
  	Data: signedBuilderBid,
  	}
  	getPayloadResponse := types.GetPayloadResponse{
  	Version: VersionBellatrix,
  	Data: payload.ExecutionPayload,
  	}
  	bidTrace := common.BidTraceV2{
  	BidTrace: *payload.Message,
  	BlockNumber: payload.ExecutionPayload.BlockNumber,
  	NumTx: uint64(len(payload.ExecutionPayload.Transactions)),
  	}
  	err = api.datastore.SaveBid(&bidTrace, &getHeaderResponse, &getPayloadResponse)
  	if err != nil {
  	log.WithError(err).Error("could not save bid and block")
  	api.RespondError(w, http.StatusBadRequest, err.Error())
  	return
  	}

Changes needed:

1. Save the latest bid of every builder
2. On every valid submission, recalculate the current best bid
3. If bid value is different from the last cached getHeader response, then update it

Notes:

• See also #51
• PR: #206

Documentation of an "ambiguous import error" with go mod tidy:

test imports
        github.com/ethereum/go-ethereum imports
        github.com/ethereum/go-ethereum/core/types imports
        github.com/ethereum/go-ethereum/crypto imports
        github.com/btcsuite/btcd/btcec/v2/ecdsa tested by
        github.com/btcsuite/btcd/btcec/v2/ecdsa.test imports
        github.com/btcsuite/btcd/chaincfg/chainhash: ambiguous import: found package github.com/btcsuite/btcd/chaincfg/chainhash in multiple modules:
        github.com/btcsuite/btcd v0.22.0-beta (/Users/metachris/go/pkg/mod/github.com/btcsuite/[email protected]/chaincfg/chainhash)
        github.com/btcsuite/btcd/chaincfg/chainhash v1.0.1 (/Users/metachris/go/pkg/mod/github.com/btcsuite/btcd/chaincfg/[email protected])

See also: [1]

Workaround: Manually import and require the latest github.com/btcsuite/btcd/btcutil (currently v1.1.2), both in go.mod and requiring it in a file (else a subsequent go mod tidy will lead to the error again.

• Announce the plan to open source
• Choose a date right before or right after the merge
• #30
• Clean up the README #72
• Publish the test coverage report
• Make sure that the test coverage is reasonable
• Define the data that a trusted relay must publish
• Prepare the source code for the audit
• Choose the auditors
• Audit the source code
• Fix the findings
• Publish a post on the risks of running an untrusted relay
• Make this repository public
• Celebrate

Using https://ethereum.github.io/beacon-APIs/#/ValidatorRequiredApi/publishBlock

I have cloned the repo and ran the docker-compose. But I'm having some questions

1.- Do I need to run a local PRYSM ?
2.- When I Run go run . housekeeper --network sepolia --db postgres://postgres:postgres@localhost:5432/postgres?sslmode=disable

I'm getting the terminal error : zsh: no matches found: postgres://postgres:postgres@localhost:5432/postgres?sslmode=disable

I don't see what makes this path internal. It appears to be configured the same as the other paths. What's preventing others from using this path? If it's public, anyone could blacklist builders.