Ethereum Developer Course for Blockchain Innovation Manager (BIM)

Concetti Generali

In questo modulo si apprenderanno i concetti fondativi che sono alla base di ogni piattaforma blockchain

Il primo lavoro accademico su una "catena di blocchi" crittograficamente protetta risale al 1991 ed è attribuito a Stuart Haber e W. Scott Stornetta i quali implementarono un sistema in cui i timestamp dei documenti inseriti non potevano essere manomessi man mano che questi venivano aggiunti al sistema. L'anno successivo, Bayer, Haber e Stornetta incorporarono gli alberi Merkle nella progettazione dell'iterazione successiva della loro creazione, migliorando l'efficienza del sistema consentendo di includere molti certificati di documenti in un solo blocco.

Tra questo primo esperimento con le "catene di blocchi" e la creazione di Bitcoin si sono susseguiti alcuni sistemi embrionali di pagamenti digitali, a partire dal protocollo ecash di David Chaum e Stefan Brands. Nel mentre, Adam Back sviluppava "hashcash", il precursore degli algoritmi "proof-of-work". Vi furono anche dei primi progetti di criptovalute distribuite basate sulla scarsità digitale: b-money di Wei Dai e "bit gold" di Nick Szabo. Nello stesso periodo, Hal Finney sviluppava hashcash migliorandolo al punto di ottenere un primo algoritmo "proof-of-work" riutilizzabile (detto RPOW).

Il primo vero progetto blockchain completamente formato viene disegnato da una persona (o un gruppo di persone) tuttora conosciuta con lo pseudonimo di Satoshi Nakamoto, nel 2008. Nakamoto non solo seppe collegare fra di loro le tecnologie dei suoi precedessori, ma migliorò notevolmente il loro design come esemplificato dal metodo, simile a Hashcash, utilizzato per aggiungere nuovi blocchi senza la necessità dell'autorità di un intermediario. Nakamoto implementò il proprio design l'anno successivo come componente principale di un sistema per una criptovaluta: Bitcoin, in modo che fungesse da registro pubblico per tutti gli scambi di Bitcoin sulla rete.

Il 18 agosto 2008 viene registrato il dominio bitcoin.org. Più tardi in quell'anno, il 31 ottobre, un link a un documento scritto da Satoshi Nakamoto (pseudonimo di una o più persone) intitolato "Bitcoin: A Peer-to-Peer Electronic Cash System[1]" appare in una mailing list di crittografia. Questo documento spiega come utilizzare una rete peer-to-peer per generare ciò che Satoshi Nakamoto descrive come "un sistema per le transazioni elettroniche senza fare affidamento sulla fiducia". Il 3 gennaio 2009, la rete Bitcoin nasce quando Satoshi Nakamoto mina il blocco di genesi, con una ricompensa di 50 BTC. Incorporato in questo blocco è scolpito il testo: The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.[2]

Il 9 gennaio 2009 viene rilasciato tramite SourceForge.net il primo client open-source di Bitcoin.

Uno dei primi sostenitori di Bitcoin nonchè ricevente della prima transazione BTC fu proprio il programmatore Hal Finney. Infatti, Finney scaricò il software client il giorno in cui venne pubblicato e ricevette come ricompensa 10BTC da Nakamoto (l'unica persona con un bilancio), il 12 gennaio 2009. Altri sostenitori iniziali furono Wei Dai e Nick Szabo, entrambi creatori dei progetti precursori a Bitcoin.

Verso la fine del 2013, mentre i punti di forza del modello di Bitcoin iniziavano a manifestarsi ad un pubblico sempre maggiore, la comunità di sviluppatori si adoperava già per portare il progetto oltre alla "semplice" applicazione monetaria. Tuttavia, gli sviluppatori avevano un primo enigma da affrontare: costruire sopra Bitcoin o creare un'altra blockchain; costruire su Bitcoin significava sottomettersi ai limiti intenzionali della rete e cercare di trovare continuamente soluzioni alternative. L'insieme limitato dei tipi di transazione, di dati e delle dimensioni di memorizzazione sembrava limitare fortemente il numero di applicazioni la cui esecuzione poteva essere viabile su Bitcoin; qualsiasi altra applicazione avrebbe necessitato di "off-chain layers" e ciò avrebbe annullato molti dei vantaggi dell'uso di una blockchain pubblica. Per i progetti che necessitavano di maggiore libertà e flessibilità (rimanendo "on-chain"), una nuova blockchain era l'unica opzione.

Nello stesso periodo, Vitalik Buterin, un giovane programmatore e appassionato di Bitcoin, iniziava a pensare come estendere ulteriormente le capacità di Bitcoin e Mastercoin (un protocollo di overlay che ha esteso Bitcoin per offrire "smart-contracts" rudimentali). Nell'Ottobre dello stesso anno, Vitalik proponeva un approccio più generalizzato al team Mastercoin, (con cui lavorava personalmente) che consentiva contratti flessibili e programmabili (anche se non ancora "Turing-complete") per sostituire il linguaggio contrattuale specializzato di Mastercoin. Mentre il team di Mastercoin riconosceva il valore dell'idea, questa proposta significava cambiamenti troppo radicale per potersi adattarsi alla loro roadmap di sviluppo.

Nel dicembre 2013, Vitalik iniziava a condividere un "white paper" che delineava la visione dietro Ethereum: una blockchain "general-purpose" e Turing-complete. A questo punto, solo alcune decine di persone erano a conoscenza di questa bozza iniziale. Gavin Wood era uno di questi ed il primo a contattare Vitalik per offrire il suo contributo nello sviluppato del protocollo e nella sua implementazione grazie alle sue capacità di programmazione in C++. Da qui in poi, Vitalik e Gavin iniziavano a rifinire e sviluppare l'idea, costruendo insieme il "protocol-layer" che sarebbe diventato Ethereum.[3]

I fondatori di Ethereum pensavano ad una blockchain programmabile general-purpose, ovvero non limitata ad un particolare scopo, che potesse supportare un'ampia varietà di applicazioni di arbitraria complessità. Proprio come Satoshi, Vitalik e Gavin non avevano inventato una nuova tecnologia dal nulla; ma avevano combinato nuove invenzioni con tecnologie già esistenti in un modo nuovo e avevano consegnato del codice prototipo funzionanete per dimostrare le loro idee al resto del mondo.

Nel corso di un paio d'anni, il gruppo di sviluppo dei soli fondatori cresceva e continuava a lavorare, costruendo e perfezionando la visione iniziale, fino a quando, il 30 luglio 2015, veniva minato il primo blocco di Ethereum e il "world-computer" entrava in servizio.

La definizione più generica di "blockchain" rimane invariatamente semplice, anche alla luce dei sempre crescenti numeri, complessità e ramificazioni di tutti i progetti che, negli ultimi 10 anni, hanno contribuito allo sviluppo di questa tecnologia.

Una blockchain è un database decentralizzato, distribuito e pubblico che viene utilizzato per comunicare, validare e registrare transazioni tra i partecipanti in modo tale che qualsiasi record coinvolto in esse non possa essere modificato retroattivamente, senza l'alterazione di anche tutti i blocchi successivi. Ciò consente ai partecipanti di poter verificare a posteriori le transazioni in modo indipendente ed accessibile.

Un'altra definizione, più formale: Una blockchain è una macchina di stato deterministica, ma praticamente illimitata, fondamentalmente costituita da uno stato singleton globalmente accessibile e verificabile ricavato da una catena di blocchi crittograficamente protetti contenenti tutte le transizioni di stato precedentemente verificate ed accettate ed una macchina virtuale che applica delle modifiche a quello stato.

Mentre fornire descrizioni generiche della tecnologia in sè non è difficile, dettagliare tutti i problemi e le esigenze a cui ciascun progetto tenta di rispondere non solo sarebbe grandemente difficile, ma andrebbe ben oltre lo scopo e la durata del corso. Ciononostante, già in questa sezione, vedremo le motivazioni dietro all'origine di progetti quali Bitcoin ed Ethereum che sono stati e rimangono, rispettivamente, i leader delle loro controparti di prima e seconda generazione.

Per iniziare, torniamo indietro di poco più di 10 anni, all'apice della Grande Recessione: la culminazione di un periodo inter-generazionale iniziato alla fine degli anni '70, inizialmente negli Stati Uniti, e caratterizzato da forte deregolamentazione nonchè da un profondo ridisegnamento dell'economia globale verso la finanziarizzazione. È in questo contesto economico e sociale che si ripresenta l'esigenza della società di creare una nuova valuta; una valuta digitale, globale, più efficiente e più sicura di qualunque altra.

Progetti come Bitcoin ed Ethereum si propongono di disintermediare, attraverso un enorme potenziale tecnologico-innovativo, tutti quei servizi dove la fiducia può essere convertita in codice; trasformando gli intermediari dalle compagnie, alle istituzioni e persone fisiche in programmi esistenti solo all'interno di sistemi distribuiti sostenuti dagli interessi economici dei partecipanti.

Tecnicamente, le blockchain hanno una curva di apprendimento molto ripida, dovuta alla diversa natura delle loro componenti fondamentali le quali coinvolgono in un unico dominio aree accademiche quali: l'informatica, la crittografia, l'economia, i sistemi distribuiti e altre loro ramificazioni.

Premesso ciò, le componenti di una blockchain pubblica (generalmente) sono:

Tutti o la maggior parte di questi componenti vengono generalmente implementati in un singolo client. Ad esempio, in Bitcoin, l'implementazione di riferimento è sviluppata dal progetto open source Bitcoin Core e viene poi implementata in un client come bitcoind.

In passato, si usava il termine blockchain come termine referenziale per rappresentare i componenti sopra elencati. Oggi, tuttavia, esiste un'enorme varietà di blockchain con proprietà diverse e vi è dunque la necessità di qualificatori, per aiutarci a comprendere le caratteristiche della blockchain in questione, come: open, public, global, decentralized, neutral e censorship-resistant.

Gli alberi di Merkle sono uno dei componenti fondamentali più importanti di qualsiasi blockchain e ne sostengono le funzionalità. Essi consentono di verificare strutture di dati potenzialmente illimitate in modo del tutto efficiente e sicuro.

La scelta di implementare gli alberi di Merkle nelle blockchain è dovuta alla necessità di garantire la scalabilità delle loro strutture di dati e mantenere o verificare trivialmente l'integrità dei dati delle stesse. Le funzioni crittografiche di hash sono la tecnologia che permette l'applicazione degli alberi di Merkle alle blockchain pertanto, come prima cosa, è importante capire in che cosa consistono queste funzioni di hash.

Semplicemente, una funzione di hash è un "tipo di funzione che può essere utilizzata per mappare dei dati di dimensioni arbitrarie a dei dati di dimensioni prestabilite". L'input per una funzione di hash è chiamato "pre-immagine", "messaggio" o più comunemente dati di input. L'output è chiamato "hash" o "digest". Le funzioni hash crittografiche sono una sottocategoria speciale di funzioni hash le cui proprietà hanno più ruoli nella sicurezza e nell'integrità di una piattaforma blockchain.

Una funzione crittografica di hash è una funzione hash unidirezionale e deterministica che mappa i dati di input ad una stringa di bit di dimensioni fisse. La natura a senso unico della funzione serve a rendere computazionalmente impossibile (in pratica) ricostruire i dati di input dal loro hash. La sola strategia per tentare questo consiste nel condurre una ricerca "brute-force", confrontando l'output di ciascuna pre-immagine candidata con l'hash originale, tuttavia, dato che il dominio di selezione dei candidati è virtualmente infinito è ovvio riconoscere l'impraticità di questo processo.

funzione crittografica di hash

Diamo uno sguardo più da vicino alle proprietà principali delle funzioni crittografiche di hash. Queste includono:

La resistenza alle collisioni degli hash è particolarmente importante per evitare, ad esempio, la contraffazione della firma digitale. Inoltre, come già menzionato, la combinazione di tali proprietà rende queste funzioni molto utili per un'ampia gamma di applicazioni di sicurezza:

All'interno delle blockchain, il fingerprinting dei dati viene usato, ad esempio, per determinare lo stato attuale delle stesse. Le blockchain sono essenzialmente liste collegate di blocchi dove l'ultimo blocco contiene sempre un puntatore-hash che lo collega al blocco precedente (e di cui rappresenta tutti i dati) e così indietro fino ad arrivare al blocco di genesi creando una catena di blocchi, da cui il nome blockchain. Collegando i blocchi in questo modo, ogni hash risultante dal blocco precedente rappresenta in realtà l'intero stato della blockchain, dal momento che quell'hash, l'ultimo, è proprio il risultante di tutti gli hash dei blocchi precedenti. In pratica, nel caso dell'algoritmo SHA-256, l'output può essere rappresentato dalla stringa seguente:

bc1a57d476ea01c7f91756adff1d560e579057ac99a28d3f30e259b30ecc9dc7

L'hash qui sopra è l'impronta dell'intero stato della blockchain prima di esso. Lo stato (come hash) della blockchain prima dell'ultimo blocco è l'input mentre l'output è proprio quell'hash. Anche se è possibile usare hash crittografici senza alberi di Merkle sarebbe estremamente inefficiente e quindi per nulla scalabile.

Come vedremo ora, gli alberi di Merkle permettono operazioni di ricerca e mappatura su questi hash in modo del tutto triviale.

In informatica, un albero di Merkle (da Ralph Merkle, che ha brevettato il concetto nel 1979) o hash è una struttura di dati ad albero[1] dove ciascun nodo foglia rappresenta l'hash di dati di input e ciascun nodo non-foglia rappresenta l'hash di tutti i suoi nodi figli. I nodi foglia sono il livello più basso di nodi nell'albero. Questo tipo di struttura di dati è ancora più semplice da comprendere visualmente:

albero binario di hash

L'esempio sopra è la forma più semplice e comune di un albero di Merkle conosciuta come albero binario di Merkle o hash; come si vede, la radice dell'albero è un semplice hash "root" che rappresenta gli hash di tutti i restanti nodi, essenzialmente gli alberi di Merkle sono una struttura di dati in grado di rappresentare "n" hash con un singolo hash output; questa particolare struttura permette di mappare efficientemente quantità arbitrarie di dati e di identificare facilmente in quali rami sono occorse variazioni di dati. Da tale concetto si derivano le "Merkle proofs" con le quali è possibile avere conferma dell'integrità trasversale dei dati sino alla radice senza dover analizzare l'intero set di hash, è invece sufficiente utilizzare un subset di hash ristretto al ramo in cui risiede un nodo per verificare che quest'ultimo è consistente con l'hash radice.

Finchè l'hash radice è noto, è possibile eseguire una ricerca chiave-valore tramite Merkle proof per stabilire la posizione e l'integrità di ogni dato all'interno dell'albero che esibisce quella particolare radice. Inoltre, laddove la radice è nota, il resto dell'albero può essere ricevuto da qualsiasi parte terza, per di più è possibile ricostruire rami diversi fra loro singolarmente anche quando gli altri non sono ancora noti. Infine, come già discusso, l'hash radice può essere utilizzato come impronta per un insieme di dati arbitrario come un database o lo stato di una blockchain.

Per reiterare, il singolo maggiore beneficio di queste strutture di dati consiste nella loro abilità di autenticare basi di dati arbitrariamente grandi attraverso lo stesso meccanismo che è usato per verificare basi di dati microscopiche. Dove n è il numero dei nodi, si dice che l'albero è log(n) efficiente per distribuire enormi set di dati come "subsets" molto più gestibili e facilmente verificabili nonostante il numero originale dei dati.

In conclusione, gli alberi di Merkle sono una componente integrale delle blockchain e consentono loro di funzionare nell'immutabilità ed integrità dei loro dati. Capire il ruolo che queste fondamentali strutture di dati svolgono nelle reti distribuite oltre alla loro tecnologia associata, le funzioni crittografiche di hash, è cruciale per cogliere i concetti alla base delle criptovalute mentre queste continuano ad evolvere in piattaforme sempre più grandi e complesse.

Come menzionato nella seconda sezione del modulo, una delle tecnologie fondative dietro le blockchain è proprio la crittografia: una branca della crittologia usata estensivamente nella sicurezza informatica. Crittografare, ovvero scrivere segreti (dal greco antico), significa costruire e analizzare quelle tecniche e quei protocolli che impediscono a parti terze, chiamate avversari, di interpretare comunicazioni private; alcuni aspetti centrali delle applicazioni moderne della crittografia sono la confidenzialità, l'integrità, l'autenticazione e il non-repudiamento delle informazioni.

Prima dell'età moderna, la crittografia era effettivamente sinonimo di crittazione: la conversione di informazioni da uno stato leggibile ad uno inintelligibile. L'origine del messaggio criptato doveva condividere la tecnica di decriptazione solo con i destinatari designati per escludere tutti gli altri dall'interpretazione del messaggio. La letteratura crittografica spesso designa con "A" l'origine, "B" il destinatario ed "E" (da "eavesdropper") l'avversario. Dall'avvento dei computer in WW-II i metodi usati in crittologia sono diventati incrementalmente completati e le loro applicazioni più prominenti oggi includono: e-commerce, POS e carte di credito, valute digitali, autenticazione con passphrase, comunicazioni militari.

La crittografia a chiave pubblica (in genere chiamata "asimmetrica") è una parte fondamentale della sicurezza delle informazioni ai giorni nostri. Il protocollo di scambio della chiave, pubblicato per la prima volta negli anni '70 da Martin Hellman, Whitfield Diffie e Ralph Merkle (lo stesso degli alberi), fu una svolta monumentale che risultò inevitabilmente in una grande ondata di interesse del pubblico verso il campo della crittografia. Prima di questo periodo, solo i governi possedevano delle conoscenze sostanziali in questo campo e le custodivano con grande segretezza.

Le due applicazioni più comuni della crittografia a chiave pubblica utilizzano chiavi univoche per criptare (confidenzialità) e firmare (identità) messaggi; queste chiavi sono basate su funzioni matematiche che sono facili da calcolare, mentre è difficile calcolarne l'inverso. Tali chiavi consentono la creazione di segreti e impronte non repudiabili garantiti dalla matematica.

Crittografia con la chiave pubblica
In uno schema di crittografia a chiave asimmetrica, chiunque è in grado di crittografare messaggi usando una propria chiave pubblica, ma solo colui che possiede la corrispondente chiave privata sarà in grado di decriptare il messaggio. La sicurezza è affidata alla chiave privata.
Firma con la chiave privata
In quest'altro esempio il messaggio è solo digitalmente firmato e non crittografato. A firma un segreto con la sua chiave privata, in questo modo B può verificare che il segreto sia di A e che il segreto stesso non sia stato alterato.

Altre funzioni matematiche crittograficamente utili, ma più avanzate, sono basate su operazioni aritmetiche che hanno a che fare con una curva ellittica. Ma occorre prima tenere a mente come la crittografia a chiave pubblica sia stata fondata sull'intrattabilità di alcuni problemi matematici. I primi sistemi a chiave pubblica semplicemente assumevano che sia sempre difficile fattorizzare un numero grande composto da più fattori primi. Per i sistemi basati sulle curve ellittiche viene altresì assunto che sia impratico trovare il logaritmo discreto di un elemento casuale posto su una curva ellittica con rispetto ad un noto punto base sulla stessa, questo problema viene chiamato ECDLP ("elliptic curve discrete logarithm problem") ed è direttamente proporzionale alle dimensioni della curva ellittica scelta. La crittografia delle curve ellittiche (ECC) è usata estensivamente in molti sistemi informatici più moderni ed è alla base della gestione delle chiavi private nella maggior parte delle blockchain.

La maggior parte delle blockchain utilizzano la crittografia asimmetrica per generare una coppia di chiavi, una privata ed una pubblica, vengono considerate una coppia perchè la chiave pubblica è facilmente derivabile da quella privata, insieme rappresentano in genere un account o "wallet" dove l'indirizzo è proprio la chiave pubblica mentre l'accesso o la firma sono delegati esclusivamente alla chiave privata. Specificatamente, la chiave privata regola l'accesso all'account essendo l'unica informazione necessaria e disponibile all'account per creare firme digitali senza le quali sarebbe impossibile, ad esempio, firmare la transazione con la quale spostare i fondi in un altro account.

Più generalmente, la chiave privata può essere usata per firmare qualsiasi tipo di messaggio; per quanto riguarda le transazioni, solitamente sono i dettagli della transazione stessa ad essere inviati (e quindi firmati). L'ECC offre sia un meccanismo per combinare il messaggio (i dettagli della transazione) con la chiave private dell'account a cui apparterrà la transazione, sia un meccanismo per permettere a chiunque di verificare che quella transazione è valida perchè i dettagli della transazione includono l'indirizzo dell'account usato per firmarli in primo luogo. In particolare, mentre il processo di verifica non coinvolge in alcun modo pratico la chiave privata allo stesso modo esso prova che la transazione sarebbe potuta provenire solo dall'account in possesso della chiave privata associata al suo indirizzo.

Le transazioni sono, funzionalmente, i più piccoli elementi costitutivi di una piattaforma blockchain. Tuttavia, questa definizione, troppo generica, nasconde tutti i loro dettagli e la loro vera funzionalità; in essenza, le transazioni sono messaggi firmati originatisi da un EOA ("externally owned account") nonchè l'unico elemento di una blockchain in grado di alterarne lo stato: si può pensare ad esse come il sangue di una blockchain.

Per quanto concerne i contenuti di questa sezione, essi verranno declinati guardando principalmente alla loro declinazione nella blockchain di Bitcoin. La ragione per questa scelta è semplice: non esistendo una specifica o implementazione universale per tali concetti è stata scelta quella più semplice. Cionostante, i componenti architetturali presentati in questa sezione sono stati, a grandi linee, estesi e implementati dalla maggior parte delle altre piattaforme blockchain.

Generalmente, le transazioni consistono di un indirizzo destinatario, un indirizzo d'origine e un valore, non diverse dalle transazioni di una carta elettronica, a dire il vero. In Bitcoin, una transazione trasferisce valore (BTC) da un indirizzo verso un altro, così facendo essa modifica permanentemente lo stato dell'intera blockchain, ciò significa che tutti i nodi partecipanti dovranno, prima o poi, ricevere e validare singolarmente quella transazione.

Riguardo al formato delle transazioni in Bitcoin, esse contengono uno o più input ed uno o più output. Ogni input è una referenza all'output di una transazione precedente, mentre ogni output deve includere un valore ed un indirizzo. In modo importante, la struttura che contiene gli input include anche una firma digitale che provi che all'origine della transazione era effettivamente permesso di originarla.

All'inizio esisteva solamente una transazione iniziale che non aveva alcun input, ma solo un output con cui creditava ad A un valore X. Eventualmente, A vuole trasferire X a B e per farlo deve creare una transazione che avrà come input una referenza all'output della transazione iniziale e come output avrà X insieme all'indirizzo di B. Quando la transazione verrà validata dalla maggior parte dei nodi allora B controllerà X che potrà trasferire a sua volta a C nello stesso fascino; come vedremo qui sotto, è proprio questo meccanismo di trasferimento di valore (o informazione) che, con il tempo, forma catene di blocchi.

Linked transactions

I blocchi sono strutture di dati il cui scopo è raggruppare insiemi di transazioni per poi essere propagati ad ogni nodo nella rete. I blocchi vengono creati dai nodi minatori (discussi nelle prossime sezioni).

I blocchi includono sempre, oltre alle transazioni stesse, un "block header", ovvero dei metadati che lo identificano e aiutano a verificarlo; in Bitcoin, i metadati tipici di un blocco includono:

Bitcoin block
Il resto del blocco contiene transazioni che il nodo minatore ha voluto includere. I partecipanti creano transazioni che inoltrano ai nodi, dopodichè attendono, in un pool, di essere incluse a loro volta in un blocco.

È importante realizzare come a ciascun nodo minatore (e non) sia permesso agire liberamente all'interno della piattaforma blockchain, dopodichè le regole vigenti del consenso stabiliranno se il suo comportamento sarà accettabile anche alla maggior parte degli altri nodi. Ciò si traduce in un sistema dove i nodi minatori hanno ogni incentivo a produrre blocchi validi e nessun incentivo (economico) a tentare di imbrogliare altri nodi. Le blockchain sono, per design, sistemi probabilistici dove ciascun nodo deve essere in grado di decidere indipendentemente quale catena di blocchi è la più lunga e valida; ogni qual volta un nuovo blocco necessita di essere aggiunto alla catena esistente ogni nodo dovrà essere in grado di collocarlo autonomamente.

Linked blocks

Nel contesto delle catene di blocchi, occorre distinguere tra diversi tipi di blocchi:

I blocchi di rami secondari sono particolarmente interessanti perchè anche se non esistono nel ramo principale possono ricomparirvi se più lavoro viene fatto su di loro, ovvero se vengono generati dei blocchi che li referenziano come genitori; esiste dunque la possibilità per un blocco di un ramo secondario di essere riarrangiato nel ramo principale. Tale riorganizzazione avviene perchè il ramo principale della blockchain è sempre quello che ha avuto più lavoro fatto su di esso.

Il continuo aumento di dispositivi connessi alla rete, dovuto in gran parte alle evoluzioni e ai progressi fatti dalla tecnologia utilizzata dai dispositivi mobili, ha portato a valutare alternative all’approccio client-server di molte tipologie di applicazioni. Da svariati anni, infatti, il paradigma "peer-to-peer" è ormai utilizzato in una moltitudine di campi, blockchain inclusa. Inizialmente, si trovavano sue applicazioni nella condivisione di file con il precursore Napster o del più moderno BitTorrent, nella messaggistica istantanea e VoIP di TeamSpeak, Discord o Skype, nei sistemi ibridi come quello che Spotify ha utilizzato fino a poco tempo fa per alleggerire il carico sui server, fino ad arrivare alle numerose web-apps di video-streaming basato sul p2p (peer-to-peer). Nelle blockchain le reti p2p sono utilizzate per permettere ai nodi di comunicare fra di loro in modo decentralizzato, specificatamente per permetter a ciascuno di loro di propagare transazioni e blocchi ad altri nodi.

Ogni rete peer-to-peer è, per design, dinamica e disordinata, infatti i nodi (o "peers", partecipanti) possono connettersi e disconnettersi in ogni momento. Ciascun peer è equipotente ed egalitariamente privilegiato rispetto agli altri peers; insieme essi formano una rete di nodi peer-to-peer. Ciascun peer rende una parte delle propri risorse, in termini di spazio d'archiviazione, banda di rete, potenza computazionale, disponibile al resto della rete, senza alcuna necessità di coordinazione da parte di un'entità centrale. Quindi, i peers possono essere sia fornitori che consumatori di risorse all'interno della rete, in contrasto con i modello client-server tradizionali.

Rete peer-to-peer
Un esempio di rete peer-to-peer in cui i nodi interconnessi condividono e utilizzano risorse tra di loro senza l'uso di un sistema di coordinamento centralizzato.

Di conseguenza diviene importante lo studio di algoritmi in grado di massimizzare l’efficienza nella diffusione delle informazioni. Tali algoritmi vengono chiamati di "gossip", o epidemici, perchè si ispirano a fenomeni propri del mondo naturale o di quello sociale. Infatti, come suggerito dai due nomi, il loro comportamento ricorda la diffusione delle malattie o di un pettegolezzo (gossip) all’interno di un gruppo sociale. In ambito informatico ci si riferisce invece alla disseminazione di messaggi, secondo determinati criteri, all’interno di una rete.

Il concetto determinante dei protocolli di gossip è espresso nel periodico scambio di informazioni tra i partecipanti riguardo ad eventi più o meno recenti. Ogni partecipante utilizza un meccanismo di selezione casuale per la scelta di altri partecipanti con cui riconciliarsi. Tale combinazione di periodicità e casualità garantisce, con grande probabilità, che eventualmente tutti i partecipanti riceveranno l'informazione.

I protocolli di gossip hanno i seguenti punti di forza: hanno una probabilità di convergenza molto alta; impongono una comunicazione a carico limitato, queste limitazioni includono utilizzo di banda e frequenza di aggiornamento; possono operare nella maggior parte delle topologie di rete, richiedendo anche solo minima banda e connettività. I protocooli di gossip hanno anche delle debolezze, ad esempio, se il contenuto del gossip eccede le dimensioni massime consentite dal protocollo allora esso dovrà essere diviso in più pacchetti aumentando significativamente i tempi di propagazione; altre debolezze più legate a specifiche standardizzazioni del protocollo possono manifestarsi in presenza di partecipanti avversari i quali potrebbero "floodare" (inondare) la rete con messaggi intenzionalmente corrotti oppure "divide-and-conquer" (dividere e conquistare) gli altri partecipanti per sottomettere loro dei gossip arbitrari.

La maggior parte delle piattaforme blockchain esistenti utilizza, come già accennato, una qualche forma di "gossiping" per disseminare transazioni, blocchi e informazioni sullo stato della rete a tutti i nodi partecipanti. Utilizzando un buon protocollo di gossip, come già menzionato, è virtualmente assicurato che, eventualmente, tutti i nodi riceveranno tutte le transazioni e blocchi. Ad esempio, i nodi in Bitcoin selezionano un piccolo sottoinsieme di nodi basato sulla prossimità per il gossip. Hyperledger Fabric, una piattaforma per creare blockchain "permissioned" (con permesso), prevede due modalità per i gossip: pull, dove i nodi richiedono informazioni e push, dove i nodi inoltrano informazioni a loro volta. Per riassumere, nei sistemi blockchain un protocollo di gossip standardizzato viene usato per permettere ai nodi partecipanti la propagazione di transazioni, blocchi ed informazioni sui nodi stessi; i protocolli di gossip sono meccanismi di comunicazioni che non rivestono alcun ruolo all'interno dei meccanismi veri e propri con cui i nodi raggiungono il consenso, quest'ultimi meccanismi verranno analizzati nella prossima sezione.

Fino ad ora, si è più volte menzionato il termine "regole di consenso, ovvero quelle regole sulle quali tutti i nodi sono chiamati a concordare tra di loro affinchè il sistema possa operare in modo decentralizzato anche se deterministico. Nell'informatica, il termine "consenso" è precedente ai sistemi blockchain ed è sempre stato correlato ad un problema più ampio di sincronizzazione dello stato all'interno dei sistemi distribuiti che riguarda il modo con cui i diversi partecipanti possono eventualmente raggiungere un accordo sullo stato a livello del sistema. Ciò significa raggiungere il consenso.

Se si considera la funzione principale della verifica e conservazione decentralizzata dei registri, può diventare problematico affidarsi esclusivamente alla fiducia per garantire che le informazioni derivate dagli aggiornamenti di stato siano corrette. Questa sfida di carattere aperto diventa particolarmente pronunciata nelle reti decentralizzate dove non (dovrebbe) esiste un'entità centrale che sancisca ciò che è vero. La mancanza di un'entità decisionale centralizzata è una delle principali attrazioni delle blockchain pubbliche, per via della loro conseguente resistenza alla censura e per la loro natura "permissionless". Tuttavia, questi benefici hanno un prezzo: in assenza di un'identità autorevole, qualsiasi disaccordo o decezione o differenza deve comunque essere riconciliabile. Gli algoritmi di consenso sono il meccanismo attraverso il quale è possibile riconciliare sicurezza e decentralizzazione.

Nelle blockchain, il consenso è una proprietà critica del sistema. Senza consenso sarebbe impossibile mantenere uno stato comune in un sistema distribuito; in altre parole, il consenso è inteso a permettere un sistema governato da regole strette, ma senza regolatori. Non vi è nessuna persona, organizzazione o gruppo "al comando", il controllo del sistema è diffuso attraverso i (idealmente molti) partecipanti, i cui interessi personali sono meglio salvaguardati quando essi osservano le regole. Ne risulta che l'abilità di raggiungere un consenso in una rete distribuita, sotto condizioni ostili, senza dover centralizzare il controllo della rete è il principio alla base di tutte le blockchain "open" o pubbliche. Per affrontare questa sfida e mantenere così la preziosa proprietà della decentralizzazione, la comunità di sviluppo continua a sperimentare con modelli diversi di consenso.

Mentre gli algoritmi di consenso sono indubbiamente una parte chiave del funzionamento delle blockchain, è bene ricordare che essi operano ad un livello fondativo molto al di sotto di, ad esempio, l'invio di una transazione; in altre parole non vi è alcun bisogno di conoscere i dettagli del funzionamento degli algoritmi di consenso delle varie blockchain per essere in grado di farne uso.

I principi e le ipotesi degli algoritmi di consenso possono essere capiti più chiaramente ponendo alcune domande chiave:

Il creatore della prima blockchain (Bitcoin) ha anche inventato un algoritmo di consenso chiamato "proof of work" (PoW). Arguabilmente, è proprio questo algoritmo a costituire la vera eredità di Bitcoin agli altri progetti blockchain. Il termine colloquiale per indicare gli algoritmi PoW è quello di "mining", il che contribuisce a causare incomprensioni riguardo ai veri presupposti del consenso; si continua ad assumere, per esempio, che lo scopo del "mining" sia la creazione di nuova valuta circolante, mentre il vero scopo di qualsiasi meccanismo di consenso è la messa in sicurezza di un sistema decentralizzato come le blockchain. La ricompensa per il "mining" costituisce solamente un incentivo per continuare a performare quest'azione critica per la sicurezza, ma intensiva dal punto di vista delle risorse; se i "miners" tentassero di estrarre nuova valuta senza attenersi alle regole del protocollo di consenso essi incorrerebbero solo il costo dell'energia che hanno già impiegato. Pertanto, il consenso basato su PoW è un delicato equilibrio di rischio e ricompensa che incentiva i partecipanti a comportarsi onestamente.

Gli algoritmi di consenso proof of work (PoW) sono il meccanismo usato dai nodi per processare i nuovi blocchi in cui le transazioni sono state raggruppate dagli stessi per aggiungerle alla blockchain, non prima che i nodi partecipanti abbiano avuto la possibilità di verificarli individualmente.

Storicamente, PoW non è stato il primo algoritmo di consenso che sia mai stato avanzato teoricamente. Infatti, prima della sua introduzione molti ricercatori avevano già proposto alcune varianti di consenso basate su uno "stake" valutario, ora chiamati algoritmi "proof of stake" (PoS). È corretto dire che PoW è stato inventato come alternativa a PoS. Dopo il successo di Bitcoin, la grande maggioranza degli altri progetti aveva adottato lo stesso tipo di consenso; tuttavia, l'esplosione di rinnovato interesse nella ricerca degli algoritmi di consenso aveva anche riesumato proof of stake avanzando significativamente lo stato della tecnologia. In generale, un algoritmo PoS funziona nel modo seguente: la blockchain tiene traccia di un gruppo di nodi validatori e, teoricamente, chiunque possegga la criptovaluta associata potrebbe essere scelto come validatore semplicemente effettuando (un deposito) una transazione speciale designata per mettere in stake una quantità di valuta arbitraria. Dopodichè, una volta scelti i validatori questi si alternano proponendo e votando su quello che ciascuno di loro considera il prossimo blocco valido dove il peso di ogni nodo validatore è proporzionale allo stake che quel nodo aveva depositato prima di essere scelto. Importantemente, un validatore rischia di perdere il proprio deposito se il blocco che esso ha scelto viene rigettato dagli altri validatori, al contrario, esso viene premiato, sempre proporzionalmente allo stake, per ciascun blocco proposto che è accettato dalla maggioranza dei validatori. Pertanto, PoS costringe i validatori a seguire le regole di consenso attraverso un meccanismo di ricompensa e punizione, non diversamente da PoW dove però la punizione è estrinseca al sistema (il costo dell'energia).

