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

Ethereum 2.0 Fase 0 sta introducendo il meccanismo di picchettamento tanto atteso alla piattaforma smart contract, oltre a lanciare lo scheletro di una futura blockchain Eth2, la Beacon Chain.

I progressi nel 2020 sono aumentati costantemente come furono introdotte sempre più reti di prova e ripetuto. Sebbene abbiano avuto successo nel complesso, non ne sono stati esentati problemi relativi alla sincronizzazione e alla produzione di blocchi.

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

Cointelegraph ha parlato con Zahary Karadjov, sviluppatore di ricerca presso Nimbus – uno di quei clienti – per saperne di più sulla strada percorsa finora da Ethereum 2.0 e sulle prossime tappe del viaggio.

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

Cointelegraph: Nimbus sembra aver avuto qualche problema in più nel raggiungere le specifiche condivise di Ethereum 2.0. Perché pensi che sia?

Zahary Karadjov: Eravamo molto impegnati 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ù specificamente, il livello di rete Libp2p.

Questo è qualcosa che abbiamo dovuto costruire da zero e ci è voluto parecchio tempo per stabilizzarlo. Ci sono stati alcuni mesi in cui stavamo lottando con le prestazioni. È stato solo di recente che abbiamo pubblicato la nostra versione stabile iniziale. Ma in questo momento, siamo fiduciosi per mainnet: stiamo lavorando sull’ultimo dei piccoli problemi e anche il nostro audit è stato completato.

CT: Prysm e Lighthouse, che in modo simile ai client Ethereum 1.0 esistenti sono stati costruiti rispettivamente in Go e Rust, sembrano essere stati un passo avanti rispetto agli altri finora. È perché sono stati in grado di sfruttare il lavoro svolto per Ethereum 1.0?

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

Il team di Prysm ha avuto il lusso di avere Libp2p sviluppato molto tempo fa, in quanto originariamente sviluppato in Go, mentre Lighthouse ha potuto sfruttare l’implementazione creata, ancora una volta, parecchio tempo fa dal team di Parity per il suo lavoro su A pois.

Libp2p è il livello di rete di Ethereum 2.0: puoi dire che è una tecnologia completamente diversa da quella utilizzata in Ethereum 1.0. In termini molto pratici, si tratta di una tecnologia di pubblicazione-sottoscrizione chiamata Gossipsub, che è un modo ottimizzato per trasmettere informazioni nella rete.

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

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 che eravamo discutendo nella nostra precedente conversazione. Se tutti sulla rete utilizzano lo stesso client, un problema tecnico in questo particolare client potrebbe mettere offline molti validatori, il che potrebbe rendere immediatamente la rete in uno stato non finalizzato.

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

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

CT: Durante il testnet e il periodo non definitivo, alcuni utenti si sono lamentati del fatto che la loro puntata fosse ridotta anche se erano online. È un bug o una caratteristica del sistema?

ZK: Potresti descriverlo come una conseguenza imprevista. Fondamentalmente, il problema è che il client viene ricompensato per le attestazioni trasmesse sulla rete. Ma queste attestazioni dovrebbero essere incluse in blocchi. Se non c’è nessuno a produrre blocchi, le tue attestazioni non finiscono sulla catena. Quindi, sembra che tu non sia attivo.

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

CT: Pensi che queste complessità e il requisito di essere costantemente online potrebbero allontanare le persone dallo staking con i propri dispositivi?

ZK: Beh, questo è un malinteso molto comune secondo cui penso che dovremmo fare un lavoro molto migliore nel comunicare. In realtà, i rischi di non essere sempre online non sono così grandi. Otterrai un profitto se sei online più del 50% delle volte. Pensaci: puoi essere offline per metà dell’anno e sarai ancora a zero. Non guadagnerai soldi, ma non perderai nemmeno soldi. Il protocollo è abbastanza indulgente a questo proposito.

CT: Cosa viene dopo il lancio sulla mainnet della Fase 0? Lo sharding è il prossimo aggiornamento nell’elenco o ti aspetti più lavoro richiesto per questa Beacon Chain iniziale?

ZK: Ci saranno sicuramente aggiornamenti in arrivo con l’integrazione della Fase 1 e richiederebbero modifiche sostanziali – o chiamiamolo semplicemente un hard fork – in cui i team client rilasceranno nuovo software man mano che più funzionalità saranno portate online. Ci aspettiamo il lancio del gadget finalizzato ad un certo punto, che finalizzerà la catena Ethereum 1.0 attraverso il meccanismo di consenso di Ethereum 2.0. Tutti questi rilasci in corso avverranno in parallelo. Sono un po ‘indipendenti l’uno dall’altro e fanno parte della roadmap di Ethereum per i prossimi anni.



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here