Eth2 dev parla delle sfide e delle lezioni apprese prima del lancio di mainnet

Nonostante alcune „conseguenze impreviste“, i testnets sono stati strumentali nel testare l’Eth2.

Dopo anni di ritardi e cambiamenti nei piani, l’Ethereum 2.0 si sta finalmente avvicinando al rilascio il 1° dicembre.

La fase 0 dell’Ethereum 2.0 sta introducendo il tanto atteso meccanismo di picchettamento sulla piattaforma contrattuale intelligente, oltre a lanciare lo scheletro di una futura catena a blocchi Eth2, la Beacon Chain.

I progressi nel 2020 hanno registrato una costante accelerazione con l’introduzione e l’iterazione di un numero sempre maggiore di testnet. Pur avendo avuto successo nel complesso, non sono stati esenti da problemi legati alla sincronizzazione e alla produzione di blocchi.

Parte di questi problemi derivava dalla sfida di mantenere lo stesso ritmo tra sette diversi clienti, o software di nodo Ethereum 2.0, lavorando con diversi linguaggi di programmazione e stack tecnologici.

Il Cointelegraph ha parlato con Zahary Karadjov, ricercatrice di Nimbus – uno di questi clienti – per saperne di più sia sulla strada che Ethereum 2.0 ha percorso finora, sia sulle prossime tappe del viaggio.

L’intervista è stata leggermente modificata per lunghezza e contesto.

Cointelegrafo: Sembra che Nimbus abbia avuto qualche problema in più per raggiungere le specifiche condivise dell’Ethereum 2.0. Secondo lei, perché?

Zahary Karadjov: Eravamo molto occupati a preparare Nimbus per mainnet. È giusto dire che è stato un po‘ più impegnativo per noi, perché ci è voluto un po‘ di tempo per sviluppare alcuni dei componenti che gli altri team avevano già a disposizione – più precisamente, il livello di rete Libp2p.

Questo è qualcosa che abbiamo dovuto costruire da zero, e ci è voluto un bel po‘ di tempo per stabilizzarlo. Ci sono stati alcuni mesi in cui abbiamo avuto problemi di prestazioni. È stato solo di recente che abbiamo pubblicato la nostra prima versione stabile. Ma in questo momento ci sentiamo fiduciosi per mainnet: Stiamo lavorando sull’ultimo dei piccoli problemi, e anche la nostra revisione è stata completata.

CT: Prysm e Lighthouse – che, come gli attuali clienti dell’Cryptosoft, sono stati costruiti rispettivamente a Go e Rust – sembrano essere stati finora in vantaggio rispetto agli altri. È perché sono stati in grado di costruire sul lavoro svolto per l’Ethereum 1.0?

ZK: La mia spiegazione sarà una semplificazione, perché ci sono molti fattori in gioco. Ma direi che lo sviluppo del Libp2p è stato per noi la fonte più significativa di ritardi. E la logica è facile da vedere qui: Anche Teku, che è sviluppato in Java, non aveva un’implementazione Libp2p, ed è diventato pronto anche in una fase leggermente successiva.

Il team di Prysm ha avuto il lusso di far sviluppare Libp2p molto tempo fa, in quanto originariamente sviluppato in Go, mentre Lighthouse ha potuto sfruttare l’implementazione creata, sempre qualche tempo fa, dal team di Parity per il suo lavoro su Polkadot.

Libp2p è lo strato di rete dell’Ethereum 2.0 – si può dire che è una tecnologia completamente diversa da quella utilizzata nell’Ethereum 1.0. In termini molto pratici, è una tecnologia di pubblicazione in abbonamento chiamata Gossipsub, che è un modo ottimizzato per trasmettere informazioni in rete.

CT: Parliamo del Medalla testnet. Quali lezioni hanno imparato Nimbus e la comunità di Eth2, soprattutto considerando i periodi in cui la blockchain non forniva garanzie di completezza?