Gli algoritmi di consenso proof of stake (PoS) scelgono dei nodi partecipanti, sulla base delle qualità del loro stake, come validatori in un processo di selezione e votazione che culmina con l'aggiunta alla blockchain del suo prossimo blocco valido.

Per quanto riguarda la scalabilità dei sistemi distribuiti basati su questi algoritmi occorre ricordare che sebbene l'algoritmo PoW, ad esempio come implementato in Bitcoin, rimanga tra i più affidabili e testati, esso ha da sempre mostrato prestazioni decisamente limitate in termini di [efficienza energetica x transazioni al secondo]. Per reiterare, questa restrizione è legata alla natura del consenso tra nodi partecipanti all'interno di una rete distribuita. Per quanto riguarda la scalabilità, le blockchain con algoritmi di consenso PoS forniscono, in genere, prestazioni migliori rispetto alle loro controparti basate su PoW, ma non abbastanza da riuscire a risolvere definitivamente il problema centrale della scalabilità di queste piattaforme. In questo contesto si inserisce la "proof of authority" (PoA) ovvero un altro algoritmo di consenso basato sulla reputazione dei partecipanti che introduce una soluzione efficiente, anche se molto più applicabile alle blockchain private, dal punto di vista delle risorse coinvolte nel raggiungimento del consenso. Questa categoria di algoritmi è stata proposta nel 2017 da Gavin Wood, già co-fondatore di Ethereum. L'algoritmo di consenso PoA fa uso del valore dell'identità di alcuni nodi, ciò significa che i nodi validatori dovranno mettere la propria reputazione, anzichè valuta, come stake; pertanto, i sistemi che scelgono questo modello di consenso dipenderanno da un numero (idealmente) limitato di nodi validatori arbitrariamente pre-approvati, fatto che permette teoricamente un sistema molto scalabile, i quali svolgeranno il ruolo di moderatori dei nuovi transazioni e blocchi.

