Pattern design and updates
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.
- 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);
- 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
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
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)
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).
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.
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.
Updates to Tangram’s whitepaper are being made throughout this month, and a full publish will be announced once the changes are complete.
A full update on test-net2 will be provided in the coming weeks to describe its design, functions and protocol analysis.
If you’re interested, have questions and feedback:
Visit the repo: https://github.com/tangramproject
Visit the website: www.tangrams.io
Read the blog: www.medium.com/@tangramd
Join the forum: forum.tangrams.io
Subscribe on Reddit: www.reddit.com/r/Tangrams
Discover on Discord: www.discord.tangrams.io
Message on Telegram: https://t.me/Tangrams
Follow on Twitter: www.twitter.com/tangram
Watch YouTube: https://www.youtube.com/channel/UCoe5hPG_zjltaG_j2n1Oh4Q