dOra: distributed Oracle

With our technology it is possible to design a decentralized system, at the base of the "blockchain alternatives"

Oracles and Smart Contracts

“Oracles” are systems delegated to acquire data, eventually normalize it, and then insert it into a Distributed Ledger. Usually this activity triggers the activation of a Smartcontract, then an uninterruptible process that can also handle economic transactions. The execution of Smartcontracts is uninterruptible and managed in a decentralized manner, making it an extremely secure computational system. However, if the data entered by the Oracle is incorrect or partial or completely absent, the Smarcontract will produce undesirable effects or will not be executed at all. Also, usually, oracles do not operate biderectionally, so they do not acquire data produced by Smarcontracts and then publish it to other destinations. The system that delivers the Cyronclad network supervisor is an Oracle, but not just an Oracle, but a Distributed Oracle or dOra. The distributed organization of the dOra system increases the level of security and quality of managed data. Indeed, it is virtually impossible to compromise the execution of the dOra system or to produce false data that appears to be published by the real system. Finally, since the dOra system performs a number of sophisticated mathematical prcedures to produce digital signatures in a distributed manner, we have endowed it with the ability to execute arbitrary tasks chosen by the client, eventually making it unnecessary to activate a smartcontract.

Distributed Oracle

dOra is a distributed Oracle, i.e. a programmable computational system in which the processor is made up of a committee of nodes.

None of the committee nodes is autonomous in producing data or performing a task (for example entering data into a DLT) without the majority of committee nodes having produced the same data or being prepared to perform that task

Mathematical security

The data produced by dOra are signed by the committee with a signature process, defined as “distributed” and “threshold”.

The signing process is distributed because none of the nodes knows the private key with which to produce a valid signature.

The public key itself is produced with a distributed process: each node creates its own private key and, following a standard procedure called Distributed Key Generation, exchanging non-critical information, obtains from the other nodes the information necessary to calculate a public key. Having the same information each node produces the same key.

It is a signature procedure known as “threshold” since to produce a valid signature it is necessary that a minimum number of nodes of the committee, the threshold, have the same data.

Each produces the same partial signature using its own private key and shares it with the other nodes.

If at least a number of nodes higher than the threshold has signed the same data and shared the partial signature then, by integrating the partial signatures, each node is able to calculate the signature that is still valid for the common public key.

Identity of the nodes and of the committee

The signature produced by the committee is a datum and like any other datum in the Cyronclad system it must be verifiable, not only for formal correctness, but for “authorship”.

Indeed, the authorship of a datum allows us to evaluate the significance of the datum.

To obtain this information in the dOra system, each subject is identified with a Digital Identifier or DID, according to the standard homonym of the W3C consortium.

A DID is represented with a URL that allows you to obtain a DID Document, a sort of identity document, which contains the information necessary to validate signatures produced by the identified subject, thus certifying the authorship of the data it produces.

The dOra system committee must also have a DID and therefore the first operation that the committee carries out when it is activated is to create its own DID and publish the relative DID Document.

Any data published by the committee will contain its DID through which it is possible to obtain the DID Document, therefore the public key with which to validate the signature of the data.

Secure and decentralized communication

One of the possible ways in which a server can be attacked in order to create a disruption is the “Denay of Service”. It is an attack technique that aims to saturate the bandwidth of the server’s network connection, or to saturate its operational resources. The attack takes place by sending an anomalous quantity of requests to the server, even trivial, causing an overload that produces effects equivalent to disconnecting the server from the network or shutting it down. To make the dOra system immune to these types of attacks, the nodes and the committee itself do not use the TCP/IP protocol to communicate with each other and with the clients, i.e. their network address is not published and therefore they cannot be attacked dos. Nodes communicate using the IOTA network as a secure transport layer.The IOTA network is made up of thousands of nodes that dynamically interconnect with each other. Nobody can know which IOTA node a dOra node is connected to and therefore it is not possible to plan an attack. Furthermore, each dOra node can use multiple IOTA nodes to publish messages destined for other nodes and therefore the communication system is highly redundant. Furthermore, the IOTA network itself ensures that the message posted by one node is almost instantly replicated to all other nodes in the network. This also makes it impossible to prevent a node from receiving a message because it will be retrievable by any other node in the network. The addressing of the messages, to ensure that they are received by the recipient, is based on the identity, i.e. the DID: each dOra node is therefore listening to an IOTA node for each message published by other nodes that has a “tag” with the own DID or the DID of the committee to which he belongs. So even sending messages to a dOra committee, containing requests for task execution, is immune from attacks, because there is not a single subject responsible for receiving them, but all the nodes of the committee will receive them simultaneously.

White paper

For more details please donwload the whitepaper.

Click here