Add Address w/ checksum support to primitives

[prestwich]

• move keccak256 to primitives
• add Address type
• implement checksumming and checksum parsing
• adjust ABI types to use address instead of B160
• update sol macro
• remove parity hex and hash macro
• replace with const generic fixedbytes
• add macro for wrapped fixed bytes

closes #16

[DaniPopes]

Looks fine, but I don't understand why Address should be its own fixed-hash type when we already have B160? Can't we implement address methods on B160 and export a type alias?

[prestwich]

Looks fine, but I don't understand why Address should be its own fixed-hash type when we already have B160? Can't we implement address methods on B160 and export a type alias?

I've gone back and forth on this a bit, but i think that they ought to be separate. For one thing, there is a type-level distinction, as only some 20-byte hashes are Addresses

I also don't want to clutter the B160 impl space with address-specific behavior (like checksumming) or do floating util functions the way ethers currently does

@gakonst any strong opinion here?

[DaniPopes]

How are not 20 byte hashes addresses? Where else is a B160 used in Ethereum other than addresses?

The u8 namespace is "cluttered" with ASCII/UTF-8 methods, u16 with UTF16 etc, I don't think this holds

[prestwich]

How are not 20 byte hashes addresses? Where else is a B160 used in Ethereum other than addresses?

Ethereum does support the Ripemd160 hash function via precompile 3. Nobody uses it really tho and it would be returned from solidity as bytes20 which we handle as [u8;20]. I'd be amenable to dropping the B160 type entirely, and just having Address

TBH, my hot take is that it's probably not ideal to even have B type aliases. Instead just use named distinct hashes OR just [u8;N]. It's weird that we have a B256 that describes rando 32-byte arrays. Smells like a legacy parity decision. There should be a KeccakOutput and a Sha2Output 😤

The u8 namespace is "cluttered" with ASCII/UTF-8 methods, u16 with UTF16 etc,

just because type-confusion is standard in representation of strings doesn't mean we need to embrace it for our types. It should be illegal at compile-time to use EIP-55 to checksum encode a Ripemd160 output or a non-address bytes20. This is a mistake, and the type-system should prevent it from happening

[DaniPopes]

Makes sense

[DaniPopes]

Some methods that can panic are missing #[track_caller], while others that can't have it

[prestwich]

this PR ended up being much larger than expected 😅