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,
and 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.
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
• Title page “Intelligent Solutions” courtesy of http://www.hloom.com/cover-pages/
• Page header / footer “Abstract blue lights” created by Kotkoa - Freepik.com
You can contact me here with any questions, suggestions and / or to discuss the topic of this document:
LinkedIn: https://www.linkedin.com/in/iwanspillebeen/
Email: [email protected]
CryptoPub/ToshiTimes: https://thecrypto.pub/u/iwan.spillebeen
I write these papers to - hopefully - help make blockchain more accessible to people new to the technology, I don't get paid, nor sponsored to write these papers. If you absolutely feel inclined to donate something to the writing of this document, you can do so at the following address:
Blockchain – Decrypted is written as a series of chapters, aimed at demystifying the various workings of blockchain technology. Where appropriate I use examples from existing or to-be cryptocurrencies, these examples are just that, examples, and do not aim at promoting or otherwise endorsing any given cryptocurrency.
This document does not constitute legal or financial advice and I do not make any guarantees or promises as to any results that may be obtained from using my content. No one should make any investment decisions without first consulting his or her own financial advisor and conducting his or her own research and due diligence. I disclaim any and all liability in the event any information, commentary, analysis, opinions, advice and/or recommendations prove to be inaccurate, incomplete or unreliable, or result in any investment or other losses.
