L’accordo di Barry Silbert: ecco perché SegWit + 2mb è l’upgrade giusto15 minuti

Contenuti dell’articolo:

1) L’accordo di Barry Silbert al Consensus 2017

2) Le reazioni da parte della community

3) Perché è auspicabile anche un aumento del blocco: i problemi del secondo layer

1. L’accordo di Barry Silbert al Consensus 2017

Come ho spiegato in questo articolo, Bitcoin è oggi a un punto di svolta della sua storia. L’utilizzo da parte della rete è arrivato a un livello tale che il Bitcoin non è più in grado di fungere da strumento di pagamento, per via dell’eccessivo costo di transazione. Finché non si risolve il problema di scalabilità, più utenti usano bitcoin, maggiori sono i costi di transazione per ciascuno. Ho più volte accusato quelli che ho chiamato “miners ostruzionisti” di bloccare lo sviluppo di Bitcoin, facendo del male a tutta la rete, per il loro ostruzionismo all’upgrade Segregated Witness (SegWit), che apre le porte a soluzioni di scalabilità.

Pochi giorni fa, finalmente, è arrivata la svolta. In anteprima assoluta, con due giorni di anticipo sull’annuncio ufficiale, su questo blog avete ricevuto le anticipazioni di una delle notizie più importanti dell’anno, ovvero l’accordo preso al Consensus 2017, che chiameremo accordo di “Silbert”, dal nome dell’organizzatore.

In questo accordo, numerosi miners riuniti, inclusi quelli che ho chiamato “miners ostruzionisti”, per un totale superiore all’80% della potenza di calcolo che sostiene la rete, affermano di voler sostenere l’upgrade a SegWit, a patto che si aumenti la capacità del blocco a 2mb entro 6 mesi. L’accordo è stato siglato da una fetta importantissima dell’ecosistema Bitcoin:

– 58 imprese di 22 diversi paesi

– 28% della potenza computazionale della rete (miners)

– aziende che sono coinvolte (in modo diretto o indiretto) in 5,1 miliardi di dollari al mese di transazioni registrate sulla blockchain

– Aziende rappresentative di 20,5 milioni di wallets

L’upgrade proposto dalle parti coinvolte non ha al momento una definizione tecnica precisa, ha piuttosto la forma di una dichiarazione d’intenti fatta a tutta la community, che espressamente invita qualunque team a “dedicare supporto tecnico e ingegneristico”. Dati i precedenti, si tratta di un’apertura a sorpresa, proclamata con toni di conciliazione: “Invitiamo tutte le imprese, miners, sviluppatori e utenti a unirsi a noi e preparare bitcoin al futuro”.

Alla tavola rotonda non erano però presenti i principali sviluppatori che hanno lavorato più recentemente al software Bitcoin Core, ovvero il software scaricato e utilizzato dal 95% dei full nodes. Questi full nodes sono già pronti all’upgrade a SegWit, ma la build di Bitcoin Core che vi è installata non prevede l’espansione del blocco a 2mb.

Mancando i dettagli tecnici, si può ipotizzare che l’upgrade verrà effettuato in uno di questi due modi:

– I miners dirigono l’hash power segnalando l’attuale deploy di SegWit, ottenendone quindi immediatamente l’attivazione. Solo successivamente, entro i 6 mesi, tutte le parti firmatarie si impegneranno a diffondere una build che preveda l’upgrade del protocollo a 2mb di blocco, che sarà supportata dall’hash power di almeno tutti i miners firmatari

Oppure

– Verrà rilasciata una nuova build che preveda l’aggiornamento a SegWit e, contemporaneamente, preveda un aumento del blocco a 2mb entro i 6 mesi. Se questa build non viene installata e supportata dai miners, SegWit non verrà quindi approvato.

Dato che SegWit + 2mb è chiaramente una soluzione di compromesso fra interessi contrastanti, non ci si aspetta che i miners propendano per la soluzione 1), dato che potrebbe risultare un autogoal: se SegWit venisse approvato immediatamente, alcune parti potrebbero non rispettare l’accordo e l’hard fork a 2mb non essere mai approvato.

