Le blockchain non scaleranno. Non oggi, almeno. Ma c’è speranza.

Il primo paper sui Bitcoin è stato rilasciato per la prima volta nel 2008. La mia eccitazione riguardo al potenziale della tecnologia blockchain è stata sin da allora in via di sviluppo.

La valuta digitale decentralizzata, una volta solo un obiettivo inverosimile, sta finalmente facendo breccia nel mainstream. Anche se è eccitante per i suoi meriti, sono personalmente molto entusiasta anche per il relativo potenziale delle applicazioni decentralizzate. Gli scambi finanziari, i mercati di previsione e le piattaforme di asset management hanno tutti un enorme potenziale.

I sistemi senza fiducia che ne sono alla base non sono meno intriganti; sistemi di verifica dell’identità, proprietà intelligenti, resistenti alla censura piattaforme sociali e strutture autonome e modelli di governance come la DAO. I casi d’uso più dirompenti probabilmente non sono ancora stati nemmeno immaginati.

Ma questo sogno rimane ancora un sogno per il futuro prossimo- mentre alcuni primi entusiasti e imprenditori stanno sperimentando la costruzione di tali applicazioni, c’è ancora un grande pezzo mancante che ci impedisce di vedere queste applicazioni giungere a buon fine: scalabilità. Le blockchain, così come sono oggi, sono limitate nella loro capacità di scalare.

Questo non vuol dire che questo sarà per sempre, ma è sicuramente vero oggi. In realtà, direi che è una delle più grandi barriere tecnologiche che affrontiamo oggi con la tecnologia blockchain. Diventa rapidamente un’area di ricerca molto attiva tra i ricercatori della comunità e la criptovaluta in generale.

Perché la blockchain non è scalabile?

Attualmente, tutti i protocolli di consenso blockchain (es. Bitcoin, Ethereum, Ripple, Tendermint) hanno una limitazione impegnativa: ogni nodo pienamente partecipante nella rete deve elaborare ogni transazione. Ricordiamo che le blockchain hanno una caratteristica fondamentale intrinseca – “decentralizzazione” – il che significa che ogni singolo nodo sulla rete elabora ogni transazione e mantiene una copia dell’intero stato.

Mentre un meccanismo di consenso basato sulla decentralizzazione offre alcuni vantaggi critici, come la tolleranza ai guasti, una forte garanzia di sicurezza, neutralità politica e autenticità, ha un costo di scalabilità. Il numero di transazioni che la blockchain può elaborare non può mai superare quello di un singolo nodo che partecipa alla rete. In effetti, la blockchain diventa effettivamente più debole man mano che altri nodi vengono aggiunti alla sua rete a causa della latenza tra i nodi che logaritmicamente aumenta con ogni nodo aggiuntivo.

In un sistema di database tradizionale, la soluzione alla scalabilità consiste nell’aggiungere più server (ad es. Potenza di calcolo) per gestire le transazioni aggiunte. Nel mondo delle blockchain decentralizzate in cui ogni nodo deve elaborare e convalidare ogni transazione, ci richiederebbe di aggiungere più calcoli a ogni nodo per la rete per ottenere più velocemente l’elaborazione delle stesse. Non avere controllo su tutti i nodi pubblici della rete ci lascia in imbarazzo.

Di conseguenza, tutti i protocolli di consenso pubblico blockchain che operano in modo così decentralizzato rendono il compromesso tra un basso volume di transazioni e un alto grado di centralizzazione. In altre parole, con l’aumentare delle dimensioni della blockchain, aumentano i requisiti di storage, larghezza di banda e potenza di calcolo richiesti dalla piena partecipazione alla rete. Ad un certo punto diventerà abbastanza difficile che per alcuni nodi sia possibile elaborare solo un blocco, il che comporta il rischio di centralizzazione.

Per scalare, il protocollo blockchain ha necessità di trovare un meccanismo per limitare il numero di nodi partecipanti necessari per convalidare ogni transazione, senza perdere la fiducia della rete secondo cui ogni transazione è valida.Potrebbe sembrare semplice a parole, ma è tecnologicamente molto difficile. Perché?

  1. Poiché ogni nodo non è autorizzato a convalidare ogni transazione, abbiamo in qualche modo bisogno di nodi per avere un mezzo statistico ed economico per garantire che altri blocchi (che non sono stati personalmente validati) siano sicuri.
  2. Ci deve essere un modo per garantire la disponibilità dei dati. In altre parole, anche se un blocco sembra valido dal punto di vista di un nodo che non convalida direttamente quel blocco, rendere i dati per quel blocco non disponibili porta a una situazione in cui nessun altro validatore nella rete può validare transazioni o produrre nuovi blocchi, e noi finiamo bloccati nello stato attuale. (Esistono diversi motivi per cui un nodo potrebbe non essere in linea, inclusi attacchi malevoli e interruzioni dell’alimentazione).
  3. Le transazioni devono essere elaborate da nodi diversi in parallelo al fine di raggiungere la scalabilità. Tuttavia, lo stato di transizione sulla blockchain ha anche diverse parti non serializzabili (seriali), quindi ci troviamo di fronte ad alcune restrizioni su come possiamo eseguire lo stato di transizione sulla blockchain mentre bilanciamo sia la parallelizzazione che l’utilità.

E quali sono i numeri?

Quindi, quali sarebbero i numeri della scalabilità? Approfondiamo il tema.

La capacità massima di elaborazione teorica di un nodo di Ethereum è oltre 1.000 transazioni al secondo [1]. Sfortunatamente, questo non è il rendimento effettivo dovuto al “limite di gas” di Ethereum, che attualmente è di circa 6,7 ​​milioni di gas in media per ogni blocco [2].

Una veloce spiegazione del cosa sia il “gas” nel caso in cui la misurazione sia nuova per voi: in Ethereum, il gas è una misura dello sforzo computazionale e ad ogni operazione viene assegnata una quantità fissa di gas (ad esempio, ottenere il saldo di un conto costa 400 gas, creando un contratto costa 32.000 gas, l’invio di una transazione costa 21.000 gas, ecc.). Le transazioni hanno un campo limite di gas per specificare la quantità massima di gas che il mittente è disposto ad acquistare. Pertanto, il “limite di gas” per ciascun blocco determina il numero di transazioni che troveranno spazio in un blocco in base al limite di gas specificato da ciascuna transazione nel blocco.

Il limite di gas di Ethereum è in qualche modo simile al limite di 1 MB di Bitcoin sulla dimensione di ogni blocco, con la differenza che il limite di gas di Ethereum è impostato dinamicamente dai minatori mentre il limite di dimensione del blocco di Bitcoin è hardcoded nel protocollo.

Questo limite di gas per Ethereum impone un soft cap sulla potenza di calcolo della rete per blocco: con l’attuale limite di 6,7 milioni di gas e il gas medio attuale utilizzato per una transazione standard di circa 21 K, otteniamo circa 300 transazioni standard per ciascunblocco. Il tempo di blocco medio attuale è di 20 secondi, il che equivale a circa 15 transazioni al secondo (300/20 = 15) al massimo [4]. Questo diventa molto più basso con transazioni più complesse (ad esempio il gas mediano utilizzato dalle chiamate agli smart contracts presenti sulla blockchain è 50 K [3], il che porta a circa ~ 7 transazioni al secondo).

In combinazione con il fatto che il numero di transazioni sulla rete Ethereum sta crescendo ad un ritmo significativo, puoi vedere come questo potrebbe diventare un problema. Le transazioni giornaliere sono passate da circa 40K a 240K dal secondo trimestre 2016 al secondo trimestre 2017 [4], il che rappresenta una crescita del 500% anno su anno. Inoltre, proprio nel mese scorso ha raggiunto un picco di oltre 440.000 transazioni al giorno! Se facciamo alcuni calcoli, questi numeri ci portano ad una media di 5 transazioni al secondo.

Oh oh.

Allo stesso modo, Bitcoin, nonostante abbia un limite teorico di 4.000 transazioni al secondo, ha attualmente un limite massimo di circa 7 transazioni al secondo per transazioni di piccole dimensioni e 3 al secondo per transazioni più complesse.

Nota che queste limitazioni non esistono per blockchain private. Le blockchain private possono, infatti, raggiungere oltre 1.000 transazioni al secondo su Ethereum o Bitcoin. Perché? Perché se si sta eseguendo una blockchain privata, si ha la possibilità di garantire che ogni nodo della rete sia un computer di alta qualità con una connessione Internet ad ampia larghezza di banda. Scalare la blockchain attualmente ci richiederebbe di aggiungere più potenza computazionale ad ogni nodo della rete al fine di aumentarne le performance. Poiché le reti gestite privatamente hanno il controllo su ogni nodo della rete, possono farlo. Inoltre, dal momento che si è su una rete privata, si possono gestire alcune azioni che altrimenti si verificherebbero sulla blockchain, fuori dalla stessa, come ad esempio assicurarsi che ogni nodo che sta partecipando stia eseguendo un vero nodo.

