Blockchains per supply chain - Lezione 4.21

00:00 Introduzione
02:01 Risolvere il consenso bizantino
09:35 Requisiti stringenti di una blockchain libera
20:31 La storia finora
22:44 Arricchirsi rapidamente oggi
24:03 Mini Bitcoin 1/3 - Hashing e Firma
29:23 Mini Bitcoin 2/3 - Transazioni
34:44 Mini Bitcoin 3/3 - Blocchi e Proof of Work
44:47 Scalare la blockchain 1/2 - Panorama applicativo
49:07 Scalare la blockchain 2/2 - Blocchi più grandi
57:11 Accelerare la blockchain 1/2
59:30 Accelerare la blockchain 2/2
01:06:54 Potenziare la blockchain
01:14:51 Caso d’uso: pagamenti
01:19:25 Caso d’uso: tracciabilità passiva
01:25:33 Caso d’uso: tracciabilità attiva
01:32:47 Caso d’uso: riciclaggio incentivato
01:35:40 Caso d’uso: sicurezza incentivata
01:41:30 Allentare i requisiti
01:44:53 Conclusione
01:49:35 4.21 Blockchains per supply chain - Domande?

Descrizione

Le criptovalute hanno attirato molta attenzione. Sono state fatte fortune. Sono state perse fortune. Gli schemi piramidali dilagavano. Da un punto di vista aziendale, la blockchain è l’eufemismo cortese usato per introdurre idee e tecnologie simili, stabilendo una distanza rispetto a quelle criptovalute. Esistono casi d’uso della supply chain per la blockchain, ma abbondano anche le sfide.

Trascrizione completa

Benvenuti a questa serie di lezioni sulla supply chain. Sono Joannes Vermorel, e oggi presenterò “Blockchains for Supply Chain.” Le criptovalute hanno catturato l’immaginazione del pubblico, sono state fatte e perse fortune, alcuni criminali sono stati catturati e incarcerati, e altri seguiranno. In mezzo a tutta questa agitazione, il termine criptovaluta è diventato un po’ troppo carico per le aziende di medie e grandi dimensioni, che tendono ad essere piuttosto conservative. Così, il termine blockchain è stato adottato come modo per distanziare l’innovazione da tutta la follia che avviene nel mondo crypto. Tuttavia, fondamentalmente, blockchain e criptovalute sono la stessa cosa.

L’obiettivo di questa lezione è acquisire una comprensione tecnica — una comprensione tecnica approfondita — di ciò che sta accadendo con le blockchain. Se possiedi alcune competenze di programmazione, al termine di questa lezione dovresti essere in grado di re-implementare la tua semplice blockchain, se lo desideri. Basandoci su questa nuova comprensione tecnica della blockchain, inizieremo a esaminare i casi d’uso della supply chain e a valutarne la fattibilità come tecnologie per risolvere problemi e il loro valore aggiunto in termini di ciò che possono fare per le supply chain. Iniziamo.

L’origine di Bitcoin è semplicemente strana. Nel 2008, sotto lo pseudonimo di Satoshi Nakamoto — che probabilmente è frutto di un lavoro di squadra — è stato pubblicato un white paper intitolato “Bitcoin: A Peer-to-Peer Electronic Cash System.” Questo documento presenta un sistema e un approccio per un nuovo tipo di valuta elettronica. È un paper relativamente breve con alcune parti matematiche, e anche le parti matematiche sono parzialmente errate.

Il paper originale afferma che il sistema dovrebbe essere sicuro se almeno la metà della potenza di hash fosse dalla parte onesta. Tuttavia, è stato successivamente dimostrato in un paper pubblicato nel 2013, “Majority is Not Enough: Bitcoin Mining is Vulnerable,” che per mantenere la rete sicura non è sufficiente che metà della potenza di hash sia onesta; è necessario, in realtà, che siano onesti oltre i due terzi della potenza di hash.

Tuttavia, esiste un white paper e un pezzo di software. Il software è open source, ed è un’implementazione di qualità molto bassa. Il client di Satoshi è di qualità molto scadente, e durante il primo anno dopo la pubblicazione del software, i collaboratori open source hanno corretto frettolosamente tonnellate di bug e problemi. Alcuni di questi problemi erano difficili da risolvere a causa del design originale e hanno avuto un effetto duraturo su tutta la comunità. Molte delle criptovalute che esistono oggi sono fork del client originale di Satoshi e, in una certa misura, portano ancora molti dei problemi che non sono stati risolti nel corso degli anni.

Quindi, questa è una situazione molto sconcertante, in cui hai un paper non di altissima qualità e un pezzo di software che è discutibilmente di qualità molto bassa, eppure il team di Satoshi Nakamoto ha compiuto una scoperta stupefacente. Fondamentalmente, il problema era noto come problema del consenso bizantino. Si tratta di un problema di calcolo distribuito. Immagina di avere dei partecipanti, e tutti quei partecipanti possono vedere quale dovrebbe essere lo stato del sistema, che nel mondo digitale può essere concepito come una lunga serie di zeri e uno, un payload di dati. I partecipanti possono aggiornare lo stato del sistema, invertire alcuni bit, aggiungerne uno, rimuoverne uno, e possono fare tutto questo contemporaneamente. I partecipanti possono comunicare tra loro, e il problema del consenso bizantino consiste nel far sì che tutti i partecipanti onesti concordino, in un dato momento, su quale sia lo stato del sistema, fino all’ultimo bit.

Il problema è molto difficile se ci sono partecipanti bizantini che agiscono come avversari, cercando di confondere tutti gli altri partecipanti. La scoperta stupefacente di Bitcoin è che se torniamo al 2008 e chiediamo agli esperti, probabilmente avrebbero detto che non sembra possibile risolvere il problema del consenso bizantino in maniera completamente decentralizzata senza un’autorità centrale. Tuttavia, la scoperta di Satoshi Nakamoto, il consenso Nakamoto, ha trovato un modo per risolvere questo problema.

La soluzione è molto sorprendente. Sembra un problema algoritmico, ma l’essenza della soluzione di Bitcoin è che Satoshi Nakamoto ha risolto questo problema aggiungendo incentivi monetari, un incentivo finanziario. Non è soltanto una soluzione algoritmica; è letteralmente un algoritmo che funziona solo perché, all’interno del sistema, gli incentivi monetari sono intrecciati, dando ai partecipanti motivazioni per agire in un certo modo.

Se vogliamo che questi incentivi siano in atto, abbiamo bisogno di una valuta elettronica, così da poter progettare tali incentivi sin dall’inizio. Ed è esattamente ciò che viene fatto in Bitcoin. Se vuoi avere una valuta elettronica, devi affrontare almeno due problemi molto difficili. Il primo problema è la doppia spesa. Se hai una certa quantità di denaro digitale rappresentato da alcuni bit di informazione, cosa ti impedisce di fare una copia di questo denaro digitale e spenderlo una volta per pagare qualcosa per poi riutilizzarlo, con la copia, per pagare qualcos’altro? Questo problema è noto come doppia spesa, ed è uno dei problemi molto difficili affrontati da Bitcoin.

Il secondo problema è l’emissione delle monete. Da dove proviene questo denaro? La cosa interessante è che, tipicamente, quando hai un problema molto difficile da affrontare, adotti un approccio divide-et-impera, suddividendo il problema in sotto-problemi più semplici che possono essere risolti separatamente. Poi, il problema totale può essere risolto. La particolarità di Bitcoin è che ci sono due problemi distinti e molto difficili: la doppia spesa e l’emissione delle monete. Invece di usare un approccio divide-et-impera, Bitcoin impiega un approccio unifica-e-intreccia, che all’epoca era innovativo, per risolvere entrambi i problemi simultaneamente. La soluzione, come vedremo più avanti in questa lezione, è sorprendentemente semplice.

Questa lezione non riguarda principalmente ciò che rende una valuta digitale una buona valuta, poiché questo meriterebbe una trattazione a sé stante. Tuttavia, le blockchain non funzionano senza gli incentivi finanziari progettati tramite le valute digitali che le supportano. Quando diciamo che criptovalute e blockchain sono la stessa cosa, l’idea è che se vuoi avere una blockchain, trasmetterai messaggi, e quei messaggi saranno transazioni con un flusso di denaro coinvolto. La prospettiva delle criptovalute è che il focus principale è sull’aspetto monetario, mentre la prospettiva della blockchain è più interessata ai metadati sovrapposti alle transazioni.

Ricorda che l’intero modello di sicurezza di questi sistemi blockchain/criptovalute si basa sugli incentivi economici progettati a livello di sistema. Non è possibile separare completamente gli obiettivi economici e quelli delle criptovalute dalla blockchain. È solo una questione di prospettiva.

Ora, diamo un’occhiata rapida ai requisiti che accompagnano un sistema blockchain/criptovalute e a come potremmo eventualmente allentarli. Il primo è la non-rinunciabilità. La non-rinunciabilità significa che, in quanto partecipante, nessuno può impedirti di trasmettere una transazione. Nessuno può impedire che una transazione valida avvenga. Questo è molto importante, poiché se c’è un partecipante in grado di farlo, essenzialmente si ha un’autorità centrale. Al contrario, nessun partecipante può impedire una transazione valida, ma allo stesso tempo non esiste alcun partecipante che possa negarti la possibilità di effettuare una transazione perché potrebbe consumare la tua stessa moneta o far sì che una transazione non valida abbia successo. Questo è il primo requisito.

Il secondo requisito è l’anonimato. Tecnicamente, Bitcoin è una rete pseudo-anonima, ma fondamentalmente, quando parlo del requisito dell’anonimato intendo che non esiste una lista di partecipanti. In una vera blockchain, i partecipanti possono comparire o lasciare il sistema in qualsiasi momento, senza alcun guardiano. Poiché i partecipanti possono unirsi o uscire liberamente, non c’è nessuno che tenga traccia della loro identità. Questo non significa che debba essere anonimo; significa semplicemente che se hai una vera blockchain canonica, il requisito dell’anonimato — in cui i partecipanti possono unirsi e lasciare come desiderano — deve essere rispettato.

Poi, elenco la scalabilità massiva come un requisito, che risulta particolarmente difficile per le blockchain perché, come vedremo, questi sistemi distribuiti non sono intrinsecamente facili da scalare. Al contrario, scalare una blockchain è notevolmente difficile. Fondamentalmente, c’è un conflitto: se permetti a qualsiasi partecipante di trasmettere un numero arbitrariamente elevato di messaggi, transazioni o aggiornamenti al sistema, un partecipante può inondare l’intera rete e, sostanzialmente, inviarvi spam. Pertanto, tutte le blockchain devono affrontare questo problema di scalabilità, che viene risolto ingegnerizzando incentivi finanziari.

L’idea è mantenere il costo di una transazione — il messaggio elementare trasmesso sulla blockchain — a circa un decimo di centesimo. È molto economico – immagina dover pagare un decimo di centesimo per inviare un’email. Non è gratuito, ma è comunque a costo molto basso. Quindi, se hai un uso regolare e desideri associare una transazione, ad esempio, al movimento di un prodotto in un warehouse, va bene; il costo rimane molto basso. Tuttavia, mantenendo il costo a 0,1 centesimo, rendi quelle transazioni troppo costose per un attaccante che volesse inondare la rete con miliardi di transazioni, cosa molto facile da fare se non ci sono commissioni. Ogni transazione deve pagare una commissione per la sua esistenza e per supportarne la trasmissione; altrimenti, un attaccante potrebbe inondare il sistema distribuito senza alcun ostacolo.

Quindi, le commissioni di transazione rappresentano un ulteriore aspetto dell’ingegneria economica per mantenere la blockchain sostenibile. Vuoi poter mantenere questa commissione di 0,1 centesimo a qualsiasi scala, perché un altro problema della scalabilità massiva è che, se abbiamo milioni di transazioni, il costo delle stesse salirà alle stelle. Questo è un grande problema che non desideriamo. Non vogliamo una situazione in cui un autobus con 100 persone pronte a salire abbia solo 50 posti. Se ciò accade, si instaurerà una sorta di meccanismo d’asta e il prezzo dei biglietti salirà alle stelle. In termini di blockchain, questo significa che il costo delle transazioni salirà vertiginosamente. A proposito, questo genere di problemi sta accadendo con più blockchain al momento. Ad esempio, sulla rete Bitcoin Core è molto frequente che il costo di una transazione superi i dieci dollari, e questo è un problema molto serio.

Ora, vogliamo anche avere una latenza abbastanza bassa. Quello che Satoshi Nakamoto ha scoperto nel 2008, il consenso Nakamoto, funziona molto bene, ma fondamentalmente è un processo molto lento. Quando dico “molto lento”, intendo che per i partecipanti convergere sullo stato del sistema ci vuole all’incirca un’ora. Non è terribilmente lento, ma nemmeno molto veloce. Se vogliamo fare qualcosa legato alla supply chain, dove desideriamo effettuare pagamenti o tracciare il movimento delle merci, sarebbe molto meglio se potessimo mantenere la latenza del sistema a circa tre secondi o meno – lo stesso tipo di latenza che ci si aspetta da un pagamento rapido con carta di credito.

Infine, uno degli ultimi requisiti è l’infrastruttura. Quando parlo dell’infrastruttura software che supporta il blockchain o la criptovaluta, essa deve essere un bene pubblico finanziato da una forma di contratto sociale concordato. Credo che Satoshi Nakamoto non lo avesse previsto nel 2008. Se vuoi gestire un sistema distribuito globale molto complesso, c’è una quantità enorme di infrastruttura software da implementare e mantenere. Il problema è che, se non possiedi un modo socialmente accettato per finanziare tutti questi sforzi, emergono avversari, non solo come avversari bizantini nella rete che cercano di confondere gli altri partecipanti sullo stato della rete, ma anche come avversari che prenderanno il controllo stesso del codice e agiranno sull’infrastruttura software in modi che antagonizzano gli interessi della comunità più ampia. È successo nella storia delle criptovalute che una squadra ostile subisca il controllo da parte di un’altra, con le nuove squadre aventi interessi completamente disallineati da quelli della comunità più ampia. Questa è una tipologia di attacchi, più orientata all’ingegneria sociale, che Satoshi Nakamoto non aveva chiaramente previsto nel 2008. Tuttavia, dopo un decennio di operazioni, questo tipo di attacchi risulta oggi molto più evidente agli osservatori del mondo crypto.

Adesso, la storia finora: questa è una serie di lezioni sulla supply chain. Siamo nella parte del quarto capitolo. Nel primo capitolo, ho presentato le mie opinioni sulla supply chain come campo di studio e come pratica, e abbiamo visto che richiede metodologie molto specifiche. L’intero secondo capitolo è dedicato alle metodologie di supply chain adatte a operare in questo ambito. La maggior parte delle metodologie naive non sopravvive al contatto con la realtà, soprattutto quando esistono conflitti di interesse. A proposito, molti degli aspetti affrontati nel secondo capitolo, dove mi occupo dei conflitti di interesse, sono molto pertinenti per la lezione di oggi, quindi invito il pubblico, se non ha ancora visto le lezioni del secondo capitolo, a dare un’occhiata a quelle. Il terzo capitolo è dedicato ai supply chain problems, che sono letteralmente lezioni in cui mi concentro esclusivamente sui problemi della supply chain, non sulle soluzioni. L’idea è capire veramente il problema prima di iniziare a inventare soluzioni.

Il quarto capitolo è essenzialmente una raccolta di scienze ausiliarie. Blockchain è un argomento marginale che sto aggiungendo alla fine di questo capitolo, ma fondamentalmente le scienze ausiliarie sono discipline che supportano realmente le pratiche moderne della supply chain. Proprio come ci si aspetterebbe da un medico moderno di avere qualche conoscenza di chimica, non è necessario essere un brillante chimico per essere un brillante medico. L’accordo generale sarebbe che, da una prospettiva moderna della scienza medica, se non sai nulla di chimica, non puoi essere considerato un bravo medico secondo gli standard attuali. Lo stesso vale per la supply chain, a mio avviso. Esiste una serie di scienze ausiliarie per le quali è necessario avere una certa preparazione se si vuole operare una supply chain in maniera ragionevolmente moderna.

Ora, per la lezione odierna, presenterò prima Mini Bitcoin, che è un’implementazione giocattolo di blockchain. Dovrebbe far luce su come funzionano le criptovalute e su quale fosse l’intuizione chiave scoperta da Satoshi Nakamoto nel 2008. Dovrebbe anche chiarire le tre grandi sfide che affrontiamo nel progettare le blockchain, ossia scalabilità, latenza ed espressività. Queste tre sfide hanno un impatto significativo sul tipo di casi d’uso della supply chain che possiamo avere basati su blockchain. È essenziale comprendere i limiti delle blockchain, poiché limitano sostanzialmente ciò che possiamo fare in ambito supply chain e il tipo di valore che possiamo creare. Infine, come seconda parte della lezione, esaminerò una serie di casi d’uso della supply chain in cui, a vari gradi, la supply chain ha qualcosa da offrire.

L’obiettivo di Mini Bitcoin è costruire una blockchain giocattolo, una versione semplificata di Bitcoin da zero. Non ci concentreremo troppo su tutte le tecnicalità coinvolte perché, nella vita reale, ingegnerizzare una blockchain richiede davvero di prestare attenzione a una miriade di dettagli. Qui, voglio solo delineare la struttura generale per mantenerla drammaticamente semplificata rispetto alla realtà, in modo da poter comprendere in poche slide cosa sta succedendo, come viene ingegnerizzata e come funziona.

In questo esempio molto semplice, ingegnerizzeremo una valuta in cui ogni singola moneta vale esattamente un bitcoin. Hai un insieme di monete, ciascuna moneta vale esattamente un bitcoin, e l’unica cosa che puoi fare è sostanzialmente trasferire una moneta da un partecipante all’altro. Se un partecipante possiede molte monete, può trasferirle tutte, ma stiamo considerando una valuta molto semplice in cui non esistono quantità frazionarie né altri elementi.

Per costruire questo Mini Bitcoin, ci servono solo tre funzioni speciali: una funzione hash, una funzione di firma e una funzione di verifica. Queste funzioni erano già standard nel 2008, quindi quando fu inventato Bitcoin, tutti i mattoni crittografici erano già in atto. Satoshi Nakamoto non ha inventato nessuno di questi strumenti. Queste funzioni crittografiche speciali, note anche come funzioni a porta trappola, erano ben note, standard e ampiamente usate nel 2008. L’innovazione chiave di Satoshi Nakamoto fu utilizzare queste funzioni in un modo molto speciale, come vedremo.

Abbiamo queste tre funzioni: la funzione di hashing, della quale non entrerò nei dettagli qui, ma di cui ho discusso in una lezione precedente. Si tratta di una versione crittografica della funzione di hashing, che può prendere un qualsiasi messaggio, una serie di bit di lunghezza arbitraria, e creare un digest di 256 bit. La funzione, in pratica, non può essere invertita. Se possiedi un digest, l’unico modo per identificare un messaggio che lo produce è conoscere in anticipo il messaggio.

La funzione di firma può prendere un messaggio, una chiave privata, e produrre una firma, che è anch’essa di 256 bit. La funzione di firma lavora in coppia con una funzione di verifica. Per chi non fosse familiare con la crittografia asimmetrica, l’idea è che esistono meccanismi che prevedono coppie di chiavi pubbliche e private. Con la chiave privata puoi produrre una firma e pubblicare un messaggio senza rivelare la tua chiave privata. Qualsiasi partecipante può usare la funzione di verifica per prendere il messaggio, la tua firma e la tua chiave pubblica e verificare che il messaggio sia stato firmato dalla chiave privata associata a quella chiave pubblica.

Queste funzioni a porta trappola non possono essere invertite, quindi se non conosci il messaggio originale, non puoi risalire dalla funzione hash, dal digest, al messaggio originale. Lo stesso vale se non possiedi la chiave privata; non puoi produrre una firma da solo per un nuovo messaggio.

Queste tre funzioni speciali sono facilmente disponibili in praticamente tutti gli ambienti di programmazione moderni, sia che si tratti di C++, Python, Java, C# o altri. Fa parte dell’ambiente standard avere accesso a queste classi di funzioni crittografiche.

Ora, esaminiamo una situazione in cui dovrei essere il proprietario della moneta numero uno. Cosa significa questo? Significa che, come parte di questo consenso bizantino, esiste un accordo condiviso tra tutti i partecipanti per questa rete mini Bitcoin, secondo il quale, come parte dell’UTXO (Unspent Transaction Outputs), questa moneta è effettivamente presente. Quando dico “questa moneta”, intendo un messaggio che include la chiave pubblica numero uno e la firma zero. Presumo semplicemente che questa faccia parte di un insieme di monete e che tutti i partecipanti concordino sul fatto che essa esista realmente ed è pronta per essere spesa. Ora, in qualità di proprietario di questa moneta numero uno, come posso effettivamente spendere questa moneta per trasferirne la proprietà a qualcun altro?

Il modo in cui lo faccio è producendo una firma. La firma viene costruita come segue: sto usando la funzione speciale “sign” e firmerò un messaggio. Questo messaggio consisterà semplicemente nella chiave pubblica numero uno, firma zero, e poi la chiave pubblica numero due. La chiave pubblica numero due è letteralmente l’indirizzo a cui sto inviando il denaro. Chi possiede la chiave privata associata a questa chiave pubblica numero due sarà il destinatario della mia transazione. Quindi, firmo questa transazione e, per firmarla, utilizzo la chiave privata numero uno. L’unico partecipante che può effettivamente produrre questa firma numero uno è la persona che possiede il segreto, ossia la chiave privata numero uno, associata alla chiave pubblica numero uno.

Se desidero rendere nota a tutta la rete l’avvenuta transazione, devo trasmettere una transazione. La transazione consisterà semplicemente in un messaggio che elenca la chiave pubblica numero uno, firma zero, chiave pubblica numero due e firma uno che ho appena prodotto. È soltanto una lista degli elementi che compongono la transazione. Quando pubblico questa transazione da uno a due, sostanzialmente la moneta numero uno esce dal pool delle monete e la moneta numero due entra nel pool come parte del sistema. Per questo è cruciale avere in atto questo consenso bizantino. Ci serve il consenso bizantino perché, potenzialmente, si potrebbe cercare di spendere denaro che non si possiede e confondere la rete riguardo alla proprietà di alcune monete. Tuttavia, se riesci a risolvere il problema del consenso bizantino, esiste un accordo fermo sulle monete che effettivamente appartengono al sistema. Una volta che una moneta viene spesa, il proprietario numero due adesso possiede una moneta. Una moneta può uscire dalla rete e una nuova moneta viene creata ed entra nello stato del sistema.

Il meccanismo può essere ripetuto; la moneta numero due può essere inviata alla moneta numero tre utilizzando lo stesso sistema: produrre una firma, trasmettere una transazione, e così via.

A proposito, ogni volta che ho detto che viene utilizzata la funzione “sign”, implicitamente significa che tutti gli osservatori possono usare la funzione “verify” per verificare che la firma sia corretta. Fondamentalmente, quando i partecipanti osserveranno le transazioni, la prima cosa che faranno sarà usare la funzione “verify” che ho illustrato precedentemente per controllare che la transazione sia effettivamente valida. Sono previsti due controlli: ogni partecipante deve verificare che la moneta trasferita facesse già parte dello stato del sistema, garantendo la sua validità, e che la transazione sia valida secondo la firma. Ciò che non ho affrontato qui è il problema del doppio-spend. Come impediamo che vengano effettuate due transazioni in conflitto contemporaneamente e come evitiamo che la rete si confonda se un avversario tenta di trasmettere simultaneamente due transazioni conflittuali, inviando lo stesso denaro a due partecipanti distinti?

Non ho neanche chiarito da dove provengano queste monete. Come vengono introdotte nel sistema in primo luogo? Il nocciolo della scoperta di Satoshi Nakamoto e del suo Nakamoto Consensus consiste proprio nel risolvere entrambi questi problemi contemporaneamente.

La proposta di Satoshi Nakamoto è di introdurre una classe speciale di partecipanti nella rete, oggi soprannominati “miners.”

I miners essenzialmente ascoltano la rete e raccolgono tutte le transazioni trasmesse. Raccolgono queste transazioni e le inseriscono in un contenitore chiamato “block.” Un block è semplicemente una raccolta di transazioni trasmesse da chiunque nella rete peer-to-peer.

La primissima transazione di un block sarà una transazione speciale chiamata “coinbase.” Una coinbase è una transazione unica che crea una nuova moneta in questo setup di mini Bitcoin dal nulla. La prima transazione è la coinbase, che crea una nuova moneta dal nulla, e poi nel block segue l’elenco delle transazioni trasmesse, così come percepite dal miner. Il miner potrebbe non essere in grado di catturare tutte le transazioni della rete Bitcoin, ma ci prova.

La coinbase è speciale, e spiegherò come costruirla perché è una transazione unica. Per prima cosa, produrremo un hash del block, un hash parziale (H1a). Questo hash è essenzialmente l’hash di un messaggio, e questo messaggio inizia con l’hash del block precedente (H0b), concatenato a tutte le transazioni presenti nel block.

La coinbase è quindi una tupla che include l’hash H1a, seguito da un nonce. Un nonce è un numero casuale scelto dal miner e riveste un’importanza fondamentale. La coinbase contiene anche la chiave pubblica del miner. Essa include un hash dell’intero contenuto del block, un numero casuale e la chiave pubblica del miner. Questa chiave pubblica verrà utilizzata successivamente dal miner per reclamare la coinbase come una moneta regolare. In questo setup di mini Bitcoin, le monete vengono emesse ad un ritmo di un Bitcoin per block. In realtà, nella rete Bitcoin Core o in Bitcoin Cash, il processo è più complicato, ma la maggior parte della complessità può essere semplificata per motivi di chiarezza.

L’idea è che, affinché il block sia considerato valido, dobbiamo produrre una coinbase. Tuttavia, se ci fermiamo qui, tutti i miners potrebbero sostenere di avere un block quando lo desiderano, e tutti avrebbero interesse a dire: “Posso produrre un pacchetto, un digest di tutte quelle transazioni. Posso produrre una coinbase. Per favore, concedetemi questo Bitcoin extra.” Come facciamo a fare in modo che, tra tutti i miners in competizione per avere la loro versione del block selezionata dalla rete, venga scelta quella vera?

Satoshi Nakamoto introdusse il concetto di proof of work. L’hash della coinbase, che è un grande numero a 256 bit, deve essere al di sopra di una soglia di difficoltà. Questo processo è come risolvere un enigma, e l’unico modo per risolverlo è trovare una coinbase il cui hash soddisfi l’obiettivo di difficoltà. Il miner può provare molti numeri casuali per il nonce nella speranza di essere il primo a raggiungere la difficoltà e a reclamare il block per sé.

In Bitcoin, la difficoltà è adattiva, e la rete utilizza un algoritmo basato essenzialmente su una media mobile per mantenere la difficoltà intorno ai 10 minuti per block. Se i block vengono trovati, in media, ad un ritmo più veloce di 10 minuti, la difficoltà aumenterà finché i block non verranno trovati ogni 10 minuti in media. Se i block iniziano ad essere trovati ogni 11 minuti, la difficoltà diminuirà per mantenere il tempo medio di individuazione di un block a 10 minuti.

La proposta di Satoshi Nakamoto è che i minatori seguano sempre la blockchain valida più lunga. Una catena di blocchi deve soddisfare l’obiettivo di difficoltà per essere valida. Quando si costruisce un blocco, lo si costruisce sempre sopra un blocco preesistente, ad eccezione del blocco genesi, che rappresenta il punto di partenza predefinito. La regola non riguarda solo l’avere la catena più lunga, ma la catena valida più lunga. Altri minatori verificheranno che tutte le transazioni elencate in un blocco siano effettivamente valide, assicurandosi che le firme corrispondano e che le monete spese siano idonee ad essere spese. Essi mantengono questo stato, ed è esattamente così che Bitcoin può risolvere sia il problema del double-spend sia quello dell’emissione delle monete. Abbiamo tutto il necessario per costruire una blockchain.

In realtà, se vuoi costruire una blockchain di livello produttivo, ci sono un sacco di ulteriori aspetti da considerare. Prima di tutto, vorresti avere quantità frazionarie. Probabilmente non vuoi poter avere un solo Bitcoin alla volta; desideri qualcosa in cui poter trasferire quantità multiple o frazionarie di Bitcoin.

In termini di monete, vorresti avere transazioni che possano consumare molte monete come input contemporaneamente e poi produrne molte altre. Non si tratterà di transazioni uno-a-uno che collegano una moneta a un’altra; saranno transazioni molti-a-molti, con molti input collegati a molti output. A proposito, è così che operano attualmente varie reti Bitcoin.

Hai anche le commissioni di transazione che ho menzionato. Se lasci che le persone trasmettano transazioni all’infinito, potrebbero inviare denaro avanti e indietro tra gli stessi indirizzi, inondando il mercato. L’idea è che una commissione rappresenti fondamentalmente il concetto secondo cui una certa parte della transazione viene reindirizzata al minatore. Il modo tipico in cui viene fatto nella maggior parte delle varianti di Bitcoin è stabilire che l’input totale, in termini di valore monetario, debba essere leggermente superiore all’output totale. La frazione di valore mancante, il gap, è la ricompensa pagata al minatore.

Ora abbiamo completato il nostro mini Bitcoin. Se sai programmare, hai tutti gli elementi necessari per implementare la tua blockchain. A proposito, puoi anche ripetere i blocchi, ed è proprio quello che sto facendo qui. Quello che hai appena fatto per un blocco, lo puoi ripetere con le stesse formule per un altro blocco, con un secondo codice. È proprio come le transazioni; lo stesso meccanismo si ripete più e più volte.

Scalare la blockchain è una sfida molto ardua. In un breve white paper del 2018, ho pubblicato un panorama applicativo di Bitcoin. L’idea è che, a seconda della quantità di dati coinvolti nelle tue blockchain, la quantità di dati che devi elaborare e trasferire varia notevolmente in base a ciò che fai con la blockchain. Essenzialmente, varia da circa 100 byte da trasferire (l’ordine di grandezza di una chiave privata) fino a 10 ordini di grandezza se devi gestire l’intera blockchain.

