Jan Xie AMA: Part Three — The Nervos Address System Addressed
Q5: According to the introduction, the CKB address will be unified to a new format after the mainnet upgrade. Does this mean that the CKB wallet address of all dApps will be the same in the future, and there will no longer be a situation where one application has one unique wallet address?
Jan: This is an interesting question because it has something to do with the design of CKB.
First of all, after this mainnet upgrade, the address format will be unified into a fixed-length format, at least for the default address. Why should I emphasize the word “default”? Because the address format used by the developers and applications is decided by them, they have the freedom to choose, and there is no way to force it. The address format is just a standard, and everyone is free to choose whether to use this standard or not. What has changed this time is the default standard: the previous problem is that the default standard contains two formats, a long address and a short address, and the new standard has only one format.
However, this does not mean that the CKB wallet address of all dApps will be the same.
If the address is not the same, it does not necessarily mean that the user experience will be bad. The two issues are separate and independent.
From community feedback, we know the reason why people hate long addresses and short addresses so much. It is the user experience, which is not good. But this problem is not caused by the address format alone. For example, let’s look at the SDK layer. Assuming that our ecosystem is mature, the SDK is complete, Mercury and Lumos are all complete, then no matter what address format there is, these intermediate layers can support it all. So for wallets , developers of dApps and exchanges, as they use SDKs such as Mercury and Lumos instead of CKB RPC directly, they can ultimately achieve a good user experience.
If the middle layer is well done, you may not feel it even if the bottom layer has 100 addresses. This is the advantage of layering, because the middle layer can hide the details of the bottom layer. The previous problem is caused by the immaturity of the middle layer as the details of the bottom layer can bubble up. This is my perspective on the problem.
So, when the ecosystem is still immature, should we wait for the middle layer to mature and find a perfect solution to solve this problem, or shouldn’t we wait and just change the address format to a unified one?
We discussed this with the core team and the community, including UniPass, .bit. Finally, we decided to change the address to a unified one, at least to solve the problem at hand. In this way, no matter whether the SDK in the middle layer is doing well or not, at least the problems we encountered before can be avoided.
But in the future, there will still be multiple addresses on the CKB, and there may even be different addresses for each dApp. This is a feature of the UTXO model. The bad user experience caused by multiple addresses needs to be solved by the middle layer. So when we design Mercury and SDK, we will pay great attention to consider what kind of address it will map to if a new script comes out. If the same address is mapped, of course there is no problem. If a different address is mapped and it is shown on the surface, should the user know about this or not? How do we design it so that users are unaware of this and will no longer encounter the troubles between long addresses and short addresses? This is an issue we have to consider in the future.
So in short, we have actually adopted a temporary solution that everyone is satisfied with — a unified address with fixed length. In the future, we should discuss how the address format should evolve while still having a good user experience.
Why is it possible to have multiple addresses? This is a very interesting thing. I don’t know if you have used a bitcoin wallet. A truly authentic Bitcoin wallet, such as Electrum, or the wallet with the official client, will generate a lot of addresses for you by default. So why do bitcoin wallets do this? Won’t this cause trouble? On the one hand, this is because addresses and accounts are inherently different concepts. Because of the popularity of Ethereum, many people don’t know the differences between the two. Secondly, there are actually many benefits to doing so, such as better privacy protection. If there is only one address, and all your activities are associated with this address, it is very easy to find out who you are with big data analysis. If you want to protect your privacy, the best way is to use a different new address for each transaction.
I don’t know if you are using one address or more addresses in your wallet at the same time. In fact, the account system is not very good in terms of privacy. Bitcoin wallets like Electrum will automatically change addresses all the time. Once you use one, it will generate a new address for you, and once you receive money, it will also generate a new address for you. In the system design of Bitcoin, addresses and accounts are two concepts: accounts do not correspond one-to-one with addresses in Bitcoin, but they correspond one-to-one in Ethereum.
In Bitcoin’s design, an account can have an infinite number of addresses. In fact, we can do it through the system design. The user only needs to remember the account. In fact, he doesn’t need to care whether there are 10 addresses or 100 addresses corresponding to his account, as long as the middle layer below can help him handle it automatically. From the perspective of the account, the assets of all addresses are in the one account, although the transfer and receipt uses different addresses. So the user experience is the same.
The relationship between address and account becoming one-to-one is a shift that has occurred after the success of Ethereum. However, if you can decouple the address from the account, there are actually many benefits, one of which is privacy as mentioned earlier. Another benefit is that because I can have different addresses, my address itself is able to encode information, and this encoded information can prompt the wallet what to do accordingly. In this way, it will make the protocol between the wallet and the application more powerful.
To conclude, having several addresses under the same account is actually not critical and we can explore it gradually. It deserves research and exploration, because everyone is so used to the design of Ethereum. We improve the user experience first, and in the future, we’ll explore how the underlying design should be while maintaining a good user experience as well.
I hope you will not simply conclude that one address is good, which in fact is not. There is actually a lot of space to design. At present, we have a clear principle: when exploring the new design, we must maintain a good user experience. This is a win-win outcome that everyone will be satisfied with.