Ho architettato e implementato un nuovo protocollo su Ethereum, e ho affrontato in prima persona il problema della scalabilità a prova di futuro. Personalmente, sono rimasto affascinato dalla quantità di ricerche, discussioni e, soprattutto, dalla sperimentazione che ha portato alla risoluzione di questo problema. Nel resto del post, descriverò alcune delle soluzioni proposte in discussione nella comunità per risolvere la scalabilità. Ciascuno ha punti di forza e compromessi unici.

La verità è che, sfortunatamente, nessuna delle soluzioni fornisce una risposta argentea alla scalabilità. In realtà, ognuna di queste soluzioni contribuirà a migliorare la scalabilità in modo incrementale. Combinati insieme, c’è una prospettiva promettente per il futuro della scalabilità della blockchain.

Vorrei che sia ben chiaro che l’obiettivo di questo post non è quello di esplorare tutte le complessità tecniche o di discutere i meriti di ciascuna soluzione proposta. Invece, il mio obiettivo è dare una panoramica dall’alto di alcune delle soluzioni proposte di cui sono a conoscenza. Se i lettori sono interessati, posso approfondire alcune delle soluzioni specifiche in modo più approfondito nei post successivi. Questo post presuppone anche che si abbia una conoscenza di base di come funziona la blockchain. (In caso contrario, puoi controllare il mio ultimo post “Bitcoin, Ethereum, Blockchain, Tokens, Ico: perché dovrebbe interessare a qualcuno?” per un rinfresco.)

Inoltriamoci nella tana del bianconiglio.

Soluzioni

Scalare la blockchain è una sfida conosciuta ed è stata un’area di ricerca attiva per diversi anni. Nello specifico, se hai seguito i dibattiti pluriennali nella comunità di Bitcoin, potresti aver sentito parlare di due soluzioni di scaling specifiche per Bitcoin conosciute come SegWit e l’aumento della dimensione del blocco di 2 megabyte (MB).

Entrambe queste soluzioni mirano a risolvere il problema specifico di Bitcoin in cui la blockchain Bitcoin ha un limite incorporato nel codice di 1 megabyte (MB) per blocco, che limita il numero di transazioni che possono essere aggiunte a un blocco. Di conseguenza, Bitcoin ha subito ritardi (a volte ore e persino giorni) nell’elaborazione e nella conferma delle transazioni da parecchio tempo. Allo stesso modo, come abbiamo visto nella sezione precedente, Ethereum affronta anche limitazioni nella sua capacità di scalare.

Fino a quando non capiremo come ridimensionare la blockchain, siamo limitati nel come l’utilizzo rapido e ampio possano effettivamente ampliare i casi d’uso. Diamo un’occhiata ad alcune soluzioni sul tavolo.

Soluzione proposta n. 1: SegWit (solo Bitcoin)

Ogni transazione Bitcoin contiene:

Input

  • I precedenti dettagli della transazione del mittente
  • Chiave privata unica del mittente (ad es. `ScriptSig`) che verifica che il mittente abbia il giusto importo (in base alle transazioni precedenti) per effettuare la transazione

Output

  • Importo da inviare:
  • Indirizzo pubblico del destinatario (ad esempio `ScriptPubKey`)

Di questi elementi, la firma digitale (`scriptSig`) è la più grande in termini di dimensioni, rappresentando il ~ 60-70% della transazione. Tuttavia, le firme sono necessarie solo al momento della convalida.

Il testimone segregato (noto anche come Segregated witness, o più colloquialmente SegWit) è la soluzione per separare le firme delle transazioni (cioè “segregate”) (cioè “testimoni”) dal resto dei dati della transazione. La firma viene eliminata dall’input e spostata in una struttura verso la fine di una transazione.

