Qubic

Il 3 Giugno 2018 la IOTA Foundation ha ampliato il sito con le informazioni riguardanti Qubic.Scopiramo insieme di cosa si tratterà!Ricordo che qui parliamo di quanto è stato annunciato dalla IOTA Foundation. Qubic è tuttora in fase di sviluppoIl contenuto è stato liberamente tradotto dal sito ufficiale del progetto Qubic.

Qubic di IOTA è:

Un modo per comunicare informazioni in sicurezza dal mondo esterno al Tangle in un ambiente fidato – Macchine Oracoli ( Oracle Machines )

) Una potente piattaforma di calcolo delegato (fog computing) per la creazione di complesse applicazioni IoT – Calcolo Delegato ( Delegated Computing )

) Un nuovo tipo di contratto intelligente, che raccoglie micro-pagamenti in tempo reale durante l’esecuzione – Contratti intelligenti ( Smart Contracts )

) Un sistema di ricompensa per incentivare la partecipazione onesta al Tangle – Pagamenti automatizzati M2M (payment machine-to-machine)

Con Qubic in oltre si definisce un protocollo per la computazione basata sul quorum. Il quorum nel calcolo distribuito è il numero minimo di voti che una transazione distribuita deve ottenere per essere autorizzata ad eseguire un’operazione. Per IOTA il qubic ciò che viene chiamato un pacchetto di computazione distribuito basato sul quorum che opera secondo il protocollo Qubic.

Una definizione più conosciuta di quorum potrebbe essere:

Un quorum è il numero minimo di membri di un’assemblea deliberativa (un organo che usa una procedura parlamentare, come un corpo legislativo) necessario per condurre gli affari di quel gruppo.

Per iniziare un riassunto Qubic:

Gli oracoli permettono a qubic di ottenere dati da fonti esterne al Tangle. e.g. dai sensori di temperatura sul territorio, allo stato dei semafori o del traffico in città, il consumo energetico di una certa zona cittadina, il livello dell’acqua di un fiume, un eventuale movimento di una parete rocciosa.

Questi dati possono essere utilizzati in qubic per le una ricerca sull’ottimizzazione della viabilità in città, o ad esempio per la prevenzione di un’alluvione

Questi dati possono essere utilizzati in qubic per le una ricerca sull’ottimizzazione della viabilità in città, o ad esempio per la prevenzione di un’alluvione Chiunque potrà partecipare con i propri dispositivi (PC, Server, VPS, rapsberry pi, smartphone, miner ASIC per bitcoin, scheda video) al calcolo di qubic. Immaginate un mondo dove i dispositivi dormienti, invece di sprecare energia per rimanere in stand-by possano essere utilizzati per supportare progetti come setiathome per trovare segnali radio alieni oppure calcolare la traiettoria migliore per raggiungere Marte il 15 settembre 2035. Questo in maniera molto riassunta è il tema dei calcoli distribuiti in Qubic

in Qubic Gli smart contracts su Qubic permettono di utilizzare i dati dagli oracoli per automatizzare delle operazioni, e.g. la tua zona limitrofe consuma più elettricità? Ti abbassiamo automaticamente la tariffa in quanto sei più attento ai consumi dei tuoi vicini!

Questo era un breve e semplice riassunto in base a ciò che posso io immaginare dopo aver tradotto Qubic.

Voi cosa potreste fare?

Segue Qubic, presentato dalla IOTA Foundation e liberamente da me tradotto:

Macchine Oracolo (Oracle Machines)

Quando si elaborano calcoli che coinvolgono un database decentralizzato come il Tangle, è difficile ottenere dati che provengono dal mondo reale o che provengono dell’esterno dell’ambiente di esecuzione.

Qubics accedono a dati esterni attraverso una macchina oracolo, che funge da lente (di lettura) tra un qubic ed il mondo esterno.

Il protocollo consente la lettura e la trasmissione di dati mantenendo un elevato grado di certezza sulla coerenza dei dati in questione. Inoltre, mentre tecnicamente ciò significa che gli stessi oracoli (e.g. gli attori esterni come gli utenti o le macchine che forniscono dati sui sensori) non rientrano nell’ambito del protocollo, Qubic può tuttavia fornire anche un alto grado di certezza circa la correttezza dei dati in questione tramite il quorum.

Qubic usa oracoli (e di conseguenza, macchine oracolo) per fornire i dati di input rilevanti per le attività computazionali basate sul quorum. Alcuni esempi di tali dati di input sono:

Dati di temperatura da sensori del mondo reale

Dati di valore delle scorte attuali o storici dal mercato azionario

Attributi personali, come età attuale, stato civile, stato di decesso

Risultati delle elezioni

Calcolo delegato (Delegated Computing)

Per qualsiasi operazione computazionale, ci saranno sempre attività troppo intense per la potenza di calcolo del dispositivo a disposizione, o attività che richiedono dati oltre a quelli disponibili localmente. Questo è particolarmente vero per i dispositivi che compongono l’Internet of Things (IoT).

Cosa accadrebbe se tali dispositivi a bassa potenza potessero semplicemente delegare calcoli intensivi a una macchina esterna più performante?

