Menu
Home » Codice e sviluppo » Non credere al FUD, Ethereum può scalare

Non credere al FUD, Ethereum può scalare

04 Marzo 2019 20:00
Tempo di lettura: 17 min.
04 Marzo 2019 20:00
Giuseppe Brogna

Negli ultimi mesi, abbiamo notato un numero significativo di articoli che proclamavano l’imminente fallimento e collasso della piattaforma di Ethereum, a causa della sua incapacità di scalare e della mancanza di popolarità tra gli utenti.

Non c’è nulla di nuovo. Un simile ciclo di hype si manifesta con molte nuove tecnologie emergenti. Nel famoso modello di Gartner, il “Picco delle Aspettative Gonfiate” è seguito rapidamente dal “Fondo della Disillusione“.

Nel caso di Ethereum, abbiamo superato la prima fase e ci troviamo a percorrere la seconda.

Le preoccupazioni sollevate negli articoli di critica sono legittime, ma in genere ignorano gli importanti progressi compiuti ogni giorno in merito alla scalabilità. No, nel suo attuale stato, Ethereum non può scalare per diventare un “computer mondiale”. Il throughput è basso e il costo è esorbitante.

Tuttavia, già prima del lancio di Ethereum come blockchain, questi problemi erano stati ipotizzati e ben compresi. In questo articolo, discuteremo le varie soluzioni che sono state ideate negli ultimi anni per affrontare tali limiti.

Nel mezzo della bolla delle ICO, i volumi elevati di transazioni hanno congestionato la rete, facendo aumentare il prezzo del gas (la piccola quantità di eher richiesta per eseguire le transazioni). Questa circostanza ha materializzato le sfide sulla scalabilità, di cui gli sviluppatori erano ben consapevoli e avevano già iniziato a trattare, malgrado l’attenzione da parte dei media abbia fatto credere diversamente.

Sebbene la scalabilità di Ethereum, per alcuni, possa rappresentare una frontiera inesplorata, le soluzioni per far fronte al throughput sono da anni sotto i radar degli sviluppatori:

  • Scalare direttamente sulla blockchain di Ethereum, per essere in grado di gestire l’aumento del carico delle transazioni (ad es. attraverso gli aggiornamenti Serenity e Casper).
  • Ridurre il carico sulla chain principale, spostando la maggior parte delle transazioni su un Layer 2, e utilizzare il layer base solo per il settlment delle transazioni (ad es., Canali di Pagamento, State Channels, Plasma e Sidechain).

Le soluzioni “Layer 1”, come Sharding e Casper, sono sulla roadmap di Ethereum da alcuni anni, ma sono state afflitte da molteplici battute d’arresto che hanno impedito progressi significativi sul fronte dell’implementazione e dello sviluppo. Anche dopo l’introduzione di questi aggiornamenti, sarà comunque necessario avvelersi di soluzioni di scalabilità “Layer 2”, che forniscano un throughput ancora maggiore, transazioni private e fee inferiori.

Prima di immergerci nelle varie soluzioni Layer 2, ti chiediamo di pensare a Ethereum come a un layer di settlment globale, piuttosto che a un computer mondiale olistico. Vuol dire che Ethereum serve a regolare tutte le transazioni che sono state effettuate fuori dalla chain principale, rendendo effettivi i conseguenti trasferimenti di valore. In questo caso d’uso, la blockchain funge da terza parte imparziale per giudicare su come operano tutte le soluzioni Layer 2.

Ad alto livello, qualsiasi soluzione Layer 2 segue questa formula, o qualche sua variante:

  1. due o più parti accettano un insieme di regole, in base alle quali dovranno accedere e uscire da una soluzione di secondo livello;
  2. le parti codificano tali regole in uno smart contract, il quale richiede che ciascuna parte effettui un deposito di garanzia;
  3. dopo aver effettuato i loro depositi, tutte le parti possono interagire tra di loro off-chain, mentre inviano aggiornamenti periodici allo smart contract on-chain;
  4. quando una o più parti desiderano uscire dalla soluzione Layer 2, tipicamente, dovranno fornire delle prove crittografiche che rappresentino in modo accurato il saldo finale del deposito di ciascuna parte.
  5. c’è un periodo di contestazione, in cui la prova può essere confutata e scartata. Se, invece, il termine di contestazione scade, le parti coinvolte usciranno dalla soluzione Layer 2 due con i loro saldi aggiornati.

