Principle and design goals

Technology implementation

Consensus mechanism

All four transaction types have a work field that must be
correctly populated. The work field allows the transaction
creator to compute a nonce such that the hash of the nonce
concatenated with the previous field in receive/send/change
transactions or the account field in an open transaction is
below a certain threshold value. Unlike Bitcoin, the PoW in
Nano is simply used as an anti-spam tool, similar to Hashcash,
and can be computed on the order of seconds [9]. Once a
transaction is sent, the PoW for the subsequent block can
be precomputed since the previous block field is known; this
will make transactions appear instantaneous to an end-user so
long as the time between transactions is greater than the time
required to compute the PoW.

Accounts and transactions

An account is the public-key portion of a digital signature
key-pair. The public-key, also referred to as the address, is
shared with other network participants while the private-key
is kept secret. A digitally signed packet of data ensures that
the contents were approved by the private-key holder. One user
may control many accounts, but only one public address may
exist per account.

Transferring funds from one account to another requires two
transactions: a send deducting the amount from the sender’s

balance and a receive adding the amount to the receiving
account’s balance (Figure 3).
Transferring amounts as separate transactions in the sender’s
and receiver’s accounts serves a few important purposes:
1) Sequencing incoming transfers that are inherently asynchronous.
2) Keeping transactions small to fit in UDP packets.

3) Facilitating ledger pruning by minimizing the data footprint.
4) Isolating settled transactions from unsettled ones.
More than one account transferring to the same destination
account is an asynchronous operation; network latency and
the sending accounts not necessarily being in communication
with each other means there is no universally agreeable way
to know which transaction happened first. Since addition is
associative, the order the inputs are sequenced does not matter,
and hence we simply need a global agreement. This is a key
design component that converts a run-time agreement in to a
design-time agreement. The receiving account has control over
deciding which transfer arrived first and is expressed by the
signed order of the incoming blocks.
If an account wants to make a large transfer that was
received as a set of many small transfers, we want to represent
this in a way that fits within a UDP packet. When a receiving
account sequences input transfers, it keeps a running total of
its account balance so that at any time it has the ability to
transfer any amount with a fixed size transaction. This differs
from the input/output transaction model used by Bitcoin and
other cryptocurrencies.
Some nodes are uninterested in expending resources to store
an account’s full transaction history; they are only interested
in each account’s current balance. When an account makes a

transaction, it encodes its accumulated balance and these nodes
only need to keep track of the latest block, which allows them
to discard historical data while maintaining correctness.
Even with a focus on design-time agreements, there is a
delay window when validating transactions due to identifying
and handling bad actors in the network. Since agreements in
Nano are reached quickly, on the order of milliseconds to
seconds, we can present the user with two familiar categories
of incoming transactions: settled and unsettled. Settled transactions
are transactions where an account has generated receive
blocks. Unsettled transactions have not yet been incorporated
in to the receiver’s cumulative balance. This is a replacement
for the more complex and unfamiliar confirmations metric in
other cryptocurrencies.

Smart contract system

Cryptography

1) Signing Algorithm: Nano uses a modified ED25519
elliptic curve algorithm with Blake2b hashing for all digital
signatures [11]. ED25519 was chosen for fast signing, fast
verification, and high security.
2) Hashing Algorithm: Since the hashing algorithm is only
used to prevent network spam, the algorithm choice is less
important when compared to mining-based cryptocurrencies.
Our implementation uses Blake2b as a digest algorithm against
block contents [12].

3) Key Derivation Function: In the reference wallet, keys
are encrypted by a password and the password is fed through
a key derivation function to protect against ASIC cracking
attempts. Presently Argon2 [13] is the winner of the only
public competition aimed at creating a resilient key derivation
function.

Distributed storage protocol

Cross-chain and exchange technology

Special technology

Economic model and incentive

Governance mechanism

Applications