Pattern design and updates

Vector node — Core concepts

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.

Session Initiation Protocol

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 ).

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

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.

Broadcast Service, Members ( +nodes)

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.