Introduction to XRB Nano (Previously RaiBlocks) Part 8

Validity of blocks on XRB and protection from transaction flooding.

The main difference between XRB Nano/Raiblocks and Bitcoin is that the Bitcoin network has one blockchain into which it records all the transactions.

For a transaction to be valid on the Bitcoin network, it needs at least 6 confirmations. A confirmation on the Bitcoin network means a reference to a transaction by a block of the bitcoin blockchain.

On the XRB Nano/Raiblocks network, each account has its own blockchain, which means that XRB Nano/Raiblocks network has many blockchains. A block on a blockchain of XRB Nano/Raiblocks network is specific to an account and a record about a transaction for that very account.

Transactions on the XRB Nano/Raiblocks networks consist of two parts: sending and receiving. When a user sends funds, the network creates a block on the blockchain of the user’s account. It may be showing the transaction as pending before the receiver completes the part on his or her end, but it doesn’t change anything for the sender because once the sender initiates a transaction, creates a block on the blockchain and sends the funds, the funds are gone even before the receiver confirms them.

For a block on any of the blockchains of XRB Nano/Raiblocks network to be valid, it first needs not already be a part of the XRB Nano/Raiblocks ledger. If a block were to already be a part of the ledger, it would mean that it is a duplicate transaction. Next, the block needs to have a signature with private-key element. This means that only the owner of an account can send funds. Next, the previous block before the next block needs to be the last one on a blockchain. If it is not the last one, it means that a user is attempting to create a fork of the account. Finally, the account must have an open block and create a spam-protecting hash.

If the block is a receiving block, meaning that it represents the incoming funds, the source block needs to have a pending hash. A pending hash is the way for the network to check that the funds have not been redeemed already. For a sending source block, the amount of funds that the block is attempting to send needs to be smaller than the amount of funds in the account (which is the same as the amount of funds in the previous block of account’s blockchain).


Synchronization of bad blocks

A bad block, which is a block that an account or a node did not broadcast correctly, may or may not be a result of an attack. One of the benefits of the XRB Nano/Raiblocks network having multiple blockchains with accounts that only update their own status is that transactions on the network occur asynchronically, meaning that they happen directly between two accounts, without having one blockchain to process and record them in the way it happens on the Bitcoin blockchain. This means that the issue of bad block synchronization won’t affect the entire network when it happens.

When there is a bad block on the network, the network has two options. The first one is to ignore the block as a malicious attempt to change accounts on the network. The second one is to request a resync for this very block.

The XRB Nano/Raiblocks network is about efficiency, which is why its developers chose to make it ignore bad blocks. A node on the network would simply wait for votes from other nodes. If the votes are positive, the node would request a sync connection. If the votes are negative, the node would treat the block as a junk block.


Transaction flooding

The goal of transaction flooding is to saturate the network with fake/spam transactions to prevent legitimate holders of accounts from using the network. One of the reasons why attackers may choose to perform a transaction flooding attack is to drive down the price of the token of a network. Theoretically, with no transaction fees on the XRB Nano/Raiblocks network, the attackers could continue such an attack indefinitely. However, what makes such an attack impossible is the minimal proof-of-work that senders need to do to send a transaction out from an account. While the proof-of-work is minimal for one sender on the network, if an attacker were to try and flood the network with transactions, he or she would need a significant amount of computational resources. Even if the attacker were to succeed with that, the attacker would need accounts with funds in them to initiate transactions, and even he or she were able to have funds in the accounts, certain nodes on the XRB Nano/Raiblocks are not fully historical nodes. These nodes only have a record of the last few blocks for the XRB Nano/Raiblocks accounts. Such nodes can prune old transactions and keep operating without any issues arising from this type of attack.