Pionieri della blockchain
Accedi

Metropolis: in viaggio verso ConstantinopleTempo di lettura: 8 min.

menu categorie articoli

Conversando con varie persone, mi sono reso conto che pochi realizzano cosa sia davvero successo con questo ultimo hard-fork di Ethereum. Si fa tanto parlare di MetropolisByzantiumConstantinople… Ma cosa realmente siano, lo sappiamo? Qualcuno addirittura si chiede cosa sia in realtà questa tanta blasonata funzione di Zk-Snark, come sia realmente possibile “eseguire transazioni anonime” e dove siano ora, come mai non siamo ancora in grado di utilizzarle.

Cerchiamo di osservare questo “macro” hard-fork Metropolis nell’insieme, e di fare chiarezza capendo cos’è stato Byzantium, cosa sarà Constantinople, e cosa abbia spinto gli sviluppatori a scegliere di dividerlo in due.

Metropolis, un progetto impegnativo

Questo Metropolis ha voluto portare con se tantissima carne al fuoco, per la maggior parte con modifiche tutto sommato poco visibili all’utente finale. Stiamo parlando di un hard-fork molto orientato al riorganizzare del “cosa succede dietro le quinte”, ma se da una parte abbiamo avuto modo di apprezzare in maniera tangibile i benefici del ribilanciamento della difficoltà dei blocchi, il bello deve ancora tutto arrivare!

Dobbiamo prenderne atto: la roadmap di Ethereum è cambiata! Come spesso accade per tanti progetti informatici, i tempi si sono dilatati, le priorità sono cambiate, e le strategie sono state ridefinite. Evitando ora di pronunciarsi su quel che sarà post-Metropolis, domandiamoci: perché dividere Metropolis in 2?

La verità è che Metropolis, con tutto quel che doveva portare, per novembre non era pronto! C’era una difficulty bomb in azione che stava congelando la blockchain, posta lì in previsione di agevolare il passaggio a Serenity, ed invece si è trovata ad ostacolare il fork ancora precedente. Arrivare a completamento di tutte le novità previste, avrebbe tardato talmente i tempi da rendere la blockchain stessa di fatto inservibile. Andava fatto qualcosa! Si è scelto quindi di prendere ciò che di pronto c’era, e di aggiungerlo assieme al ritardo della bomba. E di questo se ne tornerà a parlare tra un anno.

Byzantium, un hard-fork urgente

Byzantium aveva come scopo primario il ribilanciamento della difficoltà dei blocchi. La difficulty bomb, installata per portare quella che in gergo definiscono la “Ice Age” di Ethereum, un progressivo congelamento dei blocchi, stava iniziando a fare danni. Questa funzionalità era voluta, per impedire che all’avvenire di Serenity con POS la vecchia chain potesse sopravvivere senza ulteriori fork, ma si è fatta sentire troppo presto. Byzantium è stato attivato in main net il 16 ottobre, al blocco 4.370.000.

Assieme allo “scongelamento” dei blocchi, è stata colta la palla al balzo per introdurre un’altra caratteristica molto richiesta dagli utenti: la riduzione della produzione di ether per blocco, passata da 5 a 3. Questo sfruttando il fatto che i miner fossero oramai già abituati a guadagnare meno a causa dei blocchi diradati.

In seguito le rimanenti modifiche sono maggiormente orientate allo sviluppo. È ad esempio stata aggiornata la EVM (Ethereum Virtual Machine), l’interprete dei contratti di Ethereum, con le seguenti novità:

  • Sono state aggiunte nuove primitive di cifratura pre-compilate. Questo abbatte i costi per i contratti che vorranno farne uso, e getta le basi per lo sviluppo di Zk-Snark su Ethereum
  • È stato aggiunto un nuovo tipo di chiamata statica verso i contratti esterni, che consente di impedire a terzi qualsiasi tipo di modifica allo stato. Nello specifico, questo vuole impedire che si ripetano attacchi come quello avvenuto nel caso di “The DAO”
  • È stata aggiunta la possibilità di far fallire una chiamata, senza che venga bruciato tutto il GAS. Precedentemente, se una qualsiasi transazione avesse avuto un esito negativo, avremmo sicuramente perso tutta la tassa messa a disposizione dei miner. Ora non è più così, a discrezione del contratto

In ultima, sono stati aggiornati i protocolli per gestire le transazioni, per fornire ad esempio ai light-client maggiore autonomia sulle verifiche.

Constantinople, un hard-fork ambizioso

Ma è con Constantinople che assistiamo alla vera rivoluzione. Sull’esatto contenuto se ne sa ancora poco, ma sui punti principali di succo ce n’è molto. Come prima cosa, non è certo il periodo in cui verrà rilasciato. Quando è stato scelto di dividere Metropolis in due, Constantinople era stato previsto entro fine 2017. Attualmente, una periodo più realistico sembra essere inizio 2018. Tuttavia, in questo caso, non abbiamo alcuna fretta.

