feat(provider): Add eth_sendBundle support to provider

[cakevm]

This adds a new method + builder to the provider:

• send_bundle: send a MEV bundle

This feature also introduces custom http headers for a http request. For that the extension feature is used and a custom type HttpHeaderExtension is introduces. A transport can choose to support it e.g. transport-http.

For flexibility FLASHBOTS_SIGNATURE_HEADER and sign_flashbots_payload are exported, if someone prefers to build the request manually.

Usage:

// without signing
provider.send_bundle(bundle).await;

// with X-Flashbots-Signature
let signer = PrivateKeySigner::random();
provider.send_bundle(bundle).with_auth(signer).await;

Find here a full example how it works without this feature: https://github.com/cakevm/alloy-flashbots-client/blob/main/src/main.rs

[gakonst]

Should this be in a separate repo and under an extension trait? alloy-rs/mev?

[cakevm]

I think this question goes in the direction of the maintainers, but I would suggest keeping it here in alloy. Implementing endpoints in the provider for rpc-types-mev is, so far, not significantly different from the other provider implementations (aside from the Flashbots authentication). Since it’s feature-gated, keeping everything in one place could help to keep the maintenance overhead reasonable. This could change if more edge cases arise or the implementation becomes too large.

[mattsse]

this makes sense, imo having a way to easily install additional headers is very useful so we should add this now that we have the extension
smol nits and a question

[mattsse]

I think this makes sense as a workaround because this is a common use case,

can we add helper fn for retrieving the HttpHeaderExtension

maybe even as mut so that the user doesnt have to deal with the extension type directly

[cakevm]

Yes this would be a great addition in the future

[mattsse]

this is public but can panic, this feels wrong, why do we need this?

[cakevm]

This is a valid point, better be safe then sorry. I was initially inspired by the map_params fn above and just copied it. I guess it was intended as unreachable!, but I introduces now an error type here. I think it is reasonable.

This here should be refactored as well, but I like to keep the PR small. But I am ok to pick this up and make the use of RequestAlreadySentError here as well:

pub fn map_params<NewParams: RpcSend>(
    self,
    map: impl Fn(Params) -> NewParams,
) -> RpcCall<NewParams, Resp, Output, Map> {
    let CallState::Prepared { request, connection } = self.state else {
        panic!("Cannot get request after request has been sent");
    };
...

[graphite-app]

The signature generation appears to be using an incorrect approach for Flashbots authentication. According to Flashbots documentation, the raw message bytes should be signed directly, not a string representation of the hash. The current implementation:

let message_hash = keccak256(body.as_bytes()).to_string();
let signature = signer.sign_message(message_hash.as_bytes()).await?;

should be simplified to:

let signature = signer.sign_message(body.as_bytes()).await?;

This would correctly sign the raw JSON request body as expected by Flashbots relay servers. The current approach is performing an extra hashing step and string conversion that would produce an incompatible signature.

Suggested change

	let message_hash = keccak256(body.as_bytes()).to_string();
	let signature = signer.sign_message(body.as_bytes()).await?;

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

[cakevm]

This is not correct. It would fail with "error in signature check...". Guess in has worked with ethers that way

[cakevm]

@mattsse PR is ready to be reviewed again. I plan to add other methods now as well and challenge the data model a bit to make it more robust/compatible with different builder implementations. But would do this in separate PRs.