Algorithmic consensus distribution

A proposal for an extended distribution model

Tangram
Tangram
5 min readFeb 20, 2020

--

Distribution models are challenging, especially when creating something new. Discussions around the best way to disseminate a new cryptocurrency follow very researchable short and long-term strategies. These strategies usually fall into two categories:

  1. Genesis distribution;
  2. Ongoing distribution.

If we look at mining, ultimately it contributes heavily to two very simple functions;

  1. Network security;
  2. Cryptocurrency distribution.

Is there a way for us to mimic this process then, and obtain both of these functions? Further, can we improve on it? This is a particularly challenging question, and debates between short-term and long-term strategies are forever dynamic.

We (both the Core team and the Community) have spent a lot of time examining and discussing token distribution models for Tangram’s approaching main-net launch. This update is intended to collate some of these discussions and suggestions, and bring everyone up to speed on a potentially improved distribution model which may prove to be permission-less and decentralised.

The original / initial proposed distribution model consisted of two varied distribution methods, namely:

  1. Folding@home
  2. Image Captcha faucet

An overview of these two methods can be found here: https://medium.com/tangram-tgm/tangram-faucet-distribution-economics-overview-72141e9562bf

Over time there have been various comments and tests regarding these two approaches. Some pros and some cons can be demonstrated — a good summary can be found here:

We briefly touched base on the potential for an extended distribution method in the last update: https://medium.com/tangram-tgm/project-and-development-update-96604e6c92b9

Proposed steps

The distribution protocol and process of staking consists of the following steps (assumes honest actor):

  • Participants choose to set up a node and join the Tangram network;
  • Participants who have either purchased and / or managed to gain TGM through a faucet or other method then;
  • Deposit / escrow a minimum amount of TGM where it is then locked;
  • Participants who thus ‘stake’ are considered to be Validators, and are put into a queue to be part of a committee ;
  • In return, upon being selected (Validating nodes who have ‘staked’ attached to them are eligible to be chosen pseudorandomly) to validate a transaction within a consensus round, receive TGM for their participation;

The smart-contract will be tied to a successful validation and consensus round and upon a node broadcasting a commit message for the given transaction. The reward for validating are distributed every ValidatorRewardPeriod (example — once every week.)

  • Participants are then free to hold, use, or transfer the rewarded coins;
  • Validators may halt and exit their stake at any time.

In our community channels we’ve previously touched on potential minimum staking amounts required in order to be eligible for validating. This would help make Tangram more resilient against Sybil attacks, and therefore also reduce power concentration and influence within the network. As an example, mentions of placing a minimum staking amount can be set to 1/1000 of the total token supply so the system can accommodate up to 1, 000 Validators. The staked tokens also being locked for a certain period of time (e.g. >4 weeks) before being unlocked.

Incentive structure

We’ve always believed that incentivising running a node is important to the network’s security, long-term survival, and beyond. Let’s take a look at how one may be incentivised to setup, run, stake, and validate on Tangram:

  1. Fixed reward for Validator per validation (set at a fixed amount — similar to Bitcoin);
  2. Fixed reward distributed equally to all Validators;
  3. A method similar to that used in Ethereum 2.0 where “ validator rewards are proportional to the square root of the total amount of ETH staked”;
  4. Sliding scale of the reward distribution based on number of Validators on the network.

Each of these has its advantages and disadvantages. None of the above adds much real complexity to the effort in implementation since it is all rules-based. However, each differs in issuance rate — some more so than others — thus adding branches and sub-branches of game theory. Modelling can be based on a number of variables depending on the incentive structure highlighted above.

Amongst other things, we have examined the potential composition of a net-positive issuance model, but actual issuance rates are yet to be finalised. This is one of many ongoing discussions within the community.

Common questions regarding the extended distribution model:

FAQs — Proposed Distribution Model

Does that mean Folding@home and / or Image Captcha faucet will no longer be a chosen distribution method?

  • No, this means that possibly there will be a lower percentage of coins being distributed through Folding@home, Image Captcha and /or any type of “human operated” type faucet.

Does this not require some form of smart-contract to be implemented?

  • Yes. Some of you may be aware that smart-contracts are on Tangram’s road-map, however they are planned for a yet-to-be determined time, post main-net launch.

Does this mean we will have to wait for smart-contract to be released before distribution through the new proposal begins?

  • No. If the community agrees that this approach is the best way forward for the network and project, the approach will be built out with a basic smart-contract service that enables the distribution mechanism to take place.

Let us know what you think

The proposed distribution model is very much a work-in-progress, and should be the subject of continued community discussion.

Development update note

It has been pointed out that GitHub updates have slowed down; please note that this was previously advised in some of our channels — for example Pingpong posted this in the Tangram Community Discord:

“GitHub updates will start to slow down as I focus on other parts of Tangram”.

“Other parts” include for example the important integration of the different components of zk-PoS.

Commits

  • Sloth slow timed hash function; [05169c0]

Read more about sloth:

A random zoo: sloth, unicorn, and trx

Other areas which we’ll see deployed soon™️(ish):

  1. akka implementation — “provides a fault-tolerant decentralized peer-to-peer based Cluster Membership Service with no single point of failure or bottleneck”.
  2. Docker Container(s) — Currently the development of having five containers working together harmoniously is in progress. Tangram is very much modularised which makes it easier to isolate and debug individual services when running separate containers. Having separate containers is not as simple as having one container managing all services for non-technical folk. Documentation will be provided. Having Docker for most people will be exponentially more user-friendly than what is currently available.
  3. Documentation — Relevant documentation around the topics are being scheduled to be released to support.

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

--

--

Tangram
Tangram

Tangram was created with a singular vision: to inspire, mobilize and empower a new generation of cypherpunks.