Qubic: Quorum-based Computations — Powered by IOTA Part — 3
Part III - Deep dive into qubics
Individual qubics are, in essence, prepackaged quorum-based computational tasks. Qubic leverages the IOTA Tangle to package and distribute qubics from their owners to the oracles that will be processing 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 an intermediate trinary-based functional programming language called Abra. The Qubic programming model allows for data to flow from qubic to qubic throughout the system. Technically speaking, qubics are event-driven, meaning that they listen to the Tangle directly for input data, and run whenever the input data changes. Since qubics post their results back to the Tangle, running a single qubic can cause many other qubics to run in a sort of “chain reaction.” Qubics act as the trigger for other qubics, which in turn trigger yet other qubics, etc.
In other words, qubics can live on the Tangle in a dormant state. When specific input data becomes available or changes, they will “awaken” and begin processing, which may result in a cascade of other qubics waking up as new results become available. This allows for a very dynamic programming environment because you can add new qubics at any time and tie them to whatever input data you like.
What’s more, anyone can post a transaction containing the qubic code they want to run and, for the appropriate rewards, see the results show up in the Tangle.
THE QUBIC LIFE CYCLE
The following steps outline the lifecycle of a qubic:
- Prepare a qubic for processing
- Decide on the rewards offered
- Decide in which assembly to run the qubic
- Attach the qubic to the assembly (or a specific epoch of that assembly)
- Wait until the assembly starts processing the qubic
- Gather the committed processing results
- Evaluate the quorum consensus
- Gather the revealed processing results
- Pay the promised rewards to the quorum participants as results arrive.
- To prepare a qubic, the owner packages the Abra code and qubic metadata inside of an IOTA transaction. An IOTA transaction containing Abra code and qubic metadata is called a qubic transaction. In this respect, Qubic leverages the zero-value, data-only transaction mechanism provided by the IOTA protocol.
The owner then chooses which assembly will process the qubic by looking for specific transactions in the Tangle that provide information about an oracle assembly. These are known as assembly transactions. Attaching a qubic transaction to an assembly transaction informs the oracles that the qubic is available for processing.
Oracles, then, are the Q-node operators who process qubics. They listen to the Tangle for qubic transactions, and construct a private sub-tangle for tracking them. Qubic transactions must be well-formed and signed, otherwise the nodes will refuse to process them.
Once a qubic transaction has been validated, the node will prepare the qubic for running on the node’s particular hardware, and schedule the qubic for processing. Once the qubic has been processed, a quorum achieved, and results posted to the Tangle, two things happen: 1) the qubic goes dormant again, waiting for the next change of inputs, and 2) the cascade effect is triggered, so that dependent qubics spin up and begin processing with new inputs.
THE QUBIC DEFINITION LANGUAGE: ABRA
Abra is an intermediate trinary-based functional programming language.
Abra has been constrained with state-of-the-art hardware in mind. Qubic, like the IoT itself, is intended to run on a wide variety of hardware. To enable running the same code on different hardware platforms, qubics are packaged in this intermediate language, which essentially means that the language lends itself to easy translation or interpretation for specific hardware. This allows Qubic to be largely hardware-independent.
A functional programming language allows for easier analysis to prove the correctness of code. Writing correct programs is not a trivial task. We have seen in the past how difficult it is to make even simple smart contracts bug-free. Having a language that lends itself to automated analysis is a drastic improvement over a traditional, imperative language. As an added benefit, functional programs lend themselves to heavy use of parallelization, meaning that different pieces of a larger program can be run concurrently to take advantage of multiple CPUs or even multiple devices.
Finally, Abra is trinary-based because trinary systems can provide significant energy savings, a crucial consideration for IoT devices. One trinary digit, a trit, can represent 1.58 bits. The amount of wiring necessary for a trinary system can therefore be reduced to about 64% of an equivalent binary system, resulting in a corresponding energy reduction.
Abra is composed of functions, which themselves may be composed of functions — asymptotically converging on functions which may return a trinary value, or null, indicating termination of a logical branch. There is no control flow, but implicit branching and merging of data as it flows through these functions. A given endpoint is observed as the surviving function branch which returned some value.
Abra thus belongs to a programming paradigm known as dataflow programming, and lends itself to so-called wave pipelining. Data can flow through the several stages of the processor without the need for synchronization or buffering delays. This has been shown to be able to achieve clock-rates 2- to 7-times those possible with conventional pipelining systems.
One final note regarding optimizations: Abra will come with a library of predefined basic functions for the most common platforms. Although most functions are defined at a very low level, the nature of Abra allows us to override functions with hardware-specific implementations that are more efficient where necessary.
Like IOTA, Qubic in general and Abra in particular provide further opportunity for permissionless collaboration to help iterate, improve, and create our shared vision.