È difficile comprendere il fatto che, a seconda di ciò che stai facendo, la quantità di risorse computazionali che dovrai impiegare per portare a termine il lavoro varia di 10 ordini di grandezza. Un ordine di grandezza significa moltiplicare la quantità di risorse per un fattore di 10, e quando si arriva a 10 ordini di grandezza, si passa da uno a 10 miliardi. Questo è sorprendente ed enorme. In questo panorama applicativo vedrai che ci sono due principali distinzioni: applicazioni on-chain e off-chain. Le app off-chain sono quelle che si occupano solo dei dati generati da te o dai tuoi partner stretti. Se sei una grande azienda, potresti dover gestire milioni di transazioni, ma queste sono solo le tue transazioni. In termini di dati, può essere in grande quantità, ma è gestibile poiché riguarda direttamente il tuo business.

Dall’altra parte, le app on-chain si occupano di tutte le transazioni trasmesse in rete. Questo può essere enormemente più grande, specialmente se sei un piccolo attore e devi gestire tutte le transazioni su una grande rete, che possono essere milioni di volte superiori a quelle che ti interessano.

Inoltre, dobbiamo distinguere tra componenti che sono “ingranaggi di cassa” e “terreni di cassa”. Gli ingranaggi di cassa sono componenti fondamentali che contribuiscono alla risoluzione del problema del consenso. Se li rimuovi, la blockchain smette di funzionare perché non c’è più consenso. I terreni di cassa, invece, sono componenti opzionali che possono essere costruiti sopra l’infrastruttura della blockchain. Questi non sono strettamente necessari affinché la blockchain operi.

Tipicamente, quando pensiamo ai casi d’uso della supply chain, ci posizioniamo con i metadata nel regno dei terreni di cassa. Quello che stiamo facendo non è strettamente necessario affinché la blockchain continui a operare; potrebbe funzionare anche senza il nostro specifico caso d’uso.

In termini di scalabilità della blockchain per veri casi d’uso della supply chain, devi considerare che la blockchain dovrebbe essere in grado di gestire milioni di transazioni. Le grandi aziende gestiscono milioni di transazioni settimanali, il che non è eccezionale nel mondo della supply chain. Tuttavia, le blockchain sono scarsamente scalabili, come dimostra il fatto che i minatori devono gestire tutte le transazioni di tutti.

Per affrontare questo problema, sono state introdotte alcune innovazioni, come le soluzioni discusse precedentemente nella lezione. L’obiettivo principale è rendere la tecnologia blockchain più scalabile e adatta a gestire il massiccio volume di transazioni tipico delle applicazioni della supply chain. Se vuoi che una blockchain venga utilizzata per scopi di supply chain, deve essere in grado di gestire non solo le transazioni di una singola azienda, ma anche quelle di tutte le aziende che partecipano all’iniziativa blockchain. Questo può diventare estremamente grande, o addirittura veramente enorme, forse estremamente così. È ciò che dobbiamo analizzare, e qui, per fortuna, sono emersi essenzialmente due documenti notevoli. Quando Satoshi Nakamoto pubblicò il suo documento, affermò che con il progresso dell’hardware questo problema sarebbe stato risolto e avremmo scalato fino a quanto necessario. Questo sarebbe accaduto. Tuttavia, si è rivelato difficile, e da più di un decennio praticamente tutti gli attori nel settore della blockchain e delle criptovalute hanno lottato in termini di scalabilità.

Il primo articolo notevole è ECMH, Elliptic Curve Multiset Hash. È un documento piuttosto tecnico, ma il punto fondamentale è l’idea che non devi conservare tutte le transazioni; ti basta conservare le monete pronte per essere spese. Questa collezione di monete che possono essere spese è tecnicamente nota nell’ecosistema Bitcoin come UTXO. A titolo esemplificativo, l’UTXO della rete Bitcoin Core è attualmente leggermente inferiore a cinque gigabyte. Questa è la dimensione del dataset UTXO, ma se consideri la blockchain di Bitcoin Core, la sua dimensione è leggermente inferiore a 350 gigabyte, e la blockchain sta crescendo molto più rapidamente dell’UTXO.

Quello che l’articolo ECMH ti fornisce è una funzione hash che ha un’affinità con i multiset. Fondamentalmente, è una funzione hash che ti permette di aggiornare il tuo hash se aggiungi o rimuovi elementi dalla tua collezione. Non conservi l’insieme o il multiset stesso, ma solo l’hash, e puoi aggiungere o rimuovere elementi. Questa proprietà, simile a quella di un set, significa che puoi effettuare tali aggiunte o eliminazioni in qualsiasi ordine ottenendo comunque lo stesso hash. Ciò che puoi ottenere tramite ECMH è una forma di impegno UTXO, che permette alla comunità di allontanarsi dalla blockchain completa. La maggior parte della comunità non deve occuparsi della blockchain completa, ma può concentrarsi solo sull’UTXO. Ripeto, la dimensione dell’UTXO della rete Bitcoin Core è di cinque gigabyte, mentre la blockchain è di 350 gigabyte, quindi si ottengono praticamente due ordini di grandezza. Questo è molto significativo. Essenzialmente, con ECMH guadagni due ordini di grandezza in termini di memorizzazione persistente dei dati, il che rappresenta un enorme vantaggio.

Il secondo documento è Graphene, un nuovo protocollo per la propagazione dei blocchi che utilizza la riconciliazione dei set. Graphene ti permette di guadagnare sostanzialmente due ordini di grandezza sui requisiti di banda di picco. In questo setup mini Bitcoin che ho appena descritto, hai minatori e transazioni trasmesse in modalità peer-to-peer continuamente in rete. La banda è probabilmente il problema più risolto di Bitcoin, ma comunque, sorge un problema di banda nel momento in cui viene trovato un blocco. Il minatore, per poter reclamare il blocco, deve propagare il coinbase, in cui dichiara: “Guarda, ho un coinbase che soddisfa il mio obiettivo di difficoltà.” Poi, tutti gli altri minatori devono scaricare l’intero blocco e, se fatto in modo ingenuo, devono validare che il blocco sia effettivamente valido, non solo che il coinbase soddisfi l’obiettivo di difficoltà.

Ogni volta che viene trovato un blocco, si genera un picco di richiesta perché vuoi che il tempo necessario per trasferire un intero blocco, se fatto in modo ingenuo, sia ben al di sotto dell’intervallo di 10 minuti. In Bitcoin, l’enigma è tarato in termini di difficoltà in modo tale che il tempo medio fra due blocchi consecutivi sia di 10 minuti. Pertanto, desideri che il trasferimento del blocco avvenga in una frazione di questo tempo, diciamo meno di 30 secondi, se vuoi mantenere la rete molto stabile. Tuttavia, questo significa che il blocco deve essere trasferito in 30 secondi, il che pone un limite sulla banda di picco.

L’idea è che con Graphene, una tecnica basata sulla compressione, non sarà necessario trasferire l’intero blocco, poiché la maggior parte di ciò che il blocco contiene sono in realtà le transazioni già trasmesse attraverso la rete. L’unica cosa che vuoi trasmettere è un set di riconciliazione, solo per fornire informazioni ai tuoi peer (altri minatori) su quali transazioni siano state incluse o meno nel tuo blocco, in maniera perfettamente affidabile. Se fai così, potrai risparmiare nuovamente due ordini di grandezza sulla banda di picco, il che è molto significativo.

Questo è di grande interesse; ad esempio, Graphene funzionerebbe sulle reti Bitcoin Cash o sulle più recenti reti eCash, a causa di peculiari accidenti tecnici. Non funzionerebbe sulla rete Bitcoin Core. Questo faceva parte delle cose che Satoshi Nakamoto non aveva realmente previsto.

L’ultimo requisito che ho menzionato nella mia lista è che mantenere il software significa dover avere un contratto sociale in atto, in modo da poter contare su team capaci di occuparsi della manutenzione e di integrare successivamente nuove scoperte nella tua blockchain. Altrimenti, rimarrai bloccato con quelle prestazioni e quella stabilità che avevi un decennio fa o al momento dell’inizio della blockchain.

Ora abbiamo un altro problema: accelerare la blockchain. La rete Bitcoin classica ha un tempo medio fra i blocchi di 10 minuti, e se vuoi avere una vera fiducia nello stato del consenso, devi aspettare più blocchi. Come regola generale, si stima che per avere fiducia assoluta occorrano sei conferme, il che comporta un lasso di tempo di un’ora. L’idea è che si potrebbe accorciare questo intervallo tra i blocchi. Tuttavia, il problema è che meno tempo c’è, più piccoli devono essere i blocchi, il che mina la scalabilità. Blocchi poco frequenti significano che puoi avere blocchi molto grandi, il che è positivo perché aiuta la rete a gestire l’enorme massa di transazioni.

Considerando i ritardi presenti sulla rete globale, questo obiettivo di 10 minuti non è ottimale, ma rientra nell’ordine di efficienza per far funzionare questo tipo di consenso distribuito con blocchi molto grandi, blocchi che possono arrivare fino a un terabyte. Suona molto grande, ma in realtà, se si guarda al caso d’uso su scala umana, è ciò che serve. Devi mantenere i blocchi ben distanziati nel tempo se vuoi preservare la scalabilità. Tuttavia, questo comporta il problema di una rete lenta. Un’ora per confermare una transazione potrebbe andar bene per un caso d’uso nell’e-commerce, dove non importa se dopo il pagamento non accade nulla per 60 minuti, dato che la consegna non avverrà comunque prima di domani. Ma se si vuole operare all’interno di un magazzino o al punto vendita, questo è decisamente troppo lento. È come una carta di credito che richiederebbe un’ora per essere accreditata, il che è troppo lento.

Quello che desideriamo di solito è un obiettivo che sia di tre secondi o meno. Questo perché, dal punto di vista dell’esperienza utente, qualcosa che impiega tre secondi per essere elaborato sarà percepito come abbastanza veloce. Pensalo come un pagamento con carta di credito; se conti uno-due-tre al momento del pagamento, va bene, è ragionevolmente veloce. Se puoi garantire completa sicurezza in questo lasso di tempo, otterrai un’esperienza utente molto decente per la maggior parte dei casi d’uso. È comunque troppo lento per comunicazioni machine-to-machine a bassa latenza, ma è sufficiente per la maggior parte dei casi d’uso che coinvolgono la percezione umana.

Per quasi un decennio sono state presentate numerose soluzioni per affrontare questo problema di latenza. La stragrande maggioranza di queste soluzioni non era molto valida. Tutte presentavano varie limitazioni che compromettevano Bitcoin o la sua scalabilità, oppure erano soluzioni ingenue nate rapidamente una volta pubblicato Bitcoin. La maggior parte di queste soluzioni si basava sull’elezione di un leader, il quale agiva come un’autorità centrale temporanea per un certo periodo, fornendo servizi a bassa latenza. Tuttavia, il problema nell’elezione di un leader è che quando si passa da un leader a un altro, il processo può diventare molto caotico, e in termini di qualità del servizio, la maggior parte del tempo si registra solo qualche secondo, mentre a volte si arriva addirittura a un’ora. Questo verrebbe percepito da tutti come un periodo di inattività della rete.

Ci è voluto un decennio affinché venisse pubblicata una soluzione che, a mio avviso, fosse sufficientemente valida. Questa soluzione è un brillante lavoro di un team anonimo chiamato Team Rocket, pubblicato nel maggio 2018: Snowflake to Avalanche, un’altra famiglia di protocolli di consenso metastabile per criptovalute. Questo articolo presenta una serie di tre algoritmi: Snowflake, Snowball e Avalanche. Ogni algoritmo è costruito sul precedente e, a proposito, la vera magia risiede nell’algoritmo Snowball, che è proprio quello che non compare nel titolo dell’articolo.

Fondamentalmente, ciò che hanno ingegnerizzato è la metastabilità, ed è molto interessante. Ricorda, quando hai transazioni in conflitto, non importa davvero quale venga scelta perché migliorare la latenza significa prevenire la doppia spesa o, in realtà, ridurre il lasso di tempo in cui può sorgere ambiguità sulla doppia spesa. L’idea di avere qualcosa di meta-stabile è quella di voler un protocollo in cui i partecipanti comunicano costantemente tra loro. L’obiettivo è che, se ci sono due transazioni in conflitto, la rete raggiunga un equilibrio metastabile. La rete convergerà rapidamente verso un’interpretazione della verità; non importa quale, deve semplicemente essere una. Quindi, se ci sono oggetti in conflitto, la rete discuterà e risolverà il conflitto.

Snowflake fornisce un processo di convergenza lento, mentre Snowball, in questo articolo, offre un trucco che permette un’accelerazione esponenziale, portando a una convergenza molto più rapida. Avalanche contribuisce con alcune proprietà grafiche relative al grafo delle transazioni. Tuttavia, la mia comprensione personale è che il contributo di Avalanche sia molto più debole; è davvero Snowball a fare la magia. Potresti voler implementare Avalanche, ma solo Snowball ti darà circa il 99% della metastabilità che cerchi.

C’è un inconveniente in questo approccio. Con il proof of work e i blocchi di Satoshi Nakamoto, qualsiasi osservatore può intervenire e testimoniare ciò che è accaduto, riproducendo l’intero processo e verificando tutto. La sicurezza non dipende dal fatto che l’osservatore sia online. L’osservatore può essere online o offline, e non importa. Questo è un ottimo modello di sicurezza che non si basa su una connessione live alla rete.

Avalanche, d’altra parte, richiede che l’osservatore monitori costantemente le chat della rete per generare sicurezza. Non è possibile per un osservatore tardivo unirsi e rivalutare la sicurezza delle transazioni passate. Tuttavia, non ci interessa davvero questo problema perché, se sei attivo sulla rete, valuti la sicurezza delle transazioni che avvengono in quel momento. Per le cose che sono accadute in passato, quando non eri presente, il proof of work e i blocchi forniscono comunque un modo per convalidare le transazioni.

Avalanche non è in opposizione a Bitcoin; è complementare. Uno degli aspetti deboli della soluzione da Snowflake ad Avalanche è che non fornisce una soluzione chiara al problema dell’emissione delle monete. Per avere il meglio di entrambi i mondi, sarebbe ideale mantenere un design simile a Bitcoin con proof of work e grandi blocchi, sovrapponendovi però una sicurezza a bassa latenza.

Per evitare certe tipologie di attacchi Sybil che potrebbero confondere Avalanche, potrebbe essere impiegato il proof of stake. Questo introduce strati di intrecci economici, che è un modo di pensare molto alla Bitcoin. Per ottenere la sicurezza desiderata, dovrebbe essere creata una rete di intrecci economici per garantire che tutti rimangano onesti. Esistono modi per progettare soluzioni che garantiscano una latenza migliore.

Ora, sempre sul tema dell’espressività, cerchiamo qualcosa in più rispetto alle sole transazioni finanziarie, poiché si tratta di supply chain e dell’utilizzo di una blockchain per scopi di supply chain. Le transazioni finanziarie sono necessarie come sfondo, ma vogliamo poter fare di più. La domanda è: come incorporiamo questa logica extra?

Nel mondo delle criptovalute, molte criptovalute hanno introdotto la nozione di smart contracts. Uno smart contract è fondamentalmente un programma gestito dagli stessi miners sulla blockchain. I miners controllano la validità delle transazioni, ma se puoi includere un linguaggio di programmazione o codice assembly come parte della tua transazione, i miners potrebbero eseguire i programmi e verificare che questi soddisfino certe proprietà. Questo è ciò che normalmente si fa su Ethereum, ed è definito smart contract. Esiste il motto “code is law”, che significa che confidiamo nell’esecuzione del programma perché certificato come corretto dagli stessi miners.

Tuttavia, credo che questo approccio sia profondamente fuorviante su due fronti molto diversi. Il primo problema è che peggiori notevolmente il problema della scalabilità. Scalare una blockchain è già molto difficile, poiché devi indirizzare tutte quelle transazioni verso i miners. I miners non devono fare molto con queste transazioni; devono solo controllare la firma. Un miner può potenzialmente elaborare un’enorme quantità di transazioni perché il numero di controlli da effettuare per ciascuna transazione è minimo. Ora, immagina se a un miner non bastasse validare le transazioni, ma dovesse anche eseguire programmi arbitrari provenienti da tutte le aziende. Diventa molto difficile, ed è esattamente ciò che sta accadendo da tempo sulla rete Ethereum e su altre criptovalute orientate verso contratti complessi.

Sebbene criptovalute successive come Ethereum abbiano beneficiato di una migliore ingegneria, si trovano ancora ad affrontare un problema di scalabilità enormemente più difficile. Una volta raggiunto un certo livello di notorietà e attività sulla rete, tutte si trovano ad avere problemi massicci di scalabilità. Tutto si riduce al fatto che devi eseguire tutti quei programmi.

Il secondo problema principale degli smart contracts è che sono fondamentalmente programmi immutabili. Quando metti programmi sulla blockchain, l’idea è che confidi in quei programmi perché operano autonomamente. Per “autonomamente” si intende che ci sono miners con incentivi finanziari per eseguire quei programmi per la comunità, e l’intero processo è trasparente e verificabile. Tuttavia, il grande problema dei programmi immutabili è che, se c’è un bug, non puoi risolverlo.

La storia degli smart contracts è stata una serie infinita di violazioni che hanno portato a perdite massicce per chi gestiva i contratti. Anche Ethereum stesso ha dovuto subire un fork massiccio, portando a Ethereum ed Ethereum Classic, perché un contratto violato era così significativo che gli operatori hanno deciso fosse meglio annullare i problemi e minare la proprietà immutabile che la blockchain dovrebbe offrire. Non esiste una soluzione alternativa, e se fai qualcosa di non banale in uno smart contract, ti esponi a violazioni.

Nel 2018, ho pubblicato un altro approccio chiamato Tokida che mostra come puoi avere programmi arbitrari in esecuzione accanto alla blockchain. Con Tokida, il programma è open-source e funziona su un modello “trust but verify”. Tutte le persone interessate all’esito del contratto possono verificare se lo desiderano, e in termini di prestazioni, è più flessibile perché il resto della comunità non deve eseguire il tuo programma. Se vuoi correggere il tuo software, puoi farlo in qualsiasi momento senza che il resto della comunità rimanga all’oscuro di ciò che hai fatto.

Se si verifica una violazione, non è un problema significativo perché puoi correggerlo, e la comunità può verificare che la patch è stata effettuata in buona fede. L’intuizione è che la maggior parte di ciò che serve in termini di modello di sicurezza per la supply chain è semplicemente “trust but verify”. Devi solo assicurarti che, se qualcuno imbroglia, tutte le altre persone lo notino, e questo sarà sufficiente. Per la valuta stessa, vuoi impedire che le persone imbrogliino fin dall’inizio. Ma per gli smart contracts non serve lo stesso grado di sicurezza della valuta stessa. Essere in grado di rilevare le frodi dopo il fatto è sufficiente. Se qualcuno inizia a frodare la tua azienda, semplicemente non farai più affari con quel partner, e questa sarebbe la fine della storia. Non hai bisogno di qualcosa che impedisca alle frodi di verificarsi in primo luogo. La fiducia è essenziale negli affari e, se lavori con un partner, hai un certo grado di fiducia con lui.

Ora, stiamo entrando nella seconda parte della lezione, che tratta dei casi d’uso. Credo che il caso d’uso principale per le blockchain rimanga quello dei pagamenti. Pagare i fornitori, specialmente quelli esteri, può ancora rappresentare una sfida. L’esecuzione di un bonifico può essere lenta, arrivando fino a due settimane in alcuni casi. I flussi di lavoro dei pagamenti nel sistema bancario sono tutt’altro che aggiornati al XXI secolo, il che può portare a errori come pagamenti duplicati per fatture elevate.

Credo che ci siano molti casi d’uso per i pagamenti, specialmente quando si tratta di implementare meccanismi complessi come pagamenti posticipati, pagamenti condizionali o penalità per prodotti che non rispettano i requisiti di qualità o le scadenze. Con il denaro programmatico, puoi implementare tutti questi schemi in modi che sembrerebbero fantascienza.

Tuttavia, ci sono due avvertenze per questo caso d’uso. In primo luogo, le criptovalute sono ancora incredibilmente volatili, il che significa che il loro valore può fluttuare drasticamente nel tempo. Questa volatilità è un problema persistente, ma nell’ultimo decennio è diminuita. La volatilità era anche più alta dieci anni fa, ed è gradualmente calata da allora, ma rimane comunque al di fuori della zona di comfort della maggior parte delle grandi aziende. Osservare fluttuazioni giornaliere del 10% nel valore di queste criptovalute è ancora la norma. Un decennio fa, era intorno al 50%. Il secondo problema per i pagamenti è l’esistenza di migliaia di criptovalute, che crea il problema di sceglierne una e concordare con il partner. Tuttavia, esistono sistemi di cambio robotizzati in grado di convertire qualsiasi criptovaluta in un’altra, con commissioni molto basse, come lo 0,1%, il che aiuta a mitigare questo problema.

