Updated blocks numbers to use U64

[r3v2d0g]

Hey ✋!

The following methods/types/fields were using U256 to represent a block's number instead of, as everywhere else and decided here, U128:

• web3::api::Eth::block_number
• web3::api::Web3::wait_for_confirmations
• web3::confirm::ConfirmationCheck::Check and all related structs/types
• web3::types::TransactionReceipt.block_number

Also, maybe web3::types::BlockNumber should use U128 instead of u64?

[tomusdrw]

The PR looks good, but can we use U64 instead? The use of U256/U128 is a bit historical (we didn't use the ethereum-types crate in the past, so the types had to be manually implemented).

[r3v2d0g]

@tomusdrw

The PR looks good, but can we use U64 instead? The use of U256/U128 is a bit historical (we didn't use the ethereum-types crate in the past, so the types had to be manually implemented).

Sure 😃. Also, should we also make web3::types::BlockNumber's Number(u64) variant use U64 instead of u64(it would make more sense imho)?

[tomusdrw]

Sure smiley. Also, should we also make web3::types::BlockNumber's Number(u64) variant use U64 instead of u64(it would make more sense imho)?

Yes, let's do that.

[r3v2d0g]

@tomusdrw

Yes, let's do that.

There's also types::Trace.block_number but making it use U64 would need us to implement Deserialize on types::Trace because Parity encodes it as a base10 number (instead of a base16 one).

[tomusdrw]

@tomusdrw

Yes, let's do that.

There's also types::Trace.block_number but making it use U64 would need us to implement Deserialize on types::Trace because Parity encodes it as a base10 number (instead of a base16 one).

I see. I think that one can be left as-is.