http://www.cryptominando.it/wp-content/uploads/2018/01/iota-e1516984649314.jpg
Sono passati quindici mesi da quando la cryptomoneta IOTA è uscita dal laboratorio ed è stata listata su Bitfinex.com. In questo periodo sono successe molte cose, il progetto è evoluto, la fondazione che lo sostiene si è allargata a molti nuovi membri e la comunità di potenziali grandi adopter si è espansa notevolmente. Tuttavia i dubbi sul funzionamento di IOTA e sulle sue caratteristiche di sicurezza restano molto radicate nella community di sviluppatori e analisti nata e cresciuta attorno a Bitcoin. Stefano della Valle, membro dello IOTA Evangelist Network, prova con questa intervista a fare chiarezza sui punti più importanti e sul futuro di IOTA.

Perché utilizzare un sistema ternario al posto del consueto sistema binario?

Gli sviluppatori di IOTA sono stati attaccati duramente su questo punto, anche se di fatto non è mai stata realizzata una discussione pubblica su questo aspetto. Forse proprio questo fatto ha alimentato il mistero e lasciato spazio a illazioni di vario genere. La ragione per questa scelta è in realtà molto semplice: il progetto IOTA nasce in parallelo al progetto JINN, gestito dagli stessi progettisti. JINN è un processore ternario, ovvero una CPU che usa la matematica in base 3 (ternaria) invece che quella in base 2 (binaria) a cui siamo abituati. L’idea di un processore ternario è molto antica (https://it.wikipedia.org/wiki/Calcolatore_ternario) ma quella binaria è stata preferita per la maggiore semplicità di realizzazione delle funzioni logiche di base (AND, OR e NOT) a livello di circuito integrato quando negli anni ‘60 si è iniziato a lavorare il silicio per produrre quello che oggi conosciamo tutti come “chip” o “Circuito Integrato”.

Ma perché è pensare di cambiare sistema?

Il motivo è semplice: il livello di integrazione dei circuiti ha raggiunto il suo limite fisico. Questo implica che non riusciamo a produrre CPU più piccole, che sarebbero più economiche e veloci. Infatti da anni per aumentare la velocità dei comuni processori si sono moltiplicati i “core”, ovvero si sono inserite in un singolo chip più cpu che lavorano in parallelo. La logica ternaria, sebbene più complessa da realizzare è ovviamente più veloce, quindi a parità di compito, il consumo energetico è inferiore. Oggi comunque la complessità tecnica è decisamente più facile da superare rispetto ai pionieri degli anni ‘60. Da dove viene il vantaggio? Per comprendere perfettamente occorrerebbe una complicata dimostrazione matematica (la maggiore efficienza si otterrebbe con una logica in base e, perché il logaritmo naturale è più efficiente per i calcoli in virgola mobile), ma si può intuire con questa osservazione: il numero 27 in binario si scrive con 5 bit, in ternario con soli 3 trits (unità minima equivalente al bit che può avere valore 1, 0 oppure -1). Minore è il numero di bit/trits usati durante un calcolo e ovviamente più velocemente si esegue una moltiplicazione. La logica ternaria è quindi un modo, oggi tecnicamente realizzabile, per superare i limiti della “legge di Moore” che afferma la necessità di dimezzare le dimensioni dei chip per raddoppiarne la velocità. Questo spiega le motivazioni del progetto Jinn, ma non spiega perché adottarlo per IOTA. Qui devo fare alcune ipotesi:

Il motivo che appare più ragionevole è che un processore Jinn sarà in grado di eseguire le funzioni di calcolo di IOTA senza riconvertire in decimale i risultati prima di effettuare calcoli e viceversa. Quindi, le già performanti librerie IOTA, oggi supportate da un piccolo dispositivo come un Raspberry, potrebbero essere utilizzate da oggetti ancora più piccoli ed economici in modo nativo senza doverle adattare alla logica ternaria in quanto lo sono già.
Un secondo motivo è più legato agli aspetti di sicurezza: l’uso del sistema ternario porta a creare un alfabeto di 27 caratteri (da A a Z più il carattere 9 che rappresenta lo zero) che è l’equivalente funzionale del sistema decimale composto invece da 10 caratteri (da 0 a 9). Ipotizzo (andrebbe effettuato un confronto approfondito che non ho ancora avuto tempo e modo di effettuare) che le funzioni di firma e di hashing con 27 caratteri richiedano circa il triplo di costo energetico per poter tentare lo stesso tipo di attacco (27 è circa tre volte 10) a parità di cifre usate per la firma.

IOTA è vulnerabile al double spending. Come affrontano gli sviluppatori questo problema non da poco? IOTA è vulnerabile al double spending. Ma non conviene farlo. Un mito negativo che permane, nonostante siano state pubblicate molte dimostrazioni a riguardo, è che la possibilità di un double spending sia addirittura prevista nel progetto. Prima di addentrami nei dettagli, devo ricordare un fatto ovvio: la sicurezza, fisica o logica, è sempre legata ad un aspetto economico. Ovvero con sufficiente budget si possono creare banconote perfettamente identiche alle originali, si può effettuare un furto informatico, si può abbattere il muro di un cavò o superare ogni barriera tecnologica. È sempre e solo un problema economico, quindi se il bottino non copre le spese non ha senso tentare il colpo. In informatica però questa regola non è del tutto vera. Il danno d’immagine che si può provocare ad un competitor semplicemente dimostrando che è vulnerabile, anche rubando pochi spiccioli, è più che sufficiente per ottenere un vantaggio competitivo. Vantaggio difficilmente misurabile economicamente come effetti nel breve, ma certamente un vantaggio strategico che può almeno rimandare la competizione diretta sul mercato.

Puoi chiarire come funziona il meccanismo di consenso di IOTA? Tenendo in mente questi elementi precedentemente citati vediamo insieme come viene elaborato questo meccanismo: Una transazione IOTA è legata a due precedenti con “hash link”. Questo legame si forma quando un nodo deve pubblicare una nuova transazione. La scelta delle tx a cui collegare la propria può essere effettuata liberamente (la rete è permissionless, quindi non impone un modello di comportamento ai nodi). La pubblicazione di una tx che linka altre due si definisce “approvazione” delle due linkate. Questo perché un nodo corretto dovrebbe verificarle prima di linkarci la propria e quindi così facendo le approva. L’ipotesi che il nodo non le verifichi e per far prima scelga le tx a caso esiste. Tuttavia ogni nodo ha interesse a vedere validate e poi confermate le proprie tx il prima possibile e se gli altri nodi vedono che la tx approva due tx invalide, non la sceglieranno per linkare le proprie. Quindi la tx anomala non verrà mai confermata. Invece di scegliere a caso, il nodo che pubblica è incentivato a controllare la validità delle transazioni che sceglie. Il controllo consiste nel percorrere a ritroso tutta la sequenza di tx linkate tra loro alla ricerca di un eventuale double spending e ovviamente termina in modo positivo o cambiando tx viene individuata una anomalia. Questa ricerca non è tuttavia sufficiente. Il nodo infatti ha effettuato il percorso a ritroso partendo dalle sole tx che ha scelto, ma in altri percorsi paralleli non raggiungibili partendo da quelle tx, si potrebbe nascondere un double spending. Questo rischio viene analizzato con il progressivo allungarsi delle catene: ogni nodo che inserisce una nuova transazione va ad analizzare i possibili percorsi alternativi. Approvando altre tx che in parallelo portano a una tx candidata alla conferma, si ottiene un controllo multiplo effettuato da molteplici nodi in modo indipendente, ovvero il consenso distribuito. In sintesi, affinchè una transazione venga considerata confermata occorre che sia approvata indirettamente, ovvero esista un percorso che conduce a lei, da ognuna delle nuove tx entrate e non ancora approvate. Così facendo ogni possibile double spending viene individuato. Questo modo di operare che ho appena descritto esclude ogni possibile double spending, ma a certe condizioni. Ipotizziamo che in un certo momento la rete possa essere molto scarica, con una nuova tx ogni dieci minuti. In questo scenario ipotetico un nodo malevolo potrebbe creare due tx mandando per esempio IOTA a un exchange, e per ottenere il consenso inserisce molte nuove transazioni che vanno rapidamente (certamente in meno di 10 minuti) a creare effettivo consenso sulla sua prima tx. A questo punto può effettuare una seconda tx che punta a prendere lo stesso ammontare di IOTA dall’address già usato dalla precedente confermata. Questo address è ormai vuoto (in IOTA il resto di una tx viene sempre spostato in un nuovo address) quindi la transazione non verrebbe approvata da altre entrate generate da altri nodi, ma dato che la rete è scarica c’è tutto il tempo necessario per il nodo malevolo per generare altre tx che la approvano e in breve ottenere conferma. Questo è l’unico caso in cui il double spending in IOTA è realizzabile: è un caso ipotetico in cui il livello di transazioni in rete è estremamente basso. Questa condizione in realtà non si realizza grazie alla presenza di molti nodi che generano transazioni proprio per garantire la sicurezza della rete, ma non solo. La rete ha infatti una resilienza interna data dalla topologia:

La rete dei nodi IOTA, a differenza delle altre piattaforme non è “flat”, ma partial mesh. Ovvero un nodo comunica direttamente solo con un piccolo numero di nodi (di solito tre o quattro solo per avere sufficiente garanzia di non rimanere isolato) che ricevendo le sue tx le propagheranno ai loro vicini e viceversa. Questa topologia non è gestita centralmente e non è necessariamente statica.
Per inserire una transazione in rete e ottenerne la propagazione occorre che una tx abbia tre caratteristiche: un “time stamp” valido (non sono accettate tx pre o post datate), il totale di IOTA in ingresso e uscita deve essere zero, l’hash deve soddisfare i requisiti di anti spam, ovvero è stato eseguito un POW alla ricerca di un parametro che renda valido il formato dell’hash.

Questi dettagli implicano che la creazione di nuove tx non è un’operazione che può essere effettuata con successo anche mettendo in campo molte risorse computazionali. Infatti oltre a dover effettuare il POW (che non è costoso come quello di Bitcoin) dovremmo avere il controllo della topologia della rete: supponiamo di avere un potente nodo in grado di generare sufficienti tx/s per confermare da solo una tx anomala e che a molti “salti” di distanza ci sia un minuscolo Raspberry. A più di 100 nodi di distanza occorrono un paio secondi affinché le nostre transazioni malevole si propaghino. Non avendo il controllo diretto di tutti i nodi della rete non possiamo impedire che in quei due secondi il Raspebbery generi una tx e la inserisca nel tangle e la propaghi in rete. Il Raspebbry non vede ancora la nostra tx anomala in double spending quindi andrà a scegliere un paio di tx corrette (magari già approvata da una malevola, non è vietato) creando un percorso parallelo alle nostre. In questo modo una sola tx valida può vanificare il tentativo di confermare la nostra in double spending. Il comportamento che ho descritto è semplificato, ma descrive in modo comprensibile la caratteristica unica di IOTA: la rete è asincrona e quindi è impossibile pianificare un attacco in double spending semplicemente ragionando in termini di potenza di calcolo necessaria. Occorrerebbe avere un controllo della topologia che tuttavia non è gestita.

Parliamo un po' del Coordinatore: che cos'è e come funziona. Da quanto appena definito si potrebbe definire IOTA come una rete super sicura. Ovviamente il double spending non è l’unico tipo di attacco e in generale, come dicevo all’inizio, tentare di screditare un competitor può essere l’obiettivo che giustifica molti forzi. Quindi è normale aspettarsi tentativi creando migliaia di nodi che creano migliaia di transazioni al secondo, o più semplicemente creare delle lunghissime sequenze di transazioni invalide che possono rallentare il processo di conferma delle tx valide, ecc. ecc. Tutti questi tentativi sono possibili con costi contenuti se il livello di carico della rete è molto basso. Livello che crescerà ovviamente con l’adizione del sistema ma che per ora resta sotto limiti critici. Per evitare questo problema la fondazione IOTA eroga un servizio di “convalida” mediante un nodo particolare chiamato Coordinatore. Occorre precisare che:

Il coordinatore non ha potere di firmare tx altrui quindi non può commettere frodi: le chiavi private sono appunto private e non sono gestite o gestibili dal coordinatore
Il coordinatore non ha alcuna funzione di controllo dei nodi. Il codice dei nodi è open e chiunque può verificare che un nodo non ha backdoor o che accetta comandi da entità esterne di controllo
Il coordinatore non conferma le transazioni modificando in qualche modo lo stato del ledger.

L’unica funzione che svolge il coordinatore è creare delle transazioni che come ogni transazione vanno ad approvare una tx. La funzionalità conferma è sostanzialmente il significato che viene dato alle tx del coordinatore: se le approva lui sono certamente valide. La conferma da parte del coordinatore avviene dopo che la tx è già stata valutata e approvata da altre tx. Infatti la regola della conferma della transazione solo se approvata direttamente o indirettamente da tutte le nuove tx, resta valida e la conferma da parte del coordinatore è aggiuntiva. Volendo può anche essere ignorata. Il coordinatore quindi da evidenza del possibile tentativo di frode non approvando una tx anomala. In pratica il coordinatore si comporta come un delegato di un sistema POS che svolge la funzione di controllo di ultima istanza. Quando sarà possibile rimuoverlo? La fondazione IOTA ha fatto molte simulazioni e la teoria matematica che sta alla base del progetto e che ipotizza la convergenza del sistema al crescere delle TPS che la rete supporta è stata dimostrata formalmente da un giovane matematico, poi entrato anche lui nell’organizzazione. Il dato preciso non è stato divulgato, ma possiamo fare un’ipotesi: oggi il coordinatore genera una milestone ogni 30 secondi, periodo nel quale oggi entrano circa un centinaio di transazioni, ovvero circa 200 Tx/min. Questo è un livello molto basso (sono stati già registrati numeri molto maggiori) che può permettere un attacco. Con due ordini di grandezza superiori, 20.000 Tx/min, ovvero circa 330 tx/secondo, il livello di complessità di un attacco dovrebbe iniziare a essere scoraggiante. Abituati a numeri ben più bassi di Bitcoin e Ethereum, 330 Tx/s sembrano un numero enorme, ma data la natura asincrona della rete in realtà non sono affatto numeri che possono rappresentare un problema: 1.000 nodi (numero già oggi raggiunto dalla rete) che fanno 1 tx ogni due secondi hanno sono già in grado di raggiungere questo livello. Se questo dato comunque non fosse convincente, basti pensare ad alcuni dei progetti di adozione che andranno in esercizio nei primi mesi del 2019:

Qubic, di cui parlo più approfonditamente dopo, porterà migliaia di transazioni economiche e molte di più non economiche sulla rete IOTA.
Volkswagen, Bosh e Fujitsu hanno dichiarato pubblicamente che adotteranno IOTA almeno per la memorizzazione dei dati dei loro sistemi. Per esempio ipotizzando che una automobile VW memorizzi i dati medi orari sul tangle, i previsti 60.000 modelli venduti nei primi mesi del 2019 dovrebbero produrre un picco di 60.000 tx/ora pari a 1.000 Tx/minuto.

Lo scenario è quindi in evoluzione verso una condizione di stabilità dove il Coordinatore potrebbe essere presto rimosso. Tuttavia alcune indiscrezioni lasciano intendere che tra i vari filoni di ricerca vi sia anche uno che punta ad un obiettivo diverso: invece che rimuovere il coordinatore, decentralizzarlo. Non ho elementi per commentare questa ipotesi, ma se la decentralizzazione fosse effettiva non richiedesse alcuna ricompensa, potrebbe essere un’ottima idea. Infine per completezza devo citare il lavoro di Roman Semko, sviluppatore indipendente che lavora sulla piattaforma IOTA creando componenti aggiuntivi, come il sistema “field” che automatizza la creazione di una topologia dinamica della rete. Roman sta lavorando su un modello di consenso alternativo a quello ufficiale. In questo modello non è previsto il coordinatore e stando alle prime dichiarazioni la conferma può essere ottenuta in pochi secondi. Cito questo progetto anche se è ancora in gestazione per evidenziare una caratteristica unica di IOTA: non essendoci remunerazione dei nodi che sostengono la rete è possibile far convivere sulla rete stessa molteplici modelli di consenso, ovvero diverse tipologie di nodi che potrebbero gestire il consenso sulle tx in modo diverso pur movimentando comunque la coin IOTA. Per esempio per piccoli importi la conferma potrebbe essere considerata raggiunta già prima del completamento del processo standard se questa è “effettuata” da nodi con un dato ranking di credibilità. Un altro metodo è la creazione di tx con doppia firma, una delle quali è eseguita da un nodo di servizio che effettua la verifica della tx prima di firmarla. Ovviamente sono ipotesi, e in alcuni casi di sistemi semi-centralizzati. Questo può non soddisfare i più appassionati del modello Satoshi, ma può invece trovare molti riscontri in ambito industriale.

Diamo uno sguardo al futuro, Qubic? Ho accennato poco fa al progetto Jinn, ma Jinn non è l’unico nato dagli stessi progettisti di IOTA. Un altro, che anzi sembra aver ispirato IOTA, è Qubic. Qubic è, in estrema sintesi, un sistema di calcolo distribuito. Qubic indirizza un tema che le piattaforme crypto hanno solo parzialmente affrontato senza risolverlo: come ottenere consenso distribuito su una transazione non economica. Gli Smart Contract di Ethereum sono un esempio di sistema di calcolo distribuito che produce consenso su un output prodotto da un programma. Tuttavia, l’output di uno SC che elabora dati non economici non può essere considerato del tutto attendibile in assenza di consenso sui dati di input. Il motivo è legato ai limiti del sistema di programmazione di un SC che non permette l’accesso a dati esterni alla blockchain (sarebbe complesso garantire l’accesso a generici dati esterni da tutti i nodi, anche migliaia, che contemporaneamente devono eseguire lo SC). In pratica nell’effettuare un'elaborazione non economica un SC deve usare dati inseriti nella blockchain da un soggetto terzo. Lo SC si deve fidare ed eventualmente qualcun altro dovrà poi valutare ex-post la loro validità, con un processo centralizzato. Oltre a questo aspetto, gli SC di Eth sono ovviamente inefficienti: tutti i nodi della rete che partecipano al processo di mining devono eseguire questo calcolo. Ciò comporta costi significativi per la rete che non può scalare. Qubic indirizza e risolve questo tema:

Un Qubic è il programma che deve essere eseguito.
Un Assembly è un gruppo di nodi che esegue un Qubic. I nodi dell’Assembly ricevono una ricompensa dal proprietario del Qubic per aver svolto correttamente il compito.
Abra è il linguaggio di programmazione con cui si scrivono i Qubic. Abra permette al Qubic di accedere a qualsiasi tipologia di dato e servizio esterno.
Ogni nodo di un Assembly è indipendente ed esegue in parallelo il Qubic. Il risultato viene confrontato e considerato valido se la maggioranza dei nodi dell’Assembly ha ottenuto lo stesso (consenso distribuito).
Dato che ogni nodo ha indipendentemente eseguito il Qubic, ha anche indipendentemente acquisito i dati di input. Quindi nell’ottenimento del consenso sull’output si ottiene consenso anche sui dati di input e quindi sull’intera transazione non economica.

Qubic quindi permette a chi vuole eseguire un algoritmo in modo decentralizzato, di scegliere un Assembly con determinate caratteristiche (potenza di calcolo, sicurezza, affidabilità, …) e ottenere un risultato che ha avuto il consenso da parte dei nodi dell’Assembly. Sceglierà grandi e potenti Assembly per calcoli critici e complessi, oppure piccoli ed economici Assembly per calcoli meno critici e più semplici. Ovviamente i nodi verranno remunerati con IOTA e questo è uno dei tanti motivi che spiegano perché creare IOTA: tanti piccoli calcoli portano a tante piccole transazioni economiche che non possono essere gravate da fee e devono avere rapide modalità di conferma. Il rilascio di Qubic è previsto per l’ultima parte del 2018.

E il baco della funzione CURL? Come viene affrontato? Uno degli argomenti che spesso viene usato per sostenere una certa debolezza della piattaforma IOTA è l’adozione di una funzione di hash “realizzata in casa”. Questa scelta è stata criticata dai matematici che sono stati chiamati a fare delle valutazioni, tuttavia non sono stati presi in considerazione le motivazioni: la firma delle tx IOTA si basa sulla funzione di hash ed è pertanto fondamentale che, oltre ad essere sicura, sia anche eseguibile in modo efficiente da piccoli dispositivi. Ovviamente la scelta è stata motivata anche dalla convergenza dei progetti IOTA e JINN. Ma questo non spiega ne giustifica quanto individuato dal team MIT-DCI già a metà del 2017. Il team di ricercatori ha infatti individuato un caso di collisione sistematica della funzione: le funzioni di hash producono un output di dimensioni fisse a partire da un input di dimensioni indefinite e l’output dovrebbe cambiare di più del 50% al cambio anche di un solo bit del dato di input. Si tratta di una funzione matematica fondamentale su cui si basa, ad esempio, la firma elettronica dei documenti: invece di criptare un documento di decine di MByte con la propria firma chiave privata, si esegue la criptografia dell’hash del documento. E’ chiaro quindi che una generica funzione di hash dovrebbe avere un numero minimo di collisioni, idealmente zero. Una ovvia caratteristica della funzione di Hash è l’impossibilità di invertire il processo: da un hash non si può costruire i dati di input, quindi è sicuro pubblicare l’hash di un dato di per dimostrare di averlo avuto a disposizione. Prima di proseguire devo per correttezza evidenziare che nessuna funzione di hash ha mai ottenuto la dimostrazione formale dell’impossibilità di produrre collisioni, ma solo una valutazione statistica. Per esempio il 23 Febbraio 2017 è stata pubblicata l’individuazione di una collisione sulla funzione SHA-1, ancora oggi molto utilizzata in applicazioni mobili: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html Infine occorre considerare come la funzione di hash viene utilizzata. Nel caso di IOTA la CURL è tuttora usata per generare gli address partendo dal Seed, e veniva usata per creare dall’address la chiave privata e la firma di una tx. Appare quindi evidente la gravità della scoperta del team di ricercatori. Infatti la fondazione IOTA ha subito sostituito la CURL nelle librerie che effettuano la firma digitale con la KERL, ovvero la versione ternaria della KECCAK-256 usata da Ethereum, dichiarando l’intenzione di proseguire le ricerche per la creazione di una propria funzione di hash certificata poi da ricercatori indipendenti. Quindi la vicenda avrebbe dovuto concludersi in modo civile, come normale che sia in un sistema open source dove la comunità di ricercatori è appunto invitata a trovare difetti e aiutare a correggerli. Invece, le cose non sono proseguite in questo modo. Una serie di mail, pubblicate poi da una testata online hanno evidenziato che il team di ricercatori avrebbe voluto pubblicare il documento di ricerca dove oltre all’evidenza del baco veniva affermato con forza (rafforzata dall’appartenenza a prestigiosi istituti) che esso permetteva di effettuare il riutilizzo della firma e quindi sottomettere in rete una seconda transazione perfettamente valida che di fatto consisterebbe in un double spending. In effetti il documento è stato pubblicato senza convergenza sul contenuto. Tuttavia questa ipotesi non è mai stata dimostrata e ad onore del vero è stato dimostrato il contrario, partendo proprio dalle evidenze di quanto scoperto. Provo a spiegarlo con le parole più semplici possibili:

La collisione individuata si verifica solo se i due input differiscono in punto particolare. In pratica i due dati di input devono essere identici tranne per una lettera in una precisa posizione.
Grazie a questo baco sarebbe pertanto possibile ottenere la stessa firma partendo da due transazioni diverse, ma il set di informazioni che compongono le due transazioni dovrebbe essere identico tranne per una lettera nella precisa posizione. Se non è così l’output della funzione CURL è comunque diverso.
Per poter avere successo nella creazione di una tx valida che sposta IOTA devo pertanto prendere la transazione che voglio clonare modificare i dati che la compongono producendo però solo un byte di differenza.

Affinché la tx sia valida e quindi propagata in rete devo almeno cambiare il time stamp e questo già rende il dataset di input molto diverso. Se cambia il time stamp occorre poi cambiare il nonce che valida l’hash (ovvero rieseguire POW), ma nuovamente il dataset cambierebbe notevolmente. In sintesi è impossibile riuscire ad usare questo baco per fare un attacco. C’è poi da aggiungere che la tx che voglio clonare non potrebbe comunque essere confermata senza il supporto di un sistema che genera tx malevole, perché appunto in double spending. Infatti se volessi rubare delle IOTA dovrei farlo cambiando anche l’address di ingresso, ma questo comporterebbe un cambio completo della chiave privata derivata appunto dall’address e ciò comporterebbe che la firma non sarebbe comunque valida. In conclusione, come anche emerge dalle conversazioni intercorse tra Fondazione IOTA e team di ricercatori pubblicate, appare evidente il tentativo di buttare artificiosamente benzina sul fuoco da parte del team dei ricercatori, per motivi che evidentemente nulla hanno a che fare con scienza, matematica e ricerca.

Stefano della Valle (IOTA Evangelist Network) Service Level Agreement Concludo questa intervista in cui ho analizzato i principali punti di criticità attribuiti a IOTA con qualche nota positiva. Quando un sistema è molto diverso da tutti gli altri è inevitabile avere dei dubbi, ma con un po’ di impegno si possono approfondire tutti gli aspetti e farsi un’idea più precisa e talvolta alcune caratteristiche che appaiono curiose o addirittura "difetti", divengono interessanti. Per esempio, la possibilità di gestire i propri nodi senza diventare “miners” è molto sottovalutata: avere un proprio full nodo in azienda non solo garantisce di poter processare delle transazioni a costi predefiniti e di avere garanzie di affidabilità (se occorre ne attivo due), ma permette soprattutto di ricevere istantaneamente transazioni dati inviate da altri nodi, con la garanzia che non potranno andare perse, perché memorizzate sul tangle. Questo è il motivo che ha spinto Bosh e Volkswagen ad adottare IOTA e Fujitsu addirittura a proporla come nuovo standard per le comunicazioni tra dispositivi IoT. Queste semplici caratteristiche rendono IOTA unica e utilissima per le applicazioni industriali e giustificano molte delle scelte tecniche apparentemente curiose adottate dai progettisti. [sc name="firma"]

Posted from my blog with SteemPress : http://www.cryptominando.it/2018/09/04/iota-stefano-della-valle/

Topics