Menu
Home » Codice e sviluppo » La battaglia di Ethereum per i fondi perduti continua su EIP 867: “code is law” e “code is a process”

La battaglia di Ethereum per i fondi perduti continua su EIP 867: “code is law” e “code is a process”

27 Febbraio 2018 19:00
Tempo di lettura: 9 min.
27 Febbraio 2018 19:00
Giuseppe Brogna

Il “world computer” è di nuovo invischiato in un acceso dibattito.

Scatenato da una controversa proposta di codice chiamata EIP 867, i forum di sviluppo di Ethereum sono diventati una sorta di campo di battaglia, affollato di commenti rancorosi, pull request pungenti e tentativi coordinati di cancellare l’idea dal repository della piattaforma.

Per chi non ha familiarità, il conflitto deriva dall’idea di rendere più facile agli utenti di Ethereum il recuperaro degli ether (ETH) perduti – la criptovaluta della rete ora valutata circa $ 870 -, delineando un procedimento mediante il quale tali richieste potrebbero essere presentate in un formato chiaro ed eseguibile a coloro che supportano la tecnologia.

Non un problema di poco conto, considerando che le perdite di fondi su Ethereum sono diventate frequenti.

Casi di alto profilo, come la cancellazione di una libreria di codici dalla società di software Parity Technologies, hanno visto l’anno scorso 513.774,16 ether, o 421 milioni di dollari, resi inaccessibili. E solo pochi mesi prima, la stessa azienda aveva perso 150.000 ether, o 123 milioni di dollari, a causa di un errore di codice.

Ma non è solo Parity. L’anno scorso, un generatore di indirizzi Ethereum problematico ha visto l’exchange Kraken e il provider di wallet MyEtherWallet perdere centinaia di migliaia di fondi dei clienti. E molti altri, sia a causa di software buggati o semplici errori di battitura, hanno perso denaro sulla piattaforma: un indirizzo contiene addirittura $ 6,3 milioni in ether, perché riflette minuziosamente un codice di chiamata che blocca automaticamente i fondi.

Ma mentre alcuni utenti ritengono che il rimborso degli ether perduti sia accettabile, un effetto collaterale della proprietà del fondo digitale e della responsabilità che ne deriva, altri si sono veementemente opposti, ritenendo che tali attività minaccino l’integrità della piattaforma Ethereum, aumentando al contempo potenziali responsabilità legali.

Infatti, un core developer è persino uscito dal suo ruolo di editor di codice, citando le conseguenze legali che potrebbero derivarne.

Tuttavia, il conflitto non è una novità, richiamando alla memoria una controversa decisione che ha riguardato Ethereum nel 2016, con cui furono rimborsati 3,6 milioni di ether rubati, mediante un aggiornamento a livello di sistema, o hard fork.

Il fondatore di Ethereum, Vitalik Buterin, ha scritto su Twitter:

“Per coloro che hanno pensato che il fork DAO stabilisse una brutta china senza limiti, e un precedente duraturo, vi esorto a vedere le reazioni su questo thread.”

In questo modo, il conflitto che emerge da EIP 867 mostra che le due fazioni del dibattito devono ancora conciliarsi, e che ci sono sottigliezze al lavoro all’interno di ogni sottoinsieme.

In generale, ciascuna parte può essere intesa come se avesse un’interpretazione diversa di Ethereum.

Cos’è EIP 867?

Nello sviluppo del software Ethereum, un EIP, o Ethereum improvement protocol, è il processo mediante il quale le modifiche al codice vengono accettate sulla piattaforma.

Per aggiungere nuove funzionalità a Ethereum, le modifiche del software vengono eseguite sotto forma di upgrade a livello di piattaforma (a volte chiamati hard fork), ma per arrivare a questa fase, le proposte sono soggette a un rigoroso procedimento di accettazione, costituito grossomodo da quattro passaggi:

  1. Innanzitutto, se uno sviluppatore ha un’idea per un cambio al software, dovrebbe essere presentata come una pull request. Come pull request, è possibile apportare facilmente modifiche alla proposta e il feedback della community è ben accetto. Qui, è anche sottoposta all’esame degli editor dell’EIP;
  2. Se gli editor dell’EIP ritengono la richiesta tecnicamente corretta e in sintonia con la “filosofia di Ethereum”, possono “mergiarla” come bozza nella fase successiva;
  3. Una volta mergiata, possono avere luogo le implementazioni software, nella forma di diversi client Ethereum, come Geth e Parity, e se funzionano la proposta può essere infine accettata;
  4. Una volta accettata, la piattaforma può essere aggiornata con l’EIP, a patto che i vari nodi su cui è in esecuzione il software Ethereum decidano di attuare l’aggiornamento.