Qubic permette questi calcoli delegati e consente una partecipazione sicura e senza necessità di autorizzazione a consumatori e produttori. Il protocollo consente a chiunque di creare o richiedere di eseguire un’attività computazionale su uno o più dispositivi esterni, che a sua volta trasmettono i risultati al richiedente. Allo stesso modo, chiunque può trovare compiti e partecipare alla loro elaborazione.

Come con le macchine oracolo, questa elaborazione avviene in modo decentralizzato e sicuro, con il protocollo Qubic che garantisce che i risultati siano attendibili con un elevato grado di certezza.

Smart Contracts (Contratti intelligenti)

In generale, i contratti intelligenti (smart contracts) eliminano la necessità di controlli da parte di terzi incapsulando gli obblighi contrattuali nel software, per essere autonomamente verificati e applicati. Chiunque abbia accesso al contratto può verificare che un evento specifico porti sempre a un risultato specifico. Mentre si prevede che gli smart contracts possano essere utilizzati in futuro per sostituire molti tipi di contratti cartacei reali, ad oggi il caso d’uso più comune per i contratti intelligenti consiste nel creare token virtuali che ereditano molte delle proprietà del sistema distribuito in che sono stati creati.

Mentre Qubic è ovviamente in grado di supportare questi tipi di smart contracts tradizionali, la combinazione di transazioni a pagamento e la computazione basata sul quorum apre la porta a possibilità completamente nuove. Ad esempio, uno smart contract potrebbe essere utilizzato per aggregare i dati di temperatura di oracoli diversi in una temperatura media, che viene periodicamente pubblicata sul Tangle. Lo smart contract è ora diventato un oracolo a tutti gli effetti – cioè, il contratto stesso è diventato una fonte di dati esterni, a disposizione di una macchina oracolo per essere raccolta ed inviata ad altri qubic.

Questi tipi di smart contract sono anche solo iterazioni sulla capacità più generale di computazioni basati sul quorum. Pertanto qubic fornisce anche un modo standardizzato per definire, convalidare e far rispettare i risultati di uno smart contract con un elevato grado di certezza

Un esercizio mentale

Quello che segue è un mio esempio personale, discutiamolo insieme su Medium.

Voi avete un terreno con una coltivazione di piante medicinali. Per proteggere il vostro investimento stipulate uno smart contract con un’assicurazione nel quale definite che:

se i dati del terreno (temperatura/umidità) misurati sono differenti da quanto previsto, il vostro premio assicurativo sia alza/abbassa automaticamente

nel caso di alluvione o siccità prolungata, l’assicurazione vi paga automaticamente per i danni subiti

Di seguito i qubic in uso:

qubic temperatura e umidità del terreno: serve come una primitiva macchina oracolo che periodicamente pubblica la temperatura ambientale e l’umidità del terreno sul Tangle. L’origine dei dati sono i nostri sensori in loco.

qubic pluviometro: serve come una primitiva macchina oracolo che periodicamente pubblica il livello di piogga sul Tangle. L’origine dei dati sono i nostri sensori in loco. qubic temperatura, umidità, pioggia media: questo qubic raccoglie i dati da sensori di zone geograficamente limitrofe alla nostra coltivazione. L’originatore dei dati può essere predefinito o meno. In questo scenario gli oracoli recuperano i dati esterni al Tangle che è impossibile ottenere con altri mezzi qubic polizza: questo qubic richiede in automatico il pagamento della polizza assicurativa in base alle informazioni del qubic temperatura, umidità e livello della pioggia media. qubic copertura: in caso di alluvione o siccità prolungata paga automaticamente i danni come definito nello smart contract

Oracoli e quorum

In un mondo perfetto potremmo semplicemente continuare e permettere agli oracoli di eseguire i calcoli.

Purtroppo viviamo in un mondo in cui attori malintenzionati cercano di trarre vantaggio dagli altri, influenzando o rubando i loro risultati. Ciò significa che sarebbe necessario aggiungere una protezione aggiuntiva contro gli attori malintenzionati e metterci nella condizione di fidarci dei risultati del calcolo, indipendentemente dall’origine dell’elaborazione.

Nel protocollo Qubic questo comportamento è impiegato forzando il consenso al quorum. Dal momento che non possiamo aspettarci che ogni oracolo esegua tutti i qubics esistenti e verifichi tutti i risultati, come fanno certe soluzioni blockchain, qubic utilizza il quorum per raggiungere il consenso sui risultati.

Ciò significa che nel sistema Qubic un gruppo di oracoli si unirà in un assemblea in cui tutti i membri elaboreranno lo stesso insieme di qubics e ogni oracolo pubblicherà i risultati di elaborazione per ogni qubic sul Tangle. Ciò consentirà ai proprietari di qubic di determinare il consenso al quorum dell’assemblea. Se non si riesce a formare il quorum (almeno i 2/3 degli oracoli nell’assemblea concordano sul risultato), i risultati non saranno accettati dal proprietario del qubic.

L’incentivo ad essere onesti in un’assemblea è lo stesso incentivo di colui che diventa un oracolo: la ricompensa offerta dal proprietario qubic. Questa ricompensa sarà distribuita agli oracoli nell’assemblea che ha prodotto il risultato del quorum per quel qubic. Se ottieni un risultato manipolato o errato, perderai la ricompensa. Lo stesso vale se si decide di non partecipare all’elaborazione del qubic. Nessuna elaborazione significa nessuna ricompensa.

Si noti che un proprietario qubic può aumentare la confidenza nei risultati dell’elaborazione selezionando un’assemblea più grande, o facendo computare il qubic da più adunanze in maniera casuali. Tutto dipende dall’importanza dei dati e dalla quantità di ricompensa che è disposto a spendere.

La fiducia nei numeri

Nel calcolo delegato:

Un quorum è il numero minimo di voti che una transazione distribuita deve ottenere per essere autorizzata ad eseguire un’operazione

È applicabile agli organi legislativi:

Un quorum è il numero minimo di membri di un’assemblea deliberativa (un organo che usa una procedura parlamentare, come un corpo legislativo) necessario per condurre gli affari di quel gruppo.

Nel caso di Qubic, l “assemblea deliberativa” è un gruppo specifico di oracoli ed il quorum è la proporzione minima del potere di voto del gruppo Un quorum è il numero minimo di membri di un’assemblea deliberativa (un organo che usa una procedura parlamentare, come un corpo legislativo) necessario per condurre gli affari di quel gruppo.. Senza il quorum, il risultato è considerato non conclusivo e quindi non valido.

Qubic utilizza un quorum per raggiungere il consenso su entrambi i dati di input e i risultati dei calcoli, quando ad esempio si recuperano dati da un assemblea di oracoli o quando si elaborano calcoli basati su quorum. In entrambi i casi, che sono essenzialmente due facce della stessa medaglia, sono validi solo quando almeno i 2/3 di tutti i partecipanti sono d’accordo. Da qui il termine: computazione basata sul quorum. Il quorum rende difficile per gli attori malintenzionati falsificare i dati e riduce l’impatto di dati sporadici o non intenzionalmente errati.

Sebbene possa sembrare un sistema dispendioso computare gli stessi calcoli molteplici volte, è l’unico modo per mantenere un alto grado di certezza sulla mancata manomissione dei dati per un sistema fiduciario e decentralizzato. È importante sottolineare che, mentre altri protocolli coinvolgono ogni partecipante ad ogni computazione, Qubic si aspetta che gli oracoli in un particolare assemblea partecipino a un determinato calcolo. In effetti, Qubic consente persino assemblee ad oracolo singolo, che possono essere sfruttati in ambienti più efficienti in cui l’operatore è affidabile o dove la validità di un risultato è facile da verificare.

Formare un assemblea

Gli oracoli possono essere fidati o non fidati. Gli oracoli attendibili sono in genere quelli che sono controllati direttamente dal proprietario del qubic, o quelli che hanno guadagnato la reputazione di essere affidabili nel tempo. Si noti che quest’ultimo non consente una garanzia del 100%, ma consente un elevato grado di fiducia in un oracolo affidabile.

Generalmente la maggior parte degli oracoli mancano di fiducia da utente specifico.

Un passo importante nel ciclo di vita della maggior parte degli oracoli è quindi quello di diventare parte di un’assemblea, che combinata ad un’adeguata struttura di incentivi, è il meccanismo utilizzato per fornire fiducia in un ambiente altrimenti privo di fiducia (trustless environment).

In particolare, l’incentivo per gli oracoli a rimanere onesti è la ricompensa per la computazione, che si otterrà consegnando il risultato del quorum. Si presume che la maggior parte degli oracoli senza fiducia si comporteranno nel modo previsto – questi oracoli sono chiamati “oracoli onesti”.

Indipendentemente dal fatto che stiamo trattando o meno con oracoli di fiducia, sarà fatta la differenza in come e perché saranno formate le assemblee. Simile al teorema CAP (o di Brewer) che si occupa di dati distribuiti, qubic abilita al massimo due su tre proprietà per la computazione distribuita in una determinata assemblea: decentralizzazione, latenza e fiducia. Le seguenti sezioni illustrano alcuni dei casi d’uso più comuni.

Assemblea ad oracolo singolo

All’estremo inferiore, un singolo oracolo fidato può formare la propria assemblea, costituita da se stesso come unico membro. Questo modello dà priorità alla latenza ed alla fiducia, a spese della decentralizzazione. Tale assemblea sarebbe utile in due casi:

per elaborare qubics dai proprietari di qubic che si fidano completamente o

dai proprietari di qubic che si fidano completamente o per elaborare qubics con risultati che sono costosi da calcolare, ma facili da verificare

Un esempio:

un gruppo di sensori di un singolo produttore che a loro volta richiedono elaborazione in outsourcing o dati di input esterni. In questo caso, il produttore può configurare una singola macchina oracolo affidabile per elaborare qubics per questi sensori. Poiché la macchina oracolo è stata progettata per funzionare insieme ai sensori, la latenza può essere ottimizzata e il fattore di fiducia può essere al 100%. Non c’è modo per un oracolo non fidato di inserirsi in questa assemblea. Inoltre, poiché esiste già un incentivo per l’oracolo nell’elaborare i qubics (ad esempio, il produttore lo richiede), il premio di elaborazione può essere mantenuto a zero.

