Qubic: Quorum-based Computations-Powered by IOTA Part-2
Part II - Oracles & quorums
In a perfect world we could just go ahead and have the oracles run our computations. But sadly we live in a world where malicious actors try to take advantage of others, either by influencing their results, or by outright stealing from them if they see an opportunity. So we will need to add extra protection against malicious actors. We will need to be able to trust the computation results, no matter which oracle does the processing.
The way this is done in the Qubic protocol is by forcing quorum consensus. Since we cannot expect every oracle to run all existing qubics and verify all results, like certain block-chain solutions do, we use a quorum to come to consensus on results.
This means that in the Qubic system a group of oracles will combine into an assembly where all members will process the same set of qubics, and each oracle will post its processing results for each qubic on the Tangle. This will allow the qubic owners to determine the quorum consensus of the assembly. If they cannot form a quorum (at least 2/3 of the oracles in the assembly agree on the result) then the results will not be accepted by the qubic owner.
The incentive to be honest in an assembly is the same incentive as the one to become an oracle: the reward offered by the qubic owner. This reward will be distributed to the oracles in the assembly that have produced the quorum result for that qubic. If you come up with a doctored or erroneous dissenting result you will miss out on the rewards. The same goes if you decide not to participate in processing the qubic. No processing means no rewards.
Note that a qubic owner can increase the confidence in the processing results by selecting a larger assembly, or possibly even have the qubic processed by multiple random assemblies. It all depends on the importance of the data and the amount of reward he is willing to spend.
TRUST IN NUMBERS
In distributed computing:
A quorum is the minimum number of votes that a distributed transaction has to obtain in order to be allowed to perform an operation in a distributed system.
This is analogous to the earlier, more familiar usage of the term as it applies to legislative bodies:
A quorum is the minimum number of members of a deliberative assembly (a body that uses parliamentary procedure, such as a legislature) necessary to conduct the business of that group.
In the case of Qubic, the “deliberative assembly” is a specific group of oracles, and the quorum is the minimum percentage of the group’s voting power that must reach consensus for a result to be considered to be valid. Without a quorum, the result is considered to be inconclusive, and therefore invalid.
Qubic uses a quorum to reach consensus on both the input data and the results of computations, e.g., when retrieving data from an oracle assembly, or when processing quorum-based computations. In both cases, which are essentially two sides of the same coin, data are only considered valid when at least 2/3 of all participants agree. Hence the term: Quorum-Based Computations The quorum makes it difficult for malicious actors to falsify data, and lowers the impact of sporadic or unintentionally erroneous data.
Although it may seem wasteful to have multiple devices processing the same computations, it is the only way to maintain a high degree of certainty that data has not been tampered with in a trustless, decentralized system. Importantly, while other protocols expect every network participant to participate in every computation, Qubic only expects oracles in a particular assembly to participate in a given computation. In fact, Qubic even allows for single-oracle assemblies, which means the same protocol may be leveraged in more efficient environments where the operator is trusted, or where the validity of a result is easy to verify.
FORMATION OF AN ASSEMBLY
Oracles may be either trusted or untrusted. Trusted oracles are typically those which are controlled directly by the qubic owner, or those which have gained a reputation of being trustworthy over time. Note that the latter does not allow for a 100% guarantee, but does allow for a high degree of confidence in a known trustworthy oracle.
In the general case, however, most oracles are untrusted by any specific user. An important step in the life-cycle of most oracles is thus to become part of an assembly, which combined with an appropriate incentive structure is the mechanism used to provide trust in an otherwise trustless environment. In particular, the incentive for oracles to stay honest is the promised processing reward, which they will only receive when they deliver the quorum result. It is assumed that most untrusted oracles will therefore perform in the expected way — these oracles are called ‘honest oracles’.
Whether or not we’re dealing solely with trusted oracles will make a difference in how and why we will form our assemblies. Similar to the CAP theorem which deals with distributed data, Qubic enables at most two out of three properties for distributed computation in a given assembly: decentralization, latency, and trust. The following sections explore a few of the most common use cases.
A SINGLE-ORACLE ASSEMBLY
At the low extreme, a single trusted oracle can form its own assembly, consisting of itself as the only member. This model prioritizes latency and trust, at the expense of decentralization. Such an assembly would be useful in two cases:
- to process qubics from qubic owners that trust it completely; or
- to process qubics with results that are expensive to compute, but easy to verify.
One example: a group of sensors from a single manufacturer that themselves require outsourced processing or external input data. In this case, the manufacturer may set up a single trusted oracle machine to process qubics for these sensors. Since the oracle machine has been designed to work together with the sensors, latency can be optimized and the trust factor can be 100%. There is no way for an untrusted oracle to insert itself in this assembly. Also, because there is already an incentive for the oracle to process the qubics (e.g., the manufacturer requires it), the processing reward can be kept at zero.
Other protocols could be used to handle this case, but Qubic offers a standardized and scalable solution. Qubic makes it easy to adding more trusted oracle machines to the assembly when the group of sensors becomes too large for a single machine to process. Additionally, if the sensors themselves already run simple qubics that post their data to the Tangle, Qubic obviates the need for a separate protocol and reduces implementation overhead.
A DUAL-ORACLE ASSEMBLY
In the case where a single-oracle assembly may be used because the operator is known and trusted, it may be advantageous to expand the assembly to include a backup oracle for redundancy.
Taking the example above, suppose the sole oracle machine was malfunctioning, and reported incorrect results due to the malfunction. Since trust was assumed, the accepted result would be incorrect. Adding redundancy would make a defective or malfunctioning machine easier to spot. As long as both oracles achieve quorum, there would be a high degree of confidence in the function of the machines. As soon as only a single result is provided (i.e., one oracle broke down), or worse: conflicting results (i.e., one oracle is malfunctioning), the results immediately become suspect and the system can halt gracefully while a technician is sent out.
To increase redundancy, more oracle machines can be added to the assembly. The system as a whole can keep functioning correctly as long as quorum can be achieved, even in the face of one or more malfunctioning or broken down oracle machines. As this example also depends on a manufacturer-provided incentive and assumes trust in the oracles, again, no rewards are required.
While still prioritizing latency and trust at the expense of decentralization, latency in this case will be less optimal because of the time needed to achieve consensus.
LARGER ASSEMBLIES
Assemblies consisting of more than two untrusted oracles will most likely be the norm, especially for qubics which are processed publicly by unknown operators. This model prioritizes decentralization and trust at the expense of latency. In a large assembly, trust is provided through the incentive system, i.e., rewards.
A naive approach to creating a trustworthy system would be to simply compare the results of each individual oracle. However, the rewards themselves introduce an ulterior incentive: gaming the system to reap more rewards than deserved. There are two obvious ways to do that:
- If rewards or voting power were distributed evenly among oracles (equal parts per oracle), a single oracle could impersonate multiple oracles to conduct a Sybil attack. To prevent this, Qubic requires oracles to participate in a resource test phase before the assembly starts processing qubics.
- If results were posted openly, an oracle could cheat by not doing any processing and simply copy the quorum result that is forming. We call this a classroom attack. To prevent this, results are posted in two steps. Oracles first post a commit transaction that uniquely identifies the oracle and their result, but without giving away the answer. Only later do they post the reveal transaction, which the consumers read to find the results.
