execution-specs VS mev-boost

EIP6780 (SELFDESTRUCT only in same transaction) is planned for the Dencun upgrade. (See Cancun included EIPs https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)

I followed the link which took me to https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md and then I started getting a little lost on the details.

@ TimBeiko: teams felt comfortable moving forward with Goerli, which we agreed to fork on March 14, 10:25pm UTC. I've opened a PR to update the specs accordingly: https://github.com/ethereum/execution-specs/pull/724

Mar 01 08:37:30 computername geth[402568]: INFO [03-01|08:37:30.496] - Homestead: 1150000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/homestead.md)

EIP-4844 is slated for the Cancun Fork.

If you know Python you can read around the execution layer specs, namely for the EVM. Technically the "source of truth" for execution layer specs is still the yellow paper and EIPs but there's ongoing effort to turn it all into testable and executable specs. Otherwise this paper specifically goes in depth on the data structures used throughout the execution layer

You can see them here https://github.com/ethereum/execution-specs/pull/633/files

EIP-4895 for staking withdrawals is the main proposal members cared about, and it was upgraded from "EIPs Considered for Inclusion" to "Included EIPs" in the latest Shanghai specs. The other 3 are just minor changes.

The following EIPs have now been upgraded from "EIPs Considered for Inclusion" to "Included EIPs" in the latest Shanghai specs.

FYI, this is fixed now: https://github.com/flashbots/mev-boost/issues/541

mev-boost v1.6 was released yesterday - it's often the part of the validator stack that gets neglected when it comes to updates.

For the setup, did you look at https://boost.flashbots.net/ ? Pretty straightforward, and examples of configuration for validator nodes are provided for each soft (prysm, lighthouse, nimbus...). I remember using that (and potentially doing one or two little adjustments). For the explanation, flashbot doc is nice, you can start here: https://docs.flashbots.net/new-to-mev

Are you also using MEV? Because a few people seem to have this same issue. Maybe it is a MEV-Geth thing. If so could you post your MEV logs?

Ahh I see yep, on the builder side not the validator side. Validators using https://github.com/flashbots/mev-boost but whichever builder gets chosen may likely be using those (especially if flashbots has the highest bid).

Personally I think the risk benefit is better to have mevboost activated. https://github.com/flashbots/mev-boost/issues/518

The same thing happened to me, I opened an issue in prysm and in mevboost, we are not the only ones with bad luck, https://github.com/prysmaticlabs/prysm/issues/12434 https://github.com/flashbots/mev-boost/issues/516 try adding the --build-block-parallel flag I also removed 2 relays, flashboot and brute. Hopefully next time we'll have better luck. sorry for my bad english

MEV-Boost is an implementation of proposer-builder separation (PBS) built by Flashbots for proof of stake Ethereum. Validators running MEV-Boost maximize their staking reward by selling blockspace to an open market of builders.