Part 6, since we’ve explored the inner workings, the scalability, attack potential and took a visual view of how the block lattice operates, it is time to look at what network flooding really means and how this can be visualised.
Nano works around a principle of Network flooding, I.e. it expects all nodes to be aware of all transactions when they occur, in order to do so, a node broadcasts a block it hasn’t seen before to all other nodes in the network that it is aware of. The nodes receiving it do the same (if they hadn’t seen the block previously), etc. until the entire network is aware of the transaction.
This gives the greatest probability of all nodes receiving a copy of all transactions; or at least a probability high enough that 100% does not need to be achieved.
You could argue that a node that just started isn’t aware of a great many nodes, which is correct, but it is always aware of at least two, the node from which it received its first Nano and the node to which it is sending its first Nano. The node to which it is sending may not be connected to the rest of the network but the node from which it received will always be connected to more nodes; so flooding will inevitably happen.
Each node in the network must be aware of the transactions as they occur:
The orange node is the first recipient of the transaction, it has received a transaction from another node which issued both a sender and receiver transaction, at present no other nodes in the network are aware the transaction has occurred (all nodes are uninformed).
Since the node is the recipient, it is now informed of the transaction, it then proceeds to inform all other nodes (that it is aware of) in the network:
Those nodes in turn change into being informed and informed nodes and broadcast to the nodes they are aware of.
The flooding continues,
until all nodes in the network become informed nodes, in reality achieving 51% of the network is sufficient as in due time 100% will be informed.
Based on network flooding, in an ideal situation, each node will receive a duplicate copy of the same transaction at some point, as seen from the example above.
The time between receiving this new transaction the first time and receiving of the last duplicate copy is referred to as the network echo period. This gives a complete view of transactions accepted by all other nodes on the network and this period is probabilistically based on the network latency between nodes.
First time echo received:
Last echoes received:
This allows a node to establish a reasonable bound for itself for the duration of its own network echo. The node can use this to validate how long it should take for its transactions to be known to the entire network for example and to determine for itself when double spending is not an issue.
Quorum / Partitioning
An important property of coming to an agreement is determining quorum or in this case:
• Determining if the network is partitioned
• Determining if the network is preventing a Sybil attack
• Raiblocks/Nano use the Genesis amount to determine normal participation (e.g. quorum)
The Nano network can also limit participation directly to users who have an interest in maintaining the system (voting nodes) and an accounts participation weight is its balance as a percentage of the total supply (Genesis amount).
Remember that the Genesis block carries the Genesis amount, which is split each time a node is added, doubling the genesis amount value of a node will point you to it’s previous node, and so on until you reach genesis. If you can’t reach genesis then the node is invalid.
For more on Sybil attacks, bad actors and forks, see the next chapter: Part 7: Resolving Forks
PART 7 – Resolving Forks
Acknowledgements / References
• Title page “Intelligent Solutions” courtesy of http://www.hloom.com/cover-pages/
• Page header / footer “Abstract blue lights” created by Kotkoa – Freepik.com
Read the original article on Steemit