Arbitrage logic changes

• Arbitrage logic was previously dependent on pool address chaining. This is only the case in uni-router style pools that are swapped via the uni-v2/v3 routers, where each pool transfers tokens directly to the next. This approach doesn't work for the case of an arb contract executing the swaps individually against the pools nor other AMMs which do not have the same router paradigm (ex: balancer).

More concretely, there are two different types of arb transaction series (and potentially many more):

• Uni router style: MEV_BOT -> Pool A -> Pool B -> MEV_BOT (pools transfer directly to each other)
• Standard: MEV_BOT -> Pool A -> MEV_BOT -> Pool B -> MEV_BOT

The new algorithm works as follows:

1. Starting with a set of Swaps, we find potential start and end swap pairs. These are defined as

• start_swap.token_in == end_swap.token_out
• start_swap.from_address == end_swap.to_address
• !swap_pool_addrs.contains(start_swap.from_address)
• • !swap_pool_addrs.contains(end_swap.from_address)

2. Find all routes between start_swap/end_swap as defined by prev_swap.token_out == next_swap.token_in
3. If we find multiple arbitrage routes, filter only to those that are valid based on trace order. (Details on this can be found in the PR commentary below or the _get_arbitrages_from_swaps doc string.

Results

Results differ slightly from mev-inspect-rs. Currently picks up all the same arbs as mev-inspect-rs plus some. Also does not depend on profitability which mev-inspect-rs depends on.

Testing

• Unit tests for sub functions of routing algo
• Existing arb tests work with new logic (+ an additional tx for tests/test_arbitrage_integration.py)
• Spot tested against txs picked up by mev-inspect-rs across balancer/sushi/univ2/univ3 in single tx

In particular we need to answer these questions:

• Should profit estimation happen at the inspector level? Or elsewhere?
• Is it possible to use one script, e.g. an analysis of what tokens flowed in and out of a transaction, to estimate profit?
• Where and when are we posting data to the database?

1.) Changed the parent docker image to buster slim (still debian based but a lot more slimmer) 2.) Added a separate flashbot user (for security), it doesn't run as the root user. 3.) Also worth mentioning, since the container now runs as a non root user you won't be able to install any stuff in the image.

The resulting docker image is half the size of the original one, which will come in handy with the CI/CD stuff. I'm not sure how you handle the CI/CD part, I didn't find any build info (I guess for now you use git pull or something like that)

Tom

Fixes this: https://github.com/flashbots/mev-inspect-py/issues/198

For sandwiches, the backrun swap doesn't need to be funded by the sandwicher, it just should end up cycling back to their account

Currently all balancer transactions are being classified as ERC20 or Vault despite the addresses and abi's being unique. Coult use a second set of eyes on this.

Poetry solves a lot of common package management challenges and greatly simplifies development. It's modeled after Rust's Cargo and very similar to Yarn. The following changes were added in the migration to Poetry.

