Merge pull request #12884 from ethereum/may-it-20240501163032471

chore: import translations for it

Author: wackerow

public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/reorg-schematic.svg.xlsx

@@ -50,9 +50,15 @@ Il ciclo di vita dell'attestazione è delineato nel seguente schema:
 
 ## Ricompense {#rewards}
 
-I validatori sono ricompensati per l'invio delle attestazioni. La ricompensa dell'attestazione dipende da due variabili, la `base reward` (ricompensa di base) e l'`inclusion delay` (ritardo d'inclusione). Il miglior caso per il ritardo d'inclusione è che sia pari a 1.
+I validatori sono ricompensati per l'invio delle attestazioni. La ricompensa d'attestazione dipende dai flag di partecipazione (sorgente, destinazione e testa), dalla ricompensa di base e dal tasso di partecipazione.
 
-`ricompensa d'attestazione = 7/8 x ricompensa di base x (1/ritardo d'inclusione)`
+Ogni flag di partecipazione può essere vero o falso, a seconda dell'attestazione inviata e del suo ritardo di inclusione.
+
+Lo scenario migliore si verifica quando i tre flag sono tutti veri, nel qual caso un validatore guadagnerà (per flag corretto):
+
+`ricompensa += ricompensa di base * peso del flag * tasso di attestazione del flag / 64`
+
+Il tasso di attestazione del flag si misura utilizzando la somma dei saldi effettivi di tutti i validatori attestanti per il dato flag confrontato al saldo effettivo attivo totale.
 
 ### Ricompensa di base {#base-reward}
 
@@ -78,9 +84,9 @@ Per ogni epoca ci sono in totale 16 Aggregatori. Inoltre, alcuni validatori casu
 
 Si noti che in alcuni casi un aggregatore fortunato potrebbe anche diventare il propositore di blocchi. Se l'attestazione non è stata inclusa perché il propositore di blocchi è mancante, sarebbe il propositore successivo a selezionare l'attestazione aggregata e includerla nel blocco successivo. Tuttavia, il **ritardo d'inclusione** aumenterebbe di uno.
 
