paradigmxyz / mev-share-rs Goto Github PK

data field is missing from EventTransactionLog but the field is emitted from mev-share-node https://github.com/flashbots/mev-share-node/blob/8fd6e372bdfd18d9284fb4ac6030d2a459593f71/mevshare/types.go#L197

Example data from the same event as below

From mev-share-rs

[src/main.rs:117] &event = Event {
    hash: 0xbabc53da23e9c8e8c3d502ae8d2010eff2deced48a9d029671da58298356282f,
    transactions: [],
    logs: [
        EventTransactionLog {
            address: 0x9be957d1c1c1f86ba9a2e1215e9d9eefde615a56,
            topics: [
                0x86a27c2047f889fafe51029e28e24f466422abe8a82c0c27de4683dda79a0b5d,
            ]
        },
    ],
}

From @flashbots/mev-share-client

pendingTx PendingTransaction {
  hash: '0x2336c9d40500349735af8cf855f879ea96fac75c175e37080b9c17860ab50f0f',
  logs: [
    {
      address: '0x118bcb654d9a7006437895b51b5cd4946bf6cdc2',
      topics: [Array],
      data: '0x000000000000000000000000000000000000000000000000000922260b47caf7000000000000000000000000000000000000000000000000000922260b47cb1f'
    }
  ],
  to: null,
  functionSelector: null,
  callData: null,
  gasUsed: 70000n,
  mevGasPrice: 50000000n
}

We currently have the method stub, but need to implement additional types to support the simBundle endpoint.

ref https://docs.flashbots.net/flashbots-auction/searchers/advanced/rpc-endpoint#flashbots_getuserstatsv2

TODO

• add types + rpc trait, see existing eth/mev.rs

It's a common use-case to want to send a private transaction in conjunction with a bundle, similar to the backrun example in the TS reference implementation.
However, importing both traits will lead to compiler error: they have methods having the same name. Differentiating them, can be verbose see example below.

Proposal 1: Split the API client

One way to address this is by breaking up the EthBundleApiClient into two separate clients:

• EthTxApiClient: this client would exclusively handle individual transactions. It would encompass methods such as:

  • send_private_transaction
  • send_raw_private_transaction
  • cancel_private_transaction

• EthBundleApiClient: this client would retain methods specifically designed for bundle operations, including:

  • send_bundle
  • sim_bundle
  • cancel_bundle

Proposal 2: Prefix the 'eth' methods

An alternative solution would be to prefix the eth methods, for instance, renaming send_bundle to eth_send_bundle. However, this approach might introduce a new expectation for the mev_* methods to follow a similar naming convention, like mev_send_bundle.
This inconsistency can be confusing for users. Therefore, Proposal 1 might be more intuitive.

Hello,

After noticing @zeroXbrock's request for a Rust MEV-Share client on X/Twitter, I began working on an implementation.

Now that I'm aware of this repo, I'm unsure whether to publish mine on crates.io. I'm concerned about contributing to DX confusion or decision fatigue. I'm considering whether it makes more sense to refactor my code into a higher-level struct on top of this modular implementation (which is of top quality, by the way) or simply PR the diffs here and archive mine.

The benefits I'd like to retain in the client include:

• The ability to client.send_bundle(params).await?.inclusion().await?
• The ability to initialize a client without the use of a tower::ServiceBuilder and to abstract the signing away.

Regarding 1: Your implementation currently returns Ok() when the bundle is accepted by the relayer. However, I find it useful to keep the inclusion logic abstracted within the client lib.

You can view my take on it here. With this, usage can be extended to:

client
    .send_bundle(params)
    .await? // relayer accepted the bundle
    .inclusion()
    .await?; // bundle was included in a block

Regarding 2: Since there's only one signing logic/method, it makes sense to abstract it.

Unsure if I should retain these enhancements in my repo or if they're better suited here.

I'd be happy to draft a PoC PR if you think this is a good direction: I’m considering introducing a higher-level mev_share_rpc::RpcClient in a new mev-share-rpc crate which would operate using mev-share-rpc-api, and maintain the same abstraction level as the existing mev_share_sse::EventClient.

Of course, if you have a different direction in mind or feel the other approach would be more suitable, I'm entirely open to that as well.

Cheers

move to alloy types with upcoming alloy 0.4 release

https://github.com/alloy-rs/core

https://github.com/mattsse/mev-share-rs/blob/main/crates/mev-share-rpc-api/src/types.rs#L36-L36

currently lacks bundle variant of SendBundleRequest, needs to be boxed

however, the bundle composition is not really clear here:

For example, to allow another searcher to backrun their bundle, one could include an empty object at the end of the body:

which kinda goes against the spec:

     body: Array<
            { hash: string } |
            { tx: string, canRevert: boolean } |
            { bundle: MevSendBundleParams }
        >,

so empty object wouldn't be allowed if this should actually be a MevSendBundleParams

matchmaker.tx has this https://github.com/flashbots/matchmaker-ts/blob/655af28247330c7dc3aea27158752201a7974d3f/src/api/interfaces.ts#L96 version is optional

What's the reason that mev-share-rs doesn't support using Bundle as a BundleItem?

I see that MEV-Share supports this.

pub enum BundleItem {
    /// The hash of either a transaction or bundle we are trying to backrun.
    Hash {
        /// Tx hash.
        hash: TxHash,
    },
    /// A new signed transaction.
    #[serde(rename_all = "camelCase")]
    Tx {
        /// Bytes of the signed transaction.
        tx: Bytes,
        /// If true, the transaction can revert without the bundle being considered invalid.
        can_revert: bool,
    },
}