Altri protocolli potrebbero essere utilizzati per gestire questo caso, ma Qubic offre una soluzione standardizzata e scalabile. Qubic semplifica l’aggiunta di ulteriori macchine oracolo affidabili all’assemblea quando il gruppo di sensori diventa troppo grande per essere elaborato da una singola macchina. Inoltre, se i sensori stessi eseguono già semplici qubics che postano i loro dati sul Tangle, Qubic ovvia alla necessità di un protocollo separato e riduce il sovraccarico di implementazione.

Assemblea ad oracolo doppio

Nel caso in cui un assemblea ad oracolo singolo possa essere utilizzata perché l’operatore è noto ed affidabile, potrebbe essere vantaggioso espandere l’assemblea per includere un oracolo di backup per ridondanza.

Prendendo l’esempio sopra, supponiamo che l’unico oracolo non funzioni correttamente e abbia riportato risultati errati a causa del malfunzionamento. Dal momento che la fiducia è stata presupposta, il risultato accettato sarebbe errato. L’aggiunta di ridondanza renderebbe più facile individuare una macchina difettosa o malfunzionante. Finché entrambi gli oracoli raggiungono il quorum, ci sarà un alto grado di fiducia nella funzione delle macchine. Non appena viene fornito un solo risultato (vale a dire, un oracolo si guasta) o peggio: risultati contrastanti (cioè un oracolo ha un malfunzionamento), i risultati diventano immediatamente sospetti e il sistema può essere terminato correttamente mentre viene inviato un tecnico.

Per aumentare la ridondanza, è possibile aggiungere più macchine oracolo all’assemblea. Il sistema nel suo insieme può continuare a funzionare correttamente fino a quando il quorum può essere raggiunto, anche a fronte di una o più macchine oracolo malfunzionanti o guaste. Dato che questo esempio dipende anche da un incentivo fornito dal produttore e si assume la fiducia negli oracoli, ancora una volta, non sono richieste ricompense.

Pur dando la priorità alla latenza e alla fiducia a spese della decentralizzazione, la latenza in questo caso sarà meno ottimale a causa del tempo necessario per raggiungere il consenso.

Assemblee maggiori

Assemblee composte da più di due oracoli non attendibili molto probabilmente saranno la norma, specialmente per qubics che vengono elaborati pubblicamente da operatori sconosciuti. Questo modello dà la priorità alla decentralizzazione ed alla fiducia a spese della latenza. In una assemblea maggiore, la fiducia viene fornita attraverso il sistema di incentivi, cioè le ricompense.

Un approccio ingenuo alla creazione di un sistema affidabile sarebbe semplicemente confrontare i risultati di ogni singolo oracolo. Tuttavia, le ricompense stesse introducono un ulteriore incentivo: truccare il sistema per ottenere più ricompense di quanto meritato. Ci sono due modi molto semplici per farlo:

Se le ricompense o il potere di voto fossero distribuiti equamente tra gli oracoli (parti uguali per oracolo), un singolo oracolo potrebbe impersonare più oracoli per condurre un attacco di Sybil.

Per evitare ciò, Qubic richiede agli oracoli di partecipare a una fase di test delle risorse prima che l’assemblea inizi a elaborare qubics. Se i risultati fossero pubblicati immediatamente, un oracolo potrebbe imbrogliare non facendo alcuna elaborazione e semplicemente copiando il risultato del quorum che si sta formando. Lo chiamiamo un attacco in aula. Per evitare ciò, i risultati vengono pubblicati in due passaggi. Per prima cosa l’oracolo pubblica una transazione di commit che identifica in modo univoco l’oracolo ed il suo risultato, ma senza dare la risposta. Solo successivamente sarà pubblicata la transazione di rivelazione, che i consumatori leggono per trovare i risultati.

Approfondiamo i qubic

Individualmente i qubic sono pacchetti preconfezionati di computazioni basate su quorum. Qubic fa leva sul Tangle IOTA per impacchettare e distribuire qubics dai loro proprietari agli oracoli che li elaboreranno.

I qubics sono pubblicati come messaggi nelle normali transazioni IOTA e contengono istruzioni speciali, chiamate metadati, su come e quando elaborarli. L’oracolo può leggere i metadati qubic per decidere se eseguire o meno l’elaborazione richiesta per la ricompensa associata. I nodi IOTA-Qubic-abilitati (in breve i Nodi-Q) possono gestire gran parte di questa decisione in modo automatico in base ai parametri impostati dai loro operatori.

