Beginner’s guide to Proof of Trust

iCash | 03.06| 499

Trust — it’s one of the promised attributes of the Blockchain. While most have proven useful to ensure trust between parties, not many have addressed the issue of trusting oracle inputs into a Smart Contract. With hopes of wider Blockchain adoption, trust is becoming an increasingly necessary component.

Blockchain and Smart Contracts are fairly secure technologies to store and execute diverse information. An innate, immutable environment without any central authority or intermediary is regarded as the biggest advantage. But not enough attention is paid to the negative impact of incorrect or malicious data.

What happens when a Smart Contract is executed based on manipulated, or faulty inputs and the result is forever recorded to the Blockchain?

iCash’s Proof of Trust Protocol was born from that logical skepticism; to enable real-world inputs to be validated. After a party in the Smart Contract contests an outcome and requires adjudication, the PoT Protocol evaluates and pre-validates the information entered into Smart Contracts to safeguard transactions ranging from a few bitcoin to thousands of them.

Here’s How the Proof-of-Trust Protocol Works

A layer, or stage, of the PoT protocol is added to a Smart Contract. Whenever data input is contested by one of the Smart Contract parties, a decentralized network of qualified participants validate the data before the execution of the contract. Those participants, called Delegates, could be a person, a group, or a company, with the relevant proven experience to provide validation.

To ensure accountability, each Delegate must go through an agreed-upon KYC process. Once on-boarded, Delegates will be able to use a dedicated internal portal to set up open APIs for database query/responses like below. iCash admins may also use this portal to send notifications or inquiries to the Delegate community. With total anonymity to prevent collusion, Delegates stake their iCash tokens and reputation each time they take on contract adjudication.

Delegates are asked to escrow iCash Tokens which are used as collateral in a familiar PoS fashion, but relative to the size of contract that they may adjudicate. For instance, a Delegate that escrowed 100 iCash Tokens when on-boarding may participate in validating a contract worth 1,000 iCash.

What incentivizes the Delegates to take part in the majority consensus is the Reputation reward. Based on the result of voting for each Smart Contract query, a Delegate’s Reputation can either be retained or degraded. Fluctuating Reputation directly impacts financial reward and input capability for future contracts. For example, Delegate 1 in the case below will receive more rewards than others for maintaining the perfect Reputation.

This algorithm also “punishes” a Delegate with the wrong input by lowering his/her reputation score, hence significantly reducing the rewards the Delegate receives. If a Delegate’s reputation score is below 75% then they cannot participate in any validation until certain time and tests have passed.

SuperDelegates, on the other hand, are actors in the PoT network with impeccable reputation by always inputting consensus-driving Smart Contracts determinations with close to one hundred percent accuracy. SuperDelegates have reputations in the highest percentile and they maintain their rank by voting honestly consistently over time. To reach even lower chance of incorrectness, this additional layer would provide indelible majority consensus, and thus be considered valid.

Delegate selection is random, which means it is exploit and collusion resistant. The specific Delegates that will execute the contract will be chosen by a combination of reputation, their escrowed stake, and the chronological order in which they entered. Optimized for gamification, the iCash Delegate selection is similar to the Uber model, in which Delegates are rewarded based on honest behavior.

While many corporations have been searching for opportunities to utilize this new technology, there has been a risk of trust. Automated, immutable processes of Smart Contracts with possibility of loss cannot be trusted, or at least not until the data input is proven trustworthy.

Collective intelligence to assure the validity of Smart Contracts — it’s the perfect solution.

The iCash team

Beginner’s guide to Proof of Trust was originally published in iCash io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Comment 0


Are you sure you want to delete this post?