As per the README.md, below flag is used to ignore transactions that include mentioned addresses.

--builder.blacklist value : Path to file containing blacklisted addresses, json-encoded list of strings. Builder will ignore transactions that touch mentioned addresses.`

When I checked the code, I see that the Blacklist is only referenced in following functions.
eth/block-validation/api.go:: verifyTransactions
eth/block-validation/api.go:: isBlacklisted
eth/block-validation/api.go:: verifyTraces

All these functions are called from ValidateBuilderSubmissionV2 which in turn is called only when dryRun flag is set.
if b.dryRun {
err = b.validator.ValidateBuilderSubmissionV2 ....

As per my current understanding, the builder exclusively checks for Blacklisted addresses during dryRun mode. If this understanding is accurate, I kindly request that this be explicitly documented for the sake of clarity. Such documentation is essential for users who rely on this feature for regulatory compliance and operational purposes.

I want to know, how can I run my builder

System information

Geth version: 1.10.23-stable
Go version: go1.19.3
OS & Version: Linux
Commit hash : 9ca4d16

This line is causing a memory leak for me. My system has 128gb of memory, but after running the builder for around 10-12 hours the node consumes all my available memory and crashes. Commenting out this line results in the builder only using 2-3GB of memory. The following image is the pprof heap output after running the node for around 30 minutes. As you can see the trie being copied is consuming most of the heap space. I'm not sure why the garbage collector isn't clearing the space properly?

Rationale

I am a maintainer on Kurtosis's eth2-package and we had been using my own custom built image so far as I hadn't seen images being released but this morning I can see an image on hub.docker.com for flashbots/builder but it isn't arm64 compliant (though it might run anyway) and the image is tagged with a sha but isn't tagged latest so Docker doesn't pick it up automatically

Implementation

Tag latest
Use the multiplatform builder

I want run a builder,Do I just need to run a fork prysm and a builder? Does prysm need connect to another el client?

Is there any difference between using them simply as fullnodes?
Can anyone run the builder as a Builder to submit a block？

the current name makes it impossible to import in other projects

module declares its path as: github.com/ethereum/go-ethereum
but was required as: github.com/flashbots/builder

I am a maintainer at Kurtosis(a dev tool) and I am adding support for MEV to our Ethereum packages. The intent is to give people a private testnet of arbitrary size and clients where they can have MEV components. For the sake of this discussion I will be focussed on this package -

https://github.com/kurtosis-tech/geth-lighthouse-mev-package and specifically the demo tag.

Running kurtosis run github.com/kurtosis-tech/geth-lighthouse-mev-package@demo spins up an Ethereum network with a lighthouse validator/beacon client, a builder execution node (I am using my own image at h4ck3rk3y/builder as the project isn't publishing images yet), mev-boost, mev-relay-api, mev-relay-website, mev-relay-housekeeper nodes and mev-flood.

For some reason the Relay API is constantly complaining about blocks being 0 value. Looking at the builder logs and running get_enginePayloadV2 on them I can see that the blocks indeed have value 0 in the JSON output.

The network is configured in a way where the suggested fee recipient & the eth.accounts[0] address is the address mentioned here https://github.com/kurtosis-tech/eth-network-package/blob/main/src/prelaunch_data_generator/genesis_constants/genesis_constants.star#L11-L15. The transactions I am running are increasing the balance of this address. Based on my understanding with block level scoring the block value should be greater than 0 but its stuck at 0 and the mev relay tool discards such blocks.

I have recorded some videos on loom that illustrate this further -

https://www.loom.com/share/c1160e069fef49e0bbc38a39a686a150?sid=2b86a1d8-6585-4a3b-b78c-c7a0c3202dfd
https://www.loom.com/share/8bc3ba0c81b34851abb9d7c2cbf1b9d2?sid=be396f6d-2a38-4e9e-8b24-a421c48d25a3

Does anyone know whats going on? Some help would be appreciated.

I am not sure what the right avenue for this question is. If it isn't this Repo let me know where I should ask. Thank you!

Hello everybody, i am trying to install the builder but receiving an error.

I simply downloaded the zip from main branch and typed make geth, the same error happens when i type make all.

Actual behaviour

$ make geth
env GO111MODULE=on go run build/ci.go install ./cmd/geth
go: downloading github.com/cespare/cp v1.1.1
go: downloading github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v0.3.0
go: downloading golang.org/x/crypto v0.0.0-20220829220503-c86fa9a7ed90
go: extracting github.com/cespare/cp v1.1.1
go: extracting github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v0.3.0
go: downloading github.com/Azure/azure-sdk-for-go/sdk/azcore v0.21.1
go: downloading github.com/Azure/azure-sdk-for-go/sdk/internal v0.8.3
go: extracting github.com/Azure/azure-sdk-for-go/sdk/internal v0.8.3
go: extracting github.com/Azure/azure-sdk-for-go/sdk/azcore v0.21.1
go: extracting golang.org/x/crypto v0.0.0-20220829220503-c86fa9a7ed90
go: finding github.com/cespare/cp v1.1.1
go: finding golang.org/x/crypto v0.0.0-20220829220503-c86fa9a7ed90
go: finding github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v0.3.0
build github.com/Azure/azure-sdk-for-go/sdk/azcore: cannot load github.com/Azure/azure-sdk-for-go/sdk/azcore: no Go source files
make: *** [Makefile:12: geth] Erro 1

obs: I will present myself soon in the forum, i plan to run a builder

Rationale

What are the use-cases?

Useful for devnet testing to have shorter seconds per slot to speed up the development process. ATM there may be a few places in which it is hardcoded.

Implementation

Do you have ideas regarding the implementation of this feature? Yes
Are you willing to implement this feature? Yes

Task Tracking

Issue tracking for the Cancun Fork Upgrade for the builder in https://github.com/flashbots/builder/tree/deneb.

• Rebase deneb branch to latest geth branch for Deneb
• flashbots_validateBuilderSubmissionV3 endpoint for block validation
• Verify blob length, blob validity (proof + commitments match with blob object), matching versioned blob hashes in txs with blob objects in the validation endpoint

Dependencies

In PRs or not implemented yet.

go-builder-client

• Fixing the ssz encoding for blob bundles attestantio/go-builder-client#18
• VersionedSubmitBlockRequest types attestantio/go-builder-client#15

go-boost-utils

• Util functions to convert payload to payload headers flashbots/go-boost-utils#87
  • Will need to replace https://github.com/MariusVanDerWijden/go-ethereum/tree/4844-devnet-6 with latest geth release after the changes are merged

Known Bugs / Issues

• #128

Hi, I am boosik in a41, a korean blockchain infrastructure firm.
I found that the conditional branch of the code is wrong.

to

switch algo {
    case ALGO_GREEDY_BUCKETS:
        builder := newGreedyBucketsBuilder(chData.chain, chData.chainConfig, nil, nil, env, nil, nil)
        result, _, _ = builder.buildBlock([]types.SimulatedBundle{}, nil, txs)
    case ALGO_GREEDY:
        builder := newGreedyBuilder(chData.chain, chData.chainConfig, nil, env, nil, nil)
        result, _, _ = builder.buildBlock([]types.SimulatedBundle{}, nil, txs)
}

If it is right, I will make PR with my forked repository. thank you!

When the TX is in the mempool the coinbase transfer should also be ignored.

It this code

Builder (main branch) attempts to start the relay aggregator even if secondary relay endpoint(s) are not set:

INFO [12-03|19:17:59.193] requesting                               currentSlot=0
INFO [12-03|19:17:59.602] Updated validators                       count=54 slot=0
INFO [12-03|19:17:59.602] requesting                               currentSlot=0
ERROR[12-03|19:17:59.602] could not get validators map from relay, retrying err="Get \"/relay/v1/builder/validators\": unsupported protocol scheme \"\""
ERROR[12-03|19:18:00.603] could not get validators map from relay, retrying err="Get \"/relay/v1/builder/validators\": unsupported protocol scheme \"\""
ERROR[12-03|19:18:01.603] could not get validators map from relay, retrying err="Get \"/relay/v1/builder/validators\": unsupported protocol scheme \"\""
ERROR[12-03|19:18:02.605] could not get validators map from relay  err="Get \"/relay/v1/builder/validators\": unsupported protocol scheme \"\""
ERROR[12-03|19:18:02.605] could not connect to remote relay, continuing anyway err="Get \"/relay/v1/builder/validators\": unsupported protocol scheme \"\""

This happens because strings.Split returns a slice of length 1 with the original string ("") if it can't match the separator (","):

Making the following change fixes the issue:

-  if len(cfg.SecondaryRemoteRelayEndpoints) > 0 { 
+  if cfg.SecondaryRemoteRelayEndpoints[0] != "" {

I run a builder and prysm on goerli .
builder version: branch: capella-1.11.4
prysm version: flashbots/prysm branch:develop-boost commit 31558723

builder run cmd:
./geth --goerli --builder --verbosity 3 --nat extip:xxx.xxx.xxx.xxx --port 32305 --discovery.port 32305 --datadir /MS-4Tx2-ZFS-RAID0/flashbots-goerli/execution/geth --authrpc.jwtsecret /MS-4Tx2-ZFS-RAID0/flashbots-goerli/jwt.hex --authrpc.port=18551 --cache 2048 --maxpeers 250 --builder.beacon_endpoint=http://127.0.0.1:13500 --builder.listen_addr 0.0.0.0:28545 --miner.extradata xxxxx --builder.remote_relay_endpoint=https://0xafa4c6985aa049fb79dd37010438cfebeb0f2bd42b115b89dd678dab0670c1de38da0c4e9138c9290a398ecd9a0b3110@builder-relay-goerli.flashbots.net

flashbots/prysm run cmd:
bazel run //cmd/beacon-chain:beacon-chain --config=release -- --datadir=/MS-4Tx2-ZFS-RAID0/flashbots-goerli/consensus/prysm-from-checkpoint --execution-endpoint=http://127.0.0.1:18551 --prater --jwt-secret=/MS-4Tx2-ZFS-RAID0/flashbots-goerli/jwt.hex --suggested-fee-recipient=0xbc4c946b8dcF1Cb2a6D7d7a91B69835321EDc085 --rpc-port 14000 --grpc-gateway-port 13500 --p2p-tcp-port 13001 --p2p-udp-port 12001 --min-sync-peers 7 --http-mev-relay=https://0xafa4c6985aa049fb79dd37010438cfebeb0f2bd42b115b89dd678dab0670c1de38da0c4e9138c9290a398ecd9a0b3110@builder-relay-goerli.flashbots.net

get some error on prysm log

builder log:

what is meaning about:
ERROR[03-20|01:49:12.190] could not submit capella block err="error sending http request to relay https://0xafa4c6985aa049fb79dd37010438cfebeb0f2bd42b115b89dd678dab0670c1de38da0c4e9138c9290a398ecd9a0b3110@builder-relay-goerli.flashbots.net. err: HTTP error response: 400 / {"code":400,"message":"submission for past slot"}\n"

ERROR[03-20|01:49:58.955] could not submit capella block err="error sending http request to relay https://0xafa4c6985aa049fb79dd37010438cfebeb0f2bd42b115b89dd678dab0670c1de38da0c4e9138c9290a398ecd9a0b3110@builder-relay-goerli.flashbots.net. err: HTTP error response: 400 / {"code":400,"message":"invalid signature"}\n" #commitedBundles=0

WARN [03-20|01:50:12.938] Served builder_payloadAttributes conn=127.0.0.1:54218 reqid=563 duration="151.915µs" err="validator not found"

Rationale

Currently you can specify validation_blacklist which applies to all relays. This means that you can either configure your builder to either mostly work with censorious relays or completely work with censorious relays.

When you do not specify a validation_blacklist your builder may submit bad requests to censorious relays. It will continue to submit bad requests to the censorious relay until the transaction in question is removed from the mem pool.

When you do specify a validation_blacklist your builder will filter requests to open relays and will likely never be selected by an open relay.

Implementation

It's not realistic to run simulations for every relay. A simple approach could be to filter transactions just before submission to the relay. This will mean that submissions to open relays will be more profitable to validators and block builders. Whilst still serving up blocks to validators that are connected to censorious relays.

Rationale

To allow anyone to easily make changes to the builder, measure their impact, and ensure that they are safe.

Implementation

• Provide standardized tools and data (sample bundles)for testing
• Provide a framework for testing (e.g. performance metrics)
• Create guide to deploying and testing the builder

One way to approach this is to create a mass conflicting bundles at random and test merging against those. But thinking it through we might want a standardized dataset that allows for more precise measurement of performance (e.g. variance in the randomized generation of bundles doesn't affect performance)

Rationale

The feature would be a great tool for the searchers without access to huge upfront capital. It would help bring the leverage the big players have to the people.

Implementation

Looking at currently existing interfaces (ex http://flashbuilder.org/), the call is similar in spirit to bundles, and includes an additional parameter loanTo, that the builder loans its funds to for the duration of the bundle.
Could be implemented as a new call and bundle type, or it could extend existing structure with an optional parameter.

Is it still required to run a custom Prysm fork or the main implementation works as well ?

System information

Commit hash : dd5640df36e64d47de5c48146c0bc27bfd8fead7

As part of testing 4844 seeing invalid state roots

Oct-24 11:34:42.049[]                 info: Synced - slot: 7973 - head: 0x1462…e36c - exec-block: valid(6868 0xa70a…) - finalized: 0x3489…c880:247 - peers: 44
Oct-24 11:34:49.348[network]         error: Error receiving block slot=7974, peer=16Uiu2HAmGFWMG35HHPjzva2wgyHuG13wDFSVcnj63mn8yCkWmXAY - root=0xf5ccfb4268ba8707e1a5f6b6dae7725a7ae241932b7fd20ea4b1ccd7df02865c, expectedRoot=0x150fb38df5eb869cdf88a236c84622e1dd7bbfd53e3c384016bb8d47817c1409
Error: BLOCK_ERROR_INVALID_STATE_ROOT
    at verifyBlocksStateTransitionOnly (file:///usr/app/packages/beacon-node/src/chain/blocks/verifyBlocksStateTransitionOnly.ts:66:13)
    at BeaconChain.verifyBlocksInEpoch (file:///usr/app/packages/beacon-node/src/chain/blocks/verifyBlock.ts:95:7)
    at BeaconChain.processBlocks (file:///usr/app/packages/beacon-node/src/chain/blocks/index.ts:75:68)
    at JobItemQueue.runJob (file:///usr/app/packages/beacon-node/src/util/queue/itemQueue.ts:101:22)
Oct-24 11:34:54.001[]                 info: Synced - slot: 7974 - head: (slot -1) 0x1462…e36c - exec-block: valid(6868 0xa70a…) - finalized: 0x3489…c880:247 - peers: 44
Oct-24 11:35:06.001[]                 info: Synced - slot: 7975 - head: 0xbbfa…6981 - exec-block: valid(6869 0xe166…) - finalized: 0x3489…c880:247 - peers: 44
Oct-24 11:35:18.001[]                 info: Synced - slot: 7976 - head: 0xf49a…64c1 - exec-block: valid(6870 0xd30a…) - finalized: 0x3489…c880:247 - peers: 44

This is during capella, before the deneb fork.

AddMevBundle surely needs to lock for atomicity of adding to the bundle pool (pool.mevBundles), but as far as I can tell it doesn't interact with the rest of the txpool so should be okay to use something like pool.bundleMu.Lock()? Happy to implement if so 😃

Built Flashbots builder from Tag v1.11.5-0.2.1. Built Prysm from Tag v4.0.0-boost0.2.0 .
When running, Geth outputs error: err="the method builder_payloadAttributes does not exist/is not available".
Prysm outputs error: ERROR blockchain: Could not notify builder to build block error=method not found

Getting this error while trying to build dockerfile

` => ERROR [stage-1 2/3] RUN apk add --no-cache ca-certificates 2.9s

