feat: Added the network and accountId to the response of validate endpoint

[Imod7]

Description

Added the network and accountId in the response from the /accounts/:address/validateendpoint when the given address isValid. If it is an invalid address (isValid: false) then network and accountId have null values.

Functionality of the endpoint

Below you can find a description of how this endpoint behaves and why.

This endpoint is meant to receive only valid addresses and these can be in the following formats :

1. ss58 format
   • example address from tests 1xN1Q5eKQmS5AzASdjt6R6sHF76611vKR4PFpFjy1kXau4m
2. hex (from a u8 array) format (of valid length)
   • example address from tests 0x002a39366f6620a6c2e2fed5990a3d419e6a19dd127fc7a50b515cf17e2dc5cc592312
3. for anything else, this endpoint will/should return null which means isValid field will be false and all other fields will be null.

Comparing with subkey functionality

If we compare this endpoint's functionality with how subkey works then we have the following behaviours :

1. For the first format : subkey and validate endpoint will return a result :
   • hence will consider this address valid and
   • the AccountId returned will be the same as the one returned from the validate endpoint
2. For the second format :
   • subkey :
     1. considers this address invalid
     2. but if we correct manually the address and we remove prefix+checksum then it will return a result and the expected AccountId
   • validate endpoint :
     1. considers this address valid. Why ? because it is possible that a user stores their keys in this format.
     2. then strips the prefix+checksum and then returns the correct AccountId

Important Note

If we give as input the address (stripped from prefix+checksum hence AccountId) :

• to subkey : it will return a valid result
  • why ? because accepts addresses + account ids.
• to validate endpoint : it will return null
  • why? because this is an AccountId and this endpoint is meant to validate only addresses. For account ids we intend to create another endpoint.

[TarikGul]

For the moonbeam address I will need to look into that, and play with it. Not exactly sure whats happening there.

Note: Once were satisfied with the changes to the endpoint we'll need to update the docs.

[joepetrowski]

For the moonbeam address I will need to look into that, and play with it. Not exactly sure whats happening there.

For Ethereum style addresses they are not SS58 formatted, they are just 20 raw bytes. It should be a variant of enum MultiAddress from Substrate.

[TarikGul]

For Ethereum style addresses they are not SS58 formatted, they are just 20 raw bytes. It should be a variant of enum MultiAddress from Substrate.

Ahh okay cool, I assumed they were leveraging ethereums aaddress format. Thanks for the info.

[TarikGul]

As a note as well, when its out of [WIP] to change the squashed commit name (title of the PR) to a conventional commit structure.

[Imod7]

• Comments on the added accountId in the response of the endpoint and
• Thoughts on the implementation related to the conversion of the accountId

[TarikGul]

Few nits to resolve, but overall great job! 👍

You will also need to run yarn build:docs to regenerate the docs.

[joepetrowski]

For the Should give the correct response for a {network} hex value tests, I don't understand how the sanitization should know to which network the hex belongs? Wouldn't you have to pass it a network name or prefix as an arg? The hex value should generally speaking be the same across most networks (exceptions being those that don't use AccountId32: [u8; 32] as their AccountId type).

[TarikGul]

@joepetrowski Our process for converting a hex address goes as such:

1. convert it to a u8a
2. If the encodedlLength satisfies one of the acceptable lengths then we can check the addresses checksum.
3. We then specifically use checkAddresssChecksum which will return the ss58Prefix for us.
4. If its then valid, Using the given information we can then match that ss58Prefix with its known network.

Hope that clears that up :)

[TarikGul]

Great updates, and changes. Good catch @joepetrowski .

Just seems like there is a conflict with the docs.

git pull origin master
yarn && yarn build:docs

That should sort out the merge conflict

[Imod7]

Thank you @TarikGul and @joepetrowski for all the comments and reviews on this PR. Very much appreciated!!!

[jsdw]

Couple of wee comments but LGTM!

[TarikGul]

Awesome LGTM 👍 Thank you!