Le innovazioni Layer 2, come Plasma e i Payment Channels/State Channels, faciliteranno la maggior parte delle transazioni di Ethereum.

Scalare una blockchain pubblica (in particolare quella con un meccanismo di consenso così solido) è difficile, certamente. Ma non è assolutamente impossibile. Infatti, il supporto degli smart contract e la ethereum virtual machine (EVM), favoriscono nuove soluzioni di scalabilità e una maggiore flessibilità rispetto alle altre chain che tentano di scalare via Layer 2 con script basati tassativamente sugli unspent transaction output (UTXO), che per le loro caratteristiche non sono così estendibili (un insieme diverso di trade-off e benefici, come tutto in informatica).

Gli sforzi compiuti dalle applicazioni distribuite (dApps) per mantenere gli utenti, sono ben diffusi. Ma anni di ricerca e implementazione sulla scalabilità stanno rendendo possibile la user experience e la bassa latenza, necessarie per supportare dApps con un elevato numero di utenti mensili attivi (MAU).

In breve, per la prima volta, le soluzioni Layer 2 di Ethereum sono quasi pronte, con aziende come Cent, Spankchain e altre, che sono già al servizio degli utenti sulla blockchain, sul punto di sovvertire la narrativa secondo cui Ethereum non può scalare.

Le sezioni seguenti illustrano i limiti dei metodi di scalabilità tradizionali, altamente propagandati, ed evidenziano l’esigenza di soluzioni solide e generalizzabili per Ethereum.

Metodi tradizionali di scalabilità

I metodi di scalabilità più tradizionali, si concentrano sull’osservazione che molte interazioni non richiedono un consenso rigoroso per essere considerate definitive dalle parti coinvolte. Ad esempio, se un rivenditore e un cliente concordano che un servizio è stato reso adeguatamente, in cambio di un pagamento specificato, non vi è alcun motivo per la conferma di una terza, quarta e quinta parte.

Ciò che conta sono due fattori: (i) la certezza che il pagatore onorerà la propria parte dell’accordo e (ii) che né il pagatore né il beneficiario debbano confidare nel fatto che una terza parte eseguirà la transazione per loro conto.

Questo schema ci consente di considerare la scalabilità off-chain, in cui le transazioni vengono eseguite fuori dalla blockchain principale e successivamente regolate su quest’ultima. Nel rispetto di questo modello: (i) i pagatori devono impegnarsi crittograficamente e irrevocabilmente a trasferire i fondi; (ii) tali fondi devono essere trasferiti in maniera trsustless e, se necessario, la transazione deve essere azionabile on-chain.

Questi criteri sono alla base del Lightning Network di Bitcoin, che è stato (giustamente) oggetto di un’ampia copertura mediatica. Pensalo come a una scheda di un bar: i partecipanti concordano di pagare piccole somme nel corso di una serata, ma regolano i conti solo alla fine della notte. È, ovviamente, una eccessiva semplificazione di Lightning Network.

Lightning è una soluzione innegabilmente positiva per Bitcoin, ha un elevato potenziale per la scalabilità di Bitcoin su Layer 2. Dovuto in parte a un’ampia copertura mediatica, Lightning è spesso visto come una panacea per i problemi di scalabilità di Bitcoin. Allo stesso tempo, sono stati pubblicati numerosi articoli che acclamano “le blockchain killer di Ethereum”, ritenendo che Ethereum non sia in grado di scalare. Semplicemente, questa asserzione è errata.

Innanzitutto Ethereum è più che capace di scalare il volume dei pagamenti, in modo molto simile a Lightning. I canali di pagamento basati su hashed time-lock contract (HTLC) sono altrettanto fattibili su Ethereum, quanto lo sono su Bitcoin, e infatti Ethereum consente strategie multi-hop più innovative e user-friendly rispetto a quanto possibile su Bitcoin, che possono essere implementate più facilmente.