I compiti qubic sono definiti usando un linguaggio di programmazione intermedio, funzionale, in base ternaria chiamato Abra. Il modello di programmazione Qubic consente al flusso di dati da qubic a qubic in tutto il sistema. Dal punto di vista tecnico, i qubics sono guidati dagli eventi, il che significa che ascoltano il Tangle direttamente per i dati di input e vengono eseguiti ogni volta che i dati di input cambiano. Poiché i qubics postano i loro risultati sul Tangle, l’esecuzione di un singolo qubic può causare l’esecuzione di molti altri qubics in una sorta di “reazione a catena”. I qubics fungono da innesco per altri qubic, che a loro volta attivano altri qubic, ecc.

In altre parole i qubics possono esistere sul Tangle in uno stato dormiente. Quando specifici dati di input diventano disponibili o cambiano, si attivano ed iniziano l’elaborazione, il che può portare a una cascata di altri qubics che si attivano quando i nuovi risultati diventano disponibili. Ciò consente un ambiente di programmazione molto dinamico in quanto è possibile aggiungere nuovi qubics in qualsiasi momento e legarli a piacimento a qualsiasi dato di input.

Inoltre, chiunque può pubblicare una transazione contenente il codice qubic che desidera eseguire e, per una ricompensa appropriata, vedere i risultati visualizzati nel Tangle.

Ciclo di vita del qubic

I seguenti passaggi delineano il ciclo di vita di un qubic:

Prepara un qubic per l’elaborazione

Decidi la ricompensa offerta

Decidi in quale assemblea eseguire il qubic

Collega il qubic all’assemblea (o un’epoca specifica di quell’assemblea)

Attendi fino a quando l’assemblea inizia l’elaborazione del qubic

Raccogli i risultati di elaborazione confermati

Valuta il consenso al quorum

Raccogli i risultati di elaborazione rivelati

Paga la ricompensa promessa ai partecipanti al quorum man mano che i risultati arrivano

Per preparare un qubic, il proprietario confeziona il codice Abra ed i metadati del qubic all’interno di una transazione IOTA. Una transazione IOTA contenente codice Abra e metadati qubic è chiamata transazione qubic. A tale riguardo, Qubic sfrutta il meccanismo di transazione a “valore zero”, “solo dati” fornito dal protocollo IOTA.

Il proprietario sceglie quindi quale assemblea elaborerà il qubic cercando transazioni specifiche nel Tangle che forniscono informazioni su un assemblea di oracoli. Queste sono note come transazioni di assemblea. L’associazione di una transazione qubic a una transazione di assemblea informa gli oracoli che il qubic è disponibile per l’elaborazione.

Gli Oracoli sono gli operatori dei Nodi-Q che elaborano qubics. In ascolto sul Tangle per le transazioni qubic e costruiscono un sub-Tangle privato per rintracciarle. Le transazioni Qubic devono essere ben formate e firmate, altrimenti i nodi si rifiuteranno di elaborarle.

Una volta che una transazione qubic è stata validata, il nodo preparerà il qubic per l’esecuzione sul particolare hardware del nodo e pianificherà il qubic per l’elaborazione. Una volta che il qubic è stato processato, raggiunto il quorum ed i risultati sono stati assegnati al Tangle, accadono due cose: 1) il qubic torna di nuovo in sospeso, in attesa del successivo cambio di input, e 2) l’effetto a cascata viene attivato, in modo che i qubics si avviano e iniziano l’elaborazione con nuovi input.

Il linguaggio di definizione dei qubic: ABRA

Abra è un linguaggio di programmazione intermedio, funzionale, su linguaggio di programmazione intermedio, funzionale, in base ternaria.

La scopo di Abra è stato circoscritto avendo in mente dell’hardware all’avanguardia. Qubic, come lo stesso IoT, è progettato per funzionare su un’ampia varietà di hardware. Per abilitare l’esecuzione dello stesso codice su piattaforme hardware diverse, i qubics sono impacchettati in questo linguaggio intermedio, il che significa essenzialmente che il linguaggio si presta ad una facile traduzione o interpretazione per hardware specifico. Ciò consente a Qubic di essere in gran parte indipendente dall’hardware.

Un linguaggio di programmazione funzionale consente un’analisi più semplice per dimostrare la correttezza del codice. Scrivere programmi corretti non è un compito banale. Abbiamo visto in passato quanto sia difficile rendere privi di bug anche semplici smart contracts. Avere un linguaggio che si presta all’analisi automatizzata è un drastico miglioramento rispetto a un linguaggio tradizionale e imperativo. Come ulteriore vantaggio, i programmi funzionali si prestano a un uso intensivo della parallelizzazione, il che significa che pezzi diversi di un programma più grande possono essere eseguiti contemporaneamente per trarre vantaggio da più CPU o anche da più dispositivi.

Infine, Abra è in base ternaria perché i sistemi ternari possono fornire significativi risparmi energetici, una considerazione cruciale per i dispositivi IoT. Una cifra ternaria, un trit, può rappresentare 1,58 bit. Il cablaggio necessario per un sistema ternario può quindi essere ridotta a circa il 64% di un sistema binario equivalente, con conseguente riduzione di energia corrispondente.

