Use hexadecimal for all addresses instead of base58+bech32

[SebastienGllmt]

There are three main benefits to this:

Reason one - easier to decode

Currently, for every address, we have to do two steps

1. Try decoding as base58
2. If (1) fails, try decoding as bech32

However, given that all base58 addresses all start with the prefix 0b1000, parsing from hexadecimal immediately gives you the right address type.

Reason two - easier to query

Currently, all queries to cardano-db-sync have to use the bech32 prefix "addr" otherwise you won't get any results. This seems fairly arbitrary as a requirements. Would be much easier if I can just query the hex representation of an address and know it works for all address types.

Reason three - ambiguity on legacy addresses

I have seen people multiple times take a base58 address and wrap it in bech32. Tools like cardano-cli even accept legacy addresses in this format! It's really confusing if we have to parse base58 addresses in two different ways. Saving raw hex is the only canonical way to handle addresses.

[rhyslbw]

Currently, for every address, we have to do two steps

As consumers of the database we should only be exposed to the presentation address format, so this is a workaround.

Currently, all queries to cardano-db-sync have to use the bech32 prefix "addr" otherwise you won't get any results.

The network discrimination forms part of the address identity, why are there addresses being derived without it?

I have seen people multiple times take a base58 address and wrap it in bech32

Wrapping in bech32 seems like an odd approach to a non-existent problem (unless I am missing the point entirely). What is the point of mutating an identity?

I'd also like to see resolution to the inconsistencies, but decoding should be an internal concern of the chain sync client
#224

[erikd]

@SebastienGllmt What about adding an extra column to the tx_out table containing the un-encoded address?