Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Miners URLs exposing eth_sendBundle should be public #64

Open
ChessUsername opened this issue Aug 21, 2021 · 3 comments
Open

Miners URLs exposing eth_sendBundle should be public #64

ChessUsername opened this issue Aug 21, 2021 · 3 comments

Comments

@ChessUsername
Copy link

Miners URLs exposing eth_sendBundle should be public (github repo or docs), so anyone can run its own relay.flashbots.net endpoint.
Just in case relay.flashbots.net turns out to be malicious.

@andr11111
Copy link

It used to be this way, but in practice it showed that a public endpoint is susceptible to DoS attacks as well as operational complexities with exposing mining pool infra to the outside. Imo at the end of the day mining pools have to decide which relays they can trust to send them bundles based on their offchain reputation. The function of anti-spam / tx filtering is not a trivial problem that relays solve allowing mining pools to earn additional revenue while operating without interruptions that negatively impact the hashrate.

@ChessUsername
Copy link
Author

a public endpoint is susceptible to DoS attacks as well as operational complexities with exposing mining pool infra to the outside

That's the whole point of this repository! To avoid DDoS to the geth node, in fact, this repo acts as a proxy to the miner node, and "exposes" just 4 methods to the outside (eth_sendBundle, eth_callBundle, flashbots_getUserStats, flashbots_getBundleStats).
An eventual DDoS would just put down the relay, and not the geth node.

Imo at the end of the day mining pools have to decide which relays they can trust to send them bundles based on their offchain reputation

Nobody could ever become a relay if the miner's URLs are not public, so offchain reputation can't be established. It seems like a chicken-egg problem. Who was born first?

Let me underline what the first page of Flashbots docs says (emphasis is mine):

Our primary focus is to enable a permissionless, transparent, and fair ecosystem for MEV extraction. It falls under three goals: Democratizing Access to MEV Revenue, Bringing Transparency to MEV Activity, and Redistributing MEV Revenue.

So, without a public list of mining pool URLs, I don't think this project is democratic and transparent, because the central point (relay.flashbots.net) is not replicable.

At the moment, if the operators of relay.flashbots.net turn out to frontrun the searchers (one bundle frontrun every X bundles, where X is random and high enough, would be difficult to notice) nobody would be able to set up an alternative endpoint to call.
The only option would be to contact every top mining pool and ask them their URL to send bundles to, and that's not Democratizing Access to MEV Revenue.

@andr11111
Copy link

I fully understand the logic of your comment. That's exactly how this worked initially. However, the reality turned out to be a bit more complex which prompted a re-architecture:

  1. DoS can happen not only at the network level (sending large traffic of transactions), but at the EVM level (sending transactions that consume node's resources). So a simple/thin proxy is not enough. Currently Flashbots relay is running clusters of mev-geth nodes that simulate all incoming transactions before sending them to mining pools. It also does additional queuing and reputation-like system to further filter out malicious tx traffic, which occurs quite frequently. So a real relay that actually works is not just a simple proxy, it is an infra-heavy component. In addition, there is bundle merging, which requires compute-heavy search for not only most profitable bundles, but compatible bundles, which can be mined together in the same block.

  2. Mining pools are already incentivized to receive as good of a tx flow as possible, because it increases their profitability. They establish websocket connections with relays they trust to receive the bundle flow from. There are already multiple relays like Flashbots, Archer, Nethermind, Bloxroute - so that vision is already a reality, it just requires a social reputation/coordination for mining pools to trust a relay. Perhaps in the future this can be better automated for mev-geth to automatically connect to a list of trusted relays. In proof-of-stake networks this trust signaling is achieved via delegations for example.

  3. This architecture actually mirrors how ethereum network works. A Geth node chooses which p2p peers to receive transactions from and not the other way around. You can't force someone's node to accept your transactions, but you can ask them to establish you as a trusted peer. RPC endpoints are never publicly exposed unless you charge for it (like Infura).

  4. Potential front-running possibility at the relay level is well understood and there are active research streams trying to solve this with either encryption (SGX) or crypto-economic design. E.g. https://ethresear.ch/t/mev-sgx-a-sealed-bid-mev-auction-design/9677

Note that this represents my personal thoughts and not Flasbots as a whole. Flashbots is an open research collective where members can disagree and debate possible solutions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants