Uno dei dibattiti piu importanti nell’ambito della blockchain riguarda la preferenza tra hard forks o soft forks al momento di un avanzamento di protocollo. La semplice differenza tra i due è che una soft fork cambia i meccanismi di un protocollo reducendo strettamente l’insieme di transazioni valide, in modo tale che i nodi che seguono ancora le vecchie regole riescano comunque a “infilarsi” nella nuova catena (ammesso, ovviamente, che la maggior parte dei minatori/implementatori segua la fork). L’hard fork invece permette ai vecchi (e invalidi) blocchi di diventare validi, quindi gli users dovranno per forza aggionrare il client per stare sulla nuova catena “hard forked”. Ci sono anche due sottotipi di hard fork: strettamente espansiva, che espande strettamente l’insieme di transazioni valide, e quindi le vecchie regole appaiono come una soft fork rispetto alle nuove, e hard forks bilaterali, dove i due insieme di regole diventano incompatibili.

Qui sotto si puo vedere un diagramma di Venn che illustra i tipi di fork:

 

I benefici che solitamente si contano rispetto alle due sono:

  • Una hard fork permette agli sviluppatori molta piu flessibilita nell’aggiornamento del protocollo, visto che non devono preoccuparsi di vedere se le nuove regole possono essere inserite nelle vecchie
  • Le soft forks invece sono molto piu convenienti per gli users, visto che gli utenti non devono aggiornare il sistema per rimanere sulla catena
  • E’ molto meno probabile che le soft forks portino a uno split della catena (una “divisione”).
  • Le soft forks in realta richiedono solamente il consenso da parte di minatori/validatori. Le hard forks invece richedono un opt-it consenso da parte degli utenti.

A parte questo, una delle maggiori critiche spinte verso le hard fork è che queste ultime sono “coercitive”. La coercizione non è di forza fisica, bensi una coercizione che avviene attraverso il network effect. Questo significa che, se il network cambia regole da X a Y, anche se tu personalmente preferiresti X, se la maggior parte degli utenti preferisce Y e passa a Y anche tu dovrai passare a Y nonostante tu lo disapprovi, per essere sullo stesso network di tutti gli altri.

Solitamente, chi propone una hard fork è deriso e si pensa spesso che si voglia fare un “take-over ostile” di un network e quindi forzare gli utenti a seguirlo. Inoltre, il rischio di divisione di catena è abbastanza per definire le hard forks come “non sicure”.

Il punto di vista di Vitalik Buterin (creatore di Ethereum)

Secondo me questi criticismi sono sbagliati. E non sto specificatamente parlando di Ethereum, o Bitcoin, bensi semplicemente delle proprieta generali di certi sistemi. E ricordiamoci che stiamo parlando di cambi che in questi casi sono secondo “consenso”, perche se fossero cambi senza bisogno di consenso, non ci sarebbe nessun problema e i cambi potrebbero essere svolti facilmente.

Prima di tutto, discutiamo la questione di coercizione. Sia le hard forks sia le soft forks cambiano il protocollo in modi che potrebbero non piacere ad alcuni utenti. Ogni cambiamento di protocollo che non abbia il 100% del supporto lo farà. Quindi, entrambi i tipi di forks sono coercitivi, nel senso di network effect della parola.

Comunque, c’è una differenza essenziale tra le due forks: le hard fork sono opt in, mentre le soft permettono agli utenti di non optare in. Ovvero, affinche un utente decida di partecipare ad un hard fork, deve installare personalmente il pacchetto software che implemente le regole della fork, e l’insieme di utenti che non è d’accordo con un cambio di regole puo teoricamente stare semplicemente nella vecchia catena, e in pratica tale evento è gia accaduto. Questo è vero sia nel caso di hard fork espansive e hard fork bilaterali. Nel caso di soft fork invece, se la fork vince, la catena rimane sempre la stessa. Questo vuol dire che nel caso di soft fork, è preferita la coercizione rispetto alla successione. Dal mio punto di vista morale, io preferisco una secessione che una coercizione, pero c’è chi non la pensa come me ( e per esempio, considera i network effect come il fattore predominante). Se dovessi tirare a indovinare, nonostante cio appena detto, perche le soft fork sono considerate “Meno coercitive” delle hard fork, direi che è perche sembra che una hard fork “forzi” l’utente a installare l’aggiornamento di software mentre nella soft fork l’utente non debba fare nulla. Tuttavia, questa intuizione è sbagliata: quello che importa non è che un utente individuale debba fare uno step burocratico di schiacciare il pulsante “scarica”, ma invece vedere se l’utente è forzato ad accettare un cambio nelle regole di procollo che egli possa o no accettare. Comunque, detto tutto cio, appare come se entrambe le fork siano coercitive alla fine, e che sia l’hard fork a preservare in qualche modo la liberta dell’utente.

 

Proviamo ora a guardare a forks che sono state molto controverse, in particolare dove sono finite in conflitto le preferenze di minatori e utenti. Ci sono tre casi qui: (i) hard forks bilaterali, (ii) hard forks strettamente espansive e (iii) le cosiddette “soft forks attivate da utente” (user activated soft forks). Una quarta categoria si trova quando i minatori attivano una soft fork senza il consenso degli utenti, ma ci arriveremo dopo.

Prima di tutto, parliamo di hard forks bilaterali. Nel miglior del casi, la situazione è semplice. Le due monete sono scambiate sui mercati e sono i compratori a decidere il valore relativo delle due. Possiamo guardare il caso ETC/ETH (Ethereum Classic/Ethereum), dove si trovano diverse prove che i minatori collocano la loro potenza di calcolo sulla moneta che da loro il maggior profitto, fregandosene delle proprie idee rispetto alle monete.