Abra è composto da funzioni, che a loro volta possono essere composte da funzioni – convergenti asintoticamente su funzioni che possono restituire un valore ternario, o null, che indica la terminazione di un ramo logico. Non vi è alcun flusso di controllo, bensì ramificazione implicita e fusione dei dati mentre scorre attraverso queste funzioni. Un dato endpoint è osservato come il ramo della funzione sopravvissuta che ha restituito un valore.

Abra appartiene quindi a un paradigma di programmazione noto come dataflow programming e si presta alla cosiddetta wave pipelining . I dati possono scorrere attraverso le varie fasi del processore senza la necessità di ritardi di sincronizzazione o di bufferizzazione. Questo ha dimostrato di essere in grado di ottenere frequenze di clock da 2 a 7 volte quelle possibili con i sistemi di pipeline convenzionali.

Un’ultima nota riguardante le ottimizzazioni: Abra verrà fornito con una libreria di funzioni di base predefinite per le piattaforme più comuni. Sebbene la maggior parte delle funzioni siano definite ad un livello molto basso, la natura di Abra consente di ignorare le funzioni con implementazioni specifiche dell’hardware che sono più efficienti laddove necessario.

Come IOTA, Qubic in generale ed Abra in particolare offrono ulteriori opportunità di collaborazione senza autorizzazione (permissionless) per aiutare ad iterare, migliorare e creare la visione condivisa della IOTA Foundation.

Il protocollo Qubic

Il protocollo Qubic specifica la costruzione, l’esecuzione ed il ciclo di vita evolutivo dei qubics. Sfrutta il protocollo IOTA per una comunicazione sicura e decentralizzata tra i vari partecipanti. Inoltre, poiché IOTA dispone di un proprio sistema di pagamento integrato, i token IOTA vengono utilizzati per fornire un sistema di incentivi per gli operatori qubic. Chiunque può decidere da solo a quale soglia una ricompensa diventa abbastanza interessante per partecipare.

Qubic offre un grande incentivo per le persone a gestire i nodi: lascia che altri usino la capacità di calcolo o la capacità di archiviazione, fornendo così un servizio utile e pagati per farlo. I Nodi-Q possono dare nuova vita ai vecchi PC abbandonati e possono fornire ai minatori di criptovalute tradizionali un modo per monetizzare le apparecchiature facendo calcoli utili invece di risolvere enigmi crittografici senza senso (ed inutili).

In futuro, Qubic sfrutterà questa capacità di calcolo inutilizzata a livello mondiale per risolvere tutti i tipi di problemi computazionali. Qubic è ottimizzato per IoT – basso consumo energetico e un piccolo ingombro di memoria – ma ciò non preclude calcoli su larga scala, specialmente per calcoli che possono essere parallelizzati e distribuiti su un numero elevato di processori.

L’Epoca Qubic

Un assemblaggio è avviato pubblicando un insieme di parametri globali sul Tangle sotto forma di una transazione IOTA. Questa operazione di assemblaggio può essere successivamente utilizzata da oracoli per trovare l’assemblea e decidere se aderire.

I nuovi oracoli non possono semplicemente unirsi all’assemblea in momenti casuali. Invece, un assemblaggio può aprirsi a nuovi oracoli a determinati intervalli di tempo predefiniti, chiamati epoche. Durante un’epoca, gli oracoli che costituiscono l’assemblea sono tutti noti e corretti. All’interno di ogni epoca, tutti gli oracoli elaboreranno lo stesso insieme di eventi e, di conseguenza, attivano lo stesso insieme di qubics.

Ogni epoca ha un’ora e una durata esatta, che sono pubblicate analogamente come parametri globali come una transazione sul Tangle. La transazione epoca descrive anche se e come altri oracoli possono unirsi all’assemblea durante l’epoca. Un’epoca è a sua volta suddivisa in due fasi distinte: la fase di test delle risorse e la fase di elaborazione qubic.

Fase 1: Test delle risorse

Per prevenire la possibilità di un attacco di Sybil, le assemblee richiedono agli oracoli di fornire la test delle risorse. Il sistema Qubic è molto flessibile a questo riguardo. Può accettare diversi modi di dimostrare le risorse, e consente anche un mix di diversi tipi di prove, a seconda delle specifiche esigenze di assemblaggio. Esempi di tali tipi di test: Proof-of-Work (Dimostrazione di Lavoro), Proof-of-Stake (Dimostrazione di Partecipazione), Proof-of-Bandwith (Dimostrazione di Banda), Proof-of-Spectrum (Dimostrazione di Spettro), ecc.

Gli oracoli che vogliono partecipare all’assemblea dovranno fornire prove di risorse durante una cosiddetta fase di test delle risorse all’inizio di ogni epoca. I parametri dell’epoca specificheranno per quanto tempo durerà la fase di test delle risorse e quale tipo di prova deve essere fornita. I risultati non solo mostreranno che ogni oracolo è un’entità separata, ma mostrerà anche le capacità relative di ciascun oracolo sotto forma di fattore di ponderazione.

Partecipazione e fattore di ponderazione