[stage-1 2/3] RUN apk add --no-cache ca-certificates:
#7 0.352 fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/aarch64/APKINDEX.tar.gz
#7 1.065 281473347669064:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1919:
#7 1.065 WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.16/main: Permission denied
#7 1.065 fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/aarch64/APKINDEX.tar.gz
#7 2.704 281473347669064:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1919:
#7 2.705 WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.16/community: Permission denied
#7 2.705 ERROR: unable to select packages:
#7 2.707 ca-certificates (no such package):
#7 2.707 required by: world[ca-certificates]

executor failed running [/bin/sh -c apk add --no-cache ca-certificates]: exit code: 1`

Rationale

Why should this feature exist?

• when the builder doesn't collect any fee it is very enificient to create a payout TX on every block.
  some validators use a contract which consumes 70-100k gas so without the payout TX the total block value will be higher.

What are the use-cases?

• operating a builder that doesn't collect block fees.

Implementation

Do you have ideas regarding the implementation of this feature?

• yes
  the simulation checks -
  • if the coinbase address is the same as the validator's address
  • the coinbase balance difference is the same as the bid value

Are you willing to implement this feature?

• yes

Deneb/Cancun hardfork is coming, I want to know if I need to upgrade flashbots builder? Which version is work for Deneb/Cancun hardfork?
thanks

System information

Builder version: latest
CL client & version: e.g. lighthouse/nimbus/[email protected]
OS & Version: Windows/Linux/OSX
Commit hash : (if develop)

Expected behaviour

An error field which contains the error message shall be returned along with the gasUsed field so that RPC callers knows that the gas estimation fails and the returned gasUsed value shall not be used for gas estimation.

Actual behaviour

No error field is returned and the returned gasUsed value is only the gas usage until the point that the transaction failed and thus it is not a valid gas estimation.

Steps to reproduce the behaviour

Send the following RPC request to the builder node and note that you may need to change the blockNumber and stateBlockNumber field to a more recent main block number.
{"method":"eth_estimateGasBundle","params":[{"txs":[{"from":"0x682CD3E420f2bFAcc633D289eF6F42d8543A6Ee0","to":"0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9","data":"0x00a718a9000000000000000000000000514910771af9ca656af840dff83e8264ecf986ca000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48000000000000000000000000c557f40a556a0e7eca4c7a81c49bb2f21d3b4cbc000000000000000000000000000000000000000000000000000000000d14d8b00000000000000000000000000000000000000000000000000000000000000000","gasLimit":2000000,"value":"0x0"}],"blockNumber":"0x10cd21f","stateBlockNumber":"0x10cd21f"}],"id":1,"jsonrpc":"2.0"}

If you send the same transaction to the go-ethereum node to the eth_esitmateGas endpoint:
{"method":"eth_estimateGas","params":[{"from":"0x682CD3E420f2bFAcc633D289eF6F42d8543A6Ee0","to":"0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9","data":"0x00a718a9000000000000000000000000514910771af9ca656af840dff83e8264ecf986ca000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48000000000000000000000000c557f40a556a0e7eca4c7a81c49bb2f21d3b4cbc000000000000000000000000000000000000000000000000000000000d14d8b00000000000000000000000000000000000000000000000000000000000000000","gasLimit":2000000,"value":"0x0"}],"id":1,"jsonrpc":"2.0"} it will shows that the transaction is invalid.

Backtrace

[backtrace]

When submitting logs: please submit them as text and not screenshots.

A block with cancelled bundles could have less profit.

Rationale

Currently we are copying the state every time we are about to apply a bundle, as multi-tx bundles can't be handled with a revert to snapshort.
It should be beneficial to have a special case for single-tx bundles that avoids the state copy.

I'm a newbie regarding the blockchain, so I may be wrong all along, but here it is.

While working on my project I found some transactions that may look like sandwich attacks, even though they were validated by the Flashbots builder. And I'm certain that Flashbots won't allow sandwich attacks. Could you explain to me what's going on?

• On block 16318855, the transaction at position 0 from 0xb58...f7b is swapping WETH to RPL on UniswapV3 (0xe42...b45).
• Then another wallet performs a few arbitrage swaps at position 1, including a WETH-RPL swap on the same UniswapV3 pair (0xe42...b45)
• And at position 2, the first wallet swaps back RPL to WETH on that very same UniswapV3 pair, making an 0.5 eth profit.

The same kind of scenario happens in the same block at positions 5, 6, and 7.

Hi everyone! I'm currently actively investigating block builder. And I'm a little bit confused about bundle and tx ordering algo in block.

According to implementation and blocks produced by flashbot builders in mainnet, block builder sorts txs and bundles by effective gas and mev gas price and adds in to the block. Both for ALGO_MEV_GETH and ALGO_GREEDY algo type (I know about some differences between these algo types, but they both in general sort txs and bundles). Finally, txs and bundles are sorted in block by effective gas price.

But in the docs you have these:

• Instead of ranking and including bundles based off of effective gas price the algorithm now optimizes for overall block profit.
• Top-of-block execution is no longer a guarantee.
• Bundle ordering by effective gas price is no longer a guarantee.

I see a contradiction here here. Why docs tells that Top-of-block execution and Bundle ordering are is no longer a guarantee? I will glad to get answer to my question, thanks guys!

As per the documentation

• We reserve gas for the proposer payment using proposerTxPrepare and commit proposer payment after txs are added with
  proposerTxCommit. We do it in a way so all fees received by the block builder are sent to the fee recipient.

If the builder writes a block and that block has a transaction that sends funds to the Builder coin base, the whole transaction amount is considered as a block profit.

System information

Geth version: 1.11.5-stable-03ee71cf
OS & Version: Windows/Linux/OSX
Commit hash : (if develop)

Expected behaviour

When we run ./local-builder/devent/devent for test, geth should be work normally

Actual behaviour

geth is terminate with followed log

• Fatal: Invalid algo in --miner.algotype:

-> use builder.algotype instead of miner.,algotype in ./local-builder/devent/devent script
-> or
-> modified from BuilderAlgoTypeFlag.Name to MinerAlgoTypeFlag.Name in ./cmd/utils/flags.go 1924 line,
-> I think when MinerAlgoTypeFlag is checked, to use MinerAlgoTypeFlag.Name is clear not BulderAlgoTypeFlag.

Steps to reproduce the behaviour

git clone this builder project
cd builder
make
./local-builder/devent/devent run

Backtrace

./local-builder/devnet/devnet run
Creating genesis block
INFO [10-16|14:41:11.603] Maximum peer count                       ETH=50 LES=0 total=50
INFO [10-16|14:41:11.612] Set global gas cap                       cap=50,000,000
INFO [10-16|14:41:11.613] Using leveldb as the backing database
INFO [10-16|14:41:11.614] Allocated cache and file handles         database=/Users/kevin/work/Github/references/mev/builder/local-builder/devnet/data/geth/chaindata cache=16.00MiB handles=16
INFO [10-16|14:41:11.639] Using LevelDB as the backing database
INFO [10-16|14:41:11.675] Opened ancient database                  database=/Users/kevin/work/Github/references/mev/builder/local-builder/devnet/data/geth/chaindata/ancient/chain readonly=false
INFO [10-16|14:41:11.676] Writing custom genesis block
INFO [10-16|14:41:11.677] Persisted trie from memory database      nodes=6 size=850.00B time="93.458µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [10-16|14:41:11.690] Successfully wrote genesis state         database=chaindata hash=961b11..1d70d0
INFO [10-16|14:41:11.691] Using leveldb as the backing database
INFO [10-16|14:41:11.691] Allocated cache and file handles         database=/Users/kevin/work/Github/references/mev/builder/local-builder/devnet/data/geth/lightchaindata cache=16.00MiB handles=16
INFO [10-16|14:41:11.710] Using LevelDB as the backing database
INFO [10-16|14:41:11.746] Opened ancient database                  database=/Users/kevin/work/Github/references/mev/builder/local-builder/devnet/data/geth/lightchaindata/ancient/chain readonly=false
INFO [10-16|14:41:11.746] Writing custom genesis block
INFO [10-16|14:41:11.747] Persisted trie from memory database      nodes=6 size=850.00B time="109.792µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [10-16|14:41:11.751] Successfully wrote genesis state         database=lightchaindata hash=961b11..1d70d0
INFO [10-16|14:41:11.787] Enabling metrics collection
INFO [10-16|14:41:11.787] Enabling stand-alone metrics HTTP endpoint address=127.0.0.1:6060
INFO [10-16|14:41:11.787] Starting metrics server                  addr=http://127.0.0.1:6060/debug/metrics
INFO [10-16|14:41:11.789] Maximum peer count                       ETH=50 LES=0 total=50
Fatal: Invalid algo in --miner.algotype:

When submitting logs: please submit them as text and not screenshots.

Hi,
The builder assemble the blocks and sends them to the remote relay, while I do not see errors when sending, I see messages (submitted capella block and submitted block).
But when I go to the relay link to check if the block was included in the relay, it is not there.
Links to check blocks:
https://0xac6e77dfe25ecd6110b8e780608cce0dab71fdd5ebea22a16c0205200f2f8e2e3ad3b71d3499c54ad14d6c21b41a37ae@boost-relay.flashbots.net/relay/v1/data/bidtraces/builder_blocks_received?slot=SLOT_NUMBER
or
https://0xa1559ace749633b997cb3fdacffb890aeebdb0f5a3b6aaa7eeeaf1a38af0a8fe88b9e4b1f61f236d2e64d95733327a62@relay.ultrasound.money/relay/v1/data/bidtraces/builder_blocks_received?slot=SLOT_NUMBER

Can someone explain to me why this can happen, or what I don't understand?

Hello guys! I'm investigating your projects a couple days and I have some problems/questions.

1. Why when I call eth_sendBundle rpc call of my flashbots block builder I'm getting empty response? Or, if to be more precise, I'm getting an empty BundleHash. This is how response looks like:
   {BundleHash:}
   But! When I send exactly the same request to the public https://boost-relay-goerli.flashbots.net I'm getting the BundleHash
2. I have some trouble with documentation of builder in general. I can't find the list of the supported rpc call (I have found this, but i'm not sure that this is about block builder).
3. And the main point that I don't understand -- what should I do for block builder to send a block to relay/relays? Maybe even empty block or block with one tx. Now I just want to test it, make sure that my block builder is working and look how it works.

This is how I run my block builder:
./build/bin/geth --goerli --builder --builder.remote_relay_endpoint https://boost-relay-goerli.flashbots.net --log.debug
I'm also add BUILDER_TX_SIGNING_KEY env var

I will glad if somebody will be able to help me and explain how it works:)
Also if you need more info please let me know

readme indicates you need to use a prysm fork.

You will need to run a modified beacon node that sends a custom rpc call to trigger block building. You can use the modified prysm fork for this.

the linked fork is archived. I assume this stated requirement is no longer true

I would like some clarification on the above error. I am running a custom devnet where I would like to set up this boost-builder.
When I run it however, I get the above error.

Thank you very much in advance.

System information

Geth version: flashbots/builder:sha-ffeb673
CL client & version: e.g. lighthouse:latest
OS & Version: OSX, M1

Expected behaviour

The builder should keep running and not crash

Actual behaviour

I am starting a network with MEV components using Kurtosis but on my MAC the container just crashes when epoch 2 / slot 64 is reached. On this epoch validators get registered on the mev relay website. I have run it twice locally and run into this both times

# gyanendramishra @ Gyanendras-Laptop in ~/work/eth2-package on git:gyani/use-flashbots x [11:51:30]
$ docker ps -a | grep builder
912a5e57eb9d   flashbots/builder:sha-ffeb673                   "sh -c 'geth init --…"   5 minutes ago        Exited (137) 58 seconds ago                                                                                                                                   el-2-geth-lighthouse--79141e468a6444479b49e2e8ef593b4c

Steps to reproduce the behaviour

1. Get an M1/M2 machine
2. Install Kurtosis / Docker
3. Write the following into args.json (below)
4. Run kurtosis run github.com/kurtosis-tech/eth2-package@gyani/use-flashbots "$(cat args.json)"

{
  "network_params": {
    "capella_fork_epoch": 1,
    "seconds_per_slot": 3
  },
  "mev_type": "full",
  "mev_params": {
    "mev_flood_seconds_per_bundle": 7
  }
}

Backtrace

Here are the logs attached
builder.log

Hi, it appears the Flashbots Sepolia builder submission endpoint is returning 500 errors for eth_callBundle and eth_sendBundle. This was originally reported October 8 in the Discord by another user and re-reported in November by myself. Clearly, this hasn't been fixed. While I understand Sepolia is low-priority, projects are currently unable to proactively move to the supported testnet (as Goerli will be sunset in a few months).

As this is the most relevant project, I'm submitting this issue here so there's visibility.