A questo punto viene naturale mettere in discussione le ragioni dietro l'esistenza di così tanti algoritmi di consenso e cercare di capire quale di questi sia il migliore. La risposta al secondo interrogativo è al centro di una delle aree di ricerca sui sistemi distribuiti più eccitanti del decennio corrente. È probabile che nessun algoritmo di sarà mai ottimizzato in ciascuna delle aree più problematiche del consenso decentralizzato a tal punto da essere considerato migliore degli altri. L'intera industria delle blockchain non è altro che un gigantesco esperimento dove tutti questi dubbi e domande vengono testate ogni giorno sotto condizioni avverse per non parlare delle enormi capitalizzazioni di mercato ormai in gioco; ad ogni modo, come sempre, solo il tempo saprà fornirci le risposte definitive.

Dalla circolazione iniziale del Bitcoin "white paper" nel 2008 al mining del suo primo blocco nel 2009, chiunque poteva leggere e modificare il codice della piattaforma per creare la propria versione di "digital peer-to-peer money", dal momento che l'intero progetto era open-source e facilmente accessibile come repositorio GitHub. In questa fase, emersero molti dei così detti, "altcoin" che competevano con lo scopo di migliorare la velocità piuttosto che l'anonimato di Bitcoin; tuttavia, emersero anche alcuni progetti che si prefiggevano di ridefinire lo scopo e le applicazioni della blockchain di Bitcoin, andando anche ben oltre il "semplice" concetto di piattaforma per lo scambio peer-to-peer di valore digitale. L'idea era quella di utilizzare le blockchain per qualsiasi tipo di transazioni o accordi; Mastercoin, uno degli altcoin, tentò, senza successo, di soddisfare queste esigenze senza abbandonare le fondamenta del protocollo di Bitcoin; più tardi, sarebbe stato il progetto di Ethereum ad optare invece per la creazione di una blockchain su nuove fondamenta con le quali sarebbe stato possibile offrire un modo totalmente radicale di creare nuovi servizi digitali, interamente decentralizzati: ovvero la possibilità di programmare la blockchain stessa attraverso delle transazioni programmabili chiamate "smart contracts".

Molte grandi istituzioni private, la maggior parte finanziarie, non tardarano ad individuare nella promessa rivoluzionaria delle blockchain un'opportunità e una minaccia nel modo in cui queste riescono a catturare, custodire e far circolare valore in un'altamente finanziarizzata economia quale quella moderna. Dalle blockchain, esse riutilizzarono la loro natura di "distributed ledger technology" per creare piattaforme "permissioned" (private o ibride), dove il validatore è un membro di un consorzio oppure un'entità legale separata della stessa organizzazione. In questo contesto permissioned, l'appropriatezza dell'utilizzo del termine blockchain è altamente controverso e disputato, perciò è stato coniato il termine distributed ledger technologies per caratterizzare l'industria. Le blockchain private possono essere valide per risolvere inefficienze, sicurezza e cattiva condotta all'interno delle istituzioni private tradizionali, anche se solo incrementalmente. D'altro canto, sono le blockchain pubbliche a custodire il vero potenziale di rivoluzionare il modo in cui l'economia funziona.

Prima di dettagliare tutti i tipi di blockchain, è utile suddividerli in due categorie: permissioned e permissionless. Nei sistemi permissionless a tutti i nodi partecipanti viene concesso il permesso di leggere, creare e validare transazioni e produrre nuovi blocchi. Nei sistemi permissioned, invece, solo ad alcuni e in genere pochi nodi è permesso di produrre nuovi blocchi o addirittura di leggere, creare o validare transazioni.

