-
Notifications
You must be signed in to change notification settings - Fork 106
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
Support filtering & decoding transaction input for txs
dataset with --function-signature
#145
base: main
Are you sure you want to change the base?
Conversation
hi. just looking through this now tx decoding would be a great feature. the broad strokes of the code looks correct. basing the initial implementation off of the log_decoder code makes a lot of sense. longer term it would be good to migrate all of the decoding to something cleaner with alloy can you write out some example cli commands that demonstrate the decoding functionality? would like to see the behavior 1) with no function arguments 2) with function arguments 3) with the same function across multiple contracts 4) with unnamed function arguments the PR has good scope for the initial version. but some future roadmap items to keep in mind, in case it might influence current tradeoff decisions: 1) want to be able to provide multiple function signatures instead of just one 2) want to input/fetch entire contract abi's instead of providing individual signatures manually, so you could do things like decode all txs in the chain history 3) it would be nice to separate the filtering functionality from the decoding functionality. if you can only enter a single function signature, it makes sense to leave them combined, but in the future I think we want to move beyond single function signatures. of course this will make everything more complicated because the current approach would need separate columns for each function. so probably ok to punt that for now |
Thanks for the comments. I generally agree to your comments and I will bring some example commands and its outputs soon. Proposal 1 and 3 looks very reasonable, I will look over my code and try to separate filtering / decoding functionality that enables multiple function signatures as input. Proposal 2 seems a bit trickier, I will try to find some reference from foundry, etc. to fetch abi / contract code from etherscan, or providing path to JSON abi or contract code. |
…in decoding & column appending
example commands filtering & parsing ERC20 transfers - used arbitrum blocks because ethereum has too many transfers in single block
|
I've fixed some code to handle function signatures with anonymous argument name. Also, considerations for future expansion of this feature - I think current structure keeps separation of filtering (code) and decoding (code). If multiple function signatures are allowed, Some concerns I have is 1. how to support calldatas with unknown human readable signature but known schema, and 2. any needs to only filter but do not parse calldata into separate columns. |
Hey, sorry for dropping by randomly. But really looking forward to this feature. When do you folks think that this would be merged? |
Motivation
Closes #140.
Solution
Most codes are copied from log_decoder which makes a lot of duplicate codes, some seems to be able to be abstracted. Refactoring for removing duplicate codes & documentation TBD, review for current code structure would be very helpful.
PR Checklist