seth feature parity

[gakonst]

Problem & Context

Currently, cast and its cli are not at feature parity with seth.

All of Seth's commands can be found here, and the so far implemented cast commands can be found here.

Solution

Pick any of the commands that are not implemented, and go for it!

Some reference PRs on how this was done for other commands for newcomers can be seen below:

• feat: add nonce to cast #266
• feat: add cast --from-wei #261
• feat(cast): add tx command #260
• feat: add code to cast #242
• Add the max_uint subcommand to cast and cli #223

[odyslam]

@gakonst let's make this a good first issue and rename it to cast.

[raxhvl]

Can a Rust newbie take this up?

[gakonst]

Yes! These are small self-contained commands, so shouldn't require much. Take a look at the PRs linked in the OP for guidance. Also happy to review.

[raxhvl]

Update: I'm working on this. I'm an absolute beginner, please allow me some time.

[odyslam]

Update: I'm working on this. I'm an absolute beginner, please allow me some time.

I have started working on this as well. Perhaps we can coordinate and not implement the same functionality.

I have opened a draft PR while I work on it #284 and I note what I work on. Perhaps you can do as well or write a reply there?

[mds1]

I'll add comments to this issue for features that I've noticed are missing as I attempt to replace seth with cast during my normal usage:

• cast call does not support the --block <block> flag for querying historical data — done in feat: support block option in cast call #638
• as noted in the readme, cast run-tx is not supported—I used the --trace and --debug modes often - added in feat(cast): simulate published transaction locally #1358
• cast client — added in feat: cast client #635
• cast sig — added in feat: add cast sig #645
• cast index not supported — any ideas for better syntax than seth index? — added in feat(cast): Implemented cast index (seth feature parity #29) #676
• cast call <addr> <0xCalldata> is not supported. Probably just need a .starts_with('0x') block here? —done in feat(cast): implementing cast call/send <address> <0xCalldata> #742
• cast abi-encode with ints not supported, e.g. cast abi-encode "x(int256)" "-123" errors with "Found argument '-1' which wasn't expected, or isn't valid in this context" fixed in fix: support ints in cast #584
• Support for signed integers is lacking. Support I256 in format_units and parse_units gakonst/ethers-rs#842 should be completed first to make this simpler
  • unsupported in cast --to-fix because in cast/src/lib.rs the to_fix method only takes a U256. Ideal solution is to add support to ethers-rs format_units and pass through to that method
  • unsupported in cast --from-wei because in cast/src/lib.rs the from_wei method (1) takes an U256 and (2) passes through to ethers-rs format_units which does not support integers
  • unsupported in cast --to-wei because in cast/src/lib.rs the to_wei method (1) takes an U256 and (2) passes through to ethers-rs parse_units which does not support integers
  • unsupported in cast calldata because in utils/src/lib.rs the encode_args method calls parse_tokens which errors with Failed to parse tokens, though I have not looked into why

[psushi]

I'm working on cast index, after implementing exaclty what seth does, we can discus how to improve the syntax.

[tynes]

There are 2 reasons why I still use seth over cast

1. --rpc-url defaults to http://localhost:8545 without needing to set an env var, so I can omit adding it when I port forward my remote geth node
2. The table response is pretty printed (ie hex strings are turned into integers, easier for human consumption)

[onbjerg]

• cast send --create is missing as well

[onbjerg]

Seems like the last two remaining items are cast send --create and I256 support?

[tynes]

Seems like the last two remaining items are cast send --create and I256 support?

cast ls and cast accounts are missing as well. It's convenient to know which wallets you currently have access to. I do think the commands can be improved upon

[mds1]

Other features missing, from comparing the outputs of seth and cast

• --from-ascii
• bundle-source, though I don't think we need this one
• logs
• mktx
• sign
• solc

I'm not sure how many of these are used so we may not care about getting exact parity.

[gakonst]

sign exists under "cast wallet"

[onbjerg]

solc

What is this one?

--from-ascii

We do have this one 😄

[mds1]

Ah, --from-ascii doesn't show up when running cast -h, but yes just confirmed it is there under an alias for --from-utf8

solc lets you "compile a single file using a default --standard-json input"

[onbjerg]

Not sure we want that necessarily? 🤔

[mds1]

I've personally never used it and would be ok not adding it proactively, and perhaps we wait until its requested and discuss then?

[onbjerg]

Ok so to sum up:

• cast accounts/cast ls (they could just be merged into cast wallet ls?)
• cast send --create
• cast logs
• cast mktx

Optionally also cast bundle-source but there probably isn't a lot of usage for that command. Seems like seth bundle-source was primarily used to get source maps for seth run-tx and the DappTools debugger, but we should try to make this automatic or push Etherscan to include source maps in their API.

[tynes]

There is another command that could be useful - seth rpc which doesn't seem to completely work when passing args, but it does work when the RPC accepts no arguments. This would be useful to call RPCs that don't already have cast commands. I think something like this would be helpful to cut out the curl -H ... boilerplate.

cast rpc <rpc-method> <arg 1> <arg 2> ...

Delineating between types here would need to be handled, for example strings vs numbers. geth will only accept numbers at times, not strings of numbers. So strings would need to be explicit, like '"3"' would be a string and "3" or 3 would be a number. The response json could return the jsonrpc result field and it could be easily composed with jq

[henry-hz]

Hi :) Does cast run remote debugging with custom source ? In the example below, it's possible to start the debugger in FUSE network without the need of Etherscan.

seth run-tx --debug 0xc3b63ab002d4a16fe95566a9c0816fab6cf07ac9867bd5ad1319095cef13b9a2 --source out/dapp.sol.json

[onbjerg]

I'm not entirely sure I understand - you want to optionally use local sources for decoding with cast run? I don't think this is currently possible - feel free to open up a feature request so we can track it better :)

[henry-hz]

@onbjerg exactly, many side-chains does not have direct support to retrieve the source code from etherscan, so adding the source code of the deployed contract on the path is how seth is doing.

[gakonst]

Makes sense - we don't have support for this yet, let's track in a separate feature issue (pls open one @henry-hz) and we can discuss there

[henry-hz]

Ok!
Done

#1723

[onbjerg]

Closing, everything in here is implemented except cast mktx which is unplanned, and cast events/cast accounts that have separate issues