Blockchain, cosa sei? Definizione di una parola d'ordine del settore

Mentre ci avviciniamo al 2016, sembrano esserci infinite discussioni su "blockchain". È un termine che viene citato sempre più frequentemente anche nel giornalismo mainstream, mentre nel solo spazio FinTech ci sono una serie di potenziali fornitori e potenziali utenti che affermano che "blockchain" rivoluzionerà un numero qualsiasi di applicazioni.

Questo uso ormai comune suggerisce che si tratti di qualcosa di definito con precisione e ben compreso, ma sembra essere più una questione di mantra che di comprensione.

Le camere di risonanza di Internet riverberano su molte opinioni, ma i tentativi di trovare un significato preciso sembrano trovare una sconfortante mancanza di consenso. Per essere qualcosa di più di un'iperbole di marketing, abbiamo davvero bisogno delle risposte ad alcune domande.

Cos'è? T ? Cosa potrebbe essere? Può essere qualcosa che ci permetterà di costruire sistemi nuovi e duraturi? In breve, qual è l'essenza della blockchain?

Il white paper di Satoshi

Quasi ogni discussione sulle blockchain inizia conLibro bianco di Satoshi, ma è proprio questa fondazione che ci avvia su un percorso di confusione. Né i termini "blockchain" né "block chain" compaiono lì; ci sono 67 usi di "block" e 27 di "chain", ma zero di "block chain" o "blockchain". A parte questo, vediamo dove ci porta questa origine.

Il white paper è breve, è lungo solo nove pagine. La prima menzione di "blocco" e "catena" inizia in fondo alla pagina 2, sezione 3, dove si parla di un server di timestamp di base. Prima di questo, il white paper descrive una serie di obiettivi di progettazione associati alla progettazione Bitcoin , come la capacità di consentire a due parti di effettuare transazioni senza dover fidarsi di una terza parte.

La dichiarazione degli obiettivi di progettazione è fondamentalmente importante. Stabilisce la scena per un'implementazione che soddisfi quegli obiettivi in cui le caratteristiche sono stratificate l'una sull'altra, ma è informativo osservare cosa fa ogni nuovo strato.

Nella nostra ricerca sulla natura di una blockchain dobbiamo prestare attenzione a ciò che costituisce i suoi attributi, piuttosto che alle caratteristiche di questa prima implementazione.

Transazioni

La sezione 1 del white paper è un'introduzione ed è con la sezione 2 che vediamo qualcosa di veramente sostanziale. La sezione 2 imposta la scena per una moneta digitale, ma è descritta come una catena di transazioni in cui la "moneta" viene assegnata a nuovi proprietari. La moneta è in realtà una metafora per una cronologia delle transazioni di transazioni collegate.

È interessante notare che la sezione 2 descrive anche come un sistema centralizzato in realtà T abbia bisogno di fare questo.

Blocchi e catene

Con la sezione 3 vediamo l'essenza del design pattern che potrebbe descrivere al meglio la base di una blockchain. È dato come qualcosa che è costruito da una serie di blocchi incrementali di dati, ognuno dei quali può essere identificato da un hash crittografico sul suo contenuto. Inoltre, ogni blocco incorpora l'hash crittografico del suo blocco predecessore per garantire la costruzione di una catena.

Gli hash dei blocchi vengono pubblicati come una forma di prova ampiamente testimoniata che dimostra l'esistenza sia dei dati del blocco che dell'hash predecessore. Cambiare il predecessore o gli altri dati all'interno del blocco comporterebbe una firma hash diversa per il blocco che non corrisponderebbe alla visione ampiamente testimoniata.

Queste caratteristiche sono tutte fondamentali e senza di esse non possiamo costruire nulla di interessante. Ciò che è ugualmente interessante, però, è ciò che non è dichiarato necessario a questo punto. Non ci sono riferimenti a monete, a reti peer-to-peer, al mining, ETC. Invece, il suggerimento è che pubblicare hash in qualsiasi forma ampiamente diffusa sarebbe sufficiente, con i due esempi forniti come pubblicazione su un giornale o pubblicazione tramite Usenet.

