Nano How 3: Light Wallets – Nano
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.
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.
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)
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.
Published at Sat, 04 Jan 2020 18:01:47 +0000
{flickr|100|campaign}