Un altro caso d’uso è la tracciabilità passiva. La tracciabilità è essenziale in molte industrie, come l’aerospaziale, il farmaceutico e l’automobilistico, poiché può fare la differenza tra la vita e la morte. Parti di auto contraffatte, per esempio, possono provocare incidenti fatali se cedono sotto stress. I non-fungible tokens (NFT) possono essere utilizzati per portare la tracciabilità a un nuovo livello. Un NFT è come un numero di serie trasferibile. Con transazioni sicure, solo il proprietario di questo numero, con le proprie chiavi private, ha il potere di trasferirlo a un altro partecipante. L’uso degli NFT può prevenire le falsificazioni, anche da parte degli emittenti originali.

Per implementare la tracciabilità basata su NFT, hai bisogno solo di codici QR e di uno smartphone, rendendola principalmente una soluzione software. La tecnologia blockchain offre un modo per mantenere una tracciabilità trasparente dalla produzione al consumatore. Tuttavia, ci sono delle sfide. Innanzitutto, tutti devono concordare su un formato e su una blockchain. La blockchain trasporta payload binari, quindi se vuoi usarla per scopi di tracciabilità, il formato deve essere concordato. Questo diventa un problema complesso poiché molte industrie e aziende hanno i propri formati e standard unici.

Quello che le persone non si rendono necessariamente conto è quanto le supply chain tendano ad essere flessibili nel mondo reale. Per esempio, anche nell’aerospaziale, dove la tracciabilità è assolutamente eccellente, noterai che al punto A, il documento che segue una parte è un PDF. Nella fase successiva, è lo stesso PDF ma scannerizzato, e magari nella fase seguente, è la stessa scansione ma annotata e riscannerizzata. Fondamentalmente, si presume che un essere umano possa intervenire e decifrare i documenti. Tuttavia, se vuoi operare su una blockchain, non puoi avere un processo così lasco. Devi specificare completamente il formato binario per tutti i dati che vuoi esporre sulla blockchain; altrimenti, perdi l’angolo programmatico che ti consente di lavorare con strumenti informatici.

Unificare tutti gli standard è difficile, e devi scegliere una sola blockchain perché, affinché la tracciabilità funzioni, è necessario optare per una blockchain condivisa da tutti i partecipanti, almeno in un settore verticale e in una regione. Il problema è che, quando si tratta di scegliere una blockchain, sorgono enormi conflitti di interesse. Poiché una blockchain non può mai essere completamente separata dalla criptovaluta sottostante, se investi in una criptovaluta, diventi in conflitto nel senso che hai un interesse personale a fare in modo che l’azienda scelga la blockchain associata alla criptovaluta che possiedi.

Questi conflitti di interesse sono pervasivi e difficili da valutare poiché le blockchain sono tipicamente anonime. Se vuoi testare il terreno e ottenere feedback su quale blockchain scegliere, devi considerare i potenziali conflitti di interesse che possono sorgere tra il tuo staff. Le aziende che gestiscono grandi supply chain di solito hanno molte persone coinvolte, e questi problemi si amplificano.

Ora, consideriamo un esempio più avversariale. Immagina aziende farmaceutiche operanti in paesi molto poveri, come alcuni paesi africani, dove devono affrontare problemi significativi con farmaci contraffatti. Il problema è che, in questi paesi poveri, tutti gli intermediari sono in qualche misura corrotti. Intermediari corrotti possono prendere una scatola reale con prodotti reali, scambiare i farmaci autentici con farmaci contraffatti, e poi vendere la scatola sul mercato. Le persone che acquistano farmaci contraffatti potrebbero trovarsi in condizioni di vita o di morte e avere davvero bisogno del farmaco. Questo è un problema molto serio nei paesi poveri, e riprodurre l’imballaggio per i farmaci contraffatti è banale. Una soluzione potenziale è quella di utilizzare blockchain e token per una tracciabilità attiva, che ricorda il funzionamento dell’imposta sul valore aggiunto (IVA) in Europa. L’IVA è una tassa difficile da frodare perché crea uno schema di ingegneria sociale in cui le aziende sono intrecciate con i loro fornitori onesti.

L’idea è prendere lo stesso concetto e applicarlo alla blockchain. Per esempio, supponiamo che tu sia un’azienda farmaceutica che produce un farmaco. Vendi una confezione del farmaco a un intermediario o grossista a un prezzo più alto, per esempio $15 invece del prezzo reale di $10. Avviene il trasferimento di proprietà del token, e il grossista può riscattare $1 dal valore, portando il suo costo a $14. Il grossista poi vende la confezione di farmaci al distributore e, ancora, avviene un trasferimento di proprietà del token. Una volta che il distributore reclama il token, può riscattare $1 del valore appena acquistato, e così via, fino al consumatore finale.

Quando il consumatore finale riceve la confezione di farmaci, paga $11 e, scansionando il codice QR con uno smartphone, può riscattare $1, che gli ritorna. L’app fa due cose: per prima cosa, consente al consumatore finale di riavere il dollaro in eccesso, e soprattutto, controlla l’intera tracciabilità e la mostra al cliente. Al consumatore finale viene comunicato che ha appena recuperato il dollaro in eccesso, e il numero seriale viene ora dichiarato come consumato.

Alla fine, il consumatore finale non può trasferire il token a nessun altro, e la persona che ha appena ricevuto la scatola può vedere sulla propria app mobile che l’intera catena di tracciabilità è stata verificata, e che questa è una scatola autentica. L’idea è che, grazie a questi incentivi finanziari, diventa molto difficile imbrogliare, poiché distribuire i farmaci senza il numero di serie associato diventa impossibile. Alla fine della catena, le persone potrebbero essere povere, ma vogliono comunque accertarsi di poter verificare se il farmaco è legittimo, specialmente se si tratta di una condizione a rischio vitale. Questo è ciò che io definirei tracciabilità attiva, in cui si ha un non-fungible token (NFT) con un meccanismo finanziario sovrapposto che offre incentivi a tutti gli attori per compiere determinate azioni.

Nell’esempio dei farmaci, ogni singolo consumatore finale ha un incentivo finanziario a reclamare il numero di serie. Senza questo incentivo, le persone potrebbero non dichiarare la scatola come consumata, e farmaci contraffatti potrebbero essere reintrodotti nella rete. Marcando il numero di serie come consumato, non può essere riutilizzato da nessuno. Tuttavia, questo approccio richiede l’allineamento e la partecipazione di tutti i partecipanti, e tutti gli intermediari dovranno giocare a questo gioco finanziario. Pur essendo un caso d’uso valido, richiede una coordinazione significativa tra molte parti.

Un’altra potenziale applicazione è incentivare il riciclo attraverso sistemi di rimborso del deposito. Questi sistemi esistono da molto tempo e sono più o meno diffusi a seconda del paese. Il produttore originale è solitamente l’attore meglio posizionato nella rete per riutilizzare, riciclare o riparare l’attrezzatura immessa lungo la supply chain. Tuttavia, c’è attrito nell’implementare questi sistemi, e la sfida è ridurre ulteriormente tale attrito. Blockchain e criptovalute offrono un modo per abbassare il livello di attrito per i micropagamenti e potenzialmente ridurre l’infrastruttura necessaria per garantire che le operazioni non vengano manomesse.

Ad esempio, se restituissi 20 centesimi ogni volta che le persone riportano una bottiglia di vetro, gli avversari potrebbero potenzialmente sfruttare il sistema producendo bottiglie contraffatte e incassando il margine che ottengono vendendo le parti recuperate. Le blockchain possono fornire un modo semplice per mitigare alcune di queste malefatte, ma si tratta fondamentalmente di una soluzione di natura incrementale. Non sto affermando che i sistemi di rimborso del deposito siano nuovi; esistono da molto tempo. Si tratta semplicemente di abbassare un po’ l’attrito affinché possano emergere più casi d’uso.

Un altro caso d’uso interessante è la sicurezza, poiché le supply chain sono vulnerabili agli attacchi informatici. Le supply chain sono distribuite geograficamente per progettazione, il che significa che i sistemi IT e i dispositivi sono sparsi ovunque. Per progettazione, la superficie di attacco è ampia, e risulta difficile fare altrimenti. Una supply chain deve essere connessa a clienti, fornitori, partner e fornitori logistici terzi, creando una vasta superficie di attacco. Mentre l’integrazione dei sistemi, come l’EDI, può essere utile per ordinare dai fornitori e migliorare i tempi di risposta, un’integrazione più stretta comporta anche ulteriori problemi di sicurezza.

Un esempio di questa vulnerabilità è l’incidente della Colonial Pipeline, in cui un servizio apparentemente minore legato alla fatturazione è stato hackerato, impedendo l’operatività dell’intera pipeline per una settimana e mettendo a rischio infrastrutture critiche negli Stati Uniti. In che modo la blockchain può aiutare in questo contesto? Un approccio potrebbe essere quello di avere una piccola quantità di Bitcoin, per un valore di circa 100 dollari, in ogni singolo sistema e dispositivo, anche in quelli IoT. Pubblicizzando il fatto che tutti i sistemi e dispositivi possiedono questa riserva, si crea un incentivo per gli hacker a cercare di penetrare nei sistemi e rubare il denaro.

Tuttavia, questo non è furto; è considerato una ricompensa per gli hacker che violano il tuo sistema. Se un hacker riesce a penetrare, ad esempio, in un dispositivo IoT, può reclamare la somma di denaro al suo interno. Inoltre, se poi torna da te e ti spiega come ha fatto e come risolvere il problema, potresti pagare una seconda parte della ricompensa, per un valore di circa 300 dollari in Bitcoin. Creando un incentivo, finanzierai il lavoro degli hacker etici che testano la tua sicurezza. Se solo i malintenzionati hanno un incentivo ad attaccare i tuoi sistemi, scoprirai una violazione operata da un cattivo attore, il che può essere molto spiacevole, come accaduto con la Colonial Pipeline. Tuttavia, se offri un incentivo ad hacker onesti ed etici per entrare nel tuo sistema, è probabile che le persone che vi accederanno siano individui onesti che poi ti diranno come sistemare il tuo sistema per prevenire futuri problemi. La cosa interessante è che queste riserve sono pubbliche, quindi se le inserisci nella tua rete, puoi monitorare in modo trasparente se sei stato violato o meno. Puoi anche monitorare esternamente tutti i dispositivi, anche se il dispositivo IoT non è connesso a Internet. Se vedi che le monete, che erano all’interno di questo dispositivo, si muovono, allora significa che in qualche modo questo dispositivo è stato compromesso, ed è fondamentale esserne a conoscenza.

