feat(etherscan): account endpoints

[tomtau]

Motivation

#485

Add etherscan.io account endpoints

Solution

Added them.

PR Checklist

• Added Tests
• Added Documentation
• Updated the changelog

[tomtau]

FYI I checked forks and noticed @1wilkens had a WIP version https://github.com/1wilkens/ethers-rs/commit/f2eb53732fca388b0af21a756828e8efab8106d0 -- feel free to review if this PR works for you!

[mattsse]

Awesome, thanks for this.

A few nits and suggestions.

I'm fine with the AsRef<str> approach.

It'd be nice if you could copy some of the tests as examples to the API functions' docs

[gakonst]

nice work! just small nit around type defs

[tomtau]

@gakonst I tried to put more restricted types on the response fields, but I'm not sure whether it'll be worth it: e14d054

There are a few issues at this moment:

• I don't know if Etherscan API response schema is documented anywhere, this page only shows a few examples: https://docs.etherscan.io/api-endpoints/accounts so I'm not sure whether there are more edge cases it may fail to parse etc.
• I haven't checked in detail whether every field is interpreted correctly -- for example, whether the nonce value is a plain decimal string or a hexadecimal string (and I think U256's default deserialization assumes the latter?)
• I'm not sure how common the edge case values are -- my sense is that they are not (at least for the GENESIS ones), so it may be unnecessary for many end use cases to worry about them.

Maybe a middle ground could be to keep the returned response types flexible as before (maybe they could be renamed as e.g. RawNormalTransaction to make it clear they are raw responses that weren't fully checked) + add more restricted cleaned up domain types with a TryFrom conversion from the raw types.
What do you think?

[mattsse]

Awesome!
can we also use Address, U256 etc in the new InternalTransaction and Erc20TokenTransferEven types?

[mattsse]

• I don't know if Etherscan API response schema is documented anywhere, this page only shows a few examples: https://docs.etherscan.io/api-endpoints/accounts so I'm not sure whether there are more edge cases it may fail to parse etc.
• I haven't checked in detail whether every field is interpreted correctly -- for example, whether the nonce value is a plain decimal string or a hexadecimal string (and I think U256's default deserialization assumes the latter?)

that'll be discovered eventually so we can fix once that happens if there's a serde issue

• I'm not sure how common the edge case values are -- my sense is that they are not (at least for the GENESIS ones), so it may be unnecessary for many end use cases to worry about them.

not familiar with the GENESIS values, but that sounds reasonable

[tomtau]

can we also use Address, U256 etc in the new InternalTransaction and Erc20TokenTransferEvent types?

They are now updated to be like that if that's the preferred way (as opposed to keeping them flexible and having conversions to domain types).

[mattsse]

lgtm

[gakonst]

Sick - thank you for bearing with our nits sir.

[1wilkens]

FYI I checked forks and noticed @1wilkens had a WIP version 1wilkens@f2eb537 -- feel free to review if this PR works for you!

Sorry didn't even see your mention. Awesome that this is now merged, my branch was indeed early WIP so thanks for finishing this :)