diff --git a/public/content/translations/it/bridges/index.md b/public/content/translations/it/bridges/index.md
index 2bfc863783d..4a25cd173a7 100644
--- a/public/content/translations/it/bridges/index.md
+++ b/public/content/translations/it/bridges/index.md
@@ -63,7 +63,7 @@ Diciamo che vuoi possedere Bitcoin (BTC) nativi, ma hai fondi soltanto sulla Ret
- Inoltre, puoi fare tutto quanto descritto sopra, usando una [borsa centralizzata](/get-eth/). Tuttavia, a meno che i tuoi fondi non siano già su una borsa, comporterebbe diversi passaggi, e sarebbe più conveniente usare un ponte.
+ Inoltre, puoi fare tutto quanto descritto sopra, usando una [borsa centralizzata](/get-eth). Tuttavia, a meno che i tuoi fondi non siano già su una borsa, comporterebbe diversi passaggi, e sarebbe più conveniente usare un ponte.
diff --git a/public/content/translations/it/community/grants/index.md b/public/content/translations/it/community/grants/index.md
index 1312d04005a..2d6d26e7ac0 100644
--- a/public/content/translations/it/community/grants/index.md
+++ b/public/content/translations/it/community/grants/index.md
@@ -20,7 +20,7 @@ Questi programmi supportano il grande ecosistema di Ethereum offrendo sovvenzion
- [Sovvenzioni accademiche](https://esp.ethereum.foundation/academic-grants) - _Sovvenzioni per sostenere il lavoro accademico correlato a Ethereum_
- [Grantfarm di Blockworks](https://blockworks.co/grants/programs) - _Blockworks ha compilato una directory esaustiva di tutte le sovvenzioni, RDP e bug bounty._
-## Programmi per progetti specifici {#project-specific}
+## Programmi per progetti specifici {#grant-list-aggregators}
Questi progetti hanno creato le proprie sovvenzioni per progetti volti a sviluppare e sperimentare la propria tecnologia.
@@ -35,13 +35,13 @@ Questi progetti hanno creato le proprie sovvenzioni per progetti volti a svilupp
- [The Graph](https://thegraph.com/ecosystem/grants/): _Ecosistema di [The Graph](https://thegraph.com/)_
- [Programma di sovvenzioni di Uniswap](https://www.uniswapfoundation.org/approach): _community di [Uniswap](https://uniswap.org/)_
-## Finanziamento quadratico {#quadratic-funding}
+## Finanziamento quadratico {#comprehensive-directories}
Le radici dell'open source di Ethereum hanno portato alla crescita di un nuovo modello interessante di raccolta fondi: il finanziamento quadratico. Questo finanziamento ha il potenziale di migliorare il modo in cui finanzieremo tutti i tipi di beni pubblici in futuro. Il finanziamento quadratico assicura che i progetti che riceveranno più finanziamenti siano quelli con la domanda più esclusiva. In sintesi, i progetti che cercano di migliorare la vita del maggior numero di persone. [Maggiori informazioni sul finanziamento quadratico.](/defi/#quadratic-funding)
- [Gitcoin](https://gitcoin.co/grants)
- [clr.fund](https://clr.fund/)
-## Lavora su Ethereum {#work-in-ethereum}
+## Lavora su Ethereum {#for-developers-and-builders}
Non sei pronto per iniziare il tuo progetto? Ci sono centinaia di aziende che cercano attivamente persone appassionate con cui lavorare e contribuire all'ecosistema Ethereum. Cerchi maggiori informazioni? [Dai un'occhiata ai lavori relativi a Ethereum](/community/get-involved/#ethereum-jobs)
diff --git a/public/content/translations/it/community/online/index.md b/public/content/translations/it/community/online/index.md
index 6f38b657f11..8a75d8f69e7 100644
--- a/public/content/translations/it/community/online/index.md
+++ b/public/content/translations/it/community/online/index.md
@@ -71,5 +71,5 @@ Se credi che una community dovrebbe essere aggiunta o rimossa secondo queste lin
Maggiori informazioni sulle DAO
-
+
diff --git a/public/content/translations/it/community/research/index.md b/public/content/translations/it/community/research/index.md
index 61e2c88901e..ce50934e2d4 100644
--- a/public/content/translations/it/community/research/index.md
+++ b/public/content/translations/it/community/research/index.md
@@ -242,7 +242,7 @@ I mercati degli spazi di blocco governano l'inclusione delle transazioni dell'ut
- [Progettazione del meccanismo delle commissioni sulle transazioni per la blockchain di Ethereum: un'analisi economica di EIP-1559 (Tim Roughgarden, 2020)](https://timroughgarden.org/papers/eip1559.pdf)
- [Simulazioni di EIP-1559 (Gruppo di incentivi robusti)](https://ethereum.github.io/abm1559)
- [Economia dei rollup dai primi principi](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url)
-- [Flash Boys 2.0: frontrunning, riordinamento delle transazioni e instabilità del consenso nelle borse decentralizzate] (https://arxiv.org/abs/1904.05234)
+- [Flash Boys 2.0: frontrunning, riordinamento delle transazioni e instabilità del consenso nelle borse decentralizzate](https://arxiv.org/abs/1904.05234)
#### Ricerca recente {#recent-research-10}
diff --git a/public/content/translations/it/contributing/design/adding-design-resources/index.md b/public/content/translations/it/contributing/design/adding-design-resources/index.md
index f696b61a581..e5cf27c42f7 100644
--- a/public/content/translations/it/contributing/design/adding-design-resources/index.md
+++ b/public/content/translations/it/contributing/design/adding-design-resources/index.md
@@ -1,6 +1,6 @@
---
title: Aggiungere risorse di progettazione
-description: Linee guida e requisiti per assicurare la qualità dei materiali di progettazione su ethereum.org
+description: "Linee guida e requisiti per assicurare la qualità dei materiali di progettazione su ethereum.org"
lang: it
---
diff --git a/public/content/translations/it/contributing/index.md b/public/content/translations/it/contributing/index.md
index bc5f4e1f2b4..e38f0602fb1 100644
--- a/public/content/translations/it/contributing/index.md
+++ b/public/content/translations/it/contributing/index.md
@@ -4,7 +4,7 @@ description: Scopri i vari modi in cui puoi contribuire a ethereum.org
lang: it
---
-# Contribuire a ethereum.org {#contributing-to-ethereumorg}
+# Contribuire a ethereum.org {#contributing-to-ethereumorg}
Ethereum.org è un progetto open source con oltre **12000** collaboratori che aiutano a tradurre, scrivere, progettare e mantenere il sito web.
@@ -90,6 +90,7 @@ Se il tuo contributo viene aggiunto a ethereum.org, avrai una possibilità di ri
[Maggiori informazioni sui OAT](https://help.galxe.com/en/articles/9645630-create-quest-rewards#h_1c5d63ba03)
### Come reclamare
+
1. Unisciti al nostro [server Discord](https://discord.gg/ethereum-org).
2. Incolla un link ai tuoi contributi nel canale `#🥇 | proof-of-contribution`.
3. Attendi che un membro del nostro team ti invii un collegamento al tuo OAT.
diff --git a/public/content/translations/it/dao/index.md b/public/content/translations/it/dao/index.md
index 4c3071f0bf0..77019dfb643 100644
--- a/public/content/translations/it/dao/index.md
+++ b/public/content/translations/it/dao/index.md
@@ -1,11 +1,11 @@
---
-title: Cos'è una DAO?
-metaTitle: Cos'è una DAO? | Organizzazione autonoma decentralizzata
+title: "Cos'è una DAO?"
+metaTitle: "Cos'è una DAO? | Organizzazione autonoma decentralizzata"
description: Una panoramica delle DAO su Ethereum
lang: it
template: use-cases
emoji: ":handshake:"
-sidebarDepth: 3
+sidebarDepth: 2
image: /images/use-cases/dao-2.png
alt: Rappresentazione di una votazione DAO su una proposta.
summaryPoint1: Community posseduta dai membri, prive di leadership centralizzata.
@@ -19,7 +19,7 @@ Una DAO è un'organizzazione posseduta collettivamente che opera per realizzare
Le DAO ci consentono di lavorare con persone con la stessa mentalità provenienti da tutto il mondo, senza doversi fidare di un capo benevolo, per la gestione di fondi od operazioni. Non esiste alcun CEO che possa spendere i fondi secondo i propri capricci, o CFO che possa manipolare i libri contabili. Invece, le regole basate sulla blockchain, integrate nel codice, definiscono il funzionamento dell'organizzazione e come vengono spesi i fondi.
-Contengono delle tesoriere integrate, a cui nessuno ha l'autorità di accedere senza l'approvazione del gruppo. Le decisioni sono governate da proposte e votazioni, per assicurarsi che tutti nell'organizzazione abbiano voce in capitolo, e che tutto si verifichi in modo trasparente [sulla catena](/glossary/#on-chain).
+Contengono delle tesoriere integrate, a cui nessuno ha l'autorità di accedere senza l'approvazione del gruppo. Le decisioni sono governate da proposte e votazioni, per assicurarsi che tutti nell'organizzazione abbiano voce in capitolo, e che tutto si verifichi in modo trasparente [sulla catena](/glossary/#onchain).
## Perché abbiamo bisogno delle DAO? {#why-dao}
@@ -70,9 +70,7 @@ Ci sono molte considerazioni da fare governando una DAO, ad esempio, come funzio
Una delegazione è la versione della democrazia rappresentativa della DAO. I titolari di token delegano i voti agli utenti da loro stessi nominati e si impegnano a gestire il protocollo e a rimanere informati.
-#### Un celebre esempio {#governance-example}
-
-[ENS](https://claim.ens.domains/delegate-ranking) – I titolari di ENS possono delegare i propri voti a membri impegnati della community perché li rappresentino.
+#### Un celebre esempio {#governance-example}[ENS](https://claim.ens.domains/delegate-ranking) – I titolari di ENS possono delegare i propri voti a membri impegnati della community perché li rappresentino.
### Governance automatica delle transazioni {#governance-example}
diff --git a/public/content/translations/it/decentralized-identity/index.md b/public/content/translations/it/decentralized-identity/index.md
index 75457fe89fd..e57da4d582a 100644
--- a/public/content/translations/it/decentralized-identity/index.md
+++ b/public/content/translations/it/decentralized-identity/index.md
@@ -1,13 +1,13 @@
---
-title: Identità decentralizzata
-description: Cos'è l'identità decentralizzata e perché è importante?
+title: "Identità decentralizzata"
+description: "Cos'è l'identità decentralizzata e perché è importante?"
lang: it
template: use-cases
emoji: ":id:"
sidebarDepth: 2
image: /images/eth-gif-cat.png
-summaryPoint1: I sistemi di identità tradizionali hanno centralizzato l'emissione, manutenzione e controllo dei tuoi identificativi.
-summaryPoint2: L'identità decentralizzata rimuove la dipendenza da terze parti centralizzate.
+summaryPoint1: "I sistemi di identità tradizionali hanno centralizzato l'emissione, manutenzione e controllo dei tuoi identificativi."
+summaryPoint2: "L'identità decentralizzata rimuove la dipendenza da terze parti centralizzate."
summaryPoint3: Grazie alle cripto, gli utenti, ora, hanno nuovamente gli strumenti per emettere, detenere e controllare i propri identificativi e attestazioni.
---
@@ -75,13 +75,13 @@ L'identità decentralizzata può aiutare a creare delle community online prive d
Le applicazioni di concessione di sovvenzioni che utilizzano il [voto quadratico](/glossary/#quadratic-voting) sono vulnerabili agli [attacchi Sybil](/glossary/#sybil-attack) poiché il valore di una sovvenzione viene incrementato all'aumentare delle persone che votano, incentivando gli utenti a dividere i propri contributi tra più identità. Le identità decentralizzate aiutano a prevenirli, incrementando l'onere su ogni partecipante, per dimostrare che siano realmente umani, sebbene spesso senza dover rilevare informazioni private specifiche.
-## Cosa sono le attestazioni? {#what-are-attestations}
+## Cosa sono le attestazioni? {#national-and-government-id}
Un'attestazione, è una dichiarazione effettuata da un'entità, in merito a un'altra entità. Se vivi in Italia, la patente di guida rilasciata dal Dipartimento dei Trasporti Terrestri (un'entità), attesta che tu (un'altra entità), sei legalmente autorizzato a guidare un'auto.
Le attestazioni sono differenti dagli identificativi. Un'attestazione _contiene_ degli identificativi, riferiti a un'identità in particolare, ed effettua una dichiarazione su di un attributo, relativo a tale identità. Quindi, la tua patente di guida contiene degli identificativi (nome, data di nascita, indirizzo), ma è anche l'attestazione sul tuo diritto legale alla guida.
-### Cosa sono gli identificativi decentralizzati? {#what-are-decentralized-identifiers}
+### Cosa sono gli identificativi decentralizzati? {#case-study-bhutan-ndi}
Gli identificativi tradizionali, come il tuo nome legale o l'indirizzo email, si affidano a terze parti: governi e fornitori di email. Gli identificativi decentralizzati (DID), sono differenti: non sono emessi, gestiti o controllati da alcuna entità centrale.
@@ -89,21 +89,21 @@ Gli identificativi decentralizzati sono emessi, detenuti e controllati dagli ind
Gli identificativi decentralizzati sono memorizzati su libri mastri distribuiti ([blockchain](/glossary/#blockchain)) o su [reti peer-to-peer](/glossary/#peer-to-peer-network). Ciò rende i DID [unici a livello globale, risolvibili con elevata disponibilità e crittograficamente verificabili](https://w3c-ccg.github.io/did-primer/). Un identificativo decentralizzato può essere associato a diverse entità, tra cui persone, organizzazioni, o istituzioni governative.
-## Cosa rende possibili gli identificativi decentralizzati? {#what-makes-decentralized-identifiers-possible}
+## Cosa rende possibili gli identificativi decentralizzati? {#case-study-buenos-aires-quarkid}
-### 1. Crittografia a chiave pubblica {#public-key-cryptography}
+### 1. Crittografia a chiave pubblica {#what-are-attestations}
La crittografia a chiave pubblica è una misura di sicurezza informatica che genera una [chiave pubblica](/glossary/#public-key) e una [chiave privata](/glossary/#private-key) per un'entità. La [crittografia](/glossary/#cryptography) a chiave pubblica è utilizzata nelle reti blockchain per autenticare le identità degli utenti e dimostrare la proprietà delle risorse digitali.
Alcuni identificativi decentralizzati, come un conto di Ethereum, includono chiavi pubbliche e private. La chiave pubblica identifica chi controlla il conto, mentre le chiavi private possono firmare e decrittografare i messaggi per tale conto. La crittografia a chiave pubblica fornisce le prove necessarie per autenticare le entità, oltre a prevenire i furti d'identità e l'utilizzo di false identità, utilizzando le [firme crittografiche](https://andersbrownworth.com/blockchain/public-private-keys/) per verificare tutte le dichiarazioni.
-### 2. Datastore decentralizzati {#decentralized-datastores}
+### 2. Datastore decentralizzati {#what-are-decentralized-identifiers}
Una blockchain funge da registro di dati verificabili: una repository di informazioni aperta, affidabile e decentralizzata. L'esistenza delle blockchain pubbliche elimina l'esigenza di memorizzare gli identificativi nei registri centralizzati.
Se qualcuno deve confermare la validità di un identificativo decentralizzato, può consultare la chiave pubblica associata sulla blockchain. Ciò differisce dagli identificativi tradizionali, che richiedono l'autenticazione da parte di terzi.
-## Come fanno le attestazioni e gli identificativi decentralizzati a consentire l'identità decentralizzata? {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity}
+## Come fanno le attestazioni e gli identificativi decentralizzati a consentire l'identità decentralizzata? {#what-makes-decentralized-identifiers-possible}
L'identità decentralizzata è l'idea che le informazioni sull'identità dovrebbero essere controllate dall'individuo, private e portatili, con attestazioni e identificativi decentralizzati come blocchi di costruzione principali.
@@ -115,11 +115,11 @@ Gli identificativi decentralizzati sono il motivo per cui le attestazioni sono c
Inoltre, gli identificativi decentralizzati sono fondamentali per la protezione della privacy delle informazioni personali, tramite l'identità decentralizzata. Ad esempio, se un individuo invia la prova di un'attestazione (una patente di guida), la parte che verifica non necessita di controllare la validità delle informazioni nella prova. Invece, chi verifica necessita soltanto delle garanzie crittografiche dell'autenticità dell'attestazione, e dell'identità dell'organizzazione emittente, per determinare se la prova sia valida.
-## Tipi di attestazioni nell'identità decentralizzata {#types-of-attestations-in-decentralized-identity}
+## Tipi di attestazioni nell'identità decentralizzata {#public-key-cryptography}
Le modalità di memorizzazione e recupero delle informazioni sull'attestazione, nell'ecosistema delle identità basato su Ethereum, differiscono dalla gestione tradizionale delle identità. Ecco una panoramica dei vari approcci all'emissione, memorizzazione e verifica delle attestazioni, nei sistemi di identità decentralizzati:
-### Attestazioni esterne alla catena {#off-chain-attestations}
+### Attestazioni esterne alla catena {#decentralized-datastores}
Un timore per la memorizzazione su catena è che potrebbero contenere informazioni che gli individui desiderano mantenere private. La natura pubblica della blockchain di Ethereum, rende poco attraente la memorizzazione di tali attestazioni.
@@ -131,13 +131,13 @@ Ecco uno scenario ipotetico per spiegare le attestazioni esterne alla catena:
2. Bob si candida per un lavoro e desidera dimostrare le proprie qualifiche accademiche a un datore di lavoro, quindi, condivide l'attestazione dal proprio portafoglio mobile. L'azienda (verificatore), può quindi confermare la validità dell'attestazione, verificando il DID dell'emittente (cioè, la sua chiave pubblica su Ethereum).
-### Attestazioni esterne alla catena con accesso persistente {#offchain-attestations-with-persistent-access}
+### Attestazioni esterne alla catena con accesso persistente {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity}
In questo modo, le attestazioni sono trasformate in file JSON e memorizzate all'esterno della catena (idealmente, su una piattaforma di [archiviazione decentralizzata su cloud](/developers/docs/storage/), come IPFS o Swarm). Tuttavia, un [hash](/glossary/#hash) del file JSON è memorizzato sulla catena e collegato a un DID, tramite il registro sulla catena. Il DID associato potrebbe essere quello dell'emittente dell'attestazione, o del destinatario.
Tale approccio consente alle attestazioni di ottenere persistenza basata sulla blockchain, mantenendo le informazioni delle dichiarazioni, crittografate e verificabili. Inoltre, consente la divulgazione selettiva, poiché il titolare della chiave privata può decrittografare le informazioni.
-### Attestazioni sulla catena {#onchain-attestations}
+### Attestazioni sulla catena {#types-of-attestations-in-decentralized-identity}
Le attestazioni sulla catena sono conservate nei [contratti intelligenti](/glossary/#smart-contract) sulla blockchain di Ethereum. Il contratto intelligente (che agisce da registro), mapperà un'attestazione a un identificativo decentralizzato corrispondente sulla catena (una chiave pubblica).
@@ -149,11 +149,11 @@ Ecco un esempio per dimostrare il funzionamento in pratica delle attestazioni su
3. Il contratto intelligente che vende le quote, può verificare il contratto del registro per le identità degli acquirenti verificati, rendendo possibile la determinazione di chi possa acquistare le quote e chi no.
-### Token vincolati e identità {#soulbound}
+### Token vincolati e identità {#offchain-attestations}
I [token vincolati](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([NFT non trasferibili](/glossary/#nft)) potrebbero essere utilizzati per raccogliere informazioni univoche per un portafoglio specifico. Ciò, effettivamente, crea un'identità univoca sulla catena, vincolata a un indirizzo di Ethereum in particolare, che potrebbe includere i token rappresentanti obiettivi (ad esempio, concludere un certo corso online o superare una soglia di punteggio in un gioco), o la partecipazione della community.
-## Utilizzare l'identità decentralizzata {#use-decentralized-identity}
+## Utilizzare l'identità decentralizzata {#offchain-attestations-with-persistent-access}
Esistono molti progetti ambiziosi che utilizzano Ethereum come base per le soluzioni di identità decentralizzata:
@@ -165,9 +165,9 @@ Esistono molti progetti ambiziosi che utilizzano Ethereum come base per le soluz
- **[walt.id](https://walt.id)**: _Infrastruttura open source di identità decentralizzata e portafoglio che consente a sviluppatori e organizzazioni di sfruttare l'identità auto-sovrana e gli NFT/SBT._
- **[Veramo](https://veramo.io/)**: _Un framework di JavaScript che facilita per tutti l'utilizzo di dati verificabili crittograficamente nelle proprie applicazioni._
-## Lettura consigliate {#further-reading}
+## Lettura consigliate {#onchain-attestations}
-### Articoli {#articles}
+### Articoli {#soulbound}
- [Casi d'Uso della Blockchain: La Blockchain nell'Identità Digitale](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_
- [Cos'è l'ERC-725 di Ethereum? Gestione dell'Identità Sovrana Personale sulla Blockchain](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_
@@ -175,7 +175,7 @@ Esistono molti progetti ambiziosi che utilizzano Ethereum come base per le soluz
- [Cos'è l'Identità Decentralizzata e Perché Dovrebbe Interessarti?](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_
- [Introduzione all'Identità decentralizzata](https://walt.id/white-paper/digital-identity) - _Dominik Beron_
-### Video {#videos}
+### Video {#use-decentralized-identity}
- [Identità Decentralizzata (Sessione Live Bonus)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Un ottimo video esplicativo sull'identità decentralizzata, di Andreas Antonopolous_
- [Accedi con Ethereum e l'Identità Decentralizzata con Ceramic, IDX, React e 3ID Connect](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Tutorial di YouTube sulla creazione di un sistema di gestione dell'identità, per creare, leggere e aggiornare il profilo di un utente, utilizzandone il portafoglio di Ethereum; di Nader Dabit_
@@ -183,7 +183,7 @@ Esistono molti progetti ambiziosi che utilizzano Ethereum come base per le soluz
- [L'Internet esterno alla Catena: Identità Decentralizzata e Credenziali Verificabili](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Presentazione dell'EthDenver del 2022, di Evin McMullen
- [Credenziali verificabili spiegate](https://www.youtube.com/watch?v=ce1IdSr-Kig): Video esplicativo su YouTube con dimostrazione di Tamino Baumann
-### Community {#communities}
+### Community {#further-reading}
- [ERC-725 Alliance su GitHub](https://github.com/erc725alliance) — _Sostenitori dello standard ERC-725 per la gestione dell'identità sulla blockchain di Ethereum_
- [Server Discord di EthID](https://discord.com/invite/ZUyG3mSXFD) — _Community per appassionati e sviluppatori, al lavoro su "Accedi con Ethereum"_
diff --git a/public/content/translations/it/defi/index.md b/public/content/translations/it/defi/index.md
index 9d2ae0086cd..5e48954491e 100644
--- a/public/content/translations/it/defi/index.md
+++ b/public/content/translations/it/defi/index.md
@@ -1,16 +1,16 @@
---
title: Finanza decentralizzata (DeFi)
-metaTitle: Cos'è la DeFi? | Benefici e utilizzi della finanza decentralizzata
+metaTitle: "Cos'è la DeFi? | Benefici e utilizzi della finanza decentralizzata"
description: Una panoramica sulla DeFi su Ethereum
lang: it
template: use-cases
emoji: ":money_with_wings:"
image: /images/use-cases/defi.png
alt: Logo di Eth, composto da mattoncini Lego.
-sidebarDepth: 3
+sidebarDepth: 2
summaryPoint1: Un'alternativa globale e aperta al sistema finanziario odierno.
summaryPoint2: Prodotti che ti consentono di prendere in prestito, risparmiare, investire, scambiare, e molto altro.
-summaryPoint3: Basata sulla tecnologia open source, con cui chiunque può programmare.
+summaryPoint3: "Basata sulla tecnologia open source, con cui chiunque può programmare."
---
La DeFi è un sistema finanziario aperto e globale, creato per l'era di Internet: un'alternativa a un sistema opaco, rigidamente controllato e tenuto insieme da infrastrutture e processi vecchi di decenni. Offre il controllo e la visibilità sul proprio denaro. Fornisce esposizione ai mercati globali e alternative alla tua valuta o alle opzioni bancarie locali. I prodotti della DeFi aprono i servizi finanziari a chiunque abbia una connessione a Internet, e sono prevalentemente posseduti e mantenuti dai loro utenti. Finora, decine di miliardi di dollari in criptovalute, sono confluiti per le applicazioni della DeFi, e crescono ogni giorno.
diff --git a/public/content/translations/it/developers/docs/apis/json-rpc/index.md b/public/content/translations/it/developers/docs/apis/json-rpc/index.md
index 9f2295b0800..3620b4aa658 100644
--- a/public/content/translations/it/developers/docs/apis/json-rpc/index.md
+++ b/public/content/translations/it/developers/docs/apis/json-rpc/index.md
@@ -58,7 +58,7 @@ Ecco alcuni esempi:
- ERRATO: 0xf0f0f (dev'essere un numero di cifre pari)
- ERRATO: 004200 (deve avere il prefisso 0x)
-### Il parametro del blocco predefinito {#default-block}
+### Il parametro del blocco predefinito {#block-parameter}
I seguenti metodi hanno un parametro del blocco predefinito aggiuntivo:
@@ -566,7 +566,7 @@ Restituisce il saldo del conto del dato indirizzo.
**Parametri**
1. `DATA`, 20 byte - indirizzo per controllare il saldo.
-2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block)
+2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
@@ -597,7 +597,7 @@ Restituisce il valore da una posizione di archiviazione a un dato indirizzo.
1. `DATA`, 20 byte - Indirizzo di archiviazione.
2. `QUANTITY` - intero della posizione di archiviazione.
-3. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block)
+3. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter)
**Restituisce**
@@ -663,7 +663,7 @@ Restituisce il numero di transazioni _inviate_da un indirizzo.
**Parametri**
1. `DATA`, 20 byte - indirizzo.
-2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block)
+2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -724,7 +724,7 @@ Restituisce il numero di transazioni in un blocco corrispondente al numero di bl
**Parametri**
-1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block).
+1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter).
```js
params: [
@@ -784,7 +784,7 @@ Restituisce il numero di ommer in un blocco da un blocco che corrisponde all'has
**Parametri**
-1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block)
+1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -816,7 +816,7 @@ Restituisce il codice ad un dato indirizzo.
**Parametri**
1. `DATA`, 20 byte - indirizzo
-2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block)
+2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -1003,7 +1003,7 @@ Esegue immediatamente una nuova chiamata di messaggio senza creare una transazio
- `value`: `QUANTITY` - (facoltativo) Intero del valore inviato con questa transazione
- `input`: `DATA` - (facoltativo) Hash della firma del metodo e dei parametri codificati. Per i dettagli, consulta [ABI del Contratto di Ethereum nella documentazione di Solidity](https://docs.soliditylang.org/en/latest/abi-spec.html).
-2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block)
+2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter)
**Restituisce**
@@ -1130,7 +1130,7 @@ Restituisce informazioni su un blocco per numero di blocco.
**Parametri**
-1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block).
+1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter).
2. `Boolean` - Se `true` restituisce gli oggetti di transazione completi, se `falso` solo gli hash delle transazioni.
```js
@@ -1243,7 +1243,7 @@ Restituisce informazioni su una transazione per hash del blocco e posizione dell
**Parametri**
-1. `QUANTITY|TAG`: il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block).
+1. `QUANTITY|TAG`: il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter).
2. `QUANTITY` - la posizione dell'indice della transazione.
```js
@@ -1366,7 +1366,7 @@ Restituisce informazioni su un ommer di un blocco in base al numero e alla posiz
**Parametri**
-1. `QUANTITY|TAG` - il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, come nel [parametro predefinito del blocco](/developers/docs/apis/json-rpc/#default-block).
+1. `QUANTITY|TAG` - il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, come nel [parametro predefinito del blocco](/developers/docs/apis/json-rpc/#block-parameter).
2. `QUANTITY` - la posizione dell'indice dell'ommer.
```js
diff --git a/public/content/translations/it/developers/docs/blocks/index.md b/public/content/translations/it/developers/docs/blocks/index.md
index ff09aa44f91..2492628c912 100644
--- a/public/content/translations/it/developers/docs/blocks/index.md
+++ b/public/content/translations/it/developers/docs/blocks/index.md
@@ -24,7 +24,7 @@ Per preservare la cronologia delle transazioni, i blocchi sono ordinati in modo
Dopo essere stato realizzato da un validatore della rete selezionato casualmente, un blocco viene propagato al resto della rete; tutti i nodi vengono aggiunti al blocco alla fine della relativa blockchain e un nuovo validatore viene selezionato per creare il successivo. Il processo esatto di costruzione dei blocchi e il processo di invio/consenso è attualmente specificato nel protocollo "Proof of Stake" di Ethereum.
-## Protocollo Proof of Stake {#proof-of-work-protocol}
+## Protocollo Proof of Stake {#proof-of-stake-protocol}
Proof of Stake significa quanto segue:
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/index.md
index 386539afe5f..850ae659f73 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/index.md
@@ -4,11 +4,11 @@ description: Spiegazione dei protocolli di consenso nei sistemi distribuiti e ru
lang: it
---
-Il termine 'meccanismo di consenso' è usato spesso in modo colloquiale per far riferimento ai protocolli 'Proof of Stake', 'Proof of Work' o 'proof-of-authority'. Tuttavia, questi sono semplicemente dei componenti nel meccanismo di consenso che proteggono dagli [attacchi Sybil](/glossary/#sybil-attack). I meccanismi di consenso sono l'insieme completo di idee, protocolli e incentivi che consentono a una serie distribuita di nodi di acconsentire sullo stato di una blockchain.
+Il termine 'meccanismo di consenso' è usato spesso in modo colloquiale per far riferimento ai protocolli 'Proof of Stake', 'Proof of Work' o 'proof-of-authority'. Tuttavia, questi sono solo componenti nei meccanismi di consenso che proteggono dagli [attacchi Sybil](/glossary/#sybil-attack). I meccanismi di consenso sono l'insieme completo di idee, protocolli e incentivi che consentono a una serie distribuita di nodi di acconsentire sullo stato di una blockchain.
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, consigliamo innanzitutto di legere l'[introduzione a Ethereum](/developers/docs/intro-to-ethereum/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima la nostra [introduzione a Ethereum](/developers/docs/intro-to-ethereum/).
## Che cos'è il consenso? {#what-is-consensus}
@@ -30,25 +30,25 @@ Questi componenti costituiscono nel loro complesso il meccanismo di consenso.
## Tipi di meccanismi di consenso {#types-of-consensus-mechanisms}
-### Basato sul Proof of Work {#proof-of-work}
+### Basati su proof-of-work {#proof-of-work}
-Come Bitcoin, Ethereum in precedenza utilizzava un protocollo di consenso basato sul **Proof of Work (PoW)**.
+Come Bitcoin, Ethereum in precedenza utilizzava un protocollo di consenso basato su **proof-of-work (PoW)**.
-#### Creazione di blocchi {#pow-block-creation}
+#### Creazione del blocco {#pow-block-creation}
-I miner competono per creare nuovi blocchi, riempiti di transazioni elaborate. Il vincitore condivide il nuovo blocco con il resto della rete e guadagna ETH appena coniati. La gara è vinta dal computer che è capace di risolvere più velocemente un rompicapo matematico. Ciò produce il collegamento crittografico tra il blocco corrente e quello precedente. Risolvere questo rompicapo rappresenta il lavoro da svolgere nel modello "proof-of-work". La catena canonica è quindi determinata da una regola di scelta della biforcazione, che seleziona la serie di blocchi che ha richiesto il maggiore lavoro per essere minata.
+I miner competono per creare nuovi blocchi, riempiti di transazioni elaborate. Il vincitore condivide il nuovo blocco con il resto della rete e guadagna ETH freschi di conio. La gara è vinta dal computer che è capace di risolvere più velocemente un rompicapo matematico. Ciò produce il collegamento crittografico tra il blocco corrente e quello precedente. Risolvere questo rompicapo rappresenta il lavoro da svolgere nel modello "proof-of-work". La catena canonica è quindi determinata da una regola di scelta della biforcazione, che seleziona la serie di blocchi che ha richiesto il maggiore lavoro per essere minata.
#### Sicurezza {#pow-security}
La sicurezza della rete è garantita dal fatto che occorrerebbe il 51% della potenza totale di elaborazione della rete per frodare la catena. Ciò richiederebbe investimenti ingenti in attrezzature ed energia; con tutta probabilità spenderesti di più del possibile guadagno.
-Maggiori informazioni sul [Proof of Work](/developers/docs/consensus-mechanisms/pow/)
+Maggiori informazioni su [proof-of-work](/developers/docs/consensus-mechanisms/pow/)
-### Basato sul Proof of Stake {#proof-of-stake}
+### Basati su proof-of-stake {#proof-of-stake}
-Ora Ethereum utilizza un protocollo di consenso basato sul **Proof of Stake (PoS)**.
+Ora Ethereum utilizza un protocollo di consenso basato su **proof-of-stake (PoS)**.
-#### Creazione di blocchi {#pos-block-creation}
+#### Creazione del blocco {#pos-block-creation}
I validatori creano i blocchi. Per ogni slot viene selezionato casualmente un validatore che funge da propositore di blocchi. Il client di consenso dei validatori richiede un pacchetto di transazioni come 'payload di esecuzione' dal client di esecuzione associato. Questo viene avvolto in dati di consenso per formare un blocco, che viene inviato ad altri nodi sulla rete Ethereum. La produzione di questo blocco è ricompensata in ETH. Nei rari casi in cui esistono diversi blocchi possibili per un singolo slot, o in cui i nodi vengono a conoscenza dei blocchi in momenti diversi, l'algoritmo di scelta della diramazione seleziona il blocco che forma la catena con il maggiore peso di attestazioni (dove il peso è il numero di validatori che attestano, scalato per il loro saldo di ETH).
@@ -56,37 +56,37 @@ I validatori creano i blocchi. Per ogni slot viene selezionato casualmente un va
Un sistema di Proof of Stake è cripto-economicamente sicuro poiché un utente malevolo che tenta di prendere il controllo della catena deve distruggere un'enorme quantità di ETH. Un sistema di ricompense incentiva i singoli staker a comportarsi onestamente e le sanzioni disincentivano gli staker dall'agire in modo malevolo.
-Maggiori informazioni sul [Proof of Stake](/developers/docs/consensus-mechanisms/pos/)
+Maggiori informazioni su [proof-of-stake](/developers/docs/consensus-mechanisms/pos/)
### Una guida visiva {#types-of-consensus-video}
-Scopri altri contenuti sui diversi tipi di meccanismi di consenso usati su Ethereum:
+Scopri altri contenuti sui diversi tipi di meccanismi di consenso usati in Ethereum:
-### Resistenza di Sybil e selezione della catena {#sybil-chain}
+### Resistenza a Sybil e selezione della catena {#sybil-chain}
Il Proof of Work e il Proof of Stake non sono di per sé protocolli di consenso, ma sono spesso considerati tali per semplicità. Sono in realtà meccanismi di resistenza di Sybil e selettori dell'autore del blocco, ovvero un metodo per decidere chi è l'autore dell'ultimo blocco. Un altro importante componente è l'algoritmo di selezione della catena (anche noto come di scelta della diramazione), che consente ai nodi di selezionare un unico blocco corretto all'inizio della catena, negli scenari in cui esistono più blocchi nella stessa posizione.
-La **resistenza a Sybil** misura l'efficacia di un protocollo contro un attacco di Sybil. La resistenza a questo tipo di attacco è essenziale per una blockchain decentralizzata e consente ai miner e ai validatori di essere ricompensati equamente in base alle risorse messe in uso. Proof-of-work e Proof of Stake proteggono da questo rischio, facendo consumare agli utenti molta energia o costringendoli a mettere in campo molte garanzie. Queste protezioni sono un deterrente economico contro gli attacchi di Sybil.
+**La resistenza a Sybil** misura l'efficacia di un protocollo contro un attacco Sybil. La resistenza a questo tipo di attacco è essenziale per una blockchain decentralizzata e consente ai miner e ai validatori di essere ricompensati equamente in base alle risorse messe in uso. Proof-of-work e Proof of Stake proteggono da questo rischio, facendo consumare agli utenti molta energia o costringendoli a mettere in campo molte garanzie. Queste protezioni sono un deterrente economico contro gli attacchi di Sybil.
-Per decidere quale catena sia quella "corretta" si usa una **regola di selezione della catena**. Bitcoin usa la regola della "catena più lunga", nel senso che la blockchain più lunga è quella che il resto dei nodi accetta come valida e con cui lavora. Per le catene di Proof of Work, la catena più lunga è determinata dalla difficoltà cumulativa e totale del Proof of Work della catena. Anche Ethereum usava la regola della catena più lunga; tuttavia, ora che Ethereum opera sul Proof of Stake, ha adottato un algoritmo di scelta della diramazione che misura il 'peso' della catena. Il peso è la somma cumulata dei voti dei validatori, ponderata dai saldi di ether in staking dei validatori.
+Una **regola di selezione della catena** viene usata per decidere quale sia la catena "corretta". Bitcoin usa la regola della "catena più lunga", nel senso che la blockchain più lunga è quella che il resto dei nodi accetta come valida e con cui lavora. Per le catene di Proof of Work, la catena più lunga è determinata dalla difficoltà cumulativa e totale del Proof of Work della catena. Anche Ethereum usava la regola della catena più lunga; tuttavia, ora che Ethereum opera sul Proof of Stake, ha adottato un algoritmo di scelta della diramazione che misura il 'peso' della catena. Il peso è la somma cumulata dei voti dei validatori, ponderata dai saldi di ether in staking dei validatori.
-Ethereum usa un meccanismo di consenso noto come [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/), che combina il [proof-of-work di Casper FFG](https://arxiv.org/abs/1710.09437) con la [regola di scelta della biforcazione di GHOST](https://arxiv.org/abs/2003.03052).
+Ethereum utilizza un meccanismo di consenso noto come [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) che combina la [proof-of-stake Casper FFG](https://arxiv.org/abs/1710.09437) con la [regola di scelta della biforcazione GHOST](https://arxiv.org/abs/2003.03052).
## Letture consigliate {#further-reading}
-- [Cos'è l'algoritmo di consenso della blockchain?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
-- [Cos'è il Consenso di Nakamoto? Guida Completa per Principianti](https://blockonomi.com/nakamoto-consensus/)
+- [Cos'è un algoritmo di consenso della blockchain?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm)
+- [Cos'è il Consenso di Nakamoto? Guida completa per principianti](https://blockonomi.com/nakamoto-consensus/)
- [Come funziona Casper?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d)
-- [Sulla sicurezza e le prestazioni delle blockchain di Proof of Work](https://eprint.iacr.org/2016/555.pdf)
-- [Guasto Byzantine](https://en.wikipedia.org/wiki/Byzantine_fault)
+- [Sulla sicurezza e le prestazioni delle blockchain proof-of-work](https://eprint.iacr.org/2016/555.pdf)
+- [Errore bizantino](https://en.wikipedia.org/wiki/Byzantine_fault)
-_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
## Argomenti correlati {#related-topics}
-- [Proof of Work](/developers/docs/consensus-mechanisms/pow/)
+- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/)
- [Mining](/developers/docs/consensus-mechanisms/pow/mining/)
-- [Proof of Stake](/developers/docs/consensus-mechanisms/pos/)
-- [Proof of Authority](/developers/docs/consensus-mechanisms/poa/)
+- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/)
+- [Proof-of-authority](/developers/docs/consensus-mechanisms/poa/)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md
index aa10661a7cb..3bf1957c2a0 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md
@@ -1,6 +1,6 @@
---
-title: Prova di autorità (PoA)
-description: Una spiegazione del protocollo di consenso a prova di autorità e del suo ruolo nell'ecosistema della blockchain.
+title: "Prova di autorità (PoA)"
+description: "Una spiegazione del protocollo di consenso a prova di autorità e del suo ruolo nell'ecosistema della blockchain."
lang: it
---
@@ -77,3 +77,4 @@ Guarda una spiegazione visiva della Prova d'Autorità:
- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/)
- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/)
+
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
index 4e939b15a83..8f69502d268 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md
@@ -1,6 +1,6 @@
---
title: "Proof-of-stake Ethereum: attacchi e meccanismi di difesa"
-description: Scopri di più sui vettori di attacco noti sul proof-of-stake di Ethereum e come è possibile difendersi da essi.
+description: "Scopri di più sui vettori di attacco noti sul proof-of-stake di Ethereum e come è possibile difendersi da essi."
lang: it
---
@@ -12,7 +12,7 @@ Sono necessarie conoscenze minime sul [proof-of-stake](/developers/docs/consensu
## Cosa vogliono gli utenti malevoli? {#what-do-attackers-want}
-Spesso si crede erroneamente che, in caso di successo, un utente malevolo possa generare nuovo ether o drenarlo da qualsiasi conto desideri. Nessuna delle due cose è possibile, poiché tutte le transazioni sono eseguite da tutti i client di esecuzione sulla rete. Se non soddisfano le condizioni di validità di base (es. sono firmate dalla chiave privata del mittente, il mittente ha un saldo sufficiente ecc.) vengono semplicemente annullate. Esistono tre classi di risultati a cui un utente malevolo può realisticamente mirare: riorganizzazioni, doppia finalità o ritardo di finalità.
+Spesso si crede erroneamente che, in caso di successo, un utente malevolo possa generare nuovo ether o drenarlo da qualsiasi conto desideri. Nessuna delle due cose è possibile, poiché tutte le transazioni sono eseguite da tutti i client di esecuzione sulla rete. Devono soddisfare le condizioni di validità di base (ad es., le transazioni sono firmate dalla chiave privata del mittente, il mittente ha un saldo sufficiente, ecc.), altrimenti vengono semplicemente annullate. Esistono tre classi di risultati a cui un utente malevolo può realisticamente mirare: riorganizzazioni, doppia finalità o ritardo di finalità.
Una **"riorganizzazione"** è un rimescolamento dei blocchi in un nuovo ordine, a volte con l'aggiunta o sottrazione di blocchi nella catena canonica. Una riorganizzazione malevola può portare all'inclusione o esclusione di blocchi specifici, consentendo una doppia spesa o l'estrazione di valore da transazioni di front-running e back-running (MEV). Le riorganizzazioni, inoltre, possono essere utilizzate per impedire l'inclusione di determinate transazioni nella catena canonica: una forma di censura. La forma più estrema di riorganizzazione è detta "inversione di finalità", che rimuove o sostituisce dei blocchi precedentemente finalizzati. Essa è possibile soltanto se più di ⅓ dell'ether totale in staking è distrutto dall'utente malevolo; questa garanzia è detta "finalità economica" (argomento che affronteremo in maggior dettaglio più avanti).
@@ -130,7 +130,7 @@ Uno dei punti di forza del consenso del PoS di Ethereum è che esistono [numeros
Qualsiasi sia la sanzione imposta all'utente malevolo, la community dovrebbe anche decidere se la catena disonesta, pur essendo quella preferita dall'algoritmo di scelta della biforcazione codificato nei client di Ethereum, è di fatto non valida e se proseguire al suo posto la catena onesta. I validatori onesti potrebbero decidere collettivamente di proseguire una biforcazione accettata dalla community della blockchain di Ethereum che potrebbe, ad esempio, essersi separata dalla catena canonica prima dell'inizio dell'attacco o far rimuovere forzatamente i validatori malevoli. I validatori onesti sarebbero incentivati a proseguire tale catena evitando le sanzioni loro applicate per non aver attestato (giustamente) la catena dell'utente malevolo. Le borse, on-ramp e applicazioni basate su Ethereum preferirebbero presumibilmente rimanere sulla catena onesta e seguirebbero i validatori onesti nella blockchain onesta.
-Si tratterebbe tuttavia di una situazione decisamente complessa dal punto di vista della governance. A causa del ritorno alla catena onesta alcuni utenti e validatori andrebbero senza dubbio in perdita, le transazioni nei blocchi convalidati dopo l'attacco potrebbero essere potenzialmente annullate, disturbando il livello d'applicazione, e, semplicemente, l'etica di alcuni utenti che tendono a credere che "il codice è legge" ne risulterebbe minata. Le borse e le applicazioni avrebbero molto probabilmente azioni esterne alla catena collegate alle transazioni sulla catena che ora potrebbero essere ripristinate, creando una cascata di ritrattazioni e revisioni che sarebbero difficili da disfare correttamente, specialmente se mischiate con guadagni disonesti, depositati nella DeFi o altri derivati con effetti secondari per gli utenti onesti. Indubbiamente alcuni utenti, forse persino istituzionali, potrebbero aver già beneficiato dalla catena disonesta, per scaltrezza o fortuna, e opporsi a una biforcazione per proteggere i propri guadagni. La possibilità di simulare la risposta della community a un attacco basato su uno stake superiore al 51% per una mitigazione coordinata, precisa e rapida è già stata proposta in passato. Esistono delle discussioni utili di Vitalik su ethresear.ch [qui](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) e [qui](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363), nonché su X.com qui. L'obiettivo di una risposta sociale coordinata dovrebbe essere molto mirato e concentrarsi sulla punizione dell'utente malevolo e sulla minimizzazione degli effetti per gli altri utenti.
+Si tratterebbe tuttavia di una situazione decisamente complessa dal punto di vista della governance. A causa del ritorno alla catena onesta alcuni utenti e validatori andrebbero senza dubbio in perdita, le transazioni nei blocchi convalidati dopo l'attacco potrebbero essere potenzialmente annullate, disturbando il livello d'applicazione, e, semplicemente, l'etica di alcuni utenti che tendono a credere che "il codice è legge" ne risulterebbe minata. È molto probabile che le piattaforme di scambio e le applicazioni abbiano collegato azioni fuori dalla catena a transazioni sulla catena che ora possono essere annullate, innescando una cascata di ritrattazioni e revisioni che sarebbero difficili da districare equamente, specialmente se i guadagni illeciti sono stati mescolati, depositati in DeFi o in altri derivati con effetti secondari per gli utenti onesti. Indubbiamente alcuni utenti, forse persino istituzionali, potrebbero aver già beneficiato dalla catena disonesta, per scaltrezza o fortuna, e opporsi a una biforcazione per proteggere i propri guadagni. La possibilità di simulare la risposta della community a un attacco basato su uno stake superiore al 51% per una mitigazione coordinata, precisa e rapida è già stata proposta in passato. Esistono delle discussioni utili di Vitalik su ethresear.ch [qui](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) e [qui](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363), nonché su X.com [qui](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw). L'obiettivo di una risposta sociale coordinata dovrebbe essere molto mirato e concentrarsi sulla punizione dell'utente malevolo e sulla minimizzazione degli effetti per gli altri utenti.
La governance è di per sé un argomento complicato. Gestire una risposta d'emergenza di livello 0 a una catena in finalizzazione disonesta sarebbe indubbiamente difficoltoso per la community di Ethereum, ma questo scenario [si è già verificato](/ethereum-forks/#dao-fork-summary) ([due volte](/ethereum-forks/#tangerine-whistle)) nella storia di Ethereum.
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attestations/index.md
index 579599b28a0..62ec8f4efd2 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attestations/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attestations/index.md
@@ -8,35 +8,35 @@ Un validatore dovrebbe creare, firmare e trasmettere una attestazione durante og
## Cos'è un'attestazione? {#what-is-an-attestation}
-Ogni [epoca](/glossary/#epoch) (6,4 minuti), un validatore propone un'attestazione alla rete. L'attestazione è per uno slot specifico nell'epoca. Lo scopo dell'attestazione è votare a favore della visione della catena del validatore, in particolare il blocco giustificato più recente e il primo blocco nell'epoca corrente (noti come punti di controllo `source` (origine) e `target` (destinazione)). Queste informazioni sono combinate per tutti i validatori partecipanti, consentendo alla rete di raggiungere il consenso sullo stato della blokchain.
+Ogni [epoca](/glossary/#epoch) (6,4 minuti), un validatore propone un'attestazione alla rete. L'attestazione è per uno slot specifico nell'epoca. Lo scopo dell'attestazione è votare a favore della visione della catena del validatore, in particolare il blocco giustificato più recente e il primo blocco nell'epoca corrente (noti come checkpoint `source` e `target`). Queste informazioni sono combinate per tutti i validatori partecipanti, consentendo alla rete di raggiungere il consenso sullo stato della blokchain.
L'attestazione contiene i componenti seguenti:
-- `aggregation_bits`: un bitlist di validatori in cui la posizione mappa all'indice del validatore nella loro commissione; il valore (0/1) indica se il validatore ha firmato i `data` (cioè, se è attivo ed è d'accordo con il propositore del blocco)
-- `data`: dettagli relativi all'attestazione, come definito sotto
+- `aggregation_bits`: una bitlist di validatori in cui la posizione corrisponde all'indice del validatore nella propria commissione; il valore (0/1) indica se il validatore ha firmato i `data` (cioè se è attivo e d'accordo con il propositore del blocco).
+- `data`: dettagli relativi all'attestazione, come definiti di seguito
- `signature`: una firma BLS che aggrega le firme dei singoli validatori
-La prima mansione per un validatore attestante è costruire `data`. I `data` contengono le seguenti informazioni:
+Il primo compito per un validatore attestante è costruire i `data`. I `data` contengono le seguenti informazioni:
-- `slot`: Il numero di slot a cui si riferisce l'attestazione
-- `index`: Un numero che identifica a quale commissione appartiene il validatore in un dato slot
-- `beacon_block_root`: Hash radice del blocco che il validatore vede alla testa della catena (il risultato dell'applicazione dell'algoritmo di scelta della diramazione)
-- `source`: Parte del voto di finalità che indica ciò che i validatori vedono come il blocco giustificato più recente
-- `target`: Parte del voto di finalità che indica cosa i validatori vedono come il primo blocco nell'epoca corrente
+- `slot`: il numero di slot a cui si riferisce l'attestazione
+- `index`: un numero che identifica a quale commissione appartiene il validatore in un dato slot
+- `beacon_block_root`: hash radice del blocco che il validatore vede in testa alla catena (il risultato dell'applicazione dell'algoritmo di scelta della biforcazione)
+- `source`: parte del voto di finalità che indica ciò che i validatori vedono come il blocco giustificato più recente
+- `target`: parte del voto di finalità che indica ciò che i validatori vedono come il primo blocco nell'epoca corrente
-Una volta costruiti i `data`, il validatore può capovolgere il bit in `aggregation_bits`, corrispondenti al proprio indice del validatore da 0 a 1 per mostrare di aver partecipato.
+Una volta costruiti i `data`, il validatore può invertire il bit in `aggregation_bits` corrispondente al proprio indice del validatore da 0 a 1 per mostrare di aver partecipato.
Infine, il validatore firma l'attestazione e la trasmette sulla rete.
### Attestazione aggregata {#aggregated-attestation}
-Le spese aggiuntive associate al trasferimento di questi dati nella rete sono molto elevate per ogni validatore. Di conseguenza, prima ancora che avvenga la trasmissione su larga scala, le attestazioni dei singoli validatori sono aggregate in reti secondarie. Questo include l'aggregazione delle firme in modo che un'attestazione che viene trasmessa includa i `dati` di consenso e un'unica firma creata combinando le firme di tutte i validatori d'accordo con tali `dati`. Ciò è verificabile utilizzando `aggregation_bits`, poiché questi forniscono l'indice di ogni validatore nella propria commissione (i cui ID sono forniti in `data`) che può essere utilizzato per richiedere le singole firme.
+Le spese aggiuntive associate al trasferimento di questi dati nella rete sono molto elevate per ogni validatore. Di conseguenza, prima ancora che avvenga la trasmissione su larga scala, le attestazioni dei singoli validatori sono aggregate in reti secondarie. Questo include l'aggregazione delle firme in modo che un'attestazione trasmessa includa i `data` di consenso e una firma singola formata combinando le firme di tutti i validatori che sono d'accordo con tali `data`. Questo può essere verificato utilizzando `aggregation_bits`, poiché questo fornisce l'indice di ogni validatore nella propria commissione (il cui ID è fornito in `data`), che può essere utilizzato per interrogare le singole firme.
-In ogn epoca 16 validatori in ogni rete secondaria sono selezionati per fungere da `aggregatori`. Gli aggregatori raccolgono tutte le attestazioni a loro note sulla rete di gossip aventi `dati` equivalenti ai loro. Il mittente di ogni attestazione corrispondente è registrato negli `aggregation_bits`. Quindi, gli aggregatori trasmettono l'aggregato di attestazioni al resto della rete.
+In ogni epoca, 16 validatori in ogni sottorete sono selezionati per essere gli `aggregatori`. Gli aggregatori raccolgono tutte le attestazioni di cui vengono a conoscenza sulla rete gossip che hanno `data` equivalenti ai propri. Il mittente di ogni attestazione corrispondente è registrato in `aggregation_bits`. Quindi, gli aggregatori trasmettono l'aggregato di attestazioni al resto della rete.
Quando un validatore viene selezionato per essere un propositore di blocchi, impacchetta le attestazioni aggregate dalle reti secondarie fino all'ultimo slot nel nuovo blocco.
-### Ciclo di vita di inclusione dell'attestazione {#attestation-inclusion-lifecycle}
+### Ciclo di vita dell'inclusione dell'attestazione {#attestation-inclusion-lifecycle}
1. Generazione
2. Propagazione
@@ -64,11 +64,11 @@ Il tasso di attestazione del flag si misura utilizzando la somma dei saldi effet
La ricompensa di base è calcolata secondo il numero di validatori attestanti e i loro saldi effettivi di ether in staking:
-`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)`
+`ricompensa di base = saldo effettivo del validatore x 2^6 / SQRT(saldo effettivo di tutti i validatori attivi)`
-#### Ritardo d'inclusione {#inclusion-delay}
+#### Ritardo di inclusione {#inclusion-delay}
-Al momento del voto dei validatori sulla testa della catena (`block n`), `block n+1` non era ancora stato proposto. Pertanto, le attestazioni sono incluse naturalmente **un blocco più tardi**, così che tutte le attestazioni che hanno votato sul `block n`, che è la testa della catena, sono incluse in `block n+1` e il **ritardo d'inclusione** è 1. Se il ritardo d'inclusione raddoppia a due slot, la ricompensa di attestazione si dimezza, perché per calcolare la ricompensa di attestazione la ricompensa di base è moltiplicata per il reciproco del ritardo d'inclusione.
+Nel momento in cui i validatori hanno votato sulla testa della catena (`block n`), il `block n+1` non era ancora stato proposto. Pertanto, le attestazioni vengono naturalmente incluse **un blocco dopo**, quindi tutte le attestazioni che hanno votato affinché il `block n` fosse la testa della catena sono state incluse nel `block n+1` e il **ritardo di inclusione** è 1. Se il ritardo d'inclusione raddoppia a due slot, la ricompensa di attestazione si dimezza, perché per calcolare la ricompensa di attestazione la ricompensa di base è moltiplicata per il reciproco del ritardo d'inclusione.
### Scenari di attestazione {#attestation-scenarios}
@@ -78,15 +78,15 @@ I validatori hanno un massimo di 1 epoca per inviare le proprie attestazioni. Se
#### Aggregatore mancante {#missing-aggregator}
-Per ogni epoca ci sono in totale 16 Aggregatori. Inoltre, alcuni validatori casuali si iscrivono a **due reti secondarie per 256 epoche** e servono da backup nel caso in cui gli aggregatori siano mancanti.
+Per ogni epoca ci sono in totale 16 Aggregatori. Inoltre, validatori casuali si iscrivono a **due sottoreti per 256 epoche** e fungono da backup nel caso in cui gli aggregatori manchino.
-#### Propositore di blocchi mancante {#missing-block-proposer}
+#### Propositore del blocco mancante {#missing-block-proposer}
-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.
+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 di inclusione** aumenterà 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/capella/part3/containers/dependencies/#attestationdata)
+- [Attestazioni nella spec del consenso commentata di Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata)
+- [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!_
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/block-proposal/index.md
index 43ec2ad31d1..88ceb5a62e8 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/block-proposal/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/block-proposal/index.md
@@ -8,7 +8,7 @@ I blocchi costituiscono le unità fondamentali della blockchain. I blocchi sono
## Prerequisiti {#prerequisites}
-L'azione di proporre un blocco fa parte del protocollo di proof-of-stake. Per aiutarti a comprendere questa pagina, ti consigliamo di leggere a riguardo del [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e dell'[architettura dei blocchi](/developers/docs/blocks/).
+L'azione di proporre un blocco fa parte del protocollo di proof-of-stake. Per aiutarti a comprendere questa pagina, ti consigliamo di leggere [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e [architettura dei blocchi](/developers/docs/blocks/).
## Chi produce i blocchi? {#who-produces-blocks}
@@ -18,7 +18,7 @@ I conti del validatore propongono i blocchi. I conti del validatore sono gestiti
Un unico validatore è pseudo-casualmente scelto per proporre un blocco per ogni slot. Non esiste una vera casualità in una blockchain, poiché se ogni nodo generasse genuinamente dei numeri casuali non si arriverebbe mai al consenso. Invece, l'obiettivo è di rendere imprevedibile il processo di selezione del validatore. La casualità su Ethereum è ottenuta utilizzando un algoritmo chiamato RANDAO, che combina un hash dal propositore di blocchi con un seed aggiornato a ogni blocco. Questo valore è utilizzato per selezionare un validatore specifico dall'insieme totale di validatori. La selezione del validatore è fissata con due epoche in anticipo come forma di protezione da certi tipi di manipolazione del seed.
-Sebbene i validatori si aggiungano al RANDAO in ogni slot, il valore globale del RANDAO è aggiornato solo una volta per epoca. Per calcolare l'indice del propositore di blocchi successivo, il valore del RANDAO è combinato con il numero di slot per dare un valore univoco a ogni slot. La probabilità che un singolo validatore sia selezionato non è semplicemente `1/N` (dove `N` = validatori attivi totali). Invece, è ponderata per il saldo di ETH effettivo di ogni validatore. Il saldo effettivo massimo è di 32 ETH (ciò significa che `balance < 32 ETH` comporta un peso minore di `balance == 32 ETH`, ma `balance > 32 ETH` non comporta un peso maggiore di `balance == 32 ETH`).
+Sebbene i validatori si aggiungano al RANDAO in ogni slot, il valore globale del RANDAO è aggiornato solo una volta per epoca. Per calcolare l'indice del propositore di blocchi successivo, il valore del RANDAO è combinato con il numero di slot per dare un valore univoco a ogni slot. La probabilità che un singolo validatore sia selezionato non è semplicemente `1/N` (dove `N` = validatori attivi totali). Invece, è ponderata per il saldo di ETH effettivo di ogni validatore. Il saldo effettivo massimo è 32 ETH (ciò significa che `balance < 32 ETH` porta a una ponderazione inferiore rispetto a `balance == 32 ETH`, ma `balance > 32 ETH` non porta a una ponderazione superiore rispetto a `balance == 32 ETH`).
Solo un propositore di blocchi è selezionato per ogni slot. In condizioni normali, un singolo produttore di blocchi crea e rilascia un unico blocco nello slot dedicato. Creare due blocchi per lo stesso slot è un’infrazione tagliabile, spesso nota come "equivoco".
@@ -42,28 +42,28 @@ class BeaconBlockBody(Container):
execution_payload: ExecutionPayload
```
-Il campo `randao_reveal` prende un valore casuale verificabile che il propositore di blocchi crea firmando il numero dell'epoca corrente. `eth1_data` è un voto per la vista del contratto di deposito da parte del propositore di blocchi, che include la radice dell'albero di Merkle di deposito e il numero totale di depositi che consentono la verifica dei nuovi depositi. `graffiti` è un campo facoltativo utilizzabile per aggiungere un messaggio al blocco. `proposer_slashings` e `attester_slashings` sono campi contenenti la prova che certi validatori hanno commesso infrazioni tagliabili secondo la vista della catena del propositore. `deposits` è un elenco di nuovi depositi del validatore di cui il propositore di blocchi è consapevole, e `voluntary_exits` è un elenco di validatori che desiderano uscire di cui il propositore di blocchi è venuto a conoscenza sulla rete di gossip del livello di consenso. `sync_aggregate` è un vettore che mostra quali validatori erano precedentemente assegnati a una commissione di sincronizzazione (un sottoinsieme di validatori che servono i dati dei client leggeri) e hanno partecipato alla firma dei dati.
+Il campo `randao_reveal` assume un valore casuale verificabile che il propositore del blocco crea firmando il numero dell'epoca corrente. `eth1_data` è un voto per la visione del contratto di deposito del propositore del blocco, che include la radice dell'albero di Merkle dei depositi e il numero totale di depositi che consentono la verifica di nuovi depositi. `graffiti` è un campo facoltativo che può essere usato per aggiungere un messaggio al blocco. `proposer_slashings` e `attester_slashings` sono campi che contengono la prova che alcuni validatori hanno commesso violazioni soggette a slashing secondo la visione della catena da parte del propositore. `deposits` è un elenco di nuovi depositi di validatori di cui il propositore del blocco è a conoscenza, e `voluntary_exits` è un elenco di validatori che desiderano uscire, di cui il propositore del blocco è venuto a conoscenza sulla rete gossip del livello di consenso. `sync_aggregate` è un vettore che mostra quali validatori sono stati precedentemente assegnati a un comitato di sincronizzazione (un sottoinsieme di validatori che forniscono dati ai client leggeri) e hanno partecipato alla firma dei dati.
-`execution_payload` consente il passaggio delle informazioni sulle transazioni tra i client di esecuzione e di consenso. `execution_payload` è un blocco di dati di esecuzione che viene nidificato in un blocco beacon. I campi in `execution_payload` riflettono la struttura dei blocchi delineata nello Yellow Paper di Ethereum, tranne che non esistono ommer e che `prev_randao` esiste al posto della `difficulty`. Il client di esecuzione ha accesso a un pool locale di transazioni di cui è venuto a conoscenza sulla propria rete di gossip. Queste transazioni sono eseguite localmente per generare un albero di stato aggiornato, noto come post-stato. Le transazioni sono incluse nell'`execution_payload` come un elenco detto `transactions` e il post-stato è fornito nel campo `state-root`.
+`execution_payload` abilita il passaggio di informazioni sulle transazioni tra i client di esecuzione e di consenso. `execution_payload` è un blocco di dati di esecuzione che viene annidato all'interno di un blocco beacon. I campi all'interno di `execution_payload` riflettono la struttura del blocco descritta nello Yellow Paper di Ethereum, con l'eccezione che non ci sono ommer e che `prev_randao` esiste al posto di `difficulty`. Il client di esecuzione ha accesso a un pool locale di transazioni di cui è venuto a conoscenza sulla propria rete di gossip. Queste transazioni sono eseguite localmente per generare un albero di stato aggiornato, noto come post-stato. Le transazioni sono incluse in `execution_payload` come elenco chiamato `transactions` e il post-stato è fornito nel campo `state-root`.
Tutti questi dati sono raccolti in un blocco beacon, firmati e trasmessi ai pari del propositore di blocchi, che li distribuiscono ai loro pari, ecc.
-Maggiori informazioni più sull'[anatomia dei blocchi](/developers/docs/blocks).
+Leggi di più sull'[anatomia dei blocchi](/developers/docs/blocks/).
## Cosa succede al blocco? {#what-happens-to-blocks}
-Il blocco è aggiunto al database locale del propositore di blocchi e trasmesso ai pari tramite la rete di gossip del livello di consenso. Quando un validatore riceve il blocco, verifica i dati al suo interno, anche controllando che il blocco abbia il genitore corretto, corrisponda allo slot corretto, che l'indice del propositore sia quello previsto, che l'indicazione del RANDAO sia valida e che il propositore non sia tagliato. `execution_payload` è scompattato e il client di esecuzione del validatore ri-esegue le transazioni nell'elenco per verificare il cambiamento di stato proposto. Supponendo che il blocco superi tutti questi controlli, ogni validatore aggiunge il blocco alla propria catena canonica. Il processo quindi ricomincia nello slot successivo.
+Il blocco è aggiunto al database locale del propositore di blocchi e trasmesso ai pari tramite la rete di gossip del livello di consenso. Quando un validatore riceve il blocco, verifica i dati al suo interno, anche controllando che il blocco abbia il genitore corretto, corrisponda allo slot corretto, che l'indice del propositore sia quello previsto, che l'indicazione del RANDAO sia valida e che il propositore non sia tagliato. `execution_payload` viene scompattato e il client di esecuzione del validatore riesegue le transazioni nell'elenco per verificare la modifica di stato proposta. Supponendo che il blocco superi tutti questi controlli, ogni validatore aggiunge il blocco alla propria catena canonica. Il processo quindi ricomincia nello slot successivo.
-## Ricompense del blocco {#block-rewards}
+## Ricompensa del blocco {#block-rewards}
-Il propositore del blocco riceve il pagamento per il proprio lavoro. Esiste una `base_reward` calcolata come funzione del numero di validatori attivi e dei loro saldi effettivi. Il propositore del blocco, quindi, riceve una frazione della `base_reward` per ogni attestazione valida inclusa nel blocco; più validatori attestano al blocco, maggiore è la ricompensa del suo propositore. Esiste anche una ricompensa per aver segnalato i validatori che dovrebbero essere tagliati, pari a `1/512 * saldo effettivo` per ogni validatore tagliato.
+Il propositore del blocco riceve il pagamento per il proprio lavoro. Esiste una `base_reward` calcolata in funzione del numero di validatori attivi e dei loro saldi effettivi. Il propositore del blocco riceve quindi una frazione della `base_reward` per ogni attestazione valida inclusa nel blocco; più validatori attestano il blocco, maggiore è la ricompensa del propositore del blocco. C'è anche una ricompensa per la segnalazione di validatori che dovrebbero essere sottoposti a slashing, pari a `1/512 * saldo effettivo` per ogni validatore sottoposto a slashing.
-[Maggiori informazioni su ricompense e sanzioni](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
+[Maggiori informazioni su ricompense e penalità](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties)
## Letture consigliate {#further-reading}
- [Introduzione ai blocchi](/developers/docs/blocks/)
- [Introduzione al proof-of-stake](/developers/docs/consensus-mechanisms/pos/)
- [Specifiche del consenso di Ethereum](https://github.com/ethereum/consensus-specs)
-- [Introduzione a Gasper](/developers/docs/consensus-mechanisms/pos/)
+- [Introduzione a Gasper](/developers/docs/consensus-mechanisms/pos/gasper/)
- [Aggiornare Ethereum](https://eth2book.info/)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/faqs/index.md
index d9dffb352e6..52c665243ad 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/faqs/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/faqs/index.md
@@ -4,11 +4,11 @@ description: Domande frequenti sull'Ethereum di proof-of-stake.
lang: it
---
-## Cos'è il proof-of-stake {#what-is-proof-of-stake}
+## Cos'è la proof-of-stake {#what-is-proof-of-stake}
Il proof-of-stake è una classe di algoritmo che può fornire sicurezza alle blockchain assicurandosi che le risorse di valore siano perse dagli utenti malevoli che agiscono in modo disonesto. I sistemi di proof-of-stake richiedono che una serie di validatori rendano disponibili delle risorse che possono essere distrutte se il validatore adotta certi comportamenti comprovatamente disonesti. Ethereum utilizza il meccanismo di proof-of-stake per proteggere la blockchain.
-## Come si distingue il proof-of-stake dal proof-of-work? {#comparison-to-proof-of-work}
+## Come si distingue il proof-of-stake dal proof-of-work? Confronto con la proof-of-work {#comparison-to-proof-of-work}
Sia il proof-of-work che il proof-of-stake sono meccanismi che disincentivano economicamente gli utenti malevoli dallo spam o da truffe alla rete. In entrambi i casi, i nodi che partecipano attivamente al consenso mettono "nella rete" alcune risorse che perderanno se si comportano scorrettamente.
@@ -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 offrono 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 forniscono un buon riepilogo degli argomenti.
@@ -26,22 +26,22 @@ Il confronto proof-of-work vs. proof-of-stake è un argomento controverso. Il [b
Sì. I nodi su una rete di proof-of-stake utilizzano una minuscola quantità di energia. Uno studio di terze parti ha concluso che l'intera rete di proof-of-stake di Ethereum consuma circa 0,0026 TWh/anno, circa 13.000 volte in meno del gaming nei soli Stati Uniti.
-[Di più sul consumo energetico di Ethereum](/energy-consumption/).
+[Maggiori informazioni sul consumo energetico di Ethereum](/energy-consumption/).
## Il proof-of-stake è sicuro? {#is-pos-secure}
Il proof-of-stake di Ethereum è molto sicuro. Il meccanismo è stato studiato, sviluppato e testato rigorosamente per otto anni prima di entrare in funzione. Le garanzie di sicurezza sono differenti dalle blockchain di proof-of-work. Nel proof-of-stake, i validatori malevoli possono essere puniti attivamente ("tagliati") ed espulsi dall'insieme di validatori, costando un sostanziale importo di ETH. Nel proof-of-work, un utente malevolo può continuare a ripetere il proprio attacco fintanto che ha sufficiente potenza di hash. Inoltre, è più costoso compiere attacchi equivalenti sull'Ethereum con proof-of-stake rispetto al proof-of-work. Per influenzare la vitalità della catena, è necessario almeno il 33% dell'ether in staking totale sulla rete (tranne nei casi di attacchi molto sofisticati che hanno una probabilità di successo estremamente ridotta). Per controllare i contenuti dei blocchi futuri, è necessario almeno il 51% degli ETH in staking totali e per riscrivere lo storico serve oltre il 66% dello stake totale. Il protocollo di Ethereum distruggerebbe queste risorse negli scenari di attacco al 33% e 51% e tramite il consenso sociale nello scenario di attacchi del 66%.
-- [Maggiori informazioni sulla difesa del proof-of-stake di Ethereum dagli utenti malevoli](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
-- [Maggiori informazioni sulla progettazione del proof-of-stake](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
+- [Maggiori informazioni sulla difesa della proof-of-stake di Ethereum dagli aggressori](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
+- [Maggiori informazioni sul design della proof-of-stake](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
-## Il proof-of-stake rende Ethereum più economico? {#does-pos-make-ethereum-cheaper}
+## Il proof-of-stake rende Ethereum più economico? La PoS rende Ethereum più economico? {#does-pos-make-ethereum-cheaper}
No. Il costo di invio di una transazione (commissione sul carburante) è determinato da un mercato di commissioni dinamico che aumenta all'aumentare della domanda di rete. Il meccanismo di consenso non lo influenza direttamente.
-[Maggiori informazioni sul carburante](/developers/docs/gas).
+[Maggiori informazioni sul gas](/developers/docs/gas).
-## Cosa sono i nodi, i client e i validatori? {#what-are-nodes-clients-and-validators}
+## Cosa sono i nodi, i client e i validatori? Cosa sono nodi, client e validatori? {#what-are-nodes-clients-and-validators}
I nodi sono computer connessi alla rete di Ethereum. I client sono i software che eseguono, che trasformano il computer in un nodo. Esistono due tipi di client: di esecuzione e di consenso. Sono entrambi necessari per creare un nodo. Un validatore è un componente aggiuntivo facoltativo a un client di consenso, che consente al nodo di partecipare al consenso di proof-of-stake. Ciò significa creare e proporre blocchi quando selezionati e attestare i blocchi che sentono sulla rete. Per eseguire un validatore, l'operatore del nodo deve depositare 32 ETH nel contratto di deposito.
@@ -50,9 +50,9 @@ I nodi sono computer connessi alla rete di Ethereum. I client sono i software ch
## Il proof-of-stake è una idea nuova? {#is-pos-new}
-No. Un utente su BitcoinTalk [ha proposto l'idea di base del proof-of-stake](https://bitcointalk.org/index.php?topic=27787.0) come un aggiornamento a Bitcoin nel 2011. Erano undici anni prima che fosse pronto all'implementazione sulla Rete Principale di Ethereum. Alcune altre catene hanno implementato il proof-of-stake prima di Ethereum, ma non il meccanismo specifico di Ethereum (noto come Gasper).
+No. Un utente su BitcoinTalk [ha proposto l'idea di base della proof-of-stake](https://bitcointalk.org/index.php?topic=27787.0) come aggiornamento di Bitcoin nel 2011. Erano undici anni prima che fosse pronto all'implementazione sulla Rete Principale di Ethereum. Alcune altre catene hanno implementato il proof-of-stake prima di Ethereum, ma non il meccanismo specifico di Ethereum (noto come Gasper).
-## Cosa rende speciale il proof-of-stake di Ethereum? {#why-is-ethereum-pos-special}
+## Cosa rende speciale il proof-of-stake di Ethereum? Perché la PoS di Ethereum è speciale? {#why-is-ethereum-pos-special}
Il meccanismo di proof-of-stake di Ethereum è unico nella sua progettazione. Non è stato il primo meccanismo di proof-of-stake mai progettato e implementato, ma è il più robusto. Il meccanismo di proof-of-stake è noto come "Casper". Casper definisce come i validatori sono selezionati per proporre i blocchi, come e quando sono effettuate le attestazioni, come sono contate le attestazioni, le ricompense e le sanzioni date ai validatori, le condizioni di taglio, i meccanismi di emergenza come la perdita per inattività e le condizioni per la "finalità". La finalità è la condizione secondo cui per essere considerato una parte permanente della catena canonica, un blocco deve essere votato da almeno il 66% degli ETH in staking totali sulla rete. I ricercatori hanno sviluppato Casper specificamente per Ethereum, ed Ethereum è la prima e unica blockchain ad averlo implementato.
@@ -66,7 +66,7 @@ La combinazione di Casper e LMD-GHOST è nota come Gasper.
Taglio è il termine dato alla distruzione di parte dello stake di un validatore e la sua espulsione dalla rete. L'importo di ETH perduto in un taglio scala con il numero di validatori tagliati; ciò significa che i validatori complici sono puniti più severamente dei singoli.
-[Maggiori informazioni sul taglio](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing)
+[Maggiori informazioni sullo slashing](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing)
## Perché i validatori necessitano di 32 ETH? {#why-32-eth}
@@ -82,26 +82,26 @@ Un singolo validatore è scelto pseudo-casualmente per proporre un blocco in ogn
La frantumazione dello stake è una categoria di attacco alle reti di proof-of-stake in cui l'utente malevolo prova a orientare l'algoritmo di selezione del validatore a favore dei propri validatori. Gli attacchi di frantumazione dello stake richiedono all'incirca metà degli ETH totali in staking.
-[Maggiori informazioni sulla frantumazione dello stake](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability)
+[Maggiori informazioni sullo stake grinding](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability)
## Cos'è il taglio sociale? {#what-is-social-slashing}
Il taglio sociale è l'abilità della community di coordinare una diramazione blockchain in risposta a un attacco. Consente alla community di riprendersi da un utente malevolo che finalizza una catena disonesta. Il taglio sociale è anche utilizzabile contro gli attacchi di censura.
-- [Maggiori informazioni sul taglio sociale](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7)
-- [Vitalik Buterin sul taglio sociale](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
+- [Maggiori informazioni sullo slashing sociale](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7)
+- [Vitalik Buterin sullo slashing sociale](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
-## Riceverò un taglio? {#will-i-get-slashed}
+## Riceverò un taglio? Subirò uno slashing? {#will-i-get-slashed}
Come validatore, è molto difficile essere tagliato a meno che non si adottino deliberatamente comportamenti malevoli. Il taglio è implementato soltanto in scenari davvero specifici in cui i validatori propongono più blocchi per lo stesso slot o si contraddicono con le proprie attestazioni – situazioni che è davvero improbabile sorgano accidentalmente.
-[Maggiori informazioni sulle condizioni di taglio](https://eth2book.info/altair/part2/incentives/slashing)
+[Maggiori informazioni sulle condizioni di slashing](https://eth2book.info/altair/part2/incentives/slashing)
## Cos'è il problema del "nulla in staking"? {#what-is-nothing-at-stake-problem}
Il problema del "nulla in staking" è un problema concettuale con alcuni meccanismi di proof-of-stake in cui esistono solo ricompense e nessuna sanzione. Se non c'è nulla in staking, un validatore pragmatico è altrettanto felice di attestare qualsiasi, o persino più, diramazioni della blockchain, perché questo aumenta le sue ricompense. Ethereum aggira tale problema utilizzando le condizioni di finalità e il taglio per assicurare una catena canonica.
-[Maggiori informazioni sul problema di "nulla in staking"](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed)
+[Maggiori informazioni sul problema del nothing-at-stake](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed)
## Cos'è un algoritmo di scelta della diramazione? {#what-is-a-fork-choice-algorithm}
@@ -127,19 +127,19 @@ La soggettività debole è una funzionalità delle reti di proof-of-stake in cui
La resistenza alla censura è attualmente difficile da dimostrare. Tuttavia, a differenza del proof-of-work, il proof-of-stake offre l'opzione di coordinare i tagli per punire i validatori autori di censura. Sono previste delle modifiche al protocollo per separare i costruttori dai propositori di blocchi e implementare elenchi di transazioni che i costruttori devono includere in ogni blocco. Questa proposta è nota come separazione tra propositori e costruttori e aiuta a impedire che i validatori censurino le transazioni.
-[Maggiori informazioni sulla separazione tra propositori e costruttori](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme)
+[Maggiori informazioni sulla separazione propositore-costruttore](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme)
## Il sistema di proof-of-stake di Ethereum può subire attacchi al 51%? {#pos-51-attack}
Sì. Il proof-of-stake è vulnerabile agli attacchi al 51%, proprio come il proof-of-work. Anziché aver bisogno del 51% della potenza di hash della rete, l'utente malevolo necessita del 51% del totale degli ETH in staking. Un utente malevolo che accumula il 51% dello stake totale ottiene il controllo dell'algoritmo di scelta della diramazione. Ciò gli consente di censurare certe transazioni, effettuare riorganizzazioni a breve raggio ed estrarre MEV riordinando i blocchi a proprio favore.
-[Maggiori informazioni sugli attacchi al proof-of-stake](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
+[Maggiori informazioni sugli attacchi alla proof-of-stake](/developers/docs/consensus-mechanisms/pos/attack-and-defense)
## Cos'è il coordinamento sociale e perché è necessario? {#what-is-social-coordination}
Il coordinamento sociale è l'ultima linea di difesa di Ethereum, che consentirebbe a una catena onesta di essere recuperata da un attacco che ha finalizzato dei blocchi disonesti. In questo caso, la community di Ethereum dovrebbe coordinarsi "fuori banda" e accordarsi sull'uso di una diramazione onesta di minoranza, tagliando i validatori malevoli nel processo. Ciò richiederebbe anche alle app e alle borse di riconoscere la diramazione onesta.
-[Maggiori informazioni sul coordinamento sociale](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense)
+[Leggi di più sul coordinamento sociale](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense)
## Il ricco si arricchisce con il proof-of-stake? {#do-rich-get-richer}
@@ -149,13 +149,13 @@ Più ETH qualcuno ha da mettere in staking, più validatori può eseguire e più
No, il proof-of-work tende alla centralizzazione perché i costi di mining aumentano e tagliano fuori gli individui, poi tagliano fuori le piccole aziende e così via. L'attuale problema con il proof-of-stake è l'influenza dei derivati di staking liquidi (LSD). Si tratta di token rappresentanti gli ETH messi in staking da qualche fornitore, che chiunque può scambiare su mercati secondari senza prelevare gli ETH effettivi. Gli LSD consentono agli utenti di mettere in staking meno di 32 ETH, ma creano anche un rischio di centralizzazione in cui poche grandi organizzazioni possono finire per controllare gran parte dello stake. Per questo lo [staking in autonomia](/staking/solo) è l'opzione migliore per Ethereum.
-[Maggiori informazioni sulla centralizzazione dello stake in LSD](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
+[Maggiori informazioni sulla centralizzazione dello stake negli LSD](https://notes.ethereum.org/@djrtwo/risks-of-lsd)
## Perché posso mettere soltanto gli ETH in staking? {#why-can-i-only-stake-eth}
ETH è la valuta nativa di Ethereum. È essenziale avere una singola valuta in cui sono denominati tutti gli stake, sia per tenere conto dei saldi effettivi che per ponderare i voti e per la sicurezza. Gli stessi ETH sono componenti fondamentali di Ethereum, rispetto a un contratto intelligente. Integrare altre valute aumenterebbe significativamente la complessità, riducendo la sicurezza dello staking.
-## Ethereum è la sola blockchain di proof-of-stake? {#is-ethereum-the-only-pos-blockchain}
+## Ethereum è la sola blockchain di proof-of-stake? Ethereum è l'unica blockchain PoS? {#is-ethereum-the-only-pos-blockchain}
No, esistono diverse blockchain di proof-of-stake. Nessuna è identica a Ethereum; il meccanismo di proof-of-stake di Ethereum è unico.
@@ -163,10 +163,10 @@ No, esistono diverse blockchain di proof-of-stake. Nessuna è identica a Ethereu
La Fusione è stata il momento in cui Ethereum ha spento il suo meccanismo di consenso basato sul proof-of-work ed è passato a quello di proof-of-stake. La Fusione si è verificata il 15 settembre 2022.
-[Maggiori informazioni sulla fusione](/roadmap/merge)
+[Maggiori informazioni sulla Fusione](/roadmap/merge)
## Cosa sono vitalità e sicurezza? {#what-are-liveness-and-safety}
-Vitalità e sicurezza sono le due preoccupazioni fondamentali in materia di sicurezza per una blockchain. La vitalità è la disponibilità di una catena che si finalizza. Se la catena smette di finalizzarsi o gli utenti non possono accedervi facilmente, si parla di perdita di vitalità. Anche un costo d'accesso estremamente elevato potrebbe essere considerato una perdita di vitalità. La sicurezza si riferisce alla difficoltà di attacco della catena, ossia finalizzare punti di controllo in conflitto.
+Vitalità e sicurezza sono le due preoccupazioni fondamentali in materia di sicurezza per una blockchain. La vitalità è la disponibilità di una catena che si finalizza. Se la catena smette di finalizzarsi o gli utenti non possono accedervi facilmente, si parla di perdita di vitalità. Anche un costo d'accesso estremamente elevato potrebbe essere considerato una perdita di vitalità. La sicurezza si riferisce a quanto è difficile attaccare la catena, cioè finalizzare i checkpoint in conflitto.
-[Leggi di più nel documento di Casper](https://arxiv.org/pdf/1710.09437.pdf)
+[Leggi di più nel paper su Casper](https://arxiv.org/pdf/1710.09437.pdf)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/gasper/index.md
index ce62e76c099..634d21121ad 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/gasper/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/gasper/index.md
@@ -10,7 +10,7 @@ Gasper è una combinazione di Casper the Friendly Finality Gadget (Casper-FFG) e
## Prerequisiti
-Per comprendere questo materiale, è necessario leggere la pagina introduttiva sul [proof-of-stake](/developers/docs/consensus-mechanisms/pos/).
+Per comprendere questo materiale è necessario leggere la pagina introduttiva su [proof-of-stake](/developers/docs/consensus-mechanisms/pos/).
## Il ruolo di Gasper {#role-of-gasper}
@@ -23,14 +23,14 @@ La finalità è una proprietà di certi blocchi tale per cui non possono essere
1. Due terzi dell'ether in staking totale deve aver votato a favore dell'inclusione di quel blocco nella catena canonica. Questa condizione porta il blocco nello stato "giustificato". È improbabile che i blocchi giustificati siano ripristinati anche se in alcune condizioni è possibile.
2. Quando un altro blocco è giustificato sopra a un blocco giustificato, questo passa allo stato "finalizzato". Finalizzare un blocco corrisponde all'impegno a includere il blocco nella catena canonica. Non può essere ripristinato a meno che un utente malevolo distrugga milioni di ether (miliardi di $USD).
-Questi aggiornamenti dei blocchi non si verificano in ogni slot. Al contrario sono giustificabili e finalizzabili solo i blocchi di confine di un'epoca. Questi blocchi sono noti come "punti di controllo" (checkpoint). L'aggiornamento considera coppie di punti di controllo. Per aggiornare il punto di controllo meno recente a finalizzato e il più recente a giustificato deve esistere un "collegamento di super-maggioranza" tra due punti di controllo successivi (es. due terzi dell'ether in staking totale ha votato affinché il punto di controllo B sia il discendente corretto del punto di controllo A).
+Questi aggiornamenti dei blocchi non si verificano in ogni slot. Al contrario sono giustificabili e finalizzabili solo i blocchi di confine di un'epoca. Questi blocchi sono noti come "punti di controllo" (checkpoint). L'aggiornamento considera coppie di punti di controllo. Per aggiornare il punto di controllo meno recente a finalizzato e il blocco più recente a giustificato, deve esistere un "collegamento di supermaggioranza" tra due punti di controllo successivi (cioè, due terzi dell'ether totale in staking votano che il punto di controllo B è il discendente corretto del punto di controllo A).
Poiché la finalità richiede un accordo di due terzi per rendere un blocco canonico, un utente malevolo non può creare una catena finalizzata alternativa senza:
1. Possedere o manipolare due terzi dell'ether in staking totale.
2. Distruggere almeno un terzo dell'ether in staking totale.
-La prima condizione sorge perché per finalizzare una catena servono due terzi dell'ether in staking. La seconda sorge perché se due terzi dello stake totale ha votato in favore di entrambe le biforcazioni, allora un terzo deve aver votato su entrambe. Il doppio voto è una condizione di slashing che subirebbe la punizione massima, con la distruzione di un terzo dello stake totale. A maggio 2022, questo richiederebbe a un utente malevolo di bruciare ether per un valore di circa $10 miliardi. L'algoritmo che giustifica e finalizza i blocchi in Gasper è una forma lievemente modificata di [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf).
+La prima condizione sorge perché per finalizzare una catena servono due terzi dell'ether in staking. La seconda sorge perché se due terzi dello stake totale ha votato in favore di entrambe le biforcazioni, allora un terzo deve aver votato su entrambe. Il doppio voto è una condizione di slashing che subirebbe la punizione massima, con la distruzione di un terzo dello stake totale. A maggio 2022, questo richiederebbe a un utente malevolo di bruciare ether per un valore di circa $10 miliardi. L'algoritmo che giustifica e finalizza i blocchi in Gasper è una forma leggermente modificata di [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf).
### Incentivi e slashing {#incentives-and-slashing}
@@ -42,11 +42,11 @@ Oltre alla sicurezza, Gasper fornisce anche una "vitalità plausibile". Questa c
### Scelta della biforcazione {#fork-choice}
-La definizione originale di Casper-FFG prevedeva un algoritmo di scelta della biforcazione che imponeva la regola: `segui la catena contenente il punto di controllo giustificato avente l'altezza maggiore`, dove l'altezza è definita come la massima distanza dal blocco di genesi. In Gasper, la regola di scelta della biforcazione originale è deprecata in favore di un algoritmo più sofisticato, denominato LMD-GHOST. È importante rendersi conto che in condizioni normali non è necessaria una regola di scelta della biforcazione: esiste un propositore del singolo blocco per ogni slot e i validatori onesti lo attestano. Serve un algoritmo di scelta della biforcazione solo quando vi è una grande asincronia della rete o quando un propositore del blocco disonesto ha generato confusione. Tuttavia, quando si presentano questi casi, l'algoritmo di scelta della biforcazione è un’importante difesa che protegge la catena corretta.
+La definizione originale di Casper-FFG prevedeva un algoritmo di scelta della biforcazione che imponeva la regola: `segui la catena contenente il punto di controllo giustificato che ha l'altezza maggiore`, dove l'altezza è definita come la massima distanza dal blocco di genesi. In Gasper, la regola di scelta della biforcazione originale è deprecata in favore di un algoritmo più sofisticato, denominato LMD-GHOST. È importante rendersi conto che in condizioni normali non è necessaria una regola di scelta della biforcazione: esiste un propositore del singolo blocco per ogni slot e i validatori onesti lo attestano. Serve un algoritmo di scelta della biforcazione solo quando vi è una grande asincronia della rete o quando un propositore del blocco disonesto ha generato confusione. Tuttavia, quando si presentano questi casi, l'algoritmo di scelta della biforcazione è un’importante difesa che protegge la catena corretta.
LMD-GHOST sta per "latest message-driven greedy heaviest observed sub-tree". Si tratta di un termine molto gergale per definire un algoritmo che seleziona la biforcazione che presenta il peso di attestazioni accumulate più elevato rispetto a quello canonico (greedy heaviest subtree) e che se vengono ricevuti più messaggi da un validatore, viene considerato solo l’ultimo (latest-message driveno). Prima di aggiungere il blocco più pesante alla sua catena canonica, ogni validatore valuta ogni blocco usando questa regola.
-## Letture consigliate {#further-reading}
+## Ulteriori letture {#further-reading}
-- [Gasper: combinazione di GHOST e Casper](https://arxiv.org/pdf/2003.03052.pdf)
+- [Gasper: Combining GHOST and Casper](https://arxiv.org/pdf/2003.03052.pdf)
- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/index.md
index b74b05c7acf..4afa158cea7 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/index.md
@@ -4,11 +4,11 @@ description: Spiegazione del protocollo di consenso proof-of-stake e del suo ruo
lang: it
---
-La Proof of Stake (PoS) è alla base del [meccanismo di consenso](/developers/docs/consensus-mechanisms/) di Ethereum. Ethereum ha attivato il suo meccanismo di Proof of Stake nel 2022 perché è più sicuro, consuma meno energia ed è migliore per implementare nuove soluzioni di ridimensionamento rispetto all'architettura di [Proof of Work](/developers/docs/consensus-mechanisms/pow) precedente.
+Il Proof-of-stake (PoS) è alla base del [meccanismo di consenso](/developers/docs/consensus-mechanisms/) di Ethereum. Ethereum ha attivato il suo meccanismo di proof-of-stake nel 2022 perché è più sicuro, consuma meno energia ed è migliore per implementare nuove soluzioni di ridimensionamento rispetto alla precedente architettura [proof-of-work](/developers/docs/consensus-mechanisms/pow).
## Prerequisiti {#prerequisites}
-Per capire meglio questa pagina ti consigliamo di leggere i [meccanismi di consenso](/developers/docs/consensus-mechanisms/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima i [meccanismi di consenso](/developers/docs/consensus-mechanisms/).
## Cos'è la proof-of-stake (PoS)? {#what-is-pos}
@@ -20,38 +20,38 @@ Per partecipare come validatore, un utente deve depositare 32 ETH nel contratto
Se con il proof-of-work la tempistica dei blocchi è determinata dalla difficoltà di mining, nel proof-of-stake il ritmo invece è fisso. Il tempo in Ethereum di proof-of-stake è diviso in slot (12 secondi) ed epoche (32 slot). In ogni slot viene selezionato casualmente un validatore come propositore di blocchi. Questo validatore è responsabile della creazione di un nuovo blocco e del suo invio ad altri nodi sulla rete. Inoltre, in ogni slot, è scelto casualmente un comitato di validatori, i cui voti sono usati per determinare la validità del blocco proposto. Dividere le impostazioni del validatore in comitati è importante per mantenere gestibile il carico della rete. I comitati suddividono la serie di validatori affinché ogni validatore attivo attesti in ogni epoca ma non in ogni slot.
-## Come viene eseguita una transazione nel PoS di Ethereum {#transaction-execution-ethereum-pos}
+## Come viene eseguita una transazione in Ethereum PoS {#transaction-execution-ethereum-pos}
Di seguito è fornita una spiegazione completa dell'esecuzione di una transazione nel proof-of-stake di Ethereum.
-1. Un utente crea e firma una [transazione](/developers/docs/transactions/) con la propria chiave privata. Questo processo è solitamente gestito da un portafoglio o da una libreria come [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/), ecc., ma in sostanza l'utente sta facendo una richiesta a un nodo utilizzando l'[API JSON-RPC](/developers/docs/apis/json-rpc/) di Ethereum. L'utente definisce l'importo di carburante che è disposto a pagare come mancia a un validatore per incoraggiarlo a includere la transazione in un blocco. Le [mance](/developers/docs/gas/#priority-fee) sono pagate al validatore bruciando la [commissione di base](/developers/docs/gas/#base-fee).
-2. La transazione è inviata a un [client di esecuzione](/developers/docs/nodes-and-clients/#execution-client) di Ethereum che ne verifica la validità. Ciò significa assicurarsi che il mittente abbia abbastanza ETH per realizzare la transazione e che l'abbia firmata con la chiave corretta.
-3. Se la transazione è valida, il client di esecuzione la aggiunge al proprio mempool locale (elenco di transazioni in sospeso) e inoltre la trasmette agli altri nodi sulla rete di gossip del livello di esecuzione. Quando gli altri nodi ricevono la transazione, la aggiungono anche al proprio mempool locale. Gli utenti avanzati potrebbero astenersi dalla trasmissione della propria transazione, inoltrandola piuttosto a costruttori di blocchi specializzati, come [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). Ciò consente loro di organizzare le transazioni nei blocchi successivi per il massimo profitto ([MEV](/developers/docs/mev/#mev-extraction)).
-4. Uno dei nodi del validatore sulla rete è il propositore del blocco per lo slot corrente, selezionato precedentemente in modo pseudo-casuale utilizzando RANDAO. Questo nodo è responsabile per la costruzione e trasmissione del blocco successivo da aggiungere alla blockchain di Ethereum e di aggiornare lo stato globale. Il nodo si compone di tre parti: un client di esecuzione, un client di consenso e un client di validazione. Il client di esecuzione raggruppa le transazioni dal mempool locale in un "payload di esecuzione" e le esegue localmente per generare un cambiamento di stato. Questa informazione è passata al client di consenso, dove il payload di esecuzione è impacchettato come parte di un "blocco Beacon" che contiene anche informazioni su ricompense, sanzioni, tagli, attestazioni, ecc., che consentono alla rete di concordare sulla sequenza di blocchi alla testa della catena. La comunicazione tra i client di esecuzione e di consenso è descritta più nel dettaglio in [Connettere i client di consenso e di esecuzione](/developers/docs/networking-layer/#connecting-clients).
-5. Gli altri nodi ricevono il nuovo blocco Beacon sulla rete di gossip del livello di consenso. Lo passano al proprio client di esecuzione, dove le transazioni sono rieseguite localmente per garantire che il cambiamento di stato proposto sia valido. Il client di validazione, poi, attesta che il blocco è valido e che è il blocco successivo logico nella sua visione della catena (ossia che si basa sulla catena con il maggior peso di attestazioni, come definito dalle [regole di scelta della diramazione](/developers/docs/consensus-mechanisms/pos/#fork-choice)). Il blocco è aggiunto al database locale in ogni nodo che lo attesta.
+1. Un utente crea e firma una [transazione](/developers/docs/transactions/) con la propria chiave privata. Questa operazione è solitamente gestita da un portafoglio o una libreria come [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) ecc., ma, dietro le quinte, l'utente effettua una richiesta a un nodo usando l'[API JSON-RPC](/developers/docs/apis/json-rpc/) di Ethereum. L'utente definisce l'importo di carburante che è disposto a pagare come mancia a un validatore per incoraggiarlo a includere la transazione in un blocco. Le [mance](/developers/docs/gas/#priority-fee) vengono pagate al validatore, mentre la [commissione di base](/developers/docs/gas/#base-fee) viene bruciata.
+2. La transazione viene inviata a un [client d'esecuzione](/developers/docs/nodes-and-clients/#execution-client) di Ethereum che ne verifica la validità. Ciò significa assicurarsi che il mittente abbia abbastanza ETH per realizzare la transazione e che l'abbia firmata con la chiave corretta.
+3. Se la transazione è valida, il client di esecuzione la aggiunge al proprio mempool locale (elenco di transazioni in sospeso) e inoltre la trasmette agli altri nodi sulla rete di gossip del livello di esecuzione. Quando gli altri nodi ricevono la transazione, la aggiungono anche al proprio mempool locale. Gli utenti esperti potrebbero astenersi dal trasmettere la loro transazione e inoltrarla invece a costruttori di blocchi specializzati come [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). Ciò consente loro di organizzare le transazioni nei blocchi imminenti per il massimo profitto ([MEV](/developers/docs/mev/#mev-extraction)).
+4. Uno dei nodi del validatore sulla rete è il propositore del blocco per lo slot corrente, selezionato precedentemente in modo pseudo-casuale utilizzando RANDAO. Questo nodo è responsabile per la costruzione e trasmissione del blocco successivo da aggiungere alla blockchain di Ethereum e di aggiornare lo stato globale. Il nodo si compone di tre parti: un client di esecuzione, un client di consenso e un client di validazione. Il client di esecuzione raggruppa le transazioni dal mempool locale in un "payload di esecuzione" e le esegue localmente per generare un cambiamento di stato. Questa informazione è passata al client di consenso, dove il payload di esecuzione è impacchettato come parte di un "blocco Beacon" che contiene anche informazioni su ricompense, sanzioni, tagli, attestazioni, ecc., che consentono alla rete di concordare sulla sequenza di blocchi alla testa della catena. La comunicazione tra i client d'esecuzione e i client di consenso è descritta più in dettaglio in [Connettere i client di consenso e di esecuzione](/developers/docs/networking-layer/#connecting-clients).
+5. Gli altri nodi ricevono il nuovo blocco Beacon sulla rete di gossip del livello di consenso. Lo passano al proprio client di esecuzione, dove le transazioni sono rieseguite localmente per garantire che il cambiamento di stato proposto sia valido. Il client del validatore attesta quindi che il blocco è valido e che è il blocco logico successivo nella sua visione della catena (ossia si basa sulla catena con il maggior peso di attestazioni, come definito nelle [regole di scelta della biforcazione](/developers/docs/consensus-mechanisms/pos/#fork-choice)). Il blocco è aggiunto al database locale in ogni nodo che lo attesta.
6. La transazione è considerabile "finalizzata" se è diventata parte di una catena con un "collegamento di super-maggioranza" tra due punti di controllo. I punti di controllo si trovano all'inizio di ogni epoca ed esistono per rendere conto del fatto che solo un sottoinsieme di validatori attivi attesta in ogni slot, ma tutti i validatori attivi attestano attraverso ogni epoca. Perciò è solo tra epoche che si può dimostrare un "collegamento di super-maggioranza" (è qui che il 66% degli ETH totali in staking sulla rete concorda su due punti di controllo).
Ulteriori dettagli sulla finalità si possono trovare di seguito.
## Finalità {#finality}
-Una transazione ha "finalità" nelle reti distribuite quando fa parte di un blocco che non può cambiare senza bruciare un consistente quantitativo di ETH. Su Ethereum di proof-of-stake, questo è gestito usando i blocchi di "punto di controllo". Il primo blocco in ogni epoca è un punto di controllo. I validatori votano per le coppie di punti di controllo che considerano valide. Se una coppia di punti di controllo attrae voti che rappresentano almeno due terzi degli ETH in staking totali, i punti di controllo sono aggiornati. Il più recente dei due (target), diventa "giustificato". Il primo dei due è già giustificato perché era il "target" nell'epoca precedente. Ora è aggiornato a "finalizzato".
+Una transazione ha "finalità" nelle reti distribuite quando fa parte di un blocco che non può cambiare senza bruciare un consistente quantitativo di ETH. Su Ethereum di proof-of-stake, questo è gestito usando i blocchi di "punto di controllo". Il primo blocco in ogni epoca è un punto di controllo. I validatori votano per le coppie di punti di controllo che considerano valide. Se una coppia di punti di controllo attrae voti che rappresentano almeno due terzi degli ETH in staking totali, i punti di controllo sono aggiornati. Il più recente dei due (target), diventa "giustificato". Il primo dei due è già giustificato perché era il "target" nell'epoca precedente. Ora è aggiornato a "finalizzato". Questo processo di aggiornamento dei checkpoint è gestito da **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)**. Casper-FFG è uno strumento di finalità del blocco per il consenso. Una volta che un blocco è finalizzato, non può essere annullato o modificato senza un taglio della maggioranza degli staker, rendendolo economicamente insostenibile.
-Per annullare un blocco finalizzato, un utente malevolo dovrebbe impegnarsi a perdere almeno un terzo dell'offerta totale di ETH in staking. Il motivo esatto di ciò è spiegato in questo [post del blog dell'Ethereum Foundation](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Poiché la finalità richiede una maggioranza di due terzi, un utente malevolo potrebbe impedire alla rete di raggiungere la finalità votando con un terzo dello stake totale. Esiste un meccanismo per difendersi da questa eventualità: la [fuga d'inattività](https://eth2book.info/bellatrix/part2/incentives/inactivity). Questa si attiva ogni volta che la catena non riesce a finalizzare per più di quattro epoche. La fuga d'inattività disperde gli ETH messi in staking dai validatori che votano contro la maggioranza, consentendo a quest'ultima di ottenere nuovamente la maggioranza di due terzi e di finalizzare la catena.
+Per annullare un blocco finalizzato, un utente malevolo dovrebbe impegnarsi a perdere almeno un terzo dell'offerta totale di ETH in staking. La ragione esatta di ciò è spiegata in questo [post del blog della Ethereum Foundation](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Poiché la definitività richiede una maggioranza di due terzi, un utente malevolo potrebbe impedire alla rete di raggiungere la finalità votando con un terzo dello stake totale. Esiste un meccanismo per difendersi da questo: l'[inactivity leak](https://eth2book.info/bellatrix/part2/incentives/inactivity). Questa si attiva ogni volta che la catena non riesce a finalizzare per più di quattro epoche. La fuga d'inattività disperde gli ETH messi in staking dai validatori che votano contro la maggioranza, consentendo a quest'ultima di ottenere nuovamente la maggioranza di due terzi e di finalizzare la catena.
## Sicurezza cripto-economica {#crypto-economic-security}
Gestire un validatore è un impegno. Il validatore deve mantenere hardware e connettività sufficienti per partecipare alla validazione e proposta dei blocchi. In cambio, il validatore è pagato in ETH (il suo saldo di staking aumenta). D'altra parte, la partecipazione come validatore apre anche nuove strade attraverso le quali gli utenti potrebbero attaccare la rete per profitto personale o sabotaggio. Per impedirlo, i validatori perdono le ricompense in ETH se non partecipano quando richiesto e il loro stake esistente può essere distrutto se si comportano in modo disonesto. Due comportamenti principali sono considerabili disonesti: proporre diversi blocchi in uno slot singolo (equivoco) e inviare attestazioni contraddittorie.
-L'importo di ETH oggetto di slashing dipende da quanti validatori sono oggetto sanzionati in contemporanea. Questa è nota come la ["sanzione di correlazione"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) e può essere minore (circa l'1% dello stake se viene tagliato un singolo validatore) oppure può comportare la distruzione del 100% dello stake del validatore (taglio di massa). Viene imposto a metà di un periodo di uscita forzata che inizia con una sanzione immediata (fino a 1 ETH) al Giorno 1, la sanzione di correlazione al Giorno 18 e, infine, espulsione dalla rete al Giorno 36. Ogni giorno ricevono modeste sanzioni d'attestazione perché sono presenti sulla rete ma non inviano voti. Tutto questo significa che un attacco coordinato sarebbe molto costoso per un utente malevolo.
+L'importo di ETH oggetto di slashing dipende da quanti validatori sono oggetto sanzionati in contemporanea. Questa è nota come la ["sanzione di correlazione"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty), e può essere minore (circa l'1% dello stake se viene tagliato un singolo validatore) oppure può comportare la distruzione del 100% dello stake del validatore (taglio di massa). Viene imposto a metà di un periodo di uscita forzata che inizia con una sanzione immediata (fino a 1 ETH) al Giorno 1, la sanzione di correlazione al Giorno 18 e, infine, espulsione dalla rete al Giorno 36. Ogni giorno ricevono modeste sanzioni d'attestazione perché sono presenti sulla rete ma non inviano voti. Tutto questo significa che un attacco coordinato sarebbe molto costoso per un utente malevolo.
## Scelta della biforcazione {#fork-choice}
-Quando la rete opera in modo ottimale ed onesto, c'è sempre e solo un nuovo blocco alla testa della catena e tutti i validatori attestano quel blocco. È però possibile che i validatori abbiano una visione differente della testa della catena, a causa della latenza della rete o perché un propositore di blocchi ha equivocato. I client di consenso necessitano quindi di un algoritmo per decidere quale favorire. L'algoritmo usato in Ethereum di proof-of-stake è detto [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) e funziona identificando la biforcazione avente il peso di attestazioni maggiore nella sua storia.
+Quando la rete opera in modo ottimale ed onesto, c'è sempre e solo un nuovo blocco alla testa della catena e tutti i validatori attestano quel blocco. È però possibile che i validatori abbiano una visione differente della testa della catena, a causa della latenza della rete o perché un propositore di blocchi ha equivocato. I client di consenso necessitano quindi di un algoritmo per decidere quale favorire. L'algoritmo utilizzato nel proof-of-stake di Ethereum è chiamato [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) e funziona identificando la biforcazione che ha il maggior peso di attestazioni nella sua storia.
## Proof-of-stake e sicurezza {#pos-and-security}
-La minaccia di un [attacco 51%](https://www.investopedia.com/terms/1/51-attack.asp) esiste ancora sul proof-of-stake, come già nel proof-of-work, ma è ancora più rischiosa per gli utenti malevoli. Un utente malevolo necessiterebbe del 51% degli ETH in staking. Potrebbe poi usare le proprie attestazioni per garantire che la propria biforcazione preferita sia quella con le maggiori attestazioni accumulate. Il 'peso' delle attestazioni accumulate è ciò che i client di consenso usano per determinare la catena corretta, così l'utente malevolo potrebbe rendere canonica la propria biforcazione. Tuttavia, un punto di forza del proof-of-stake rispetto al proof-of-work è che la community gode di una flessibilità nel preparare un contrattacco. Ad esempio, i validatori onesti potrebbero decidere di continuare a costruire sulla catena di minoranza e ignorare la biforcazione dell'utente malevolo, incoraggiando app, borse e pool a fare lo stesso. Potrebbero anche decidere di rimuovere forzatamente l'utente malevolo dalla rete e di distruggerne gli ETH in staking. Si tratta di difese economiche forti contro un attacco 51%.
+La minaccia di un [attacco del 51%](https://www.investopedia.com/terms/1/51-attack.asp) esiste ancora nel proof-of-stake, così come nel proof-of-work, ma è ancora più rischiosa per gli aggressori. Un utente malevolo necessiterebbe del 51% degli ETH in staking. Potrebbe poi usare le proprie attestazioni per garantire che la propria biforcazione preferita sia quella con le maggiori attestazioni accumulate. Il 'peso' delle attestazioni accumulate è ciò che i client di consenso usano per determinare la catena corretta, così l'utente malevolo potrebbe rendere canonica la propria biforcazione. Tuttavia, un punto di forza del proof-of-stake rispetto al proof-of-work è che la community gode di una flessibilità nel preparare un contrattacco. Ad esempio, i validatori onesti potrebbero decidere di continuare a costruire sulla catena di minoranza e ignorare la biforcazione dell'utente malevolo, incoraggiando app, borse e pool a fare lo stesso. Potrebbero anche decidere di rimuovere forzatamente l'utente malevolo dalla rete e di distruggerne gli ETH in staking. Si tratta di difese economiche forti contro un attacco 51%.
Oltre agli attacchi del 51%, i malintenzionati potrebbero anche tentare altri tipi di attività malevole, come:
@@ -64,14 +64,14 @@ In generale è stato dimostrato che il proof-of-stake, come implementato su Ethe
## Pro e contro {#pros-and-cons}
-| Pro | Contro |
-| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
-| Lo staking rende più semplice per le persone partecipare alla protezione della rete, promuovendo la decentralizzazione. Il nodo del validatore può essere eseguito su un normale laptop. I pool di staking consentono agli utenti di mettere in staking senza avere 32 ETH. | Il proof-of-stake è più giovane e meno testato rispetto al proof-of-work |
-| Lo staking è più decentralizzato. Non valgono le stesse economie di scala del mining proof-of-work. | Il proof-of-stake è più complesso da implementare del proof-of-work |
-| Il proof-of-stake offre una maggiore sicurezza cripto-economica rispetto al proof-of-work | Gli utenti devono far funzionare tre parti di software per partecipare al proof-of-stake di Ethereum. |
-| È richiesta una minore emissione di nuovi ETH per incentivare i partecipanti alla rete | |
+| Pro | Contro |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| Lo staking rende più semplice per le persone partecipare alla protezione della rete, promuovendo la decentralizzazione. Il nodo del validatore può essere eseguito su un normale laptop. I pool di staking consentono agli utenti di mettere in staking senza avere 32 ETH. | Il proof-of-stake è più giovane e meno testato rispetto al proof-of-work |
+| Lo staking è più decentralizzato. Non valgono le stesse economie di scala del mining proof-of-work. | Il proof-of-stake è più complesso da implementare del proof-of-work |
+| Il proof-of-stake offre una maggiore sicurezza cripto-economica rispetto al proof-of-work | Gli utenti devono far funzionare tre parti di software per partecipare al proof-of-stake di Ethereum. |
+| È richiesta una minore emissione di nuovi ETH per incentivare i partecipanti alla rete | |
-### Confronto con proof-of-work {#comparison-to-proof-of-work}
+### Confronto con il proof-of-work {#comparison-to-proof-of-work}
Originariamente Ethereum utilizzava il proof-of-work, ma è passata al proof-of-stake nel settembre 2022. Il PoS offre svariati vantaggi rispetto al PoW, come ad esempio:
@@ -84,16 +84,16 @@ Originariamente Ethereum utilizzava il proof-of-work, ma è passata al proof-of-
## Letture consigliate {#further-reading}
-- [Domande Frequenti sul 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_
-- [Proof of Stake: come ho imparato ad amare la soggettività debole](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_
+- [Proof of Stake: come ho imparato ad amare la Weak Subjectivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_
- [Attacco e difesa del proof-of-stake di Ethereum](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs)
-- [Una filosofia di progettazione di Proof of Stake](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_
+- [Una filosofia di design del Proof of Stake](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_
- [Video: Vitalik Buterin spiega il proof-of-stake a Lex Fridman](https://www.youtube.com/watch?v=3yrqBG-7EVE)
## Argomenti correlati {#related-topics}
-- [Proof of Work](/developers/docs/consensus-mechanisms/pow/)
-- [Proof of Authority](/developers/docs/consensus-mechanisms/poa/)
+- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/)
+- [Proof-of-authority](/developers/docs/consensus-mechanisms/poa/)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/keys/index.md
index d229a5c230c..cd72f7dc835 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/keys/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/keys/index.md
@@ -6,15 +6,15 @@ lang: it
Ethereum protegge le risorse degli utenti utilizzando la crittografia a chiave pubblica-privata. La chiave pubblica è utilizzata come base per un indirizzo di Ethereum, ossia, è visibile al pubblico generale ed è utilizzata come un identificativo univoco. La chiave privata (o 'segreta') dovrebbe essere accessibile soltanto al proprietario di un conto. La chiave privata è utilizzata per 'firmare' le transazioni e i dati, così che la crittografia possa provare che il detentore approva determinate azioni di una chiave privata specifica.
-Le chiavi di Ethereum sono generate utilizzando la [crittografia a curva ellittica](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography).
+Le chiavi di Ethereum sono generate usando la [crittografia a curva ellittica](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography).
-Tuttavia, quando Ethereum è passato dal [proof-of-work](/developers/docs/consensus-mechanisms/pow) al [proof-of-stake](/developers/docs/consensus-mechanisms/pos), è stato aggiunto un nuovo tipo di chiave. Le chiavi originali funzionano esattamente come prima, non ci sono state modifiche alle chiavi basate sulla curva ellittica che proteggono i conti. Tuttavia, gli utenti necessitavano di un nuovo tipo di chiave per partecipare al proof-of-stake mettendo gli ETH in staking ed eseguire i validatori. Questa esigenza è sorta dalle sfide di scalabilità associate al passaggio di molti messaggi tra grandi quantità di validatori, il che richiede un metodo crittografico facilmente aggregabile per ridurre la quantità di comunicazioni necessarie perché la rete raggiunga il consenso.
+Tuttavia, quando Ethereum è passato da [proof-of-work](/developers/docs/consensus-mechanisms/pow) a [proof-of-stake](/developers/docs/consensus-mechanisms/pos), a Ethereum è stato aggiunto un nuovo tipo di chiave. Le chiavi originali funzionano esattamente come prima, non ci sono state modifiche alle chiavi basate sulla curva ellittica che proteggono i conti. Tuttavia, gli utenti necessitavano di un nuovo tipo di chiave per partecipare al proof-of-stake mettendo gli ETH in staking ed eseguire i validatori. Questa esigenza è sorta dalle sfide di scalabilità associate al passaggio di molti messaggi tra grandi quantità di validatori, il che richiede un metodo crittografico facilmente aggregabile per ridurre la quantità di comunicazioni necessarie perché la rete raggiunga il consenso.
Questo nuovo tipo di chiave utilizza lo [schema di firma **Boneh-Lynn-Shacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature). BLS consente un'aggregazione molto efficiente delle firme, ma consente anche di sottoporre a ingegneria inversa le chiavi dei singoli validatori aggregati ed è ideale per gestire le azioni tra validatori.
## I due tipi di chiavi del validatore {#two-types-of-keys}
-Prima del passaggio al proof-of-stake, gli utenti di Ethereum avevano soltanto una chiave privata basata sulla curva ellittica per accedere ai propri fondi. Con l'introduzione del proof-of-stake, gli utenti che desideravano essere staker in autonomia necessitavano anche di una **chiave del validatore** e di una **chiave di prelievo**.
+Prima del passaggio al proof-of-stake, gli utenti di Ethereum avevano soltanto una chiave privata basata sulla curva ellittica per accedere ai propri fondi. Con l'introduzione del proof-of-stake, gli utenti che desideravano essere staker in solitaria richiedevano anche una **chiave del validatore** e una **chiave di prelievo**.
### La chiave del validatore {#validator-key}
@@ -23,9 +23,9 @@ La chiave di firma del validatore consiste in due elementi:
- Chiave **privata** del validatore
- Chiave **pubblica** del validatore
-Lo scopo della chiave privata del validatore è firmare le operazioni sulla catena, quali proposte e attestazioni dei blocchi. Per questo, queste chiavi devono essere tenute in un portafoglio "caldo".
+Lo scopo della chiave privata del validatore è di firmare le operazioni on-chain come le proposte di blocchi e le attestazioni. Per questo, queste chiavi devono essere tenute in un portafoglio "caldo".
-Questa flessibilità ha il vantaggio di spostare molto rapidamente le chiavi di firma del validatore da un dispositivo a un altro, però se vengono perse o rubate un ladro potrebbe **agire malevolmente** in alcuni modi:
+Questa flessibilità ha il vantaggio di spostare le chiavi di firma del validatore molto rapidamente da un dispositivo all'altro; tuttavia, se vengono perse o rubate, un malintenzionato potrebbe **agire in modo malevolo** in alcuni modi:
- Far tagliare il validatore:
- Facendo il propositore e firmando due blocchi Beacon differenti per lo stesso slot
@@ -33,13 +33,15 @@ Questa flessibilità ha il vantaggio di spostare molto rapidamente le chiavi di
- Facendo l'attestatore e firmando due attestazioni differenti aventi la stessa destinazione
- Forzare un'uscita volontaria, che impedisce al validatore di mettere in staking e concede l'accesso al suo saldo di ETH al proprietario della chiave di prelievo
-La **chiave pubblica del validatore** è inclusa nei dati della transazione quando un utente deposita gli ETH al contratto di deposito di staking. Questi sono noti come _dati di deposito_ e consentono a Ethereum di identificare il validatore.
+La **chiave pubblica del validatore** è inclusa nei dati della transazione quando un utente deposita ETH nel contratto di deposito dello staking. Questi sono noti come _dati di deposito_ e permettono a Ethereum di identificare il validatore.
### Credenziali di prelievo {#withdrawal-credentials}
-Ogni validatore ha una proprietà nota come _credenziali di prelievo_. Questo campo di 32 byte inizia con uno `0x00`, che rappresenta le credenziali di prelievo BLS, o uno `0x01`, che rappresenta le credenziali che puntano a un indirizzo di esecuzione.
+Ogni validatore ha una proprietà nota come _credenziali di prelievo_. Il primo byte di questo campo a 32 byte identifica il tipo di conto: `0x00` rappresenta le credenziali BLS originali (pre-Shapella, non prelevabili), `0x01` rappresenta le credenziali legacy che puntano a un indirizzo di esecuzione, e `0x02` rappresenta il moderno tipo di credenziale composta.
-I validatori con le chiavi BLS `0x00` devono aggiornare tali credenziali affinché puntino a un indirizzo di esecuzione per poter attivare i pagamenti del saldo in eccesso o il prelievo completo dallo staking. Ciò può essere fatto fornendo un indirizzo di esecuzione nei dati di deposito durante la generazione iniziale della chiave, _O_ utilizzando la chiave di prelievo in un momento successivo per firmare e trasmettere un messaggio `BLSToExecutionChange`.
+I validatori con chiavi BLS `0x00` devono aggiornare queste credenziali affinché puntino a un indirizzo di esecuzione per attivare i pagamenti del saldo in eccesso o il prelievo completo dallo staking. Ciò può essere fatto fornendo un indirizzo di esecuzione nei dati di deposito durante la generazione iniziale della chiave, _OPPURE_ utilizzando la chiave di prelievo in un momento successivo per firmare e trasmettere un messaggio `BLSToExecutionChange`.
+
+[Maggiori informazioni sulle credenziali di prelievo del validatore](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/)
### La chiave di prelievo {#withdrawal-key}
@@ -56,11 +58,13 @@ Separare le chiavi del validatore dalle chiavi del conto di Ethereum consente a
-## Derivare le chiavi da una frase di seed {#deriving-keys-from-seed}
+**Nota**: uscire dai doveri di staking e prelevare il saldo di un validatore attualmente richiede la firma di un [messaggio di uscita volontaria (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) con la chiave del validatore. Tuttavia, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) è una proposta che in futuro consentirà a un utente di attivare l'uscita di un validatore e di prelevarne il saldo, firmando i messaggi di uscita con la chiave di prelievo. Questo ridurrà le ipotesi di fiducia, consentendo agli staker che delegano ETH a [fornitori di staking-as-a-service](/staking/saas/#what-is-staking-as-a-service) di mantenere il controllo dei loro fondi.
+
+## Derivare le chiavi da una frase seed {#deriving-keys-from-seed}
Se ogni 32 ETH in staking richiedessero una nuova serie di 2 chiavi completamente indipendenti, la gestione delle chiavi diverrebbe rapidamente scomoda, specialmente per gli utenti che eseguono più validatori. Invece, più chiavi del validatore sono derivabili da un'unica frase segreta comune e memorizzare tale singola frase segreta consente l'accesso a più chiavi del validatore.
-Le [frasi mnemoniche](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) e i percorsi sono funzionalità prominenti che gli utenti incontrano spesso quando [accedono](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) ai propri portafogli. La frase mnemonica è una sequenza di parole che agisce da seed iniziale per una chiave privata. Combinandola con dei dati aggiuntivi, la frase mnemonica genera un hash noto come la 'chiave principale'. Questa può essere vista come la radice di un albero. I rami da questo albero sono derivabili utilizzando un percorso gerarchico così che i nodi figli possano esistere come combinazioni dell'hash del loro nodo genitore e del loro indice nell'albero. Leggi informazioni sugli standard [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) e [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) per la generazione di chiavi basate sulla frase mnemonica.
+[Le mnemoniche](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) e i percorsi sono caratteristiche importanti che gli utenti incontrano spesso quando [accedono](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) ai loro portafogli. La frase mnemonica è una sequenza di parole che agisce da seed iniziale per una chiave privata. Combinandola con dei dati aggiuntivi, la frase mnemonica genera un hash noto come la 'chiave principale'. Questa può essere vista come la radice di un albero. I rami da questo albero sono derivabili utilizzando un percorso gerarchico così che i nodi figli possano esistere come combinazioni dell'hash del loro nodo genitore e del loro indice nell'albero. Leggi gli standard [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) e [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) per la generazione di chiavi basata su mnemonica.
Questi percorsi hanno la seguente struttura, che risulterà familiare agli utenti che hanno interagito con portafogli hardware:
@@ -71,10 +75,10 @@ m/44'/60'/0'/0`
Gli slash in questo percorso separano i componenti della chiave privata come segue:
```
-master_key / purpose / coin_type / account / change / address_index
+chiave_master / scopo / tipo_moneta / conto / cambio / indice_indirizzo
```
-Questa logica consente agli utenti di collegare quanti più validatori possibili a una singola **frase mnemonica**, poiché la radice dell'albero può essere comune e la differenziazione può verificarsi a livello dei rami. L'utente può **derivare qualsiasi numero di chiavi** dalla frase mnemonica.
+Questa logica consente agli utenti di collegare quanti più validatori possibile a un'unica **frase mnemonica**, poiché la radice dell'albero può essere comune e la differenziazione può avvenire nei rami. L'utente può **derivare un numero qualsiasi di chiavi** dalla frase mnemonica.
```
[m / 0]
@@ -86,11 +90,13 @@ Questa logica consente agli utenti di collegare quanti più validatori possibili
[m / 2]
```
-Ogni ramo è separato da uno `/`, quindi `m/2` significa iniziare con la chiave principale e seguire il ramo 2. Nello schema seguente, una singola frase mnemonica è utilizzata per memorizzare tre chiavi di prelievo, ognuna con due validatori associati.
+Ogni ramo è separato da un `/`, quindi `m/2` significa iniziare con la chiave master e seguire il ramo 2. Nello schema seguente, una singola frase mnemonica è utilizzata per memorizzare tre chiavi di prelievo, ognuna con due validatori associati.
-## 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)
+- [Generazione di chiavi EIP-2333 BLS12-381](https://eips.ethereum.org/EIPS/eip-2333)
+- [EIP-7002: Uscite attivate dal Livello di esecuzione](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge)
+- [Gestione delle chiavi su vasta scala](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md
index 1899d384e07..fad756323e9 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md
@@ -12,19 +12,19 @@ Questa pagina spiega la logica dietro il passaggio di Ethereum al proof-of-stake
I ricercatori di Ethereum considerano il proof-of-stake più sicuro del proof-of-work. Tuttavia, è stato implementato soltanto di recente per la vera rete principale di Ethereum ed è meno collaudato del proof-of-work. Le seguenti sezioni discutono dei pro e contro del modello di sicurezza del proof-of-stake rispetto al proof-of-work.
-### Costo di attacco {#cost-to-attack}
+### Costo per l'attacco {#cost-to-attack}
-Nel proof-of-stake, i validatori devono mettere in garanzia (in "staking") almeno 32 ETH in un contratto intelligente. Ethereum può distruggere l'ether in staking, per punire i validatori che si comportano in maniera errata. Per raggiungere il consenso, almeno il 66% dell'ether in staking totale deve votare in favore di una serie particolare di blocchi. I blocchi votati dal >=66% dello stake diventano "finalizzati", a significare che non possono essere rimossi o riorganizzati.
+Nel proof-of-stake, i validatori devono mettere in garanzia (in "staking") almeno 32 ETH in un contratto intelligente. Ethereum può distruggere l'ether in staking, per punire i validatori che si comportano in maniera errata. Per raggiungere il consenso, almeno il 66% dell'ether in staking totale deve votare in favore di una serie particolare di blocchi. I blocchi votati da >=66% dello stake diventano "finalizzati", il che significa che non possono essere rimossi o riorganizzati.
Attaccare la rete può significare impedire alla catena di finalizzarsi, o assicurare una certa organizzazione di blocchi nella catena canonica tale che avvantaggi un utente malevolo. Ciò richiede all'utente malevolo di deviare il percorso del consenso onesto, accumulando una grande quantità di ether e votando direttamente con essa, o ingannando i validatori onesti nel votare in un modo in particolare. A parte gli attacchi sofisticati e a bassa probabilità che ingannano i validatori onesti, il costo di attacco di Ethereum è il costo dello stake che un utente malevolo deve accumulare per influenzare il consenso a proprio favore.
-Il costo minimo di attacco è il >33% dello stake totale. Un utente malevolo che possiede il >33% dello stake totale può causare un ritardo di finalità semplicemente andando offline. Questo è un problema relativamente minore per la rete, esistendo un meccanismo, noto come "perdita d'inattività", che fa trapelare lo stake dai validatori offline finché la maggioranza online non rappresenta il 66% dello stake e può nuovamente finalizzare la catena. Inoltre, è teoricamente possibile, per un utente malevolo, causare la doppia finalità con poco più del 33% dello stake totale, creando due blocchi invece di uno, quando gli viene chiesto di essere produttore di blocchi e quindi di votare due volte con tutti i validatori. Ogni biforcazione richiede che soltanto il 50% dei validatori onesti rimanenti visualizzi ogni blocco per primo, quindi, se riescono a sincronizzare i propri messaggi nel modo giusto, potrebbero riuscire a finalizzare entrambe le biforcazioni. Ciò ha una bassa probabilità di successo, ma se un utente malevolo è riuscito a causare una doppia finalità, la comunità di Ethereum dovrebbe decidere di seguire una biforcazione, nel qual caso i validatori dell'utente malevolo verrebbero necessariamente frammentati nell'altra.
+Il costo più basso di un attacco è >33% dello stake totale. Un utente malintenzionato che detiene >33% dello stake totale può causare un ritardo di finalità semplicemente andando offline. Questo è un problema relativamente minore per la rete, esistendo un meccanismo, noto come "perdita d'inattività", che fa trapelare lo stake dai validatori offline finché la maggioranza online non rappresenta il 66% dello stake e può nuovamente finalizzare la catena. Inoltre, è teoricamente possibile, per un utente malevolo, causare la doppia finalità con poco più del 33% dello stake totale, creando due blocchi invece di uno, quando gli viene chiesto di essere produttore di blocchi e quindi di votare due volte con tutti i validatori. Ogni biforcazione richiede che soltanto il 50% dei validatori onesti rimanenti visualizzi ogni blocco per primo, quindi, se riescono a sincronizzare i propri messaggi nel modo giusto, potrebbero riuscire a finalizzare entrambe le biforcazioni. Ciò ha una bassa probabilità di successo, ma se un utente malevolo è riuscito a causare una doppia finalità, la comunità di Ethereum dovrebbe decidere di seguire una biforcazione, nel qual caso i validatori dell'utente malevolo verrebbero necessariamente frammentati nell'altra.
-Con il >33% dello stake totale, un utente malevolo ha una possibilità di avere un effetto minore (ritardo di finalità) o più grave (doppia finalità) sulla rete di Ethereum. Con più di 14.000.000 ETH in staking sulla rete e un prezzo rappresentativo di $1000/ETH, il costo minimo per eseguire questi attacchi è di `1000 x 14.000.000 x 0,33 = $4.620.000.000`. L'utente malevolo perderebbe tale denaro tramite il frazionamento e verrebbe espulso dalla rete. Per ripetere l'attacco, dovrebbe accumulare il >33% dello stake (nuovamente) e bruciarlo (di nuovo). Ogni tentativo di attaccare la rete costerebbe >$4,6 miliardi (a $1000/ETH e 14M di ETH in staking). L'utente malevolo, inoltre, viene espulso dalla rete quando è frazionato e dovrà aggiungersi alla coda d'attivazione per unirsi nuovamente. Ciò significa che il tasso di un attacco ripetuto è limitato non soltanto alla velocità a cui l'utente malevolo può accumulare il >33% dello stake totale, ma anche al tempo necessario per far accedere tutti i validatori alla rete. Ogni volta che l'utente malevolo attacca diventa molto più povero e il resto della comunità si arricchisce grazie allo shock di approvvigionamento risultante.
+Con >33% dello stake totale, un utente malintenzionato ha la possibilità di avere un effetto minore (ritardo di finalità) o più grave (doppia finalità) sulla rete di Ethereum. Con più di 14.000.000 di ETH messi in staking sulla rete e un prezzo rappresentativo di $1000/ETH, il costo minimo per sferrare questi attacchi è `1000 x 14.000.000 x 0,33 = $4.620.000.000`. L'utente malevolo perderebbe tale denaro tramite il frazionamento e verrebbe espulso dalla rete. Per attaccare di nuovo, dovrebbero accumulare >33% dello stake (di nuovo) e bruciarlo (di nuovo). Ogni tentativo di attaccare la rete costerebbe >$4,6 miliardi (a $1000/ETH e 14M di ETH messi in staking). L'utente malevolo, inoltre, viene espulso dalla rete quando è frazionato e dovrà aggiungersi alla coda d'attivazione per unirsi nuovamente. Ciò significa che la frequenza di un attacco ripetuto è limitata non solo dalla velocità con cui l'utente malintenzionato può accumulare >33% dello stake totale, ma anche dal tempo necessario per integrare tutti i suoi validatori nella rete. Ogni volta che l'utente malevolo attacca diventa molto più povero e il resto della comunità si arricchisce grazie allo shock di approvvigionamento risultante.
Altri attacchi, come gli attacchi al 51% o l'inversione di finalità con il 66% dello stake totale, richiedono sostanzialmente più ETH e sono molto più costosi per l'utente malevolo.
-Confrontalo con il proof-of-work. Il costo di lanciare un attacco al proof-of-work di Ethereum era il costo di possedere costantemente il >50% del tasso di hash di rete totale. Ciò corrispondeva ai costi del hardware e di gestione della potenza di calcolo sufficiente per superare la concorrenza degli altri miner e calcolare coerentemente le soluzioni di proof-of-work. Ethereum era per lo più minato utilizzando le GPU piuttosto che l'ASIC, il che ha mantenuto i costi bassi (tuttavia, se Ethereum fosse rimasto sul proof-of-work, il mining con ASIC sarebbe potuto divenire più popolare). Un concorrente avrebbe dovuto acquistare molto hardware e pagare per l'elettricità per eseguirlo per attaccare una rete di Ethereum in proof-of-work, ma il costo totale sarebbe stato inferiore a quello richiesto per accumulare abbastanza ETH e attaccare Ethereum. Un attacco del 51% è circa [20 volte meno](https://youtu.be/1m12zgJ42dI?t=1562) costoso sul proof-of-work che sul proof-of-stake. Se l'attacco è stato rilevato e la catena è stata biforcata duramente per rimuovere le modifiche, l'utente malevolo potrebbe utilizzare ripetutamente lo stesso hardware per attaccare la nuova biforcazione.
+Confrontalo con il proof-of-work. Il costo di lanciare un attacco su Ethereum proof-of-work era il costo di possedere costantemente >50% dell'hash rate totale della rete. Ciò corrispondeva ai costi del hardware e di gestione della potenza di calcolo sufficiente per superare la concorrenza degli altri miner e calcolare coerentemente le soluzioni di proof-of-work. Ethereum era per lo più minato utilizzando le GPU piuttosto che l'ASIC, il che ha mantenuto i costi bassi (tuttavia, se Ethereum fosse rimasto sul proof-of-work, il mining con ASIC sarebbe potuto divenire più popolare). Un concorrente avrebbe dovuto acquistare molto hardware e pagare per l'elettricità per eseguirlo per attaccare una rete di Ethereum in proof-of-work, ma il costo totale sarebbe stato inferiore a quello richiesto per accumulare abbastanza ETH e attaccare Ethereum. Un attacco del 51% è ~[20 volte meno](https://youtu.be/1m12zgJ42dI?t=1562) costoso su proof-of-work che su proof-of-stake. Se l'attacco è stato rilevato e la catena è stata biforcata duramente per rimuovere le modifiche, l'utente malevolo potrebbe utilizzare ripetutamente lo stesso hardware per attaccare la nuova biforcazione.
### Complessità {#complexity}
@@ -32,11 +32,11 @@ Il proof-of-stake è molto più complesso del proof-of-work. Questo potrebbe ess
Per sviluppare e testare in sicurezza la logica di consenso del proof-of-stake, la Beacon Chain è stata lanciata due anni prima dell'implementazione del proof-of-stake sulla rete principale di Ethereum. La Beacon Chain ha agito da sandbox per il test del proof-of-stake, essendo una blockchain attiva che implementava la logica di consenso del proof-of-stake senza toccare le transazioni reali di Ethereum, in modo efficace, arrivando al consenso soltanto su se stessa. Una volta che questa è diventata stabile e priva di bug per un periodo sufficiente, la Beacon Chain è stata "fusa" con la rete principale di Ethereum. Tutto ciò ha contribuito a "domare" la complessità del proof-of-stake al punto che i rischi di conseguenze impreviste o bug del client sono stati ridotti al minimo.
-### Superficie d'attacco {#attack-surface}
+### Superficie di attacco {#attack-surface}
Il proof-of-stake è più complesso del proof-of-work, il che significa che esistono più vettori d'attacco potenziali da gestire. Invece di una rete tra pari che connette i client, ne esistono due, ognuna delle quali implementa un protocollo separato. Avere un validatore specifico e preselezionato per proporre un blocco in ogni spazio crea il potenziale per la negazione del servizio, laddove grandi quantità di traffico di rete portano tale validatore specifico ad andare offline.
-Esistono inoltre dei modi in cui gli utenti malevoli possono sincronizzare attentamente il rilascio dei propri blocchi o delle proprie attestazioni, così che siano ricevuti da una certa percentuale della rete onesta influenzandola a votare in certi modi. Infine, un utente malevolo potrebbe semplicemente accumulare abbastanza ETH da mettere in staking, dominando il meccanismo di consenso. Ognuno di questi [vettori d'attacco ha delle difese associate](/developers/docs/consensus-mechanisms/pos/attack-and-defense), ma non esistono per la difesa sotto il proof-of-work.
+Esistono inoltre dei modi in cui gli utenti malevoli possono sincronizzare attentamente il rilascio dei propri blocchi o delle proprie attestazioni, così che siano ricevuti da una certa percentuale della rete onesta influenzandola a votare in certi modi. Infine, un utente malevolo potrebbe semplicemente accumulare abbastanza ETH da mettere in staking, dominando il meccanismo di consenso. Ciascuno di questi [vettori d'attacco ha le proprie difese associate](/developers/docs/consensus-mechanisms/pos/attack-and-defense), ma non esistono da difendere sotto proof-of-work.
## Decentralizzazione {#decentralization}
@@ -50,7 +50,7 @@ La migliore opzione per Ethereum è che i validatori siano operati localmente su
Il proof-of-stake è un metodo a basso costo carbonico per proteggere la blockchain. Sotto il proof-of-work, i miner competono per il diritto di minare un blocco. I miner hanno più successo quando possono eseguire i calcoli più velocemente, incentivando l'investimento in hardware e il consumo energetico. Ciò è stato osservato per Ethereum prima che passasse al proof-of-stake. Poco dopo la transizione al proof-of-stake, Ethereum consumava approssimativamente 78 TWh/anno; tanto quanto un piccolo paese. Tuttavia, il passaggio al proof-of-stake ha ridotto il consumo energetico di circa il 99,98%. Il proof-of-stake ha reso Ethereum una piattaforma a basso tenore carbonico, nonché efficiente a livello energetico.
-[Di più sul consumo energetico di Ethereum](/energy-consumption)
+[Maggiori informazioni sul consumo energetico di Ethereum](/energy-consumption)
## Emissione {#issuance}
@@ -64,6 +64,6 @@ Guarda Justin Drake spiegare i benefici del proof-of-stake rispetto al proof-of-
## Letture consigliate {#further-reading}
-- [Filosofia di design del proof-of-stake di Vitalik](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
-- [FAQ sul proof-of-stake di Vitalik](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
-- [Video di "Spiegazione semplice" su PoS e PoW a confronto](https://www.youtube.com/watch?v=M3EFi_POhps)
+- [La filosofia di progettazione della proof-of-stake di Vitalik](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51)
+- [Le FAQ sulla proof-of-stake di Vitalik](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake)
+- [Video "Simply Explained" su PoS e PoW](https://www.youtube.com/watch?v=M3EFi_POhps)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md
index f4bac577534..2090f018168 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md
@@ -1,10 +1,10 @@
---
title: Ricompense e sanzioni del proof-of-stake
-description: Scopri di più sugli incentivi del protocollo nel proof-of-stake di Ethereum.
+description: "Scopri di più sugli incentivi del protocollo nel proof-of-stake di Ethereum."
lang: it
---
-Ethereum è protetta utilizzando la sua criptovaluta nativa, ether (ETH). Gli operatori del nodo che desiderano partecipare alla convalida dei blocchi e all'identificazione della testa della catena, depositano dell'ether nel [contratto di deposito](/staking/deposit-contract/) su Ethereum. Quindi sono pagati in ether per eseguire il software del validatore, che verifica la validità dei nuovi blocchi ricevuti tramite la rete peer-to-peer e applica l'algoritmo di scelta della diramazione per identificare la testa della catena.
+Ethereum è protetta utilizzando la sua criptovaluta nativa, ether (ETH). Gli operatori dei nodi che desiderano partecipare alla convalida dei blocchi e all'identificazione della testa della catena, depositano ether nel [contratto di deposito](/staking/deposit-contract/) su Ethereum. Quindi sono pagati in ether per eseguire il software del validatore, che verifica la validità dei nuovi blocchi ricevuti tramite la rete peer-to-peer e applica l'algoritmo di scelta della diramazione per identificare la testa della catena.
Esistono due ruoli principali per un validatore: 1) controllare i nuovi blocchi e "attestarne" la validità, 2) proporre nuovi blocchi quando selezionati casualmente dal gruppo totale di validatori. Se il validatore non riesce a svolgere una di queste mansioni quando richiesto, perde un pagamento di ether. Talvolta, inoltre, i validatori sono incaricati di aggregare le firme e partecipare alle commissioni di sincronizzazione.
@@ -18,7 +18,7 @@ Continua a leggere per ulteriori dettagli...
### Ricompense {#rewards}
-I validatori ricevono ricompense quando effettuano voti coerenti con la maggioranza degli altri validatori, quando propongono blocchi e quando partecipano alle commissioni di sincronizzazione. Il valore delle ricompense in ogni epoca è calcolato a partire da una `base_reward` (ricompensa di base). Questa unità fornisce le basi per il calcolo delle ricompense. La`base_reward` rappresenta la ricompensa media ricevuta da un validatore in condizioni ottimali per ogni epoca. Questa è calcolata in base al saldo effettivo del validatore e al numero totale di validatori attivi, come segue:
+I validatori ricevono ricompense quando effettuano voti coerenti con la maggioranza degli altri validatori, quando propongono blocchi e quando partecipano alle commissioni di sincronizzazione. Il valore delle ricompense in ogni epoca è calcolato da una `base_reward`. Questa unità fornisce le basi per il calcolo delle ricompense. La `base_reward` rappresenta la ricompensa media ricevuta da un validatore in condizioni ottimali per ogni epoca. Questa è calcolata in base al saldo effettivo del validatore e al numero totale di validatori attivi, come segue:
```
base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance))))
@@ -26,43 +26,43 @@ base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch
dove `base_reward_factor` è 64, `base_rewards_per_epoch` è 4 e `sum(active balance)` è l'ether totale in staking tra tutti i validatori attivi.
-Ciò significa che la ricompensa di base è proporzionale al saldo effettivo del validatore ed è inversamente proporzionale al numero di validatori sulla rete. Più validatori ci sono, maggiore sarà l'emissione complessiva (poiché `sqrt(N)`), ma minore sarà la `base_reward` per validatore (come `1/sqrt(N)`). Questi fattori influenzano l'APR per un nodo di staking. Leggi la logica alla base nelle [note di Vitalik](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards).
+Ciò significa che la ricompensa di base è proporzionale al saldo effettivo del validatore ed è inversamente proporzionale al numero di validatori sulla rete. Più validatori ci sono, maggiore è l'emissione complessiva (come `sqrt(N)`) ma minore è la `base_reward` per validatore (come `1/sqrt(N)`). Questi fattori influenzano l'APR per un nodo di staking. Leggi la motivazione alla base di ciò nelle [note di Vitalik](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards).
La ricompensa totale è quindi calcolata come la somma di cinque componenti, ognuno avente un peso che determina quanto ogni componente aggiunge alla ricompensa totale. I componenti sono:
```
-1. voto sull'origine: il validatore ha effettuato un voto tempestivo per il punto di controllo di origine corretto
-2. voto sulla destinazione: il validatore ha effettuato un voto tempestivo per il punto di controllo di destinazione corretto
-3. voto sulla testa: il validatore ha effettuato un voto tempestivo per il blocco di testa corretto
-4. ricompensa della commissione di sincronizzazione: il validatore ha partecipato a una commissione di sincronizzazione
+1. voto di origine: il validatore ha effettuato un voto tempestivo per il checkpoint di origine corretto
+2. voto di destinazione: il validatore ha effettuato un voto tempestivo per il checkpoint di destinazione corretto
+3. voto di testa: il validatore ha effettuato un voto tempestivo per il blocco di testa corretto
+4. ricompensa del comitato di sincronizzazione: il validatore ha partecipato a un comitato di sincronizzazione
5. ricompensa del propositore: il validatore ha proposto un blocco nello slot corretto
```
Le ponderazioni per ciascun componente sono le seguenti:
```
-TIMELY_SOURCE_WEIGHT uint64(14)
-TIMELY_TARGET_WEIGHT uint64(26)
-TIMELY_HEAD_WEIGHT uint64(14)
-SYNC_REWARD_WEIGHT uint64(2)
-PROPOSER_WEIGHT uint64(8)
+TIMELY_SOURCE_WEIGHT uint64(14)
+TIMELY_TARGET_WEIGHT uint64(26)
+TIMELY_HEAD_WEIGHT uint64(14)
+SYNC_REWARD_WEIGHT uint64(2)
+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`.
+Questi pesi ammontano a 64. La ricompensa è calcolata come la somma dei pesi applicabili, divisa per 64. Un validatore che ha effettuato tempestivi voti di origine, di destinazione e di testa, ha proposto un blocco e ha partecipato a un comitato 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 né propositori di blocchi né in un comitato 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 di blocco e l'attestazione. Ad esempio, se l'attestazione viene inviata entro uno slot dalla 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`.
+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 uno slashing sarà ricompensato con `slashed_validators_effective_balance / 512`.
### Sanzioni {#penalties}
Finora abbiamo considerato validatori che si comportano in modo impeccabile, ma quali sono le sanzioni per i validatori che non effettuano tempestivi voti sull'origine, sulla destinazione e sulla testa o lo fanno lentamente?
-Le sanzioni per la mancanza di voti sull'origine e sulla destinazione equivalgono alle ricompense che l'attestatore avrebbe ricevuto se li avesse inviati. Ciò significa che, invece di aggiungere la ricompensa al loro saldo, si vedono rimuovere un valore equivalente dal proprio saldo. Non è presente alcuna sanzione per il mancato voto sulla testa (ossia, i voti di testa sono solo ricompensati, mai sanzionati). Non esiste alcuna sanzione associata all'`inclusion_delay`; la ricompensa, semplicemente, non sarà aggiunta al saldo del validatore. Inoltre, non esiste alcuna sanzione per la mancata proposizione di un blocco.
+Le sanzioni per la mancanza di voti sull'origine e sulla destinazione equivalgono alle ricompense che l'attestatore avrebbe ricevuto se li avesse inviati. Ciò significa che, invece di aggiungere la ricompensa al loro saldo, si vedono rimuovere un valore equivalente dal proprio saldo. Non è prevista alcuna sanzione per il mancato voto di testa (ossia, i voti di testa sono solo ricompensati, mai sanzionati). Non esiste alcuna sanzione associata all'`inclusion_delay`: la ricompensa, semplicemente, non sarà aggiunta al saldo del validatore. Inoltre, non esiste alcuna sanzione per la mancata proposizione di un blocco.
-Leggi di più sulle ricompense e le sanzioni nelle [specifiche del consenso](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Ricompense e sanzioni sono state adeguate nell'aggiornamento di Bellatrix; guarda Danny Ryan e Vitalik discuterne in questo [Video Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ).
+Leggi di più su ricompense e sanzioni nelle [specifiche del consenso](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Ricompense e sanzioni sono state modificate nell'aggiornamento Bellatrix: guarda Danny Ryan e Vitalik discuterne in questo [video di Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ).
-## Taglio {#slashing}
+## Slashing {#slashing}
Il taglio è un'azione più grave che risulta nella rimozione forzata di un validatore dalla rete e nella perdita associata del suo ether in staking. Esistono tre modi in cui un validatore può essere tagliato, tutti equivalenti alla proposta o attestazione disonesta dei blocchi:
@@ -70,20 +70,21 @@ Il taglio è un'azione più grave che risulta nella rimozione forzata di un vali
- Attestando un blocco che ne "circonda" un altro (modificando di fatto lo storico)
- Eseguendo un "doppio voto", attestando due candidati per lo stesso blocco
-Se queste azioni sono rilevate, il validatore viene tagliato. Ciò significa che 1/32 del suo ether in staking (fino a un massimo di 1 ether) viene immediatamente bruciato, poi inizia un periodo di rimozione di 36 giorni. Durante tale periodo di rimozione, lo stake del validatore si riduce gradualmente. Al punto intermedio (Giorno 18), è applicata una sanzione aggiuntiva la cui portata scala con il totale di ether in staking di tutti i validatori tagliati nei 36 giorni precedenti all'evento di taglio. Ciò significa che più validatori sono tagliati, maggiore è l'entità del taglio. Il taglio massimo è il saldo effettivo di tutti i validatori tagliati (cioè, se molti validatori sono tagliati, potrebbero perdere il proprio intero stake). D'altra parte, un evento di taglio singolo e isolato brucia soltanto una piccola porzione dello stake del validatore. Questa sanzione intermedia che scala con il numero di validatori tagliati è detta "sanzione di correlazione".
+Se queste azioni sono rilevate, il validatore viene tagliato. Questo significa che 0,0078125 viene immediatamente bruciato per un validatore da 32 ETH (scalato linearmente con il saldo attivo), dopodiché inizia un periodo di rimozione di 36 giorni. Durante tale periodo di rimozione, lo stake del validatore si riduce gradualmente. Al punto intermedio (Giorno 18), è applicata una sanzione aggiuntiva la cui portata scala con il totale di ether in staking di tutti i validatori tagliati nei 36 giorni precedenti all'evento di taglio. Ciò significa che più validatori sono tagliati, maggiore è l'entità del taglio. Lo slashing massimo è il saldo effettivo completo di tutti i validatori soggetti a slashing (ossia, se molti validatori subiscono uno slashing, potrebbero perdere il loro intero stake). D'altra parte, un evento di taglio singolo e isolato brucia soltanto una piccola porzione dello stake del validatore. Questa sanzione intermedia che scala con il numero di validatori tagliati è detta "sanzione di correlazione".
## Perdita per inattività {#inactivity-leak}
-Se il livello del consenso ha superato più di quattro epoche senza finalizzare, un protocollo di emergenza detto "perdita di inattività" viene attivato. Lo scopo ultimo della perdita per inattività è creare le condizioni necessarie perché la catena recuperi la finalità. Come spiegato sopra, la finalità richiede una maggioranza dei 2/3 dell'ether in staking totale per accordarsi sui punti di controllo di origine e di destinazione. Se validatori che rappresentano oltre 1/3 dei validatori totali vanno offline o non riescono a inviare le attestazioni corrette, non è possibile che una supermaggioranza dei 2/3 finalizzi i punti di controllo. La perdita per inattività consente allo stake appartenente ai validatori inattivi di disperdersi gradualmente finché non controllano meno di 1/3 dello stake totale, consentendo ai validatori attivi rimanenti di finalizzare la catena. Indipendentemente da quanto sia grande il gruppo di validatori inattivi, i rimanenti validatori attivi alla fine controlleranno più di 2/3 dello stake. La perdita di stake è un forte incentivo per i validatori inattivi a riattivarsi appena possibile! Uno scenario di perdita per inattività è stato riscontrato sulla rete di prova Medalla quando \<66% di validatori attivi è riuscito ad arrivare al consenso sulla testa corrente della blockchain. La perdita per inattività è stata attivata e la finalità è stata infine recuperata!
+Se il livello del consenso ha superato più di quattro epoche senza finalizzare, un protocollo di emergenza detto "perdita di inattività" viene attivato. Lo scopo ultimo della perdita per inattività è creare le condizioni necessarie perché la catena recuperi la finalità. Come spiegato sopra, la finalità richiede una maggioranza dei 2/3 dell'ether in staking totale per accordarsi sui punti di controllo di origine e di destinazione. Se validatori che rappresentano oltre 1/3 dei validatori totali vanno offline o non riescono a inviare le attestazioni corrette, non è possibile che una supermaggioranza dei 2/3 finalizzi i punti di controllo. La perdita per inattività consente allo stake appartenente ai validatori inattivi di disperdersi gradualmente finché non controllano meno di 1/3 dello stake totale, consentendo ai validatori attivi rimanenti di finalizzare la catena. Indipendentemente da quanto sia grande il gruppo di validatori inattivi, i rimanenti validatori attivi alla fine controlleranno più di 2/3 dello stake. La perdita di stake è un forte incentivo per i validatori inattivi a riattivarsi appena possibile! Uno scenario di perdita per inattività è stato riscontrato sulla rete di prova Medalla quando <66% di validatori attivi è riuscito ad arrivare al consenso sulla testa corrente della blockchain. La perdita per inattività è stata attivata e la finalità è stata infine recuperata!
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)
-- [Specifiche annotate di Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1)
-- [Suggerimenti di prevenzione del taglio di Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50)
+- [Aggiornare Ethereum: Il livello di incentivi](https://eth2book.info/altair/part2/incentives)
+- [Incentivi nel protocollo Casper ibrido di Ethereum](https://arxiv.org/pdf/1903.04205.pdf)
+- [Le specifiche commentate di Vitalik](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1)
+- [Consigli per la prevenzione dello slashing su Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50)
+- [Analisi delle sanzioni per slashing secondo l'EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509)
_Fonti_
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md
index 4c1b5628951..042e9d3a320 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md
@@ -1,6 +1,6 @@
---
-title: Soggettività debole
-description: Una spiegazione della soggettività debole e del suo ruolo nell'Ethereum PoS.
+title: "Soggettività debole"
+description: "Una spiegazione della soggettività debole e del suo ruolo nell'Ethereum PoS."
lang: it
---
@@ -30,10 +30,10 @@ Un punto di controllo della soggettività debole potrebbe persino essere inserit
Infine, i punti di controllo possono essere richiesti da altri nodi; ad es. un altro utente di Ethereum che esegue un nodo completo può fornire un punto di controllo che i validatori possono poi verificare rispetto ai dati ricevuti da un esploratore del blocco. In generale, fidarsi del fornitore di un punto di controllo della soggettività debole può essere considerato come problematico tanto quanto fidarsi degli sviluppatori del client. La fiducia generale richiesta è bassa. È importante osservare che queste considerazioni diventano importanti solo nell'improbabile evento che una maggioranza di validatori cospiri per generare una biforcazione alternativa della blockchain. In qualsiasi altra circostanza, esiste solo una catena di Ethereum da cui scegliere.
-## Letture consigliate {#further-reading}
+## Ulteriori letture {#further-reading}
- [Soggettività debole in Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2)
-- [Vitalik: come ho imparato ad amare la soggettività debole](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)
-- [Soggettività debole (documentazione di Teku)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/)
-- [Fase 0 della guida alla soggettività debole](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md)
+- [Vitalik: Come ho imparato ad amare la soggettività debole](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)
+- [Soggettività debole (documentazione Teku)](https://docs.teku.consensys.io/concepts/weak-subjectivity)
+- [Guida alla soggettività debole della Fase 0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md)
- [Analisi della soggettività debole in Ethereum 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md
new file mode 100644
index 00000000000..6a3d94f8f08
--- /dev/null
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md
@@ -0,0 +1,64 @@
+---
+title: Credenziali di prelievo
+description: Una spiegazione dei tipi di credenziali di prelievo del validatore (0x00, 0x01, 0x02) e le loro implicazioni per gli staker di Ethereum.
+lang: it
+---
+
+Ogni validatore ha una **credenziale di prelievo** che determina come e dove i suoi ETH in staking e le ricompense possono essere prelevati. Il tipo di credenziale è indicato dal primo byte: `0x00`, `0x01` o `0x02`. Comprendere questi tipi è importante per i validatori che gestiscono il proprio stake.
+
+## 0x00: Credenziali Pre-Shapella {#0x00-credentials}
+
+Il tipo `0x00` è il formato originale delle credenziali di prelievo precedente all'aggiornamento Shapella (aprile 2023). I validatori con questo tipo di credenziali non hanno un indirizzo di prelievo impostato sul livello di esecuzione, il che significa che i loro fondi rimangono bloccati sul livello di consenso. Se si dispone ancora di credenziali `0x00`, è necessario eseguire l'aggiornamento a `0x01` o `0x02` prima di poter ricevere prelievi.
+
+## 0x01: Credenziali di prelievo legacy {#0x01-credentials}
+
+Il tipo `0x01` è stato introdotto con l'aggiornamento Shapella ed è diventato lo standard per i validatori che volevano impostare un indirizzo di prelievo sul livello di esecuzione. Con le credenziali `0x01`:
+
+- Qualsiasi saldo superiore a 32 ETH viene **automaticamente trasferito** al proprio indirizzo di prelievo
+- Le uscite complete passano attraverso la coda di uscita standard
+- Le ricompense superiori a 32 ETH non possono essere composte; vengono trasferite periodicamente
+
+**Perché alcuni validatori usano ancora 0x01:** è più semplice e familiare. Molti validatori hanno depositato dopo Shapella e hanno già questo tipo, e funziona bene per coloro che desiderano prelievi automatici del saldo in eccesso.
+
+**Perché non è consigliato:** con `0x01`, si perde la possibilità di comporre le ricompense superiori a 32 ETH. Ogni importo in eccesso viene trasferito automaticamente, il che limita il potenziale di guadagno del proprio validatore e richiede la gestione separata dei fondi prelevati.
+
+## 0x02: Credenziali di prelievo a composizione {#0x02-credentials}
+
+Il tipo `0x02` è stato introdotto con l'aggiornamento Pectra ed è la **scelta consigliata** per i validatori oggi. I validatori con credenziali `0x02` sono talvolta chiamati "validatori a composizione".
+
+Con le credenziali `0x02`:
+
+- Le ricompense superiori a 32 ETH **si compongono** con incrementi di 1 ETH fino a un saldo effettivo massimo di 2048 ETH
+- I prelievi parziali devono essere richiesti manualmente (i trasferimenti automatici si verificano solo al di sopra della soglia di 2048 ETH)
+- I validatori possono consolidare più validatori da 32 ETH in un unico validatore con un saldo maggiore
+- Le uscite complete sono ancora supportate attraverso la coda di uscita standard
+
+Sia i prelievi parziali che i consolidamenti possono essere eseguiti tramite le [Azioni del Validatore del Launchpad](https://launchpad.ethereum.org/en/validator-actions).
+
+**Perché i validatori dovrebbero preferire 0x02:** offre una migliore efficienza del capitale attraverso la composizione, un maggiore controllo su quando avvengono i prelievi e supporta il consolidamento dei validatori. Per gli staker individuali che accumulano ricompense nel tempo, ciò significa che il loro saldo effettivo, e quindi le loro ricompense, può crescere oltre i 32 ETH senza intervento manuale.
+
+**Importante:** una volta effettuata la conversione da `0x01` a `0x02`, non è possibile tornare indietro.
+
+Per una guida dettagliata sulla conversione alle credenziali di tipo 2 e sulla funzionalità MaxEB, vedere la [pagina esplicativa su MaxEB](/roadmap/pectra/maxeb/).
+
+## Cosa dovrei scegliere? {#what-should-i-pick}
+
+- **Nuovi validatori:** scegliere `0x02`. È lo standard moderno con una migliore composizione e flessibilità.
+- **Validatori 0x01 esistenti:** valutare la conversione a `0x02` se si desidera che le ricompense si compongano al di sopra di 32 ETH o si prevede di consolidare i validatori.
+- **Validatori 0x00 esistenti:** eseguire immediatamente l'aggiornamento; non è possibile prelevare senza aggiornare le proprie credenziali. È necessario prima convertire a `0x01`, poi è possibile convertire a `0x02`.
+
+## Strumenti per la gestione delle credenziali di prelievo {#withdrawal-credential-tools}
+
+Diversi strumenti supportano la scelta o la conversione tra i tipi di credenziali:
+
+- **[Launchpad per lo Staking di Ethereum](https://launchpad.ethereum.org/en/validator-actions)** - Lo strumento ufficiale per i depositi e la gestione dei validatori, incluse le conversioni di credenziali e i consolidamenti
+- **[Pectra Staking Manager](https://pectrastaking.com)** - Interfaccia utente web con supporto wallet-connect per conversioni e consolidamento
+- **[Pectra Validator Ops CLI Tool](https://github.com/Luganodes/Pectra-Batch-Contract)** - Strumento a riga di comando per conversioni in batch
+- **[Ethereal](https://github.com/wealdtech/ethereal)** - Strumento CLI per le operazioni di Ethereum, inclusa la gestione dei validatori
+
+Per un elenco completo degli strumenti di consolidamento e istruzioni dettagliate per la conversione, vedere [strumenti di consolidamento MaxEB](/roadmap/pectra/maxeb/#consolidation-tooling).
+
+## Letture consigliate {#further-reading}
+
+- [Chiavi in Ethereum proof-of-stake](/developers/docs/consensus-mechanisms/pos/keys/) - Informazioni sulle chiavi del validatore e sulla loro relazione con le credenziali di prelievo
+- [MaxEB](/roadmap/pectra/maxeb/) - Guida dettagliata sull'aggiornamento Pectra e sulla funzionalità del saldo effettivo massimo
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/index.md
index 9b427930fa1..fb30cd7b3dc 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/index.md
@@ -4,28 +4,28 @@ description: Spiegazione del consenso con il protocollo Proof of Work e il suo r
lang: it
---
-La rete Ethereum venne avviata usando un meccanismo di consenso che utilizzava il **[Proof of Work (PoW)](/developers/docs/consensus-mechanisms/pow)** che consentiva ai nodi della rete Ethereum di concordare sullo stato di tutte le informazioni registrate sulla blockchain Ethereum e impediva alcuni tipi di attacchi economici. Tuttavia, Ethereum ha disattivato il Proof of Work nel 2022 e ha iniziato, invece, a usare il [Proof of Stake](/developers/docs/consensus-mechanisms/pos).
+La rete Ethereum ha iniziato utilizzando un meccanismo di consenso che prevedeva la **[Proof-of-work (PoW)](/developers/docs/consensus-mechanisms/pow)**. che consentiva ai nodi della rete Ethereum di concordare sullo stato di tutte le informazioni registrate sulla blockchain Ethereum e impediva alcuni tipi di attacchi economici. Tuttavia, Ethereum ha disattivato la proof-of-work nel 2022 e ha iniziato, invece, a usare la [proof-of-stake](/developers/docs/consensus-mechanisms/pos).
- Il Proof of Work è diventato ormai obsoleto. Ethereum non usa più il Proof of Work come parte del suo meccanismo di consenso, e usa invece il Proof of Stake. Leggi di più sul [Proof of Stake](/developers/docs/consensus-mechanisms/pos/) e sullo [staking](/staking/).
+ Il Proof of Work è diventato ormai obsoleto. Ethereum non usa più il Proof of Work come parte del suo meccanismo di consenso, e usa invece il Proof of Stake. Leggi di più su [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e [staking](/staking/).
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, consigliamo innanzi tutto di leggere il materiale relativo alle [transazioni](/developers/docs/transactions/), [ai blocchi](/developers/docs/blocks/), e [ai meccanismi di consenso](/developers/docs/consensus-mechanisms/).
+Per comprendere meglio questa pagina, ti suggeriamo di leggere prima qualcosa sulle [transazioni](/developers/docs/transactions/), sui [blocchi](/developers/docs/blocks/), e i [meccanismi di consenso](/developers/docs/consensus-mechanisms/).
## Cos'è la Proof of Work (PoW)? {#what-is-pow}
-Il consenso di Nakamoto, che utilizza il proof-of-work, è il meccanismo che un tempo consentiva alla rete decentralizzata di Ethereum di raggiungere il consenso (ossia, l'accordo di tutti i nodi) su aspetti come i saldi dei conti e l'ordine delle transazioni. Questo impediva che gli utenti spendessero due volte le loro monete e assicurava che la catena Ethereum fosse estremamente difficile da attaccare o manipolare. Ora, invece, queste proprietà di sicurezza provengono dal proof-of-stake, usando il meccanismo di consenso noto come [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/).
+Il consenso di Nakamoto, che utilizza la proof-of-work, è il meccanismo che un tempo consentiva alla rete decentralizzata di Ethereum di raggiungere il consenso (ossia, l'accordo di tutti i nodi) su aspetti come i saldi dei conti e l'ordine delle transazioni. Questo impediva che gli utenti spendessero due volte le loro monete e assicurava che la catena Ethereum fosse estremamente difficile da attaccare o manipolare. Ora, invece, queste proprietà di sicurezza provengono dalla proof-of-stake, usando il meccanismo di consenso noto come [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/).
-## Proof of Work e mining {#pow-and-mining}
+## Proof-of-work e mining {#pow-and-mining}
-Il Proof of Work è l'algoritmo sottostante che imposta la difficoltà e le regole per il lavoro che i miner devono svolgere su blockchain di Proof of Work. Il mining è il "lavoro" da svolgere. Si tratta dell'atto di aggiungere blocchi validi alla catena. Questo è importante perché la lunghezza della catena aiuta le rete a seguire la corretta diramazione della blockchain. Più "lavoro" viene svolto, più è lunga la catena e maggiore è il numero di blocchi, e più la rete può essere certa dello stato attuale delle cose.
+Il Proof of Work è l'algoritmo sottostante che imposta la difficoltà e le regole per il lavoro che i miner devono svolgere su blockchain di Proof of Work. Il mining è il "lavoro" stesso. Si tratta dell'atto di aggiungere blocchi validi alla catena. Questo è importante perché la lunghezza della catena aiuta le rete a seguire la corretta diramazione della blockchain. Più "lavoro" viene svolto, più è lunga la catena e maggiore è il numero di blocchi, e più la rete può essere certa dello stato attuale delle cose.
[Maggiori informazioni sul mining](/developers/docs/consensus-mechanisms/pow/mining/)
@@ -34,12 +34,12 @@ Il Proof of Work è l'algoritmo sottostante che imposta la difficoltà e le rego
Le transazioni di Ethereum vengono elaborate in blocchi. Nell'Ethereum Proof of Work ora obsoleto, ogni blocco conteneva:
- difficoltà del blocco, ad esempio: 3.324.092.183.262.715
-- un mixHash, ad esempio: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
-- nonce, ad esempio: `0xd3ee432b4fb3d26b`
+- mixHash – ad esempio: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
+- nonce – ad esempio: `0xd3ee432b4fb3d26b`
Questi dati del blocco erano correlati direttamente alla al Proof of Work
-### Il lavoro nel Proof of Work {#the-work}
+### Il lavoro nella proof-of-work {#the-work}
Il protocollo di Proof of Work, detto Ethash, richiedeva che i miner competessero tramite processi di tentativo ed errore per trovare il nonce di un blocco. Solo i blocchi con un nonce valido potevano essere aggiunti alla catena.
@@ -47,9 +47,9 @@ Quando competeva per creare un blocco, un miner inseriva ripetutamente un set di
La difficoltà determinava il target per l'hash. Più basso era il target, più piccolo era il set di hash validi. Una volta generato, era incredibilmente facile per gli altri miner e client verificarne la bontà. Anche se una transazione fosse cambiata, l'hash sarebbe stato completamente diverso, segnalando una potenziale frode.
-L'hashing rende le frodi facili da individuare. Ma il processo del Proof of Work era anche un grande deterrente contro gli attacchi alla catena.
+L'hashing permette di individuare le frodi con facilità. Ma il processo del Proof of Work era anche un grande deterrente contro gli attacchi alla catena.
-### Proof of Work e sicurezza {#security}
+### Proof-of-work e sicurezza {#security}
I miner erano incentivati a fare questo lavoro sulla catena principale di Ethereum. L'incentivo a iniziare una catena propria era molto ridotto per i miner, perché avrebbe compromesso il sistema. Le blockchain fanno affidamento sul fatto di avere un solo stato di riferimento, che è considerato l'unica fonte di verità.
@@ -57,11 +57,11 @@ L'obiettivo del Proof of Work era di estendere la catena. La catena più lunga e
Per creare costantemente blocchi malevoli ma validi, un miner malevolo avrebbe dovuto avere più del 51% della potenza di mining della rete, per poter battere tutti gli altri. Tale quantità di "lavoro" richiede un grande quantità di costosa potenza di calcolo e l'energia consumata avrebbe potuto persino superare i guadagni derivanti dall'attacco.
-### L'economia della Proof of Work {#economics}
+### Economia della proof-of-work {#economics}
Il Proof of Work era anche responsabile del rilascio di nuova valuta nel sistema e dell'incentivazione dei miner a fare il proprio lavoro.
-Dall'[aggiornamento di Costantinopoli](/ethereum-forks/#constantinople), i miner che creavano correttamente un blocco erano ricompensati con due ETH appena coniati e parte delle commissioni di transazione. Anche i blocchi ommer erano ricompensati con 1,75 ETH. I blocchi ommer erano blocchi validi, creati da un miner praticamente contestualmente alla creazione del blocco canonico da parte di un altro miner, determinati in ultima analisi dalla catena su cui la creazione era avvenuta prima. I blocchi ommer si verificavano in genere a causa della latenza della rete.
+Dall'[aggiornamento Constantinople](/ethereum-forks/#constantinople), i miner che creavano con successo un blocco venivano ricompensati con due ETH appena coniati e una parte delle commissioni di transazione. Anche i blocchi ommer erano ricompensati con 1,75 ETH. I blocchi ommer erano blocchi validi, creati da un miner praticamente contestualmente alla creazione del blocco canonico da parte di un altro miner, determinati in ultima analisi dalla catena su cui la creazione era avvenuta prima. I blocchi ommer si verificavano in genere a causa della latenza della rete.
## Finalità {#finality}
@@ -69,21 +69,21 @@ Una transazione ha una "finalità" su Ethereum quando fa parte di un blocco che
Dato che i miner lavoravano in modo decentralizzato, era possibile che avvenisse il mining di due blocchi validi nello stesso momento. In questo caso, si crea una diramazione temporanea. Alla fine veniva accettata una sola catena (quella più lunga), creata quando venivano eseguiti il mining e l'aggiunta di blocchi successivi.
-Per complicare ulteriormente le cose, le transazioni che erano state rifiutate sulla diramazione temporanea potevano non essere state aggiunte alla catena accettata. Questo significa che la catena poteva essere annullata. Quindi la finalità si riferisce al tempo per cui era necessario attendere prima di considerare una transazione irreversibile. Con il precedente Ethereum di Proof of Work, più blocchi erano minati su uno specifico blocco `N`, maggiore sarebbe stata la certezza che le transazioni in `N` riuscissero e non fossero annullate. Ora, con il Proof of Stake, la finalizzazione è una proprietà esplicita, piuttosto che probabilistica, di un blocco.
+Per complicare ulteriormente le cose, le transazioni che erano state rifiutate sulla diramazione temporanea potevano non essere state aggiunte alla catena accettata. Questo significa che la catena poteva essere annullata. Quindi la finalità si riferisce al tempo per cui era necessario attendere prima di considerare una transazione irreversibile. Nel precedente Ethereum basato su proof-of-work, più blocchi venivano minati sopra uno specifico blocco `N`, maggiore era la sicurezza che le transazioni in `N` fossero andate a buon fine e non sarebbero state annullate. Ora, con il Proof of Stake, la finalizzazione è una proprietà esplicita, piuttosto che probabilistica, di un blocco.
-## Consumo energetico del Proof of Work {#energy}
+## Consumo energetico della proof-of-work {#energy}
-Una delle principali critiche mosse al Proof of Work riguarda la quantità di energia necessaria per mantenere la rete sicura. Per mantenere la sicurezza e la decentralizzazione, Ethereum sul Proof of Work consumava elevate quantità di energia. Poco prima di passare al Proof of Stake, i miner di Ethereum consumavano collettivamente circa 70 TWh/anno (quasi quanto la Repubblica ceca, secondo [digiconomist](https://digiconomist.net/), il 18 luglio 2022).
+Una delle principali critiche mosse al Proof of Work riguarda la quantità di energia necessaria per mantenere la rete sicura. Per mantenere la sicurezza e la decentralizzazione, Ethereum sul Proof of Work consumava elevate quantità di energia. Poco prima del passaggio alla proof-of-stake, i miner di Ethereum consumavano collettivamente circa 70 TWh/anno (quasi quanto la Repubblica Ceca - secondo [digiconomist](https://digiconomist.net/) il 18 luglio 2022).
## Pro e contro {#pros-and-cons}
-| Pro | Contro |
-| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Il Proof of Work è neutrale. Non servono ETH per iniziare e le ricompense per i blocchi consentono di passare da 0 ETH a un saldo positivo. Con il [ Proof of Stake](/developers/docs/consensus-mechanisms/pos/) occorrono ETH per iniziare. | Il Proof of Work utilizza così tanta energia da risultare dannoso per l'ambiente. |
-| Il PoW è un meccanismo di consenso testato e ben collaudato che mantiene Bitcoin ed Ethereum sicure e decentralizzate da molti anni. | Chi desidera occuparsi di mining deve avere apparecchiature specializzate, con un conseguente notevole investimento iniziale. |
-| Rispetto alla Proof of Stake è relativamente facile da implementare. | A causa della crescente richiesta di potenza di calcolo, alcuni i gruppi di mining potrebbero potenzialmente dominare l'attività di mining, portando così alla centralizzazione e a rischi di sicurezza. |
+| Pro | Contro |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Il Proof of Work è neutrale. Non servono ETH per iniziare e le ricompense per i blocchi consentono di passare da 0 ETH a un saldo positivo. Con la [proof-of-stake](/developers/docs/consensus-mechanisms/pos/), per iniziare sono necessari degli ETH. | Il Proof of Work utilizza così tanta energia da risultare dannoso per l'ambiente. |
+| Il PoW è un meccanismo di consenso testato e ben collaudato che mantiene Bitcoin ed Ethereum sicure e decentralizzate da molti anni. | Chi desidera occuparsi di mining deve avere apparecchiature specializzate, con un conseguente notevole investimento iniziale. |
+| Rispetto alla Proof of Stake è relativamente facile da implementare. | A causa della crescente richiesta di potenza di calcolo, alcuni i gruppi di mining potrebbero potenzialmente dominare l'attività di mining, portando così alla centralizzazione e a rischi di sicurezza. |
-## Confronto con il Proof of Stake {#compared-to-pos}
+## Confronto con la proof-of-stake {#compared-to-pos}
Ad alto livello, il Proof of Stake ha lo stesso obiettivo del Proof of Work: permettere a una rete decentralizzata di raggiungere il consenso in totale sicurezza. Ma ci sono alcune differenze nei processi e nel personale:
@@ -92,16 +92,16 @@ Ad alto livello, il Proof of Stake ha lo stesso obiettivo del Proof of Work: per
- I validatori non competono per creare blocchi, sono invece scelti casualmente da un algoritmo.
- La finalità è più chiara: in alcuni checkpoint, se i 2/3 dei validatori concordano sullo stato del blocco, questo è considerato definitivo. I validatori devono scommettere il loro intero stake su questo, per cui se dovessero provare a cospirare in seguito, perderebbero il loro intero stake.
-[Maggiori informazioni sul Proof of Stake](/developers/docs/consensus-mechanisms/pos/)
+[Maggiori informazioni sulla proof-of-stake](/developers/docs/consensus-mechanisms/pos/)
## Preferisci un approccio visivo all'apprendimento? {#visual-learner}
-## Letture consigliate {#further-reading}
+## Ulteriori letture {#further-reading}
-- [Majority attack](https://en.bitcoin.it/wiki/Majority_attack)
-- [On settlement finality](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
+- [Attacco di maggioranza](https://en.bitcoin.it/wiki/Majority_attack)
+- [Sulla finalità del regolamento](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
### Video {#videos}
@@ -110,5 +110,5 @@ Ad alto livello, il Proof of Stake ha lo stesso obiettivo del Proof of Work: per
## Argomenti correlati {#related-topics}
- [Mining](/developers/docs/consensus-mechanisms/pow/mining/)
-- [Proof of Stake](/developers/docs/consensus-mechanisms/pos/)
-- [Proof of Authority](/developers/docs/consensus-mechanisms/poa/)
+- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/)
+- [Proof-of-authority](/developers/docs/consensus-mechanisms/poa/)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/index.md
index 4836bc6c326..004e14b0128 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/index.md
@@ -8,14 +8,14 @@ lang: it
-Il Proof of Work non è più il meccanismo di consenso alla base di Ethereum, il che significa che il mining è stato disattivato. Invece, Ethereum è protetto dai validatori che mettono ETH in staking. Puoi iniziare fin da subito a mettere in staking i tuoi ETH. Leggi di più su La Fusione, il proof-of-stake e lo staking. Questa pagina è solo per interesse storico.
+Il Proof of Work non è più il meccanismo di consenso alla base di Ethereum, il che significa che il mining è stato disattivato. Invece, Ethereum è protetto dai validatori che mettono ETH in staking. Puoi iniziare oggi a mettere i tuoi ETH in staking. Leggi di più su La Fusione, il proof-of-stake e lo staking. Questa pagina è solo per interesse storico.
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, consigliamo innanzi tutto di leggere [transazioni](/developers/docs/transactions/), [blocchi](/developers/docs/blocks/) e [Proof of Work](/developers/docs/consensus-mechanisms/pow/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima qualcosa su [transazioni](/developers/docs/transactions/), [blocchi](/developers/docs/blocks/) e [proof-of-work](/developers/docs/consensus-mechanisms/pow/).
## Cos'è il mining in Ethereum? {#what-is-ethereum-mining}
@@ -31,43 +31,43 @@ Il mining è la linfa vitale di qualsiasi blockchain basata sul Proof of Work. P
Nei sistemi decentralizzati come Ethereum, dobbiamo assicurarci che tutti concordino sull'ordine delle transazioni. In questo i miner aiutavano risolvendo complessi enigmi di calcolo con lo scopo di produrre blocchi, tenendo la rete al sicuro dagli attacchi.
-[Maggiori informazioni sul Proof of Work](/developers/docs/consensus-mechanisms/pow/)
+[Maggiori informazioni sul proof-of-work](/developers/docs/consensus-mechanisms/pow/)
In precedenza, chiunque poteva minare sulla rete Ethereum usando il proprio computer. Tuttavia, non tutti potevano estrarre ether (ETH) in modo redditizio. In gran parte dei casi, i miner dovevano acquistare hardware dedicato e avere accesso a fonti energetiche convenienti. Per il computer medio, era improbabile guadagnare abbastanza ricompense dei blocchi da coprire i costi associati al mining.
-### Costi del mining {#cost-of-mining}
+### Costo del mining {#cost-of-mining}
- I costi potenziali dell'hardware necessario per costruire e mantenere una piattaforma di mining
- I costi elettrici per alimentarla
- Se si effettuava il mining all'interno di un gruppo, questi gruppi di mining addebitavano generalmente una commissione forfettaria percentuale su ciascun blocco generato dal gruppo
- I costi potenziali delle attrezzature per supportare la piattaforma di mining (ventilazione, monitoraggio energetico, cablaggio, etc.)
-Per approfondire ulteriormente la redditività del mining, usa un apposito calcolatore, come quello messo a disposizione da [Etherscan](https://etherscan.io/ether-mining-calculator).
+Per approfondire ulteriormente la redditività del mining, usa un calcolatore di mining, come quello fornito da [Etherscan](https://etherscan.io/ether-mining-calculator).
-## Come avveniva il mining delle transazioni Ethereum {#how-ethereum-transactions-were-mined}
+## Come venivano minate le transazioni di Ethereum {#how-ethereum-transactions-were-mined}
-Quanto segue fornisce una panoramica di come erano minate le transazioni, nel proof-of-work di Ethereum. Una descrizione analoga di questo processo per il proof-of-stake di Ethereum, si può trovare [qui](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos).
+Quanto segue fornisce una panoramica di come erano minate le transazioni, nel proof-of-work di Ethereum. Una descrizione analoga di questo processo per il proof-of-stake di Ethereum è disponibile [qui](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos).
1. Un utente scrive e firma una richiesta di [transazione](/developers/docs/transactions/) con la chiave privata di un [conto](/developers/docs/accounts/).
-2. L'utente trasmette la richiesta di transazione all'intera rete Ethereum attraverso un [nodo](/developers/docs/nodes-and-clients/).
+2. L'utente trasmette la richiesta di transazione all'intera rete Ethereum da un [nodo](/developers/docs/nodes-and-clients/).
3. Dopo aver recepito la richiesta della nuova transazione, ogni nodo nella rete Ethereum aggiunge la richiesta alla propria mempool locale, un elenco di tutte le richieste di transazioni delle quali è venuto a conoscenza e che non sono ancora state inviate alla blockchain in un blocco.
-4. A un certo punto, un nodo di mining aggrega diverse dozzine o centinaia di richieste di transazione in un [blocco](/developers/docs/blocks/) potenziale, così da massimizzare le [commissioni di transazione](/developers/docs/gas/) che saranno guadagnate, entro il limite di gas del blocco. A questo punto, il nodo di mining:
- 1. Verifica la validità di ogni richiesta di transazione (cioè, che nessuno stia provando a trasferire ether da un conto per cui non ha prodotto una firma, la richiesta non è malformata, etc.) e, poi, esegue il codice della richiesta, alterando lo stato della loro copia locale dell'EVM. Il miner assegna la commissione sulla transazione per ogni simile richiesta di transazione, al proprio conto.
+4. A un certo punto, un nodo di mining aggrega diverse dozzine o centinaia di richieste di transazione in un potenziale [blocco](/developers/docs/blocks/), in modo da massimizzare le [commissioni di transazione](/developers/docs/gas/) che guadagna, pur rimanendo sotto il limite di gas del blocco. A questo punto, il nodo di mining:
+ 1. Verifica la validità di ogni richiesta di transazione (cioè, che nessuno stia provando a trasferire ether da un conto per cui non ha prodotto una firma, la richiesta non è malformata, ecc.), e poi esegue il codice della richiesta, alterando lo stato della loro copia locale dell'EVM. Il miner assegna la commissione sulla transazione per ogni simile richiesta di transazione, al proprio conto.
2. Inizia il processo di produzione del "certificato di legittimità" Proof of Work per il blocco potenziale, una volta che tutte le richieste di transazione nel blocco sono state verificate ed eseguite nella copia dell'EVM locale.
5. Infine un miner concluderà la produzione di un certificato per un blocco che include la nostra richiesta di transazione specifica. Il miner trasmetterà quindi il blocco completato, che include il certificato e una checksum del nuovo stato dell'EVM dichiarato.
6. Gli altri nodi vengono a conoscenza del nuovo blocco. Verificano il certificato, eseguono tutte le transazioni sul blocco (includendo la transazione originalmente inviata dal nostro utente) e verificano che la checksum del nuovo stato dell'EVM dopo l'esecuzione di tutte le transazioni combaci quella dello stato dichiarato dal blocco del miner. Solo a questo punto allora questi nodi aggiungeranno il blocco alla coda della blockchain e accetteranno il nuovo stato dell'EVM come canonico.
7. Ogni nodo rimuove tutte le transazioni nel nuovo blocco dalla propria mempool locale di richieste di transazioni non eseguite.
8. I nuovi nodi che si aggiungono alla rete scaricano tutti i blocchi in sequenza, incluso il blocco che contiene la transazione della quale stiamo parlando. Inizializzano la propria copia locale dell'EVM (che partirà come EVM con stato vuoto) e si avvieranno al processo di esecuzione di ogni transazione contenuta in ogni blocco aggiungendola alla propria copia dell'EVM locale e verificando le checksum dello stato ad ogni blocco che esamineranno.
-Il mining di ogni transazione (cioè l'inclusione in un nuovo blocco e la prima propagazione) avviene una volta sola, ma la transazione viene eseguita e verificata da ogni partecipante nel processo di avanzamento dello stato canonico dell'EVM. Questa è una delle regole fondamentali della blockchain: **non ti fidare, verifica**.
+Il mining di ogni transazione (cioè l'inclusione in un nuovo blocco e la prima propagazione) avviene una volta sola, ma la transazione viene eseguita e verificata da ogni partecipante nel processo di avanzamento dello stato canonico dell'EVM. Questo evidenzia uno dei mantra centrali della blockchain: **Non fidarti, verifica**.
-## Blocchi ommer (zio) {#ommer-blocks}
+## Blocchi ommer (uncle) {#ommer-blocks}
-L'estrazione di blocchi basata sul proof-of-work era solo probabilistica, il che significa che a volte due blocchi validi venivano pubblicati simultaneamente a causa della latenza della rete. In questo caso, il protocollo doveva determinare la catena più lunga (e quindi più "valida") garantendo al tempo stesso un trattamento equo dei miner, ricompensando parzialmente il blocco valido proposto non incluso. Ciò incoraggiava l'ulteriore decentralizzazione della rete in quanto i piccoli miner, che potevano trovarsi ad affrontare una latenza più elevata, potevano comunque generare rendimenti tramite ricompense per blocchi [ommer](/glossary/#ommer).
+L'estrazione di blocchi basata sul proof-of-work era solo probabilistica, il che significa che a volte due blocchi validi venivano pubblicati simultaneamente a causa della latenza della rete. In questo caso, il protocollo doveva determinare la catena più lunga (e quindi più "valida") garantendo al tempo stesso un trattamento equo dei miner, ricompensando parzialmente il blocco valido proposto non incluso. Ciò incoraggiava un'ulteriore decentralizzazione della rete, poiché i miner più piccoli, che potevano riscontrare una maggiore latenza, potevano comunque generare rendimenti tramite le ricompense dei blocchi [ommer](/glossary/#ommer).
-"Ommer" è il termine preferito, neutro dal punto di vista del genere, per lo stesso livello di un blocco genitore, ma a volte viene anche indicato come "zio". **Da quando Ethereum è passato alla proof-of-stake, i blocchi ommer non vengono più estratti** poiché in ogni slot viene eletto solo un proponente. Questo cambiamento può essere osservato nel [grafico storico](https://ycharts.com/indicators/ethereum_uncle_rate) dei blocchi ommer estratti.
+"Ommer" è il termine preferito, neutro dal punto di vista del genere, per lo stesso livello di un blocco genitore, ma a volte viene anche indicato come "zio". **Da quando Ethereum è passato al proof-of-stake, i blocchi ommer non vengono più minati**, poiché in ogni slot viene eletto un solo proponente. Puoi vedere questo cambiamento visualizzando il [grafico storico](https://ycharts.com/indicators/ethereum_uncle_rate) dei blocchi ommer minati.
-## Demo visiva {#a-visual-demo}
+## Una demo visiva {#a-visual-demo}
Austin ti guiderà attraverso il mining e la blockchain basata sul proof-of-work.
@@ -75,7 +75,7 @@ Austin ti guiderà attraverso il mining e la blockchain basata sul proof-of-work
## L'algoritmo di mining {#mining-algorithm}
-La Rete principale di Ethereum ha sempre e solo usato un algoritmo di mining: ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash è stato il successore di un algoritmo R&D originale noto come ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/).
+La Mainnet di Ethereum ha sempre utilizzato un solo algoritmo di mining: ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash è stato il successore di un algoritmo di R&S originale noto come ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/).
[Maggiori informazioni sugli algoritmi di mining](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/).
@@ -83,4 +83,4 @@ La Rete principale di Ethereum ha sempre e solo usato un algoritmo di mining: ['
- [Gas](/developers/docs/gas/)
- [EVM](/developers/docs/evm/)
-- [Proof of Work](/developers/docs/consensus-mechanisms/pow/)
+- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/)
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md
index b7e06e4f117..3b7d4888019 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md
@@ -4,32 +4,32 @@ description: Uno sguardo dettagliato all'algoritmo di Dagger-Hashimoto.
lang: it
---
-Dagger-Hashimoto era l'implementazione e specifica di ricerca originale per l'algoritmo di mining di Ethereum. Dagger-Hashimoto è stato sostituito da [Ethash](#ethash). Il mining è stato disattivato completamente con [La Fusione](/roadmap/merge/), il 15 settembre 2022. Da allora, Ethereum è stato assicurato utilizzando un meccanismo [proof-of-of-stake](/developers/docs/consensus-mechanisms/pos). Questa pagina è di interesse storico - le informazioni qui non sono più rilevanti per post-Merge Ethereum.
+Dagger-Hashimoto era l'implementazione e specifica di ricerca originale per l'algoritmo di mining di Ethereum. Dagger-Hashimoto è stato soppiantato da [Ethash](#ethash). Il mining è stato disattivato completamente con [La Fusione](/roadmap/merge/) il 15 settembre 2022. Da allora, Ethereum è protetto utilizzando invece un meccanismo di [proof-of-stake](/developers/docs/consensus-mechanisms/pos). Questa pagina è di interesse storico - le informazioni qui non sono più rilevanti per post-Merge Ethereum.
## Prerequisiti {#prerequisites}
-Per meglio comprendere questa pagina, ti consigliamo prima di informarti sul [consenso proof-of-work](/developers/docs/consensus-mechanisms/pow), sul [mining](/developers/docs/consensus-mechanisms/pow/mining) e sugli [algoritmi di mining](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima il [consenso proof-of-work](/developers/docs/consensus-mechanisms/pow), il [mining](/developers/docs/consensus-mechanisms/pow/mining) e gli [algoritmi di mining](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms).
## Dagger-Hashimoto {#dagger-hashimoto}
Dagger-Hashimoto punta a soddisfare due obiettivi:
-1. **Resistenza ASIC**: la creazione di hardware specializzato per l'algoritmo dovrebbe apportare un beneficio minimo
-2. **Verificabilità da un client leggero**: un blocco dovrebbe essere efficientemente verificabile da un client leggero.
+1. **Resistenza ASIC**: il vantaggio derivante dalla creazione di hardware specializzato per l'algoritmo dovrebbe essere il più piccolo possibile
+2. **Verificabilità del client leggero**: un blocco dovrebbe essere verificabile in modo efficiente da un client leggero.
Con una modifica aggiuntiva, specifichiamo anche come raggiungere un terzo obiettivo se desiderato, ma al costo di una maggiore complessità:
-**Archiviazione della catena completa**: il mining dovrebbe richiedere l'archiviazione dello stato completo della blockchain (a causa della struttura irregolare dell'albero di stato di Ethereum, prevediamo la possibilità di alcune potature (pruning), soprattutto dopo alcuni contratti usati spesso, che vogliamo comunque mantenere al minimo).
+**Archiviazione dell'intera catena**: il mining dovrebbe richiedere l'archiviazione dello stato completo della blockchain (a causa della struttura irregolare del trie di stato di Ethereum, prevediamo che sarà possibile un po' di potatura (pruning), in particolare di alcuni contratti usati di frequente, ma vogliamo minimizzarlo).
## Generazione del DAG {#dag-generation}
-Il codice per l'algoritmo sarà definito in Python, di seguito. Per prima cosa, diamo `encode_int` per il marshaling in stringhe di interi non firmati con una precisione specificata. È dato anche il suo opposto:
+Il codice per l'algoritmo sarà definito in Python, di seguito. Innanzitutto, forniamo `encode_int` per il marshaling di interi senza segno di precisione specificata in stringhe. È dato anche il suo opposto:
```python
NUM_BITS = 512
def encode_int(x):
- "Encode an integer x as a string of 64 characters using a big-endian scheme"
+ "Codifica un intero x in una stringa di 64 caratteri utilizzando uno schema big-endian"
o = ''
for _ in range(NUM_BITS / 8):
o = chr(x % 256) + o
@@ -37,7 +37,7 @@ def encode_int(x):
return o
def decode_int(s):
- "Unencode an integer x from a string using a big-endian scheme"
+ "Decodifica un intero x da una stringa utilizzando uno schema big-endian"
x = 0
for c in s:
x *= 256
@@ -45,7 +45,7 @@ def decode_int(s):
return x
```
-Poi supponiamo che `sha3` sia una funzione che prende un intero e produce un intero e che `dbl_sha3` sia una funzione double-sha3; se vogliamo convertire questo codice di riferimento in un uso d'implementazione:
+Assumiamo poi che `sha3` sia una funzione che accetta un intero e restituisce un intero, e `dbl_sha3` sia una funzione double-sha3; se si converte questo codice di riferimento in un'implementazione, usare:
```python
from pyethereum import utils
@@ -82,9 +82,9 @@ params = {
}
```
-`P` in questo caso è un numero primo scelto in modo che `log₂(P)` sia solo di poco inferiore a 512, che corrisponde ai 512 bit che abbiamo usato per rappresentare i nostri numeri. Nota che in realtà deve essere memorizzata solo la seconda metà del DAG, quindi il requisito de-facto di RAM parte da 1 GB e cresce di 441 MB l'anno.
+`P` in questo caso è un numero primo scelto in modo tale che `log₂(P)` sia appena inferiore a 512, che corrisponde ai 512 bit che abbiamo usato per rappresentare i nostri numeri. Nota che in realtà deve essere memorizzata solo la seconda metà del DAG, quindi il requisito de-facto di RAM parte da 1 GB e cresce di 441 MB l'anno.
-### Costruzione del grafico dagger {#dagger-graph-building}
+### Costruzione del grafo Dagger {#dagger-graph-building}
Il primitivo di costruzione del grafico dagger è definito come segue:
@@ -101,11 +101,11 @@ def produce_dag(params, seed, length):
return o
```
-Essenzialmente, avvia un grafico come un singolo nodo, `sha3(seed)` e da lì si inizia ad aggiungere sequenzialmente gli altri nodi, a seconda dei nodi casuali precedenti. Quando viene creato un nuovo nodo, è calcolata una potenza modulare del seed per selezionare casualmente degli indici inferiori a `i` (usando il suddetto `x % i`) e i valori dei nodi a questi indici sono usati all'interno di un calcolo per generare un nuovo valore per `x`, che viene poi passato a una piccola funzione di proof-of-work (basata su XOR) per generare, infine, il valore del grafico all'indice `i`. La logica dietro questa costruzione particolare è forzare l'accesso sequenziale del DAG; il valore successivo del DAG che sarà accessibile non è determinabile finché non sia noto il valore corrente. Infine, l'esponenziazione modulare genera ulteriormente un hashing del risultato.
+In sostanza, avvia un grafo come un singolo nodo, `sha3(seed)`, e da lì inizia ad aggiungere in sequenza altri nodi basati su nodi precedenti casuali. Quando viene creato un nuovo nodo, viene calcolata una potenza modulare del seed per selezionare casualmente alcuni indici inferiori a `i` (usando `x % i` sopra), e i valori dei nodi a quegli indici vengono utilizzati in un calcolo per generare un nuovo valore per `x`, che viene poi immesso in una piccola funzione di proof-of-work (basata su XOR) per generare infine il valore del grafo all'indice `i`. La logica dietro questa costruzione particolare è forzare l'accesso sequenziale del DAG; il valore successivo del DAG che sarà accessibile non è determinabile finché non sia noto il valore corrente. Infine, l'esponenziazione modulare genera ulteriormente un hashing del risultato.
Questo algoritmo si basa su diversi risultati dalla teoria dei numeri. Vedere l'appendice più avanti per una discussione.
-## Valutazione da client leggero {#light-client-evaluation}
+## Valutazione del client leggero {#light-client-evaluation}
Questa costruzione del grafico intende consentire a ogni nodo nel grafico di essere ricostruito calcolando solamente l'albero secondario di un piccolo numero di nodi, in modo da richiedere solo una piccola quantità di memoria ausiliaria. Nota che, con k=1, l'albero secondario è solo una catena di valori che cresce al primo elemento nel DAG.
@@ -131,11 +131,11 @@ def quick_calc(params, seed, p):
return quick_calc_cached(p)
```
-essenzialmente, è semplicemente una riscrittura dell'algoritmo di cui sopra, che elimina il ciclo di calcolo dei valori per l'intero DAG e sostituisce la ricerca del nodo precedente con una chiamata ricorsiva o una ricerca della cache. Nota che per `k=1`, la cache non è necessaria, anche se in realtà un'ulteriore ottimizzazione pre-calcola le prime migliaia di valori del DAG e li mantiene come una cache statica per i calcoli; vedi l'appendice per l'implementazione di un codice a riguardo.
+essenzialmente, è semplicemente una riscrittura dell'algoritmo di cui sopra, che elimina il ciclo di calcolo dei valori per l'intero DAG e sostituisce la ricerca del nodo precedente con una chiamata ricorsiva o una ricerca della cache. Si noti che per `k=1` la cache non è necessaria, sebbene un'ulteriore ottimizzazione precalcoli effettivamente i primi mille valori del DAG e li conservi come cache statica per i calcoli; vedere l'appendice per un'implementazione del codice di questo.
-## Doppio buffer di DAG {#double-buffer}
+## Doppio buffer dei DAG {#double-buffer}
-In un client completo, è usato un [_doppio buffer_](https://wikipedia.org/wiki/Multiple_buffering) di 2 DAG prodotti dalla suddetta formula. L'idea è che i DAG siano prodotti ogni `epochtime` numero di blocchi, secondo i parametri indicati sopra. Il client non usa l'ultimo DAG prodotto, ma quello precedente. Il beneficio è che consente ai DAG di essere sostituiti nel tempo senza dover prevedere un passaggio in cui i miner devono improvvisamente ricalcolare tutti i dati. In caso contrario vi sarebbe il rischio, a intervalli regolari, di un brusco rallentamento temporaneo nell'elaborazione della catena e l'aumento drastico della centralizzazione. In quei pochi minuti prima che tutti i dati siano ricalcolati sussiste quindi il rischio di un attacco 51%.
+In un client completo, viene utilizzato un [_doppio buffer_](https://wikipedia.org/wiki/Multiple_buffering) di 2 DAG prodotti dalla formula di cui sopra. L'idea è che i DAG vengano prodotti ogni `epochtime` numero di blocchi secondo i parametri di cui sopra. Il client non usa l'ultimo DAG prodotto, ma quello precedente. Il beneficio è che consente ai DAG di essere sostituiti nel tempo senza dover prevedere un passaggio in cui i miner devono improvvisamente ricalcolare tutti i dati. In caso contrario vi sarebbe il rischio, a intervalli regolari, di un brusco rallentamento temporaneo nell'elaborazione della catena e l'aumento drastico della centralizzazione. In quei pochi minuti prima che tutti i dati siano ricalcolati sussiste quindi il rischio di un attacco 51%.
L'algoritmo usato per generare la serie di DAG usati per calcolare il lavoro per un blocco è il seguente:
@@ -256,54 +256,50 @@ Inoltre, nota che Dagger-Hashimoto impone anche altri requisiti sull'intestazion
## Letture consigliate {#further-reading}
-_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
## Appendice {#appendix}
-Come notato sopra, l'RNG usato per la generazione del DAG si affida ad alcuni risultati dalla teoria dei numeri. Per prima cosa, accertiamoci che l'RNG di Lehmer che è la base per la variabile `picker` abbia un periodo ampio. In secondo luogo, mostriamo che `pow(x,3,P)` non mapperà `x` a `1` o `P-1`, a condizione che all’inizio `x ∈ [2,P-2]`. Infine, mostriamo che `pow(x,3,P)` ha un basso tasso di collisione se trattato come funzione di hashing.
+Come notato sopra, l'RNG usato per la generazione del DAG si affida ad alcuni risultati dalla teoria dei numeri. In primo luogo, forniamo la garanzia che l'RNG di Lehmer, che è la base della variabile `picker`, abbia un periodo ampio. In secondo luogo, mostriamo che `pow(x,3,P)` non mapperà `x` a `1` o `P-1`, a condizione che all'inizio `x ∈ [2,P-2]`. Infine, mostriamo che `pow(x,3,P)` ha un basso tasso di collisione se trattato come una funzione di hashing.
### Generatore di numeri casuali di Lehmer {#lehmer-random-number}
-Sebbene la funzione `produce_dag` non necessiti di produrre numeri casuali imparziali, un possibile rischio è dato dal fatto che `seed**i % P` prende solo una manciata di valori. Questo potrebbe fornire un vantaggio ai miner che riconoscono lo schema, rispetto a quelli che non lo conoscono.
+Sebbene la funzione `produce_dag` non debba produrre numeri casuali non distorti, una minaccia potenziale è che `seed**i % P` assuma solo una manciata di valori. Questo potrebbe fornire un vantaggio ai miner che riconoscono lo schema, rispetto a quelli che non lo conoscono.
-Per evitarlo, si è fatto ricorso a un risultato dalla teoria dei numeri. Un [_Numero primo sicuro_](https://en.wikipedia.org/wiki/Safe_prime) si definisce come numero primo `P` tale per cui anche `(P-1)/2` è un numero primo. L'_ordine_ di un membro `x` del [gruppo moltiplicativo](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` è definito come il valore minimo di `m` tale per cui
xᵐ mod P ≡ 1
+Per evitarlo, si è fatto ricorso a un risultato dalla teoria dei numeri. Un [_Numero Primo Sicuro_](https://en.wikipedia.org/wiki/Safe_prime) è definito come un numero primo `P` tale che anche `(P-1)/2` sia primo. L'_ordine_ di un membro `x` del [gruppo moltiplicativo](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` è definito come il `m` minimo tale che
xᵐ mod P ≡ 1
Date queste definizioni, abbiamo:
-> Osservazione 1. Ipotizziamo che `x` sia un membro del gruppo moltiplicativo `ℤ/Pℤ` per un numero primo sicuro `P`. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, allora l'ordine di `x` è `P-1` o `(P-1)/2`.
+> Osservazione 1. Sia `x` un membro del gruppo moltiplicativo `ℤ/Pℤ` per un numero primo sicuro `P`. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, allora l'ordine di `x` è `P-1` o `(P-1)/2`.
-_Dimostrazione_. Poiché `P` è un numero primo sicuro, allora per il \[Teorema di Lagrange\]\[lagrange\], l'ordine di `x` è `1`, `2`, `(P-1)/2` o `P-1`.
+_Dimostrazione_. Poiché `P` è un numero primo sicuro, allora per il [Teorema di Lagrange][lagrange] l'ordine di `x` è `1`, `2`, `(P-1)/2` o `P-1`.
-L'ordine di `x` non può essere `1`, poiché secondo il Piccolo teorema di Fermat:
+L'ordine di `x` non può essere `1`, poiché per il Piccolo Teorema di Fermat abbiamo:
xP-1 mod P ≡ 1
-Quindi, `x`, deve essere un'identità moltiplicativa di `ℤ/nℤ`, che è univoca. Poiché abbiamo presupposto che `x ≠ 1`, ciò è impossibile.
+Quindi `x` deve essere un'identità moltiplicativa di `ℤ/nℤ`, che è unica. Poiché abbiamo assunto per ipotesi che `x ≠ 1`, questo non è possibile.
-L'ordine di `x` non può essere `2` a meno che `x = P-1`, poiché ciò violerebbe il fatto che `P` sia un numero primo.
+L'ordine di `x` non può essere `2` a meno che `x = P-1`, poiché ciò violerebbe il fatto che `P` sia primo.
-Dalla suddetta proposizione possiamo capire che iterando `(picker * init) % P`, avrà una lunghezza del ciclo di almeno `(P-1)/2`. Questo perché abbiamo selezionato `P` come un numero primo sicuro, approssimativamente pari a una potenza superiore di due e che `init` è nell'intervallo `[2,2**256+1]`. Data la portata di `P`, non dovremmo mai aspettarci un ciclo dall'elevamento a potenza modulare.
+Dalla proposizione precedente, possiamo riconoscere che l'iterazione di `(picker * init) % P` avrà una lunghezza del ciclo di almeno `(P-1)/2`. Questo perché abbiamo selezionato `P` come un numero primo sicuro approssimativamente uguale a una potenza superiore di due, e `init` si trova nell'intervallo `[2,2**256+1]`. Data la grandezza di `P`, non dovremmo mai aspettarci un ciclo dall'esponenziazione modulare.
-Quando assegniamo la prima cella nel DAG (la variabile etichettata come `init`), calcoliamo `pow(sha3(seed) + 2, 3, P)`. A prima vista, questo non garantisce che il risultato sia `1` né `P-1`. Tuttavia, poiché `P-1` è un numero primo sicuro, abbiamo la seguente garanzia aggiuntiva, che è un corollario dell'Osservazione 1:
+Quando assegniamo la prima cella nel DAG (la variabile etichettata `init`), calcoliamo `pow(sha3(seed) + 2, 3, P)`. A prima vista, questo non garantisce che il risultato non sia né `1` né `P-1`. Tuttavia, poiché `P-1` è un numero primo sicuro, abbiamo la seguente garanzia aggiuntiva, che è un corollario dell'Osservazione 1:
-> Osservazione 2. Ipotizziamo che `x` sia un membro del gruppo moltiplicativo `ℤ/Pℤ` per un numero primo sicuro `P`, e prendiamo `w` come numero naturale. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, nonché `w mod P ≠ P-1 mod P` e `w mod P ≠ 0 mod P`, allora `xʷ mod P ≠ 1 mod P` e `xʷ mod P ≠ P-1 mod P`
+> Osservazione 2. Sia `x` un membro del gruppo moltiplicativo `ℤ/Pℤ` per un numero primo sicuro `P`, e sia `w` un numero naturale. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, così come `w mod P ≠ P-1 mod P` e `w mod P ≠ 0 mod P`, allora `xʷ mod P ≠ 1 mod P` e `xʷ mod P ≠ P-1 mod P`
### Esponenziazione modulare come funzione di hash {#modular-exponentiation}
-Per certi valori di `P` e `w`, la funzione `pow(x, w, P)` potrebbe avere molte collisioni. Ad esempio, `pow(x,9,19)` prende solo i valori `{1,18}`.
+Per certi valori di `P` e `w`, la funzione `pow(x, w, P)` può avere molte collisioni. Ad esempio, `pow(x,9,19)` assume solo i valori `{1,18}`.
-Dato che `P` è primo, allora è possibile scegliere un'appropriata `w` per una funzione di hashing di esponenziazione modulare usando il seguente risultato:
+Dato che `P` è primo, una `w` appropriata per una funzione di hashing a esponenziazione modulare può essere scelta usando il seguente risultato:
-> Osservazione 3. Prendiamo `P` come numero primo; `w` e `P-1` sono coprimi se e solo se per ogni `a` e `b` in `ℤ/Pℤ`:
->
->
-> `aʷ mod P ≡ bʷ mod P` se e solo se `a mod P ≡ b mod P`
->
+> Osservazione 3. Sia `P` un numero primo; `w` e `P-1` sono coprimi se e solo se per tutti gli `a` e `b` in `ℤ/Pℤ`:
`aʷ mod P ≡ bʷ mod P` se e solo se `a mod P ≡ b mod P`
-Dunque, dato che `P` è primo e `w` è coprimo rispetto a `P-1`, abbiamo che `|{pow(x, w, P) : x ∈ ℤ}| = P`, e questo implica che la funzione di hashing ha la frequenza di collisione minima possibile.
+Quindi, dato che `P` è primo e `w` è coprimo con `P-1`, abbiamo che `|{pow(x, w, P) : x ∈ ℤ}| = P`, il che implica che la funzione di hashing ha il tasso di collisione minimo possibile.
-Nel caso speciale in cui `P` sia un numero primo sicuro, come da noi selezionato, allora `P-1` ha solo i fattori 1, 2, `(P-1)/2` e `P-1`. Poiché `P` > 7, sappiamo che 3 è primo rispetto a `P-1`, quindi `w=3` soddisfa la proposizione precedente.
+Nel caso speciale in cui `P` è un numero primo sicuro come abbiamo selezionato, `P-1` ha solo i fattori 1, 2, `(P-1)/2` e `P-1`. Poiché `P` > 7, sappiamo che 3 è coprimo con `P-1`, quindi `w=3` soddisfa la proposizione precedente.
-## Algoritmo di valutazione più efficiente basato sulla cache {#cache-based-evaluation}
+## Algoritmo di valutazione più efficiente basato su cache {#cache-based-evaluation}
```python
def quick_calc(params, seed, p):
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
index cee1f041f73..5939bae02d7 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md
@@ -8,12 +8,12 @@ lang: it
- Ethash era l'algoritmo di mining di proof-of-work di Ethereum. Il proof-of-work è ora stato **disattivato interamente** e, invece, Ethereum è ora protetto utilizzando il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). Leggi di più su [La Fusione](/roadmap/merge/), sul [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e sullo [staking](/staking/). Questa pagina è per interesse storico!
+ Ethash era l'algoritmo di mining di proof-of-work di Ethereum. Il proof-of-work è stato ora **interamente disattivato** ed Ethereum è ora protetto usando invece il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). Leggi di più su [La Fusione](/roadmap/merge/), [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e [staking](/staking/). Questa pagina è per interesse storico!
-Ethash è una versione modificata dell'algoritmo di [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). Il proof-of-work di Ethash è [a elevato consumo di memoria](https://wikipedia.org/wiki/Memory-hard_function), cosa pensata per rendere l'algoritmo resistente agli ASIC. Gli ASIC di Ethash sono infine stati sviluppati, ma il mining della GPU è stata un'opzione ancora valida fino alla disattivazione del proof-of-work. Ethash è ancora usato per minare altre valute su altre reti di proof-of-work non di Ethereum.
+Ethash è una versione modificata dell'algoritmo [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). Il proof-of-work di Ethash è [memory hard](https://wikipedia.org/wiki/Memory-hard_function), caratteristica pensata per rendere l'algoritmo resistente agli ASIC. Gli ASIC di Ethash sono infine stati sviluppati, ma il mining della GPU è stata un'opzione ancora valida fino alla disattivazione del proof-of-work. Ethash è ancora usato per minare altre valute su altre reti di proof-of-work non di Ethereum.
## Come funziona Ethash? {#how-does-ethash-work}
@@ -21,9 +21,9 @@ La gravosità sulla memoria è ottenuta con un algoritmo di proof-of-work che ri
Il percorso generale intrapreso dall'algoritmo è il seguente:
-1. Esiste un **seed**, calcolabile per ogni blocco scansionando fino a quel punto le intestazioni dei blocchi.
-2. Dal seed, si può calcolare una **cache pseudo-casuale di 16 MB**. I client leggeri memorizzano la cache.
-3. Dalla cache, possiamo generare un **dataset di 1 GB**, caratterizzato dal fatto che ogni elemento nel dataset dipende solo da una piccola quantità di elementi dalla cache. I client completi e i miner memorizzano il dataset. Il dataset cresce linearmente col tempo.
+1. Esiste un **seed** che può essere calcolato per ogni blocco, scansionando le intestazioni dei blocchi fino a quel punto.
+2. Dal seed, è possibile calcolare una **cache pseudocasuale da 16 MB**. I client leggeri memorizzano la cache.
+3. Dalla cache, possiamo generare un **dataset di 1 GB**, con la proprietà che ogni elemento del dataset dipende solo da un piccolo numero di elementi della cache. I client completi e i miner memorizzano il dataset. Il dataset cresce linearmente col tempo.
4. Durante il mining vengono prese delle fette (slice) casuali del dataset, eseguendone l'hashing. La verifica può essere effettuata con poca memoria usando la cache per rigenerare le parti specifiche del dataset necessarie, così da dover solo memorizzare la cache.
Il grande dataset è aggiornato una volta ogni 30.000 blocchi, in questo modo l'impegno di un miner sarà per lo più quello di leggere il dataset, non effettuare modifiche a esso.
@@ -33,23 +33,23 @@ Il grande dataset è aggiornato una volta ogni 30.000 blocchi, in questo modo l'
Adottiamo le seguenti definizioni:
```
-WORD_BYTES = 4 # bytes in word
-DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis
-DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch
-CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis
-CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch
-CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache
-EPOCH_LENGTH = 30000 # blocks per epoch
-MIX_BYTES = 128 # width of mix
-HASH_BYTES = 64 # hash length in bytes
-DATASET_PARENTS = 256 # number of parents of each dataset element
-CACHE_ROUNDS = 3 # number of rounds in cache production
-ACCESSES = 64 # number of accesses in hashimoto loop
+WORD_BYTES = 4 # byte in parola
+DATASET_BYTES_INIT = 2**30 # byte nel dataset alla genesi
+DATASET_BYTES_GROWTH = 2**23 # crescita del dataset per epoca
+CACHE_BYTES_INIT = 2**24 # byte nella cache alla genesi
+CACHE_BYTES_GROWTH = 2**17 # crescita della cache per epoca
+CACHE_MULTIPLIER=1024 # Dimensione del DAG relativa alla cache
+EPOCH_LENGTH = 30000 # blocchi per epoca
+MIX_BYTES = 128 # ampiezza del mix
+HASH_BYTES = 64 # lunghezza dell'hash in byte
+DATASET_PARENTS = 256 # numero di parent di ogni elemento del dataset
+CACHE_ROUNDS = 3 # numero di round nella produzione della cache
+ACCESSES = 64 # numero di accessi nel loop di hashimoto
```
-### L'uso di "SHA3" {#sha3}
+### L'uso di 'SHA3' {#sha3}
-Lo sviluppo di Ethereum è coinciso con lo sviluppo dello standard SHA3 e il processo standard ha effettuato una modifica tardiva al padding dell'algoritmo di hash finalizzato, quindi, gli hash "sha3_256" e "sha3_512" di Ethereum non sono hash dello standard sha3, ma una variante, spesso definita "Keccak-256" e "Keccak-512" in altri contesti. Vedi la discussione, ad esempio [qui](https://eips.ethereum.org/EIPS/eip-1803), [qui](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use) o [qui](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057).
+Lo sviluppo di Ethereum è coinciso con lo sviluppo dello standard SHA3 e il processo standard ha effettuato una modifica tardiva al padding dell'algoritmo di hash finalizzato, quindi, gli hash "sha3_256" e "sha3_512" di Ethereum non sono hash dello standard sha3, ma una variante, spesso definita "Keccak-256" e "Keccak-512" in altri contesti. Vedi la discussione, ad es., [qui](https://eips.ethereum.org/EIPS/eip-1803), [qui](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), o [qui](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057).
Si ricorda che gli hash "sha3" siano presentati nella descrizione dell'algoritmo più avanti.
@@ -83,12 +83,12 @@ Specifichiamo ora la funzione per produrre una cache:
def mkcache(cache_size, seed):
n = cache_size // HASH_BYTES
- # Sequentially produce the initial dataset
+ # Produci sequenzialmente il dataset iniziale
o = [sha3_512(seed)]
for i in range(1, n):
o.append(sha3_512(o[-1]))
- # Use a low-round version of randmemohash
+ # Usa una versione a basso numero di round di randmemohash
for _ in range(CACHE_ROUNDS):
for i in range(n):
v = o[i][0] % n
@@ -97,11 +97,11 @@ def mkcache(cache_size, seed):
return o
```
-Il processo di produzione della cache richiede dapprima il riempimento sequenziale di 32 MB di memoria, poi l'esecuzione di due passaggi dell'algoritmo _RandMemoHash_ di Sergio Demian Lerner da [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). L'output è una serie di valori a 64 byte 524288.
+Il processo di produzione della cache comporta prima il riempimento sequenziale di 32 MB di memoria, poi l'esecuzione di due passaggi dell'algoritmo _RandMemoHash_ di Sergio Demian Lerner, da [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). L'output è una serie di valori a 64 byte 524288.
## Funzione di aggregazione dei dati {#date-aggregation-function}
-Usiamo un algoritmo ispirato dall'[hash FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) in alcuni casi come un sostituto non associativo per XOR. Nota che moltiplichiamo il numero primo con l'intero input a 32 bit, a differenza della specifica FNV-1, che moltiplica invece il numero primo con un byte (ottetto).
+In alcuni casi, usiamo un algoritmo ispirato all'[hash FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) come sostituto non associativo di XOR. Nota che moltiplichiamo il numero primo con l'intero input a 32 bit, a differenza della specifica FNV-1, che moltiplica invece il numero primo con un byte (ottetto).
```python
FNV_PRIME = 0x01000193
@@ -112,7 +112,7 @@ def fnv(v1, v2):
Anche lo yellow paper specifica fnv come v1\*(FNV_PRIME ^ v2), tutte le implementazioni correnti usano attualmente la suddetta definizione.
-## Calcolo dell'intero dataset {#full-dataset-calculation}
+## Calcolo del dataset completo {#full-dataset-calculation}
Ogni elemento da 64 byte nell'intero dataset da 1 GB è calcolato come segue:
@@ -120,11 +120,11 @@ Ogni elemento da 64 byte nell'intero dataset da 1 GB è calcolato come segue:
def calc_dataset_item(cache, i):
n = len(cache)
r = HASH_BYTES // WORD_BYTES
- # initialize the mix
+ # inizializza il mix
mix = copy.copy(cache[i % n])
mix[0] ^= i
mix = sha3_512(mix)
- # fnv it with a lot of random cache nodes based on i
+ # applica fnv con molti nodi della cache casuali basati su i
for j in range(DATASET_PARENTS):
cache_index = fnv(i ^ j, mix[j % r])
mix = map(fnv, mix, cache[cache_index % n])
@@ -138,29 +138,29 @@ def calc_dataset(full_size, cache):
return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)]
```
-## Ciclo principale {#main-loop}
+## Loop principale {#main-loop}
-Ora, specifichiamo il ciclo principale in stile "hashimoto", dove aggreghiamo i dati dal dataset completo per poter produrre il valore finale per un'intestazione e nonce in particolare. Nel codice seguente, `header` rappresenta l'_hash_ SHA3-256 della rappresentazione RLP di un'intestazione del blocco _troncata_, ovvero, di un'intestazione che esclude i campi **mixHash** e **nonce**. Un `nonce` si compone degli otto byte di un intero non firmato da 64 bit, con ordinamento big-endian. Quindi `nonce[::-1]` è la rappresentazione little-endian di otto byte di quel valore:
+Ora, specifichiamo il ciclo principale in stile "hashimoto", dove aggreghiamo i dati dal dataset completo per poter produrre il valore finale per un'intestazione e nonce in particolare. Nel codice seguente, `header` rappresenta l'_hash_ SHA3-256 della rappresentazione RLP di un'_intestazione del blocco_ troncata, ossia di un'intestazione che esclude i campi **mixHash** e **nonce**. Il `nonce` è costituito dagli otto byte di un intero non firmato a 64 bit in ordine big-endian. Quindi `nonce[::-1]` è la rappresentazione little-endian a otto byte di quel valore:
```python
def hashimoto(header, nonce, full_size, dataset_lookup):
n = full_size / HASH_BYTES
w = MIX_BYTES // WORD_BYTES
mixhashes = MIX_BYTES / HASH_BYTES
- # combine header+nonce into a 64 byte seed
+ # combina header+nonce in un seed di 64 byte
s = sha3_512(header + nonce[::-1])
- # start the mix with replicated s
+ # inizia il mix con s replicato
mix = []
for _ in range(MIX_BYTES / HASH_BYTES):
mix.extend(s)
- # mix in random dataset nodes
+ # mixa con nodi del dataset casuali
for i in range(ACCESSES):
p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
newdata = []
for j in range(MIX_BYTES / HASH_BYTES):
newdata.extend(dataset_lookup(p + j))
mix = map(fnv, mix, newdata)
- # compress mix
+ # comprimi il mix
cmix = []
for i in range(0, len(mix), 4):
cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
@@ -176,7 +176,7 @@ def hashimoto_full(full_size, dataset, header, nonce):
return hashimoto(header, nonce, full_size, lambda x: dataset[x])
```
-Essenzialmente, manteniamo un mix di 128 byte e recuperiamo sequenzialmente e ripetutamente 128 byte dal dataset completo e usiamo la funzione `fnv` per combinarli col mix. Vengono usati 128 byte di accesso sequenziale così che ogni ciclo dell'algoritmo recuperi sempre una pagina intera dalla RAM, minimizzando le ricerche a vuoto nel lookaside buffer che gli ASIC dovrebbero teoricamente poter evitare.
+In sostanza, manteniamo un "mix" largo 128 byte e recuperiamo ripetutamente e in sequenza 128 byte dal dataset completo, utilizzando la funzione `fnv` per combinarli con il mix. Vengono usati 128 byte di accesso sequenziale così che ogni ciclo dell'algoritmo recuperi sempre una pagina intera dalla RAM, minimizzando le ricerche a vuoto nel lookaside buffer che gli ASIC dovrebbero teoricamente poter evitare.
Se l'output di questo algoritmo è inferiore all'obiettivo desiderato, allora il nonce è valido. Nota che l'applicazione aggiuntiva di `sha3_256` alla fine assicura che esista un nonce intermedio, che può essere fornito per provare che almeno una piccola quantità di lavoro è stata eseguita; questa rapida verifica di PoW esterna è utilizzabile per scopi anti-DDoS. Serve anche a fornire la garanzia statistica che il risultato sia un numero a 256 bit imparziale.
@@ -186,7 +186,7 @@ L'algoritmo di mining è definito come segue:
```python
def mine(full_size, dataset, header, difficulty):
- # zero-pad target to compare with hash on the same digit
+ # riempi di zeri il target per confrontarlo con l'hash sulla stessa cifra
target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
from random import randint
nonce = randint(0, 2**64)
@@ -195,7 +195,7 @@ def mine(full_size, dataset, header, difficulty):
return nonce
```
-## Definire l'hash del seed {#seed-hash}
+## Definizione dell'hash del seed {#seed-hash}
Per poter calcolare l'hash del seed da usare per fare mining su un dato blocco, usiamo il seguente algoritmo:
@@ -211,7 +211,7 @@ Nota che per la fluidità delle attività di mining e verifica, consigliamo di p
## Letture consigliate {#further-reading}
-_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
## Appendice {#appendix}
@@ -220,7 +220,7 @@ Il seguente codice dovrebbe essere anteposto se sei interessato all'esecuzione d
```python
import sha3, copy
-# Assumes little endian bit ordering (same as Intel architectures)
+# Presuppone un ordinamento dei bit little-endian (come nelle architetture Intel)
def decode_int(s):
return int(s[::-1].encode('hex'), 16) if s else 0
@@ -248,7 +248,7 @@ def serialize_cache(ds):
serialize_dataset = serialize_cache
-# sha3 hash function, outputs 64 bytes
+# funzione di hash sha3, restituisce 64 byte
def sha3_512(x):
return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
@@ -686,7 +686,7 @@ data_sizes = [
18102613376, 18111004544, 18119388544, 18127781248, 18136170368,
18144558976, 18152947328, 18161336192, 18169724288, 18178108544,
18186498944, 18194886784, 18203275648, 18211666048, 18220048768,
-18228444544, 18236833408, 18245220736]
+1822844544, 18236833408, 18245220736]
cache_sizes = [
16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072,
@@ -881,139 +881,139 @@ cache_sizes = [
177209152, 177340096, 177470528, 177600704, 177731648, 177864256,
177994816, 178126528, 178257472, 178387648, 178518464, 178650176,
178781888, 178912064, 179044288, 179174848, 179305024, 179436736,
-179568448, 179698496, 179830208, 179960512, 180092608, 180223808,
-180354752, 180485696, 180617152, 180748096, 180877504, 181009984,
-181139264, 181272512, 181402688, 181532608, 181663168, 181795136,
-181926592, 182057536, 182190016, 182320192, 182451904, 182582336,
-182713792, 182843072, 182976064, 183107264, 183237056, 183368384,
-183494848, 183631424, 183762752, 183893824, 184024768, 184154816,
-184286656, 184417984, 184548928, 184680128, 184810816, 184941248,
-185072704, 185203904, 185335616, 185465408, 185596352, 185727296,
-185859904, 185989696, 186121664, 186252992, 186383552, 186514112,
-186645952, 186777152, 186907328, 187037504, 187170112, 187301824,
-187429184, 187562048, 187693504, 187825472, 187957184, 188087104,
-188218304, 188349376, 188481344, 188609728, 188743616, 188874304,
-189005248, 189136448, 189265088, 189396544, 189528128, 189660992,
-189791936, 189923264, 190054208, 190182848, 190315072, 190447424,
-190577984, 190709312, 190840768, 190971328, 191102656, 191233472,
-191364032, 191495872, 191626816, 191758016, 191888192, 192020288,
-192148928, 192282176, 192413504, 192542528, 192674752, 192805952,
-192937792, 193068608, 193198912, 193330496, 193462208, 193592384,
-193723456, 193854272, 193985984, 194116672, 194247232, 194379712,
-194508352, 194641856, 194772544, 194900672, 195035072, 195166016,
-195296704, 195428032, 195558592, 195690304, 195818176, 195952576,
-196083392, 196214336, 196345792, 196476736, 196607552, 196739008,
-196869952, 197000768, 197130688, 197262784, 197394368, 197523904,
-197656384, 197787584, 197916608, 198049472, 198180544, 198310208,
-198442432, 198573632, 198705088, 198834368, 198967232, 199097792,
-199228352, 199360192, 199491392, 199621696, 199751744, 199883968,
-200014016, 200146624, 200276672, 200408128, 200540096, 200671168,
-200801984, 200933312, 201062464, 201194944, 201326144, 201457472,
-201588544, 201719744, 201850816, 201981632, 202111552, 202244032,
-202374464, 202505152, 202636352, 202767808, 202898368, 203030336,
-203159872, 203292608, 203423296, 203553472, 203685824, 203816896,
-203947712, 204078272, 204208192, 204341056, 204472256, 204603328,
-204733888, 204864448, 204996544, 205125568, 205258304, 205388864,
-205517632, 205650112, 205782208, 205913536, 206044736, 206176192,
-206307008, 206434496, 206569024, 206700224, 206831168, 206961856,
-207093056, 207223616, 207355328, 207486784, 207616832, 207749056,
-207879104, 208010048, 208141888, 208273216, 208404032, 208534336,
-208666048, 208796864, 208927424, 209059264, 209189824, 209321792,
-209451584, 209582656, 209715136, 209845568, 209976896, 210106432,
-210239296, 210370112, 210501568, 210630976, 210763712, 210894272,
-211024832, 211156672, 211287616, 211418176, 211549376, 211679296,
-211812032, 211942592, 212074432, 212204864, 212334016, 212467648,
-212597824, 212727616, 212860352, 212991424, 213120832, 213253952,
-213385024, 213515584, 213645632, 213777728, 213909184, 214040128,
-214170688, 214302656, 214433728, 214564544, 214695232, 214826048,
-214956992, 215089088, 215219776, 215350592, 215482304, 215613248,
-215743552, 215874752, 216005312, 216137024, 216267328, 216399296,
-216530752, 216661696, 216790592, 216923968, 217054528, 217183168,
-217316672, 217448128, 217579072, 217709504, 217838912, 217972672,
-218102848, 218233024, 218364736, 218496832, 218627776, 218759104,
-218888896, 219021248, 219151936, 219281728, 219413056, 219545024,
-219675968, 219807296, 219938624, 220069312, 220200128, 220331456,
-220461632, 220592704, 220725184, 220855744, 220987072, 221117888,
-221249216, 221378368, 221510336, 221642048, 221772736, 221904832,
-222031808, 222166976, 222297536, 222428992, 222559936, 222690368,
-222820672, 222953152, 223083968, 223213376, 223345984, 223476928,
-223608512, 223738688, 223869376, 224001472, 224132672, 224262848,
-224394944, 224524864, 224657344, 224788288, 224919488, 225050432,
-225181504, 225312704, 225443776, 225574592, 225704768, 225834176,
-225966784, 226097216, 226229824, 226360384, 226491712, 226623424,
-226754368, 226885312, 227015104, 227147456, 227278528, 227409472,
-227539904, 227669696, 227802944, 227932352, 228065216, 228196288,
-228326464, 228457792, 228588736, 228720064, 228850112, 228981056,
-229113152, 229243328, 229375936, 229505344, 229636928, 229769152,
-229894976, 230030272, 230162368, 230292416, 230424512, 230553152,
-230684864, 230816704, 230948416, 231079616, 231210944, 231342016,
-231472448, 231603776, 231733952, 231866176, 231996736, 232127296,
-232259392, 232388672, 232521664, 232652608, 232782272, 232914496,
-233043904, 233175616, 233306816, 233438528, 233569984, 233699776,
-233830592, 233962688, 234092224, 234221888, 234353984, 234485312,
-234618304, 234749888, 234880832, 235011776, 235142464, 235274048,
-235403456, 235535936, 235667392, 235797568, 235928768, 236057152,
-236190272, 236322752, 236453312, 236583616, 236715712, 236846528,
-236976448, 237108544, 237239104, 237371072, 237501632, 237630784,
-237764416, 237895232, 238026688, 238157632, 238286912, 238419392,
-238548032, 238681024, 238812608, 238941632, 239075008, 239206336,
-239335232, 239466944, 239599168, 239730496, 239861312, 239992384,
-240122816, 240254656, 240385856, 240516928, 240647872, 240779072,
-240909632, 241040704, 241171904, 241302848, 241433408, 241565248,
-241696192, 241825984, 241958848, 242088256, 242220224, 242352064,
-242481856, 242611648, 242744896, 242876224, 243005632, 243138496,
-243268672, 243400384, 243531712, 243662656, 243793856, 243924544,
-244054592, 244187072, 244316608, 244448704, 244580032, 244710976,
-244841536, 244972864, 245104448, 245233984, 245365312, 245497792,
-245628736, 245759936, 245889856, 246021056, 246152512, 246284224,
-246415168, 246545344, 246675904, 246808384, 246939584, 247070144,
-247199552, 247331648, 247463872, 247593536, 247726016, 247857088,
-247987648, 248116928, 248249536, 248380736, 248512064, 248643008,
-248773312, 248901056, 249036608, 249167552, 249298624, 249429184,
-249560512, 249692096, 249822784, 249954112, 250085312, 250215488,
-250345792, 250478528, 250608704, 250739264, 250870976, 251002816,
-251133632, 251263552, 251395136, 251523904, 251657792, 251789248,
-251919424, 252051392, 252182464, 252313408, 252444224, 252575552,
-252706624, 252836032, 252968512, 253099712, 253227584, 253361728,
-253493056, 253623488, 253754432, 253885504, 254017216, 254148032,
-254279488, 254410432, 254541376, 254672576, 254803264, 254933824,
-255065792, 255196736, 255326528, 255458752, 255589952, 255721408,
-255851072, 255983296, 256114624, 256244416, 256374208, 256507712,
-256636096, 256768832, 256900544, 257031616, 257162176, 257294272,
-257424448, 257555776, 257686976, 257818432, 257949632, 258079552,
-258211136, 258342464, 258473408, 258603712, 258734656, 258867008,
-258996544, 259127744, 259260224, 259391296, 259522112, 259651904,
-259784384, 259915328, 260045888, 260175424, 260308544, 260438336,
-260570944, 260700992, 260832448, 260963776, 261092672, 261226304,
-261356864, 261487936, 261619648, 261750592, 261879872, 262011968,
-262143424, 262274752, 262404416, 262537024, 262667968, 262799296,
-262928704, 263061184, 263191744, 263322944, 263454656, 263585216,
-263716672, 263847872, 263978944, 264108608, 264241088, 264371648,
-264501184, 264632768, 264764096, 264895936, 265024576, 265158464,
-265287488, 265418432, 265550528, 265681216, 265813312, 265943488,
-266075968, 266206144, 266337728, 266468032, 266600384, 266731072,
-266862272, 266993344, 267124288, 267255616, 267386432, 267516992,
-267648704, 267777728, 267910592, 268040512, 268172096, 268302784,
-268435264, 268566208, 268696256, 268828096, 268959296, 269090368,
-269221312, 269352256, 269482688, 269614784, 269745856, 269876416,
-270007616, 270139328, 270270272, 270401216, 270531904, 270663616,
-270791744, 270924736, 271056832, 271186112, 271317184, 271449536,
-271580992, 271711936, 271843136, 271973056, 272105408, 272236352,
-272367296, 272498368, 272629568, 272759488, 272891456, 273022784,
-273153856, 273284672, 273415616, 273547072, 273677632, 273808448,
-273937088, 274071488, 274200896, 274332992, 274463296, 274595392,
-274726208, 274857536, 274988992, 275118656, 275250496, 275382208,
-275513024, 275643968, 275775296, 275906368, 276037184, 276167872,
-276297664, 276429376, 276560576, 276692672, 276822976, 276955072,
-277085632, 277216832, 277347008, 277478848, 277609664, 277740992,
-277868608, 278002624, 278134336, 278265536, 278395328, 278526784,
-278657728, 278789824, 278921152, 279052096, 279182912, 279313088,
-279443776, 279576256, 279706048, 279838528, 279969728, 280099648,
-280230976, 280361408, 280493632, 280622528, 280755392, 280887104,
-281018176, 281147968, 281278912, 281411392, 281542592, 281673152,
-281803712, 281935552, 282066496, 282197312, 282329024, 282458816,
-282590272, 282720832, 282853184, 282983744, 283115072, 283246144,
-283377344, 283508416, 283639744, 283770304, 283901504, 284032576,
-284163136, 284294848, 284426176, 284556992, 284687296, 284819264,
-284950208, 285081536]
+179568448, 179698496, 179830208, 180092608, 180223808, 180354752,
+180485696, 180617152, 180748096, 180877504, 181009984, 181139264,
+181272512, 181402688, 181532608, 181663168, 181795136, 181926592,
+182057536, 182190016, 182320192, 182451904, 182582336, 182713792,
+182843072, 182976064, 183107264, 183237056, 183368384, 183494848,
+183631424, 183762752, 183893824, 184024768, 184154816, 184286656,
+184417984, 184548928, 184680128, 184810816, 184941248, 185072704,
+185203904, 185335616, 185465408, 185596352, 185727296, 185859904,
+185989696, 186121664, 186252992, 186383552, 186514112, 186645952,
+186777152, 186907328, 187037504, 187170112, 187301824, 187429184,
+187562048, 187693504, 187825472, 187957184, 188087104, 188218304,
+188349376, 188481344, 188609728, 188743616, 188874304, 189005248,
+189136448, 189265088, 189396544, 189528128, 189660992, 189791936,
+189923264, 190054208, 190182848, 190315072, 190447424, 190577984,
+190709312, 190840768, 190971328, 191102656, 191233472, 191364032,
+191495872, 191626816, 191758016, 191888192, 192020288, 192148928,
+192282176, 192413504, 192542528, 192674752, 192805952, 192937792,
+193068608, 193198912, 193330496, 193462208, 193592384, 193723456,
+193854272, 193985984, 194116672, 194247232, 194379712, 194508352,
+194641856, 194772544, 194900672, 195035072, 195166016, 195296704,
+195428032, 195558592, 195690304, 195818176, 195952576, 196083392,
+196214336, 196345792, 196476736, 196607552, 196739008, 196869952,
+197000768, 197130688, 197262784, 197394368, 197523904, 197656384,
+197787584, 197916608, 198049472, 198180544, 198310208, 198442432,
+198573632, 198705088, 198834368, 198967232, 199097792, 199228352,
+199360192, 199491392, 199621696, 199751744, 199883968, 200014016,
+200146624, 200276672, 200408128, 200540096, 200671168, 200801984,
+200933312, 201062464, 201194944, 201326144, 201457472, 201588544,
+201719744, 201850816, 201981632, 202111552, 202244032, 202374464,
+202505152, 202636352, 202767808, 202898368, 203030336, 203159872,
+203292608, 203423296, 203553472, 203685824, 203816896, 203947712,
+204078272, 204208192, 204341056, 204472256, 204603328, 204733888,
+204864448, 204996544, 205125568, 205258304, 205388864, 205517632,
+205650112, 205782208, 205913536, 206044736, 206176192, 206307008,
+206434496, 206569024, 206700224, 206831168, 206961856, 207093056,
+207223616, 207355328, 207486784, 207616832, 207749056, 207879104,
+208010048, 208141888, 208273216, 208404032, 208534336, 208666048,
+208796864, 208927424, 209059264, 209189824, 209321792, 209451584,
+209582656, 209715136, 209845568, 209976896, 210106432, 210239296,
+210370112, 210501568, 210630976, 210763712, 210894272, 211024832,
+211156672, 211287616, 211418176, 211549376, 211679296, 211812032,
+211942592, 212074432, 212204864, 212334016, 212467648, 212597824,
+212727616, 212860352, 212991424, 213120832, 213253952, 213385024,
+213515584, 213645632, 213777728, 213909184, 214040128, 214170688,
+214302656, 214433728, 214564544, 214695232, 214826048, 214956992,
+215089088, 215219776, 215350592, 215482304, 215613248, 215743552,
+215874752, 216005312, 216137024, 216267328, 216399296, 216530752,
+216661696, 216790592, 216923968, 217054528, 217183168, 217316672,
+217448128, 217579072, 217709504, 217838912, 217972672, 218102848,
+218233024, 218364736, 218496832, 218627776, 218759104, 218888896,
+219021248, 219151936, 219281728, 219413056, 219545024, 219675968,
+219807296, 219938624, 220069312, 220200128, 220331456, 220461632,
+220592704, 220725184, 220855744, 220987072, 221117888, 221249216,
+221378368, 221510336, 221642048, 221772736, 221904832, 222031808,
+222166976, 222297536, 222428992, 222559936, 222690368, 222820672,
+222953152, 223083968, 223213376, 223345984, 223476928, 223608512,
+223738688, 223869376, 224001472, 224132672, 224262848, 224394944,
+224524864, 224657344, 224788288, 224919488, 225050432, 225181504,
+225312704, 225443776, 225574592, 225704768, 225834176, 225966784,
+226097216, 226229824, 226360384, 226491712, 226623424, 226754368,
+226885312, 227015104, 227147456, 227278528, 227409472, 227539904,
+227669696, 227802944, 227932352, 228065216, 228196288, 228326464,
+228457792, 228588736, 228720064, 228850112, 228981056, 229113152,
+229243328, 229375936, 229505344, 229636928, 229769152, 229894976,
+230030272, 230162368, 230292416, 230424512, 230553152, 230684864,
+230816704, 230948416, 231079616, 231210944, 231342016, 231472448,
+231603776, 231733952, 231866176, 231996736, 232127296, 232259392,
+232388672, 232521664, 232652608, 232782272, 232914496, 233043904,
+233175616, 233306816, 233438528, 233569984, 233699776, 233830592,
+233962688, 234092224, 234221888, 234353984, 234485312, 234618304,
+234749888, 234880832, 235011776, 235142464, 235274048, 235403456,
+235535936, 235667392, 235797568, 235928768, 236057152, 236190272,
+236322752, 236453312, 236583616, 236715712, 236846528, 236976448,
+237108544, 237239104, 237371072, 237501632, 237630784, 237764416,
+237895232, 238026688, 238157632, 238286912, 238419392, 238548032,
+238681024, 238812608, 238941632, 239075008, 239206336, 239335232,
+239466944, 239599168, 239730496, 239861312, 239992384, 240122816,
+240254656, 240385856, 240516928, 240647872, 240779072, 240909632,
+241040704, 241171904, 241302848, 241433408, 241565248, 241696192,
+241825984, 241958848, 242088256, 242220224, 242352064, 242481856,
+242611648, 242744896, 242876224, 243005632, 243138496, 243268672,
+243400384, 243531712, 243662656, 243793856, 243924544, 244054592,
+244187072, 244316608, 244448704, 244580032, 244710976, 244841536,
+244972864, 245104448, 245233984, 245365312, 245497792, 245628736,
+245759936, 245889856, 246021056, 246152512, 246284224, 246415168,
+246545344, 246675904, 246808384, 246939584, 247070144, 247199552,
+247331648, 247463872, 247593536, 247726016, 247857088, 247987648,
+248116928, 248249536, 248380736, 248512064, 248643008, 248773312,
+248901056, 249036608, 249167552, 249298624, 249429184, 249560512,
+249692096, 249822784, 249954112, 250085312, 250215488, 250345792,
+250478528, 250608704, 250739264, 250870976, 251002816, 251133632,
+251263552, 251395136, 251523904, 251657792, 251789248, 251919424,
+252051392, 252182464, 252313408, 252444224, 252575552, 252706624,
+252836032, 252968512, 253099712, 253227584, 253361728, 253493056,
+253623488, 253754432, 253885504, 254017216, 254148032, 254279488,
+254410432, 254541376, 254672576, 254803264, 254933824, 255065792,
+255196736, 255326528, 255458752, 255589952, 255721408, 255851072,
+255983296, 256114624, 256244416, 256374208, 256507712, 256636096,
+256768832, 256900544, 257031616, 257162176, 257294272, 257424448,
+257555776, 257686976, 257818432, 257949632, 258079552, 258211136,
+258342464, 258473408, 258603712, 258734656, 258867008, 258996544,
+259127744, 259260224, 259391296, 259522112, 259651904, 259784384,
+259915328, 260045888, 260175424, 260308544, 260438336, 260570944,
+260700992, 260832448, 260963776, 261092672, 261226304, 261356864,
+261487936, 261619648, 261750592, 261879872, 262011968, 262143424,
+262274752, 262404416, 262537024, 262667968, 262799296, 262928704,
+263061184, 263191744, 263322944, 263454656, 263585216, 263716672,
+263847872, 263978944, 264108608, 264241088, 264371648, 264501184,
+264632768, 264764096, 264895936, 265024576, 265158464, 265287488,
+265418432, 265550528, 265681216, 265813312, 265943488, 266075968,
+266206144, 266337728, 266468032, 266600384, 266731072, 266862272,
+266993344, 267124288, 267255616, 267386432, 267516992, 267648704,
+267777728, 267910592, 268040512, 268172096, 268302784, 268435264,
+268566208, 268696256, 268828096, 268959296, 269090368, 269221312,
+269352256, 269482688, 269614784, 269745856, 269876416, 270007616,
+270139328, 270270272, 270401216, 270531904, 270663616, 270791744,
+270924736, 271056832, 271186112, 271317184, 271449536, 271580992,
+271711936, 271843136, 271973056, 272105408, 272236352, 272367296,
+272498368, 272629568, 272759488, 272891456, 273022784, 273153856,
+273284672, 273415616, 273547072, 273677632, 273808448, 273937088,
+274071488, 274200896, 274332992, 274463296, 274595392, 274726208,
+274857536, 274988992, 275118656, 275250496, 275382208, 275513024,
+275643968, 275775296, 275906368, 276037184, 276167872, 276297664,
+276429376, 276560576, 276692672, 276822976, 276955072, 277085632,
+277216832, 277347008, 277478848, 277609664, 277740992, 277868608,
+278002624, 278134336, 278265536, 278395328, 278526784, 278657728,
+278789824, 278921152, 279052096, 279182912, 279313088, 279443776,
+279576256, 279706048, 279838528, 279969728, 280099648, 280230976,
+280361408, 280493632, 280622528, 280755392, 280887104, 281018176,
+281147968, 281278912, 281411392, 281542592, 281673152, 281803712,
+281935552, 282066496, 282197312, 282329024, 282458816, 282590272,
+282720832, 282853184, 282983744, 283115072, 283246144, 283377344,
+283508416, 283639744, 283770304, 283901504, 284032576, 284163136,
+284294848, 284426176, 284556992, 284687296, 284819264, 284950208,
+285081536]
```
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
index 374f5830ef7..e618c3cda23 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
@@ -8,7 +8,7 @@ lang: it
-Il proof-of-work non è più alla base del meccanismo di consenso di Ethereum, a significare che il mining è stato disattivato. Invece, Ethereum, è protetto dai validatori che mettono ETH in staking. Puoi iniziare oggi a mettere i tuoi ETH in staking. Leggi di più su La Fusione, il proof-of-stake e lo staking. Questa pagina è per solo interesse storico.
+Il Proof of Work non è più il meccanismo di consenso alla base di Ethereum, il che significa che il mining è stato disattivato. Invece, Ethereum è protetto dai validatori che mettono ETH in staking. Puoi iniziare oggi a mettere i tuoi ETH in staking. Leggi di più su La Fusione, il proof-of-stake e lo staking. Questa pagina è solo per interesse storico.
@@ -17,15 +17,15 @@ Il mining di Ethereum usava un algoritmo noto come Ethash. L'idea fondamentale d
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, ti consigliamo prima di leggere sul [consenso proof-of-work](/developers/docs/consensus-mechanisms/pow) e sul [mining](/developers/docs/consensus-mechanisms/pow/mining).
+Per comprendere meglio questa pagina, ti suggeriamo di leggere prima del [consenso proof-of-work](/developers/docs/consensus-mechanisms/pow) e del [mining](/developers/docs/consensus-mechanisms/pow/mining).
## Dagger Hashimoto {#dagger-hashimoto}
Dagger Hashimoto era un algoritmo di ricerca precursore del mining di Ethereum, sostituito da Ethash. Era un amalgama di due algoritmi differenti: Dagger e Hashimoto. È sempre e solo stato un'implementazione di ricerca e fu superato da Ethash prima del lancio della Rete Principale di Ethereum.
-[Dagger](http://www.hashcash.org/papers/dagger.html) prevede la generazione di un [Grafico Aciclico Diretto](https://en.wikipedia.org/wiki/Directed_acyclic_graph), porzioni casuali del quale ricevono un hashing insieme. Il principio fondamentale è che ogni nonce richiede solo una piccola porzione di un grande albero di dati totali. Ricalcolare l'albero secondario per ogni nonce è proibitivo per il mining, da cui l'esigenza di memorizzare l'albero, invece, va bene per verificare un singolo nonce. Dagger è stato progettato per essere un'alternativa agli algoritmi esistenti come Scrypt, che sono gravosi per la memoria (memory-hard) ma difficili da verificare all'aumentare dell'uso della memoria verso livelli veramente sicuri. Dagger era però vulnerabile all'accelerazione dell'hardware con memoria condiviso ed è stato abbandonato a favore di altre vie di ricerca.
+[Dagger](http://www.hashcash.org/papers/dagger.html) comporta la generazione di un [Grafo Aciclico Diretto](https://en.wikipedia.org/wiki/Directed_acyclic_graph), le cui sezioni casuali vengono hashate insieme. Il principio fondamentale è che ogni nonce richiede solo una piccola porzione di un grande albero di dati totali. Ricalcolare l'albero secondario per ogni nonce è proibitivo per il mining, da cui l'esigenza di memorizzare l'albero, invece, va bene per verificare un singolo nonce. Dagger è stato progettato per essere un'alternativa agli algoritmi esistenti come Scrypt, che sono gravosi per la memoria (memory-hard) ma difficili da verificare all'aumentare dell'uso della memoria verso livelli veramente sicuri. Dagger era però vulnerabile all'accelerazione dell'hardware con memoria condiviso ed è stato abbandonato a favore di altre vie di ricerca.
-[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) è un algoritmo che aggiunge resistenza ASIC, essendo vincolato da aspetti I/O (cioè le letture di memoria rappresentano il fattore limitante nel processo di mining). La teoria è che vi sia più disponibilità di RAM che di calcolo: sono già stati usati miliardi di dollari in ricerca per l'ottimizzazione della RAM per diversi scenari d'uso, che spesso coinvolgono schemi d'accesso semi-casuale (da cui "memoria d'accesso casuale", Random Access Memory). Di conseguenza, è probabile che la RAM esistente sia abbastanza vicina all'ottimale per valutare l'algoritmo. Hashimoto usa la blockchain come una fonte di dati, perché soddisfa simultaneamente i punti (1) e (3) di cui sopra.
+[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) è un algoritmo che aggiunge resistenza ASIC essendo vincolato da aspetti I/O (cioè, le letture di memoria rappresentano il fattore limitante nel processo di mining). La teoria è che vi sia più disponibilità di RAM che di calcolo: sono già stati usati miliardi di dollari in ricerca per l'ottimizzazione della RAM per diversi scenari d'uso, che spesso coinvolgono schemi d'accesso semi-casuale (da cui "memoria d'accesso casuale", Random Access Memory). Di conseguenza, è probabile che la RAM esistente sia abbastanza vicina all'ottimale per valutare l'algoritmo. Hashimoto usa la blockchain come una fonte di dati, perché soddisfa simultaneamente i punti (1) e (3) di cui sopra.
Dagger-Hashimoto usava delle versioni modificate degli algoritmi di Dagger e Hashimoto. La differenza tra Dagger Hashimoto e Hashimoto è che, anziché usare la blockchain come una fonte di dati, Dagger Hashimoto usa una serie di dati generata e personalizzata, che si aggiorna a seconda dei dati del blocco ogni N blocchi. La serie di dati è generata usando l'algoritmo di Dagger, che consente di calcolare efficientemente una sotto-serie specifica a ogni nonce per l'algoritmo di verifica del client leggero. La differenza tra Dagger Hashimoto e Dagger è che, a differenza del Dagger originale, il dataset usato per interrogare il blocco è semi-permanente, in quanto viene aggiornato solo occasionalmente (es. una volta a settimana). Questo significa che la porzione dello sforzo per generare il dataset è prossima allo zero, e diventano quindi trascurabili gli argomenti di Sergio Lerner riguardanti le velocizzazioni della memoria condivisa.
@@ -33,10 +33,10 @@ Maggiori informazioni su [Dagger-Hashimoto](/developers/docs/consensus-mechanism
## Ethash {#ethash}
-Ethash era l'algoritmo di mining che era effettiamente usato sulla vera Rete Principale di Ethereum sotto l'ora deprecata architettura del proof-of-work. Ethash in realtà è un nuovo nome assegnato a una versione specifica di Dagger-Hashimoto dopo un aggiornamento significativo dell'algoritmo, che comunque eredita i principi fondamentali del suo predecessore. La Rete Principale di Ethereum ha sempre e solo usato Ethash; Dagger Hashimoto era una versione R&D dell'algoritmo di mining che fu superata prima che il mining fosse avviato sulla Rete Principale di Ethereum.
+Ethash era l'algoritmo di mining che era effettiamente usato sulla vera Rete Principale di Ethereum sotto l'ora deprecata architettura del proof-of-work. Ethash in realtà è un nuovo nome assegnato a una versione specifica di Dagger-Hashimoto dopo un aggiornamento significativo dell'algoritmo, che comunque eredita i principi fondamentali del suo predecessore. La Rete Principale di Ethereum ha sempre e solo usato Ethash. Dagger Hashimoto era una versione di R&S dell'algoritmo di mining che è stata superata prima che il mining iniziasse sulla Rete Principale di Ethereum.
-[Di più su Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
+[Maggiori informazioni su Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
## Letture consigliate {#further-reading}
-_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
diff --git a/public/content/translations/it/developers/docs/data-and-analytics/index.md b/public/content/translations/it/developers/docs/data-and-analytics/index.md
index 326c2658b65..2a913ee8348 100644
--- a/public/content/translations/it/developers/docs/data-and-analytics/index.md
+++ b/public/content/translations/it/developers/docs/data-and-analytics/index.md
@@ -32,20 +32,21 @@ Usando [GraphQL](https://graphql.org/), gli sviluppatori possono interrogare una
La [diversità dei client](/developers/docs/nodes-and-clients/client-diversity/) è importante per la salute complessiva della rete di Ethereum, poiché fornisce resilienza a bug ed exploit. Attualmente esistono vari pannelli di controllo della diversità del client, tra cui [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) ed [Ethernodes](https://ethernodes.org/).
-## Dune Analytics {#dune-analytics}
+## Dune Analytics {#client-diversity}
[Dune Analytics](https://dune.com/) pre-elabora i dati della blockchain nelle tabelle del database relazionale (DuneSQL), consente agli utenti di richiedere i dati della blockchain utilizzando SQL e crea pannelli di controllo basati sui risultati della richiesta. I dati sulla catena sono organizzati in 4 tabelle grezze: `blocks`, `transactions`, `logs` (di eventi) e `traces` (di chiamate). I contratti e protocolli popolari sono stati decodificati e ognuno ha la propria serie di tabelle di eventi e chiamate. Queste tabelle di eventi e chiamate sono ulteriormente elaborate e organizzate in tabelle di astrazione secondo il tipo di protocolli, ad esempio dex, lending, stablecoins, ecc.
-## Rete di SubQuery {#subquery-network}
+## Rete di SubQuery {#dune-analytics}
[SubQuery](https://subquery.network/) è un indicizzatore di dati leader del settore, che fornisce agli sviluppatori API veloci, affidabili, decentralizzate e personalizzate per i loro progetti in Web3. SubQuery emancipa gli sviluppatori da oltre 165 ecosistemi (incluso Ethereum) con dati indicizzati ricchi, per creare esperienze intuitive e immersive per i propri utenti. La Rete di SubQuery alimenta le tue inarrestabili app con una rete resiliente e un'infrastruttura decentralizzata. Utilizza gli strumenti per sviluppatori di blockchain di SubQuery per creare le applicazioni Web3 del futuro, senza dover dedicare tempo a sviluppare un backend personalizzato per le attività di elaborazione dei dati.
Per iniziare, visita la [guida rapida per principianti di Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) per iniziare a indicizzare i dati della blockchain di Ethereum in pochi minuti in un ambiente locale di Docker per i test prima di distribuire il tuo progetto su un [servizio gestito da SubQuery](https://managedservice.subquery.network/) o su una [rete decentralizzata di SubQuery](https://app.subquery.network/dashboard).
-## Ethernow - Programma dei dati del Mempool {#ethernow}
+## Ethernow - Programma dei dati del Mempool {#sqd}
+
[Blocknative](https://www.blocknative.com/) fornisce l'accesso aperto al suo [archivio dei dati del mempool](https://www.ethernow.xyz/mempool-data-archive) storico di Ethereum. Questo consente ai ricercatori e ai progetti della community di esplorare il livello pre-catena della Rete Principale di Ethereum. La serie di dati è mantenuta attivamente e rappresenta il registro storico più completo degli eventi di transazione del mempool nell'ecosistema di Ethereum. Maggiori informazioni su [Ethernow](https://www.ethernow.xyz/).
-## Letture consigliate {#further-reading}
+## Letture consigliate {#subquery-network}
- [Panoramica della rete Graph](https://thegraph.com/docs/en/about/)
- [GraphQL Playground](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current)
diff --git a/public/content/translations/it/developers/docs/data-availability/index.md b/public/content/translations/it/developers/docs/data-availability/index.md
index 7b1bb070581..369d6d81788 100644
--- a/public/content/translations/it/developers/docs/data-availability/index.md
+++ b/public/content/translations/it/developers/docs/data-availability/index.md
@@ -1,6 +1,6 @@
---
-title: Disponibilità dei dati
-description: Una panoramica dei problemi e delle soluzioni relative alla disponibilità dei dati in Ethereum
+title: "Disponibilità dei dati"
+description: "Una panoramica dei problemi e delle soluzioni relative alla disponibilità dei dati in Ethereum"
lang: it
---
diff --git a/public/content/translations/it/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/it/developers/docs/design-and-ux/heuristics-for-web3/index.md
index 2f0aaa2df51..f89f227fde2 100644
--- a/public/content/translations/it/developers/docs/design-and-ux/heuristics-for-web3/index.md
+++ b/public/content/translations/it/developers/docs/design-and-ux/heuristics-for-web3/index.md
@@ -1,6 +1,6 @@
---
title: 7 euristiche per la progettazione di interfacce Web3
-description: Principi per migliorare l'usabilità del Web3
+description: "Principi per migliorare l'usabilità del Web3"
lang: it
---
diff --git a/public/content/translations/it/developers/docs/design-and-ux/index.md b/public/content/translations/it/developers/docs/design-and-ux/index.md
index 40ba1cd7f16..aa157d71d20 100644
--- a/public/content/translations/it/developers/docs/design-and-ux/index.md
+++ b/public/content/translations/it/developers/docs/design-and-ux/index.md
@@ -78,7 +78,7 @@ Partecipate ad organizzazioni professionali guidate dalla community o unitevi a
- [We3.co](https://we3.co/)
- [Openux.xyz](https://openux.xyz/)
-## Sistemi di progettazione {#design-systems}
+## Sistemi di progettazione {#design-systems-and-resources}
- [Progettazione di Optimism](https://www.figma.com/@optimism) (Figma)
- [Sistema di progettazione di Ethereum.org](https://www.figma.com/@ethdotorg) (Figma)
diff --git a/public/content/translations/it/developers/docs/evm/index.md b/public/content/translations/it/developers/docs/evm/index.md
index c1ae60e919f..50268badf5a 100644
--- a/public/content/translations/it/developers/docs/evm/index.md
+++ b/public/content/translations/it/developers/docs/evm/index.md
@@ -4,7 +4,7 @@ description: Un'introduzione alla Macchina Virtuale di Ethereum e a come si rela
lang: it
---
-La Macchina Virtuale di Ethereum (EVM) è un ambiente virtuale decentralizzato che esegue il codice con coerenza e sicurezza su tutti i nodi di Ethereum. I nodi eseguono l'EVM per eseguire i contratti intelligenti, utilizzando il "[gas](/gas/)" per misurare lo sforzo di calcolo necessario per le [operazioni](/developers/docs/evm/opcodes/), assicurando un'efficace allocazione delle risorse e la sicurezza della rete.
+La Macchina Virtuale di Ethereum (EVM) è un ambiente virtuale decentralizzato che esegue il codice con coerenza e sicurezza su tutti i nodi di Ethereum. I nodi eseguono l'EVM per eseguire i contratti intelligenti, utilizzando il "[gas](/developers/docs/gas/)" per misurare lo sforzo di calcolo necessario per le [operazioni](/developers/docs/evm/opcodes/), assicurando un'efficace allocazione delle risorse e la sicurezza della rete.
## Prerequisiti {#prerequisites}
diff --git a/public/content/translations/it/developers/docs/intro-to-ethereum/index.md b/public/content/translations/it/developers/docs/intro-to-ethereum/index.md
index 26d4c9ffb8e..da74e7a90f2 100644
--- a/public/content/translations/it/developers/docs/intro-to-ethereum/index.md
+++ b/public/content/translations/it/developers/docs/intro-to-ethereum/index.md
@@ -111,6 +111,6 @@ Uno snippet di codice riutilizzabile (programma) che uno sviluppatore pubblica n
_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
-## Tutorial correlati {#related-tutorials}
+## Tutorial correlati {#visual-learner}
- [Una guida per sviluppatori a Ethereum, parte 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Un'esplorazione di Ethereum pensata per i principianti usando Python e web3.py_
diff --git a/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md
index 114400531ff..0fce61908eb 100644
--- a/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md
+++ b/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md
@@ -82,7 +82,7 @@ La presenza di più implementazioni client indipendenti aumenta la resilienza e
Se un client presenta problemi o vulnerabilità, gli altri client possono continuare a funzionare senza problemi, evitando un punto di errore singolo. Inoltre, le diverse implementazioni dei clienti favoriscono l'innovazione e la concorrenza, promuovendo miglioramenti e riducendo il rischio di monopolio all'interno dell'ecosistema.
-## Letture consigliate {#futher-reading}
+## Letture consigliate {#further-reading}
- [La Rete Portal (Piper Merriam al Devcon di Bogotà)](https://www.youtube.com/watch?v=0stc9jnQLXA).
- [Discord della Rete Portal](https://discord.gg/CFFnmE7Hbs)
diff --git a/public/content/translations/it/developers/docs/networks/index.md b/public/content/translations/it/developers/docs/networks/index.md
index 08b89ae21e4..e2f09ac32c0 100644
--- a/public/content/translations/it/developers/docs/networks/index.md
+++ b/public/content/translations/it/developers/docs/networks/index.md
@@ -84,11 +84,11 @@ Hoodi è una rete di prova per testare la convalida e lo staking. La rete Hoodi
Per lanciare un Validatore sulla rete di prova Hoodi, usa il [launchpad di Hoodi](https://hoodi.launchpad.ethereum.org/en/).
-### Rete di prova del livello 2 {#layer-2-testnets}
+### Rete di prova del livello 2 {#ephemery}
[Livello 2 (L2)](/layer-2/) è un termine collettivo per descrivere un insieme specifico di soluzioni di ridimensionamento di Ethereum. Un livello 2 è una blockchain separata che estende Ethereum ed eredita le garanzie di sicurezza di Ethereum. Solitamente le reti di prova di Livello 2 sono strettamente accoppiate alle reti di prova pubbliche di Ethereum.
-#### Arbitrum Sepolia {#arbitrum-sepolia}
+#### Arbitrum Sepolia {#holesky}
Una rete di prova per [Arbitrum](https://arbitrum.io/).
@@ -97,7 +97,7 @@ Una rete di prova per [Arbitrum](https://arbitrum.io/).
- [Faucet Chainlink](https://faucets.chain.link/arbitrum-sepolia)
- [Faucet Alchemy](https://www.alchemy.com/faucets/arbitrum-sepolia)
-#### Optimistic Sepolia {#optimistic-sepolia}
+#### Optimistic Sepolia {#layer-2-testnets}
Una rete di prova per [Optimism](https://www.optimism.io/).
@@ -106,7 +106,7 @@ Una rete di prova per [Optimism](https://www.optimism.io/).
- [Faucet Chainlink](https://faucets.chain.link/optimism-sepolia)
- [Faucet Alchemy](https://www.alchemy.com/faucets/optimism-sepolia)
-#### Starknet Sepolia {#starknet-sepolia}
+#### Starknet Sepolia {#arbitrum-sepolia}
Una rete di prova per [Starknet](https://www.starknet.io).
@@ -114,28 +114,28 @@ Una rete di prova per [Starknet](https://www.starknet.io).
- [Faucet Alchemy](https://www.alchemy.com/faucets/starknet-sepolia)
-## Reti private {#private-networks}
+## Reti private {#optimistic-sepolia}
Una rete Ethereum è una rete privata se i relativi nodi non sono connessi a una rete pubblica (ossia Rete principale o una rete di prova). In questo contesto, privato significa solo riservato o isolato, e non protetto o sicuro.
-### Reti di sviluppo {#development-networks}
+### Reti di sviluppo {#starknet-sepolia}
Per sviluppare un'applicazione Ethereum, è consigliabile eseguirla prima su una rete privata per vedere come funziona prima di distribuirla. Come quando si crea un server locale sul computer per lo sviluppo web, è possibile creare un'istanza locale della blockchain per testare una dapp. Questo offre un'iterazione molto più veloce rispetto a una rete di prova pubblica.
Ci sono progetti e strumenti dedicati a questo scopo. Scopri di più sulle [reti di sviluppo](/developers/docs/development-networks/).
-### Reti di consorzio {#consortium-networks}
+### Reti di consorzio {#private-networks}
Il processo di consenso è controllato da una serie predefinita di nodi considerati attendibili. Un esempio può essere una rete privata di istituti accademici noti, dove ogni istituto controlla un singolo nodo e i blocchi vengono convalidati da una soglia di firmatari all'interno della rete.
Se una rete Ethereum pubblica è come la rete Internet pubblica, una rete di consorzio è come una Intranet privata.
-## Strumenti correlati {#related-tools}
+## Strumenti correlati {#development-networks}
- [Chainlist](https://chainlist.org/) _Elenco di reti EVM per connettere portafogli e fornitori all'ID della Catena e ID di Rete appropriati._
- [Catene basate su EVM](https://github.com/ethereum-lists/chains) _Repository di GitHub di metadati della catena che alimentano Chainlist._
-## Letture consigliate {#further-reading}
+## Letture consigliate {#consortium-networks}
- [Proposta: ciclo di vita prevedibile delle reti di prova di Ethereum](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17)
- [L'evoluzione delle reti di prova di Ethereum](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/)
diff --git a/public/content/translations/it/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/it/developers/docs/nodes-and-clients/client-diversity/index.md
index 06dc895256d..63192bb54f0 100644
--- a/public/content/translations/it/developers/docs/nodes-and-clients/client-diversity/index.md
+++ b/public/content/translations/it/developers/docs/nodes-and-clients/client-diversity/index.md
@@ -1,6 +1,6 @@
---
-title: Diversità dei client
-description: Una spiegazione generica dell'importanza della diversità di client di Ethereum.
+title: "Diversità dei client"
+description: "Una spiegazione generica dell'importanza della diversità di client di Ethereum."
lang: it
sidebarDepth: 2
---
@@ -49,15 +49,15 @@ I dati del livello di esecuzione sono stati ottenuti da [Ethernodes](https://eth
I dati di diversità dei client aggiornati per il livello del consenso sono ora disponibili su [clientdiversity.org](https://clientdiversity.org/).
-## Livello di esecuzione {#execution-layer}
+## Livello di esecuzione {#execution-clients-breakdown}
Finora, la conversazione sulla diversità dei client si è concentrata sul livello del consenso. Tuttavia, il client d'esecuzione [Geth](https://geth.ethereum.org) rappresenta correntemente circa 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 {#use-minority-client}
+## Usare un client di minoranza {#consensus-clients-breakdown}
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 {#execution-clients}
+### Client di esecuzione {#execution-layer}
[Besu](https://www.hyperledger.org/use/besu)
@@ -67,7 +67,7 @@ Per "indirizzare" la diversità dei client non basta che i singoli utenti scelga
[Go-Ethereum](https://geth.ethereum.org/)
-### Client di consenso {#consensus-clients}
+### Client di consenso {#use-minority-client}
[Nimbus](https://nimbus.team/)
@@ -83,7 +83,7 @@ Per "indirizzare" la diversità dei client non basta che i singoli utenti scelga
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](https://clientdiversity.org/).
-## Pannelli di controllo sulla diversità dei client {#client-diversity-dashboards}
+## Pannelli di controllo sulla diversità dei client {#execution-clients}
Diversi pannelli di controllo forniscono statistiche sulla diversità dei client in tempo reale per il livello d'esecuzione e di consenso.
@@ -95,7 +95,7 @@ Diversi pannelli di controllo forniscono statistiche sulla diversità dei client
- [supermajority.info](https://supermajority.info//)
- [Ethernodes](https://ethernodes.org/)
-## Letture consigliate {#further-reading}
+## Letture consigliate {#consensus-clients}
- [Diversità dei client sul livello di consenso di Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA)
- [Fusione di Ethereum: esegui il client di maggioranza a tuo rischio!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest, 24 marzo 2022_
@@ -105,7 +105,7 @@ Diversi pannelli di controllo forniscono statistiche sulla diversità dei client
- [Diversità di Ethereum e come risolverla (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU)
- [clientdiversity.org](https://clientdiversity.org/)
-## Argomenti correlati {#related-topics}
+## Argomenti correlati {#client-diversity-dashboards}
- [Eseguire un nodo di Ethereum](/run-a-node/)
- [Nodi e client](/developers/docs/nodes-and-clients/)
diff --git a/public/content/translations/it/developers/docs/nodes-and-clients/index.md b/public/content/translations/it/developers/docs/nodes-and-clients/index.md
index 98eb12ebed7..74f6e768d3f 100644
--- a/public/content/translations/it/developers/docs/nodes-and-clients/index.md
+++ b/public/content/translations/it/developers/docs/nodes-and-clients/index.md
@@ -1,6 +1,6 @@
---
title: Nodi e client
-description: Panoramica dei nodi Ethereum e del software client, come configurare un nodo e perché farlo.
+description: "Panoramica dei nodi Ethereum e del software client, come configurare un nodo e perché farlo."
lang: it
sidebarDepth: 2
---
diff --git a/public/content/translations/it/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/it/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
index 8a29e3a51a0..e83c721403d 100644
--- a/public/content/translations/it/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
+++ b/public/content/translations/it/developers/docs/nodes-and-clients/nodes-as-a-service/index.md
@@ -1,6 +1,6 @@
---
title: Nodi come servizio
-description: Panoramica entry-level dei servizi dei nodi, dei pro e dei contro, e dei fornitori più diffusi.
+description: "Panoramica entry-level dei servizi dei nodi, dei pro e dei contro, e dei fornitori più diffusi."
lang: it
sidebarDepth: 2
---
diff --git a/public/content/translations/it/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/it/developers/docs/nodes-and-clients/run-a-node/index.md
index e3d8b368210..eda86442bcb 100644
--- a/public/content/translations/it/developers/docs/nodes-and-clients/run-a-node/index.md
+++ b/public/content/translations/it/developers/docs/nodes-and-clients/run-a-node/index.md
@@ -234,7 +234,7 @@ Questa sezione ti guiderà nell'avvio dei client di esecuzione. Serve solo da es
Ricordati che questo è solo un esempio di base, tutte le altre impostazioni saranno predefinite. Presta attenzione alla documentazione di ogni client per conoscere i valori predefiniti, le impostazioni e le funzionalità. Per ulteriori funzionalità, ad esempio per eseguire i validatori, per il monitoraggio, ecc., fai riferimento alla documentazione del client specifico.
-> Nota che i backslash `\` negli esempi servono solo a scopi di formattazione; i flag di configurazione sono definibili in una singola riga.
+> Nota che i backslash `` negli esempi servono solo a scopi di formattazione; i flag di configurazione sono definibili in una singola riga.
##### Eseguire Besu
diff --git a/public/content/translations/it/developers/docs/oracles/index.md b/public/content/translations/it/developers/docs/oracles/index.md
index 3232aa07b4c..bac34bad496 100644
--- a/public/content/translations/it/developers/docs/oracles/index.md
+++ b/public/content/translations/it/developers/docs/oracles/index.md
@@ -1,6 +1,6 @@
---
title: Oracoli
-description: Gli oracoli forniscono ai contratti intelligenti di Ethereum l'accesso ai dati del mondo reale, sbloccando più casi d'uso e maggiore valore per gli utenti.
+description: "Gli oracoli forniscono ai contratti intelligenti di Ethereum l'accesso ai dati del mondo reale, sbloccando più casi d'uso e maggiore valore per gli utenti."
lang: it
---
diff --git a/public/content/translations/it/developers/docs/programming-languages/javascript/index.md b/public/content/translations/it/developers/docs/programming-languages/javascript/index.md
index e6e69f0248c..81a821658c4 100644
--- a/public/content/translations/it/developers/docs/programming-languages/javascript/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/javascript/index.md
@@ -32,7 +32,7 @@ Di più sui [contratti intelligenti](/developers/docs/smart-contracts/).
### La macchina virtuale Ethereum {#the-ethereum-virtual-machine}
-Esiste un'implementazione JavaScript della [macchina virtuale di Ethereum](/en/developers/docs/evm/), che supporta le regole più recenti relative alle diramazioni della rete. Le regole relative alle diramazioni si riferiscono alle modifiche apportate alla macchina virtuale di Ethereum (EVM) a seguito di upgrade pianificati.
+Esiste un'implementazione JavaScript della [macchina virtuale di Ethereum](/developers/docs/evm/), che supporta le regole più recenti relative alle diramazioni della rete. Le regole relative alle diramazioni si riferiscono alle modifiche apportate alla macchina virtuale di Ethereum (EVM) a seguito di upgrade pianificati.
È suddivisa in vari pacchetti JavaScript che puoi leggere per comprendere meglio:
diff --git a/public/content/translations/it/developers/docs/scaling/index.md b/public/content/translations/it/developers/docs/scaling/index.md
index 6fd3b842b9b..97da0bd92d5 100644
--- a/public/content/translations/it/developers/docs/scaling/index.md
+++ b/public/content/translations/it/developers/docs/scaling/index.md
@@ -1,6 +1,6 @@
---
-title: Scalabilità
-description: Introduzione alle diverse opzioni di scalabilità attualmente in fase di sviluppo da parte della community Ethereum.
+title: "Scalabilità"
+description: "Introduzione alle diverse opzioni di scalabilità attualmente in fase di sviluppo da parte della community Ethereum."
lang: it
sidebarDepth: 3
---
@@ -19,7 +19,7 @@ A livello concettuale, per prima cosa occorre distinguere tra scalabilità on-ch
Dovresti avere una buona conoscenza di tutti gli argomenti fondamentali. L'implementazione di soluzioni di scalabilità è un argomento avanzato, in quanto la tecnologia è meno testata sul campo e continua ad essere oggetto di ricerca e sviluppo.
-## Scalabilità on-chain {#on-chain-scaling}
+## Scalabilità on-chain {#onchain-scaling}
La scalabilità on-chain richiede modifiche al protocollo Ethereum ([rete principale](/glossary/#mainnet) di livello 1). Per molto tempo si è pensato che lo sharding della blockchain avrebbe ridimensionato Ethereum. Questo avrebbe coinvolto la divisione della blockchain in pezzi discreti (shard), che sarebbero stati verificati da sottoinsiemi dei validatori. Tuttavia, il ridimensionamento dai rollup di livello 2 ha preso il controllo come la tecnica di ridimensionamento principale. Questa è supportata dall'aggiunta di una nuova e più economica forma di dati connessi ai blocchi di Ethereum, progettati specificamente per rendere i rollup economici per gli utenti.
@@ -27,7 +27,7 @@ La scalabilità on-chain richiede modifiche al protocollo Ethereum ([rete princi
Lo sharding è il processo di frammentazione di un database. Sottoinsiemi di validatori sarebbero responsabili dei singoli shard invece di tenere traccia di tutta la rete Ethereum. Un tempo destinato a essere trasferito verso il proof-of-stake prima della Fusione, lo sharding è stato per molto tempo sulla [tabella di marcia](/roadmap/) di Ethereum. Tuttavia, il rapido sviluppo dei [rollup di livello 2](#layer-2-scaling) e l'invenzione del [Dansharding](/roadmap/danksharding) (aggiunta di blob di dati di rollup ai blocchi di Ethereum che possono essere verificati in modo molto efficiente dai validatori), ha portato la community di Ethereum a preferire il ridimensionamento incentrato sui rollup piuttosto che sullo sharding. Ciò aiuterà anche a mantenere più semplice la logica del consenso di Ethereum.
-## Scalabilità off-chain {#off-chain-scaling}
+## Scalabilità off-chain {#offchain-scaling}
Le soluzioni off-chain sono implementate separatamente dalla Rete principale di livello 1, e non richiedono alcuna modifica al protocollo Ethereum esistente. Alcune soluzioni, note come soluzioni di "livello 2", derivano la loro sicurezza direttamente dal consenso del livello 1 di Ethereum, come i [rollup ottimistici](/developers/docs/scaling/optimistic-rollups/), i [rollup a conoscenza zero](/developers/docs/scaling/zk-rollups/) o i [canali di stato](/developers/docs/scaling/state-channels/). Altre soluzioni comportano la creazione di nuove catene in varie forme, che derivano la propria sicurezza separatamente dalla Rete principale, come le [catene secondarie](#sidechains), i [validium](#validium) o le [catene Plasma](#plasma). Queste soluzioni comunicano con la Rete principale, ma derivano la loro sicurezza in modo diverso per raggiungere una serie di obiettivi.
diff --git a/public/content/translations/it/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/it/developers/docs/scaling/optimistic-rollups/index.md
index 65fc1e05800..ea335814158 100644
--- a/public/content/translations/it/developers/docs/scaling/optimistic-rollups/index.md
+++ b/public/content/translations/it/developers/docs/scaling/optimistic-rollups/index.md
@@ -28,7 +28,7 @@ Se il batch del rollup non viene contestata (cioè, tutte le transazioni sono es
## Come interagiscono i rollup ottimistici con Ethereum? {#optimistic-rollups-and-Ethereum}
-I rollup ottimistici sono [soluzioni di ridimensionamento off-chain](/developers/docs/scaling/#off-chain-scaling) create per funzionare su Ethereum. Ogni rollup ottimistico è gestito da una serie di contratti intelligenti distribuiti sulla rete di Ethereum. I rollup ottimistici elaborano le transazioni al di fuori della catena principale di Ethereum, ma pubblicano le transazioni off-chain (in batch) in un contratto di rollup on-chain. Come la blockchain di Ethereum, questo registro delle transazioni è immutabile e forma la "catena di rollup ottimistico".
+I rollup ottimistici sono [soluzioni di ridimensionamento off-chain](/developers/docs/scaling/#offchain-scaling) create per funzionare su Ethereum. Ogni rollup ottimistico è gestito da una serie di contratti intelligenti distribuiti sulla rete di Ethereum. I rollup ottimistici elaborano le transazioni al di fuori della catena principale di Ethereum, ma pubblicano le transazioni off-chain (in batch) in un contratto di rollup on-chain. Come la blockchain di Ethereum, questo registro delle transazioni è immutabile e forma la "catena di rollup ottimistico".
L'architettura di un optimistic rollup comprende le seguenti parti:
diff --git a/public/content/translations/it/developers/docs/scaling/plasma/index.md b/public/content/translations/it/developers/docs/scaling/plasma/index.md
index 67acee07f30..b89cffbde83 100644
--- a/public/content/translations/it/developers/docs/scaling/plasma/index.md
+++ b/public/content/translations/it/developers/docs/scaling/plasma/index.md
@@ -1,6 +1,6 @@
---
title: Catene plasma
-description: Un'introduzione alle catene plasma come soluzione di scalabilità, attualmente utilizzata dalla comunità Ethereum.
+description: "Un'introduzione alle catene plasma come soluzione di scalabilità, attualmente utilizzata dalla comunità Ethereum."
lang: it
incomplete: true
sidebarDepth: 3
@@ -24,7 +24,7 @@ Le funzioni del contratto Plasma, tra le altre cose, fungono da [ponte](/develop
I componenti di base del quadro Plasma sono:
-### Calcolo off-chain {#off-chain-computation}
+### Calcolo off-chain {#offchain-computation}
La velocità di elaborazione attuale di Ethereum è limitata a circa 15-20 transazioni al secondo, riducendo la possibilità a breve termine di ridimensionamento per gestire più utenti. Questo problema esiste principalmente perché il [meccanismo di consenso](/developers/docs/consensus-mechanisms/) di Ethereum richiede molti nodi peer-to-peer per verificare ogni aggiornamento allo stato della blockchain.
diff --git a/public/content/translations/it/developers/docs/scaling/validium/index.md b/public/content/translations/it/developers/docs/scaling/validium/index.md
index ea548046013..e5e2f46d99c 100644
--- a/public/content/translations/it/developers/docs/scaling/validium/index.md
+++ b/public/content/translations/it/developers/docs/scaling/validium/index.md
@@ -1,6 +1,6 @@
---
title: Validium
-description: Un'introduzione a Validium come soluzione di scalabilità, attualmente utilizzata dalla comunità Ethereum.
+description: "Un'introduzione a Validium come soluzione di scalabilità, attualmente utilizzata dalla comunità Ethereum."
lang: it
sidebarDepth: 3
---
@@ -119,7 +119,7 @@ Alcuni team, tuttavia, stanno cercando di ottimizzare gli opcode EVM esistenti p
## Come fanno i validium a ridimensionare Ethereum? {#scaling-ethereum-with-validiums}
-### 1. Archiviazione dei dati off-chain {#off-chain-data-storage}
+### 1. Archiviazione dei dati off-chain {#offchain-data-storage}
I progetti di ridimensionamento del livello 2, come i rollup ottimistici e a conoscenza zero, rinunciano all'infinita scalabilità dei protocolli di ridimensionamento off-chain puri (ad es. [Plasma](/developers/docs/scaling/plasma/)) in cambio della sicurezza, pubblicando alcuni dati di transazione su L1. Ma questo fa sì che le proprietà di scalabilità dei rollup sia limitata dalla larghezza di banda dei dati sulla Rete principale di Ethereum (lo [sharding dei dati](/roadmap/danksharding/) propone di migliorare la capacità di archiviazione dei dati di Ethereum per questo motivo).
diff --git a/public/content/translations/it/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/it/developers/docs/scaling/zk-rollups/index.md
index c80610d5c15..53e0a590cd4 100644
--- a/public/content/translations/it/developers/docs/scaling/zk-rollups/index.md
+++ b/public/content/translations/it/developers/docs/scaling/zk-rollups/index.md
@@ -30,7 +30,7 @@ L'architettura principale del rollup ZK si compone dei seguenti componenti:
2. **Macchina virtuale (VM) off-chain**: benché il protocollo del rollup ZK risieda su Ethereum, l'esecuzione della transazione e l'archiviazione di stato si verificano su una macchina virtuale separata e indipendente dall'[EVM](/developers/docs/evm/). Questa VM off-chain è l'ambiente di esecuzione per le transazioni sul rollup ZK e serve da livello secondario o "livello 2" per il protocollo rollup ZK. Le prove di validità verificate sulla Rete principale di Ethereum garantiscono la correttezza delle transizioni di stato nella VM off-chain.
-I rollup ZK sono "soluzioni di ridimensionamento ibride": protocolli off-chain che operano indipendentemente ma derivano la sicurezza da Ethereum. Nello specifico, la rete di Ethereum impone la validità degli aggiornamenti di stato sul rollup ZK e garantisce la disponibilità dei dati dietro ogni aggiornamento allo stato del rollup. Di conseguenza, i rollup ZK sono considerevolmente più sicuri delle soluzioni di ridimensionamento off-chain, come le [sidechain](/developers/docs/scaling/sidechains/), responsabili delle proprie proprietà di sicurezza, o i [validium](/developers/docs/scaling/validiums/), che pur verificando le transazioni su Ethereum con le prove di validità, memorizzano altrove i dati della transazione.
+I rollup ZK sono "soluzioni di ridimensionamento ibride": protocolli off-chain che operano indipendentemente ma derivano la sicurezza da Ethereum. Nello specifico, la rete di Ethereum impone la validità degli aggiornamenti di stato sul rollup ZK e garantisce la disponibilità dei dati dietro ogni aggiornamento allo stato del rollup. Di conseguenza, i rollup ZK sono considerevolmente più sicuri delle soluzioni di ridimensionamento off-chain, come le [sidechain](/developers/docs/scaling/sidechains/), responsabili delle proprie proprietà di sicurezza, o i [validium](/developers/docs/scaling/validium/), che pur verificando le transazioni su Ethereum con le prove di validità, memorizzano altrove i dati della transazione.
I rollup ZK si affidano al protocollo principale di Ethereum per quanto segue:
diff --git a/public/content/translations/it/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/it/developers/docs/smart-contracts/compiling/index.md
index d811e9e935d..13c5b8fe609 100644
--- a/public/content/translations/it/developers/docs/smart-contracts/compiling/index.md
+++ b/public/content/translations/it/developers/docs/smart-contracts/compiling/index.md
@@ -1,6 +1,6 @@
---
title: Compilazione dei contratti intelligenti
-description: Una spiegazione del perché devi compilare i contratti intelligenti e di cosa succede effettivamente durante la compilazione.
+description: "Una spiegazione del perché devi compilare i contratti intelligenti e di cosa succede effettivamente durante la compilazione."
lang: it
incomplete: true
---
diff --git a/public/content/translations/it/developers/docs/smart-contracts/composability/index.md b/public/content/translations/it/developers/docs/smart-contracts/composability/index.md
index 794afad7d10..f3366c41acc 100644
--- a/public/content/translations/it/developers/docs/smart-contracts/composability/index.md
+++ b/public/content/translations/it/developers/docs/smart-contracts/composability/index.md
@@ -1,5 +1,5 @@
---
-title: Componibilità dei contratti intelligenti
+title: "Componibilità dei contratti intelligenti"
description:
lang: it
incomplete: true
diff --git a/public/content/translations/it/developers/docs/smart-contracts/languages/index.md b/public/content/translations/it/developers/docs/smart-contracts/languages/index.md
index 8783253b63f..3620feb806f 100644
--- a/public/content/translations/it/developers/docs/smart-contracts/languages/index.md
+++ b/public/content/translations/it/developers/docs/smart-contracts/languages/index.md
@@ -123,24 +123,32 @@ Per ulteriori informazioni, [consulta la logica di Vyper](https://vyper.readthed
# Apertura asta
# Parametri d'asta
+
# Il beneficiario riceve denaro dal miglior offerente
+
beneficiary: public(address)
auctionStart: public(uint256)
auctionEnd: public(uint256)
# Stato attuale dell'asta
+
highestBidder: public(address)
highestBid: public(uint256)
# Imposta a true alla fine per non permettere più modifiche
+
ended: public(bool)
# Tiene traccia delle offerte rimborsate in modo da poter seguire il modello di prelievo
+
pendingReturns: public(HashMap[address, uint256])
# Crea una semplice asta con `_bidding_time`
+
# tempo di offerta in secondi per conto
+
# dell'indirizzo del beneficiario `_beneficiary`.
+
@external
def __init__(_beneficiary: address, _bidding_time: uint256):
self.beneficiary = _beneficiary
@@ -148,9 +156,13 @@ def __init__(_beneficiary: address, _bidding_time: uint256):
self.auctionEnd = self.auctionStart + _bidding_time
# Offerta sull'asta con il valore inviato
+
# insieme a questa transazione.
+
# Il valore sarà rimborsato solo se l'asta
+
# non viene vinta.
+
@external
@payable
def bid():
@@ -165,9 +177,13 @@ def bid():
self.highestBid = msg.value
# Preleva un'offerta precedentemente rimborsata. Il modello di prelievo è
+
# utilizzato qui per evitare un problema di sicurezza. Se i rimborsi venissero inviati direttamente
+
# come parte di bid(), un contratto di offerta malevolo potrebbe bloccarli
+
# e quindi bloccare le nuove offerte più alte in arrivo.
+
@external
def withdraw():
pending_amount: uint256 = self.pendingReturns[msg.sender]
@@ -175,7 +191,9 @@ def withdraw():
send(msg.sender, pending_amount)
# Termina l'asta e invia l'offerta più alta
+
# al beneficiario.
+
@external
def endAuction():
# It is a good guideline to structure functions that interact
diff --git a/public/content/translations/it/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/it/developers/docs/smart-contracts/verifying/index.md
index f46d2fbc5f8..bffe6042b3d 100644
--- a/public/content/translations/it/developers/docs/smart-contracts/verifying/index.md
+++ b/public/content/translations/it/developers/docs/smart-contracts/verifying/index.md
@@ -80,7 +80,7 @@ Etherscan è lo strumento più utilizzato per verificare i contratti. Tuttavia,
[Maggiori informazioni sulla verifica dei contratti su Etherscan](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
-### Sourcify {#sourcify}
+### Sourcify {#blockscout}
[Sourcify](https://sourcify.dev/#/verifier) è un altro strumento, open source e decentralizzato, per verificare i contratti. Non è un esploratore di blocchi e verifica i contratti soltanto su [diverse reti basate sull'EVM](https://docs.sourcify.dev/docs/chains). Agisce da infrastruttura pubblica per la costruzione di altri strumenti e mira a consentire interazioni con i contratti più intuitive, utilizzando i commenti [ABI](/developers/docs/smart-contracts/compiling/#web-applications) e [NatSpc](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) che si trovano nel file dei metadati.
@@ -90,7 +90,7 @@ Inoltre, è anche possibile recuperare i file del codice sorgente via IPFS, poic
[Maggiori informazioni sulla verifica dei contratti su Sourcify](https://blog.soliditylang.org/2020/06/25/sourcify-faq/).
-### Tenderly {#tenderly}
+### Tenderly {#sourcify}
La [piattaforma Tenderly](https://tenderly.co/) consente agli sviluppatori in Web3 di creare, testare, monitorare e gestire i contratti intelligenti. Combinando strumenti di debug con osservabilità e blocchi di costruzione dell'infrastruttura, Tenderly aiuta gli sviluppatori ad accelerare lo sviluppo dei contratti intelligenti. Per abilitare appieno le funzionalità di Tenderly, gli sviluppatori devono [eseguire la verifica del codice sorgente](https://docs.tenderly.co/monitoring/contract-verification) utilizzando svariati metodi.
@@ -102,6 +102,6 @@ Verificando i contratti tramite il Pannello di controllo, devi importare il file
L'utilizzo del plugin Hardhat di Tenderly consente di avere maggiore controllo sul processo di verifica con minori sforzi, consentendoti di scegliere tra una verifica automatica (senza codice) e manuale (basata sul codice).
-## Letture consigliate {#further-reading}
+## Letture consigliate {#tenderly}
- [Verificare il codice sorgente del contratto](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
diff --git a/public/content/translations/it/developers/docs/storage/index.md b/public/content/translations/it/developers/docs/storage/index.md
index ef3bd169125..b67c1ceffaf 100644
--- a/public/content/translations/it/developers/docs/storage/index.md
+++ b/public/content/translations/it/developers/docs/storage/index.md
@@ -1,6 +1,6 @@
---
title: Archiviazione Decentralizzata
-description: Panoramica di cos'è l'archiviazione decentralizzata e degli strumenti disponibili per integrarla in una dapp.
+description: "Panoramica di cos'è l'archiviazione decentralizzata e degli strumenti disponibili per integrarla in una dapp."
lang: it
---
diff --git a/public/content/translations/it/developers/docs/transactions/index.md b/public/content/translations/it/developers/docs/transactions/index.md
index 0a3ede82e33..f2d5d47562b 100644
--- a/public/content/translations/it/developers/docs/transactions/index.md
+++ b/public/content/translations/it/developers/docs/transactions/index.md
@@ -106,7 +106,7 @@ Con l'hash di firma, la transazione può provare crittograficamente che proviene
### Il campo di dati {#the-data-field}
-La grande maggioranza delle transazioni accede a un contratto da un conto esterno. Gran parte dei contratti è scritta in Solidity e interpreta il proprio campo dei dati secondo l'[interfaccia binaria dell'applicazione (Application Binary Interface – ABI)](/glossary/#abi/).
+La grande maggioranza delle transazioni accede a un contratto da un conto esterno. Gran parte dei contratti è scritta in Solidity e interpreta il proprio campo dei dati secondo l'[interfaccia binaria dell'applicazione (Application Binary Interface – ABI)](/glossary/#abi).
I primi quattro byte specificano quale funzione chiamare, usando l'hash del nome e degli argomenti della funzione. Talvolta si può identificare la funzione dal selettore, usando [questo database](https://www.4byte.directory/signatures/).
diff --git a/public/content/translations/it/developers/docs/wrapped-eth/index.md b/public/content/translations/it/developers/docs/wrapped-eth/index.md
index f6633c6df9d..93a7afd5584 100644
--- a/public/content/translations/it/developers/docs/wrapped-eth/index.md
+++ b/public/content/translations/it/developers/docs/wrapped-eth/index.md
@@ -1,6 +1,6 @@
---
-title: Che cos'è il Wrapped Ether (WETH)
-description: Un'introduzione al Wrapped ether (WETH)—un wrapper per ether (ETH) compatibile con ERC20.
+title: "Che cos'è il Wrapped Ether (WETH)"
+description: "Un'introduzione al Wrapped ether (WETH)—un wrapper per ether (ETH) compatibile con ERC20."
lang: it
---
@@ -35,19 +35,16 @@ Puoi "scartare" (ovvero unwrap) WETH per ETH utilizzando il contratto intelligen
Devi pagare delle commissioni del gas per avvolgere o scartare ETH utilizzando il contratto WETH.
-
WETH è generalmente considerato sicuro perché si basa su un contratto intelligente semplice e testato sul campo. Anche il contratto WETH è stato formalmente verificato, che è lo standard di sicurezza più elevato per i contratti intelligenti su Ethereum.
-
Oltre all'[implementazione canonica di WETH](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) descritta in questa pagina, ci sono altre varianti in giro. Queste possono essere token personalizzati creati dagli sviluppatori di applicazioni o versioni emesse su altre blockchain, e potrebbero comportarsi diversamente o avere proprietà di sicurezza diverse. **Ricontrolla sempre le informazioni sui token per sapere con quale implementazione di WETH stai interagendo.**
-
@@ -55,7 +52,6 @@ Oltre all'[implementazione canonica di WETH](https://etherscan.io/token/0xc02aaa
- [Rete Principale di Ethereum](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2)
- [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1)
- [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)
-
## Letture consigliate {#further-reading}
diff --git a/public/content/translations/it/developers/tutorials/all-you-can-cache/index.md b/public/content/translations/it/developers/tutorials/all-you-can-cache/index.md
index 57c7b8c3940..f6ff02e95b8 100644
--- a/public/content/translations/it/developers/tutorials/all-you-can-cache/index.md
+++ b/public/content/translations/it/developers/tutorials/all-you-can-cache/index.md
@@ -1,6 +1,6 @@
---
title: "Salva nella cache quanto vuoi"
-description: Scopri come creare e utilizzare un contratto di memorizzazione nella cache per transazioni rollup più economiche
+description: "Scopri come creare e utilizzare un contratto di memorizzazione nella cache per transazioni rollup più economiche"
author: Ori Pomerantz
tags:
- "livello 2"
diff --git a/public/content/translations/it/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/it/developers/tutorials/erc-721-vyper-annotated-code/index.md
index 1aa4513316d..ae81072d902 100644
--- a/public/content/translations/it/developers/tutorials/erc-721-vyper-annotated-code/index.md
+++ b/public/content/translations/it/developers/tutorials/erc-721-vyper-annotated-code/index.md
@@ -244,6 +244,7 @@ Restituisce il valore dall'HashMap `self-supportedInterfaces`, che è impostata
```python
### VIEW FUNCTIONS ###
+
```
Queste sono le funzioni di visualizzazione che rendono le informazioni sui token disponibili a utenti e altri contratti.
diff --git a/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md
index 77d28e8c2a6..685a839b550 100644
--- a/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md
+++ b/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md
@@ -1,6 +1,6 @@
---
title: "Guida dettagliata al contratto ERC-20"
-description: Cosa c'è nel contratto ERC-20 di OpenZeppelin e a cosa serve?
+description: "Cosa c'è nel contratto ERC-20 di OpenZeppelin e a cosa serve?"
author: Ori Pomerantz
lang: it
tags:
diff --git a/public/content/translations/it/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md b/public/content/translations/it/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
index 4530e734b93..5a4ee39d1a3 100644
--- a/public/content/translations/it/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
+++ b/public/content/translations/it/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md
@@ -11,7 +11,7 @@ tags:
skill: beginner
lang: it
published: 2020-10-30
-source: Medio
+source: Medium
sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f
---
diff --git a/public/content/translations/it/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/it/developers/tutorials/guide-to-smart-contract-security-tools/index.md
index cbc0ab8e3a8..91b5bb0c29e 100644
--- a/public/content/translations/it/developers/tutorials/guide-to-smart-contract-security-tools/index.md
+++ b/public/content/translations/it/developers/tutorials/guide-to-smart-contract-security-tools/index.md
@@ -9,7 +9,7 @@ tags:
- "sicurezza"
skill: intermediate
published: 2020-09-07
-source: Creare contratti sicuri
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis
---
diff --git a/public/content/translations/it/developers/tutorials/hello-world-smart-contract-fullstack/index.md b/public/content/translations/it/developers/tutorials/hello-world-smart-contract-fullstack/index.md
index 0a417e53d75..9bc76177f55 100644
--- a/public/content/translations/it/developers/tutorials/hello-world-smart-contract-fullstack/index.md
+++ b/public/content/translations/it/developers/tutorials/hello-world-smart-contract-fullstack/index.md
@@ -628,8 +628,6 @@ ETHERSCAN_API_KEY = "your-etherscan-key"
### Contratti intelligenti distribuiti su Hardhat {#hardhat-deployed-smart-contracts}
-
-
#### Installa hardhat-etherscan {#install-hardhat-etherscan}
Pubblicare i tuoi contratti su Ethereum usando Hardhat è semplice. Per iniziare è necessario installare il plugin `hardhat-etherscan`. `hardhat-etherscan` verificherà automaticamente il codice sorgente e la ABI del contratto intelligente su Etherscan. Per aggiungerlo, esegui dalla cartella `hello-world`:
@@ -903,8 +901,9 @@ return (
-
-
+
+
+
)
```
diff --git a/public/content/translations/it/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md b/public/content/translations/it/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md
index cec6a7b6dab..0f10e0f3195 100644
--- a/public/content/translations/it/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md
+++ b/public/content/translations/it/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md
@@ -1,6 +1,6 @@
---
title: Come simulare i contratti intelligenti in Solidity per testarli
-description: Perché è importante prendersi gioco dei propri contratti in fase di test
+description: "Perché è importante prendersi gioco dei propri contratti in fase di test"
author: Markus Waas
lang: it
tags:
diff --git a/public/content/translations/it/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md b/public/content/translations/it/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
index bc374533d9a..91f6087b864 100644
--- a/public/content/translations/it/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
+++ b/public/content/translations/it/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md
@@ -11,7 +11,7 @@ tags:
- "fuzzing"
skill: advanced
published: 2020-04-10
-source: Creare contratti sicuri
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna
---
diff --git a/public/content/translations/it/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md b/public/content/translations/it/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
index 7d97bd4a966..88e70637953 100644
--- a/public/content/translations/it/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
+++ b/public/content/translations/it/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md
@@ -11,7 +11,7 @@ tags:
- "verifica formale"
skill: advanced
published: 2020-01-13
-source: Creare contratti sicuri
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore
---
@@ -396,6 +396,7 @@ symbolic_var = m.make_symbolic_value()
contract_account.f(symbolic_var)
## Controlla se l'esecuzione termina con REVERT o INVALID
+
for state in m.terminated_states:
last_tx = state.platform.transactions[-1]
if last_tx.result in ['REVERT', 'INVALID']:
@@ -500,6 +501,7 @@ contract_account.f(symbolic_var)
no_bug_found = True
## Controlla se l'esecuzione termina con REVERT o INVALID
+
for state in m.terminated_states:
last_tx = state.platform.transactions[-1]
if last_tx.result in ['REVERT', 'INVALID']:
diff --git a/public/content/translations/it/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md b/public/content/translations/it/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
index 28111da448b..f4487b0edde 100644
--- a/public/content/translations/it/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
+++ b/public/content/translations/it/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md
@@ -11,7 +11,7 @@ tags:
- "analisi statica"
skill: advanced
published: 2020-06-09
-source: Creare contratti sicuri
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither
---
diff --git a/public/content/translations/it/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/it/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
index 8a4d38bb867..c442b02686e 100644
--- a/public/content/translations/it/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
+++ b/public/content/translations/it/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md
@@ -9,7 +9,7 @@ tags:
- "oracoli"
skill: beginner
published: 2021-06-29
-source: Documentazione di Tellor
+source: Tellor Docs
sourceUrl: https://docs.tellor.io/tellor/
---
diff --git a/public/content/translations/it/developers/tutorials/how-to-write-and-deploy-an-nft/index.md b/public/content/translations/it/developers/tutorials/how-to-write-and-deploy-an-nft/index.md
index c7995522e44..b0b68e38c75 100644
--- a/public/content/translations/it/developers/tutorials/how-to-write-and-deploy-an-nft/index.md
+++ b/public/content/translations/it/developers/tutorials/how-to-write-and-deploy-an-nft/index.md
@@ -1,6 +1,6 @@
---
title: Come Scrivere e Distribuire un NFT (Parte 1/3 della Serie di tutorial sugli NFT)
-description: Questo tutorial è la Parte 1 di una serie sui NFT che ti guiderà passo dopo passo alla scrittura e distribuzione del contratto intelligente di un Token Non Fungibile (token ERC-721) usando Ethereum e l'InterPlanetary File System (IPFS).
+description: "Questo tutorial è la Parte 1 di una serie sui NFT che ti guiderà passo dopo passo alla scrittura e distribuzione del contratto intelligente di un Token Non Fungibile (token ERC-721) usando Ethereum e l'InterPlanetary File System (IPFS)."
author: "Sumi Mudgil"
tags:
- "ERC-721"
diff --git a/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md b/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md
index 8d093e6360e..20ef58025ce 100644
--- a/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md
+++ b/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md
@@ -1,6 +1,6 @@
---
title: Avvia lo sviluppo del frontend della tua dapp con create-eth-app
-description: Una panoramica su come usare create-eth-app e le sue funzionalità
+description: "Una panoramica su come usare create-eth-app e le sue funzionalità"
author: "Markus Waas"
tags:
- "create-eth-app"
diff --git a/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md b/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md
index 8d093e6360e..20ef58025ce 100644
--- a/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md
+++ b/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md
@@ -1,6 +1,6 @@
---
title: Avvia lo sviluppo del frontend della tua dapp con create-eth-app
-description: Una panoramica su come usare create-eth-app e le sue funzionalità
+description: "Una panoramica su come usare create-eth-app e le sue funzionalità"
author: "Markus Waas"
tags:
- "create-eth-app"
diff --git a/public/content/translations/it/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md b/public/content/translations/it/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
index eb020f647c1..ac53cd738cf 100644
--- a/public/content/translations/it/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
+++ b/public/content/translations/it/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md
@@ -1,6 +1,6 @@
---
-title: Prove di Merkle per l'integrità dei dati offline
-description: Garantire l'integrità dei dati sulla catena per i dati memorizzati principalmente al di fuori di essa
+title: "Prove di Merkle per l'integrità dei dati offline"
+description: "Garantire l'integrità dei dati sulla catena per i dati memorizzati principalmente al di fuori di essa"
author: Ori Pomerantz
tags:
- "archiviazione"
@@ -33,7 +33,7 @@ L'hash principale è l'unica parte che deve essere memorizzata sulla catena. Per
[Il campione di codice è disponibile qui](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity).
-### Codice esterno alla catena {#off-chain-code}
+### Codice esterno alla catena {#offchain-code}
In questo articolo usiamo JavaScript per i calcoli al di fuori della catena. Gran parte delle app decentralizzate hanno i propri componenti esterni alla catena su JavaScript.
@@ -163,7 +163,7 @@ Eseguiamo l'hashing di `(v[0],v[1])`, `(v[2],v[3])`, ecc. Quindi per i valori pa
} // getMerkleProof
```
-### Codice on-chain {#on-chain-code}
+### Codice on-chain {#onchain-code}
Finalmente abbiamo il codice che verifica la prova. Il codice on-chain è scritto in [Solidity](https://docs.soliditylang.org/en/v0.8.11/). L'ottimizzazione è molto più importante qui, perché il gas è relativamente costoso.
diff --git a/public/content/translations/it/developers/tutorials/nft-minter/index.md b/public/content/translations/it/developers/tutorials/nft-minter/index.md
index 5029f29175f..6f777a22037 100644
--- a/public/content/translations/it/developers/tutorials/nft-minter/index.md
+++ b/public/content/translations/it/developers/tutorials/nft-minter/index.md
@@ -183,7 +183,7 @@ return (
Mint NFT
{status}
-
+
)
```
diff --git a/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md
index 623a368b33e..20ffd103981 100644
--- a/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md
+++ b/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md
@@ -1,6 +1,6 @@
---
title: "Guida del ponte standard di Optimism per contratti"
-description: Come funziona il ponte standard per Optimism? Perché funziona così?
+description: "Come funziona il ponte standard per Optimism? Perché funziona così?"
author: Ori Pomerantz
tags:
- "solidity"
diff --git a/public/content/translations/it/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/it/developers/tutorials/run-node-raspberry-pi/index.md
index 0b7f03a7701..a5d4e6b6795 100644
--- a/public/content/translations/it/developers/tutorials/run-node-raspberry-pi/index.md
+++ b/public/content/translations/it/developers/tutorials/run-node-raspberry-pi/index.md
@@ -10,7 +10,7 @@ tags:
lang: it
skill: intermediate
published: 2022-06-10
-source: Ethereum su ARM
+source: Ethereum on ARM
sourceUrl: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/
---
diff --git a/public/content/translations/it/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/it/developers/tutorials/secure-development-workflow/index.md
index 124522bb671..4d961ea14a3 100644
--- a/public/content/translations/it/developers/tutorials/secure-development-workflow/index.md
+++ b/public/content/translations/it/developers/tutorials/secure-development-workflow/index.md
@@ -9,7 +9,7 @@ tags:
skill: intermediate
lang: it
published: 2020-09-07
-source: Creare contratti sicuri
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md
---
diff --git a/public/content/translations/it/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/it/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
index ac548d8aaa8..4db85d9821c 100644
--- a/public/content/translations/it/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
+++ b/public/content/translations/it/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md
@@ -9,7 +9,7 @@ tags:
skill: beginner
lang: it
published: 2020-11-04
-source: documentazione Alchemy
+source: Alchemy docs
sourceUrl: https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum
---
diff --git a/public/content/translations/it/developers/tutorials/short-abi/index.md b/public/content/translations/it/developers/tutorials/short-abi/index.md
index 15b2ff853f5..0ebe8f089b4 100644
--- a/public/content/translations/it/developers/tutorials/short-abi/index.md
+++ b/public/content/translations/it/developers/tutorials/short-abi/index.md
@@ -327,7 +327,7 @@ Crea una transazione di trasferimento. Il primo byte è "0x02", seguito dall'ind
}) // describe
```
-### Esempio {#example}
+### Esempio {#reducing-the-cost-when-you-do-control-the-destination-contract}
Se desideri vedere questi file in azione senza eseguirli tu stesso, segui questi link:
@@ -337,13 +337,13 @@ Se desideri vedere questi file in azione senza eseguirli tu stesso, segui questi
4. [Chiamata a `OrisUselessToken.approve()`](https://kovan-optimistic.etherscan.io/tx/1410747). Questa chiamata deve andare direttamente al contratto del token, poiché l'elaborazione si affida al `msg.sender`.
5. [Chiamata a `transfer()`](https://kovan-optimistic.etherscan.io/tx/1410748).
-## Ridurre il costo quando hai il controllo del contratto di destinazione {#reducing-the-cost-when-you-do-control-the-destination-contract}
+## Ridurre il costo quando hai il controllo del contratto di destinazione {#token-sol-2}
Se hai il controllo sul contratto di destinazione, puoi creare funzioni che bypassano i controlli `msg.sender` poiché si fidano dell'interprete dei calldata. [Puoi vedere un esempio di come funziona qui, nel ramo `control-contract`](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract).
Se il contratto rispondesse solo alle transazioni esterne, potremmo riuscirsi con un solo contratto. Tuttavia, questo spezzerebbe la [componibilità](/developers/docs/smart-contracts/composability/). È molto meglio avere un contratto che risponda alle normali chiamate ERC-20 e un altro che risponda alle transazioni con dati della chiamata brevi.
-### Token.sol {#token-sol-2}
+### Token.sol {#calldatainterpreter-sol-2}
In questo esempio, possiamo modificare `Token.sol`. Questo ci permette di avere un numero di funzioni che solo il proxy può chiamare. Ecco le nuove parti:
@@ -441,7 +441,7 @@ Queste sono tre operazioni che normalmente richiedono che il messaggio provenga
1. È modificata da `onlyProxy()`, così che nessun altro possa controllarla.
2. Ottiene l'indirizzo che sarebbe normalmente `msg.sender` come un parametro aggiuntivo.
-### CalldataInterpreter.sol {#calldatainterpreter-sol-2}
+### CalldataInterpreter.sol {#test-js-2}
L'interprete dei dati della chiamata è praticamente identico a quello precedente, tranne che le funzioni in proxy ricevono un parametro `msg.sender` e non è necessaria un'indennità per `transfer`.
@@ -475,7 +475,7 @@ L'interprete dei dati della chiamata è praticamente identico a quello precedent
}
```
-### Test.js {#test-js-2}
+### Test.js {#conclusion}
Ci sono alcune modifiche tra il codice di test precedente e questo.
diff --git a/public/content/translations/it/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/it/developers/tutorials/smart-contract-security-guidelines/index.md
index d58a2b840ee..72c04d2ac1e 100644
--- a/public/content/translations/it/developers/tutorials/smart-contract-security-guidelines/index.md
+++ b/public/content/translations/it/developers/tutorials/smart-contract-security-guidelines/index.md
@@ -9,7 +9,7 @@ tags:
skill: intermediate
lang: it
published: 2020-09-06
-source: Creare contratti sicuri
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
---
@@ -27,7 +27,7 @@ La documentazione può essere scritta su diversi livelli e deve essere aggiornat
- **Schema e diagrammi architettonici**, incluse le interazioni del contratto e la macchina a stati del sistema. Le [stampanti Slither](https://github.com/crytic/slither/wiki/Printer-documentation) possono aiutare a generare questi schemi.
- **Documentazione approfondita sul codice**, il [formato Natspec](https://solidity.readthedocs.io/en/develop/natspec-format.html) si può usare per Solidity.
-### Calcolo sulla catena ed esterno alla catena {#on-chain-vs-off-chain-computation}
+### Calcolo sulla catena ed esterno alla catena {#onchain-vs-offchain-computation}
- **Mantieni quanto più codice possibile al di fuori della catena.** Il livello sulla catena deve essere il più ridotto possibile. Elabora anticipatamente i dati con il codice esternamente alla catena così che la verifica su di essa sia semplice. Ti serve un elenco ordinato? Ordina l'elenco esternamente alla catena, poi controlla solo l'ordine sulla catena.
diff --git a/public/content/translations/it/developers/tutorials/the-graph-fixing-web3-data-querying/index.md b/public/content/translations/it/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
index 1adc5485c36..74a030740b1 100644
--- a/public/content/translations/it/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
+++ b/public/content/translations/it/developers/tutorials/the-graph-fixing-web3-data-querying/index.md
@@ -1,6 +1,6 @@
---
title: "The Graph: query di dati in Web3"
-description: La blockchain è come un database ma senza SQL. Contiene tutti i dati, ma non c'è modo di accedervi. Vediamo come risolvere la situazione con The Graph e GraphQL.
+description: "La blockchain è come un database ma senza SQL. Contiene tutti i dati, ma non c'è modo di accedervi. Vediamo come risolvere la situazione con The Graph e GraphQL."
author: Markus Waas
lang: it
tags:
diff --git a/public/content/translations/it/developers/tutorials/token-integration-checklist/index.md b/public/content/translations/it/developers/tutorials/token-integration-checklist/index.md
index 50630419398..d6579c04b63 100644
--- a/public/content/translations/it/developers/tutorials/token-integration-checklist/index.md
+++ b/public/content/translations/it/developers/tutorials/token-integration-checklist/index.md
@@ -10,7 +10,7 @@ tags:
- "token"
skill: intermediate
published: 2020-08-13
-source: Creare contratti sicuri
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md
---
diff --git a/public/content/translations/it/developers/tutorials/uniswap-v2-annotated-code/index.md b/public/content/translations/it/developers/tutorials/uniswap-v2-annotated-code/index.md
index 23ed18a2053..82e24f12a55 100644
--- a/public/content/translations/it/developers/tutorials/uniswap-v2-annotated-code/index.md
+++ b/public/content/translations/it/developers/tutorials/uniswap-v2-annotated-code/index.md
@@ -1,6 +1,6 @@
---
title: "Guida dettagliata al contratto Uniswap-v2"
-description: Come funziona il contratto Uniswap-v2? Perché è scritto così?
+description: "Come funziona il contratto Uniswap-v2? Perché è scritto così?"
author: Ori Pomerantz
tags:
- "solidity"
@@ -55,9 +55,8 @@ Questo è il flusso più comune, usato dai trader:
3. Identifica l'importo necessario da scambiare su ogni scambio lungo il percorso.
4. Itera sul percorso. Per ogni scambio lungo il percorso, invia il token di input e poi chiama la funzione di `swap` dello scambio. In gran parte dei casi, l'indirizzo di destinazione per i token è lo scambio in pari successivo nel percorso. Nello scambio finale è presente l'indirizzo fornito dal trader.
-#### Nel contratto principale (UniswapV2Pair.sol) {#in-the-core-contract-uniswapv2pairsol-2}
+#### Nel contratto principale (UniswapV2Pair.sol) {#in-the-core-contract-uniswapv2pairsol-2}5. Verifica che il contratto principale non raggiri il sistema e possa mantenere liquidità sufficiente dopo lo scambio.
-5. Verifica che il contratto principale non raggiri il sistema e possa mantenere liquidità sufficiente dopo lo scambio.
6. Vede quanti token aggiuntivi abbiamo, in aggiunta alle riserve note. Quell'importo è il numero di token di input ricevuti da scambiare.
7. Invia i token d'output alla destinazione.
8. Chiama `_update` per aggiornare gli importi della riserva
@@ -743,7 +742,7 @@ Questa è la funzione principale della factory, per creare uno scambio in pari t
(address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
```
-Vogliamo che l'indirizzo del nuovo scambio sia deterministico, quindi calcolabile in anticipo al di fuori della catena (questo può essere utile per le [transazioni di livello 2](/developers/docs/layer-2-scaling/)). Per farlo, dobbiamo avere un ordine coerente degli indirizzi del token, indipendentemente dall'ordine in cui li abbiamo ricevuti, quindi li ordiniamo qui.
+Vogliamo che l'indirizzo del nuovo scambio sia deterministico, quindi calcolabile in anticipo al di fuori della catena (questo può essere utile per le [transazioni di livello 2](/developers/docs/scaling/)). Per farlo, dobbiamo avere un ordine coerente degli indirizzi del token, indipendentemente dall'ordine in cui li abbiamo ricevuti, quindi li ordiniamo qui.
```solidity
require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS');
diff --git a/public/content/translations/it/developers/tutorials/using-websockets/index.md b/public/content/translations/it/developers/tutorials/using-websockets/index.md
index 892853e0405..f96fc83dfca 100644
--- a/public/content/translations/it/developers/tutorials/using-websockets/index.md
+++ b/public/content/translations/it/developers/tutorials/using-websockets/index.md
@@ -9,8 +9,8 @@ tags:
- "query"
- "javascript"
skill: beginner
-source: documentazione Alchemy
-sourceUrl: https://docs.alchemyapi.io/guides/using-websockets
+source: Alchemy docs
+sourceUrl: https://www.alchemy.com/docs/reference/best-practices-for-using-websockets-in-web3
published: 2020-12-01
---
diff --git a/public/content/translations/it/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md b/public/content/translations/it/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
index bec9d55112b..676f647e349 100644
--- a/public/content/translations/it/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
+++ b/public/content/translations/it/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md
@@ -295,4 +295,4 @@ Il codice sorgente di questo tutorial si può trovare [qui](https://github.com/E
Altri tutorial che potrebbero interessarti:
-- [Test di Smart Contract con Waffle](/developers/tutorials/testing-smart-contract-with-waffle/)
+- [Test di Smart Contract con Waffle](/developers/tutorials/waffle-test-simple-smart-contract/)
diff --git a/public/content/translations/it/developers/tutorials/waffle-test-simple-smart-contract/index.md b/public/content/translations/it/developers/tutorials/waffle-test-simple-smart-contract/index.md
index d440693878a..6b30dec8150 100644
--- a/public/content/translations/it/developers/tutorials/waffle-test-simple-smart-contract/index.md
+++ b/public/content/translations/it/developers/tutorials/waffle-test-simple-smart-contract/index.md
@@ -30,7 +30,6 @@ published: 2021-02-26
Il tutorial dimostra la configurazione di prova e opera utilizzando yarn, ma non ci sono problemi se preferisci npm: fornirò gli adeguati riferimenti alla [documentazione](https://ethereum-waffle.readthedocs.io/en/latest/index.html) ufficiale di Waffle.
### Installa dipendenze {#install-dependencies}
-
[Aggiungi](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#installation) ethereum-waffle e le dipendenze di TypeScript alle dipendenze di sviluppo del tuo progetto.
```bash
@@ -38,7 +37,6 @@ yarn add --dev ethereum-waffle ts-node typescript @types/jest
```
### Esempio di contratto intelligente {#example-smart-contract}
-
Durante il tutorial lavoreremo a un esempio di contratto intelligente semplice: EtherSplitter. Non fa molto, tranne che consentire a chiunque di inviare wei e dividerli uniformemente tra due destinatari predefiniti. La funzione di divisione richiede che il numero di wei sia pari, altrimenti si ripristinerà. Per entrambi i destinatari esegue un trasferimento di wei, seguito dall'emissione dell'evento Trasferimento.
Posiziona il frammento del codice di EtherSplitter in `src/EtherSplitter.sol`.
@@ -68,7 +66,6 @@ contract EtherSplitter {
```
### Compila il contratto {#compile-the-contract}
-
Per [compilare](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#compiling-the-contract) il contratto, aggiungi il seguente elemento al file package.json:
```json
@@ -91,7 +88,6 @@ Poi, crea un file di configurazione di Waffle nella cartella di root del progett
Esegui `yarn build`. Di conseguenza, la cartella `build` apparirà con il contratto compilato di EtherSplitter nel formato JSON.
### Testare la configurazione {#test-setup}
-
Testare con Waffle richiede l'utilizzo di abbinatori Chai e Mocha, quindi, devi [aggiungerli](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests) al tuo progetto. Aggiorna il tuo file package.json e aggiungi l'elemento `test` nella parte degli script:
```json
@@ -135,7 +131,6 @@ Solo due parole prima di iniziare. `MockProvider` offre una versione fittizia de
Quindi, dichiariamo una variabile detta "splitter" (divisore), che è il nostro contratto fittizio EtherSplitter. È creato prima di ogni esecuzione di un singolo test dal metodo `deployContract`. Questo metodo simula la distribuzione di un contratto dal portafoglio passato come primo parametro (nel nostro caso, il portafoglio del mittente). Il secondo parametro è l'ABI e il bytecode del contratto testato; qui, passiamo il file json del contratto compilato EtherSplitter dalla cartella `build`. Il terzo parametro è un insieme con gli argomenti del costruttore del contratto che, nel nostro caso, sono gli indirizzi dei due destinatari.
### changeBalances {#changebalances}
-
Prima controlleremo se il metodo di divisione modifica effettivamente i saldi dei portafogli dei destinatari. Se dividiamo 50 wei dall'account del mittente, i saldi di entrambi i destinatari dovrebbero aumentare di 25 wei. Utilizzeremo l'abbinatore di Waffle "`changeBalances`:
```ts
@@ -163,7 +158,6 @@ Nota che in entrambi i casi di `changeBalance` e `changeBalances`, passiamo la f
Poi, testeremo se l'evento Trasferimento è stato emesso dopo ogni trasferimento di wei. Ci rivolgeremo a un altro abbinatore da Waffle:
### Emetti {#emit}
-
```ts
it("Emits event on the transfer to the first receiver", async () => {
await expect(splitter.split({ value: 50 }))
@@ -181,7 +175,6 @@ it("Emits event on the transfer to the second receiver", async () => {
L'abbinatore `emit` ci consente di verificare se un contratto ha emesso un evento alla chiamata di un metodo. Come parametri all'abbinatore `emit`, forniamo il contratto fittizio che prevediamo emetterà l'evento, insieme al nome di tale evento. Nel nostro caso, il contratto fittizio è `splitter` e il nome dell'evento è `Trasferimento`. Inoltre, possiamo verificare i valori precisi degli argomenti con cui è stato emesso l'evento; passiamo altrettanti argomenti all'abbinatore `withArgs`, come previsto dalla dichiarazione del nostro evento. Nel caso del contratto EtherSplitter, passiamo gli indirizzi del mittente e del destinatario insieme all'importo trasferito di wei.
### revertedWith {#revertedwith}
-
Come ultimo esempio verificheremo se la transazione è stata ripristinata, nel caso di un numero dispari di wei. Utilizzeremo l'abbinatore `revertedWith`:
```ts
diff --git a/public/content/translations/it/ethereum-forks/index.md b/public/content/translations/it/ethereum-forks/index.md
index d5f6252e37c..b3a41fd3001 100644
--- a/public/content/translations/it/ethereum-forks/index.md
+++ b/public/content/translations/it/ethereum-forks/index.md
@@ -16,7 +16,6 @@ Le diramazioni si verificano quando è necessario apportare importanti aggiornam
Quando sono necessari aggiornamenti in software tradizionali controllati centralmente, l'azienda pubblica una nuova versione per l'utente finale. Le blockchain funzionano diversamente perché non esiste una proprietà centrale. I [client di Ethereum](/developers/docs/nodes-and-clients/) devono aggiornare il proprio software e implementare le regole della nuova diramazione. Inoltre i creatori dei blocchi (miner in contesto Proof of Work e validatori in contesto Proof of Stake) e i nodi devono creare blocchi e convalidarli in base alle nuove regole. [Maggiori informazioni sui meccanismi di consenso](/developers/docs/consensus-mechanisms/)
Queste modifiche alle regole potrebbero creare una divisione temporanea nella rete. I nuovi blocchi potrebbero essere creati in base alle nuove regole o a quelle vecchie. Le diramazioni di solito sono concordate in anticipo in modo che i client adottino le modifiche all'unisono e la diramazione legata agli upgrade diventi la catena principale. Tuttavia, in rari casi, disaccordi sulle diramazioni possono causare una divisione permanente della rete, come è successo con la creazione di Ethereum Classic con la diramazione DAO.
-
@@ -59,7 +58,6 @@ Gli aggiornamenti dei livelli di esecuzione e di consenso erano inizialmente dis
| ----------------- | ----------------- | ---------- |
| Shanghai | Capella | "Shapella" |
| Cancun | Deneb | "Dencun" |
-
Salta direttamente alle informazioni su alcuni degli ultimi aggiornamenti particolarmente importanti: [La Beacon Chain](/roadmap/beacon-chain/); [La Fusione](/roadmap/merge/) ed [EIP-1559](#london)
@@ -68,13 +66,13 @@ Stai cercando i prossimi aggiornamenti di protocollo? [Scopri di più sui prossi
-## 2024 {#2024}
+## 2024 {#2025}
-### Cancun-Deneb ("Dencun") {#dencun}
+### Cancun-Deneb ("Dencun") {#fusaka}
-#### Riepilogo di Cancun {#cancun-summary}
+#### Riepilogo di Cancun {#pectra}
L'aggiornamento di Cancun contiene una serie di miglioramenti all'_esecuzione_ di Ethereum, mirati a migliorarne la scalabilità, in tandem con gli aggiornamenti al consenso di Deneb.
@@ -90,7 +88,6 @@ Notevolmente, include l'EIP-4844, nota come **Proto-Danksharding**, che riduce s
EIP-6780: SELFDESTRUCT soltanto nella stessa transazione
-
- [Rollup del Livello 2](/layer-2/)
@@ -98,7 +95,7 @@ Notevolmente, include l'EIP-4844, nota come **Proto-Danksharding**, che riduce s
- [Danksharding](/roadmap/danksharding/)
- [Leggi le specifiche dell'aggiornamento di Cancun](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md)
-#### Riepilogo di Deneb {#deneb-summary}
+#### Riepilogo di Deneb {#2024}
L'aggiornamento di Deneb contiene una serie di miglioramenti al _consenso_ di Ethereum, mirati a migliorarne la scalabilità. Questo aggiornamento è in tandem con gli aggiornamenti del livello di esecuzione Cancun per consentire il Proto-Danksharding (EIP-4844), insieme ad altri miglioramenti alla Beacon Chain.
@@ -115,7 +112,6 @@ EIP-7514 comporta un rafforzamento dell'emissione di ETH, limitando il tasso di
EIP-7045: Aumento degli slot massimi di inclusione dell'attestazione
EIP-7514: Aggiunta del limite massimo di churn per epoca
-
- [Leggi le specifiche dell'aggiornamento di Deneb](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/)
@@ -123,13 +119,13 @@ EIP-7514 comporta un rafforzamento dell'emissione di ETH, limitando il tasso di
-## 2023 {#2023}
+## 2023 {#dencun}
-### Shanghai-Capella ("Shapella") {#shapella}
+### Shanghai-Capella ("Shapella") {#cancun-summary}
-#### Riepilogo di Shanghai {#shanghai-summary}
+#### Riepilogo di Shanghai {#deneb-summary}
L'aggiornamento di Shanghai ha portato i prelievi di staking al livello d'esecuzione. Insieme all'aggiornamento Capella, questo abiliterà i blocchi ad accettare le operazioni di prelievo, che consentono agli staker di prelevare i propri ETH dalla Beacon Chain al livello d'esecuzione.
@@ -142,12 +138,11 @@ L'aggiornamento di Shanghai ha portato i prelievi di staking al livello d'esecuz
EIP-4895 – La Beacon Chain lancia i prelievi come operazioni
-
- [Leggi le specifiche dell'aggiornamento Shanghai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)
-#### Riepilogo di Capella {#capella-summary}
+#### Riepilogo di Capella {#2023}
L'aggiornamento di Capella è il terzo aggiornamento principale al livello del consenso (Beacon Chain) e ha abilitato i prelievi di staking. Capella è avvenuto contemporaneamente all'aggiornamento del livello di esecuzione di Shanghai, e ha reso disponibili le funzioni di prelievo da staking.
@@ -160,13 +155,13 @@ L'aggiornamento, inoltre, ha fornito la funzionalità di pulizia automatica dei
-## 2022 {#2022}
+## 2022 {#shapella}
-### Paris (la Fusione) {#paris}
+### Paris (la Fusione) {#shanghai-summary}
-#### Riepilogo {#paris-summary}
+#### Riepilogo {#capella-summary}
L'aggiornamento Paris è stato attivato dal passaggio da una blockchain proof-of-work di una [difficoltà totale terminale](/glossary/#terminal-total-difficulty) di 58750000000000000000000. Questo è avvenuto al blocco 15537393 il 15 settembre 2022, innescando l'aggiornamento Paris dal blocco successivo. Paris è stata la transizione [alla Fusione](/roadmap/merge/): la sua caratteristica principale è lo spegnimento dell'algoritmo di mining [proof-of-work](/developers/docs/consensus-mechanisms/pow) e della relativa logica di consenso, e l'attivazione della [proof-of-stake](/developers/docs/consensus-mechanisms/pos). Paris è stata un aggiornamento ai [client di esecuzione](/developers/docs/nodes-and-clients/#execution-clients) (equivalente a Bellatrix a livello di consenso) che ha permesso loro di ricevere istruzioni dai loro [client di consenso](/developers/docs/nodes-and-clients/#consensus-clients) collegati. Questo ha richiesto l'attivazione di una nuova serie di metodi API interni, collettivamente noti come l'[API Engine](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md). Questo è stato probabilmente l'aggiornamento più significativo nella storia di Ethereum dopo [Homestead](#homestead)!
@@ -178,16 +173,15 @@ L'aggiornamento Paris è stato attivato dal passaggio da una blockchain proof-of
EIP-4399 – Sostituisce l'opcode DIFFICULTY con PREVRANDAO
-
---
-### Bellatrix {#bellatrix}
+### Bellatrix {#2022}
-#### Riepilogo {#bellatrix-summary}
+#### Riepilogo {#paris}
L'aggiornamento Bellatrix è stato il secondo aggiornamento programmato per la [Beacon Chain](/roadmap/beacon-chain), preparando la catena per [la Fusione](/roadmap/merge/). Porta le penalità dei validatori al valore pieno per inattività e azioni sanzionabili (slashing). Bellatrix include anche un aggiornamento alle regole di scelta della diramazione per preparare la catena per la Fusione e la transizione dall'ultimo blocco di proof-of-work al primo blocco proof-of-stake. A tale scopo occorre far sì che i client di consenso siano consapevoli della [difficoltà terminale totale](/glossary/#terminal-total-difficulty) di 58750000000000000000000.
@@ -195,11 +189,11 @@ L'aggiornamento Bellatrix è stato il secondo aggiornamento programmato per la [
---
-### Gray Glacier {#gray-glacier}
+### Gray Glacier {#paris-summary}
-#### Riepilogo {#gray-glacier-summary}
+#### Riepilogo {#bellatrix}
L'aggiornamento della rete di Gray Glacier ha rimandato di tre mesi la [bomba di difficoltà](/glossary/#difficulty-bomb). Questa è l'unica modifica introdotta in questo aggiornamento ed è simile per natura agli aggiornamenti di [Arrow Glacier](#arrow-glacier) e [Muir Glacier](#muir-glacier). Modifiche simili sono state effettuate sugli aggiornamenti di rete [Byzantium](#byzantium), [Constantinople](#constantinople) e [London](#london).
@@ -210,18 +204,17 @@ L'aggiornamento della rete di Gray Glacier ha rimandato di tre mesi la [bomba di
EIP-5133 – ritarda la bomba di difficoltà fino a settembre 2022
-
-## 2021 {#2021}
+## 2021 {#bellatrix-summary}
-### Arrow Glacier {#arrow-glacier}
+### Arrow Glacier {#gray-glacier}
-#### Riepilogo {#arrow-glacier-summary}
+#### Riepilogo {#gray-glacier-summary}
L'aggiornamento di rete Arrow Glacier ha rimandato la [bomba di difficoltà](/glossary/#difficulty-bomb) di diversi mesi. Questo è l'unico cambiamento introdotto in questo aggiornamento, ed è simile nella sostanza all'aggiornamento [Muir Glacier](#muir-glacier). Modifiche simili sono state effettuate sugli aggiornamenti di rete [Byzantium](#byzantium), [Constantinople](#constantinople) e [London](#london).
@@ -233,22 +226,21 @@ L'aggiornamento di rete Arrow Glacier ha rimandato la [bomba di difficoltà](/gl
EIP-4345 – ritarda la bomba di difficoltà fino a giugno 2022
-
---
-### Altair {#altair}
+### Altair {#2021}
-#### Riepilogo {#altair-summary}
+#### Riepilogo {#arrow-glacier}
L'aggiornamento Altair è stato il primo aggiornamento pianificato per la [Beacon Chain](/roadmap/beacon-chain). Ha aggiunto il supporto per le "commissioni di sincronizzazione", abilitando i "client leggeri", aumentando le penalità per inattività e slashing per i validatori man mano che lo sviluppo procedeva verso la Fusione.
- [Leggi le specifiche dell'aggiornamento di Altair](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair)
-#### Curiosità! {#altair-fun-fact}
+#### Curiosità! {#arrow-glacier-summary}
Altair è stato il primo importante aggiornamento di rete che ha avuto un tempo di rollout esatto. Tutti gli aggiornamenti precedenti erano basati su un numero di blocco dichiarato su una catena proof-of-work, dove i tempi del blocco variavano. La Beacon Chain non richiede la risoluzione del proof-of-work e funziona invece su un sistema di epoche basato sul tempo che consiste in 32 "slot" di dodici secondi in cui i validatori possono proporre dei blocchi. Questo è il motivo per cui sapevamo esattamente quando avremmo raggiunto l'epoca 74.240 e Altair sarebbe diventato operativo!
@@ -256,15 +248,15 @@ Altair è stato il primo importante aggiornamento di rete che ha avuto un tempo
---
-### London {#london}
+### London {#altair}
-#### Riepilogo {#london-summary}
+#### Riepilogo {#altair-summary}
L'aggiornamento London ha introdotto l'[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), che ha riformato il mercato delle commissioni sulle transazioni, oltre a modificare come sono gestiti i rimborsi di carburante e la pianificazione di [Ice Age](/glossary/#ice-age).
-#### Cos'è l'Aggiornamento di Londra / EIP-1559? {#eip-1559}
+#### Cos'è l'Aggiornamento di Londra / EIP-1559? {#altair-fun-fact}
Prima dell'Aggiornamento di Londra, Ethereum disponeva di blocchi di dimensioni fisse. Nei momenti di elevata domanda di rete, questi blocchi operavano a piena capacità. Di conseguenza, gli utenti devono spesso attendere che la domanda si riduca per essere inclusi in un blocco, il che ha portato a una scadente esperienza degli utenti. L'Aggiornamento di Londra ha introdotto blocchi di dimensioni variabili a Ethereum.
@@ -291,16 +283,15 @@ Questo video spiega l'EIP-1559 e i benefici che comporta: [EIP-1559 Explained](h
EIP-3541 - impedisce la distribuzione dei contratti che iniziano con 0xEF
EIP-3554 – ritarda l'Era Glaciale fino a dicembre 2021
-
---
-### Berlin {#berlin}
+### Berlin {#london}
-#### Riepilogo {#berlin-summary}
+#### Riepilogo {#london-summary}
L'aggiornamento Berlin ha ottimizzato i costi del carburante per certe azioni dell'EVM e ha aumentato il supporto per vari tipi di transazioni.
@@ -315,18 +306,17 @@ L'aggiornamento Berlin ha ottimizzato i costi del carburante per certe azioni de
EIP-2929 – il costo del carburante aumenta per gli opcode d'accesso allo stato
-
-## 2020 {#2020}
+## 2020 {#eip-1559}
-### Genesi della Beacon Chain {#beacon-chain-genesis}
+### Genesi della Beacon Chain {#berlin}
-#### Riepilogo {#beacon-chain-genesis-summary}
+#### Riepilogo {#berlin-summary}
La [Beacon Chain](/roadmap/beacon-chain/) necessita di 16384 depositi da 32 ETH di staking per poter funzionare in sicurezza. Questo è successo il 27 novembre, quindi la Beacon Chain ha iniziato a produrre blocchi il 1° dicembre 2020. Questa è una prima fase importante nel percorso per raggiungere la [visione di Ethereum](/roadmap/vision/).
@@ -338,11 +328,11 @@ La [Beacon Chain](/roadmap/beacon-chain/) necessita di 16384 depositi da 32 ETH
---
-### Distribuzione del contratto di deposito in staking {#staking-deposit-contract}
+### Distribuzione del contratto di deposito in staking {#2020}
-#### Riepilogo {#deposit-contract-summary}
+#### Riepilogo {#beacon-chain-genesis}
Il contratto di deposito in staking ha introdotto lo [staking](/glossary/#staking) all'ecosistema di Ethereum. Nonostante fosse un contratto della [Rete principale](/glossary/#mainnet), ha avuto un impatto diretto sulla linea temporale per il lancio della [Beacon Chain](/roadmap/beacon-chain/), un importante [aggiornamento di Ethereum](/roadmap/).
@@ -354,11 +344,11 @@ Il contratto di deposito in staking ha introdotto lo [staking](/glossary/#stakin
---
-### Muir Glacier {#muir-glacier}
+### Muir Glacier {#beacon-chain-genesis-summary}
-#### Riepilogo {#muir-glacier-summary}
+#### Riepilogo {#staking-deposit-contract}
La diramazione Muir Glacier ha introdotto un ritardo nella [bomba di difficoltà](/glossary/#difficulty-bomb). Aumenta la difficoltà del blocco del meccanismo di consenso [Proof-of-Work](/developers/docs/consensus-mechanisms/pow/), che rischiava di peggiorare l'utilizzabilità di Ethereum, aumentando i tempi d'attesa per l'invio delle transazioni e l'uso delle dapp.
@@ -370,18 +360,17 @@ La diramazione Muir Glacier ha introdotto un ritardo nella [bomba di difficoltà
EIP-2384 – ritarda la bomba di difficoltà per altri 4.000.000 blocchi, o circa 611 giorni.
-
-## 2019 {#2019}
+## 2019 {#deposit-contract-summary}
-### Istanbul {#istanbul}
+### Istanbul {#muir-glacier}
-#### Riepilogo {#istanbul-summary}
+#### Riepilogo {#muir-glacier-summary}
La diramazione Instanbul:
@@ -403,16 +392,15 @@ La diramazione Instanbul:
EIP-2028 – riduce il costo di CallData per consentire più dati nei blocchi, buono per il [ridimensionamento del Livello 2](/developers/docs/scaling/#layer-2-scaling).
EIP-2200 – altre alterazioni del prezzo del carburante dell'opcode.
EIP-100 – modifica la formula di regolazione della difficoltà.
EIP-649 – ritarda la [bomba di difficoltà](/glossary/#difficulty-bomb) di 1 anno e riduce la ricompensa del blocco da 5 a 3 ETH.
-
-## 2016 {#2016}
+## 2016 {#2017}
-### Spurious Dragon {#spurious-dragon}
+### Spurious Dragon {#byzantium}
-#### Riepilogo {#spurious-dragon-summary}
+#### Riepilogo {#byzantium-summary}
La diramazione Spurious Dragon è stata la seconda risposta agli attacchi denial of service (DoS) sulla rete (settembre/ottobre 2016) e ha reso possibile, tra l'altro:
@@ -495,16 +481,15 @@ La diramazione Spurious Dragon è stata la seconda risposta agli attacchi denial
EIP-161 – consente la rimozione dei conti vuoti aggiunti tramite attacchi DoS.
EIP-170 – modifica la dimensione massima del codice che un contratto sulla blockchain può avere, a 24576 byte.
-
---
-### Tangerine Whistle {#tangerine-whistle}
+### Tangerine Whistle {#2016}
-#### Riepilogo {#tangerine-whistle-summary}
+#### Riepilogo {#spurious-dragon}
La diramazione Tangerine Whistle è stata la prima risposta agli attacchi di denial of service (DoS) alla rete (settembre/ottobre 2016) e ha incluso:
@@ -518,16 +503,15 @@ La diramazione Tangerine Whistle è stata la prima risposta agli attacchi di den
EIP-150 – aumenta i costi del carburante degli opcode utilizzabili negli attacchi di spam.
EIP-158 – riduce le dimensioni di stato rimuovendo un gran numero di conti vuoti messi nello stato a costo bassissimo a causa di bug nelle versioni precedenti del protocollo di Ethereum.
-
---
-### Diramazione OAD {#dao-fork}
+### Diramazione OAD {#spurious-dragon-summary}
-#### Riepilogo {#dao-fork-summary}
+#### Riepilogo {#tangerine-whistle}
La diramazione OAD è stata pensata come risposta all'[attacco OAD del 2016](https://www.coindesk.com/learn/understanding-the-dao-attack/), durante il quale un contratto [OAD](/glossary/#dao) non protetto è stato privato di oltre 3,6 milioni di ETH in un solo attacco. La diramazione ha spostato i fondi dal contratto difettoso a un [nuovo contratto](https://etherscan.io/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754) con una sola funzione: il prelievo. Chi aveva perso fondi ha potuto prelevare 1 ETH per ogni 100 token OAD nel proprio portafoglio.
@@ -539,11 +523,11 @@ Alcuni miner rifiutarono di creare la diramazione perché l'incidente DAO non er
---
-### Homestead {#homestead}
+### Homestead {#tangerine-whistle-summary}
-#### Riepilogo {#homestead-summary}
+#### Riepilogo {#dao-fork}
La diramazione Homestead guardava al futuro. Includeva diverse modifiche al protocollo e un cambiamento che ha dato a Ethereum la possibilità di eseguire ulteriori aggiornamenti della rete.
@@ -556,18 +540,17 @@ La diramazione Homestead guardava al futuro. Includeva diverse modifiche al prot
EIP-8 – introduce i requisiti di compatibilità progressiva a devp2p
-
-## 2015 {#2015}
+## 2015 {#dao-fork-summary}
-### Frontier thawing {#frontier-thawing}
+### Frontier thawing {#homestead}
-#### Riepilogo {#frontier-thawing-summary}
+#### Riepilogo {#homestead-summary}
La diramazione Frontier Thawing ha innalzato il limite di 5.000 [gas](/glossary/#gas) per [blocco](/glossary/#block) e ha impostato il prezzo predefinito del gas a 51 [gwei](/glossary/#gwei). Ciò ha reso possibili le transazioni, che richiedono 21.000 gas. La [bomba di difficoltà](/glossary/#difficulty-bomb) è stata introdotta per assicurare una hard-fork futura verso il [proof-of-stake](/glossary/#pos).
@@ -576,11 +559,11 @@ La diramazione Frontier Thawing ha innalzato il limite di 5.000 [gas](/glossary/
---
-### Frontier {#frontier}
+### Frontier {#2015}
-#### Riepilogo {#frontier-summary}
+#### Riepilogo {#frontier-thawing}
Frontier è stata un'implementazione operativa ma rudimentale del progetto Ethereum. È seguita alla positiva fase di test Olympic. Era destinata agli utenti tecnici, in particolare gli sviluppatori. I [blocchi](/glossary/#block) avevano un limite di 5.000 [gas](/glossary/#gas). Questo periodo di "disgelo" (dall'inglese thawing) ha consentito ai miner di iniziare la propria operatività e ai primi utilizzatori di installare i client senza fretta.
@@ -588,9 +571,9 @@ Frontier è stata un'implementazione operativa ma rudimentale del progetto Ether
-## 2014 {#2014}
+## 2014 {#frontier-thawing-summary}
-### Vendita di Ether {#ether-sale}
+### Vendita di Ether {#frontier}
@@ -600,7 +583,7 @@ Ether fu ufficialmente messo in vendita per 42 giorni. Lo potresti acquistare in
---
-### Pubblicazione dello yellowpaper {#yellowpaper}
+### Pubblicazione dello yellowpaper {#frontier-summary}
@@ -610,9 +593,9 @@ Lo Yellow Paper, redatto dal dott. Gavin Wood, è una definizione tecnica del pr
-## 2013 {#2013}
+## 2013 {#2014}
-### Pubblicazione del whitepaper {#whitepaper}
+### Pubblicazione del whitepaper {#ether-sale}
diff --git a/public/content/translations/it/foundation/index.md b/public/content/translations/it/foundation/index.md
index c742def2847..d1560ff071c 100644
--- a/public/content/translations/it/foundation/index.md
+++ b/public/content/translations/it/foundation/index.md
@@ -1,11 +1,11 @@
---
title: Ethereum Foundation
-description: Scopri di più sulla Ethereum Foundation (EF), un'organizzazione no-profit dedita al supporto di Ethereum e delle tecnologie correlate.
+description: "Scopri di più sulla Ethereum Foundation (EF), un'organizzazione no-profit dedita al supporto di Ethereum e delle tecnologie correlate."
hideEditButton: true
lang: it
---
-# Informazioni sulla Ethereum Foundation {#about-the-ethereum-foundation}
+# Informazioni sulla Ethereum Foundation {#ethereum-foundation}
@@ -13,16 +13,14 @@ La [Ethereum Foundation](http://ethereum.foundation/) (EF) è un'organizzazione
Non è un'azienda, né una no-profit tradizionale. Il suo ruolo non è quello di controllare o guidare Ethereum, e non è l'unica organizzazione che finanzia lo sviluppo critico delle tecnologie correlate a Ethereum. L'EF fa parte di un [ecosistema](/community/) molto più ampio.
-## Iniziative dell'Ethereum Foundation {#ethereum-foundation-initiatives}
-
-### Programma di supporto dell'ecosistema {#ecosystem-support-program}
+## Iniziative dell'Ethereum Foundation {#what-the-ef-does}
+### Programma di supporto dell'ecosistema {#programs-and-initiatives}
Il [programma di supporto dell'ecosistema](https://esp.ethereum.foundation/) esiste per dare sostegno sia finanziario che non a progetti ed entità all'interno di tutta la community Ethereum, con lo scopo di accelerare la crescita dell'ecosistema. È un'espansione dell'originario Ethereum Grants Program, che si concentrava soprattutto sul supporto finanziario.
Scopri di più sul programma di supporto dell'ecosistema, sui destinatari delle sovvenzioni passati e sul processo di candidatura per le sovvenzioni su [esp.ethereum.foundation](https://esp.ethereum.foundation/). Puoi anche consultare l'[Ecosystem Support Program Blog](https://blog.ethereum.org/category/ecosystem-support-program/) o seguire [@EF_ESP](https://twitter.com/EF_ESP) per rimanere al passo con gli ultimi annunci e le notizie più recenti.
-### Devcon {#devcon}
-
+### Devcon {#learn-more}
Fin dal 2014, Ethereum Foundation ha organizzato Devcon, la conferenza annuale per tutti gli sviluppatori Ethereum, i ricercatori, i creatori e i pensatori.
Puoi accedere ai contenuti video o alle conferenze di ogni anno, a partire da quello di creazione, su [archive.devcon.org](https://archive.devcon.org/).
diff --git a/public/content/translations/it/governance/index.md b/public/content/translations/it/governance/index.md
index 21a0a339cf5..fc1dff16672 100644
--- a/public/content/translations/it/governance/index.md
+++ b/public/content/translations/it/governance/index.md
@@ -22,7 +22,7 @@ Nessuna persona possiede o controlla il protocollo Ethereum, ma è comunque nece
La governance di Ethereum è il processo attraverso il quale vengono apportate modifiche al protocollo. È importante sottolineare che questo processo non ha a che fare con il modo in cui le persone e le applicazioni utilizzano il protocollo, infatti Ethereum è senza autorizzazioni. Chiunque da qualsiasi parte del mondo può partecipare ad attività on-chain. Non ci sono regole fisse su chi può o non può creare un'applicazione o inviare una transazione. Tuttavia, esiste un processo per proporre modifiche al protocollo principale, su cui vengono eseguite queste applicazioni. Poiché molte persone dipendono dalla stabilità di Ethereum, esiste una soglia di coordinamento davvero elevata per i cambiamenti principali, inclusi i processi sociali e tecnici, per garantire che ogni modifica a Ethereum sia sicura e ampiamente supportata dalla community.
-### Governance on-chain e off-chain {#on-chain-vs-off-chain}
+### Governance on-chain e off-chain {#onchain-vs-offchain}
La tecnologia blockchain rende possibili nuove modalità di governance, conosciute come governance on-chain. Per governance on-chain si intende che le proposte di modifica al protocollo sono decise tramite il voto degli stakeholder, che in genere detengono un governance token, e la votazione avviene sulla blockchain. In alcune forme di governance on-chain, le modifiche proposte al protocollo sono già scritte nel codice e vengono implementate automaticamente nel caso in cui vengano approvate dagli stakeholder tramite la sottoscrizione di una transazione.
diff --git a/public/content/translations/it/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/it/guides/how-to-create-an-ethereum-account/index.md
index b171b3ceb04..245478be491 100644
--- a/public/content/translations/it/guides/how-to-create-an-ethereum-account/index.md
+++ b/public/content/translations/it/guides/how-to-create-an-ethereum-account/index.md
@@ -47,7 +47,7 @@ Alcune applicazioni chiederanno di salvare una "frase di recupero" segreta (a vo
Come utilizzare un portafoglio
-
+
diff --git a/public/content/translations/it/guides/how-to-id-scam-tokens/index.md b/public/content/translations/it/guides/how-to-id-scam-tokens/index.md
index 3af9b81af23..ad4b9dc7072 100644
--- a/public/content/translations/it/guides/how-to-id-scam-tokens/index.md
+++ b/public/content/translations/it/guides/how-to-id-scam-tokens/index.md
@@ -20,7 +20,6 @@ title="Cosa è ARB?"
contentPreview=''>
Arbitrum è un'organizzazione che sviluppa e gestisce [rollup ottimistici](/developers/docs/scaling/optimistic-rollups/). Inizialmente Arbitrum era organizzata come società a scopo di lucro, ma poi ha preso provvedimenti per decentralizzarsi. Nell'ambito di questo processo, hanno emesso un [token di governance](/dao/#token-based-membership) negoziabile.
-
In Ethereum esiste una convenzione per cui, quando una risorsa non è conforme a ERC-20, ne viene creata una versione "wrapped" con il nome che inizia con "w". Quindi, ad esempio, abbiamo wBTC per bitcoin e wETH per ether.
Non ha senso creare una versione wrapped di un token ERC-20 già presente su Ethereum, ma i truffatori si basano sull'apparenza di legittimità piuttosto che sulla realtà sottostante.
-
## Come funzionano i token truffa? {#how-do-scam-tokens-work}
@@ -42,7 +40,6 @@ title="Cosa sono i contratti intelligenti?"
contentPreview=''>
[I contratti intelligenti](/developers/docs/smart-contracts/) sono i programmi che vengono eseguiti sulla blockchain di Ethereum. Ogni token ERC-20, ad esempio, è implementato come un contratto intelligente.
-
In particolare, Arbitrum ha distribuito un contratto che utilizza il simbolo `ARB`. Ma questo non impedisce ad altre persone di distribuire un contratto che utilizza lo stesso simbolo o uno simile. Chiunque scriva il contratto può stabilire ciò che il contratto farà.
diff --git a/public/content/translations/it/nft/index.md b/public/content/translations/it/nft/index.md
index 3279ce0720f..a9ad889f49d 100644
--- a/public/content/translations/it/nft/index.md
+++ b/public/content/translations/it/nft/index.md
@@ -5,11 +5,11 @@ description: Una panoramica dei NFT su Ethereum
lang: it
template: use-cases
emoji: ":frame_with_picture:"
-sidebarDepth: 3
+sidebarDepth: 2
image: /images/infrastructure_transparent.png
alt: Un logo Eth visualizzato tramite ologramma.
summaryPoint1: Un modo pe rappresentare qualsiasi cosa sia univoca, come una risorsa basata su Ethereum.
-summaryPoint2: I NFT stanno dando ai creatori di contenuti più potere che mai.
+summaryPoint2: "I NFT stanno dando ai creatori di contenuti più potere che mai."
summaryPoint3: Basati sui contratti intelligenti, sulla blockchain di Ethereum.
---
diff --git a/public/content/translations/it/roadmap/account-abstraction/index.md b/public/content/translations/it/roadmap/account-abstraction/index.md
index 8695d3cd058..11786ab121e 100644
--- a/public/content/translations/it/roadmap/account-abstraction/index.md
+++ b/public/content/translations/it/roadmap/account-abstraction/index.md
@@ -1,6 +1,6 @@
---
title: Astrazione account
-description: Una panoramica dei piani di Ethereum per rendere i conti degli utenti più semplici e sicuri
+description: "Una panoramica dei piani di Ethereum per rendere i conti degli utenti più semplici e sicuri"
lang: it
summaryPoints:
- L'astrazione del conto semplifica molto la creazione di portafogli di contratti intelligenti
@@ -61,7 +61,6 @@ La gestione del gas, inoltre, è di molto migliorata con l'astrazione del conto.
La gestione del gas è una delle frizioni principali per gli utenti di Ethereum, principalmente perché gli ETH sono la sola risorsa utilizzabile per pagare le transazioni. Immagina di avere un portafoglio con un saldo di USDC, ma nessun ETH. Non puoi spostare o scambiare quei token USDC, poiché non puoi pagare il gas. Non puoi nemmeno scambiare gli USDC per ETH, poiché anche questo costa del gas. Dovresti inviare altri ETH al tuo conto da una piattaforma di scambio o da un altro indirizzo per risolvere il problema. Con i portafogli di contratti intelligenti, invece, puoi semplicemente pagare il gas in USDC, liberando il tuo conto. Non devi più mantenere un saldo di ETH in tutti i tuoi conti.
L'astrazione del conto, inoltre, consente agli sviluppatori di dapp di essere creativi con la gestione del gas. Ad esempio, potresti riuscire a iniziare a pagare una commissione fissa mensile alla tua DEX preferita, per delle transazioni illimitate. Le Dapp potrebbero offrire di pagare tutte le tue commissioni di gas per conto tuo, come ricompensa per aver utilizzato la loro piattaforma, o come offerta di inserimento. Per gli sviluppatori, sarebbe molto più facile innovare sul gas, quando i portafogli di contratti intelligenti sono supportati al livello del protocollo.
-
Le sessioni fidate, inoltre, sono potenzialmente trasformative per le esperienze degli utenti, specialmente per applicazioni come il gaming, in cui grandi numeri di piccole transazioni, potrebbero necessitare dell'approvazione in un breve tempo. Approvare individualmente ogni transazione spezzerebbe l'esperienza di gioco, ma l'approvazione permanente non è sicura. Il portafoglio di un contratto intelligente potrebbe approvare certe transazioni per un dato tempo, fino a un valore specifico o solo per certi indirizzi.
@@ -77,7 +76,6 @@ I portafogli di contratti intelligenti, ad oggi, esistono, ma implementarli è i
EIP-2771 introduce il concetto delle meta-transazioni, che consentono a terze parti di pagare i costi del gas degli utenti senza apportare modifiche al protocollo di Ethereum. L'idea è che le transazioni firmate da un utente sono inviate a un contratto `Corriere`. Il corriere è un'entità fidata che verifica che le transazioni siano valide, prima di inviarle a un ripetitore di gas. Ciò avviene all'esterno della catena, evitando il bisogno di pagare il gas. Il ripetitore di gas passa la transazione a un contratto `Destinatario`, pagando il gas necessario per rendere la transazione eseguibile su Ethereum. La transazione è eseguita se il `Corriere` è noto ed è ritenuto attendibile dal `Destinatario`. Questo modello semplifica, per gli sviluppatori, l'implementazione di transazioni a gas zero per gli utenti.
-
@@ -87,7 +85,6 @@ L'EIP-4337 è il primo passo verso il supporto dei portafogli di contratti intel
Anche il funzionamento dei portafogli cambierà sotto EIP-4337. Invece di far reimplementare da ogni portafoglio una logica di sicurezza complessa ma comune, queste funzioni saranno affidate a un contratto del portafoglio globale, noto come "punto d'accesso". Questo, gestirebbe le operazioni come il pagamento delle commissioni e l'esecuzione del codice dell'EVM, così che gli sviluppatori di portafogli possano concentrarsi sul fornire eccellenti esperienze agli utenti.
Nota: il contratto del punto d'accesso dell'EIP-4337, è stato distribuito alla Rete Principale di Ethereum l'1 marzo 2023. Puoi visualizzare il contratto su Etherscan.
-
@@ -95,7 +92,6 @@ Anche il funzionamento dei portafogli cambierà sotto EIP-4337. Invece di far re
L'EIP-2938 mira ad aggiornare il protocollo di Ethereum introducendo un nuovo tipo di transazione, AA_TX_TYPE che include tre campi: nonce, target e data, dove nonce è un contatore di transazioni, target è l'indirizzo del contratto del punto d'accesso, e data è il bytecode dell'EVM. Per eseguire queste transazioni, devono essere aggiunte due nuove istruzioni (note come codici operativi) all'EVM: NONCE e PAYGAS. Il codice operativo NONCE traccia la sequenza della transazione e PAYGAS calcola e preleva il gas necessario per eseguire la transazione dal saldo del contratto. Queste nuove funzionalità consentono a Ethereum di supportare nativamente i portafogli di contratti intelligenti, poiché l'infrastruttura necessaria è integrata nel protocollo di Ethereum.
Nota che l'EIP-2938 non è correntemente attiva. La community, al momento, preferisce EIP-4337 poiché non richiede modifiche al protocollo.
-
@@ -103,7 +99,6 @@ Nota che l'EIP-2938 non è correntemente attiva. La community, al momento, prefe
L'EIP-3074 mira ad aggiornare i conti posseduti esternamente di Ethereum, consentendo loro di delegare il controllo a un contratto intelligente. Ciò significa che la logica dei contratti intelligenti potrebbe approvare le transazioni originate da un EOA. Questo consentirebbe funzionalità come la sponsorizzazione del gas e le transazioni raggruppate. Perché funzioni, devono essere aggiunti due nuovi codici operativi all'EVM: AUTH e AUTHCALL. Con l'EIP-3074, i benefici del portafoglio di un contratto intelligente sono resi disponibili senza la necessità di un contratto, invece un tipo specifico di contratto privo di stato, privo di fiducia e non ggiornabile, noto come "invocatore", gestisce le transazioni.
Nota che EIP-3074 non è correntemente attivo. La community, al momento, preferisce EIP-4337 poiché non richiede modifiche al protocollo.
-
## Stato attuale {#current-progress}
diff --git a/public/content/translations/it/roadmap/beacon-chain/index.md b/public/content/translations/it/roadmap/beacon-chain/index.md
index fdfafae0a45..d4529c6a841 100644
--- a/public/content/translations/it/roadmap/beacon-chain/index.md
+++ b/public/content/translations/it/roadmap/beacon-chain/index.md
@@ -6,7 +6,7 @@ template: upgrade
image: /images/upgrades/core.png
alt:
summaryPoint1: La Beacon Chain ha introdotto il proof-of-stake all'ecosistema di Ethereum.
-summaryPoint2: Si è unita alla catena di proof-of-work originale di Ethereum a settembre 2022.
+summaryPoint2: "Si è unita alla catena di proof-of-work originale di Ethereum a settembre 2022."
summaryPoint3: La Beacon Chain ha introdotto la logica del consenso e il protocollo di gossip dei blocchi, che ora protegge Ethereum.
---
@@ -32,7 +32,7 @@ Lo staking ha un ruolo simile a quello che aveva il [mining](/developers/docs/co
La transizione al proof of stake ha reso Ethereum significativamente più sicura e decentralizzata rispetto al proof of work. Più persone parteciperanno alla rete, più questa diventerà decentralizzata e protetta dagli attacchi.
-E l'utilizzo del proof of stake come meccanismo di consenso è un componente fondamentale per [l'Ethereum sicuro, ecosostenibile e scalabile che conosciamo ora](/roadmap/vision/).
+E l'utilizzo del proof of stake come meccanismo di consenso è un componente fondamentale per [l'Ethereum sicuro, ecosostenibile e scalabile che conosciamo ora](/staking/).
diff --git a/public/content/translations/it/roadmap/danksharding/index.md b/public/content/translations/it/roadmap/danksharding/index.md
index 59099359eac..6a853f4f77e 100644
--- a/public/content/translations/it/roadmap/danksharding/index.md
+++ b/public/content/translations/it/roadmap/danksharding/index.md
@@ -22,13 +22,11 @@ Ciò è costoso perché elaborato da tutti i nodi di Ethereum e risiede per semp
I rollup sono un metodo per scalare Ethereum raggruppando le transazioni all'esterno della catena e, in seguito, pubblicando i risultati su Ethereum. Un rollup, essenzialmente, si compone di due parti: dati e controllo dell'esecuzione. I dati sono la sequenza completa delle transazioni elaborate da un rollup per produrre il cambiamento di stato pubblicato su Ethereum. Il controllo d'esecuzione è la ri-esecuzione di tali transazioni da un utente onesto (dimostratore) per aassicurarsi che il cambiamento di stato proposto sia corretto. Per effettuare il controllo d'esecuzione, i dati della transazione devono essere disponibili per un tempo sufficiente perché chiunque possa scaricarli e controllarli. Ciò significa che qualsiasi comportamento disonesto dal sequenziatore del rollup puà essere identificato e sfidato dal dimostratore. Tuttavia, non è necessario che sia disponibile per sempre.
-
I rollup pubblicano gli impegni ai dati delle proprie transazioni on chain e, inoltre, rendono disponibili i dati effettivi nei blob di dati. Ciò significa che i dimostratori possono verificare che gli impegni siano validi o sfidare i dati che ritengono siano errati. Al livello del nodo, i blob di dati sono conservati nel client del consenso. I client del consenso attestano di aver visto i dati e che sono stati propagati per la rete. Se i dati fossero conservati per sempre, tali client si allargherebberò, determinando grandi requisiti hardware per l'esecuzione di nodi. Invece, i dati sono eliminati automaticamente dal nodo ogni 18 giorni. Le attestazioni del client del consenso dimostrano che vi è stata un'opportunità sufficiente, affinché i dimostratori potessero verificare i dati. I dati effettivi possono essere memorizzati off-chain dagli operatori di rollup, dagli utenti o da terzi.
-
### Come sono verificati i dati dei blob? {#how-are-blobs-verified}
@@ -48,13 +46,11 @@ La cerimonia KZG dell'EIP-4844 era aperta al pubblico e decine di migliaia di pe
Quando un rollup pubblica dati in un blob, fornisce un "impegno" che viene pubblicato sulla catena. Questo, è il risultato della valutazione di un adattamento polinomiale ai dati, in certi punti. Questi punti sono definiti dai numeri casuali generati nella cerimonia KZG. I dimostratori, quindi, possono valutare la polinomiale agli stessi punti, per poter verificare i dati; se arrivano agli stessi valori, allora i dati sono corretti.
-
Se qualcuno conoscesse le posizioni casuali utilizzate per l'impegno, sarebbe facile, per loro, generare una nuova polinomiaale che si adatti a quei punti specifici (cioè, una "collisione"). Ciò significa che potrebbero aggiungere o rimuovere i dati dal blob e, comunque, fornire una prova valida. Per impedirlo, invece di dare ai dimostratori le posizioni segrete effettive, ricevono in realtà le posizioni, avvolte in una "scatola nera" crittografica, utilizzando le curve ellittiche. Questi, infatti, rimescolano i valori in modo tale che i valori originali non siano decodificabili, ma con dimostratori e verificatori capaci in algebra, le polinomiali sono ancora valutabili ai punti rappresentati.
-
@@ -70,13 +66,11 @@ Funziona espandendo i blob collegati ai blocchi da sei (6) nel proto-dankshardin
La separazione di propositori e costruttori è necessaria per impedire ai singoli validatori di dover generare costosi impegni e prove, per 32 MB di dati del blob. Questo metterebbe a dura prova gli staker domestici e richiederebbe loro di investire in hardware più potenti, danneggiando la decentralizzazione. Invece, i costruttori di blocchi specializzati si prendono la responsabilità di questo costoso lavoro di calcolo. Poi, mettono a disposizione i propri blocchi ai propositori di blocchi per la trasmissione. Il propositore di blocchi, semplicemente, sceglie il blocco più redditizio. Chiunque può verificare i blob in modo economico e rapido, a significare che ogni normale validatore può verificare che i costruttori di blocchi si stiano comportando onestamente. Questo permette di elaborare i blob di grandi dimensioni senza sacrificare la decentralizzazione. I costruttori di blocchi malevoli potrebbero semplicemente essere esplusi dalla rete e tagliati; altri arriverebbero al loro posto, poiché la costruzione di blocchi è un'attività redditizia.
-
Il campionamento della disponibilità dei dati è necessario perché i validatori verifichino in modo rapido ed efficace i dati dei blob. Utilizzando il campionmento della disponibilità dei dati, i validatori possono essere davvero certi che i blob di dati fossero disponibili e che siano stati inviati correttamente. Ogni validatore può campionare casualmente alcuni punti di dati e creare una prova, a significare che nessun validatore deve verificare l'intero blob. Se mancano dei dati, saranno identificati rapidamente e il blob sarà respinto.
-
### Stato attuale {#current-progress}
diff --git a/public/content/translations/it/roadmap/future-proofing/index.md b/public/content/translations/it/roadmap/future-proofing/index.md
index 9166a97866d..6047829e3d4 100644
--- a/public/content/translations/it/roadmap/future-proofing/index.md
+++ b/public/content/translations/it/roadmap/future-proofing/index.md
@@ -1,6 +1,6 @@
---
title: Rendere Ethereum a prova di futuro
-description: Questi aggiornamenti cementano Ethereum come lo strato fondamentale, resiliente e decentralizzato per il futuro, indipendentemente da ciò che conterrà.
+description: "Questi aggiornamenti cementano Ethereum come lo strato fondamentale, resiliente e decentralizzato per il futuro, indipendentemente da ciò che conterrà."
lang: it
image: /images/roadmap/roadmap-future.png
alt: "Roadmap di Ethereum"
diff --git a/public/content/translations/it/roadmap/merge/index.md b/public/content/translations/it/roadmap/merge/index.md
index 06cded798a0..eed70dddc1f 100644
--- a/public/content/translations/it/roadmap/merge/index.md
+++ b/public/content/translations/it/roadmap/merge/index.md
@@ -5,8 +5,8 @@ lang: it
template: upgrade
image: /images/upgrades/merge.png
alt:
-summaryPoint1: La Rete Principale di Ethereum utilizza il proof-of-stake, ma non è sempre stato così.
-summaryPoint2: L'aggiornamento dal meccanismo originale di proof-of-work al proof-of-stake, è stato detto La Fusione.
+summaryPoint1: "La Rete Principale di Ethereum utilizza il proof-of-stake, ma non è sempre stato così."
+summaryPoint2: "L'aggiornamento dal meccanismo originale di proof-of-work al proof-of-stake, è stato detto La Fusione."
summaryPoint3: La Fusione si riferisce all'unione della Rete Principale di Ethereum con una blockchain di proof-of-stake separata, detta Beacon Chain, ora coesistenti come un'unica catena.
summaryPoint4: La Fusione ha ridotto il consumo energetico di Ethereum di circa il 99,95%.
---
@@ -88,7 +88,6 @@ Gli elementi d'azione chiave includono:
- Autenticare i client di esecuzione e di consenso con un segreto JWT condiviso, così che possano comunicare in sicurezza tra loro.
Non completare i suddetti elementi farà sì che il tuo nodo risulti "offline", finché entrambi i livelli non saranno sincronizzati e autenticati.
-
Per ulteriori informazioni, consulta questo post del blog di Tim Beiko su Come La Fusione Influenza il Livello d'Applicazione di Ethereum.
-
## La Fusione e il consumo energetico {#merge-and-energy}
@@ -116,7 +114,7 @@ La Fusione ha segnato la fine del proof-of-work per Ethereum e ha dato inizio al
## La Fusione e il ridimensionamento {#merge-and-scaling}
-La Fusione ha inoltre gettato le basi per ulteriori aggiornamenti di scalabilità, impossibili sotto il Poof of Work, portando Ethereum un po' più vicina al raggiungimento della completa scalabilità, sicurezza e sostenibilità delinate nella [visione di Ethereum](/roadmap/vision/).
+La Fusione ha inoltre gettato le basi per ulteriori aggiornamenti di scalabilità, impossibili sotto il Poof of Work, portando Ethereum un po' più vicina al raggiungimento della completa scalabilità, sicurezza e sostenibilità delinate nella [visione di Ethereum](/energy-consumption/).
## Equivoci su La Fusione {#misconceptions}
@@ -135,7 +133,6 @@ Eseguire un nodo che non produce blocchi è possibile per chiunque, in entrambi
L'abilità per chiunque di gestire il proprio nodo è assolutamente essenziale per mantenere la decentralizzazione della rete di Ethereum.
[Ulteriori informazioni sull'esecuzione di un proprio nodo](/run-a-node/)
-
tabella di marcia incentrata sui rollup, gli sforzi si concentrano sul ridimensionamento delle attività degli utenti al [livello 2](/layer-2/), consentendo alla Rete Principale di Livello 1 di essere un livello di accordo decentralizzato e sicuro, ottimizzato per l'archiviazione dei dati dei rollup, per aiutare a rendere esponenzialmente più economiche le transazioni dei rollup. La transizione al Proof of stake è un precursore essenziale per realizzarlo. [Ulteriori informazioni su gas e commissioni.](/developers/docs/gas/)
-
indirizzo di prelievo per iniziare a ricevere pagamenti automatici di qualsiasi saldo di staking in eccesso (ETH superiori a 32, da ricompense del protocollo). Questo aggiornamento, inoltre, ha consentito la capacità di un validatore di sbloccare e rivendicare l'intero saldo all'uscita dalla rete.
[Maggiori informazioni sui prelievi in staking](/staking/withdrawals/)
-
- L'emissione di staking esatta fluttua a seconda dell'importo totale di ETH in staking
- **Da La Fusione, restano approssimativamnte soltanto 1.700 ETH/giorno, riducendo la nuova emissione totale di ETH di circa l'88%**
- La bruciatura: questa, fluttua secondo la domanda di rete. _Se_ per un dato giorno si osserva un prezzo di gas medio di almeno 16 gwei, questo compensa effettivamente i circa 1.700 ETH emessi ai validatori e porta l'inflazione netta di ETH a zero, o meno, per quel giorno.
-
## Pre-Fusione (storico) {#pre-merge}
@@ -63,7 +62,9 @@ Offerta totale di ETH: **circa 120.520.000 ETH** (al momento della Fusione a set
**Circa l'11,3%** era emesso agli staker sul livello del consenso (0,52 / 4,61 * 100)
+
+
## Post-Fusione (oggi) {#post-merge}
@@ -97,7 +98,9 @@ Tasso di emissione annualizzato totale: **circa 0,52%**
Riduzione netta nell'emissione annuale di ETH: **circa 88,7%** ((4,61%-0,52%) / 4,61% * 100)
+
+
## La bruciatura {#the-burn}
@@ -109,7 +112,9 @@ La forza opposta all'emissione di ETH è il tasso a cui gli ETH sono bruciati. P
La bruciatura delle commissioni è divenuta attiva con l'[aggiornamento di Londra](/ethereum-forks/#london) ad agosto 2021 e resta immutata da La Fusione.
+
+
Oltre alla bruciatura della commissione, implementata dall'aggiornamento di Londra, i validatori, inoltre, possono incorrere in sanzioni per essere online o, peggio, possono ricevere tagli per l'infrazione di regole specifiche che minacciano la sicurezza della rete. Queste, risultano in una riduzione degli ETH dal saldo di quel validatore, che non è ricompensato direttamente a nessun altro conto, bruciandoli/rimuovendoli effettivamente dalla circolazione.
diff --git a/public/content/translations/it/roadmap/pbs/index.md b/public/content/translations/it/roadmap/pbs/index.md
index 4b0b292c707..be168336e77 100644
--- a/public/content/translations/it/roadmap/pbs/index.md
+++ b/public/content/translations/it/roadmap/pbs/index.md
@@ -1,6 +1,6 @@
---
title: Separazione proponente-sviluppatore
-description: Scopri come e perché i validatori di Ethereum divideranno le proprie responsabilità di costruzione e trasmissione dei blocchi.
+description: "Scopri come e perché i validatori di Ethereum divideranno le proprie responsabilità di costruzione e trasmissione dei blocchi."
lang: it
---
@@ -21,7 +21,6 @@ I [mempool crittografati](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpkt
Potenti organizzazioni possono spingere i validatori a censurare le transazioni da o verso certi indirizzi. I validatori si conformano a tale pressione rilevando gli indirizzi nella lista nera del proprio gruppo di transazioni e omettendoli dai blocchi che propongono. Dopo la PBS, non sarà più possibile poiché i propositori di blocchi non sapranno quali transazioni stanno trasmettendo nei propri blocchi. Potrebbe essere importante, per certi individui o app, conformarsi alle regole di censura, ad esempio, quando è emanata una legge nella loro regione. In tali casi, la conformità si verifica a livello di applicazione, mentre il protocolo rimane privo di permessi e di censura.
-
## PBS e MEV {#pbs-and-mev}
diff --git a/public/content/translations/it/roadmap/scaling/index.md b/public/content/translations/it/roadmap/scaling/index.md
index 54d6c3f2ac9..2d511aa85e6 100644
--- a/public/content/translations/it/roadmap/scaling/index.md
+++ b/public/content/translations/it/roadmap/scaling/index.md
@@ -1,6 +1,6 @@
---
title: Ridimensionare Ethereum
-description: I rollup raggruppano le transazioni al di fuori della catena, riducendo i costi per l'utente. Tuttavia, il modo in cui i rollup utilizzano i dati al momento è troppo costoso, il che limita l'economicità delle transazioni. Il Proto-Danksharding lo corregge.
+description: "I rollup raggruppano le transazioni al di fuori della catena, riducendo i costi per l'utente. Tuttavia, il modo in cui i rollup utilizzano i dati al momento è troppo costoso, il che limita l'economicità delle transazioni. Il Proto-Danksharding lo corregge."
lang: it
image: /images/roadmap/roadmap-transactions.png
alt: "Roadmap di Ethereum"
diff --git a/public/content/translations/it/roadmap/security/index.md b/public/content/translations/it/roadmap/security/index.md
index 11dfbd8b335..8526aae04e7 100644
--- a/public/content/translations/it/roadmap/security/index.md
+++ b/public/content/translations/it/roadmap/security/index.md
@@ -1,6 +1,6 @@
---
-title: Un Ethereum più sicuro
-description: Ethereum è la piattaforma di contratti intelligenti più sicura e decentralizzata che esista. Tuttavia, restano ancora da implementare alcuni miglioramenti in modo che Ethereum resti resiliente a qualsiasi livello di attacco anche in un futuro lontano.
+title: "Un Ethereum più sicuro"
+description: "Ethereum è la piattaforma di contratti intelligenti più sicura e decentralizzata che esista. Tuttavia, restano ancora da implementare alcuni miglioramenti in modo che Ethereum resti resiliente a qualsiasi livello di attacco anche in un futuro lontano."
lang: it
image: /images/roadmap/roadmap-security.png
alt: "Roadmap di Ethereum"
diff --git a/public/content/translations/it/roadmap/single-slot-finality/index.md b/public/content/translations/it/roadmap/single-slot-finality/index.md
index d8e0bc0c4a6..02ba9bcc682 100644
--- a/public/content/translations/it/roadmap/single-slot-finality/index.md
+++ b/public/content/translations/it/roadmap/single-slot-finality/index.md
@@ -1,6 +1,6 @@
---
-title: Finalità dello spazio singolo
-description: Spiegazione della finalità dello spazio singolo
+title: "Finalità dello spazio singolo"
+description: "Spiegazione della finalità dello spazio singolo"
lang: it
---
diff --git a/public/content/translations/it/roadmap/user-experience/index.md b/public/content/translations/it/roadmap/user-experience/index.md
index 2748d708027..3713de6141f 100644
--- a/public/content/translations/it/roadmap/user-experience/index.md
+++ b/public/content/translations/it/roadmap/user-experience/index.md
@@ -1,6 +1,6 @@
---
title: Migliorare l'esperienza degli utenti
-description: Per molti, è ancora troppo complesso utilizzare Ethereum. Per incoraggiare l'adozione di massa, Ethereum deve ridurre drasticamente le proprie barriere d'accesso; gli utenti devono ricevere i benefici dell'accesso decentralizzato, privo di permessi e resistente alla censura a Ethereum, ma dev'essere privo di frizione, tanto quanto utilizzare una tradizionale app del web2.
+description: "Per molti, è ancora troppo complesso utilizzare Ethereum. Per incoraggiare l'adozione di massa, Ethereum deve ridurre drasticamente le proprie barriere d'accesso; gli utenti devono ricevere i benefici dell'accesso decentralizzato, privo di permessi e resistente alla censura a Ethereum, ma dev'essere privo di frizione, tanto quanto utilizzare una tradizionale app del web2."
lang: it
image: /images/roadmap/roadmap-ux.png
alt: "Roadmap di Ethereum"
diff --git a/public/content/translations/it/roadmap/verkle-trees/index.md b/public/content/translations/it/roadmap/verkle-trees/index.md
index 59cae3a2e7c..02bb4b09d23 100644
--- a/public/content/translations/it/roadmap/verkle-trees/index.md
+++ b/public/content/translations/it/roadmap/verkle-trees/index.md
@@ -18,7 +18,6 @@ Gli alberi di Verkle sono un passaggio fondamentale sul percorso per i client di
I client di Ethereum, al momento, utilizzano una struttura di dati nota come Albero di Patricia di Merkle per memorizzarne i dati di stato. Le informazioni sui singoli conti sono memorizzati come foglie su un albero e, le coppie di foglie, ricevono ripetutamente un hash finché non ne resta soltanto uno. Questo hash finale è noto come la "radice". Per verficare i blocchi, i client di Ethereum eseguono tutte le transazioni in un blocco e aggiornano il proprio albero di stato locale. Il blocco è considerato valido se la radice dell'albero locale è identica a quella fornita dal propositore di blocchi, poiché qualsiasi differenza nel calcolo effettuato dal propositore del blocco e dal nodo di convalida, formerebbe un hash di radice completamente differente. Il problema è che la verifica della blockchain richiede che ogni client memorizzi l'intero albero di stato per il blocco di testa e per diversi blocchi storici (di default, su Geth, sono mantenuti i dati di stato per 128 blocchi oltre la testa). Ciò richiede che i client abbiano accesso a una grande quantità di spazio su disco, limitando l'esecuzione dei nodi completi su hardware economici e poco potenti. Una soluzione è aggiornare l'albero di stato a una struttura più efficiente (l'albero di Verkle), riepilogabile utilizzando un piccolo "testimone" ai dati, condivisibile invece dei dati di stato completi. Riformattare i dati di stato in un albero di Verkle è una pietra miliare per spostarsi verso i client privi di stato.
-
## Cos'è un testimone e perché è necessario? {#what-is-a-witness}
@@ -34,7 +33,6 @@ Sotto lo schema di impegno polinomiale, i testimoni hanno dimensioni gestibili,
Le dimensioni dei testimoni variano a seconda del numero di foglie che include. Supponendo che il testimone copra 1000 foglie, un testimone per un albero di Merkle occuperebbe all'incirca 3,5 MB (ipotizzando 7 livelli all'albero). Un testimone per gli stessi dati in un albero di Verkle (ipotizzando 4 livelli all'albero) occuperebbe circa 150 kB; **circa 23 volte più piccolo**. Questa riduzione delle dimensioni del testimone consentirà ai testimoni del client di essere accettabilmente piccoli. I testimoni polinomiali variano da 0,128 a 1 kB a seconda dello specifico impegno polinomiale utilizzato.
-
## Qual è la struttura di un albero di Verkle? {#what-is-the-structure-of-a-verkle-tree}
diff --git a/public/content/translations/it/social-networks/index.md b/public/content/translations/it/social-networks/index.md
index 47d7099ccb2..2c62d2f1d3f 100644
--- a/public/content/translations/it/social-networks/index.md
+++ b/public/content/translations/it/social-networks/index.md
@@ -65,18 +65,18 @@ I post pubblicati su Mirror sono memorizzati permanentemente su Arweave, una pia
Gli utenti utilizzano il token [ERC-20](/glossary/#erc-20) nativo della piattaforma $MIND per pagare gli articoli. Inoltre, gli utenti, possono anche guadagnare token $MIND, pubblicando contenuti popolari, contribuendo all'ecosistema e riferendo altri alla piattaforma.
-## Utilizzare i social decentralizzati {#use-decentralized-social-networks}
+## Utilizzare i social decentralizzati {#farcaster}
- **[Status.im](https://status.im/)**: _Status è un'app di messaggistica sicura che utilizza un protocollo open source e tra pari, nonché la crittografia end-to-end per proteggere i tuoi messaggi dalle terze parti._
- **[Mirror.xyz](https://mirror.xyz/)**: _Mirror è una piattaforma di pubblicazione decentralizzata e posseduta dagli utenti basata su Ethereum, per il crowdfunding delle idee, la monetizzazione dei contenuti e la creazione di community dal valore elevato._
- **[Lens Protocol](https://lens.xyz/)**: _Lens Protocol è un grafico sociale componibile e decentralizzato che aiuta i creatori a prendere possesso dei propri contenuti, ovunque vadano nel proprio giardino digitale dell'Intenet decentralizzato._
- **[Farcaster](https://farcaster.xyz/)**: _Farcaster è un social sufficientemente decentralizzato. È un protocollo aperto che supporta molti client, proprio come l'email._
-## Social network Web2 su Ethereum {#web2-social-networks-and-ethereum}
+## Social network Web2 su Ethereum {#use-decentralized-social-networks}
Le piattaforme social native del [Web3](/glossary/#web3) non sono le sole che stanno tentando di incorporare la tecnologia della blockchain nei social. Anche molte piattaforme centralizzate stanno pianificando di integrare Ethereum nella propria infrastruttura:
-### Reddit {#reddit}
+### Reddit {#web2-social-networks-and-ethereum}
Reddit ha [pubblicizzato i Punti della Community](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users): token ERC-20 che gli utenti possono guadagnare pubblicando contenuti di qualità e contribuendo alle community online (subreddit). Puoi riscattare tali token in una subreddit per ottenere privilegi e vantaggi esclusivi. Per questo progetto, Reddit sta lavorando con Arbitrum, una rete di [livello 2](/glossary/#layer-2) progettata per ridimensionare le transazioni di Ethereum.
@@ -84,9 +84,9 @@ Il programma è già attivo: la subreddit r/CryptoCurrency [adopera la propria v
Oltre a utilizzare i Punti della Community per sbloccare funzionalità speciali, gli utenti possono anche scambiarli per valuta legale nelle piattaforme di scambio. Inoltre, l'importo di Punti della Community posseduto da un utente ne determina l'influenza sul processo decisionale all'interno della community.
-## Lettura consigliate {#further-reading}
+## Lettura consigliate {#brave}
-### Articoli {#articles}
+### Articoli {#audius}
- [Decentralizzare i social: una guida allo stack dei social di Web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) - _Coinbase Ventures_
- [I social sono la prossima grande opportunità per la decentralizzazione](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) - _Ben Goertzel_
@@ -95,12 +95,12 @@ Oltre a utilizzare i Punti della Community per sbloccare funzionalità speciali,
- [In che modo la blockchain può risolvere la privacy dei social](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) - _Prableen Bajpai_
- [Decentralizzazione sufficiente per i social](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) - _Varun Srinivasan_
-### Video {#videos}
+### Video {#sorare}
- [Social decentralizzati spiegati](https://www.youtube.com/watch?v=UdT2lpcGvcQ) - _Coinmarketcap_
- [La blockchain DeSo vuole decentralizzare i social](https://www.youtube.com/watch?v=SG2HUiVp0rE) - _Bloomberg Technology_
- [Il futuro dei social decentralizzati, con Balaji Srinivasan, Vitalik Buterin e Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) - _ETHGlobal_
-### Community {#communities}
+### Community {#twitter}
- [Subreddit r/CryptoCurrency](https://www.reddit.com/r/CryptoCurrency/)
diff --git a/public/content/translations/it/staking/dvt/index.md b/public/content/translations/it/staking/dvt/index.md
index d2f9a11efe2..b719b9c0de7 100644
--- a/public/content/translations/it/staking/dvt/index.md
+++ b/public/content/translations/it/staking/dvt/index.md
@@ -1,6 +1,6 @@
---
title: Tecnologia del validatore distribuito
-description: La tecnologia del validatore distribuito consente l'operazione distribuita di un validatore di Ethereum da più parti.
+description: "La tecnologia del validatore distribuito consente l'operazione distribuita di un validatore di Ethereum da più parti."
lang: it
---
diff --git a/public/content/translations/it/staking/solo/index.md b/public/content/translations/it/staking/solo/index.md
index d1460e62efc..629e55fc205 100644
--- a/public/content/translations/it/staking/solo/index.md
+++ b/public/content/translations/it/staking/solo/index.md
@@ -71,6 +71,7 @@ Differente dalle sanzioni di inattività per esser offline, il taglio Ulteriori informazioni sullo slashing e sul ciclo di vita dei validatori
+
@@ -130,7 +131,6 @@ Esistono alcune domande molto comuni sullo staking che meritano di essere affron
Un validatore è un'entità virtuale che risiede su Ethereum e partecipa al consenso del protocollo di Ethereum. I validatori sono rappresentati da un saldo, una chiave pubblica e altre proprietà. Un client del validatore è il software che agisce per conto del validatore detenendone e usandone la chiave privata. Un singolo client del validatore può detenere molte coppie di chiavi, controllando molti validatori.
-
diff --git a/public/content/translations/it/staking/withdrawals/index.md b/public/content/translations/it/staking/withdrawals/index.md
index da48375cdc0..e0317c01898 100644
--- a/public/content/translations/it/staking/withdrawals/index.md
+++ b/public/content/translations/it/staking/withdrawals/index.md
@@ -166,7 +166,6 @@ eventName="read more">
Se fai parte di un [pool di staking](/staking/pools/) o detieni token di staking, dovresti chiedere al tuo fornitore ulteriori dettagli su come vengono gestiti i prelievi dallo staking, poiché ogni servizio opera in modo diverso.
In generale, gli utenti dovrebbero essere liberi di rivendicare i propri ETH in staking sottostanti, o di modificare il fornitore di staking che utilizzano. Se un pool in particolare sta diventando troppo grande, è possibile uscire, riscattare i fondi e rimetterli in staking con un fornitore di dimensioni minori. O, se hai accumulato abbastanza ETH, potresti [fare staking da casa](/staking/solo/).
-
No, se il tuo validatore è ancora attivo sulla rete, un prelievo completo non si verificherà automaticamente. Questo richiede l'avvio manuale di un'uscita volontaria.
Una volta che un validatore ha completato il procedimento di uscita e supponendo che il conto abbia le credenziali di prelievo, il saldo rimanente sarà then prelevato durante la successivapulizia del validatore.
-
Gli operatori del validatore dovrebbero visitare la pagina dei Prelievi del Launchpad di Staking, dove troveranno ulteriori dettagli su come preparare il proprio validatore ai prelievi, le tempistiche degli eventi e ulteriori dettagli sul funzionamento dei prelievi.
Per testare la tua configurazione su una rete di prova, visita il Launchpad di Staking della rete di prova di Holesky per iniziare.
-