Ricorda che in quelle violazioni di alto profilo che diventano pubbliche, di solito accade che gli attori restano nei sistemi per mesi prima di decidere finalmente di reclamare il riscatto. Utilizzando questo sistema di sicurezza basato sulla blockchain, crei un meccanismo di allerta precoce. Anche se hacker non etici penetrano nel sistema, potrebbero semplicemente prendere il denaro e fuggire, senza dover affrontare il disordinato processo di riscatto.

Questo è un modo diverso di concepire la sicurezza e probabilmente non è il caso d’uso che avevi in mente per la blockchain nella tua supply chain. Ma come puoi vedere, i casi d’uso interessanti per la supply chain includono sempre una qualche forma di incentivo monetario, che è molto alla Bitcoin in termini di approccio alla blockchain nei casi d’uso della supply chain.

Ora, come ho già detto, le blockchain sono molto difficili da progettare rispetto a quasi ogni soluzione alternativa. Puoi aspettarti che sia almeno due ordini di grandezza più difficile sviluppare una soluzione blockchain. Quindi, ogni volta che pensi di poter risolvere un problema spendendo una settimana del tempo di un ingegnere software, moltiplica quel numero per 100, e questo ti darà un’idea dello sforzo necessario per fare lo stesso con la blockchain. Ci sono situazioni in cui ha senso; non è perché sia costoso che non possa essere redditizio, ma è fondamentalmente difficile, e devi tenerne conto. I costi sono anche molto più elevati per quanto riguarda le risorse computazionali. In genere, la blockchain è molto difficile da scalare, e rispetto a un setup non blockchain, finisci per spendere 100 volte più risorse computazionali per qualunque cosa tu voglia fare con la blockchain. In alcune situazioni potresti non farci caso, ma in molte altre, un aumento di 100 volte dei costi del tuo hardware di calcolo è significativo.

La domanda è: come proviamo alternative? In quasi ogni situazione in cui è coinvolta una blockchain, esiste un’alternativa non blockchain. Solitamente ciò si ottiene allentando i requisiti. In termini di valore aggiunto, se sei disposto a rinunciare alla proprietà di non ripudiabilità che ho descritto all’inizio di questa lezione, puoi nominare un consorzio di qualche tipo. Questo consorzio utilizzerà un database checkpoint, pubblicherà registri che potranno essere verificati da terze parti all’interno del consorzio o, potenzialmente, da aziende o enti esterni al consorzio. Uno dei punti critici sarà avere formati binari specificati in maniera molto chiara affinché le parti possano operare programmaticamente. Con ciò in atto, otterrai la maggior parte del valore che altrimenti otterresti da una blockchain.

Un ottimo esempio nella supply chain di questo è GS1 per i codici a barre. GS1 è un ente che assegna i codici a barre, e lo fa da decenni. Questa organizzazione è stata creata come entità separata, quindi all’epoca non era direttamente IBM a gestire i codici a barre. GS1 fornisce il valore aggiunto di una blockchain senza effettivamente utilizzare una blockchain. Tuttavia, questo approccio richiede un’autorità centrale o un consorzio di cui ci si può fidare. In molte industrie molto concentrate, come quella farmaceutica, stabilire un consorzio dove esiste già una quota di mercato significativa potrebbe non essere troppo difficile.

Per concludere, il consenso di Satoshi Nakamoto è una scoperta straordinaria. Nel 2008, se avessi chiesto agli esperti in sistemi distribuiti se fosse possibile risolvere il problema del consenso bizantino senza ricorrere a un’autorità centrale, la maggior parte di loro avrebbe detto di no, poiché non sembrava possibile. L’idea era così al di fuori del regno del possibile, che non la stavano nemmeno considerando. In questo senso, è stata una scoperta sorprendente. Come ho presentato con il mini Bitcoin, è un’idea molto semplice che ha usi oltre il denaro, con il denaro che rappresenta il caso d’uso principale.

Ciò che dobbiamo tenere a mente è che per ogni caso d’uso della blockchain, esiste tipicamente un’alternativa non blockchain che è di gran lunga più semplice da gestire. Dobbiamo davvero valutare se il sovraccarico extra associato a una blockchain valga tutte le complicazioni che comporterà. Come riflessione finale, non dimenticare mai che una blockchain è fondamentalmente intrecciata con la sua valuta sottostante, e questo genera la madre di tutti i conflitti di interesse.

In una delle mie precedenti lezioni sulla ricerca di mercato avversariale, ho espresso il mio punto di vista su come scegliere i fornitori aziendali e ho discusso le problematiche relative alle recensioni. Molti modi intuitivi per affrontare questi problemi vengono minati dai conflitti di interesse. Con blockchain e criptovalute, il problema è mille volte peggiore. Tutti hanno enormi incentivi se possiedono Bitcoin, Bitcoin Cash, eCash o altre criptovalute. Avranno un pregiudizio significativo a causa dei loro investimenti, e se la tua azienda prende una direzione favorevole a una specifica blockchain, potrebbe risultare favorevole anche per i loro investimenti.

Non ho una buona soluzione a questo problema, ma consiglio di essere consapevoli e preparati. La maggior parte delle informazioni trovate online sulle criptovalute è inaffidabile, poiché molte persone hanno conflitti di interesse nel promuovere la loro valuta preferita. Non fidarti di nessuno, tranne dei colleghi a cui affideresti la tua vita. Affidati al tuo giudizio o a quello dei colleghi che capiscono cosa sta succedendo. I conflitti di interesse con le blockchain portano a comportamenti inaspettati, specialmente nella supply chain, dove tipicamente sono presenti relazioni di lunga durata e un alto grado di fiducia.

Le organizzazioni che gestiscono grandi supply chain potrebbero non essere preparate al livello di sfiducia presente nel mondo delle criptovalute. Questo conclude la lezione. Diamo un’occhiata alle domande.

Domanda: Blockchain e Bitcoin non sono la stessa cosa; una è unica mentre l’altra è una tecnologia di base.

Sì, semantica e terminologia sono importanti. Sapevo, quando preparavo questa lezione, che ci sarebbero state persone a sottolineare che non sono esattamente la stessa cosa. Tuttavia, se vuoi esaminare una blockchain pura nel senso tecnico, allora un repository Git, come GitHub, è una blockchain. I repository Git esistono da circa 15 anni, e non hanno fatto impazzire il mondo. Non ci sono miliardi di euro e dollari che fluiscono dentro e fuori da questi repository Git.

Il punto è che la blockchain funziona solo in termini di valore aggiunto che crea. Ciò che differenzia Bitcoin da Git, nonostante entrambi siano blockchain, è che Bitcoin ha incentivi finanziari incorporati che sbloccano alcuni aspetti della tecnologia. Questo è il trucco. Se rimuovi tutti gli aspetti monetari e gli incentivi che sono stati progettati, allora hai qualcosa che è solamente una struttura dati tecnica, ma non ha alcun interesse. Sì, è una bella struttura dati – Git è una bella struttura dati – ma non ha fatto impazzire l’intero mercato, e sicuramente le persone non esclamerebbero: “Oh, questo repository Git vale miliardi.” C’è qualcosa di diverso. Lasciando da parte la pedanteria terminologica, credo che la ragione principale per cui molte aziende hanno optato per la terminologia blockchain sia stata quella di introdurre una distinzione nel discorso rispetto a quelle criptovalute che venivano viste come il completo selvaggio west.

Domanda: Blockchain è la tecnologia che consente il consenso decentralizzato ma a un costo – ritardo, scalabilità, ecc., e inquinamento.

Assolutamente. A proposito, posso anche affrontare il caso d’uso dell’inquinamento. Il fatto è che ogni volta che hai un processo di emissione di denaro, non importa come il denaro venga emesso – che si tratti della banca centrale per l’euro, della Fed per il dollaro o altro – se gli attori economici possono investire per trarne beneficio, investiranno fino al costo marginale. Quindi, se la banca centrale stampa 100 e io posso investire 90 per riottenere quei 100, lo farò.

Non importa come funzioni il processo di emissione di denaro, le persone spenderanno fino al costo marginale per ottenere l’utilità corrispondente. Si è scoperto che, poiché Bitcoin Core si è inflazionato in valore, le persone sono disposte a pagare molto in termini di elettricità per acquisire quei Bitcoin appena coniati. Tuttavia, il processo sta diminuendo esponenzialmente, il che significa che tra qualche decennio la quantità di Bitcoin appena coniati si ridurrà a quasi nulla, e quindi l’importo che le persone saranno disposte a pagare per la proof of work sarà quasi zero. Questo è un problema transitorio, e al momento si sta utilizzando principalmente capacità elettrica inutilizzata.

Concordo con la tua conclusione; ti offre un consenso decentralizzato dal punto di vista del consenso bizantino, e sì, ci sono enormi costi aggiuntivi associati. Assolutamente, questa è la conclusione corretta.

Domanda: Perché usarlo nell’industria della supply chain? Cosa risolve il paradigma decentralizzato? Quale problema porta?

Ho fornito vari casi d’uso nella mia lezione. Avere la decentralizzazione ti solleva dalla necessità di progettare un consorzio. Il problema è che se hai un’autorità centrale di cui ti fidi e questa autorità è onesta, allora perfetto – non ti serve una blockchain. Il trucco è: cosa fare quando non ce l’hai?