Poiché Bitcoin utilizza un modello UTXO, i fondi devono essere effettivamente trasmessi utilizzando i tradizionali metodi di messaggistica crittografica per effettuare transazioni (anche quelle off-chain). Al contrario, il sistema account di Ethereum consente aggiornamenti off-chain del saldo più semplici e meno costosi.

Ad esempio, l’implementazione di Connext dei canali di pagamento (che gestisce i pagamenti in produzione per Spankchain da alcuni mesi) utilizza “threads”, un’implementazione multi-hop che consente alle parti di trasmettere direttamente tra esse gli aggiornamenti del saldo, piuttosto che basarsi sul routing dei pagamenti hash-locked. Si tratta di un approccio computazionalmente più economico, ugualmente veloce e sicuro che, rispetto a Lightning, è probabilmente più adatto a molti modelli di transazione.

Inoltre, le interazioni contrattuali complesse sono un pò più dispendiose da implementare, poiché lo scripting di bitcoin è alquanto limitante. Il modello UTXO, sebbene sia un metodo eccellente per inviare e ricevere transazioni firmate, da verificare su una rete basata su blockchain, significa che è necessario estendere i propri script per nuovo casi d’uso (ad esempio gli escrow).

Con la generalizzabilità di Ethereum, e la capacità di creare token, registri, asset non fungibili (come CryptoKitties o identificatori digitali per beni di lusso), e altri standard di smart contract accettati dalla comunità, la costruzione di contratti modulari e interoperabili rivolti alla EVM, è possibile senza soluzione di continuità.

State Channels generalizzati

Il supporto per gli smart contract e la EVM, su Ethereum consentono un’ampia varietà di applicazioni che non sono attualmente realizzabili su piattaforme non Turing-complete come Bitcoin, a causa delle sue scelte di architettura e design che riducono la superficie di attacco complessiva, che a loro volta pongono maggiore attenzione sul caso d’uso dei pagamenti peer-to-peer permissionless, come sua caratteristica maggiormente reclamizzata.

Poiché gli script Turing-complete sono più complessi da eseguire rispetto alle transazioni semplici, tali funzionalità aumentano la congestione generale su Ethereum (e fanno sì che le dimensioni dello stato crescano a un ritmo molto più veloce).

Abbiamo già discusso di come i canali di pagamento possano ridurre le fee e la latenza per i pagamenti peer-to-peer, ma Ethereum supporta logiche di transazione molto più complesse, delle quali i canali di pagamento non si occupano.

Gli state channels generalizzati, tuttavia, propongono una soluzione ai problemi di scalabilità associati a complesse interazioni di contratto. Al momento, le interazioni contrattuali “stateful”, che consentono i casi d’uso per i quali Ethereum è conosciuto, devono essere eseguite sulla blockchain. Molti ribassisti su Ethereum ritengono che, man mano che verranno deployati sempre più contratti, le chiamate di funzioni sovraccaricheranno lentamente la rete, facendo schizzare in alto i prezzi del gas.

La scalabilità su Layer 1, che ha ricevuto la maggior parte della copertura mediatica, si chiede come possiamo accogliere un maggior numero di queste complesse interazioni direttamente sulla blockchain. Le soluzioni Layer 2, come gli state channels generalizzati e Plasma (guarda più avanti), si chiedono come possiamo spostare il maggior numero di queste funzioni off-chain, pur mantenendo la sicurezza e l’integrità che ci vengono fornite dalla rete principale (dati alcuni trade-off).

La sicurezza dei canali di pagamento fa leva sulla capacità di ciascuna delle parti di andare on-chain e utilizzare uno smart contract per giudicare e risolvere le controversie. Cioè, i canali di pagamento consentono a due parti di comportarsi come se stessero effettuando transazioni on-chain, anche se non lo stanno facendo.