Permissioned vs Permissionless blockchains
permissioned vs permissionless blockchains
"Blockchains: What and Why", Gavin Wood.
Blockchain Pubbliche
Le blockchain più usate continuano ad essere quelle open-source e permissionless. Chiunque può parteciparvi semplicemente installando il codice del client necessario ad eseguire un nodo locale per poter subito iniziare a validare transazioni, esplorare la rete ecc. Chiunque è anche in grado di mandare transazioni ed aspettarsi che queste, se valide, vengano incluse nella blockchain. Le transazioni sono sempre pubblicamente verificabili, anche se rimangono in forma anonima/pseudo-anonima. Ciononostante, è importante ricordare che è possibile per una blockchain pubblica essere permissioned; un esempio è dato da EOS, una piattaforma pubblica dove solo 21 nodi producono blocchi.
Blockchain Ibride
Attualmente, le blockchain più decentralizzate (pubbliche) hanno un "throughput" (η×C -> efficienza del protocollo x capacità di trasmissione) molto basso. La mainnet di Ethereum, per esempio, processa in media 12 tx/s; altresì, una blockchain poco decentralizzata come Quorum è in grado di processarne circa 100 tx/s con solo 7 7 nodi validatori, per via della centralizzazione del meccanismo di consenso. Dal momento che la decentralizzazione è la chiave, come si può ottenere un sistema davvero decentralizzato che sia anche veloce? Una soluzione alquanto promettente è un ibrido tra la blockchain privata e pubblica; in una blockchain ibrida ad ogni transazione viene permesso di essere processata in una propria chain separata e commessa nella catena principale solo se e quando è necessario che sia validata pubblicamente. Il risultato è chiaro, la fiducia immutabile della decentralizzazione è mantenuta con i benefici aggiunti di una blockchain privata, come la scalabilità.
Blockchain Private
I permessi di creazione e validazione delle transazioni sono centralizzati in una o più organizzazioni (controllo federato o consorzio). I permessi di verifica delle transazioni possono essere pubblici o anch'essi arbitrariamente ristretti. Alcuni casi d'uso includono database management, auditing e altri oneri interni ad una singola compagnia o ad ristretto gruppo di compagnie relazionate. Questi meccanismi comportano inevitabilmente un ritorno dei rischi che piagano le soluzioni centralizzate tradizionale come certi benefici dal punto di vista della conformità a quelle regolamentazioni più moderne non altrimenti soddisfacibili come il diritto alla cancellazione dei dati utente.

