By Matt Zand and Brian Wu
Due to the popularity of blockchain and decentralized finance, many applications that offer digital currencies like Bitcoin or Cryptocurrencies come with a feature called digital wallet. A wallet allows users to store and manage their private keys. A wallet is also used for key generation. Depending on the platform in which a user can access and manage their wallet, there are 4 types of wallets: web, desktop, mobile, and Hardware.
Another way to categorize wallets is based on the way in which keys are generated which includes deterministic and nondeterministic wallets. A non-deterministic wallet is considered a rather old style compared to a deterministic wallet. Modern deterministic wallets have advantages over non-deterministic wallets in many aspects, such as backups, security, data storage, accounting, auditing, and access controls.
The Hardware or HD wallet is the most well-known kind of deterministic wallet. It's also a preferred option among the deterministic wallets if you want to create one since it is well developed. When it comes to the following cases, the HD wallet shows more advantages than other types of deterministic wallets like web and mobile applications.
Normally, a deterministic wallet holds a single chain of keypairs, which doesn't support selective keypair sharing, while the HD wallet allows such selective sharing on multiple keypair chains that are generated from a single root. In some cases, being able to create public keys without exposing private keys makes the HD wallet available in environments that would normally be a higher security risk. With respect to security, the private key management does not only refer to key generation offline (away from the network, such as cold storage). Key sharding and splitting or division of signatures are other alternatives. Key sharding, also known as Shamir's secret sharing, is basically splitting a key into several pieces, or shards. This makes each shard useless, and the original key would be reconstructed unless enough pieces are assembled to reconstruct. A similar but very different concept to this is multi-signature wallet.
With cryptocurrency wallets becoming more and more developed, the protocols and standards need to be shared across the industry. The Ethereum community has been establishing standards over the years. Some of them are known as Ethereum Improvement Proposals (EIPs). Some are on application-level standards, for example, the standard format for smart contracts, known as Ethereum Requests for Comment (ERC). Standards are also followed for wallet creation. There are a few standards that are widely adopted, as follows:
BIP stands for Bitcoin Improvement Proposal. Although there are so many differences between Bitcoin and Ethereum networks today, they still have a lot in common and share standards and protocols.
The mnemonic code words is 128-bit to 256-bit entropy. This entropy will be plugged into a Password-Based Key Derivation Function 2 (PBKDF2) function and stretched to a 512-bit seed. The seed will be used in building a deterministic wallet.
In this article, we will review HD wallet or BIP- standard.
HD wallets follow the BIP-32 standard, which was created on February 11, 2012. The standard was set for mainly two aspects:
Before going into any details regarding key derivation, we need to understand the concept of extended keys properly. The concept of extended keys came into the picture to prevent the derived child keys from entirely depending on the parent key itself. The process for deriving the child keys is as follows:
1. Take the private and public parent key.
2. Extend the key with an extra 256-bit entropy, called chain code:
3. The extended keys will be used to produce the child key instead of the original private and public parent keys.
For key derivation, Child Key Derivation (CDK) functions are defined. They are functions that are used to derive child keys from a parent key. There will be a different CDK for each computation of the following:
The parent key doesn't need to be the root of the tree, and it can be any node on the tree. To summarize, there are two ways to generate a child public key:
Notice it won't be possible to compute a private child key from a public parent key.
However, the feature of generating child public keys from parent public keys only is a key feature of the HD wallet. This brought us back to the second point of advantage deterministic wallets have over non-deterministic ones. With an extended public key on a web server, we can generate as many public keys and addresses as we need. If it wasn't an HD wallet, we would have to store all those pubic keys and addresses on a server, which is more work for maintenance and security. On the other hand, extended private keys can be secured on a separate server or offline cold wallet. Even if the server holding the pubic keys is compromised, the private keys won't be impacted.
Like a coin with two faces, the convenience of generating all the public child keys from the extended public key also comes with risks. Recall the process of generating extended keys. In the second step, we extend the public key with a chain code. If the attacker gets the chain code from the extended public key, it will compromise the non-hardened child key. With the child private key plus the chain code, the attacker will be able to derive the parent private key. Other than extended keys, we will introduce another concept, that is, hardened and normal (unhardened or non-hardened) keys. Here, we simplify the computation of those keys as follows:
For the hardened child key, the linkage between the parent pubic key and private child key is broken. Therefore, the risk of exposing the child and parent private keys is countered.
In the formula for hardened and normal child keys, we are using an index. To generate more than one child key from a certain parent key, an index is very useful to keep things in order. The index is defined as a 32-bit integer. Just like how we distinguish private and public extended keys using prefixes xprv and xpub, we use different ranges of indexes for hardened and normal child keys:
With all the concepts of keys in mind, let's move on to the key derivation process. Instead of solely using one key, both private and public keys are used in extension with an extra 256 bits of entropy. With all CDKs in place, the key tree can be built. Building the key tree takes on the following process:
The keys are in the format of 256 bits, while there are 2 possible extended keypairs in total. Because of security considerations, master keys won't be generated, but are generated from seed values instead.
Having a tree of key pairs, the structure of a wallet can be imposed on the tree. The default wallet layout is defined like so:
HD wallets support a lot of use cases, for example:
When it's for accounting and auditing purposes, accountants or auditors need to read the history of transactions. For accessing the transactions, wallet owners can generate the public keys at the hierarchical level needed. In terms of access control, the owner of the HD wallet will have the flexibility to determine how much ether others can spend by designing the hierarchy of the wallet.
For implementations, there are quite a few packages in different languages. We are only listing a few here for reference:
| Language | Library Name |
| C ++ | mSIGNA: https://github.com/ciphrex/mSIGNA |
| Go | btcutil: https://github.com/btcsuite/btcutil go-hdwallet: https://github.com/wemeetagain/go-hdwallet |
| Java | supernode: https://github.com/bitsofproof/supernode bushido-java-core: https://github.com/bushidowallet/bushido-java-core |
| Python | pycoin: https://github.com/richardkiss/pycoin bip32utils 0.3.post4: https://pypi.org/project/bip32utils/ |
| Ruby | money-tree: https://github.com/GemHQ/money-tree |
You can extend your reading to the wiki page of this standard: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
If you have been doing extra reading upon BIP 32, you will have noticed a picture of key derivation, which can be found here. In this picture, the master node at depth 0 has a notation of m. At depth 1, wallets have notations such as m/0, m/1, and so on. And for depth 2, wallets have notations such as m/0/0, m/0/1, ..., m/i/0, and m/i/1.
This is another convention for keys in HD wallets. All keys are formatted like a path. It's defined as follows:
The last digit of the path describes which one is the child of the parent, and the rest of path is the parent. You may also see keys such as M/1/0, this means it's a public key. Public keys starts with an uppercase M while private keys start with a lowercase m.
We know one parent extended key can have more than one child key and that the upper limit of numbers of child keys is about 4 billion—2 billion of each hardened and normal child keys. Therefore, the entire tree of HD wallets that are described in BIP-32 can end up being very deep and wide. To reduce the degrees of freedom that BIP-32 offers, BIP-43 and BIP-44 were introduced to further standardize the structure of the tree of HD wallets.
In this article, we learn about Ethereum digital wallet. We started off by explaining the role of a digital wallet in a DeFi application as well as differences between deterministic and non-deterministic methods for key generation. Then, we moved on by reviewing Ethereum standards for digital wallet creation and management. For the remainder of this article, we focused on HD wallet or standard BIP-32 by explaining how to derive a tree of keypairs and wallet structure for Ethereum HD wallets.
Here is a list of resources for learning more about blockchain development with Ethereum:
You can also learn more about Alibaba Cloud's Blockchain as a Service offering at https://www.alibabacloud.com/product/baas
Matt Zand is a serial entrepreneur and the founder of 4 tech startups: DC Web Makers, Hash Flow, Coding Bootcamps and High School Technology Services. He is a leading author of Hands-on Smart Contract Development with Hyperledger Fabric book by O'Reilly Media. He has written more than 100 technical articles and tutorials on blockchain development for Hyperledger, Ethereum and Corda R3 platforms at sites such as IBM, SAP, Alibaba Cloud, Hyperledger, The Linux Foundation, and more. At Hash Flow, he leads a team of blockchain experts for consulting and deploying enterprise decentralized applications. As chief architect, he has designed and developed blockchain courses and training programs for Coding Bootcamps. He has a master's degree in business management from the University of Maryland. Prior to blockchain development and consulting, he worked as senior web and mobile App developer and consultant, investor, business advisor for a few startup companies. You can connect with him on LinkedIn
Brian Wu is an advisor at Hash Flow. He has written 7 books related to blockchain. Visit his Amazon author profile page to learn more: https://www.amazon.com/Xun-Brian-Wu/e/B07MK53PYN/
Alibaba Cloud Further Expands its Asia Footprint with First Data Center in the Philippines
2,599 posts | 764 followers
FollowAlibaba Clouder - March 6, 2017
Alibaba Cloud Community - November 3, 2022
Alibaba Clouder - December 21, 2020
Alibaba Clouder - July 26, 2021
Alibaba Cloud Blockchain Service Team - May 5, 2019
Wei Kuo - August 30, 2019
2,599 posts | 764 followers
Follow
LedgerDB
A ledger database that provides powerful data audit capabilities.
Learn More
Blockchain as a Service
BaaS provides an enterprise-level platform service based on leading blockchain technologies, which helps you build a trusted cloud infrastructure.
Learn More
Digital Marketing Solution
Transform your business into a customer-centric brand while keeping marketing campaigns cost effective.
Learn More
Digital Credit Lending Solution
This built-in AI solution allows Financial Institutions (FIs) to dynamically develop, train, and deploy credit risk and fraud risk models to decide digital lending applications in real-time and control risks.
Learn MoreMore Posts by Alibaba Clouder
