Il mio business model ha bisogno di una blockchain?

11 min readJun 3, 2019

Con questo articolo voglio fornire delle linee guida per aiutarti a decidere se il tuo progetto ha realmente bisogno di una blockchain.

Negli ultimi mesi ho visto circolare numerosi modelli decisionali a supporto di tale decisione, tuttavia nessuno di questi mi ha soddisfatto pienamente, alcuni pongono le domande sbagliate, altri semplificano eccessivamente il flusso decisionale. Ho quindi deciso di pubblicare la mia versione.

Cominciamo col formulare la domanda giusta: molti articoli mescolano la necessità di integrare una blockchain esistente con la possibilità di crearne una nuova, e questo crea confusione. La necessità di impiegare una blockchain nel proprio business model può essere declinata in modi differenti, si può infatti avere, in ordine di complessità:

l’uso di una tecnologia blockchain ed una community e network esistenti (public blockchain);
l’impiego di una piattaforma blockchain off-the-shelf in una rete privata (consortium / private blockchain);
La realizzazione di una nuova blockchain e relativi community e network, o lo sviluppo di un second layer su una public blockchain.

L’integrazione con una blockchain e relativo network si ha quando per il nostro business model è sufficiente poter partecipare all’economia degli asset messi a disposizione da una blockchain (uso di cryptocurrency o token esistenti), oppure quando è possibile definire degli asset su di essa che rispondano ai nostri requisiti (creazione di una token economy anche via Smart Contract).

L’impiego di una blockchain in un network privato si osserva quando non ci sono sufficienti incentivi economici per costruire un equivalente pubblico ma ce ne sono abbastanza per coinvolgere entità indipendenti.

Infine la realizzazione di una nuova blockchain pubblica comporta invece delle complessità enormi, che di sicuro non possono essere affrontate con un semplice modello decisionale.

La domanda specifica a cui risponde questo articolo quindi è: il mio business model riesce a beneficiare di una blockchain, e quale tipo di blockchain e tecnologie correlate è più appropriata?

Alcune domande ingannevoli

Prima di esaminare la mia proposta di diagramma decisionale, riporto una lista di domande usate in diagrammi simili, a mio avviso errate o ingannevoli.

Do you need a (shared) database? Questa domanda è ingannevole, in quanto la necessità di un database è un requisito non funzionale, che dovrebbe essere motivato dai requisiti funzionali del nostro progetto. Esistono molte applicazioni che richiedono un database ma che sono pensate per essere usate da un singolo utente, quindi la necessità di un database non è discriminante. La domanda più opportuna è se abbiamo bisogno di condividere uno stato consistente con più entità distinte.

Do you need data to be updated or deleted? Altra domanda legata ad un uso improprio delle tecnologie blockchain. Una blockchain può essere vista come un database append-only, in cui è possibile aggiornare e cancellare informazioni semplicemente segnalando un update per un dato o marcando tale dato come cancellato. Ovviamente tutto lo storico degli aggiornamenti di un oggetto rimarrà sempre visibile a tutti. Se il motivo di avere supporto per update e cancellazioni è legato alla sistemazione di problemi con dati sensibili, troverete maggiori delucidazioni nelle considerazioni associate alla prossima domanda.

Sensitive data will/will not be written to the data store? Questa domanda vincola l’utilizzo di una blockchain al fatto di scrivere o meno dati sensibili su un registro pubblico e inalterabile, ponendo un falso problema: è infatti possibile e fortemente consigliabile di evitare di scrivere i dati originali quando possibile, preferendo piuttosto di inserire i digest dei dati su una blockchain, detenendo i dati originali off-chain, in modo da ottimizzare i costi di scrittura e mantenere la riservatezza del dato, potendo comunque dimostrare l’esistenza di determinate informazioni a partire da un dato istante temporale, se necessario esponendo il dato originale solo alle parti interessate. Utilizzando poi tecniche di Zero Knowledge Proof è addirittura possibile dimostrare dei fatti sui dati senza nemmeno dover rivelare gli stessi.

Are you working with digital assets (versus physical ones)? Sebbene lavorare con asset puramente digitali sia sicuramente un vantaggio nella modellazione di un business model basato su blockchain, e sia una garanzia ulteriore della sua decentrabilità, l’utilizzo di asset fisici non è necessariamente una limitazione. Una discriminante più interessante è se questi asset fisici sono mono proprietari (ossia tutti appartenenti ad un’unica entità) nel caso si tratti di beni immobili, o se sono open hardware (ossia liberamente costruibili e riproducibili) nel caso in cui siano beni mobili.

