Proposal: Token Address Scheme

[mcf-rocks]

1. Preamble

• DIP Number: (To be assigned upon acceptance)
• Title: Token Address Scheme
• Author(s): smith@shoji.org
• Status: Draft
• Category/Type:
• Creation Date 2024-04-15

2. Abstract

Scheme for mapping from bls public key to token address.

3. Motivation

For use in token contracts (separate DIP to follow) there will need to be some unique identity representation of the user which is provably owned by the user; to hold balances against, to be owner of the contract, etc. The user will be represented in the contract by their token address.

The regular Dusk addresses used in the wallet should not be revealed, but the bls public key can be revealed (as in the case of provisioners), therefore the token address can be safely derived from the bls public key.

This scheme describes how to derive a token address from a bls public key.

4. Technical Specification

i) derive address from bls public key

a) Take the (96) bytes of the bls public key as input to a blake3 hasher

b) output as fixed length 20 bytes (finalize_xof)

c) prepend version/type bytes [ 4, 175, 225 ] to the previous output

d) take these (23) bytes as input to a (new) blake3 hasher

e) the first 4 bytes of the output is the checksum

f) append the checksum to the previous input to give 27 bytes; VVVKKKKKKKKKKKKKKKKKKKKCCCC

g) encode to base58 using the BITCOIN alphabet to give a string

ii) check an address is valid

a) decode string from base58 using the BITCOIN alphabet to 27 bytes

b) take the last 4 bytes as checksum

c) take the first 23 bytes as input to a blake3 hasher

d) if first 4 bytes of output == checksum, address is valid

5. Rationale

Many schemes are possible, all crypto protocols derive addresses from keys, example addresses (Bitcoin, Ethereum, Solana):

1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
0xd8da6bf26964af9d7eed9e03e53415d37aa96045
52C9T2T7JRojtxumYnYZhyUmrN7kqzvCLc4Ksvjk7TxD

This scheme produces 1) output in base58, a format designed to maximize human readability 2) addresses which are reasonably short 3) includes a checksum 4) uses a fast hashing algorithm 5) includes version/type bytes.

An example address:

dk1ms96q8mqVHwx7qXaWgpTUnpTSdhwkT3yt

6. Backwards Compatibility

n/a

7. Test Cases

TBD

8. Implementation

TBD

9. Security Considerations

If it is computationally possible to find bls secret keys for token addresses, or if it is computationally possible to find multiple bls public keys that map to the same token address (collisions), the scheme is broken.

10. Other Considerations

Although this has been framed in terms of token contracts, likely many contracts would need a similar identity representation mechanism. This DIP only covers deriving an address, for actual use the ownership of the address would need to be verified (by passing the bls public key and a signed message and verifying in the contract). These two things together are essentially msg.sender in Ethereum which is part of their standard contract invocation mechanism. If we think many contracts will end up doing this, would it be worth implementing in core?

References
blake3
bs58