Vai al contenuto principale

Aiuta ad aggiornare questa pagina

🌏

C'è una nuova versione di questa pagina, ma al momento è solo in inglese. Aiutaci a tradurre l'ultima versione.

Traduci la pagina
Visualizza in inglese

Nessun bug qui!🐛

Questa pagina non è stata tradotta. Per il momento, è stata intenzionalmente lasciata in inglese.

Diversità dei client

Ultima modifica: , Invalid DateTime
Modifica la pagina

Il comportamento di un nodo di Ethereum è controllato dal software del client che esegue. Esistono diversi client di Ethereum di livello di produzione, ognuno sviluppato e mantenuto in diversi linguaggi da team distinti. I client sono costruiti su specifiche comuni che assicurano che i client comunichino senza problemi tra loro e abbiano le stesse funzionalità, fornendo un'esperienza utente equivalente. Tuttavia, al momento, la distribuzione dei client tra i nodi non è abbastanza equilibrata da realizzare in tutta la sua potenzialità questa fortificazione della rete. Idealmente, gli utenti dovrebbero dividersi approssimativamente in modo equo tra i vari client, per portare quanta più diversità dei client possibile alla rete.

Prerequisiti

Se ancora non sai cosa sono i nodi e i client, dai un'occhiata a nodi e client. I livelli di esecuzione e consenso sono definiti nel glossario.

Perché esistono diversi client?

Esistono diversi client sviluppati e mantenuti indipendentemente perché la diversità dei client rende la rete più resistente ad attacchi e bug. Diversi client sono una forza unica per Ethereum, mentre altre blockchain si affidano all'infallibilità di un singolo client. Tuttavia, non basta avere semplicemente diversi client disponibili, devono essere adottati dalla community e i nodi attivi totali devono essere distribuiti in modo relativamente uniforme tra loro.

Perché la diversità dei client è importante?

Avere molti client sviluppati e mantenuti indipendentemente è vitale per l'integrità di una rete decentralizzata. Vediamo perché.

Bug

Un bug in un singolo client rappresenta un pericolo minore per la rete se rappresenta una minoranza di nodi di Ethereum. Con una distribuzione approssimativamente uniforme dei nodi tra molti client, la probabilità che gran parte dei client soffra di un problema comune è minima e, di conseguenza, la rete è più robusta.

Resistenza agli attacchi

La diversità dei client offre anche resistenza agli attacchi. Ad esempio, un attacco che inganna un client specifico su un ramo particolare della catena, difficilmente riuscirà nel suo intento perché non è probabile che anche gli altri client siano vulnerabili allo stesso modo, e la catena canonica non viene quindi corrotta. Una bassa diversità dei client aumenta i rischi associati a un attacco sul client dominante. È stato dimostrato che la diversità dei client è una difesa importante contro gli attacchi malevoli sulla rete, ad esempio, l'attacco di denial of service di Shanghai nel 2016 è stato possibile perché gli utenti malevoli sono riusciti a ingannare il client dominante (Geth) facendogli eseguire un'operazione lenta di I/O su disco decine di migliaia di volte per blocco. Poiché online erano presenti anche altri client alternativi che non avevano la stessa vulnerabilità, Ethereum è riuscita a resistere all'attacco e a continuare a funzionare mentre veniva risolta la vulnerabilità di Geth.

Finalità del proof-of-stake

Un bug in un client del consenso con oltre il 33% dei nodi di Ethereum potrebbe impedire alla Beacon Chain di finalizzarsi, a significare che gli utenti non potrebbero fidarsi del fatto che le transazioni sarebbero a un certo punto ripristinate o modificate. Questo sarebbe molto problematico per molte delle app basate su Ethereum, in particolare, le DeFi.

🚨 Ancora peggio, un bug critico in un client con una maggioranza di due terzi potrebbe causare la una divisione e finalizzazione errata della catena, bloccando un gran numero di validatori su una catena non valida. Se vogliono rientrare nella catena corretta, quei validatori devo sottoporsi a tagli (slashing) o a un prelievo volontario, costoso e lento, e alla riattivazione. L'ammontare del taglio (slashing) aumenta col numero di nodi colpevoli, potendo interessare al massimo una maggioranza di due terzi (32 ETH).

Sebbene questi siano scenari improbabili, l'ecosistema di Ethereum può mitigarne il rischio equilibrando la distribuzione dei client tra i nodi attivi. Idealmente, nessun client del consenso dovrebbe mai raggiungere una quota del 33% dei nodi totali.

