In your previous examples, we explicitly passed the default
ss58Format to the keyring. To understand the impact, we will use a real example of formatting using a known mnemonic.
While the pair has not changed at all since creation, each change of the
ss58Format yields a different output. The human-readable format does not represent any difference in the underlying data, but the encoding is different.
To understand the above example, we will re-construct the actual encoding, based on the actual publicKey and using the underlying util-crypto libraries. First we will decode the addresses generated above.
Here we used the
decodeAddress exposed on the keyring, however we could also import it from
@polkadot/util-crypto. To understand what decode does, it takes the formatted address, verifies the checksums and then extracts the underlying
publicKey. So the formatted address is a representation of the underlying
AccountId, which on the default substrate chains maps to the
publicKey for the pair.
This also means we can encode from publicKey back to an address.
As per the previous example we used
encodeAddress exposed on the keyring, however it could also be imported
Now that we have an understanding of the keyring basics, time to expand our horizons and use the pairs to sign and verify messages.