Gli "oracoli" sono sistemi deputati ad acquisire dati, eventualmente normalizzarli e quindi inserirli in un registro distribuito. Solitamente questa attività innesca l'attivazione di uno Smart contract, quindi un processo ininterrotto che può gestire anche transazioni economiche. L'esecuzione dei contratti Smart è ininterrotta e gestita in modo decentralizzato, rendendolo un sistema computazionale estremamente sicuro. Tuttavia, qualora i dati inseriti da Oracle risultino errati o parziali o del tutto assenti, lo Smarcontract produrrà effetti indesiderati o non avrà alcuna esecuzione. Inoltre, solitamente, gli oracoli non operano in modo bidirezionale, quindi non acquisiscono i dati prodotti dagli Smart Contract per poi pubblicarli su altre destinazioni. Il sistema che fornisce il supervisore di rete Cyronclad è un Oracle, ma non solo un Oracle, ma un Distributed Oracle o dOra. L'organizzazione distribuita del sistema dOra aumenta il livello di sicurezza e qualità dei dati gestiti. Infatti, è praticamente impossibile compromettere l'esecuzione del sistema dOra o produrre dati falsi che sembrano essere pubblicati dal sistema reale. Infine, poiché il sistema dOra esegue una serie di sofisticate procedure matematiche per produrre firme digitali in modo distribuito, lo abbiamo dotato della capacità di eseguire compiti arbitrari scelti dal cliente, rendendo eventualmente non necessaria l'attivazione di uno smart contract.

dOra è un un Oracolo distribuito, ovvero un sistema computazionale programmabile in cui il processore è costituito da un comitato di nodi. Nessuno dei nodi del comitato è autonomo nel produrre un dato o svolgere un compito (ad esempio immettere dati in un DLT) senza che la maggioranza dei nodi del comitato abbia prodotto lo stesso dato o sia predisposta a svolgere quel compito

I dati prodotti da dOra sono firmati dal comitato con un processo di firma, definito "distribuito" e "a soglia". Il processo di firma è distribuito perchè nessuno dei nodi conosce la chiave privata con cui poter produrre una firma valida. La stessa chiave pubblica è prodotta con un processo distribuito: ogni nodo crea una propria chiave privata e, seguendo un procedimento standard chiamato Distributed Key Generagion, scambiando informazione non critiche, ottiene dagli altri nodi le informazioni necessarie per calcolare la una chiave pubblica. Avendo le stesse informazioni ogni nodo produce la stessa chiave. E' un procedimento di fima detto "a soglia" in quanto per produrre una firma valida occorre che un minim numero di nodi del comitato, la soglia, abbia lo stesso dato. Ogni produce stessa firma parziale usando la propria chiave privata e la condivide con gli altri nodi. Se almeno un numero di nodi superiore alla soglia ha firmato lo stesso dato e condiviso la firma parziale allora, integrando le firme parziali, ogni nodo è in grado calcolare la firma comunque, valida per la chiave pubblica comunue.

La firma prodotta dal comitato è un dato e come ogni altro dato nel sistema Cyronclad deve essere verificabile, non solo per correttezza formale, ma per "paternità". La paternità di un dato ci permette infatti di valutare la significativitò del dato. Per ottenere questa informazioni nel sistema dOra ogni soggetto è indentificato con un Identificativo Digitale o DID, secondo l'omonicmo standard del consorzion W3C. Un DID è rappresentato con una URL che permette di ottenere un DID Document, una sorta di documento di identità, che contiene le informazioni necessarie a validare firme prodotte dal soggetto identificato, quindi certificare la paternità dei dati che produce. Anche il comitato del sistema dOra deve avere un DID e pertanto la prima operazione che il comitato svolge quando viene attivato è proprio creare il proprio DID e pubblicare il relativo DID Document. Qualunque dato pubblicato da comitato conterrà il suo DID mediante il quale è possibile ottenere il DID Document, quindi la chiave pubblica con cui validare la firma del dato.

Uno dei possibili modi con cui un server può essere attaccato allo scopo di creare un disservizio è il "Denay of Service". Si tratta di una tecnica di attacco che ha l'obiettivo di saturare la banda del collegamento di rete del server, o di saturare le sue risorse operative. L'attacco avviene inviando al server una quantità anomala di richieste, anche banali, provocando un sovraccarico che è produce effetti equivalenti al distacco del server dalla rete o al suo spegnimento. Per rendere il sistema dOra immune da questi tipi di attacco, i nodi e lo stesso comitato non usano il protocollo TCP/IP per comunicare tra loro e con i client, ovvero il loro indirizzo di rete non è pubblicato e pertanto non possono subire un attacco DOS. I nodi comunicano usando la rete IOTA come secure transport layer. La rete IOTA è composta da migliaia di nodi che si interconnettono in modo dinamico tra loro. Nessuno può sapere a quale nodo IOTA è collegato un nodo dOra e pertanto non è possibile pianificare un attacco. Inoltre, ogni nodo dOra può usare più nodi IOTA per pubblicare i messaggi destinati agli altri nodi e pertanto il sistema di comunicazione è altamente ridondante. Inoltre, la stessa rete IOTA garantisce che il messaggio pubblicato da un nodo sia quasi istantaneamente replicato su tutti gli altri nodi della rete. Ciò rende impossibile anche impedire a un nodo di ricevere un messaggio perché sarà recuperabile da qualsiasi altro nodo della rete. L'indirizzamento dei messaggi, a garanzia che vengano ricevuti dal destinatario, è basato sull'identità, ovvero il DID: ogni nodo dOra è pertanto in ascolto su un nodo IOTA per ogni messaggio pubblicato da altri nodi che abbia un "tag" con il proprio DID o il DID del comitato a cui appartiene. Quindi anche l'invio dei messaggi a un comitato dOra, contenenti richieste di esecuzione di task, è immune da attacchi, perché non vi è un singolo soggetto preposto a riceverli, ma tutti i nodi del comitato lo riceveranno contemporaneamente.

Maggiorni dettagli nel documento scaricabile con questo link: