Name resolution on node side for RPC requests

[RealJohnSmith]

Description of the issue

I think that read-only RPC requests (e.g., getBalance, getNonce, ...) should allow for name service resolution by a node to same roundtrip (latency) and overhead with handling extra network traffic.

These request could take another parameter in the request. If JSON contains String name it would try to resolve and use this, if it contains address it would use this field as an address. This system guarantees that no name that looks like a valid address can be "accidentally" resolved and data returned for an unexpected target. It also requires explicit action from the client (not to use address field, but name field instead), which implies that the client wants to do this action and otherwise would have to resolve the name and use it in the subsequent request anyway.

When it comes to transactions, they still need a program hash and client would have to request this from the node. Nodes shouldn't allow transactions by named addresses.

Issue-Type (put an x sign in the square brackets)

• bug report
• feature request
• Documentation improvement

Checklist

• Running latest version of the code.
• This issue has not been reported earlier.

Your environment

• OS: Not relevant
• Go version: Not relevant
• Release tag/commit of the code: ed50f28

[yilunzhang]

We need to solve 2 corners cases:

1. How can we make sure a name is not address-like? A harder question is: how can we distinguish a misspelled address from a name.
2. Name can be de-registered transferred. If transferred, there may be some security concern.

Also, if we decide to do it, name -> pk conversion should be done on the wallet side using an API call to make sure that only pk appears in txn data, otherwise it will make historical block verification very hard (node needs to know name -> pk map at any height)

[RealJohnSmith]

1. Node doesn't have to care about that, because the client will tell it what to do in the request (e.g. treat it as an address or treat it as a name). The client can decide using the same logic as it would use to decide if it wants to resolve and use the result as an address or use it as an address directly. This may be augmented by some UI clues of a specific application.

2. Only security concern I can think of right now is if it was used in transactions and it wouldn't, as both of us said.

What is the mechanism to do a name/pk decision when it comes to sending a client to client messages? In that case, the node has to decide if it is misspelled pk or a name. Can we use the same decision system?
One more solution would be to force prepend names with some special character. So instead of somename it would be $somename and the dollar sign would mean "resolve this"

[yilunzhang]

Currently the name has a max length 12 so it's not a problem. But it's a problem we need to solve. The most simple solution is to restrict name length to make sure it's shorter than address 😂

And to be more explicit, the process should be purely on client side like this:

1. when the sdk receives a string as receiver, it will use length or other way to determined whether it's a name or address.
2. If it's a name, it will use the get address by name rpc call to get the address from the node and replace the name with the address.
3. Then when sdk is creating a txn, he will always use address but not name

Also there is another minor security concern: if the node is compromised, sdk may send money to the wrong address...

[RealJohnSmith]

It can't. Nobody will be using this for TXNs. Only thing I wanted is that it will be possible to resolve on a node to do simple RPC requests like query balance.

[yilunzhang]

2 more related comments:

1. A RPC to get pk by name is needed for client end to end encryption.
2. A string that is either a valid pk or a valid wallet address should be considered as invalid name to avoid ambiguity.