The NOS Payment Ecosystem

NOS Distributed Ledgers

The NOS Payment Ecosystem consist of various independent networks for NOS Stablecoins (Nollar, Nound and Neuro) and a decentralized solution which is the NOS Network itself. All networks in the NOS ecosystem provide safe, fast, and free transfer & store of value. It is achieved by aggregating some of the best ideas, innovations, and technologies developed in recent years.

Many of these ideas have already existed in some form, yet nobody has aggregated them into a single ecosystem and reached universal acceptance.

In the following, we will give an overview of the innovations and improvements that The NOS Payment Ecosystem offers.

Free & Instant Transfer

The NOS ecosystem offers feeless and instant value transfer. Based on the innovative architectural design made by Nano called the block-lattice, a distributed infinitely scalable base layer that serves as the underlying foundation of the network.
Contrary to the traditional blockchain which does not scale due to its linear block-structure; the NOS networks have no limit in how many transactions they can handle. The throughput is only limited by individual user bandwidt

Each account has its own blockchain (account-chain) equivalent to the account’s transaction/balance history. Each account-chain can only be updated by the account’s owner; this allows each account-chain to be updated immediately and asynchronously to the rest of the block-lattice, resulting in quick transactions. NOS protocol is extremely light-weight; each transaction fits within the required minimum UDP packet size for being transmitted over the internet. Hardware requirements for nodes are also minimal, since nodes only have to record and rebroadcast blocks for most transactions. The system is initiated with a genesis account containing the genesis balance. The genesis balance is a fixed quantity and can never be increased. The genesis balance is divided and sent to other accounts via send transactions registered on the genesis account-chain. The sum of the balances of all accounts will never exceed the initial genesis balance which gives the system an upper bound on quantity and no ability to increase it.

Transactions

Transactions transferring funds from one account to another requires two transactions: a send deducting the amount from the sender’s 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 NOS 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. (Nano Documentation 30/1/2019).

Network Consensus

Contrary to the traditional blockchain, via a block-lattice, each user has its own blockchain and does a negligible amount of POW via their wallet which takes care of the 1% POW (Proof of Work) component that serves to prevent spam attacks on the network. An additional 99% of the consensus on the decentralized NOS network is achieved via DPOS (Delegated Proof of Stake). A rebroadcasting representative will need around 0.1% of the network voting weight to be able to rebroadcast. Each person that holds a small amount of NOS coins can already delegate their voting weight via their personal wallet to a trusted representative. Optimal decentralization will be reached once a large amount of nodes is set-up among the community as well as enough voting weight is delegated among hundreds of representatives.

Representatives

Representatives are accounts which cast votes in the case of a fork in the network. Account holders who are unable to reliably participate in voting for connectivity reasons can name a representative who can vote with the weight of their balance, but do not otherwise have any access to their funds. Each account may name one representative.

A good representative is a node that has high uptime (so it can vote frequently) and a locally stored wallet containing accounts that other users can delegate to. Maximizing the number and diversity of representatives increases network resiliency. (Nano Documentation 30/1/2019)

Decentralization

Like any other network that has ultimate decentralization on their schedule, the NOS network first starts out as a centralized network that gradually moves towards a censorship resistant, distributed, trustless network that no single entity or group of people can control.

Proof of Work

As an anti-spam measure, each block published to the network must include a valid work value, which is a 64-bit integer (displayed in hex format in block explorers and RPC commands).

The Proof of Work algorithm works by iterating through random 64-bit integers, or "work values". It concatenates the previous block hash (or the account's public key, if the account has no blocks yet) with the work value and runs the concatenated value through a Blake2b hash until the resulting hash exceeds the work_threshold agreed upon by nodes in the network, which is 0xffffffc000000000 as of February 2018.

Proof of Work is not meant to take a long time--it can take as little as 0.2 seconds on average on the fastest GPUs available in early 2018. It is simply meant to prevent abuse of the network. Since every block an account publishes must include work generated from the previous block's hash, an account can send a maximum of 5 transactions per second with high-end hardware (Nano Documentation 30/1/2019)

Attack Vectors

NOS Stablecoins & NOS (XNOS), like all decentralized cryptocurrencies, may be attacked by malicious parties for attempted financial gain or system demise. In this section we outline a few possible attack scenarios, the consequences of such an attack, and how NOS protocol takes preventative measures.

Block Gap Synchronization

In the following paragraph we discuss the scenario where a block may not be properly broadcasted, causing the network to ignore subsequent blocks. If a node observes a block that does not have the referenced previous block, it has two options: 1) Ignore the block as it might be a malicious garbage block. 2) Request a resync with another node. In the case of a resync, a TCP connection must be formed with a bootstrapping node to facilitate the increased amount of traffic a resync requires. However, if the block was actually a bad block, then the resync was unnecessary and needlessly increased traffic on the network. This is a Network Amplification Attack and results in a denial-of-service. To avoid unnecessary resyncing, nodes will wait until a certain threshold of votes have been observed for a potentially malicious block before initiating a connection to a bootstrap node to synchronize. If a block doesn’t receive enough votes it can be assumed to be junk data. (Nano Documentation 30/1/2019)

Transaction Flooding