Poiché hanno la possibilità di andare on-chain in qualsiasi momento (siccome gli aggiornamenti di saldo, che inviano avanti e indietro, portano il peso delle transazioni on-chain), in una controversia il contratto decide semplicemente quale aggiornamento del saldo è più recente, tramite il polling della mainnet. La risoluzione on-chain delle controversie è costosa in termini di tempo e di gas, quindi gli attori razionali eviterebbero questo scenario.

E, se la maggior parte degli state channels utilizzeranno standard sicuri e verificati, potremo creare sistemi interoperabili con “finalità” veloce, che sono legati dalle stesse garanzie crittografiche delle interazioni in mainnet, con un costo del gas drasticamente ridotto, quasi zero.

Istanziazione contrafattuale

L’approccio che stiamo seguendo solleva la seguente domanda: se possiamo incentivare le parti a comportarsi come se esistesse un semplice contratto sulla chain, possiamo fare lo stesso per una logica più complessa? Una strategia è nota come “istanziazione controfattuale”.

Esistono diverse implementazioni, ma ruotano attorno allo stesso principio: lo stato viene trasmesso al framework generalizzato una volta, all’inizio, e può essere mutato in base a un contratto specificato (ma non deployato), quando il canale viene aperto. Anche i casi di controversia sono giudicati dal contratto. Poiché i partecipanti hanno la possibilità di andare on-chain e invocare il contratto, le parti sono incentivate ​​a comportarsi come se effettivamente esistesse.

Gli effetti degli state channels generalizzati che sfruttano l’istanziazione controfattuale saranno duplici:

  1. Le operazioni che implicano contratti che ora possono essere istanziati in modo controfattuale, verranno tutte eseguite off-chain. Il volume dei contratti deployati diminuirà rispetto a quanto avviene ora. Ciò ridurrà la congestione della rete, avvantaggiando i contratti che devono essere deployati on-chain.
  2. Le operazioni che avvengono off-chain negli state channels generalizzati, non richiedono tempi di conferma o fee per il gas. Ciò migliorerà radicalmente l’esperienza utente, e consentirà a Ethereum (nel suo complesso) di gestire volumi di transazioni di ordini di grandezza maggiori.

Connext, Counterfactual, Perun e altri, stanno lavorando attivamente verso i framework degli state channels generalizzati, che affronteranno direttamente la congestione della rete, l’esperienza dell’utente e le problematiche di costo, che molti citano come i talloni di Achille di Ethereum.

Queste soluzioni sono consentite dalle funzionalità degli smart contract, sono significativamente più espandibili delle soluzioni di scalabilità basate sugli UTXO, conservano la sicurezza della blockchain sottostante, e hanno il potenziale per sdoganare i nuovi mercati e le opportunità di business promesse da Ethereum.

Riteniamo che gli state channels generalizzati abbiano il potenziale di essere trasformativi per Ethereum, tanto quanto Serenity. Per via della scarsa accessibilità delle informazioni, o della campagna pubblicitaria inadeguata, non hanno ottenuto la loro dovuta attenzione.

Lightning

Lightning è stato il punto di partenza per i canali di pagamento basati sugli UTXO, gli atomic swap e altre implementazioni. Il lavoro che è stato fatto da Olaoluwa Osuntokun, Joseph Poon e l’intero ecosistema dei ricercatori e degli ingegneri di Lightning, è impressionante.

Ci sono alcune implementazioni funzionanti del protocollo e della specifica di Lightning, incluso il progetto LND (da Lightning Labs, guidato dal suo direttore scientifico, Olaoluwa, e scritto nel linguaggio di programmazione GO) e il progetto C-Lightning (scritto in C).

Al di sopra di interessanti introduzioni, come i “Watchovers” (servizi che osservano i canali di pagamento per evitare le truffe, che, in cambio di una fee, restano in linea in modo che il tuo nodo non debba esserlo), il wallet Neutrino (light client sperimentale di Lightning Labs, scritto anche in GO), ci sono un sacco di altri miglioramenti in fase di sviluppo, man mano che la specifica di Lightning e la comunità degli sviluppatori matura e cresce.

