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.