Inoltre, con SegWit, i testimoni vengono spostati in un nuovo campo “testimone” nei dati della transazione, che ci consente di cambiare il modo in cui vengono calcolate le dimensioni dei blocchi. Il limite della dimensione del blocco non viene più misurato in byte. Invece, ai blocchi e alle transazioni viene assegnata una nuova metrica chiamata “peso” che corrisponde alla domanda che posizionano sulle risorse del nodo. Nello specifico, a ciascun byte di un testimone segregato viene assegnato un peso pari a 1, a ciascun byte in un blocco viene assegnato un peso di 4 e il peso massimo consentito di un blocco è 4 milioni, che consente a un blocco contenente transazioni SegWit di contenere più dati superiori a quelli consentiti dalla dimensione massima del blocco corrente. Ciò aumenterebbe in modo efficace il limite dal limite di 1 MB a poco meno di 4 MB, ottenendo un aumento del 70% circa delle transazioni.

SegWit risolve anche altri problemi oltre alla scalabilità, come la malleabilità delle transazioni e l’aumento della sicurezza (che non tratterò qui poiché non è correlato alla scalabilità).

Soluzione proposta n. 2: dimensione del blocco di 2 MB (solo Bitcoin)

Mentre un lato della comunità Bitcoin (gli utenti) supporta fortemente SegWit, l’altro lato della comunità (i minatori) preferisce un hard fork che cambierebbe il limite di dimensione del blocco di 1 MB a 2 MB (Tieni presente che il limite di 1 MB non può essere modificato senza un hard fork). L’idea di base è semplice: aumentando la dimensione del blocco, consentirebbe a più transazioni di entrare in ciascun blocco, consentendo alla rete di gestire più transazioni al secondo.

I piani di questo aumento delle dimensioni dei blocchi sono stati a lungo oggetto di dibattito acceso nella comunità di Bitcoin, e hanno acquisito crescente attenzione dall’inizio del 2015, quando la dimensione dei blocchi ha iniziato ad avvicinarsi all’attuale limite rigido di 1 MB.

Soluzione proposta n. 3: canali di stato fuori dalla blockchain

I canali di stato sono essenzialmente un meccanismo attraverso il quale le interazioni blockchain che potrebbero e normalmente si verifichino sulla blockchain vengono invece condotte fuori dalla blockchain. Questo viene fatto in modo crittograficamente sicuro senza aumentare il rischio di qualsiasi partecipante, pur fornendo significativi miglioramenti in termini di costo e velocità. Personalmente ritengo che i canali di stato costituiranno una parte fondamentale del ridimensionamento delle tecnologie blockchain per supportare livelli più elevati di utilizzo.

Un canale di stato funziona come segue:

  1. Parte della situazione sulla blockchain è bloccata tramite transazioni multi-firma o una sorta di contratto intelligente, in cui l’unico modo per aggiornarlo è se un insieme specifico di partecipanti è completamente d’accordo.
  2. I partecipanti si aggiornano tra loro costruendo e firmando crittograficamente le transazioni senza inviarle alla blockchain. Ogni nuovo aggiornamento sostituisce gli aggiornamenti precedenti.
  3. In un secondo momento, i partecipanti aggiornano lo stato della blockchain, che chiude il canale di stato e sblocca nuovamente lo stato.

I passaggi 1 e 3 riguardano le operazioni di blockchain che vengono pubblicate sulla rete, pagano le commissioni e attendono le conferme. Tuttavia, il passaggio 2 non coinvolge affatto la blockchain. Può contenere un numero illimitato di aggiornamenti e può rimanere aperto indefinitamente. In questo senso, la blockchain viene utilizzata esclusivamente come livello di regolamento per elaborare la transazione finale di una serie di interazioni per il regolamento finale, che aiuta a sollevare l’onere dalla blockchain sottostante.

In qualsiasi momento durante il processo, qualsiasi partecipante può inviare una transazione nel contratto per chiudere il canale e avviare una procedura di pagamento. Ciò avvia un limite di tempo entro il quale i partecipanti possono inviare transazioni e viene elaborata la transazione con il numero di sequenza più alto. Se uno dei partecipanti lascia o tenta di imbrogliare, un altro può in qualsiasi momento pubblicare l’ultima transazione sulla blockchain per finalizzare lo stato, assumendo che tutti i partecipanti siano completamente d’accordo sullo stato.

