Nano How 3: Light Wallets
Tl;dr: Light wallets provide an easy way for users to send and receive Nano, instead of having to maintain a full node. A light wallet holds your private key and communicates with a full node that the wallet provider runs. To receive transactions, it pulls pending blocks and creates corresponding receive blocks; to send, it generates send blocks and pushes these to the full node. The node then broadcasts blocks to the network.
Disclaimer
This article does not mention any specific light wallets for Nano, and how they compare against each other. We however invite all developers and wallet providers to discuss their implementation details through our guest article submission process.
History
In the early Nano days when it was known as Raiblocks, the only option was to run and maintain a full node which was difficult for many users, cumbersome to access remotely, and had an initial setup time due to having to download the entire ledger.
Work began in late 2017 to bring the community some light wallets to ease the process of using the network for its basic functionalities of sending and receiving transactions. Since then, there is now a multitude of robust and fully-featured wallets available to choose from, for your phone, desktop, or browser, and some of them cross-platform.
The Basics
Due to being a distributed ledger, it is possible to interact with the Nano network from different wallets. The private keys and seeds are transferable. This means that if your favorite wallet is down for maintenance you can use another one.
Generating a private key, public key and account address
As we learned in a previous article, a seed generates pairs of private-public keys, and public keys are directly linked to account addresses.
The first step for any light wallet is to generate the user’s keys. This can be either in the form of new keys, from a random seed, or the user’s previous keys from a specific seed that the user provides. In this case, usually the first few accounts that can be generated are checked to see if they have been previously used. These are the ones presented to the user so it can interact with them.
From the seed, the light wallet derives a private-public key pair and the corresponding account. The private key is stored internally, so that it can be used to sign blocks.
Receiving Transactions
Every light wallet has a full node attached to it. The light wallet server uses the node to discover new pending blocks that were sent to one of the user’s accounts. Upon seeing one of these blocks, the wallet then creates a receive block (see this article for details on that) and signs it with the stored private key for the receiving account. Finally, the work is added and the block is pushed to the node to be published on the network. Once the block is validated and confirmed, that transaction is shown as received and the account’s balance updated.
Sending Transactions
The main difference between receiving and sending a transaction is that a send is initiated by the user, which enters the destination account and amount. The amount is converted to the appropriate unit (raw) and then to a balance. As seen in this article, one of the necessary fields of a state block is the block hash that precedes it in the account chain (field “previous”). The way the wallet gets this field is by querying the node for the head/frontier block of the account. This is also how the current account balance is obtained.
Similarly to the receive transaction, once the block is created the wallet signs it using the private key, adds the work, and publishes the block to the network using the node.
Work
It is important to note that the work value for a block can be added after it has been signed. As such, the wallet provider can decide what is the best way to obtain it. The options can be summarized in three categories:
- The user’s computer itself generates the work (local work)
- The wallet provider generates the work (remote work)
- The wallet requests work from another service (distributed remote work, for example DPoW)
Security Concepts
Because using a light wallet involves relying on a third party server to interact with the network, the most important issue concerns security. There are some techniques facilitated by wallet providers to improve security.
When sensitive data, such as a private keys, have to be stored remotely, they should always be securely encrypted with a user password. Remember to use a strong, unique password. 2-factor authentication can add additional security in case the password has been leaked.
In many light wallets, the sensitive data is stored only locally in the user’s computer, phone or browser cache. The disadvantage with this approach is that if you clear your cache or configuration of the wallet, you will need to re-enter your seed or import the wallet in some other way. In these wallets, block creation and signing usually happens locally and natively, such that the wallet provider server never sees the user’s private keys.
Any opinions expressed by the Guest writer are their’s alone, and do not necessarily reflect the views of the Nano Foundation (NF), its officers or employees. Any links to third party sites are for information only, and may offer commercial or financial services or products which may: be subject to additional regulation; or, not lawfully be promoted to you in your jurisdiction. The inclusion of any such link is not an approval, endorsement or guarantee of that website, any information you may obtain from it, or the site’s owner (or their products/services), nor certification that the site is suitable or lawful for you to view or use. NF disclaims any and all liability for the acts, omissions and conduct of any such third parties and Guest writer. YOUR ACCESS TO AND USE OF ANY EXTERNAL SITE IS ENTIRELY AT YOUR OWN RISK.