Se si intende effettuare l’upgrade con la soluzione 2, è necessario il deploy di una nuova build con SegWit + 2mb e che questa venga installata sulla maggioranza di full nodes. Se i full nodes non la installassero, non riconoscerebbero le transazioni convalidate dai miners. In quel caso verrebbero a crearsi in effetti 2 monete diverse, quella accettata dai full nodes che non hanno installato la nuova build, e quella invece accettata da nodi che hanno fatto l’upgrade ai 2mb di blocco: scoppierebbe il caos fra gli utenti che non vedono più convalidate numerose transazioni, mentre gli exchange dovrebbero introdurre una quotazione diversa fra le due monete e dar loro un nome distinto. Il crollo del valore di Bitcoin sarebbe inevitabile.

Per questa ragione, è bene che l’upgrade sia fatto di concerto con la community tutta.

2. Le reazioni da parte della community

La soluzione migliore sarebbe che lo stesso Bitcoin Core venisse aggiornato assecondando la proposta del Consensus: essendo Core il software di riferimento per la stragrande maggioranza della rete, sarebbe più facile ottenere l’upgrade della maggioranza di nodi in poco tempo. Purtroppo, è difficile che Core possa sostenere as-is la proposta uscita dalla tavola rotonda di Silbert. Infatti, come afferma il developer Matt Corallo, un hard fork entro 6 mesi è un periodo di tempo “altamente irrealistico”. Ciononostante, Corallo stesso specifica di approvare il “sentiment” e gli scopi dell’accordo: “sono del tutto a supporto degli scopi dichiarati, assumendo, ovviamente, che ci sia consenso nella community di utenti verso questa direzione, cosa che penso sia possibile” (vedi twitter)

Dal momento che manca il dettaglio tecnico della proposta, c’è ancora margine per strutturarla nel modo più inclusivo e conciliante possibile ed è questa la direzione in cui bisogna andare. Abbiamo definito il “cosa” su cui siamo d’accordo (Segwit+2mb), non resta che definire il “come” e, se fosse necessario, rivedere il “quando”.

Purtroppo, a remare contro ci sono dei membri della community arroccati su posizioni estremiste, come il CEO dell’italiana BlockchainLab Giacomo Zucco, il quale addirittura dichiara che eviterà qualsiasi ulteriore relazione professionale con le aziende firmatarie dell’accordo di Silbert, come se fossero il male assoluto:

Zucco vede l’accordo come un “attacco” a Bitcoin e accusa persino BitFury, storica pool a favore dell’upgrade a SegWit, di far parte degli attaccanti. Un tweet davvero eccessivo, per cui Zucco viene redarguito addirittura da Adam Back in persona.

Vale la pena commentare anche l’affermazione di Zucco in merito a UASF e POW. L’UASF, o User Activated Soft Fork, è l’upgrade a SegWit fatto da parte degli utenti. Ovvero un upgrade per cui i nodi riconoscono solo le transazioni validate dai miners con blocchi SegWit. Se un buon numero di full nodes supportasse l’UASF, gli utenti riuscirebbero addirittura a costringere i miners all’adozione di SegWit, poiché quei miners che non creano blocchi SegWit sarebbero, alla lunga, tagliati fuori dal mercato. Vista la situazione di stallo e l’urgenza di ottenere una soluzione di scalabilità, io stesso, prima dell’accordo di Silbert, sarei stato d’accordo per una UASF, e convengo che rimane una soluzione valida se le parti presenti alla stipula dovessero dimostrare di non considerare l’accordo vincolante e si rivelassero ben poco intenzionate a portarlo avanti. Tuttavia, non condivido il fatto di assumere una posizione così divisiva, espressa ad accordo appena stipulato e quando ancora non è chiaro come evolverà la situazione.

