Pattern design and updates

Vector node — Core concepts

Published in

Tangram

5 min readMar 6, 2020

In this article we will highlight some further details of the Tangram implementation. An important design pattern in Tangram will be highlighted, and some core concepts covered.

Clients (wallets) vs. Nodes

Firstly; wallets are independent of nodes in that they do not share secret keys with a node.

Nodes

Store the complete (full node) or partial (until synchronisation takes place) distributed ledger data and serve the network (other nodes with any requested available data);
Receive new transactions;
Can be either a Validating node participating within the consensus, or a Surrogate (basic) node which listens to all transactions and propagates;
Verify and cement all transactions (if Validator).
Do not have access to a wallet’s private keys, (no link) and therefore is unable to view the contents of the wallet (transaction history and amount);

Wallets

Are privy to only their own coins;
Connect and Interact with nodes;
Do not allow nodes to access their private keys;
Send and receive online and / or offline messages and transactions.

Session Initiation Protocol (SIP)

Here we describe how the Session Initial Protocol (SIP) is utilised in Tangram, however, SIP has been around since the 90’s. SIP is a signalling protocol used for initiating, maintaining, and terminating real-time sessions, and can be with UDP and TCP protocols.

For every Tangram node which sends transaction(s), a SIP service is initiated and maintained. Once a node sends transaction(s), the SIP manages the session and communication of these transactions to hand-over the payload to a Boost Graph service. SIP provides Tangram a layer of reliability that messages and transactions will be delivered.

Boost Graph(s), Coin hash(s), and Job Actor

The BoostGraph service(s) can consist of many coin hash’s (more on coin hash’s below). A BoostGraph service in the context of Tangram, provides the service to verify, validate and proceeds with the rounds of consensus.

A transaction in this context is described as a ‘coin hash’ or a string of coin hash’s where each coin hash may differ in value. Each coin hash needs a BoostGraph service to process the transaction which in turn triggers state changes (see JobActor).

Job Actor

The role of job actor(s) in Tangram is to monitor, report and *act* on state changes within the consensus based on the validation and decisions coming from the Boost Graph(s) component.

As a refresher (see transition in link) state transitions are:

Pre-prepare > Prepare: The node who first proposed a new block broadcasts a pre-prepare to all other nodes within their membership.Prepare > Commit: When a node receives its corresponding pre-prepare, it begins to broadcast prepare, which includes the contents of the pre-prepare and prepare messages.Pre-prepare > Prepare > Commit: Nodes await prepare messages, and once received with its set conditions and correct views, the node will begin to broadcast commit.Prepare > Commit: Nodes await commit messages, and once received, the node can then be committed to the position that the nodes agree upon, and continue to participate in the protocol

Broadcast Service, Members (+nodes)

In the Broadcast Service, nodes simply perform the gossip protocol propagation: they accept transactions from JobActor(s) that are valid and broadcast to all members in their membership list.

Bird’s-eye view of the life-cycle

Consolidating all of the above information provides a more complete picture of a transaction’s life-cycle in Tangram.

Hopefully this has provided some further education and context for some of the core concepts of Vector (Tangram’s node code).

Roadmap Updates

Docker Container(s)

Currently the way to build-and-run-a-node on Tangram (Vector) as quoted by a member “feels like you’ve just run a marathon”. To this end we are in the process of creating a Docker Container setup which should greatly simplify the process for everyone. This process has five main components which collaborate and provide a service, and development is currently underway.

Many existing Dockerfiles have been produced, the existing ones updated, and the containers are currently building as expected. TGMGateway, OnionAPI and MessagepoolAPI containers have been tested and are building and running as they should.

Along the way and as a final result, basic ‘how-to’ reference notes and descriptions of the process of building, configuring and running the containers using docker-compose have been and are being included.

A few problems have been identified as preventing seamless build and running of the docker-containers - these are currently being debugged. Once done, testing of the documentation will proceed to help those wanting to run locally in a docker-compose arrangement. Furthermore a conversion to a K8S configuration and testing will commence once the the docker-compose arrangement has been finalised.

Once this is complete, we will review whether or not we think it’s a simple enough process for non-techies, or whether we’d need to go further and look at providing a single Dockerfile in which all five processes build and run.