A malicious entity could send many unnecessary but valid transactions between accounts under its control in an attempt to saturate the network. With no transaction fees they are able to continue this attack indefinitely. However, the PoW required for each transaction limits the transaction rate the malicious entity could generate without significantly investing in computational resources. Even under such an attack in an attempt to inflate the ledger, nodes that are not full historical nodes are able to prune old transactions from their chain; this clamps the storage usage from this type of attack for almost all users. (Nano Documentation 30/1/2019)

Sybil Attack

An entity could create hundreds of RaiBlocks nodes on a single machine; however, since the voting system is weighted based on account balance, adding extra nodes in to the network will not gain an attacker extra votes. Therefore there is no advantage to be gained via a Sybil attack.

Penny-Spend Attack

A penny-spend attack is where an attacker spends infinitesimal quantities to a large number of accounts in order to waste the storage resources of nodes. Block publishing is ratelimited by the PoW, so this limits the creation of accounts and transactions to a certain extent. Nodes that are not full historical nodes can prune accounts below a statistical metric where the account is most likely not a valid account. Finally, RaiBlocks is tuned to use minimal permanent storage space, so space required to store one additional account is proportional to the size of an open block+indexing = 96B+ 32B = 128B. This equates to 1GB being able to store 8 million penny-spend account. If nodes wanted to prune more aggressively, they can calculate a distribution based on access frequency and delegate infrequently used accounts to slower storage. (Nano Documentation 30/1/2019)

Precomputed PoW Attack

Since the owner of an account will be the only entity adding blocks to the account-chain, sequential blocks can be computed, along with their PoW, before being broadcasted to the network. Here the attacker generates a myriad of sequential blocks, each of minimal value, over an extended period of time. At a certain point, the attacker performs a Denial of Service (DoS) by flooding the network with lots of valid transactions, which other nodes will process and echo as quickly as possible. This is an advanced version of the transaction flooding described in Section V-B. Such an attack would only work briefly, but could be used in conjunction with other attacks, such as a >50% Attack (Section V-F) to increase effectiveness. Transaction rate-limiting and other techniques are currently being investigated to mitigate attacks. (Nano Documentation 30/1/2019)

>50% Attack

The metric of consensus for NOS is a balance weighted voting system. If an attacker is able to gain over 50% of the voting strength, they can cause the network to oscillate consensus rendering the system broken. An attacker is able to lower the amount of balance they must forfeit by preventing good nodes from voting through a network DoS. RaiBlocks takes the following measures to prevent such an attack:

  1. The primary defense against this type of attack is voting weight being tied to investment in the system. An account holder is inherently incentivized to maintain the honesty of the system to protect their investment. Attempting to flip the ledger would be destructive to the system as a whole which would destroy their investment.

  2. The cost of this attack is proportional to the market capitalization of NOS. In PoW systems, technology can be invented that gives disproportionate control compared to monetary investment and if the attack is successful, this technology could be repurposed after the attack is complete. With NOS the cost of attacking the system scales with the system itself and if an attack were to be successful the investment in the attack cannot be recovered.

  3. In order to maintain the maximum quorum of voters, the next line of defense is representative voting. Account holders who are unable to reliably participate in voting for connectivity reasons can name a representative who can vote with the weight of their balance. Maximizing the number and diversity of representatives increases network resiliency.

  4. Forks in the NOS networks are never accidental, so nodes can make policy decisions on how to interact with forked blocks. The only time non-attacker accounts are vulnerable to block forks is if they receive a balance from an attacking account. Accounts wanting to be secure from block forks can wait a little or a lot longer before receiving from an account who generated forks or opt to never receive at all. Receivers could also generate separate accounts to use when receiving funds from dubious accounts in order to insulate other accounts.

  5. A final line of defense that has not yet been implemented is block cementing. NOS goes to great lengths to settle block forks quickly via voting. Nodes could be configured to cement blocks, which would prevent them from being rolled back after a certain period of time. The network is sufficiently secured through focusing on fast settling time to prevent ambiguous forks. (Nano Documentation 30/1/2019)

Bootstrap Poisoning

The longer an attacker is able to hold an old private-key with a balance, the higher the probability that balances that existed at that time will not have participating representatives because their balances or representatives have transferred to newer accounts. This means if a node is bootstrapped to an old representation of the network where the attacker has a quorum of voting stake compared to representatives at that point in time, they would be able to oscillate voting decisions to that node. If this new user wanted to interact with anyone besides the attacking node all of their transactions would be denied since they have different head blocks. The net result is nodes can waste the time of new nodes in the network by feeding them bad information. To prevent this, nodes can be paired with an initial database of accounts and known good block heads; this is a replacement for downloading the database all the way back to the genesis block. The closer the download is to being current, the higher the probability of accurately defending against this attack. In the end, this attack is probably no worse than feeding junk data to nodes while bootstrapping, since they wouldn’t be able to transact with anyone who has a contemporary database.

NOS Stablecoins & NOS (XNOS) provide trustless, feeless, low-latency cryptocurrencies that utilize a novel block-lattice structure and delegated Proof of Stake voting.
The networks requires minimal resources, no high-power mining hardware, and can process a high transaction throughput. All of this is achieved by having individual blockchains for each account, eliminating access issues and inefficiencies of a global data-structure.

How to get invited

Joining NOS Initiative is by invitation only.
Here are two simple ways to get invited:

1

Go to NOS Initiative Facebook or Twitter page and see which of your friends already follows Initiative NOS. They may already be registered.

2

Submit a post on social media asking your friends whether one of them can invite you.

Want to learn more?