Merged
Conversation
This was referenced Jan 20, 2025
ZanCorDX
pushed a commit
to flashbots/rbuilder
that referenced
this pull request
Jan 21, 2025
… DX (#364) ## 📝 Summary While getting flashbots/builder-playground#37 working I ran into a couple DX gotchas with the current `config-playground.toml` file. ## 💡 Motivation and Context - The `parallel` algoirthm was pegging all my CPUs at 100%. Also figured just running `mgp-ordering` is enough. - Having a random coinbase made it harder to test block building since we only build profitable blocks. IIRC we now have a setting to build always, but I still think it's cleaner to use the prefunded accounts from the playground. - Having debug logs helped a ton tracking down pectra issues, so I expect it's useful any time anyone is using the playground for development. --- ## ✅ I have completed the following steps: * [ ] Run `make lint` * [ ] Run `make test` * [ ] Added tests (if applicable)
not4x217
pushed a commit
to not4x217/builder-playground
that referenced
this pull request
Feb 25, 2025
* chore(pectra): Use pectra devnet-4 compatbile geth and prysm * chore: log genesis info on startup to help w/ debugging * chore(pectra): use the current pectra mev-boost-relay code as well * chore(devnet5): https://github.com/s1na/go-ethereum/commits/prague-devnet-5/ * chore(devnet-5): https://github.com/prysmaticlabs/prysm/commits/devnet5/ * chore(devnet5): https://github.com/flashbots/mev-boost-relay/commits/electra/ * chore(devnet-5): Use develop@0b16c79 for Prysm * fix(reth): Use new engine flags for reth v1.1.6+ * fix(relay-mock-validation): Use a rnadom port form OS instead of picking our own * chore(devnet-5): Use flashbots/mev-boost-relay#671 * chore(devnet-6): Updates for devnet-6. * fixup: minor cleanup * fixup: go mod tidy * basic config to use assertoor to generate a bunch of deposits on-chain * fixup(assertoor): genesis.json had zero deposit contract address. * fixup(assertoor): Use one of the other prefunded accounts * chore(deps): Update to latest geth, prysm, and mev-boost-relay * fixup: reth 1.2.0! * fixup(vc): Use --prefer-builder-proposals to always use builder block if available. * chore(lighthouse): use v7.0.0-beta.0, emit warning on macOS. * chore(geth): Use 1.15.1 since its out.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a replacement for #32 that actually works end-to-end!
The only remaining oddity is that on macOS the
lighthouse-v7.0.0-beta.0binary (which is always x86_64, they dropped their -portable builds) behaves odd: rbuilder never seems to "see" the payload events even though curling the endpoint seems to work as expected. As a work-around for now, I detect this scenario and emit a warning suggesting using--use-bin-pathinstead.Anyways, otherwise it "just works":
Start
rbuilder, then send a juicy tx that pays the coinbase.And sure enough, we have a pectra block in the builder-playground output!
If you want to go further, I've also included a config file for
assertoorwhich can be used to spam the chain with deposit requests:This tests the new
execution_requestsfield in the pectra fork. Tooling on this field is a little mixed, currently the easiest way to see if a block contained requests is to usecast blockThe "empty" hash for requests is
0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855so the fact that they differ implies that requests we included.