Non solo la capacità transazionale è aumentata con i canali di stato, ma forniscono anche altri due importanti vantaggi: maggiore velocità e tariffe più basse. Poiché la maggior parte delle transazioni avviene fuori catena, i pagamenti possono essere gestiti istantaneamente poiché gli aggiornamenti tra due parti che avvengono fuori blockchain non richiedono il tempo aggiuntivo per essere elaborati e verificati dalla rete. In secondo luogo, i pagamenti incorrono anche in commissioni più basse perché solo un piccolo numero di transazioni su catena sono necessarie per garantire i canali dello stato di regolamento, mentre la maggior parte delle transazioni avviene fuori catena senza commissioni.

Esistono diverse implementazioni di questo. Per esempio, il Lightning Network è una rete decentralizzata che utilizza i canali di stato tramite smart contract per consentire pagamenti istantanei e scalabili su una rete di partecipanti. Inizialmente, il Lightning Network è stato creato per Bitcoin, ma ora sembra che consenta anche transazioni su varie blockchain.

Raiden Network è l’analogio del Lightning Network sulla rete di Ethereum. Il Raiden Network sfrutta anche le reti fuori rete per estendere Ethereum con transazioni scalabili e istantanee.

Soluzione proposta n. 4: Sharding

Lo Sharding nel mondo blockchain è simile alla condivisione del database nei sistemi software tradizionali. Con i database tradizionali, un frammento è una partizione orizzontale dei dati in un database, in cui ogni frammento viene archiviato su un’istanza del server database separata. Questo aiuta a distribuire il carico su diversi server.

Allo stesso modo, con lo sharding applicato alla blockchain, lo stato complessivo della blockchain viene separato in diversi frammenti e ogni parte dello stato viene memorizzata da diversi nodi nella rete.

Un singolo frammento

Diagramma di livello superiore dello sharding della blockchain [6]

Le transazioni che si verificano sulla rete sono dirette a diversi nodi a seconda dei frammenti che influenzano. Ogni frammento elabora solo una piccola parte dello stato e lo fa in parallelo. Per comunicare tra i frammenti, è necessario un meccanismo di trasmissione dei messaggi.

Esistono vari modi per implementare il passaggio dei messaggi. Nel caso di Ethereum, l’approccio che stanno adottando è un paradigma di “ricevimento”: quando una transazione all’interno di un frammento viene eseguito, può cambiare lo stato del proprio frammento locale, generando anche “ricevute”, che sono memorizzate in una sorta di distribuzione memoria condivisa che può essere successivamente visualizzata (ma non modificata) da altri frammenti.

Il paradigma di ricevuta di Ethereum [1]

Il paradigma della ricevuta di Ethereum [6]

Nel complesso, la condivisione della blockchain ci impone di creare una rete in cui ogni nodo elabora solo una piccola parte di tutte le transazioni, mantenendo comunque un’elevata sicurezza … Una sfida difficile a dir poco.

Perché?

Bene, per esempio, il protocollo blockchain presuppone che tutti i nodi della rete non si fidano l’uno dell’altro. Tuttavia, le transazioni devono concordare uno stato comune nonostante vengano elaborate su computer diversi. Poiché ciascun nodo non si fida di un altro, non è sufficiente che un nodo elabori le transazioni sul frammento A per dire semplicemente ai nodi che elaborano le transazioni sullo shard B che si è verificata una transazione; piuttosto, avrebbe bisogno di dimostrare loro l’esistenza della stessa in qualche modo.

Inoltre, poiché l’obiettivo dello sharding è di non avere ogni nodo che convalida ogni transazione, dobbiamo capire un meccanismo che determini quali nodi convalidano il frammento in un modo sicuro, senza creare opportunità per un utente malintenzionato che potrebbe avere un sacco di potere in questo sistema per interrompere la rete.

Un altro motivo per cui è difficile implementare il sharding è perché una transazione eseguita sulla blockchain può dipendere da qualsiasi parte dello stato precedente nella blockchain, il che rende difficile fare le cose in parallelo. Inoltre, con la parallelizzazione, ora è necessario un modo infallibile per mitigare le condizioni della competizione.

Ci sono molte altre chicche tecniche su come verrà implementata lo sharding in Ethereum – in particolare, come utilizzare “incentivi crittografici” per guidare gli attori in un sistema a non imbrogliare (in questo caso, assicurando che i nodi passino informazioni valide ad altri nodi ).

Soluzione proposta n. 5: Plasma

Plasma è stato introdotto di recente ed è tra le soluzioni più promettenti proposte per il calcolo scalabile sulla blockchain.