Anche aree che avevano autorità centrali, come ad esempio i bonifici per i pagamenti, sono sotto il controllo delle autorità centrali – ci sono gatekeeper che sono le banche e poi le banche centrali. Non siamo, direi, in una carenza di autorità centrali, ma comunque, nel 2021, liquidare un pagamento con i miei clienti esteri richiede ancora due settimane. Questo è il XXI secolo; posso inviare un’email, e viene ricevuta in pochi secondi da quei clienti, ma l’invio di un bonifico richiede settimane. Quindi ovviamente, ci sono alcuni problemi che a volte sono molto difficili da risolvere perché forse il problema non è che non ci siano autorità centrali, ma che ce ne siano troppe, o che si tratti di problemi complessi in cui non si riesce a mettere d’accordo la gente per trovare una soluzione.

Ho descritto alcuni casi d’uso, per esempio, la tracciabilità attiva, dove operi in un paese povero in cui tutti gli intermediari sono corrotti. Questo è un altro problema in cui non ci si può fidare di nessuno. Quando la corruzione è endemica, questi problemi sono molto difficili da affrontare. Questa è una situazione in cui la blockchain decentralizzata può offrirti un modo per ingegnerizzare l’onestà dei partecipanti. Ecco il trucco: non ci si aspetta che i partecipanti siano onesti; sono progettati per rimanere onesti mentre gestiscono la supply chain. Se tutti sono già molto onesti e le autorità centrali sono applicate, il valore aggiunto è minimo.

Domanda: Come gestisci l’esistenza degli ASIC (Application-Specific Integrated Circuits), hardware specializzato nel mining e nelle farm, per garantire che nessuno possa facilmente ottenere il 51% della potenza delle reti?

Storicamente, gli ASIC sono stati una forza positiva per la sicurezza della rete Bitcoin Core. Perché? Perché c’è un altro problema nel panorama moderno: i botnet. I botnet sono vaste flotte di computer compromessi controllati da organizzazioni criminali che letteralmente prendono il controllo di milioni di dispositivi quotidiani come computer, stampanti e telecamere di sicurezza. Queste organizzazioni non vogliono impedirti di usare il tuo dispositivo, poiché ciò comporterebbe riparazioni e la rimozione del malware.

In termini di sicurezza, lo scenario attuale è che le organizzazioni criminali hanno a disposizione letteralmente decine di milioni di computer gratuitamente. Queste organizzazioni che gestiscono botnet, se osservi gli aggiornamenti di sicurezza di Microsoft, vedrai che, un paio di volte l’anno, Microsoft ha spazzato via botnet davvero massicci. Avrebbero comunicato, per esempio, “Abbiamo rilasciato questo aggiornamento di Windows e, a proposito, abbiamo appena eliminato, spazzato via questa botnet da 50 milioni di macchine.” È impressionante. Quindi, gli ASIC significano che non ha senso giocare a questo gioco con hardware comune, come quello dei tuoi computer quotidiani. Di conseguenza, i criminali che gestiscono botnet non possono utilizzare quei botnet per fare mining di criptovalute, eliminando così un angolo per monetizzare tali botnet. Costringe i miner a essere impegnati con la valuta.

Vedi, gli ASIC non sono un problema; sono, al contrario, il tipo di soluzione che garantisce che questa potenza di elaborazione extra non crei disastri o non sfrutti la potenza che risulta dai botnet. I botnet sono già un problema enorme per tutti, e non vogliamo ulteriormente potenziarli.

Domanda: Quali sono le tue opinioni sul Telegram Open Network che non ha potuto vedere la luce a causa dei tribunali statunitensi? Quali sono le tue opinioni in generale sulle criptovalute emesse dai messenger? Porta qualcosa di nuovo?

Beh, credo che la situazione sia molto prevedibile per Telegram e lo stesso vale per Facebook, e per qualsiasi azienda che voglia operare come società pubblica. Esistono regolamenti generali che affermano che se sei un’azienda, ci sono requisiti KYC (Know Your Customer), e non entrerò troppo nei dettagli. Fondamentalmente, se sei una grande azienda, puoi aspettarti che in molte giurisdizioni esistano requisiti KYC. Non sono qui per discutere se le normative siano adeguate o meno; sto solo dicendo che le normative KYC sono diffuse in molti paesi.

Se torni a ciò che rende una blockchain una blockchain, come ho descritto nella lista dei requisiti, il punto numero due è che i partecipanti sono anonimi. Ecco dunque i requisiti KYC. Se vuoi gestire una blockchain, devi essere disposto a preservare una sorta di pseudo-anonimato di chiunque partecipi a questa rete, il che significa che, in termini di requisiti KYC, sei completamente fuori gioco.

Non ero molto sicuro di cosa stessero pensando quelle aziende, ma non riesco a immaginare un’azienda che voglia essere sia pubblica sia rispondere ad autorità come la SEC negli Stati Uniti o l’AMF in Francia, mentre possa impegnarsi in uno schema che ovviamente va completamente contro i regolamenti KYC, così diffusi per le grandi aziende. La mia opinione è che, fondamentalmente, probabilmente stessero sondando il terreno per vedere se i regolatori potessero allentare le normative solo per loro, solo perché erano grandi. Potrebbe non essere andata come speravano, e per questo si stanno tirando indietro. Fondamentalmente, a parte questo, credo che, per esempio, Telegram o Facebook, se accettassero di limitarsi a promuovere una criptovaluta senza gestirla, potrebbero effettivamente dare un enorme impulso a quella criptovaluta. Tuttavia, il problema è che, limitandosi solo alla promozione e non alla gestione, avrebbero poco da guadagnare a meno che non ingegnerizzino un conflitto di interessi che li faccia beneficiare della crescita della valuta. A proposito, Elon Musk, ti sto guardando quando inizi a twittare su Bitcoin e sul fatto che la tua azienda ha una posizione in merito. Questo è letteralmente il gioco che si può fare: prima acquisisci una partecipazione in una criptovaluta e poi pompi letteralmente quella criptovaluta semplicemente facendo dichiarazioni molto visibili al riguardo. Lasci che la valutazione salga e poi, una volta che è più alta, la vendi. A proposito, questo processo si chiama pump and dump. Probabilmente Telegram e Facebook hanno capito che l’unico modo per trarre profitto dal semplice fatto di promuovere una valuta senza gestirla era attraverso il pump and dump, e non volevano che la loro reputazione venisse danneggiata da questo tipo di marachelle.

Domanda: Sette anni fa, ho visto molte startup portare la tecnologia blockchain in campi legati alla supply chain. Nessuna di esse ha avuto successo, almeno su larga scala. Ne conosci qualcuna che abbia avuto successo e dimostrato di funzionare su larga scala?

Buona domanda. Voglio dire, prima di tutto, non credo che qualcuno, su questo pianeta, possieda una blockchain che sia dimostrabilmente scalabile e funzioni davvero su larga scala. Se osserviamo l’esperimento Bitcoin Core, non va per il verso giusto. La rete è completamente satura; lo è da quattro anni ormai. Questo è davvero l’opposto della scalabilità. Se guardi Bitcoin Cash, è un’altra blockchain. Hanno fatto qualche progresso, ma non hanno mai davvero avuto il tempo; ci sono state dissidenze interne, e quindi non hanno mai completato tutti gli aspetti ingegneristici necessari per farla funzionare. Esiste un altro fork, come ho già accennato, di recente creato, chiamato eCash, che è fondamentalmente un fork di Bitcoin Cash, in cui stanno nuovamente cercando di fare tutte quelle cose che non sono state implementate nel client originale di Satoshi, dato che la maggior parte dei problemi di scalabilità risale proprio al client originale di Satoshi. C’è una speranza che possano raggiungere una scalabilità massiccia, ma ancora, questo è più una prospettiva teorica. Non è dimostrato nel senso che, al giorno d’oggi, esista qualcosa che funzioni a iperscala, anche se abbiamo motivo di credere che, in una certa misura, sia possibile. Ho pubblicato a riguardo, a proposito, se vuoi dare un’occhiata alla mia pubblicazione sui blocchi da dimensione terabyte per Bitcoin.

Adesso, non c’è nessuno che sia riuscito a portare quelle cose su larga scala. È molto difficile. Scalare il livello base è la prima sfida, e poi ovviamente, le startup che vogliono farlo nella supply chain desiderano fare qualcosa di ancora più avanzato. Devono disporre di un livello base scalabile, e poi vogliono fare qualcosa che coinvolga anche una supply chain su larga scala. Credo che nessuna di esse abbia avuto successo perché, come ho descritto, sì, ci sono casi d’uso per la supply chain, e sì, c’è spazio per un valore aggiunto, ma prima di tutto bisogna risolvere quei problemi estremamente difficili di scalabilità e latenza. Potrebbe non essere andata come speravano, e puoi notare che i documenti che ho citato non sono così vecchi. Voglio dire, i documenti su Avalanche hanno letteralmente solo pochi anni. Ci sono stati dei progressi che sono ancora abbastanza recenti, e ci vorrà ancora molto tempo. Per scalare, occorrono progressi a livello di algoritmi teorici, cosa estremamente difficile da realizzare.

Gli algoritmi che ho descritto, come Avalanche, sono incredibilmente difficili da implementare correttamente. Ci sono molti dettagli che possono essere sbagliati, e in termini di blockchain, se sbagli anche solo qualcosa, significherà che verrai violato, attaccato, e perderai denaro. La gravità di avere bug e problemi quando si opera nel mondo della blockchain è davvero elevata. Non è come il software aziendale comune che, se va in crash, puoi semplicemente riavviarlo, correggere manualmente i dati interessati e riprendere da lì. Con le blockchain, una volta che si verifica una massiccia corruzione, il danno potrebbe essere permanente, e questo è un problema molto difficile da affrontare.

Credo che molte delle startup che sono entrate in questo settore fossero assolutamente impreparate in termini di mentalità ingegneristica necessaria per affrontare le sfide del mondo blockchain. Una buona ingegneria non basta; serve un’ingegneria veramente eccezionale per avere successo.

Questo conclude la sezione Q&A di questa lezione. La prossima lezione tratterà dell’ottimizzazione matematica per la supply chain e si terrà mercoledì, 25 agosto. Mi prenderò qualche giorno di vacanza. A proposito, l’ottimizzazione matematica, contrariamente alla blockchain, viene utilizzata quotidianamente in molte supply chain. Le applicazioni sono enormi e i casi d’uso sono molto concreti. Non stiamo parlando di casi d’uso di nicchia; le applicazioni sono massicce.

L’ottimizzazione matematica è strettamente correlata all’apprendimento statistico e al prendere le migliori supply chain decisions. A presto.