Le novità maggiormente attese sono due, forse tre. La terza, la introduco subito, potrebbe essere l’implementazione di un EIP, come EIP156, in grado di rilasciare i fondi congelati dall’ultimo Parity Hack (vedi articolo per approfondimenti). Le altre due, vediamole in seguito.

Constantinople dovrebbe introdurre la prima implementazione funzionante di Casper! Casper, come tutti sappiamo, è il nome dell’implementazione POS (Proof of Stake) di Ethereum. Non tutti probabilmente invece sapranno che Casper si divide in due progetti distinti: Casper the Friendly Finality Gadget (CFFG) seguito da Vitalik Buterin, e Casper Correct By Construction (CCBC) seguito da Vlad Zamfir.

Il primo è un protocollo ibrido, POW-POS. Prevede una base di POW, ed ogni 100 blocchi normali un “checkpoint” realizzato con POS. È un approccio più “moderato e cauto” al problema. Il secondo invece è un approccio POS puro, in cui la necessità di POW sparisce, e se ne parlerà probabilmente per Serenity. Con Constantinople dovrebbe arrivare una prima implementazione dell’algoritmo di Vitalik, per mettere con Ethereum un primo passo nel mondo del Proof of Stake.

La seconda grossa novità sarà invece il tanto discusso EIP86 (https://github.com/ethereum/EIPs/issues/86), ovvero l’astrazione sugli account di Ethereum, ed il metodo con la quale eseguono le transazioni! Sembra una cosa totalmente astratta e poco concreta, ma cosa significa davvero?

Attualmente, il metodo con la quale vengono gestiti gli account, ed il modo con la quale vengono generate e validate le transazioni è codificato direttamente all’interno del codice del client (geth/parity per esempio). Questo significa che quella parte di codice è di fatto unica ed immutabile e non offre, cioè, la possibilità di essere programmata con regole a piacere. Quello che si propone di fare questo EIP è proprio questo: rilasciare agli sviluppatori la possibilità di definire in autonomia cosa siano le transazioni, e come esse debbano essere trattate!

Le possibilità previste da questa modifica sono probabilmente ad oggi ancora in larga parte inesplorate, ne citiamo in seguito solo alcuni esempi:

  • Potremo finalmente eseguire transazioni con il tanto atteso Zk-Snark! Saremo così in grado di far accedere i nostri ether in questo “universo” in cui le transazioni vengono eseguite senza necessità di rivelare il mittente, il destinatario, e l’ammontare
  • Potremo avere transazioni in “stile Bitcoin”, ovvero con un arbitrario numero di indirizzi di input, ed un arbitrario numero di indirizzi in output. Non saremo quindi più costretti a riutilizzare sempre lo stesso indirizzo, e potremo fare più pagamenti con una sola transazione
  • Potremo muovere token da indirizzi senza ether, delegando il pagamento del gas ad un altro nostro indirizzo
  • Potremo eseguire contratti senza pagare noi il costo del GAS, delegando al contratto stesso il compito di pagare l’ammontare
  • Potremo impostare una condizione di validità preventiva per le transazioni, specificando cioè una condizione per cui, una transazione, potrà essere rimossa dalla pool senza che venga inserita in un blocco.
    Immaginiamo ad esempio di partecipare ad una ICO che generi molto traffico, come in passato è accaduto più volte. La ICO termina, ma la coda è ancora piena di transazioni che andranno a fallire in attesa di partecipare. In questo caso è possibile porre la condizione di vita “la tx è valida sino a che la ICO xyz è aperta”, e alla chiusura della ICO la pool si svuoterà automaticamente. Niente più chain bloccata per ore

Le novità annunciate per Constantinople terminano qui, fatemi sapere nei commenti cosa ne pensate, quali sono gli aspetti che preferite, e quali prospettive vedete per il prossimo fork in arrivo. Appena vi saranno aggiornamenti cercheremo di analizzarne i contenuti.

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

Non perdere le ultime notizie

Se questo articolo ti è piaciuto e vuoi rimanere sempre aggiornato sul mondo cripto e blockchain iscriviti alla nostra Newsletter

Picture of Mirko Da Corte

Mirko Da Corte

Appassionato di tecnologia da sempre, incontrai per caso blockchain in un pomeriggio di sole. Fu amore a prima vista. Founder e CTO di Digicando Srl, collaboro alla moderazione del gruppo Ethereum Italia
Picture of Mirko Da Corte

Mirko Da Corte

Appassionato di tecnologia da sempre, incontrai per caso blockchain in un pomeriggio di sole. Fu amore a prima vista. Founder e CTO di Digicando Srl, collaboro alla moderazione del gruppo Ethereum Italia

Commenti

Lascia un commento

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