1. Requirements are now in pyproject under dependencies and dev dependencies, versioning is now managed. New dependencies can be added via poetry add package or poetry add --dev package
2. Python version file is now apart of pyproject, if the original structure is required by another package we can revert this, but I think this should be fine.
3. Scripts are now added in the dev_tools file and can be accessed via `poetry run lint' for example. Commands include lint, test (uses pytest now), isort, isortcheck, mypy, black, blackcheck, and start, build and start_it which are docker commands
4. Pytest was added along with coverage and some "sugar" to "prettify" the output. Pytest will work with unnittest so no changes are required but I would encourage tests to be written using pytest, it's far simpler.

Setting up a project is now as simple as poetry install which will install all the dependencies and setup an environment. The env can be accessed via poetry shell.

This PR

Adds a data class for the "calls" field in Block Also adds some generic utilities for helping in translating from camel case to Python-standard snake case Also moves the logic for building a new block to fetch_block to use for manual testing (+ cleaner)

Writing this:

• to make it easier for inspector implementors to see what data they have available in calls (still TODO actions + result types)
• as a first example of adding a child type on Block + handling the awkwardness around camel case

Todo in future PRs:

• add typing for the different actions and results for each call type
• adopt these in the inspectors - to make things easy for now I switched the call objects back to JSON when passing to inspectors so they don't need to update, but this should change to use the objects when we're ready

Testing

Ensured there are no validation errors from running against different ranges of block numbers

    base_provider = Web3.HTTPProvider(rpc)
    w3 = Web3(base_provider)

    for i, block_number in enumerate(range(block_start, block_start + block_limit)):
        typer.echo(f"Testing {block_number} ({i+1}/{block_limit})")
        # includes trying to load the block
        fetch_block(w3, base_provider, block_number)

Thanks for this great project. I installed this project and tried to do ./mev inspect 12914944. I am using the RPC endpoint on Pokt as recommended. Sometimes I can get it to work and dump to the postgres, sometime I get this error: File "/app/mev_inspect/block.py", line 115, in _fetch_block_traces traces_json = await w3.eth.trace_block(block_number) File "/home/flashbot/.local/lib/python3.9/site-packages/web3/module.py", line 72, in caller result = await w3.manager.coro_request(method_str, File "/home/flashbot/.local/lib/python3.9/site-packages/web3/manager.py", line 203, in coro_request return self.formatted_response(response, File "/home/flashbot/.local/lib/python3.9/site-packages/web3/manager.py", line 168, in formatted_response raise ValueError(response["error"]) ValueError: {'message': 'Internal JSON-RPC error.', 'code': -32603} command terminated with exit code 1

It is truly random -- all it takes for error to go away is to run the command again. What is going on here?

Right now

To backfill a large set of blocks, we:

• Specify the range to backfill and a parallelism N
• Spin up N pods each dedicated to len(range) / N blocks
• Wait for each pod to complete

Some issues with this:

• It's difficult to tell how quickly we're processing the block range / how close we are to done
• If one block fails in the range, that entire pod fails causing it to start over
• if pods finish early, the parallelism drops (only the remaining ones keep working) - we'd prefer to have parallelism of N throughout the full time
• If we want to increase or decrease parallelism during the run, we're out of luck
• If we want to add more blocks to this backfill without changing parallelism, we're out of luck

This PR

Switches to a new model using a simple queue over Redis called dramatiq

Now to backfill a range we:

• Queue up many small batches (ex: 10 blocks) of work for a large range
• Spin up a set parallelism of worker nodes to process one batch at a time
• If a batch fails, it's automatically retried
• if it continues to fail after retries, it stops being retried and is placed in a "dead letter" queue for manual inspection, allowing the pod to continue working on the rest of the data

Using this model we can:

• Query redis to see how far along we are and any blocks being retried or failed
• Increase or decrease our parallelism by adjusting the number of workers
• Increase or decrease the number of blocks being worked on by adding / removing elements from Redis

Conflict between migrations causing error on:

./mev exec alembic upgrade head

Output:

ERROR [alembic.util.messaging] Requested revision 52d75a7e0533 overlaps with other requested revisions b9fa1ecc9929

Adds a table for sandwiches and another for the swaps being sandwiched

Currently doesn't include profit data as this table's immediate purpose is for filtering arbitrages that participate in sandwiches

I am using an endpoint from pokt.network: https://eth-mainnet.gateway.pokt.network/v1/lb/xxxx

I have done all steps mentioned in the README, while got following error:

➜  mev-inspect-py git:(main) ./mev inspect 12914944

Inspecting block 12914944
Skipping virtualenv creation, as specified in config file.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/flashbot/.local/lib/python3.9/site-packages/click/core.py", line 1137, in __call__
    return self.main(*args, **kwargs)
  File "/home/flashbot/.local/lib/python3.9/site-packages/click/core.py", line 1062, in main
    rv = self.invoke(ctx)
  File "/home/flashbot/.local/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/flashbot/.local/lib/python3.9/site-packages/click/core.py", line 763, in invoke
    return __callback(*args, **kwargs)
  File "/app/mev_inspect/concurrency.py", line 18, in wrapper
    loop.run_until_complete(f(*args, **kwargs))
  File "/usr/local/lib/python3.9/asyncio/base_events.py", line 647, in run_until_complete
    return future.result()
  File "/app/cli.py", line 45, in inspect_block_command
    await inspector.inspect_single_block(
  File "/app/mev_inspect/inspector.py", line 56, in inspect_single_block
    return await inspect_block(
  File "/app/mev_inspect/inspect_block.py", line 68, in inspect_block
    await inspect_many_blocks(
  File "/app/mev_inspect/inspect_block.py", line 105, in inspect_many_blocks
    block = await create_from_block_number(
  File "/app/mev_inspect/block.py", line 31, in create_from_block_number
    block_timestamp, receipts, traces, base_fee_per_gas = await asyncio.gather(
  File "/app/mev_inspect/block.py", line 86, in _find_or_fetch_block_traces
    return await _fetch_block_traces(w3, block_number)
  File "/app/mev_inspect/block.py", line 115, in _fetch_block_traces
    traces_json = await w3.eth.trace_block(block_number)
  File "/home/flashbot/.local/lib/python3.9/site-packages/web3/module.py", line 72, in caller
    result = await w3.manager.coro_request(method_str,
  File "/home/flashbot/.local/lib/python3.9/site-packages/web3/manager.py", line 203, in coro_request
    return self.formatted_response(response,
  File "/home/flashbot/.local/lib/python3.9/site-packages/web3/manager.py", line 168, in formatted_response
    raise ValueError(response["error"])
ValueError: {'code': -32601, 'message': 'the method trace_block does not exist/is not available'}
command terminated with exit code 1

mev-inspect-py is unable to process any blocks since the merge. The reason seems to be that the 'miner' of each block is determined by looking for a trace of type reward. Presumably since there is no block subsidy post-merge, there are no longer any traces of this type.

Accordingly _get_miner_address_from_traces returns None and so create_block_from_number fails.

This could be easily fixed by getting the 'miner' from w3.eth.get_block(block_number), which returns the fee recipient for post-merge blocks.

Reverted Compound liquidations are not properly handled and cause an exception during block processing. For example:

block 15049646 processing fails due to transaction 0x6dd0d8be8a77651f64ef399b47fbc87011bd796b43349c3164ff7da965e0b345

other examples are:

0x4ad1e75751058213ece676f2b68fcccdd8290d5db86539773f8c0b15961e0bc3 (block 15352204) 0x56fe1a490b1cea68957721754c0275b4737ef836ca564c114c051cab88b19938 (block 15382895) 0x779537496f27aa54db49dbcb1c3abc710cf46f9f25a2e4f433db063c6ca5e4ad (block 15382904) etc

To reproduce run ./mev inspect with any of the above block numbers.

What does this PR do?

Added a separate transfer classifier spec for the transferToReserve() function on the LendingPoolCore contract. This makes sure that the debt transfer is detected and classified even when the reserve is ETH

Related issue

#313 ETH liquidations on Aave not detected

Testing

Unit test for block 10384319 to check if liquidations for ETH are detected.

Checklist before merging

• [x] Read the contributing guide
• [x] Installed and ran pre-commit hooks
• [x] All tests pass with ./mev test

The Aave spec is not able to detect liquidations for ETH borrowed from the reserve against a collateral token.

The ETH sent with the liquidation call is not classified as a transfer, hence the whole liquidation is not detected on running ./mev inspect 10384319

I am using an archival node with trace calls from pokt network as suggested but am unable to make a request. Everything works fine until I run the line -> ./mev inspect 12914944