Qubics

This article is a translation of the German IOTA Beginner’s Guide by .

Individual qubics are essentially pre-packaged quorum-based (majority principle) computational tasks.

Qubic uses the IOTA Tangle to package qubics from their owners and distribute them to the oracles that will process them.

Qubics are published as messages in normal IOTA transactions and contain special instructions, called metadata, on how and when to process them. Oracles can read qubic metadata to decide whether or not to perform the required processing for the associated rewards. Qubic-enabled IOTA nodes (Q-nodes for short) can handle much of this decision making automatically based on parameters set by their operators.

Qubic tasks are specified using the ternary-based functional intermediate programming language called Qupla / Abra. The Qubic programming model allows data to flow from qubic to qubic throughout the system. Technically, qubics are event-driven, meaning that they listen to the tangle directly for input data and are executed whenever the input data changes. Because qubics report their results back to the Tangle, the execution of a single qubic can cause many other qubics to run in a kind of “chain reaction.” qubics act as triggers for other qubics, which in return trigger other qubics, and so on.

In other words, qubics can live at idle in the Tangle. When certain input data becomes available or changes, they “wake up” and begin processing, which can cause a cascade of other qubics to wake up as new results become available. This makes for a very dynamic programming environment, as you can add new qubics at any time and bind them to any input data.

In addition, anyone can publish a transaction with the qubic code they want to run and see the results in the Tangle for the appropriate rewards.

The following steps describe the life cycle of a qubic:

Prepare a qubic for processing
Decide on the rewards offered
Decide in which assembly the qubic should run
Link the qubic to the assembly (or to a specific epoch of that assembly)
Wait for the assembly to start processing the qubic
Collect the confirmed processing results
Evaluate the consensus on the quorum
Collect the revealed processing results
Pay the promised reward to the quorum participants once the results are available
To prepare a qubic, the owner packages the Qupla / Abra code and qubic metadata within an IOTA transaction. An IOTA transaction that contains abra code and qubic metadata is called a qubic transaction. In this regard, Qubic uses the value-free, data-only transaction mechanism of the IOTA protocol.

The owner then selects which assembly the qubic should process by searching for specific transactions in the tangle that provide information about an Oracle assembly. These are referred to as assembly transactions. Attaching a qubic transaction to an assembly transaction informs oracles that the qubic is available for processing.

Oracles are thus the Q-Nodes operators that process qubics. They listen to the tangle for qubic transactions and construct a private sub-tangle to track them. Qubic transactions must be well formulated and signed, or the nodes will refuse to process them.

Once a qubic transaction is validated, the node prepares the qubic to run on the node’s respective hardware and schedules the qubic for processing. Once the qubic has been processed, a quorum has been reached, and the results have been placed in the tangle, two things happen:

The qubic goes back to inactive and waits for the next change in inputs.
The cascade effect is triggered so that dependent qubics start up and begin processing with new inputs.

Original source

https://iota-einsteiger-guide.de/qubics.html

Last Updated on 16. February 2021