Do you need high performance transactions (and so consider alternative approaches)? Ritengo che questa domanda, e la conclusione a cui viene associata siano errate. Esistono già dei second layer su alcune blockchain come Bitcoin, che risolvono specifici problemi di scalabilità transazionale, inoltre è già possibile realizzare delle sidechain che aggirano le limitazioni attuali di molte blockchain. Infine, rilassando alcuni requisiti di decentralizzazione del consenso, sono disponibili delle blockchain con alti livelli di scalabilità (ad esempio EOS).

Il modello decisionale

Come si legge

Partendo da Start si risponde ai vari quesiti in modo affermativo (freccia verde) o negativo (freccia rossa), e si segue il flusso fino ad arrivare ad uno degli step finali (rettangoli arrotondati con bordo spesso). Le frecce nere tratteggiate conducono a possibili sottodomande nel caso si vogliano considerare ulteriori elementi. Alcune step finali sono contrassegnate da uno o più box PoW (Proof of Work), PoS (Proof of Stake), PoA (Proof of Authority), che indicano, per le principali tipologie di consenso, quali sono più appropriate per soddisfare uno specifico sotto caso. Alcuni step finali hanno un bordo arancione, per distinguere gli scenari di utilizzo di una blockchain esistente dagli scenari di implementazione di una soluzione custom.

I quesiti

Segue una breve guida interpretativa per i quesiti impiegati nel modello decisionale.

Your business model can be / has already been implemented without Blockchain. La prima cosa da considerare è se il nostro business model sia stato già implementato in passato, e quindi se può essere realizzato in maniera tradizionale, oppure se è un business model che verte sugli aspetti della decentralizzazione, in tal caso potrebbe avere senso solo se realizzato con un approccio decentralizzato. Ribadisco che la value proposition principale nell’utilizzo della blockchain consiste nella riduzione dei costi e dei tempi legati alla fiducia fra le parti.

The key activities enabling the value propositions can be decentralised. Se le value propositions del vostro business model vertono su delle key activities che non sono decentralizzabili (ad esempio richiedono interazioni col mondo fisico o poggiano su sistemi centralizzati), va riconsiderata opportunamente la possibilità di impiegare una blockchain. Ricollegandosi alle considerazioni sulla questione “are we working with digital vs physical assets”, avere a che fare con degli oggetti fisici (come dei beni immobili) o degli oggetti controllati da entità centralizzate (come conti correnti fiat, oppure company securities) non impedisce di implementare degli scenari di decentralizzazione, ma richiede di individuare dei compromessi che riducono l’efficacia della decentralizzazione, richiedono inoltre l’individuazione di un framework legale a supporto.

Tokenization of your business model has real advantages in terms of adoption and market size. Chiedetevi quali sono i vantaggi reali in termini di adozione e dimensione potenziale di mercato nei confronti di un approccio decentralizzato e se la value proposition è realmente aumentata dall’introduzione di un approccio trustless. Alcuni tra i principali driver di tale approccio sono l’abbattimento dei costi di mediazione, l’accessibilità internazionale (borderless), la velocità di esecuzione delle operazioni rispetto all’equivalente intermediato umano, la possibilità di automatizzare molte operazioni, la disponibilità di servizio 24/7/365.

You need to store a shared consistent state among different entities. Ammesso che tutte le premesse siano rispettate, è importante avere delle asserzioni la cui esecuzione, verifica e condivisione inalterabili abbiano valore per le parti interessate dal business model.

The independent entities are trusted. Nel caso in cui le entità indipendenti che partecipano al business model si fidano fra di loro al livello da poter interagire senza la necessità di un intermediatore, la value proposition della blockchain si affievolisce. In caso contrario invece si avvera un’ulteriore premessa per l’impiego di tale paradigma.

It is possible to find an economic incentive to let all untrusted entities collaborate. Un importante obiettivo da raggiungere è quello dell’individuazione di un incentivo economico che renda più conveniente per tutte le entità che partecipano al business di operare secondo le regole prestabilite. L’incapacità di individuare tale incentivo porta a ridimensionare la tipologia di tecnologia decentralizzata utilizzabile, riducendola ad un semplice strumento di convergenza delle informazioni.

