Qubic: Quorum-based Computations — Powered by IOTA Part — 4
Part IV - The Qubic Protocol
The Qubic protocol specifies the construction, execution, and evolutionary life-cycle of qubics. It leverages the IOTA protocol for secure, decentralized communication between the various participants. Additionally, since IOTA has its own built-in payment system, IOTA tokens are used to provide an incentive system for qubic operators. Anyone can decide for themselves at what threshold a reward becomes interesting enough to participate.
Qubic offers a great incentive for people to run nodes: let others use spare computational power or storage capacity, thus providing a useful service, and get paid to do so. Q-nodes can give new life to old, abandoned PCs, and they can provide traditional cryptocurrency miners with a way of monetizing equipment by doing useful computations instead of solving meaningless (and wasteful) cryptographic puzzles.
In the future, Qubic will leverage this world-wide unused computation capacity to solve all kinds of computational problems. Qubic is optimized for IoT — low energy consumption and a small memory footprint — but that does not preclude large-scale computations, especially for computations that may be parallelized and distributed over a large number of processors.
THE QUBIC EPOCH
An assembly is initiated by publishing a set of global parameters on the Tangle in the form of an IOTA transaction. This assembly transaction can subsequently be used by oracles to find the assembly and to decide if they want to join it.
New oracles cannot simply join the assembly at random times. Instead, an assembly can open up to new oracles at certain predefined time intervals, called epochs. During an epoch, the oracles that constitute the assembly are all known and fixed. Within each epoch, all oracles will process the same set of events and consequently trigger the same set of qubics to run.
Each epoch has an exact start time and duration, which are similarly published as global parameters as a transaction on the Tangle. The epoch transaction also details if and how other oracles can join the assembly during the epoch. An epoch is itself split into two distinct phases: the resource test phase and the qubic processing phase.
PHASE 1: RESOURCE TEST
To prevent the possibility of a Sybil attack, assemblies require oracles to provide Proof of Resources. The Qubic system is very flexible in this regard. It can accept different ways of proving resources, and it even allows for a mix of different proof types, depending on the specific assembly needs. Examples of such proof types: Proof of Work (PoW), Proof of Stake (PoS), Proof of Bandwidth, Proof of Spectrum, etc.
Oracles that want to participate in the assembly will need to provide resource proofs during a so-called Resource Test Phase at the start of each epoch. The epoch parameters will specify how long the resource test phase will last, and what type of proof needs to be provided. The results will not only show that each oracle is a separate entity, but will also show the relative capabilities of each oracle in the form of a weighing factor.
Stake & weighing factors
Each type of resource proof has an associated stake factor that determines its relative voting power between resource proof types within the assembly. The assembly initiator will start as the only stake holder, and would not require proof of stake alone. The initiator may decide to add a few other trusted oracles to the assembly as separate no-proof-necessary stake holders with their own predefined stake factors. Alternatively, the assembly may be opened to any oracles that want to join based on some proof of resources. Such a stake factor is shared by these oracles and allocated to them based on their weighing factor.
The relative stake factors determine the proportional voting power of each individual oracle in the assembly. Any rewards provided by qubic owners will be distributed to the oracles proportional to this voting power.
Suppose the stake factor is Proof of Work (PoW). New oracles joining the assembly would solve a certain cryptographic puzzle as many times as possible during the resource test phase. The method of PoW can be specified by the qubic as part of the epoch parameters. Oracles that want to participate in the assembly are required to provide their resource proofs by the end of the resource test phase, which will define their weighing factor for the current epoch.
When the assembly consists solely of no-proof stake holders, the resource test phase at the start of the epoch is unnecessary, and the qubic processing phase can start immediately.
At any moment during an epoch, any participating oracle can suggest adjustments to the composition of the stakes or other epoch parameters by attaching an adjustment transaction. Each oracle can vote on that adjustment by attaching votes to the transaction. If by the end of the epoch a quorum result has been achieved, the new parameters are published together with the epoch transaction that specifies when they take effect.
This means that an assembly can control its own bootstrapping phase responsibly, respond in an agile manner to changes in technology, and the founders of an assembly can safely divest themselves over time. They can dynamically respond to changes in their network, whether that means increasing oracle turnaround by decreasing the epoch duration, or cooperating with other assemblies to share work. Allowing for an optimization for network conditions is one of the strong points of the Qubic protocol.
Rewards as incentive
Rewards are distributed to oracles who return the correct quorum result according to their respective weighing factor. Each oracle performs the same amount of work to reach the same result, so the question arises: why pay more rewards to more powerful oracles? The answer is twofold:
- To prevent a powerful oracle from impersonating several less powerful oracles. The sum of the weights of the impersonated oracles can never be more than its weight without impersonations. Multiple impersonations will therefore not result in any advantage.
- To give economic incentive to oracles for gravitating towards assemblies that contain similarly powered oracles.
A less powerful oracle will not be able to keep up with the rest of the assembly, and can earn more rewards in a similar-peer group. A more powerful oracle will have its excess processing capabilities sitting idle, so it too can earn more rewards in a similar-peer group.
The result is different classes of processing power offered by different assemblies, with associated differentiation in rewards. Within each assembly, however, the rewards will be divided more evenly because the weight of the oracles in the group will be quite similar. Economic forces ensure that the rewards for each assembly settle into a reasonable equilibrium. Groups of oracles with similar-weight also help prevent one oracle from unduly influencing the quorum.
Qubic owners can decide the cost vs. time benefit of running their qubics on more or less powerful assemblies, and again, economic forces will drive this choice.
PHASE 2: PROCESSING
Once the resource test phase has completed, the oracles participating in the assembly will begin processing the qubics that have been attached to the assembly (or epoch).
Due to the functional nature of the Abra intermediate language, a qubic will always generate the exact same output result data given the same input data. Therefore a qubic will process its inputs and ultimately end up with a stable output state. The time period it takes a qubic to process its inputs completely is called a quant. Note that a quant is measured in logical time, not real time, because the real processing time for each qubic may vary. In other words, the quant is a counter or iterator.
Abra does not allow infinite loops, and therefore qubics must always end in a finite amount of time: i.e., a quant. A qubic’s inputs have a predefined invocation time limit within a quant to prevent infinite loops. A quant ends when all cascading qubics have processed their inputs and posted their results. Quants are also used for locating results for the same computational task from different oracles.
Due to these constraints imposed by Abra, it is important to note that a qubic is not Turing complete within a single (or finite number of) epoch(s). However, Qubic allows for Turing completeness over an indeterminate number of epochs.
It is possible to delay output data for a number of quants before it becomes available as input data for other qubics. This allows for more flexibility in determining when certain qubics will be triggered, and may be thought of as “Proof of Elapsed (Logical) Time.”
Immediately before the end of an epoch, all oracles post a transaction that functions as a snapshot of their internal processing state. These snapshots can be used at the start of the next epoch by any newly participating oracles, so quorum consensus rules apply. Lastly, the next epoch starts with a new resource test phase.
PREVENTING CLASSROOM ATTACKS
To prevent the possibility of a Classroom Attack (cheating by copying results from others) qubics post results to the Tangle in two separate transactions: a commit transaction, followed by a reveal transaction.
Commit Transaction
In the commit transaction, the quorum result will be determined without revealing the actual result.
Each oracle posts its calculated results in a commit transaction on the Tangle. The commit transaction includes:
- A unique identifying value, called a salt
- A hash of the result data
- A hash of the result data concatenated with the salt
- A signature to verify the oracle
This guarantees that other oracles cannot simply copy the result, yet the resulting hash values can still be compared to see if a quorum decision on the result was reached.
Reveal Transaction
Once a quorum is reached in the commit phase (2/3 of oracles have made commit transactions with the same result hash), each oracle posts their calculated result to the Tangle in a reveal transaction, allowing the qubic owner to consume the results.
The qubic owner can now distribute the promised rewards to the oracles who contributed to the correct quorum result and also had the correct hash for the result combined with their unique identifying value in the commit phase (meaning they did not cheat).
A NOTE ON TIMESTAMPS
Timestamps serve various functions in both IOTA and Qubic. For example, resource test results must be posted within a given time frame. Timestamps are also useful for historical investigation of the Tangle, but only if they are accurate with a high degree of certainty. For any of these functions, an efficient way of determining timestamp confidence is required. The IOTA Foundation’s own Dr. Serguei Popov and his team have detailed two approaches to timestamps in their paper On timestamps in the Tangle. Qubic will likely leverage one or both of these methods pending further research into their performance and capabilities.
