Oct 24, 2019
Vector Update — Preparing for Phase 2 (Run a node).
To learn more, visit https://github.com/tangramproject/Tangram.Vector
More than a couple of weeks ago, we open-sourced the Tangram Node code. During that release, we said that users would be able to run their own Tangram Node within a week — this has obviously not been the case. This was due to the fact that Tor was already integrated with the test-net, which caused difficulties debugging the network and after some last test realised that by enabling users to run a node would do little in the advancement of the network and testing.
After several fixes and de-coupling Tor from the network layer, we were able to identify, test and integrate much needed network changes and additions that allows for a more robust networking and consensus layer. However this process took valuable time, hence the delay.
Before we announce and release the code for running a node a some bugs, optimisations are needed to ensure we dont waste anyone’s time when setting up and starting to become familiar with joining the network etc … Please see below under ‘Update on tracking development progress and updates’ for these “issues”.
Major Features
There have been a number of bug fixes, features, refactors and other changes shipped as a part of Vector release — run a node. Here is an overview of the major changes:
Job queue
1. Started state: Intialise job;
2. Queued state: Initiates when a block receives a reply;
3. Dead state: When a block has not received a reply;
4. Dialing state: When a node tries to download missing blocks;
5. Answered state: When a node finishes downloading missing blocks;
6. Blockmania state: When blocks are locked in for that round;
7. Running state: When a block has been handed off to the block DAG;
8. Polished state: When a block reaches consensus;
9. ViewChange state: Awaiting a block if timeout was reached.
Micro Services
Below services can be found here:
Describing each micro-service:
Coin.API— Handles the block DAG consensus algorithm. Validates rules and stores blocks;Membership.API— Scalable Weakly-consistent Infection-style Process Group Membership Protocol;MessagePool.API— Stores and routes messages on the network;Onion.API— Configures and runs Tor (to be enabled at a later stage). Signs member messages for verification;TGMGateway— Controls the entry and flow to each downstream micro service.
Wallet Updates
- Changed framework from .NET Core 2.2 to .NET Core 3.0
Bugs We Know Of
Community members and individuals who are following the project may find known bugs in the link below. This list is likely to grow as time goes on and once Phase 2 (running a node) is released.
Optimizations and Enhancements
The current issues highlighted in the link below are segmented into two parts and will be extended and expanded upon as time goes on:
- Enhancements for which are new requests or features which are planned to be developed and integrated and;
- Optimizations such as automatically starting micro-services so that developers and users do not have to manually start-up each micro-service.
It is important to understand the effort and impact that each optimization and enhancement will have in a set matrix, namely for users (usability and quality of life), technical (network, consensus and the overall ecosystem) and time (effort and the complexity of the solution). Understanding these three verticals allows us to triage and define the progression of an enhancement and optimization “issue” through the life-cycle of development and release.
Notable Update
One of the areas we wanted to touch-base on was the de-coupling of Tor from the network layer. We have concluded that adopting Tor on the network layer this early in development and prior to sufficient testing of the core protocol was a mistake, and exponentially decreased the efficiency and rate of issue identfication and optimisation on the network layer. De-coupling Tor has provided the following benefits:
- Enabled investigation of issues which wasn’t readily achievable while running nodes and clients over Tor;
- Allowed us to identify errors and enhancements and then come up with solutions to handle timeouts, dead communications and refused connections. (In some areas false-positives were received under certain states etc. …);
- Exponentially increase the rate of development (described above);
- An overall better networking scope.
While we would prefer to have Tor integrated as soon as possible, as mentioned, we believe this is something Tangram can only take on once known and unknown bugs, enhancements and optimizations have been identified, correctly scoped, researched, developed and released. Once the network is in a consistent state that the community feels comfortable with, R&D will take place in order to identify the best solution for enabling anonymous communication over Tangram’s network. I.e. — Tor, I2P, Katzenpost, etc.
Development Updates
We have now been able to identify bottlenecks and network issues that may otherwise may not have been found, or eventually perhaps; but definitely at a much slower rate. A list of commits related to this release can be found here:
If you are willing, we urge you to take a look at the commits to identify minor and major updates.
Update on tracking development progress and updates
Moving forward, in order for the community to track progress and release updates that are specific to development. Community members are able to follow the status and completion % of both node code and wallet code here:
Node:
Wallet:
If you’re interested, have questions and feedback:
Visit our website: www.tangrams.io
Read our blog: www.medium.com/@tangramd
Subscribe on Reddit: www.reddit.com/r/Tangrams
Discover us on Discord: www.discord.tangrams.io
Message us on Telegram: https://t.me/Tangrams
Follow us on Twitter: www.twitter.com/tangram
Watch on YouTube: https://www.youtube.com/channel/UCoe5hPG_zjltaG_j2n1Oh4Q
