Blockchain Decrypted: The Block Lattice - Visualisation

in #blockchain7 years ago (edited)

Abstract-blue-lights-header 850x105 - chapter 11 - block lattice - 5 visualisation.png

Part 5, it is high time we get visual, here we take a look at how the block lattice actually works from a visual perspective, what is the sequence of a transaction and how well does it all operate together. A long post because of loads of images.

Index Nano logo.jpg

How does the Block Lattice Work?

The block lattice is based on the double entry accounting principle, which is unique in comparison to other blockchains. In order to process a transaction, the user needs to submit a send and a receive transaction and each user has his/her own blockchain (one per node).

Only the node owner can perform transactions on his her own blockchain and the node manages the ledger. The node connects to other nodes over the internet, using IPV6/IPV4 and UDP.

Process in brief

visual 1.png

  • Each transaction is captured in its own block, on the nodes' blockchain (both sender and receiver)
  • When a receiving block is added, the receiving node broadcasts the block back out to the network to announce it has been observed.
  • The node then waits and observes incoming publish and confirm messages to see if any conflicting blocks are published
  • Non-voting nodes will transmit unsigned publish blocks and voting nodes will sign the block with their voting key and publish a confirm message
  • A message is considered confirmed if there are no conflicting blocks and a 50% vote quorum has been reached.
  • If there is a conflicting block the node will wait 4 voting periods (1 minute total, 15 sec/period) and confirm the winning block

Basic transactions

  • The lattice is a set of blockchains per node:
    • Alice
    • Bob
    • Carol
  • Each have their own chain
  • Alice is a voting node
  • Every transaction is 1:1

visual 2.png

  • In order to perform a transaction the node creates a send transaction in its own blockchain (Bob sends to Carol)
    visual 3.png

  • The node also creates an identical receiving transaction which is sent to the recipient chain (Carol receives from Bob)
    visual 4.png

  • Carol’s chain needs to accept the transaction

  • It runs the confirmation procedure

  • It broadcasts the block to the network

  • It waits for network confirmation (check for conflict)

  • A voting block (Alice) will sign with their key and publish a confirm message (50% quorum – 15secs)

visual 5.png

Simultaneous / Asynchronous

In the block lattice, a large number of transactions happens simultaneously

  • Some are asynchronous
    visual 6.png

Example 1

• Carol sends a transaction to Dave

visual 7.png

• Dave sends a transaction to Alice which is instantly received by Alice

visual 8.png

• Dave accepts Carol’s transaction (1)
visual 9.png

Example 2

• Alice sends a transaction to Bob

visual 10.png

• Bob sends a transaction to Carol which is instantly received by Carol
visual 11.png

• Bob sends a transaction to Alice which is accepted by Alice some time later
visual 12.png

• Bob accepts Alice’s transaction (1)
visual 13.png

Start of the Lattice / Genesis

  • Each chain starts with a genesis block, containing the genesis balance
  • The genesis balance is fixed and can never be increased
  • The genesis balance is divided and sent to other accounts who further divide it and sent it to other accounts
  • This provides traceability back to the Genesis block for each account (the sum of all balances of all accounts will never exceed the initial genesis balance)

Now that we’ve outlined the workings of the lattice network, we can look into Network flooding and network echo in more detail, which will be covered in the next two chapters.

Acknowledgements / References

Artwork:

• Title page “Intelligent Solutions” courtesy of http://www.hloom.com/cover-pages/
• Page header / footer “Abstract blue lights” created by Kotkoa - Freepik.com

Other references:

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.

Abstract-blue-lights-footer 850x105 - with copyright.png

Sort:  

Chapter 6 is now available (https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-block-lattice-network-flooding) in which we discuss network flooding and network echo.

Hey there, I'm curios as to what you make of this statement by Dan Larimer of EOS.

"Redefining the Semantics of a Transfer:
What if we redefined the requirements for a valid block to require that each account may receive at most one deposit or one withdraw."

Taken from:
https://steemit.com/blockchain/@dantheman/how-to-process-100m-transfers-second-on-a-single-blockchain

This sounds a lot like the blocklattice that is being described in your article.

I always wondered how he was going to do an asynchronous, highly scalable blockchain. This seems like the likely approach.

Best,

Hi, sorry for the late reply, I've been extremely busy with work for the last couple of weeks. Yes, the structure he describes is exactly how the block lattice operates. Each transaction consists of two pieces, one withdraw transaction and one deposit transactions, and each of these occurs on their respective blockchains so as such there is only one transaction type (deposit or withdraw) per account.

This ties is very closely with tried and tested methods of duel entry accounting (always have a debit and credit in a transaction and neither of these can be in the same ledger). This is one of the most likely ways of achieving a true asynchronous, highly scalable blockchain.

There is a tremendous use potential for this in various fields, I'm currently exploring and working on some that are completely non-crypto related.