Enhance: explicit account types/binary encoding of addresses (pub keys) instead of encoded string in tx

[iltoga]

Description

In order to allow multiple account types in transactions, we need to normalize the way account addresses are saved and exchanged with client apps. We propose to adopt similar logic of that in the previous core-node prototype, splitting account address (now an encoded/formatted string) into account type and account bytes.

to achieve that we will need to refactor the follwoing tables schema and all relative code: mempool:

• sender_account_address
• recipient_account_address transaction:
• sender_account_address
• recipient_account_address account_balance:
• account_address node_registry:
• account_address account_dataset:
• setter_account_address
• recipient_account_address account_ledger:
• account_address escrow_transaction:
  • sender_address
  • recipient_address
  • approver_address pending_transaction:
• sender address pending_signature:
• account_address multisignature_info:
• multisig_address liquid_payment_transaction:
• sender_address fee_vote_commitment_vote:
• voter_address fee_vote_reveal_vote:
• voter_address multisignature_participant:
• multisig_address: careful with this that can be an address or the hash of another multisig_info bytes
• account_address

Moreover, since all account addresses are now in bytes, that makes very hard to debug at db level, we need to think of a way to keep a reference in db to the string (formatted) version of every account.

1. we can have two account fields in account_balance table (one in bytes and one in string) and join that table with any other that has only account in bytes to show a 'readable' account in query results (this will generate duplicates)
2. we can add an unmanaged table containing:
   • acc type
   • acc (butes)
   • strAcc (formatted account) and use that one to show formatted account in query results (this adds extra complexity to the schema)

Breakdown

• Refactor all above tables in migration.go (refactor relative proto messages)
• Refactor all relative code! (this is potencially a very big code refactoring)
• Refactor all affected unit tests!!

Expected behavior

After this, in db we should always have account addresses expressed in bytes + account type.

[andy-shi88]

looks good and yes multisigInfo will be affected as well, as now the address of multisig is hashes of all account address ( in string), it'll need to be updated to use bytes form