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/poa/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md
index aa10661a7cb..744486b8bdc 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
---
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..9017d3116b8 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
---
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..5dabb469e8a 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,6 +1,6 @@
---
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
---
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..5c34d9ab106 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
---
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..6b7c5c89975 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,7 +8,7 @@ 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 è 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!
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/learn-foundational-ethereum-topics-with-sql/index.md b/public/content/translations/it/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md
index bfa2f23fd63..42c43b4be78 100644
--- a/public/content/translations/it/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md
+++ b/public/content/translations/it/developers/tutorials/learn-foundational-ethereum-topics-with-sql/index.md
@@ -1,11 +1,8 @@
---
title: Imparare gli argomenti fondamentali di Ethereum con SQL
-description: Questo tutorial aiuta i lettori a comprendere i concetti fondamentali di Ethereum, incluse le transazioni, i blocchi e il gas, interrogando i dati sulla catena con il Linguaggio di Richiesta Strutturato (SQL).
+description: Questo tutorial aiuta i lettori a comprendere i concetti fondamentali di Ethereum, incluse le transazioni, i blocchi e il gas, interrogando i dati on-chain con lo Structured Query Language (SQL).
author: "Paul Apivat"
-tags:
- - "SQL"
- - "Interrogazioni"
- - "Transazioni"
+tags: [ "SQL", "Interrogazione", "Transazioni" ]
skill: beginner
lang: it
published: 2021-05-11
@@ -13,27 +10,27 @@ source: paulapivat.com
sourceUrl: https://paulapivat.com/post/query_ethereum/
---
-Molti tutorial di Ethereum sono rivolti agli sviluppatori, mancano invece risorse educative per gli analisti di dati o per le persone che vogliono visualizzare dati sulla catena senza eseguire un client o un nodo.
+Molti tutorial di Ethereum sono rivolti agli sviluppatori, ma mancano risorse didattiche per gli analisti di dati o per le persone che desiderano visualizzare i dati on-chain senza eseguire un client o un nodo.
-Questo tutorial aiuta i lettori a comprendere i concetti fondamentali di Ethereum, incluse le transazioni, i blocchi e il gas, interrogando i dati sulla catena con il linguaggio di richiesta strutturato (SQL), tramite un'interfaccia fornita da [Dune Analytics](https://dune.xyz/home).
+Questo tutorial aiuta i lettori a comprendere i concetti fondamentali di Ethereum, tra cui transazioni, blocchi e gas, interrogando i dati on-chain con il linguaggio di interrogazione strutturato (SQL) tramite un'interfaccia fornita da [Dune Analytics](https://dune.com/).
-I dati sulla catena possono aiutarci a comprendere Ethereum, la rete, come un'economia per la potenza di calcolo, e dovrebbero servire da base per comprendere le sfide che Ethereum affronta oggi (cioè, l'aumento dei prezzi del gas) e, soprattutto, le discussioni sulle soluzioni di ridimensionamento.
+I dati on-chain possono aiutarci a comprendere Ethereum, la rete e un'economia per la potenza di calcolo e dovrebbero servire da base per comprendere le sfide che Ethereum affronta oggi (ad esempio, l'aumento dei prezzi del gas) e, cosa più importante, le discussioni sulle soluzioni di ridimensionamento.
### Transazioni {#transactions}
-Il percorso di un utente su Ethereum inizia inizializzando il conto controllato da un utente o da un'entità, con un saldo di ETH. Esistono due tipi di conto: controllato dall'utente o contratto intelligente (vedi [ethereum.org](/developers/docs/accounts/)).
+Il percorso di un utente su Ethereum inizia inizializzando un conto controllato da un utente o un'entità con un saldo in ETH. Esistono due tipi di conto: controllato dall'utente o un contratto intelligente (vedi [ethereum.org](/developers/docs/accounts/)).
-Ogni conto è visualizzabile su un esploratore di blocchi come [Etherscan](https://etherscan.io/). Gli esploratori di blocchi sono un portale ai dati di Ethereum. Mostrano, in tempo reale, i dati su blocchi, transazioni, miner, conti e altre attività sulla catena (vedi [qui](/developers/docs/data-and-analytics/block-explorers/)).
+Qualsiasi conto può essere visualizzato su un esploratore di blocchi come [Etherscan](https://etherscan.io/) o [Blockscout](https://eth.blockscout.com/). Gli esploratori di blocchi sono un portale per i dati di Ethereum. Visualizzano, in tempo reale, dati su blocchi, transazioni, miner, conti e altre attività on-chain (vedi [qui](/developers/docs/data-and-analytics/block-explorers/)).
-Tuttavia, è possibile che un utente voglia interrogare i dati direttamente per riconciliare le informazioni fornite da esploratori di blocchi esterni. [Dune Analytics](https://duneanalytics.com/)mette a disposizione questa capacità a chiunque abbia una conoscenza di SQL.
+Tuttavia, un utente potrebbe voler interrogare i dati direttamente per riconciliare le informazioni fornite dagli esploratori di blocchi esterni. [Dune Analytics](https://dune.com/) fornisce questa funzionalità a chiunque abbia una certa conoscenza di SQL.
-Per riferimento, il conto del contratto intelligente per la Ethereum Foundation (EF) può essere visualizzato su [Etherscan](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae).
+Come riferimento, il conto del contratto intelligente della Ethereum Foundation (EF) può essere visualizzato su [Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe).
-Una cosa da notare è che tutti i conti, incluso quello dell'EF, hanno un indirizzo pubblico, utilizzabile per inviare e ricevere le transazioni.
+Da notare che tutti i conti, compreso quello dell'EF, hanno un indirizzo pubblico che può essere utilizzato per inviare e ricevere transazioni.
-Il saldo del conto su Etherscan comprende transazioni regolari e interne. Le transazioni interne, nonostante il nome, non sono transazioni _reali_ che modificano lo stato della catena. Sono trasferimenti di valore avviati eseguendo un contratto ([sorgente](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions)). Poiché le transazioni interne non hanno firma, **non** sono incluse sulla blockchain e non sono interrogabili con Dune Analytics.
+Il saldo del conto su Etherscan comprende transazioni regolari e transazioni interne. Le transazioni interne, nonostante il nome, non sono transazioni _effettive_ che modificano lo stato della catena. Sono trasferimenti di valore avviati dall'esecuzione di un contratto ([fonte](https://ethereum.stackexchange.com/questions/3417/how-to-get-contract-internal-transactions)). Poiché le transazioni interne non hanno firma, **non** sono incluse nella blockchain e non possono essere interrogate con Dune Analytics.
-Questo tutorial si concentrerà dunque sulle transazioni regolari. Queste sono interrogabili come segue:
+Pertanto, questo tutorial si concentrerà sulle transazioni regolari. Possono essere interrogate come segue:
```sql
WITH temp_table AS (
@@ -61,33 +58,33 @@ SELECT
FROM temp_table
```
-Questo produrrà le stesse informazioni fornite sulla pagina della transazione di Etherscan. A titolo di confronto, ecco le due sorgenti:
+Questo restituirà le stesse informazioni fornite sulla pagina delle transazioni di Etherscan. Per confronto, ecco le due fonti:
#### Etherscan {#etherscan}
-[Pagina del contratto dell'EF su Etherscan.](https://etherscan.io/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)
+[Pagina del contratto dell'EF su Blockscout.](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)
#### Dune Analytics {#dune-analytics}
-Puoi trovare la dashboard [qui](https://duneanalytics.com/paulapivat/Learn-Ethereum). Clicca sulla tabella per vedere l'interrogazione (vedi anche sopra).
+La dashboard è disponibile [qui](https://dune.com/paulapivat/Learn-Ethereum). Fare clic sulla tabella per visualizzare la query (vedi anche sopra).
-### Spezzare le Transazioni {#breaking_down_transactions}
+### Analisi dettagliata delle transazioni {#breaking_down_transactions}
-Una transazione inviata presenta diverse informazioni, tra cui ([sorgente](/developers/docs/transactions/)):
+Una transazione inviata include diverse informazioni, tra cui ([fonte](/developers/docs/transactions/)):
-- **Destinatario**: l'indirizzo ricevente (interrogato come "a")
-- **Firma**: mentre le chiavi private di un mittente firmano una transazione, con SQL possiamo interrogare l'indirizzo pubblico di un mittente ("da").
-- **Valore**: questo è l'importo di ETH trasferito (vedi la colonna di `ether`).
-- **Dati**: sono i dati arbitrari che hanno ricevuto l'hashing (vedi la colonna `data`)
-- **gasLimit**: l'importo massimo di unità di gas consumabili dalla transazione. Le unità di gas rappresentano le fasi di calcolo
-- **maxPriorityFeePerGas**: l'importo massimo di gas da includere come mancia al miner
-- **maxFeePerGas**: l'importo massimo di gas che si è disposti a pagare per la transazione (inclusiva di baseFeePerGas e maxPriorityFeePerGas)
+- **Destinatario**: l'indirizzo di ricezione (interrogato come "to")
+- **Firma**: mentre le chiavi private di un mittente firmano una transazione, ciò che possiamo interrogare con SQL è l'indirizzo pubblico di un mittente ("from").
+- **Valore**: questo è l'importo di ETH trasferito (vedi la colonna `ether`).
+- **Dati**: sono dati arbitrari a cui è stato applicato l'hashing (vedi la colonna `data`)
+- **gasLimit** – la quantità massima di unità di gas che può essere consumata dalla transazione. Le unità di gas rappresentano i passaggi computazionali
+- **maxPriorityFeePerGas** - l'importo massimo di gas da includere come mancia per il miner
+- **maxFeePerGas** - l'importo massimo di gas che si è disposti a pagare per la transazione (comprensivo di baseFeePerGas e maxPriorityFeePerGas)
-Possiamo richiedere informazioni specifici per le transazioni all'indirizzo pubblico della Ethereum Foundation:
+Possiamo interrogare queste informazioni specifiche per le transazioni verso l'indirizzo pubblico della Ethereum Foundation:
```sql
SELECT
@@ -106,15 +103,15 @@ ORDER BY block_time DESC
### Blocchi {#blocks}
-Ogni transazione cambierà lo stato della macchina virtuale di Ethereum ([EVM](/developers/docs/evm/)) ([sorgente](/developers/docs/transactions/)). Le transazioni sono trasmesse alla rete per esser verificate e incluse in un blocco. Ogni transazione è associata al numero di un blocco. Per vedere i dati, potremmo interrogare un numero di blocco specifico: 12396854 (il blocco più recente tra le transazioni di Ethereum Foundation al momento della scrittura, 05/11/2021).
+Ogni transazione modificherà lo stato della macchina virtuale di Ethereum ([EVM](/developers/docs/evm/)) ([fonte](/developers/docs/transactions/)). Le transazioni vengono trasmesse alla rete per essere verificate e incluse in un blocco. Ogni transazione è associata a un numero di blocco. Per visualizzare i dati, potremmo interrogare un numero di blocco specifico: 12396854 (il blocco più recente tra le transazioni della Ethereum Foundation al momento della stesura, 05/11/21).
-Inoltre, quando interroghiamo i due blocchi successivi, possiamo vedere che ogni blocco contiene l'hash del blocco precedente (cioè l'hash padre), e questo illustra com'è formata la blockchain.
+Inoltre, quando interroghiamo i due blocchi successivi, possiamo vedere che ogni blocco contiene l'hash del blocco precedente (cioè l'hash genitore), illustrando come si forma la blockchain.
-Ogni blocco contiene un riferimento al suo blocco padre. Questo è mostrato di sotto tra le colonne `hash` e `parent_hash` ([sorgente](/developers/docs/blocks/)):
+Ogni blocco contiene un riferimento al suo blocco genitore. Ciò è mostrato di seguito tra le colonne `hash` e `parent_hash` ([fonte](/developers/docs/blocks/)):
-Ecco l'[interrogazione](https://duneanalytics.com/queries/44856/88292) su Dune Analytics:
+Ecco la [query](https://dune.com/queries/44856/88292) su Dune Analytics:
```sql
SELECT
@@ -128,16 +125,16 @@ WHERE "number" = 12396854 OR "number" = 12396855 OR "number" = 12396856
LIMIT 10
```
-Possiamo esaminare un blocco interrogando orario, numero del blocco, difficoltà, hash, hash padre e nonce.
+Possiamo esaminare un blocco interrogando ora, numero del blocco, difficoltà, hash, hash genitore e nonce.
-L'unica cosa che questa interrogazione non copre è l'_elenco di transazioni_, che richiede un'apposita interrogazione successiva, e il _root di stato_. Un nodo completo o d'archivio memorizzerà tutte le transazioni e transizioni di stato, consentendo ai client di interrogare lo stato della catena in qualsiasi momento. Poiché questo richiede un grande spazio d'archiviazione, possiamo separare i dati della catena dai dati di stato:
+L'unica cosa che questa query non copre è l'_elenco delle transazioni_, che richiede una query separata di seguito, e la _radice di stato_. Un nodo completo o di archivio memorizzerà tutte le transazioni e le transizioni di stato, consentendo ai client di interrogare lo stato della catena in qualsiasi momento. Poiché ciò richiede un ampio spazio di archiviazione, possiamo separare i dati della catena dai dati di stato:
- Dati della catena (elenco di blocchi, transazioni)
- Dati di stato (risultato della transizione di stato di ogni transazione)
-Il root di stato rientra nel secondo gruppo e si compone di dati _impliciti_ (non memorizzati sulla catena), mentre i dati della catena sono espliciti e memorizzati nella catena stessa ([sorgente](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored)).
+La radice di stato rientra in quest'ultima categoria ed è un dato _implicito_ (non memorizzato on-chain), mentre i dati della catena sono espliciti e memorizzati sulla catena stessa ([fonte](https://ethereum.stackexchange.com/questions/359/where-is-the-state-data-stored)).
-Per questo tutorial, ci concentreremo sui dati sulla catena che sono _interrogabili_ con SQL tramite Dune Analytics.
+Per questo tutorial, ci concentreremo sui dati on-chain che _possono_ essere interrogati con SQL tramite Dune Analytics.
Come indicato sopra, ogni blocco contiene un elenco di transazioni, possiamo interrogarlo filtrando per un blocco specifico. Proveremo con il blocco più recente, 12396854:
@@ -147,13 +144,13 @@ WHERE block_number = 12396854
ORDER BY block_time DESC`
```
-Ecco l'output in SQL su Dune:
+Ecco l'output SQL su Dune:
-Questo singolo blocco aggiunto alla catena cambia lo stato della macchina virtuale di Ethereum ([EVM](/developers/docs/evm/)). Dozzine, a volte, centinaia di transazioni vengono verificate in un solo colpo. In questo caso specifico, sono state incluse 222 transazioni.
+Questo singolo blocco, aggiunto alla catena, modifica lo stato della macchina virtuale di Ethereum ([EVM](/developers/docs/evm/)). Decine, a volte centinaia, di transazioni vengono verificate contemporaneamente. In questo caso specifico, sono state incluse 222 transazioni.
-Per vedere quante sono realmente riuscite, aggiungeremmo un altro filtro per contare le transazioni riuscite:
+Per vedere quante hanno avuto effettivamente successo, aggiungeremmo un altro filtro per contare le transazioni andate a buon fine:
```sql
WITH temp_table AS (
@@ -166,15 +163,15 @@ SELECT
FROM temp_table
```
-Per il blocco 12396854, di 222 transazioni totali, 204 sono state verificate correttamente:
+Per il blocco 12396854, su un totale di 222 transazioni, 204 sono state verificate con successo:
-Le richieste di transazioni si verificano dozzine di volte al secondo, ma i blocchi sono impegnati approssimativamente ogni 15 secondi ([sorgente](/developers/docs/blocks/)).
+Le richieste di transazione avvengono decine di volte al secondo, ma i blocchi vengono confermati circa una volta ogni 15 secondi ([fonte](/developers/docs/blocks/)).
-Per vedere che un blocco è prodotto approssimativamente ogni 15 secondi, potremmo prendere il numero di secondi in una giornata (86400) diviso per 15 per ottenere un numero medio stimato di blocchi al giorno (circa 5760).
+Per vedere che un blocco viene prodotto circa ogni 15 secondi, potremmo prendere il numero di secondi in un giorno (86.400) e dividerlo per 15 per ottenere un numero medio stimato di blocchi al giorno (~ 5.760).
-Il grafico per i blocchi di Ethereum prodotti al giorno (2016 - presente) è:
+Il grafico dei blocchi di Ethereum prodotti al giorno (2016 - oggi) è:
@@ -182,10 +179,10 @@ Il numero medio di blocchi prodotti giornalmente in questo periodo di tempo è d
-Le interrogazioni sono:
+Le query sono:
```sql
-# query to visualize number of blocks produced daily since 2016
+# query per visualizzare il numero di blocchi prodotti giornalmente dal 2016
SELECT
DATE_TRUNC('day', time) AS dt,
@@ -194,7 +191,7 @@ FROM ethereum."blocks"
GROUP BY dt
OFFSET 1
-# average number of blocks produced per day
+# numero medio di blocchi prodotti al giorno
WITH temp_table AS (
SELECT
@@ -209,13 +206,13 @@ SELECT
FROM temp_table
```
-Il numero medio di blocchi prodotto ogni giorno dal 2016 è lievemente superiore a quel numero, a 5.874. In alternativa, dividendo 86400 secondi per i 5874 blocchi medi, si ottiene 14,7 secondi, pari a circa un blocco ogni 15 secondi.
+Il numero medio di blocchi prodotti al giorno dal 2016 è leggermente superiore a tale numero, attestandosi a 5.874. In alternativa, dividendo 86.400 secondi per 5.874 blocchi medi si ottengono 14,7 secondi, ovvero circa un blocco ogni 15 secondi.
### Gas {#gas}
-I blocchi hanno dimensioni limitate. La dimensione massima del blocco è dinamica e varia a seconda della domanda di rete, tra le 12.500.000 e le 25.000.000 unità. I limiti sono necessari per evitare che le dimensioni arbitrariamente grandi dei blocchi mettano a dura prova i nodi completi, in termini di requisiti di spazio su disco e velocità ([fonte](/developers/docs/blocks/)).
+I blocchi hanno dimensioni limitate. La dimensione massima del blocco è dinamica e varia a seconda della domanda della rete tra 12.500.000 e 25.000.000 di unità. I limiti sono necessari per evitare che le dimensioni arbitrariamente grandi dei blocchi mettano a dura prova i nodi completi, in termini di requisiti di spazio su disco e velocità ([fonte](/developers/docs/blocks/)).
-Un modo per concettualizzare il limite di gas del blocco è immaginarlo come l'**offerta** di spazio del blocco disponibile, in cui raggruppare le transazioni. Il limite di gas del blocco è interrogabile e visualizzabile dal 2016 a oggi:
+Un modo per concettualizzare il limite del gas del blocco è immaginarlo come l'**offerta** di spazio disponibile nel blocco in cui raggruppare le transazioni. Il limite del gas del blocco può essere interrogato e visualizzato dal 2016 a oggi:
@@ -228,7 +225,7 @@ GROUP BY dt
OFFSET 1
```
-Poi, c'è il gas effettivo, usato quotidianamente per pagare i calcoli effettuati sulla catena di Ethereum (cioè, l'invio della transazione, la chiamata di un contratto intelligente, il conio di un NFT). Questa è la **domanda** di spazio per i blocchi disponibile di Ethereum:
+Poi, c'è il gas effettivo, usato quotidianamente per pagare i calcoli effettuati sulla catena di Ethereum (cioè, l'invio della transazione, la chiamata di un contratto intelligente, il conio di un NFT). Questa è la **domanda** di spazio disponibile per i blocchi di Ethereum:
@@ -245,13 +242,13 @@ Possiamo anche giustapporre questi due grafici insieme per vedere come si alline
-Dunque, possiamo comprendere i prezzi del gas come una funzione di domanda per lo spazio del blocco di Ethereum, data l'offerta disponibile.
+Dunque, possiamo comprendere i prezzi del gas come una funzione della domanda di spazio per i blocchi di Ethereum, data l'offerta disponibile.
-Infine, potremmo voler interrogare i prezzi del gas quotidiani medi per la catena di Ethereum, tuttavia, farlo risulterà in un tempo di richiesta particolarmente lungo, quindi filtreremo la nostra richiesta all'importo medio di gas pagato per transazione dall'Ethereum Foundation.
+Infine, potremmo voler interrogare i prezzi medi giornalieri del gas per la catena di Ethereum, tuttavia, farlo comporterebbe un tempo di interrogazione particolarmente lungo, quindi filtreremo la nostra query sull'importo medio di gas pagato per transazione dalla Ethereum Foundation.
-Possiamo vedere i prezzi del gas pagati per tutte le transazioni effettuate all'indirizzo dell'Ethereum Foundation negli anni. Ecco l'interrogazione:
+Possiamo vedere i prezzi del gas pagati per tutte le transazioni effettuate all'indirizzo dell'Ethereum Foundation negli anni. Ecco la query:
```sql
SELECT
@@ -265,8 +262,8 @@ ORDER BY block_time DESC
### Riepilogo {#summary}
-Con questo tutorial esaminiamo i concetti fondamentali di Ethereum e come funziona la blockchain di Ethereum interrogando e comprendendo i dati sulla catena.
+Con questo tutorial, comprendiamo i concetti fondamentali di Ethereum e il funzionamento della blockchain di Ethereum, interrogando e familiarizzando con i dati on-chain.
-La dashboard che contiene tutto il codice usato in questo tutorial si può trovare [qui](https://duneanalytics.com/paulapivat/Learn-Ethereum).
+La dashboard che contiene tutto il codice utilizzato in questo tutorial è disponibile [qui](https://dune.com/paulapivat/Learn-Ethereum).
-Per altri usi dei dati per l'esplorazione di web3 [cercami su Twitter](https://twitter.com/paulapivat).
+Per ulteriori utilizzi dei dati per esplorare il web3, [trovami su Twitter](https://twitter.com/paulapivat).
diff --git a/public/content/translations/it/developers/tutorials/logging-events-smart-contracts/index.md b/public/content/translations/it/developers/tutorials/logging-events-smart-contracts/index.md
index 5c6624399c7..637aae0473c 100644
--- a/public/content/translations/it/developers/tutorials/logging-events-smart-contracts/index.md
+++ b/public/content/translations/it/developers/tutorials/logging-events-smart-contracts/index.md
@@ -1,12 +1,8 @@
---
-title: Registrare dati dagli Smart Contract con gli eventi
-description: Introduzione agli eventi degli Smart Contract e come usarli per registrare dati
+title: Registrazione di dati da contratti intelligenti con eventi
+description: Un'introduzione agli eventi dei contratti intelligenti e a come utilizzarli per registrare dati
author: "jdourlens"
-tags:
- - "contratti intelligenti"
- - "remix"
- - "solidity"
- - "eventi"
+tags: [ "smart contract", "remix", "Solidity", "eventi" ]
skill: intermediate
lang: it
published: 2020-04-03
@@ -15,19 +11,19 @@ sourceUrl: https://ethereumdev.io/logging-data-with-events/
address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
---
-In Solidity, gli [eventi](/developers/docs/smart-contracts/anatomy/#events-and-logs) sono segnali inviati che possono essere attivati dagli Smart Contract. Le dapp, o qualsiasi cosa sia connessa all'API di JSON-RPC di Ethereum, possono ascoltare questi eventi e agire di conseguenza. Gli eventi sono anche indicizzabili così che la cronologia dell'evento sia ricercabile in seguito.
+In Solidity, gli [eventi](/developers/docs/smart-contracts/anatomy/#events-and-logs) sono segnali inviati che i contratti intelligenti possono attivare. Le dApp, o qualsiasi cosa connessa all'API JSON-RPC di Ethereum, possono ascoltare questi eventi e agire di conseguenza. Un evento può anche essere indicizzato in modo che la cronologia dell'evento sia ricercabile in seguito.
## Eventi {#events}
-L'evento più comune sulla blockchain Ethereum al momento della scrittura di questo articolo è l'evento Transfer, emesso dai token ERC20 quando qualcuno trasferisce token.
+L'evento più comune sulla blockchain di Ethereum al momento della stesura di questo articolo è l'evento Transfer, emesso dai token ERC20 quando qualcuno trasferisce dei token.
```solidity
event Transfer(address indexed from, address indexed to, uint256 value);
```
-Le firme dell'evento sono dichiarate nel codice del contratto e possono essere emesse con la parola chiave emit. Per esempio l'evento transfer registra chi ha inviato il trasferimento (_from_), a chi (_to_) e quanti token sono stati trasferiti (_value_).
+La firma dell'evento è dichiarata all'interno del codice del contratto e può essere emessa con la parola chiave emit. Ad esempio, l'evento transfer registra chi ha inviato il trasferimento (_from_), a chi (_to_) e quanti token sono stati trasferiti (_value_).
-Torniamo al nostro Smart Contract Counter e decidiamo di registrare ogni volta che il valore cambia. Poiché questo contratto non è inteso per la distribuzione ma serve come base per la costruzione di un altro contratto tramite estensione, è detto contratto astratto. Nel caso del nostro esempio Counter somiglierà a:
+Se torniamo al nostro contratto intelligente Counter e decidiamo di registrare ogni volta che il valore viene modificato. Poiché questo contratto non è destinato a essere distribuito ma a fungere da base per la creazione di un altro contratto tramite estensione, è detto contratto astratto. Nel caso del nostro esempio Counter, il risultato sarà il seguente:
```solidity
pragma solidity 0.5.17;
@@ -36,16 +32,16 @@ contract Counter {
event ValueChanged(uint oldValue, uint256 newValue);
- // Variabile privata di tipo int senza segno per tenere il numero di conteggi
+ // Variabile privata di tipo intero senza segno per conservare il numero di conteggi
uint256 private count = 0;
- // Funzione che incrementa il Counter
+ // Funzione che incrementa il nostro contatore
function increment() public {
count += 1;
emit ValueChanged(count - 1, count);
}
- // Getter per ottenere il valore di conteggio
+ // Getter per ottenere il valore del conteggio
function getCount() public view returns (uint256) {
return count;
}
@@ -57,10 +53,10 @@ Da notare:
- **Riga 5**: dichiariamo l'evento e cosa contiene, il vecchio e il nuovo valore.
-- **Riga 13**: quando aumentiamo la variabile di conteggio, emettiamo l'evento.
+- **Riga 13**: quando incrementiamo la nostra variabile di conteggio, emettiamo l'evento.
-Se ora distribuiamo il contratto e chiamiamo la funzione di incremento, vedremo che Remix lo mostrerà automaticamente se clicchiamo sulla nuova transazione all'interno di un array di registri con nome.
+Se ora distribuiamo il contratto e chiamiamo la funzione di incremento, vedremo che Remix lo mostrerà automaticamente se facciamo clic sulla nuova transazione all'interno di un array chiamato logs.
-I registri sono davvero utili per il debug degli Smart Contract ma sono anche importanti se si creano applicazioni usate da persone diverse e facilitano l'analisi per monitorare e comprendere come viene usato lo Smart Contract. I registri generati da transazioni sono mostrati in block explorer popolari e ad esempio si possono usare per creare script esterni alla catena, con lo scopo di attendere eventi specifici ed eseguire determinate azioni quando si verificano.
+I log sono molto utili per il debug dei contratti intelligenti, ma sono anche importanti se si creano applicazioni usate da persone diverse e facilitano l'analisi per monitorare e comprendere come viene usato il contratto intelligente. I log generati dalle transazioni sono visualizzati nei più diffusi esploratori di blocchi e si possono anche usare, ad esempio, per creare script fuori dalla catena che restino in ascolto di eventi specifici e intraprendano azioni quando questi si verificano.
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..d0b2e6c7752 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,9 +1,8 @@
---
-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 che sono archiviati, per lo più, fuori dalla catena"
author: Ori Pomerantz
-tags:
- - "archiviazione"
+tags: [ "archiviazione" ]
skill: advanced
lang: it
published: 2021-12-30
@@ -13,9 +12,11 @@ published: 2021-12-30
Idealmente, vorremmo archiviare tutto nell'archiviazione di Ethereum, memorizzata tra migliaia di computer e avente una disponibilità estremamente elevata (i dati non sono censurabili) e integrità (i dati non sono modificabili in un modo non autorizzato), ma archiviare una parola di 32 byte costa tipicamente 20.000 gas. Mentre scriviamo il presente articolo, tale costo equivale a 6,60 dollari. Ne consegue che 21 centesimi per byte sia un costo impraticabile per molti utilizzi.
-Per risolvere questo problema l'ecosistema di Ethereum ha sviluppato [molti metodi alternativi per memorizzare dati in modo decentralizzato](/developers/docs/storage/). Solitamente occorre raggiungere un compromesso tra disponibilità e prezzo, mentre l'integrità è generalmente garantita.
+Per risolvere questo problema, l'ecosistema di Ethereum ha sviluppato molti modi alternativi per memorizzare i dati in modo decentralizzato
+. Solitamente occorre raggiungere un compromesso tra disponibilità e prezzo, mentre l'integrità è generalmente garantita.
-In questo articolo imparerai **come** garantire l'integrità dei dati senza memorizzare i dati sulla blockchain, usando le [prove di Merkle](https://computersciencewiki.org/index.php/Merkle_proof).
+In questo articolo imparerà **come** garantire l'integrità dei dati senza memorizzare i dati sulla blockchain, utilizzando
+le [prove di Merkle](https://computersciencewiki.org/index.php/Merkle_proof).
## Come funziona? {#how-does-it-work}
@@ -25,19 +26,19 @@ La soluzione consiste nel procedere ripetutamente all'hashing di diverse sottose
-L'hash principale è l'unica parte che deve essere memorizzata sulla catena. Per provare un dato valore, occorre fornire tutti gli hash che devono essere combinati con esso per ottenere il root. Ad esempio, per provare `C`, occorre fornire `D`, `H(A-B)` e `H(E-H)`.
+L'hash radice è l'unica parte che deve essere memorizzata sulla catena. Per provare un dato valore, occorre fornire tutti gli hash che devono essere combinati con esso per ottenere il root. Ad esempio, per provare `C` occorre fornire `D`, `H(A-B)` e `H(E-H)`.
## Implementazione {#implementation}
-[Il campione di codice è disponibile qui](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity).
+[Il codice di esempio è fornito qui](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity).
-### Codice esterno alla catena {#off-chain-code}
+### Codice fuori dalla 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.
+In questo articolo usiamo JavaScript per i calcoli fuori dalla catena. La maggior parte delle applicazioni decentralizzate ha la propria componente fuori dalla catena in JavaScript.
-#### Creare il root di Merkle {#creating-the-merkle-root}
+#### Creazione della radice di Merkle {#creating-the-merkle-root}
Prima dobbiamo fornire il root di Merkle alla catena.
@@ -45,48 +46,52 @@ Prima dobbiamo fornire il root di Merkle alla catena.
const ethers = require("ethers")
```
-[Usiamo la funzione hash dal pacchetto ethers](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256).
+[Utilizziamo la funzione hash dal pacchetto Ethers](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256).
```javascript
-// The raw data whose integrity we have to verify. The first two bytes a
-// are a user identifier, and the last two bytes the amount of tokens the
-// user owns at present.
+// I dati grezzi di cui dobbiamo verificare l'integrità. I primi due byte
+// sono un identificatore utente e gli ultimi due byte la quantità di token che
+// l'utente possiede al momento.
const dataArray = [
0x0bad0010, 0x60a70020, 0xbeef0030, 0xdead0040, 0xca110050, 0x0e660060,
0xface0070, 0xbad00080, 0x060d0091,
]
```
-Codificando ogni voce in un unico numero intero da 256 bit si ottiene un codice meno leggibile rispetto, ad esempio, all'utilizzo di JSON. Tuttavia, ciò comporta un'elaborazione significativamente ridotta per recuperare i dati nel contratto, quindi costi del gas molto inferiori. [JSON può essere letto sulla catena](https://github.com/chrisdotn/jsmnSol), ma è una cattiva idea, quindi se possibile consigliamo di evitarlo.
+Codificando ogni voce in un unico numero intero da 256 bit si ottiene un codice meno leggibile rispetto, ad esempio, all'utilizzo di JSON. Tuttavia, ciò comporta un'elaborazione significativamente ridotta per recuperare i dati nel contratto, quindi costi del gas molto inferiori. [È possibile leggere JSON sulla catena](https://github.com/chrisdotn/jsmnSol), ma è una pessima idea se evitabile.
```javascript
-// The array of hash values, as BigInts
+// L'insieme di valori di hash, come BigInts
const hashArray = dataArray
```
In questo caso, per iniziare i nostri dati sono valori da 256 bit, quindi non è necessaria alcuna elaborazione. Se usiamo una struttura di dati più complicata, come le stringhe, dovremo assicurarci di eseguire per prima cosa l'hashing dei dati, così da ottenere un insieme di hash. Anche questo, ricordiamo che non importa se gli utenti conoscono le informazioni altrui. In caso contrario, dovremmo eseguire l'hashing in modo tale che l'utente 1 non conosca il valore per l'utente 0, l'utente 2 non conosca il valore per l'utente 3, ecc.
```javascript
-// Convert between the string the hash function expects and the
-// BigInt we use everywhere else.
+// Converte tra la stringa che la funzione hash si aspetta e il
+// BigInt che usiamo altrove.
const hash = (x) =>
BigInt(ethers.utils.keccak256("0x" + x.toString(16).padStart(64, 0)))
```
-La funzione hash di ethers prevede di ottenere una stringa in JavaScript con un numero esadecimale, come `0x60A7` e rispondere con un'altra stringa con la stessa struttura. Tuttavia, per il resto del codice è più facile usare `BigInt`, in modo da poter convertire in una stringa esadecimale e tornare indietro.
+La funzione hash di Ethers si aspetta di ricevere una stringa JavaScript con un numero esadecimale, come `0x60A7`, e risponde con un'altra stringa con la stessa struttura. Tuttavia, per il resto del codice è più facile usare `BigInt`, quindi convertiamo in una stringa esadecimale e viceversa.
```javascript
-// Symmetrical hash of a pair so we won't care if the order is reversed.
+// Hash simmetrico di una coppia, così non ci importerà se l'ordine viene invertito.
const pairHash = (a, b) => hash(hash(a) ^ hash(b))
```
-Questa funzione è simmetrica (hash di una b [xor](https://en.wikipedia.org/wiki/Exclusive_or)). Questo significa che quando controlliamo la prova di Merkle, non dobbiamo preoccuparci di mettere il valore dalla prova prima o dopo il valore calcolato. Il controllo della prova di Merkle ha luogo sulla catena, quindi meno bisogna fare lì, meglio è.
+Questa funzione è simmetrica (hash di a [xor](https://en.wikipedia.org/wiki/Exclusive_or) b). Questo significa che quando controlliamo la prova di Merkle, non dobbiamo preoccuparci di mettere il valore dalla prova prima o dopo il valore calcolato. Il controllo della prova di Merkle avviene sulla catena, quindi meno è necessario fare lì, meglio è.
-Attenzione: La crittografia è più complessa di quanto sembri. La versione iniziale di questo articolo conteneva la funzione di hash `hash(a^b)`. Quella era una **cattiva** idea, poiché comportava che, conoscendo i valori legittimi di `a` e `b` avresti potuto usare `b' = a^b^a'` per provare qualsiasi valore `a'` desiderato. Con questa funzione dovresti calcolare `b'` così che `hash(a') ^ hash(b')` sia pari a un valore noto (il ramo successivo verso la radice), il che è molto più difficile.
+Attenzione:
+La crittografia è più complessa di quanto sembri.
+La versione iniziale di questo articolo aveva la funzione hash `hash(a^b)`.
+È stata una **pessima** idea perché significava che, se si fossero conosciuti i valori legittimi di `a` e `b`, si sarebbe potuto usare `b' = a^b^a'` per provare qualsiasi valore `a'` desiderato.
+Con questa funzione si dovrebbe calcolare `b'` in modo che `hash(a') ^ hash(b')` sia uguale a un valore noto (il ramo successivo verso la radice), il che è molto più difficile.
```javascript
-// The value to denote that a certain branch is empty, doesn't
-// have a value
+// Il valore denota che un certo ramo è vuoto, non
+// ha un valore
const empty = 0n
```
@@ -95,11 +100,11 @@ Quando il numero di valori non è una potenza intera di due, dobbiamo gestire i
```javascript
-// Calculate one level up the tree of a hash array by taking the hash of
-// each pair in sequence
+// Calcola un livello superiore dell'albero di un array di hash, prendendo l'hash di
+// ogni coppia in sequenza
const oneLevelUp = (inputArray) => {
var result = []
- var inp = [...inputArray] // To avoid over writing the input // Add an empty value if necessary (we need all the leaves to be // paired)
+ var inp = [...inputArray] // Per evitare di sovrascrivere l'input // Aggiunge un valore vuoto se necessario (abbiamo bisogno che tutte le foglie siano // accoppiate)
if (inp.length % 2 === 1) inp.push(empty)
@@ -110,13 +115,13 @@ const oneLevelUp = (inputArray) => {
} // oneLevelUp
```
-Questa funzione "scala" un livello nell'albero di Merkle eseguendo l'hashing di coppie di valori al livello corrente. Nota che questa non è l'implementazione più efficiente: avremmo potuto evitare di copiare l'input e aggiungere semplicemente `hashEmpty` nel punto appropriato del ciclo, ma questo codice è ottimizzato per migliorare la leggibilità.
+Questa funzione "scala" un livello nell'albero di Merkle eseguendo l'hashing di coppie di valori al livello corrente. Si noti che questa non è l'implementazione più efficiente; avremmo potuto evitare di copiare l'input e aggiungere `hashEmpty` quando appropriato nel ciclo, ma questo codice è ottimizzato per la leggibilità.
```javascript
const getMerkleRoot = (inputArray) => {
var result
- result = [...inputArray] // Climb up the tree until there is only one value, that is the // root. // // If a layer has an odd number of entries the // code in oneLevelUp adds an empty value, so if we have, for example, // 10 leaves we'll have 5 branches in the second layer, 3 // branches in the third, 2 in the fourth and the root is the fifth
+ result = [...inputArray] // Si risale l'albero finché non rimane un solo valore, che è la // radice. // // Se un livello ha un numero dispari di voci, il // codice in oneLevelUp aggiunge un valore vuoto, quindi se abbiamo, ad esempio, // 10 foglie, avremo 5 rami nel secondo livello, 3 // rami nel terzo, 2 nel quarto e la radice è il quinto
while (result.length > 1) result = oneLevelUp(result)
@@ -126,27 +131,27 @@ const getMerkleRoot = (inputArray) => {
Per ottenere la radice, scala finché non resta un solo valore.
-#### Creare una prova di Merkle {#creating-a-merkle-proof}
+#### Creazione di una prova di Merkle {#creating-a-merkle-proof}
Una prova di Merkle è data dai valori da sottoporre all'hashing insieme al valore dimostrato in modo da ottenere nuovamente il root di Merkle. Il valore da provare spesso è ricavabile da altri dati, quindi preferisco fornirlo separatamente anziché come parte del codice.
```javascript
-// A merkle proof consists of the value of the list of entries to
-// hash with. Because we use a symmetrical hash function, we don't
-// need the item's location to verify the proof, only to create it
+// Una prova di Merkle consiste nel valore dell'elenco di voci con cui
+// eseguire l'hashing. Poiché usiamo una funzione hash simmetrica, non
+// abbiamo bisogno della posizione dell'elemento per verificare la prova, ma solo per crearla
const getMerkleProof = (inputArray, n) => {
var result = [], currentLayer = [...inputArray], currentN = n
- // Until we reach the top
+ // Finché non raggiungiamo la cima
while (currentLayer.length > 1) {
- // No odd length layers
+ // Nessun livello di lunghezza dispari
if (currentLayer.length % 2)
currentLayer.push(empty)
result.push(currentN % 2
- // If currentN is odd, add with the value before it to the proof
+ // Se currentN è dispari, aggiungi alla prova il valore che lo precede
? currentLayer[currentN-1]
- // If it is even, add the value after it
+ // Se è pari, aggiungi il valore che lo segue
: currentLayer[currentN+1])
```
@@ -154,7 +159,7 @@ const getMerkleProof = (inputArray, n) => {
Eseguiamo l'hashing di `(v[0],v[1])`, `(v[2],v[3])`, ecc. Quindi per i valori pari ci serve quello successivo, mentre per i valori dispari ci serve quello precedente.
```javascript
- // Move to the next layer up
+ // Passa al livello superiore
currentN = Math.floor(currentN/2)
currentLayer = oneLevelUp(currentLayer)
} // while currentLayer.length > 1
@@ -163,9 +168,9 @@ 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 sulla catena {#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.
+Finalmente abbiamo il codice che verifica la prova. Il codice sulla catena è scritto in [Solidity](https://docs.soliditylang.org/en/v0.8.11/). L'ottimizzazione è molto più importante qui, perché il gas è relativamente costoso.
```solidity
//SPDX-License-Identifier: Public Domain
@@ -174,7 +179,7 @@ pragma solidity ^0.8.0;
import "hardhat/console.sol";
```
-L'ho scritto usando l'[ambiente di sviluppo Hardhat](https://hardhat.org/), che ci consente di avere l'[output della console da Solidity](https://hardhat.org/docs/cookbook/debug-logs) durante lo sviluppo.
+L'ho scritto usando l'ambiente di sviluppo [Hardhat](https://hardhat.org/), che ci consente di avere [l'output della console da Solidity](https://hardhat.org/docs/cookbook/debug-logs) durante lo sviluppo.
```solidity
@@ -185,15 +190,15 @@ contract MerkleProof {
return merkleRoot;
}
- // Extremely insecure, in production code access to
- // this function MUST BE strictly limited, probably to an
- // owner
+ // Estremamente insicuro, nel codice di produzione l'accesso a
+ // questa funzione DEVE ESSERE rigorosamente limitato, probabilmente a un
+ // proprietario
function setRoot(uint _merkleRoot) external {
merkleRoot = _merkleRoot;
} // setRoot
```
-Imposta e ottieni le funzioni per il root di Merkle. Consentire a chiunque di aggiornare il root di Merkle è un'_idea assolutamente pessima_ in un sistema di produzione. Qui lo faccio per motivi di semplicità del codice di esempio. **Sconsiglio di farlo su un sistema in cui l'integrità dei dati è importante**.
+Imposta e ottieni le funzioni per il root di Merkle. Consentire a tutti di aggiornare la radice di Merkle è un'_idea estremamente pessima_ in un sistema di produzione. Qui lo faccio per motivi di semplicità del codice di esempio. **Non va fatto su un sistema in cui l'integrità dei dati è davvero importante**.
```solidity
function hash(uint _a) internal pure returns(uint) {
@@ -205,12 +210,12 @@ Imposta e ottieni le funzioni per il root di Merkle. Consentire a chiunque di ag
}
```
-Questa funzione genera l'hash di una coppia. È semplicemente la traduzione di Solidity del codice in JavaScript per `hash` e `pairHash`.
+Questa funzione genera l'hash di una coppia. È solo la traduzione in Solidity del codice JavaScript per `hash` e `pairHash`.
-**Nota:** Questo è un altro caso d'ottimizzazione per migliorare la leggibilità. In base alla [definizione della funzione](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm), potrebbe essere possibile memorizzare i dati come valore [`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays) ed evitare le conversioni.
+**Nota:** questo è un altro caso di ottimizzazione per la leggibilità. In base alla [definizione della funzione](https://www.tutorialspoint.com/solidity/solidity_cryptographic_functions.htm), potrebbe essere possibile memorizzare i dati come un valore [`bytes32`](https://docs.soliditylang.org/en/v0.5.3/types.html#fixed-size-byte-arrays) ed evitare le conversioni.
```solidity
- // Verify a Merkle proof
+ // Verifica una prova di Merkle
function verifyProof(uint _value, uint[] calldata _proof)
public view returns (bool) {
uint temp = _value;
@@ -226,16 +231,18 @@ Questa funzione genera l'hash di una coppia. È semplicemente la traduzione di S
} // MarkleProof
```
-Nella notazione matematica, la verifica della prova di Merkle somiglia a questa: `H(proof_n, H(proof_n-1, H(proof_n-2, ... H(proof_1, H(proof_0, value))...)))`. Questo codice la implementa.
+Nella notazione matematica, la verifica della prova di Merkle si presenta così: `H(proof_n, H(proof_n-1, H(proof_n-2, ...` `H(proof_1, H(proof_0, value))...)))`. Questo codice la implementa.
-## Prove di Merkle e rollup non si mescolano {#merkle-proofs-and-rollups}
+## Le prove di Merkle e i rollup non sono compatibili {#merkle-proofs-and-rollups}
Le prove di Merkle non funzionano bene con i [rollup](/developers/docs/scaling/#rollups). Il motivo è che i rollup scrivono tutti i dati della transazione su L1, ma elaborano su L2. Il costo medio per inviare una prova di Merkle con una transazione è di 638 gas per livello (correntemente, un byte nei dati della chiamata costa 16 gas se non è zero, e 4 se è zero). Se abbiamo 1024 parole di dati, una prova di Merkle richiede dieci livelli, o un totale di 6380 gas.
-Ad esempio, guardando a [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m), la scrittura del gas del L1 costa circa 100 gwei e del L2 circa 0,001 gwei (questo è il prezzo normale, può aumentare con la congestione). Quindi, per il costo di un gas del L1, possiamo consumare centomila gas sull'elaborazione del L2. Supponendo di non sovrascrivere l'archiviazione, ciò significa che possiamo scrivere circa cinque parole all'archiviazione sul L2, per il prezzo di un gas del L1. Per una singola prova di Merkle, possiamo scrivere tutte le 1024 parole all'archiviazione (supponendo innanzitutto che siano calcolabili sulla catena, piuttosto che fornite in una transazione) e comunque avere una rimanenza di gran parte del gas.
+Prendendo ad esempio [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m), il gas per scrivere su L1 costa circa 100 gwei, mentre il gas per L2 costa 0,001 gwei (questo è il prezzo normale, che può aumentare con la congestione). Quindi, per il costo di un gas del L1, possiamo consumare centomila gas sull'elaborazione del L2. Supponendo di non sovrascrivere l'archiviazione, ciò significa che possiamo scrivere circa cinque parole all'archiviazione sul L2, per il prezzo di un gas del L1. Per una singola prova di Merkle, possiamo scrivere tutte le 1024 parole in archivio (supponendo che possano essere calcolate sulla catena, invece di essere fornite in una transazione) e avere comunque la maggior parte del gas rimanente.
## Conclusione {#conclusion}
Nella vita reale potresti non trovarti mai a implementare alberi di Merkle per conto tuo. Esistono librerie ben note e controllate che puoi usare e, in generale, è meglio non implementare primitivi crittografici autonomamente. Ma spero che ora tu abbia compreso meglio le prove di Merkle e possa decidere quando vale la pena usarle.
-Nota che benché le prove di Merkle preservino l'_integrità_, non preservano la _disponibilità_. Sapere che nessun altro può prendere le tue risorse è una magra consolazione se la memoria dati decide di non consentire l'accesso e non puoi neanche costruire un albero di Merkle per accedervi. Quindi gli alberi di Merkle funzionano meglio con qualche tipo di memoria decentralizzata, come IPFS.
+Si noti che, sebbene le prove di Merkle preservino l'_integrità_, non preservano la _disponibilità_. Sapere che nessun altro può prendere le tue risorse è una magra consolazione se la memoria dati decide di non consentire l'accesso e non puoi neanche costruire un albero di Merkle per accedervi. Quindi gli alberi di Merkle funzionano meglio con qualche tipo di memoria decentralizzata, come IPFS.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
diff --git a/public/content/translations/it/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md b/public/content/translations/it/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
index f88aaf9ee3a..95228e2bf5f 100644
--- a/public/content/translations/it/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
+++ b/public/content/translations/it/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/index.md
@@ -1,26 +1,24 @@
---
title: Monitorare Geth con InfluxDB e Grafana
-description:
+description: Configura il monitoraggio per il tuo nodo Geth usando InfluxDB e Grafana per tracciare le prestazioni e identificare i problemi.
author: "Mario Havel"
-tags:
- - "client"
- - "nodi"
+tags: [ "client", "nodi" ]
skill: intermediate
lang: it
published: 2021-01-13
---
-Questo tutorial ti aiuterà a configurare il monitoraggio per il tuo nodo di Geth così che tu possa meglio comprenderne le prestazioni e identificare i problemi potenziali.
+Questo tutorial ti aiuterà a configurare il monitoraggio per il tuo nodo Geth, in modo da poterne comprendere meglio le prestazioni e identificare potenziali problemi.
## Prerequisiti {#prerequisites}
-- Dovresti avere già in esecuzione un'istanza di Geth.
-- Gran parte dei passaggi ed esempi sono per l'ambiente Linux, è utile quindi una conoscenza di base della console.
-- Dai un'occhiata a questa panoramica video della suite di metriche di Geth: [Monitoring an Ethereum infrastructure by Péter Szilágyi](https://www.youtube.com/watch?v=cOBab8IJMYI).
+- Dovresti già avere in esecuzione un'istanza di Geth.
+- La maggior parte dei passaggi e degli esempi sono per l'ambiente Linux; sarà utile una conoscenza di base del terminale.
+- Dai un'occhiata a questa panoramica video della suite di metriche di Geth: [Monitoring an Ethereum infrastructure di Péter Szilágyi](https://www.youtube.com/watch?v=cOBab8IJMYI).
## Stack di monitoraggio {#monitoring-stack}
-Un client di Ethereum raccoglie molti dati leggibili sotto forma di database cronologico. Per semplificare il monitoraggio, puoi alimentare i dati nel software di visualizzazione. Esistono numerose opzioni disponibili:
+Un client di Ethereum raccoglie molti dati leggibili sotto forma di database cronologico. Per semplificare il monitoraggio, puoi alimentare questi dati in un software di visualizzazione dati. Sono disponibili diverse opzioni:
- [Prometheus](https://prometheus.io/) (modello pull)
- [InfluxDB](https://www.influxdata.com/get-influxdb/) (modello push)
@@ -31,11 +29,12 @@ Un client di Ethereum raccoglie molti dati leggibili sotto forma di database cro
Esiste anche [Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter), un'opzione preconfigurata con InfluxDB e Grafana.
-In questo tutorial, configureremo il tuo client di Geth per inviare i dati a InfluxDB per creare un database e Grafana per creare una visualizzazione grafica dei dati. Farlo manualmente ti aiuterà a comprendere meglio il processo e a distribuirlo in ambienti diversi.
+In questo tutorial, configureremo il tuo client Geth per inviare dati a InfluxDB per creare un database e a Grafana per creare una visualizzazione grafica dei dati. Farlo manualmente ti aiuterà a comprendere meglio il processo, a modificarlo e a distribuirlo in ambienti diversi.
-## Configurare InfluxDB {#setting-up-influxdb}
+## Configurazione di InfluxDB {#setting-up-influxdb}
-Prima, scarichiamo e installiamo InfluxDB. Varie opzioni di download si possono trovare alla [pagina di release di Influxdata](https://portal.influxdata.com/downloads/). Seleziona quella che si adatta al tuo ambiente. Puoi anche installarla da una [repository](https://repos.influxdata.com/). Per esempio, nella distribuzione basata su Debian:
+Per prima cosa, scarichiamo e installiamo InfluxDB. Varie opzioni di download sono disponibili nella [pagina di release di Influxdata](https://portal.influxdata.com/downloads/). Scegli quella che si adatta al tuo ambiente.
+Puoi anche installarlo da un [repository](https://repos.influxdata.com/). Ad esempio, in una distribuzione basata su Debian:
```
curl -tlsv1.3 --proto =https -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add
@@ -48,13 +47,14 @@ sudo systemctl start influxdb
sudo apt install influxdb-client
```
-Dopo aver installato correttamente InfluxDB, accertati che sia in esecuzione in background. Di default, è raggiungibile a `localhost:8086`. Prima di usare il client `influx`, devi creare un nuovo utente con privilegi d'amministratore. Questo utente servirà per l'amministrazione d'alto livello, la creazione di database e utenti.
+Dopo aver installato correttamente InfluxDB, assicurati che sia in esecuzione in background. Per impostazione predefinita, è raggiungibile all'indirizzo `localhost:8086`.
+Prima di usare il client `influx`, devi creare un nuovo utente con privilegi di amministratore. Questo utente servirà per la gestione di alto livello, la creazione di database e utenti.
```
curl -XPOST "http://localhost:8086/query" --data-urlencode "q=CREATE USER username WITH PASSWORD 'password' WITH ALL PRIVILEGES"
```
-Ora puoi usare il client di influx per accedere alla [shell di InfluxDB](https://docs.influxdata.com/influxdb/v1.8/tools/shell/) con questo utente.
+Ora puoi usare il client influx per entrare nella [shell di InfluxDB](https://docs.influxdata.com/influxdb/v1.8/tools/shell/) con questo utente.
```
influx -username 'username' -password 'password'
@@ -80,28 +80,30 @@ Esci dalla shell di InfluxDB.
exit
```
-InfluxDB è in esecuzione e configurato per memorizzare le metriche da Geth.
+InfluxDB è in esecuzione e configurato per archiviare le metriche da Geth.
-## Preparare Geth {#preparing-geth}
+## Preparazione di Geth {#preparing-geth}
-Dopo aver configurato il database, dobbiamo abilitare la raccolta di metriche su Geth. Presta attenzione a `METRICS AND STATS OPTIONS` in `geth --help`. Lì si possono trovare diverse opzioni, in questo caso vogliamo che Geth alimenti i dati in InfluxDB. La configurazione di base specifica l'endpoint dove InfluxDB è raggiungibile e l'autenticazione per il database.
+Dopo aver configurato il database, dobbiamo abilitare la raccolta delle metriche in Geth. Presta attenzione a `METRICS AND STATS OPTIONS` in `geth --help`. Lì si possono trovare diverse opzioni, in questo caso vogliamo che Geth invii i dati a InfluxDB.
+La configurazione di base specifica l'endpoint in cui InfluxDB è raggiungibile e l'autenticazione per il database.
```
geth --metrics --metrics.influxdb --metrics.influxdb.endpoint "http://0.0.0.0:8086" --metrics.influxdb.username "geth" --metrics.influxdb.password "chosenpassword"
```
-Questi flag possono essere accodati a un comando che avvia il client o salvati nel file di configurazione.
+Questi flag possono essere aggiunti a un comando che avvia il client o salvati nel file di configurazione.
-Puoi verificare che Geth stia inviando correttamente i dati, per esempio, elencando le metriche nel database. Nella shell di InfluxDB:
+Puoi verificare che Geth stia inviando correttamente i dati, ad esempio elencando le metriche nel database. Nella shell di InfluxDB:
```
use geth
show measurements
```
-## Configurare Grafana {#setting-up-grafana}
+## Configurazione di Grafana {#setting-up-grafana}
-Il prossimo passo è installare Grafana, che interpreterà graficamente i dati. Segui il processo di installazione per il tuo ambiente nella documentazione di Grafana. Assicurati di installare la versione OSS, se non desideri un'altra versione. Esempio di fasi d'installazione per le distribuzioni di Debian usando il repository:
+Il passaggio successivo è l'installazione di Grafana, che interpreterà i dati graficamente. Segui la procedura di installazione per il tuo ambiente nella documentazione di Grafana. Assicurati di installare la versione OSS, se non diversamente desiderato.
+Esempio di passaggi di installazione per le distribuzioni Debian che utilizzano il repository:
```
curl -tlsv1.3 --proto =https -sL https://packages.grafana.com/gpg.key | sudo apt-key add -
@@ -112,15 +114,16 @@ sudo systemctl enable grafana-server
sudo systemctl start grafana-server
```
-Quando Grafana è in esecuzione, dovrebbe esser raggiungibile a `localhost:3000`. Usa il tuo browser preferito per accedere a questo percorso, poi accedi con le credenziali predefinite (utente: `admin` e password: `admin`). Quando richiesto, modifica la password predefinita e salva.
+Quando Grafana è in esecuzione, dovrebbe essere raggiungibile all'indirizzo `localhost:3000`.
+Usa il tuo browser preferito per accedere a questo percorso, quindi accedi con le credenziali predefinite (utente: `admin` e password: `admin`). Quando richiesto, modifica la password predefinita e salva.
-Sarai reindirizzato alla pagina home di Grafana. Per prima cosa, configura i tuoi dati sorgente. Clicca sull'icona di configurazione nella barra a sinistra e seleziona "Sorgenti dati".
+Sarai reindirizzato alla home page di Grafana. Per prima cosa, imposta i dati di origine. Fai clic sull'icona della configurazione nella barra di sinistra e seleziona "Sorgenti dati".
-Se non sono ancora state create sorgenti di dati, clicca su "Aggiungi sorgente di dati" per definirne una.
+Non ci sono ancora origini dati create, fai clic su "Aggiungi origine dati" per definirne una.
@@ -128,20 +131,21 @@ Per questa configurazione, seleziona "InfluxDB" e procedi.
-La configurazione della sorgente di dati è abbastanza semplice se esegui gli strumenti sulla stessa macchina. Devi impostare l'indirizzo di InfluxDB e i dettagli per accedere al database. Fai riferimento alla seguente immagine.
+La configurazione dell'origine dati è piuttosto semplice se si eseguono gli strumenti sulla stessa macchina. È necessario impostare l'indirizzo di InfluxDB e i dettagli per accedere al database. Fai riferimento all'immagine sottostante.
-Se tutto è completo e InfluxDB è raggiungibile, clicca su "Salva e prova" e attendi che compaia la conferma.
+Se tutto è completo e InfluxDB è raggiungibile, fai clic su "Salva e testa" e attendi la comparsa della conferma.
-Grafana è ora configurato per leggere i dati da InfluxDB. Ora devi creare una dashboard che li interpreterà e mostrerà. Le proprietà dei pannelli di controllo sono codificate nei file JSON, che possono essere creati da chiunque e sono facilmente importabili. Sulla barra sinistra, clicca su "Crea e Importa".
+Grafana è ora impostato per leggere i dati da InfluxDB. Ora è necessario creare una dashboard che la interpreterà e la visualizzerà. Le proprietà delle dashboard sono codificate in file JSON che possono essere creati da chiunque e importati facilmente. Sulla barra di sinistra, fai clic su "Crea e importa".
-Per una dashboard di monitoraggio di Geth, copia l'ID di [questa dashboard](https://grafana.com/grafana/dashboards/13877/) e incollalo nella "Pagina d'importazione" su Grafana. Dopo aver salvato la dashboard, dovrebbe somigliare a questo:
+Per una dashboard di monitoraggio Geth, copia l'ID di [questa dashboard](https://grafana.com/grafana/dashboards/13877/) e incollalo nella pagina "Importa" di Grafana. Dopo aver salvato la dashboard, dovrebbe apparire così:
-Puoi modificare i tuoi pannelli di controllo. Ogni pannello può essere modificato, spostato, rimosso o aggiunto. Puoi modificare le tue configurazioni. Sta a te! Per saperne di più su come funzionano i pannelli di controllo, fai riferimento alla [documentazione di Grafana](https://grafana.com/docs/grafana/latest/dashboards/). Potresti esser anche interessato agli [avvisi](https://grafana.com/docs/grafana/latest/alerting/), che ti consentono di configurare delle notifiche di avviso per quando le metriche raggiungono certi valori. Sono supportati diversi canali di comunicazione.
+Puoi modificare le tue dashboard. Ogni pannello può essere modificato, spostato, rimosso o aggiunto. Puoi modificare le tue configurazioni. Dipende da te! Per saperne di più su come funzionano i pannelli di controllo, consulta la [documentazione di Grafana](https://grafana.com/docs/grafana/latest/dashboards/).
+Potresti anche essere interessato a [Alerting](https://grafana.com/docs/grafana/latest/alerting/). Ciò consente di impostare notifiche di avviso per quando le metriche raggiungono determinati valori. Sono supportati vari canali di comunicazione.
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..33d9046c047 100644
--- a/public/content/translations/it/developers/tutorials/nft-minter/index.md
+++ b/public/content/translations/it/developers/tutorials/nft-minter/index.md
@@ -3,12 +3,14 @@ title: Tutorial del Coniatore di NFT
description: In questo tutorial, creerai un coniatore di NFT e imparerai come creare una dapp in full stack connettendo il tuo smart contract a un frontend di React usando gli strumenti di MetaMask e Web3.
author: "smudgil"
tags:
- - "solidity"
- - "NFT"
- - "alchemy"
- - "contratti intelligenti"
- - "frontend"
- - "Pinata"
+ [
+ "Solidity",
+ "NFT",
+ "alchemy",
+ "smart contract",
+ "frontend",
+ "Pinata"
+ ]
skill: intermediate
lang: it
published: 2021-10-06
@@ -22,63 +24,63 @@ Creando un coniatore di NFT, una semplice UI in cui è possibile inserire un lin
- Chiamare i metodi dello smart contract dal tuo frontend
- Firmare le transazioni usando MetaMask
-In questo tutorial, utilizzeremo [React](https://reactjs.org/) come framework di frontend. Poiché questo tutorial è incentrato principalmente sullo sviluppo di Web3, non dedicheremo molto tempo ad analizzare i fondamenti di React. Al contrario, ci concentreremo sul portare funzionalità al nostro progetto.
+In questo tutorial, useremo [React](https://react.dev/) come framework frontend. Poiché questo tutorial è incentrato principalmente sullo sviluppo di Web3, non dedicheremo molto tempo ad analizzare i fondamenti di React. Al contrario, ci concentreremo sul portare funzionalità al nostro progetto.
-Come prerequisito, dovresti avere conoscenze di base di React e sapere come funzionano i componenti, gli accessori, useState/useEffect e la chiamata delle funzioni di base. Se non hai mai sentito parlare di alcuno di questi termini prima d'ora, è consigliabile dare un'occhiata a questo [tutorial d'introduzione a React](https://reactjs.org/tutorial/tutorial.html). Per chi preferisce l'apprendimento visivo, consigliamo vivamente quest'eccellente serie di video [Tutorial moderno e completo su React](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d) di Net Ninja.
+Come prerequisito, dovresti avere conoscenze di base di React e sapere come funzionano i componenti, gli accessori, useState/useEffect e la chiamata delle funzioni di base. Se non hai mai sentito parlare di nessuno di questi termini prima d'ora, potresti voler consultare questo [tutorial di introduzione a React](https://react.dev/learn/tutorial-tic-tac-toe). Per chi preferisce l'apprendimento visivo, consigliamo vivamente questa eccellente serie di video [Tutorial moderno e completo su React](https://www.youtube.com/playlist?list=PL4cUxeGkcC9gZD-Tvwfod2gaISzfRiP9d) di Net Ninja.
-E se non lo hai già fatto, necessiterai decisamente di un conto di Alchemy, per completare questo tutorial, nonché per creare qualsiasi cosa sulla blockchain. Registra gratuitamente un conto,[qui](https://alchemy.com/).
+E se non lo hai già fatto, necessiterai decisamente di un conto di Alchemy, per completare questo tutorial, nonché per creare qualsiasi cosa sulla blockchain. Registrati per un account gratuito [qui](https://alchemy.com/).
Iniziamo quindi!
-## Guida alla Creazione di NFT {#making-nfts-101}
+## Creare NFT 101 {#making-nfts-101}
Prima ancora d'iniziare ad esaminare qualsiasi codice, è importante comprendere come funziona la creazione di un NFT. Si articola in due fasi:
-### Pubblicare lo smart contract di un NFT sulla blockchain di Ethereum {#publish-nft}
+### Pubblicare uno smart contract NFT sulla blockchain di Ethereum {#publish-nft}
La più grande differenza tra i due standard di smart contract di NFT è che ERC-1155 è uno standard multi-token e comprende funzionalità batch, mentre ERC-721 è uno standard a token singolo, supporta dunque solo il trasferimento di un token per volta.
-### Chiamare la funzione di conio {#minting-function}
+### Chiamare la funzione di minting {#minting-function}
-Solitamente, questa funzione di conio richiede di passare due variabili come parametri, prima `recipient`, che specifica l'indirizzo che riceverà il tuo NFT appena coniato e poi il `tokenURI` del NFT, una stringa che si risolve a un documento JSON che descrive i metadati del NFT.
+Solitamente, questa funzione di minting richiede di passare due variabili come parametri: prima il `recipient`, che specifica l'indirizzo che riceverà il tuo NFT appena coniato, e poi il `tokenURI` dell'NFT, una stringa che si risolve in un documento JSON che descrive i metadati dell'NFT.
-I metadati di un NFT sono davvero ciò che lo porta in vita, consentendogli di avere proprietà, quali nome, descrizione, immagine (o altre risorse digitali) e altri attributi. Ecco [un esempio di un tokenURI](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2), contenente i metadati di un NFT.
+I metadati di un NFT sono davvero ciò che lo porta in vita, consentendogli di avere proprietà, quali nome, descrizione, immagine (o altre risorse digitali) e altri attributi. Ecco [un esempio di tokenURI](https://gateway.pinata.cloud/ipfs/QmSvBcb4tjdFpajGJhbFAWeK3JAxCdNQLQtr6ZdiSi42V2), che contiene i metadati di un NFT.
In questo tutorial, ci concentreremo sulla parte 2: chiamare una funzione di conio dello smart contract del NFT esistente usando la nostra UI di React.
-[Ecco un link](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE) allo smart contract del NFT dell'ERC-721 che chiameremo in questo tutorial. Se sei interessato a imparare come lo abbiamo creato, consigliamo vivamente di dare un'occhiata al nostro tutorial, ["Come creare un NFT"](https://docs.alchemyapi.io/alchemy/tutorials/how-to-create-an-nft).
+[Ecco un link](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE) allo smart contract ERC-721 NFT che chiameremo in questo tutorial. Se desideri imparare come lo abbiamo creato, ti consigliamo vivamente di consultare il nostro altro tutorial, ["Come creare un NFT"](https://www.alchemy.com/docs/how-to-create-an-nft).
Forte! Ora che sappiamo come funziona la creazione di un NFT, cloniamo i nostri file iniziali!
-## Clonare i file iniziali {#clone-the-starter-files}
+## Clonare i file di base {#clone-the-starter-files}
-Prima, vai al [repository di GitHub nft-minter-tutorial](https://github.com/alchemyplatform/nft-minter-tutorial) per ottenere i file iniziali per questo progetto. Clona questo repository nel tuo ambiente locale.
+Innanzitutto, vai al [repository GitHub nft-minter-tutorial](https://github.com/alchemyplatform/nft-minter-tutorial) per ottenere i file di base per questo progetto. Clona questo repository nel tuo ambiente locale.
Quando apri questo repository `nft-minter-tutorial` clonato, noterai che contiene due cartelle: `minter-starter-files` e `nft-minter`.
-- `minter-starter-files` contiene i file iniziali (essenzialmente l'UI di React) per questo progetto. In questo tutorial, **lavoreremo in questa cartella**, mentre impari a dar vita a questa UI connettendola al tuo portafoglio di Ethereum e a uno smart contract di NFT.
-- `nft-minter` contiene l'intero tutorial completato e serve come **riferimento** **se dovessi bloccarti.**
+- `minter-starter-files` contiene i file di base (essenzialmente la UI di React) per questo progetto. In questo tutorial, **lavoreremo in questa directory**, mentre impari come dar vita a questa UI collegandola al tuo portafoglio Ethereum e a uno smart contract NFT.
+- `nft-minter` contiene l'intero tutorial completato ed è a tua disposizione come **riferimento** **se dovessi bloccarti.**
-Apri quindi la tua copia di `minter-starter-files` nel tuo editor di codice e poi vai alla cartella `src`.
+Successivamente, apri la tua copia di `minter-starter-files` nel tuo editor di codice, quindi naviga nella cartella `src`.
-Tutto il codice che scriveremo sarà sotto la cartella `src`. Modificheremo il componente `Minter.js` e scriveremo altri file in JavaScript per dare funzionalità al nostro progetto Web3.
+Tutto il codice che scriveremo si troverà nella cartella `src`. Modificheremo il componente `Minter.js` e scriveremo altri file javascript per dare al nostro progetto la funzionalità Web3.
-## Fase 2: dai un'occhiata ai nostri file iniziali {#step-2-check-out-our-starter-files}
+## Fase 2: Controllare i nostri file di base {#step-2-check-out-our-starter-files}
Prima di iniziare a programmare, è importante dare un'occhiata a ciò che è già disponibile nei file iniziali.
-### Metti in funzione il tuo progetto di React {#get-your-react-project-running}
+### Avviare il progetto React {#get-your-react-project-running}
Iniziamo eseguendo il progetto di React nel browser. La bellezza di React è che una volta eseguito il nostro progetto nel browser, ogni modifica che salviamo sarà aggiornata dal vivo nel browser.
-Per mettere il progetto in funzione, vai alla cartella di root della cartella `minter-starter-files` ed esegui `npm install` nel terminale per installare le dipendenze del progetto:
+Per avviare il progetto, naviga alla directory principale della cartella `minter-starter-files` ed esegui `npm install` nel tuo terminale per installare le dipendenze del progetto:
```bash
cd minter-starter-files
npm install
```
-Una volta terminata l'installazione, esegui `npm start` nel terminale:
+Una volta terminata l'installazione, esegui `npm start` nel tuo terminale:
```bash
npm start
@@ -90,14 +92,14 @@ Se provi a cliccare i pulsanti "Connetti Portafoglio" o "Conia NFT", noterai che
### Il componente Minter.js {#minter-js}
-**NOTA:** Assicurati di essere nella cartella `minter-starter-files` e non nella cartella `nft-minter`!
+**NOTA:** assicurati di essere nella cartella `minter-starter-files` e non nella cartella `nft-minter`!
-Torniamo alla cartella `src` nell'editor e apriamo il file `Minter.js`. È davvero importante comprendere tutto il contenuto di questo file, che è il componente principale di React su cui lavoreremo.
+Torniamo alla cartella `src` nel nostro editor e apriamo il file `Minter.js`. È davvero importante comprendere tutto il contenuto di questo file, che è il componente principale di React su cui lavoreremo.
In cima al nostro file, abbiamo le nostre variabili di stato che aggiorneremo dopo eventi specifici.
```javascript
-//State variables
+//Variabili di stato
const [walletAddress, setWallet] = useState("")
const [status, setStatus] = useState("")
const [name, setName] = useState("")
@@ -105,135 +107,135 @@ const [description, setDescription] = useState("")
const [url, setURL] = useState("")
```
-Mai sentito parlare di variabili di stato di React o di hook di stato? Dai un'occhiata a [questa](https://reactjs.org/docs/hooks-state.html) documentazione.
+Mai sentito parlare di variabili di stato di React o di hook di stato? Consulta [questa](https://legacy.reactjs.org/docs/hooks-state.html) documentazione.
Ecco cosa rappresenta ognuna delle variabili:
-- `walletAddress` - una stringa che memorizza l'indirizzo del portafoglio dell'utente
-- `status` - una stringa contenente un messaggio da mostrare in fondo all'UI
-- `name` - una stringa che memorizza il nome del NFT
-- `description` - una stringa che memorizza la descrizione del NFT
-- `url` - una stringa che rappresenta un link alla risorsa digitale del NFT
+- `walletAddress`: una stringa che memorizza l'indirizzo del portafoglio dell'utente
+- `status`: una stringa che contiene un messaggio da visualizzare in fondo alla UI
+- `name`: una stringa che memorizza il nome dell'NFT
+- `description`: una stringa che memorizza la descrizione dell'NFT
+- `url`: una stringa che è un link all'asset digitale dell'NFT
-Dopo le variabili di stato, vedrai tre funzioni non implementate: `useEffect`, `connectWalletPressed` e `onMintPressed`. Noterai che tutte queste funzioni sono `async`, perché al loro interno effettueremo chiamate asincrone all'API! I nomi sono indicativi delle loro funzionalità:
+Dopo le variabili di stato, vedrai tre funzioni non implementate: `useEffect`, `connectWalletPressed` e `onMintPressed`. Noterai che tutte queste funzioni sono `async`, perché al loro interno effettueremo chiamate API asincrone! I nomi sono indicativi delle loro funzionalità:
```javascript
useEffect(async () => {
- //TODO: implement
+ //TODO: implementare
}, [])
const connectWalletPressed = async () => {
- //TODO: implement
+ //TODO: implementare
}
const onMintPressed = async () => {
- //TODO: implement
+ //TODO: implementare
}
```
-- [`useEffect`](https://reactjs.org/docs/hooks-effect.html) - questo è un hook di React chiamato dopo il rendering del tuo componente. Poiché in essa viene passato un array vuoto `[]` (vedi la riga 3), sarà chiamata solo al _primo_ rendering del componente. Qui chiameremo il listener del nostro portafoglio e un'altra funzione del portafoglio per aggiornare la nostra UI affinché rifletta se un portafoglio è già collegato.
-- `connectWalletPressed` - questa funzione sarà chiamata per connettere il portafoglio di MetaMask dell'utente alla nostra dapp.
-- `onMintPressed` - questa funzione sarà chiamata per coniare il NFT dell'utente.
+- [`useEffect`](https://legacy.reactjs.org/docs/hooks-effect.html): questo è un hook di React che viene chiamato dopo il rendering del tuo componente. Poiché ha un array vuoto `[]` come prop (vedi riga 3), verrà chiamato solo al _primo_ rendering del componente. Qui chiameremo il listener del nostro portafoglio e un'altra funzione del portafoglio per aggiornare la nostra UI affinché rifletta se un portafoglio è già collegato.
+- `connectWalletPressed`: questa funzione verrà chiamata per collegare il portafoglio MetaMask dell'utente alla nostra dApp.
+- `onMintPressed`: questa funzione verrà chiamata per eseguire il minting dell'NFT dell'utente.
-Vicino alla fine di questo file, abbiamo l'UI del nostro componente. Se esamini attentamente questo codice, noterai che aggiorniamo le nostre variabili di stato `url`, `name` e `description`, quando l'input nei relativi campi di testo cambia.
+Vicino alla fine di questo file, abbiamo l'UI del nostro componente. Se esamini attentamente questo codice, noterai che aggiorniamo le nostre variabili di stato `url`, `name` e `description` quando l'input nei campi di testo corrispondenti cambia.
-Vedrai anche che `connectWalletPressed` e `onMintPressed` vengono chiamate rispettivamente quando viene fatto clic sui pulsanti con ID `mintButton` e `walletButton`.
+Vedrai anche che `connectWalletPressed` e `onMintPressed` vengono chiamate quando si fa clic rispettivamente sui pulsanti con ID `mintButton` e `walletButton`.
```javascript
-//the UI of our component
+//l'interfaccia utente del nostro componente
return (
-
🧙♂️ Alchemy NFT Minter
+
🧙♂️ Minter di NFT di Alchemy
- Simply add your asset's link, name, and description, then press "Mint."
+ Aggiungi semplicemente il link, il nome e la descrizione del tuo asset, quindi premi "Esegui il minting".
{status}
-
+
)
```
Infine, vediamo dove viene aggiunto questo componente del Coniatore.
-Se vai al file `App.js`, che è il componente principale su React e che agisce come contenitore per tutti gli altri componenti, vedrai che il nostro componente del Coniatore è inserito alla riga 7.
+Se vai al file `App.js`, che è il componente principale in React che funge da contenitore per tutti gli altri componenti, vedrai che il nostro componente Minter viene inserito alla riga 7.
-**In questo tutorial, modificheremo solo il file `Minter.js` e aggiungeremo i file alla nostra cartella `src`.**
+**In questo tutorial, modificheremo solo il file `Minter.js` e aggiungeremo file nella nostra cartella `src`.**
Ora che ci è chiaro con cosa stiamo lavorando, configuriamo il portafoglio di Ethereum!
-## Configura il tuo wallet Ethereum {#set-up-your-ethereum-wallet}
+## Configura il tuo portafoglio Ethereum {#set-up-your-ethereum-wallet}
Per poter interagire con il tuo smart contract, gli utenti dovranno connettere il proprio portafoglio di Ethereum alla tua dapp.
### Scarica MetaMask {#download-metamask}
-Per questo tutorial, utilizzeremo MetaMask, un portafoglio virtuale nel browser, utilizzato per gestire l'indirizzo del tuo conto di Ethereum. Se vuoi capire di più su come funzionano le transazioni su Ethereum, dai un'occhiata a [questa pagina](/developers/docs/transactions/).
+Per questo tutorial, utilizzeremo MetaMask, un portafoglio virtuale nel browser, utilizzato per gestire l'indirizzo del tuo conto di Ethereum. Se vuoi saperne di più su come funzionano le transazioni su Ethereum, consulta [questa pagina](/developers/docs/transactions/).
-Puoi scaricare e creare gratuitamente un conto di MetaMask [qui](https://metamask.io/download). Quando stai creando un conto, o se ne hai già uno, assicurati di passare alla "Rete di Prova di Ropsten" in alto a destra \(così da non avere a che fare con denaro reale\).
+Puoi scaricare e creare un account MetaMask gratuitamente [qui](https://metamask.io/download). Quando stai creando un conto, o se ne hai già uno, assicurati di passare alla "Rete di Prova di Ropsten" in alto a destra \(così da non avere a che fare con denaro reale\).
### Aggiungere ether da un Faucet {#add-ether-from-faucet}
-Per coniare i nostri NFT (o firmare qualsiasi transazione sulla blockchain di Ethereum), avremo bisogno di qualche finto Eth. Per ottenere degli Eth puoi andare al [faucet di Ropsten](https://faucet.ropsten.be/) e inserire l'indirizzo del tuo conto di Ropsten, poi cliccare “Invia Eth a Ropsten.” Poco dopo, dovresti vedere gli Eth nel tuo conto di MetaMask!
+Per coniare i nostri NFT (o firmare qualsiasi transazione sulla blockchain di Ethereum), avremo bisogno di qualche finto Eth. Per ottenere Eth, puoi andare al [faucet Ropsten](https://faucet.ropsten.be/), inserire l'indirizzo del tuo account Ropsten e fare clic su “Invia Eth di Ropsten”. Poco dopo, dovresti vedere gli Eth nel tuo conto di MetaMask!
### Controlla il tuo saldo {#check-your-balance}
-Per ricontrollare che ci sia il saldo, facciamo una richiesta [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) usando lo [strumento compositore di Alchemy](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Questo restituirà l'importo di Eth nel tuo portafoglio. Dopo aver inserito l'indirizzo del tuo conto di MetaMask e aver cliccato "Invia Richiesta", dovresti visualizzare una risposta simile alla seguente:
+Per verificare che il nostro saldo sia presente, effettuiamo una richiesta [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) usando lo [strumento compositore di Alchemy](https://composer.alchemyapi.io/?composer_state=%7B%22network%22%3A0%2C%22methodName%22%3A%22eth_getBalance%22%2C%22paramValues%22%3A%5B%22%22%2C%22latest%22%5D%7D). Questo restituirà l'importo di Eth nel tuo portafoglio. Dopo aver inserito l'indirizzo del tuo conto di MetaMask e aver cliccato "Invia Richiesta", dovresti visualizzare una risposta simile alla seguente:
```text
{"jsonrpc": "2.0", "id": 0, "result": "0xde0b6b3a7640000"}
```
-**NOTA:** Questo risultato è in wei non in eth. Wei è usato come taglio più piccolo dell'ether. La conversione da wei a eth è: 1 eth = 10¹⁸ wei. Quindi se convertiamo 0xde0b6b3a7640000 in decimali, otteniamo 1\*10¹⁸, pari a 1 eth.
+**NOTA:** questo risultato è in wei, non in eth. Wei è usato come taglio più piccolo dell'ether. La conversione da wei a eth è: 1 eth = 10¹⁸ wei. Quindi se convertiamo 0xde0b6b3a7640000 in decimali, otteniamo 1\*10¹⁸, pari a 1 eth.
Meno male! I nostri soldi finti ci sono tutti!
-## Connettere MetaMask alla UI {#connect-metamask-to-your-UI}
+## Collega MetaMask alla tua UI {#connect-metamask-to-your-UI}
Ora che il nostro portafoglio di MetaMask è configurato, connettiamo la nostra dapp!
-Poiché vogliamo prescrivere al paradigma del [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller), creeremo un file separato che contiene le nostre funzioni per gestire la logica, i dati e le regole della nostra dapp e poi passeremo tali funzioni al nostro frontend (il nostro componente Minter.js).
+Poiché vogliamo attenerci al paradigma [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller), creeremo un file separato che contiene le nostre funzioni per gestire la logica, i dati e le regole della nostra dApp, per poi passare tali funzioni al nostro frontend (il nostro componente Minter.js).
### La funzione `connectWallet` {#connect-wallet-function}
-Per farlo, creiamo una nuova cartella chiamata `utils` nella nostra cartella `src` e aggiungiamo al suo interno un file chiamato `interact.js`, che conterrà tutte le funzioni d'interazione del nostro portafoglio e del nostro smart contract.
+Per farlo, creiamo una nuova cartella chiamata `utils` nella directory `src` e aggiungiamo al suo interno un file chiamato `interact.js`, che conterrà tutte le nostre funzioni di interazione con il portafoglio e lo smart contract.
Nel nostro file `interact.js`, scriveremo una funzione `connectWallet`, che poi importeremo e chiameremo nel nostro componente `Minter.js`.
-Nel tuo file `interact.js`, aggiungi quanto segue
+Nel tuo file `interact.js`, aggiungi quanto segue:
```javascript
export const connectWallet = async () => {
@@ -243,7 +245,7 @@ export const connectWallet = async () => {
method: "eth_requestAccounts",
})
const obj = {
- status: "👆🏽 Write a message in the text-field above.",
+ status: "👆🏽 Scrivi un messaggio nel campo di testo qui sopra.",
address: addressArray[0],
}
return obj
@@ -261,7 +263,7 @@ export const connectWallet = async () => {
@@ -274,24 +276,24 @@ export const connectWallet = async () => {
Analizziamo cosa fa questo codice:
-Per prima cosa, la nostra funzione verifica se `window.ethereum` è abilitato nel browser.
+Innanzitutto, la nostra funzione controlla se `window.ethereum` è abilitato nel tuo browser.
-`window.ethereum` è un'API globale, iniettata da MetaMask e altri fornitori di portafogli, che consente ai siti web di richiedere i conti di Ethereum degli utenti. Se approvata, può leggere i dati dalle blockchain a cui è connesso l'utente e suggerire all'utente di firmare messaggi e transazioni. Dai un'occhiata alla [documentazione di MetaMask](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents) per ulteriori informazioni!
+`window.ethereum` è un'API globale iniettata da MetaMask e da altri provider di portafogli che consente ai siti web di richiedere gli account Ethereum degli utenti. Se approvata, può leggere i dati dalle blockchain a cui è connesso l'utente e suggerire all'utente di firmare messaggi e transazioni. Consulta la [documentazione di MetaMask](https://docs.metamask.io/guide/ethereum-provider.html#table-of-contents) per maggiori informazioni!
-Se `window.ethereum` _non è_ presente, significa che MetaMask non è installato. Verrà quindi restituito un oggetto JSON in cui l'`address` restituito è una stringa vuota e l'oggetto JSX di `status` indica che l'utente deve installare MetaMask.
+Se `window.ethereum` _non è_ presente, significa che MetaMask non è installato. Questo restituisce un oggetto JSON, in cui l'`address` restituito è una stringa vuota e l'oggetto JSX `status` comunica che l'utente deve installare MetaMask.
-**Gran parte delle funzioni che scriveremo restituiranno oggetti JSON che possiamo usare per aggiornare le nostre variabili di stato e l'UI.**
+**La maggior parte delle funzioni che scriviamo restituirà oggetti JSON che potremo usare per aggiornare le nostre variabili di stato e la nostra UI.**
-Ora, se `window.ethereum` _è_ presente, le cose cominciano a farsi interessanti.
+Ora, se `window.ethereum` _è_ presente, è qui che le cose si fanno interessanti.
-Utilizzando un ciclo try/catch, proveremo a connetterci a MetaMask chiamando `[window.ethereum.request({ method: "eth_requestAccounts" });](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts)`. Chiamare questa funzione aprirà MetaMask nel browser, dove sarà richiesto all'utente di connettere il proprio portafoglio alla tua dapp.
+Usando un ciclo try/catch, proveremo a connetterci a MetaMask chiamando [`window.ethereum.request({ method: "eth_requestAccounts" });`](https://docs.metamask.io/guide/rpc-api.html#eth-requestaccounts). Chiamare questa funzione aprirà MetaMask nel browser, dove sarà richiesto all'utente di connettere il proprio portafoglio alla tua dapp.
-- Se l'utente sceglie di connettersi, `method: "eth_requestAccounts"` restituirà un insieme contenente tutti gli indirizzi del conto dell'utente, connessi alla dapp. Nel complesso, la nostra funzione `connectWallet` restituirà un oggetto JSON contenente il _primo_ `address` in questo array \(vedi la riga 9\) e un messaggio di `status` che richiede all'utente di scrivere un messaggio nello smart contract.
-- Se l'utente rifiuta la connessione, allora l'oggetto JSON conterrà una stringa vuota per l'`address` restituito e un messaggio di `status` che indica che l'utente ha rifiutato la connessione.
+- Se l'utente sceglie di connettersi, `method: "eth_requestAccounts"` restituirà un array contenente tutti gli indirizzi degli account dell'utente collegati alla dApp. Complessivamente, la nostra funzione `connectWallet` restituirà un oggetto JSON che contiene il _primo_ `address` in questo array (vedi riga 9) e un messaggio di `status` che chiede all'utente di scrivere un messaggio allo smart contract.
+- Se l'utente rifiuta la connessione, l'oggetto JSON conterrà una stringa vuota per l'`address` restituito e un messaggio `status` che riflette il rifiuto della connessione da parte dell'utente.
### Aggiungi la funzione connectWallet al tuo componente UI Minter.js {#add-connect-wallet}
-Ora che abbiamo scritto questa funzione `connectWallet`, connettiamola al nostro componente `Minter.js.`.
+Ora che abbiamo scritto questa funzione `connectWallet`, colleghiamola al nostro componente `Minter.js.`.
Prima, dovremo importare la nostra funzione nel file `Minter.js`, aggiungendo `import { connectWallet } from "./utils/interact.js";` in cima al file `Minter.js`. Le tue prime 11 righe di `Minter.js` dovrebbero somigliare a questo:
@@ -301,7 +303,7 @@ import { connectWallet } from "./utils/interact.js";
const Minter = (props) => {
- //State variables
+ //Variabili di stato
const [walletAddress, setWallet] = useState("");
const [status, setStatus] = useState("");
const [name, setName] = useState("");
@@ -321,7 +323,7 @@ const connectWalletPressed = async () => {
Nota come gran parte della nostra funzionalità è esterna al nostro componente `Minter.js` dal file `interact.js`? Questo perché stiamo seguendo il modello M-V-C!
-In `connectWalletPressed`, creiamo semplicemente una chiamata d'attesa alla nostra funzione `connectWallet` importata e, usando la sua risposta, aggiorniamo le nostre variabili `status` e `walletAddress` tramite i loro hook di stato.
+In `connectWalletPressed`, creiamo semplicemente una chiamata `await` alla nostra funzione `connectWallet` importata e, usando la sua risposta, aggiorniamo le nostre variabili `status` e `walletAddress` tramite i loro hook di stato.
Ora, salviamo entrambi i file `Minter.js` e `interact.js` e testiamo la nostra UI.
@@ -331,9 +333,9 @@ Se hai MetaMask installato, ti dovrebbe essere richiesto di connettere il tuo po
Dovresti vedere ora che il pulsante del portafoglio indica che l'indirizzo è connesso.
-Prova quindi a ricaricare la pagina... questo è strano. Il nostro pulsante del portafoglio ci sta richiedendo di connetterci a MetaMask, anche se è già connesso...
+Prova quindi a ricaricare la pagina... strano. Il nostro pulsante del portafoglio ci sta richiedendo di connetterci a MetaMask, anche se è già connesso...
-Non preoccuparti! Possiamo risolverlo facilmente implementando una funzione chiamata `getCurrentWalletConnected`, che verificherà se un indirizzo è già connesso alla nostra dapp e aggiornerà l'UI di conseguenza!
+Non preoccuparti! Possiamo risolverlo facilmente implementando una funzione chiamata `getCurrentWalletConnected`, che verificherà se un indirizzo è già connesso alla nostra dApp e aggiornerà l'UI di conseguenza!
### La funzione getCurrentWalletConnected {#get-current-wallet}
@@ -349,12 +351,12 @@ export const getCurrentWalletConnected = async () => {
if (addressArray.length > 0) {
return {
address: addressArray[0],
- status: "👆🏽 Write a message in the text-field above.",
+ status: "👆🏽 Scrivi un messaggio nel campo di testo qui sopra.",
}
} else {
return {
address: "",
- status: "🦊 Connect to MetaMask using the top right button.",
+ status: "🦊 Connettiti a MetaMask usando il pulsante in alto a destra.",
}
}
} catch (err) {
@@ -371,7 +373,7 @@ export const getCurrentWalletConnected = async () => {
@@ -384,7 +386,7 @@ export const getCurrentWalletConnected = async () => {
Questo codice è _molto_ simile alla funzione `connectWallet` che abbiamo scritto poco fa.
-La differenza principale è che, invece di chiamare il metodo `eth_requestAccounts`, che apre MetaMask perché l'utente connetta il proprio portafoglio, qui chiamiamo il metodo `eth_accounts` che, semplicemente, restituisce un insieme contenente gli indirizzi di MetaMask correntemente connessi alla nostra dapp.
+La differenza principale è che, invece di chiamare il metodo `eth_requestAccounts`, che apre MetaMask perché l'utente connetta il proprio portafoglio, qui chiamiamo il metodo `eth_accounts` che, semplicemente, restituisce un array contenente gli indirizzi di MetaMask correntemente connessi alla nostra dApp.
Per vedere questa funzione in azione, chiamiamola nella funzione `useEffect` del nostro componente `Minter.js`.
@@ -394,7 +396,7 @@ Come abbiamo fatto per `connectWallet`, dobbiamo importare questa funzione dal f
import { useEffect, useState } from "react"
import {
connectWallet,
- getCurrentWalletConnected, //import here
+ getCurrentWalletConnected, //importa qui
} from "./utils/interact.js"
```
@@ -412,7 +414,7 @@ Nota che stiamo usando la risposta alla nostra chiamata a `getCurrentWalletConne
Una volta aggiunto questo codice, prova a ricaricare la nostra finestra del browser. Il pulsante dovrebbe dire che sei connesso e mostrare un'anteprima dell'indirizzo del tuo portafoglio connesso, anche dopo un refresh!
-### Implementare addWalletListener {#implement-add-wallet-listener}
+### Implementa addWalletListener {#implement-add-wallet-listener}
Il passaggio finale della configurazione del portafoglio della nostra dapp è implementare l'ascoltatore del portafoglio, così che la nostra UI si aggiorni al cambiamento dello stato del nostro portafoglio, ad esempio, quando l'utente si disconnette o cambia conto.
@@ -424,10 +426,10 @@ function addWalletListener() {
window.ethereum.on("accountsChanged", (accounts) => {
if (accounts.length > 0) {
setWallet(accounts[0])
- setStatus("👆🏽 Write a message in the text-field above.")
+ setStatus("👆🏽 Scrivi un messaggio nel campo di testo qui sopra.")
} else {
setWallet("")
- setStatus("🦊 Connect to MetaMask using the top right button.")
+ setStatus("🦊 Connettiti a MetaMask usando il pulsante in alto a destra.")
}
})
} else {
@@ -435,7 +437,7 @@ function addWalletListener() {
)
@@ -445,9 +447,9 @@ function addWalletListener() {
Esaminiamo rapidamente cosa sta succedendo qui:
-- Per prima cosa, la nostra funzione verifica se `window.ethereum` è abilitata \(cioè se MetaMask è installato\).
- - Se non lo è, impostiamo semplicemente la nostra variabile di stato `status`a una stringa JSX che richiede all'utente di installare MetaMask.
- - Se è abilitato, configuriamo l'ascoltatore `window.ethereum.on("accountsChanged")` alla riga 3, affinché ascolti i cambiamenti di stato nel portafoglio di MetaMask, tra cui, quando l'utente connette un ulteriore conto alla dapp, cambia conto, o ne disconnette uno. Se è connesso almeno un conto, la variabile di stato `walletAddress` è aggiornata come primo conto nell'insieme `accounts`, restituito dall'ascoltatore. Altrimenti, `walletAddress` è impostato come una stringa vuota.
+- Innanzitutto, la nostra funzione controlla se `window.ethereum` è abilitato (cioè se MetaMask è installato).
+ - In caso contrario, impostiamo semplicemente la nostra variabile di stato `status` su una stringa JSX che richiede all'utente di installare MetaMask.
+ - Se è abilitato, configuriamo l'ascoltatore `window.ethereum.on("accountsChanged")` alla riga 3, affinché ascolti i cambiamenti di stato nel portafoglio di MetaMask, tra cui, quando l'utente connette un ulteriore account alla dApp, cambia account, o ne disconnette uno. Se è connesso almeno un account, la variabile di stato `walletAddress` è aggiornata come primo account nell'array `accounts`, restituito dall'ascoltatore. Altrimenti, `walletAddress` è impostato come una stringa vuota.
Infine, dobbiamo chiamarlo nella nostra funzione `useEffect`:
@@ -463,7 +465,7 @@ useEffect(async () => {
E voilà! Abbiamo completato la programmazione di tutte le funzionalità del nostro portafoglio! Ora che il nostro portafoglio è configurato, cerchiamo di capire come coniare il nostro NFT!
-## Guida di base ai Metadati del NFT {#nft-metadata-101}
+## Metadati NFT 101 {#nft-metadata-101}
Ricorda quindi che i metadati del NFT di cui abbiamo appena parlato al Passaggio 0 di questo tutorial, portano in vita un NFT, consentendogli di avere proprietà quali una risorsa digitale, un nome, una descrizione e altri attributi.
@@ -477,41 +479,41 @@ Il testo nei campi "Link to Asset", "Name", "Description" comprenderà le divers
Per memorizzare i nostri metadati su IPFS, useremo [Pinata](https://pinata.cloud/), una comoda API e un toolkit per IPFS. Al prossimo passaggio, spiegheremo esattamente come farlo!
-## Utilizza Pinata per fissare i tuoi metadati su IPFS {#use-pinata-to-pin-your-metadata-to-IPFS}
+## Usa Pinata per fissare i tuoi metadati su IPFS {#use-pinata-to-pin-your-metadata-to-IPFS}
-Se non hai un conto di [Pinata](https://pinata.cloud/), registrane gratuitamente uno [qui](https://app.pinata.cloud/auth/signup) e completa i passaggi per verificare la tua email e il tuo conto.
+Se non hai un account [Pinata](https://pinata.cloud/), registrane gratuitamente uno [qui](https://app.pinata.cloud/auth/signup) e completa i passaggi per verificare la tua email e il tuo account.
-### Crea la tua chiave API di Pinata {#create-pinata-api-key}
+### Crea la tua chiave API Pinata {#create-pinata-api-key}
-Vai alla pagina [https://pinata.cloud/keys](https://pinata.cloud/keys), quindi seleziona il pulsante "Nuova Chiave" in alto, abilita il widget Admin e assegna un nome alla tua chiave.
+Vai alla pagina [https://pinata.cloud/keys](https://pinata.cloud/keys), quindi seleziona il pulsante "Nuova chiave" in alto, imposta il widget Admin come abilitato e assegna un nome alla tua chiave.
Ti sarà poi mostrato un popup con le informazioni sulla tua API. Assicurati di conservarle da qualche parte al sicuro.
Ora che la nostra chiave è configurata, aggiungiamola al nostro progetto così da poterla usare.
-### Crea un file .env {#create-a-env}
+### Creare un file .env {#create-a-env}
-Possiamo memorizzare in sicurezza la nostra chiave e il codice segreto di Pinata in un file di ambiente. Installiamo il [pacchetto dotenv](https://www.npmjs.com/package/dotenv) nella cartella del progetto.
+Possiamo memorizzare in sicurezza la nostra chiave e il codice segreto di Pinata in un file di ambiente. Installiamo il [pacchetto dotenv](https://www.npmjs.com/package/dotenv) nella directory del tuo progetto.
-Apri una nuova scheda nel terminale \(separata da quella che sta eseguendo l'host locale\) e assicurati di essere nella cartella `minter-starter-files`, poi esegui il seguente comando nel terminale:
+Apri una nuova scheda nel terminale (separata da quella che sta eseguendo l'host locale) e assicurati di essere nella cartella `minter-starter-files`, poi esegui il seguente comando nel terminale:
```text
npm install dotenv --save
```
-Crea quindi un file `.env` nella cartella di root del tuo `minter-starter-files` inserendo quanto segue a riga di comando:
+Crea quindi un file `.env` nella directory principale di `minter-starter-files` inserendo quanto segue a riga di comando:
```javascript
vim.env
```
-Questo aprirà il file `.env` in vim \(un editor di testo\). Per salvarlo, clicca "esc" + ":" + "q" sulla tua tastiera in questa sequenza.
+Questo aprirà il file `.env` in vim (un editor di testo). Per salvarlo, clicca "esc" + ":" + "q" sulla tua tastiera in questa sequenza.
Poi, su VSCode, vai al file `.env` e aggiungi al suo interno la tua chiave API di Pinata e il codice segreto dell'API, come segue:
```text
-REACT_APP_PINATA_KEY =
-REACT_APP_PINATA_SECRET =
+REACT_APP_PINATA_KEY =
+REACT_APP_PINATA_SECRET =
```
Salva il file: sei pronto ora per scrivere la funzione per caricare i tuoi metadati di JSON su IPFS!
@@ -539,7 +541,7 @@ const axios = require("axios")
export const pinJSONToIPFS = async (JSONBody) => {
const url = `https://api.pinata.cloud/pinning/pinJSONToIPFS`
- //making axios POST request to Pinata ⬇️
+ //effettua la richiesta POST di axios a Pinata ⬇️
return axios
.post(url, JSONBody, {
headers: {
@@ -570,8 +572,8 @@ Prima di tutto, importa [axios](https://www.npmjs.com/package/axios), un client
Poi abbiamo la nostra funzione asincrona `pinJSONToIPFS`, che prende un `JSONBody` come input e la chiave API e il codice segreto di Pinata nell'intestazione, tutto per creare una richiesta di POST all'API `pinJSONToIPFS`.
-- Se questa richiesta di POST riesce, allora la nostra funzione restituisce un oggetto JSON con il booleano `success` impostato a true e il `pinataUrl` in cui i nostri metadati sono stati fissati. Useremo il `pinataUrl` restituito come l'input del `tokenURI` alla funzione di conio del nostro smart contract.
-- Se questa richiesta di POST fallisce, allora la nostra funzione restituisce un oggetto JSON con il booleano `success` impostato false e una stringa `message` che comunica l'errore.
+- Se questa richiesta di POST riesce, allora la nostra funzione restituisce un oggetto JSON con il booleano `success` impostato a true e il `pinataUrl` in cui i nostri metadati sono stati fissati. Useremo questo `pinataUrl` restituito come input `tokenURI` della funzione di minting del nostro smart contract.
+- Se questa richiesta di post fallisce, allora la nostra funzione restituisce un oggetto JSON con il booleano `success` impostato a false e una stringa `message` che comunica il nostro errore.
Come con i tipi restituiti dalla nostra funzione `connectWallet`, stiamo restituendo oggetti JSON, così da poterne usare i parametri per aggiornare le nostre variabili di stato e l'UI.
@@ -579,19 +581,19 @@ Come con i tipi restituiti dalla nostra funzione `connectWallet`, stiamo restitu
Ora che abbiamo un modo per caricare i metadati del nostro NFT su IPFS tramite la nostra funzione `pinJSONToIPFS`, avremo bisogno di un modo per caricare un'istanza del nostro smart contract, così da poterne chiamare la funzione `mintNFT`.
-Come menzionato prima, in questo tutorial useremo [questo smart contract NFT esistente](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE); se invece sei interessato a sapere come lo abbiamo creato, o se vuoi crearne uno tuo, consigliamo vivamente di dare un'occhiata all'altro nostro tutorial, ["Come Creare un NFT."](https://docs.alchemyapi.io/alchemy/tutorials/how-to-create-an-nft).
+Come menzionato prima, in questo tutorial useremo [questo smart contract NFT esistente](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE); se invece sei interessato a sapere come lo abbiamo creato, o se vuoi crearne uno tuo, consigliamo vivamente di dare un'occhiata all'altro nostro tutorial, ["Come creare un NFT."](https://www.alchemy.com/docs/how-to-create-an-nft).
### L'ABI del contratto {#contract-abi}
-Se hai esaminato attentamente i nostri file, avrai notato che nella nostra cartella `src` si trova un file `contract-abi.json`. Un'ABI serve per specificare quale funzione invocherà un contratto, oltre che per garantire che la funzione restituirà i dati nel formato previsto.
+Se hai esaminato attentamente i nostri file, avrai notato che nella nostra directory `src` si trova un file `contract-abi.json`. Un'ABI serve per specificare quale funzione invocherà un contratto, oltre che per garantire che la funzione restituirà i dati nel formato previsto.
Avremo anche bisogno di una chiave API di Alchemy e dell'API Alchemy Web3 per connetterci alla blockchain di Ethereum e caricare il nostro smart contract.
### Crea la tua chiave API di Alchemy {#create-alchemy-api}
-Se non hai già un conto di Alchemy, [registrane gratuitamente uno qui.](https://alchemy.com/?a=eth-org-nft-minter)
+Se non hai già un account Alchemy, [registrati gratuitamente qui.](https://alchemy.com/?a=eth-org-nft-minter)
-Una volta creato un conto di Alchemy, puoi generare una chiave API creando un'app. Questo ci consentirà di effettuare richieste alla rete di prova di Ropsten.
+Una volta creato un conto di Alchemy, puoi generare una chiave API creando un'app. Questo ci permetterà di effettuare delle richieste alla rete di prova di Ropsten.
Vai alla pagina “Crea App” nella tua dashboard di Alchemy passando su “App” nella barra di navigazione e cliccando “Crea App”.
@@ -604,16 +606,16 @@ Fantastico, ora che abbiamo creato il nostro URL dell'API di Alchemy HTTP, copia
…e poi aggiungiamolo al nostro file `.env`. Nel complesso, il file .env dovrebbe somigliare a questo:
```text
-REACT_APP_PINATA_KEY =
-REACT_APP_PINATA_SECRET =
-REACT_APP_ALCHEMY_KEY = https://eth-ropsten.alchemyapi.io/v2/
+REACT_APP_PINATA_KEY =
+REACT_APP_PINATA_SECRET =
+REACT_APP_ALCHEMY_KEY = https://eth-ropsten.alchemyapi.io/v2/
```
Ora che abbiamo l'ABI del nostro contratto e la nostra chiave API di Alchemy, siamo pronti a caricare il nostro smart contract usando [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3).
-### Configura l'endpoint e il contratto di Web3 di Alchemy {#setup-alchemy-endpoint}
+### Configura l'endpoint e il contratto di Alchemy Web3 {#setup-alchemy-endpoint}
-Prima di tutto, se non lo hai già fatto, dovrai installare [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) navigando alla cartella home: `nft-minter-tutorial` nel terminale:
+Prima di tutto, se non lo hai già fatto, dovrai installare [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) navigando alla directory principale: `nft-minter-tutorial` nel terminale:
```text
cd ..
@@ -629,7 +631,7 @@ const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
const web3 = createAlchemyWeb3(alchemyKey)
```
-[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) è un wrapper intorno a[Web3.js](https://docs.web3js.org/) che fornisce metodi API migliorati e altri benefici fondamentale per semplificare la tua vita a uno sviluppatore web3. È progettato per richiedere una configurazione minima, così da poter iniziare a usarlo immediatamente nella tua app!
+[Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) è un wrapper di [Web3.js](https://docs.web3js.org/) che fornisce metodi API migliorati e altri benefici fondamentali per semplificare la vita agli sviluppatori web3. È progettato per richiedere una configurazione minima, così da poter iniziare a usarlo immediatamente nella tua app!
In seguito, aggiungiamo l'ABI del nostro contratto e l'indirizzo del contratto al nostro file.
@@ -647,70 +649,70 @@ Una volta che abbiamo entrambi, siamo pronti a iniziare a programmare la nostra
## Implementa la funzione mintNFT {#implement-the-mintnft-function}
-Nel file `interact.js`, definiamo la nostra funzione, `mintNFT`, che conierà il nostro omonimo NFT.
+Nel file `interact.js`, definiamo la nostra funzione, `mintNFT`, che eseguirà il minting del nostro NFT.
Poiché effettueremo numerose chiamate asincrone \(a Pinata per fissare i nostri metadati su IPFS, a Alchemy Web3 per caricare il nostro smart contract e a MetaMask per firmare le nostre transazioni\), anche la nostra funzione sarà asincrona.
-I tre input alla nostra funzione saranno l'`url` della nostra risorsa digitale, il `name` e la `description`. Aggiungi la seguente firma della funzione sotto la funzione `connectWallet`:
+I tre input della nostra funzione saranno `url`, `name` e `description` del nostro asset digitale. Aggiungi la seguente firma della funzione sotto la funzione `connectWallet`:
```javascript
export const mintNFT = async (url, name, description) => {}
```
-### Gestione degli errori d'input {#input-error-handling}
+### Gestione degli errori di input {#input-error-handling}
Naturalmente, è utile avere una certa gestione degli errori di input all'inizio della funzione, uscendo dalla funzione se i nostri parametri di input sono errati. Nella nostra funzione, aggiungiamo il seguente codice:
```javascript
export const mintNFT = async (url, name, description) => {
- //error handling
+ //gestione degli errori
if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
return {
success: false,
- status: "❗Please make sure all fields are completed before minting.",
+ status: "❗Assicurati che tutti i campi siano compilati prima di eseguire il minting.",
}
}
}
```
-Essenzialmente, se uno qualsiasi dei parametri d'input è una stringa vuota, restituiamo un oggetto JSON in cui il booleano `success` è false e la stringa `status` indica che tutti i campi nella nostra UI devono esser completi.
+Essenzialmente, se uno qualsiasi dei parametri di input è una stringa vuota, restituiamo un oggetto JSON in cui il booleano `success` è `false` e la stringa `status` indica che tutti i campi nella nostra UI devono essere compilati.
-### Carica i metadati su IPFS {#upload-metadata-to-ipfs}
+### Caricare i metadati su IPFS {#upload-metadata-to-ipfs}
Una volta che sappiamo che i nostri metadati sono correttamente formattati, il prossimo passaggio è avvolgerli in un oggetto JSON e caricarli su IPFS tramite il `pinJSONToIPFS` che abbiamo scritto!
-Per farlo, prima dobbiamo importare la funzione `pinJSONToIPFS` nel nostro file `interact.js`. In cima al `interact.js`, aggiungiamo:
+Per farlo, prima dobbiamo importare la funzione `pinJSONToIPFS` nel nostro file `interact.js`. In cima a `interact.js`, aggiungiamo:
```javascript
import { pinJSONToIPFS } from "./pinata.js"
```
-Ricorda che `pinJSONToIPFS` riceve in un body JSON. Quindi, prima di effettuare una chiamata a esso, dovremo formattare i nostri parametri `url`, `name` e `description` in un oggetto JSON.
+Ricorda che `pinJSONToIPFS` riceve un body JSON. Quindi, prima di effettuare una chiamata a esso, dovremo formattare i nostri parametri `url`, `name` e `description` in un oggetto JSON.
Aggiorniamo il nostro codice per creare un oggetto JSON chiamato `metadata` e poi effettuiamo una chiamata a `pinJSONToIPFS` con questo parametro `metadata`:
```javascript
export const mintNFT = async (url, name, description) => {
- //error handling
+ //gestione degli errori
if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
return {
success: false,
- status: "❗Please make sure all fields are completed before minting.",
+ status: "❗Assicurati che tutti i campi siano compilati prima di eseguire il minting.",
}
}
- //make metadata
+ //crea metadati
const metadata = new Object()
metadata.name = name
metadata.image = url
metadata.description = description
- //make pinata call
+ //effettua la chiamata a pinata
const pinataResponse = await pinJSONToIPFS(metadata)
if (!pinataResponse.success) {
return {
success: false,
- status: "😢 Something went wrong while uploading your tokenURI.",
+ status: "😢 Si è verificato un errore durante il caricamento del tuo tokenURI.",
}
}
const tokenURI = pinataResponse.pinataUrl
@@ -719,7 +721,7 @@ export const mintNFT = async (url, name, description) => {
Nota che memorizziamo la risposta della nostra chiamata a `pinJSONToIPFS(metadata)` nell'oggetto `pinataResponse`. Analizziamo quindi questo oggetto alla ricerca di eventuali errori.
-Se è presente un errore, restituiamo un oggetto JSON in cui il booleano `success` è impostato a false e la nostra stringa `status` indica che la nostra chiamata non è andata a buon fine. Altrimenti, estraiamo `pinataURL` dal `pinataResponse` e lo memorizziamo come la nostra variabile `tokenURI`.
+Se si verifica un errore, restituiamo un oggetto JSON in cui il booleano `success` è `false` e la nostra stringa `status` indica che la chiamata non è riuscita. Altrimenti, estraiamo `pinataURL` da `pinataResponse` e lo memorizziamo come nostra variabile `tokenURI`.
È arrivato il momento di caricare il nostro smart contract usando l'API Alchemy Web3 che abbiamo inizializzato in cima al nostro file. Aggiungi la seguente riga di codice in fondo alla funzione `mintNFT` per impostare il contratto alla variabile globale `window.contract`:
@@ -727,19 +729,19 @@ Se è presente un errore, restituiamo un oggetto JSON in cui il booleano `succes
window.contract = await new web3.eth.Contract(contractABI, contractAddress)
```
-L'ultima cosa da aggiungere alla nostra funzione `mintNFT` è la nostra transazione di Ethereum:
+L'ultima cosa da aggiungere alla nostra funzione `mintNFT` è la nostra transazione Ethereum:
```javascript
-//set up your Ethereum transaction
+//imposta la tua transazione Ethereum
const transactionParameters = {
- to: contractAddress, // Required except during contract publications.
- from: window.ethereum.selectedAddress, // must match user's active address.
+ to: contractAddress, // Obbligatorio, tranne durante la pubblicazione di contratti.
+ from: window.ethereum.selectedAddress, // deve corrispondere all'indirizzo attivo dell'utente.
data: window.contract.methods
.mintNFT(window.ethereum.selectedAddress, tokenURI)
- .encodeABI(), //make call to NFT smart contract
+ .encodeABI(), //effettua la chiamata allo smart contract NFT
}
-//sign the transaction via MetaMask
+//firma la transazione tramite MetaMask
try {
const txHash = await window.ethereum.request({
method: "eth_sendTransaction",
@@ -748,13 +750,13 @@ try {
return {
success: true,
status:
- "✅ Check out your transaction on Etherscan: https://ropsten.etherscan.io/tx/" +
+ "✅ Controlla la tua transazione su Etherscan: https://ropsten.etherscan.io/tx/" +
txHash,
}
} catch (error) {
return {
success: false,
- status: "😥 Something went wrong: " + error.message,
+ status: "😥 Qualcosa è andato storto: " + error.message,
}
}
```
@@ -762,54 +764,54 @@ try {
Se conosci già le transazioni di Ethereum, noterai che la struttura è abbastanza simile a quella che hai visto.
- Prima, configuriamo i parametri delle nostre transazioni.
- - `to` specifica l'indirizzo del destinatario \(il nostro smart contract\)
- - `from` specifica il firmatario della transazione \(l'indirizzo dell'utente connesso a MetaMask: `window.ethereum.selectedAddress`\)
- - `data` contiene la chiamata al metodo `mintNFT` del nostro smart contract, che riceve come input il nostro `tokenURI` e l'indirizzo del portafoglio dell'utente, `window.ethereum.selectedAddress`.
-- Creiamo quindi una chiamata d'attesa, `window.ethereum.request,` in cui chiediamo a MetaMask di firmare la transazione. Nota che, in questa richiesta, stiamo specificando il nostro metodo eth \(eth_SentTransaction\) e passando il nostro `transactionParameters`. A questo punto, MetaMask si aprirà nel browser e richiederà all'utente di firmare o rifiutare la transazione.
- - Se la transazione va a buon fine, la funzione restituirà un oggetto JSON in cui il booleano `success` è impostato a true e la stringa `status` richiede all'utente di controllare Etherscan per ulteriori informazioni sulla sua transazione.
- - Se la transazione non va a buon fine, la funzione restituirà un oggetto JSON in cui il booleano `success` è impostato a false e la stringa `status` trasmette il messaggio d'errore.
+ - `to` specifica l'indirizzo del destinatario (il nostro smart contract)
+ - `from` specifica il firmatario della transazione (l'indirizzo dell'utente connesso a MetaMask: `window.ethereum.selectedAddress`)
+ - `data` contiene la chiamata al metodo `mintNFT` del nostro smart contract, che riceve come input il nostro `tokenURI` e l'indirizzo del portafoglio dell'utente, `window.ethereum.selectedAddress`
+- Creiamo quindi una chiamata `await`, `window.ethereum.request`, in cui chiediamo a MetaMask di firmare la transazione. Nota che, in questa richiesta, stiamo specificando il nostro metodo `eth` (`eth_SentTransaction`) e passando i nostri `transactionParameters`. A questo punto, MetaMask si aprirà nel browser e richiederà all'utente di firmare o rifiutare la transazione.
+ - Se la transazione va a buon fine, la funzione restituirà un oggetto JSON in cui il booleano `success` è impostato a `true` e la stringa `status` richiede all'utente di controllare Etherscan per ulteriori informazioni sulla sua transazione.
+ - Se la transazione non va a buon fine, la funzione restituirà un oggetto JSON in cui il booleano `success` è impostato a `false` e la stringa `status` trasmette il messaggio d'errore.
Nel complesso, la nostra funzione `mintNFT` dovrebbe somigliare a questa:
```javascript
export const mintNFT = async (url, name, description) => {
- //error handling
+ //gestione degli errori
if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
return {
success: false,
- status: "❗Please make sure all fields are completed before minting.",
+ status: "❗Assicurati che tutti i campi siano compilati prima di eseguire il minting.",
}
}
- //make metadata
+ //crea metadati
const metadata = new Object()
metadata.name = name
metadata.image = url
metadata.description = description
- //pinata pin request
+ //richiesta di pin a pinata
const pinataResponse = await pinJSONToIPFS(metadata)
if (!pinataResponse.success) {
return {
success: false,
- status: "😢 Something went wrong while uploading your tokenURI.",
+ status: "😢 Si è verificato un errore durante il caricamento del tuo tokenURI.",
}
}
const tokenURI = pinataResponse.pinataUrl
- //load smart contract
+ //carica smart contract
window.contract = await new web3.eth.Contract(contractABI, contractAddress) //loadContract();
- //set up your Ethereum transaction
+ //imposta la tua transazione Ethereum
const transactionParameters = {
- to: contractAddress, // Required except during contract publications.
- from: window.ethereum.selectedAddress, // must match user's active address.
+ to: contractAddress, // Obbligatorio, tranne durante la pubblicazione di contratti.
+ from: window.ethereum.selectedAddress, // deve corrispondere all'indirizzo attivo dell'utente.
data: window.contract.methods
.mintNFT(window.ethereum.selectedAddress, tokenURI)
- .encodeABI(), //make call to NFT smart contract
+ .encodeABI(), //effettua la chiamata allo smart contract NFT
}
- //sign transaction via MetaMask
+ //firma transazione tramite MetaMask
try {
const txHash = await window.ethereum.request({
method: "eth_sendTransaction",
@@ -818,13 +820,13 @@ export const mintNFT = async (url, name, description) => {
return {
success: true,
status:
- "✅ Check out your transaction on Etherscan: https://ropsten.etherscan.io/tx/" +
+ "✅ Controlla la tua transazione su Etherscan: https://ropsten.etherscan.io/tx/" +
txHash,
}
} catch (error) {
return {
success: false,
- status: "😥 Something went wrong: " + error.message,
+ status: "😥 Qualcosa è andato storto: " + error.message,
}
}
}
@@ -832,7 +834,7 @@ export const mintNFT = async (url, name, description) => {
Questa è una funzione gigante! Ora, dobbiamo solo connettere la nostra funzione `mintNFT` al nostro componente `Minter.js`...
-## Connetti mintNFT al nostro frontend di Minter.js {#connect-our-frontend}
+## Connetti mintNFT al nostro frontend Minter.js {#connect-our-frontend}
Apri il file `Minter.js` e aggiorna la riga `import { connectWallet, getCurrentWalletConnected } from "./utils/interact.js";` in alto affinché sia:
@@ -844,7 +846,7 @@ import {
} from "./utils/interact.js"
```
-Infine, implementa la funzione `onMintPressed` per effettuare la chiamata d'attesa alla tua funzione `mintNFT` importata e aggiornare la variabile di stato `status` affinché rifletta se la nostra transazione è andata o meno a buon fine:
+Infine, implementa la funzione `onMintPressed` per effettuare la chiamata `await` alla tua funzione `mintNFT` importata e aggiornare la variabile di stato `status` affinché rifletta se la nostra transazione è andata o meno a buon fine:
```javascript
const onMintPressed = async () => {
@@ -855,11 +857,11 @@ const onMintPressed = async () => {
## Distribuisci il tuo NFT a un sito web live {#deploy-your-NFT}
-Pronto a portare in vita il tuo progetto affinché gli utenti vi interagiscano? Dai un'occhiata a [questo tutorial](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online) per distribuire il tuo Coniatore su un sito web live.
+Pronto a portare in vita il tuo progetto affinché gli utenti vi interagiscano? Consulta [questo tutorial](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online) per la distribuzione del tuo Minter su un sito web live.
Un ultimo passaggio...
-## Prendi d'assalto il mondo della blockchain {#take-the-blockchain-world-by-storm}
+## Conquista il mondo della blockchain {#take-the-blockchain-world-by-storm}
Stiamo scherzando, sei arrivato alla fine del tutorial!
@@ -869,6 +871,6 @@ Per ricapitolare, creando un coniatore di NFT, hai imparato correttamente come:
- Chiamare i metodi dello smart contract dal tuo frontend
- Firmare le transazioni usando MetaMask
-Molto probabilmente vorrai mostrare gli NFT coniati tramite la tua dapp nel tuo portafoglio, dai quindi un'occhiata al nostro rapido tutorial [Come visualizzare il tuo NFT nel tuo Portafoglio](https://docs.alchemyapi.io/alchemy/tutorials/how-to-write-and-deploy-a-nft-smart-contract/how-to-view-your-nft-in-your-wallet)!
+Presumibilmente, vorrai mostrare gli NFT coniati tramite la tua dApp nel tuo portafoglio, dai quindi un'occhiata al nostro rapido tutorial [Come visualizzare il tuo NFT nel tuo portafoglio](https://www.alchemy.com/docs/how-to-view-your-nft-in-your-mobile-wallet)!
-E, come sempre, se hai qualsiasi domanda, siamo qui per aiutare sul [Discord di Alchemy](https://discord.gg/gWuC7zB). Non vediamo l'ora di vedere come applicherai i concetti di questo tutorial ai tuoi progetti futuri!
+E, come sempre, se hai qualsiasi domanda, siamo qui per aiutarti sul [Discord di Alchemy](https://discord.gg/gWuC7zB). Non vediamo l'ora di vedere come applicherai i concetti di questo tutorial ai tuoi progetti futuri!
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..c2adf4f5424 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,21 +1,24 @@
---
-title: "Guida del ponte standard di Optimism per contratti"
-description: Come funziona il ponte standard per Optimism? Perché funziona così?
+title: "Procedura dettagliata del contratto del ponte standard di Optimism"
+description: "Come funziona il ponte standard per Optimism? Perché funziona così?"
author: Ori Pomerantz
-tags:
- - "solidity"
- - "ponte"
- - "livello 2"
+tags: [ "Solidity", "ponte", "livello 2" ]
skill: intermediate
published: 2022-03-30
lang: it
---
-[Optimism](https://www.optimism.io/) è un [Rollup ottimistico](/developers/docs/scaling/optimistic-rollups/). I rollup ottimistici possono elaborare le transazioni a un prezzo molto più basso di quello della rete principale di Ethereum (nota anche come livello 1 o L1), poiché le transazioni sono elaborate solo da alcuni nodi, invece che da ogni nodo sulla rete. Allo stesso tempo, i dati vengono tutti scritti nel L1, così che tutto possa essere provato e ricostruito con le garanzie d'integrità e disponibilità della rete principale.
+[Optimism](https://www.optimism.io/) è un [rollup ottimistico](/developers/docs/scaling/optimistic-rollups/).
+I rollup ottimistici possono elaborare le transazioni a un prezzo molto più basso di quello della rete principale di Ethereum (nota anche come livello 1 o L1), poiché le transazioni sono elaborate solo da alcuni nodi, invece che da ogni nodo sulla rete.
+Allo stesso tempo, i dati vengono tutti scritti su L1, così che tutto possa essere provato e ricostruito con tutte le garanzie di integrità e disponibilità della rete principale.
-Per usare le risorse del L1 su Optimism (o su qualsiasi altro L2), le risorse devono essere collegate con un [ponte](/bridges/#prerequisites). Un modo per farlo è che gli utenti blocchino le risorse (ETH e [token ERC-20](/developers/docs/standards/tokens/erc-20/) sono le più comuni) nel L1 e ricevano le risorse equivalenti da usare nel L2. In definitiva, chiunque le riceva potrebbe volerle ricollegare al L1. Così facendo, le risorse sono bruciate nel L2 e poi rilasciate nuovamente all'utente nel L1.
+Per usare gli asset di L1 su Optimism (o qualsiasi altro L2), gli asset devono essere [collegati tramite un ponte](/bridges/#prerequisites).
+Un modo per raggiungere questo obiettivo è che gli utenti blocchino gli asset (i più comuni sono ETH e [token ERC-20](/developers/docs/standards/tokens/erc-20/)) su L1, e ricevano asset equivalenti da usare su L2.
+Infine, chiunque li ottenga potrebbe volerli ricollegare tramite ponte a L1.
+Così facendo, gli asset vengono bruciati su L2 e poi rilasciati di nuovo all'utente su L1.
-Questo è il modo in cui funziona il [ponte standard di Optimism](https://docs.optimism.io/app-developers/bridging/standard-bridge). In questo articolo esaminiamo il codice sorgente di quel ponte, per vedere come funziona e per studiarlo come un esempio di codice di Solidity ben scritto.
+Questo è il modo in cui funziona il [ponte standard di Optimism](https://docs.optimism.io/app-developers/bridging/standard-bridge).
+In questo articolo esaminiamo il codice sorgente di quel ponte, per vedere come funziona e per studiarlo come un esempio di codice Solidity ben scritto.
## Flussi di controllo {#control-flows}
@@ -28,21 +31,21 @@ Il ponte ha due flussi principali:
#### Livello 1 {#deposit-flow-layer-1}
-1. In caso di deposito di un ERC-20, il depositante concede al ponte un'indennità per spendere l'importo depositato
-2. Il depositante chiama il ponte L1 (`depositERC20`, `depositERC20To`, `depositETH`, o `depositETHTo`)
-3. Il ponte L1 prende possesso della risorsa collegata
- - ETH: la risorsa è trasferita dal depositante all'interno della chiamata
- - ERC-20: la risorsa è trasferita dal ponte a sé stessa, usando l'indennità fornita dal depositante
-4. Il ponte L1 usa il meccanismo di messaggio interdominio per chiamare `finalizeDeposit` sul ponte L2
+1. In caso di deposito di un ERC-20, il depositante concede al ponte un'autorizzazione (allowance) per spendere l'importo depositato.
+2. Il depositante chiama il ponte L1 (`depositERC20`, `depositERC20To`, `depositETH` o `depositETHTo`)
+3. Il ponte L1 prende possesso dell'asset collegato.
+ - ETH: l'asset è trasferito dal depositante all'interno della chiamata
+ - ERC-20: l'asset è trasferito dal ponte a sé stesso, usando l'autorizzazione (allowance) fornita dal depositante
+4. Il ponte L1 utilizza il meccanismo di messaggistica interdominio per chiamare `finalizeDeposit` sul ponte L2.
#### Livello 2 {#deposit-flow-layer-2}
5. Il ponte L2 verifica che la chiamata a `finalizeDeposit` sia legittima:
- Proviene dal contratto di messaggistica interdominio
- - Originariamente proveniva dal ponte su L1
+ - Proveniva originariamente dal ponte su L1
6. Il ponte L2 verifica se il contratto del token ERC-20 su L2 è quello corretto:
- - Il contratto L2 segnala che la sua controparte del L1 è uguale a quella da cui i token provenivano su L1
- - Il contratto L2 segnala che supporta l'interfaccia corretta ([che usa ERC-165](https://eips.ethereum.org/EIPS/eip-165)).
+ - Il contratto L2 segnala che la sua controparte L1 è uguale a quella da cui i token provenivano su L1
+ - Il contratto L2 segnala che supporta l'interfaccia corretta ([usando ERC-165](https://eips.ethereum.org/EIPS/eip-165)).
7. Se il contratto L2 è quello corretto, chiamalo per coniare il numero di token appropriato all'indirizzo corretto. Altrimenti, avvia un processo di prelievo per consentire all'utente di rivendicare i token su L1.
### Flusso di prelievo {#withdrawal-flow}
@@ -51,14 +54,14 @@ Il ponte ha due flussi principali:
1. Il prelevante chiama il ponte L2 (`withdraw` o `withdrawTo`)
2. Il ponte L2 brucia il giusto numero di token appartenente a `msg.sender`
-3. Il ponte L2 usa il meccanismo di messaggio interdominio per chiamare `finalizeETHWithdrawal` o `finalizeERC20Withdrawal` sul ponte L1
+3. Il ponte L2 utilizza il meccanismo di messaggistica interdominio per chiamare `finalizeETHWithdrawal` o `finalizeERC20Withdrawal` sul ponte L1.
#### Livello 1 {#withdrawal-flow-layer-1}
4. Il ponte L1 verifica che la chiamata a `finalizeETHWithdrawal` o `finalizeERC20Withdrawal` sia legittima:
- Proviene dal meccanismo di messaggistica interdominio
- - Originariamente proveniva dal ponte su L2
-5. Il ponte L1 trasferisce la risorsa appropriata (ETH o ERC-20) all'indirizzo appropriato
+ - Proveniva originariamente dal ponte su L2
+5. Il ponte L1 trasferisce l'asset appropriato (ETH o ERC-20) all'indirizzo appropriato.
## Codice del Livello 1 {#layer-1-code}
@@ -66,19 +69,21 @@ Questo è il codice eseguito su L1, la rete principale di Ethereum.
### IL1ERC20Bridge {#IL1ERC20Bridge}
-[Quest'interfaccia è definita qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol). Include le funzioni e definizioni richieste per collegare i token ERC-20.
+[Questa interfaccia è definita qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1ERC20Bridge.sol).
+Include le funzioni e le definizioni richieste per collegare i token ERC-20.
```solidity
// SPDX-License-Identifier: MIT
```
-[Gran parte del codice di Optimism è rilasciato sotto la licenza MIT](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-).
+[La maggior parte del codice di Optimism è rilasciata sotto licenza MIT](https://help.optimism.io/hc/en-us/articles/4411908707995-What-software-license-does-Optimism-use-).
```solidity
pragma solidity >0.5.0 <0.9.0;
```
-Al momento della scrittura, l'ultima versione di Solidity è la 0.8.12. Fino al rilascio della versione 0.9.0, non sappiamo se questo codice è compatibile con esso o meno.
+Al momento della scrittura, l'ultima versione di Solidity è la 0.8.12.
+Fino al rilascio della versione 0.9.0, non sappiamo se questo codice sarà compatibile con essa o meno.
```solidity
/**
@@ -92,14 +97,17 @@ interface IL1ERC20Bridge {
event ERC20DepositInitiated(
```
-Nella terminologia del ponte di Optimism, _deposito_ indica un trasferimento da L1 a L2, e _prelievo_ indica un trasferimento da L2 a L1.
+Nella terminologia del ponte di Optimism, "deposito" indica un trasferimento da L1 a L2 e "prelievo" indica un trasferimento da L2 a L1.
```solidity
address indexed _l1Token,
address indexed _l2Token,
```
-Nella maggior parte dei casi, l'indirizzo di un ERC-20 su L1 non equivale all'indirizzo dell'ERC-20 equivalente su L2. [Puoi visualizzare l'elenco di indirizzi di token qui](https://static.optimism.io/optimism.tokenlist.json). L'indirizzo con `chainId` 1 è sul L1 (Mainnet) e l'indirizzo con `chainId` 10 è sul L2 (Optimism). Gli altri due valori di `chainId` sono per la rete di prova Kovan (42) e la rete di prova Kovan di Optimistic (69).
+Nella maggior parte dei casi, l'indirizzo di un ERC-20 su L1 non equivale all'indirizzo dell'ERC-20 equivalente su L2.
+[Puoi vedere l'elenco degli indirizzi dei token qui](https://static.optimism.io/optimism.tokenlist.json).
+L'indirizzo con `chainId` 1 è su L1 (rete principale) e l'indirizzo con `chainId` 10 è su L2 (Optimism).
+Gli altri due valori di `chainId` sono per la rete di prova Kovan (42) e la rete di prova Kovan di Optimistic (69).
```solidity
address indexed _from,
@@ -122,7 +130,8 @@ Nella maggior parte dei casi, l'indirizzo di un ERC-20 su L1 non equivale all'in
);
```
-Lo stesso contratto del ponte gestisce i trasferimenti in entrambe le direzioni. Nel caso del ponte L1, ciò indica l'inizializzazione dei depositi e la finalizzazione dei prelievi.
+Lo stesso contratto del ponte gestisce i trasferimenti in entrambe le direzioni.
+Nel caso del ponte L1, ciò indica l'inizializzazione dei depositi e la finalizzazione dei prelievi.
```solidity
@@ -137,7 +146,8 @@ Lo stesso contratto del ponte gestisce i trasferimenti in entrambe le direzioni.
function l2TokenBridge() external returns (address);
```
-Questa funzione non è davvero necessaria, perché sul L2 è un contratto pre-distribuito, quindi è sempre all'indirizzo `0x4200000000000000000000000000000000000010`. Serve per simmetria con il ponte L2, perché _non_ è banale sapere l'indirizzo del ponte L1.
+Questa funzione non è davvero necessaria, perché su L2 è un contratto pre-distribuito, quindi è sempre all'indirizzo `0x4200000000000000000000000000000000000010`.
+È qui per simmetria con il ponte L2, perché l'indirizzo del ponte L1 _non_ è banale da conoscere.
```solidity
/**
@@ -159,7 +169,9 @@ Questa funzione non è davvero necessaria, perché sul L2 è un contratto pre-di
) external;
```
-Il parametro `_l2Gas` è l'importo di gas del L2 che la transazione può spendere. [Fino a un certo limite (elevato), è gratuito](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2), quindi, a meno che il contratto ERC-20 non faccia qualcosa di davvero strano durante il conio, non dovrebbe essere un problema. Questa funzione si occupa dello scenario comune, in cui un utente collega le risorse allo stesso indirizzo su una blockchain differente.
+Il parametro `_l2Gas` è l'importo di gas L2 che la transazione è autorizzata a spendere.
+[Fino a un certo limite (elevato), questo è gratuito](https://community.optimism.io/docs/developers/bridge/messaging/#for-l1-%E2%87%92-l2-transactions-2), quindi, a meno che il contratto ERC-20 non faccia qualcosa di veramente strano durante il conio, non dovrebbe essere un problema.
+Questa funzione si occupa dello scenario comune, in cui un utente collega gli asset allo stesso indirizzo su una blockchain differente.
```solidity
/**
@@ -218,13 +230,17 @@ Questa funzione è quasi identica a `depositERC20`, ma ti consente di inviare l'
I prelievi (e altri messaggi da L2 a L1) su Optimism sono processi in due fasi:
1. Una transazione di avvio su L2.
-2. Una transazione di finalizzazione o rivendicazione su L1. Questa transazione deve verificarsi dopo il [periodo di contestazione dell'errore](https://community.optimism.io/docs/how-optimism-works/#fault-proofs) perché la transazione di L2 termini.
+2. Una transazione di finalizzazione o rivendicazione su L1.
+ Questa transazione deve avvenire dopo la fine del [periodo di contestazione dell'errore](https://community.optimism.io/docs/how-optimism-works/#fault-proofs) per la transazione L2.
### IL1StandardBridge {#il1standardbridge}
-[Quest'interfaccia è definita qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol). Questo file contiene le definizioni dell'evento e la funzione per ETH. Queste definizioni sono molto simili a quelle definite nel precedente `IL1ERC20Bridge` per ERC-20.
+[Questa interfaccia è definita qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/IL1StandardBridge.sol).
+Questo file contiene le definizioni dell'evento e della funzione per ETH.
+Queste definizioni sono molto simili a quelle definite nel precedente `IL1ERC20Bridge` per ERC-20.
-L'interfaccia del ponte è divisa tra due file perché alcuni token ERC-20 richiedono un'elaborazione specifica e non possono esser gestiti dal ponte standard. Il ponte personalizzato che gestisce un token di questo tipo può quindi implementare `IL1ERC20Bridge` e non dover collegare anche ETH.
+L'interfaccia del ponte è divisa tra due file perché alcuni token ERC-20 richiedono un'elaborazione specifica e non possono essere gestiti dal ponte standard.
+In questo modo, il ponte personalizzato che gestisce un token di questo tipo può implementare `IL1ERC20Bridge` senza dover anche collegare ETH.
```solidity
// SPDX-License-Identifier: MIT
@@ -247,7 +263,8 @@ interface IL1StandardBridge is IL1ERC20Bridge {
);
```
-Questo evento è quasi identico alla versione di ERC-20 (`ERC20DepositInitiated`), salvo che mancano gli indirizzi del token di L1 e L2. Lo stesso vale per gli altri eventi e le altre funzioni.
+Questo evento è quasi identico alla versione ERC-20 (`ERC20DepositInitiated`), ma non include gli indirizzi dei token L1 e L2.
+Lo stesso vale per gli altri eventi e le altre funzioni.
```solidity
event ETHWithdrawalFinalized(
@@ -303,7 +320,7 @@ Questo evento è quasi identico alla versione di ERC-20 (`ERC20DepositInitiated`
### CrossDomainEnabled {#crossdomainenabled}
-[Questo contratto](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol) è ereditato da entrambi i ponti ([L1](#the-l1-bridge-contract) e [L2](#the-l2-bridge-contract)) per inviare i messaggi all'altro livello.
+[Questo contratto](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/CrossDomainEnabled.sol) è ereditato da entrambi i ponti ([L1](#the-l1-bridge-contract) e [L2](#the-l2-bridge-contract)) per inviare messaggi all'altro livello.
```solidity
// SPDX-License-Identifier: MIT
@@ -313,7 +330,8 @@ pragma solidity >0.5.0 <0.9.0;
import { ICrossDomainMessenger } from "./ICrossDomainMessenger.sol";
```
-[Quest'interfaccia](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol) dice al contratto come inviare i messaggi all'altro livello, usando la messaggistica interdominio. Questa messaggistica interdominio è un sistema totalmente a sé, che merita il proprio articolo, che spero scriverò in futuro.
+[Questa interfaccia](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/bridge/ICrossDomainMessenger.sol) indica al contratto come inviare messaggi all'altro livello, utilizzando il messaggero interdominio.
+Questa messaggistica interdominio è un sistema totalmente a sé, che merita un articolo a parte, che spero di scrivere in futuro.
```solidity
/**
@@ -342,7 +360,8 @@ contract CrossDomainEnabled {
}
```
-Il parametro che il contratto deve conoscere, l'indirizzo della messaggistica interdominio su questo livello. Questo parametro è impostato una volta, nel costruttore, e non cambia mai.
+L'unico parametro che il contratto deve conoscere è l'indirizzo del messaggero interdominio su questo livello.
+Questo parametro è impostato una volta, nel costruttore, e non cambia mai.
```solidity
@@ -358,7 +377,8 @@ Il parametro che il contratto deve conoscere, l'indirizzo della messaggistica in
modifier onlyFromCrossDomainAccount(address _sourceDomainAccount) {
```
-La messaggistica interdominio è accessibile da qualsiasi contratto sulla blockchain mentre è in esecuzione (sulla mainnet di Ethereum o su Optimism). Ma per fidarsi _solo_ di certi messaggi, se provengono dal ponte dall'altra parte, serve il ponte su entrambi i lati.
+La messaggistica interdominio è accessibile da qualsiasi contratto sulla blockchain su cui è in esecuzione (sulla rete principale di Ethereum o su Optimism).
+Ma è necessario che il ponte su ciascun lato si fidi di determinati messaggi solo se provengono dal ponte sull'altro lato.
```solidity
require(
@@ -367,7 +387,7 @@ La messaggistica interdominio è accessibile da qualsiasi contratto sulla blockc
);
```
-Solo i messaggi dalla messaggistica interdominio appropriata (`messenger`, come vedi di seguito) sono affidabili.
+Solo i messaggi provenienti dal messaggero interdominio appropriato (`messenger`, come vedrai di seguito) possono essere considerati affidabili.
```solidity
@@ -377,7 +397,8 @@ Solo i messaggi dalla messaggistica interdominio appropriata (`messenger`, come
);
```
-Il modo in cui la messaggistica interdominio fornisce l'indirizzo che ha inviato un messaggio con l'altro livello è [la funzione `.xDomainMessageSender()`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128). Se è chiamato nella transazione avviata dal messaggio, può fornire queste informazioni.
+Il modo in cui il messaggero interdominio fornisce l'indirizzo che ha inviato un messaggio all'altro livello è [la funzione `.xDomainMessageSender()`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol#L122-L128).
+Finché viene chiamata nella transazione avviata dal messaggio, può fornire questa informazione.
Dobbiamo assicurarci che il messaggio ricevuto provenga dall'altro ponte.
@@ -400,7 +421,8 @@ Dobbiamo assicurarci che il messaggio ricevuto provenga dall'altro ponte.
}
```
-Questa funzione restituisce la messaggistica interdominio. Usiamo una funzione piuttosto che la variabile `messenger` per consentire ai contratti che ereditano da questa di usare un algoritmo per specificare quale messaggistica interdominio utilizzare.
+Questa funzione restituisce il messaggero interdominio.
+Usiamo una funzione piuttosto che la variabile `messenger` per consentire ai contratti che ereditano da questo di usare un algoritmo per specificare quale messaggero interdominio utilizzare.
```solidity
@@ -424,7 +446,8 @@ Infine, la funzione che invia un messaggio all'altro livello.
// slither-disable-next-line reentrancy-events, reentrancy-benign
```
-[Slither](https://github.com/crytic/slither) è un analizzatore statico che Optimism esegue su ogni contratto per cercare le vulnerabilità e altri problemi potenziali. In questo caso, la seguente riga innesca due vulnerabilità:
+[Slither](https://github.com/crytic/slither) è un analizzatore statico che Optimism esegue su ogni contratto per cercare vulnerabilità e altri potenziali problemi.
+In questo caso, la riga seguente attiva due vulnerabilità:
1. [Eventi di rientranza](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-3)
2. [Rientranza benigna](https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities-2)
@@ -435,9 +458,9 @@ Infine, la funzione che invia un messaggio all'altro livello.
}
```
-In questo caso, non ci preoccupiamo della rientranza, sappiamo che `getCrossDomainMessenger()` restituisce un indirizzo affidabile, anche se Slither non ha modo di saperlo.
+In questo caso non ci preoccupiamo della rientranza, poiché sappiamo che `getCrossDomainMessenger()` restituisce un indirizzo affidabile, anche se Slither non ha modo di saperlo.
-### Il contratto del ponte di L1 {#the-l1-bridge-contract}
+### Il contratto del ponte L1 {#the-l1-bridge-contract}
[Il codice sorgente di questo contratto è qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol).
@@ -446,7 +469,8 @@ In questo caso, non ci preoccupiamo della rientranza, sappiamo che `getCrossDoma
pragma solidity ^0.8.9;
```
-Le interfacce possono far parte di altri contratti, quindi devono supportare una vasta gamma di versioni di Solidity. Ma il ponte in sé è il nostro contratto, e possiamo essere rigidi sulla versione di Solidity utilizzata.
+Le interfacce possono far parte di altri contratti, quindi devono supportare una vasta gamma di versioni di Solidity.
+Ma il ponte stesso è il nostro contratto e possiamo essere rigidi sulla versione di Solidity che utilizza.
```solidity
/* Interface Imports */
@@ -460,13 +484,14 @@ import { IL1ERC20Bridge } from "./IL1ERC20Bridge.sol";
import { IL2ERC20Bridge } from "../../L2/messaging/IL2ERC20Bridge.sol";
```
-[Quest'interfaccia](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) ci consente di creare messaggi per controllare il ponte standard su L2.
+[Questa interfaccia](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) ci consente di creare messaggi per controllare il ponte standard su L2.
```solidity
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
```
-[Quest'interfaccia](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) ci consente di controllare i contratti ERC-20. [Puoi approfondire questo argomento qui](/developers/tutorials/erc20-annotated-code/#the-interface).
+[Questa interfaccia](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) ci consente di controllare i contratti ERC-20.
+[Puoi leggere di più qui](/developers/tutorials/erc20-annotated-code/#the-interface).
```solidity
/* Library Imports */
@@ -479,26 +504,26 @@ import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.so
import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol";
```
-[`Lib_PredeployAddresses`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol) contiene gli indirizzi per i contratti L2 che hanno sempre lo stesso indirizzo. Comprende il ponte standard su L2.
+`Lib_PredeployAddresses`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol) contiene gli indirizzi dei contratti L2 che hanno sempre lo stesso indirizzo. Ciò include il ponte standard su L2.
```solidity
import { Address } from "@openzeppelin/contracts/utils/Address.sol";
```
-[Utility per indirizzi di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol). Serve a distinguere tra gli indirizzi del contratto e quelli appartenenti a conti posseduti esternamente (EOA).
+[Utility Address di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol). Serve a distinguere tra gli indirizzi del contratto e quelli appartenenti a conti di proprietà esterna (EOA).
-Non è una soluzione perfetta, perché non esiste modo di distinguere tra chiamate dirette e chiamate effettuate dal costruttore di un contratto ma, quantomeno, ci consente di identificare ed evitare alcuni errori comuni dell'utente.
+Si noti che questa non è una soluzione perfetta, perché non esiste modo di distinguere tra chiamate dirette e chiamate effettuate dal costruttore di un contratto ma, quantomeno, ci consente di identificare ed evitare alcuni errori comuni dell'utente.
```solidity
import { SafeERC20 } from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
```
-[Lo standard ERC-20](https://eips.ethereum.org/EIPS/eip-20) supporta due metodi di segnalazione del fallimento di un contratto:
+[Lo standard ERC-20](https://eips.ethereum.org/EIPS/eip-20) supporta due modi per un contratto di segnalare un fallimento:
1. Ripristino
2. Restituzione di `false`
-Gestire entrambi i casi renderebbe il nostro codice più complicato, quindi, invece, usiamo [`SafeERC20` di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol), che si assicura che [tutti i fallimenti portino a un ripristino](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96).
+La gestione di entrambi i casi renderebbe il nostro codice più complicato, quindi usiamo invece [`SafeERC20` di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol), che garantisce che [tutti i fallimenti risultino in un ripristino (`revert`)](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96).
```solidity
/**
@@ -512,7 +537,7 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled {
using SafeERC20 for IERC20;
```
-Questa riga specifica come usare il wrapper di `SafeERC20`, ogni volta che usiamo l'interfaccia di `IERC20`.
+Questa riga specifica come usare il wrapper `SafeERC20` ogni volta che usiamo l'interfaccia `IERC20`.
```solidity
@@ -531,7 +556,10 @@ L'indirizzo di [L2StandardBridge](#the-l2-bridge-contract).
mapping(address => mapping(address => uint256)) public deposits;
```
-Una doppia [mappatura](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) come questa definisce un [array sparso bidimensionale](https://en.wikipedia.org/wiki/Sparse_matrix). I valori in questa struttura di dati sono identificati come `deposit[L1 token addr][L2 token addr]`. Il valore predefinito è zero. Solo le celle impostate a un valore differente sono scritte in memoria.
+Una doppia [mappatura](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) come questa è il modo in cui si definisce una [matrice sparsa bidimensionale](https://en.wikipedia.org/wiki/Sparse_matrix).
+I valori in questa struttura di dati sono identificati come `deposit[indirizzo token L1][indirizzo token L2]`.
+Il valore predefinito è zero.
+Solo le celle impostate a un valore diverso vengono scritte nell'archiviazione.
```solidity
@@ -543,9 +571,13 @@ Una doppia [mappatura](https://www.tutorialspoint.com/solidity/solidity_mappings
constructor() CrossDomainEnabled(address(0)) {}
```
-Per poter aggiornare questo contratto senza dover copiare tutte le variabili in memoria. Per farlo, usiamo un [`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy), un contratto che usa [`delegatecall`](https://solidity-by-example.org/delegatecall/) per trasferire le chiamate a un contratto distinto, il cui indirizzo è memorizzato dal contratto del proxy (quando aggiorni, dici al proxy di modificare tale indirizzo). Quando usi `delegatecall`, la memoria rimane quella del contratto _chiamante_, quindi non sono influenzati i valori di tutte le variabili di stato del contratto.
+Per poter aggiornare questo contratto senza dover copiare tutte le variabili nell'archiviazione.
+Per farlo, usiamo un [`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy), un contratto che usa `delegatecall` per trasferire le chiamate a un contratto separato, il cui indirizzo è memorizzato dal contratto del proxy (quando si aggiorna, si dice al proxy di modificare tale indirizzo).
+Quando si usa `delegatecall`, l'archiviazione rimane quella del contratto _chiamante_, quindi i valori di tutte le variabili di stato del contratto non sono influenzati.
-Un effetto di questo schema è che l'archiviazione del contratto, ovvero la _chiamata_ di `delegatecall`, non è usata e dunque i valori del costruttore a esso passati non importano. Questo è il motivo per cui possiamo fornire un valore senza senso al costruttore di `CrossDomainEnabled`. È anche il motivo per cui l'inizializzazione di seguito è separata dal costruttore.
+Un effetto di questo schema è che l'archiviazione del contratto _chiamato_ da `delegatecall` non viene utilizzata e, quindi, i valori del costruttore passati ad esso non hanno importanza.
+Questo è il motivo per cui possiamo fornire un valore senza senso al costruttore di `CrossDomainEnabled`.
+È anche il motivo per cui l'inizializzazione sottostante è separata dal costruttore.
```solidity
/******************
@@ -559,19 +591,27 @@ Un effetto di questo schema è che l'archiviazione del contratto, ovvero la _chi
// slither-disable-next-line external-function
```
-Questo [test di Slither](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external), identifica le funzioni non chiamate dal codice del contratto e che potrebbero dunque esser dichiarate `external` invece che `public`. Il costo del gas delle funzioni `external` può essere inferiore, perché possono contenere dei parametri nei dati della chiamata. Le funzioni dichiarate come `public` devono esser accessibili dall'interno del contratto. I contratti non possono modificare i propri dati di chiamata, quindi, i parametri devono essere in memoria. Quando una funzione simile è chiamata esternamente, è necessario copiare i dati della chiamata alla memoria, il che costa gas. In questo caso la funzione è chiamata solo una volta, quindi, non siamo interessati alla sua inefficienza.
+Questo [test di Slither](https://github.com/crytic/slither/wiki/Detector-Documentation#public-function-that-could-be-declared-external) identifica le funzioni che non sono chiamate dal codice del contratto e che potrebbero quindi essere dichiarate `external` invece che `public`.
+Il costo del gas delle funzioni `external` può essere inferiore, perché possono essere fornite con parametri nei dati della chiamata (calldata).
+Le funzioni dichiarate `public` devono essere accessibili dall'interno del contratto.
+I contratti non possono modificare i propri dati di chiamata (calldata), quindi i parametri devono essere in memoria.
+Quando una funzione di questo tipo viene chiamata esternamente, è necessario copiare i dati della chiamata (calldata) in memoria, il che ha un costo in gas.
+In questo caso, la funzione viene chiamata solo una volta, quindi l'inefficienza non è importante per noi.
```solidity
function initialize(address _l1messenger, address _l2TokenBridge) public {
require(messenger == address(0), "Contract has already been initialized.");
```
-La funzione `initialize` dovrebbe esser chiamata solo una volta. Se cambia l'indirizzo della messaggistica interdominio di L1 o del ponte del token L2, creiamo un nuovo proxy e un nuovo ponte che lo chiama. È improbabile che si verifichi, tranne quando viene aggiornato l'intero sistema, un evento molto raro.
+La funzione `initialize` dovrebbe essere chiamata una sola volta.
+Se l'indirizzo del messaggero interdominio di L1 o del ponte del token L2 cambia, creiamo un nuovo proxy e un nuovo ponte che lo chiama.
+È improbabile che ciò accada, se non quando l'intero sistema viene aggiornato, un evento molto raro.
-Nota che questa funzione non ha alcun meccanismo che limiti _chi_ possa chiamarla. Questo significa che, in teoria, un malintenzionato potrebbe attendere la distribuzione del proxy e della prima versione del ponte e, poi, eseguire un [front running](https://solidity-by-example.org/hacks/front-running/) per ottenere la funzione `initialize`, prima dell'utente legittimo. Ma esistono due metodi per impedirlo:
+Si noti che questa funzione non ha alcun meccanismo che limiti _chi_ può chiamarla.
+Questo significa che, in teoria, un utente malintenzionato potrebbe attendere la distribuzione del proxy e della prima versione del ponte e poi eseguire un [front-running](https://solidity-by-example.org/hacks/front-running/) per arrivare alla funzione `initialize` prima dell'utente legittimo. Ma esistono due metodi per impedirlo:
-1. Se i contratti sono distribuiti indirettamente da un conto EOA, ma [in una transazione avente un altro contratto che li crea](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595), l'intero processo può esser atomico e terminare prima che ogni altra transazione sia eseguita.
-2. Se la chiamata legittima a `initialize` fallisce, è sempre possibile ignorare il proxy e il ponte appena creato e crearne di nuovi.
+1. Se i contratti non sono distribuiti direttamente da un EOA ma [in una transazione che ne prevede la creazione da parte di un altro contratto](https://medium.com/upstate-interactive/creating-a-contract-with-a-smart-contract-bdb67c5c8595), l'intero processo può essere atomico e terminare prima che venga eseguita qualsiasi altra transazione.
+2. Se la chiamata legittima a `initialize` fallisce, è sempre possibile ignorare il proxy e il ponte appena creati e crearne di nuovi.
```solidity
messenger = _l1messenger;
@@ -597,7 +637,7 @@ Questi sono i due parametri che il ponte deve conoscere.
}
```
-Per questo abbiamo bisogno delle utility `Address` di OpenZeppelin.
+Questo è il motivo per cui avevamo bisogno delle utility `Address` di OpenZeppelin.
```solidity
/**
@@ -611,7 +651,8 @@ Per questo abbiamo bisogno delle utility `Address` di OpenZeppelin.
}
```
-Questa funzione serve per scopi di test. Non compare nelle definizioni dell'interfaccia: non è pensata per un uso ordinario.
+Questa funzione esiste per scopi di test.
+Si noti che non compare nelle definizioni dell'interfaccia: non è per un uso normale.
```solidity
/**
@@ -633,7 +674,7 @@ Questa funzione serve per scopi di test. Non compare nelle definizioni dell'inte
}
```
-Queste due funzioni sono wrapper intorno a `_initiateETHDeposit`, la funzione che gestisce l'effettivo deposito di ETH.
+Queste due funzioni sono wrapper attorno a `_initiateETHDeposit`, la funzione che gestisce l'effettivo deposito di ETH.
```solidity
/**
@@ -656,7 +697,10 @@ Queste due funzioni sono wrapper intorno a `_initiateETHDeposit`, la funzione ch
bytes memory message = abi.encodeWithSelector(
```
-I messaggi interdominio funzionano chiamando il contratto di destinazione passando il messaggio come dati di chiamata. I contratti in Solidity interpretano sempre i propri dati di chiamata secondo [le specifiche ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html). La funzione di Solidity [`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions) crea questi dati di chiamata.
+Il modo in cui funzionano i messaggi interdominio è che il contratto di destinazione viene chiamato con il messaggio come dati di chiamata (calldata).
+I contratti in Solidity interpretano sempre i propri dati di chiamata (calldata) secondo
+[le specifiche ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html).
+La funzione di Solidity [`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions) crea questi dati di chiamata (calldata).
```solidity
IL2ERC20Bridge.finalizeDeposit.selector,
@@ -669,16 +713,16 @@ I messaggi interdominio funzionano chiamando il contratto di destinazione passan
);
```
-In questo caso il messaggio chiama [la funzione `finalizeDeposit`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148) con questi parametri:
+Il messaggio qui è di chiamare [la funzione `finalizeDeposit`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol#L141-L148) con questi parametri:
-| Parametro | Valore | Significato |
-| ----------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
-| \_l1Token | address(0) | Valore speciale che sta per ETH (che non è un token ERC-20) su L1 |
-| \_l2Token | Lib_PredeployAddresses.OVM_ETH | Il contratto L2 che gestisce ETH su Optimism, `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` (questo contratto è solo per uso interno a Optimism) |
-| \_from | \_from | L'indirizzo su L1 che invia gli ETH |
-| \_to | \_to | L'indirizzo su L2 che riceve gli ETH |
-| amount | msg.value | Importo di wei inviato (già inviato al ponte) |
-| \_data | \_data | Data aggiuntiva da allegare al deposito |
+| Parametro | Valore | Significato |
+| ------------------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| \_l1Token | address(0) | Valore speciale che sta per ETH (che non è un token ERC-20) su L1. |
+| \_l2Token | Lib_PredeployAddresses.OVM_ETH | Il contratto L2 che gestisce ETH su Optimism, `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` (questo contratto è solo per uso interno a Optimism). |
+| \_from | \_from | L'indirizzo su L1 che invia gli ETH. |
+| \_to | \_to | L'indirizzo su L2 che riceve gli ETH. |
+| importo | msg.value | Importo di wei inviato (che è già stato inviato al ponte). |
+| \_data | \_data | Dati aggiuntivi da allegare al deposito |
```solidity
// Send calldata into L2
@@ -686,7 +730,7 @@ In questo caso il messaggio chiama [la funzione `finalizeDeposit`](https://githu
sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);
```
-Invia il messaggio tramite la messaggistica interdominio.
+Invia il messaggio tramite il messaggero interdominio.
```solidity
// slither-disable-next-line reentrancy-events
@@ -694,16 +738,16 @@ Invia il messaggio tramite la messaggistica interdominio.
}
```
-Emette un evento per informare qualsiasi applicazione decentralizzata che ascolta questo trasferimento.
+Emette un evento per informare qualsiasi applicazione decentralizzata in ascolto di questo trasferimento.
```solidity
/**
* @inheritdoc IL1ERC20Bridge
*/
function depositERC20(
- .
- .
- .
+ .
+ .
+ .
) external virtual onlyEOA {
_initiateERC20Deposit(_l1Token, _l2Token, msg.sender, msg.sender, _amount, _l2Gas, _data);
}
@@ -712,15 +756,15 @@ Emette un evento per informare qualsiasi applicazione decentralizzata che ascolt
* @inheritdoc IL1ERC20Bridge
*/
function depositERC20To(
- .
- .
- .
+ .
+ .
+ .
) external virtual {
_initiateERC20Deposit(_l1Token, _l2Token, msg.sender, _to, _amount, _l2Gas, _data);
}
```
-Queste due funzioni sono wrapper intorno a `_initiateERC20Deposit`, la funzione che gestisce l'effettivo deposito ERC-20.
+Queste due funzioni sono wrapper attorno a `_initiateERC20Deposit`, la funzione che gestisce l'effettivo deposito ERC-20.
```solidity
/**
@@ -748,7 +792,9 @@ Queste due funzioni sono wrapper intorno a `_initiateERC20Deposit`, la funzione
) internal {
```
-Questa funzione è simile a `_initiateETHDeposit` di cui sopra, con alcune importanti differenze. La prima differenza è che questa funzione riceve come parametri gli indirizzi del token e l'importo da trasferire. Nel caso degli ETH, la chiamata al ponte include il trasferimento della risorsa al conto del ponte (`msg.value`).
+Questa funzione è simile a `_initiateETHDeposit` di cui sopra, con alcune importanti differenze.
+La prima differenza è che questa funzione riceve come parametri gli indirizzi dei token e l'importo da trasferire.
+Nel caso dell'ETH, la chiamata al ponte include già il trasferimento dell'asset al conto del ponte (`msg.value`).
```solidity
// When a deposit is initiated on L1, the L1 Bridge transfers the funds to itself for future
@@ -758,13 +804,14 @@ Questa funzione è simile a `_initiateETHDeposit` di cui sopra, con alcune impor
IERC20(_l1Token).safeTransferFrom(_from, address(this), _amount);
```
-I trasferimenti di token ERC-20 seguono un processo differente rispetto agli ETH:
+I trasferimenti di token ERC-20 seguono un processo diverso rispetto all'ETH:
-1. L'utente (`_from`) dà un indennità al ponte per trasferire i token appropriati.
-2. L'utente chiama il ponte con l'indirizzo del contratto del token, l'importo, etc.
-3. Il ponte trasferisce i token (a sé stesso) nell'ambito del processo di deposito.
+1. L'utente (`_from`) concede un'autorizzazione (allowance) al ponte per trasferire i token appropriati.
+2. L'utente chiama il ponte con l'indirizzo del contratto del token, l'importo, ecc.
+3. Il ponte trasferisce i token (a sé stesso) come parte del processo di deposito.
-Il primo passaggio potrebbe verificarsi in una transazione separata dalle ultime due. Tuttavia, il front running non è un problema perché le due funzioni che chiamano `_initiateERC20Deposit` (`depositERC20` e `depositERC20To`), chiamano questa funzione con `msg.sender` come solo parametro `_from`.
+Il primo passaggio potrebbe verificarsi in una transazione separata dagli ultimi due.
+Tuttavia, il front-running non è un problema perché le due funzioni che chiamano `_initiateERC20Deposit` (`depositERC20` e `depositERC20To`) chiamano questa funzione solo con `msg.sender` come parametro `_from`.
```solidity
// Construct calldata for _l2Token.finalizeDeposit(_to, _amount)
@@ -786,7 +833,8 @@ Il primo passaggio potrebbe verificarsi in una transazione separata dalle ultime
deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] + _amount;
```
-Aggiungi l'importo di token depositato alla struttura dei dati `deposits`. Potrebbero esistere diversi indirizzi su L2 corrispondenti allo stesso token L1 ERC-20, quindi non basta usare il saldo del ponte del token L1 ERC-20, per monitorare i depositi.
+Aggiunge l'importo di token depositato alla struttura di dati `deposits`.
+Potrebbero esistere più indirizzi su L2 che corrispondono allo stesso token L1 ERC-20, quindi non è sufficiente utilizzare il saldo del ponte del token L1 ERC-20 per tenere traccia dei depositi.
```solidity
@@ -808,20 +856,21 @@ Aggiungi l'importo di token depositato alla struttura dei dati `deposits`. Potre
bytes calldata _data
```
-Il ponte L2 invia un messaggio alla messaggistica interdominio del L2, che fa sì che la messaggistica interdominio del L1 chiami questa funzione (una volta che la [transazione che finalizza il messaggio](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions) è inviata al L1, ovviamente).
+Il ponte L2 invia un messaggio al messaggero interdominio L2, il che fa sì che il messaggero interdominio L1 chiami questa funzione (una volta che la [transazione che finalizza il messaggio](https://community.optimism.io/docs/developers/bridge/messaging/#fees-for-l2-%E2%87%92-l1-transactions) viene inviata su L1, ovviamente).
```solidity
) external onlyFromCrossDomainAccount(l2TokenBridge) {
```
-Assicurati che questo sia un messaggio _legittimo_, proveniente dalla messaggistica interdominio e proveniente dal ponte del token del L2. Questa funzione è usata per prelevare ETH dal ponte, quindi dobbiamo assicurarci che sia chiamata solo dal chiamante autorizzato.
+Assicurati che questo sia un messaggio _legittimo_, proveniente dal messaggero interdominio e originato dal ponte del token L2.
+Questa funzione è usata per prelevare ETH dal ponte, quindi dobbiamo assicurarci che sia chiamata solo dal chiamante autorizzato.
```solidity
// slither-disable-next-line reentrancy-events
(bool success, ) = _to.call{ value: _amount }(new bytes(0));
```
-Il metodo per trasferire ETH è chiamare il destinatario indicando l'importo di wei nel `msg.value`.
+Il modo per trasferire ETH è chiamare il destinatario con l'importo di wei in `msg.value`.
```solidity
require(success, "TransferHelper::safeTransferETH: ETH transfer failed");
@@ -830,7 +879,7 @@ Il metodo per trasferire ETH è chiamare il destinatario indicando l'importo di
emit ETHWithdrawalFinalized(_from, _to, _amount, _data);
```
-Genera un evento riguardante il prelievo.
+Emetti un evento riguardante il prelievo.
```solidity
}
@@ -848,16 +897,15 @@ Genera un evento riguardante il prelievo.
) external onlyFromCrossDomainAccount(l2TokenBridge) {
```
-Questa funzione è simile al precedente `finalizeETHWithdrawal`, con le modifiche necessarie per i token ERC-20.
+Questa funzione è simile a `finalizeETHWithdrawal` di cui sopra, con le modifiche necessarie per i token ERC-20.
```solidity
deposits[_l1Token][_l2Token] = deposits[_l1Token][_l2Token] - _amount;
```
-Aggiorna la struttura dei dati di `deposits`.
+Aggiorna la struttura dei dati `deposits`.
```solidity
-
// When a withdrawal is finalized on L1, the L1 Bridge transfers the funds to the withdrawer
// slither-disable-next-line reentrancy-events
IERC20(_l1Token).safeTransfer(_to, _amount);
@@ -881,15 +929,22 @@ Aggiorna la struttura dei dati di `deposits`.
}
```
-Vi è stata un'implementazione precedente del ponte. Quando ci siamo spostati a questa nuova implementazione, abbiamo dovuto spostare tutte le risorse. I token ERC-20 possono essere semplicemente spostati. Al contrario, per trasferire ETH a un contratto, serve l'approvazione di quel contratto, e proprio questo a cui serve `donateETH`.
+C'è stata un'implementazione precedente del ponte.
+Quando siamo passati da quella implementazione a questa, abbiamo dovuto spostare tutti gli asset.
+I token ERC-20 possono essere semplicemente spostati.
+Tuttavia, per trasferire ETH a un contratto, è necessaria l'approvazione di quel contratto, che è ciò che `donateETH` ci fornisce.
-## Token ERC-20 sul L2 {#erc-20-tokens-on-l2}
+## Token ERC-20 su L2 {#erc-20-tokens-on-l2}
-Perché un token ERC-20 si adatti al ponte standard, deve consentire al ponte standard, e _solo_ al ponte standard, di coniare il token. Questo è necessario perché i ponti devono assicurare che il numero di token in circolazione su Optimism sia pari al numero di token bloccati nel contratto del ponte del L1. Se esistono troppi token su L2, alcuni utenti non potrebbero ricollegare le proprie risorse al L1. Invece di un ponte fidato, ricreeremmo essenzialmente la [riserva frazionaria bancaria](https://www.investopedia.com/terms/f/fractionalreservebanking.asp). Se esistono troppi token su L1, alcuni di questi rimarrebbero bloccati nel contratto del ponte per sempre, perché non esiste modo di rilasciarli senza bruciare token del L2.
+Affinché un token ERC-20 si adatti al ponte standard, deve consentire al ponte standard, e _solo_ al ponte standard, di coniare il token.
+Questo è necessario perché i ponti devono garantire che il numero di token in circolazione su Optimism sia uguale al numero di token bloccati all'interno del contratto del ponte L1.
+Se ci sono troppi token su L2, alcuni utenti non sarebbero in grado di ricollegare i propri asset a L1.
+Invece di un ponte fidato, ricreeremmo essenzialmente un [sistema bancario a riserva frazionaria](https://www.investopedia.com/terms/f/fractionalreservebanking.asp).
+Se ci sono troppi token su L1, alcuni di questi token rimarrebbero bloccati all'interno del contratto del ponte per sempre, perché non c'è modo di rilasciarli senza bruciare i token L2.
### IL2StandardERC20 {#il2standarderc20}
-Ogni token ERC-20 sul L2 che usa il ponte standard deve presentare [quest'interfaccia](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol), che ha le funzioni e gli eventi necessari al ponte standard.
+Ogni token ERC-20 su L2 che utilizza il ponte standard deve fornire [questa interfaccia](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/IL2StandardERC20.sol), che contiene le funzioni e gli eventi di cui il ponte standard ha bisogno.
```solidity
// SPDX-License-Identifier: MIT
@@ -898,20 +953,24 @@ pragma solidity ^0.8.9;
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
```
-[L'interfaccia standard dell'ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) non include le funzioni `mint` e `burn`. Questi metodi non sono richiesti dallo [standard ERC-20](https://eips.ethereum.org/EIPS/eip-20), che non specifica i meccanismi per creare e distruggere i token.
+[L'interfaccia standard ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) non include le funzioni `mint` e `burn`.
+Questi metodi non sono richiesti dallo [standard ERC-20](https://eips.ethereum.org/EIPS/eip-20), che non specifica i meccanismi per creare e distruggere i token.
```solidity
import { IERC165 } from "@openzeppelin/contracts/utils/introspection/IERC165.sol";
```
-[L'interfaccia ERC-165](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol) è usata per specificare quali funzioni sono fornite da un contratto. [Puoi leggere lo standard qui](https://eips.ethereum.org/EIPS/eip-165).
+[L'interfaccia ERC-165](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/introspection/IERC165.sol) è utilizzata per specificare quali funzioni fornisce un contratto.
+[Puoi leggere lo standard qui](https://eips.ethereum.org/EIPS/eip-165).
```solidity
interface IL2StandardERC20 is IERC20, IERC165 {
function l1Token() external returns (address);
```
-Questa funzione fornisce l'indirizzo del token L1, collegato a questo contratto. Nota che non esiste una funzione simile nella direzione opposta. Dobbiamo poter collegare qualsiasi token del L1, indipendentemente dal fatto che il supporto a L2 sia stato o meno pianificato alla sua implementazione.
+Questa funzione fornisce l'indirizzo del token L1 che è collegato tramite ponte a questo contratto.
+Si noti che non abbiamo una funzione simile nella direzione opposta.
+Dobbiamo essere in grado di collegare tramite ponte qualsiasi token L1, indipendentemente dal fatto che il supporto a L2 sia stato pianificato o meno durante la sua implementazione.
```solidity
@@ -924,11 +983,13 @@ Questa funzione fornisce l'indirizzo del token L1, collegato a questo contratto.
}
```
-Funzioni ed eventi per coniare (creare) e bruciare (distruggere) i token. Il ponte dovrebbe esser la sola entità capace d'eseguire queste funzioni per assicurare che il numero di token sia corretto (pari al numero di token bloccati su L1).
+Funzioni ed eventi per coniare (creare) e bruciare (distruggere) i token.
+Il ponte dovrebbe essere l'unica entità in grado di eseguire queste funzioni per garantire che il numero di token sia corretto (uguale al numero di token bloccati su L1).
### L2StandardERC20 {#L2StandardERC20}
-[Questa è la nostra implementazione dell'interfaccia di `IL2StandardERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol). A meno che tu non necessiti di qualche tipo di logica personalizzata, dovresti usare questa.
+[Questa è la nostra implementazione dell'interfaccia `IL2StandardERC20`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/standards/L2StandardERC20.sol).
+A meno che non sia necessaria una logica personalizzata, si dovrebbe usare questa.
```solidity
// SPDX-License-Identifier: MIT
@@ -937,7 +998,8 @@ pragma solidity ^0.8.9;
import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
```
-[Il contratto ERC-20 di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol). Optimism non vuole reinventare la ruota, specialmente quando questa è ben rodata e deve esser abbastanza affidabile da contenere delle risorse.
+[Il contratto ERC-20 di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol).
+Optimism non crede nel reinventare la ruota, specialmente quando la ruota è ben controllata e deve essere abbastanza affidabile da contenere asset.
```solidity
import "./IL2StandardERC20.sol";
@@ -947,7 +1009,7 @@ contract L2StandardERC20 is IL2StandardERC20, ERC20 {
address public l2Bridge;
```
-Questi sono due parametri di configurazione aggiuntivi che noi richiediamo e che invece ERC-20 normalmente non richiede.
+Questi sono i due parametri di configurazione aggiuntivi che richiediamo e che ERC-20 normalmente non richiede.
```solidity
@@ -968,7 +1030,7 @@ Questi sono due parametri di configurazione aggiuntivi che noi richiediamo e che
}
```
-Per prima cosa, chiama il costruttore per il contratto da cui ereditiamo (`ERC20(_name, _symbol)`) e poi imposta le nostre variabili.
+Prima chiama il costruttore per il contratto da cui ereditiamo (`ERC20(_name, _symbol)`) e poi imposta le nostre variabili.
```solidity
@@ -988,11 +1050,12 @@ Per prima cosa, chiama il costruttore per il contratto da cui ereditiamo (`ERC20
}
```
-[ERC-165](https://eips.ethereum.org/EIPS/eip-165) funziona così. Ogni interfaccia è un numero di funzioni supportate ed è identificata come l'[OR esclusivo](https://en.wikipedia.org/wiki/Exclusive_or) dei [selettori della funzione ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector) di queste funzioni.
+Questo è il modo in cui funziona [ERC-165](https://eips.ethereum.org/EIPS/eip-165).
+Ogni interfaccia è un insieme di funzioni supportate ed è identificata come lo [OR esclusivo](https://en.wikipedia.org/wiki/Exclusive_or) dei [selettori di funzione ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector) di tali funzioni.
-Il ponte L2 usa ERC-165 come controllo di integrità per assicurarsi che il contratto ERC-20 a cui invia le risorse sia un `IL2StandardERC20`.
+Il ponte L2 usa ERC-165 come controllo di integrità per assicurarsi che il contratto ERC-20 a cui invia gli asset sia un `IL2StandardERC20`.
-**Nota:** Non c'è nulla che impedisca che un contratto malevolo fornisca risposte false a `supportsInterface`, questo è quindi un meccanismo di controllo dell'integrità, _non_ un meccanismo di sicurezza.
+**Nota:** non c'è nulla che impedisca a un contratto fraudolento di fornire risposte false a `supportsInterface`, quindi questo è un meccanismo di controllo dell'integrità, _non_ un meccanismo di sicurezza.
```solidity
// slither-disable-next-line external-function
@@ -1011,13 +1074,15 @@ Il ponte L2 usa ERC-165 come controllo di integrità per assicurarsi che il cont
}
```
-Solo il ponte L2 può coniare e bruciare le risorse.
+Solo il ponte L2 è autorizzato a coniare e bruciare asset.
-`_mint` e `_burn` sono in realtà definiti nel [contratto ERC-20 di OpenZeppelin](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn). Quel contratto non li espone esternamente, perché le condizioni per coniare e bruciare token sono tanto varie quanto il numero di metodi per usare ERC-20.
+`_mint` e `_burn` sono in realtà definiti nel [contratto ERC-20 di OpenZeppelin](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn).
+Quel contratto semplicemente non li espone esternamente, perché le condizioni per coniare e bruciare i token sono tanto varie quanto i modi di usare un ERC-20.
-## Codice del ponte di L2 {#l2-bridge-code}
+## Codice del ponte L2 {#l2-bridge-code}
-Questo è il codice che esegue il ponte su Optimism. [Il codice sorgente di questo contratto è qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol).
+Questo è il codice che esegue il ponte su Optimism.
+[Il codice sorgente di questo contratto è qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol).
```solidity
// SPDX-License-Identifier: MIT
@@ -1029,10 +1094,13 @@ import { IL1ERC20Bridge } from "../../L1/messaging/IL1ERC20Bridge.sol";
import { IL2ERC20Bridge } from "./IL2ERC20Bridge.sol";
```
-L'interfaccia di [IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) è molto simile all'[equivalente di L1](#IL1ERC20Bridge), visto in precedenza. Vi sono due differenze significative:
+L'interfaccia [IL2ERC20Bridge](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/IL2ERC20Bridge.sol) è molto simile all'[equivalente L1](#IL1ERC20Bridge) che abbiamo visto sopra.
+Ci sono due differenze significative:
-1. Su L1, avvii i depositi e finalizzi i prelievi. Qui, avvii i prelievi e finalizzi i depositi.
-2. Su L1 è necessario distinguere tra ETH e token ERC-20. Su L2 possiamo usare le stesse funzioni per entrambi perché, internamente, i saldi di ETH su Optimism sono gestiti come un token ERC-20 con l'indirizzo [0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://optimistic.etherscan.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000).
+1. Su L1 si avviano i depositi e si finalizzano i prelievi.
+ Qui si avviano i prelievi e si finalizzano i depositi.
+2. Su L1 è necessario distinguere tra token ETH ed ERC-20.
+ Su L2 possiamo usare le stesse funzioni per entrambi, perché internamente i saldi di ETH su Optimism sono gestiti come un token ERC-20 con l'indirizzo [0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000](https://explorer.optimism.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000).
```solidity
/* Library Imports */
@@ -1060,7 +1128,9 @@ contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled {
address public l1TokenBridge;
```
-Tieni traccia dell'indirizzo del ponte L1. Nota che, a differenza dell'equivalente L1, qui _serve_ questa variabile. L'indirizzo del ponte L1 non è noto preventivamente.
+Tiene traccia dell'indirizzo del ponte L1.
+Si noti che, a differenza dell'equivalente L1, qui _abbiamo bisogno_ di questa variabile.
+L'indirizzo del ponte L1 non è noto in anticipo.
```solidity
@@ -1108,7 +1178,9 @@ Tieni traccia dell'indirizzo del ponte L1. Nota che, a differenza dell'equivalen
}
```
-Queste due funzioni avviano dei prelievi. Nota che non serve specificare l'indirizzo del token L1. I token L2 dovrebbero dirci l'indirizzo dell'equivalente L1.
+Queste due funzioni avviano i prelievi.
+Si noti che non è necessario specificare l'indirizzo del token L1.
+Ci si aspetta che i token L2 ci dicano l'indirizzo dell'equivalente L1.
```solidity
@@ -1138,7 +1210,7 @@ Queste due funzioni avviano dei prelievi. Nota che non serve specificare l'indir
IL2StandardERC20(_l2Token).burn(msg.sender, _amount);
```
-Nota che _non_ ci stiamo affidando al parametro `_from`, ma su `msg.sender`, molto più difficile da falsificare (impossibile, per quanto ne so).
+Si noti che _non_ ci affidiamo al parametro `_from`, ma a `msg.sender`, che è molto più difficile da falsificare (impossibile, a quanto ne so).
```solidity
@@ -1202,7 +1274,8 @@ Questa funzione è chiamata da `L1StandardBridge`.
) external virtual onlyFromCrossDomainAccount(l1TokenBridge) {
```
-Assicurati che la fonte del messaggio sia legittima. Questo è importante perché questa funzione chiama `_mint` e potrebbe esser usata per dare token non coperti dai token posseduti dal ponte su L1.
+Assicurati che la fonte del messaggio sia legittima.
+Questo è importante perché questa funzione chiama `_mint` e potrebbe essere usata per dare token non coperti da quelli che il ponte possiede su L1.
```solidity
// Check the target token is compliant and
@@ -1216,7 +1289,7 @@ Assicurati che la fonte del messaggio sia legittima. Questo è importante perch
Controlli di integrità:
1. L'interfaccia corretta è supportata
-2. L'indirizzo L1 del contratto ERC-20 del L2 corrisponde alla sorgente L1 dei token
+2. L'indirizzo L1 del contratto ERC-20 L2 corrisponde all'origine L1 dei token.
```solidity
) {
@@ -1228,10 +1301,10 @@ Controlli di integrità:
emit DepositFinalized(_l1Token, _l2Token, _from, _to, _amount, _data);
```
-Se il controllo di integrità riesce, finalizza il deposito:
+Se i controlli di integrità passano, finalizza il deposito:
1. Conia i token
-2. Genera l'evento appropriato
+2. Emetti l'evento appropriato
```solidity
} else {
@@ -1245,7 +1318,8 @@ Se il controllo di integrità riesce, finalizza il deposito:
// user error and mitigate some forms of malicious contract behavior.
```
-Se un utente ha commesso un errore rilevabile usando l'indirizzo del token L2 errato, dobbiamo annullare il deposito e restituire i token sul L1. Il solo modo in cui possiamo farlo da L2 è inviare un messaggio che dovrà attendere il periodo di contestazione dell'errore, ma è molto meglio per l'utente rispetto a perdere permanentemente i token.
+Se un utente ha commesso un errore rilevabile usando l'indirizzo del token L2 errato, vogliamo annullare il deposito e restituire i token su L1.
+L'unico modo per farlo da L2 è inviare un messaggio che dovrà attendere il periodo di contestazione dell'errore, ma è molto meglio per l'utente che perdere i token in modo permanente.
```solidity
bytes memory message = abi.encodeWithSelector(
@@ -1268,10 +1342,15 @@ Se un utente ha commesso un errore rilevabile usando l'indirizzo del token L2 er
}
```
-## Conclusioni {#conclusion}
+## Conclusione {#conclusion}
+
+Il ponte standard è il meccanismo più flessibile per i trasferimenti di asset.
+Tuttavia, essendo così generico, non è sempre il meccanismo più facile da usare.
+Soprattutto per i prelievi, la maggior parte degli utenti preferisce usare [ponti di terze parti](https://optimism.io/apps#bridge) che non attendono il periodo di contestazione e non richiedono una prova di Merkle per finalizzare il prelievo.
-Il ponte standard è il meccanismo più flessibile per i trasferimenti di risorse. Tuttavia, essendo così generico, non è sempre il metodo più facile da usare. Specialmente per i prelievi, gran parte degli utenti preferisce usare [ponti di terze parti](https://optimism.io/apps#bridge) che non attendono il periodo di contestazione dell'errore e non richiedono una prova di Merkle per finalizzare il prelievo.
+Questi ponti funzionano tipicamente avendo asset su L1, che forniscono immediatamente per una piccola commissione (spesso inferiore al costo del gas per un prelievo con il ponte standard).
+Quando il ponte (o le persone che lo gestiscono) prevede di avere pochi asset su L1, trasferisce asset sufficienti da L2. Poiché si tratta di prelievi molto grandi, il costo del prelievo è ammortizzato su un importo elevato e rappresenta una percentuale molto più piccola.
-Questi ponti funzionano tipicamente avendo delle risorse sul L1, che forniscono immediatamente per una ridotta commissione (spesso inferiore al costo del gas per un prelievo del ponte standard). Quando il ponte (o le persone che lo gestiscono) prevede di avere poche risorse su L1, trasferisce delle sufficienti risorse da L2. Poiché questi sono prelievi molto grandi, il costo di prelievo è ammortizzato su un grande importo e ha un'incidenza minore.
+Speriamo che questo articolo ti abbia aiutato a capire meglio come funziona il livello 2 e come scrivere codice Solidity chiaro e sicuro.
-Spero che questo articolo ti abbia aiutato a comprendere meglio come funziona il livello 2 e come scrivere un codice chiaro e sicuro in Solidity.
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
diff --git a/public/content/translations/it/developers/tutorials/reverse-engineering-a-contract/index.md b/public/content/translations/it/developers/tutorials/reverse-engineering-a-contract/index.md
index 54164ff0435..82252bf15f7 100644
--- a/public/content/translations/it/developers/tutorials/reverse-engineering-a-contract/index.md
+++ b/public/content/translations/it/developers/tutorials/reverse-engineering-a-contract/index.md
@@ -3,28 +3,26 @@ title: "Decompilare un contratto"
description: Come comprendere un contratto quando non hai il codice sorgente
author: Ori Pomerantz
lang: it
-tags:
- - "evm"
- - "opcode"
+tags: [ "evm", "opcodes" ]
skill: advanced
published: 2021-12-30
---
## Introduzione {#introduction}
-_Non ci sono segreti sulla blockchain_: tutto ciò che si verifica è coerente, verificabile e disponibile pubblicamente. Idealmente, il codice sorgente dei [contratti dovrebbe essere pubblicato e verificato su Etherscan](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code). Però [non sempre è così](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code). In questo articolo imparerai come decompilare i contratti guardando un contratto privo del codice sorgente, [`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f).
+_Non ci sono segreti sulla blockchain_, tutto ciò che avviene è coerente, verificabile e disponibile pubblicamente. Idealmente, [i contratti dovrebbero avere il codice sorgente pubblicato e verificato su Etherscan](https://etherscan.io/address/0xb8901acb165ed027e32754e0ffe830802919727f#code). Tuttavia, [non è sempre così](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#code). In questo articolo imparerai come decompilare i contratti guardando un contratto senza codice sorgente, [`0x2510c039cc3b061d79e564b38836da87e31b342f`](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f).
-Esistono dei decompilatori, ma non producono sempre [risultati utilizzabili](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f). In questo articolo imparerai come decompilare manualmente e comprendere un contratto dagli [opcode](https://github.com/wolflo/evm-opcodes), nonché come interpretare i risultati di un decompilatore.
+Esistono dei decompilatori, ma non sempre producono [risultati utilizzabili](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f). In questo articolo imparerai come decompilare manualmente e comprendere un contratto dagli [opcode](https://github.com/wolflo/evm-opcodes), nonché come interpretare i risultati di un decompilatore.
-Per poter comprendere questo articolo dovresti già conoscere le basi dell'EVM ed avere una certa familiarità con l'assembler dell'EVM. [Puoi leggere articoli su questi argomenti qui](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e).
+Per poter comprendere questo articolo dovresti già conoscere le basi dell'EVM ed avere una certa familiarità con l'assembler dell'EVM. [Puoi leggere di più su questi argomenti qui](https://medium.com/mycrypto/the-ethereum-virtual-machine-how-does-it-work-9abac2b7c9e).
## Preparare il codice eseguibile {#prepare-the-executable-code}
-Puoi ottenere gli opcode andando su Etherscan per il contratto, facendo clic sulla scheda **Contract** e poi **Switch to Opcodes View**. Ottieni una vista composta da un opcode per riga.
+Puoi ottenere gli opcode andando su Etherscan per il contratto, facendo clic sulla scheda **Contract** e poi su **Switch to Opcodes View**. Ottieni una vista composta da un opcode per riga.
-
+
-Per poter comprendere i salti, però, devi sapere dove si trova ogni opcode nel codice. Per farlo, un modo è aprire un Foglio di calcolo di Google e incollare gli opcode nella colonna C. [Puoi saltare i passaggi successivi creando una copia di questo foglio di calcolo già pronto](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing).
+Per poter comprendere i salti, però, devi sapere dove si trova ogni opcode nel codice. Per farlo, un modo è aprire un Foglio di calcolo Google e incollare gli opcode nella colonna C. [Puoi saltare i passaggi successivi creando una copia di questo foglio di calcolo già pronto](https://docs.google.com/spreadsheets/d/1tKmTJiNjUwHbW64wCKOSJxHjmh0bAUapt6btUYE7kDA/edit?usp=sharing).
Il prossimo passaggio è ottenere le posizioni corrette del codice, così da poter comprendere i salti. Inseriremo la dimensione dell'opcode nella colonna B e la posizione (in esadecimale) nella colonna A. Digita questa funzione nella cella `B1` e poi copiala e incollala per il resto della colonna B, fino alla fine del codice. Dopo averlo fatto, puoi nascondere la colonna B.
@@ -32,7 +30,7 @@ Il prossimo passaggio è ottenere le posizioni corrette del codice, così da pot
=1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)
```
-Questa funzione aggiunge prima un byte per l'opcode stesso e poi cerca `PUSH`. Gli opcode push sono speciali perché hanno bisogno di byte aggiuntivi affinché venga eseguito il push del valore. Se l'opcode è un `PUSH`, estraiamo il numero di byte e lo aggiungiamo.
+Questa funzione aggiunge prima un byte per l'opcode stesso e poi cerca `PUSH`. Gli opcode Push sono speciali perché hanno bisogno di byte aggiuntivi affinché venga eseguito il push del valore. Se l'opcode è un `PUSH`, estraiamo il numero di byte e lo aggiungiamo.
In `A1` inserisci il primo scostamento: zero. Poi, in `A2`, inserisci questa funzione e di nuovo copiala e incollala per il resto della colonna A:
@@ -42,258 +40,258 @@ In `A1` inserisci il primo scostamento: zero. Poi, in `A2`, inserisci questa fun
Ci serve che questa funzione ci restituisca il valore esadecimale perché i valori su cui è stato eseguito il push prima dei salti (`JUMP` e `JUMPI`) ci vengono dati in esadecimali.
-## Il Punto d'accesso (0x00) {#the-entry-point-0x00}
+## Il punto d'ingresso (0x00) {#the-entry-point-0x00}
I contratti sono sempre eseguiti dal primo byte. Questa è la parte iniziale del codice:
-| Offset | Opcode | Stack (dopo l'opcode) |
-| ------:| ------------ | --------------------- |
-| 0 | PUSH1 0x80 | 0x80 |
-| 2 | PUSH1 0x40 | 0x40, 0x80 |
-| 4 | MSTORE | Vuoto |
-| 5 | PUSH1 0x04 | 0x04 |
-| 7 | CALLDATASIZE | CALLDATASIZE 0x04 |
-| 8 | LT | CALLDATASIZE\<4 |
-| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE\<4 |
-| C | JUMPI | Vuoto |
+| Scostamento | Opcode | Stack (dopo l'opcode) |
+| ----------: | ------------ | ---------------------------------------------- |
+| 0 | PUSH1 0x80 | 0x80 |
+| 2 | PUSH1 0x40 | 0x40, 0x80 |
+| 4 | MSTORE | Vuoto |
+| 5 | PUSH1 0x04 | 0x04 |
+| 7 | CALLDATASIZE | CALLDATASIZE 0x04 |
+| 8 | LT | CALLDATASIZE\<4 |
+| 9 | PUSH2 0x005e | 0x5E CALLDATASIZE\<4 |
+| C | JUMPI | Vuoto |
Questo codice fa due cose:
1. Scrive 0x80 come un valore a 32 byte nelle posizioni di memoria 0x40-0x5F (0x80 è memorizzato in 0x5F e 0x40-0x5E sono tutti zeri).
-2. Legge la dimensione dei calldata. Normalmente i dati della chiamata per un contratto di Ethereum seguono [l'ABI (Application Binary Interface, interfaccia binaria dell'applicazione)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html), che richiede come minimo quattro byte per il selettore della funzione. Se la dimensione dei dati della chiamata è inferiore a quattro, salta a 0x5E.
+2. Legge la dimensione dei calldata. Normalmente i dati della chiamata per un contratto Ethereum seguono [l'ABI (application binary interface)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html), che richiede come minimo quattro byte per il selettore della funzione. Se la dimensione dei dati della chiamata è inferiore a quattro, salta a 0x5E.
-
+
-### Il Gestore a 0x5E (per i dati della chiamata non ABI) {#the-handler-at-0x5e-for-non-abi-call-data}
+### Il gestore a 0x5E (per i dati di chiamata non-ABI) {#the-handler-at-0x5e-for-non-abi-call-data}
-| Offset | Opcode |
-| ------:| ------------ |
-| 5E | JUMPDEST |
-| 5F | CALLDATASIZE |
-| 60 | PUSH2 0x007c |
-| 63 | JUMPI |
+| Scostamento | Opcode |
+| ----------: | ------------ |
+| 5E | JUMPDEST |
+| 5F | CALLDATASIZE |
+| 60 | PUSH2 0x007c |
+| 63 | JUMPI |
-Questo frammento inizia con un `JUMPDEST`. I programmi dell'EVM (macchina virtuale di Ethereum) lanciano un'eccezione se salti a un opcode che non è `JUMPDEST`. Poi guarda la CALLDATASIZE e se è "true" (ovvero, non è zero) salta a 0x7C. Lo vedremo di seguito.
+Questo frammento inizia con un `JUMPDEST`. I programmi della EVM (macchina virtuale di Ethereum) lanciano un'eccezione se salti a un opcode che non è `JUMPDEST`. Poi guarda la CALLDATASIZE e se è "true" (ovvero, non è zero) salta a 0x7C. Lo vedremo di seguito.
-| Offset | Opcode | Stack (dopo l'opcode) |
-| ------:| ---------- | ------------------------------------------------------------------------------ |
-| 64 | CALLVALUE | [Wei](/glossary/#wei) fornito dalla chiamata. Chiamato `msg.value` in Solidity |
-| 65 | PUSH1 0x06 | 6 CALLVALUE |
-| 67 | PUSH1 0x00 | 0 6 CALLVALUE |
-| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE |
-| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE |
-| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE |
+| Scostamento | Opcode | Stack (dopo l'opcode) |
+| ----------: | ---------- | ------------------------------------------------------------------------------------------------------------ |
+| 64 | CALLVALUE | [Wei](/glossary/#wei) fornito dalla chiamata. Chiamato msg.value in Solidity |
+| 65 | PUSH1 0x06 | 6 CALLVALUE |
+| 67 | PUSH1 0x00 | 0 6 CALLVALUE |
+| 69 | DUP3 | CALLVALUE 0 6 CALLVALUE |
+| 6A | DUP3 | 6 CALLVALUE 0 6 CALLVALUE |
+| 6B | SLOAD | Storage[6] CALLVALUE 0 6 CALLVALUE |
-Quindi quando non ci sono dati della chiamata leggiamo il valore di Storage[6]. Non sappiamo ancora cosa sia questo valore, ma possiamo cercare delle transazioni ricevute dal contratto prive di dati della chiamata. Le transazioni che trasferiscono semplicemente ETH senza alcun dato della chiamata (e dunque senza metodo) contengono in Etherscan il metodo `Transfer`. Difatti, [la prima vera transazione ricevuta dal contratto](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7) è un trasferimento.
+Quindi quando non ci sono dati della chiamata leggiamo il valore di Storage[6]. Non sappiamo ancora cosa sia questo valore, ma possiamo cercare delle transazioni ricevute dal contratto prive di dati della chiamata. Le transazioni che trasferiscono semplicemente ETH senza alcun dato di chiamata (e dunque senza metodo) contengono in Etherscan il metodo `Transfer`. [La primissima transazione ricevuta dal contratto](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7), infatti, è un trasferimento.
-Se guardiamo in quella transazione e facciamo clic su **Click to see More**, vediamo che i dati della chiamata, detti dati di input, sono vuoti (`0x`). Nota anche che il valore è 1,559 ETH, che sarà rilevante in seguito.
+Se guardiamo in quella transazione e facciamo clic su **Click to see More**, vediamo che i dati della chiamata, detti dati di input, sono effettivamente vuoti (`0x`). Nota anche che il valore è 1,559 ETH, che sarà rilevante in seguito.
-A questo punto, fai clic sulla scheda **State** ed espandi il contratto che stiamo decompilando (0x2510...). Puoi vedere che `Storage[6]` è cambiato durante la transazione e, passando da Hex a **Number**, vedrai che è diventato 1.559.000.000.000.000.000, il valore trasferito in wei (ho aggiunto i punti per chiarezza), corrispondente al valore del contratto successivo.
+A questo punto, fai clic sulla scheda **State** ed espandi il contratto che stiamo decompilando (0x2510...). Puoi vedere che `Storage[6]` è cambiato durante la transazione e, se passi da Hex a **Number**, vedrai che è diventato 1.559.000.000.000.000.000, il valore trasferito in wei (ho aggiunto i punti per chiarezza), corrispondente al valore del contratto successivo.
![Il cambiamento in Storage[6]](storage6.png)
-Se guardiamo i cambiamenti di stato causati da [altre transazioni `Transfer` dallo stesso periodo](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b66fd5d6a6863db627067167cbf93d84d1#statechange), vediamo che `Storage[6]` ha monitorato il valore del contratto per un po'. Per ora lo chiameremo `Value*`. L'asterisco (`*`) ci ricorda che ancora non _sappiamo_ cosa faccia questa variabile, ma non può servire solo a tracciare il valore del contratto, poiché non è necessario utilizzare l'archiviazione, essendo molto costosa, quando si può ottenere il saldo dei conti utilizzando `ADDRESS BALANCE`. Il primo opcode effettua il push dell'indirizzo del contratto. Il secondo legge l'indirizzo in cima allo stack e lo sostituisce con il saldo di quell'indirizzo.
+Se osserviamo le modifiche di stato causate da [altre transazioni `Transfer` dello stesso periodo](https://etherscan.io/tx/0xf708d306de39c422472f43cb975d97b66fd5d6a6863db627067167cbf93d84d1#statechange), vediamo che `Storage[6]` ha tracciato il valore del contratto per un po' di tempo. Per ora lo chiameremo `Value*`. L'asterisco (`*`) ci ricorda che non _sappiamo_ ancora cosa faccia questa variabile, ma non può servire solo a tracciare il valore del contratto, poiché non è necessario usare l'archiviazione, che è molto costosa, quando si può ottenere il saldo dei propri conti usando `ADDRESS BALANCE`. Il primo opcode effettua il push dell'indirizzo proprio del contratto. Il secondo legge l'indirizzo in cima allo stack e lo sostituisce con il saldo di quell'indirizzo.
-| Offset | Opcode | Stack |
-| ------:| ------------ | --------------------------------------------- |
-| 6C | PUSH2 0x0075 | 0x75 Value\* CALLVALUE 0 6 CALLVALUE |
-| 6F | SWAP2 | CALLVALUE Value\* 0x75 0 6 CALLVALUE |
-| 70 | SWAP1 | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 71 | PUSH2 0x01a7 | 0x01A7 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 74 | JUMP | |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ------------------------------------------- |
+| 6C | PUSH2 0x0075 | 0x75 Value\* CALLVALUE 0 6 CALLVALUE |
+| 6F | SWAP2 | CALLVALUE Value\* 0x75 0 6 CALLVALUE |
+| 70 | SWAP1 | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 71 | PUSH2 0x01a7 | 0x01A7 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 74 | JUMP | |
Continueremo a monitorare questo codice alla destinazione del salto.
-| Offset | Opcode | Stack |
-| ------:| ---------- | ------------------------------------------------------------- |
-| 1A7 | JUMPDEST | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1A8 | PUSH1 0x00 | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1AA | DUP3 | CALLVALUE 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1AB | NOT | 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| Scostamento | Opcode | Stack |
+| ----------: | ---------- | ----------------------------------------------------------- |
+| 1A7 | JUMPDEST | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1A8 | PUSH1 0x00 | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AA | DUP3 | CALLVALUE 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AB | NOT | 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-Il `NOT` opera su singoli bit, quindi annulla il valore di ogni bit nel valore della chiamata.
+Il `NOT` opera su singoli bit, quindi inverte il valore di ogni bit nel valore della chiamata.
-| Offset | Opcode | Stack |
-| ------:| ------------ | ------------------------------------------------------------------------------- |
-| 1AC | DUP3 | Value\* 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1AD | GT | Value\*>2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1AE | ISZERO | Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1AF | PUSH2 0x01df | 0x01DF Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1B2 | JUMPI | |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ------------------------------------------------------------------------------------------------------ |
+| 1AC | DUP3 | Value\* 2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AD | GT | Value\*>2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AE | ISZERO | Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1AF | PUSH2 0x01df | 0x01DF Value\*\<=2^256-CALLVALUE-1 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1B2 | JUMPI | |
-Saltiamo se `Value*` è inferiore o pari a 2^256-CALLVALUE-1. Questa sembra una logica per prevenire l'overflow. E in effetti vediamo che dopo alcune operazioni senza senso (la scrittura sulla memoria sta per essere eliminata, ad esempio), all'offset 0x01DE il contratto si annulla se viene rilevato l'overflow, il che è comportamento normale.
+Saltiamo se `Value*` è inferiore o pari a 2^256-CALLVALUE-1. Questa sembra una logica per prevenire l'overflow. E in effetti vediamo che dopo alcune operazioni senza senso (la scrittura sulla memoria sta per essere eliminata, ad esempio), all'offset 0x01DE il contratto si annulla se viene rilevato l'overflow, il che è un comportamento normale.
-Nota che l'overflow è estremamente improbabile, perché richiederebbe che il valore della chiamata più `Value*` fosse comparabile a 2^256 wei, circa 10^59 ETH. [La quantità totale di ETH, al momento della scrittura, è inferiore a duecento milioni](https://etherscan.io/stat/supply).
+Nota che un tale overflow è estremamente improbabile, perché richiederebbe che il valore della chiamata più `Value*` fosse comparabile a 2^256 wei, circa 10^59 ETH. [La quantità totale di ETH, al momento della scrittura, è inferiore a duecento milioni](https://etherscan.io/stat/supply).
-| Offset | Opcode | Stack |
-| ------:| -------- | ------------------------------------------- |
-| 1DF | JUMPDEST | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1E0 | POP | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
-| 1E1 | ADD | Value\*+CALLVALUE 0x75 0 6 CALLVALUE |
-| 1E2 | SWAP1 | 0x75 Value\*+CALLVALUE 0 6 CALLVALUE |
-| 1E3 | JUMP | |
+| Scostamento | Opcode | Stack |
+| ----------: | -------- | ----------------------------------------- |
+| 1DF | JUMPDEST | 0x00 Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E0 | POP | Value\* CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E1 | ADD | Value\*+CALLVALUE 0x75 0 6 CALLVALUE |
+| 1E2 | SWAP1 | 0x75 Value\*+CALLVALUE 0 6 CALLVALUE |
+| 1E3 | JUMP | |
Se siamo arrivati qui, ottieni `Value* + CALLVALUE` e salta all'offset 0x75.
-| Offset | Opcode | Stack |
-| ------:| -------- | --------------------------------- |
-| 75 | JUMPDEST | Value\*+CALLVALUE 0 6 CALLVALUE |
-| 76 | SWAP1 | 0 Value\*+CALLVALUE 6 CALLVALUE |
-| 77 | SWAP2 | 6 Value\*+CALLVALUE 0 CALLVALUE |
-| 78 | SSTORE | 0 CALLVALUE |
+| Scostamento | Opcode | Stack |
+| ----------: | -------- | ------------------------------- |
+| 75 | JUMPDEST | Value\*+CALLVALUE 0 6 CALLVALUE |
+| 76 | SWAP1 | 0 Value\*+CALLVALUE 6 CALLVALUE |
+| 77 | SWAP2 | 6 Value\*+CALLVALUE 0 CALLVALUE |
+| 78 | SSTORE | 0 CALLVALUE |
-Se siamo arrivati qui (che richiede che i dati della chiamata siano vuoti), aggiungiamo il valore della chiamata a `Value*`. Ciò è coerente con ciò che diciamo che facciano le transazioni `Transfer`.
+Se arriviamo qui (che richiede che i dati della chiamata siano vuoti), aggiungiamo a `Value*` il valore della chiamata. Ciò è coerente con ciò che diciamo che facciano le transazioni `Transfer`.
-| Offset | Opcode |
-| ------:| ------ |
-| 79 | POP |
-| 7A | POP |
-| 7B | STOP |
+| Scostamento | Opcode |
+| ----------: | ------ |
+| 79 | POP |
+| 7A | POP |
+| 7B | STOP |
-Infine, cancelliamo lo stack (che non è necessario) e segnaliamo che la transazione è andata a buon fine.
+Infine, svuotiamo lo stack (che non è necessario) e segnaliamo la fine della transazione con successo.
-Per riassumere tutto, ecco un diagramma di flusso per il codice iniziale.
+Per riassumere, ecco un diagramma di flusso per il codice iniziale.
-
+
-## Il Gestore a 0x7C {#the-handler-at-0x7c}
+## Il gestore a 0x7C {#the-handler-at-0x7c}
-Volutamente ho omesso di inserire nell'intestazione cosa fa questo gestore. Il punto non è insegnarti come funziona questo contratto specifico, ma come decompilare i contratti. Imparerai cosa faccia come ho fatto io, seguendo il codice.
+Volutamente ho omesso di inserire nell'intestazione cosa fa questo gestore. Il punto non è insegnarti come funziona questo contratto specifico, ma come decompilare i contratti. Imparerai cosa fa nello stesso modo in cui l'ho fatto io: seguendo il codice.
Arriviamo qui da diversi punti:
-- Se ci sono dati della chiamata di 1, 2 o 3 byte (dall'offset 0x63)
+- Se ci sono dati di chiamata di 1, 2 o 3 byte (dall'offset 0x63)
- Se la firma del metodo non è nota (dagli offset 0x42 e 0x5D)
-| Offset | Opcode | Stack |
-| ------:| ------------ | -------------------- |
-| 7C | JUMPDEST | |
-| 7D | PUSH1 0x00 | 0x00 |
-| 7F | PUSH2 0x009d | 0x9D 0x00 |
-| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 |
-| 84 | SLOAD | Storage[3] 0x9D 0x00 |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ------------------------------------------------------------------------ |
+| 7C | JUMPDEST | |
+| 7D | PUSH1 0x00 | 0x00 |
+| 7F | PUSH2 0x009d | 0x9D 0x00 |
+| 82 | PUSH1 0x03 | 0x03 0x9D 0x00 |
+| 84 | SLOAD | Storage[3] 0x9D 0x00 |
-Questa è un'altra cella di memoria; non riuscivo a trovarla in nessuna transazione quindi è più difficile sapere cosa significhi. Il codice seguente lo chiarirà.
+Questa è un'altra cella di archiviazione, che non sono riuscito a trovare in nessuna transazione, quindi è più difficile sapere cosa significhi. Il codice seguente lo chiarirà.
-| Offset | Opcode | Stack |
-| ------:| ------------------------------------------------- | ------------------------------- |
-| 85 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xff....ff Storage[3] 0x9D 0x00 |
-| 9A | AND | Storage[3]-as-address 0x9D 0x00 |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 85 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xff....ff Storage[3] 0x9D 0x00 |
+| 9A | AND | Storage[3]-as-address 0x9D 0x00 |
-Questi opcode troncano il valore che leggiamo da Storage[3] a 160 bit, la lunghezza di un indirizzo di Ethereum.
+Questi opcode troncano il valore che leggiamo da Storage[3] a 160 bit, la lunghezza di un indirizzo Ethereum.
-| Offset | Opcode | Stack |
-| ------:| ------ | ------------------------------- |
-| 9B | SWAP1 | 0x9D Storage[3]-as-address 0x00 |
-| 9C | JUMP | Storage[3]-as-address 0x00 |
+| Scostamento | Opcode | Stack |
+| ----------: | ------ | ----------------------------------------------------------------------------------- |
+| 9B | SWAP1 | 0x9D Storage[3]-as-address 0x00 |
+| 9C | JUMP | Storage[3]-as-address 0x00 |
-Questo salto è superfluo, poiché stiamo andando all'opcode successivo. Questo codice non è tanto efficiente a livello di gas, rispetto a quanto potrebbe.
+Questo salto è superfluo, poiché stiamo andando all'opcode successivo. Questo codice non è efficiente in termini di gas come potrebbe essere.
-| Offset | Opcode | Stack |
-| ------:| ---------- | ------------------------------- |
-| 9D | JUMPDEST | Storage[3]-as-address 0x00 |
-| 9E | SWAP1 | 0x00 Storage[3]-as-address |
-| 9F | POP | Storage[3]-as-address |
-| A0 | PUSH1 0x40 | 0x40 Storage[3]-as-address |
-| A2 | MLOAD | Mem[0x40] Storage[3]-as-address |
+| Scostamento | Opcode | Stack |
+| ----------: | ---------- | --------------------------------------------------------------------------------------------------------------------------------------- |
+| 9D | JUMPDEST | Storage[3]-as-address 0x00 |
+| 9E | SWAP1 | 0x00 Storage[3]-as-address |
+| 9F | POP | Storage[3]-as-address |
+| A0 | PUSH1 0x40 | 0x40 Storage[3]-as-address |
+| A2 | MLOAD | Mem[0x40] Storage[3]-as-address |
-All'inizio del codice, impostiamo Mem[0x40] a 0x80. Se cerchiamo 0x40 in seguito, vediamo che non lo cambiamo, quindi supponiamo che sia 0x80.
+All'inizio del codice, impostiamo Mem[0x40] a 0x80. Se cerchiamo 0x40 in seguito, vediamo che non lo cambiamo, quindi possiamo supporre che sia 0x80.
-| Offset | Opcode | Stack |
-| ------:| ------------ | ------------------------------------------------- |
-| A3 | CALLDATASIZE | CALLDATASIZE 0x80 Storage[3]-as-address |
-| A4 | PUSH1 0x00 | 0x00 CALLDATASIZE 0x80 Storage[3]-as-address |
-| A6 | DUP3 | 0x80 0x00 CALLDATASIZE 0x80 Storage[3]-as-address |
-| A7 | CALLDATACOPY | 0x80 Storage[3]-as-address |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ----------------------------------------------------------------------------------------------------- |
+| A3 | CALLDATASIZE | CALLDATASIZE 0x80 Storage[3]-as-address |
+| A4 | PUSH1 0x00 | 0x00 CALLDATASIZE 0x80 Storage[3]-as-address |
+| A6 | DUP3 | 0x80 0x00 CALLDATASIZE 0x80 Storage[3]-as-address |
+| A7 | CALLDATACOPY | 0x80 Storage[3]-as-address |
Copia tutti i dati della chiamata nella memoria, a partire da 0x80.
-| Offset | Opcode | Stack |
-| ------:| ------------- | -------------------------------------------------------------------------------- |
-| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-as-address |
-| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-as-address |
-| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
-| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
-| AD | DUP6 | Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
-| AE | GAS | GAS Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
-| AF | DELEGATE_CALL | |
+| Scostamento | Opcode | Stack |
+| ----------: | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| A8 | PUSH1 0x00 | 0x00 0x80 Storage[3]-as-address |
+| AA | DUP1 | 0x00 0x00 0x80 Storage[3]-as-address |
+| AB | CALLDATASIZE | CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
+| AC | DUP4 | 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
+| AD | DUP6 | Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
+| AE | GAS | GAS Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address |
+| AF | DELEGATE_CALL | |
-Ora le cose sono molto più chiare. Questo contratto può fungere da [proxy](https://blog.openzeppelin.com/proxy-patterns/), chiamando l'indirizzo in Storage[3] per compiere il vero lavoro. `DELEGATE_CALL` chiama un contratto separato, ma resta nella stessa memoria. Questo significa che il contratto delegato, quello per cui siamo un proxy, accede allo stesso spazio d'archiviazione. I parametri per la chiamata sono:
+Ora le cose sono molto più chiare. Questo contratto può fungere da [proxy](https://blog.openzeppelin.com/proxy-patterns/), chiamando l'indirizzo in Storage[3] per svolgere il vero lavoro. `DELEGATE_CALL` chiama un contratto separato, ma resta nella stessa archiviazione. Questo significa che il contratto delegato, quello per cui siamo un proxy, accede allo stesso spazio di archiviazione. I parametri per la chiamata sono:
- _Gas_: Tutto il gas rimanente
- _Indirizzo chiamato_: Storage[3]-as-address
-- _dati della chiamata_: i byte CALLDATASIZE che iniziano a 0x80, ovvero dove inseriamo i dati di chiamata originali
-- _Dati restituiti_: nessuno (0x00 - 0x00) Otterremo i dati restituiti con altri mezzi (vedi di seguito)
+- _Dati di chiamata_: i byte CALLDATASIZE che iniziano da 0x80, ovvero dove inseriamo i dati di chiamata originali
+- _Dati restituiti_: Nessuno (0x00 - 0x00) Otterremo i dati restituiti con altri mezzi (vedi di seguito)
-| Offset | Opcode | Stack |
-| ------:| -------------- | --------------------------------------------------------------------------------------------- |
-| B0 | RETURNDATASIZE | RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| B1 | DUP1 | RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| B2 | PUSH1 0x00 | 0x00 RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| B4 | DUP5 | 0x80 0x00 RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| B5 | RETURNDATACOPY | RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
+| Scostamento | Opcode | Stack |
+| ----------: | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| B0 | RETURNDATASIZE | RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| B1 | DUP1 | RETURNDATASIZE RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| B2 | PUSH1 0x00 | 0x00 RETURNDATASIZE RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| B4 | DUP5 | 0x80 0x00 RETURNDATASIZE RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| B5 | RETURNDATACOPY | RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
-Qui copiamo tutti i dati restituiti al buffer di memoria partendo a 0x80.
+Qui copiamo tutti i dati restituiti al buffer di memoria partendo da 0x80.
-| Offset | Opcode | Stack |
-| ------:| ------------ | ---------------------------------------------------------------------------------------------------------------------------- |
-| B6 | DUP2 | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| B7 | DUP1 | (((call success/failure))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| B8 | ISZERO | (((did the call fail))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| B9 | PUSH2 0x00c0 | 0xC0 (((did the call fail))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| BC | JUMPI | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| BD | DUP2 | RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| BE | DUP5 | 0x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| BF | RETURN | |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| B6 | DUP2 | (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| B7 | DUP1 | (((successo/fallimento della chiamata))) (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| B8 | ISZERO | (((la chiamata è fallita))) (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| B9 | PUSH2 0x00c0 | 0xC0 (((la chiamata è fallita))) (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| BC | JUMPI | (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| BD | DUP2 | RETURNDATASIZE (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| BE | DUP5 | 0x80 RETURNDATASIZE (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| BF | RETURN | |
-Quindi, dopo la chiamata, copiamo i dati restituiti al buffer 0x80 - 0x80+RETURNDATASIZE, e se la chiamata è andata a buon fine `RETURN` esattamente con quel buffer.
+Quindi, dopo la chiamata, copiamo i dati restituiti al buffer 0x80 - 0x80+RETURNDATASIZE, e se la chiamata va a buon fine eseguiamo `RETURN` con esattamente quel buffer.
-### DELEGATECALL fallita {#delegatecall-failed}
+### DELEGATECALL non riuscito {#delegatecall-failed}
-Se arriviamo qui, a 0xC0, significa che il contratto che abbiamo chiamato è annullato. Poiché siamo solo un proxy per quel contratto, vogliamo restituire gli stessi dati e annullare a nostra volta.
+Se arriviamo qui, a 0xC0, significa che il contratto che abbiamo chiamato è stato annullato. Poiché siamo solo un proxy per quel contratto, vogliamo restituire gli stessi dati e annullare a nostra volta.
-| Offset | Opcode | Stack |
-| ------:| -------- | ------------------------------------------------------------------------------------------------------------------- |
-| C0 | JUMPDEST | (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| C1 | DUP2 | RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| C2 | DUP5 | 0x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address |
-| C3 | REVERT | |
+| Scostamento | Opcode | Stack |
+| ----------: | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| C0 | JUMPDEST | (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| C1 | DUP2 | RETURNDATASIZE (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| C2 | DUP5 | 0x80 RETURNDATASIZE (((successo/fallimento della chiamata))) RETURNDATASIZE (((successo/fallimento della chiamata))) 0x80 Storage[3]-as-address |
+| C3 | REVERT | |
-Quindi noi `REVERT` con lo stesso buffer usato prima per `RETURN`: 0x80 - 0x80+RETURNDATASIZE
+Quindi eseguiamo `REVERT` con lo stesso buffer usato prima per `RETURN`: 0x80 - 0x80+RETURNDATASIZE
-
+
## Chiamate ABI {#abi-calls}
Se la dimensione dei dati della chiamata è di quattro byte o superiore, potrebbe essere una chiamata ABI valida.
-| Offset | Opcode | Stack |
-| ------:| ------------ | ------------------------------------------------- |
-| D | PUSH1 0x00 | 0x00 |
-| F | CALLDATALOAD | (((First word (256 bits) of the call data))) |
-| 10 | PUSH1 0xe0 | 0xE0 (((First word (256 bits) of the call data))) |
-| 12 | SHR | (((first 32 bits (4 bytes) of the call data))) |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ------------------------------------------------------------------------------------------------------------------------------------- |
+| D | PUSH1 0x00 | 0x00 |
+| F | CALLDATALOAD | (((Prima parola (256 bit) dei dati della chiamata))) |
+| 10 | PUSH1 0xe0 | 0xE0 (((Prima parola (256 bit) dei dati della chiamata))) |
+| 12 | SHR | (((primi 32 bit (4 byte) dei dati della chiamata))) |
-Etherscan ci dice che `1C` è un opcode sconosciuto, perché [è stato aggiunto dopo che Etherscan aveva scritto questa funzionalità](https://eips.ethereum.org/EIPS/eip-145) e non l'ha aggiornata. Una [tabella degli opcode aggiornata](https://github.com/wolflo/evm-opcodes) ci indica che questo è lo spostamento a destra
+Etherscan ci dice che `1C` è un opcode sconosciuto, perché [è stato aggiunto dopo che Etherscan ha scritto questa funzionalità](https://eips.ethereum.org/EIPS/eip-145) e non l'hanno aggiornata. Una [tabella opcode aggiornata](https://github.com/wolflo/evm-opcodes) ci mostra che si tratta di uno spostamento a destra.
-| Offset | Opcode | Stack |
-| ------:| ---------------- | -------------------------------------------------------------------------------------------------------- |
-| 13 | DUP1 | (((first 32 bits (4 bytes) of the call data))) (((first 32 bits (4 bytes) of the call data))) |
-| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((first 32 bits (4 bytes) of the call data))) (((first 32 bits (4 bytes) of the call data))) |
-| 19 | GT | 0x3CD8045E>first-32-bits-of-the-call-data (((first 32 bits (4 bytes) of the call data))) |
-| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>first-32-bits-of-the-call-data (((first 32 bits (4 bytes) of the call data))) |
-| 1D | JUMPI | (((first 32 bits (4 bytes) of the call data))) |
+| Scostamento | Opcode | Stack |
+| ----------: | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 13 | DUP1 | (((primi 32 bit (4 byte) dei dati della chiamata))) (((primi 32 bit (4 byte) dei dati della chiamata))) |
+| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((primi 32 bit (4 byte) dei dati della chiamata))) (((primi 32 bit (4 byte) dei dati della chiamata))) |
+| 19 | GT | 0x3CD8045E>primi-32-bit-dei-dati-della-chiamata (((primi 32 bit (4 byte) dei dati della chiamata))) |
+| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>primi-32-bit-dei-dati-della-chiamata (((primi 32 bit (4 byte) dei dati della chiamata))) |
+| 1D | JUMPI | (((primi 32 bit (4 byte) dei dati della chiamata))) |
-Dividere le prove di corrispondenza della firma del metodo in due, in questo modo, permette di risparmiare in media metà delle prove. Il codice che segue immediatamente questo e il codice in 0x43 seguono lo stesso schema: `DUP1` i primi 32 bit dei dati della chiamata, `PUSH4 (((method signature>`, esegui `EQ` per verificare l'uguaglianza e poi `JUMPI` se la firma del metodo corrisponde. Ecco le firme del metodo, i loro indirizzi e, se nota, [la definizione del metodo corrispondente](https://www.4byte.directory/):
+Dividere in due i test di corrispondenza della firma del metodo in questo modo permette di risparmiare in media la metà dei test. Il codice che segue immediatamente questo e il codice in 0x43 seguono lo stesso schema: `DUP1` i primi 32 bit dei dati della chiamata, `PUSH4 (((firma metodo`, esegui `EQ` per verificare l'uguaglianza e poi `JUMPI` se la firma del metodo corrisponde. Ecco le firme del metodo, i loro indirizzi e, se nota, [la definizione del metodo corrispondente](https://www.4byte.directory/):
-| Metodo | Firma del metodo | Offset a cui saltare |
-| -------------------------------------------------------------------------------------- | ---------------- | -------------------- |
+| Metodo | Firma del metodo | Offset a cui saltare |
+| --------------------------------------------------------------------------------------------------------- | ---------------- | -------------------- |
| [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 |
-| ??? | 0x81e580d3 | 0x0138 |
+| ??? | 0x81e580d3 | 0x0138 |
| [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 |
-| ??? | 0x1f135823 | 0x00C4 |
+| ??? | 0x1f135823 | 0x00C4 |
| [merkleRoot()](https://www.4byte.directory/signatures/?bytes4_signature=0x2eb4a7ab) | 0x2eb4a7ab | 0x00ED |
Se non è trovata alcuna corrispondenza, il codice salta al [gestore del proxy a 0x7C](#the-handler-at-0x7c), nella speranza che il contratto per cui siamo un proxy abbia una corrispondenza.
@@ -302,255 +300,255 @@ Se non è trovata alcuna corrispondenza, il codice salta al [gestore del proxy a
## splitter() {#splitter}
-| Offset | Opcode | Stack |
-| ------:| ------------ | ----------------------------- |
-| 103 | JUMPDEST | |
-| 104 | CALLVALUE | CALLVALUE |
-| 105 | DUP1 | CALLVALUE CALLVALUE |
-| 106 | ISZERO | CALLVALUE==0 CALLVALUE |
-| 107 | PUSH2 0x010f | 0x010F CALLVALUE==0 CALLVALUE |
-| 10A | JUMPI | CALLVALUE |
-| 10B | PUSH1 0x00 | 0x00 CALLVALUE |
-| 10D | DUP1 | 0x00 0x00 CALLVALUE |
-| 10E | REVERT | |
-
-La prima cosa che fa questa funzione è controllare che la chiamata non abbia inviato alcun ETH. Questa funzione non è [`pagabile`](https://solidity-by-example.org/payable/). Se qualcuno ci ha invitato degli ETH, deve trattarsi di un errore e vogliamo `REVERT` (RIPRISTINARE) per evitare che tali ETH finiscano per essere irrecuperabili.
-
-| Offset | Opcode | Stack |
-| ------:| ------------------------------------------------- | --------------------------------------------------------------------------- |
-| 10F | JUMPDEST | |
-| 110 | POP | |
-| 111 | PUSH1 0x03 | 0x03 |
-| 113 | SLOAD | (((Storage[3] a.k.a the contract for which we are a proxy))) |
-| 114 | PUSH1 0x40 | 0x40 (((Storage[3] a.k.a the contract for which we are a proxy))) |
-| 116 | MLOAD | 0x80 (((Storage[3] a.k.a the contract for which we are a proxy))) |
-| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] a.k.a the contract for which we are a proxy))) |
-| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] a.k.a the contract for which we are a proxy))) |
-| 12D | SWAP2 | (((Storage[3] a.k.a the contract for which we are a proxy))) 0xFF...FF 0x80 |
-| 12E | AND | ProxyAddr 0x80 |
-| 12F | DUP2 | 0x80 ProxyAddr 0x80 |
-| 130 | MSTORE | 0x80 |
-
-E ora 0x80 contiene l'indirizzo del proxy
-
-| Offset | Opcode | Stack |
-| ------:| ------------ | --------- |
-| 131 | PUSH1 0x20 | 0x20 0x80 |
-| 133 | ADD | 0xA0 |
-| 134 | PUSH2 0x00e4 | 0xE4 0xA0 |
-| 137 | JUMP | 0xA0 |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ----------------------------- |
+| 103 | JUMPDEST | |
+| 104 | CALLVALUE | CALLVALUE |
+| 105 | DUP1 | CALLVALUE CALLVALUE |
+| 106 | ISZERO | CALLVALUE==0 CALLVALUE |
+| 107 | PUSH2 0x010f | 0x010F CALLVALUE==0 CALLVALUE |
+| 10A | JUMPI | CALLVALUE |
+| 10B | PUSH1 0x00 | 0x00 CALLVALUE |
+| 10D | DUP1 | 0x00 0x00 CALLVALUE |
+| 10E | REVERT | |
+
+La prima cosa che fa questa funzione è controllare che la chiamata non abbia inviato alcun ETH. Questa funzione non è [`payable`](https://solidity-by-example.org/payable/). Se qualcuno ci ha inviato ETH, deve trattarsi di un errore e vogliamo usare `REVERT` per evitare che quegli ETH siano irrecuperabili.
+
+| Scostamento | Opcode | Stack |
+| ----------: | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 10F | JUMPDEST | |
+| 110 | POP | |
+| 111 | PUSH1 0x03 | 0x03 |
+| 113 | SLOAD | (((Storage[3] ovvero il contratto per cui siamo un proxy))) |
+| 114 | PUSH1 0x40 | 0x40 (((Storage[3] ovvero il contratto per cui siamo un proxy))) |
+| 116 | MLOAD | 0x80 (((Storage[3] ovvero il contratto per cui siamo un proxy))) |
+| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] ovvero il contratto per cui siamo un proxy))) |
+| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] ovvero il contratto per cui siamo un proxy))) |
+| 12D | SWAP2 | (((Storage[3] ovvero il contratto per cui siamo un proxy))) 0xFF...FF 0x80 |
+| 12E | AND | ProxyAddr 0x80 |
+| 12F | DUP2 | 0x80 ProxyAddr 0x80 |
+| 130 | MSTORE | 0x80 |
+
+E ora 0x80 contiene l'indirizzo del proxy.
+
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | --------- |
+| 131 | PUSH1 0x20 | 0x20 0x80 |
+| 133 | ADD | 0xA0 |
+| 134 | PUSH2 0x00e4 | 0xE4 0xA0 |
+| 137 | JUMP | 0xA0 |
### Il Codice E4 {#the-e4-code}
Questa è la prima volta che vediamo queste righe, ma sono condivise con altri metodi (vedi di seguito). Quindi chiameremo il valore nello stack X e ricorderemo semplicemente che in `splitter()` il valore di questa X è 0xA0.
-| Offset | Opcode | Stack |
-| ------:| ---------- | ----------- |
-| E4 | JUMPDEST | X |
-| E5 | PUSH1 0x40 | 0x40 X |
-| E7 | MLOAD | 0x80 X |
-| E8 | DUP1 | 0x80 0x80 X |
-| E9 | SWAP2 | X 0x80 0x80 |
-| EA | SUB | X-0x80 0x80 |
-| EB | SWAP1 | 0x80 X-0x80 |
-| EC | RETURN | |
+| Scostamento | Opcode | Stack |
+| ----------: | ---------- | ----------- |
+| E4 | JUMPDEST | X |
+| E5 | PUSH1 0x40 | 0x40 X |
+| E7 | MLOAD | 0x80 X |
+| E8 | DUP1 | 0x80 0x80 X |
+| E9 | SWAP2 | X 0x80 0x80 |
+| EA | SUB | X-0x80 0x80 |
+| EB | SWAP1 | 0x80 X-0x80 |
+| EC | RETURN | |
-Quindi questo codice riceve un puntatore di memoria nello stack (X) e fa sì che il contratto dia `RETURN` con un buffer che sia 0x80 - X.
+Quindi questo codice riceve un puntatore di memoria nello stack (X) e fa sì che il contratto esegua `RETURN` con un buffer che sia 0x80 - X.
Nel caso di `splitter()`, ciò restituisce l'indirizzo per cui siamo un proxy. `RETURN` restituisce il buffer in 0x80-0x9F, ovvero dove abbiamo scritto questi dati (offset 0x130 sopra).
## currentWindow() {#currentwindow}
-Il codice negli offset 0x158-0x163 è identico a quello che abbiamo visto in 0x103-0x10E in `splitter()` (diverso dalla destinazione `JUMPI`), quindi sappiamo che neanche `currentWindow()` è `pagabile`.
+Il codice negli offset 0x158-0x163 è identico a quello che abbiamo visto in 0x103-0x10E in `splitter()` (diverso dalla destinazione di `JUMPI`), quindi sappiamo che neanche `currentWindow()` è `payable`.
-| Offset | Opcode | Stack |
-| ------:| ------------ | -------------------- |
-| 164 | JUMPDEST | |
-| 165 | POP | |
-| 166 | PUSH2 0x00da | 0xDA |
-| 169 | PUSH1 0x01 | 0x01 0xDA |
-| 16B | SLOAD | Storage[1] 0xDA |
-| 16C | DUP2 | 0xDA Storage[1] 0xDA |
-| 16D | JUMP | Storage[1] 0xDA |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ------------------------------------------------------------------------ |
+| 164 | JUMPDEST | |
+| 165 | POP | |
+| 166 | PUSH2 0x00da | 0xDA |
+| 169 | PUSH1 0x01 | 0x01 0xDA |
+| 16B | SLOAD | Storage[1] 0xDA |
+| 16C | DUP2 | 0xDA Storage[1] 0xDA |
+| 16D | JUMP | Storage[1] 0xDA |
### Il codice DA {#the-da-code}
Questo codice è condiviso anche con altri metodi. Quindi chiameremo il valore nello stack Y e ricorderemo semplicemente che in `currentWindow()` il valore di questa Y è Storage[1].
-| Offset | Opcode | Stack |
-| ------:| ---------- | ---------------- |
-| DA | JUMPDEST | Y 0xDA |
-| DB | PUSH1 0x40 | 0x40 Y 0xDA |
-| DD | MLOAD | 0x80 Y 0xDA |
-| DE | SWAP1 | Y 0x80 0xDA |
-| DF | DUP2 | 0x80 Y 0x80 0xDA |
-| E0 | MSTORE | 0x80 0xDA |
+| Scostamento | Opcode | Stack |
+| ----------: | ---------- | ---------------- |
+| DA | JUMPDEST | Y 0xDA |
+| DB | PUSH1 0x40 | 0x40 Y 0xDA |
+| DD | MLOAD | 0x80 Y 0xDA |
+| DE | SWAP1 | Y 0x80 0xDA |
+| DF | DUP2 | 0x80 Y 0x80 0xDA |
+| E0 | MSTORE | 0x80 0xDA |
-Scrivi Y a 0x80-0x9F.
+Scrivi Y in 0x80-0x9F.
-| Offset | Opcode | Stack |
-| ------:| ---------- | -------------- |
-| E1 | PUSH1 0x20 | 0x20 0x80 0xDA |
-| E3 | ADD | 0xA0 0xDA |
+| Scostamento | Opcode | Stack |
+| ----------: | ---------- | -------------- |
+| E1 | PUSH1 0x20 | 0x20 0x80 0xDA |
+| E3 | ADD | 0xA0 0xDA |
-E il resto è già spiegato [sopra](#the-e4-code). Quindi salta a 0xDA, scrive la cima dello stack (Y) a 0x80-0x9F e restituisce quel valore. Nel caso di `currentWindow()`, restituisce Storage[1].
+E il resto è già spiegato [sopra](#the-e4-code). Quindi i salti a 0xDA scrivono la cima dello stack (Y) in 0x80-0x9F e restituiscono quel valore. Nel caso di `currentWindow()`, restituisce Storage[1].
## merkleRoot() {#merkleroot}
-Il codice negli offset 0xED-0xF8 è identico a quello che abbiamo visto in 0x103-0x10E in `splitter()` (diverso dalla destinazione `JUMPI`), quindi sappiamo che neanche `merkleRoot()` è `pagabile`.
+Il codice negli offset 0xED-0xF8 è identico a quello che abbiamo visto in 0x103-0x10E in `splitter()` (diverso dalla destinazione di `JUMPI`), quindi sappiamo che neanche `merkleRoot()` è `payable`.
-| Offset | Opcode | Stack |
-| ------:| ------------ | -------------------- |
-| F9 | JUMPDEST | |
-| FA | POP | |
-| FB | PUSH2 0x00da | 0xDA |
-| FE | PUSH1 0x00 | 0x00 0xDA |
-| 100 | SLOAD | Storage[0] 0xDA |
-| 101 | DUP2 | 0xDA Storage[0] 0xDA |
-| 102 | JUMP | Storage[0] 0xDA |
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ------------------------------------------------------------------------ |
+| F9 | JUMPDEST | |
+| FA | POP | |
+| FB | PUSH2 0x00da | 0xDA |
+| FE | PUSH1 0x00 | 0x00 0xDA |
+| 100 | SLOAD | Storage[0] 0xDA |
+| 101 | DUP2 | 0xDA Storage[0] 0xDA |
+| 102 | JUMP | Storage[0] 0xDA |
-Cosa succede dopo il salto, [lo abbiamo già capito](#the-da-code). Quindi `merkleRoot()` restituisce Storage[0].
+Cosa succede dopo il salto [lo abbiamo già capito](#the-da-code). Quindi `merkleRoot()` restituisce Storage[0].
## 0x81e580d3 {#0x81e580d3}
-Il codice negli offset 0x138-0x143 è identico a quello che abbiamo visto in 0x103-0x10E in `splitter()` (diverso dalla destinazione `JUMPI`), quindi sappiamo che neanche questa funzione è `pagabile`.
-
-| Offset | Opcode | Stack |
-| ------:| ------------ | ------------------------------------------------------------ |
-| 144 | JUMPDEST | |
-| 145 | POP | |
-| 146 | PUSH2 0x00da | 0xDA |
-| 149 | PUSH2 0x0153 | 0x0153 0xDA |
-| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA |
-| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA |
-| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA |
-| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA |
-| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA |
-| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 197 | SLT | CALLDATASIZE-4\<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+Il codice negli offset 0x138-0x143 è identico a quello che abbiamo visto in 0x103-0x10E in `splitter()` (diverso dalla destinazione di `JUMPI`), quindi sappiamo che neanche questa funzione è `payable`.
+
+| Scostamento | Opcode | Stack |
+| ----------: | ------------ | ------------------------------------------------------------------------------- |
+| 144 | JUMPDEST | |
+| 145 | POP | |
+| 146 | PUSH2 0x00da | 0xDA |
+| 149 | PUSH2 0x0153 | 0x0153 0xDA |
+| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA |
+| 14D | PUSH1 0x04 | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 14F | PUSH2 0x018f | 0x018F 0x04 CALLDATASIZE 0x0153 0xDA |
+| 152 | JUMP | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 18F | JUMPDEST | 0x04 CALLDATASIZE 0x0153 0xDA |
+| 190 | PUSH1 0x00 | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 192 | PUSH1 0x20 | 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 194 | DUP3 | 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 195 | DUP5 | CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 196 | SUB | CALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 197 | SLT | CALLDATASIZE-4\<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 198 | ISZERO | CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 199 | PUSH2 0x01a0 | 0x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
+| 19C | JUMPI | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
Sembra che questa funzione richieda almeno 32 byte (una parola) di dati della chiamata.
-| Offset | Opcode | Stack |
-| ------:| ------ | -------------------------------------------- |
-| 19D | DUP1 | 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 19E | DUP2 | 0x00 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 19F | REVERT | |
-
-Se non ottiene i dati della chiamata, la transazione è annullata senza alcun dato restituito.
-
-Vediamo cosa succede se la funzione _ottiene_ i dati della chiamata che necessita.
-
-| Offset | Opcode | Stack |
-| ------:| ------------ | ---------------------------------------- |
-| 1A0 | JUMPDEST | 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 1A1 | POP | 0x04 CALLDATASIZE 0x0153 0xDA |
-| 1A2 | CALLDATALOAD | calldataload(4) CALLDATASIZE 0x0153 0xDA |
-
-`calldataload(4)` è la prima parola della dei dati della chiamata _dopo_ la firma del metodo
-
-| Offset | Opcode | Stack |
-| ------:| ------------ | ---------------------------------------------------------------------------- |
-| 1A3 | SWAP2 | 0x0153 CALLDATASIZE calldataload(4) 0xDA |
-| 1A4 | SWAP1 | CALLDATASIZE 0x0153 calldataload(4) 0xDA |
-| 1A5 | POP | 0x0153 calldataload(4) 0xDA |
-| 1A6 | JUMP | calldataload(4) 0xDA |
-| 153 | JUMPDEST | calldataload(4) 0xDA |
-| 154 | PUSH2 0x016e | 0x016E calldataload(4) 0xDA |
-| 157 | JUMP | calldataload(4) 0xDA |
-| 16E | JUMPDEST | calldataload(4) 0xDA |
-| 16F | PUSH1 0x04 | 0x04 calldataload(4) 0xDA |
-| 171 | DUP2 | calldataload(4) 0x04 calldataload(4) 0xDA |
-| 172 | DUP2 | 0x04 calldataload(4) 0x04 calldataload(4) 0xDA |
-| 173 | SLOAD | Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA |
-| 174 | DUP2 | calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA |
-| 175 | LT | calldataload(4)\)` e un altro è `isClaimed()`, quindi sembra un contratto airdrop. Invece di analizzare il resto opcode per opcode, possiamo [provare il decompilatore](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761), che produce risultati utilizzabili per tre funzioni da questo contratto. La decompilazione degli altri viene lasciato come esercizio per il lettore.
+Uno dei metodi rimanenti è `claim()` e un altro è `isClaimed()`, quindi sembra un contratto di airdrop. Invece di analizzare il resto opcode per opcode, possiamo [provare il decompilatore](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761), che produce risultati utilizzabili per tre funzioni da questo contratto. La decompilazione degli altri è lasciata come esercizio per il lettore.
### scaleAmountByPercentage {#scaleamountbypercentage}
@@ -592,15 +590,15 @@ def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:
return (_param1 * _param2 / 100 * 10^6)
```
-Il primo `require` testa che i dati della chiamata abbiano, oltre ai quattro byte della firma della funzione, almeno 64 byte. abbastanza per i due parametri. Altrimenti c'è ovviamente qualcosa di sbagliato.
+Il primo `require` verifica che i dati della chiamata abbiano, oltre ai quattro byte della firma della funzione, almeno 64 byte, abbastanza per i due parametri. Altrimenti c'è ovviamente qualcosa di sbagliato.
-L'istruzione `if` sembra verificare che `_param1` non sia zero e che `_param1 * _param2` non sia negativo. Probabilmente serve a impedire casi di avvolgimento.
+L'istruzione `if` sembra verificare che `_param1` non sia zero e che `_param1 * _param2` non sia negativo. Probabilmente serve a impedire casi di wrap-around.
Infine, la funzione restituisce un valore in scala.
### claim {#claim}
-Il codice creato dal decompilatore è complesso, e non tutto è rilevante per noi. Ne salterò una parte per concentrarci sulle righe che ritengo forniscano informazioni utili
+Il codice creato dal decompilatore è complesso e non tutto è rilevante per noi. Ne salterò una parte per concentrarmi sulle righe che ritengo forniscano informazioni utili.
```python
def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
@@ -608,21 +606,21 @@ def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _pa
require _param2 == addr(_param2)
...
if currentWindow <= _param1:
- revert with 0, 'cannot claim for a future window'
+ revert with 0, 'impossibile rivendicare per una finestra futura'
```
Qui vediamo due cose importanti:
-- `_param2`, sebbene sia dichiarato come `uint256`, è in realtà un indirizzo
+- `_param2`, sebbene sia dichiarato come un `uint256`, è in realtà un indirizzo
- `_param1` è la finestra rivendicata, che dev'essere `currentWindow` o precedente.
```python
...
if stor5[_claimWindow][addr(_claimFor)]:
- revert with 0, 'Account already claimed the given window'
+ revert with 0, 'Il conto ha già rivendicato la finestra data'
```
-Quindi ora sappiamo che Storage[5] è un array di finestre e indirizzi, e se l'indirizzo ha rivendicato la ricompensa per quella finestra.
+Quindi ora sappiamo che Storage[5] è un array di finestre e indirizzi e se l'indirizzo ha rivendicato la ricompensa per quella finestra.
```python
...
@@ -639,7 +637,7 @@ Quindi ora sappiamo che Storage[5] è un array di finestre e indirizzi, e se l'i
s = sha3(mem[_66 + 32 len mem[_66]])
continue
if unknown2eb4a7ab != s:
- revert with 0, 'Invalid proof'
+ revert with 0, 'Prova non valida'
```
Sappiamo che `unknown2eb4a7ab` è in realtà la funzione `merkleRoot()`, quindi sembra che questo codice stia verificando una [prova di Merkle](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5). Ciò significa che `_param4` è una prova di Merkle.
@@ -650,7 +648,7 @@ Sappiamo che `unknown2eb4a7ab` è in realtà la funzione `merkleRoot()`, quindi
gas 30000 wei
```
-Ecco come un contratto trasferisce i propri ETH a un altro indirizzo (contratto o posseduto esternamente). Lo chiama con un valore che è l'importo da trasferire. Quindi sembra che questo sia un airdrop di ETH.
+Ecco come un contratto trasferisce i propri ETH a un altro indirizzo (un contratto o posseduto esternamente). Lo chiama con un valore che è l'importo da trasferire. Quindi sembra che questo sia un airdrop di ETH.
```python
if not return_data.size:
@@ -660,22 +658,21 @@ Ecco come un contratto trasferisce i propri ETH a un altro indirizzo (contratto
value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
```
-Le ultime due righe ci dicono che anche Storage[2] è un contratto che chiamiamo. Se [guardiamo la transazione del costruttore](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange), vediamo che questo contratto è [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), un contratto Wrapped Ether [il cui codice sorgente è stato caricato in Etherscan](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code).
+Le ultime due righe ci dicono che anche Storage[2] è un contratto che chiamiamo. Se [esaminiamo la transazione del costruttore](https://etherscan.io/tx/0xa1ea0549fb349eb7d3aff90e1d6ce7469fdfdcd59a2fd9b8d1f5e420c0d05b58#statechange) vediamo che questo contratto è [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), un contratto di Wrapped Ether [il cui codice sorgente è stato caricato su Etherscan](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2#code).
-Quindi sembra che i contratti tentino di inviare ETH a `_param2`. Se riescono a farlo, ottimo. Altrimenti, tentano di inviare [WETH](https://weth.io/). Se `_param2` è un conto posseduto esternamente (EOA), allora può sempre ricevere ETH, ma i contratti possono rifiutarsi di ricevere ETH. Tuttavia, WETH è ERC-20 e i contratti non possono rifiutarsi di accettarlo.
+Quindi sembra che i contratti tentino di inviare ETH a `_param2`. Se ci riescono, ottimo. In caso contrario, tenta di inviare [WETH](https://weth.tkn.eth.limo/). Se `_param2` è un conto di proprietà esterna (EOA), può sempre ricevere ETH, ma i contratti possono rifiutarsi di riceverli. Tuttavia, WETH è un ERC-20 e i contratti non possono rifiutarsi di accettarlo.
```python
- ...
- log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success)
+ ...log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success)
```
-Alla fine della funzione vediamo che viene generata una voce del registro. [Guarda le voci del registro generate](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events) e filtra l'argomento che inizia per `0xdbd5...`. Se [clicchiamo su una delle transazioni che hanno generato tale voce](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274), vediamo che sembra indubbiamente una rivendicazione: il conto ha inviato un messaggio al contratto che stiamo decompilando e, in cambio, ha ricevuto degli ETH.
+Alla fine della funzione vediamo che viene generata una voce del registro. [Guarda le voci del registro generate](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events) e filtra per l'argomento che inizia con `0xdbd5...`. Se [facciamo clic su una delle transazioni che hanno generato tale voce](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274), vediamo che sembra indubbiamente una rivendicazione: il conto ha inviato un messaggio al contratto che stiamo decompilando e, in cambio, ha ricevuto ETH.
### 1e7df9d3 {#1e7df9d3}
-Questa funzione è molto simile alla suddetta [`claim`](#claim). Verifica anche una prova di Merkle, tenta di trasferire ETH al primo e produce lo stesso tipo di voce del registro.
+Questa funzione è molto simile alla [`claim`](#claim) di cui sopra. Verifica anche una prova di Merkle, tenta di trasferire ETH al primo e produce lo stesso tipo di voce del registro.
```python
def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
@@ -693,7 +690,7 @@ def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
...
if unknown2eb4a7ab != s:
- revert with 0, 'Invalid proof'
+ revert with 0, 'Prova non valida'
...
call addr(_param1) with:
value s wei
@@ -708,7 +705,7 @@ def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)
```
-La differenza principale è che il primo parametro, la finestra per prelevare, non c'è. Invece, c'è un ciclo su tutte le finestre rivendicabili.
+La differenza principale è che il primo parametro, la finestra da cui prelevare, non c'è. Invece, c'è un ciclo su tutte le finestre rivendicabili.
```python
idx = 0
@@ -741,4 +738,6 @@ Quindi, sembra una variante di `claim` che rivendica tutte le finestre.
## Conclusione {#conclusion}
-A questo punto dovresti sapere come comprendere i contratti il cui codice sorgente non è disponibile usando gli opcode o (quando funziona) il decompilatore. Come è evidente dalla lunghezza di questo articolo, decompilare un contratto non è banale, ma in un sistema in cui la sicurezza è essenziale, poter verificare che i contratti operino come promesso è un'abilità importante.
+A questo punto dovresti sapere come comprendere i contratti il cui codice sorgente non è disponibile usando gli opcode o (quando funziona) il decompilatore. Come è evidente dalla lunghezza di questo articolo, la decompilazione di un contratto non è banale, ma in un sistema in cui la sicurezza è essenziale, poter verificare che i contratti funzionino come promesso è un'abilità importante.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
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..fd02f06abfa 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
@@ -1,135 +1,137 @@
---
-title: Come trasformare un Raspberry Pi 4 in un nodo eseguendo il flashing della scheda MicroSD
+title: Esegui un nodo Ethereum su Raspberry Pi 4
description: Esegui il flashing del Raspberry Pi 4, collega un cavo Ethernet, collega il disco SSD e accendi il dispositivo per trasformare Raspberry Pi 4 in un nodo completo di Ethereum + validatore
author: "EthereumOnArm"
tags:
- - "client"
- - "livello di esecuzione"
- - "livello di consenso"
- - "nodi"
+ [
+ "client",
+ "livello di esecuzione",
+ "livello di consenso",
+ "nodi"
+ ]
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/
---
-**Ethereum on Arm è un'immagine Linux personalizzata che può trasformare un Raspberry Pi in un nodo di Ethereum.**
+**Ethereum on Arm è un'immagine Linux personalizzata che può trasformare un Raspberry Pi in un nodo Ethereum.**
-Per usare Ethereum on Arm per trasformare un Raspberry Pi in un nodo di Ethereum, si consiglia il seguente hardware:
+Per usare Ethereum on Arm per trasformare un Raspberry Pi in un nodo Ethereum, si consiglia il seguente hardware:
-- Raspberry 4 (modello B 8 GB), scheda Odroid M1 o Rock 5B (8 GB/16 GB RAM)
-- Scheda MicroSD (almeno 16 GB Classe 10)
-- SSD da minimo 2 TB, disco USB 3.0 o una SSD con un case USB a SATA.
+- Scheda Raspberry 4 (modello B 8GB), Odroid M1 o Rock 5B (8GB/16GB RAM)
+- Scheda MicroSD (minimo 16 GB Classe 10)
+- SSD da minimo 2 TB, disco USB 3.0 o una SSD con un case da USB a SATA.
- Alimentatore
-- Cavo Ethernet
-- Port forwarding (vedi i client per maggiori informazioni)
+- Cavo ethernet
+- Inoltro della porta (vedi client per maggiori informazioni)
- Un case con dissipatore di calore e ventola
-- Tastiera USB, monitor e cavo HDMI (micro-HDMI) (opzionale)
+- Tastiera USB, monitor e cavo HDMI (micro-HDMI) (facoltativo)
-## Perché eseguire Ethereum on ARM? {#why-run-ethereum-on-arm}
+## Perché eseguire Ethereum su ARM? {#why-run-ethereum-on-arm}
-Le schede ARM sono computer molto convenienti, flessibili e di dimensioni ridotte. Sono una buona scelta per eseguire i nodi di Ethereum perché sono economiche, possono essere configurate in modo che tutte le risorse si concentrino solo sul nodo, il che le rende efficienti, consumano quantità minime di energia e sono fisicamente piccole così da occupare poco spazio in qualsiasi casa. Inoltre è molto facile avviare i nodi perché il flashing della MicroSD del Raspberry Pi può essere eseguito in modo semplice con un'immagine pre-costruita, senza necessità di scaricare o creare software.
+Le schede ARM sono computer molto convenienti, flessibili e di dimensioni ridotte. Sono un'ottima scelta per l'esecuzione di nodi Ethereum perché sono economiche, possono essere configurate in modo che tutte le loro risorse si concentrino solo sul nodo, rendendole efficienti, consumano poca energia e sono fisicamente piccole, quindi possono essere collocate con discrezione in qualsiasi casa. È anche molto facile avviare i nodi, perché è possibile eseguire semplicemente il flash della MicroSD del Raspberry Pi con un'immagine precompilata, senza bisogno di scaricare o creare alcun software.
## Come funziona? {#how-does-it-work}
-Il flashing della scheda di memoria del Raspberry Pi è eseguito con un'immagine pre-costruita che contiene tutto il necessario per eseguire un nodo di Ethereum. Con una scheda su cui è stato eseguito il flashing, tutto ciò che l'utente deve fare è accendere il Raspberry Pi. Tutti i processi necessari per eseguire il nodo sono avviati automaticamente. Questo funziona perché la scheda di memoria contiene un sistema operativo (OS) basato su Linux su cui i processi a livello di sistema sono eseguiti automaticamente, trasformando l'unità in un nodo di Ethereum.
+Sulla scheda di memoria del Raspberry Pi viene eseguito il flash di un'immagine precompilata. Questa immagine contiene tutto il necessario per eseguire un nodo Ethereum. Con una scheda su cui è stato eseguito il flash, tutto ciò che l'utente deve fare è accendere il Raspberry Pi. Tutti i processi necessari per l'esecuzione del nodo vengono avviati automaticamente. Questo funziona perché la scheda di memoria contiene un sistema operativo basato su Linux (OS) su cui vengono eseguiti automaticamente i processi a livello di sistema che trasformano l'unità in un nodo Ethereum.
-Ethereum non è eseguibile usando il popolare OS Linux per Raspberry Pi "Raspbian" poiché questo usa ancora un'architettura a 32 bit che causa agli utenti di Ethereum problemi di memoria, e i client di consenso non supportano i binari a 32 bit. Per superare ciò, il team di Ethereum on Arm è migrato a un OS a 64 bit nativo chiamato "Armbian".
+Ethereum non può essere eseguito utilizzando il popolare sistema operativo Linux per Raspberry Pi "Raspbian" perché Raspbian utilizza ancora un'architettura a 32 bit, che causa problemi di memoria agli utenti di Ethereum, e i client di consenso non supportano i file binari a 32 bit. Per ovviare a questo problema, il team di Ethereum on Arm è passato a un sistema operativo nativo a 64 bit chiamato "Armbian".
-**Le immagini comprendono tutti i passaggi necessari**, dalla configurazione dell'ambiente, alla formattazione del disco SSD, dall'installazione ed esecuzione del software Ethereum fino all'avvio della sincronizzazione della blockchain.
+**Le immagini si occupano di tutti i passaggi necessari**, dalla configurazione dell'ambiente e dalla formattazione del disco SSD, all'installazione e all'esecuzione del software di Ethereum, fino all'avvio della sincronizzazione della blockchain.
## Nota sui client di esecuzione e di consenso {#note-on-execution-and-consensus-clients}
-L'immagine Ethereum su Arm include l'esecuzione precostruita e client di consenso come servizi. Un nodo Ethereum richiede che entrambi i client siano sincronizzati ed in esecuzione. È necessario solo scaricare e copiare l'immagine e quindi avviare i servizi. L'immagine è precaricata con i seguenti client di esecuzione:
+L'immagine di Ethereum on Arm include client di esecuzione e di consenso precompilati come servizi. Un nodo Ethereum richiede che entrambi i client siano sincronizzati e in esecuzione. Devi solo scaricare l'immagine, eseguirne il flash e quindi avviare i servizi. L'immagine è precaricata con i seguenti client di esecuzione:
- Geth
- Nethermind
- Besu
-e i seguenti clienti di consenso:
+e i seguenti client di consenso:
- Lighthouse
- Nimbus
- Prysm
- Teku
-È necessario scegliere uno di ciascun gruppo da eseguire - tutti i client di esecuzione sono compatibili con tutti i client di consenso. Se non si seleziona esplicitamente un client, il nodo tornerà ai suoi valori predefiniti - Geth e Lighthouse - e li eseguirà automaticamente quando la scheda è accesa. È necessario aprire la porta 30303 sul router in modo che Geth possa trovare e connettersi ai pari.
+Dovresti sceglierne uno per ciascun tipo da eseguire: tutti i client di esecuzione sono compatibili con tutti i client di consenso. Se non selezioni esplicitamente un client, il nodo tornerà ai suoi valori predefiniti, Geth e Lighthouse, e li eseguirà automaticamente all'accensione della scheda. Devi aprire la porta 30303 sul tuo router in modo che Geth possa trovare i peer e connettersi a essi.
-## Download immagine {#downloading-the-image}
+## Download dell'immagine {#downloading-the-image}
-L'immagine Raspberry Pi 4 Ethereum è un'immagine "plug and play" che installa e imposta automaticamente sia i client di esecuzione che di consenso, configurarli per farli comunicare tra loro e connettersi alla rete Ethereum. Tutto ciò che l'utente deve fare è avviarne i processi usando un semplice comando.
+L'immagine Ethereum per Raspberry Pi 4 è un'immagine "plug and play" che installa e configura automaticamente sia il client di esecuzione sia quello di consenso, impostandoli in modo che comunichino tra loro e si connettano alla rete di Ethereum. Tutto ciò che l'utente deve fare è avviare i processi utilizzando un semplice comando.
-Scarica l'immagine di Raspberry Pi da [Ethereum on Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/ES56R_SuvaVFkiMO1Tgnf6kB7lEbBfla5c2c18E3WQRJzA?download=1) e verifica l'hash SHA256:
+Scarica l'immagine per Raspberry Pi da [Ethereum on Arm](https://ethereumonarm-my.sharepoint.com/:u:/p/dlosada/Ec_VmUvr80VFjf3RYSU-NzkBmj2JOteDECj8Bibde929Gw?download=1) e verifica l'hash SHA256:
```sh
-# From directory containing the downloaded image
+# Dalla directory contenente l'immagine scaricata
shasum -a 256 ethonarm_22.04.00.img.zip
-# Hash should output: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f
+# L'output dell'hash dovrebbe essere: fb497e8f8a7388b62d6e1efbc406b9558bee7ef46ec7e53083630029c117444f
```
-Nota che le immagini per le schede Rock 5B e Odroid M1 sono disponibili alla [pagina di download](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/download-and-install.html) di Ethereum-su-Arm.
+Si noti che le immagini per le schede Rock 5B e Odroid M1 sono disponibili nella [pagina dei download](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/quick-guide/download-and-install.html) di Ethereum-on-Arm.
-## Flashing della MicroSD {#flashing-the-microsd}
+## Flash della MicroSD {#flashing-the-microsd}
-La scheda MicroSD che sarà usata per il Raspberry Pi dovrebbe innanzitutto essere inserita in un computer desktop o portatile, così da eseguirne la copia. Poi, i seguenti comandi del terminale eseguiranno la copia dell'immagine scaricata sulla scheda SD:
+La scheda MicroSD che userai per il Raspberry Pi deve essere prima inserita in un computer desktop o portatile per poterne eseguire il flash. Successivamente, i seguenti comandi da terminale eseguiranno il flash dell'immagine scaricata sulla scheda SD:
```shell
-# check the MicroSD card name
+# controlla il nome della scheda MicroSD
sudo fdisk -l
>> sdxxx
```
-È davvero importante inserire il nome corretto, perché il prossimo comando include `dd`, che cancella completamente i contenuti esistenti della scheda prima di caricarvi l'immagine. Per continuare, naviga fino alla cartella contenente l'immagine compressa:
+È davvero importante inserire il nome corretto, perché il comando successivo include `dd`, che cancella completamente il contenuto esistente della scheda prima di copiarvi l'immagine. Per continuare, naviga fino alla directory contenente l'immagine zippata:
```shell
-# unzip and flash image
+# decomprimi ed esegui il flash dell'immagine
unzip ethonarm_22.04.00.img.zip
sudo dd bs=1M if=ethonarm_22.04.00.img of=/dev/ conv=fdatasync status=progress
```
-Dopo aver eseguito la copia, la scheda può essere inserita nel Raspberry Pi.
+Ora che sulla scheda è stato eseguito il flash, puoi inserirla nel Raspberry Pi.
## Avviare il nodo {#start-the-node}
Con la scheda SD inserita nel Raspberry Pi, connetti il cavo Ethernet e la SSD, poi accendilo. Il sistema operativo si avvierà e avvierà automaticamente l'esecuzione delle attività preconfigurate che trasformeranno il Raspberry Pi in un nodo Ethereum, compresa l'installazione e la creazione del software client. Ciò richiederà probabilmente da 10 a 15 minuti.
-Una volta che tutto è installato e configurato, accedi al dispositivo tramite una connessione ssh o usando il terminale direttamente se alla scheda sono collegati uno schermo e una tastiera. Usa l'account `ethereum` per accedere, in quanto ha i permessi necessari per avviare il nodo.
+Una volta installato e configurato tutto, accedi al dispositivo tramite una connessione ssh o usando il terminale direttamente se alla scheda sono collegati un monitor e una tastiera. Usa l'account `ethereum` per accedere, in quanto ha i permessi necessari per avviare il nodo.
```shell
-User: ethereum
+Utente: ethereum
Password: ethereum
```
-Il client di esecuzione predefinito, Geth, verrà avviato automaticamente. È possibile confermarlo controllando i registri utilizzando il seguente comando terminale:
+Il client di esecuzione predefinito, Geth, si avvierà automaticamente. Puoi confermarlo controllando i log tramite il seguente comando da terminale:
```sh
sudo journalctl -u geth -f
```
-Il client di consenso deve essere avviato esplicitamente. Per fare questo, prima aprire la porta 9000 sul router in modo che Lighthouse possa trovare e connettersi ai pari. Quindi abilitare e avviare il servizio lighthouse:
+Il client di consenso deve essere avviato esplicitamente. Per farlo, apri prima la porta 9000 sul tuo router in modo che Lighthouse possa trovare e connettersi ai peer. Quindi abilita e avvia il servizio lighthouse:
```sh
sudo systemctl enable lighthouse-beacon
sudo systemctl start lighthouse-beacon
```
-Controllare il client utilizzando i registri:
+Controlla il client utilizzando i log:
```sh
sudo journalctl -u lighthouse-beacon
```
-Si noti che il client di consenso si sincronizzerà in pochi minuti perché utilizza la sincronizzazione dei checkpoint. Il client di esecuzione richiederà più tempo, potenzialmente diverse ore, e si avvierà quando il client di consenso avrà già terminato la sincronizzazione (questo perché il client di esecuzione ha bisogno di un obiettivo per la sincronizzazione fornito dal client di consenso).
+Si noti che il client di consenso si sincronizzerà in pochi minuti perché utilizza la sincronizzazione da checkpoint. Il client di esecuzione richiederà più tempo, potenzialmente diverse ore, e non si avvierà finché il client di consenso non avrà terminato la sincronizzazione (questo perché il client di esecuzione ha bisogno di un obiettivo a cui sincronizzarsi, che viene fornito dal client di consenso sincronizzato).
-Con i servizi Geth e Lighthouse in esecuzione e sincronizzati, il tuo Raspberry Pi è ora un nodo Ethereum! È più comune interagire con la rete Ethereum utilizzando la console Javascript di Geth, che può essere collegata al client Geth sulla porta 8545. È anche possibile inviare comandi formattati come oggetti JSON utilizzando uno strumento di richiesta come Curl. Maggiori informazioni nella [documentazione di Geth](https://geth.ethereum.org/).
+Con i servizi Geth e Lighthouse in esecuzione e sincronizzati, il tuo Raspberry Pi è ora un nodo Ethereum! Il modo più comune per interagire con la rete di Ethereum è usare la console Javascript di Geth, che può essere collegata al client di Geth sulla porta 8545. È anche possibile inviare comandi formattati come oggetti JSON utilizzando uno strumento di richiesta come Curl. Ulteriori informazioni nella [documentazione di Geth](https://geth.ethereum.org/).
-Geth è preconfigurato per segnalare le metriche a un pannello Grafana che può essere visualizzato nel browser. Gli utenti più avanzati potrebbero voler utilizzare questa funzione per monitorare lo stato di salute del loro nodo accedendo a `ipaddress:3000` con nome `utente: admin` e `passwd: ethereum`.
+Geth è preconfigurato per inviare le metriche a una dashboard di Grafana, che può essere visualizzata nel browser. Gli utenti più avanzati potrebbero voler utilizzare questa funzione per monitorare lo stato di salute del proprio nodo accedendo a `ipaddress:3000`, e inserendo `user: admin` e `passwd: ethereum`.
## Validatori {#validators}
-Un validatore può anche essere aggiunto facoltativamente al client di consenso. Il software validatore consente al nodo di partecipare attivamente al consenso e fornisce alla rete sicurezza criptoeconomica. Per questo lavoro in ETH si viene ricompensati. Per poter eseguire un validatore, devi prima avere accesso a 32 ETH, che devono essere depositati nel contratto di deposito. **Questo è un impegno a lungo termine - non è ancora possibile ritirare questi ETH!**. Questo deposito può essere eseguito seguendo la guida passo-passo sul [Launchpad](https://launchpad.ethereum.org/). Fallo su un computer desktop/portatile, ma non generare chiavi - questo puoi farlo direttamente sul Raspberry Pi.
+È anche possibile aggiungere facoltativamente un validatore al client di consenso. Il software del validatore permette al tuo nodo di partecipare attivamente al consenso e fornisce sicurezza crittoeconomica alla rete. Per questo lavoro, sarai ricompensato in ETH. Per eseguire un validatore, devi prima possedere 32 ETH, che devono essere depositati nel contratto di deposito. Il deposito può essere effettuato seguendo la guida dettagliata sul [Launchpad](https://launchpad.ethereum.org/). Esegui questa operazione su un computer desktop/portatile, ma non generare le chiavi: puoi farlo direttamente sul Raspberry Pi.
Apri un terminale sul Raspberry Pi ed esegui il seguente comando per generare le chiavi di deposito:
@@ -139,32 +141,35 @@ sudo apt-get install staking-deposit-cli
cd && deposit new-mnemonic --num_validators 1
```
-Mantieni al sicuro la frase mnemonica! Il suddetto comando ha generato due file nel keystore del nodo: le chiavi del validatore e un file dei dati di deposito. I dati di deposito devono essere caricati nel launchpad, quindi devono esser copiati dal Raspberry Pi nel PC/portatile. Questo si può fare usando una connessione ssh o qualsiasi altro metodo copia/incolla.
+(In alternativa, scarica [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) per eseguirlo su una macchina air-gapped ed esegui il comando `deposit new-mnemnonic`)
-Una volta che il file dei dati di deposito è disponibile sul computer che esegue il launchpad, può essere selezionato e trascinato sul `+` nella schermata del launchpad. Segui le istruzioni sullo schermo per inviare una transazione al contratto di deposito.
+Conserva la frase mnemonica in un posto sicuro! Il comando precedente ha generato due file nel keystore del nodo: le chiavi del validatore e un file di dati di deposito. I dati di deposito devono essere caricati nel launchpad, quindi devono essere copiati dal Raspberry Pi al desktop/laptop. Puoi farlo usando una connessione ssh o qualsiasi altro metodo di copia e incolla.
-Tornando al Raspberry Pi, può essere avviato un validatore. Ciò richiede l'importazione delle chiavi del validatore, l'impostazione dell'indirizzo per incassare le ricompense e successivamente l'avvio del processo pre-configurato del validatore. Gli esempi seguenti sono per Lighthouse, le istruzioni per gli altri client di consenso sono disponibili nella [documentazione di Ethereum su Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/):
+Una volta che il file dei dati di deposito è disponibile sul computer che esegue il Launchpad, può essere trascinato e rilasciato sul `+` nella schermata del Launchpad. Segui le istruzioni sullo schermo per inviare una transazione al contratto di deposito.
+
+Tornando al Raspberry Pi, può essere avviato un validatore. Ciò richiede l'importazione delle chiavi del validatore, l'impostazione dell'indirizzo per riscuotere le ricompense e quindi l'avvio della procedura preconfigurata del validatore. L'esempio seguente è per Lighthouse; le istruzioni per altri client di consenso sono disponibili nella [documentazione di Ethereum on Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/):
```shell
-# import the validator keys
+# importa le chiavi del validatore
lighthouse account validator import --directory=/home/ethereum/validator_keys
-# set the reward address
+# imposta l'indirizzo della ricompensa
sudo sed -i 's/' /etc/ethereum/lighthouse-validator.conf
-# start the validator
+# avvia il validatore
sudo systemctl start lighthouse-validator
```
-Congratulazioni, hai ora un nodo di Ethereum completo e un validatore in esecuzione su un Raspberry Pi!
+Congratulazioni, ora hai un nodo Ethereum completo e un validatore in esecuzione su un Raspberry Pi!
-## Maggiori dettagli {#more-details}
+## Ulteriori dettagli {#more-details}
-Questa pagina ha fornito una panoramica di come configurare un nodo Geth-Lighthouse e validatore utilizzando Raspberry Pi. Istruzioni più dettagliate sono disponibili sul sito web [Ethereum-su-Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/index.html).
+Questa pagina ha fornito una panoramica su come configurare un nodo e un validatore Geth-Lighthouse utilizzando un Raspberry Pi. Istruzioni più dettagliate sono disponibili sul [sito web di Ethereum-on-Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/index.html).
-## Ogni feedback è benvenuto {#feedback-appreciated}
+## Il feedback è gradito {#feedback-appreciated}
-Sappiamo che Raspberry Pi ha un'enorme base di utenti che potrebbe avere un impatto molto positivo sulla salute della rete di Ethereum. Sei pregato di approfondire i dettagli in questo tutorial, provare a eseguirlo su altre reti di prova, dare un'occhiata al GitHub di Ethereum su Arm, fornire feedback, creare ticket e richieste di pull e aiutare a far progredire la tecnologia e la documentazione!
+Sappiamo che il Raspberry Pi ha un'enorme base di utenti che potrebbe avere un impatto molto positivo sulla salute della rete di Ethereum.
+Approfondisci i dettagli di questa guida, prova a eseguire su reti di prova, consulta il GitHub di Ethereum on Arm, fornisci feedback, segnala problemi e invia pull request per contribuire al progresso della tecnologia e della documentazione!
## Riferimenti {#references}
diff --git a/public/content/translations/it/developers/tutorials/scam-token-tricks/index.md b/public/content/translations/it/developers/tutorials/scam-token-tricks/index.md
new file mode 100644
index 00000000000..7138f072a99
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/scam-token-tricks/index.md
@@ -0,0 +1,470 @@
+---
+title: "Alcuni trucchi usati dai token truffa e come individuarli"
+description: In questa guida analizziamo un token truffa per vedere alcuni dei trucchi usati dai truffatori, come li implementano e come possiamo individuarli.
+author: Ori Pomerantz
+tags:
+ [
+ "truffa",
+ "solidity",
+ "erc-20",
+ "javascript",
+ "typescript"
+ ]
+skill: intermediate
+published: 2023-09-15
+lang: it
+---
+
+In questa guida analizziamo [un token truffa](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) per vedere alcuni dei trucchi usati dai truffatori e come li implementano. Alla fine della guida avrai una visione più completa dei contratti dei token ERC-20, delle loro funzionalità e del perché lo scetticismo è necessario. Successivamente, esamineremo gli eventi emessi da quel token truffa e vedremo come possiamo identificare automaticamente che non è legittimo.
+
+## Token truffa: cosa sono, perché le persone li creano e come evitarli {#scam-tokens}
+
+Uno degli utilizzi più comuni di Ethereum è quello di permettere a un gruppo di persone di creare un token scambiabile, che potremmo definire la loro valuta. Tuttavia, ovunque ci siano casi d'uso legittimi che apportano valore, ci sono anche criminali che cercano di accaparrarsi quel valore.
+
+Puoi leggere di più su questo argomento [altrove su ethereum.org](/guides/how-to-id-scam-tokens/) dal punto di vista di un utente. Questa guida si concentra sull'analisi di un token truffa per vedere come viene creato e come può essere individuato.
+
+### Come faccio a sapere che wARB è una truffa? {#warb-scam}
+
+Il token che analizziamo è [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code), che finge di essere equivalente al [token ARB](https://etherscan.io/token/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1) legittimo.
+
+Il modo più semplice per sapere qual è il token legittimo è guardare l'organizzazione di origine, [Arbitrum](https://arbitrum.foundation/). Gli indirizzi legittimi sono specificati [nella loro documentazione](https://docs.arbitrum.foundation/deployment-addresses#token).
+
+### Perché il codice sorgente è disponibile? {#why-source}
+
+Normalmente ci aspetteremmo che le persone che cercano di truffare gli altri siano riservate, e in effetti molti token truffa non hanno il loro codice disponibile (ad esempio, [questo](https://optimistic.etherscan.io/token/0x15992f382d8c46d667b10dc8456dc36651af1452#code) e [questo](https://optimistic.etherscan.io/token/0x026b623eb4aada7de37ef25256854f9235207178#code)).
+
+Tuttavia, i token legittimi di solito pubblicano il loro codice sorgente, quindi per apparire legittimi, a volte anche gli autori dei token truffa fanno lo stesso. [wARB](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) è uno di quei token con codice sorgente disponibile, il che ne rende più facile la comprensione.
+
+Mentre i deployer di contratti possono scegliere se pubblicare o meno il codice sorgente, essi _non possono_ pubblicare il codice sorgente sbagliato. L'esploratore di blocchi compila in modo indipendente il codice sorgente fornito e, se non ottiene lo stesso identico bytecode, rifiuta quel codice sorgente. [Puoi leggere di più a riguardo sul sito di Etherscan](https://etherscan.io/verifyContract).
+
+## Confronto con i token ERC-20 legittimi {#compare-legit-erc20}
+
+Confronteremo questo token con i token ERC-20 legittimi. Se non hai familiarità con il modo in cui i token ERC-20 legittimi vengono solitamente scritti, [consulta questa guida](/developers/tutorials/erc20-annotated-code/).
+
+### Costanti per indirizzi privilegiati {#constants-for-privileged-addresses}
+
+I contratti a volte necessitano di indirizzi privilegiati. I contratti progettati per un uso a lungo termine consentono ad alcuni indirizzi privilegiati di modificare tali indirizzi, ad esempio per consentire l'uso di un nuovo contratto multisig. Ci sono diversi modi per farlo.
+
+Il [contratto del token `HOP`](https://etherscan.io/address/0xc5102fe9359fd9a28f877a67e36b0f050d81a3cc#code) usa il modello [`Ownable`](https://docs.openzeppelin.com/contracts/2.x/access-control#ownership-and-ownable). L'indirizzo privilegiato è conservato nell'archiviazione, in un campo chiamato `_owner` (vedi il terzo file, `Ownable.sol`).
+
+```solidity
+abstract contract Ownable is Context {
+ address private _owner;
+ .
+ .
+ .
+}
+```
+
+Il [contratto del token `ARB`](https://etherscan.io/address/0xad0c361ef902a7d9851ca7dcc85535da2d3c6fc7#code) non ha direttamente un indirizzo privilegiato. Tuttavia, non ne ha bisogno. Si trova dietro un [`proxy`](https://docs.openzeppelin.com/contracts/5.x/api/proxy) all'[indirizzo `0xb50721bcf8d664c30412cfbc6cf7a15145234ad1`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1#code). Quel contratto ha un indirizzo privilegiato (vedi il quarto file, `ERC1967Upgrade.sol`) che può essere usato per gli aggiornamenti.
+
+```solidity
+ /**
+ * @dev Memorizza un nuovo indirizzo nello slot admin di EIP1967.
+ */
+ function _setAdmin(address newAdmin) private {
+ require(newAdmin != address(0), "ERC1967: il nuovo amministratore è l'indirizzo zero");
+ StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin;
+ }
+```
+
+Al contrario, il contratto `wARB` ha un `contract_owner` codificato in modo fisso.
+
+```solidity
+contract WrappedArbitrum is Context, IERC20 {
+ .
+ .
+ .
+ address deployer = 0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1;
+ address public contract_owner = 0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33;
+ .
+ .
+ .
+}
+```
+
+[Il proprietario di questo contratto](https://etherscan.io/address/0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33) non è un contratto che potrebbe essere controllato da conti diversi in momenti diversi, ma un [conto di proprietà esterna](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs). Ciò significa che è probabilmente progettato per un uso a breve termine da parte di un individuo, piuttosto che come soluzione a lungo termine per controllare un ERC-20 che manterrà il suo valore.
+
+E infatti, se guardiamo su Etherscan, vediamo che il truffatore ha usato questo contratto solo per 12 ore (dalla [prima transazione](https://etherscan.io/tx/0xf49136198c3f925fcb401870a669d43cecb537bde36eb8b41df77f06d5f6fbc2) all'[ultima transazione](https://etherscan.io/tx/0xdfd6e717157354e64bbd5d6adf16761e5a5b3f914b1948d3545d39633244d47b)) il 19 maggio 2023.
+
+### La funzione `_transfer` fittizia {#the-fake-transfer-function}
+
+È prassi standard che i trasferimenti effettivi avvengano utilizzando [una funzione interna `_transfer`](/developers/tutorials/erc20-annotated-code/#the-_transfer-function-_transfer).
+
+In `wARB` questa funzione sembra quasi legittima:
+
+```solidity
+ function _transfer(address sender, address recipient, uint256 amount) internal virtual{
+ require(sender != address(0), "ERC20: trasferimento dall'indirizzo zero");
+ require(recipient != address(0), "ERC20: trasferimento all'indirizzo zero");
+
+ _beforeTokenTransfer(sender, recipient, amount);
+
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: l'importo del trasferimento supera il saldo");
+ _balances[recipient] = _balances[recipient].add(amount);
+ if (sender == contract_owner){
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+La parte sospetta è:
+
+```solidity
+ if (sender == contract_owner){
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+```
+
+Se il proprietario del contratto invia token, perché l'evento `Transfer` mostra che provengono da `deployer`?
+
+Tuttavia, c'è un problema più importante. Chi chiama questa funzione `_transfer`? Non può essere chiamata dall'esterno, è contrassegnata come `internal`. E il codice che abbiamo non include alcuna chiamata a `_transfer`. Chiaramente, è qui come un'esca.
+
+```solidity
+ function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
+ _f_(_msgSender(), recipient, amount);
+ return true;
+ }
+
+ function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
+ _f_(sender, recipient, amount);
+ _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: l'importo del trasferimento supera la disponibilità"));
+ return true;
+ }
+```
+
+Quando guardiamo le funzioni chiamate per trasferire i token, `transfer` e `transferFrom`, vediamo che chiamano una funzione completamente diversa, `_f_`.
+
+### La vera funzione `_f_` {#the-real-f-function}
+
+```solidity
+ function _f_(address sender, address recipient, uint256 amount) internal _mod_(sender,recipient,amount) virtual {
+ require(sender != address(0), "ERC20: trasferimento dall'indirizzo zero");
+ require(recipient != address(0), "ERC20: trasferimento all'indirizzo zero");
+
+ _beforeTokenTransfer(sender, recipient, amount);
+
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: l'importo del trasferimento supera il saldo");
+ _balances[recipient] = _balances[recipient].add(amount);
+ if (sender == contract_owner){
+
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+In questa funzione ci sono due potenziali campanelli d'allarme.
+
+- L'uso del [modificatore di funzione](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `_mod_`. Tuttavia, quando esaminiamo il codice sorgente, vediamo che `_mod_` è in realtà innocuo.
+
+ ```solidity
+ modifier _mod_(address sender, address recipient, uint256 amount){
+ _;
+ }
+ ```
+
+- Lo stesso problema che abbiamo visto in `_transfer`, ovvero quando `contract_owner` invia token, sembrano provenire da `deployer`.
+
+### La funzione di eventi fittizia `dropNewTokens` {#the-fake-events-function-dropNewTokens}
+
+Ora arriviamo a qualcosa che sembra una vera e propria truffa. Ho modificato un po' la funzione per renderla più leggibile, ma è funzionalmente equivalente.
+
+```solidity
+function dropNewTokens(address uPool,
+ address[] memory eReceiver,
+ uint256[] memory eAmounts) public auth()
+```
+
+Questa funzione ha il modificatore `auth()`, il che significa che può essere chiamata solo dal proprietario del contratto.
+
+```solidity
+modifier auth() {
+ require(msg.sender == contract_owner, "Non autorizzato a interagire");
+ _;
+}
+```
+
+Questa restrizione ha perfettamente senso, perché non vorremmo che conti casuali distribuissero token. Tuttavia, il resto della funzione è sospetto.
+
+```solidity
+{
+ for (uint256 i = 0; i < eReceiver.length; i++) {
+ emit Transfer(uPool, eReceiver[i], eAmounts[i]);
+ }
+}
+```
+
+Una funzione per trasferire da un conto di un gruppo a un array di destinatari un array di importi ha perfettamente senso. Ci sono molti casi d'uso in cui si desidera distribuire token da un'unica fonte a più destinazioni, come buste paga, airdrop, ecc. È più economico (in gas) farlo in un'unica transazione invece di emettere più transazioni, o anche chiamare l'ERC-20 più volte da un contratto diverso come parte della stessa transazione.
+
+Tuttavia, `dropNewTokens` non fa questo. Emette [eventi `Transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer-1), ma in realtà non trasferisce alcun token. Non c'è alcun motivo legittimo per confondere le applicazioni fuori dalla catena comunicando loro un trasferimento che in realtà non è avvenuto.
+
+### La funzione `Approve` che brucia {#the-burning-approve-function}
+
+I contratti ERC-20 dovrebbero avere [una funzione `approve`](/developers/tutorials/erc20-annotated-code/#approve) per le disponibilità, e in effetti il nostro token truffa ha una funzione del genere, ed è persino corretta. Tuttavia, poiché Solidity discende da C, è sensibile alle maiuscole e minuscole. `Approve` e `approve` sono stringhe diverse.
+
+Inoltre, la funzionalità non è correlata a `approve`.
+
+```solidity
+ function Approve(
+ address[] memory holders)
+```
+
+Questa funzione è chiamata con un array di indirizzi per i detentori del token.
+
+```solidity
+ public approver() {
+```
+
+Il modificatore `approver()` assicura che solo `contract_owner` possa chiamare questa funzione (vedi sotto).
+
+```solidity
+ for (uint256 i = 0; i < holders.length; i++) {
+ uint256 amount = _balances[holders[i]];
+ _beforeTokenTransfer(holders[i], 0x0000000000000000000000000000000000000001, amount);
+ _balances[holders[i]] = _balances[holders[i]].sub(amount,
+ "ERC20: l'importo da bruciare supera il saldo");
+ _balances[0x0000000000000000000000000000000000000001] =
+ _balances[0x0000000000000000000000000000000000000001].add(amount);
+ }
+ }
+
+```
+
+Per ogni indirizzo di un detentore, la funzione sposta l'intero saldo del detentore all'indirizzo `0x00...01`, di fatto bruciandolo (l'effettivo `burn` nello standard modifica anche la fornitura totale e trasferisce i token a `0x00...00`). Ciò significa che `contract_owner` può rimuovere gli asset di qualsiasi utente. Non sembra una funzionalità che vorresti in un token di governance.
+
+### Problemi di qualità del codice {#code-quality-issues}
+
+Questi problemi di qualità del codice non _provano_ che questo codice sia una truffa, ma lo fanno apparire sospetto. Le aziende organizzate come Arbitrum di solito non rilasciano codice di così scarsa qualità.
+
+#### La funzione `mount` {#the-mount-function}
+
+Sebbene non sia specificato nello [standard](https://eips.ethereum.org/EIPS/eip-20), in generale la funzione che crea nuovi token si chiama [`mint`](https://ethereum.org/el/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn).
+
+Se guardiamo nel costruttore di `wARB`, vediamo che la funzione di mint è stata rinominata in `mount` per qualche motivo, e viene chiamata cinque volte con un quinto della fornitura iniziale, invece di una volta sola per l'intero importo per efficienza.
+
+```solidity
+ constructor () public {
+
+ _name = "Wrapped Arbitrum";
+ _symbol = "wARB";
+ _decimals = 18;
+ uint256 initialSupply = 1000000000000;
+
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ mount(deployer, initialSupply*(10**18)/5);
+ }
+```
+
+Anche la funzione `mount` stessa è sospetta.
+
+```solidity
+ function mount(address account, uint256 amount) public {
+ require(msg.sender == contract_owner, "ERC20: conio per l'indirizzo zero");
+```
+
+Guardando il `require`, vediamo che solo il proprietario del contratto è autorizzato a coniare. Questo è legittimo. Ma il messaggio di errore dovrebbe essere _solo il proprietario è autorizzato a coniare_ o qualcosa del genere. Invece, è l'irrilevante _ERC20: conio per l'indirizzo zero_. Il test corretto per il conio all'indirizzo zero è `require(conto != indirizzo(0), "")`, che il contratto non si preoccupa mai di controllare.
+
+```solidity
+ _totalSupply = _totalSupply.add(amount);
+ _balances[contract_owner] = _balances[contract_owner].add(amount);
+ emit Transfer(address(0), account, amount);
+ }
+```
+
+Ci sono altri due fatti sospetti, direttamente correlati al conio:
+
+- C'è un parametro `conto`, che è presumibilmente il conto che dovrebbe ricevere l'importo coniato. Ma il saldo che aumenta è in realtà quello di `contract_owner`.
+
+- Mentre l'aumento del saldo appartiene a `contract_owner`, l'evento emesso mostra un trasferimento al `conto`.
+
+### Perché sia `auth` che `approver`? Perché il `mod` che non fa nulla? {#why-both-autho-and-approver-why-the-mod-that-does-nothing}
+
+Questo contratto contiene tre modificatori: `_mod_`, `auth` e `approver`.
+
+```solidity
+ modifier _mod_(address sender, address recipient, uint256 amount){
+ _;
+ }
+```
+
+`_mod_` accetta tre parametri e non ne fa nulla. Perché averlo?
+
+```solidity
+ modifier auth() {
+ require(msg.sender == contract_owner, "Non autorizzato a interagire");
+ _;
+ }
+
+ modifier approver() {
+ require(msg.sender == contract_owner, "Non autorizzato a interagire");
+ _;
+ }
+```
+
+`auth` e `approver` hanno più senso, perché controllano che il contratto sia stato chiamato da `contract_owner`. Ci aspetteremmo che alcune azioni privilegiate, come il conio, fossero limitate a quel conto. Tuttavia, che senso ha avere due funzioni separate che fanno _esattamente la stessa cosa_?
+
+## Cosa possiamo rilevare automaticamente? {#what-can-we-detect-automatically}
+
+Possiamo vedere che `wARB` è un token truffa guardando Etherscan. Tuttavia, questa è una soluzione centralizzata. In teoria, Etherscan potrebbe essere sovvertito o violato. È meglio essere in grado di capire autonomamente se un token è legittimo o meno.
+
+Ci sono alcuni trucchi che possiamo usare per identificare che un token ERC-20 è sospetto (o una truffa o scritto molto male), guardando gli eventi che emettono.
+
+## Eventi `Approval` sospetti {#suspicious-approval-events}
+
+[Gli eventi `Approval`](https://eips.ethereum.org/EIPS/eip-20#approval) dovrebbero verificarsi solo con una richiesta diretta (a differenza degli [eventi `Transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer-1) che possono verificarsi come risultato di una disponibilità). [Consulta la documentazione di Solidity](https://docs.soliditylang.org/en/v0.8.20/security-considerations.html#tx-origin) per una spiegazione dettagliata di questo problema e del perché le richieste devono essere dirette, piuttosto che mediate da un contratto.
+
+Ciò significa che gli eventi `Approval` che approvano la spesa da un [conto di proprietà esterna](/developers/docs/accounts/#types-of-account) devono provenire da transazioni che hanno origine in quel conto e la cui destinazione è il contratto ERC-20. Qualsiasi altro tipo di approvazione da un conto di proprietà esterna è sospetto.
+
+Ecco [un programma che identifica questo tipo di evento](https://github.com/qbzzt/20230915-scam-token-detection), utilizzando [viem](https://viem.sh/) e [TypeScript](https://www.typescriptlang.org/docs/), una variante di JavaScript con sicurezza dei tipi. Per eseguirlo:
+
+1. Copia `.env.example` in `.env`.
+2. Modifica `.env` per fornire l'URL di un nodo della Rete Principale di Ethereum.
+3. Esegui `pnpm install` per installare i pacchetti necessari.
+4. Esegui `pnpm susApproval` per cercare le approvazioni sospette.
+
+Ecco una spiegazione riga per riga:
+
+```typescript
+import {
+ Address,
+ TransactionReceipt,
+ createPublicClient,
+ http,
+ parseAbiItem,
+} from "viem"
+import { mainnet } from "viem/chains"
+```
+
+Importa le definizioni dei tipi, le funzioni e la definizione della catena da `viem`.
+
+```typescript
+import { config } from "dotenv"
+config()
+```
+
+Leggi `.env` per ottenere l'URL.
+
+```typescript
+const client = createPublicClient({
+ chain: mainnet,
+ transport: http(process.env.URL),
+})
+```
+
+Crea un client Viem. Dobbiamo solo leggere dalla blockchain, quindi questo client non ha bisogno di una chiave privata.
+
+```typescript
+const testedAddress = "0xb047c8032b99841713b8e3872f06cf32beb27b82"
+const fromBlock = 16859812n
+const toBlock = 16873372n
+```
+
+L'indirizzo del contratto ERC-20 sospetto e i blocchi entro cui cercheremo gli eventi. I provider di nodi in genere limitano la nostra capacità di leggere gli eventi perché la larghezza di banda può diventare costosa. Fortunatamente `wARB` non è stato utilizzato per un periodo di diciotto ore, quindi possiamo cercare tutti gli eventi (ce n'erano solo 13 in totale).
+
+```typescript
+const approvalEvents = await client.getLogs({
+ address: testedAddress,
+ fromBlock,
+ toBlock,
+ event: parseAbiItem(
+ "event Approval(address indexed _owner, address indexed _spender, uint256 _value)"
+ ),
+})
+```
+
+Questo è il modo per chiedere a Viem informazioni sugli eventi. Quando gli forniamo l'esatta firma dell'evento, inclusi i nomi dei campi, analizza l'evento per noi.
+
+```typescript
+const isContract = async (addr: Address): boolean =>
+ await client.getBytecode({ address: addr })
+```
+
+Il nostro algoritmo è applicabile solo ai conti di proprietà esterna. Se c'è un bytecode restituito da `client.getBytecode`, significa che si tratta di un contratto e dovremmo semplicemente saltarlo.
+
+Se non hai mai usato TypeScript prima, la definizione della funzione potrebbe sembrare un po' strana. Non gli diciamo solo che il primo (e unico) parametro si chiama `addr`, ma anche che è di tipo `Address`. Allo stesso modo, la parte `: boolean` dice a TypeScript che il valore di ritorno della funzione è un booleano.
+
+```typescript
+const getEventTxn = async (ev: Event): TransactionReceipt =>
+ await client.getTransactionReceipt({ hash: ev.transactionHash })
+```
+
+Questa funzione ottiene la ricevuta della transazione da un evento. Abbiamo bisogno della ricevuta per essere sicuri di sapere qual era la destinazione della transazione.
+
+```typescript
+const suspiciousApprovalEvent = async (ev : Event) : (Event | null) => {
+```
+
+Questa è la funzione più importante, quella che decide effettivamente se un evento è sospetto o meno. Il tipo di ritorno, `(Event | null)`, dice a TypeScript che questa funzione può restituire un `Event` o `null`. Restituiamo `null` se l'evento non è sospetto.
+
+```typescript
+const owner = ev.args._owner
+```
+
+Viem ha i nomi dei campi, quindi ha analizzato l'evento per noi. `_owner` è il proprietario dei token da spendere.
+
+```typescript
+// Le approvazioni da parte dei contratti non sono sospette
+if (await isContract(owner)) return null
+```
+
+Se il proprietario è un contratto, si presume che questa approvazione non sia sospetta. Per verificare se l'approvazione di un contratto è sospetta o meno, dovremo tracciare l'intera esecuzione della transazione per vedere se è mai arrivata al contratto del proprietario e se quel contratto ha chiamato direttamente il contratto ERC-20. Questo richiede molte più risorse di quelle che vorremmo usare.
+
+```typescript
+const txn = await getEventTxn(ev)
+```
+
+Se l'approvazione proviene da un conto di proprietà esterna, ottieni la transazione che l'ha causata.
+
+```typescript
+// L'approvazione è sospetta se proviene da un proprietario di EOA che non è il `from` della transazione
+if (owner.toLowerCase() != txn.from.toLowerCase()) return ev
+```
+
+Non possiamo semplicemente verificare l'uguaglianza delle stringhe perché gli indirizzi sono esadecimali, quindi contengono lettere. A volte, ad esempio in `txn.from`, queste lettere sono tutte minuscole. In altri casi, come `ev.args._owner`, l'indirizzo è in [maiuscole e minuscole per l'identificazione degli errori](https://eips.ethereum.org/EIPS/eip-55).
+
+Ma se la transazione non proviene dal proprietario, e quel proprietario è di proprietà esterna, allora abbiamo una transazione sospetta.
+
+```typescript
+// È anche sospetto se la destinazione della transazione non è il contratto ERC-20 che stiamo
+// indagando
+if (txn.to.toLowerCase() != testedAddress) return ev
+```
+
+Allo stesso modo, se l'indirizzo `to` della transazione, il primo contratto chiamato, non è il contratto ERC-20 sotto indagine, allora è sospetto.
+
+```typescript
+ // Se non c'è motivo di sospettare, restituisci null.
+ return null
+}
+```
+
+Se nessuna delle due condizioni è vera, l'evento `Approval` non è sospetto.
+
+```typescript
+const testPromises = approvalEvents.map((ev) => suspiciousApprovalEvent(ev))
+const testResults = (await Promise.all(testPromises)).filter((x) => x != null)
+
+console.log(testResults)
+```
+
+Una funzione `async` restituisce un oggetto `Promise`. Con la sintassi comune, `await x()`, aspettiamo che quella `Promise` sia soddisfatta prima di continuare l'elaborazione. Questo è semplice da programmare e seguire, ma è anche inefficiente. Mentre aspettiamo che la `Promise` per un evento specifico venga soddisfatta, possiamo già iniziare a lavorare sull'evento successivo.
+
+Qui usiamo [`map`](https://www.w3schools.com/jsref/jsref_map.asp) per creare un array di oggetti `Promise`. Poi usiamo [`Promise.all`](https://www.javascripttutorial.net/es6/javascript-promise-all/) per aspettare che tutte quelle promesse vengano risolte. Quindi [`filtriamo`](https://www.w3schools.com/jsref/jsref_filter.asp) quei risultati per rimuovere gli eventi non sospetti.
+
+### Eventi `Transfer` sospetti {#suspicious-transfer-events}
+
+Un altro modo possibile per identificare i token truffa è vedere se hanno trasferimenti sospetti. Ad esempio, trasferimenti da conti che non hanno così tanti token. Puoi vedere [come implementare questo test](https://github.com/qbzzt/20230915-scam-token-detection/blob/main/susTransfer.ts), ma `wARB` non ha questo problema.
+
+## Conclusione {#conclusion}
+
+Il rilevamento automatico delle truffe ERC-20 soffre di [falsi negativi](https://en.wikipedia.org/wiki/False_positives_and_false_negatives#False_negative_error), perché una truffa può utilizzare un contratto di token ERC-20 perfettamente normale che semplicemente non rappresenta nulla di reale. Quindi dovresti sempre tentare di _ottenere l'indirizzo del token da una fonte attendibile_.
+
+Il rilevamento automatico può aiutare in alcuni casi, come nei pezzi DeFi, dove ci sono molti token e devono essere gestiti automaticamente. Ma come sempre [caveat emptor](https://www.investopedia.com/terms/c/caveatemptor.asp), fai le tue ricerche e incoraggia i tuoi utenti a fare lo stesso.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
diff --git a/public/content/translations/it/developers/tutorials/secret-state/index.md b/public/content/translations/it/developers/tutorials/secret-state/index.md
new file mode 100644
index 00000000000..68bd750e663
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/secret-state/index.md
@@ -0,0 +1,741 @@
+---
+title: Utilizzo della conoscenza-zero per uno stato segreto
+description: "I giochi on-chain sono limitati perché non possono conservare alcuna informazione nascosta. Dopo aver letto questa guida, il lettore sarà in grado di combinare prove a conoscenza-zero e componenti server per creare giochi verificabili con uno stato segreto, componente off-chain. La tecnica per farlo sarà dimostrata creando un gioco di campo minato."
+author: Ori Pomerantz
+tags:
+ [
+ "server",
+ "offchain",
+ "centralizzato",
+ "conoscenza-zero",
+ "zokrates",
+ "mud"
+ ]
+skill: advanced
+lang: it
+published: 2025-03-15
+---
+
+_Non ci sono segreti sulla blockchain_. Tutto ciò che viene pubblicato sulla blockchain è aperto alla lettura da parte di tutti. Questo è necessario, perché la blockchain si basa sulla capacità di chiunque di verificarla. Tuttavia, i giochi si basano spesso su uno stato segreto. Ad esempio, il gioco del [campo minato](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) non ha assolutamente senso se si può semplicemente andare su un esploratore di blockchain e vedere la mappa.
+
+La soluzione più semplice è utilizzare un [componente server](/developers/tutorials/server-components/) per conservare lo stato segreto. Tuttavia, il motivo per cui utilizziamo la blockchain è per impedire che lo sviluppatore del gioco possa barare. Dobbiamo garantire l'onestà del componente server. Il server può fornire un hash dello stato e utilizzare [prove a conoscenza-zero](/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important) per dimostrare che lo stato utilizzato per calcolare il risultato di una mossa è quello corretto.
+
+Dopo aver letto questo articolo saprai come creare questo tipo di server che conserva uno stato segreto, un client per mostrare lo stato e un componente on-chain per la comunicazione tra i due. Gli strumenti principali che utilizzeremo saranno:
+
+| Strumento | Scopo | Verificato sulla versione |
+| --------------------------------------------- | ---------------------------------------------------------------- | --------------------------------------: |
+| [Zokrates](https://zokrates.github.io/) | Prove a conoscenza-zero e loro verifica | 1.1.9 |
+| [Typescript](https://www.typescriptlang.org/) | Linguaggio di programmazione sia per il server che per il client | 5.4.2 |
+| [Node](https://nodejs.org/en) | Esecuzione del server | 20.18.2 |
+| [Viem](https://viem.sh/) | Comunicazione con la blockchain | 2.9.20 |
+| [MUD](https://mud.dev/) | Gestione dei dati on-chain | 2.0.12 |
+| [React](https://react.dev/) | Interfaccia utente del client | 18.2.0 |
+| [Vite](https://vitejs.dev/) | Erogazione del codice client | 4.2.1 |
+
+## Esempio di Campo Minato {#minesweeper}
+
+[Campo Minato](https://en.wikipedia.org/wiki/Minesweeper_\(video_game\)) è un gioco che include una mappa segreta con un campo minato. Il giocatore sceglie di scavare in una posizione specifica. Se in quella posizione c'è una mina, il gioco finisce. Altrimenti, il giocatore ottiene il numero di mine nelle otto caselle che circondano quella posizione.
+
+Questa applicazione è scritta utilizzando [MUD](https://mud.dev/), un framework che ci consente di archiviare dati on-chain utilizzando un [database chiave-valore](https://aws.amazon.com/nosql/key-value/) e sincronizzare tali dati automaticamente con i componenti off-chain. Oltre alla sincronizzazione, MUD facilita il controllo degli accessi e consente ad altri utenti di [estendere](https://mud.dev/guides/extending-a-world) la nostra applicazione senza autorizzazione.
+
+### Esecuzione dell'esempio di Campo Minato {#running-minesweeper-example}
+
+Per eseguire l'esempio di Campo Minato:
+
+1. Assicurati di [aver installato i prerequisiti](https://mud.dev/quickstart#prerequisites): [Node](https://mud.dev/quickstart#prerequisites), [Foundry](https://book.getfoundry.sh/getting-started/installation), [`git`](https://git-scm.com/downloads), [`pnpm`](https://git-scm.com/downloads) e [`mprocs`](https://github.com/pvolok/mprocs).
+
+2. Clona il repository.
+
+ ```sh copy
+ git clone https://github.com/qbzzt/20240901-secret-state.git
+ ```
+
+3. Installa i pacchetti.
+
+ ```sh copy
+ cd 20240901-secret-state/
+ pnpm install
+ npm install -g mprocs
+ ```
+
+ Se Foundry è stato installato come parte di `pnpm install`, è necessario riavviare la shell della riga di comando.
+
+4. Compila i contratti
+
+ ```sh copy
+ cd packages/contracts
+ forge build
+ cd ../..
+ ```
+
+5. Avvia il programma (inclusa una blockchain [anvil](https://book.getfoundry.sh/anvil/)) e attendi.
+
+ ```sh copy
+ mprocs
+ ```
+
+ Nota che l'avvio richiede molto tempo. Per vedere i progressi, utilizza prima la freccia giù per scorrere fino alla scheda _contracts_ per vedere il deploy dei contratti MUD. Quando ricevi il messaggio _Waiting for file changes…_, i contratti sono distribuiti e ulteriori progressi avverranno nella scheda _server_. Lì, attendi fino a quando non ricevi il messaggio _Verifier address: 0x...._.
+
+ Se questo passaggio ha esito positivo, vedrai la schermata `mprocs`, con i diversi processi a sinistra e l'output della console per il processo attualmente selezionato a destra.
+
+ 
+
+ In caso di problemi con `mprocs`, è possibile eseguire i quattro processi manualmente, ciascuno nella propria finestra della riga di comando:
+
+ - **Anvil**
+
+ ```sh
+ cd packages/contracts
+ anvil --base-fee 0 --block-time 2
+ ```
+
+ - **Contratti**
+
+ ```sh
+ cd packages/contracts
+ pnpm mud dev-contracts --rpc http://127.0.0.1:8545
+ ```
+
+ - **Server**
+
+ ```sh
+ cd packages/server
+ pnpm start
+ ```
+
+ - **Client**
+
+ ```sh
+ cd packages/client
+ pnpm run dev
+ ```
+
+6. Ora puoi navigare fino al [client](http://localhost:3000), fare clic su **New Game** (Nuova partita) e iniziare a giocare.
+
+### Tabelle {#tables}
+
+Abbiamo bisogno di [diverse tabelle](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts) on-chain.
+
+- `Configuration`: questa tabella è un singleton, non ha chiave e un singolo record. È usata per contenere le informazioni di configurazione del gioco:
+ - `height`: l'altezza di un campo minato
+ - `width`: la larghezza di un campo minato
+ - `numberOfBombs`: il numero di bombe in ogni campo minato
+
+- `VerifierAddress`: anche questa tabella è un singleton. Viene utilizzata per contenere una parte della configurazione, l'indirizzo del contratto di verifica (`verifier`). Avremmo potuto inserire queste informazioni nella tabella `Configuration`, ma sono impostate da un componente diverso, il server, quindi è più facile inserirle in una tabella separata.
+
+- `PlayerGame`: la chiave è l'indirizzo del giocatore. I dati sono:
+
+ - `gameId`: valore a 32 byte che è l'hash della mappa su cui il giocatore sta giocando (l'identificatore del gioco).
+ - `win`: un booleano che indica se il giocatore ha vinto la partita.
+ - `lose`: un booleano che indica se il giocatore ha perso la partita.
+ - `digNumber`: il numero di scavi riusciti nel gioco.
+
+- `GamePlayer`: questa tabella contiene la mappatura inversa, da `gameId` all'indirizzo del giocatore.
+
+- `Map`: la chiave è una tupla di tre valori:
+
+ - `gameId`: valore a 32 byte che è l'hash della mappa su cui il giocatore sta giocando (l'identificatore del gioco).
+ - coordinata `x`
+ - coordinata `y`
+
+ Il valore è un singolo numero. È 255 se è stata rilevata una bomba. Altrimenti, è il numero di bombe intorno a quella posizione più uno. Non possiamo usare solo il numero di bombe, perché per impostazione predefinita tutto lo storage nell'EVM e tutti i valori di riga in MUD sono zero. Dobbiamo distinguere tra "il giocatore non ha ancora scavato qui" e "il giocatore ha scavato qui e ha scoperto che non ci sono bombe intorno".
+
+Inoltre, la comunicazione tra il client e il server avviene attraverso il componente on-chain. Anche questo è implementato utilizzando le tabelle.
+
+- `PendingGame`: Richieste non servite per iniziare una nuova partita.
+- `PendingDig`: Richieste non servite di scavare in un posto specifico in una partita specifica. Questa è una [tabella off-chain](https://mud.dev/store/tables#types-of-tables), il che significa che non viene scritta nell'archiviazione EVM, ma è leggibile solo off-chain tramite eventi.
+
+### Flussi di esecuzione e di dati {#execution-data-flows}
+
+Questi flussi coordinano l'esecuzione tra il client, il componente on-chain e il server.
+
+#### Inizializzazione {#initialization-flow}
+
+Quando si esegue `mprocs`, si verificano questi passaggi:
+
+1. [`mprocs`](https://github.com/pvolok/mprocs) esegue quattro componenti:
+
+ - [Anvil](https://book.getfoundry.sh/anvil/), che esegue una blockchain locale
+ - [Contracts](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/contracts), che compila (se necessario) e distribuisce i contratti per MUD
+ - [Client](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/client), che esegue [Vite](https://vitejs.dev/) per servire l'interfaccia utente e il codice del client ai browser Web.
+ - [Server](https://github.com/qbzzt/20240901-secret-state/tree/main/packages/server), che esegue le azioni del server
+
+2. Il pacchetto `contracts` distribuisce i contratti MUD e quindi esegue [lo script `PostDeploy.s.sol`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol). Questo script imposta la configurazione. Il codice da GitHub specifica [un campo minato 10x5 con otto mine](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/script/PostDeploy.s.sol#L23).
+
+3. [Il server](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts) inizia [impostando MUD](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L6). Tra le altre cose, questo attiva la sincronizzazione dei dati, in modo che una copia delle tabelle pertinenti esista nella memoria del server.
+
+4. Il server sottoscrive una funzione da eseguire [quando la tabella `Configuration` cambia](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L23). [Questa funzione](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L24-L168) viene chiamata dopo che `PostDeploy.s.sol` viene eseguito e modifica la tabella.
+
+5. Quando la funzione di inizializzazione del server ha la configurazione, [chiama `zkFunctions`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L34-L35) per inizializzare [la parte a conoscenza-zero del server](#using-zokrates-from-typescript). Questo non può accadere finché non otteniamo la configurazione, perché le funzioni a conoscenza-zero devono avere la larghezza e l'altezza del campo minato come costanti.
+
+6. Dopo l'inizializzazione della parte a conoscenza-zero del server, il passo successivo è [distribuire il contratto di verifica a conoscenza-zero sulla blockchain](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L42-L53) e impostare l'indirizzo del verificato in MUD.
+
+7. Infine, ci iscriviamo agli aggiornamenti per vedere quando un giocatore richiede di [iniziare una nuova partita](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71) o di [scavare in una partita esistente](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73-L108).
+
+#### Nuova partita {#new-game-flow}
+
+Questo è ciò che accade quando il giocatore richiede una nuova partita.
+
+1. Se non c'è una partita in corso per questo giocatore, o ce n'è una ma con un gameId pari a zero, il client visualizza un [pulsante Nuova partita](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175). Quando l'utente preme questo pulsante, [React esegue la funzione `newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L96).
+
+2. [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L43-L46) è una chiamata di `Sistema`. In MUD tutte le chiamate vengono instradate attraverso il contratto `World` e nella maggior parte dei casi si chiama `__`. In questo caso, la chiamata è a `app__newGame`, che MUD instrada a [`newGame` in `GameSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L16-L22).
+
+3. La funzione on-chain controlla che il giocatore non abbia una partita in corso e, in caso contrario, [aggiunge la richiesta alla tabella `PendingGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L21).
+
+4. Il server rileva la modifica in `PendingGame` ed [esegue la funzione sottoscritta](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L55-L71). Questa funzione chiama [`newGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L110-L114), che a sua volta chiama [`createGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L116-L144).
+
+5. La prima cosa che `createGame` fa è [creare una mappa casuale con il numero appropriato di mine](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L120-L135). Quindi, chiama [`makeMapBorders`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L147-L166) per creare una mappa con bordi vuoti, necessaria per Zokrates. Infine, `createGame` chiama [`calculateMapHash`](#calculateMapHash), per ottenere l'hash della mappa, che viene utilizzato come ID del gioco.
+
+6. La funzione `newGame` aggiunge la nuova partita a `gamesInProgress`.
+
+7. L'ultima cosa che fa il server è chiamare [`app__newGameResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L38-L43), che è on-chain. Questa funzione si trova in un `Sistema` diverso, [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol), per abilitare il controllo degli accessi. Il controllo degli accessi è definito nel [file di configurazione MUD](https://mud.dev/config), [`mud.config.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts#L67-L72).
+
+ La lista di accesso consente solo a un singolo indirizzo di chiamare il `Sistema`. Ciò limita l'accesso alle funzioni del server a un singolo indirizzo, in modo che nessuno possa impersonare il server.
+
+8. Il componente on-chain aggiorna le tabelle pertinenti:
+
+ - Creare la partita in `PlayerGame`.
+ - Impostare la mappatura inversa in `GamePlayer`.
+ - Rimuovere la richiesta da `PendingGame`.
+
+9. Il server identifica la modifica in `PendingGame`, ma non fa nulla perché [`wantsGame`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L58-L60) è falso.
+
+10. Sul client [`gameRecord`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L143-L148) è impostato sulla voce `PlayerGame` per l'indirizzo del giocatore. Quando `PlayerGame` cambia, cambia anche `gameRecord`.
+
+11. Se c'è un valore in `gameRecord`, e la partita non è stata né vinta né persa, il client [mostra la mappa](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190).
+
+#### Scavo {#dig-flow}
+
+1. Il giocatore [fa clic sul pulsante della cella della mappa](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L188), che chiama [la funzione `dig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/mud/createSystemCalls.ts#L33-L36). Questa funzione chiama [`dig` on-chain](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L24-L32).
+
+2. Il componente on-chain [esegue una serie di controlli di integrità](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L25-L30) e, in caso di successo, aggiunge la richiesta di scavo a [`PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/GameSystem.sol#L31).
+
+3. Il server [rileva la modifica in `PendingDig`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L73). [Se è valida](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L75-L84), [chiama il codice a conoscenza-zero](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L86-L95) (spiegato di seguito) per generare sia il risultato che una prova della sua validità.
+
+4. [Il server](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L97-L107) chiama [`digResponse`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L45-L64) on-chain.
+
+5. `digResponse` fa due cose. Innanzitutto, controlla [la prova a conoscenza-zero](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L47-L61). Quindi, se la prova è corretta, chiama [`processDigResult`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L67-L86) per elaborare effettivamente il risultato.
+
+6. `processDigResult` controlla se la partita è stata [persa](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L76-L78) o [vinta](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L83-L86) e [aggiorna `Map`, la mappa on-chain](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol#L80).
+
+7. Il client rileva automaticamente gli aggiornamenti e [aggiorna la mappa visualizzata al giocatore](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190) e, se applicabile, comunica al giocatore se ha vinto o perso.
+
+## Utilizzo di Zokrates {#using-zokrates}
+
+Nei flussi spiegati sopra abbiamo saltato le parti a conoscenza-zero, trattandole come una scatola nera. Ora apriamola e vediamo come è scritto quel codice.
+
+### Hashing della mappa {#hashing-map}
+
+Possiamo utilizzare [questo codice JavaScript](https://github.com/ZK-Plus/ICBC24_Tutorial_Compute-Offchain-Verify-onchain/tree/solutions/exercise) per implementare [Poseidon](https://www.poseidon-hash.info), la funzione di hash di Zokrates che utilizziamo. Tuttavia, sebbene questo sarebbe più veloce, sarebbe anche più complicato che usare semplicemente la funzione di hash di Zokrates per farlo. Questo è un tutorial e quindi il codice è ottimizzato per la semplicità, non per le prestazioni. Pertanto, abbiamo bisogno di due diversi programmi Zokrates, uno per calcolare semplicemente l'hash di una mappa (`hash`) e uno per creare effettivamente una prova a conoscenza-zero del risultato dello scavo in una posizione sulla mappa (`dig`).
+
+### La funzione di hash {#hash-function}
+
+Questa è la funzione che calcola l'hash di una mappa. Analizzeremo questo codice riga per riga.
+
+```
+import "hashes/poseidon/poseidon.zok" as poseidon;
+import "utils/pack/bool/pack128.zok" as pack128;
+```
+
+Queste due righe importano due funzioni dalla [libreria standard di Zokrates](https://zokrates.github.io/toolbox/stdlib.html). [La prima funzione](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/hashes/poseidon/poseidon.zok) è un [hash Poseidon](https://www.poseidon-hash.info/). Accetta un array di elementi [`field` (campo)](https://zokrates.github.io/language/types.html#field) e restituisce un `field`.
+
+L'elemento di campo in Zokrates è in genere lungo meno di 256 bit, ma non di molto. Per semplificare il codice, limitiamo la mappa a un massimo di 512 bit ed eseguiamo l'hash di un array di quattro campi, e in ogni campo utilizziamo solo 128 bit. [La funzione `pack128`](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/utils/pack/bool/pack128.zok) cambia un array di 128 bit in un `field` a questo scopo.
+
+```
+ def hashMap(bool[${width+2}][${height+2}] map) -> field {
+```
+
+Questa riga avvia la definizione di una funzione. `hashMap` ottiene un singolo parametro chiamato `map`, un array `bool`(eano) bidimensionale. La dimensione della mappa è `width+2` per `height+2` per ragioni che sono [spiegate di seguito](#why-map-border).
+
+Possiamo usare `${width+2}` e `${height+2}` perché i programmi Zokrates sono memorizzati in questa applicazione come [stringhe modello](https://www.w3schools.com/js/js_string_templates.asp). Il codice tra `${` e `}` viene valutato da JavaScript e in questo modo il programma può essere utilizzato per diverse dimensioni di mappa. Il parametro della mappa ha un bordo largo una posizione tutto intorno senza bombe, che è il motivo per cui dobbiamo aggiungere due alla larghezza e all'altezza.
+
+Il valore di ritorno è un `field` (campo) che contiene l'hash.
+
+```
+ bool[512] mut map1d = [false; 512];
+```
+
+La mappa è bidimensionale. Tuttavia, la funzione `pack128` non funziona con array bidimensionali. Quindi prima appiattiamo la mappa in un array di 512 byte, usando `map1d`. Per impostazione predefinita le variabili Zokrates sono costanti, ma dobbiamo assegnare valori a questo array in un ciclo, quindi lo definiamo come [`mut`](https://zokrates.github.io/language/variables.html#mutability).
+
+Dobbiamo inizializzare l'array perché Zokrates non ha `undefined`. L'espressione `[false; 512]` significa [un array di 512 valori `false`](https://zokrates.github.io/language/types.html#declaration-and-initialization).
+
+```
+ u32 mut counter = 0;
+```
+
+Abbiamo anche bisogno di un contatore per distinguere tra i bit che abbiamo già riempito in `map1d` e quelli che non abbiamo riempito.
+
+```
+ for u32 x in 0..${width+2} {
+```
+
+Questo è il modo in cui si dichiara un [ciclo `for`](https://zokrates.github.io/language/control_flow.html#for-loops) in Zokrates. Un ciclo `for` di Zokrates deve avere limiti fissi, perché mentre sembra essere un ciclo, il compilatore in realtà lo "srotola". L'espressione `${width+2}` è una costante di compilazione perché `width` viene impostata dal codice TypeScript prima di chiamare il compilatore.
+
+```
+ for u32 y in 0..${height+2} {
+ map1d[counter] = map[x][y];
+ counter = counter+1;
+ }
+ }
+```
+
+Per ogni posizione nella mappa, inserisci quel valore nell'array `map1d` e incrementa il contatore.
+
+```
+ field[4] hashMe = [
+ pack128(map1d[0..128]),
+ pack128(map1d[128..256]),
+ pack128(map1d[256..384]),
+ pack128(map1d[384..512])
+ ];
+```
+
+`pack128` crea un array di quattro valori `field` da `map1d`. In Zokrates `array[a..b]` significa la fetta dell'array che inizia in `a` e termina in `b-1`.
+
+```
+ return poseidon(hashMe);
+}
+```
+
+Usa `poseidon` per convertire questo array in un hash.
+
+### Il programma di hash {#hash-program}
+
+Il server deve chiamare `hashMap` direttamente per creare gli identificatori del gioco. Tuttavia, Zokrates può chiamare solo la funzione `main` in un programma per iniziare, quindi creiamo un programma con un `main` che chiama la funzione di hash.
+
+```
+${hashFragment}
+
+def main(bool[${width+2}][${height+2}] map) -> field {
+ return hashMap(map);
+}
+```
+
+### Il programma di scavo {#dig-program}
+
+Questo è il cuore della parte a conoscenza-zero dell'applicazione, dove produciamo le prove che vengono utilizzate per verificare i risultati dello scavo.
+
+```
+${hashFragment}
+
+// Il numero di mine nella posizione (x,y)
+def map2mineCount(bool[${width+2}][${height+2}] map, u32 x, u32 y) -> u8 {
+ return if map[x+1][y+1] { 1 } else { 0 };
+}
+```
+
+#### Perché il bordo della mappa {#why-map-border}
+
+Le prove a conoscenza-zero utilizzano [circuiti aritmetici](https://medium.com/web3studio/simple-explanations-of-arithmetic-circuits-and-zero-knowledge-proofs-806e59a79785), che non hanno un equivalente facile a un'istruzione `if`. Invece, usano l'equivalente dell'[operatore condizionale](https://en.wikipedia.org/wiki/Ternary_conditional_operator). Se `a` può essere zero o uno, è possibile calcolare `if a { b } else { c }` come `ab+(1-a)c`.
+
+Per questo motivo, un'istruzione `if` di Zokrates valuta sempre entrambi i rami. Ad esempio, se si dispone di questo codice:
+
+```
+bool[5] arr = [false; 5];
+u32 index=10;
+return if index>4 { 0 } else { arr[index] }
+```
+
+Genererà un errore, perché deve calcolare `arr[10]`, anche se quel valore verrà successivamente moltiplicato per zero.
+
+Questo è il motivo per cui abbiamo bisogno di un bordo largo una posizione tutto intorno alla mappa. Dobbiamo calcolare il numero totale di mine intorno a una posizione, e questo significa che dobbiamo vedere la posizione una riga sopra e sotto, a sinistra e a destra, della posizione in cui stiamo scavando. Ciò significa che quelle posizioni devono esistere nell'array della mappa fornito a Zokrates.
+
+```
+def main(private bool[${width+2}][${height+2}] map, u32 x, u32 y) -> (field, u8) {
+```
+
+Per impostazione predefinita le prove Zokrates includono i loro input. Non serve a nulla sapere che ci sono cinque mine intorno a un punto a meno che non si sappia effettivamente di quale punto si tratta (e non si può semplicemente abbinarlo alla propria richiesta, perché allora il provatore potrebbe usare valori diversi e non dirlo). Tuttavia, dobbiamo mantenere la mappa segreta, fornendola a Zokrates. La soluzione consiste nell'utilizzare un parametro `privato`, uno che _non_ viene rivelato dalla prova.
+
+Questo apre un'altra via per l'abuso. Il provatore potrebbe usare le coordinate corrette, ma creare una mappa con un numero qualsiasi di mine intorno alla posizione, e possibilmente nella posizione stessa. Per prevenire questo abuso, facciamo in modo che la prova a conoscenza-zero includa l'hash della mappa, che è l'identificatore del gioco.
+
+```
+ return (hashMap(map),
+```
+
+Il valore di ritorno qui è una tupla che include l'array di hash della mappa e il risultato dello scavo.
+
+```
+ if map2mineCount(map, x, y) > 0 { 0xFF } else {
+```
+
+Usiamo 255 come valore speciale nel caso in cui la posizione stessa abbia una bomba.
+
+```
+ map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) +
+ map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) +
+ map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1)
+ }
+ );
+}
+```
+
+Se il giocatore non ha colpito una mina, aggiungi il conteggio delle mine per l'area intorno alla posizione e restituisci quello.
+
+### Utilizzo di Zokrates da TypeScript {#using-zokrates-from-typescript}
+
+Zokrates ha un'interfaccia a riga di comando, ma in questo programma lo usiamo nel [codice TypeScript](https://zokrates.github.io/toolbox/zokrates_js.html).
+
+La libreria che contiene le definizioni Zokrates si chiama [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts).
+
+```typescript
+import { initialize as zokratesInitialize } from "zokrates-js"
+```
+
+Importa i [binding JavaScript di Zokrates](https://zokrates.github.io/toolbox/zokrates_js.html). Abbiamo bisogno solo della funzione [`initialize`](https://zokrates.github.io/toolbox/zokrates_js.html#initialize) perché restituisce una promessa che si risolve in tutte le definizioni di Zokrates.
+
+```typescript
+export const zkFunctions = async (width: number, height: number) : Promise => {
+```
+
+Similmente a Zokrates stesso, esportiamo anche una sola funzione, che è anche [asincrona](https://www.w3schools.com/js/js_async.asp). Quando alla fine restituisce, fornisce diverse funzioni come vedremo di seguito.
+
+```typescript
+const zokrates = await zokratesInitialize()
+```
+
+Inizializza Zokrates, ottieni tutto ciò di cui abbiamo bisogno dalla libreria.
+
+```typescript
+const hashFragment = `
+ import "utils/pack/bool/pack128.zok" as pack128;
+ import "hashes/poseidon/poseidon.zok" as poseidon;
+ .
+ .
+ .
+ }
+ `
+
+const hashProgram = `
+ ${hashFragment}
+ .
+ .
+ .
+ `
+
+const digProgram = `
+ ${hashFragment}
+ .
+ .
+ .
+ `
+```
+
+Successivamente abbiamo la funzione di hash e due programmi Zokrates che abbiamo visto sopra.
+
+```typescript
+const digCompiled = zokrates.compile(digProgram)
+const hashCompiled = zokrates.compile(hashProgram)
+```
+
+Qui compiliamo quei programmi.
+
+```typescript
+// Crea le chiavi per la verifica a conoscenza-zero.
+// Su un sistema di produzione vorresti usare una cerimonia di configurazione.
+// (https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony).
+const keySetupResults = zokrates.setup(digCompiled.program, "")
+const verifierKey = keySetupResults.vk
+const proverKey = keySetupResults.pk
+```
+
+Su un sistema di produzione potremmo utilizzare una [cerimonia di configurazione](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony) più complessa, ma questa è sufficiente per una dimostrazione. Non è un problema che gli utenti possano conoscere la chiave del provatore - non possono comunque usarla per provare cose a meno che non siano vere. Poiché specifichiamo l'entropia (il secondo parametro, `""`), i risultati saranno sempre gli stessi.
+
+**Nota:** La compilazione dei programmi Zokrates e la creazione delle chiavi sono processi lenti. Non è necessario ripeterli ogni volta, solo quando la dimensione della mappa cambia. Su un sistema di produzione li faresti una volta, e poi memorizzeresti l'output. L'unica ragione per cui non lo faccio qui è per semplicità.
+
+#### `calculateMapHash` {#calculateMapHash}
+
+```typescript
+const calculateMapHash = function (hashMe: boolean[][]): string {
+ return (
+ "0x" +
+ BigInt(zokrates.computeWitness(hashCompiled, [hashMe]).output.slice(1, -1))
+ .toString(16)
+ .padStart(64, "0")
+ )
+}
+```
+
+La funzione [`computeWitness`](https://zokrates.github.io/toolbox/zokrates_js.html#computewitnessartifacts-args-options) esegue effettivamente il programma Zokrates. Restituisce una struttura con due campi: `output`, che è l'output del programma come stringa JSON, e `witness`, che è l'informazione necessaria per creare la prova a conoscenza-zero del risultato. Qui abbiamo bisogno solo dell'output.
+
+L'output è una stringa del tipo `"31337"`, un numero decimale racchiuso tra virgolette. Ma l'output di cui abbiamo bisogno per `viem` è un numero esadecimale del tipo `0x60A7`. Quindi usiamo `.slice(1,-1)` per rimuovere le virgolette e poi `BigInt` per eseguire la stringa rimanente, che è un numero decimale, in un [`BigInt`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt). `.toString(16)` converte questo `BigInt` in una stringa esadecimale, e `"0x"+` aggiunge il marcatore per i numeri esadecimali.
+
+```typescript
+// Scava e restituisci una prova a conoscenza-zero del risultato
+// (codice lato server)
+```
+
+La prova a conoscenza-zero include gli input pubblici (`x` e `y`) e i risultati (hash della mappa e numero di bombe).
+
+```typescript
+ const zkDig = function(map: boolean[][], x: number, y: number) : any {
+ if (x<0 || x>=width || y<0 || y>=height)
+ throw new Error("Trying to dig outside the map")
+```
+
+È un problema controllare se un indice è fuori dai limiti in Zokrates, quindi lo facciamo qui.
+
+```typescript
+const runResults = zokrates.computeWitness(digCompiled, [map, `${x}`, `${y}`])
+```
+
+Esegui il programma di scavo.
+
+```typescript
+ const proof = zokrates.generateProof(
+ digCompiled.program,
+ runResults.witness,
+ proverKey)
+
+ return proof
+ }
+```
+
+Usa [`generateProof`](https://zokrates.github.io/toolbox/zokrates_js.html#generateproofprogram-witness-provingkey-entropy) e restituisci la prova.
+
+```typescript
+const solidityVerifier = `
+ // Dimensione mappa: ${width} x ${height}
+ \n${zokrates.exportSolidityVerifier(verifierKey)}
+ `
+```
+
+Un verificatore Solidity, un contratto intelligente che possiamo distribuire sulla blockchain e utilizzare per verificare le prove generate da `digCompiled.program`.
+
+```typescript
+ return {
+ zkDig,
+ calculateMapHash,
+ solidityVerifier,
+ }
+}
+```
+
+Infine, restituisci tutto ciò di cui altro codice potrebbe aver bisogno.
+
+## Test di sicurezza {#security-tests}
+
+I test di sicurezza sono importanti perché un bug di funzionalità alla fine si rivelerà da solo. Ma se l'applicazione è insicura, è probabile che rimanga nascosta per molto tempo prima che venga rivelata da qualcuno che bara e si appropria di risorse che appartengono ad altri.
+
+### Autorizzazioni {#permissions}
+
+C'è un'entità privilegiata in questo gioco, il server. È l'unico utente autorizzato a chiamare le funzioni in [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol). Possiamo usare [`cast`](https://book.getfoundry.sh/cast/) per verificare che le chiamate a funzioni con autorizzazione siano consentite solo come account del server.
+
+[La chiave privata del server è in `setupNetwork.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/mud/setupNetwork.ts#L52).
+
+1. Sul computer che esegue `anvil` (la blockchain), imposta queste variabili d'ambiente.
+
+ ```sh copy
+ WORLD_ADDRESS=0x8d8b6b8414e1e3dcfd4168561b9be6bd3bf6ec4b
+ UNAUTHORIZED_KEY=0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a
+ AUTHORIZED_KEY=0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d
+ ```
+
+2. Usa `cast` per tentare di impostare l'indirizzo del verificatore come un indirizzo non autorizzato.
+
+ ```sh copy
+ cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $UNAUTHORIZED_KEY
+ ```
+
+ Non solo `cast` segnala un fallimento, ma puoi aprire **MUD Dev Tools** nel gioco sul browser, fare clic su **Tables**, e selezionare **app\_\_VerifierAddress**. Vedi che l'indirizzo non è zero.
+
+3. Imposta l'indirizzo del verificatore come indirizzo del server.
+
+ ```sh copy
+ cast send $WORLD_ADDRESS 'app__setVerifier(address)' `cast address-zero` --private-key $AUTHORIZED_KEY
+ ```
+
+ L'indirizzo in **app\_\_VerifiedAddress** dovrebbe ora essere zero.
+
+Tutte le funzioni MUD nello stesso `Sistema` passano attraverso lo stesso controllo di accesso, quindi considero questo test sufficiente. Se non lo fai, puoi controllare le altre funzioni in [`ServerSystem`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/src/systems/ServerSystem.sol).
+
+### Abusi a conoscenza-zero {#zero-knowledge-abuses}
+
+La matematica per verificare Zokrates va oltre lo scopo di questo tutorial (e le mie capacità). Tuttavia, possiamo eseguire vari controlli sul codice a conoscenza-zero per verificare che se non è fatto correttamente fallisca. Tutti questi test richiederanno di modificare [`zero-knowledge.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts) e riavviare l'intera applicazione. Non è sufficiente riavviare il processo del server, perché mette l'applicazione in uno stato impossibile (il giocatore ha una partita in corso, ma la partita non è più disponibile per il server).
+
+#### Risposta sbagliata {#wrong-answer}
+
+La possibilità più semplice è fornire la risposta sbagliata nella prova a conoscenza-zero. Per fare ciò, andiamo all'interno di `zkDig` e [modifichiamo la riga 91](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L91):
+
+```ts
+proof.inputs[3] = "0x" + "1".padStart(64, "0")
+```
+
+Questo significa che affermeremo sempre che c'è una bomba, indipendentemente dalla risposta corretta. Prova a giocare con questa versione e vedrai nella scheda **server** della schermata `pnpm dev` questo errore:
+
+```
+ cause: {
+ code: 3,
+ message: 'execution reverted: revert: Zero knowledge verification fail',
+ data: '0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000
+00000000000000000000000000000000000000000000000205a65726f206b6e6f776c6564676520766572696669636174696f6
+e206661696c'
+ },
+```
+
+Quindi questo tipo di imbroglio fallisce.
+
+#### Prova errata {#wrong-proof}
+
+Cosa succede se forniamo le informazioni corrette, ma abbiamo solo i dati della prova sbagliati? Ora, sostituisci la riga 91 con:
+
+```ts
+proof.proof = {
+ a: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ b: [
+ ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+ ],
+ c: ["0x" + "1".padStart(64, "0"), "0x" + "2".padStart(64, "0")],
+}
+```
+
+Fallisce ancora, ma ora fallisce senza un motivo perché accade durante la chiamata al verificatore.
+
+### Come può un utente verificare il codice a fiducia-zero? {#user-verify-zero-trust}
+
+I contratti intelligenti sono relativamente facili da verificare. In genere, lo sviluppatore pubblica il codice sorgente su un esploratore di blocchi, e l'esploratore di blocchi verifica che il codice sorgente venga compilato nel codice della [transazione di distribuzione del contratto](/developers/docs/smart-contracts/deploying/). Nel caso dei `Sistemi` MUD questo è [leggermente più complicato](https://mud.dev/cli/verify), ma non di molto.
+
+Questo è più difficile con la conoscenza-zero. Il verificatore include alcune costanti ed esegue alcuni calcoli su di esse. Questo non ti dice cosa viene provato.
+
+```solidity
+ function verifyingKey() pure internal returns (VerifyingKey memory vk) {
+ vk.alpha = Pairing.G1Point(uint256(0x0f43f4fe7b5c2326fed4ac6ed2f4003ab9ab4ea6f667c2bdd77afb068617ee16), uint256(0x25a77832283f9726935219b5f4678842cda465631e72dbb24708a97ba5d0ce6f));
+ vk.beta = Pairing.G2Point([uint256(0x2cebd0fbd21aca01910581537b21ae4fed46bc0e524c055059aa164ba0a6b62b), uint256(0x18fd4a7bc386cf03a95af7163d5359165acc4e7961cb46519e6d9ee4a1e2b7e9)], [uint256(0x11449dee0199ef6d8eebfe43b548e875c69e7ce37705ee9a00c81fe52f11a009), uint256(0x066d0c83b32800d3f335bb9e8ed5e2924cf00e77e6ec28178592eac9898e1a00)]);
+```
+
+La soluzione, almeno finché gli esploratori di blocchi non aggiungeranno la verifica Zokrates alle loro interfacce utente, è che gli sviluppatori dell'applicazione rendano disponibili i programmi Zokrates e che almeno alcuni utenti li compilino da soli con la chiave di verifica appropriata.
+
+Per farlo:
+
+1. [Installa Zokrates](https://zokrates.github.io/gettingstarted.html).
+
+2. Crea un file, `dig.zok`, con il programma Zokrates. Il codice seguente presuppone che tu abbia mantenuto la dimensione originale della mappa, 10x5.
+
+ ```zokrates
+ import "utils/pack/bool/pack128.zok" as pack128;
+ import "hashes/poseidon/poseidon.zok" as poseidon;
+
+ def hashMap(bool[12][7] map) -> field {
+ bool[512] mut map1d = [false; 512];
+ u32 mut counter = 0;
+
+ for u32 x in 0..12 {
+ for u32 y in 0..7 {
+ map1d[counter] = map[x][y];
+ counter = counter+1;
+ }
+ }
+
+ field[4] hashMe = [
+ pack128(map1d[0..128]),
+ pack128(map1d[128..256]),
+ pack128(map1d[256..384]),
+ pack128(map1d[384..512])
+ ];
+
+ return poseidon(hashMe);
+ }
+
+
+ // Il numero di mine nella posizione (x,y)
+ def map2mineCount(bool[12][7] map, u32 x, u32 y) -> u8 {
+ return if map[x+1][y+1] { 1 } else { 0 };
+ }
+
+ def main(private bool[12][7] map, u32 x, u32 y) -> (field, u8) {
+ return (hashMap(map) ,
+ if map2mineCount(map, x, y) > 0 { 0xFF } else {
+ map2mineCount(map, x-1, y-1) + map2mineCount(map, x, y-1) + map2mineCount(map, x+1, y-1) +
+ map2mineCount(map, x-1, y) + map2mineCount(map, x+1, y) +
+ map2mineCount(map, x-1, y+1) + map2mineCount(map, x, y+1) + map2mineCount(map, x+1, y+1)
+ }
+ );
+ }
+ ```
+
+3. Compila il codice Zokrates e crea la chiave di verifica. La chiave di verifica deve essere creata con la stessa entropia utilizzata nel server originale, [in questo caso una stringa vuota](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L67).
+
+ ```sh copy
+ zokrates compile --input dig.zok
+ zokrates setup -e ""
+ ```
+
+4. Crea il verificatore Solidity da solo e verifica che sia funzionalmente identico a quello sulla blockchain (il server aggiunge un commento, ma non è importante).
+
+ ```sh copy
+ zokrates export-verifier
+ diff verifier.sol ~/20240901-secret-state/packages/contracts/src/verifier.sol
+ ```
+
+## Decisioni di progettazione {#design}
+
+In ogni applicazione sufficientemente complessa ci sono obiettivi di progettazione contrastanti che richiedono compromessi. Diamo un'occhiata ad alcuni dei compromessi e al motivo per cui la soluzione attuale è preferibile ad altre opzioni.
+
+### Perché conoscenza-zero {#why-zero-knowledge}
+
+Per Campo Minato non hai davvero bisogno della conoscenza-zero. Il server può sempre conservare la mappa e poi rivelarla tutta quando il gioco è finito. Quindi, alla fine del gioco, il contratto intelligente può calcolare l'hash della mappa, verificare che corrisponda e, in caso contrario, penalizzare il server o ignorare completamente il gioco.
+
+Non ho usato questa soluzione più semplice perché funziona solo per giochi brevi con uno stato finale ben definito. Quando un gioco è potenzialmente infinito (come nel caso dei [mondi autonomi](https://0xparc.org/blog/autonomous-worlds)), hai bisogno di una soluzione che provi lo stato _senza_ rivelarlo.
+
+Come guida, questo articolo aveva bisogno di un gioco breve e facile da capire, ma questa tecnica è più utile per giochi più lunghi.
+
+### Perché Zokrates? {#why-zokrates}
+
+[Zokrates](https://zokrates.github.io/) non è l'unica libreria a conoscenza-zero disponibile, ma è simile a un normale linguaggio di programmazione [imperativo](https://en.wikipedia.org/wiki/Imperative_programming) e supporta variabili booleane.
+
+Per la tua applicazione, con requisiti diversi, potresti preferire utilizzare [Circum](https://docs.circom.io/getting-started/installation/) o [Cairo](https://www.cairo-lang.org/tutorials/getting-started-with-cairo/).
+
+### Quando compilare Zokrates {#when-compile-zokrates}
+
+In questo programma compiliamo i programmi Zokrates [ogni volta che il server si avvia](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L60-L61). Questo è chiaramente uno spreco di risorse, ma questo è un tutorial, ottimizzato per la semplicità.
+
+Se stessi scrivendo un'applicazione a livello di produzione, verificherei se ho un file con i programmi Zokrates compilati a questa dimensione del campo minato, e in tal caso lo userei. Lo stesso vale per la distribuzione di un contratto di verifica on-chain.
+
+### Creazione delle chiavi di verificatore e provatore {#key-creation}
+
+[La creazione delle chiavi](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L63-L69) è un altro calcolo puro che non deve essere fatto più di una volta per una data dimensione del campo minato. Anche in questo caso, viene fatto una sola volta per semplicità.
+
+Inoltre, potremmo usare [una cerimonia di configurazione](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony). Il vantaggio di una cerimonia di configurazione è che è necessaria l'entropia o qualche risultato intermedio di ogni partecipante per barare sulla prova a conoscenza-zero. Se almeno un partecipante alla cerimonia è onesto e cancella tali informazioni, le prove a conoscenza-zero sono al sicuro da certi attacchi. Tuttavia, non esiste _nessun meccanismo_ per verificare che le informazioni siano state eliminate da ogni parte. Se le prove a conoscenza-zero sono di fondamentale importanza, è consigliabile partecipare alla cerimonia di configurazione.
+
+Qui ci affidiamo a [perpetual powers of tau](https://github.com/privacy-scaling-explorations/perpetualpowersoftau), che ha avuto dozzine di partecipanti. È probabilmente abbastanza sicuro e molto più semplice. Inoltre, non aggiungiamo entropia durante la creazione delle chiavi, il che rende più facile per gli utenti [verificare la configurazione a conoscenza-zero](#user-verify-zero-trust).
+
+### Dove verificare {#where-verification}
+
+Possiamo verificare le prove a conoscenza-zero on-chain (il che costa gas) o nel client (usando [`verify`](https://zokrates.github.io/toolbox/zokrates_js.html#verifyverificationkey-proof)). Ho scelto la prima, perché permette di [verificare il verificatore](#user-verify-zero-trust) una volta e poi confidare che non cambi finché l'indirizzo del suo contratto rimane lo stesso. Se la verifica fosse fatta sul client, dovresti verificare il codice che ricevi ogni volta che scarichi il client.
+
+Inoltre, sebbene questo gioco sia per un solo giocatore, molti giochi blockchain sono multiplayer. La verifica on-chain significa che verifichi la prova a conoscenza-zero una sola volta. Farlo nel client richiederebbe a ogni client di verificare in modo indipendente.
+
+### Appiattire la mappa in TypeScript o Zokrates? {#where-flatten}
+
+In generale, quando l'elaborazione può essere eseguita in TypeScript o Zokrates, è meglio farlo in TypeScript, che è molto più veloce e non richiede prove a conoscenza-zero. Questo è il motivo, ad esempio, per cui non forniamo a Zokrates l'hash per fargli verificare che sia corretto. L'hashing deve essere fatto all'interno di Zokrates, ma la corrispondenza tra l'hash restituito e l'hash on-chain può avvenire al di fuori di esso.
+
+Tuttavia, [appiattiamo ancora la mappa in Zokrates](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L15-L20), mentre avremmo potuto farlo in TypeScript. La ragione è che le altre opzioni sono, a mio parere, peggiori.
+
+- Fornire un array unidimensionale di booleani al codice Zokrates e utilizzare un'espressione come `x*(height+2)
+ +y` per ottenere la mappa bidimensionale. Questo renderebbe [il codice](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/zero-knowledge.ts#L44-L47) leggermente più complicato, quindi ho deciso che il guadagno di prestazioni non ne vale la pena per una guida.
+
+- Invia a Zokrates sia l'array unidimensionale che l'array bidimensionale. Tuttavia, questa soluzione non ci porta alcun vantaggio. Il codice Zokrates dovrebbe verificare che l'array unidimensionale che gli viene fornito sia davvero la rappresentazione corretta dell'array bidimensionale. Quindi non ci sarebbe alcun guadagno di prestazioni.
+
+- Appiattire l'array bidimensionale in Zokrates. Questa è l'opzione più semplice, quindi l'ho scelta.
+
+### Dove memorizzare le mappe {#where-store-maps}
+
+In questa applicazione [`gamesInProgress`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/server/src/app.ts#L20) è semplicemente una variabile in memoria. Ciò significa che se il server muore e deve essere riavviato, tutte le informazioni che ha memorizzato vengono perse. Non solo i giocatori non possono continuare la loro partita, ma non possono nemmeno iniziarne una nuova perché il componente on-chain pensa che abbiano ancora una partita in corso.
+
+Questo è chiaramente un cattivo design per un sistema di produzione, in cui queste informazioni verrebbero memorizzate in un database. L'unico motivo per cui ho usato una variabile qui è perché questo è un tutorial e la semplicità è la considerazione principale.
+
+## Conclusione: in quali condizioni questa è la tecnica appropriata? {#conclusion}
+
+Quindi, ora sai come scrivere un gioco con un server che memorizza uno stato segreto che non appartiene all'on-chain. Ma in quali casi dovresti farlo? Ci sono due considerazioni principali.
+
+- _Gioco a lunga durata_: [Come accennato in precedenza](#why-zero-knowledge), in un gioco breve puoi semplicemente pubblicare lo stato una volta che il gioco è finito e far verificare tutto allora. Ma questa non è un'opzione quando il gioco richiede un tempo lungo o indefinito, e lo stato deve rimanere segreto.
+
+- _Una certa centralizzazione è accettabile_: le prove a conoscenza-zero possono verificare l'integrità, che un'entità non stia falsificando i risultati. Ciò che non possono fare è garantire che l'entità sarà ancora disponibile e risponderà ai messaggi. In situazioni in cui anche la disponibilità deve essere decentralizzata, le prove a conoscenza-zero non sono una soluzione sufficiente e hai bisogno di un [calcolo multipartitico](https://en.wikipedia.org/wiki/Secure_multi-party_computation).
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
+
+### Riconoscimenti {#acknowledgements}
+
+- Alvaro Alonso ha letto una bozza di questo articolo e ha chiarito alcune delle mie incomprensioni su Zokrates.
+
+Eventuali errori rimanenti sono di mia responsabilità.
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..0d0b2c9d9d0 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
@@ -2,18 +2,15 @@
title: Elenco di controllo di sicurezza per gli smart contract
description: Un flusso di lavoro suggerito per scrivere smart contract sicuri
author: "Trailofbits"
-tags:
- - "smart Contract"
- - "sicurezza"
- - "Solidity"
+tags: [ "Smart Contract", "sicurezza", "solidity" ]
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
---
-## Elenco di controllo per lo sviluppo di smart contract {#smart-contract-development-checklist}
+## Lista di controllo per lo sviluppo di contratti intelligenti {#smart-contract-development-checklist}
Ecco un processo d'alto livello che consigliamo di seguire per la scrittura degli smart contract.
@@ -24,22 +21,22 @@ Verifica i problemi di sicurezza noti:
Considera le funzionalità speciali del tuo contratto:
-- I tuoi contratti sono aggiornabili? Revisiona il tuo codice di aggiornabilità per i difetti con [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks) o [Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/). Abbiamo documentato 17 modi in cui gli aggiornamenti possono andare male.
+- I tuoi contratti sono aggiornabili? Revisiona il tuo codice di aggiornabilità per eventuali difetti con [`slither-check-upgradeability`](https://github.com/crytic/slither/wiki/Upgradeability-Checks) o [Crytic](https://blog.trailofbits.com/2020/06/12/upgradeable-contracts-made-safer-with-crytic/). Abbiamo documentato 17 modi in cui gli aggiornamenti possono andare male.
- I tuoi contratti pretendono di esser conformi agli ERC? Controllali con [`slither-check-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance). Questo strumento identifica istantaneamente le deviazioni da sei specifiche comuni.
-- Integri con token di terze parti? Revisiona il nostro [elenco di controllo di integrazione del token](/developers/tutorials/token-integration-checklist/) prima di affidarti a contratti esterni.
+- Integri con token di terze parti? Consulta la nostra [lista di controllo per l'integrazione dei token](/developers/tutorials/token-integration-checklist/) prima di fare affidamento su contratti esterni.
Ispeziona visivamente le funzionalità di sicurezza critiche del tuo codice:
-- Revisiona l'editore di Slither, [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph). Evita shadowing involontari e problemi di linearizzazione di C3.
-- Revisiona l'editore di Slither, [function-summary](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary). Segnala la visibilità della funzione e i controlli d'accesso.
-- Revisiona l'editore di Slither, [vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization). Segnala i controlli d'accesso sulle variabili di stato.
+- Consulta il printer [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph) di Slither. Evita shadowing involontari e problemi di linearizzazione di C3.
+- Consulta il printer [function-summary](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary) di Slither. Segnala la visibilità della funzione e i controlli d'accesso.
+- Consulta il printer [vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization) di Slither. Segnala i controlli d'accesso sulle variabili di stato.
Documenta le proprietà di sicurezza critiche e usa generatori di test automatizzati per valutarle:
- Impara a [documentare le proprietà di sicurezza per il tuo codice](/developers/tutorials/guide-to-smart-contract-security-tools/). All'inizio è difficile, ma è l'attività in assoluto più importante per ottenere un buon risultato. È anche un prerequisito per usare qualsiasi tecnica avanzata in questo tutorial.
-- Definisci le proprietà di sicurezza in Solidity, per l'uso con [Echidna](https://github.com/crytic/echidna) e [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html). Concentrati sulla tua macchina di stato, controlli d'accesso, operazioni aritmetiche, interazioni esterne e conformità agli standard.
-- Definisci le proprietà di sicurezza con l'[API di Python di Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/). Concentrati su eredità, dipendenze della variabile, controlli d'accesso e altri problemi strutturali.
-- Esegui i tuoi test di proprietà a ogni commit con [Crytic](https://crytic.io). Crytic può consumare e valutare i test di proprietà di sicurezza in modo che tutti nel team possano facilmente vedere che passano su GitHub. I testi falliti possono bloccare i commit.
+- Definisci le proprietà di sicurezza in Solidity, da usare con [Echidna](https://github.com/crytic/echidna) e [Manticore](https://manticore.readthedocs.io/en/latest/verifier.html). Concentrati sulla tua macchina di stato, controlli d'accesso, operazioni aritmetiche, interazioni esterne e conformità agli standard.
+- Definisci le proprietà di sicurezza con [l'API Python di Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/). Concentrati su eredità, dipendenze della variabile, controlli d'accesso e altri problemi strutturali.
+- Esegui i test di proprietà ad ogni commit con [Crytic](https://crytic.io). Crytic può consumare e valutare i test di proprietà di sicurezza in modo che tutti nel team possano facilmente vedere che passano su GitHub. I testi falliti possono bloccare i commit.
Infine, ricordati dei problemi che gli strumenti automatizzati non possono facilmente trovare:
@@ -50,6 +47,6 @@ Infine, ricordati dei problemi che gli strumenti automatizzati non possono facil
## Chiedi aiuto {#ask-for-help}
-[Orari lavorativi di Ethereum](https://calendly.com/dan-trailofbits/office-hours): ogni martedì pomeriggio. Queste sessioni 1 a 1 di un'ora sono un'opportunità per farci domande sulla sicurezza, la risoluzione dei problemi usando i nostri strumenti e la ricezione di feedback dagli esperti sul tuo approccio corrente. Ti aiuteremo ad arrivare in fondo a questa guida.
+[Ethereum office hours](https://calendly.com/dan-trailofbits/office-hours) si tengono ogni martedì pomeriggio. Queste sessioni 1 a 1 di un'ora sono un'opportunità per farci domande sulla sicurezza, la risoluzione dei problemi usando i nostri strumenti e la ricezione di feedback dagli esperti sul tuo approccio corrente. Ti aiuteremo ad arrivare in fondo a questa guida.
Unisciti al nostro Slack: [Empire Hacking](https://join.slack.com/t/empirehacking/shared_invite/zt-h97bbrj8-1jwuiU33nnzg67JcvIciUw). Siamo sempre disponibili nei canali #crytic ed #ethereum se hai domande.
diff --git a/public/content/translations/it/developers/tutorials/send-token-ethersjs/index.md b/public/content/translations/it/developers/tutorials/send-token-ethersjs/index.md
index 2041f8e2e15..668a4fa3d8a 100644
--- a/public/content/translations/it/developers/tutorials/send-token-ethersjs/index.md
+++ b/public/content/translations/it/developers/tutorials/send-token-ethersjs/index.md
@@ -2,10 +2,7 @@
title: Invio di token utilizzando ethers.js
description: Guida per principianti per l'invio di token utilizzando ethers.js.
author: Kim YongJun
-tags:
- - "ETHERS.JS"
- - "ERC-20"
- - "TOKEN"
+tags: [ "ETHERS.JS", "ERC-20", "TOKEN" ]
skill: beginner
lang: it
published: 2021-04-06
@@ -13,7 +10,7 @@ published: 2021-04-06
## Invio di token utilizzando ethers.js(5.0) {#send-token}
-### In questo tutorial imparerai come {#you-learn-about}
+### In questa guida imparerai come {#you-learn-about}
- Importare ethers.js
- Trasferire token
@@ -21,7 +18,8 @@ published: 2021-04-06
### Per iniziare {#to-get-started}
-Per iniziare, dobbiamo prima importare la libreria di ethers.js nel nostro javascript. `Include ethers.js(5.0)`
+Per iniziare, dobbiamo prima importare la libreria ethers.js nel nostro javascript
+Includi ethers.js(5.0)
### Installazione {#install-ethersjs}
@@ -34,7 +32,7 @@ ES6 nel browser
```html
```
@@ -59,19 +57,19 @@ ES3(UMD) nel browser
`signTransaction(tx)` è rimossa perché `sendTransaction()` lo fa internamente.
-## Invio delle procedure {#procedure}
+## Procedure di invio {#procedure}
-### 1. Connettiti alla rete (rete di prova) {#connect-to-network}
+### 1. Connessione alla rete (rete di test) {#connect-to-network}
-#### Imposta il provider (Infura) {#set-provider}
+#### Impostazione del provider (Infura) {#set-provider}
-Connettiti alla rete di prova di Ropsten
+Connettiti alla rete di test Ropsten
```javascript
window.ethersProvider = new ethers.providers.InfuraProvider("ropsten")
```
-### 2. Crea il portafoglio {#create-wallet}
+### 2. Creare un portafoglio {#create-wallet}
```javascript
let wallet = new ethers.Wallet(private_key)
@@ -89,16 +87,16 @@ let walletSigner = wallet.connect(window.ethersProvider)
window.ethersProvider.getGasPrice() // gasPrice
```
-### 5. Definisci la transazione {#define-transaction}
+### 5. Definire la transazione {#define-transaction}
-Queste variabili definite di seguito dipendono da `send_token()`
+Le variabili definite di seguito dipendono da `send_token()`
### Parametri della transazione {#transaction-params}
-1. **`send_account`**: L'indirizzo del mittente del token
+1. **`send_account`**: indirizzo del mittente del token
2. **`to_address`**: indirizzo del destinatario del token
3. **`send_token_amount`**: l'importo di token da inviare
-4. **`gas_limit`**: limite di gas
+4. **`gas_limit`**: limite del gas
5. **`gas_price`**: prezzo del gas
[Vedi sotto come usarli](#how-to-use)
@@ -119,11 +117,11 @@ const tx = {
```javascript
walletSigner.sendTransaction(tx).then((transaction) => {
console.dir(transaction)
- alert("Send finished!")
+ alert("Invio completato!")
})
```
-## Come usarlo {#how-to-use}
+## Come si usa {#how-to-use}
```javascript
let private_key =
@@ -148,7 +146,7 @@ send_token(
### Fatto! {#success}
-
+
## send_token() {#send-token-method}
@@ -168,23 +166,23 @@ function send_token(
console.log(`gas_price: ${gas_price}`)
if (contract_address) {
- // general token send
+ // invio di token generico
let contract = new ethers.Contract(
contract_address,
send_abi,
walletSigner
)
- // How many tokens?
+ // Quanti token?
let numberOfTokens = ethers.utils.parseUnits(send_token_amount, 18)
console.log(`numberOfTokens: ${numberOfTokens}`)
- // Send tokens
+ // Invia token
contract.transfer(to_address, numberOfTokens).then((transferResult) => {
console.dir(transferResult)
- alert("sent token")
+ alert("token inviato")
})
- } // ether send
+ } // invio di ether
else {
const tx = {
from: send_account,
@@ -201,10 +199,10 @@ function send_token(
try {
walletSigner.sendTransaction(tx).then((transaction) => {
console.dir(transaction)
- alert("Send finished!")
+ alert("Invio completato!")
})
} catch (error) {
- alert("failed to send!!")
+ alert("invio non riuscito!!")
}
}
})
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..2a0ce11882b 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
@@ -1,104 +1,101 @@
---
-title: Inviare transazioni usando Web3
-description: "Questa è una guida per principianti per inviare transazioni di Ethereum usando Web3. Ci sono tre fasi principali per inviare una transazione alla blockchain di Ethereum: creare, firmare e trasmettere. Le vedremo tutte e tre."
+title: Invio di transazioni con Web3
+description: "Questa è una guida per principianti all'invio di transazioni Ethereum tramite Web3. Ci sono tre passaggi principali per inviare una transazione alla blockchain di Ethereum: creare, firmare e trasmettere. Li esamineremo tutti e tre."
author: "Elan Halpern"
-tags:
- - "transazioni"
- - "web3.js"
- - "alchemy"
+tags: [ "transazioni", "web3.js", "alchemy" ]
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
---
-Questa è una guida per principianti per inviare transazioni di Ethereum usando Web3. Esistono tre passaggi principali per poter inviare una transazione alla blockchain di Ethereum: creare, firmare e trasmettere. Le vedremo tutte e tre, sperando di rispondere a tutte le domande che potreste avere! In questo tutorial, useremo [Alchemy](https://www.alchemy.com/) per inviare le nostre transazioni alla catena di Ethereum. Puoi [creare qui un conto gratuito di Alchemy](https://auth.alchemyapi.io/signup).
+Questa è una guida per principianti all'invio di transazioni Ethereum tramite Web3. Ci sono tre passaggi principali per inviare una transazione alla blockchain di Ethereum: creare, firmare e trasmettere. Li esamineremo tutti e tre, sperando di rispondere a tutte le tue domande! In questa guida, useremo [Alchemy](https://www.alchemy.com/) per inviare le nostre transazioni alla catena di Ethereum. Puoi [creare un account Alchemy gratuito qui](https://auth.alchemyapi.io/signup).
-**NOTA:** Questa guida è per firmare le tue transazioni sul _backend_ per la tua app. Se desideri integrare la firma delle tue transazioni sul frontend, dai un'occhiata all'integrazione di [Web3 con un fornitore del browser](https://docs.alchemy.com/reference/api-overview#with-a-browser-provider).
+**NOTA:** questa guida riguarda la firma delle tue transazioni sul _backend_ della tua app. Se vuoi integrare la firma delle tue transazioni sul frontend, consulta l'integrazione di [Web3 con un provider del browser](https://docs.alchemy.com/reference/api-overview#with-a-browser-provider).
-## Le nozioni di base {#the-basics}
+## Le basi {#the-basics}
-Come gran parte degli sviluppatori di blockchain quando iniziano, potresti aver fatto delle ricerche su come inviare una transazione (il che dovrebbe essere abbastanza facile) e potresti essere incappato in una moltitudine di guide, ognuna con indicazioni diverse, che rischiano di lasciare sopraffatti e confusi. Se sei su quella barca, non preoccuparti; ci siamo passati tutti! Quindi, prima d'iniziare, mettiamo in chiaro alcune cose:
+Come la maggior parte degli sviluppatori blockchain all'inizio, potresti aver fatto qualche ricerca su come inviare una transazione (qualcosa che dovrebbe essere abbastanza semplice) ed esserti imbattuto in una pletora di guide, ognuna con indicazioni diverse, che ti hanno lasciato un po' sopraffatto e confuso. Se ti trovi in questa situazione, non preoccuparti; ci siamo passati tutti a un certo punto! Quindi, prima d'iniziare, mettiamo in chiaro alcune cose:
-### 1\. Alchemy non memorizza le tue chiavi private {#alchemy-does-not-store-your-private-keys}
+### 1. Alchemy non memorizza le tue chiavi private {#alchemy-does-not-store-your-private-keys}
-- Questo significa che Alchemy non può firmare e inviare transazioni per conto tuo. Il motivo di ciò è la sicurezza. Alchemy non ti chiederà mai di condividere la tua chiave privata e non dovresti mai condividerla con un nodo ospitato (o, se è per questo, con nessuno).
+- Questo significa che Alchemy non può firmare e inviare transazioni per conto tuo. Il motivo è la sicurezza. Alchemy non ti chiederà mai di condividere la tua chiave privata e non dovresti mai condividerla con un nodo ospitato (o con chiunque altro, se è per questo).
- Puoi leggere dalla blockchain usando l'API principale di Alchemy, ma per scrivere dovrai usare qualcos'altro per firmare le transazioni prima di inviarle tramite Alchemy (così come per ogni altro [servizio di nodo](/developers/docs/nodes-and-clients/nodes-as-a-service/)).
-### 2\. Cos'è un "firmatario"? {#what-is-a-signer}
+### 2. Cos'è un "firmatario"? {#what-is-a-signer}
-- I firmatari firmano le transazioni per te usando la tua chiave privata. In questo tutorial useremo [ web3 di Alchemy](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3) per firmare la nostra transazione, ma puoi anche usare qualsiasi altra libreria di web3.
-- Sul frontend, un buon esempio di firmatario sarebbe [MetaMask](https://metamask.io/), che firmerà e invierà le transazioni per conto tuo.
+- I firmatari firmano le transazioni per te usando la tua chiave privata. In questa guida useremo [Alchemy web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3) per firmare la nostra transazione, ma puoi anche usare qualsiasi altra libreria web3.
+- Sul frontend, un buon esempio di firmatario è [MetaMask](https://metamask.io/), che firmerà e invierà le transazioni per tuo conto.
-### 3\. Perché devo firmare le mie transazioni? {#why-do-i-need-to-sign-my-transactions}
+### 3. Perché devo firmare le mie transazioni? {#why-do-i-need-to-sign-my-transactions}
- Ogni utente che desidera inviare una transazione sulla rete di Ethereum deve firmare la transazione (usando la propria chiave privata), per poter convalidare che l'origine della transazione sia quella affermata.
-- È davvero importante proteggere questa chiave privata, poiché avere accesso a essa concede il pieno controllo sul tuo conto privato, consentendoti (o a chiunque acceda) di eseguire transazioni per conto tuo.
+- È molto importante proteggere questa chiave privata, poiché avervi accesso garantisce il pieno controllo del tuo account Ethereum, consentendo a te (o a chiunque vi abbia accesso) di eseguire transazioni per tuo conto.
-### 4\. Come proteggo la mia chiave privata? {#how-do-i-protect-my-private-key}
+### 4. Come proteggo la mia chiave privata? {#how-do-i-protect-my-private-key}
-- Ci sono molti modi per proteggere la tua chiave privata e usarla per inviare le transazioni. In questo tutorial useremo un file `.env`. Tuttavia, potresti anche usare un provider separato che memorizzi le chiavi private, usare un file keystore o altre opzioni.
+- Ci sono molti modi per proteggere la tua chiave privata e usarla per inviare le transazioni. In questa guida useremo un file `.env`. Tuttavia, potresti anche usare un provider separato che memorizzi le chiavi private, usare un file keystore o altre opzioni.
-### 5\. Qual è la differenza tra `eth_sendTransaction` e `eth_sendRawTransaction`? {#difference-between-send-and-send-raw}
+### 5. Qual è la differenza tra `eth_sendTransaction` e `eth_sendRawTransaction`? {#difference-between-send-and-send-raw}
-`eth_sendTransaction` e `eth_sendRawTransaction` sono entrambe funzioni dell'API di Ethereum che trasmettono una transazione alla rete di Ethereum affinché venga aggiunta a un blocco futuro. Differiscono in come gestiscono la firma delle transazioni.
+`eth_sendTransaction` e `eth_sendRawTransaction` sono entrambe funzioni dell'API di Ethereum che trasmettono una transazione alla rete di Ethereum affinché venga aggiunta a un blocco futuro. Differiscono nel modo in cui gestiscono la firma delle transazioni.
-- [`eth_sendTransaction`](https://docs.web3js.org/api/web3-eth/function/sendTransaction) è usato per inviare transazioni _non firmate_, il che significa che il nodo a cui stai inviando deve gestire la tua chiave privata in modo che tu possa firmare la transazione prima di trasmetterla alla catena. Poiché Alchemy non detiene le chiavi private dell'utente, non supportiamo questo metodo.
-- [`eth_sendRawTransaction`](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction) è usato per trasmettere le transazioni che sono già state firmate. Ciò significa che devi prima usare [`signTransaction(tx, private_key)`](https://docs.web3js.org/api/web3-eth-accounts/function/signTransaction), poi passare il risultato in `eth_sendRawTransaction`.
+- [`eth_sendTransaction`](https://docs.web3js.org/api/web3-eth/function/sendTransaction) è usato per inviare transazioni _non firmate_, il che significa che il nodo a cui stai inviando deve gestire la tua chiave privata in modo da poter firmare la transazione prima di trasmetterla alla catena. Poiché Alchemy non detiene le chiavi private degli utenti, non supporta questo metodo.
+- [`eth_sendRawTransaction`](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction) è usato per trasmettere transazioni che sono già state firmate. Ciò significa che devi prima usare [`signTransaction(tx, private_key)`](https://docs.web3js.org/api/web3-eth-accounts/function/signTransaction), poi passare il risultato in `eth_sendRawTransaction`.
-Usando web3, l'accesso a `eth_sendRawTransaction` ha luogo chiamando la funzione [web3.eth.sendSignedTransaction](https://docs.web3js.org/api/web3-eth/function/sendSignedTransaction).
+Quando si usa web3, si accede a `eth_sendRawTransaction` chiamando la funzione [web3.eth.sendSignedTransaction](https://docs.web3js.org/api/web3-eth/function/sendSignedTransaction).
-Questo è ciò che useremo nel nostro tutorial.
+Questo è ciò che useremo in questa guida.
-### 6\. Cos'è la libreria di web3? {#what-is-the-web3-library}
+### 6. Cos'è la libreria web3? {#what-is-the-web3-library}
-- Web3.js è una libreria di wrapper basata sulle chiamate JSON RPC standard, utilizzata abbastanza comunemente nello sviluppo di Ethereum.
-- Esistono molte librerie web3 per diversi linguaggi. In questo tutorial useremo [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), scritto in JavaScript. Puoi consultare altre opzioni [qui](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries), come [ethers.js](https://docs.ethers.org/v5/).
+- Web3.js è una libreria wrapper basata sulle chiamate JSON RPC standard, utilizzata abbastanza comunemente nello sviluppo di Ethereum.
+- Esistono molte librerie web3 per diversi linguaggi. In questa guida useremo [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), che è scritto in JavaScript. Puoi consultare altre opzioni [qui](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries), come [ethers.js](https://docs.ethers.org/v5/).
-Okay, ora che ci siamo tolti alcune di queste domande, passiamo al tutorial. Sentiti libero di fare domande in qualsiasi momento su [Discord](https://discord.gg/gWuC7zB) di Alchemy!
+Ok, ora che abbiamo chiarito alcune di queste domande, passiamo alla guida. Sentiti libero di fare domande in qualsiasi momento nel [discord](https://discord.gg/gWuC7zB) di Alchemy!
-### 7\. Come inviare transazioni sicure, ottimizzate a livello di gas e private? {#how-to-send-secure-gas-optimized-and-private-transactions}
+### 7. Come inviare transazioni sicure, ottimizzate per il gas e private? {#how-to-send-secure-gas-optimized-and-private-transactions}
-- [Alchemy ha una suite di API di Transact](https://docs.alchemy.com/reference/transact-api-quickstart). Puoi utilizzarle per inviare delle transazioni reinforzate, simulare le transazioni prima che si verifichino, inviare transazioni private e inviare transazioni ottimizzate a livello di gas
-- Inoltre, puoi utilizzare l'[API di Notify](https://docs.alchemy.com/docs/alchemy-notify) per essere avvisato quando la tua transazione è prelevata dal mempool ed è aggiunta alla catena
+- [Alchemy ha una suite di API Transact](https://docs.alchemy.com/reference/transact-api-quickstart). Puoi usarle per inviare transazioni rinforzate, simulare transazioni prima che avvengano, inviare transazioni private e inviare transazioni ottimizzate per il gas.
+- Puoi anche usare l'[API Notify](https://docs.alchemy.com/docs/alchemy-notify) per essere avvisato quando la tua transazione viene estratta dalla mempool e aggiunta alla catena.
-**NOTA:** Questa guida richiede un conto di Alchemy, un indirizzo di Ethereum o un portafoglio di Metamask, NodeJS e npm installato. Altrimenti, segui questi passaggi:
+**NOTA:** questa guida richiede un account Alchemy, un indirizzo Ethereum o un portafoglio MetaMask e l'installazione di NodeJs e npm. In caso contrario, segui questi passaggi:
-1. [Crea un conto gratuito di Alchemy](https://auth.alchemyapi.io/signup)
-2. [Crea un conto di MetaMask](https://metamask.io/) (od ottieni un indirizzo di Ethereum)
-3. [Segui questi passaggi per installare NodeJs e NPM](https://docs.alchemy.com/alchemy/guides/alchemy-for-macs)
+1. [Crea un account Alchemy gratuito](https://auth.alchemyapi.io/signup)
+2. [Crea un account MetaMask](https://metamask.io/) (o ottieni un indirizzo Ethereum)
+3. [Segui questi passaggi per installare NodeJs e NPM](https://docs.alchemy.com/alchemy/guides/alchemy-for-macs)
-## Fasi per inviare la tua transazione {#steps-to-sending-your-transaction}
+## Passaggi per inviare la tua transazione {#steps-to-sending-your-transaction}
-### 1\. Crea un'app di Alchemy sulla rete di prova di Sepolia {#create-an-alchemy-app-on-the-sepolia-testnet}
+### 1. Creare un'app Alchemy sulla rete di test Sepolia {#create-an-alchemy-app-on-the-sepolia-testnet}
-Accedi al tuo [pannello di controllo di Alchemy](https://dashboard.alchemyapi.io/) e crea una nuova app, scegliendo Sepolia (o qualsiasi altra rete di prova) per la tua rete.
+Vai al tuo [Pannello di controllo di Alchemy](https://dashboard.alchemyapi.io/) e crea una nuova app, scegliendo Sepolia (o qualsiasi altra rete di test) come rete.
-### 2\. Richiedere ETH dal faucet di Sepolia {#request-eth-from-sepolia-faucet}
+### 2. Richiedere ETH dal faucet di Sepolia {#request-eth-from-sepolia-faucet}
-Segui le istruzioni sul [faucet di Sepolia di Alchemy](https://www.sepoliafaucet.com/) per ricevere gli ETH. Assicurati di includere il tuo indirizzo di Ethereum di **Sepolia** (da MetaMask) e non di un'altra rete. Dopo aver seguito le istruzioni, ricontrolla di aver ricevuto gli ETH nel tuo portafoglio.
+Segui le istruzioni sul [faucet di Sepolia di Alchemy](https://www.sepoliafaucet.com/) per ricevere ETH. Assicurati di includere il tuo indirizzo Ethereum di **Sepolia** (da MetaMask) e non quello di un'altra rete. Dopo aver seguito le istruzioni, ricontrolla di aver ricevuto gli ETH nel tuo portafoglio.
-### 3\. Crea la cartella di un nuovo progetto e `cd` al suo interno {#create-a-new-project-direction}
+### 3. Creare una nuova directory di progetto ed entrarvi con `cd` {#create-a-new-project-direction}
-Crea una nuova cartella del progetto dalla riga di comando (terminale per mac) e naviga al suo interno:
+Crea una nuova directory di progetto dalla riga di comando (terminale per Mac) e naviga al suo interno:
```
mkdir sendtx-example
cd sendtx-example
```
-### 4\. Installa Alchemy Web3 (o altra libreria di web3) {#install-alchemy-web3}
+### 4. Installare Alchemy Web3 (o qualsiasi libreria web3) {#install-alchemy-web3}
-Esegui il seguente comando nella cartella del tuo progetto per installare [Alchemy Web3](https://docs.alchemy.com/reference/api-overview):
+Esegui il seguente comando nella tua directory di progetto per installare [Alchemy Web3](https://docs.alchemy.com/reference/api-overview):
-Nota che per utilizzare la libreria di ethers.js, [devi seguire le istruzioni qui](https://docs.alchemy.com/docs/how-to-send-transactions-on-ethereum).
+Nota: se desideri utilizzare la libreria ethers.js, [segui le istruzioni qui](https://docs.alchemy.com/docs/how-to-send-transactions-on-ethereum).
```
npm install @alch/alchemy-web3
```
-### 5\. Installa dotenv {#install-dotenv}
+### 5. Installare dotenv {#install-dotenv}
Useremo un file `.env` per memorizzare in sicurezza la nostra chiave API e la chiave privata.
@@ -106,12 +103,12 @@ Useremo un file `.env` per memorizzare in sicurezza la nostra chiave API e la ch
npm install dotenv --save
```
-### 6\. Crea il file `.env` {#create-the-dotenv-file}
+### 6. Creare il file `.env` {#create-the-dotenv-file}
-Crea un file `.env` nella cartella del tuo progetto e aggiungi quanto segue (sostituendo "`your-api-url`" e "`your-private-key`")
+Crea un file `.env` nella tua directory di progetto e aggiungi quanto segue (sostituendo "`your-api-url`" e "`your-private-key`")
-- Per trovare l'URL della tua API di Alchemy, accedi alla pagina dei dettagli dell'app che hai appena creato sul tuo pannello di controllo, clicca "Visualizza chiave" nell'angolo in alto a destra e individua l'URL HTTP.
-- Per trovare la tua chiave privata usando MetaMask, dai un'occhiata a questa [guida](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key).
+- Per trovare il tuo URL dell'API di Alchemy, vai alla pagina dei dettagli dell'app che hai appena creato sul tuo pannello di controllo, fai clic su "View Key" in alto a destra e prendi l'URL HTTP.
+- Per trovare la tua chiave privata usando MetaMask, consulta questa [guida](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key).
```
API_URL = "your-api-url"
@@ -121,16 +118,16 @@ PRIVATE_KEY = "your-private-key"
-Non eseguire il commit di .env! Sei pregato di assicurarti di non condividere o esporre mai il tuo file .env con nessuno, poiché così facendo comprometteresti i tuoi segreti. Se stai usando il controllo della versione, aggiungi il tuo .env a un file gitignore.
+Non eseguire il commit di .env! Assicurati di non condividere o esporre mai il tuo file .env a nessuno, poiché così facendo comprometteresti i tuoi segreti. Se stai usando un sistema di controllo di versione, aggiungi il tuo file .env a un file .gitignore.
-### 7\. Crea il file `sendTx.js` {#create-sendtx-js}
+### 7. Creare il file `sendTx.js` {#create-sendtx-js}
-Ottimo, ora che abbiamo protetto i nostri dati sensibili in un file `.env`, iniziamo a programmare. Per il nostro esempio di invio transazione, rinvieremo gli ETH al faucet di Sepolia.
+Ottimo, ora che abbiamo protetto i nostri dati sensibili in un file .env, iniziamo a programmare. Per il nostro esempio di invio di transazione, invieremo ETH al faucet di Sepolia.
-Creare un file `sendTx.js`, dove configureremo e invieremo la nostra transazione d'esempio e aggiungere a esso le seguenti righe di codice:
+Crea un file `sendTx.js`, dove configureremo e invieremo la nostra transazione d'esempio, e aggiungi le seguenti righe di codice:
```
async function main() {
@@ -138,25 +135,25 @@ async function main() {
const { API_URL, PRIVATE_KEY } = process.env;
const { createAlchemyWeb3 } = require("@alch/alchemy-web3");
const web3 = createAlchemyWeb3(API_URL);
- const myAddress = '0x610Ae88399fc1687FA7530Aac28eC2539c7d6d63' //TODO: replace this address with your own public address
+ const myAddress = '0x610Ae88399fc1687FA7530Aac28eC2539c7d6d63' //TODO: sostituisci questo indirizzo con il tuo indirizzo pubblico
- const nonce = await web3.eth.getTransactionCount(myAddress, 'latest'); // nonce starts counting from 0
+ const nonce = await web3.eth.getTransactionCount(myAddress, 'latest'); // il nonce parte da 0
const transaction = {
- 'to': '0x31B98D14007bDEe637298086988A0bBd31184523', // faucet address to return eth
+ 'to': '0x31B98D14007bDEe637298086988A0bBd31184523', // indirizzo del faucet per restituire l'ETH
'value': 1000000000000000000, // 1 ETH
'gas': 30000,
'nonce': nonce,
- // optional data field to send message or execute smart contract
+ // campo dati facoltativo per inviare un messaggio o eseguire uno smart contract
};
const signedTx = await web3.eth.accounts.signTransaction(transaction, PRIVATE_KEY);
web3.eth.sendSignedTransaction(signedTx.rawTransaction, function(error, hash) {
if (!error) {
- console.log("🎉 The hash of your transaction is: ", hash, "\n Check Alchemy's Mempool to view the status of your transaction!");
+ console.log("🎉 L'hash della tua transazione è: ", hash, "\n Controlla la Mempool di Alchemy per visualizzare lo stato della tua transazione!");
} else {
- console.log("❗Something went wrong while submitting your transaction:", error)
+ console.log("❗Si è verificato un errore durante l'invio della transazione:", error)
}
});
}
@@ -166,45 +163,46 @@ main();
Assicurati di sostituire l'indirizzo alla **riga 6** con il tuo indirizzo pubblico.
-Prima di passare all'esecuzione di questo codice, vediamo alcuni di questi componenti.
+Ora, prima di passare all'esecuzione di questo codice, parliamo di alcuni dei suoi componenti.
-- `nonce`: La specifica nonce è usata per tenere traccia del numero di transazioni inviate dal tuo indirizzo. Ci serve per motivi di sicurezza e per prevenire gli [attacchi di riproduzione](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce). Per ottenere il numero di transazioni inviate dal tuo indirizzo, usiamo [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount).
-- `transaction`: L'oggetto transazione ha alcuni aspetti che dobbiamo specificare
- - `to`: Questo è l'indirizzo a cui vogliamo inviare ETH. In questo caso, stiamo rinviando degli ETH al [faucet di Sepolia](https://sepoliafaucet.com/), da cui li avevamo inizialmente richiesti.
- - `value`: Questo è l'importo che desideriamo inviare, specificato in Wei, dove 10^18 Wei = 1 ETH
- - `gas`: Esistono molti modi per determinare il giusto importo di gas da includere con la tua transazione. Alchemy ha persino un [webhook dei prezzi del gas](https://docs.alchemyapi.io/guides/alchemy-notify#address-activity-1), per notificarti quando il prezzo del gas ricade entro una certa soglia. Per le transazioni di Mainnet, è buona pratica controllare uno strumento di stima del gas come [ETH Gas Station](https://ethgasstation.info/) per determinare il giusto importo di gas da includere. 21.000 è l'importo minimo di gas che un'operazione su Ethereum adopererà, quindi, per assicurarci che la nostra transazione sarà eseguita, inseriamo qui 30.000.
- - `nonce`: vedi sopra la definizione di nonce. Nonce inizia a contare da zero.
- - [OPTIONAL] dati: serve per inviare informazioni aggiuntive con il tuo trasferimento, o per chiamare un contratto intelligente, non serve per i trasferimenti di saldo; guarda la nota più avanti.
-- `signedTx`: Per firmare il nostro oggetto di transazione, useremo il metodo `signTransaction` con la nostra `PRIVATE_KEY`
-- `sendSignedTransaction`: Una volta che abbiamo una transazione firmata, possiamo inviarla per includerla in un blocco successivo usando `sendSignedTransaction`
+- `nonce`: la specifica del nonce è usata per tenere traccia del numero di transazioni inviate dal tuo indirizzo. Ne abbiamo bisogno per motivi di sicurezza e per prevenire i [replay attack](https://docs.alchemyapi.io/resources/blockchain-glossary#account-nonce). Per ottenere il numero di transazioni inviate dal tuo indirizzo, usiamo [getTransactionCount](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc#eth_gettransactioncount).
+- `transaction`: l'oggetto della transazione ha alcuni aspetti che dobbiamo specificare
+ - `to`: questo è l'indirizzo a cui vogliamo inviare ETH. In questo caso, stiamo rinviando ETH al [faucet di Sepolia](https://sepoliafaucet.com/) da cui li avevamo inizialmente richiesti.
+ - `value`: questo è l'importo che desideriamo inviare, specificato in Wei dove 10^18 Wei = 1 ETH
+ - `gas`: esistono molti modi per determinare la giusta quantità di gas da includere nella transazione. Alchemy ha anche un [webhook per il prezzo del gas](https://docs.alchemyapi.io/guides/alchemy-notify#address-activity-1) per avvisarti quando il prezzo del gas scende al di sotto di una certa soglia. Per le transazioni sulla Rete Principale, è buona norma controllare uno stimatore di gas come [ETH Gas Station](https://ethgasstation.info/) per determinare la giusta quantità di gas da includere. 21000 è la quantità minima di gas che un'operazione su Ethereum utilizzerà, quindi, per garantire che la nostra transazione venga eseguita, qui inseriamo 30000.
+ - `nonce`: vedi sopra la definizione di nonce. Il nonce inizia a contare da zero.
+ - [FACOLTATIVO] dati: usato per inviare informazioni aggiuntive con il tuo trasferimento, o per chiamare uno smart contract; non è richiesto per i trasferimenti di saldo, controlla la nota qui sotto.
+- `signedTx`: per firmare il nostro oggetto di transazione, useremo il metodo `signTransaction` con la nostra `PRIVATE_KEY`
+- `sendSignedTransaction`: una volta che abbiamo una transazione firmata, possiamo inviarla per includerla in un blocco successivo usando `sendSignedTransaction`
-**Una Nota sui dati** Esistono due tipi principali di transazioni che è possibile inviare su Ethereum.
+**Una nota sui dati**
+Ci sono due tipi principali di transazioni che possono essere inviate in Ethereum.
-- Trasferimento del saldo: Invia ETH da un indirizzo a un altro. Non serve nessun campo di dati, ma se vuoi inviare ulteriori informazioni insieme alla tua transazione, puoi inserire queste informazioni nel formato HEX in questo campo.
- - Ad esempio, ipotizziamo di voler scrivere l'hash di un documento IPFS per la catena di Ethereum per dargli una marca oraria immutabile. Il campo dei nostri dati dovrebbe essere così: dati: `web3.utils.toHex(‘IPFS hash‘)`. Ora tutti possono interrogare la catena e vedere quando quel documento è stato aggiunto.
-- Transazione del contratto intelligente: esegui il codice di qualche contratto intelligente sulla catena. In questo caso, il campo di dati dovrebbe contenere la funzione intelligente che vorresti eseguire, insieme a eventuali parametri.
- - Per un esempio pratico, dai un'occhiata alla fase 8 in questo [Tutorial Hello World](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#step-8-create-the-transaction).
+- Trasferimento di saldo: invia ETH da un indirizzo a un altro. Nessun campo dati richiesto; tuttavia, se desideri inviare informazioni aggiuntive insieme alla transazione, puoi includere tali informazioni in formato HEX in questo campo.
+ - Ad esempio, supponiamo di voler scrivere l'hash di un documento IPFS sulla catena di Ethereum per dargli una marca temporale immutabile. Il nostro campo dati dovrebbe quindi assomigliare a: `web3.utils.toHex('hash IPFS')`. E ora chiunque può interrogare la catena e vedere quando quel documento è stato aggiunto.
+- Transazione di smart contract: esegui del codice di uno smart contract sulla catena. In questo caso, il campo dati dovrebbe contenere la funzione dello smart contract che desideri eseguire, insieme a eventuali parametri.
+ - Per un esempio pratico, consulta il Passaggio 8 di questa [Guida Hello World](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#step-8-create-the-transaction).
-### 8\. Esegui il codice usando `node sendTx.js` {#run-the-code-using-node-sendtx-js}
+### 8. Eseguire il codice usando `node sendTx.js` {#run-the-code-using-node-sendtx-js}
-Torna al terminale o alla riga di comando ed esegui:
+Torna al tuo terminale o alla riga di comando ed esegui:
```
node sendTx.js
```
-### 9\. Visualizza la tua transazione nel Mempool {#see-your-transaction-in-the-mempool}
+### 9. Visualizzare la tua transazione nella Mempool {#see-your-transaction-in-the-mempool}
-Apri la [pagina del Mempool](https://dashboard.alchemyapi.io/mempool) nel tuo pannello di controllo di Alchemy e filtra per l'app che hai creato per trovare la tua transazione. Qui possiamo visualizzare la transizione della nostra transazione dallo stato in sospeso allo stato minato (se andata a buon fine) o allo stato abbandonato (se non riuscita). Assicurati di mantenerlo su "Tutti" così da intercettare le transazioni "minate", "in sospeso" e "abbandonate". Puoi anche cercare la tua transazione tra le transazioni inviate all'indirizzo `0x31b98d14007bdee637298086988a0bbd31184523` .
+Apri la [pagina della Mempool](https://dashboard.alchemyapi.io/mempool) nel tuo pannello di controllo di Alchemy e filtra per l'app che hai creato per trovare la tua transazione. Qui possiamo osservare la transizione della nostra transazione dallo stato in sospeso allo stato minato (se riuscita) o allo stato scartato in caso di insuccesso. Assicurati di mantenerlo su "All" in modo da catturare le transazioni "mined", "pending" e "dropped". Puoi anche cercare la tua transazione cercando le transazioni inviate all'indirizzo `0x31b98d14007bdee637298086988a0bbd31184523`.
-Per visualizzare i dettagli della tua transazione, una volta trovata, seleziona l'hash tx, che dovrebbe portarti a una vista simile a questa:
+Per visualizzare i dettagli della tua transazione una volta trovata, seleziona l'hash tx, che dovrebbe portarti a una visualizzazione come questa:
-
+
-Da qui puoi visualizzare la tua transazione su Etherscan, cliccando sull'icona cerchiata in rosso!
+Da lì puoi visualizzare la tua transazione su Etherscan facendo clic sull'icona cerchiata in rosso!
-**Evviva! Hai appena inviato la tua prima transazione di Ethereum usando Alchemy**
+**Evviva!** Hai appena inviato la tua prima transazione Ethereum usando Alchemy 🎉\*\*
-_Per feedback e suggerimenti su questa guida, puoi scrivere a Elan su [Discord](https://discord.gg/A39JVCM) di Alchemy!_
+_Per feedback e suggerimenti su questa guida, invia un messaggio a Elan sul [Discord](https://discord.gg/A39JVCM) di Alchemy!_
-_Originariamente pubblicato su [https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy](https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy)_
+_Pubblicato originariamente su [https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy](https://docs.alchemyapi.io/tutorials/sending-transactions-using-web3-and-alchemy)_
diff --git a/public/content/translations/it/developers/tutorials/server-components/index.md b/public/content/translations/it/developers/tutorials/server-components/index.md
new file mode 100644
index 00000000000..7eb59107200
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/server-components/index.md
@@ -0,0 +1,295 @@
+---
+title: "Componenti server e agenti per app web3"
+description: "Dopo aver letto questo tutorial, sarai in grado di scrivere server TypeScript che ascoltano gli eventi su una blockchain e rispondono di conseguenza con le proprie transazioni. Questo ti consentirà di scrivere applicazioni centralizzate (poiché il server è un punto di errore), ma che possono interagire con le entità web3. Le stesse tecniche possono essere usate anche per scrivere un agente che risponda agli eventi sulla catena senza l'intervento di un essere umano."
+
+author: Ori Pomerantz
+lang: it
+tags: [ "agente", "server", "offchain" ]
+skill: beginner
+published: 2024-07-15
+---
+
+## Introduzione {#introduction}
+
+Nella maggior parte dei casi, un'app decentralizzata utilizza un server per distribuire il software, ma tutta l'interazione effettiva avviene tra il client (in genere un browser web) e la blockchain.
+
+
+
+Tuttavia, ci sono alcuni casi in cui un'applicazione trarrebbe vantaggio dall'avere un componente server che viene eseguito in modo indipendente. Un server di questo tipo sarebbe in grado di rispondere agli eventi e alle richieste provenienti da altre fonti, come un'API, emettendo transazioni.
+
+
+
+Ci sono diversi compiti possibili che un server di questo tipo potrebbe svolgere.
+
+- Detentore di stato segreto. Nei giochi è spesso utile non rendere disponibili ai giocatori tutte le informazioni che il gioco conosce. Tuttavia, _non ci sono segreti sulla blockchain_, qualsiasi informazione che si trova sulla blockchain è facile da scoprire per chiunque. Pertanto, se una parte dello stato del gioco deve essere mantenuta segreta, deve essere memorizzata altrove (e possibilmente gli effetti di quello stato devono essere verificati usando le [prove a conoscenza-zero](/zero-knowledge-proofs)).
+
+- Oracolo centralizzato. Se la posta in gioco è sufficientemente bassa, un server esterno che legge alcune informazioni online e poi le pubblica sulla catena può essere sufficiente per essere utilizzato come [oracolo](/developers/docs/oracles/).
+
+- Agente. Nulla accade sulla blockchain senza una transazione che lo attivi. Un server può agire per conto di un utente per eseguire azioni come l'[arbitraggio](/developers/docs/mev/#mev-examples-dex-arbitrage) quando se ne presenta l'opportunità.
+
+## Programma di esempio {#sample-program}
+
+Puoi vedere un server di esempio [su GitHub](https://github.com/qbzzt/20240715-server-component). Questo server ascolta gli eventi provenienti da [questo contratto](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=contract_code), una versione modificata del Greeter di Hardhat. Quando il saluto viene cambiato, lo ripristina.
+
+Per eseguirlo:
+
+1. Clona il repository.
+
+ ```sh copy
+ git clone https://github.com/qbzzt/20240715-server-component.git
+ cd 20240715-server-component
+ ```
+
+2. Installa i pacchetti necessari. Se non lo hai già, [installa prima Node](https://nodejs.org/en/download/package-manager).
+
+ ```sh copy
+ npm install
+ ```
+
+3. Modifica `.env` per specificare la chiave privata di un account che ha ETH sulla rete di test Holesky. Se non hai ETH su Holesky, puoi [usare questo faucet](https://holesky-faucet.pk910.de/).
+
+ ```sh filename=".env" copy
+ PRIVATE_KEY=0x
+ ```
+
+4. Avvia il server.
+
+ ```sh copy
+ npm start
+ ```
+
+5. Vai su [un esploratore di blocchi](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract) e, usando un indirizzo diverso da quello che ha la chiave privata, modifica il saluto. Verifica che il saluto venga ripristinato automaticamente.
+
+### Come funziona? {#how-it-works}
+
+Il modo più semplice per capire come scrivere un componente server è esaminare l'esempio riga per riga.
+
+#### `src/app.ts` {#src-app-ts}
+
+La stragrande maggioranza del programma è contenuta in [`src/app.ts`](https://github.com/qbzzt/20240715-server-component/blob/main/src/app.ts).
+
+##### Creazione degli oggetti prerequisiti
+
+```typescript
+import {
+ createPublicClient,
+ createWalletClient,
+ getContract,
+ http,
+ Address,
+} from "viem"
+```
+
+Queste sono le entità di [Viem](https://viem.sh/) di cui abbiamo bisogno, le funzioni e [il tipo `Address`](https://viem.sh/docs/glossary/types#address). Questo server è scritto in [TypeScript](https://www.typescriptlang.org/), un'estensione di JavaScript che lo rende [fortemente tipizzato](https://en.wikipedia.org/wiki/Strong_and_weak_typing).
+
+```typescript
+import { privateKeyToAccount } from "viem/accounts"
+```
+
+[Questa funzione](https://viem.sh/docs/accounts/privateKey) ci permette di generare le informazioni del portafoglio, incluso l'indirizzo, corrispondenti a una chiave privata.
+
+```typescript
+import { holesky } from "viem/chains"
+```
+
+Per usare una blockchain in Viem è necessario importarne la definizione. In questo caso, vogliamo connetterci alla blockchain di test [Holesky](https://github.com/eth-clients/holesky).
+
+```typescript
+// Questo è il modo in cui aggiungiamo le definizioni in .env a process.env.
+import * as dotenv from "dotenv"
+dotenv.config()
+```
+
+Questo è il modo in cui leggiamo `.env` nell'ambiente. Ne abbiamo bisogno per la chiave privata (vedi più avanti).
+
+```typescript
+const greeterAddress : Address = "0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6"
+const greeterABI = [
+ {
+ "inputs": [
+ {
+ "internalType": "string",
+ "name": "_greeting",
+ "type": "string"
+ }
+ ],
+ "stateMutability": "nonpayable",
+ "type": "constructor"
+ },
+ .
+ .
+ .
+ {
+ "inputs": [
+ {
+ "internalType": "string",
+ "name": "_greeting",
+ "type": "string"
+ }
+ ],
+ "name": "setGreeting",
+ "outputs": [],
+ "stateMutability": "nonpayable",
+ "type": "function"
+ }
+] as const
+```
+
+Per usare un contratto abbiamo bisogno del suo indirizzo e della sua [ABI](/glossary/#abi). Qui li forniamo entrambi.
+
+In JavaScript (e quindi in TypeScript) non è possibile assegnare un nuovo valore a una costante, ma è _possibile_ modificare l'oggetto che vi è memorizzato. Usando il suffisso `as const` stiamo dicendo a TypeScript che la lista stessa è costante e non può essere modificata.
+
+```typescript
+const publicClient = createPublicClient({
+ chain: holesky,
+ transport: http(),
+})
+```
+
+Creare un [client pubblico](https://viem.sh/docs/clients/public.html) Viem. I client pubblici non hanno una chiave privata associata e quindi non possono inviare transazioni. Possono chiamare le [funzioni `view`](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm), leggere i saldi dei conti, ecc.
+
+```typescript
+const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`)
+```
+
+Le variabili d'ambiente sono disponibili in [`process.env`](https://www.totaltypescript.com/how-to-strongly-type-process-env). Tuttavia, TypeScript è fortemente tipizzato. Una variabile d'ambiente può essere una stringa qualsiasi o vuota, quindi il tipo per una variabile d'ambiente è `string | undefined`. Tuttavia, una chiave è definita in Viem come `0x${string}` (`0x` seguito da una stringa). Qui diciamo a TypeScript che la variabile d'ambiente `PRIVATE_KEY` sarà di quel tipo. In caso contrario, otterremo un errore di runtime.
+
+La funzione [`privateKeyToAccount`](https://viem.sh/docs/accounts/privateKey) utilizza quindi questa chiave privata per creare un oggetto account completo.
+
+```typescript
+const walletClient = createWalletClient({
+ account,
+ chain: holesky,
+ transport: http(),
+})
+```
+
+Successivamente, usiamo l'oggetto account per creare un [client portafoglio](https://viem.sh/docs/clients/wallet). Questo client ha una chiave privata e un indirizzo, quindi può essere utilizzato per inviare transazioni.
+
+```typescript
+const greeter = getContract({
+ address: greeterAddress,
+ abi: greeterABI,
+ client: { public: publicClient, wallet: walletClient },
+})
+```
+
+Ora che abbiamo tutti i prerequisiti, possiamo finalmente creare un'[istanza di contratto](https://viem.sh/docs/contract/getContract). Useremo questa istanza di contratto per comunicare con il contratto sulla catena.
+
+##### Leggere dalla blockchain
+
+```typescript
+console.log(`Current greeting:`, await greeter.read.greet())
+```
+
+Le funzioni del contratto che sono di sola lettura ([`view`](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm) e [`pure`](https://www.tutorialspoint.com/solidity/solidity_pure_functions.htm)) sono disponibili sotto `read`. In questo caso, la usiamo per accedere alla funzione [`greet`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=read_contract#cfae3217), che restituisce il saluto.
+
+JavaScript è single-threaded, quindi quando avviamo un processo a lunga esecuzione dobbiamo [specificare che lo facciamo in modo asincrono](https://eloquentjavascript.net/11_async.html#h-XvLsfAhtsE). Chiamare la blockchain, anche per un'operazione di sola lettura, richiede un round-trip tra il computer e un nodo della blockchain. Questo è il motivo per cui qui specifichiamo che il codice deve attendere (`await`) il risultato.
+
+Se sei interessato a come funziona, puoi [leggere qui](https://www.w3schools.com/js/js_promise.asp), ma in termini pratici tutto ciò che devi sapere è che devi attendere (`await`) i risultati se avvii un'operazione che richiede molto tempo e che qualsiasi funzione che lo faccia deve essere dichiarata come `async`.
+
+##### Emissione di transazioni
+
+```typescript
+const setGreeting = async (greeting: string): Promise => {
+```
+
+Questa è la funzione che chiami per emettere una transazione che cambia il saluto. Poiché si tratta di un'operazione lunga, la funzione è dichiarata come `async`. A causa dell'implementazione interna, qualsiasi funzione `async` deve restituire un oggetto `Promise`. In questo caso, `Promise` significa che non specifichiamo cosa verrà esattamente restituito nella `Promise`.
+
+```typescript
+const txHash = await greeter.write.setGreeting([greeting])
+```
+
+Il campo `write` dell'istanza del contratto ha tutte le funzioni che scrivono sullo stato della blockchain (quelle che richiedono l'invio di una transazione), come [`setGreeting`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=write_contract#a4136862). I parametri, se presenti, sono forniti come una lista e la funzione restituisce l'hash della transazione.
+
+```typescript
+ console.log(`Working on a fix, see https://eth-holesky.blockscout.com/tx/${txHash}`)
+
+ return txHash
+}
+```
+
+Riporta l'hash della transazione (come parte di un URL all'esploratore di blocchi per visualizzarlo) e restituiscilo.
+
+##### Rispondere agli eventi
+
+```typescript
+greeter.watchEvent.SetGreeting({
+```
+
+[La funzione `watchEvent`](https://viem.sh/docs/actions/public/watchEvent) consente di specificare che una funzione deve essere eseguita quando viene emesso un evento. Se ti interessa solo un tipo di evento (in questo caso, `SetGreeting`), puoi usare questa sintassi per limitarti a quel tipo di evento.
+
+```typescript
+ onLogs: logs => {
+```
+
+La funzione `onLogs` viene chiamata quando ci sono voci di registro. In Ethereum "log" ed "evento" sono solitamente intercambiabili.
+
+```typescript
+console.log(
+ `Address ${logs[0].args.sender} changed the greeting to ${logs[0].args.greeting}`
+)
+```
+
+Potrebbero esserci più eventi, ma per semplicità ci interessa solo il primo. `logs[0].args` sono gli argomenti dell'evento, in questo caso `sender` e `greeting`.
+
+```typescript
+ if (logs[0].args.sender != account.address)
+ setGreeting(`${account.address} insists on it being Hello!`)
+ }
+})
+```
+
+Se il mittente _non_ è questo server, usa `setGreeting` per cambiare il saluto.
+
+#### `package.json` {#package-json}
+
+[Questo file](https://github.com/qbzzt/20240715-server-component/blob/main/package.json) controlla la configurazione di [Node.js](https://nodejs.org/en). Questo articolo spiega solo le definizioni importanti.
+
+```json
+{
+ "main": "dist/index.js",
+```
+
+Questa definizione specifica quale file JavaScript eseguire.
+
+```json
+ "scripts": {
+ "start": "tsc && node dist/app.js",
+ },
+```
+
+Gli script sono varie azioni dell'applicazione. In questo caso, l'unico che abbiamo è `start`, che compila e poi esegue il server. Il comando `tsc` fa parte del pacchetto `typescript` e compila TypeScript in JavaScript. Se vuoi eseguirlo manualmente, si trova in `node_modules/.bin`. Il secondo comando esegue il server.
+
+```json
+ "type": "module",
+```
+
+Esistono più tipi di applicazioni node JavaScript. Il tipo `module` ci consente di avere `await` nel codice di primo livello, il che è importante quando si eseguono operazioni lente (e quindi asincrone).
+
+```json
+ "devDependencies": {
+ "@types/node": "^20.14.2",
+ "typescript": "^5.4.5"
+ },
+```
+
+Questi sono pacchetti richiesti solo per lo sviluppo. Qui abbiamo bisogno di `typescript` e, poiché lo stiamo usando con Node.js, stiamo anche ottenendo i tipi per le variabili e gli oggetti di node, come `process`. [La notazione `^`](https://github.com/npm/node-semver?tab=readme-ov-file#caret-ranges-123-025-004) significa quella versione o una versione superiore che non ha modifiche che causano rotture. Vedi [qui](https://semver.org) per maggiori informazioni sul significato dei numeri di versione.
+
+```json
+ "dependencies": {
+ "dotenv": "^16.4.5",
+ "viem": "2.14.1"
+ }
+}
+```
+
+Questi sono pacchetti richiesti in fase di runtime, durante l'esecuzione di `dist/app.js`.
+
+## Conclusione {#conclusion}
+
+Il server centralizzato che abbiamo creato qui fa il suo lavoro, ovvero agire come un agente per un utente. Chiunque altro voglia che la dApp continui a funzionare e sia disposto a spendere il gas può eseguire una nuova istanza del server con il proprio indirizzo.
+
+Tuttavia, questo funziona solo quando le azioni del server centralizzato possono essere facilmente verificate. Se il server centralizzato ha informazioni di stato segrete o esegue calcoli difficili, è un'entità centralizzata di cui è necessario fidarsi per utilizzare l'applicazione, che è esattamente ciò che le blockchain cercano di evitare. In un articolo futuro ho intenzione di mostrare come utilizzare le [prove a conoscenza-zero](/zero-knowledge-proofs) per aggirare questo problema.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
diff --git a/public/content/translations/it/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md b/public/content/translations/it/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
index 79b12affdf1..fe202a934f8 100644
--- a/public/content/translations/it/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
+++ b/public/content/translations/it/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/index.md
@@ -1,10 +1,8 @@
---
title: Configura web3.js per usare la blockchain di Ethereum in JavaScript
-description: Come usare uno Smart Contract per interagire con un token utilizzando il linguaggio Solidity
+description: Impara a impostare e configurare la libreria web3.js per interagire con la blockchain di Ethereum da applicazioni JavaScript.
author: "jdourlens"
-tags:
- - "web3.js"
- - "javascript"
+tags: [ "web3.js", "javascript" ]
skill: beginner
lang: it
published: 2020-04-11
@@ -13,15 +11,15 @@ sourceUrl: https://ethereumdev.io/setup-web3js-to-use-the-ethereum-blockchain-in
address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
---
-In questo tutorial, vedremo come muovere i primi passi con [web3.js](https://web3js.readthedocs.io/) per interagire con la blockchain di Ethereum. Web3.js è utilizzabile sia in frontend che backend per leggere i dati dalla blockchain o effettuare transazioni e persino distribuire gli smart contract.
+In questa guida, vedremo come muovere i primi passi con [web3.js](https://web3js.readthedocs.io/) per interagire con la blockchain di Ethereum. Web3.js è utilizzabile sia in frontend che backend per leggere i dati dalla blockchain o effettuare transazioni e persino distribuire gli smart contract.
-Per prima cosa occorre includere web3.js nel progetto. Per usarlo in una pagina web, puoi importare la libreria direttamente usando un CDN come JSDeliver.
+Il primo passo è includere web3.js nel tuo progetto. Per usarlo in una pagina web, puoi importare la libreria direttamente usando un CDN come JSDeliver.
```html
```
-Se preferisci installare la libreria da usare nel progetto di backend o frontend che usa build, puoi usare npm:
+Se preferisci installare la libreria da usare nel tuo backend o in un progetto frontend con un processo di build, puoi installarla usando npm:
```bash
npm install web3 --save
@@ -33,13 +31,13 @@ A questo punto, per importare Web3.js in uno script Node.js o un progetto fronte
const Web3 = require("web3")
```
-Ora che hai incluso la libreria nel progetto, dobbiamo inizializzarla. Il progetto deve poter comunicare con la blockchain. Gran parte delle librerie di Ethereum comunica con un [nodo](/developers/docs/nodes-and-clients/) tramite le chiamate RPC. Per avviare il nostro provider Web3, istanzieremo un'istanza di Web3 passando per il costruttore dell'URL del provider. Se hai un nodo o un'[istanza ganache in esecuzione sul tuo computer](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/), apparirà così:
+Ora che hai incluso la libreria nel progetto, devi inizializzarla. Il tuo progetto deve poter comunicare con la blockchain. Gran parte delle librerie di Ethereum comunica con un [nodo](/developers/docs/nodes-and-clients/) tramite le chiamate RPC. Per avviare il nostro provider Web3, istanzieremo un'istanza di Web3 passando l'URL del provider al costruttore. Se hai un nodo o [un'istanza di ganache in esecuzione sul tuo computer](https://ethereumdev.io/testing-your-smart-contract-with-existing-protocols-ganache-fork/), apparirà così:
```js
const web3 = new Web3("http://localhost:8545")
```
-Se vorresti avere accesso diretto a un nodo ospitato, puoi trovare le opzioni su [nodi come servizi](/developers/docs/nodes-and-clients/nodes-as-a-service).
+Se desideri accedere direttamente a un nodo in hosting, puoi trovare delle opzioni su [nodi come servizio](/developers/docs/nodes-and-clients/nodes-as-a-service).
```js
const web3 = new Web3("https://cloudflare-eth.com")
@@ -56,7 +54,7 @@ web3.eth.getBlockNumber(function (error, result) {
})
```
-Se viene eseguito, questo programma produrrà semplicemente il numero dell'ultimo blocco: la cima della blockchain. Puoi anche usare le chiamate della funzione `await/async` per evitare di annidare delle callback nel tuo codice:
+Se esegui questo programma, stamperà semplicemente il numero dell'ultimo blocco: la cima della blockchain. Puoi anche usare le chiamate di funzione `await/async` per evitare di annidare i callback nel tuo codice:
```js
async function getBlockNumber() {
@@ -68,27 +66,27 @@ async function getBlockNumber() {
getBlockNumber()
```
-Puoi vedere tutte le funzioni disponibili sull'istanza di web3 nella [documentazione ufficiale di web3.js](https://docs.web3js.org/).
+Puoi vedere tutte le funzioni disponibili sull'istanza di Web3 nella [documentazione ufficiale di web3.js](https://docs.web3js.org/).
-Gran parte delle librerie di Web3 sono asincrone perché, in background, la libreria effettua chiamate RPC di JSON al nodo, il quale restituisce il risultato.
+La maggior parte delle librerie Web3 sono asincrone perché in background la libreria effettua chiamate JSON-RPC al nodo, che restituisce il risultato.
Se lavori nel browser, alcuni portafogli iniettano direttamente un'istanza Web3 e dovresti provare a usarla appena possibile, specialmente se prevedi di interagire con l'indirizzo di Ethereum dell'utente per effettuare le transazioni.
-Qui riportiamo il frammento che permette di rilevare se è disponibile un portafoglio di MetaMask e, in tal caso, provare ad abilitarlo. In seguito, ti consentirà di leggere il saldo dell'utente e abilitarlo per convalidare le transazioni che vorresti effettuasse sulla blockchain di Ethereum:
+Ecco lo snippet per rilevare se è disponibile un portafoglio MetaMask e provare ad abilitarlo in tal caso. In seguito, ti consentirà di leggere il saldo dell'utente e di abilitarlo a convalidare le transazioni che vorresti fargli effettuare sulla blockchain di Ethereum:
```js
if (window.ethereum != null) {
state.web3 = new Web3(window.ethereum)
try {
- // Request account access if needed
+ // Richiedi l'accesso all'account se necessario
await window.ethereum.enable()
- // Accounts now exposed
+ // Account ora esposti
} catch (error) {
- // User denied account access...
+ // L'utente ha negato l'accesso all'account...
}
}
```
-Alternative a web3.js come [Ethers.js](https://docs.ethers.io/) esistono e sono anche utilizzate comunemente. Nel prossimo tutorial vedremo [come ascoltare facilmente i nuovi blocchi in arrivo sulla blockchain e esaminarne il contenuto](https://ethereumdev.io/listening-to-new-transactions-happening-on-the-blockchain/).
+Esistono alternative a web3.js, come [Ethers.js](https://docs.ethers.io/), che sono anche di uso comune. Nella prossima guida vedremo [come mettersi facilmente in ascolto dei nuovi blocchi in arrivo sulla blockchain e vedere cosa contengono](https://ethereumdev.io/listening-to-new-transactions-happening-on-the-blockchain/).
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..59762036ac5 100644
--- a/public/content/translations/it/developers/tutorials/short-abi/index.md
+++ b/public/content/translations/it/developers/tutorials/short-abi/index.md
@@ -1,49 +1,60 @@
---
title: "ABI brevi per l'ottimizzazione dei calldata"
-description: Ottimizzare gli smart contract per i Rollup ottimistici
+description: Ottimizzare gli smart contract per i rollup ottimistici
author: Ori Pomerantz
lang: it
-tags:
- - "livello 2"
+tags: [ "livello 2" ]
skill: intermediate
published: 2022-04-01
---
## Introduzione {#introduction}
-In questo articolo conoscerai i [rollup ottimistici](/developers/docs/scaling/optimistic-rollups), il costo delle transazioni su di essi e come tale diversa struttura di costo ci imponga di ottimizzare diversi aspetti rispetto alla Rete principale di Ethereum. Imparerai anche come implementare quest'ottimizzazione.
+In questo articolo conoscerai i [rollup ottimistici](/developers/docs/scaling/optimistic-rollups), il costo delle transazioni su di essi e come tale diversa struttura di costo ci imponga di ottimizzare diversi aspetti rispetto alla Rete principale di Ethereum.
+Imparerai anche come implementare quest'ottimizzazione.
-### Divulgazione completa {#full-disclosure}
+### Dichiarazione di trasparenza {#full-disclosure}
-Sono un dipendente a tempo pieno di [Optimism](https://www.optimism.io/), quindi gli esempi in questo articolo saranno eseguiti su Optimism. Tuttavia la tecnica qui spiegata dovrebbe funzionare altrettanto bene per altri rollup.
+Sono un dipendente a tempo pieno di [Optimism](https://www.optimism.io/), quindi gli esempi in questo articolo saranno eseguiti su Optimism.
+Tuttavia, la tecnica qui spiegata dovrebbe funzionare altrettanto bene per altri rollup.
### Terminologia {#terminology}
-Parlando di rollup, il termine "livello 1" (L1) è usato per la Rete principale, la rete di produzione di Ethereum. Il termine "livello 2" (L2) è usato per il rollup o qualsiasi altro sistema che si basa sul L1 per la sicurezza ma svolge gran parte della sua elaborazione al di fuori della catena.
+Parlando di rollup, il termine "livello 1" (L1) è usato per la Rete principale, la rete di produzione di Ethereum.
+Il termine "livello 2" (L2) è usato per il rollup o qualsiasi altro sistema che si basa sul L1 per la sicurezza ma svolge gran parte della sua elaborazione fuori dalla catena.
-## Come possiamo ridurre ulteriormente il costo delle transazioni su L2? {#how-can-we-further-reduce-the-cost-of-L2-transactions}
+## Come possiamo ridurre ulteriormente il costo delle transazioni L2? {#how-can-we-further-reduce-the-cost-of-L2-transactions}
-I [Rollup ottimistici](/developers/docs/scaling/optimistic-rollups) devono conservare un registro di ogni transazione storica, così che chiunque possa consultarlo e verificare che lo stato corrente sia corretto. Il metodo più economico per inserire dati nella Rete principale di Ethereum è scriverli come calldata. Questa soluzione è stata scelta sia da [Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-) che da [Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups).
+I [rollup ottimistici](/developers/docs/scaling/optimistic-rollups) devono conservare un registro di ogni transazione storica, così che chiunque possa consultarlo e verificare che lo stato corrente sia corretto.
+Il metodo più economico per inserire dati nella Rete principale di Ethereum è scriverli come calldata.
+Questa soluzione è stata scelta sia da [Optimism](https://help.optimism.io/hc/en-us/articles/4413163242779-What-is-a-rollup-) che da [Arbitrum](https://developer.offchainlabs.com/docs/rollup_basics#intro-to-rollups).
-### Costo delle transazioni su L2 {#cost-of-l2-transactions}
+### Costo delle transazioni L2 {#cost-of-l2-transactions}
-Il costo delle transazioni su L2 ha due componenti:
+Il costo delle transazioni L2 ha due componenti:
1. Elaborazione su L2, solitamente estremamente economica
2. Archiviazione sul L1, legata ai costi del gas della Rete Principale
-Al momento della redazione, su Optimism il costo del gas del L2 è 0,001 [Gwei](/developers/docs/gas/#pre-london). Il costo del gas del L1, d'altra parte, è approssimativamente di 40 gwei. [Puoi visualizzare i prezzi correnti qui](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m).
+Al momento della stesura, su Optimism il costo del gas L2 è di 0,001 [Gwei](/developers/docs/gas/#pre-london).
+Il costo del gas del L1, d'altra parte, è approssimativamente di 40 gwei.
+[Puoi vedere i prezzi attuali qui](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m).
-Un byte di dati di chiamata costa 4 gas (se è zero) o 16 gas (se ha qualsiasi altro valore). Una delle operazioni più costose sull'EVM è scrivere in memoria. Il costo massimo della scrittura di una parola di 32 byte all'archiviazione sul L2, è di 22.100 gas. Attualmente, ciò equivale a 22,1 gwei. Quindi, se possiamo risparmiare un singolo byte zero di calldata, potremo scrivere circa 200 byte in memoria e ne usciremo comunque bene.
+Un byte di calldata costa 4 gas (se è zero) o 16 gas (se ha un qualsiasi altro valore).
+Una delle operazioni più costose sull'EVM è scrivere nell'archiviazione.
+Il costo massimo della scrittura di una parola di 32 byte nell'archiviazione su L2 è di 22.100 gas. Attualmente, ciò equivale a 22,1 gwei.
+Quindi, se possiamo risparmiare un singolo byte zero di calldata, potremo scrivere circa 200 byte in archiviazione e ne usciremo comunque avvantaggiati.
### L'ABI {#the-abi}
-La stragrande maggioranza delle transazioni, accede a un contratto da un conto posseduto esternamente. Gran parte dei contratti è scritta in Solidity e interpreta il proprio campo dei dati secondo [l'interfaccia binaria dell'applicazione (Application Binary Interface – ABI)](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding).
+La stragrande maggioranza delle transazioni, accede a un contratto da un conto posseduto esternamente.
+La maggior parte dei contratti è scritta in Solidity e interpreta il proprio campo di dati secondo [l'interfaccia binaria dell'applicazione (ABI)](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding).
-Tuttavia, l'ABI è stata progettata per il L1, dove un byte di calldata costa approssimativamente quanto quattro operazioni aritmetiche, non per il L2 dove un byte di calldata costa più di un migliaio di operazioni aritmetiche. Ad esempio, [ecco una transazione di trasferimento ERC-20](https://kovan-optimistic.etherscan.io/tx/0x7ce4c144ebfce157b4de99d8ad53a352ae91b57b3fa06d8a1c79439df6bfa998). I calldata sono divisi come segue:
+Tuttavia, l'ABI è stata progettata per il L1, dove un byte di calldata costa approssimativamente quanto quattro operazioni aritmetiche, non per il L2 dove un byte di calldata costa più di un migliaio di operazioni aritmetiche.
+I calldata sono divisi come segue:
| Sezione | Lunghezza | Byte | Byte sprecati | Gas sprecato | Byte necessari | Gas necessario |
-| ------------------------- | ---------:| -----:| -------------:| ------------:| --------------:| --------------:|
+| ------------------------- | --------: | ----: | ------------: | -----------: | -------------: | -------------: |
| Selettore della funzione | 4 | 0-3 | 3 | 48 | 1 | 16 |
| Zeri | 12 | 4-15 | 12 | 48 | 0 | 0 |
| Indirizzo di destinazione | 20 | 16-35 | 0 | 0 | 20 | 320 |
@@ -52,34 +63,44 @@ Tuttavia, l'ABI è stata progettata per il L1, dove un byte di calldata costa ap
Spiegazione:
-- **Selettore della funzione**: il contratto ha meno di 256 funzioni, quindi, possiamo distinguerle con un solo byte. Questi byte sono tipicamente diversi da zero e, dunque, [costano sedici gas](https://eips.ethereum.org/EIPS/eip-2028).
-- **Zeri**: questi byte sono sempre zero perché un indirizzo di venti byte non richiede una parola di trentadue byte. I byte contenenti zero costano quattro gas ([vedi lo yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf), Appendice G, p. 27, il valore per `G``txdatazero`).
-- **Importo**: se supponiamo che in questo contratto, `decimals` sia diciotto (il valore normale) e l'importo massimo di token che trasferiamo sarà 1018, otteniamo un importo massimo di 1036. 25615 > 1036, quindi quindici byte sono sufficienti.
+- **Selettore della funzione**: il contratto ha meno di 256 funzioni, quindi, possiamo distinguerle con un solo byte.
+ Questi byte sono tipicamente non-zero e quindi [costano sedici gas](https://eips.ethereum.org/EIPS/eip-2028).
+- **Zeri**: questi byte sono sempre zero perché un indirizzo di venti byte non richiede una parola di trentadue byte per contenerlo.
+ I byte che contengono lo zero costano quattro gas ([vedi lo yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf), Appendice G,
+ p. 27, il valore per `G``txdatazero`).
+- **Importo**: se supponiamo che in questo contratto `decimals` sia diciotto (il valore normale) e l'importo massimo di token che trasferiamo sarà 1018, otteniamo un importo massimo di 1036.
+ 25615 > 1036, quindi quindici byte sono sufficienti.
-Uno spreco di 160 gas sul L1 è di norma trascurabile. Una transazione costa almeno [21.000 gas](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed), quindi un ulteriore 0,8% non conta. Tuttavia, sul L2 le cose sono diverse. Quasi l'intero costo della transazione deriva dalla scrittura sul L1. Oltre ai calldata della transazione, ci sono 109 byte di intestazione della transazione (indirizzo di destinazione, firma, ecc.). Il costo totale è dunque `109*16+576+160=2480`, e ne stiamo sprecando circa il 6,5%.
+Uno spreco di 160 gas sul L1 è di norma trascurabile. Una transazione costa almeno [21.000 gas](https://yakkomajuri.medium.com/blockchain-definition-of-the-week-ethereum-gas-2f976af774ed), quindi uno 0,8% in più non ha importanza.
+Tuttavia, sul L2 le cose sono diverse. Quasi l'intero costo della transazione deriva dalla scrittura sul L1.
+Oltre ai calldata della transazione, ci sono 109 byte di intestazione della transazione (indirizzo di destinazione, firma, ecc.).
+Il costo totale è dunque `109*16+576+160=2480`, e ne stiamo sprecando circa il 6,5%.
## Ridurre i costi quando non controlli la destinazione {#reducing-costs-when-you-dont-control-the-destination}
-Supponendo di non avere il controllo sul contratto di destinazione, puoi comunque usare una soluzione simile a [questa](https://github.com/qbzzt/ethereum.org-20220330-shortABI). Vediamo i file pertinenti.
+Supponendo di non avere il controllo sul contratto di destinazione, puoi comunque usare una soluzione simile a [questa](https://github.com/qbzzt/ethereum.org-20220330-shortABI).
+Vediamo i file pertinenti.
### Token.sol {#token-sol}
-[Questo è il contratto di destinazione](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol). È un contratto ERC-20 standard, con una funzionalità aggiuntiva. Questa funzione `faucet` consente a qualsiasi utente di ottenere dei token da usare. Renderebbe inutile una produzione del contratto ERC-20, ma semplifica la vita quando l'ERC-20 esiste solo per facilitare i test.
+[Questo è il contratto di destinazione](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/Token.sol).
+È un contratto ERC-20 standard, con una funzionalità aggiuntiva.
+Questa funzione `faucet` consente a qualsiasi utente di ottenere dei token da usare.
+Renderebbe inutile una produzione del contratto ERC-20, ma semplifica la vita quando un ERC-20 esiste solo per facilitare i test.
```solidity
/**
- * @dev Gives the caller 1000 tokens to play with
+ * @dev Dà al chiamante 1000 token con cui giocare
*/
function faucet() external {
_mint(msg.sender, 1000);
} // function faucet
```
-[Puoi vedere un esempio di questo contratto distribuito qui](https://kovan-optimistic.etherscan.io/address/0x950c753c0edbde44a74d3793db738a318e9c8ce8).
-
### CalldataInterpreter.sol {#calldatainterpreter-sol}
-[Questo è il contratto che le transazioni dovrebbero chiamare con calldata più brevi](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol). Analizziamolo riga per riga.
+[Questo è il contratto che le transazioni dovrebbero chiamare con calldata più brevi](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/contracts/CalldataInterpreter.sol).
+Analizziamolo riga per riga.
```solidity
//SPDX-License-Identifier: Unlicense
@@ -102,8 +123,8 @@ L'indirizzo del token per cui siamo un proxy.
```solidity
/**
- * @dev Specify the token address
- * @param tokenAddr_ ERC-20 contract address
+ * @dev Specifica l'indirizzo del token
+ * @param tokenAddr_ Indirizzo del contratto ERC-20
*/
constructor(
address tokenAddr_
@@ -125,13 +146,15 @@ Leggi un valore dai calldata.
uint _retVal;
require(length < 0x21,
- "calldataVal length limit is 32 bytes");
+ "il limite di lunghezza di calldataVal è 32 byte");
require(length + startByte <= msg.data.length,
- "calldataVal trying to read beyond calldatasize");
+ "calldataVal sta tentando di leggere oltre calldatasize");
```
-Caricheremo in memoria un'unica parola da 32 byte (256 bit) e rimuoveremo i byte che non fanno parte del campo che vogliamo. Questo algoritmo non funziona per valori più lunghi di 32 byte e, ovviamente, non possiamo leggere oltre il termine dei calldata. Sul L1, potrebbe esser necessario saltare questi test per risparmiare sul gas, ma sul L2, il gas è estremamente economico, consentendo qualsiasi controllo d'integrità immaginabile.
+Caricheremo in memoria un'unica parola da 32 byte (256 bit) e rimuoveremo i byte che non fanno parte del campo che vogliamo.
+Questo algoritmo non funziona per valori più lunghi di 32 byte e, ovviamente, non possiamo leggere oltre il termine dei calldata.
+Sul L1, potrebbe esser necessario saltare questi test per risparmiare sul gas, ma sul L2, il gas è estremamente economico, consentendo qualsiasi controllo d'integrità immaginabile.
```solidity
assembly {
@@ -141,14 +164,16 @@ Caricheremo in memoria un'unica parola da 32 byte (256 bit) e rimuoveremo i byte
Potremmo aver copiato i dati dalla chiamata a `fallback()` (vedi sotto), ma è più facile usare [Yul](https://docs.soliditylang.org/en/v0.8.12/yul.html), il linguaggio assembly dell'EVM.
-Qui usiamo [l'opcode CALLDATALOAD](https://www.evm.codes/#35) per leggere i byte da `startByte` a `startByte+31` nello stack. In generale, la sintassi di un opcode su Yul è `(,...)`.
+Qui usiamo [l'opcode CALLDATALOAD](https://www.evm.codes/#35) per leggere i byte da `startByte` a `startByte+31` nello stack.
+In generale, la sintassi di un opcode in Yul è `(,...)`.
```solidity
_retVal = _retVal >> (256-length*8);
```
-Solo i byte `length` più significativi fanno parte del campo, quindi effettuiamo uno [spostamento a destra](https://en.wikipedia.org/wiki/Logical_shift) per liberarci degli altri valori. Questo ha il vantaggio aggiuntivo di spostare il valore a destra del campo, quindi è il valore stesso invece del valore moltiplicato per 256qualcosa.
+Solo i `length` byte più significativi fanno parte del campo, quindi effettuiamo uno [spostamento a destra](https://en.wikipedia.org/wiki/Logical_shift) per liberarci degli altri valori.
+Questo ha il vantaggio aggiuntivo di spostare il valore a destra del campo, quindi è il valore stesso invece del valore moltiplicato per 256qualcosa.
```solidity
@@ -159,7 +184,8 @@ Solo i byte `length` più significativi fanno parte del campo, quindi effettuiam
fallback() external {
```
-Quando una chiamata a un contratto in Solidity non corrisponde ad alcuna delle firme della funzione, chiama [la funzione `fallback()`](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) (supponendo che ne esista una). Nel caso di `CalldataInterpreter`, _qualsiasi_ chiamata arriva qui perché non vi sono altre funzioni `external` o `public`.
+Quando una chiamata a un contratto in Solidity non corrisponde ad alcuna delle firme della funzione, chiama [la funzione `fallback()`](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) (supponendo che ne esista una).
+Nel caso di `CalldataInterpreter`, _qualsiasi_ chiamata arriva qui perché non vi sono altre funzioni `external` o `public`.
```solidity
uint _func;
@@ -167,17 +193,21 @@ Quando una chiamata a un contratto in Solidity non corrisponde ad alcuna delle f
_func = calldataVal(0, 1);
```
-Leggi il primo byte dei calldata, che ci dice la funzione. Ci sono due motivi per cui una funzione potrebbe non essere disponibile qui:
+Leggi il primo byte dei calldata, che ci dice la funzione.
+Ci sono due motivi per cui una funzione potrebbe non essere disponibile qui:
-1. Le funzioni che sono `pure` o `view` non cambiano lo stato e non costano gas (quando chiamate al di fuori della catena). Non ha senso provare a ridurne il loro costo del gas.
-2. Le funzioni che si affidano a [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties). Il valore del `msg.sender` sarà l'indirizzo `CalldataInterpreter`, non il chiamante.
+1. Le funzioni che sono `pure` o `view` non cambiano lo stato e non costano gas (quando chiamate fuori dalla catena).
+ Non ha senso provare a ridurne il costo del gas.
+2. Funzioni che si basano su [`msg.sender`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#block-and-transaction-properties).
+ Il valore di `msg.sender` sarà l'indirizzo di `CalldataInterpreter`, non del chiamante.
-Sfortunatamente, [guardando alle specifiche dell'ERC-20](https://eips.ethereum.org/EIPS/eip-20), questo lascia solo una funzione: `transfer`. Questo ci lascia con soltanto due funzioni: `transfer` (poiché possiamo chiamare `transferFrom`) e `faucet` (poiché possiamo ritrasferire i token a chiunque ci abbia chiamati).
+Sfortunatamente, [guardando le specifiche ERC-20](https://eips.ethereum.org/EIPS/eip-20), questo lascia solo una funzione, `transfer`.
+Questo ci lascia con soltanto due funzioni: `transfer` (poiché possiamo chiamare `transferFrom`) e `faucet` (poiché possiamo ritrasferire i token a chiunque ci abbia chiamati).
```solidity
- // Call the state changing methods of token using
- // information from the calldata
+ // Chiama i metodi di modifica dello stato del token usando
+ // informazioni dal calldata
// faucet
if (_func == 1) {
@@ -192,10 +222,12 @@ Una chiamata a `faucet()`, priva di parametri.
}
```
-Dopo aver chiamato `token.faucet()` otteniamo i token. Tuttavia, come contratto proxy, non **necessitiamo** di token. L'EOA (conto posseduto esternamente) o il contratto che ci ha chiamati, sì. Quindi trasferiamo tutti i nostri token a chiunque ci abbia chiamati.
+Dopo aver chiamato `token.faucet()` otteniamo i token. Tuttavia, come contratto proxy, non **abbiamo bisogno di** token.
+L'EOA (conto posseduto esternamente) o il contratto che ci ha chiamati, sì.
+Quindi trasferiamo tutti i nostri token a chiunque ci abbia chiamati.
```solidity
- // transfer (assume we have an allowance for it)
+ // transfer (si presuppone di avere un'autorizzazione per questo)
if (_func == 2) {
```
@@ -212,7 +244,8 @@ Consentiamo solo ai chiamanti di trasferire i token che possiedono
address(uint160(calldataVal(1, 20))),
```
-L'indirizzo di destinazione inizia al byte #1 (il byte #0 è la funzione). Come indirizzo, è lungo 20 byte.
+L'indirizzo di destinazione inizia al byte #1 (il byte #0 è la funzione).
+Come indirizzo, è lungo 20 byte.
```solidity
calldataVal(21, 2)
@@ -225,10 +258,10 @@ Per questo contratto specifico supponiamo che il numero massimo di token che chi
}
```
-In generale, un trasferimento richiede 35 byte di calldata:
+Complessivamente, un trasferimento richiede 35 byte di calldata:
| Sezione | Lunghezza | Byte |
-| ------------------------- | ---------:| -----:|
+| ------------------------- | --------: | ----: |
| Selettore della funzione | 1 | 0 |
| Indirizzo di destinazione | 32 | 1-32 |
| Importo | 2 | 33-34 |
@@ -241,7 +274,8 @@ In generale, un trasferimento richiede 35 byte di calldata:
### test.js {#test-js}
-[Questo test unitario di JavaScript](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) ci mostra come usare questo meccanismo (e come verificare che funzioni correttamente). Partirò dal presupposto che tu comprenda [chai](https://www.chaijs.com/) ed [ether](https://docs.ethers.io/v5/) e spiegherò solo le parti che si applicano nello specifico al contratto.
+[Questo unit test in JavaScript](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) ci mostra come usare questo meccanismo (e come verificare che funzioni correttamente).
+Partirò dal presupposto che tu comprenda [chai](https://www.chaijs.com/) e [ethers](https://docs.ethers.io/v5/) e spiegherò solo le parti che si applicano nello specifico al contratto.
```js
const { expect } = require("chai");
@@ -264,11 +298,12 @@ describe("CalldataInterpreter", function () {
Iniziamo distribuendo entrambi i contratti.
```javascript
- // Get tokens to play with
+ // Otteniamo token con cui giocare
const faucetTx = {
```
-Non possiamo usare le funzioni di alto livello che useremmo normalmente (come `token.faucet()`) per creare le transazioni, perché non seguiamo l'ABI. Invece, dobbiamo costruire noi stessi la transazione e poi inviarla.
+Non possiamo usare le funzioni di alto livello che useremmo normalmente (come `token.faucet()`) per creare le transazioni, perché non seguiamo l'ABI.
+Invece, dobbiamo costruire noi stessi la transazione e poi inviarla.
```javascript
to: cdi.address,
@@ -277,8 +312,10 @@ Non possiamo usare le funzioni di alto livello che useremmo normalmente (come `t
Ci sono due parametri che dobbiamo fornire per la transazione:
-1. `to`, l'indirizzo di destinazione. Questo è il contratto dell'interprete dei calldata.
-2. `data`, i calldata da inviare. Nel caso di una chiamata al faucet, i dati sono in un singolo byte, `0x01`.
+1. `to`, l'indirizzo di destinazione.
+ Questo è il contratto dell'interprete dei calldata.
+2. `data`, i calldata da inviare.
+ Nel caso di una chiamata al faucet, i dati sono in un singolo byte, `0x01`.
```javascript
@@ -289,23 +326,24 @@ Ci sono due parametri che dobbiamo fornire per la transazione:
Chiamiamo [il metodo `sendTransaction` del firmatario](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction) perché abbiamo già specificato la destinazione (`faucetTx.to`) e ci serve che la transazione sia firmata.
```javascript
-// Check the faucet provides the tokens correctly
+// Controlla che il faucet fornisca correttamente i token
expect(await token.balanceOf(signer.address)).to.equal(1000)
```
-Qui verifichiamo il saldo. Non serve risparmiare gas sulle funzioni `view`, quindi le eseguiamo normalmente.
+Qui verifichiamo il saldo.
+Non serve risparmiare gas sulle funzioni `view`, quindi le eseguiamo normalmente.
```javascript
-// Give the CDI an allowance (approvals cannot be proxied)
+// Dai al CDI un'autorizzazione (le approvazioni non possono essere proxate)
const approveTX = await token.approve(cdi.address, 10000)
await approveTX.wait()
expect(await token.allowance(signer.address, cdi.address)).to.equal(10000)
```
-Dà all'interprete dei calldata un'indennità per poter effettuare trasferimenti.
+Dai all'interprete dei calldata un'autorizzazione per poter effettuare trasferimenti.
```javascript
-// Transfer tokens
+// Trasferisci i token
const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
const transferTx = {
to: cdi.address,
@@ -318,48 +356,45 @@ Crea una transazione di trasferimento. Il primo byte è "0x02", seguito dall'ind
```javascript
await (await signer.sendTransaction(transferTx)).wait()
- // Check that we have 256 tokens less
+ // Verifichiamo che abbiamo 256 token in meno
expect (await token.balanceOf(signer.address)).to.equal(1000-256)
- // And that our destination got them
+ // E che la nostra destinazione li ha ricevuti
expect (await token.balanceOf(destAddr)).to.equal(256)
}) // it
}) // describe
```
-### Esempio {#example}
-
-Se desideri vedere questi file in azione senza eseguirli tu stesso, segui questi link:
-
-1. [Distribuzione di`OrisUselessToken`](https://kovan-optimistic.etherscan.io/tx/1410744) all'[indirizzo `0x950c753c0edbde44a74d3793db738a318e9c8ce8`](https://kovan-optimistic.etherscan.io/address/0x950c753c0edbde44a74d3793db738a318e9c8ce8).
-2. [Distribuzione di `CalldataInterpreter`](https://kovan-optimistic.etherscan.io/tx/1410745) all'[indirizzo `0x16617fea670aefe3b9051096c0eb4aeb4b3a5f55`](https://kovan-optimistic.etherscan.io/address/0x16617fea670aefe3b9051096c0eb4aeb4b3a5f55).
-3. [Chiamata a `faucet()`](https://kovan-optimistic.etherscan.io/tx/1410746).
-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 controlli il contratto di destinazione {#reducing-the-cost-when-you-do-control-the-destination-contract}
-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 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 branch `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.
+Se il contratto rispondesse solo a transazioni esterne, potremmo cavarcela con un solo contratto.
+Tuttavia, ciò romperebbe [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}
-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:
+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:
```solidity
- // The only address allowed to specify the CalldataInterpreter address
+ // L'unico indirizzo autorizzato a specificare l'indirizzo di CalldataInterpreter
address owner;
- // The CalldataInterpreter address
+ // L'indirizzo di CalldataInterpreter
address proxy = address(0);
```
-Il contratto ERC-20 deve conoscere l'identità del proxy autorizzato. Tuttavia, non possiamo impostare questa variabile nel costruttore, perché non conosciamo ancora il valore. Questo contratto è stato istanziato subito poiché il proxy si aspetta che l'indirizzo del token sia nel suo costruttore.
+Il contratto ERC-20 deve conoscere l'identità del proxy autorizzato.
+Tuttavia, non possiamo impostare questa variabile nel costruttore, perché non conosciamo ancora il valore.
+Questo contratto è stato istanziato subito poiché il proxy si aspetta che l'indirizzo del token sia nel suo costruttore.
```solidity
/**
- * @dev Calls the ERC20 constructor.
+ * @dev Chiama il costruttore ERC20.
*/
constructor(
) ERC20("Oris useless token-2", "OUT-2") {
@@ -371,33 +406,36 @@ L'indirizzo del creatore (chiamato `owner`) è memorizzato qui perché è l'unic
```solidity
/**
- * @dev set the address for the proxy (the CalldataInterpreter).
- * Can only be called once by the owner
+ * @dev Imposta l'indirizzo per il proxy (CalldataInterpreter).
+ * Può essere chiamata solo una volta dal proprietario
*/
function setProxy(address _proxy) external {
- require(msg.sender == owner, "Can only be called by owner");
- require(proxy == address(0), "Proxy is already set");
+ require(msg.sender == owner, "Può essere chiamata solo dal proprietario");
+ require(proxy == address(0), "Proxy già impostato");
proxy = _proxy;
} // function setProxy
```
-Il proxy ha accesso privilegiato, perché può bypassare i controlli di sicurezza. Per essere certi di poterci fidare del proxy, l'unico che può chiamare questa funzione è l'`owner`, e solo una volta. Una volta che `proxy` ha un valore reale (non zero), quel valore non può cambiare, quindi anche se il proprietario diventa malevolo, o la sua mnemonica viene rivelata, siamo comunque al sicuro.
+Il proxy ha accesso privilegiato, perché può bypassare i controlli di sicurezza.
+Per essere certi di poterci fidare del proxy, lasciamo che solo `owner` chiami questa funzione, e solo una volta.
+Una volta che `proxy` ha un valore reale (non zero), quel valore non può cambiare, quindi anche se il proprietario diventa malevolo, o la sua mnemonica viene rivelata, siamo comunque al sicuro.
```solidity
/**
- * @dev Some functions may only be called by the proxy.
+ * @dev Alcune funzioni possono essere chiamate solo dal proxy.
*/
modifier onlyProxy {
```
-Questa è una [funzione `modifier`](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm), ossia modifica come funzionano le altre funzioni.
+Questa è una funzione [`modifier`](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm), modifica il modo in cui funzionano le altre funzioni.
```solidity
require(msg.sender == proxy);
```
-In primo luogo, verifica che siamo stati chiamati dal proxy e da nessun altro. Altrimenti, `revert`.
+In primo luogo, verifica che siamo stati chiamati dal proxy e da nessun altro.
+Altrimenti, `revert`.
```solidity
_;
@@ -407,7 +445,7 @@ In primo luogo, verifica che siamo stati chiamati dal proxy e da nessun altro. A
Se è così, esegui la funzione che modifichiamo.
```solidity
- /* Functions that allow the proxy to actually proxy for accounts */
+ /* Funzioni che consentono al proxy di fare effettivamente il proxy per i conti */
function transferProxy(address from, address to, uint256 amount)
public virtual onlyProxy() returns (bool)
@@ -436,17 +474,18 @@ Se è così, esegui la funzione che modifichiamo.
}
```
-Queste sono tre operazioni che normalmente richiedono che il messaggio provenga direttamente dall'entità che sta trasferendo token o approvando un'indennità. Qui abbiamo una versione del proxy di queste operazioni che:
+Queste sono tre operazioni che normalmente richiedono che il messaggio provenga direttamente dall'entità che sta trasferendo token o approvando un'autorizzazione.
+Qui abbiamo una versione del proxy di queste operazioni che:
-1. È modificata da `onlyProxy()`, così che nessun altro possa controllarla.
+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}
-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`.
+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'autorizzazione per `transfer`.
```solidity
- // transfer (no need for allowance)
+ // transfer (nessuna autorizzazione necessaria)
if (_func == 2) {
token.transferProxy(
msg.sender,
@@ -475,7 +514,7 @@ L'interprete dei dati della chiamata è praticamente identico a quello precedent
}
```
-### Test.js {#test-js-2}
+### test.js {#test-js-2}
Ci sono alcune modifiche tra il codice di test precedente e questo.
@@ -491,16 +530,17 @@ Dobbiamo dire al contratto ERC-20 di quale proxy fidarsi
```js
console.log("CalldataInterpreter addr:", cdi.address)
-// Need two signers to verify allowances
+// Servono due firmatari per verificare le autorizzazioni
const signers = await ethers.getSigners()
const signer = signers[0]
const poorSigner = signers[1]
```
-Per verificare `approve()` e `transferFrom()`, ci serve un secondo firmatario. Lo chiamiamo `poorSigner` perché non riceve nessuno dei nostri token (deve avere degli ETH, ovviamente).
+Per verificare `approve()` e `transferFrom()` ci serve un secondo firmatario.
+Lo chiamiamo `poorSigner` perché non riceve nessuno dei nostri token (deve avere degli ETH, ovviamente).
```js
-// Transfer tokens
+// Trasferisci i token
const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
const transferTx = {
to: cdi.address,
@@ -509,10 +549,10 @@ const transferTx = {
await (await signer.sendTransaction(transferTx)).wait()
```
-Poiché il contratto ERC-20 si fida del proxy (`cdi`), non ci serve un'indennità per inoltrare i trasferimenti.
+Poiché il contratto ERC-20 si fida del proxy (`cdi`), non ci serve un'autorizzazione per inoltrare i trasferimenti.
```js
-// approval and transferFrom
+// approvazione e transferFrom
const approveTx = {
to: cdi.address,
data: "0x03" + poorSigner.address.slice(2, 42) + "00FF",
@@ -527,24 +567,19 @@ const transferFromTx = {
}
await (await poorSigner.sendTransaction(transferFromTx)).wait()
-// Check the approve / transferFrom combo was done correctly
+// Controlla che la combo approva / transferFrom sia stata eseguita correttamente
expect(await token.balanceOf(destAddr2)).to.equal(255)
```
-Testa le due nuove funzioni. Nota che `transferFromTx` richiede due parametri dell'indirizzo: l'autore dell'indennità e il destinatario.
+Testa le due nuove funzioni.
+Nota che `transferFromTx` richiede due parametri dell'indirizzo: l'autore dell'autorizzazione e il destinatario.
-### Esempio {#example-2}
-
-Se desideri vedere questi file in azione senza eseguirli tu stesso, segui questi link:
+## Conclusione {#conclusion}
-1. [Distribuzione di `OrisUselessToken-2`](https://kovan-optimistic.etherscan.io/tx/1475397) all'indirizzo [`0xb47c1f550d8af70b339970c673bbdb2594011696`](https://kovan-optimistic.etherscan.io/address/0xb47c1f550d8af70b339970c673bbdb2594011696).
-2. [Distribuzione di `CalldataInterpreter`](https://kovan-optimistic.etherscan.io/tx/1475400) all'indirizzo [`0x0dccfd03e3aaba2f8c4ea4008487fd0380815892`](https://kovan-optimistic.etherscan.io/address/0x0dccfd03e3aaba2f8c4ea4008487fd0380815892).
-3. [Chiamata a `setProxy()`](https://kovan-optimistic.etherscan.io/tx/1475402).
-4. [Chiamata a `faucet()`](https://kovan-optimistic.etherscan.io/tx/1475409).
-5. [Chiamata a `transferProxy()`](https://kovan-optimistic.etherscan.io/tx/1475416).
-6. [Chiamata a `approveProxy()`](https://kovan-optimistic.etherscan.io/tx/1475419).
-7. [Chiamata a `transferFromProxy()`](https://kovan-optimistic.etherscan.io/tx/1475421). Nota che questa chiamata proviene da un indirizzo diverso dagli altri, `poorSigner` invece di `signer`.
+Sia [Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) che [Arbitrum](https://developer.offchainlabs.com/docs/special_features) stanno cercando modi per ridurre la dimensione dei calldata scritti su L1 e quindi il costo delle transazioni.
+Tuttavia, come fornitori di infrastruttura alla ricerca di soluzioni generiche, le nostre capacità sono limitate.
+Come sviluppatore di dApp, hai conoscenze specifiche per l'applicazione che ti consentono di ottimizzare i tuoi calldata molto meglio di quanto potremmo fare noi in una soluzione generica.
+Speriamo che questo articolo ti aiuti a trovare la soluzione ideale per le tue esigenze.
-## Conclusione {#conclusion}
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
-Sia [Optimism](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) che [Arbitrum](https://developer.offchainlabs.com/docs/special_features) stanno cercando modi per ridurre le dimensioni dei calldata scritti al L1 e dunque per ridurre il costo delle transazioni. Tuttavia, come fornitori di infrastruttura alla ricerca di soluzioni generiche, le nostre capacità sono limitate. Come sviluppatore di dapp, hai conoscenze specifiche per l'applicazione che ti consentono di ottimizzare i tuoi calldata molto meglio di quanto potremmo fare noi in una soluzione generica. Speriamo che questo articolo ti aiuti a trovare la soluzione ideale per le tue esigenze.
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..6defd033c0e 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
@@ -1,15 +1,12 @@
---
-title: Linee guida di sicurezza per gli Smart Contract
+title: Linee guida di sicurezza per i contratti intelligenti
description: Elenco di controllo con le linee guida di sicurezza da tenere presenti per la creazione di una dapp
author: "Trailofbits"
-tags:
- - "solidity"
- - "smart contract"
- - "sicurezza"
+tags: [ "Solidity", "Smart Contract", "sicurezza" ]
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
---
@@ -24,29 +21,29 @@ La progettazione del contratto deve essere discussa in anticipo, prima di scrive
La documentazione può essere scritta su diversi livelli e deve essere aggiornata durante l'implementazione dei contratti:
- **Una descrizione semplice in inglese del sistema**, che descriva cosa fanno i contratti e tutte le ipotesi sulla base di codice.
-- **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.
+- **Schema e diagrammi architettonici**, incluse le interazioni del contratto e la macchina a stati del sistema. Le [stampanti di Slither](https://github.com/crytic/slither/wiki/Printer-documentation) possono aiutare a generare questi schemi.
+- **Documentazione approfondita del codice**, il formato [Natspec](https://docs.soliditylang.org/en/develop/natspec-format.html) può essere usato per Solidity.
-### Calcolo sulla catena ed esterno alla catena {#on-chain-vs-off-chain-computation}
+### Calcolo on-chain e off-chain {#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.
+- **Mantieni quanto più codice possibile off-chain.** Mantieni ridotto il livello on-chain. Pre-elabora i dati con codice off-chain in modo tale che la verifica on-chain sia semplice. Ti serve un elenco ordinato? Ordina l'elenco esternamente alla catena, poi controlla solo l'ordine sulla catena.
### Aggiornabilità {#upgradeability}
-Abbiamo discusso le diverse soluzioni di aggiornabilità nel [nostro post di blog](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Fai una scelta deliberata per supportare l'aggiornabilità o non prima di scrivere codice. La decisione influirà su come strutturi il tuo codice. In generale, consigliamo:
+Abbiamo discusso le diverse soluzioni di aggiornabilità nel [nostro post sul blog](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Fai una scelta deliberata per supportare l'aggiornabilità o non prima di scrivere codice. La decisione influirà su come strutturi il tuo codice. In generale, consigliamo:
-- **Prediligere la [migrazione del contratto](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) rispetto all'aggiornabilità.** I sistemi di migrazione presentano molti vantaggi identici a quelli aggiornabili, senza i loro svantaggi.
-- **Usare lo schema di separazione dei dati rispetto a quello delegatecallproxy.** Se il progetto ha una chiara separazione dell'astrazione, l'aggiornabilità che usa la separazione dei dati necessiterà solo di poche modifiche. delegatecallproxy richiede esperienza con l'EVM ed è altamente incline a errori.
-- **Documentare la procedura di migrazione/aggiornamento prima della distribuzione.** Se dovrai reagire sotto pressione senza linee guida, commetterai degli errori. Scrivi in anticipo la procedura da seguire. Deve includere:
+- **Prediligi la [migrazione del contratto](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) rispetto all'aggiornabilità.** I sistemi di migrazione presentano molti vantaggi identici a quelli aggiornabili, senza i loro svantaggi.
+- **Usa lo schema di separazione dei dati rispetto a quello delegatecallproxy.** Se il progetto ha una chiara separazione dell'astrazione, l'aggiornabilità che usa la separazione dei dati necessiterà solo di poche modifiche. delegatecallproxy richiede esperienza con l'EVM ed è altamente incline a errori.
+- **Documenta la procedura di migrazione/aggiornamento prima della distribuzione.** Se dovrai reagire sotto pressione senza linee guida, commetterai degli errori. Scrivi in anticipo la procedura da seguire. Deve includere:
- Le chiamate che inizializzano i nuovi contratti
- Dove sono memorizzate le chiavi e come accedervi
- Come controllare la distribuzione. Sviluppa e testa uno script post-distribuzione.
-## Linee guida per l'implementazione {#implementation-guidelines}
+## Linee guida di implementazione {#implementation-guidelines}
**Punta alla semplicità.** Usa sempre la soluzione più semplice adatta al tuo scopo. Tutti i membri del team devono essere in grado di comprendere la tua soluzione.
-### Composizione della funzione {#function-composition}
+### Composizione di funzioni {#function-composition}
L'architettura della base di codice deve rendere il codice semplice da controllare. Evita le scelte architettoniche che riducono la capacità di ragionare sulla sua correttezza.
@@ -56,39 +53,39 @@ L'architettura della base di codice deve rendere il codice semplice da controlla
### Ereditarietà {#inheritance}
- **Rendi gestibile l'ereditarietà.** L'ereditarietà deve essere usata per dividere la logica, tuttavia, il progetto deve puntare a ridurre la profondità e la larghezza dell'albero d'ereditarietà.
-- **Usa la [stampante dell'ereditarietà](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) di Slither per verificare la gerarchia dei contratti.** La stampante dell'ereditarietà ti aiuterà a controllare la dimensione della gerarchia.
+- **Usa la stampante dell'ereditarietà di [Slither](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) per verificare la gerarchia dei contratti.** La stampante dell'ereditarietà ti aiuterà a controllare la dimensione della gerarchia.
### Eventi {#events}
- **Registra tutte le operazioni cruciali.** Gli eventi aiuteranno ad eseguire il debug del contratto durante lo sviluppo e a monitorarlo dopo la distribuzione.
-### Evita trappole note {#avoid-known-pitfalls}
+### Evita le trappole note {#avoid-known-pitfalls}
-- **Sii consapevole dei problemi di sicurezza più comuni.** Ci sono molte risorse online per saperne di più sui problemi più comuni, come [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture the Ether](https://capturetheether.com/), o [Not so Smart Contract](https://github.com/crytic/not-so-smart-contracts/).
-- **Sii consapevole delle sezioni di avviso nella [documentazione di Solidity](https://solidity.readthedocs.io/en/latest/).**Le sezioni di avviso ti informeranno del comportamento non ovvio del linguaggio.
+- **Sii consapevole dei problemi di sicurezza più comuni.** Ci sono molte risorse online per conoscere i problemi comuni, come [Ethernaut CTF](https://ethernaut.openzeppelin.com/), [Capture the Ether](https://capturetheether.com/) o [Not so smart contracts](https://github.com/crytic/not-so-smart-contracts/).
+- **Sii consapevole delle sezioni di avviso nella [documentazione di Solidity](https://docs.soliditylang.org/en/latest/).** Le sezioni di avviso ti informeranno del comportamento non ovvio del linguaggio.
### Dipendenze {#dependencies}
-- **Usa librerie ben testate.** Importare il codice da librerie ben testate ridurrà la possibilità di scrivere codici con bug. Se vuoi scrivere un contratto ERC20, usa [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20).
+- **Usa librerie ben testate.** Importare codice da librerie ben testate ridurrà la probabilità di scrivere codice con bug. Se vuoi scrivere un contratto ERC20, usa [OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20).
- **Usa un gestore di dipendenze; evita il copia-incolla del codice.** Se ti basi su un'origine esterna, mantieni sempre il codice aggiornato rispetto all'origine.
### Test e verifica {#testing-and-verification}
-- **Scrivi test unitari approfonditi.** Un'ampia serie di test è cruciale per craare software di alta qualità.
-- **Scrivi controlli e proprietà personalizzati in [Slither](https://github.com/crytic/slither), [Echidna](https://github.com/crytic/echidna) e [Manticore](https://github.com/trailofbits/manticore).** Gli strumenti automatizzati contribuiranno a garantire la sicurezza del contratto. Consulta il resto di questa guida per imparare a scrivere controlli e proprietà efficienti.
-- **Usa [crytic.io](https://crytic.io/).** Crytic si integra con GitHub, fornisce accesso a rilevatori privati di Slither ed esegue controlli personalizzati delle proprietà da Echidna.
+- **Scrivi test unitari approfonditi.** Un'ampia suite di test è cruciale per creare software di alta qualità.
+- **Scrivi controlli e proprietà personalizzati per [Slither](https://github.com/crytic/slither), [Echidna](https://github.com/crytic/echidna) e [Manticore](https://github.com/trailofbits/manticore).** Gli strumenti automatizzati aiuteranno a garantire che il tuo contratto sia sicuro. Consulta il resto di questa guida per imparare a scrivere controlli e proprietà efficienti.
+- **Usa [crytic.io](https://crytic.io/).** Crytic si integra con GitHub, fornisce l'accesso a rilevatori privati di Slither ed esegue controlli personalizzati delle proprietà da Echidna.
### Solidity {#solidity}
- **Preferisci Solidity 0.5 rispetto a 0.4 e 0.6.** Secondo noi, Solidity 0.5 è più sicuro e contiene prassi meglio integrate rispetto a 0.4. Solidity 0.6 si è dimostrato troppo instabile per la produzione e ha bisogno ancora di tempo per maturare.
-- **Usa una versione stabile per compilare; usa l'ultima versione per controllare gli avvisi.** Controlla che per il tuo codice non vengano segnalati problemi con l'ultima versione del compiler. Solidity però ha un ciclo di rilascio veloce e una lunga cronologia di bug del compilatore, quindi non consigliamo l'ultima versione per la distribuzione (vedi i [consigli sulla versione solc](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) di Slither).
-- **Non usare l'assembly inline.** Assembly richiede esperienza con l'EVM. Non scrivere il codice dell'EVM se non ha una _conoscenza approfondita_ dello yellow paper.
+- **Usa una versione stabile per compilare; usa la versione più recente per controllare gli avvisi.** Controlla che il tuo codice non presenti problemi segnalati con l'ultima versione del compilatore. Tuttavia, Solidity ha un ciclo di rilascio veloce e una storia di bug del compilatore, quindi non raccomandiamo la versione più recente per la distribuzione (vedi i [consigli sulla versione solc](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) di Slither).
+- **Non usare l'assembly inline.** Assembly richiede esperienza con l'EVM. Non scrivere codice EVM se non hai una _piena padronanza_ dello Yellow Paper.
## Linee guida di distribuzione {#deployment-guidelines}
Una volta sviluppato e distribuito il contratto:
- **Monitora i contratti.** Guarda i registri e reagisci con prontezza in caso di compromissione del contratto o del portafoglio.
-- **Aggiungi le tue informazioni di contatto in [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).** Questo elenco aiuta terze parti a contattarti se viene scoperto un difetto nella sicurezza.
-- **Proteggi i portafogli degli utenti privilegiati.** Segui le nostre [best practice](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) se memorizzi chiavi in portafogli hardware.
-- **Prepara una risposta con un piano per gli incidenti.** Tieni presente che gli Smart Contract che crei possono essere compromessi. Anche se i contratti sono privi di bug, un aggressore potrebbe assumere il controllo delle chiavi del proprietario del contratto.
+- **Aggiungi le tue informazioni di contatto a [blockchain-security-contacts](https://github.com/crytic/blockchain-security-contacts).** Questo elenco aiuta le terze parti a contattarti se viene scoperto un difetto di sicurezza.
+- **Metti in sicurezza i portafogli degli utenti con privilegi.** Segui le nostre [migliori prassi](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) se archivi le chiavi in portafogli hardware.
+- **Prepara un piano di risposta agli incidenti.** Considera che i tuoi contratti intelligenti possono essere compromessi. Anche se i contratti sono privi di bug, un aggressore potrebbe assumere il controllo delle chiavi del proprietario del contratto.
diff --git a/public/content/translations/it/developers/tutorials/stealth-addr/index.md b/public/content/translations/it/developers/tutorials/stealth-addr/index.md
new file mode 100644
index 00000000000..1dde19956f6
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/stealth-addr/index.md
@@ -0,0 +1,443 @@
+---
+title: "Utilizzo degli Indirizzi Nascosti"
+description: "Gli indirizzi nascosti consentono agli utenti di trasferire asset in modo anonimo. Dopo aver letto questo articolo, sarai in grado di: spiegare cosa sono gli indirizzi nascosti e come funzionano, capire come usare gli indirizzi nascosti in modo da preservare l'anonimato e scrivere un'applicazione basata sul web che utilizza gli indirizzi nascosti."
+author: Ori Pomerantz
+tags:
+ [
+ "Indirizzo nascosto",
+ "privacy",
+ "crittografia",
+ "rust",
+ "wasm"
+ ]
+skill: intermediate
+published: 2025-11-30
+lang: it
+sidebarDepth: 3
+---
+
+Tu sei Bill. Per motivi che non approfondiremo, vuoi fare una donazione alla campagna "Alice Regina del Mondo" e vuoi che Alice sappia che hai donato, in modo che ti ricompensi in caso di vittoria. Sfortunatamente, la sua vittoria non è garantita. C'è una campagna concorrente, "Carol Imperatrice del Sistema Solare". Se Carol vince e scopre che hai fatto una donazione ad Alice, sarai nei guai. Quindi non puoi semplicemente trasferire 200 ETH dal tuo conto a quello di Alice.
+
+[ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) offre la soluzione. Questo ERC spiega come usare gli [indirizzi nascosti](https://nerolation.github.io/stealth-utils) per i trasferimenti anonimi.
+
+**Avvertenza**: La crittografia alla base degli indirizzi nascosti è, per quanto ne sappiamo, solida. Tuttavia, esistono potenziali attacchi side-channel. [Di seguito](#go-wrong), vedrai cosa puoi fare per ridurre questo rischio.
+
+## Come funzionano gli indirizzi nascosti {#how}
+
+Questo articolo tenterà di spiegare gli indirizzi nascosti in due modi. Il primo è [come usarli](#how-use). Questa parte è sufficiente per comprendere il resto dell'articolo. Poi c'è [una spiegazione della matematica che vi sta dietro](#how-math). Se sei interessato alla crittografia, leggi anche questa parte.
+
+### La versione semplice (come usare gli indirizzi nascosti) {#how-use}
+
+Alice crea due chiavi private e pubblica le chiavi pubbliche corrispondenti (che possono essere combinate in un unico meta-indirizzo di doppia lunghezza). Anche Bill crea una chiave privata e pubblica la chiave pubblica corrispondente.
+
+Usando la chiave pubblica di una parte e la chiave privata dell'altra, è possibile derivare un segreto condiviso noto solo ad Alice e Bill (non può essere derivato dalle sole chiavi pubbliche). Usando questo segreto condiviso, Bill ottiene l'indirizzo nascosto e può inviarvi degli asset.
+
+Anche Alice ottiene l'indirizzo dal segreto condiviso, ma poiché conosce le chiavi private delle chiavi pubbliche che ha pubblicato, può anche ottenere la chiave privata che le permette di prelevare da quell'indirizzo.
+
+### La matematica (perché gli indirizzi nascosti funzionano così) {#how-math}
+
+Gli indirizzi nascosti standard utilizzano la [crittografia a curva ellittica (ECC)](https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/#elliptic-curves-building-blocks-of-a-better-trapdoor) per ottenere prestazioni migliori con meno bit di chiave, pur mantenendo lo stesso livello di sicurezza. Ma per la maggior parte possiamo ignorarlo e fingere di usare l'aritmetica normale.
+
+C'è un numero che tutti conoscono, _G_. Puoi moltiplicare per _G_. Ma a causa della natura dell'ECC, è praticamente impossibile dividere per _G_. Il modo in cui la crittografia a chiave pubblica funziona generalmente in Ethereum è che puoi usare una chiave privata, _Ppriv_, per firmare le transazioni che vengono poi verificate da una chiave pubblica, _Ppub = GPpriv_.
+
+Alice crea due chiavi private, _Kpriv_ e _Vpriv_. _Kpriv_ sarà usata per spendere fondi dall'indirizzo nascosto, e _Vpriv_ per visualizzare gli indirizzi che appartengono ad Alice. Alice pubblica quindi le chiavi pubbliche: _Kpub = GKpriv_ e _Vpub = GVpriv_
+
+Bill crea una terza chiave privata, _Rpriv_, e pubblica _Rpub = GRpriv_ in un registro centrale (Bill avrebbe potuto inviarla anche ad Alice, ma supponiamo che Carol sia in ascolto).
+
+Bill calcola _RprivVpub = GRprivVpriv_, che si aspetta che anche Alice conosca (spiegato di seguito). Questo valore è chiamato _S_, il segreto condiviso. Questo dà a Bill una chiave pubblica, _Ppub = Kpub+G\*hash(S)_. Da questa chiave pubblica, può calcolare un indirizzo e inviarvi qualsiasi risorsa desideri. In futuro, se Alice vince, Bill può dirle _Rpriv_ per dimostrare che le risorse provengono da lui.
+
+Alice calcola _RpubVpriv = GRprivVpriv_. Questo le dà lo stesso segreto condiviso, _S_. Poiché conosce la chiave privata, _Kpriv_, può calcolare _Ppriv = Kpriv+hash(S)_. Questa chiave le consente di accedere agli asset nell'indirizzo che risulta da _Ppub = GPpriv = GKpriv+G\*hash(S) = Kpub+G\*hash(S)_.
+
+Abbiamo una chiave di visualizzazione separata per consentire ad Alice di subappaltare ai Servizi della Campagna di Dominazione Mondiale di Dave. Alice è disposta a far conoscere a Dave gli indirizzi pubblici e a informarla quando sono disponibili più fondi, ma non vuole che lui spenda i soldi della sua campagna.
+
+Poiché la visualizzazione e la spesa usano chiavi separate, Alice può dare a Dave _Vpriv_. Poi Dave può calcolare _S = RpubVpriv = GRprivVpriv_ e in questo modo ottenere le chiavi pubbliche (_Ppub = Kpub+G\*hash(S)_). Ma senza _Kpriv_ Dave non può ottenere la chiave privata.
+
+Per riassumere, questi sono i valori noti ai diversi partecipanti.
+
+| Alice | Published | Bill | Dave |
+| - | - | - | - |
+| G | G | G | G |
+| _Kpriv_ | - | - | - |
+| _Vpriv_ | - | - | _Vpriv_ |
+| _Kpub = GKpriv_ | _Kpub_ | _Kpub_ | _Kpub_ |
+| _Vpub = GVpriv_ | _Vpub_ | _Vpub_ | _Vpub_ |
+| - | - | _Rpriv_ | - |
+| _Rpub_ | _Rpub_ | _Rpub = GRpriv_ | _Rpub_ |
+| _S = RpubVpriv = GRprivVpriv_ | - | _S = RprivVpub = GRprivVpriv_ | _S = _RpubVpriv_ = GRprivVpriv_ |
+| _Ppub = Kpub+G\*hash(S)_ | - | _Ppub = Kpub+G\*hash(S)_ | _Ppub = Kpub+G\*hash(S)_ |
+| _Indirizzo=f(Ppub)_ | - | _Indirizzo=f(Ppub)_ | _Indirizzo=f(Ppub)_ | _Indirizzo=f(Ppub)_ |
+| _Ppriv = Kpriv+hash(S)_ | - | - | - |
+
+## Quando gli indirizzi nascosti vanno male {#go-wrong}
+
+_Non ci sono segreti sulla blockchain_. Sebbene gli indirizzi nascosti possano fornire privacy, tale privacy è suscettibile all'analisi del traffico. Per fare un esempio banale, immagina che Bill finanzi un indirizzo e invii immediatamente una transazione per pubblicare un valore _Rpub_. Senza la _Vpriv_ di Alice, non possiamo essere sicuri che si tratti di un indirizzo nascosto, ma è la scommessa più probabile. Poi, vediamo un'altra transazione che trasferisce tutti gli ETH da quell'indirizzo all'indirizzo del fondo della campagna di Alice. Potremmo non essere in grado di provarlo, ma è probabile che Bill abbia appena fatto una donazione alla campagna di Alice. Carol la penserebbe certamente così.
+
+È facile per Bill separare la pubblicazione di _Rpub_ dal finanziamento dell'indirizzo nascosto (farle in momenti diversi, da indirizzi diversi). Tuttavia, ciò non è sufficiente. Lo schema che Carol cerca è che Bill finanzia un indirizzo, e poi il fondo della campagna di Alice preleva da esso.
+
+Una soluzione è che la campagna di Alice non prelevi il denaro direttamente, ma lo usi per pagare una terza parte. Se la campagna di Alice invia 10 ETH ai Servizi della Campagna di Dominazione Mondiale di Dave, Carol sa solo che Bill ha fatto una donazione a uno dei clienti di Dave. Se Dave ha abbastanza clienti, Carol non sarebbe in grado di sapere se Bill ha fatto una donazione ad Alice, che è sua concorrente, o ad Adam, Albert o Abigail, di cui a Carol non importa. Alice può includere un valore hashato con il pagamento, e poi fornire a Dave la preimmagine, per dimostrare che era la sua donazione. In alternativa, come notato sopra, se Alice dà a Dave la sua _Vpriv_, lui sa già da chi proviene il pagamento.
+
+Il problema principale di questa soluzione è che richiede che Alice si preoccupi della segretezza quando quella segretezza va a vantaggio di Bill. Alice potrebbe voler mantenere la sua reputazione in modo che anche Bob, l'amico di Bill, le faccia una donazione. Ma è anche possibile che non le dispiaccia smascherare Bill, perché così lui avrà paura di ciò che accadrà se Carol vincerà. Bill potrebbe finire per fornire ad Alice un sostegno ancora maggiore.
+
+### Utilizzo di più livelli nascosti {#multi-layer}
+
+Invece di affidarsi ad Alice per preservare la privacy di Bill, Bill può farlo da solo. Può generare più meta-indirizzi per persone fittizie, Bob e Bella. Bill quindi invia ETH a Bob, e "Bob" (che in realtà è Bill) li invia a Bella. "Bella" (sempre Bill) li invia ad Alice.
+
+Carol può ancora fare l'analisi del traffico e vedere la pipeline Bill-Bob-Bella-Alice. Tuttavia, se "Bob" e "Bella" usano ETH anche per altri scopi, non sembrerà che Bill abbia trasferito nulla ad Alice, anche se Alice preleva immediatamente dall'indirizzo nascosto al suo indirizzo di campagna noto.
+
+## Scrivere un'applicazione per indirizzi nascosti {#write-app}
+
+Questo articolo spiega un'applicazione di indirizzi nascosti [disponibile su GitHub](https://github.com/qbzzt/251022-stealth-addresses.git).
+
+### Strumenti {#tools}
+
+Esiste [una libreria di indirizzi nascosti per typescript](https://github.com/ScopeLift/stealth-address-sdk) che potremmo usare. Tuttavia, le operazioni crittografiche possono essere ad alta intensità di CPU. Preferisco implementarli in un linguaggio compilato, come [Rust](https://rust-lang.org/), e usare [WASM](https://webassembly.org/) per eseguire il codice nel browser.
+
+Useremo [Vite](https://vite.dev/) e [React](https://react.dev/). Questi sono strumenti standard del settore; se non li conosci, puoi usare [questa guida](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Per usare Vite, abbiamo bisogno di Node.
+
+### Vedere gli indirizzi nascosti in azione {#in-action}
+
+1. Installa gli strumenti necessari: [Rust](https://rust-lang.org/tools/install/) e [Node](https://nodejs.org/en/download).
+
+2. Clona la repository di GitHub.
+
+ ```sh
+ git clone https://github.com/qbzzt/251022-stealth-addresses.git
+ cd 251022-stealth-addresses
+ ```
+
+3. Installa i prerequisiti e compila il codice Rust.
+
+ ```sh
+ cd src/rust-wasm
+ rustup target add wasm32-unknown-unknown
+ cargo install wasm-pack
+ wasm-pack build --target web
+ ```
+
+4. Avvia il server web.
+
+ ```sh
+ cd ../..
+ npm install
+ npm run dev
+ ```
+
+5. Vai all'[applicazione](http://localhost:5173/). Questa pagina dell'applicazione ha due frame: uno per l'interfaccia utente di Alice e l'altro per quella di Bill. I due frame non comunicano; sono sulla stessa pagina solo per comodità.
+
+6. Nei panni di Alice, fai clic su **Genera un meta-indirizzo nascosto**. Questo visualizzerà il nuovo indirizzo nascosto e le chiavi private corrispondenti. Copia il meta-indirizzo nascosto negli appunti.
+
+7. Nei panni di Bill, incolla il nuovo meta-indirizzo nascosto e fai clic su **Genera un indirizzo**. Questo ti dà l'indirizzo da finanziare per Alice.
+
+8. Copia l'indirizzo e la chiave pubblica di Bill e incollali nell'area "Chiave privata per l'indirizzo generato da Bill" dell'interfaccia utente di Alice. Una volta compilati questi campi, vedrai la chiave privata per accedere agli asset a quell'indirizzo.
+
+9. Puoi usare [un calcolatore online](https://iancoleman.net/ethereum-private-key-to-address/) per assicurarti che la chiave privata corrisponda all'indirizzo.
+
+### Come funziona il programma {#how-the-program-works}
+
+#### Il componente WASM {#wasm}
+
+Il codice sorgente che compila in WASM è scritto in [Rust](https://rust-lang.org/). Puoi vederlo in [`src/rust_wasm/src/lib.rs`](https://github.com/qbzzt/251022-stealth-addresses/blob/main/src/rust-wasm/src/lib.rs). Questo codice è principalmente un'interfaccia tra il codice JavaScript e [la libreria `eth-stealth-addresses`](https://github.com/kassandraoftroy/eth-stealth-addresses).
+
+**`Cargo.toml`**
+
+[`Cargo.toml`](https://doc.rust-lang.org/cargo/reference/manifest.html) in Rust è analogo a [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) in JavaScript. Contiene informazioni sul pacchetto, dichiarazioni di dipendenza, ecc.
+
+```toml
+[package]
+name = "rust-wasm"
+version = "0.1.0"
+edition = "2024"
+
+[dependencies]
+eth-stealth-addresses = "0.1.0"
+hex = "0.4.3"
+wasm-bindgen = "0.2.104"
+getrandom = { version = "0.2", features = ["js"] }
+```
+
+Il pacchetto [`getrandom`](https://docs.rs/getrandom/latest/getrandom/) deve generare valori casuali. Ciò non può essere fatto con mezzi puramente algoritmici; richiede l'accesso a un processo fisico come fonte di entropia. Questa definizione specifica che otterremo quell'entropia chiedendola al browser in cui siamo in esecuzione.
+
+```toml
+console_error_panic_hook = "0.1.7"
+```
+
+[Questa libreria](https://docs.rs/console_error_panic_hook/latest/console_error_panic_hook/) ci fornisce messaggi di errore più significativi quando il codice WASM va in panico e non può continuare.
+
+```toml
+[lib]
+crate-type = ["cdylib", "rlib"]
+```
+
+Il tipo di output richiesto per produrre codice WASM.
+
+**`lib.rs`**
+
+Questo è il codice Rust effettivo.
+
+```rust
+use wasm_bindgen::prelude::*;
+```
+
+Le definizioni per creare un pacchetto WASM da Rust. Sono documentate [qui](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/index.html).
+
+```rust
+use eth_stealth_addresses::{
+ generate_stealth_meta_address,
+ generate_stealth_address,
+ compute_stealth_key
+};
+```
+
+Le funzioni di cui abbiamo bisogno dalla [libreria `eth-stealth-addresses`](https://github.com/kassandraoftroy/eth-stealth-addresses).
+
+```rust
+use hex::{decode,encode};
+```
+
+Rust usa tipicamente [array](https://doc.rust-lang.org/std/primitive.array.html) di byte (`[u8; ]`) per i valori. Ma in JavaScript, usiamo tipicamente stringhe esadecimali. [La libreria `hex`](https://docs.rs/hex/latest/hex/) traduce per noi da una rappresentazione all'altra.
+
+```rust
+#[wasm_bindgen]
+```
+
+Genera i binding WASM per poter chiamare questa funzione da JavaScript.
+
+```rust
+pub fn wasm_generate_stealth_meta_address() -> String {
+```
+
+Il modo più semplice per restituire un oggetto con più campi è restituire una stringa JSON.
+
+```rust
+ let (address, spend_private_key, view_private_key) =
+ generate_stealth_meta_address();
+```
+
+La funzione [`generate_stealth_meta_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_meta_address.html) restituisce tre campi:
+
+- Il meta-indirizzo (_Kpub_ e _Vpub_)
+- La chiave privata di visualizzazione (_Vpriv_)
+- La chiave privata di spesa (_Kpriv_)
+
+La sintassi [tuple](https://doc.rust-lang.org/std/primitive.tuple.html) ci permette di separare di nuovo questi valori.
+
+```rust
+ format!("{{\"address\":\"{}\",\"view_private_key\":\"{}\",\"spend_private_key\":\"{}\"}}",
+ encode(address),
+ encode(view_private_key),
+ encode(spend_private_key)
+ )
+}
+```
+
+Usa la macro [`format!`](https://doc.rust-lang.org/std/fmt/index.html) per generare la stringa codificata in JSON. Usa [`hex::encode`](https://docs.rs/hex/latest/hex/fn.encode.html) per cambiare gli array in stringhe esadecimali.
+
+```rust
+fn str_to_array(s: &str) -> Option<[u8; N]> {
+```
+
+Questa funzione trasforma una stringa esadecimale (fornita da JavaScript) in un array di byte. La usiamo per analizzare i valori forniti dal codice JavaScript. Questa funzione è complicata a causa del modo in cui Rust gestisce gli array e i vettori.
+
+L'espressione `` è chiamata [generica](https://doc.rust-lang.org/book/ch10-01-syntax.html). `N` è un parametro che controlla la lunghezza dell'array restituito. La funzione è in realtà chiamata `str_to_array::`, dove `n` è la lunghezza dell'array.
+
+Il valore di ritorno è `Option<[u8; N]>`, il che significa che l'array restituito è [opzionale](https://doc.rust-lang.org/std/option/). Questo è un modello tipico in Rust per le funzioni che possono fallire.
+
+Ad esempio, se chiamiamo `str_to_array::10("bad060a7")`, la funzione dovrebbe restituire un array di dieci valori, ma l'input è di soli quattro byte. La funzione deve fallire, e lo fa restituendo `None`. Il valore di ritorno per `str_to_array::4("bad060a7")` sarebbe `Some<[0xba, 0xd0, 0x60, 0xa7]>`.
+
+```rust
+ // decode restituisce Result, _>
+ let vec = decode(s).ok()?;
+```
+
+La funzione [`hex::decode`](https://docs.rs/hex/latest/hex/fn.decode.html) restituisce un `Result, FromHexError>`. Il tipo [`Result`](https://doc.rust-lang.org/std/result/) può contenere un risultato di successo (`Ok(value)`) o un errore (`Err(error)`).
+
+Il metodo `.ok()` trasforma il `Result` in un `Option`, il cui valore è il valore `Ok()` in caso di successo o `None` in caso contrario. Infine, l'[operatore punto interrogativo](https://doc.rust-lang.org/std/option/#the-question-mark-operator-) interrompe le funzioni correnti e restituisce `None` se l'`Option` è vuoto. Altrimenti, estrae il valore e lo restituisce (in questo caso, per assegnare un valore a `vec`).
+
+Questo sembra un metodo stranamente contorto per gestire gli errori, ma `Result` e `Option` assicurano che tutti gli errori siano gestiti, in un modo o nell'altro.
+
+```rust
+ if vec.len() != N { return None; }
+```
+
+Se il numero di byte non è corretto, è un fallimento e restituiamo `None`.
+
+```rust
+ // try_into consuma vec e tenta di creare [u8; N]
+ let array: [u8; N] = vec.try_into().ok()?;
+```
+
+Rust ha due tipi di array. Gli [array](https://doc.rust-lang.org/std/primitive.array.html) hanno una dimensione fissa. I [vettori](https://doc.rust-lang.org/std/vec/index.html) possono crescere e ridursi. `hex::decode` restituisce un vettore, ma la libreria `eth_stealth_addresses` vuole ricevere degli array. [`.try_into()`](https://doc.rust-lang.org/std/convert/trait.TryInto.html#required-methods) converte un valore in un altro tipo, ad esempio un vettore in un array.
+
+```rust
+ Some(array)
+}
+```
+
+Rust non richiede di usare la parola chiave [`return`](https://doc.rust-lang.org/std/keyword.return.html) quando si restituisce un valore alla fine di una funzione.
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_generate_stealth_address(stealth_address: &str) -> Option {
+```
+
+Questa funzione riceve un meta-indirizzo pubblico, che include sia _Vpub_ che _Kpub_. Restituisce l'indirizzo nascosto, la chiave pubblica da pubblicare (_Rpub_) e un valore di scansione di un byte che accelera l'identificazione di quali indirizzi pubblicati possono appartenere ad Alice.
+
+Il valore di scansione fa parte del segreto condiviso (_S = GRprivVpriv_). Questo valore è disponibile per Alice, e controllarlo è molto più veloce che controllare se _f(Kpub+G\*hash(S))_ è uguale all'indirizzo pubblicato.
+
+```rust
+ let (address, r_pub, scan) =
+ generate_stealth_address(&str_to_array::<66>(stealth_address)?);
+```
+
+Usiamo la funzione [`generate_stealth_address`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.generate_stealth_address.html) della libreria.
+
+```rust
+ format!("{{\"address\":\"{}\",\"rPub\":\"{}\",\"scan\":\"{}\"}}",
+ encode(address),
+ encode(r_pub),
+ encode(&[scan])
+ ).into()
+}
+```
+
+Prepara la stringa di output codificata in JSON.
+
+```rust
+#[wasm_bindgen]
+pub fn wasm_compute_stealth_key(
+ address: &str,
+ bill_pub_key: &str,
+ view_private_key: &str,
+ spend_private_key: &str
+) -> Option {
+ .
+ .
+ .
+}
+```
+
+Questa funzione usa [`compute_stealth_key`](https://docs.rs/eth-stealth-addresses/latest/eth_stealth_addresses/fn.compute_stealth_key.html) della libreria per calcolare la chiave privata per prelevare dall'indirizzo (_Rpriv_). Questo calcolo richiede questi valori:
+
+- L'indirizzo (_Indirizzo=f(Ppub)_)
+- La chiave pubblica generata da Bill (_Rpub_)
+- La chiave privata di visualizzazione (_Vpriv_)
+- La chiave privata di spesa (_Kpriv_)
+
+```rust
+#[wasm_bindgen(start)]
+```
+
+[`#[wasm_bindgen(start)]`](https://wasm-bindgen.github.io/wasm-bindgen/reference/attributes/on-rust-exports/start.html) specifica che la funzione viene eseguita quando il codice WASM viene inizializzato.
+
+```rust
+pub fn main() {
+ console_error_panic_hook::set_once();
+}
+```
+
+Questo codice specifica che l'output di panico venga inviato alla console di JavaScript. Per vederlo in azione, usa l'applicazione e dai a Bill un meta-indirizzo non valido (basta cambiare una cifra esadecimale). Vedrai questo errore nella console di JavaScript:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/subtle-2.6.1/src/lib.rs:701:9:
+assertion `left == right` failed
+ left: 0
+ right: 1
+```
+
+Seguito da una traccia dello stack. Poi dai a Bill il meta-indirizzo valido, e ad Alice un indirizzo o una chiave pubblica non validi. Vedrai questo errore:
+
+```
+rust_wasm.js:236 panicked at /home/ori/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/eth-stealth-addresses-0.1.0/src/lib.rs:78:9:
+keys do not generate stealth address
+```
+
+Di nuovo, seguito da una traccia dello stack.
+
+#### L'interfaccia utente {#ui}
+
+L'interfaccia utente è scritta usando [React](https://react.dev/) e servita da [Vite](https://vite.dev/). Puoi imparare a usarli con [questa guida](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Non c'è bisogno di [WAGMI](https://wagmi.sh/) qui perché non interagiamo direttamente con una blockchain o un portafoglio.
+
+L'unica parte non ovvia dell'interfaccia utente è la connettività WASM. Ecco come funziona.
+
+**`vite.config.js`**
+
+Questo file contiene [la configurazione di Vite](https://vite.dev/config/).
+
+```js
+import { defineConfig } from 'vite'
+import react from '@vitejs/plugin-react'
+import wasm from "vite-plugin-wasm";
+
+// https://vite.dev/config/
+export default defineConfig({
+ plugins: [react(), wasm()],
+})
+```
+
+Abbiamo bisogno di due plugin di Vite: [react](https://www.npmjs.com/package/@vitejs/plugin-react) e [wasm](https://github.com/Menci/vite-plugin-wasm#readme).
+
+**`App.jsx`**
+
+Questo file è il componente principale dell'applicazione. È un contenitore che include due componenti: `Alice` e `Bill`, le interfacce utente per questi utenti. La parte rilevante per WASM è il codice di inizializzazione.
+
+```jsx
+import init from './rust-wasm/pkg/rust_wasm.js'
+```
+
+Quando usiamo [`wasm-pack`](https://rustwasm.github.io/docs/wasm-pack/), esso crea due file che usiamo qui: un file wasm con il codice effettivo (qui, `src/rust-wasm/pkg/rust_wasm_bg.wasm`) e un file JavaScript con le definizioni per usarlo (qui, `src/rust_wasm/pkg/rust_wasm.js`). L'esportazione predefinita di quel file JavaScript è il codice che deve essere eseguito per avviare WASM.
+
+```jsx
+function App() {
+ .
+ .
+ .
+ useEffect(() => {
+ const loadWasm = async () => {
+ try {
+ await init();
+ setWasmReady(true)
+ } catch (err) {
+ console.error('Errore durante il caricamento di wasm:', err)
+ alert("Errore Wasm: " + err)
+ }
+ }
+
+ loadWasm()
+ }, []
+ )
+```
+
+L'hook [`useEffect`](https://react.dev/reference/react/useEffect) consente di specificare una funzione che viene eseguita quando le variabili di stato cambiano. Qui, l'elenco delle variabili di stato è vuoto (`[]`), quindi questa funzione viene eseguita una sola volta al caricamento della pagina.
+
+La funzione effetto deve restituire immediatamente. Per usare codice asincrono, come l' `init` di WASM (che deve caricare il file `.wasm` e quindi richiede tempo) definiamo una funzione interna [`async`](https://en.wikipedia.org/wiki/Async/await) e la eseguiamo senza `await`.
+
+**`Bill.jsx`**
+
+Questa è l'interfaccia utente per Bill. Ha una singola azione, creare un indirizzo basato sul meta-indirizzo nascosto fornito da Alice.
+
+```jsx
+import { wasm_generate_stealth_address } from './rust-wasm/pkg/rust_wasm.js'
+```
+
+Oltre all'esportazione predefinita, il codice JavaScript generato da `wasm-pack` esporta una funzione per ogni funzione nel codice WASM.
+
+```jsx
+