Ad ogni tipo di test delle risorse è associato un fattore di partecipazione che determina il suo potere di voto relativo tra le tipologie di test delle risorse all’interno dell’assemblea. L’iniziatore dell’assemblea partirà come unico detentore di azioni e non richiederà la dimostrazione di partecipazione (Proof-of-Stake). L’iniziatore può decidere di aggiungere altri oracoli fidati all’assemblea come detentori senza la necessità di test con i fattori di partecipazione predefiniti. In alternativa, l’assemblea può essere aperta a tutti gli oracoli che desiderano unirsi in base ad alcuni test di risorse. Tale fattore di partecipazione è condiviso tra questi oracoli e viene loro assegnato in base al fattore di ponderazione.

I fattori di partecipazione relativi determinano il potere di voto proporzionale di ogni singolo oracolo nell’assemblea. Qualsiasi ricompensa fornita dai proprietari di qubic sarà distribuita agli oracoli in proporzione al potere di voto.

Supponiamo che il fattore di partecipazione sia Dimostrazione di lavoro (Proof-of-Work). I nuovi oracoli che si uniscono al l’assemblea risolvono un certo puzzle crittografico il più volte possibile durante la fase di test delle risorse. Il metodo di Proof-of-Work può essere specificato dal qubic come parte dei parametri dell’epoca. Gli oracoli che vogliono partecipare all’assemblea sono tenuti a fornire la loro dimostrazione delle risorse entro la fine della fase di test delle risorse, che definirà il loro fattore di ponderazione per l’epoca attuale.

Quando l’assemblea consiste esclusivamente da detentori senza la necessità di test, la fase di test delle risorse all’inizio dell’epoca non è necessaria e la fase di elaborazione qubic può iniziare immediatamente.

Gli oracoli partecipanti possono suggerire aggiustamenti alla composizione delle partecipazioni o altri parametri di epoca in qualsiasi momento, allegando una transazione di aggiustamento. Ogni oracolo può votare su tale adeguamento allegando voti alla transazione. Se alla fine dell’epoca è stato raggiunto il risultato del quorum, i nuovi parametri vengono pubblicati insieme alla transazione epoca che specifica quando i parametri saranno incorporati.

Ciò significa che un assemblea può controllare la propria fase di bootstrap in modo responsabile, rispondere in modo agile ai cambiamenti tecnologici e che i fondatori di un assemblea possono tranquillamente disinvestirsi nel tempo. Possono rispondere dinamicamente ai cambiamenti nella loro rete, sia che ciò significhi aumentare il ritorno dell’oracolo diminuendo la durata dell’epoca, o cooperando con altre assemblee per condividere il lavoro. Consentire un’ottimizzazione delle condizioni della rete è uno dei punti di forza del protocollo Qubic.

Ricompense come incentivo

Le ricompense sono distribuite agli oracoli che restituiscono il risultato del quorum corretto, in base al loro rispettivo fattore di ponderazione. Ogni oracolo esegue la stessa quantità di lavoro per raggiungere lo stesso risultato, quindi sorge la domanda: perché pagare più premi a oracoli più potenti?

La risposta è duplice:

Per impedire ad un oracolo più potente di impersonare molti oracoli meno potenti. La somma della ponderazione degli oracoli impersonati non può mai essere maggiore della ponderazione senza imitazioni. Pertanto, impersonificazioni multiple non daranno alcun vantaggio Dare incentivi economici agli oracoli per gravitare verso assemblee, che contengono oracoli di simile configurazione

Un oracolo meno potente non sarà in grado di tenere il passo con il resto del gruppo e può guadagnare più premi in un assemblea di pari livello. Un oracolo più potente avrà ulteriori capacità di elaborazione che rimarranno inattive, in un gruppo di pari livello potrà guadagnare più ricompense.

Il risultato è diverse classi di potenza di elaborazione, offerte da diversi gruppi, con differenziazione associata in ricompense. All’interno di ogni assemblea, tuttavia, i premi saranno suddivisi in modo più uniforme perché il peso degli oracoli nel gruppo sarà abbastanza simile. Le forze economiche assicurano che le ricompense per ogni assemblea si stabilizzino in un ragionevole equilibrio. Anche gruppi di oracoli con peso simile impediscono ad un oracolo di influenzare indebitamente il quorum.

I proprietari di Qubic possono decidere i vantaggi in termini di costi e tempi di esecuzione dei loro qubics su assemblee più o meno potenti, e ancora una volta, le forze economiche guideranno questa scelta.

Fase 2: Elaborazione

Una volta completata la fase di test delle risorse, gli oracoli che partecipano all’assemblea inizieranno ad elaborare i qubics che sono stati allegati all’assemblea (o all’epoca).

A causa della natura funzionale del linguaggio intermedio Abra, un qubic genererà sempre gli stessi risultati dei risultati di output dati gli stessi dati di input. Pertanto un qubic elaborerà i suoi input e alla fine terminerà con uno stato di output stabile. Il periodo di tempo che impiega un qubic per elaborare completamente i suoi input è chiamato quant. Si noti che un quant è misurato in tempo logico, non in tempo reale, perché il tempo di elaborazione reale per ogni qubic può variare. In altre parole, il quant è un contatore od un iteratore.

