We use cookies to enhance your browsing experience and analyze our traffic. By clicking "Accept All", you consent to our use of cookies.. View our Privacy Policy for more information.
Your browser (Internet Explorer) is out of date. Please download one of these up-to-date, free and excellent browsers:
For more security speed and comfort.
The download is safe from the vendor's official website.

Blog:

The life cycle of a HUMAN Protocol job — the basics

HUMAN Blog
Fundamentals
HUMAN Protocol
Mar 5, 2021

The life cycle of a HUMAN Protocol job — the basics

2 min read

How does the Protocol work? Here, we outline the most basic application of the Protocol to complete a simple job. We will continue to release articles demonstrating the different possibilities and variations of a job, in the hope that by reforming, exploring, and applying examples, we can facilitate an intuitive understanding of the full power of the network.

We are creating a different kind of decentralized system in which each entity has eyes on the other entities, and the means, through staking and incentives, to penalise them in the case of abuse.

Step one — the Validator

Definition: The Validator is an independent entity which receives a job and safely mediates the actions of all the entities in the network. It is the foremost staking entity in the HUMAN Protocol.

The Validator’s first duty is to download the job manifest and package the job according to the requirements of the chains it will send it to. For example, if the job uses a captcha system, it has to be packaged to fit that use case. This would likely mean: no porn can be in the images, the images are formatted correctly, rotated to face the right way up, as well super fast storage so the link can pop up quickly anywhere across the world.

As it signs off on the job, the Validator stakes HMT to participate in the network by assigning oracles to do the work. The Validator ensures there are no conflicting agreements between the oracles in the network. In a distributed system, the Validators gain trust by staking HMT in a whitelist smart contract which the oracles can access if injured. Each oracle can request a minimum amount to be staked.

The job moves on to the next step and the first oracle network in the sequence — the Exchange.

A note on trust

The three oracles run independently. They do not need to trust each other. They simply translate, store, and pass on data relevant to a job. The Validator has a relationship with each one of the oracles; the security of the network is blanketed by the Validator, which has staked a sum of tokens for the transactions it verifies, as occurring on and through the oracles. Because the Recording Oracles may be located with one server, and the Reputation Oracles with another, we are creating a different kind of decentralized system in which each entity has eyes on the other entities, and the means, through staking and incentives, to penalise them in the case of abuse.

Step two — the Exchange

The notable quality of the Exchange system is that involves human, machine, and blockchain interactions across the Protocol. When the job enters the Exchange, the Exchange can break it down into tasks, and potentially sends it to different exchanges across different chains. It is important to note that the Exchange system has Exchange Oracles; while the Exchange is exchanging human and machine intelligence, the Exchange Oracle, for example, an individual CVAT user, submits answers to the Exchange and thereby performs a blockchain action that processes off chain information into an on-chain order book.

The Exchange passes the job on to various applications. Websites feed the answers back into the Exchange.

Step three — the Recording Oracle

The Recording Oracle makes an intermediate assessment of answer quality relating to the job, which it bases off its withheld ground-truth. The ground-truth is a quantity of correct answers it holds in reserve to judge the current answers against.

The answers continue to feed in. The Recording Oracle sends live feedback to the Exchange relating to answer quality. If the Exchange is feeding back poor answers, the Recording Oracle can notify the Validator, which can withhold further work from that Exchange.

Step four — the Reputation Oracle

The Reputation Oracle analyzes the results from the Recording Oracle and then makes the final assessment of answer quality. The Reputation Oracle has the information required to trigger the release of HMT from the smart contract, and can then deliver that HMT asynchronously over different chains to the workers who have completed the tasks.

Step five — completion

Workers are paid. Users have the answers they want. The Validator and Oracles receive HMT for their role in securing the network.

For the latest updates on HUMAN Protocol, follow us on Twitter or join our community Telegram channel.

Legal Disclaimer

The HUMAN Protocol Foundation makes no representation, warranty, or undertaking, express or implied, as to the accuracy, reliability, completeness, or reasonableness of the information contained here. Any assumptions, opinions, and estimations expressed constitute the HUMAN Protocol Foundation’s judgment as of the time of publishing and are subject to change without notice. Any projection contained within the information presented here is based on a number of assumptions, and there can be no guarantee that any projected outcomes will be achieved.


Guest post