Responsabilità condivisa

Esiste anche un costo umano associato alla presenza di client di maggioranza. Essa comporta un eccesso di lavoro e responsabilità su un team di sviluppo di piccole dimensioni. Minore è la diversità dei client, maggiore l'onere di responsabilità per gli sviluppatori che mantengono il client di maggioranza. Distribuire la responsabilità tra diversi team è un bene sia per la salute della rete di nodi di Ethereum che per la sua rete di persone.

Attuale diversità dei client

Grafico a torta che mostra la diversità dei client Dati del diagramma provenienti da ethernodes.org e clientdiversity.org

I due grafici a torta di cui sopra mostrano le istantanee dell'attuale diversità dei client per i livelli d'esecuzione e del consenso (al momento della scrittura di questo testo, gennaio 2022). Il livello d'esecuzione è prevalentemente dominato daGeth, con distacco sul secondo, Open Ethereum, Erigon in terza posizione e Nethermind quarto, con altri client che rappresentano meno dell'1% della rete. Il client più diffuso sul livello del consenso, Prysm, non è tanto dominante quanto Geth, ma rappresenta comunque oltre il 60% della rete. Lighthouse e Teku rappresentano rispettivamente circa il 20% e circa il 14%, e gli altri client sono poco usati.

I dati del livello d'esecuzione sono stati ottenuti da Ethernodes il 23/01/22. I dati per i client di consenso sono stati ottenuti da Michael Sproul. I dati dei client di consenso sono più difficili da ottenere perché i client della Beacon Chain non hanno sempre tracce inequivocabili, utilizzabili per identificarli. I dati sono stati generati usando un algoritmo di classificazione che talvolta confonde alcuni dei client di minoranza (vedi qui per ulteriori dettagli). Nel diagramma precedente, queste classificazioni ambigue sono trattate classificate come alternative multiple (es. Nimbus/Teku). È comunque chiaro che la maggioranza della rete sta eseguendo Prysm. I dati sono un'istantanea su una serie fissa di blocchi (in questo caso i blocchi della Beacon Chain dallo slot 2048001 al 2164916) e in alcuni momenti la dominanza di Prysm è stata anche maggiore, superando il 68%. Nonostante siano solo istantanee, i valori nel diagramma forniscono una buona indicazione generale dello stato corrente della diversità dei client.

I dati della diversità dei client aggiornati per il livello di consenso sono ora disponibili su https://clientdiversity.org/.

Livello di esecuzione

Finora, la conversazione sulla diversità dei client si è concentrata sul livello del consenso. Tuttavia, il client d'esecuzione Geth rappresenta attualmente l'85% di tutti i nodi. Questa percentuale è problematica per gli stessi motivi dei client di consenso. Ad esempio, un bug su Geth che influenzi la gestione delle transazioni o la costruzione dei carichi utili d'esecuzione potrebbe condurre alla finalizzazione da parte dei client di consenso di transazioni problematiche o contenenti bug. Ethereum sarebbe più quindi più robusto con una distribuzione più equa dei client d'esecuzione, idealmente senza alcun client che rappresenti oltre il 33% della rete.

Usare un client di minoranza

Per "indirizzare" la diversità dei client non basta che i singoli utenti scelgano i client di minoranza, richiede che anche i pool di mining/validatori e le istituzioni come le dApp principali e gli scambi cambino client. Tuttavia, tutti gli utenti possono fare la propria parte nel correggere l'attuale disequilibrio e normalizzare l'uso di tutti i software di Ethereum disponibili. Dopo La Fusione, tutti gli operatori di nodi dovranno eseguire un client d'esecuzione e un client di consenso. Scegliere le combinazioni dei client suggerite di seguito aiuterà ad aumentare la diversità dei client.

Client di esecuzione

Besu

Nethermind

Erigon

Akula

Go-Ethereum

Client di consenso

Nimbus

Lighthouse

Teku

Lodestar - In fase di revisione e controllo

Gli utenti tecnici possono aiutare ad accelerare questo processo scrivendo più tutorial e documentazioni per i client di minoranza e incoraggiando i propri peer che eseguono dei nodi a migrare dai client dominanti. Le guide per passare a un client di consenso di minoranza sono disponibili su clientdiversity.org.

Pannelli di controllo sulla diversità dei client

Diversi pannelli di controllo forniscono statistiche sulla diversità dei client in tempo reale per il livello d'esecuzione e di consenso.

Livello di consenso:

Livello di esecuzione:

Letture consigliate

Questo articolo è stato utile?