Sebbene osserviamo alcune caratteristiche esplicite, queste portano ad alcune caratteristiche implicite:

La pubblicazione degli hash non ha senso a meno che quegli stessi hash non possano essere ricalcolati in modo indipendente da un osservatore esterno a cui vengono forniti solo i dati dei blocchi nella catena. È questa caratteristica che consente agli osservatori di non dover fidarsi dell'originatore della catena di blocchi; al contrario, sono in grado di confrontare gli hash storici da soli.

Il ricalcolo degli hash richiede che l'algoritmo con cui vengono prodotti i blocchi sia deterministico e ben specificato. Senza questi, il nostro osservatore esterno non può ricalcolare gli hash.

Abilitazione delle operazioni peer-to-peer

La sezione successiva, la 4, del white paper parla di proof-of-work. La prima riga è interessante: "Per implementare un server timestamp distribuito su base peer-to-peer (P2P), dovremo usare un sistema proof-of-work simile a Hashcash di Adam Back". Il proof-of-work non è necessario per costruire una blockchain, ma solo per abilitare l'implementazione peer-to-peer del server timestamp.

Successive progettazioni Criptovaluta hanno dimostrato che potenzialmente ci sono altri approcci che possono essere adottati anche in questo caso (ad esempio: forme di proof-of-stake o ibridi di entrambi), ma se siamo soddisfatti di un approccio client-server, nessuno di questi è effettivamente necessario.

Ciò non significa che la proof-of-work non possa avere altri utilizzi in una progettazione blockchain, ma nessuno di essi sembra fondamentale per la nostra ricerca.

Rete e oltre

La sezione 5 descrive le caratteristiche di implementazione della rete Bitcoin . Niente qui estende esplicitamente il concetto di cosa sia una blockchain o cosa potrebbe richiedere. Infatti, né le sezioni 6, 7, 8, 9, 10, 11 o 12 (la sezione finale) proseguono offrendo esplicitamente nuove idee su cosa potrebbe essere una blockchain.

Risposte alle nostre domande

Se il white paper di Satoshi è l'origine del design della blockchain, ci ritroviamo con una definizione piuttosto sottile, ma forse è l'aspetto più illuminante. È molto esplicito riguardo a particolari scelte di design e al loro scopo, il che tende a portare alla consapevolezza che molte delle affermazioni sulle "blockchain" potrebbero in realtà essere una questione di implementazione piuttosto che di architettura.

Allora poniamoci qualche domanda specifica!

Una blockchain deve avere monete?

Nel white paper c'è un'interessante discussione sulla necessità di fornire incentivi a coloro che forniscono sicurezza alla rete P2P per rimanere onesti e come mezzo per introdurre "monete" nel sistema, ma la discussione è chiaramente nel contesto della rete P2P. Il concetto di monete in sé è notato come non necessario con una "zecca" affidabile.

Una zecca affidabile non è qualcosa di desiderabile in una Criptovaluta, ma non sembra esserci alcun requisito per le monete se desideriamo costruire una catena di blocchi collegati crittograficamente. C'è una domanda interessante da porre sulla fiducia, ma ci torneremo più avanti.

Una blockchain deve implementare contratti intelligenti?

Dal punto di vista del white paper questo sembra improbabile. La parola "contratto" non compare da nessuna parte.

Una blockchain potrebbe abilitare contratti intelligenti? Sì, certo che potrebbe, ma potrebbe abilitare anche molte altre cose.

Una blockchain deve essere programmabile?

Anche in questo caso la risposta sembra essere no. Nel white paper non compaiono né le parole "programma" né "script".

Una blockchain ha il requisito di essere interpretabile da ONE o più osservatori indipendenti, quindi è chiaramente costruita da ONE o più strutture dati ben definite. La struttura dati del blocco deve contenere un hash del blocco precedente e l'hash crittografico del blocco deve essere eseguito in un modo molto specifico, ma nessuno di questi richiede che la struttura dati porti alcuna nozione di codice eseguibile.