Il Plasma è essenzialmente una serie di contratti eseguiti su una blockchain (cioè la principale blockchain di Ethereum). La blockchain radice applica la validità dello stato nelle catene del plasma usando qualcosa chiamato “prove antifrode”. (Nota: le prove antifrode sono un meccanismo attraverso il quale i nodi possono determinare se un blocco non è valido usando prove matematiche).

Fonte: Plasma Whitepaper

Le blockchain sono composte in una gerarchia ad albero, e ogni ramo è trattato come una blockchain che ha una propria storia di blockchain e calcoli che sono riducibili in una mappa. Chiamiamo le catene secondarie “Plasma blockchains”, ognuna delle quali è una catena all’interno di una blockchain.

La blockchain Plasma non rivela il contenuto della blockchain sulla blockchain radice. (ad es. Ethereum). Invece, solo gli hash blockheader vengono inviati sulla catena radice, il che è sufficiente per determinare la validità del blocco. Se è presente una prova di frode presentata nella catena radice, il blocco viene ripristinato e il creatore del blocco viene penalizzato. In altre parole, inviamo alla blockchain root dati nelle condizioni della tolleranza Bizantina.

Di conseguenza, la blockchain di root elabora solo una piccola quantità di impegni da blockchain figlio, che a sua volta riduce la quantità di dati passati sulla blockchain di root e consente un numero molto maggiore di calcoli.

Inoltre, i dati vengono propagati solo a coloro che desiderano convalidare uno stato particolare. Questo rende le esecuzioni dei contratti più scalabili, eliminando la necessità per ogni nodo di guardare ogni catena. Invece, guardano solo quelli di cui sono influenzati economicamente al fine di imporre un comportamento corretto e penalizzare le frodi. Le prove antifrode consentono a qualsiasi parte di imporre blocchi non validi e garantire che tutte le transizioni di stato siano convalidate.

Inoltre, se si verifica un attacco a una particolare catena, i partecipanti possono effettuare in modo rapido ed economico un’uscita di massa dalla catena di blocchi corrotti.

Il plasma potrebbe sembrare simile alle implementazioni dei canali di stato (ad es. Lightning Network) che gestiscono le transazioni fuori catena. La principale differenza tra i canali di stato e Plasma è che con Plasma, non tutti i partecipanti devono essere online per aggiornare lo stato. Inoltre, i partecipanti non devono inviare dati alla blockchain di root per partecipare e confermare le transazioni.

La parte essenziale di Plasma è che le soluzioni di tipo “canali di stato” come Lightning Network potrebbero essere il principale strato di interfaccia per pagamenti / contratti finanziari rapidi su Plasma, mentre lo stesso mantiene gli aggiornamenti allo stato con impegni minimi per lo stato della catena principale.

Ci sono molti dettagli intricati su questa soluzione che spero di approfondire in un post futuro.

Soluzione proposta n. 6: calcoli fuori catena (es. TrueBit)

TrueBit è un esempio di soluzione che utilizza calcoli fuori catena per abilitare transazioni scalabili tra i contratti smart di Ethereum. In sostanza, proprio come i canali di stato, TrueBit utilizza uno strato esterno alla blockchain per esonerarla dall’onere di elaborare una grande mole di transazioni. In altre parole, è un sistema che esegue in modo verificabile calcoli fuori catena che sarebbero altrimenti proibitivi per l’esecuzione on-chain. Funziona così.

Invece di ogni nodo che partecipa, specifici partecipanti alla rete, chiamati “Risolutori”, eseguono i calcoli fatti da contratti intelligenti e presentano una soluzione al problema, insieme a un deposito. Se il Risolutore è corretto, il risolutore viene ricompensato e il deposito restituito. Altrimenti, se il Risolutore ha ingannato, il deposito viene perso e qualsiasi controversia viene risolta sulla blockchain utilizzando il “Gioco della verifica”.

I giochi della verifica sono fatti così: ci sono una serie di partecipanti nella rete chiamata “verificatori” che controllano il lavoro dei risolutori dalla blockchain. Se nessun verificatore segnala un errore, il sistema accetta la soluzione. Se un verificatore contesta la correttezza della soluzione del Risolutore, il gioco procede in una serie di round per risolvere la disputa sulla blockchain, dove “Giudici” nella rete con potere computazionale limitato giudicano tutte le dispute. Il sistema è stato progettato per garantire che il lavoro svolto dai giudici sulla blockchain sia ridotto rispetto al lavoro richiesto per eseguire il compito effettivo fuori dalla stessa.

