Dopo anni di ritardi e cambi di programma, Ethereum 2.0 ha finalmente raggiunto il lancio del 1° dicembre.

La Phase 0 di Ethereum 2.0 introduce l’attesissimo meccanismo di staking e avvia la Beacon Chain, ovvero lo scheletro del futuro network di Ethereum.

I progressi nel 2020 hanno gradualmente accelerato il passo, accompagnati dall’introduzione di nuovi testnet. Nonostante il successo complessivo, queste piattaforme hanno assistito a problemi relativi a sincronizzazione e produzione dei blocchi.

Parte di queste problematiche era dovuta alla sfida di mantenere di pari passo i progressi di sette client diversi, o node software di Ethereum 2.0, lavorando con linguaggi di programmazione e stack tecnologici differenti.

Cointelegraph ha discusso con Zahary Karadjov, research developer presso Nimbus (uno di questi client) per saperne di più sulla strada percorsa finora da Ethereum 2.0 e sulle prossime tappe del viaggio.

Cointelegraph: sembra che Nimbus abbia avuto qualche problema a raggiungere le specifiche comuni di Ethereum 2.0. Quale credi che sia stato il motivo?

Zahary Karadjov: Eravamo molto impegnati a preparare Nimbus per il mainnet. È corretto dire che è stato un compito più difficile per noi in quanto ci abbiamo messo un po’ a sviluppare alcune delle componenti che gli altri team avevano già a disposizione. Più precisamente, il livello di rete Libp2p.

Questo è un elemento che abbiamo dovuto costruire da zero, e ci è voluto molto tempo per stabilizzarlo. Abbiamo avuto difficoltà con le performance per qualche mese. Solo di recente abbiamo pubblicato la nostra versione stabile iniziale. Ora, però, siamo fiduciosi per il mainnet: stiamo lavorando sull’ultimo piccolo problema, il nostro audit è già stato completato.

CT: Prysm e Lighthouse, sviluppati rispettivamente in Go e Rust come client esistenti di Ethereum 1.0, sembrano essere un passo davanti agli altri finora. Forse perché hanno potuto sfruttare il lavoro svolto per Ethereum 1.0?

ZK: La mia spiegazione sarà una semplificazione, in quanto ci sono molti fattori coinvolti. Direi che lo sviluppo di Libp2p sia stato per noi la fonte di ritardi più significativa: anche Teku, sviluppato in Java, non aveva un’implementazione Libp2p, e come noi è stato completato un po’ più tardi.

Il team di Prysm ha avuto il lusso di avere Libp2p creato molto tempo fa, in quanto è stato sviluppato originariamente in Go, mentre Lighthouse è riuscito a sfruttare l’implementazione creata, di nuovo, tempo fa dal team di Parity per i lavori su Polkadot.

Libp2p è il livello di rete di Ethereum 2.0, si può dire che sia una tecnologia completamente differente da quella utilizzata in Ethereum 1.0. In termini molto pratici, è una tecnologia publish-subscribe chiamata Gossipsub, che rappresenta un modo ottimizzato per trasmettere informazioni nel network.

CT: Parliamo del testnet Medalla. Quali sono le lezioni imparate da Nimbus e dalla comunità di Eth2, soprattutto considerando i periodi in cui la blockchain non ha fornito garanzie sufficienti per la finalità dei blocchi?

ZK: Beh, le difficoltà relative alla finalità sono iniziate con un problema tecnico. Il famoso incidente Cloudflare Roughtime dimostra esattamente ciò di cui abbiamo discusso nella nostra conversazione precedente. Se tutti nel network utilizzassero lo stesso client, un problema tecnico in questo particolare client potrebbe mandare offline molti validatori, spingendo immediatamente la rete in uno stato non finalizzante.

Abbiamo avuto questo problema con il client Prysm, e ci ha insegnato una grande lezione sull’importanza della comunicazione. Il team di Prysm è riuscito a fornire una soluzione per questo problema in un lasso di tempo molto breve, solo un paio d’ore. Tuttavia, la comunità ci ha messo un po’ per rendersi conto del problema e implementare la soluzione.

Questo è stato l’incidente iniziale che ha creato un lungo periodo di non finalizzazione per Medalla. Tuttavia, si è rivelato in realtà molto utile per i client. Quando il network non finalizza i blocchi, i client devono considerare molti possibili fork e storie alternative, e questo provoca un forte stress. Quindi, questi lunghi periodi di non finalizzazione ci hanno permesso di esaminare e ottimizzare i client per questi momenti difficili nel network in cui non tutto va per il verso giusto.

CT: Durante il testnet e il periodo di non finalità, alcuni utenti si sono lamentati del fatto che la loro stake è stata ridotta anche se erano online. Si tratta di un bug o di una funzione del sistema?

ZK: Potresti descriverla come una conseguenza imprevista. Sostanzialmente, il problema è che il client viene ricompensato per le attestazioni trasmesse sul network. Tuttavia, queste attestazioni dovrebbero essere incluse nei blocchi. Se non c’è nessuno che produce blocchi, le tue attestazioni non finiscono sulla blockchain. Quindi, sembra che non sei attivo.

Credo che questo problema sia ben riconosciuto dal team di implementazione e dal team di ricerca. Dovrebbe essere affrontato nel futuro di Ethereum, nella Phase 1 o persino nella Phase 0.5, uno dei primi aggiornamenti del network. Comunque, dobbiamo ricordarci che sarebbe piuttosto inaspettato vedere tassi di partecipazione bassi sul mainnet. Infatti, quando vengono coinvolte stake reali, gli incentivi per convincere i validatori a rimanere online sono molto più forti.

CT: Credi che queste complessità e il requisito di essere costantemente online possano allontanare la gente dallo staking con i propri dispositivi?

ZK: Questa è un malinteso molto comune che dovremmo chiarire meglio. In realtà, i rischi legati al non essere online in continuazione non sono così grandi. Ricaverai un profitto rimanendo online per oltre il 50% del tempo. Pensaci: puoi restare offline per metà anno e sarai ancora a zero. Non guadagnerai nulla, ma non perderai soldi. Il protocollo è piuttosto indulgente in questo ambito.

CT: Cosa viene dopo il lancio del mainnet nella Phase 0? Lo sharding è il prossimo aggiornamento sulla lista o credi che ci sarà altro lavoro da fare su questa Beacon Chain iniziale?

ZK: Ci saranno sicuramente aggiornamenti introdotti con l’integrazione della Phase 1, e richiederanno profonde modifiche (chiamiamole un hard fork) in cui i team dei client pubblicheranno nuovo software man mano che altre funzionalità vengono portate online. Prevediamo l’implementazione del gadget di finalità prima o poi, che finalizzerà la catena di Ethereum 1.0 attraverso il meccanismo di consenso di Ethereum 2.0. Tutti questi lanci avverranno in parallelo. Sono abbastanza indipendenti l’uno dall’altro e fanno parte della tabella di marcia di Ethereum per i prossimi anni.