SS58 is a simple address format designed for Substrate based chains. There’s no problem with using other address formats for a chain, but this serves as a robust default. It is heavily based on Bitcoin’s Base-58-check format with a few alterations.
The basic idea is a base-58 encoded value which can identify a specific account on the Substrate chain. Different chains have different means of identifying accounts. SS58 is designed to be extensible for this reason.
The basic format conforms to:
base58encode ( concat ( <address-type>, <address>, <checksum> ) )
That is, the concatenated byte series of address type, address and checksum then passed into a base-58 encoder. The
base58encode function is exactly as defined in Bitcoin and IPFS, using the same alphabet as both.
<address-type> is one or more bytes that describe the precise format of the following bytes.
Currently, there exist four valid values:
The latter two are “wildcard” addresses that are meant to be equally valid on all Substrate networks that support fixed-length addresses and/or indexed addresses. For production networks, however, a network-specific version may be desirable to help avoid the key-reuse between networks and some of the problems that it can cause. Substrate Node will default to printing keys in address type 42, though alternative Substrate-based node implementations (e.g. Polkadot) may elect to default to some other type.
There are 16 different address formats, identified by the length (in bytes) of the total payload (i.e. including the checksum).
Several potential checksum strategies exist within Substrate, giving different length and longevity guarantees. There are two types of checksum preimage (known as SS58 and AccountID) and many different checksum lengths (1 to 8 bytes).
In all cases for Substrate, the Blake2-256 hash function is used. The variants simply select the preimage used as the input to the hash function and the number of bytes taken from its output.
The bytes used are always the left most bytes. The input to be used is one of:
concat( <address-type>, <address> ).
The advantage of using more checksum bytes is simply that more bytes provide a greater degree of protection against input errors and index alteration at the cost of widening the textual address by an extra few characters. For the account ID form, this is insignificant and therefore no 1-byte alternative is provided. For the shorter account-index formats, the extra byte represents a far greater portion of the final address and so it is left for further up the stack (though not necessarily the user themself) to determine the best tradeoff for their purposes.
The advantages of using the SS58 preimage format is that the resultant address may be trivially checked for validity, even when offline. However, when combining this with the account-index short-forms, the format doesn’t manage the concern that the same index may eventually represent a different underlying address, perhaps one that the original owner doesn’t hold. Using the AccountID preimage format means that any change in the underlying account-id must have the same initial portion of hash-output as the original account-id. At lower sizes of checksum, this does little more than prevent accidentally using an old SS58 address. For higher sizes it provides modest, but quantifiable, security against a casual attacker, requiring the attacker to find an address whose Blake2 hash that shares upto 8 bytes with the original.