Alla fine di questo gioco, se il Risolutore avesse effettivamente barato, verrà scoperto e punito. In caso contrario, lo Sfidante pagherà le risorse consumate dal falso allarme.

Un diagramma molto approssimativo di calcoli fuori catena come proposto da TrueBit

Infine, per convincere i verificatori che i bug esistono realmente e che vale la pena tentare di trovare questi bug, TrueBit fa qualcosa di interessante dove occasionalmente costringe i Solver a presentare soluzioni errate, il che rovescia i normali incentivi del sistema: il Risolutore viene pagato per inviare una soluzione errata e penalizzata per aver inviato una soluzione corretta. Ciò garantisce che nel sistema esistano sempre dei verificatori che convalidano le transazioni.

In sintesi, il protocollo consente a chiunque di postare un’attività computazionale e a chiunque altro di ricevere una ricompensa per il completamento, mentre la struttura di incentivi del sistema garantisce la correttezza delle soluzioni restituite. E spostando i calcoli e il processo di verifica dalla blockchain di Ethereum in un protocollo separato, può adattarsi ad un grande numero di calcoli senza essere limitato dal limite di gas di Ethereum.

Altre soluzioni proposte per la scalabilità di blockchain.

Ci sono alcune altre proposte che girano attorno alla comunità cripto che trovo interessanti. Sebbene le soluzioni non siano direttamente finalizzate alla risoluzione della scalabilità, aiutano indirettamente a risolvere alcuni problemi di scalabilità più facilmente.

Proof of stake

Simile alla Proof-of-work, la proof-of-Stake è un meccanismo di consenso che sostiene la sicurezza della blockchain prevenendo la doppia-spesa, o doublespend.

In sistemi tradizionali di Proof-of-Work basati su blockchain, i minatori mantengono l’integrità dei dati della blockchain gareggiano per risolvere enigmi matematici di proof-of-work, in cambio di ricompense. A questo proposito, aiutano a convalidare le transazioni con la loro potenza della CPU, e a più potenza della CPU corrisponde una proporzionalmente maggiore capacità di influenzare la rete. Nella Proof of Stake, le parti interessate votano con i loro “dollari” (nel caso di Ethereum, etere) piuttosto che con la potenza computazionale.

Come funziona esattamente?

La blockchain tiene traccia di determinati nodi di convalida, chiamati “validatori”, che devono depositare un deposito di sicurezza (denominato “legame”) per partecipare alla convalida dei blocchi. Se un validatore produce qualcosa che il protocollo considera “non valido” in modo cripto-grafico, sia il loro deposito sia il privilegio di partecipare al processo di consenso vengono confiscati. Se scommettono correttamente, guadagnano il loro deposito insieme alle spese di transazione.

In effetti, i validatori fanno soldi scommettendo a favore dell’eventuale consenso e perdeno denaro scommettendo contro lo stesso. Si può fare un’analogia con la Proof-of-work in cui ogni minatore scommette con la propria potenza hash su quale blocco verrà accettato. Se scommettono in modo errato per imbrogliare il sistema, qualsiasi blocco che producono sarà orfano, causando loro perdite di denaro.

Esistono diversi tipi di algoritmi di verifica della prova del palo e diversi meccanismi per assegnare i premi ai validatori, che non saranno oggetto di questo post.

In che modo la Proof-of-Stake aiuta la scalabilità?

Un esempio è con lo sharding. Sharding con la Proof-of-work è difficile da fare in modo sicuro. Ricordiamo che con lo sharding, dividiamo la responsabilità di validazione tra molti nodi in modo che ogni nodo non debba elaborare tutto. Tuttavia, la Prova di lavoro è implementata per essere completamente anonima, il che pone un problema perché anche se un singolo frammento (shard) è protetto solo da una piccola porzione di un hashpower dei minatori, un utente malintenzionato può dirigere tutti i suoi hashpower ad attaccare questo frammento e interrompere il network. Ad esempio, supponiamo di avere due frammenti, A e B. A ha il 90% del hashpower e B il 10%. A potrebbe attaccare B con solo il 5,1% del totale di hashpower (in virtù di maggioranza 51% di attacco).

