Blockchain e Radix: “Diarix dal campo di battaglia con l’esercito di Bisanzio”.
Di Andrea Ciacchella (MY LIFE FACTORY e CIO BlockchainTerni)
Se al giorno d’oggi ci potessimo avvalere con la testimonianza fisica di almeno 1 generale bizantino d’allora, sicuramente ce lo ritroveremo esterrefatto e non solo per il salto di più di 1500 anni.
Questo perché, l’impresa umana di predisporre la tecnologia nel risolvere il dilemma generato della stessa variabilità umana, rispetto all’esercizio del tradimento o all’obbedienza verso un’autorità, ha elaborato in quest’ultimo decennio tante di quelle varianti, che il pover’uomo rimarrebbe ugualmente senza certezze e senza soluzione, ancora per un pò.
Ma evitando d’approfondire sull’etica della natura umana, sempre in attesa che la “AI” intervenga dove la mano dell’uomo vacilli, nel frangente momento, diverse soluzioni sono sorte per porre alle strette l’incertezza sul ” consenso automatico ” e far scivolare velocemente l’economia mondiale, alla ricerca del prodotto più personalizzabile possibile.
Una delle compagini, che a mio avviso, è andata ben oltre lo sviluppo del protocollo bitcoin in questi ultimi anni, è RADIX DLT.
Da Newcastle UK, Dan Hughes il fondatore e il suo team sono stati per ben 5 anni lavorando in sordina, contando sulle proprie forze economiche, sapendo che se non tiravano fuori una soluzione geniale, non sarebbero mai stati in grado d’influire sulla scelta della tecnologia per l’implementazione del consenso automatico distribuito e regolato dagli Smart Contracts (ne abbiamo parlato qui), per i prossimi anni.
Quando nel 2018 hanno reso pubblico: codice e proposta imprenditoriale; non c’è stato un grande scalpore, anzi, qualcuno l’ha buttata la come un’altra noiosa architettura blockchain, allontanando i riflettori da questo progetto, che invece vale la pena cercare di capire, nell’innovazione che presenta.
Iniziamo con puntualizzare che Radix non è una blockchain e neanche una DAG ( Grafo Aciclico Diretto ). Punto.
L’approccio a questa tecnologia sembra ricalcare in grandi linee lo studio avvenuto per dare un nome e una ragione alla stessa vita che interpretiamo oggi, cioè la scoperta dell’elemento più piccolo esistente ( fino a pochi anni fa): l’Atomo. E quella dell’Universo che tutto lo racchiude.
Da Democrito a Hubble passando per Dalton fino a Rutheford, attraverso la vita dell’Atomo si costituisce la materia e così dovrà essere anche per la DLT di Radix.
L’Atomo viene creato e sparato in Rete, esattamente in un Universo di Tempo, quest’ultimo definisce lo spazio-Network dove saranno presenti i Nodi.
Il Nodo non è altro che un computer o un dispositivo che abbia installato il software Client nativo.
Gli Atomi sono di 2 tipi: carico ( payload) e di trasferenza (transfer).
In Tempo appena succede un nuovo evento (transazione o messaggio) un Atomo viene a generarsi e avrà al suo interno: 1 indirizzo di end-point di default, per renderlo indicizzabile, la private Key dell’operatore, una serie di dati e metadati rispetto al proprietario e all’oggetto di scambio, un importo in valuta (se consiste in una trasferenza è richiesto ), il destinatario dello scambio e la firma dell’operatore.
Un Atomo potrebbe anche contenere altri atomi, fin quando il peso complessivo non superi i 64kb, che rappresenta il max consentito per sostenere la velocità assicurata nell’invio agli altri Nodi vicini, della transazione o il messaggio.
Sempre attraverso i Nodi, si vengono a immagazzinare i frammenti (shards) che non è altro la struttura fisica costituente il database di Radix.
Questi frammenti, per le loro caratteristiche di poco ingombro, nonostante la presenza in un numero, calcolato in 2*64, permettono all’indicizzazione di effettuare un lavoro relativamente semplice per ritrovare i dati richiesti nei frammenti inerenti e risalire a tutti gli eventuali proprietari e Nodi precedenti per dove sono passati, in virtù del fatto che gli Atomi di trasferenza, che fanno un pò da facchino, sono replicati su più Nodi per mantenere la fruibilità delle informazioni che racchiudono.
Ma veniamo all’operatività di questo database distribuito attraverso i frammenti.
Nel momento che un operatore costituitosi in un Nodo (si presume che dovrà identificarsi e una volta fatto non potrà modificare le sue coordinate), crea e invia un Atomo dove sono presenti il suo ID, la Private Key, la firma, il bene e/o servizio che vuole scambiare (se si trattasse di valuta e/o token deve inserire la Pubblic Key del Wallet) e infine il destinatario della transazione, automaticamente si vengono a creare diversi Atomi di trasferenza contenenti:
le precedenti informazioni nell’Atomo di carico (payload) più le caratteristiche dell’oggetto (nello stato primario al momento che viene caricato sul Network) e questi Atomi si insedieranno nei Nodi di prossimità, generando di conseguenza il fenomeno del Gossip, che non è altro la scissione degli Atomi di trasferenza in particelle più piccole, ma sempre rispettando la formazione base, perché provvisti degli end-points necessari per l’indicizzazione.
A rigore di ciò, per garantire un livello superiore agli standard di sicurezza attuali, ogni Nodo è provvisto di un orologio logico che registra ad ogni evento = creazione di Atomo, una unità temporale parallela dentro Tempo ( una specie di badge) e solo una alla volta.
Infatti, ogni volta che un evento viene a crearsi, automaticamente lo script esegue una Prova temporale, apponendogli una data, per confermare che quell’Atomo possiede la coerenza dimostrabile dalle particelle precedentemente sparate ai Nodi di prossimità, ma presenti in più frammenti che non sono riconducibili, per il senso inverso, in caso di “double spend”, ad alcun altro Atomo, per il fatto che la data apposta è sempre univoca con rispetto ad un evento e tutte le altre prove temporali presenti nell’Atomo, saranno sempre precedenti a quella dell’evento creato.
A tutti gli effetti la Prova temporale, se per costituzione non è parte di un Atomo, è a sua volta atomizzante per trasmettersi ai Nodi circostanti inoltrando la richiesta di convalidazione della transazione in corso.
Mentre tutto ciò avviene, i dati richiesti si vanno agglomerando per formare un insieme di dati assemblati su: posizione, data d’impressione, hash dell’Atomo alla creazione, infine eventuali Nodi osservatori.
Quando il protocollo di convalida accerterà che c’è coerenza al 51% ( perché andare oltre a spendere tempo?), la transazione verrà eseguita e un’altro Atomo con il bene scambiabile Xa, sarà immagazzinato nel frammento del registro distribuito, con l’ID di un’altro proprietario del bene scambiato.
In questa prima parte dell’attività di scambio di Atomi tra i vari Nodi, appare evidente il protagonismo assoluto degli stessi Nodi, con la conseguente domanda che considero lecito porsi:
“Chi ci sarà dietro ai Nodi?” , “Sarà permesso creare consorzi, con un limite di quanti Nodi ognuno?” , ” Saranno necessarie verifiche in ordine ad una proposta d’intenti dell’operatore?”
Questo e quant’altro riguardi la futura sicurezza di tutto il Network, hanno in assoluto, la legittimità del mondo per essere formulate, in ragione della semplice equazione: nessuna applicazione informatica che si sviluppa in un ambito pubblico sarà al 100% sicura, finchè tutte le possibili vulnerabilità siano prese in considerazione e risolte.
Anche perché i test eseguiti in fase di sviluppo, non vedranno mai delle soluzioni globali come quando si è effettivamente in produzione.
Nessun CIO vorrà mai arrivare a gestire questa incresciosa situazione. Quindi se nei Nodi risiede il potere di condizionare il libero flusso degli eventi, come prevedere ogni tipo di intrusione maligna?
Oltre a permettere una ampia eterogeneità di partecipanti che consentirebbe la decentralizzazione selvaggia, un’opzione fattibile per mantenere al sicuro il Network da tendenze accentratrici e una delle soluzioni a mio avviso più innovative, è l’introduzione di un protocollo di validazione Merkle Hash, che sancisce la costante attività di ogni Nodo a modo riassuntivo, come un post-it momentaneo, dove viene applicato il principio della Prova temporale come nella creazione di un Atomo.
Queste specie di backup, che rappresentano dei dati sansibili a tutti gli effetti e avranno le stesse caratteristiche dell’Atomo, non è dato definito ancora sul dove saranno sparati, ma il buonsenso in questo caso suggerisce d’inviarli a Nodi certificati e quindi protetti da ulteriori firme proprietarie; quindi un’orbita di Nodi di classe superiore, quello che sarà probabilmente il Core del Network di Radix.
Nella parte seguente per capire il complesso dell’attività di Tempo, ci sarebbe da interpretare come interagiranno le differenti potenze di calcolo, in base all’hardware di ogni dispositivo connesso al Network e quali saranno gli incentivi offerti per partecipare.
Questa incognita alla quale faccio riferimento, in realtà non esiste nelle strutture vincolate al protocollo Bitcoin, infatti le maggiori potenze di calcolo si accaparrano il grosso della ricompensa alla finalizzazione del blocco, mentre agli altri vengono lasciate solo le briciole.
Un operatore di queste catene di blocchi, dovrà porsi un giorno la domanda se continuare a perdere progressivamente tutti i margini a disposizione o cercare un Network dove si garantisca perlomeno un margine accettabile di stabilità.
Nella struttura Sharding di Tempo, invece ogni Nodo avrà l’opzione di processare gli shards annidati, che il sistema operativo del dispositivo gli permetterà.
Il software Client che sarà rilasciato prevederebbe assegnare maggiore incidenza di calcolo ai processori più potenti, identificati con l’ID e i metadati annessi, per alleviare il lavoro di validazione a quelli con minor potenza, proprio come i dispositivi cellulari.
Gli ultimi Smartphones in commercio stanno infatti provvedendo a creare un sistema di archiviazione, probabilmente in SHA-1 e SHA-2, per estremare la privacy utente in caso di connessione a networks blockchain.
Niente si muove per caso e certe scelte aziendali vanno rispettate per quello che sostengono, specialmente se sono i grandi players a cavalcarle.
Con un’attenzione particolare all’affrontare il fabbisogno d’energia che si andrà a generare con soluzioni che siano percorribili nel medio – lungo termine, visto che le questioni cambio climatico: #climatechange #ClimateActionNow sono sulla scala delle max priorità da sostenere nei centri direzionali delle Big M, alle Blue chips incluse.
Tutti devono lavorare per adattare i processi produttivi alla contingenza del momento storico che viviamo, con l’esponenziale sfruttamento degli eco-sistemi non più in grado di rigenerarsi allo stesso ritmo di quando l’umanità era solo alla 1ª Rivoluzione industriale.
Anche se da allora gli studi scientifici si sono moltiplicati, l’applicazione di queste teorie hanno trovato ancora troppo poco spazio operativo.
L’end- point-no-reverse si sta trascurando per condiscendere all’ego insaziabile della finanza speculativa.
E non è la solita “morale della favola“, ma c’è da stare accorti a tutti i livelli.
Le aziende dell’ITC, Dig.ECO, BLCH, devono quindi guardare oltre il ROI programmato e accellerare sull’implementazione del consenso distribuito, perché ci sono le premesse ideali per garantire la trasparenza, la sicurezza e l’affidabilità delle transazioni e distribuire valore dove ce n’è più bisogno, in un ambiente scalabile progressivo.
Queste sono le caratteristiche fondamentali, che ogni imprenditore entusiasmato dalla tecnologia blockchain dovrebbe richiedere per il suo progetto: con una piattaforma predisposta a crescere di forma esponenziale e che contribuisca a rendere la decentralizzazione un motore costante per il consenso, mai così prima equamente distribuito e sicuro.
Nel piano impresariale, nei Business plans, vengono realizzate previsioni basate sulla coincidenza di una quantità troppo elevata di variabili, perciò è essenziale orientare i progetti verso strutture dove la breaking news del “data breach dove non ce l’aspettavamo“ sia un’evento critico da analizzare e ridurre a rischio infinitesimale, ma molto a priori.
Sappiamo bene che le certezze si costruiscono giorno per giorno e dopo anni di lavoro di squadra, perché di esempi se li cerchiamo ne troveremo tanti.
Le analisi delle variabili ambientali dove si muove un progetto e il confronto con i valori positivi riscontrati nella fase di sviluppo, devono indubbiamente portare ad individuare quei segmenti di successo dove far incidere il processo costruttivo in fase di produzione.
Il confronto esistente con più developers in contatto con Radix in questi ultimi mesi, è da a intendere la propensione al richiamo partecipativo e alla conferma di tutte le buone premesse.
In questa del tutto personale trattazione, per quel sesto senso che il più delle volte ha permesso di orientarmi nell’esercizio della navigazione tra gli uomini, connessi o meno, quella situazione che non ti genera dentro troppa apprensione e confusione, la sono stata palpando nel leggere e seguire in questi ultimi mesi, il progetto di Radix DLT.
Io sostengo questa visione e mi adopererò per presentarla al pubblico, ovunque sia chiamato in causa il principio del consenso distribuito.
Chiederò l’aiuto di Dan o Piers su come fornire maggiori informazioni sull’implementazione dei Nodi e l’eventuale carico di lavoro per studiarne come inciderà sull’infrastruttura TCP/Ip italiana e presentare dei case study alle aziende che mostrino interesse per questa soluzione.
Solo per concludere, mi sembra di dover ricordare – Ad memoriam dei generali bizantini che sacrificarono le loro vite, senza mai arrivare alla soluzione definitiva del problema – noi crediamo in Radix DLT!
Andrea Ciacchella (MY LIFE FACTORY e CIO BlockchainTerni)
Desideri una consulenza o supporto legale? Scrivi alla nostra segreteria, ti contatteremo per approfondire la tematica e formulare il nostro miglior preventivo.