-## Lettura consigliate {#further-reading}
+## Letture consigliate {#further-reading}
 
 - [Le attestazioni nelle specifiche del consenso annotate da Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
-- [Le attestazioni su eth2book.info](https://eth2book.info/altair/part3/containers/dependencies#attestationdata)
+- [Le attestazioni su eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata)
 
-_Conosci una risorsa pubblica che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_

public/content/translations/it/developers/docs/consensus-mechanisms/pos/attestations/attestation_schematic.svg.xlsx

@@ -18,7 +18,7 @@ Il proof-of-stake richiede che i nodi, noti come validatori, inviino esplicitame
 
 Il proof-of-work consuma molta più energia perché il processo di mining consumata elettricità. Il proof-of-stake, d'altra parte, richiede soltanto una piccola quantità di energia: i validatori di Ethereum possono essere eseguiti persino su un dispositivo a bassa potenza, come un Raspberry Pi. Il meccanismo di proof-of-stake di Ethereum è concepito per essere più sicuro del proof-of-work, perché il costo dell'attacco è maggiore e le conseguenze sono più severe.
 
-Il confronto proof-of-work vs. proof-of-stake è un argomento controverso. [Il blog di Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) e il dibattito tra Justin Drake e Lyn Alden hanno dato una buona sintesi delle argomentazioni.
+Il confronto proof-of-work vs. proof-of-stake è un argomento controverso. Il [blog di Vitalik Buterin](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) e il dibattito tra Justin Drake e Lyn Alden offrono una buona sintesi delle argomentazioni.
 
 <YouTube id="1m12zgJ42dI" />
 

public/content/translations/it/developers/docs/consensus-mechanisms/pos/attestations/index.md

@@ -79,7 +79,7 @@ Ethereum non è sempre stata una rete di proof-of-stake. All'inizio Ethereum uti
 
 ## Letture consigliate {#further-reading}
 
-- [FAQ Proof of Stake](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_
+- [Domande Frequenti sul Proof-of-Stake](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_
 - [Cos'è il Proof of Stake](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_
 - [Cos'è il Proof of Stake e perché è importante](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_
 - [Perché il Proof of Stake (Nov 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_

public/content/translations/it/developers/docs/consensus-mechanisms/pos/faqs/index.md

@@ -90,7 +90,7 @@ Ogni ramo è separato da uno `/`, quindi `m/2` significa iniziare con la chiave
 
 ![logica della chiave del validatore](multiple-keys.png)
 
-## Lettura consigliate {#further-reading}
+## Letture consigliate {#further-reading}
 
 - [Post del blog della Ethereum Foundation di Carl Beekhuizen](https://blog.ethereum.org/2020/05/21/keys/)
 - [Generazione delle chiavi BLS12-381 dell'EIP-2333](https://eips.ethereum.org/EIPS/eip-2333)

public/content/translations/it/developers/docs/consensus-mechanisms/pos/index.md

@@ -50,7 +50,7 @@ PROPOSER_WEIGHT uint64(8)
 
 Questi pesi ammontano a 64. La ricompensa è calcolata come la somma dei pesi applicabili, divisa per 64. Un validatore che ha effettuato tempestivi voti sull'origine, sula destinazione e sulla testa, ha proposto un blocco e ha partecipato a una commissione di sincronizzazione, potrebbe ricevere `64/64 * base_reward == base_reward`. Tuttavia, solitamente un validatore non è un propositore di blocchi, quindi la sua ricompensa massima è `64-8 /64 * base_reward == 7/8 * base_reward`. I validatori che non sono propositori di blocchi né partecipano a una commissione di sincronizzazione possono ricevere `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`.
 
-È prevista una ricompensa aggiuntiva per incentivare attestazioni rapide. Questa è la `inclusion_delay_reward`. Ha un valore pari alla `base_reward`, moltiplicata per `1/delay`, dove `delay` è il numero di slot che separano la proposta e l'attestazione del blocco. Ad esempio, se l'attestazione è inviata entro uno slot della proposta del blocco, l'attestatore riceve `base_reward * 1/1 == base_reward`. Se l'attestazione arriva nello slot successivo, l'attestatore riceve `base_reward * 1/2` e così via.
+È prevista una ricompensa aggiuntiva per incentivare attestazioni rapide. Questa è la `inclusion_delay_reward`. Ha un valore pari alla `base_reward`, moltiplicata per `1/delay`, dove `delay` è il numero di slot che separano la proposta e l'attestazione del blocco. Ad esempio, se l'attestazione è inviata entro uno slot della proposta del blocco, l'attestatore riceve `base_reward * 1/1 == base_reward`. Se l'attestazione arriva nello slot successivo, l'attestatore riceve `base_reward * 1/2`, e così via.
 
 I propositori di blocchi ricevono `8 / 64 * base_reward` per **ogni attestazione valida** inclusa nel blocco, quindi il valore effettivo della ricompensa scala con il numero di validatori attestanti. I propositori di blocchi, inoltre, possono incrementare la propria ricompensa includendo prova del comportamento scorretto di altri validatori nel loro blocco proposto. Queste ricompense sono le "carote" che incoraggiano l'onestà del validatore. Un propositore di blocchi che include il taglio sarà ricompensato con `slashed_validators_effective_balance / 512`.
 
@@ -78,7 +78,7 @@ Se il livello del consenso ha superato più di quattro epoche senza finalizzare,
 
 Il design di ricompense, sanzioni e frazionamenti del meccanismo di consenso incoraggia i singoli validatori a comportarsi correttamente. Tuttavia, da tali scelte di progettazione emerge un sistema che incentiva fortemente la distribuzione equa dei validatori tra i vari client e dovrebbe disincentivare fortemente il dominio di un singolo client.
 
-## Ulteriori letture {#further-reading}
+## Letture consigliate {#further-reading}
 
 - [Aggiornare Ethereum: Il livello d'incentivazione](https://eth2book.info/altair/part2/incentives)
 - [Incentivi nel protocollo ibrido Casper di Ethereum](https://arxiv.org/pdf/1903.04205.pdf)

public/content/translations/it/developers/docs/consensus-mechanisms/pos/keys/index.md

@@ -5,13 +5,17 @@ lang: it
 sidebarDepth: 2
 ---
 
-Un Trie di Patricia Merkle fornisce una struttura di dati autenticata crittograficamente, utilizzabile per memorizzare tutte le associazioni `(key, value)` (chiave, valore).
+Lo stato di Ethereum (la totalità di tutti i conti, i saldi e i contratti intelligenti) è codificato in una versione speciale della struttura dei dati, nota generalmente in informatica come un Albero di Merkle. Questa struttura è utile per molte applicazioni crittografiche, poiché crea una relazione verificabile tra tutti le singole parti di dati facenti parte dell'albero, dando come risultato un singolo valore di **radice** utilizzabile per provare delle cose sui dati.
 
-I Trie di Patricia Merkle sono interamente deterministici, a significare che è garantito che degli alberi con le stesse associazioni `(key, value)` siano identici, fino all'ultimo byte. Ciò significa che hanno lo stesso hash di root, fornendo il Sacro Graal dell'efficienza di `O(log(n))` per inserimenti, ricerche ed eliminazioni. Inoltre, sono più semplici da comprendere e programmare rispetto alle più complesse alternative basate sul confronto, come gli alberi rosso-nero.
+La struttura dei dati di Ethereum è un 'Trie di Merkle-Patricia modificato', così detto perché prende in prestito alcune funzionalità di PATRICIA (l'Algoritmo Pratico Per Recuperare Informazioni Codificate in Alfanumerico), e poiché è progetttato per il **recupero** efficiente dei dati che costituiscono lo stato di Ethereum.
+
+Un trie di Merkle-Patricia è deterministico e verificabile crittograficamente: il solo modo per generare una radice di stato è calcolandola da ogni singola parte dello stato, e due stati identici sono facilmente dimostrabili confrontando l'hash di radice e gli hash che hanno portato a esso (_una prova di Merkle_). Per contro, non esiste alcun modo per creare due stati differenti con lo stesso hash di radice, e qualsiasi tentativo di modificare lo stato con valori differenti risulterà in un hash della radice di stato differente. Teoricamente, questa struttura rappresenta il 'Sacro Graal' dell'efficienza di `O(log(n))` per inserimenti, ricerche ed eliminazioni.
+
+Nel prossimo futuro, Ethereum prevede di migrare a una struttura ad [Albero di Verkle](https://ethereum.org/en/roadmap/verkle-trees), che aprirà le porte a molte nuove possibilità per le future migliorie al protocollo.
 
 ## Prerequisiti {#prerequisites}
 
-Per meglio comprendere questa pagina, sarebbe utile avere una conoscenza di base di [hash](https://en.wikipedia.org/wiki/Hash_function), [alberi di Merkle](https://en.wikipedia.org/wiki/Merkle_tree), [trie](https://en.wikipedia.org/wiki/Trie) e [serializzazione](https://en.wikipedia.org/wiki/Serialization).
+Per meglio comprendere questa pagina, sarebbe utile avere una conoscenza di base di [hash](https://en.wikipedia.org/wiki/Hash_function), [alberi di Merkle](https://en.wikipedia.org/wiki/Merkle_tree), [trie](https://en.wikipedia.org/wiki/Trie) e [serializzazione](https://en.wikipedia.org/wiki/Serialization). Questo articolo si apre con una descrizione di un [albero radicato](https://en.wikipedia.org/wiki/Radix_tree) di base, introducendo poi gradualmente alle modifiche necessarie per la struttura di dati più ottimizzata di Ethereum.
 
 ## Trie della radice di base {#basic-radix-tries}
 
@@ -62,7 +66,7 @@ Le operazioni di aggiornamento ed eliminazione per gli alberi radicati sono defi
                 return hash(newnode)
 ```
 
-Un albero Radicato di "Merkle" è costruito collegando i nodi utilizzando sinossi di hash crittografici generati deterministicamente. Questo indirizzamento del contenuto (nel DB chiave/valore `key == keccak256(rlp(value))`) fornisce una garanzia dell'integrità crittografica dei dati memorizzati. Se l'hash radice di un dato albero è noto pubblicamente, allora chiunque abbia accesso ai dati delle foglie sottostanti può costruire una prova che l'albero include un dato valore a un percorso specifico, fornendo gli hash di ogni nodo che unisce un valore specifico alla radice dell'albero.
+Un albero Radicato di "Merkle" è costruito collegando i nodi utilizzando sinossi di hash crittografici generati deterministicamente. Questo indirizzamento del contenuto (nel DB chiave/valore `key == keccak256(rlp(value))`) fornisce una garanzia dell'integrità crittografica dei dati memorizzati. Se l'hash radice di un dato albero è noto pubblicamente,  allora chiunque abbia accesso ai dati delle foglie sottostanti può costruire  una prova che l'albero include un dato valore a un percorso specifico, fornendo gli hash di ogni nodo che unisce un valore specifico alla radice dell'albero.
 
 È impossibile, per un utente malevolo, fornire una prova di una coppia `(percorso, valore)` che non esiste, poiché l'hash radice in definitiva si basa su tutti gli hash inferiori. Qualsiasi modifica sottostante modificherebbe l'hash radice. Si può pensare all'hash come una rappresentazione compressa delle informazioni strutturali sui dati, assicurata da una protezione pre-immagine della funzione di hashing.
 
@@ -93,12 +97,12 @@ Attraversando i percorsi in "nibble", potremmo finire con un numero dispari di n
 
 Il flagging sia _della lunghezza del percorso parziale rimanente, dispari o pari,_ sia del _nodo leaf o estensione_, come descritto sopra, risiede nel primo nibble del percorso parziale di qualsiasi nodo di 2 elementi. Il risultato è il seguente:
 
-    char hex    bit    |    parziale tipo nodo     lungh percorso
+    hex char    bits    |    node type partial     path length
     ----------------------------------------------------------
-       0        0000    |       estensione              pari
-       1        0001    |       estensione              dispari
-       2        0010    |   terminazione (leaf)         pari
-       3        0011    |   terminazione (leaf)         dispari
+       0        0000    |       extension              even
+       1        0001    |       extension              odd
+       2        0010    |   terminating (leaf)         even
+       3        0011    |   terminating (leaf)         odd
 
 per la lunghezza del percorso rimanente pari (`0` or `2`), seguirà sempre un altro nibble di "padding" `0`.
 
@@ -112,7 +116,7 @@ per la lunghezza del percorso rimanente pari (`0` or `2`), seguirà sempre un al
             hexarray = [flags] + hexarray
         else:
             hexarray = [flags] + [0] + hexarray
-        // hexarray ha ora una lunghezza pari, il cui primo nibble si compone dei flag.
+        // hexarray now has an even length whose first nibble is the flags.
         o = ''
         for i in range(0,len(hexarray),2):
             o += chr(16 * hexarray[i] + hexarray[i+1])