-
Notifications
You must be signed in to change notification settings - Fork 265
Geth support for inspect #112
base: main
Are you sure you want to change the base?
Conversation
cli.py
Outdated
@@ -26,12 +27,15 @@ def cli(): | |||
@click.argument("block_number", type=int) | |||
@click.option("--rpc", default=lambda: os.environ.get(RPC_URL_ENV, "")) | |||
@click.option("--cache/--no-cache", default=True) | |||
def inspect_block_command(block_number: int, rpc: str, cache: bool): | |||
@click.option("--geth/--no-geth", default=False) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a way for us to derive this from the RPC directly?
would be great to plug in any RPC and have it "just work"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just talked to @sragss who had some ideas for doing that in supporting OpenEthereum
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, it seems to be possible to check whether the first RPC query failed or not and decide which method to use based on that. Then, if RPC endpoint client changes and request fails again, we could do the same thing just checking the response code every time.
OpenEthereum also supports block tracing btw: https://openethereum.github.io/JSONRPC-trace-module#trace_block
) | ||
) | ||
except Exception: | ||
return [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what causes this to get hit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from my experience, CREATE2
. Not used in analysis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that's the case, want to move this to the same as you have for STATICCALL where it checks for it explicitly?
It's better on our side to have it just blow up with an exception for now. We'd rather know if we're missing cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Added
create2
- Added
logger
warning.
Haven't yet made it to throw exception when stuff happens since it helps us back-fill in "best effort" form. Yet, person who wants to work on this further for translation to be "exact" can remove this. Can add a comment around here though. What do you think? @lukevs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For 1, should there be a line like this?
if tx_trace["type"] == "CREATE2":
return []
For 2, is there anything that still makes it throw now that create2 is supported?
I'm a little hesitant to blanket accept all Exception - if there are known failures I'm ok with skipping those blocks for now, but I think we should at least limit the scope of exceptions to what we know
Otherwise for geth users they could be unknowingly missing blocks
traces = await geth_get_tx_traces_parity_format(base_provider, block_json[0]) | ||
geth_tx_receipts = await geth_get_tx_receipts_async( | ||
base_provider.endpoint_uri, block_json[0]["transactions"] | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these can be grouped with a gather to make in parallel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have seen extra load while tracing is being done hamper tracer in polygon. Sometimes the tracer runs out of time (internal timeout) and errors. Better to keep separate.
mev_inspect/block.py
Outdated
base_provider.endpoint_uri, block_json[0]["transactions"] | ||
) | ||
receipts = geth_receipts_translator(block_json[0], geth_tx_receipts) | ||
base_fee_per_gas = 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there no way to fetch base fee for geth?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be, however, we don't use in polygon. Could be taken up in a separate PR/GH issue since it will need to be tested for the concerned chain before merge.
from hexbytes._utils import hexstr_to_bytes | ||
|
||
|
||
class RPCType(Enum): | ||
parity = 0 | ||
geth = 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Elsewhere we do like:
class RPCType(Enum):
parity = "parity"
geth = "geth"
which then allows you to instantiate from the string directly
>>> RPCType("parity")
<RPCType.parity: 'parity'>
instead of custom conversion logic
Is there any appetite for getting this merged into main? I think it's a really crucial addition in order to make inspect multichain. EDIT: I just checked this out and the divergence from main goes deep. Maybe the crucial stuff can be pulled out, or someone more familiar with the repo than me can attempt the rebase? |
Added support for geth nodes by introducing a translation layer at RPC call sites. Translates geth traces and geth receipts to parity like traces and parity like receipts. Works for analyzing arbitrages on polygon chain.