Alcuni sostengono che tali sistemi (ibridi e privati) non possono essere definito come piattaforme blockchain. Non è ancora noto in che modo la tecnologia verrà ultimamente adottata. Tuttavia, in molti sostengono che tali sistemi potrebbero subire il destino che hanno subito le Intranets negli anni '90, quando le compagnie private costruirono le proprie LAN o WAN invece di condividere i loro servizi con l'Internet pubblica, solo per poi diventare obsolete con l'avvento del Web 2.0.


Pubblica
Nessuna gestione centralizzata
Ibrida
Parziale gestione decentralizzata
Privata
Singola o federata gestione centralizzata
Participation Permissionless
  • Libera
  • Distribuita
  • Potenzialmente avversaria
Permissionless / Permissioned
  • Libera / Ristretta
  • Distribuita / Identificata
Permissioned
  • Ristretta
  • Identificata
Consenso PoW, PoS, PoA...
  • Alto consumo energetico in PoW
  • Decentralizzato
  • 51% attack
PoW, PoS, PoA... / Algoritmo di consenso "inter-partes"
  • Veloce
  • Alto consumo energetico in PoW / Basso consumo energetico
Algoritmo di consenso "inter-partes"
  • Veloce
  • Centralizzato
  • Basso consumo energetico
  • Finalità
Frequenza di blocco Lungo
Ethereum: ~12 s
Medio
varia
Corto
~1xxx ms
USP Dirompente
Rivoluzionaria dal punto di vista della disintermediazione. Non ancora compatibile con l'utilizzo enterprise o regolamentato.
Efficiente
Può ridurre drammaticamente i costi delle transazioni. Minore ridondanza dei dati, tempi di transazione più rapidi, maggiore trasparenza
Business-friendly
Scalabilità e conformità alle regolamentazioni sulla privacy dei dati e altri aspetti normativi

Il termine "smart contract" è stato utilizzato nel corso degli anni per descrivere un'ampia varietà di cose diverse. Negli anni '90, il crittografo Nick Szabo ha coniato il termine definendolo come "un insieme di promesse, specificate in forma digitale, inclusi i protocolli all'interno dei quali le parti soddisfano quelle promesse.". Da allora, il concetto di smart contracts si è evoluto, specialmente dopo l'introduzione delle piattaforme blockchain con l'invenzione di Bitcoin nel 2008. Nel contesto di Ethereum, il termine è stato impropriamente assegnato in realtà dato che gli smart contracts di Ethereum non sono nè intelligenti (essendo funzioni che rispecchiano "entità morte") nè davvero legali (anche se questo sta cambiando); cionostante, il termine è rimasto. Per gli scopi di questo corso, il termine smart contract sarà sempre utilizzato in riferimento a quei programmi immutabili che funzionano in modo deterministico nel contesto della EVM (Ethereum Virtual Machine), ovvero sulla blockchain di Ethereum.

Scomponiamo quest'ultima definizione per capire meglio le proprietà e il funzionamento degli Ethereum smart contracts:

Gli smart contract sono tipicamente scritti in un linguaggio di "alto-livello", come Solidity. Ma prima di essere distribuiti, il loro codice di alto-livello dev'essere compilato in bytecode di basso-livello che la EVM è in grado di interpretare. Fatto ciò, essi possono essere distribuiti sulla piattaforma di Ethereum tramite una transazione speciale di "contract creation", la quale è identificata come tale da un indirizzo di destinazione speciale: "0x0". Ciascun smart contract è identificato univocamente attraverso da un indirizzo pubblico, non diverso dall'indirizzo di un EOA ed è derivato a partire dall'indirizzo di origine della transazione di creazione e dal suo nonce. L'indirizzo del contratto può essere utilizzato per interfacciarvisi piuttosto che per mandare dei fondi; è bene notare che, al contrario degli EOAs, non esistono chiavi private associate agli "account" degli smart contract. Più in generale, è corretto dire che generalmente (a meno che non sia espressamente dichiarato nel codice) essi non hanno alcun padrone dal momento della distribuzione.

Un concetto particolarmente rilevante dal punto di vista dell'essenza di queste entità giace nel fatto che gli smart contracts vengono solo e sempre eseguiti se sono stati chiamati da una transazione. Ripetendo, tutti gli smart contracts di Ethereum vengono eseguiti, ultimamente, a causa di una transazione originatasi da un EOA. Mentre un contratto può invocare a sua volta un altro contratto esso dovrà essere stato originariamente invocato da un EOA. I contratti non vengono mai eseguiti "in background" come fossero thread di un appserver, essi invece giacciono dormenti sulla blockchain fino a quando non sono invocati da una transazione di un EOA. È inoltre importante sottolineare che gli smart Contracts non sono mai eseguiti "in parallelo" in ogni senso del termine; Ethereum, insieme alle altre blockchain, può essere considerato una macchina "single-threaded".

Per quanto riguarda il meccanismo di funzionamento è bene ricordare che le transazioni sono di per se "atomiche", indipendente dalla loro catena di esecuzione. Le transazioni sono eseguite nella loro interezza, inclusi i potenziali cambiamenti che apportano allo stato della blockchain, solo se la loro esecuzione termina correttamente. Un'esecuzione di successo significa che il programma è stato eseguito senza errori ed ha raggiunto la fine di ogni calcolo. Se l'esecuzione dovesse fallire a causa di un errore, tutti i suoi effetti (inclusi i cambiamenti di stato) vengono ritornati allo stato iniziale, come se la transazione non fosse mai stata eseguita. Una transazione fallita viene comunque registrata dal contratto sulla blockchain per mostrare che è stata tentata e la valuta in termini di gas utilizzato per l'abortita esecuzione viene comunque dedotta dal EOA.

Come menzionato in precedenza, è importante ricordare che il codice di un contratto non può essere cambiato, generalmente. Tuttavia, un contratto può essere effettivamente eliminato (o meglio disabilitato) rimuovendone il codice e lo storage legati al suo indirizzo, ovvero lasciandosi dietro solo un indirizzo vuoto. Qualsiasi transazioni mandata a quell'indirizzo dopo che il contratto era stato cancellato non risulterà in alcuna computazione perchè non vi è più codice da eseguire. Per cancellare un contratto, basta eseguire l'istruzione della EVM avente opcode SELFDESTRUCT (previously SUICIDE). Questa particolare operazione ha un costo negativo di gas, ovvero un rimborso valutariamente che serve ad incentizzare il rilascio delle risorse di storage inutilizzate nella piattaforma. Cancellare un contratto in questo modo non cancella il suo storico delle transazioni, dal momento che lo stato concordato della blockchain è immutabile. È anche importante precisare come l'istruzione SELFDESTRUCT sia disponibile solamente qualora il programmatore del contratto ha predisposto l'utilizzo di questa capacità; se il codice del contratto non contiene quell'opcode o lo contiene ma è altresì inaccessibile allora quel particolare smart contract non potrà essere eliminato.

