Validator address is same as account address. Should it be?

[b00f]

The method of generating addresses and making them human-readable is explained here.

From some user feedback, we've discovered an issue. Users use the block explorer to check their validators by searching for them by address, but they get a "not found" error. This happens because the block explorer searches for accounts by address, not validators.

This can be fixed: If the account isn't found, then search for the validator.
However, another issue may come up: There may have both an account and a validator with the same address.

We use the same technique to generate both the account address and the validator address. The address is agnostic about the type of entity it represents (account or validator or anything else in future)

Here are some scenarios:

1- Adding a new type to the address data for validators.
For example, Type 1 could be for validators, Type 2 for accounts. This approach increases code complexity. Also address got more knowledgeable. It has the knowledge of it representative entity.

2- Fixing the problem when we convert the address to a human-readable string.
In this case, we could use another prefix like pv instead of pc for addresses.
Something we need to consider is that whenever we convert an address to a string, we must know whether it's an account or a validator.

3- Not changing anything.
In this scenario, the block explorer could show both account and validator addresses to the user.

[b00f]

@Ja7ad @kehiy @yenkhoon @nagarajmanjunath @amirvalhalla @jwmdev

Any idea?

[kehiy]

both of 1 and 2 scenario is good, why?
first of all we can get address to smart contracts easily in future too
then we and other users or apps can check the address rule without making any request to any where or even do a complex calculation

[amirvalhalla]

The method of generating addresses and making them human-readable is explained here.

From some user feedback, we've discovered an issue. Users use the block explorer to check their validators by searching for them by address, but they get a "not found" error. This happens because the block explorer searches for accounts by address, not validators.

This can be fixed: If the account isn't found, then search for the validator. However, another issue may come up: There may have both an account and a validator with the same address.

We use the same technique to generate both the account address and the validator address. The address is agnostic about the type of entity it represents (account or validator or anything else in future)

Here are some scenarios:

1- Adding a new type to the address data for validators. For example, Type 1 could be for validators, Type 2 for accounts. This approach increases code complexity. Also address got more knowledgeable. It has the knowledge of it representative entity.

2- Fixing the problem when we convert the address to a human-readable string. In this case, we could use another prefix like pv instead of pc for addresses. Something we need to consider is that whenever we convert an address to a string, we must know whether it's an account or a validator.

3- Not changing anything. In this scenario, the block explorer could show both account and validator addresses to the user.

I don't agree with scenario 3 at all because as long as your validator's count increases, the explorer should send a query and this query will search in larger data also I don't agree with scenario 1 because as you said it increases code complexity.

I think the best scenario is scenario 2 the first reason is when we use pv or ps in the address it's more human-readable and the second reason is when we use different prefixes somehow it could help users to detect who is the validator or it's just an account, This helps prevent users from being scammed

@b00f

[kehiy]

PIP-8 fixed this issue:
https://pips.pactus.org/PIPs/pip-8