Alcune delle ricerche più impegnative, sono attualmente concentrate su: “Splicing” (deposito/prelievo parziale e deployment del canale parallelo); “Wumbo” (rimozione del limite di capacità del canale); “Pagamenti Multi-Path” (frazionamento di un pagamento per instradarlo attraverso diversi percorsi); “Hidden Destinations” (percorsi pubblici per i pagamenti ai canali privati); e lavoro impegnativo viene compiuto ripetutamente a conferenze e da team indipendenti in tutto il mondo.

Il lavoro da parte del team di Lightning e delle chain con soluzioni di scalabilità basate sugli UTXO – utilizzando alcune implementazioni all’avanguardia delle criptovalute -, non è un’impresa da poco e non può essere sminuita. Spesso, il problema risiede nel fatto che le persone cercano di comparare direttamente Lightning e le misure di scalabilità Layer 2 di Ethereum, utilizzando simili regole che non considerano i trade-off e le possibilità uniche offerte dalle due diverse soluzioni, per via della peculiare architettura della blockchain sottostante (cioè il modello UTXO contro il modello account di Ethereum).

Plasma

Gli state channel generalizzati non sono l’unica opzione di scalabilità per Ethereum. Plasma è una soluzione di scalabilità Layer 2 che, in tandem con gli state channels, cerca di fornire addizionale throughput e finalità, ma con alcuni trade-off aggiuntivi.

Pensa a Plasma come una sorta di “proto-chain”, che cerca di imitare, il quanto più possibile, l’integrità e la sicurezza della chain principale, solo con una componente di costo variabile, che è tipicamente superiore quando confrontata con gli state channels (a causa della replicazione della maggior parte della funzionalità della chain principale, su un nuovo substrato sopra di essa).

Plasma prende l’interezza dello stato off-chain, mantenendo uno stato completo, il cui hash viene inviato alla chain principale (che ha il suo insieme di trade-off di rischio, sebbene sia costantemente migliorato attraverso una ricerca aggiuntiva).

Sebbene il throughput possa essere superiore rispetto alla chain principale, a differenza degli state channels in cui non esiste un algoritmo di consenso formale, le chain di Plasma possono avere il loro particolare algoritmo di consenso, insieme a dei block-time personalizzati (con la propria serie di trade-off).

Sebbene il throughput e la finalità non siano così veloci, sono molto più raggiungibili rispetto agli state channels, poiché chiunque può accedere allo stato della chain principale che è stato broadcastato, mentre negli state channels sono disponibili solo se c’è accordo tra le parti (nella maggior parte delle implementazioni correnti).

Inoltre, gli state channels non sono più disponibili dopo la chiusura del canale, il che li rende “macchine economiche” con una durata di vita limitata, essendo creati allo scopo di essere semi-permanenti. Tuttavia, in Plasma, dal momento che bisogna salvare sulla chain principale ogni interazione di stato della chain figlia, i costi sono più elevati, a seconda della versione di Plasma che si decide di implementare.

Con i passi avanti compiuti da molti team distribuiti a livello globale, siamo sicuri che si presenterà uno standard comune, con una insieme ragionevole di trade-off che possono essere applicati a una vasta gamma di casi d’uso.

Il potere degli standard interoperabili

La liquidità “non custodiale” – e come trasmetterla in modo più efficiente e sicuro in una serie di scenari diversi, che coinvolgono più partecipanti – è una scoperta in divenire, che continua ad ampliarsi sulla disciplina emergente della cripto-economia e su come i vari meccanismi operano in condizioni antagonistiche.

Standard come ERC-20 (per i token) e ERC-721 (per gli asset non fungibili) rendono la tecnologia di scalabilità Layer 2 di Ethereum, e le dApps, più socialmente sicuri, dato che ci sono norme accettate dalla comunità e buone pratiche intorno a quali standard implementare per determinati casi d’uso.

È un aspetto particolarmente importante quando questi diversi standard – che cercano di interagire l’uno con l’altro in modo fluido, per far funzionare la “finanza decentralizzata” – possono comunicare in modo interoperabile, con il minimo di attrito e costi.