Una blockchain può contenere una qualche forma di codice di programma? Questa è una domanda di implementazione e la risposta è sì. Bitcoin include un linguaggio di scripting limitato e altri sistemi, come Ethereum, hanno successivamente tentato di supportare modelli di programmazione più elaborati.

La scelta di supportare tali concetti sembra più una questione di convenienza o di obiettivi di progettazione più ambiziosi, ma pare che una blockchain non debba essere "programmabile" più di qualsiasi altra struttura di dati di tipo elenco concatenato.

Una blockchain è un database?

Ancora una volta la risposta sembra essere no. Come prima, la parola "database" non compare nel white paper.

In CORE, una blockchain è un tipo speciale di struttura dati. I blocchi all'interno della catena contengono dati, ma questo non la rende un database; al massimo, i blocchi rappresentano il registro delle transazioni di una specifica implementazione del database.

Allo stesso modo, non esiste una semantica per interrogare una blockchain, così come non esiste per interrogare una lista concatenata. Un'implementazione specifica potrebbe consentire interrogazioni di entrambi, ma l'implementazione non definisce la cosa in sé.

Come punto di paragone, i pacchetti IP per i pacchetti TCP che trasportano questo articolo sono definiti come strutture dati in una serie di documenti IETF (Internet Engineering Task Force) RFC (Request For Comments). I documenti descrivono la forma dei pacchetti e il loro comportamento quando vengono trasportati. I destinatari di tali pacchetti sono in grado di determinare autonomamente la loro validità senza riguardo a nessuna parte dell'implementazione di rete tra loro e l'originatore.

Un'implementazione di un router/firewall può offrire una funzionalità per catturare quei pacchetti in modo che possano essere analizzati in seguito, e può offrire query di database di quei pacchetti, ma non c'è nulla nella natura di un pacchetto IP che lo renda un database, né c'è nulla nelle RFC che suggerisca il contrario. Le funzionalità di implementazione e le specifiche sono cose molto diverse.

La blockchain è affidabile?

La risposta qui è no, ma questo perché la domanda è troppo ampia. Una blockchain ci consente di richiedere meno fiducia rispetto a molti sistemi tradizionali, ma qualsiasi implementazione richiede comunque un certo livello di fiducia.

Un destinatario di dati di blocco deve fidarsi che siano stati consegnati senza essere compromessi da qualche intermediario. La distribuzione P2P di blocchi all'interno di Bitcoin e reti simili si prefigge di provare a ridurre al minimo la fiducia nei peer, ma anche questo modello ha potenziali punti di fallimento. Eccone alcuni:

• Confidiamo che il software blockchain che stiamo eseguendo non sia stato compromesso per fornire dati falsificati
• Confidiamo che il sistema operativo su cui gira il nostro software blockchain non sia stato compromesso per fornire dati falsificati
• Confidiamo che i processori di rete che forniscono connettività al nostro sistema non siano stati compromessi per fornire dati falsificati.

"Ci fidiamo del codice" è un mantra interessante, ma oltre 30 anni di malware, spyware, ETC. ci informano che si tratta di una strategia altamente discutibile.

Un design blockchain rende le falsificazioni più difficili per un avversario e rende gli errori accidentali molto meno probabili. Siamo in grado di "fidarci ma verificare" (entro certi limiti), ma questo è comunque un miglioramento significativo rispetto alla fiducia cieca. Ancora più importante, nessuna di queste caratteristiche di minimizzazione della fiducia è un aspetto del design della rete P2P, ma è invece intrinseca alla codifica a blocchi.

Una blockchain deve essere senza autorizzazione oppure può esserlo?

Una blockchain è solo una struttura dati, quindi la domanda non ha davvero senso. Chi ha la capacità di leggere o scrivere una struttura dati è una questione completamente diversa.

Ignoriamo per un momento questa sottile distinzione, però, e agiamo come se la domanda potesse avere senso. Consideriamo il caso di Bitcoin; chi scrive la blockchain?

