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.
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.
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.
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.
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).
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 4×15 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.
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:
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
• Page header / footer “Colorful abstract banners set” Designed by Creative_hat / Freepik
Read the original article on Steemit