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 the blocks to the network.
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.
In the early Nano/RaiBlocks days, 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 the 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.
Due to being a distributed ledger, you can interact with the Nano network from different wallets, the private keys or seeds are transferable. This means that if your favourite 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 Nano How, 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 opened. 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.
Every light wallet has a full node attached to it. The light wallet server uses the node to discover new pending send 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 the last Nano How for details on that) and signs it with the stored private key for the receiving account. Finally, the proof of 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.
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 the last Nano How, 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.
Similarly to the receive transaction, once the block is created, the wallet signs it using the private key, adds the proof of work, and pushes the block to the network using the node.
Proof of Work (PoW)
It is important to note that the PoW for a block can be added after it has been signed. As such, it can be left to the wallet provider the best way to obtain this proof. The options can be summarized in three categories:
- The user’s computer itself computes the proof (local PoW)
- The wallet provider server computes the proof (remote PoW)
- The wallet requests the proof from another service (remote PoW, for example DPoW)
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, 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 kept 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 in the wallet itself, natively, such that the wallet provider server never sees the user’s private keys.