Abra non ammette loop infiniti, e quindi un qubic deve sempre terminare in una quantità di tempo finita: cioè, un quant. Gli input di un qubic hanno un limite di tempo di chiamata predefinito all’interno di un quant per prevenire loop infiniti. Un quant finisce quando tutti i qubics a cascata hanno elaborato i loro input e hanno pubblicato i loro risultati. I quant sono anche usati per localizzare i risultati per lo stesso compito computazionale da diversi oracoli.

A causa di questi vincoli imposti da Abra, è importante notare che un qubic non è Turing equivalente all’interno di un singolo (o numero finito di epoche). Tuttavia, Qubic consente la Turing equivalenza su un numero indeterminato di epoche.

È possibile ritardare i dati di output per un numero di quant prima che diventi disponibile come dati di input per altri qubics. Ciò consente una maggiore flessibilità nel determinare quando alcuni qubit saranno attivati ​​e potrebbe essere considerato come “Proof of Elapsed (Logical) Time (Dimostrazione del tempo (logico) trascorso)”.

Immediatamente prima della fine di un’epoca, tutti gli oracoli pubblicano una transazione che funziona come un’istantanea del loro stato di elaborazione interno. Queste istantanee possono essere utilizzate all’inizio della prossima epoca da qualsiasi oracolo che partecipa di recente, quindi si applicano le regole di consenso del quorum. Infine, la prossima epoca inizia con una nuova fase di test delle risorse.

Prevenire l’attacco “aula scolastica”

Per prevenire la possibilità di un attacco “aula scolastica” (imbrogliare copiando i risultati d’altri), i qubics inviano i risultati al Tangle in due transazioni separate: una transazione di commit, seguita da una transazione di rivelazione.

Transazione di commit

Nella transazione di commit, il risultato del quorum sarà determinato senza rivelare il risultato effettivo.

Ogni oracolo pubblica i risultati calcolati in una transazione di commit sul Tangle.

La transazione di commit include:

Un valore identificativo unico, chiamato salt

Un hash dei dati dei risultati

Un hash dei dati dei risultati concatenati con il salt

Una firma per verificare l’oracolo

Ciò garantisce che altri oracoli non possano semplicemente copiare il risultato, tuttavia i valori hash risultanti possono essere ancora confrontati per verificare se è stata raggiunta una decisione di quorum sul risultato.

Rivelazione della transazione

Una volta raggiunto il quorum nella fase di commit (2/3 degli oracoli hanno effettuato transazioni di commit con lo stesso hash del risultato), ogni oracolo registra il risultato calcolato su Tangle in una transazione di rivelazione, consentendo al proprietario del qubic di utilizzare i risultati.

Il proprietario del qubic può ora distribuire le ricompense promesse agli oracoli che hanno contribuito al risultato del quorum ed il hash corretto per il risultato combinato con il loro valore identificativo univoco nella fase di commit (dimostrando che non hanno imbrogliato).

Una nota sulla marca temporale

Le marche temporali servono varie funzioni sia in IOTA che in Qubic. Ad esempio, i risultati del test delle risorse devono essere pubblicati entro un determinato periodo di tempo. Le marche temporali sono anche utili per le indagini storiche sul Tangle, ma solo se sono accurate e con un alto grado di certezza. Per ognuna di queste funzioni, è necessario un modo efficiente per determinare la confidenza temporale. Il Dr. Serguei Popov e il suo team della Fondazione IOTA hanno descritto dettagliatamente due approcci alle marche temporali nel loro articolo On timestamps in the Tangle. Probabilmente Qubic utilizzerà uno o entrambi questi metodi in attesa di ulteriori ricerche sulle loro prestazioni e capacità.

Roadmap

La prima parte della Roadmap di Qubic è già stata sviluppata ed è ben avviata alla produzione: IOTA ed il Tangle. I pezzi rimanenti sono in varie fasi di ricerca e sperimentazione. Con una serie completa di versioni sperimentali dei vari componenti, sarà possibile iniziare a Proof-of-Convept Qubic non indifferenti e dimostrazioni, che alla fine saranno i terreno di prova per Qubic nel mondo reale.

Bozza iniziale di Whitepaper: sotto revisione interna

Marche temporali: teoria e algoritmi determinati; essere implementato dallo IOTA

Strutture dati del Q-graph: per lo più decise, alcune parti in discussione

Messaggistica e convalida: implementazioni sperimentali di strutture dati conosciute

Abra: specifica iniziale con ambiente di esecuzione sperimentale per CPU

Per ulteriori informazioni in italiano o tedesco trovate i miei contatti a questa pagina.

Se avete trovato utile la mia traduzione, accetto volentieri delle donazioni 😉

IOTA:

CHQAYWPQUGQ9GANEWISFH99XBMTZAMHFFMPHWCLUZPFKJTFDFIJXFWCBISUTVGSNW9JI9QCOAHUHFUQC9SYVFXDQ9D

BTC:

1BFgqtMC2nfRxPRge5Db3gkYK7kDwWRF79

*Tutte le immagini sono proprietà della IOTA Foundation. Fonte.

Non garantisco nulla e mi libero da ogni responsabilità.