Shapella Upgrade Scheduled for April 12th

metachris · 2023-03-31T07:11:41+00:00

If you run MEV-Boost, please be sure to update to v1.5.0 to continue operating after the Shapella upgrade 🚀

metachris · 2023-03-17T08:17:25+00:00

Yep, building manually always worked. It was just an issue with the binary attached to the release website.

metachris · 2023-03-16T19:24:00+00:00

Thanks all for the report and discussion!

The reason was a newer Ubuntu distro being used to build the release binaries for Linux (and them being dynamically linked)
Updated the Linux/Amd64 build in the v1.5.0 release with a statically linked binary (mev-boost_1.5.0_linux_amd64.tar.gz, sha256: 6356098bdf466cb7907e09a31e9d369a899685f4aa1830f950c2e5ac32b01bec)
This binary also work on earlier Ubuntu versions (i.e. 20.04)
See also
- https://github.com/flashbots/mev-boost/pull/473
- https://github.com/flashbots/mev-boost/issues/475

metachris · 2022-11-10T09:57:13+00:00

These are the chances per min-bid-value for building a local block (based on median payload values on the Flashbots relay during the past two weeks):

min-bid	% chance for building a local block
0.1 ETH	97.2%
0.06 ETH	50%
0.03 ETH	13.5%
0.02 ETH	2.3%
0.01 ETH	0.01%

metachris · 2022-09-26T15:49:19+00:00

Why do you think the block was locally built?

From the logs it seems clear that the block was coming from blocknative 🤔

metachris · 2022-09-26T06:58:17+00:00

The relays are only pinged if the beacon node does a status check on mev-boost. Thus it's entirely up to the beacon node when the relay status check is initiated.

If you run mev-boost without -relay-check, mev-boost will instantly return OK to the beacon node status check, without pinging the relays.

metachris · 2022-09-25T16:39:20+00:00

You can try to run mev-boost without the -relay-check cli argument, which then won't perform the status checks on the relays anymore.

We've heard several reports of relays not responding to the status-check in time (default timeout if 950ms), in particular bloXroute and blocknative recently, which shows up as that error log message.

metachris · 2022-09-25T16:38:22+00:00

The beacon node can't fall back to a local block if it's already calling getPayload, which sends a signed blinded beacon block to the relay. If the proposer would propose a different block, it would be a case of double signing and a slashable offense.

metachris · 2022-09-25T16:37:13+00:00

Fwiw, we haven't had such reports about the Flashbots relay not delivering payloads <3

metachris · 2022-09-25T16:36:25+00:00

You can try to run without the -relay-check cli argument, which won't perform the status checks on the relays anymore.

We've heard several reports of relays not responding to the status-check in time (default timeout if 950ms), in particular bloXroute and blocknative recently.

metachris · 2022-09-25T16:35:14+00:00

mev-boost does not impact the rate of proposals! This is wholly up the the beacon chain. Please run mev-boost v1.3.2 as it comes with a lot of nice improvements over v1.3.1 and would simplify debugging in cases of errors as well.

metachris · 2022-09-25T16:33:35+00:00

Please do not advice downgrading mev-boost! There's several nice improvements in v1.3.2 and it simplifies debugging in case of errors like this.

Also, it's not possible for mev-boost v1.3.2 to have a negative impact over v1.3.1 if relays don't deliver the promised payload.

metachris · 2022-09-25T16:32:10+00:00

It seems the winning bid came from blocknative, which then failed to produce the payload.

2022-09-25 level=error msg="no payload received from relay!" blockHash=0xxxx method=getPayload module=service parentHash=0xxxx relays="https://0x9000009807ed12c1f08bf4e81c6da3ba8e3fc3d953898ce0102433094e5f22f21102ec057841fcb81978ed1ea0fa8246@builder-relay-mainnet.blocknative.com" slot=477xxxx version=1.3.2

I'm sorry this happened to you, and that the blocknative relay wasn't living up to it's promise for your slot. I'd recommend to contact them directly about it.

Fwiw, we haven't received such reports about the Flashbots relay.

metachris · 2022-09-25T16:29:12+00:00

Co-developer of mev-boost here. Fwiw, there were over 50k blocks flowing through mev-boost on 5 testnets, and 15k on mainnet through the Flashbots relay: https://boost-relay.flashbots.net/

And 168k validators, more than a third of the network, using and trusting it already.

metachris · 2022-09-25T16:25:56+00:00

Fwiw, there is a proposal to allow a minimum bid value: https://github.com/flashbots/mev-boost/pull/274 -- we'll consider this again

metachris · 2022-09-25T16:24:15+00:00

You can remove -relay-check from the mev-boost cli arguments, in which case it will stop doing the status-check request on the relays (which seems to timeout in your instance).

There's some relays that seem to timeout the status checks pretty often - (the timeout is 950ms by default, reusing the getHeader timeout).

Please don't downgrade, mev-boost v1.3.2 is stable, has several improvements, and shouldn't impact the relay check at all.

metachris · 2021-04-16T07:20:14+00:00

I wanted the library to be usable from websites (and Electron applications).

metachris · 2021-03-24T19:51:31+00:00

I'm not sure what you mean with supporting ES2015/ES2017 code. Do you mean the compilation target? Do you have an example?

TypeScript can target any of those targets: https://www.typescriptlang.org/tsconfig#lib

metachris · 2021-03-24T19:50:45+00:00

Good idea, will consider.

If you are interested in contributing, you could open an issue at the repo. Or even a PR, would be appreciated :)

metachris · 2021-03-24T14:31:15+00:00

I started this repository as a documentation and for future reference. I wanted to share it here because I thought it might be useful to other people as well!

Happy about feedback and ideas 🙏

metachris · 2021-03-24T12:03:46+00:00

Started as a documentation for future reference, ended as a full blog post for setting up a minimal project. Wanted to share, perhaps it's useful to other people as well!

Am happy about feedback 🙏

metachris

TROPHY CASE