Per quanto riguarda un cambio di Proof of Work (POW), se davvero venisse mai approvato un upgrade al protocollo di questo tipo, comporterebbe che il lavoro dei miners (work) che serve a provare (proof) la validità di un blocco creato, non può più essere svolto efficacemente con lo stesso tipo di hardware. I miners sarebbero costretti a rinnovare il parco macchine, con un elevato dispendio economico. Questo andrebbe a detrimento di quei soggetti che hanno investito maggiormente nell’ecosistema Bitcoin (tutti i miners, inclusi quelli pro-segwit), senza effettivamente migliorare in alcun modo la decentralizzazione del sistema. Infatti anche nel nuovo regime di POW, in un periodo relativamente breve, ci saranno aziende in grado di specializzarsi nel mining. Un cambio di POW potrebbe anche essere sensato, in futuro, ma solo se la soluzione trovata impedisse la creazione di monopoli o oligopoli naturali, come accade oggi nel libero mercato del mining. Al momento, una soluzione tecnica condivisa per risolvere questo “problema” non esiste, perciò cambiare POW sarebbe solo un dispetto fatto verso alcuni stakeholders. Una vendetta di questo tipo fine a se stessa non ha senso, nonostante Jihan Wu* sia ufficialmente candidato al concorso “miglior super-cattivo di sempre”: vedi qui.

* fondatore di Bitmain, casa produttrice di Asics per il mining e proprietaria di Antpool, la più potente mining pool al mondo.

3. Perché è auspicabile anche un aumento del blocco: i problemi del secondo layer

Come spiegavo in questo articolo, un aumento del blocco comporta un aumento del costo per far girare un full node. Questo può costituire una minaccia alla decentralizzazione della rete, poiché solo chi ha una disponibilità economica rilevante sarà in grado di mantenere un full node. Il rischio è che la gestione della rete rimanga nelle mani di poche entità in grado di controllarla a piacimento. Tuttavia, un aumento di 2mb non è rischioso, poiché la tecnologia esistente oggi permetterebbe all’utente medio di mantenere un full node a costi ancora contenuti. In poche parole, aumentando il blocco a 2mb, è assai improbabile che qualche utente dismetta il proprio full node per il semplice fatto di non riuscire più a gestirlo da un punto di vista economico.

Ciononostante, quello che molti pensano è che, una volta approvato SegWit, la tecnologia Lightning Network di per sé renderà totalmente inutile un aumento del blocco, permettendo la scalabilità a livelli esponenziali, al punto che non saranno necessari altri interventi correttivi al protocollo. Sotto quest’ottica, la migliore soluzione sarebbe mantenere il blocco più piccolo possibile, così da poter avere full nodes estremamente economici. Chi ha una posizione di assoluta contrarietà ad un aumento dei blocchi, afferma che non bisogna cedere ad alcun compromesso sotto il ricatto di alcuni poteri forti (i miners con il proprio hashrate, o potenza di calcolo), perché anche se un aumento a 2mb non è un pericolo, si creerebbe un precedente per cui la rete ha ceduto ad attacchi o ricatti da parte di grossi stakeholder. Se così fosse, player del calibro di Stati nazione o istituzioni sovranazionali (banche centrali incluse) potrebbero avere una chance di manipolare il sistema e l’indipendenza della rete sarebbe solo un miraggio.

Ma c’è un errore di fondo in questa visione ed è dovuto a un eccessivo ottimismo verso l’impiego della tecnologia Lightning Network (LN). L’aumento del blocco è in realtà auspicabile, se non necessario, e chi lo propone non è un attaccante, ma una semplice fazione coinvolta nel processo politico-decisionale per la gestione della rete Bitcoin. La straordinaria caratteristica del Bitcoin rispetto ad altri sistemi monetari o istituzionali è proprio il processo politico-decisionale che sta dietro alla gestione della rete. Non esistono tirannie della maggioranza, ci sono solo due modi per cambiare: o una decisione è presa all’unanimità, oppure chi è scontento opta per l’exit, creando il proprio fork, la propria moneta. È un sistema puramente volontaristico e non coercitivo, insomma l’incarnazione dell’ideale libertario di libero mercato. E in questo contesto, è nel pieno interesse della community aumentare il blocco, almeno finché questo aumento non ha un impatto negativo sul numero di full nodes (attuali o potenziali) che fanno girare la rete. In poche parole, maggiore è il progresso tecnologico (che rende meno dispendioso lo storage per conservare la blockchain e la banda per trasmettere i dati agli altri nodi) maggiore è l’aumento auspicabile del blocco. Per dirla in un altro modo, nel corso del tempo è un bene che il blocco aumenti a patto che questo aumento non impedisca, per ragioni economiche, all’utente medio Statunitense, Italiano, Cinese o Nigeriano, di far girare il proprio full node. Il team di sviluppo di Bitcoin Core sa bene che aumentare il blocksize è un passaggio che prima o poi si dovrà affrontare:

“Finally–at some point the capacity increases from the above may not be enough. Delivery on relay improvements, segwit fraud proofs, dynamic block size controls, and other advances in technology will reduce the risk and therefore controversy around moderate block size increase proposals (such as 2/4/8 rescaled to respect segwit’s increase). Bitcoin will be able to move forward with these increases when improvements and understanding render their risks widely acceptable relative to the risks of not deploying them” (fonte)

Lightning Network richiederà molto tempo prima di funzionare a regime. La teoria dei 6 gradi di separazione non funziona per un network nuovo, come LN, che ha bisogno di tempo per crescere, non solo dal punto di vista sociale, ma anche tecnologico. Siamo ancora lontani dalla release di un software LN gestibile da un utente medio, quindi con un’interfaccia grafica facilmente accessibile e che non richieda skills di coding. Tanto più siamo lontani dalla release di un software che l’utente medio possa utilizzare serenamente per fungere da nodo intermediario, senza la paura di incorrere in perdite dovute alla trasmissione onchain di stati (di committment transactions) ormai vecchi. Per chi vuole approfondire, mi spiego più nel dettaglio (chi non conosce LN può studiare questa mia guida):

ipotizziamo che Alice debba ricevere un pagamento di 2 btc da Charlie, e l’intermediario è Bob. Alice ha aperto un canale con Bob, in cui l’ultimo status (l’ultima commitment) presenta un balance di 5btc ritirabili da Alice e 5btc da Bob. Nel canale viene creata una nuova committment ove il balance è 7btc per Alice e 3btc per Bob. Alice può trasmettere onchain questo nuovo balance solo se conosce l’image data da Charlie, che effettivamente conosce. Quindi decide di trasmettere onchain. Dall’altro lato, Bob ha aperto un canale con Charlie, ove Charlie trasferisce 2btc a Bob. Charlie tuttavia è malvagio, e a suo rischio e pericolo trasmette onchain una commitment precedente del canale fra Charlie e Bob, dove Charlie possiede ancora i 2btc. Se Bob è distratto, impossibilitato, o offline, Alice riceverà i suoi btc, Charlie non avrà pagato, e Bob ci avrà rimesso 2btc. Bob invece avrebbe dovuto trasmettere la Breach Remedy transaction per recuperare i suoi 2btc (più il resto dei fondi presenti sul canale con Charlie, se ce ne sono). Il problema di Bob è che deve essere attento e vigile per compiere questa operazione. Se il rischio di Bob è tanto alto (perdere 2btc) la fee che farà pagare ad Alice e /o Charlie per la transazione sarà molto alta. Ovviamente, non sarà Bob a dover occuparsi manualmente di trasmettere onchain la Breach Remedy, bensì il suo software, per questo motivo la speranza è che le fee su LN saranno basse. Ma ora bisognerebbe chiedersi quando sarà rilasciato un software così sofisticato e sicuro, utilizzabile da utenti senza particolari capacità informatiche? È molto probabile che inizialmente siano solo dei grossi hub a fungere da intermediari, e non solo perché saranno specializzati nella chiusura dei canali per conto degli utenti in caso di tentativi di frode, ma anche perché gli utenti hanno convenienza a utilizzare gli stessi hub per una vantaggio di network: usando tutti lo stesso intermediario, si trova più facilmente un canale già percorribile, senza dover effettuare costose transazioni onchain.

Insomma, è probabile che, a parte quanto conserveremo sui nostri paper wallet, tutti gli altri btc li terremo già su dei “wallet” che in realtà sono multisignature funding transaction con il wallet provider, ovvero delle transazioni onchain di apertura di canale. Depositare soldi sul nostro wallet significherà in effetti già aprire un canale e avere quindi una strada offchain per inviare e ricevere denaro col resto de mondo, attraverso il provider del wallet che fungerà da grosso hub. Se il blocksize della blockchain rimane a 1mb e la rete dovesse essere intasata prima che LN entri a regime in modo diffuso e decentralizzato (cosa probabile dati i tempi di attesa prima di una buona release), avremmo un grosso problema:

– Un singolo hub, o pochi singoli hub, potrebbero monopolizzare il mercato di intermediazione, facendo pagare fee alte. Gli utenti rimarrebbero sul canale dell’hub, perché cambiare canale, rivolgendosi a un altro hub più economico o aprendo canali diretti fra utenti, costerebbe troppo, data la fee ancora più elevata per effettuare una transazione onchain di apertura di un nuovo canale. Inoltre, l’utente sarebbe disincentivato dal lasciare l’hub intermediario, per via del rischio di non avere più un collegamento diretto offchain con i propri contatti, cosa che lo costringerebbe a fare ulteriori costose transazioni onchain.

– Un attacco ai server del wallet provider (il grosso intermediario) potrebbe rallentare improvvisamente tutta la rete, costringendo gli utenti a transazioni dirette (e costose) onchain. Nel peggiore dei casi, potrebbe impedire la trasmissione di Breach Remedy transctions onchain, causando il furto di molti btc.

Per esemplificare quanto espresso, pensiamo al rapporto oggi fra un utente e l’operatore telefonico. Se l’operatore ha costi troppo elevati (fee richieste dal canale), l’utente ha la possibilità di affidarsi a un competitor, cioè cambiare operatore telefonico. Per farlo, dovrà sostenere un costo per il cambiamento, ad esempio l’attivazione della sim, o la recessione dal contratto con il vecchio operatore (la transazione onchain). Inoltre, cambiando operatore, potrebbe perdere il “numero amico” con cui poteva parlare senza costi (la perdita di possibile network se il canale alternativo ha meno connessioni).

La speranza è che a un certo punto, con una rete LN ben diffusa e decentralizzata, ci saranno molte più interconnessioni capillari, gli utenti avranno molti canali aperti, insomma come se tutti avessero più telefoni e operatori diversi. Purtroppo però l’effetto network potrebbe prevalere e un grosso hub potrà far pagare delle fee più alte per le transazioni rispetto a canali più economici, ma con meno connessioni.  Se le transazioni offchain sono molto costose sin da subito, il costo di “uscita” da un canale potrebbe scoraggiare molto l’utente ad aprire canali alternativi. Come se ci fossero dei costi burocratici per il passaggio di operatore. La blockchain è un buon burocrate, che decreta che il contratto con l’operatore è rescisso. Più centralizzato è il mining, maggiori sono i rischi che questo burocrate sia censurabile o corruttibile, ma anche minori sono i costi da pagare al burocrate per la recessione del contratto. Viceversa se si mantiene una maggiore decentralizzazione del mining (cioè se il blocksize rimane limitato).

Alla luce di quanto espresso, la soluzione di politica monetaria che gli utenti devono cercare di far approvare è la seguente: il blocco deve crescere man mano che la tecnologia progredisce, ma non deve essere mai più grande di quanto può essere gestito dall’hardware e dalla banda accessibili a un utente medio. Insomma si deve mantenere un grado sufficiente di decentralizzazione. Deve anche essere grande a sufficienza perché possa dare la possibilità agli utenti di “cambiare operatore telefonico”, impedendo un’eccessiva centralizzazione del layer due. Inevitabilmente, chi sviluppa soluzioni sul layer 2 ed è interessato esclusivamente al profitto personale, punterà a ridurre il blocco il più possibile e ad accentrare tutte le transazioni degli utenti sui propri canali, i miner invece esclusivamente interessati al profitto personale vorranno un blocco più grande, così da permettere agli utenti di effettuare tutte le transazioni onchain e pagare fee solo ai miners, e non agli hub sviluppati sul layer 2. In quest’ottica, a ben vedere e a essere maliziosi, gli utenti dovrebbero guardare con attenzione sia alle proposte dei miners che degli sviluppatori, entrambe le fazioni infatti potrebbero avere un conflitto di interessi. In realtà, io sono convinto che a guidare il dibattito sullo scaling non siano tanto interessi personali, quanto piuttosto contrapposizioni ideologiche dovute per lo più a visioni miopi e limitate su questioni puramente tecniche.

Nel frattempo, Calvin Rechner ha pubblicato una bozza di Bitcoin Improvement Proposal (BIP) per dare seguito all’accordo di Silbert.

Si aprano le danze.

Iscriviti alla mailing list per ricevere una notifica ad ogni nuovo articolo pubblicato!