Tuttavia, in questo procedimento, EIP 867 differisce leggermente. Innanzitutto, non propone modifiche al software in sé, ma semplicemente documenta un framework che possa essere seguito dalle proposte.

Da questo punto di vista ricade in un’altra categoria, chiamata “meta EIP“, che è un modo per raccogliere e formalizzare gli EIP riguardanti una specifica categoria – in questo caso, le proposte di recupero. Per questo motivo, gli sviluppatori di EIP 867 hanno dato alla meta EIP un nome unico: Standardizing Ethereum Recovery Proposals, o ERPs.

Dopo il congelamento dei $ 421 milioni di fondi dell’anno scorso, Parity Technologies ha elaborato diverse opzioni per recuperare i fondi, tutte rigorosamente rifiutate all’epoca. Esiste anche un EIP denominato EIP 156 che, scritto da Buterin, descrive un metodo per restituire i fondi persi da Kraken e MyEtherWallet, nonché in altri casi popolari di fondi persi.

Secondo EIP 867, il fallimento di tali proposte è dovuto in parte “alla natura relativamente ad hoc di tali richieste e alla soggettività che è spesso richiesta per valutare il merito“. Come tale, l’EIP fornisce “un formato standardizzato per le EIP di recupero dei fondi, e uno standard obiettivo con cui misurare le proposte future“.

Infine, se accettata, le EIP rientranti nella categoria Ethereum recovery proposal (ERPs), sarebbero soggette allo stesso procedimento di valutazione di qualsiasi proposta di codice riguardante la piattaforma.

Attualmente, EIP 867 è in stallo nella seconda fase del procedimento di accettazione delle EIP: si tratta di un draft non mergiato. L’ex editor dell’EIP, Yoichi Hirai, inizialmente respinse la proposta a causa del suo mancato allineamento con la “filosofia di Ethereum”, uno dei parametri di giudizio nel processo formale delle EIP.

Hirai in seguito si è dimesso dalla sua posizione di direttore dell’EIP, citando le conseguenze legali che potrebbero derivare dal permettere al progetto di continuare.

E a causa della sua natura divisiva, gli sviluppatori di Ethereum hanno affermato che, prima di ogni ulteriore azione, il processo di EIP deve essere ulteriormente rivalutato, per chiarire se alcune cose, come il giudizio soggettivo, possano entrare in gioco.

Visione 1: “Code Is Law” (“Il codice è legge”)

Quando Ethereum è stato aggiornato per ripristinare i 3,6 milioni di ether – ora valutati oltre $ 3 miliardi – persi nell’hack del The DAO, una parte della comunità ha abbandonato la piattaforma per creare una nuova criptovaluta denominata Ethereum classic.

Su Ethereum classic, che ora è valutato poco meno di $ 1 miliardo, vi è la piattaforma di Ethereum al netto del recupero dei fondi del The DAO, come se il recupero non si fosse mai verificato e i fondi fossero definitivamente perduti.

Ad influenzare questa decisione è stata la convinzione che “code is law”, il che significa che su una blockchain tutte le esecuzioni e le transazioni sono definitive e immutabili, e non possono essere sovrascritte o corrette, specialmente quando si tratta di soldi veri. In questa prospettiva, errori di codice, come falle nei software che possono essere violati o interrotti, sono dolorose ma necessarie lezioni per lo sviluppo.

Dato che EIP 867 potrebbe rendere tali correzioni più frequenti, in centinaia sono insorti con le loro opinioni su Github, con qualche minaccia di migrare a Ethereum classic.

Il blockchain architect Cody Burns, ha scritto su Twitter:

“Se non vi piace la possibilità di recuperare i fondi usate [ethereum classic], questo dibattito è stato risolto due anni fa”.

Poiché il The DAO è stato in gran parte guidato da sviluppatori Ethereum, con legami con la Fondazione Ethereum, molti hanno visto il rimborso di 3,6 milioni come un bailout“, un’accusa di corruzione degli sviluppatori che persiste nel dibattito EIP 867.

Marius Kjærstad, la voce dell’opposizione, ha scritto in un thread:

“Se volete i bailout, dovreste attenervi alle fiat”.

Sostenendo che tali cambiamenti danneggino l’incentivo a mantenere i ledger decentralizzati, lo sviluppatore di software Charles Cooper ha scritto:

“In presenza di questo processo, Ethereum non può più essere chiamato blockchain, è solo una banca centrale che usa i minatori per convalidare la maggior parte delle transazioni”.