ZK: Beh, le lotte con la finalità sono iniziate con un problema tecnico. C’è il famoso incidente di Cloudflare Roughtime, che ha dimostrato esattamente quello di cui stavamo discutendo nella nostra precedente conversazione. Se tutti i membri della rete utilizzano lo stesso cliente, un problema tecnico in questo particolare cliente potrebbe mettere offline molti validatori, il che potrebbe rendere immediatamente la rete in uno stato non definitivo.

Abbiamo avuto questo problema con il cliente Prysm, e ci ha anche insegnato una lezione importante sull’importanza della comunicazione. Il team Prysm è stato in grado di fornire una soluzione a questo problema in un tempo molto breve – solo un paio d’ore. Ma ci è voluto un bel po‘ di tempo prima che la comunità si rendesse conto che c’era un problema e che la soluzione fosse pronta.

Questo è stato l’incidente iniziale che ha creato un lungo periodo di non finalizzazione per Medalla. Ma questo è stato in realtà molto utile per i clienti, perché quando la rete non è in fase di finalizzazione, i clienti devono prendere in considerazione molte diverse possibili forchette e storie alternative, e questo mette molto stress ai clienti. Quindi, questi lunghi periodi di non finalizzazione ci hanno permesso di vedere e di ottimizzare i clienti per questi momenti stressanti della rete in cui tutto non funziona come previsto.

CT: Durante il testnet e il periodo di non finalizzazione, alcuni utenti si sono lamentati che la loro quota di partecipazione si è ridotta anche se erano online. È un bug o una caratteristica del sistema?

ZK: Si potrebbe descrivere come una conseguenza imprevista. In sostanza, il problema è che il cliente viene ricompensato per gli attestati trasmessi in rete. Ma questi attestati dovrebbero essere inclusi nei blocchi. Se non c’è nessuno a produrre i blocchi, gli attestati non finiscono nella catena. Quindi, sembra che non siate attivi.

Penso che questo problema sia ben riconosciuto e riconosciuto dal team di implementazione e dal team di ricerca. Dovrebbe essere affrontato nel futuro dell’Ethereum – nella Fase 1, o anche nella Fase 0.5, uno dei primissimi aggiornamenti della rete. Ma non dobbiamo dimenticare che sarebbe del tutto inaspettato se vedessimo bassi tassi di partecipazione sulla rete principale, perché quando c’è una vera posta in gioco, gli incentivi per i validatori a essere online sono molto più forti.

CT: Ritiene che queste complessità e l’esigenza di essere costantemente online potrebbero distogliere le persone dal puntare con i propri dispositivi?

ZK: Beh, questo è un malinteso molto comune che penso che dovremmo fare un lavoro molto migliore nel comunicare. In realtà, i rischi di non essere sempre online non sono così grandi. Si ottiene un profitto se si è online per più del 50% del tempo. Pensateci: Puoi stare offline per metà dell’anno e sarai comunque a zero. Non guadagnerai nulla, ma non perderai neanche un soldo. Il protocollo è abbastanza indulgente a questo proposito.

CT: Cosa succede dopo il lancio della Fase 0 sulla rete principale? Si sta eliminando il prossimo aggiornamento della lista o si aspetta che ci sia bisogno di più lavoro per questa prima Beacon Chain?

ZK: Ci saranno certamente degli aggiornamenti con l’integrazione della Fase 1, e ciò richiederebbe dei cambiamenti di rottura – o chiamiamolo semplicemente un hard fork – dove i team del cliente rilasceranno un nuovo software man mano che verranno messe online più funzionalità. Ci aspettiamo il rollout del gadget delle finalità ad un certo punto, che finalizzerà la catena dell’Ethereum 1.0 attraverso il meccanismo di consenso dell’Ethereum 2.0. Tutti questi rilasci in corso avverranno in parallelo. Sono un po‘ indipendenti l’uno dall’altro e fanno parte della roadmap dell’Ethereum per i prossimi anni.

Bitcoin