pt.5 The Block Lattice Visualisation

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.


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.

PART 6 – Network Flooding

Acknowledgements / References


• Title page “Intelligent Solutions” courtesy of
• Page header / footer “Abstract blue lights” created by Kotkoa –

Other references:


Read the original article on Steemit