The independent entities can rely on a trusted 3rd party. Nel caso in cui entità indipendenti possano trovare economicamente conveniente, nell’implementazione di uno scenario di business, l’impiego di un trusted 3rd party, verrebbe meno la motivazione per la decentralizzazione. Nello scenario di utilizzo di un trustless 3rd party convergono ad esempio tutte le applicazioni di asset tokenization, in cui si ricorre and un arbitro decentralizzato principalmente per abbattere i costi di gestione ed aumentare la velocità delle operazioni.

The economic incentive is valid for any anonymous participant. Questo aspetto è molto importante, infatti l’incentivo economico è più robusto se può essere applicato ad identità anonime, in quanto la partecipazione al network è aperta a qualunque soggetto senza limiti giuridici. In alcuni scenari tuttavia risulta essere indispensabile identificare gli attori, ad esempio in caso di gestione di asset che hanno una controparte legale legacy, oppure in scenari che coinvolgono fiat currency, al fine di essere compliant con le regole internazionali di anti money laundering. In generale gli scenari che prevedono l’autenticazione delle entità partecipanti sono legati all’interazione con la finanza tradizionale o le giurisdizioni nazionali.

It is possible to find an indirect economic incentive to let all untrusted entities collaborate. Questo è il caso delle consortium blockchain, ossia di entità potenzialmente in competizione, che sono tenute, per limitazioni o imposizioni normative o strategiche, a condividere delle risorse. In questo caso il loro incentivo a collaborare è forzato dalla natura della loro attività, attraverso un incentivo economico indiretto. Nel caso invece in cui le varie entità appartengono alla stessa organizzazione abbiamo un caso di utilizzo per le private blockchain. Nel caso in cui non si riesca ad individuare nemmeno tale incentivo allora siamo di nuovo nello scenario in cui non è utile o efficace l’utilizzo della blockchain.

You need legal verifiability. Alcune applicazioni blockchain necessitano supporto legale. Si possono individuare due tipologie principali di applicazioni legali:

public registry: ossia quando una o più parti vogliono provare pubblicamente di aver creato o detenuto un certo contenuto digitale o digitalizzabile (proprietà intellettuale, creatività) a partire da una certa data. In tal caso necessitano di un registro 3e parti almeno leggibile e auditabile pubblicamente (public permissionless/permissioned blockchain).
peers agreement: ossia quando più parti concordano un set condiviso di condizioni, in tal caso ogni parte appone la propria firma sul agreement. In questo scenario l’utilizzo di un registro pubblico risulta utile se l’esecuzione dell’agreement può essere automatizzata. Risulta inoltre rilevante l’identificazione pubblica di tutte le parti, a questo scopo si possono utilizzare certificati digitali legalmente riconosciuti.

You need control over governance and protocol evolution. Alcuni business model possono richiedere che la blockchain su cui sono costruiti possa evolvere con loro. Si tratta di solito di blockchain dedicate a soddisfare degli scenari specifici, ed è richiesto che la strategia di evoluzione del protocollo blockchain sia controllabile attraverso dei processi espliciti di governance del network che sostiene la blockchain, governance che può essere esplicita se basata sull’esercizio del voto pesato (Proof of Stake) o implicita se basata sull’appoggio di uno o altro fork (Proof of Work).

You have strict performance requirements. Alcuni business model sono soggetti a dei vincoli di performance (scalability, costi transazionali, finality time) che al momento non sono soddisfatti da alcuna blockchain pubblica, sebbene ci sia molto fermento nelle varie community per migliorare questi aspetti. Per poter sopperire a tale mancanza si può al momento ricorrere all’uso di side chain o di second layer. Una sidechain ed un second layer sono due approcci architetturalmente diversi per ottenere lo stesso risultato: aumentare la scalabilità di una blockchain, continuando tuttavia ad utilizzare il livello di sicurezza offerto dal network originale.

You have strict privacy requirements. In alcuni casi è necessario poter condividere degli stati consistenti fra business partner, garantendo tuttavia la massima riservatezza in termini di dati privati e di business. Ci sono diversi approcci che possono essere utilizzati:

