Discussing Consensus Protocols: Gems

By lab | January 12, 2018

Overview

Blockchains, and many other types of networks, rely on consensus to process information. Routing protocols such as BGP much come to an agreement on best paths to route network traffic. Blockchains must come to an agreement on the true state of the distributed ledger. Now, even smart contracts must determine the “truthiness” of an transaction in order to validate state.

Why?

In a fully trusted environment where all nodes have all required information, consensus would be easy. Any actor could broadcast information, and all other actors would accept that information as the entire truth. This is not applicable in most instances. Networks are required to consider malicious actors, actors with incorrect information, or actors who are simply incorrect.

Therefore, nodes must analyze and process information received and use potentially complex protocols to decide what do to with received information.

Examples

Cryptocurrency Proof of Work

Blockchain based cryptocurrencies use a digital signature, hashes, and nonces to come to consensus. The sum of this is the “Proof of work”. If the digital signature is valid, and the provided hash works the provided nonce, the transaction is considered valid and distributed throughout the network.

Cryptocurrency Proof of Stake

In a Proof of Stake system, rather than using time consuming mathematical operations to validate transactions, a “voting” type process is used. Participants place some required amount of the currency as a vote. The network as a whole votes to determine whether the transaction is valid. If voter/staker/participant is determine to have behaved maliciously, their stake (currency) is lost.

CAPTCHA

CAPTCHA also use consensus to build truth. Rather than relying on pure mathematical concepts, CAPTCHAs essentially take the input of humans, determine the popularity of a given answer, and consider that to be the truth. E.g. if a picture is shown to 100 people, 98 people say its a car, 2 say it’s a horse, the CAPTCHA system will believe that the picture is a car.

Interesting cases: Gems

The inspiration for this post was initiated after reading the whitepaper for Gems which intends to use an interesting method for reaching consensus on human based microtasks using a Staking type consensus protocol. It peaked some high level questions including one from Vitalik himself.

Problem

Humans who are paid to perform microtasks (think Amazon’s Mechanical Turk), must be incentivized to complete the work accurately and discouraged from acting maliciously. I.e. a human who understands the problem to be solved or a bot which completes work with no thought. In order to validate the completion of a microtask, Mechanical Turk uses a process similar to a CAPTCHA system. Multiple humans complete each task and the popular answer is selected as the “answer”. While this may result in quality answers, there is redundancy and loss of efficiency.

The tasks humans are being asked to perform may be tasks which are challenging for a computer to complete (hence the use of expensive human labor). If a computer cannot perform the task, a computer cannot validate the successful completion of a task or contribute to the consensus.

The Proposed Solution

The Gems whitepaper describes a solution where humans are both incentivized to complete the task successfully and disincentivized to act maliciously (or inaccurately). Workers (or miners) maintain a “reputation” which can be used to decrease the redundancy and validation requirements, improving efficiency.

Requester: a human with a problem to solve. E.g. identify pictures of cars

Miner: a human who will solve the problem. E.g. look at pictures and indicate which are cars

Verifier: a human who will validate the task was completed successfully. E.g. if the pictures identified are actually cars.

How to incentivize

Gems chooses to use both positive and negative incentives for successful completion of a task:

Positive: a token reward for successful completion.

Negative: a required token stake, which is lost if the task is completed incorrectly. (said stake is high enough to pay for the transaction cost, limiting spam style attacks as well)

How to validate

Th role of “Verifier” is filled by miners who have accumulated a high reputation. A verifier also stakes tokens on a task and verifies the task was completely successfully. Rather than requiring large numbers of untrusted miners to complete the same problem, a few miners, and a few verifiers can complete a task is a trusted manner. Verifiers are required to place a stake as well. A verifier’s work is ALSO validated by additional verifiers and the requester.

The verifier’s stake adds an incentive to validate work accurately and properly.

Preventing spam

Requiring a miner to provide a stake prevents spam and malice from a miner, but what about from a requester? To prevent requesters from flooding the platform with malicious tasks, the requester is ALSO required to place a stake, in the form of a prepayment into escrow.

Done

Consensus protocols are interesting, and it is especially cool to see how they can be applied across different domains. I will be following the Gems project closely to see how their implementation plays out.

Note: I am not affiliated in any way with the Gems project or team.