Proof of Trust Consensus Protocol!

Design of A New Blockchain Protocol — Proof of Trust!

No PoW, No PoS. Just Proof of Trust.

I find the terminology of Trustless and Trusted in the blockchain world a bit odd. We seek to create trusted transactions using parties that, apparently, need not be trusted.

That narrative is proving to be troublesome. PoW has caused BTC mining to be concentrated in the hands of a few in China. Even a well designed PoS (Tendermint, Ethereum) is very likely to devolve into a situation of oligopoly as well. That is harmful for trust.

For why specifically PoS and BFT do not really mix, click to check out my two assessments here of Algorand and Hashgraph for example.

In blockchain protocols, even if it may not be in the best self-interest of the blockchain validators to violate trust, it is nevertheless an uncomfortable situation to leave the door open for just that.

This set me thinking, and I got myself and team together to design a new blockchain protocol (TrustChain) with trust baked in.

Briefly, this is how it works:

1. Firstly, we start with the concept of Trust Token(TT). 1 TT is awarded to some (could be all or a random subset) of the validators who contribute to validating a block. TrustToken is not transferable, not mutable by owner, and not usable in any way except as a count for the TrustChain. (This token is not to be confused with rewards for block validation, which is designed to work separately and will be detailed in another post.)
2. Any one with full access to the blockchain data can create a validator node, without needing to put in stake or have tons of hash power.
3. The set of validators is segregated into three parts. Senior, Middle and Junior. To qualify to the Senior block, a validator must have atleast 1000 TT, for the Middle — 350, and for the Junior — 0. (In a variation of the protocol, quantum of TT offered for validation may differ based on seniority.)
4. For every block, 1000 Seniors, 350 Middlers and 150 Juniors will be picked for validation using a pseudorandom self-selection process. The count of nodes required for each generation is called the Minimum Quorum Count (MQC). The total set of validators is called the Quorum. (The Quorum count can later be changed to scale in proportion to the number of transactions processed by the blockchain.). (The partitioning of the Quorum will be based on a VRF function on the timestamp of the validator’s wallet creation time and the TT count in that wallet and the total validator count of the seniority of that validator. This algorithm may change later.)
5. Transactions are gossiped through the network.
6. A small set of proposers will be self-selected from the Quorum for proposing the block.
7. Each Quorum member gets one vote. When at least 2/3rds have voted YES for a transaction, it is added to the block. (We will also have additional constraints based on the seniority of the nodes.). Multiple rounds will be required for validation and block production.
8. Bad validators will be punished by setting their TT to 0.

At the genesis of the TrustChain, the TrustChain Foundation will set up the first batch of (senior, middle, junior) validators with TT=1000, 350, 100 etc who will mine the first blocks and earn rewards till new validators join the Quorum. Simultaneously, fresh validators will be allowed to induct into the system as Juniors, who will have the ability to graduate to Middlers and Seniors as the mining process goes on.

How is it better than Algorand and Hedera?

We will list just a couple of reasons here.

TrustChain is a solution to the problem we observed in Algorand that trying to create a committee based purely on PoS could result in inability to reach minimum quorum count and therefore lose liveness.

TrustChain also does not have a liveness problem like Hedera, where a partitioning of a small set of nodes has an impact on block production. In fact, TrustChain now has the true theoretical failure limit of 33% of validator nodes. This is the solution to the problem we mentioned in the article on Hedera.

In a sense, Algorand and Hedera have the same problem that neither knows how much of the staking money (votes) out there is available for block production.

TrustChain does not have this problem because, being a validator is not based on amount of money but only trust in the form of TrustTokens which can only be earned by being a good player in the system and which cannot be manipulated. The count of Senior, Middler validators is known at all times. Any player with any count of TrustTokens absconding from the system at any point of time has minimal impact on block production due to the fact that this player gets only one vote. By design, less than 33% of such departures are acceptable.

Note: All the numbers provided here, such as the Quorum Count etc may change after implementation and testing. Also, info on forks, sharding, light clients etc will follow in our whitepaper to be released at a later time.

— Cheers! (Rajesh Bhaskar — rajesh@trilloc.com)

(My team and I are working on building TrustChain inspired by Algorand, Hedera and others. This post is a draft version of the Protocol. I have shared this post with Dr Micali and Dr Baird to know their views. Feedback and collaboration from anyone interested is highly appreciated!)

Note to Investors: If you would like to invest in TrustChain, we are open to a small investment.

(+) If you liked this article and would simply consider donating to my independent blockchain research efforts to build TrustChain, please do so to the wallets below:

ETH: 0x058503afffd50303e1e49623c67e8760f50d304d

BTC: 3PrR945zHeTPh7kmUiftUUwmxUV2jkuy4M