A fare ombra su questo, è la preoccupazione che EIP 867 darebbe agli sviluppatori troppo potere sulla piattaforma Ethereum. Citando una legge giapponese, Hirai sosteneva che il movimento di fondi, specialmente nel caso di titolarità non univoca, andrebbe al di là della competenza degli sviluppatori, e potrebbe renderli responsabili di corruzione, coercizione e abuso.

Ha scritto Alexey Akhunov sul thread:

“Voglio essere uno sviluppatore di software, non un avvocato”.

Dal lato più moderato di questa sponda del dibattito, altre voci sostengono che il The DAO sia stato un avvenimento unico, e gli upgrade del software per il recupero dei fondi dovrebbero essere rari e sempre più eccezionali” con la maturazione della piattaforma, una posizione che lo stesso Buterin ha sostenuto.

In questa direzione, lo sviluppatore del browser Mist di Ethereum, Alex Van de Sande, ha proposto un sistema in base al quale il recupero dei fondi potrebbe essere possibile senza aggiornamenti software, ma creando una riserva assicurativa per i rimborsi di ether.

Visione 2: “Code is a process” (“Il codice è un processo”)

Dall’altra parte del dibattito ci sono alcuni dei migliori sviluppatori di Ethereum, i quali sostengono che, nei casi in cui la titolarità dei fondi sia chiara e indiscutibile, il recupero dovrebbe avere luogo.

Il programmatore di Ethereum, Nick Johnson, ha scritto su Twitter:

“Mi sembra davvero che l’ipotesi di recuperare gli ether perduti, dove è facile identificare il vero proprietario e recuperarli imponga un basso peso a tutti gli altri, dovrebbe essere abbastanza chiara e senza controversie”.

E tali casi sono relativamente comuni.

Negli esempi citati nell’EIP 156 di Buterin, i fondi persi in determinati casi potrebbero essere riscattati e, secondo alcuni, a ragione.

Jesse Powell, CEO dell’exchange di criptovalute Kraken, ha scritto in risposta a EIP 156 due anni fa:

“Parlando a nome di Kraken, lo definirei più come una ricompensa che come un salvataggio: abbiamo subito alcune perdite non trascurabili a causa del citato bug nella vecchia libreria javascript di Ethereum. A quel tempo, le perdite furono coperte di tasca propria da Kraken, per proteggere i nostri clienti. “

E Kraken non è solo. In effetti, l’EIP 156 è disseminato di commenti di altri che sono stati colpiti in diversi modi, ognuno dei quali si rivolge alla comunità per ottenere giustizia in merito ai fondi persi senza alcuna colpa propria.

Ha scritto un utente infuriato su Reddit:

“MyEtherWallet mi ha appena bruciato 121 ETH”.

Secondo alcuni, Ethereum ha una responsabilità nei confronti dei propri utenti in questi casi. Inoltre, fornendo protezione per i fondi persi, il rischio di utilizzare la piattaforma si ridurrebbe al minimo, portando ad una maggiore adozione.

E mentre il consenso della comunità è essenziale per far sì che i cambiamenti sulla piattaforma si verifichino, è stato espresso il timore che la forte opposizione a EIP 867 non sia rappresentativa della più ampia cerchia di stakeholder di Ethereum.

Parlando con CoinDesk, James Levy di Taptrust, uno degli sviluppatori che ha guidato la proposta, ha dichiarato:

“Una delle cose più complicate ora è che c’è una voce di minoranza, non do per scontato che la risposta del pubblico fosse totalmente rappresentativa”.

Levy ha aggiunto:

“La grande maggioranza silenziosa vuole che la rete funzioni e che il valore di ether cresca: non hanno alcun interesse personale nella disputa”.

Infine, poiché EIP 867 non è in sé e per sé una proposta su fondi perduti, ma piuttosto uno standard con cui formalizzare le proposte per il recupero di fondi smarriti, c’è la tesi secondo cui l’attuale EIP di per sé non richiede affatto alcun cambiamento controverso.

Invece, se accettate, le Ethereum recovery proposal (ERPs) passerebbero attraverso lo stesso rigoroso procedimento di controllo degli EIP standard. Alla fine, se viene implementata una proposta controversa, gli utenti potrebbero scegliere di non aggiornare il loro software, quindi non sincronizzarsi con la catena dominante.

Di Coindesk

Clicca qui per accedere alla guida gratuita su come comprare, vendere, trasferire e conservare in sicurezza gli Ether.

Condividi
  • 4
    Shares

CATEGORIE:

Codice e sviluppoHard fork Ethereum


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