MNID: A safer way of encoding blockchain addresses in a multi-chain world
Ethereum addresses don’t natively support multiple networks
As of right now, there are at least 7 public Ethereum-based blockchains and a range of private or permissioned chains as well. If someone hands you a regular address like 0x00521965e7bd230323c423d96c657db5b79d099f and you send funds to it, do you really know where those funds are going?
The simple answer is no. If the address is generated from a cryptographic key, it can be used across networks. Most addresses you interact with today and in the future are likely going to be smart contract addresses that exist only on one of these networks. Therefore, it’s a requirement that the uPort platform is capable of understanding the network that an identity exists on.
Let’s illustrate the problem. Today, if you send 1000 ETH from your mainnet Ethereum address to purchase a token on the Ropsten or Kovan test network, that ETH essentially disappears. You’ve just lost 1000 ETH and there isn’t really much anyone can do. This is true for all transactions sent to the wrong network.
At uPort, we are trying to build simple identity and transaction infrastructure for Ethereum, allowing normal people to identify themselves and interact with dApps and smart contracts. A regular user should never need to understand the difference between Morden, Kovan, Main-net, or Rinkeby. uPort shoud protect its users from errors. In other words —
the platform should just work.
The Bitcoin protocol uses Base58Check encoding to prevent just this issue. However, the Ethereum world had hoped for higher-level solutions such as ENS to solve it. Yet, even with ENS, no one really foresaw even the amount of different test nets we currently have today.
As uPort is planning on supporting multiple networks as well as main nets, we needed to solve this issue urgently.
Multi Network Identifiers (MNID)
Our proposal is inspired by the Base58Check encoding as well as EIP77, but adds a network identifier, which allows us to programmatically extract the network used by an address as well as provide a visual indicator of the network used.
The following items are encoded:
- 1 byte version number currently 1
- network id or four bytes of genesis block hash
- actual address data
- Four bytes (32 bits) of SHA3-based error checking code (digest of the version, network and payload)
Then use base58 encoding of the end result. The end result is fairly complete and we feel much safer than any of the previous solutions, but it is still extensible in the future. We could start using simply the network id and replace it with genesis block hash and other meta data in the future.
Examples
The following Ethereum hex encoded address 0x00521965e7bd230323c423d96c657db5b79d099f could be encoded as follows
- main-net:
2nQtiQG6Cgm1GYTBaaKAgr76uY7iSexUkqX - ropsten:
2oDZvNUgn77w2BKTkd9qKpMeUo8EL94QL5V - kovan:
34ukSmiK1oA1C5Du8aWpkjFGALoH7nsHeDX - infuranet:
9Xy8yQpdeCNSPGQ9jwTha9MRSb2QJ8HYzf1u
Extensibility
This was designed to work with Ethereum-based blockchains, but there really is no reason why it couldn’t be used for other blockchain flavors or even for non blockchain identifiers in the future.
It would be trivial to add shard ids, fork descriptors (block number and hash), etc. to the address. It would also be trivial to encode other kinds of identities that don’t correspond directly to an address on a chain.
MNID and the uPort Mobile App
All new identities created as of today’s release of the uPort Mobile App will automatically create an MNID as its primary identifier.
We know many of you are busy integrating uPort in your current apps and we did not want to add extra friction for you if you’re on a dead-line, so your current uPort identities stay absolutely the same and behave the same.
We will have an option soon allowing you to switch over your existing identity to MNID format.
MNID and the uPort javascript libraries
We have released a simple-to-use MNID javascript library. As well as updated uport-lite, uport-connect and uport npm packages to transparently handle both hex and MNID formatted addresses.
Why did we build this?
In the time that Ropsten was being spammed, we needed to consider supporting many new networks simultaneously while maintaining a functioning platform. This event accelerated the development of MNIDs.
