By lab | January 12, 2018
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.
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.
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 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.
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.
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.
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.