Part 7, sadly we are approaching the end of the series (for now) on how the block lattice operates, so we have one final thought on how it deals with resolving transactions, double spending and forks in the blockchain. Thank you for joining me on this review and I’m sure more episodes will be added in future.
Index
- Part 1: Introduction
(https://steemit.com/blockchain/@iwan.spillebeen/bockchain-decrypted-the-block-lattice-introduction) - Part 2: In depth
(https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-in-depth) - Part 3: Adaptability / Scalability
(https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-adaptability) - Part 4: Attack Potential
(https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-attack-potential) - Part 5: Block Lattice Visualisation
(https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-visualisation) - Part 6: Network Flooding
(https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-network-flooding) - Part 7: Resolving Forks
(https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-resolving-forks)
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 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).
Which brings us to the topic of Sybil attacks, bad actors and network forking.
Sybil Attacks
In brief, a Sybil attack is a person creating a lot of nodes on the network, possibly thousands on a single machine, and using these in order to get a disproportionate vote on networks; where each node gets an equal vote in order to control the voting power of the network and as such the network itself.
Bad Actors
Normally, nodes balance transfers without ambiguity and without contention, since only the owner/signing key is responsible for each chain and since the specifications require the owner to pick a linear order for entries to the chain; which cannot be achieved in traditional blockchains (their architecture isn’t created to support this).
Next to this, there is no guarantee that the account owner will follow the specifications due to either poor programming or due to malicious intent.
Such practices, be they intentional or accidental, will always result in a fork of the network. With a fork in this case we mean a break in the single linked list nature of the chain in question. We don’t mean a hard fork which relates to upgrading of the blockchain technology that usually results in a coin being duplicated.
Resolving Forks
Basics
Depending on the order these blocks were received by the network, they could have conflicting views of the account state (remember this is asynchronous)
• The network is designed so that all nodes resolve the forks to a single branch
• Losing branches will be rolled back and deleted
• This also means removing all dependent blocks in any chain in the system
• This means accounts receiving balances must allow adequate time for confirmation or risk having their chain rolled back
In reality this is a maximum of 4 voting periods, 15 seconds maximum each, at which time the network corrects itself (a critical mass of nodes will have decided on a single branch and the decision won’t be undone).
Identification
Fork identification is very fast (one network echo period), by virtue of the fact that all nodes flood the network with any transaction they accept.
A receiving account trying to get a block confirmed simply needs to wait several network echo periods to see if there is a conflicting block announcement from anywhere in the network.
If they see a conflict they need to wait longer until resolution has completed before re-evaluating if they want to accept the balance; with a maximum of 4 voting periods or 4x15 seconds.
A receiver can continue interacting with other accounts while they wait for this resolution since chains act asynchronously; in other words, each node can continue to send and receive transactions, while a particular transaction is being resolved by the network.
Resolution
The whole network performs arbitration in a distributed fashion, as a balance weighted vote on which branch of a fork to accept. As such, each node that controls an account with a balance evaluates the tally of votes it has seen and changes its vote to the entry with the highest vote total
• If the tally is positive, the node will vote positive and vice versa
• Periodically each node broadcasts its vote until the end of the resolution period
Using balance weighted voting allows nodes to identify quorum and makes sure only interested parties are voting.
Lastly, it is interesting to note that due to the structure and underlying principles and technology described in the past 7 chapters, there is virtually no limit to the number of transactions that can be processed by the network.
While testing is still taking place and results are still being compiled, stress tests have already been executed by users of the network with remarkably high results. For one example of such a stress test performed by Brian Pugh, please visit the following link: https://medium.com/@bnp117/stress-testing-the-raiblocks-network-part-ii-def83653b21f
You can see these tests in action right here:
https://gfycat.com/gifs/detail/sandyagitatedgermanpinscher
https://gfycat.com/gifs/detail/remarkableyellowamericancicada
Conclusion
I believe the block lattice to be a next step in blockchain technology, vastly embracing and dramatically improving on what Bitcoin and The Blockchain has offered to the world. This technology has the potential to become a very big part of everyone’s daily lives, depending on the use cases that are being developed based on the block lattice, I for one can think of a myriad (and I'm working on a few at BlockchainLabs.ai).
My thanks to the Nano / Raiblocks / XRB / Block lattice team for giving us such a fantastic piece of technology!
Having said that, there has - unfortunately - been quite a bit of bad news surrounding Nano/XRB (which is the cryptocurrency that uses the block lattice, we will expand on this in a separate episode : Nano - Controversies
Artwork:
• Page header / footer "Colorful abstract banners set" Designed by Creative_hat / Freepik
Other references:
- https://medium.com/@yourcryptomarketing/Nano-the-future-of-bockchain-architecture-no-fees-and-unlimited-scalability-for-all-b2c51a0d80a7
- https://www.reddit.com/user/meor
- https://www.forbes.com/sites/louiscolumbus/2016/11/27/roundup-of-internet-of-things-forecasts-and-market-estimates-2016/#54bb8ea9292d
- https://github.com/clemahieu/Nano/wiki/Double-spending-and-confirmation
- https://github.com/clemahieu/Nano/wiki/Representatives-and-decentralization
- https://Nano.net/page/resources.php#devtools
- https://en.wikipedia.org/wiki/Steganography
- https://hackernoon.com/iota-vs-Nano-413679bb4c3e
- https://github.com/clemahieu/Nano/wiki/Distribution,-Mining-and-Units
- https://github.com/clemahieu/Nano/wiki/Roadmap
- https://github.com/clemahieu/Nano/wiki/Attacks
- https://hackernoon.com/visualizing-how-Nano-works-8c70678ef082
- https://medium.com/@bnp117/stress-testing-the-raiblocks-network-part-ii-def83653b21f
Contact me
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: iwan@blockchainlabs.ai
CryptoPub/ToshiTimes: https://forum.toshitimes.com/u/iwan.spillebeen
Sponsoring
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:
- Ethereum / Ether: 0x6E2a1f9baD495B894A2c6F8240918620F899f4E2
- Nano / XRB: xrb_1xxzi1o9ywinusod35dcun6ku385i33bohhh8hpap76fh67fgnxg1m3qm9mb
Disclaimer
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.