Anche se alcuni minatori professano preferenze ideologiche verso uno dei due lati, è molto probabile che ci saranno abbastanza minatori a dividersi i profitti dovuti al ratio di prezzo e hashpower, e dunque le monete finiranno per essere allineate. Se un cartello di minatori decide di non minare su una catena, possono succedere due cose, visti i grandi incentivi di non minare anche da parte degli altri.

La prima è la possibilita che, per colpa di un aggiustamento inefficiente dell’algoritmo di difficolta, il valore del mining della moneta scenda, visto che il prezzo della moneta scende e la difficolta nel minare rimane la stessa. Se la difficolta rimane la stessa e quindi non si riesce a compensare, il mining diventa non profittevole. Se non ci sono minatori che sono disposti a minare perdendoci soldi, la difficolta non riesce a riaggiustarsi. Questo è stato il caso di Bitcoin. In questo caso, la catena minore non riesce a rialzarsi e quindi piano piano morirà.

Il secondo caso invece succede se la disparità è molto grande. In questo caso la catena grande può attaccare la catena minore (51% attack). Anche nel caso di uno split ETH/ETC con un ration di 10:1, questo non è comunque succcesso. Quindi possiamo dire che non è una cosa che succeda tutti i giiorno. Comunque, è sempre una possibilita se i minatori della catena dominante preferiscono la coercizione alla secessione.

Ora, diamo un’occhiata a hard forks strettamente espansive. In un SEHF, esiste la proprietà che la catena non forked è valida sotto le regole della forked, e quindi se la fork ha un prezzo piu basso della catna non forked, essa avrà meno hashpower che quella non forked, e quindi quest’ultima finira per essere la catena accettata come la catena piu lunga sia dal client originale e sia dal client che segue le regole della forked e quindi la forked chain sarà eliminata (…lo so… non è un concetto semplicissimo!).

Esiste un dibattito che dice che se esiste un interesse forte verso il non successo di una tale fork, che quindi la forked chain sia annichilita, il prezzo della moneta sulla catena forked si abbassera sempre di piu, facendo in modo che salgano le possibilita che la catena venga annichilita.

Gli sviluppatori di Bitcoin Unlimited suggeriscono di risolvere il problema rendendo la hard fork bilaterale manualmente dopo che la fork accade, ma una scelta migliore sarebbe di costruirla direttamente in maniera bilaterale; per esempio, nel caso di bitcoin, una persona puo aggiungere una regola che banni qualsiasi opcode non usato, poi fare una transazione che contenga l’opcode sulla catena non forked in modo tale che sotto le regole della fork la catena non forked rimanga per sempre considerata invalida. Nel caso di Ethereum, visti i vari dettagli su come funzionano i calcoli, quasi tutte le hard forks sono automaticamente bilaterali. Altre catene possono avere invece diverse proprietà, secondo le loro architetture.

L’ultimo tipo di fork che era stato menzionato sopra è la soft fork attivata dall’user (user-activated). In una UASF, gli utenti seguono le regole di una soft fork senza preoccuparsi del consenso dei minatori. Questi ultimi dovrebbero seguire gli utenti per il loro mero interesse economico. Se tanti utenti non seguono le UASF, ci sarà quindi una divisione di moneta che porterà allo stesso identico scenario che avremmo con una hard fork strettamente espansiva a parte che, la stessa pressione dovuta al “rischio di annichilimento” sfavorisce la forked chain nella hard fork strettamente espansiva. Anche se una UASF è opt-in (ovvero, è l’utente che decide se parteciparci), usa l’asimmetria economica per dirigersi verso il suo successo (anche se, se la UASF è molto impopolare non avrà successo e quindi non porterà a a una divisione di catena).

Tuttavia, le UASF sono un gioco molto pericoloso. Per esempio, supponiamo che gli sviluppatori di un progetto vogliono sviluppare un patch che converta un opcode non utilizzato che prima accettava tutte le transazioni in un opcode che accetta solamente transazioni che seguono le regole di un particolare nuovo feature, anche se è un feature che è politicamente e tecnicamente controverso e che non piace ai minatori. Questi ultimi hanno un modo intelligente per combatterlo: possono infatti tutti implementare una soft fork attivata dai minatori che non manda in porto tutte le transazioni che sono fatte usando il nuovo feature.

Ora, abbiamo un insieme di tre regole:

1)      La regola originale dove c’è l’opcode X è sempre valida

2)      La regola dove l’opcode X è valida solamente se il resto delle transazioni segue le nuove regole

3)      La regola dove c’è l’opcode X è sempre invalida

Nota che se (2) è una soft fork con rispetto a (1), e (3) è una soft fork con rispetto a (2). Ora c’è una forte pressione economica in favore di (3) e la soft fork fallisce nel suo obbiettivo.

La conclusione è questa. Le soft fork sono un gioco pericoloso e diventano ancora piu pericolose se sono contenziose e i minatori iniziano a combatterla. Anche le hard fork strettamente espansive sono un gioco pericoloso. Le soft fork attivate dai minatori sono coercitive. Le soft fork attivate dagli user sono meno coercitive anche se lo rimangono comunque per colpa della pressione economica. Se davvero si vuole fare un cambio contenzioso, e si è deciso che gli alti costi sociali ne valgono la pena, la cosa migliore è una hard fork bilaterale pulita, investire un po di tempo per aggiungere le protezioni necessarie e fare decidere al mercato tutto il resto.

 

Emanuele Coscia

Author: Emanuele Coscia

A volte faccio trading con cryptovalute, ma molto spesso sto leggendo qualcosa. Mi definirei un bitcoin maximalist se non fosse che Vitalik è davvero bellissimo.

Lascia un commento

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