The Network has a utility token which allows for the exchange of storage, bandwidth and compute resource between node operators and users wishing to store data on the Network.
It's the financial incentive for node operators to join the Network and cooperate toward the goal of providing secure data storage. Conceptually this is similar to that of Bitcoin: to ensure that cooperative participation is a more rational course of action than uncooperative or malicious activity.
Tokens can also be transferred directly between users and used as a means to pay third parties for goods and services.
When a user of the Network requests a file, it uses the data map (which may be held locally or stored somewhere on the network) to identify the component chunks. It then asks the Network for those chunks and the requests are routed automatically to the nodes that hold them. Those nodes then return the chunks and the client uses the data map to decrypt them and piece them back together to recreate the file.
Data storage on Autonomi is paid for using the transfers described above.
As a recap, before data is stored on the Network, it is broken into chunks and encrypted. Each chunk has a unique hash value from which its XOR Network address is derived.
Nodes also have a unique Network address. Data is stored on the nodes which have the closest Network address to the data itself. This is why we say data is content-addressable.
A client can get the nodes that are closest to a chunk’s address by querying the network. Once it knows the closest nodes, it performs a ‘store cost’ query to ask the price for holding data at that location. The price depends on the storage capacity of the nodes, which ultimately depends on demand.
Once the client knows the store costs offered by the closest nodes, it picks one and sends the data along with the transfer paying for it. Upon receiving the data, the chosen node verifies the transfer, take the payment, verifies the data itself and stores it. It is then replicated to the other close nodes.
There is no charge for downloading data, but uploaders must pay a one-time fee to pay for storage. Once data is paid for it remains stored and accessible to it's owner for the lifetime of the Network.
Data payments are split in two parts:
85% is paid to node operators as a Resource Supply Reward
15% is remitted as Network Royalties
When receiving data payments, nodes make sure that both their payment and Network royalties are valid before storing the data.
All of this is done automatically when the user uploads data using the CLI, or an app.
Sometimes the store cost accepted by the client changes between receiving a quote and uploading the chunk, in which case the client pays the difference.
Nodes cannot manipulate the store cost themselves. The price is purely a function of their fullness. To receive payment a node needs to store new data and already have all the existing data in its range.
Let us first understand how basic transfers work. Everyone on the Autonomi Network, both clients (wallet apps, the CLI, etc) and nodes (data storage) has a public/private keypair.
The public key is used to receive tokens. It is equivalent to bitcoin or ethereum addresses. The private key (secret key) is used to sign transactions and prove ownership of money.
This is what a public key looks like:
93d01b3c6c0d41c4e50c855c753f906ba478f97a838415e6d74615a4b037a7101e724f935727bbf23d17293ab74a3027
Money in a wallet is stored as CashNotes
. These are like a cheque, or a digital bearer certificate, for a given value. They contain all the necessary information for the owner to spend the value in them.
Unlike cash, CashNotes
have owners; they have no value for anyone else as they are useless without the private key. Also they need to be ‘reissued’ to a payee before they can be spent. This is to prevent double-spend.
In summary, CashNotes provide a quick, safe, flexible way to make payments that is compatible with multisig/threshold signature cryptography and can be used online and eventually offline. They simplify many aspects of the Network economy and remove the need for section wallets or similar mechanisms to manage token transfers.
Here’s how they work in practice. When someone wants to send money, they create a ‘transaction’ whereby they spend their own CashNotes
in exchange for new CashNotes
that are owned by the recipient.
Since those CashNotes
contain secrets that might affect the privacy of the sender and the recipient (e.g. their public key), they are never sent or stored on the Network. Instead, the sender creates ‘CashNoteRedemptions’, small files that contain the minimum information that the recipient needs to verify the transaction and re-create their own CashNote on their side.
CashNoteRedemptions are encrypted and packed into a transfer which is sent directly to the recipient. The recipient of the transfer can then decrypt it using their secret key, verify and rebuild the CashNotes, before adding them to their wallet. At that point, the transfer is complete!
You can send a transfer with:
safe wallet send <amount> <to [public_key]>
Example:
This will print the encrypted transfer which can be published or sent directly to the recipient.
They can receive it with: safe wallet receive <transfer>
When data is paid for, transaction information is stored on the Network in ‘spends’. These contain the transaction plus all its inputs and outputs.
To audit and check against possible double-spend, clients can trace a spend's history and locate all subsequent spends recursively to build a directed acyclic graph (DAG).
Spends could be for Data Payments, or direct transfers between users, or 3rd parties. For the purposes of everyday payments, users need only check the parents of each spend. However, transactions can be traced all the way back to the Genesis or emission event using the DAG, if required. You can audit the entire token supply in this way, should you choose to.