In the previous article, we gave an overview of the Darwinia chains merge. In this article, we will look at the unification of the address format and precision after the merge.

Address Format Unification

We learned from the previous article that Darwinia Chain, Darwinia Smart Chain and Darwinia Parachain will be merged. Of these chains, Darwinia Chain and Darwinia Parachain use the ss58 address format (ss58 address) while Darwinia Smart Chain uses the Ethereum-style H160 format (H160 address). After the merge, we will no longer need two different formats; they will be merged into a single H160 address.

Why Use An H160 Address?

Considering Darwinia ‘users’ are actually developers, we have decided to simplify their experience, and make it even easier to build cross-chain Dapps.

Prior to the merge, the two address formats coexisted, with ss58 being inherited as the substrate framework’s default address format, and H160 address introduced later on in order to simplify Dapp development on the EVM smart contract platform. For a while, the two address formats were retained for forward compatibility, so Dapps could be developed using H160 addresses in the EVM, and the original on-chain functions using ss58 would not be affected.

However, the coexistence of both address formats had some disadvantages. For example, an H160 address can be converted to an ss58 and easily reverted back to its original format, but it’s impossible to convert an ss58 address to an H160 address, without the ss58 format address being derived from the H160 address to begin with.

With both address formats in use, it is rather confusing for new developers and users alike, especially when operations need to cross EVM-Substrate boundaries.

Therefore, we have considered and settled upon the unification of the Substrate and EVM format addresses as part of the scope of upgrades to Darwinia 2.0, which will leave H160 as the default.

No Need To Consider Different Address Formats Any Longer

A unified address format will make the ecosystem more cohesive and intuitive for both developers and users, as many common operations will cease to require address conversion.

Unified Operation Interface

Prior to the merge, applications such as https://apps.darwinia.network/ needed to connect to both MetaMask and polkadot{.js}. Afterwards, users will only require a single wallet, which will be useful for all blockchain operations including core applications, where we perform staking actions and governance.

Easier Integration And Deployment To The EVM Infrastructure

At present, EVM is the smart contract platform with the longest history, and it has accumulated a variety of excellent tools including wallets, development tools, development frameworks, etc.

When Darwinia is fully compatible with the H160 address format, we will be able to devote more time to the EVM ecosystem. Dapp developers will only need to consider using the EVM ecosystem tools that they are already familiar with, without worrying about incompatibility. And there will be no(or less) additional non-evm staff in Dapp development.

In addition, when third-party systems access Darwinia 2.0, they will only need to use the json-rpc API and rich SDKs that they are already very familiar with.

Underlying Changes Of Address Format

The implications of making the changes required to unify the address formats are not trivial.

The ss58 address format is based on Substrate framework’s AccountId32 type; a product of the sr25519 signature algorithm. Conversely, the H160 address is a product of the ECDSA signature algorithm. Considering the underlying cryptographic algorithms of the two formats are different, in order to change the address format, Darwinia will need to deprecate the sr25519 algorithm and use the ECDSA algorithm when signing transactions, instead. Fortunately, Substrate already supports ECDSA.

We only need to change the account keys signature scheme to ECDSA, while the signature algorithm used by session keys will remain unchanged.

What Darwinia needs to do is to replace AccountId32 with the AccountId20 type. In the Substrate framework, AccountId20 is the wrapper for H160 addresses.

Problems

While the Substrate framework has made it relatively easy to support H160 addresses, there are still some challenges.

Since there is no way to convert an sr25519 public key (AccountId32) to an H160 address without knowing its private key, the original assets or data under an ss58 address cannot automatically be migrated. In addition to that, third-party wallets may also need to modify the transaction signature algorithm to ECDSA.

Here are some of the problems we will encounter:

1. Migration of assets under ordinary substrate accounts

Ordinary accounts are those ss58 addresses controlled by private keys.

When the new chain is ready, users will have to prepare the H160 address on the new chain, and then initiate a claim to migrate the assets from the original ss58 address to the new H160 address. There will be a tool for users to do this migration.

The private keys of the old and new addresses will both be owned by the users themselves, which will ensure the assets will always be under their control.

More details and tutorial will be provided soon.

2. Migration of assets under multi-sig accounts

How the multi-sig account migration will work is not completely determined yet. In the new chain, the multi-sig functionality may be implemented through a multi-sig smart contract. Whether the original multi-sig functionality is retained or totally migrated to the new multi-sig contract is also under discussion.

In addition, the Darwinia multi-sig UI provided by third parties also needs to be adjusted, such as the multi-sig tool provided by Subscan.

3. Data migration of other account-related modules

Data migration including Governance, Vesting, Proxy, Utils, etc. is still under discussion.

4. Wallets upgrade

After replacing sr25519 signature algorithm with ECDSA, extrinsic will be signed using ECDSA. All wallets that support Darwinia will have to upgrade their signature algorithm as well.

Precision Unification

Previous to the merge, we calculated native token values to both 9 and 18 digits of precision. 9 digits of precision for ss58 addresses, and 18 for H160 addresses after the introduction of EVM. We used 18 digits precision for H160 addresses so as to stay consistent with Ethereum. Staying consistent with Ethereum could reduce the developers learning curve.

Maintaining parallel account systems with varying levels of precision presented a challenge when transferring native tokens from ss58 addresses to H160 addresses and vice versa, which is why for this upgrade, a unified measurement of precision has naturally been included. After the merge, Darwinia protocol will become easier to understand and reduce the developer’s learning curve as well. In short, on Darwinia 2.0, native tokens will all have 18 digits of precision.

About Darwinia Network

Darwinia is a cross-chain messaging infrastructure, which provides a light client-based, programmable, universal cross-chain messaging network for decentralized applications. Now, we’ve successfully used Darwinia’s light-client cross-chain messaging protocol(LCMP) to bridge cross-chain messages between substrate-based chains, and even between substrate-based chains and EVM chains, meanwhile, Darwinia provides developers with an SDK, so they can easily integrate cross-chain capabilities into their Dapps. This will have profound implications for cross-chain interoperability, and Darwinia as a cross-chain messaging infrastructure will facilitate the building of a hybrid cross-chain network.

Darwinia 2.0 Will Unify Address Format And Precision