digest tracking: si depositano su blockchain solo i digest delle informazioni che sono invece persistite off-chain dalle parti interessate;
encryption: si depositano su blockchain dati criptati che possono essere letti solo da attori interessati;
zero knowledge proof: si depositano su blockchain delle proof che consentono a chiunque di verificare che determinate condizioni sui dati siano rispettate senza dover rivelare tali dati.

You have arbitrary contract processing needs. Molti interazioni tra parti richiedono delle logiche di mediazione che possono essere implementate solo con un’espressività programmatica arbitrariamente complessa. Tale livello di programmabilità è garantito da Smart Contract che sono computationally universal o Turing complete, ossia in grado di processare operazioni senza limiti di complessità.

Tipologie di output

Public Permissionless. Sono le blockchain pubbliche che conosciamo tutti, come Bitcoin e Ethereum. Sono leggibili ed utilizzabili da chiunque, in forma anonima, senza autorizzazioni preventive.

Public Permissioned. Sono alcune blockchain pubbliche con uso ristretto, come Ripple. Possono essere lette da chiunque ma solo gli autorizzati possono utilizzarle e beneficiare dei suoi incentivi economici.

Consortium Blockchain. Sono blockchain leggibili e scrivibili solo da entità autorizzate, giuridicamente distinte, di solito sono utilizzate per scopi specifici. Possono creare ecosistemi economici deboli.

Private Blockchain. Sono registri distribuiti gestiti da un’unica entità giuridica, di solito grandi organizzazioni territorialmente frammentate, tali da richiedere dei meccanismi di trust. Non costituiscono le premesse per creare ecosistemi economici, ma si possono utilizzare per l’auditing e della tracciatura di processi interni complessi. Molti considerano le blockchain private (o intra-firm) del tutto inutili, personalmente ritengo che le dinamiche sociali e politiche che si sviluppano all’interno di organizzazioni costituite da decine di migliaia di individui, strutturati per gerarchie organizzate su decine di livelli, distribuite su diversi continenti, possa beneficiare, almeno nei processi decisionali, autorizzativi e di auditing di una tecnologia blockchain. È comunque necessaria una premessa per l’uso corretto di blockchain private: affinché possano risultare efficaci, la loro gestione, all’interno della stessa organizzazione, deve essere in mano a dipartimenti indipendenti, il controllo dei nodi del network privato non può essere in mano ad un singolo gruppo.

Sidechain / 2nd Layer. Sono due approcci complementari per aggirare le limitazioni inserite in un protocollo blockchain per controllare i rischi di sicurezza e le performance di funzionamento.

sidechains: sono blockchain indipendenti in grado di implementare una propria logica di funzionamento, basata su un protocollo custom, che però sono in grado di interagire con una chain di coordinamento detta anche main chain. Una sidechain è in grado di scambiare token con la main chain di coordinamento in maniera bidirezionale attraverso una serie di sistemi di lock mutuali. In questo modo è possibile trasferire del valore da una main chain ad una sidechain e viceversa, continuando ad usufruire dei livelli di sicurezza garantiti dalla main chain.
2nd layer: sono dei layer costruiti su una blockchain per estenderne il funzionamento, che tipicamente prevede una fase di setup on chain ed una fase operativa off-chain, attraverso l’interazione P2P al di fuori del network della blockchain di coordinamento.

Zero Knowledge. È una disciplina della crittografia che mette a disposizione delle funzioni per dimostrare dei fatti su informazioni arbitrarie senza rivelare il contenuto delle stesse.

Smart Contract Enabled. Sono blockchain che supportano Smart Contract con livello di espressività Turing Complete. Tali contratti sono basati su linguaggi di programmazione in grado di processare operazioni senza limiti virtuali di complessità. Alcune blockchain, come Bitcoin, limitano l’espressività dei loro linguaggi di validazione delle transazioni, al fine di ridurre i rischi di sicurezza nel loro utilizzo e tenere sotto controllo l’impiego delle risorse computazionali e di storage del network. Queste limitazioni introducono stabilità a discapito dei casi d’uso.

Grazie!

Se sei arrivato fin qui probabilmente hai apprezzato il mio articolo. Perchè non mi lasci un feedback, come un commento o degli applausi? Se sei nuovo su Medium probabilmente non saprai che un click sul bottone applausi vale solo 1 / 50 del voto massimo.