Nel software, un'interfaccia binaria applicativa è un'interfaccia tra due moduli di programmi distinti; spesso, tra il sistema operativo ed i programmi che ospita. L'ABI definisce come le strutture di dati e le funzioni sono accedute nel codice macchine e non deve essere confuso con un'API (interfaccia programmativa applicativa) che invece definisce l'accesso ad alto-livello, in formato intelleggibile. Perciò l'ABI è il modo primario per codificare e decodificare i dati dentro e fuori del codice macchina. In Ethereum, l'ABI è usato per codificare le chiamate dei contratti per l'EVM e per leggere i dati delle transazioni. Il presupposto di un ABI è quello di definire le funzioni di un contratto che possono essere invocate e descrivere quali argomenti e ritorni avranno. L'ABI di un contratto è specificato come un array delle descrizione delle singole funzioni rappresentate come JSON. Tutto ciò che occorre a qualunque applicazione che voglia interagire con il contratto saranno un'ABI e l'indirizzo del contratto da cui l'ABI era stato derivato.

In questa sezione esploreremo il mondo delle "decentralized applications", or DApps. Sin dai giorni iniziali del progetto Ethereum, la visione adottata dai fondatori (proposta da Gavin Wood) si spingeva molto più in là degli smart contracts: niente di meno che decentralizzare almeno il world wide web, al più il resto del mondo. Gli smart contracts sono quindi solo una delle vie (anche se colonne portanti) verso la decentralizzazione della logica di controllo delle applicazoni; le DApps, per definirsi tali, devono necessariamente riuscire a decentralizzare ogni altro aspetto necessario alle applicazioni: archiviazione, comunicazione, risoluzione (DNS) etc. Da tali concetti è stato coniato (da Gavin Wood) il termine Web3, che richiama sia i tre pilastri delle DApps (computazione, archiviazione, comunicazione) sia il suo precedente, ovvero il Web 2.0. Attualmente esistonopochissime vere DApps e tante CApps, ovvero il termine DApps è, al momento, ancora impropriamente assegnato a qualunque applicazione possegga uno smart contract ed un front-end web.

Web3
Web3: A decentralized web using smart contracts and P2P technologies.

Alla luce di quanto introdotto fino ad ora e prima di approfondire le prerogative delle DApps, rinfreschiamo ora un concetto con cui si è, inconsciamente, molto più familiari: quello di un'applicazione centralizzata. (CApps). Una CApp è controllata da una singola entità centrale: una compagnia, un'istituzione, un'agenzia governativa. L'entità ospita il servizio unicamente sulle loro premesse ed ha accesso architetturale completo ai sistemi impiegati per offrire il servizio. L'utente può solo scegliere qualora utilizzare il servizio basandosi sulla reputazione dell'entità; in altre parole, dal punto di vista dell'utente il sistema è fidato o meno. Questo è il modo in cui la maggior parte delle applicazioni Web e aziendali sono progettate oggi.

CApp

Torniamo ora alle applicazioni decentralizzate. Reiterando, con il termine DApp si indica un'applicazione che è in parte (improprio) o interamente decentralizzata; consideriamo tutti i possibili aspetti di un'applicazione che potrebbero essere decentralizzati:

Ogni elemento della lista potrebbe essere alquanto centralizzato o decentralizzato; ad esempio, il frontend potrebbe essere sviluppato come web app distribuita su server centralizzati (cloud) oppure come applicazione mobile. Il backend e lo storage potrebbero essere basati su server privati e database proprietari, oppure su qualche smart contracts e peer-to-peer storage. Indubbiamente, vi sono molti vantaggi nell'architettura di una DApp che una tipica architettura centralizzata non potrebbe offrire:

Backend (Smart Contract)
In una DApp, gli smart contracts vengono usati come contenitori della business logic (codice lato server) e dello stato inerente all'applicazione (es. giochi acquistati da un utente). Questa descrizione rimane, tuttavia, una semplificazione, almeno per il momento, poichè ogni step computazionale del contratto sarà molto costoso (ad esempio, sulla blockchain di Ethereum). Diventa quindi importante identificare quali aspetti del codice backend hanno bisogno di un ambiente decentralizzato e per quali è accettabile utilizzare le architetture più tradizionali.

La prima considerazione maggiore nel design degli smart contracts deve necesseriamente essere l'inabilità di modificare il loro codice una volta distribuiti. Come già detto, anche uno smart contract eliminato si lascierà alle spalle lo storico delle sue transazioni.

La seconda considerazione maggiore dev'essere le dimensioni della Dapp. Ogni singola esecuzione di uno smart contract monolitico sarà, con grande probabilità, proibitivamente costosa. Pertanto, alcune applicazioni dovrebbero mantenere le computazioni più onerose off-chain oltre a mantenere una soluzione di storage alternativa.
Frontend (Interfaccia Utente)
A differenza della business logic di una DApp, la quale richiede che lo sviluppatore sia familiare con la EVM e con linguaggi specifici come Solidity, l'interfaccia lato client di una DApp è perfettamente realizzabile con le tecnologie standard del Web: HTML, CSS e JS. Importantemente, questo permette allo sviluppatore di riutilizzare quei frameworks e quelle librerie con cui è più familiare. Le interazioni con le varie blockchain sono altrettanto facilmente performabili attraverso i comuni web browsers.
Archiviazione di dati
A causa degli alti costi di esecuzione inerenti agli smart contracts, quest'ultimi non possono essere utilizzati per conservare o processare grandi volumi di dati. Quindi, la maggior parte delle DApps attualmente sono costrette alle soluzioni off-chain tradizionali per l'archiviazione dei dati più onerosi. Tuttavia, esistono delle alternative decentralizzate già operative come IPFS o Swarm che offrono l'archiviazione di qualsiasi file attraverso una rete peer-to-peer.

IPFS
L'"Inter-Planetary File System" è un sistema decentralizzato di storage dei dati interrogabile per contenuto (hash), ovvero ogni qual volta che un file è caricato su questo sistema l'hash corrispondente è restituito all'utente ed è univocamente utilizzato per identificare quel file, ad esempio per essere successivamente richiesto a qualsiasi nodo del sistema. IPFS mira a sostituire HTTP/S come protocollo standard per la distribuzione delle applicazioni web.

Swarm
Swarm è un altro sistema p2p interrogabile per contenuto, praticamente identico a IPFS, creato dall'Ethereum Foundation. Come IPFS, permette di custodire qualunque tipo di file che viene poi replicato attraverso tutti i nodi della rete, dopodichè lo stesso file può essere recuperato da qualsiasi nodo attraverso il suo hash. Allo stesso modo, Swarm permette anche la fruizione di contenuti web statici in modo decentralizzato.
Comunicazione di dati
L'ultima componente maggiore di qualunque applicazione è la communicazioni inter-processuale. Ovvero l'abilità di scambiarsi dati tra applicazioni diverse, istanze diverse della stessa applicazione o utenti diversi della stessa applicazione. Tradizionalmente, tutto questo è stato realizzato dipendendo da server centralizzati. Esistono tuttavia varie alternative decentralizzate ai protocolli basati sui server tradizionali, che permettono effettivamente di messaggiare su una rete p2p. Di queste, l'implementazione più notevole è sicuramente Whisper[1] .

Ethereum

In questo modulo si esplorerà Ethereum, si imparerà a interagire con la chain e si metteranno le basi per la sua programmazione

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...


Solidity

In questo modulo si vedranno le caratteristiche del linguaggio Solidity e si farà esperienza nella scrittura di Smart Contracts

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...


Web3 & Truffle

In questo modulo si comprenderà l'architettura delle applicazioni decentralizzate e si imparerà a scrivere il codice on-chain e quello off-chain

Lorem ipsum...

Lorem ipsum...

Lorem ipsum...