Le interazioni prive di frizioni e le economie che scaturiscono dalla nuova interoperabilità tra token, asset non fungibili e scalabilità Layer 2, generano ulteriore sicurezza per la rete Ethereum nel suo complesso, poiché tutti i partecipanti sono ora coinvolti in attività economiche complesse sui layer aggiuntivi, tutti costruiti su standard sicuri, che sono stati verificati e accettati dalla più ampia comunità tecnica.

L’importanza dell’architettura non custodiale, combinata con il percorso di minor resistenza alla funzionalità più espandibile e generalizzabile, non può essere sminuita. Queste sono componenti cruciali per dare vita a “macchine economiche” nuove e innovative che, a causa di costi, regolamentazioni e limiti computazionali, una volta erano ritenute impossibili da implementare nel mondo reale.

Il tempo per una nuova narrativa

Scalare le blockchain è difficile, Ethereum non fa eccezione. Ma esaltare le blockchain “ethereum-killer”, o le sue alternative preesistenti, sulla presunzione che Ethereum non possa scalare, minimizza il notevole lavoro che la comunità di Ethereum sta svolgendo sulla tecnologia Layer 2.

Le soluzioni Layer 1 sono in cantiere, ed è probabile che più avanti si riveleranno trasformative per la rete, ma le soluzioni Layer 2 stanno raggiungendo il mercato adesso. La narrativa secondo cui Ethereum non può scalare, e l’idea che le soluzioni Layer 1 siano gli unici piani per scalare la rete, sono fastidiose e vengono quotidianamente confutate negli ambienti di produzione.

Oggi, Ethereum è una piattaforma lenta e inarrestabile per denaro programmabile. Il potenziale di un tale sistema è evidente. Un sistema finanziario completamente nuovo potrebbe essere costruito sulla base di Ethereum, e le soluzioni Layer 2 apriranno la strada a nuovi mercati radicali che sfruttano questo sistema finanziario decentralizzato.

Il trasferimento di valore, la governance, nuovi tipi di mercati e strutture di incentivi, il coordinamento della comunità e persino un’adeguata implementazione della politica fiscale, sono possibili su Ethereum.

Gli sviluppatori di Ethereum vedono questo futuro e stanno creando le dApps per renderlo possibile. Altri sviluppatori di Ethereum, per far sì che questo futuro diventi realtà, stanno costruendo i protocolli per rendere la rete utilizzabile su larga scala a sufficienza.

Questo articolo non va inteso come una critica verso implementazioni blockchain alternative, molte delle quali stanno rendendo all’avanguardia la ricerca sulle soluzioni crittografiche applicate alla blockchain, come sopra indicato. Né è un’argomentazione per ICO, di imbonimento e hype fuorviante. Piuttosto, è un’analisi sulla scalabilità di Ethereum, per un futuro economico decentralizzato che utilizza la blockchain di Ethereum come layer per il settlment e facilita la maggior parte delle transazioni con le tecnologie Layer 2.

È un argomentazione per l’Ethereum che vediamo, per cui si auspica che otterrà agli occhi del pubblico quello che gli è dovuto.

 

Articolo originale: Coindesk



3 VIDEO GRATUITI DALLA DM CRIPTO












Ti invieremo i
VIDEO GRATUITI
e in più, n
elle email successive, il frutto delle nostre ricerche più avanzate sulle criptovalute e i nostri servizi legati ad esse.

Tratteremo i tuoi
dati personali
con la massima cura e in conformità della normativa privacy GDPR UE2016/679. E potrai disiscriverti in qualsiasi momento con un semplice click.


Condividi
  • 21
    Shares

CATEGORIE:

Codice e sviluppo


Giuseppe Brogna

Giuseppe è laureato in giurisprudenza, da sempre appassionato di tecnologia e studioso di tematiche economiche. Stimolato dal potenziale impatto economico e sociale, si approccia al mondo delle DLT; matura particolari interessi nella nuova finanza hitech legata alle tecnologie del ledger distribuito.


Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Condividi questo articolo

Invia questo articolo ad un amico