Questo cambia con l’attuale proposta di Proof-of-Stake di Ethereum perché è progettata in modo tale che i validatori abbiano delle identità note (ad esempio gli indirizzi di Ethereum). Conoscere le loro identità ci consente di risolvere questo tipo di attacco mirato scegliendo casualmente un insieme di nodi dall’intero set di validatori per elaborare qualsiasi dato insieme di transazioni su un frammento, il che rende impossibile per un utente malintenzionato bersagliare in modo specifico un qualsiasi frammento.

Un altro motivo per cui Proof-of-stake aiuta la scalabilità (in particolare per Ethereum) è perché a differenza della proof-of-work che emette nuovi token per i minatori che convalidano i blocchi, in Proof of Stake, i validatori probabilmente vedranno nelle commissioni di transazione la sola fonte di guadagno. Di conseguenza, hanno un incentivo ad aumentare il blocco “limite di gas” (perché guadagna più compensi e contemporaneamente misura più transazioni in ogni blocco), se il loro server di convalida può gestire il carico. La condizione è che i validatori aumenteranno il limite del gas solo fino ad un punto che è tollerabile dagli altri validatori, perché altrimenti vedranno ridurre i loro rendimenti dal mandare fuori sincronizzazione altri validatori più lenti.

Blockchain rent

Un’altra soluzione specifica di Ethereum è “Blockchain rent” [5]. Blockchain rent è una soluzione che mira a ridurre la quantità di dati archiviati sulla rete al fine di accelerare i tempi di transazione. Con Ethereum, gli utenti pagano per i passaggi computazionali, la memoria, i registri delle transazioni e la memorizzazione permanente. Mentre la maggior parte di queste risorse sono pagate in modo adeguatamente incentivato, l’affermazione qui è che l’archiviazione non lo è.

Nel sistema attuale, gli utenti pagano solo i byte di archiviazione. Tuttavia, in realtà, possiamo affermare che lo storage è diverso dalle altre risorse perché è memorizzato per sempre in modo permanente nei blocchi. Invece, Blockchain rent propone di introdurre un costo di archiviazione da indicare con `byte x tempo`. In questo modo, c’è un incentivo incorporato nel protocollo per mantenere la rete più leggera e ridurre i tempi di transazione.

Stoccaggio decentralizzato

Un’altra soluzione per mantenere la rete più leggera è l’utilizzo di un servizio di archiviazione decentralizzato come Swarn. Swarm è un protocollo di condivisione file peer-to-peer per Ethereum che consente di archiviare il codice dell’applicazione e i dati fuori dalla blockchain principale nei nodi swarm, che sono collegati alla blockchain di Ethereum e in seguito scambiare questi dati sulla blockchain.La premessa di base è che al posto dei nodi che memorizzano tutto sulla blockchain, memorizzano solo i dati che sono più frequentemente richiesti localmente e lasciano altri dati sul “cloud” tramite Swarm.

Un diagramma molto approssimativo dell’archiviazione decentralizzata usando Swarm

C’è di più, ma per brevità (questo post sta diventando piuttosto lungo!), Per ora li lascerò fuori :)

Conclusione

Questo argomento è mostruosamente complesso, ma spero che questo post sia stato utile per darvi un’idea del perché la scalabilità sia importante nel mondo blockchain e come possa essere risolta.

Questo non è un elenco completo di tutti i mezzi, e invito tutti a stare dietro questo argomento mentre la ricerca avanza. Personalmente dubito che ci sarà una risposta singola e risolutiva alla scalabilità … ma credo che una combinazione di approcci alla fine risolverà il problema e consentirà alle applicazioni di blockchain di fare il balzo in avanti.

Ti invito, non esitare a correggere eventuali errori che ho commesso o avviare una discussione (salutare) nei commenti.

Buon blockchaining! ;)


Riferimenti:

[1] http://www.r3cev.com/blog/2016/6/2/ethereum-platform-review

[2] https://etherscan.io/chart/gaslimit

[3] http://ethgasstation.info/

[4] https://etherscan.io/chart/tx

[5] https://github.com/ethereum/EIPs/issues/35

[6] https://docs.google.com/presentation/d/1CjD0W4l4-CwHKUvfF5Vlps76fKLEC6pIwu1a_kC_YRQ/edit#slide=id.gd284b9333_0_6

L'articolo originale: https://hackernoon.com/blockchains-dont-scale-not-today-at-least-but-there-s-hope-2cb43946551a