La risposta è che i minatori (o più precisamente, i creatori di blocchi come gli operatori di mining pool, non coloro che si limitano a hash dei blocchi) possono scrivere nuovi blocchi. I transattori sulla rete possono fornire transazioni candidate da includere nei blocchi, ma questo non garantisce che i blocchi conterranno mai tali transazioni. Con Bitcoin parliamo di questo come "non-permesso" perché nessuno ha bisogno di un permesso esplicito per diventare un Maker di blocchi.

Se consideriamo altri potenziali utilizzi di un design blockchain, tuttavia, c'è un set di partecipanti spesso molto ben definito che vorremmo poter scrivere dati di blocco. In molti casi questo potrebbe anche essere ONE singolo partecipante.

Una critica rivolta a tali potenziali utilizzi di una blockchain è che questo non la rende migliore di un database, ma un database convenzionale è qualcosa in cui si deve riporre una fiducia cieca. Il suo stato interno è generalmente inconoscibile. Anche nei suoi utilizzi più semplici una blockchain può almeno fornire un mezzo per verificare lo stato di tale sistema, e per farlo in un modo che consenta di convalidare le cronologie. Questo è solo l'inizio delle possibilità, tuttavia!

La blockchain è l'Internet del denaro (o l'Internet di qualsiasi altra cosa)?

Realisticamente no, o almeno non da solo.

Quando abbiamo esaminato "non un database" abbiamo anche accennato al motivo per cui questa affermazione T ha molto senso. Superficialmente l'argomento sembra seducente. Il pensiero è che possiamo costruire un sacco di Tecnologie su una blockchain nel modo in cui uno stack di rete è stratificato.

Ci sono molti problemi con questa proposta, ma ONE ovvio è che una blockchain è solo una struttura dati. È un buon candidato per essere utilizzato per trasmettere informazioni attraverso Internet, ma T abilita nulla di per sé.

Separare la blockchain da qualsiasi trasporto di una blockchain, tuttavia, dà qualche speranza che le blockchain possano abilitare applicazioni finanziarie più affidabili su Internet. Una netta separazione consente anche la sperimentazione a ogni livello della progettazione del sistema e questa è una caratteristica fondamentale che ha permesso a Internet di avere così tanto successo.

Con Internet, i candidati per tutti i livelli dello stack di rete possono essere sperimentati, sostituiti o modificati, consentendo ai progetti migliori di WIN. Allo stesso modo, l'approccio basato sugli standard ha consentito a implementazioni disparate di funzionare insieme senza impedire che i vantaggi commerciali fossero ricercati e monetizzati.

Nel caso delle blockchain, abbiamo già visto che è necessario supportare osservatori esterni e ciò richiede un certo livello di interoperabilità.

Ultimi pensieri

Abbiamo esaminato cosa potrebbe o non potrebbe essere una blockchain, e forse abbiamo visto qualche accenno a cosa potrebbe abilitare. La Tecnologie che sostiene Bitcoin può essere utilizzata per costruire molte cose, e l'eredità di bitcoin non dovrebbe essere solo Bitcoin stesso: ha dimostrato la fattibilità di qualcosa di molto più fondamentale.

Il dibattito su cosa costituisca una blockchain T finirà qui, ma dobbiamo portare avanti la discussione e resistere alla tentazione di lasciarla diventare solo un altro termine di moda nel marketing.

Per far sì che ciò accada, abbiamo bisogno sia di una terminologia chiara, sia di un utilizzo ben ragionato. Dobbiamo evitare di confondere molte idee diverse, e abbiamo bisogno che le affermazioni Tecnologie siano realistiche e realizzabili. Se falliamo, alla fine, il termine "blockchain" non avrà più senso e dovrà essere sostituito. Questo sembra il risultato sbagliato.

Se ci riusciremo, l'idea di una blockchain non sarà la fine della storia. Invece, prenderà il suo posto come strato su cui si possono costruire sistemi migliori e sempre più utili.

Questo articolo è stato ripubblicato con l'autorizzazione diHashingit.comPuoi Seguici Dave su Twitter a @hashingitcom.

Immaginetramite Shutterstock