This article was first published on IOTA - Medium
Ever since we first revealed the Qubic protocol we have been asked to go into more detail about the inner workings of the Qubic Computation Model. This is the first, in a series of blog posts, that will attempt to do exactly that. So fasten your seat belt, it’s going to be an interesting ride!
There is a lot of ground to cover, and we will for now ignore the higher level Qubic protocol concepts like Assemblies, Quorums, or even the IOTA Tangle. Instead, we will first look at how Qubic programs are being executed using a structured functional dataflow language specification called Abra, and discuss the basic concepts used in Abra.
In future installments we will examine Qupla, a Qubic Programming Language, which is the first implementation of the Abra specification, and look at Qupla’s basic entities, functions, expressions, operations, and some programming examples. After that we will examine the part of a Qubic-enabled node (Q-node) that initiates and facilitates the actual processing of a qubic task: the Qubic Supervisor. We will show how the Supervisor is closely intertwined with the Abra processing model.
Abra: a functional dataflow language specification
Disclaimer: the Abra specification is not yet 100% complete. We may introduce additional concepts and changes that we think are useful while we are trying to use the specification for real-world tasks. But overall the concepts are clear. We currently have a working Qupla interpreter and compiler that implements the Abra specification.
Abra specifies an extremely minimal general instruction set that is designed to provide natural mapping of dataflow based functional programs to the wildly varying types of hardware run by IoT devices. That means it can be easily mapped to run on any device from CPUs, to GPUs, to FPGAs, to ASICs. However, Abra ...
To keep reading, please go to the original article at:
IOTA - Medium