Project and development update

26th January 2020

Published in

Tangram

7 min readJan 26, 2020

This has been a long awaited project and development update. It is also a new year, twice over within a month (unlike our updates), so Happy Chinese New Year! 🐀.

Now a major project alignment piece has been on the front burner for quite some time. We’d like to touch on the following:

What is currently being worked on
Milestones remaining before considering main-net
Update on road-map items
Distribution
How far are we from …

1. What is currently being worked on

In our last update we highlighted the development and integration work being done with zk-PoS. Development is on-going, and the ground-work for zk-PoS has made relatively good progress thus far. By keeping the development work and integration simple we’ve reduced the complexity of the implementation as well as the risk of known and unknown attack vectors commonly seen in PoS consensus.

Highlights of zk-PoS and other interested areas

Some may have noticed the first commit for PoS, providing a lottery system which works with Verifiable Random Functions (VRF). The initial commit has been tested, and some minor adjustments will be required before we move further into development and integration of another piece of the Tangram ‘puzzle’; Verifiable Delay Function (VDF). This function is important to Tangram’s zk-PoS consensus algorithm.

The combination of VRF and VDF provides the ability to pseudo-randomly assign nodes different amounts of time to solve the puzzle(s) needed to validate each transaction, and thus achieve randomness (irrespective of the hardware an individual or entity is running). It also provides the attribute of being very efficient for nodes to verify that a node has indeed solved its assigned puzzle instance.

See #Distribution (below) on how we’re also intending to utilise these functions as part of the distribution, embedded as part of the protocol.

On a side note, in preparation for zk-PoS test-net2 release, we have been seeking supported development work (update: this has been found as of today) to simplify setting up and running a node. Obviously there is no point in having zk-PoS if there isn’t a good amount of nodes running on the network and validating. Therefore this is a high priority outside of core-development. Further updates on this will be made as soon as possible once development work has been verified.

2. Milestones remaining before considering main-net

To keep it simple:

zk-PoS (VDF, VRF, Bulletproof integration, slashing and locking mechanisms);
Squash any bugs that arise;
User experience adjustments and enhancements.

Some enhancements and adjustments to:

Future posts will highlight the proposed rules for slashing and the locking mechanism embedded in Tangram’s zk-PoS. Other posts and updates to the white-paper will discuss where any node can become a validator after placing a lower limit and higher limit stake by a validator to prevent sybil and other attacks.

3. Update on Road Map items

Updates have been made to the #trello_roadmap. The most notable item is for the whitepaper / technical introduction to be updated so that we can bring the community up to speed on all the current technical updates, including what is planned prior to main-net. You may notice that we have planned to release a version of a test-net that includes zk-PoS by the end of Q1. *Currently the release of test-net 2 (zk-PoS) looks to be on schedule at this stage, however it cannot be stressed enough that these estimates are oftentimes overturned due to unforeseen complexity or bugs.

Please continue to bear in mind there is no technical blueprint for what we’re doing.

4. Distribution mechanism (to faucet or not to faucet).

This topic has seen exhaustive discussion since the inception of the project, with no foreseeable end until the distribution mechanism is actually out in the wild, working, and coins are being distributed across the world. From day one our stated intention has been for Tangram to be distributed via free faucets. Originally, the most widely accepted proposed method involved a combination of solving CAPTCHAs of some sorts and using your computer hardware (GPU and / or CPU) for the greater good.

Although we seriously considered all tenable proposals, we deliberately chose not to comment much in the discussions for a plethora of reasons. This unfortunately lead to some conflicted views, and many further public and private discussions.

One of the ideas posted was to embed the distribution mechanism as part of the protocol. After cost/benefit analysis, we deemed this to be the most beneficial to the long-term stability and longevity of the network. (If you have logical evidence and some good arguments against this, please feel free to open a discussion in one of our channels.) Further analysis and discussions will continue on the modelling and coin issuance rate, however ultimately of course this needs to be healthy for the network.

So what’s the plan? On a high-level from day one Tangram has been designed and built to enable building and running applications (that do things, e.g. smart contracts). Due to this, embedding the distribution mechanism will be relatively simple in the context of smart contracts. Thus, when and if you choose to run a node and / or validate transactions you would be rewarded for it. As simple as that.

Just as miners are rewarded for validating in any PoW blockchain (classified as block rewards), and just as in Monero rewards are visible, so will it be in the case of Tangram. Validators will receive a reward (distribution) for their willingness to setup a node, run a node, stake and for random selection to validate a transaction, in that order. One of the main attributes to note for reward issuance per a node validating a transaction is that validators receive a proportional share of the daily distribution rewards. Disclosure of the reward is necessary, but the reward in itself does not give much away to any individual or entity that may be monitoring.

So where does VDF and VRF come into play? Randomness. Validators are selected by random, which means the rewards (distribution) is essentially random. In order to be eligible for distribution, you need to be running a node and willing to validate just as much as you’re willing to solve a CAPTCHA or set up your computer to solve mathematical puzzles. Incentive is built into the protocol.

This update is meant to be high-level, and more discussions on the mechanism, rules and algorithms will continue to be highlighted on our different channels at different times.

This topic is extremely important to the success of Tangram and when the network is in a state where it is ready for main-net launch, the topic of distribution will automatically become the highest priority.

5. How far are we from…

Based on the items discussed in #Milestones remaining before considering main-net

This is obviously a tough one. We’ve been aggressive with dates before and we’ve learnt some lessons a long the way. Traditionally timelines and dates are given in any project, however, traditionally no project has tried to achieve what Tangram wants to achieve. Privacy by default, fee-less, relatively fast (under 10 seconds transaction times — wallet to wallet) while being secure, decentralized and fairly distributed through incentivization for the longevity and stability of the network.

Target date: Tuesday 2020

Let the meme be fate.

Estimates are based on the best of our knowledge and experience but there are many aspects of privacy, DLT development, networking and then some that are impossible to predict because they literally cover uncharted territory.

Our internal schedules still tend to have aggressive dates. This helps to push the team (currently extremely small) to focus and scope their tasks, especially in the case of technical development. Every team needs target dates, so you will see dates adjust (as seen in the past) as we get more accurate information or understanding of what’s needed to be completed.

It is important to understand that in many cases (especially with groundbreaking engineering tasks like this) the complexity and difficulty in testing at both small and large scales can make it very hard to reproduce and isolate bugs. We base our estimates, again, on our experience and understanding on what is to be done, but we also know that it’s possible for a single bug to cause a delay of days or weeks when a hundred others might be fixed almost instantly.

This is the reality of what we’re trying to achieve with the level of support and tools at our disposal.

Community, project and development updates — generally

Updates are scheduled once every 3 weeks from publish. Bi-weekly updates will continue when community, project and technical updates and any other updates come available and are critical and informative.