Buono a sapersi
+Gli agenti IA e gli strumenti correlati sono ancora in fase di sviluppo iniziale e molto sperimentali: usali con cautela.
+`nonce``
-`` - _Tag d'apertura, contenente un frammento di codice_
+`` - _Tag di apertura, che contiene un frammento di codice_
nonce - _Testo non traducibile_
`` - _Tag di chiusura_
-
+
-Il testo di partenza contiene anche tag abbreviati, contenenti solo numeri, il che significa che la loro funzione non è immediatamente ovvia. Puoi passare su questi tag per vedere esattamente quale scopo assolvono.
+Il testo di origine contiene anche tag abbreviati, che contengono solo numeri, il che significa che la loro funzione non è immediatamente ovvia. Puoi passare il mouse sopra questi tag per vedere esattamente quale funzione svolgono.
-Nell'esempio seguente, passando con il mouse sul `<0>` tag puoi vedere che rappresenta `` e contiene un frammento di codice, quindi il contenuto non va tradotto.
+Nell'esempio seguente, puoi vedere che passando il mouse sopra il tag `<0>` viene mostrato che rappresenta `` e contiene un frammento di codice, pertanto il contenuto all'interno di questi tag non dovrebbe essere tradotto.
-
+
-## Formule/abbreviazioni brevi vs. complete {#short-vs-full-forms}
+## Forme brevi vs. complete/abbreviazioni {#short-vs-full-forms}
-Nel sito web sono usate molte abbreviazioni, es. dapp, NFT, DAO, DeFi, ecc. Queste abbreviazioni sono comunemente usate in inglese e gran parte dei visitatori del sito web ne è a conoscenza.
+Ci sono molte abbreviazioni usate sul sito web, es. dApp, NFT, DAO, DeFi, ecc. Queste abbreviazioni sono comunemente usate in inglese e la maggior parte dei visitatori del sito web ha familiarità con esse.
-Dal momento che di solito non esistono traduzioni attestate in altre lingue, il modo migliore per trattare questi termini e altri simili è quello di fornire una traduzione descrittiva della forma estesa e aggiungere l'abbreviazione inglese tra parentesi.
+Poiché di solito non hanno traduzioni consolidate in altre lingue, il modo migliore per affrontare questi e termini simili è fornire una traduzione descrittiva della forma completa e aggiungere l'abbreviazione inglese tra parentesi.
-Non tradurre queste abbreviazioni, poiché la maggior parte delle persone non le conoscerebbe e le versioni localizzate non avrebbero molto senso per la maggior parte dei visitatori.
+Non tradurre queste abbreviazioni, poiché la maggior parte delle persone non avrebbe familiarità con esse e le versioni localizzate non avrebbero molto senso per la maggior parte dei visitatori.
-Esempio di come tradurre le dapp:
+Esempio di come tradurre dApp:
-- Applicazioni decentralizzate (dApp) → _Tradotto integralmente (abbreviazione tra parentesi)_
+- Applicazioni decentralizzate (dApp) → _Forma completa tradotta (abbreviazione inglese tra parentesi)_
-## Termini senza traduzioni attestate {#terms-without-established-translations}
+## Termini senza traduzioni consolidate {#terms-without-established-translations}
-Alcuni termini potrebbero non avere traduzioni attestate in altre lingue e sono ampiamente noti con il termine originale in inglese. Tali termini includono principalmente concetti recenti, come Proof of Work, Proof of Stake, Beacon Chain, staking, ecc.
+Alcuni termini potrebbero non avere traduzioni consolidate in altre lingue e sono ampiamente conosciuti con il termine inglese originale. Tali termini includono per lo più concetti più recenti, come prova di lavoro, prova di stake, beacon chain, staking, ecc.
-Sebbene la traduzione di questi termini possa sembrare innaturale, poiché la versione inglese è comunemente usata anche in altre lingue, si consiglia vivamente di tradurli.
+Sebbene tradurre questi termini possa sembrare innaturale, poiché la versione inglese è comunemente usata anche in altre lingue, si consiglia vivamente di tradurli.
-Traducendoli, sentiti libero di essere creativo, usa traduzioni descrittive o semplicemente traducili in maniera letterale.
+Quando li traduci, sentiti libero di essere creativo, usa traduzioni descrittive o semplicemente traducili letteralmente.
-**Il motivo per cui la maggior parte dei termini dovrebbe essere tradotta, invece di lasciarne alcuni in inglese, è il fatto che questa nuova terminologia diventerà più diffusa in futuro, man mano che più persone inizieranno a utilizzare Ethereum e le relative tecnologie. Se vogliamo coinvolgere più persone da tutto il mondo in questo spazio, dobbiamo fornire una terminologia comprensibile in quante più lingue possibili, anche se dobbiamo crearla noi stessi.**
+**Il motivo per cui la maggior parte dei termini dovrebbe essere tradotta, invece di lasciarne alcuni in inglese, è il fatto che questa nuova terminologia diventerà più diffusa in futuro, man mano che più persone inizieranno a usare Ethereum e le tecnologie correlate. Se vogliamo far entrare più persone da tutto il mondo in questo spazio, dobbiamo fornire una terminologia comprensibile nel maggior numero di lingue possibile, anche se dobbiamo crearla noi stessi.**
## Pulsanti e CTA {#buttons-and-ctas}
-Il sito web contiene numerosi pulsanti, che dovrebbero essere tradotti in modo diverso dagli altri contenuti.
+Il sito web contiene numerosi pulsanti, che dovrebbero essere tradotti in modo diverso rispetto agli altri contenuti.
-Il testo del pulsante può essere identificato visualizzando gli screenshot contestuali, associati a gran parte delle stringhe, o controllando il contesto nell'editor, che include l'espressione "button".
+Il testo dei pulsanti può essere identificato visualizzando gli screenshot di contesto, collegati alla maggior parte delle stringhe, o controllando il contesto nell'editor, che include la parola ''button''.
-Le traduzioni dei pulsanti dovrebbero essere il più possibile brevi, onde evitare mancate corrispondenze di formattazione. Inoltre, le traduzioni dei pulsanti dovrebbero essere in forma imperativa, ovvero indicare un comando o una richiesta.
+Le traduzioni per i pulsanti dovrebbero essere il più brevi possibile, per prevenire problemi di formattazione. Inoltre, le traduzioni dei pulsanti dovrebbero essere all'imperativo, cioè presentare un comando o una richiesta.
-
+
## Tradurre per l'inclusività {#translating-for-inclusivity}
-I visitatori di ethereum.org provengono da tutto il mondo e da contesti sociali diversi. La lingua sul sito web deve quindi essere neutrale, accogliente per tutti e non esclusiva.
+I visitatori di Ethereum.org provengono da tutto il mondo e da contesti diversi. Il linguaggio sul sito web dovrebbe quindi essere neutrale, accogliente per tutti e non esclusivo.
-A tale riguardo, un aspetto importante è la neutralità di genere. Questa è facilmente ottenibile usando uno stile formale ed evitando parole specifiche per il genere nelle traduzioni.
+Un aspetto importante di questo è la neutralità di genere. Questo può essere facilmente ottenuto usando la forma formale di indirizzamento ed evitando qualsiasi parola specifica per genere nelle traduzioni.
-Un'altra forma di inclusività consiste nel tentare di tradurre per un pubblico globale, non specifico a paesi, razze o regioni.
+Un'altra forma di inclusività è cercare di tradurre per un pubblico globale, non specifico per alcun paese, razza o regione.
-Infine, la lingua dovrebbe essere adatta a qualsiasi pubblico e fascia di età.
+Infine, il linguaggio dovrebbe essere adatto a tutti i pubblici e a tutte le età.
-## Traduzioni specifiche in base alla lingua {#language-specific-translations}
+## Traduzioni specifiche per lingua {#language-specific-translations}
-Quando si traduce è importante seguire le regole grammaticali, le convenzioni e la formattazione utilizzate nella propria lingua, anziché copiare quelle del testo originale. Il testo d'origine segue le regole e convenzioni della grammatica inglese, non applicabili a molte altre lingue.
+Durante la traduzione, è importante seguire le regole grammaticali, le convenzioni e la formattazione usate nella tua lingua, invece di copiare dalla fonte. Il testo di origine segue le regole grammaticali e le convenzioni inglesi, che non sono applicabili a molte altre lingue.
-Dovresti essere a conoscenza delle regole per la tua lingua e tradurre di conseguenza. Se ti occorre aiuto, contattaci e ti aiuteremo a trovare risorse utili su come questi elementi dovrebbero essere usati nella tua lingua.
+Dovresti essere a conoscenza delle regole per la tua lingua e tradurre di conseguenza. Se hai bisogno di aiuto, contattaci e ti aiuteremo a trovare alcune risorse su come questi elementi dovrebbero essere usati nella tua lingua.
-Alcuni esempi di aspetti a cui prestare particolare attenzione:
+Alcuni esempi di cosa prestare particolare attenzione:
### Punteggiatura, formattazione {#punctuation-and-formatting}
-**Maiuscole/minuscole**
+**Uso delle maiuscole**
-- Esistono notevoli differenze nell'uso di maiuscole e minuscole in diverse lingue.
-- In inglese, è comune usare le maiuscole per tutte le parole di titoli e nomi, mesi e giorni, nomi di lingue, festività, etc. In molte altre lingue, questo è sbagliato dal punto di vista grammaticale, in quanto vigono regole diverse sull'uso delle maiuscole/minuscole.
-- Alcune lingue hanno anche regole sull'uso della maiuscola per pronomi personali, sostantivi e alcuni aggettivi, che in inglese vengono scritti con l'iniziale minuscola.
+- Ci sono vaste differenze nell'uso delle maiuscole in lingue diverse.
+- In inglese, è comune mettere in maiuscolo tutte le parole nei titoli e nei nomi, nei mesi e nei giorni, nei nomi delle lingue, nelle festività, ecc. In molte altre lingue, questo è grammaticalmente scorretto, poiché hanno regole diverse per l'uso delle maiuscole.
+- Alcune lingue hanno anche regole sull'uso delle maiuscole per i pronomi personali, i sostantivi e certi aggettivi, che non sono in maiuscolo in inglese.
**Spaziatura**
-- Le regole ortografiche definiscono l'uso degli spazi per ogni lingua. Poiché gli spazi sono usati ovunque, queste regole sono alcune delle più distinte e gli spazi sono alcuni degli elementi maggiormente tradotti in modo improprio.
-- Alcune differenze comuni nella spaziatura tra l'inglese e altre lingue:
- - Spazio prima dell'unità di misura e delle valute (es. USD, EUR, kB, MB)
+- Le regole ortografiche definiscono l'uso degli spazi per ogni lingua. Poiché gli spazi sono usati ovunque, queste regole sono tra le più distinte e gli spazi sono tra gli elementi più tradotti in modo errato.
+- Alcune differenze comuni nella spaziatura tra l'inglese e le altre lingue:
+ - Spazio prima delle unità di misura e delle valute (es. USD, EUR, kB, MB)
- Spazio prima dei segni di grado (es. °C, ℉)
- - Spazio prima di certi segni di punteggiatura, specialmente i puntini di sospensione (…)
+ - Spazio prima di alcuni segni di punteggiatura, specialmente i puntini di sospensione (…)
- Spazio prima e dopo le barre (/)
**Elenchi**
-- Ogni lingua ha una diversa e complessa serie di regole per la redazione di elenchi. Questi possono differire significativamente rispetto all'inglese.
-- In alcune lingue, la prima parola di ogni nuova riga deve essere maiuscola, mentre in altre le nuove righe devono iniziare con lettere minuscole. Molte lingue hanno anche regole differenti sull'uso delle maiuscole/minuscole negli elenchi, a seconda della lunghezza di ogni riga.
-- Lo stesso si applica alla punteggiatura dei vari punti dell'elenco. La punteggiatura finale negli elenchi può essere un punto (**.**), una virgola (**,**) o un punto e virgola (**;**), a seconda della lingua.
+- Ogni lingua ha un insieme di regole diverso e complesso per la scrittura degli elenchi. Queste possono essere significativamente diverse dall'inglese.
+- In alcune lingue, la prima parola di ogni nuova riga deve essere in maiuscolo, mentre in altre, le nuove righe dovrebbero iniziare con lettere minuscole. Molte lingue hanno anche regole diverse sull'uso delle maiuscole negli elenchi, a seconda della lunghezza di ogni riga.
+- Lo stesso vale per la punteggiatura delle voci. La punteggiatura finale negli elenchi può essere un punto (**.**), una virgola (**,**) o un punto e virgola (**;**), a seconda della lingua.
**Virgolette**
-- Le varie lingue usano tipi diversi di virgolette. Copiare semplicemente le virgolette inglesi dal segmento originale spesso è sbagliato.
-- Tra i tipi più comuni di virgolette troviamo:
+- Le lingue usano molti tipi diversi di virgolette. Copiare semplicemente le virgolette inglesi dalla fonte è spesso scorretto.
+- Alcuni dei tipi più comuni di virgolette includono:
- „testo di esempio“
- ‚testo di esempio’
- »testo di esempio«
@@ -242,27 +248,27 @@ Alcuni esempi di aspetti a cui prestare particolare attenzione:
- ‘testo di esempio’
- «testo di esempio»
-**Trattini lunghi e corti**
+**Trattini e lineette**
-- In inglese si utilizza un trattino corto (-) per unire parole o parti diverse di una parola e un trattino lungo (–) per indicare un intervallo o una pausa.
-- Molte lingue hanno regole diverse per l'uso di trattini corti e lunghi, che dovrebbero essere osservate.
+- In inglese, un trattino (-) è usato per unire parole o parti diverse di una parola, mentre una lineetta (–) è usata per indicare un intervallo o una pausa.
+- Molte lingue hanno regole diverse per l'uso di trattini e lineette che dovrebbero essere osservate.
### Formati {#formats}
**Numeri**
-- La differenza principale nella scrittura dei numeri nelle varie lingue riguarda il separatore usato per decimali e migliaia. Per le migliaia, può essere un punto, una virgola o uno spazio. Analogamente, alcune lingue usano un punto decimale, mentre altre usano una virgola.
+- La differenza principale nella scrittura dei numeri in lingue diverse è il separatore usato per i decimali e le migliaia. Per le migliaia, questo può essere un punto, una virgola o uno spazio. Allo stesso modo, alcune lingue usano un punto decimale, mentre altre usano una virgola decimale.
- Alcuni esempi di grandi numeri:
- Inglese – **1,000.50**
- Spagnolo – **1.000,50**
- Francese – **1 000,50**
-- Un'altra considerazione importante sulla traduzione dei numeri riguarda il segno percentuale. Può essere scritto in diversi modi: **100%**, **100 %** o **%100**.
-- Infine, i numeri negativi possono esser scritti diversamente, a secnda della lingua: -100, 100-, (100) o [100].
+- Un'altra considerazione importante quando si traducono i numeri è il segno di percentuale. Può essere scritto in modi diversi: **100%**, **100 %** o **%100**.
+- Infine, i numeri negativi possono essere visualizzati in modo diverso, a seconda della lingua: -100, 100-, (100) o [100].
**Date**
-- Traducendo le date, esistono numerose considerazioni e differenze basate sulla lingua. Ciò include il formato della data, il separatore, l'uso di maiuscole e minuscole e gli zeri iniziali. Esistono anche differenze tra le date scritte per esteso e le date numeriche.
- - Alcuni esempi di formati di data diversi:
+- Quando si traducono le date, ci sono una serie di considerazioni e differenze basate sulla lingua. Queste includono il formato della data, il separatore, l'uso delle maiuscole e gli zeri iniziali. Ci sono anche differenze tra date per esteso e numeriche.
+ - Alcuni esempi di diversi formati di data:
- Inglese UK (gg/mm/aaaa) – 1st January, 2022
- Inglese US (mm/gg/aaaa) – January 1st, 2022
- Cinese (aaaa-mm-gg) – 2022 年 1 月 1 日
@@ -272,22 +278,22 @@ Alcuni esempi di aspetti a cui prestare particolare attenzione:
**Valute**
-- Tradurre le valute può essere complicato, a causa dei diversi formati, convenzioni e conversioni. Come regola generale, consigliamo di lasciare la valuta riportata nel testo originale. Puoi aggiungere la tua valuta locale e la conversione tra parentesi, per comodità del lettore.
-- Le principali differenze nella scrittura delle valute nelle varie lingue riguardano il posizionamento dei simboli, l'uso di virgole o punti decimali, la spaziatura e l'uso di abbreviazioni o simboli.
+- Tradurre le valute può essere impegnativo, a causa dei diversi formati, convenzioni e conversioni. Come regola generale, ti preghiamo di mantenere le valute uguali alla fonte. Puoi aggiungere la tua valuta locale e la conversione tra parentesi, a vantaggio del lettore.
+- Le principali differenze nella scrittura delle valute in lingue diverse includono il posizionamento del simbolo, virgole decimali vs. punti decimali, spaziatura e abbreviazioni vs. simboli.
- Posizionamento del simbolo: $100 o 100$
- - Virgole vs. punti decimali: 100,50$ o 100.50$
+ - Virgole decimali vs. punti decimali: 100,50$ o 100.50$
- Spaziatura: 100$ o 100 $
- Abbreviazioni vs. simboli: 100 $ o 100 USD
**Unità di misura**
-- Come regola generale, consigliamo di lasciare le unità di misura come appaiono nel testo originale. Se il tuo paese usa un sistema differente, puoi includere la conversione tra parentesi.
-- Oltre alla localizzazione delle unità di misura, è importante notare anche il diverso trattamento di tali unità nelle varie lingue. La differenza principale riguarda la spaziatura tra numero e unità, che può variare in base alla lingua. Esempi di ciò includono: 100kB o 100 kB, 50°F o 50 °F.
+- Come regola generale, ti preghiamo di mantenere le unità di misura come nella fonte. Se il tuo paese usa un sistema diverso, puoi includere la conversione tra parentesi.
+- Oltre alla localizzazione delle unità di misura, è anche importante notare le differenze nel modo in cui le lingue si approcciano a queste unità. La differenza principale è la spaziatura tra il numero e l'unità, che può essere diversa in base alla lingua. Esempi di questo includono 100kB vs. 100 kB o 50ºF vs. 50 ºF.
-## Conclusioni {#conclusion}
+## Conclusione {#conclusion}
Tradurre ethereum.org è una grande opportunità per conoscere i diversi aspetti di Ethereum.
-Quando traduci, cerca di non andare troppo in fretta. Prendila con calma e goditi l'esperienza!
+Durante la traduzione, cerca di non avere fretta. Prenditela comoda e divertiti!
-Grazie per aver partecipato al Programma di Traduzione e per averci aiutato a rendere il sito web accessibile a un pubblico più ampio. La comunità di Ethereum è globale e siamo felici che tu ne faccia parte!
+Grazie per essere coinvolto nel Programma di Traduzione e per aiutarci a rendere il sito web accessibile a un pubblico più ampio. La comunità di Ethereum è globale e siamo felici che tu ne faccia parte!
\ No newline at end of file
diff --git a/public/content/translations/it/dao/index.md b/public/content/translations/it/dao/index.md
index 4c3071f0bf0..ed960ab10d1 100644
--- a/public/content/translations/it/dao/index.md
+++ b/public/content/translations/it/dao/index.md
@@ -1,167 +1,169 @@
---
-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.
-summaryPoint2: Un modo sicuro per collaborare con sconosciuti su Internet.
-summaryPoint3: Un luogo sicuro per impegnare fondi in una causa specifica.
+alt: Una rappresentazione di una DAO che vota su una proposta.
+summaryPoint1: "Comunità di proprietà dei membri senza una leadership centralizzata."
+summaryPoint2: Un modo sicuro per collaborare con sconosciuti su internet.
+summaryPoint3: Un luogo sicuro in cui impegnare fondi per una causa specifica.
---
## Cosa sono le DAO? {#what-are-daos}
-Una DAO è un'organizzazione posseduta collettivamente che opera per realizzare una missione condivisa.
+Una DAO è un'organizzazione di proprietà collettiva che lavora per una missione condivisa.
-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.
+Le DAO ci consentono di lavorare con persone affini in tutto il mondo senza doverci fidare di un leader benevolo per la gestione dei fondi o delle operazioni. Non c'è un CEO che possa spendere i fondi per un capriccio o un CFO che possa manipolare i registri. Invece, regole basate sulla blockchain e 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).
+Hanno tesorerie integrate a cui nessuno ha l'autorità di accedere senza l'approvazione del gruppo. Le decisioni sono governate da proposte e votazioni per garantire che tutti nell'organizzazione abbiano voce in capitolo, e tutto avviene in modo trasparente [on-chain](/glossary/#onchain).
## Perché abbiamo bisogno delle DAO? {#why-dao}
-Per avviare un'organizzazione con altre persone quando sono in ballo finanziamenti e denaro occorre riporre molta fiducia nei propri compagni di avventura. Ma è difficile fidarsi di qualcuno con cui hai interagito solo tramite Internet. Con le DAO non occorre fidarsi di nessun altro nel gruppo, bensì solamente del codice DAO, che è al 100% trasparente e verificabile da chiunque.
+Avviare un'organizzazione con qualcuno che coinvolge finanziamenti e denaro richiede molta fiducia nelle persone con cui si lavora. Ma è difficile fidarsi di qualcuno con cui si ha interagito solo su internet. Con le DAO non devi fidarti di nessun altro nel gruppo, solo del codice della DAO, che è trasparente al 100% e verificabile da chiunque.
-Ciò apre molte opportunità di cooperazione e coordinamento a livello globale.
+Questo apre tantissime nuove opportunità per la collaborazione e il coordinamento globale.
### Un confronto {#dao-comparison}
-| DAO | Organizzazione tradizionale |
-| --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
-| Di solito orizzontale e completamente democratizzata. | Di solito gerarchica. |
-| Votazione richiesta dai membri per l'implementazione di eventuali modifiche. | A seconda della struttura, le modifiche possono essere richieste da una sola parte oppure sottoposte a votazione. |
-| Conteggio dei voti e implementazione automatica del risultato senza intermediari. | Se la votazione è consentita, i voti sono conteggiati internamente e l'esito della votazione deve essere gestito manualmente. |
-| I servizi offerti vengono gestiti automaticamente in modo decentralizzato (ad esempio distribuzione di fondi filantropici). | Richiede manipolazione umana o automazione controllata centralmente, suscettibile di manipolazione. |
-| Tutte le attività sono trasparenti e completamente pubbliche. | L'attività è tipicamente privata e limitata al pubblico. |
+| DAO | Un'organizzazione tradizionale |
+| ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
+| Solitamente orizzontale e completamente democratizzata. | Solitamente gerarchica. |
+| È richiesta la votazione dei membri per implementare qualsiasi modifica. | A seconda della struttura, le modifiche possono essere richieste da una singola parte, o può essere offerta una votazione. |
+| I voti vengono conteggiati e il risultato viene implementato automaticamente senza un intermediario fidato. | Se la votazione è consentita, i voti vengono conteggiati internamente e il risultato della votazione deve essere gestito manualmente. |
+| I servizi offerti sono gestiti automaticamente in modo decentralizzato (ad esempio la distribuzione di fondi filantropici). | Richiede la gestione umana, o un'automazione controllata centralmente, soggetta a manipolazione. |
+| Tutte le attività sono trasparenti e completamente pubbliche. | Le attività sono tipicamente private e limitate al pubblico. |
### Esempi di DAO {#dao-examples}
-Per aiutarti a comprendere meglio, ecco alcuni esempi di come potresti utilizzare una DAO:
+Per rendere tutto questo più chiaro, ecco alcuni esempi di come potresti usare una DAO:
-- ** Un ente di beneficenza**: puoi accettare donazioni da chiunque nel mondo e votare in merito a quali cause finanziare.
-- **Proprietà collettiva**: potresti acquistare beni fisici o digitali e i membri possono votare sul loro utilizzo.
-- **Iniziative e sovvenzioni**: potresti creare un fondo di rischio che raggruppa il capitale di investimento e che vota sulle iniziative da finanziare. Il denaro rimborsato potrebbe essere successivamente ridistribuito tra i membri del DAO.
+- **Un ente di beneficenza** – potresti accettare donazioni da chiunque nel mondo e votare su quali cause finanziare.
+- **Proprietà collettiva** – potresti acquistare asset fisici o digitali e i membri possono votare su come utilizzarli.
+- **Iniziative e sovvenzioni** – potresti creare un fondo di venture capital che raccoglie capitale di investimento e vota sulle iniziative da sostenere. Il denaro rimborsato potrebbe poi essere ridistribuito tra i membri della DAO.
- Esplora le app della DeFi
+ Esplora le dApp della DeFi
-## Tutto è iniziato con Bitcoin... {#bitcoin}
+## È iniziato tutto con Bitcoin... {#bitcoin}
-Bitcoin è considerabile, sotto molti aspetti, come la prima applicazione di DeFi. Bitcoin ti consente di possedere realmente e di controllare il valore, inviandolo in tutto il mondo. Infatti, fornisce un metodo, per grandi numeri di persone che non si fidano tra loro, di accordarsi su un libro mastro di conti, senza la necessità di un intermediario fidato. Bitcoin è aperto a tutti e nessuno ha l'autorità di modificarne le regole. Le regole di Bitcoin, come la sua scarsità e la sua apertura, sono scritte nella tecnologia. Non è come la finanza tradizionale, dove i governi possono stampare denaro che svaluta i tuoi risparmi e le aziende possono chiudere i mercati.
+Bitcoin, per molti versi, è stata la prima applicazione della DeFi. Bitcoin ti permette di possedere e controllare realmente il valore e di inviarlo ovunque nel mondo. Lo fa fornendo un modo a un gran numero di persone, che non si fidano l'una dell'altra, di concordare su un registro di account senza il bisogno di un intermediario fidato. Bitcoin è aperto a chiunque e nessuno ha l'autorità di cambiarne le regole. Le regole di Bitcoin, come la sua scarsità e la sua apertura, sono scritte nella tecnologia. Non è come la finanza tradizionale, dove i governi possono stampare denaro che svaluta i tuoi risparmi e le aziende possono chiudere i mercati.
-Ethereum si basa su questo. Come per Bitcoin, le regole non sono modificabili e tutti vi hanno accesso. Inoltre, questo sistema rende il denaro digitale programmabile, utilizzando i [contratti intelligenti](/glossary/#smart-contract), così che tu possa andare oltre l'archiviazione e l'invio di valore.
+Ethereum si basa su questo. Come per Bitcoin, le regole non possono cambiare a tuo svantaggio e tutti hanno accesso. Ma rende anche questo denaro digitale programmabile, utilizzando i [contratti intelligenti](/glossary/#smart-contract), così puoi andare oltre la semplice conservazione e l'invio di valore.
- Esplora i nostri suggerimenti per le applicazioni della DeFi da provare, se sei nuovo su Ethereum.
+
+ Esplora i nostri suggerimenti per le applicazioni della DeFi da provare se sei nuovo su Ethereum.
- Esplora le app di DeFi
+ Esplora le dApp della DeFi
## Cosa puoi fare con la DeFi? {#defi-use-cases}
-Esiste un'alternativa decentralizzata a gran parte dei servizi finanziari. Ma Ethereum, inoltre, offre l'opportunità di creare prodotti finanziari completamente nuovi. Questo è un elenco in continu espansione.
+Esiste un'alternativa decentralizzata alla maggior parte dei servizi finanziari. Ma Ethereum crea anche opportunità per creare prodotti finanziari completamente nuovi. Questa è una lista in continua crescita.
- [Inviare denaro in tutto il mondo](#send-money)
-- [Trasmettere denaro in tutto il mondo](#stream-money)
+- [Trasmettere denaro in streaming in tutto il mondo](#stream-money)
- [Accedere a valute stabili](#stablecoins)
-- [Assumere fondi con garanzia](#lending)
-- [Erogare fondi senza garanzia](#flash-loans)
-- [Creare risparmi di criptovalute](#saving)
+- [Prendere in prestito fondi con collaterale](#lending)
+- [Prendere in prestito senza collaterale](#flash-loans)
+- [Iniziare a risparmiare in criptovalute](#saving)
- [Scambiare token](#swaps)
-- [Accrescere il proprio portafoglio](#investing)
-- [Finanziare le proprie idee](#crowdfunding)
-- [Acquistare assicurazioni](#insurance)
-- [Gestire il proprio portafoglio](#aggregators)
+- [Far crescere il tuo portafoglio](#investing)
+- [Finanziare le tue idee](#crowdfunding)
+- [Acquistare un'assicurazione](#insurance)
+- [Gestire il tuo portafoglio](#aggregators)
- Visualizza le dApp di pagamento
+ Vedi le dApp di pagamento
-#### Trasmettere denaro in tutto il mondo... {#stream-money}
+#### Trasmettere denaro in streaming in tutto il mondo... {#stream-money}
-Su Ethereum, inoltre, è possibile trasmettere denaro. Ciò ti consente di pagare il salario di qualcuno in pochi secondi, consentendogli di accedere al proprio denaro quando necessario. Oppure, noleggiare qualcosa all'istante, come un magazzino o uno scooter elettrico.
+Puoi anche trasmettere denaro in streaming su Ethereum. Questo ti permette di pagare a qualcuno il suo stipendio al secondo, dandogli accesso al suo denaro ogni volta che ne ha bisogno. Oppure affittare qualcosa al secondo, come un armadietto o un monopattino elettrico.
-E se non vuoi inviare o trasmettere [ETH](/glossary/#ether) a causa della sua volatilità, su Ethereum puoi trovare delle valute alternative: le [Stablecoin](/glossary/#stablecoin).
+E se non vuoi inviare o trasmettere in streaming [ETH](/glossary/#ether) a causa di quanto può cambiare il suo valore, ci sono valute alternative su Ethereum: le [stablecoin](/glossary/#stablecoin).
- Altro sulle Stablecoin
+ Maggiori informazioni sulle stablecoin
- Vedi le dApp di assunzione di prestiti
+ Vedi le dApp di prestito
-Esistono molti vantaggi, derivati dall'utilizzo di un creditore decentralizzato...
+Ci sono molti vantaggi nell'usare un prestatore decentralizzato...
-#### Assunzione di prestiti nell'anonimato {#borrowing-privacy}
+#### Prendere in prestito con privacy {#borrowing-privacy}
-Oggi, assumere ed erogare prestiti, dipende esclusivamente dagli individui coinvolti. Prima di erogare un prestito, le banche devono sapere se sarai in grado di rimborsarlo.
+Oggi, prestare e prendere in prestito denaro ruota tutto attorno agli individui coinvolti. Le banche hanno bisogno di sapere se sei propenso a ripagare un prestito prima di concederlo.
-Il prestito decentraliizzato funziona senza che nessuna delle parti debba identificarsi. Il debitore deve invece produrre garanzie reali, che il creditore riceverà automaticamente se il prestito non viene rimborsato. Alcuni creditori accettano persino [NFT](/glossary/#nft) come garanzia. I NFT sono atti per risorse univoche, come un dipinto. [Di più sui NFT](/nft/)
+Il prestito decentralizzato funziona senza che nessuna delle parti debba identificarsi. Invece, il mutuatario deve fornire un collaterale che il prestatore riceverà automaticamente se il prestito non viene ripagato. Alcuni prestatori accettano persino i [token non fungibile (NFT)](/glossary/#nft) come collaterale. Gli NFT sono un atto di proprietà di un asset unico, come un dipinto. [Maggiori informazioni sugli NFT](/nft/)
-Questo ti consente di assumere un prestito senza controlli sul credito, o la trasmissione di informazioni private.
+Questo ti permette di prendere in prestito denaro senza controlli del credito o senza dover consegnare informazioni private.
-#### Accedere a fondi globali {#access-global-funds}
+#### Accesso a fondi globali {#access-global-funds}
-Ricorrendo a un creditore decentralizzato, hai accesso ai fondi depositati da tutto il mondo, non soltanto a quelli in custodia presso la banca o l'istituzione scelta. Ciò rende i prestiti più accessibili, migliorando i tassi d'interesse.
+Quando usi un prestatore decentralizzato hai accesso a fondi depositati da tutto il mondo, non solo ai fondi in custodia presso la tua banca o istituzione scelta. Questo rende i prestiti più accessibili e migliora i tassi di interesse.
-#### Vantaggi fiscali {#tax-efficiencies}
+#### Efficienze fiscali {#tax-efficiencies}
-Assumere un prestito può concederti l'accesso ai fondi necessari, senza dover vendere i tuoi ETH (un evento imponibile). Puoi invece usare ETH come garanzia per un prestito di stablecoin. Così, benefici del flusso di cassa, pur mantenendo i tuoi ETH. Le Stablecoin sono token più adatti a quando necessiti di denaro contante, poiché non fluttuano in valore come gli ETH. [Di più sulle Stablecoin](#stablecoins)
+Prendere in prestito può darti accesso ai fondi di cui hai bisogno senza dover vendere i tuoi ETH (un evento tassabile). Invece, puoi usare gli ETH come collaterale per un prestito in stablecoin. Questo ti dà il flusso di cassa di cui hai bisogno e ti permette di mantenere i tuoi ETH. Le stablecoin sono token molto migliori per quando hai bisogno di contanti, poiché non fluttuano di valore come gli ETH. [Maggiori informazioni sulle stablecoin](#stablecoins)
-#### Prestiti istantanei {#flash-loans}
+#### Prestiti flash {#flash-loans}
-I prestiti istantanei sono una forma più sperimentale di erogazione di prestiti decentralizzati, che ti consente di assumere prestiti senza garanzia, e senza fornire alcuna informazione personale.
+I prestiti flash sono una forma più sperimentale di prestito decentralizzato che ti permette di prendere in prestito senza collaterale o senza fornire alcuna informazione personale.
-Al momento non sono ampiamente accessibili agli utenti non tecnici, ma danno un'idea di cosa potrebbe essere possibile per tutti, in futuro.
+Al momento non sono ampiamente accessibili alle persone non tecniche, ma suggeriscono cosa potrebbe essere possibile per tutti in futuro.
-Si basano sul fatto che il prestito è assunto e ripagato durante la stessa transazione. Se non può essere restituito, la transazione si ripristina, come se nulla fosse mai successo.
+Funziona sulla base del fatto che il prestito viene contratto e ripagato all'interno della stessa transazione. Se non può essere ripagato, la transazione viene annullata come se nulla fosse mai accaduto.
-Spesso, i fondi utilizzati sono mantenuti in gruppi di liquidità (grandi gruppi di fondi utilizzati per i prestiti). Se in un dato momento non sono utilizzati, ciò crea un'opportunità per qualcuno, di assumere il prestito di tali fondi, concluervi affari e ripagarli ineramente, letteralmente in contemporanea alla ricezione del prestito.
+I fondi che vengono spesso utilizzati sono detenuti in pool di liquidità (grandi pool di fondi utilizzati per i prestiti). Se non vengono utilizzati in un dato momento, questo crea un'opportunità per qualcuno di prendere in prestito questi fondi, condurre affari con essi e ripagarli per intero letteralmente nello stesso momento in cui vengono presi in prestito.
-Ciò significa che dev'essere inclusa molta logica, in una transazione ad hoc. Un semplice esempio potrebbe essere l'utilizzo di un prestito istantaneo per assumere il prestito di una risorsa a un prezzo, così da poterla rivendere su una piattaforma di scambio differente, dove il prezzo è maggiore.
+Questo significa che molta logica deve essere inclusa in una transazione molto su misura. Un semplice esempio potrebbe essere qualcuno che usa un prestito flash per prendere in prestito la maggior quantità possibile di un asset a un certo prezzo, in modo da poterlo vendere su un exchange diverso dove il prezzo è più alto.
-Quindi, in una singola transazione, avviene quanto segue:
+Quindi, in una singola transazione, accade quanto segue:
-- Assumi il prestito di X $asset a $1,00 dalla piattaforma di scambio A
-- Vendi X $asset sulla piattaforma di scambio B per $1,10
-- Ripaghi il prestito sulla piattaforma di scambio A
-- Mantieni il profitto, a cui è sottratta la commissione sulla transazione
+- Prendi in prestito una quantità X di $asset a 1,00 $ dall'exchange A
+- Vendi X $asset sull'exchange B per 1,10 $
+- Ripaghi il prestito all'exchange A
+- Tieni il profitto meno la commissione della transazione
-Se l'offerta sulla piattaforma di scambio B cala improvvisamente, e l'utente non riesce ad acquistare abbastanza da coprire il prestito originale, la transazione non va semplicemente a buon fine.
+Se l'offerta dell'exchange B diminuisse improvvisamente e l'utente non fosse in grado di acquistare abbastanza per coprire il prestito originale, la transazione semplicemente fallirebbe.
-Per applicare l'esempio precedente nel mondo finanziario tradizionale, necessiteresti di un ingente importo di denaro. Queste strategie di guadagno sono accessibili soltanto a persone già ricche. I prestiti istantanei sono l'esempio ddi un futuro in cui possedere denaro non è necessariamente un prerequisito per guadagnare.
+Per poter fare l'esempio sopra nel mondo della finanza tradizionale, avresti bisogno di un'enorme quantità di denaro. Queste strategie per fare soldi sono accessibili solo a chi ha già ricchezza. I prestiti flash sono un esempio di un futuro in cui avere denaro non è necessariamente un prerequisito per fare denaro.
- Di più sui prestiti istantanei
+ Maggiori informazioni sui prestiti flash
- Consulta le dapp di erogazione di prestiti
+ Vedi le dApp di prestito
-#### Lotterie prive di perdita {#no-loss-lotteries}
+#### Lotterie senza perdite {#no-loss-lotteries}
-Le lotterie prive di perdita, come PoolTogether, sono un nuovo metodo divertente e innovativo, per risparmiare denaro.
+Le lotterie senza perdite come PoolTogether sono un modo nuovo, divertente e innovativo per risparmiare denaro.
-- Acquisti 100 biglietti, utilizzando 100 token DAI.
-- Ricevi 100 plDai, rappresentanti i tuoi 100 biglietti.
-- Se uno dei tuoi biglietti è estratto come vincitore, il tuo saldo di plDai incrementa, all'importo del montepremi.
-- Se perdi, i tuoi 100 plDai sono aggiunti all'estrazione della settimana successiva.
-- Puoi prelevare regolarmente un importo di DAI, pari al tuo saldo di plDai, in qualsiasi momento.
+- Compri 100 biglietti usando 100 token Dai.
+- Ricevi 100 plDai che rappresentano i tuoi 100 biglietti.
+- Se uno dei tuoi biglietti viene estratto come vincitore, il tuo saldo di plDai aumenterà dell'importo del montepremi.
+- Se non vinci, i tuoi 100 plDai passano all'estrazione della settimana successiva.
+- Puoi prelevare una quantità di Dai regolari pari al tuo saldo di plDai in qualsiasi momento.
-Il montepremi si compone di tutti gli interessi generati dall'erogazione dei depositi dei ticket, come nel precedente esempio di erogazione dei prestiti.
+Il montepremi è generato da tutti gli interessi prodotti prestando i depositi dei biglietti, come nell'esempio di prestito qui sopra.
Prova PoolTogether
@@ -213,131 +213,140 @@ Il montepremi si compone di tutti gli interessi generati dall'erogazione dei dep
### Scambiare token {#swaps}
-Esistono migliaia di token su Ethereum. Le piattaforme di scambio decentralizzate (DEX), consentono di scambiare token differenti, ogni volta che vuoi. Non rinunci mai al controllo delle tue risorse. Funzionano similmente al cambio di valuta, quando si visita un paese estero. Ma la versione della DeFi non chiude mai. I mercati sono aperti 24/7, 365 giorni l'anno e, la tecnologia, garantisce che ci sia sempre qualcuno che accetti uno scambio.
+Ci sono migliaia di token su Ethereum. Gli exchange decentralizzati (DEX) ti permettono di scambiare token diversi quando vuoi. Non rinunci mai al controllo dei tuoi asset. È come usare un cambio valuta quando visiti un paese diverso. Ma la versione della DeFi non chiude mai. I mercati sono aperti 24 ore su 24, 7 giorni su 7, 365 giorni all'anno e la tecnologia garantisce che ci sarà sempre qualcuno ad accettare uno scambio.
-Ad esempio, se desideri utilizzare la lotteria priva di perdite di PoolTogheter (descritta sopra), necessiterai di un token come DAI o USDC. Queste DEX ti consentono di scambiare i tuoi ETH per tali token, e viceversa quando hai finito.
+Ad esempio, se vuoi usare la lotteria senza perdite PoolTogether (descritta sopra), avrai bisogno di un token come Dai o USDC. Questi DEX ti permettono di scambiare i tuoi ETH per quei token e viceversa quando hai finito.
- Visualizza le piattaforme di scambio di token
+ Vedi gli exchange di token
- Consulta le dapp di trading
+ Vedi le dApp di trading
- Consulta le dapp d'investimento
+ Vedi le dApp di investimento
- Consulta le dapp di crowdfunding
+ Vedi le dApp di crowdfunding
#### Finanziamento quadratico {#quadratic-funding}
-Ethereum è un software open source e, finora, buona parte del lavoro è stata finanziata dalla community. Ciò ha comportato la crescita di un nuovo interessante modello di finanziamento: il finanziamento quadratico. Questo finanziamento ha il potenziale di migliorare il modo in cui finanzieremo tutti i tipi di beni pubblici in futuro.
+Ethereum è un software open-source e gran parte del lavoro finora è stato finanziato dalla comunità. Questo ha portato alla crescita di un nuovo e interessante modello di raccolta fondi: il finanziamento quadratico. Questo ha il potenziale per 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ù unica. In sintesi, i progetti che cercano di migliorare la vita del maggior numero di persone. Ecco come funziona:
+Il finanziamento quadratico si assicura che i progetti che ricevono più fondi siano quelli con la domanda più unica. In altre parole, i progetti che mirano a migliorare la vita del maggior numero di persone. Ecco come funziona:
-1. È presente un gruppo corrispondente di fondi donati.
-2. Una serie di finanziamenti pubblici è avviata.
-3. Le persone possono segnalare la propria domanda per un progetto, donando del denaro.
-4. Una volta terminata la serie, il gruppo corrisponente è distribuito ai progetti. Quelli con la domanda più unica, ricevono l'importo maggiore dal gruppo corrispondente.
+1. C'è un pool di fondi donati per il matching.
+2. Inizia un round di finanziamento pubblico.
+3. Le persone possono segnalare la loro richiesta per un progetto donando del denaro.
+4. Una volta terminato il round, il pool di matching viene distribuito ai progetti. Quelli con la domanda più unica ottengono l'importo più alto dal pool di matching.
-Ciò significa che il Progetto A, con le sue 100 donazioni da 1 dollaro, potrebbe ricevere maggiori finanziamenti del Progetto B, con una singola donazione da 10.000 dollari (a seconda delle dimensioni del gruppo corrispondente).
+Questo significa che il Progetto A, con le sue 100 donazioni da 1 dollaro, potrebbe finire con più fondi del Progetto B con una singola donazione di 10.000 dollari (a seconda delle dimensioni del pool di matching).
- Di più sul finanziamento quadratico
+ Maggiori informazioni sul finanziamento quadratico
- Consulta le dApp assicurative
+ Vedi le dApp di assicurazione
- Consulta le dapp del portfolio
+ Vedi le dApp di portafoglio
- Di più sulla creazione di dapp
+ Maggiori informazioni sulla costruzione di dApp
+## Oltre la DeFi tradizionale {#beyond-traditional-defi}
+
+L'ecosistema della DeFi continua a espandersi in nuove aree:
+
+- **[Mercati di previsione](/prediction-markets/)** – Piattaforme decentralizzate in cui puoi scommettere sull'esito di eventi futuri, dalle elezioni agli eventi sportivi, senza intermediari.
+- **[Asset del mondo reale (RWA)](/real-world-assets/)** – Tokenizzazione di asset fisici come immobili, materie prime e obbligazioni su Ethereum, portando trilioni di dollari di valore on-chain.
+- **[Pagamenti](/payments/)** – Utilizzo di Ethereum e stablecoin per pagamenti globali veloci e a basso costo senza l'infrastruttura bancaria tradizionale.
+- **[Agenti IA](/ai-agents/)** – Agenti software autonomi che possono effettuare transazioni su Ethereum, abilitando nuove forme di trading automatizzato, gestione del portafoglio e interazione on-chain.
+
## Letture consigliate {#further-reading}
### Dati sulla DeFi {#defi-data}
@@ -347,19 +356,19 @@ La DeFi è un movimento open source. I protocolli e le applicazioni della DeFi s
### Articoli sulla DeFi {#defi-articles}
-- [Una guida per principianti alla DeFi](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6 gennaio 2020_
+- [A beginner's guide to DeFi](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 6 gennaio 2020_
+- [EEA DeFi Risk Assessment Guidelines](https://entethalliance.org/specs/defi-risks/) – Una panoramica supportata dal settore su come identificare e valutare i rischi chiave nei protocolli della DeFi.
### Video {#videos}
-- [Finematics: istruzione finanziaria decentralizzata](https://finematics.com/): _Viddeo sulla DeFi_
-- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq): _Fondamenti di DeFi: Tutto ciò che devi sapere per muovere i primi passi, in questo spazio talvolta sconcertante._
+- [Finematics - decentralized finance education](https://finematics.com/) – _Video sulla DeFi_
+- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) - _Le basi della DeFi: tutto ciò che devi sapere per iniziare in questo spazio a volte sconcertante._
- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _Cos'è la DeFi?_
-### Community {#communities}
+### Comunità {#communities}
-- [Server Discord di DeFi Llama](https://discord.defillama.com/)
-- [Server Discord di DeFi Pulse](https://discord.gg/Gx4TCTk)
+- [DeFi Llama Discord server](https://discord.defillama.com/)
@@ -87,50 +88,50 @@ Please enter a password for the new account to be created:
INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120
WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120
WARN [10-28|16:19:09.306] Please remember your password!
-Account generato 0x5e97870f263700f46aa00d967821199b9bc5a120
+Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120
```
[Documentazione di Geth](https://geth.ethereum.org/docs)
-È possibile derivare nuove chiavi pubbliche dalla tua chiave privata ma non puoi derivare una chiave privata dalle chiavi pubbliche. È essenziale mantenere le proprie chiavi private al sicuro e, come suggerito dal nome, **PRIVATE**.
+È possibile derivare nuove chiavi pubbliche dalla tua chiave privata, ma non puoi derivare una chiave privata dalle chiavi pubbliche. È vitale mantenere le tue chiavi private al sicuro e, come suggerisce il nome, **PRIVATE**.
-Necessiti di una chiave privata per firmare i messaggi e le transazioni che producono una firma. Gli altri possono quindi prendere la firma per derivare la tua chiave pubblica, provando l'autore del messaggio. Nella tua applicazione puoi utilizzare una libreria Javascript per inviare transazioni alla rete.
+Hai bisogno di una chiave privata per firmare messaggi e transazioni che producono una firma. Altri possono quindi prendere la firma per derivare la tua chiave pubblica, dimostrando l'autore del messaggio. Nella tua applicazione, puoi utilizzare una libreria JavaScript per inviare transazioni alla rete.
-## Conti del contratto {#contract-accounts}
+## Account di contratto {#contract-accounts}
-Inoltre, i conti del contratto contengono un indirizzo esadecimale da 42 caratteri:
+Anche gli account di contratto hanno un indirizzo esadecimale di 42 caratteri:
Esempio:
`0x06012c8cf97bead5deae237070f9587f8e7a266d`
-L'indirizzo del contratto è solitamente dato alla distribuzione di un contratto alla Blockchain di Ethereum. L’indirizzo deriva da quello del creatore e dal numero di transazioni inviate da tale indirizzo (il “nonce”).
+L'indirizzo del contratto viene solitamente fornito quando un contratto viene distribuito sulla blockchain di Ethereum. L'indirizzo deriva dall'indirizzo del creatore e dal numero di transazioni inviate da quell'indirizzo (il "nonce").
-## Chiavi del validatore {#validators-keys}
+## Chiavi dei validatori {#validators-keys}
-Esiste inoltre un altro tipo di chiave su Ethereum, introdotto quando Ethereum è passato dal consenso basato sul proof-of-work al proof-of-stake. Queste sono le chiavi 'BLS' e sono usate per identificare i validatori. Queste chiavi possono esser aggregate efficientemente per ridurre la larghezza di banda necessaria affinché la rete raggiunga il consenso. Senza questa chiave, l'aggregazione della quota minima per un validatore saremme molto maggiore.
+C'è anche un altro tipo di chiave in Ethereum, introdotto quando Ethereum è passato dal consenso basato sulla prova di lavoro alla prova di stake. Queste sono le chiavi 'BLS' e vengono utilizzate per identificare i validatori. Queste chiavi possono essere aggregate in modo efficiente per ridurre la larghezza di banda richiesta alla rete per raggiungere il consenso. Senza questa aggregazione di chiavi, lo stake minimo per un validatore sarebbe molto più alto.
-[Di più sulle chiavi del validatore](/developers/docs/consensus-mechanisms/pos/keys/).
+[Maggiori informazioni sulle chiavi dei validatori](/developers/docs/consensus-mechanisms/pos/keys/).
## Una nota sui portafogli {#a-note-on-wallets}
-Un conto non è un portafoglio. Un portafoglio è un'interfaccia o un'applicazione che ti consente di interagire con il tuo conto di Ethereum, sia esso posseduto esternamente o di un contratto.
+Un account non è un portafoglio. Un portafoglio è un'interfaccia o un'applicazione che ti consente di interagire con il tuo account di Ethereum, che sia un account controllato esternamente o un account di contratto.
-## Dimostrazione visiva {#a-visual-demo}
+## Una demo visiva {#a-visual-demo}
-Fatti guidare da Austin attraverso le funzionalità di hash e le coppie di chiavi.
+Guarda Austin guidarti attraverso le funzioni di hash e le coppie di chiavi.
+ Prova l'endpoint nel playground
+
**Parametri**
@@ -308,15 +312,15 @@ Nessuno
**Restituisce**
-I dati restituiti precisi variano a seconda delle implementazioni del client. Tutti i client restituiscono `False` quando il nodo non si sta sincronizzando, e tutti i client restituiscono i seguenti campi.
+I dati precisi restituiti variano tra le implementazioni dei client. Tutti i client restituiscono `False` quando il nodo non si sta sincronizzando e tutti i client restituiscono i seguenti campi.
-`Object|Boolean`, un oggetto con i dati dello stato di sincronizzazione o `FALSE`, quando non è in sincronizzazione:
+`Object|Boolean`, Un oggetto con i dati dello stato di sincronizzazione o `FALSE`, quando non in sincronizzazione:
-- `startingBlock`: `QUANTITY` - Il blocco in cui è iniziata l'importazione (si ripristina soltanto dopo che la sincronizzazione ha raggiunto la sua testa)
-- `currentBlock`: `QUANTITY` - Il blocco corrente, uguale a eth_blockNumber
+- `startingBlock`: `QUANTITY` - Il blocco al quale è iniziata l'importazione (sarà ripristinato solo dopo che la sincronizzazione avrà raggiunto la sua testa)
+- `currentBlock`: `QUANTITY` - Il blocco attuale, uguale a eth_blockNumber
- `highestBlock`: `QUANTITY` - Il blocco più alto stimato
-Tuttavia, i singoli client potrebbero anche fornire ulteriori dati. Ad esempio, Geth, restituisce quanto segue:
+Tuttavia, i singoli client possono anche fornire dati aggiuntivi. Ad esempio, Geth restituisce quanto segue:
```json
{
@@ -357,7 +361,7 @@ Mentre Besu restituisce:
}
```
-Si rimanda alla documentazione del client specifico per ulteriori dettagli.
+Fai riferimento alla documentazione del tuo client specifico per maggiori dettagli.
**Esempio**
@@ -374,7 +378,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
highestBlock: '0x454'
}
}
-// O quando non sta sincronizzando
+// O quando non è in sincronizzazione
{
"id":1,
"jsonrpc": "2.0",
@@ -384,9 +388,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}
### eth_coinbase {#eth_coinbase}
-Restituisce l'indirizzo di coinbase del client.
+Restituisce l'indirizzo coinbase del client.
+
+
+ Prova l'endpoint nel playground
+
-> **Nota:** Questo metodo è stato deprecato alla **v1.14.0** e non è più supportato. Tentare di utilizzarlo risulterà in un errore "Metodo non supportato".
+> **Nota:** Questo metodo è stato deprecato a partire dalla **v1.14.0** e non è più supportato. Il tentativo di utilizzare questo metodo comporterà un errore "Method not supported".
**Parametri**
@@ -394,7 +402,7 @@ Nessuno
**Restituisce**
-`DATA`, 20 byte - l'indirizzo di coinbase corrente.
+`DATA`, 20 byte - l'indirizzo coinbase attuale.
**Esempio**
@@ -411,7 +419,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":6
### eth_chainId {#eth_chainId}
-Restituisce l'ID della catena utilizzato per firmare le transazioni protette da riproduzione.
+Restituisce l'ID della catena utilizzato per firmare le transazioni protette da replay.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
@@ -419,7 +431,7 @@ Nessuno
**Restituisce**
-`chainId`, valore esadecimale come stringa rappresentante l'intero dell'ID della catena corrente.
+`chainId`, valore esadecimale come stringa che rappresenta l'intero dell'id della catena attuale.
**Esempio**
@@ -436,7 +448,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67
### eth_mining {#eth_mining}
-Restituisce `true` se il client sta minando attivamente nuovi blocchi. Può restituire `true` soltanto per le reti di proof-of-work e potrebbe non essere disponibile in alcuni client da [La Fusione](/roadmap/merge/).
+Restituisce `true` se il client sta attivamente minando nuovi blocchi. Questo può restituire `true` solo per le reti a prova di lavoro e potrebbe non essere disponibile in alcuni client da [La Fusione](/roadmap/merge/).
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
@@ -451,7 +467,7 @@ Nessuno
```js
// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}'
-//
+
{
"id":71,
"jsonrpc": "2.0",
@@ -461,7 +477,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}
### eth_hashrate {#eth_hashrate}
-Restituisce il numero di hash al secondo con cui il nodo sta minando. Può restituire `true` soltanto per le reti di proof-of-work e potrebbe non essere disponibile in alcuni client da [La Fusione](/roadmap/merge/).
+Restituisce il numero di hash al secondo con cui il nodo sta minando. Questo può restituire `true` solo per le reti a prova di lavoro e potrebbe non essere disponibile in alcuni client da [La Fusione](/roadmap/merge/).
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
@@ -486,7 +506,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":7
### eth_gasPrice {#eth_gasprice}
-Restituisce una stima del prezzo corrente per gas, in wei. Ad esempio, il client di Besu esamina gli ultimi 100 blocchi e restituisce il prezzo unitario medio del gas di default.
+Restituisce una stima del prezzo del gas attuale in wei. Ad esempio, il client Besu esamina gli ultimi 100 blocchi e restituisce il prezzo unitario mediano del gas per impostazione predefinita.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
@@ -494,7 +518,7 @@ Nessuno
**Restituisce**
-`QUANTITY` - intero del prezzo corrente del gas in wei.
+`QUANTITY` - intero del prezzo del gas attuale in wei.
**Esempio**
@@ -513,13 +537,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":7
Restituisce un elenco di indirizzi posseduti dal client.
+
+ Prova l'endpoint nel playground
+
+
**Parametri**
Nessuno
**Restituisce**
-`Array of DATA`, 20 Byte - indirizzi posseduti dal client.
+`Array di DATA`, 20 Byte - indirizzi posseduti dal client.
**Esempio**
@@ -538,13 +566,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1
Restituisce il numero del blocco più recente.
+
+ Prova l'endpoint nel playground
+
+
**Parametri**
Nessuno
**Restituisce**
-`QUANTITY` - intero del numero di blocco corrente su cui è attivo il client.
+`QUANTITY` - intero del numero di blocco attuale su cui si trova il client.
**Esempio**
@@ -561,12 +593,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id
### eth_getBalance {#eth_getbalance}
-Restituisce il saldo del conto del dato indirizzo.
+Restituisce il saldo dell'account a un dato indirizzo.
+
+
+ Prova l'endpoint nel playground
+
**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)
+1. `DATA`, 20 Byte - indirizzo di cui controllare il saldo.
+2. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"`, o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
@@ -574,7 +610,7 @@ params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"]
**Restituisce**
-`QUANTITY` - intero del saldo corrente in wei.
+`QUANTITY` - intero del saldo attuale in wei.
**Esempio**
@@ -593,23 +629,28 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407
Restituisce il valore da una posizione di archiviazione a un dato indirizzo.
+
+ Prova l'endpoint nel playground
+
+
**Parametri**
-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)
+1. `DATA`, 20 Byte - indirizzo dell'archiviazione.
+2. `QUANTITY` - intero della posizione nell'archiviazione.
+3. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter)
**Restituisce**
`DATA` - il valore in questa posizione di archiviazione.
-**Esempio** Il calcolo della posizione corretta dipende dall'archiviazione da recuperare. Considera il seguente contratto distribuito su `0x295a70b2de5e3953354a6a8344e616ed314d7251` dall'indirizzo `0x391694e7e0b0cce554cb130d723a9d27458f9298`.
+**Esempio**
+Il calcolo della posizione corretta dipende dall'archiviazione da recuperare. Considera il seguente contratto distribuito a `0x295a70b2de5e3953354a6a8344e616ed314d7251` dall'indirizzo `0x391694e7e0b0cce554cb130d723a9d27458f9298`.
```
contract Storage {
uint pos0;
mapping(address => uint) pos1;
- function Storage() {
+ constructor() {
pos0 = 1234;
pos1[msg.sender] = 5678;
}
@@ -629,7 +670,7 @@ Recuperare un elemento della mappa è più difficile. La posizione di un element
keccak(LeftPad32(key, 0), LeftPad32(map position, 0))
```
-Ciò significa che per recuperare l'archiviazione in pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"] dobbiamo calcolare la posizione con:
+Questo significa che per recuperare l'archiviazione su pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"] dobbiamo calcolare la posizione con:
```js
keccak(
@@ -640,7 +681,7 @@ keccak(
)
```
-La console geth che viene fornita con la libreria web3 può essere utilizzata per effettuare il calcolo:
+La console di geth fornita con la libreria web3 può essere utilizzata per effettuare il calcolo:
```js
> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
@@ -649,7 +690,7 @@ undefined
"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"
```
-A questo punto, per recuperare l'archiviazione:
+Ora per recuperare l'archiviazione:
```js
curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
@@ -658,12 +699,16 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [
### eth_getTransactionCount {#eth_gettransactioncount}
-Restituisce il numero di transazioni _inviate_da un indirizzo.
+Restituisce il numero di transazioni _inviate_ da un indirizzo.
+
+
+ Prova l'endpoint nel playground
+
**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)
+1. `DATA`, 20 Byte - indirizzo.
+2. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -691,11 +736,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params
### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash}
-Restituisce il numero di transazioni in un blocco da un blocco corrispondente al dato hash del blocco.
+Restituisce il numero di transazioni in un blocco da un blocco che corrisponde all'hash del blocco fornito.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
-1. `DATA`, 32 byte - hash di un blocco
+1. `DATA`, 32 Byte - hash di un blocco
```js
params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
@@ -708,9 +757,9 @@ params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"]
**Esempio**
```js
-// Request
+// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}'
-// Result
+// Risultato
{
"id":1,
"jsonrpc": "2.0",
@@ -720,11 +769,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHa
### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber}
-Restituisce il numero di transazioni in un blocco corrispondente al numero di blocco specificato.
+Restituisce il numero di transazioni in un blocco che corrisponde al numero di blocco fornito.
+
+
+ Prova l'endpoint nel playground
+
**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 di un numero di blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter).
```js
params: [
@@ -739,9 +792,9 @@ params: [
**Esempio**
```js
-// Request
+// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}'
-// Result
+// Risultato
{
"id":1,
"jsonrpc": "2.0",
@@ -751,11 +804,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNu
### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash}
-Restituisce il numero di ommer in un blocco da un blocco che corrisponde all'hash del blocco specificato.
+Restituisce il numero di uncle in un blocco da un blocco che corrisponde all'hash del blocco fornito.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
-1. `DATA`, 32 Bytes - Hash di un blocco
+1. `DATA`, 32 Byte - hash di un blocco
```js
params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
@@ -763,14 +820,14 @@ params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"]
**Restituisce**
-`QUANTITY` - intero del numero di ommer in questo blocco.
+`QUANTITY` - intero del numero di uncle in questo blocco.
**Esempio**
```js
-// Request
+// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}'
-// Result
+// Risultato
{
"id":1,
"jsonrpc": "2.0",
@@ -780,11 +837,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","p
### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber}
-Restituisce il numero di ommer in un blocco da un blocco che corrisponde all'hash del blocco specificato.
+Restituisce il numero di uncle in un blocco da un blocco che corrisponde al numero di blocco fornito.
+
+
+ Prova l'endpoint nel playground
+
**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 di un numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -794,14 +855,14 @@ params: [
**Restituisce**
-`QUANTITY` - intero del numero di ommer in questo blocco.
+`QUANTITY` - intero del numero di uncle in questo blocco.
**Esempio**
```js
-// Request
+// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}'
-// Result
+// Risultato
{
"id":1,
"jsonrpc": "2.0",
@@ -811,12 +872,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber",
### eth_getCode {#eth_getcode}
-Restituisce il codice ad un dato indirizzo.
+Restituisce il codice a un dato indirizzo.
+
+
+ Prova l'endpoint nel playground
+
**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)
+1. `DATA`, 20 Byte - indirizzo
+2. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter)
```js
params: [
@@ -832,9 +897,9 @@ params: [
**Esempio**
```js
-// Request
+// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}'
-// Result
+// Risultato
{
"id":1,
"jsonrpc": "2.0",
@@ -844,16 +909,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA
### eth_sign {#eth_sign}
-Il metodo della firma calcola una firma specifica di Ethereum con: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`.
+Il metodo sign calcola una firma specifica di Ethereum con: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`.
-Aggiungendo un prefisso al messaggio si rende la firma calcolata riconoscibile come firma specifica di Ethereum. Ciò impedisce l'uso improprio in cui una dapp malevola può firmare i dati arbitrari (es. la transazione) e usare la firma per impersonare la vittima.
+L'aggiunta di un prefisso al messaggio rende la firma calcolata riconoscibile come una firma specifica di Ethereum. Questo previene abusi in cui una dApp malevola può firmare dati arbitrari (es. una transazione) e utilizzare la firma per impersonare la vittima.
Nota: l'indirizzo con cui firmare deve essere sbloccato.
**Parametri**
-1. `DATA`, 20 Bytes - indirizzo
-2. `DATA`, N byte - messaggio da firmare
+1. `DATA`, 20 Byte - indirizzo
+2. `DATA`, N Byte - messaggio da firmare
**Restituisce**
@@ -874,24 +939,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d37
### eth_signTransaction {#eth_signtransaction}
-Firma una transazione che può essere inviata alla rete in un secondo momento utilizzando [eth_sendRawTransaction](#eth_sendrawtransaction).
+Firma una transazione che può essere inviata alla rete in un momento successivo utilizzando [eth_sendRawTransaction](#eth_sendrawtransaction).
**Parametri**
1. `Object` - L'oggetto della transazione
- `type`:
-- `from`: `DATA`, 20 byte - L'indirizzo da cui viene inviata la transazione.
-- `to`: `DATA`, 20 byte - (facoltativo quando si crea un nuovo contratto) L'indirizzo a cui è indirizzata la transazione.
-- `gas`: `QUANTITY` - (facoltativo, predefinito: 90000) Intero del carburante fornito per l'esecuzione della transazione. Restituirà il carburante inutilizzato.
-- `gasPrice`: `QUANTITY` - (facoltativo, predefinito: To-Be-Determined) Intero del gasPrice usato per ogni unità di carburante pagata, in Wei.
-- `value`: `QUANTITY` - (facoltativo) Intero del valore inviato con questa transazione, in Wei.
-- `data`: `DATA` - Il codice compilato di un contratto OPPURE l'hash della firma del metodo richiamato e i parametri codificati.
-- `nonce`: `QUANTITY` - (facoltativo) Intero di un nonce. Ciò permette di sovrascrivere le proprie transazioni in sospeso che utilizzano lo stesso nonce.
+- `from`: `DATA`, 20 Byte - L'indirizzo da cui viene inviata la transazione.
+- `to`: `DATA`, 20 Byte - (opzionale quando si crea un nuovo contratto) L'indirizzo a cui è diretta la transazione.
+- `gas`: `QUANTITY` - (opzionale, predefinito: 90000) Intero del gas fornito per l'esecuzione della transazione. Restituirà il gas non utilizzato.
+- `gasPrice`: `QUANTITY` - (opzionale, predefinito: Da determinare) Intero del gasPrice utilizzato per ogni gas pagato, in Wei.
+- `value`: `QUANTITY` - (opzionale) Intero del valore inviato con questa transazione, in Wei.
+- `data`: `DATA` - Il codice compilato di un contratto OPPURE l'hash della firma del metodo invocato e dei parametri codificati.
+- `nonce`: `QUANTITY` - (opzionale) Intero di un nonce. Questo consente di sovrascrivere le proprie transazioni in sospeso che utilizzano lo stesso nonce.
**Restituisce**
-`DATA`, L'oggetto della transazione codificata in RLP, firmato dal conto specificato.
+`DATA`, L'oggetto della transazione codificato in RLP firmato dall'account specificato.
**Esempio**
@@ -908,19 +973,19 @@ curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","
### eth_sendTransaction {#eth_sendtransaction}
-Crea la transazione di chiamata del nuovo messaggio o la creazione di un contratto, se il campo dei dati contiene del codice, e la firma utilizzando il conto specificato in `from`.
+Crea una nuova transazione di chiamata di messaggio o la creazione di un contratto, se il campo dati contiene codice, e la firma utilizzando l'account specificato in `from`.
**Parametri**
-1. `Oggetto` - L'oggetto della transazione
+1. `Object` - L'oggetto della transazione
-- `from`: `DATA`, 20 byte - L'indirizzo da cui viene inviata la transazione.
-- `to`: `DATA`, 20 byte - (facoltativo quando si crea un nuovo contratto) L'indirizzo a cui è indirizzata la transazione.
-- `gas`: `QUANTITY` - (facoltativo, predefinito: 90000) Intero del carburante fornito per l'esecuzione della transazione. Restituirà il carburante inutilizzato.
-- `gasPrice`: `QUANTITY` - (facoltativo, predefinito: To-Be-Determined) Intero del gasPrice usato per ogni unità di carburante pagata.
-- `value`: `QUANTITY` - (facoltativo) Intero del valore inviato con questa transazione, in Wei.
-- `input`: `DATA` - Il codice compilato di un contratto O l'hash della firma del metodo invocato e i parametri codificati.
-- `nonce`: `QUANTITY` - (facoltativo) Intero di un nonce. Ciò permette di sovrascrivere le proprie transazioni in sospeso che utilizzano lo stesso nonce.
+- `from`: `DATA`, 20 Byte - L'indirizzo da cui viene inviata la transazione.
+- `to`: `DATA`, 20 Byte - (opzionale quando si crea un nuovo contratto) L'indirizzo a cui è diretta la transazione.
+- `gas`: `QUANTITY` - (opzionale, predefinito: 90000) Intero del gas fornito per l'esecuzione della transazione. Restituirà il gas non utilizzato.
+- `gasPrice`: `QUANTITY` - (opzionale, predefinito: Da determinare) Intero del gasPrice utilizzato per ogni gas pagato.
+- `value`: `QUANTITY` - (opzionale) Intero del valore inviato con questa transazione.
+- `input`: `DATA` - Il codice compilato di un contratto OPPURE l'hash della firma del metodo invocato e dei parametri codificati.
+- `nonce`: `QUANTITY` - (opzionale) Intero di un nonce. Questo consente di sovrascrivere le proprie transazioni in sospeso che utilizzano lo stesso nonce.
```js
params: [
@@ -938,9 +1003,9 @@ params: [
**Restituisce**
-`DATA`, 32 Bytes - l'hash della transazione, o l'hash zero se la transazione non è ancora disponibile.
+`DATA`, 32 Byte - l'hash della transazione, o l'hash zero se la transazione non è ancora disponibile.
-Usa [eth_getTransactionReceipt](#eth_gettransactionreceipt) quando hai creato un contratto per ottenere l'indirizzo del contratto dopo che la transazione è stata proposta in un blocco.
+Usa [eth_getTransactionReceipt](#eth_gettransactionreceipt) per ottenere l'indirizzo del contratto, dopo che la transazione è stata proposta in un blocco, quando hai creato un contratto.
**Esempio**
@@ -957,11 +1022,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{
### eth_sendRawTransaction {#eth_sendrawtransaction}
-Crea una nuova transazione di chiamata di messaggio o la stipula di un contratto, per le transazioni firmate.
+Crea una nuova transazione di chiamata di messaggio o la creazione di un contratto per le transazioni firmate.
**Parametri**
-1. `DATA`, L'oggetto transazione firmato.
+1. `DATA`, I dati della transazione firmata.
```js
params: [
@@ -971,9 +1036,9 @@ params: [
**Restituisce**
-`DATA`, 32 Bytes - l'hash della transazione, o l'hash zero se la transazione non è ancora disponibile.
+`DATA`, 32 Byte - l'hash della transazione, o l'hash zero se la transazione non è ancora disponibile.
-Usa [eth_getTransactionReceipt](#eth_gettransactionreceipt) quando hai creato un contratto per ottenere l'indirizzo del contratto dopo che la transazione è stata proposta in un blocco.
+Usa [eth_getTransactionReceipt](#eth_gettransactionreceipt) per ottenere l'indirizzo del contratto, dopo che la transazione è stata proposta in un blocco, quando hai creato un contratto.
**Esempio**
@@ -990,24 +1055,28 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params"
### eth_call {#eth_call}
-Esegue immediatamente una nuova chiamata di messaggio senza creare una transazione nella blockchain. Spesso utilizzato per eseguire le funzioni dei contratti intelligenti di sola lettura, ad esempio `balanceOf` per un contratto ERC-20.
+Esegue immediatamente una nuova chiamata di messaggio senza creare una transazione sulla blockchain. Spesso utilizzato per eseguire funzioni di contratto intelligente di sola lettura, ad esempio il `balanceOf` per un contratto ERC-20.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
-1. `Object` - L'oggetto della chiamata della transazione
+1. `Object` - L'oggetto della chiamata di transazione
-- `from`: `DATA`, 20 byte - (facoltativo) L'indirizzo da cui viene inviata la transazione.
-- `to`: `DATA`, 20 byte - L'indirizzo a cui è indirizzata la transazione.
-- `gas`: `QUANTITY` - (facoltativo) Intero del carburante fornito per l'esecuzione della transazione. eth_call consuma zero carburante, ma questo parametro potrebbe essere necessario per alcune esecuzioni.
-- `gasPrice`: `QUANTITY` - (facoltativo) Intero del gasPrice usato per ogni unità di carburante pagata
-- `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).
+- `from`: `DATA`, 20 Byte - (opzionale) L'indirizzo da cui viene inviata la transazione.
+- `to`: `DATA`, 20 Byte - L'indirizzo a cui è diretta la transazione.
+- `gas`: `QUANTITY` - (opzionale) Intero del gas fornito per l'esecuzione della transazione. eth_call consuma zero gas, ma questo parametro potrebbe essere necessario per alcune esecuzioni.
+- `gasPrice`: `QUANTITY` - (opzionale) Intero del gasPrice utilizzato per ogni gas pagato
+- `value`: `QUANTITY` - (opzionale) Intero del valore inviato con questa transazione
+- `input`: `DATA` - (opzionale) Hash della firma del metodo e dei parametri codificati. Per i dettagli vedi [Ethereum Contract ABI 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` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter)
**Restituisce**
-`DATA` - Il valore di ritorno del contratto eseguito.
+`DATA` - il valore restituito dal contratto eseguito.
**Esempio**
@@ -1024,15 +1093,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}]
### eth_estimateGas {#eth_estimategas}
-Genera e restituisce una stima di quanto gas è necessario per consentire il completamento della transazione. La transazione non verrà aggiunta alla blockchain. Si noti che la stima potrebbe esser significativamente superiore all'importo di gas effettivamente usato dalla transazione, per vari motivi, incluse le meccaniche dell'EVM e le prestazioni del nodo.
+Genera e restituisce una stima di quanto gas è necessario per consentire il completamento della transazione. La transazione non verrà aggiunta alla blockchain. Nota che la stima potrebbe essere significativamente superiore alla quantità di gas effettivamente utilizzata dalla transazione, per una serie di motivi tra cui le meccaniche della EVM e le prestazioni del nodo.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
-Vedi i parametri di [eth_call](#eth_call), tranne che tutte le proprietà sono facoltative. Se non è specificato alcun limite di gas, geth usa il limite di gas del blocco dal blocco in sospeso come limite massimo. Di conseguenza, la stima restituita potrebbe non esser sufficiente per eseguire la chiamata/transazione quando l'importo di gas è superiore al limite di gas del blocco.
+Vedi i parametri di [eth_call](#eth_call), tranne per il fatto che tutte le proprietà sono opzionali. Se non viene specificato alcun limite del gas, geth utilizza il limite del gas del blocco dal blocco in sospeso come limite superiore. Di conseguenza, la stima restituita potrebbe non essere sufficiente per eseguire la chiamata/transazione quando la quantità di gas è superiore al limite del gas del blocco in sospeso.
**Restituisce**
-`QUANTITY` - la quantità di gas utilizzato.
+`QUANTITY` - la quantità di gas utilizzata.
**Esempio**
@@ -1051,10 +1124,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see
Restituisce informazioni su un blocco tramite hash.
+
+ Prova l'endpoint nel playground
+
+
**Parametri**
-1. `DATA`, 32 byte - Hash di un blocco.
-2. `Boolean` - Se `true` restituisce gli oggetti di transazione completi, se `falso` solo gli hash delle transazioni.
+1. `DATA`, 32 Byte - Hash di un blocco.
+2. `Boolean` - Se `true` restituisce gli oggetti completi della transazione, se `false` solo gli hash delle transazioni.
```js
params: [
@@ -1065,27 +1142,27 @@ params: [
**Restituisce**
-`Object` - Un oggetto blocco, o `null` quando non viene trovato alcun blocco:
-
-- `number`: `QUANTITY` - il numero di blocco. `null` quando è in attesa del blocco.
-- `hash`: `DATA`, 32 byte - hash del blocco. `null` quando è in attesa del blocco.
-- `hash`: `DATA`, 32 byte - hash del blocco genitore.
-- `nonce`: `DATA`, 8 byte - hash del proof-of-work generato. `null` quando è in attesa del blocco.
-- `sha3Uncles`: `DATA`, 32 byte - SHA3 dei dati ommer del blocco.
-- `logsBloom`: `DATA`, 256 byte - il filtro bloom per i registri del blocco. `null` quando è in attesa del blocco.
-- `transactionsRoot`: `DATA`, 32 byte - la radice dell'albero delle transazioni del blocco.
-- `stateRoot`: `DATA`, 32 byte - la radice dell'albero di stato finale del blocco.
-- `receiptsRoot`: `DATA`, 32 byte - la radice dell'albero delle ricevute del blocco.
-- `miner`: `DATA`, 20 byte - l'indirizzo del beneficiario a cui sono state fornite le ricompense di mining.
+`Object` - Un oggetto blocco, o `null` quando non è stato trovato alcun blocco:
+
+- `number`: `QUANTITY` - il numero del blocco. `null` quando è un blocco in sospeso.
+- `hash`: `DATA`, 32 Byte - hash del blocco. `null` quando è un blocco in sospeso.
+- `parentHash`: `DATA`, 32 Byte - hash del blocco genitore.
+- `nonce`: `DATA`, 8 Byte - hash della prova di lavoro generata. `null` quando è un blocco in sospeso, `0x0` per i blocchi a prova di stake (da La Fusione)
+- `sha3Uncles`: `DATA`, 32 Byte - SHA3 dei dati degli uncle nel blocco.
+- `logsBloom`: `DATA`, 256 Byte - il filtro bloom per i log del blocco. `null` quando è un blocco in sospeso.
+- `transactionsRoot`: `DATA`, 32 Byte - la radice del trie delle transazioni del blocco.
+- `stateRoot`: `DATA`, 32 Byte - la radice del trie dello stato finale del blocco.
+- `receiptsRoot`: `DATA`, 32 Byte - la radice del trie delle ricevute del blocco.
+- `miner`: `DATA`, 20 Byte - l'indirizzo del beneficiario a cui sono state date le ricompense del blocco.
- `difficulty`: `QUANTITY` - intero della difficoltà per questo blocco.
- `totalDifficulty`: `QUANTITY` - intero della difficoltà totale della catena fino a questo blocco.
- `extraData`: `DATA` - il campo "dati extra" di questo blocco.
-- `size`: `QUANTITY` - intero in bytes della dimensione di questo blocco.
-- `gasLimit`: `QUANTITY` - il carburante massimo consentito in questo blocco.
-- `gasUsed`: `QUANTITY` - il carburante totale usato da tutte le transazioni in questo blocco.
-- `timestamp`: `QUANTITY` - la marca temporale unix relativa a quando il blocco è stato collazionato.
-- `transactions`: `Array` - Array di oggetti transazione, o hash di transazione da 32 byte a seconda dell'ultimo parametro specificato.
-- `uncles`: `Array` - Array di hash ommer.
+- `size`: `QUANTITY` - intero della dimensione di questo blocco in byte.
+- `gasLimit`: `QUANTITY` - il limite del gas massimo consentito in questo blocco.
+- `gasUsed`: `QUANTITY` - il gas totale utilizzato da tutte le transazioni in questo blocco.
+- `timestamp`: `QUANTITY` - il timestamp unix di quando il blocco è stato collazionato.
+- `transactions`: `Array` - Array di oggetti transazione, o hash di transazione di 32 Byte a seconda dell'ultimo parametro fornito.
+- `uncles`: `Array` - Array di hash degli uncle.
**Esempio**
@@ -1094,10 +1171,9 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}'
// Risultato
{
-{
-"jsonrpc": "2.0",
-"id": 1,
-"result": {
+ "jsonrpc": "2.0",
+ "id": 1,
+ "result": {
"difficulty": "0x4ea3f27bc",
"extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32",
"gasLimit": "0x1388",
@@ -1120,18 +1196,22 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0
"transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
"uncles": [
]
-}
+ }
}
```
### eth_getBlockByNumber {#eth_getblockbynumber}
-Restituisce informazioni su un blocco per numero di blocco.
+Restituisce informazioni su un blocco tramite numero di blocco.
+
+
+ Prova l'endpoint nel playground
+
**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).
-2. `Boolean` - Se `true` restituisce gli oggetti di transazione completi, se `falso` solo gli hash delle transazioni.
+1. `QUANTITY|TAG` - intero di un numero di blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter).
+2. `Boolean` - Se `true` restituisce gli oggetti completi della transazione, se `false` solo gli hash delle transazioni.
```js
params: [
@@ -1140,7 +1220,8 @@ params: [
]
```
-**Restituisce** Vedi [eth_getBlockByHash](#eth_getblockbyhash)
+**Restituisce**
+Vedi [eth_getBlockByHash](#eth_getblockbyhash)
**Esempio**
@@ -1153,11 +1234,15 @@ Per il risultato vedi [eth_getBlockByHash](#eth_getblockbyhash)
### eth_getTransactionByHash {#eth_gettransactionbyhash}
-Restituisce le informazioni su una transazione richiesta dall'hash della transazione.
+Restituisce le informazioni su una transazione richiesta tramite hash della transazione.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
-1. `DATA`, 32 byte - hash di una transazione
+1. `DATA`, 32 Byte - hash di una transazione
```js
params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
@@ -1165,22 +1250,22 @@ params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"]
**Restituisce**
-`Object` - Un oggetto transazione, oppure `null` quando non viene trovata alcuna transazione:
+`Object` - Un oggetto transazione, o `null` quando non è stata trovata alcuna transazione:
-- `blockHash`: `DATA`, 32 byte - hash del blocco in cui si trovava questa transazione. `null` quando è in sospeso.
-- `blockNumber`: `QUANTITY` - numero di blocco in cui si trovava questa transazione. `null` quando è in sospeso.
-- `from`: `DATA`, 20 byte - indirizzo del mittente.
-- `gas`: `QUANTITY` - carburante fornito dal mittente.
-- `gasPrice`: `QUANTITY` - prezzo del carburante fornito dal mittente in Wei.
-- `hash`: `DATA`, 32 byte - hash della transazione.
+- `blockHash`: `DATA`, 32 Byte - hash del blocco in cui si trovava questa transazione. `null` quando è in sospeso.
+- `blockNumber`: `QUANTITY` - numero del blocco in cui si trovava questa transazione. `null` quando è in sospeso.
+- `from`: `DATA`, 20 Byte - indirizzo del mittente.
+- `gas`: `QUANTITY` - gas fornito dal mittente.
+- `gasPrice`: `QUANTITY` - prezzo del gas fornito dal mittente in Wei.
+- `hash`: `DATA`, 32 Byte - hash della transazione.
- `input`: `DATA` - i dati inviati insieme alla transazione.
- `nonce`: `QUANTITY` - il numero di transazioni effettuate dal mittente prima di questa.
-- `to`: `DATA`, 20 byte - l'indirizzo del destinatario. `null` quando è una transazione di creazione del contratto.
-- `transactionIndex`: `QUANTITY` - intero della posizione dell'indice delle transazioni nel blocco. `null` quando è in sospeso.
+- `to`: `DATA`, 20 Byte - indirizzo del destinatario. `null` quando è una transazione di creazione di un contratto.
+- `transactionIndex`: `QUANTITY` - intero della posizione dell'indice della transazione nel blocco. `null` quando è in sospeso.
- `value`: `QUANTITY` - valore trasferito in Wei.
-- `v`: `QUANTITY` - ID di recupero ECDSA
-- `r`: `QUANTITY` - firma r ECDSA
-- `s`: `QUANTITY` - firma s ECDSA
+- `v`: `QUANTITY` - id di recupero ECDSA
+- `r`: `QUANTITY` - firma ECDSA r
+- `s`: `QUANTITY` - firma ECDSA s
**Esempio**
@@ -1212,11 +1297,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","param
### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex}
-Restituisce informazioni su una transazione per hash del blocco e posizione dell'indice della transazione.
+Restituisce informazioni su una transazione tramite hash del blocco e posizione dell'indice della transazione.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
-1. `DATA`, 32 byte - hash di un blocco.
+1. `DATA`, 32 Byte - hash di un blocco.
2. `QUANTITY` - intero della posizione dell'indice della transazione.
```js
@@ -1226,24 +1315,29 @@ params: [
]
```
-**Restituisce** Vedi [eth_getTransactionByHash](#eth_gettransactionbyhash)
+**Restituisce**
+Vedi [eth_getTransactionByHash](#eth_gettransactionbyhash)
**Esempio**
```js
-// Request
+// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
```
-Risultato vedi [eth_getBlockByHash](#eth_gettransactionbyhash)
+Per il risultato vedi [eth_getTransactionByHash](#eth_gettransactionbyhash)
### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex}
-Restituisce informazioni su una transazione per hash del blocco e posizione dell'indice della transazione.
+Restituisce informazioni su una transazione tramite numero di blocco e posizione dell'indice della transazione.
+
+
+ Prova l'endpoint nel playground
+
**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` - un numero di blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter).
2. `QUANTITY` - la posizione dell'indice della transazione.
```js
@@ -1253,51 +1347,53 @@ params: [
]
```
-**Restituisce** Vedi [eth_getTransactionByHash](#eth_gettransactionbyhash)
+**Restituisce**
+Vedi [eth_getTransactionByHash](#eth_gettransactionbyhash)
**Esempio**
```js
-// Request
+// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}'
```
-Risultato vedi [eth_getBlockByHash](#eth_gettransactionbyhash)
+Per il risultato vedi [eth_getTransactionByHash](#eth_gettransactionbyhash)
### eth_getTransactionReceipt {#eth_gettransactionreceipt}
-Restituisce la ricevuta di una transazione tramite l'hash di transazione.
+Restituisce la ricevuta di una transazione tramite hash della transazione.
-**Nota** che la ricevuta non è disponibile per le transazioni in sospeso.
+**Nota** Che la ricevuta non è disponibile per le transazioni in sospeso.
**Parametri**
-1. `DATA`, 32 Bytes - hash di una transazione
+1. `DATA`, 32 Byte - hash di una transazione
```js
params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"]
```
-**Restituisce** `Object` - Un oggetto ricevuta della transazione, o `null` quando non è stata trovata nessuna ricevuta:
-
-- `transactionHash`: `DATA`, 32 byte - hash della transazione.
-- `transactionIndex`: `QUANTITY` - intero della posizione dell'indice delle transazioni nel blocco.
-- `blockHash`: `DATA`, 32 byte - hash del blocco in cui si trovava questa transazione.
-- `blockNumber`: `QUANTITY` - numero di blocco in cui si trovava questa transazione.
-- `from`: `DATA`, 20 byte - indirizzo del mittente.
-- `to`: `DATA`, 20 byte - l'indirizzo del destinatario. null quando è una transazione di creazione del contratto.
-- `cumulativeGasUsed`: `QUANTITY` - La quantità totale di carburante usato nel blocco per l'esecuzione della transazione.
-- `effectiveGasPrice` : `QUANTITY` - La somma della commissione di base e delle mance pagata per unità di carburante.
-- `gasUsed`: `QUANTITY` - La quantità di carburante usato solo da questa specifica transazione.
-- `contractAddress`: `DATA`, 20 byte - L'indirizzo del contratto creato, se la transazione consisteva nella creazione di un contratto, altrimenti `null`.
-- `logs`: `Array` - Array di oggetti di registro generati da questa transazione.
-- `logsBloom`: `DATA`, 256 byte - Filtro Bloom per i client leggeri per recuperare rapidamente i registri correlati.
-- `type`: `QUANTITY`: intero del tipo di transazione, `0x0` per le transazioni ereditarie, `0x1` per i tipi di elenco d'accesso, `0x2` per le commissioni dinamiche.
-
-Restituisce anche _in alternativa_:
-
-- `root` : `DATA` 32 bytes dello stateRoot post-transazione (pre Byzantium)
-- `status`: `QUANTITY` o `1` (successo) o `0` (insuccesso)
+**Restituisce**
+`Object` - Un oggetto ricevuta della transazione, o `null` quando non è stata trovata alcuna ricevuta:
+
+- `transactionHash `: `DATA`, 32 Byte - hash della transazione.
+- `transactionIndex`: `QUANTITY` - intero della posizione dell'indice della transazione nel blocco.
+- `blockHash`: `DATA`, 32 Byte - hash del blocco in cui si trovava questa transazione.
+- `blockNumber`: `QUANTITY` - numero del blocco in cui si trovava questa transazione.
+- `from`: `DATA`, 20 Byte - indirizzo del mittente.
+- `to`: `DATA`, 20 Byte - indirizzo del destinatario. null quando è una transazione di creazione di un contratto.
+- `cumulativeGasUsed` : `QUANTITY ` - La quantità totale di gas utilizzata quando questa transazione è stata eseguita nel blocco.
+- `effectiveGasPrice` : `QUANTITY` - La somma della commissione di base e della mancia pagata per unità di gas.
+- `gasUsed `: `QUANTITY ` - La quantità di gas utilizzata solo da questa specifica transazione.
+- `contractAddress `: `DATA`, 20 Byte - L'indirizzo del contratto creato, se la transazione era una creazione di un contratto, altrimenti `null`.
+- `logs`: `Array` - Array di oggetti log, che questa transazione ha generato.
+- `logsBloom`: `DATA`, 256 Byte - Filtro Bloom per i client leggeri per recuperare rapidamente i log correlati.
+- `type`: `QUANTITY` - intero del tipo di transazione, `0x0` per le transazioni legacy, `0x1` per i tipi di lista di accesso, `0x2` per le commissioni dinamiche.
+
+Restituisce anche _uno dei seguenti_ :
+
+- `root` : `DATA` 32 byte della radice dello stato post-transazione (pre Byzantium)
+- `status`: `QUANTITY` o `1` (successo) o `0` (fallimento)
**Esempio**
@@ -1312,15 +1408,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para
"blockHash":
"0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3",
"blockNumber": "0xeff35f",
- "contractAddress": null, // string of the address if it was created
+ "contractAddress": null, // stringa dell'indirizzo se è stato creato
"cumulativeGasUsed": "0xa12515",
"effectiveGasPrice": "0x5a9c688d4",
"from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7",
"gasUsed": "0xb4c8",
"logs": [{
- // logs as returned by getFilterLogs, etc.
+ // log come restituiti da getFilterLogs, ecc.
}],
- "logsBloom": "0x00...0", // 256 byte bloom filter
+ "logsBloom": "0x00...0", // filtro bloom di 256 byte
"status": "0x1",
"to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2",
"transactionHash":
@@ -1333,12 +1429,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para
### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex}
-Restituisce informazioni su un ommer di un blocco in base all'hash e alla posizione dell'indice dell'ommer.
+Restituisce informazioni su un uncle di un blocco tramite hash e posizione dell'indice dell'uncle.
+
+
+ Prova l'endpoint nel playground
+
**Parametri**
-1. `DATA`, 32 byte - hash di un blocco.
-2. `QUANTITY` - La posizione dell'indice dell'ommer.
+1. `DATA`, 32 Byte - L'hash di un blocco.
+2. `QUANTITY` - La posizione dell'indice dell'uncle.
```js
params: [
@@ -1347,27 +1447,32 @@ params: [
]
```
-**Restituisce** Vedi [eth_getBlockByHash](#eth_getblockbyhash)
+**Restituisce**
+Vedi [eth_getBlockByHash](#eth_getblockbyhash)
**Esempio**
```js
-// Request
+// Richiesta
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}'
```
Per il risultato vedi [eth_getBlockByHash](#eth_getblockbyhash)
-**Nota**: Un ommer non contiene transazioni individuali.
+**Nota**: Un uncle non contiene transazioni individuali.
### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex}
-Restituisce informazioni su un ommer di un blocco in base al numero e alla posizione dell'indice dell'ommer.
+Restituisce informazioni su un uncle di un blocco tramite numero e posizione dell'indice dell'uncle.
+
+
+ Prova l'endpoint nel playground
+
**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).
-2. `QUANTITY` - la posizione dell'indice dell'ommer.
+1. `QUANTITY|TAG` - un numero di blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, come nel [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter).
+2. `QUANTITY` - la posizione dell'indice dell'uncle.
```js
params: [
@@ -1376,9 +1481,10 @@ params: [
]
```
-**Restituisce** Vedi [eth_getBlockByHash](#eth_getblockbyhash)
+**Restituisce**
+Vedi [eth_getBlockByHash](#eth_getblockbyhash)
-**Nota**: Un ommer non contiene transazioni individuali.
+**Nota**: Un uncle non contiene transazioni individuali.
**Esempio**
@@ -1391,23 +1497,25 @@ Per il risultato vedi [eth_getBlockByHash](#eth_getblockbyhash)
### eth_newFilter {#eth_newfilter}
-Crea un oggetto filtro, basato sulle opzioni di filtro, per avvertire quando lo stato cambia (registri). Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges).
+Crea un oggetto filtro, basato sulle opzioni del filtro, per notificare quando lo stato cambia (log).
+Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges).
-**Una nota per specificare i filtri degli argomenti:** Gli argomenti dipendono dall'ordine. Una transazione con un registro con argomenti [A, B] sarà abbinata ai seguenti filtri tematici:
+**Una nota sulla specifica dei filtri degli argomenti (topic):**
+Gli argomenti dipendono dall'ordine. Una transazione con un log con argomenti [A, B] corrisponderà ai seguenti filtri di argomenti:
-- `[]` "qualsiasi"
-- `[A]`: "A in prima posizione (e tutto il resto segue)"
-- `[null, B]`: "tutto nella prima posizione e B nella seconda (e tutto il resto segue)"
-- `[A, B]`: "A in prima posizione e B in seconda (e tutto il resto segue)"
-- `[[A, B], [A, B]]`: "(A OR B) in prima posizione e (A OR B) in seconda posizione (e tutto il resto segue)"
+- `[]` "qualsiasi cosa"
+- `[A]` "A in prima posizione (e qualsiasi cosa dopo)"
+- `[null, B]` "qualsiasi cosa in prima posizione E B in seconda posizione (e qualsiasi cosa dopo)"
+- `[A, B]` "A in prima posizione E B in seconda posizione (e qualsiasi cosa dopo)"
+- `[[A, B], [A, B]]` "(A O B) in prima posizione E (A O B) in seconda posizione (e qualsiasi cosa dopo)"
- **Parametri**
1. `Object` - Le opzioni del filtro:
-- `fromBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero intero del blocco, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato o `"pending"`, `"earliest"` per le transazioni non ancora presenti in un blocco.
-- `toBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero intero del blocco, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato o `"pending"`, `"earliest"` per le transazioni non ancora presenti in un blocco.
-- `address`: `DATA|Array`, 20 byte - (facoltativo) L'indirizzo del contratto oppure un elenco di indirizzi da cui dovrebbero avere origine i registri.
-- `topics`: `Array of DATA`, - (facoltativo) Array di argomenti `DATA` a 32 byte. Gli argomenti dipendono dall'ordine. Ogni argomento può anche essere una matrice di DATA con opzioni "OR".
+- `fromBlock`: `QUANTITY|TAG` - (opzionale, predefinito: `"latest"`) Numero di blocco intero, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato, o `"pending"`, `"earliest"` per le transazioni non ancora in un blocco.
+- `toBlock`: `QUANTITY|TAG` - (opzionale, predefinito: `"latest"`) Numero di blocco intero, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato, o `"pending"`, `"earliest"` per le transazioni non ancora in un blocco.
+- `address`: `DATA|Array`, 20 Byte - (opzionale) Indirizzo del contratto o un elenco di indirizzi da cui dovrebbero originare i log.
+- `topics`: `Array di DATA`, - (opzionale) Array di argomenti `DATA` di 32 Byte. Gli argomenti dipendono dall'ordine. Ogni argomento può anche essere un array di DATA con opzioni "o".
```js
params: [
@@ -1427,7 +1535,8 @@ params: [
]
```
-**Restituisce** `QUANTITY` - Un ID filtro.
+**Restituisce**
+`QUANTITY` - Un id del filtro.
**Esempio**
@@ -1444,11 +1553,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topic
### eth_newBlockFilter {#eth_newblockfilter}
-Crea un filtro nel nodo, per avvisare quando arriva un nuovo blocco. Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges).
+Crea un filtro nel nodo, per notificare quando arriva un nuovo blocco.
+Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges).
-**Parametri** Nessuno
+**Parametri**
+Nessuno
-**Restituisce** `QUANTITY` - Un ID filtro.
+**Restituisce**
+`QUANTITY` - Un id del filtro.
**Esempio**
@@ -1465,11 +1577,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],
### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter}
-Crea un filtro nel nodo, per avvisare quando arrivano nuove transazioni in sospeso. Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges).
+Crea un filtro nel nodo, per notificare quando arrivano nuove transazioni in sospeso.
+Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges).
-**Parametri** Nessuno
+**Parametri**
+Nessuno
-**Restituisce** `QUANTITY` - Un ID filtro.
+**Restituisce**
+`QUANTITY` - Un id del filtro.
**Esempio**
@@ -1486,11 +1601,12 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter"
### eth_uninstallFilter {#eth_uninstallfilter}
-Disinstalla un filtro con un dato ID. Dovrebbe essere sempre chiamato quando l'orologio non è più necessario. Inoltre i filtri scadono quando non vengono richiesti con [eth_getFilterChanges](#eth_getfilterchanges) per un periodo di tempo.
+Disinstalla un filtro con l'id fornito. Dovrebbe sempre essere chiamato quando l'osservazione non è più necessaria.
+Inoltre, i filtri scadono quando non vengono richiesti con [eth_getFilterChanges](#eth_getfilterchanges) per un periodo di tempo.
**Parametri**
-1. `QUANTITY` - L'ID del filtro.
+1. `QUANTITY` - L'id del filtro.
```js
params: [
@@ -1498,7 +1614,8 @@ params: [
]
```
-**Restituisce** `Boolean` - `true` se il filtro è stato disinstallato con successo, altrimenti `false`.
+**Restituisce**
+`Boolean` - `true` se il filtro è stato disinstallato con successo, altrimenti `false`.
**Esempio**
@@ -1515,11 +1632,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["
### eth_getFilterChanges {#eth_getfilterchanges}
-Metodo di sondaggio per un filtro, che restituisce un array di registri che si sono verificati dall'ultimo sondaggio.
+Metodo di polling per un filtro, che restituisce un array di log che si sono verificati dall'ultimo polling.
**Parametri**
-1. `QUANTITY` - L'ID del filtro.
+1. `QUANTITY` - l'id del filtro.
```js
params: [
@@ -1527,20 +1644,22 @@ params: [
]
```
-**Restituisce** `Array` - Array di oggetti registro, o un array vuoto se nulla è cambiato dall'ultimo sondaggio.
-
-- Per i filtri creati con `eth_newBlockFilter` vengono restituiti hash di blocco (`DATA`, 32 byte), ad esempio `["0x3454645634534..."]`.
-- Per i filtri creati con `eth_newPendingTransactionFiltro` vengono restituiti hash di transazione (`DATA`, 32 byte), ad esempio `["0x6345343454645..."]`.
-- Per i filtri creati con `eth_newFiltro` i registri sono oggetti con i seguenti parametri:
- - `removed`: `TAG` - `true` quando il registro è stato rimosso, a causa di una riorganizzazione a catena. `false` se è un registro valido.
- - `transactionIndex`: `QUANTITY` - numero intero della posizione dell'indice del registro nel blocco. `null` quando il registro è in sospeso.
- - `transactionIndex`: `QUANTITY` - numero intero del registro della posizione dell'indice delle transazioni da cui è stato creato. `null` quando il registro è in sospeso.
- - `transactionHash`: `DATA`, 32 byte - hash delle transazioni da cui è stato creato il registro. `null` quando il registro è in sospeso.
- - `blockHash`: `DATA`, 32 byte - hash del blocco in cui si trovava questo registro. `null` quando è in sospeso. `null` quando il registro è in sospeso.
- - `blockNumber`: `QUANTITY` il numero di blocco in cui si trovava questo registro. `null` quando è in sospeso. `null` quando il registro è in sospeso.
- - `address`: `DATI`, 20 byte - indirizzo da cui è nato questo registro.
- - `data`: `DATA` - contiene zero o più argomenti non indicizzati da 32 byte del registro.
- - `topics`: `Array of DATA` - Array da 0 a 432 byte di `DATA` di argomenti di registro indicizzati. (In _solidity_: il primo argomento è l'_hash_ della firma dell'evento (ad es. `Deposit(address,bytes32,uint256)`), tranne se hai dichiarato l'evento con lo specificatore `anonymous`
+**Restituisce**
+`Array` - Array di oggetti log, o un array vuoto se nulla è cambiato dall'ultimo polling.
+
+- Per i filtri creati con `eth_newBlockFilter` il ritorno sono hash di blocco (`DATA`, 32 Byte), es., `["0x3454645634534..."]`.
+- Per i filtri creati con `eth_newPendingTransactionFilter ` il ritorno sono hash di transazione (`DATA`, 32 Byte), es., `["0x6345343454645..."]`.
+- Per i filtri creati con `eth_newFilter` i log sono oggetti con i seguenti parametri:
+ - `removed`: `TAG` - `true` quando il log è stato rimosso, a causa di una riorganizzazione della catena. `false` se è un log valido.
+ - `logIndex`: `QUANTITY` - intero della posizione dell'indice del log nel blocco. `null` quando è un log in sospeso.
+ - `transactionIndex`: `QUANTITY` - intero della posizione dell'indice della transazione da cui è stato creato il log. `null` quando è un log in sospeso.
+ - `transactionHash`: `DATA`, 32 Byte - hash delle transazioni da cui è stato creato questo log. `null` quando è un log in sospeso.
+ - `blockHash`: `DATA`, 32 Byte - hash del blocco in cui si trovava questo log. `null` quando è in sospeso. `null` quando è un log in sospeso.
+ - `blockNumber`: `QUANTITY` - il numero del blocco in cui si trovava questo log. `null` quando è in sospeso. `null` quando è un log in sospeso.
+ - `address`: `DATA`, 20 Byte - indirizzo da cui ha avuto origine questo log.
+ - `data`: `DATA` - dati di log non indicizzati a lunghezza variabile. (In _solidity_: zero o più argomenti di log non indicizzati di 32 Byte.)
+ - `topics`: `Array di DATA` - Array da 0 a 4 `DATA` di 32 Byte di argomenti di log indicizzati. (In _solidity_: Il primo argomento è l'_hash_ della firma dell'evento (es., `Deposit(address,bytes32,uint256)`), a meno che tu non abbia dichiarato l'evento con lo specificatore `anonymous`.)
+
- **Esempio**
```js
@@ -1567,11 +1686,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":[
### eth_getFilterLogs {#eth_getfilterlogs}
-Restituisce un array di tutti i registri corrispondenti al filtro con un dato ID.
+Restituisce un array di tutti i log che corrispondono al filtro con l'id fornito.
**Parametri**
-1. `QUANTITY` - L'ID del filtro.
+1. `QUANTITY` - L'id del filtro.
```js
params: [
@@ -1579,7 +1698,8 @@ params: [
]
```
-**Restituisce** Vedi [eth_getBlockByHash](#eth_getfilterchanges)
+**Restituisce**
+Vedi [eth_getFilterChanges](#eth_getfilterchanges)
**Esempio**
@@ -1588,21 +1708,21 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}'
```
-Risultato vedi [eth_getFilterChanges](#eth_getfilterchanges)
+Per il risultato vedi [eth_getFilterChanges](#eth_getfilterchanges)
### eth_getLogs {#eth_getlogs}
-Restituisce un array di tutti i registri che corrispondono a un dato oggetto filtro.
+Restituisce un array di tutti i log che corrispondono a un dato oggetto filtro.
**Parametri**
1. `Object` - Le opzioni del filtro:
-- `fromBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero intero del blocco, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato o `"pending"`, `"earliest"` per le transazioni non ancora presenti in un blocco.
-- `toBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero intero del blocco, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato o `"pending"`, `"earliest"` per le transazioni non ancora presenti in un blocco.
-- `address`: `DATA|Array`, 20 byte - (facoltativo) L'indirizzo del contratto oppure un elenco di indirizzi da cui dovrebbero avere origine i registri.
-- `topics`: `Array of DATA`, - (facoltativo) Array di argomenti `DATA` a 32 byte. Gli argomenti dipendono dall'ordine. Ogni argomento può anche essere una matrice di DATA con opzioni "OR".
-- `blockhash`: `DATI`, 32 byte - (facoltativo , **future**) Con l'aggiunta di EIP-234, `blockHash` sarà una nuova opzione di filtro che limita i registri restituiti al singolo blocco con l'hash `blockHash` da 32 byte. L'utilizzo di `blockHash` equivale a `fromBlock` = `toBlock` = il numero di blocco con hash `blockHash`. Se `blockHash` è presente nei criteri di filtraggio, non sono permessi né `fromBlock` né `toBlock`.
+- `fromBlock`: `QUANTITY|TAG` - (opzionale, predefinito: `"latest"`) Numero di blocco intero, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato, o `"pending"`, `"earliest"` per le transazioni non ancora in un blocco.
+- `toBlock`: `QUANTITY|TAG` - (opzionale, predefinito: `"latest"`) Numero di blocco intero, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato, o `"pending"`, `"earliest"` per le transazioni non ancora in un blocco.
+- `address`: `DATA|Array`, 20 Byte - (opzionale) Indirizzo del contratto o un elenco di indirizzi da cui dovrebbero originare i log.
+- `topics`: `Array di DATA`, - (opzionale) Array di argomenti `DATA` di 32 Byte. Gli argomenti dipendono dall'ordine. Ogni argomento può anche essere un array di DATA con opzioni "o".
+- `blockHash`: `DATA`, 32 Byte - (opzionale, **futuro**) Con l'aggiunta dell'EIP-234, `blockHash` sarà una nuova opzione di filtro che limita i log restituiti al singolo blocco con l'hash di 32 byte `blockHash`. L'utilizzo di `blockHash` equivale a `fromBlock` = `toBlock` = il numero di blocco con hash `blockHash`. Se `blockHash` è presente nei criteri di filtro, non sono consentiti né `fromBlock` né `toBlock`.
```js
params: [
@@ -1614,7 +1734,8 @@ params: [
]
```
-**Restituisce** Vedi [eth_getBlockByHash](#eth_getfilterchanges)
+**Restituisce**
+Vedi [eth_getFilterChanges](#eth_getfilterchanges)
**Esempio**
@@ -1623,15 +1744,15 @@ params: [
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}'
```
-Risultato vedi [eth_getFilterChanges](#eth_getfilterchanges)
+Per il risultato vedi [eth_getFilterChanges](#eth_getfilterchanges)
## Esempio di utilizzo {#usage-example}
-### Distribuire un contratto utilizzando JSON_RPC {#deploying-contract}
+### Distribuire un contratto usando JSON_RPC {#deploying-contract}
-Questa sezione include una dimostrazione di come distribuire un contratto utilizzando solo l'interfaccia RPC. Esistono vie alternative per la distribuzione di contratti in cui questa complessità viene eliminata tramite astrazione, ad esempio utilizzando librerie costruite partendo dall'interfaccia RPC, come [web3. s](https://web3js.readthedocs.io/) e [web3.py](https://github.com/ethereum/web3.py). Queste astrazioni sono generalmente più facili da capire e meno soggette a errori, ma è comunque utile capire cosa succede dietro le quinte.
+Questa sezione include una dimostrazione di come distribuire un contratto usando solo l'interfaccia RPC. Esistono percorsi alternativi per distribuire contratti in cui questa complessità viene astratta, ad esempio, usando librerie costruite sopra l'interfaccia RPC come [web3.js](https://web3js.readthedocs.io/) e [web3.py](https://github.com/ethereum/web3.py). Queste astrazioni sono generalmente più facili da comprendere e meno soggette a errori, ma è comunque utile capire cosa succede dietro le quinte.
-Di seguito, trovi un semplice contratto intelligente chiamato `Multiply7`, che sarà distribuito usando l'interfaccia JSON-RPC a un nodo di Ethereum. Questo tutorial presuppone che il lettore stia già eseguendo un nodo Geth. Maggiori informazioni sui nodi e sui client sono disponibili [qui](/developers/docs/nodes-and-clients/run-a-node). Fare riferimento alla documentazione del singolo [client](/developers/docs/nodes-and-clients/) per capire come avviare HTTP JSON-RPC per i client non-Geth. La maggior parte dei client serve di default su `localhost:8545`.
+Di seguito è riportato un semplice contratto intelligente chiamato `Multiply7` che verrà distribuito usando l'interfaccia JSON-RPC su un nodo Ethereum. Questo tutorial presuppone che il lettore stia già eseguendo un nodo Geth. Maggiori informazioni su nodi e client sono disponibili [qui](/developers/docs/nodes-and-clients/run-a-node). Si prega di fare riferimento alla documentazione dei singoli [client](/developers/docs/nodes-and-clients/) per vedere come avviare l'HTTP JSON-RPC per i client non Geth. La maggior parte dei client serve per impostazione predefinita su `localhost:8545`.
```javascript
contract Multiply7 {
@@ -1643,7 +1764,7 @@ contract Multiply7 {
}
```
-La prima cosa da fare è assicurarsi che l'interfaccia HTTP RPC sia abilitata. Questo significa che forniamo a Geth il flag `--http` all'avvio. In questo esempio usiamo il nodo Geth su una catena di sviluppo privata. Utilizzando questo approccio non abbiamo bisogno di ether sulla rete reale.
+La prima cosa da fare è assicurarsi che l'interfaccia HTTP RPC sia abilitata. Ciò significa che forniamo a Geth il flag `--http` all'avvio. In questo esempio usiamo il nodo Geth su una catena di sviluppo privata. Usando questo approccio non abbiamo bisogno di ether sulla rete reale.
```bash
geth --http --dev console 2>>geth.log
@@ -1651,26 +1772,26 @@ geth --http --dev console 2>>geth.log
Questo avvierà l'interfaccia HTTP RPC su `http://localhost:8545`.
-Possiamo verificare l'esecuzione dell'interfaccia recuperando l'indirizzo (ottenendo il primo indirizzo dall'array di conti) e il saldo di coinbase utilizzando [curl](https://curl.se). Si noti che i dati in questi esempi saranno diversi sul nodo locale. Se vuoi provare questi comandi, sostituisci i parametri di richiesta nella seconda richiesta di curl con il risultato restituito dalla prima.
+Possiamo verificare che l'interfaccia sia in esecuzione recuperando l'indirizzo coinbase (ottenendo il primo indirizzo dall'array degli account) e il saldo usando [curl](https://curl.se). Si prega di notare che i dati in questi esempi differiranno sul proprio nodo locale. Se si desidera provare questi comandi, sostituire i parametri di richiesta nella seconda richiesta curl con il risultato restituito dalla prima.
```bash
-curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[]", "id":1}' -H "Content-Type: application/json" localhost:8545
+curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545
{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]}
curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"}
```
-Poiché i numeri sono soggetti a codifica esadecimale, il saldo viene restituito in wei sotto forma di stringa esadecimale. Se vogliamo ottenere il saldo in ether sotto forma di numero possiamo utilizzare web3 dalla console Geth.
+Poiché i numeri sono codificati in esadecimale, il saldo viene restituito in wei come stringa esadecimale. Se vogliamo avere il saldo in ether come numero, possiamo usare web3 dalla console di Geth.
```javascript
web3.fromWei("0x1639e49bba16280000", "ether")
// "410"
```
-Ora che ci sono ether nella nostra catena di sviluppo privata, possiamo distribuire il contratto. Il primo passo è quello di compilare il contratto Multiply7 al codice di byte che può essere inviato all'EVM. Per installare solc, il compilatore Solidity, seguire la [documentazione Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Potresti voler utilizzare una versione `solc` più vecchia che corrisponda [ alla versione del compilatore utilizzata per il nostro esempio](https://github.com/ethereum/solidity/releases/tag/v0.4.20).)
+Ora che c'è un po' di ether sulla nostra catena di sviluppo privata, possiamo distribuire il contratto. Il primo passo è compilare il contratto Multiply7 in byte code che può essere inviato all'EVM. Per installare solc, il compilatore Solidity, seguire la [documentazione di Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Potresti voler usare una versione precedente di `solc` per farla corrispondere alla [versione del compilatore usata per il nostro esempio](https://github.com/ethereum/solidity/releases/tag/v0.4.20)).
-Il passo successivo è quello di compilare il contratto Multiply7 al codice di byte che può essere inviato all'EVM.
+Il passo successivo è compilare il contratto Multiply7 in byte code che può essere inviato all'EVM.
```bash
echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin
@@ -1680,58 +1801,58 @@ Binary:
6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029
```
-Ora che abbiamo il codice compilato, dobbiamo determinare quanto carburante occorre per distribuirlo. L'interfaccia RPC ha un metodo `eth_estimateGas` che ci darà una stima.
+Ora che abbiamo il codice compilato dobbiamo determinare quanto gas costa distribuirlo. L'interfaccia RPC ha un metodo `eth_estimateGas` che ci fornirà una stima.
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545
{"jsonrpc":"2.0","id":5,"result":"0x1c31e"}
```
-E infine distribuiamo il contratto.
+E infine distribuire il contratto.
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545
{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"}
```
-La transazione è accettata dal nodo e viene restituito un hash di transazione. Questo hash può essere usato per tracciare la transazione. Il passo successivo è quello di determinare l'indirizzo dove il nostro contratto è distribuito. Ogni transazione eseguita creerà una ricevuta. Questa ricevuta contiene varie informazioni sulla transazione, ad esempio, in quale blocco è stata inclusa e quanto carburante è stato usato dall'EVM. Se una transazione crea un contratto, ne conterrà anche l'indirizzo. Possiamo recuperare la ricevuta con il metodo RPC `eth_getTransactionReceipt`.
+La transazione viene accettata dal nodo e viene restituito un hash della transazione. Questo hash può essere usato per tracciare la transazione. Il passo successivo è determinare l'indirizzo in cui è distribuito il nostro contratto. Ogni transazione eseguita creerà una ricevuta. Questa ricevuta contiene varie informazioni sulla transazione, come in quale blocco è stata inclusa la transazione e quanto gas è stato usato dall'EVM. Se una transazione crea un contratto, conterrà anche l'indirizzo del contratto. Possiamo recuperare la ricevuta con il metodo RPC `eth_getTransactionReceipt`.
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545
{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
```
-Il nostro contratto è stato creato su `0x4d03d617d700cf81935d7f797f4e2ae719648262`. Un risultato nullo invece di una ricevuta significa che la transazione non è stata ancora inclusa in un blocco. Attendere un attimo e controllare se il proprio client di consenso è in esecuzione, quindi riprovare.
+Il nostro contratto è stato creato su `0x4d03d617d700cf81935d7f797f4e2ae719648262`. Un risultato nullo invece di una ricevuta significa che la transazione non è ancora stata inclusa in un blocco. Attendi un momento, controlla se il tuo client di consenso è in esecuzione e riprova.
#### Interagire con i contratti intelligenti {#interacting-with-smart-contract}
In questo esempio invieremo una transazione usando `eth_sendTransaction` al metodo `multiply` del contratto.
-`eth_sendTransaction` richiede diversi argomenti, in particolare `from`, `to` e `data`. `From` è l'indirizzo pubblico del nostro conto, mentre `to` è l'indirizzo del contratto. L'argomento `data` contiene un payload che definisce quale metodo deve essere chiamato e con quali argomenti. È qui che entra in gioco l'[ABI (interfaccia binaria dell'applicazione)](https://docs.soliditylang.org/en/latest/abi-spec.html). L'ABI è un file JSON che determina come definire e codificare i dati per l'EVM.
+`eth_sendTransaction` richiede diversi argomenti, in particolare `from`, `to` e `data`. `From` è l'indirizzo pubblico del nostro account e `to` è l'indirizzo del contratto. L'argomento `data` contiene un payload che definisce quale metodo deve essere chiamato e con quali argomenti. È qui che entra in gioco l'[ABI (interfaccia binaria dell'applicazione)](https://docs.soliditylang.org/en/latest/abi-spec.html). L'ABI è un file JSON che definisce come definire e codificare i dati per l'EVM.
-I byte del payload definiscono quale metodo viene chiamato nel contratto. Si tratta dei primi 4 byte dall'hash Keccak sul nome della funzione e sui suoi tipi di argomento, con codifica esadecimale. La funzione di moltiplicazione accetta un uint che è un alias per uint256. Ci ritroviamo quindi con:
+I byte del payload definiscono quale metodo nel contratto viene chiamato. Si tratta dei primi 4 byte dall'hash Keccak sul nome della funzione e sui tipi dei suoi argomenti, codificati in esadecimale. La funzione multiply accetta un uint che è un alias per uint256. Questo ci lascia con:
```javascript
web3.sha3("multiply(uint256)").substring(0, 10)
// "0xc6888fa1"
```
-Il passo successivo è codificare gli argomenti. Vi è solo un uint256, ad esempio il valore 6. L'ABI ha una sezione che specifica come codificare i tipi uint256.
+Il passo successivo è codificare gli argomenti. C'è solo un uint256, diciamo, il valore 6. L'ABI ha una sezione che specifica come codificare i tipi uint256.
-`int: enc(X)` è la codifica big-endian in complemento a due di X, riempita sul lato di ordine superiore (sinistro) con 0xff per X negativo e con zero > byte per X positivo, in modo tale che la lunghezza sia un multiplo di 32 byte.
+`int: enc(X)` è la codifica in complemento a due big-endian di X, riempita sul lato di ordine superiore (sinistra) con 0xff per X negativo e con zero byte per X positivo in modo tale che la lunghezza sia un multiplo di 32 byte.
-Si ottiene la codifica `0000000000000000000000000000000000000000000000000000000000000006`.
+Questo si codifica in `0000000000000000000000000000000000000000000000000000000000000006`.
-Combinando il selettore di funzione e l'argomento codificato, otterremo i dati `0xc6888fa100000000000000000000000000000000000000000000000000000000000000000000000000000006`.
+Combinando il selettore della funzione e l'argomento codificato, i nostri dati saranno `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`.
-A questo punto possiamo inviare al nodo:
+Questo può ora essere inviato al nodo:
```bash
curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545
{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"}
```
-Dall'invio di una transazione, è stato restituito un hash di transazione. Recuperando la ricevuta si ottiene:
+Poiché è stata inviata una transazione, è stato restituito un hash della transazione. Recuperando la ricevuta si ottiene:
```javascript
{
@@ -1755,19 +1876,19 @@ Dall'invio di una transazione, è stato restituito un hash di transazione. Recup
}
```
-La ricevuta contiene un registro. Questo registro è stato generato da EVM sull'esecuzione della transazione e incluso nella ricevuta. La funzione `multiply` mostra che l'evento `Print` è stato lanciato con i tempi di input 7. Poiché l'argomento per l'evento `Print` era un uint256, possiamo decodificarlo secondo le regole ABI, ottenendo così il decimale 42 previsto. Oltre ai dati, vale la pena notare che gli argomenti possono essere utilizzati per determinare quale evento ha creato il registro:
+La ricevuta contiene un log. Questo log è stato generato dall'EVM all'esecuzione della transazione e incluso nella ricevuta. La funzione `multiply` mostra che l'evento `Print` è stato sollevato con l'input moltiplicato per 7. Poiché l'argomento per l'evento `Print` era un uint256, possiamo decodificarlo secondo le regole dell'ABI, il che ci lascerà con il decimale atteso 42. A parte i dati, vale la pena notare che i topic possono essere usati per determinare quale evento ha creato il log:
```javascript
web3.sha3("Print(uint256)")
// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"
```
-Questa è stata solo una breve introduzione su alcuni dei compiti più comuni, dimostrando l'uso diretto del JSON-RPC.
+Questa era solo una breve introduzione ad alcune delle attività più comuni, che dimostra l'uso diretto della JSON-RPC.
## Argomenti correlati {#related-topics}
-- [Specifiche di JSON-RPC](http://www.jsonrpc.org/specification)
-- [ Nodi e client](/developers/docs/nodes-and-clients/)
+- [Specifica JSON-RPC](http://www.jsonrpc.org/specification)
+- [Nodi e client](/developers/docs/nodes-and-clients/)
- [API JavaScript](/developers/docs/apis/javascript/)
-- [API del backend](/developers/docs/apis/backend/)
-- [Client di esecuzione](/developers/docs/nodes-and-clients/#execution-clients)
+- [API di backend](/developers/docs/apis/backend/)
+- [Client di esecuzione](/developers/docs/nodes-and-clients/#execution-clients)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/blocks/index.md b/public/content/translations/it/developers/docs/blocks/index.md
index ff09aa44f91..a482db9c5ad 100644
--- a/public/content/translations/it/developers/docs/blocks/index.md
+++ b/public/content/translations/it/developers/docs/blocks/index.md
@@ -1,152 +1,153 @@
---
title: Blocchi
-description: 'Panoramica dei blocchi nella blockchain Ethereum: struttura dati, a cosa servono e come sono fatti.'
+description: "Una panoramica dei blocchi nella blockchain di Ethereum: la loro struttura dei dati, perché sono necessari e come vengono creati."
lang: it
---
-I blocchi sono un insieme di transazioni che contengono un hash del blocco precedente nella catena. Per questo motivo, sono collegati l'uno all'altro nella catena, perché gli hash vengono calcolati crittograficamente dai dati del blocco. Questi impedisce anche le frodi, perché un cambiamento in qualsiasi blocco nella cronologia invaliderebbe tutti i blocchi successivi, dato che gli hash successivi cambierebbero e tutti coloro che eseguono la blockchain se ne accorgerebbero.
+I blocchi sono lotti di transazioni con un hash del blocco precedente nella catena. Questo collega i blocchi insieme (in una catena) perché gli hash sono derivati crittograficamente dai dati del blocco. Ciò previene le frodi, perché una modifica in qualsiasi blocco nella storia invaliderebbe tutti i blocchi successivi, poiché tutti gli hash successivi cambierebbero e chiunque esegua la blockchain se ne accorgerebbe.
## Prerequisiti {#prerequisites}
-Quello dei blocchi è un argomento piuttosto basico. Ma, per aiutarti a comprendere meglio questa pagina, ti consigliamo innanzitutto di leggere sui [Conti](/developers/docs/accounts/), sulle [Transazioni](/developers/docs/transactions/) e la nostra [introduzione a Ethereum](/developers/docs/intro-to-ethereum/).
+I blocchi sono un argomento molto accessibile ai principianti. Ma per aiutarti a comprendere meglio questa pagina, ti consigliamo di leggere prima [Account](/developers/docs/accounts/), [Transazioni](/developers/docs/transactions/) e la nostra [introduzione a Ethereum](/developers/docs/intro-to-ethereum/).
## Perché i blocchi? {#why-blocks}
-Per far sì che tutti i partecipanti della rete Ethereum siano sincronizzati e concordino sulla cronologia esatta delle transazioni, le transazioni vengono raggruppate in blocchi. Significa che decine (o centinaia) di transazioni vengono inviate, approvate e sincronizzate in una volta sola.
+Per garantire che tutti i partecipanti sulla rete [Ethereum](/) mantengano uno stato sincronizzato e concordino sulla cronologia precisa delle transazioni, raggruppiamo le transazioni in blocchi. Ciò significa che dozzine (o centinaia) di transazioni vengono confermate, concordate e sincronizzate tutte in una volta.
- _Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-Scaglionando gli invii, diamo a tutti i partecipanti della rete abbastanza tempo per giungere al consenso: anche se arrivano decine di richieste di transazione al secondo, i blocchi su Ethereum vengono creati e inviati a Ethereum solo più o meno ogni quindici secondi.
+Distanziando le conferme, diamo a tutti i partecipanti della rete abbastanza tempo per raggiungere il consenso: anche se le richieste di transazione si verificano dozzine di volte al secondo, i blocchi vengono creati e confermati su Ethereum solo una volta ogni dodici secondi.
## Come funzionano i blocchi {#how-blocks-work}
-Per preservare la cronologia delle transazioni, i blocchi sono ordinati in modo rigoroso (ogni nuovo blocco che viene creato contiene un riferimento al blocco padre) e anche le transazioni all'interno del blocco sono ordinate altrettanto rigorosamente. A parte in rari casi, in ogni momento, tutti i partecipanti della rete concordano sul numero e sulla cronologia esatta dei blocchi e lavorano per raggruppare le richieste di transazione live nel blocco successivo.
+Per preservare la cronologia delle transazioni, i blocchi sono rigorosamente ordinati (ogni nuovo blocco creato contiene un riferimento al suo blocco genitore) e anche le transazioni all'interno dei blocchi sono rigorosamente ordinate. Tranne in rari casi, in qualsiasi momento, tutti i partecipanti sulla rete concordano sul numero esatto e sulla cronologia dei blocchi e stanno lavorando per raggruppare le attuali richieste di transazione in tempo reale nel blocco successivo.
-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.
+Una volta che un blocco viene assemblato da un validatore selezionato casualmente sulla rete, viene propagato al resto della rete; tutti i nodi aggiungono questo blocco alla fine della loro blockchain e un nuovo validatore viene selezionato per creare il blocco successivo. L'esatto processo di assemblaggio dei blocchi e il processo di conferma/consenso sono attualmente specificati dal protocollo "prova di stake" di Ethereum.
-## Protocollo Proof of Stake {#proof-of-work-protocol}
+## Protocollo di prova di stake {#proof-of-stake-protocol}
-Proof of Stake significa quanto segue:
+La prova di stake significa quanto segue:
-- I nodi di convalida devono mettere in staking 32 ETH in un contratto di deposito come garanzia contro i comportamenti malevoli. Questo aiuta a proteggere la rete, poiché le attività palesemente disoneste portano alla distruzione di parte o dell'intero stake.
-- In ogni slot (a distanza di dodici secondi), un validatore è selezionato casualmente per essere il propositore del blocco. Questo raggruppa le transazioni, le esegue e determina un nuovo 'stato'. Avvolge queste informazioni in un blocco e lo passa agli altri validatori.
-- Gli altri validatori che vengono a conoscenza di un nuovo blocco ri-eseguono le transazioni per assicurare di acconsentire alla modifica proposta allo stato globale. Supponendo che il blocco sia valido, lo aggiungono al proprio database.
-- Se un validatore è a conoscenza di due blocchi in conflitto per lo stesso slot, usa il proprio algoritmo di scelta della diramazione per selezionare quello supportato da più ETH in staking.
+- I nodi di validazione devono mettere in stake 32 ETH in un contratto di deposito come garanzia contro comportamenti scorretti. Questo aiuta a proteggere la rete perché un'attività palesemente disonesta porta alla distruzione di parte o di tutto quello stake.
+- In ogni slot (distanziati di dodici secondi l'uno dall'altro) un validatore viene selezionato casualmente per essere il proponente del blocco. Raggruppa le transazioni, le esegue e determina un nuovo 'stato'. Racchiude queste informazioni in un blocco e lo trasmette agli altri validatori.
+- Gli altri validatori che vengono a conoscenza del nuovo blocco rieseguono le transazioni per assicurarsi di concordare con la modifica proposta allo stato globale. Supponendo che il blocco sia valido, lo aggiungono al proprio database.
+- Se un validatore viene a conoscenza di due blocchi in conflitto per lo stesso slot, utilizza il proprio algoritmo di scelta della biforcazione per scegliere quello supportato dalla maggior quantità di ETH in stake.
-[Maggiori informazioni sul Proof of Stake](/developers/docs/consensus-mechanisms/pos)
+[Maggiori informazioni sulla prova di stake](/developers/docs/consensus-mechanisms/pos)
## Cosa c'è in un blocco? {#block-anatomy}
-In un blocco sono contenute molte informazioni. Al livello più alto, un blocco contiene i seguenti campi:
-
-| Campo | Descrizione |
-|:------------------- |:--------------------------------------------------------- |
-| `slot` | lo slot a cui appartiene il blocco |
-| `indice_proponente` | l'ID del validatore che propone il blocco |
-| `parent_root` | l'hash del blocco precedente |
-| `state_root` | l'hash radice dell'oggetto di stato |
-| `corpo` | un oggetto contenente più campi, come definito di seguito |
-
-Il blocco `body` contiene a sua volta diversi campi:
-
-| Campo | Descrizione |
-|:-------------------- |:---------------------------------------------------------------------- |
-| `randao_reveal` | un valore utilizzato per selezionare il prossimo proponente di blocchi |
-| `et1_data` | informazioni sul contratto di deposito |
-| `graffiti` | dati arbitrari utilizzati per contrassegnare blocchi |
-| `proposer_slashings` | elenco di validatori da tagliare |
-| `taglio_attestatori` | elenco di attestatori da tagliare |
-| `attestazioni` | elenco di attestazioni a favore del blocco corrente |
-| `depositi` | elenco dei nuovi depositi nel contratto di deposito |
-| `uscite_volontarie` | elenco di validatori che escono dalla rete |
-| `sync_aggregate` | sottoinsieme di validatori, utilizzato per servire i client leggeri |
-| `execution_payload` | transazioni passate dal client di esecuzione |
-
-Il campo `attestations` contiene un elenco di tutte le attestazioni nel blocco. Le attestazioni hanno il proprio tipo di dati, contenente diversi pezzi di dati. Ogni attestazione contiene:
-
-| Campo | Descrizione |
-|:------------------ |:-------------------------------------------------------------------- |
-| `aggregation_bits` | un elenco dei validatori che hanno partecipato a questa attestazione |
-| `dati` | un contenitore con diversi campi secondari |
-| `firma` | firma aggregata di tutti i validatori attestanti |
+Ci sono molte informazioni contenute all'interno di un blocco. Al livello più alto, un blocco contiene i seguenti campi:
+
+| Campo | Descrizione |
+| :--------------- | :---------------------------------------------------- |
+| `slot` | lo slot a cui appartiene il blocco |
+| `proposer_index` | l'ID del validatore che propone il blocco |
+| `parent_root` | l'hash del blocco precedente |
+| `state_root` | l'hash radice dell'oggetto di stato |
+| `body` | un oggetto contenente diversi campi, come definito di seguito |
+
+Il `body` del blocco contiene a sua volta diversi campi:
+
+| Campo | Descrizione |
+| :------------------- | :----------------------------------------------- |
+| `randao_reveal` | un valore utilizzato per selezionare il prossimo proponente del blocco |
+| `eth1_data` | informazioni sul contratto di deposito |
+| `graffiti` | dati arbitrari utilizzati per etichettare i blocchi |
+| `proposer_slashings` | elenco di validatori da punire |
+| `attester_slashings` | elenco di attestatori da punire |
+| `attestations` | elenco di attestazioni fatte contro gli slot precedenti |
+| `deposits` | elenco di nuovi depositi al contratto di deposito |
+| `voluntary_exits` | elenco di validatori che escono dalla rete |
+| `sync_aggregate` | sottoinsieme di validatori utilizzati per servire i client leggeri |
+| `execution_payload` | transazioni passate dal client di esecuzione |
+
+Il campo `attestations` contiene un elenco di tutte le attestazioni nel blocco. Le attestazioni hanno il proprio tipo di dati che contiene diverse informazioni. Ogni attestazione contiene:
+
+| Campo | Descrizione |
+| :----------------- | :------------------------------------------------------------- |
+| `aggregation_bits` | un elenco di quali validatori hanno partecipato a questa attestazione |
+| `data` | un contenitore con più sottocampi |
+| `signature` | firma aggregata di un insieme di validatori rispetto alla parte `data` |
Il campo `data` nell'`attestation` contiene quanto segue:
-| Campo | Descrizione |
-|:------------------- |:--------------------------------------------------------- |
-| `slot` | lo slot cui si riferisce l'attestazione |
-| `indice` | indici per l'attestazione dei validatori |
-| `beacon_block_root` | l'hash radice del blocco Beacon contenente questo oggetto |
-| `fonte` | l'ultimo punto di controllo giustificato |
-| `obiettivo` | il blocco di confine dell'ultima epoca |
+| Campo | Descrizione |
+| :------------------ | :-------------------------------------------------------------- |
+| `slot` | lo slot a cui si riferisce l'attestazione |
+| `index` | indici per i validatori attestanti |
+| `beacon_block_root` | l'hash radice del blocco della beacon chain visto come testa della catena |
+| `source` | l'ultimo checkpoint giustificato |
+| `target` | l'ultimo blocco di confine dell'epoca |
-L'esecuzione delle transazioni nell'`execution_payload` aggiorna lo stato globale. Tutti i client ri-eseguono le transazioni nell'`execution_payload` per assicurare che il nuovo stato corrisponda a quello nel campo `state_root` del nuovo blocco. Così, i client, possono dire che un nuovo blocco è valido e sicuro da aggiungere alla loro blockchain. L'`execution payload` stesso è un oggetto composto da diversi campi. Inoltre, esiste un `execution_payload_header`, contenente importanti informazioni sommarie sui dati di esecuzione. Queste strutture di dati sono organizzate come segue:
+L'esecuzione delle transazioni nell'`execution_payload` aggiorna lo stato globale. Tutti i client rieseguono le transazioni nell'`execution_payload` per assicurarsi che il nuovo stato corrisponda a quello nel campo `state_root` del nuovo blocco. È così che i client possono stabilire che un nuovo blocco è valido e sicuro da aggiungere alla loro blockchain. L'`execution payload` stesso è un oggetto con diversi campi. C'è anche un `execution_payload_header` che contiene importanti informazioni riassuntive sui dati di esecuzione. Queste strutture di dati sono organizzate come segue:
L'`execution_payload_header` contiene i seguenti campi:
-| Campo | Descrizione |
-|:------------------- |:------------------------------------------------------------------------------------- |
-| `parent_hash` | hash del blocco padre |
-| `fee_recipient` | indirizzo del conto a cui pagare le commissioni sulla transazione |
-| `state_root` | hash radice per lo stato globale dopo l'applicazione delle modifiche in questo blocco |
-| `receipts_root` | hash del trie delle ricevute delle transazioni |
-| `logs_bloom` | struttura di dati contenente i registri dell'evento |
-| `prev_randao` | valore usato nella selezione casuale del validatore |
-| `numero_blocco` | numero del blocco corrente |
-| `limite_gas` | carburante massimo consentito in questo blocco |
-| `gas_utilizzato` | quantità effettiva di carburante usata in questo blocco |
-| `marca oraria` | tempo di blocco |
-| `dati_extra` | dati aggiuntivi arbitrari come byte grezzi |
-| `fee_base_per_gas` | il valore base della commissione |
-| `hash_del_blocco` | Hash del blocco di esecuzione |
-| `transactions_root` | hash radice delle transazioni nel payload |
-| `withdrawal_root` | hash radice del prelievo nel payload |
-
-Lo stesso `execution_payload` contiene quanto segue (si noti che è identico all'intestazione, tranne per il fatto che, invece dell'hash radice delle transazioni, include l'elenco effettivo delle transazioni e informazioni sui prelievi):
-
-| Campo | Descrizione |
-|:------------------ |:----------------------------------------------------------------------------------- |
-| `parent_hash` | hash del blocco genitore |
-| `fee_recipient` | indirizzo del conto a cui pagare le commissioni di transazione |
-| `stato_del_root` | hash radice per lo stato globale, dopo l'applicazione di modifiche in questo blocco |
-| `receipts_root` | hash dell'albero delle ricevute di transazione |
-| `logs_bloom` | struttura dei dati contenente registri di eventi |
-| `prev_randao` | valore usato in una selezione casuale del validatore |
-| `numero_blocco` | numero del blocco corrente |
-| `limite_gas` | gas massimo allocato in questo blocco |
-| `gas_utilizzato` | l'attuale ammontare di gas utilizzato in questo blocco |
-| `marca oraria` | tempo del blocco |
-| `dati_extra` | dati arbitrari aggiuntivi, in byte grezzi |
-| `fee_base_per_gas` | il valore base della commissione |
-| `hash_del_blocco` | Hash dell'esecuzione del blocco |
-| `transazioni` | elenco delle transazioni da eseguire |
-| `prelievi` | elenco degli oggetti prelievo |
-
-L'elenco dei `withdrawals` contiene oggetti `withdrawal` strutturati nel modo seguente:
-
-| Campo | Descrizione |
-|:---------------- |:------------------------------------ |
-| `address` | indirizzo del conto che ha prelevato |
-| `importo` | importo del prelievo |
-| `indice` | valore dell'indice di prelievo |
-| `validatorIndex` | valore dell'indice del validatore |
+| Campo | Descrizione |
+| :------------------ | :------------------------------------------------------------------ |
+| `parent_hash` | hash del blocco genitore |
+| `fee_recipient` | indirizzo dell'account a cui pagare le commissioni della transazione |
+| `state_root` | hash radice per lo stato globale dopo aver applicato le modifiche in questo blocco |
+| `receipts_root` | hash del trie delle ricevute delle transazioni |
+| `logs_bloom` | struttura dati contenente i log degli eventi |
+| `prev_randao` | valore utilizzato nella selezione casuale dei validatori |
+| `block_number` | il numero del blocco corrente |
+| `gas_limit` | limite del gas massimo consentito in questo blocco |
+| `gas_used` | la quantità effettiva di gas utilizzata in questo blocco |
+| `timestamp` | il tempo del blocco |
+| `extra_data` | dati aggiuntivi arbitrari come byte grezzi |
+| `base_fee_per_gas` | il valore della commissione di base |
+| `block_hash` | Hash del blocco di esecuzione |
+| `transactions_root` | hash radice delle transazioni nel payload |
+| `withdrawal_root` | hash radice dei prelievi nel payload |
+
+L'`execution_payload` stesso contiene quanto segue (nota che questo è identico all'intestazione tranne per il fatto che invece dell'hash radice delle transazioni include l'elenco effettivo delle transazioni e le informazioni sui prelievi):
+
+| Campo | Descrizione |
+| :----------------- | :------------------------------------------------------------------ |
+| `parent_hash` | hash del blocco genitore |
+| `fee_recipient` | indirizzo dell'account a cui pagare le commissioni della transazione |
+| `state_root` | hash radice per lo stato globale dopo aver applicato le modifiche in questo blocco |
+| `receipts_root` | hash del trie delle ricevute delle transazioni |
+| `logs_bloom` | struttura dati contenente i log degli eventi |
+| `prev_randao` | valore utilizzato nella selezione casuale dei validatori |
+| `block_number` | il numero del blocco corrente |
+| `gas_limit` | limite del gas massimo consentito in questo blocco |
+| `gas_used` | la quantità effettiva di gas utilizzata in questo blocco |
+| `timestamp` | il tempo del blocco |
+| `extra_data` | dati aggiuntivi arbitrari come byte grezzi |
+| `base_fee_per_gas` | il valore della commissione di base |
+| `block_hash` | Hash del blocco di esecuzione |
+| `transactions` | elenco di transazioni da eseguire |
+| `withdrawals` | elenco di oggetti di prelievo |
+
+L'elenco `withdrawals` contiene oggetti `withdrawal` strutturati nel seguente modo:
+
+| Campo | Descrizione |
+| :--------------- | :--------------------------------- |
+| `address` | indirizzo dell'account che ha prelevato |
+| `amount` | importo del prelievo |
+| `index` | valore dell'indice di prelievo |
+| `validatorIndex` | valore dell'indice del validatore |
## Tempo di blocco {#block-time}
-Il tempo di blocco si riferisce al tempo che separa i blocchi. In Ethereum, il tempo è diviso in unità da dodici secondi, dette 'slot'. In ogni slot viene selezionato un singolo validatore per proporre un blocco. Supponendo che tutti i validatori siano online e totalmente operativi, ci sarà un blocco in ogni slot, a significare che il tempo del blocco è 12 secondi. Tuttavia, occasionalmente, i validatori potrebbero essere offline quando chiamati a proporre un blocco, a significare che talvolta gli slot possono rimanere vuoti.
+Il tempo di blocco si riferisce al tempo che separa i blocchi. In Ethereum, il tempo è diviso in unità di dodici secondi chiamate 'slot'. In ogni slot viene selezionato un singolo validatore per proporre un blocco. Supponendo che tutti i validatori siano online e perfettamente funzionanti, ci sarà un blocco in ogni slot, il che significa che il tempo di blocco è di 12s. Tuttavia, occasionalmente i validatori potrebbero essere offline quando chiamati a proporre un blocco, il che significa che gli slot a volte possono rimanere vuoti.
-Questa implementazione differisce dai sistemi basati sul proof-of-work, in cui i tempi di blocco sono probabilistici e regolati dalla difficoltà di mining target del protocollo. Il [tempo medio di blocco](https://etherscan.io/chart/blocktime) di Ethereum è un esempio perfetto da cui è possibile desumere il passaggio da proof-of-work a proof-of-stake in base alla coerenza del nuovo tempo di blocco da 12 secondi.
+Questa implementazione differisce dai sistemi basati sulla prova di lavoro in cui i tempi di blocco sono probabilistici e regolati dalla difficoltà di mining target del protocollo. Il [tempo medio di blocco](https://etherscan.io/chart/blocktime) di Ethereum è un perfetto esempio di ciò, in cui la transizione dalla prova di lavoro alla prova di stake può essere chiaramente dedotta in base alla coerenza del nuovo tempo di blocco di 12s.
-## Dimensioni del blocco {#block-size}
+## Dimensione del blocco {#block-size}
-Un'ultima nota importante: i blocchi stessi sono limitati in termini di dimensioni. Ogni blocco ha una dimensione prevista di 30 milioni di gas, ma la dimensione dei blocchi aumenterà o diminuirà in base alle esigenze della rete, fino al limite di 60 milioni di gas (2x dimensioni del blocco previste). Il limite di gas del blocco è regolabile per eccesso o per difetto con un fattore di 1/1024 rispetto al limite di gas del blocco precedente. Di conseguenza, i validatori possono modificare il limite di gas del blocco tramite il consenso. La quantità totale di carburante usato da tutte le transazioni nel blocco deve essere inferiore al limite di carburante del blocco. Ciò è importante perché evita che i blocchi siano arbitrariamente grandi. Se i blocchi potessero essere arbitrariamente grandi, i nodi completi meno performanti, gradualmente, non riuscirebbero più stare al passo con la rete per via dei requisiti di spazio e velocità. Più grande è il blocco, maggiore sarà la potenza di calcolo richiesta per elaborarlo in tempo per il prossimo slot. Questa è una forza centralizzante, a cui si resiste limitando le dimensioni dei blocchi.
+Un'ultima nota importante è che i blocchi stessi hanno dimensioni limitate. Ogni blocco ha una dimensione target di 30 milioni di gas, ma la dimensione dei blocchi aumenterà o diminuirà in base alle richieste della rete, fino al limite del gas del blocco di 60 milioni di gas (2 volte la dimensione target del blocco). Il limite del gas del blocco può essere regolato verso l'alto o verso il basso di un fattore di 1/1024 rispetto al limite del gas del blocco precedente. Di conseguenza, i validatori possono modificare il limite del gas del blocco attraverso il consenso. La quantità totale di gas spesa da tutte le transazioni nel blocco deve essere inferiore al limite del gas del blocco. Questo è importante perché garantisce che i blocchi non possano essere arbitrariamente grandi. Se i blocchi potessero essere arbitrariamente grandi, i nodi completi meno performanti smetterebbero gradualmente di essere in grado di tenere il passo con la rete a causa dei requisiti di spazio e velocità. Più grande è il blocco, maggiore è la potenza di calcolo richiesta per elaborarli in tempo per lo slot successivo. Questa è una forza centralizzante, a cui si resiste limitando le dimensioni dei blocchi.
## Letture consigliate {#further-reading}
-_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
## Argomenti correlati {#related-topics}
- [Transazioni](/developers/docs/transactions/)
- [Gas](/developers/docs/gas/)
-- [Proof of Stake](/developers/docs/consensus-mechanisms/pos)
+- [Prova di stake](/developers/docs/consensus-mechanisms/pos)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/bridges/index.md b/public/content/translations/it/developers/docs/bridges/index.md
index 774262b4f01..4278680dfe7 100644
--- a/public/content/translations/it/developers/docs/bridges/index.md
+++ b/public/content/translations/it/developers/docs/bridges/index.md
@@ -1,135 +1,137 @@
---
-title: Bridge
-description: Una panoramica del bridging per gli sviluppatori
+title: Ponti
+description: Una panoramica sui ponti per gli sviluppatori
lang: it
---
-Con la rapida crescita di soluzioni di [ridimensionamento](/developers/docs/scaling/) delle blockchain di L1 e L2, affiancata da un numero sempre maggiore di applicazioni decentralizzate che operano cross-chain, il bisogno di comunicazione e di movimentazione di risorse tra catene sono diventati una parte essenziale nell'infrastruttura della rete. Esistono diverse tipologie di ponti per renderlo possibile.
+Con la proliferazione delle blockchain L1 e delle soluzioni di [scalabilità](/developers/docs/scaling/) L2, insieme a un numero sempre crescente di applicazioni decentralizzate che diventano cross-chain, la necessità di comunicazione e movimento di asset tra le catene è diventata una parte essenziale dell'infrastruttura di rete. Esistono diversi tipi di ponti per contribuire a rendere tutto ciò possibile.
-## Necessità di ponti {#need-for-bridges}
+## Necessità dei ponti {#need-for-bridges}
-I ponti esistono per connettere diverse reti blockchain. Essi abilitano la connettività ed interoperabilità tra le diverse blockchain.
+I ponti esistono per connettere le reti blockchain. Consentono la connettività e l'interoperabilità tra le blockchain.
-Le blockchain esistono in compartimenti stagni, nel senso che non c'è modo per le blockchain di effettuare scambi e comunicare con altre blockchain in maniera naturale. Di conseguenza, anche se potrebbe esserci un'importante attività e innovazione all'interno di un ecosistema, ciò è limitato dalla mancanza di connettività ed interoperabilità con gli altri ecosistemi.
+Le blockchain esistono in ambienti isolati, il che significa che non c'è modo per le blockchain di scambiare e comunicare con altre blockchain in modo naturale. Di conseguenza, sebbene possa esserci un'attività e un'innovazione significative all'interno di un ecosistema, questo è limitato dalla mancanza di connettività e interoperabilità con altri ecosistemi.
-I ponti offrono una via per connettere tra loro delle blockchain isolate. Stabiliscono un percorso di trasporto tra blockchain dove token, messaggi, dati arbitrari e persino le chiamate a [contratti intelligenti](/developers/docs/smart-contracts/) possono essere trasferite da una catena all'altra.
+I ponti offrono un modo agli ambienti blockchain isolati di connettersi tra loro. Stabiliscono un percorso di trasporto tra le blockchain in cui token, messaggi, dati arbitrari e persino chiamate ai [contratti intelligenti](/developers/docs/smart-contracts/) possono essere trasferiti da una catena all'altra.
-## Benefici dei ponti {#benefits-of-bridges}
+## Vantaggi dei ponti {#benefits-of-bridges}
-In parole povere, i ponti permettono di sbloccare numerosi casi d'uso consentendo alle reti di blockchain di scambiare dati e risorse tra loro.
+In parole povere, i ponti sbloccano numerosi casi d'uso consentendo alle reti blockchain di scambiare dati e spostare asset tra di loro.
-Le blockchain hanno punti forti, punti deboli e approcci unici per costruire applicazioni (velocità, volumi, costi, ecc.). I ponti contribuiscono allo sviluppo generale dell'ecosistema delle criptovalute consentendo alle blockchain di sfruttare le reciproche innovazioni.
+Le blockchain hanno punti di forza, debolezze e approcci unici alla creazione di applicazioni (come velocità, produttività, costi, ecc.). I ponti aiutano lo sviluppo dell'ecosistema cripto complessivo consentendo alle blockchain di sfruttare le reciproche innovazioni.
Per gli sviluppatori, i ponti consentono quanto segue:
-- il trasferimento di qualsiasi dato, informazione e risorsa tra le varie catene.
-- sbloccare nuove funzionalità e casi d'uso per i protocolli, in quando i ponti espandono lo spazio di progettazione per ciò che i protocolli possono offrire. Ad esempio, i protocolli per lo yield farming originariamente lanciati sulla Rete principale di Ethereum possono offrire pool di liquidità in tutte le catene compatibili con EVM.
-- l'opportunità di sfruttare i punti di forza delle differenti blockchain. Per esempio, gli sviluppatori possono beneficiare delle minori commissioni offerte dalle diverse soluzioni di L2 distribuendo le proprie dapp nei diversi rollup, e le sidechain e gli utenti possono collegarli tra loro.
-- collaborazione tra gli sviluppatori provenienti da diversi ecosistemi di blockchain per costruire nuovi prodotti.
-- attrarre utenti e community da vari ecosistemi verso le proprie dapp.
+- il trasferimento di qualsiasi dato, informazione e asset tra le catene.
+- lo sblocco di nuove funzionalità e casi d'uso per i protocolli, poiché i ponti espandono lo spazio di progettazione per ciò che i protocolli possono offrire. Ad esempio, un protocollo per lo yield farming originariamente distribuito sulla [rete principale](/) di Ethereum può offrire pool di liquidità su tutte le catene compatibili con la EVM.
+- l'opportunità di sfruttare i punti di forza di diverse blockchain. Ad esempio, gli sviluppatori possono beneficiare delle commissioni più basse offerte dalle diverse soluzioni L2 distribuendo le loro dApp su rollup e catene laterali, e gli utenti possono usare i ponti per spostarsi tra di esse.
+- la collaborazione tra sviluppatori di vari ecosistemi blockchain per creare nuovi prodotti.
+- l'attrazione di utenti e comunità da vari ecosistemi verso le loro dApp.
## Come funzionano i ponti? {#how-do-bridges-work}
-Sebbene esistano molti [tipi di progetti di ponti](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/), spiccano tre modi per facilitare il trasferimento di risorse tra catene:
+Sebbene esistano molti [tipi di design per i ponti](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/), spiccano tre modi per facilitare il trasferimento cross-chain di asset:
-- **Blocca e conia –** Blocca le risorse sulla catena di origine e conia le risorse nella catena di destinazione.
-- **Brucia e Conia –** Brucia le risorse sulla catena di origine e conia le risorse nella catena di destinazione.
-- **Scambi atomici –** Scambia le risorse sulla catena di origine con risorse sulla catena di destinazione con un'altra parte.
+- **Blocca e conia (Lock and mint) –** Blocca gli asset sulla catena di origine e conia gli asset sulla catena di destinazione.
+- **Brucia e conia (Burn and mint) –** Brucia gli asset sulla catena di origine e conia gli asset sulla catena di destinazione.
+- **Scambi atomici (Atomic swaps) –** Scambia gli asset sulla catena di origine con asset sulla catena di destinazione con un'altra parte.
-## Tipologie di ponte {#bridge-types}
+## Tipi di ponti {#bridge-types}
-I ponti possono essere solitamente classificati in uno dei seguenti:
+I ponti possono solitamente essere classificati in una delle seguenti categorie:
-- **Ponti nativi –** Questi ponti sono in genere costruiti per avviare la liquidità su una particolare blockchain, facilitando agli utenti il trasferimento dei fondi verso l'ecosistema. Ad esempio, il [Arbitrum Bridge](https://bridge.arbitrum.io/) è progettato per rendere comodo per gli utenti il collegamento da Ethereum Mainnet a Arbitrum. Altri ponti di questo tipo includono Polygon PoS Bridge, [Optimism Gateway](https://app.optimism.io/bridge), ecc.
-- **Ponti basati su validatori od oracoli –** Questi ponti si affidano ad un insieme esterno di validatori oppure a degli oracoli per validare trasferimenti tra catene. Esempi: Multichain e Across.
-- ** Ponti generalizzati di passaggio di messaggi –** Questi ponti possono trasferire risorse, insieme a messaggi e dati arbitrari attraverso le catene. Esempi: Axelar, LayerZero e Nomad.
-- **Reti di liquidità –** Questi ponti si concentrano principalmente sul trasferimento di risorse da una catena all'altra tramite scambi atomici. Generalmente non supportano il passaggio di messaggi tra catene. Esempi: Connext e Hop.
+- **Ponti nativi –** Questi ponti sono in genere costruiti per avviare la liquidità su una particolare blockchain, rendendo più facile per gli utenti spostare fondi nell'ecosistema. Ad esempio, l'[Arbitrum Bridge](https://bridge.arbitrum.io/) è costruito per rendere conveniente agli utenti l'uso del ponte dalla rete principale di Ethereum ad Arbitrum. Altri ponti di questo tipo includono Polygon PoS Bridge, [Optimism Gateway](https://app.optimism.io/bridge), ecc.
+- **Ponti basati su validatori o oracoli –** Questi ponti si basano su un set di validatori esterni o oracoli per convalidare i trasferimenti cross-chain. Esempi: Multichain e Across.
+- **Ponti di passaggio di messaggi generalizzati –** Questi ponti possono trasferire asset, insieme a messaggi e dati arbitrari tra le catene. Esempi: Axelar, LayerZero e Nomad.
+- **Reti di liquidità –** Questi ponti si concentrano principalmente sul trasferimento di asset da una catena all'altra tramite scambi atomici. Generalmente, non supportano il passaggio di messaggi cross-chain. Esempi: Connext e Hop.
## Compromessi da considerare {#trade-offs}
-Con i ponti, non esistono soluzioni perfette. Piuttosto, ci sono solo compromessi accettati per realizzare uno scopo. Gli sviluppatori e gli utenti possono valutare i diversi ponti in base ai seguenti fattori:
+Con i ponti, non esistono soluzioni perfette. Piuttosto, ci sono solo compromessi fatti per raggiungere uno scopo. Sviluppatori e utenti possono valutare i ponti in base ai seguenti fattori:
-- **Sicurezza –** Chi verifica il sistema? I ponti messi in sicurezza dai validatori esterni sono tipicamente meno sicuri dei ponti locali o tenuti sicuri in modo nativo dai validatori della blockchain.
-- **Comodità–** Quanto tempo ci vuole per completare una transazione e quante transazioni ha dovuto firmare un utente? Per uno sviluppatore, quanto tempo ci vuole per integrare un ponte, e quanto è complesso questo processo?
-- **Connettività –** Quali sono le diverse catene di destinazione che un ponte può collegare (ossia rollup, sidechain, altre blockchain di livello 1, ecc.), e quanto è difficile integrare una nuova blockchain?
-- **Capacità di passare dati più complessi –** Un ponte può abilitare il trasferimento di messaggi e dati arbitrari più complessi attraverso le catene, o supporta solo i trasferimenti di risorse tra catene?
-- **Rapporto costo-efficacia –** Quanto costa trasferire le risorse tra le catene attraverso un ponte? Tipicamente, i ponti addebitano una commissione fissa o variabile a seconda del costo del carburante e dalla liquidità di specifici percorsi. È inoltre fondamentale valutare il rapporto costi-efficacia di un ponte sulla base del capitale necessario per garantirne la sicurezza.
+- **Sicurezza –** Chi verifica il sistema? I ponti protetti da validatori esterni sono in genere meno sicuri dei ponti protetti localmente o nativamente dai validatori della blockchain.
+- **Convenienza –** Quanto tempo ci vuole per completare una transazione e quante transazioni ha dovuto firmare un utente? Per uno sviluppatore, quanto tempo ci vuole per integrare un ponte e quanto è complesso il processo?
+- **Connettività –** Quali sono le diverse catene di destinazione che un ponte può connettere (ad es. rollup, catene laterali, altre blockchain di livello 1, ecc.) e quanto è difficile integrare una nuova blockchain?
+- **Capacità di passare dati più complessi –** Un ponte può consentire il trasferimento di messaggi e dati arbitrari più complessi tra le catene, o supporta solo trasferimenti di asset cross-chain?
+- **Efficienza dei costi –** Quanto costa trasferire asset tra le catene tramite un ponte? In genere, i ponti addebitano una commissione fissa o variabile a seconda dei costi del gas e della liquidità di percorsi specifici. È anche fondamentale valutare l'efficienza dei costi di un ponte in base al capitale richiesto per garantirne la sicurezza.
-Ad un livello elevato, i ponti possono essere classificati come fidati e senza fiducia.
+Ad alto livello, i ponti possono essere classificati come fidati (trusted) e senza fiducia (trustless).
-- **Fidato –** I ponti fidati sono verificati esternamente. Usano un insieme esterno di verificatori (Federazioni con sistemi di calcolo multifirma, multi-parte, oracolo) per inviare dati attraverso le catene. Di conseguenza, possono offrire una grande connettività e consentire il passaggio di messaggi completamente generalizzati attraverso le catene. Inoltre, tendono a funzionare meglio con la velocità e il rapporto costi-efficacia. Ciò va a scapito della sicurezza, poiché gli utenti devono fare affidamento sulla sicurezza del ponte.
-- **Senza fiducia –** Questi ponti si basano sulle blockchain che stanno connettendo e i loro validatori per trasferire messaggi e token. Sono 'senza fiducia' perché non aggiungono nuove ipotesi di fiducia (oltre alle blockchain). Di conseguenza, i ponti senza fiducia sono considerati più sicuri dei ponti fidati.
+- **Fidati (Trusted) –** I ponti fidati sono verificati esternamente. Utilizzano un set esterno di verificatori (Federazioni con multifirma, sistemi di calcolo multiparte, reti di oracoli) per inviare dati tra le catene. Di conseguenza, possono offrire un'ottima connettività e consentire il passaggio di messaggi completamente generalizzato tra le catene. Tendono anche a funzionare bene in termini di velocità ed efficienza dei costi. Questo va a scapito della sicurezza, poiché gli utenti devono fare affidamento sulla sicurezza del ponte.
+- **Senza fiducia (Trustless) –** Questi ponti si basano sulle blockchain che stanno connettendo e sui loro validatori per trasferire messaggi e token. Sono "senza fiducia" perché non aggiungono nuove ipotesi di fiducia (oltre alle blockchain). Di conseguenza, i ponti senza fiducia sono considerati più sicuri dei ponti fidati.
-Per valutare i ponti senza fiducia sulla base di altri fattori, dobbiamo suddividerli in ponti generalizzati di passaggio di messaggi e reti di liquidità.
+Per valutare i ponti senza fiducia in base ad altri fattori, dobbiamo suddividerli in ponti di passaggio di messaggi generalizzati e reti di liquidità.
-- **Ponti generalizzati di passaggio di messaggio –** Questi ponti eccellono in termini di sicurezza e capacità di trasferire dati più complessi attraverso le catene. In genere, hanno anche buoni rapporti costi-efficacia. Tuttavia, questi punti di forza sono generalmente a scapito della connettività per i ponti client leggeri (es: IBC) e hanno svantaggi di velocità per i ponti ottimistici (es: Nomad) che utilizzano prove di frode.
-- **Reti di liquidità –** Questi ponti utilizzano gli scambi atomici per trasferire le risorse e sono sistemi localmente verificati (ossia, utilizzano i validatori delle blockchain sottostanti per verificare le transazioni). Di conseguenza, eccellono in sicurezza e velocità. Inoltre, sono considerati relativamente convenienti e offrono una buona connettività. Tuttavia, il principale compromesso è la loro incapacità di trasmettere dati più complessi, poiché non supportano il passaggio di messaggi tra catene.
+- **Ponti di passaggio di messaggi generalizzati –** Questi ponti eccellono in sicurezza e nella capacità di trasferire dati più complessi tra le catene. In genere, sono anche buoni in termini di efficienza dei costi. Tuttavia, questi punti di forza vanno generalmente a scapito della connettività per i ponti client leggeri (es: IBC) e degli svantaggi di velocità per i ponti ottimistici (es: Nomad) che utilizzano prove di frode.
+- **Reti di liquidità –** Questi ponti utilizzano scambi atomici per il trasferimento di asset e sono sistemi verificati localmente (ovvero, utilizzano i validatori delle blockchain sottostanti per verificare le transazioni). Di conseguenza, eccellono in sicurezza e velocità. Inoltre, sono considerati comparativamente efficienti in termini di costi e offrono una buona connettività. Tuttavia, il compromesso principale è la loro incapacità di passare dati più complessi, poiché non supportano il passaggio di messaggi cross-chain.
-## Rischi nell'uso dei ponti {#risk-with-bridges}
+## Rischi con i ponti {#risk-with-bridges}
-I ponti rappresentano i primi tre [attacchi principali nella DeFi](https://rekt.news/leaderboard/) e sono ancora nelle prime fasi di sviluppo. L'utilizzo di un ponte comporta i seguenti rischi:
+I ponti sono responsabili dei tre [più grandi hack nella DeFi](https://rekt.news/leaderboard/) e sono ancora nelle prime fasi di sviluppo. L'utilizzo di qualsiasi ponte comporta i seguenti rischi:
-- **Rischio di contratto intelligente –** Mentre molti ponti hanno superato con successo i controlli, basta un difetto in un contratto intelligente affinché le risorse siano esposte agli attacchi (es: [il ponte Wormhole di Solana](https://rekt.news/wormhole-rekt/)).
-- **Rischi finanziari sistemici** – Molti ponti utilizzano risorse impacchettate per coniare le versioni canoniche di risorse originali in una nuova catena. Ciò espone l'ecosistema a un rischio sistemico, poiché abbiamo visto sfruttate le versioni impacchettate dei token.
-- **Rischio di controparte –** Alcuni ponti utilizzano un design fidato che richiede agli utenti di fare affidamento sul presupposto che i validatori non collaboreranno per rubare i fondi degli utenti. La necessità per gli utenti di fidarsi di questi attori di terze parti li espone a rischi come rug pull, censura e altre attività malevole.
-- **Questioni aperte –** Dato che i ponti sono nelle fasi iniziali del loro sviluppo, ci sono molte domande senza risposta relative a come funzioneranno in diverse condizioni di mercato, come in periodi di congestione della rete e durante eventi imprevisti come attacchi a livello di rete o rollback dello stato. Questa incertezza presenta alcuni rischi, il cui grado è ancora sconosciuto.
+- **Rischio dei contratti intelligenti –** Sebbene molti ponti abbiano superato con successo gli audit, basta un solo difetto in un contratto intelligente affinché gli asset siano esposti agli hack (es: [Wormhole Bridge di Solana](https://rekt.news/wormhole-rekt/)).
+- **Rischi finanziari sistemici** – Molti ponti utilizzano asset avvolti per coniare versioni canoniche dell'asset originale su una nuova catena. Ciò espone l'ecosistema a un rischio sistemico, poiché abbiamo visto versioni avvolte di token essere sfruttate.
+- **Rischio di controparte –** Alcuni ponti utilizzano un design fidato che richiede agli utenti di fare affidamento sul presupposto che i validatori non colluderanno per rubare i fondi degli utenti. La necessità per gli utenti di fidarsi di questi attori di terze parti li espone a rischi come rug pull, censura e altre attività dannose.
+- **Problemi aperti –** Dato che i ponti sono nelle fasi nascenti dello sviluppo, ci sono molte domande senza risposta relative a come si comporteranno i ponti in diverse condizioni di mercato, come in tempi di congestione della rete e durante eventi imprevisti come attacchi a livello di rete o rollback dello stato. Questa incertezza pone determinati rischi, il cui grado è ancora sconosciuto.
-## In che modo le dapp possono utilizzare i ponti? {#how-can-dapps-use-bridges}
+## Come possono le dApp utilizzare i ponti? {#how-can-dapps-use-bridges}
-Ecco alcune applicazioni pratiche che gli sviluppatori possono prendere in considerazione sui ponti e sul portare la loro dapp cross-chain:
+Ecco alcune applicazioni pratiche che gli sviluppatori possono considerare riguardo ai ponti e al portare la loro dApp cross-chain:
### Integrare i ponti {#integrating-bridges}
-Per gli sviluppatori, vi sono diversi modi per aggiungere il supporto per i ponti:
+Per gli sviluppatori, ci sono molti modi per aggiungere il supporto per i ponti:
-1. **Costruire il proprio ponte –** Costruire un ponte sicuro e affidabile non è facile, soprattutto se si prende un percorso a fiducia minimizzata. Inoltre, servono anni di esperienza e competenze tecniche in materia di scalabilità e interoperabilità. Inoltre, sarebbe necessario un team sul campo per mantenere un ponte e attirare liquidità sufficiente per renderlo fattibile.
+1. **Costruire il proprio ponte –** Costruire un ponte sicuro e affidabile non è facile, specialmente se si intraprende un percorso con minimizzazione della fiducia. Inoltre, richiede anni di esperienza e competenza tecnica relative agli studi sulla scalabilità e sull'interoperabilità. In aggiunta, richiederebbe un team pratico per mantenere un ponte e attrarre liquidità sufficiente per renderlo fattibile.
-2. **Mostrare agli utenti varie opzioni di ponte –** Molte [dapp](/developers/docs/dapps/) richiedono agli utenti di avere il loro token nativo per interagire con loro. Per consentire agli utenti di accedere ai loro token, offrono diverse opzioni di ponte sul loro sito web. Tuttavia, questo metodo è una soluzione rapida al problema in quanto allontana l'utente dall'interfaccia dapp e richiede comunque che interagisca con altri dapp e ponti. Si tratta di un'esperienza complicata d'ingresso al protocollo, con una maggiore possibilità di commettere errori.
+2. **Mostrare agli utenti più opzioni di ponti –** Molte [dApp](/developers/docs/dapps/) richiedono agli utenti di avere il loro token nativo per interagire con esse. Per consentire agli utenti di accedere ai loro token, offrono diverse opzioni di ponti sul loro sito web. Tuttavia, questo metodo è una soluzione rapida al problema in quanto allontana l'utente dall'interfaccia della dApp e richiede comunque di interagire con altre dApp e ponti. Questa è un'esperienza di onboarding macchinosa con una maggiore possibilità di commettere errori.
-3. **Integrare un ponte –** Questa soluzione non richiede che la dapp invii utenti a interfacce di ponti o DEX esterne. Consente alle dapp di migliorare l'esperienza d'ingresso dell'utente. Tuttavia, questo approccio ha i suoi limiti:
+3. **Integrare un ponte –** Questa soluzione non richiede alla dApp di inviare gli utenti alle interfacce esterne del ponte e del DEX. Consente alle dApp di migliorare l'esperienza di onboarding dell'utente. Tuttavia, questo approccio ha i suoi limiti:
+ - La valutazione e la manutenzione dei ponti sono difficili e dispendiose in termini di tempo.
+ - La selezione di un solo ponte crea un singolo punto di guasto e dipendenza.
+ - La dApp è limitata dalle capacità del ponte.
+ - I ponti da soli potrebbero non essere sufficienti. Le dApp potrebbero aver bisogno di DEX per offrire maggiori funzionalità come gli scambi cross-chain.
- - La valutazione e la manutenzione dei ponti sono difficili e richiedono tempo.
- - Selezionare un solo ponte crea un punto di errore unico e dipendenza.
- - La dapp è limitata dalla capacità del ponte.
- - I ponti da soli potrebbero non bastare. Le dapp potrebbero avere necessità dei DEX per offrire maggiori funzionalità, come gli scambi tra le diverse catene.
+4. **Integrare più ponti –** Questa soluzione risolve molti problemi associati all'integrazione di un singolo ponte. Tuttavia, ha anche dei limiti, poiché l'integrazione di più ponti consuma risorse e crea sovraccarichi tecnici e di comunicazione per gli sviluppatori, la risorsa più scarsa nel settore cripto.
-4. **Integrare più ponti –** Questa soluzione risolve molti problemi associati all'integrazione di un unico ponte. Tuttavia, anche questa ha dei limiti, poiché l'integrazione di più ponti richiede risorse e crea costi tecnici e comunicativi per gli sviluppatori – la risorsa più scarsa nelle criptovalute.
+5. **Integrare un aggregatore di ponti –** Un'altra opzione per le dApp è l'integrazione di una soluzione di aggregazione di ponti che dia loro accesso a più ponti. Gli aggregatori di ponti ereditano i punti di forza di tutti i ponti e quindi non sono limitati dalle capacità di un singolo ponte. In particolare, gli aggregatori di ponti in genere mantengono le integrazioni dei ponti, il che salva la dApp dal fastidio di dover rimanere aggiornata sugli aspetti tecnici e operativi dell'integrazione di un ponte.
-5. **Integrare un aggregatore di ponti –** Un'altra opzione per le dapp è l'integrazione di un aggregatore di ponti che dia loro accesso a più ponti simultaneamente. Gli aggregatori di ponti ereditano i punti di forza di tutti i ponti e quindi non sono limitati dalle capacità di un singolo ponte. In particolare, gli aggregatori di ponti mantengono tipicamente le integrazioni dei ponti, il che evita alla dapp la seccatura di stare dietro agli aspetti tecnici e operativi di un'integrazione di ponte.
+Detto questo, anche gli aggregatori di ponti hanno i loro limiti. Ad esempio, sebbene possano offrire più opzioni di ponti, sul mercato sono in genere disponibili molti più ponti oltre a quelli offerti sulla piattaforma dell'aggregatore. Inoltre, proprio come i ponti, anche gli aggregatori di ponti sono esposti ai rischi dei contratti intelligenti e della tecnologia (più contratti intelligenti = più rischi).
-Detto questo, anche gli aggregatori di ponti hanno i loro limiti. Per esempio, benché possano offrire più opzioni di ponte, molti altri sono tipicamente disponibili sul mercato diversi da quelli offerti dalla piattaforma dell'aggregatore. Inoltre, proprio come i ponti, anche gli aggregatori di ponti sono esposti a rischi di contratti intelligenti e tecnologici (più contratti intelligenti = più rischi).
+Se una dApp intraprende la strada dell'integrazione di un ponte o di un aggregatore, ci sono diverse opzioni in base a quanto profonda debba essere l'integrazione. Ad esempio, se si tratta solo di un'integrazione front-end per migliorare l'esperienza di onboarding dell'utente, una dApp integrerebbe il widget. Tuttavia, se l'integrazione serve a esplorare strategie cross-chain più profonde come lo staking, lo yield farming, ecc., la dApp integra l'SDK o l'API.
-Se una dapp prosegue lungo il percorso di integrazione di un ponte o di un aggregatore, esistono diverse opzioni in base al grado di profondità dell'integrazione stessa. Per esempio, se si tratta solo di un'integrazione front-end per migliorare l'esperienza d'ingresso dell'utente, una dapp integrerebbe il widget. Tuttavia, se l'integrazione è volta a esplorare strategie cross-chain più profonde come staking, yield farming, ecc., la dAapp integra l'SDK o l'API.
+### Distribuire una dApp su più catene {#deploying-a-dapp-on-multiple-chains}
-### Distribuire una dapp su diverse catene {#deploying-a-dapp-on-multiple-chains}
-
-Per distribuire una dApp su più catene, gli sviluppatori possono utilizzare piattaforme di sviluppo come [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/), ecc. In genere, queste piattaforme sono dotate di plugin componibili che possono consentire alle dapp di essere distribuite su diverse catene. Per esempio, gli sviluppatori possono utilizzare un proxy di distribuzione deterministico offerto dal [plugin hardhat-deploy](https://github.com/wighawag/hardhat-deploy).
+Per distribuire una dApp su più catene, gli sviluppatori possono utilizzare piattaforme di sviluppo come [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/), ecc. In genere, queste piattaforme sono dotate di plugin componibili che possono consentire alle dApp di diventare cross-chain. Ad esempio, gli sviluppatori possono utilizzare un proxy di distribuzione deterministico offerto dal [plugin hardhat-deploy](https://github.com/wighawag/hardhat-deploy).
#### Esempi:
-- [Come costruire dapp cross-chain](https://moralis.io/how-to-build-cross-chain-dapps/)
+- [Come costruire dApp cross-chain](https://moralis.io/how-to-build-cross-chain-dapps/)
- [Costruire un marketplace NFT cross-chain](https://youtu.be/WZWCzsB1xUE)
-- [Moralis: costruire una dapp NFT cross-chain](https://www.youtube.com/watch?v=ehv70kE1QYo)
+- [Moralis: Costruire dApp NFT cross-chain](https://www.youtube.com/watch?v=ehv70kE1QYo)
-### Monitoraggio dell'attività del contratto tra le catene {#monitoring-contract-activity-across-chains}
+### Monitorare l'attività dei contratti tra le catene {#monitoring-contract-activity-across-chains}
-Per monitorare l'attività del contratto tra le catene, gli sviluppatori possono utilizzare sotto-grafici e piattaforme di sviluppo come Tenderly per osservare i contratti intelligenti in tempo reale. Tali piattaforme dispongono anche di strumenti che offrono maggiori funzionalità di monitoraggio dei dati per le attività cross-chain, ad esempio il controllo di [eventi emessi dai contratti](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events), ecc.
+Per monitorare l'attività dei contratti tra le catene, gli sviluppatori possono utilizzare sottografi e piattaforme per sviluppatori come Tenderly per osservare i contratti intelligenti in tempo reale. Tali piattaforme dispongono anche di strumenti che offrono maggiori funzionalità di monitoraggio dei dati per le attività cross-chain, come il controllo degli [eventi emessi dai contratti](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events), ecc.
#### Strumenti
- [The Graph](https://thegraph.com/en/)
- [Tenderly](https://tenderly.co/)
-## Ulteriori letture {#further-reading}
+## Letture consigliate {#further-reading}
-- [Ponti della blockchain](/bridges/) – ethereum.org
-- [Ponti della blockchain: creare reti di criptoreti](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 8 Set 2021 - Dmitriy Berenzon
-- [Il trilemma dell'interoperabilità](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 1 Ott 2021 - Arjun Bhuptani
-- [Cluster: come i ponti fidati & a fiducia minimizzata danno forma al paesaggio multi-catena](https://blog.celestia.org/clusters/) 4 Ott 2021 – Mustafa Al-Bassam
-- [LI.FI: con i ponti, la fiducia è uno spettro](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 28 Apr 2022 – Arjun Chand
+- [Ponti blockchain](/bridges/) – ethereum.org
+- [L2Beat Bridge Risk Framework](https://l2beat.com/bridges/summary)
+- [Blockchain Bridges: Building Networks of Cryptonetworks](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) - 8 set 2021 – Dmitriy Berenzon
+- [The Interoperability Trilemma](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) - 1 ott 2021 – Arjun Bhuptani
+- [Clusters: How Trusted & Trust-Minimized Bridges Shape the Multi-Chain Landscape](https://blog.celestia.org/clusters/) - 4 ott 2021 – Mustafa Al-Bassam
+- [LI.FI: With Bridges, Trust is a Spectrum](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) - 28 apr 2022 – Arjun Chand
+- [The State Of Rollup Interoperability Solutions](https://web.archive.org/web/20250428015516/https://research.2077.xyz/the-state-of-rollup-interoperability) - 20 giu 2024 – Alex Hook
+- [Harnessing Shared Security For Secure Cross-Chain Interoperability: Lagrange State Committees And Beyond](https://web.archive.org/web/20250125035123/https://research.2077.xyz/harnessing-shared-security-for-secure-blockchain-interoperability) - 12 giu 2024 – Emmanuel Awosika
-Inoltre, ecco alcune presentazioni intuitive di [James Prestwich](https://twitter.com/_prestwich) che possono contribuire a sviluppare una comprensione più profonda dei ponti:
+Inoltre, ecco alcune presentazioni interessanti di [James Prestwich](https://twitter.com/_prestwich) che possono aiutare a sviluppare una comprensione più profonda dei ponti:
-- [Costruire ponti, giardini non recintati](https://youtu.be/ZQJWMiX4hT0)
-- [Rompere i ponti](https://youtu.be/b0mC-ZqN8Oo)
-- [Perché i ponti sono roventi](https://youtu.be/c7cm2kd20j8)
+- [Building Bridges, Not Walled Gardens](https://youtu.be/ZQJWMiX4hT0)
+- [Breaking Down Bridges](https://youtu.be/b0mC-ZqN8Oo)
+- [Why are the Bridges Burning](https://youtu.be/c7cm2kd20j8)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/index.md
index 386539afe5f..543547f54ed 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/index.md
@@ -1,92 +1,92 @@
---
title: Meccanismi di consenso
-description: Spiegazione dei protocolli di consenso nei sistemi distribuiti e ruolo che svolgono in Ethereum.
+description: Una spiegazione dei protocolli di consenso nei sistemi distribuiti e del ruolo che svolgono in Ethereum.
lang: it
---
-Il termine 'meccanismo di consenso' è usato spesso in modo colloquiale per far riferimento ai protocolli 'Proof of Stake', 'Proof of Work' o 'proof-of-authority'. Tuttavia, questi sono semplicemente dei componenti nel meccanismo di consenso che proteggono dagli [attacchi Sybil](/glossary/#sybil-attack). I meccanismi di consenso sono l'insieme completo di idee, protocolli e incentivi che consentono a una serie distribuita di nodi di acconsentire sullo stato di una blockchain.
+Il termine "meccanismo di consenso" è spesso usato colloquialmente per riferirsi ai protocolli di "prova di stake", "prova di lavoro" o "proof-of-authority". Tuttavia, questi sono solo componenti dei meccanismi di consenso che proteggono dagli [attacchi Sybil](/glossary/#sybil-attack). I meccanismi di consenso sono l'insieme completo di idee, protocolli e incentivi che consentono a un gruppo distribuito di nodi di concordare sullo stato di una blockchain.
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, consigliamo innanzitutto di legere l'[introduzione a Ethereum](/developers/docs/intro-to-ethereum/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima la nostra [introduzione a Ethereum](/developers/docs/intro-to-ethereum/).
-## Che cos'è il consenso? {#what-is-consensus}
+## Cos'è il consenso? {#what-is-consensus}
-Per consenso, intendiamo dire che è stato raggiunto un accordo generale. Consideriamo un gruppo di persone che vanno al cinema. Se non c'è disaccordo sulla proposta del film da scegliere, allora si raggiunge il consenso. Se vi è disaccordo, il gruppo deve avere i mezzi per decidere quale film guardare. Nel caso estremo il gruppo alla fine si dividerà.
+Per consenso, intendiamo che è stato raggiunto un accordo generale. Considera un gruppo di persone che va al cinema. Se non c'è disaccordo sulla scelta del film proposta, allora si raggiunge un consenso. Se c'è disaccordo, il gruppo deve avere i mezzi per decidere quale film vedere. In casi estremi, il gruppo alla fine si dividerà.
-Per quanto riguarda la blockchain di Ethereum, raggiungere un consenso significa che almeno il 66% dei nodi sulla rete è d'accordo sul prossimo stato globale della rete.
+Per quanto riguarda la blockchain di [Ethereum](/), il processo è formalizzato e raggiungere il consenso significa che almeno il 66% dei nodi sulla rete concorda sullo stato globale della rete.
-## Che cos'è un meccanismo di consenso? {#what-is-a-consensus-mechanism}
+## Cos'è un meccanismo di consenso? {#what-is-a-consensus-mechanism}
-Il termine meccanismo di consenso si riferisce all'insieme completo di protocolli, incentivi e idee che consente a una rete di nodi di acconsentire sullo stato di una blockchain.
+Il termine meccanismo di consenso si riferisce all'intero insieme di protocolli, incentivi e idee che consentono a una rete di nodi di concordare sullo stato di una blockchain.
-Ethereum usa un meccanismo di consenso basato sul Proof of Stake che trae la propria sicurezza cripto-economica da una serie di ricompense e sanzioni applicate al capitale bloccato dagli staker. Questa struttura di incentivi incoraggia i singoli staker a gestire validatori onesti, punisce coloro che non lo fanno, e crea un costo estremamente elevato per attaccare la rete.
+Ethereum utilizza un meccanismo di consenso basato sulla prova di stake che deriva la sua sicurezza crittoeconomica da un insieme di ricompense e penalità applicate al capitale bloccato dagli staker. Questa struttura di incentivi incoraggia i singoli staker a operare validatori onesti, punisce coloro che non lo fanno e crea un costo estremamente elevato per attaccare la rete.
-Quindi, esiste un protocollo che governa il modo in cui i validatori onesti sono selezionati per proporre o convalidare i blocchi, elaborare le transazioni e votare per la loro vista della testa della catena. Nelle rare situazioni in cui diversi blocchi sono nella stessa posizione vicino alla testa della catena, esiste un meccanismo di scelta della diramazione che seleziona i blocchi che compongono la catena 'più pesante', misurata dal numero di validatori che hanno votato per i blocchi, ponderato dal loro saldo di ether in staking.
+Inoltre, c'è un protocollo che governa come i validatori onesti vengono selezionati per proporre o convalidare i blocchi, elaborare le transazioni e votare per la loro visione della testa della catena. Nelle rare situazioni in cui più blocchi si trovano nella stessa posizione vicino alla testa della catena, c'è un meccanismo di scelta della biforcazione che seleziona i blocchi che compongono la catena più "pesante", misurata dal numero di validatori che hanno votato per i blocchi ponderato dal loro saldo di ether in stake.
-Alcuni concetti importanti per il consenso non sono definiti esplicitamente nel codice, come la sicurezza aggiuntiva offerta dal potenziale coordinamento sociale fuori banda, come un'ultima linea di difesa contro gli attacchi alla rete.
+Alcuni concetti importanti per il consenso non sono esplicitamente definiti nel codice, come la sicurezza aggiuntiva offerta dal potenziale coordinamento sociale fuori banda come ultima linea di difesa contro gli attacchi alla rete.
-Questi componenti costituiscono nel loro complesso il meccanismo di consenso.
+Questi componenti insieme formano il meccanismo di consenso.
## Tipi di meccanismi di consenso {#types-of-consensus-mechanisms}
-### Basato sul Proof of Work {#proof-of-work}
+### Basato sulla prova di lavoro {#proof-of-work}
-Come Bitcoin, Ethereum in precedenza utilizzava un protocollo di consenso basato sul **Proof of Work (PoW)**.
+Come Bitcoin, Ethereum un tempo utilizzava un protocollo di consenso basato sulla **prova di lavoro (PoW)**.
-#### Creazione di blocchi {#pow-block-creation}
+#### Creazione dei blocchi {#pow-block-creation}
-I miner competono per creare nuovi blocchi, riempiti di transazioni elaborate. Il vincitore condivide il nuovo blocco con il resto della rete e guadagna ETH appena coniati. La gara è vinta dal computer che è capace di risolvere più velocemente un rompicapo matematico. Ciò produce il collegamento crittografico tra il blocco corrente e quello precedente. Risolvere questo rompicapo rappresenta il lavoro da svolgere nel modello "proof-of-work". La catena canonica è quindi determinata da una regola di scelta della biforcazione, che seleziona la serie di blocchi che ha richiesto il maggiore lavoro per essere minata.
+I miner competono per creare nuovi blocchi pieni di transazioni elaborate. Il vincitore condivide il nuovo blocco con il resto della rete e guadagna alcuni ETH appena coniati. La gara viene vinta dal computer che è in grado di risolvere un enigma matematico più velocemente. Questo produce il collegamento crittografico tra il blocco corrente e il blocco precedente. Risolvere questo enigma è il lavoro nella "prova di lavoro". La catena canonica è quindi determinata da una regola di scelta della biforcazione che seleziona l'insieme di blocchi che hanno richiesto il maggior lavoro per essere estratti.
#### Sicurezza {#pow-security}
-La sicurezza della rete è garantita dal fatto che occorrerebbe il 51% della potenza totale di elaborazione della rete per frodare la catena. Ciò richiederebbe investimenti ingenti in attrezzature ed energia; con tutta probabilità spenderesti di più del possibile guadagno.
+La rete è mantenuta sicura dal fatto che avresti bisogno del 51% della potenza di calcolo della rete per frodare la catena. Ciò richiederebbe investimenti così enormi in attrezzature ed energia; è probabile che spenderesti più di quanto guadagneresti.
-Maggiori informazioni sul [Proof of Work](/developers/docs/consensus-mechanisms/pow/)
+Maggiori informazioni sulla [prova di lavoro](/developers/docs/consensus-mechanisms/pow/)
-### Basato sul Proof of Stake {#proof-of-stake}
+### Basato sulla prova di stake {#proof-of-stake}
-Ora Ethereum utilizza un protocollo di consenso basato sul **Proof of Stake (PoS)**.
+Ethereum ora utilizza un protocollo di consenso basato sulla **prova di stake (PoS)**.
-#### Creazione di blocchi {#pos-block-creation}
+#### Creazione dei blocchi {#pos-block-creation}
-I validatori creano i blocchi. Per ogni slot viene selezionato casualmente un validatore che funge da propositore di blocchi. Il client di consenso dei validatori richiede un pacchetto di transazioni come 'payload di esecuzione' dal client di esecuzione associato. Questo viene avvolto in dati di consenso per formare un blocco, che viene inviato ad altri nodi sulla rete Ethereum. La produzione di questo blocco è ricompensata in ETH. Nei rari casi in cui esistono diversi blocchi possibili per un singolo slot, o in cui i nodi vengono a conoscenza dei blocchi in momenti diversi, l'algoritmo di scelta della diramazione seleziona il blocco che forma la catena con il maggiore peso di attestazioni (dove il peso è il numero di validatori che attestano, scalato per il loro saldo di ETH).
+I validatori creano i blocchi. Un validatore viene selezionato casualmente in ogni slot per essere il proponente del blocco. Il loro client di consenso richiede un pacchetto di transazioni come "carico utile di esecuzione" dal loro client di esecuzione associato. Lo avvolgono nei dati di consenso per formare un blocco, che inviano ad altri nodi sulla rete Ethereum. Questa produzione di blocchi è ricompensata in ETH. In rari casi in cui esistono più blocchi possibili per un singolo slot, o i nodi vengono a conoscenza dei blocchi in momenti diversi, l'algoritmo di scelta della biforcazione sceglie il blocco che forma la catena con il maggior peso di attestazioni (dove il peso è il numero di validatori che attestano proporzionato al loro saldo in ETH).
#### Sicurezza {#pos-security}
-Un sistema di Proof of Stake è cripto-economicamente sicuro poiché un utente malevolo che tenta di prendere il controllo della catena deve distruggere un'enorme quantità di ETH. Un sistema di ricompense incentiva i singoli staker a comportarsi onestamente e le sanzioni disincentivano gli staker dall'agire in modo malevolo.
+Un sistema di prova di stake è sicuro dal punto di vista crittoeconomico perché un utente malintenzionato che tenta di prendere il controllo della catena deve distruggere un'enorme quantità di ETH. Un sistema di ricompense incentiva i singoli staker a comportarsi onestamente e le penalità disincentivano gli staker dall'agire in modo dannoso.
-Maggiori informazioni sul [Proof of Stake](/developers/docs/consensus-mechanisms/pos/)
+Maggiori informazioni sulla [prova di stake](/developers/docs/consensus-mechanisms/pos/)
### Una guida visiva {#types-of-consensus-video}
-Scopri altri contenuti sui diversi tipi di meccanismi di consenso usati su Ethereum:
+Guarda di più sui diversi tipi di meccanismi di consenso utilizzati su Ethereum:
- Il Proof of Work è diventato ormai obsoleto. Ethereum non usa più il Proof of Work come parte del suo meccanismo di consenso, e usa invece il Proof of Stake. Leggi di più sul [Proof of Stake](/developers/docs/consensus-mechanisms/pos/) e sullo [staking](/staking/).
+ La prova di lavoro è stata ora deprecata. Ethereum non utilizza più la prova di lavoro come parte del suo meccanismo di consenso. Utilizza invece la prova di stake. Maggiori informazioni sulla [prova di stake](/developers/docs/consensus-mechanisms/pos/) e sullo [staking](/staking/).
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, consigliamo innanzi tutto di leggere il materiale relativo alle [transazioni](/developers/docs/transactions/), [ai blocchi](/developers/docs/blocks/), e [ai meccanismi di consenso](/developers/docs/consensus-mechanisms/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima le [transazioni](/developers/docs/transactions/), i [blocchi](/developers/docs/blocks/) e i [meccanismi di consenso](/developers/docs/consensus-mechanisms/).
-## Cos'è la Proof of Work (PoW)? {#what-is-pow}
+## Cos'è la prova di lavoro (PoW)? {#what-is-pow}
-Il consenso di Nakamoto, che utilizza il proof-of-work, è il meccanismo che un tempo consentiva alla rete decentralizzata di Ethereum di raggiungere il consenso (ossia, l'accordo di tutti i nodi) su aspetti come i saldi dei conti e l'ordine delle transazioni. Questo impediva che gli utenti spendessero due volte le loro monete e assicurava che la catena Ethereum fosse estremamente difficile da attaccare o manipolare. Ora, invece, queste proprietà di sicurezza provengono dal proof-of-stake, usando il meccanismo di consenso noto come [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/).
+Il consenso di Nakamoto, che utilizza la prova di lavoro, è il meccanismo che un tempo consentiva alla rete decentralizzata di Ethereum di raggiungere il consenso (ovvero, tutti i nodi concordano) su cose come i saldi degli account e l'ordine delle transazioni. Questo impediva agli utenti di "spendere due volte" le loro monete e garantiva che la catena di Ethereum fosse tremendamente difficile da attaccare o manipolare. Queste proprietà di sicurezza ora derivano invece dalla prova di stake utilizzando il meccanismo di consenso noto come [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/).
-## Proof of Work e mining {#pow-and-mining}
+## Prova di lavoro e mining {#pow-and-mining}
-Il Proof of Work è l'algoritmo sottostante che imposta la difficoltà e le regole per il lavoro che i miner devono svolgere su blockchain di Proof of Work. Il mining è il "lavoro" da svolgere. Si tratta dell'atto di aggiungere blocchi validi alla catena. Questo è importante perché la lunghezza della catena aiuta le rete a seguire la corretta diramazione della blockchain. Più "lavoro" viene svolto, più è lunga la catena e maggiore è il numero di blocchi, e più la rete può essere certa dello stato attuale delle cose.
+La prova di lavoro è l'algoritmo sottostante che imposta la difficoltà e le regole per il lavoro che i minatori svolgono sulle blockchain basate sulla prova di lavoro. Il mining è il "lavoro" stesso. È l'atto di aggiungere blocchi validi alla catena. Questo è importante perché la lunghezza della catena aiuta la rete a seguire la biforcazione corretta della blockchain. Più "lavoro" viene svolto, più lunga è la catena e maggiore è il numero del blocco, più la rete può essere certa dello stato attuale delle cose.
[Maggiori informazioni sul mining](/developers/docs/consensus-mechanisms/pow/mining/)
-## Come funzionava il Proof of Work di Ethereum? {#how-it-works}
+## Come funzionava la prova di lavoro di Ethereum? {#how-it-works}
-Le transazioni di Ethereum vengono elaborate in blocchi. Nell'Ethereum Proof of Work ora obsoleto, ogni blocco conteneva:
+Le transazioni di Ethereum vengono elaborate in blocchi. Nell'ormai deprecato Ethereum basato sulla prova di lavoro, ogni blocco conteneva:
-- difficoltà del blocco, ad esempio: 3.324.092.183.262.715
-- un mixHash, ad esempio: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
-- nonce, ad esempio: `0xd3ee432b4fb3d26b`
+- difficoltà del blocco – ad esempio: 3,324,092,183,262,715
+- mixHash – ad esempio: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29`
+- nonce – ad esempio: `0xd3ee432b4fb3d26b`
-Questi dati del blocco erano correlati direttamente alla al Proof of Work
+Questi dati del blocco erano direttamente correlati alla prova di lavoro.
-### Il lavoro nel Proof of Work {#the-work}
+### Il lavoro nella prova di lavoro {#the-work}
-Il protocollo di Proof of Work, detto Ethash, richiedeva che i miner competessero tramite processi di tentativo ed errore per trovare il nonce di un blocco. Solo i blocchi con un nonce valido potevano essere aggiunti alla catena.
+Il protocollo di prova di lavoro, Ethash, richiedeva ai minatori di affrontare un'intensa corsa per tentativi ed errori per trovare il nonce per un blocco. Solo i blocchi con un nonce valido potevano essere aggiunti alla catena.
-Quando competeva per creare un blocco, un miner inseriva ripetutamente un set di dati, che si poteva ottenere solo tramite il download e l'esecuzione dell'intera catena (che è quello che fa il miner), attraverso una funzione matematica. Il set di dati veniva utilizzato per generare un mixHash al di sotto di un target dettato dalla difficoltà del blocco. Il miglior modo per farlo era tramite un processo di ripetuti tentativi ed errori.
+Durante la corsa per creare un blocco, un minatore inseriva ripetutamente un set di dati, che poteva essere ottenuto solo scaricando ed eseguendo l'intera catena (come fa un minatore), attraverso una funzione matematica. Il set di dati veniva utilizzato per generare un mixHash al di sotto di un obiettivo dettato dalla difficoltà del blocco. Il modo migliore per farlo è per tentativi ed errori.
-La difficoltà determinava il target per l'hash. Più basso era il target, più piccolo era il set di hash validi. Una volta generato, era incredibilmente facile per gli altri miner e client verificarne la bontà. Anche se una transazione fosse cambiata, l'hash sarebbe stato completamente diverso, segnalando una potenziale frode.
+La difficoltà determinava l'obiettivo per l'hash. Più basso era l'obiettivo, più piccolo era l'insieme di hash validi. Una volta generato, questo era incredibilmente facile da verificare per altri minatori e client. Anche se una sola transazione fosse cambiata, l'hash sarebbe stato completamente diverso, segnalando una frode.
-L'hashing rende le frodi facili da individuare. Ma il processo del Proof of Work era anche un grande deterrente contro gli attacchi alla catena.
+L'hashing rende le frodi facili da individuare. Ma la prova di lavoro come processo era anche un grande deterrente contro gli attacchi alla catena.
-### Proof of Work e sicurezza {#security}
+### Prova di lavoro e sicurezza {#security}
-I miner erano incentivati a fare questo lavoro sulla catena principale di Ethereum. L'incentivo a iniziare una catena propria era molto ridotto per i miner, perché avrebbe compromesso il sistema. Le blockchain fanno affidamento sul fatto di avere un solo stato di riferimento, che è considerato l'unica fonte di verità.
+I minatori erano incentivati a svolgere questo lavoro sulla catena principale di Ethereum. C'era poco incentivo per un sottoinsieme di minatori a iniziare la propria catena: mina il sistema. Le blockchain si basano sull'avere un singolo stato come fonte di verità.
-L'obiettivo del Proof of Work era di estendere la catena. La catena più lunga era quella più credibile in termini di validità, perché era quella che racchiudeva in sé la maggior parte del lavoro computazionale eseguito. Nel sistema PoW di Ethereum era praticamente impossibile creare nuovi blocchi che cancellassero transazioni o che ne creassero di false, o mantenere una seconda catena. Questo perché un miner malevolo avrebbe dovuto sempre risolvere il nonce del blocco più velocemente di chiunque altro.
+L'obiettivo della prova di lavoro era estendere la catena. La catena più lunga era la più credibile come quella valida perché aveva la maggior quantità di lavoro computazionale svolto per generarla. All'interno del sistema PoW di Ethereum, era quasi impossibile creare nuovi blocchi che cancellassero transazioni, ne creassero di false o mantenessero una seconda catena. Questo perché un minatore malintenzionato avrebbe dovuto risolvere sempre il nonce del blocco più velocemente di tutti gli altri.
-Per creare costantemente blocchi malevoli ma validi, un miner malevolo avrebbe dovuto avere più del 51% della potenza di mining della rete, per poter battere tutti gli altri. Tale quantità di "lavoro" richiede un grande quantità di costosa potenza di calcolo e l'energia consumata avrebbe potuto persino superare i guadagni derivanti dall'attacco.
+Per creare costantemente blocchi malintenzionati ma validi, un minatore malintenzionato avrebbe avuto bisogno di oltre il 51% della potenza di mining della rete per battere tutti gli altri. Quella quantità di "lavoro" richiede molta potenza di calcolo costosa e l'energia spesa avrebbe potuto persino superare i guadagni ottenuti in un attacco.
-### L'economia della Proof of Work {#economics}
+### Economia della prova di lavoro {#economics}
-Il Proof of Work era anche responsabile del rilascio di nuova valuta nel sistema e dell'incentivazione dei miner a fare il proprio lavoro.
+La prova di lavoro era anche responsabile dell'emissione di nuova valuta nel sistema e dell'incentivazione dei minatori a svolgere il lavoro.
-Dall'[aggiornamento di Costantinopoli](/ethereum-forks/#constantinople), i miner che creavano correttamente un blocco erano ricompensati con due ETH appena coniati e parte delle commissioni di transazione. Anche i blocchi ommer erano ricompensati con 1,75 ETH. I blocchi ommer erano blocchi validi, creati da un miner praticamente contestualmente alla creazione del blocco canonico da parte di un altro miner, determinati in ultima analisi dalla catena su cui la creazione era avvenuta prima. I blocchi ommer si verificavano in genere a causa della latenza della rete.
+A partire dall'aggiornamento [Constantinople](/ethereum-forks/#constantinople), i minatori che creavano con successo un blocco venivano ricompensati con due ETH appena coniati e parte delle commissioni della transazione. I blocchi ommer compensavano anche 1,75 ETH. I blocchi ommer erano blocchi validi creati da un minatore praticamente nello stesso momento in cui un altro minatore creava il blocco canonico, che alla fine veniva determinato da quale catena veniva costruita per prima. I blocchi ommer di solito si verificavano a causa della latenza della rete.
## Finalità {#finality}
-Una transazione ha una "finalità" su Ethereum quando fa parte di un blocco che non può cambiare.
+Una transazione ha "finalità" su Ethereum quando fa parte di un blocco che non può cambiare.
-Dato che i miner lavoravano in modo decentralizzato, era possibile che avvenisse il mining di due blocchi validi nello stesso momento. In questo caso, si crea una diramazione temporanea. Alla fine veniva accettata una sola catena (quella più lunga), creata quando venivano eseguiti il mining e l'aggiunta di blocchi successivi.
+Poiché i minatori lavoravano in modo decentralizzato, due blocchi validi potevano essere minati contemporaneamente. Questo crea una biforcazione temporanea. Alla fine, una di queste catene diventava la catena accettata dopo che i blocchi successivi venivano minati e aggiunti ad essa, rendendola più lunga.
-Per complicare ulteriormente le cose, le transazioni che erano state rifiutate sulla diramazione temporanea potevano non essere state aggiunte alla catena accettata. Questo significa che la catena poteva essere annullata. Quindi la finalità si riferisce al tempo per cui era necessario attendere prima di considerare una transazione irreversibile. Con il precedente Ethereum di Proof of Work, più blocchi erano minati su uno specifico blocco `N`, maggiore sarebbe stata la certezza che le transazioni in `N` riuscissero e non fossero annullate. Ora, con il Proof of Stake, la finalizzazione è una proprietà esplicita, piuttosto che probabilistica, di un blocco.
+A complicare ulteriormente le cose, le transazioni rifiutate sulla biforcazione temporanea potrebbero non essere state incluse nella catena accettata. Ciò significa che potrebbero essere annullate. Quindi la finalità si riferisce al tempo che dovresti aspettare prima di considerare una transazione irreversibile. Nel precedente Ethereum basato sulla prova di lavoro, più blocchi venivano minati sopra un blocco specifico `N`, maggiore era la sicurezza che le transazioni in `N` avessero avuto successo e non sarebbero state annullate. Ora, con la prova di stake, la finalizzazione è una proprietà esplicita, piuttosto che probabilistica, di un blocco.
-## Consumo energetico del Proof of Work {#energy}
+## Consumo energetico della prova di lavoro {#energy}
-Una delle principali critiche mosse al Proof of Work riguarda la quantità di energia necessaria per mantenere la rete sicura. Per mantenere la sicurezza e la decentralizzazione, Ethereum sul Proof of Work consumava elevate quantità di energia. Poco prima di passare al Proof of Stake, i miner di Ethereum consumavano collettivamente circa 70 TWh/anno (quasi quanto la Repubblica ceca, secondo [digiconomist](https://digiconomist.net/), il 18 luglio 2022).
+Una delle principali critiche alla prova di lavoro è la quantità di energia richiesta per mantenere la rete sicura. Per mantenere la sicurezza e la decentralizzazione, Ethereum basato sulla prova di lavoro consumava grandi quantità di energia. Poco prima di passare alla prova di stake, i minatori di Ethereum consumavano collettivamente circa 70 TWh/anno (più o meno come la Repubblica Ceca - secondo [digiconomist](https://digiconomist.net/) il 18 luglio 2022).
## Pro e contro {#pros-and-cons}
-| Pro | Contro |
-| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Il Proof of Work è neutrale. Non servono ETH per iniziare e le ricompense per i blocchi consentono di passare da 0 ETH a un saldo positivo. Con il [ Proof of Stake](/developers/docs/consensus-mechanisms/pos/) occorrono ETH per iniziare. | Il Proof of Work utilizza così tanta energia da risultare dannoso per l'ambiente. |
-| Il PoW è un meccanismo di consenso testato e ben collaudato che mantiene Bitcoin ed Ethereum sicure e decentralizzate da molti anni. | Chi desidera occuparsi di mining deve avere apparecchiature specializzate, con un conseguente notevole investimento iniziale. |
-| Rispetto alla Proof of Stake è relativamente facile da implementare. | A causa della crescente richiesta di potenza di calcolo, alcuni i gruppi di mining potrebbero potenzialmente dominare l'attività di mining, portando così alla centralizzazione e a rischi di sicurezza. |
+| Pro | Contro |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| La prova di lavoro è neutrale. Non hai bisogno di ETH per iniziare e le ricompense del blocco ti consentono di passare da 0 ETH a un saldo positivo. Con la [prova di stake](/developers/docs/consensus-mechanisms/pos/) hai bisogno di ETH per iniziare. | La prova di lavoro consuma così tanta energia da essere dannosa per l'ambiente. |
+| La prova di lavoro è un meccanismo di consenso collaudato che ha mantenuto Bitcoin ed Ethereum sicuri e decentralizzati per molti anni. | Se vuoi minare, hai bisogno di attrezzature così specializzate che rappresenta un grande investimento per iniziare. |
+| Rispetto alla prova di stake è relativamente facile da implementare. | A causa del crescente calcolo necessario, le pool di mining potrebbero potenzialmente dominare il gioco del mining, portando a centralizzazione e rischi per la sicurezza. |
-## Confronto con il Proof of Stake {#compared-to-pos}
+## Confronto con la prova di stake {#compared-to-pos}
-Ad alto livello, il Proof of Stake ha lo stesso obiettivo del Proof of Work: permettere a una rete decentralizzata di raggiungere il consenso in totale sicurezza. Ma ci sono alcune differenze nei processi e nel personale:
+Ad alto livello, la prova di stake ha lo stesso obiettivo finale della prova di lavoro: aiutare la rete decentralizzata a raggiungere il consenso in modo sicuro. Ma presenta alcune differenze nel processo e nel personale:
-- Il PoS scambia l'importanza della potenza di calcolo con gli ETH in staking.
-- Il PoS sostituisce i miner con i validatori. I validatori fanno staking con i loro ETH per avere la possibilità di creare nuovi blocchi.
-- I validatori non competono per creare blocchi, sono invece scelti casualmente da un algoritmo.
-- La finalità è più chiara: in alcuni checkpoint, se i 2/3 dei validatori concordano sullo stato del blocco, questo è considerato definitivo. I validatori devono scommettere il loro intero stake su questo, per cui se dovessero provare a cospirare in seguito, perderebbero il loro intero stake.
+- La prova di stake sostituisce l'importanza della potenza di calcolo con gli ETH in staking.
+- La prova di stake sostituisce i minatori con i validatori. I validatori mettono in staking i loro ETH per attivare la capacità di creare nuovi blocchi.
+- I validatori non competono per creare blocchi, ma vengono scelti casualmente da un algoritmo.
+- La finalità è più chiara: a determinati checkpoint, se 2/3 dei validatori concordano sullo stato del blocco, questo è considerato finale. I validatori devono scommettere il loro intero stake su questo, quindi se cercano di colludere in seguito, perderanno il loro intero stake.
-[Maggiori informazioni sul Proof of Stake](/developers/docs/consensus-mechanisms/pos/)
+[Maggiori informazioni sulla prova di stake](/developers/docs/consensus-mechanisms/pos/)
-## Preferisci un approccio visivo all'apprendimento? {#visual-learner}
+## Impari meglio visivamente? {#visual-learner}
-Il Proof of Work non è più il meccanismo di consenso alla base di Ethereum, il che significa che il mining è stato disattivato. Invece, Ethereum è protetto dai validatori che mettono ETH in staking. Puoi iniziare fin da subito a mettere in staking i tuoi ETH. Leggi di più su La Fusione, il proof-of-stake e lo staking. Questa pagina è solo per interesse storico.
+La prova di lavoro non è più alla base del meccanismo di consenso di Ethereum, il che significa che il mining è stato disattivato. Invece, [Ethereum](/) è protetto da validatori che mettono in stake ETH. Puoi iniziare a fare staking dei tuoi ETH oggi stesso. Maggiori informazioni su La Fusione (The Merge), prova di stake e staking. Questa pagina è solo di interesse storico.
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, consigliamo innanzi tutto di leggere [transazioni](/developers/docs/transactions/), [blocchi](/developers/docs/blocks/) e [Proof of Work](/developers/docs/consensus-mechanisms/pow/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima le [transazioni](/developers/docs/transactions/), i [blocchi](/developers/docs/blocks/) e la [prova di lavoro](/developers/docs/consensus-mechanisms/pow/).
-## Cos'è il mining in Ethereum? {#what-is-ethereum-mining}
+## Cos'è il mining di Ethereum? {#what-is-ethereum-mining}
-Il mining è il processo di creazione di un blocco di transazioni, da aggiungere alla blockchain Ethereum nell'architettura ormai obsoleta di Proof of Work.
+Il mining è il processo di creazione di un blocco di transazioni da aggiungere alla blockchain di Ethereum nell'architettura di prova di lavoro di Ethereum, ora deprecata.
-La parola mining origina nel contesto dell'analogia dell'oro per le criptovalute. L'oro e i metalli preziosi sono scarsi, così come i token digitali, e l'unico modo per aumentarne il volume totale in un sistema di Proof of Work attraverso il mining. Nell'Ethereum Proof of Work, l'unico metodo di emissione era tramite il mining. A differenza dell'oro e dei metalli preziosi, però, il mining di Ethereum era anche il metodo per proteggere la rete, creando, verificando, pubblicando e propagando i blocchi nella blockchain.
+La parola mining ha origine nel contesto dell'analogia dell'oro per le criptovalute. L'oro o i metalli preziosi sono scarsi, così come i token digitali, e l'unico modo per aumentare il volume totale in un sistema di prova di lavoro è attraverso il mining. In Ethereum basato sulla prova di lavoro, l'unica modalità di emissione era tramite il mining. A differenza dell'oro o dei metalli preziosi, tuttavia, il mining di Ethereum era anche il modo per proteggere la rete creando, verificando, pubblicando e propagando blocchi nella blockchain.
Minare ether = Proteggere la Rete
-Il mining è la linfa vitale di qualsiasi blockchain basata sul Proof of Work. Prima della transizione al Proof of Stake, i miner di Ethereum (computer che eseguono software) usavano il loro tempo e la loro capacità di calcolo per elaborare transazioni e produrre blocchi.
+Il mining è la linfa vitale di qualsiasi blockchain basata sulla prova di lavoro. I minatori di Ethereum - computer che eseguono software - usavano il loro tempo e la loro potenza di calcolo per elaborare transazioni e produrre blocchi prima della transizione alla prova di stake.
-## Perché esistono i miner? {#why-do-miners-exist}
+## Perché esistono i minatori? {#why-do-miners-exist}
-Nei sistemi decentralizzati come Ethereum, dobbiamo assicurarci che tutti concordino sull'ordine delle transazioni. In questo i miner aiutavano risolvendo complessi enigmi di calcolo con lo scopo di produrre blocchi, tenendo la rete al sicuro dagli attacchi.
+Nei sistemi decentralizzati come Ethereum, dobbiamo assicurarci che tutti siano d'accordo sull'ordine delle transazioni. I minatori aiutavano a far sì che ciò accadesse risolvendo enigmi computazionalmente difficili per produrre blocchi, proteggendo la rete dagli attacchi.
-[Maggiori informazioni sul Proof of Work](/developers/docs/consensus-mechanisms/pow/)
+[Maggiori informazioni sulla prova di lavoro](/developers/docs/consensus-mechanisms/pow/)
-In precedenza, chiunque poteva minare sulla rete Ethereum usando il proprio computer. Tuttavia, non tutti potevano estrarre ether (ETH) in modo redditizio. In gran parte dei casi, i miner dovevano acquistare hardware dedicato e avere accesso a fonti energetiche convenienti. Per il computer medio, era improbabile guadagnare abbastanza ricompense dei blocchi da coprire i costi associati al mining.
+In precedenza, chiunque era in grado di minare sulla rete di Ethereum usando il proprio computer. Tuttavia, non tutti potevano minare ether (ETH) in modo redditizio. Nella maggior parte dei casi, i minatori dovevano acquistare hardware informatico dedicato e avere accesso a fonti di energia economiche. Era improbabile che il computer medio guadagnasse abbastanza ricompense del blocco per coprire i costi associati al mining.
-### Costi del mining {#cost-of-mining}
+### Costo del mining {#cost-of-mining}
-- I costi potenziali dell'hardware necessario per costruire e mantenere una piattaforma di mining
-- I costi elettrici per alimentarla
-- Se si effettuava il mining all'interno di un gruppo, questi gruppi di mining addebitavano generalmente una commissione forfettaria percentuale su ciascun blocco generato dal gruppo
-- I costi potenziali delle attrezzature per supportare la piattaforma di mining (ventilazione, monitoraggio energetico, cablaggio, etc.)
+- Costi potenziali dell'hardware necessario per costruire e mantenere un impianto di mining (mining rig)
+- Costo elettrico per alimentare l'impianto di mining
+- Se stavi minando in una pool, queste pool in genere addebitavano una commissione percentuale fissa su ogni blocco generato dalla pool
+- Costo potenziale delle attrezzature per supportare l'impianto di mining (ventilazione, monitoraggio dell'energia, cablaggio elettrico, ecc.)
-Per approfondire ulteriormente la redditività del mining, usa un apposito calcolatore, come quello messo a disposizione da [Etherscan](https://etherscan.io/ether-mining-calculator).
+Per esplorare ulteriormente la redditività del mining, usa un calcolatore di mining, come quello fornito da [Etherscan](https://etherscan.io/ether-mining-calculator).
-## Come avveniva il mining delle transazioni Ethereum {#how-ethereum-transactions-were-mined}
+## Come venivano minate le transazioni di Ethereum {#how-ethereum-transactions-were-mined}
-Quanto segue fornisce una panoramica di come erano minate le transazioni, nel proof-of-work di Ethereum. Una descrizione analoga di questo processo per il proof-of-stake di Ethereum, si può trovare [qui](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos).
+Di seguito viene fornita una panoramica di come le transazioni venivano minate nella prova di lavoro di Ethereum. Una descrizione analoga di questo processo per la prova di stake di Ethereum può essere trovata [qui](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos).
-1. Un utente scrive e firma una richiesta di [transazione](/developers/docs/transactions/) con la chiave privata di un [conto](/developers/docs/accounts/).
-2. L'utente trasmette la richiesta di transazione all'intera rete Ethereum attraverso un [nodo](/developers/docs/nodes-and-clients/).
-3. Dopo aver recepito la richiesta della nuova transazione, ogni nodo nella rete Ethereum aggiunge la richiesta alla propria mempool locale, un elenco di tutte le richieste di transazioni delle quali è venuto a conoscenza e che non sono ancora state inviate alla blockchain in un blocco.
-4. A un certo punto, un nodo di mining aggrega diverse dozzine o centinaia di richieste di transazione in un [blocco](/developers/docs/blocks/) potenziale, così da massimizzare le [commissioni di transazione](/developers/docs/gas/) che saranno guadagnate, entro il limite di gas del blocco. A questo punto, il nodo di mining:
- 1. Verifica la validità di ogni richiesta di transazione (cioè, che nessuno stia provando a trasferire ether da un conto per cui non ha prodotto una firma, la richiesta non è malformata, etc.) e, poi, esegue il codice della richiesta, alterando lo stato della loro copia locale dell'EVM. Il miner assegna la commissione sulla transazione per ogni simile richiesta di transazione, al proprio conto.
- 2. Inizia il processo di produzione del "certificato di legittimità" Proof of Work per il blocco potenziale, una volta che tutte le richieste di transazione nel blocco sono state verificate ed eseguite nella copia dell'EVM locale.
-5. Infine un miner concluderà la produzione di un certificato per un blocco che include la nostra richiesta di transazione specifica. Il miner trasmetterà quindi il blocco completato, che include il certificato e una checksum del nuovo stato dell'EVM dichiarato.
-6. Gli altri nodi vengono a conoscenza del nuovo blocco. Verificano il certificato, eseguono tutte le transazioni sul blocco (includendo la transazione originalmente inviata dal nostro utente) e verificano che la checksum del nuovo stato dell'EVM dopo l'esecuzione di tutte le transazioni combaci quella dello stato dichiarato dal blocco del miner. Solo a questo punto allora questi nodi aggiungeranno il blocco alla coda della blockchain e accetteranno il nuovo stato dell'EVM come canonico.
-7. Ogni nodo rimuove tutte le transazioni nel nuovo blocco dalla propria mempool locale di richieste di transazioni non eseguite.
-8. I nuovi nodi che si aggiungono alla rete scaricano tutti i blocchi in sequenza, incluso il blocco che contiene la transazione della quale stiamo parlando. Inizializzano la propria copia locale dell'EVM (che partirà come EVM con stato vuoto) e si avvieranno al processo di esecuzione di ogni transazione contenuta in ogni blocco aggiungendola alla propria copia dell'EVM locale e verificando le checksum dello stato ad ogni blocco che esamineranno.
+1. Un utente scrive e firma una richiesta di [transazione](/developers/docs/transactions/) con la chiave privata di un [account](/developers/docs/accounts/).
+2. L'utente trasmette la richiesta di transazione all'intera rete di Ethereum da un [nodo](/developers/docs/nodes-and-clients/).
+3. Dopo aver appreso della nuova richiesta di transazione, ogni nodo nella rete di Ethereum aggiunge la richiesta alla propria mempool locale, un elenco di tutte le richieste di transazione di cui sono venuti a conoscenza e che non sono ancora state confermate nella blockchain in un blocco.
+4. A un certo punto, un nodo di mining aggrega diverse dozzine o centinaia di richieste di transazione in un potenziale [blocco](/developers/docs/blocks/), in un modo che massimizza le [commissioni della transazione](/developers/docs/gas/) che guadagnano pur rimanendo al di sotto del limite del gas del blocco. Il nodo di mining quindi:
+ 1. Verifica la validità di ogni richiesta di transazione (ad es., nessuno sta cercando di trasferire ether da un account per cui non ha prodotto una firma, la richiesta non è malformata, ecc.), e poi esegue il codice della richiesta, alterando lo stato della propria copia locale della EVM. Il minatore assegna la commissione della transazione per ciascuna di queste richieste di transazione al proprio account.
+ 2. Inizia il processo di produzione del "certificato di legittimità" della prova di lavoro per il potenziale blocco, una volta che tutte le richieste di transazione nel blocco sono state verificate ed eseguite sulla copia locale della EVM.
+5. Alla fine, un minatore finirà di produrre un certificato per un blocco che include la nostra specifica richiesta di transazione. Il minatore trasmette quindi il blocco completato, che include il certificato e un checksum del nuovo stato della EVM dichiarato.
+6. Altri nodi vengono a conoscenza del nuovo blocco. Verificano il certificato, eseguono loro stessi tutte le transazioni sul blocco (inclusa la transazione originariamente trasmessa dal nostro utente) e verificano che il checksum del loro nuovo stato della EVM dopo l'esecuzione di tutte le transazioni corrisponda al checksum dello stato dichiarato dal blocco del minatore. Solo allora questi nodi aggiungono questo blocco alla fine della loro blockchain e accettano il nuovo stato della EVM come stato canonico.
+7. Ogni nodo rimuove tutte le transazioni nel nuovo blocco dalla propria mempool locale di richieste di transazione non soddisfatte.
+8. I nuovi nodi che si uniscono alla rete scaricano tutti i blocchi in sequenza, incluso il blocco contenente la nostra transazione di interesse. Inizializzano una copia locale della EVM (che inizia come una EVM a stato vuoto), e poi passano attraverso il processo di esecuzione di ogni transazione in ogni blocco sopra la loro copia locale della EVM, verificando i checksum dello stato ad ogni blocco lungo il percorso.
-Il mining di ogni transazione (cioè l'inclusione in un nuovo blocco e la prima propagazione) avviene una volta sola, ma la transazione viene eseguita e verificata da ogni partecipante nel processo di avanzamento dello stato canonico dell'EVM. Questa è una delle regole fondamentali della blockchain: **non ti fidare, verifica**.
+Ogni transazione viene minata (inclusa in un nuovo blocco e propagata per la prima volta) una volta, ma eseguita e verificata da ogni partecipante nel processo di avanzamento dello stato canonico della EVM. Questo evidenzia uno dei mantra centrali della blockchain: **Non fidarti, verifica**.
-## Blocchi ommer (zio) {#ommer-blocks}
+## Blocchi ommer (uncle) {#ommer-blocks}
-L'estrazione di blocchi basata sul proof-of-work era solo probabilistica, il che significa che a volte due blocchi validi venivano pubblicati simultaneamente a causa della latenza della rete. In questo caso, il protocollo doveva determinare la catena più lunga (e quindi più "valida") garantendo al tempo stesso un trattamento equo dei miner, ricompensando parzialmente il blocco valido proposto non incluso. Ciò incoraggiava l'ulteriore decentralizzazione della rete in quanto i piccoli miner, che potevano trovarsi ad affrontare una latenza più elevata, potevano comunque generare rendimenti tramite ricompense per blocchi [ommer](/glossary/#ommer).
+Il mining dei blocchi sulla prova di lavoro era probabilistico, il che significa che a volte due blocchi validi venivano pubblicati contemporaneamente a causa della latenza della rete. In questo caso, il protocollo doveva determinare la catena più lunga (e quindi più "valida") garantendo al contempo equità verso i minatori ricompensando parzialmente il blocco valido proposto non incluso. Questo incoraggiava un'ulteriore decentralizzazione della rete poiché i minatori più piccoli, che potevano affrontare una maggiore latenza, potevano comunque generare rendimenti tramite le ricompense del blocco [ommer](/glossary/#ommer).
-"Ommer" è il termine preferito, neutro dal punto di vista del genere, per lo stesso livello di un blocco genitore, ma a volte viene anche indicato come "zio". **Da quando Ethereum è passato alla proof-of-stake, i blocchi ommer non vengono più estratti** poiché in ogni slot viene eletto solo un proponente. Questo cambiamento può essere osservato nel [grafico storico](https://ycharts.com/indicators/ethereum_uncle_rate) dei blocchi ommer estratti.
+Il termine "ommer" è il termine neutro preferito per il fratello di un blocco genitore, ma a volte viene anche chiamato "uncle" (zio). **Dal passaggio di Ethereum alla prova di stake, i blocchi ommer non vengono più minati** poiché viene eletto un solo proponente in ogni slot. Puoi vedere questo cambiamento visualizzando il [grafico storico](https://ycharts.com/indicators/ethereum_uncle_rate) dei blocchi ommer minati.
-## Demo visiva {#a-visual-demo}
+## Una demo visiva {#a-visual-demo}
-Austin ti guiderà attraverso il mining e la blockchain basata sul proof-of-work.
+Guarda Austin guidarti attraverso il mining e la blockchain basata sulla prova di lavoro.
xᵐ mod P ≡ 1
+Per evitare ciò, si fa appello a un risultato della teoria dei numeri. Un [_Numero primo sicuro_](https://en.wikipedia.org/wiki/Safe_prime) è definito come un numero primo `P` tale che anche `(P-1)/2` sia primo. L'_ordine_ di un membro `x` del [gruppo moltiplicativo](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` è definito come il minimo `m` tale che xᵐ mod P ≡ 1
Date queste definizioni, abbiamo:
-> Osservazione 1. Ipotizziamo che `x` sia un membro del gruppo moltiplicativo `ℤ/Pℤ` per un numero primo sicuro `P`. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, allora l'ordine di `x` è `P-1` o `(P-1)/2`.
+> Osservazione 1. Sia `x` un membro del gruppo moltiplicativo `ℤ/Pℤ` per un numero primo sicuro `P`. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, allora l'ordine di `x` è `P-1` o `(P-1)/2`.
-_Dimostrazione_. Poiché `P` è un numero primo sicuro, allora per il \[Teorema di Lagrange\]\[lagrange\], l'ordine di `x` è `1`, `2`, `(P-1)/2` o `P-1`.
+_Dimostrazione_. Poiché `P` è un numero primo sicuro, allora per il [Teorema di Lagrange][lagrange] abbiamo che l'ordine di `x` è `1`, `2`, `(P-1)/2` o `P-1`.
-L'ordine di `x` non può essere `1`, poiché secondo il Piccolo teorema di Fermat:
+L'ordine di `x` non può essere `1`, poiché per il Piccolo Teorema di Fermat abbiamo:
xP-1 mod P ≡ 1
-Quindi, `x`, deve essere un'identità moltiplicativa di `ℤ/nℤ`, che è univoca. Poiché abbiamo presupposto che `x ≠ 1`, ciò è impossibile.
+Quindi `x` deve essere un'identità moltiplicativa di `ℤ/nℤ`, che è unica. Poiché abbiamo supposto che `x ≠ 1` per ipotesi, questo non è possibile.
-L'ordine di `x` non può essere `2` a meno che `x = P-1`, poiché ciò violerebbe il fatto che `P` sia un numero primo.
+L'ordine di `x` non può essere `2` a meno che `x = P-1`, poiché ciò violerebbe il fatto che `P` sia primo.
-Dalla suddetta proposizione possiamo capire che iterando `(picker * init) % P`, avrà una lunghezza del ciclo di almeno `(P-1)/2`. Questo perché abbiamo selezionato `P` come un numero primo sicuro, approssimativamente pari a una potenza superiore di due e che `init` è nell'intervallo `[2,2**256+1]`. Data la portata di `P`, non dovremmo mai aspettarci un ciclo dall'elevamento a potenza modulare.
+Dalla proposizione precedente, possiamo riconoscere che l'iterazione di `(picker * init) % P` avrà una lunghezza del ciclo di almeno `(P-1)/2`. Questo perché abbiamo selezionato `P` in modo che sia un numero primo sicuro approssimativamente uguale a una potenza superiore di due, e `init` è nell'intervallo `[2,2**256+1]`. Data la grandezza di `P`, non dovremmo mai aspettarci un ciclo dall'esponenziazione modulare.
-Quando assegniamo la prima cella nel DAG (la variabile etichettata come `init`), calcoliamo `pow(sha3(seed) + 2, 3, P)`. A prima vista, questo non garantisce che il risultato sia `1` né `P-1`. Tuttavia, poiché `P-1` è un numero primo sicuro, abbiamo la seguente garanzia aggiuntiva, che è un corollario dell'Osservazione 1:
+Quando assegniamo la prima cella nel DAG (la variabile etichettata `init`), calcoliamo `pow(sha3(seed) + 2, 3, P)`. A prima vista, questo non garantisce che il risultato non sia né `1` né `P-1`. Tuttavia, poiché `P-1` è un numero primo sicuro, abbiamo la seguente garanzia aggiuntiva, che è un corollario dell'Osservazione 1:
-> Osservazione 2. Ipotizziamo che `x` sia un membro del gruppo moltiplicativo `ℤ/Pℤ` per un numero primo sicuro `P`, e prendiamo `w` come numero naturale. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, nonché `w mod P ≠ P-1 mod P` e `w mod P ≠ 0 mod P`, allora `xʷ mod P ≠ 1 mod P` e `xʷ mod P ≠ P-1 mod P`
+> Osservazione 2. Sia `x` un membro del gruppo moltiplicativo `ℤ/Pℤ` per un numero primo sicuro `P`, e sia `w` un numero naturale. Se `x mod P ≠ 1 mod P` e `x mod P ≠ P-1 mod P`, così come `w mod P ≠ P-1 mod P` e `w mod P ≠ 0 mod P`, allora `xʷ mod P ≠ 1 mod P` e `xʷ mod P ≠ P-1 mod P`
### Esponenziazione modulare come funzione di hash {#modular-exponentiation}
-Per certi valori di `P` e `w`, la funzione `pow(x, w, P)` potrebbe avere molte collisioni. Ad esempio, `pow(x,9,19)` prende solo i valori `{1,18}`.
+Per determinati valori di `P` e `w`, la funzione `pow(x, w, P)` potrebbe avere molte collisioni. Ad esempio, `pow(x,9,19)` assume solo i valori `{1,18}`.
-Dato che `P` è primo, allora è possibile scegliere un'appropriata `w` per una funzione di hashing di esponenziazione modulare usando il seguente risultato:
+Dato che `P` è primo, allora un `w` appropriato per una funzione di hashing di esponenziazione modulare può essere scelto utilizzando il seguente risultato:
-> Osservazione 3. Prendiamo `P` come numero primo; `w` e `P-1` sono coprimi se e solo se per ogni `a` e `b` in `ℤ/Pℤ`:
->
->
-> `aʷ mod P ≡ bʷ mod P` se e solo se `a mod P ≡ b mod P`
->
+> Osservazione 3. Sia `P` un numero primo; `w` e `P-1` sono coprimi se e solo se per tutti gli `a` e `b` in `ℤ/Pℤ`:`aʷ mod P ≡ bʷ mod P` se e solo se `a mod P ≡ b mod P`
-Dunque, dato che `P` è primo e `w` è coprimo rispetto a `P-1`, abbiamo che `|{pow(x, w, P) : x ∈ ℤ}| = P`, e questo implica che la funzione di hashing ha la frequenza di collisione minima possibile.
+Pertanto, dato che `P` è primo e `w` è coprimo rispetto a `P-1`, abbiamo che `|{pow(x, w, P) : x ∈ ℤ}| = P`, il che implica che la funzione di hashing ha il tasso di collisione minimo possibile.
-Nel caso speciale in cui `P` sia un numero primo sicuro, come da noi selezionato, allora `P-1` ha solo i fattori 1, 2, `(P-1)/2` e `P-1`. Poiché `P` > 7, sappiamo che 3 è primo rispetto a `P-1`, quindi `w=3` soddisfa la proposizione precedente.
+Nel caso speciale in cui `P` sia un numero primo sicuro come abbiamo selezionato, allora `P-1` ha solo i fattori 1, 2, `(P-1)/2` e `P-1`. Poiché `P` > 7, sappiamo che 3 è coprimo rispetto a `P-1`, quindi `w=3` soddisfa la proposizione precedente.
-## Algoritmo di valutazione più efficiente basato sulla cache {#cache-based-evaluation}
+## Algoritmo di valutazione basato su cache più efficiente {#cache-based-evaluation}
```python
def quick_calc(params, seed, p):
@@ -331,4 +327,4 @@ def quick_hashimoto_cached(cache, dagsize, params, header, nonce):
for _ in range(params["accesses"]):
mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m)
return dbl_sha3(mix)
-```
+```
\ No newline at end of file
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..0277d91f341 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
@@ -1,6 +1,6 @@
---
title: Ethash
-description: Uno sguardo dettagliato all'algoritmo Ethash.
+description: Un'occhiata dettagliata all'algoritmo Ethash.
lang: it
---
@@ -8,29 +8,29 @@ 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 prova di lavoro di Ethereum. La prova di lavoro è stata ora **completamente disattivata** ed Ethereum è ora protetto utilizzando invece la [prova di stake](/developers/docs/consensus-mechanisms/pos/). Scopri di più su [The Merge](/roadmap/merge/), la [prova di stake](/developers/docs/consensus-mechanisms/pos/) e lo [staking](/staking/). Questa pagina è di interesse storico!
-Ethash è una versione modificata dell'algoritmo di [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). Il proof-of-work di Ethash è [a elevato consumo di memoria](https://wikipedia.org/wiki/Memory-hard_function), cosa pensata per rendere l'algoritmo resistente agli ASIC. Gli ASIC di Ethash sono infine stati sviluppati, ma il mining della GPU è stata un'opzione ancora valida fino alla disattivazione del proof-of-work. Ethash è ancora usato per minare altre valute su altre reti di proof-of-work non di Ethereum.
+Ethash è una versione modificata dell'algoritmo [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). La prova di lavoro di Ethash è [memory hard](https://wikipedia.org/wiki/Memory-hard_function) (difficile per la memoria), il che si pensava rendesse l'algoritmo resistente agli ASIC. Alla fine sono stati sviluppati ASIC per Ethash, ma il mining con GPU è rimasto un'opzione praticabile fino a quando la prova di lavoro non è stata disattivata. Ethash è ancora utilizzato per minare altre monete su altre reti di prova di lavoro non di Ethereum.
## Come funziona Ethash? {#how-does-ethash-work}
-La gravosità sulla memoria è ottenuta con un algoritmo di proof-of-work che richiede la scelta di sotto-serie di una risorsa fissa, dipendente dal nonce e dall'intestazione del blocco. Questa risorsa (di pochi gigabyte di dimensioni) è detta DAG. Il DAG è modificato ogni 30.000 blocchi, una finestra di circa 125 ore detta un'epoca (circa 5,2 giorni) e richiede un po' di tempo per generarsi. Poiché il DAG dipende solo dall'altezza del blocco, può esser pre-generato, ma se non è il client, deve attendere fino alla fine di questo processo per produrre un blocco. Se i client non si pre-generano e salvano anticipatamente nella cache i DAG, la rete potrebbe subire un enorme ritardo dei blocchi a ogni transizione d'epoca. Il DAG non deve necessariamente essere generato per verificare il proof-of-work, perché è essenzialmente possibile eseguire la verifica con poca CPU e poca memoria.
+La difficoltà per la memoria è ottenuta con un algoritmo di prova di lavoro che richiede la scelta di sottoinsiemi di una risorsa fissa dipendente dal nonce e dall'intestazione del blocco. Questa risorsa (della dimensione di alcuni gigabyte) è chiamata DAG. Il DAG viene modificato ogni 30000 blocchi, una finestra di circa 125 ore chiamata epoca (circa 5,2 giorni) e richiede un po' di tempo per essere generato. Poiché il DAG dipende solo dall'altezza del blocco, può essere pre-generato, ma se non lo è, il client deve attendere la fine di questo processo per produrre un blocco. Se i client non pre-generano e memorizzano nella cache i DAG in anticipo, la rete potrebbe subire un massiccio ritardo dei blocchi a ogni transizione di epoca. Si noti che il DAG non deve essere generato per verificare la prova di lavoro, consentendo essenzialmente la verifica con CPU e memoria ridotte.
-Il percorso generale intrapreso dall'algoritmo è il seguente:
+Il percorso generale seguito dall'algoritmo è il seguente:
-1. Esiste un **seed**, calcolabile per ogni blocco scansionando fino a quel punto le intestazioni dei blocchi.
-2. Dal seed, si può calcolare una **cache pseudo-casuale di 16 MB**. I client leggeri memorizzano la cache.
-3. Dalla cache, possiamo generare un **dataset di 1 GB**, caratterizzato dal fatto che ogni elemento nel dataset dipende solo da una piccola quantità di elementi dalla cache. I client completi e i miner memorizzano il dataset. Il dataset cresce linearmente col tempo.
-4. Durante il mining vengono prese delle fette (slice) casuali del dataset, eseguendone l'hashing. La verifica può essere effettuata con poca memoria usando la cache per rigenerare le parti specifiche del dataset necessarie, così da dover solo memorizzare la cache.
+1. Esiste un **seme** (seed) che può essere calcolato per ogni blocco scansionando le intestazioni dei blocchi fino a quel punto.
+2. Dal seme, si può calcolare una **cache pseudocasuale di 16 MB**. I client leggeri memorizzano la cache.
+3. Dalla cache, possiamo generare un **set di dati di 1 GB**, con la proprietà che ogni elemento nel set di dati dipende solo da un piccolo numero di elementi della cache. I client completi e i minatori memorizzano il set di dati. Il set di dati cresce linearmente nel tempo.
+4. Il mining comporta il prelievo di porzioni casuali del set di dati e il loro hashing insieme. La verifica può essere eseguita con poca memoria utilizzando la cache per rigenerare i pezzi specifici del set di dati di cui si ha bisogno, quindi è necessario memorizzare solo la cache.
-Il grande dataset è aggiornato una volta ogni 30.000 blocchi, in questo modo l'impegno di un miner sarà per lo più quello di leggere il dataset, non effettuare modifiche a esso.
+Il grande set di dati viene aggiornato una volta ogni 30000 blocchi, quindi la stragrande maggioranza dello sforzo di un minatore consisterà nel leggere il set di dati, non nell'apportarvi modifiche.
## Definizioni {#definitions}
-Adottiamo le seguenti definizioni:
+Impieghiamo le seguenti definizioni:
```
WORD_BYTES = 4 # bytes in word
@@ -47,15 +47,15 @@ CACHE_ROUNDS = 3 # number of rounds in cache production
ACCESSES = 64 # number of accesses in hashimoto loop
```
-### L'uso di "SHA3" {#sha3}
+### L'uso di 'SHA3' {#sha3}
-Lo sviluppo di Ethereum è coinciso con lo sviluppo dello standard SHA3 e il processo standard ha effettuato una modifica tardiva al padding dell'algoritmo di hash finalizzato, quindi, gli hash "sha3_256" e "sha3_512" di Ethereum non sono hash dello standard sha3, ma una variante, spesso definita "Keccak-256" e "Keccak-512" in altri contesti. Vedi la discussione, ad esempio [qui](https://eips.ethereum.org/EIPS/eip-1803), [qui](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use) o [qui](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057).
+Lo sviluppo di Ethereum ha coinciso con lo sviluppo dello standard SHA3 e il processo di standardizzazione ha apportato una modifica tardiva al riempimento (padding) dell'algoritmo di hash finalizzato, in modo che gli hash "sha3_256" e "sha3_512" di Ethereum non siano hash sha3 standard, ma una variante spesso indicata come "Keccak-256" e "Keccak-512" in altri contesti. Vedi la discussione, ad es., [qui](https://eips.ethereum.org/EIPS/eip-1803), [qui](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use) o [qui](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057).
-Si ricorda che gli hash "sha3" siano presentati nella descrizione dell'algoritmo più avanti.
+Tienilo a mente poiché gli hash "sha3" sono menzionati nella descrizione dell'algoritmo di seguito.
## Parametri {#parameters}
-I parametri della cache e del dataset di Ethash dipendono dal numero del blocco. Le dimensioni della cache e del dataset crescono entrambe linearmente; tuttavia, prendiamo sempre il numero primo maggiore successivo alla soglia di crescita lineare, per ridurre il rischio di regolarità accidentali che determinano un comportamento ciclico.
+I parametri per la cache e il set di dati di Ethash dipendono dal numero del blocco. La dimensione della cache e la dimensione del set di dati crescono entrambe linearmente; tuttavia, prendiamo sempre il numero primo più alto al di sotto della soglia di crescita lineare per ridurre il rischio di regolarità accidentali che portano a comportamenti ciclici.
```python
def get_cache_size(block_number):
@@ -73,22 +73,22 @@ def get_full_size(block_number):
return sz
```
-Nell'appendice sono presentate tabelle delle dimensioni del dataset e della cache.
+Le tabelle dei valori delle dimensioni del set di dati e della cache sono fornite nell'appendice.
## Generazione della cache {#cache-generation}
-Specifichiamo ora la funzione per produrre una cache:
+Ora, specifichiamo la funzione per produrre una cache:
```python
def mkcache(cache_size, seed):
n = cache_size // HASH_BYTES
- # Sequentially produce the initial dataset
+ # Produci sequenzialmente il dataset iniziale
o = [sha3_512(seed)]
for i in range(1, n):
o.append(sha3_512(o[-1]))
- # Use a low-round version of randmemohash
+ # Usa una versione con pochi round di randmemohash
for _ in range(CACHE_ROUNDS):
for i in range(n):
v = o[i][0] % n
@@ -97,11 +97,11 @@ def mkcache(cache_size, seed):
return o
```
-Il processo di produzione della cache richiede dapprima il riempimento sequenziale di 32 MB di memoria, poi l'esecuzione di due passaggi dell'algoritmo _RandMemoHash_ di Sergio Demian Lerner da [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). L'output è una serie di valori a 64 byte 524288.
+Il processo di produzione della cache prevede prima il riempimento sequenziale di 32 MB di memoria, quindi l'esecuzione di due passaggi dell'algoritmo _RandMemoHash_ di Sergio Demian Lerner da [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). L'output è un insieme di 524288 valori da 64 byte.
## Funzione di aggregazione dei dati {#date-aggregation-function}
-Usiamo un algoritmo ispirato dall'[hash FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) in alcuni casi come un sostituto non associativo per XOR. Nota che moltiplichiamo il numero primo con l'intero input a 32 bit, a differenza della specifica FNV-1, che moltiplica invece il numero primo con un byte (ottetto).
+Utilizziamo un algoritmo ispirato all'hash [FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) in alcuni casi come sostituto non associativo per lo XOR. Si noti che moltiplichiamo il numero primo con l'intero input a 32 bit, in contrasto con le specifiche FNV-1 che moltiplicano il numero primo con un byte (ottetto) alla volta.
```python
FNV_PRIME = 0x01000193
@@ -110,28 +110,28 @@ def fnv(v1, v2):
return ((v1 * FNV_PRIME) ^ v2) % 2**32
```
-Anche lo yellow paper specifica fnv come v1\*(FNV_PRIME ^ v2), tutte le implementazioni correnti usano attualmente la suddetta definizione.
+Si prega di notare che, sebbene lo yellow paper specifichi fnv come v1\*(FNV_PRIME ^ v2), tutte le implementazioni attuali utilizzano coerentemente la definizione di cui sopra.
-## Calcolo dell'intero dataset {#full-dataset-calculation}
+## Calcolo del set di dati completo {#full-dataset-calculation}
-Ogni elemento da 64 byte nell'intero dataset da 1 GB è calcolato come segue:
+Ogni elemento da 64 byte nel set di dati completo da 1 GB viene calcolato come segue:
```python
def calc_dataset_item(cache, i):
n = len(cache)
r = HASH_BYTES // WORD_BYTES
- # initialize the mix
+ # inizializza il mix
mix = copy.copy(cache[i % n])
mix[0] ^= i
mix = sha3_512(mix)
- # fnv it with a lot of random cache nodes based on i
+ # applica fnv con molti nodi di cache casuali basati su i
for j in range(DATASET_PARENTS):
cache_index = fnv(i ^ j, mix[j % r])
mix = map(fnv, mix, cache[cache_index % n])
return sha3_512(mix)
```
-Essenzialmente, combiniamo i dati da 256 nodi della cache selezionati pseudo-casualmente e ne eseguiamo l'hash per calcolare il nodo del dataset. L'intero dataset è quindi generato da:
+Essenzialmente, combiniamo i dati da 256 nodi della cache selezionati in modo pseudocasuale e ne facciamo l'hash per calcolare il nodo del set di dati. L'intero set di dati viene quindi generato da:
```python
def calc_dataset(full_size, cache):
@@ -140,27 +140,27 @@ def calc_dataset(full_size, cache):
## Ciclo principale {#main-loop}
-Ora, specifichiamo il ciclo principale in stile "hashimoto", dove aggreghiamo i dati dal dataset completo per poter produrre il valore finale per un'intestazione e nonce in particolare. Nel codice seguente, `header` rappresenta l'_hash_ SHA3-256 della rappresentazione RLP di un'intestazione del blocco _troncata_, ovvero, di un'intestazione che esclude i campi **mixHash** e **nonce**. Un `nonce` si compone degli otto byte di un intero non firmato da 64 bit, con ordinamento big-endian. Quindi `nonce[::-1]` è la rappresentazione little-endian di otto byte di quel valore:
+Ora, specifichiamo il ciclo principale in stile "hashimoto", in cui aggreghiamo i dati dal set di dati completo per produrre il nostro valore finale per una particolare intestazione e nonce. Nel codice sottostante, `header` rappresenta l'_hash_ SHA3-256 della rappresentazione RLP di un'intestazione di blocco _troncata_, ovvero di un'intestazione che esclude i campi **mixHash** e **nonce**. `nonce` sono gli otto byte di un intero senza segno a 64 bit in ordine big-endian. Quindi `nonce[::-1]` è la rappresentazione little-endian a otto byte di quel valore:
```python
def hashimoto(header, nonce, full_size, dataset_lookup):
n = full_size / HASH_BYTES
w = MIX_BYTES // WORD_BYTES
mixhashes = MIX_BYTES / HASH_BYTES
- # combine header+nonce into a 64 byte seed
+ # combina header+nonce in un seed da 64 byte
s = sha3_512(header + nonce[::-1])
- # start the mix with replicated s
+ # inizia il mix con s replicato
mix = []
for _ in range(MIX_BYTES / HASH_BYTES):
mix.extend(s)
- # mix in random dataset nodes
+ # mescola nodi casuali del dataset
for i in range(ACCESSES):
p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes
newdata = []
for j in range(MIX_BYTES / HASH_BYTES):
newdata.extend(dataset_lookup(p + j))
mix = map(fnv, mix, newdata)
- # compress mix
+ # comprimi il mix
cmix = []
for i in range(0, len(mix), 4):
cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3]))
@@ -176,9 +176,9 @@ def hashimoto_full(full_size, dataset, header, nonce):
return hashimoto(header, nonce, full_size, lambda x: dataset[x])
```
-Essenzialmente, manteniamo un mix di 128 byte e recuperiamo sequenzialmente e ripetutamente 128 byte dal dataset completo e usiamo la funzione `fnv` per combinarli col mix. Vengono usati 128 byte di accesso sequenziale così che ogni ciclo dell'algoritmo recuperi sempre una pagina intera dalla RAM, minimizzando le ricerche a vuoto nel lookaside buffer che gli ASIC dovrebbero teoricamente poter evitare.
+Essenzialmente, manteniamo un "mix" largo 128 byte e recuperiamo ripetutamente in modo sequenziale 128 byte dal set di dati completo e utilizziamo la funzione `fnv` per combinarlo con il mix. Vengono utilizzati 128 byte di accesso sequenziale in modo che ogni round dell'algoritmo recuperi sempre un'intera pagina dalla RAM, riducendo al minimo i mancati riscontri nel translation lookaside buffer (TLB) che gli ASIC sarebbero teoricamente in grado di evitare.
-Se l'output di questo algoritmo è inferiore all'obiettivo desiderato, allora il nonce è valido. Nota che l'applicazione aggiuntiva di `sha3_256` alla fine assicura che esista un nonce intermedio, che può essere fornito per provare che almeno una piccola quantità di lavoro è stata eseguita; questa rapida verifica di PoW esterna è utilizzabile per scopi anti-DDoS. Serve anche a fornire la garanzia statistica che il risultato sia un numero a 256 bit imparziale.
+Se l'output di questo algoritmo è inferiore all'obiettivo desiderato, allora il nonce è valido. Si noti che l'applicazione aggiuntiva di `sha3_256` alla fine garantisce l'esistenza di un nonce intermedio che può essere fornito per dimostrare che è stata eseguita almeno una piccola quantità di lavoro; questa rapida verifica esterna della prova di lavoro (PoW) può essere utilizzata per scopi anti-DDoS. Serve anche a fornire la garanzia statistica che il risultato sia un numero a 256 bit non distorto.
## Mining {#mining}
@@ -186,7 +186,7 @@ L'algoritmo di mining è definito come segue:
```python
def mine(full_size, dataset, header, difficulty):
- # zero-pad target to compare with hash on the same digit
+ # riempi di zeri il target per confrontarlo con l'hash sulla stessa cifra
target = zpad(encode_int(2**256 // difficulty), 64)[::-1]
from random import randint
nonce = randint(0, 2**64)
@@ -195,9 +195,9 @@ def mine(full_size, dataset, header, difficulty):
return nonce
```
-## Definire l'hash del seed {#seed-hash}
+## Definizione dell'hash del seme {#seed-hash}
-Per poter calcolare l'hash del seed da usare per fare mining su un dato blocco, usiamo il seguente algoritmo:
+Per calcolare l'hash del seme che verrebbe utilizzato per minare sopra un dato blocco, utilizziamo il seguente algoritmo:
```python
def get_seedhash(block):
@@ -207,7 +207,7 @@ Per poter calcolare l'hash del seed da usare per fare mining su un dato blocco,
return s
```
-Nota che per la fluidità delle attività di mining e verifica, consigliamo di pre-calcolare gli hash dei seed futuri e i dataset in un thread separato.
+Si noti che per un mining e una verifica fluidi, si consiglia di pre-calcolare i futuri hash dei semi e i set di dati in un thread separato.
## Letture consigliate {#further-reading}
@@ -215,12 +215,12 @@ _Conosci una risorsa della community che ti è stata utile? Modifica questa pagi
## Appendice {#appendix}
-Il seguente codice dovrebbe essere anteposto se sei interessato all'esecuzione della suddetta specifica di Python come codice.
+Il seguente codice dovrebbe essere anteposto se sei interessato a eseguire le specifiche python di cui sopra come codice.
```python
import sha3, copy
-# Assumes little endian bit ordering (same as Intel architectures)
+# Presume un ordinamento dei bit little endian (lo stesso delle architetture Intel)
def decode_int(s):
return int(s[::-1].encode('hex'), 16) if s else 0
@@ -248,7 +248,7 @@ def serialize_cache(ds):
serialize_dataset = serialize_cache
-# sha3 hash function, outputs 64 bytes
+# funzione di hash sha3, restituisce 64 byte
def sha3_512(x):
return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x)
@@ -267,7 +267,7 @@ def isprime(x):
### Dimensioni dei dati {#data-sizes}
-Le seguenti tabelle di ricerca forniscono approssimativamente 2048 epoche tabulate di dimensioni dei dati e della cache.
+Le seguenti tabelle di ricerca forniscono circa 2048 epoche tabulate di dimensioni dei dati e dimensioni della cache.
```python
def get_datasize(block_number):
@@ -1016,4 +1016,4 @@ cache_sizes = [
283377344, 283508416, 283639744, 283770304, 283901504, 284032576,
284163136, 284294848, 284426176, 284556992, 284687296, 284819264,
284950208, 285081536]
-```
+```
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
index 374f5830ef7..2a0bd5d0e31 100644
--- a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
+++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md
@@ -1,6 +1,6 @@
---
title: Algoritmi di mining
-description: Uno sguardo dettagliato agli algoritmi usati per il mining di Ethereum.
+description: Uno sguardo dettagliato agli algoritmi utilizzati per il mining di Ethereum.
lang: it
---
@@ -8,35 +8,35 @@ lang: it
-Il proof-of-work non è più alla base del meccanismo di consenso di Ethereum, a significare che il mining è stato disattivato. Invece, Ethereum, è protetto dai validatori che mettono ETH in staking. Puoi iniziare oggi a mettere i tuoi ETH in staking. Leggi di più su La Fusione, il proof-of-stake e lo staking. Questa pagina è per solo interesse storico.
+La prova di lavoro non è più alla base del meccanismo di consenso di Ethereum, il che significa che il mining è stato disattivato. Invece, Ethereum è protetto dai validatori che mettono in stake i propri ETH. Puoi iniziare a fare staking dei tuoi ETH oggi stesso. Scopri di più su The Merge, sulla prova di stake e sullo staking. Questa pagina è solo di interesse storico.
-Il mining di Ethereum usava un algoritmo noto come Ethash. L'idea fondamentale dell'algoritmo è che un miner prova a trovare l'input di un nonce usando il calcolo di forza bruta, così che l'hash risultante sia inferiore a una soglia determinata dalla difficoltà calcolata. Questo livello di difficoltà può esser regolato dinamicamente, consentendo alla produzione dei blocchi di verificarsi a un intervallo regolare.
+Il mining di Ethereum utilizzava un algoritmo noto come Ethash. L'idea fondamentale dell'algoritmo è che un minatore cerca di trovare un input nonce utilizzando il calcolo a forza bruta in modo che l'hash risultante sia inferiore a una soglia determinata dalla difficoltà calcolata. Questo livello di difficoltà può essere regolato dinamicamente, consentendo alla produzione del blocco di avvenire a intervalli regolari.
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, ti consigliamo prima di leggere sul [consenso proof-of-work](/developers/docs/consensus-mechanisms/pow) e sul [mining](/developers/docs/consensus-mechanisms/pow/mining).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima il [consenso basato sulla prova di lavoro](/developers/docs/consensus-mechanisms/pow) e il [mining](/developers/docs/consensus-mechanisms/pow/mining).
## Dagger Hashimoto {#dagger-hashimoto}
-Dagger Hashimoto era un algoritmo di ricerca precursore del mining di Ethereum, sostituito da Ethash. Era un amalgama di due algoritmi differenti: Dagger e Hashimoto. È sempre e solo stato un'implementazione di ricerca e fu superato da Ethash prima del lancio della Rete Principale di Ethereum.
+Dagger Hashimoto era un algoritmo di ricerca precursore per il mining di Ethereum che è stato sostituito da Ethash. Era una fusione di due diversi algoritmi: Dagger e Hashimoto. È stato solo un'implementazione di ricerca ed è stato sostituito da Ethash al momento del lancio della rete principale di Ethereum.
-[Dagger](http://www.hashcash.org/papers/dagger.html) prevede la generazione di un [Grafico Aciclico Diretto](https://en.wikipedia.org/wiki/Directed_acyclic_graph), porzioni casuali del quale ricevono un hashing insieme. Il principio fondamentale è che ogni nonce richiede solo una piccola porzione di un grande albero di dati totali. Ricalcolare l'albero secondario per ogni nonce è proibitivo per il mining, da cui l'esigenza di memorizzare l'albero, invece, va bene per verificare un singolo nonce. Dagger è stato progettato per essere un'alternativa agli algoritmi esistenti come Scrypt, che sono gravosi per la memoria (memory-hard) ma difficili da verificare all'aumentare dell'uso della memoria verso livelli veramente sicuri. Dagger era però vulnerabile all'accelerazione dell'hardware con memoria condiviso ed è stato abbandonato a favore di altre vie di ricerca.
+[Dagger](http://www.hashcash.org/papers/dagger.html) prevede la generazione di un [Grafo Aciclico Diretto (DAG)](https://en.wikipedia.org/wiki/Directed_acyclic_graph), le cui porzioni casuali vengono sottoposte ad hash insieme. Il principio fondamentale è che ogni nonce richiede solo una piccola porzione di un grande albero di dati totale. Ricalcolare il sottoalbero per ogni nonce è proibitivo per il mining - da qui la necessità di memorizzare l'albero - ma va bene per la verifica del valore di un singolo nonce. Dagger è stato progettato per essere un'alternativa agli algoritmi esistenti come Scrypt, che sono intensivi in termini di memoria (memory-hard) ma difficili da verificare quando la loro intensità di memoria aumenta a livelli genuinamente sicuri. Tuttavia, Dagger era vulnerabile all'accelerazione hardware della memoria condivisa ed è stato abbandonato a favore di altre vie di ricerca.
-[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) è un algoritmo che aggiunge resistenza ASIC, essendo vincolato da aspetti I/O (cioè le letture di memoria rappresentano il fattore limitante nel processo di mining). La teoria è che vi sia più disponibilità di RAM che di calcolo: sono già stati usati miliardi di dollari in ricerca per l'ottimizzazione della RAM per diversi scenari d'uso, che spesso coinvolgono schemi d'accesso semi-casuale (da cui "memoria d'accesso casuale", Random Access Memory). Di conseguenza, è probabile che la RAM esistente sia abbastanza vicina all'ottimale per valutare l'algoritmo. Hashimoto usa la blockchain come una fonte di dati, perché soddisfa simultaneamente i punti (1) e (3) di cui sopra.
+[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) è un algoritmo che aggiunge resistenza agli ASIC essendo limitato dall'I/O (cioè, le letture della memoria sono il fattore limitante nel processo di mining). La teoria è che la RAM sia più disponibile del calcolo; miliardi di dollari di ricerca hanno già studiato l'ottimizzazione della RAM per diversi casi d'uso, che spesso comportano modelli di accesso quasi casuali (da cui "memoria ad accesso casuale"). Di conseguenza, è probabile che la RAM esistente sia moderatamente vicina all'ottimale per la valutazione dell'algoritmo. Hashimoto utilizza la blockchain come fonte di dati, soddisfacendo contemporaneamente i punti (1) e (3) di cui sopra.
-Dagger-Hashimoto usava delle versioni modificate degli algoritmi di Dagger e Hashimoto. La differenza tra Dagger Hashimoto e Hashimoto è che, anziché usare la blockchain come una fonte di dati, Dagger Hashimoto usa una serie di dati generata e personalizzata, che si aggiorna a seconda dei dati del blocco ogni N blocchi. La serie di dati è generata usando l'algoritmo di Dagger, che consente di calcolare efficientemente una sotto-serie specifica a ogni nonce per l'algoritmo di verifica del client leggero. La differenza tra Dagger Hashimoto e Dagger è che, a differenza del Dagger originale, il dataset usato per interrogare il blocco è semi-permanente, in quanto viene aggiornato solo occasionalmente (es. una volta a settimana). Questo significa che la porzione dello sforzo per generare il dataset è prossima allo zero, e diventano quindi trascurabili gli argomenti di Sergio Lerner riguardanti le velocizzazioni della memoria condivisa.
+Dagger-Hashimoto utilizzava versioni modificate degli algoritmi Dagger e Hashimoto. La differenza tra Dagger Hashimoto e Hashimoto è che, invece di utilizzare la blockchain come fonte di dati, Dagger Hashimoto utilizza un set di dati generato su misura, che si aggiorna in base ai dati del blocco ogni N blocchi. Il set di dati viene generato utilizzando l'algoritmo Dagger, consentendo di calcolare in modo efficiente un sottoinsieme specifico per ogni nonce per l'algoritmo di verifica del client leggero. La differenza tra Dagger Hashimoto e Dagger è che, a differenza del Dagger originale, il set di dati utilizzato per interrogare il blocco è semi-permanente, venendo aggiornato solo a intervalli occasionali (ad es., una volta alla settimana). Ciò significa che la porzione di sforzo per generare il set di dati è vicina allo zero, quindi le argomentazioni di Sergio Lerner riguardo ai miglioramenti di velocità della memoria condivisa diventano trascurabili.
Maggiori informazioni su [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto).
## Ethash {#ethash}
-Ethash era l'algoritmo di mining che era effettiamente usato sulla vera Rete Principale di Ethereum sotto l'ora deprecata architettura del proof-of-work. Ethash in realtà è un nuovo nome assegnato a una versione specifica di Dagger-Hashimoto dopo un aggiornamento significativo dell'algoritmo, che comunque eredita i principi fondamentali del suo predecessore. La Rete Principale di Ethereum ha sempre e solo usato Ethash; Dagger Hashimoto era una versione R&D dell'algoritmo di mining che fu superata prima che il mining fosse avviato sulla Rete Principale di Ethereum.
+Ethash era l'algoritmo di mining effettivamente utilizzato sulla vera rete principale di Ethereum sotto l'architettura basata sulla prova di lavoro, ora deprecata. Ethash era di fatto un nuovo nome dato a una versione specifica di Dagger-Hashimoto dopo che l'algoritmo è stato significativamente aggiornato, pur ereditando i principi fondamentali del suo predecessore. La rete principale di Ethereum ha utilizzato solo Ethash: Dagger Hashimoto era una versione di ricerca e sviluppo dell'algoritmo di mining che è stata sostituita prima dell'inizio del mining sulla rete principale di Ethereum.
-[Di più su Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
+[Maggiori informazioni su Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash).
## Letture consigliate {#further-reading}
-_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/dapps/index.md b/public/content/translations/it/developers/docs/dapps/index.md
index f53b9af7416..9f13daaab93 100644
--- a/public/content/translations/it/developers/docs/dapps/index.md
+++ b/public/content/translations/it/developers/docs/dapps/index.md
@@ -1,96 +1,104 @@
---
-title: Introduzione alle dapp
+title: Introduzione tecnica alle dApp
description:
lang: it
---
-Un'applicazione decentralizzata (dapp) è un'applicazione costruita su una rete decentralizzata che combina un [contratto intelligente](/developers/docs/smart-contracts/) e l'interfaccia utente di un frontend. Su Ethereum, i contratti intelligenti sono accessibili e trasparenti (come le API aperte), quindi la tua dapp può persino includere un contratto intelligente, già scritto da qualcun altro.
+Un'applicazione decentralizzata (dApp) è un'applicazione creata su una rete decentralizzata che combina un [contratto intelligente](/developers/docs/smart-contracts/) e un'interfaccia utente frontend. Su [Ethereum](/), i contratti intelligenti sono accessibili e trasparenti, come delle API aperte, quindi la tua dApp può persino includere un contratto intelligente scritto da qualcun altro.
## Prerequisiti {#prerequisites}
-Prima di approfondire le dapp, è consigliabile conoscere le [basi della blockchain](/developers/docs/intro-to-ethereum/) e informarsi sulla rete Ethereum e sul perché è decentralizzata.
+Prima di imparare a conoscere le dApp, dovresti coprire le [basi della blockchain](/developers/docs/intro-to-ethereum/) e leggere della rete di Ethereum e di come sia decentralizzata.
-## Definizione di dapp {#definition-of-a-dapp}
+## Definizione di una dApp {#definition-of-a-dapp}
-Il codice backend di una dapp viene eseguito su una rete decentralizzata peer-to-peer. L'opposto di quello che succede con una app il cui codice backend gira su server centralizzati.
+Una dApp ha il suo codice di backend in esecuzione su una rete peer-to-peer decentralizzata. Confrontalo con un'app in cui il codice di backend è in esecuzione su server centralizzati.
-Una dapp può avere codice frontend e interfacce utente scritti in qualsiasi linguaggio (come qualsiasi app) che possono fare chiamate al backend. Inoltre, il frontend può essere ospitato su uno storage decentralizzato come [IPFS](https://ipfs.io/).
+Una dApp può avere codice frontend e interfacce utente scritte in qualsiasi linguaggio (proprio come un'app) per effettuare chiamate al suo backend. Inoltre, il suo frontend può essere ospitato su un'archiviazione decentralizzata come [IPFS](https://ipfs.io/).
-- **Decentralizzate** - Le dApp operano su Ethereum, una piattaforma pubblica decentralizzata dove nessun individuo o gruppo detiene il controllo
-- **Deterministiche**: eseguono la stessa funzione a prescindere dall'ambiente dove vengono eseguite.
-- **Turing complete** - Le dApp possono eseguire qualsiasi azione una volta fornite le risorse necessarie
-- **Isolate** - Le dApp sono eseguite in un ambiente virtuale, noto come la Macchina Virtuale di Ethereum, così che se il contratto intelligente contiene un bug, non ostacolerà il normale funzionamento della rete della blockchain
+- **Decentralizzata**: le dApp operano su Ethereum, una piattaforma decentralizzata pubblica e aperta in cui nessuna persona o gruppo ha il controllo.
+- **Deterministica**: le dApp svolgono la stessa funzione indipendentemente dall'ambiente in cui vengono eseguite.
+- **Turing completa**: le dApp possono eseguire qualsiasi azione date le risorse necessarie.
+- **Isolata**: le dApp vengono eseguite in un ambiente virtuale noto come macchina virtuale di Ethereum, in modo che se il contratto intelligente ha un bug, non ostacolerà il normale funzionamento della rete blockchain.
### Sui contratti intelligenti {#on-smart-contracts}
-Per introdurre le dapp, dobbiamo introdurre i contratti intelligenti: la backend di una dapp, in mancanza di un termine migliore. Per una panoramica dettagliata, consulta la nostra sezione sui [contratti intelligenti](/developers/docs/smart-contracts/).
+Per introdurre le dApp, dobbiamo introdurre i contratti intelligenti: il backend di una dApp, in mancanza di un termine migliore. Per una panoramica dettagliata, vai alla nostra sezione sui [contratti intelligenti](/developers/docs/smart-contracts/).
-Un contratto intelligente è codice che risiede sulla blockchain di Ethereum e opera esattamente come programmato. Una volta distribuiti i contratti intelligenti sulla rete, non puoi modificarli. Le dapp possono essere decentralizzate perché sono controllate della logica scritta nel contratto, non da un individuo o da un'azienda. Questo significa anche che devi progettare i tuoi contratti molto attenteamente e testarli accuratamente.
+Un contratto intelligente è un codice che risiede sulla blockchain di Ethereum e viene eseguito esattamente come programmato. Una volta che i contratti intelligenti sono distribuiti sulla rete, non puoi modificarli. Le dApp possono essere decentralizzate perché sono controllate dalla logica scritta nel contratto, non da un individuo o da un'azienda. Questo significa anche che devi progettare i tuoi contratti con molta attenzione e testarli a fondo.
-## Vantaggi dello sviluppo delle dapp {#benefits-of-dapp-development}
+## Vantaggi dello sviluppo di dApp {#benefits-of-dapp-development}
-- **Nessun tempo di inattività** – Una volta distribuito il contratto intelligente sulla blockchain, l'intera rete potrà sempre servire i clienti che cercano di interagire con il contratto. Gli attori malevoli quindi non possono lanciare attacchi denial-of-service verso dapp singole.
-- **Privacy**: non è necessario fornire un'identità reale per distribuire una dapp o interagirvi.
-- **Resistenza alla censura**: nessuna entità sulla rete può impedire agli utenti di inviare transazioni, distribuire dapp o leggere dati dalla blockchain.
-- **Completa integrità dei dati**: i dati conservati sulla blockchain sono immutabili e indiscutibili, grazie alle primitive crittografiche. Attori malevoli non possono falsificare transazioni o altri dati che sono già stati resi pubblici.
-- **Calcolo senza fiducia/comportamento verificabile** – I contratti intelligenti sono analizzabili e, l'esecuzione in modi prevedibili è garantita, senza il bisogno di affidarsi a un'autorità centrale. Questo non accade nei modelli tradizionali. Per esempio, quando usiamo l'online banking dobbiamo fidarci del fatto che gli istituti finanziari non abusino dei nostri dati finanziari, non manomettano record e non vengano attaccati da hacker.
+- **Zero tempi di inattività**: una volta che il contratto intelligente è distribuito sulla blockchain, la rete nel suo complesso sarà sempre in grado di servire i client che cercano di interagire con il contratto. Gli attori malintenzionati, pertanto, non possono lanciare attacchi denial-of-service mirati a singole dApp.
+- **Privacy**: non è necessario fornire un'identità del mondo reale per distribuire o interagire con una dApp.
+- **Resistenza alla censura**: nessuna singola entità sulla rete può impedire agli utenti di inviare transazioni, distribuire dApp o leggere dati dalla blockchain.
+- **Integrità completa dei dati**: i dati archiviati sulla blockchain sono immutabili e indiscutibili, grazie alle primitive crittografiche. Gli attori malintenzionati non possono falsificare transazioni o altri dati che sono già stati resi pubblici.
+- **Calcolo senza fiducia/comportamento verificabile**: i contratti intelligenti possono essere analizzati e sono garantiti per essere eseguiti in modi prevedibili, senza la necessità di fidarsi di un'autorità centrale. Questo non è vero nei modelli tradizionali; ad esempio, quando utilizziamo i sistemi bancari online, dobbiamo fidarci che le istituzioni finanziarie non abusino dei nostri dati finanziari, non manomettano i registri o non vengano hackerate.
## Svantaggi dello sviluppo di dApp {#drawbacks-of-dapp-development}
-- **Manutenzione**: le dapp possono essere impegnative da mantenere perché il codice e i dati pubblicati sulla blockchain sono più difficili da modificare. Per gli sviluppatori, è difficile apportare degli aggiornamenti alle loro dApp (o ai dati sottostanti, memorizzati da una dApp) una volta distribuite, anche se vengono individuati dei bug o rischi di sicurezza in una versione precedente.
-- **Overhead delle prestazioni**: l'overhead delle prestazioni è enorme e scalare è davvero difficile. Per raggiungere il livello di sicurezza, integrità, trasparenza e affidabilità al quale aspira Ethereum, ogni nodo esegue e memorizza ogni transazione. Oltre a ciò, anche il consenso di proof-of-stake richiede tempo.
-- **Congestione della rete**: quando una dApp utilizza troppe risorse di calcolo, l'intera rete viene sostenuta. Attualmente, la rete è in grado di elaborare circa 10 transazioni al secondo; se le transazioni vengono inviate a un ritmo più alto, l'insieme di transazioni non confermate può "gonfiarsi" e accumularsi.
-- **Esperienza utente**: potrebbe essere difficile creare esperienze intuitive. L'utente medio potrebbe trovare troppo difficile configurare la serie di strumenti necessaria a interagire con la blockchain in modo veramente sicuro.
-- **Centralizzazione**: soluzioni facili da utilizzare e compatibili con gli sviluppatori costruite sullo strato base di Ethereum potrebbero finire per assomigliare comunque a servizi centralizzati. Ad esempio, tali servizi potrebbero memorizzare le chiavi o altre informazioni sensibili sul lato del server, servire un frontend utilizzando un server centralizzato oppure utilizzare un'importante logica commerciale su un server centralizzato prima di scrivere sulla blockchain. La centralizzazione annulla molti (se non tutti) i vantaggi della blockchain rispetto al modello tradizionale.
+- **Manutenzione**: le dApp possono essere più difficili da mantenere perché il codice e i dati pubblicati sulla blockchain sono più difficili da modificare. È difficile per gli sviluppatori apportare aggiornamenti alle loro dApp (o ai dati sottostanti archiviati da una dApp) una volta distribuite, anche se vengono identificati bug o rischi per la sicurezza in una vecchia versione.
+- **Sovraccarico delle prestazioni**: c'è un enorme sovraccarico delle prestazioni e la scalabilità è davvero difficile. Per raggiungere il livello di sicurezza, integrità, trasparenza e affidabilità a cui aspira Ethereum, ogni nodo esegue e archivia ogni transazione. Oltre a questo, anche il consenso della prova di stake richiede tempo.
+- **Congestione della rete**: quando una dApp utilizza troppe risorse computazionali, l'intera rete si blocca. Attualmente, la rete può elaborare solo circa 10-15 transazioni al secondo; se le transazioni vengono inviate più velocemente di così, il pool di transazioni non confermate può gonfiarsi rapidamente.
+- **Esperienza utente**: potrebbe essere più difficile progettare esperienze user-friendly perché l'utente finale medio potrebbe trovare troppo difficile configurare uno stack di strumenti necessario per interagire con la blockchain in modo veramente sicuro.
+- **Centralizzazione**: le soluzioni user-friendly e developer-friendly costruite sopra il livello di base di Ethereum potrebbero finire per sembrare comunque servizi centralizzati. Ad esempio, tali servizi potrebbero archiviare chiavi o altre informazioni sensibili lato server, servire un frontend utilizzando un server centralizzato o eseguire importanti logiche aziendali su un server centralizzato prima di scrivere sulla blockchain. La centralizzazione elimina molti (se non tutti) i vantaggi della blockchain rispetto al modello tradizionale.
-## Preferisci un approccio visivo all'apprendimento? {#visual-learner}
+## Preferisci imparare visivamente? {#visual-learner}
.json`, dove `` è l'UUID a 128 bit assegnato alla chiave segreta (un proxy che preserva la privacy per l'indirizzo della chiave segreta).
+
+Tutti questi file hanno una password associata. Per derivare la chiave segreta di un dato file `.json`, prima deriva la chiave di crittografia del file; questo viene fatto prendendo la password del file e passandola attraverso una funzione di derivazione della chiave come descritto dalla chiave `kdf`. I parametri statici e dinamici dipendenti dalla KDF per la funzione KDF sono descritti nella chiave `kdfparams`.
+
+PBKDF2 deve essere supportato da tutte le implementazioni minimamente conformi, indicato tramite:
+
+- `kdf`: `pbkdf2`
+
+Per PBKDF2, i kdfparams includono:
+
+- `prf`: Deve essere `hmac-sha256` (potrebbe essere esteso in futuro);
+- `c`: numero di iterazioni;
+- `salt`: salt passato a PBKDF;
+- `dklen`: lunghezza per la chiave derivata. Deve essere >= 32.
+
+Una volta derivata la chiave del file, dovrebbe essere verificata attraverso la derivazione del MAC. Il MAC dovrebbe essere calcolato come l'hash SHA3 (keccak-256) dell'array di byte formato come le concatenazioni dei secondi 16 byte da sinistra della chiave derivata con i contenuti della chiave `ciphertext`, ovvero:
+
+```js
+KECCAK(DK[16..31] ++ )
+```
+
+(dove `++` è l'operatore di concatenazione)
+
+Questo valore dovrebbe essere confrontato con i contenuti della chiave `mac`; se sono diversi, dovrebbe essere richiesta una password alternativa (o l'operazione annullata).
+
+Dopo che la chiave del file è stata verificata, il testo cifrato (la chiave `ciphertext` nel file) può essere decrittografato utilizzando l'algoritmo di crittografia simmetrica specificato dalla chiave `cipher` e parametrizzato tramite la chiave `cipherparams`. Se la dimensione della chiave derivata e la dimensione della chiave dell'algoritmo non corrispondono, i byte più a destra, riempiti di zeri, della chiave derivata dovrebbero essere usati come chiave per l'algoritmo.
+
+Tutte le implementazioni minimamente conformi devono supportare l'algoritmo AES-128-CTR, indicato tramite:
+
+- `cipher: aes-128-ctr`
+
+Questo cifrario accetta i seguenti parametri, forniti come chiavi alla chiave cipherparams:
+
+- `iv`: vettore di inizializzazione a 128 bit per il cifrario.
+
+La chiave per il cifrario sono i 16 byte più a sinistra della chiave derivata, ovvero `DK[0..15]`
+
+La creazione/crittografia di una chiave segreta dovrebbe essere essenzialmente l'inverso di queste istruzioni. Assicurati che `uuid`, `salt` e `iv` siano effettivamente casuali.
+
+Oltre al campo `version`, che dovrebbe fungere da identificatore "rigido" della versione, le implementazioni possono anche utilizzare `minorversion` per tracciare modifiche più piccole e non bloccanti al formato.
+
+## Vettori di Test {#test-vectors}
+
+Dettagli:
+
+- `Indirizzo`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b`
+- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67`
+- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6`
+- `Password`: `testpassword`
+- `Segreto`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d`
+
+### PBKDF2-SHA-256 {#PBKDF2-SHA-256}
+
+Vettore di test che utilizza `AES-128-CTR` e `PBKDF2-SHA-256`:
+
+Contenuti del file `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "6087dab2f9fdbbfaddc31a909735c1e6"
+ },
+ "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46",
+ "kdf": "pbkdf2",
+ "kdfparams": {
+ "c": 262144,
+ "dklen": 32,
+ "prf": "hmac-sha256",
+ "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd"
+ },
+ "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**Intermedi**:
+
+`Chiave derivata`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551`
+`Corpo del MAC`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46`
+`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2`
+`Chiave del cifrario`: `f06d69cdc7da0faffb1008270bca38f5`
+
+### Scrypt {#scrypt}
+
+Vettore di test che utilizza AES-128-CTR e Scrypt:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-ctr",
+ "cipherparams": {
+ "iv": "740770fce12ce862af21264dab25f1da"
+ },
+ "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2",
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034"
+ },
+ "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c"
+ },
+ "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6",
+ "version": 3
+}
+```
+
+**Intermedi**:
+
+`Chiave derivata`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d`
+`Corpo del MAC`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2`
+`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c`
+`Chiave del cifrario`: `7446f59ecc301d2d79bc3302650d8a5c`
+
+## Modifiche dalla Versione 1 {#alterations-from-v2}
+
+Questa versione corregge diverse incongruenze con la versione 1 pubblicata [qui](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst). In breve queste sono:
+
+- L'uso delle maiuscole è ingiustificato e incoerente (scrypt minuscolo, Kdf misto, MAC maiuscolo).
+- L'indirizzo non è necessario e compromette la privacy.
+- `Salt` è intrinsecamente un parametro della funzione di derivazione della chiave e merita di esservi associato, non alla crittografia in generale.
+- _SaltLen_ non è necessario (basta derivarlo da Salt).
+- La funzione di derivazione della chiave è fornita, eppure l'algoritmo crittografico è fissato rigidamente.
+- `Version` è intrinsecamente numerico eppure è una stringa (il controllo delle versioni strutturato sarebbe possibile con una stringa, ma può essere considerato fuori ambito per un formato di file di configurazione che cambia raramente).
+- `KDF` e `cipher` sono concettualmente concetti fratelli eppure sono organizzati in modo diverso.
+- `MAC` è calcolato attraverso un dato indipendente dagli spazi vuoti(!)
+
+Sono state apportate modifiche al formato per fornire il seguente file, funzionalmente equivalente all'esempio fornito nella pagina precedentemente collegata:
+
+```json
+{
+ "crypto": {
+ "cipher": "aes-128-cbc",
+ "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b",
+ "cipherparams": {
+ "iv": "16d67ba0ce5a339ff2f07951253e6ba8"
+ },
+ "kdf": "scrypt",
+ "kdfparams": {
+ "dklen": 32,
+ "n": 262144,
+ "p": 1,
+ "r": 8,
+ "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91"
+ },
+ "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd",
+ "version": 1
+ },
+ "id": "0498f19a-59db-4d54-ac95-33901b4f1870",
+ "version": 2
+}
+```
+
+## Modifiche dalla Versione 2 {#alterations-from-v2}
+
+La versione 2 era una prima implementazione in C++ con una serie di bug. Tutti gli elementi essenziali rimangono invariati rispetto ad essa.
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/it/developers/docs/design-and-ux/dex-design-best-practice/index.md
index c63da6300fd..3b046faed45 100644
--- a/public/content/translations/it/developers/docs/design-and-ux/dex-design-best-practice/index.md
+++ b/public/content/translations/it/developers/docs/design-and-ux/dex-design-best-practice/index.md
@@ -1,220 +1,216 @@
---
-title: Buone pratiche di progettazione di borse decentralizzate (DEX)
+title: Migliori pratiche di progettazione per gli exchange decentralizzati (DEX)
description: Una guida che spiega le decisioni UX/UI per lo scambio di token.
lang: it
---
-Dal lancio di Uniswap nel 2018, sono state lanciate centinaia di borse decentralizzate in decine di catene differenti.
-Molte di queste hanno introdotto nuovi elementi o aggiunto i propri tocchi, ma l'interfaccia è rimasta per lo più la stessa.
+Dal lancio di Uniswap nel 2018, sono stati lanciati centinaia di exchange decentralizzati su dozzine di catene diverse.
+Molti di questi hanno introdotto nuovi elementi o aggiunto il proprio tocco personale, ma l'interfaccia è rimasta generalmente la stessa.
-Una delle ragioni è la [Legge di Jakob](https://lawsofux.com/jakobs-law/):
+Una ragione di ciò è la [Legge di Jakob](https://lawsofux.com/jakobs-law/):
-> Gli utenti trascorrono la maggior parte del tempo su altri siti. Ciò significa che gli utenti preferiscono che il tuo sito funzioni proprio come gli altri che già conoscono.
+> Gli utenti trascorrono la maggior parte del loro tempo su altri siti. Ciò significa che gli utenti preferiscono che il tuo sito funzioni allo stesso modo di tutti gli altri siti che già conoscono.
-Grazie ai primi innovatori come Uniswap, Pancakeswap e Sushiswap, gli utenti della DeFi hanno un'idea collettiva dell'aspetto di una DEX.
-Per questo motivo adesso sta emergendo qualcosa di simile alle "buone pratiche". Osserviamo una sempre maggiore standardizzazione delle decisioni di progettazione nei vari siti. L'evoluzione delle DEX può essere visto come un grande esempio di test in corso d'opera. Le cose che hanno funzionato rimangono, mentre quelle che non hanno funzionato vengono scartate. C'è ancora spazio per la personalità, ma ci sono alcuni standard a cui una DEX si deve conformare.
-
-Questo articolo è il riassunto di:
+Grazie ai primi innovatori come Uniswap, Pancakeswap e Sushiswap, gli utenti della DeFi hanno un'idea collettiva di come sia fatto un DEX.
+Per questo motivo, sta ora emergendo qualcosa di simile a una "migliore pratica". Vediamo sempre più decisioni di progettazione standardizzate tra i siti. Puoi vedere l'evoluzione dei DEX come un gigantesco esempio di test dal vivo. Le cose che hanno funzionato sono rimaste, quelle che non hanno funzionato sono state scartate. C'è ancora spazio per la personalità, ma ci sono determinati standard a cui un DEX dovrebbe conformarsi.
+Questo articolo è un riassunto di:
- cosa includere
-- come renderlo utilizzabile e possibile
-- i modi principali di personalizzare la progettazione
-
-Tutti i wireframe di esempio sono stati realizzati specificatamente per questo articolo, anche se si basano su progetti reali.
+- come renderlo il più utilizzabile possibile
+- i modi principali per personalizzare il design
-In fondo è incluso anche il kit di Figma: puoi usarlo liberamente per velocizzare i tuoi wireframe!
+Tutti i wireframe di esempio sono stati realizzati specificamente per questo articolo, sebbene siano tutti basati su progetti reali.
-## Anatomia di base di uan DEX {#basic-anatomy-of-a-dex}
+Il kit Figma è incluso anche in fondo: sentiti libero di usarlo e velocizzare i tuoi wireframe!
-L'interfaccia utente (UI) in genere contiene tre elementi:
+## Anatomia di base di un DEX {#basic-anatomy-of-a-dex}
+L'interfaccia utente (UI) contiene generalmente tre elementi:
1. Modulo principale
2. Pulsante
3. Pannello dei dettagli
-
-
-## Varianti {#variations}
+
-Questo sarà un tema ricorrente in questo articolo, ma ci sono modi diversi con i quali questi elementi possono essere organizzati. I "pannello dei dettagli" può essere:
+## Variazioni {#variations}
+Questo sarà un tema comune in questo articolo, ma ci sono vari modi diversi in cui questi elementi possono essere organizzati. Il "pannello dei dettagli" può essere:
- Sopra il pulsante
- Sotto il pulsante
-- Nascosto in un pannello accordion
-- E/o in una finestra modale “anteprima”
-
-N.B. Una finestra modale "anteprima" è facoltativa ma diventa essenziale se si stanno mostrando pochissimi dettagli sull'UI principale.
+- Nascosto in un pannello a fisarmonica
+- E/o su un modale di "anteprima"
+
+N.B. Un modale di "anteprima" è opzionale, ma se stai mostrando pochissimi dettagli sull'UI principale, diventa essenziale.
## Struttura del modulo principale {#structure-of-the-main-form}
-Questo è il riquadro dove si sceglie di fatto quale token scambiare. Il componente consiste in un campo di input e un piccolo pulsante sulla stessa riga.
+Questo è il riquadro in cui scegli effettivamente quale token vuoi scambiare. Il componente è costituito da un campo di input e da un piccolo pulsante in una riga.
-Le DEX di solito mostrano ulteriori dettagli su una riga sopra e una sotto, anche se questo può essere configurato diversamente.
+I DEX in genere mostrano dettagli aggiuntivi in una riga sopra e una riga sotto, sebbene ciò possa essere configurato diversamente.
-
+
-## Varianti {#variations2}
+## Variazioni {#variations2}
-Qui sono mostrate due varianti della UI: una senza bordi, creando un design molto aperto, e una dove la riga di input ha un bordo, creando un focus su quell'elemento.
+Qui sono mostrate due variazioni dell'UI; una senza alcun bordo, creando un design molto aperto, e una in cui la riga di input ha un bordo, creando un focus su quell'elemento.
-
+
-Questa struttura di base permette di visualizzare **quattro informazioni chiave** nel design: una in ogni angolo. Se c'è solo una riga sopra/sotto, allora ci sono solo due punti focali.
+Questa struttura di base consente di mostrare **quattro informazioni chiave** nel design: una in ogni angolo. Se c'è solo una riga superiore/inferiore, allora ci sono solo due posti.
-Durante l'evoluzione della DeFi, qui sono stati inclusi molti elementi diversi.
+Durante l'evoluzione della DeFi, qui sono state incluse molte cose diverse.
## Informazioni chiave da includere {#key-info-to-include}
- Saldo nel portafoglio
-- Pulsante max
-- Equivalente in valuta legale
-- Impatto del prezzo sull'importo "ricevuto"
-
-Agli albori della DeFi, l'equivalente in valuta legale era spesso mancante. Se si sta costruendo qualsiasi progetto Web3, è essenziale che sia mostrato un equivalente in valuta legale. Gli utenti pensano ancora in termini di valuta locale, quindi questo dato dovrebbe essere incluso per adeguarsi ai modelli mentali del mondo reale.
+- Pulsante Max
+- Equivalente in valuta fiat
+- Impatto sul prezzo dell'importo "ricevuto"
-Nel secondo campo (quello dove si sceglie il token per il quale effettuare lo scambio), vicino all'importo in valuta legale è possibile includere anche l'impatto del prezzo, calcolando la differenza tra l'importo dell'input e la stima dell'importo dell'output. Questo è un dettaglio piuttosto utile da includere.
+Agli albori della DeFi, l'equivalente in valuta fiat era spesso assente. Se stai costruendo qualsiasi tipo di progetto web3, è essenziale che venga mostrato un equivalente in valuta fiat. Gli utenti pensano ancora in termini di valute locali, quindi per corrispondere ai modelli mentali del mondo reale, questo dovrebbe essere incluso.
-I pulsanti di percentuale (ad es. 25%, 50%, 75%) possono essere una funzione utile, ma occupano più spazio, aggiungono più chiamate all'azione e aumentano il carico mentale. Lo stesso vale per i cursori percentuali. Alcune di queste decisioni sulla UI dipendono dal proprio brand e dal proprio tipo di utente.
+Nel secondo campo (quello in cui scegli il token verso cui stai scambiando) puoi anche includere l'impatto sul prezzo accanto all'importo in valuta fiat, calcolando la differenza tra l'importo di input e gli importi di output stimati. Questo è un dettaglio piuttosto utile da includere.
-Sotto il modulo principale possono essere visualizzati dettagli extra. Dato che questo tipo di informazione è soprattutto per gli utenti avanzati, ha senso:
+I pulsanti percentuali (ad es. 25%, 50%, 75%) possono essere una funzionalità utile, ma occupano più spazio, aggiungono più inviti all'azione e aumentano il carico mentale. Lo stesso vale per i cursori percentuali. Alcune di queste decisioni sull'UI dipenderanno dal tuo marchio e dal tuo tipo di utente.
-- tenerli il più minimali possibile, oppure;
-- nasconderli nel pannello accordion
+Dettagli extra possono essere mostrati sotto il modulo principale. Poiché questo tipo di informazioni è principalmente per utenti professionisti, ha senso:
+- mantenerlo il più minimale possibile, oppure;
+- nasconderlo in un pannello a fisarmonica
-
+
## Informazioni extra da includere {#extra-info-to-include}
-- Prezzo dei token
-- Scivolamento
+- Prezzo del token
+- Slippage
- Minimo ricevuto
- Output previsto
-- Impatto del prezzo
+- Impatto sul prezzo
- Stima del costo del gas
- Altre commissioni
-- Instradamento degli ordini
+- Instradamento dell'ordine
-Probabilmente alcuni di questi dettagli potrebbero essere facoltativi.
+Probabilmente, alcuni di questi dettagli potrebbero essere opzionali.
-L'instradamento degli ordini è interessante, ma non fa molta differenza per la maggior parte degli utenti.
+L'instradamento dell'ordine è interessante, ma non fa molta differenza per la maggior parte degli utenti.
-Altri dettagli ripetono semplicemente la stessa cosa in modi diversi. Per esempio "minimo ricevuto" e "scivolamento" sono due facce della stessa medaglia. Se si ha lo scivolamento fissato all'1%, allora il minimo che ci si può aspettare di ricevere = output previsto -1%. Alcune UI visualizzeranno la quantità prevista, la quantità minima e lo scivolamento… Il che è utile ma forse eccessivo.
+Alcuni altri dettagli stanno semplicemente ribadendo la stessa cosa in modi diversi. Ad esempio "minimo ricevuto" e "slippage" sono due facce della stessa medaglia. Se hai lo slippage impostato all'1%, allora il minimo che puoi aspettarti di ricevere = output previsto-1%. Alcune UI mostreranno l'importo previsto, l'importo minimo e lo slippage... Il che è utile ma forse eccessivo.
-Molti utenti lasceranno in ogni caso lo scivolamento predefinito.
+La maggior parte degli utenti lascerà comunque lo slippage predefinito.
-L'"impatto del prezzo" è spesso visualizzato tra parentesi vicino all'equivalente in valuta legale nel campo "a". Questo è un fantastico dettaglio UX da aggiungere – ma se viene visualizzato qui, occorre davvero che sia mostrato di nuovo anche sotto? E poi ancora una volta su una schermata di anteprima?
+L'"impatto sul prezzo" è spesso mostrato tra parentesi accanto all'equivalente in valuta fiat nel campo "verso". Questo è un ottimo dettaglio UX da aggiungere, ma se viene mostrato qui, ha davvero bisogno di essere mostrato di nuovo sotto? E poi di nuovo in una schermata di anteprima?
-A molti utenti (specialmente quelli che scambiano piccole cifre) non interessano questi dettagli; vogliono semplicemente immettere un numero e cliccare su scambia.
+A molti utenti (specialmente quelli che scambiano piccole somme) non importerà di questi dettagli; inseriranno semplicemente un numero e premeranno scambia.
-I dettagli precisi che saranno visualizzati dipenderà dal proprio pubblico e dall'impatto che si vuole abbia la propria applicazione.
+Esattamente quali dettagli vengono mostrati dipenderà dal tuo pubblico e dall'atmosfera che vuoi che l'app abbia.
-Se si decide di includere la tolleranza di scivolamento nel pannello dei dettagli, dovrebbe anche essere resa modificabile direttamente da lì. Questo è un buon esempio di "acceleratore"; un trucco per una UX pulita che può velocizzare il flusso degli utenti esperti senza inficiare l'usabilità generale dell'applicazione.
+Se includi la tolleranza allo slippage nel pannello dei dettagli, dovresti anche renderla modificabile direttamente da qui. Questo è un buon esempio di "acceleratore"; un trucco UX pulito che può velocizzare i flussi degli utenti esperti, senza influire sull'usabilità generale dell'app.
-
+
-È una buona idea pensare attentamente non solo a un'informazione specifica in una schermata, ma all'intero flusso come segue:
-Immettere numeri nel Modulo principale → Rivedere i dettagli → Fare clic sulla Schermata di anteprima (se prevista).
-Il pannello dei dettagli dev'essere sempre visibile o l'utente deve cliccare per ampliarlo?
-Andrebbe creata frizione aggiungendo una schermata di anteprima? Questo obbliga l'utente a rallentare e valutare lo scambio, il che può essere utile. Ma desidera vedere di nuovo le stesse informazioni? Qual è la più importante a questo punto?
+È una buona idea pensare attentamente non solo a una specifica informazione su una schermata, ma all'intero flusso:
+Inserimento dei numeri nel Modulo Principale → Scansione dei Dettagli → Clic sulla Schermata di Anteprima (se hai una schermata di anteprima).
+Il pannello dei dettagli dovrebbe essere sempre visibile o l'utente deve cliccarlo per espanderlo?
+Dovresti creare attrito aggiungendo una schermata di anteprima? Questo costringe l'utente a rallentare e considerare il proprio scambio, il che può essere utile. Ma vogliono vedere di nuovo tutte le stesse informazioni? Cosa è più utile per loro a questo punto?
-## Opzioni di progettazione {#design-options}
+## Opzioni di design {#design-options}
-Come detto, molto di tutto ciò dipende dal proprio stile personale
-Chi è il proprio utente?
-Qual è il proprio marchio?
-Si desidera un'interfaccia avanzata che visualizzi ogni dettaglio o qualcosa di minimalista?
-Anche se si mira agli utenti avanzati che vogliono tutte le informazioni possibili, non bisogna dimenticare le parole sagge di Alan Cooper:
+Come accennato, molto di questo si riduce al tuo stile personale
+Chi è il tuo utente?
+Qual è il tuo marchio?
+Vuoi un'interfaccia "pro" che mostri ogni dettaglio o vuoi essere minimalista?
+Anche se punti agli utenti pro che vogliono tutte le informazioni possibili, dovresti comunque ricordare le sagge parole di Alan Cooper:
-> Non importa quanto bella o di tendenza sia la tua interfaccia, sarebbe ancora più bella se fosse ridotta.
+> Non importa quanto sia bella, non importa quanto sia fantastica la tua interfaccia, sarebbe meglio se ce ne fosse di meno.
### Struttura {#structure}
-- token sulla sinistra, o token sulla destra
+- token a sinistra o token a destra
- 2 righe o 3
- dettagli sopra o sotto il pulsante
-- dettagli ampliati, ridotti a icona o non visualizzati
+- dettagli espansi, ridotti a icona o non mostrati
-### Stile dei componenti {#component-style}
+### Stile del componente {#component-style}
- vuoto
-- bordato
-- pieno
+- contornato
+- riempito
-Da un punto di vista puramente UX, lo stile della UI è meno importante di quanto si pensi. Le tendenze vanno e vengono ciclicamente e molte preferenze sono soggettive.
+Da un punto di vista puramente UX, lo stile dell'UI conta meno di quanto pensi. Le tendenze visive vanno e vengono in cicli e gran parte delle preferenze è soggettiva.
-Il modo più facile per farsi un'idea – e pensare alle varie configurazioni diverse – è dare un'occhiata ad alcuni esempi e poi sperimentare.
+Il modo più semplice per farsi un'idea di questo - e pensare alle varie configurazioni diverse - è dare un'occhiata ad alcuni esempi e poi fare qualche esperimento da soli.
-Il kit di Figma incluso contiene componenti vuoti, bordati e pieni.
+Il kit Figma incluso contiene componenti vuoti, contornati e riempiti.
-Dai un'occhiata ai seguenti esempi per vedere modi diversi per combinarli:
+Dai un'occhiata agli esempi seguenti per vedere i diversi modi in cui puoi mettere tutto insieme:
-
+
-
+
-
+
-
+
-
+
-## Ma da quale parte dovrebbe andare il token? {#but-which-side-should-the-token-go-on}
+## Ma da che parte dovrebbe andare il token? {#but-which-side-should-the-token-go-on}
-Il punto è che probabilmente non farà molta differenza in quanto a usabilità. Ci sono alcune cose da tenere comunque presenti che potrebbero influenzarti in un modo o nell'altro.
+Il punto fondamentale è che probabilmente non fa un'enorme differenza per l'usabilità. Ci sono alcune cose da tenere a mente, tuttavia, che potrebbero farti propendere da una parte o dall'altra.
-È abbastanza interessante vedere come la moda cambia con il tempo. Uniswap inizialmente aveva il token sulla sinistra ma lo ha poi spostato sulla destra. Anche Sushiswap fece questo cambiamento durante un aggiornamento di design. Molti ma non tutti i protocolli hanno fatto altrettanto.
+È stato moderatamente interessante vedere la moda cambiare nel tempo. Uniswap inizialmente aveva il token a sinistra, ma da allora lo ha spostato a destra. Anche Sushiswap ha apportato questa modifica durante un aggiornamento del design. La maggior parte dei protocolli, ma non tutti, ha seguito l'esempio.
-La convenzione finanziaria mette tradizionalmente il simbolo della valuta prima del numero, ad es. $50, €50, £50, ma _diciamo_ 50 dollari, 50 euro, 50 sterline.
+La convenzione finanziaria tradizionalmente mette il simbolo della valuta prima del numero, ad es. $50, €50, £50, ma noi *diciamo* 50 dollari, 50 euro, 50 sterline.
-Per l'utente generico – specialmente qualcuno che legge da sinistra a destra, dall'alto al basso – il token sulla destra risulta probabilmente più naturale.
+Per l'utente generico - specialmente qualcuno che legge da sinistra a destra, dall'alto verso il basso - il token a destra probabilmente sembra più naturale.
-
+
-Mettere il token sulla sinistra e tutti i numeri sulla destra dà un aspetto piacevolmente simmetrico, il che è un vantaggio, ma c'è un altro lato negativo in questa disposizione.
+Mettere il token a sinistra e tutti i numeri a destra sembra piacevolmente simmetrico, il che è un vantaggio, ma c'è un altro svantaggio in questo layout.
-La legge della prossimità dice che gli elementi vicini sono percepiti come correlati. Di conseguenza vogliamo mettere gli elementi correlati gli uni vicini agli altri. Il saldo del token è direttamente correlato al token stesso e cambierà ogni volta che viene selezionato un nuovo token. Ha quindi più senso che il saldo dei token sia vicino al pulsante per selezionare il token. Potrebbe essere spostato sotto il token, ma in questo modo si romperebbe la simmetria della disposizione.
+La legge della prossimità afferma che gli elementi vicini tra loro sono percepiti come correlati. Di conseguenza, vogliamo posizionare gli elementi correlati uno accanto all'altro. Il saldo del token è direttamente correlato al token stesso e cambierà ogni volta che viene selezionato un nuovo token. Ha quindi leggermente più senso che il saldo del token si trovi accanto al pulsante di selezione del token. Potrebbe essere spostato sotto il token, ma ciò rompe la simmetria del layout.
-In definitiva ci sono pro e contro in entrambe le opzioni, ma è interessante come il trend sembri andare verso il token sulla destra.
+In definitiva, ci sono pro e contro per entrambe le opzioni, ma è interessante come la tendenza sembri essere verso il token a destra.
## Comportamento del pulsante {#button-behavior}
-Non inserire un pulsante separato per Approva. Inoltre, non prevedere clic separati per Approva. L'utente vuole Scambiare, quindi basta indicare "scambia" sul pulsante e avviare l'approvazione come primo passaggio. Una finestra modale può mostrare il progresso con uno stepper o con una semplice notifica che dica "tx 1 di 2 - approvazione in corso".
+Non avere un pulsante separato per Approva. Inoltre, non avere un clic separato per Approva. L'utente vuole Scambiare, quindi scrivi semplicemente "scambia" sul pulsante e avvia l'approvazione come primo passo. Un modale può mostrare i progressi con un indicatore di passaggi, o una semplice notifica "tx 1 di 2 - approvazione in corso".
-
+
-
+
-### Pulsanti come aiuto contestuale {#button-as-contextual-help}
+### Pulsante come aiuto contestuale {#button-as-contextual-help}
-Il pulsante può svolgere il doppio compito di avviso!
+Il pulsante può svolgere una doppia funzione come avviso!
-Questo è infatti un modello di progettazione abbastanza insolito fuori dal Web3, ma è diventato la norma al suo interno. Si tratta di un'ottima innovazione che fa risparmiare spazio e tiene focalizzata l'attenzione.
+Questo è in realtà un modello di progettazione piuttosto insolito al di fuori del web3, ma è diventato standard al suo interno. Questa è una buona innovazione in quanto fa risparmiare spazio e mantiene l'attenzione focalizzata.
-Se l'azione principale – SCAMBIO – non è disponibile a causa di un errore, la ragione può essere spiegata attraverso il pulsante, ad es.:
+Se l'azione principale - SCAMBIA - non è disponibile a causa di un errore, il motivo può essere spiegato con il pulsante, ad es.:
- cambia rete
- connetti portafoglio
-- errori vari
+- vari errori
-Il pulsante può anche venire **mappato all'azione** che deve essere eseguita. Per esempio, se un utente non può effettuare lo scambio perché è nella rete sbagliata, il pulsante dovrebbe dire "passa a Ethereum", e quando l'utente clicca sul pulsante la rete dovrebbe passare a Ethereum. Questo velocizza il flusso dell'utente in maniera significativa.
+Il pulsante può anche essere **mappato all'azione** che deve essere eseguita. Ad esempio, se l'utente non può scambiare perché si trova sulla rete sbagliata, il pulsante dovrebbe dire "passa a Ethereum" e, quando l'utente fa clic sul pulsante, dovrebbe cambiare la rete in Ethereum. Questo accelera notevolmente il flusso dell'utente.
-
+
-### Costruisci la tua con questo file di Figma {#build-your-own-with-this-figma-file}
+## Costruisci il tuo con questo file Figma {#build-your-own-with-this-figma-file}
-Grazie al duro lavoro di vari protocolli, la progettazione delle DEX è migliorata parecchio. Sappiamo di quali informazioni ha bisogno l'utente, come dobbiamo visualizzarle e come far andare più liscio possibile il flusso.
-Speriamo che questo articolo ti abbia dato una solida panoramica dei principi UX.
+Grazie al duro lavoro di molteplici protocolli, il design dei DEX è migliorato molto. Sappiamo di quali informazioni ha bisogno l'utente, come dovremmo mostrarle e come rendere il flusso il più fluido possibile.
+Speriamo che questo articolo fornisca una solida panoramica dei principi UX.
-Se desideri sperimentare, sentiti libero di utilizzare il kit wireframe di Figma. È tenuto il più semplice possibile ma ha abbastanza flessibilità per costruire la struttura di base in vari modi.
+Se vuoi sperimentare, sentiti libero di usare il kit wireframe di Figma. È mantenuto il più semplice possibile, ma ha abbastanza flessibilità per costruire la struttura di base in vari modi.
[Kit wireframe di Figma](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit)
-La DeFi continuerà a evolversi e ci sarà sempre margine di miglioramento.
+La DeFi continuerà a evolversi e c'è sempre spazio per miglioramenti.
-Buona fortuna!
+Buona fortuna!
\ No newline at end of file
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..d27bcfef1bc 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,138 +1,131 @@
---
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
---
-Le euristiche di usabilità sono “regole pratiche” generali che puoi utilizzare per misurare l'usabilità del tuo sito.
-Le 7 euristiche sono specificamente su misura per il Web3 e dovrebbero essere utilizzate insieme ai [10 principi generali per la progettazione dell'interazione](https://www.nngroup.com/articles/ten-usability-heuristics/) di Jakob Nielsen.
+Le euristiche di usabilità sono "regole pratiche" generali che puoi utilizzare per misurare l'usabilità del tuo sito.
+Le 7 euristiche qui presentate sono specificamente adattate per il Web3 e dovrebbero essere utilizzate insieme ai [10 principi generali per la progettazione dell'interazione](https://www.nngroup.com/articles/ten-usability-heuristics/) di Jakob Nielsen.
## Sette euristiche di usabilità per il web3 {#seven-usability-heuristics-for-web3}
-1. I feedback seguono l'azione
+1. Il feedback segue l'azione
2. Sicurezza e fiducia
-3. L'informazione più importante è ovvia
+3. Le informazioni più importanti sono ovvie
4. Terminologia comprensibile
-5. Le azioni sono le più brevi possibili
+5. Le azioni sono il più brevi possibile
6. Le connessioni di rete sono visibili e flessibili
-7. Controllo dall'applicazione non dal portafoglio
+7. Controllo dall'app, non dal portafoglio
## Definizioni ed esempi {#definitions-and-examples}
### 1. Il feedback segue l'azione {#feedback-follows-action}
-**Dovrebbe essere ovvio quando qualcosa è successo o sta succedendo**
+**Dovrebbe essere ovvio quando qualcosa è successo o sta succedendo.**
-Gli utenti decidono i loro passi successivi basandosi sul risultato delle azioni precedenti. Perciò è essenziale che rimangano informati sullo stato del sistema. Questo è specialmente importante nel Web3 perché a volte le transazioni possono metterci poco tempo a impegnarsi sulla blockchain. Se non c'è un feedback che li informi di aspettare, gli utenti non sanno se è successo qualcosa o meno.
+Gli utenti decidono i loro passi successivi in base al risultato dei passi precedenti. Pertanto è essenziale che rimangano informati sullo stato del sistema. Questo è particolarmente importante nel Web3 poiché le transazioni a volte possono richiedere un po' di tempo per essere registrate sulla blockchain. Se non c'è alcun feedback che li informi di aspettare, gli utenti non sono sicuri che sia successo qualcosa.
-**Suggerimenti:**
-
-- Informare gli utenti con messaggi, notifiche o altri avvisi.
-- Comunicare chiaramente i tempi di attesa.
-- Se un'azione impiegherà più di qualche secondo, rassicurare l'utente con un timer o un'animazione per fargli capire che sta accadendo qualcosa.
-- Se ci sono vari passaggi in un processo, mostrare ogni passaggio.
+**Suggerimenti:**
+- Informa l'utente tramite messaggi, notifiche e altri avvisi.
+- Comunica chiaramente i tempi di attesa.
+- Se un'azione richiederà più di qualche secondo, rassicura l'utente con un timer o un'animazione per fargli capire che sta succedendo qualcosa.
+- Se ci sono più passaggi in un processo, mostra ogni passaggio.
**Esempio:**
-Mostrare ogni passaggio previsto in una transazione aiuta gli utenti a sapere a che punto si trovano nel processo. Icone appropriate fanno sapere all'utente lo stato delle sue azioni.
+Mostrare ogni passaggio coinvolto in una transazione aiuta gli utenti a sapere a che punto del processo si trovano. Icone appropriate fanno conoscere all'utente lo stato delle sue azioni.
-
+
-### 2. Sicurezza e fiducia sono integrati {#security-and-trust-are-backed-in}
+### 2. Sicurezza e fiducia sono integrate {#security-and-trust-are-backed-in}
-La sicurezza dovrebbe essere prioritaria e questo deve essere enfatizzato per l'utente.
-Le persone tengono moltissimo ai loro dati. La sicurezza è spesso una preoccupazione primaria per gli utenti e quindi deve essere considerata a tutti i livelli di progettazione. Si dovrebbe sempre cercare di guadagnare la fiducia dei propri utenti, ma il modo in cui lo si fa può avere implicazioni diverse su applicazioni differenti. Non dovrebbe essere inclusa in un secondo momento, ma dovrebbe essere progettata consapevolmente in ogni fase. Costruire la fiducia attraverso l'esperienza dell'utente, anche attraverso canali social e documentazione, oltre alla UI finale. Aspetti come il livello di decentralizzazione, lo stato multi-firma del patrimonio e se il team è doxato, avranno un effetto sulla fiducia dell'utente
+La sicurezza dovrebbe avere la priorità, e questo dovrebbe essere enfatizzato per l'utente.
+Le persone tengono molto ai propri dati. La sicurezza è spesso una preoccupazione primaria per gli utenti, quindi dovrebbe essere considerata a tutti i livelli della progettazione. Dovresti sempre cercare di guadagnare la fiducia dei tuoi utenti, ma il modo in cui lo fai può significare cose diverse su app diverse. Non dovrebbe essere un ripensamento, ma dovrebbe essere progettato consapevolmente in ogni sua parte. Costruisci la fiducia attraverso l'intera esperienza utente, inclusi i canali social e la documentazione, così come l'interfaccia utente finale. Cose come il livello di decentralizzazione, lo stato multifirma della tesoreria e se il team è pubblico (doxxed), influenzano tutte la fiducia degli utenti.
**Suggerimenti:**
+- Elenca con orgoglio i tuoi audit
+- Ottieni più audit
+- Pubblicizza qualsiasi funzionalità di sicurezza che hai progettato
+- Evidenzia i possibili rischi, incluse le integrazioni sottostanti
+- Comunica la complessità delle strategie
+- Considera i problemi non legati all'interfaccia utente che potrebbero influenzare la percezione di sicurezza dei tuoi utenti
-- Elencare fieramente i propri controlli
-- Ottenere molteplici controlli
-- Pubblicizzare tutte le funzionalità di sicurezza progettate
-- Evidenziare i possibili rischi, comprese le integrazioni sottostanti
-- Comunicare la complessità delle strategie
-- Considerare le problematiche non-UI che potrebbero influire sulla percezione della sicurezza da parte degli utenti
+**Esempio:**
+Includi i tuoi audit nel piè di pagina, in dimensioni ben visibili.
-**Esempio:**
-Includere i propri controlli a piè pagina, ad una dimensione ben visibile.
+
-
+### 3. Le informazioni più importanti sono ovvie {#the-most-important-info-is-obvious}
-### 3. L'informazione più importante è ovvia {#the-most-important-info-is-obvious}
-
-Per sistemi complessi, mostrare solo i dati più rilevanti. Determinare ciò che è più importante e poi darvi priorità nella visualizzazione.
-Troppe informazioni diventano opprimenti e gli utenti tipicamente si basano su una sola informazione quando devono prendere una decisione. Nella DeFi questa sarà probabilmente l'APR sulle app di rendimento e il LTV sulle app di prestito.
+Per i sistemi complessi, mostra solo i dati più rilevanti. Determina cosa è più importante e dai priorità alla sua visualizzazione.
+Troppe informazioni sono opprimenti e gli utenti in genere si ancorano a una singola informazione quando prendono decisioni. Nella DeFi, questo sarà probabilmente l'APR sulle app di rendimento e l'LTV sulle app di prestito.
**Suggerimenti:**
+- La ricerca sugli utenti scoprirà la metrica più importante
+- Rendi grandi le informazioni chiave e piccoli e discreti gli altri dettagli
+- Le persone non leggono, scorrono; assicurati che il tuo design sia facilmente scansionabile visivamente
-- La ricerca sugli utenti farà chiarezza sulle metriche più importanti
-- Mostrare le informazioni chiave in grande e gli altri dettagli in piccolo e in maniera discreta
-- Le persone non leggono, scansionano; assicurati che il tuo design sia scansionabile
-
-**Esempio:** I grandi token in colori pieni sono facili da trovare quando si scansiona. L'APR è grande ed evidenziato in un colore che risalta.
+**Esempio:** I token grandi a colori sono facili da trovare durante lo scorrimento visivo. L'APR è grande ed evidenziato in un colore d'accento.
### 4. Terminologia chiara {#clear-terminology}
La terminologia dovrebbe essere comprensibile e appropriata.
-Il gergo tecnico può essere un blocco notevole perché richiede la costruzione di un modello mentale completamente nuovo. Gli utenti non sono in grado di correlare il design alle parole, alle frasi e ai concetti che già conoscono. Tutto sembra confuso e poco familiare e c'è una curva di apprendimento ripida prima che possano anche tentare di utilizzarlo. Un utente potrebbe approcciarsi alla DeFi con l'intento di risparmiare un po' di denaro e quello che trova è: minare, farmare, staking, emissioni, tangenti, caveau, locker, veToken, vesting, epoche, algoritmi decentralizzati, liquidità di proprietà del protocollo…
-Provare ad utilizzare termini semplici che possano essere compresi da un ampio gruppo di persone. Non inventarsi un nuovo termine di sana pianta per il proprio progetto.
+Il gergo tecnico può essere un enorme ostacolo, perché richiede la costruzione di un modello mentale completamente nuovo. Gli utenti non sono in grado di mettere in relazione il design con parole, frasi e concetti che già conoscono. Tutto sembra confuso e non familiare, e c'è una ripida curva di apprendimento prima ancora che possano tentare di usarlo. Un utente potrebbe avvicinarsi alla DeFi volendo risparmiare un po' di denaro, e quello che trova è: Mining, farming, staking, emissioni, tangenti (bribes), caveau (vaults), armadietti (lockers), veToken, maturazione (vesting), epoche, algoritmi decentralizzati, liquidità di proprietà del protocollo...
+Cerca di usare termini semplici che saranno compresi dal gruppo più ampio di persone. Non inventare termini completamente nuovi solo per il tuo progetto.
**Suggerimenti:**
-
-- Utilizzare terminologia semplice e coerente
-- Utilizzare il linguaggio esistente il più possibile
-- Non inventarsi dei termini nuovi
-- Seguire le conversazioni come appaiono
-- Educare gli utenti il più possibile
+- Usa una terminologia semplice e coerente
+- Usa il più possibile il linguaggio esistente
+- Non inventare i tuoi termini
+- Segui le convenzioni man mano che appaiono
+- Educa gli utenti il più possibile
**Esempio:**
-“Le tue ricompense” è un termine neutrale e ampiamente comprensibile, non una parola nuova inventata per questo progetto. Le ricompense sono denominate in USD per riflettere i modelli mentali del mondo reale, anche quando le ricompense stesse sono in un altro token.
+"Le tue ricompense" è un termine neutro e ampiamente compreso; non una nuova parola inventata per questo progetto. Le ricompense sono denominate in USD per corrispondere ai modelli mentali del mondo reale, anche se le ricompense stesse sono in un altro token.
-
+
-### 5. Le azioni sono le più brevi possibili {#actions-are-as-short-as-possible}
+### 5. Le azioni sono il più brevi possibile {#actions-are-as-short-as-possible}
-Velocizzare le interazioni dell'utente raggruppando le azioni secondarie.
-Questo può essere fatto anche a livello di contratto intelligente o della UI. L'utente non dovrebbe essere obbligato a muoversi da una parte all'altra del sistema – o lasciare completamente il sistema – per completare delle azioni comuni.
+Velocizza le interazioni dell'utente raggruppando le sotto-azioni.
+Questo può essere fatto a livello di contratto intelligente, così come nell'interfaccia utente. L'utente non dovrebbe doversi spostare da una parte all'altra del sistema – o lasciare del tutto il sistema – per completare un'azione comune.
**Suggerimenti:**
+- Combina "Approva" con altre azioni dove possibile
+- Raggruppa i passaggi di firma il più vicino possibile
-- Combinare "Approva" con altre azioni quando possibile
-- Raggruppa i passaggi che richiedono una firma il più vicino possibile
-
-**Esempio:** Combinare "aggiungi liquidità" e "metti in staking" è un semplice esempio di un passaggio veloce che fa risparmiare all'utente sia tempo che gas.
+**Esempio:** Combinare "aggiungi liquidità" e "stake" è un semplice esempio di acceleratore che fa risparmiare all'utente sia tempo che gas.
-
+
### 6. Le connessioni di rete sono visibili e flessibili {#network-connections-are-visible-and-flexible}
-Informare l'utente della rete alla quale è connesso e fornire scorciatoie chiare per cambiare rete.
-Questo è particolarmente importante nelle applicazioni multi-catena. Le funzioni principali dell'applicazione dovrebbero essere sempre visibili mentre si è disconnessi o connessi a reti non supportate.
+Informa l'utente su quale rete è connesso e fornisci scorciatoie chiare per cambiare rete.
+Questo è particolarmente importante sulle app multi-catena. Le funzioni principali dell'app dovrebbero essere ancora visibili mentre si è disconnessi o connessi a una rete non supportata.
**Suggerimenti:**
+- Mostra il più possibile dell'app mentre si è disconnessi
+- Mostra a quale rete l'utente è attualmente connesso
+- Non costringere l'utente ad andare sul portafoglio per cambiare rete
+- Se l'app richiede all'utente di cambiare rete, richiedi l'azione dalla chiamata all'azione (CTA) principale
+- Se l'app contiene mercati o caveau per più reti, indica chiaramente quale set l'utente sta attualmente guardando
-- Visualizzare il più possibile dell'applicazione anche quando si è disconnessi
-- Mostrare la rete alla quale l'utente è collegato in quel momento
-- Non costringere l'utente ad andare nel portafoglio per poter cambiare rete
-- Se l'applicazione richiede all'utente di cambiare rete, richiediere l'azione dalla chiamata all'azione principale
-- Se l'applicazione contiene mercati o casseforti di più reti, dichiarare in maniera chiara quale set l'utente ha davanti in quel momento
-
-**Esempio:** Mostrare all'utente a quale rete è collegato e permettergli di cambiarla nella barra dell'applicazione.
+**Esempio:** Mostra all'utente a quale rete è connesso e consentigli di cambiarla, nella barra dell'app.
-### 7. Controllare dall'applicazione non dal portafoglio {#control-from-the-app-not-the-wallet}
+### 7. Controllo dall'app, non dal portafoglio {#control-from-the-app-not-the-wallet}
-La UI dovrebbe dire all'utente tutto ciò che deve sapere e dargli il controllo su tutto quello che deve fare.
-Nel Web3 ci sono azioni che si fanno nella UI e azioni che si fanno nel portafoglio. Generalmente si inizia con un'azione nella UI e poi si conferma nel portafoglio. Gli utenti potrebbe sentirsi a disagio se queste due parti non sono attentamente integrate.
+L'interfaccia utente dovrebbe dire all'utente tutto ciò che ha bisogno di sapere e dargli il controllo su tutto ciò che deve fare.
+Nel Web3, ci sono azioni che intraprendi nell'interfaccia utente e azioni che intraprendi nel portafoglio. Generalmente, avvii un'azione nell'interfaccia utente e poi la confermi nel portafoglio. Gli utenti possono sentirsi a disagio se questi due filoni non sono integrati con attenzione.
**Suggerimenti:**
+- Comunica lo stato del sistema tramite feedback nell'interfaccia utente
+- Tieni un registro della loro cronologia
+- Fornisci collegamenti agli esploratori di blocchi per le vecchie transazioni
+- Fornisci scorciatoie per cambiare rete.
-- Comunicare lo stato del sistema attraverso un feedback nella UI
-- Tenere un registro dello storico
-- Fornire i link agli esploratori di blocchi per le vecchie transazioni
-- Fornire scorciatoie per cambiare rete.
-
-**Esempio:** Un contenitore discreto mostra all'utente quali token rilevanti ha nel proprio portafoglio e la CTA principale fornisce una scorciatoia per cambiare rete.
+**Esempio:** Un contenitore discreto mostra all'utente quali token rilevanti ha nel proprio portafoglio, e la CTA principale fornisce una scorciatoia per cambiare la rete.
-
+
\ No newline at end of file
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 688fd7cefd5..0686144b6fd 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
@@ -1,90 +1,87 @@
---
-title: Progettazione e UX nel Web3
-description: Introduzione alla progettazione e alla ricerca di UX nello spazio web3 e in Ethereum
+title: Design e UX nel web3
+description: Introduzione al design e alla ricerca UX nello spazio web3 e in Ethereum
lang: it
---
-Sei nuovo alla progettazione con Ethereum? Questo è il posto giusto per te. La community di Ethereum ha scritto le risorse per introdurti alle basi della progettazione e della ricerca web3. Imparerai i concetti fondamentali che potrebbero differire da altri progetti di applicazioni con cui hai familiarità.
+Sei nuovo nel design con Ethereum? Questo è il posto giusto per te. La community di Ethereum ha scritto delle risorse per introdurti alle basi del design e della ricerca nel web3. Imparerai i concetti fondamentali che potrebbero differire da altri design di app con cui hai familiarità.
-Hai prima bisogno di una conoscenza più di base del web3? Dai un'occhiata al [**Learn Hub**](/learn/).
+Hai prima bisogno di una comprensione più basilare del web3? Dai un'occhiata all'[**Hub di apprendimento**](/learn/).
-## Inizia con la ricerca utente {#start-with-user-research}
+## Inizia con la ricerca sugli utenti {#start-with-user-research}
-La progettazione efficace va oltre la creazione di interfacce utente accattivanti a livello visivo. Si tratta di comprendere a fondo i bisogni, gli obiettivi e i fattori trainanti dell'utente. Pertanto, consigliamo fortemente che tutti i progettisti adottino un processo di progettazione come il [**processo del doppio diamante**](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)), per assicurare che il loro lavoro sia consapevole e intenzionale.
+Un design efficace va oltre la creazione di interfacce utente visivamente accattivanti. Implica l'acquisizione di una profonda comprensione delle esigenze, degli obiettivi e dei fattori trainanti dell'utente. Pertanto, raccomandiamo vivamente a tutti i designer di adottare un processo di design, come il [**processo del doppio diamante**](), per garantire che il loro lavoro sia ponderato e intenzionale.
-- [Il Web3 necessita di più ricercatori e progettisti di UX](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - Una panoramica dell'attuale maturità della progettazione
-- [Una guida semplice alla ricerca UX](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - Una semplice guida su come fare ricerca
-- [Come affrontare le decisioni di UX nel Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - Una breve panoramica di ricerca quantitativa e qualitativa e le differenze tra queste due (video, 6 minuti)
-- [Essere un ricercatore ux nel web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Un punto di vista personale su cosa significhi essere un ricercatore UX nel web3
+- [Il Web3 ha bisogno di più Ricercatori e Designer UX](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - Una panoramica dell'attuale maturità del design
+- [Una guida semplice alla Ricerca UX nel web3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - Guida semplice su come fare ricerca
+- [Come affrontare le decisioni UX nel Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - Una breve panoramica della ricerca quantitativa e qualitativa e le differenze tra le due (video, 6 min)
+- [Essere un ricercatore UX nel web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Una visione personale su come sia essere un ricercatore UX nel web3
## Studi di ricerca nel web3 {#research-in-web3}
-Questo è un elenco curato di ricerche utente fatte nel web3 che potrebbero esserti utili nelle decisioni di progettazione e prodotto o potrebbero inspirarti a condurre nuovi studi.
-
-| Area di interesse | Nome |
-|:--------------------------------------------------------------------- |:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Integrazione delle criptovalute | [WalletConnect Pulse 2024: Opinione e utilizzo del cripto-consumatore](https://www.businesswire.com/news/home/20240229407983/en/WalletConnect-Uncovers-Major-Crypto-Consumer-Findings-in-Inaugural-Pulse-Report) |
-| Integrazione delle criptovalute | [CRADL: la UX nelle criptovalute](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) |
-| Integrazione delle criptovalute | [CRADL: ingresso nelle criptovalute](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) |
-| Integrazione delle criptovalute | [Report sulla UX Bitcoin](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) |
-| Integrazione delle criptovalute | [ConSensys: lo stato della percezione del Web3 nel mondo nel 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) |
-| Integrazione delle criptovalute | [NEAR: accelerare il percorso di adozione](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) |
-| Staking | [OpenUX: UX dell'operatore del nodo in pool di Rocket](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) |
-| Staking | [Staking: Tendenze fondamentali, risultati e previsioni - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) |
-| Staking | [Staking a Più App](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) |
-| OAD | [Aggiornamento 2022 sulla ricerca delle DAO: di cosa hanno bisogno i costruttori di DAO?](https://blog.aragon.org/2022-dao-research-update/) |
-| DeFi | [Gruppi di copertura](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) |
-| DeFi | [ConSensys: rapporto di ricerca sugli utenti DeFI 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) |
-| Metaverso | [Metaverso: report di ricerca sugli utenti](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) |
-| Metaverso | [Andare ad un Safari: ricerca sugli utenti nel Metaverso](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (video, 27 minuti) |
-| Statistiche dell'UX di Ethereum.org | [Pannello di controllo del sondaggio sull'utilizzabilità e soddisfazione degli utenti - Ethereum.org](https://lookerstudio.google.com/reporting/0a189a7c-a890-40db-a5c6-009db52c81c9) |
-
-## Progettazione per il web3 {#design-for-web3}
-
-- [Web3 UX Design Handbook](https://web3ux.design/) - Guida pratica alla progettazione di applicazioni Web3
-- [Principi di progettazione Web3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - Un framework di regole di UX per le dapp basate su blockchain
-- [Principi di progettazione blockchain](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - Lezioni apprese dal team di progettazione blockchain di IBM
-- [Modello di progettazione Web3](https://www.web3designpatterns.io/)- Una libreria curata di modelli di progettazione di prodotti Web3 reali
-- [W3design.io](https://w3design.io/) - Una libreria curata di flussi di UI di vari progetti nell'ecosistema
-- [Neueux.com](https://neueux.com/apps) - Una libreria UI di flussi di utenti con diversi opzioni di filtro
-- [Web3's Usability Crisis: What You NEED to Know!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - Una tavola rotonda sulle insidie della creazione di progetti incentrati sugli sviluppatori (video, 34 minuti)
-
-## Primi passi {#getting-started}
-
-- [Euristiche per il Web3](/developers/docs/design-and-ux/heuristics-for-web3/): 7 euristiche per la progettazione dell'interfaccia di Web3
-- [Migliori pratiche di progettazione delle DEX](/developers/docs/design-and-ux/dex-design-best-practice/): Una guida alla progettazione di borse decentralizzate
-
-## Casi di studio di progettazione Web3 {#design-case-studies}
-
-- [Deep Work Studio](https://deepwork.studio/case-studies/)
-- [Manuale di UX cripto](https://www.cryptouxhandbook.com/)
+Questa è una lista curata di ricerche sugli utenti effettuate nel web3 che possono aiutare nelle decisioni di design e di prodotto o fungere da ispirazione per condurre il proprio studio.
+
+| Area di interesse | Nome |
+| :------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Onboarding crypto | [The Reown Pulse 2024: Crypto Consumer Sentiment & Usage](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) |
+| Onboarding crypto | [CRADL: UX in Cryptocurrency](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) |
+| Onboarding crypto | [CRADL: Onboarding to Cryptocurrency](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) |
+| Onboarding crypto | [Bitcoin UX report](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) |
+| Onboarding crypto | [ConSensys: The State of Web3 perception around the world 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) |
+| Onboarding crypto | [NEAR: Accelerating the journey towards adoption](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) |
+| Staking | [OpenUX: Rocket Pool Node Operator UX](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) |
+| Staking | [Staking: Key trends, takeaways, and predictions - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) |
+| Staking | [Multi App Staking]() |
+| DAO | [2022 DAO Research Update: What do DAO Builders Need?](https://blog.aragon.org/2022-dao-research-update/) |
+| DeFi | [Coverage pools](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) |
+| DeFi | [ConSensys: DeFi User Research Report 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) |
+| Metaverso | [Metaverse: User Research Report](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) |
+| Metaverso | [Going on Safari: Researching Users in the Metaverse](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (video, 27 min) |
+
+## Design per il web3 {#design-for-web3}
+
+- [Web3 Design Playbook](https://learnweb3.design/) - Una raccolta completa di framework e note sui principi UX del Web3, pattern DeFi, design della governance, UX dei portafogli e pensiero a livello di protocollo per designer e fondatori
+- [Web3 UX Design Handbook](https://web3ux.design/) - Guida pratica alla progettazione di app Web3
+- [Web3 Design Principles](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - Un framework di regole UX per dApp basate su blockchain
+- [Blockchain Design Principles](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - Lezioni apprese dal team di design blockchain di IBM
+- [Neueux.com](https://neueux.com/apps) - Libreria UI di flussi utente con diverse opzioni di filtraggio
+- [Web3's Usability Crisis: What You NEED to Know!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - Una tavola rotonda sulle insidie della costruzione di progetti incentrati sugli sviluppatori (video, 34 min)
+
+## Per Iniziare {#getting-started}
+
+- [Euristiche per il Web3](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 euristiche per il design delle interfacce Web3
+- [Migliori Pratiche di Design per DEX](/developers/docs/design-and-ux/dex-design-best-practice/) - Una guida alla progettazione di exchange decentralizzati
+
+## Casi di Studio di Design nel Web3 {#design-case-studies}
+
+- [Deep Work Studio](https://www.deepwork.studio/case-studies)
- [Vendere un NFT su OpenSea](https://builtformars.com/case-studies/opensea)
-- [UX del portafoglio: un'analisi di come i portafogli devono cambiare](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (video, 20 min)
+- [Analisi della UX dei portafogli: come devono cambiare i portafogli](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (video, 20 min)
-## Ricompense di progettazione {#bounties}
+## Taglie di Design {#bounties}
- [Dework](https://app.dework.xyz/bounties)
-- [Hackathon di Buildbox](https://app.buidlbox.io/)
-- [Hackathon di ETHGlobal](https://ethglobal.com/)
+- [Buildbox hackathons](https://app.buidlbox.io/)
+- [ETHGlobal hackathons](https://ethglobal.com/)
-## Progettazione di DAO e di community {#design-daos-and-communities}
+## DAO e community di design {#design-daos-and-communities}
-Partecipate ad organizzazioni professionali guidate dalla community o unitevi a gruppi di progettazione per discutere argomenti e tendenze legati a progetti e alla ricerca con altri membri.
+Partecipa a organizzazioni professionali guidate dalla community o unisciti a gruppi di design per discutere di argomenti e tendenze legati al design e alla ricerca con altri membri.
- [Vectordao.com](https://vectordao.com/)
- [Deepwork.studio](https://www.deepwork.studio/)
-- [Designer-dao.xyz](https://www.designer-dao.xyz/)
- [We3.co](https://we3.co/)
- [Openux.xyz](https://openux.xyz/)
-## Sistemi di progettazione {#design-systems}
+## Design System e altre risorse di design {#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)
-- [Finity, un sistema di progettazione di Polygon](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma)
-- [Sistema di progettazione Kleros](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma)
-- [Sistema di progettazione Sicuro](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma)
-- [Sistema di progettazione ENS](https://thorin.ens.domains/)
-- [Sistema di progettazione Mirror](https://degen-xyz.vercel.app/)
+- [Optimism Design](https://www.figma.com/@optimism) (Figma)
+- [Ethereum.org Design system](https://www.figma.com/@ethdotorg) (Figma)
+- [Finity, un design system di Polygon](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma)
+- [Kleros Design System](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma)
+- [Safe Design System](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma)
+- [ENS Design system](https://thorin.ens.domains/)
+- [Mirror Design System](https://degen-xyz.vercel.app/)
-**Gli articoli e i progetti elencati in questa pagina non costituiscono sponsorizzazioni ufficiali** e sono forniti solo a scopo informativo. Aggiungiamo i collegamenti a questa pagina in base ai criteri della nostra [politica di inserimento](/contributing/design/adding-design-resources). Se vorresti che aggiungessimo un progetto/articolo, modifica questa pagina su [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md).
+**Gli articoli e i progetti elencati in questa pagina non sono approvazioni ufficiali** e sono forniti solo a scopo informativo.
+Aggiungiamo link a questa pagina in base ai criteri della nostra [politica di inserimento](/contributing/design/adding-design-resources). Se desideri che aggiungiamo un progetto/articolo, modifica questa pagina su [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/development-networks/index.md b/public/content/translations/it/developers/docs/development-networks/index.md
index 2d4dde81e5a..1aa1d23e7d1 100644
--- a/public/content/translations/it/developers/docs/development-networks/index.md
+++ b/public/content/translations/it/developers/docs/development-networks/index.md
@@ -1,73 +1,75 @@
---
title: Reti di sviluppo
-description: Panoramica delle reti di sviluppo e degli strumenti disponibili per creare applicazioni Ethereum.
+description: Una panoramica delle reti di sviluppo e degli strumenti disponibili per aiutare a creare applicazioni su Ethereum.
lang: it
---
-Creando un'applicazione di Ethereum con i contratti intelligenti, vorrai eseguirlo su una rete locale per vedere come funziona, prima di distribuirla.
+Quando si crea un'applicazione [Ethereum](/) con contratti intelligenti, è consigliabile eseguirla su una rete locale per vederne il funzionamento prima di distribuirla.
-Come è possibile eseguire un server locale sul computer per lo sviluppo web, allo stesso modo è possibile usare una rete di sviluppo per creare un'istanza di blockchain locale per testare una dapp. Queste reti di sviluppo Ethereum offrono funzionalità che permettono un'iterazione molto più veloce rispetto a una rete di prova pubblica (ad esempio, non è necessario acquisire ETH da un faucet di una rete di prova).
+Similmente a come si potrebbe eseguire un server locale sul proprio computer per lo sviluppo web, è possibile utilizzare una rete di sviluppo per creare un'istanza locale della blockchain per testare la propria dApp. Queste reti di sviluppo di Ethereum forniscono funzionalità che consentono un'iterazione molto più rapida rispetto a una rete di test pubblica (ad esempio, non è necessario preoccuparsi di acquisire ETH da un rubinetto della rete di test).
## Prerequisiti {#prerequisites}
-È necessario conoscere le [basi dello stack Ethereum](/developers/docs/ethereum-stack/) e delle [reti Ethereum](/developers/docs/networks/) prima di iniziare ad utilizzare le reti di sviluppo.
+Dovresti comprendere le [basi dello stack di Ethereum](/developers/docs/ethereum-stack/) e le [reti di Ethereum](/developers/docs/networks/) prima di immergerti nelle reti di sviluppo.
## Cos'è una rete di sviluppo? {#what-is-a-development-network}
-Si tratta essenzialmente di client Ethereum (implementazioni di Ethereum) progettate in modo specifico per lo sviluppo locale.
+Le reti di sviluppo sono essenzialmente client di Ethereum (implementazioni di Ethereum) progettati specificamente per lo sviluppo locale.
-**Perché allora non eseguire semplicemente un nodo Ethereum locale?**
+**Perché non eseguire semplicemente un nodo standard di Ethereum localmente?**
-_Potresti_ [eseguire un nodo](/developers/docs/nodes-and-clients/#running-your-own-node), ma poiché le reti di sviluppo sono costruite per lo sviluppo, spesso includono funzionalità pratiche come:
+_Potresti_ [eseguire un nodo](/developers/docs/nodes-and-clients/#running-your-own-node) ma, poiché le reti di sviluppo sono create appositamente per lo sviluppo, spesso sono dotate di comode funzionalità come:
-- Inserimento deterministico dei dati nella tua blockchain locale (es. conti con saldi di ETH)
-- Produzione istantanea di blocchi a ogni transazione ricevuta, in ordine e senza ritardi
-- Funzionalità di debugging e registrazione avanzate
+- Popolamento deterministico della blockchain locale con dati (es. account con saldi in ETH)
+- Produzione istantanea di blocchi con ogni transazione che riceve, in ordine e senza ritardi
+- Funzionalità avanzate di debug e registrazione (logging)
## Strumenti disponibili {#available-projects}
-**Nota**: la maggior parte dei [framework di sviluppo](/developers/docs/frameworks/) include una rete di sviluppo incorporata. Raccomandiamo di iniziare con un framework per [impostare l'ambiente di sviluppo locale](/developers/local-environment/).
+**Nota**: La maggior parte dei [framework di sviluppo](/developers/docs/frameworks/) include una rete di sviluppo integrata. Consigliamo di iniziare con un framework per [configurare il tuo ambiente di sviluppo locale](/developers/local-environment/).
-### Rete Hardhat {#hardhat-network}
+### Hardhat Network {#hardhat-network}
-Rete Ethereum locale progettata per lo sviluppo. Permette di distribuire contratti, eseguire test e il debug del codice.
+Una rete Ethereum locale progettata per lo sviluppo. Ti consente di distribuire i tuoi contratti, eseguire i tuoi test ed effettuare il debug del tuo codice.
-La rete Hardhat è incorporata in Hardhat, un ambiente di sviluppo Ethereum professionale.
+Hardhat Network è integrata in Hardhat, un ambiente di sviluppo Ethereum per professionisti.
-- [Sito Web](https://hardhat.org/)
-- [GitHub](https://github.com/nomiclabs/hardhat)
+- [Sito web](https://hardhat.org/)
+- [GitHub](https://github.com/NomicFoundation/hardhat)
-### Beacon Chain Locali {#local-beacon-chains}
+### Beacon chain locali {#local-beacon-chains}
-Alcuni client del consenso sono dotati di strumenti integrati per avviare Beacon Chain locali per scopi di test. Sono disponibili le istruzioni per Lighthouse, Nimbus e Lodestar:
+Alcuni client di consenso dispongono di strumenti integrati per avviare beacon chain locali a scopo di test. Sono disponibili le istruzioni per Lighthouse, Nimbus e Lodestar:
-- [Testnet locale usando Lodestar](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/)
-- [Testnet locale usando Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
+- [Rete di test locale usando Lodestar](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/)
+- [Rete di test locale usando Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets)
-### Catene di prova pubbliche di Ethereum {#public-beacon-testchains}
+### Catene di test pubbliche di Ethereum {#public-beacon-testchains}
-Esistono anche due implementazioni di prova pubbliche e mantenute di Ethereum: Sepolia e Hoodi. Sepolia è la rete di prova standard consigliata per lo sviluppo di applicazioni, con un insieme di validatori chiuso per una sincronizzazione rapida. Hoodi è una rete di prova per la validazione e lo staking, che utilizza un insieme di validatori aperto e permette potenzialmente a chiunque di validare.
+Esistono anche due implementazioni di test pubbliche mantenute di Ethereum: Sepolia e Hoodi. La rete di test consigliata con supporto a lungo termine è Hoodi, su cui chiunque è libero di validare. Sepolia utilizza un set di validatori autorizzati, il che significa che non c'è accesso generale per nuovi validatori su questa rete di test.
-- [Launchpad di staking di Hoodi](https://hoodi.launchpad.ethereum.org/en/)
-- [Sito Web di Sepolia](https://sepolia.dev/)
-- [Sito Web di Hoodi](https://hoodi.ethpandaops.io/)
+- [Launchpad di staking di Hoodi](https://hoodi.launchpad.ethereum.org/)
-### Pacchetto Ethereum di Kurtosis {#kurtosis}
+### Pacchetto Ethereum Kurtosis {#kurtosis}
-Kurtosis è un sistema di produzione per ambienti di prova multi-contenitore che consente agli sviluppatori di avviare localmente istanze riproducibili di reti blockchain.
+Kurtosis è un sistema di compilazione per ambienti di test multi-container che consente agli sviluppatori di avviare localmente istanze riproducibili di reti blockchain.
-Il pacchetto Kurtosis di Ethereum è utilizzabile per istanziare rapidamente una rete di prova di Ethereum parametrizzabile, altamente scalabile e privata, su Docker o Kubernetes. Il pacchetto supporta tutti i clienti principali dei Livelli d'Esecuzione (EL) e del Consenso (CL). Kurtosis gestisce comodamente tutte le mappature delle porte locali e le connessioni del servizio per una rete rappresentativa da utilizzare nei flussi di lavoro di convalida e test, relativamente all'infrastruttura principale di Ethereum.
+Il pacchetto Ethereum Kurtosis può essere utilizzato per istanziare rapidamente una rete di test di Ethereum parametrizzabile, altamente scalabile e privata su Docker o Kubernetes. Il pacchetto supporta tutti i principali client del livello di esecuzione (EL) e del livello di consenso (CL). Kurtosis gestisce in modo elegante tutte le mappature delle porte locali e le connessioni ai servizi per una rete rappresentativa da utilizzare nei flussi di lavoro di validazione e test relativi all'infrastruttura principale di Ethereum.
-- [Pacchetto rete Ethereum](https://github.com/kurtosis-tech/ethereum-package)
-- [Sito Web](https://www.kurtosis.com/)
+- [Pacchetto di rete Ethereum](https://github.com/kurtosis-tech/ethereum-package)
+- [Sito web](https://www.kurtosis.com/)
- [GitHub](https://github.com/kurtosis-tech/kurtosis)
- [Documentazione](https://docs.kurtosis.com/)
## Letture consigliate {#further-reading}
-_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
## Argomenti correlati {#related-topics}
-- [Quadri di sviluppo](/developers/docs/frameworks/)
-- [Configura un ambiente di sviluppo locale](/developers/local-environment/)
+- [Framework di sviluppo](/developers/docs/frameworks/)
+- [Configurare un ambiente di sviluppo locale](/developers/local-environment/)
+
+## Tutorial: Reti di sviluppo e ambienti di test su Ethereum {#tutorials}
+
+- [Sviluppare e testare dApp con una rete di test locale multi-client di Ethereum](/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/) _– Come avviare una rete di test locale multi-client di Ethereum con Kurtosis per lo sviluppo e il test di dApp._
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/ethereum-stack/index.md b/public/content/translations/it/developers/docs/ethereum-stack/index.md
index e1296df03d0..4dc7685fa37 100644
--- a/public/content/translations/it/developers/docs/ethereum-stack/index.md
+++ b/public/content/translations/it/developers/docs/ethereum-stack/index.md
@@ -1,61 +1,61 @@
---
title: Introduzione allo stack di Ethereum
-description: Percorso all'interno dei vari livelli dello stack di Ethereum che indica anche come interagiscono.
+description: Una panoramica dei diversi livelli dello stack di Ethereum e di come si integrano tra loro.
lang: it
---
-Come ogni stack di software, lo "stack di Ethereum" completo varia da progetto a progetto in base ai propri obiettivi.
+Come per qualsiasi stack software, lo "stack di Ethereum" completo varierà da progetto a progetto a seconda dei tuoi obiettivi.
-Sono comunque disponibili tecnologie base di Ethereum che aiutano a fornire un modello mentale di come le applicazioni software interagiscono con la blockchain Ethereum. Comprendere i livelli dello stack aiuterà anche a comprendere i molti modi in cui Ethereum può essere integrato all'interno di progetti software.
+Ci sono, tuttavia, componenti principali di Ethereum che aiutano a fornire un modello mentale di come le applicazioni software interagiscono con la blockchain di Ethereum. Comprendere i livelli dello stack ti aiuterà a capire i diversi modi in cui Ethereum può essere integrato nei progetti software.
-## Livello 1: macchina virtuale Ethereum {#ethereum-virtual-machine}
+## Livello 1: Macchina Virtuale di Ethereum {#ethereum-virtual-machine}
-La [Macchina Virtuale di Ethereum (EVM)](/developers/docs/evm/) è l'ambiente di esecuzione per i contratti intelligenti su Ethereum. Tutti i contratti intelligenti e i cambiamenti di stato sulle blockchain di Ethereum sono eseguiti dalle [transazioni](/developers/docs/transactions/). La EVM gestisce l'elaborazione di tutte le transazioni sulla rete Ethereum.
+La [Macchina Virtuale di Ethereum (EVM)](/developers/docs/evm/) è l'ambiente di esecuzione per i contratti intelligenti su Ethereum. Tutti i contratti intelligenti e le modifiche di stato sulla blockchain di Ethereum sono eseguiti tramite [transazioni](/developers/docs/transactions/). L'EVM gestisce tutta l'elaborazione delle transazioni sulla rete di Ethereum.
-Come avviene con ogni macchina virtuale, la EVM crea un livello di astrazione fra il codice in esecuzione e la macchina che esegue tale codice (il nodo Ethereum). Al momento la EVM è in esecuzione su migliaia di nodi distribuiti in tutto il mondo.
+Come per qualsiasi macchina virtuale, l'EVM crea un livello di astrazione tra il codice in esecuzione e la macchina esecutrice (un nodo di Ethereum). Attualmente, l'EVM è in esecuzione su migliaia di nodi distribuiti in tutto il mondo.
-La EVM utilizza un insieme di istruzioni opcode per eseguire attività specifiche. Questi (140) opcode (univoci) consentono all'EVM di essere [Turing-completa](https://en.wikipedia.org/wiki/Turing_completeness), cioè in grado di calcolare praticamente tutto, se sono presenti risorse sufficienti.
+Dietro le quinte, l'EVM utilizza un set di istruzioni opcode per eseguire compiti specifici. Questi opcode (140 unici) consentono all'EVM di essere [Turing-completa](https://en.wikipedia.org/wiki/Turing_completeness), il che significa che l'EVM è in grado di calcolare quasi tutto, date risorse sufficienti.
-A uno sviluppatore di dapp non serve conoscere a fondo la EVM, gli basta sapere che esiste e fa funzionare in modo affidabile tutte le applicazioni su Ethereum senza interruzioni.
+Come sviluppatore di dApp, non hai bisogno di sapere molto sull'EVM, se non che esiste e che alimenta in modo affidabile tutte le applicazioni su Ethereum senza tempi di inattività.
## Livello 2: Contratti intelligenti {#smart-contracts}
-I [contratti intelligenti](/developers/docs/smart-contracts/) sono i programmi eseguiti sulla blockchain di Ethereum.
+I [contratti intelligenti](/developers/docs/smart-contracts/) sono i programmi eseguibili che girano sulla blockchain di Ethereum.
-I contratti intelligenti sono scritti usando [linguaggi di programmazione](/developers/docs/smart-contracts/languages/) specifici, compilati al bytecode dell'EVM (istruzioni della macchina di basso livello, dette opcode).
+I contratti intelligenti sono scritti utilizzando specifici [linguaggi di programmazione](/developers/docs/smart-contracts/languages/) che vengono compilati in bytecode EVM (istruzioni macchina di basso livello chiamate opcode).
-Non solo i contratti intelligenti servono da librerie open source, ma sono essenzialmente servizi API aperti in continua esecuzione e non disattivabili. I contratti intelligenti forniscono funzioni pubbliche con cui gli utenti e le applicazioni ([dapp](/developers/docs/dapps/)) potrebbero interagire, senza necessitare di permessi. Qualsiasi applicazione potrebbe integrarsi con i contratti intelligenti distribuiti per comporre la funzionalità, come aggiungere [feed di dati](/developers/docs/oracles/) o supportare gli scambi di token. Inoltre, chiunque può distribuire nuovi contratti intelligenti a Ethereum per aggiungere funzionalità personalizzate che soddisfino le esigenze della loro applicazione.
+I contratti intelligenti non fungono solo da librerie open source, ma sono essenzialmente servizi API aperti sempre in esecuzione e che non possono essere disattivati. I contratti intelligenti forniscono funzioni pubbliche con cui gli utenti e le applicazioni ([dApp](/developers/docs/dapps/)) possono interagire, senza bisogno di permessi. Qualsiasi applicazione può integrarsi con i contratti intelligenti distribuiti per comporre funzionalità, come l'aggiunta di [feed di dati](/developers/docs/oracles/) o per supportare lo scambio di token. Inoltre, chiunque può distribuire nuovi contratti intelligenti su Ethereum al fine di aggiungere funzionalità personalizzate per soddisfare le esigenze della propria applicazione.
-Come sviluppatore di dapp, dovrvai scrivere i contratti intelligenti solo se desideri aggiungere funzionalità personalizzate alla blockchain di Ethereum. Potresti renderti conto di poter soddisfare gran parte o tutte le esigenze del tuo progetto, semplicemente integrando con contratti intelligenti esistenti, ad esempio, se desideri supportare pagamenti in stablecoin o consentire lo scambio decentralizzato di token.
+Come sviluppatore di dApp, dovrai scrivere contratti intelligenti solo se desideri aggiungere funzionalità personalizzate sulla blockchain di Ethereum. Potresti scoprire di poter soddisfare la maggior parte o tutte le esigenze del tuo progetto semplicemente integrandoti con i contratti intelligenti esistenti, ad esempio se desideri supportare i pagamenti in stablecoin o abilitare un exchange decentralizzato di token.
-## Livello 3: nodi Ethereum {#ethereum-nodes}
+## Livello 3: Nodi di Ethereum {#ethereum-nodes}
-Affinché un'applicazione interagisca con la blockchain di Ethereum, deve connettersi a un [nodo di Ethereum](/developers/docs/nodes-and-clients/). Connettersi a un nodo permette di leggere i dati della blockchain e/o inviare transazioni alla rete.
+Affinché un'applicazione possa interagire con la blockchain di Ethereum, deve connettersi a un [nodo di Ethereum](/developers/docs/nodes-and-clients/). Connettersi a un nodo ti consente di leggere i dati della blockchain e/o inviare transazioni alla rete.
-I nodi Ethereum sono computer che eseguono software, ovvero un client Ethereum. Un client è una implementazione di Ethereum che verifica tutte le transazioni presenti in un blocco, facendo in modo che la rete rimanga sicura e i dati siano accurati. **I nodi di Ethereum sono la blockchain di Ethereum**. Memorizzano in maniera collettiva lo stato della blockchain Ethereum e raggiungono il consenso sulle transazioni per modificare lo stato della blockchain.
+I nodi di Ethereum sono computer che eseguono un software: un client di Ethereum. Un client è un'implementazione di Ethereum che verifica tutte le transazioni in ogni blocco, mantenendo la rete sicura e i dati accurati. **I nodi di Ethereum sono la blockchain di Ethereum**. Essi memorizzano collettivamente lo stato della blockchain di Ethereum e raggiungono il consenso sulle transazioni per mutare lo stato della blockchain.
-Connettendo la tua applicazione a un nodo di Ethereum (tramite l'[API JSON-RPC](/developers/docs/apis/json-rpc/)), la tua applicazione può leggere i dati dalla blockchain (come i saldi dei conti degli utenti), nonché trasmettere le nuove transazioni alla rete (come trasferire ETH tra conti degli utenti o eseguire funzioni dei contratti intelligenti).
+Connettendo la tua applicazione a un nodo di Ethereum (tramite l'[API JSON-RPC](/developers/docs/apis/json-rpc/)), la tua applicazione è in grado di leggere i dati dalla blockchain (come i saldi degli account degli utenti) e di trasmettere nuove transazioni alla rete (come il trasferimento di ETH tra gli account degli utenti o l'esecuzione di funzioni dei contratti intelligenti).
-## Livello 4: API client Ethereum {#ethereum-client-apis}
+## Livello 4: API dei client di Ethereum {#ethereum-client-apis}
-Molte librerie (create e gestite dalla community open source di Ethereum) consentono alle applicazioni per gli utenti finali di connettersi e comunicare con la blockchain Ethereum.
+Molte librerie di utilità (create e mantenute dalla community open source di Ethereum) consentono alle tue applicazioni di connettersi e comunicare con la blockchain di Ethereum.
-Se un'applicazione per gli utenti è una Wweb app, è possibile decidere di installare tramite `npm install` un'[API JavaScript](/developers/docs/apis/javascript/) direttamente sul frontend. In alternativa, è possibile implementare questa funzionalità sul lato server, usando un'API [Python](/developers/docs/programming-languages/python/) o [Java](/developers/docs/programming-languages/java/).
+Se la tua applicazione rivolta all'utente è un'app web, potresti scegliere di eseguire `npm install` di un'[API JavaScript](/developers/docs/apis/javascript/) direttamente nel tuo frontend. O forse sceglierai di implementare questa funzionalità lato server, utilizzando un'API [Python](/developers/docs/programming-languages/python/) o [Java](/developers/docs/programming-languages/java/).
-Pur non essendo necessariamente parte dello stack, queste API eliminano gran parte della complessità necessaria per interagire direttamente con un nodo Ethereum. Assicurano inoltre funzioni di utilità (ad esempio la conversione da ETH ain Gwei) per fare in modo che gli sviluppatori dedichino meno tempo alle complessità dei client Ethereum e più tempo alle funzionalità specifiche dell'applicazione.
+Sebbene queste API non siano un pezzo necessario dello stack, astraggono gran parte della complessità dell'interazione diretta con un nodo di Ethereum. Forniscono anche funzioni di utilità (ad es. la conversione di ETH in Gwei) in modo che, come sviluppatore, tu possa dedicare meno tempo ad affrontare le complessità dei client di Ethereum e più tempo a concentrarti sulle funzionalità specifiche della tua applicazione.
-## Livello 5: applicazioni per gli utenti finali {#end-user-applications}
+## Livello 5: Applicazioni per l'utente finale {#end-user-applications}
-Al livello più alto dello stack ci sono le applicazioni rivolte agli utenti. Si tratta delle applicazioni standard utilizzate e create normalmente oggi, principalmente Web app ed applicazioni mobili.
+Al livello più alto dello stack ci sono le applicazioni rivolte all'utente. Queste sono le applicazioni standard che usi e crei regolarmente oggi: principalmente app web e mobili.
-Il modo di progettare queste interfacce utente rimane essenzialmente invariato. Spesso gli utenti non hanno bisogno di sapere che l'applicazione che stanno usando è stata creata usando una blockchain.
+Il modo in cui sviluppi queste interfacce utente rimane essenzialmente invariato. Spesso gli utenti non avranno bisogno di sapere che l'applicazione che stanno utilizzando è costruita usando una blockchain.
-## Vuoi scegliere il tuo stack ora? {#ready-to-choose-your-stack}
+## Pronto a scegliere il tuo stack? {#ready-to-choose-your-stack}
-Consulta la nostra guida per [configurare un ambiente di sviluppo locale](/developers/local-environment/) per un'applicazione Ethereum.
+Dai un'occhiata alla nostra guida per [configurare un ambiente di sviluppo locale](/developers/local-environment/) per la tua applicazione Ethereum.
## Letture consigliate {#further-reading}
-- [L'Architettura di un'applicazione Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
+- [L'architettura di un'applicazione Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_
-_Conosci una risorsa pubblica che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/evm/index.md b/public/content/translations/it/developers/docs/evm/index.md
index c1ae60e919f..5c89b6cb642 100644
--- a/public/content/translations/it/developers/docs/evm/index.md
+++ b/public/content/translations/it/developers/docs/evm/index.md
@@ -1,78 +1,93 @@
---
-title: Macchina virtuale Ethereum (EVM)
-description: Un'introduzione alla Macchina Virtuale di Ethereum e a come si relaziona allo stato, alle transazioni e ai contratti intelligenti.
+title: Macchina Virtuale di Ethereum (EVM)
+description: Un'introduzione alla macchina virtuale di Ethereum e a come si relaziona con lo stato, le transazioni e i contratti intelligenti.
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 codice in modo coerente e sicuro su tutti i nodi [Ethereum](/). I nodi eseguono l'EVM per eseguire i contratti intelligenti, utilizzando il "[gas](/developers/docs/gas/)" per misurare lo sforzo computazionale richiesto per le [operazioni](/developers/docs/evm/opcodes/), garantendo un'allocazione efficiente delle risorse e la sicurezza della rete.
## Prerequisiti {#prerequisites}
-Per comprendere l'EVM, è richiesta una conoscenza di base dei termini comuni dell'informatica, come ad esempio [byte](https://wikipedia.org/wiki/Byte), [memoria](https://wikipedia.org/wiki/Computer_memory) e [stack](https://wikipedia.org/wiki/Stack_(abstract_data_type)). Sarebbe inoltre utile esser a conoscenza dei concetti crittografici e della blockchain come le [funzioni di hash](https://wikipedia.org/wiki/Cryptographic_hash_function) e l'[albero di Merkle](https://wikipedia.org/wiki/Merkle_tree).
+Per comprendere l'EVM è necessaria una certa familiarità di base con la terminologia comune dell'informatica, come [byte](https://wikipedia.org/wiki/Byte), [memoria](https://wikipedia.org/wiki/Computer_memory) e [stack](). Sarebbe inoltre utile avere dimestichezza con i concetti di crittografia/blockchain come le [funzioni di hash](https://wikipedia.org/wiki/Cryptographic_hash_function) e l'[albero di Merkle](https://wikipedia.org/wiki/Merkle_tree).
-## Dal libro mastro alla macchina a stati {#from-ledger-to-state-machine}
+## Dal registro alla macchina a stati {#from-ledger-to-state-machine}
-Per descrivere blockchain come Bitcoin, viene spesso utilizzata l'analogia con un "libro mastro distribuito", che permette l'esistenza di una valuta decentralizzata utilizzando strumenti base della crittografia. Il libro mastro mantiene un registro delle attività che deve aderire a una serie di regole che governano ciò che qualcuno può e non può fare per modificarlo. Ad esempio, un indirizzo Bitcoin non può spendere più Bitcoin di quanti ne abbia ricevuti in precedenza. Queste regole sono alla base di tutte le transazioni su Bitcoin e di molte altre blockchain.
+L'analogia di un "registro distribuito" è spesso usata per descrivere blockchain come Bitcoin, che abilitano una valuta decentralizzata utilizzando strumenti fondamentali di crittografia. Il registro mantiene uno storico delle attività che deve aderire a un insieme di regole che governano ciò che qualcuno può e non può fare per modificare il registro. Ad esempio, un indirizzo Bitcoin non può spendere più Bitcoin di quanti ne abbia ricevuti in precedenza. Queste regole sono alla base di tutte le transazioni su Bitcoin e su molte altre blockchain.
-Mentre Ethereum ha la propria criptovaluta nativa (Ether) che segue quasi esattamente le stesse regole intuitive, consente anche una funzione molto più potente: i [contratti intelligenti](/developers/docs/smart-contracts/). Per questa caratteristica più complessa, è necessaria un'analogia più complessa. Invece di essere un libro mastro distribuito, Ethereum è una [macchina di stato distribuita](https://wikipedia.org/wiki/Finite-state_machine). Lo stato di Ethereum è una grande struttura di dati che contiene non solo tutti i conti e i saldi, ma uno _stato della macchina_, che può cambiare da blocco a blocco secondo una serie predefinita di regole e che può eseguire il codice arbitrario della macchina. Le regole specifiche di cambio stato da blocco a blocco sono definite dall'EVM.
+Sebbene Ethereum abbia la propria criptovaluta nativa (ether) che segue quasi esattamente le stesse regole intuitive, abilita anche una funzione molto più potente: i [contratti intelligenti](/developers/docs/smart-contracts/). Per questa funzionalità più complessa, è necessaria un'analogia più sofisticata. Invece di un registro distribuito, Ethereum è una [macchina a stati](https://wikipedia.org/wiki/Finite-state_machine) distribuita. Lo stato di Ethereum è una grande struttura dati che contiene non solo tutti gli account e i saldi, ma uno _stato della macchina_, che può cambiare da blocco a blocco secondo un insieme predefinito di regole e che può eseguire codice macchina arbitrario. Le regole specifiche per il cambiamento di stato da blocco a blocco sono definite dall'EVM.
- _Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## La funzione di transizione di stato di Ethereum {#the-ethereum-state-transition-function}
-L'EVM si comporta come una funzione matematica: dato un input, produce un output deterministico. Quindi è più utile descrivere formalmente Ethereum come avente una **funzione di transizione di stato**:
+L'EVM si comporta come farebbe una funzione matematica: dato un input, produce un output deterministico. È quindi piuttosto utile descrivere più formalmente Ethereum come avente una **funzione di transizione di stato**:
```
Y(S, T)= S'
```
-Dato un vecchio stato valido `(S)` e un nuovo set di transazioni valide `(T)`, la funzione di transizione di stato di Ethereum `Y(S, T)` produce un nuovo stato di output valido `S'`
+Dato un vecchio stato valido `(S)` e un nuovo insieme di transazioni valide `(T)`, la funzione di transizione di stato di Ethereum `Y(S, T)` produce un nuovo stato di output valido `S'`
### Stato {#state}
-Nel contesto di Ethereum, lo stato è un'enorme struttura di dati detta un [albero di Patricia Merkle modificato](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), che contiene tutti i [conti](/developers/docs/accounts/) collegati da hash e riducibili a un singolo hash di radice, archiviato sulla blockchain.
+Nel contesto di Ethereum, lo stato è un'enorme struttura dati chiamata [Trie di Merkle Patricia modificato](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), che mantiene tutti gli [account](/developers/docs/accounts/) collegati da hash e riducibili a un singolo hash radice memorizzato sulla blockchain.
### Transazioni {#transactions}
-Le transazioni sono istruzioni firmate crittograficamente, provenienti dai conti. Esistono due tipi di transazioni: quelle che danno luogo a chiamate di messaggio e quelle che invece danno luogo alla creazione di contratti.
+Le transazioni sono istruzioni firmate crittograficamente dagli account. Esistono due tipi di transazioni: quelle che risultano in chiamate di messaggi e quelle che risultano nella creazione di contratti.
-La creazione del contratto risulta nella creazione di un nuovo conto del contratto, contenente bytecode compilato del [contratto intelligente](/developers/docs/smart-contracts/anatomy/). Ogni volta che un altro conto effettua una chiamata di messaggio a quel contratto, esegue il suo bytecode.
+La creazione di un contratto risulta nella creazione di un nuovo account del contratto contenente il bytecode compilato del [contratto intelligente](/developers/docs/smart-contracts/anatomy/). Ogni volta che un altro account effettua una chiamata di messaggio a quel contratto, ne esegue il bytecode.
## Istruzioni dell'EVM {#evm-instructions}
-L'EVM viene eseguita come una [macchina a stack](https://wikipedia.org/wiki/Stack_machine) con una profondità di 1024 elementi. Ogni elemento è una parola di 256 bit, scelta per la facilità d'uso con la crittografia a 256 bit (come gli hash Keccak-256 o le firme secp256k1).
+L'EVM viene eseguita come una [macchina a stack](https://wikipedia.org/wiki/Stack_machine) con una profondità di 1024 elementi. Ogni elemento è una parola a 256 bit, scelta per la facilità d'uso con la crittografia a 256 bit (come gli hash Keccak-256 o le firme secp256k1).
-Durante l'esecuzione, l'EVM mantiene una _memoria_ transitoria (sotto forma di array di byte con indirizzamento a parola), che non rimane persistente tra le transazioni.
+Durante l'esecuzione, l'EVM mantiene una _memoria_ transitoria (come un array di byte indirizzato a parole), che non persiste tra le transazioni.
-I contratti, comunque, contengono un albero d'_archiviazione_ di Merkle Patricia (come un insieme indirizzabile alle parole contenute), associato al conto in questione e parte dello stato globale.
+### Archiviazione transitoria
-Il bytecode compilato del contratto intelligente è eseguito come un numero degli [opcode](/developers/docs/evm/opcodes) dell'EVM, che eseguono operazioni standard dello stack come `XOR`, `AND`, `ADD`, `SUB`, etc. L'EVM implementa anche una serie di operazioni di stack specifiche della blockchain, come `INDIRIZZO`, `SALDO`, `BLOCKHASH`, etc.
+L'archiviazione transitoria è un archivio chiave-valore per transazione a cui si accede tramite gli opcode `TSTORE` e `TLOAD`. Persiste attraverso tutte le chiamate interne durante la stessa transazione, ma viene cancellata alla fine della transazione. A differenza della memoria, l'archiviazione transitoria è modellata come parte dello stato dell'EVM piuttosto che del frame di esecuzione, eppure non viene confermata nello stato globale. L'archiviazione transitoria consente la condivisione temporanea dello stato in modo efficiente in termini di gas tra le chiamate interne durante una transazione.
- _Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+### Archiviazione
+
+I contratti contengono un trie di _archiviazione_ di Merkle Patricia (come un array di parole indirizzabile a parole), associato all'account in questione e parte dello stato globale. Questa archiviazione persistente differisce dall'archiviazione transitoria, che è disponibile solo per la durata di una singola transazione e non fa parte del trie di archiviazione persistente dell'account.
+
+### Opcode
+
+Il bytecode compilato del contratto intelligente viene eseguito come una serie di [opcode](/developers/docs/evm/opcodes) dell'EVM, che eseguono operazioni standard di stack come `XOR`, `AND`, `ADD`, `SUB`, ecc. L'EVM implementa anche una serie di operazioni di stack specifiche per la blockchain, come `ADDRESS`, `BALANCE`, `BLOCKHASH`, ecc. Il set di opcode include anche `TSTORE` e `TLOAD`, che forniscono l'accesso all'archiviazione transitoria.
+
+
+_Diagrammi adattati da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
## Implementazioni dell'EVM {#evm-implementations}
-Tutte le implementazioni dell'EVM devono rispettare le specifiche descritte nello Yellowpaper di Ethereum.
+Tutte le implementazioni dell'EVM devono aderire alle specifiche descritte nell'Ethereum Yellowpaper.
-Nei nove anni di storia di Ethereum, l'EVM ha subito diverse revisioni, ed esistono diverse implementazioni dell'EVM in vari linguaggi di programmazione.
+Nel corso dei dieci anni di storia di Ethereum, l'EVM ha subito diverse revisioni e ci sono diverse implementazioni dell'EVM in vari linguaggi di programmazione.
-Tutti i [client Ethereum](/developers/docs/nodes-and-clients/#execution-clients) includono un'implementazione dell'EVM. Inoltre, esistono diverse implementazioni standalone, tra cui:
+I [client di esecuzione](/developers/docs/nodes-and-clients/#execution-clients) di Ethereum includono un'implementazione dell'EVM. Inoltre, ci sono molteplici implementazioni indipendenti, tra cui:
- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_
- [evmone](https://github.com/ethereum/evmone) - _C++_
- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_
- [revm](https://github.com/bluealloy/revm) - _Rust_
-## Letture consigliate {#further-reading}
+## Letture di approfondimento {#further-reading}
- [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf)
-- [Jellopaper o KEVM: Semantica di EVM in K](https://jellopaper.org/)
+- [Jellopaper aka KEVM: Semantics of EVM in K](https://jellopaper.org/)
- [The Beigepaper](https://github.com/chronaeon/beigepaper)
-- [Ethereum Virtual Machine Opcodes](https://www.ethervm.io/)
-- [Documentazione di riferimento del codice operativo della macchina virtuale di Ethereum](https://www.evm.codes/)
-- [Una breve introduzione alla documentazione di Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
-- [Padroneggiare Ethereum - La Macchina Virtuale di Ethereum](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc)
+- [Opcode della Macchina Virtuale di Ethereum](https://www.ethervm.io/)
+- [Riferimento interattivo agli opcode della Macchina Virtuale di Ethereum](https://www.evm.codes/)
+- [Una breve introduzione nella documentazione di Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6)
+- [Mastering Ethereum - The Ethereum Virtual Machine](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc)
## Argomenti correlati {#related-topics}
- [Gas](/developers/docs/gas/)
+
+## Tutorial: Macchina Virtuale di Ethereum (EVM) / Opcode su Ethereum {#tutorials}
+
+- [Comprendere le specifiche dell'EVM dello Yellow Paper](/developers/tutorials/yellow-paper-evm/) _– Una guida passo passo alle specifiche formali dell'EVM tratte dall'Ethereum Yellow Paper._
+- [Ingegneria inversa di un contratto](/developers/tutorials/reverse-engineering-a-contract/) _– Come fare ingegneria inversa di un contratto intelligente compilato utilizzando gli opcode dell'EVM._
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/evm/opcodes/index.md b/public/content/translations/it/developers/docs/evm/opcodes/index.md
index 3bc11b514ee..aee9910a2ee 100644
--- a/public/content/translations/it/developers/docs/evm/opcodes/index.md
+++ b/public/content/translations/it/developers/docs/evm/opcodes/index.md
@@ -6,169 +6,172 @@ lang: it
## Panoramica {#overview}
-Questa è una versione aggiornata della pagina di riferimento dell'EVM a [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). Tratta anche dallo [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), dal [Jello Paper](https://jellopaper.org/evm/) e dall'implementazione di [geth](https://github.com/ethereum/go-ethereum). Si tratta di un riferimento accessibile, ma non particolarmente rigoroso. Se vuoi essere certo della correttezza e consapevole di ogni caso limite, è consigliabile utilizzare lo Jello Paper o un'implementazione del client.
+Questa è una versione aggiornata della pagina di riferimento dell'EVM su [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes).
+Tratta anche dallo [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), dal [Jello Paper](https://jellopaper.org/evm/) e dall'implementazione di [geth](https://github.com/ethereum/go-ethereum).
+Vuole essere un riferimento accessibile, ma non è particolarmente rigoroso.
+Se si vuole avere la certezza della correttezza e conoscere ogni caso limite, è consigliabile utilizzare il Jello Paper o un'implementazione del client.
-Cerchi un riferimento interattivo? Dai un'occhiata su [evm.codes](https://www.evm.codes/).
+Cerchi un riferimento interattivo? Dai un'occhiata a [evm.codes](https://www.evm.codes/).
-Per le operazioni con costi del carburante dinamici, consulta [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md).
+Per le operazioni con costi del gas dinamici, vedi [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md).
-💡 Consiglio rapido: per visualizzare le righe intere, usa `[shift] + scorrimento` per scorrere orizzontalmente su desktop.
+💡 Suggerimento rapido: per visualizzare le righe intere, usa `[shift] + scroll` per scorrere orizzontalmente su desktop.
-| Stack | Nome | Gas | Stack Iniziale | Stack Risultante | Mem / Archiviazione | Note |
-|:-----:|:-------------- |:------------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 00 | STOP | 0 | | | | halt execution |
-| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 |
-| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 |
-| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 |
-| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division |
-| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division |
-| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus |
-| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus |
-| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N |
-| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N |
-| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 |
-| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes |
-| 0C-0F | _invalid_ | | | | | |
-| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than |
-| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than |
-| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than |
-| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than |
-| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality |
-| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero |
-| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND |
-| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR |
-| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR |
-| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT |
-| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left |
-| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left |
-| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right |
-| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right |
-| 1E-1F | _invalid_ | | | | | |
-| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 |
-| 21-2F | _invalid_ | | | | | |
-| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract |
-| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei |
-| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx |
-| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender |
-| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei |
-| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` |
-| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes |
-| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data |
-| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes |
-| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode |
-| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) |
-| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes |
-| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` |
-| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes |
-| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call |
-| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 |
-| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | |
-| 41 | COINBASE | 2 | `.` | `block.coinbase` | | indirizzo del propositore del blocco corrente |
-| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block |
-| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block |
-| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon |
-| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block |
-| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack |
-| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei |
-| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block |
-| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) |
-| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | commissione di base del blob del blocco corrente ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) |
-| 4B-4F | _invalid_ | | | | | |
-| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it |
-| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` |
-| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory |
-| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory |
-| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage |
-| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage |
-| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest |
-| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` |
-| 58 | PC | 2 | `.` | `$pc` | | program counter |
-| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes |
-| 5A | GAS | 2 | `.` | `gasRemaining` | | |
-| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data |
-| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | legge la parola dall'archiviazione transiente ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | scrive la parola all'archiviazione transiente ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
-| 5E | MCOPY | 3+3\*parole+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copia la memoria da un'area a un'altra ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) |
-| 5F | PUSH0 | 2 | `.` | `uint8` | | spinge il valore costante 0 allo stack |
-| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack |
-| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack |
-| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack |
-| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack |
-| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack |
-| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack |
-| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack |
-| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack |
-| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack |
-| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack |
-| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack |
-| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack |
-| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack |
-| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack |
-| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack |
-| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack |
-| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack |
-| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack |
-| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack |
-| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack |
-| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack |
-| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack |
-| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack |
-| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack |
-| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack |
-| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack |
-| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack |
-| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack |
-| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack |
-| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack |
-| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack |
-| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack |
-| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack |
-| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack |
-| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack |
-| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack |
-| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack |
-| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack |
-| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack |
-| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack |
-| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack |
-| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack |
-| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack |
-| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack |
-| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack |
-| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack |
-| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack |
-| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack |
-| 90 | SWAP1 | 3 | `a, b` | `b, a` | | |
-| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | |
-| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | |
-| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | |
-| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | |
-| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | |
-| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) |
-| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) |
-| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) |
-| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) |
-| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
-| A5-EF | _invalid_ | | | | | |
-| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) |
-| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value |
-| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] |
-| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] |
-| F6-F9 | _invalid_ | | | | | |
-| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | |
-| FB-FC | _invalid_ | | | | | |
-| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) |
-| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | |
-| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | invia tutti gli ETH ad `addr`; se eseguito nella stessa transazione in cui un contratto è stato creato, lo distrugge |
+| Stack | Name | Gas | Initial Stack | Resulting Stack | Mem / Storage | Notes |
+| :---: | :------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------- | :------------------------------ | :---------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------- |
+| 00 | STOP | 0 | | | | interrompe l'esecuzione |
+| 01 | ADD | 3 | `a, b` | `a + b` | | addizione (u)int256 modulo 2\*\*256 |
+| 02 | MUL | 5 | `a, b` | `a * b` | | moltiplicazione (u)int256 modulo 2\*\*256 |
+| 03 | SUB | 3 | `a, b` | `a - b` | | sottrazione (u)int256 modulo 2\*\*256 |
+| 04 | DIV | 5 | `a, b` | `a // b` | | divisione uint256 |
+| 05 | SDIV | 5 | `a, b` | `a // b` | | divisione int256 |
+| 06 | MOD | 5 | `a, b` | `a % b` | | modulo uint256 |
+| 07 | SMOD | 5 | `a, b` | `a % b` | | modulo int256 |
+| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | addizione (u)int256 modulo N |
+| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | moltiplicazione (u)int256 modulo N |
+| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | esponenziazione uint256 modulo 2\*\*256 |
+| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [estensione del segno](https://wikipedia.org/wiki/Sign_extension) di `x` da `(b+1)` byte a 32 byte |
+| 0C-0F | _non valido_ |
+| 10 | LT | 3 | `a, b` | `a < b` | | minore di uint256 |
+| 11 | GT | 3 | `a, b` | `a > b` | | maggiore di uint256 |
+| 12 | SLT | 3 | `a, b` | `a < b` | | minore di int256 |
+| 13 | SGT | 3 | `a, b` | `a > b` | | maggiore di int256 |
+| 14 | EQ | 3 | `a, b` | `a == b` | | uguaglianza (u)int256 |
+| 15 | ISZERO | 3 | `a` | `a == 0` | | iszero (u)int256 |
+| 16 | AND | 3 | `a, b` | `a && b` | | AND bit a bit |
+| 17 | OR | 3 | `a, b` | `a \|\| b` | | OR bit a bit |
+| 18 | XOR | 3 | `a, b` | `a ^ b` | | XOR bit a bit |
+| 19 | NOT | 3 | `a` | `~a` | | NOT bit a bit |
+| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`-esimo byte di (u)int256 `x`, da sinistra |
+| 1B | SHL | 3 | `shift, val` | `val << shift` | | scorrimento a sinistra |
+| 1C | SHR | 3 | `shift, val` | `val >> shift` | | scorrimento logico a destra |
+| 1D | SAR | 3 | `shift, val` | `val >> shift` | | scorrimento aritmetico a destra |
+| 1E-1F | _non valido_ |
+| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 |
+| 21-2F | _non valido_ |
+| 30 | ADDRESS | 2 | `.` | `address(this)` | | indirizzo del contratto in esecuzione |
+| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | saldo, in wei |
+| 32 | ORIGIN | 2 | `.` | `tx.origin` | | indirizzo che ha originato la transazione |
+| 33 | CALLER | 2 | `.` | `msg.sender` | | indirizzo del mittente del msg |
+| 34 | CALLVALUE | 2 | `.` | `msg.value` | | valore del msg, in wei |
+| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | legge una parola dai dati del msg all'indice `idx` |
+| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | lunghezza dei dati del msg, in byte |
+| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copia i dati del msg |
+| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | lunghezza del codice del contratto in esecuzione, in byte |
+| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copia il bytecode del contratto in esecuzione |
+| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | prezzo del gas della transazione, in wei per unità di gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) |
+| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | dimensione del codice all'indirizzo addr, in byte |
+| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copia il codice da `addr` |
+| 3D | RETURNDATASIZE | 2 | `.` | `size` | | dimensione dei dati restituiti dall'ultima chiamata esterna, in byte |
+| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copia i dati restituiti dall'ultima chiamata esterna |
+| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 |
+| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | |
+| 41 | COINBASE | 2 | `.` | `block.coinbase` | | indirizzo del proponente del blocco corrente |
+| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp del blocco corrente |
+| 43 | NUMBER | 2 | `.` | `block.number` | | numero del blocco corrente |
+| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | beacon di casualità |
+| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | limite del gas del blocco corrente |
+| 46 | CHAINID | 2 | `.` | `chain_id` | | inserisce l'[ID della catena](https://eips.ethereum.org/EIPS/eip-155) corrente nello stack |
+| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | saldo del contratto in esecuzione, in wei |
+| 48 | BASEFEE | 2 | `.` | `block.basefee` | | commissione di base del blocco corrente |
+| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) |
+| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | commissione di base del blob del blocco corrente ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) |
+| 4B-4F | _non valido_ |
+| 50 | POP | 2 | `_anon` | `.` | | rimuove l'elemento dalla cima dello stack e lo scarta |
+| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | legge una parola dalla memoria all'offset `ost` |
+| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | scrive una parola in memoria |
+| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | scrive un singolo byte in memoria |
+| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | legge una parola dallo storage |
+| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | scrive una parola nello storage |
+| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` segna che `pc` viene assegnato solo se `dst` è un jumpdest valido |
+| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` |
+| 58 | PC | 2 | `.` | `$pc` | | contatore di programma |
+| 59 | MSIZE | 2 | `.` | `len(mem)` | | dimensione della memoria nel contesto di esecuzione corrente, in byte |
+| 5A | GAS | 2 | `.` | `gasRemaining` | |
+| 5B | JUMPDEST | 1 | | | segna una destinazione di salto valida | una destinazione di salto valida, ad esempio una destinazione di salto non all'interno dei dati di push |
+| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | legge una parola dallo storage transitorio ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
+| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | scrive una parola nello storage transitorio ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) |
+| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copia la memoria da un'area all'altra ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) |
+| 5F | PUSH0 | 2 | `.` | `uint8` | | inserisce il valore costante 0 nello stack |
+| 60 | PUSH1 | 3 | `.` | `uint8` | | inserisce un valore di 1 byte nello stack |
+| 61 | PUSH2 | 3 | `.` | `uint16` | | inserisce un valore di 2 byte nello stack |
+| 62 | PUSH3 | 3 | `.` | `uint24` | | inserisce un valore di 3 byte nello stack |
+| 63 | PUSH4 | 3 | `.` | `uint32` | | inserisce un valore di 4 byte nello stack |
+| 64 | PUSH5 | 3 | `.` | `uint40` | | inserisce un valore di 5 byte nello stack |
+| 65 | PUSH6 | 3 | `.` | `uint48` | | inserisce un valore di 6 byte nello stack |
+| 66 | PUSH7 | 3 | `.` | `uint56` | | inserisce un valore di 7 byte nello stack |
+| 67 | PUSH8 | 3 | `.` | `uint64` | | inserisce un valore di 8 byte nello stack |
+| 68 | PUSH9 | 3 | `.` | `uint72` | | inserisce un valore di 9 byte nello stack |
+| 69 | PUSH10 | 3 | `.` | `uint80` | | inserisce un valore di 10 byte nello stack |
+| 6A | PUSH11 | 3 | `.` | `uint88` | | inserisce un valore di 11 byte nello stack |
+| 6B | PUSH12 | 3 | `.` | `uint96` | | inserisce un valore di 12 byte nello stack |
+| 6C | PUSH13 | 3 | `.` | `uint104` | | inserisce un valore di 13 byte nello stack |
+| 6D | PUSH14 | 3 | `.` | `uint112` | | inserisce un valore di 14 byte nello stack |
+| 6E | PUSH15 | 3 | `.` | `uint120` | | inserisce un valore di 15 byte nello stack |
+| 6F | PUSH16 | 3 | `.` | `uint128` | | inserisce un valore di 16 byte nello stack |
+| 70 | PUSH17 | 3 | `.` | `uint136` | | inserisce un valore di 17 byte nello stack |
+| 71 | PUSH18 | 3 | `.` | `uint144` | | inserisce un valore di 18 byte nello stack |
+| 72 | PUSH19 | 3 | `.` | `uint152` | | inserisce un valore di 19 byte nello stack |
+| 73 | PUSH20 | 3 | `.` | `uint160` | | inserisce un valore di 20 byte nello stack |
+| 74 | PUSH21 | 3 | `.` | `uint168` | | inserisce un valore di 21 byte nello stack |
+| 75 | PUSH22 | 3 | `.` | `uint176` | | inserisce un valore di 22 byte nello stack |
+| 76 | PUSH23 | 3 | `.` | `uint184` | | inserisce un valore di 23 byte nello stack |
+| 77 | PUSH24 | 3 | `.` | `uint192` | | inserisce un valore di 24 byte nello stack |
+| 78 | PUSH25 | 3 | `.` | `uint200` | | inserisce un valore di 25 byte nello stack |
+| 79 | PUSH26 | 3 | `.` | `uint208` | | inserisce un valore di 26 byte nello stack |
+| 7A | PUSH27 | 3 | `.` | `uint216` | | inserisce un valore di 27 byte nello stack |
+| 7B | PUSH28 | 3 | `.` | `uint224` | | inserisce un valore di 28 byte nello stack |
+| 7C | PUSH29 | 3 | `.` | `uint232` | | inserisce un valore di 29 byte nello stack |
+| 7D | PUSH30 | 3 | `.` | `uint240` | | inserisce un valore di 30 byte nello stack |
+| 7E | PUSH31 | 3 | `.` | `uint248` | | inserisce un valore di 31 byte nello stack |
+| 7F | PUSH32 | 3 | `.` | `uint256` | | inserisce un valore di 32 byte nello stack |
+| 80 | DUP1 | 3 | `a` | `a, a` | | clona il 1° valore nello stack |
+| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clona il 2° valore nello stack |
+| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clona il 3° valore nello stack |
+| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clona il 4° valore nello stack |
+| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clona il 5° valore nello stack |
+| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clona il 6° valore nello stack |
+| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clona il 7° valore nello stack |
+| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clona l'8° valore nello stack |
+| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clona il 9° valore nello stack |
+| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clona il 10° valore nello stack |
+| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clona l'11° valore nello stack |
+| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clona il 12° valore nello stack |
+| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clona il 13° valore nello stack |
+| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clona il 14° valore nello stack |
+| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clona il 15° valore nello stack |
+| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clona il 16° valore nello stack |
+| 90 | SWAP1 | 3 | `a, b` | `b, a` | |
+| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | |
+| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | |
+| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | |
+| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | |
+| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | |
+| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | |
+| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | |
+| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | |
+| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | |
+| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | |
+| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | |
+| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | |
+| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | |
+| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | |
+| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | |
+| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) |
+| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) |
+| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) |
+| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) |
+| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) |
+| A5-EF | _non valido_ |
+| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) |
+| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata |
+| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | uguale a DELEGATECALL, ma non propaga il msg.sender e il msg.value originali |
+| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | restituisce mem[ost:ost+len-1] |
+| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata |
+| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] |
+| F6-F9 | _non valido_ |
+| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata |
+| FB-FC | _non valido_ |
+| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) |
+| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | opcode non valido designato - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) |
+| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | invia tutti gli ETH a `addr`; se eseguito nella stessa transazione in cui è stato creato un contratto, distrugge il contratto |
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/frameworks/index.md b/public/content/translations/it/developers/docs/frameworks/index.md
index 050f0852693..cdf12809f6c 100644
--- a/public/content/translations/it/developers/docs/frameworks/index.md
+++ b/public/content/translations/it/developers/docs/frameworks/index.md
@@ -1,138 +1,138 @@
---
-title: Framework di sviluppo delle dapp
-description: Scopri Esplora i vantaggi dei framework e confronta le opzioni disponibili.
+title: Framework di sviluppo per dApp
+description: Esplora i vantaggi dei framework e confronta le opzioni disponibili.
lang: it
---
## Introduzione ai framework {#introduction-to-frameworks}
-Sviluppare una dapp completa richiede diverse tecnologie. I framework software includono molte delle funzionalità necessarie oppure offrono semplici plugin per scegliere gli strumenti richiesti.
+Costruire una dApp a tutti gli effetti richiede diversi elementi tecnologici. I framework software includono molte delle funzionalità necessarie o forniscono semplici sistemi di plugin per scegliere gli strumenti desiderati.
-I framework sono già dotati di molte funzionalità, come:
+I framework sono dotati di molte funzionalità pronte all'uso, come:
-- Funzionalità per avviare un'istanza di blockchain locale.
+- Funzionalità per avviare un'istanza locale della blockchain.
- Utilità per compilare e testare i tuoi contratti intelligenti.
-- Componenti aggiuntivi di sviluppo client per creare un'applicazione rivolta all'utente all'interno dello stesso progetto/repository.
-- Configurazione per connettersi a reti Ethereum e distribuire contratti, a un'istanza locale o a una delle reti pubbliche di Ethereum.
-- Distribuzione di app decentralizzate - integrazioni con opzioni di archiviazione come IPFS.
+- Componenti aggiuntivi per lo sviluppo del client per creare la tua applicazione rivolta all'utente all'interno dello stesso progetto/repository.
+- Configurazione per connettersi alle reti di Ethereum e distribuire contratti, sia su un'istanza in esecuzione locale, sia su una delle reti pubbliche di Ethereum.
+- Distribuzione di app decentralizzate: integrazioni con opzioni di archiviazione come IPFS.
## Prerequisiti {#prerequisites}
-Prima di iniziare a studiare i framework, raccomandiamo la lettura della nostra introduzione alle [dApp](/developers/docs/dapps/) e allo [stack di Ethereum](/developers/docs/ethereum-stack/).
+Prima di immergerti nei framework, ti consigliamo di leggere la nostra introduzione alle [dApp](/developers/docs/dapps/) e allo [stack di Ethereum](/developers/docs/ethereum-stack/).
## Framework disponibili {#available-frameworks}
-**Foundry** - **_Foundry è un toolkit dalla straordinaria velocità, portatile e modulare per lo sviluppo di applicazioni di Ethereum._**
+**Foundry** - **_Foundry è un toolkit incredibilmente veloce, portatile e modulare per lo sviluppo di applicazioni su Ethereum_**
- [Installa Foundry](https://book.getfoundry.sh/)
-- [Guida a Foundry](https://book.getfoundry.sh/)
+- [Libro di Foundry](https://book.getfoundry.sh/)
- [Chat della community di Foundry su Telegram](https://t.me/foundry_support)
- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry)
-**Hardhat:** **_ ambiente di sviluppo Ethereum per professionisti_**
+**Hardhat -** **_Ambiente di sviluppo su Ethereum per professionisti._**
- [hardhat.org](https://hardhat.org)
- [GitHub](https://github.com/nomiclabs/hardhat)
-**Ape**: **_Lo strumento di sviluppo di contratti intelligenti per utilizzatori di Python, Data Scientist e Professionisti della Sicurezza._**
+**Ape -** **_Lo strumento di sviluppo di contratti intelligenti per programmatori Python, scienziati dei dati e professionisti della sicurezza._**
- [Documentazione](https://docs.apeworx.io/ape/stable/)
- [GitHub](https://github.com/ApeWorX/ape)
-**Web3j -** **_Una piattaforma per sviluppare applicazioni della blockchain sulla JVM_**
+**Web3j -** **_Una piattaforma per lo sviluppo di applicazioni blockchain sulla JVM._**
-- [Home page](https://www.web3labs.com/web3j-sdk)
+- [Homepage](https://www.web3labs.com/web3j-sdk)
- [Documentazione](https://docs.web3j.io)
- [GitHub](https://github.com/web3j/web3j)
-**ethers-kt -** **_Libreria asincrona e ad alte prestazioni per Kotlin/Java/Android per le blockchain basate sull'EVM._**
+**ethers-kt -** **_Libreria asincrona e ad alte prestazioni in Kotlin/Java/Android per blockchain basate su EVM._**
- [GitHub](https://github.com/Kr1ptal/ethers-kt)
- [Esempi](https://github.com/Kr1ptal/ethers-kt/tree/master/examples)
- [Discord](https://discord.gg/rx35NzQGSb)
-**Create Eth App -** **_Crea app per Ethereum con un comando. Offre una vasta scelta di framework per l'interfaccia utente e modelli DeFI tra cui scegliere._**
+**Create Eth App -** **_Crea app basate su Ethereum con un solo comando. Viene fornito con un'ampia offerta di framework per l'interfaccia utente e modelli DeFi tra cui scegliere._**
- [GitHub](https://github.com/paulrberg/create-eth-app)
- [Modelli](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates)
-**Scaffold-Eth -** **_I componenti Ethers.js + Hardhat + React e gli hook per web3: tutto ciò che ti serve per iniziare a creare applicazioni decentralizzate alimentate da contratti intelligenti._**
+**Scaffold-Eth -** **_Ethers.js + Hardhat + componenti e hook React per il web3: tutto ciò di cui hai bisogno per iniziare a creare applicazioni decentralizzate basate su contratti intelligenti._**
- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2)
-**Tenderly -** **_Piattaforma di sviluppo di Web3 che consente agli sviluppatori della blockchain di costruire, testare, eseguire il debug, monitorare e gestire i contratti intelligenti, nonché di migliorare l'UX della dapp._**
+**Tenderly -** **_Piattaforma di sviluppo web3 che consente agli sviluppatori blockchain di creare, testare, eseguire il debug, monitorare e gestire contratti intelligenti e migliorare l'UX delle dApp._**
-- [Sito Web](https://tenderly.co/)
+- [Sito web](https://tenderly.co/)
- [Documentazione](https://docs.tenderly.co/)
-**The Graph -** **_ The Graph per interrogare efficientemente i dati della blockchain_**
+**The Graph -** **_The Graph per interrogare i dati della blockchain in modo efficiente._**
-- [Sito Web](https://thegraph.com/)
+- [Sito web](https://thegraph.com/)
- [Tutorial](/developers/tutorials/the-graph-fixing-web3-data-querying/)
-**Alchemy -** **_Piattaforma di sviluppo Ethereum_**
+**Alchemy -** **_Piattaforma di sviluppo su Ethereum._**
- [alchemy.com](https://www.alchemy.com/)
- [GitHub](https://github.com/alchemyplatform)
- [Discord](https://discord.com/invite/alchemyplatform)
-**NodeReal -** **_Piattaforma di sviluppo per Ethereum._**
+**NodeReal -** **_Piattaforma di sviluppo su Ethereum._**
- [Nodereal.io](https://nodereal.io/)
- [GitHub](https://github.com/node-real)
- [Discord](https://discord.gg/V5k5gsuE)
-**thirdweb SDK -** **_Sviluppa applicazioni web3 che possono interagire con i tuoi contratti intelligenti usando i nostri potenti SDK e CLI._**
+**thirdweb SDK -** **_Crea applicazioni web3 che possono interagire con i tuoi contratti intelligenti utilizzando i nostri potenti SDK e CLI._**
- [Documentazione](https://portal.thirdweb.com/sdk/)
- [GitHub](https://github.com/thirdweb-dev/)
-**Chainstack -** **_Piattaforma di sviluppo Web3 (Ethereum e altri)._**
+**Chainstack -** **_Piattaforma di sviluppo Web3 (Ethereum e altro)._**
- [chainstack.com](https://www.chainstack.com/)
- [GitHub](https://github.com/chainstack)
- [Discord](https://discord.gg/BSb5zfp9AT)
-**Crossmint -** **_Piattaforma di sviluppo Web3 per imprese che ti consente di creare applicazioni NFT su tutte le principali catene EVM (e non solo)._**
+**Crossmint -** **_Piattaforma di sviluppo web3 di livello aziendale, che ti consente di creare applicazioni NFT su tutte le principali catene EVM (e altre)._**
-- [Sito Web](https://www.crossmint.com)
+- [Sito web](https://www.crossmint.com)
- [Documentazione](https://docs.crossmint.com)
- [Discord](https://discord.com/invite/crossmint)
-**Brownie -** **_ Ambiente di sviluppo e framework per il test basati su Python _**
+**Brownie -** **_Ambiente di sviluppo e framework di test basato su Python._**
- [Documentazione](https://eth-brownie.readthedocs.io/en/latest/)
- [GitHub](https://github.com/eth-brownie/brownie)
-- **Brownie non è al momento mantenuto**
+- **Brownie non è attualmente mantenuto**
-**OpenZeppelin SDK -** **_Il kit di strumenti definitivo per i contratti intelligenti: una suite di strumenti per aiutarti a sviluppare, compilare, aggiornare, distribuire e interagire con i contratti intelligenti_**
+**OpenZeppelin SDK -** **_Il toolkit definitivo per i contratti intelligenti: una suite di strumenti per aiutarti a sviluppare, compilare, aggiornare, distribuire e interagire con i contratti intelligenti._**
-- [OpenZeppelin SDK](https://openzeppelin.com/sdk/)
+- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk)
- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk)
- [Forum della community](https://forum.openzeppelin.com/c/support/17)
- **Lo sviluppo di OpenZeppelin SDK è terminato**
-**Catapulta -** **_Strumento di distribuzione di contratti intelligenti multi-catena, automatizza le verifiche negli esploratori dei blocchi, tiene traccia dei contratti intelligenti distribuiti e condivide i rapporti di distribuzione; pronto all'uso per i progetti di Foundry e Hardhat._**
+**Catapulta -** **_Strumento di distribuzione di contratti intelligenti multi-catena, automatizza le verifiche negli esploratori di blocchi, tiene traccia dei contratti intelligenti distribuiti e condivide i report di distribuzione, plug-n-play per progetti Foundry e Hardhat._**
-- [Github](https://github.com/catapulta-sh)
+- [GitHub](https://github.com/catapulta-sh)
-**Covalent -** **_API della blockchain arricchite per oltre 200 catene._**
+**GoldRush (basato su Covalent) -** **_GoldRush offre la suite di API di dati blockchain più completa per sviluppatori, analisti e aziende. Che tu stia costruendo una dashboard DeFi, un portafoglio, un bot di trading, un agente IA o una piattaforma di conformità, le API di dati forniscono un accesso rapido, accurato e intuitivo per gli sviluppatori ai dati on-chain essenziali di cui hai bisogno_**
-- [covalenthq.com](https://www.covalenthq.com/)
-- [Documentazione](https://www.covalenthq.com/docs/api/)
+- [Sito web](https://goldrush.dev/)
+- [Documentazione](https://goldrush.dev/docs/chains/ethereum)
- [GitHub](https://github.com/covalenthq)
- [Discord](https://www.covalenthq.com/discord/)
-**Wake -** **_Assetto completo di Python per testare i contratti, fuzzing, distribuzione, scansione delle vulnerabilità e navigazione del codice_**
+**Wake -** **_Framework Python all-in-one per test dei contratti, fuzzing, distribuzione, scansione delle vulnerabilità e navigazione del codice._**
-- [Home page](https://getwake.io/)
+- [Homepage](https://getwake.io/)
- [Documentazione](https://ackeeblockchain.com/wake/docs/latest/)
- [GitHub](https://github.com/Ackee-Blockchain/wake)
-- [Estensione del codice VS](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity)
+- [Estensione per VS Code](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity)
-**Veramo**: **_Framework open source, modulare e agnostico che semplifica la creazione di identità decentralizzate e credenziali verificabili per gli sviluppatori di applicazioni decentralizzate nelle proprie applicazioni._**
+**Veramo -** **_Framework open source, modulare e agnostico che semplifica agli sviluppatori di applicazioni decentralizzate la creazione di identità decentralizzate e credenziali verificabili nelle loro applicazioni._**
-- [Home page](https://veramo.io/)
+- [Homepage](https://veramo.io/)
- [Documentazione](https://veramo.io/docs/basics/introduction)
- [GitHub](https://github.com/uport-project/veramo)
- [Discord](https://discord.com/invite/FRRBdjemHV)
@@ -140,8 +140,12 @@ Prima di iniziare a studiare i framework, raccomandiamo la lettura della nostra
## Letture consigliate {#further-reading}
-_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
## Argomenti correlati {#related-topics}
-- [Configura un ambiente di sviluppo locale](/developers/local-environment/)
+- [Configurare un ambiente di sviluppo locale](/developers/local-environment/)
+
+## Tutorial: Framework di sviluppo su Ethereum {#tutorials}
+
+- [Contratto intelligente Hello World per principianti – Fullstack](/developers/tutorials/hello-world-smart-contract-fullstack/) _– Crea e distribuisci un contratto intelligente hello world usando Hardhat, quindi connettilo a un frontend._
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/gas/index.md b/public/content/translations/it/developers/docs/gas/index.md
index b095fdcf0ba..e4aae111000 100644
--- a/public/content/translations/it/developers/docs/gas/index.md
+++ b/public/content/translations/it/developers/docs/gas/index.md
@@ -1,140 +1,151 @@
---
title: Gas e commissioni
-metaTitle: "Gas e commissioni Ethereum: panoramica tecnica"
-description:
+metaTitle: "Gas e commissioni di Ethereum: panoramica tecnica"
+description: Scopri le commissioni del gas di Ethereum, come vengono calcolate e il loro ruolo nella sicurezza della rete e nell'elaborazione delle transazioni.
lang: it
---
-Il gas è essenziale per la rete di Ethereum. È il carburante che gli consente di operare, proprio come un'automobile lo necessita per funzionare.
+Il gas è essenziale per la rete [Ethereum](/). È il carburante che le permette di funzionare, allo stesso modo in cui un'auto ha bisogno di benzina per muoversi.
## Prerequisiti {#prerequisites}
-Per capire meglio questa pagina, consigliamo innanzi tutto di leggere gli argomenti su [transazioni](/developers/docs/transactions/) ed [EVM](/developers/docs/evm/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima le [transazioni](/developers/docs/transactions/) e la [EVM](/developers/docs/evm/).
## Cos'è il gas? {#what-is-gas}
-Gas fa riferimento all'unità che misura la quantità di sforzo di calcolo necessario per eseguire operazioni specifiche sulla rete di Ethereum.
+Il gas si riferisce all'unità che misura la quantità di sforzo computazionale richiesto per eseguire operazioni specifiche sulla rete Ethereum.
-Poiché ogni transazione di Ethereum richiede risorse computazionali per essere eseguita, queste risorse devono essere pagate per assicurare che Ethereum non sia vulnerabile a spam e che non si blocchi in cicli computazionali infiniti. Il pagamento per il calcolo è fatto sotto forma di commissioni di carburante (comunemente chiamato gas).
+Poiché ogni transazione di Ethereum richiede risorse computazionali per essere eseguita, tali risorse devono essere pagate per garantire che Ethereum non sia vulnerabile allo spam e non possa bloccarsi in cicli computazionali infiniti. Il pagamento per il calcolo viene effettuato sotto forma di commissione del gas.
-La commissione del gas è **la quantità di gas usato per eseguire alcune operazioni, moltiplicato per il costo di una unità di gas**. La commissione viene pagata indipendentemente dal fatto che la transazione abbia successo o fallisca.
+La commissione del gas è **la quantità di gas utilizzata per eseguire un'operazione, moltiplicata per il costo per unità di gas**. La commissione viene pagata indipendentemente dal fatto che una transazione abbia successo o fallisca.
- _Diagramma adattato da [Ethereum EVM illustrato](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-Le commissioni del gas devono essere pagate nella valuta nativa di Ethereum, l'ether (ETH). I prezzi del gas sono solitamente riportati in gwei, che è una sottounità di ETH. Ogni gwei equivale ad un miliardesimo di ETH (0,000000001 ETH or 10-9 ETH).
+Le commissioni del gas devono essere pagate nella valuta nativa di Ethereum, l'ether (ETH). I prezzi del gas sono solitamente quotati in gwei, che è una denominazione di ETH. Ogni gwei è pari a un miliardesimo di ETH (0,000000001 ETH o 10-9 ETH).
-Per esempio, invece di dire che il gas costa 0,000000001 ether, puoi dire che costa 1 gwei.
+Ad esempio, invece di dire che il tuo gas costa 0,000000001 ether, puoi dire che il tuo gas costa 1 gwei.
-La parola 'gwei' è l'abbreviazione di 'giga-wei', che significa 'miliardo di wei'. Un gwei equivale ad un miliardo di wei. Il wei (dal nome di [Wei Dai](https://wikipedia.org/wiki/Wei_Dai), creatore di [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) è l'unità più piccola di ETH.
+La parola 'gwei' è una contrazione di 'giga-wei', che significa 'un miliardo di wei'. Un gwei è uguale a un miliardo di wei. Il wei stesso (che prende il nome da [Wei Dai](https://wikipedia.org/wiki/Wei_Dai), creatore di [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) è l'unità più piccola di ETH.
-## Come sono calcolate le commissioni del gas? {#how-are-gas-fees-calculated}
+## Come vengono calcolate le commissioni del gas? {#how-are-gas-fees-calculated}
-Quando invii una transazione, puoi impostare la quantità di gas che sei disposto a pagare. Offrendo una certa quantità di gas, stai facendo un'offerta per includere la tua transazione nel prossimo blocco. Se offri troppo poco, i validatori saranno meno disposti a scegliere la tua transazione per includerla, il che significa che la tua transazione potrebbe essere eseguita in ritardo o non essere eseguita affatto. Se offri troppo, potresti rischiare di sprecare un po' di ETH. Quindi, come si fa a capire quanto pagare?
+Puoi impostare la quantità di gas che sei disposto a pagare quando invii una transazione. Offrendo una certa quantità di gas, fai un'offerta affinché la tua transazione venga inclusa nel blocco successivo. Se offri troppo poco, è meno probabile che i validatori scelgano la tua transazione per l'inclusione, il che significa che la tua transazione potrebbe essere eseguita in ritardo o non essere eseguita affatto. Se offri troppo, potresti sprecare degli ETH. Quindi, come fai a sapere quanto pagare?
-Il gas totale che paghi è diviso in due componenti: la `base fee` e la `priority fee` (mancia).
+Il gas totale che paghi è diviso in due componenti: la `commissione di base` e la `commissione di priorità` (mancia).
-La `base fee` è stabilita dal protocollo - è necessario pagare almeno questo importo affinché la tua transazione sia considerata valida. La `priority fee` è una mancia che si aggiunge alla commissione base per rendere la tua transazione accattivante per i validatori in modo che la scelgano per includerla nel blocco successivo.
+La `commissione di base` è impostata dal protocollo: devi pagare almeno questo importo affinché la tua transazione sia considerata valida. La `commissione di priorità` è una mancia che aggiungi alla commissione di base per rendere la tua transazione attraente per i validatori, in modo che la scelgano per l'inclusione nel blocco successivo.
-Una transazione che paga solo la `base fee` è tecnicamente valida ma è improbabile (che venga inclusa) perché non offre incentivi ai validatori per sceglierla rispetto ad altre transazioni. La commissione `priority` 'corretta' è determinata dall'utilizzo della rete nel momento in cui invii la transazione - se c'è molta richiesta, è possibile che tu debba impostare una commissione `priority` più alta, mentre se c'è meno domanda potrai pagare meno.
+Una transazione che paga solo la `commissione di base` è tecnicamente valida ma è improbabile che venga inclusa perché non offre alcun incentivo ai validatori per sceglierla rispetto a qualsiasi altra transazione. La commissione di `priorità` 'corretta' è determinata dall'utilizzo della rete nel momento in cui invii la tua transazione: se c'è molta domanda potresti dover impostare la tua commissione di `priorità` più alta, ma quando c'è meno domanda puoi pagare di meno.
-Ad esempio, ipotizziamo che Jordan debba pagare 1 ETH a Taylor. Il trasferimento di ETH richiede 21.000 unità di gas, e la commissione base è di 10 gwei. Jordan include una mancia di 2 gwei.
+Ad esempio, supponiamo che Jordan debba pagare a Taylor 1 ETH. Un trasferimento di ETH richiede 21.000 unità di gas e la commissione di base è di 10 gwei. Jordan include una mancia di 2 gwei.
La commissione totale sarebbe ora pari a:
-`unità di gas usato * (commissione base + commissione prioritaria)`
+`unità di gas utilizzate * (commissione di base + commissione di priorità)`
-dove la `base fee` è il valore impostato dal protocollo e la `priority fee` è il valore impostato dall'utente come mancia per il validatore.
+dove la `commissione di base` è un valore impostato dal protocollo e la `commissione di priorità` è un valore impostato dall'utente come mancia per il validatore.
-ovvero `21,000 * (10 + 2) = 252,000 gwei` (0,000252 ETH).
+es., `21.000 * (10 + 2) = 252.000 gwei` (0,000252 ETH).
-Quando Jordan invia il denaro, dal suo conto sono sottratti 1,000252 ETH. Taylor riceve un accredito di 1,0000 ETH. Il validatore riceve la mancia di 0,000042 ETH. La `base fee` di 0,00021 ETH viene bruciata.
+Quando Jordan invia il denaro, 1,000252 ETH verranno detratti dall'account di Jordan. A Taylor verrà accreditato 1,0000 ETH. Il validatore riceve la mancia di 0,000042 ETH. La `commissione di base` di 0,00021 ETH viene bruciata.
-### Commissione base {#base-fee}
+### Commissione di base {#base-fee}
-Ogni blocco ha una commissione base che funge da prezzo di riserva. Per poter essere inseriti in un blocco, il prezzo offerto per il gas deve essere pari almeno alla commissione base. La commissione base è calcolata indipendentemente dal blocco corrente ed è invece determinata dai blocchi che lo precedono, il che rende le commissioni sulle transazioni più prevedibili per gli utenti. Quando il blocco viene creato questa **commissione base viene "bruciata"**, ovvero rimossa dalla circolazione.
+Ogni blocco ha una commissione di base che funge da prezzo di riserva. Per essere idoneo all'inclusione in un blocco, il prezzo offerto per il gas deve essere almeno pari alla commissione di base. La commissione di base è calcolata indipendentemente dal blocco corrente ed è invece determinata dai blocchi precedenti, rendendo le commissioni della transazione più prevedibili per gli utenti. Quando il blocco viene creato, questa **commissione di base viene "bruciata"**, rimuovendola dalla circolazione.
-La commissione di base è calcolata con una formula che confronta le dimensioni del blocco precedente (la quantità di gas usata per tutte le transazioni) con le dimensioni di quello corrente. La commissione base aumenta di un massimo del 12,5% per blocco se la dimensione prevista del blocco viene superata. Questa crescita esponenziale rende economicamente impensabile che la dimensione del blocco resti elevata per un tempo indefinito.
+La commissione di base è calcolata da una formula che confronta la dimensione del blocco precedente (la quantità di gas utilizzata per tutte le transazioni) con la dimensione di destinazione (metà del limite del gas). La commissione di base aumenterà o diminuirà di un massimo del 12,5% per blocco se la dimensione del blocco di destinazione è rispettivamente superiore o inferiore alla destinazione. Questa crescita esponenziale rende economicamente non redditizio che la dimensione del blocco rimanga elevata a tempo indeterminato.
-| Numero del blocco | Gas Incluso | Aumento della commissione | Tariffa base corrente |
-| ----------------- | -----------:| -------------------------:| ---------------------:|
-| 1 | 15M | 0% | 100 gwei |
-| 2 | 30M | 0% | 100 gwei |
-| 3 | 30M | 12,5% | 112,5 gwei |
-| 4 | 30M | 12,5% | 126,6 gwei |
-| 5 | 30M | 12,5% | 142,4 gwei |
-| 6 | 30M | 12,5% | 160,2 gwei |
-| 7 | 30M | 12,5% | 180,2 gwei |
-| 8 | 30M | 12,5% | 202,7 gwei |
+| Numero del Blocco | Gas Incluso | Aumento della Commissione | Commissione di Base Corrente |
+| ----------------- | ----------: | ------------------------: | ---------------------------: |
+| 1 | 18M | 0% | 100 gwei |
+| 2 | 36M | 0% | 100 gwei |
+| 3 | 36M | 12,5% | 112,5 gwei |
+| 4 | 36M | 12,5% | 126,6 gwei |
+| 5 | 36M | 12,5% | 142,4 gwei |
+| 6 | 36M | 12,5% | 160,2 gwei |
+| 7 | 36M | 12,5% | 180,2 gwei |
+| 8 | 36M | 12,5% | 202,7 gwei |
-Secondo la tabella che precede, per creare una transazione sul blocco numero 9, un portafoglio indica all'utente con certezza che la **commissione base massima** da aggiungere al blocco successivo è `current base fee * 112.5%` o `202.7 gwei * 112.5% = 228.1 gwei`.
+Nella tabella sopra, viene dimostrato un esempio utilizzando 36 milioni come limite del gas. Seguendo questo esempio, per creare una transazione sul blocco numero 9, un portafoglio farà sapere all'utente con certezza che la **commissione di base massima** da aggiungere al blocco successivo è `commissione di base corrente * 112,5%` o `202,7 gwei * 112,5% = 228,1 gwei`.
-Inoltre, è importante notare che, vista la velocità con cui la commissione base aumenta mentre si avanza verso un blocco completo, è improbabile assistere a picchi prolungati di blocchi completi.
+È anche importante notare che è improbabile che vedremo picchi prolungati di blocchi pieni a causa della velocità con cui la commissione di base aumenta prima di un blocco pieno.
-| Numero del blocco | Gas Incluso | Aumento della commissione | Tariffa base corrente |
-| ----------------- | -----------:| -------------------------:| ---------------------:|
-| 30 | 30M | 12,5% | 2.705,6 gwei |
-| ... | ... | 12,5% | ... |
-| 50 | 30M | 12,5% | 28.531,3 gwei |
-| ... | ... | 12,5% | ... |
-| 100 | 30M | 12,5% | 10.302.608,6 gwei |
+| Numero del Blocco | Gas Incluso | Aumento della Commissione | Commissione di Base Corrente |
+| ----------------- | ----------: | ------------------------: | ---------------------------: |
+| 30 | 36M | 12,5% | 2705,6 gwei |
+| ... | ... | 12,5% | ... |
+| 50 | 36M | 12,5% | 28531,3 gwei |
+| ... | ... | 12,5% | ... |
+| 100 | 36M | 12,5% | 10302608,6 gwei |
-### Commissione prioritaria (mance) {#priority-fee}
+### Commissione di priorità (mance) {#priority-fee}
-La commissione prioritaria (mancia) incentiva i validatori ad includere una transazione nel blocco. Senza la mancia, i validatori troverebbero economicamente redditizio minare blocchi vuoti, poiché riceverebbero la stessa ricompensa per i blocchi. Mance basse offrono ai validatori un incentivo minimo ad includere una transazione. Affinché le transazioni vengano eseguite in via preferenziale prima di altre transazioni nello stesso blocco, è possibile aggiungere una mancia più alta per cercare di superare le transazioni concorrenti.
+La commissione di priorità (mancia) incentiva i validatori a massimizzare il numero di transazioni in un blocco, limitato solo dal limite del gas del blocco. Senza mance, un validatore razionale potrebbe includere meno transazioni, o persino zero, senza alcuna penalità diretta a livello di esecuzione o a livello di consenso, poiché le ricompense di staking sono indipendenti da quante transazioni ci sono in un blocco. Inoltre, le mance consentono agli utenti di superare le offerte di altri per la priorità all'interno dello stesso blocco, segnalando di fatto l'urgenza.
### Commissione massima {#maxfee}
-Per eseguire una transazione sulla rete, gli utenti possono specificare un limite massimo che sono disposti a pagare affinché la loro transazione venga eseguita. Questo parametro facoltativo è noto come `maxFeePerGas`. Affinché una transazione venga eseguita, la commissione massima deve essere maggiore della somma della commissione base e della mancia. Il mittente della transazione riceve il rimborso della differenza tra la commissione massima e la somma della commissione base e della mancia.
+Per eseguire una transazione sulla rete, gli utenti possono specificare un limite massimo che sono disposti a pagare affinché la loro transazione venga eseguita. Questo parametro opzionale è noto come `maxFeePerGas`. Affinché una transazione venga eseguita, la commissione massima deve superare la somma della commissione di base e della mancia. Al mittente della transazione viene rimborsata la differenza tra la commissione massima e la somma della commissione di base e della mancia.
### Dimensione del blocco {#block-size}
-Ogni blocco ha una dimensione prevista di 30 milioni di gas, ma la dimensione dei blocchi aumenta o diminuisce in base alla domanda della rete, fino al limite massimo di 60 milioni di gas per blocco (2 volte la dimensione prevista del blocco). Il protocollo raggiunge una dimensione del blocco equilibrata di 30 milioni in media tramite il processo di _tâtonnement_. Significa che se la dimensione del blocco supera quella prevista, il protocollo aumenta la commissione base per il blocco successivo. Analogamente, il protocollo riduce la commissione base se la dimensione del blocco è inferiore a quella prevista. L'importo della commissione base si adatta proporzionalmente alla distanza della dimensione del blocco corrente rispetto a quella prevista. [Maggiori informazioni sui blocchi](/developers/docs/blocks/).
+Ogni blocco ha una dimensione di destinazione pari alla metà dell'attuale limite del gas, ma la dimensione dei blocchi aumenterà o diminuirà in base alla domanda della rete, fino al raggiungimento del limite del blocco (2 volte la dimensione del blocco di destinazione). Il protocollo raggiunge una dimensione media del blocco di equilibrio in corrispondenza della destinazione attraverso il processo di _tâtonnement_. Ciò significa che se la dimensione del blocco è maggiore della dimensione del blocco di destinazione, il protocollo aumenterà la commissione di base per il blocco successivo. Allo stesso modo, il protocollo diminuirà la commissione di base se la dimensione del blocco è inferiore alla dimensione del blocco di destinazione.
-### Calcolo delle commissioni del gas in pratica {#calculating-fees-in-practice}
+L'importo di cui viene adeguata la commissione di base è proporzionale a quanto la dimensione del blocco corrente si discosta dalla destinazione. Si tratta di un calcolo lineare dal -12,5% per un blocco vuoto, allo 0% alla dimensione di destinazione, fino al +12,5% per un blocco che raggiunge il limite del gas. Il limite del gas può fluttuare nel tempo in base alle segnalazioni dei validatori, nonché tramite gli aggiornamenti della rete. Puoi [visualizzare le modifiche al limite del gas nel tempo qui](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths).
-Puoi indicare esplicitamente quanto sei disposto a pagare per far eseguire la tua transazione. Tuttavia, la maggior parte dei fornitori di portafogli imposterà automaticamente una commissione sulla transazione consigliata (commissione base + commissione prioritaria consigliata) per ridurre la complessità che grava sui propri utenti.
+[Maggiori informazioni sui blocchi](/developers/docs/blocks/)
+
+### Calcolare le commissioni del gas in pratica {#calculating-fees-in-practice}
+
+Puoi dichiarare esplicitamente quanto sei disposto a pagare per far eseguire la tua transazione. Tuttavia, la maggior parte dei fornitori di portafogli imposterà automaticamente una commissione della transazione consigliata (commissione di base + commissione di priorità consigliata) per ridurre la quantità di complessità a carico dei propri utenti.
## Perché esistono le commissioni del gas? {#why-do-gas-fees-exist}
-In breve, le commissioni del gas aiutano a proteggere la rete di Ethereum. Richiedendo una commissione per ogni calcolo eseguito sulla rete, impediamo agli utenti malevoli di compiere spam sulla rete. Per evitare cicli infiniti accidentali od ostili oppure altri sprechi di calcolo nel codice, ogni transazione deve definire un limite al numero di passaggi di calcolo dell'esecuzione del codice che può utilizzare. L'unità fondamentale di calcolo è il "gas".
+In breve, le commissioni del gas aiutano a mantenere sicura la rete Ethereum. Richiedendo una commissione per ogni calcolo eseguito sulla rete, impediamo ai malintenzionati di inviare spam sulla rete. Al fine di evitare cicli infiniti accidentali o ostili o altri sprechi computazionali nel codice, a ogni transazione è richiesto di impostare un limite a quanti passaggi computazionali di esecuzione del codice può utilizzare. L'unità fondamentale di calcolo è il "gas".
-Sebbene una transazione preveda un limite, tutto il gas non utilizzato in una transazione viene rimborsato all'utente (ciò che viene restituito è: `max fee - (base fee + tip)`).
+Sebbene una transazione includa un limite, qualsiasi gas non utilizzato in una transazione viene restituito all'utente (es., viene restituita la `commissione massima - (commissione di base + mancia)`).
- _Diagramma adattato da [Ethereum EVM illustrato](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-## Cosa è il limite del gas? {#what-is-gas-limit}
+## Cos'è il limite del gas? {#what-is-gas-limit}
-Il limite di gas si riferisce all'importo massimo di gas che sei disposto a consumare in una transazione. Le transazioni più complicate che coinvolgono i [contratti intelligenti](/developers/docs/smart-contracts/), richiedono un maggiore lavoro di calcolo e quindi un limite di gas maggiore rispetto a un semplice pagamento. Un trasferimento standard di ETH richiede un limite di gas di 21.000 unità di gas.
+Il limite del gas si riferisce alla quantità massima di gas che sei disposto a consumare in una transazione. Le transazioni più complicate che coinvolgono [contratti intelligenti](/developers/docs/smart-contracts/) richiedono più lavoro computazionale, quindi richiedono un limite del gas più elevato rispetto a un semplice pagamento. Un trasferimento standard di ETH richiede un limite del gas di 21.000 unità di gas.
-Ad esempio, se imposti un limite di gas di 50.000 per un semplice trasferimento di ETH, l'EVM ne consumerebbe 21.000 unità e restituirebbe le 29.000 rimanenti. Tuttavia, se specifichi troppo poco gas, ad esempio un limite di gas di 20.000 per un semplice trasferimento di ETH, l'EVM consumerà le tue 20.000 unità di gas tentando di soddisfare la transazione, ma non la completerà. A quel punto l'EVM annulla ogni modifica, ma dato che il validatore ha già eseguito un lavoro pari a 20.000 unità di gas, questo gas viene consumato.
+Ad esempio, se inserisci un limite del gas di 50.000 per un semplice trasferimento di ETH, la EVM ne consumerebbe 21.000 e ti verrebbero restituiti i restanti 29.000. Tuttavia, se specifichi troppo poco gas, ad esempio un limite del gas di 20.000 per un semplice trasferimento di ETH, la transazione fallirà durante la fase di convalida. Verrà rifiutata prima di essere inclusa in un blocco e non verrà consumato alcun gas. D'altra parte, se una transazione esaurisce il gas durante l'esecuzione (es., un contratto intelligente esaurisce tutto il gas a metà), la EVM annullerà qualsiasi modifica, ma tutto il gas fornito verrà comunque consumato per il lavoro svolto.
-## Perché le commissioni del gas possono essere così elevate? {#why-can-gas-fees-get-so-high}
+## Perché le commissioni del gas possono diventare così alte? {#why-can-gas-fees-get-so-high}
-Le commissioni del gas elevate sono dovute alla popolarità di Ethereum. Se c'è troppa domanda, gli utenti devono offrire mance più alte per cercare di superare le transazioni degli altri utenti. Una mancia più cospicua può rendere più probabile che la tua transazione troverà posto nel blocco successivo. Inoltre, le applicazioni di contratti intelligenti più complessi potrebbero dover eseguire molte operazioni per supportare le loro funzioni, consumando molto gas.
+Le elevate commissioni del gas sono dovute alla popolarità di Ethereum. Se c'è troppa domanda, gli utenti devono offrire importi di mancia più elevati per cercare di superare le transazioni degli altri utenti. Una mancia più alta può rendere più probabile che la tua transazione entri nel blocco successivo. Inoltre, le app di contratti intelligenti più complesse potrebbero eseguire molte operazioni per supportare le loro funzioni, facendole consumare molto gas.
## Iniziative per ridurre i costi del gas {#initiatives-to-reduce-gas-costs}
-Gli [aggiornamenti di scalabilità](/roadmap/) di Ethereum dovrebbero infine risolvere alcuni problemi delle commissioni del gas, che, a loro volta, consentiranno alla piattaforma di elaborare migliaia di transazioni al secondo e di scalare globalmente.
+Gli aggiornamenti per la [scalabilità](/roadmap/) di Ethereum dovrebbero in definitiva risolvere alcuni dei problemi relativi alle commissioni del gas, il che, a sua volta, consentirà alla piattaforma di elaborare migliaia di transazioni al secondo e di scalare a livello globale.
+
+La scalabilità di livello 2 è un'iniziativa primaria per migliorare notevolmente i costi del gas, l'esperienza utente e la scalabilità.
-Il ridimensionamento del Livello 2 è un'iniziativa fondamentale per migliorare notevolmente i costi del gas, l'esperienza utente e il ridimensionamento. [Maggiori informazioni sul ridimensionamento del Livello 2](/developers/docs/scaling/#layer-2-scaling).
+[Maggiori informazioni sulla scalabilità di livello 2](/developers/docs/scaling/#layer-2-scaling)
-## Monitoraggio delle commissioni del gas {#monitoring-gas-fees}
+## Monitorare le commissioni del gas {#monitoring-gas-fees}
-Se desideri monitorare i prezzi del gas, così da poter inviare i tuoi ETH a un costo inferiore, puoi usare molti strumenti differenti, come:
+Se vuoi monitorare i prezzi del gas, in modo da poter inviare i tuoi ETH a un costo inferiore, puoi utilizzare molti strumenti diversi come:
-- [Etherscan](https://etherscan.io/gastracker): _Strumento di stima del prezzo del gas delle transazioni_
-- [ETH Gas Tracker](https://www.ethgastracker.com/): _Monitora e traccia i prezzi di Ethereum e del L2 per ridurre le commissioni sulle transazioni e risparmiare denaro_
-- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm): _Estensione di stima del gas di Chrome che supporta sia transazioni ereditarie di Tipo 0 che transazioni EIP-1559 di Tipo 2._
-- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _Calcola le commissioni del gas nella tua valuta locale per diversi tipi di transazione sulla rete principale, su Arbitrum e su Polygon._
+- [Etherscan](https://etherscan.io/gastracker) _Stimatore del prezzo del gas delle transazioni_
+- [Blockscout](https://eth.blockscout.com/gas-tracker) _Stimatore open source del prezzo del gas delle transazioni_
+- [ETH Gas Tracker](https://www.ethgastracker.com/) _Monitora e traccia i prezzi del gas di Ethereum e dei L2 per ridurre le commissioni delle transazioni e risparmiare denaro_
+- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Estensione di Chrome per la stima del gas che supporta sia le transazioni legacy di Tipo 0 che le transazioni EIP-1559 di Tipo 2._
+- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _Calcola le commissioni del gas nella tua valuta locale per diversi tipi di transazioni sulla rete principale, Arbitrum e Polygon._
## Strumenti correlati {#related-tools}
-- [Blocknative's Gas Platform](https://www.blocknative.com/gas): _API di stima del gas sviluppata dalla piattaforma di dati della mempool globale di Blocknative_
+- [Piattaforma Gas di Blocknative](https://www.blocknative.com/gas) _API di stima del gas basata sulla piattaforma globale di dati mempool di Blocknative_
+- [Gas Network](https://gas.network) Oracoli del gas on-chain. Supporto per oltre 35 catene.
## Letture consigliate {#further-reading}
-- [Spiegazione del Gas di Ethereum](https://defiprime.com/gas)
-- [Ridurre il consumo di gas dei tuoi Contratti Intelligenti](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
-- [Strategie di ottimizzazione del carburante per sviluppatori](https://www.alchemy.com/overviews/solidity-gas-optimization)
-- [Documenti di EIP-1559](https://eips.ethereum.org/EIPS/eip-1559).
-- [Risorse dell'EIP-1559 di Tim Beiko](https://hackmd.io/@timbeiko/1559-resources).
+- [Spiegazione del gas di Ethereum](https://defiprime.com/gas)
+- [Ridurre il consumo di gas dei tuoi contratti intelligenti](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a)
+- [Strategie di ottimizzazione del gas per gli sviluppatori](https://www.alchemy.com/overviews/solidity-gas-optimization)
+- [Documentazione EIP-1559](https://eips.ethereum.org/EIPS/eip-1559).
+- [Risorse EIP-1559 di Tim Beiko](https://hackmd.io/@timbeiko/1559-resources)
+- [EIP-1559: Separare i meccanismi dai meme](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/ides/index.md b/public/content/translations/it/developers/docs/ides/index.md
index e0185be02fd..ca39b5bf7b8 100644
--- a/public/content/translations/it/developers/docs/ides/index.md
+++ b/public/content/translations/it/developers/docs/ides/index.md
@@ -1,38 +1,38 @@
---
-title: Ambienti di sviluppo integrati (IDE)
-description:
+title: Ambienti di Sviluppo Integrati (IDE)
+description: "Scopri gli IDE basati sul web e desktop per lo sviluppo su Ethereum, inclusi Remix, VS Code e i plugin più popolari."
lang: it
---
-Quando si tratta di configurare un [ambiente di sviluppo integrato (IDE)](https://wikipedia.org/wiki/Integrated_development_environment), la programmazione delle applicazioni su Ethereum è simile alla programmazione di qualsiasi altro progetto software. Ci sono molte opzioni tra cui scegliere, quindi in fin dei conti, seleziona l'IDE o l'editor di codice che più si adegua alle tue preferenze. Più probabilmente, la migliore scelta di IDE per il tuo sviluppo in Ethereum è l'IDE che usi già per lo sviluppo software tradizionale.
+Quando si tratta di configurare un [ambiente di sviluppo integrato (IDE)](https://wikipedia.org/wiki/Integrated_development_environment), programmare applicazioni su Ethereum è simile a programmare qualsiasi altro progetto software. Ci sono molte opzioni tra cui scegliere, quindi, alla fine, scegli l'IDE o l'editor di codice che meglio si adatta alle tue preferenze. Molto probabilmente la scelta migliore di un IDE per il tuo sviluppo su Ethereum è l'IDE che usi già per lo sviluppo software tradizionale.
-## IDE basato su Web {#web-based-ides}
+## IDE basati sul web {#web-based-ides}
-Se desideri provare a scrivere del codice prima di [configurare un ambiente di sviluppo locale](/developers/local-environment/), queste app web sono personalizzate per lo sviluppo di contratti intelligenti di Ethereum.
+Se stai cercando di armeggiare con il codice prima di [configurare un ambiente di sviluppo locale](/developers/local-environment/), queste app web sono create appositamente per lo sviluppo di contratti intelligenti su Ethereum.
-**[Remix](https://remix.ethereum.org/)**: **_IDE basato sul web che integra analisi statica e una macchina virtuale per una blockchain di prova_**
+**[Remix](https://remix.ethereum.org/)** - **_IDE basato sul web con analisi statica integrata e una macchina virtuale blockchain di test_**
- [Documentazione](https://remix-ide.readthedocs.io/en/latest/#)
- [Gitter](https://gitter.im/ethereum/remix)
-**[ChainIDE](https://chainide.com/)**: **_un IDE multi-catena basato su cloud_**
+**[ChainIDE](https://chainide.com/)** - **_Un IDE multi-chain basato sul cloud_**
- [Documentazione](https://chainide.gitbook.io/chainide-english-1/)
- [Forum di supporto](https://forum.chainide.com/)
-**[Replit (Solidity Starter - Beta) ](https://replit.com/@replit/Solidity-starter-beta)** - **_Un ambiente di sviluppo personalizzabile per Ethereum con ricarica rapida, controllo degli errori e supporto della rete di prova di prima classe_**
+**[Replit (Solidity Starter - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_Un ambiente di sviluppo personalizzabile per Ethereum con ricaricamento a caldo, controllo degli errori e supporto di prim'ordine per le reti di test_**
-- [Docs](https://docs.replit.com/)
+- [Documentazione](https://docs.replit.com/)
-**[Tenderly Sandbox](https://sandbox.tenderly.co/)**: **_un ambiente di prototipazione veloce è possibile scrivere, eseguire ed effettuare il debug dei contratti intelligenti nel browser usando Solidity e JavaScript_**
+**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_Un ambiente di prototipazione rapida in cui puoi scrivere, eseguire ed effettuare il debug di contratti intelligenti nel browser usando Solidity e JavaScript_**
-**[EthFiddle](https://ethfiddle.com/)**: **_IDE basato sul web che consente di scrivere, compilare ed eseguire il debug del tuo contratto intelligente_**
+**[EthFiddle](https://ethfiddle.com/)** - **_IDE basato sul web che ti consente di scrivere, compilare ed effettuare il debug del tuo contratto intelligente_**
- [Gitter](https://gitter.im/loomnetwork/ethfiddle)
## IDE desktop {#desktop-ides}
-Gli IDE più diffusi hanno plugin integrati che migliorano l'esperienza di sviluppo per Ethereum. Come minimo, offrono l'evidenziazione della sintassi per i [linguaggi dei contratti intelligenti](/developers/docs/smart-contracts/languages/).
+La maggior parte degli IDE consolidati ha creato plugin per migliorare l'esperienza di sviluppo su Ethereum. Come minimo, forniscono l'evidenziazione della sintassi per i [linguaggi dei contratti intelligenti](/developers/docs/smart-contracts/languages/).
**Visual Studio Code -** **_IDE multipiattaforma professionale con supporto ufficiale per Ethereum_**
@@ -40,25 +40,25 @@ Gli IDE più diffusi hanno plugin integrati che migliorano l'esperienza di svilu
- [Esempi di codice](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md)
- [GitHub](https://github.com/microsoft/vscode)
-**JetBrains IDEs (IntelliJ IDEA, ecc.) -** **_Strumenti essenziali per sviluppatori di software e team_**
+**IDE JetBrains (IntelliJ IDEA, ecc.) -** **_Strumenti essenziali per sviluppatori di software e team_**
- [JetBrains](https://www.jetbrains.com/)
- [GitHub](https://github.com/JetBrains)
- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/)
-**Remix Desktop -** **_Sperimenta Remix IDE sulla tua macchina locale_**
+**Remix Desktop -** **_Prova l'IDE Remix sulla tua macchina locale_**
- [Download](https://github.com/ethereum/remix-desktop/releases)
- [GitHub](https://github.com/ethereum/remix-desktop)
## Plugin ed estensioni {#plugins-extensions}
-- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Ethereum Solidity Language per Visual Studio Code
-- [Solidity + Hardhat per VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - Supporto Solidity e Hardhat fornito da Hardhat team
-- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - Formattatore di codice basato su Prettier
+- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) - Linguaggio Solidity di Ethereum per Visual Studio Code
+- [Solidity + Hardhat per VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) - Supporto per Solidity e Hardhat dal team di Hardhat
+- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) - Formattatore di codice che utilizza prettier
## Letture consigliate {#further-reading}
-- [IDE di Ethereum](https://www.alchemy.com/list-of/web3-ides-on-ethereum)_- Lista degli IDE di Ethereum di Alchemy_
+- [IDE per Ethereum](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _- L'elenco di Alchemy degli IDE per Ethereum_
-_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/index.md b/public/content/translations/it/developers/docs/index.md
index c96dd311f44..1a66430000d 100644
--- a/public/content/translations/it/developers/docs/index.md
+++ b/public/content/translations/it/developers/docs/index.md
@@ -1,16 +1,16 @@
---
-title: Documentazione sullo sviluppo di Ethereum
-description: Presentazione della documentazione di sviluppo per ethereum.org.
+title: Documentazione per lo sviluppo su Ethereum
+description: Introduzione alla documentazione per sviluppatori di ethereum.org.
lang: it
---
-Questa documentazione è progettata per aiutarti a creare con Ethereum. Tratta Ethereum come un concetto, spiega lo stack tecnologico di Ethereum e documenta argomenti avanzati per applicazioni e casi d'uso più complessi.
+Questa documentazione è progettata per aiutarti a sviluppare con [Ethereum](/). Tratta Ethereum come concetto, spiega lo stack tecnologico di Ethereum e documenta argomenti avanzati per applicazioni e casi d'uso più complessi.
-Questa è uno sforzo della community open source, quindi sentiti libero di suggerire nuovi argomenti, aggiungere contenuti e fornire esempi laddove pensi potrebbero essere utili. Tutta la documentazione è modificabile tramite GitHub – se se insicuro su come fare, [segui queste istruzioni](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md).
+Questo è uno sforzo open-source della community, quindi sentiti libero di suggerire nuovi argomenti, aggiungere nuovi contenuti e fornire esempi ovunque pensi possa essere utile. Tutta la documentazione può essere modificata tramite GitHub: se non sei sicuro di come fare, [segui queste istruzioni](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md).
## Moduli di sviluppo {#development-modules}
-Se questo è il tuo primo tentativo di sviluppo su Ethereum, consigliamo di cominciare dall'inizio e farsi strada come fosse un libro.
+Se questo è il tuo primo tentativo di sviluppo su Ethereum, ti consigliamo di iniziare dall'inizio e procedere come se stessi leggendo un libro.
### Argomenti fondamentali {#foundational-topics}
@@ -22,4 +22,4 @@ Se questo è il tuo primo tentativo di sviluppo su Ethereum, consigliamo di comi
### Avanzato {#advanced}
-@:"
```
-## Eseguire un nodo d'avvio {#run-a-bootnode}
+## Eseguire un bootnode {#run-a-bootnode}
-I nodi d'avvio sono nodi completi non posti dietro una NAT ([Traduzione dell'indirizzo di rete](https://www.geeksforgeeks.org/network-address-translation-nat/)). Ogni nodo completo può agire da nodo d'avvio a condizione che sia pubblicamente disponibile.
+I bootnode sono nodi completi che non si trovano dietro a un NAT ([Network Address Translation](https://www.geeksforgeeks.org/network-address-translation-nat/)). Ogni nodo completo può fungere da bootnode purché sia disponibile pubblicamente.
-Quando avvii un nodo, dovrebbe registrare il tuo [enode](/developers/docs/networking-layer/network-addresses/#enode), un identificativo pubblico utilizzabile dagli altri per connettersi al tuo nodo.
+Quando avvii un nodo, dovrebbe registrare il tuo [enode](/developers/docs/networking-layer/network-addresses/#enode), che è un identificatore pubblico che altri possono usare per connettersi al tuo nodo.
-L'enode è solitamente rigenerato a ogni riavvio, quindi assicurati di consultare la documentazione del tuo client su come generare un enode persistente per il tuo nodo d'avvio.
+L'enode viene solitamente rigenerato a ogni riavvio, quindi assicurati di consultare la documentazione del tuo client su come generare un enode persistente per il tuo bootnode.
-Per poter essere un buon nodo d'avvio è una buona idea incrementare il numero massimo di pari che possono connettersi a esso. L'esecuzione di un nodo d'avvio con molti peer aumenterà in modo significativo i requisiti di larghezza di banda.
+Per essere un buon bootnode, è una buona idea aumentare il numero massimo di peer che possono connettersi ad esso. Eseguire un bootnode con molti peer aumenterà significativamente il requisito di larghezza di banda.
-## Nodi d'avvio disponibili {#available-bootnodes}
+## Bootnode disponibili {#available-bootnodes}
-Un elenco di nodi d'avvio integrati in go-ethereum si può trovare [qui](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Questi nodi d'avvio sono mantenuti dalla Ethereum Foundation e dal team di go-ethereum.
+Un elenco di bootnode integrati in go-ethereum può essere trovato [qui](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Questi bootnode sono mantenuti dalla Ethereum Foundation e dal team di go-ethereum.
-Sono disponibili altri elenchi di nodi d'avvio tenuti da volontari. Assicurati di includere sempre almeno un nodo d'avvio ufficiale, altrimenti potresti subire un attacco eclipse.
+Sono disponibili altri elenchi di bootnode mantenuti da volontari. Assicurati di includere sempre almeno un bootnode ufficiale, altrimenti potresti subire un attacco eclipse.
\ No newline at end of file
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..5740950f22b 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,96 +1,117 @@
---
-title: Diversità dei client
-description: Una spiegazione generica dell'importanza della diversità di client di Ethereum.
+title: "Diversità dei client"
+description: "Una spiegazione ad alto livello dell'importanza della diversità dei client di Ethereum."
lang: it
sidebarDepth: 2
---
-Il comportamento di un nodo di Ethereum è controllato dal software del client che esegue. Esistono diversi client di Ethereum di livello di produzione, ognuno sviluppato e mantenuto in diversi linguaggi da team distinti. I client sono costruiti su specifiche comuni che assicurano che i client comunichino senza problemi tra loro e abbiano le stesse funzionalità, fornendo un'esperienza utente equivalente. Tuttavia, al momento, la distribuzione dei client tra i nodi non è abbastanza equilibrata da realizzare in tutta la sua potenzialità questa fortificazione della rete. Idealmente, gli utenti dovrebbero dividersi approssimativamente in modo equo tra i vari client, per portare quanta più diversità dei client possibile alla rete.
+Il comportamento di un nodo di [Ethereum](/) è controllato dal software del client che esegue. Esistono diversi client di Ethereum a livello di produzione, ognuno sviluppato e mantenuto in linguaggi diversi da team separati. I client sono costruiti secondo una specifica comune che garantisce che comunichino tra loro senza problemi, abbiano le stesse funzionalità e forniscano un'esperienza utente equivalente. Tuttavia, al momento la distribuzione dei client tra i nodi non è abbastanza equa da realizzare questa fortificazione della rete al suo pieno potenziale. Idealmente, gli utenti si dividono in modo approssimativamente uguale tra i vari client per portare quanta più diversità dei client possibile alla rete.
## Prerequisiti {#prerequisites}
-Se ancora non sai cosa sono i nodi e i client, dai un'occhiata a [nodi e client](/developers/docs/nodes-and-clients/). I livelli di [esecuzione](/glossary/#execution-layer) e [consenso](/glossary/#consensus-layer) sono definiti nel glossario.
+Se non capisci ancora cosa siano i nodi e i client, dai un'occhiata a [nodi e client](/developers/docs/nodes-and-clients/). I livelli di [esecuzione](/glossary/#execution-layer) e [consenso](/glossary/#consensus-layer) sono definiti nel glossario.
-## Perché esistono diversi client? {#why-multiple-clients}
+## Perché ci sono più client? {#why-multiple-clients}
-Esistono diversi client sviluppati e mantenuti indipendentemente perché la diversità dei client rende la rete più resistente ad attacchi e bug. Diversi client sono una forza unica per Ethereum, mentre altre blockchain si affidano all'infallibilità di un singolo client. Tuttavia, non basta avere semplicemente diversi client disponibili, devono essere adottati dalla community e i nodi attivi totali devono essere distribuiti in modo relativamente uniforme tra loro.
+Esistono più client sviluppati e mantenuti in modo indipendente perché la diversità dei client rende la rete più resiliente ad attacchi e bug. Avere più client è un punto di forza unico di Ethereum: altre blockchain si affidano all'infallibilità di un singolo client. Tuttavia, non è sufficiente avere semplicemente più client disponibili, devono essere adottati dalla community e i nodi attivi totali devono essere distribuiti in modo relativamente uniforme tra di essi.
## Perché la diversità dei client è importante? {#client-diversity-importance}
-Avere molti client sviluppati e mantenuti indipendentemente è vitale per l'integrità di una rete decentralizzata. Vediamo perché.
+Avere molti client sviluppati e mantenuti in modo indipendente è vitale per la salute di una rete decentralizzata. Esploriamone i motivi.
### Bug {#bugs}
-Un bug in un singolo client rappresenta un pericolo minore per la rete se rappresenta una minoranza di nodi di Ethereum. Con una distribuzione approssimativamente uniforme dei nodi tra molti client, la probabilità che gran parte dei client soffra di un problema comune è minima e, di conseguenza, la rete è più robusta.
+Un bug in un singolo client rappresenta un rischio minore per la rete quando rappresenta una minoranza dei nodi di Ethereum. Con una distribuzione approssimativamente uniforme dei nodi tra molti client, la probabilità che la maggior parte dei client soffra di un problema condiviso è piccola e, di conseguenza, la rete è più robusta.
-### Resistenza agli attacchi {#resilience}
+### Resilienza agli attacchi {#resilience}
-La diversità dei client offre anche resistenza agli attacchi. Ad esempio, un attacco che [inganna un client specifico](https://twitter.com/vdWijden/status/1437712249926393858) su un ramo particolare della catena, difficilmente riuscirà nel suo intento perché non è probabile che anche gli altri client siano vulnerabili allo stesso modo, e la catena canonica non viene quindi corrotta. Una bassa diversità dei client aumenta i rischi associati a un attacco sul client dominante. È stato dimostrato che la diversità dei client è una difesa importante contro gli attacchi malevoli sulla rete, ad esempio, l'attacco di denial of service di Shanghai nel 2016 è stato possibile perché gli utenti malevoli sono riusciti a ingannare il client dominante (Geth) facendogli eseguire un'operazione lenta di I/O su disco decine di migliaia di volte per blocco. Poiché online erano presenti anche altri client alternativi che non avevano la stessa vulnerabilità, Ethereum è riuscita a resistere all'attacco e a continuare a funzionare mentre veniva risolta la vulnerabilità di Geth.
+La diversità dei client offre anche resilienza agli attacchi. Ad esempio, un attacco che [inganna un particolare client](https://twitter.com/vdWijden/status/1437712249926393858) su un particolare ramo della catena è improbabile che abbia successo perché è improbabile che altri client siano sfruttabili allo stesso modo e la catena canonica rimane incorrotta. Una bassa diversità dei client aumenta il rischio associato a un hack sul client dominante. La diversità dei client si è già dimostrata un'importante difesa contro gli attacchi dannosi alla rete, ad esempio l'attacco denial-of-service di Shanghai nel 2016 è stato possibile perché gli aggressori sono stati in grado di ingannare il client dominante (Geth) facendogli eseguire una lenta operazione di I/O su disco decine di migliaia di volte per blocco. Poiché erano online anche client alternativi che non condividevano la vulnerabilità, Ethereum è stato in grado di resistere all'attacco e continuare a operare mentre la vulnerabilità in Geth veniva risolta.
-### Finalità del proof-of-stake {#finality}
+### Finalità della prova di stake {#finality}
-Un bug in un client di consenso con oltre il 33% dei nodi di Ethereum potrebbe impedire la finalizzazione del livello di consenso, il che significa che gli utenti non possono essere sicuri che le transazioni non vengano annullate o modificate ad un certo punto. Questo sarebbe molto problematico per molte delle app basate su Ethereum, in particolare, le DeFi.
+Un bug in un client di consenso con oltre il 33% dei nodi di Ethereum potrebbe impedire al livello di consenso di raggiungere la finalità, il che significa che gli utenti non potrebbero fidarsi del fatto che le transazioni non vengano annullate o modificate a un certo punto. Questo sarebbe molto problematico per molte delle app costruite su Ethereum, in particolare per la DeFi.
-) è un concetto della teoria dei giochi che presuppone che più entità adotteranno sempre una soluzione comune a un problema in assenza di qualsiasi comunicazione. I meccanismi del punto di Schelling sono spesso utilizzati nelle reti di oracoli decentralizzate per consentire ai nodi di raggiungere il consenso sulle risposte alle richieste di dati.
-Una prima idea a riguardo è stato [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed) un feed di dati proposto in cui i partecipanti inviano risposte a domande "scalari" (domande le cui risposte sono descritte da una grandezza, ad esempio "qual è il prezzo di ETH?"), insieme a un deposito. Gli utenti che forniscono valori compresi tra il 25° e il 75° [percentile](https://en.wikipedia.org/wiki/Percentile) vengono premiati, mentre quelli i cui valori si discostano ampiamente dal valore mediano vengono penalizzati.
+Una prima idea per questo è stata [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed), un feed di dati proposto in cui i partecipanti inviano risposte a domande "scalari" (domande le cui risposte sono descritte da una grandezza, ad es., "qual è il prezzo di ETH?"), insieme a un deposito. Gli utenti che forniscono valori compresi tra il 25° e il 75° [percentile](https://en.wikipedia.org/wiki/Percentile) vengono ricompensati, mentre quelli i cui valori si discostano ampiamente dal valore mediano vengono penalizzati.
-Sebbene SchellingCoin oggi non esista, alcuni oracoli decentralizzati, diversi oracoli decentralizzati – in particolare gli [oracoli del Protocollo Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module) – utilizzano il meccanismo del punto di Schelling per migliorare la precisione dei dati dell'oracolo. Ogni Oracolo Maker consiste in una rete P2P off-chain di nodi ("relayer" e "feed") che inviano i prezzi di mercato per le risorse collaterali e un contratto "Medianizer" on-chain che calcola la mediana di tutti i valori forniti. Una volta terminato il periodo di ritardo specificato, questo valore mediano diventa il nuovo prezzo di riferimento per la risorsa associata.
+Sebbene SchellingCoin non esista oggi, un certo numero di oracoli decentralizzati — in particolare gli [Oracoli del Protocollo Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module) — utilizzano il meccanismo del punto di Schelling per migliorare l'accuratezza dei dati dell'oracolo. Ogni Oracolo Maker è costituito da una rete P2P fuori catena di nodi ("relayer" e "feed") che inviano i prezzi di mercato per gli asset collaterali e da un contratto "Medianizer" on-chain che calcola la mediana di tutti i valori forniti. Una volta terminato il periodo di ritardo specificato, questo valore mediano diventa il nuovo prezzo di riferimento per l'asset associato.
-Altri esempi di oracoli che utilizzano meccanismi del punto di Schelling sono [Chainlink Off-Chain Reporting](https://docs.chain.link/docs/off-chain-reporting/) e [Witnet](https://witnet.io/). In entrambi i sistemi, le risposte dei nodi oracolo nella rete peer-to-peer vengono aggregate in un unico valore, come la media o la mediana. I nodi vengono premiati o sanzionati in base alla misura in cui le loro risposte si allineano o si discostano dal valore aggregato.
+Altri esempi di oracoli che utilizzano meccanismi del punto di Schelling includono [Chainlink Offchain Reporting](https://docs.chain.link/architecture-overview/off-chain-reporting) e [Witnet](https://witnet.io/). In entrambi i sistemi, le risposte dei nodi oracolo nella rete peer-to-peer vengono aggregate in un singolo valore aggregato, come una media o una mediana. I nodi vengono ricompensati o puniti in base alla misura in cui le loro risposte si allineano o si discostano dal valore aggregato.
-I meccanismi del punto di Schelling sono interessanti perché riducono al minimo lo spazio occupato on-chain (è necessario inviare una sola transazione) garantendo al contempo la decentralizzazione. Questa è possibile perché i nodi devono approvare l'elenco delle risposte inviate prima che questo venga inserito nell'algoritmo che produce il valore medio/mediano.
+I meccanismi del punto di Schelling sono attraenti perché riducono al minimo l'impronta on-chain (deve essere inviata solo una transazione) garantendo al contempo la decentralizzazione. Quest'ultima è possibile perché i nodi devono firmare l'elenco delle risposte inviate prima che venga inserito nell'algoritmo che produce il valore medio/mediano.
### Disponibilità {#availability}
-I servizi oracolo decentralizzati garantiscono un'elevata disponibilità di dati off-chain per i contratti intelligenti. Ciò si ottiene decentralizzando sia la fonte delle informazioni off-chain sia i nodi responsabili del trasferimento delle informazioni on-chain.
+I servizi di oracolo decentralizzati garantiscono un'elevata disponibilità di dati fuori catena ai contratti intelligenti. Ciò si ottiene decentralizzando sia la fonte delle informazioni fuori catena sia i nodi responsabili del trasferimento delle informazioni on-chain.
-Questo garantisce la tolleranza ai guasti, perché il contratto oracolo può affidarsi a più nodi (che si affidano anche a più fonti di dati) per eseguire interrogazioni da altri contratti. La decentralizzazione a livello sorgente _e_ di operatore del nodo è fondamentale: una rete di nodi oracolo che servono informazioni recuperate dalla stessa fonte incorrerà nello stesso problema di un oracolo centralizzato.
+Ciò garantisce la tolleranza ai guasti poiché il contratto dell'oracolo può fare affidamento su più nodi (che a loro volta si affidano a più fonti di dati) per eseguire query da altri contratti. La decentralizzazione alla fonte _e_ a livello di operatore del nodo è cruciale: una rete di nodi oracolo che serve informazioni recuperate dalla stessa fonte incorrerà nello stesso problema di un oracolo centralizzato.
-È anche possibile che gli oracoli basati sullo staking possano tagliare gli operatori dei nodi che non rispondono rapidamente alle richieste di dati. Questo incentiva in modo significativo i nodi oracolo a investire nell'infrastruttura tollerante ai guasti e a fornire i dati in modo tempestivo.
+È anche possibile per gli oracoli basati sullo staking punire gli operatori dei nodi che non rispondono rapidamente alle richieste di dati. Ciò incentiva in modo significativo i nodi oracolo a investire in infrastrutture tolleranti ai guasti e a fornire dati in modo tempestivo.
-### Buona compatibilità con gli incentivi {#good-incentive-compatibility}
+### Buona compatibilità degli incentivi {#good-incentive-compatibility}
-Gli oracoli decentralizzati implementano svariati modelli di incentivi per prevenire il comportamento [bizantino](https://en.wikipedia.org/wiki/Byzantine_fault) tra i nodi dell'oracolo. In particolare, ottengono _attribuibilità_ e _responsabilità_:
+Gli oracoli decentralizzati implementano vari modelli di incentivi per prevenire comportamenti [bizantini](https://en.wikipedia.org/wiki/Byzantine_fault) tra i nodi oracolo. Nello specifico, ottengono _attribuibilità_ e _responsabilità_:
-1. Ai nodi oracolo decentralizzati viene spesso richiesto di firmare i dati che forniscono in risposta alle richieste di dati. Queste informazioni aiutano a valutare le prestazioni storiche dei nodi oracolo, in modo che gli utenti possano filtrare i nodi oracolo inaffidabili quando effettuano richieste di dati. Un esempio è il [sistema algoritmico di reputazione](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) di Witnet.
+1. Ai nodi oracolo decentralizzati è spesso richiesto di firmare i dati che forniscono in risposta alle richieste di dati. Queste informazioni aiutano a valutare le prestazioni storiche dei nodi oracolo, in modo che gli utenti possano filtrare i nodi oracolo inaffidabili quando effettuano richieste di dati. Un esempio è il [Sistema di Reputazione Algoritmica](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) di Witnet.
-2. Gli oracoli decentralizzati, come spiegato in precedenza, possono richiedere ai nodi di mettere token in staking per garantire la veridicità dei dati inviati. Se i dati vengono confermati, lo stake può essere restituito insieme ai premi per il servizio onesto. Ma può anche essere tagliato nel caso in cui le informazioni non siano corrette, il che fornisce un certo grado di responsabilità.
+2. Gli oracoli decentralizzati — come spiegato in precedenza — possono richiedere ai nodi di piazzare uno stake sulla loro fiducia nella veridicità dei dati che inviano. Se l'affermazione risulta corretta, questo stake può essere restituito insieme a ricompense per il servizio onesto. Ma può anche essere punito nel caso in cui le informazioni siano errate, il che fornisce una certa misura di responsabilità.
## Applicazioni degli oracoli nei contratti intelligenti {#applications-of-oracles-in-smart-contracts}
I seguenti sono casi d'uso comuni per gli oracoli in Ethereum:
-### Recupero dei dati finanziari {#retrieving-financial-data}
+### Recupero di dati finanziari {#retrieving-financial-data}
-Le applicazioni di [finanza decentralizzata](/defi/) (DeFi) consentono di concedere e ricevere prestiti e scambiare risorse peer-to-peer. Questo spesso impone di ottenere diverse informazioni finanziarie, tra cui i dati sui tassi di cambio (per calcolare il valore in moneta legale delle criptovalute o per confrontare i prezzi dei token) e i dati sui mercati dei capitali (per calcolare il valore delle risorse tokenizzate, come l'oro o il dollaro USA).
+Le applicazioni di [finanza decentralizzata](/defi/) (DeFi) consentono il prestito, l'indebitamento e il trading di asset peer-to-peer. Ciò richiede spesso l'ottenimento di diverse informazioni finanziarie, inclusi i dati sui tassi di cambio (per calcolare il valore fiat delle criptovalute o confrontare i prezzi dei token) e i dati dei mercati dei capitali (per calcolare il valore degli asset tokenizzati, come l'oro o il dollaro USA).
-Un protocollo di prestito DeFi, ad esempio, deve poter interrogare i prezzi di mercato correnti per le risorse (es. ETH) depositate come garanzia. Ciò consente al contratto di determinare il valore delle risorse collaterali e di determinare quanto può prendere in prestito dal sistema.
+Un protocollo di prestito DeFi, ad esempio, deve interrogare i prezzi di mercato attuali per gli asset (ad es., ETH) depositati come garanzia. Ciò consente al contratto di determinare il valore degli asset collaterali e determinare quanto può prendere in prestito dal sistema.
-Gli “oracoli di prezzo” popolari (come sono spesso chiamati) nella DeFi includono Chainlink Price Feeds, [Open Price Feed](https://compound.finance/docs/prices) di Compound Protocol, [Time-Weighted Average Prices (TWAP)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) di Uniswap e [Oracoli Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module).
+I popolari "oracoli di prezzo" (come vengono spesso chiamati) nella DeFi includono i Chainlink Price Feeds, l'[Open Price Feed](https://compound.finance/docs/prices) del Protocollo Compound, i [Time-Weighted Average Prices (TWAP)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) di Uniswap e i [Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module).
-I costruttori dovrebbero comprendere le avvertenze che accompagnano questi oracoli dei prezzi prima di integrarli nel proprio progetto. Questo [articolo](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) fornisce un'analisi dettagliata degli aspetti da considerare quando si intende utilizzare uno degli oracoli di prezzo citati.
+I costruttori dovrebbero comprendere le avvertenze che derivano da questi oracoli di prezzo prima di integrarli nel loro progetto. Questo [articolo](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) fornisce un'analisi dettagliata di cosa considerare quando si pianifica di utilizzare uno qualsiasi degli oracoli di prezzo menzionati.
-Di seguito è riportato un esempio di come recuperare l'ultimo prezzo dell'ETH nel proprio contratto intelligente utilizzando un feed di prezzo di Chainlink:
+Di seguito è riportato un esempio di come puoi recuperare l'ultimo prezzo di ETH nel tuo contratto intelligente utilizzando un feed di prezzo Chainlink:
```solidity
pragma solidity ^0.6.7;
@@ -329,18 +329,24 @@ contract PriceConsumerV3 {
AggregatorV3Interface internal priceFeed;
- /**
- * Network: Kovan
- * Aggregator: ETH/USD
- * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331
- */
+ /* *
+ * Rete: Kovan
+ * Aggregatore: ETH/USD
+ * Indirizzo: 0x9326BFA02ADD2366b30bacB125260Af641031331 */
+
+
+
+
+
constructor() public {
priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331);
}
- /**
- * Returns the latest price
- */
+ /* *
+ * Restituisce l'ultimo prezzo */
+
+
+
function getLatestPrice() public view returns (int) {
(
uint80 roundID,
@@ -354,77 +360,84 @@ contract PriceConsumerV3 {
}
```
-### Generare casualità verificabile {#generating-verifiable-randomness}
+### Generazione di casualità verificabile {#generating-verifiable-randomness}
-Alcune applicazioni della blockchain, come i giochi o le lotterie basate su blockchain, richiedono un alto livello di imprevedibilità e casualità per funzionare efficacemente. Tuttavia, l'esecuzione deterministica delle blockchain elimina la casualità.
+Alcune applicazioni blockchain, come i giochi basati su blockchain o i sistemi di lotteria, richiedono un alto livello di imprevedibilità e casualità per funzionare in modo efficace. Tuttavia, l'esecuzione deterministica delle blockchain elimina la casualità.
-L'approcio originale consisteva nell'utilizzare una funzione crittografica pseudocasuale, come ad esempio `blockhash`, ma questa era suscettibile di [manipolazioni da parte dei minatori](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) che risolvevano l'algoritmo di proof-of-work. Inoltre il [passaggio al proof-of-stake](/roadmap/merge/) di Ethereum fa sì che gli sviluppatori non possano più affidarsi al `blockhash` per la casualità on-chain. Il [meccanismo RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) della Beacon Chain fornisce invece una fonte alternativa di casualità.
+L'approccio originale era quello di utilizzare funzioni crittografiche pseudocasuali, come `blockhash`, ma queste potevano essere [manipolate dai miner](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) che risolvevano l'algoritmo di prova di lavoro. Inoltre, il [passaggio di Ethereum alla prova di stake](/roadmap/merge/) significa che gli sviluppatori non possono più fare affidamento su `blockhash` per la casualità on-chain. Il [meccanismo RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) della beacon chain fornisce invece una fonte alternativa di casualità.
-È possibile generare il valore casuale off-chain e inviarlo sulla catena, ma ciò impone agli utenti requisiti di fiducia elevati. Devono credere che il valore sia stato realmente generato attraverso meccanismi imprevedibili e non sia stato alterato in transito.
+È possibile generare il valore casuale fuori catena e inviarlo on-chain, ma farlo impone elevati requisiti di fiducia agli utenti. Devono credere che il valore sia stato veramente generato tramite meccanismi imprevedibili e non sia stato alterato durante il transito.
-Gli oracoli progettati per il calcolo off-chain risolvono questo problema generando in modo sicuro risultati casuali fuori catena che trasmettono sulla catena insieme a prove crittografiche che attestano l'imprevedibilità del processo. Un esempio è [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (Verifiable Random Function), che è un generatore di numeri casuali (RNG) dimostrabilmente equo e a prova di manomissione, utile per costruire contratti intelligenti affidabili per applicazioni che si basano su risultati imprevedibili.
+Gli oracoli progettati per il calcolo fuori catena risolvono questo problema generando in modo sicuro risultati casuali fuori catena che trasmettono on-chain insieme a prove crittografiche che attestano l'imprevedibilità del processo. Un esempio è [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (Verifiable Random Function), che è un generatore di numeri casuali (RNG) dimostrabilmente equo e a prova di manomissione utile per costruire contratti intelligenti affidabili per applicazioni che si basano su risultati imprevedibili.
### Ottenere risultati per gli eventi {#getting-outcomes-for-events}
-Con gli oracoli, la creazione di contratti intelligenti che rispondono a eventi del mondo reale è facile. I servizi oracolo lo rendono possibile consentendo ai contratti di connettersi ad API esterne attraverso componenti off-chain e di consumare informazioni da tali fonti di dati. Ad esempio, la dapp predittiva menzionata in precedenza può richiedere a un oracolo di restituire i risultati delle elezioni da una fonte fidata off-chain (ad esempio l'Associated Press).
+Con gli oracoli, creare contratti intelligenti che rispondono a eventi del mondo reale è facile. I servizi di oracolo lo rendono possibile consentendo ai contratti di connettersi ad API esterne tramite componenti fuori catena e consumare informazioni da quelle fonti di dati. Ad esempio, la dApp di previsione menzionata in precedenza potrebbe richiedere a un oracolo di restituire i risultati elettorali da una fonte fuori catena affidabile (ad es., l'Associated Press).
+
+L'utilizzo di oracoli per recuperare dati basati su risultati del mondo reale abilita altri nuovi casi d'uso; ad esempio, un prodotto assicurativo decentralizzato ha bisogno di informazioni accurate su meteo, disastri, ecc. per funzionare in modo efficace.
-L'utilizzo degli oracoli per recuperare i dati secondo i risultati del mondo reale consente altri nuovi casi d'uso; ad esempio, un prodotto assicurativo decentralizzato necessita di informazioni accurate su meteo, disastri, ecc., per funzionare efficientemente.
+### Automazione dei contratti intelligenti {#automating-smart-contracts}
-### Automatizzare i contratti intelligenti {#automating-smart-contracts}
+I contratti intelligenti non vengono eseguiti automaticamente; piuttosto, un account controllato esternamente (EOA), o un altro account di contratto, deve innescare le funzioni giuste per eseguire il codice del contratto. Nella maggior parte dei casi, la maggior parte delle funzioni del contratto sono pubbliche e possono essere invocate da EOA e altri contratti.
-I contratti intelligenti non si eseguono automaticamente; piuttosto, un conto posseduto esternamente (EOA), o un altro conto di contratto, deve attivare le funzioni giuste per eseguire il codice del contratto. Nella maggior parte dei casi, la maggior parte delle funzioni del contratto è pubblica e può essere invocata da EOA e altri contratti.
+Ma ci sono anche _funzioni private_ all'interno di un contratto che sono inaccessibili ad altri, ma che sono fondamentali per la funzionalità complessiva di una dApp. Esempi includono una funzione `mintERC721Token()` che conia periodicamente nuovi NFT per gli utenti, una funzione per l'assegnazione di pagamenti in un mercato di previsione o una funzione per sbloccare i token in staking in un DEX.
-Ma in un contratto esistono anche _funzioni private_ che non sono accessibili ad altri, ma critiche per la funzionalità complessiva della dApp. Alcuni esempi sono una funzione `mintERC721Token()` che conia periodicamente nuovi NFT per gli utenti, una funzione per assegnare le vincite in un mercato predittivo, o una funzione per sbloccare i token messi in staking in un DEX.
+Gli sviluppatori dovranno innescare tali funzioni a intervalli per mantenere l'applicazione in esecuzione senza intoppi. Tuttavia, ciò potrebbe portare a più ore perse in compiti banali per gli sviluppatori, motivo per cui l'automazione dell'esecuzione dei contratti intelligenti è attraente.
-Gli sviluppatori dovranno attivare tali funzioni a intervalli per mantenere il corretto funzionamento dell'applicazione. Tuttavia, ciò potrebbe comportare un aumento delle ore perse in attività banali per gli sviluppatori, motivo per cui l'automazione dell'esecuzione dei contratti intelligenti è accattivante.
+Alcune reti di oracoli decentralizzate offrono servizi di automazione, che consentono ai nodi oracolo fuori catena di innescare le funzioni dei contratti intelligenti in base a parametri definiti dall'utente. In genere, ciò richiede la "registrazione" del contratto di destinazione con il servizio di oracolo, fornendo fondi per pagare l'operatore dell'oracolo e specificando le condizioni o i tempi per innescare il contratto.
-Alcune reti di oracoli decentralizzati offrono servizi di automazione, che consentono ai nodi oracolo off-chain di attivare funzioni di contratti intelligenti in base a parametri definiti dall'utente. In genere, ciò richiede la "registrazione" del contratto interessato al servizio oracolo, la fornitura di fondi per pagare l'operatore dell'oracolo e la specificazione delle condizioni o dei tempi di attivazione del contratto.
+La [Keeper Network](https://chain.link/keepers) di Chainlink fornisce opzioni per i contratti intelligenti per esternalizzare le normali attività di manutenzione in modo decentralizzato e con fiducia ridotta al minimo. Leggi la [documentazione ufficiale di Keeper](https://docs.chain.link/docs/chainlink-keepers/introduction/) per informazioni su come rendere il tuo contratto compatibile con Keeper e utilizzare il servizio Upkeep.
-[Keeper Network](https://chain.link/keepers) di Chainlink fornisce opzioni per i contratti intelligenti per esternalizzare le attività di manutenzione ordinaria in modo decentralizzato e con il minimo di fiducia. Leggi la [documentazione ufficiale di Keeper](https://docs.chain.link/docs/chainlink-keepers/introduction/) per le informazioni su come rendere il tuo contratto compatibile con Keeper e utilizzare il servizio Upkeep.
+## Come usare gli oracoli blockchain {#use-blockchain-oracles}
-## Come utilizzare gli oracoli della blockchain {#use-blockchain-oracles}
+Ci sono diverse applicazioni di oracoli che puoi integrare nella tua dApp di Ethereum:
-Ci sono più applicazioni di oracoli che puoi integrare nella tua dapp su Ethereum:
+**[Chainlink](https://chain.link/)** - _Le reti di oracoli decentralizzate Chainlink forniscono input, output e calcoli a prova di manomissione per supportare contratti intelligenti avanzati su qualsiasi blockchain._
-**[Chainlink](https://chain.link/)** - _ Le reti di oracoli decentralizzati di Chainlink forniscono input a prova di manomissione, output e calcoli per supportare contratti intelligenti avanzati su qualsiasi blockchain._
+**[RedStone Oracles](https://redstone.finance/)** - _RedStone è un oracolo modulare decentralizzato che fornisce feed di dati ottimizzati per il gas. È specializzato nell'offrire feed di prezzo per asset emergenti, come i token di liquid staking (LST), i token di liquid restaking (LRT) e i derivati di staking di Bitcoin._
-**[Chronicle](https://chroniclelabs.org/)** - _Chronicle supera le attuali limitazioni del trasferimento dei dati sulla catena sviluppando oracoli veramente scalabili, economici, decentralizzati e verificabili._
+**[Chronicle](https://chroniclelabs.org/)** - _Chronicle supera gli attuali limiti del trasferimento di dati on-chain sviluppando oracoli veramente scalabili, efficienti in termini di costi, decentralizzati e verificabili._
**[Witnet](https://witnet.io/)** - _Witnet è un oracolo senza permessi, decentralizzato e resistente alla censura che aiuta i contratti intelligenti a reagire agli eventi del mondo reale con forti garanzie cripto-economiche._
-**[UMA Oracle](https://uma.xyz)** - _L'oracolo ottimistico di UMA consente ai contratti intelligenti di ricevere rapidamente qualsiasi tipo di dati per diverse applicazioni, tra cui assicurazioni, derivati finanziari e mercati predittivi._
+**[UMA Oracle](https://uma.xyz)** - _L'oracolo ottimistico di UMA consente ai contratti intelligenti di ricevere rapidamente qualsiasi tipo di dato per diverse applicazioni, tra cui assicurazioni, derivati finanziari e mercati di previsione._
+
+**[Tellor](https://tellor.io/)** - _Tellor è un protocollo oracolo trasparente e senza permessi per il tuo contratto intelligente per ottenere facilmente qualsiasi dato ogni volta che ne ha bisogno._
+
+**[Band Protocol](https://bandprotocol.com/)** - _Band Protocol è una piattaforma di oracoli di dati cross-chain che aggrega e connette dati del mondo reale e API ai contratti intelligenti._
+
+**[Pyth Network](https://pyth.network/)** - _La rete Pyth è una rete di oracoli finanziari di prima parte progettata per pubblicare dati continui del mondo reale on-chain in un ambiente a prova di manomissione, decentralizzato e autosostenibile._
-**[Tellor](https://tellor.io/)** - _Tellor è un protocollo di oracolo trasparente e senza permessi per i tuoi contratti intelligenti al fine di ottenere facilmente tutti i dati ogni volta che ne hanno bisogno._
+**[API3 DAO](https://www.api3.org/)** - _API3 DAO sta fornendo soluzioni di oracoli di prima parte che offrono maggiore trasparenza delle fonti, sicurezza e scalabilità in una soluzione decentralizzata per i contratti intelligenti_
-**[Band Protocol](https://bandprotocol.com/)** - _Band Protocol è una piattaforma di oracolo di dati tra catene che aggrega e collega dati reali e API ai contratti intelligenti._
+**[Supra](https://supra.com/)** - Un toolkit integrato verticalmente di soluzioni cross-chain che interconnettono tutte le blockchain, pubbliche (L1 e L2) o private (aziende), fornendo feed di prezzo di oracoli decentralizzati che possono essere utilizzati per casi d'uso on-chain e fuori catena.
-**[Pyth Network](https://pyth.network/)** - _La rete Pyth è una rete di oracoli finanziari di prima parte progettata per pubblicare dati continui del mondo reale sulla catena in un ambiente resistente alle manomissioni, decentralizzato e autosostenibile._
+**[Gas Network](https://gas.network/)** - Una piattaforma di oracoli distribuita che fornisce dati sui prezzi del gas in tempo reale attraverso la blockchain. Portando on-chain i dati dei principali fornitori di dati sui prezzi del gas, Gas Network sta aiutando a guidare l'interoperabilità. Gas Network supporta i dati per oltre 35 catene, tra cui la rete principale di Ethereum e molti dei principali L2.
-**[DAO di API3](https://www.api3.org/)**: _la DAO di API3 distribuisce soluzioni di oracolo di prima parte che offrono una maggiore trasparenza della fonte, sicurezza e scalabilità in una soluzione decentralizzata per i contratti intelligenti_
+**[DIA](https://www.diadata.org/)** - Una rete di oracoli cross-chain che fornisce feed di dati verificabili per oltre 20.000 asset in tutte le principali classi di asset. DIA ricava i dati grezzi di trading direttamente da oltre 100 mercati primari e li calcola on-chain, garantendo completa trasparenza e verificabilità dei dati con configurazioni personalizzate per qualsiasi caso d'uso.
-**[Supra](https://supra.com/)**: un kit di strumenti integrato verticalmente di soluzioni tra catene che interconnettono tutte le blockchain, pubbliche (L1 e L2) o private (aziendali), fornendo feed sui prezzi degli oracoli decentralizzati utilizzabili per i casi d'uso interni ed esterni alla catena.
+**[Stork](https://stork.network)** - Stork fornisce dati sui prezzi a latenza ultra-bassa, supportando un'ampia gamma di casi d'uso tra cui mercati perpetui, protocolli di prestito ed ecosistemi DeFi, con nuovi asset supportati rapidamente al momento della quotazione.
-## Ulteriori letture {#further-reading}
+## Letture consigliate {#further-reading}
**Articoli**
-- [What Is a Blockchain Oracle?](https://chain.link/education/blockchain-oracles) — _Chainlink_
-- [What is a Blockchain Oracle?](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) — _Patrick Collins_
-- [Decentralised Oracles: a comprehensive overview](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _Julien Thevenard_
-- [Implementing a Blockchain Oracle on Ethereum](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_
-- [Why can't smart contracts make API calls?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_
-- [So you want to use a price oracle](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_
+- [Cos'è un oracolo blockchain?](https://chain.link/education/blockchain-oracles) — _Chainlink_
+- [Cos'è un oracolo blockchain?](https://medium.com/better-programming/what-is-a-blockchain-oracle-f5ccab8dbd72) — _Patrick Collins_
+- [Oracoli decentralizzati: una panoramica completa](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) — _Julien Thevenard_
+- [Implementazione di un oracolo blockchain su Ethereum](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_
+- [Perché i contratti intelligenti non possono effettuare chiamate API?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) — _StackExchange_
+- [Quindi vuoi usare un oracolo di prezzo](https://samczsun.com/so-you-want-to-use-a-price-oracle/) — _samczsun_
**Video**
-- [Oracoli ed espansione dell'utilità della blockchain](https://youtu.be/BVUZpWa8vpw) - _Real Vision Finance_
-- [Le differenze gli oracoli di prime e di terze parti](https://blockchainoraclesummit.io/first-party-vs-third-party-oracles/): _Blockchain Oracle Summit_
+- [Gli oracoli e l'espansione dell'utilità della blockchain](https://youtu.be/BVUZpWa8vpw) — _Real Vision Finance_
**Tutorial**
-- [Come recuperare il prezzo corrente di Ethereum in Solidity](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) - _Chainlink_
-- [Consuming Oracle Data](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_
+- [Come recuperare il prezzo attuale di Ethereum in Solidity](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) — _Chainlink_
+- [Consumare i dati dell'oracolo](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_
**Progetti di esempio**
-- [Progetto iniziale e completo di Chainlink per Ethereum in Solidity](https://github.com/hackbg/chainlink-fullstack) - _HackBG_
+- [Progetto iniziale completo Chainlink per Ethereum in Solidity](https://github.com/hackbg/chainlink-fullstack) — _HackBG_
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/dart/index.md b/public/content/translations/it/developers/docs/programming-languages/dart/index.md
index ba1069144fa..bada7d07fb3 100644
--- a/public/content/translations/it/developers/docs/programming-languages/dart/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/dart/index.md
@@ -1,28 +1,31 @@
---
-title: Ethereum per sviluppatori Dart
-description: Impara a sviluppare per Ethereum usando il linguaggio Dart
+title: Ethereum per gli sviluppatori Dart
+description: Scopri come sviluppare per Ethereum usando il linguaggio Dart
lang: it
incomplete: true
---
-## Primi passi con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
+## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
## Tutorial {#tutorials}
-- [Flutter e Blockchain – Hello World Dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) è una guida passo dopo passo per chi inizia da zero:
+- [Flutter and Blockchain – Hello World Dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) ti guida attraverso tutti i passaggi per iniziare:
1. Scrivere un contratto intelligente in [Solidity](https://soliditylang.org/)
- 2. Scrivere un'interfaccia utente su Dart
-- [Creare una dapp Mobile con Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) è molto più breve, il che potrebbe esser meglio se conosci già le basi
-- Se preferisci imparare guardando un video, puoi guardare [Build Your First Blockchain Flutter App](https://www.youtube.com/watch?v=3Eeh3pJ6PeA), lungo all'incirca un'ora
-- Se sei impaziente, questo potrebbe fare al caso tuo [Building a Blockchain Decentralized-app with Flutter and Dart on Ethereum](https://www.youtube.com/watch?v=jaMFEOCq_1s) (Creare un'app decentralizzata sulla Blockchain con Flutter e Dart su Ethereum), che dura solo circa venti minuti
-- [Integrating MetaMask in Flutter application with Web3Modal by WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) - questo breve video ti guida nei passaggi dell'integrazione di MetaMask nelle tue applicazioni di Flutter con la libreria [Web3Modal](https://pub.dev/packages/web3modal_flutter) di WalletConnect
-- [Mobile Blockchain Developer Bootcamp Course With Solidity & Flutter](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - playlist del corso per sviluppatori di blockchain mobili full stack
+ 2. Scrivere un'interfaccia utente in Dart
+- [Building a Mobile dapp with Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) è molto più breve, il che potrebbe essere meglio se conosci già le basi
+- Se preferisci imparare guardando un video, puoi guardare [Build Your First Blockchain Flutter App](https://www.youtube.com/watch?v=3Eeh3pJ6PeA), che dura circa un'ora
+- Se sei impaziente, potresti preferire [Building a Blockchain Decentralized-app with Flutter and Dart on Ethereum](https://www.youtube.com/watch?v=jaMFEOCq_1s), che dura solo una ventina di minuti
+- [Integrating MetaMask in Flutter application with Web3Modal by WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) - questo breve video ti guida attraverso i passaggi per integrare MetaMask nelle tue applicazioni Flutter con la libreria [Web3Modal](https://pub.dev/packages/web3modal_flutter) di WalletConnect
+- [Mobile Blockchain Developer Bootcamp Course With Solidity & Flutter](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) - playlist del corso per sviluppatori blockchain mobile full stack
## Lavorare con i client di Ethereum {#working-with-ethereum-clients}
-Puoi usare Ethereum per creare applicazioni decentralizzate (o "dapp") che utilizzano i benefici delle criptovalute e la tecnologia della blockchain. Esistono almeno due librerie attualmente mantenute per Dart per utilizzare l'[API di JSON-RPC](/developers/docs/apis/json-rpc/) per Ethereum.
+Puoi usare Ethereum per creare applicazioni decentralizzate (o "dApp") che sfruttano i vantaggi della criptovaluta e della tecnologia blockchain.
+Ci sono almeno due librerie attualmente mantenute per Dart per usare l'[API JSON-RPC](/developers/docs/apis/json-rpc/) per Ethereum.
-1. [Web3dart da simonbutler.eu](https://pub.dev/packages/web3dart)
-1. [Ethereum 5.0.0 da darticulate.com](https://pub.dev/packages/ethereum)
+1. [Web3dart di pwa.ir](https://pub.dev/packages/web3dart)
+1. [Ethereum 5.0.0 di darticulate.com](https://pub.dev/packages/ethereum)
-Esistono anche librerie aggiuntive che ti consentono di manipolare indirizzi specifici di Ethereum o che ti consentono di recuperare i prezzi di varie criptovalute. [Qui puoi visualizzare l'elenco completo](https://pub.dev/dart/packages?q=ethereum).
+Ci sono anche librerie aggiuntive che ti permettono di manipolare specifici indirizzi Ethereum,
+o che ti consentono di recuperare i prezzi di varie criptovalute.
+[Puoi vedere l'elenco completo qui](https://pub.dev/dart/packages?q=ethereum).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/delphi/index.md b/public/content/translations/it/developers/docs/programming-languages/delphi/index.md
index 69ddee82a10..b60e656d3ce 100644
--- a/public/content/translations/it/developers/docs/programming-languages/delphi/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/delphi/index.md
@@ -1,56 +1,56 @@
---
-title: Ethereum per sviluppatori Delphi
-description: Impara a sviluppare per Ethereum utilizzando il linguaggio di programmazione Delphi
+title: Ethereum per gli sviluppatori Delphi
+description: Scopri come sviluppare per Ethereum usando il linguaggio di programmazione Delphi
lang: it
incomplete: true
---
-Impara a sviluppare per Ethereum utilizzando il linguaggio di programmazione Delphi
+Scopri come sviluppare per Ethereum usando il linguaggio di programmazione Delphi
-Usa Ethereum per creare applicazioni decentralizzate (dette "dapp") che sfruttano i vantaggi delle criptovalute e della tecnologia blockchain. Queste dapp sono attendibili perché, una volta "caricate" su Ethereum, vengono eseguite sempre come sono state programmate. Possono controllare risorse digitali per creare nuove tipologie di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibile da censurare.
+Usa Ethereum per creare applicazioni decentralizzate (o "dApp") che sfruttano i vantaggi della criptovaluta e della tecnologia blockchain. Queste dApp possono essere affidabili, il che significa che una volta distribuite su Ethereum, verranno sempre eseguite come programmate. Possono controllare risorse digitali al fine di creare nuovi tipi di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibili da censurare.
-Creare applicazioni decentralizzate su Ethereum e interagire con i contratti intelligenti usando il linguaggio di programmazione Delphi!
+Crea applicazioni decentralizzate su Ethereum e interagisci con i contratti intelligenti usando il linguaggio di programmazione Delphi!
-## Primi passi con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
+## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
-**Inizia a integrare Delphi con Ethereum**
+**Fai i tuoi primi passi per integrare Delphi con Ethereum**
-Hai prima bisogno di nozioni di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
+Hai prima bisogno di un'introduzione più basilare? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
-- [Blockchain Explained](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Comprendere i Contratti Intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Scrivi il tuo Primo Contratto Intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Learn How to Compile and Deploy Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Spiegazione della Blockchain](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Comprendere i contratti intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Scrivi il tuo primo contratto intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Scopri come compilare e distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
## Riferimenti e link per principianti {#beginner-references-and-links}
**Introduzione alla libreria Delphereum**
-- [What is Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md)
-- [Connecting Delphi to a local (in-memory) blockchain](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
+- [Cos'è Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md)
+- [Connettere Delphi a una blockchain locale (in memoria)](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0)
- [Connettere Delphi alla rete principale di Ethereum](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83)
-- [Connettere Delphi ai Contratti Intelligenti](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
+- [Connettere Delphi ai contratti intelligenti](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1)
-**Vuoi lasciare stare la configurazione per ora e passare direttamente agli esempi?**
+**Vuoi saltare la configurazione per ora e passare direttamente agli esempi?**
-- [Un Contratto Intelligente di 3 minuti e Delphi - Parte 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
-- [Un Contratto Intelligente di 3 minuti e Delphi - Parte 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
+- [Un contratto intelligente in 3 minuti e Delphi - Parte 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d)
+- [Un contratto intelligente in 3 minuti e Delphi - Parte 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b)
## Articoli di livello intermedio {#intermediate-articles}
-- [Generating an Ethereum-signed message signature in Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
-- [Transferring ether with Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
-- [Transferring ERC-20 tokens with Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
+- [Generare una firma di messaggio firmata da Ethereum in Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b)
+- [Trasferire ether con Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4)
+- [Trasferire token ERC-20 con Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d)
-## Modelli d'uso avanzati {#advanced-use-patterns}
+## Modelli di utilizzo avanzati {#advanced-use-patterns}
-- [Delphi and Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
-- [QuikNode, Ethereum and Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
-- [Delphi e la Dark Forest di Ethereum](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
-- [Scambia un token per un altro su Delphi](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
+- [Delphi ed Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7)
+- [QuikNode, Ethereum e Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23)
+- [Delphi e la Foresta Oscura di Ethereum](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93)
+- [Scambiare un token per un altro in Delphi](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7)
-Cerchi altre risorse? Dai un'occhiata a [ethereum.org/developers](/developers/).
+Cerchi altre risorse? Dai un'occhiata a [ethereum.org/developers](/developers/).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/it/developers/docs/programming-languages/dot-net/index.md
index 5e6db2a11f0..545c7a68f1d 100644
--- a/public/content/translations/it/developers/docs/programming-languages/dot-net/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/dot-net/index.md
@@ -1,86 +1,86 @@
---
-title: Ethereum per sviluppatori .NET
-description: Impara a sviluppare per Ethereum usando progetti e strumenti basati su .NET
+title: Ethereum per gli sviluppatori .NET
+description: Scopri come sviluppare per Ethereum usando progetti e strumenti basati su .NET
lang: it
incomplete: true
---
-Impara a sviluppare per Ethereum usando progetti e strumenti basati su .NET
+Scopri come sviluppare per Ethereum usando progetti e strumenti basati su .NET
-Usa Ethereum per creare applicazioni decentralizzate (dette "dapp") che sfruttano i vantaggi delle criptovalute e della tecnologia blockchain. Queste dapp sono attendibili perché, una volta "caricate" su Ethereum, vengono eseguite sempre come sono state programmate. Possono controllare risorse digitali per creare nuove tipologie di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibile da censurare.
+Usa Ethereum per creare applicazioni decentralizzate (o "dApp") che sfruttano i vantaggi della criptovaluta e della tecnologia blockchain. Queste dApp possono essere affidabili, il che significa che una volta distribuite su Ethereum, verranno sempre eseguite come programmate. Possono controllare risorse digitali al fine di creare nuovi tipi di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibili da censurare.
-Crea applicazioni decentralizzate basate su Ethereum e interagisci con i contratti intelligenti utilizzando strumenti e linguaggi dallo stack della tecnologia di Microsoft: Supporto C#. # Visual Basic .NET, F#, con strumenti come VSCode e Visual Studio, su .NET Framework/.NET Core/.NET Standard. Distribuisci una blockchain Ethereum su Azure usando Microsoft Azure Blockchain in pochi minuti. Porta .NET su Ethereum!
+Crea applicazioni decentralizzate su Ethereum e interagisci con i contratti intelligenti usando strumenti e linguaggi dello stack tecnologico Microsoft - Supportando C#, # Visual Basic .NET, F#, su strumenti come VSCode e Visual Studio, attraverso .NET Framework/.NET Core/.NET Standard. Distribuisci una blockchain di Ethereum su Azure usando Microsoft Azure Blockchain in pochi minuti. Porta l'amore per .NET su Ethereum!
-## Primi passi con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
+## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-the-solidity-language}
-**Operazioni di base per integrare .NET con Ethereum**
+**Fai i tuoi primi passi per integrare .NET con Ethereum**
-Hai prima bisogno di nozioni di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
+Hai prima bisogno di un'introduzione più basilare? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
-- [Blockchain Explained](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Comprendere i Contratti Intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Scrivi il tuo Primo Contratto Intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Learn How to Compile and Deploy Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Spiegazione della blockchain](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Comprendere i contratti intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Scrivi il tuo primo contratto intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Scopri come compilare e distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
## Riferimenti e link per principianti {#beginner-references-and-links}
-**Introduzione alla libreria Nethereum e VS Code Solidity**
+**Introduzione alla libreria Nethereum e a VS Code Solidity**
-- [Nethereum, Getting Started](https://docs.nethereum.com/en/latest/getting-started/)
-- [Installing VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity)
-- [Il Flusso di Lavoro di uno Sviluppatore .NET per Creare e Chiamare i Contratti Intelligenti di Ethereum](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
+- [Nethereum, per iniziare](https://docs.nethereum.com/en/latest/getting-started/)
+- [Installazione di VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity)
+- [Il flusso di lavoro di uno sviluppatore .NET per creare e chiamare contratti intelligenti di Ethereum](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2)
- [Integrazione dei contratti intelligenti con Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm)
-- [Interfacciare .NET e i Contratti Intelligenti della Blockchain di Ethereum con Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), anche in [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)
-- [Nethereum - An open source .NET integration library for blockchain](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
-- [Writing Ethereum Transactions to SQL Database Using Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36)
+- [Interfacciare .NET e i contratti intelligenti della blockchain di Ethereum con Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), anche in [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1)
+- [Nethereum - Una libreria di integrazione .NET open source per la blockchain](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/)
+- [Scrivere transazioni di Ethereum su database SQL usando Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36)
- [Scopri come distribuire facilmente i contratti intelligenti di Ethereum usando C# e VisualStudio](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c)
-**Vuoi lasciar stare temporaneamente la configurazione e passare direttamente agli esempi?**
+**Vuoi saltare la configurazione per ora e passare direttamente agli esempi?**
-- [Playground](http://playground.nethereum.com/) - Interagire con Ethereum e imparare a utilizzare Nethereum con il browser.
- - Interroga il saldo del conto [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001)
- - Interroga il Saldo di ERC20 del Contratto Intelligente [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004)
- - Trasferisci Ether in un Conto [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003)
- - ... e molto altro!
+- [Playground](http://playground.nethereum.com/) - Interagisci con Ethereum e impara a usare Nethereum tramite il browser.
+ - Interroga il saldo dell'account [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001)
+ - Interroga il saldo del contratto intelligente ERC20 [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004)
+ - Trasferisci ether a un account [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003)
+ - ... E molto altro!
## Articoli di livello intermedio {#intermediate-articles}
-- [Nethereum Workbook/Sample List](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
-- [Deploy Your Own Development Testchains](https://github.com/Nethereum/Testchains)
-- [VSCode Codegen Plugin for Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
-- [Unity and Ethereum: Why and How](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
-- [Create ASP.NET Core Web API for Ethereum dapps](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
-- [Using Nethereum Web3 to Implement a Supply Chain Tracking System](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
-- [Nethereum Block Processing](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), with [C# Playground sample](http://playground.nethereum.com/csharp/id/1025)
-- [Nethereum Websocket Streaming](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/)
-- [Kaleido and Nethereum](https://kaleido.io/kaleido-and-nethereum/)
-- [Quorum and Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md)
+- [Cartella di lavoro/Elenco di esempi di Nethereum](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/)
+- [Distribuisci le tue catene di test di sviluppo](https://github.com/Nethereum/Testchains)
+- [Plugin Codegen di VSCode per Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/)
+- [Unity ed Ethereum: perché e come](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how)
+- [Creare un'API Web ASP.NET Core per le dApp di Ethereum](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/)
+- [Usare Nethereum Web3 per implementare un sistema di tracciamento della catena di approvvigionamento](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4)
+- [Elaborazione dei blocchi di Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), con [esempio in C# su Playground](http://playground.nethereum.com/csharp/id/1025)
+- [Streaming Websocket di Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/)
+- [Kaleido e Nethereum](https://kaleido.io/kaleido-and-nethereum/)
+- [Quorum e Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md)
-## Modelli d'uso avanzati {#advanced-use-patterns}
+## Modelli di utilizzo avanzati {#advanced-use-patterns}
-- [Azure Key Vault And Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
+- [Azure Key Vault e Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum)
- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid)
-- [Ujo Nethereum backend reference architecture](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/)
+- [Architettura di riferimento del backend Ujo Nethereum](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/)
-## Progetti .NET, strumenti e altre risorse interessanti {#dot-net-projects-tools-and-other-fun-stuff}
+## Progetti .NET, strumenti e altre cose divertenti {#dot-net-projects-tools-and-other-fun-stuff}
-- [Playground Nethereum](http://playground.nethereum.com/) - _Compila, crea ed esegui frammenti di codice Nethereum nel browser_
-- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Codegen Nethereum con interfaccia utente in Blazor_
-- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _Navigatore della blockchain leggero e semplice portafoglio in .NET Wasm SPA_
-- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _Motore di regole aziendali (per la piattaforma .NET e per quella di Ethereum) intrinsecamente guidato da metadati_
-- [Nethermind](https://github.com/NethermindEth/nethermind): _Un client di Ethereum di .NET Core per Linux, Windows, MacOS_
-- [eth-utils](https://github.com/ethereum/eth-utils/) - _Funzioni di utilità per lavorare con basi di codice relative a Ethereum_
-- [TestChains](https://github.com/Nethereum/TestChains) - _Catene di sviluppo .NET preconfigurate per risposte veloci (PoA)_
+- [Nethereum Playground](http://playground.nethereum.com/) - _Compila, crea ed esegui frammenti di codice Nethereum nel browser_
+- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Codegen di Nethereum con interfaccia utente in Blazor_
+- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _Un esploratore di blockchain leggero e portafoglio semplice SPA Wasm .NET_
+- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _Un motore di regole aziendali (sia per la piattaforma .NET che per la piattaforma Ethereum) intrinsecamente guidato dai metadati_
+- [Nethermind](https://github.com/NethermindEth/nethermind) - _Un client di Ethereum in .NET Core per Linux, Windows, MacOS_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _funzioni di utilità per lavorare con basi di codice relative a Ethereum_
+- [TestChains](https://github.com/Nethereum/TestChains) - _Catene di sviluppo .NET preconfigurate per una risposta rapida (PoA)_
Cerchi altre risorse? Dai un'occhiata a [ethereum.org/developers](/developers/).
## Collaboratori della community .NET {#dot-net-community-contributors}
-Per Nethereum, scambiamo opinioni per lo più su [Gitter](https://gitter.im/Nethereum/Nethereum), dove tutti possono chiedere o rispondere a domande, cercare aiuto o semplicemente consultare informazioni. Sentiti libero di effettuare una PR o di aprire una segnalazione sul [repository di GitHub di Nethereum](https://github.com/Nethereum) o, semplicemente, di sfogliare i molti progetti secondari/di esempio disponibili. Ci trovi anche su [Discord](https://discord.gg/jQPrR58FxX)!
+In Nethereum, ci ritroviamo principalmente su [Gitter](https://gitter.im/Nethereum/Nethereum) dove tutti sono i benvenuti per fare/rispondere a domande, ricevere aiuto o semplicemente rilassarsi. Sentiti libero di fare una PR o aprire un problema sul [repository GitHub di Nethereum](https://github.com/Nethereum), o semplicemente sfogliare i numerosi progetti secondari/di esempio che abbiamo. Puoi trovarci anche su [Discord](https://discord.gg/jQPrR58FxX)!
-Se sei nuovo su Nethermind e necessiti d'aiuto per iniziare, unisciti al nostro [Discord](http://discord.gg/PaCMRFdvWT). I nostri sviluppatori sono a disposizione per rispondere alle tue domande. Non esitare ad aprire una PR o a sollevare qualsiasi dubbio sulla [repository di GitHub di Nethermind](https://github.com/NethermindEth/nethermind).
+Se sei nuovo su Nethermind e hai bisogno di aiuto per iniziare, unisciti al nostro [Discord](http://discord.gg/PaCMRFdvWT). I nostri sviluppatori sono a disposizione per rispondere alle tue domande. Non esitare ad aprire una PR o a segnalare eventuali problemi sul [repository GitHub di Nethermind](https://github.com/NethermindEth/nethermind).
## Altri elenchi aggregati {#other-aggregated-lists}
-[Official Nethereum Site](https://nethereum.com/)
-[Official Nethermind Site](https://nethermind.io/)
+[Sito ufficiale di Nethereum](https://nethereum.com/)
+[Sito ufficiale di Nethermind](https://nethermind.io/)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/elixir/index.md b/public/content/translations/it/developers/docs/programming-languages/elixir/index.md
index cac80dd116e..a5c756bb5e6 100644
--- a/public/content/translations/it/developers/docs/programming-languages/elixir/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/elixir/index.md
@@ -1,55 +1,55 @@
---
title: Ethereum per gli sviluppatori Elixir
-description: Scopri come sviluppare per Ethereum utilizzando progetti e strumenti basati su Elixir.
+description: Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Elixir.
lang: it
incomplete: false
---
-Scopri come sviluppare per Ethereum utilizzando progetti e strumenti basati su Elixir.
+Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Elixir.
-Usa Ethereum per creare applicazioni decentralizzate (dette "dapp") che sfruttano i vantaggi delle criptovalute e della tecnologia blockchain. Queste dapp possono essere senza fiducia, a significare che una volta distribuite su Ethereum, saranno sempre eseguite come programmate. Possono controllare risorse digitali per creare nuove tipologie di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibile da censurare.
+Usa Ethereum per creare applicazioni decentralizzate (o "dApp") che sfruttano i vantaggi della criptovaluta e della tecnologia blockchain. Queste dApp possono essere "trustless" (senza bisogno di fiducia), il che significa che una volta distribuite su Ethereum, verranno sempre eseguite come programmate. Possono controllare risorse digitali per creare nuovi tipi di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibili da censurare.
## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
**Fai i tuoi primi passi per integrare Elixir con Ethereum**
-Hai prima bisogno di nozioni di base? Consulta [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
+Hai prima bisogno di un'introduzione più basilare? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
-- [Blockchain spiegate](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Spiegazione della Blockchain](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
- [Comprendere i contratti intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
- [Scrivi il tuo primo contratto intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
- [Impara a compilare e distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
## Articoli per principianti {#beginner-articles}
-- [Comprendere finalmente i conti di Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
-- [Ethers: Una libreria Web3 di Ethereum di prima classe per Elixir](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122)
+- [Comprendere finalmente gli account di Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
+- [Ethers — Una libreria Web3 di Ethereum di prim'ordine per Elixir](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122)
-## Articoli intermedi {#intermediate-articles}
+## Articoli di livello intermedio {#intermediate-articles}
-- [Come firmare le transazioni grezze del contratto di Ethereum con Elixir](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b)
-- [I contratti intelligenti di Ethereum ed Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4)
+- [Come firmare transazioni grezze di contratti Ethereum con Elixir](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b)
+- [Contratti intelligenti di Ethereum ed Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4)
-## Progetti e strumenti di Elixir {#elixir-projects-and-tools}
+## Progetti e strumenti Elixir {#elixir-projects-and-tools}
### Attivi {#active}
-- [block_keys](https://github.com/ExWeb3/block_keys): _Implentazione di BIP32 e BIP44 in Elixir (Gerarchia di più conti per i portafogli deterministici)_
-- [ethereumex](https://github.com/mana-ethereum/ethereumex): _Client JSON-RPC di Elixir per la blockchain di Ethereum_
-- [ethers](https://github.com/ExWeb3/elixir_ethers): _Una libreria Web3 completa per interagire con i contratti intelligenti su Ethereum utilizzando Elixir_
-- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms): _Una libreria del firmatario di KMS per Ethers (firma le transazioni con KMS di AWS)_
-- [ex_abi](https://github.com/poanetwork/ex_abi): _Implementazione dell'analizzatore/decodificatore/codificatore dell'ABI di Ethereum in Elixir_
-- [ex_keccak](https://github.com/ExWeb3/ex_keccak): _Libreria di Elixir per calcolare gli hash Keccak SHA3-256 utilizzando una minuscola crate di Rust Keccac, creata da NIF_
-- [ex_rlp](https://github.com/mana-ethereum/ex_rlp): _Implementazione di Elixir della codifica RLP (prefisso a lunghezza ricorsiva) di Ethereum_
+- [block_keys](https://github.com/ExWeb3/block_keys) - _Implementazione di BIP32 e BIP44 in Elixir (Gerarchia multi-account per portafogli deterministici)_
+- [ethereumex](https://github.com/mana-ethereum/ethereumex) - _Client JSON-RPC in Elixir per la blockchain di Ethereum_
+- [ethers](https://github.com/ExWeb3/elixir_ethers) - _Una libreria Web3 completa per interagire con i contratti intelligenti su Ethereum usando Elixir_
+- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) - _Una libreria di firma KMS per Ethers (firma le transazioni con AWS KMS)_
+- [ex_abi](https://github.com/poanetwork/ex_abi) - _Implementazione di parser/decodificatore/codificatore ABI di Ethereum in Elixir_
+- [ex_keccak](https://github.com/ExWeb3/ex_keccak) - _Libreria Elixir per calcolare gli hash Keccak SHA3-256 usando un crate Rust tiny-keccak integrato con NIF_
+- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) - _Implementazione in Elixir della codifica RLP (Recursive Length Prefix) di Ethereum_
### Archiviati / Non più mantenuti {#archived--no-longer-maintained}
-- [eth](https://hex.pm/packages/eth): _Utilità di Ethereum per Elixir_
-- [exw3](https://github.com/hswick/exw3): _Client RPC di Ethereum di alto livello per Elixir_
-- [mana](https://github.com/mana-ethereum/mana): _Implementazione del nodo completo di Ethereum scritta in Elixir_
+- [eth](https://hex.pm/packages/eth) - _Utilità di Ethereum per Elixir_
+- [exw3](https://github.com/hswick/exw3) - _Client RPC di Ethereum di alto livello per Elixir_
+- [mana](https://github.com/mana-ethereum/mana) - _Implementazione di un nodo completo di Ethereum scritta in Elixir_
-Cerchi altre risorse? Consulta la nostra [home degli Sviluppatori](/developers/).
+Cerchi altre risorse? Dai un'occhiata alla [nostra pagina per sviluppatori](/developers/).
## Collaboratori della community di Elixir {#elixir-community-contributors}
-Il [canale di Slack #ethereum di Elixir](https://elixir-lang.slack.com/archives/C5RPZ3RJL) ospita una community in rapida crescita ed è la risorsa dedicata per le discussioni su qualsiasi dei suddetti progetti e argomenti correlati.
+Il [canale #ethereum sullo Slack di Elixir](https://elixir-lang.slack.com/archives/C5RPZ3RJL) ospita una community in rapida crescita ed è la risorsa dedicata per le discussioni su qualsiasi dei progetti sopra citati e argomenti correlati.
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/golang/index.md b/public/content/translations/it/developers/docs/programming-languages/golang/index.md
index 87694a4fc17..c3a5395ad6e 100644
--- a/public/content/translations/it/developers/docs/programming-languages/golang/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/golang/index.md
@@ -1,5 +1,5 @@
---
-title: Ethereum per sviluppatori Go
+title: Ethereum per gli sviluppatori Go
description: Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Go
lang: it
incomplete: true
@@ -7,78 +7,78 @@ incomplete: true
Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Go
-Usa Ethereum per creare applicazioni decentralizzate (o "dapp"). Queste dapp sono attendibili perché, una volta "caricate" su Ethereum, vengono eseguite sempre come sono state programmate. Sono decentralizzate, significa che sono eseguite su una rete peer-to-peer e non esiste un punto di errore singolo. Nessun ente o persona le controlla e sono quasi impossibili da censurare. Possono controllare risorse digitali in modo da creare nuovi tipi di applicazioni.
+Usa Ethereum per creare applicazioni decentralizzate (o "dApp"). Queste dApp possono essere affidabili, il che significa che una volta distribuite su Ethereum, verranno sempre eseguite come programmate. Sono decentralizzate, il che significa che vengono eseguite su una rete peer-to-peer e non c'è un singolo punto di guasto. Nessuna singola entità o persona le controlla e sono quasi impossibili da censurare. Possono controllare risorse digitali al fine di creare nuovi tipi di applicazioni.
-## Primi passi con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
+## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
-**Operazioni di base per integrare Go con Ethereum**
+**Fai i tuoi primi passi per integrare Go con Ethereum**
-Hai prima bisogno di nozioni di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
+Hai prima bisogno di un'introduzione più basilare? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
-- [Blockchain Explained](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Comprendere i Contratti Intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Scrivi il tuo Primo Contratto Intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Learn How to Compile and Deploy Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-- [Contract Tutorial](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial)
+- [Spiegazione della Blockchain](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Comprendere i contratti intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Scrivi il tuo primo contratto intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Impara a compilare e distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Tutorial sui contratti](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial)
## Articoli e libri per principianti {#beginner-articles-and-books}
-- [Getting Started with Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458)
-- [Use Golang to Connect to Ethereum](https://www.youtube.com/watch?v=-7uChuO_VzM)
-- [Distribuisci i Contratti Intelligenti di Ethereum Usando Golang](https://www.youtube.com/watch?v=pytGqQmDslE)
-- [Una Guida Passo dopo Passo per Testare e Distribuire i Contratti Intelligenti di Ethereum in Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
-- [eBook: Ethereum Development with Go](https://goethereumbook.org/) - _Sviluppare applicazioni Ethereum con Go_
+- [Iniziare con Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458)
+- [Usare Golang per connettersi a Ethereum](https://www.youtube.com/watch?v=-7uChuO_VzM)
+- [Distribuire contratti intelligenti di Ethereum usando Golang](https://www.youtube.com/watch?v=pytGqQmDslE)
+- [Una guida passo passo per testare e distribuire contratti intelligenti di Ethereum in Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78)
+- [eBook: Sviluppo su Ethereum con Go](https://goethereumbook.org/) - _Sviluppa applicazioni Ethereum con Go_
## Articoli e documentazione di livello intermedio {#intermediate-articles-and-docs}
-- [Go Ethereum Documentation](https://geth.ethereum.org/docs/) - _La documentazione per il Golang ufficiale di Ethereum_
-- [Guida per Programmatori a Erigon](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _Guida illustrata con l'albero di stato, prove multiple ed elaborazione delle transazioni_
-- [Erigon ed Ethereum senza Stato](https://youtu.be/3-Mn7OckSus?t=394) - _Conferenza della Community di Ethereum 2020 (EthCC 3)_
-- [Erigon: ottimizzare i client di Ethereum](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _2018 Devcon 4_
-- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum)
-- [Creare una dapp in Go con Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
-- [Work with Ethereum Private Network with Golang and Geth](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
-- [Unit testing Solidity contracts on Ethereum with Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
-- [Quick reference for using Geth as a library](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
-
-## Modelli d'uso avanzati {#advanced-use-patterns}
-
-- [The GETH Simulated Backend](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top)
-- [Blockchain-as-a-Service Apps Using Ethereum and Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html)
-- [Distributed Storage IPFS and Swarm in Ethereum Blockchain Applications](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
-- [Mobile Clients: Libraries and Inproc Ethereum Nodes](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
-- [Dapp native: Collegamenti di Go ai contratti di Ethereum](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts)
-
-## Progetti e strumenti di Go {#go-projects-and-tools}
-
-- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _Implementazione ufficiale di Go del protocollo di Ethereum_
-- [Go Ethereum Code Analysis](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Controllo e analisi del codice sorgente di Go Ethereum_
-- [Erigon](https://github.com/ledgerwatch/erigon) - _Derivato più veloce di Go Ethereum, incentrato sull'archiviazione dei nodi_
+- [Documentazione di Go Ethereum](https://geth.ethereum.org/docs) - _La documentazione per il Golang ufficiale di Ethereum_
+- [Guida del programmatore di Erigon](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) - _Guida illustrata che include l'albero dello stato, le multi-prove e l'elaborazione delle transazioni_
+- [Erigon ed Ethereum senza stato](https://youtu.be/3-Mn7OckSus?t=394) - _Conferenza della community di Ethereum 2020 (EthCC 3)_
+- [Erigon: ottimizzare i client di Ethereum](https://www.youtube.com/watch?v=CSpc1vZQW2Q) - _Devcon 4 del 2018_
+- [GoDoc di Go Ethereum](https://godoc.org/github.com/ethereum/go-ethereum)
+- [Creare una dApp in Go con Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/)
+- [Lavorare con una rete privata di Ethereum con Golang e Geth](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php)
+- [Test unitari dei contratti Solidity su Ethereum con Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281)
+- [Riferimento rapido per l'uso di Geth come libreria](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e)
+
+## Modelli di utilizzo avanzati {#advanced-use-patterns}
+
+- [Il backend simulato di GETH](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top)
+- [App Blockchain-as-a-Service usando Ethereum e Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html)
+- [Archiviazione distribuita IPFS e Swarm nelle applicazioni blockchain di Ethereum](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html)
+- [Client mobili: librerie e nodi Ethereum Inproc](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes)
+- [dApp native: binding Go per i contratti di Ethereum](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts)
+
+## Progetti e strumenti Go {#go-projects-and-tools}
+
+- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _Implementazione ufficiale in Go del protocollo Ethereum_
+- [Analisi del codice di Go Ethereum](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Revisione e analisi del codice sorgente di Go Ethereum_
+- [Erigon](https://github.com/ledgerwatch/erigon) - _Derivato più veloce di Go Ethereum, con un focus sui nodi di archivio_
- [Golem](https://github.com/golemfactory/golem) - _Golem sta creando un mercato globale per la potenza di calcolo_
-- [Quorum](https://github.com/jpmorganchase/quorum) - _Implementazione con permessi di Ethereum a supporto della privacy dei dati_
-- [Prysm](https://github.com/prysmaticlabs/prysm) - _Implementazione Go di 'Serenity' 2.0 per Ethereum_
-- [Eth Tweet](https://github.com/yep/eth-tweet) - _Twitter decentralizzato: un servizio di microblogging sulla blockchain di Ethereum_
-- [Plasma MVP Golang](https://github.com/kyokan/plasma) - _Implementazione di Golang ed estensione della specifica Minimum Viable Plasma_-
-- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _Pool di mining open source di Ethereum_
-- [Ethereum HD Wallet](https://github.com/miguelmota/go-ethereum-hdwallet) - _Derivazioni del portafoglio HD di Ethereum in Go_
-- [Multi Geth](https://github.com/multi-geth/multi-geth) - _Supporto per molti tipi di reti Ethereum_
-- [Geth Light Client](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Implementazione Geth del protocollo secondario Ethereum leggero_
-- [Ethereum Golang SDK](https://github.com/everFinance/goether) - _Una semplice implementazione del portafoglio e utilità in Golang_
-- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _Accesso efficiente ai dati della blockchain tramite la SDK di Go per oltre 200 blockchain_
+- [Quorum](https://github.com/jpmorganchase/quorum) - _Un'implementazione autorizzata di Ethereum che supporta la privacy dei dati_
+- [Prysm](https://github.com/prysmaticlabs/prysm) - _Implementazione in Go di Ethereum 'Serenity' 2.0_
+- [Eth Tweet](https://github.com/yep/eth-tweet) - _Twitter decentralizzato: un servizio di microblogging in esecuzione sulla blockchain di Ethereum_
+- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Implementazione in Golang ed estensione della specifica Minimum Viable Plasma_
+- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _Una pool di mining di Ethereum open source_
+- [Portafoglio HD di Ethereum](https://github.com/miguelmota/go-ethereum-hdwallet) - _Derivazioni del portafoglio HD di Ethereum in Go_
+- [Multi Geth](https://github.com/multi-geth/multi-geth) - _Supporto per molte specie di reti Ethereum_
+- [Client leggero di Geth](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Implementazione in Geth del sottocollo leggero di Ethereum_
+- [SDK Golang di Ethereum](https://github.com/everFinance/goether) - _Una semplice implementazione di portafoglio Ethereum e utilità in Golang_
+- [SDK Golang di Covalent](https://github.com/covalenthq/covalent-api-sdk-go) - _Accesso efficiente ai dati della blockchain tramite l'SDK Go per oltre 200 blockchain_
Cerchi altre risorse? Dai un'occhiata a [ethereum.org/developers](/developers/)
-## Collaboratori della community di Go {#go-community-contributors}
+## Collaboratori della community Go {#go-community-contributors}
-- [Geth Discord](https://discordapp.com/invite/nthXNEv)
-- [Geth Sgist](https://gitter.im/ethereum/go-ethereum)
-- [Gophers Slack](https://invite.slack.golangbridge.org/) - [Canale #ethereum](https://gophers.slack.com/messages/C9HP1S9V2)
+- [Discord di Geth](https://discordapp.com/invite/nthXNEv)
+- [Gist di Geth](https://gitter.im/ethereum/go-ethereum)
+- [Slack di Gophers](https://invite.slack.golangbridge.org/) - [canale #ethereum](https://gophers.slack.com/messages/C9HP1S9V2)
- [StackExchange - Ethereum](https://ethereum.stackexchange.com/)
-- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth)
-- [Ethereum Gitter](https://gitter.im/ethereum/home)
-- [Geth light Client Gitter](https://gitter.im/ethereum/light-client)
+- [Gitter di Multi Geth](https://gitter.im/ethoxy/multi-geth)
+- [Gitter di Ethereum](https://gitter.im/ethereum/home)
+- [Gitter del client leggero di Geth](https://gitter.im/ethereum/light-client)
## Altri elenchi aggregati {#other-aggregated-lists}
- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum)
-- [Consensys: A Definitive List of Ethereum Developer Tools](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [Fonte GitHub](https://github.com/ConsenSys/ethereum-developer-tools-list)
+- [Consensys: un elenco definitivo di strumenti per sviluppatori di Ethereum](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [Sorgente GitHub](https://github.com/ConsenSys/ethereum-developer-tools-list)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/index.md b/public/content/translations/it/developers/docs/programming-languages/index.md
index 957682e4bb3..336afa647b1 100644
--- a/public/content/translations/it/developers/docs/programming-languages/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/index.md
@@ -1,21 +1,22 @@
---
title: Linguaggi di programmazione
-description:
+description: Scopri le risorse di sviluppo di Ethereum per vari linguaggi di programmazione, tra cui JavaScript, Python, Go, Rust e altri.
lang: it
---
-Spesso, si crede erroneamente che gli sviluppatori debbano scrivere i [contratti intelligenti](/developers/docs/smart-contracts/) per poter sviluppare su Ethereum. Non è vero. Uno degli aspetti positivi della rete e della community Ethereum è che si può [partecipare](/community/) usando praticamente qualsiasi linguaggio di programmazione.
+Un malinteso comune è che gli sviluppatori debbano scrivere [contratti intelligenti](/developers/docs/smart-contracts/) per poter sviluppare su Ethereum. Questo è falso.
+Una delle bellezze della rete e della community di Ethereum è che puoi [partecipare](/community/) in quasi tutti i linguaggi di programmazione.
-Ethereum e la sua community adottano l'open source. È possibile trovare progetti della community, cioè implementazioni di client, API, framework di sviluppo, strumenti di test, in un'ampia gamma di linguaggi.
+Ethereum e la sua community abbracciano l'open source. Puoi trovare progetti della community - implementazioni di client, API, framework di sviluppo, strumenti di test - in un'ampia varietà di linguaggi.
-## Scegli il linguaggio che preferisci {#data}
+## Scegli il tuo linguaggio {#data}
-Seleziona il linguaggio di programmazione che preferisci per trovare progetti, risorse e community virtuali:
+Seleziona il tuo linguaggio di programmazione preferito per trovare progetti, risorse e community virtuali:
- [Ethereum per sviluppatori Dart](/developers/docs/programming-languages/dart/)
- [Ethereum per sviluppatori Delphi](/developers/docs/programming-languages/delphi/)
- [Ethereum per sviluppatori .NET](/developers/docs/programming-languages/dot-net/)
-- [Ethereum per gli sviluppatori Elixir](/developers/docs/programming-languages/elixir/)
+- [Ethereum per sviluppatori Elixir](/developers/docs/programming-languages/elixir/)
- [Ethereum per sviluppatori Go](/developers/docs/programming-languages/golang/)
- [Ethereum per sviluppatori Java](/developers/docs/programming-languages/java/)
- [Ethereum per sviluppatori JavaScript](/developers/docs/programming-languages/javascript/)
@@ -23,8 +24,8 @@ Seleziona il linguaggio di programmazione che preferisci per trovare progetti, r
- [Ethereum per sviluppatori Ruby](/developers/docs/programming-languages/ruby/)
- [Ethereum per sviluppatori Rust](/developers/docs/programming-languages/rust/)
-### Cosa succede se il mio linguaggio non è supportato {#other-lang}
+### E se il mio linguaggio non fosse supportato? {#other-lang}
-Se vuoi collegarti alle risorse o puntare a una community virtuale per un linguaggio di programmazione aggiuntivo, puoi richiedere una nuova pagina [aprendo una segnalazione](https://github.com/ethereum/ethereum-org-website/issues/new/choose).
+Se desideri collegare risorse o indicare una community virtuale per un linguaggio di programmazione aggiuntivo, puoi richiedere una nuova pagina [aprendo una issue](https://github.com/ethereum/ethereum-org-website/issues/new/choose).
-Se vuoi solo scrivere il codice sull'interfaccia con la blockchain usando un linguaggio attualmente non supportato, puoi usare l'[interfaccia JSON-RPC](/developers/docs/apis/json-rpc/) per connetterti alla rete di Ethereum. Ogni linguaggio di programmazione che può usare TCP/IP può usare quest'interfaccia.
+Se vuoi solo scrivere codice per interfacciarti con la blockchain usando un linguaggio attualmente non supportato, puoi usare l'[interfaccia JSON-RPC](/developers/docs/apis/json-rpc/) per connetterti alla rete di Ethereum. Qualsiasi linguaggio di programmazione in grado di usare TCP/IP può usare questa interfaccia.
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/java/index.md b/public/content/translations/it/developers/docs/programming-languages/java/index.md
index c8e79bc762f..0f2518633f3 100644
--- a/public/content/translations/it/developers/docs/programming-languages/java/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/java/index.md
@@ -1,5 +1,5 @@
---
-title: Ethereum per sviluppatori Java
+title: Ethereum per gli sviluppatori Java
description: Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Java
lang: it
incomplete: true
@@ -7,57 +7,57 @@ incomplete: true
Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Java
-Usa Ethereum per creare applicazioni decentralizzate (dette "dapp") che sfruttano i vantaggi delle criptovalute e della tecnologia blockchain. Queste dapp sono attendibili perché, una volta "caricate" su Ethereum, vengono eseguite sempre come sono state programmate. Possono controllare risorse digitali per creare nuove tipologie di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibile da censurare.
+Usa Ethereum per creare applicazioni decentralizzate (o "dApp") che sfruttano i vantaggi della criptovaluta e della tecnologia blockchain. Queste dApp possono essere affidabili, il che significa che una volta distribuite su Ethereum, verranno sempre eseguite come programmate. Possono controllare risorse digitali al fine di creare nuovi tipi di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibili da censurare.
-## Primi passi con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
+## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
-**Operazioni di base per integrare Java con Ethereum**
+**Fai i tuoi primi passi per integrare Java con Ethereum**
-Hai prima bisogno di nozioni di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers.](/developers/)
+Hai prima bisogno di un'introduzione più basilare? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers.](/developers/)
-- [Blockchain Explained](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Comprendere i Contratti Intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Scrivi il tuo Primo Contratto Intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Learn How to Compile and Deploy Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Spiegazione della Blockchain](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Comprendere i contratti intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Scrivi il tuo primo contratto intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Scopri come compilare e distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-## Lavorare con client Ethereum {#working-with-ethereum-clients}
+## Lavorare con i client di Ethereum {#working-with-ethereum-clients}
-Scopri come utilizzare [Web3J](https://github.com/web3j/web3j) e Hyperledger Besu, due dei principali client Java Ethereum
+Scopri come usare [Web3J](https://github.com/web3j/web3j) e Hyperledger Besu, due dei principali client di Ethereum in Java
-- [Connecting to an Ethereum client with Java, Eclipse, and Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
-- [Gestire un conto di Ethereum con Java e Web3j](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j)
-- [Genera un Java Wrapper dal tuo Contratto Intelligente](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
-- [Interagire con un Contratto Intelligente di Ethereum](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
-- [Ascoltare per Eventi del Contratto Intelligente di Ethereum](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
-- [Using Besu (Pantheon), the Java Ethereum Client with Linux](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
-- [Running a Hyperledger Besu (Pantheon) Node in Java Integration Tests](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
-- [Web3j Cheat Sheet](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c)
+- [Connettersi a un client di Ethereum con Java, Eclipse e Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j)
+- [Gestire un account di Ethereum con Java e Web3j](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j)
+- [Generare un Wrapper Java dal tuo contratto intelligente](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract)
+- [Interagire con un contratto intelligente di Ethereum](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java)
+- [Ascoltare gli eventi del contratto intelligente di Ethereum](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java)
+- [Usare Besu (Pantheon), il client di Ethereum in Java con Linux](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux)
+- [Eseguire un nodo Hyperledger Besu (Pantheon) nei test di integrazione Java](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests)
+- [Cheat Sheet di Web3j]()
-Scopri come utilizzare [ethers-kt](https://github.com/Kr1ptal/ethers-kt), una libreria Kotlin asincrona e ad alte prestazioni per interagire con le blockchain basate sull'EVM. Si occupando delle piattaforme JVM e Android.
-- [Transfer ERC20 tokens](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
-- [UniswapV2 swap with event listening](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
-- [ETH / ERC20 balance tracker](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
+Scopri come usare [ethers-kt](https://github.com/Kr1ptal/ethers-kt), una libreria Kotlin asincrona e ad alte prestazioni per interagire con le blockchain basate su EVM. Destinata alle piattaforme JVM e Android.
+- [Trasferire token ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt)
+- [Scambio su UniswapV2 con ascolto degli eventi](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt)
+- [Tracciatore di saldo ETH / ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt)
-## Articoli di livello intermedio {#intermediate-articles}
+## Articoli intermedi {#intermediate-articles}
-- [Managing storage in a Java application with IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
-- [Manage ERC20 tokens in Java with Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j)
-- [Web3j Transaction Managers](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
+- [Gestire l'archiviazione in un'applicazione Java con IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs)
+- [Gestire i token ERC20 in Java con Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j)
+- [Gestori delle transazioni di Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers)
-## Modelli d'uso avanzati {#advanced-use-patterns}
+## Modelli di utilizzo avanzati {#advanced-use-patterns}
-- [Usare Eventum per costruire la cache dei dati di un contratto intelligente in Java](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache)
+- [Usare Eventeum per creare una cache di dati del contratto intelligente in Java](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache)
-## Progetti e strumenti di Java {#java-projects-and-tools}
+## Progetti e strumenti Java {#java-projects-and-tools}
-- [Web3J (Library for Interacting with Ethereum Clients)](https://github.com/web3j/web3j)
-- [ethers-kt (Async, high-performance Kotlin/Java/Android library for EVM-based blockchains.)](https://github.com/Kr1ptal/ethers-kt)
-- [Eventeum (Event Listener)](https://github.com/ConsenSys/eventeum)
-- [Mahuta (IPFS Dev Tools)](https://github.com/ConsenSys/mahuta)
+- [Web3J (Libreria per interagire con i client di Ethereum)](https://github.com/web3j/web3j)
+- [ethers-kt (Libreria Kotlin/Java/Android asincrona e ad alte prestazioni per blockchain basate su EVM.)](https://github.com/Kr1ptal/ethers-kt)
+- [Eventeum (Ascoltatore di eventi)](https://github.com/ConsenSys/eventeum)
+- [Mahuta (Strumenti di sviluppo IPFS)](https://github.com/ConsenSys/mahuta)
Cerchi altre risorse? Dai un'occhiata a [ethereum.org/developers.](/developers/)
-## Collaboratori della community di Java {#java-community-contributors}
+## Collaboratori della community Java {#java-community-contributors}
- [IO Builders](https://io.builders)
-- [Kauri](https://kauri.io)
+- [Kauri](https://kauri.io)
\ No newline at end of file
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 81a821658c4..4d8b00b1110 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
@@ -1,73 +1,72 @@
---
-title: Ethereum per sviluppatori JavaScript
-description: Impara a sviluppare per Ethereum usando progetti e strumenti basati su JavaScript.
+title: Ethereum per gli sviluppatori JavaScript
+description: Scopri come sviluppare per Ethereum usando progetti e strumenti basati su JavaScript.
lang: it
---
-JavaScript è tra i linguaggi più popolari nell'ecosistema Ethereum. C'è persino un [team](https://github.com/ethereumjs) che si occupa di trasferire Ethereum il più possibile in JavaScript.
+JavaScript è tra i linguaggi più popolari nell'ecosistema di Ethereum. Infatti, c'è un [team](https://github.com/ethereumjs) dedicato a portare quanto più possibile di Ethereum su JavaScript.
-Esistono opportunità per scrivere in JavaScript (o simile) a [tutti i livelli dello stack](/developers/docs/ethereum-stack/).
+Ci sono opportunità per scrivere in JavaScript (o qualcosa di simile) a [tutti i livelli dello stack](/developers/docs/ethereum-stack/).
## Interagire con Ethereum {#interact-with-ethereum}
-### Librerie API JavaScript {#javascript-api-libraries}
+### Librerie di API JavaScript {#javascript-api-libraries}
-Se vuoi scrivere in JavaScript per interrogare la blockchain, inviare transazioni e altro ancora, il modo più comodo per farlo è utilizzare una [libreria API JavaScript](/developers/docs/apis/javascript/). Queste API consentono agli sviluppatori di interagire facilmente con i [nodi della rete Ethereum](/developers/docs/nodes-and-clients/).
+Se desideri scrivere in JavaScript per interrogare la blockchain, inviare transazioni e altro ancora, il modo più conveniente per farlo è usare una [libreria di API JavaScript](/developers/docs/apis/javascript/). Queste API consentono agli sviluppatori di interagire facilmente con i [nodi nella rete di Ethereum](/developers/docs/nodes-and-clients/).
-Puoi utilizzare queste librerie per interagire con i contratti intelligenti su Ethereum, quindi è possibile creare una dapp in cui, semplicemente, utilizzi JavaScript per interagire con i contratti pre-esistenti.
+Puoi usare queste librerie per interagire con i contratti intelligenti su Ethereum, in modo che sia possibile creare una dApp in cui usi semplicemente JavaScript per interagire con contratti preesistenti.
-**Dai un'occhiata a:**
+**Dai un'occhiata a**
-- [Web3.js](https://web3js.readthedocs.io/)
-- [Ethers.js](https://docs.ethers.io/) _– Contiene l'implementazione del portafoglio di Ethereum e le utility in JavaScript e TypeScript._
-- [viem](https://viem.sh): un'interfaccia TypeScript per Ethereum che fornisce primitivi con assenza di stato di basso livello per interagire con Ethereum.
+- [Web3.js](https://web3js.readthedocs.io)
+- [Ethers.js](https://ethers.org) – _include l'implementazione di un portafoglio Ethereum e utilità in JavaScript e TypeScript._
+- [viem](https://viem.sh) – _un'interfaccia TypeScript per Ethereum che fornisce primitive senza stato di basso livello per interagire con Ethereum._
+- [Drift](https://ryangoree.github.io/drift/) – _una meta-libreria TypeScript con caching integrato, hook e mock di test per uno sviluppo su Ethereum senza sforzo attraverso le librerie web3._
### Contratti intelligenti {#smart-contracts}
-Se sei uno sviluppatore JavaScript e vorresti scrivere il tuo contratto intelligente, consigliamo di familiarizzare con [Solidity](https://solidity.readthedocs.io). Questo è il linguaggio di contratti intelligenti più popolare ed è sintatticamente simile a JavaScript, che lo rende più facile da imparare.
+Se sei uno sviluppatore JavaScript e vuoi scrivere il tuo contratto intelligente, potresti voler familiarizzare con [Solidity](https://solidity.readthedocs.io). Questo è il linguaggio per contratti intelligenti più popolare ed è sintatticamente simile a JavaScript, il che potrebbe renderlo più facile da imparare.
-Di più sui [contratti intelligenti](/developers/docs/smart-contracts/).
+Maggiori informazioni sui [contratti intelligenti](/developers/docs/smart-contracts/).
## Comprendere il protocollo {#understand-the-protocol}
-### La macchina virtuale Ethereum {#the-ethereum-virtual-machine}
+### La macchina virtuale di Ethereum {#the-ethereum-virtual-machine}
-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.
+Esiste un'implementazione in JavaScript della [macchina virtuale di Ethereum](/developers/docs/evm/). Supporta le ultime regole di biforcazione. Le regole di biforcazione si riferiscono alle modifiche apportate all'EVM a seguito di aggiornamenti pianificati.
-È suddivisa in vari pacchetti JavaScript che puoi leggere per comprendere meglio:
+È suddivisa in vari pacchetti JavaScript che puoi consultare per comprendere meglio:
-- Conti
+- Account
- Blocchi
- La blockchain stessa
- Transazioni
-- E molto altro...
+- E altro ancora...
-Ciò ti aiuterà a comprendere cose come "cos'è la struttura dei dati di un conto?".
+Questo ti aiuterà a capire cose come "qual è la struttura dei dati di un account?".
-Se preferisci invece leggere codice, questo codice JavaScript può essere un'alternativa interessante alla lettura della nostra documentazione.
+Se preferisci leggere il codice, questo JavaScript potrebbe essere un'ottima alternativa alla lettura della nostra documentazione.
-**Guarda il monorepo**
-[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-vm)
+**Dai un'occhiata all'EVM**
+[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm)
### Nodi e client {#nodes-and-clients}
-Un client di Ethereumjs è in sviluppo attivo e ti consentirà di approfondire il funzionamento dei client di Ethereum in un linguaggio che comprendi: JavaScript!
+Un client Ethereumjs è in fase di sviluppo attivo e ti consente di approfondire il funzionamento dei client di Ethereum in un linguaggio che comprendi: JavaScript!
-Era ospitato in una [`repository`](https://github.com/ethereumjs/ethereumjs-client) indipendente, tuttavia, è stato in seguito unito nella repository singola di EthereumVM come pacchetto.
-
-**Guarda il client**
-[`ethereumjs-client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
+**Dai un'occhiata al client**
+[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client)
## Altri progetti {#other-projects}
-Ci sono molte altre novità nel mondo di JavaScript per Ethereum, tra cui:
+Ci sono anche molte altre cose in corso nel mondo di Ethereum JavaScript, tra cui:
-- librerie di utilità per i portafogli.
-- strumenti per generare, importare ed esportare chiavi Ethereum.
-- un'implementazione di `merkle-patricia-tree`, una struttura di dati delineata nel yellow paper di Ethereum.
+- librerie di utilità per portafogli.
+- strumenti per generare, importare ed esportare chiavi di Ethereum.
+- un'implementazione del `merkle-patricia-tree` – una struttura dati delineata nello yellow paper di Ethereum.
-Approfondisci ciò che ti interessa maggiormente sulla [repository EthereumJS](https://github.com/ethereumjs)
+Approfondisci ciò che ti interessa di più nella [repository di EthereumJS](https://github.com/ethereumjs)
## Letture consigliate {#further-reading}
-_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/python/index.md b/public/content/translations/it/developers/docs/programming-languages/python/index.md
index 9fbcda44cbc..25d8b92451c 100644
--- a/public/content/translations/it/developers/docs/programming-languages/python/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/python/index.md
@@ -1,90 +1,99 @@
---
-title: Ethereum per sviluppatori Python
-description: Impara a sviluppare per Ethereum usando progetti e strumenti basati su Python
+title: Ethereum per gli sviluppatori Python
+description: Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Python
lang: it
incomplete: true
---
-Impara a sviluppare per Ehereum, utilizzando progetti e strumenti basati su Python
+Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Python
-Usa Ethereum per creare applicazioni decentralizzate (dette "dapp") che sfruttano i vantaggi delle criptovalute e della tecnologia blockchain. Queste dapp sono attendibili perché, una volta "caricate" su Ethereum, vengono eseguite sempre come sono state programmate. Possono controllare risorse digitali per creare nuove tipologie di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibile da censurare.
+Usa Ethereum per creare applicazioni decentralizzate (o "dApp") che sfruttano i vantaggi della criptovaluta e della tecnologia blockchain. Queste dApp possono essere affidabili, il che significa che una volta distribuite su Ethereum, verranno sempre eseguite come programmate. Possono controllare risorse digitali al fine di creare nuovi tipi di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibili da censurare.
-## Primi passi con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
+## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
-**Operazioni di base per integrare Python con Ethereum**
+**Fai i tuoi primi passi per integrare Python con Ethereum**
-Hai prima bisogno di nozioni di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
+Hai prima bisogno di un'introduzione più basilare? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
-- [Blockchain Explained](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Comprendere i Contratti Intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Scrivi il tuo Primo Contratto Intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Learn How to Compile and Deploy Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Spiegazione della Blockchain](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Comprendere i contratti intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Scrivi il tuo primo contratto intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Scopri come compilare e distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Rapporto sullo stato di Python nella blockchain nel 2023](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
-## Articoli per chi inizia ora {#beginner-articles}
+## Articoli per principianti {#beginner-articles}
-- [Guida di uno sviluppatore (Python) a Ethereum](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/)
-- [Report 2023 sullo stato di Python in blockchain](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023)
-- [Introduzione agli Smart Contract con Vyper (in inglese)](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
-- [Distribuisci il tuo Token ERC20 con Python e Brownie](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
-- [Come sviluppare un contratto Ethereum usando Python Flask (in inglese)](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
-- [Introduzione a Web3.py · Ethereum per sviluppatori Python (in inglese)](https://www.dappuniversity.com/articles/web3-py-intro)
-- [Come chiamare la funzione di uno Smart Contract usando Python e web3.py (in inglese)](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
+- [Panoramica di web3.py](https://web3py.readthedocs.io/en/latest/overview.html)
+- [Tour dell'ecosistema Python di Ethereum](https://snakecharmers.ethereum.org/python-ecosystem/)
+- [Guida a Ethereum per sviluppatori (Python)](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/)
+- [Prize-Worthy: una guida agli hackathon Python di Ethereum](https://snakecharmers.ethereum.org/prize-worthy/)
+- [Un'introduzione ai contratti intelligenti con Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/)
+- [Come sviluppare un contratto Ethereum usando Python Flask?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e)
+- [Introduzione a Web3.py · Ethereum per sviluppatori Python](https://www.dappuniversity.com/articles/web3-py-intro)
+- [Come chiamare una funzione di un contratto intelligente usando Python e web3.py](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py)
## Articoli di livello intermedio {#intermediate-articles}
-- [Dapp Development for Python Programmers](https://www.youtube.com/watch?v=tE-8bG35VNw)
-- [Creating a Python Ethereum Interface: Part 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d)
-- [Contratti Intelligenti di Ethereum su Python: una guida (quasi) completa](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
-- [Usare Brownie e Python per distribuire i Contratti Intelligenti](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
-- [Creare NFT su OpenSea con Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
+- [Amici di web3.py: introduzione ad Ape](https://snakecharmers.ethereum.org/intro-to-ape/)
+- [Sviluppo di dApp per programmatori Python](https://www.youtube.com/watch?v=tE-8bG35VNw)
+- [Creare un'interfaccia Ethereum in Python: Parte 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d)
+- [Contratti intelligenti di Ethereum in Python: una guida (quasi) completa](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988)
## Modelli d'uso avanzati {#advanced-use-patterns}
-- [Compilazione, distribuzione e chiamata del contratto intelligente di Ethereum usando Python](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
-- [Analizzare i Contratti Intelligenti in Solidity con Slither](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
-- [Blockchain Fintech Tutorial: Lending and Borrowing With Python](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
+- [Modelli di web3.py: iscrizioni agli eventi in tempo reale](https://snakecharmers.ethereum.org/subscriptions/)
+- [Modelli di web3.py: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/)
+- [Compilare, distribuire e chiamare un contratto intelligente di Ethereum usando Python](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/)
+- [Analizzare i contratti intelligenti in Solidity con Slither](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither)
+- [Tutorial Fintech sulla Blockchain: prestare e prendere in prestito con Python](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/)
+
+## Articoli archiviati
+
+- [Distribuisci il tuo token ERC20 con Python e Brownie](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58)
+- [Usare Brownie e Python per distribuire contratti intelligenti](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp)
+- [Creare NFT su OpenSea con Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/)
-## Progetti e strumenti di Python {#python-projects-and-tools}
+## Progetti e strumenti Python {#python-projects-and-tools}
### Attivi: {#active}
- [Web3.py](https://github.com/ethereum/web3.py) - _Libreria Python per interagire con Ethereum_
-- [Vyper](https://github.com/ethereum/vyper/) - _Linguaggio dei Contratti Intelligenti di Python per l'EVM_
-- [Ape](https://github.com/ApeWorX/ape) - _Lo strumento di sviluppo di contratti intelligenti per utilizzatori di Python, Scienziati dei Dati e Professionisti della Sicurezza_
-- [py-evm](https://github.com/ethereum/py-evm) - _Implementazione della macchina virtuale Ethereum_
-- [eth-tester](https://github.com/ethereum/eth-tester) - _Strumenti per testare le applicazioni basate su Ethereum_
-- [eth-utils](https://github.com/ethereum/eth-utils/) - _Funzioni di utilità per lavorare con le basi di codice legate a Ethereum_
+- [Vyper](https://github.com/ethereum/vyper/) - _Linguaggio per contratti intelligenti in stile Python per la EVM_
+- [Ape](https://github.com/ApeWorX/ape) - _Lo strumento di sviluppo di contratti intelligenti per programmatori Python, scienziati dei dati e professionisti della sicurezza_
+- [py-evm](https://github.com/ethereum/py-evm) - _implementazione della macchina virtuale di Ethereum_
+- [eth-tester](https://github.com/ethereum/eth-tester) - _strumenti per testare applicazioni basate su Ethereum_
+- [eth-utils](https://github.com/ethereum/eth-utils/) - _funzioni di utilità per lavorare con basi di codice relative a Ethereum_
- [py-solc-x](https://pypi.org/project/py-solc-x/) - _Wrapper Python per il compilatore Solidity solc con supporto per 0.5.x_
- [pymaker](https://github.com/makerdao/pymaker) - _API Python per i contratti Maker_
-- [siwe](https://github.com/signinwithethereum/siwe-py) - _Accesso con Ethereum (siwe) per Python_
-- [DeFi di Web3 per le integrazioni di Ethereum](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _Un pacchetto di Python con integrazioni pronte per l'ERC-20, Uniswap e altri progetti popolari_
-- [Wake](https://getwake.io) - _Assetto completo di Python per testare i contratti, fuzzing, distribuzione, scansione delle vulnerabilità e navigazione del codice (server del linguaggio: [Tools for Solidity](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
+- [siwe](https://github.com/signinwithethereum/siwe-py) - _Accedi con Ethereum (siwe) per Python_
+- [Web3 DeFi per integrazioni Ethereum](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _Un pacchetto Python con integrazioni pronte per ERC-20, Uniswap e altri progetti popolari_
+- [Wake](https://getwake.io) - _Framework Python all-in-one per test dei contratti, fuzzing, distribuzione, scansione delle vulnerabilità e navigazione del codice (server di linguaggio - [Strumenti per Solidity](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_
-### Archiviato / Non più mantenuto: {#archived--no-longer-maintained}
+### Archiviati / Non più mantenuti: {#archived--no-longer-maintained}
-- [Trinity](https://github.com/ethereum/trinity) - _Il client Python di Ethereum_
-- [Mamba](https://github.com/arjunaskykok/mamba) - _Framework per scrivere, compilare e distribuire contratti intelligenti scritti nel linguaggio Vyper_
-- [Brownie](https://github.com/eth-brownie/brownie) - _Framework di Python per distribuire, testare e interagire con i contratti intelligenti di Ethereum_
-- [pydevp2p](https://github.com/ethereum/pydevp2p) - _implementazione dello stack di Ethereum P2P_
-- [py-wasm](https://github.com/ethereum/py-wasm) - _Implementazione Python dell'interprete di web assembly_
+- [Trinity](https://github.com/ethereum/trinity) - _Client Python per Ethereum_
+- [Mamba](https://github.com/arjunaskykok/mamba) - _framework per scrivere, compilare e distribuire contratti intelligenti scritti nel linguaggio Vyper_
+- [Brownie](https://github.com/eth-brownie/brownie) - _Framework Python per distribuire, testare e interagire con i contratti intelligenti di Ethereum_
+- [pydevp2p](https://github.com/ethereum/pydevp2p) - _implementazione dello stack P2P di Ethereum_
+- [py-wasm](https://github.com/ethereum/py-wasm) - _Implementazione Python dell'interprete WebAssembly_
Cerchi altre risorse? Dai un'occhiata a [ethereum.org/developers](/developers/).
-## Progetti che utilizzano gli strumenti Python {#projects-using-python-tooling}
+## Progetti che usano strumenti Python {#projects-using-python-tooling}
-I seguenti progetti basati su Ethereum usano strumenti menzionati su questa pagina. Le repository open source correlate fungono da riferimento utile per il codice d'esempio e le migliori pratiche.
+I seguenti progetti basati su Ethereum usano gli strumenti menzionati in questa pagina. I relativi repository open-source fungono da buon riferimento per codice di esempio e migliori pratiche.
-- [Yearn Finance](https://yearn.finance/) e [Repository di Yearn Vault Contracts](https://github.com/yearn/yearn-vaults)
-- [Curve](https://curve.fi/) e la [repository dei contratti intelligenti di Curve](https://github.com/curvefi/curve-contract)
+- [Yearn Finance](https://yearn.finance/) e il [repository dei contratti Yearn Vault](https://github.com/yearn/yearn-vaults)
+- [Curve](https://www.curve.finance/) e il [repository dei contratti intelligenti di Curve](https://github.com/curvefi/curve-contract)
- [BadgerDAO](https://badger.com/) e i [contratti intelligenti che usano la toolchain di Brownie](https://github.com/Badger-Finance/badger-system)
-- [Sushi](https://sushi.com/) usa [Python nella gestione e distribuzione dei suoi vesting contract](https://github.com/sushiswap/sushi-vesting-protocols)
-- [Alpha Venture DAO](https://alphaventuredao.io/), di Alpha Homora, usa [Brownie per testare e distribuire i contratti intelligenti](https://github.com/AlphaFinanceLab/alpha-staking-contract)
+- [Sushi](https://sushi.com/) usa [Python per gestire e distribuire i propri contratti di maturazione (vesting)](https://github.com/sushiswap/sushi-vesting-protocols)
+- [Alpha Finance](https://alphaventuredao.io/), famoso per Alpha Homora, usa [Brownie per testare e distribuire contratti intelligenti](https://github.com/AlphaFinanceLab/alpha-staking-contract)
-## Discussione della Community di Python {#python-community-contributors}
+## Discussioni della community Python {#python-community-contributors}
-- [Discor dell'Ethereum Python Community](https://discord.gg/9zk7snTfWe) per Web3.py e altre discussioni del quadro di Python
-- [Discord di Vyper](https://discord.gg/SdvKC79cJk) per la discussione sulla programmazione dei contratti intelligenti in Vyper
+- [Discord della community Python di Ethereum](https://discord.gg/9zk7snTfWe) per discussioni su Web3.py e altri framework Python
+- [Discord di Vyper](https://discord.gg/SdvKC79cJk) per discussioni sulla programmazione di contratti intelligenti in Vyper
## Altri elenchi aggregati {#other-aggregated-lists}
-La wiki di Vyper contiene un [incredibile elenco di risorse per Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources)
\ No newline at end of file
+La wiki di Vyper ha un'[incredibile lista di risorse per Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/ruby/index.md b/public/content/translations/it/developers/docs/programming-languages/ruby/index.md
index 78b485b302f..bc688e2a44b 100644
--- a/public/content/translations/it/developers/docs/programming-languages/ruby/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/ruby/index.md
@@ -1,60 +1,60 @@
---
title: Ethereum per gli sviluppatori Ruby
-description: Impara a sviluppare per Ethereum usando progetti e strumenti basati su Ruby.
+description: Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Ruby.
lang: it
incomplete: false
---
-Impara a sviluppare per Ethereum usando progetti e strumenti basati su Ruby.
+Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Ruby.
-Usa Ethereum per creare applicazioni decentralizzate (dette "dapp") che sfruttano i vantaggi delle criptovalute e della tecnologia blockchain. Queste dapp possono essere senza fiducia, a significare che una volta distribuite su Ethereum, saranno sempre eseguite come programmate. Possono controllare risorse digitali per creare nuove tipologie di applicazioni finanziarie. Possono essere decentralizzate, pertanto nessuna entità singola o individuo le controlla e sono quasi impossibili da censurare.
+Usa Ethereum per creare applicazioni decentralizzate (o "dApp") che sfruttano i vantaggi della criptovaluta e della tecnologia blockchain. Queste dApp possono essere trustless (senza bisogno di fiducia), il che significa che una volta distribuite su Ethereum, verranno sempre eseguite come programmato. Possono controllare asset digitali per creare nuovi tipi di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibili da censurare.
-## Primi passi con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
+## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
-**Inizia a integrare Ruby con Ethereum**
+**Muovi i primi passi per integrare Ruby con Ethereum**
-Ti servono prima le nozioni di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
+Hai prima bisogno di un'introduzione di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
-- [Blockchain Explained](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Comprendere i Contratti Intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Scrivi il tuo Primo Contratto Intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Impara Come Compilare e Distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Spiegazione della blockchain](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Comprendere i contratti intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Scrivi il tuo primo contratto intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Scopri come compilare e distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-## Articoli per chi inizia ora {#beginner-articles}
+## Articoli per principianti {#beginner-articles}
-- [Comprendere definitivamente i conti di Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
-- [Autenticare definitivamente gli utenti di Rails con Metamask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
+- [Comprendere finalmente gli account di Ethereum](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe)
+- [Autenticare finalmente gli utenti Rails con MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj)
- [Come connettersi alla rete di Ethereum usando Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby)
-- [Come generare un nuovo indirizzo di Ethereum in Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
+- [Come generare un nuovo indirizzo Ethereum in Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby)
## Articoli di livello intermedio {#intermediate-articles}
-- [App della Blockchain con Ruby](https://www.nopio.com/blog/blockchain-app-ruby/)
-- [Usa Ruby, connesso a Ethereum, per eseguire il Contratto Intelligente](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
+- [App blockchain con Ruby](https://www.nopio.com/blog/blockchain-app-ruby/)
+- [Usare Ruby, connesso a Ethereum, per eseguire il contratto intelligente](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9)
## Progetti e strumenti Ruby {#ruby-projects-and-tools}
### Attivi {#active}
-- [eth.rb](https://github.com/q9f/eth.rb): _Libreria di Ruby e client RPC per gestire conti, messaggi e transazioni di Ethereum_
-- [keccak.rb](https://github.com/q9f/keccak.rb) - _L'hash di The Keccak (SHA3) usato da Ethereum_
-- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _Implementazione in Ruby dell'Accesso con Ethereum_
-- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _Gemma di Rails che aggiunge la firma locale SIWE nei percorsi_
-- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _Esempio di SIWE usando Ruby on Rails con un controller personalizzato_
-- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _Strategia di OmniAuth per l’Accesso con Ethereum (SIWE)_
-- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _Strategia di OmniAuth per autenticarsi tramite il possesso di NFT_
-- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _Modello di Ethereum on Rails che consente di connettere MetaMask a Ruby on Rails_
+- [eth.rb](https://github.com/q9f/eth.rb) - _Libreria Ruby e client RPC per gestire account, messaggi e transazioni di Ethereum_
+- [keccak.rb](https://github.com/q9f/keccak.rb) - _L'hash Keccak (SHA3) usato da Ethereum_
+- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) - _Implementazione Ruby di Sign-In with Ethereum_
+- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) - _Gemma Rails che aggiunge percorsi di accesso locale SIWE_
+- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) - _Esempio SIWE che usa Ruby on Rails con controller personalizzato_
+- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) - _Strategia OmniAuth per Sign In With Ethereum (SIWE)_
+- [omniauth-nft](https://github.com/valthon/omniauth-nft) - _Strategia OmniAuth per l'autenticazione tramite la proprietà di NFT_
+- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) - _Modello Ethereum on Rails che consente di connettere MetaMask a Ruby on Rails_
-### Archiviato / Non più mantenuto {#archived--no-longer-maintained}
+### Archiviati / Non più mantenuti {#archived--no-longer-maintained}
-- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _Metodi di chiamata RPC del nodo di Ethereum con Ruby_
-- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _Libreria di Ruby per generare indirizzi ETH da un portafoglio Deterministico Gerarchico secondo lo standard BIP32_
+- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) - _Chiamare metodi RPC del nodo Ethereum con Ruby_
+- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) - _Libreria Ruby per generare indirizzi ETH da un portafoglio deterministico gerarchico secondo lo standard BIP32_
- [etherlite](https://github.com/budacom/etherlite) - _Integrazione di Ethereum per Ruby on Rails_
-- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _Client di Ethereum in Ruby che usa l'interfaccia JSON-RPC per inviare transazioni, creare e interagire coi contratti, nonché utili toolkit per lavorare coi nodi di Ethereum_
+- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) - _Client Ethereum in Ruby che usa l'interfaccia JSON-RPC per inviare transazioni, creare e interagire con i contratti, oltre a un utile kit di strumenti per lavorare con il nodo Ethereum_
- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) - _Implementa la strategia del provider Ethereum per OmniAuth_
-Cerchi altre risorse? Dai un'occhiata alla [nostra home dello Sviluppatore](/developers/).
+Cerchi altre risorse? Dai un'occhiata alla [nostra pagina per sviluppatori](/developers/).
## Collaboratori della community Ruby {#ruby-community-contributors}
-Il [Gruppo Ethereum Ruby Telegram](https://t.me/ruby_eth) ospita una community in rapida crescita ed è la risorsa dedicata alle discussioni su ognuno dei suddetti progetti e argomenti correlati.
+Il [gruppo Telegram Ethereum Ruby](https://t.me/ruby_eth) ospita una community in rapida crescita ed è la risorsa dedicata per le discussioni su uno qualsiasi dei progetti sopra indicati e sugli argomenti correlati.
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/programming-languages/rust/index.md b/public/content/translations/it/developers/docs/programming-languages/rust/index.md
index 15a16b6bfa9..f474db03556 100644
--- a/public/content/translations/it/developers/docs/programming-languages/rust/index.md
+++ b/public/content/translations/it/developers/docs/programming-languages/rust/index.md
@@ -1,57 +1,57 @@
---
-title: Ethereum per sviluppatori Rust
-description: Impara a sviluppare per Ethereum usando progetti e strumenti basati su Rust
+title: Ethereum per gli sviluppatori Rust
+description: Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Rust
lang: it
incomplete: true
---
-Impara a sviluppare per Ehereum, utilizzando progetti e strumenti basati su Rust
+Scopri come sviluppare per Ethereum usando progetti e strumenti basati su Rust
-Usa Ethereum per creare applicazioni decentralizzate (dette "dapp") che sfruttano i vantaggi delle criptovalute e della tecnologia blockchain. Queste dapp sono attendibili perché, una volta "caricate" su Ethereum, vengono eseguite sempre come sono state programmate. Possono controllare risorse digitali per creare nuove tipologie di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibile da censurare.
+Usa Ethereum per creare applicazioni decentralizzate (o "dApp") che sfruttano i vantaggi della criptovaluta e della tecnologia blockchain. Queste dApp possono essere affidabili, il che significa che una volta distribuite su Ethereum, verranno sempre eseguite come programmate. Possono controllare risorse digitali al fine di creare nuovi tipi di applicazioni finanziarie. Possono essere decentralizzate, il che significa che nessuna singola entità o persona le controlla e sono quasi impossibili da censurare.
-## Primi passi con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
+## Iniziare con i contratti intelligenti e il linguaggio Solidity {#getting-started-with-smart-contracts-and-solidity}
-**Operazioni di base per integrare Rust con Ethereum**
+**Fai i tuoi primi passi per integrare Rust con Ethereum**
-Hai prima bisogno di nozioni di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
+Hai prima bisogno di un'introduzione di base? Dai un'occhiata a [ethereum.org/learn](/learn/) o [ethereum.org/developers](/developers/).
-- [Blockchain Explained](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
-- [Comprendere i Contratti Intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
-- [Scrivi il tuo Primo Contratto Intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
-- [Learn How to Compile and Deploy Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
+- [Spiegazione della Blockchain](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained)
+- [Comprendere i contratti intelligenti](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract)
+- [Scrivi il tuo primo contratto intelligente](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract)
+- [Scopri come compilare e distribuire Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment)
-## Articoli per chi inizia ora {#beginner-articles}
+## Articoli per principianti {#beginner-articles}
-- [The Rust Ethereum Client](https://openethereum.github.io/) \* **Notare che OpenEthereum [è ormai superato](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) e non viene più mantenuto.** Usalo con cautela e preferibilmente passa a un'altra implementazione client.
-- [Sending Transaction to Ethereum Using Rust](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
-- [Tutorial passo-passo per scrivere contratti in rust Wasm per Kovan (in inglese)](https://github.com/paritytech/pwasm-tutorial)
+- [Il client Ethereum in Rust](https://openethereum.github.io/) \* **Nota che OpenEthereum [è stato deprecato](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) e non è più mantenuto.** Usalo con cautela e preferibilmente passa a un'altra implementazione del client.
+- [Inviare una transazione a Ethereum usando Rust](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/)
+- [Un tutorial passo-passo su come scrivere contratti in Rust Wasm per Kovan](https://github.com/paritytech/pwasm-tutorial)
## Articoli di livello intermedio {#intermediate-articles}
## Modelli d'uso avanzati {#advanced-use-patterns}
-- [Libreria pwasm_ethereum esterna per interagire con reti di tipo Ethereum (in inglese)](https://github.com/openethereum/pwasm-ethereum)
-- [Creare una chat decentralizzata usando JavaScript e Rust (in inglese)](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
-- [Creare un'app decentralizzata Todo usando Vue.js e Rust (in inglese)](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
+- [Libreria di extern pwasm_ethereum per interagire con una rete simile a Ethereum](https://github.com/openethereum/pwasm-ethereum)
+- [Costruire una chat decentralizzata usando JavaScript e Rust](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52)
+- [Costruire un'app Todo decentralizzata usando Vue.js e Rust](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb)
-- [Costruisci una blockchain in Rust](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
+- [Costruire una blockchain in Rust](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/)
-## Progetti e strumenti di Rust {#rust-projects-and-tools}
+## Progetti e strumenti in Rust {#rust-projects-and-tools}
-- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _Raccolta di esterni per interagire con reti simili a Ethereum_
-- [Lighthouse](https://github.com/sigp/lighthouse) - _Client veloce del livello di consenso di Ethereum_
-- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _Rivisitazione proposta del livello di esecuzione del contratto intelligente di Ethereum, utilizzando un sottoinsieme deterministico di WebAssembly_
-- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _Riferimento API di OASIS_
-- [Solaris](https://github.com/paritytech/sol-rs) - _Test unitario dei contratti intelligenti in Solidity che sfrutta l'utilizzo dell'EVM nativa del Client di Parity._
-- [SputnikVM](https://github.com/rust-blockchain/evm) - _Implementazione della Macchina Virtuale di Ethereum in Rust_
-- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Smart Contract Wavelet in Rust_
-- [Foundry](https://github.com/foundry-rs/foundry) - _Kit di strumenti per lo sviluppo di applicazioni Ethereum_
+- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _Collezione di extern per interagire con una rete simile a Ethereum_
+- [Lighthouse](https://github.com/sigp/lighthouse) - _Client veloce per il livello di consenso di Ethereum_
+- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _Proposta di riprogettazione del livello di esecuzione dei contratti intelligenti di Ethereum usando un sottoinsieme deterministico di WebAssembly_
+- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _Riferimento API OASIS_
+- [Solaris](https://github.com/paritytech/sol-rs) - _Strumento di unit test per i contratti intelligenti in Solidity usando l'EVM nativa del client Parity._
+- [SputnikVM](https://github.com/rust-blockchain/evm) - _Implementazione in Rust della macchina virtuale di Ethereum_
+- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Contratto intelligente Wavelet in Rust_
+- [Foundry](https://github.com/foundry-rs/foundry) - _Toolkit per lo sviluppo di applicazioni Ethereum_
- [Alloy](https://alloy.rs) - _Librerie ad alte prestazioni, ben testate e documentate per interagire con Ethereum e altre catene basate su EVM._
-- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _Libreria di Ethereum e implementazione di portafogli_
-- [SewUp](https://github.com/second-state/SewUp) - _Una libreria per aiutarti a creare il tuo contratto webassembly di Ethereum con Rust e sviluppare in un backend comune_
-- [Substreams](https://github.com/streamingfast/substreams): _tecnologia d'indicizzazione parallelizzata dei dati della blockchain_
-- [Reth](https://github.com/paradigmxyz/reth) Reth (abbreviazione di Rust Ethereum) è una nuova implementazione a nodo completo su Ethereum
-- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust): _Una raccolta curata di progetti nell'ecosistema di Ethereum, scritta in Rust_
+- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _Libreria Ethereum e implementazione di portafoglio_
+- [SewUp](https://github.com/second-state/SewUp) - _Una libreria per aiutarti a costruire il tuo contratto webassembly per Ethereum con Rust, proprio come se sviluppassi in un backend comune_
+- [Substreams](https://github.com/streamingfast/substreams) - _Tecnologia parallelizzata di indicizzazione dei dati della blockchain_
+- [Reth](https://github.com/paradigmxyz/reth) Reth (abbreviazione di Rust Ethereum) è una nuova implementazione di nodo completo di Ethereum
+- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Una raccolta curata di progetti nell'ecosistema Ethereum scritti in Rust_
Cerchi altre risorse? Dai un'occhiata a [ethereum.org/developers.](/developers/)
@@ -60,4 +60,4 @@ Cerchi altre risorse? Dai un'occhiata a [ethereum.org/developers.](/developers/)
- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby)
- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby)
- [Parity Gitter](https://gitter.im/paritytech/parity)
-- [Enigma](https://discord.gg/SJK32GY)
+- [Enigma](https://discord.gg/SJK32GY)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/scaling/index.md b/public/content/translations/it/developers/docs/scaling/index.md
index 86a141a6caf..e408af261cf 100644
--- a/public/content/translations/it/developers/docs/scaling/index.md
+++ b/public/content/translations/it/developers/docs/scaling/index.md
@@ -1,112 +1,118 @@
---
-title: Scalabilità
-description: Introduzione alle diverse opzioni di scalabilità attualmente in fase di sviluppo da parte della community Ethereum.
+title: "Scalabilità"
+description: "Un'introduzione alle diverse opzioni di scalabilità attualmente in fase di sviluppo da parte della comunità di Ethereum."
lang: it
sidebarDepth: 3
---
-## Panoramica della scalabilità {#scaling-overview}
+## Panoramica sulla scalabilità {#scaling-overview}
-Poiché il numero di persone che usano Ethereum è aumentato, la blockchain ha raggiunto determinati limiti di capacità. Ciò ha aumentato il costo di utilizzo della rete, creando la necessità di "soluzioni di scalabilità". Ci sono molteplici soluzioni in fase di ricerca, sperimentazione e implementazione, che adottano approcci diversi per raggiungere obiettivi simili.
+Man mano che il numero di persone che utilizzano [Ethereum](/) è cresciuto, la blockchain ha raggiunto determinati limiti di capacità. Ciò ha fatto aumentare il costo di utilizzo della rete, creando la necessità di "soluzioni di scalabilità". Ci sono molteplici soluzioni in fase di ricerca, test e implementazione che adottano approcci diversi per raggiungere obiettivi simili.
-L'obiettivo principale della scalabilità è incrementare la velocità (finalità più veloce) e il volume delle transazioni (maggior numero al secondo), senza sacrificare la decentralizzazione o la sicurezza. Sulla blockchain di livello 1 di Ethereum, l'elevata domanda comporta transazioni più lente e [prezzi del gas](/developers/docs/gas/) impraticabili. L'aumento della capacità della rete in termini di velocità e produttività è fondamentale per una significativa adozione di massa di Ethereum.
+L'obiettivo principale della scalabilità è aumentare la velocità delle transazioni (finalità più rapida) e il throughput delle transazioni (maggior numero di transazioni al secondo) senza sacrificare la decentralizzazione o la sicurezza. Sulla blockchain di Ethereum di livello 1, l'elevata domanda porta a transazioni più lente e a [prezzi del gas](/developers/docs/gas/) non sostenibili. Aumentare la capacità della rete in termini di velocità e throughput è fondamentale per un'adozione significativa e di massa di Ethereum.
-Anche se velocità e produttività sono aspetti importanti, è essenziale che le soluzioni di scalabilità che rendono possibili questi obiettivi rimangano decentralizzate e sicure. Mantenere una barriera all'ingresso bassa per gli operatori dei nodi è fondamentale per scongiurare una progressione verso una potenza di calcolo centralizzata e insicura.
+Sebbene la velocità e il throughput siano importanti, è essenziale che le soluzioni di scalabilità che consentono di raggiungere questi obiettivi rimangano decentralizzate e sicure. Mantenere bassa la barriera all'ingresso per gli operatori dei nodi è fondamentale per prevenire una progressione verso una potenza di calcolo centralizzata e insicura.
-A livello concettuale, per prima cosa occorre distinguere tra scalabilità on-chain o off-chain.
+Concettualmente, classifichiamo innanzitutto la scalabilità come scalabilità on-chain o scalabilità fuori catena.
## Prerequisiti {#prerequisites}
-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.
+Dovresti avere una buona comprensione di tutti gli argomenti fondamentali. L'implementazione di soluzioni di scalabilità è un argomento avanzato poiché la tecnologia è meno collaudata e continua a essere ricercata e sviluppata.
-## 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.
+La scalabilità on-chain richiede modifiche al protocollo di Ethereum (la [rete principale](/glossary/#mainnet) di livello 1). Per molto tempo, ci si aspettava che la frammentazione della blockchain avrebbe scalato Ethereum. Ciò avrebbe comportato la divisione della blockchain in pezzi discreti (frammenti) da far verificare a sottoinsiemi di validatori. Tuttavia, la scalabilità tramite i rollup di livello 2 ha preso il sopravvento come tecnica di scalabilità principale. Ciò è supportato dall'aggiunta di una nuova forma di dati più economica allegata ai blocchi di Ethereum, appositamente progettata per rendere i rollup economici per gli utenti.
-### Sharding {#sharding}
+### Frammentazione {#sharding}
-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.
+La frammentazione è il processo di divisione di un database. Sottoinsiemi di validatori sarebbero responsabili dei singoli frammenti piuttosto che tenere traccia di tutto Ethereum. La frammentazione è stata sul [piano d'azione](/roadmap/) di Ethereum per molto tempo, e un tempo si intendeva rilasciarla prima de La Fusione (The Merge) alla prova di stake. Tuttavia, il rapido sviluppo dei [rollup di livello 2](#layer-2-scaling) e l'invenzione del [Danksharding](/roadmap/danksharding) (l'aggiunta di blob di dati dei rollup ai blocchi di Ethereum che possono essere verificati in modo molto efficiente dai validatori) ha portato la comunità di Ethereum a favorire una scalabilità incentrata sui rollup invece della scalabilità tramite frammentazione. Questo aiuterà anche a mantenere più semplice la logica di consenso di Ethereum.
-## Scalabilità off-chain {#off-chain-scaling}
+## Scalabilità fuori catena {#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.
+Le soluzioni fuori catena sono implementate separatamente dalla rete principale di livello 1: non richiedono modifiche al protocollo di Ethereum esistente. Alcune soluzioni, note come soluzioni di "livello 2", derivano la loro sicurezza direttamente dal consenso di Ethereum di livello 1, 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 loro sicurezza separatamente dalla rete principale, come le [catene laterali](#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 ottenere una varietà di obiettivi.
### Scalabilità di livello 2 {#layer-2-scaling}
-Questa categoria di soluzioni off-chain deriva la sua sicurezza dalla Rete principale di Ethereum.
+Questa categoria di soluzioni fuori catena deriva la sua sicurezza dalla rete principale di Ethereum.
-Livello 2 è un termine collettivo per le soluzioni progettate per aiutare a ridimensionare la tua applicazione gestendo le transazioni al di fuori della rete principale di Ethereum (livello 1), sfruttando il robusto modello di sicurezza decentralizzato della Rete principale. La velocità delle transazioni ne risente quando la rete è molto carica, e l'esperienza utente può risultare poco piacevole per alcuni tipi di dApp. E, man mano che la rete si congestiona, i prezzi del carburante aumentano mentre i mittenti delle transazioni mirano a superarsi a vicenda. Ciò può rendere l'utilizzo di Ethereum alquanto dispendioso.
+Livello 2 è un termine collettivo per le soluzioni progettate per aiutare a scalare la tua applicazione gestendo le transazioni fuori dalla rete principale di Ethereum (livello 1) pur sfruttando il robusto modello di sicurezza decentralizzato della rete principale. La velocità delle transazioni ne risente quando la rete è occupata, rendendo l'esperienza utente scadente per determinati tipi di dApp. E man mano che la rete diventa più occupata, i prezzi del gas aumentano poiché i mittenti delle transazioni mirano a superarsi a vicenda con le offerte. Questo può rendere l'utilizzo di Ethereum molto costoso.
-La maggior parte delle soluzioni di livello 2 è incentrata su un server o su un cluster di server, ognuno dei quali può essere denominato nodo, validatore, operatore, sequenziatore, produttore di blocchi o termini simili. A seconda dell'implementazione, questi nodi di livello 2 possono essere gestiti da persone, aziende o entità che li usano, da operatori terzi o da un grande gruppo di individui (in modo simile alla Rete principale). In linea generale, le transazioni vengono inviate a questi nodi di livello 2 anziché essere inviate direttamente al livello 1 (Rete principale). Per alcune soluzioni, l'istanza di livello 2 le riunisce in gruppi prima di collegarle al livello 1, a quel punto sono protette dal livello 1 e non possono essere alterate. I dettagli dell'esecuzione vera e propria variano notevolmente tra le varie tecnologie e implementazioni di livello 2.
+La maggior parte delle soluzioni di livello 2 è incentrata su un server o un cluster di server, ognuno dei quali può essere definito nodo, validatore, operatore, sequenziatore, produttore di blocchi o con un termine simile. A seconda dell'implementazione, questi nodi di livello 2 possono essere gestiti da individui, aziende o entità che li utilizzano, o da un operatore di terze parti, o da un ampio gruppo di individui (simile alla rete principale). In generale, le transazioni vengono inviate a questi nodi di livello 2 invece di essere inviate direttamente al livello 1 (rete principale). Per alcune soluzioni, l'istanza di livello 2 le raggruppa in lotti prima di ancorarle al livello 1, dopodiché sono protette dal livello 1 e non possono essere alterate. I dettagli su come ciò avvenga variano in modo significativo tra le diverse tecnologie e implementazioni di livello 2.
-Un'istanza specifica di livello 2 può essere aperta e condivisa da molte applicazioni, oppure può essere implementata da un progetto e dedicata a sostenere solo quell'applicazione specifica.
+Una specifica istanza di livello 2 può essere aperta e condivisa da molte applicazioni, oppure può essere distribuita da un progetto e dedicata a supportare solo la propria applicazione.
-#### Perché il Livello 2 è necessario? {#why-is-layer-2-needed}
+#### Perché è necessario il livello 2? {#why-is-layer-2-needed}
-- L'aumento delle transazioni al secondo migliora notevolmente l'esperienza utente e riduce la congestione della rete sulla Mainnet di Ethereum.
-- Le transazioni sono raggruppate in una singola transazione sulla Rete Principale di Ethereum, riducendo le commissioni del gas per gli utenti e rendendo Ethereum più inclusivo e accessibile per le persone da tutto il mondo.
-- Qualunque aggiornamento alla scalabilità non dovrebbe sacrificare decentralizzazione e sicurezza - il livello 2 è basato su Ethereum.
-- Esistono reti di livello 2 specifiche per le applicazioni che sfruttano le proprie efficienze lavorando con risorse su scala.
+- L'aumento delle transazioni al secondo migliora notevolmente l'esperienza utente e riduce la congestione della rete sulla rete principale di Ethereum.
+- Le transazioni vengono raggruppate (rollup) in un'unica transazione verso la rete principale di Ethereum, riducendo le commissioni per gli utenti e rendendo Ethereum più inclusivo e accessibile per le persone ovunque.
+- Qualsiasi aggiornamento alla scalabilità non dovrebbe andare a scapito della decentralizzazione o della sicurezza: il livello 2 si basa su Ethereum.
+- Esistono reti di livello 2 specifiche per le applicazioni che portano il proprio insieme di efficienze quando si lavora con risorse su larga scala.
[Maggiori informazioni sul livello 2](/layer-2/).
#### Rollup {#rollups}
-I rollup eseguono le transazioni al di fuori del livello 1, dopodiché i dati vengono pubblicati al livello 1, dove viene raggiunto il consenso. Poiché i dati della transazione sono inclusi nei blocchi del livello 1, ciò consente ai rollup di essere protetti dalla sicurezza nativa di Ethereum.
+I rollup eseguono le transazioni al di fuori del livello 1 e poi i dati vengono pubblicati sul livello 1 dove viene raggiunto il consenso. Poiché i dati delle transazioni sono inclusi nei blocchi di livello 1, ciò consente ai rollup di essere protetti dalla sicurezza nativa di Ethereum.
-Esistono due tipi di rollup con diversi modelli di sicurezza:
+Esistono due tipi di rollup con modelli di sicurezza diversi:
-- **Rollup ottimistici**: presumono che le transazioni siano valide di default ed eseguono solo il calcolo, tramite una [**prova di frode**](/glossary/#fraud-proof), nel caso di una contestazione. [Maggiori informazioni sui rollup ottimistici](/developers/docs/scaling/optimistic-rollups/).
-- **Rollup a conoscenza zero**: esegue il calcolo al di fuori della catena e invia una [**prova di validità**](/glossary/#validity-proof) alla catena. [Maggiori informazioni sui rollup a conoscenza zero](/developers/docs/scaling/zk-rollups/).
+- **Rollup ottimistici**: presumono che le transazioni siano valide per impostazione predefinita ed eseguono il calcolo, tramite una [**prova di frode**](/glossary/#fraud-proof), solo in caso di contestazione. [Maggiori informazioni sui rollup ottimistici](/developers/docs/scaling/optimistic-rollups/).
+- **Rollup a conoscenza zero**: eseguono il calcolo fuori catena e inviano una [**prova di validità**](/glossary/#validity-proof) alla catena. [Maggiori informazioni sui rollup a conoscenza zero](/developers/docs/scaling/zk-rollups/).
#### Canali di stato {#channels}
-I canali di stato utilizzano contratti multifirma per consentire ai partecipanti di effettuare transazioni rapidamente e liberamente al di fuori della catena, regolando la finalità con la Rete principale. In questo modo si riducono al minimo la congestione, le commissioni e i ritardi sulla rete. Al momento esistono due tipi di canali: canali di stato e canali di pagamento.
+I canali di stato utilizzano contratti multifirma per consentire ai partecipanti di effettuare transazioni in modo rapido e libero fuori catena, per poi stabilire la finalità con la rete principale. Ciò riduce al minimo la congestione della rete, le commissioni e i ritardi. I due tipi di canali sono attualmente i canali di stato e i canali di pagamento.
-Maggiori informazioni sui [canali di stato](/developers/docs/scaling/state-channels/).
+Scopri di più sui [canali di stato](/developers/docs/scaling/state-channels/).
-### Sidechain {#sidechains}
+### Catene laterali {#sidechains}
-Una sidechain è una blockchain indipendente compatibile con EVM che viene eseguita in parallelo alla Rete principale. È compatibile con Ethereum tramite ponti bidirezionali e funziona secondo regole di consenso e parametri del blocco propri.
+Una catena laterale è una blockchain indipendente compatibile con l'EVM che funziona in parallelo alla rete principale. Queste sono compatibili con Ethereum tramite ponti bidirezionali e funzionano secondo le proprie regole di consenso e parametri dei blocchi scelti.
-Maggiori informazioni sulle [sidechain](/developers/docs/scaling/sidechains/).
+Scopri di più sulle [catene laterali](/developers/docs/scaling/sidechains/).
### Plasma {#plasma}
-Una catena Plasma è una blockchain separata e collegata alla catena principale di Ethereum che utilizza le prove di frode (come i [rollup ottimistici](/developers/docs/scaling/optimistic-rollups/)) per arbitrare le dispute.
+Una catena plasma è una blockchain separata che è ancorata alla catena principale di Ethereum e utilizza prove di frode (come i [rollup ottimistici](/developers/docs/scaling/optimistic-rollups/)) per arbitrare le controversie.
-Scopri di più sui [rollup](/developers/docs/scaling/plasma/).
+Scopri di più su [Plasma](/developers/docs/scaling/plasma/).
### Validium {#validium}
-Una catena Validum usa le prove di validità come i rollup a conoscenza zero, ma i dati non sono memorizzati sulla catena di livello 1 principale di Ethereum. Questo può tradursi in 10.000 transazioni al secondo per catena Validium, con la possibilità di eseguire più catene in parallelo.
+Una catena Validium utilizza prove di validità come i rollup a conoscenza zero, ma i dati non vengono archiviati sulla catena principale di Ethereum di livello 1. Ciò può portare a 10.000 transazioni al secondo per catena Validium e più catene possono essere eseguite in parallelo.
Scopri di più su [Validium](/developers/docs/scaling/validium/).
## Perché sono necessarie così tante soluzioni di scalabilità? {#why-do-we-need-these}
-- Soluzioni multiple possono contribuire a ridurre la congestione generale su qualsiasi parte della rete, nonché a evitare singoli punti di errore.
-- Il tutto è superiore alla somma delle sue parti. Diverse soluzioni possono coesistere e lavorare in armonia, producendo un effetto esponenziale sulla velocità e la produttività delle transazioni future.
-- Non tutte le soluzioni richiedono l'utilizzo dell'algoritmo di consenso di Ethereum direttamente, e le alternative possono offrire benefici che altrimenti sarebbero difficili da ottenere.
+- Molteplici soluzioni possono aiutare a ridurre la congestione complessiva su qualsiasi parte della rete e anche a prevenire singoli punti di guasto.
+- Il tutto è maggiore della somma delle sue parti. Soluzioni diverse possono esistere e lavorare in armonia, consentendo un effetto esponenziale sulla velocità e sul throughput delle transazioni future.
+- Non tutte le soluzioni richiedono l'utilizzo diretto dell'algoritmo di consenso di Ethereum e le alternative possono offrire vantaggi che altrimenti sarebbero difficili da ottenere.
-## Preferisci un approccio visivo all'apprendimento? {#visual-learner}
+## Impari meglio visivamente? {#visual-learner}
)) che scopre una vulnerabilità in un contratto intelligente e la rivela agli sviluppatori. I bug bounty sono simili agli audit poiché implicano la richiesta ad altri di aiutare a trovare difetti nei contratti intelligenti.
-La differenza principale è che i programmi di bug bounty sono aperti alla più ampia community di sviluppatori/hacker e attrae un'ampia classe di hacker etici e professionisti della sicurezza indipendenti dotati di competenze uniche ed esperienza. Questo potrebbe essere un vantaggio rispetto ai controlli del contratto intelligente che si affidano principalmente ai team che potrebbero possedere esperienza limitata o minima.
+La differenza principale è che i programmi di bug bounty sono aperti alla più ampia comunità di sviluppatori/hacker e attraggono un'ampia classe di hacker etici e professionisti della sicurezza indipendenti con competenze ed esperienze uniche. Questo può essere un vantaggio rispetto agli audit dei contratti intelligenti che si basano principalmente su team che potrebbero possedere competenze limitate o ristrette.
-## Strumenti di test e librerie {#testing-tools-and-libraries}
+## Strumenti e librerie di test {#testing-tools-and-libraries}
-### Strumenti per i test unitari {#unit-testing-tools}
+### Strumenti di test unitari {#unit-testing-tools}
- **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** - _Strumento di copertura del codice per contratti intelligenti scritti in Solidity._
-- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _Quadro per lo sviluppo e test avanzati dei contratti intelligenti (basato su ethers.js)_.
+- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** - _Framework per lo sviluppo e il test avanzati di contratti intelligenti (basato su ethers.js)_.
-- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Strumento per testare contratti intelligenti in Solidity. Opera sotto il plugin "Solidity Unit Testing" di Remix IDE, usato per scrivere ed eseguire casi di prova per un contratto._
+- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Strumento per testare i contratti intelligenti in Solidity. Funziona sotto il plugin "Solidity Unit Testing" di Remix IDE, che viene utilizzato per scrivere ed eseguire casi di test per un contratto._
-- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _Libreria di asserzioni per i test di contratti intelligenti di Ethereum. Assicurati che i tuoi contratti si comportino come previsto!_
+- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** - _Libreria di asserzioni per il test dei contratti intelligenti di Ethereum. Assicurati che i tuoi contratti si comportino come previsto!_
-- **[Quadro di test unitari di Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie utilizza Pytest, un quadro di test ricco di funzionalità che ti consente di scrivere piccoli test con codice minimale, si ridimensiona bene per i grandi progetti ed è altamente estendibile._
+- **[Framework di test unitari Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** - _Brownie utilizza Pytest, un framework di test ricco di funzionalità che ti consente di scrivere piccoli test con codice minimo, scala bene per progetti di grandi dimensioni ed è altamente estensibile._
-- **[Test di Foundry](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry offre Forge, un quadro di test di Ethereum veloci e flessibili, in grado di eseguire semplici test unitari, controlli d'ottimizzazione del carburante e fuzzing del contratto._
+- **[Foundry Tests](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** - _Foundry offre Forge, un framework di test per Ethereum veloce e flessibile in grado di eseguire semplici test unitari, controlli di ottimizzazione del gas e fuzzing dei contratti._
-- **[Test di Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _Quadro per testare i contratti intelligenti basato su ethers.js, Mocha e Chai._
+- **[Hardhat Tests](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** - _Framework per testare i contratti intelligenti basato su ethers.js, Mocha e Chai._
-- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _Quadro di sviluppo e test basato su Python per i contratti intelligenti, rivolto alla Macchina Virtuale Intelligente._
+- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** - _Framework di sviluppo e test basato su Python per contratti intelligenti mirati alla macchina virtuale di Ethereum._
-- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _Assetto basato su Python per i test unitari e il fuzzing, con forti capacità di debug e supporto ai test tra catene, che utilizza pytest e Anvil per un'esperienza dell'utente e prestazioni migliori._
+- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _Framework basato su Python per test unitari e fuzzing con forti capacità di debug e supporto per test cross-chain, che utilizza pytest e Anvil per la migliore esperienza utente e prestazioni._
### Strumenti di test basati sulle proprietà {#property-based-testing-tools}
#### Strumenti di analisi statica {#static-analysis-tools}
-- **[Slither](https://github.com/crytic/slither)** - _Quadro di analisi statica in Solidity basato su Python per trovare vulnerabilità, migliorare la comprensione del codice e scrivere analisi personalizzate per i contratti intelligenti._
+- **[Slither](https://github.com/crytic/slither)** - _Framework di analisi statica per Solidity basato su Python per trovare vulnerabilità, migliorare la comprensione del codice e scrivere analisi personalizzate per i contratti intelligenti._
+
+- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Linter per far rispettare le migliori pratiche di stile e sicurezza per il linguaggio di programmazione dei contratti intelligenti Solidity._
-- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** - _Linter per l'applicazione delle migliori pratiche di stile e sicurezza per il linguaggio di programmazione dei contratti intelligenti Solidity_
+- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** - _Analizzatore statico basato su Rust specificamente progettato per la sicurezza e lo sviluppo di contratti intelligenti Web3._
-- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)**: _Analizzatore statico basato su Rust, progettato specificamente per la sicurezza e lo sviluppo di contratti intelligenti in Web3._
+- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _Framework di analisi statica basato su Python con rilevatori di vulnerabilità e qualità del codice, stampanti per estrarre informazioni utili dal codice e supporto per la scrittura di sottomoduli personalizzati._
-- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _Assetto di analisi statica basato su Python con rilevatori delle vulnerabilità e della qualità del codice, stampanti per estrarre informazioni utili dal codice e supporto alla scrittura di moduli secondari personalizzati._
+- **[Slippy](https://github.com/fvictorio/slippy)** - _Un linter semplice e potente per Solidity._
#### Strumenti di analisi dinamica {#dynamic-analysis-tools}
-- **[Echidna](https://github.com/crytic/echidna/)** - _Veloce fuzzer di contratti per rilevare le vulnerabilità nei contratti intelligenti tramite i test basati sulle proprietà._
+- **[Echidna](https://github.com/crytic/echidna/)** - _Fuzzer di contratti veloce per rilevare vulnerabilità nei contratti intelligenti attraverso test basati sulle proprietà._
-- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _Strumento automatizzato di fuzzing utile per rilevare le violazioni delle proprietà nel codice dei contratti intelligenti._
+- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** - _Strumento di fuzzing automatizzato utile per rilevare violazioni delle proprietà nel codice dei contratti intelligenti._
-- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _Quadro di esecuzione simbolica e dinamica per analizzare il bytecode dell'EVM._
+- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** - _Framework di esecuzione simbolica dinamica per l'analisi del bytecode della EVM._
-- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _Strumento di valutazione del bytecode dell'EVM per rilevare le vulnerabilità del contratto utilizzando l'analisi a macchia, l'analisi concolica e la verifica del flusso di controllo._
+- **[Mythril](https://github.com/ConsenSys/mythril-classic)** - _Strumento di valutazione del bytecode della EVM per rilevare le vulnerabilità dei contratti utilizzando l'analisi delle contaminazioni (taint analysis), l'analisi concolica e il controllo del flusso di controllo._
-- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble è uno strumento di verifica del linguaggio della specifica e dell'esecuzione che consente di annotare i contratti intelligenti con proprietà che consentono di testare automaticamente i contratti con strumenti come Diligence Fuzzing o MythX._
+- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** - _Scribble è un linguaggio di specifica e uno strumento di verifica a runtime che ti consente di annotare i contratti intelligenti con proprietà che ti permettono di testare automaticamente i contratti con strumenti come Diligence Fuzzing o MythX._
## Tutorial correlati {#related-tutorials}
-- [Panoramica e confronto dei diversi prodotti di test](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
-- [Come usare Echidna per testare gli smart contract](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
-- [Come utilizzare Manticore per trovare bug nei contratti intelligenti](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
+- [Una panoramica e un confronto di diversi prodotti di test](/developers/tutorials/guide-to-smart-contract-security-tools/) \_
+- [Come usare Echidna per testare i contratti intelligenti](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/)
+- [Come usare Manticore per trovare bug nei contratti intelligenti](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/)
- [Come usare Slither per trovare bug nei contratti intelligenti](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/)
-- [Come simulare contratti in Solidity per i test](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
-- [Come eseguire i test unitari in Solidity, utilizzando Foundry](https://www.rareskills.io/post/foundry-testing-solidity)
+- [Come simulare (mock) i contratti Solidity per i test](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/)
+- [Come eseguire test unitari in Solidity usando Foundry](https://www.rareskills.io/post/foundry-testing-solidity)
## Letture consigliate {#further-reading}
-- [Una guida approfondita ai test dei contratti intelligenti di Ethereum](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
+- [Una guida approfondita al test dei contratti intelligenti di Ethereum](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297)
- [Come testare i contratti intelligenti di Ethereum](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d)
- [Guida ai test unitari di MolochDAO per sviluppatori](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide)
- [Come testare i contratti intelligenti come una rockstar](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001)
+
+## Tutorial: Test dei contratti intelligenti su Ethereum {#tutorials}
+
+- [Come sviluppare e testare una dApp su una rete di test locale multi-client](/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/) _– Procedura dettagliata per la distribuzione di un contratto intelligente su una rete di test locale e l'esecuzione di test._
+- [Come simulare (mock) i contratti intelligenti Solidity per i test](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) _– Tutorial intermedio su come utilizzare dati fittizi e implementare test unitari._
+- [Come usare Echidna per testare i contratti intelligenti](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) _– Approccio avanzato al fuzzing e al test dei contratti intelligenti._
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/it/developers/docs/smart-contracts/upgrading/index.md
index 1d0658cdd34..de7841b614b 100644
--- a/public/content/translations/it/developers/docs/smart-contracts/upgrading/index.md
+++ b/public/content/translations/it/developers/docs/smart-contracts/upgrading/index.md
@@ -1,165 +1,165 @@
---
title: Aggiornare i contratti intelligenti
-description: Una panoramica degli schemi di aggiornamento per i contratti intelligenti di Ethereum
+description: Una panoramica dei modelli di aggiornamento per i contratti intelligenti di Ethereum
lang: it
---
-I contratti intelligenti su Ethereum sono programmi autoeseguibili eseguiti nella Macchina Virtuale di Ethereum (EVM). Questi programmi sono immutabili per progettazione, il che impedisce qualsiasi aggiornamento alla logica aziendale una volta che il contratto è distribuito.
+I contratti intelligenti su Ethereum sono programmi auto-eseguibili che operano nella macchina virtuale di Ethereum (EVM). Questi programmi sono immutabili per concezione, il che impedisce qualsiasi aggiornamento alla logica di business una volta che il contratto è stato distribuito.
-Sebbene l'immutabilità sia necessaria per la mancanza di fiducia, la decentralizzazione e la sicurezza dei contratti intelligenti, potrebbe talvolta comportare uno svantaggio. Ad esempio, un codice immutabile può rendere impossibile per gli sviluppatori correggere dei contratti vulnerabili.
+Sebbene l'immutabilità sia necessaria per l'assenza di fiducia (trustlessness), la decentralizzazione e la sicurezza dei contratti intelligenti, in certi casi può rappresentare uno svantaggio. Ad esempio, il codice immutabile può rendere impossibile per gli sviluppatori correggere i contratti vulnerabili.
-Tuttavia, maggiori ricerche volte a migliorare i contratti intelligenti hanno portato all'introduzione di svariati schemi di aggiornamento. Questi consentono agli sviluppatori di aggiornare i contratti intelligenti (preservandone l'immutabilità) inserendo della logica aziendale in contratti differenti.
+Tuttavia, la crescente ricerca per migliorare i contratti intelligenti ha portato all'introduzione di diversi modelli di aggiornamento. Questi modelli di aggiornamento consentono agli sviluppatori di aggiornare i contratti intelligenti (pur preservandone l'immutabilità) inserendo la logica di business in contratti diversi.
## Prerequisiti {#prerequisites}
-Dovresti avere una buona comprensione dei [contratti intelligenti](/developers/docs/smart-contracts/), dell'[anatomia dei contratti intelligenti](/developers/docs/smart-contracts/anatomy/) e della [Macchina Virtuale di Ethereum (EVM)](/developers/docs/evm/). Questa guida, inoltre, presume che i lettori comprendano la programmazione dei contratti intelligenti.
+Dovresti avere una buona comprensione dei [contratti intelligenti](/developers/docs/smart-contracts/), dell'[anatomia dei contratti intelligenti](/developers/docs/smart-contracts/anatomy/) e della [macchina virtuale di Ethereum (EVM)](/developers/docs/evm/). Questa guida presuppone inoltre che i lettori abbiano una conoscenza di base della programmazione dei contratti intelligenti.
-## Cos'è l'aggiornamento di un contratto intelligente? {#what-is-a-smart-contract-upgrade}
+## Cos'è un aggiornamento di un contratto intelligente? {#what-is-a-smart-contract-upgrade}
-L'aggiornamento di un contratto intelligente comporta la modifica della sua logica aziendale pur preservandone lo stato. È importante chiarire che l'aggiornabilità e la mutabilità non sono la stessa cosa, specialmente nel contesto dei contratti intelligenti.
+L'aggiornamento di un contratto intelligente comporta la modifica della logica di business di un contratto intelligente preservando lo stato del contratto. È importante chiarire che aggiornabilità e mutabilità non sono la stessa cosa, specialmente nel contesto dei contratti intelligenti.
-Non è comunque possibile modificare un programma distribuito a un indirizzo sulla rete di Ethereum. Ma è possibile modificare il codice eseguito quando gli utenti interagiscono con il contratto intelligente.
+Non è ancora possibile modificare un programma distribuito a un indirizzo sulla rete di Ethereum. Ma è possibile modificare il codice che viene eseguito quando gli utenti interagiscono con un contratto intelligente.
-Ciò può avvenire tramite uno dei seguenti metodi:
+Questo può essere fatto tramite i seguenti metodi:
-1. Creazione di diverse versioni di un contratto intelligente e migrazione dello stato (cioè, dei dati) dal vecchio contratto a una sua nuova istanza.
+1. Creare più versioni di un contratto intelligente e migrare lo stato (cioè i dati) dal vecchio contratto a una nuova istanza del contratto.
-2. Creazione di contratti separati per memorizzare la logica aziendale e lo stato.
+2. Creare contratti separati per memorizzare la logica di business e lo stato.
-3. Utilizzo di modelli proxy per delegare le chiamate alle funzioni da un contratto proxy immutabile a un contratto logico modificabile.
+3. Utilizzare modelli proxy per delegare le chiamate di funzione da un contratto proxy immutabile a un contratto logico modificabile.
-4. Creazione di un contratto principale immutabile che si interfacci con contratti satellite flessibili, e si basi su questi ultimi, per eseguire funzioni specifiche.
+4. Creare un contratto principale immutabile che si interfaccia e si affida a contratti satellite flessibili per eseguire funzioni specifiche.
-5. Utilizzo di modelli a diamante per delegare le chiamate alle funzioni da un contratto proxy a contratti logici.
+5. Utilizzare il modello a diamante (diamond pattern) per delegare le chiamate di funzione da un contratto proxy a contratti logici.
-### Meccanismo di aggiornamento n. 1: migrazione del contratto {#contract-migration}
+### Meccanismo di aggiornamento #1: Migrazione del contratto {#contract-migration}
-La migrazione del contratto si basa sul versionamento: l'idea di creare e gestire stati univoci dello stesso software. La migrazione del contratto comporta la distribuzione di una nuova istanza di un contratto intelligente esistente e il trasferimento di archiviazione e saldi al nuovo contratto.
+La migrazione del contratto si basa sul controllo delle versioni (versioning), ovvero l'idea di creare e gestire stati unici dello stesso software. La migrazione del contratto comporta la distribuzione di una nuova istanza di un contratto intelligente esistente e il trasferimento dell'archiviazione e dei saldi al nuovo contratto.
-Il nuovo contratto distribuito avrà un'archiviazione vuota, consentendoti di recuperare i dati dal precedente e di scriverli nella nuova implementazione. Dopodiché, dovrai aggiornare tutti i contratti che hanno interagito con il vecchio contratto affinché riflettano il nuovo indirizzo.
+Il contratto appena distribuito avrà un'archiviazione vuota, consentendoti di recuperare i dati dal vecchio contratto e scriverli nella nuova implementazione. Successivamente, dovrai aggiornare tutti i contratti che interagivano con il vecchio contratto per riflettere il nuovo indirizzo.
-L'ultimo passaggio nella migrazione del contratto è convincere gli utenti a passare all'utilizzo di quello nuovo. La nuova versione del contratto manterrà i saldi e indirizzi degli utenti, preservandone l'immutabilità. Se è un contratto basato su token, dovrai anche contattare le borse per scartare il vecchio contratto e utilizzare quello nuovo.
+L'ultimo passaggio nella migrazione del contratto è convincere gli utenti a passare all'utilizzo del nuovo contratto. La nuova versione del contratto manterrà i saldi e gli indirizzi degli utenti, il che preserva l'immutabilità. Se si tratta di un contratto basato su token, dovrai anche contattare gli exchange per scartare il vecchio contratto e utilizzare il nuovo.
-La migrazione del contratto è una misura relativamente semplice e sicura per aggiornare i contratti intelligenti senza spezzare le interazioni degli utenti. Tuttavia, la migrazione manuale dell'archiviazione e dei saldi degli utenti al nuovo contratto richiede tempo e può comportare costi elevati in termini di carburante.
+La migrazione del contratto è una misura relativamente semplice e sicura per aggiornare i contratti intelligenti senza interrompere le interazioni degli utenti. Tuttavia, la migrazione manuale dell'archiviazione e dei saldi degli utenti al nuovo contratto richiede molto tempo e può comportare costi del gas elevati.
-[Maggiori informazioni sulla migrazione del contratto.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
+[Maggiori informazioni sulla migrazione dei contratti.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/)
-### Meccanismo di aggiornamento n. 2: separazione dei dati {#data-separation}
+### Meccanismo di aggiornamento #2: Separazione dei dati {#data-separation}
-Un altro metodo per aggiornare i contratti intelligenti è separare la logica aziendale e l'archiviazione dei dati in contratti separati. Ciò significa che gli utenti interagiscono con il contratto logico, mentre i dati sono memorizzati in quello d'archiviazione.
+Un altro metodo per aggiornare i contratti intelligenti è separare la logica di business e l'archiviazione dei dati in contratti separati. Ciò significa che gli utenti interagiscono con il contratto logico, mentre i dati sono memorizzati nel contratto di archiviazione.
-Il contratto logico contiene il codice eseguito quando gli utenti interagiscono con l'applicazione. Inoltre, contiene l'indirizzo del contratto d'archiviazione e vi interagisce per ottenere e impostare dati.
+Il contratto logico contiene il codice eseguito quando gli utenti interagiscono con l'applicazione. Contiene anche l'indirizzo del contratto di archiviazione e interagisce con esso per ottenere e impostare i dati.
-Nel mentre, il contratto d'archiviazione detiene lo stato associato al contratto intelligente, come saldi e indirizzi degli utenti. Nota che il contratto d'archiviazione è posseduto dal contratto logico ed è configurato con l'indirizzo di quest'ultimo alla distribuzione. Ciò impedisce ai contratti non autorizzati di chiamare il contratto d'archiviazione o di aggiornarne i dati.
+Nel frattempo, il contratto di archiviazione mantiene lo stato associato al contratto intelligente, come i saldi e gli indirizzi degli utenti. Nota che il contratto di archiviazione è di proprietà del contratto logico ed è configurato con l'indirizzo di quest'ultimo al momento della distribuzione. Questo impedisce a contratti non autorizzati di chiamare il contratto di archiviazione o di aggiornarne i dati.
-Di default, il contratto d'archiviazione è immutabile, ma puoi sostituire il contratto logico a cui è indirizzato con una nuova implementazione. Questo modificherà il codice eseguito nell'EVM, mantenendo intatti archiviazione e saldi.
+Per impostazione predefinita, il contratto di archiviazione è immutabile, ma puoi sostituire il contratto logico a cui punta con una nuova implementazione. Questo cambierà il codice che viene eseguito nella EVM, mantenendo intatti l'archiviazione e i saldi.
-Utilizzare questo metodo di aggiornamento richiede l'aggiornamento dell'indirizzo del contratto logico nel contratto d'archiviazione. Devi inoltre configurare il nuovo contratto logico con l'indirizzo del contratto d'archiviazione per i suddetti motivi.
+L'utilizzo di questo metodo di aggiornamento richiede l'aggiornamento dell'indirizzo del contratto logico nel contratto di archiviazione. Devi anche configurare il nuovo contratto logico con l'indirizzo del contratto di archiviazione per i motivi spiegati in precedenza.
-Il modello di separazione dei dati è indubbiamente più facile da implementare rispetto alla migrazione del contratto. Tuttavia, dovrai gestire svariati contratti e implementare complessi schemi di autorizzazione per proteggere i contratti intelligenti dagli aggiornamenti malevoli.
+Il modello di separazione dei dati è probabilmente più facile da implementare rispetto alla migrazione del contratto. Tuttavia, dovrai gestire più contratti e implementare schemi di autorizzazione complessi per proteggere i contratti intelligenti da aggiornamenti dannosi.
-### Meccanismo di aggiornamento n. 3: modelli del proxy {#proxy-patterns}
+### Meccanismo di aggiornamento #3: Modelli proxy {#proxy-patterns}
-Anche il modello del proxy utilizza la separazione dei dati per mantenere la logica aziendale e i dati in contratti separati. Tuttavia, in un modello del proxy, il contratto di archiviazione (detto proxy) chiama il contratto logico durante l'esecuzione del codice. Questo è l'inverso del metodo di separazione dei dati, in cui il contratto logico chiama il contratto d'archiviazione.
+Anche il modello proxy utilizza la separazione dei dati per mantenere la logica di business e i dati in contratti separati. Tuttavia, in un modello proxy, il contratto di archiviazione (chiamato proxy) chiama il contratto logico durante l'esecuzione del codice. Questo è l'inverso del metodo di separazione dei dati, in cui il contratto logico chiama il contratto di archiviazione.
-Questo è quanto si verifica in un modello del proxy:
+Ecco cosa succede in un modello proxy:
-1. Gli utenti interagiscono con il contratto proxy, che memorizza i dati ma non detiene la logica aziendale.
+1. Gli utenti interagiscono con il contratto proxy, che memorizza i dati, ma non contiene la logica di business.
-2. Il contratto proxy memorizza gli indirizzi del contratto logico e delega tutte le chiamate alle funzioni al contratto logico (che detiene la logica aziendale) utilizzando la funzione `delegatecall`.
+2. Il contratto proxy memorizza l'indirizzo del contratto logico e delega tutte le chiamate di funzione al contratto logico (che contiene la logica di business) utilizzando la funzione `delegatecall`.
-3. Dopo l'inoltro della chiamata al contratto logico, i dati restituiti dal contratto logico sono recuperati e restituiti all'utente.
+3. Dopo che la chiamata è stata inoltrata al contratto logico, i dati restituiti dal contratto logico vengono recuperati e restituiti all'utente.
-Utilizzare i modelli del proxy richiede una comprensione della funzione **delegatecall**. Fondamentalmente, `delegatecall` è un opcode che permette a un contratto di chiamarne un altro, mentre l'esecuzione effettiva del codice si verifica nel contesto del contratto chiamante. Un'implicazione dell'utilizzo di `delegatecall` nei modelli del proxy è che il contratto proxy legge e scrive alla propria archiviazione, eseguendo la logica archiviata al contratto logico come se stesse chiamando una funzione interna.
+L'utilizzo dei modelli proxy richiede la comprensione della funzione **delegatecall**. Fondamentalmente, `delegatecall` è un codice operativo (opcode) che consente a un contratto di chiamare un altro contratto, mentre l'effettiva esecuzione del codice avviene nel contesto del contratto chiamante. Un'implicazione dell'uso di `delegatecall` nei modelli proxy è che il contratto proxy legge e scrive nella sua archiviazione ed esegue la logica memorizzata nel contratto logico come se stesse chiamando una funzione interna.
Dalla [documentazione di Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries):
-> _Esiste una variante speciale di una chiamata al messaggio, detta **delegatecall**, identica a una chiamata al messaggio tranne nel fatto che il codice all'indirizzo di destinazione è eseguito nel contesto (cioè, all'indirizzo) del contratto chiamante e `msg.sender` e `msg.value` non modificano i propri valori. _ _Ciò significa che un contratto può caricare dinamicamente il codice da un indirizzo differente all'esecuzione. L'archiviazione, l'indirizzo corrente e il saldo fanno ancora riferimento al contratto chiamante, solo il codice è preso dall'indirizzo chiamato._
+> _Esiste una variante speciale di una chiamata di messaggio, denominata **delegatecall**, che è identica a una chiamata di messaggio a parte il fatto che il codice all'indirizzo di destinazione viene eseguito nel contesto (cioè, all'indirizzo) del contratto chiamante e `msg.sender` e `msg.value` non cambiano i loro valori._ _Ciò significa che un contratto può caricare dinamicamente codice da un indirizzo diverso in fase di esecuzione. L'archiviazione, l'indirizzo corrente e il saldo si riferiscono ancora al contratto chiamante, solo il codice viene preso dall'indirizzo chiamato._
-Il contratto proxy sa di invocare `delegatecall` ogni volta che un utente chiama una funzione, poiché ha una funzione di `fallback` integrata. Nella programmazione in Solidity, la [funzione di fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) è eseguita quando una chiamata a una funzione non corrisponde alle funzioni specificate in un contratto.
+Il contratto proxy sa di dover invocare `delegatecall` ogni volta che un utente chiama una funzione perché ha una funzione di `fallback` integrata. Nella programmazione Solidity la [funzione di fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) viene eseguita quando una chiamata di funzione non corrisponde alle funzioni specificate in un contratto.
-Far funzionare il modello del proxy richiede la scrittura di una funzione di fallback personalizzata che specifichi come il contratto proxy dovrebbe gestire le chiamate alla funzione che non supporta. In questo caso, la funzione di fallback del proxy è programmata per avviare una delegatecall e reindirizzare la richiesta dell'utente all'implementazione del contratto logico corrente.
+Far funzionare il modello proxy richiede la scrittura di una funzione di fallback personalizzata che specifichi come il contratto proxy debba gestire le chiamate di funzione che non supporta. In questo caso la funzione di fallback del proxy è programmata per avviare una delegatecall e reindirizzare la richiesta dell'utente all'attuale implementazione del contratto logico.
-Il contratto proxy è immutabile di default, ma possono essere creati dei nuovi contratti logici con logica aziendale aggiornata. Eseguire l'aggiornamento dipende quindi dalla modifica dell'indirizzo del contratto logico a cui si fa riferimento nel contratto proxy.
+Il contratto proxy è immutabile per impostazione predefinita, ma possono essere creati nuovi contratti logici con logica di business aggiornata. Eseguire l'aggiornamento è quindi una questione di modifica dell'indirizzo del contratto logico a cui si fa riferimento nel contratto proxy.
-Indicando il contratto proxy a un nuovo contratto logico, il codice eseguito quando gli utenti chiamano la funzione del contratto proxy cambia. Ciò ci consente di aggiornare la logica di un contratto senza chiedere agli utenti di interagire con un nuovo contratto.
+Puntando il contratto proxy a un nuovo contratto logico, il codice eseguito quando gli utenti chiamano la funzione del contratto proxy cambia. Questo ci consente di aggiornare la logica di un contratto senza chiedere agli utenti di interagire con un nuovo contratto.
-I modelli del proxy sono un metodo popolare per aggiornare i contratti intelligenti poiché eliminano le difficoltà associate alla migrazione del contratto. Tuttavia, i modelli del proxy sono più complicati da utilizzare e possono introdurre falle critiche, come [conflitti del selettore di funzione](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357), se usate impropriamente.
+I modelli proxy sono un metodo popolare per aggiornare i contratti intelligenti perché eliminano le difficoltà associate alla migrazione del contratto. Tuttavia, i modelli proxy sono più complicati da usare e possono introdurre difetti critici, come i [conflitti dei selettori di funzione](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357), se usati in modo improprio.
-[Maggiori informazioni sui modelli del proxy](https://blog.openzeppelin.com/proxy-patterns/).
+[Maggiori informazioni sui modelli proxy](https://blog.openzeppelin.com/proxy-patterns/).
-### Meccanismo di aggiornamento n. 4: modello strategico {#strategy-pattern}
+### Meccanismo di aggiornamento #4: Modello di strategia {#strategy-pattern}
-Questa tecnica è influenzata dal [modello strategico](https://en.wikipedia.org/wiki/Strategy_pattern), che incoraggia la creazione di programmi software che si interfaccino con altri programmi per implementare specifiche funzionalità. Applicare il modello strategico allo sviluppo di Ethereum significherebbe costruire un contratto intelligente che chiami le funzioni da altri contratti.
+Questa tecnica è influenzata dal [modello di strategia](https://en.wikipedia.org/wiki/Strategy_pattern), che incoraggia la creazione di programmi software che si interfacciano con altri programmi per implementare funzionalità specifiche. Applicare il modello di strategia allo sviluppo su Ethereum significherebbe costruire un contratto intelligente che chiama funzioni da altri contratti.
-Il contratto principale in questo caso contiene la logica aziendale principale, ma si interfaccia con altri contratti intelligenti ("contratti satellite") per eseguire certe funzioni. Questo contratto principale, inoltre, memorizza l'indirizzo per ogni contratto satellite e può passare tra diverse implementazioni del contratto satellite.
+Il contratto principale in questo caso contiene la logica di business di base, ma si interfaccia con altri contratti intelligenti ("contratti satellite") per eseguire determinate funzioni. Questo contratto principale memorizza anche l'indirizzo per ogni contratto satellite e può passare da un'implementazione all'altra del contratto satellite.
-Puoi creare un nuovo contratto satellite e configurare il contratto principale con il nuovo indirizzo. Ciò ti consente di cambiare le _strategie_ (cioè, implementare nuova logica) per un contratto intelligente.
+Puoi costruire un nuovo contratto satellite e configurare il contratto principale con il nuovo indirizzo. Questo ti consente di cambiare _strategie_ (cioè, implementare nuova logica) per un contratto intelligente.
-Sebbene sia simile al modello del proxy discusso in precedenza, il modello strategico è differente poiché il contratto principale, con cui gli utenti interagiscono, detiene la logica aziendale. Utilizzare questo modello ti offre l'opportunità di introdurre modifiche limitate a un contratto intelligente senza influenzare l'infrastruttura principale.
+Sebbene simile al modello proxy discusso in precedenza, il modello di strategia è diverso perché il contratto principale, con cui gli utenti interagiscono, contiene la logica di business. L'utilizzo di questo modello ti offre l'opportunità di introdurre modifiche limitate a un contratto intelligente senza influire sull'infrastruttura di base.
-Lo svantaggio principale è che questo modello è per lo più utile per implementare aggiornamenti minori. Inoltre, se il contratto intelligente è compromesso (es. per via di una violazione), non puoi utilizzare questo metodo di aggiornamento.
+Lo svantaggio principale è che questo modello è utile soprattutto per lanciare aggiornamenti minori. Inoltre, se il contratto principale viene compromesso (ad es. tramite un attacco informatico), non puoi utilizzare questo metodo di aggiornamento.
-### Meccanismo di aggiornamento n. 5: modello a diamante {#diamond-pattern}
+### Meccanismo di aggiornamento #5: Modello a diamante {#diamond-pattern}
-Il modello a diamante può essere considerato un miglioramento del modello del proxy. I modelli a diamante differiscono dai modelli del proxy perché il contratto proxy a diamante può delegare le chiamate alle funzioni a più di un contratto logico.
+Il modello a diamante può essere considerato un miglioramento del modello proxy. I modelli a diamante differiscono dai modelli proxy perché il contratto proxy a diamante può delegare le chiamate di funzione a più di un contratto logico.
-I contratti logici nel modello a diamante sono noti come _sfaccettature_. Per far funzionare il modello a diamante, devi creare una mappatura nel contratto proxy che mappi i [selettori della funzione](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) a diversi indirizzi di sfaccettatura.
+I contratti logici nel modello a diamante sono noti come _sfaccettature_ (facets). Per far funzionare il modello a diamante, devi creare una mappatura nel contratto proxy che associ i [selettori di funzione](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) a diversi indirizzi delle sfaccettature.
-Quando un utente effettua una chiamata a una funzione, il contratto proxy controlla la mappatura per trovare la sfaccettatura responsabile dell'esecuzione di tale funzione. Quindi invoca `delegatecall` (utilizzando la funzione di fallback) e reindirizza la chiamata al contratto logico appropriato.
+Quando un utente effettua una chiamata di funzione, il contratto proxy controlla la mappatura per trovare la sfaccettatura responsabile dell'esecuzione di quella funzione. Quindi invoca `delegatecall` (utilizzando la funzione di fallback) e reindirizza la chiamata al contratto logico appropriato.
-Il modello di aggiornamento a diamante presenta dei vantaggi rispetto ai tradizionali modelli di aggiornamento del proxy:
+Il modello di aggiornamento a diamante presenta alcuni vantaggi rispetto ai tradizionali modelli di aggiornamento proxy:
-1. Ti consente di aggiornare una piccola parte del contratto senza modificare tutto il codice. L'utilizzo del modello del proxy per gli aggiornamenti richiede la creazione di un contratto logico completamente nuovo, anche per aggiornamenti minori.
+1. Ti consente di aggiornare una piccola parte del contratto senza modificare tutto il codice. L'utilizzo del modello proxy per gli aggiornamenti richiede la creazione di un contratto logico completamente nuovo, anche per aggiornamenti minori.
-2. Tutti i contratti intelligenti (inclusi i contratti logici utilizzati nei modelli del proxy) hanno un limite di dimensione di 24KB che può risultare limitante, specialmente per i contratti complessi che richiedono più funzioni. Il modello a diamante semplifica la risoluzione di questo problema dividendo le funzioni tra più contratti logici.
+2. Tutti i contratti intelligenti (inclusi i contratti logici utilizzati nei modelli proxy) hanno un limite di dimensione di 24KB, che può essere una limitazione, specialmente per contratti complessi che richiedono più funzioni. Il modello a diamante semplifica la risoluzione di questo problema suddividendo le funzioni su più contratti logici.
-3. I modelli del proxy adottano un approccio omnicomprensivo per i controlli dell'accesso. Un'entità con accesso alle funzioni di aggiornamento può modificare l'_intero_ contratto. Ma il modello a diamante consente un approccio modulare ai permessi, in cui puoi fare in modo che le entità possano aggiornare solo determinate funzioni in un contratto intelligente.
+3. I modelli proxy adottano un approccio generico (catch-all) ai controlli di accesso. Un'entità con accesso alle funzioni di aggiornamento può modificare l'_intero_ contratto. Ma il modello a diamante consente un approccio modulare alle autorizzazioni, in cui puoi limitare le entità all'aggiornamento di determinate funzioni all'interno di un contratto intelligente.
-[Maggiori informazioni sui modelli a diamante](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
+[Maggiori informazioni sul modello a diamante](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w).
## Pro e contro dell'aggiornamento dei contratti intelligenti {#pros-and-cons-of-upgrading-smart-contracts}
-| Pro | Contro |
-| ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| L'aggiornamento di un contratto intelligente può semplificare la correzione delle vulnerabilità scoperte nella fase post-distribuzione. | L'aggiornamento dei contratti intelligenti nega l'idea dell'immutabilità del codice, il che ha implicazioni per la decentralizzazione e la sicurezza. |
-| Gli sviluppatori possono utilizzare gli aggiornamenti logici per aggiungere nuove funzionalità alle applicazioni decentralizzate. | Gli utenti devono fidarsi del fatto che gli sviluppatori non modifichino arbitrariamente i contratti intelligenti. |
-| Gli aggiornamenti dei contratti intelligenti possono migliorare la sicurezza per gli utenti finali grazie a una rapida correzione dei bug. | La programmazione di funzionalità di aggiornamento nei contratti intelligenti aggiunge un ulteriore livello di complessità, incrementando la possibilità di falle critiche. |
-| Gli aggiornamenti dei contratti danno più spazio agli sviluppatori per sperimentare con varie funzionalità e migliorare le dapp nel corso del tempo. | L'opportunità di aggiornare i contratti intelligenti potrebbe incoraggiare gli sviluppatori a lanciare i progetti più velocemente senza la dovuta diligenza durante la fase di sviluppo. |
-| | Un controllo dell'accesso non sicuro o la centralizzazione nei contratti intelligenti possono semplificare l'esecuzione di aggiornamenti non autorizzati da parte di utenti malevoli. |
+| Pro | Contro |
+| --- | --- |
+| Un aggiornamento di un contratto intelligente può semplificare la correzione delle vulnerabilità scoperte nella fase successiva alla distribuzione. | L'aggiornamento dei contratti intelligenti nega l'idea dell'immutabilità del codice, il che ha implicazioni per la decentralizzazione e la sicurezza. |
+| Gli sviluppatori possono utilizzare gli aggiornamenti logici per aggiungere nuove funzionalità alle applicazioni decentralizzate. | Gli utenti devono fidarsi che gli sviluppatori non modifichino arbitrariamente i contratti intelligenti. |
+| Gli aggiornamenti dei contratti intelligenti possono migliorare la sicurezza per gli utenti finali poiché i bug possono essere corretti rapidamente. | Programmare la funzionalità di aggiornamento nei contratti intelligenti aggiunge un ulteriore livello di complessità e aumenta la possibilità di difetti critici. |
+| Gli aggiornamenti dei contratti offrono agli sviluppatori più spazio per sperimentare diverse funzionalità e migliorare le dApp nel tempo. | L'opportunità di aggiornare i contratti intelligenti potrebbe incoraggiare gli sviluppatori a lanciare i progetti più velocemente senza eseguire la dovuta diligenza durante la fase di sviluppo. |
+| | Un controllo degli accessi insicuro o la centralizzazione nei contratti intelligenti possono rendere più facile per gli attori malintenzionati eseguire aggiornamenti non autorizzati. |
-## Considerazioni sull'aggiornamento dei contratti intelligenti {#considerations-for-upgrading-smart-contracts}
+## Considerazioni per l'aggiornamento dei contratti intelligenti {#considerations-for-upgrading-smart-contracts}
-1. Utilizzare meccanismi di controllo/autorizzazione dell'accesso sicuro per prevenire aggiornamenti non autorizzati ai contratti intelligenti, specialmente se si utilizzano modelli proxy, modelli strategici o separazione dei dati. Un esempio è limitare l'accesso alla funzione di aggiornamento, così che soltanto il proprietario del contratto possa chiamarla.
+1. Utilizza meccanismi sicuri di controllo degli accessi/autorizzazione per prevenire aggiornamenti non autorizzati dei contratti intelligenti, specialmente se si utilizzano modelli proxy, modelli di strategia o separazione dei dati. Un esempio è limitare l'accesso alla funzione di aggiornamento, in modo che solo il proprietario del contratto possa chiamarla.
-2. L'aggiornamento dei contratti intelligenti è un'attività complessa e richiede un elevato livello di diligenza per prevenire l'introduzione di vulnerabilità.
+2. L'aggiornamento dei contratti intelligenti è un'attività complessa e richiede un alto livello di diligenza per prevenire l'introduzione di vulnerabilità.
-3. Ridurre le ipotesi di fiducia decentralizzando il processo di implementazione degli aggiornamenti. Le possibili strategie includono l'utilizzo di un [contratto del portafoglio multifirma](/developers/docs/smart-contracts/#multisig) per controllare gli aggiornamenti, o la richiesta ai [membri di una DAO](/dao/) di votare sull'approvazione dell'aggiornamento.
+3. Riduci le ipotesi di fiducia decentralizzando il processo di implementazione degli aggiornamenti. Le possibili strategie includono l'utilizzo di un [contratto di portafoglio multifirma](/developers/docs/smart-contracts/#multisig) per controllare gli aggiornamenti, o richiedere ai [membri di una DAO](/dao/) di votare per approvare l'aggiornamento.
-4. Essere consapevoli dei costi comportati dall'aggiornamento dei contratti. Ad esempio, copiare lo stato (es. i saldi degli utenti) da un contratto vecchio a uno nuovo durante la sua migrazione potrebbe richiedere più di una transazione, il che significa maggiori commissioni sul carburante.
+4. Sii consapevole dei costi coinvolti nell'aggiornamento dei contratti. Ad esempio, copiare lo stato (es. i saldi degli utenti) da un vecchio contratto a un nuovo contratto durante la migrazione del contratto potrebbe richiedere più di una transazione, il che significa maggiori commissioni del gas.
-5. Considerare l'implementazione di **blocchi temporali** per proteggere gli utenti. Un blocco temporale si riferisce a un ritardo imposto alle modifiche a un sistema. I blocchi temporali sono combinabili con un sistema di governance multifirma per controllare gli aggiornamenti: se un'azione proposta raggiunge la soglia di approvazione necessaria, non viene eseguita fino al termine del periodo di ritardo predefinito.
+5. Considera l'implementazione di **timelock** (blocchi temporali) per proteggere gli utenti. Un timelock si riferisce a un ritardo imposto alle modifiche di un sistema. I timelock possono essere combinati con un sistema di governance multifirma per controllare gli aggiornamenti: se un'azione proposta raggiunge la soglia di approvazione richiesta, non viene eseguita fino allo scadere del periodo di ritardo predefinito.
-I blocchi temporali danno del tempo agli utenti per uscire dal sistema se sono in disaccordo con una modifica proposta (es. aggiornamento logico o nuovi schemi di commissioni). Senza i blocchi temporali, gli utenti devono fidarsi del fatto che gli sviluppatori non implementino modifiche arbitrarie in un contratto intelligente senza preavviso. In questo caso lo svantaggio è che i blocchi temporali limitano la possibilità di correggere rapidamente le vulnerabilità.
+I timelock danno agli utenti un po' di tempo per uscire dal sistema se non sono d'accordo con una modifica proposta (es. aggiornamento logico o nuovi schemi di commissioni). Senza i timelock, gli utenti devono fidarsi che gli sviluppatori non implementino modifiche arbitrarie in un contratto intelligente senza preavviso. Lo svantaggio in questo caso è che i timelock limitano la capacità di correggere rapidamente le vulnerabilità.
## Risorse {#resources}
-**OpenZeppelin Upgrades Plugins - _Una suite di strumenti per distribuire e proteggere contratti intelligenti aggiornabili._**
+**Plugin di aggiornamento di OpenZeppelin - _Una suite di strumenti per distribuire e proteggere contratti intelligenti aggiornabili._**
- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades)
- [Documentazione](https://docs.openzeppelin.com/upgrades)
## Tutorial {#tutorials}
-- [Aggiornare i tuoi contratti intelligenti | Tutorial YouTube](https://www.youtube.com/watch?v=bdXJmWajZRY) di Patrick Collins
-- [Tutorial di migrazione dei contratti intelligenti di Ethereum](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) di Austin Griffith
+- [Aggiornare i tuoi contratti intelligenti | Tutorial su YouTube](https://www.youtube.com/watch?v=bdXJmWajZRY) di Patrick Collins
+- [Tutorial sulla migrazione dei contratti intelligenti di Ethereum](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) di Austin Griffith
- [Utilizzare il modello proxy UUPS per aggiornare i contratti intelligenti](https://blog.logrocket.com/author/praneshas/) di Pranesh A.S
-- [Tutorial Web3: scrivere contratti intelligenti aggiornabili (proxy) utilizzando OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) di fangjun.eth
+- [Tutorial Web3: Scrivere un contratto intelligente aggiornabile (proxy) utilizzando OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) di fangjun.eth
## Letture consigliate {#further-reading}
- [Lo stato degli aggiornamenti dei contratti intelligenti](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) di Santiago Palladino
-- [Svariati metodi per aggiornare un contratto intelligente in Solidity](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Blog Crypto Market Pool
-- [Impara: aggiornare i contratti intelligenti](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - Documentazione di OpenZeppelin
-- [Modelli proxy per l'aggiornabilità dei contratti in Solidity: proxy trasparenti vs. UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) di Naveen Sahu
-- [Come funzionano gli aggiornamenti a diamante](https://dev.to/mudgen/how-diamond-upgrades-work-417j) di Nick Mudge
+- [Diversi modi per aggiornare un contratto intelligente in Solidity](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) - Blog di Crypto Market Pool
+- [Impara: Aggiornare i contratti intelligenti](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) - Documentazione di OpenZeppelin
+- [Modelli proxy per l'aggiornabilità dei contratti in Solidity: Proxy trasparenti vs UUPS](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) di Naveen Sahu
+- [Come funzionano gli aggiornamenti a diamante](https://dev.to/mudgen/how-diamond-upgrades-work-417j) di Nick Mudge
\ No newline at end of file
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..44688bd7622 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
@@ -1,107 +1,113 @@
---
-title: Verificare gli smart contract
+title: Verificare i contratti intelligenti
description: Una panoramica della verifica del codice sorgente per i contratti intelligenti di Ethereum
lang: it
---
-I [contratti intelligenti](/developers/docs/smart-contracts/) sono progettati per essere "senza fiducia", a significare che gli utenti non dovrebbero essere obbligati a fidarsi di terze parti (es. sviluppatori e aziende) prima di interagire con un contratto. Come requisito della mancanza di fiducia, gli utenti e gli altri sviluppatori devono poter verificare il codice sorgente di un contratto intelligente. La verifica del codice sorgente assicura agli utenti e agli sviluppatori che il codice del contratto pubblicato è lo stesso eseguito all'indirizzo del contratto sulla blockchain di Ethereum.
+I [contratti intelligenti](/developers/docs/smart-contracts/) sono progettati per essere "trustless" (senza bisogno di fiducia), il che significa che gli utenti non dovrebbero doversi fidare di terze parti (ad es. sviluppatori e aziende) prima di interagire con un contratto. Come requisito per l'assenza di fiducia, gli utenti e gli altri sviluppatori devono essere in grado di verificare il codice sorgente di un contratto intelligente. La verifica del codice sorgente assicura agli utenti e agli sviluppatori che il codice del contratto pubblicato sia lo stesso codice in esecuzione all'indirizzo del contratto sulla blockchain di Ethereum.
-È importante operare una distinzione tra "verifica del codice sorgente" e "[verifica formale](/developers/docs/smart-contracts/formal-verification/)". La verifica del codice sorgente, che sarà spiegata nel dettaglio di seguito, si riferisce alla verifica che un dato codice sorgente di un contratto intelligente in un linguaggio di alto livello (es. Solidity) si compili allo stesso bytecode da eseguire all'indirizzo del contratto. Tuttavia, la verifica formale descrive la verifica della correttezza di un contratto intelligente, ossia che il contratto si comporti come previsto. Sebbene dipenda dal contesto, la verifica del contratto si riferisce solitamente alla verifica del codice sorgente.
+È importante fare una distinzione tra "verifica del codice sorgente" e "[verifica formale](/developers/docs/smart-contracts/formal-verification/)". La verifica del codice sorgente, che verrà spiegata in dettaglio di seguito, si riferisce alla verifica che il codice sorgente fornito di un contratto intelligente in un linguaggio di alto livello (ad es. Solidity) venga compilato nello stesso bytecode da eseguire all'indirizzo del contratto. Tuttavia, la verifica formale descrive la verifica della correttezza di un contratto intelligente, il che significa che il contratto si comporta come previsto. Sebbene dipenda dal contesto, la verifica del contratto di solito si riferisce alla verifica del codice sorgente.
## Cos'è la verifica del codice sorgente? {#what-is-source-code-verification}
-Prima di distribuire un contratto intelligente nella [Macchina Virtuale di Ethereum (EVM)](/developers/docs/evm/), gli sviluppatori [compilano](/developers/docs/smart-contracts/compiling/) il codice sorgente del contratto – le istruzioni [scritte in Solidity](/developers/docs/smart-contracts/languages/) o in un altro linguaggio di programmazione di alto livello – al bytecode. Poiché l'EVM non può interpretare le istruzioni di alto livello, compilare il codice sorgente al bytecode (cioè, al basso livello, le istruzioni macchina) è necessario per eseguire la logica del contratto nell'EVM.
+Prima di distribuire un contratto intelligente nella [macchina virtuale di Ethereum (EVM)](/developers/docs/evm/), gli sviluppatori [compilano](/developers/docs/smart-contracts/compiling/) il codice sorgente del contratto (istruzioni [scritte in Solidity](/developers/docs/smart-contracts/languages/) o in un altro linguaggio di programmazione di alto livello) in bytecode. Poiché l'EVM non può interpretare istruzioni di alto livello, la compilazione del codice sorgente in bytecode (ovvero istruzioni macchina di basso livello) è necessaria per eseguire la logica del contratto nell'EVM.
-La verifica del codice sorgente consiste nel confrontare il codice sorgente di un contratto intelligente e il bytecode compilato utilizzato durante la creazione del contratto per rilevare eventuali differenze. La verifica dei contratti intelligenti è importante perché il codice del contratto pubblicizzato potrebbe avere una forma differente da quello eseguito sulla blockchain.
+La verifica del codice sorgente consiste nel confrontare il codice sorgente di un contratto intelligente e il bytecode compilato utilizzato durante la creazione del contratto per rilevare eventuali differenze. Verificare i contratti intelligenti è importante perché il codice del contratto pubblicizzato potrebbe essere diverso da quello in esecuzione sulla blockchain.
-La verifica del contratto intelligente consente di studiare cosa faccia un contratto tramite il linguaggio di livello superiore in cui è scritto senza dover leggere il codice macchina. Le funzioni, i valori e solitamente i nomi delle variabili e i commenti restano uguali al codice sorgente originale compilato e distribuito. Questo semplifica molto la lettura del codice. La verifica del codice sorgente, inoltre, prevede la documentazione del codice, così che gli utenti finali sappiano per cosa sia progettato un contratto intelligente.
+La verifica del contratto intelligente consente di indagare su cosa fa un contratto attraverso il linguaggio di livello superiore in cui è scritto, senza dover leggere il codice macchina. Funzioni, valori e di solito i nomi delle variabili e i commenti rimangono gli stessi del codice sorgente originale che viene compilato e distribuito. Questo rende la lettura del codice molto più semplice. La verifica del sorgente prevede anche la documentazione del codice, in modo che gli utenti finali sappiano per cosa è progettato un contratto intelligente.
### Cos'è la verifica completa? {#full-verification}
-Esistono delle parti del codice sorgente che non influenzano il bytecode compilato, quali commenti o nomi delle variabili. Ciò significa che due codici sorgente con nomi delle variabili e commenti differenti sarebbero entrambi capaci di verificare lo stesso contratto. Così, un utente malevolo può aggiungere commenti ingannevoli o dare nomi di variabili fuorvianti nel codice sorgente e far verificare il contratto con un codice sorgente differente da quello originale.
+Ci sono alcune parti del codice sorgente che non influenzano il bytecode compilato, come i commenti o i nomi delle variabili. Ciò significa che due codici sorgente con nomi di variabili diversi e commenti diversi sarebbero entrambi in grado di verificare lo stesso contratto. Con questo, un attore malintenzionato può aggiungere commenti ingannevoli o dare nomi di variabili fuorvianti all'interno del codice sorgente e far verificare il contratto con un codice sorgente diverso da quello originale.
-È possibile evitarlo aggiungendo ulteriori dati al bytecode, che servano da _garanzia crittografica_ per l'esattezza del codice sorgente, e da _impronta digitale_ delle informazioni di compilazione. Le informazioni necessarie si trovano nei [metadati del contratto di Solidity](https://docs.soliditylang.org/en/v0.8.15/metadata.html), e l'hash di questo file è aggiunto al bytecode di un contratto. Puoi vederlo in azione nel [playground dei metadati](https://playground.sourcify.dev)
+È possibile evitare ciò aggiungendo dati extra al bytecode che fungano da _garanzia crittografica_ per l'esattezza del codice sorgente e come _impronta digitale_ delle informazioni di compilazione. Le informazioni necessarie si trovano nei [metadati del contratto di Solidity](https://docs.soliditylang.org/en/v0.8.15/metadata.html), e l'hash di questo file viene aggiunto al bytecode di un contratto. Puoi vederlo in azione nel [playground dei metadati](https://playground.sourcify.dev)
-Il file dei metadati contiene le informazioni sulla compilazione del contratto, inclusi i file sorgente e i loro hash. Ciò significa che, se una delle impostazioni di compilazione o persino un byte in uno dei file sorgente cambiano, il file dei metadati cambia. Di conseguenza, anche l'hash del file dei metadati, aggiunto al bytecode, cambia. Ciò significa che se il bytecode di un contratto + l'hash dei metadati aggiunto corrisponde al codice sorgente e alle impostazioni di compilazione indicati, possiamo essere certi che sia esattamente lo stesso codice sorgente utilizzato nella compilazione originale e che nemmeno un singolo byte sia differente.
+Il file dei metadati contiene informazioni sulla compilazione del contratto, inclusi i file sorgente e i loro hash. Ciò significa che se una qualsiasi delle impostazioni di compilazione o anche un solo byte in uno dei file sorgente cambia, il file dei metadati cambia. Di conseguenza, cambia anche l'hash del file dei metadati, che è aggiunto al bytecode. Ciò significa che se il bytecode di un contratto + l'hash dei metadati aggiunto corrispondono al codice sorgente e alle impostazioni di compilazione forniti, possiamo essere sicuri che questo sia esattamente lo stesso codice sorgente utilizzato nella compilazione originale, senza che nemmeno un singolo byte sia diverso.
-Questo tipo di verifica che sfrutta l'hash dei metadati è noto come **"[verifica completa](https://docs.sourcify.dev/docs/full-vs-partial-match/)"** (o "verifica perfetta"). Se gli hash dei metadati non corrispondono o non sono considerati nella verifica, sarebbe una "corrispondenza parziale", attualmente il metodo più comune per verificare i contratti. È possibile [inserire del codice malevolo](https://samczsun.com/hiding-in-plain-sight/) che non sarebbe riflesso nel codice sorgente verificato senza la verifica completa. Gran parte degli sviluppatori non è a conoscenza della verifica completa e non conserva il file dei metadati della propria compilazione, per cui finora la verifica parziale è stata il metodo utilizzato di fatto per la verifica dei contratti.
+Questo tipo di verifica che sfrutta l'hash dei metadati è indicato come **"[verifica completa](https://docs.sourcify.dev/docs/full-vs-partial-match/)"** (anche "verifica perfetta"). Se gli hash dei metadati non corrispondono o non vengono considerati nella verifica, si tratterebbe di una "corrispondenza parziale", che attualmente è il modo più comune per verificare i contratti. È possibile [inserire codice dannoso](https://samczsun.com/hiding-in-plain-sight/) che non si rifletterebbe nel codice sorgente verificato senza una verifica completa. La maggior parte degli sviluppatori non è a conoscenza della verifica completa e non conserva il file dei metadati della propria compilazione, quindi la verifica parziale è stata finora il metodo de facto per verificare i contratti.
## Perché la verifica del codice sorgente è importante? {#importance-of-source-code-verification}
-### Mancanza di fiducia {#trustlessness}
+### Assenza di fiducia (Trustlessness) {#trustlessness}
-La mancanza di fiducia è senza dubbio la più grande premessa per i contratti intelligenti e le [applicazioni decentralizzate (dapp)](/developers/docs/dapps/). I contratti intelligenti sono "immutabili" e inalterabili; un contratto eseguirà la logica aziendale definita nel codice soltanto al momento della distribuzione. Ciò significa che sviluppatori e imprese non possono manomettere il codice di un contratto dopo la distribuzione su Ethereum.
+L'assenza di fiducia è probabilmente la premessa più grande per i contratti intelligenti e le [applicazioni decentralizzate (dApp)](/developers/docs/dapps/). I contratti intelligenti sono "immutabili" e non possono essere alterati; un contratto eseguirà solo la logica di business definita nel codice al momento della distribuzione. Ciò significa che gli sviluppatori e le imprese non possono manomettere il codice di un contratto dopo averlo distribuito su Ethereum.
-Perché un contratto intelligente sia senza fiducia, il suo codice dovrebbe essere disponibile per la verifica indipendente. Mentre il bytecode compilato per ogni contratto intelligente è pubblicamente disponibile sulla blockchain, il linguaggio di basso livello è difficile da comprendere, sia per gli sviluppatori che per gli utenti.
+Affinché un contratto intelligente sia trustless, il codice del contratto dovrebbe essere disponibile per una verifica indipendente. Sebbene il bytecode compilato per ogni contratto intelligente sia pubblicamente disponibile sulla blockchain, il linguaggio di basso livello è difficile da comprendere, sia per gli sviluppatori che per gli utenti.
-I progetti riducono le ipotesi di fiducia pubblicando il codice sorgente dei propri contratti. Ma ciò comporta un altro problema: è difficile verificare che il codice sorgente pubblicato corrisponda al bytecode del contratto. In questo scenario, il valore di mancanza di fiducia è perduto poiché gli utenti devono fidarsi del fatto che gli sviluppatori non modifichino la logica aziendale di un contratto (modificando il bytecode) prima di distribuirlo sulla blockchain.
+I progetti riducono le supposizioni di fiducia pubblicando il codice sorgente dei loro contratti. Ma questo porta a un altro problema: è difficile verificare che il codice sorgente pubblicato corrisponda al bytecode del contratto. In questo scenario, il valore dell'assenza di fiducia va perso perché gli utenti devono fidarsi che gli sviluppatori non cambino la logica di business di un contratto (ad es. modificando il bytecode) prima di distribuirlo sulla blockchain.
-Gli strumenti di verifica del codice sorgente forniscono garanzie che i file del codice sorgente di un contratto intelligente corrispondano al codice assembly. Il risultato è un ecosistema senza fiducia, in cui gli utenti non si fidano ciecamente di terze parti e verificano piuttosto il codice prima di depositare fondi in un contratto.
+Gli strumenti di verifica del codice sorgente forniscono garanzie che i file del codice sorgente di un contratto intelligente corrispondano al codice assembly. Il risultato è un ecosistema trustless, in cui gli utenti non si fidano ciecamente di terze parti e invece verificano il codice prima di depositare fondi in un contratto.
-### Sicurezza degli utenti {#user-safety}
+### Sicurezza dell'utente {#user-safety}
-Con i contratti intelligenti, solitamente è in gioco molto denaro. Questo richiede maggiori garanzie di sicurezza e la verifica della logica di un contratto intelligente prima del suo utilizzo. Il problema è che gli sviluppatori disonesti possono ingannare gli utenti inserendo del codice malevolo in un contratto intelligente. Senza verifiche, i contratti intelligenti malevoli possono contenere delle [backdoor](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), meccanismi di controllo dell'accesso controversi, vulnerabilità sfruttabili e altri aspetti che mettono a repentaglio la sicurezza dell'utente, che passerebbero inosservati.
+Con i contratti intelligenti, di solito ci sono molti soldi in gioco. Ciò richiede maggiori garanzie di sicurezza e la verifica della logica di un contratto intelligente prima di utilizzarlo. Il problema è che sviluppatori senza scrupoli possono ingannare gli utenti inserendo codice dannoso in un contratto intelligente. Senza verifica, i contratti intelligenti dannosi possono avere [backdoor](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), meccanismi di controllo degli accessi controversi, vulnerabilità sfruttabili e altre cose che mettono a repentaglio la sicurezza dell'utente e che passerebbero inosservate.
-Pubblicare i file del codice sorgente di un contratto intelligente rende più semplice per coloro che sono interessati, come i revisori, valutare il contratto per individuare potenziali vettori d'attacco. Con molte parti che verificano indipendentemente un contratto intelligente, gli utenti hanno maggiori garanzie della sua sicurezza.
+La pubblicazione dei file del codice sorgente di un contratto intelligente rende più facile per gli interessati, come i revisori, valutare il contratto per potenziali vettori di attacco. Con più parti che verificano in modo indipendente un contratto intelligente, gli utenti hanno garanzie più forti della sua sicurezza.
## Come verificare il codice sorgente per i contratti intelligenti di Ethereum {#source-code-verification-for-ethereum-smart-contracts}
-La [distribuzione di un contratto intelligente su Ethereum](/developers/docs/smart-contracts/deploying/) richiede l'invio di una transazione con il un payload di dati (bytecode compilato) a un indirizzo specifico. Il payload di dati è generato compilando il codice sorgente, più gli [argomenti del costruttore](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) dell'istanza del contratto aggiunti al payload di dati nella transazione. La compilazione è deterministica, il che significa che produce sempre lo stesso risultato (cioè, il bytecode del contratto) se sono utilizzati gli stessi file sorgente e le stesse impostazioni di compilazione (es. versione del compilatore, ottimizzatore).
+[Distribuire un contratto intelligente su Ethereum](/developers/docs/smart-contracts/deploying/) richiede l'invio di una transazione con un payload di dati (bytecode compilato) a un indirizzo speciale. Il payload di dati viene generato compilando il codice sorgente, più gli [argomenti del costruttore](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) dell'istanza del contratto aggiunti al payload di dati nella transazione. La compilazione è deterministica, il che significa che produce sempre lo stesso output (ovvero il bytecode del contratto) se vengono utilizzati gli stessi file sorgente e le stesse impostazioni di compilazione (ad es. versione del compilatore, ottimizzatore).
La verifica di un contratto intelligente comporta fondamentalmente i seguenti passaggi:
-1. Inserimento dei file sorgente e delle impostazioni di compilazione in un compilatore.
+1. Inserire i file sorgente e le impostazioni di compilazione in un compilatore.
-2. Il compilatore produce il bytecode del contratto
+2. Il compilatore restituisce il bytecode del contratto.
-3. Ottenimento del bytecode del contratto distribuito a un certo indirizzo
+3. Ottenere il bytecode del contratto distribuito a un determinato indirizzo.
-4. Confronto del bytecode distribuito con il bytecode ricompilato. Se i codici corrispondono, il contratto viene verificato con il codice sorgente e le impostazioni di compilazione indicati.
+4. Confrontare il bytecode distribuito con il bytecode ricompilato. Se i codici corrispondono, il contratto viene verificato con il codice sorgente e le impostazioni di compilazione forniti.
-5. Inoltre, se gli hash dei metadati alla fine del bytecode corrispondono, sarà una corrispondenza completa.
+5. Inoltre, se gli hash dei metadati alla fine del bytecode corrispondono, si tratterà di una corrispondenza completa.
-Nota che questa è una descrizione semplicistica della verifica e che esistono molte eccezioni che non funzionerebbero, come avere delle [variabili immutabili](https://docs.sourcify.dev/docs/immutables/).
+Nota che questa è una descrizione semplicistica della verifica e ci sono molte eccezioni che non funzionerebbero con questo, come avere [variabili immutabili](https://docs.sourcify.dev/docs/immutables/).
## Strumenti di verifica del codice sorgente {#source-code-verification-tools}
-Il tradizionale processo di verifica dei contratti può essere complesso. Per questo abbiamo strumenti per la verifica del codice sorgente per i contratti intelligenti distribuiti su Ethereum. Questi automatizzano buona parte della verifica del codice sorgente, oltre a curare i contratti verificati per i benefici degli utenti.
+Il processo tradizionale di verifica dei contratti può essere complesso. Questo è il motivo per cui disponiamo di strumenti per verificare il codice sorgente per i contratti intelligenti distribuiti su Ethereum. Questi strumenti automatizzano gran parte della verifica del codice sorgente e curano anche i contratti verificati a vantaggio degli utenti.
### Etherscan {#etherscan}
-Sebbene per lo più conosciuto come un [esploratore della blockchain di Ethereum](/developers/docs/data-and-analytics/block-explorers/), Etherscan offre anche un [servizio di verifica del codice sorgente](https://etherscan.io/verifyContract) per sviluppatori e utenti dei contratti intelligenti.
+Sebbene sia noto principalmente come un [esploratore di blocchi di Ethereum](/developers/docs/data-and-analytics/block-explorers/), Etherscan offre anche un [servizio di verifica del codice sorgente](https://etherscan.io/verifyContract) per sviluppatori e utenti di contratti intelligenti.
-Etherscan ti consente di ricompilare il bytecode del contratto dal payload di dati originale (codice sorgente, indirizzo della libreria, impostazioni del compilatore, indirizzo del contratto, ecc.) Se il bytecode ricompilato è associato al bytecode (e ai parametri del costruttore) del contratto su catena, allora [il contratto è verificato](https://info.etherscan.com/types-of-contract-verification/).
+Etherscan ti consente di ricompilare il bytecode del contratto dal payload di dati originale (codice sorgente, indirizzo della libreria, impostazioni del compilatore, indirizzo del contratto, ecc.). Se il bytecode ricompilato è associato al bytecode (e ai parametri del costruttore) del contratto on-chain, allora [il contratto è verificato](https://info.etherscan.com/types-of-contract-verification/).
-Una volta verificato, il codice sorgente del tuo contratto riceve un'etichetta "verificato" ed è pubblicato su Etherscan per essere revisionato da altri. Inoltre, viene aggiunto alla sezione [Contratti verificati](https://etherscan.io/contractsVerified/), una repository dei contratti intelligenti con codici sorgente verificati.
+Una volta verificato, il codice sorgente del tuo contratto riceve un'etichetta "Verified" (Verificato) e viene pubblicato su Etherscan affinché altri possano controllarlo. Viene anche aggiunto alla sezione [Verified Contracts](https://etherscan.io/contractsVerified/), un archivio di contratti intelligenti con codici sorgente verificati.
-Etherscan è lo strumento più utilizzato per verificare i contratti. Tuttavia, la verifica dei contratti di Etherscan presenta uno svantaggio: non riesce a confrontare l'**hash dei metadati** del bytecode su catena e del bytecode ricompilato. Dunque, le corrispondenze su Etherscan sono parziali.
+Etherscan è lo strumento più utilizzato per verificare i contratti. Tuttavia, la verifica del contratto di Etherscan ha uno svantaggio: non riesce a confrontare l'**hash dei metadati** del bytecode on-chain e del bytecode ricompilato. Pertanto le corrispondenze in Etherscan sono corrispondenze parziali.
[Maggiori informazioni sulla verifica dei contratti su Etherscan](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327).
+### Blockscout {#blockscout}
+
+[Blockscout](https://blockscout.com/) è un esploratore di blockchain open source che fornisce anche un [servizio di verifica dei contratti](https://eth.blockscout.com/contract-verification) per sviluppatori e utenti di contratti intelligenti. Come alternativa open source, Blockscout offre trasparenza su come viene eseguita la verifica e consente i contributi della community per migliorare il processo di verifica.
+
+Similmente ad altri servizi di verifica, Blockscout ti consente di verificare il codice sorgente del tuo contratto ricompilando il bytecode e confrontandolo con il contratto distribuito. Una volta verificato, il tuo contratto riceve lo stato di verifica e il codice sorgente diventa pubblicamente disponibile per l'auditing e l'interazione. I contratti verificati sono anche elencati nell'[archivio dei contratti verificati](https://eth.blockscout.com/verified-contracts) di Blockscout per facilitarne la navigazione e la scoperta.
+
### Sourcify {#sourcify}
-[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.
+[Sourcify](https://sourcify.dev/#/verifier) è un altro strumento per verificare i contratti che è open source e decentralizzato. Non è un esploratore di blocchi e verifica solo i contratti su [diverse reti basate su EVM](https://docs.sourcify.dev/docs/chains). Agisce come un'infrastruttura pubblica su cui altri strumenti possono basarsi e mira a consentire interazioni con i contratti più a misura d'uomo utilizzando l'[ABI](/developers/docs/smart-contracts/compiling/#web-applications) e i commenti [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) trovati nel file dei metadati.
-A differenza di Etherscan, Sourcify supporta le corrispondenze complete con l'hash dei metadati. I contratti verificati sono serviti nella sua [repository pubblica](https://docs.sourcify.dev/docs/repository/) su HTTP e [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), un'archiviazione [indirizzata ai contenuti](https://web3.storage/docs/concepts/content-addressing/) e decentralizzata. Questo consente il recupero dei file dei metadati di un contratto via IPFS, poiché l'hash dei metadati aggiunto è un hash IPFS.
+A differenza di Etherscan, Sourcify supporta le corrispondenze complete con l'hash dei metadati. I contratti verificati sono serviti nel suo [archivio pubblico](https://docs.sourcify.dev/docs/repository/) su HTTP e [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), che è un'archiviazione decentralizzata e [indirizzata ai contenuti](https://docs.storacha.network/concepts/content-addressing/). Ciò consente di recuperare il file dei metadati di un contratto tramite IPFS poiché l'hash dei metadati aggiunto è un hash IPFS.
-Inoltre, è anche possibile recuperare i file del codice sorgente via IPFS, poiché anche gli hash IPFS di questi file si trovano nei metadati. Un contratto è verificabile fornendo il file dei metadati e i file sorgente tramite la sua API o tramite l'[UI](https://sourcify.dev/#/verifier), o utilizzando i plugin. Lo strumento di monitoraggio di Sourcify ascolta anche le creazioni dei contratti su nuovi blocchi e prova a verificare i contratti se i loro metadati e file sorgente sono pubblicati su IPFS.
+Inoltre, è anche possibile recuperare i file del codice sorgente tramite IPFS, poiché anche gli hash IPFS di questi file si trovano nei metadati. Un contratto può essere verificato fornendo il file dei metadati e i file sorgente tramite la sua API o l'[interfaccia utente](https://sourcify.dev/#/verifier), oppure utilizzando i plugin. Lo strumento di monitoraggio di Sourcify ascolta anche le creazioni di contratti su nuovi blocchi e cerca di verificare i contratti se i loro metadati e file sorgente sono pubblicati su IPFS.
-[Maggiori informazioni sulla verifica dei contratti su Sourcify](https://blog.soliditylang.org/2020/06/25/sourcify-faq/).
+[Maggiori informazioni sulla verifica dei contratti su Sourcify](https://soliditylang.org/blog/2020/06/25/sourcify-faq/).
### Tenderly {#tenderly}
-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.
+La [piattaforma Tenderly](https://tenderly.co/) consente agli sviluppatori Web3 di creare, testare, monitorare e gestire 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 completamente le funzionalità di Tenderly, gli sviluppatori devono [eseguire la verifica del codice sorgente](https://docs.tenderly.co/monitoring/contract-verification) utilizzando diversi metodi.
-È possibile verificare un contratto sia privatamente che pubblicamente. Se verificato privatamente, il contratto intelligente è visibile soltanto a te (e agli altri membri del tuo progetto). Verificarlo pubblicamente lo rende visibile a chiunque utilizzi la piattaforma Tenderly.
+È possibile verificare un contratto privatamente o pubblicamente. Se verificato privatamente, il contratto intelligente è visibile solo a te (e ad altri membri del tuo progetto). Verificare un contratto pubblicamente lo rende visibile a tutti coloro che utilizzano la piattaforma Tenderly.
-Puoi verificare i tuoi contratti utilizzando il [Pannello di controllo](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract), il [plugin Hardhat di Tenderly](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin) o la [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli).
+Puoi verificare i tuoi contratti utilizzando la [Dashboard](https://docs.tenderly.co/contract-verification), il [plugin Tenderly Hardhat](https://docs.tenderly.co/contract-verification/hardhat) o la [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli).
-Verificando i contratti tramite il Pannello di controllo, devi importare il file sorgente o il file dei metadati generati dal compilatore in Solidity, l'indirizzo/rete e le impostazioni del compilatore.
+Quando verifichi i contratti tramite la Dashboard, devi importare il file sorgente o il file dei metadati generato dal compilatore Solidity, l'indirizzo/rete e le impostazioni del compilatore.
-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).
+L'utilizzo del plugin Tenderly Hardhat consente un maggiore controllo sul processo di verifica con meno sforzo, permettendoti di scegliere tra la verifica automatica (senza codice) e manuale (basata sul codice).
## Letture consigliate {#further-reading}
-- [Verificare il codice sorgente del contratto](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
+- [Verificare il codice sorgente del contratto](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/index.md b/public/content/translations/it/developers/docs/standards/index.md
index 0156d8bd1a3..cce80f38217 100644
--- a/public/content/translations/it/developers/docs/standards/index.md
+++ b/public/content/translations/it/developers/docs/standards/index.md
@@ -1,59 +1,59 @@
---
title: Standard di sviluppo di Ethereum
-description:
+description: Scopri gli standard di Ethereum, inclusi gli EIP, gli standard dei token come ERC-20 ed ERC-721 e le convenzioni di sviluppo.
lang: it
incomplete: true
---
-## Panoramica degli standard {#standards-overview}
+## Panoramica sugli standard {#standards-overview}
-La community di Ethereum ha adottato molti standard che aiutano a mantenere interoperabili i progetti (come i [client di Ethereum](/developers/docs/nodes-and-clients/) e i portafogli) tra le implementazioni e ad assicurarsi che i contratti intelligenti e le dapp restino componibili.
+La community di Ethereum ha adottato molti standard che aiutano a mantenere i progetti (come i [client di Ethereum](/developers/docs/nodes-and-clients/) e i portafogli) interoperabili tra le implementazioni e assicurano che i contratti intelligenti e le dApp rimangano componibili.
-Normalmente, gli standard vengono introdotti come [proposte di miglioramento di Ethereum](/eips/) (EIP) che vengono discusse dai membri della community attraverso un [processo standard](https://eips.ethereum.org/EIPS/eip-1).
+In genere, gli standard vengono introdotti come [Proposte di miglioramento di Ethereum](/eips/) (EIP), che vengono discusse dai membri della community attraverso un [processo standard](https://eips.ethereum.org/EIPS/eip-1).
-- [Introduzione alle EIP](/eips/)
-- [Elenco delle EIP](https://eips.ethereum.org/)
-- [Repo di GitHub delle EIP](https://github.com/ethereum/EIPs)
-- [Forum di discussione per le EIP](https://ethereum-magicians.org/c/eips)
-- [Introduzione alla Governance di Ethereum](/governance/)
-- [Ethereum Governance Overview](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _March 31, 2019 - Boris Mann_
-- [Ethereum Protocol Development Governance and Network Upgrade Coordination](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _March 23, 2020 - Hudson Jameson_
-- [Playlist di tutti gli incontri di Core Dev di Ethereum](https://www.youtube.com/@EthereumProtocol) _(Playlist di YouTube)_
+- [Introduzione agli EIP](/eips/)
+- [Elenco degli EIP](https://eips.ethereum.org/)
+- [Repository GitHub degli EIP](https://github.com/ethereum/EIPs)
+- [Forum di discussione degli EIP](https://ethereum-magicians.org/c/eips)
+- [Introduzione alla governance di Ethereum](/governance/)
+- [Panoramica sulla governance di Ethereum](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _31 marzo 2019 - Boris Mann_
+- [Governance dello sviluppo del protocollo di Ethereum e coordinamento degli aggiornamenti di rete](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23 marzo 2020 - Hudson Jameson_
+- [Playlist di tutte le riunioni dei Core Dev di Ethereum](https://www.youtube.com/@EthereumProtocol) _(Playlist di YouTube)_
## Tipi di standard {#types-of-standards}
Esistono 3 tipi di EIP:
-- Traccia Standard: descrive qualsiasi modifica che influenzi gran parte o tutte le implementazioni di Ethereum
-- [Meta-Traccia](https://eips.ethereum.org/meta): descrive un processo circostante Ethereum o propone una modifica a un processo
-- [Traccia Informativa](https://eips.ethereum.org/informational): descrive un problema di design di Ethereum o fornisce linee guida o informazioni generali alla community di Ethereum
+- Standards Track: descrive qualsiasi modifica che influisce sulla maggior parte o su tutte le implementazioni di Ethereum
+- [Meta Track](https://eips.ethereum.org/meta): descrive un processo relativo a Ethereum o propone una modifica a un processo
+- [Informational Track](https://eips.ethereum.org/informational): descrive un problema di progettazione di Ethereum o fornisce linee guida generali o informazioni alla community di Ethereum
-Inoltre, la Traccia Standard è suddivisa in 4 categorie:
+Inoltre, lo Standards Track è suddiviso in 4 categorie:
-- [Principale](https://eips.ethereum.org/core): miglioramenti che richiedono una diramazione del consenso
-- [Rete](https://eips.ethereum.org/networking): miglioramenti relativi a devp2p e al protocollo secondario Ethereum leggero, nonché miglioramenti proposti alle specifiche del protocollo di rete di Whisper e Swarm.
-- [Interfaccia](https://eips.ethereum.org/interface): miglioramenti relativi alle specifiche e agli standard API/RPC del client e certi standard di livello linguistico come i nomi dei metodi e le ABI del contratto.
-- [ERC](https://eips.ethereum.org/erc): standard e convenzioni a livello delle applicazioni
+- [Core](https://eips.ethereum.org/core): miglioramenti che richiedono una biforcazione del consenso
+- [Networking](https://eips.ethereum.org/networking): miglioramenti relativi a devp2p e al Light Ethereum Subprotocol, nonché proposte di miglioramento alle specifiche del protocollo di rete di whisper e swarm.
+- [Interface](https://eips.ethereum.org/interface): miglioramenti relativi alle specifiche e agli standard API/RPC dei client e ad alcuni standard a livello di linguaggio come i nomi dei metodi e le ABI dei contratti.
+- [ERC](https://eips.ethereum.org/erc): standard e convenzioni a livello di applicazione
-Informazioni più dettagliate su questi diversi tipi e categorie sono disponibili in [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types)
+Informazioni più dettagliate su questi diversi tipi e categorie sono disponibili nell'[EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types)
-### Standard per i token {#token-standards}
+### Standard dei token {#token-standards}
-- [ERC-20](/developers/docs/standards/tokens/erc-20/) - Un'interfaccia standard per token fungibili (intercambiabili), come i token di voto, i token di staking o le valute virtuali.
- - [ERC-223](/developers/docs/standards/tokens/erc-223/) - Uno standard di token fungibili che fa comportare i token in modo identico all'ether e supporta la gestione dei trasferimenti di token dal lato dei destinatari.
- - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - Definisce un'interfaccia token per i token ERC-20 che supporta l'esecuzione del codice del destinatario dopo il codice transfer o transferFrom o spender dopo l'approvazione.
-- [ERC-721](/developers/docs/standards/tokens/erc-721/) - Un'interfaccia standard per token non fungibili, come un atto relativo a opere d'arte o canzoni.
- - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - Un evento standardizzato emesso quando si creano/trasferiscono uno o molti token non fungibili utilizzando identificatori di token consecutivi.
- - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - Estensione dell'interfaccia per il ruolo dei consumatori EIP-721.
- - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - Aggiungere un ruolo limitato nel tempo e con permessi limitati ai token ERC-721.
-- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(SCONSIGLIATO)** Uno standard token migliorato rispetto a ERC-20.
-- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - Uno standard per i token che può contenere risorse sia fungibili che non fungibili.
-- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - Uno standard di cassaforte tokenizzata progettato per ottimizzare e unificare i parametri tecnici delle cassaforti di resa.
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - Un'interfaccia standard per i token fungibili (intercambiabili), come i token di voto, i token di staking o le valute virtuali.
+ - [ERC-223](/developers/docs/standards/tokens/erc-223/) - Uno standard per i token fungibili che fa sì che i token si comportino in modo identico agli ether e supporta la gestione dei trasferimenti di token dal lato dei destinatari.
+ - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - Un'interfaccia di estensione per i token ERC-20 che supporta l'esecuzione di callback sui contratti destinatari in una singola transazione.
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - Un'interfaccia standard per i token non fungibili, come un atto di proprietà per un'opera d'arte o una canzone.
+ - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - Un evento standardizzato emesso durante la creazione/trasferimento di uno o più token non fungibili utilizzando identificatori di token consecutivi.
+ - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - Estensione dell'interfaccia per il ruolo di consumatore EIP-721.
+ - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - Aggiunge un ruolo limitato nel tempo con permessi ristretti ai token ERC-721.
+- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(NON CONSIGLIATO)** Uno standard di token che migliora l'ERC-20.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - Uno standard di token che può contenere sia asset fungibili che non fungibili.
+- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - Uno standard per i vault tokenizzati progettato per ottimizzare e unificare i parametri tecnici dei vault fruttiferi.
-Maggiori informazioni sugli [standard peri token](/developers/docs/standards/tokens/).
+Scopri di più sugli [standard dei token](/developers/docs/standards/tokens/).
## Letture consigliate {#further-reading}
- [Proposte di miglioramento di Ethereum (EIP)](/eips/)
-_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/it/developers/docs/standards/tokens/erc-1155/index.md
index 4bc768c00b0..8796158e78a 100644
--- a/public/content/translations/it/developers/docs/standards/tokens/erc-1155/index.md
+++ b/public/content/translations/it/developers/docs/standards/tokens/erc-1155/index.md
@@ -1,35 +1,35 @@
---
title: Standard Multi-Token ERC-1155
-description:
+description: Scopri l'ERC-1155, uno standard multi-token che combina token fungibili e non fungibili in un singolo contratto.
lang: it
---
## Introduzione {#introduction}
-Un'interfaccia standard per i contratti che gestiscono più tipi di token. Un singolo contratto distribuito può includere qualsiasi combinazione di token fungibili, token non fungibili o altre configurazioni (ad esempio token semi-fungibili).
+Un'interfaccia standard per i contratti che gestiscono più tipi di token. Un singolo contratto distribuito può includere qualsiasi combinazione di token fungibili, token non fungibili o altre configurazioni (ad es., token semi-fungibili).
**Cosa si intende per Standard Multi-Token?**
-L'idea è semplice e cerca di creare un'interfaccia per i contratti intelligenti, che possa rappresentare e controllare qualsiasi numero di tipi di token fungibili e non fungibili. In questo modo, il token ERC-1155 può svolgere le stesse funzioni di un token [ERC-20](/developers/docs/standards/tokens/erc-20/) e [ERC-721](/developers/docs/standards/tokens/erc-721/), e anche entrambi contemporaneamente. Migliora la funzionalità degli standard ERC-20 ed ERC-721, rendendola più efficiente e correggendo ovvi errori d'implementazione.
+L'idea è semplice e cerca di creare un'interfaccia per contratti intelligenti in grado di rappresentare e controllare un numero qualsiasi di tipi di token fungibili e non fungibili. In questo modo, il token ERC-1155 può svolgere le stesse funzioni di un token [ERC-20](/developers/docs/standards/tokens/erc-20/) e [ERC-721](/developers/docs/standards/tokens/erc-721/), e persino di entrambi contemporaneamente. Migliora la funzionalità di entrambi gli standard ERC-20 ed ERC-721, rendendolo più efficiente e correggendo evidenti errori di implementazione.
-Il token ERC-1155 è descritto nella sua interezza in [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155).
+Il token ERC-1155 è descritto completamente nell'[EIP-1155](https://eips.ethereum.org/EIPS/eip-1155).
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, consigliamo innanzi tutto di leggere [token standards](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/), and [ERC-721](/developers/docs/standards/tokens/erc-721/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima gli [standard dei token](/developers/docs/standards/tokens/), l'[ERC-20](/developers/docs/standards/tokens/erc-20/) e l'[ERC-721](/developers/docs/standards/tokens/erc-721/).
-## ERC-1155 Funzioni e caratteristiche: {#body}
+## Funzioni e caratteristiche dell'ERC-1155: {#body}
-- [Batch Transfer](#batch_transfers): trasferire più risorse con una singola chiamata.
-- [Batch Balance](#batch_transfers): richiedere i saldi di più risorse con una singola chiamata.
-- [Batch Approval](#batch_approval): approvare tutti i token ad un indirizzo.
-- [Hook](#receive_hook): ricevere l'hook dei token.
-- [Supporto NFT](#nft_support): Se la quantità è solo 1, trattatala come NFT.
-- [Regole di trasferimento sicure](#safe_transfer_rule): insieme di regole per il trasferimento sicuro.
+- [Trasferimento in blocco](#batch_transfers): Trasferisce più asset in una singola chiamata.
+- [Saldo in blocco](#batch_balance): Ottiene i saldi di più asset in una singola chiamata.
+- [Approvazione in blocco](#batch_approval): Approva tutti i token per un indirizzo.
+- [Hook](#receive_hook): Hook per la ricezione dei token.
+- [Supporto NFT](#nft_support): Se la fornitura è solo 1, lo tratta come NFT.
+- [Regole di trasferimento sicuro](#safe_transfer_rule): Insieme di regole per un trasferimento sicuro.
-### Trasferimenti in batch {#batch-transfers}
+### Trasferimenti in blocco {#batch-transfers}
-Il trasferimento in batch funziona in modo molto simile ai normali trasferimenti ERC-20. Diamo un'occhiata alla normale funzione `transferFrom` dell'ERC-20:
+Il trasferimento in blocco funziona in modo molto simile ai normali trasferimenti ERC-20. Diamo un'occhiata alla normale funzione `transferFrom` dell'ERC-20:
```solidity
// ERC-20
@@ -45,17 +45,17 @@ function safeBatchTransferFrom(
) external;
```
-La sola differenza in ERC-1155 è che passiamo i valori come un array e inoltre passiamo un array di ID. Per esempio, dati `ids=[3, 6, 13]` e `values=[100, 200, 5]`, i trasferimenti risultanti saranno
+L'unica differenza nell'ERC-1155 è che passiamo i valori come un array e passiamo anche un array di ID. Ad esempio, dati `ids=[3, 6, 13]` e `values=[100, 200, 5]`, i trasferimenti risultanti saranno:
-1. Trasferisci 100 token con id 3 da `_from` a `_to`.
-2. Trasferisci 200 token con id 6 da `_from` a `_to`.
-3. Trasferisci 5 token con id 13 da `_from` a `_to`.
+1. Trasferimento di 100 token con ID 3 da `_from` a `_to`.
+2. Trasferimento di 200 token con ID 6 da `_from` a `_to`.
+3. Trasferimento di 5 token con ID 13 da `_from` a `_to`.
-In ERC-1155 abbiamo solo `transferFrom`, non `transfer`. Per usarlo come un normale `transfer`, basta impostare l'indirizzo di provenienza all'indirizzo che sta chiamando la funzione.
+Nell'ERC-1155 abbiamo solo `transferFrom`, non `transfer`. Per usarlo come un normale `transfer`, basta impostare l'indirizzo di provenienza (from) all'indirizzo che sta chiamando la funzione.
-### Saldo Batch {#batch-balance}
+### Saldo in blocco {#batch-balance}
-La rispettiva chiamata dell'ERC-20 `balanceOf`, ha la propria funzione partner con supporto al batch. Come promemoria, questa è la versione dell'ERC-20:
+La rispettiva chiamata `balanceOf` dell'ERC-20 ha analogamente la sua funzione partner con supporto per i blocchi. Come promemoria, questa è la versione ERC-20:
```solidity
// ERC-20
@@ -68,9 +68,9 @@ function balanceOfBatch(
) external view returns (uint256[] memory);
```
-Ancora più semplice per la chiamata del saldo, possiamo recuperare più saldi in una sola chiamata. Passiamo l'array di proprietari, seguito dall'array di id del token.
+Ancora più semplice per la chiamata del saldo, possiamo recuperare più saldi in una singola chiamata. Passiamo l'array dei proprietari, seguito dall'array degli ID dei token.
-Per esempio, dati `_ids=[3, 6, 13]` e `_owners=[0xbeef..., 0x1337..., 0x1111...]`, il valore restituito sarà
+Ad esempio, dati `_ids=[3, 6, 13]` e `_owners=[0xbeef..., 0x1337..., 0x1111...]`, il valore restituito sarà:
```solidity
[
@@ -80,7 +80,7 @@ Per esempio, dati `_ids=[3, 6, 13]` e `_owners=[0xbeef..., 0x1337..., 0x1111...]
]
```
-### Approvazione del batch {#batch-approval}
+### Approvazione in blocco {#batch-approval}
```solidity
// ERC-1155
@@ -95,13 +95,13 @@ function isApprovedForAll(
) external view returns (bool);
```
-Le approvazioni sono leggermente diverse da quelle dell'ERC-20. Invece di approvare quantità specifiche, si imposta un operatore come approvato o non approvato tramite `setApprovalForAll`.
+Le approvazioni sono leggermente diverse rispetto all'ERC-20. Invece di approvare importi specifici, si imposta un operatore come approvato o non approvato tramite `setApprovalForAll`.
-È possibile leggere lo stato corrente tramite `isApprovedForAll`. Come puoi vedere, si tratta di un'operazione "o tutto o niente". Non è possibile definire quanti token o quale classe di token approvare.
+La lettura dello stato attuale può essere effettuata tramite `isApprovedForAll`. Come puoi vedere, è un'operazione del tipo tutto o niente. Non puoi definire quanti token approvare o persino quale classe di token.
-Questo è intenzionalmente progettato pensando alla semplicità. È possibile solo approvare tutto per un indirizzo.
+Questo è stato progettato intenzionalmente tenendo a mente la semplicità. Puoi solo approvare tutto per un indirizzo.
-### Ricevere Hook {#receive-hook}
+### Hook di ricezione {#receive-hook}
```solidity
function onERC1155BatchReceived(
@@ -113,34 +113,34 @@ function onERC1155BatchReceived(
) external returns(bytes4);
```
-Dato il supporto all'[EIP-165](https://eips.ethereum.org/EIPS/eip-165), i supporti di ERC-1155 ricevono hook solo per i contratti intelligenti. La funzione di hook deve restituire un valore bytes4 magico predefinito dato come:
+Dato il supporto dell'[EIP-165](https://eips.ethereum.org/EIPS/eip-165), l'ERC-1155 supporta gli hook di ricezione solo per i contratti intelligenti. La funzione hook deve restituire un valore magico predefinito bytes4 che è dato come:
```solidity
bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)"))
```
-Quando il contratto ricevente restituisce questo valore, si presume che il contratto accetti il trasferimento e sappia come gestire i token ERC-1155. Fantastico, niente più token bloccati in un contratto!
+Quando il contratto ricevente restituisce questo valore, si presume che il contratto accetti il trasferimento e sappia come gestire i token ERC-1155. Ottimo, niente più token bloccati in un contratto!
### Supporto NFT {#nft-support}
-Quando la quantità è solo una, il token è essenzialmente un token non fungibile (NFT). E, come nel caso dello standard per l'ERC-721, è possibile definire un URL di metadati. L'URL può essere letto e modificato dai client, vedi [qui](https://eips.ethereum.org/EIPS/eip-1155#metadata).
+Quando la fornitura è solo una, il token è essenzialmente un token non fungibile (NFT). E come è standard per l'ERC-721, puoi definire un URL di metadati. L'URL può essere letto e modificato dai client, vedi [qui](https://eips.ethereum.org/EIPS/eip-1155#metadata).
### Regola di trasferimento sicuro {#safe-transfer-rule}
-Abbiamo già accennato ad alcune regole di trasferimento sicure già nelle spiegazioni precedenti. Ma diamo un'occhiata alla regola più importante:
+Abbiamo già accennato ad alcune regole di trasferimento sicuro nelle spiegazioni precedenti. Ma diamo un'occhiata alla più importante delle regole:
-1. il chiamante dev'esser approvato per spendere i token per l'indirizzo `_from` o il chiamante dev'esser pari a `_from`.
-2. la chiamata di trasferimento deve ripristinarsi se
- 1. l'indirizzo `_to` è 0.
- 2. la lunghezza di `_ids` non è pari alla lunghezza di `_values`.
- 3. uno qualsiasi dei saldi dei titolari per i token in `_ids` è inferiore ai rispettivi importi in `_values` inviati al destinatario.
- 4. si verifica qualsiasi altro errore.
+1. Il chiamante deve essere approvato per spendere i token per l'indirizzo `_from` o il chiamante deve essere uguale a `_from`.
+2. La chiamata di trasferimento deve essere annullata (revert) se:
+ 1. L'indirizzo `_to` è 0.
+ 2. La lunghezza di `_ids` non è uguale alla lunghezza di `_values`.
+ 3. Qualsiasi saldo dei titolari per i token in `_ids` è inferiore ai rispettivi importi in `_values` inviati al destinatario.
+ 4. Si verifica qualsiasi altro errore.
-_Nota_: tutte le funzioni batch compreso l'hook esistono anche come versioni senza batch. Ciò avviene per l'efficienza del gas, considerando che trasferire una singola risorsa sarebbe comunque il metodo più usato. Li abbiamo esclusi per semplicità nelle spiegazioni, lo stesso vale per le regole di trasferimento sicure. I nomi sono identici, basta rimuovere 'Batch'.
+_Nota_: Tutte le funzioni in blocco (batch), incluso l'hook, esistono anche in versioni senza blocco. Questo viene fatto per l'efficienza del gas, considerando che il trasferimento di un solo asset sarà probabilmente ancora il modo più comunemente usato. Le abbiamo omesse per semplicità nelle spiegazioni, incluse le regole di trasferimento sicuro. I nomi sono identici, basta rimuovere 'Batch'.
## Letture consigliate {#further-reading}
-- [EIP-1155 Standard Multi-Token](https://eips.ethereum.org/EIPS/eip-1155)
-- [ERC-1155: Openzeppelin Docs](https://docs.openzeppelin.com/contracts/3.x/erc1155)
-- [ERC-1155: Repository di GitHub](https://github.com/enjin/erc-1155)
-- [API di Alchemy NFT](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
+- [EIP-1155: Standard Multi Token](https://eips.ethereum.org/EIPS/eip-1155)
+- [ERC-1155: Documentazione di OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/erc1155)
+- [ERC-1155: Repository GitHub](https://github.com/enjin/erc-1155)
+- [API NFT di Alchemy](https://www.alchemy.com/docs/reference/nft-api-quickstart)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/it/developers/docs/standards/tokens/erc-1363/index.md
new file mode 100644
index 00000000000..7b62851ec60
--- /dev/null
+++ b/public/content/translations/it/developers/docs/standards/tokens/erc-1363/index.md
@@ -0,0 +1,297 @@
+---
+title: Standard dei Token Pagabili ERC-1363
+description: "L'ERC-1363 è un'interfaccia di estensione per i token ERC-20 che supporta l'esecuzione di logica personalizzata su un contratto ricevente dopo i trasferimenti, o su un contratto di spesa dopo le approvazioni, tutto all'interno di una singola transazione."
+lang: it
+---
+
+## Introduzione {#introduction}
+
+### Cos'è l'ERC-1363? {#what-is-erc1363}
+
+L'ERC-1363 è un'interfaccia di estensione per i token ERC-20 che supporta l'esecuzione di logica personalizzata su un contratto ricevente dopo i trasferimenti, o su un contratto di spesa dopo le approvazioni, tutto all'interno di una singola transazione.
+
+### Differenze rispetto all'ERC-20 {#erc20-differences}
+
+Le operazioni standard dell'ERC-20 come `transfer`, `transferFrom` e `approve`, non consentono l'esecuzione di codice sul contratto ricevente o di spesa senza una transazione separata.
+Ciò introduce complessità nello sviluppo dell'interfaccia utente (UI) e attrito nell'adozione, poiché gli utenti devono attendere l'esecuzione della prima transazione per poi inviare la seconda.
+Devono inoltre pagare il gas due volte.
+
+L'ERC-1363 rende i token fungibili capaci di eseguire azioni più facilmente e di funzionare senza l'uso di alcun listener fuori catena.
+Consente di effettuare una callback su un contratto ricevente o di spesa, dopo un trasferimento o un'approvazione, in una singola transazione.
+
+## Prerequisiti {#prerequisites}
+
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima:
+
+- [Standard dei token](/developers/docs/standards/tokens/)
+- [ERC-20](/developers/docs/standards/tokens/erc-20/)
+
+## Corpo {#body}
+
+L'ERC-1363 introduce un'API standard per i token ERC-20 per interagire con i contratti intelligenti dopo `transfer`, `transferFrom` o `approve`.
+
+Questo standard fornisce funzionalità di base per trasferire token, oltre a consentire l'approvazione dei token in modo che possano essere spesi da un'altra terza parte on-chain, per poi effettuare una callback sul contratto ricevente o di spesa.
+
+Ci sono molti usi proposti per i contratti intelligenti che possono accettare callback ERC-20.
+
+Alcuni esempi potrebbero essere:
+
+- **Crowdsale**: i token inviati innescano l'allocazione istantanea delle ricompense.
+- **Servizi**: il pagamento attiva l'accesso al servizio in un solo passaggio.
+- **Fatture**: i token saldano le fatture automaticamente.
+- **Abbonamenti**: l'approvazione della tariffa annuale attiva l'abbonamento con il pagamento del primo mese.
+
+Per questi motivi è stato originariamente chiamato **"Token Pagabile"**.
+
+Il comportamento della callback espande ulteriormente la sua utilità, consentendo interazioni fluide come:
+
+- **Staking**: i token trasferiti innescano il blocco automatico in un contratto di staking.
+- **Votazione**: i token ricevuti registrano i voti in un sistema di governance.
+- **Scambio**: le approvazioni dei token attivano la logica di scambio in un singolo passaggio.
+
+I token ERC-1363 possono essere utilizzati per utilità specifiche in tutti i casi che richiedono l'esecuzione di una callback dopo un trasferimento o un'approvazione ricevuta.
+L'ERC-1363 è utile anche per evitare la perdita o il blocco dei token nei contratti intelligenti verificando la capacità del destinatario di gestire i token.
+
+A differenza di altre proposte di estensione dell'ERC-20, l'ERC-1363 non sovrascrive i metodi `transfer` e `transferFrom` dell'ERC-20 e definisce gli ID delle interfacce da implementare mantenendo la retrocompatibilità con l'ERC-20.
+
+Dall'[EIP-1363](https://eips.ethereum.org/EIPS/eip-1363):
+
+### Metodi {#methods}
+
+I contratti intelligenti che implementano lo standard ERC-1363 **DEVONO** implementare tutte le funzioni nell'interfaccia `ERC1363`, così come le interfacce `ERC20` e `ERC165`.
+
+```solidity
+pragma solidity ^0.8.0;
+
+/* *
+ * @title ERC1363
+ * @dev Un'interfaccia di estensione per i token ERC-20 che supporta l'esecuzione di codice su un contratto destinatario
+ * dopo `transfer` o `transferFrom`, o di codice su un contratto spenditore dopo `approve`, in una singola transazione. */
+
+
+
+
+
+interface ERC1363 is ERC20, ERC165 {
+ /* * NOTE: l'identificatore ERC-165 per questa interfaccia è 0xb0202a11.
+ * 0xb0202a11 ===
+ * bytes4(keccak256('transferAndCall(address,uint256)')) ^
+ * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^
+ * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^
+ * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^
+ * bytes4(keccak256('approveAndCall(address,uint256)')) ^
+ * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) */
+
+
+
+
+
+
+
+
+
+
+
+ /* *
+ * @dev Sposta una quantità `value` di token dall'account del chiamante a `to`
+ * e poi chiama `ERC1363Receiver::onTransferReceived` su `to`.
+ * @param to L'indirizzo a cui vengono trasferiti i token.
+ * @param value La quantità di token da trasferire.
+ * @return Un valore booleano che indica che l'operazione ha avuto successo a meno che non venga lanciata un'eccezione. */
+
+
+
+
+
+
+
+ function transferAndCall(address to, uint256 value) external returns (bool);
+
+ /* *
+ * @dev Sposta una quantità `value` di token dall'account del chiamante a `to`
+ * e poi chiama `ERC1363Receiver::onTransferReceived` su `to`.
+ * @param to L'indirizzo a cui vengono trasferiti i token.
+ * @param value La quantità di token da trasferire.
+ * @param data Dati aggiuntivi senza formato specificato, inviati nella chiamata a `to`.
+ * @return Un valore booleano che indica che l'operazione ha avuto successo a meno che non venga lanciata un'eccezione. */
+
+
+
+
+
+
+
+
+ function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool);
+
+ /* *
+ * @dev Sposta una quantità `value` di token da `from` a `to` utilizzando il meccanismo di allowance
+ * e poi chiama `ERC1363Receiver::onTransferReceived` su `to`.
+ * @param from L'indirizzo da cui inviare i token.
+ * @param to L'indirizzo a cui vengono trasferiti i token.
+ * @param value La quantità di token da trasferire.
+ * @return Un valore booleano che indica che l'operazione ha avuto successo a meno che non venga lanciata un'eccezione. */
+
+
+
+
+
+
+
+
+ function transferFromAndCall(address from, address to, uint256 value) external returns (bool);
+
+ /* *
+ * @dev Sposta una quantità `value` di token da `from` a `to` utilizzando il meccanismo di allowance
+ * e poi chiama `ERC1363Receiver::onTransferReceived` su `to`.
+ * @param from L'indirizzo da cui inviare i token.
+ * @param to L'indirizzo a cui vengono trasferiti i token.
+ * @param value La quantità di token da trasferire.
+ * @param data Dati aggiuntivi senza formato specificato, inviati nella chiamata a `to`.
+ * @return Un valore booleano che indica che l'operazione ha avuto successo a meno che non venga lanciata un'eccezione. */
+
+
+
+
+
+
+
+
+
+ function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool);
+
+ /* *
+ * @dev Imposta una quantità `value` di token come allowance di `spender` sui token del chiamante
+ * e poi chiama `ERC1363Spender::onApprovalReceived` su `spender`.
+ * @param spender L'indirizzo che spenderà i fondi.
+ * @param value La quantità di token da spendere.
+ * @return Un valore booleano che indica che l'operazione ha avuto successo a meno che non venga lanciata un'eccezione. */
+
+
+
+
+
+
+
+ function approveAndCall(address spender, uint256 value) external returns (bool);
+
+ /* *
+ * @dev Imposta una quantità `value` di token come allowance di `spender` sui token del chiamante
+ * e poi chiama `ERC1363Spender::onApprovalReceived` su `spender`.
+ * @param spender L'indirizzo che spenderà i fondi.
+ * @param value La quantità di token da spendere.
+ * @param data Dati aggiuntivi senza formato specificato, inviati nella chiamata a `spender`.
+ * @return Un valore booleano che indica che l'operazione ha avuto successo a meno che non venga lanciata un'eccezione. */
+
+
+
+
+
+
+
+
+ function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool);
+}
+
+interface ERC20 {
+ event Transfer(address indexed from, address indexed to, uint256 value);
+ event Approval(address indexed owner, address indexed spender, uint256 value);
+ function transfer(address to, uint256 value) external returns (bool);
+ function transferFrom(address from, address to, uint256 value) external returns (bool);
+ function approve(address spender, uint256 value) external returns (bool);
+ function totalSupply() external view returns (uint256);
+ function balanceOf(address account) external view returns (uint256);
+ function allowance(address owner, address spender) external view returns (uint256);
+}
+
+interface ERC165 {
+ function supportsInterface(bytes4 interfaceId) external view returns (bool);
+}
+```
+
+Un contratto intelligente che desidera accettare token ERC-1363 tramite `transferAndCall` o `transferFromAndCall` **DEVE** implementare l'interfaccia `ERC1363Receiver`:
+
+```solidity
+/* *
+ * @title ERC1363Receiver
+ * @dev Interfaccia per qualsiasi contratto che desidera supportare `transferAndCall` o `transferFromAndCall` dai contratti token ERC-1363. */
+
+
+
+
+interface ERC1363Receiver {
+ /* *
+ * @dev Ogni volta che i token ERC-1363 vengono trasferiti a questo contratto tramite `ERC1363::transferAndCall` o `ERC1363::transferFromAndCall`
+ * da `operator` da `from`, viene chiamata questa funzione.
+ *
+ * NOTE: Per accettare il trasferimento, questa deve restituire
+ * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))`
+ * (cioè 0x88a7ca5c, o il proprio selettore di funzione).
+ *
+ * @param operator L'indirizzo che ha chiamato la funzione `transferAndCall` o `transferFromAndCall`.
+ * @param from L'indirizzo da cui vengono trasferiti i token.
+ * @param value La quantità di token trasferiti.
+ * @param data Dati aggiuntivi senza formato specificato.
+ * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` se il trasferimento è consentito a meno che non venga lanciata un'eccezione. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4);
+}
+```
+
+Un contratto intelligente che desidera accettare token ERC-1363 tramite `approveAndCall` **DEVE** implementare l'interfaccia `ERC1363Spender`:
+
+```solidity
+/* *
+ * @title ERC1363Spender
+ * @dev Interfaccia per qualsiasi contratto che desidera supportare `approveAndCall` dai contratti token ERC-1363. */
+
+
+
+
+interface ERC1363Spender {
+ /* *
+ * @dev Ogni volta che un `owner` di token ERC-1363 approva questo contratto tramite `ERC1363::approveAndCall`
+ * per spendere i propri token, viene chiamata questa funzione.
+ *
+ * NOTE: Per accettare l'approvazione, questa deve restituire
+ * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))`
+ * (cioè 0x7b04a2d0, o il proprio selettore di funzione).
+ *
+ * @param owner L'indirizzo che ha chiamato la funzione `approveAndCall` e che in precedenza possedeva i token.
+ * @param value La quantità di token da spendere.
+ * @param data Dati aggiuntivi senza formato specificato.
+ * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` se l'approvazione è consentita a meno che non venga lanciata un'eccezione. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+ function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4);
+}
+```
+
+## Letture di approfondimento {#further-reading}
+
+- [ERC-1363: Standard dei Token Pagabili](https://eips.ethereum.org/EIPS/eip-1363)
+- [ERC-1363: Repository GitHub](https://github.com/vittominacori/erc1363-payable-token)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/it/developers/docs/standards/tokens/erc-20/index.md
index 6d648b8e8df..139b9847d42 100644
--- a/public/content/translations/it/developers/docs/standards/tokens/erc-20/index.md
+++ b/public/content/translations/it/developers/docs/standards/tokens/erc-20/index.md
@@ -1,46 +1,46 @@
---
-title: Standard token ERC-20
-description:
+title: Standard dei Token ERC-20
+description: Scopri l'ERC-20, lo standard per i token fungibili su Ethereum che consente applicazioni di token interoperabili.
lang: it
---
## Introduzione {#introduction}
-**Cos'è un token?**
+**Cos'è un Token?**
-I token possono rappresentare praticamente tutto in Ethereum:
+I token possono rappresentare virtualmente qualsiasi cosa in [Ethereum](/):
-- punti di reputazione in piattaforme online
-- abilità di un personaggio di un videogioco
-- strumenti finanziari come una partecipazione in una società
-- una valuta legale come il dollaro statunitense
+- punti reputazione in una piattaforma online
+- abilità di un personaggio in un gioco
+- attività finanziarie come un'azione in una società
+- una valuta fiat come l'USD
- un'oncia d'oro
- e molto altro...
-Una caratteristica così potente di Ethereum deve essere gestita da uno standard robusto. Questo è esattamente il ruolo di ERC-20! Questo standard permette agli sviluppatori di creare applicazioni token interoperabili con altri prodotti e servizi. Lo standard ERC-20 è anche utilizzato per fornire funzionalità aggiuntive a [ether](/glossary/#ether).
+Una funzionalità così potente di Ethereum deve essere gestita da uno standard robusto, giusto? È esattamente qui che l'ERC-20 entra in gioco! Questo standard consente agli sviluppatori di creare applicazioni di token interoperabili con altri prodotti e servizi. Lo standard ERC-20 è utilizzato anche per fornire funzionalità aggiuntive all'[ether](/glossary/#ether).
-**Cos'è ERC-20?**
+**Cos'è l'ERC-20?**
-ERC-20 introduce uno standard per i token fungibili. In altre parole, questi token hanno una proprietà che rende ogni token esattamente uguale (per tipo e valore) a un altro token. Per esempio, un token ERC-20 funziona esattamente come ETH, ossia 1 token è e sarà sempre uguale a tutti gli altri token.
+L'ERC-20 introduce uno standard per i Token Fungibili, in altre parole, hanno una proprietà che rende ogni Token esattamente uguale (per tipo e valore) a un altro Token. Ad esempio, un Token ERC-20 agisce proprio come l'ETH, il che significa che 1 Token è e sarà sempre uguale a tutti gli altri Token.
## Prerequisiti {#prerequisites}
-- [Conti](/developers/docs/accounts)
-- [Contratti Intelligenti](/developers/docs/smart-contracts/)
-- [Standard per i token](/developers/docs/standards/tokens/)
+- [Account](/developers/docs/accounts)
+- [Contratti intelligenti](/developers/docs/smart-contracts/)
+- [Standard dei token](/developers/docs/standards/tokens/)
## Corpo {#body}
-L'ERC-20 (Ethereum Request for Comments 20), proposto da Fabian Vogelsteller nel novembre del 2015, è uno Standard del Token che implementa un'API per i token nei Contratti Intelligenti.
+L'ERC-20 (Ethereum Request for Comments 20), proposto da Fabian Vogelsteller nel novembre 2015, è uno Standard dei Token che implementa un'API per i token all'interno dei contratti intelligenti.
-Esempio di funzionalità fornite da ERC-20:
+Esempi di funzionalità fornite dall'ERC-20:
-- trasferire token da un conto all'altro
-- ottenere il saldo corrente di token di un conto
-- richiedere la quantità totale di token disponibile sulla rete
-- approvare se un importo di token da un conto è spendibile da un conto di terze parti
+- trasferire token da un account a un altro
+- ottenere il saldo attuale dei token di un account
+- ottenere l'offerta totale del token disponibile sulla rete
+- approvare se una quantità di token di un account può essere spesa da un account di terze parti
-Se un Contratto Intelligente implementa i seguenti metodi ed eventi, può esser definito un Contratto a Token ERC-20 e, una volta distribuito, sarà responsabile di tenere traccia dei token creati su Ethereum.
+Se un contratto intelligente implementa i seguenti metodi ed eventi, può essere definito un Contratto di Token ERC-20 e, una volta distribuito, sarà responsabile di tenere traccia dei token creati su Ethereum.
Da [EIP-20](https://eips.ethereum.org/EIPS/eip-20):
@@ -67,11 +67,11 @@ event Approval(address indexed _owner, address indexed _spender, uint256 _value)
### Esempi {#web3py-example}
-Vediamo perché uno standard è così importante per semplificare l'ispezione dei contratti token ERC-20 su Ethereum. Ci serve solo la Contract Application Binary Interface (ABI) per creare un'interfaccia per qualsiasi token ERC-20. Come puoi vedere di seguito, useremo un'ABI semplificata per fornire un esempio semplice da capire.
+Vediamo come uno Standard sia così importante per semplificarci l'ispezione di qualsiasi Contratto di Token ERC-20 su Ethereum. Abbiamo solo bisogno dell'Application Binary Interface (ABI) del contratto per creare un'interfaccia per qualsiasi Token ERC-20. Come puoi vedere di seguito, utilizzeremo un'ABI semplificata, per renderlo un esempio a basso attrito.
-#### Esempio Web3.py {#web3py-example}
+#### Esempio con Web3.py {#web3py-example}
-Prima di tutto, controlla di avere installato la libreria Python [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation):
+Innanzitutto, assicurati di aver installato la libreria Python [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation):
```
pip install web3
@@ -83,13 +83,13 @@ from web3 import Web3
w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
-dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI
-weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH)
+dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI
+weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH)
-acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2
+acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2
-# questa è un'ABI (Contract Application Binary Interface) semplificata per un contratto token ERC-20.
-# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply()
+# Questa è una Contract Application Binary Interface (ABI) semplificata di un contratto token ERC-20.
+# Esporrà solo i metodi: balanceOf(address), decimals(), symbol() e totalSupply()
simplified_abi = [
{
'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}],
@@ -123,7 +123,7 @@ decimals = dai_contract.functions.decimals().call()
totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals
addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals
-# DAI
+# DAI
print("===== %s =====" % symbol)
print("Total Supply:", totalSupply)
print("Addr Balance:", addr_balance)
@@ -134,7 +134,7 @@ decimals = weth_contract.functions.decimals().call()
totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals
addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals
-# WETH
+# WETH
print("===== %s =====" % symbol)
print("Total Supply:", totalSupply)
print("Addr Balance:", addr_balance)
@@ -142,32 +142,49 @@ print("Addr Balance:", addr_balance)
## Problemi noti {#erc20-issues}
-### Problema di ricezione del token ERC-20 {#reception-issue}
+### Problema di ricezione dei token ERC-20 {#reception-issue}
-Quando i token ERC-20 sono inviati a un contratto intelligente non progettato per gestirli, questi potrebbero essere perduti permanentemente. Questo si verifica perché il contratto ricevente non dispone della funzionalità per riconoscere o rispondere ai token in entrata e perché nello standard ERC-20 non è presente alcun meccanismo per avvertire il contratto ricevente dei token in entrata. Le forme principali assunte da questo problema sono:
+**Al 20/06/2024, almeno 83.656.418 $ in token ERC-20 sono stati persi a causa di questo problema. Nota che un'implementazione ERC-20 pura è soggetta a questo problema a meno che non si implementi una serie di restrizioni aggiuntive oltre allo standard, come elencato di seguito.**
-1. Meccanismo di trasferimento del token
- - I token ERC-20 sono trasferiti utilizzando le funzioni transfer e transferFrom
- - Quando un utente invia i token a un indirizzo del contratto utilizzando queste funzioni, i token sono trasferiti indipendentemente dal fatto che il contratto ricevente sia progettato per gestirli
-2. Mancanza di notifica
- - Il contratto ricevente non riceve una notifica o callback quando gli vengono inviati i token
- - Se il contratto ricevente manca di un meccanismo per gestire i token (ad es. una funzione di ripiego o una funzione dedicata per gestirne la ricezione), i token restano di fatto bloccati nell'indirizzo del contratto
-3. Nessuna gestione integrata
- - Lo standard ERC-20 non include una funzione obbligatoria che i contratti riceventi devono implementare, il che comporta situazioni in cui molti contratti non riescono a gestire adeguatamente i token in entrata
+Quando i token ERC-20 vengono inviati a un contratto intelligente che non è progettato per gestire i token ERC-20, tali token possono andare persi in modo permanente. Questo accade perché il contratto ricevente non ha la funzionalità per riconoscere o rispondere ai token in arrivo e non c'è alcun meccanismo nello standard ERC-20 per notificare al contratto ricevente i token in arrivo. I modi principali in cui questo problema prende forma sono attraverso:
-Alcuni standard alternativi hanno risolto questo problema, come l'[ERC-223](/developers/docs/standards/tokens/erc-223) o l'[ERC-1363](/developers/docs/standards/tokens/erc-1363).
+1. Meccanismo di trasferimento dei token
+ - I token ERC-20 vengono trasferiti utilizzando le funzioni transfer o transferFrom
+ - Quando un utente invia token all'indirizzo del contratto utilizzando queste funzioni, i token vengono trasferiti indipendentemente dal fatto che il contratto ricevente sia progettato per gestirli
+2. Mancanza di notifica
+ - Il contratto ricevente non riceve una notifica o un callback che i token gli sono stati inviati
+ - Se il contratto ricevente non ha un meccanismo per gestire i token (ad es., una funzione di fallback o una funzione dedicata per gestire la ricezione dei token), i token rimangono effettivamente bloccati nell'indirizzo del contratto
+3. Nessuna gestione integrata
+ - Lo standard ERC-20 non include una funzione obbligatoria da implementare per i contratti riceventi, portando a una situazione in cui molti contratti non sono in grado di gestire correttamente i token in arrivo
+
+**Possibili Soluzioni**
+
+Sebbene non sia possibile prevenire completamente questo problema con l'ERC-20, esistono metodi che consentirebbero di ridurre significativamente la possibilità di perdita di token per l'utente finale:
+
+- Il problema più comune si verifica quando un utente invia token all'indirizzo del contratto del token stesso (ad es., USDT depositati all'indirizzo del contratto del token USDT). Si consiglia di limitare la funzione `transfer(..)` per annullare tali tentativi di trasferimento. Considera l'aggiunta del controllo `require(_to != address(this));` all'interno dell'implementazione della funzione `transfer(..)`.
+- La funzione `transfer(..)` in generale non è progettata per depositare token nei contratti. Il pattern `approve(..) & transferFrom(..)` viene invece utilizzato per depositare token ERC-20 nei contratti. È possibile limitare la funzione di trasferimento per impedire il deposito di token in qualsiasi contratto con essa, tuttavia ciò potrebbe interrompere la compatibilità con i contratti che presumono che i token possano essere depositati nei contratti con la funzione `transfer(..)` (ad es., le pool di liquidità di Uniswap).
+- Presumi sempre che i token ERC-20 possano finire nel tuo contratto anche se il tuo contratto non dovrebbe mai riceverne. Non c'è modo di prevenire o rifiutare depositi accidentali da parte del destinatario. Si consiglia di implementare una funzione che consenta di estrarre i token ERC-20 depositati accidentalmente.
+- Considera l'utilizzo di standard dei token alternativi.
+
+Da questo problema sono emersi alcuni standard alternativi come l'[ERC-223](/developers/docs/standards/tokens/erc-223) o l'[ERC-1363](/developers/docs/standards/tokens/erc-1363).
## Letture consigliate {#further-reading}
-- [EIP-20: Standard dei token ERC-20](https://eips.ethereum.org/EIPS/eip-20)
+- [EIP-20: Standard dei Token ERC-20](https://eips.ethereum.org/EIPS/eip-20)
- [OpenZeppelin - Token](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20)
- [OpenZeppelin - Implementazione ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol)
-- [Alchemy - Guida ai token ERC20 di Solidity](https://www.alchemy.com/overviews/erc20-solidity)
-
+- [Alchemy - Guida ai Token ERC20 in Solidity](https://www.alchemy.com/overviews/erc20-solidity)
## Altri standard di token fungibili {#fungible-token-standards}
- [ERC-223](/developers/docs/standards/tokens/erc-223)
- [ERC-1363](/developers/docs/standards/tokens/erc-1363)
- [ERC-777](/developers/docs/standards/tokens/erc-777)
-- [ERC-4626 - Casseforti tokenizzate](/developers/docs/standards/tokens/erc-4626)
\ No newline at end of file
+- [ERC-4626 - Caveau tokenizzati](/developers/docs/standards/tokens/erc-4626)
+
+## Tutorial: Sviluppare con l'ERC-20 su Ethereum {#tutorials}
+
+- [Panoramica del contratto ERC-20](/developers/tutorials/erc20-annotated-code/) _– Una panoramica annotata riga per riga dell'implementazione del contratto ERC-20 di OpenZeppelin._
+- [ERC-20 con misure di sicurezza](/developers/tutorials/erc20-with-safety-rails/) _– Come aggiungere salvaguardie ai token ERC-20 per aiutare gli utenti a evitare errori comuni._
+- [Inviare token utilizzando ethers.js](/developers/tutorials/send-token-ethersjs/) _– Una guida per principianti al trasferimento di token ERC-20 utilizzando ethers.js._
+- [Alcuni trucchi utilizzati dai token truffa e come rilevarli](/developers/tutorials/scam-token-tricks/) _– Un'analisi approfondita dei pattern dei token ERC-20 truffa e come identificarli._
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/it/developers/docs/standards/tokens/erc-223/index.md
index a18b66de118..d79ce24876e 100644
--- a/public/content/translations/it/developers/docs/standards/tokens/erc-223/index.md
+++ b/public/content/translations/it/developers/docs/standards/tokens/erc-223/index.md
@@ -1,44 +1,43 @@
---
-title: Standard dei token ERC-223
-description: Una panoramica dello standard per token fungibili ERC-223, come funziona e un confronto con ERC-20.
+title: Standard dei Token ERC-223
+description: Una panoramica dello standard dei token fungibili ERC-223, come funziona e un confronto con l'ERC-20.
lang: it
---
## Introduzione {#introduction}
-### Cos'è ERC-223? {#what-is-erc223}
+### Cos'è l'ERC-223? {#what-is-erc223}
-ERC-223 è uno standard per token fungibili simile allo standard ERC-20. La differenza principale è che ERC-223 definisce non solo l'API del token ma anche la logica per trasferire i token dal mittente al destinatario. Introduce un modello di comunicazione che permette la gestione dei trasferimenti di token da parte del destinatario.
+L'ERC-223 è uno standard per i token fungibili, simile allo standard ERC-20. La differenza chiave è che l'ERC-223 definisce non solo l'API del token, ma anche la logica per il trasferimento dei token dal mittente al destinatario. Introduce un modello di comunicazione che consente di gestire i trasferimenti di token dal lato del destinatario.
-### Differenze rispetto a ERC-20 {#erc20-differences}
+### Differenze rispetto all'ERC-20 {#erc20-differences}
-ERC-223 affronta alcune limitazioni di ERC-20 e introduce un nuovo metodo di interazione tra il contratto del token e un contratto che potrebbe ricevere i token. Ci sono alcune cose che sono possibili con ERC-223 ma non con ERC-20:
+L'ERC-223 affronta alcune limitazioni dell'ERC-20 e introduce un nuovo metodo di interazione tra il contratto del token e un contratto che potrebbe ricevere i token. Ci sono alcune cose che sono possibili con l'ERC-223 ma non con l'ERC-20:
-- La gestione del trasferimento dei token da parte del destinatario: i destinatari possono rilevare che un token ERC-223 è stato depositato.
-- Il rifiuto di token inviati erroneamente: se un utente manda dei token ERC-223 a un contratto che non dovrebbe ricevere token, il contratto può rifiutare la transazione impedendo la perdita di token.
-- Metadati nei trasferimenti: i token ERC-223 possono includere metadati, permettendo di allegare informazioni arbitrarie alle transazioni di token.
+- Gestione del trasferimento di token dal lato del destinatario: i destinatari possono rilevare che un token ERC-223 viene depositato.
+- Rifiuto di token inviati in modo improprio: se un utente invia token ERC-223 a un contratto che non dovrebbe ricevere token, il contratto può rifiutare la transazione, prevenendo la perdita di token.
+- Metadati nei trasferimenti: i token ERC-223 possono includere metadati, consentendo di allegare informazioni arbitrarie alle transazioni di token.
## Prerequisiti {#prerequisites}
-- [Conti](/developers/docs/accounts)
+- [Account](/developers/docs/accounts)
- [Contratti intelligenti](/developers/docs/smart-contracts/)
- [Standard dei token](/developers/docs/standards/tokens/)
- [ERC-20](/developers/docs/standards/tokens/erc-20/)
-## Body {#body}
+## Corpo {#body}
-ERC-223 è uno standard di token che implementa un'API per i token con contratti intelligenti. Dichiara anche un'API per i contratti che dovrebbero ricevere token ERC-223. I contratti che non supportano l'API ERC-223 del destinatario non possono ricevere token ERC-223, impedendo un errore utente.
+L'ERC-223 è uno standard di token che implementa un'API per i token all'interno dei contratti intelligenti. Dichiara inoltre un'API per i contratti che dovrebbero ricevere token ERC-223. I contratti che non supportano l'API del Ricevitore ERC-223 non possono ricevere token ERC-223, prevenendo errori da parte dell'utente.
-Se un contratto intelligente implementa i seguenti metodi ed eventi può essere definito contratto di toke compatibile con ERC-223. Una volta distribuito,
-sarà responsabile di tener traccia dei token creati su Ethereum.
+Se un contratto intelligente implementa i seguenti metodi ed eventi, può essere definito un contratto di token compatibile con l'ERC-223. Una volta distribuito, sarà responsabile di tenere traccia dei token creati su Ethereum.
-Il contratto non è obbligato ad avere solo queste funzioni e uno sviluppatore può aggiungere qualsiasi altra funzione da diversi standard di token a questo contratto. Per esempio, le funzioni `approve` e `transferFrom` non sono parte dello standard ERC-223 ma queste funzioni potrebbero essere implementate se necessario.
+Il contratto non è obbligato ad avere solo queste funzioni e uno sviluppatore può aggiungere a questo contratto qualsiasi altra funzionalità da diversi standard di token. Ad esempio, le funzioni `approve` e `transferFrom` non fanno parte dello standard ERC-223, ma queste funzioni potrebbero essere implementate qualora fosse necessario.
Da [EIP-223](https://eips.ethereum.org/EIPS/eip-223):
### Metodi {#methods}
-Il token ERC-223 deve implementare i metodi seguenti:
+Il token ERC-223 deve implementare i seguenti metodi:
```solidity
function name() public view returns (string)
@@ -50,13 +49,13 @@ function transfer(address _to, uint256 _value) public returns (bool success)
function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success)
```
-Un contratto che debba ricevere token ERC-223 deve implementare il metodo seguente:
+Un contratto che dovrebbe ricevere token ERC-223 deve implementare il seguente metodo:
```solidity
function tokenReceived(address _from, uint _value, bytes calldata _data)
```
-Se i token ERC-223 sono inviati a un contratto che non ha implementato la funzione `tokenReceived(..)`, il trasferimento deve fallire e i token non possono essere spostati dal saldo del mittente.
+Se i token ERC-223 vengono inviati a un contratto che non implementa la funzione `tokenReceived(..)`, il trasferimento deve fallire e i token non devono essere spostati dal saldo del mittente.
### Eventi {#events}
@@ -66,11 +65,11 @@ event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes
### Esempi {#examples}
-L'API del token ERC-223 è simile a quella del ERC-20, quindi dalla prospettiva dello sviluppo della UI non ci sono differenze. L'unica eccezione qui è che i token ERC-223 potrebbero non avere le funzioni `approve` + `transferFrom` dato che sono facoltative per questo standard.
+L'API del token ERC-223 è simile a quella dell'ERC-20, quindi dal punto di vista dello sviluppo dell'interfaccia utente non c'è alcuna differenza. L'unica eccezione qui è che i token ERC-223 potrebbero non avere le funzioni `approve` + `transferFrom`, poiché queste sono opzionali per questo standard.
#### Esempi in Solidity {#solidity-example}
-L'esempio seguente illustra come funziona un contratto del token ERC-223 di base:
+Il seguente esempio illustra come opera un contratto di token ERC-223 di base:
```solidity
pragma solidity ^0.8.19;
@@ -116,7 +115,7 @@ contract VeryBasicERC223Token {
}
```
-Adesso vogliamo che un altro contratto accetti i depositi di `tokenA` presupponendo che il tokenA sia un token ERC-223. Il contratto deve accettare solo tokenA e rigettare qualsiasi altro token. Quando il contratto riceve tokenA deve emettere un evento `Deposit()` e aumentare il valore della variabile interna `deposits`.
+Ora vogliamo che un altro contratto accetti depositi di `tokenA` supponendo che tokenA sia un token ERC-223. Il contratto deve accettare solo tokenA e rifiutare qualsiasi altro token. Quando il contratto riceve tokenA, deve emettere un evento `Deposit()` e aumentare il valore della variabile interna `deposits`.
Ecco il codice:
@@ -124,14 +123,14 @@ Ecco il codice:
contract RecipientContract is IERC223Recipient {
event Deposit(address whoSentTheTokens);
uint256 deposits = 0;
- address tokenA; // The only token that we want to accept.
+ address tokenA; // L'unico token che vogliamo accettare.
function tokenReceived(address _from, uint _value, bytes memory _data) public override
{
- // It is important to understand that within this function
- // msg.sender is the address of a token that is being received,
- // msg.value is always 0 as the token contract does not own or send Ether in most cases,
- // _from is the sender of the token transfer,
- // _value is the amount of tokens that was deposited.
+ // È importante capire che all'interno di questa funzione
+ // msg.sender è l'indirizzo di un token che viene ricevuto,
+ // msg.value è sempre 0 poiché il contratto del token non possiede né invia ether nella maggior parte dei casi,
+ // _from è il mittente del trasferimento del token,
+ // _value è la quantità di token che è stata depositata.
require(msg.sender == tokenA);
deposits += _value;
emit Deposit(_from);
@@ -141,31 +140,31 @@ contract RecipientContract is IERC223Recipient {
## Domande frequenti {#faq}
-### Cosa succede se mandiamo dei tokenB al contratto? {#sending-tokens}
+### Cosa succederà se inviamo del tokenB al contratto? {#sending-tokens}
-La transazione fallirà e il trasferimento dei token non avrà luogo. I token saranno restituiti all'indirizzo del mittente.
+La transazione fallirà e il trasferimento dei token non avverrà. I token verranno restituiti all'indirizzo del mittente.
-### Come possiamo fare un deposito su questo contratto? {#contract-deposits}
+### Come possiamo effettuare un deposito su questo contratto? {#contract-deposits}
-Chiamare la funzione `transfer(address,uint256)` o `transfer(address,uint256,bytes)` del token ERC-223 specificando l'indirizzo del `RecipientContract`.
+Chiama la funzione `transfer(address,uint256)` o `transfer(address,uint256,bytes)` del token ERC-223, specificando l'indirizzo del `RecipientContract`.
-### Cosa succede se trasferiamo un token ERC-20 a questo contratto? {#erc-20-transfers}
+### Cosa succederà se trasferiamo un token ERC-20 a questo contratto? {#erc-20-transfers}
-Se un token ERC-20 viene inviato al `RecipientContract`, i token saranno trasferiti ma il trasferimento non verrà riconosciuto (non sarà attivato alcun evento `Deposit()` e il valore del deposito non cambierà). Non è possibile filtrare o impedire depositi di ERC-20 indesiderati.
+Se un token ERC-20 viene inviato al `RecipientContract`, i token verranno trasferiti, ma il trasferimento non sarà riconosciuto (nessun evento `Deposit()` verrà attivato e il valore dei depositi non cambierà). I depositi ERC-20 indesiderati non possono essere filtrati o prevenuti.
-### E nel caso volessimo eseguire qualche funzione dopo che il deposito del token è completato? {#function-execution}
+### E se volessimo eseguire una funzione dopo il completamento del deposito del token? {#function-execution}
-Ci sono vari modi per farlo. In questo esempio seguiamo il metodo che rende i trasferimenti di ERC-223 identici a trasferimenti di Ether:
+Ci sono diversi modi per farlo. In questo esempio seguiremo il metodo che rende i trasferimenti ERC-223 identici ai trasferimenti di ether:
```solidity
contract RecipientContract is IERC223Recipient {
event Foo();
event Bar(uint256 someNumber);
- address tokenA; // The only token that we want to accept.
+ address tokenA; // L'unico token che vogliamo accettare.
function tokenReceived(address _from, uint _value, bytes memory _data) public override
{
require(msg.sender == tokenA);
- address(this).call(_data); // Handle incoming transaction and perform a subsequent function call.
+ address(this).call(_data); // Gestire la transazione in entrata ed eseguire una successiva chiamata di funzione.
}
function foo() public
{
@@ -178,21 +177,21 @@ contract RecipientContract is IERC223Recipient {
}
```
-Quando il `RecipientContract` riceverà un token ERC-223 il contratto eseguirà una funzione codificata come parametro `_data` della transazione del token, in modo identico a come le transazioni di Ether codificano le chiamate di funzioni come transazioni `data`. Leggi [il campo dati](/developers/docs/transactions/#the-data-field) per maggiori informazioni.
+Quando il `RecipientContract` riceverà un token ERC-223, il contratto eseguirà una funzione codificata come parametro `_data` della transazione del token, in modo identico a come le transazioni di ether codificano le chiamate di funzione come `data` della transazione. Leggi [il campo dei dati](/developers/docs/transactions/#the-data-field) per maggiori informazioni.
-Nell'esempio precedente un token ERC-223 deve essere trasferito all'indirizzo del `RecipientContract` con la funzione `transfer(address,uin256,bytes calldata _data)`. Se il parametro dei dati sarà `0xc2985578` (la firma di una funzione `foo()`) allora la funzione foo() sarà invocata dopo che il deposito del token è stato ricevuto e l'evento Foo() è stato attivato.
+Nell'esempio sopra, un token ERC-223 deve essere trasferito all'indirizzo del `RecipientContract` con la funzione `transfer(address,uin256,bytes calldata _data)`. Se il parametro dei dati sarà `0xc2985578` (la firma di una funzione `foo()`), allora la funzione foo() verrà invocata dopo aver ricevuto il deposito del token e verrà attivato l'evento Foo().
-I parametri possono essere codificati anche come `data` del trasferimento del token, per esempio possiamo chiamare la funzione bar() con valore 12345 per `_someNumber`. In questo caso `data` deve essere `0x0423a13200000000000000000000000000000000000000000000000000000000000004d2` dove `0x0423a132` è la firma della funzione `bar(uint256)` e `00000000000000000000000000000000000000000000000000000000000004d2` è 12345 in uint256.
+I parametri possono essere codificati anche nei `data` del trasferimento del token, ad esempio possiamo chiamare la funzione bar() con il valore 12345 per `_someNumber`. In questo caso i `data` devono essere `0x0423a13200000000000000000000000000000000000000000000000000000000000004d2` dove `0x0423a132` è la firma della funzione `bar(uint256)` e `00000000000000000000000000000000000000000000000000000000000004d2` è 12345 come uint256.
## Limitazioni {#limitations}
-Nonostante ERC-223 affronti diversi problemi che si trovano nello standard ERC-20, non è privo di limitazioni:
+Sebbene l'ERC-223 affronti diversi problemi riscontrati nello standard ERC-20, non è privo di limitazioni:
-- Adozione e compatibilità: ERC-223 non è ancora adottato ampiamente, il che potrebbe limitarne la compatibilità con strumenti e piattaforme esistenti.
-- Compatibilità retroattiva: ERC-223 non è compatibile con le versioni precedenti di ERC-20, il che significa che i contratti ERC-20 e gli strumenti esistenti non funzionano con i token ERC-223 senza modifiche.
-- Costi del gas: ulteriori controlli e funzionalità nei trasferimenti di ERC-223 potrebbero risultare in costi del gas maggiori rispetto a transazioni di ERC-20.
+- Adozione e compatibilità: l'ERC-223 non è ancora ampiamente adottato, il che potrebbe limitare la sua compatibilità con gli strumenti e le piattaforme esistenti.
+- Retrocompatibilità: l'ERC-223 non è retrocompatibile con l'ERC-20, il che significa che i contratti e gli strumenti ERC-20 esistenti non funzioneranno con i token ERC-223 senza modifiche.
+- Costi del gas: i controlli e le funzionalità aggiuntive nei trasferimenti ERC-223 potrebbero comportare costi del gas più elevati rispetto alle transazioni ERC-20.
## Letture consigliate {#further-reading}
-- [EIP-223: standard per token ERC-223](https://eips.ethereum.org/EIPS/eip-223)
-- [Proposta iniziale di ERC-223](https://github.com/ethereum/eips/issues/223)
+- [EIP-223: Standard dei Token ERC-223](https://eips.ethereum.org/EIPS/eip-223)
+- [Proposta iniziale dell'ERC-223](https://github.com/ethereum/eips/issues/223)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/it/developers/docs/standards/tokens/erc-4626/index.md
index 441c54a55a2..36001c20082 100644
--- a/public/content/translations/it/developers/docs/standards/tokens/erc-4626/index.md
+++ b/public/content/translations/it/developers/docs/standards/tokens/erc-4626/index.md
@@ -1,26 +1,42 @@
---
-title: Standard della cassaforte tokenizzata ERC-4626
-description: Uno standard per le cassaforti di resa.
+title: Standard dei Vault Tokenizzati ERC-4626
+description: Uno standard per i vault che generano rendimento.
lang: it
---
## Introduzione {#introduction}
-ERC-4626 è uno standard per ottimizzare e unificare i parametri tecnici delle cassaforti di resa. Fornisce un'API standard per le cassaforti di resa tokenizzate che rappresenta le quote di un singolo token ERC-20 sottostante. ERC-4626 delinea anche un'estensione facoltativa per le cassaforti tokenizzate usando ERC-20, offrendo le funzionalità di base per depositare e prelevare token e leggere i saldi.
+L'ERC-4626 è uno standard per ottimizzare e unificare i parametri tecnici dei vault che generano rendimento. Fornisce un'API standard per i vault tokenizzati che generano rendimento che rappresentano quote di un singolo token ERC-20 sottostante. L'ERC-4626 delinea anche un'estensione opzionale per i vault tokenizzati che utilizzano l'ERC-20, offrendo funzionalità di base per depositare, prelevare token e leggere i saldi.
-**Il ruolo dell'ERC-4626 nelle cassaforti di resa**
+**Il ruolo dell'ERC-4626 nei vault che generano rendimento**
-I mercati di prestito, gli aggregatori e i token intrinsecamente fruttiferi di interessi aiutano gli utenti a trovare la miglior resa sui propri cripto-token eseguendo strategie differenti. Queste strategie sono create con lievi variazioni, che potrebbero essere incline a errore o potrebbero sprecare risorse di sviluppo.
+I mercati di prestito, gli aggregatori e i token intrinsecamente fruttiferi aiutano gli utenti a trovare il miglior rendimento sui loro token crittografici eseguendo diverse strategie. Queste strategie vengono eseguite con lievi variazioni, il che potrebbe essere soggetto a errori o sprecare risorse di sviluppo.
-L'ERC-4626 nelle cassaforti di resa ridurrà lo sforzo di integrazione e sbloccherà l'accesso alla resa in varie applicazioni con piccoli sforzi specializzati dagli sviluppatori, creando schemi d'implementazione coerenti e robusti.
+L'ERC-4626 nei vault che generano rendimento ridurrà lo sforzo di integrazione e sbloccherà l'accesso al rendimento in varie applicazioni con poco sforzo specializzato da parte degli sviluppatori, creando modelli di implementazione più coerenti e robusti.
-Il token ERC-4626 è descritto nella sua interezza in [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626).
+Il token ERC-4626 è descritto completamente nell'[EIP-4626](https://eips.ethereum.org/EIPS/eip-4626).
+
+**Estensione asincrona del vault (ERC-7540)**
+
+L'ERC-4626 è ottimizzato per depositi e rimborsi atomici fino a un limite. Se il limite viene raggiunto, non possono essere inviati nuovi depositi o rimborsi. Questa limitazione non funziona bene per alcun sistema di contratto intelligente con azioni asincrone o ritardi come prerequisito per interfacciarsi con il Vault (ad es. protocolli di asset del mondo reale, protocolli di prestito sottocollateralizzati, protocolli di prestito cross-chain, token di staking liquido o moduli di sicurezza assicurativa).
+
+L'ERC-7540 espande l'utilità dei Vault ERC-4626 per i casi d'uso asincroni. L'interfaccia esistente del Vault (`deposit`/`withdraw`/`mint`/`redeem`) è completamente utilizzata per rivendicare le Richieste asincrone.
+
+L'estensione ERC-7540 è descritta completamente nell'[ERC-7540](https://eips.ethereum.org/EIPS/eip-7540).
+
+**Estensione del vault multi-asset (ERC-7575)**
+
+Un caso d'uso mancante che non è supportato dall'ERC-4626 sono i Vault che hanno più asset o punti di ingresso come i Token dei fornitori di liquidità (LP). Questi sono generalmente poco maneggevoli o non conformi a causa del requisito dell'ERC-4626 di essere esso stesso un ERC-20.
+
+L'ERC-7575 aggiunge il supporto per i Vault con più asset esternalizzando l'implementazione del token ERC-20 dall'implementazione dell'ERC-4626.
+
+L'estensione ERC-7575 è descritta completamente nell'[ERC-7575](https://eips.ethereum.org/EIPS/eip-7575).
## Prerequisiti {#prerequisites}
-Per comprendere meglio questa pagina, consigliamo innanzitutto di leggere [standard per i token](/developers/docs/standards/tokens/) e [ERC-20](/developers/docs/standards/tokens/erc-20/).
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima gli [standard dei token](/developers/docs/standards/tokens/) e l'[ERC-20](/developers/docs/standards/tokens/erc-20/).
-## ERC-4626 Funzioni e caratteristiche: {#body}
+## Funzioni e caratteristiche dell'ERC-4626: {#body}
### Metodi {#methods}
@@ -30,7 +46,7 @@ Per comprendere meglio questa pagina, consigliamo innanzitutto di leggere [stand
function asset() public view returns (address assetTokenAddress)
```
-Questa funzione restituisce l'indirizzo del token sottostante, utilizzato per la cassaforte per la contabilità, i depositi e i prelievi.
+Questa funzione restituisce l'indirizzo del token sottostante utilizzato per il vault per la contabilità, il deposito e il prelievo.
#### totalAssets {#totalassets}
@@ -38,7 +54,7 @@ Questa funzione restituisce l'indirizzo del token sottostante, utilizzato per la
function totalAssets() public view returns (uint256)
```
-Questa funzione restituisce l'importo totale di risorse sottostanti detenute dalla cassaforte.
+Questa funzione restituisce l'importo totale degli asset sottostanti detenuti dal vault.
#### convertToShares {#convertoshares}
@@ -46,7 +62,7 @@ Questa funzione restituisce l'importo totale di risorse sottostanti detenute dal
function convertToShares(uint256 assets) public view returns (uint256 shares)
```
-Questa funzione restituisce la quantità di `shares` che sarebbe scambiata dalla cassaforte per la quantità fornita di `assets`.
+Questa funzione restituisce la quantità di `shares` (quote) che verrebbe scambiata dal vault per la quantità di `assets` fornita.
#### convertToAssets {#convertoassets}
@@ -54,7 +70,7 @@ Questa funzione restituisce la quantità di `shares` che sarebbe scambiata dalla
function convertToAssets(uint256 shares) public view returns (uint256 assets)
```
-Questa funzione restituisce la quantità di `assets` che sarebbe scambiata dalla cassaforte per la quantità di `shares` fornita.
+Questa funzione restituisce la quantità di `assets` che verrebbe scambiata dal vault per la quantità di `shares` fornita.
#### maxDeposit {#maxdeposit}
@@ -62,7 +78,7 @@ Questa funzione restituisce la quantità di `assets` che sarebbe scambiata dalla
function maxDeposit(address receiver) public view returns (uint256 maxAssets)
```
-Questa funzione restituisce la quantità massima di risorse sottostanti depositabili in una singola chiamata a [`deposit`](#deposit) dal `receiver`.
+Questa funzione restituisce l'importo massimo di asset sottostanti che possono essere depositati in una singola chiamata [`deposit`](#deposit), con le quote coniate per il `receiver`.
#### previewDeposit {#previewdeposit}
@@ -78,7 +94,7 @@ Questa funzione consente agli utenti di simulare gli effetti del loro deposito a
function deposit(uint256 assets, address receiver) public returns (uint256 shares)
```
-Questa funzione deposita `assets` di token sottostanti nella cassaforte e concede la proprietà delle `shares` al `receiver`.
+Questa funzione deposita gli `assets` dei token sottostanti nel vault e concede la proprietà delle `shares` al `receiver`.
#### maxMint {#maxmint}
@@ -86,7 +102,7 @@ Questa funzione deposita `assets` di token sottostanti nella cassaforte e conced
function maxMint(address receiver) public view returns (uint256 maxShares)
```
-Questa funzione restituisce la quantità massima di quote coniabili in una sola chiamata a [`mint`](#mint) dal `receiver`.
+Questa funzione restituisce la quantità massima di quote che possono essere coniate in una singola chiamata [`mint`](#mint), con le quote coniate per il `receiver`.
#### previewMint {#previewmint}
@@ -94,7 +110,7 @@ Questa funzione restituisce la quantità massima di quote coniabili in una sola
function previewMint(uint256 shares) public view returns (uint256 assets)
```
-Questa funzione consente agli utenti di simulare gli effetti del loro conio al blocco corrente.
+Questa funzione consente agli utenti di simulare gli effetti della loro coniazione al blocco corrente.
#### mint {#mint}
@@ -102,7 +118,7 @@ Questa funzione consente agli utenti di simulare gli effetti del loro conio al b
function mint(uint256 shares, address receiver) public returns (uint256 assets)
```
-Questa funzione conia esattamente quote della cassaforte `shares` al `receiver`, depositando `assets` di token sottostanti.
+Questa funzione conia esattamente le `shares` del vault per il `receiver` depositando gli `assets` dei token sottostanti.
#### maxWithdraw {#maxwithdraw}
@@ -110,7 +126,7 @@ Questa funzione conia esattamente quote della cassaforte `shares` al `receiver`,
function maxWithdraw(address owner) public view returns (uint256 maxAssets)
```
-Questa funzione restituisce la quantità massima di risorse sottostanti prelevabili dal saldo dell'`owner` con una singola chiamata a [`withdraw`](#withdraw).
+Questa funzione restituisce l'importo massimo di asset sottostanti che possono essere prelevati dal saldo dell'`owner` con una singola chiamata [`withdraw`](#withdraw).
#### previewWithdraw {#previewwithdraw}
@@ -126,7 +142,7 @@ Questa funzione consente agli utenti di simulare gli effetti del loro prelievo a
function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares)
```
-Questa funzione brucia `shares` da `owner` e invia esattamente token `assets` dalla cassaforte al `receiver`.
+Questa funzione brucia le `shares` dall'`owner` e invia esattamente i token `assets` dal vault al `receiver`.
#### maxRedeem {#maxredeem}
@@ -134,7 +150,7 @@ Questa funzione brucia `shares` da `owner` e invia esattamente token `assets` da
function maxRedeem(address owner) public view returns (uint256 maxShares)
```
-Questa funzione restituisce la quantità massima di quote che possono essere riscattate dal saldo dell'`owner` tramite una chiamata a [`redeem`](#redeem).
+Questa funzione restituisce la quantità massima di quote che possono essere rimborsate dal saldo dell'`owner` tramite una chiamata [`redeem`](#redeem).
#### previewRedeem {#previewredeem}
@@ -142,7 +158,7 @@ Questa funzione restituisce la quantità massima di quote che possono essere ris
function previewRedeem(uint256 shares) public view returns (uint256 assets)
```
-Questa funzione consente agli utenti di simulare gli effetti del loro riscatto al blocco corrente.
+Questa funzione consente agli utenti di simulare gli effetti del loro rimborso al blocco corrente.
#### redeem {#redeem}
@@ -150,7 +166,7 @@ Questa funzione consente agli utenti di simulare gli effetti del loro riscatto a
function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets)
```
-Questa funzione riscatta un numero specifico di `shares` dall'`owner` e invia `assets` del token sottostante dalla cassaforte al `receiver`.
+Questa funzione rimborsa un numero specifico di `shares` dall'`owner` e invia gli `assets` del token sottostante dal vault al `receiver`.
#### totalSupply {#totalsupply}
@@ -158,7 +174,7 @@ Questa funzione riscatta un numero specifico di `shares` dall'`owner` e invia `a
function totalSupply() public view returns (uint256)
```
-Restituisce il numero totale di quote della cassaforte non riscattate in circolazione.
+Restituisce il numero totale di quote del vault non rimborsate in circolazione.
#### balanceOf {#balanceof}
@@ -166,17 +182,17 @@ Restituisce il numero totale di quote della cassaforte non riscattate in circola
function balanceOf(address owner) public view returns (uint256)
```
-Restituisce la quantità totale di quote della cassaforte che l'`owner` possiede attualmente.
+Restituisce l'importo totale delle quote del vault che l'`owner` possiede attualmente.
### Mappa dell'interfaccia {#mapOfTheInterface}
-
+
### Eventi {#events}
-#### Evento di Deposito
+#### Evento Deposit
-**DEVE** essere emesso quando i token sono depositati nella cassaforte tramite i metodi [`mint`](#mint) e [`deposit`](#deposit)
+**DEVE** essere emesso quando i token vengono depositati nel vault tramite i metodi [`mint`](#mint) e [`deposit`](#deposit).
```solidity
event Deposit(
@@ -187,11 +203,11 @@ event Deposit(
)
```
-Dove `sender` è l'utente che ha scambiato `assets` per `shares` e ha trasferito tali `shares` all'`owner`.
+Dove `sender` è l'utente che ha scambiato gli `assets` per le `shares` e ha trasferito tali `shares` all'`owner`.
-#### Evento di Prelievo (Withdraw)
+#### Evento Withdraw
-**DEVE** essere emesso quando le quote sono prelevate dalla cassaforte da un depositante con i metodi [`redeem`](#redeem) o [`withdraw`](#withdraw).
+**DEVE** essere emesso quando le quote vengono prelevate dal vault da un depositante nei metodi [`redeem`](#redeem) o [`withdraw`](#withdraw).
```solidity
event Withdraw(
@@ -203,9 +219,9 @@ event Withdraw(
)
```
-Dove `sender` è l'utente che ha innescato il prelievo e scambiato `shares`, possedute dall'`owner`, per `assets`. `receiver` è l'utente che ha ricevuto le `assets` prelevate.
+Dove `sender` è l'utente che ha attivato il prelievo e ha scambiato le `shares`, di proprietà dell'`owner`, per gli `assets`. `receiver` è l'utente che ha ricevuto gli `assets` prelevati.
## Letture consigliate {#further-reading}
-- [EIP-4626: Tokenized vault Standard](https://eips.ethereum.org/EIPS/eip-4626)
-- [ERC-4626: GitHub Repo](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol)
+- [EIP-4626: Standard dei vault tokenizzati](https://eips.ethereum.org/EIPS/eip-4626)
+- [ERC-4626: Repository GitHub](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/it/developers/docs/standards/tokens/erc-721/index.md
index d64b0dc7cde..6715e52a445 100644
--- a/public/content/translations/it/developers/docs/standards/tokens/erc-721/index.md
+++ b/public/content/translations/it/developers/docs/standards/tokens/erc-721/index.md
@@ -1,6 +1,6 @@
---
-title: Standard token non fungibile ERC-721
-description:
+title: Standard dei token non fungibili ERC-721
+description: Scopri l'ERC-721, lo standard per i token non fungibili (NFT) che rappresentano risorse digitali uniche su Ethereum.
lang: it
---
@@ -8,27 +8,29 @@ lang: it
**Cos'è un token non fungibile?**
-Un token non fungibile (NFT) è usato per identificare inequivocabilmente qualcosa o qualcuno. Questo tipo di Token è perfetto su piattaforme che offrono oggetti collezionabili, chiavi di accesso, biglietti della lotteria, posti numerati per concerti o eventi sportivi ecc. Questo particolare tipo di token offre possibilità straordinarie quindi si merita uno standard vero e proprio, ed ERC-721 serve proprio per questo!
+Un token non fungibile (NFT) è utilizzato per identificare qualcosa o qualcuno in modo unico. Questo tipo di token è perfetto per essere utilizzato su piattaforme che offrono oggetti da collezione, chiavi di accesso, biglietti della lotteria, posti numerati per concerti e partite sportive, ecc. Questo tipo speciale di token ha possibilità incredibili, quindi merita uno standard adeguato, e l'ERC-721 è nato per risolvere questo problema!
-**Cos'è ERC-721?**
+**Cos'è l'ERC-721?**
-L'ERC-721 introduce uno standard per gli NFT; in altre parole, questo tipo di Token è unico e può avere un valore differente da un altro Token dallo stesso Contratto Intelligente, forse a causa della sua età, rarità o persino ad altro, come il suo aspetto. Cosa? Aspetto?
+L'ERC-721 introduce uno standard per gli NFT; in altre parole, questo tipo di token è unico e può avere un valore diverso rispetto a un altro token proveniente dallo stesso contratto intelligente, magari a causa della sua età, rarità o persino di qualcos'altro come il suo aspetto visivo.
+Aspetta, aspetto visivo?
-Sì! Tutti gli NFT hanno una variabile `uint256` chiamata `tokenId`, quindi per i contratti ERC-721 la coppia `contract address, uint256 tokenId` deve essere unica a livello globale. Detto ciò, una dapp può avere un "convertitore" che utilizza il `tokenId` come input e restituisce l'immagine di qualcosa come zombie, armi, abilità o teneri gattini!
+Sì! Tutti gli NFT hanno una variabile `uint256` chiamata `tokenId`, quindi per qualsiasi contratto ERC-721, la coppia `indirizzo del contratto, uint256 tokenId` deve essere globalmente unica. Detto questo, una dApp può avere un "convertitore" che utilizza il `tokenId` come input e restituisce un'immagine di qualcosa di fantastico, come zombi, armi, abilità o gattini incredibili!
## Prerequisiti {#prerequisites}
-- [Conti](/developers/docs/accounts/)
-- [Contratti Intelligenti](/developers/docs/smart-contracts/)
-- [Standard token](/developers/docs/standards/tokens/)
+- [Account](/developers/docs/accounts/)
+- [Contratti intelligenti](/developers/docs/smart-contracts/)
+- [Standard dei token](/developers/docs/standards/tokens/)
## Corpo {#body}
-L'ERC-721 (Ethereum Request for Comments 721), proposto da William Entriken, Dieter Shirely, Jacob Evans e Nastassia Sachs a gennaio 2018, è uno Standard del Token Non Fungibile che implementa un'API per i token nei Contratti Intelligenti.
+L'ERC-721 ([Ethereum](/) Request for Comments 721), proposto da William Entriken, Dieter Shirley, Jacob Evans e Nastassia Sachs nel gennaio 2018, è uno standard per token non fungibili che implementa un'API per i token all'interno dei contratti intelligenti.
-Fornisce funzionalità come il trasferimento dei token da un conto all'altro, l'ottenimento del saldo corrente del token di un conto, l'ottenimento del proprietario di un token specifico, nonché l'offerta totale del token disponibile sulla rete. Oltre a ciò, ha alcune altre funzionalità, come approvare che un importo di token da un conto possa esser spostato da un conto di terze parti.
+Fornisce funzionalità come il trasferimento di token da un account a un altro, l'ottenimento del saldo attuale dei token di un account, l'identificazione del proprietario di un token specifico e anche l'offerta totale del token disponibile sulla rete.
+Oltre a queste, ha anche altre funzionalità, come l'approvazione affinché una quantità di token da un account possa essere spostata da un account di terze parti.
-Se un Contratto Intelligente implementa i seguenti metodi ed eventi, può esser definito un Contratto a Token Non Fungibile ERC-721 e, una volta distribuito, sarà responsabile di tenere traccia dei token creati su Ethereum.
+Se un contratto intelligente implementa i seguenti metodi ed eventi, può essere definito un contratto di token non fungibili ERC-721 e, una volta distribuito, sarà responsabile di tenere traccia dei token creati su Ethereum.
Da [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
@@ -56,11 +58,12 @@ Da [EIP-721](https://eips.ethereum.org/EIPS/eip-721):
### Esempi {#web3py-example}
-Vediamo perché uno standard è così importante per semplificare l'ispezione dei contratti token ERC-721 su Ethereum. Ci serve solo la Contract Application Binary Interface (ABI) per creare un'interfaccia per qualsiasi token ERC-721. Come puoi vedere di seguito, useremo un'ABI semplificata per fornire un esempio semplice da capire.
+Vediamo come uno standard sia così importante per semplificarci l'ispezione di qualsiasi contratto di token ERC-721 su Ethereum.
+Abbiamo solo bisogno dell'Application Binary Interface (ABI) del contratto per creare un'interfaccia verso qualsiasi token ERC-721. Come puoi vedere di seguito, utilizzeremo un'ABI semplificata, per renderlo un esempio a basso attrito.
-#### Esempio Web3.py {#web3py-example}
+#### Esempio con Web3.py {#web3py-example}
-Prima di tutto, controlla di avere installato la libreria Python [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation):
+Innanzitutto, assicurati di aver installato la libreria Python [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation):
```
pip install web3
@@ -73,12 +76,12 @@ from web3._utils.events import get_event_data
w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com"))
-ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract
+ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # Contratto CryptoKitties
-acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction
+acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # Asta di vendita CryptoKitties
-# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract.
-# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply()
+# Questa è una Contract Application Binary Interface (ABI) semplificata di un contratto NFT ERC-721.
+# Esporrà solo i metodi: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply()
simplified_abi = [
{
'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}],
@@ -136,7 +139,7 @@ print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}")
pregnant_kitties = ck_contract.functions.pregnantKitties().call()
print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}")
-# Using the Transfer Event ABI to get info about transferred Kitties.
+# Utilizzo dell'ABI dell'evento Transfer per ottenere informazioni sui Kitties trasferiti.
tx_event_abi = {
'anonymous': False,
'inputs': [
@@ -147,7 +150,7 @@ tx_event_abi = {
'type': 'event'
}
-# We need the event's signature to filter the logs
+# Abbiamo bisogno della firma dell'evento per filtrare i log
event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex()
logs = w3.eth.get_logs({
@@ -156,25 +159,25 @@ logs = w3.eth.get_logs({
"topics": [event_signature]
})
-# Notes:
-# - Increase the number of blocks up from 120 if no Transfer event is returned.
-# - If you didn't find any Transfer event you can also try to get a tokenId at:
-# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
-# Click to expand the event's logs and copy its "tokenId" argument
+# Note:
+# - Aumenta il numero di blocchi oltre 120 se non viene restituito alcun evento Transfer.
+# - Se non hai trovato alcun evento Transfer, puoi anche provare a ottenere un tokenId su:
+# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events
+# Fai clic per espandere i log dell'evento e copia il suo argomento "tokenId"
recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs]
if recent_tx:
- kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above
+ kitty_id = recent_tx[0]['tokenId'] # Incolla qui il "tokenId" dal link sopra
is_pregnant = ck_contract.functions.isPregnant(kitty_id).call()
print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}")
```
-Il contratto CryptoKitties contiene alcuni eventi interessanti oltre a quelli standard.
+Il contratto di CryptoKitties ha alcuni eventi interessanti oltre a quelli standard.
-Diamo un'occhiata a due di questi, `Pregnant` e `Birth`.
+Controlliamone due: `Pregnant` e `Birth`.
```python
-# Viene usata l'ABI Pregnant e Birth Events per ottenere informazioni sui nuovi gattini.
+# Utilizzo dell'ABI degli eventi Pregnant e Birth per ottenere informazioni sui nuovi Kitties.
ck_extra_events_abi = [
{
'anonymous': False,
@@ -198,13 +201,13 @@ ck_extra_events_abi = [
'type': 'event'
}]
-# We need the event's signature to filter the logs
+# Abbiamo bisogno della firma dell'evento per filtrare i log
ck_event_signatures = [
w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(),
w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(),
]
-# Here is a Pregnant Event:
+# Ecco un evento Pregnant:
# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog
pregnant_logs = w3.eth.get_logs({
"fromBlock": w3.eth.block_number - 120,
@@ -214,7 +217,7 @@ pregnant_logs = w3.eth.get_logs({
recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs]
-# Here is a Birth Event:
+# Ecco un evento Birth:
# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a
birth_logs = w3.eth.get_logs({
"fromBlock": w3.eth.block_number - 120,
@@ -225,20 +228,28 @@ birth_logs = w3.eth.get_logs({
recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs]
```
-## NFT più popolari {#popular-nfts}
+## NFT popolari {#popular-nfts}
-- [Etherscan NFT Tracker](https://etherscan.io/tokens-nft) elenca i principali NFT su Ethereum per volume di trasferimento.
-- [CryptoKitties](https://www.cryptokitties.co/) è un gioco basato su creature a cui si può dare da mangiare, collezionabili e molto tenere chiamate CryptoKitties.
-- [Sorare](https://sorare.com/) è un gioco di calcio fantasy globale in cui si possono collezionare oggetti in edizione limitata e gestire squadre, gareggiando per vincere premi.
-- [The Ethereum Name Service (ENS)](https://ens.domains/) offre un modo sicuro e decentralizzato per indirizzare risorse sia all'interno che all'esterno della blockchain utilizzando nomi semplici e leggibili.
-- [POAP](https://poap.xyz) offre NFT gratuiti alle persone che partecipano a eventi o completano azioni specifiche. I POAP sono creabili e distribuibili gratuitamente.
-- [Unstoppable Domains](https://unstoppabledomains.com/) è un'azienda di San Francisco che crea domini sulle blockchain. I domini delle blockchain sostituiscono gli indirizzi della criptovaluta con nomi leggibili dall'uomo, che possono essere usati per creare siti web resistenti alla censura.
-- [Gods Unchained Cards](https://godsunchained.com/) è un gioco di carte collezionabili sulla blockchain Ethereum che usa gli NFT per dare una proprietà reale alle risorse del gioco.
-- [Bored Ape Yacht Club](https://boredapeyachtclub.com) è una raccolta di 10.000 NFT unici che, oltre a essere opere d'arte la cui rarità è dimostrata, fungono da token di appartenenza al club, fornendo ai membri vantaggi e benefici che possono aumentare nel tempo come risultato degli sforzi della community.
+- [Etherscan NFT Tracker](https://etherscan.io/nft-top-contracts) elenca i migliori NFT su Ethereum per volume di trasferimenti.
+- [CryptoKitties](https://www.cryptokitties.co/) è un gioco incentrato su creature allevabili, collezionabili e adorabili che chiamiamo CryptoKitties.
+- [Sorare](https://sorare.com/) è un gioco di fantacalcio globale in cui puoi raccogliere oggetti da collezione in edizione limitata, gestire le tue squadre e competere per vincere premi.
+- [L'Ethereum Name Service (ENS)](https://ens.domains/) offre un modo sicuro e decentralizzato per indirizzare le risorse sia sulla blockchain che fuori utilizzando nomi semplici e leggibili dall'uomo.
+- [POAP](https://poap.xyz) distribuisce NFT gratuiti alle persone che partecipano a eventi o completano azioni specifiche. I POAP sono gratuiti da creare e distribuire.
+- [Unstoppable Domains](https://unstoppabledomains.com/) è un'azienda con sede a San Francisco che crea domini sulle blockchain. I domini blockchain sostituiscono gli indirizzi di criptovaluta con nomi leggibili dall'uomo e possono essere utilizzati per abilitare siti web resistenti alla censura.
+- [Gods Unchained Cards](https://godsunchained.com/) è un gioco di carte collezionabili (TCG) sulla blockchain di Ethereum che utilizza gli NFT per conferire la vera proprietà alle risorse di gioco.
+- [Bored Ape Yacht Club](https://boredapeyachtclub.com) è una collezione di 10.000 NFT unici che, oltre a essere un'opera d'arte di comprovata rarità, funge da token di appartenenza al club, fornendo vantaggi e benefici ai membri che aumentano nel tempo grazie agli sforzi della community.
## Letture consigliate {#further-reading}
-- [EIP-721: ERC-721 Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721)
-- [OpenZeppelin - ERC-721 Docs](https://docs.openzeppelin.com/contracts/3.x/erc721)
-- [OpenZeppelin - ERC-721 Implementation](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
-- [API di Alchemy NFT](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api)
+- [EIP-721: Standard dei token non fungibili ERC-721](https://eips.ethereum.org/EIPS/eip-721)
+- [OpenZeppelin - Documentazione ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721)
+- [OpenZeppelin - Implementazione ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol)
+- [API per NFT di Alchemy](https://www.alchemy.com/docs/reference/nft-api-quickstart)
+
+## Tutorial: Sviluppare con i token non fungibili (ERC-721) su Ethereum {#tutorials}
+
+- [Guida al contratto ERC-721 in Vyper](/developers/tutorials/erc-721-vyper-annotated-code/) _– Una guida annotata di un contratto NFT ERC-721 completo scritto in Vyper._
+- [Come scrivere e distribuire un NFT (Parte 1/3)](/developers/tutorials/how-to-write-and-deploy-an-nft/) _– Guida passo passo per scrivere e distribuire il tuo primo contratto intelligente ERC-721._
+- [Come coniare un NFT (Parte 2/3)](/developers/tutorials/how-to-mint-an-nft/) _– Come coniare un NFT ERC-721 utilizzando il tuo contratto intelligente distribuito e Web3._
+- [Come visualizzare il tuo NFT nel tuo portafoglio (Parte 3/3)](/developers/tutorials/how-to-view-nft-in-metamask/) _– Come visualizzare il tuo NFT coniato in MetaMask dopo la distribuzione._
+- [Tutorial per coniare NFT](/developers/tutorials/nft-minter/) _– Crea una dApp full-stack per coniare NFT con un frontend React, MetaMask e Alchemy._
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/it/developers/docs/standards/tokens/erc-777/index.md
new file mode 100644
index 00000000000..10f92791c55
--- /dev/null
+++ b/public/content/translations/it/developers/docs/standards/tokens/erc-777/index.md
@@ -0,0 +1,45 @@
+---
+title: Standard dei Token ERC-777
+description: Scopri l'ERC-777, uno standard migliorato per i token fungibili con hook, sebbene l'ERC-20 sia raccomandato per la sicurezza.
+lang: it
+---
+
+## Avvertenza {#warning}
+
+**L'ERC-777 è difficile da implementare correttamente, a causa della sua [suscettibilità a diverse forme di attacco](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620). Si raccomanda invece di utilizzare l'[ERC-20](/developers/docs/standards/tokens/erc-20/).** Questa pagina rimane come archivio storico.
+
+## Introduzione? {#introduction}
+
+L'ERC-777 è uno standard per token fungibili che migliora l'attuale standard [ERC-20](/developers/docs/standards/tokens/erc-20/).
+
+## Prerequisiti {#prerequisites}
+
+Per comprendere meglio questa pagina, ti consigliamo di leggere prima l'[ERC-20](/developers/docs/standards/tokens/erc-20/).
+
+## Quali miglioramenti propone l'ERC-777 rispetto all'ERC-20? {#-erc-777-vs-erc-20}
+
+L'ERC-777 fornisce i seguenti miglioramenti rispetto all'ERC-20.
+
+### Hook {#hooks}
+
+Gli hook sono una funzione descritta nel codice di un contratto intelligente. Gli hook vengono chiamati quando i token vengono inviati o ricevuti tramite il contratto. Ciò consente a un contratto intelligente di reagire ai token in entrata o in uscita.
+
+Gli hook vengono registrati e scoperti utilizzando lo standard [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820).
+
+#### Perché gli hook sono fantastici? {#why-are-hooks-great}
+
+1. Gli hook consentono di inviare token a un contratto e di notificare il contratto in una singola transazione, a differenza dell'[ERC-20](https://eips.ethereum.org/EIPS/eip-20), che richiede una doppia chiamata (`approve`/`transferFrom`) per ottenere questo risultato.
+2. I contratti che non hanno registrato hook sono incompatibili con l'ERC-777. Il contratto mittente interromperà la transazione quando il contratto ricevente non ha registrato un hook. Questo previene trasferimenti accidentali a contratti intelligenti non ERC-777.
+3. Gli hook possono rifiutare le transazioni.
+
+### Decimali {#decimals}
+
+Lo standard risolve anche la confusione attorno ai `decimals` causata nell'ERC-20. Questa chiarezza migliora l'esperienza degli sviluppatori.
+
+### Retrocompatibilità con l'ERC-20 {#backwards-compatibility-with-erc-20}
+
+È possibile interagire con i contratti ERC-777 come se fossero contratti ERC-20.
+
+## Letture consigliate {#further-reading}
+
+[EIP-777: Standard dei Token](https://eips.ethereum.org/EIPS/eip-777)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/standards/tokens/index.md b/public/content/translations/it/developers/docs/standards/tokens/index.md
index b608ec768ee..0b480b229f6 100644
--- a/public/content/translations/it/developers/docs/standards/tokens/index.md
+++ b/public/content/translations/it/developers/docs/standards/tokens/index.md
@@ -1,39 +1,41 @@
---
-title: Standard token
-description:
+title: Standard dei token
+description: Esplora gli standard dei token di Ethereum, inclusi ERC-20, ERC-721 ed ERC-1155 per token fungibili e non fungibili.
lang: it
incomplete: true
---
## Introduzione {#introduction}
-Molti standard di sviluppo di Ethereum si incentrano sulle interfacce dei token. Questi standard aiutano ad assicurarsi che i contratti intelligenti restino componibili, così che, ad esempio, quando un nuovo progetto emette un token, esso rimanga compatibile con le borse decentralizzate esistenti.
+Molti standard di sviluppo di [Ethereum](/) si concentrano sulle interfacce dei token. Questi standard aiutano a garantire che i contratti intelligenti rimangano componibili, in modo che quando un nuovo progetto emette un token, questo rimanga compatibile con le applicazioni e gli exchange decentralizzati esistenti.
+
+Gli standard dei token definiscono come i token si comportano e interagiscono nell'ecosistema di Ethereum. Semplificano il lavoro degli sviluppatori permettendo loro di costruire senza reinventare la ruota, garantendo che i token funzionino perfettamente con portafogli, exchange e piattaforme DeFi. Che si tratti di giochi, governance o altri casi d'uso, questi standard forniscono coerenza e rendono Ethereum più interconnesso.
## Prerequisiti {#prerequisites}
-- [Standard di sviluppo Ethereum](/developers/docs/standards/)
+- [Standard di sviluppo di Ethereum](/developers/docs/standards/)
- [Contratti intelligenti](/developers/docs/smart-contracts/)
-## Standard token {#token-standards}
+## Standard dei token {#token-standards}
-Ecco alcuni degli standard token più popolari su Ethereum:
+Ecco alcuni degli standard dei token più popolari su Ethereum:
-- [ERC-20](/developers/docs/standards/tokens/erc-20/) - Un'interfaccia standard per token fungibili (intercambiabili), come i token di voto, i token di staking o le valute virtuali.
+- [ERC-20](/developers/docs/standards/tokens/erc-20/) - Un'interfaccia standard per i token fungibili (intercambiabili), come i token di voto, i token di staking o le valute virtuali.
-### Standard NFT {#nft-standards}
+### Standard degli NFT {#nft-standards}
-- [ERC-721](/developers/docs/standards/tokens/erc-721/) - Un'interfaccia standard per token non fungibili, come un atto relativo a opere d'arte o canzoni.
-- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - ERC-1155 consente scambi e aggregazioni di transazioni più efficienti, risparmiando sui costi. Questo standard del token consente di creare token d'utilità (come $BNB o $BAT) e token non fungibili come CryptoPunks.
+- [ERC-721](/developers/docs/standards/tokens/erc-721/) - Un'interfaccia standard per i token non fungibili, come l'atto di proprietà di un'opera d'arte o di una canzone.
+- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) - L'ERC-1155 consente scambi più efficienti e il raggruppamento delle transazioni, risparmiando così sui costi. Questo standard dei token consente di creare sia token di utilità (come $BNB o $BAT) che token non fungibili come i CryptoPunks.
L'elenco completo delle proposte [ERC](https://eips.ethereum.org/erc).
## Letture consigliate {#further-reading}
-_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
## Tutorial correlati {#related-tutorials}
-- [Token integration checklist](/developers/tutorials/token-integration-checklist/) _- Una checklist di aspetti da considerare quando interagiamo con i token._
-- [Comprendere il contratto intelligente del token ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/): _Un'introduzione alla distribuzione del tuo primo contratto intelligente su una rete di prova di Ethereum._
-- [Trasferimenti e approvazione dei token ERC20 da un contratto intelligente in Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/): _Come usare un contratto intelligente per interagire con un token, usando il linguaggio Solidity._
-- [Implementing an ERC721 market [a how-to guide]](/developers/tutorials/how-to-implement-an-erc721-market/) _- Come mettere in vendita oggetti tokenizzati su una bacheca annunci decentralizzata._
+- [Lista di controllo per l'integrazione dei token](/developers/tutorials/token-integration-checklist/) _– Una lista di controllo delle cose da considerare quando si interagisce con i token._
+- [Comprendere il contratto intelligente del token ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Un'introduzione alla distribuzione del tuo primo contratto intelligente su una rete di test di Ethereum._
+- [Trasferimenti e approvazione di token ERC20 da un contratto intelligente in Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Come usare un contratto intelligente per interagire con un token usando il linguaggio Solidity._
+- [Implementare un mercato ERC721 [una guida pratica]](/developers/tutorials/how-to-implement-an-erc721-market/) _– Come mettere in vendita oggetti tokenizzati su una bacheca di annunci decentralizzata._
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/storage/index.md b/public/content/translations/it/developers/docs/storage/index.md
index ef3bd169125..3843306cd06 100644
--- a/public/content/translations/it/developers/docs/storage/index.md
+++ b/public/content/translations/it/developers/docs/storage/index.md
@@ -1,90 +1,90 @@
---
-title: Archiviazione Decentralizzata
-description: Panoramica di cos'è l'archiviazione decentralizzata e degli strumenti disponibili per integrarla in una dapp.
+title: Archiviazione decentralizzata
+description: "Panoramica di cos'è l'archiviazione decentralizzata e degli strumenti disponibili per integrarla in una dApp."
lang: it
---
-A differenza di un server centralizzato gestito da una singola società o organizzazione, il sistema di storage decentralizzato consiste in una rete peer-to-peer di operatori-user che trattengono una porzione di tutti i dati esistenti, creando un sistema resiliente di salvataggio e condivisione di file. Tale sistema può trovarsi in un'applicazione basata sulla blockchain o in qualunque rete peer-to-peer.
+A differenza di un server centralizzato gestito da una singola azienda o organizzazione, i sistemi di archiviazione decentralizzata consistono in una rete peer-to-peer di utenti-operatori che detengono una porzione dei dati complessivi, creando un sistema di condivisione e archiviazione di file resiliente. Questi possono trovarsi in un'applicazione basata su blockchain o in qualsiasi rete basata su peer-to-peer.
-Lo stesso Ethereum è utilizzabile come un sistema decentralizzato d'archiviazione e ciò avviene per l'archiviazione del codice in tutti i contratti intelligenti. Ad ogni modo, Ethereum non è stato progettato per gestire grandi quantitativi di dati. La catena Ethereum cresce costantemente e, al momento della redazione di questa pagina, si aggira intorno a 500GB - 1TB ([a seconda del client](https://etherscan.io/chartsync/chaindefault)), ed ogni nodo sulla rete deve essere in grado di memorizzare tutti i dati. Se la catena dovesse espandersi raggiungendo un grosso volume di dati (ad esempio 5TB), non sarebbe possibile continuare l'esecuzione di tutti i nodi. Inoltre, il costo di distribuzione di così tanti dati alla Rete Principale, sarebbe proibitivo a causa delle commissioni del [gas](/developers/docs/gas).
+Ethereum stesso può essere utilizzato come sistema di archiviazione decentralizzata, e lo è quando si tratta di archiviare il codice in tutti i contratti intelligenti. Tuttavia, quando si tratta di grandi quantità di dati, non è per questo che Ethereum è stato progettato. La catena è in costante crescita, ma al momento della stesura, la catena di Ethereum è di circa 500GB - 1TB ([a seconda del client](https://etherscan.io/chartsync/chaindefault)), e ogni nodo sulla rete deve essere in grado di archiviare tutti i dati. Se la catena dovesse espandersi a grandi quantità di dati (diciamo 5TB) non sarebbe fattibile per tutti i nodi continuare a funzionare. Inoltre, il costo di distribuzione di una tale quantità di dati sulla rete principale sarebbe proibitivo a causa delle commissioni del [gas](/developers/docs/gas).
-A causa di tali vincoli, necessitiamo di una catena o metodologia diversa per archiviare grandi quantità di dati in modo decentralizzato.
+A causa di questi vincoli, abbiamo bisogno di una catena o metodologia diversa per archiviare grandi quantità di dati in modo decentralizzato.
-Guardando alle opzioni di archiviazione decentralizzata (dStorage), esistono alcune cose che un utente deve tenere a mente.
+Quando si esaminano le opzioni di archiviazione decentralizzata (dStorage), ci sono alcune cose che un utente deve tenere a mente.
-- Meccanismo di persistenza / struttura d'incentivazione
-- Applicazione della ritenzione dei dati
-- Decentralità
+- Meccanismo di persistenza / struttura degli incentivi
+- Applicazione della conservazione dei dati
+- Decentralizzazione
- Consenso
-## Meccanismo di persistenza / struttura d'incentivazione {#persistence-mechanism}
+## Meccanismo di persistenza / struttura degli incentivi {#persistence-mechanism}
-### Basata sulla blockchain {#blockchain-based}
+### Basato su blockchain {#blockchain-based}
-Affinché un dato persista nel tempo, occorre usare un meccanismo di persistenza. Ad esempio, su Ethereum, il meccanismo di persistenza prevede di tener conto dell'intera catena, operando un nodo. Nuovi pezzi di dati vengono aggiunti alla fine della chain, e questa continua a crescere - richiedendo ad ogni nodo di replicare tutti i dati incorporati.
+Affinché un dato persista per sempre, dobbiamo utilizzare un meccanismo di persistenza. Ad esempio, su Ethereum, il meccanismo di persistenza prevede che l'intera catena debba essere presa in considerazione quando si esegue un nodo. Nuovi dati vengono aggiunti alla fine della catena, che continua a crescere, richiedendo a ogni nodo di replicare tutti i dati incorporati.
-Questo meccanismo prende il nome di persistenza **basata sulla blockchain**.
+Questa è nota come persistenza **basata su blockchain**.
-Il problema della persistenza basata sulla blockchain è che la chain potrebbe diventare troppo grande per mantenere e memorizzare tutti i dati in modo fattibile (e.g., [molte fonti](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) stimano che, per fare ciò, internet richieda una capacità di archiviazione di oltre 40 Zetabyte).
+Il problema con la persistenza basata su blockchain è che la catena potrebbe diventare troppo grande per mantenere e archiviare tutti i dati in modo fattibile (ad es., [molte fonti](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) stimano che Internet richieda oltre 40 Zettabyte di capacità di archiviazione).
-La blockchain deve anche avere qualche tipo di struttura d'incentivazione. Per la persistenza basata sulla blockchain, esiste un pagamento effettuato al validatore. Quando i dati sono aggiunti alla catena, i validatori sono pagati per aggiungervi i dati.
+La blockchain deve anche avere un qualche tipo di struttura degli incentivi. Per la persistenza basata su blockchain, viene effettuato un pagamento al validatore. Quando i dati vengono aggiunti alla catena, i validatori vengono pagati per aggiungervi i dati.
-Le piattaforme con persistenza basata sulla blockchain sono:
+Piattaforme con persistenza basata su blockchain:
- Ethereum
- [Arweave](https://www.arweave.org/)
-### Persistenza basata su contratto {#contract-based}
+### Basato su contratti {#contract-based}
-La persistenza **basata sul contratto** si basa sull'intuizione che i dati non possono essere replicati da ogni nodo e memorizzati per sempre, devono invece essere mantenuti con accordi contrattuali. Si tratta di accordi effettuati con più nodi che si sono impegnati a conservare un dato per un certo periodo di tempo. Per far sì che mantengano i dati, devono essere rimborsati o rinnovati ogni volta che scadono.
+La persistenza **basata su contratti** si fonda sull'intuizione che i dati non possono essere replicati da ogni nodo e archiviati per sempre, ma devono invece essere mantenuti tramite accordi contrattuali. Si tratta di accordi stipulati con più nodi che hanno promesso di conservare un dato per un periodo di tempo. Devono essere rimborsati o rinnovati ogni volta che scadono per mantenere i dati persistenti.
-In gran parte dei casi, invece di archiviare tutti i dati sulla catena, viene memorizzato l'hash che indica la posizione dei dati sulla catena. In questo modo, l'intera catena non deve scalare per mantenere tutti i dati.
+Nella maggior parte dei casi, invece di archiviare tutti i dati on-chain, viene archiviato l'hash della posizione in cui si trovano i dati su una catena. In questo modo, l'intera catena non ha bisogno di scalare per conservare tutti i dati.
-Le piattaforme con persistenza basata su contratto sono:
+Piattaforme con persistenza basata su contratti:
-- [Filecoin](https://docs.filecoin.io/about-filecoin/what-is-filecoin/)
-- [Skynet](https://siasky.net/)
+- [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin)
+- [Skynet](https://sia.tech/)
- [Storj](https://storj.io/)
- [Züs](https://zus.network/)
-- [Rete Crust](https://crust.network)
+- [Crust Network](https://crust.network)
- [Swarm](https://www.ethswarm.org/)
- [4EVERLAND](https://www.4everland.org/)
### Considerazioni aggiuntive {#additional-consideration}
-IPFS è un sistema distribuito per memorizzare e accedere a file, siti web, applicazioni e dati. Non ha un sistema di incentivi incorporato, ma può essere utilizzato con una qualsiasi delle soluzioni di incentivazione basate sul contratto citate prima per una persistenza di maggiore durata. Un altro modo per mantenere i dati su IPFS è quello di lavorare con un servizio di pinning, che "appunta" i dati per te. È possibile anche eseguire il proprio nodo IPFS e contribuire alla rete per conservare i propri dati e/o quelli degli altri gratuitamente!
+IPFS è un sistema distribuito per l'archiviazione e l'accesso a file, siti web, applicazioni e dati. Non ha uno schema di incentivi integrato, ma può invece essere utilizzato con una qualsiasi delle soluzioni di incentivi basate su contratti di cui sopra per una persistenza a lungo termine. Un altro modo per rendere persistenti i dati su IPFS è lavorare con un servizio di pinning, che "fisserà" (pin) i tuoi dati per te. Puoi persino eseguire il tuo nodo IPFS e contribuire alla rete per rendere persistenti i tuoi dati e/o quelli di altri gratuitamente!
- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/)
- [Pinata](https://www.pinata.cloud/) _(servizio di pinning IPFS)_
-- [Pinata](https://www.pinata.cloud/) _(servizio di pinning IPFS)_
-- [Pinata](https://www.pinata.cloud/) _(servizio di pinning IPFS)_
-- [IPFS Scan](https://ipfs-scan.io) _(esploratore di pinning di IPFS)_
-- [4EVERLAND](https://www.4everland.org/)_（Servizio di pinning IPFS）_
+- [web3.storage](https://web3.storage/) _(servizio di pinning IPFS/Filecoin)_
+- [Infura](https://infura.io/product/ipfs) _(servizio di pinning IPFS)_
+- [IPFS Scan](https://ipfs-scan.io) _(esploratore di pinning IPFS)_
+- [4EVERLAND](https://www.4everland.org/)_（servizio di pinning IPFS）_
- [Filebase](https://filebase.com) _(Servizio di pinning IPFS)_
-- [Spheron Network](https://spheron.network/) _(Servizio di pinning IPFS/Filecoin)_
+- [Spheron Network](https://spheron.network/) _(servizio di pinning IPFS/Filecoin)_
-SWARM è una tecnologia decentralizzata di archiviazione e distribuzione di dati con un sistema di incentivazione di archiviazione e un oracolo del prezzo di affitto della memoria.
+SWARM è una tecnologia di archiviazione e distribuzione dei dati decentralizzata con un sistema di incentivi per l'archiviazione e un oracolo per il prezzo di affitto dell'archiviazione.
-## Ritenzione dei dati {#data-retention}
+## Conservazione dei dati {#data-retention}
-Per conservare i dati, i sistemi devono avere qualche tipo di meccanismo per assicurarsi che i dati vengano conservati.
+Al fine di conservare i dati, i sistemi devono avere una sorta di meccanismo per assicurarsi che i dati vengano conservati.
-### Meccanismo di messa alla prova {#challenge-mechanism}
+### Meccanismo di sfida {#challenge-mechanism}
-Uno dei metodi più diffusi per verificare l'effettiva conservazione dei dati consiste nell'utilizzare qualche tipo di meccanismo di messa alla prova crittografica applicato ai nodi per accertare che contengano ancora i dati. Un esempio semplice è quello di verificare il proof-of-access di Arweave. I nodi vengono messi alla prova per vedere se contengono i dati sia sul blocco più recente sia su un blocco casuale in passato. Se il nodo non trova la risposta, viene penalizzato.
+Uno dei modi più popolari per assicurarsi che i dati vengano conservati è utilizzare un qualche tipo di sfida crittografica che viene inviata ai nodi per assicurarsi che abbiano ancora i dati. Un esempio semplice è la prova di accesso (proof-of-access) di Arweave. Emettono una sfida ai nodi per vedere se hanno i dati sia nel blocco più recente che in un blocco casuale nel passato. Se il nodo non riesce a fornire la risposta, viene penalizzato.
-Tipi di dStorage con meccanismo di messa alla prova:
+Tipi di dStorage con un meccanismo di sfida:
- Züs
- Skynet
- Arweave
- Filecoin
-- Rete Crust
+- Crust Network
- 4EVERLAND
-### Decentralità {#decentrality}
+### Decentralizzazione {#decentrality}
-Non esistono strumenti impeccabili per misurare il livello di decentralizzazione delle piattaforme ma, in generale, si tende a ricorrere a strumenti che non utilizzano qualche tipo di KYC per dimostrare di non essere centralizzati.
+Non ci sono ottimi strumenti per misurare il livello di decentralizzazione delle piattaforme, ma in generale, vorrai utilizzare strumenti che non abbiano alcuna forma di KYC per fornire prove che non siano centralizzati.
Strumenti decentralizzati senza KYC:
@@ -93,64 +93,64 @@ Strumenti decentralizzati senza KYC:
- Filecoin
- IPFS
- Ethereum
-- Rete Crust
+- Crust Network
- 4EVERLAND
### Consenso {#consensus}
-Gran parte di questi strumenti ha la propria versione di un [meccanismo di consenso](/developers/docs/consensus-mechanisms/), ma generalmente si basano su [**proof-of-work (PoW)**](/developers/docs/consensus-mechanisms/pow/) o [**proof-of-stake (PoS)**](/developers/docs/consensus-mechanisms/pos/).
+La maggior parte di questi strumenti ha la propria versione di un [meccanismo di consenso](/developers/docs/consensus-mechanisms/), ma generalmente si basano sulla [**prova di lavoro (PoW)**](/developers/docs/consensus-mechanisms/pow/) o sulla [**prova di stake (PoS)**](/developers/docs/consensus-mechanisms/pos/).
-Basata sul proof-of-work:
+Basati sulla prova di lavoro:
- Skynet
- Arweave
-Basata sul proof-of-stake:
+Basati sulla prova di stake:
- Ethereum
- Filecoin
- Züs
-- Rete Crust
+- Crust Network
## Strumenti correlati {#related-tools}
-**IPFS - _InterPlanetary File System è un sistema decentralizzato di archiviazione e referenziazione dei file per Ethereum._**
+**IPFS - _L'InterPlanetary File System è un sistema di archiviazione decentralizzata e di riferimento ai file per Ethereum._**
- [Ipfs.io](https://ipfs.io/)
- [Documentazione](https://docs.ipfs.io/)
- [GitHub](https://github.com/ipfs/ipfs)
-**Storj DCS - _Archiviazione decentralizzata di oggetti su cloud per sviluppatori, sicura, privata e compatibile con S3._**
+**Storj DCS - _Archiviazione di oggetti cloud decentralizzata sicura, privata e compatibile con S3 per sviluppatori._**
- [Storj.io](https://storj.io/)
- [Documentazione](https://docs.storj.io/)
- [GitHub](https://github.com/storj/storj)
-**Skynet - _Skynet è una catena di PoW decentralizzata dedicata a un web decentralizzato._**
+**Sia - _Sfrutta la crittografia per creare un mercato di archiviazione cloud trustless, consentendo ad acquirenti e venditori di effettuare transazioni direttamente._**
-- [Skynet.net](https://siasky.net/)
-- [Documentazione](https://siasky.net/docs/)
-- [GitHub](https://github.com/SkynetLabs/)
+- [Skynet.net](https://sia.tech/)
+- [Documentazione](https://docs.sia.tech/)
+- [GitHub](https://github.com/SiaFoundation/)
-**Filecoin - _Filecoin è stato creato dallo stesso team dietro a IPFS. È un livello d'incentivazione basato sui principi di IPFS._**
+**Filecoin - _Filecoin è stato creato dallo stesso team dietro IPFS. È un livello di incentivi basato sugli ideali di IPFS._**
- [Filecoin.io](https://filecoin.io/)
- [Documentazione](https://docs.filecoin.io/)
- [GitHub](https://github.com/filecoin-project/)
-**Arweave - _Arweave è una piattaforma di dStorage per l'archiviazione di dati._**
+**Arweave - _Arweave è una piattaforma dStorage per l'archiviazione dei dati._**
- [Arweave.org](https://www.arweave.org/)
- [Documentazione](https://docs.arweave.org/info/)
- [Arweave](https://github.com/ArweaveTeam/arweave/)
-**Züs - _Züs è una piattaforma di dStorage in proof-of-stake con sharding e blobber._**
+**Züs - _Züs è una piattaforma dStorage basata sulla prova di stake con frammentazione e blobber._**
- [zus.network](https://zus.network/)
-- [Documentazione](https://0chaindocs.gitbook.io/zus-docs)
+- [Documentazione](https://docs.zus.network/zus-docs/)
- [GitHub](https://github.com/0chain/)
-**Rete Crust: _Crust è una piattaforma di dStorage basata su IPFS._**
+**Crust Network - _Crust è una piattaforma dStorage basata su IPFS._**
- [Crust.network](https://crust.network)
- [Documentazione](https://wiki.crust.network)
@@ -159,7 +159,7 @@ Basata sul proof-of-stake:
**Swarm - _Una piattaforma di archiviazione distribuita e un servizio di distribuzione di contenuti per lo stack web3 di Ethereum._**
- [EthSwarm.org](https://www.ethswarm.org/)
-- [Documentazione](https://docs.ethswarm.org/docs/)
+- [Documentazione](https://docs.ethswarm.org/)
- [GitHub](https://github.com/ethersphere/)
**OrbitDB - _Un database peer-to-peer decentralizzato basato su IPFS._**
@@ -168,37 +168,37 @@ Basata sul proof-of-stake:
- [Documentazione](https://github.com/orbitdb/field-manual/)
- [GitHub](https://github.com/orbitdb/orbit-db/)
-**Aleph.im - _Progetto decentralizzato su cloud (database, archiviazione di file, calcolo e DID). Una combinazione unica di tecnologia peer-to-peer on-chain e off-chain. Compatibilità multi-catena e IPFS._**
+**Aleph.im - _Progetto cloud decentralizzato (database, archiviazione di file, calcolo e DID). Una miscela unica di tecnologia peer-to-peer fuori catena e on-chain. Compatibilità con IPFS e multi-chain._**
-- [Aleph.im](https://aleph.im/)
-- [Documentazione](https://aleph.im/#/developers/)
+- [Aleph.im](https://aleph.cloud/)
+- [Documentazione](https://docs.aleph.cloud/)
- [GitHub](https://github.com/aleph-im/)
-**Ceramic - _Archiviazione di database IPFS controllata dall'utente per applicazioni impegnative e ricche di dati._**
+**Ceramic - _Archiviazione di database IPFS controllata dall'utente per applicazioni ricche di dati e coinvolgenti._**
- [Ceramic.network](https://ceramic.network/)
-- [Documentazione](https://developers.ceramic.network/learn/welcome/)
+- [Documentazione](https://developers.ceramic.network/)
- [GitHub](https://github.com/ceramicnetwork/js-ceramic/)
-**Filebase - _archiviazione decentralizzata compatibile con S3 e servizio di pinning IPFS geo-ridondante. Tutti i file caricati in IPFS tramite Filebase sono fissati automaticamente all'infrastruttura di Filebase con replicazione 3x in tutto il globo._**
+**Filebase - _Archiviazione decentralizzata compatibile con S3 e servizio di pinning IPFS geo-ridondante. Tutti i file caricati su IPFS tramite Filebase vengono automaticamente fissati (pinned) all'infrastruttura Filebase con una replica 3x in tutto il mondo._**
- [Filebase.com](https://filebase.com/)
- [Documentazione](https://docs.filebase.com/)
- [GitHub](https://github.com/filebase)
-**4EVERLAND: _Una piattaforma di cloud computing in Web 3.0 che integra archiviazione, calcolo e capacità essenziali di rete, è compatibile con S3 e fornisce l'archiviazione sincrona dei dati su reti di archiviazione decentralizzate quali IPFS e Arweave._**
+**4EVERLAND - _Una piattaforma di cloud computing Web 3.0 che integra funzionalità principali di archiviazione, calcolo e rete, è compatibile con S3 e fornisce archiviazione dati sincrona su reti di archiviazione decentralizzata come IPFS e Arweave._**
- [4everland.org](https://www.4everland.org/)
- [Documentazione](https://docs.4everland.org/)
- [GitHub](https://github.com/4everland)
-**Kaleido - _Una piattaforma di blockchain-as-a-service con Nodi IPFS alla pressione di un pulsante_**
+**Kaleido - _Una piattaforma blockchain-as-a-service con nodi IPFS attivabili con un clic_**
- [Kaleido](https://kaleido.io/)
- [Documentazione](https://docs.kaleido.io/kaleido-services/ipfs/)
- [GitHub](https://github.com/kaleido-io)
-**Spheron Network - _Spheron è una platform-as-a-service (PaaS) progettata per le dApp che desiderano lanciare le proprie applicazioni su infrastrutture decentralizzate con le migliori prestazioni. Fornisce calcolo, archiviazione decentralizzata, CDN e hosting web pronti all'uso._**
+**Spheron Network - _Spheron è una platform-as-a-service (PaaS) progettata per le dApp che desiderano lanciare le proprie applicazioni su un'infrastruttura decentralizzata con le migliori prestazioni. Fornisce calcolo, archiviazione decentralizzata, CDN e web hosting pronti all'uso._**
- [spheron.network](https://spheron.network/)
- [Documentazione](https://docs.spheron.network/)
@@ -206,11 +206,11 @@ Basata sul proof-of-stake:
## Letture consigliate {#further-reading}
-- [Cos'è l'archiviazione decentralizzata?](https://coinmarketcap.com/alexandria/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_
-- [Sfatiamo cinque falsi miti sull'archiviazione decentralizzata](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_
+- [Cos'è l'archiviazione decentralizzata?](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) - _CoinMarketCap_
+- [Sfatare cinque miti comuni sull'archiviazione decentralizzata](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) - _Storj_
-_Conosci una risorsa pubblica che ti è stata utile? Modifica questa pagina e aggiungila!_
+_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
## Argomenti correlati {#related-topics}
-- [Quadri di sviluppo](/developers/docs/frameworks/)
+- [Framework di sviluppo](/developers/docs/frameworks/)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/docs/transactions/index.md b/public/content/translations/it/developers/docs/transactions/index.md
index 0a3ede82e33..567b38c03d4 100644
--- a/public/content/translations/it/developers/docs/transactions/index.md
+++ b/public/content/translations/it/developers/docs/transactions/index.md
@@ -1,56 +1,57 @@
---
title: Transazioni
-description: 'Panoramica sulle transazioni Ethereum: come funzionano, struttura dati e come inviarle tramite un''applicazione.'
+description: "Una panoramica delle transazioni di Ethereum: come funzionano, la loro struttura dei dati e come inviarle tramite un'applicazione."
lang: it
---
-Le transazioni sono istruzioni firmate crittograficamente dai conti. Un conto avvierà una transazione per aggiornare lo stato della rete di Ethereum. La transazione più semplice è il trasferimento di ETH da un conto all'altro.
+Le transazioni sono istruzioni firmate crittograficamente dagli account. Un account avvierà una transazione per aggiornare lo stato della rete [Ethereum](/). La transazione più semplice è il trasferimento di ETH da un account a un altro.
## Prerequisiti {#prerequisites}
-Per aiutarti a comprendere meglio questa pagina, ti consigliamo di leggere, innanzitutto, sui [Conti](/developers/docs/accounts/) e la nostra [introduzione a Ethereum](/developers/docs/intro-to-ethereum/).
+Per aiutarti a comprendere meglio questa pagina, ti consigliamo di leggere prima [Account](/developers/docs/accounts/) e la nostra [introduzione a Ethereum](/developers/docs/intro-to-ethereum/).
## Cos'è una transazione? {#whats-a-transaction}
-Una transazione di Ethereum si riferisce a un'azione avviata da un conto esterno, in altre parole, da un conto gestito da un umano, non da un contratto. Ad esempio, se Bob invia 1 ETH ad Alice, il conto di Bob sarà addebitato e quello di Alice sarà accreditato. Questa azione che modifica lo stato avviene all'interno di una transazione.
+Una transazione di Ethereum si riferisce a un'azione avviata da un account controllato esternamente, in altre parole un account gestito da un essere umano, non da un contratto. Ad esempio, se Bob invia ad Alice 1 ETH, l'account di Bob deve essere addebitato e quello di Alice accreditato. Questa azione di modifica dello stato avviene all'interno di una transazione.
- _Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-Le transazioni, che cambiano lo stato dell'EVM, devono essere trasmesse all'intera rete. Ogni nodo può trasmettere una richiesta di esecuzione di una transazione sull'EVM; in seguito, un validatore eseguirà la transazione e propagherà il cambiamento di stato risultante al resto della rete.
+Le transazioni, che cambiano lo stato della macchina virtuale di Ethereum (EVM), devono essere trasmesse all'intera rete. Qualsiasi nodo può trasmettere una richiesta affinché una transazione venga eseguita sull'EVM; dopo che ciò accade, un validatore eseguirà la transazione e propagherà il cambiamento di stato risultante al resto della rete.
-Le transazioni richiedono una commissione e devono essere incluse in un blocco validato. Per semplificare questa spiegazione, parleremo in altra sede di commissioni e di convalida.
+Le transazioni richiedono una commissione e devono essere incluse in un blocco convalidato. Per rendere questa panoramica più semplice, tratteremo le commissioni del gas e la convalida altrove.
-Una transazione inviata contiene le seguenti informazioni:
+Una transazione inviata include le seguenti informazioni:
-- `from` – indirizzo del mittente che firmerà la transazione. Questo sarà un conto posseduto esternamente, in quanto i conti contratto non possono inviare transazioni
-- `to`: l'indirizzo del destinatario (se è un conto posseduto esternamente, la transazione trasferirà il valore. Se è un conto di contratto, la transazione eseguirà il codice del contratto)
-- `signature` – l'identificativo del mittente. Viene generata quando la chiave privata del mittente firma la transazione e conferma che il mittente ha autorizzato la transazione
-- `nonce` – un contatore con incremento sequenziale, che indica il numero della transazione dal conto
-- `value` – quantità di ETH da trasferire dal mittente al destinatario (denominata in WEI, dove 1 ETH corrisponde a 1e+18wei)
-- `input data` - campo facoltativo per includere dati arbitrari
-- `gasLimit` – importo massimo di unità di carburante che possono essere consumate dalla transazione. L'[EVM](/developers/docs/evm/opcodes) specifica le unità di gas necessarie per ogni passaggio di calcolo
-- `maxPriorityFeePerGas` – il prezzo massimo del carburante consumato da includere come mancia al validatore
-- `maxFeePerGas` – la commissione massima per unità di carburante che si desidera pagare per la transazione (che include `baseFeePerGas` e `maxPriorityFeePerGas`)
+- `from` – l'indirizzo del mittente, che firmerà la transazione. Questo sarà un account controllato esternamente poiché gli account dei contratti non possono inviare transazioni
+- `to` – l'indirizzo di ricezione (se è un account controllato esternamente, la transazione trasferirà valore. Se è un account di un contratto, la transazione eseguirà il codice del contratto)
+- `signature` – l'identificatore del mittente. Questo viene generato quando la chiave privata del mittente firma la transazione e conferma che il mittente ha autorizzato questa transazione
+- `nonce` - un contatore che si incrementa in modo sequenziale e indica il numero della transazione dall'account
+- `value` – la quantità di ETH da trasferire dal mittente al destinatario (denominata in WEI, dove 1 ETH equivale a 1e+18 wei)
+- `input data` – campo opzionale per includere dati arbitrari
+- `gasLimit` – la quantità massima di unità di gas che possono essere consumate dalla transazione. L'[EVM](/developers/docs/evm/opcodes) specifica le unità di gas richieste da ogni passaggio computazionale
+- `maxPriorityFeePerGas` - il prezzo massimo del gas consumato da includere come mancia per il validatore
+- `maxFeePerGas` - la commissione massima per unità di gas che si è disposti a pagare per la transazione (comprensiva di `baseFeePerGas` e `maxPriorityFeePerGas`)
-Il gas è un riferimento al calcolo necessario perché un validatore elabori la transazione. Gli utenti devono pagare una commissione per questo calcolo. Il `gasLimit` e il `maxPriorityFeePerGas` determinano la commissione massima sulla transazione pagata al validatore. [Di più sul Gas](/developers/docs/gas/).
+Il gas è un riferimento al calcolo richiesto per elaborare la transazione da parte di un validatore. Gli utenti devono pagare una commissione per questo calcolo. Il `gasLimit` e la `maxPriorityFeePerGas` determinano la commissione della transazione massima pagata al validatore. [Maggiori informazioni sul Gas](/developers/docs/gas/).
-L'oggetto della transazione sarà qualcosa del genere:
+L'oggetto della transazione avrà un aspetto simile a questo:
```js
{
from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
gasLimit: "21000",
- maxFeePerGas: "300"
- maxPriorityFeePerGas: "10"
+ maxFeePerGas: "300",
+ maxPriorityFeePerGas: "10",
nonce: "0",
- value: "10000000000",
+ value: "10000000000"
}
```
-Ma l'oggetto di una transazione deve essere firmato utilizzando la chiave privata del mittente. Questo prova che la transazione è stata originata solo dal mittente e non è stata inviata in modo fraudolento.
+Ma un oggetto della transazione deve essere firmato utilizzando la chiave privata del mittente. Questo dimostra che la transazione può provenire solo dal mittente e non è stata inviata in modo fraudolento.
-Un client Ethereum come Geth gestirà il processo di firma.
+Un client di Ethereum come Geth gestirà questo processo di firma.
Esempio di chiamata [JSON-RPC](/developers/docs/apis/json-rpc):
@@ -99,22 +100,26 @@ Esempio di risposta:
}
```
-- `raw` è la transazione firmata nella forma codificata [prefisso di lunghezza ricorsiva (RLP)](/developers/docs/data-structures-and-encoding/rlp)
+- `raw` è la transazione firmata in forma codificata [Recursive Length Prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp)
- `tx` è la transazione firmata in formato JSON
-Con l'hash di firma, la transazione può provare crittograficamente che proviene dal mittente ed è stata inviata alla rete.
+Con l'hash della firma, si può dimostrare crittograficamente che la transazione proviene dal mittente ed è stata inviata alla rete.
-### Il campo di dati {#the-data-field}
+### Il campo 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 stragrande maggioranza delle transazioni accede a un contratto da un account controllato esternamente.
+La maggior parte dei contratti è scritta in Solidity e interpreta il proprio campo dati in conformità con l'[interfaccia binaria dell'applicazione (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/).
+I primi quattro byte specificano quale funzione chiamare, utilizzando l'hash del nome della funzione e dei suoi argomenti.
+A volte puoi identificare la funzione dal selettore utilizzando [questo database](https://www.4byte.directory/signatures/).
Il resto dei calldata sono gli argomenti, [codificati come specificato nelle specifiche dell'ABI](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding).
-Ad esempio, diamo un'occhiata a [questa transazione](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1). Usa **Clicca per scoprire di più** per visualizzare i calldata.
+Ad esempio, diamo un'occhiata a [questa transazione](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1).
+Usa **Click to see More** per vedere i calldata.
-Il selettore della funzione è `0xa9059cbb`. Ci sono diverse [funzioni note con questa firma](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb). In questo caso, [il codice sorgente del contratto](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) è stato caricato su Etherscan, quindi sappiamo che la funzione è `transfer(address,uint256)`.
+Il selettore della funzione è `0xa9059cbb`. Ci sono diverse [funzioni note con questa firma](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb).
+In questo caso [il codice sorgente del contratto](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) è stato caricato su Etherscan, quindi sappiamo che la funzione è `transfer(address,uint256)`.
Il resto dei dati è:
@@ -123,21 +128,23 @@ Il resto dei dati è:
000000000000000000000000000000000000000000000000000000003b0559f4
```
-Secondo le specifiche ABI, i valori interi (come gli indirizzi, che sono interi da 20 byte), appaiono nell'ABI come words a 32 byte, con riempimento di zeri nella parte anteriore. Quindi sappiamo che l'indirizzo `to` è [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279). Il `value` è 0x3b0559f4 = 990206452.
+Secondo le specifiche dell'ABI, i valori interi (come gli indirizzi, che sono interi a 20 byte) appaiono nell'ABI come parole a 32 byte, riempite con zeri all'inizio.
+Quindi sappiamo che l'indirizzo `to` è [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279).
+Il `value` è 0x3b0559f4 = 990206452.
## Tipi di transazioni {#types-of-transactions}
-Su Ethereum esistono diversi tipi di transazioni:
+Su Ethereum ci sono alcuni tipi diversi di transazioni:
-- Transazioni regolari: una transazione da un conto a un altro.
-- Transazioni di distribuzione del contratto: una transazione senza un indirizzo 'to', in cui il campo dei dati è usato per il codice del contratto.
-- Esecuzione di un contratto: una transazione che interagisce con un contratto intelligente distribuito. In questo caso, l'indirizzo 'a' è l'indirizzo del contratto intelligente.
+- Transazioni regolari: una transazione da un account a un altro.
+- Transazioni di distribuzione del contratto: una transazione senza un indirizzo 'to', in cui il campo dati viene utilizzato per il codice del contratto.
+- Esecuzione di un contratto: una transazione che interagisce con un contratto intelligente distribuito. In questo caso, l'indirizzo 'to' è l'indirizzo del contratto intelligente.
### Sul gas {#on-gas}
-Come accennato, le transazioni hanno un costo di [gas](/developers/docs/gas/) per essere eseguite. Semplici transazioni di trasferimento richiedono 21.000 unità di Gas.
+Come accennato, l'esecuzione delle transazioni costa [gas](/developers/docs/gas/). Le transazioni di trasferimento semplici richiedono 21000 unità di Gas.
-Quindi, perché Bob possa inviare 1 ETH ad Alice a una `baseFeePerGas` di 190 gwei e una `maxPriorityFeePerGas` di 10 gwei, Bob dovrà pagare la seguente commissione:
+Quindi, affinché Bob invii ad Alice 1 ETH a una `baseFeePerGas` di 190 gwei e una `maxPriorityFeePerGas` di 10 gwei, Bob dovrà pagare la seguente commissione:
```
(190 + 10) * 21000 = 4,200,000 gwei
@@ -145,68 +152,72 @@ Quindi, perché Bob possa inviare 1 ETH ad Alice a una `baseFeePerGas` di 190 gw
0.0042 ETH
```
-Sul conto di Bob sarà addebitato **-1,0042 ETH** (1 ETH per Alice + 0,0042 ETH di commissioni del gas)
+L'account di Bob verrà addebitato di **-1,0042 ETH** (1 ETH per Alice + 0,0042 ETH in commissioni del gas)
-Il conto di Alice sarà accreditato di **+1,0 ETH**
+L'account di Alice verrà accreditato di **+1,0 ETH**
-La commissione base brucerà **-0,00399 ETH**
+La commissione di base verrà bruciata **-0,00399 ETH**
-Il validatore riceve la mancia di **oltre 0,000210 ETH**
+Il validatore trattiene la mancia **+0,000210 ETH**
- _Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
+
+_Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_
-Il gas non utilizzato, viene rimborsato al conto dell'utente.
+Qualsiasi gas non utilizzato in una transazione viene rimborsato all'account dell'utente.
### Interazioni con i contratti intelligenti {#smart-contract-interactions}
-Il gas è necessario per qualsiasi transazione riguardi un contratto intelligente.
+Il gas è richiesto per qualsiasi transazione che coinvolga un contratto intelligente.
-Inoltre, i contratti intelligenti possono contenere delle funzioni note come [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) o [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions), che non alterano lo stato del contratto. Per questo, chiamare tali funzioni da un EOA non richiederà alcun gas. La chiamata RPC sottostante per questo scenario è [`eth_call`](/developers/docs/apis/json-rpc#eth_call).
+I contratti intelligenti possono anche contenere funzioni note come funzioni [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) o [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions), che non alterano lo stato del contratto. Pertanto, chiamare queste funzioni da un account controllato esternamente (EOA) non richiederà alcun gas. La chiamata RPC sottostante per questo scenario è [`eth_call`](/developers/docs/apis/json-rpc#eth_call).
-A differenza di quando si accede utilizzando `eth_call`, queste funzioni `view` o `pure` sono comunemente chiamate anche internamente (cioè dal contratto stesso o da un altro contratto) e questo costa gas.
+A differenza di quando vi si accede utilizzando `eth_call`, queste funzioni `view` o `pure` sono anche comunemente chiamate internamente (cioè, dal contratto stesso o da un altro contratto), il che costa gas.
-## Ciclo di vita delle transazioni {#transaction-lifecycle}
+## Ciclo di vita della transazione {#transaction-lifecycle}
-Una volta inviata una transazione, succede quanto segue:
+Una volta inviata la transazione, accade quanto segue:
-1. Un hash della transazione è stato generato crittograficamente: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017`
-2. La transazione è quindi trasmessa alla rete e aggiunta a un pool di transazione consistente in tutte le altre transazioni in sospeso della rete.
-3. Un validatore deve scegliere la transazione e includerla in un blocco per verificarla e considerarla "riuscita".
-4. Col passare del tempo, il blocco contenente la tua transazione sarà aggiornato a "giustificato", poi "finalizzato". Questi aggiornamenti rendono molto più certo che la transazione sia "riuscita" e che non sarà mai alterata. Una volta che un blocco è "finalizzato", l'unica cosa che potrebbe cambiarlo è un attacco a livello della rete che costerebbe molti miliardi di dollari.
+1. Viene generato crittograficamente un hash della transazione:
+ `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017`
+2. La transazione viene quindi trasmessa alla rete e aggiunta a un pool di transazioni costituito da tutte le altre transazioni di rete in sospeso.
+3. Un validatore deve prelevare la tua transazione e includerla in un blocco per verificare la transazione e considerarla "riuscita".
+4. Col passare del tempo, il blocco contenente la tua transazione verrà aggiornato a "giustificato" e poi a "finalizzato". Questi aggiornamenti rendono molto più certo che la tua transazione sia andata a buon fine e non verrà mai alterata. Una volta che un blocco è "finalizzato", potrebbe essere modificato solo da un attacco a livello di rete che costerebbe molti miliardi di dollari.
-## Dimostrazione visiva {#a-visual-demo}
+## Una demo visiva {#a-visual-demo}
-Guarda Austin mentre ti illustra transazioni, gas e mining.
+Guarda Austin che ti guida attraverso le transazioni, il gas e il mining.
Nota: Ethereum fa uso regolare delle funzioni di hash per produrre valori di dimensioni fisse ("hash"). Gli hash giocano un ruolo importante in Ethereum, ma per il momento puoi tranquillamente vederli come ID unici.
+Nota: Ethereum fa un uso regolare di funzioni di hash per produrre valori di dimensione fissa ("hash"). Gli hash svolgono un ruolo importante in Ethereum, ma per ora puoi tranquillamente pensarli come ID univoci.
-
+
-_Una blockchain è fondamentalmente un elenco collegato; ogni blocco si riferisce al precedente._
+_Una blockchain è essenzialmente una lista concatenata; ogni blocco ha un riferimento al blocco precedente._
-Questa struttura di dati non è nulla di nuovo, ma le regole (ovvero i protocolli peer-to-peer) che governano la rete lo sono. Non esiste alcuna autorità centrale; la rete di pari deve collaborare per sostenere la rete e competere per decidere quali transazioni includere nel blocco successivo. Quindi, se desideri inviare denaro a un amico, dovrai trasmettere la transazione alla rete, quindi attendere che venga inclusa in un blocco successivo.
+Questa struttura dati non è una novità, ma le regole (ovvero i protocolli peer-to-peer) che governano la rete lo sono. Non c'è un'autorità centrale; la rete di peer deve collaborare per sostenere la rete e competere per decidere quali transazioni includere nel blocco successivo. Quindi, quando vuoi inviare del denaro a un amico, dovrai trasmettere quella transazione alla rete, per poi aspettare che venga inclusa in un blocco imminente.
-L'unico modo per la blockchain di verificare che il denaro sia realmente inviato da un utente all'altro è usare una valuta nativa a quella blockchain (es., creata e governata da essa). In Ethereum, questa valuta è detta ether e la blockchain di Ethereum contiene solo il registro ufficiale dei saldi dei conti.
+L'unico modo per la blockchain di verificare che il denaro sia stato veramente inviato da un utente all'altro è utilizzare una valuta nativa (cioè creata e governata da) quella blockchain. In Ethereum, questa valuta si chiama ether e la blockchain di Ethereum contiene l'unico registro ufficiale dei saldi degli account.
## Un nuovo paradigma {#a-new-paradigm}
-Questa nuova tecnologia decentralizzata ha generato nuovi strumenti per sviluppatori. Questi esistono in molti linguaggi di programmazione, ma per il momento guarderemo attraverso la lente di Python. Per ribadire: anche se Python non è il tuo linguaggio preferito, non dovrebbe esser troppo difficile proseguire.
+Questo nuovo stack tecnologico decentralizzato ha generato nuovi strumenti per sviluppatori. Tali strumenti esistono in molti linguaggi di programmazione, ma noi li guarderemo attraverso la lente di Python. Per ribadire: anche se Python non è il tuo linguaggio preferito, non dovrebbe essere un grosso problema seguire.
-Gli sviluppatori di Python che desiderano interagire con Ethereum, probabilmente sceglieranno [Web3.py](https://web3py.readthedocs.io/). Web3.py è una libreria che semplifica notevolmente la connessione a un nodo di Ethereum e l'invio e la ricezione di dati da esso.
+Gli sviluppatori Python che vogliono interagire con Ethereum probabilmente ricorreranno a [Web3.py](https://web3py.readthedocs.io/). Web3.py è una libreria che semplifica notevolmente il modo in cui ti connetti a un nodo Ethereum, per poi inviare e ricevere dati da esso.
-Nota: "nodo di Ethereum" e "client di Ethereum" sono usati in modo intercambiabile. Ad ogni modo, ci riferiamo al software eseguito da un partecipante alla rete di Ethereum. Questo software può leggere i dati del blocco, ricevere aggiornamenti quando i nuovi blocchi sono aggiunti alla catena, trasmettere le nuove transazioni e tanto altro. Tecnicamente, il client è il software, il nodo è il computer che esegue il software.
+Nota: "nodo Ethereum" e "client Ethereum" sono usati in modo intercambiabile. In entrambi i casi, si riferiscono al software eseguito da un partecipante alla rete Ethereum. Questo software può leggere i dati dei blocchi, ricevere aggiornamenti quando nuovi blocchi vengono aggiunti alla catena, trasmettere nuove transazioni e altro ancora. Tecnicamente, il client è il software, il nodo è il computer che esegue il software.
-I [client di Ethereum](/developers/docs/nodes-and-clients/) sono configurabili per esser raggiungibili da [IPC](https://wikipedia.org/wiki/Inter-process_communication), HTTP, o Websocket, quindi Web3.py dovrà rispecchiare tale configurazione. Web3.py si riferisce a queste opzioni di connessione come **provider**. Occorre scegliere uno dei tre provider per collegare l'istanza di Web3.py al tuo nodo.
+I [client Ethereum](/developers/docs/nodes-and-clients/) possono essere configurati per essere raggiungibili tramite [IPC](https://wikipedia.org/wiki/Inter-process_communication), HTTP o Websocket, quindi Web3.py dovrà rispecchiare questa configurazione. Web3.py si riferisce a queste opzioni di connessione come **provider**. Dovrai scegliere uno dei tre provider per collegare l'istanza di Web3.py al tuo nodo.
-
+
-_Configura il nodo di Ethereum e Web3.py per comunicare tramite lo stesso protocollo, ad es. IPC in questo diagramma._
+_Configura il nodo Ethereum e Web3.py per comunicare tramite lo stesso protocollo, ad es. IPC in questo diagramma._
-Una volta configurato correttamente Web3.py, puoi iniziare a interagire con la blockchain. Ecco un paio di esempi di utilizzo di Web3.py come anticipazione di ciò che vedremo tra poco:
+Una volta che Web3.py è configurato correttamente, puoi iniziare a interagire con la blockchain. Ecco un paio di esempi di utilizzo di Web3.py come anteprima di ciò che verrà:
```python
-# read block data:
+# leggi i dati del blocco:
w3.eth.get_block('latest')
-# send a transaction:
+# invia una transazione:
w3.eth.send_transaction({'from': ..., 'to': ..., 'value': ...})
```
## Installazione {#installation}
-In questa guida, lavoreremo solo all'interno di un interprete Python. Non creeremo cartelle, file, classi o funzioni.
+In questa guida, lavoreremo solo all'interno di un interprete Python. Non creeremo directory, file, classi o funzioni.
-Nota: Negli esempi seguenti, i comandi che iniziano con "$" sono intesi come da eseguire nel terminale. (Non occorre digitare "$", indica solo l'inizio della riga.)
+Nota: Negli esempi seguenti, i comandi che iniziano con `$` sono destinati a essere eseguiti nel terminale. (Non digitare il `$`, indica solo l'inizio della riga.)
-Innanzi tutto, installa [IPython](https://ipython.org/) per un ambiente user-friendly da esplorare. IPython offre il completamento delle schede, tra le altre funzionalità, facilitando notevolmente la visualizzazione di cosa è possibile in Web3.py.
+Per prima cosa, installa [IPython](https://ipython.org/) per avere un ambiente user-friendly in cui esplorare. IPython offre il completamento con il tasto Tab, tra le altre funzionalità, rendendo molto più facile vedere cosa è possibile fare all'interno di Web3.py.
```bash
pip install ipython
```
-Web3.py è pubblicato sotto il nome `web3`. Installalo come segue:
+Web3.py è pubblicato con il nome `web3`. Installalo in questo modo:
```bash
pip install web3
```
-Un'altra cosa: più avanti simuleremo una blockchain, il che richiede un paio di altre dipendenze. Puoi installarle tramite:
+Un'ultima cosa: più tardi simuleremo una blockchain, il che richiede un paio di dipendenze in più. Puoi installarle tramite:
```bash
pip install 'web3[tester]'
```
-È tutto pronto per iniziare!
+Sei pronto per iniziare!
-Nota: il pacchetto `web3[tester]` funziona fino a Python 3.10.xx.
+Nota: Il pacchetto `web3[tester]` funziona fino a Python 3.10.xx
-## Aprire un sandbox {#spin-up-a-sandbox}
+## Avviare una sandbox {#spin-up-a-sandbox}
-Apri un nuovo ambiente di Python eseguendo `ipyton` nel tuo terminale. Ciò è comparabile ad eseguire `python`, ma con qualche fronzolo in più.
+Apri un nuovo ambiente Python eseguendo `ipython` nel tuo terminale. Questo è paragonabile all'esecuzione di `python`, ma è dotato di più funzionalità.
```bash
ipython
```
-Questo produrrà una serie di informazioni sulle versioni di Python e IPython in uso, poi dovresti vedere una richiesta d'inserimento in attesa:
+Questo stamperà alcune informazioni sulle versioni di Python e IPython che stai eseguendo, dopodiché dovresti vedere un prompt in attesa di input:
```python
In [1]:
```
-Ciò che vedi ora è una shell interattiva di Python. In sostanza, è un recinto di sabbia in cui giocare. Se sei arrivato fin qui, è il momento di importare Web3.py:
+Ora stai guardando una shell Python interattiva. Essenzialmente, è una sandbox in cui giocare. Se sei arrivato fin qui, è il momento di importare Web3.py:
```python
In [1]: from web3 import Web3
@@ -126,22 +125,22 @@ In [1]: from web3 import Web3
## Introduzione al modulo Web3 {#introducing-the-web3-module}
-Oltre all'essere un gateway per Ethereum, il modulo [Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api) offre alcune funzioni comode. Esploriamone alcune.
+Oltre a essere un gateway per Ethereum, il modulo [Web3](https://web3py.readthedocs.io/en/stable/overview.html#base-api) offre alcune funzioni di utilità. Esploriamone un paio.
-In un'applicazione di Ethereum, normalmente occorre convertire le denominazioni delle valute. Il modulo Web3 fornisce un paio di metodi di supporto appositamente per questo: [from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei) e [to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei).
+In un'applicazione Ethereum, avrai comunemente bisogno di convertire le denominazioni di valuta. Il modulo Web3 fornisce un paio di metodi di supporto proprio per questo: [from_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.from_wei) e [to_wei](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_wei).
-Nota: I computer sono notoriamente inefficaci nella gestione della matematica decimale. Per aggirare ciò, gli sviluppatori archiviano spesso importi di dollari in centesimi. Per esempio, un oggetto con un prezzo di $5,99 potrebbe esser memorizzato nel database come 599.
+Nota: I computer sono notoriamente pessimi nel gestire la matematica decimale. Per aggirare questo problema, gli sviluppatori spesso memorizzano gli importi in dollari in centesimi. Ad esempio, un articolo con un prezzo di $5.99 potrebbe essere memorizzato nel database come 599.
-Uno schema simile è usato per gestire le transazioni in ether. Tuttavia, invece di due punti decimali, ether ne ha 18! La più piccola denominazione di ether è chiamata wei, ovvero il valore specificato inviando le transazioni.
+Un modello simile viene utilizzato quando si gestiscono transazioni in ether. Tuttavia, invece di due cifre decimali, l'ether ne ha 18! La denominazione più piccola di ether si chiama wei, quindi questo è il valore specificato quando si inviano transazioni.
1 ether = 1000000000000000000 wei
-1 wei = 0,000000000000000001 ether
+1 wei = 0.000000000000000001 ether
-Prova a convertire dei valori da e verso wei. Nota che [esistono nomi per molte delle denominazioni](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations) tra ether e wei. Una delle più note è **gwei**, spesso utilizzata per rappresentare le commissioni di transazione.
+Prova a convertire alcuni valori da e verso wei. Nota che [ci sono nomi per molte delle denominazioni](https://web3py.readthedocs.io/en/stable/troubleshooting.html#how-do-i-convert-currency-denominations) tra ether e wei. Una delle più note tra queste è il **gwei**, poiché è spesso il modo in cui vengono rappresentate le commissioni della transazione.
```python
In [2]: Web3.to_wei(1, 'ether')
@@ -151,49 +150,50 @@ In [3]: Web3.from_wei(500000000, 'gwei')
Out[3]: Decimal('0.5')
```
-Altri metodi d'utilità sul modulo Web3 includono i convertitori di formato dei dati (ad es. [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex)), helper di indirizzo (ad es. [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress)) e funzioni di hash (es., [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak)). Molti di questi saranno affrontati in seguito nella serie. Per visualizzare tutti i metodi e le proprietà disponibili, usa l'autocompilazione di Python digitando `Web3` e premi il tasto tab due volte dopo il punto.
+Altri metodi di utilità sul modulo Web3 includono convertitori di formato dati (ad es., [`toHex`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.toHex)), helper per gli indirizzi (ad es., [`isAddress`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.isAddress)) e funzioni di hash (ad es., [`keccak`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.keccak)). Molti di questi verranno trattati più avanti nella serie. Per visualizzare tutti i metodi e le proprietà disponibili, utilizza l'autocompletamento di IPython digitando `Web3.` e premendo due volte il tasto Tab dopo il punto.
-## Comunicare con la catena {#talk-to-the-chain}
+## Parlare con la catena {#talk-to-the-chain}
-I metodi di convenienza sono fantastici, ma passiamo alla blockchain. Il prossimo passaggio è configurare Web3.py per comunicare con un nodo di Ethereum. Qui abbiamo l'opzione di usare i provider IPC, HTTP o Websocket.
+I metodi di utilità sono adorabili, ma passiamo alla blockchain. Il passo successivo è configurare Web3.py per comunicare con un nodo Ethereum. Qui abbiamo l'opzione di utilizzare i provider IPC, HTTP o Websocket.
-Non percorreremo questo percorso, ma un esempio di flusso di lavoro completo usando il provider HTTP potrebbe apparire così:
+Non seguiremo questa strada, ma un esempio di flusso di lavoro completo utilizzando l'HTTP Provider potrebbe assomigliare a questo:
-- Scarica un nodo di Ethereum, ad es. [Geth](https://geth.ethereum.org/).
-- Avvia Geth in una finestra del terminale e attendi che si sincronizzi alla rete. La porta HTTP predefinita è `8545`, ma è configurabile.
-- Dì a Web3.py di connettersi al nodo tramite HTTP, su `localhost:8545`. `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))`
+- Scarica un nodo Ethereum, ad es. [Geth](https://geth.ethereum.org/).
+- Avvia Geth in una finestra del terminale e attendi che sincronizzi la rete. La porta HTTP predefinita è `8545`, ma è configurabile.
+- Dì a Web3.py di connettersi al nodo tramite HTTP, su `localhost:8545`.
+ `w3 = Web3(Web3.HTTPProvider('http://127.0.0.1:8545'))`
- Usa l'istanza `w3` per interagire con il nodo.
-Questo è uno dei modi "reali" per farlo, mentre il processo di sincronizzazione impiega ore e non è necessario se vuoi solo un ambiente di sviluppo. Web3.py espone un quarto provider per questo scopo, l'**EthereumTesterProvider**. Questo provider di prova si collega a un nodo simulato di Ethereum con autorizzazioni rilassate e valute false con cui giocare.
+Sebbene questo sia un modo "reale" per farlo, il processo di sincronizzazione richiede ore ed è inutile se desideri solo un ambiente di sviluppo. Web3.py espone un quarto provider per questo scopo, l'**EthereumTesterProvider**. Questo provider di test si collega a un nodo Ethereum simulato con permessi rilassati e valuta finta con cui giocare.
-
+
-_L'EthereumTesterProvider si connette a un nodo simulato ed è utile per gli ambienti di sviluppo rapido._
+_L'EthereumTesterProvider si connette a un nodo simulato ed è comodo per ambienti di sviluppo rapidi._
-Quel nodo simulato è detto [eth-tester](https://github.com/ethereum/eth-tester) e lo abbiamo installato come parte del comando `pip install web3[tester]`. Configurare Web3.py per usare questo provider di prova è semplicissimo:
+Quel nodo simulato si chiama [eth-tester](https://github.com/ethereum/eth-tester) e lo abbiamo installato come parte del comando `pip install web3[tester]`. Configurare Web3.py per utilizzare questo provider di test è semplice come:
```python
In [4]: w3 = Web3(Web3.EthereumTesterProvider())
```
-Ora sei pronto a navigare sulla catena! In realtà non si dice così, l'ho inventato io sul momento. Facciamo un rapido tour.
+Ora sei pronto per navigare sulla catena! Non è una cosa che si dice. Me la sono appena inventata. Facciamo un rapido tour.
## Il tour rapido {#the-quick-tour}
-Per prima cosa, un bel sanity check:
+Prima di tutto, un controllo di integrità:
```python
In [5]: w3.is_connected()
Out[5]: True
```
-Poiché stiamo usando il provider di prova, non è un test probante, ma se dovesse fallire, c'è la possibilità che tu abbia digitato qualcosa di sbagliato per avviare un'istanza della variabile `w3`. Ricontrolla di aver incluso le parentesi interne, ad es.`Web3.EthereumTesterProvider()`.
+Poiché stiamo utilizzando il provider di test, questo non è un test molto prezioso, ma se fallisce, è probabile che tu abbia digitato qualcosa di sbagliato durante l'istanziazione della variabile `w3`. Ricontrolla di aver incluso le parentesi interne, ovvero `Web3.EthereumTesterProvider()`.
-## Fermata #1 del tour: [conti](/developers/docs/accounts/) {#tour-stop-1-accounts}
+## Tappa del tour n. 1: [account](/developers/docs/accounts/) {#tour-stop-1-accounts}
-Per comodità, il fornitore di tester ha creato alcuni account e li ha precaricati con test ether.
+Per comodità, il provider di test ha creato alcuni account e li ha precaricati con ether di test.
-In primo luogo, vediamo un elenco di questi account:
+Per prima cosa, vediamo un elenco di quegli account:
```python
In [6]: w3.eth.accounts
@@ -202,27 +202,27 @@ Out[6]: ['0x7E5F4552091A69125d5DfCb7b8C2659029395Bdf',
'0x6813Eb9362372EEF6200f3b1dbC3f819671cBA69', ...]
```
-Se esegui questo comando, vedrai un elenco di dieci stringhe che iniziano per `0x`. Ciascuna di esse è un **indirizzo pubblico** ed è in qualche modo analoga al numero dell'account di verifica. Puoi fornire questo indirizzo a chiunque voglia inviarti ether.
+Se esegui questo comando, dovresti vedere un elenco di dieci stringhe che iniziano con `0x`. Ognuna è un **indirizzo pubblico** ed è, in qualche modo, analoga al numero di conto di un conto corrente. Forniresti questo indirizzo a qualcuno che volesse inviarti ether.
-Come accennato, il fornitore di tester ha precaricato ciascuno di questi account con qualche test ether. Scopriamo quanto c'è nel primo account:
+Come accennato, il provider di test ha precaricato ciascuno di questi account con alcuni ether di test. Scopriamo quanto c'è nel primo account:
```python
In [7]: w3.eth.get_balance(w3.eth.accounts[0])
Out[7]: 1000000000000000000000000
```
-Sono molti zeri! Prima di correre alla velocità della luce fino alla banca finta, ricordati la lezione di poco fa sulle denominazioni della valuta. I valori dell'ether sono rappresentati nella più piccola denominazione, ovvero il wei. Convertila in ether:
+Sono un sacco di zeri! Prima di andare a ridere fino alla finta banca, ricorda quella lezione sulle denominazioni di valuta di prima. I valori in ether sono rappresentati nella denominazione più piccola, i wei. Convertilo in ether:
```python
In [8]: w3.from_wei(1000000000000000000000000, 'ether')
Out[8]: Decimal('1000000')
```
-Un milione di ether di prova, comunque una cifra di tutto rispetto.
+Un milione di ether di test: non è affatto male.
-## Fermata del tour #2: dati del blocco {#tour-stop-2-block-data}
+## Tappa del tour n. 2: dati del blocco {#tour-stop-2-block-data}
-Diamo una sbirciatina allo stato di questa blockchain simulata:
+Diamo un'occhiata allo stato di questa blockchain simulata:
```python
In [9]: w3.eth.get_block('latest')
@@ -235,15 +235,15 @@ Out[9]: AttributeDict({
})
```
-Vengono restituite molte informazioni su un blocco, ma qui vale la pena di sottolineare solo un paio di cose:
+Vengono restituite molte informazioni su un blocco, ma ci sono solo un paio di cose da sottolineare qui:
-- Il numero del blocco è zero, non importa quanto tempo fa tu abbia configurato il provider di prova. A differenza della vera rete di Ethereum, che aggiunge un nuovo blocco ogni 12 secondi, questa simulazione attenderà finché non le darai qualcosa da fare.
-- `transactions` è un elenco vuoto, per lo stesso motivo: non abbiamo ancora fatto nulla. Questo primo blocco è un **blocco vuoto**, giusto per dare il via alla catena.
-- Nota che il `parentHash` è solo un mucchio di byte vuoti. Questo significa che è il primo blocco nella catena, anche noto come **blocco di genesi**.
+- Il numero del blocco è zero, indipendentemente da quanto tempo fa hai configurato il provider di test. A differenza della vera rete Ethereum, che aggiunge un nuovo blocco ogni 12 secondi, questa simulazione aspetterà finché non le darai del lavoro da fare.
+- `transactions` è un elenco vuoto, per lo stesso motivo: non abbiamo ancora fatto nulla. Questo primo blocco è un **blocco vuoto**, solo per dare il via alla catena.
+- Nota che il `parentHash` è solo un mucchio di byte vuoti. Questo significa che è il primo blocco della catena, noto anche come **blocco genesi**.
-## Fermata #3 del tour: [transazioni](/developers/docs/transactions/) {#tour-stop-3-transactions}
+## Tappa del tour n. 3: [transazioni](/developers/docs/transactions/) {#tour-stop-3-transactions}
-Siamo fermi al blocco zero finché non si verifica una transazione in sospeso, quindi diamogliene una. Invia qualche ether di prova da un account all'altro:
+Siamo bloccati al blocco zero finché non c'è una transazione in sospeso, quindi diamogliene una. Invia alcuni ether di test da un account all'altro:
```python
In [10]: tx_hash = w3.eth.send_transaction({
@@ -254,13 +254,16 @@ In [10]: tx_hash = w3.eth.send_transaction({
})
```
-Questo è tipicamente il punto in cui dovresti aspettare diversi secondi affinché la tua transazione sia inclusa in un nuovo blocco. L'intero processo va più o meno come indicato sotto:
+Questo è in genere il punto in cui aspetteresti diversi secondi affinché la tua transazione venga inclusa in un nuovo blocco. L'intero processo si svolge più o meno così:
-1. Invia una transazione e mantieni l'hash della transazione. Finché il blocco contenente la transazione non viene creato e trasmesso, la transazione è "in sospeso". `tx_hash = w3.eth.send_transaction({ … })`
-2. Attendi che la transazione sia inclusa in un blocco: `w3.eth.wait_for_transaction_receipt(tx_hash)`
-3. Prosegui la logica dell'applicazione. Per visualizzare la transazione riuscita: `w3.eth.get_transaction(tx_hash)`
+1. Invia una transazione e conserva l'hash della transazione. Finché il blocco contenente la transazione non viene creato e trasmesso, la transazione è "in sospeso".
+ `tx_hash = w3.eth.send_transaction({ … })`
+2. Attendi che la transazione venga inclusa in un blocco:
+ `w3.eth.wait_for_transaction_receipt(tx_hash)`
+3. Continua la logica dell'applicazione. Per visualizzare la transazione andata a buon fine:
+ `w3.eth.get_transaction(tx_hash)`
-Il nostro ambiente simulato aggiungerà la transazione in un nuovo blocco istantaneamente, quindi possiamo visualizzare immediatamente la transazione:
+Il nostro ambiente simulato aggiungerà la transazione in un nuovo blocco all'istante, in modo da poter visualizzare immediatamente la transazione:
```python
In [11]: w3.eth.get_transaction(tx_hash)
@@ -275,9 +278,9 @@ Out[11]: AttributeDict({
})
```
-Vedrai qualche dettaglio familiare qui: i campi `from`, `to` e `value` dovrebbero corrispondere alle immissioni della tua chiamata `send_transaction`. L'altra parte rassicurante è che questa transazione è stata inclusa come prima transazione (`'transactionIndex': 0`) nel blocco numero 1.
+Vedrai alcuni dettagli familiari qui: i campi `from`, `to` e `value` dovrebbero corrispondere agli input della nostra chiamata `send_transaction`. L'altro dettaglio rassicurante è che questa transazione è stata inclusa come prima transazione (`'transactionIndex': 0`) all'interno del blocco numero 1.
-Possiamo anche verificare facilmente il successo di questa transazione controllando i saldi dei due account coinvolti. Tre ether dovrebbero essersi spostati dal primo al secondo.
+Possiamo anche verificare facilmente il successo di questa transazione controllando i saldi dei due account coinvolti. Tre ether dovrebbero essersi spostati da uno all'altro.
```python
In [12]: w3.eth.get_balance(w3.eth.accounts[0])
@@ -287,12 +290,12 @@ In [13]: w3.eth.get_balance(w3.eth.accounts[1])
Out[13]: 1000003000000000000000000
```
-Quest'ultima parte sembra a posto! Il saldo è passato da 1.000.000 a 1.000.003 ether. Ma cosa è successo al primo account? Sembra aver perso lievemente di più di tre ether. Ahimè, niente nella vita è gratis e per usare la rete pubblica di Ethereum occorre compensare i tuoi pari per il loro ruolo di supporto. Una piccola commissione di transazione è stata detratta dall'account che ha inviato la transazione: si tratta dell'importo di gas bruciato (21000 unità di gas per un trasferimento di ETH), moltiplicato per una commissione di base che varia a seconda dell'attività della rete, più una mancia inviata al validatore che include la transazione in un blocco.
+Il secondo sembra a posto! Il saldo è passato da 1.000.000 a 1.000.003 ether. Ma cosa è successo al primo account? Sembra aver perso poco più di tre ether. Ahimè, niente nella vita è gratis e l'utilizzo della rete pubblica di Ethereum richiede di compensare i propri peer per il loro ruolo di supporto. Una piccola commissione della transazione è stata detratta dall'account che ha inviato la transazione: questa commissione è la quantità di gas bruciato (21000 unità di gas per un trasferimento di ETH) moltiplicata per una commissione di base che varia in base all'attività della rete più una mancia che va al validatore che include la transazione in un blocco.
Maggiori informazioni sul [gas](/developers/docs/gas/#post-london)
-Nota: Sulla rete pubblica, le commissioni di transazione sono variabili in base alla domanda della rete ella rapidità con cui vorresti che una transazione fosse elaborata. Se sei interessato a una ripartizione di come sono calcolate le commissioni, vedi il mio post precedente su come sono incluse le transazioni in un blocco.
+Nota: Sulla rete pubblica, le commissioni della transazione sono variabili in base alla domanda della rete e alla rapidità con cui desideri che una transazione venga elaborata. Se sei interessato a un'analisi dettagliata di come vengono calcolate le commissioni, consulta il mio post precedente su come le transazioni vengono incluse in un blocco.
## E respira {#and-breathe}
-Ci siamo soffermati su questo argomento per un po' di tempo, quindi sembra un buon momento per prendersi una pausa. L'argomento non è esaurito e continueremo a parlarne nella seconda parte di questa serie. Alcuni concetti che affronteremo: connettersi a un nodo reale, contratti intelligenti e token. Hai domande d'approfondimento? Fammelo sapere! Il tuo feedback influenzerà il contenuto della seconda parte. Le richieste sono benvenute tramite [Twitter](https://twitter.com/wolovim).
+Siamo stati su questo per un po', quindi questo sembra un buon posto come un altro per fare una pausa. La tana del bianconiglio continua e continueremo a esplorare nella seconda parte di questa serie. Alcuni concetti in arrivo: connessione a un nodo reale, contratti intelligenti e token. Hai domande di follow-up? Fammelo sapere! Il tuo feedback influenzerà la direzione che prenderemo da qui in poi. Le richieste sono benvenute tramite [Twitter](https://twitter.com/wolovim).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/ai-trading-agent/index.md b/public/content/translations/it/developers/tutorials/ai-trading-agent/index.md
index 44283b84a24..08026d536c6 100644
--- a/public/content/translations/it/developers/tutorials/ai-trading-agent/index.md
+++ b/public/content/translations/it/developers/tutorials/ai-trading-agent/index.md
@@ -1,39 +1,40 @@
---
title: Crea il tuo agente di trading IA su Ethereum
-description: In questa guida imparerai a creare un semplice agente di trading IA. Questo agente legge le informazioni dalla blockchain, chiede una raccomandazione a un LLM in base a tali informazioni, esegue lo scambio consigliato dall'LLM, quindi attende e ripete.
+description: In questo tutorial imparerai come creare un semplice agente di trading IA. Questo agente legge informazioni dalla blockchain, chiede a un LLM una raccomandazione basata su tali informazioni, esegue lo scambio raccomandato dall'LLM, quindi attende e ripete.
author: Ori Pomerantz
-tags: [ "IA", "trading", "agente", "python" ]
+tags: ["IA", "trading", "agente", "Python"]
skill: intermediate
+breadcrumb: Agente di trading IA
published: 2026-02-13
lang: it
sidebarDepth: 3
---
-In questa guida imparerai a creare un semplice agente di trading IA. Questo agente funziona seguendo questi passaggi:
+In questo tutorial imparerai come costruire un semplice agente di trading IA. Questo agente funziona seguendo questi passaggi:
-1. Leggere i prezzi attuali e passati di un token, nonché altre informazioni potenzialmente pertinenti
-2. Costruire una query con queste informazioni, insieme a informazioni di base per spiegare come potrebbero essere pertinenti
+1. Leggere i prezzi attuali e passati di un token, oltre ad altre informazioni potenzialmente rilevanti
+2. Costruire una query con queste informazioni, insieme a informazioni di base per spiegare come potrebbero essere rilevanti
3. Inviare la query e ricevere in risposta un prezzo previsto
-4. Effettuare uno scambio in base alla raccomandazione
+4. Fare trading in base alla raccomandazione
5. Attendere e ripetere
-Questo agente dimostra come leggere le informazioni, tradurle in una query che fornisce una risposta utilizzabile e utilizzare tale risposta. Tutti questi sono passaggi richiesti per un agente IA. Questo agente è implementato in Python perché è il linguaggio più comune utilizzato nell'IA.
+Questo agente dimostra come leggere informazioni, tradurle in una query che produce una risposta utilizzabile e utilizzare tale risposta. Tutti questi sono passaggi richiesti per un agente IA. Questo agente è implementato in Python perché è il linguaggio più comune utilizzato nell'IA.
## Perché farlo? {#why-do-this}
-Gli agenti di trading automatizzati consentono agli sviluppatori di selezionare ed eseguire una strategia di trading. Gli [agenti IA](/ai-agents) consentono strategie di trading più complesse e dinamiche, utilizzando potenzialmente informazioni e algoritmi che lo sviluppatore non ha nemmeno considerato di usare.
+Gli agenti di trading automatizzati consentono agli sviluppatori di selezionare ed eseguire una strategia di trading. Gli [agenti IA](/ai-agents) consentono strategie di trading più complesse e dinamiche, utilizzando potenzialmente informazioni e algoritmi che lo sviluppatore non ha nemmeno preso in considerazione.
## Gli strumenti {#tools}
-Questa guida utilizza [Python](https://www.python.org/), la [libreria Web3](https://web3py.readthedocs.io/en/stable/) e [Uniswap v3](https://github.com/Uniswap/v3-periphery) per quotazioni e trading.
+Questo tutorial utilizza [Python](https://www.python.org/), la [libreria Web3](https://web3py.readthedocs.io/en/stable/) e [Uniswap v3](https://github.com/Uniswap/v3-periphery) per le quotazioni e il trading.
### Perché Python? {#python}
-Il linguaggio più utilizzato per l'IA è [Python](https://www.python.org/), quindi lo usiamo qui. Non ti preoccupare se non conosci Python. Il linguaggio è molto chiaro e spiegherò esattamente cosa fa.
+Il linguaggio più utilizzato per l'IA è [Python](https://www.python.org/), quindi lo useremo qui. Non preoccuparti se non conosci Python. Il linguaggio è molto chiaro e spiegherò esattamente cosa fa.
-La [libreria Web3](https://web3py.readthedocs.io/en/stable/) è l'API Python di Ethereum più comune. È abbastanza facile da usare.
+La [libreria Web3](https://web3py.readthedocs.io/en/stable/) è l'API Ethereum per Python più comune. È piuttosto facile da usare.
-### Trading sulla blockchain {#trading-on-blockchain}
+### Fare trading sulla blockchain {#trading-on-blockchain}
Ci sono [molti exchange decentralizzati (DEX)](/apps/categories/defi/) che ti permettono di scambiare token su Ethereum. Tuttavia, tendono ad avere tassi di cambio simili a causa dell'[arbitraggio](/developers/docs/smart-contracts/composability/#better-user-experience).
@@ -41,44 +42,44 @@ Ci sono [molti exchange decentralizzati (DEX)](/apps/categories/defi/) che ti pe
### OpenAI {#openai}
-Per un modello linguistico di grandi dimensioni, ho scelto di iniziare con [OpenAI](https://openai.com/). Per eseguire l'applicazione in questa guida dovrai pagare per l'accesso all'API. Il pagamento minimo di 5$ è più che sufficiente.
+Per un modello linguistico di grandi dimensioni (LLM), ho scelto di iniziare con [OpenAI](https://openai.com/). Per eseguire l'applicazione in questo tutorial dovrai pagare per l'accesso all'API. Il pagamento minimo di 5$ è più che sufficiente.
## Sviluppo, passo dopo passo {#step-by-step}
-Per semplificare lo sviluppo, procediamo per fasi. Ogni passaggio è un branch in GitHub.
+Per semplificare lo sviluppo, procederemo per fasi. Ogni passaggio è un branch su GitHub.
### Per iniziare {#getting-started}
-Ci sono passaggi per iniziare con UNIX o Linux (incluso [WSL](https://learn.microsoft.com/en-us/windows/wsl/install))
+Ci sono dei passaggi per iniziare su UNIX o Linux (incluso [WSL](https://learn.microsoft.com/en-us/windows/wsl/install))
1. Se non lo hai già, scarica e installa [Python](https://www.python.org/downloads/).
-2. Clona la repository di GitHub.
+2. Clona il repository GitHub.
```sh
git clone https://github.com/qbzzt/260215-ai-agent.git -b 01-getting-started
cd 260215-ai-agent
- ```
+```
3. Installa [`uv`](https://docs.astral.sh/uv/getting-started/installation/). Il comando sul tuo sistema potrebbe essere diverso.
```sh
pipx install uv
- ```
+```
4. Scarica le librerie.
```sh
uv sync
- ```
+```
5. Attiva l'ambiente virtuale.
```sh
source .venv/bin/activate
- ```
+```
-6. Per verificare che Python e Web3 funzionino correttamente, esegui `python3` e forniscigli questo programma. Puoi inserirlo al prompt `>>>`; non è necessario creare un file.
+6. Per verificare che Python e Web3 funzionino correttamente, esegui `python3` e forniscigli questo programma. Puoi inserirlo al prompt `>>>`; non c'è bisogno di creare un file.
```python
from web3 import Web3
@@ -86,18 +87,18 @@ Ci sono passaggi per iniziare con UNIX o Linux (incluso [WSL](https://learn.micr
w3 = Web3(Web3.HTTPProvider(MAINNET_URL))
w3.eth.block_number
quit()
- ```
+```
-### Lettura dalla blockchain {#read-blockchain}
+### Leggere dalla blockchain {#read-blockchain}
-Il passo successivo è leggere dalla blockchain. Per farlo, devi passare al branch `02-read-quote` e quindi usare `uv` per eseguire il programma.
+Il passaggio successivo è leggere dalla blockchain. Per farlo, devi passare al branch `02-read-quote` e poi usare `uv` per eseguire il programma.
```sh
git checkout 02-read-quote
uv run agent.py
```
-Dovresti ricevere un elenco di oggetti `Quote`, ognuno con un indicatore ora, un prezzo e l'asset (attualmente sempre `WETH/USDC`).
+Dovresti ricevere un elenco di oggetti `Quote`, ciascuno con un timestamp, un prezzo e l'asset (attualmente sempre `WETH/USDC`).
Ecco una spiegazione riga per riga.
@@ -113,19 +114,19 @@ import functools
import sys
```
-Importa le librerie di cui abbiamo bisogno. Sono spiegati di seguito quando vengono utilizzati.
+Importa le librerie di cui abbiamo bisogno. Sono spiegate di seguito quando vengono utilizzate.
```python
print = functools.partial(print, flush=True)
```
-Sostituisce il `print` di Python con una versione che svuota sempre l'output immediatamente. Questo è utile in uno script a lunga esecuzione perché non vogliamo attendere aggiornamenti di stato o output di debug.
+Sostituisce il `print` di Python con una versione che svuota sempre l'output immediatamente. Questo è utile in uno script a esecuzione prolungata perché non vogliamo aspettare per gli aggiornamenti di stato o l'output di debug.
```python
MAINNET_URL = "https://eth.drpc.org"
```
-Un URL per accedere alla Rete Principale. Puoi ottenerne uno da [Nodo come servizio](/developers/docs/nodes-and-clients/nodes-as-a-service/) o usare uno di quelli pubblicizzati in [Chainlist](https://chainlist.org/chain/1).
+Un URL per accedere alla rete principale. Puoi ottenerne uno da [Nodo come servizio](/developers/docs/nodes-and-clients/nodes-as-a-service/) o usarne uno tra quelli pubblicizzati su [Chainlist](https://chainlist.org/chain/1).
```python
BLOCK_TIME_SECONDS = 12
@@ -134,20 +135,20 @@ HOUR_BLOCKS = MINUTE_BLOCKS * 60
DAY_BLOCKS = HOUR_BLOCKS * 24
```
-Un blocco della Rete Principale di Ethereum si verifica in genere ogni dodici secondi, quindi questo è il numero di blocchi che ci aspetteremmo si verifichino in un periodo di tempo. Nota che questa non è una cifra esatta. Quando il [proponente del blocco](/developers/docs/consensus-mechanisms/pos/block-proposal/) non è attivo, quel blocco viene saltato e il tempo per il blocco successivo è di 24 secondi. Se volessimo ottenere il blocco esatto per un indicatore ora, useremmo la [ricerca binaria](https://en.wikipedia.org/wiki/Binary_search). Tuttavia, questo è sufficientemente vicino per i nostri scopi. Prevedere il futuro non è una scienza esatta.
+Un blocco della rete principale di Ethereum viene tipicamente prodotto ogni dodici secondi, quindi questo è il numero di blocchi che ci aspetteremmo in un determinato periodo di tempo. Nota che questa non è una cifra esatta. Quando il [proponente del blocco](/developers/docs/consensus-mechanisms/pos/block-proposal/) è inattivo, quel blocco viene saltato e il tempo per il blocco successivo è di 24 secondi. Se volessimo ottenere il blocco esatto per un timestamp, useremmo la [ricerca binaria](https://it.wikipedia.org/wiki/Ricerca_dicotomica). Tuttavia, questo è abbastanza vicino per i nostri scopi. Prevedere il futuro non è una scienza esatta.
```python
CYCLE_BLOCKS = DAY_BLOCKS
```
-La dimensione del ciclo. Esaminiamo le quotazioni una volta per ciclo e proviamo a stimare il valore alla fine del ciclo successivo.
+La dimensione del ciclo. Esaminiamo le quotazioni una volta per ciclo e cerchiamo di stimare il valore alla fine del ciclo successivo.
```python
-# L'indirizzo del gruppo che stiamo leggendo
+# L'indirizzo della pool che stiamo leggendo
WETHUSDC_ADDRESS = Web3.to_checksum_address("0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640")
```
-I valori delle quotazioni sono presi dal gruppo USDC/WETH di Uniswap 3 all'indirizzo [`0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640`](https://eth.blockscout.com/address/0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640?tab=read_write_contract). Questo indirizzo è già in formato checksum, ma è meglio usare [`Web3.to_checksum_address`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_checksum_address) per rendere il codice riutilizzabile.
+I valori delle quotazioni sono presi dalla pool USDC/WETH di Uniswap 3 all'indirizzo [`0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640`](https://eth.blockscout.com/address/0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640?tab=read_write_contract). Questo indirizzo è già in formato checksum, ma è meglio usare [`Web3.to_checksum_address`](https://web3py.readthedocs.io/en/stable/web3.main.html#web3.Web3.to_checksum_address) per rendere il codice riutilizzabile.
```python
POOL_ABI = [
@@ -179,9 +180,9 @@ class ERC20Token:
contract: Contract
```
-Questo è un modo per creare una classe di dati in Python. Il tipo di dati [`Contract`](https://web3py.readthedocs.io/en/stable/web3.contract.html) viene utilizzato per connettersi al contratto. Nota il `(frozen=True)`. In Python i [booleani](https://en.wikipedia.org/wiki/Boolean_data_type) sono definiti come `True` o `False`, con la lettera maiuscola. Questa classe di dati è `frozen`, il che significa che i campi non possono essere modificati.
+Questo è un modo per creare una classe di dati (data class) in Python. Il tipo di dati [`Contract`](https://web3py.readthedocs.io/en/stable/web3.contract.html) viene utilizzato per connettersi al contratto. Nota il `(frozen=True)`. In Python i [booleani](https://it.wikipedia.org/wiki/Tipo_booleano) sono definiti come `True` o `False`, con l'iniziale maiuscola. Questa classe di dati è `frozen` (congelata), il che significa che i campi non possono essere modificati.
-Nota l'indentazione. A differenza dei [linguaggi derivati dal C](https://en.wikipedia.org/wiki/List_of_C-family_programming_languages), Python usa l'indentazione per denotare i blocchi. L'interprete Python sa che la seguente definizione non fa parte di questa classe di dati perché non inizia con la stessa indentazione dei campi della classe di dati.
+Nota l'indentazione. A differenza dei [linguaggi derivati dal C](https://it.wikipedia.org/wiki/Linguaggio_C), Python usa l'indentazione per denotare i blocchi. L'interprete Python sa che la definizione seguente non fa parte di questa classe di dati perché non inizia con la stessa indentazione dei campi della classe di dati.
```python
@dataclass(frozen=True)
@@ -202,10 +203,10 @@ Il tipo [`Decimal`](https://docs.python.org/3/library/decimal.html) viene utiliz
Questo è il modo per definire una funzione in Python. La definizione è indentata per mostrare che fa ancora parte di `PoolInfo`.
-In una funzione che fa parte di una classe di dati il primo parametro è sempre `self`, l'istanza della classe di dati che ha chiamato qui. Qui c'è un altro parametro, il numero del blocco.
+In una funzione che fa parte di una classe di dati, il primo parametro è sempre `self`, l'istanza della classe di dati che ha effettuato la chiamata. Qui c'è un altro parametro, il numero del blocco.
```python
- assert block <= w3.eth.block_number, "Il blocco è nel futuro"
+ assert block <= w3.eth.block_number, "Block is in the future"
```
Se potessimo leggere il futuro, non avremmo bisogno dell'IA per il trading.
@@ -214,7 +215,7 @@ Se potessimo leggere il futuro, non avremmo bisogno dell'IA per il trading.
sqrt_price_x96 = Decimal(self.contract.functions.slot0().call(block_identifier=block)[0])
```
-La sintassi per chiamare una funzione sulla EVM da Web3 è questa: `.functions.().call()`. I parametri possono essere i parametri della funzione EVM (se presenti; qui non ce ne sono) o [parametri nominativi](https://en.wikipedia.org/wiki/Named_parameter) per modificare il comportamento della blockchain. Qui ne usiamo uno, `block_identifier`, per specificare [il numero del blocco](/developers/docs/apis/json-rpc/#default-block) in cui desideriamo eseguire.
+La sintassi per chiamare una funzione sull'EVM da Web3 è questa: `.functions.().call()`. I parametri possono essere i parametri della funzione EVM (se presenti; qui non ce ne sono) o [parametri nominati](https://it.wikipedia.org/wiki/Parametro_nominato) per modificare il comportamento della blockchain. Qui ne usiamo uno, `block_identifier`, per specificare [il numero del blocco](/developers/docs/apis/json-rpc/#default-block) in cui desideriamo eseguire.
Il risultato è [questa struct, in forma di array](https://github.com/Uniswap/v3-core/blob/main/contracts/UniswapV3Pool.sol#L56-L72). Il primo valore è una funzione del tasso di cambio tra i due token.
@@ -222,14 +223,14 @@ Il risultato è [questa struct, in forma di array](https://github.com/Uniswap/v3
raw_price = (sqrt_price_x96 / Decimal(2**96)) ** 2
```
-Per ridurre i calcoli sulla catena, Uniswap v3 non memorizza il fattore di cambio effettivo ma la sua radice quadrata. Poiché l'EVM non supporta la matematica in virgola mobile o le frazioni, invece del valore effettivo, la risposta è
+Per ridurre i calcoli on-chain, Uniswap v3 non memorizza il fattore di cambio effettivo, ma piuttosto la sua radice quadrata. Poiché l'EVM non supporta la matematica in virgola mobile o le frazioni, invece del valore effettivo, la risposta è
```python
# (token1 per token0)
return 1/(raw_price * self.decimal_factor)
```
-Il prezzo grezzo che otteniamo è il numero di `token0` che otteniamo per ogni `token1`. Nel nostro gruppo `token0` è USDC (stablecoin con lo stesso valore di un dollaro USA) e `token1` è [WETH](https://opensea.io/learn/blockchain/what-is-weth). Il valore che vogliamo veramente è il numero di dollari per WETH, non l'inverso.
+Il prezzo grezzo che otteniamo è il numero di `token0` che riceviamo per ogni `token1`. Nella nostra pool `token0` è USDC (stablecoin con lo stesso valore di un dollaro USA) e `token1` è [WETH](https://opensea.io/learn/blockchain/what-is-weth). Il valore che vogliamo veramente è il numero di dollari per WETH, non l'inverso.
Il fattore decimale è il rapporto tra i [fattori decimali](https://docs.openzeppelin.com/contracts/4.x/erc20#a-note-on-decimals) per i due token.
@@ -241,7 +242,7 @@ class Quote:
asset: str
```
-Questa classe di dati rappresenta una quotazione: il prezzo di un asset specifico in un dato momento. A questo punto, il campo `asset` è irrilevante perché usiamo un singolo gruppo e quindi abbiamo un singolo asset. Tuttavia, aggiungeremo altri asset in seguito.
+Questa classe di dati rappresenta una quotazione: il prezzo di un asset specifico in un dato momento. A questo punto, il campo `asset` è irrilevante perché usiamo una singola pool e quindi abbiamo un singolo asset. Tuttavia, aggiungeremo altri asset in seguito.
```python
def read_token(address: str) -> ERC20Token:
@@ -277,7 +278,7 @@ def read_pool(address: str) -> PoolInfo:
)
```
-Questa funzione restituisce tutto ciò di cui abbiamo bisogno su [un gruppo specifico](https://github.com/Uniswap/v3-core/blob/main/contracts/UniswapV3Pool.sol). La sintassi `f""` è una [stringa formattata](https://docs.python.org/3/reference/lexical_analysis.html#f-strings).
+Questa funzione restituisce tutto ciò di cui abbiamo bisogno su [una pool specifica](https://github.com/Uniswap/v3-core/blob/main/contracts/UniswapV3Pool.sol). La sintassi `f""` è una [stringa formattata](https://docs.python.org/3/reference/lexical_analysis.html#f-strings).
```python
def get_quote(pool: PoolInfo, block_number: int = None) -> Quote:
@@ -292,7 +293,7 @@ Ottieni un oggetto `Quote`. Il valore predefinito per `block_number` è `None` (
Se non è stato specificato un numero di blocco, usa `w3.eth.block_number`, che è l'ultimo numero di blocco. Questa è la sintassi per [un'istruzione `if`](https://docs.python.org/3/reference/compound_stmts.html#the-if-statement).
-Potrebbe sembrare che sarebbe stato meglio impostare semplicemente il valore predefinito su `w3.eth.block_number`, ma non funziona bene perché sarebbe il numero di blocco al momento della definizione della funzione. In un agente a lunga esecuzione, questo sarebbe un problema.
+Potrebbe sembrare che sarebbe stato meglio impostare semplicemente il valore predefinito su `w3.eth.block_number`, ma non funziona bene perché sarebbe il numero del blocco al momento in cui la funzione viene definita. In un agente a esecuzione prolungata, questo sarebbe un problema.
```python
block = w3.eth.get_block(block_number)
@@ -310,14 +311,14 @@ Usa [la libreria `datetime`](https://docs.python.org/3/library/datetime.html) pe
def get_quotes(pool: PoolInfo, start_block: int, end_block: int, step: int) -> list[Quote]:
```
-In Python si definisce un [elenco](https://docs.python.org/3/library/stdtypes.html#typesseq-list) che può contenere solo un tipo specifico usando `list[]`.
+In Python definisci una [lista](https://docs.python.org/3/library/stdtypes.html#typesseq-list) che può contenere solo un tipo specifico usando `list[]`.
```python
quotes = []
for block in range(start_block, end_block + 1, step):
```
-In Python un [`ciclo `for``](https://docs.python.org/3/tutorial/controlflow.html#for-statements) di solito itera su un elenco. L'elenco di numeri di blocco in cui trovare le quotazioni proviene da [`range`](https://docs.python.org/3/library/stdtypes.html#range).
+In Python un [ciclo `for`](https://docs.python.org/3/tutorial/controlflow.html#for-statements) tipicamente itera su una lista. L'elenco dei numeri di blocco in cui trovare le quotazioni proviene da [`range`](https://docs.python.org/3/library/stdtypes.html#range).
```python
quote = get_quote(pool, block)
@@ -325,7 +326,7 @@ In Python un [`ciclo `for``](https://docs.python.org/3/tutorial/controlflow.html
return quotes
```
-Per ogni numero di blocco, ottieni un oggetto `Quote` e aggiungilo all'elenco `quotes`. Quindi restituisci quell'elenco.
+Per ogni numero di blocco, ottieni un oggetto `Quote` e aggiungilo alla lista `quotes`. Quindi restituisci quella lista.
```python
pool = read_pool(WETHUSDC_ADDRESS)
@@ -339,9 +340,9 @@ quotes = get_quotes(
pprint(quotes)
```
-Questo è il codice principale dello script. Leggi le informazioni del gruppo, ottieni dodici quotazioni e visualizzale con [`pprint`](https://docs.python.org/3/library/pprint.html#pprint.pprint).
+Questo è il codice principale dello script. Leggi le informazioni sulla pool, ottieni dodici quotazioni e stampale con [`pprint`](https://docs.python.org/3/library/pprint.html#pprint.pprint).
-### Creazione di un prompt {#prompt}
+### Creare un prompt {#prompt}
Successivamente, dobbiamo convertire questo elenco di quotazioni in un prompt per un LLM e ottenere un valore futuro atteso.
@@ -353,7 +354,7 @@ uv run agent.py
L'output ora sarà un prompt per un LLM, simile a:
```
-Date queste quotazioni:
+Given these quotes:
Asset: WETH/USDC
2026-01-20T16:34 3016.21
.
@@ -369,19 +370,19 @@ Asset: WBTC/WETH
2026-02-01T17:50 33.46
-Quale valore ti aspetteresti per WETH/USDC all'ora 2026-02-02T17:56?
+What would you expect the value for WETH/USDC to be at time 2026-02-02T17:56?
-Fornisci la tua risposta come un singolo numero arrotondato a due cifre decimali,
-senza alcun altro testo.
+Provide your answer as a single number rounded to two decimal places,
+without any other text.
```
Nota che qui ci sono quotazioni per due asset, `WETH/USDC` e `WBTC/WETH`. L'aggiunta di quotazioni da un altro asset potrebbe migliorare l'accuratezza della previsione.
-#### Come appare un prompt {#prompt-explanation}
+#### Come si presenta un prompt {#prompt-explanation}
-Questo prompt contiene tre sezioni, che sono abbastanza comuni nei prompt LLM.
+Questo prompt contiene tre sezioni, che sono piuttosto comuni nei prompt degli LLM.
-1. Informazioni. Gli LLM hanno molte informazioni dal loro addestramento, ma di solito non hanno le più recenti. Questo è il motivo per cui dobbiamo recuperare le ultime quotazioni qui. L'aggiunta di informazioni a un prompt è chiamata [generazione aumentata dal recupero (RAG)](https://en.wikipedia.org/wiki/Retrieval-augmented_generation).
+1. Informazioni. Gli LLM hanno molte informazioni derivanti dal loro addestramento, ma di solito non hanno le più recenti. Questo è il motivo per cui dobbiamo recuperare le ultime quotazioni qui. L'aggiunta di informazioni a un prompt è chiamata [retrieval augmented generation (RAG)](https://it.wikipedia.org/wiki/Retrieval-augmented_generation).
2. La domanda vera e propria. Questo è ciò che vogliamo sapere.
@@ -395,15 +396,15 @@ Ecco il nuovo codice.
from datetime import datetime, timezone, timedelta
```
-Dobbiamo fornire all'LLM l'ora per la quale vogliamo una stima. Per ottenere un'ora "n minuti/ore/giorni" nel futuro, usiamo [la classe `timedelta`](https://docs.python.org/3/library/datetime.html#datetime.timedelta).
+Dobbiamo fornire all'LLM il momento per il quale vogliamo una stima. Per ottenere un tempo "n minuti/ore/giorni" nel futuro, usiamo [la classe `timedelta`](https://docs.python.org/3/library/datetime.html#datetime.timedelta).
```python
-# Gli indirizzi dei gruppi che stiamo leggendo
+# Gli indirizzi delle pool che stiamo leggendo
WETHUSDC_ADDRESS = Web3.to_checksum_address("0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640")
WETHWBTC_ADDRESS = Web3.to_checksum_address("0xCBCdF9626bC03E24f779434178A73a0B4bad62eD")
```
-Abbiamo due gruppi che dobbiamo leggere.
+Abbiamo due pool che dobbiamo leggere.
```python
@dataclass(frozen=True)
@@ -414,16 +415,16 @@ class PoolInfo:
reverse: bool = False
def get_price(self, block: int) -> Decimal:
- assert block <= w3.eth.block_number, "Il blocco è nel futuro"
+ assert block <= w3.eth.block_number, "Block is in the future"
sqrt_price_x96 = Decimal(self.contract.functions.slot0().call(block_identifier=block)[0])
- raw_price = (sqrt_price_x96 / Decimal(2**96)) ** 2 # (token1 per token0)
+ raw_price = (sqrt_price_x96 / Decimal(2**96)) ** 2 # (token1 per token0)
if self.reverse:
return 1/(raw_price * self.decimal_factor)
else:
return raw_price * self.decimal_factor
```
-Nel gruppo WETH/USDC, vogliamo sapere quanti `token0` (USDC) ci servono per acquistare un `token1` (WETH). Nel gruppo WETH/WBTC, vogliamo sapere quanti `token1` (WETH) ci servono per acquistare un `token0` (WBTC, che è Bitcoin wrappato). Dobbiamo tenere traccia se il rapporto del gruppo deve essere invertito.
+Nella pool WETH/USDC, vogliamo sapere quanti `token0` (USDC) ci servono per comprare un `token1` (WETH). Nella pool WETH/WBTC, vogliamo sapere quanti `token1` (WETH) ci servono per comprare un `token0` (WBTC, che è Bitcoin avvolto). Dobbiamo tenere traccia se il rapporto della pool deve essere invertito.
```python
def read_pool(address: str, reverse: bool = False) -> PoolInfo:
@@ -441,9 +442,9 @@ def read_pool(address: str, reverse: bool = False) -> PoolInfo:
)
```
-Per sapere se un gruppo deve essere invertito, dobbiamo ottenerlo come input per `read_pool`. Inoltre, il simbolo dell'asset deve essere impostato correttamente.
+Per sapere se una pool deve essere invertita, dobbiamo ottenerlo come input per `read_pool`. Inoltre, il simbolo dell'asset deve essere impostato correttamente.
-La sintassi ` if else ` è l'equivalente Python dell'[operatore condizionale ternario](https://en.wikipedia.org/wiki/Ternary_conditional_operator), che in un linguaggio derivato dal C sarebbe ` ? : `.
+La sintassi ` if else ` è l'equivalente Python dell'[operatore condizionale ternario](https://it.wikipedia.org/wiki/Operatore_ternario), che in un linguaggio derivato dal C sarebbe ` ? : `.
```python
def format_quotes(quotes: list[Quote]) -> str:
@@ -453,30 +454,30 @@ def format_quotes(quotes: list[Quote]) -> str:
return result
```
-Questa funzione costruisce una stringa che formatta un elenco di oggetti `Quote`, assumendo che si applichino tutti allo stesso asset.
+Questa funzione costruisce una stringa che formatta un elenco di oggetti `Quote`, supponendo che si applichino tutti allo stesso asset.
```python
def make_prompt(quotes: list[list[Quote]], expected_time: str, asset: str) -> str:
return f"""
```
-In Python le [stringhe letterali multiriga](https://www.w3schools.com/python/gloss_python_multi_line_strings.asp) sono scritte come `"""` .... `"""`.
+In Python le [stringhe letterali multilinea](https://www.w3schools.com/python/gloss_python_multi_line_strings.asp) sono scritte come `"""` .... `"""`.
```python
-Date queste quotazioni:
+Given these quotes:
{
functools.reduce(lambda acc, q: acc + '\n' + q,
map(lambda q: format_quotes(q), quotes))
}
```
-Qui usiamo il modello [MapReduce](https://en.wikipedia.org/wiki/MapReduce) per generare una stringa per ogni elenco di quotazioni con `format_quotes`, quindi li riduciamo in una singola stringa da usare nel prompt.
+Qui, usiamo il pattern [MapReduce](https://it.wikipedia.org/wiki/MapReduce) per generare una stringa per ogni elenco di quotazioni con `format_quotes`, quindi le riduciamo in una singola stringa da usare nel prompt.
```python
-Quale valore ti aspetteresti per {asset} all'ora {expected_time}?
+What would you expect the value for {asset} to be at time {expected_time}?
-Fornisci la tua risposta come un singolo numero arrotondato a due cifre decimali,
-senza alcun altro testo.
+Provide your answer as a single number rounded to two decimal places,
+without any other text.
"""
```
@@ -500,7 +501,7 @@ wethwbtc_quotes = get_quotes(
)
```
-Esamina i due gruppi e ottieni quotazioni da entrambi.
+Esamina le due pool e ottieni le quotazioni da entrambe.
```python
future_time = (datetime.now(timezone.utc) + timedelta(days=1)).isoformat()[0:16]
@@ -512,33 +513,30 @@ Determina il momento futuro per il quale vogliamo la stima e crea il prompt.
### Interfacciarsi con un LLM {#interface-llm}
-Successivamente, inviamo un prompt a un LLM effettivo e riceviamo un valore futuro atteso. Ho scritto questo programma usando OpenAI, quindi se vuoi usare un fornitore diverso, dovrai adattarlo.
-
-1. Ottieni un [conto OpenAI](https://auth.openai.com/create-account)
-
-2. [Ricarica il conto](https://platform.openai.com/settings/organization/billing/overview)—l'importo minimo al momento della scrittura è di 5$
+Successivamente, interroghiamo un vero LLM e riceviamo un valore futuro atteso. Ho scritto questo programma usando OpenAI, quindi se vuoi usare un provider diverso, dovrai adattarlo.
+1. Ottieni un [account OpenAI](https://auth.openai.com/create-account)
+2. [Finanzia l'account](https://platform.openai.com/settings/organization/billing/overview): l'importo minimo al momento della stesura è di 5$
3. [Crea una chiave API](https://platform.openai.com/settings/organization/api-keys)
-
4. Nella riga di comando, esporta la chiave API in modo che il tuo programma possa usarla
```sh
- export OPENAI_API_KEY=sk-
- ```
+ export OPENAI_API_KEY=sk-
+```
5. Fai il checkout ed esegui l'agente
```sh
git checkout 04-interface-llm
uv run agent.py
- ```
+```
Ecco il nuovo codice.
```python
from openai import OpenAI
-open_ai = OpenAI() # Il client legge la variabile d'ambiente OPENAI_API_KEY
+open_ai = OpenAI() # Il client legge la variabile d'ambiente OPENAI_API_KEY
```
Importa e istanzia l'API di OpenAI.
@@ -560,20 +558,20 @@ Chiama l'API di OpenAI (`open_ai.chat.completions.create`) per creare la rispost
expected_price = Decimal(response.choices[0].message.content.strip())
current_price = wethusdc_quotes[-1].price
-print ("Prezzo attuale:", wethusdc_quotes[-1].price)
-print(f"In {future_time}, prezzo previsto: {expected_price} USD")
+print ("Current price:", wethusdc_quotes[-1].price)
+print(f"In {future_time}, expected price: {expected_price} USD")
if (expected_price > current_price):
- print(f"Compra, mi aspetto che il prezzo salga di {expected_price - current_price} USD")
+ print(f"Buy, I expect the price to go up by {expected_price - current_price} USD")
else:
- print(f"Vendi, mi aspetto che il prezzo scenda di {current_price - expected_price} USD")
+ print(f"Sell, I expect the price to go down by {current_price - expected_price} USD")
```
-Mostra il prezzo e fornisci una raccomandazione di acquisto o vendita.
+Emetti il prezzo e fornisci una raccomandazione di acquisto o vendita.
#### Testare le previsioni {#testing-the-predictions}
-Ora che possiamo generare previsioni, possiamo anche utilizzare dati storici per valutare se produciamo previsioni utili.
+Ora che possiamo generare previsioni, possiamo anche usare i dati storici per valutare se produciamo previsioni utili.
```sh
uv run test-predictor.py
@@ -582,27 +580,27 @@ uv run test-predictor.py
Il risultato atteso è simile a:
```
-Previsione per 2026-01-05T19:50: previsto 3138.93 USD, reale 3218.92 USD, errore 79.99 USD
-Previsione per 2026-01-06T19:56: previsto 3243.39 USD, reale 3221.08 USD, errore 22.31 USD
-Previsione per 2026-01-07T20:02: previsto 3223.24 USD, reale 3146.89 USD, errore 76.35 USD
-Previsione per 2026-01-08T20:11: previsto 3150.47 USD, reale 3092.04 USD, errore 58.43 USD
+Prediction for 2026-01-05T19:50: predicted 3138.93 USD, real 3218.92 USD, error 79.99 USD
+Prediction for 2026-01-06T19:56: predicted 3243.39 USD, real 3221.08 USD, error 22.31 USD
+Prediction for 2026-01-07T20:02: predicted 3223.24 USD, real 3146.89 USD, error 76.35 USD
+Prediction for 2026-01-08T20:11: predicted 3150.47 USD, real 3092.04 USD, error 58.43 USD
.
.
.
-Previsione per 2026-01-31T22:33: previsto 2637.73 USD, reale 2417.77 USD, errore 219.96 USD
-Previsione per 2026-02-01T22:41: previsto 2381.70 USD, reale 2318.84 USD, errore 62.86 USD
-Previsione per 2026-02-02T22:49: previsto 2234.91 USD, reale 2349.28 USD, errore 114.37 USD
-Errore medio di previsione su 29 previsioni: 83.87103448275862068965517241 USD
-Variazione media per raccomandazione: 4.787931034482758620689655172 USD
-Varianza standard delle variazioni: 104.42 USD
-Giorni redditizi: 51.72%
-Giorni in perdita: 48.28%
+Prediction for 2026-01-31T22:33: predicted 2637.73 USD, real 2417.77 USD, error 219.96 USD
+Prediction for 2026-02-01T22:41: predicted 2381.70 USD, real 2318.84 USD, error 62.86 USD
+Prediction for 2026-02-02T22:49: predicted 2234.91 USD, real 2349.28 USD, error 114.37 USD
+Mean prediction error over 29 predictions: 83.87103448275862068965517241 USD
+Mean change per recommendation: 4.787931034482758620689655172 USD
+Standard variance of changes: 104.42 USD
+Profitable days: 51.72%
+Losing days: 48.28%
```
La maggior parte del tester è identica all'agente, ma ecco le parti nuove o modificate.
```python
-CYCLES_FOR_TEST = 40 # Per il backtest, quanti cicli testiamo
+CYCLES_FOR_TEST = 40 # Per il backtest, su quanti cicli effettuiamo il test
# Ottieni molte quotazioni
wethusdc_pool = read_pool(WETHUSDC_ADDRESS, True)
@@ -622,31 +620,31 @@ wethwbtc_quotes = get_quotes(
)
```
-Guardiamo indietro di `CYCLES_FOR_TEST` (specificato come 40 qui) giorni.
+Guardiamo indietro di `CYCLES_FOR_TEST` (specificato qui come 40) giorni.
```python
-# Crea previsioni e confrontale con la cronologia reale
+# Crea previsioni e verificale con lo storico reale
total_error = Decimal(0)
changes = []
```
-Ci sono due tipi di errori che ci interessano. Il primo, `total_error`, è semplicemente la somma degli errori commessi dal predittore.
+Ci sono due tipi di errori a cui siamo interessati. Il primo, `total_error`, è semplicemente la somma degli errori commessi dal predittore.
-Per capire il secondo, `changes`, dobbiamo ricordare lo scopo dell'agente. Non è prevedere il rapporto WETH/USDC (prezzo di ETH). È emettere raccomandazioni di vendita e acquisto. Se il prezzo è attualmente di 2000 $ e prevede 2010 $ domani, non ci importa se il risultato effettivo è 2020 $ e guadagniamo soldi extra. Ma ci importa se ha previsto 2010 $, e ha comprato ETH sulla base di quella raccomandazione, e il prezzo scende a 1990 $.
+Per capire il secondo, `changes`, dobbiamo ricordare lo scopo dell'agente. Non è prevedere il rapporto WETH/USDC (prezzo di ETH). È emettere raccomandazioni di vendita e acquisto. Se il prezzo è attualmente di 2000$ e prevede 2010$ per domani, non ci dispiace se il risultato effettivo è 2020$ e guadagniamo soldi extra. Ma ci _dispiace_ se ha previsto 2010$ e ha comprato ETH in base a quella raccomandazione, e il prezzo scende a 1990$.
```python
for index in range(0,len(wethusdc_quotes)-CYCLES_BACK):
```
-Possiamo esaminare solo i casi in cui la cronologia completa (i valori utilizzati per la previsione e il valore del mondo reale con cui confrontarla) è disponibile. Ciò significa che il caso più recente deve essere quello iniziato `CYCLES_BACK` fa.
+Possiamo esaminare solo i casi in cui è disponibile la cronologia completa (i valori utilizzati per la previsione e il valore reale con cui confrontarla). Ciò significa che il caso più recente deve essere quello iniziato `CYCLES_BACK` fa.
```python
wethusdc_slice = wethusdc_quotes[index:index+CYCLES_BACK]
wethwbtc_slice = wethwbtc_quotes[index:index+CYCLES_BACK]
```
-Usa le [slice](https://www.w3schools.com/python/ref_func_slice.asp) per ottenere lo stesso numero di campioni utilizzato dall'agente. Il codice tra qui e il segmento successivo è lo stesso codice per ottenere una previsione che abbiamo nell'agente.
+Usa gli [slice](https://www.w3schools.com/python/ref_func_slice.asp) per ottenere lo stesso numero di campioni del numero utilizzato dall'agente. Il codice tra qui e il segmento successivo è lo stesso codice per ottenere una previsione che abbiamo nell'agente.
```python
predicted_price = Decimal(response.choices[0].message.content.strip())
@@ -659,7 +657,7 @@ Ottieni il prezzo previsto, il prezzo reale e il prezzo al momento della previsi
```python
error = abs(predicted_price - real_price)
total_error += error
- print (f"Previsione per {prediction_time}: previsto {predicted_price} USD, reale {real_price} USD, errore {error} USD")
+ print (f"Prediction for {prediction_time}: predicted {predicted_price} USD, real {real_price} USD, error {error} USD")
```
Calcola l'errore e aggiungilo al totale.
@@ -670,30 +668,30 @@ Calcola l'errore e aggiungilo al totale.
changes.append(price_increase if recomended_action == 'buy' else -price_increase)
```
-Per `changes`, vogliamo l'impatto monetario dell'acquisto o della vendita di un ETH. Quindi, prima dobbiamo determinare la raccomandazione, poi valutare come è cambiato il prezzo effettivo e se la raccomandazione ha prodotto un guadagno (variazione positiva) o una perdita (variazione negativa).
+Per `changes`, vogliamo l'impatto monetario dell'acquisto o della vendita di un ETH. Quindi, per prima cosa, dobbiamo determinare la raccomandazione, quindi valutare come è cambiato il prezzo effettivo e se la raccomandazione ha fatto guadagnare (variazione positiva) o perdere denaro (variazione negativa).
```python
-print (f"Errore medio di previsione su {len(wethusdc_quotes)-CYCLES_BACK} previsioni: {total_error / Decimal(len(wethusdc_quotes)-CYCLES_BACK)} USD")
+print (f"Mean prediction error over {len(wethusdc_quotes)-CYCLES_BACK} predictions: {total_error / Decimal(len(wethusdc_quotes)-CYCLES_BACK)} USD")
length_changes = Decimal(len(changes))
mean_change = sum(changes, Decimal(0)) / length_changes
-print (f"Variazione media per raccomandazione: {mean_change} USD")
+print (f"Mean change per recommendation: {mean_change} USD")
var = sum((x - mean_change) ** 2 for x in changes) / length_changes
-print (f"Varianza standard delle variazioni: {var.sqrt().quantize(Decimal("0.01"))} USD")
+print (f"Standard variance of changes: {var.sqrt().quantize(Decimal("0.01"))} USD")
```
Riporta i risultati.
```python
-print (f"Giorni redditizi: {len(list(filter(lambda x: x > 0, changes)))/length_changes:.2%}")
-print (f"Giorni in perdita: {len(list(filter(lambda x: x < 0, changes)))/length_changes:.2%}")
+print (f"Profitable days: {len(list(filter(lambda x: x > 0, changes)))/length_changes:.2%}")
+print (f"Losing days: {len(list(filter(lambda x: x < 0, changes)))/length_changes:.2%}")
```
-Usa [`filter`](https://www.w3schools.com/python/ref_func_filter.asp) per contare il numero di giorni redditizi e il numero di giorni costosi. Il risultato è un oggetto filtro, che dobbiamo convertire in un elenco per ottenerne la lunghezza.
+Usa [`filter`](https://www.w3schools.com/python/ref_func_filter.asp) per contare il numero di giorni redditizi e il numero di giorni in perdita. Il risultato è un oggetto filtro, che dobbiamo convertire in una lista per ottenerne la lunghezza.
-### Invio di transazioni {#submit-txn}
+### Inviare transazioni {#submit-txn}
-Ora dobbiamo effettivamente inviare le transazioni. Tuttavia, non voglio spendere soldi veri a questo punto, prima che il sistema sia collaudato. Invece, creeremo una biforcazione locale della Rete Principale e faremo "trading" su quella rete.
+Ora dobbiamo effettivamente inviare transazioni. Tuttavia, non voglio spendere soldi veri a questo punto, prima che il sistema sia collaudato. Invece, creeremo una biforcazione locale della rete principale e faremo "trading" su quella rete.
Ecco i passaggi per creare una biforcazione locale e abilitare il trading.
@@ -703,20 +701,20 @@ Ecco i passaggi per creare una biforcazione locale e abilitare il trading.
```sh
anvil --fork-url https://eth.drpc.org --block-time 12
- ```
+```
- `anvil` è in ascolto sull'URL predefinito per Foundry, http://localhost:8545, quindi non è necessario specificare l'URL per [il comando `cast`](https://getfoundry.sh/cast/overview) che usiamo per manipolare la blockchain.
+ `anvil` è in ascolto sull'URL predefinito per Foundry, http://localhost:8545, quindi non abbiamo bisogno di specificare l'URL per [il comando `cast`](https://getfoundry.sh/cast/overview) che usiamo per manipolare la blockchain.
-3. Quando si esegue in `anvil`, ci sono dieci conti di prova che hanno ETH: imposta le variabili d'ambiente per il primo
+3. Quando si esegue in `anvil`, ci sono dieci account di test che hanno ETH: imposta le variabili d'ambiente per il primo
```sh
PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
ADDRESS=`cast wallet address $PRIVATE_KEY`
- ```
+```
-4. Questi sono i contratti che dobbiamo usare. [`SwapRouter`](https://github.com/Uniswap/v3-periphery/blob/main/contracts/SwapRouter.sol) è il contratto di Uniswap v3 che usiamo per fare trading. Potremmo fare trading direttamente attraverso il gruppo, ma questo è molto più facile.
+4. Questi sono i contratti che dobbiamo usare. [`SwapRouter`](https://github.com/Uniswap/v3-periphery/blob/main/contracts/SwapRouter.sol) è il contratto Uniswap v3 che usiamo per fare effettivamente trading. Potremmo fare trading direttamente tramite la pool, ma questo è molto più semplice.
- Le due variabili in basso sono i percorsi di Uniswap v3 necessari per scambiare tra WETH e USDC.
+ Le due variabili in basso sono i percorsi di Uniswap v3 necessari per lo scambio tra WETH e USDC.
```sh
WETH_ADDRESS=0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2
@@ -725,13 +723,13 @@ Ecco i passaggi per creare una biforcazione locale e abilitare il trading.
SWAP_ROUTER=0xE592427A0AEce92De3Edee1F18E0157C05861564
WETH_TO_USDC=0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc20001F4A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
USDC_TO_WETH=0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB480001F4C02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2
- ```
+```
-5. Ognuno dei conti di prova ha 10.000 ETH. Usa il contratto WETH per wrappare 1000 ETH per ottenere 1000 WETH per il trading.
+5. Ciascuno degli account di test ha 10.000 ETH. Usa il contratto WETH per avvolgere 1000 ETH per ottenere 1000 WETH per il trading.
```sh
cast send $WETH_ADDRESS "deposit()" --value 1000ether --private-key $PRIVATE_KEY
- ```
+```
6. Usa `SwapRouter` per scambiare 500 WETH con USDC.
@@ -742,16 +740,16 @@ Ecco i passaggi per creare una biforcazione locale e abilitare il trading.
"exactInput((bytes,address,uint256,uint256,uint256))" \
"($WETH_TO_USDC,$ADDRESS,$MAXINT,500ether,1000000)" \
--private-key $PRIVATE_KEY
- ```
+```
- La chiamata `approve` crea un'autorizzazione che consente a `SwapRouter` di spendere alcuni dei nostri token. I contratti non possono monitorare gli eventi, quindi se trasferiamo i token direttamente al contratto `SwapRouter`, questo non saprebbe di essere stato pagato. Invece, permettiamo al contratto `SwapRouter` di spendere un certo importo, e poi `SwapRouter` lo fa. Questo viene fatto tramite una funzione chiamata da `SwapRouter`, quindi sa se ha avuto successo.
+ La chiamata `approve` crea un'indennità (allowance) che consente a `SwapRouter` di spendere alcuni dei nostri token. I contratti non possono monitorare gli eventi, quindi se trasferissimo i token direttamente al contratto `SwapRouter`, non saprebbe di essere stato pagato. Invece, permettiamo al contratto `SwapRouter` di spendere un certo importo, e poi `SwapRouter` lo fa. Questo viene fatto tramite una funzione chiamata da `SwapRouter`, in modo che sappia se ha avuto successo.
7. Verifica di avere abbastanza di entrambi i token.
```sh
cast call $WETH_ADDRESS "balanceOf(address)" $ADDRESS | cast from-wei
echo `cast call $USDC_ADDRESS "balanceOf(address)" $ADDRESS | cast to-dec`/10^6 | bc
- ```
+```
Ora che abbiamo WETH e USDC, possiamo effettivamente eseguire l'agente.
@@ -764,26 +762,26 @@ L'output sarà simile a:
```
(ai-trading-agent) qbzzt@Ori-Cloudnomics:~/260215-ai-agent$ uv run agent.py
-Prezzo attuale: 1843.16
-In 2026-02-06T23:07, prezzo previsto: 1724.41 USD
-Saldi del conto prima dello scambio:
-Saldo USDC: 927301.578272
-Saldo WETH: 500
-Vendi, mi aspetto che il prezzo scenda di 118.75 USD
-Transazione di approvazione inviata: 74e367ddbb407c1aaf567d87aa5863049991b1d2aa092b6b85195d925e2bd41f
-Transazione di approvazione minata.
-Transazione di vendita inviata: fad1bcf938585c9e90364b26ac7a80eea9efd34c37e5db81e58d7655bcae28bf
-Transazione di vendita minata.
-Saldi del conto dopo lo scambio:
-Saldo USDC: 929143.797116
-Saldo WETH: 499
+Current price: 1843.16
+In 2026-02-06T23:07, expected price: 1724.41 USD
+Account balances before trade:
+USDC Balance: 927301.578272
+WETH Balance: 500
+Sell, I expect the price to go down by 118.75 USD
+Approve transaction sent: 74e367ddbb407c1aaf567d87aa5863049991b1d2aa092b6b85195d925e2bd41f
+Approve transaction mined.
+Sell transaction sent: fad1bcf938585c9e90364b26ac7a80eea9efd34c37e5db81e58d7655bcae28bf
+Sell transaction mined.
+Account balances after trade:
+USDC Balance: 929143.797116
+WETH Balance: 499
```
Per usarlo effettivamente, hai bisogno di alcune piccole modifiche.
-- Nella riga 14, cambia `MAINNET_URL` in un punto di accesso reale, come `https://eth.drpc.org`
-- Nella riga 28, cambia `PRIVATE_KEY` con la tua chiave privata
-- A meno che tu non sia molto ricco e possa comprare o vendere 1 ETH ogni giorno per un agente non provato, potresti voler cambiare la riga 29 per diminuire `WETH_TRADE_AMOUNT`
+- Alla riga 14, cambia `MAINNET_URL` in un vero punto di accesso, come `https://eth.drpc.org`
+- Alla riga 28, cambia `PRIVATE_KEY` con la tua chiave privata
+- A meno che tu non sia molto ricco e possa comprare o vendere 1 ETH ogni giorno per un agente non collaudato, potresti voler cambiare la riga 29 per diminuire `WETH_TRADE_AMOUNT`
#### Spiegazione del codice {#trading-code}
@@ -821,7 +819,7 @@ SWAP_ROUTER_ABI = [
]
```
-Nell'ABI di `SwapRouter` abbiamo solo bisogno di `exactInput`. Esiste una funzione correlata, `exactOutput`, che potremmo usare per comprare esattamente un WETH, ma per semplicità usiamo solo `exactInput` in entrambi i casi.
+Nell'ABI di `SwapRouter` abbiamo solo bisogno di `exactInput`. C'è una funzione correlata, `exactOutput`, che potremmo usare per comprare esattamente un WETH, ma per semplicità usiamo solo `exactInput` in entrambi i casi.
```python
account = w3.eth.account.from_key(PRIVATE_KEY)
@@ -831,7 +829,7 @@ swap_router = w3.eth.contract(
)
```
-Le definizioni Web3 per il [`conto`](https://web3py.readthedocs.io/en/stable/web3.eth.account.html) e il contratto `SwapRouter`.
+Le definizioni Web3 per l'[`account`](https://web3py.readthedocs.io/en/stable/web3.eth.account.html) e il contratto `SwapRouter`.
```python
def txn_params() -> dict:
@@ -843,13 +841,13 @@ def txn_params() -> dict:
}
```
-I parametri della transazione. Abbiamo bisogno di una funzione qui perché [il nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) deve cambiare ogni volta.
+I parametri della transazione. Abbiamo bisogno di una funzione qui perché [il nonce](https://it.wikipedia.org/wiki/Nonce) deve cambiare ogni volta.
```python
def approve_token(contract: Contract, amount: int):
```
-Approva un'autorizzazione di token per `SwapRouter`.
+Approva un'indennità di token per `SwapRouter`.
```python
txn = contract.functions.approve(SWAP_ROUTER_ADDRESS, amount).build_transaction(txn_params())
@@ -857,15 +855,15 @@ Approva un'autorizzazione di token per `SwapRouter`.
tx_hash = w3.eth.send_raw_transaction(signed_txn.raw_transaction)
```
-Questo è il modo in cui inviamo una transazione in Web3. Per prima cosa usiamo [l'oggetto `Contract`](https://web3py.readthedocs.io/en/stable/web3.contract.html) per costruire la transazione. Poi usiamo [`web3.eth.account.sign_transaction`](https://web3py.readthedocs.io/en/stable/web3.eth.account.html#sign-a-contract-transaction) per firmare la transazione, usando `PRIVATE_KEY`. Infine, usiamo [`w3.eth.send_raw_transaction`](https://web3py.readthedocs.io/en/stable/transactions.html#chapter-2-w3-eth-send-raw-transaction) per inviare la transazione.
+Questo è il modo in cui inviamo una transazione in Web3. Per prima cosa usiamo [l'oggetto `Contract`](https://web3py.readthedocs.io/en/stable/web3.contract.html) per costruire la transazione. Quindi usiamo [`web3.eth.account.sign_transaction`](https://web3py.readthedocs.io/en/stable/web3.eth.account.html#sign-a-contract-transaction) per firmare la transazione, usando `PRIVATE_KEY`. Infine, usiamo [`w3.eth.send_raw_transaction`](https://web3py.readthedocs.io/en/stable/transactions.html#chapter-2-w3-eth-send-raw-transaction) per inviare la transazione.
```python
- print(f"Transazione di approvazione inviata: {tx_hash.hex()}")
+ print(f"Approve transaction sent: {tx_hash.hex()}")
w3.eth.wait_for_transaction_receipt(tx_hash)
- print("Transazione di approvazione minata.")
+ print("Approve transaction mined.")
```
-[`w3.eth.wait_for_transaction_receipt`](https://web3py.readthedocs.io/en/stable/web3.eth.html#web3.eth.Eth.wait_for_transaction_receipt) attende che la transazione venga minata. Restituisce la ricevuta, se necessario.
+[`w3.eth.wait_for_transaction_receipt`](https://web3py.readthedocs.io/en/stable/web3.eth.html#web3.eth.Eth.wait_for_transaction_receipt) attende fino a quando la transazione non viene minata. Restituisce la ricevuta se necessario.
```python
SELL_PARAMS = {
@@ -877,7 +875,7 @@ SELL_PARAMS = {
}
```
-Questi sono i parametri per la vendita di WETH.
+Questi sono i parametri quando si vende WETH.
```python
def make_buy_params(quote: Quote) -> dict:
@@ -890,7 +888,7 @@ def make_buy_params(quote: Quote) -> dict:
}
```
-A differenza di `SELL_PARAMS`, i parametri di acquisto possono cambiare. L'importo in entrata è il costo di 1 WETH, come disponibile in `quote`.
+A differenza di `SELL_PARAMS`, i parametri di acquisto possono cambiare. L'importo di input è il costo di 1 WETH, come disponibile in `quote`.
```python
def buy(quote: Quote):
@@ -899,9 +897,9 @@ def buy(quote: Quote):
txn = swap_router.functions.exactInput(buy_params).build_transaction(txn_params())
signed_txn = w3.eth.account.sign_transaction(txn, private_key=PRIVATE_KEY)
tx_hash = w3.eth.send_raw_transaction(signed_txn.raw_transaction)
- print(f"Transazione di acquisto inviata: {tx_hash.hex()}")
+ print(f"Buy transaction sent: {tx_hash.hex()}")
w3.eth.wait_for_transaction_receipt(tx_hash)
- print("Transazione di acquisto minata.")
+ print("Buy transaction mined.")
def sell():
@@ -910,36 +908,36 @@ def sell():
txn = swap_router.functions.exactInput(SELL_PARAMS).build_transaction(txn_params())
signed_txn = w3.eth.account.sign_transaction(txn, private_key=PRIVATE_KEY)
tx_hash = w3.eth.send_raw_transaction(signed_txn.raw_transaction)
- print(f"Transazione di vendita inviata: {tx_hash.hex()}")
+ print(f"Sell transaction sent: {tx_hash.hex()}")
w3.eth.wait_for_transaction_receipt(tx_hash)
- print("Transazione di vendita minata.")
+ print("Sell transaction mined.")
```
-Le funzioni `buy()` e `sell()` sono quasi identiche. Per prima cosa approviamo un'autorizzazione sufficiente per `SwapRouter`, e poi lo chiamiamo con il percorso e l'importo corretti.
+Le funzioni `buy()` e `sell()` sono quasi identiche. Per prima cosa approviamo un'indennità sufficiente per `SwapRouter`, e poi lo chiamiamo con il percorso e l'importo corretti.
```python
def balances():
token0_balance = wethusdc_pool.token0.contract.functions.balanceOf(account.address).call()
token1_balance = wethusdc_pool.token1.contract.functions.balanceOf(account.address).call()
- print(f"{wethusdc_pool.token0.symbol} Saldo: {Decimal(token0_balance) / Decimal(10 ** wethusdc_pool.token0.decimals)}")
- print(f"{wethusdc_pool.token1.symbol} Saldo: {Decimal(token1_balance) / Decimal(10 ** wethusdc_pool.token1.decimals)}")
+ print(f"{wethusdc_pool.token0.symbol} Balance: {Decimal(token0_balance) / Decimal(10 ** wethusdc_pool.token0.decimals)}")
+ print(f"{wethusdc_pool.token1.symbol} Balance: {Decimal(token1_balance) / Decimal(10 ** wethusdc_pool.token1.decimals)}")
```
Riporta i saldi dell'utente in entrambe le valute.
```python
-print("Saldi del conto prima dello scambio:")
+print("Account balances before trade:")
balances()
if (expected_price > current_price):
- print(f"Compra, mi aspetto che il prezzo salga di {expected_price - current_price} USD")
+ print(f"Buy, I expect the price to go up by {expected_price - current_price} USD")
buy(wethusdc_quotes[-1])
else:
- print(f"Vendi, mi aspetto che il prezzo scenda di {current_price - expected_price} USD")
+ print(f"Sell, I expect the price to go down by {current_price - expected_price} USD")
sell()
-print("Saldi del conto dopo lo scambio:")
+print("Account balances after trade:")
balances()
```
@@ -953,28 +951,28 @@ Questa non è una versione di produzione completa; è semplicemente un esempio p
Ci sono due fatti importanti che l'agente ignora quando decide cosa fare.
-- _L'entità del cambiamento previsto_. L'agente vende una quantità fissa di `WETH` se si prevede che il prezzo diminuisca, indipendentemente dall'entità del calo.
- Probabilmente, sarebbe meglio ignorare le piccole variazioni e vendere in base a quanto ci aspettiamo che il prezzo diminuisca.
-- _Il portafoglio attuale_. Se il 10% del tuo portafoglio è in WETH e pensi che il prezzo salirà, probabilmente ha senso acquistarne di più. Ma se il 90% del tuo portafoglio è in WETH, potresti essere sufficientemente esposto e non c'è bisogno di acquistarne di più. Il contrario è vero se ti aspetti che il prezzo scenda.
+- _L'entità del cambiamento previsto_. L'agente vende un importo fisso di `WETH` se si prevede che il prezzo diminuirà, indipendentemente dall'entità del calo.
+ Probabilmente, sarebbe meglio ignorare i cambiamenti minori e vendere in base a quanto ci aspettiamo che il prezzo diminuisca.
+- _Il portafoglio attuale_. Se il 10% del tuo portafoglio è in WETH e pensi che il prezzo salirà, probabilmente ha senso comprarne di più. Ma se il 90% del tuo portafoglio è in WETH, potresti essere sufficientemente esposto e non c'è bisogno di comprarne di più. Il contrario è vero se ti aspetti che il prezzo scenda.
### E se volessi mantenere segreta la tua strategia di trading? {#secret}
-I fornitori di IA possono vedere le query che invii ai loro LLM, il che potrebbe esporre il geniale sistema di trading che hai sviluppato con il tuo agente. Un sistema di trading che troppe persone usano è inutile perché troppe persone cercano di comprare quando vuoi comprare tu (e il prezzo sale) e cercano di vendere quando vuoi vendere tu (e il prezzo scende).
+I fornitori di IA possono vedere le query che invii ai loro LLM, il che potrebbe esporre il geniale sistema di trading che hai sviluppato con il tuo agente. Un sistema di trading che troppe persone usano è inutile perché troppe persone cercano di comprare quando tu vuoi comprare (e il prezzo sale) e cercano di vendere quando tu vuoi vendere (e il prezzo scende).
-Puoi eseguire un LLM localmente, ad esempio, utilizzando [LM-Studio](https://lmstudio.ai/), per evitare questo problema.
+Puoi eseguire un LLM localmente, ad esempio, usando [LM-Studio](https://lmstudio.ai/), per evitare questo problema.
### Da bot IA ad agente IA {#bot-to-agent}
-Si può sostenere validamente che questo è [un bot IA, non un agente IA](/ai-agents/#ai-agents-vs-ai-bots). Implementa una strategia relativamente semplice che si basa su informazioni predefinite. Possiamo abilitare l'auto-miglioramento, ad esempio, fornendo un elenco di gruppi di Uniswap v3 e i loro ultimi valori e chiedendo quale combinazione ha il miglior valore predittivo.
+Si può sostenere a ragione che questo sia [un bot IA, non un agente IA](/ai-agents/#ai-agents-vs-ai-bots). Implementa una strategia relativamente semplice che si basa su informazioni predefinite. Possiamo abilitare l'auto-miglioramento, ad esempio, fornendo un elenco di pool Uniswap v3 e i loro ultimi valori e chiedendo quale combinazione abbia il miglior valore predittivo.
### Protezione dallo slippage {#slippage-protection}
-Attualmente non c'è [protezione dallo slippage](https://uniswapv3book.com/milestone_3/slippage-protection.html). Se la quotazione attuale è di 2000 $ e il prezzo previsto è di 2100 $, l'agente comprerà. Tuttavia, se prima che l'agente acquisti il costo sale a 2200 $, non ha più senso comprare.
+Attualmente non c'è [protezione dallo slippage](https://uniswapv3book.com/milestone_3/slippage-protection.html). Se la quotazione attuale è di 2000$ e il prezzo previsto è di 2100$, l'agente comprerà. Tuttavia, se prima che l'agente compri il costo sale a 2200$, non ha più senso comprare.
Per implementare la protezione dallo slippage, specifica un valore `amountOutMinimum` nelle righe 325 e 334 di [`agent.py`](https://github.com/qbzzt/260215-ai-agent/blob/05-trade/agent.py#L325).
## Conclusione {#conclusion}
-Speriamo che ora tu sappia abbastanza per iniziare con gli agenti IA. Questa non è una panoramica completa dell'argomento; ci sono interi libri dedicati a questo, ma questo è sufficiente per iniziare. Buona fortuna!
+Speriamo che ora tu ne sappia abbastanza per iniziare con gli agenti IA. Questa non è una panoramica completa dell'argomento; ci sono interi libri dedicati a questo, ma è sufficiente per iniziare. Buona fortuna!
-[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
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 f754fba4728..560a6b96e20 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,43 +1,40 @@
---
-title: "Salva nella cache quanto vuoi"
-description: Scopri come creare e utilizzare un contratto di memorizzazione nella cache per transazioni rollup più economiche
+title: "Tutto ciò che puoi mettere in cache"
+description: "Impara a creare e utilizzare un contratto di caching per transazioni di rollup più economiche"
author: Ori Pomerantz
-tags:
- - "livello 2"
- - "memorizzazione nella cache"
- - "archiviazione"
+tags: ["livello 2", "caching", "archiviazione", "scalabilità"]
skill: intermediate
-breadcrumb: "Cache per rollup"
+breadcrumb: Caching per i rollup
published: 2022-09-15
lang: it
---
-Utilizzando i rollup, il costo di un byte nella transazione è molto maggiore di quello di uno spazio d'archiviazione. Dunque, ha senso salvare nella cache quante più informazioni possibili sulla catena.
+Quando si utilizzano i rollup, il costo di un byte nella transazione è molto più costoso del costo di uno slot di archiviazione. Pertanto, ha senso memorizzare nella cache quante più informazioni possibili on-chain.
-In questo articolo imparerai come creare e utilizzare un contratto di memorizzazione nella cache, in modo tale che il valore di ogni parametro che è probabile sia utilizzato più volte sarà salvato nella cache e disponibile all'uso (dopo la prima volta), con un numero di byte molto inferiore, e come scrivere il codice fuori catena che utilizza tale cache.
+In questo articolo imparerai come creare e utilizzare un contratto di caching in modo tale che qualsiasi valore di parametro che probabilmente verrà utilizzato più volte venga memorizzato nella cache e reso disponibile per l'uso (dopo la prima volta) con un numero molto inferiore di byte, e come scrivere codice fuori catena che utilizzi questa cache.
-Se desideri saltare l'articolo e visualizzare soltanto il codice sorgente, [lo trovi qui](https://github.com/qbzzt/20220915-all-you-can-cache). Lo stack di sviluppo è [Foundry](https://book.getfoundry.sh/getting-started/installation).
+Se vuoi saltare l'articolo e vedere solo il codice sorgente, [è qui](https://github.com/qbzzt/20220915-all-you-can-cache). Lo stack di sviluppo è [Foundry](https://getfoundry.sh/introduction/installation/).
## Design generale {#overall-design}
-Per semplicità supponiamo che tutti i parametri delle transazioni siano `uint256`, lunghi 32 byte. Quando riceviamo una transazione, analizziamo ogni parametro come segue:
+Per semplicità, supporremo che tutti i parametri della transazione siano `uint256`, lunghi 32 byte. Quando riceviamo una transazione, analizzeremo ogni parametro in questo modo:
-1. Se il primo byte è `0xFF`, prendi i successivi 32 byte come valore di parametro e scrivilo nella cache.
+1. Se il primo byte è `0xFF`, prendi i successivi 32 byte come valore del parametro e scrivilo nella cache.
-2. Se il primo byte è `0xFE`, prendi i successivi 32 byte come valore del parametro e _non_ scriverli nella cache.
+2. Se il primo byte è `0xFE`, prendi i successivi 32 byte come valore del parametro ma _non_ scriverlo nella cache.
-3. Per qualsiasi altro valore, prendi i primi quattro bit come numero di byte aggiuntivi e gli ultimi quattro come i bit più significativi della chiave di cache. Ecco alcuni esempi:
+3. Per qualsiasi altro valore, prendi i primi quattro bit come numero di byte aggiuntivi e gli ultimi quattro bit come bit più significativi della chiave della cache. Ecco alcuni esempi:
- | Byte nei calldata | Chiave della cache |
- |:----------------- | ------------------:|
- | 0x0F | 0x0F |
- | 0x10,0x10 | 0x10 |
- | 0x12,0xAC | 0x02AC |
- | 0x2D,0xEA, 0xD6 | 0x0DEAD6 |
+ | Byte in calldata | Chiave della cache |
+ | :---------------- | --------: |
+ | 0x0F | 0x0F |
+ | 0x10,0x10 | 0x10 |
+ | 0x12,0xAC | 0x02AC |
+ | 0x2D,0xEA, 0xD6 | 0x0DEAD6 |
## Manipolazione della cache {#cache-manipulation}
-La cache è implementata in [`Cache.sol`](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol). Analizziamolo riga per riga.
+La cache è implementata in [`Cache.sol`](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol). Esaminiamola riga per riga.
```solidity
// SPDX-License-Identifier: UNLICENSED
@@ -50,81 +47,81 @@ contract Cache {
bytes1 public constant DONT_CACHE = 0xFE;
```
-Queste costanti sono utilizzate per interpretare i casi speciali in cui forniamo tutte le informazioni e se desideriamo scriverle o no nella cache. Scrivere nella cache richiede due operazioni [`SSTORE`](https://www.evm.codes/#55) negli spazi d'archiviazione precedentemente inutilizzati, al costo di 22100 gas l'uno, quindi lo rendiamo facoltativo.
+Queste costanti sono utilizzate per interpretare i casi speciali in cui forniamo tutte le informazioni e vogliamo che vengano scritte nella cache o meno. Scrivere nella cache richiede due operazioni [`SSTORE`](https://www.evm.codes/#55) in slot di archiviazione precedentemente inutilizzati a un costo di 22100 gas ciascuna, quindi lo rendiamo opzionale.
```solidity
mapping(uint => uint) public val2key;
```
-Una [mappatura](https://www.geeksforgeeks.org/solidity-mappings/) tra i valori e le loro chiavi. Queste informazioni sono necessarie per codificare i valori prima di inviare la transazione.
+Una [mappatura](https://www.geeksforgeeks.org/solidity/solidity-mappings/) tra i valori e le loro chiavi. Questa informazione è necessaria per codificare i valori prima di inviare la transazione.
```solidity
- // Location n has the value for key n+1, because we need to preserve
- // zero as "not in the cache".
+ // La posizione n ha il valore per la chiave n+1, perché dobbiamo preservare
+ // lo zero come "non nella cache".
uint[] public key2val;
```
-Possiamo utilizzare un insieme per la mappatura dalle chiavi ai valori, perché assegniamo le chiavi e, per semplicità, lo facciamo sequenzialmente.
+Possiamo usare un array per la mappatura dalle chiavi ai valori perché assegniamo noi le chiavi e, per semplicità, lo facciamo in modo sequenziale.
```solidity
function cacheRead(uint _key) public view returns (uint) {
require(_key <= key2val.length, "Reading uninitialize cache entry");
return key2val[_key-1];
- } // cacheRead
+ } // cacheRead
```
Legge un valore dalla cache.
```solidity
- // Write a value to the cache if it's not there already
- // Only public to enable the test to work
+ // Scrive un valore nella cache se non è già presente
+ // Pubblico solo per permettere al test di funzionare
function cacheWrite(uint _value) public returns (uint) {
- // If the value is already in the cache, return the current key
+ // Se il valore è già nella cache, restituisce la chiave corrente
if (val2key[_value] != 0) {
return val2key[_value];
}
```
-Non ha senso mettere lo stesso valore nella cache più di una volta. Se il valore è già presente, basta restituire la chiave esistente.
+Non ha senso inserire lo stesso valore nella cache più di una volta. Se il valore è già presente, restituisce semplicemente la chiave esistente.
```solidity
- // Since 0xFE is a special case, the largest key the cache can
- // hold is 0x0D followed by 15 0xFF's. If the cache length is already that
- // large, fail.
- // 1 2 3 4 5 6 7 8 9 A B C D E F
+ // Poiché 0xFE è un caso speciale, la chiave più grande che la cache può
+ // contenere è 0x0D seguito da 15 0xFF. Se la lunghezza della cache è già così
+ // grande, fallisce.
+ // 1 2 3 4 5 6 7 8 9 A B C D E F
require(key2val.length+1 < 0x0DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF,
"cache overflow");
```
-Non penso che otterremo mai una cache così grande (approssimativamente 1,8\*1037 voci, che richiederebbero circa 1027 TB per l'archiviazione). Tuttavia, sono abbastanza anziano da ricordare che ["640 kB saranno sempre sufficienti"](https://quoteinvestigator.com/2011/09/08/640k-enough/). Questo test è molto economico.
+Non credo che avremo mai una cache così grande (circa 1.8\*1037 voci, che richiederebbero circa 1027 TB per l'archiviazione). Tuttavia, sono abbastanza vecchio da ricordare che ["640kB sarebbero sempre stati sufficienti"](https://quoteinvestigator.com/2011/09/08/640k-enough/). Questo test è molto economico.
```solidity
- // Write the value using the next key
+ // Scrive il valore usando la chiave successiva
val2key[_value] = key2val.length+1;
```
-Aggiungi la ricerca inversa (dal valore alla chiave).
+Aggiunge la ricerca inversa (dal valore alla chiave).
```solidity
key2val.push(_value);
```
-Aggiungi la ricerca inversa (dalla chiave al valore). Poiché assegniamo i valori sequenzialmente, possiamo semplicemente aggiungerli dopo il valore dell'ultimo insieme.
+Aggiunge la ricerca in avanti (dalla chiave al valore). Poiché assegniamo i valori in modo sequenziale, possiamo semplicemente aggiungerlo dopo l'ultimo valore dell'array.
```solidity
return key2val.length;
- } // cacheWrite
+ } // cacheWrite
```
-Restituisce la nuova lunghezza di `key2val`, la cella in cui è memorizzato il nuovo valore.
+Restituisce la nuova lunghezza di `key2val`, che è la cella in cui è memorizzato il nuovo valore.
```solidity
function _calldataVal(uint startByte, uint length)
private pure returns (uint)
```
-Questa funzione legge un valore dai calldata di lunghezza arbitraria (fino a 32 byte, le dimensioni delle parole).
+Questa funzione legge un valore dal calldata di lunghezza arbitraria (fino a 32 byte, la dimensione della parola).
```solidity
{
@@ -136,7 +133,7 @@ Questa funzione legge un valore dai calldata di lunghezza arbitraria (fino a 32
"_calldataVal trying to read beyond calldatasize");
```
-Questa funzione è interna, quindi se il resto del codice è scritto correttamente, questi test non sono necessari. Tuttavia, non costano molto, quindi potremmo anche averli.
+Questa funzione è interna, quindi se il resto del codice è scritto correttamente questi test non sono necessari. Tuttavia, non costano molto, quindi tanto vale averli.
```solidity
assembly {
@@ -144,7 +141,7 @@ Questa funzione è interna, quindi se il resto del codice è scritto correttamen
}
```
-Questo codice è in [Yul](https://docs.soliditylang.org/en/v0.8.16/yul.html). Legge un valore di 32 byte dai calldata. Ciò funziona anche se i calldata si fermano prima di `startByte+32`, poiché lo spazio non inizializzato nell'EVM è considerato pari a zero.
+Questo codice è in [Yul](https://docs.soliditylang.org/en/v0.8.16/yul.html). Legge un valore di 32 byte dal calldata. Questo funziona anche se il calldata si ferma prima di `startByte+32` perché lo spazio non inizializzato nell'EVM è considerato pari a zero.
```solidity
_retVal = _retVal >> (256-length*8);
@@ -157,43 +154,43 @@ Non vogliamo necessariamente un valore di 32 byte. Questo elimina i byte in ecce
} // _calldataVal
- // Read a single parameter from the calldata, starting at _fromByte
+ // Legge un singolo parametro dalla calldata, partendo da _fromByte
function _readParam(uint _fromByte) internal
returns (uint _nextByte, uint _parameterValue)
{
```
-Legge un singolo parametro dai calldata. Nota che dobbiamo restituire non soltanto il valore che leggiamo, ma anche la posizione di quello successivo, poiché i parametri possono andare da una lunghezza di 1 byte a 33 byte.
+Legge un singolo parametro dal calldata. Nota che dobbiamo restituire non solo il valore che abbiamo letto, ma anche la posizione del byte successivo perché i parametri possono variare da 1 byte a 33 byte di lunghezza.
```solidity
- // The first byte tells us how to interpret the rest
+ // Il primo byte ci dice come interpretare il resto
uint8 _firstByte;
_firstByte = uint8(_calldataVal(_fromByte, 1));
```
-Solidity prova a ridurre il numero di bug vietando le [conversioni di tipo implicito](https://docs.soliditylang.org/en/v0.8.16/types.html#implicit-conversions) potenzialmente pericolose. Un downgrade, ad esempio da 256 bit a 8 bit, dev'essere esplicito.
+Solidity cerca di ridurre il numero di bug vietando [conversioni di tipo implicite](https://docs.soliditylang.org/en/v0.8.16/types.html#implicit-conversions) potenzialmente pericolose. Un declassamento, ad esempio da 256 bit a 8 bit, deve essere esplicito.
```solidity
- // Read the value, but do not write it to the cache
+ // Legge il valore, ma non lo scrive nella cache
if (_firstByte == uint8(DONT_CACHE))
return(_fromByte+33, _calldataVal(_fromByte+1, 32));
- // Read the value, and write it to the cache
+ // Legge il valore e lo scrive nella cache
if (_firstByte == uint8(INTO_CACHE)) {
uint _param = _calldataVal(_fromByte+1, 32);
cacheWrite(_param);
return(_fromByte+33, _param);
}
- // If we got here it means that we need to read from the cache
+ // Se siamo arrivati qui significa che dobbiamo leggere dalla cache
- // Number of extra bytes to read
+ // Numero di byte extra da leggere
uint8 _extraBytes = _firstByte / 16;
```
-Prendi un [nibble](https://en.wikipedia.org/wiki/Nibble) inferiore e combinalo con altri byte per leggere il valore dalla cache.
+Prende il [nibble](https://en.wikipedia.org/wiki/Nibble) inferiore e lo combina con gli altri byte per leggere il valore dalla cache.
```solidity
uint _key = (uint256(_firstByte & 0x0F) << (8*_extraBytes)) +
@@ -201,20 +198,20 @@ Prendi un [nibble](https://en.wikipedia.org/wiki/Nibble) inferiore e combinalo c
return (_fromByte+_extraBytes+1, cacheRead(_key));
- } // _readParam
+ } // _readParam
- // Read n parameters (functions know how many parameters they expect)
+ // Legge n parametri (le funzioni sanno quanti parametri si aspettano)
function _readParams(uint _paramNum) internal returns (uint[] memory) {
```
-Potremmo ottenere il numero di parametri dagli stessi calldata, ma le funzioni che ci chiamano sanno quanti parametri sono previsti. È più facile lasciarcelo dire.
+Potremmo ottenere il numero di parametri che abbiamo dal calldata stesso, ma le funzioni che ci chiamano sanno quanti parametri si aspettano. È più facile lasciare che ce lo dicano loro.
```solidity
- // The parameters we read
+ // I parametri che leggiamo
uint[] memory params = new uint[](_paramNum);
- // Parameters start at byte 4, before that it's the function signature
+ // I parametri iniziano al byte 4, prima c'è la firma della funzione
uint _atByte = 4;
for(uint i=0; i<_paramNum; i++) {
@@ -222,62 +219,62 @@ Potremmo ottenere il numero di parametri dagli stessi calldata, ma le funzioni c
}
```
-Leggi i parametri finché non ottieni il numero desiderato. Se andiamo oltre la fine dei calldata, `_readParams` ripristinerà la chiamata.
+Legge i parametri finché non hai il numero di cui hai bisogno. Se andiamo oltre la fine del calldata, `_readParams` annullerà la chiamata.
```solidity
return(params);
- } // readParams
+ } // readParams
- // For testing _readParams, test reading four parameters
+ // Per testare _readParams, testa la lettura di quattro parametri
function fourParam() public
returns (uint256,uint256,uint256,uint256)
{
uint[] memory params;
params = _readParams(4);
return (params[0], params[1], params[2], params[3]);
- } // fourParam
+ } // fourParam
```
-Un grande vantaggio di Foundry è che consente la scrittura dei test in Solidity ([vedi Testare la cache di seguito](#testing-the-cache)). Questo semplifica molto i test unitari. Questa è una funzione che legge quattro parametri e li restituisce in modo che il test possa verificare che siano corretti.
+Un grande vantaggio di Foundry è che consente di scrivere test in Solidity ([vedi Testare la cache di seguito](#testing-the-cache)). Questo rende i test unitari molto più semplici. Questa è una funzione che legge quattro parametri e li restituisce in modo che il test possa verificare che fossero corretti.
```solidity
- // Get a value, return bytes that will encode it (using the cache if possible)
+ // Ottiene un valore, restituisce i byte che lo codificheranno (usando la cache se possibile)
function encodeVal(uint _val) public view returns(bytes memory) {
```
-`encodeVal` è una funzione che il codice fuori catena chiama per aiutare a creare calldata che utilizzano la cache. Riceve un singolo valore e restituisce i byte che lo codificano. Questa funzione è una `view`, quindi non richiede una transazione e quando chiamata esternamente non costa alcun gas.
+`encodeVal` è una funzione che il codice fuori catena chiama per aiutare a creare calldata che utilizza la cache. Riceve un singolo valore e restituisce i byte che lo codificano. Questa funzione è una `view`, quindi non richiede una transazione e quando chiamata esternamente non costa alcun gas.
```solidity
uint _key = val2key[_val];
- // The value isn't in the cache yet, add it
+ // Il valore non è ancora nella cache, lo aggiunge
if (_key == 0)
return bytes.concat(INTO_CACHE, bytes32(_val));
```
-Nell'[EVM](/developers/docs/evm/) si presume che tutta l'archiviazione non inizializzata contenga zeri. Quindi se cerchiamo la chiave per un valore assente, otteniaamo uno zero. In quel caso i byte che la codificano sono `INTO_CACHE` (quindi sarà salvato nella cache la prossima volta), seguiti dal valore effettivo.
+Nell'[EVM](/developers/docs/evm/) (macchina virtuale di Ethereum) tutta l'archiviazione non inizializzata si presume sia composta da zeri. Quindi, se cerchiamo la chiave per un valore che non c'è, otteniamo uno zero. In tal caso i byte che lo codificano sono `INTO_CACHE` (in modo che venga memorizzato nella cache la prossima volta), seguiti dal valore effettivo.
```solidity
- // If the key is <0x10, return it as a single byte
+ // Se la chiave è <0x10, la restituisce come singolo byte
if (_key < 0x10)
return bytes.concat(bytes1(uint8(_key)));
```
-I byte singoli sono i più facili. Semplicemente, utilizziamo [`bytes.concat`](https://docs.soliditylang.org/en/v0.8.16/types.html#the-functions-bytes-concat-and-string-concat) per trasformare un tipo `bytes` in un insieme di byte di qualsiasi lunghezza. Nonostante il nome, funziona bene quando fornito con un solo argomento.
+I byte singoli sono i più facili. Usiamo semplicemente [`bytes.concat`](https://docs.soliditylang.org/en/v0.8.16/types.html#the-functions-bytes-concat-and-string-concat) per trasformare un tipo `bytes` in un array di byte che può essere di qualsiasi lunghezza. Nonostante il nome, funziona bene quando viene fornito con un solo argomento.
```solidity
- // Two byte value, encoded as 0x1vvv
+ // Valore a due byte, codificato come 0x1vvv
if (_key < 0x1000)
return bytes.concat(bytes2(uint16(_key) | 0x1000));
```
-Quando abbiamo una chiave inferiore a 163, possiamo esprimerla in due byte. Prima convertiamo `_key`, un valore da 256 bit, in un valore da 16 bit, quindi utilizziamo il logical o aggiungiamo il numero di byte aggiuntivi al primo byte. Quindi abbiamo un valore `bytes2` convertibile in `bytes`.
+Quando abbiamo una chiave inferiore a 163, possiamo esprimerla in due byte. Per prima cosa convertiamo `_key`, che è un valore a 256 bit, in un valore a 16 bit e usiamo l'OR logico per aggiungere il numero di byte extra al primo byte. Quindi lo inseriamo semplicemente in un valore `bytes2`, che può essere convertito in `bytes`.
```solidity
- // There is probably a clever way to do the following lines as a loop,
- // but it's a view function so I'm optimizing for programmer time and
- // simplicity.
+ // Probabilmente c'è un modo intelligente per eseguire le righe seguenti come un ciclo,
+ // ma è una funzione view, quindi sto ottimizzando per il tempo del programmatore e
+ // la semplicità.
if (_key < 16*256**2)
return bytes.concat(bytes3(uint24(_key) | (0x2 * 16 * 256**2)));
@@ -292,24 +289,24 @@ Quando abbiamo una chiave inferiore a 163, possiamo esprimerla in due
return bytes.concat(bytes16(uint128(_key) | (0xF * 16 * 256**15)));
```
-Gli altri valori (3 byte, 4 byte, ecc.) sono gestiti allo stesso modo, ma con dimensioni del campo differenti.
+Gli altri valori (3 byte, 4 byte, ecc.) vengono gestiti allo stesso modo, solo con dimensioni del campo diverse.
```solidity
- // If we get here, something is wrong.
+ // Se arriviamo qui, c'è qualcosa di sbagliato.
revert("Error in encodeVal, should not happen");
```
-Se arriviamo qui significa che abbiamo una chiave non inferiore a 16\*25615. Ma `cacheWrite` limita le chiavi quindi non possiamo arrivare nemmeno fino a 14\*25616 (che avrebbe un primo byte di 0xFE, quindi apparirebbe così: `DONT_CACHE`). Ma aggiungere un test nel caso in cui un programmatore futuro aggiunga un bug non ci costa molto.
+Se arriviamo qui significa che abbiamo ottenuto una chiave che non è inferiore a 16\*25615. Ma `cacheWrite` limita le chiavi, quindi non possiamo nemmeno arrivare a 14\*25616 (che avrebbe un primo byte di 0xFE, quindi sembrerebbe `DONT_CACHE`). Ma non ci costa molto aggiungere un test nel caso in cui un programmatore futuro introduca un bug.
```solidity
} // encodeVal
-} // Cache
+} // Cache
```
### Testare la cache {#testing-the-cache}
-Uno dei vantaggi di Foundry è che [ti consente di scrivere i test in Solidity](https://book.getfoundry.sh/forge/tests), semplificando la scrittura dei test unitari. I test per la classe `Cache` sono [qui](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/Cache.t.sol). Poiché il codice del test è ripetitivo, come tendono a essere i test, questo articolo spiega soltanto le parti interessanti.
+Uno dei vantaggi di Foundry è che [ti permette di scrivere test in Solidity](https://getfoundry.sh/forge/tests/overview/), il che rende più facile scrivere test unitari. I test per la classe `Cache` sono [qui](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/Cache.t.sol). Poiché il codice di test è ripetitivo, come tendono a essere i test, questo articolo spiega solo le parti interessanti.
```solidity
// SPDX-License-Identifier: UNLICENSED
@@ -318,11 +315,11 @@ pragma solidity ^0.8.13;
import "forge-std/Test.sol";
-// Need to run `forge test -vv` for the console.
+// È necessario eseguire `forge test -vv` per la console.
import "forge-std/console.sol";
```
-Questo è solo un modello standard necessario per utilizzare il pacchetto del test e `console.log`.
+Questo è solo codice boilerplate necessario per utilizzare il pacchetto di test e `console.log`.
```solidity
import "src/Cache.sol";
@@ -339,13 +336,13 @@ contract CacheTest is Test {
}
```
-La funzione `setUp` viene chiamata prima di ogni test. In questo caso, creiamo semplicemente una nuova cache, così che i nostri test non si influenzeranno a vicenda.
+La funzione `setUp` viene chiamata prima di ogni test. In questo caso creiamo semplicemente una nuova cache, in modo che i nostri test non si influenzino a vicenda.
```solidity
function testCaching() public {
```
-I test sono funzioni i cui nomi iniziano per `test`. Questa funzione verifica la funzionalità di base della cache, scrivendo i valori e rileggendoli.
+I test sono funzioni i cui nomi iniziano con `test`. Questa funzione controlla la funzionalità di base della cache, scrivendo valori e leggendoli di nuovo.
```solidity
for(uint i=1; i<5000; i++) {
@@ -356,15 +353,15 @@ I test sono funzioni i cui nomi iniziano per `test`. Questa funzione verifica la
assertEq(cache.cacheRead(i), i*i);
```
-Ecco come si esegue il test effettivo, utilizzando le funzioni [`assert...`](https://book.getfoundry.sh/reference/forge-std/std-assertions). In questo caso verifichiamo che il valore scritto sia quello che leggiamo. Possiamo scartare il risultato di `cache.cacheWrite`, poiché sappiamo che le chiavi della cache sono assegnate linearmente.
+Ecco come si esegue il test vero e proprio, utilizzando le [funzioni `assert...`](https://getfoundry.sh/reference/forge-std/std-assertions/). In questo caso, controlliamo che il valore che abbiamo scritto sia quello che abbiamo letto. Possiamo scartare il risultato di `cache.cacheWrite` perché sappiamo che le chiavi della cache vengono assegnate in modo lineare.
```solidity
}
- } // testCaching
+ } // testCaching
- // Cache the same value multiple times, ensure that the key stays
- // the same
+ // Mette in cache lo stesso valore più volte, assicurandosi che la chiave rimanga
+ // la stessa
function testRepeatCaching() public {
for(uint i=1; i<100; i++) {
uint _key1 = cache.cacheWrite(i);
@@ -373,26 +370,26 @@ Ecco come si esegue il test effettivo, utilizzando le funzioni [`assert...`](htt
}
```
-Prima scriviamo ogni valore due volte nella cache e ci assicuriamo che le chiavi siano uguali (a significare che la seconda scrittura non si è verificata realmente).
+Per prima cosa scriviamo ogni valore due volte nella cache e ci assicuriamo che le chiavi siano le stesse (il che significa che la seconda scrittura non è avvenuta realmente).
```solidity
for(uint i=1; i<100; i+=3) {
uint _key = cache.cacheWrite(i);
assertEq(_key, i);
}
- } // testRepeatCaching
+ } // testRepeatCaching
```
-In teoria, potrebbe esserci un bug che non influenza le scritture consecutive nella cache. Quindi qui eseguiamo altre scritture non consecutive e visualizziamo i valori che non sono ancora riscritti.
+In teoria potrebbe esserci un bug che non influisce sulle scritture consecutive nella cache. Quindi qui facciamo alcune scritture che non sono consecutive e vediamo che i valori non vengono comunque riscritti.
```solidity
- // Read a uint from a memory buffer (to make sure we get back the parameters
- // we sent out)
+ // Legge un uint da un buffer di memoria (per assicurarsi di riavere i parametri
+ // che abbiamo inviato)
function toUint256(bytes memory _bytes, uint256 _start) internal pure
returns (uint256)
```
-Legge una parola da 256 bit da un buffer `bytes memory`. Questa funzione di utilità ci consente di verificare che riceviamo i risultati corretti, eseguendo la chiamata a una funzione che utilizza la cache.
+Legge una parola a 256 bit da un buffer `bytes memory`. Questa funzione di utilità ci consente di verificare di ricevere i risultati corretti quando eseguiamo una chiamata di funzione che utilizza la cache.
```solidity
{
@@ -404,31 +401,31 @@ Legge una parola da 256 bit da un buffer `bytes memory`. Questa funzione di util
}
```
-Yul non supporta le strutture di dati oltre `uint256`, quindi quando fai riferimento a strutture di dati più sofisticate, come il buffer di memoria `_bytes`, ne ottieni l'indirizzo. Solidity memorizza i valori di `bytes memory` come una parola da 32 byte contenente la lunghezza, seguita dai byte effettivi, quindi per ottenere il numero di byte `_start`, dobbiamo calcolare `_bytes+32+_start`.
+Yul non supporta strutture dati oltre a `uint256`, quindi quando ti riferisci a una struttura dati più sofisticata, come il buffer di memoria `_bytes`, ottieni l'indirizzo di quella struttura. Solidity memorizza i valori `bytes memory` come una parola di 32 byte che contiene la lunghezza, seguita dai byte effettivi, quindi per ottenere il numero di byte `_start` dobbiamo calcolare `_bytes+32+_start`.
```solidity
return tempUint;
- } // toUint256
+ } // toUint256
- // Function signature for fourParams(), courtesy of
+ // Firma della funzione per fourParams(), per gentile concessione di
// https://www.4byte.directory/signatures/?bytes4_signature=0x3edc1e6d
bytes4 constant FOUR_PARAMS = 0x3edc1e6d;
- // Just some constant values to see we're getting the correct values back
+ // Solo alcuni valori costanti per vedere che stiamo ottenendo indietro i valori corretti
uint256 constant VAL_A = 0xDEAD60A7;
uint256 constant VAL_B = 0xBEEF;
uint256 constant VAL_C = 0x600D;
uint256 constant VAL_D = 0x600D60A7;
```
-Alcune costanti necessarie per il test.
+Alcune costanti di cui abbiamo bisogno per i test.
```solidity
function testReadParam() public {
```
-Chiama `fourParams()`, una funzione che utilizza `readParams` per testare la possibilità di leggere correttamente i parametri.
+Chiama `fourParams()`, una funzione che utilizza `readParams`, per testare che possiamo leggere i parametri correttamente.
```solidity
address _cacheAddr = address(cache);
@@ -437,23 +434,23 @@ Chiama `fourParams()`, una funzione che utilizza `readParams` per testare la pos
bytes memory _callOutput;
```
-Non possiamo utilizzare il normale meccanismo ABI per chiamare una funzione utilizzando la cache, quindi dobbiamo utilizzare il meccanismo di basso livello [`.call()`](https://docs.soliditylang.org/en/v0.8.16/types.html#members-of-addresses). Tale meccanismo prende `bytes memory` come input e lo restituisce (insieme a un valore Booleano) come output.
+Non possiamo usare il normale meccanismo ABI per chiamare una funzione usando la cache, quindi dobbiamo usare il meccanismo di basso livello [`.call()`](https://docs.soliditylang.org/en/v0.8.16/types.html#members-of-addresses). Quel meccanismo accetta un `bytes memory` come input e lo restituisce (insieme a un valore booleano) come output.
```solidity
- // First call, the cache is empty
+ // Prima chiamata, la cache è vuota
_callInput = bytes.concat(
FOUR_PARAMS,
```
-È utile, per lo stesso contratto, supportare sie le funzioni nella cache (per le chiamate direttamente dalle transazioni) che le funzioni non nella cache (per le chiamate da altri contratti intelligenti). Per farlo, dobbiamo continuare ad affidarci al meccanismo di Solidity per chiamare la funzione corretta, invece di mettere tutto in [una funzione di `fallback`](https://docs.soliditylang.org/en/v0.8.16/contracts.html#fallback-function). Farlo semplifica la compositività. Un singolo byte basterebbe per identificare la funzione in gran parte dei casi, quindi stiamo sprecando tre byte (16\*3=48 gas). Tuttavia, al momento della scrittura di questa guida, quei 48 di gas costano 0,07 centesimi, un costo ragionevole del codice più semplice e meno soggetto a bug.
+È utile che lo stesso contratto supporti sia funzioni memorizzate nella cache (per chiamate direttamente dalle transazioni) sia funzioni non memorizzate nella cache (per chiamate da altri contratti intelligenti). Per farlo dobbiamo continuare ad affidarci al meccanismo di Solidity per chiamare la funzione corretta, invece di inserire tutto in [una funzione di `fallback`](https://docs.soliditylang.org/en/v0.8.16/contracts.html#fallback-function). Fare questo rende la componibilità molto più semplice. Un singolo byte sarebbe sufficiente per identificare la funzione nella maggior parte dei casi, quindi stiamo sprecando tre byte (16\*3=48 gas). Tuttavia, mentre scrivo questo, quei 48 gas costano 0,07 centesimi, che è un costo ragionevole per un codice più semplice e meno soggetto a bug.
```solidity
- // First value, add it to the cache
+ // Primo valore, lo aggiunge alla cache
cache.INTO_CACHE(),
bytes32(VAL_A),
```
-Il primo valore: un flag che dice che è un valore completo che necessita di essere scritto nella cache, seguito dai 32 byte del valore. Gli altri tre valori sono simili, ma `VAL_B` non è scritto nella cache e `VAL_C` è sia il terzo che il quarto parametro.
+Il primo valore: un flag che indica che è un valore completo che deve essere scritto nella cache, seguito dai 32 byte del valore. Gli altri tre valori sono simili, tranne per il fatto che `VAL_B` non viene scritto nella cache e `VAL_C` è sia il terzo parametro che il quarto.
```solidity
.
@@ -463,20 +460,20 @@ Il primo valore: un flag che dice che è un valore completo che necessita di ess
(_success, _callOutput) = _cacheAddr.call(_callInput);
```
-Qui è dove chiamiamo effettivamente il contratto `Cache`.
+È qui che chiamiamo effettivamente il contratto `Cache`.
```solidity
assertEq(_success, true);
```
-Ci aspettiamo che la chiamata riesca.
+Ci aspettiamo che la chiamata abbia successo.
```solidity
assertEq(cache.cacheRead(1), VAL_A);
assertEq(cache.cacheRead(2), VAL_C);
```
-Iniziamo con una cache vuota e poi aggiungiamo `VAL_A`, seguito da `VAL_C`. Ci aspetteremmo che la prima abbia la chiave 1 e che la seconda abbia la chiave 2.
+Iniziamo con una cache vuota e poi aggiungiamo `VAL_A` seguito da `VAL_C`. Ci aspetteremmo che il primo abbia la chiave 1 e il secondo abbia 2.
```
assertEq(toUint256(_callOutput,0), VAL_A);
@@ -485,32 +482,32 @@ Iniziamo con una cache vuota e poi aggiungiamo `VAL_A`, seguito da `VAL_C`. Ci a
assertEq(toUint256(_callOutput,96), VAL_C);
```
-Il risultato comprende i quattro parametri. Qui verifichiamo che sia corretto.
+L'output sono i quattro parametri. Qui verifichiamo che sia corretto.
```solidity
- // Second call, we can use the cache
+ // Seconda chiamata, possiamo usare la cache
_callInput = bytes.concat(
FOUR_PARAMS,
- // First value in the Cache
+ // Primo valore nella Cache
bytes1(0x01),
```
-Le chiavi della cache sotto 16 sono composte da un solo byte.
+Le chiavi della cache inferiori a 16 sono di un solo byte.
```solidity
- // Second value, don't add it to the cache
+ // Secondo valore, non lo aggiunge alla cache
cache.DONT_CACHE(),
bytes32(VAL_B),
- // Third and fourth values, same value
+ // Terzo e quarto valore, stesso valore
bytes1(0x02),
bytes1(0x02)
);
.
.
.
- } // testReadParam
+ } // testReadParam
```
I test dopo la chiamata sono identici a quelli dopo la prima chiamata.
@@ -519,7 +516,7 @@ I test dopo la chiamata sono identici a quelli dopo la prima chiamata.
function testEncodeVal() public {
```
-Questa funzione è simile a `testReadParam`, ma, invece di scrivere i parametri esplicitamente, utilizziamo `encodeVal()`.
+Questa funzione è simile a `testReadParam`, tranne per il fatto che invece di scrivere i parametri esplicitamente usiamo `encodeVal()`.
```solidity
.
@@ -536,26 +533,26 @@ Questa funzione è simile a `testReadParam`, ma, invece di scrivere i parametri
.
.
assertEq(_callInput.length, 4+1*4);
- } // testEncodeVal
+ } // testEncodeVal
```
-Il solo test aggiuntivo in `testEncodeVal()` consiste nel verificare che la lunghezza di `_callInput` sia corretta. Per la prima chiamata, è 4+33\*4. Per la seconda, dove ogni valore è già nella cache, è 4+1\*4.
+L'unico test aggiuntivo in `testEncodeVal()` è verificare che la lunghezza di `_callInput` sia corretta. Per la prima chiamata è 4+33\*4. Per la seconda, dove ogni valore è già nella cache, è 4+1\*4.
```solidity
- // Test encodeVal when the key is more than a single byte
- // Maximum three bytes because filling the cache to four bytes takes
- // too long.
+ // Testa encodeVal quando la chiave è più di un singolo byte
+ // Massimo tre byte perché riempire la cache a quattro byte richiede
+ // troppo tempo.
function testEncodeValBig() public {
- // Put a number of values in the cache.
- // To keep things simple, use key n for value n.
+ // Mette un certo numero di valori nella cache.
+ // Per mantenere le cose semplici, usa la chiave n per il valore n.
for(uint i=1; i<0x1FFF; i++) {
cache.cacheWrite(i);
}
```
-La funzione `testEncodeVal` precedente scrive soltanto quattro valori nella cache, quindi [la parte della funzione che si occupa dei valori a più byte](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol#L144-L171) non è controllata. Ma quel codice è complicato e tende ad avere errori.
+La funzione `testEncodeVal` sopra scrive solo quattro valori nella cache, quindi [la parte della funzione che gestisce i valori multi-byte](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/Cache.sol#L144-L171) non viene controllata. Ma quel codice è complicato e soggetto a errori.
-La prima parte di questa funzione è un ciclo che scrive tutti i valori da 1 a 0x1FFF nella cache in ordine, quindi potrai codificarli e sapere cosa sta succedendo.
+La prima parte di questa funzione è un ciclo che scrive tutti i valori da 1 a 0x1FFF nella cache in ordine, in modo da poter codificare quei valori e sapere dove stanno andando.
```solidity
.
@@ -564,28 +561,28 @@ La prima parte di questa funzione è un ciclo che scrive tutti i valori da 1 a 0
_callInput = bytes.concat(
FOUR_PARAMS,
- cache.encodeVal(0x000F), // One byte 0x0F
- cache.encodeVal(0x0010), // Two bytes 0x1010
- cache.encodeVal(0x0100), // Two bytes 0x1100
- cache.encodeVal(0x1000) // Three bytes 0x201000
+ cache.encodeVal(0x000F), // Un byte 0x0F
+ cache.encodeVal(0x0010), // Due byte 0x1010
+ cache.encodeVal(0x0100), // Due byte 0x1100
+ cache.encodeVal(0x1000) // Tre byte 0x201000
);
```
-Testa valori da uno, due e tre byte. Non testiamo oltre tali valori perché ci vorrebbe troppo tempo per scrivere abbastanza elementi dello stack (almeno 0x10000000, approssimativamente, un quarto di miliardo).
+Testa valori di un byte, due byte e tre byte. Non testiamo oltre perché ci vorrebbe troppo tempo per scrivere abbastanza voci nello stack (almeno 0x10000000, circa un quarto di miliardo).
```solidity
.
.
.
.
- } // testEncodeValBig
+ } // testEncodeValBig
- // Test what with an excessively small buffer we get a revert
+ // Testa che con un buffer eccessivamente piccolo otteniamo un revert
function testShortCalldata() public {
```
-Testiamo cosa si verifica nel caso anomalo in cui non ci siano abbastanza parametri.
+Testa cosa succede nel caso anomalo in cui non ci sono abbastanza parametri.
```solidity
.
@@ -593,10 +590,10 @@ Testiamo cosa si verifica nel caso anomalo in cui non ci siano abbastanza parame
.
(_success, _callOutput) = _cacheAddr.call(_callInput);
assertEq(_success, false);
- } // testShortCalldata
+ } // testShortCalldata
```
-Poiché si ripristina, dovremmo ottenere `false`.
+Poiché si annulla, il risultato che dovremmo ottenere è `false`.
```
// Call with cache keys that aren't there
@@ -618,41 +615,41 @@ Poiché si ripristina, dovremmo ottenere `false`.
);
```
-Questa funzione ottiene quattro parametri perfettamente legittimi, ma la cache è vuota, quindi non non sono presenti valori da leggere.
+Questa funzione ottiene quattro parametri perfettamente legittimi, tranne per il fatto che la cache è vuota, quindi non ci sono valori da leggere.
```solidity
.
.
.
- // Test what with an excessively long buffer everything works file
+ // Testa che con un buffer eccessivamente lungo tutto funziona correttamente
function testLongCalldata() public {
address _cacheAddr = address(cache);
bool _success;
bytes memory _callInput;
bytes memory _callOutput;
- // First call, the cache is empty
+ // Prima chiamata, la cache è vuota
_callInput = bytes.concat(
FOUR_PARAMS,
- // First value, add it to the cache
+ // Primo valore, lo aggiunge alla cache
cache.INTO_CACHE(), bytes32(VAL_A),
- // Second value, add it to the cache
+ // Secondo valore, lo aggiunge alla cache
cache.INTO_CACHE(), bytes32(VAL_B),
- // Third value, add it to the cache
+ // Terzo valore, lo aggiunge alla cache
cache.INTO_CACHE(), bytes32(VAL_C),
- // Fourth value, add it to the cache
+ // Quarto valore, lo aggiunge alla cache
cache.INTO_CACHE(), bytes32(VAL_D),
- // And another value for "good luck"
+ // E un altro valore per "buona fortuna"
bytes4(0x31112233)
);
```
-Questa funzione invia cinque valori. Sappiamo che il quinto valore è ignorato perché non è un elemento della cache valido, ma avrebbe causato un ripristino se non fosse stato incluso.
+Questa funzione invia cinque valori. Sappiamo che il quinto valore viene ignorato perché non è una voce di cache valida, il che avrebbe causato un annullamento se non fosse stato incluso.
```solidity
(_success, _callOutput) = _cacheAddr.call(_callInput);
@@ -660,19 +657,19 @@ Questa funzione invia cinque valori. Sappiamo che il quinto valore è ignorato p
.
.
.
- } // testLongCalldata
+ } // testLongCalldata
-} // CacheTest
+} // CacheTest
```
-## Un esempio di applicazione {#a-sample-app}
+## Un'applicazione di esempio {#a-sample-app}
-Scrivere test in Solidity va bene, ma alla fine una dapp deve poter elaborare le richieste dall'esterno della catena per essere utile. Questo articolo dimostra come utilizzare la memorizzazione nella cache in una dapp con `WORM`, che sta per "Write Once, Read Many" (Scrivi una volta, leggi molte volte). Se una chiave non è ancora stata scritta, puoi scriverci un valore. Se la chiave è già scritta, ottieni un ripristino.
+Scrivere test in Solidity va benissimo, ma alla fine della giornata una dApp deve essere in grado di elaborare richieste dall'esterno della catena per essere utile. Questo articolo dimostra come utilizzare il caching in una dApp con `WORM`, che sta per "Write Once, Read Many" (Scrivi una volta, leggi molte). Se una chiave non è ancora stata scritta, puoi scriverci un valore. Se la chiave è già scritta, ottieni un annullamento.
### Il contratto {#the-contract}
-[Questo è il contratto](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/WORM.sol). Per lo più ripete ciò che abbiamo già fatto con `Cache` e `CacheTest`, quindi copriremo soltanto le parti interessanti.
+[Questo è il contratto](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/src/WORM.sol). Ripete per lo più ciò che abbiamo già fatto con `Cache` e `CacheTest`, quindi copriamo solo le parti interessanti.
```solidity
import "./Cache.sol";
@@ -680,38 +677,38 @@ import "./Cache.sol";
contract WORM is Cache {
```
-Il metodo più facile per utilizzare `Cache` è ereditarlo nel proprio contratto.
+Il modo più semplice per usare `Cache` è ereditarlo nel nostro contratto.
```solidity
function writeEntryCached() external {
uint[] memory params = _readParams(2);
writeEntry(params[0], params[1]);
- } // writeEntryCached
+ } // writeEntryCached
```
-Questa funzione è simile a `fourParam` nel precedente `CacheTest`. Poiché non seguiamo le specifiche ABI, è meglio non dichiarare alcun parametro nella funzione.
+Questa funzione è simile a `fourParam` in `CacheTest` sopra. Poiché non seguiamo le specifiche ABI, è meglio non dichiarare alcun parametro nella funzione.
```solidity
- // Make it easier to call us
- // Function signature for writeEntryCached(), courtesy of
+ // Rende più facile chiamarci
+ // Firma della funzione per writeEntryCached(), per gentile concessione di
// https://www.4byte.directory/signatures/?bytes4_signature=0xe4e4f2d3
bytes4 constant public WRITE_ENTRY_CACHED = 0xe4e4f2d3;
```
-Il codice esterno che chiama `writeEntryCached` dovrà creare manualmente i calldata, invece di utilizzare `worm.writeEntryCached`, poiché non seguiamo le specifiche ABI. Avere questo valore costante ne semplifica la scrittura.
+Il codice esterno che chiama `writeEntryCached` dovrà costruire manualmente il calldata, invece di usare `worm.writeEntryCached`, perché non seguiamo le specifiche ABI. Avere questo valore costante rende semplicemente più facile scriverlo.
-Nota che anche se definiamo `WRITE_ENTRY_CACHED` come una variabile di stato, per leggerla esternamente è necessario utilizzare la sua funzione di ottenimento, `worm.WRITE_ENTRY_CACHED()`.
+Nota che anche se definiamo `WRITE_ENTRY_CACHED` come una variabile di stato, per leggerla esternamente è necessario utilizzare la sua funzione getter, `worm.WRITE_ENTRY_CACHED()`.
```solidity
function readEntry(uint key) public view
returns (uint _value, address _writtenBy, uint _writtenAtBlock)
```
-La funzione Leggi è una `view`, quindi non richiede una transazione, né costa gas. Di conseguenza, non vi è beneficio nell'usare la cache per il parametro. Con le funzioni view, è meglio utilizzare il meccanismo standard, che è più semplice.
+La funzione di lettura è una `view`, quindi non richiede una transazione e non costa gas. Di conseguenza, non c'è alcun vantaggio nell'usare la cache per il parametro. Con le funzioni view è meglio usare il meccanismo standard che è più semplice.
-### Il codice di prova {#the-testing-code}
+### Il codice di test {#the-testing-code}
-[Questo è il codice di prova per il contratto](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/WORM.t.sol). Anche in questo caso ci occupiamo soltanto di ciò che ci interessa.
+[Questo è il codice di test per il contratto](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/test/WORM.t.sol). Ancora una volta, guardiamo solo ciò che è interessante.
```solidity
function testWReadWrite() public {
@@ -721,27 +718,27 @@ La funzione Leggi è una `view`, quindi non richiede una transazione, né costa
worm.writeEntry(0xDEAD, 0xBEEF);
```
-[Questo (`vm.expectRevert`)](https://book.getfoundry.sh/cheatcodes/expect-revert#expectrevert) è il modo in cui specifichiamo in un test Foundry che la chiamata successiva dovrebbe non riuscire e il motivo segnalato per l'errore. Questo si applica quando utilizziamo la sintassi `.()`, piuttosto che creare i calldata e chiamare il contratto utilizzando l'interfaccia di basso livello (`.call()`, etc.).
+[Questo (`vm.expectRevert`)](https://book.getfoundry.sh/cheatcodes/expect-revert#expectrevert) è il modo in cui specifichiamo in un test di Foundry che la chiamata successiva dovrebbe fallire, e il motivo riportato per un fallimento. Questo si applica quando usiamo la sintassi `.()` piuttosto che costruire il calldata e chiamare il contratto usando l'interfaccia di basso livello (`.call()`, ecc.).
```solidity
function testReadWriteCached() public {
uint cacheGoat = worm.cacheWrite(0x60A7);
```
-Qui utilizziamo il fatto che `cacheWrite` restituisce la chiave della cache. Questo non è qualcosa che prevediamo di utilizzare in produzione, poiché `cacheWrite` cambia lo stato, ed è quindi chiamabile soltanto durante una transazione. Le transazioni non hanno valori restituiti, se hanno risultati, questi dovrebbero essere emessi come eventi. Quindi, il valore restituito di `cacheWrite` è accessibile soltanto dal codice sulla catena, che non necessita il salvataggio nella cache dei parametri.
+Qui usiamo il fatto che `cacheWrite` restituisce la chiave della cache. Questo non è qualcosa che ci aspetteremmo di usare in produzione, perché `cacheWrite` cambia lo stato, e quindi può essere chiamato solo durante una transazione. Le transazioni non hanno valori di ritorno, se hanno risultati si suppone che quei risultati vengano emessi come eventi. Quindi il valore di ritorno di `cacheWrite` è accessibile solo dal codice on-chain, e il codice on-chain non ha bisogno del caching dei parametri.
```solidity
(_success,) = address(worm).call(_callInput);
```
-Questo è il modo in cui diciamo a Solidity che mentre `.call()` ha due valori restituiti, ci importa soltanto del primo.
+Questo è il modo in cui diciamo a Solidity che mentre `.call()` ha due valori di ritorno, a noi interessa solo il primo.
```solidity
(_success,) = address(worm).call(_callInput);
assertEq(_success, false);
```
-Poiché utilizziamo la funzione di basso livello `.call()`, non possiamo utilizzare `vm.expectRevert()` e dobbiamo guardare al valore di successo booleano, ottenuto dalla chiamata.
+Poiché usiamo la funzione di basso livello `.call()`, non possiamo usare `vm.expectRevert()` e dobbiamo guardare il valore booleano di successo che otteniamo dalla chiamata.
```solidity
event EntryWritten(uint indexed key, uint indexed value);
@@ -757,49 +754,49 @@ Poiché utilizziamo la funzione di basso livello `.call()`, non possiam
(_success,) = address(worm).call(_callInput);
```
-Così, verifichiamo che il codice [emetta un evento correttamente](https://book.getfoundry.sh/cheatcodes/expect-emit), in Foundry.
+Questo è il modo in cui verifichiamo che il codice [emetta un evento correttamente](https://getfoundry.sh/reference/cheatcodes/expect-emit/) in Foundry.
### Il client {#the-client}
-Una cosa che non ottieni con i test in Solidity è il codice in JavaScript che puoi tagliare e incollare nella tua applicazione. Per scrivere quel codice, ho distribuito WORM a [Optimism Goerli](https://community.optimism.io/docs/useful-tools/networks/#optimism-goerli), la nuova rete di prova di [Optimism](https://www.optimism.io/). Si trova all'indirizzo [`0xd34335b1d818cee54e3323d3246bd31d94e6a78a`](https://goerli-optimism.etherscan.io/address/0xd34335b1d818cee54e3323d3246bd31d94e6a78a).
+Una cosa che non ottieni con i test di Solidity è il codice JavaScript che puoi tagliare e incollare nella tua applicazione. Per scrivere quel codice ho distribuito WORM su [Optimism Goerli](https://community.optimism.io/docs/useful-tools/networks/#optimism-goerli), la nuova rete di test di [Optimism](https://www.optimism.io/). Si trova all'indirizzo [`0xd34335b1d818cee54e3323d3246bd31d94e6a78a`](https://goerli-optimism.etherscan.io/address/0xd34335b1d818cee54e3323d3246bd31d94e6a78a).
-[Puoi visualizzare qui il codice in JavaScript per il client](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/javascript/index.js). Per utilizzarlo:
+[Puoi vedere il codice JavaScript per il client qui](https://github.com/qbzzt/20220915-all-you-can-cache/blob/main/javascript/index.js). Per usarlo:
-1. Clona la repository di git:
+1. Clona il repository git:
```sh
git clone https://github.com/qbzzt/20220915-all-you-can-cache.git
- ```
+```
2. Installa i pacchetti necessari:
```sh
cd javascript
yarn
- ```
+```
3. Copia il file di configurazione:
```sh
cp .env.example .env
- ```
+```
4. Modifica `.env` per la tua configurazione:
- | Parametro | Valore |
- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
- | MNEMONIC | La frase mnemonica per un account avente abbastanza ETH da pagare per una transazione. [Puoi ottenere ETH gratuiti per la rete Goerli di Optimism qui](https://optimismfaucet.xyz/). |
- | OPTIMISM_GOERLI_URL | URL per Goerli di Optimism. L'endpoint pubblico, `https://goerli.optimism.io`, è limitato ma sufficiente per ciò che ci occorre qui |
+ | Parametro | Valore |
+ | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+ | MNEMONIC | La frase mnemonica per un account che ha abbastanza ETH per pagare una transazione. [Puoi ottenere ETH gratuiti per la rete Optimism Goerli qui](https://optimismfaucet.xyz/). |
+ | OPTIMISM_GOERLI_URL | URL per Optimism Goerli. L'endpoint pubblico, `https://goerli.optimism.io`, ha un limite di velocità ma è sufficiente per ciò di cui abbiamo bisogno qui |
5. Esegui `index.js`.
```sh
node index.js
- ```
+```
- Questo esempio di applicazione prima scrive una voce nel WORM, mostrando i calldata e un collegamento alla transazione su Etherscan. Poi rilegge quella voce e mostra la chiave che utilizza e i valori nella voce (valore, numero del blocco e autore).
+ Questa applicazione di esempio scrive prima una voce in WORM, visualizzando il calldata e un link alla transazione su Etherscan. Quindi rilegge quella voce e visualizza la chiave che utilizza e i valori nella voce (valore, numero del blocco e autore).
-Gran parte del client è una normale Dapp in JavaScript. Quindi, ancora, analizzeremo soltanto le parti interessanti.
+La maggior parte del client è normale JavaScript per dApp. Quindi, ancora una volta, esamineremo solo le parti interessanti.
```javascript
.
@@ -808,20 +805,20 @@ Gran parte del client è una normale Dapp in JavaScript. Quindi, ancora, analizz
const main = async () => {
const func = await worm.WRITE_ENTRY_CACHED()
- // Need a new key every time
+ // Serve una nuova chiave ogni volta
const key = await worm.encodeVal(Number(new Date()))
```
-Un dato spazio è scrivibile soltanto una volta, quindi utilizziamo la marca oraria per assicurarci di non riutilizzarlo.
+Un determinato slot può essere scritto solo una volta, quindi usiamo il timestamp per assicurarci di non riutilizzare gli slot.
```javascript
const val = await worm.encodeVal("0x600D")
-// Write an entry
+// Scrive una voce
const calldata = func + key.slice(2) + val.slice(2)
```
-Gli ether si aspettano che i dati di chiamata siano una stringa esadecimale, `0x`, seguita da un numero pari di crifre esadecimali. Poiché sia `key` che `val` iniziano con `0x`, dobbiamo rimuovere queste intestazioni.
+Ethers si aspetta che i dati della chiamata siano una stringa esadecimale, `0x` seguita da un numero pari di cifre esadecimali. Poiché sia `key` che `val` iniziano con `0x`, dobbiamo rimuovere quelle intestazioni.
```javascript
const tx = await worm.populateTransaction.writeEntryCached()
@@ -830,39 +827,41 @@ tx.data = calldata
sentTx = await wallet.sendTransaction(tx)
```
-Come con il codice di test di Solidity, non possiamo chiamare normalmente una funzione. Invece, dobbiamo utilizzare un meccanismo di livello inferiore.
+Come con il codice di test di Solidity, non possiamo chiamare normalmente una funzione memorizzata nella cache. Invece, dobbiamo usare un meccanismo di livello inferiore.
```javascript
.
.
.
- // Read the entry just written
- const realKey = '0x' + key.slice(4) // remove the FF flag
+ // Legge la voce appena scritta
+ const realKey = '0x' + key.slice(4) // rimuove il flag FF
const entryRead = await worm.readEntry(realKey)
.
.
.
```
-Per leggere le voci possiamo utilizzare il meccanismo normale. Non serve utilizzare il salvataggio nella cache del parametro con le funzioni `view`.
+Per leggere le voci possiamo usare il meccanismo normale. Non c'è bisogno di usare il caching dei parametri con le funzioni `view`.
-## Conclusioni {#conclusion}
+## Conclusione {#conclusion}
-Il codice in questo articolo è una prova di concetto, lo scopo è rendere l'idea facile da comprendere. Per un sistema pronto alla produzione, potresti voler implementare delle funzionalità aggiuntive:
+Il codice in questo articolo è una prova di concetto, lo scopo è rendere l'idea facile da capire. Per un sistema pronto per la produzione potresti voler implementare alcune funzionalità aggiuntive:
-- Gestisce i valori diversi da `uint256`. Ad esempio, stringhe.
-- Invece di una cache globale, forse, avere una mappatura tra utenti e cache. Utenti differenti utilizzano valori differenti.
-- I valori utilizzati per gli indirizzi sono distinti da quelli utilizzati per altri scopi. Potrebbe avere senso avere una cache separata soltanto per gli indirizzi.
-- Al momento, le chiavi della cache si basano su un algoritmo "il primo che arriva riceve la chiave più piccola". I primi sedici valori sono inviabili come un singolo byte. I 4080 valori successivi sono inviabili come due byte. Il successivo milione approssimativo di valori è in tre byte, ecc. Un sistema di produzione dovrebbe mantenere dei contatori di utilizzo sulle voci della cache e riorganizzarli così che i sedici valori _più comuni_ siano un byte, i successivi 4080 valori più comuni siano due byte, ecc.
+- Gestire valori che non sono `uint256`. Ad esempio, le stringhe.
+- Invece di una cache globale, magari avere una mappatura tra utenti e cache. Utenti diversi usano valori diversi.
+- I valori utilizzati per gli indirizzi sono distinti da quelli utilizzati per altri scopi. Potrebbe avere senso avere una cache separata solo per gli indirizzi.
+- Attualmente, le chiavi della cache si basano su un algoritmo "primo arrivato, chiave più piccola". I primi sedici valori possono essere inviati come un singolo byte. I successivi 4080 valori possono essere inviati come due byte. Il successivo milione circa di valori sono tre byte, ecc. Un sistema di produzione dovrebbe mantenere contatori di utilizzo sulle voci della cache e riorganizzarle in modo che i sedici valori _più comuni_ siano di un byte, i successivi 4080 valori più comuni di due byte, ecc.
Tuttavia, questa è un'operazione potenzialmente pericolosa. Immagina la seguente sequenza di eventi:
- 1. Noam Naive chiama `encodeVal` per codificare l'indirizzo a cui desidera inviare i token. Quell'indirizzo è uno dei primi utilizzati sull'applicazione, quindi il valore codificato è 0x06. Questa è una funzione `view`, non una transazione, quindi si trova tra Noam e il nodo che utilizza, e nessun altro ne è a conoscenza
+ 1. Noam Naive chiama `encodeVal` per codificare l'indirizzo a cui vuole inviare i token. Quell'indirizzo è uno dei primi utilizzati sull'applicazione, quindi il valore codificato è 0x06. Questa è una funzione `view`, non una transazione, quindi è tra Noam e il nodo che utilizza, e nessun altro ne è a conoscenza.
+
+ 2. Owen Owner esegue l'operazione di riordino della cache. Pochissime persone utilizzano effettivamente quell'indirizzo, quindi ora è codificato come 0x201122. A un valore diverso, 1018, viene assegnato 0x06.
- 2. Owen Owner esegue l'operazione di riordinamento della cache. In pochissimi utilizzano realmente quell'indirizzo, quindi è ora codificato come 0x201122. Un valore differente, 1018, è assegnato a 0x06.
+ 3. Noam Naive invia i suoi token a 0x06. Vanno all'indirizzo `0x0000000000000000000000000de0b6b3a7640000`, e poiché nessuno conosce la chiave privata per quell'indirizzo, rimangono semplicemente bloccati lì. Noam _non è felice_.
- 3. Noam Naive invia i suoi token a 0x06. I token arrivano all'indirizzo `0x0000000000000000000000000de0b6b3a7640000` e, poiché nessuno conosce la chiave privata per quell'indirizzo, restano bloccati lì. Noam _non è felice_.
+ Ci sono modi per risolvere questo problema, e il problema correlato delle transazioni che si trovano nella mempool durante il riordino della cache, ma devi esserne consapevole.
- Esistono dei modi per risolvere questo problema e il problema correlato delle transazioni nel mempool durante il riordino della cache, ma devi esserne consapevole.
+Ho dimostrato il caching qui con Optimism, perché sono un dipendente di Optimism e questo è il rollup che conosco meglio. Ma dovrebbe funzionare con qualsiasi rollup che addebita un costo minimo per l'elaborazione interna, in modo che in confronto la scrittura dei dati della transazione su L1 sia la spesa maggiore.
-Qui, ho dimostrato il salvataggio nella cache con Optimism, perché ne sono un dipendente ed è il rollup che conosco meglio. Ma dovrebbe funzionare con qualsiasi rollup che addebiti un costo minimo per l'elaborazione interna, così che, in confronto, scrivere i dati della transazione a L1 sia la spesa maggiore.
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/app-plasma/index.md b/public/content/translations/it/developers/tutorials/app-plasma/index.md
new file mode 100644
index 00000000000..31d82c2ced9
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/app-plasma/index.md
@@ -0,0 +1,1256 @@
+---
+title: Scrivere un plasma specifico per l'app che preserva la privacy
+description: "In questo tutorial, costruiamo una banca semi-segreta per i depositi. La banca è un componente centralizzato; conosce il saldo di ogni utente. Tuttavia, queste informazioni non sono memorizzate on-chain. Invece, la banca pubblica un hash dello stato. Ogni volta che si verifica una transazione, la banca pubblica il nuovo hash, insieme a una prova a conoscenza-zero di avere una transazione firmata che modifica lo stato dell'hash in quello nuovo. Dopo aver letto questo tutorial, capirai non solo come usare le prove a conoscenza-zero, ma anche perché usarle e come farlo in modo sicuro."
+author: Ori Pomerantz
+tags: ["conoscenza-zero", "server", "fuori catena", "privacy"]
+skill: advanced
+breadcrumb: Plasma specifico per l'app
+lang: it
+published: 2025-10-15
+---
+
+## Introduzione {#introduction}
+
+A differenza dei [rollup](/developers/docs/scaling/zk-rollups/), i [plasma](/developers/docs/scaling/plasma) utilizzano la rete principale di Ethereum per l'integrità, ma non per la disponibilità. In questo articolo, scriviamo un'applicazione che si comporta come un plasma, con Ethereum che garantisce l'integrità (nessuna modifica non autorizzata) ma non la disponibilità (un componente centralizzato può bloccarsi e disabilitare l'intero sistema).
+
+L'applicazione che scriviamo qui è una banca che preserva la privacy. Diversi indirizzi hanno account con saldi e possono inviare denaro (ETH) ad altri account. La banca pubblica gli hash dello stato (account e relativi saldi) e delle transazioni, ma mantiene i saldi effettivi fuori catena dove possono rimanere privati.
+
+## Progettazione {#design}
+
+Questo non è un sistema pronto per la produzione, ma uno strumento didattico. Come tale, è scritto con diverse ipotesi semplificative.
+
+- Pool di account fisso. Esiste un numero specifico di account e ogni account appartiene a un indirizzo predeterminato. Questo rende il sistema molto più semplice perché è difficile gestire strutture dati di dimensioni variabili nelle prove a conoscenza-zero. Per un sistema pronto per la produzione, possiamo usare la [radice di Merkle](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) come hash dello stato e fornire prove di Merkle per i saldi richiesti.
+
+- Archiviazione in memoria. In un sistema di produzione, dobbiamo scrivere tutti i saldi degli account su disco per preservarli in caso di riavvio. Qui, va bene se le informazioni vengono semplicemente perse.
+
+- Solo trasferimenti. Un sistema di produzione richiederebbe un modo per depositare asset nella banca e per prelevarli. Ma lo scopo qui è solo illustrare il concetto, quindi questa banca è limitata ai trasferimenti.
+
+### Prove a conoscenza-zero {#zero-knowledge-proofs}
+
+A livello fondamentale, una prova a conoscenza-zero dimostra che il dimostratore conosce alcuni dati, _Datiprivati_ tali che esista una relazione _Relazione_ tra alcuni dati pubblici, _Datipubblici_, e _Datiprivati_. Il verificatore conosce la _Relazione_ e i _Datipubblici_.
+
+Per preservare la privacy, abbiamo bisogno che gli stati e le transazioni siano privati. Ma per garantire l'integrità, abbiamo bisogno che l' [hash crittografico](https://en.wikipedia.org/wiki/Cryptographic_hash_function) degli stati sia pubblico. Per dimostrare alle persone che inviano transazioni che quelle transazioni sono realmente avvenute, dobbiamo anche pubblicare gli hash delle transazioni.
+
+Nella maggior parte dei casi, i _Datiprivati_ sono l'input del programma di prova a conoscenza-zero e i _Datipubblici_ sono l'output.
+
+Questi campi nei _Datiprivati_:
+
+- _Staton_, il vecchio stato
+- _Staton+1_, il nuovo stato
+- _Transazione_, una transazione che passa dal vecchio stato al nuovo. Questa transazione deve includere questi campi:
+ - _Indirizzo di destinazione_ che riceve il trasferimento
+ - _Importo_ trasferito
+ - _Nonce_ per garantire che ogni transazione possa essere elaborata solo una volta.
+ L'indirizzo di origine non deve essere nella transazione, perché può essere recuperato dalla firma.
+- _Firma_, una firma autorizzata a eseguire la transazione. Nel nostro caso, l'unico indirizzo autorizzato a eseguire una transazione è l'indirizzo di origine. Poiché il nostro sistema a conoscenza-zero funziona in questo modo, abbiamo bisogno anche della chiave pubblica dell'account, oltre alla firma di Ethereum.
+
+Questi sono i campi nei _Datipubblici_:
+
+- _Hash(Staton)_ l'hash del vecchio stato
+- _Hash(Staton+1)_ l'hash del nuovo stato
+- _Hash(Transazione)_ l'hash della transazione che cambia lo stato da _Staton_ a _Staton+1_.
+
+La relazione verifica diverse condizioni:
+
+- Gli hash pubblici sono effettivamente gli hash corretti per i campi privati.
+- La transazione, quando applicata al vecchio stato, si traduce nel nuovo stato.
+- La firma proviene dall'indirizzo di origine della transazione.
+
+A causa delle proprietà delle funzioni di hash crittografico, dimostrare queste condizioni è sufficiente per garantire l'integrità.
+
+### Strutture dati {#data-structures}
+
+La struttura dati principale è lo stato mantenuto dal server. Per ogni account, il server tiene traccia del saldo dell'account e di un [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce), utilizzato per prevenire gli [attacchi di replay](https://en.wikipedia.org/wiki/Replay_attack).
+
+### Componenti {#components}
+
+Questo sistema richiede due componenti:
+
+- Il _server_ che riceve le transazioni, le elabora e pubblica gli hash sulla catena insieme alle prove a conoscenza-zero.
+- Un _contratto intelligente_ che memorizza gli hash e verifica le prove a conoscenza-zero per garantire che le transizioni di stato siano legittime.
+
+### Flusso di dati e controllo {#flows}
+
+Questi sono i modi in cui i vari componenti comunicano per trasferire da un account all'altro.
+
+1. Un browser web invia una transazione firmata richiedendo un trasferimento dall'account del firmatario a un account diverso.
+
+2. Il server verifica che la transazione sia valida:
+
+ - Il firmatario ha un account nella banca con un saldo sufficiente.
+ - Il destinatario ha un account nella banca.
+
+3. Il server calcola il nuovo stato sottraendo l'importo trasferito dal saldo del firmatario e aggiungendolo al saldo del destinatario.
+
+4. Il server calcola una prova a conoscenza-zero che il cambiamento di stato è valido.
+
+5. Il server invia a Ethereum una transazione che include:
+
+ - Il nuovo hash dello stato
+ - L'hash della transazione (in modo che il mittente della transazione possa sapere che è stata elaborata)
+ - La prova a conoscenza-zero che dimostra che la transizione al nuovo stato è valida
+
+6. Il contratto intelligente verifica la prova a conoscenza-zero.
+
+7. Se la prova a conoscenza-zero è corretta, il contratto intelligente esegue queste azioni:
+ - Aggiorna l'hash dello stato corrente al nuovo hash dello stato
+ - Emette una voce di registro con il nuovo hash dello stato e l'hash della transazione
+
+### Strumenti {#tools}
+
+Per il codice lato client, useremo [Vite](https://vite.dev/), [React](https://react.dev/), [Viem](https://viem.sh/) e [Wagmi](https://wagmi.sh/). Questi sono strumenti standard del settore; se non hai familiarità con essi, puoi usare [questo tutorial](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/).
+
+La maggior parte del server è scritta in JavaScript usando [Node](https://nodejs.org/en). La parte a conoscenza-zero è scritta in [Noir](https://noir-lang.org/). Abbiamo bisogno della versione `1.0.0-beta.10`, quindi dopo aver [installato Noir come indicato](https://noir-lang.org/docs/getting_started/quick_start), esegui:
+
+```
+noirup -v 1.0.0-beta.10
+```
+
+La blockchain che usiamo è `anvil`, una blockchain di test locale che fa parte di [Foundry](https://getfoundry.sh/introduction/installation).
+
+## Implementazione {#implementation}
+
+Poiché si tratta di un sistema complesso, lo implementeremo in fasi.
+
+### Fase 1 - Conoscenza-zero manuale {#stage-1}
+
+Per la prima fase, firmeremo una transazione nel browser e poi forniremo manualmente le informazioni alla prova a conoscenza-zero. Il codice a conoscenza-zero si aspetta di ottenere quelle informazioni in `server/noir/Prover.toml` (documentato [qui](https://noir-lang.org/docs/getting_started/project_breakdown#provertoml-1)).
+
+Per vederlo in azione:
+
+1. Assicurati di avere [Node](https://nodejs.org/en/download) e [Noir](https://noir-lang.org/install) installati. Preferibilmente, installali su un sistema UNIX come macOS, Linux o [WSL](https://learn.microsoft.com/en-us/windows/wsl/install).
+
+2. Scarica il codice della fase 1 e avvia il server web per servire il codice client.
+
+ ```sh
+ git clone https://github.com/qbzzt/250911-zk-bank.git -b 01-manual-zk
+ cd 250911-zk-bank
+ cd client
+ npm install
+ npm run dev
+```
+
+ Il motivo per cui hai bisogno di un server web qui è che, per prevenire determinati tipi di frode, molti portafogli (come MetaMask) non accettano file serviti direttamente dal disco
+
+3. Apri un browser con un portafoglio.
+
+4. Nel portafoglio, inserisci una nuova frase di recupero. Nota che questo eliminerà la tua frase di recupero esistente, quindi _assicurati di avere un backup_.
+
+ La frase di recupero è `test test test test test test test test test test test junk`, la frase di recupero di test predefinita per anvil.
+
+5. Vai al [codice lato client](http://localhost:5173/).
+
+6. Connettiti al portafoglio e seleziona l'account di destinazione e l'importo.
+
+7. Fai clic su **Sign** (Firma) e firma la transazione.
+
+8. Sotto l'intestazione **Prover.toml**, troverai del testo. Sostituisci `server/noir/Prover.toml` con quel testo.
+
+9. Esegui la prova a conoscenza-zero.
+
+ ```sh
+ cd ../server/noir
+ nargo execute
+```
+
+ L'output dovrebbe essere simile a
+
+ ```
+ ori@CryptoDocGuy:~/noir/250911-zk-bank/server/noir$ nargo execute
+
+ [zkBank] Circuit witness successfully solved
+ [zkBank] Witness saved to target/zkBank.gz
+ [zkBank] Circuit output: (0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b, 0x0cfc0a67cb7308e4e9b254026b54204e34f6c8b041be207e64c5db77d95dd82d, 0x450cf9da6e180d6159290554ae3d8787, 0x6d8bc5a15b9037e52fb59b6b98722a85)
+```
+
+10. Confronta gli ultimi due valori con l'hash che vedi sul browser web per vedere se il messaggio è stato sottoposto ad hash correttamente.
+
+#### `server/noir/Prover.toml` {#server-noir-prover-toml}
+
+[Questo file](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml) mostra il formato delle informazioni previsto da Noir.
+
+```toml
+message="send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 500 finney (milliEth) 0 "
+```
+
+Il messaggio è in formato testo, il che lo rende facile da capire per l'utente (il che è necessario al momento della firma) e da analizzare per il codice Noir. L'importo è quotato in finney per consentire trasferimenti frazionari da un lato, ed essere facilmente leggibile dall'altro. L'ultimo numero è il [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce).
+
+La stringa è lunga 100 caratteri. Le prove a conoscenza-zero non gestiscono bene i dati di dimensioni variabili, quindi è spesso necessario riempire i dati (padding).
+
+```toml
+pubKeyX=["0x83",...,"0x75"]
+pubKeyY=["0x35",...,"0xa5"]
+signature=["0xb1",...,"0x0d"]
+```
+
+Questi tre parametri sono array di byte a dimensione fissa.
+
+```toml
+[[accounts]]
+address="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"
+balance=100_000
+nonce=0
+
+[[accounts]]
+address="0x70997970C51812dc3A010C7d01b50e0d17dc79C8"
+balance=100_000
+nonce=0
+```
+
+Questo è il modo per specificare un array di strutture. Per ogni voce, specifichiamo l'indirizzo, il saldo (in milliETH, noto anche come [finney](https://cryptovalleyjournal.com/glossary/finney/)) e il valore del nonce successivo.
+
+#### `client/src/Transfer.tsx` {#client-src-transfer-tsx}
+
+[Questo file](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/client/src/Transfer.tsx) implementa l'elaborazione lato client e genera il file `server/noir/Prover.toml` (quello che include i parametri a conoscenza-zero).
+
+Ecco la spiegazione delle parti più interessanti.
+
+```tsx
+export default attrs => {
+```
+
+Questa funzione crea il componente React `Transfer`, che altri file possono importare.
+
+```tsx
+ const accounts = [
+ "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
+ "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",
+ "0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC",
+ "0x90F79bf6EB2c4f870365E785982E1f101E93b906",
+ "0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65",
+ ]
+```
+
+Questi sono gli indirizzi degli account, gli indirizzi creati dalla frase di recupero `test ... test junk`. Se vuoi usare i tuoi indirizzi, modifica semplicemente questa definizione.
+
+```tsx
+ const account = useAccount()
+ const wallet = createWalletClient({
+ transport: custom(window.ethereum!)
+ })
+```
+
+Questi [hook di Wagmi](https://wagmi.sh/react/api/hooks) ci permettono di accedere alla libreria [viem](https://viem.sh/) e al portafoglio.
+
+```tsx
+ const message = `send ${toAccount} ${ethAmount*1000} finney (milliEth) ${nonce}`.padEnd(100, " ")
+```
+
+Questo è il messaggio, riempito con spazi. Ogni volta che una delle variabili [`useState`](https://react.dev/reference/react/useState) cambia, il componente viene ridisegnato e `message` viene aggiornato.
+
+```tsx
+ const sign = async () => {
+```
+
+Questa funzione viene chiamata quando l'utente fa clic sul pulsante **Sign**. Il messaggio viene aggiornato automaticamente, ma la firma richiede l'approvazione dell'utente nel portafoglio e non vogliamo chiederla a meno che non sia necessario.
+
+```tsx
+ const signature = await wallet.signMessage({
+ account: fromAccount,
+ message,
+ })
+```
+
+Chiedi al portafoglio di [firmare il messaggio](https://viem.sh/docs/accounts/local/signMessage).
+
+```tsx
+ const hash = hashMessage(message)
+```
+
+Ottieni l'hash del messaggio. È utile fornirlo all'utente per il debug (del codice Noir).
+
+```tsx
+ const pubKey = await recoverPublicKey({
+ hash,
+ signature
+ })
+```
+
+[Ottieni la chiave pubblica](https://viem.sh/docs/utilities/recoverPublicKey). Questo è richiesto per la funzione [`ecrecover` di Noir](https://github.com/colinnielsen/ecrecover-noir).
+
+```tsx
+ setSignature(signature)
+ setHash(hash)
+ setPubKey(pubKey)
+```
+
+Imposta le variabili di stato. In questo modo si ridisegna il componente (dopo l'uscita della funzione `sign`) e si mostrano all'utente i valori aggiornati.
+
+```tsx
+ let proverToml = `
+```
+
+Il testo per `Prover.toml`.
+
+```tsx
+message="${message}"
+
+pubKeyX=${hexToArray(pubKey.slice(4,4+2*32))}
+pubKeyY=${hexToArray(pubKey.slice(4+2*32))}
+```
+
+Viem ci fornisce la chiave pubblica come una stringa esadecimale di 65 byte. Il primo byte è `0x04`, un marcatore di versione. Questo è seguito da 32 byte per la `x` della chiave pubblica e poi 32 byte per la `y` della chiave pubblica.
+
+Tuttavia, Noir si aspetta di ottenere queste informazioni come array di due byte, uno per `x` e uno per `y`. È più facile analizzarlo qui sul client piuttosto che come parte della prova a conoscenza-zero.
+
+Nota che questa è una buona pratica nella conoscenza-zero in generale. Il codice all'interno di una prova a conoscenza-zero è costoso, quindi qualsiasi elaborazione che può essere eseguita al di fuori della prova a conoscenza-zero _dovrebbe_ essere eseguita al di fuori della prova a conoscenza-zero.
+
+```tsx
+signature=${hexToArray(signature.slice(2,-2))}
+```
+
+Anche la firma viene fornita come una stringa esadecimale di 65 byte. Tuttavia, l'ultimo byte è necessario solo per recuperare la chiave pubblica. Poiché la chiave pubblica sarà già fornita al codice Noir, non ne abbiamo bisogno per verificare la firma e il codice Noir non lo richiede.
+
+```tsx
+${accounts.map(accountInProverToml).reduce((a,b) => a+b, "")}
+`
+```
+
+Fornisci gli account.
+
+```tsx
+ setProverToml(proverToml)
+ }
+
+ return (
+ \<>
+ Transfer
+```
+
+Questo è il formato HTML (più precisamente, [JSX](https://react.dev/learn/writing-markup-with-jsx)) del componente.
+
+#### `server/noir/src/main.nr` {#server-noir-src-main-nr}
+
+[Questo file](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/src/main.nr) è il codice a conoscenza-zero effettivo.
+
+```
+use std::hash::pedersen_hash;
+```
+
+L'[hash di Pedersen](https://rya-sge.github.io/access-denied/2024/05/07/pedersen-hash-function/) è fornito con la [libreria standard di Noir](https://noir-lang.org/docs/noir/standard_library/cryptographic_primitives/hashes#pedersen_hash). Le prove a conoscenza-zero usano comunemente questa funzione di hash. È molto più facile da calcolare all'interno dei [circuiti aritmetici](https://rareskills.io/post/arithmetic-circuit) rispetto alle funzioni di hash standard.
+
+```
+use keccak256::keccak256;
+use dep::ecrecover;
+```
+
+Queste due funzioni sono librerie esterne, definite in [`Nargo.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Nargo.toml). Sono esattamente ciò per cui prendono il nome, una funzione che calcola l'[hash keccak256](https://emn178.github.io/online-tools/keccak_256.html) e una funzione che verifica le firme di Ethereum e recupera l'indirizzo Ethereum del firmatario.
+
+```
+global ACCOUNT_NUMBER : u32 = 5;
+```
+
+Noir è ispirato a [Rust](https://www.rust-lang.org/). Le variabili, per impostazione predefinita, sono costanti. È così che definiamo le costanti di configurazione globali. Nello specifico, `ACCOUNT_NUMBER` è il numero di account che memorizziamo.
+
+I tipi di dati denominati `u` sono quel numero di bit, senza segno. Gli unici tipi supportati sono `u8`, `u16`, `u32`, `u64` e `u128`.
+
+```
+global FLAT_ACCOUNT_FIELDS : u32 = 2;
+```
+
+Questa variabile è usata per l'hash di Pedersen degli account, come spiegato di seguito.
+
+```
+global MESSAGE_LENGTH : u32 = 100;
+```
+
+Come spiegato sopra, la lunghezza del messaggio è fissa. È specificata qui.
+
+```
+global ASCII_MESSAGE_LENGTH : [u8; 3] = [0x31, 0x30, 0x30];
+global HASH_BUFFER_SIZE : u32 = 26+3+MESSAGE_LENGTH;
+```
+
+Le [firme EIP-191](https://eips.ethereum.org/EIPS/eip-191) richiedono un buffer con un prefisso di 26 byte, seguito dalla lunghezza del messaggio in ASCII e infine dal messaggio stesso.
+
+```
+struct Account {
+ balance: u128,
+ address: Field,
+ nonce: u32,
+}
+```
+
+Le informazioni che memorizziamo su un account. [`Field`](https://noir-lang.org/docs/noir/concepts/data_types/fields) è un numero, in genere fino a 253 bit, che può essere usato direttamente nel [circuito aritmetico](https://rareskills.io/post/arithmetic-circuit) che implementa la prova a conoscenza-zero. Qui usiamo il `Field` per memorizzare un indirizzo Ethereum a 160 bit.
+
+```
+struct TransferTxn {
+ from: Field,
+ to: Field,
+ amount: u128,
+ nonce: u32
+}
+```
+
+Le informazioni che memorizziamo per una transazione di trasferimento.
+
+```
+fn flatten_account(account: Account) -> [Field; FLAT_ACCOUNT_FIELDS] {
+```
+
+Una definizione di funzione. Il parametro è l'informazione dell'`Account`. Il risultato è un array di variabili `Field`, la cui lunghezza è `FLAT_ACCOUNT_FIELDS`
+
+```
+ let flat = [
+ account.address,
+ ((account.balance << 32) + account.nonce.into()).into(),
+ ];
+```
+
+Il primo valore nell'array è l'indirizzo dell'account. Il secondo include sia il saldo che il nonce. Le chiamate `.into()` cambiano un numero nel tipo di dati che deve essere. `account.nonce` è un valore `u32`, ma per aggiungerlo a `account.balance << 32`, un valore `u128`, deve essere un `u128`. Questo è il primo `.into()`. Il secondo converte il risultato `u128` in un `Field` in modo che si adatti all'array.
+
+```
+ flat
+}
+```
+
+In Noir, le funzioni possono restituire un valore solo alla fine (non c'è un ritorno anticipato). Per specificare il valore di ritorno, lo valuti appena prima della parentesi di chiusura della funzione.
+
+```
+fn flatten_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] {
+```
+
+Questa funzione trasforma l'array degli account in un array `Field`, che può essere usato come input per un hash di Petersen.
+
+```
+ let mut flat: [Field; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER] = [0; FLAT_ACCOUNT_FIELDS*ACCOUNT_NUMBER];
+```
+
+Questo è il modo in cui specifichi una variabile mutabile, cioè _non_ una costante. Le variabili in Noir devono sempre avere un valore, quindi inizializziamo questa variabile a tutti zeri.
+
+```
+ for i in 0..ACCOUNT_NUMBER {
+```
+
+Questo è un ciclo `for`. Nota che i limiti sono costanti. I cicli Noir devono avere i loro limiti noti in fase di compilazione. Il motivo è che i circuiti aritmetici non supportano il controllo del flusso. Durante l'elaborazione di un ciclo `for`, il compilatore inserisce semplicemente il codice al suo interno più volte, una per ogni iterazione.
+
+```
+ let fields = flatten_account(accounts[i]);
+ for j in 0..FLAT_ACCOUNT_FIELDS {
+ flat[i*FLAT_ACCOUNT_FIELDS + j] = fields[j];
+ }
+ }
+
+ flat
+}
+
+fn hash_accounts(accounts: [Account; ACCOUNT_NUMBER]) -> Field {
+ pedersen_hash(flatten_accounts(accounts))
+}
+```
+
+Infine, siamo arrivati alla funzione che esegue l'hash dell'array degli account.
+
+```
+fn find_account(accounts: [Account; ACCOUNT_NUMBER], address: Field) -> u32 {
+ let mut account : u32 = ACCOUNT_NUMBER;
+
+ for i in 0..ACCOUNT_NUMBER {
+ if accounts[i].address == address {
+ account = i;
+ }
+ }
+```
+
+Questa funzione trova l'account con un indirizzo specifico. Questa funzione sarebbe terribilmente inefficiente nel codice standard perché itera su tutti gli account, anche dopo aver trovato l'indirizzo.
+
+Tuttavia, nelle prove a conoscenza-zero, non c'è controllo del flusso. Se abbiamo mai bisogno di controllare una condizione, dobbiamo controllarla ogni volta.
+
+Una cosa simile accade con le istruzioni `if`. L'istruzione `if` nel ciclo sopra è tradotta in queste istruzioni matematiche.
+
+_condizionerisultato = accounts[i].address == address_ // uno se sono uguali, zero altrimenti
+
+_accountnuovo = condizionerisultato\*i + (1-condizionerisultato)\*accountvecchio_
+
+```rust
+ assert (account < ACCOUNT_NUMBER, f"{address} does not have an account");
+
+ account
+}
+```
+
+La funzione [`assert`](https://noir-lang.org/docs/dev/noir/concepts/assert) fa sì che la prova a conoscenza-zero si blocchi se l'asserzione è falsa. In questo caso, se non riusciamo a trovare un account con l'indirizzo pertinente. Per segnalare l'indirizzo, usiamo una [stringa di formato](https://noir-lang.org/docs/noir/concepts/data_types/strings#format-strings).
+
+```rust
+fn apply_transfer_txn(accounts: [Account; ACCOUNT_NUMBER], txn: TransferTxn) -> [Account; ACCOUNT_NUMBER] {
+```
+
+Questa funzione applica una transazione di trasferimento e restituisce il nuovo array di account.
+
+```rust
+ let from = find_account(accounts, txn.from);
+ let to = find_account(accounts, txn.to);
+
+ let (txnFrom, txnAmount, txnNonce, accountNonce) =
+ (txn.from, txn.amount, txn.nonce, accounts[from].nonce);
+```
+
+Non possiamo accedere agli elementi della struttura all'interno di una stringa di formato in Noir, quindi creiamo una copia utilizzabile.
+
+```rust
+ assert (accounts[from].balance >= txn.amount,
+ f"{txnFrom} does not have {txnAmount} finney");
+
+ assert (accounts[from].nonce == txn.nonce,
+ f"Transaction has nonce {txnNonce}, but the account is expected to use {accountNonce}");
+```
+
+Queste sono due condizioni che potrebbero rendere non valida una transazione.
+
+```rust
+ let mut newAccounts = accounts;
+
+ newAccounts[from].balance -= txn.amount;
+ newAccounts[from].nonce += 1;
+ newAccounts[to].balance += txn.amount;
+
+ newAccounts
+}
+```
+
+Crea il nuovo array di account e poi restituiscilo.
+
+```rust
+fn readAddress(messageBytes: [u8; MESSAGE_LENGTH]) -> Field
+```
+
+Questa funzione legge l'indirizzo dal messaggio.
+
+```rust
+{
+ let mut result : Field = 0;
+
+ for i in 7..47 {
+```
+
+L'indirizzo è sempre lungo 20 byte (ovvero 40 cifre esadecimali) e inizia dal carattere #7.
+
+```rust
+ result *= 0x10;
+ if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9
+ result += (messageBytes[i]-48).into();
+ }
+ if messageBytes[i] >= 65 & messageBytes[i] <= 70 { // A-F
+ result += (messageBytes[i]-65+10).into()
+ }
+ if messageBytes[i] >= 97 & messageBytes[i] <= 102 { // a-f
+ result += (messageBytes[i]-97+10).into()
+ }
+ }
+
+ result
+}
+
+fn readAmountAndNonce(messageBytes: [u8; MESSAGE_LENGTH]) -> (u128, u32)
+```
+
+Leggi l'importo e il nonce dal messaggio.
+
+```rust
+{
+ let mut amount : u128 = 0;
+ let mut nonce: u32 = 0;
+ let mut stillReadingAmount: bool = true;
+ let mut lookingForNonce: bool = false;
+ let mut stillReadingNonce: bool = false;
+```
+
+Nel messaggio, il primo numero dopo l'indirizzo è l'importo di finney (ovvero un millesimo di ETH) da trasferire. Il secondo numero è il nonce. Qualsiasi testo tra di loro viene ignorato.
+
+```rust
+ for i in 48..MESSAGE_LENGTH {
+ if messageBytes[i] >= 48 & messageBytes[i] <= 57 { // 0-9
+ let digit = (messageBytes[i]-48);
+
+ if stillReadingAmount {
+ amount = amount*10 + digit.into();
+ }
+
+ if lookingForNonce { // L'abbiamo appena trovato
+ stillReadingNonce = true;
+ lookingForNonce = false;
+ }
+
+ if stillReadingNonce {
+ nonce = nonce*10 + digit.into();
+ }
+ } else {
+ if stillReadingAmount {
+ stillReadingAmount = false;
+ lookingForNonce = true;
+ }
+ if stillReadingNonce {
+ stillReadingNonce = false;
+ }
+ }
+ }
+
+ (amount, nonce)
+}
+```
+
+Restituire una [tupla](https://noir-lang.org/docs/noir/concepts/data_types/tuples) è il modo di Noir per restituire più valori da una funzione.
+
+```rust
+fn readTransferTxn(message: str) -> TransferTxn
+{
+ let mut txn: TransferTxn = TransferTxn { from: 0, to: 0, amount:0, nonce:0 };
+ let messageBytes = message.as_bytes();
+
+ txn.to = readAddress(messageBytes);
+ let (amount, nonce) = readAmountAndNonce(messageBytes);
+ txn.amount = amount;
+ txn.nonce = nonce;
+
+ txn
+}
+```
+
+Questa funzione converte il messaggio in byte, quindi converte gli importi in una `TransferTxn`.
+
+```rust
+// L'equivalente di hashMessage di Viem
+// https://viem.sh/docs/utilities/hashMessage#hashmessage
+fn hashMessage(message: str) -> [u8;32] {
+```
+
+Siamo stati in grado di usare l'hash di Pedersen per gli account perché vengono sottoposti ad hash solo all'interno della prova a conoscenza-zero. Tuttavia, in questo codice dobbiamo controllare la firma del messaggio, che viene generata dal browser. Per farlo, dobbiamo seguire il formato di firma di Ethereum in [EIP 191](https://eips.ethereum.org/EIPS/eip-191). Ciò significa che dobbiamo creare un buffer combinato con un prefisso standard, la lunghezza del messaggio in ASCII e il messaggio stesso, e usare lo standard Ethereum keccak256 per eseguirne l'hash.
+
+```rust
+ // Prefisso ASCII
+ let prefix_bytes = [
+ 0x19, // \x19
+ 0x45, // 'E'
+ 0x74, // 't'
+ 0x68, // 'h'
+ 0x65, // 'e'
+ 0x72, // 'r'
+ 0x65, // 'e'
+ 0x75, // 'u'
+ 0x6D, // 'm'
+ 0x20, // ' '
+ 0x53, // 'S'
+ 0x69, // 'i'
+ 0x67, // 'g'
+ 0x6E, // 'n'
+ 0x65, // 'e'
+ 0x64, // 'd'
+ 0x20, // ' '
+ 0x4D, // 'M'
+ 0x65, // 'e'
+ 0x73, // 's'
+ 0x73, // 's'
+ 0x61, // 'a'
+ 0x67, // 'g'
+ 0x65, // 'e'
+ 0x3A, // ':'
+ 0x0A // '\n'
+ ];
+```
+
+Per evitare casi in cui un'applicazione chiede all'utente di firmare un messaggio che può essere usato come transazione o per qualche altro scopo, l'EIP 191 specifica che tutti i messaggi firmati iniziano con il carattere 0x19 (non un carattere ASCII valido) seguito da `Ethereum Signed Message:` e una nuova riga.
+
+```rust
+ let mut buffer: [u8; HASH_BUFFER_SIZE] = [0u8; HASH_BUFFER_SIZE];
+ for i in 0..26 {
+ buffer[i] = prefix_bytes[i];
+ }
+
+ let messageBytes : [u8; MESSAGE_LENGTH] = message.as_bytes();
+
+ if MESSAGE_LENGTH <= 9 {
+ for i in 0..1 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+1] = messageBytes[i];
+ }
+ }
+
+ if MESSAGE_LENGTH >= 10 & MESSAGE_LENGTH <= 99 {
+ for i in 0..2 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+2] = messageBytes[i];
+ }
+ }
+
+ if MESSAGE_LENGTH >= 100 {
+ for i in 0..3 {
+ buffer[i+26] = ASCII_MESSAGE_LENGTH[i];
+ }
+
+ for i in 0..MESSAGE_LENGTH {
+ buffer[i+26+3] = messageBytes[i];
+ }
+ }
+
+ assert(MESSAGE_LENGTH < 1000, "Messages whose length is over three digits are not supported");
+```
+
+Gestisci lunghezze di messaggio fino a 999 e fallisci se è maggiore. Ho aggiunto questo codice, anche se la lunghezza del messaggio è una costante, perché rende più facile cambiarla. In un sistema di produzione, probabilmente presumeresti semplicemente che `MESSAGE_LENGTH` non cambi per il bene di prestazioni migliori.
+
+```rust
+ keccak256::keccak256(buffer, HASH_BUFFER_SIZE)
+}
+```
+
+Usa la funzione standard di Ethereum `keccak256`.
+
+```rust
+fn signatureToAddressAndHash(
+ message: str,
+ pubKeyX: [u8; 32],
+ pubKeyY: [u8; 32],
+ signature: [u8; 64]
+ ) -> (Field, Field, Field) // indirizzo, primi 16 byte dell'hash, ultimi 16 byte dell'hash
+{
+```
+
+Questa funzione verifica la firma, che richiede l'hash del messaggio. Ci fornisce quindi l'indirizzo che l'ha firmato e l'hash del messaggio. L'hash del messaggio è fornito in due valori `Field` perché sono più facili da usare nel resto del programma rispetto a un array di byte.
+
+Dobbiamo usare due valori `Field` perché i calcoli dei campi vengono eseguiti [modulo](https://en.wikipedia.org/wiki/Modulo) un numero grande, ma quel numero è in genere inferiore a 256 bit (altrimenti sarebbe difficile eseguire quei calcoli nella EVM).
+
+```rust
+ let hash = hashMessage(message);
+
+ let mut (hash1, hash2) = (0,0);
+
+ for i in 0..16 {
+ hash1 = hash1*256 + hash[31-i].into();
+ hash2 = hash2*256 + hash[15-i].into();
+ }
+```
+
+Specifica `hash1` e `hash2` come variabili mutabili e scrivi l'hash in esse byte per byte.
+
+```rust
+ (
+ ecrecover::ecrecover(pubKeyX, pubKeyY, signature, hash),
+```
+
+Questo è simile a [`ecrecover` di Solidity](https://docs.soliditylang.org/en/v0.8.30/cheatsheet.html#mathematical-and-cryptographic-functions), con due importanti differenze:
+
+- Se la firma non è valida, la chiamata fallisce un `assert` e il programma viene interrotto.
+- Sebbene la chiave pubblica possa essere recuperata dalla firma e dall'hash, questa è un'elaborazione che può essere eseguita esternamente e, pertanto, non vale la pena farla all'interno della prova a conoscenza-zero. Se qualcuno cerca di imbrogliarci qui, la verifica della firma fallirà.
+
+```rust
+ hash1,
+ hash2
+ )
+}
+
+fn main(
+ accounts: [Account; ACCOUNT_NUMBER],
+ message: str,
+ pubKeyX: [u8; 32],
+ pubKeyY: [u8; 32],
+ signature: [u8; 64],
+ ) -> pub (
+ Field, // Hash dell'array dei vecchi account
+ Field, // Hash dell'array dei nuovi account
+ Field, // Primi 16 byte dell'hash del messaggio
+ Field, // Ultimi 16 byte dell'hash del messaggio
+ )
+```
+
+Infine, raggiungiamo la funzione `main`. Dobbiamo dimostrare di avere una transazione che modifica validamente l'hash degli account dal vecchio valore a quello nuovo. Dobbiamo anche dimostrare che ha questo specifico hash della transazione in modo che la persona che l'ha inviata sappia che la sua transazione è stata elaborata.
+
+```rust
+{
+ let mut txn = readTransferTxn(message);
+```
+
+Abbiamo bisogno che `txn` sia mutabile perché non leggiamo l'indirizzo del mittente dal messaggio, lo leggiamo dalla firma.
+
+```rust
+ let (fromAddress, txnHash1, txnHash2) = signatureToAddressAndHash(
+ message,
+ pubKeyX,
+ pubKeyY,
+ signature);
+
+ txn.from = fromAddress;
+
+ let newAccounts = apply_transfer_txn(accounts, txn);
+
+ (
+ hash_accounts(accounts),
+ hash_accounts(newAccounts),
+ txnHash1,
+ txnHash2
+ )
+}
+```
+
+### Fase 2 - Aggiunta di un server {#stage-2}
+
+Nella seconda fase, aggiungiamo un server che riceve e implementa le transazioni di trasferimento dal browser.
+
+Per vederlo in azione:
+
+1. Ferma Vite se è in esecuzione.
+
+2. Scarica il ramo che include il server e assicurati di avere tutti i moduli necessari.
+
+ ```sh
+ git checkout 02-add-server
+ cd client
+ npm install
+ cd ../server
+ npm install
+```
+
+ Non c'è bisogno di compilare il codice Noir, è lo stesso codice che hai usato per la fase 1.
+
+3. Avvia il server.
+
+ ```sh
+ npm run start
+```
+
+4. In una finestra della riga di comando separata, esegui Vite per servire il codice del browser.
+
+ ```sh
+ cd client
+ npm run dev
+```
+
+5. Vai al codice client su [http://localhost:5173](http://localhost:5173)
+
+6. Prima di poter emettere una transazione, devi conoscere il nonce, così come l'importo che puoi inviare. Per ottenere queste informazioni, fai clic su **Update account data** (Aggiorna dati account) e firma il messaggio.
+
+ Abbiamo un dilemma qui. Da un lato, non vogliamo firmare un messaggio che può essere riutilizzato (un [attacco di replay](https://en.wikipedia.org/wiki/Replay_attack)), motivo per cui vogliamo un nonce in primo luogo. Tuttavia, non abbiamo ancora un nonce. La soluzione è scegliere un nonce che può essere usato solo una volta e che abbiamo già su entrambi i lati, come l'ora corrente.
+
+ Il problema con questa soluzione è che l'ora potrebbe non essere perfettamente sincronizzata. Quindi, invece, firmiamo un valore che cambia ogni minuto. Ciò significa che la nostra finestra di vulnerabilità agli attacchi di replay è al massimo di un minuto. Considerando che in produzione la richiesta firmata sarà protetta da TLS e che l'altro lato del tunnel---il server---può già rivelare il saldo e il nonce (deve conoscerli per funzionare), questo è un rischio accettabile.
+
+7. Una volta che il browser riceve indietro il saldo e il nonce, mostra il modulo di trasferimento. Seleziona l'indirizzo di destinazione e l'importo e fai clic su **Transfer** (Trasferisci). Firma questa richiesta.
+
+8. Per vedere il trasferimento, fai clic su **Update account data** o guarda nella finestra in cui esegui il server. Il server registra lo stato ogni volta che cambia.
+
+ ```
+ ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start
+
+ > server@1.0.0 start
+ > node --experimental-json-modules index.mjs
+
+ Listening on port 3000
+ Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 36000 finney (milliEth) 0 processed
+ New state:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 64000 (1)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 100000 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0)
+ Txn send 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 7200 finney (milliEth) 1 processed
+ New state:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 56800 (2)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 136000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0)
+ Txn send 0x90F79bf6EB2c4f870365E785982E1f101E93b906 3000 finney (milliEth) 2 processed
+ New state:
+ 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 has 53800 (3)
+ 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 has 107200 (0)
+ 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC has 100000 (0)
+ 0x90F79bf6EB2c4f870365E785982E1f101E93b906 has 139000 (0)
+ 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 has 100000 (0)
+```
+
+#### `server/index.mjs` {#server-index-mjs-1}
+
+[Questo file](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/index.mjs) contiene il processo del server e interagisce con il codice Noir in [`main.nr`](https://github.com/qbzzt/250911-zk-bank/blob/02-add-server/server/noir/src/main.nr). Ecco una spiegazione delle parti interessanti.
+
+```js
+import { Noir } from '@noir-lang/noir_js'
+```
+
+La libreria [noir.js](https://www.npmjs.com/package/@noir-lang/noir_js) fa da interfaccia tra il codice JavaScript e il codice Noir.
+
+```js
+const circuit = JSON.parse(await fs.readFile("./noir/target/zkBank.json"))
+const noir = new Noir(circuit)
+```
+
+Carica il circuito aritmetico---il programma Noir compilato che abbiamo creato nella fase precedente---e preparati a eseguirlo.
+
+```js
+// Forniamo informazioni sull'account solo in risposta a una richiesta firmata
+const accountInformation = async signature => {
+ const fromAddress = await recoverAddress({
+ hash: hashMessage("Get account data " + Math.floor((new Date().getTime())/60000)),
+ signature
+ })
+```
+
+Per fornire le informazioni sull'account, abbiamo bisogno solo della firma. Il motivo è che sappiamo già quale sarà il messaggio e quindi l'hash del messaggio.
+
+```js
+const processMessage = async (message, signature) => {
+```
+
+Elabora un messaggio ed esegui la transazione che codifica.
+
+```js
+ // Ottieni la chiave pubblica
+ const pubKey = await recoverPublicKey({
+ hash,
+ signature
+ })
+```
+
+Ora che eseguiamo JavaScript sul server, possiamo recuperare la chiave pubblica lì piuttosto che sul client.
+
+```js
+ let noirResult
+ try {
+ noirResult = await noir.execute({
+ message,
+ signature: signature.slice(2,-2).match(/.{2}/g).map(x => `0x${x}`),
+ pubKeyX,
+ pubKeyY,
+ accounts: Accounts
+ })
+```
+
+`noir.execute` esegue il programma Noir. I parametri sono equivalenti a quelli forniti in [`Prover.toml`](https://github.com/qbzzt/250911-zk-bank/blob/01-manual-zk/server/noir/Prover.toml). Nota che i valori lunghi sono forniti come un array di stringhe esadecimali (`["0x60", "0xA7"]`), non come un singolo valore esadecimale (`0x60A7`), nel modo in cui lo fa Viem.
+
+```js
+ } catch (err) {
+ console.log(`Noir error: ${err}`)
+ throw Error("Invalid transaction, not processed")
+ }
+```
+
+Se c'è un errore, catturalo e poi trasmetti una versione semplificata al client.
+
+```js
+ Accounts[fromAccountNumber].nonce++
+ Accounts[fromAccountNumber].balance -= amount
+ Accounts[toAccountNumber].balance += amount
+```
+
+Applica la transazione. Lo abbiamo già fatto nel codice Noir, ma è più facile farlo di nuovo qui piuttosto che estrarre il risultato da lì.
+
+```js
+let Accounts = [
+ {
+ address: "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
+ balance: 5000,
+ nonce: 0,
+ },
+```
+
+La struttura iniziale di `Accounts`.
+
+### Fase 3 - Contratti intelligenti di Ethereum {#stage-3}
+
+1. Ferma i processi del server e del client.
+
+2. Scarica il ramo con i contratti intelligenti e assicurati di avere tutti i moduli necessari.
+
+ ```sh
+ git checkout 03-smart-contracts
+ cd client
+ npm install
+ cd ../server
+ npm install
+```
+
+3. Esegui `anvil` in una finestra della riga di comando separata.
+
+4. Genera la chiave di verifica e il verificatore solidity, quindi copia il codice del verificatore nel progetto Solidity.
+
+ ```sh
+ cd noir
+ bb write_vk -b ./target/zkBank.json -o ./target --oracle_hash keccak
+ bb write_solidity_verifier -k ./target/vk -o ./target/Verifier.sol
+ cp target/Verifier.sol ../../smart-contracts/src
+```
+
+5. Vai ai contratti intelligenti e imposta le variabili d'ambiente per usare la blockchain `anvil`.
+
+ ```sh
+ cd ../../smart-contracts
+ export ETH_RPC_URL=http://localhost:8545
+ ETH_PRIVATE_KEY=ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
+```
+
+6. Distribuisci `Verifier.sol` e memorizza l'indirizzo in una variabile d'ambiente.
+
+ ```sh
+ VERIFIER_ADDRESS=`forge create src/Verifier.sol:HonkVerifier --private-key $ETH_PRIVATE_KEY --optimize --broadcast | awk '/Deployed to:/ {print $3}'`
+ echo $VERIFIER_ADDRESS
+```
+
+7. Distribuisci il contratto `ZkBank`.
+
+ ```sh
+ ZKBANK_ADDRESS=`forge create ZkBank --private-key $ETH_PRIVATE_KEY --broadcast --constructor-args $VERIFIER_ADDRESS 0x199aa62af8c1d562a6ec96e66347bf3240ab2afb5d022c895e6bf6a5e617167b | awk '/Deployed to:/ {print $3}'`
+ echo $ZKBANK_ADDRESS
+```
+
+ Il valore `0x199..67b` è l'hash di Pederson dello stato iniziale di `Accounts`. Se modifichi questo stato iniziale in `server/index.mjs`, puoi eseguire una transazione per vedere l'hash iniziale riportato dalla prova a conoscenza-zero.
+
+8. Avvia il server.
+
+ ```sh
+ cd ../server
+ npm run start
+```
+
+9. Esegui il client in una finestra della riga di comando diversa.
+
+ ```sh
+ cd client
+ npm run dev
+```
+
+10. Esegui alcune transazioni.
+
+11. Per verificare che lo stato sia cambiato on-chain, riavvia il processo del server. Vedi che `ZkBank` non accetta più transazioni, perché il valore hash originale nelle transazioni differisce dal valore hash memorizzato on-chain.
+
+ Questo è il tipo di errore previsto.
+
+ ```
+ ori@CryptoDocGuy:~/x/250911-zk-bank/server$ npm run start
+
+ > server@1.0.0 start
+ > node --experimental-json-modules index.mjs
+
+ Listening on port 3000
+ Verification error: ContractFunctionExecutionError: The contract function "processTransaction" reverted with the following reason:
+ Wrong old state hash
+
+ Contract Call:
+ address: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
+ function: processTransaction(bytes _proof, bytes32[] _publicInputs)
+ args: (0x0000000000000000000000000000000000000000000000042ab5d6d1986846cf00000000000000000000000000000000000000000000000b75c020998797da7800000000000000000000000000000000000000000000000
+```
+
+#### `server/index.mjs` {#server-index-mjs-2}
+
+Le modifiche in questo file riguardano principalmente la creazione della prova effettiva e il suo invio on-chain.
+
+```js
+import { exec } from 'child_process'
+import util from 'util'
+
+const execPromise = util.promisify(exec)
+```
+
+Dobbiamo usare [il pacchetto Barretenberg](https://github.com/AztecProtocol/aztec-packages/tree/next/barretenberg) per creare la prova effettiva da inviare on-chain. Possiamo usare questo pacchetto eseguendo l'interfaccia a riga di comando (`bb`) o usando la [libreria JavaScript, `bb.js`](https://www.npmjs.com/package/@aztec/bb.js). La libreria JavaScript è molto più lenta dell'esecuzione nativa del codice, quindi usiamo [`exec`](https://nodejs.org/api/child_process.html#child_processexeccommand-options-callback) qui per usare la riga di comando.
+
+Nota che se decidi di usare `bb.js`, devi usare una versione compatibile con la versione di Noir che stai usando. Al momento della stesura, la versione attuale di Noir (1.0.0-beta.11) usa la versione 0.87 di `bb.js`.
+
+```js
+const zkBankAddress = process.env.ZKBANK_ADDRESS || "0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512"
+```
+
+L'indirizzo qui è quello che ottieni quando inizi con un `anvil` pulito e segui le indicazioni sopra.
+
+```js
+const walletClient = createWalletClient({
+ chain: anvil,
+ transport: http(),
+ account: privateKeyToAccount("0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6")
+})
+```
+
+Questa chiave privata è uno degli account pre-finanziati predefiniti in `anvil`.
+
+```js
+const generateProof = async (witness, fileID) => {
+```
+
+Genera una prova usando l'eseguibile `bb`.
+
+```js
+ const fname = `witness-${fileID}.gz`
+ await fs.writeFile(fname, witness)
+```
+
+Scrivi il testimone (witness) in un file.
+
+```js
+ await execPromise(`bb prove -b ./noir/target/zkBank.json -w ${fname} -o ${fileID} --oracle_hash keccak --output_format fields`)
+```
+
+Crea effettivamente la prova. Questo passaggio crea anche un file con le variabili pubbliche, ma non ne abbiamo bisogno. Abbiamo già ottenuto quelle variabili da `noir.execute`.
+
+```js
+ const proof = "0x" + JSON.parse(await fs.readFile(`./${fileID}/proof_fields.json`)).reduce((a,b) => a+b, "").replace(/0x/g, "")
+```
+
+La prova è un array JSON di valori `Field`, ciascuno rappresentato come un valore esadecimale. Tuttavia, dobbiamo inviarlo nella transazione come un singolo valore `bytes`, che Viem rappresenta con una grande stringa esadecimale. Qui cambiamo il formato concatenando tutti i valori, rimuovendo tutti gli `0x` e poi aggiungendone uno alla fine.
+
+```js
+ await execPromise(`rm -r ${fname} ${fileID}`)
+
+ return proof
+}
+```
+
+Pulisci e restituisci la prova.
+
+```js
+const processMessage = async (message, signature) => {
+ .
+ .
+ .
+
+ const publicFields = noirResult.returnValue.map(x=>'0x' + x.slice(2).padStart(64, "0"))
+```
+
+I campi pubblici devono essere un array di valori a 32 byte. Tuttavia, poiché dovevamo dividere l'hash della transazione tra due valori `Field`, appare come un valore a 16 byte. Qui aggiungiamo zeri in modo che Viem capisca che in realtà sono 32 byte.
+
+```js
+ const proof = await generateProof(noirResult.witness, `${fromAddress}-${nonce}`)
+```
+
+Ogni indirizzo usa ogni nonce solo una volta in modo da poter usare una combinazione di `fromAddress` e `nonce` come identificatore univoco per il file del testimone e la directory di output.
+
+```js
+ try {
+ await zkBank.write.processTransaction([
+ proof, publicFields])
+ } catch (err) {
+ console.log(`Verification error: ${err}`)
+ throw Error("Can't verify the transaction onchain")
+ }
+ .
+ .
+ .
+}
+```
+
+Invia la transazione alla catena.
+
+#### `smart-contracts/src/ZkBank.sol` {#smart-contracts-src-zkbank-sol}
+
+Questo è il codice on-chain che riceve la transazione.
+
+```solidity
+// SPDX-License-Identifier: MIT
+
+pragma solidity >=0.8.21;
+
+import {HonkVerifier} from "./Verifier.sol";
+
+contract ZkBank {
+ HonkVerifier immutable myVerifier;
+ bytes32 currentStateHash;
+
+ constructor(address _verifierAddress, bytes32 _initialStateHash) {
+ currentStateHash = _initialStateHash;
+ myVerifier = HonkVerifier(_verifierAddress);
+ }
+```
+
+Il codice on-chain deve tenere traccia di due variabili: il verificatore (un contratto separato che viene creato da `nargo`) e l'hash dello stato corrente.
+
+```solidity
+ event TransactionProcessed(
+ bytes32 indexed transactionHash,
+ bytes32 oldStateHash,
+ bytes32 newStateHash
+ );
+```
+
+Ogni volta che lo stato cambia, emettiamo un evento `TransactionProcessed`.
+
+```solidity
+ function processTransaction(
+ bytes calldata _proof,
+ bytes32[] calldata _publicFields
+ ) public {
+```
+
+Questa funzione elabora le transazioni. Ottiene la prova (come `bytes`) e gli input pubblici (come un array `bytes32`), nel formato richiesto dal verificatore (per ridurre al minimo l'elaborazione on-chain e quindi i costi del gas).
+
+```solidity
+ require(_publicInputs[0] == currentStateHash,
+ "Wrong old state hash");
+```
+
+La prova a conoscenza-zero deve dimostrare che la transazione cambia dal nostro hash corrente a uno nuovo.
+
+```solidity
+ myVerifier.verify(_proof, _publicFields);
+```
+
+Chiama il contratto del verificatore per verificare la prova a conoscenza-zero. Questo passaggio annulla la transazione se la prova a conoscenza-zero è sbagliata.
+
+```solidity
+ currentStateHash = _publicFields[1];
+
+ emit TransactionProcessed(
+ _publicFields[2]<<128 | _publicFields[3],
+ _publicFields[0],
+ _publicFields[1]
+ );
+ }
+}
+```
+
+Se tutto è corretto, aggiorna l'hash dello stato al nuovo valore ed emetti un evento `TransactionProcessed`.
+
+## Abusi da parte del componente centralizzato {#abuses}
+
+La sicurezza delle informazioni è costituita da tre attributi:
+
+- _Riservatezza_, gli utenti non possono leggere informazioni che non sono autorizzati a leggere.
+- _Integrità_, le informazioni non possono essere modificate se non da utenti autorizzati in modo autorizzato.
+- _Disponibilità_, gli utenti autorizzati possono usare il sistema.
+
+Su questo sistema, l'integrità è fornita attraverso prove a conoscenza-zero. La disponibilità è molto più difficile da garantire e la riservatezza è impossibile, perché la banca deve conoscere il saldo di ogni account e tutte le transazioni. Non c'è modo di impedire a un'entità che possiede informazioni di condividere tali informazioni.
+
+Potrebbe essere possibile creare una banca veramente riservata usando [indirizzi stealth](https://vitalik.eth.limo/general/2023/01/20/stealth.html), ma questo va oltre lo scopo di questo articolo.
+
+### Informazioni false {#false-info}
+
+Un modo in cui il server può violare l'integrità è fornire informazioni false quando [vengono richiesti i dati](https://github.com/qbzzt/250911-zk-bank/blob/03-smart-contracts/server/index.mjs#L278-L291).
+
+Per risolvere questo problema, possiamo scrivere un secondo programma Noir che riceve gli account come input privato e l'indirizzo per il quale vengono richieste le informazioni come input pubblico. L'output è il saldo e il nonce di quell'indirizzo e l'hash degli account.
+
+Naturalmente, questa prova non può essere verificata on-chain, perché non vogliamo pubblicare nonce e saldi on-chain. Tuttavia, può essere verificata dal codice client in esecuzione nel browser.
+
+### Transazioni forzate {#forced-txns}
+
+Il meccanismo abituale per garantire la disponibilità e prevenire la censura sui L2 sono le [transazioni forzate](https://docs.optimism.io/stack/transactions/forced-transaction). Ma le transazioni forzate non si combinano con le prove a conoscenza-zero. Il server è l'unica entità che può verificare le transazioni.
+
+Possiamo modificare `smart-contracts/src/ZkBank.sol` per accettare transazioni forzate e impedire al server di cambiare lo stato finché non vengono elaborate. Tuttavia, questo ci espone a un semplice attacco denial-of-service. E se una transazione forzata non fosse valida e quindi impossibile da elaborare?
+
+La soluzione è avere una prova a conoscenza-zero che una transazione forzata non è valida. Questo dà al server tre opzioni:
+
+- Elaborare la transazione forzata, fornendo una prova a conoscenza-zero che è stata elaborata e il nuovo hash dello stato.
+- Rifiutare la transazione forzata e fornire una prova a conoscenza-zero al contratto che la transazione non è valida (indirizzo sconosciuto, nonce errato o saldo insufficiente).
+- Ignorare la transazione forzata. Non c'è modo di forzare il server a elaborare effettivamente la transazione, ma significa che l'intero sistema non è disponibile.
+
+#### Vincoli di disponibilità {#avail-bonds}
+
+In un'implementazione reale, ci sarebbe probabilmente un qualche tipo di motivo di profitto per mantenere il server in esecuzione. Possiamo rafforzare questo incentivo facendo in modo che il server pubblichi un vincolo di disponibilità che chiunque può bruciare se una transazione forzata non viene elaborata entro un certo periodo.
+
+### Codice Noir errato {#bad-noir-code}
+
+Normalmente, per far sì che le persone si fidino di un contratto intelligente, carichiamo il codice sorgente su un [esploratore di blocchi](https://eth.blockscout.com/address/0x7D16d2c4e96BCFC8f815E15b771aC847EcbDB48b?tab=contract). Tuttavia, nel caso delle prove a conoscenza-zero, ciò è insufficiente.
+
+`Verifier.sol` contiene la chiave di verifica, che è una funzione del programma Noir. Tuttavia, quella chiave non ci dice quale fosse il programma Noir. Per avere effettivamente una soluzione fidata, devi caricare il programma Noir (e la versione che lo ha creato). Altrimenti, le prove a conoscenza-zero potrebbero riflettere un programma diverso, uno con una backdoor.
+
+Finché gli esploratori di blocchi non inizieranno a permetterci di caricare e verificare i programmi Noir, dovresti farlo tu stesso (preferibilmente su [IPFS](/developers/tutorials/ipfs-decentralized-ui/)). Quindi gli utenti sofisticati saranno in grado di scaricare il codice sorgente, compilarlo da soli, creare `Verifier.sol` e verificare che sia identico a quello on-chain.
+
+## Conclusione {#conclusion}
+
+Le applicazioni di tipo plasma richiedono un componente centralizzato come archiviazione delle informazioni. Questo apre a potenziali vulnerabilità ma, in cambio, ci permette di preservare la privacy in modi non disponibili sulla blockchain stessa. Con le prove a conoscenza-zero possiamo garantire l'integrità e possibilmente rendere economicamente vantaggioso per chiunque gestisca il componente centralizzato mantenere la disponibilità.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
+
+## Ringraziamenti {#acknowledgements}
+
+- Josh Crites ha letto una bozza di questo articolo e mi ha aiutato con uno spinoso problema di Noir.
+
+Eventuali errori rimanenti sono di mia responsabilità.
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/calling-a-smart-contract-from-javascript/index.md b/public/content/translations/it/developers/tutorials/calling-a-smart-contract-from-javascript/index.md
index dffdcb04b04..9b7d8ccc66c 100644
--- a/public/content/translations/it/developers/tutorials/calling-a-smart-contract-from-javascript/index.md
+++ b/public/content/translations/it/developers/tutorials/calling-a-smart-contract-from-javascript/index.md
@@ -1,14 +1,10 @@
---
title: Chiamare un contratto intelligente da JavaScript
-description: Come chiamare la funzione di un contratto intelligente da JavaScript usando un esempio di token Dai
+description: Come chiamare una funzione di un contratto intelligente da JavaScript usando un esempio con il token Dai
author: jdourlens
-tags:
- - "transazioni"
- - "frontend"
- - "JavaScript"
- - "web3.js"
+tags: ["transazioni", "frontend", "JavaScript", "web3.js"]
skill: beginner
-breadcrumb: "Chiamare contratti da JS"
+breadcrumb: Chiamare contratti da JS
lang: it
published: 2020-04-19
source: EthereumDev
@@ -16,15 +12,15 @@ sourceUrl: https://ethereumdev.io/calling-a-smart-contract-from-javascript/
address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
---
-In questo tutorial vedremo come chiamare la funzione di un [Contratto Intelligente](/developers/docs/smart-contracts/) da JavaScript. Prima, bisogna leggere lo stato di un contratto intelligente (es. il saldo di un titolare di ERC20), poi modificheremo lo stato della blockchain effettuando un trasferimento di token. Dovresti esser già familiare con la [configurazione di un ambiente JS per interagire con la blockchain](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/).
+In questo tutorial vedremo come chiamare una funzione di un [contratto intelligente](/developers/docs/smart-contracts/) da JavaScript. Prima leggeremo lo stato di un contratto intelligente (ad es., il saldo di un possessore di ERC20), poi modificheremo lo stato della blockchain effettuando un trasferimento di token. Dovresti avere già familiarità con la [configurazione di un ambiente JS per interagire con la blockchain](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/).
-Per questo esempio, avremo a che fare con il token DAI e, per scopi di testing biforcheremo la blockchain usando ganache-cli e sbloccheremo un indirizzo che contiene già molti DAI:
+Per questo esempio giocheremo con il token DAI, a scopo di test effettueremo una biforcazione della blockchain usando ganache-cli e sbloccheremo un indirizzo che ha già molti DAI:
```bash
ganache-cli -f https://mainnet.infura.io/v3/[YOUR INFURA KEY] -d -i 66 1 --unlock 0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81
```
-Per interagire con un contratto intelligente, avremo bisogno del suo indirizzo e ABI:
+Per interagire con un contratto intelligente avremo bisogno del suo indirizzo e dell'ABI:
```js
const ERC20TransferABI = [
@@ -75,9 +71,9 @@ const ERC20TransferABI = [
const DAI_ADDRESS = "0x6b175474e89094c44da98b954eedeac495271d0f"
```
-Per questo progetto abbiamo ridotto l'ABI completa dell'ERC20 per mantenere solo la funzione `balancecOf` e `transfer`, ma puoi trovare l'[ABI completa dell'ERC20 qui](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/).
+Per questo progetto abbiamo ridotto l'ABI completa dell'ERC20 per mantenere solo le funzioni `balanceOf` e `transfer`, ma puoi trovare [l'ABI completa dell'ERC20 qui](https://ethereumdev.io/abi-for-erc20-contract-on-ethereum/).
-Poi dobbiamo istanziare il nostro contratto intelligente:
+Dobbiamo quindi istanziare il nostro contratto intelligente:
```js
const web3 = new Web3("http://localhost:8545")
@@ -85,7 +81,7 @@ const web3 = new Web3("http://localhost:8545")
const daiToken = new web3.eth.Contract(ERC20TransferABI, DAI_ADDRESS)
```
-Inoltre, configureremo due indirizzi:
+Imposteremo anche due indirizzi:
- quello che riceverà il trasferimento e
- quello che abbiamo già sbloccato che lo invierà:
@@ -95,13 +91,13 @@ const senderAddress = "0x4d10ae710Bd8D1C31bd7465c8CBC3add6F279E81"
const receiverAddress = "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
```
-Nella prossima parte, chiameremo la funzione `balanceOf` per recuperare l'importo corrente dei token posseduti da entrambi gli indirizzi.
+Nella prossima parte chiameremo la funzione `balanceOf` per recuperare la quantità attuale di token posseduta da entrambi gli indirizzi.
-## Chiamata: Leggere il valore da un contratto intelligente {#call-reading-value-from-a-smart-contract}
+## Call: Leggere un valore da un contratto intelligente {#call-reading-value-from-a-smart-contract}
-Il primo esempio chiamerà un metodo "constant" ed eseguirà il metodo del suo contratto intelligente nell'EVM, senza inviare alcuna transazione. Per questo leggeremo il saldo di ERC20 di un indirizzo. [Leggi il nostro articolo sui token ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/).
+Il primo esempio chiamerà un metodo "costante" ed eseguirà il suo metodo del contratto intelligente nella EVM senza inviare alcuna transazione. Per questo leggeremo il saldo ERC20 di un indirizzo. [Leggi il nostro articolo sui token ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/).
-Puoi accedere ai metodi di un contratto intelligente istanziato per cui hai fornito l'ABI come segue: `yourContract.methods.methodname`. Usando la funzione `call` riceverai il risultato dell'esecuzione della funzione.
+Puoi accedere ai metodi di un contratto intelligente istanziato per cui hai fornito l'ABI nel modo seguente: `yourContract.methods.methodname`. Usando la funzione `call` riceverai il risultato dell'esecuzione della funzione.
```js
daiToken.methods.balanceOf(senderAddress).call(function (err, res) {
@@ -113,11 +109,11 @@ daiToken.methods.balanceOf(senderAddress).call(function (err, res) {
})
```
-Ricorda che l'ERC20 di DAI contiene 18 cifre decimali, il che significa che devi rimuovere 18 zeri per ottenere l'importo corretto. I valori uint256 sono restituiti come stringhe, poiché JavaScript non gestisce i grandi valori numerici. Se non sai [come gestire i grandi numeri in JS consulta il nostro tutorial su bignumber.js](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/).
+Ricorda che il DAI ERC20 ha 18 decimali, il che significa che devi rimuovere 18 zeri per ottenere l'importo corretto. Gli uint256 vengono restituiti come stringhe poiché JavaScript non gestisce valori numerici grandi. Se non sei sicuro di [come gestire i grandi numeri in JS, dai un'occhiata al nostro tutorial su bignumber.js](https://ethereumdev.io/how-to-deal-with-big-numbers-in-javascript/).
-## Invio: Inviare una transazione alla funzione di un contratto intelligente {#send-sending-a-transaction-to-a-smart-contract-function}
+## Send: Inviare una transazione a una funzione di un contratto intelligente {#send-sending-a-transaction-to-a-smart-contract-function}
-Per il secondo esempio, chiameremo la funzione di trasferimento del contratto intelligente di DAI per inviare 10 DAI al nostro secondo indirizzo. La funzione di trasferimento accetta due parametri: l'indirizzo del destinatario e l'importo di token da trasferire:
+Per il secondo esempio chiameremo la funzione di trasferimento del contratto intelligente DAI per inviare 10 DAI al nostro secondo indirizzo. La funzione di trasferimento accetta due parametri: l'indirizzo del destinatario e la quantità di token da trasferire:
```js
daiToken.methods
@@ -131,6 +127,6 @@ daiToken.methods
})
```
-La funzione di chiamata restituiscec l'hash dedlla transazione che sarà minato nella blockchain. Su Ethereum, gli hash della transazione sono prevedibili, così possiamo ottenere l'hash della transazione prima che sia eseguita ([scopri qui come sono calcolati gli hash](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction)).
+La funzione call restituisce l'hash della transazione che verrà minata nella blockchain. Su Ethereum, gli hash delle transazioni sono prevedibili: ecco come possiamo ottenere l'hash della transazione prima che venga eseguita ([scopri come vengono calcolati gli hash qui](https://ethereum.stackexchange.com/questions/45648/how-to-calculate-the-assigned-txhash-of-a-transaction)).
-Poiché la funzione invia soltanto la transazione alla blockchain, non possiamo vedere il risultato finché non sappiamo quando è minato e incluso nella blockchain. Nel prossimo tutorial, impareremo [come attendedre l'esecuzione di una transazione, conoscendone l'hash](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/).
+Poiché la funzione invia solo la transazione alla blockchain, non possiamo vedere il risultato finché non sappiamo quando viene minata e inclusa nella blockchain. Nel prossimo tutorial impareremo [come attendere che una transazione venga eseguita sulla blockchain conoscendone l'hash](https://ethereumdev.io/waiting-for-a-transaction-to-be-mined-on-ethereum-with-js/).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md b/public/content/translations/it/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
new file mode 100644
index 00000000000..e940de51ed2
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md
@@ -0,0 +1,772 @@
+---
+title: "Creare un'interfaccia utente per il tuo contratto"
+description: Utilizzando componenti moderni come TypeScript, React, Vite e Wagmi, esamineremo un'interfaccia utente moderna ma minimale e impareremo come connettere un portafoglio all'interfaccia utente, chiamare un contratto intelligente per leggere informazioni, inviare una transazione a un contratto intelligente e monitorare gli eventi da un contratto intelligente per identificare i cambiamenti.
+author: Ori Pomerantz
+tags: ["TypeScript", "React", "Vite", "Wagmi", "frontend"]
+skill: beginner
+breadcrumb: UI con WAGMI
+published: 2023-11-01
+lang: it
+sidebarDepth: 3
+---
+
+Hai trovato una funzionalità di cui abbiamo bisogno nell'ecosistema di Ethereum. Hai scritto i contratti intelligenti per implementarla, e forse anche del codice correlato che viene eseguito fuori catena. È fantastico! Sfortunatamente, senza un'interfaccia utente non avrai alcun utente, e l'ultima volta che hai scritto un sito web le persone usavano modem dial-up e JavaScript era una novità.
+
+Questo articolo fa per te. Presumo che tu conosca la programmazione, e forse un po' di JavaScript e HTML, ma che le tue competenze in materia di interfacce utente siano arrugginite e obsolete. Insieme esamineremo una semplice applicazione moderna in modo che tu possa vedere come si fa al giorno d'oggi.
+
+## Perché è importante {#why-important}
+
+In teoria, potresti semplicemente far usare alle persone [Etherscan](https://sepolia.etherscan.io/address/0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA#readContract) o [Blockscout](https://eth-sepolia.blockscout.com/address/0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA?tab=read_write_contract) per interagire con i tuoi contratti. Questo è ottimo per gli Ethereani esperti. Ma stiamo cercando di servire [un altro miliardo di persone](https://blog.ethereum.org/2021/05/07/ethereum-for-the-next-billion). Questo non accadrà senza un'ottima esperienza utente, e un'interfaccia utente amichevole ne è una parte importante.
+
+## Applicazione Greeter {#greeter-app}
+
+C'è molta teoria dietro al funzionamento delle moderne interfacce utente, e [molti ottimi siti](https://react.dev/learn/thinking-in-react) [che la spiegano](https://wagmi.sh/core/getting-started). Invece di ripetere l'ottimo lavoro svolto da quei siti, presumerò che tu preferisca imparare facendo e iniziare con un'applicazione con cui puoi giocare. Hai comunque bisogno della teoria per fare le cose, e ci arriveremo: esamineremo semplicemente file sorgente per file sorgente e discuteremo le cose man mano che le incontriamo.
+
+### Installazione {#installation}
+
+1. L'applicazione utilizza la rete di test [Sepolia](https://sepolia.dev/). Se necessario, [ottieni ETH di test di Sepolia](/developers/docs/networks/#sepolia) e [aggiungi Sepolia al tuo portafoglio](https://chainlist.org/chain/11155111).
+
+2. Clona il repository GitHub e installa i pacchetti necessari.
+
+ ```sh
+ git clone https://github.com/qbzzt/260301-modern-ui-web3.git
+ cd 260301-modern-ui-web3
+ npm install
+```
+
+3. L'applicazione utilizza punti di accesso gratuiti, che presentano limitazioni di prestazioni. Se desideri utilizzare un fornitore di [Nodi come servizio](/developers/docs/nodes-and-clients/nodes-as-a-service/), sostituisci gli URL in [`src/wagmi.ts`](#wagmi-ts).
+
+4. Avvia l'applicazione.
+
+ ```sh
+ npm run dev
+```
+
+5. Naviga all'URL mostrato dall'applicazione. Nella maggior parte dei casi, è [http://localhost:5173/](http://localhost:5173/).
+
+6. Puoi vedere il codice sorgente del contratto, una versione modificata del Greeter di Hardhat, [su un esploratore di blocchi](https://eth-sepolia.blockscout.com/address/0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA?tab=contract_code).
+
+### Analisi dei file {#file-walk-through}
+
+#### `index.html` {#index-html}
+
+Questo file è un boilerplate HTML standard, ad eccezione di questa riga, che importa il file di script.
+
+```html
+
+```
+
+#### `src/main.tsx` {#main-tsx}
+
+L'estensione del file indica che si tratta di un [componente React](https://www.w3schools.com/react/react_components.asp) scritto in [TypeScript](https://www.typescriptlang.org/), un'estensione di JavaScript che supporta il [controllo dei tipi](https://en.wikipedia.org/wiki/Type_system#Type_checking). TypeScript viene compilato in JavaScript, quindi possiamo usarlo lato client.
+
+Questo file è spiegato principalmente nel caso in cui tu sia interessato. Di solito non si modifica questo file, ma [`src/App.tsx`](#app-tsx) e i file che importa.
+
+```tsx
+import { QueryClient, QueryClientProvider } from '@tanstack/react-query'
+import React from 'react'
+import ReactDOM from 'react-dom/client'
+import { WagmiProvider } from 'wagmi'
+```
+
+Importa il codice della libreria di cui abbiamo bisogno.
+
+```tsx
+import App from './App.tsx'
+```
+
+Importa il componente React che implementa l'applicazione (vedi sotto).
+
+```tsx
+import { config } from './wagmi.ts'
+```
+
+Importa la configurazione di [wagmi](https://wagmi.sh/), che include la configurazione della blockchain.
+
+```tsx
+const queryClient = new QueryClient()
+```
+
+Crea una nuova istanza del gestore della cache di [React Query](https://tanstack.com/query/latest/docs/framework/react/overview). Questo oggetto memorizzerà:
+
+- Chiamate RPC memorizzate nella cache
+- Letture del contratto
+- Stato di recupero in background
+
+Abbiamo bisogno del gestore della cache perché wagmi v3 utilizza React Query internamente.
+
+```tsx
+ReactDOM.createRoot(document.getElementById('root')!).render(
+```
+
+Crea il componente React radice. Il parametro per `render` è [JSX](https://www.w3schools.com/react/react_jsx.asp), un linguaggio di estensione che utilizza sia HTML che JavaScript/TypeScript. Il punto esclamativo qui dice al componente TypeScript: "non sai che `document.getElementById('root')` sarà un parametro valido per `ReactDOM.createRoot`, ma non preoccuparti: sono lo sviluppatore e ti dico che ci sarà".
+
+```tsx
+
+```
+
+L'applicazione andrà all'interno di [un componente `React.StrictMode`](https://react.dev/reference/react/StrictMode). Questo componente dice alla libreria React di inserire controlli di debug aggiuntivi, il che è utile durante lo sviluppo.
+
+```tsx
+
+```
+
+L'applicazione è anche all'interno di [un componente `WagmiProvider`](https://wagmi.sh/react/api/WagmiProvider). [La libreria wagmi (we are going to make it)](https://wagmi.sh/) collega le definizioni dell'interfaccia utente React con [la libreria viem](https://viem.sh/) per scrivere un'applicazione decentralizzata su Ethereum.
+
+```tsx
+
+```
+
+E infine, aggiungi un provider React Query in modo che qualsiasi componente dell'applicazione possa utilizzare le query memorizzate nella cache.
+
+```tsx
+
+
+ ,
+)
+```
+
+Naturalmente, dobbiamo chiudere gli altri componenti.
+
+#### `src/App.tsx` {#app-tsx}
+
+```tsx
+import {
+ useConnect,
+ useConnection,
+ useDisconnect,
+ useSwitchChain
+} from 'wagmi'
+
+import { useEffect } from 'react'
+import { Greeter } from './Greeter'
+```
+
+Importa le librerie di cui abbiamo bisogno, così come [il componente `Greeter`](#greeter-tsx).
+
+```tsx
+const SEPOLIA_CHAIN_ID = 11155111
+```
+
+L'ID della catena Sepolia.
+
+```
+function App() {
+```
+
+Questo è il modo standard per creare un componente React: definire una funzione che viene chiamata ogni volta che deve essere renderizzata. Questa funzione contiene in genere codice TypeScript o JavaScript, seguito da un'istruzione `return` che restituisce il codice JSX.
+
+```tsx
+ const connection = useConnection()
+```
+
+Usa [`useConnection`](https://wagmi.sh/react/api/hooks/useConnection) per ottenere informazioni relative alla connessione corrente, come l'indirizzo e il `chainId`.
+
+Per convenzione, in React le funzioni chiamate `use...` sono [hook](https://www.w3schools.com/react/react_hooks.asp). Queste funzioni non si limitano a restituire dati al componente; assicurano anche che venga renderizzato di nuovo (la funzione del componente viene eseguita di nuovo e il suo output sostituisce quello precedente nell'HTML) quando quei dati cambiano.
+
+```tsx
+ const { connectors, connect, status, error } = useConnect()
+```
+
+Usa [`useConnect`](https://wagmi.sh/react/api/hooks/useConnect) per ottenere informazioni sulla connessione del portafoglio.
+
+```tsx
+ const { disconnect } = useDisconnect()
+```
+
+[Questo hook](https://wagmi.sh/react/api/hooks/useDisconnect) ci fornisce la funzione per disconnetterci dal portafoglio.
+
+```tsx
+ const { switchChain } = useSwitchChain()
+```
+
+[Questo hook](https://wagmi.sh/react/api/hooks/useSwitchChain) ci permette di cambiare catena.
+
+```tsx
+ useEffect(() => {
+```
+
+L'hook di React [`useEffect`](https://react.dev/reference/react/useEffect) ti consente di eseguire una funzione ogni volta che il valore di una variabile cambia per sincronizzare un sistema esterno.
+
+```tsx
+ if (connection.status === 'connected' &&
+ connection.chainId !== SEPOLIA_CHAIN_ID
+ ) {
+ switchChain({ chainId: SEPOLIA_CHAIN_ID })
+ }
+```
+
+Se siamo connessi, ma non alla blockchain di Sepolia, passa a Sepolia.
+
+```tsx
+ }, [connection.status, connection.chainId])
+```
+
+Esegui di nuovo la funzione ogni volta che lo stato della connessione o il chainId della connessione cambiano.
+
+```tsx
+ return (
+ <>
+```
+
+Il JSX di un componente React _deve_ restituire un singolo componente HTML. Quando abbiamo più componenti e non abbiamo bisogno di un contenitore per avvolgerli tutti, usiamo un componente vuoto (`<> ... `) per combinarli in un singolo componente.
+
+```tsx
+ Connection
+
+ status: {connection.status}
+
+ addresses: {JSON.stringify(connection.addresses)}
+
+ chainId: {connection.chainId}
+
+```
+
+Fornisci informazioni sulla connessione corrente. All'interno di JSX, `{}` significa valutare l'espressione come JavaScript.
+
+```tsx
+ {connection.status === 'connected' && (
+```
+
+La sintassi `{ && } significa "se la condizione è `true`, valuta il valore; se non lo è, valuta `false`".
+
+Questo è il modo standard per inserire istruzioni if all'interno di JSX.
+
+```tsx
+
+
+```
+
+JSX segue lo standard XML, che è più rigoroso dell'HTML. Se un tag non ha un tag di chiusura corrispondente, _deve_ avere una barra (`/`) alla fine per terminarlo.
+
+Qui abbiamo due di questi tag, `
` per una linea orizzontale](https://www.w3schools.com/tags/tag_hr.asp).
+
+```tsx
+
+
+ )}
+```
+
+Se l'utente fa clic su questo pulsante, chiama la funzione `disconnect`.
+
+```tsx
+ {connection.status !== 'connected' && (
+```
+
+Se _non_ siamo connessi, mostra le opzioni necessarie per connettersi al portafoglio.
+
+```tsx
+
+ Connect
+ {connectors.map((connector) => (
+```
+
+In `connectors` abbiamo un elenco di connettori. Usiamo [`map`](https://www.w3schools.com/jsref/jsref_map.asp) per trasformarlo in un elenco di pulsanti JSX da visualizzare.
+
+```tsx
+
+ ))}
+```
+
+I pulsanti del connettore.
+
+```tsx
+ {status}
+ {error?.message}
+
+
+ )}
+```
+
+Fornisci informazioni aggiuntive. La sintassi dell'espressione `?.` dice a JavaScript che se la variabile è definita, valuta quel campo. Se la variabile non è definita, allora questa espressione valuta `undefined`.
+
+L'espressione `error.message`, quando non ci sono errori, solleverebbe un'eccezione. L'uso di `error?.message` ci consente di evitare questo problema.
+
+#### `src/Greeter.tsx` {#greeter-tsx}
+
+Questo file contiene la maggior parte delle funzionalità dell'interfaccia utente. Include definizioni che normalmente si troverebbero in più file, ma poiché si tratta di un tutorial, il programma è ottimizzato per essere facile da comprendere la prima volta, piuttosto che per le prestazioni o la facilità di manutenzione.
+
+```tsx
+import {
+ useState,
+ useEffect,
+ } from 'react'
+import { useChainId,
+ useAccount,
+ useReadContract,
+ useWriteContract,
+ useWatchContractEvent,
+ useSimulateContract
+ } from 'wagmi'
+```
+
+Usiamo queste funzioni di libreria. Anche in questo caso, sono spiegate di seguito dove vengono utilizzate.
+
+```tsx
+import { AddressType } from 'abitype'
+```
+
+[La libreria `abitype`](https://abitype.dev/) ci fornisce definizioni TypeScript per vari tipi di dati di Ethereum, come [`AddressType`](https://abitype.dev/config#addresstype).
+
+```tsx
+let greeterABI = [
+ { "type": "function", "name": "greet", ... },
+ { "type": "function", "name": "setGreeting", ... },
+ { "type": "event", "name": "SetGreeting", ... },
+] as const // greeterABI
+```
+
+L'ABI per il contratto `Greeter`.
+Se stai sviluppando i contratti e l'interfaccia utente contemporaneamente, normalmente li metteresti nello stesso repository e useresti l'ABI generata dal compilatore Solidity come file nella tua applicazione. Tuttavia, questo non è necessario qui perché il contratto è già sviluppato e non cambierà.
+
+Usiamo [`as const`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions) per dire a TypeScript che questa è una _vera_ costante. Normalmente, quando specifichi in JavaScript `const x = {"a": 1}`, puoi cambiare il valore in `x`, semplicemente non puoi assegnargli un nuovo valore.
+
+```tsx
+type AddressPerBlockchainType = {
+ [key: number]: AddressType
+}
+```
+
+TypeScript è fortemente tipizzato. Usiamo questa definizione per specificare l'indirizzo in cui il contratto `Greeter` è distribuito su diverse catene. La chiave è un numero (il chainId) e il valore è un `AddressType` (un indirizzo).
+
+```tsx
+const contractAddrs : AddressPerBlockchainType = {
+ // Sepolia
+ 11155111: '0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA'
+}
+```
+
+L'indirizzo del contratto su [Sepolia](https://eth-sepolia.blockscout.com/address/0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA?tab=contract).
+
+##### Componente Timer {#timer-component}
+
+Il componente `Timer` mostra il numero di secondi trascorsi da un determinato momento. Questo è importante ai fini dell'usabilità. Quando gli utenti fanno qualcosa, si aspettano una reazione immediata. Nelle blockchain, questo è spesso impossibile perché non succede nulla finché una transazione non viene inserita in un blocco. Una soluzione è mostrare quanto tempo è trascorso da quando l'utente ha eseguito l'azione, in modo che l'utente possa decidere se il tempo richiesto è ragionevole.
+
+```tsx
+type TimerProps = {
+ lastUpdate: Date
+}
+```
+
+Il componente `Timer` accetta un parametro, `lastUpdate`, che è l'ora dell'ultima azione.
+
+```tsx
+const Timer = ({ lastUpdate }: TimerProps) => {
+ const [_, setNow] = useState(new Date())
+```
+
+Dobbiamo avere uno stato (una variabile legata al componente) e aggiornarlo affinché il componente funzioni correttamente. Ma non abbiamo mai bisogno di leggerlo, quindi non preoccuparti di creare una variabile.
+
+```tsx
+ useEffect(() => {
+ const id = setInterval(() => setNow(new Date()), 1000)
+ return () => clearInterval(id)
+ }, [])
+```
+
+La funzione [`setInterval`](https://www.w3schools.com/jsref/met_win_setinterval.asp) ci consente di programmare l'esecuzione periodica di una funzione. In questo caso, ogni secondo. La funzione chiama `setNow` per aggiornare lo stato, in modo che il componente `Timer` venga renderizzato di nuovo. Avvolgiamo questo all'interno di [`useEffect`](https://react.dev/reference/react/useEffect) con un elenco di dipendenze vuoto in modo che avvenga solo una volta, piuttosto che ogni volta che il componente viene renderizzato.
+
+```tsx
+ const secondsSinceUpdate = Math.floor(
+ (Date.now() - lastUpdate.getTime()) / 1000
+ )
+
+ return (
+ {secondsSinceUpdate} seconds ago
+ )
+}
+```
+
+Calcola il numero di secondi dall'ultimo aggiornamento e restituiscilo.
+
+##### Componente Greeter {#greeter-component}
+
+```tsx
+const Greeter = () => {
+```
+
+Infine, arriviamo a definire il componente.
+
+```tsx
+ const chainId = useChainId()
+ const account = useAccount()
+```
+
+Informazioni sulla catena e sull'account che stiamo utilizzando, per gentile concessione di [wagmi](https://wagmi.sh/). Poiché si tratta di un hook (`use...`), il componente viene renderizzato di nuovo ogni volta che queste informazioni cambiano.
+
+```tsx
+ const greeterAddr = chainId && contractAddrs[chainId]
+```
+
+L'indirizzo del contratto Greeter, che è `undefined` se non abbiamo informazioni sulla catena, o se siamo su una catena senza quel contratto.
+
+```tsx
+ const readResults = useReadContract({
+ address: greeterAddr,
+ abi: greeterABI,
+ functionName: "greet", // Nessun argomento
+ })
+```
+
+[L'hook `useReadContract`](https://wagmi.sh/react/api/hooks/useReadContract) chiama la funzione `greet` del [contratto](https://eth-sepolia.blockscout.com/address/0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA?tab=contract).
+
+```tsx
+ const [ currentGreeting, setCurrentGreeting ] =
+ useState("Please wait while we fetch the greeting from the blockchain...")
+ const [ newGreeting, setNewGreeting ] = useState("")
+```
+
+L'hook [`useState`](https://www.w3schools.com/react/react_usestate.asp) di React ci consente di specificare una variabile di stato, il cui valore persiste da un rendering del componente all'altro. Il valore iniziale è il parametro, in questo caso la stringa vuota.
+
+L'hook `useState` restituisce un elenco con due valori:
+
+1. Il valore corrente della variabile di stato.
+2. Una funzione per modificare la variabile di stato quando necessario. Poiché si tratta di un hook, ogni volta che viene chiamato il componente viene renderizzato di nuovo.
+
+In questo caso, stiamo utilizzando una variabile di stato per il nuovo saluto che l'utente desidera impostare.
+
+```tsx
+ const [ lastSetterAddress, setLastSetterAddress ] = useState("")
+```
+
+Se più utenti utilizzano lo stesso contratto contemporaneamente, potrebbero sovrascrivere i saluti degli altri. Questo sembrerebbe agli utenti come se l'applicazione non funzionasse correttamente. Se l'applicazione mostra chi ha impostato il saluto per ultimo, l'utente saprà che è stato qualcun altro e che l'applicazione funziona correttamente.
+
+```tsx
+ const [ status, setStatus ] = useState("")
+ const [ statusTime, setStatusTime ] = useState(new Date())
+```
+
+Agli utenti piace vedere che le loro azioni hanno un effetto immediato. Tuttavia, su una blockchain, non è così. Queste variabili di stato ci consentono almeno di visualizzare qualcosa agli utenti in modo che sappiano che la loro azione è in corso.
+
+```tsx
+ useEffect(() => {
+ if (readResults.data) {
+ setCurrentGreeting(readResults.data)
+ setStatus("Greeting fetched from blockchain")
+ }
+ }, [readResults.data])
+```
+
+Se `readResults` sopra modifica i dati e non è impostato su un valore falso (ad esempio `undefined`), aggiorna il saluto corrente a quello letto dalla blockchain. Inoltre, aggiorna lo stato.
+
+```tsx
+ useWatchContractEvent({
+ address: greeterAddr,
+ abi: greeterABI,
+ eventName: 'SetGreeting',
+ chainId,
+```
+
+Ascolta gli eventi `SetGreeting`.
+
+```tsx
+ enabled: !!greeterAddr,
+```
+
+`!!` significa che se il valore è `false`, o un valore che viene valutato come falso, come `undefined`, `0` o una stringa vuota, l'espressione nel complesso è `false`. Per qualsiasi altro valore, è `true`. È un modo per convertire i valori in booleani, perché se non c'è `greeterAddr`, non vogliamo ascoltare gli eventi.
+
+```tsx
+ onLogs: logs => {
+ const greetingFromContract = logs[0].args.greeting
+ setCurrentGreeting(greetingFromContract)
+ setLastSetterAddress(logs[0].args.sender)
+ updateStatus("Greeting updated by event")
+ },
+ })
+```
+
+Quando vediamo i log (il che accade quando vediamo un nuovo evento), significa che il saluto è stato modificato. In tal caso, possiamo aggiornare `currentGreeting` e `lastSetterAddress` ai nuovi valori. Inoltre, vogliamo aggiornare la visualizzazione dello stato.
+
+```tsx
+ const updateStatus = (newStatus: string) => {
+ setStatus(newStatus)
+ setStatusTime(new Date())
+ }
+```
+
+Quando aggiorniamo lo stato vogliamo fare due cose:
+
+1. Aggiornare la stringa di stato (`status`)
+2. Aggiornare l'ora dell'ultimo aggiornamento di stato (`statusTime`) ad adesso.
+
+```tsx
+ const greetingChange = (evt) =>
+ setNewGreeting(evt.target.value)
+```
+
+Questo è il gestore di eventi per le modifiche al nuovo campo di input del saluto. Potremmo specificare il tipo del parametro `evt`, ma TypeScript è un linguaggio con tipi opzionali. Poiché questa funzione viene chiamata solo una volta, in un gestore di eventi HTML, non credo sia necessario.
+
+```tsx
+ const { writeContractAsync } = useWriteContract()
+```
+
+La funzione per scrivere su un contratto. È simile a [`writeContracts`](https://wagmi.sh/core/api/actions/writeContracts#writecontracts), ma consente migliori aggiornamenti di stato.
+
+```tsx
+ const simulation = useSimulateContract({
+ address: greeterAddr,
+ abi: greeterABI,
+ functionName: 'setGreeting',
+ args: [newGreeting],
+ account: account.address
+ })
+```
+
+Questo è il processo per inviare una transazione blockchain dalla prospettiva del client:
+
+1. Invia la transazione a un nodo nella blockchain utilizzando [`eth_estimateGas`](https://docs.alchemy.com/reference/eth-estimategas).
+2. Attendi una risposta dal nodo.
+3. Quando viene ricevuta la risposta, chiedi all'utente di firmare la transazione tramite il portafoglio. Questo passaggio _deve_ avvenire dopo aver ricevuto la risposta del nodo perché all'utente viene mostrato il costo del gas della transazione prima di firmarla.
+4. Attendi l'approvazione dell'utente.
+5. Invia di nuovo la transazione, questa volta utilizzando [`eth_sendRawTransaction`](https://docs.alchemy.com/reference/eth-sendrawtransaction).
+
+È probabile che il passaggio 2 richieda una quantità di tempo percettibile, durante la quale gli utenti potrebbero chiedersi se il loro comando sia stato ricevuto dall'interfaccia utente e perché non venga ancora chiesto loro di firmare la transazione. Ciò crea una scarsa esperienza utente (UX).
+
+Una soluzione è inviare `eth_estimateGas` ogni volta che un parametro cambia. Quindi, quando l'utente desidera effettivamente inviare la transazione (in questo caso premendo **Update greeting**), il costo del gas è noto e l'utente può vedere immediatamente la pagina del portafoglio.
+
+```tsx
+ return (
+```
+
+Ora possiamo finalmente creare l'HTML effettivo da restituire.
+
+```tsx
+ <>
+ Greeter
+ {currentGreeting}
+```
+
+Mostra il saluto corrente.
+
+```tsx
+ {lastSetterAddress && (
+ Last updated by {
+ lastSetterAddress === account.address ? "you" : lastSetterAddress
+ }
+ )}
+```
+
+Se sappiamo chi ha impostato il saluto per ultimo, visualizza tali informazioni. `Greeter` non tiene traccia di queste informazioni e non vogliamo guardare indietro per gli eventi `SetGreeting`, quindi le otteniamo solo una volta che il saluto viene modificato mentre siamo in esecuzione.
+
+```tsx
+
+
+
+```
+
+Questo è il campo di testo di input in cui l'utente può impostare un nuovo saluto. Ogni volta che l'utente preme un tasto, chiamiamo `greetingChange`, che chiama `setNewGreeting`. Poiché `setNewGreeting` proviene da `useState`, fa sì che il componente `Greeter` venga renderizzato di nuovo. Questo significa che:
+
+- Dobbiamo specificare `value` per mantenere il valore del nuovo saluto, perché altrimenti tornerebbe al valore predefinito, la stringa vuota.
+- Anche `simulation` viene aggiornato ogni volta che `newGreeting` cambia, il che significa che otterremo una simulazione con il saluto corretto. Questo potrebbe essere rilevante perché il costo del gas dipende dalla dimensione dei dati della chiamata, che dipende dalla lunghezza della stringa.
+
+```tsx
+
+
+```
+
+`writeContractAsync` restituisce un valore solo dopo che la transazione è stata effettivamente inviata. Questo ci consente di mostrare all'utente da quanto tempo la transazione è in attesa di essere inclusa nella blockchain.
+
+```tsx
+ Status: {status}
+ Updated
+
+ )
+}
+```
+
+Mostra lo stato e da quanto tempo è stato aggiornato.
+
+```
+export {Greeter}
+```
+
+Esporta il componente.
+
+#### `src/wagmi.ts` {#wagmi-ts}
+
+Infine, varie definizioni relative a wagmi si trovano in `src/wagmi.ts`. Non spiegherò tutto qui, perché la maggior parte è boilerplate che difficilmente avrai bisogno di cambiare.
+
+```ts
+import { http, webSocket, createConfig, fallback } from 'wagmi'
+import { sepolia } from 'wagmi/chains'
+import { injected } from 'wagmi/connectors'
+
+export const config = createConfig({
+ chains: [sepolia],
+```
+
+La configurazione di wagmi include le catene supportate da questa applicazione. Puoi vedere l'[elenco delle catene disponibili](https://wagmi.sh/core/api/chains).
+
+```ts
+ connectors: [
+ injected(),
+ ],
+```
+
+[Questo connettore](https://wagmi.sh/core/api/connectors/injected) ci consente di comunicare con un portafoglio installato nel browser.
+
+```ts
+ transports: {
+ [sepolia.id]: http()
+```
+
+L'endpoint HTTP predefinito fornito con Viem è sufficiente. Se vogliamo un URL diverso, possiamo usare `http("https:// hostname ")` o `webSocket("wss:// hostname ")`.
+
+```ts
+ },
+ multiInjectedProviderDiscovery: false,
+})
+```
+
+## Aggiungere un'altra blockchain {#add-blockchain}
+
+Al giorno d'oggi ci sono molte [soluzioni di scalabilità di livello 2](https://ethereum.org/layer-2/), e potresti voler supportarne alcune che viem non supporta ancora. Per farlo, modifica `src/wagmi.ts`. Queste istruzioni spiegano come aggiungere [Optimism Sepolia](https://chainlist.org/chain/11155420).
+
+1. Modifica `src/wagmi.ts`
+
+ A. Importa il tipo `defineChain` da viem.
+
+ ```ts
+ import { defineChain } from 'viem'
+```
+
+ B. Aggiungi la definizione della rete. Non hai davvero bisogno di farlo per Optimism Sepolia, [è già in `viem`](https://github.com/wevm/viem/blob/main/src/chains/definitions/optimismSepolia.ts), ma in questo modo impari come aggiungere una blockchain che non è in `viem`.
+
+ ```ts
+ const optimismSepolia = defineChain({
+ id: 11_155_420,
+ name: 'OP Sepolia',
+ nativeCurrency: { name: 'Sepolia Ether', symbol: 'ETH', decimals: 18 },
+ rpcUrls: {
+ default: {
+ http: ['https://sepolia.optimism.io'],
+ webSocket: ['wss://optimism-sepolia.drpc.org'],
+ },
+ },
+ blockExplorers: {
+ default: {
+ name: 'Blockscout',
+ url: 'https://optimism-sepolia.blockscout.com',
+ apiUrl: 'https://optimism-sepolia.blockscout.com/api',
+ }
+ },
+ })
+```
+
+ C. Aggiungi la nuova catena alla chiamata `createConfig`.
+
+ ```ts
+ export const config = createConfig({
+ chains: [sepolia, optimismSepolia],
+ connectors: [
+ injected(),
+ ],
+ transports: {
+ [optimismSepolia.id]: http(),
+ [sepolia.id]: http()
+ },
+ multiInjectedProviderDiscovery: false,
+ })
+```
+
+2. Modifica `src/App.tsx` per commentare il passaggio automatico a Sepolia. Su un sistema di produzione, probabilmente mostreresti pulsanti con collegamenti a ciascuna delle blockchain che supporti.
+
+ ```ts
+ /* useEffect(() => {
+ if (connection.status === 'connected' &&
+ connection.chainId !== SEPOLIA_CHAIN_ID
+ ) {
+ switchChain({ chainId: SEPOLIA_CHAIN_ID })
+ }
+ }, [connection.status, connection.chainId]) */
+
+
+
+
+
+
+
+
+
+```
+
+3. Modifica `src/Greeter.tsx` per assicurarti che l'applicazione conosca l'indirizzo dei tuoi contratti sulla nuova rete.
+
+ ```ts
+ const contractAddrs: AddressPerBlockchainType = {
+ // Optimism Sepolia
+ 11155420: "0x4dd85791923E9294E934271522f63875EAe5806f",
+
+ // Sepolia
+ 11155111: "0x7143d5c190F048C8d19fe325b748b081903E3BF0",
+ }
+```
+
+4. Nel tuo browser.
+
+ A. Naviga su [ChainList](https://chainlist.org/chain/11155420?testnets=true) e fai clic su uno dei pulsanti sul lato destro della tabella per aggiungere la catena al tuo portafoglio.
+
+ B. Nell'applicazione, fai clic su **Disconnect** e poi riconnettiti per cambiare la blockchain. Ci sono modi più eleganti per gestirlo, ma richiederebbero modifiche all'applicazione.
+
+## Conclusione {#conclusion}
+
+Naturalmente, non ti interessa davvero fornire un'interfaccia utente per `Greeter`. Vuoi creare un'interfaccia utente per i tuoi contratti. Per creare la tua applicazione, esegui questi passaggi:
+
+1. Specifica di creare un'applicazione wagmi.
+
+ ```sh copy
+ npm create wagmi
+```
+
+2. Digita `y` per procedere.
+
+3. Dai un nome all'applicazione.
+
+4. Seleziona il framework **React**.
+
+5. Seleziona la variante **Vite**.
+
+Ora vai e rendi i tuoi contratti utilizzabili per il mondo intero.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/deploying-your-first-smart-contract/index.md b/public/content/translations/it/developers/tutorials/deploying-your-first-smart-contract/index.md
index 85a1b1209b4..3e3be9f5d13 100644
--- a/public/content/translations/it/developers/tutorials/deploying-your-first-smart-contract/index.md
+++ b/public/content/translations/it/developers/tutorials/deploying-your-first-smart-contract/index.md
@@ -1,14 +1,10 @@
---
-title: Distribuzione del primo Smart Contract
-description: Introduzione alla distribuzione del primo Smart Contract su una rete di prova Ethereum
+title: Distribuire il tuo primo contratto intelligente
+description: Un'introduzione alla distribuzione del tuo primo contratto intelligente su una rete di test di Ethereum
author: "jdourlens"
-tags:
- - "smart contract"
- - "remix"
- - "Solidity"
- - "distribuzione"
+tags: ["contratti intelligenti", "Remix", "Solidity", "distribuzione"]
skill: beginner
-breadcrumb: "Primo contratto"
+breadcrumb: Distribuisci il primo contratto
lang: it
published: 2020-04-03
source: EthereumDev
@@ -16,15 +12,15 @@ sourceUrl: https://ethereumdev.io/deploying-your-first-smart-contract/
address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE"
---
-Sicuramente sarai entusiasta almeno quanto noi di [distribuire](/developers/docs/smart-contracts/deploying/) il tuo primo [Smart Contract](/developers/docs/smart-contracts/) e interagirvi sulla blockchain Ethereum.
+Immagino che tu sia entusiasta quanto noi di [distribuire](/developers/docs/smart-contracts/deploying/) e interagire con il tuo primo [contratto intelligente](/developers/docs/smart-contracts/) sulla blockchain di Ethereum.
-Non preoccuparti, essendo il nostro primo smart contract, lo distribuiremo su una [rete locale di prova](/developers/docs/networks/) così che non ti costi nulla distribuirlo e giocarci quanto vuoi.
+Non preoccuparti, dato che è il nostro primo contratto intelligente, lo distribuiremo su una [rete di test locale](/developers/docs/networks/) in modo che non ti costi nulla distribuirlo e giocarci quanto vuoi.
-## Scrittura del contratto {#writing-our-contract}
+## Scrivere il nostro contratto {#writing-our-contract}
-Il primo passaggio consiste nel [visitare Remix](https://remix.ethereum.org/) e creare un nuovo file. Nella parte in alto a sinistra dell'interfaccia di Remix, aggiungi un nuovo file e inserisci il nome che preferisci.
+Il primo passo è [visitare Remix](https://remix.ethereum.org/) e creare un nuovo file. Nella parte in alto a sinistra dell'interfaccia di Remix, aggiungi un nuovo file e inserisci il nome del file che desideri.
-
+
Nel nuovo file, incolleremo il seguente codice.
@@ -34,15 +30,15 @@ pragma solidity >=0.5.17;
contract Counter {
- // Public variable of type unsigned int to keep the number of counts
+ // Variabile pubblica di tipo unsigned int per mantenere il numero di conteggi
uint256 public count = 0;
- // Function that increments our counter
+ // Funzione che incrementa il nostro contatore
function increment() public {
count += 1;
}
- // Not necessary getter to get the count value
+ // Getter non necessario per ottenere il valore del conteggio
function getCount() public view returns (uint256) {
return count;
}
@@ -50,51 +46,51 @@ contract Counter {
}
```
-Se sei familiare con la programmazione, puoi facilmente intuire cosa faccia questo programma. Ecco una spiegazione riga per riga:
+Se sei abituato a programmare, puoi facilmente intuire cosa fa questo programma. Ecco una spiegazione riga per riga:
-- Riga 4: definiamo un contratto con il nome `Counter`.
-- Riga 7: il nostro contratto memorizza un numero intero senza firma `count` a partire da 0.
-- Riga 10: la prima funzione modificherà lo stato del contratto e incrementerà (`increment()`) la nostra variabile `count`.
-- Riga 15: la seconda funzione è solo un getter per leggere il valore della variabile `count` al di fuori dello Smart Contract. Nota che, dato che abbiamo definito la variabile `count` come pubblica, questo non è necessario. Lo indichiamo come esempio.
+- Riga 4: Definiamo un contratto con il nome `Counter`.
+- Riga 7: Il nostro contratto memorizza un intero senza segno chiamato `count` che parte da 0.
+- Riga 10: La prima funzione modificherà lo stato del contratto e incrementerà (`increment()`) la nostra variabile `count`.
+- Riga 15: La seconda funzione è solo un getter per poter leggere il valore della variabile `count` all'esterno del contratto intelligente. Nota che, poiché abbiamo definito la nostra variabile `count` come pubblica, questo non è necessario ma viene mostrato come esempio.
-Questo è tutto per il nostro primo semplice Smart Contract. Come forse saprai, somiglia un po' un linguaggio di OOP (Programmazione Orientata agli Oggetti), come Java o C++. Ora è il momento di sperimentare con il contratto.
+Questo è tutto per il nostro primo semplice contratto intelligente. Come forse saprai, assomiglia a una classe dei linguaggi OOP (Programmazione Orientata agli Oggetti) come Java o C++. Ora è il momento di giocare con il nostro contratto.
-## Distribuzione del contratto {#deploying-our-contract}
+## Distribuire il nostro contratto {#deploying-our-contract}
-Una volta scritto il nostro primo Smart Contract, è il momento di distribuirlo sulla blockchain per potervi interagire.
+Poiché abbiamo scritto il nostro primissimo contratto intelligente, ora lo distribuiremo sulla blockchain per poterci giocare.
-[Distribuire il primo Smart Contract sulla blockchain](/developers/docs/smart-contracts/deploying/) significa semplicemente inviare una transazione contenente il codice dello Smart Contract compilato senza specificare nessun destinatario.
+[Distribuire il contratto intelligente sulla blockchain](/developers/docs/smart-contracts/deploying/) in realtà consiste solo nell'inviare una transazione contenente il codice del contratto intelligente compilato senza specificare alcun destinatario.
-Dovremo per prima cosa [compilare il contratto](/developers/docs/smart-contracts/compiling/) facendo clic sull'icona di compilazione sul lato sinistro:
+Per prima cosa [compileremo il contratto](/developers/docs/smart-contracts/compiling/) cliccando sull'icona di compilazione sul lato sinistro:
-
+
-Poi facciamo clic sul pulsante di compilazione:
+Quindi clicca sul pulsante di compilazione:
-
+
Puoi scegliere di selezionare l'opzione "Auto compile" in modo che il contratto venga sempre compilato quando salvi il contenuto nell'editor di testo.
-Poi passa alla schermata per la distribuzione e l'esecuzione delle transazioni:
+Quindi naviga alla schermata "deploy and run transactions" (distribuisci ed esegui transazioni):
-
+
-Una volta sulla schermata di distribuzione ed esecuzione, controlla bene che appaia il nome del tuo contratto e fai clic su Deploy. Come puoi vedere in alto nella pagina, l'ambiente corrente è "JavaScript VM", che significa che distribuiremo il nostro Smart Contract e interagiremo con esso su una blockchain di test locale per poter effettuare test in modo più veloce e senza commissioni.
+Una volta che sei nella schermata "deploy and run transactions", controlla che appaia il nome del tuo contratto e clicca su Deploy. Come puoi vedere in cima alla pagina, l'ambiente attuale è "JavaScript VM", il che significa che distribuiremo e interagiramo con il nostro contratto intelligente su una blockchain di test locale per poter testare più velocemente e senza alcuna commissione.
-
+
-Una volta fatto clic sul pulsante "Deploy", il tuo contratto apparirà nella parte inferiore. Fai clic sulla freccia a sinistra per espanderlo, così da vederne il contenuto. Questa è la nostra variabile `counter`, la nostra funzione `increment()` e il getter `getCounter()`.
+Una volta cliccato il pulsante "Deploy", vedrai apparire il tuo contratto in basso. Clicca sulla freccia a sinistra per espanderlo in modo da vedere il contenuto del nostro contratto. Questa è la nostra variabile `counter`, la nostra funzione `increment()` e il getter `getCounter()`.
-Se fai clic sul pulsante `count` o `getCount`, verrà recuperato e mostrato il contenuto della variabile `count` del contratto. Dato che non abbiamo ancora chiamato la funzione `increment`, questa dovrebbe indicare 0.
+Se clicchi sul pulsante `count` o `getCount`, recupererà effettivamente il contenuto della variabile `count` del contratto e lo visualizzerà. Poiché non abbiamo ancora chiamato la funzione `increment`, dovrebbe visualizzare 0.
-
+
-Chiamiamo ora la funzione `increment` facendo clic sul pulsante. Appariranno i log delle transazioni nella parte inferiore della finestra. Vedrai che i log sono diversi quando premi il pulsante per recuperare i dati invece del pulsante `increment`. Questo perché leggere dati sulla blockchain non richiede alcuna transazione (scrittura) o commissione. Perché una transazione è richiesta solo quando si modifica lo stato della blockchain:
+Chiamiamo ora la funzione `increment` cliccando sul pulsante. Vedrai i log delle transazioni effettuate apparire nella parte inferiore della finestra. Vedrai che i log sono diversi quando premi il pulsante per recuperare i dati invece del pulsante `increment`. Questo perché la lettura dei dati sulla blockchain non richiede alcuna transazione (scrittura) o commissione. Perché solo la modifica dello stato della blockchain richiede di effettuare una transazione:
-
+
-Dopo aver scelto il pulsante increment che genererà una transazione per chiamare la funzione `increment()`, se facciamo clic di nuovo sui pulsanti count o getCount, leggiamo lo stato aggiornato del nostro Smart Contract con la variabile count maggiore di 0.
+Dopo aver premuto il pulsante di incremento che genererà una transazione per chiamare la nostra funzione `increment()`, se clicchiamo di nuovo sui pulsanti count o getCount leggeremo il nuovo stato aggiornato del nostro contratto intelligente con la variabile count maggiore di 0.
-
+
-Nel prossimo tutorial spiegheremo [come aggiungere eventi agli Smart Contract](/developers/tutorials/logging-events-smart-contracts/). Avere un log degli eventi è un modo comodo per eseguire il debug di uno Smart Contract e per capire cosa succede quando si chiama una funzione.
+Nel prossimo tutorial, tratteremo [come puoi aggiungere eventi ai tuoi contratti intelligenti](/developers/tutorials/logging-events-smart-contracts/). La registrazione degli eventi è un modo conveniente per eseguire il debug del tuo contratto intelligente e capire cosa sta succedendo durante la chiamata di una funzione.
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md b/public/content/translations/it/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md
new file mode 100644
index 00000000000..654c53b4004
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/develop-and-test-dapps-with-a-multi-client-local-eth-testnet/index.md
@@ -0,0 +1,373 @@
+---
+title: Come sviluppare e testare una dApp su una rete di test locale multi-client
+description: "Questa guida ti illustrerà prima come istanziare e configurare una rete di test locale di Ethereum multi-client prima di utilizzare la rete di test per distribuire e testare una dApp."
+author: "Tedi Mitiku"
+tags:
+ [
+ "client",
+ "nodi",
+ "contratti intelligenti",
+ "componibilità",
+ "livello di consenso",
+ "livello di esecuzione",
+ "test",
+ ]
+skill: intermediate
+breadcrumb: Rete di test multi-client
+lang: it
+published: 2023-04-11
+---
+
+## Introduzione {#introduction}
+
+Questa guida ti accompagna nel processo di istanziazione di una rete di test locale e configurabile di Ethereum, di distribuzione di un contratto intelligente su di essa e di utilizzo della rete di test per eseguire test sulla tua dApp. Questa guida è progettata per gli sviluppatori di dApp che desiderano sviluppare e testare le proprie dApp localmente su diverse configurazioni di rete prima di distribuirle su una rete di test attiva o sulla rete principale.
+
+In questa guida, potrai:
+
+- Istanziare una rete di test locale di Ethereum con l'[`eth-network-package`](https://github.com/kurtosis-tech/eth-network-package) utilizzando [Kurtosis](https://www.kurtosis.com/),
+- Connettere il tuo ambiente di sviluppo di dApp Hardhat alla rete di test locale per compilare, distribuire e testare una dApp, e
+- Configurare la rete di test locale, inclusi parametri come il numero di nodi e specifici abbinamenti di client EL/CL, per abilitare flussi di lavoro di sviluppo e test su varie configurazioni di rete.
+
+### Cos'è Kurtosis? {#what-is-kurtosis}
+
+[Kurtosis](https://www.kurtosis.com/) è un sistema di compilazione componibile progettato per configurare ambienti di test multi-container. Consente specificamente agli sviluppatori di creare ambienti riproducibili che richiedono logiche di configurazione dinamiche, come le reti di test blockchain.
+
+In questa guida, l'eth-network-package di Kurtosis avvia una rete di test locale di Ethereum con supporto per il client del livello di esecuzione (EL) [`geth`](https://geth.ethereum.org/), oltre ai client del livello di consenso (CL) [`teku`](https://consensys.io/teku), [`lighthouse`](https://lighthouse.sigmaprime.io/) e [`lodestar`](https://lodestar.chainsafe.io/). Questo pacchetto funge da alternativa configurabile e componibile alle reti in framework come Hardhat Network, Ganache e Anvil. Kurtosis offre agli sviluppatori un maggiore controllo e flessibilità sulle reti di test che utilizzano, che è uno dei motivi principali per cui la [Fondazione Ethereum ha utilizzato Kurtosis per testare il Merge](https://www.kurtosis.com/blog/testing-the-ethereum-merge) e continua a utilizzarlo per testare gli aggiornamenti della rete.
+
+## Configurare Kurtosis {#setting-up-kurtosis}
+
+Prima di procedere, assicurati di aver:
+
+- [Installato e avviato il motore Docker](https://docs.kurtosis.com/install/#i-install--start-docker) sulla tua macchina locale
+- [Installato la CLI di Kurtosis](https://docs.kurtosis.com/install#ii-install-the-cli) (o aggiornata all'ultima versione, se hai già installato la CLI)
+- Installato [Node.js](https://nodejs.org/en), [yarn](https://classic.yarnpkg.com/lang/en/docs/install/#mac-stable) e [npx](https://www.npmjs.com/package/npx) (per il tuo ambiente dApp)
+
+## Istanziare una rete di test locale di Ethereum {#instantiate-testnet}
+
+Per avviare una rete di test locale di Ethereum, esegui:
+
+```python
+kurtosis --enclave local-eth-testnet run github.com/kurtosis-tech/eth-network-package
+```
+
+Nota: questo comando nomina la tua rete: "local-eth-testnet" utilizzando il flag `--enclave`.
+
+Kurtosis stamperà i passaggi che sta eseguendo in background mentre lavora per interpretare, convalidare e quindi eseguire le istruzioni. Alla fine, dovresti vedere un output simile al seguente:
+
+```python
+INFO[2023-04-04T18:09:44-04:00] ======================================================
+INFO[2023-04-04T18:09:44-04:00] || Created enclave: local-eth-testnet ||
+INFO[2023-04-04T18:09:44-04:00] ======================================================
+Name: local-eth-testnet
+UUID: 39372d756ae8
+Status: RUNNING
+Creation Time: Tue, 04 Apr 2023 18:09:03 EDT
+
+========================================= Files Artifacts =========================================
+UUID Name
+d4085a064230 cl-genesis-data
+1c62cb792e4c el-genesis-data
+bd60489b73a7 genesis-generation-config-cl
+b2e593fe5228 genesis-generation-config-el
+d552a54acf78 geth-prefunded-keys
+5f7e661eb838 prysm-password
+054e7338bb59 validator-keystore-0
+
+========================================== User Services ==========================================
+UUID Name Ports Status
+e20f129ee0c5 cl-client-0-beacon http: 4000/tcp -> RUNNING
+ metrics: 5054/tcp ->
+ tcp-discovery: 9000/tcp -> 127.0.0.1:54263
+ udp-discovery: 9000/udp -> 127.0.0.1:60470
+a8b6c926cdb4 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:54267 RUNNING
+ metrics: 5064/tcp ->
+d7b802f623e8 el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:54253 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:54251
+ tcp-discovery: 30303/tcp -> 127.0.0.1:54254
+ udp-discovery: 30303/udp -> 127.0.0.1:53834
+ ws: 8546/tcp -> 127.0.0.1:54252
+514a829c0a84 prelaunch-data-generator-1680646157905431468 STOPPED
+62bd62d0aa7a prelaunch-data-generator-1680646157915424301 STOPPED
+05e9619e0e90 prelaunch-data-generator-1680646157922872635 STOPPED
+
+```
+
+Congratulazioni! Hai utilizzato Kurtosis per istanziare una rete di test locale di Ethereum, con un client CL (`lighthouse`) ed EL (`geth`), su Docker.
+
+### Revisione {#review-instantiate-testnet}
+
+In questa sezione, hai eseguito un comando che ha indicato a Kurtosis di utilizzare l'[`eth-network-package` ospitato in remoto su GitHub](https://github.com/kurtosis-tech/eth-network-package) per avviare una rete di test locale di Ethereum all'interno di un'[Enclave](https://docs.kurtosis.com/advanced-concepts/enclaves/) di Kurtosis. All'interno della tua enclave, troverai sia "artefatti di file" che "servizi utente".
+
+Gli [Artefatti di File](https://docs.kurtosis.com/advanced-concepts/files-artifacts/) nella tua enclave includono tutti i dati generati e utilizzati per avviare i client EL e CL. I dati sono stati creati utilizzando il servizio `prelaunch-data-generator` creato da questa [immagine Docker](https://github.com/ethpandaops/ethereum-genesis-generator)
+
+I servizi utente mostrano tutti i servizi containerizzati operativi nella tua enclave. Noterai che è stato creato un singolo nodo, che presenta sia un client EL che un client CL.
+
+## Connettere il tuo ambiente di sviluppo di dApp alla rete di test locale di Ethereum {#connect-your-dapp}
+
+### Configurare l'ambiente di sviluppo della dApp {#set-up-dapp-env}
+
+Ora che hai una rete di test locale in esecuzione, puoi connettere il tuo ambiente di sviluppo di dApp per utilizzare la tua rete di test locale. Il framework Hardhat verrà utilizzato in questa guida per distribuire una dApp di blackjack sulla tua rete di test locale.
+
+Per configurare il tuo ambiente di sviluppo di dApp, clona il repository che contiene la nostra dApp di esempio e installa le sue dipendenze, esegui:
+
+```python
+git clone https://github.com/kurtosis-tech/awesome-kurtosis.git && cd awesome-kurtosis/smart-contract-example && yarn
+```
+
+La cartella [smart-contract-example](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example) utilizzata qui contiene la configurazione tipica per uno sviluppatore di dApp che utilizza il framework [Hardhat](https://hardhat.org/):
+
+- [`contracts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/contracts) contiene alcuni semplici contratti intelligenti per una dApp di Blackjack
+- [`scripts/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/scripts) contiene uno script per distribuire un contratto di token sulla tua rete locale di Ethereum
+- [`test/`](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/smart-contract-example/test) contiene un semplice test .js per il tuo contratto di token per confermare che ogni giocatore nella nostra dApp di Blackjack abbia 1000 token coniati per loro
+- [`hardhat.config.ts`](https://github.com/kurtosis-tech/awesome-kurtosis/blob/main/smart-contract-example/hardhat.config.ts) configura la tua installazione di Hardhat
+
+### Configurare Hardhat per utilizzare la rete di test locale {#configure-hardhat}
+
+Con il tuo ambiente di sviluppo di dApp configurato, ora connetterai Hardhat per utilizzare la rete di test locale di Ethereum generata utilizzando Kurtosis. Per farlo, sostituisci `<$YOUR_PORT>` nella struttura `localnet` nel tuo file di configurazione `hardhat.config.ts` con la porta dell'URI RPC in output da qualsiasi servizio `el-client-`. In questo caso di esempio, la porta sarebbe `64248`. La tua porta sarà diversa.
+
+Esempio in `hardhat.config.ts`:
+
+```js
+localnet: {
+url: 'http://127.0.0.1:<$YOUR_PORT>', // TODO: SOSTITUISCI $YOUR_PORT CON LA PORTA DI UN URI DEL NODO PRODOTTO DAL PACCHETTO ETH NETWORK KURTOSIS
+
+// Queste sono chiavi private associate ad account di test prefinanziati creati dall'eth-network-package
+//
+accounts: [
+ "ef5177cd0b6b21c87db5a0bf35d4084a8a57a9d6a064f86d51ac85f2b873a4e2",
+ "48fcc39ae27a0e8bf0274021ae6ebd8fe4a0e12623d61464c498900b28feb567",
+ "7988b3a148716ff800414935b305436493e1f25237a2a03e5eebc343735e2f31",
+ "b3c409b6b0b3aa5e65ab2dc1930534608239a478106acf6f3d9178e9f9b00b35",
+ "df9bb6de5d3dc59595bcaa676397d837ff49441d211878c024eabda2cd067c9f",
+ "7da08f856b5956d40a72968f93396f6acff17193f013e8053f6fbb6c08c194d6",
+ ],
+},
+```
+
+Una volta salvato il file, il tuo ambiente di sviluppo di dApp Hardhat è ora connesso alla tua rete di test locale di Ethereum! Puoi verificare che la tua rete di test funzioni eseguendo:
+
+```python
+npx hardhat balances --network localnet
+```
+
+L'output dovrebbe essere simile a questo:
+
+```python
+0x878705ba3f8Bc32FCf7F4CAa1A35E72AF65CF766 has balance 10000000000000000000000000
+0x4E9A3d9D1cd2A2b2371b8b3F489aE72259886f1A has balance 10000000000000000000000000
+0xdF8466f277964Bb7a0FFD819403302C34DCD530A has balance 10000000000000000000000000
+0x5c613e39Fc0Ad91AfDA24587e6f52192d75FBA50 has balance 10000000000000000000000000
+0x375ae6107f8cC4cF34842B71C6F746a362Ad8EAc has balance 10000000000000000000000000
+0x1F6298457C5d76270325B724Da5d1953923a6B88 has balance 10000000000000000000000000
+```
+
+Questo conferma che Hardhat sta utilizzando la tua rete di test locale e rileva gli account prefinanziati creati dall'`eth-network-package`.
+
+### Distribuire e testare la tua dApp localmente {#deploy-and-test-dapp}
+
+Con l'ambiente di sviluppo della dApp completamente connesso alla rete di test locale di Ethereum, ora puoi eseguire flussi di lavoro di sviluppo e test sulla tua dApp utilizzando la rete di test locale.
+
+Per compilare e distribuire il contratto intelligente `ChipToken.sol` per la prototipazione e lo sviluppo locale, esegui:
+
+```python
+npx hardhat compile
+npx hardhat run scripts/deploy.ts --network localnet
+```
+
+L'output dovrebbe essere simile a:
+
+```python
+ChipToken deployed to: 0xAb2A01BC351770D09611Ac80f1DE076D56E0487d
+```
+
+Ora prova a eseguire il test `simple.js` sulla tua dApp locale per confermare che ogni giocatore nella nostra dApp di Blackjack abbia 1000 token coniati per loro:
+
+L'output dovrebbe essere simile a questo:
+
+```python
+npx hardhat test --network localnet
+```
+
+L'output dovrebbe essere simile a questo:
+
+```python
+ChipToken
+ mint
+ ✔ should mint 1000 chips for PLAYER ONE
+
+ 1 passing (654ms)
+```
+
+### Revisione {#review-dapp-workflows}
+
+A questo punto, hai configurato un ambiente di sviluppo di dApp, lo hai connesso a una rete locale di Ethereum creata da Kurtosis e hai compilato, distribuito ed eseguito un semplice test sulla tua dApp.
+
+Ora esploriamo come puoi configurare la rete sottostante per testare le nostre dApp in diverse configurazioni di rete.
+
+## Configurare la rete di test locale di Ethereum {#configure-testnet}
+
+### Modificare le configurazioni dei client e il numero di nodi {#configure-client-config-and-num-nodes}
+
+La tua rete di test locale di Ethereum può essere configurata per utilizzare diverse coppie di client EL e CL, oltre a un numero variabile di nodi, a seconda dello scenario e della specifica configurazione di rete che desideri sviluppare o testare. Ciò significa che, una volta configurata, puoi avviare una rete di test locale personalizzata e utilizzarla per eseguire gli stessi flussi di lavoro (distribuzione, test, ecc.) in varie configurazioni di rete per assicurarti che tutto funzioni come previsto. Per saperne di più sugli altri parametri che puoi modificare, visita questo link.
+
+Fai una prova! Puoi passare varie opzioni di configurazione all'`eth-network-package` tramite un file JSON. Questo file JSON dei parametri di rete fornisce le configurazioni specifiche che Kurtosis utilizzerà per configurare la rete locale di Ethereum.
+
+Prendi il file di configurazione predefinito e modificalo per avviare due nodi con diverse coppie EL/CL:
+
+- Nodo 1 con `geth`/`lighthouse`
+- Nodo 2 con `geth`/`lodestar`
+- Nodo 3 con `geth`/`teku`
+
+Questa configurazione crea una rete eterogenea di implementazioni di nodi Ethereum per testare la tua dApp. Il tuo file di configurazione dovrebbe ora apparire così:
+
+```yaml
+{
+ "participants":
+ [
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "lighthouse",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "lodestar",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ {
+ "el_client_type": "geth",
+ "el_client_image": "",
+ "el_client_log_level": "",
+ "cl_client_type": "teku",
+ "cl_client_image": "",
+ "cl_client_log_level": "",
+ "beacon_extra_params": [],
+ "el_extra_params": [],
+ "validator_extra_params": [],
+ "builder_network_params": null,
+ },
+ ],
+ "network_params":
+ {
+ "preregistered_validator_keys_mnemonic": "giant issue aisle success illegal bike spike question tent bar rely arctic volcano long crawl hungry vocal artwork sniff fantasy very lucky have athlete",
+ "num_validator_keys_per_node": 64,
+ "network_id": "3151908",
+ "deposit_contract_address": "0x4242424242424242424242424242424242424242",
+ "seconds_per_slot": 12,
+ "genesis_delay": 120,
+ "capella_fork_epoch": 5,
+ },
+}
+```
+
+Ogni struttura `participants` è mappata a un nodo nella rete, quindi 3 strutture `participants` diranno a Kurtosis di avviare 3 nodi nella tua rete. Ogni struttura `participants` ti consentirà di specificare la coppia EL e CL utilizzata per quel nodo specifico.
+
+La struttura `network_params` configura le impostazioni di rete che vengono utilizzate per creare i file di genesi per ogni nodo, oltre ad altre impostazioni come i secondi per slot della rete.
+
+Salva il tuo file dei parametri modificato in qualsiasi directory desideri (nell'esempio seguente, è salvato sul desktop) e quindi utilizzalo per eseguire il tuo pacchetto Kurtosis eseguendo:
+
+```python
+kurtosis clean -a && kurtosis run --enclave local-eth-testnet github.com/kurtosis-tech/eth-network-package "$(cat ~/eth-network-params.json)"
+```
+
+Nota: il comando `kurtosis clean -a` viene utilizzato qui per istruire Kurtosis a distruggere la vecchia rete di test e i suoi contenuti prima di avviarne una nuova.
+
+Ancora una volta, Kurtosis lavorerà per un po' e stamperà i singoli passaggi che stanno avendo luogo. Alla fine, l'output dovrebbe essere simile a:
+
+```python
+Starlark code successfully run. No output was returned.
+INFO[2023-04-07T11:43:16-04:00] ==========================================================
+INFO[2023-04-07T11:43:16-04:00] || Created enclave: local-eth-testnet ||
+INFO[2023-04-07T11:43:16-04:00] ==========================================================
+Name: local-eth-testnet
+UUID: bef8c192008e
+Status: RUNNING
+Creation Time: Fri, 07 Apr 2023 11:41:58 EDT
+
+========================================= Files Artifacts =========================================
+UUID Name
+cc495a8e364a cl-genesis-data
+7033fcdb5471 el-genesis-data
+a3aef43fc738 genesis-generation-config-cl
+8e968005fc9d genesis-generation-config-el
+3182cca9d3cd geth-prefunded-keys
+8421166e234f prysm-password
+d9e6e8d44d99 validator-keystore-0
+23f5ba517394 validator-keystore-1
+4d28dea40b5c validator-keystore-2
+
+========================================== User Services ==========================================
+UUID Name Ports Status
+485e6fde55ae cl-client-0-beacon http: 4000/tcp -> http://127.0.0.1:65010 RUNNING
+ metrics: 5054/tcp -> http://127.0.0.1:65011
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65012
+ udp-discovery: 9000/udp -> 127.0.0.1:54455
+73739bd158b2 cl-client-0-validator http: 5042/tcp -> 127.0.0.1:65016 RUNNING
+ metrics: 5064/tcp -> http://127.0.0.1:65017
+1b0a233cd011 cl-client-1-beacon http: 4000/tcp -> 127.0.0.1:65021 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65023
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65024
+ udp-discovery: 9000/udp -> 127.0.0.1:56031
+ validator-metrics: 5064/tcp -> 127.0.0.1:65022
+949b8220cd53 cl-client-1-validator http: 4000/tcp -> 127.0.0.1:65028 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65030
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65031
+ udp-discovery: 9000/udp -> 127.0.0.1:60784
+ validator-metrics: 5064/tcp -> 127.0.0.1:65029
+c34417bea5fa cl-client-2 http: 4000/tcp -> 127.0.0.1:65037 RUNNING
+ metrics: 8008/tcp -> 127.0.0.1:65035
+ tcp-discovery: 9000/tcp -> 127.0.0.1:65036
+ udp-discovery: 9000/udp -> 127.0.0.1:63581
+e19738e6329d el-client-0 engine-rpc: 8551/tcp -> 127.0.0.1:64986 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:64988
+ tcp-discovery: 30303/tcp -> 127.0.0.1:64987
+ udp-discovery: 30303/udp -> 127.0.0.1:55706
+ ws: 8546/tcp -> 127.0.0.1:64989
+e904687449d9 el-client-1 engine-rpc: 8551/tcp -> 127.0.0.1:64993 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:64995
+ tcp-discovery: 30303/tcp -> 127.0.0.1:64994
+ udp-discovery: 30303/udp -> 127.0.0.1:58096
+ ws: 8546/tcp -> 127.0.0.1:64996
+ad6f401126fa el-client-2 engine-rpc: 8551/tcp -> 127.0.0.1:65003 RUNNING
+ rpc: 8545/tcp -> 127.0.0.1:65001
+ tcp-discovery: 30303/tcp -> 127.0.0.1:65000
+ udp-discovery: 30303/udp -> 127.0.0.1:57269
+ ws: 8546/tcp -> 127.0.0.1:65002
+12d04a9dbb69 prelaunch-data-generator-1680882122181135513 STOPPED
+5b45f9c0504b prelaunch-data-generator-1680882122192182847 STOPPED
+3d4aaa75e218 prelaunch-data-generator-1680882122201668972 STOPPED
+```
+
+Congratulazioni! Hai configurato con successo la tua rete di test locale per avere 3 nodi invece di 1. Per eseguire gli stessi flussi di lavoro che hai fatto prima sulla tua dApp (distribuzione e test), esegui le stesse operazioni che abbiamo fatto prima sostituendo `<$YOUR_PORT>` nella struttura `localnet` nel tuo file di configurazione `hardhat.config.ts` con la porta dell'URI RPC in output da qualsiasi servizio `el-client-` nella tua nuova rete di test locale a 3 nodi.
+
+## Conclusione {#conclusion}
+
+E questo è tutto! Per riassumere questa breve guida, hai:
+
+- Creato una rete di test locale di Ethereum su Docker utilizzando Kurtosis
+- Connesso il tuo ambiente di sviluppo di dApp locale alla rete locale di Ethereum
+- Distribuito una dApp ed eseguito un semplice test su di essa sulla rete locale di Ethereum
+- Configurato la rete Ethereum sottostante per avere 3 nodi
+
+Ci piacerebbe sapere da te cosa è andato bene, cosa potrebbe essere migliorato o rispondere a qualsiasi tua domanda. Non esitare a contattarci tramite [GitHub](https://github.com/kurtosis-tech/kurtosis/issues/new/choose) o [inviaci un'e-mail](mailto:feedback@kurtosistech.com)!
+
+### Altri esempi e guide {#other-examples-guides}
+
+Ti invitiamo a dare un'occhiata alla nostra [guida rapida](https://docs.kurtosis.com/quickstart) (dove costruirai un database Postgres e un'API su di esso) e ai nostri altri esempi nel nostro [repository awesome-kurtosis](https://github.com/kurtosis-tech/awesome-kurtosis) dove troverai alcuni ottimi esempi, inclusi pacchetti per:
+
+- [Avviare la stessa rete di test locale di Ethereum](https://github.com/kurtosis-tech/eth2-package), ma con servizi aggiuntivi connessi come uno spammer di transazioni (per simulare transazioni), un monitor di biforcazione e un'istanza Grafana e Prometheus connessa
+- Eseguire un [test di sotto-rete](https://github.com/kurtosis-tech/awesome-kurtosis/tree/main/ethereum-network-partition-test) sulla stessa rete locale di Ethereum
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md b/public/content/translations/it/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md
index 5594e708601..8b45b6797df 100644
--- a/public/content/translations/it/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md
+++ b/public/content/translations/it/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md
@@ -1,14 +1,11 @@
---
-title: "Ridimensionare i contratti per combattere i limiti di dimensioni"
-description: Cosa puoi fare per impedire che i tuoi smart contract diventino troppo grandi?
+title: "Ridurre le dimensioni dei contratti per combattere il limite di dimensione del contratto"
+description: Cosa puoi fare per evitare che i tuoi contratti intelligenti diventino troppo grandi?
author: Markus Waas
lang: it
-tags:
- - "solidity"
- - "contratti intelligenti"
- - "archiviazione"
+tags: ["Solidity", "contratti intelligenti", "archiviazione"]
skill: intermediate
-breadcrumb: "Ridurre i contratti"
+breadcrumb: Ridurre le dimensioni dei contratti
published: 2020-06-26
source: soliditydeveloper.com
sourceUrl: https://soliditydeveloper.com/max-contract-size
@@ -16,46 +13,44 @@ sourceUrl: https://soliditydeveloper.com/max-contract-size
## Perché c'è un limite? {#why-is-there-a-limit}
-Il [22 Novembre 2016](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon), la diramazione permanente Spurious Dragon ha introdotto [EIP-170](https://eips.ethereum.org/EIPS/eip-170), che ha aggiunto un limite di dimensioni per gli smart contract di 24.576 kb. Per gli sviluppatori in Solidity, significa che quando si aggiungono più funzionalità al contratto, a un certo punto si raggiunge il limite e, in fase di implementazione, si vedrà l'errore:
+Il [22 novembre 2016](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon) la biforcazione hard Spurious Dragon ha introdotto l'[EIP-170](https://eips.ethereum.org/EIPS/eip-170) che ha aggiunto un limite di dimensione del contratto intelligente di 24,576 kb. Per te come sviluppatore Solidity questo significa che quando aggiungi sempre più funzionalità al tuo contratto, a un certo punto raggiungerai il limite e durante la distribuzione vedrai l'errore:
-`Attenzione: La dimensione del codice del contratto eccede i 24576 byte (un limite introdotto in Spurious Dragon). This contract may not be deployable on Mainnet. Considera di abilitare l'ottimizzatore (con un valore di "esecuzioni" basso!), disattivare le stringhe di ripristino o usare le librerie.`
+`Warning: Contract code size exceeds 24576 bytes (a limit introduced in Spurious Dragon). This contract may not be deployable on Mainnet. Consider enabling the optimizer (with a low "runs" value!), turning off revert strings, or using libraries.`
-Questo limite è stato introdotto per prevenire gli attacchi DOS (denial-of-service). Qualsiasi chiamata a un contratto è relativamente economica in termini di gas. Tuttavia, l'impatto della chiamata di un contratto per i nodi di Ethereum aumenta sproporzionatamente in base alla dimensione del codice del contratto chiamato (lettura del codice dal disco, pre-elaborazione del codice, aggiunta di dati alla prova di Merkle). Ogni volta che ti trovi in una situazione in cui il malintenzionato richiede poche risorse per causare molto lavoro per altri, esiste il potenziale di attacchi DOS.
+Questo limite è stato introdotto per prevenire attacchi denial-of-service (DOS). Qualsiasi chiamata a un contratto è relativamente economica in termini di gas. Tuttavia, l'impatto di una chiamata al contratto per i nodi di Ethereum aumenta in modo sproporzionato a seconda delle dimensioni del codice del contratto chiamato (lettura del codice dal disco, pre-elaborazione del codice, aggiunta di dati alla prova di Merkle). Ogni volta che si verifica una situazione in cui l'attaccante richiede poche risorse per causare molto lavoro agli altri, si ottiene il potenziale per attacchi DOS.
-In origine, questo era un problema minore, dato che il limite naturale di dimensioni del contratto è il limite di gas del blocco. Ovviamente, un contratto dev'esser distribuito entro una transazione che detenga tutto il codice del byte del contratto. Se includi solo quella transazione in un blocco, puoi usare anche tutto il gas, ma non è infinito. Dall'[Aggiornamento di Londra](/ethereum-forks/#london), il limite di gas del blocco è stato capace di variare tra le 15M e le 30M unità, a seconda della domanda di rete.
+In origine questo era un problema minore perché un limite naturale alle dimensioni del contratto è il limite del gas del blocco. Ovviamente, un contratto deve essere distribuito all'interno di una transazione che contiene tutto il bytecode del contratto. Se includi solo quella transazione in un blocco, puoi consumare tutto quel gas, ma non è infinito. A partire dall'[Aggiornamento di Londra](/ethereum-forks/#london), il limite del gas del blocco ha potuto variare tra 15M e 30M di unità a seconda della domanda della rete.
-Di seguito, passeremo in rassegna alcuni metodi, ordinati in base al loro impatto potenziale. Pensiamo ad esempio alla perdita di peso: la strategia migliore per raggiungere il proprio peso target (nel nostro caso 24kb) consiste nel concentrarsi prima sui metodi a maggiore impatto. In gran parte dei casi è sufficiente adattare la propria dieta, mentre in altri serve qualcosa di più. Si può aggiungere un po' di esercizio fisico (impatto medio) o persino degli integratori (impatto ridotto).
+Di seguito esamineremo alcuni metodi ordinati in base al loro potenziale impatto. Pensaci in termini di perdita di peso. La strategia migliore per raggiungere il proprio peso forma (nel nostro caso 24kb) è concentrarsi prima sui metodi a grande impatto. Nella maggior parte dei casi, basta sistemare la dieta per arrivarci, ma a volte serve un po' di più. Quindi potresti aggiungere un po' di esercizio fisico (impatto medio) o persino degli integratori (impatto basso).
-## Impatto elevato {#big-impact}
+## Grande impatto {#big-impact}
### Separa i tuoi contratti {#separate-your-contracts}
-Questo dovrebbe sempre essere l'approccio preferenziale. Come fare per separare un unico contratto in diversi contratti più piccoli? Generalmente è necessario trovare un'architettura efficace per i propri contratti. I contratti più piccoli sono sempre preferibili a livello di leggibilità del codice. Per dividere i contratti, chiediti:
+Questo dovrebbe sempre essere il tuo primo approccio. Come puoi separare il contratto in più contratti più piccoli? In genere ti costringe a ideare una buona architettura per i tuoi contratti. I contratti più piccoli sono sempre preferiti dal punto di vista della leggibilità del codice. Per dividere i contratti, chiediti:
-- Quali funzioni devono rimanere insieme? Ogni serie di funzioni potrebbe risultare più efficace in un contratto a sé stante.
-- Quali funzioni non richiedono la lettura dello stato del contratto o solo un sottoinsieme specifico dello stato?
-- Puoi dividere archiviazione e funzionalità?
+- Quali funzioni appartengono allo stesso gruppo? Ogni insieme di funzioni potrebbe stare meglio nel proprio contratto.
+- Quali funzioni non richiedono la lettura dello stato del contratto o solo di un sottoinsieme specifico dello stato?
+- Puoi separare l'archiviazione e le funzionalità?
### Librerie {#libraries}
-Un modo semplice per togliere il codice di funzionalità dall'archiviazione consiste nell'utilizzare una [libreria](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries). Evita di dichiarare le funzioni della libreria come interne, poiché verranno [aggiunte al contratto](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking) direttamente durante la compilazione. Se invece usi funzioni pubbliche, queste si troveranno nel contratto di una libreria separata. Considera [using for](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for) per rendere l'utilizzo delle librerie più pratico.
+Un modo semplice per allontanare il codice delle funzionalità dall'archiviazione è utilizzare una [libreria](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#libraries). Non dichiarare le funzioni della libreria come interne, poiché queste verranno [aggiunte al contratto](https://ethereum.stackexchange.com/questions/12975/are-internal-functions-in-libraries-not-covered-by-linking) direttamente durante la compilazione. Ma se usi funzioni pubbliche, allora queste saranno di fatto in un contratto di libreria separato. Considera l'utilizzo di [using for](https://solidity.readthedocs.io/en/v0.6.10/contracts.html#using-for) per rendere più conveniente l'uso delle librerie.
### Proxy {#proxies}
-Una strategia più avanzata è il sistema proxy. Le librerie usano `DELEGATECALL` in background, che esegue semplicemente la funzione di un altro contratto con lo stato del contratto chiamante. Dai un'occhiata a [questo post del blog](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2) per scoprire di più sui sistemi proxy. Offono maggiore funzionalità, ad es. consentono l'aggiornabilità ma aggiungono anche una notevole complessità. Non li aggiungerei solo per ridurre le dimensioni del contratto, a meno che non sia la sola opzione per qualche motivo.
+Una strategia più avanzata sarebbe un sistema proxy. Le librerie usano `DELEGATECALL` in background, che esegue semplicemente la funzione di un altro contratto con lo stato del contratto chiamante. Dai un'occhiata a [questo post del blog](https://hackernoon.com/how-to-make-smart-contracts-upgradable-2612e771d5a2) per saperne di più sui sistemi proxy. Ti offrono maggiori funzionalità, ad esempio consentono l'aggiornabilità, ma aggiungono anche molta complessità. Non li aggiungerei solo per ridurre le dimensioni del contratto, a meno che non sia la tua unica opzione per qualsiasi motivo.
## Impatto medio {#medium-impact}
-### Rimuovi le funzioni {#remove-functions}
+### Rimuovi funzioni {#remove-functions}
-Questo punto dovrebbe essere ovvio. Le funzioni aumentano di un bel po' le dimensioni di un contratto.
+Questo dovrebbe essere ovvio. Le funzioni aumentano un bel po' le dimensioni di un contratto.
-- **Esterne**: talvolta aggiungiamo molte funzioni di visualizzazione per motivi di comodità, il che va perfettamente bene finché non si supera il limite di dimensioni. A quel punto si potrebbe seriamente pensare di rimuovere tutte le funzioni tranne quelle essenziali.
-- **Interne**: puoi rimuovere anche le funzioni interne/private e limitarti a mettere il codice in linea, a condizione che la funzione venga chiamata solo una volta.
+- **Esterne**: Spesso aggiungiamo molte funzioni di visualizzazione (view) per motivi di comodità. Va benissimo finché non si raggiunge il limite di dimensione. A quel punto potresti voler pensare seriamente di rimuovere tutte quelle non assolutamente essenziali.
+- **Interne**: Puoi anche rimuovere le funzioni interne/private e semplicemente inserire il codice in linea, a patto che la funzione venga chiamata solo una volta.
-### Evita le variabili aggiuntive {#avoid-additional-variables}
-
-Una semplice modifica come questa:
+### Evita variabili aggiuntive {#avoid-additional-variables}
```solidity
function get(uint id) returns (address,address) {
@@ -70,24 +65,23 @@ function get(uint id) returns (address,address) {
}
```
-crea una differenza di **0,28kb**. È facile incontrare numerose situazioni simili nei propri contratti, con il rischio che si sommino fino a raggiungere volumi significativi.
+Un semplice cambiamento come questo fa una differenza di **0,28kb**. È probabile che tu possa trovare molte situazioni simili nei tuoi contratti e queste possono davvero sommarsi fino a raggiungere quantità significative.
-### Abbrevia i messaggi d'errore {#shorten-error-message}
+### Accorcia i messaggi di errore {#shorten-error-message}
-I messaggi di ripristino lunghi e, in particolare, la presenza di numerosi messaggi diversi possono fare espandere il contratto. Invece, è meglio usare brevi codici d'errore e decodificali nel contratto. In questo modo è possibile rendere brevi i messaggi più lunghi:
+I messaggi di revert lunghi e in particolare molti messaggi di revert diversi possono gonfiare il contratto. Usa invece codici di errore brevi e decodificali nel tuo contratto. Un messaggio lungo potrebbe diventare molto più corto:
```solidity
require(msg.sender == owner, "Only the owner of this contract can call this function");
-
```
```solidity
require(msg.sender == owner, "OW1");
```
-### Utilizza gli errori personalizzati invece dei messaggi d'errore
+### Usa errori personalizzati invece di messaggi di errore
-Gli errori personalizzati sono stati introdotti in [Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/). Sono ottimi modi per ridurre le dimensioni dei tuoi contratti, poiché sono codificati in ABI come selettori (proprio come le funzioni).
+Gli errori personalizzati sono stati introdotti in [Solidity 0.8.4](https://blog.soliditylang.org/2021/04/21/custom-errors/). Sono un ottimo modo per ridurre le dimensioni dei tuoi contratti, perché sono codificati in ABI come selettori (proprio come lo sono le funzioni).
```solidity
error Unauthorized();
@@ -97,15 +91,15 @@ if (msg.sender != owner) {
}
```
-### Considera un valore d'esecuzione basso nell'ottimizzatore {#consider-a-low-run-value-in-the-optimizer}
+### Considera un valore di esecuzione basso nell'ottimizzatore {#consider-a-low-run-value-in-the-optimizer}
-Puoi anche cambiare le impostazioni dell'ottimizzatore. Il valore predefinito di 200 significa che sta provando a ottimizzare il bytecode come se una funzione fosse chiamata 200 volte. Se lo modifichi a 1, fondamentalmente dici all'ottimizzatore di ottimizzare nel caso dell'esecuzione di ogni funzione una sola volta. Una funzione ottimizzata per essere eseguita solo una volta è ottimizzata per la distribuzione stessa. Sappi che **ciò aumenta i [costi del gas](/developers/docs/gas/) per l'esecuzione delle funzioni**, quindi meglio non farlo.
+Puoi anche modificare le impostazioni dell'ottimizzatore. Il valore predefinito di 200 significa che sta cercando di ottimizzare il bytecode come se una funzione venisse chiamata 200 volte. Se lo modifichi a 1, in pratica dici all'ottimizzatore di ottimizzare per il caso in cui ogni funzione venga eseguita solo una volta. Una funzione ottimizzata per essere eseguita una sola volta significa che è ottimizzata per la distribuzione stessa. Tieni presente che **questo aumenta i [costi del gas](/developers/docs/gas/) per l'esecuzione delle funzioni**, quindi potresti non volerlo fare.
-## Piccolo impatto {#small-impact}
+## Impatto basso {#small-impact}
-### Evita il passaggio di struct alle funzioni {#avoid-passing-structs-to-functions}
+### Evita di passare struct alle funzioni {#avoid-passing-structs-to-functions}
-Se utilizzi l'[ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2), può essere utile evitare il passaggio di struct a una funzione. Anziché passare il parametro come struct...
+Se stai utilizzando l'[ABIEncoderV2](https://solidity.readthedocs.io/en/v0.6.10/layout-of-source-files.html#abiencoderv2), può essere utile non passare struct a una funzione. Invece di passare il parametro come struct, passa direttamente i parametri richiesti. In questo esempio abbiamo risparmiato un altro **0,1kb**.
```solidity
function get(uint id) returns (address,address) {
@@ -127,12 +121,10 @@ function _get(address addr1, address addr2) private view returns(address,address
}
```
-... passa direttamente i parametri richiesti. In questo esempio abbiamo risparmiato altri **0,1kb**.
-
### Dichiara la visibilità corretta per funzioni e variabili {#declare-correct-visibility-for-functions-and-variables}
-- Funzioni o variabili chiamate solo dall'esterno? Dichiarale come `external` anziché `public`.
-- Funzioni o variabili chiamate dall'interno del contratto? Dichiarale come `private` o `internal` anziché `public`.
+- Funzioni o variabili che vengono chiamate solo dall'esterno? Dichiarale come `external` invece di `public`.
+- Funzioni o variabili chiamate solo dall'interno del contratto? Dichiarale come `private` o `internal` invece di `public`.
### Rimuovi i modificatori {#remove-modifiers}
@@ -150,4 +142,4 @@ function checkStuff() private {}
function doSomething() { checkStuff(); }
```
-Questi suggerimenti dovrebbero aiutarti a ridurre significativamente le dimensioni del contratto. Ancora una volta, non smetterò mai di insistere sull'importanza di concentrarsi sempre sulla divisione dei contratti, se possibile, per avere il massimo impatto.
+Questi suggerimenti dovrebbero aiutarti a ridurre significativamente le dimensioni del contratto. Ancora una volta, non lo sottolineerò mai abbastanza, concentrati sempre sulla divisione dei contratti, se possibile, per ottenere l'impatto maggiore.
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/eip-1271-smart-contract-signatures/index.md b/public/content/translations/it/developers/tutorials/eip-1271-smart-contract-signatures/index.md
index 0f3c6f62491..2f7a868ca39 100644
--- a/public/content/translations/it/developers/tutorials/eip-1271-smart-contract-signatures/index.md
+++ b/public/content/translations/it/developers/tutorials/eip-1271-smart-contract-signatures/index.md
@@ -1,67 +1,63 @@
---
-title: "EIP-1271: firmare e verificare le firme dei contratti intelligenti"
-description: Una panoramica della generazione e della verifica delle firme dei contratti intelligenti con EIP-1271. Rivediamo anche l'implementazione di EIP-1271 utilizzata in Safe (precedentemente Gnosis Safe) per fornire un esempio concreto agli sviluppatori di contratti intelligenti su cui costruire.
+title: "EIP-1271: Firmare e Verificare le Firme dei Contratti Intelligenti"
+description: Una panoramica sulla generazione e verifica delle firme dei contratti intelligenti con l'EIP-1271. Esaminiamo anche l'implementazione dell'EIP-1271 utilizzata in Safe (precedentemente Gnosis Safe) per fornire un esempio concreto su cui gli sviluppatori di contratti intelligenti possono basarsi.
author: Nathan H. Leung
lang: it
-tags:
- - "eip-1271"
- - "contratti intelligenti"
- - "verifica"
- - "firma"
+tags: ["eip-1271", "contratti intelligenti", "verifica", "firma"]
skill: intermediate
-breadcrumb: "Firme EIP-1271"
+breadcrumb: Firme EIP-1271
published: 2023-01-12
---
-Lo standard [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) permette ai contratti intelligenti di verificare le firme.
+Lo standard [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) consente ai contratti intelligenti di verificare le firme.
-In questo tutorial diamo una panoramica delle firme digitali, conoscenze di base su EIP-1271 e l'implementazione specifica di EIP-1271 utilizzata da [Safe](https://safe.global/) (precedentemente Gnosis Safe). Tutto ciò può servire come punto di partenza per implementare EIP-1271 nei tuoi contratti.
+In questo tutorial, forniamo una panoramica delle firme digitali, del contesto dell'EIP-1271 e dell'implementazione specifica dell'EIP-1271 utilizzata da [Safe](https://safe.global/) (precedentemente Gnosis Safe). Tutto questo può servire come punto di partenza per implementare l'EIP-1271 nei propri contratti.
-## Che cos'è una firma?
+## Cos'è una firma?
-In questo contesto una firma (più precisamente una "firma digitale") è un messaggio con in più una sorta di prova che quel messaggio arriva da una specifica persona/mittente/indirizzo.
+In questo contesto, una firma (più precisamente, una "firma digitale") è un messaggio più una sorta di prova che il messaggio provenga da una persona/mittente/indirizzo specifico.
-Ad esempio, una firma digitale potrebbe essere così:
+Ad esempio, una firma digitale potrebbe apparire così:
-1. Messaggio: "Voglio accedere a questo sito web con il mio portafoglio di Ethereum."
+1. Messaggio: "Voglio accedere a questo sito web con il mio portafoglio Ethereum."
2. Firmatario: Il mio indirizzo è `0x000…`
-3. Prova: Qui c'è una prova che io, `0x000…`, ho effettivamente creato questo intero messaggio (questo di solito è qualcosa di crittografico).
+3. Prova: Ecco alcune prove che io, `0x000…`, ho effettivamente creato l'intero messaggio (di solito si tratta di qualcosa di crittografico).
È importante notare che una firma digitale include sia un "messaggio" che una "firma".
-Perché? Ad esempio, se tu mi dessi un contratto da firmare, e poi io tagliassi via la pagina con la firma e te lo restituissi solo con le mie firme senza il resto del contratto, il contratto non sarebbe valido.
+Perché? Ad esempio, se mi dessi un contratto da firmare, e poi io tagliassi la pagina della firma e ti restituissi solo le mie firme senza il resto del contratto, il contratto non sarebbe valido.
-Allo stesso modo una firma digitale non significa nulla senza un messaggio a essa associato!
+Allo stesso modo, una firma digitale non significa nulla senza un messaggio associato!
-## Perché esiste lo standard EIP-1271?
+## Perché esiste l'EIP-1271?
-Per creare una firma digitale che possa essere utilizzata su una blockchain basata su Ethereum, in linea generale si ha bisogno di una chiave privata che nessun altro conosca. Questo è ciò che rende tua la tua firma (nessun altro può creare la stessa firma senza sapere la chiave segreta).
+Per creare una firma digitale da utilizzare sulle blockchain basate su Ethereum, in genere è necessaria una chiave privata segreta che nessun altro conosce. Questo è ciò che rende la tua firma, tua (nessun altro può creare la stessa firma senza conoscere la chiave segreta).
-Il tuo conto di Ethereum (ovvero il tuo conto posseduto esternamente/EOA) ha una chiave privata associata, e questa è la chiave privata che tipicamente viene utilizzata quando un sito web o una dApp chiede la tua firma (ad es. per "Accedi con Ethereum").
+Il tuo account Ethereum (ovvero, il tuo account controllato esternamente/EOA) ha una chiave privata associata, e questa è la chiave privata che viene tipicamente utilizzata quando un sito web o una dApp ti chiede una firma (ad es., per "Accedi con Ethereum").
-Un'app può [verificare una firma](https://docs.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum) creata usando una libreria esterna come ether.js [senza conoscere la tua chiave privata](https://en.wikipedia.org/wiki/Public-key_cryptography) ed essere sicura che _tu_ sia la persona che ha generato la firma.
+Un'app può [verificare una firma](https://www.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum) che crei utilizzando una libreria di terze parti come ethers.js [senza conoscere la tua chiave privata](https://en.wikipedia.org/wiki/Public-key_cryptography) ed essere sicura che _tu_ sia stato colui che ha creato la firma.
-> Infatti siccome le firme digitali degli EOA utilizzano una crittografia a chiave pubblica, possono essere generate e verificate **fuori dalla catena**! Così funziona la votazione senza gas nelle DAO: invece di inviare voti sulla catena, le firme digitali possono creare e verificare fuori dalla catena utilizzando librerie crittografiche.
+> Infatti, poiché le firme digitali degli EOA utilizzano la crittografia a chiave pubblica, possono essere generate e verificate **fuori catena**! È così che funziona il voto delle DAO senza gas: invece di inviare i voti on-chain, le firme digitali possono essere create e verificate fuori catena utilizzando librerie crittografiche.
-Mentre i conti EOA hanno una chiave privata, i conti dei contratti intelligenti non hanno alcun tipo di chiave privata o segreta (quindi "Accedi con Ethereum", e simili non possono funzionare nativamente con i conti dei contratti intelligenti).
+Mentre gli account EOA hanno una chiave privata, gli account dei contratti intelligenti non hanno alcun tipo di chiave privata o segreta (quindi "Accedi con Ethereum", ecc. non può funzionare nativamente con gli account dei contratti intelligenti).
-Il problema che EIP-1271 si pone di risolvere: come possiamo essere sicuri che la firma di un contratto intelligente sia valida se il contratto intelligente non ha un "segreto" da incorporare nella firma?
+Il problema che l'EIP-1271 mira a risolvere: come possiamo dire che la firma di un contratto intelligente è valida se il contratto intelligente non ha alcun "segreto" che può incorporare nella firma?
-## Come funziona EIP-1271?
+## Come funziona l'EIP-1271?
-I contratti intelligenti non hanno chiavi private che possano essere usate per firmare i messaggi. Quindi come possiamo sapere se una firma è autentica?
+I contratti intelligenti non hanno chiavi private che possono essere utilizzate per firmare messaggi. Quindi come possiamo dire se una firma è autentica?
-Un'idea è che possiamo semplicemente _chiedere_ al contratto intelligente se una firma è autentica!
+Beh, un'idea è che possiamo semplicemente _chiedere_ al contratto intelligente se una firma è autentica!
-Quello che fa EIP-1271 è standardizzare l'idea di "chiedere" a un contratto intelligente se una data firma sia valida.
+Ciò che fa l'EIP-1271 è standardizzare questa idea di "chiedere" a un contratto intelligente se una data firma è valida.
-Un contratto che implementa EIP-1271 deve avere una funzione chiamata `isValidSignature` che accetti un messaggio e una firma. Il contratto può quindi eseguire qualche logica di validazione (le specifiche non impongono nulla di specifico qui) e restituire un valore che indica se la firma sia valida o meno.
+Un contratto che implementa l'EIP-1271 deve avere una funzione chiamata `isValidSignature` che accetta un messaggio e una firma. Il contratto può quindi eseguire una logica di convalida (la specifica non impone nulla di specifico qui) e quindi restituire un valore che indica se la firma è valida o meno.
-Se `isValidSignature` restituisce un risultato valido, significa che il contratto sta dicendo "sì, approvo questa firma + messaggio!"
+Se `isValidSignature` restituisce un risultato valido, è praticamente il contratto che dice "sì, approvo questa firma + messaggio!"
### Interfaccia
-Ecco l'interfaccia esatta presente nelle specifiche EIP-1271 (parleremo del parametro `_hash` più avanti, ma per adesso, puoi pensarlo come il messaggio che viene verificato):
+Ecco l'interfaccia esatta nella specifica EIP-1271 (parleremo del parametro `_hash` di seguito, ma per ora, pensalo come il messaggio che viene verificato):
```jsx
pragma solidity ^0.5.0;
@@ -71,15 +67,23 @@ contract ERC1271 {
// bytes4(keccak256("isValidSignature(bytes32,bytes)")
bytes4 constant internal MAGICVALUE = 0x1626ba7e;
- /**
- * @dev Should return whether the signature provided is valid for the provided hash
- * @param _hash Hash of the data to be signed
- * @param _signature Signature byte array associated with _hash
+ /* *
+ * @dev Dovrebbe restituire se la firma fornita è valida per l'hash fornito
+ * @param _hash Hash dei dati da firmare
+ * @param _signature Array di byte della firma associato a _hash
*
- * MUST return the bytes4 magic value 0x1626ba7e when function passes.
- * MUST NOT modify state (using STATICCALL for solc < 0.5, view modifier for solc > 0.5)
- * MUST allow external calls
- */
+ * DEVE restituire il valore magico bytes4 0x1626ba7e quando la funzione ha successo.
+ * NON DEVE modificare lo stato (usando STATICCALL per solc < 0.5, modificatore view per solc > 0.5)
+ * DEVE consentire chiamate esterne */
+
+
+
+
+
+
+
+
+
function isValidSignature(
bytes32 _hash,
bytes memory _signature)
@@ -89,40 +93,40 @@ contract ERC1271 {
}
```
-## Esempio di implementazione di EIP-1271: Safe
+## Esempio di Implementazione dell'EIP-1271: Safe
-I contratti possono implementare `isValidSignature` in diversi modi, le specifiche da sole non dicono molto riguardo l'esatta implementazione.
+I contratti possono implementare `isValidSignature` in molti modi: la specifica non dice molto sull'implementazione esatta.
-Un contratto degno di nota che implementa EIP-1271 è Safe (precedentemente Gnosis Safe).
+Un contratto degno di nota che implementa l'EIP-1271 è Safe (precedentemente Gnosis Safe).
Nel codice di Safe, `isValidSignature` [è implementata](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol) in modo che le firme possano essere create e verificate in [due modi](https://ethereum.stackexchange.com/questions/122635/signing-messages-as-a-gnosis-safe-eip1271-support):
1. Messaggi on-chain
- 1. Creazione: un proprietario sicuro crea una nuova transazione sicura per "firmare" il messaggio, passando il messaggio come dati nella transazione. Quando un numero sufficiente di proprietari firma la transazione per raggiungere la soglia multifirma, la transazione è trasmessa ed eseguita. Nella transazione viene chiamata una funzione sicura che aggiunge il messaggio all'elenco di messaggi "approvati".
- 2. Verifica: chiama `isValidSignature` sul contratto di Safe, passando il messaggio da verificare come parametro messaggio e [un valore vuoto per il parametro firma](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (ossia `0x`). Safe vedrà che il parametro firma è vuoto e invece di verificare in maniera crittografica la firma, saprà di dover andare avanti e controllare se il messaggio si trova nell'elenco di messaggi "approvati".
-2. Messaggi off-chain:
- 1. Creazione: un proprietario sicuro crea un messaggio off-chain, poi fa in modo che altri proprietari sicuri firmino il messaggio, ognuno individualmente, finché ci sono abbastanza firme per superare la soglia di approvazione multifirma.
- 2. Verifica: chiama `isValidSignature`. Nel parametro messaggio, passa il messaggio da verificare. Nel parametro firma, passa ognuna delle firme dei proprietari sicure tutte concatenate, una dietro l'altra. Safe controllerà che ci siano abbastanza firme per raggiungere la soglia **e** che ogni firma sia valida. Se è così, restituirà un valore che indica che la firma è stata verificata con successo.
+ 1. Creazione: un proprietario del safe crea una nuova transazione del safe per "firmare" un messaggio, passando il messaggio come dati nella transazione. Una volta che un numero sufficiente di proprietari firma la transazione per raggiungere la soglia della multifirma, la transazione viene trasmessa ed eseguita. Nella transazione, c'è una funzione del safe chiamata (`signMessage(bytes calldata _data)`) che aggiunge il messaggio a un elenco di messaggi "approvati".
+ 2. Verifica: chiama `isValidSignature` sul contratto Safe e passa il messaggio da verificare come parametro del messaggio e [un valore vuoto per il parametro della firma](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (ovvero, `0x`). Il Safe vedrà che il parametro della firma è vuoto e invece di verificare crittograficamente la firma, saprà di dover semplicemente procedere e controllare se il messaggio è nell'elenco dei messaggi "approvati".
+2. Messaggi fuori catena:
+ 1. Creazione: un proprietario del safe crea un messaggio fuori catena, quindi fa in modo che altri proprietari del safe firmino il messaggio ciascuno individualmente fino a quando non ci sono abbastanza firme per superare la soglia di approvazione della multifirma.
+ 2. Verifica: chiama `isValidSignature`. Nel parametro del messaggio, passa il messaggio da verificare. Nel parametro della firma, passa le singole firme di ciascun proprietario del safe tutte concatenate insieme, una dopo l'altra. Il Safe controllerà che ci siano abbastanza firme per soddisfare la soglia **e** che ogni firma sia valida. In tal caso, restituirà un valore che indica l'avvenuta verifica della firma.
-## Che cos'è esattamente il parametro `_hash`? Perché non passiamo l'intero messaggio?
+## Cos'è esattamente il parametro `_hash`? Perché non passare l'intero messaggio?
-Potresti aver notato che la funzione `isValidSignature` nell'[interfaccia EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) non prende il messaggio stesso bensì un parametro `_hash`. Questo significa che invece che passare l'intero messaggio di lunghezza arbitraria a `isValidSignature`, passiamo invece un hash di 32-byte del messaggio (generalmente keccak256).
+Potresti aver notato che la funzione `isValidSignature` nell'[interfaccia EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) non accetta il messaggio stesso, ma un parametro `_hash`. Ciò significa che invece di passare l'intero messaggio di lunghezza arbitraria a `isValidSignature`, passiamo invece un hash di 32 byte del messaggio (generalmente keccak256).
-Ogni byte di calldata – ovvero dati dei parametri della funzione passati a una funzione del contratto intelligente – [costa 16 unità di gas (4 unità di gas se sono zero byte)](https://eips.ethereum.org/EIPS/eip-2028), quindi in questo modo si può risparmiare molto gas se il messaggio è lungo.
+Ogni byte di calldata — ovvero, i dati dei parametri della funzione passati a una funzione del contratto intelligente — [costa 16 gas (4 gas se il byte è zero)](https://eips.ethereum.org/EIPS/eip-2028), quindi questo può far risparmiare molto gas se un messaggio è lungo.
-### Specifiche precedenti di EIP-1271
+### Specifiche Precedenti dell'EIP-1271
-Esistono specifiche di EIP-1271 che hanno la funzione `isValidSignature` con un primo parametro di tipo `bytes` (di lunghezza arbitraria invece che di lunghezza fissa `bytes32`) e un parametro nome `message`. Questa è una [versione precedente](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206) dello standard EIP-1271.
+Ci sono specifiche EIP-1271 in circolazione che hanno una funzione `isValidSignature` con un primo parametro di tipo `bytes` (lunghezza arbitraria, invece di un `bytes32` a lunghezza fissa) e nome del parametro `message`. Questa è una [versione precedente](https://github.com/safe-global/safe-contracts/issues/391#issuecomment-1075427206) dello standard EIP-1271.
-## Come dovrei implementare EIP-1271 nei miei contratti?
+## Come dovrebbe essere implementato l'EIP-1271 nei miei contratti?
-La specifica è molto flessibile in merito. L'implementazione di Safe ha alcune buone idee:
+La specifica è molto aperta qui. L'implementazione di Safe ha alcune buone idee:
-- È possibile considerare valide le firme EOA del "proprietario" del contratto.
-- Si potrebbe memorizzare un elenco di messaggi approvati e considerare validi solo quelli.
+- Puoi considerare valide le firme degli EOA del "proprietario" del contratto.
+- Potresti memorizzare un elenco di messaggi approvati e considerare validi solo quelli.
-Alla fine, dipende da te, in quanto sviluppatore del contratto!
+Alla fine, spetta a te come sviluppatore del contratto!
-## Conclusioni
+## Conclusione
-[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) è uno standard versatile che consente ai contratti intelligenti di verificare le firme. Apre la porta perché i contratti intelligenti agiscano in modo più simile agli EOA - ad esempio fornendo un modo per far funzionare "Accedi con Ethereum" con i contratti intelligenti - e può essere implementato in molti modi (Safe ha un'implementazione non banale e interessante da considerare).
+L'[EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) è uno standard versatile che consente ai contratti intelligenti di verificare le firme. Apre le porte affinché i contratti intelligenti agiscano in modo più simile agli EOA — ad esempio fornendo un modo per far funzionare "Accedi con Ethereum" con i contratti intelligenti — e può essere implementato in molti modi (Safe ha un'implementazione non banale e interessante da considerare).
\ No newline at end of file
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 5d200b803a3..7509998e705 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
@@ -1,32 +1,34 @@
---
-title: "Guisa sul Contratto ERC-721 Vyper"
+title: "Guida passo passo al contratto ERC-721 in Vyper"
description: Il contratto ERC-721 di Ryuya Nakamura e come funziona
author: Ori Pomerantz
lang: it
-tags:
- - "vyper"
- - "erc-721"
- - "python"
+tags: ["Vyper", "erc-721", "Python"]
skill: beginner
-breadcrumb: "Vyper ERC-721"
+breadcrumb: Vyper ERC-721
published: 2021-04-01
---
## Introduzione {#introduction}
-Lo standard [ERC-721](/developers/docs/standards/tokens/erc-721/) è utilizzato per determinare la proprietà di un Token Non Fungibile (NFT). I token [ERC-20](/developers/docs/standards/tokens/erc-20/) si comportano come una commodity, perché non c'è differenza tra i token individuali. Al contrario, i token ERC-721 sono progettati per risorse simili ma non identiche, come diversi [cat cartoon](https://www.cryptokitties.co/) o titoli di diverse proprietà immobiliari.
+Lo standard [ERC-721](/developers/docs/standards/tokens/erc-721/) è utilizzato per detenere la proprietà dei token non fungibili (NFT).
+I token [ERC-20](/developers/docs/standards/tokens/erc-20/) si comportano come una merce, perché non c'è differenza tra i singoli token.
+Al contrario, i token ERC-721 sono progettati per asset simili ma non identici, come diversi [gatti dei cartoni animati](https://www.cryptokitties.co/)
+o titoli di diverse proprietà immobiliari.
-In questo articolo analizzeremo [il contratto ERC-721 di Ryuya Nakamura](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy). Questo contratto è scritto in [Vyper](https://vyper.readthedocs.io/en/latest/index.html), un linguaggio per contratti simile a Python, pensato per rendere più difficile scrivere codice non sicuro rispetto a Solidity.
+In questo articolo analizzeremo [il contratto ERC-721 di Ryuya Nakamura](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy).
+Questo contratto è scritto in [Vyper](https://vyper.readthedocs.io/en/latest/index.html), un linguaggio per contratti simile a Python progettato per rendere più difficile scrivere codice insicuro rispetto a Solidity.
## Il contratto {#contract}
```python
-# @dev Implementation of ERC-721 non-fungible token standard.
+# @dev Implementazione dello standard dei token non fungibili ERC-721.
# @author Ryuya Nakamura (@nrryuya)
-# Modified from: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy
+# Modificato da: https://github.com/vyperlang/vyper/blob/de74722bf2d8718cca46902be165f9fe0e3641dd/examples/tokens/ERC721.vy
```
-I commenti in Vyper, come in Python, iniziano con un hash (`#`) e continuano fino alla fine della riga. I commenti che includono `@` sono usati da [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html) per produrre una documentazione leggibile.
+I commenti in Vyper, come in Python, iniziano con un cancelletto (`#`) e continuano fino alla fine della riga. I commenti che includono
+`@` sono utilizzati da [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html) per produrre documentazione leggibile dall'uomo.
```python
from vyper.interfaces import ERC721
@@ -34,22 +36,29 @@ from vyper.interfaces import ERC721
implements: ERC721
```
-L'interfaccia ERC-721 è creata nel linguaggio Vyper. [Puoi vedere qui la definizione del codice](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py). La definizione dell'interfaccia è scritta in Python, anziché in Vyper, perché le interfacce non sono usate solo nella blockchain, ma anche quando si invia una transazione alla blockchain da un client esterno, che potrebbe esser scritto in Python.
+L'interfaccia ERC-721 è integrata nel linguaggio Vyper.
+[Puoi vedere la definizione del codice qui](https://github.com/vyperlang/vyper/blob/master/vyper/builtin_interfaces/ERC721.py).
+La definizione dell'interfaccia è scritta in Python, anziché in Vyper, perché le interfacce sono utilizzate non solo all'interno della
+blockchain, ma anche quando si invia alla blockchain una transazione da un client esterno, che potrebbe essere scritto in
+Python.
-La prima riga importa l'interfaccia, la seconda specifica che la stiamo implementando qui.
+La prima riga importa l'interfaccia e la seconda specifica che la stiamo implementando qui.
### L'interfaccia ERC721Receiver {#receiver-interface}
```python
-# Interface for the contract called by safeTransferFrom()
+# Interfaccia per il contratto chiamato da safeTransferFrom()
interface ERC721Receiver:
def onERC721Received(
```
-ERC-721 supporta due tipi di trasferimento:
+L'ERC-721 supporta due tipi di trasferimento:
-- `transferFrom`, che consente al mittente di specificare qualsiasi indirizzo di destinazione e pone sul mittente la responsabilità del trasferimento. Ciò significa che puoi trasferire a un indirizzo non valido, nel qual caso l'NFT è perso definitivamente.
-- `safeTransferFrom`, che controlla se l'indirizzo di destinazione è un contratto. In tal caso, il contratto ERC-721 chiede al contratto ricevente se vuole ricevere l’NFT.
+- `transferFrom`, che consente al mittente di specificare qualsiasi indirizzo di destinazione e pone la responsabilità
+ del trasferimento sul mittente. Ciò significa che puoi trasferire a un indirizzo non valido, nel qual caso
+ l'NFT è perso per sempre.
+- `safeTransferFrom`, che controlla se l'indirizzo di destinazione è un contratto. In tal caso, il contratto ERC-721
+ chiede al contratto ricevente se desidera ricevere l'NFT.
Per rispondere alle richieste `safeTransferFrom`, un contratto ricevente deve implementare `ERC721Receiver`.
@@ -58,135 +67,165 @@ Per rispondere alle richieste `safeTransferFrom`, un contratto ricevente deve im
_from: address,
```
-L'indirizzo `_from` è il proprietario corrente del token. L'indirizzo `_operator` è quello che ha richiesto il trasferimento (i due potrebbero non corrispondere, a causa delle indennità).
+L'indirizzo `_from` è l'attuale proprietario del token. L'indirizzo `_operator` è quello che ha
+richiesto il trasferimento (questi due potrebbero non essere gli stessi, a causa delle autorizzazioni).
```python
_tokenId: uint256,
```
-Gli ID del token ERC-721 sono a 256 bit. Solitamente sono creati mediante hashing di una descrizione di qualsiasi token rappresenti.
+Gli ID dei token ERC-721 sono a 256 bit. In genere vengono creati eseguendo l'hash di una descrizione di ciò che
+il token rappresenta.
```python
_data: Bytes[1024]
```
-La richiesta può avere fino a 1024 byte di dati utente.
+La richiesta può contenere fino a 1024 byte di dati utente.
```python
) -> bytes32: view
```
-Per impedire casi la possibilità che un contratto accetti accidentalmente un trasferimento, il valore restituito non è booleano, ma 256 bit con un valore specifico.
+Per prevenire i casi in cui un contratto accetta accidentalmente un trasferimento, il valore di ritorno non è un booleano,
+ma 256 bit con un valore specifico.
-Questa funzione è una `view`, ovvero può leggere lo stato della blockchain, ma non modificarlo.
+Questa funzione è una `view`, il che significa che può leggere lo stato della blockchain, ma non modificarlo.
### Eventi {#events}
-Gli [eventi](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e) sono emessi per informare gli utenti e i server al di fuori della blockchain degli eventi. Nota che il contenuto degli eventi non è disponibile per i contratti sulla blockchain.
+Gli [eventi](https://media.consensys.net/technical-introduction-to-events-and-logs-in-ethereum-a074d65dd61e)
+vengono emessi per informare gli utenti e i server all'esterno della blockchain degli eventi. Nota che il contenuto degli eventi
+non è disponibile per i contratti sulla blockchain.
```python
-# @dev Emits when ownership of any NFT changes by any mechanism. This event emits when NFTs are
-# created (`from` == 0) and destroyed (`to` == 0). Exception: during contract creation, any
-# number of NFTs may be created and assigned without emitting Transfer. At the time of any
-# transfer, the approved address for that NFT (if any) is reset to none.
-# @param _from Sender of NFT (if address is zero address it indicates token creation).
-# @param _to Receiver of NFT (if address is zero address it indicates token destruction).
-# @param _tokenId The NFT that got transferred.
+# @dev Emesso quando la proprietà di qualsiasi NFT cambia tramite qualsiasi meccanismo. Questo evento viene emesso quando gli NFT vengono
+# creati (`from` == 0) e distrutti (`to` == 0). Eccezione: durante la creazione del contratto, qualsiasi
+# numero di NFT può essere creato e assegnato senza emettere Transfer. Al momento di qualsiasi
+# trasferimento, l'indirizzo approvato per quell'NFT (se presente) viene reimpostato a nessuno.
+# @param _from Mittente dell'NFT (se l'indirizzo è l'indirizzo zero indica la creazione del token).
+# @param _to Ricevitore dell'NFT (se l'indirizzo è l'indirizzo zero indica la distruzione del token).
+# @param _tokenId L'NFT che è stato trasferito.
event Transfer:
sender: indexed(address)
receiver: indexed(address)
tokenId: indexed(uint256)
```
-Questo è simile all'evento di Trasferimento dell'ERC-20, tranne per il fatto che segnaliamo un `tokenId` anziché un importo. Nessuno possiede l'indirizzo zero, quindi per convenzione lo usiamo per segnalare la creazione e distruzione dei token.
+Questo è simile all'evento Transfer dell'ERC-20, tranne per il fatto che riportiamo un `tokenId` invece di un importo.
+Nessuno possiede l'indirizzo zero, quindi per convenzione lo usiamo per segnalare la creazione e la distruzione dei token.
```python
-# @dev This emits when the approved address for an NFT is changed or reaffirmed. The zero
-# address indicates there is no approved address. When a Transfer event emits, this also
-# indicates that the approved address for that NFT (if any) is reset to none.
-# @param _owner Owner of NFT.
-# @param _approved Address that we are approving.
-# @param _tokenId NFT which we are approving.
+# @dev Questo viene emesso quando l'indirizzo approvato per un NFT viene modificato o riaffermato. L'indirizzo
+# zero indica che non c'è alcun indirizzo approvato. Quando viene emesso un evento Transfer, questo
+# indica anche che l'indirizzo approvato per quell'NFT (se presente) viene reimpostato a nessuno.
+# @param _owner Proprietario dell'NFT.
+# @param _approved Indirizzo che stiamo approvando.
+# @param _tokenId NFT che stiamo approvando.
event Approval:
owner: indexed(address)
approved: indexed(address)
tokenId: indexed(uint256)
```
-L'approvazione di un ERC-721 è simile a un'indennità dell'ERC-20. Un indirizzo specifico può trasferire un token specifico. Questo offre ai contratti un meccanismo per rispondere quando accettano un token. I contratti non possono ascoltare gli eventi, quindi se semplicemente trasferisci loro il token, non lo "sanno". In questo modo, il proprietario invia prima un'approvazione e poi una richiesta al contratto: "Ho approvato il tuo trasferimento del token X, sei pregato di...".
+Un'approvazione ERC-721 è simile a un'autorizzazione (allowance) ERC-20. A un indirizzo specifico è consentito trasferire un token
+specifico. Questo fornisce un meccanismo ai contratti per rispondere quando accettano un token. I contratti non possono
+ascoltare gli eventi, quindi se trasferisci semplicemente il token a loro, non ne "sanno" nulla. In questo modo il
+proprietario invia prima un'approvazione e poi invia una richiesta al contratto: "Ho approvato il trasferimento del token
+X da parte tua, per favore procedi...".
-Si tratta di una scelta di progettazione per rendere lo standard ERC-721 simile allo standard ERC-20. Poiché i token di ERC-721 non sono fungibili, un contratto può capire di aver ricevuto un token specifico anche guardando alle sue proprietà.
+Questa è una scelta di progettazione per rendere lo standard ERC-721 simile allo standard ERC-20. Poiché
+i token ERC-721 non sono fungibili, un contratto può anche identificare di aver ottenuto un token specifico
+esaminando la proprietà del token.
```python
-# @dev This emits when an operator is enabled or disabled for an owner. The operator can manage
-# all NFTs of the owner.
-# @param _owner Owner of NFT.
-# @param _operator Address to which we are setting operator rights.
-# @param _approved Status of operator rights(true if operator rights are given and false if
-# revoked).
+# @dev Questo viene emesso quando un operatore viene abilitato o disabilitato per un proprietario. L'operatore può gestire
+# tutti gli NFT del proprietario.
+# @param _owner Proprietario dell'NFT.
+# @param _operator Indirizzo al quale stiamo impostando i diritti di operatore.
+# @param _approved Stato dei diritti dell'operatore (true se i diritti dell'operatore sono concessi e false se
+# revocati).
event ApprovalForAll:
owner: indexed(address)
operator: indexed(address)
approved: bool
```
-Talvolta, è utile avere un _operatore_, che possa gestire tutti i token di un conto di un tipo specifico (quelli gestiti da un contratto specifico), similmente a una delega. Ad esempio, potrei voler dare a un contratto una delega per verificare se non l'ho contattato per sei mesi e, in questo caso, distribuisce le mie risorse ai miei eredi (se uno di loro lo richiede, i contratti non possono fare niente senza esser chiamati da una transazione). In ERC-20 possiamo solo dare un'indennità elevata a un contratto di ereditarietà, ma questo non funziona per ERC-721 perché i token non sono fungibili. Questo è l'equivalente.
+A volte è utile avere un _operatore_ che possa gestire tutti i token di un account di un tipo specifico (quelli gestiti da
+un contratto specifico), in modo simile a una procura. Ad esempio, potrei voler dare tale potere a un contratto che controlla se
+non l'ho contattato per sei mesi e, in tal caso, distribuisce i miei beni ai miei eredi (se uno di loro lo chiede, i contratti
+non possono fare nulla senza essere chiamati da una transazione). Nell'ERC-20 possiamo semplicemente dare un'alta autorizzazione a un contratto di eredità,
+ma questo non funziona per l'ERC-721 perché i token non sono fungibili. Questo è l'equivalente.
-Il valore `approved` ci comunica se l'evento è per un'approvazione, o la revoca di un'approvazione.
+Il valore `approved` ci dice se l'evento riguarda un'approvazione o il ritiro di un'approvazione.
### Variabili di stato {#state-vars}
-Queste variabili contengono lo stato corrente dei token: quali sono disponibili e chi li possiede. Gran parte di questi sono oggetti di `HashMap`, [mappature unidirezionali che esistono tra due tipi](https://vyper.readthedocs.io/en/latest/types.html#mappings).
+Queste variabili contengono lo stato attuale dei token: quali sono disponibili e chi li possiede. La maggior parte di questi
+sono oggetti `HashMap`, [mappature unidirezionali che esistono tra due tipi](https://vyper.readthedocs.io/en/latest/types.html#mappings).
```python
-# @dev Mapping from NFT ID to the address that owns it.
+# @dev Mappatura dall'ID dell'NFT all'indirizzo che lo possiede.
idToOwner: HashMap[uint256, address]
-# @dev Mapping from NFT ID to approved address.
+# @dev Mappatura dall'ID dell'NFT all'indirizzo approvato.
idToApprovals: HashMap[uint256, address]
```
-Le identità dell'utente e del contratto su Ethereum sono rappresentate da indirizzi a 160 bit. Queste due variabili mappano gli ID dei token con i loro proprietari e quelli approvati per trasferirli (a un massimo di uno ciascuno). In Ethereum, i dati non inizializzati sono sempre zero, quindi se non c'è alcun proprietario o trasferente approvato, il valore per quel token è zero.
+Le identità degli utenti e dei contratti in Ethereum sono rappresentate da indirizzi a 160 bit. Queste due variabili mappano
+dagli ID dei token ai loro proprietari e a coloro che sono approvati per trasferirli (al massimo uno per ciascuno). In Ethereum,
+i dati non inizializzati sono sempre zero, quindi se non c'è un proprietario o un trasferitore approvato, il valore per quel token
+è zero.
```python
-# @dev Mapping from owner address to count of his tokens.
+# @dev Mappatura dall'indirizzo del proprietario al conteggio dei suoi token.
ownerToNFTokenCount: HashMap[address, uint256]
```
-Questa variabile tiene conto dei token per ogni proprietario. Non c'è alcuna mappatura dai proprietari ai token, quindi l'unico modo per identificare i token che un proprietario specifico possiede è guardare alla cronologia di eventi della blockchain e vedere gli eventi di `trasferimento` appropriati. Possiamo usare questa variabile per sapere quando abbiamo tutti gli NFT e non dobbiamo guardare oltre nel tempo.
+Questa variabile contiene il conteggio dei token per ogni proprietario. Non c'è alcuna mappatura dai proprietari ai token, quindi
+l'unico modo per identificare i token posseduti da un proprietario specifico è guardare indietro nella cronologia degli eventi della blockchain
+e vedere gli eventi `Transfer` appropriati. Possiamo usare questa variabile per sapere quando abbiamo tutti gli NFT e non
+abbiamo bisogno di guardare ancora più indietro nel tempo.
-Questo algoritmo funziona solo per le interfacce utente e i server esterni. Il codice in esecuzione sulla blockchain stessa non può leggere gli eventi passati.
+Nota che questo algoritmo funziona solo per le interfacce utente e i server esterni. Il codice in esecuzione sulla blockchain
+stessa non può leggere gli eventi passati.
```python
-# @dev Mapping from owner address to mapping of operator addresses.
+# @dev Mappatura dall'indirizzo del proprietario alla mappatura degli indirizzi degli operatori.
ownerToOperators: HashMap[address, HashMap[address, bool]]
```
-Un conto potrebbe avere più di un singolo operatore. Un semplice `HashMap` è insufficiente per tenerne traccia, perché ogni chiave conduce a un valore singolo. Invece, puoi usare `HashMap[address, bool]` come valore. Di default, il valore per ogni indirizzo è `False`, che significa che non è un operatore. Puoi impostare i valori a `True` se necessario.
+Un account può avere più di un singolo operatore. Una semplice `HashMap` è insufficiente per
+tenerne traccia, perché ogni chiave porta a un singolo valore. Invece, puoi usare
+`HashMap[address, bool]` come valore. Per impostazione predefinita, il valore per ogni indirizzo è `False`, il che significa che
+non è un operatore. Puoi impostare i valori su `True` secondo necessità.
```python
-# @dev Address of minter, who can mint a token
+# @dev Indirizzo del minter, che può coniare un token
minter: address
```
-I nuovi token devono in qualche modo esser creati. In questo contratto, esiste solo un'entità che può farlo, il `coniatore`. Questo sarà probabilmente sufficiente per un gioco, ad esempio. Per altri scopi, potrebbe esser necessario creare una logica di business più complicata.
+I nuovi token devono essere creati in qualche modo. In questo contratto c'è una singola entità a cui è consentito farlo, il
+`minter` (coniatore). Questo è probabilmente sufficiente per un gioco, ad esempio. Per altri scopi, potrebbe essere necessario
+creare una logica di business più complicata.
```python
-# @dev Mapping of interface id to bool about whether or not it's supported
+# @dev Mappatura dell'id dell'interfaccia a bool per indicare se è supportata o meno
supportedInterfaces: HashMap[bytes32, bool]
-# @dev ERC165 interface ID of ERC165
+# @dev ID dell'interfaccia ERC165 di ERC165
ERC165_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000001ffc9a7
-# @dev ERC165 interface ID of ERC721
+# @dev ID dell'interfaccia ERC165 di ERC721
ERC721_INTERFACE_ID: constant(bytes32) = 0x0000000000000000000000000000000000000000000000000000000080ac58cd
```
-[ERC-165](https://eips.ethereum.org/EIPS/eip-165) specifica un meccanismo con cui un contratto può rivelare come le applicazioni possono comunicare con esso, a quali ERC è conforme. In questo caso, il contratto è conforme a ERC-165 ed ERC-721.
+L'[ERC-165](https://eips.ethereum.org/EIPS/eip-165) specifica un meccanismo per un contratto per rivelare come le applicazioni
+possono comunicare con esso, a quali ERC è conforme. In questo caso, il contratto è conforme a ERC-165 ed ERC-721.
### Funzioni {#functions}
-Queste sono le funzioni che implementano effettivamente ERC-721.
+Queste sono le funzioni che implementano effettivamente l'ERC-721.
#### Costruttore {#constructor}
@@ -195,15 +234,18 @@ Queste sono le funzioni che implementano effettivamente ERC-721.
def __init__():
```
-In Vyper, come in Python, la funzione del costruttore è chiamata `__init__`.
+In Vyper, come in Python, la funzione costruttore è chiamata `__init__`.
```python
- """
- @dev Contract constructor.
- """
+ # @dev Costruttore del contratto.
+
+
+
```
-Su Python e su Vyper, puoi anche creare un commento specificando una stringa su più righe (che inizia e termina per `"""`), senza usarla in alcun modo. Questi commenti possono anche includere [NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html).
+In Python e in Vyper, puoi anche creare un commento specificando una stringa multilinea (che inizia e finisce
+con `"""`) e non utilizzandola in alcun modo. Questi commenti possono includere anche
+[NatSpec](https://vyper.readthedocs.io/en/latest/natspec.html).
```python
self.supportedInterfaces[ERC165_INTERFACE_ID] = True
@@ -211,57 +253,69 @@ Su Python e su Vyper, puoi anche creare un commento specificando una stringa su
self.minter = msg.sender
```
-Per accedere alle variabili di stato, si usa `self.` (di nuovo, come in Python).
+Per accedere alle variabili di stato si usa `self.` (di nuovo, come in Python).
-#### Funzioni di visualizzazione {#views}
+#### Funzioni View {#views}
-Sono funzioni che non modificano lo stato della blockchain e dunque sono eseguibili liberamente se chiamate esternamente. Se le funzioni di visualizzazione sono chiamate da un contratto, devono comunque esser eseguite su ogni nodo e, dunque, costano gas.
+Queste sono funzioni che non modificano lo stato della blockchain e, pertanto, possono essere eseguite
+gratuitamente se chiamate esternamente. Se le funzioni view vengono chiamate da un contratto, devono comunque essere eseguite su
+ogni nodo e quindi costano gas.
```python
@view
@external
```
-Queste parole chiave prima della definizione di una funzione che inizia con un segno (`@`) sono dette _decorazioni_. Specificano le circostanze in cui una funzione è chiamabile.
+Queste parole chiave prima della definizione di una funzione che iniziano con una chiocciola (`@`) sono chiamate _decorazioni_.
+Specificano le circostanze in cui una funzione può essere chiamata.
-- `@view` specifica che questa funzione è una visualizzazione.
-- `@external` specifica che questa particolare funzione è chiamabile dalle transazioni o da altri contratti.
+- `@view` specifica che questa funzione è una view.
+- `@external` specifica che questa particolare funzione può essere chiamata dalle transazioni e da altri contratti.
```python
def supportsInterface(_interfaceID: bytes32) -> bool:
```
-A differenza di Python, Vyper è un [linguaggio tipizzato statico](https://wikipedia.org/wiki/Type_system#Static_type_checking). Non puoi dichiarare una variabile, o il parametro di una funzione, senza indicare il [tipo di dato](https://vyper.readthedocs.io/en/latest/types.html). In questo caso, il parametro inserito è `bytes32`, un valore a 256 bit (256 bit è la dimensione nativa della word della [Macchina Virtuale di Ethereum](/developers/docs/evm/)). L'output è un valore booleano. Per convenzione, i nomi dei parametri della funzione iniziano con un trattino basso (`_`).
+A differenza di Python, Vyper è un [linguaggio a tipizzazione statica](https://wikipedia.org/wiki/Type_system#Static_type_checking).
+Non puoi dichiarare una variabile o un parametro di funzione senza identificare il [tipo di dato](https://vyper.readthedocs.io/en/latest/types.html). In questo caso il parametro di input è `bytes32`, un valore a 256 bit
+(256 bit è la dimensione della parola nativa della [macchina virtuale di Ethereum](/developers/docs/evm/)). L'output è un valore booleano.
+Per convenzione, i nomi dei parametri di funzione iniziano con un trattino basso (`_`).
```python
- """
- @dev Interface identification is specified in ERC-165.
- @param _interfaceID Id of the interface
- """
+ # @dev L'identificazione dell'interfaccia è specificata in ERC-165.
+ @param _interfaceID Id dell'interfaccia
+
+
+
+
return self.supportedInterfaces[_interfaceID]
```
-Restituisce il valore dall'HashMap `self-supportedInterfaces`, che è impostata nel costruttore (`__init__`).
+Restituisce il valore dalla HashMap `self.supportedInterfaces`, che è impostata nel costruttore (`__init__`).
```python
-### VIEW FUNCTIONS ###
+# ## FUNZIONI DI VISUALIZZAZIONE ###
```
-Queste sono le funzioni di visualizzazione che rendono le informazioni sui token disponibili a utenti e altri contratti.
+Queste sono le funzioni view che rendono disponibili le informazioni sui token agli utenti e ad altri contratti.
```python
@view
@external
def balanceOf(_owner: address) -> uint256:
- """
- @dev Returns the number of NFTs owned by `_owner`.
- Throws if `_owner` is the zero address. NFTs assigned to the zero address are considered invalid.
- @param _owner Address for whom to query the balance.
- """
+ # @dev Restituisce il numero di NFT posseduti da `_owner`.
+ Genera un'eccezione se `_owner` è l'indirizzo zero. Gli NFT assegnati all'indirizzo zero sono considerati non validi.
+ @param _owner Indirizzo per il quale interrogare il saldo.
+
+
+
+
+
assert _owner != ZERO_ADDRESS
```
-Questa riga [afferma](https://vyper.readthedocs.io/en/latest/statements.html#assert) che `_owner` non è zero. Se lo è, c'è un errore e l'operazione è annullata.
+Questa riga [asserisce](https://vyper.readthedocs.io/en/latest/statements.html#assert) che `_owner` non è
+zero. Se lo è, c'è un errore e l'operazione viene annullata (reverted).
```python
return self.ownerToNFTokenCount[_owner]
@@ -269,72 +323,91 @@ Questa riga [afferma](https://vyper.readthedocs.io/en/latest/statements.html#ass
@view
@external
def ownerOf(_tokenId: uint256) -> address:
- """
- @dev Returns the address of the owner of the NFT.
- Throws if `_tokenId` is not a valid NFT.
- @param _tokenId The identifier for an NFT.
- """
+ # @dev Restituisce l'indirizzo del proprietario dell'NFT.
+ Genera un'eccezione se `_tokenId` non è un NFT valido.
+ @param _tokenId L'identificatore per un NFT.
+
+
+
+
+
owner: address = self.idToOwner[_tokenId]
- # Throws if `_tokenId` is not a valid NFT
+ # Genera un'eccezione se `_tokenId` non è un NFT valido
assert owner != ZERO_ADDRESS
return owner
```
-Nella Macchina Virtuale di Ethereum (EVM), ogni memoria senza un valore memorizzato è zero. Se non esiste alcun token a `_tokenId`, allora il valore di `self.idToOwner[_tokenId]` è zero. In quel caso la funzione si annulla.
+Nella macchina virtuale di Ethereum (EVM) qualsiasi spazio di archiviazione che non ha un valore memorizzato in esso è zero.
+Se non c'è alcun token in `_tokenId`, il valore di `self.idToOwner[_tokenId]` è zero. In tal
+caso la funzione viene annullata.
```python
@view
@external
def getApproved(_tokenId: uint256) -> address:
- """
- @dev Get the approved address for a single NFT.
- Throws if `_tokenId` is not a valid NFT.
- @param _tokenId ID of the NFT to query the approval of.
- """
- # Throws if `_tokenId` is not a valid NFT
+ # @dev Ottiene l'indirizzo approvato per un singolo NFT.
+ Genera un'eccezione se `_tokenId` non è un NFT valido.
+ @param _tokenId ID dell'NFT di cui interrogare l'approvazione.
+
+
+
+
+
+ # Genera un'eccezione se `_tokenId` non è un NFT valido
assert self.idToOwner[_tokenId] != ZERO_ADDRESS
return self.idToApprovals[_tokenId]
```
-Nota che `getApproved` _può_ restituire zero. Se il token è valido, restituisce `self.idToApprovals[_tokenId]`. Se non c'è alcun approvatore, quel valore è zero.
+Nota che `getApproved` _può_ restituire zero. Se il token è valido, restituisce `self.idToApprovals[_tokenId]`.
+Se non c'è alcun approvatore, quel valore è zero.
```python
@view
@external
def isApprovedForAll(_owner: address, _operator: address) -> bool:
- """
- @dev Checks if `_operator` is an approved operator for `_owner`.
- @param _owner The address that owns the NFTs.
- @param _operator The address that acts on behalf of the owner.
- """
+ # @dev Controlla se `_operator` è un operatore approvato per `_owner`.
+ @param _owner L'indirizzo che possiede gli NFT.
+ @param _operator L'indirizzo che agisce per conto del proprietario.
+
+
+
+
+
return (self.ownerToOperators[_owner])[_operator]
```
-Questa funzione verifica se `_operator` può gestire tutti i token del `_owner` in questo contratto. Poiché possono esserci diversi operatori, si tratta di un HashMap a due livelli.
+Questa funzione controlla se a `_operator` è consentito gestire tutti i token di `_owner` in questo contratto.
+Poiché possono esserci più operatori, questa è una HashMap a due livelli.
-#### Funzioni d'aiuto al trasferimento {#transfer-helpers}
+#### Funzioni di supporto al trasferimento {#transfer-helpers}
Queste funzioni implementano operazioni che fanno parte del trasferimento o della gestione dei token.
```python
-### TRANSFER FUNCTION HELPERS ###
+# ## FUNZIONI DI SUPPORTO AL TRASFERIMENTO ###
@view
@internal
```
-Questa decorazione, `@internal`, significa che la funzione è accessibile solo da altre funzioni nello stesso contratto. Per convenzione, questi nomi di funzione iniziano anch'essi con un trattino basso (`_`).
+Questa decorazione, `@internal`, significa che la funzione è accessibile solo da altre funzioni all'interno dello
+stesso contratto. Per convenzione, anche i nomi di queste funzioni iniziano con un trattino basso (`_`).
```python
def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool:
- """
- @dev Returns whether the given spender can transfer a given token ID
- @param spender address of the spender to query
- @param tokenId uint256 ID of the token to be transferred
- @return bool whether the msg.sender is approved for the given token ID,
- is an operator of the owner, or is the owner of the token
- """
+ # @dev Restituisce se lo spender specificato può trasferire un determinato ID del token
+ @param spender indirizzo dello spender da interrogare
+ @param tokenId uint256 ID del token da trasferire
+ @return bool se il msg.sender è approvato per l'ID del token specificato,
+ è un operatore del proprietario, o è il proprietario del token
+
+
+
+
+
+
+
owner: address = self.idToOwner[_tokenId]
spenderIsOwner: bool = owner == _spender
spenderIsApproved: bool = _spender == self.idToApprovals[_tokenId]
@@ -342,117 +415,145 @@ def _isApprovedOrOwner(_spender: address, _tokenId: uint256) -> bool:
return (spenderIsOwner or spenderIsApproved) or spenderIsApprovedForAll
```
-Esistono tre modi in cui a un indirizzo è consentito trasferire un token:
+Ci sono tre modi in cui a un indirizzo può essere consentito di trasferire un token:
1. L'indirizzo è il proprietario del token
-2. L'indirizzo è autorizzato a spendere quel token
+2. L'indirizzo è approvato per spendere quel token
3. L'indirizzo è un operatore per il proprietario del token
-La funzione che precedere può essere una visualizzazione, perché non modifica lo stato. Per ridurre i costi operativi, ogni funzione che _può_ essere una visualizzazione, _dovrebbe_ esserlo.
+La funzione precedente può essere una view perché non modifica lo stato. Per ridurre i costi operativi, qualsiasi
+funzione che _può_ essere una view _dovrebbe_ essere una view.
```python
@internal
def _addTokenTo(_to: address, _tokenId: uint256):
- """
- @dev Add a NFT to a given address
- Throws if `_tokenId` is owned by someone.
- """
- # Throws if `_tokenId` is owned by someone
+ # @dev Aggiunge un NFT a un determinato indirizzo
+ Genera un'eccezione se `_tokenId` è posseduto da qualcuno.
+
+
+
+
+ # Genera un'eccezione se `_tokenId` è posseduto da qualcuno
assert self.idToOwner[_tokenId] == ZERO_ADDRESS
- # Change the owner
+ # Cambia il proprietario
self.idToOwner[_tokenId] = _to
- # Change count tracking
+ # Cambia il tracciamento del conteggio
self.ownerToNFTokenCount[_to] += 1
@internal
def _removeTokenFrom(_from: address, _tokenId: uint256):
- """
- @dev Remove a NFT from a given address
- Throws if `_from` is not the current owner.
- """
- # Throws if `_from` is not the current owner
+ # @dev Rimuove un NFT da un determinato indirizzo
+ Genera un'eccezione se `_from` non è il proprietario attuale.
+
+
+
+
+ # Genera un'eccezione se `_from` non è il proprietario attuale
assert self.idToOwner[_tokenId] == _from
- # Change the owner
+ # Cambia il proprietario
self.idToOwner[_tokenId] = ZERO_ADDRESS
- # Change count tracking
+ # Cambia il tracciamento del conteggio
self.ownerToNFTokenCount[_from] -= 1
```
-Quando c'è un problema con un trasferimento, anulliamo la chiamata.
+Quando c'è un problema con un trasferimento, annulliamo la chiamata.
```python
@internal
def _clearApproval(_owner: address, _tokenId: uint256):
- """
- @dev Clear an approval of a given address
- Throws if `_owner` is not the current owner.
- """
- # Throws if `_owner` is not the current owner
+ # @dev Cancella un'approvazione di un determinato indirizzo
+ Genera un'eccezione se `_owner` non è il proprietario attuale.
+
+
+
+
+ # Genera un'eccezione se `_owner` non è il proprietario attuale
assert self.idToOwner[_tokenId] == _owner
if self.idToApprovals[_tokenId] != ZERO_ADDRESS:
- # Reset approvals
+ # Reimposta le approvazioni
self.idToApprovals[_tokenId] = ZERO_ADDRESS
```
-Cambia il valore solo se necessario. Le variabili di stato risiedono nella memoria. La scrittura all'archiviazione è una delle operazioni più costose che l'EVM (Macchina Virtuale di Ethereum) effettua (in termini di [gas](/developers/docs/gas/)). Dunque, è bene mantenerla al minimo, anche scrivere il valore esistente ha un costo elevato.
+Modifica il valore solo se necessario. Le variabili di stato risiedono nell'archiviazione (storage). Scrivere nell'archiviazione è
+una delle operazioni più costose che l'EVM (macchina virtuale di Ethereum) esegue (in termini di
+[gas](/developers/docs/gas/)). Pertanto, è una buona idea ridurla al minimo; persino scrivere il
+valore esistente ha un costo elevato.
```python
@internal
def _transferFrom(_from: address, _to: address, _tokenId: uint256, _sender: address):
- """
- @dev Execute transfer of a NFT.
- Throws unless `msg.sender` is the current owner, an authorized operator, or the approved
- address for this NFT. (NOTE: `msg.sender` not allowed in private function so pass `_sender`.)
- Throws if `_to` is the zero address.
- Throws if `_from` is not the current owner.
- Throws if `_tokenId` is not a valid NFT.
- """
+ # @dev Esegue il trasferimento di un NFT.
+ Genera un'eccezione a meno che `msg.sender` non sia il proprietario attuale, un operatore autorizzato o l'indirizzo
+ approvato per questo NFT. (NOTA: `msg.sender` non è consentito in una funzione privata, quindi passa `_sender`.)
+ Genera un'eccezione se `_to` è l'indirizzo zero.
+ Genera un'eccezione se `_from` non è il proprietario attuale.
+ Genera un'eccezione se `_tokenId` non è un NFT valido.
+
+
+
+
+
+
+
+
```
-Abbiamo questa funzione interna perché esistono due modi per trasferire i token (regolare e sicuro), ma vogliamo una sola posizione nel codice dove farlo, per semplificare il controllo.
+Abbiamo questa funzione interna perché ci sono due modi per trasferire i token (normale e sicuro), ma
+vogliamo solo una singola posizione nel codice in cui lo facciamo per semplificare l'auditing.
```python
- # Check requirements
+ # Controlla i requisiti
assert self._isApprovedOrOwner(_sender, _tokenId)
- # Throws if `_to` is the zero address
+ # Genera un'eccezione se `_to` è l'indirizzo zero
assert _to != ZERO_ADDRESS
- # Clear approval. Throws if `_from` is not the current owner
+ # Cancella l'approvazione. Genera un'eccezione se `_from` non è il proprietario attuale
self._clearApproval(_from, _tokenId)
- # Remove NFT. Throws if `_tokenId` is not a valid NFT
+ # Rimuove l'NFT. Genera un'eccezione se `_tokenId` non è un NFT valido
self._removeTokenFrom(_from, _tokenId)
- # Add NFT
+ # Aggiunge l'NFT
self._addTokenTo(_to, _tokenId)
- # Log the transfer
+ # Registra il trasferimento
log Transfer(_from, _to, _tokenId)
```
-Per emettere un evento su Vyper, si usa una dichiarazione di `log` ([vedi qui per ulteriori dettagli](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging)).
+Per emettere un evento in Vyper si usa un'istruzione `log` ([vedi qui per maggiori dettagli](https://vyper.readthedocs.io/en/latest/event-logging.html#event-logging)).
#### Funzioni di trasferimento {#transfer-funs}
```python
-### TRANSFER FUNCTIONS ###
+# ## FUNZIONI DI TRASFERIMENTO ###
@external
def transferFrom(_from: address, _to: address, _tokenId: uint256):
- """
- @dev Throws unless `msg.sender` is the current owner, an authorized operator, or the approved
- address for this NFT.
- Throws if `_from` is not the current owner.
- Throws if `_to` is the zero address.
- Throws if `_tokenId` is not a valid NFT.
- @notice The caller is responsible to confirm that `_to` is capable of receiving NFTs or else
- they maybe be permanently lost.
- @param _from The current owner of the NFT.
- @param _to The new owner.
- @param _tokenId The NFT to transfer.
- """
+ # @dev Genera un'eccezione a meno che `msg.sender` non sia il proprietario attuale, un operatore autorizzato o l'indirizzo
+ approvato per questo NFT.
+ Genera un'eccezione se `_from` non è il proprietario attuale.
+ Genera un'eccezione se `_to` è l'indirizzo zero.
+ Genera un'eccezione se `_tokenId` non è un NFT valido.
+ @notice Il chiamante è responsabile di confermare che `_to` sia in grado di ricevere NFT, altrimenti
+ potrebbero andare persi in modo permanente.
+ @param _from Il proprietario attuale dell'NFT.
+ @param _to Il nuovo proprietario.
+ @param _tokenId L'NFT da trasferire.
+
+
+
+
+
+
+
+
+
+
+
+
self._transferFrom(_from, _to, _tokenId, msg.sender)
```
-Questa funzione ti consente di trasferire a un indirizzo arbitrario. A meno che l'indirizzo non sia un utente o un contratto che sa come trasferire i token, ogni token che trasferisci sarà bloccato in quell'indirizzo e inutile.
+Questa funzione ti consente di trasferire a un indirizzo arbitrario. A meno che l'indirizzo non sia un utente o un contratto che
+sa come trasferire i token, qualsiasi token trasferito rimarrà bloccato in quell'indirizzo e sarà inutile.
```python
@external
@@ -462,172 +563,228 @@ def safeTransferFrom(
_tokenId: uint256,
_data: Bytes[1024]=b""
):
- """
- @dev Transfers the ownership of an NFT from one address to another address.
- Throws unless `msg.sender` is the current owner, an authorized operator, or the
- approved address for this NFT.
- Throws if `_from` is not the current owner.
- Throws if `_to` is the zero address.
- Throws if `_tokenId` is not a valid NFT.
- If `_to` is a smart contract, it calls `onERC721Received` on `_to` and throws if
- the return value is not `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
- NOTE: bytes4 is represented by bytes32 with padding
- @param _from The current owner of the NFT.
- @param _to The new owner.
- @param _tokenId The NFT to transfer.
- @param _data Additional data with no specified format, sent in call to `_to`.
- """
+ # @dev Trasferisce la proprietà di un NFT da un indirizzo a un altro indirizzo.
+ Genera un'eccezione a meno che `msg.sender` non sia il proprietario attuale, un operatore autorizzato o
+ l'indirizzo approvato per questo NFT.
+ Genera un'eccezione se `_from` non è il proprietario attuale.
+ Genera un'eccezione se `_to` è l'indirizzo zero.
+ Genera un'eccezione se `_tokenId` non è un NFT valido.
+ Se `_to` è uno smart contract, chiama `onERC721Received` su `_to` e genera un'eccezione se
+ il valore di ritorno non è `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`.
+ NOTA: bytes4 è rappresentato da bytes32 con padding
+ @param _from Il proprietario attuale dell'NFT.
+ @param _to Il nuovo proprietario.
+ @param _tokenId L'NFT da trasferire.
+ @param _data Dati aggiuntivi senza formato specificato, inviati nella chiamata a `_to`.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
self._transferFrom(_from, _to, _tokenId, msg.sender)
```
-Va bene effettuare prima il trasferimento perché se c'è un problema, ripristineremo comunque, quindi tutto ciò che è fatto nella chiamata sarà annullato.
+Va bene eseguire prima il trasferimento perché, se c'è un problema, annulleremo comunque l'operazione,
+quindi tutto ciò che è stato fatto nella chiamata verrà cancellato.
```python
- if _to.is_contract: # check if `_to` is a contract address
+ if _to.is_contract: # controlla se `_to` è un indirizzo di contratto
```
-Prima controlla per vedere se l'indirizzo è un contratto (se ha il codice). Altrimenti, presumi che sia un indirizzo utente e che l'utente possa usare o trasferire il token. Ma non abbandonarti a un falso senso di sicurezza. Puoi infatti perdere i token, anche con `safeTransferFrom`, se li trasferisci a un indirizzo di cui nessuno conosce la chiave privata.
+Per prima cosa controlla se l'indirizzo è un contratto (se ha del codice). In caso contrario, presumi che sia un indirizzo utente
+e che l'utente sarà in grado di utilizzare il token o trasferirlo. Ma non farti cullare da un falso
+senso di sicurezza. Puoi perdere i token, anche con `safeTransferFrom`, se li trasferisci
+a un indirizzo di cui nessuno conosce la chiave privata.
```python
returnValue: bytes32 = ERC721Receiver(_to).onERC721Received(msg.sender, _from, _tokenId, _data)
```
-Chiama il contratto di destinazione per vedere se può ricevere i token ERC-721.
+Chiama il contratto di destinazione per vedere se può ricevere token ERC-721.
```python
- # Throws if transfer destination is a contract which does not implement 'onERC721Received'
+ # Genera un'eccezione se la destinazione del trasferimento è un contratto che non implementa 'onERC721Received'
assert returnValue == method_id("onERC721Received(address,address,uint256,bytes)", output_type=bytes32)
```
-Se la destinazione è un contratto, ma un contratto che non accetta i token ERC-721 (o che ha deciso di non accettare questo specifico trasferimento), annulla.
+Se la destinazione è un contratto, ma non accetta token ERC-721 (o ha deciso di non accettare questo
+particolare trasferimento), annulla l'operazione.
```python
@external
def approve(_approved: address, _tokenId: uint256):
- """
- @dev Set or reaffirm the approved address for an NFT. The zero address indicates there is no approved address.
- Throws unless `msg.sender` is the current NFT owner, or an authorized operator of the current owner.
- Throws if `_tokenId` is not a valid NFT. (NOTE: This is not written the EIP)
- Throws if `_approved` is the current owner. (NOTE: This is not written the EIP)
- @param _approved Address to be approved for the given NFT ID.
- @param _tokenId ID of the token to be approved.
- """
+ # @dev Imposta o riafferma l'indirizzo approvato per un NFT. L'indirizzo zero indica che non c'è alcun indirizzo approvato.
+ Genera un'eccezione a meno che `msg.sender` non sia il proprietario attuale dell'NFT, o un operatore autorizzato del proprietario attuale.
+ Genera un'eccezione se `_tokenId` non è un NFT valido. (NOTA: Questo non è scritto nell'EIP)
+ Genera un'eccezione se `_approved` è il proprietario attuale. (NOTA: Questo non è scritto nell'EIP)
+ @param _approved Indirizzo da approvare per l'ID dell'NFT specificato.
+ @param _tokenId ID del token da approvare.
+
+
+
+
+
+
+
+
owner: address = self.idToOwner[_tokenId]
- # Throws if `_tokenId` is not a valid NFT
+ # Genera un'eccezione se `_tokenId` non è un NFT valido
assert owner != ZERO_ADDRESS
- # Throws if `_approved` is the current owner
+ # Genera un'eccezione se `_approved` è il proprietario attuale
assert _approved != owner
```
Per convenzione, se non vuoi avere un approvatore, nomini l'indirizzo zero, non te stesso.
```python
- # Check requirements
+ # Controlla i requisiti
senderIsOwner: bool = self.idToOwner[_tokenId] == msg.sender
senderIsApprovedForAll: bool = (self.ownerToOperators[owner])[msg.sender]
assert (senderIsOwner or senderIsApprovedForAll)
```
-Per impostare un'approvazione, puoi essere il proprietario o un operatore autorizzato dal proprietario.
+Per impostare un'approvazione puoi essere il proprietario o un operatore autorizzato dal proprietario.
```python
- # Set the approval
+ # Imposta l'approvazione
self.idToApprovals[_tokenId] = _approved
log Approval(owner, _approved, _tokenId)
@external
def setApprovalForAll(_operator: address, _approved: bool):
- """
- @dev Enables or disables approval for a third party ("operator") to manage all of
- `msg.sender`'s assets. It also emits the ApprovalForAll event.
- Throws if `_operator` is the `msg.sender`. (NOTE: This is not written the EIP)
- @notice This works even if sender doesn't own any tokens at the time.
- @param _operator Address to add to the set of authorized operators.
- @param _approved True if the operators is approved, false to revoke approval.
- """
- # Throws if `_operator` is the `msg.sender`
+ # @dev Abilita o disabilita l'approvazione per una terza parte ("operatore") per gestire tutti gli
+ asset di `msg.sender`. Emette anche l'evento ApprovalForAll.
+ Genera un'eccezione se `_operator` è il `msg.sender`. (NOTA: Questo non è scritto nell'EIP)
+ @notice Questo funziona anche se il mittente non possiede alcun token in quel momento.
+ @param _operator Indirizzo da aggiungere all'insieme degli operatori autorizzati.
+ @param _approved True se l'operatore è approvato, false per revocare l'approvazione.
+
+
+
+
+
+
+
+
+ # Genera un'eccezione se `_operator` è il `msg.sender`
assert _operator != msg.sender
self.ownerToOperators[msg.sender][_operator] = _approved
log ApprovalForAll(msg.sender, _operator, _approved)
```
-#### Conia nuovi token e distruggi token esistenti {#mint-burn}
+#### Coniare nuovi token e distruggere quelli esistenti {#mint-burn}
-Il conto che ha creato il contratto è il `minter`, il super utente autorizzato a coniare nuovi NFT. Tuttavia, nemmeno lui è autorizzato a bruciare i token esistenti. Può farlo solo il proprietario, o un'entità da autorizzata dal proprietario.
+L'account che ha creato il contratto è il `minter`, il super utente autorizzato a coniare
+nuovi NFT. Tuttavia, nemmeno a lui è consentito bruciare i token esistenti. Solo il proprietario, o un'entità
+autorizzata dal proprietario, può farlo.
```python
-### MINT & BURN FUNCTIONS ###
+# ## FUNZIONI PER CONIARE E BRUCIARE ###
@external
def mint(_to: address, _tokenId: uint256) -> bool:
```
-Questa funzione restituisce sempre `True`, perché se l'operazione fallisce è ripristinata.
+Questa funzione restituisce sempre `True`, perché se l'operazione fallisce viene annullata.
```python
- """
- @dev Function to mint tokens
- Throws if `msg.sender` is not the minter.
- Throws if `_to` is zero address.
- Throws if `_tokenId` is owned by someone.
- @param _to The address that will receive the minted tokens.
- @param _tokenId The token id to mint.
- @return A boolean that indicates if the operation was successful.
- """
- # Throws if `msg.sender` is not the minter
+ # @dev Funzione per coniare token
+ Genera un'eccezione se `msg.sender` non è il minter.
+ Genera un'eccezione se `_to` è l'indirizzo zero.
+ Genera un'eccezione se `_tokenId` è posseduto da qualcuno.
+ @param _to L'indirizzo che riceverà i token coniati.
+ @param _tokenId L'id del token da coniare.
+ @return Un booleano che indica se l'operazione ha avuto successo.
+
+
+
+
+
+
+
+
+
+ # Genera un'eccezione se `msg.sender` non è il minter
assert msg.sender == self.minter
```
-Solo il coniatore (il conto che ha creato il contratto ERC-721) può coniare nuovi token. Questo può essere un problema in futuro se si vuole cambiare l'identità del coniatore. In un contratto di produzione, potresti volere una funzione che consenta al coniatore di trasferire i propri privilegi a qualcun altro.
+Solo il minter (l'account che ha creato il contratto ERC-721) può coniare nuovi token. Questo può essere un
+problema in futuro se vogliamo cambiare l'identità del minter. In
+un contratto di produzione probabilmente vorresti una funzione che consenta al minter di trasferire
+i privilegi di minter a qualcun altro.
```python
- # Throws if `_to` is zero address
+ # Genera un'eccezione se `_to` è l'indirizzo zero
assert _to != ZERO_ADDRESS
- # Add NFT. Throws if `_tokenId` is owned by someone
+ # Aggiunge l'NFT. Genera un'eccezione se `_tokenId` è posseduto da qualcuno
self._addTokenTo(_to, _tokenId)
log Transfer(ZERO_ADDRESS, _to, _tokenId)
return True
```
-Per convenzione, coniare i nuovi token conta come un trasferimento all'indirizzo zero.
+Per convenzione, il conio di nuovi token conta come un trasferimento dall'indirizzo zero.
```python
@external
def burn(_tokenId: uint256):
- """
- @dev Burns a specific ERC721 token.
- Throws unless `msg.sender` is the current owner, an authorized operator, or the approved
- address for this NFT.
- Throws if `_tokenId` is not a valid NFT.
- @param _tokenId uint256 id of the ERC721 token to be burned.
- """
- # Check requirements
+ # @dev Brucia uno specifico token ERC721.
+ Genera un'eccezione a meno che `msg.sender` non sia il proprietario attuale, un operatore autorizzato o l'indirizzo
+ approvato per questo NFT.
+ Genera un'eccezione se `_tokenId` non è un NFT valido.
+ @param _tokenId uint256 id del token ERC721 da bruciare.
+
+
+
+
+
+
+
+ # Controlla i requisiti
assert self._isApprovedOrOwner(msg.sender, _tokenId)
owner: address = self.idToOwner[_tokenId]
- # Throws if `_tokenId` is not a valid NFT
+ # Genera un'eccezione se `_tokenId` non è un NFT valido
assert owner != ZERO_ADDRESS
self._clearApproval(owner, _tokenId)
self._removeTokenFrom(owner, _tokenId)
log Transfer(owner, ZERO_ADDRESS, _tokenId)
```
-Chiunque è autorizzato a trasferire un token, può bruciarlo. Anche se bruciare un token appare equivalente a trasferirlo all'indirizzo zero, l'indirizzo zero non riceve realmente il token. Ciò ci consente di liberare tutta l'archiviazione usata per il token, riducendo il costo del gas della transazione.
+Chiunque sia autorizzato a trasferire un token è autorizzato a bruciarlo. Sebbene una bruciatura appaia equivalente al
+trasferimento all'indirizzo zero, l'indirizzo zero in realtà non riceve il token. Questo ci consente di
+liberare tutto lo spazio di archiviazione che è stato utilizzato per il token, il che può ridurre il costo del gas della transazione.
-## Usare questo contratto {#using-contract}
+## Utilizzare questo contratto {#using-contract}
-A differenza di Solidity, Vyper non ha un ereditarietà. Si tratta di una scelta progettuale deliberata per rendere il codice più chiaro e quindi più facile da proteggere. Quindi, per creare il tuo contratto ERC-721 in Vyper, prendi [questo contratto](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy) e lo modifichi per implementare la logica di business che desideri.
+A differenza di Solidity, Vyper non ha l'ereditarietà. Questa è una scelta di progettazione deliberata per rendere il
+codice più chiaro e quindi più facile da proteggere. Quindi, per creare il tuo contratto ERC-721 in Vyper, prendi [questo
+contratto](https://github.com/vyperlang/vyper/blob/master/examples/tokens/ERC721.vy) e modificalo
+per implementare la logica di business che desideri.
-### Conclusione {#conclusion}
+## Conclusione {#conclusion}
-Per ripasso presentiamo alcune delle idee più importanti in questo contratto:
+Per riepilogare, ecco alcune delle idee più importanti in questo contratto:
-- Per ricevere i token ERC-721 con un trasferimento sicuro, i contratti devono implementare l'interfaccia di `ERC721Receiver`.
-- Anche se usi il trasferimento sicuro, i token possono comunque rimanere bloccati se li invii a un indirizzo la cui chiave privata è sconosciuta.
-- Quando c'è un problema con un'operazione, è una buona idea eseguire il `revert` della chiamata, piuttosto che restituire semplicemente un valore d'errore.
+- Per ricevere token ERC-721 con un trasferimento sicuro, i contratti devono implementare l'interfaccia `ERC721Receiver`.
+- Anche se usi il trasferimento sicuro, i token possono comunque rimanere bloccati se li invii a un indirizzo di cui non si conosce la chiave privata.
+- Quando c'è un problema con un'operazione, è una buona idea annullare (`revert`) la chiamata, piuttosto che restituire semplicemente
+ un valore di fallimento.
- I token ERC-721 esistono quando hanno un proprietario.
-- Esistono tre modi per essere autorizzati a trasferire un NFT. Puoi essere il proprietario, essere approvato per un token specifico o essere un operatore per tutti i token del proprietario.
-- Gli eventi passati sono visibili solo al di fuori della blockchain. Il codice eseguito nella blockchain non può vederli.
+- Ci sono tre modi per essere autorizzati a trasferire un NFT. Puoi essere il proprietario, essere approvato per un token specifico,
+ o essere un operatore per tutti i token del proprietario.
+- Gli eventi passati sono visibili solo all'esterno della blockchain. Il codice in esecuzione all'interno della blockchain non può visualizzarli.
+
+Ora vai e implementa contratti Vyper sicuri.
-Ora puoi andare a implementare contratti sicuri in Vyper.
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
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 c28b6b22582..833f74e51a3 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,31 +1,29 @@
---
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 perché si trova lì?"
author: Ori Pomerantz
lang: it
-tags:
- - "solidity"
- - "erc-20"
+tags: ["Solidity", "erc-20"]
skill: beginner
-breadcrumb: "ERC-20 passo passo"
+breadcrumb: Guida dettagliata a ERC-20
published: 2021-03-09
---
## Introduzione {#introduction}
-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. In genere questi token seguono uno standard, l'[ERC-20](/developers/docs/standards/tokens/erc-20/). Questo standard permette di scrivere gli strumenti, come pool di liquidità e wallet, compatibili con tutti i token ERC-20. In questo articolo analizzeremo l'[Implementazione di ERC20 in Solidity su OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol), nonché la [definizione dell'interfaccia](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol).
+Uno degli usi più comuni di Ethereum è la creazione da parte di un gruppo di un token scambiabile, in un certo senso la propria valuta. Questi token seguono tipicamente uno standard, l'[ERC-20](/developers/docs/standards/tokens/erc-20/). Questo standard rende possibile scrivere strumenti, come pool di liquidità e portafogli, che funzionano con tutti i token ERC-20. In questo articolo analizzeremo l'[implementazione ERC20 in Solidity di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol), così come la [definizione dell'interfaccia](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol).
-Qui parliamo del codice sorgente annotato. Se vuoi implementare ERC-20, [leggi questo tutorial](https://docs.openzeppelin.com/contracts/2.x/erc20-supply).
+Questo è codice sorgente annotato. Se vuoi implementare l'ERC-20, [leggi questo tutorial](https://docs.openzeppelin.com/contracts/2.x/erc20-supply).
-## L'interfaccia {#the-interface}
+## L'Interfaccia {#the-interface}
-Lo scopo di uno standard come ERC-20 è quello di consentire molte implementazioni di token che siano interoperabili tra le varie applicazioni, quali wallet e scambi decentralizzati. A tale scopo, creiamo un'[interfaccia](https://www.geeksforgeeks.org/solidity-basics-of-interface/). Ogni codice che necessita di usare il contratto del token può avvalersi delle stesse definizioni nell'interfaccia ed essere compatibile con tutti i contratti del token che la usano, che si tratti di un portafoglio come MetaMask, una dApp come etherscan.io o un contratto diverso, come un pool di liquidità.
+Lo scopo di uno standard come l'ERC-20 è consentire molte implementazioni di token che siano interoperabili tra le applicazioni, come portafogli ed exchange decentralizzati. Per ottenere ciò, creiamo un'[interfaccia](https://www.geeksforgeeks.org/solidity/solidity-basics-of-interface/). Qualsiasi codice che debba utilizzare il contratto del token può usare le stesse definizioni nell'interfaccia ed essere compatibile con tutti i contratti dei token che la utilizzano, che si tratti di un portafoglio come MetaMask, di una dApp come etherscan.io o di un contratto diverso come una pool di liquidità.
-
+
-Se sei un programmatore esperto, probabilmente ricorderai di aver visto costrutti simili in [Java](https://www.w3schools.com/java/java_interface.asp) o persino nei [file d'intestazione in C](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html).
+Se sei un programmatore esperto, probabilmente ricordi di aver visto costrutti simili in [Java](https://www.w3schools.com/java/java_interface.asp) o persino nei [file header del C](https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html).
-Questa è una definizione dell'[Interfaccia di ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) da OpenZeppelin. È una traduzione dello [standard leggibile umano](https://eips.ethereum.org/EIPS/eip-20) nel codice di Solidity. Ovviamente, l'interfaccia di per sé non definisce _come_ fare qualcosa. Ciò è spiegato nel codice sorgente del contratto di seguito.
+Questa è una definizione dell'[Interfaccia ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol) di OpenZeppelin. È una traduzione dello [standard leggibile dall'uomo](https://eips.ethereum.org/EIPS/eip-20) in codice Solidity. Naturalmente, l'interfaccia stessa non definisce _come_ fare qualcosa. Questo è spiegato nel codice sorgente del contratto di seguito.
@@ -33,7 +31,7 @@ Questa è una definizione dell'[Interfaccia di ERC-20](https://github.com/OpenZe
// SPDX-License-Identifier: MIT
```
-I file di Solidity dovrebbero includere un'identificativo della licenza. [Puoi vedere qui l'elenco di licenze](https://spdx.org/licenses/). Se hai bisogno di una licenza diversa, basta spiegarlo nei commenti.
+I file Solidity dovrebbero includere un identificatore di licenza. [Puoi vedere l'elenco delle licenze qui](https://spdx.org/licenses/). Se hai bisogno di una licenza diversa, spiegalo semplicemente nei commenti.
@@ -41,17 +39,19 @@ I file di Solidity dovrebbero includere un'identificativo della licenza. [Puoi v
pragma solidity >=0.6.0 <0.8.0;
```
-Il linguaggio Solidity si sta ancora evolvendo rapidamente e le nuove versioni potrebbero non essere compatibili con il vecchio codice ([vedi qui](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html)). Dunque, è una buona idea specificare non solo una versione minima del linguaggio, ma anche una versione massima, l'ultima con cui hai testato il codice.
+Il linguaggio Solidity si sta ancora evolvendo rapidamente e le nuove versioni potrebbero non essere compatibili con il vecchio codice ([vedi qui](https://docs.soliditylang.org/en/v0.7.0/070-breaking-changes.html)). Pertanto, è una buona idea specificare non solo una versione minima del linguaggio, ma anche una versione massima, l'ultima con cui hai testato il codice.
```solidity
-/**
- * @dev Interface of the ERC20 standard as defined in the EIP.
- */
+/* *
+ * @dev Interfaccia dello standard ERC20 come definito nell'EIP. */
+
+
+
```
-Il `@dev` nel commento è parte del [formato NatSpec](https://docs.soliditylang.org/en/develop/natspec-format.html), usato per produrre la documentazione dal codice sorgente.
+Il `@dev` nel commento fa parte del [formato NatSpec](https://docs.soliditylang.org/en/develop/natspec-format.html), utilizzato per produrre documentazione dal codice sorgente.
@@ -59,135 +59,181 @@ Il `@dev` nel commento è parte del [formato NatSpec](https://docs.soliditylang.
interface IERC20 {
```
-Per convenzione, i nomi dell'interfaccia iniziano per `I`.
+Per convenzione, i nomi delle interfacce iniziano con `I`.
```solidity
- /**
- * @dev Returns the amount of tokens in existence.
- */
+ /* *
+ * @dev Restituisce la quantità di token esistenti. */
+
+
+
function totalSupply() external view returns (uint256);
```
-Questa funzione è `external`, a significare che [può essere chiamata solo dal di fuori del contratto](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2). Restituisce la fornitura totale di token nel contratto. Questo valore è restituito usando il tipo più comune in Ethereum, ovvero 256 bit non firmati (256 bit è la dimensione nativa della parola dell'EVM). Questa funzione è anche una `view`, il che significa che non cambia stato, quindi è eseguibile su un nodo singolo invece di farla eseguire da ciascun nodo nella blockchain. Questo tipo di funzione non genera una transazione e non costa [gas](/developers/docs/gas/).
+Questa funzione è `external`, il che significa che [può essere chiamata solo dall'esterno del contratto](https://docs.soliditylang.org/en/v0.7.0/cheatsheet.html#index-2). Restituisce l'offerta totale di token nel contratto. Questo valore viene restituito utilizzando il tipo più comune in Ethereum, 256 bit senza segno (256 bit è la dimensione della parola nativa della EVM). Questa funzione è anche una `view`, il che significa che non modifica lo stato, quindi può essere eseguita su un singolo nodo invece di farla eseguire a ogni nodo della blockchain. Questo tipo di funzione non genera una transazione e non costa [gas](/developers/docs/gas/).
-**Nota:** In teoria, si potrebbe pensare che il creatore del contratto possa imbrogliare restituendo una fornitura totale inferiore al valore reale, facendo apparire ogni token come più prezioso di quanto sia realmente. Tuttavia, tale timore ignora la vera natura della blockchain. Tutto ciò che succede sulla blockchain è verificabile da ogni nodo. A tale scopo, il codice del linguaggio della macchina e la memoria di ciascun contratto sono disponibili su tutti i nodi. Benché non sia obbligatorio pubblicare il codice di Solidity per il tuo contratto, nessuno ti prenderebbe sul serio se non pubblicassi il codice sorgente e la versione di Solidity con cui lo hai compilato, così da renderlo verificabile rispetto al codice del linguaggio della macchina che hai indicato. Vediamo ad esempio [questo contratto](https://etherscan.io/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD#code).
+**Nota:** In teoria potrebbe sembrare che il creatore di un contratto possa imbrogliare restituendo un'offerta totale inferiore al valore reale, facendo apparire ogni token più prezioso di quanto non sia in realtà. Tuttavia, questo timore ignora la vera natura della blockchain. Tutto ciò che accade sulla blockchain può essere verificato da ogni nodo. Per ottenere ciò, il codice in linguaggio macchina e l'archiviazione di ogni contratto sono disponibili su ogni nodo. Sebbene non sia richiesto di pubblicare il codice Solidity per il tuo contratto, nessuno ti prenderebbe sul serio a meno che tu non pubblichi il codice sorgente e la versione di Solidity con cui è stato compilato, in modo che possa essere verificato rispetto al codice in linguaggio macchina che hai fornito.
+Ad esempio, vedi [questo contratto](https://eth.blockscout.com/address/0xa530F85085C6FE2f866E7FdB716849714a89f4CD?tab=contract).
```solidity
- /**
- * @dev Returns the amount of tokens owned by `account`.
- */
+ /* *
+ * @dev Restituisce la quantità di token posseduti da `account`. */
+
+
+
function balanceOf(address account) external view returns (uint256);
```
-Come dice il nome `balanceOf` restituisce il saldo di un conto. I conti di Ethereum sono identificati in Solidity usando il tipo `address`, contenente 160 bit. È anche `external` e `view`.
+Come dice il nome, `balanceOf` restituisce il saldo di un account. Gli account di Ethereum sono identificati in Solidity utilizzando il tipo `address`, che contiene 160 bit. È anche `external` e `view`.
```solidity
- /**
- * @dev Moves `amount` tokens from the caller's account to `recipient`.
+ /* *
+ * @dev Sposta `amount` token dall'account del chiamante a `recipient`.
*
- * Returns a boolean value indicating whether the operation succeeded.
+ * Restituisce un valore booleano che indica se l'operazione ha avuto successo.
*
- * Emits a {Transfer} event.
- */
+ * Emette un evento {Transfer}. */
+
+
+
+
+
+
+
function transfer(address recipient, uint256 amount) external returns (bool);
```
-La funzione `transfer` trasferisce i token dal chiamante a un indirizzo diverso. Ciò implica un cambio di stato, quindi non è una `view`. Quando un utente chiama questa funzione, crea una transazione e consuma del gas. Inoltre viene emesso un evento, `Transfer`, per informare tutti sulla blockchain dell'evento.
+La funzione `transfer` trasferisce dei token dal chiamante a un indirizzo diverso. Ciò comporta un cambiamento di stato, quindi non è una `view`. Quando un utente chiama questa funzione, crea una transazione e costa gas. Emette anche un evento, `Transfer`, per informare tutti sulla blockchain dell'evento.
La funzione ha due tipi di output per due diversi tipi di chiamanti:
-- Gli utenti che chiamano la funzione direttamente da un'interfaccia utente. In genere l'utente invia una transazione e non attende una risposta, il che potrebbe richiedere un tempo indefinito. L'utente può vedere cosa è successo cercando la ricevuta della transazione (identificata dall'hash della transazione) o cercando l'evento `Transfer`.
-- Altri contratti, che chiamano la funzione nell'ambito di una transazione complessiva. Questi ottengono il risultato immediatamente, perché sono eseguiti nella transazione stessa, così da poter usare il valore di ritorno della funzione.
+- Gli utenti che chiamano la funzione direttamente da un'interfaccia utente. Tipicamente l'utente invia una transazione e non aspetta una risposta, che potrebbe richiedere un tempo indefinito. L'utente può vedere cosa è successo cercando la ricevuta della transazione (che è identificata dall'hash della transazione) o cercando l'evento `Transfer`.
+- Altri contratti, che chiamano la funzione come parte di una transazione complessiva. Quei contratti ottengono il risultato immediatamente, perché vengono eseguiti nella stessa transazione, quindi possono utilizzare il valore di ritorno della funzione.
-Lo stesso tipo di output è creato da altre funzioni che cambiano lo stato del contratto.
+Lo stesso tipo di output viene creato dalle altre funzioni che modificano lo stato del contratto.
-Le indennità permettono a un conto di spendere dei token appartenenti a un altro proprietario. Ciò è utile, ad esempio, per i contratti che fungono da venditori. I contratti non possono monitorare gli eventi, quindi se un acquirente dovesse trasferire token al contratto del venditore direttamente, quel contratto non saprebbe di aver ricevuto il pagamento. Invece, l'acquirente permette al contratto del venditore di spendere un certo importo e il venditore trasferisce quell'importo. Questo avviene tramite un funzione chiamata dal contratto del venditore, in modo tale che il contratto del venditore possa sapere se è andata a buon fine.
+Le autorizzazioni (allowance) permettono a un account di spendere alcuni token che appartengono a un proprietario diverso. Questo è utile, ad esempio, per i contratti che agiscono come venditori. I contratti non possono monitorare gli eventi, quindi se un acquirente trasferisse i token direttamente al contratto del venditore, quel contratto non saprebbe di essere stato pagato. Invece, l'acquirente autorizza il contratto del venditore a spendere un certo importo, e il venditore trasferisce quell'importo. Questo viene fatto tramite una funzione chiamata dal contratto del venditore, in modo che il contratto del venditore possa sapere se ha avuto successo.
```solidity
- /**
- * @dev Returns the remaining number of tokens that `spender` will be
- * allowed to spend on behalf of `owner` through {transferFrom}. This is
- * zero by default.
+ /* *
+ * @dev Restituisce il numero rimanente di token che `spender` sarà
+ * autorizzato a spendere per conto di `owner` tramite {transferFrom}. Questo è
+ * zero per impostazione predefinita.
*
- * This value changes when {approve} or {transferFrom} are called.
- */
+ * Questo valore cambia quando vengono chiamati {approve} o {transferFrom}. */
+
+
+
+
+
+
+
function allowance(address owner, address spender) external view returns (uint256);
```
-La funzione `allowance` consente a chiunque di richiedere di vedere quale sia il margine di tolleranza che un indirizzo (`owner`) permette all'altro indirizzo (`spender`) di spendere.
+La funzione `allowance` consente a chiunque di interrogare per vedere qual è l'autorizzazione che un indirizzo (`owner`) consente a un altro indirizzo (`spender`) di spendere.
```solidity
- /**
- * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
+ /* *
+ * @dev Imposta `amount` come limite di spesa di `spender` sui token del chiamante.
*
- * Returns a boolean value indicating whether the operation succeeded.
+ * Restituisce un valore booleano che indica se l'operazione ha avuto successo.
*
- * IMPORTANT: Beware that changing an allowance with this method brings the risk
- * that someone may use both the old and the new allowance by unfortunate
- * transaction ordering. One possible solution to mitigate this race
- * condition is to first reduce the spender's allowance to 0 and set the
- * desired value afterwards:
+ * IMPORTANTE: Attenzione che modificare un limite di spesa con questo metodo comporta il rischio
+ * che qualcuno possa utilizzare sia il vecchio che il nuovo limite di spesa a causa di uno sfortunato
+ * ordinamento delle transazioni. Una possibile soluzione per mitigare questa race
+ * condition è ridurre prima il limite di spesa dello spender a 0 e impostare il
+ * valore desiderato in seguito:
* https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
*
- * Emits an {Approval} event.
- */
+ * Emette un evento {Approval}. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
function approve(address spender, uint256 amount) external returns (bool);
```
-La funzione `approve` crea una tolleranza. Assicurati di leggere il messaggio sui rischi di utilizzo improprio. In Ethereum puoi controllare l'ordine delle tue transazioni, ma non puoi controllare l'ordine con cui le transazioni altrui saranno eseguite, a meno che tu tenga in sospeso la tua transazione finché non vedi che la transazione dell'altro lato ha avuto luogo.
+La funzione `approve` crea un'autorizzazione. Assicurati di leggere il messaggio su come può essere abusata. In Ethereum controlli l'ordine delle tue transazioni, ma non puoi controllare l'ordine in cui verranno eseguite le transazioni di altre persone, a meno che tu non invii la tua transazione finché non vedi che la transazione dell'altra parte è avvenuta.
```solidity
- /**
- * @dev Moves `amount` tokens from `sender` to `recipient` using the
- * allowance mechanism. `amount` is then deducted from the caller's
- * allowance.
+ /* *
+ * @dev Sposta `amount` token da `sender` a `recipient` utilizzando il
+ * meccanismo del limite di spesa. `amount` viene quindi detratto dal limite di spesa
+ * del chiamante.
*
- * Returns a boolean value indicating whether the operation succeeded.
+ * Restituisce un valore booleano che indica se l'operazione ha avuto successo.
*
- * Emits a {Transfer} event.
- */
+ * Emette un evento {Transfer}. */
+
+
+
+
+
+
+
+
+
function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
```
-Infine, `transferFrom` è usata dallo spender per spendere concretamente il margine di tolleranza.
+Infine, `transferFrom` viene utilizzata dallo spenditore per spendere effettivamente l'autorizzazione.
```solidity
- /**
- * @dev Emitted when `value` tokens are moved from one account (`from`) to
- * another (`to`).
+ /* *
+ * @dev Emesso quando `value` token vengono spostati da un account (`from`) a
+ * un altro (`to`).
*
- * Note that `value` may be zero.
- */
+ * Nota che `value` può essere zero. */
+
+
+
+
+
+
event Transfer(address indexed from, address indexed to, uint256 value);
- /**
- * @dev Emitted when the allowance of a `spender` for an `owner` is set by
- * a call to {approve}. `value` is the new allowance.
- */
+ /* *
+ * @dev Emesso quando il limite di spesa di uno `spender` per un `owner` viene impostato da
+ * una chiamata a {approve}. `value` è il nuovo limite di spesa. */
+
+
+
+
event Approval(address indexed owner, address indexed spender, uint256 value);
}
```
-Questi eventi sono emessi quando lo stato del contratto ERC-20 cambia.
+Questi eventi vengono emessi quando lo stato del contratto ERC-20 cambia.
-## Il Contratto effettivo {#the-actual-contract}
+## Il Contratto Effettivo {#the-actual-contract}
-Si tratta del contratto vero e proprio che implementa lo standard ERC-20, [preso da qui](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol). Non è destinato a essere utilizzato così com'è, ma puoi [ereditare](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm) la sua struttura ed estenderla per ottenere un qualcosa di utilizzabile.
+Questo è il contratto effettivo che implementa lo standard ERC-20, [preso da qui](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol). Non è pensato per essere utilizzato così com'è, ma puoi [ereditare](https://www.tutorialspoint.com/solidity/solidity_inheritance.htm) da esso per estenderlo a qualcosa di utilizzabile.
```solidity
// SPDX-License-Identifier: MIT
@@ -196,9 +242,9 @@ pragma solidity >=0.6.0 <0.8.0;
-### Dichiarazioni relative all'importazione {#import-statements}
+### Dichiarazioni di Importazione {#import-statements}
-Oltre alle definizioni d'interfaccia summenzionate, la definizione del contratto importa altri due file:
+Oltre alle definizioni dell'interfaccia di cui sopra, la definizione del contratto importa altri due file:
```solidity
@@ -207,48 +253,71 @@ import "./IERC20.sol";
import "../../math/SafeMath.sol";
```
-- `GSN/Context.sol` è la definizione necessaria per usare [OpenGSN](https://www.opengsn.org/), un sistema che consente agli utenti senza ether di usare la blockchain. Tieni conto che questa è una versione obsoleta. Se vuoi integrare con OpenGSN [usa questo tutorial](https://docs.opengsn.org/javascript-client/tutorial.html).
-- [La libreria SafeMath](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/), usata per effettuare addizioni e sottrazioni senza sovraflussi. È necessaria perché altrimenti una persona potrebbe in qualche modo avere un token, spenderne due e poi ritrovarsi con 2^256-1.
+- `GSN/Context.sol` contiene le definizioni necessarie per utilizzare [OpenGSN](https://www.opengsn.org/), un sistema che consente agli utenti senza ether di utilizzare la blockchain. Nota che questa è una vecchia versione, se vuoi integrarti con OpenGSN [usa questo tutorial](https://docs.opengsn.org/javascript-client/tutorial.html).
+- [La libreria SafeMath](https://ethereumdev.io/using-safe-math-library-to-prevent-from-overflows/), che previene overflow/underflow aritmetici per le versioni di Solidity **<0.8.0**. In Solidity ≥0.8.0, le operazioni aritmetiche si annullano automaticamente in caso di overflow/underflow, rendendo SafeMath non necessaria. Questo contratto utilizza SafeMath per la retrocompatibilità con le versioni precedenti del compilatore.
Questo commento spiega lo scopo del contratto.
```solidity
-/**
- * @dev Implementation of the {IERC20} interface.
+/* *
+ * @dev Implementazione dell'interfaccia {IERC20}.
*
- * This implementation is agnostic to the way tokens are created. This means
- * that a supply mechanism has to be added in a derived contract using {_mint}.
- * For a generic mechanism see {ERC20PresetMinterPauser}.
+ * Questa implementazione è agnostica rispetto al modo in cui vengono creati i token. Ciò significa
+ * che un meccanismo di fornitura deve essere aggiunto in un contratto derivato utilizzando {_mint}.
+ * Per un meccanismo generico vedi {ERC20PresetMinterPauser}.
*
- * TIP: For a detailed writeup see our guide
+ * SUGGERIMENTO: Per una descrizione dettagliata vedi la nostra guida
* https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
* to implement supply mechanisms].
*
- * We have followed general OpenZeppelin guidelines: functions revert instead
- * of returning `false` on failure. This behavior is nonetheless conventional
- * and does not conflict with the expectations of ERC20 applications.
+ * Abbiamo seguito le linee guida generali di OpenZeppelin: le funzioni si annullano (revert) invece
+ * di restituire `false` in caso di fallimento. Questo comportamento è tuttavia convenzionale
+ * e non è in conflitto con le aspettative delle applicazioni ERC20.
*
- * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
- * This allows applications to reconstruct the allowance for all accounts just
- * by listening to said events. Other implementations of the EIP may not emit
- * these events, as it isn't required by the specification.
+ * Inoltre, un evento {Approval} viene emesso alle chiamate a {transferFrom}.
+ * Questo permette alle applicazioni di ricostruire il limite di spesa per tutti gli account semplicemente
+ * ascoltando tali eventi. Altre implementazioni dell'EIP potrebbero non emettere
+ * questi eventi, poiché non è richiesto dalle specifiche.
*
- * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
- * functions have been added to mitigate the well-known issues around setting
- * allowances. See {IERC20-approve}.
- */
+ * Infine, le funzioni non standard {decreaseAllowance} e {increaseAllowance}
+ * sono state aggiunte per mitigare i ben noti problemi relativi all'impostazione
+ * dei limiti di spesa. Vedi {IERC20-approve}. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
```
-### Composizione del contratto {#contract-definition}
+### Definizione del Contratto {#contract-definition}
```solidity
contract ERC20 is Context, IERC20 {
```
-Questa riga specifica l'eredità, in questo caso da `IERC20` da sopra e `Context`, per OpenGSN.
+Questa riga specifica l'ereditarietà, in questo caso da `IERC20` di cui sopra e `Context`, per OpenGSN.
@@ -258,19 +327,19 @@ Questa riga specifica l'eredità, in questo caso da `IERC20` da sopra e `Context
```
-Questa riga allega la libreria `SafeMath` al tipo `uint256`. Puoi trovare questa libreria [qui](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol).
+Questa riga collega la libreria `SafeMath` al tipo `uint256`. Puoi trovare questa libreria [qui](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/SafeMath.sol).
-### Definizioni delle variabili {#variable-definitions}
+### Definizioni delle Variabili {#variable-definitions}
-Queste definizioni specificano le variabili di stato del contratto. Queste variabili sono dichiarate come `private`, ma ciò significa solo che gli altri contratti sulla blockchain non possono leggerle. _Non ci sono segreti sulla blockchain_, il software su ogni nodo ha lo stato di ciascun contratto in ogni blocco. Per convenzione, le variabili di stato sono denominate `_`.
+Queste definizioni specificano le variabili di stato del contratto. Queste variabili sono dichiarate `private`, ma ciò significa solo che altri contratti sulla blockchain non possono leggerle. _Non ci sono segreti sulla blockchain_, il software su ogni nodo ha lo stato di ogni contratto a ogni blocco. Per convenzione, le variabili di stato sono chiamate `_`.
-Le prime due variabili sono di [mappatura](https://www.tutorialspoint.com/solidity/solidity_mappings.htm), il che significa che si comportano più o meno come [insiemi associativi](https://wikipedia.org/wiki/Associative_array), se con la differenza che le chiavi sono valori numerici. La memoria è allocata solo per le voci che hanno valori differenti dal default (zero).
+Le prime due variabili sono [mappature (mapping)](https://www.tutorialspoint.com/solidity/solidity_mappings.htm), il che significa che si comportano all'incirca come gli [array associativi](https://wikipedia.org/wiki/Associative_array), tranne per il fatto che le chiavi sono valori numerici. L'archiviazione viene allocata solo per le voci che hanno valori diversi da quello predefinito (zero).
```solidity
mapping (address => uint256) private _balances;
```
-La prima mappatura, `_balances` è composta da indirizzi e dai rispettivi saldi di questo token. Per accedere al saldo, usa questa sintassi: `_balances[]`.
+La prima mappatura, `_balances`, rappresenta gli indirizzi e i loro rispettivi saldi di questo token. Per accedere al saldo, usa questa sintassi: `_balances[]`.
@@ -278,7 +347,7 @@ La prima mappatura, `_balances` è composta da indirizzi e dai rispettivi saldi
mapping (address => mapping (address => uint256)) private _allowances;
```
-Questa variabile, `_allowances`, memorizza i margini di tolleranza spiegati in precedenza. Il primo indice è il proprietario dei token e il secondo è il contratto con il margine di tolleranza. Per accedere all'importo che l'indirizzo A può spendere dal conto dell'indirizzo B, usa `_allowances[B][A]`.
+Questa variabile, `_allowances`, memorizza le autorizzazioni spiegate in precedenza. Il primo indice è il proprietario dei token, e il secondo è il contratto con l'autorizzazione. Per accedere all'importo che l'indirizzo A può spendere dall'account dell'indirizzo B, usa `_allowances[B][A]`.
@@ -286,7 +355,7 @@ Questa variabile, `_allowances`, memorizza i margini di tolleranza spiegati in p
uint256 private _totalSupply;
```
-Come suggerisce il nome, questa variabile tiene traccia della fornitura totale di token.
+Come suggerisce il nome, questa variabile tiene traccia dell'offerta totale di token.
@@ -296,126 +365,164 @@ Come suggerisce il nome, questa variabile tiene traccia della fornitura totale d
uint8 private _decimals;
```
-Queste tre variabili sono usate per migliorare la leggibilità. Le prime due sono autoesplicative, ma `_decimals` no.
+Queste tre variabili sono utilizzate per migliorare la leggibilità. Le prime due si spiegano da sole, ma `_decimals` no.
-Da un lato, Ethereum non ha un numero in virgola mobile o variabili frazionali. Dall'altro, gli esseri vogliono la libertà di dividere i token. Un motivo per cui è stato scelto l'oro per gli scambi era la difficoltà di dare il resto quando qualcuno voleva comprare una quantità di mucca equivalente a un'anatra.
+Da un lato, Ethereum non ha variabili a virgola mobile o frazionarie. Dall'altro lato, agli esseri umani piace poter dividere i token. Uno dei motivi per cui le persone hanno scelto l'oro come valuta è che era difficile dare il resto quando qualcuno voleva comprare una mucca per il valore di un'anatra.
-La soluzione è tenere traccia degli interi e, al posto del token reale, contare un token frazionale, quasi privo di valore. Nel caso dell'ether, il token frazionale è detto wei e 10^18 wei sono pari a un ETH. Mentre scriviamo questo articolo, 10.000.000.000.000 wei corrispondono a circa un centesimo di dollaro americano o di euro.
+La soluzione è tenere traccia dei numeri interi, ma contare invece del token reale un token frazionario che è quasi senza valore. Nel caso dell'ether, il token frazionario si chiama wei, e 10^18 wei equivalgono a un ETH. Al momento della stesura, 10.000.000.000.000 wei corrispondono a circa un centesimo di dollaro USA o di euro.
-Le applicazioni devono sapere come mostrare il saldo di token. Se un utente ha 3.141.000.000.000.000.000 wei, vuol dire che ha in mano 3,14 ETH? O forse 31,41 ETH? O magari 3.141 ETH? Nel caso dell'ether, è definito a 10^18 wei per ETH, ma per il tuo token, puoi selezionare un valore differente. Se dividere il token non ha senso, puoi usare un valore `_decimals` di zero. Se vuoi usare lo stesso standard come ETH, usa il valore **18**.
+Le applicazioni devono sapere come visualizzare il saldo del token. Se un utente ha 3.141.000.000.000.000.000 wei, sono 3,14 ETH? 31,41 ETH? 3.141 ETH? Nel caso dell'ether è definito 10^18 wei per ETH, ma per il tuo token puoi selezionare un valore diverso. Se dividere il token non ha senso, puoi usare un valore `_decimals` pari a zero. Se vuoi usare lo stesso standard dell'ETH, usa il valore **18**.
-### Il costruttore {#the-constructor}
+### Il Costruttore {#the-constructor}
```solidity
- /**
- * @dev Sets the values for {name} and {symbol}, initializes {decimals} with
- * a default value of 18.
+ /* *
+ * @dev Imposta i valori per {name} e {symbol}, inizializza {decimals} con
+ * un valore predefinito di 18.
*
- * To select a different value for {decimals}, use {_setupDecimals}.
+ * Per selezionare un valore diverso per {decimals}, usa {_setupDecimals}.
*
- * All three of these values are immutable: they can only be set once during
- * construction.
- */
+ * Tutti e tre questi valori sono immutabili: possono essere impostati solo una volta durante
+ * la costruzione. */
+
+
+
+
+
+
+
+
+
constructor (string memory name_, string memory symbol_) public {
+ // In Solidity ≥0.7.0, 'public' è implicito e può essere omesso.
+
_name = name_;
_symbol = symbol_;
_decimals = 18;
}
```
-Il costruttore viene chiamato alla prima creazione del contratto. Per convenzione, i parametri della funzione sono denominati `_`.
+Il costruttore viene chiamato quando il contratto viene creato per la prima volta. Per convenzione, i parametri della funzione sono chiamati `_`.
-### Funzioni dell'interfaccia utente {#user-interface-functions}
+### Funzioni dell'Interfaccia Utente {#user-interface-functions}
```solidity
- /**
- * @dev Returns the name of the token.
- */
+ /* *
+ * @dev Restituisce il nome del token. */
+
+
+
function name() public view returns (string memory) {
return _name;
}
- /**
- * @dev Returns the symbol of the token, usually a shorter version of the
- * name.
- */
+ /* *
+ * @dev Restituisce il simbolo del token, di solito una versione più corta del
+ * nome. */
+
+
+
+
function symbol() public view returns (string memory) {
return _symbol;
}
- /**
- * @dev Returns the number of decimals used to get its user representation.
- * For example, if `decimals` equals `2`, a balance of `505` tokens should
- * be displayed to a user as `5,05` (`505 / 10 ** 2`).
+ /* *
+ * @dev Restituisce il numero di decimali utilizzati per ottenere la sua rappresentazione utente.
+ * Ad esempio, se `decimals` è uguale a `2`, un saldo di `505` token dovrebbe
+ * essere mostrato a un utente come `5,05` (`505 / 10 ** 2`).
*
- * Tokens usually opt for a value of 18, imitating the relationship between
- * ether and wei. This is the value {ERC20} uses, unless {_setupDecimals} is
- * called.
+ * I token di solito optano per un valore di 18, imitando la relazione tra
+ * ether e wei. Questo è il valore che {ERC20} utilizza, a meno che non venga chiamato
+ * {_setupDecimals}.
*
- * NOTE: This information is only used for _display_ purposes: it in
- * no way affects any of the arithmetic of the contract, including
- * {IERC20-balanceOf} and {IERC20-transfer}.
- */
+ * NOTA: Questa informazione è utilizzata solo a scopo di _visualizzazione_: non
+ * influisce in alcun modo sull'aritmetica del contratto, inclusi
+ * {IERC20-balanceOf} e {IERC20-transfer}. */
+
+
+
+
+
+
+
+
+
+
+
+
+
function decimals() public view returns (uint8) {
return _decimals;
}
```
-Queste funzioni, `name`, `symbol`, e `decimals` aiutano le interfacce utente a conoscere il tuo contratto, in modo da visualizzarlo correttamente.
+Queste funzioni, `name`, `symbol` e `decimals` aiutano le interfacce utente a conoscere il tuo contratto in modo che possano visualizzarlo correttamente.
-Il tipo di restituzione è `string memory`, a significare che la restituzione è una stringa archiviata in memoria. Le variabili, come le stringhe, sono memorizzabili in tre posizioni:
+Il tipo di ritorno è `string memory`, il che significa che restituisce una stringa memorizzata in memoria. Le variabili, come le stringhe, possono essere memorizzate in tre posizioni:
-| | Durata | Accesso al contratto | Costo del Gas |
-| ------------- | ----------------------- | -------------------- | ---------------------------------------------------------------------------------- |
-| Memoria | Chiamata della funzione | Lettura/Scrittura | Decine o centinaia (maggiori per maggiori posizioni) |
-| Calldata | Chiamata della funzione | Sola Lettura | Inutilizzabile come tipo di restituzione, solo un tipo di parametro della funzione |
-| Archiviazione | Fino alla modifica | Lettura/Scrittura | Elevato (800 per la lettura, 20.000 per la scrittura) |
+| | Durata | Accesso al Contratto | Costo del Gas |
+| -------- | ------------- | --------------- | -------------------------------------------------------------- |
+| Memoria (Memory) | Chiamata di funzione | Lettura/Scrittura | Decine o centinaia (più alto per posizioni più alte) |
+| Dati di chiamata (Calldata) | Chiamata di funzione | Solo Lettura | Non può essere usato come tipo di ritorno, solo come tipo di parametro di funzione |
+| Archiviazione (Storage) | Fino a modifica | Lettura/Scrittura | Alto (800 per la lettura, 20k per la scrittura) |
In questo caso, `memory` è la scelta migliore.
-### Informazioni di lettura del token {#read-token-information}
+### Leggere le Informazioni del Token {#read-token-information}
-Queste sono funzioni che forniscono informazioni sul token, la fornitura totale o il saldo di un conto.
+Queste sono funzioni che forniscono informazioni sul token, che si tratti dell'offerta totale o del saldo di un account.
```solidity
- /**
- * @dev See {IERC20-totalSupply}.
- */
+ /* *
+ * @dev Vedi {IERC20-totalSupply}. */
+
+
+
function totalSupply() public view override returns (uint256) {
return _totalSupply;
}
```
-La funzione `totalSupply` restituisce la fornitura totale di token.
+La funzione `totalSupply` restituisce l'offerta totale di token.
```solidity
- /**
- * @dev See {IERC20-balanceOf}.
- */
+ /* *
+ * @dev Vedi {IERC20-balanceOf}. */
+
+
+
function balanceOf(address account) public view override returns (uint256) {
return _balances[account];
}
```
-Leggi il saldo di un conto. Nota che chiunque può ottenere il saldo del conto di qualcun altro. Non ha senso provare a nascondere queste informazioni, perché sono comunque disponibili su ogni nodo. _Non ci sono segreti sulla blockchain._
+Legge il saldo di un account. Nota che a chiunque è permesso ottenere il saldo dell'account di chiunque altro. Non ha senso cercare di nascondere queste informazioni, perché sono comunque disponibili su ogni nodo. _Non ci sono segreti sulla blockchain._
-### Trasferire token {#transfer-tokens}
+### Trasferire Token {#transfer-tokens}
```solidity
- /**
- * @dev See {IERC20-transfer}.
+ /* *
+ * @dev Vedi {IERC20-transfer}.
*
- * Requirements:
+ * Requisiti:
*
- * - `recipient` cannot be the zero address.
- * - the caller must have a balance of at least `amount`.
- */
+ * - `recipient` non può essere l'indirizzo zero.
+ * - il chiamante deve avere un saldo di almeno `amount`. */
+
+
+
+
+
+
+
+
function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
```
-La funzione `transfer` è chiamata per trasferire i token dal conto del mittente a un altro. Nota che anche se viene restituito un valore booleano, quel valore è sempre **true**. Se il trasferimento fallisce, il contratto ripristina la chiamata.
+La funzione `transfer` viene chiamata per trasferire token dall'account del mittente a uno diverso. Nota che anche se restituisce un valore booleano, quel valore è sempre **true**. Se il trasferimento fallisce, il contratto annulla (revert) la chiamata.
@@ -425,44 +532,52 @@ La funzione `transfer` è chiamata per trasferire i token dal conto del mittente
}
```
-La funzione `_transfer` fa il lavoro effettivo. È una funzione privata, chiamabile solo da altre funzioni del contratto. Per convenzione le funzioni private sono denominate `_`, come le variabili di stato.
+La funzione `_transfer` fa il lavoro effettivo. È una funzione privata che può essere chiamata solo da altre funzioni del contratto. Per convenzione le funzioni private sono chiamate `_`, come le variabili di stato.
-Normalmente, in Solidity usiamo `msg.sender` per il mittente del messaggio. Tuttavia, ciò corrompe [OpenGSN](http://opengsn.org/). Se vogliamo consentire transazioni senza ether con il nostro token, dobbiamo usare `_msgSender()`. Restituisce `msg.sender` per le transazioni normali, ma per quelle senza ether restituisce il firmatario originale e non il contratto che ha trasmesso il messaggio.
+Normalmente in Solidity usiamo `msg.sender` per il mittente del messaggio. Tuttavia, questo rompe [OpenGSN](http://opengsn.org/). Se vogliamo consentire transazioni senza ether con il nostro token, dobbiamo usare `_msgSender()`. Restituisce `msg.sender` per le transazioni normali, ma per quelle senza ether restituisce il firmatario originale e non il contratto che ha inoltrato il messaggio.
-### Funzioni di tolleranza {#allowance-functions}
+### Funzioni di Autorizzazione {#allowance-functions}
-Sono le funzioni che implementano il margine di tolleranza: `allowance`, `approve`, `transferFrom` e `_approve`. Inoltre, l'implementazione di OpenZeppelin va oltre lo standard di base e include alcune funzionalità che migliorano la sicurezza: `increaseAllowance` e `decreaseAllowance`.
+Queste sono le funzioni che implementano la funzionalità di autorizzazione: `allowance`, `approve`, `transferFrom` e `_approve`. Inoltre, l'implementazione di OpenZeppelin va oltre lo standard di base per includere alcune funzionalità che migliorano la sicurezza: `increaseAllowance` e `decreaseAllowance`.
-#### La funzione di tolleranza {#allowance}
+#### La funzione allowance {#allowance}
```solidity
- /**
- * @dev See {IERC20-allowance}.
- */
+ /* *
+ * @dev Vedi {IERC20-allowance}. */
+
+
+
function allowance(address owner, address spender) public view virtual override returns (uint256) {
return _allowances[owner][spender];
}
```
-La funzione `allowance` consente a chiunque di verificare qualsiasi margine di tolleranza.
+La funzione `allowance` consente a tutti di controllare qualsiasi autorizzazione.
-#### La funzione di approvazione {#approve}
+#### La funzione approve {#approve}
```solidity
- /**
- * @dev See {IERC20-approve}.
+ /* *
+ * @dev Vedi {IERC20-approve}.
*
- * Requirements:
+ * Requisiti:
*
- * - `spender` cannot be the zero address.
- */
+ * - `spender` non può essere l'indirizzo zero. */
+
+
+
+
+
+
+
function approve(address spender, uint256 amount) public virtual override returns (bool) {
```
-Questa funzione viene chiamata per creare un margine di tolleranza. È simile alla suddetta funzione `transfer`:
+Questa funzione viene chiamata per creare un'autorizzazione. È simile alla funzione `transfer` di cui sopra:
-- La funzione chiama semplicemente una funzione interna (in questo caso, `_approve`), che fa il lavoro vero e proprio.
-- La funzione restituisce `true` (se va a buon fine), altrimenti si ripristina.
+- La funzione chiama semplicemente una funzione interna (in questo caso, `_approve`) che fa il vero lavoro.
+- La funzione restituisce `true` (se ha successo) o si annulla (se non lo ha).
@@ -472,26 +587,38 @@ Questa funzione viene chiamata per creare un margine di tolleranza. È simile al
}
```
-Usiamo le funzioni interne per minimizzre il numero di posti in cui si verificano cambi di stato. _Qualsiasi_ funzione che cambia stato costituisce un potenziale rischio di sicurezza, che va controllato per sicurezza. Così facendo riduciamo il rischio di conseguenze negative.
+Usiamo funzioni interne per ridurre al minimo il numero di punti in cui avvengono i cambiamenti di stato. _Qualsiasi_ funzione che modifichi lo stato è un potenziale rischio per la sicurezza che deve essere verificato. In questo modo abbiamo meno possibilità di sbagliare.
#### La funzione transferFrom {#transferFrom}
-È la funzione chiamata dallo spender per spendere un margine di tolleranza. Richiede due operazioni: trasferire l'importo speso e ridurre il margine di tolleranza in misura pari allo stesso importo.
+Questa è la funzione che uno spenditore chiama per spendere un'autorizzazione. Ciò richiede due operazioni: trasferire l'importo speso e ridurre l'autorizzazione di tale importo.
```solidity
- /**
- * @dev See {IERC20-transferFrom}.
+ /* *
+ * @dev Vedi {IERC20-transferFrom}.
*
- * Emits an {Approval} event indicating the updated allowance. This is not
- * required by the EIP. See the note at the beginning of {ERC20}.
+ * Emette un evento {Approval} che indica il limite di spesa aggiornato. Questo non è
+ * richiesto dall'EIP. Vedi la nota all'inizio di {ERC20}.
*
- * Requirements:
+ * Requisiti:
*
- * - `sender` and `recipient` cannot be the zero address.
- * - `sender` must have a balance of at least `amount`.
- * - the caller must have allowance for ``sender``'s tokens of at least
- * `amount`.
- */
+ * - `sender` e `recipient` non possono essere l'indirizzo zero.
+ * - `sender` deve avere un saldo di almeno `amount`.
+ * - il chiamante deve avere un limite di spesa per i token di ``sender`` di almeno
+ * `amount`. */
+
+
+
+
+
+
+
+
+
+
+
+
+
function transferFrom(address sender, address recipient, uint256 amount) public virtual
override returns (bool) {
_transfer(sender, recipient, amount);
@@ -499,7 +626,7 @@ Usiamo le funzioni interne per minimizzre il numero di posti in cui si verifican
-La funzione `a.sub(b, "message")` produce due azioni. Innanzi tutto calcola `a-b`, ovvero il nuovo margine di tolleranza (allowance). Quindi controlla che tale risultato non sia negativo. Se lo è, la chiamata si ripristina con il messaggio fornito. Occorre notare che, in caso di ripristino, qualsiasi elaborazione effettuata in precedenza durante tale chiamata viene ignorata, così da evitare di dover annullare il `_transfer`.
+La chiamata di funzione `a.sub(b, "message")` fa due cose. Primo, calcola `a-b`, che è la nuova autorizzazione. Secondo, controlla che questo risultato non sia negativo. Se è negativo, la chiamata si annulla con il messaggio fornito. Nota che quando una chiamata si annulla, qualsiasi elaborazione eseguita in precedenza durante quella chiamata viene ignorata, quindi non abbiamo bisogno di annullare il `_transfer`.
```solidity
_approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount,
@@ -510,73 +637,97 @@ La funzione `a.sub(b, "message")` produce due azioni. Innanzi tutto calcola `a-b
#### Aggiunte di sicurezza di OpenZeppelin {#openzeppelin-safety-additions}
-È pericoloso impostare un margine di tolleranza diverso da zero su un altro valore diverso da zero, perché puoi controllare solo l'ordine delle tue transazioni, ma non di quelle altrui. Immagina che ci siano due utenti: Alice, una ragazza ingenua, e Bill, un uomo disonesto. Alice vuole ricevere da Bill un servizio che secondo lei costa cinque token, quindi concede a Bill un margine di tolleranza di cinque token.
+È pericoloso impostare un'autorizzazione diversa da zero a un altro valore diverso da zero, perché controlli solo l'ordine delle tue transazioni, non quello di nessun altro. Immagina di avere due utenti, Alice che è ingenua e Bill che è disonesto. Alice vuole un servizio da Bill, che pensa costi cinque token, quindi dà a Bill un'autorizzazione di cinque token.
-Poi qualcosa cambia e il prezzo di Bill aumenta a dieci token. Alice, che è ancora interessata a ricevere il servizio, invia una transazione che imposta il margine di tolleranza di Bill a dieci. Quando Bill vede questa nuova transazione nel pool della transazione, invia una transazione che spende cinque token di Alice e ha un prezzo del gas molto maggiore, così che sarà minata più rapidamente. In questo modo Bill può spendere prima i cinque token e poi, una volta minato il nuovo margine di tolleranza di Alice, spenderne altri dieci per un prezzo complessivo di quindici token, più di quanto Alice volesse autorizzare. Questa tecnica è detta [front-running](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running)
+Poi qualcosa cambia e il prezzo di Bill sale a dieci token. Alice, che vuole ancora il servizio, invia una transazione che imposta l'autorizzazione di Bill a dieci. Nel momento in cui Bill vede questa nuova transazione nel pool delle transazioni, invia una transazione che spende i cinque token di Alice e ha un prezzo del gas molto più alto in modo che venga minata più velocemente. In questo modo Bill può spendere prima cinque token e poi, una volta minata la nuova autorizzazione di Alice, spenderne altri dieci per un prezzo totale di quindici token, più di quanto Alice intendesse autorizzare. Questa tecnica è chiamata [front-running](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/#front-running)
-| Transazione di Alice | Nonce di Alice | Transazione di Bill | Nonce di Bill | Tolleranza di Bill | Entrate totali di Bill da Alice |
-| -------------------- | -------------- | ----------------------------- | ------------- | ------------------ | ------------------------------- |
-| approve(Bill, 5) | 10 | | | 5 | 0 |
-| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 |
-| approve(Bill, 10) | 11 | | | 10 | 5 |
-| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 15 |
+| Transazione di Alice | Nonce di Alice | Transazione di Bill | Nonce di Bill | Autorizzazione di Bill | Entrate Totali di Bill da Alice |
+| ----------------- | ----------- | ----------------------------- | ---------- | ---------------- | ---------------------------- |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 |
+| approve(Bill, 10) | 11 | | | 10 | 5 |
+| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 15 |
-Per evitare questo problema, queste due funzioni (`increaseAllowance` e `decreaseAllowance`) ti consentono di modificare il margine di tolleranza di un importo specifico. Quindi, se Bill avesse già speso cinque token, potrà spenderne solo altri cinque. A seconda delle tempistiche, esistono due modi in cui questo può funzionare, entrambi terminano con Bill che riceve solo dieci token:
+Per evitare questo problema, queste due funzioni (`increaseAllowance` e `decreaseAllowance`) consentono di modificare l'autorizzazione di un importo specifico. Quindi, se Bill avesse già speso cinque token, potrà spenderne solo altri cinque. A seconda delle tempistiche, ci sono due modi in cui questo può funzionare, entrambi i quali finiscono con Bill che ottiene solo dieci token:
A:
-| Transazione di Alice | Nonce di Alice | Transazione di Bill | Nonce di Bill | Tolleranza di Bill | Entrate totali di Bill da Alice |
-| -------------------------- | --------------:| ---------------------------- | -------------:| ------------------:| ------------------------------- |
-| approve(Bill, 5) | 10 | | | 5 | 0 |
-| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 |
-| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 |
-| | | transferFrom(Alice, Bill, 5) | 10,124 | 0 | 10 |
+| Transazione di Alice | Nonce di Alice | Transazione di Bill | Nonce di Bill | Autorizzazione di Bill | Entrate Totali di Bill da Alice |
+| -------------------------- | ----------: | ---------------------------- | ---------: | ---------------: | ---------------------------- |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| | | transferFrom(Alice, Bill, 5) | 10,123 | 0 | 5 |
+| increaseAllowance(Bill, 5) | 11 | | | 0+5 = 5 | 5 |
+| | | transferFrom(Alice, Bill, 5) | 10,124 | 0 | 10 |
B:
-| Transazione di Alice | Nonce di Alice | Transazione di Bill | Nonce di Bill | Tolleranza di Bill | Entrate totali di Bill da Alice |
-| -------------------------- | --------------:| ----------------------------- | -------------:| ------------------:| -------------------------------:|
-| approve(Bill, 5) | 10 | | | 5 | 0 |
-| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 |
-| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 10 |
+| Transazione di Alice | Nonce di Alice | Transazione di Bill | Nonce di Bill | Autorizzazione di Bill | Entrate Totali di Bill da Alice |
+| -------------------------- | ----------: | ----------------------------- | ---------: | ---------------: | ---------------------------: |
+| approve(Bill, 5) | 10 | | | 5 | 0 |
+| increaseAllowance(Bill, 5) | 11 | | | 5+5 = 10 | 0 |
+| | | transferFrom(Alice, Bill, 10) | 10,124 | 0 | 10 |
```solidity
- /**
- * @dev Atomically increases the allowance granted to `spender` by the caller.
+ /* *
+ * @dev Aumenta atomicamente il limite di spesa concesso a `spender` dal chiamante.
*
- * This is an alternative to {approve} that can be used as a mitigation for
- * problems described in {IERC20-approve}.
+ * Questa è un'alternativa a {approve} che può essere utilizzata come mitigazione per
+ * i problemi descritti in {IERC20-approve}.
*
- * Emits an {Approval} event indicating the updated allowance.
+ * Emette un evento {Approval} che indica il limite di spesa aggiornato.
*
- * Requirements:
+ * Requisiti:
*
- * - `spender` cannot be the zero address.
- */
+ * - `spender` non può essere l'indirizzo zero. */
+
+
+
+
+
+
+
+
+
+
+
+
function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
_approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));
return true;
}
```
-La funzione `a.add(b)` è un'aggiunta sicura. Nell'improbabile caso in cui `a`+`b`>=`2^256`, non ha luogo il mormale avvolgimento come avviene con l'addizione normale.
+La funzione `a.add(b)` è un'addizione sicura. Nel caso improbabile in cui `a`+`b`>=`2^256`, non ricomincia da zero (wrap around) come fa la normale addizione.
```solidity
- /**
- * @dev Atomically decreases the allowance granted to `spender` by the caller.
+ /* *
+ * @dev Diminuisce atomicamente il limite di spesa concesso a `spender` dal chiamante.
*
- * This is an alternative to {approve} that can be used as a mitigation for
- * problems described in {IERC20-approve}.
+ * Questa è un'alternativa a {approve} che può essere utilizzata come mitigazione per
+ * i problemi descritti in {IERC20-approve}.
*
- * Emits an {Approval} event indicating the updated allowance.
+ * Emette un evento {Approval} che indica il limite di spesa aggiornato.
*
- * Requirements:
+ * Requisiti:
*
- * - `spender` cannot be the zero address.
- * - `spender` must have allowance for the caller of at least
- * `subtractedValue`.
- */
+ * - `spender` non può essere l'indirizzo zero.
+ * - `spender` deve avere un limite di spesa per il chiamante di almeno
+ * `subtractedValue`. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
_approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue,
"ERC20: decreased allowance below zero"));
@@ -584,31 +735,44 @@ La funzione `a.add(b)` è un'aggiunta sicura. Nell'improbabile caso in cui `a`+`
}
```
-### Funzioni che modificano le informazioni del token {#functions-that-modify-token-information}
+### Funzioni che Modificano le Informazioni del Token {#functions-that-modify-token-information}
-Queste sono le quattro funzioni che effettuano il lavoro effettivo: `_transfer`, `_mint`, `_burn` e `_approve`.
+Queste sono le quattro funzioni che fanno il lavoro effettivo: `_transfer`, `_mint`, `_burn` e `_approve`.
-#### La funzione \_transfer {#_transfer}
+#### La funzione _transfer {#_transfer}
```solidity
- /**
- * @dev Moves tokens `amount` from `sender` to `recipient`.
+ /* *
+ * @dev Sposta `amount` token da `sender` a `recipient`.
*
- * This is internal function is equivalent to {transfer}, and can be used to
- * e.g., implement automatic token fees, slashing mechanisms, etc.
+ * Questa funzione interna è equivalente a {transfer}, e può essere utilizzata per
+ * es., implementare commissioni automatiche sui token, meccanismi di slashing, ecc.
*
- * Emits a {Transfer} event.
+ * Emette un evento {Transfer}.
*
- * Requirements:
+ * Requisiti:
*
- * - `sender` cannot be the zero address.
- * - `recipient` cannot be the zero address.
- * - `sender` must have a balance of at least `amount`.
- */
+ * - `sender` non può essere l'indirizzo zero.
+ * - `recipient` non può essere l'indirizzo zero.
+ * - `sender` deve avere un saldo di almeno `amount`. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
function _transfer(address sender, address recipient, uint256 amount) internal virtual {
```
-Questa funzione, `_transfer`, trasferisce i token da un conto all'altro. È chiamata sia da `transfer` (per i trasferimenti dal conto del mittente) che da `transferFrom` (per usare le indennità per trasferire dal conto di qualcun altro).
+Questa funzione, `_transfer`, trasferisce token da un account a un altro. Viene chiamata sia da `transfer` (per i trasferimenti dal proprio account del mittente) sia da `transferFrom` (per l'utilizzo delle autorizzazioni per trasferire dall'account di qualcun altro).
@@ -617,7 +781,7 @@ Questa funzione, `_transfer`, trasferisce i token da un conto all'altro. È chia
require(recipient != address(0), "ERC20: transfer to the zero address");
```
-Nessuno possiedere realmente l'indirizzo zero in Ethereum (ciò significa che nessuno conosce una chiave privata la cui chiave pubblica corrispondente è trasformata all'indirizzo zero). Quando si usa quell'indirizzo, in genere si tratta di un bug del software, quindi falliamo se usiamo l'indirizzo zero come mittente o destinatario.
+Nessuno possiede effettivamente l'indirizzo zero in Ethereum (cioè, nessuno conosce una chiave privata la cui chiave pubblica corrispondente si trasforma nell'indirizzo zero). Quando le persone usano quell'indirizzo, di solito si tratta di un bug del software, quindi falliamo se l'indirizzo zero viene utilizzato come mittente o destinatario.
@@ -626,14 +790,14 @@ Nessuno possiedere realmente l'indirizzo zero in Ethereum (ciò significa che ne
```
-Esistono due modi per usare questo contratto:
+Ci sono due modi per utilizzare questo contratto:
-1. Usarlo come modello per il proprio codice
-1. [Ereditare da esso](https://www.bitdegree.org/learn/solidity-inheritance) e sovrascrivere solo le funzioni da modificare
+1. Usarlo come modello per il tuo codice
+1. [Ereditare da esso](https://www.bitdegree.org/learn/solidity-inheritance) e sovrascrivere solo le funzioni che devi modificare
-Il secondo metodo è di gran lunga migliore perché il codice ERC-20 di OpenZeppelin è stato già controllato e mostrato come sicuro. Quando si usa l'eredità, le funzioni da modificare sono note e, per fidarsi del tuo contratto, gli altri devono controllare solo quelle funzioni specifiche.
+Il secondo metodo è molto migliore perché il codice ERC-20 di OpenZeppelin è già stato verificato e si è dimostrato sicuro. Quando usi l'ereditarietà è chiaro quali sono le funzioni che modifichi, e per fidarsi del tuo contratto le persone devono solo verificare quelle funzioni specifiche.
-Spesso è utile eseguire una funzione ogni volta che i token passano di mano. Tuttavia, `_transfer` è una funzione davvero importante ed esiste il rischio di scriverla in modo non sicuro (vedi sotto), quindi è meglio non sovrascriverla. La soluzione è `_beforeTokenTransfer`, una [funzione hook](https://wikipedia.org/wiki/Hooking). Puoi sovrascrivere questa funzione, che verrà quindi richiamata a ogni trasferimento.
+Spesso è utile eseguire una funzione ogni volta che i token passano di mano. Tuttavia, `_transfer` è una funzione molto importante ed è possibile scriverla in modo non sicuro (vedi sotto), quindi è meglio non sovrascriverla. La soluzione è `_beforeTokenTransfer`, una [funzione hook](https://wikipedia.org/wiki/Hooking). Puoi sovrascrivere questa funzione e verrà chiamata a ogni trasferimento.
@@ -642,7 +806,7 @@ Spesso è utile eseguire una funzione ogni volta che i token passano di mano. Tu
_balances[recipient] = _balances[recipient].add(amount);
```
-Queste sono le righe che effettuano concretamente il trasferimento. Nota che non c'è **nulla** tra di esse e che sottraiamo l'importo trasferito dal mittente prima di aggiungerlo al destinatario. Questo passaggio è importante perché, se ci fosse una chiamata a un contratto diverso nel mezzo, potrebbe essere utilizzata per barare su questo contratto. Questo metodo di trasferimento è atomico, in quanto nulla può verificarsi mentre è in corso.
+Queste sono le righe che eseguono effettivamente il trasferimento. Nota che non c'è **nulla** tra di esse, e che sottraiamo l'importo trasferito dal mittente prima di aggiungerlo al destinatario. Questo è importante perché se ci fosse stata una chiamata a un contratto diverso nel mezzo, avrebbe potuto essere usata per imbrogliare questo contratto. In questo modo il trasferimento è atomico, non può succedere nulla nel mezzo.
@@ -651,24 +815,32 @@ Queste sono le righe che effettuano concretamente il trasferimento. Nota che non
}
```
-Infine, emetti un evento `Transfer`. Gli eventi non sono accessibili agli smart contract, ma il codice eseguito al di fuori della blockchain può ascoltarli e reagire a essi. Ad esempio, un portafoglio può tracciare la ricezione di altri token da parte del proprietario.
+Infine, emette un evento `Transfer`. Gli eventi non sono accessibili ai contratti intelligenti, ma il codice in esecuzione all'esterno della blockchain può ascoltare gli eventi e reagire ad essi. Ad esempio, un portafoglio può tenere traccia di quando il proprietario ottiene più token.
-#### Le funzioni \_mint e \_burn {#_mint-and-_burn}
+#### Le funzioni _mint e _burn {#_mint-and-_burn}
-Queste due funzioni (`_mint` e `_burn`) modificano la fornitura totale di token. Sono interne e non esiste alcuna funzione che le chiami in questo contratto, quindi sono utili solo se erediti dal contratto e aggiungi la tua logica per decidere a quali condizioni coniare nuovi token o bruciare quelli esistenti.
+Queste due funzioni (`_mint` e `_burn`) modificano l'offerta totale di token. Sono interne e non c'è alcuna funzione che le chiami in questo contratto, quindi sono utili solo se erediti dal contratto e aggiungi la tua logica per decidere a quali condizioni coniare nuovi token o bruciare quelli esistenti.
-**NOTA:** Ogni token ERC-20 ha la propria logica commerciale che detta la gestione del token. Ad esempio, un contratto di fornitura fissa potrebbe chiamare solo `_mint` nel costruttore e mai `_burn`. Un contratto che vende token chiamerà `_mint` quando è pagato e chiamerà presumibilmente `_burn` a un certo punto per evitare l'inflazione incontrollata.
+**NOTA:** Ogni token ERC-20 ha la propria logica di business che detta la gestione dei token. Ad esempio, un contratto a fornitura fissa potrebbe chiamare `_mint` solo nel costruttore e non chiamare mai `_burn`. Un contratto che vende token chiamerà `_mint` quando viene pagato, e presumibilmente chiamerà `_burn` a un certo punto per evitare un'inflazione fuori controllo.
```solidity
- /** @dev Creates `amount` tokens and assigns them to `account`, increasing
- * the total supply.
+ /* * @dev Crea `amount` token e li assegna a `account`, aumentando
+ * la fornitura totale.
*
- * Emits a {Transfer} event with `from` set to the zero address.
+ * Emette un evento {Transfer} con `from` impostato all'indirizzo zero.
*
- * Requirements:
+ * Requisiti:
*
- * - `to` cannot be the zero address.
- */
+ * - `to` non può essere l'indirizzo zero. */
+
+
+
+
+
+
+
+
+
function _mint(address account, uint256 amount) internal virtual {
require(account != address(0), "ERC20: mint to the zero address");
_beforeTokenTransfer(address(0), account, amount);
@@ -682,18 +854,28 @@ Assicurati di aggiornare `_totalSupply` quando il numero totale di token cambia.
-```
- /**
- * @dev Destroys `amount` tokens from `account`, reducing the
- * total supply.
+```solidity
+ /* *
+ * @dev Distrugge `amount` token da `account`, riducendo la
+ * fornitura totale.
*
- * Emits a {Transfer} event with `to` set to the zero address.
+ * Emette un evento {Transfer} con `to` impostato all'indirizzo zero.
*
- * Requirements:
+ * Requisiti:
*
- * - `account` cannot be the zero address.
- * - `account` must have at least `amount` tokens.
- */
+ * - `account` non può essere l'indirizzo zero.
+ * - `account` deve avere almeno `amount` token. */
+
+
+
+
+
+
+
+
+
+
+
function _burn(address account, uint256 amount) internal virtual {
require(account != address(0), "ERC20: burn from the zero address");
@@ -705,26 +887,38 @@ Assicurati di aggiornare `_totalSupply` quando il numero totale di token cambia.
}
```
-La funzione `_burn` è quasi identica a `_mint`, con la differenza che va in senso opposto.
+La funzione `_burn` è quasi identica a `_mint`, tranne per il fatto che va nell'altra direzione.
-#### La funzione \_approve {#_approve}
+#### La funzione _approve {#_approve}
-Questa è la funzione che specifica concretamente i margini di tolleranza. Nota che consente a un proprietario di specificare una tolleranza superiore al saldo corrente del proprietario. Questo non è un problema, poiché il saldo è controllato al momento del trasferimento, quando potrebbe differire dal saldo alla creazione del margine di tolleranza.
+Questa è la funzione che specifica effettivamente le autorizzazioni. Nota che consente a un proprietario di specificare un'autorizzazione superiore al saldo attuale del proprietario. Questo va bene perché il saldo viene controllato al momento del trasferimento, quando potrebbe essere diverso dal saldo al momento della creazione dell'autorizzazione.
```solidity
- /**
- * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.
+ /* *
+ * @dev Imposta `amount` come limite di spesa di `spender` sui token di `owner`.
*
- * This internal function is equivalent to `approve`, and can be used to
- * e.g., set automatic allowances for certain subsystems, etc.
+ * Questa funzione interna è equivalente a `approve`, e può essere utilizzata per
+ * es., impostare limiti di spesa automatici per determinati sottosistemi, ecc.
*
- * Emits an {Approval} event.
+ * Emette un evento {Approval}.
*
- * Requirements:
+ * Requisiti:
*
- * - `owner` cannot be the zero address.
- * - `spender` cannot be the zero address.
- */
+ * - `owner` non può essere l'indirizzo zero.
+ * - `spender` non può essere l'indirizzo zero. */
+
+
+
+
+
+
+
+
+
+
+
+
+
function _approve(address owner, address spender, uint256 amount) internal virtual {
require(owner != address(0), "ERC20: approve from the zero address");
require(spender != address(0), "ERC20: approve to the zero address");
@@ -734,7 +928,7 @@ Questa è la funzione che specifica concretamente i margini di tolleranza. Nota
-Emette un evento `Approval`. In base a come è scritta l'applicazione, il contratto dello spender può essere informato dell'approvazione dal proprietario o da un server che monitora questi eventi.
+Emette un evento `Approval`. A seconda di come è scritta l'applicazione, il contratto dello spenditore può essere informato dell'approvazione dal proprietario o da un server che ascolta questi eventi.
```solidity
emit Approval(owner, spender, amount);
@@ -742,57 +936,78 @@ Emette un evento `Approval`. In base a come è scritta l'applicazione, il contra
```
-### Modificare la variabile dei decimali {#modify-the-decimals-variable}
+### Modificare la Variabile Decimals {#modify-the-decimals-variable}
```solidity
- /**
- * @dev Sets {decimals} to a value other than the default one of 18.
+ /* *
+ * @dev Imposta {decimals} a un valore diverso da quello predefinito di 18.
*
- * WARNING: This function should only be called from the constructor. Most
- * applications that interact with token contracts will not expect
- * {decimals} to ever change, and may work incorrectly if it does.
- */
+ * AVVERTENZA: Questa funzione dovrebbe essere chiamata solo dal costruttore. La maggior parte
+ * delle applicazioni che interagiscono con i contratti dei token non si aspetterà
+ * che {decimals} cambi mai, e potrebbero funzionare in modo errato se lo fa. */
+
+
+
+
+
+
+
function _setupDecimals(uint8 decimals_) internal {
_decimals = decimals_;
}
```
-Questa funzione modifica la variabile `_decimals`, usata per indicare alle interfacce utente come interpretare l'importo. Suggeriamo di chiamarla dal costruttore. Sarebbe disonesto chiamarla in qualsiasi punto successivo e le applicazioni non sono progettate per gestirla.
+Questa funzione modifica la variabile `_decimals` che viene utilizzata per dire alle interfacce utente come interpretare l'importo. Dovresti chiamarla dal costruttore. Sarebbe disonesto chiamarla in qualsiasi momento successivo, e le applicazioni non sono progettate per gestirlo.
### Hook {#hooks}
```solidity
- /**
- * @dev Hook that is called before any transfer of tokens. This includes
- * minting and burning.
+ /* *
+ * @dev Hook che viene chiamato prima di qualsiasi trasferimento di token. Questo include
+ * il coniare e il bruciare.
*
- * Calling conditions:
+ * Condizioni di chiamata:
*
- * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
- * will be to transferred to `to`.
- * - when `from` is zero, `amount` tokens will be minted for `to`.
- * - when `to` is zero, `amount` of ``from``'s tokens will be burned.
- * - `from` and `to` are never both zero.
+ * - quando `from` e `to` sono entrambi non zero, `amount` dei token di ``from``
+ * saranno trasferiti a `to`.
+ * - quando `from` è zero, `amount` token saranno coniati per `to`.
+ * - quando `to` è zero, `amount` dei token di ``from`` saranno bruciati.
+ * - `from` e `to` non sono mai entrambi zero.
*
- * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
- */
+ * Per saperne di più sugli hook, vai a xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks]. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
}
```
-Questa è la funzione hook da chiamare durante i trasferimenti. Qui è vuota, ma se hai bisogno di fare qualcosa, basta sovrascriverla.
+Questa è la funzione hook da chiamare durante i trasferimenti. Qui è vuota, ma se hai bisogno che faccia qualcosa, basta sovrascriverla.
+
+## Conclusione {#conclusion}
-## Conclusioni {#conclusion}
+Per riepilogare, ecco alcune delle idee più importanti in questo contratto (secondo me, la tua opinione potrebbe variare):
-A titolo di ripasso, ecco alcune delle idee più importanti in questo contrato (a mio parere, probabilmente il tuo sarà diverso):
+- _Non ci sono segreti sulla blockchain_. Qualsiasi informazione a cui un contratto intelligente può accedere è disponibile per tutto il mondo.
+- Puoi controllare l'ordine delle tue transazioni, ma non quando avvengono le transazioni di altre persone. Questo è il motivo per cui modificare un'autorizzazione può essere pericoloso, perché consente allo spenditore di spendere la somma di entrambe le autorizzazioni.
+- I valori di tipo `uint256` ricominciano da zero (wrap around). In altre parole, _0-1=2^256-1_. Se questo non è il comportamento desiderato, devi verificarlo (o usare la libreria SafeMath che lo fa per te). Nota che questo è cambiato in [Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html).
+- Esegui tutti i cambiamenti di stato di un tipo specifico in un luogo specifico, perché semplifica la verifica (auditing). Questo è il motivo per cui abbiamo, ad esempio, `_approve`, che viene chiamata da `approve`, `transferFrom`, `increaseAllowance` e `decreaseAllowance`
+- I cambiamenti di stato dovrebbero essere atomici, senza nessun'altra azione nel mezzo (come puoi vedere in `_transfer`). Questo perché durante il cambiamento di stato si ha uno stato incoerente. Ad esempio, tra il momento in cui deduci dal saldo del mittente e il momento in cui aggiungi al saldo del destinatario ci sono meno token in esistenza di quanti dovrebbero esserci. Questo potrebbe essere potenzialmente abusato se ci sono operazioni tra di loro, specialmente chiamate a un contratto diverso.
-- _Non ci sono segreti sulla blockchain_. Ogni informazione accessibile a uno smart contract è disponibile per il mondo intero.
-- Puoi controllare l'ordine delle tue transazioni, ma non come si verificano quelle altrui. Per questo modificare un'indennità può esser pericoloso, perché consente allo spender di spendere la somma di entrambi i margini di tolleranza.
-- I valori di tipo `uint256` si avvolgono o, in altre parole, _0-1=2^256-1_. Se questo non è il comportamento desiderato, devi verificarlo (o usare la libreria SafeMath più adatta alle tue esigenze). Nota che ciò è cambiato in [Solidity 0.8.0](https://docs.soliditylang.org/en/breaking/080-breaking-changes.html).
-- Effettua tutte le modifiche di un tipo specifico in un luogo specifico, così da semplificare i controlli. Per questo abbiamo, ad esempio, `_approve`, chiamata da `approve`, `transferFrom`, `increaseAllowance` e `decreaseAllowance`
-- I cambi di stato dovrebbero essere atomici, senza altre azioni nel mezzo (come si può vedere in `_transfer`). Questo perché durante il cambio di stato hai uno stato incoerente. Ad esempio, tra il momento in cui detrai dal saldo del mittente e il momento in cui aggiungi al saldo del destinatario, esistono meno token di quanti dovrebbero essercene. Questa condizione potrebbe essere esposta ad abusi se vengono effettuate operazioni tra di essi, specialmente nel caso di chiamate a un contratto differente.
+Ora che hai visto come è scritto il contratto ERC-20 di OpenZeppelin, e specialmente come è reso più sicuro, vai e scrivi i tuoi contratti e applicazioni sicuri.
-Ora che hai visto come è scritto il contratto ERC-20 di OpenZeppelin e specialmente come viene reso più sicuro, vai a scrivere i tuoi contratti sicuri e le tue applicazioni.
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/erc20-with-safety-rails/index.md b/public/content/translations/it/developers/tutorials/erc20-with-safety-rails/index.md
index 0c84502f174..81623ddd6a9 100644
--- a/public/content/translations/it/developers/tutorials/erc20-with-safety-rails/index.md
+++ b/public/content/translations/it/developers/tutorials/erc20-with-safety-rails/index.md
@@ -1,61 +1,60 @@
---
-title: ERC-20 con barriere di sicurezza
-description: Come aiutare le persone a evitare errori banali
+title: ERC-20 con misure di sicurezza
+description: Come aiutare le persone a evitare errori sciocchi
author: Ori Pomerantz
lang: it
-tags:
- - "erc-20"
+tags: ["erc-20"]
skill: beginner
-breadcrumb: "ERC-20 sicuro"
+breadcrumb: Sicurezza ERC-20
published: 2022-08-15
---
## Introduzione {#introduction}
-Una delle cose fantastiche su Ethereum è che non esiste un'autorità centrale che possa modificare o annullare le tue transazioni. Uno dei suoi grandi problemi è che non c'è un'autorità centrale con il potere di annullare gli errori o le transazioni illecite degli utenti. In questo articolo imparerai alcuni dei comuni errori che gli utenti commettono con i token [ERC-20](/developers/docs/standards/tokens/erc-20/), nonché come creare dei contratti ERC-20 che aiutano gli utenti a evitarli, o danno poteri a un'autorità centrale (ad esempio, congelare gli account).
+Una delle cose fantastiche di Ethereum è che non esiste un'autorità centrale in grado di modificare o annullare le tue transazioni. Uno dei grandi problemi di Ethereum è che non esiste un'autorità centrale con il potere di annullare gli errori degli utenti o le transazioni illecite. In questo articolo scoprirai alcuni degli errori comuni che gli utenti commettono con i token [ERC-20](/developers/docs/standards/tokens/erc-20/), oltre a come creare contratti intelligenti ERC-20 che aiutino gli utenti a evitare tali errori, o che conferiscano a un'autorità centrale un certo potere (ad esempio per congelare gli account).
-Nota che, mentre utilizzeremo il [contratto del token ERC-20 di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20), questo articolo non lo spiega nel dettaglio. Puoi trovare queste informazioni [qui](/developers/tutorials/erc20-annotated-code).
+Nota che, sebbene utilizzeremo il [contratto del token ERC-20 di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20), questo articolo non lo spiega in grande dettaglio. Puoi trovare queste informazioni [qui](/developers/tutorials/erc20-annotated-code).
-Se desideri visualizzare il codice sorgente completo:
+Se vuoi vedere il codice sorgente completo:
-1. Apri l'[IDE di Remix](https://remix.ethereum.org/).
-2. Clicca l'icona di clonazione di GitHub ().
-3. Clona la repository di GitHub `https://github.com/qbzzt/20220815-erc20-safety-rails`.
-4. Apri **contratti > erc20-safety-rails.sol**.
+1. Apri l'[IDE Remix](https://remix.ethereum.org/).
+2. Clicca sull'icona per clonare da github ().
+3. Clona il repository github `https://github.com/qbzzt/20220815-erc20-safety-rails`.
+4. Apri **contracts > erc20-safety-rails.sol**.
## Creare un contratto ERC-20 {#creating-an-erc-20-contract}
-Prima di poter aggiungere la funzionalità della barriera di sicurezza, ci occorre un contratto ERC-20. In questo articolo utilizzeremo [la procedura guidata dei contratti di OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/wizard). Aprila in un altro browser e segui queste istruzioni:
+Prima di poter aggiungere la funzionalità delle misure di sicurezza, abbiamo bisogno di un contratto ERC-20. In questo articolo utilizzeremo [il Wizard dei Contratti di OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/wizard). Aprilo in un altro browser e segui queste istruzioni:
1. Seleziona **ERC20**.
2. Inserisci queste impostazioni:
- | Parametro | Valore |
- | --------------- | ---------------- |
- | Nome | SafetyRailsToken |
- | Symbol | SAFE |
- | Premint | 1000 |
- | Caratteristiche | Nessuno |
- | Access Control | Ownable |
- | Upgradability | Nessuno |
+ | Parametro | Valore |
+ | -------------- | ---------------- |
+ | Nome | SafetyRailsToken |
+ | Simbolo | SAFE |
+ | Premint | 1000 |
+ | Funzionalità | Nessuna |
+ | Controllo degli accessi | Ownable |
+ | Aggiornabilità | Nessuna |
-3. Scorri in alto e clicca su **Apri su Remix** (per Remix) o su **Scarica** per utilizzare un ambiente differente. Supporrò che tu stia utilizzando Remix, altrimenti, effettua le modifiche appropriate.
-4. Ora, abbiamo un contratto ERC-20 pienamente funzionante. Puoi espandere `.deps` > `npm` per visualizzare il codice importato.
-5. Compila, distribuisci e gioca con il contratto, per scoprire che funziona come un contratto ERC-20. Se devi apprendere come funziona Remix, [utilizza questo tutorial](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth).
+3. Scorri verso l'alto e clicca su **Open in Remix** (per Remix) o **Download** per utilizzare un ambiente diverso. Darò per scontato che tu stia usando Remix; se usi qualcos'altro, apporta semplicemente le modifiche appropriate.
+4. Ora abbiamo un contratto ERC-20 completamente funzionante. Puoi espandere `.deps` > `npm` per vedere il codice importato.
+5. Compila, distribuisci e gioca con il contratto per vedere che funziona come un contratto ERC-20. Se hai bisogno di imparare a usare Remix, [usa questo tutorial](https://remix.ethereum.org/?#activate=udapp,solidity,LearnEth).
## Errori comuni {#common-mistakes}
### Gli errori {#the-mistakes}
-Gli utenti, talvolta, inviano dei token all'indirizzo errato. Anche se non possiamo leggere la loro mente per sapere cosa intendevano fare, ci sono due tipi di errore che capitano spesso e sono facili da rilevare:
+A volte gli utenti inviano token all'indirizzo sbagliato. Sebbene non possiamo leggere le loro menti per sapere cosa intendessero fare, ci sono due tipi di errori che si verificano spesso e sono facili da rilevare:
-1. Inviare i token all'indirizzo del contratto. Ad esempio, il [token OP di Optimism](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c) è riuscito ad accumulare [oltre 120.000](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000042#tokentxns) token OP in meno di due mesi. Questo rappresenta una significativa quantità di ricchezza che, presumibilmente, è semplicemente stata persa dalle persone.
+1. Inviare i token all'indirizzo del contratto stesso. Ad esempio, il [token OP di Optimism](https://optimism.mirror.xyz/qvd0WfuLKnePm1Gxb9dpGchPf5uDz5NSMEFdgirDS4c) è riuscito ad accumulare [oltre 120.000](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000042) token OP in meno di due mesi. Ciò rappresenta una quantità significativa di ricchezza che presumibilmente le persone hanno semplicemente perso.
-2. Inviare i token a un indirizzo vuoto, non corrispondente a un [conto posseduto esternamente](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) o a un [contratto intelligente](/developers/docs/smart-contracts). Sebbene non siano disponibili le statistiche su quanto spesso si verifichi, [un incidente potrebbe costare fino a 20.000.000 token](https://gov.optimism.io/t/message-to-optimism-community-from-wintermute/2595).
+2. Inviare i token a un indirizzo vuoto, uno che non corrisponde a un [account controllato esternamente](/developers/docs/accounts/#externally-owned-accounts-and-key-pairs) o a un [contratto intelligente](/developers/docs/smart-contracts). Sebbene non abbia statistiche su quanto spesso ciò accada, [un incidente potrebbe essere costato 20.000.000 di token](https://gov.optimism.io/t/message-to-optimism-community-from-wintermute/2595).
### Prevenire i trasferimenti {#preventing-transfers}
-Il contratto ERC-20 di OpenZeppelin include [un hook, `_beforeTokenTransfer`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368), chiamato prima del trasferimento di un token. Per impostazione predefinita, questo hook non fa nulla, ma possiamo allegarci la nostra funzionalità, come controlli che ripristinano la transazione se si verifica un problema.
+Il contratto ERC-20 di OpenZeppelin include [un hook, `_beforeTokenTransfer`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol#L364-L368), che viene chiamato prima che un token venga trasferito. Per impostazione predefinita, questo hook non fa nulla, ma possiamo agganciarvi le nostre funzionalità, come controlli che annullano l'operazione se c'è un problema.
Per utilizzare l'hook, aggiungi questa funzione dopo il costruttore:
@@ -68,42 +67,42 @@ Per utilizzare l'hook, aggiungi questa funzione dopo il costruttore:
}
```
-Alcune parti di questa funzione potrebbero essere nuove, se non hai familiarità con Solidity:
+Alcune parti di questa funzione potrebbero essere nuove se non hai molta familiarità con Solidity:
```solidity
internal virtual
```
-La parola chiave `virtual` signiica che appena abbiamo ereditato la funzionalità da `ERC20` e sovrascritto questa funzione, gli altri contratti possono ereditare da noi e sovrascriverla.
+La parola chiave `virtual` significa che, proprio come abbiamo ereditato la funzionalità da `ERC20` e sovrascritto questa funzione, altri contratti possono ereditare da noi e sovrascrivere questa funzione.
```solidity
override(ERC20)
```
-Dobbiamo specificare esplicitamente che stiamo [sovrascrivendo](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding) la definizione del token ERC20 di `_beforeTokenTransfer`. In generale, le definizioni esplicite sono molto migliori, dal punto di vista della sicurezza, rispetto a quelle implicite: non puoi dimenticare di aver fatto qualcosa se ce l'hai davanti. Questo è anche il motivo per cui dobbiamo specificare il `_beforeTokenTransfer` di quale superclasse stiamo sovrascrivendo.
+Dobbiamo specificare esplicitamente che stiamo [sovrascrivendo](https://docs.soliditylang.org/en/v0.8.15/contracts.html#function-overriding) la definizione del token ERC20 di `_beforeTokenTransfer`. In generale, le definizioni esplicite sono molto migliori, dal punto di vista della sicurezza, rispetto a quelle implicite: non puoi dimenticare di aver fatto qualcosa se è proprio di fronte a te. Questo è anche il motivo per cui dobbiamo specificare quale `_beforeTokenTransfer` della superclasse stiamo sovrascrivendo.
```solidity
super._beforeTokenTransfer(from, to, amount);
```
-Questa riga chiama la funzione `_beforeTokenTransfer` del contratto o dei contratti da cui abbiamo ereditato o che la contengono. In qusto caso, è solo `ERC20`, `Ownable` non contiene questo hook. Sebbene correntemente `ERC20._beforeTokenTransfer` non faccia nulla, lo chiamiamo nel caso in cui la funzionalità sia aggiunta in futuro (e, quindi, decidiamo di ridistribuire il contratto, poiché i contratti non cambiano dopo la distribuzione).
+Questa riga chiama la funzione `_beforeTokenTransfer` del contratto o dei contratti da cui abbiamo ereditato che ce l'hanno. In questo caso, è solo `ERC20`, `Ownable` non ha questo hook. Anche se attualmente `ERC20._beforeTokenTransfer` non fa nulla, lo chiamiamo nel caso in cui vengano aggiunte funzionalità in futuro (e decidessimo quindi di ridistribuire il contratto, perché i contratti non cambiano dopo la distribuzione).
-### Codifica dei requisiti {#coding-the-requirements}
+### Codificare i requisiti {#coding-the-requirements}
Vogliamo aggiungere questi requisiti alla funzione:
-- L'indirizzo `to` non può equivalere ad `address(this)`, l'indirizzo dello stesso contratto ERC-20.
-- L'indirizzo `to` non può essere vuoto, dev'essere:
- - Account posseduti esternamente (EOA). Non possiamo verificare se un indirizzo è un EOA direttamente, ma possiamo verificare il saldo di ETH di un indirizzo. Gli EOA contengono quasi sempre un saldo, anche se non sono più utilizzati; è difficile ripulirli fino all'ultimo wei.
- - Un contratto intelligente. Testare se un indirizzo è un contratto intelligente è più difficile. Esiste un codice operativo che controlla la lunghezza del codice esterno, chiamato [`EXTCODESIZE`](https://www.evm.codes/#3b), ma non è direttamente disponibile in Solidity. Dobbiamo utilizzare [Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html), un assemblaggio dell'EVM, per farlo. Esistono altri valori che potremmo utilizzare da Solidity ([`.code` e `.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types)), ma costano di più.
+- L'indirizzo `to` non può essere uguale a `address(this)`, l'indirizzo del contratto ERC-20 stesso.
+- L'indirizzo `to` non può essere vuoto, deve essere uno dei seguenti:
+ - Un account controllato esternamente (EOA). Non possiamo verificare direttamente se un indirizzo è un EOA, ma possiamo controllare il saldo in ETH di un indirizzo. Gli EOA hanno quasi sempre un saldo, anche se non vengono più utilizzati: è difficile svuotarli fino all'ultimo wei.
+ - Un contratto intelligente. Verificare se un indirizzo è un contratto intelligente è un po' più difficile. Esiste un opcode che controlla la lunghezza del codice esterno, chiamato [`EXTCODESIZE`](https://www.evm.codes/#3b), ma non è disponibile direttamente in Solidity. Dobbiamo usare [Yul](https://docs.soliditylang.org/en/v0.8.15/yul.html), che è l'assembly dell'EVM, per farlo. Ci sono altri valori che potremmo usare da Solidity ([`.code` e `.codehash`](https://docs.soliditylang.org/en/v0.8.15/units-and-global-variables.html#members-of-address-types)), ma costano di più.
-Analizziamo il codice, riga per riga:
+Esaminiamo il nuovo codice riga per riga:
```solidity
require(to != address(this), "Can't send tokens to the contract address");
```
-Questo è il primo requisito, controlla che `to` `this(address)` non siano la stessa cosa.
+Questo è il primo requisito, verificare che `to` e `this(address)` non siano la stessa cosa.
```solidity
bool isToContract;
@@ -112,81 +111,81 @@ Questo è il primo requisito, controlla che `to` `this(address)` non siano la st
}
```
-È così che controlliamo se un indirizzo è un contratto. Non possiamo ricevere direttamente il risultato da Yul, quindi, invece, definiamo una variabile che detenga il risultato (`isToContract` in questo caso). Yul funziona così: ogni codice operativo è considerato come una funzione. Quindi, prima chiamiamo [`EXTCODESIZE`](https://www.evm.codes/#3b) per ottenere le dimensioni del contratto, quindi utilizziamo [`GT`](https://www.evm.codes/#11) per verificare che non sia zero (stiamo avendo a che fare con interi non firmati, quindi, ovviamente, non possono essere negativi). Poi, dobbiamo scrivere il risultato in `isToContract`.
+Ecco come verifichiamo se un indirizzo è un contratto. Non possiamo ricevere l'output direttamente da Yul, quindi definiamo invece una variabile per contenere il risultato (`isToContract` in questo caso). Il modo in cui funziona Yul è che ogni opcode è considerato una funzione. Quindi prima chiamiamo [`EXTCODESIZE`](https://www.evm.codes/#3b) per ottenere la dimensione del contratto, e poi usiamo [`GT`](https://www.evm.codes/#11) per verificare che non sia zero (abbiamo a che fare con interi senza segno, quindi ovviamente non può essere negativo). Scriviamo quindi il risultato in `isToContract`.
```solidity
require(to.balance != 0 || isToContract, "Can't send tokens to an empty address");
```
-E, infine, abbiamo il controllo effettivo per gli indirizzi vuoti.
+E infine, abbiamo il controllo effettivo per gli indirizzi vuoti.
## Accesso amministrativo {#admin-access}
-Talvolta è utile avere un amministratore che possa annullare gli errori. Per ridurre il potenziale di abusi, questo può essere una [multifirma](https://blog.logrocket.com/security-choices-multi-signature-wallets/), quindi più persone devono approvare un'azione. In questo articolo abbiamo due funzionalità amministrative:
+A volte è utile avere un amministratore che possa annullare gli errori. Per ridurre il potenziale di abuso, questo amministratore può essere un [multifirma](https://blog.logrocket.com/security-choices-multi-signature-wallets/) in modo che più persone debbano concordare su un'azione. In questo articolo avremo due funzionalità amministrative:
-1. Congelamento e scongelamento degli account. Utile, ad esempio, quando un account potrebbe essere compromesso.
-2. Pulizia della risorsa.
+1. Congelare e scongelare gli account. Questo può essere utile, ad esempio, quando un account potrebbe essere compromesso.
+2. Pulizia degli asset.
- Talvolta, i truffatori inviano token fraudolenti al contratto del token reale, per ottenere legittimità. Ad esempio, [vedi qui](https://optimistic.etherscan.io/token/0x2348b1a1228ddcd2db668c3d30207c3e1852fbbe?a=0x4200000000000000000000000000000000000042). Il contratto ERC-20 legittimo è [0x4200....0042](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000042). La truffa che pretende di essere tale contratto è [0x234....bbe](https://optimistic.etherscan.io/address/0x2348b1a1228ddcd2db668c3d30207c3e1852fbbe).
+ A volte i truffatori inviano token fraudolenti al contratto del token reale per ottenere legittimità. Ad esempio, [vedi qui](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe?tab=holders). Il contratto ERC-20 legittimo è [0x4200....0042](https://optimism.blockscout.com/token/0x4200000000000000000000000000000000000042). La truffa che finge di esserlo è [0x234....bbe](https://optimism.blockscout.com/token/0x2348B1a1228DDCd2dB668c3d30207c3E1852fBbe).
- Inoltre, è possibile che le persone inviino token ERC-20 legittimi al nostro contratto per errore, un altro motivo per cui vogliamo avere un modo per farli uscire.
+ È anche possibile che le persone inviino per errore token ERC-20 legittimi al nostro contratto, il che è un altro motivo per voler avere un modo per tirarli fuori.
-OpenZeppelin fornisce due meccanismi per consentire l'accesso amministrativo:
+OpenZeppelin fornisce due meccanismi per abilitare l'accesso amministrativo:
-- I contratti [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) hanno un singolo proprietario. Le funzioni aventi il [modificatore](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `onlyOwner` possono essere chiamate soltanto dal proprietario. I proprietari possono trasferire la proprietà a qualcun altro o rinunciarvi completamente. I diritti di tutti gli altri account sono solitamente identici.
-- I contratti [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control) hanno il [controllo d'accesso basato sul ruolo (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control).
+- I contratti [`Ownable`](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) hanno un singolo proprietario. Le funzioni che hanno il [modificatore](https://www.tutorialspoint.com/solidity/solidity_function_modifiers.htm) `onlyOwner` possono essere chiamate solo da quel proprietario. I proprietari possono trasferire la proprietà a qualcun altro o rinunciarvi completamente. I diritti di tutti gli altri account sono in genere identici.
+- I contratti [`AccessControl`](https://docs.openzeppelin.com/contracts/5.x/access-control#role-based-access-control) hanno il [controllo degli accessi basato sui ruoli (RBAC)](https://en.wikipedia.org/wiki/Role-based_access_control).
-Per semplicità, in questo articolo utilizzeremo `Ownable`.
+Per motivi di semplicità, in questo articolo utilizziamo `Ownable`.
### Congelare e scongelare i contratti {#freezing-and-thawing-contracts}
Congelare e scongelare i contratti richiede diverse modifiche:
-- Una [mappatura](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) dagli indirizzi a [booleani](https://en.wikipedia.org/wiki/Boolean_data_type) per tenere traccia di quali indirizzi siano congelati. Tutti i valori sono inizialmente pari a zero, che per i valori booleani è interpretato come falso. Questo è ciò che vogliamo perché gli account non sono congelati per impostazione predefinita.
+- Una [mappatura](https://www.tutorialspoint.com/solidity/solidity_mappings.htm) dagli indirizzi ai [booleani](https://en.wikipedia.org/wiki/Boolean_data_type) per tenere traccia di quali indirizzi sono congelati. Tutti i valori sono inizialmente zero, che per i valori booleani viene interpretato come falso. Questo è ciò che vogliamo perché per impostazione predefinita gli account non sono congelati.
```solidity
mapping(address => bool) public frozenAccounts;
- ```
+```
-- [Eventi](https://www.tutorialspoint.com/solidity/solidity_events.htm) per informare chiunque sia interessato quando un account è congelato o scongelato. Tecnicamente parlando, gli eventi non sono necessari per tali azioni, ma aiutano il codice esterno alla catena a essere capace di ascoltare tali eventi e sapere che sta succedendo. È considerata buona pratica, per un contratto intelligente, di emetterli quando si verifica qualcosa che potrebbe essere rilevante per qualcuno.
+- [Eventi](https://www.tutorialspoint.com/solidity/solidity_events.htm) per informare chiunque sia interessato quando un account viene congelato o scongelato. Tecnicamente parlando, gli eventi non sono richiesti per queste azioni, ma aiutano il codice fuori catena a poter ascoltare questi eventi e sapere cosa sta succedendo. È considerata buona educazione per un contratto intelligente emetterli quando accade qualcosa che potrebbe essere rilevante per qualcun altro.
- Gli eventi sono indicizzati, quindi sarà possibile cercarli tutte le volte che un account è stato congelato o scongelato.
+ Gli eventi sono indicizzati, quindi sarà possibile cercare tutte le volte in cui un account è stato congelato o scongelato.
```solidity
- // When accounts are frozen or unfrozen
+ // Quando gli account vengono congelati o scongelati
event AccountFrozen(address indexed _addr);
event AccountThawed(address indexed _addr);
- ```
+```
-- Funzioni per congelare e scongelare gli account. Queste due funzioni sono quasi identiche, quindi analizzeremo soltanto la funzione di congelamento.
+- Funzioni per congelare e scongelare gli account. Queste due funzioni sono quasi identiche, quindi esamineremo solo la funzione di congelamento.
```solidity
function freezeAccount(address addr)
public
onlyOwner
- ```
+```
- Le funzioni contrassegnate come [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm), possono essere chiamate da altri contratti intelligenti o direttamente da una transazione.
+ Le funzioni contrassegnate come [`public`](https://www.tutorialspoint.com/solidity/solidity_contracts.htm) possono essere chiamate da altri contratti intelligenti o direttamente da una transazione.
```solidity
{
require(!frozenAccounts[addr], "Account already frozen");
frozenAccounts[addr] = true;
emit AccountFrozen(addr);
- } // freezeAccount
- ```
+ } // freezeAccount
+```
- Se l'account è già congelato, si ripristina. Altrimenti, lo congela ed emette (`emit`) un evento.
+ Se l'account è già congelato, esegui un revert. Altrimenti, congelalo ed emetti (`emit`) un evento.
-- Modificare `_beforeTokenTransfer` per impedire che il denaro sia spostato da un account congelato. Nota che il denaro è ancora trasferibile in un account congelato.
+- Modifica `_beforeTokenTransfer` per impedire che il denaro venga spostato da un account congelato. Nota che il denaro può ancora essere trasferito nell'account congelato.
```solidity
require(!frozenAccounts[from], "The account is frozen");
- ```
+```
-### Pulizia della risorsa {#asset-cleanup}
+### Pulizia degli asset {#asset-cleanup}
-Per rilasciare i token ERC-20 detenuti da questo contratto, dobbiamo chiamare una funzione sul contratto del token cui aappartengono, [`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer) o [`approve`](https://eips.ethereum.org/EIPS/eip-20#approve). Non ha senso, in questo caso, sprecare gas sulle indennità, potremmo anche trasferirle direttamente.
+Per rilasciare i token ERC-20 detenuti da questo contratto dobbiamo chiamare una funzione sul contratto del token a cui appartengono, ovvero [`transfer`](https://eips.ethereum.org/EIPS/eip-20#transfer) o [`approve`](https://eips.ethereum.org/EIPS/eip-20#approve). Non ha senso sprecare gas in questo caso per le allowance, tanto vale trasferire direttamente.
```solidity
function cleanupERC20(
@@ -199,7 +198,7 @@ Per rilasciare i token ERC-20 detenuti da questo contratto, dobbiamo chiamare un
IERC20 token = IERC20(erc20);
```
-Questa è la sintassi per creare un oggetto per un contratto quando riceviamo l'indirizzo. Possiamo farlo perché abbiamo la definizione per i token ERC20 come parte del codice sorgente (vedi riga 4) e tale file include [la definizione per IERC20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol), l'interfaccia per un contratto ERC-20 di OpenZeppelin.
+Questa è la sintassi per creare un oggetto per un contratto quando riceviamo l'indirizzo. Possiamo farlo perché abbiamo la definizione per i token ERC20 come parte del codice sorgente (vedi riga 4), e quel file include [la definizione per IERC20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol), l'interfaccia per un contratto ERC-20 di OpenZeppelin.
```solidity
uint balance = token.balanceOf(address(this));
@@ -207,8 +206,10 @@ Questa è la sintassi per creare un oggetto per un contratto quando riceviamo l'
}
```
-Questa è una funzione di pulizia, quindi, presumibilmente, non vogliamo lasciare alcun token. Invece di ottenere manualmente il saldo dall'utente, potremmo automatizzare anche questo processo.
+Questa è una funzione di pulizia, quindi presumibilmente non vogliamo lasciare alcun token. Invece di ottenere il saldo dall'utente manualmente, tanto vale automatizzare il processo.
+
+## Conclusione {#conclusion}
-## Conclusioni {#conclusion}
+Questa non è una soluzione perfetta: non esiste una soluzione perfetta per il problema "l'utente ha commesso un errore". Tuttavia, l'utilizzo di questo tipo di controlli può almeno prevenire alcuni errori. La capacità di congelare gli account, sebbene pericolosa, può essere utilizzata per limitare i danni di determinati attacchi informatici negando all'hacker i fondi rubati.
-Questa non è una soluzione perfetta, non esiste una soluzione perfetta al problema "un utente ha commesso un errore". Tuttavia, utilizzando questi tipi di controlli, alcuni errori possono almeno essere prevenuti. L'abilità di congelare gli account, sebbene pericolosa, è utilizzabile per limitare i danni di certi attacchi, negando all'hacker i fondi rubati.
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/ethereum-for-web2-auth/index.md b/public/content/translations/it/developers/tutorials/ethereum-for-web2-auth/index.md
new file mode 100644
index 00000000000..70a7434954a
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/ethereum-for-web2-auth/index.md
@@ -0,0 +1,888 @@
+---
+title: Utilizzare Ethereum per l'autenticazione web2
+description: "Dopo aver letto questo tutorial, uno sviluppatore sarà in grado di integrare l'accesso di Ethereum (web3) con l'accesso SAML, uno standard utilizzato nel web2 per fornire il single sign-on e altri servizi correlati. Questo consente di autenticare l'accesso alle risorse web2 tramite le firme di Ethereum, con gli attributi dell'utente provenienti dalle attestazioni."
+author: Ori Pomerantz
+tags: ["web2", "autenticazione", "eas"]
+skill: beginner
+breadcrumb: Ethereum per l'autenticazione web2
+lang: it
+published: 2025-04-30
+---
+
+## Introduzione
+
+[SAML](https://www.onelogin.com/learn/saml) è uno standard utilizzato nel web2 per consentire a un [provider di identità (IdP)](https://en.wikipedia.org/wiki/Identity_provider#SAML_identity_provider) di fornire informazioni sull'utente ai [provider di servizi (SP)](https://en.wikipedia.org/wiki/Service_provider_(SAML)).
+
+In questo tutorial imparerai come integrare le firme di Ethereum con SAML per consentire agli utenti di utilizzare i propri portafogli Ethereum per autenticarsi ai servizi web2 che non supportano ancora nativamente Ethereum.
+
+Nota che questo tutorial è scritto per due tipi di pubblico distinti:
+
+- Utenti di Ethereum che comprendono Ethereum e hanno bisogno di imparare SAML
+- Utenti del web2 che comprendono SAML e l'autenticazione web2 e hanno bisogno di imparare Ethereum
+
+Di conseguenza, conterrà molto materiale introduttivo che potresti già conoscere. Sentiti libero di saltarlo.
+
+### SAML per gli utenti di Ethereum
+
+SAML è un protocollo centralizzato. Un provider di servizi (SP) accetta asserzioni (come "questo è il mio utente John, dovrebbe avere i permessi per fare A, B e C") da un provider di identità (IdP) solo se ha una relazione di fiducia preesistente con esso, o con l'[autorità di certificazione](https://www.ssl.com/article/what-is-a-certificate-authority-ca/) che ha firmato il certificato di quell'IdP.
+
+Ad esempio, l'SP può essere un'agenzia di viaggi che fornisce servizi di viaggio alle aziende, e l'IdP può essere il sito web interno di un'azienda. Quando i dipendenti devono prenotare un viaggio di lavoro, l'agenzia di viaggi li invia per l'autenticazione da parte dell'azienda prima di consentire loro di prenotare effettivamente il viaggio.
+
+
+
+Questo è il modo in cui le tre entità, il browser, l'SP e l'IdP, negoziano l'accesso. L'SP non ha bisogno di sapere nulla in anticipo sull'utente che utilizza il browser, deve solo fidarsi dell'IdP.
+
+### Ethereum per gli utenti di SAML
+
+Ethereum è un sistema decentralizzato.
+
+
+
+Gli utenti hanno una chiave privata (tipicamente conservata in un'estensione del browser). Dalla chiave privata è possibile derivare una chiave pubblica, e da questa un indirizzo di 20 byte. Quando gli utenti devono accedere a un sistema, viene loro richiesto di firmare un messaggio con un nonce (un valore monouso). Il server può verificare che la firma sia stata creata da quell'indirizzo.
+
+
+
+La firma verifica solo l'indirizzo di Ethereum. Per ottenere altri attributi dell'utente, in genere si utilizzano le [attestazioni](https://attest.org/). Un'attestazione ha tipicamente questi campi:
+
+- **Attestatore**, l'indirizzo che ha effettuato l'attestazione
+- **Destinatario**, l'indirizzo a cui si applica l'attestazione
+- **Dati**, i dati attestati, come nome, permessi, ecc.
+- **Schema**, l'ID dello schema utilizzato per interpretare i dati.
+
+A causa della natura decentralizzata di Ethereum, qualsiasi utente può effettuare attestazioni. L'identità dell'attestatore è importante per identificare quali attestazioni consideriamo affidabili.
+
+## Configurazione
+
+Il primo passo è far comunicare tra loro un SP SAML e un IdP SAML.
+
+1. Scarica il software. Il software di esempio per questo articolo è [su github](https://github.com/qbzzt/250420-saml-ethereum). Le diverse fasi sono memorizzate in rami diversi, per questa fase ti serve `saml-only`
+
+ ```sh
+ git clone https://github.com/qbzzt/250420-saml-ethereum -b saml-only
+ cd 250420-saml-ethereum
+ pnpm install
+```
+
+2. Crea chiavi con certificati autofirmati. Questo significa che la chiave è la propria autorità di certificazione e deve essere importata manualmente nel provider di servizi. Consulta [la documentazione di OpenSSL](https://docs.openssl.org/master/man1/openssl-req/) per maggiori informazioni.
+
+ ```sh
+ mkdir keys
+ cd keys
+ openssl req -new -x509 -days 365 -nodes -sha256 -out saml-sp.crt -keyout saml-sp.pem -subj /CN=sp/
+ openssl req -new -x509 -days 365 -nodes -sha256 -out saml-idp.crt -keyout saml-idp.pem -subj /CN=idp/
+ cd ..
+```
+
+3. Avvia i server (sia SP che IdP)
+
+ ```sh
+ pnpm start
+```
+
+4. Naviga verso l'SP all'URL [http://localhost:3000/](http://localhost:3000/) e fai clic sul pulsante per essere reindirizzato all'IdP (porta 3001).
+
+5. Fornisci all'IdP il tuo indirizzo e-mail e fai clic su **Login to the service provider**. Vedrai che verrai reindirizzato di nuovo al provider di servizi (porta 3000) e che ti riconoscerà tramite il tuo indirizzo e-mail.
+
+### Spiegazione dettagliata
+
+Questo è ciò che accade, passo dopo passo:
+
+
+
+#### src/config.mts
+
+Questo file contiene la configurazione sia per il Provider di Identità che per il Provider di Servizi. Normalmente queste due sarebbero entità diverse, ma qui possiamo condividere il codice per semplicità.
+
+```typescript
+const fs = await import("fs")
+
+const protocol="http"
+```
+
+Per ora stiamo solo testando, quindi va bene usare HTTP.
+
+```typescript
+export const spCert = fs.readFileSync("keys/saml-sp.crt").toString()
+export const idpCert = fs.readFileSync("keys/saml-idp.crt").toString()
+```
+
+Leggi le chiavi pubbliche, che sono normalmente disponibili per entrambi i componenti (e considerate affidabili direttamente, o firmate da un'autorità di certificazione fidata).
+
+```typescript
+export const spPort = 3000
+export const spHostname = "localhost"
+export const spDir = "sp"
+
+export const idpPort = 3001
+export const idpHostname = "localhost"
+export const idpDir = "idp"
+
+export const spUrl = `${protocol}://${spHostname}:${spPort}/${spDir}`
+export const idpUrl = `${protocol}://${idpHostname}:${idpPort}/${idpDir}`
+```
+
+Gli URL per entrambi i componenti.
+
+```typescript
+export const spPublicData = {
+```
+
+I dati pubblici per il provider di servizi.
+
+```typescript
+ entityID: `${spUrl}/metadata`,
+```
+
+Per convenzione, in SAML l'`entityID` è l'URL in cui sono disponibili i metadati dell'entità. Questi metadati corrispondono ai dati pubblici qui presenti, tranne per il fatto che sono in formato XML.
+
+```typescript
+ wantAssertionsSigned: true,
+ authnRequestsSigned: false,
+ signingCert: spCert,
+ allowCreate: true,
+ assertionConsumerService: [{
+ Binding: 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
+ Location: `${spUrl}/assertion`,
+ }]
+ }
+```
+
+La definizione più importante per i nostri scopi è l'`assertionConsumerServer`. Significa che per asserire qualcosa (ad esempio, "l'utente che ti invia queste informazioni è somebody@example.com") al provider di servizi dobbiamo usare [HTTP POST](https://www.w3schools.com/tags/ref_httpmethods.asp) all'URL `http://localhost:3000/sp/assertion`.
+
+```typescript
+export const idpPublicData = {
+ entityID: `${idpUrl}/metadata`,
+ signingCert: idpCert,
+ wantAuthnRequestsSigned: false,
+ singleSignOnService: [{
+ Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
+ Location: `${idpUrl}/login`
+ }],
+ singleLogoutService: [{
+ Binding: "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST",
+ Location: `${idpUrl}/logout`
+ }],
+ }
+```
+
+I dati pubblici per il provider di identità sono simili. Specificano che per far accedere un utente si effettua un POST a `http://localhost:3001/idp/login` e per disconnettere un utente si effettua un POST a `http://localhost:3001/idp/logout`.
+
+#### src/sp.mts
+
+Questo è il codice che implementa un provider di servizi.
+
+```typescript
+import * as config from "./config.mts"
+const fs = await import("fs")
+const saml = await import("samlify")
+```
+
+Usiamo la libreria [`samlify`](https://www.npmjs.com/package/samlify) per implementare SAML.
+
+```typescript
+import * as validator from "@authenio/samlify-node-xmllint"
+saml.setSchemaValidator(validator)
+```
+
+La libreria `samlify` si aspetta di avere un pacchetto che convalidi che l'XML sia corretto, firmato con la chiave pubblica prevista, ecc. Usiamo [`@authenio/samlify-node-xmllint`](https://www.npmjs.com/package/@authenio/samlify-node-xmllint) per questo scopo.
+
+```typescript
+const express = (await import("express")).default
+const spRouter = express.Router()
+const app = express()
+```
+
+Un [`Router`](https://expressjs.com/en/5x/api.html#router) di [`express`](https://expressjs.com/) è un "mini sito web" che può essere montato all'interno di un sito web. In questo caso, lo usiamo per raggruppare tutte le definizioni del provider di servizi.
+
+```typescript
+const spPrivateKey = fs.readFileSync("keys/saml-sp.pem").toString()
+
+const sp = saml.ServiceProvider({
+ privateKey: spPrivateKey,
+ ...config.spPublicData
+})
+```
+
+La rappresentazione che il provider di servizi ha di se stesso è costituita da tutti i dati pubblici e dalla chiave privata che utilizza per firmare le informazioni.
+
+```typescript
+const idp = saml.IdentityProvider(config.idpPublicData);
+```
+
+I dati pubblici contengono tutto ciò che il provider di servizi deve sapere sul provider di identità.
+
+```typescript
+spRouter.get(`/metadata`,
+ (req, res) => res.header("Content-Type", "text/xml").send(sp.getMetadata())
+)
+```
+
+Per consentire l'interoperabilità con altri componenti SAML, i provider di servizi e di identità dovrebbero avere i loro dati pubblici (chiamati metadati) disponibili in formato XML in `/metadata`.
+
+```typescript
+spRouter.post(`/assertion`,
+```
+
+Questa è la pagina a cui accede il browser per identificarsi. L'asserzione include l'identificatore dell'utente (qui usiamo l'indirizzo e-mail) e può includere attributi aggiuntivi. Questo è il gestore per il passaggio 7 nel diagramma di sequenza sopra.
+
+```typescript
+ async (req, res) => {
+ // console.log(`Risposta SAML:\n${Buffer.from(req.body.SAMLResponse, 'base64').toString('utf-8')}`)
+```
+
+Puoi usare il comando commentato per vedere i dati XML forniti nell'asserzione. È [codificato in base64](https://en.wikipedia.org/wiki/Base64).
+
+```typescript
+ try {
+ const loginResponse = await sp.parseLoginResponse(idp, 'post', req);
+```
+
+Analizza la richiesta di accesso dal server di identità.
+
+```typescript
+ res.send(`
+
+
+ Hello ${loginResponse.extract.nameID}
+
+
+ `)
+ res.send();
+```
+
+Invia una risposta HTML, solo per mostrare all'utente che abbiamo ricevuto l'accesso.
+
+```typescript
+ } catch (err) {
+ console.error('Error processing SAML response:', err);
+ res.status(400).send('SAML authentication failed');
+ }
+ }
+)
+```
+
+Informa l'utente in caso di fallimento.
+
+```typescript
+spRouter.get('/login',
+```
+
+Crea una richiesta di accesso quando il browser tenta di ottenere questa pagina. Questo è il gestore per il passaggio 1 nel diagramma di sequenza sopra.
+
+```typescript
+ async (req, res) => {
+ const loginRequest = await sp.createLoginRequest(idp, "post")
+```
+
+Ottieni le informazioni per inviare una richiesta di accesso.
+
+```typescript
+ res.send(`
+
+
+
+```
+
+Questa pagina invia il modulo (vedi sotto) automaticamente. In questo modo l'utente non deve fare nulla per essere reindirizzato. Questo è il passaggio 2 nel diagramma di sequenza sopra.
+
+```typescript
+
+
+
+ `)
+ }
+)
+
+app.use(express.urlencoded({extended: true}))
+```
+
+[Questo middleware](https://expressjs.com/en/5x/api.html#express.urlencoded) legge il corpo della [richiesta HTTP](https://www.tutorialspoint.com/http/http_requests.htm). Per impostazione predefinita express lo ignora, perché la maggior parte delle richieste non lo richiede. Ne abbiamo bisogno perché POST utilizza il corpo.
+
+```typescript
+app.use(`/${config.spDir}`, spRouter)
+```
+
+Monta il router nella directory del provider di servizi (`/sp`).
+
+```typescript
+app.get("/", (req, res) => {
+ res.send(`
+
+
+
+
+
+ `)
+})
+```
+
+Se un browser tenta di ottenere la directory principale, forniscigli un link alla pagina di accesso.
+
+```typescript
+app.listen(config.spPort, () => {
+ console.log(`service provider is running on http://${config.spHostname}:${config.spPort}`)
+})
+```
+
+Ascolta la `spPort` con questa applicazione express.
+
+#### src/idp.mts
+
+Questo è il provider di identità. È molto simile al provider di servizi, le spiegazioni di seguito riguardano le parti che sono diverse.
+
+```typescript
+const xmlParser = new (await import("fast-xml-parser")).XMLParser(
+ {
+ ignoreAttributes: false, // Preserva gli attributi
+ attributeNamePrefix: "@_", // Prefisso per gli attributi
+ }
+)
+```
+
+Dobbiamo leggere e comprendere la richiesta XML che riceviamo dal provider di servizi.
+
+```typescript
+const getLoginPage = requestId => `
+```
+
+Questa funzione crea la pagina con il modulo inviato automaticamente che viene restituita nel passaggio 4 del diagramma di sequenza sopra.
+
+```typescript
+
+
+ Login page
+
+
+ Login page
+
+
+
+
+const idpRouter = express.Router()
+
+idpRouter.post("/loginSubmitted", async (req, res) => {
+ const loginResponse = await idp.createLoginResponse(
+```
+
+Questo è il gestore per il passaggio 5 del diagramma di sequenza sopra. [`idp.createLoginResponse`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L73-L125) crea la risposta di accesso.
+
+```typescript
+ sp,
+ {
+ authnContextClassRef: 'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport',
+ audience: sp.entityID,
+```
+
+Il pubblico è il provider di servizi.
+
+```typescript
+ extract: {
+ request: {
+ id: req.body.requestId
+ }
+ },
+```
+
+Informazioni estratte dalla richiesta. L'unico parametro che ci interessa nella richiesta è il requestId, che consente al provider di servizi di far corrispondere le richieste e le relative risposte.
+
+```typescript
+ signingKey: { privateKey: idpPrivateKey, publicKey: config.idpCert } // Assicura la firma
+```
+
+Abbiamo bisogno di `signingKey` per avere i dati per firmare la risposta. Il provider di servizi non si fida delle richieste non firmate.
+
+```typescript
+ },
+ "post",
+ {
+ email: req.body.email
+```
+
+Questo è il campo con le informazioni sull'utente che inviamo di nuovo al provider di servizi.
+
+```typescript
+ }
+ );
+
+ res.send(`
+
+
+
+
+
+
+
+ `)
+})
+```
+
+Ancora una volta, usa un modulo inviato automaticamente. Questo è il passaggio 6 del diagramma di sequenza sopra.
+
+```typescript
+
+// Endpoint IdP per le richieste di login
+idpRouter.post(`/login`,
+```
+
+Questo è l'endpoint che riceve una richiesta di accesso dal provider di servizi. Questo è il gestore del passaggio 3 del diagramma di sequenza sopra.
+
+```typescript
+ async (req, res) => {
+ try {
+ // Soluzione alternativa perché non sono riuscito a far funzionare parseLoginRequest.
+ // const loginRequest = await idp.parseLoginRequest(sp, 'post', req)
+ const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8'))
+ res.send(getLoginPage(samlRequest["samlp:AuthnRequest"]["@_ID"]))
+```
+
+Dovremmo essere in grado di usare [`idp.parseLoginRequest`](https://github.com/tngan/samlify/blob/master/src/entity-idp.ts#L127-L144) per leggere l'ID della richiesta di autenticazione. Tuttavia, non sono riuscito a farlo funzionare e non valeva la pena dedicarci molto tempo, quindi uso semplicemente un [parser XML di uso generale](https://www.npmjs.com/package/fast-xml-parser). L'informazione di cui abbiamo bisogno è l'attributo `ID` all'interno del tag ``, che si trova al livello superiore dell'XML.
+
+## Utilizzare le firme di Ethereum
+
+Ora che possiamo inviare un'identità utente al provider di servizi, il passo successivo è ottenere l'identità utente in modo affidabile. Viem ci consente di chiedere semplicemente al portafoglio l'indirizzo dell'utente, ma questo significa chiedere le informazioni al browser. Non controlliamo il browser, quindi non possiamo fidarci automaticamente della risposta che ne otteniamo.
+
+Invece, l'IdP invierà al browser una stringa da firmare. Se il portafoglio nel browser firma questa stringa, significa che è davvero quell'indirizzo (cioè, conosce la chiave privata che corrisponde all'indirizzo).
+
+Per vederlo in azione, ferma l'IdP e l'SP esistenti ed esegui questi comandi:
+
+```sh
+git checkout eth-signatures
+pnpm install
+pnpm start
+```
+
+Quindi naviga [verso l'SP](http://localhost:3000) e segui le indicazioni.
+
+Nota che a questo punto non sappiamo come ottenere l'indirizzo e-mail dall'indirizzo di Ethereum, quindi riportiamo invece `@bad.email.address` all'SP.
+
+### Spiegazione dettagliata
+
+Le modifiche sono nei passaggi 4-5 del diagramma precedente.
+
+
+
+L'unico file che abbiamo modificato è `idp.mts`. Ecco le parti modificate.
+
+```typescript
+import { v4 as uuidv4 } from 'uuid'
+import { verifyMessage } from 'viem'
+```
+
+Abbiamo bisogno di queste due librerie aggiuntive. Usiamo [`uuid`](https://www.npmjs.com/package/uuid) per creare il valore del [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce). Il valore in sé non ha importanza, solo il fatto che venga utilizzato una sola volta.
+
+La libreria [`viem`](https://viem.sh/) ci consente di utilizzare le definizioni di Ethereum. Qui ne abbiamo bisogno per verificare che la firma sia effettivamente valida.
+
+```typescript
+const loginPrompt = "To access the service provider, sign this nonce: "
+```
+
+Il portafoglio chiede all'utente il permesso di firmare il messaggio. Un messaggio che è solo un nonce potrebbe confondere gli utenti, quindi includiamo questo prompt.
+
+```typescript
+// Mantieni qui i requestID
+let nonces = {}
+```
+
+Abbiamo bisogno delle informazioni della richiesta per potervi rispondere. Potremmo inviarle con la richiesta (passaggio 4) e riceverle indietro (passaggio 5). Tuttavia, non possiamo fidarci delle informazioni che otteniamo dal browser, che è sotto il controllo di un utente potenzialmente ostile. Quindi è meglio memorizzarle qui, con il nonce come chiave.
+
+Nota che lo stiamo facendo qui come variabile per motivi di semplicità. Tuttavia, questo presenta diversi svantaggi:
+
+- Siamo vulnerabili a un attacco denial of service. Un utente malintenzionato potrebbe tentare di accedere più volte, riempiendo la nostra memoria.
+- Se il processo IdP deve essere riavviato, perdiamo i valori esistenti.
+- Non possiamo bilanciare il carico su più processi, perché ognuno avrebbe la propria variabile.
+
+Su un sistema di produzione useremmo un database e implementeremmo un qualche tipo di meccanismo di scadenza.
+
+```typescript
+const getSignaturePage = requestId => {
+ const nonce = uuidv4()
+ nonces[nonce] = requestId
+```
+
+Crea un nonce e memorizza il `requestId` per un uso futuro.
+
+```typescript
+ return `
+
+
+
+
+
+ Please sign
+
+
+
+
+
+`
+}
+```
+
+Il resto è solo HTML standard.
+
+```typescript
+idpRouter.get("/signature/:nonce/:account/:signature", async (req, res) => {
+```
+
+Questo è il gestore per il passaggio 5 nel diagramma di sequenza.
+
+```typescript
+ const requestId = nonces[req.params.nonce]
+ if (requestId === undefined) {
+ res.send("Bad nonce")
+ return ;
+ }
+
+ nonces[req.params.nonce] = undefined
+```
+
+Ottieni l'ID della richiesta ed elimina il nonce da `nonces` per assicurarti che non possa essere riutilizzato.
+
+```typescript
+ try {
+```
+
+Poiché ci sono così tanti modi in cui la firma può essere non valida, racchiudiamo questo in un blocco `try ... catch` per intercettare eventuali errori generati.
+
+```typescript
+ const validSignature = await verifyMessage({
+ address: req.params.account,
+ message: `${loginPrompt}${req.params.nonce}`,
+ signature: req.params.signature
+ })
+```
+
+Usa [`verifyMessage`](https://viem.sh/docs/actions/public/verifyMessage#verifymessage) per implementare il passaggio 5.5 nel diagramma di sequenza.
+
+```typescript
+ if (!validSignature)
+ throw("Bad signature")
+ } catch (err) {
+ res.send("Error:" + err)
+ return ;
+ }
+```
+
+Il resto del gestore è equivalente a quello che abbiamo fatto in precedenza nel gestore `/loginSubmitted`, ad eccezione di una piccola modifica.
+
+```typescript
+ const loginResponse = await idp.createLoginResponse(
+ .
+ .
+ .
+ {
+ email: req.params.account + "@bad.email.address"
+ }
+ );
+```
+
+Non abbiamo l'indirizzo e-mail effettivo (lo otterremo nella prossima sezione), quindi per ora restituiamo l'indirizzo di Ethereum e lo contrassegniamo chiaramente come non un indirizzo e-mail.
+
+
+```typescript
+// Endpoint IdP per le richieste di login
+idpRouter.post(`/login`,
+ async (req, res) => {
+ try {
+ // Soluzione alternativa perché non sono riuscito a far funzionare parseLoginRequest.
+ // const loginRequest = await idp.parseLoginRequest(sp, 'post', req)
+ const samlRequest = xmlParser.parse(Buffer.from(req.body.SAMLRequest, 'base64').toString('utf-8'))
+ res.send(getSignaturePage(samlRequest["samlp:AuthnRequest"]["@_ID"]))
+ } catch (err) {
+ console.error('Error processing SAML response:', err);
+ res.status(400).send('SAML authentication failed');
+ }
+ }
+)
+```
+
+Invece di `getLoginPage`, ora usa `getSignaturePage` nel gestore del passaggio 3.
+
+## Ottenere l'indirizzo e-mail
+
+Il passo successivo è ottenere l'indirizzo e-mail, l'identificatore richiesto dal provider di servizi. Per farlo, usiamo l'[Ethereum Attestation Service (EAS)](https://attest.org/).
+
+Il modo più semplice per ottenere le attestazioni è usare l'[API GraphQL](https://docs.attest.org/docs/developer-tools/api). Usiamo questa query:
+
+```
+query GetAttestationsByRecipient {
+ attestations(
+ where: {
+ recipient: { equals: "${getAddress(ethAddr)}" }
+ schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" }
+ }
+ take: 1
+ ) {
+ data
+ id
+ attester
+ }
+}
+```
+
+Questo [`schemaId`](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977) include solo un indirizzo e-mail. Questa query richiede le attestazioni di questo schema. Il soggetto dell'attestazione è chiamato `recipient` (destinatario). È sempre un indirizzo di Ethereum.
+
+Attenzione: Il modo in cui stiamo ottenendo le attestazioni qui presenta due problemi di sicurezza.
+
+- Stiamo andando all'endpoint dell'API, `https://optimism.easscan.org/graphql`, che è un componente centralizzato. Possiamo ottenere l'attributo `id` e poi fare una ricerca on-chain per verificare che un'attestazione sia reale, ma l'endpoint dell'API può comunque censurare le attestazioni non informandoci su di esse.
+
+ Questo problema non è impossibile da risolvere, potremmo eseguire il nostro endpoint GraphQL e ottenere le attestazioni dai log della catena, ma questo è eccessivo per i nostri scopi.
+
+- Non guardiamo l'identità dell'attestatore. Chiunque può fornirci informazioni false. In un'implementazione nel mondo reale avremmo un insieme di attestatori fidati e guarderemmo solo le loro attestazioni.
+
+Per vederlo in azione, ferma l'IdP e l'SP esistenti ed esegui questi comandi:
+
+```sh
+git checkout email-address
+pnpm install
+pnpm start
+```
+
+Quindi fornisci il tuo indirizzo e-mail. Hai due modi per farlo:
+
+- Importa un portafoglio usando una chiave privata e usa la chiave privata di test `0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80`.
+
+- Aggiungi un'attestazione per il tuo indirizzo e-mail:
+
+ 1. Naviga verso [lo schema nell'esploratore di attestazioni](https://optimism.easscan.org/schema/view/0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977).
+
+ 2. Fai clic su **Attest with Schema**.
+
+ 3. Inserisci il tuo indirizzo di Ethereum come destinatario, il tuo indirizzo e-mail come email address e seleziona **Onchain**. Quindi fai clic su **Make Attestation**.
+
+ 4. Approva la transazione nel tuo portafoglio. Avrai bisogno di un po' di ETH sulla [Blockchain di Optimism](https://app.optimism.io/bridge/deposit) per pagare il gas.
+
+In ogni caso, dopo averlo fatto naviga verso [http://localhost:3000](http://localhost:3000) e segui le indicazioni. Se hai importato la chiave privata di test, l'e-mail che ricevi è `test_addr_0@example.com`. Se hai usato il tuo indirizzo, dovrebbe essere quello che hai attestato.
+
+### Spiegazione dettagliata
+
+
+
+I nuovi passaggi sono la comunicazione GraphQL, passaggi 5.6 e 5.7.
+
+Ancora una volta, ecco le parti modificate di `idp.mts`.
+
+```typescript
+import { GraphQLClient } from 'graphql-request'
+import { SchemaEncoder } from '@ethereum-attestation-service/eas-sdk'
+```
+
+Importa le librerie di cui abbiamo bisogno.
+
+```typescript
+const graphqlEndpointUrl = "https://optimism.easscan.org/graphql"
+```
+
+C'è [un endpoint separato per ogni blockchain](https://docs.attest.org/docs/developer-tools/api).
+
+```typescript
+const graphqlClient = new GraphQLClient(graphqlEndpointUrl, { fetch })
+```
+
+Crea un nuovo client `GraphQLClient` che possiamo usare per interrogare l'endpoint.
+
+```typescript
+const graphqlSchema = 'string emailAddress'
+const graphqlEncoder = new SchemaEncoder(graphqlSchema)
+```
+
+GraphQL ci fornisce solo un oggetto dati opaco con byte. Per capirlo abbiamo bisogno dello schema.
+
+```typescript
+const ethereumAddressToEmail = async ethAddr => {
+```
+
+Una funzione per passare da un indirizzo di Ethereum a un indirizzo e-mail.
+
+```typescript
+ const query = `
+ query GetAttestationsByRecipient {
+```
+
+Questa è una query GraphQL.
+
+```typescript
+ attestations(
+```
+
+Stiamo cercando attestazioni.
+
+```typescript
+ where: {
+ recipient: { equals: "${getAddress(ethAddr)}" }
+ schemaId: { equals: "0xfa2eff59a916e3cc3246f9aec5e0ca00874ae9d09e4678e5016006f07622f977" }
+ }
+```
+
+Le attestazioni che vogliamo sono quelle nel nostro schema, in cui il destinatario è `getAddress(ethAddr)`. La funzione [`getAddress`](https://viem.sh/docs/utilities/getAddress#getaddress) si assicura che il nostro indirizzo abbia il [checksum](https://github.com/ethereum/ercs/blob/master/ERCS/erc-55.md) corretto. Questo è necessario perché GraphQL fa distinzione tra maiuscole e minuscole. "0xBAD060A7", "0xBad060A7" e "0xbad060a7" sono valori diversi.
+
+```typescript
+ take: 1
+```
+
+Indipendentemente da quante attestazioni troviamo, vogliamo solo la prima.
+
+```typescript
+ ) {
+ data
+ id
+ attester
+ }
+ }`
+```
+
+I campi che vogliamo ricevere.
+
+- `attester`: L'indirizzo che ha inviato l'attestazione. Normalmente questo viene utilizzato per decidere se fidarsi o meno dell'attestazione.
+- `id`: L'ID dell'attestazione. Puoi usare questo valore per [leggere l'attestazione on-chain](https://optimism.blockscout.com/address/0x4200000000000000000000000000000000000021?tab=read_proxy&source_address=0x4E0275Ea5a89e7a3c1B58411379D1a0eDdc5b088#0xa3112a64) per verificare che le informazioni dalla query GraphQL siano corrette.
+- `data`: I dati dello schema (in questo caso, l'indirizzo e-mail).
+
+```typescript
+ const queryResult = await graphqlClient.request(query)
+
+ if (queryResult.attestations.length == 0)
+ return "no_address@available.is"
+```
+
+Se non c'è alcuna attestazione, restituisci un valore che è ovviamente errato, ma che apparirebbe valido al provider di servizi.
+
+```typescript
+ const attestationDataFields = graphqlEncoder.decodeData(queryResult.attestations[0].data)
+ return attestationDataFields[0].value.value
+}
+```
+
+Se c'è un valore, usa `decodeData` per decodificare i dati. Non abbiamo bisogno dei metadati che fornisce, solo del valore stesso.
+
+```typescript
+ const loginResponse = await idp.createLoginResponse(
+ sp,
+ {
+ .
+ .
+ .
+ },
+ "post",
+ {
+ email: await ethereumAddressToEmail(req.params.account)
+ }
+ );
+```
+
+Usa la nuova funzione per ottenere l'indirizzo e-mail.
+
+## E la decentralizzazione?
+
+In questa configurazione gli utenti non possono fingere di essere qualcuno che non sono, a patto di affidarci ad attestatori fidati per la mappatura dall'indirizzo di Ethereum all'indirizzo e-mail. Tuttavia, il nostro provider di identità è ancora un componente centralizzato. Chiunque abbia la chiave privata del provider di identità può inviare informazioni false al provider di servizi.
+
+Potrebbe esserci una soluzione che utilizza il [calcolo multiparte (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation). Spero di scriverne in un tutorial futuro.
+
+## Conclusione
+
+L'adozione di uno standard di accesso, come le firme di Ethereum, affronta il problema dell'uovo e della gallina. I provider di servizi vogliono attrarre il mercato più ampio possibile. Gli utenti vogliono poter accedere ai servizi senza doversi preoccupare di supportare il loro standard di accesso.
+La creazione di adattatori, come un IdP di Ethereum, può aiutarci a superare questo ostacolo.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/gasless/index.md b/public/content/translations/it/developers/tutorials/gasless/index.md
new file mode 100644
index 00000000000..2b6aaad18f1
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/gasless/index.md
@@ -0,0 +1,363 @@
+---
+title: "Sponsorizzare le commissioni: Come coprire i costi di transazione per i tuoi utenti"
+description: "È facile creare una chiave privata e un indirizzo; è solo questione di eseguire il software giusto. Ma ci sono molti posti al mondo in cui ottenere ETH per inviare transazioni è molto più difficile. In questo tutorial imparerai come coprire i costi del gas on-chain per l'esecuzione di dati strutturati fuori catena firmati dall'utente nel tuo contratto intelligente. Fai firmare all'utente una struttura contenente le informazioni della transazione, che il tuo codice fuori catena invia poi alla blockchain come transazione."
+author: Ori Pomerantz
+tags: ["senza gas", "Solidity", "eip-712", "meta-transazioni"]
+skill: intermediate
+breadcrumb: Sponsorizzazione del gas
+lang: it
+published: 2026-02-27
+---
+
+## Introduzione {#introduction}
+
+Se vogliamo che Ethereum serva [un miliardo di persone in più](https://blog.ethereum.org/category/next-billion), dobbiamo rimuovere gli attriti e renderlo il più facile possibile da usare. Una fonte di questo attrito è la necessità di ETH per pagare le commissioni.
+
+Se hai una dApp che guadagna dagli utenti, potrebbe avere senso consentire agli utenti di inviare transazioni tramite il tuo server e pagare tu stesso le commissioni della transazione. Poiché gli utenti firmano comunque un [messaggio di autorizzazione EIP-712](https://eips.ethereum.org/EIPS/eip-712) nei loro portafogli, mantengono le garanzie di integrità di Ethereum. La disponibilità dipende dal server che trasmette le transazioni, quindi è più limitata. Tuttavia, puoi configurare le cose in modo che gli utenti possano anche accedere direttamente al contratto intelligente (se ottengono ETH) e consentire ad altri di configurare i propri server se desiderano sponsorizzare le transazioni.
+
+La tecnica in questo tutorial funziona solo quando controlli il contratto intelligente. Ci sono altre tecniche, inclusa l'[astrazione dell'account](https://eips.ethereum.org/EIPS/eip-4337) che ti permettono di sponsorizzare transazioni verso altri contratti intelligenti, che spero di trattare in un tutorial futuro.
+
+Nota: Questo _non_ è codice a livello di produzione. È vulnerabile ad attacchi significativi e manca di funzionalità importanti. Scopri di più nella [sezione sulle vulnerabilità di questa guida](#vulnerabilities).
+
+### Prerequisiti {#prerequisites}
+
+Per comprendere questo tutorial devi avere già familiarità con:
+
+- Solidity
+- JavaScript
+- React e WAGMI. Se non hai familiarità con questi strumenti per l'interfaccia utente, [abbiamo un tutorial a riguardo](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/).
+
+## L'applicazione di esempio {#sample-app}
+
+L'applicazione di esempio qui è una variante del contratto `Greeter` di Hardhat. Puoi vederla [su GitHub](https://github.com/qbzzt/260301-gasless). Il contratto intelligente è già distribuito su [Sepolia](https://sepolia.dev/), all'indirizzo [`0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA`](https://eth-sepolia.blockscout.com/address/0xC87506C66c7896366b9E988FE0aA5B6dDE77CFfA).
+
+Per vederla in azione, segui questi passaggi.
+
+1. Clona il repository e installa il software necessario.
+
+ ```sh
+ git clone https://github.com/qbzzt/260301-gasless.git
+ cd 260301-gasless/server
+ npm install
+```
+
+2. Modifica `.env` per impostare `PRIVATE_KEY` su un portafoglio che ha ETH su Sepolia. Se hai bisogno di ETH su Sepolia, [usa un rubinetto](/developers/docs/networks/#sepolia). Idealmente, questa chiave privata dovrebbe essere diversa da quella che hai nel portafoglio del tuo browser.
+
+3. Avvia il server.
+
+ ```sh
+ npm run dev
+```
+
+4. Naviga verso l'applicazione all'URL [`http://localhost:5173`](http://localhost:5173).
+
+5. Fai clic su **Connect with Injected** per connetterti a un portafoglio. Approva nel portafoglio e approva il passaggio a Sepolia se necessario.
+
+6. Scrivi un nuovo saluto e fai clic su **Update greeting via sponsor**.
+
+7. Firma il messaggio.
+
+8. Attendi circa 12 secondi (il tempo di blocco su Sepolia). Durante l'attesa puoi guardare l'URL nella console del server per vedere la transazione.
+
+9. Verifica che il saluto sia cambiato e che il valore dell'indirizzo dell'ultimo aggiornamento sia ora l'indirizzo del portafoglio del tuo browser.
+
+Per capire come funziona, dobbiamo esaminare come il messaggio viene creato nell'interfaccia utente, come viene trasmesso dal server e come il contratto intelligente lo elabora.
+
+### L'interfaccia utente {#ui-changes}
+
+L'interfaccia utente è basata su [WAGMI](https://wagmi.sh/); puoi leggerne a riguardo [in questo tutorial](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/).
+
+Ecco come firmiamo il messaggio:
+
+```js
+const signGreeting = useCallback(
+```
+
+L'hook di React [`useCallback`](https://react.dev/reference/react/useCallback) ci permette di migliorare le prestazioni riutilizzando la stessa funzione quando il componente viene ridisegnato.
+
+```js
+ async (greeting) => {
+ if (!account) throw new Error("Wallet not connected")
+```
+
+Se non c'è alcun account, solleva un errore. Questo non dovrebbe mai accadere perché il pulsante dell'interfaccia utente che avvia il processo che chiama `signGreeting` è disabilitato in quel caso. Tuttavia, i programmatori futuri potrebbero rimuovere quella salvaguardia, quindi è una buona idea controllare questa condizione anche qui.
+
+```js
+ const domain = {
+ name: "Greeter",
+ version: "1",
+ chainId,
+ verifyingContract: contractAddr,
+ }
+```
+
+Parametri per il [separatore di dominio](https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator). Questo valore è costante, quindi in un'implementazione meglio ottimizzata, potremmo calcolarlo una volta anziché ricalcolarlo ogni volta che la funzione viene chiamata.
+
+- `name` è un nome leggibile dall'utente, come il nome della dApp per cui stiamo producendo le firme.
+- `version` è la versione. Versioni diverse non sono compatibili.
+- `chainId` è la catena che stiamo utilizzando, come fornito [da WAGMI](https://wagmi.sh/react/api/hooks/useChainId).
+- `verifyingContract` è l'indirizzo del contratto che verificherà questa firma. Non vogliamo che la stessa firma si applichi a più contratti, nel caso in cui ci siano diversi contratti `Greeter` e vogliamo che abbiano saluti diversi.
+
+```js
+
+ const types = {
+ GreetingRequest: [
+ { name: "greeting", type: "string" },
+ ],
+ }
+```
+
+Il tipo di dati che firmiamo. Qui abbiamo un singolo parametro, `greeting`, ma i sistemi reali in genere ne hanno di più.
+
+```js
+ const message = { greeting }
+```
+
+Il messaggio effettivo che vogliamo firmare e inviare. `greeting` è sia il nome del campo che il nome della variabile che lo riempie.
+
+```js
+ const signature = await signTypedDataAsync({
+ domain,
+ types,
+ primaryType: "GreetingRequest",
+ message,
+ })
+```
+
+Ottieni effettivamente la firma. Questa funzione è asincrona perché gli utenti impiegano molto tempo (dal punto di vista di un computer) per firmare i dati.
+
+```js
+ const r = `0x${signature.slice(2, 66)}`
+ const s = `0x${signature.slice(66, 130)}`
+ const v = parseInt(signature.slice(130, 132), 16)
+
+ return {
+ req: { greeting },
+ v,
+ r,
+ s,
+ }
+ },
+```
+
+La funzione restituisce un singolo valore esadecimale. Qui lo dividiamo in campi.
+
+```js
+ [account, chainId, contractAddr, signTypedDataAsync],
+)
+```
+
+Se una qualsiasi di queste variabili cambia, crea una nuova istanza della funzione. I parametri `account` e `chainId` possono essere modificati dall'utente nel portafoglio. `contractAddr` è una funzione dell'Id della catena. `signTypedDataAsync` non dovrebbe cambiare, ma lo importiamo da [un hook](https://wagmi.sh/react/api/hooks/useSignTypedData), quindi non possiamo esserne sicuri, ed è meglio aggiungerlo qui.
+
+Ora che il nuovo saluto è firmato, dobbiamo inviarlo al server.
+
+```js
+ const sponsoredGreeting = async () => {
+ try {
+```
+
+Questa funzione prende una firma e la invia al server.
+
+```js
+ const signedMessage = await signGreeting(newGreeting)
+ const response = await fetch("/server/sponsor", {
+```
+
+Invia al percorso `/server/sponsor` nel server da cui proveniamo.
+
+```js
+ method: "POST",
+ headers: { "Content-Type": "application/json" },
+ body: JSON.stringify(signedMessage),
+ })
+```
+
+Usa `POST` per inviare le informazioni codificate in JSON.
+
+```js
+ const data = await response.json()
+ console.log("Server response:", data)
+ } catch (err) {
+ console.error("Error:", err)
+ }
+ }
+```
+
+Emetti la risposta. Su un sistema di produzione mostreremmo anche la risposta all'utente.
+
+### Il server {#server}
+
+Mi piace usare [Vite](https://vite.dev/) come mio front-end. Serve automaticamente le librerie React e aggiorna il browser quando il codice front-end cambia. Tuttavia, Vite non include strumenti di backend.
+
+La soluzione è in [`index.js`](https://github.com/qbzzt/260301-gasless/blob/main/server/index.js).
+
+```js
+ app.post("/server/sponsor", async (req, res) => {
+ ...
+ })
+
+ // Lascia che Vite gestisca tutto il resto
+ const vite = await createViteServer({
+ server: { middlewareMode: true }
+ })
+
+ app.use(vite.middlewares)
+```
+
+Per prima cosa registriamo un gestore per le richieste che gestiamo noi stessi (`POST` a `/server/sponsor`). Quindi creiamo e usiamo un server Vite per gestire tutti gli altri URL.
+
+```js
+ app.post("/server/sponsor", async (req, res) => {
+ try {
+ const signed = req.body
+
+ const txHash = await sepoliaClient.writeContract({
+ address: greeterAddr,
+ abi: greeterABI,
+ functionName: 'sponsoredSetGreeting',
+ args: [signed.req, signed.v, signed.r, signed.s],
+ })
+ } ...
+ })
+```
+
+Questa è solo una chiamata standard alla blockchain con [viem](https://viem.sh/).
+
+### Il contratto intelligente {#smart-contract}
+
+Infine, [`Greeter.sol`](https://github.com/qbzzt/260301-gasless/blob/main/contracts/src/Greeter.sol) deve verificare la firma.
+
+```solidity
+ constructor(string memory _greeting) {
+ greeting = _greeting;
+
+ DOMAIN_SEPARATOR = keccak256(
+ abi.encode(
+ keccak256(
+ "EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)"
+ ),
+ keccak256(bytes("Greeter")),
+ keccak256(bytes("1")),
+ block.chainid,
+ address(this)
+ )
+ );
+ }
+```
+
+Il costruttore crea il [separatore di dominio](https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator), in modo simile al codice dell'interfaccia utente sopra. L'esecuzione sulla blockchain è molto più costosa, quindi lo calcoliamo solo una volta.
+
+```solidity
+ struct GreetingRequest {
+ string greeting;
+ }
+```
+
+Questa è la struttura che viene firmata. Qui abbiamo un solo campo.
+
+```solidity
+ bytes32 private constant GREETING_TYPEHASH =
+ keccak256("GreetingRequest(string greeting)");
+```
+
+Questo è l'[identificatore della struttura](https://eips.ethereum.org/EIPS/eip-712#definition-of-hashstruct). Viene calcolato ogni volta nell'interfaccia utente.
+
+```solidity
+ function sponsoredSetGreeting(
+ GreetingRequest calldata req,
+ uint8 v,
+ bytes32 r,
+ bytes32 s
+ ) external {
+```
+
+Questa funzione riceve una richiesta firmata e aggiorna il saluto.
+
+```solidity
+ // Calcola il digest EIP-712
+ bytes32 digest = keccak256(
+ abi.encodePacked(
+ "\x19\x01",
+ DOMAIN_SEPARATOR,
+ keccak256(
+ abi.encode(
+ GREETING_TYPEHASH,
+ keccak256(bytes(req.greeting))
+ )
+ )
+ )
+ );
+```
+
+Crea il digest in conformità con l'[EIP 712](https://eips.ethereum.org/EIPS/eip-712).
+
+```solidity
+ // Recupera il firmatario
+ address signer = ecrecover(digest, v, r, s);
+ require(signer != address(0), "Invalid signature");
+```
+
+Usa [`ecrecover`](https://www.evm.codes/precompiled?fork=osaka#0x01) per ottenere l'indirizzo del firmatario. Nota che una firma errata può comunque produrre un indirizzo valido, solo che sarà casuale.
+
+```solidity
+ // Applica il saluto come se il firmatario lo avesse chiamato
+ greeting = req.greeting;
+ emit SetGreeting(signer, req.greeting);
+ }
+```
+
+Aggiorna il saluto.
+
+## Vulnerabilità {#vulnerabilities}
+
+Questo _non_ è codice a livello di produzione. È vulnerabile ad attacchi significativi e manca di funzionalità importanti. Eccone alcune, insieme a come risolverle.
+
+Per vedere alcuni di questi attacchi, fai clic sui pulsanti sotto l'intestazione _Attacks_ e guarda cosa succede. Per il pulsante **Invalid signature**, controlla la console del server per vedere la risposta della transazione.
+
+### Denial of service sul server {#dos-on-server}
+
+L'attacco più semplice è un attacco [denial-of-service](https://en.wikipedia.org/wiki/Denial-of-service_attack) sul server. Il server riceve richieste da qualsiasi parte di Internet e, in base a tali richieste, invia transazioni. Non c'è assolutamente nulla che impedisca a un utente malintenzionato di emettere un mucchio di firme, valide o non valide. Ognuna causerà una transazione. Alla fine il server esaurirà gli ETH per pagare il gas.
+
+Una soluzione a questo problema è limitare la frequenza a una transazione per blocco. Se lo scopo è mostrare i saluti agli [account controllati esternamente](/developers/docs/accounts/#key-differences), non importa comunque quale sia il saluto nel mezzo del blocco.
+
+Un'altra soluzione è tenere traccia degli indirizzi e consentire solo le firme da clienti validi.
+
+### Firme di saluto errate {#wrong-greeting-sigs}
+
+Quando fai clic su **Signature for wrong greeting**, invii una firma valida per un indirizzo specifico (`0xaA92c5d426430D4769c9E878C1333BDe3d689b3e`) e un saluto (`Hello`). Ma lo invia con un saluto diverso. Questo confonde `ecrecover`, che cambia il saluto ma ha l'indirizzo sbagliato.
+
+Per risolvere questo problema, aggiungi l'indirizzo alla [struttura firmata](https://github.com/qbzzt/260301-gasless/blob/main/server/src/Greeter.jsx#L122-L124). In questo modo, l'indirizzo casuale di `ecrecover` non corrisponderà all'indirizzo nella firma e il contratto intelligente rifiuterà il messaggio.
+
+### Attacchi di replay {#replay-attack}
+
+Quando fai clic su **Replay attack**, invii la stessa firma "Sono 0xaA92c5d426430D4769c9E878C1333BDe3d689b3e e vorrei che il saluto fosse `Hello`", ma con il saluto corretto. Di conseguenza, il contratto intelligente crede che l'indirizzo (che non è il tuo) abbia riportato il saluto a `Hello`. Le informazioni per farlo sono pubblicamente disponibili nelle [informazioni della transazione](https://eth-sepolia.blockscout.com/tx/0xa66afe4bbf886f59533e677a798c802ceab1ac0f9db6e83a4d4b59a45cf7c1b1).
+
+Se questo è un problema, una soluzione è aggiungere un [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce). Crea una [mappatura](https://docs.soliditylang.org/en/latest/types.html#mapping-types) tra indirizzi e numeri e aggiungi un campo nonce alla firma. Se il campo nonce corrisponde alla mappatura per l'indirizzo, accetta la firma e incrementa la mappatura per la volta successiva. In caso contrario, rifiuta la transazione.
+
+Un'altra soluzione è aggiungere un timestamp ai dati firmati e accettare la firma come valida solo per pochi secondi dopo quel timestamp. Questo è più semplice ed economico, ma rischiamo attacchi di replay all'interno della finestra temporale e il fallimento di transazioni legittime se la finestra temporale viene superata.
+
+## Altre funzionalità mancanti {#other-missing-features}
+
+Ci sono funzionalità aggiuntive che aggiungeremmo in un ambiente di produzione.
+
+### Accesso da altri server {#other-servers}
+
+Attualmente, consentiamo a qualsiasi indirizzo di inviare un `sponsorSetGreeting`. Questo potrebbe essere esattamente ciò che vogliamo, nell'interesse della decentralizzazione. O forse vogliamo assicurarci che le transazioni sponsorizzate passino attraverso il _nostro_ server, nel qual caso controlleremmo `msg.sender` nel contratto intelligente.
+
+In ogni caso, questa dovrebbe essere una decisione di progettazione consapevole, non solo il risultato di non aver pensato al problema.
+
+### Gestione degli errori {#error-handling}
+
+Un utente invia un saluto. Forse viene aggiornato al blocco successivo. Forse no. Gli errori sono invisibili. Su un sistema di produzione, l'utente dovrebbe essere in grado di distinguere tra questi casi:
+
+- Il nuovo saluto non è stato ancora inviato
+- Il nuovo saluto è stato inviato ed è in fase di elaborazione
+- Il nuovo saluto è stato rifiutato
+
+## Conclusione {#conclusion}
+
+A questo punto, dovresti essere in grado di creare un'esperienza senza gas per gli utenti della tua dApp, al costo di una certa centralizzazione.
+
+Tuttavia, questo funziona solo con contratti intelligenti che supportano ERC-712. Per trasferire un token ERC-20, ad esempio, è necessario che la transazione sia firmata dal proprietario anziché solo un messaggio. La soluzione è l'[astrazione dell'account (ERC-4337)](https://docs.erc4337.io/index.html). Spero di scrivere un tutorial futuro a riguardo.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
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 13d10e13f2f..12f51be6b43 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
@@ -1,61 +1,56 @@
---
-title: Primi passi con lo sviluppo di Ethereum
-description: "Questa è una guida per principianti per iniziare con lo sviluppo di Ethereum. Ti guideremo dal lancio di un endpoint API alla formulazione di una richiesta da riga di comando, fino alla scrittura del tuo primo script web3! Non è necessaria alcuna esperienza di sviluppo con le blockchain!"
+title: Iniziare con lo sviluppo su Ethereum
+description: "Questa è una guida per principianti per iniziare con lo sviluppo su Ethereum. Ti accompagneremo dall'avvio di un endpoint API, all'esecuzione di una richiesta da riga di comando, fino alla scrittura del tuo primo script web3! Nessuna esperienza di sviluppo blockchain necessaria!"
author: "Elan Halpern"
-tags:
- - "javascript"
- - "ethers.js"
- - "nodi"
- - "query"
- - "alchemy"
+tags: ["JavaScript", "ethers.js", "nodi", "query", "Alchemy"]
skill: beginner
-breadcrumb: "Primi passi"
+breadcrumb: Per iniziare
lang: it
published: 2020-10-30
-source: Medio
+source: Medium
sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f
---
-
+
-Questa è una guida per principianti per muovere i primi passi con lo sviluppo di Ethereum. Per questo tutorial useremo [Alchemy](https://alchemyapi.io/), la piattaforma principale per sviluppatori della blockchain con milioni di utenti dal 70% delle migliori app della blockchain, tra cui Maker, 0x, MyEtherWallet, Dharma e Kyber. Alchemy ci darà accesso all'endpoint di un'API sulla catena di Ethereum, così da permetterci di leggere e scrivere le transazioni.
+Questa è una guida per principianti per iniziare con lo sviluppo su Ethereum. Per questo tutorial utilizzeremo [Alchemy](https://alchemyapi.io/), la principale piattaforma di sviluppo blockchain che alimenta milioni di utenti dal 70% delle migliori app blockchain, tra cui Maker, 0x, MyEtherWallet, Dharma e Kyber. Alchemy ci darà accesso a un endpoint API sulla catena di Ethereum in modo da poter leggere e scrivere transazioni.
-Inizieremo dalla registrazione ad Alchemy e passeremo alla scrittura del tuo primo script web3! Non è necessaria alcuna esperienza di sviluppo con blockchain.
+Ti accompagneremo dalla registrazione su Alchemy alla scrittura del tuo primo script web3! Nessuna esperienza di sviluppo blockchain necessaria!
-## 1. Registrati per un Conto Gratuito di Alchemy {#sign-up-for-a-free-alchemy-account}
+## 1. Registrati per un account Alchemy gratuito {#sign-up-for-a-free-alchemy-account}
-Creare un conto di Alchemy è facile, [registrati gratuitamente qui](https://auth.alchemyapi.io/signup).
+Creare un account con Alchemy è facile, [registrati gratuitamente qui](https://auth.alchemy.com/).
-## 2. Crea un'app con Alchemy {#create-an-alchemy-app}
+## 2. Crea un'app Alchemy {#create-an-alchemy-app}
-Per comunicare con la catena Ethereum e per utilizzare i prodotti di Alchemy, è necessaria una chiave API per autenticare le richieste.
+Per comunicare con la catena di Ethereum e utilizzare i prodotti di Alchemy, hai bisogno di una chiave API per autenticare le tue richieste.
-Puoi [creare chiavi API dalla dashboard](http://dashboard.alchemyapi.io/). Per creare una nuova chiave, vai a "Create App" come mostrato sotto:
+Puoi [creare chiavi API dalla dashboard](https://dashboard.alchemy.com/). Per creare una nuova chiave, vai su "Create App" (Crea App) come mostrato di seguito:
-Ringraziamenti speciali a [_ShapeShift_](https://shapeshift.com/) _per averci permesso di mostrare la sua dashboard!_
+Un ringraziamento speciale a [_ShapeShift_](https://shapeshift.com/) _per averci permesso di mostrare la loro dashboard!_
-Compila i dettagli sotto "Create App" per ottenere la tua nuova chiave. Qui puoi anche vedere le app create in precedenza e quelle create dal tuo team. Preleva le chiavi esistenti facendo clic su "View Key" per qualsiasi app.
+Compila i dettagli sotto "Create App" per ottenere la tua nuova chiave. Qui puoi anche vedere le app che hai creato in precedenza e quelle create dal tuo team. Recupera le chiavi esistenti cliccando su "View Key" (Visualizza Chiave) per qualsiasi app.
-
+
-Puoi anche prelevare chiavi API esistenti passando con il mouse su "Apps" e selezionandone una. Puoi scegliere "View Key" o "Edit App" per consentire domini specifici, vedere diversi strumenti da sviluppatore e visualizzare i dati analitici.
+Puoi anche recuperare le chiavi API esistenti passando il mouse su "Apps" e selezionandone una. Qui puoi cliccare su "View Key", così come su "Edit App" (Modifica App) per inserire nella whitelist domini specifici, vedere diversi strumenti per sviluppatori e visualizzare le analisi.
-
+
## 3. Effettua una richiesta dalla riga di comando {#make-a-request-from-the-command-line}
-Interagisci con la blockchain Ethereum tramite Alchemy usando JSON-RPC e curl.
+Interagisci con la blockchain di Ethereum tramite Alchemy utilizzando JSON-RPC e curl.
-Per le richieste manuali, consigliamo di interagire con `JSON-RPC` tramite richieste `POST`. Passa semplicemente nell'intestazione `Content-Type: application/json` la tua query sotto forma di corpo `POST` con i seguenti campi:
+Per le richieste manuali, consigliamo di interagire con `JSON-RPC` tramite richieste `POST`. Passa semplicemente l'intestazione `Content-Type: application/json` e la tua query come corpo della richiesta `POST` con i seguenti campi:
-- `jsonrpc`: versione JSON-RPC. Attualmente è supportata solo la `2.0`.
-- `method`: metodo dell'API ETH. [Vedi il riferimento all'API.](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc)
-- `params`: elenco di parametri da passare al metodo.
-- `id`: ID della richiesta. Sarà restituita dalla risposta, e potrai controllare sempre a quale richiesta appartiene la risposta.
+- `jsonrpc`: La versione JSON-RPC; attualmente è supportata solo la `2.0`.
+- `method`: Il metodo dell'API ETH. [Vedi il riferimento API.](https://docs.alchemyapi.io/documentation/alchemy-api-reference/json-rpc)
+- `params`: Un elenco di parametri da passare al metodo.
+- `id`: L'ID della tua richiesta. Verrà restituito dalla risposta in modo da poter tenere traccia a quale richiesta appartiene una risposta.
-Ecco un esempio che puoi eseguire dalla riga di comando per recuperare il prezzo corrente del gas:
+Ecco un esempio che puoi eseguire dalla riga di comando per recuperare l'attuale prezzo del gas:
```bash
curl https://eth-mainnet.alchemyapi.io/v2/demo \
@@ -64,7 +59,7 @@ curl https://eth-mainnet.alchemyapi.io/v2/demo \
-d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}'
```
-_**NOTA:** Sostituisci [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo) con la tua chiave API `https://eth-mainnet.alchemyapi.io/v2/**your-api-key`._
+_**NOTA:** Sostituisci [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-mainnet.alchemyapi.io/jsonrpc/demo) con la tua chiave API `https://eth-mainnet.alchemyapi.io/v2/**la-tua-chiave-api`._
**Risultati:**
@@ -72,15 +67,15 @@ _**NOTA:** Sostituisci [https://eth-mainnet.alchemyapi.io/v2/demo](https://eth-m
{ "id": 73,"jsonrpc": "2.0","result": "0x09184e72a000" // 10000000000000 }
```
-## 4. Configura il client Web3 {#set-up-your-web3-client}
+## 4. Configura il tuo client Web3 {#set-up-your-web3-client}
-**Se hai già un client,** cambia l'URL del provider del nodo corrente inserendo un URL Alchemy con la tua chiave API: `"https://eth-mainnet.alchemyapi.io/v2/your-api-key"`
+**Se hai un client esistente,** cambia l'URL del tuo attuale fornitore di nodi in un URL di Alchemy con la tua chiave API: `“https://eth-mainnet.alchemyapi.io/v2/la-tua-chiave-api"`
-**_NOTA:_** gli script qui sotto devono essere eseguiti in un **contesto node** o **salvati in un file**, non devono essere eseguiti dalla riga di comando. Se non hai installato Node o npm, dai un'occhiata a questa [guida di configurazione per Mac](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs).
+**_NOTA:_** Gli script sottostanti devono essere eseguiti in un **contesto nodo** o **salvati in un file**, non eseguiti dalla riga di comando. Se non hai già installato Node o npm, dai un'occhiata a questa rapida [guida alla configurazione per Mac](https://app.gitbook.com/@alchemyapi/s/alchemy/guides/alchemy-for-macs).
-Ci sono tantissime [librerie Web3](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries) che puoi integrare con Alchemy, tuttavia, consigliamo di usare [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), un sostituto di web3.js, creato e configurato per funzionare senza problemi con Alchemy. Fornisce diversi vantaggi, come tentativi automatici e supporto affidabile per WebSocket.
+Ci sono tantissime [librerie Web3](https://docs.alchemyapi.io/guides/getting-started#other-web3-libraries) che puoi integrare con Alchemy, tuttavia, ti consigliamo di utilizzare [Alchemy Web3](https://docs.alchemy.com/reference/api-overview), un sostituto diretto per web3.js, creato e configurato per funzionare perfettamente con Alchemy. Questo offre molteplici vantaggi come i tentativi automatici e un robusto supporto WebSocket.
-Per installare AlchemyWeb3.js, **passa alla directory del tuo progetto** ed esegui:
+Per installare AlchemyWeb3.js, **vai alla directory del tuo progetto** ed esegui:
**Con Yarn:**
@@ -94,7 +89,7 @@ yarn add @alch/alchemy-web3
npm install @alch/alchemy-web3
```
-Per interagire con l'infrastruttura del nodo di Alchemy, esegui NodeJS o aggiungi il codice seguente a un file JavaScript:
+Per interagire con l'infrastruttura del nodo di Alchemy, esegui in NodeJS o aggiungi questo a un file JavaScript:
```js
const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
@@ -105,24 +100,24 @@ const web3 = createAlchemyWeb3(
## 5. Scrivi il tuo primo script Web3! {#write-your-first-web3-script}
-Ora per sporcarci un po' le mani con la programmazione web3 scriveremo uno script semplice che riporta il numero dell'ultimo blocco della rete principale Ethereum.
+Ora, per sporcarci le mani con un po' di programmazione web3, scriveremo un semplice script che stampa l'ultimo numero di blocco dalla rete principale di Ethereum.
-**1. Se non lo hai già fatto, nel terminale crea una nuova directory del progetto passa ad essa (cd):**
+**1. Se non l'hai già fatto, nel tuo terminale crea una nuova directory di progetto ed entraci con cd:**
```
mkdir web3-example
cd web3-example
```
-**2. Se non lo hai già fatto, installa la dipendenza Alchemy Web3 (o web3 di altro tipo) nel progetto:**
+**2. Installa la dipendenza web3 di Alchemy (o qualsiasi web3) nel tuo progetto se non l'hai già fatto:**
```
npm install @alch/alchemy-web3
```
-**3. Crea un file denominato `index.js` e aggiungi i seguenti contenuti:**
+**3. Crea un file chiamato `index.js` e aggiungi i seguenti contenuti:**
-> Devi sostituire `demo` con la tua chiave API HTTP di Alchemy.
+> Alla fine dovresti sostituire `demo` con la tua chiave API HTTP di Alchemy.
```js
async function main() {
@@ -134,22 +129,22 @@ async function main() {
main()
```
-Non hai famigliarità con la programmazione asincrona? Dai un'occhiata a questo [post di Medium](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c).
+Non hai familiarità con la programmazione asincrona? Dai un'occhiata a questo [post su Medium](https://medium.com/better-programming/understanding-async-await-in-javascript-1d81bb079b2c).
-**4. Eseguilo nel terminale usando node**
+**4. Eseguilo nel tuo terminale usando node**
```
node index.js
```
-**5. A questo punto dovresti vedere l'output con il numero dell'ultimo blocco nella console!**
+**5. Ora dovresti vedere l'output dell'ultimo numero di blocco nella tua console!**
```
The latest block number is 11043912
```
-**Wow! Congratulazioni! Hai appena scritto il tuo primo script web3 usando Alchemy**
+**Evviva! Congratulazioni! Hai appena scritto il tuo primo script web3 usando Alchemy 🎉**
-Non sai come proseguire? Prova a distribuire il tuo primo smart contract e fai qualche prova pratica di programmazione in Solidity nella nostra [Guida agli smart contract Hello World](https://docs.alchemyapi.io/tutorials/hello-world-smart-contract) o testa la tua conoscenza della Dashboard con l'[_App Demo della Dashboard_](https://docs.alchemyapi.io/tutorials/demo-app)!
+Non sai cosa fare dopo? Prova a distribuire il tuo primo contratto intelligente e sporcati le mani con un po' di programmazione in Solidity nella nostra [Guida al contratto intelligente Hello World](https://www.alchemy.com/docs/hello-world-smart-contract), oppure metti alla prova la tua conoscenza della dashboard con l'[App Demo della Dashboard](https://docs.alchemyapi.io/tutorials/demo-app)!
-_[Iscriviti gratis ad Alchemy](https://auth.alchemyapi.io/signup), dai un'occhiata alla nostra [documentazione](https://docs.alchemyapi.io/) e, per le ultime notizie, seguici su [Twitter](https://twitter.com/AlchemyPlatform)_.
+_[Registrati gratuitamente su Alchemy](https://auth.alchemy.com/), dai un'occhiata alla nostra [documentazione](https://www.alchemy.com/docs/) e, per le ultime notizie, seguici su [Twitter](https://twitter.com/AlchemyPlatform)_.
\ No newline at end of file
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 302d70f5b8e..51a1e458b54 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
@@ -1,106 +1,103 @@
---
-title: Una guida agli strumenti di sicurezza per gli smart contract
-description: Una panoramica di tre differenti tecniche di test e analisi del programma
+title: Una guida agli strumenti di sicurezza per i contratti intelligenti
+description: Una panoramica di tre diverse tecniche di test e analisi dei programmi
author: "Trailofbits"
lang: it
-tags:
- - "solidity"
- - "contratti intelligenti"
- - "sicurezza"
+tags: ["Solidity", "contratti intelligenti", "sicurezza"]
skill: intermediate
-breadcrumb: "Strumenti di sicurezza"
+breadcrumb: Strumenti di sicurezza
published: 2020-09-07
-source: Creare contratti sicuri
+source: Building secure contracts
sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis
---
-Utilizziremo tre distinte tecniche di test e analisi del programma:
+Utilizzeremo tre tecniche distinte di test e analisi dei programmi:
-- **Analisi statica con [Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/).** Tutti i percorsi del programma sono approssimati e analizzati simultaneamente, tramite diverse presentazioni del programma (es. diagramma di flusso di controllo)
-- **Fuzzing con [Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/).** Il codice è eseguito con una generazione pseudo-casuale di transazioni. Il fuzzer proverà a trovare una sequenza di transazioni per violare una data proprietà.
-- **Esecuzione simbolica con [Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/).** Una tecnica di verifica formale che traduce ogni percorso d'esecuzione in una formula matematica, su cui possono essere controllati i vincoli massimi.
+- **Analisi statica con [Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/).** Tutti i percorsi del programma vengono approssimati e analizzati contemporaneamente, attraverso diverse presentazioni del programma (es. grafo del flusso di controllo).
+- **Fuzzing con [Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/).** Il codice viene eseguito con una generazione pseudo-casuale di transazioni. Il fuzzer cercherà di trovare una sequenza di transazioni per violare una determinata proprietà.
+- **Esecuzione simbolica con [Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/).** Una tecnica di verifica formale, che traduce ogni percorso di esecuzione in una formula matematica, su cui possono essere verificati dei vincoli.
-Ogni tecnica ha vantaggi e svantaggi ed è utile in [casi specifici](#determining-security-properties):
+Ogni tecnica presenta vantaggi e insidie, e sarà utile in [casi specifici](#determining-security-properties):
-| Tecnica | Strumento | Uso | Velocità | Bug mancati | Falsi allarmi |
-| -------------------- | --------- | ------------------------------ | -------- | ----------- | ------------- |
-| Analisi statica | Slither | CLI e script | secondi | moderati | bassi |
-| Fuzzing | Echidna | Proprietà di Solidity | minuti | bassi | nessuno |
-| Esecuzione simbolica | Manticore | Proprietà di Solidity e script | ore | nessuno\* | nessuno |
+| Tecnica | Strumento | Utilizzo | Velocità | Bug mancati | Falsi allarmi |
+| ------------------ | --------- | ----------------------------- | ------- | ----------- | ------------ |
+| Analisi Statica | Slither | CLI e script | secondi | moderati | bassi |
+| Fuzzing | Echidna | Proprietà di Solidity | minuti | bassi | nessuno |
+| Esecuzione Simbolica | Manticore | Proprietà di Solidity e script | ore | nessuno\* | nessuno |
-\* se tutti i percorsi sono esplorati senza timeout
+\* se tutti i percorsi vengono esplorati senza timeout
-**Slither** analizza i contratti in pochi secondi, tuttavia, l'analisi statica potrebbe condurre a falsi allarmi e sarà meno idonea per i controlli complessi (es. controlli aritmetici). Esegui Slither tramite l'API per l'accesso ai pulsanti per i rilevatori integrati o tramite l'API per i controlli definiti dall'utente.
+**Slither** analizza i contratti in pochi secondi, tuttavia, l'analisi statica potrebbe portare a falsi allarmi e sarà meno adatta per controlli complessi (es. controlli aritmetici). Esegui Slither tramite l'API per un accesso immediato ai rilevatori integrati o tramite l'API per controlli definiti dall'utente.
-**Echidna** deve essere eseguito per diversi minuti e produrrà solo veri positivi. Echidna controlla le proprietà di sicurezza fornite dall'utente, scritte in Solidity. Potrebbe tralasciare dei bug, essendo basato sull'esplorazione casuale.
+**Echidna** deve essere eseguito per diversi minuti e produrrà solo veri positivi. Echidna verifica le proprietà di sicurezza fornite dall'utente, scritte in Solidity. Potrebbe mancare dei bug poiché si basa sull'esplorazione casuale.
-**Manticore** esegue l'analisi dal "peso maggiore". Come Echidna, Manticore verifica le proprietà fornite dall'utente. Necessiterà di maggiore tempo per funzionare, ma può provare la validità di una proprietà e non segnalerà falsi allarmi.
+**Manticore** esegue l'analisi "più intensiva". Come Echidna, Manticore verifica le proprietà fornite dall'utente. Avrà bisogno di più tempo per l'esecuzione, ma può dimostrare la validità di una proprietà e non segnalerà falsi allarmi.
## Flusso di lavoro suggerito {#suggested-workflow}
-Inizia con i rilevatori integrati di Slither per assicurarti che non siano presenti bug semplici ora o che non saranno introdotti in seguito. Usa Slither per controllare le proprietà correlate all'eredità, le dipendenze della variabile e i problemi strutturali. Al crescere della base di codice, usa Echidna per testare proprietà più complesse della macchina di stato. Rivisita Slither per sviluppare controlli personalizzati per protezioni non disponibili con Solidity, come la protezione contro una funzione in sovrascrizione. Infine, usa Manticore per eseguire la verifica mirata di proprietà di sicurezza critiche, ad es. operazioni aritmetiche.
+Inizia con i rilevatori integrati di Slither per assicurarti che non siano presenti bug semplici ora o che non vengano introdotti in seguito. Usa Slither per verificare le proprietà relative all'ereditarietà, alle dipendenze delle variabili e ai problemi strutturali. Man mano che la base di codice cresce, usa Echidna per testare proprietà più complesse della macchina a stati. Ritorna a Slither per sviluppare controlli personalizzati per protezioni non disponibili in Solidity, come la protezione contro la sovrascrittura di una funzione. Infine, usa Manticore per eseguire una verifica mirata delle proprietà di sicurezza critiche, ad es. le operazioni aritmetiche.
-- Usa la CLI di Slither per individuare problemi comuni
-- Usa Echidna per testare le proprietà di sicurezza d'alto livello del tuo contratto
+- Usa la CLI di Slither per individuare i problemi comuni
+- Usa Echidna per testare le proprietà di sicurezza di alto livello del tuo contratto
- Usa Slither per scrivere controlli statici personalizzati
-- Usa Manticore quando desideri un'assicurazione approfondita delle proprietà di sicurezza critiche
+- Usa Manticore quando desideri una garanzia approfondita delle proprietà di sicurezza critiche
-**Una nota sui test unitari**. I testi unitari servono necessariamente per creare software di alta qualità. Tuttavia, queste tecniche non sono le più adatte a trovare difetti di sicurezza. Sono tipicamente usati per testare i comportamenti positivi del codice (ad es. il codice funziona come previsto nel contesto normale), mentre i difetti di sicurezza tendono a risiedere in casi al limite che gli sviluppatori non hanno considerato. Nel nostro studio di dozzine di revisioni di sicurezza di contratti intelligenti, la [copertura dei test unitari non ha avuto alcun effetto sul numero o sulla gravità dei difetti di sicurezza](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/) trovati nel codice del nostro client.
+**Una nota sui test unitari**. I test unitari sono necessari per creare software di alta qualità. Tuttavia, queste tecniche non sono le più adatte per trovare falle di sicurezza. In genere vengono utilizzate per testare i comportamenti positivi del codice (ovvero, il codice funziona come previsto nel contesto normale), mentre le falle di sicurezza tendono a risiedere in casi limite che gli sviluppatori non hanno considerato. Nel nostro studio su dozzine di revisioni di sicurezza dei contratti intelligenti, [la copertura dei test unitari non ha avuto alcun effetto sul numero o sulla gravità delle falle di sicurezza](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/) che abbiamo trovato nel codice dei nostri clienti.
## Determinare le proprietà di sicurezza {#determining-security-properties}
-Per testare e verificare efficacemente il tuo codice, devi identificare le aree che richiedono attenzione. Poiché le risorse impiegate per la sicurezza sono limitate, è importante sfruttare le parti deboli o d'alto valore della tua base di codice per ottimizzare lo sforzo. La modellazione della minaccia può essere utile. Puoi consultare:
+Per testare e verificare efficacemente il tuo codice, devi identificare le aree che richiedono attenzione. Poiché le risorse spese per la sicurezza sono limitate, definire l'ambito delle parti deboli o di alto valore della tua base di codice è importante per ottimizzare i tuoi sforzi. La modellazione delle minacce può aiutare. Prendi in considerazione la revisione di:
-- [Valutazione rapida del rischio](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) (il nostro approccio preferito quando c'è poco tempo a disposizione)
-- [Guide to Data-Centric System Threat Modeling](https://csrc.nist.gov/publications/detail/sp/800-154/draft) (o NIST 800-154)
-- [Modellazione delle minacce Shostack](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998)
-- [STRIDE](https://wikipedia.org/wiki/STRIDE_(security)) / [DREAD](https://wikipedia.org/wiki/DREAD_(risk_assessment_model))
+- [Valutazioni rapide del rischio](https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) (il nostro approccio preferito quando il tempo scarseggia)
+- [Guida alla modellazione delle minacce dei sistemi incentrati sui dati](https://csrc.nist.gov/pubs/sp/800/154/ipd) (nota anche come NIST 800-154)
+- [Modellazione delle minacce di Shostack](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998)
+- [STRIDE]() / [DREAD]()
- [PASTA](https://wikipedia.org/wiki/Threat_model#P.A.S.T.A.)
- [Uso delle asserzioni](https://blog.regehr.org/archives/1091)
### Componenti {#components}
-Sapere cosa vuoi controllare ti aiuterà anche a selezionare lo strumento più adatto.
+Sapere cosa si desidera controllare aiuterà anche a selezionare lo strumento giusto.
-Tra le grandi aree spesso pertinenti per gli smart contract troviamo:
+Le ampie aree che sono frequentemente rilevanti per i contratti intelligenti includono:
-- **Macchina di stato.** Gran parte dei contratti è rappresentabile come una macchina di stato. Considera di controllare che: (1) nessuno stato invalido sia raggiungibile, (2) se uno stato è valido, che sia raggiungibile e (3) nessuno stato intrappoli il contratto.
+- **Macchina a stati.** La maggior parte dei contratti può essere rappresentata come una macchina a stati. Considera di verificare che (1) non possa essere raggiunto alcuno stato non valido, (2) se uno stato è valido possa essere raggiunto, e (3) nessuno stato intrappoli il contratto.
- - Echidna e Manticore sono gli strumenti da preferire per testare le specifiche della macchina di stato.
+ - Echidna e Manticore sono gli strumenti da preferire per testare le specifiche della macchina a stati.
-- **Controlli d'accesso.** Se il tuo sistema ha degli utenti privilegiati (ad es. un proprietario, controllori...) devi assicurarti che (1) ogni utente possa eseguire solo le azioni autorizzate e (2) nessun utente possa bloccare le azioni da un utente più privilegiato.
+- **Controlli di accesso.** Se il tuo sistema ha utenti privilegiati (es. un proprietario, controllori, ...) devi assicurarti che (1) ogni utente possa eseguire solo le azioni autorizzate e (2) nessun utente possa bloccare le azioni di un utente più privilegiato.
- - Slither, Echidna e Manticore possono controllare i controlli d'accesso corretti. Ad esempio, Slither può controllare che solo alle funzioni incluse nella white list manchi il modificatore onlyOwner. Echidna e Manticore sono utili per un controllo d'accesso più complesso, come un permesso dato solo se il contratto raggiunge un particolare stato.
+ - Slither, Echidna e Manticore possono verificare la correttezza dei controlli di accesso. Ad esempio, Slither può verificare che solo le funzioni in whitelist siano prive del modificatore `onlyOwner`. Echidna e Manticore sono utili per controlli di accesso più complessi, come un permesso concesso solo se il contratto raggiunge un determinato stato.
-- **Operazioni aritmetiche.** Controllare la solidità delle operazioni aritmetiche è fondamentale. Usare `SafeMath` ovunque è un buon passo per prevenire overflow e underflow, ma occorre comunque considerare altri difetti aritmetici, tra cui i problemi d'arrotondamento e i difetti che intrappolano il contratto.
+- **Operazioni aritmetiche.** Verificare la solidità delle operazioni aritmetiche è fondamentale. Usare `SafeMath` ovunque è un buon passo per prevenire overflow/underflow, tuttavia, devi comunque considerare altre falle aritmetiche, inclusi problemi di arrotondamento e falle che intrappolano il contratto.
- - Manticore è la migliore scelta a questo scopo. Echidna è utilizzabile se l'aritmetica è esclusa dall'ambito del risolutore SMT.
+ - Manticore è la scelta migliore in questo caso. Echidna può essere utilizzato se l'aritmetica è fuori dall'ambito del risolutore SMT.
-- **Correttezza dell'eredità.** I contratti di Solidity fanno ampio affidamento sull'eredità multipla. Sono facilmente introducibili errori quali funzioni di shadowing prive di chiamata `super` e ordini di linearizzazione c3 interpretati erroneamente.
+- **Correttezza dell'ereditarietà.** I contratti Solidity si basano pesantemente sull'ereditarietà multipla. Errori come una funzione di shadowing a cui manca una chiamata `super` e un ordine di linearizzazione c3 interpretato male possono essere facilmente introdotti.
- - Slither è lo strumento giusto per assicurare il rilevamento di tali problemi.
+ - Slither è lo strumento per garantire il rilevamento di questi problemi.
-- **Interazioni esterne.** I contratti interagiscono tra loro, ragion per cui non ci si dovrebbe fidare di alcuni contratti esterni. Ad esempio, se il tuo contratto si basa su oracoli esterni, rimarrà sicuro se metà degli oracoli disponibili sono compromessi?
+- **Interazioni esterne.** I contratti interagiscono tra loro e alcuni contratti esterni non dovrebbero essere considerati attendibili. Ad esempio, se il tuo contratto si affida a oracoli esterni, rimarrà sicuro se metà degli oracoli disponibili viene compromessa?
- - Manticore ed Echidna sono la scelta migliore per testare le interazioni esterne coi tuoi contratti. Manticore ha un meccanismo integrato per troncare i contratti esterni.
+ - Manticore ed Echidna sono la scelta migliore per testare le interazioni esterne con i tuoi contratti. Manticore ha un meccanismo integrato per creare stub dei contratti esterni.
-- **Conformità standard.** Gli standard di Ethereum (es. ERC20) sono noti per i difetti a livello di progettazione. Sii consapevole delle limitazioni dello standard su cui stai costruendo.
- - Slither, Echidna e Manticore ti aiuteranno a rilevare le deviazioni da un dato standard.
+- **Conformità agli standard.** Gli standard di Ethereum (es. ERC20) hanno una storia di falle nella loro progettazione. Sii consapevole delle limitazioni dello standard su cui stai costruendo.
+ - Slither, Echidna e Manticore ti aiuteranno a rilevare le deviazioni da un determinato standard.
-### Tabella riepilogativa per la selezione degli strumenti {#tool-selection-cheatsheet}
+### Cheat sheet per la selezione degli strumenti {#tool-selection-cheatsheet}
-| Componente | Strumenti | Esempi |
-| ------------------------ | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Macchina di stato | Echidna, Manticore | |
-| Controllo d'accesso | Slither, Echidna, Manticore | [Esercizio di Slither 2](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md), [Esercizio di Echidna 2](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) |
-| Operazioni aritmetiche | Manticore, Echidna | [Esercizio di Echidna 1](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md), [Esercizi di Manticore 1 - 3](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) |
-| Correttezza d'eredità | Slither | [Esercizio di Slither 1](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) |
-| Interazioni esterne | Manticore, Echidna | |
-| Conformità agli standard | Slither, Echidna, Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) |
+| Componente | Strumenti | Esempi |
+| ----------------------- | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Macchina a stati | Echidna, Manticore |
+| Controllo di accesso | Slither, Echidna, Manticore | [Esercizio 2 di Slither](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise2.md), [Esercizio 2 di Echidna](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-2.md) |
+| Operazioni aritmetiche | Manticore, Echidna | [Esercizio 1 di Echidna](https://github.com/crytic/building-secure-contracts/blob/master/program-analysis/echidna/exercises/Exercise-1.md), [Esercizi 1 - 3 di Manticore](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore/exercises) |
+| Correttezza dell'ereditarietà | Slither | [Esercizio 1 di Slither](https://github.com/crytic/slither/blob/7f54c8b948c34fb35e1d61adaa1bd568ca733253/docs/src/tutorials/exercise1.md) |
+| Interazioni esterne | Manticore, Echidna |
+| Conformità agli standard | Slither, Echidna, Manticore | [`slither-erc`](https://github.com/crytic/slither/wiki/ERC-Conformance) |
-Occorrerà controllare altri aspetti a seconda degli obiettivi, ma queste macro aree di attenzione sono un buon inizio per qualunque sistema di smart contract.
+Altre aree dovranno essere controllate a seconda dei tuoi obiettivi, ma queste aree di interesse generali sono un buon punto di partenza per qualsiasi sistema di contratti intelligenti.
-I nostri controlli pubblici contengono esempi di proprietà verificate o testate. Considera di leggere le sezioni `Test e verifiche automatizzate` dei seguenti report per verificare le proprietà di sicurezza reali:
+I nostri audit pubblici contengono esempi di proprietà verificate o testate. Considera di leggere le sezioni `Automated Testing and Verification` dei seguenti report per esaminare le proprietà di sicurezza del mondo reale:
- [0x](https://github.com/trailofbits/publications/blob/master/reviews/0x-protocol.pdf)
-- [Balancer](https://github.com/trailofbits/publications/blob/master/reviews/BalancerCore.pdf)
+- [Balancer](https://github.com/trailofbits/publications/blob/master/reviews/BalancerCore.pdf)
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/hello-world-smart-contract/index.md b/public/content/translations/it/developers/tutorials/hello-world-smart-contract/index.md
index bf6c2e7eab5..9c13bbc4196 100644
--- a/public/content/translations/it/developers/tutorials/hello-world-smart-contract/index.md
+++ b/public/content/translations/it/developers/tutorials/hello-world-smart-contract/index.md
@@ -1,91 +1,80 @@
---
-title: Smart Contract "Hello World" per principianti
-description: Tutorial introduttivo su come scrivere e distribuire un semplice smart contract su Ethereum.
+title: Contratto intelligente Hello World per principianti
+description: Tutorial introduttivo sulla scrittura e la distribuzione di un semplice contratto intelligente su Ethereum.
author: "elanh"
-tags:
- - "solidity"
- - "hardhat"
- - "alchemy"
- - "smart contract"
- - "distribuzione"
+tags: ["Solidity", "Hardhat", "Alchemy", "contratti intelligenti", "distribuzione"]
skill: beginner
-breadcrumb: "Contratto Hello World"
+breadcrumb: Contratto Hello World
lang: it
published: 2021-03-31
---
-Se hai appena iniziato con lo sviluppo blockchain e non sai da dove cominciare, oppure se sei solo interessato a capire come distribuire e interagire con gli smart contract, questa è la guida che fa al caso tuo. Esamineremo la creazione e la distribuzione di un semplice contratto intelligente sulla rete di prova di Goerli, utilizzando un portafoglio virtuale di [MetaMask](https://metamask.io/), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org/) e [Alchemy](https://alchemyapi.io/eth) (non preoccuparti se non capisci cosa significhi, lo spiegheremo).
+Se sei nuovo nello sviluppo su blockchain e non sai da dove iniziare, o se vuoi semplicemente capire come distribuire e interagire con i contratti intelligenti, questa guida fa per te. Ti guideremo attraverso la creazione e la distribuzione di un semplice contratto intelligente sulla rete di test Sepolia utilizzando un portafoglio virtuale [MetaMask](https://metamask.io/), [Solidity](https://docs.soliditylang.org/en/v0.8.0/), [Hardhat](https://hardhat.org/) e [Alchemy](https://www.alchemy.com/eth) (non preoccuparti se non capisci ancora cosa significhi tutto questo, lo spiegheremo).
-> **Attenzione**
->
-> 🚧 Avviso di obsolescenza
->
-> Per l'intera guida, la rete di test Goerli viene utilizzata per creare e distribuire un contratto intelligente. Tuttavia, tieni presente che la Ethereum Foundation ha annunciato che [Goerli sarà presto abbandonata](https://www.alchemy.com/blog/goerli-faucet-deprecation).
->
-> Ti consigliamo di utilizzare [Sepolia](https://sepoliafaucet.com/) e il [faucet di Sepolia](https://www.alchemy.com/overviews/sepolia-testnet) per questo tutorial.
+Nella [parte 2](https://docs.alchemy.com/docs/interacting-with-a-smart-contract) di questo tutorial vedremo come interagire con il nostro contratto intelligente una volta distribuito qui, e nella [parte 3](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan) spiegheremo come pubblicarlo su Etherscan.
-Nella [parte 2](https://docs.alchemy.com/docs/interacting-with-a-smart-contract) di questo tutorial, esamineremo come possiamo interagire con il nostro contratto intelligente una volta distribuito e, nella [parte 3](https://docs.alchemy.com/docs/submitting-your-smart-contract-to-etherscan), copriremo come pubblicarlo su Etherscan.
+Se hai domande in qualsiasi momento, sentiti libero di contattarci nel [Discord di Alchemy](https://discord.gg/gWuC7zB)!
-Se in qualsiasi momento hai domande, non esitare a contattarci nel [Discord di Alchemy](https://discord.gg/gWuC7zB)!
+## Passaggio 1: Connettiti alla rete Ethereum {#step-1}
-## Fase 1: connettersi alla rete di Ethereum {#step-1}
+Ci sono molti modi per fare richieste alla catena di Ethereum. Per semplicità, useremo un account gratuito su Alchemy, una piattaforma per sviluppatori blockchain e API che ci consente di comunicare con la catena di Ethereum senza dover eseguire i nostri nodi. La piattaforma dispone anche di strumenti per sviluppatori per il monitoraggio e l'analisi che sfrutteremo in questo tutorial per capire cosa succede dietro le quinte nella distribuzione del nostro contratto intelligente. Se non hai già un account Alchemy, [puoi registrarti gratuitamente qui](https://dashboard.alchemy.com/signup).
-Esistono molti modi per effettuare richieste alla catena di Ethereum. Per semplicità, ci serviremo di un conto gratuito su Alchemy, una piattaforma per sviluppatori di blockchain e API che ci consentirà di comunicare con la catena di Ethereum senza dover operare i nostri nodi. La piattaforma offre anche strumenti di analisi e monitoraggio di cui ci serviremo in questo tutorial per comprendere al meglio l'andamento della distribuzione del nostro smart contract. Se non possiedi già un conto di Alchemy, [puoi iscriverti gratuitamente qui](https://dashboard.alchemyapi.io/signup).
+## Passaggio 2: Crea la tua app (e la chiave API) {#step-2}
-## Fase 2: crea la tua app (e chiave API) {#step-2}
+Una volta creato un account Alchemy, puoi generare una chiave API creando un'app. Questo ci consentirà di fare richieste alla rete di test Sepolia. Se non hai familiarità con le reti di test, dai un'occhiata a [questa pagina](/developers/docs/networks/).
-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 Goerli. Se non hai familiarità con le reti di prova, dai un'occhiata a [questa pagina](/developers/docs/networks/).
+1. Naviga alla pagina "Create new app" (Crea nuova app) nella tua Dashboard di Alchemy selezionando "Select an app" (Seleziona un'app) nella barra di navigazione e cliccando su "Create new app"
-1. Vai alla pagina “Crea App” nella tua dashboard di Alchemy passando su “App” nella barra di navigazione e cliccando “Crea App”
+
-
+2. Dai un nome alla tua app "Hello World", offri una breve descrizione e scegli un caso d'uso, ad es. "Infra & Tooling". Successivamente, cerca "Ethereum" e seleziona la rete.
-2. Denomina la tua app "Ciao Mondo", offri una breve descrizione, seleziona "Staging" per l'Ambiente (utilizzato per la contabilità della tua app) e scegli "Goerli" per la tua rete.
+
-
+3. Clicca su "Next" (Avanti) per procedere, poi su "Create app" (Crea app) e il gioco è fatto! La tua app dovrebbe apparire nel menu a discesa della barra di navigazione, con una chiave API disponibile per essere copiata.
-3. Clicca “Create app” ed è tutto! La tua app dovrebbe apparire nella tabella sottostante.
+## Passaggio 3: Crea un account Ethereum (indirizzo) {#step-3}
-## Fase 3: Crea un conto di Ethereum (indirizzo) {#step-3}
+Abbiamo bisogno di un account Ethereum per inviare e ricevere transazioni. Per questo tutorial, useremo MetaMask, un portafoglio virtuale nel browser utilizzato per gestire l'indirizzo del tuo account Ethereum. Maggiori informazioni sulle [transazioni](/developers/docs/transactions/).
-Per inviare e ricevere le transazioni, necessitiamo di un conto di Ethereum. Per questo tutorial, useremo MetaMask, un portafoglio virtuale nel browser per gestire l'indirizzo del tuo conto di Ethereum. Maggiori informazioni sulle [transazioni](/developers/docs/transactions/).
+Puoi scaricare MetaMask e creare un account Ethereum gratuitamente [qui](https://metamask.io/download). Quando crei un account, o se ne hai già uno, assicurati di passare alla rete di test "Sepolia" utilizzando il menu a discesa della rete (in modo da non avere a che fare con denaro reale).
-Puoi scaricare e creare gratuitamente un conto di MetaMask [qui](https://metamask.io/download). Quando crei un account, o se ne possiedi già uno, assicurati di passare alla "rete di prova di Goerli" in alto a destra (così da non avere a che fare con denaro reale).
+Se non vedi Sepolia nell'elenco, vai nel menu, poi su Advanced (Avanzate) e scorri verso il basso per attivare "Show test networks" (Mostra reti di test). Nel menu di selezione della rete, scegli la scheda "Custom" (Personalizzata) per trovare un elenco di reti di test e seleziona "Sepolia".
-
+
-## Fase 4: aggiungi ether da un Faucet {#step-4}
+## Passaggio 4: Aggiungi ether da un rubinetto {#step-4}
-Per poter distribuire il nostro contratto intelligente alla rete di prova, avremo bisogno di degli ETH finti. Per ottenere degli ETH, puoi andare al [faucet di Goerli](https://goerlifaucet.com/), accedere al tuo conto di Alchemy e inserire l'indirizzo del tuo portafoglio, cliccando poi su "Inviami gli ETH". Potrebbe volerci del tempo per ricevere i tuoi ETH finti, a causa del traffico della rete. (Al momento della scrittura di questo tutorial, ci sono voluti circa 30 minuti.) Dovresti vedere i tuoi ETH nel tuo conto di Metamask dopo qualche minuto!
+Per distribuire il nostro contratto intelligente sulla rete di test, avremo bisogno di alcuni finti ETH. Per ottenere ETH di Sepolia puoi andare ai [dettagli della rete Sepolia](/developers/docs/networks/#sepolia) per visualizzare un elenco di vari rubinetti. Se uno non funziona, provane un altro poiché a volte possono esaurirsi. Potrebbe volerci del tempo per ricevere i tuoi finti ETH a causa del traffico di rete. Dovresti vedere gli ETH nel tuo account MetaMask subito dopo!
-## Fase 5: controlla il saldo {#step-5}
+## Passaggio 5: Controlla il tuo saldo {#step-5}
-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 nostro portafoglio. Dopo aver inserito l'indirizzo del tuo conto di MetaMask e aver cliccato su “Invia Richiesta”, dovresti vedere una risposta come questa:
+Per verificare che il nostro saldo sia presente, facciamo una richiesta [eth_getBalance](/developers/docs/apis/json-rpc/#eth_getbalance) utilizzando lo [strumento composer di Alchemy](https://sandbox.alchemy.com/?network=ETH_SEPOLIA&method=eth_getBalance&body.id=1&body.jsonrpc=2.0&body.method=eth_getBalance&body.params%5B0%5D=&body.params%5B1%5D=latest). Questo restituirà la quantità di ETH nel nostro portafoglio. Dopo aver inserito l'indirizzo del tuo account MetaMask e cliccato su "Send Request" (Invia richiesta), dovresti vedere una risposta come questa:
```json
{ "jsonrpc": "2.0", "id": 0, "result": "0x2B5E3AF16B1880000" }
```
-> **NOTA:** questo risultato è in wei non in ETH. Wei è usato come taglio più piccolo dell'ether. La conversione da wei a ETH è: 1 eth = 1018 wei. Quindi se convertiamo 0x2B5E3AF16B1880000 in decimali, otteniamo 5\*10¹⁸, pari a 5 ETH.
+> **NOTA:** Questo risultato è in wei, non in ETH. Il wei è utilizzato come la più piccola denominazione di ether. La conversione da wei a ETH è: 1 eth = 1018 wei. Quindi, se convertiamo 0x2B5E3AF16B1880000 in decimale otteniamo 5\*10¹⁸ che equivale a 5 ETH.
>
-> Meno male! I nostri soldi finti ci sono tutti
-Non eseguire il commit di .env! Assicurati di non condividere o esporre mai il tuo file .env con nessuno, poiché così facendo comprometteresti i tuoi segreti. Se stai usando il controllo di versione, aggiungi il tuo .env a un file gitignore.
+Non committare .env! Assicurati di non condividere o esporre mai il tuo file .env a nessuno, poiché così facendo comprometti i tuoi segreti. Se stai utilizzando il controllo di versione, aggiungi il tuo .env a un file gitignore.
-## Fase 12: installa Ethers.js {#step-12-install-ethersjs}
+## Passaggio 12: Installa Ethers.js {#step-12-install-ethersjs}
-Ethers.js è una libreria che rende più facile interagire ed effettuare richieste a Ethereum tramite wrapping dei [metodi JSON-RPC standard](/developers/docs/apis/json-rpc/) con altri metodi più facili da usare.
+Ethers.js è una libreria che semplifica l'interazione e l'esecuzione di richieste a Ethereum avvolgendo i [metodi JSON-RPC standard](/developers/docs/apis/json-rpc/) con metodi più intuitivi.
-Hardhat rende davvero facile integrare [Plugin](https://hardhat.org/plugins/) per strumenti e funzionalità aggiuntive. Sfrutteremo il [plugin di Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) per la distribuzione del contratto ([Ethers.js](https://github.com/ethers-io/ethers.js/) ha dei metodi di distribuzione del contratto molto puliti).
+Hardhat rende facilissimo integrare i [Plugin](https://hardhat.org/plugins/) per strumenti aggiuntivi e funzionalità estese. Sfrutteremo il [plugin Ethers](https://hardhat.org/docs/plugins/official-plugins#hardhat-ethers) per la distribuzione dei contratti ([Ethers.js](https://github.com/ethers-io/ethers.js/) ha alcuni metodi di distribuzione dei contratti estremamente puliti).
-Nella cartella del tuo progetto digita:
+Nella directory del tuo progetto digita:
```
npm install --save-dev @nomiclabs/hardhat-ethers "ethers@^5.0.0"
```
-Avremo bisogno di ethers anche nel nostro `hardhat.config.js` nella prossima fase.
+Richiederemo anche ethers nel nostro `hardhat.config.js` nel passaggio successivo.
-## Fase 13: aggiorna hardhat.config.js {#step-13-update-hardhatconfigjs}
+## Passaggio 13: Aggiorna hardhat.config.js {#step-13-update-hardhatconfigjs}
-Finora abbiamo aggiunto diverse dipendenze e plugin, ora dobbiamo aggiornare `hardhat.config.js` in modo che il nostro progetto li riconosca tutti.
+Finora abbiamo aggiunto diverse dipendenze e plugin, ora dobbiamo aggiornare `hardhat.config.js` in modo che il nostro progetto li conosca tutti.
-Aggiorna il tuo `hardhat.config.js` affinché somigli a questo:
+Aggiorna il tuo `hardhat.config.js` in modo che appaia così:
```
require('dotenv').config();
@@ -278,10 +267,10 @@ const { API_URL, PRIVATE_KEY } = process.env;
*/
module.exports = {
solidity: "0.7.3",
- defaultNetwork: "goerli",
+ defaultNetwork: "sepolia",
networks: {
hardhat: {},
- goerli: {
+ sepolia: {
url: API_URL,
accounts: [`0x${PRIVATE_KEY}`]
}
@@ -289,9 +278,9 @@ module.exports = {
}
```
-## Fase 14: compila il contratto {#step-14-compile-our-contracts}
+## Passaggio 14: Compila il nostro contratto {#step-14-compile-our-contracts}
-Per assicurarti che tutto funzioni fino a questo punto, compila il contratto. L'attività di `compilazione` è una delle attività integrate di hardhat.
+Per assicurarci che tutto funzioni finora, compiliamo il nostro contratto. L'attività `compile` è una delle attività integrate di hardhat.
Dalla riga di comando esegui:
@@ -299,13 +288,13 @@ Dalla riga di comando esegui:
npx hardhat compile
```
-Potresti ottenere un avviso sull'assenza `nel file sorgente dell'identificativo della licenza SPDX`, ma non preoccupartene, si spera che tutto il resto funzioni! Altrimenti, puoi sempre inviare un messaggio nel [Discord di Alchemy](https://discord.gg/u72VCg3).
+Potresti ricevere un avviso su `SPDX license identifier not provided in source file`, ma non c'è bisogno di preoccuparsi: si spera che tutto il resto vada bene! In caso contrario, puoi sempre inviare un messaggio nel [Discord di Alchemy](https://discord.gg/u72VCg3).
-## Fase 15: scrivi lo script di distribuzione {#step-15-write-our-deploy-scripts}
+## Passaggio 15: Scrivi il nostro script di distribuzione {#step-15-write-our-deploy-scripts}
-Ora che il nostro contratto è scritto e il nostro file di configurazione è pronto, è il momento di scrivere lo script di distribuzione del contratto.
+Ora che il nostro contratto è scritto e il nostro file di configurazione è pronto, è il momento di scrivere il nostro script di distribuzione del contratto.
-Vai alla cartella `script/` e crea un nuovo file chiamato `deploy.js`, aggiungendo i seguenti contenuti:
+Naviga nella cartella `scripts/` e crea un nuovo file chiamato `deploy.js`, aggiungendovi i seguenti contenuti:
```
async function main() {
@@ -323,48 +312,49 @@ main()
});
```
-Nel suo [tutorial sui Contratti](https://hardhat.org/tutorial/testing-contracts.html#writing-tests) hardhat spiega in modo eccellente cosa fa ognuna di queste righe di codice nel loro, quindi riportiamo qui le loro spiegazioni.
+Hardhat fa un lavoro straordinario nello spiegare cosa fa ciascuna di queste righe di codice nel loro [tutorial sui Contratti](https://hardhat.org/tutorial/testing-contracts.html#writing-tests), abbiamo adottato le loro spiegazioni qui.
```
const HelloWorld = await ethers.getContractFactory("HelloWorld");
```
-Un `ContractFactory` su ethers.js è un'astrazione usata per distribuire nuovi smart contract, quindi `HelloWorld` qui è una fabbrica di istanze del nostro contratto hello world. Usando il plugin `hardhat-ethers`, le istanze `ContractFactory` e `Contract` sono connesse di default al primo firmatario.
+Una `ContractFactory` in ethers.js è un'astrazione utilizzata per distribuire nuovi contratti intelligenti, quindi `HelloWorld` qui è una fabbrica per le istanze del nostro contratto hello world. Quando si utilizza il plugin `hardhat-ethers`, le istanze `ContractFactory` e `Contract` sono connesse al primo firmatario per impostazione predefinita.
```
const hello_world = await HelloWorld.deploy();
```
-Chiamare `deploy()` su un `ContractFactory` avvierà la distribuzione e restituirà un `Promise` che si risolve in un `Contract`. Questo è l'oggetto che ha un metodo per ciascuna delle funzioni del nostro smart contract.
+Chiamare `deploy()` su una `ContractFactory` avvierà la distribuzione e restituirà una `Promise` che si risolve in un `Contract`. Questo è l'oggetto che ha un metodo per ciascuna delle funzioni del nostro contratto intelligente.
-## Fase 16: distribuisci il contratto {#step-16-deploy-our-contract}
+## Passaggio 16: Distribuisci il nostro contratto {#step-16-deploy-our-contract}
-Siamo finalmente pronti a distribuire il nostro smart contract! Vai alla riga di comando ed esegui:
+Siamo finalmente pronti per distribuire il nostro contratto intelligente! Naviga nella riga di comando ed esegui:
```
-npx hardhat run scripts/deploy.js --network goerli
+npx hardhat run scripts/deploy.js --network sepolia
```
-Vorrai poi vedere qualcosa del genere:
+Dovresti quindi vedere qualcosa del genere:
```
Contract deployed to address: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570
```
-Se andiamo all'[Etherscan di Goerli](https://goerli.etherscan.io/) e cerchiamo l'indirizzo del nostro contratto, dovremmo poter vedere che è stato distribuito correttamente. La transazione somiglierà a questa:
+Se andiamo su [Sepolia etherscan](https://sepolia.etherscan.io/) e cerchiamo l'indirizzo del nostro contratto, dovremmo essere in grado di vedere che è stato distribuito con successo. La transazione apparirà più o meno così:
-
+
-L'indirizzo `From` dovrebbe corrispondere all'indirizzo del tuo conto di MetaMask e, l'indirizzo To indicherà la "Creazione del Contratto"; ma cliccando sulla transazione, vedremo l'indirizzo del nostro contratto nel campo `To`:
+L'indirizzo `From` dovrebbe corrispondere all'indirizzo del tuo account MetaMask e l'indirizzo To dirà "Contract Creation" (Creazione del contratto), ma se clicchiamo sulla transazione vedremo l'indirizzo del nostro contratto nel campo `To`:
-
+
-Congratulazioni! Hai appena distribuito uno smart contract nella chain di Ethereum
+Congratulazioni! Hai appena distribuito un contratto intelligente sulla catena di Ethereum 🎉
-Per capire cosa sta succedendo, andiamo alla scheda Explorer nel nostro [dashboard di Alchemy](https://dashboard.alchemyapi.io/explorer). Se hai diverse app di Alchemy, assicurati di filtrare per app e selezionare "Hello World". 
+Per capire cosa succede dietro le quinte, navighiamo nella scheda Explorer nella nostra [dashboard di Alchemy](https://dashboard.alchemyapi.io/explorer). Se hai più app Alchemy, assicurati di filtrare per app e seleziona "Hello World".
+
-Qui vedrai numerose chiamate a JSON-RPC che Hardhat/Ethers ha effettuato per noi quando abbiamo chiamato la funzione `.deploy()`. Due funzioni importanti da chiamare qui sono [`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction), che è la richiesta per scrivere effettivamente il nostro contratto sulla catena di Goerli, e [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash), che è una richiesta di leggere le informazioni sulla nostra transazione, dato l'hash (uno schema tipico nelle transazioni). Per saperne di più sull'invio delle transazioni, dai un'occhiata a questo tutorial [ sull'invio di transazioni usando web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)
+Qui vedrai una manciata di chiamate JSON-RPC che Hardhat/Ethers ha effettuato dietro le quinte per noi quando abbiamo chiamato la funzione `.deploy()`. Due importanti da segnalare qui sono [`eth_sendRawTransaction`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-send-raw-transaction), che è la richiesta per scrivere effettivamente il nostro contratto sulla catena Sepolia, e [`eth_getTransactionByHash`](https://www.alchemy.com/docs/node/abstract/abstract-api-endpoints/eth-get-transaction-by-hash) che è una richiesta per leggere informazioni sulla nostra transazione dato l'hash (un modello tipico quando si effettuano transazioni). Per saperne di più sull'invio di transazioni, dai un'occhiata a questo tutorial sull'[invio di transazioni utilizzando Web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/)
-Questo è tutto per la parte 1 di questo tutorial, nella parte 2, [interagiremo realmente con il nostro smart contract](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#part-2-interact-with-your-smart-contract) aggiornando il nostro messaggio iniziale e nella parte 3 [pubblicheremo il nostro smart contract su Etherscan](https://docs.alchemyapi.io/alchemy/tutorials/hello-world-smart-contract#optional-part-3-publish-your-smart-contract-to-etherscan), così che tutti sapranno come interagire con esso.
+Questo è tutto per la parte 1 di questo tutorial, nella parte 2 [interagiremo effettivamente con il nostro contratto intelligente](https://www.alchemy.com/docs/interacting-with-a-smart-contract) aggiornando il nostro messaggio iniziale, e nella parte 3 [pubblicheremo il nostro contratto intelligente su Etherscan](https://www.alchemy.com/docs/submitting-your-smart-contract-to-etherscan) in modo che tutti sappiano come interagire con esso.
-**Vuoi saperne di più su Alchemy? Dai un'occhiata al nostro [sito web](https://alchemyapi.io/eth). Non vuoi mai perderti un aggiornamento? Iscriviti alla nostra newsletter [qui](https://www.alchemyapi.io/newsletter)! Assicurati anche di seguire il nostro [Twitter](https://twitter.com/alchemyplatform) e di unirti al nostro [Discord](https://discord.com/invite/u72VCg3)**.
+**Vuoi saperne di più su Alchemy? Dai un'occhiata al nostro [sito web](https://www.alchemy.com/eth). Non vuoi mai perderti un aggiornamento? Iscriviti alla nostra newsletter [qui](https://www.alchemy.com/newsletter)! Assicurati anche di unirti al nostro [Discord](https://discord.gg/u72VCg3).**
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/how-to-implement-an-erc721-market/index.md b/public/content/translations/it/developers/tutorials/how-to-implement-an-erc721-market/index.md
index 364904e4e08..a508b3df4fa 100644
--- a/public/content/translations/it/developers/tutorials/how-to-implement-an-erc721-market/index.md
+++ b/public/content/translations/it/developers/tutorials/how-to-implement-an-erc721-market/index.md
@@ -1,76 +1,72 @@
---
-title: Come implementare un market ERC-721
-description: Come mettere in vendita oggetti tokenizzati su bacheche di annunci decentralizzate
+title: Come implementare un mercato ERC-721
+description: Come mettere in vendita oggetti tokenizzati su una bacheca di annunci decentralizzata
author: "Alberto Cuesta Cañada"
-tags:
- - "smart contract"
- - "erc-721"
- - "Solidity"
- - "token"
+tags: ["contratti intelligenti", "erc-721", "Solidity", "token"]
skill: intermediate
-breadcrumb: "Mercato ERC-721"
+breadcrumb: Mercato ERC-721
lang: it
published: 2020-03-19
source: Hackernoon
sourceUrl: https://hackernoon.com/how-to-implement-an-erc721-market-1e1a32j9
---
-In questo articolo, ti mostrerò come sviluppare in Craigslist per la blockchain Ethereum.
+In questo articolo, ti mostrerò come programmare Craigslist per la blockchain di Ethereum.
-Prima di Gumtree, Ebay e Craigstlist, le bacheche di annunci erano più che altro di sughero o carta. C'erano bacheche nei corridoi delle scuole, sui giornali, sui lampioni o sulle vetrine.
+Prima di Gumtree, Ebay e Craigslist, le bacheche di annunci erano per lo più fatte di sughero o carta. C'erano bacheche di annunci nei corridoi delle scuole, sui giornali, sui lampioni, nelle vetrine dei negozi.
-Con Internet è cambiato tutto. Il numero di persone che potevano vedere una determinata bacheca di annunci si è moltiplicato a livello esponenziale. Di conseguenza, i mercati che rappresentano sono diventati molto più efficienti e si rivolgono a livello globale. Ebay è un business enorme che ha le sue origini proprio in queste bacheche di annunci fisiche.
+Tutto questo è cambiato con Internet. Il numero di persone che potevano vedere una specifica bacheca di annunci si è moltiplicato di molti ordini di grandezza. Con ciò, i mercati che rappresentano sono diventati molto più efficienti e sono scalati a dimensioni globali. Ebay è un'azienda enorme che affonda le sue origini in queste bacheche di annunci fisiche.
-Con la blockchain questi mercati sono destinati a cambiare di nuovo, vediamo come.
+Con la blockchain questi mercati sono destinati a cambiare ancora una volta, lascia che ti mostri come.
## Monetizzazione {#monetization}
-Il modello di business di una bacheca di annunci su blockchain pubblica sarà diverso da quello di Ebay e simili.
+Il modello di business di una bacheca di annunci su una blockchain pubblica dovrà essere diverso da quello di Ebay e compagnia.
-Prima di tutto, c'è la [questione della decentralizzazione](/developers/docs/web2-vs-web3/). Le piattaforme esistenti devono mantenere i loro server. Una piattaforma decentralizzata è gestita dai suoi utenti, quindi il costo per tenere attiva la piattaforma base scende a zero per il proprietario della piattaforma.
+Innanzitutto, c'è [l'aspetto della decentralizzazione](/developers/docs/web2-vs-web3/). Le piattaforme esistenti devono mantenere i propri server. Una piattaforma decentralizzata è mantenuta dai suoi utenti, quindi il costo di gestione della piattaforma principale scende a zero per il proprietario della piattaforma.
-Poi c'è il front end, ossia il sito Web o l'interfaccia che dà accesso alla piattaforma. Qua ci sono molte opzioni. Il proprietario della piattaforma può limitare l'accesso e costringere tutti a usare la propria interfaccia, imponendo un costo di utilizzo. I proprietari della piattaforma possono anche decidere di lasciare libero l'accesso (potere al popolo!) e di permettere che chiunque crei interfacce per la piattaforma. Oppure, potrebbero decidere qualsiasi altro tipo di approccio tra questi due estremi.
+Poi c'è il front-end, il sito web o l'interfaccia che dà accesso alla piattaforma. Qui ci sono molte opzioni. I proprietari della piattaforma possono limitare l'accesso e costringere tutti a usare la loro interfaccia, addebitando una commissione. I proprietari della piattaforma possono anche decidere di aprire l'accesso (Potere al Popolo!) e lasciare che chiunque costruisca interfacce per la piattaforma. Oppure i proprietari potrebbero decidere per un approccio a metà tra questi estremi.
-_Chi si occupa di affari e ha più visione di me saprà come monetizzare tutto questo. Tutto quello che io riesco a capire è che questo è diverso dallo status quo e probabilmente redditizio._
+_I leader aziendali con più visione di me sapranno come monetizzare tutto questo. Tutto ciò che vedo è che questo è diverso dallo status quo e probabilmente redditizio._
-In più, c'è la questione dell'automazione e dei pagamenti. Alcuni articoli si prestano molto ad essere [tokenizzati in modo efficace](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com) e scambiati in una bacheca di annunci. Le risorse tokenizzate sono facilmente trasferibili su una blockchain. Metodi di pagamento altamente complessi possono essere facilmente implementati su una blockchain.
+Inoltre, c'è l'aspetto dell'automazione e dei pagamenti. Alcune cose possono essere [tokenizzate in modo molto efficace](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com) e scambiate in una bacheca di annunci. Gli asset tokenizzati sono facilmente trasferibili in una blockchain. Metodi di pagamento altamente complessi possono essere facilmente implementati in una blockchain.
-Sento odore di business. Una bacheca di annunci senza costi di gestione può facilmente essere implementata con complessi percorsi di pagamento inclusi in ogni transazione. Sono sicuro che qualcuno verrà fuori con qualche idea su come utilizzare tutto questo.
+Sento odore di un'opportunità di business qui. Una bacheca di annunci senza costi di gestione può essere facilmente implementata, con percorsi di pagamento complessi inclusi in ogni transazione. Sono sicuro che a qualcuno verrà in mente un'idea su come utilizzarla.
-Io sono felice di occuparmi della programmazione. Diamo un'occhiata al codice.
+Io sono solo felice di costruirla. Diamo un'occhiata al codice.
## Implementazione {#implementation}
-Un po' di tempo fa abbiamo iniziato un [repository open source](https://github.com/HQ20/contracts?ref=hackernoon.com) con implementazioni di esempio e altre cose interessanti, consiglio di dare una sbirciata.
+Qualche tempo fa abbiamo avviato un [repository open source](https://github.com/HQ20/contracts?ref=hackernoon.com) con implementazioni di esempi di casi aziendali e altre chicche, dacci un'occhiata.
-Il codice di questa [bacheca di annunci Ethereum](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com) è qui, potete usarlo e anche abusarne. Occhio solo che non è stato verificato e quindi fate molta attenzione prima di metterci dei soldi.
+Il codice per questa [Bacheca di Annunci di Ethereum](https://github.com/HQ20/contracts/tree/master/contracts/classifieds?ref=hackernoon.com) è lì, per favore usalo e abusane. Tieni solo presente che il codice non è stato verificato e devi fare la tua due diligence prima di investirci del denaro.
-Le basi della bacheca non sono difficili. Tutti gli annunci della bacheca saranno semplicemente uno struct con pochi campi:
+Le basi della bacheca non sono complesse. Tutti gli annunci nella bacheca saranno solo una struct con alcuni campi:
```solidity
struct Trade {
address poster;
uint256 item;
uint256 price;
- bytes32 status; // Open, Executed, Cancelled
+ bytes32 status; // Aperto, Eseguito, Annullato
}
```
-Supponiamo che ci sia qualcuno che pubblica l'annuncio. Un oggetto in vendita. Un prezzo per l'oggetto. Lo stato dello scambio che può essere aperto, chiuso o annullato.
+Quindi c'è qualcuno che pubblica l'annuncio. Un oggetto in vendita. Un prezzo per l'oggetto. Lo stato dello scambio che può essere aperto, eseguito o annullato.
-Tutti questi scambi saranno tenuti in un mapping. Perché tutto in Solidity sembra essere un mapping. E anche perché è comodo.
+Tutti questi scambi saranno conservati in una mappatura. Perché tutto in Solidity sembra essere una mappatura. Anche perché è conveniente.
```solidity
mapping(uint256 => Trade) public trades;
```
-Usare un mapping significa solo che dobbiamo trovare un ID per ogni annuncio prima di pubblicarlo e che dovremo conoscere l'ID di un annuncio prima di poter lavorare su di esso. Ci sono molti modi per affrontare questo problema sia con gli Smart Contract che nel front end. Chiedi se ti servono delle indicazioni.
+Usare una mappatura significa solo che dobbiamo inventare un ID per ogni annuncio prima di pubblicarlo, e avremo bisogno di conoscere l'ID di un annuncio prima di potervi operare. Ci sono molti modi per affrontare questo problema sia nel contratto intelligente che nel front-end. Chiedi pure se hai bisogno di qualche dritta.
-La seconda questione è capire quali sono gli elementi con cui lavoriamo e qual è la valuta che deve essere usata per pagare la transazione.
+Poi sorge la domanda su quali siano quegli oggetti di cui ci occupiamo, e quale sia questa valuta utilizzata per pagare la transazione.
-Per gli elementi, chiederemo solo che implementino l'interfaccia [ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com), che è semplicemente un modo per rappresentare gli oggetti del mondo reale su una blockchain, anche se [funziona meglio con le risorse digitali](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com). Specificheremo il nostro contratto ERC271 nel costruttore, dicendo che ogni risorsa della nostra bacheca di annunci deve prima essere tokenizzata.
+Per gli oggetti, chiederemo semplicemente che implementino l'interfaccia [ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/IERC721.sol?ref=hackernoon.com), che in realtà è solo un modo per rappresentare oggetti del mondo reale in una blockchain, sebbene [funzioni meglio con gli asset digitali](https://hackernoon.com/tokenization-of-digital-assets-g0ffk3v8s?ref=hackernoon.com). Specificheremo il nostro contratto ERC721 nel costruttore, il che significa che qualsiasi asset nella nostra bacheca di annunci deve essere stato tokenizzato in precedenza.
-Per i pagamenti, faremo qualcosa di simile. La maggior parte dei progetti di blockchain definisce la propria criptovaluta [ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com). Altri preferiscono usarne una popolare come DAI. In questa bacheca di annunci, dovrai solo decidere al momento della creazione quale sarà la tua valuta. Facile.
+Per i pagamenti, faremo qualcosa di simile. La maggior parte dei progetti blockchain definisce la propria criptovaluta [ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol?ref=hackernoon.com). Altri preferiscono usarne una tradizionale come DAI. In questa bacheca di annunci, devi solo decidere al momento della costruzione quale sarà la tua valuta. Facile.
```solidity
constructor (
@@ -82,9 +78,9 @@ constructor (
}
```
-Ci siamo quasi. Abbiamo annunci, oggetti da scambiare e una valuta per i pagamenti. Creare un annuncio significa mettere un oggetto in deposito per mostrare sia che tu lo possiedi, sia che non lo hai pubblicato due volte, magari in una bacheca diversa.
+Ci stiamo arrivando. Abbiamo annunci, oggetti da scambiare e una valuta per i pagamenti. Creare un annuncio significa mettere un oggetto in garanzia (escrow) per dimostrare sia che lo possiedi sia che non lo hai pubblicato due volte, possibilmente in una bacheca diversa.
-Il codice qui sotto fa esattamente questo. Mette l'oggetto in deposito, crea l'annuncio e fa un po' di altri lavoretti.
+Il codice qui sotto fa esattamente questo. Mette l'oggetto in garanzia, crea l'annuncio, fa un po' di pulizia.
```solidity
function openTrade(uint256 _item, uint256 _price)
@@ -102,7 +98,7 @@ function openTrade(uint256 _item, uint256 _price)
}
```
-Accettare lo scambio significa scegliere un annuncio (scambio), pagare il prezzo, ricevere l'oggetto. Il codice qui sotto recupera uno scambio. Controlla se è disponibile. Paga l'oggetto. Recupera l'oggetto. Aggiorna l'annuncio.
+Accettare lo scambio significa scegliere un annuncio (scambio), pagare il prezzo, ricevere l'oggetto. Il codice qui sotto recupera uno scambio. Controlla che sia disponibile. Paga l'oggetto. Recupera l'oggetto. Aggiorna l'annuncio.
```solidity
function executeTrade(uint256 _trade)
@@ -117,9 +113,9 @@ function executeTrade(uint256 _trade)
}
```
-Infine abbiamo un'opzione che permette al venditore di uscire da uno scambio prima che l'acquirente lo accetti. In alcuni modelli, invece, gli annunci rimangono online per un determinato periodo di tempo, prima di scadere. La scelta è tua, a seconda di come funziona il tuo marketplace.
+Infine, abbiamo un'opzione per i venditori di ritirarsi da uno scambio prima che un acquirente lo accetti. In alcuni modelli, gli annunci rimarrebbero invece attivi per un periodo di tempo prima di scadere. A te la scelta, a seconda del design del tuo mercato.
-Il codice è molto simile a quello usato per eseguire uno scambio, solo che qua non c'è moneta che passa di mano e l'oggetto torna indietro a chi ha pubblicato l'annuncio.
+Il codice è molto simile a quello utilizzato per eseguire uno scambio, solo che non c'è alcun passaggio di valuta e l'oggetto torna a chi ha pubblicato l'annuncio.
```solidity
function cancelTrade(uint256 _trade)
@@ -137,14 +133,14 @@ function cancelTrade(uint256 _trade)
}
```
-Ecco qua. Siamo giunti alla fine dell'implementazione. È sorprendente come alcuni concetti di business siano compatti quando vengono espressi con codice, e questo è uno di questi esempi. Guarda il contratto completo [nel nostro repo](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol).
+Questo è tutto. Sei arrivato alla fine dell'implementazione. È abbastanza sorprendente quanto siano compatti alcuni concetti aziendali quando espressi in codice, e questo è uno di quei casi. Controlla il contratto completo [nel nostro repo](https://github.com/HQ20/contracts/blob/master/contracts/classifieds/Classifieds.sol).
## Conclusione {#conclusion}
-Le bacheche di annunci sono una configurazione di mercato comune che ha preso piede rapidamente con Internet, diventando un modello di business incredibilmente popolare, con alcuni monopoli che si sono accaparrati il segmento di mercato.
+Le bacheche di annunci sono una configurazione di mercato comune che è scalata massicciamente con Internet, diventando un modello di business estremamente popolare con pochi vincitori monopolistici.
-Sono anche uno strumento facile da replicare in un ambiente blockchain, con caratteristiche molto specifiche che permetteranno di sfidare i giganti attuali.
+Le bacheche di annunci si rivelano anche uno strumento facile da replicare in un ambiente blockchain, con caratteristiche molto specifiche che renderanno possibile una sfida ai giganti esistenti.
-In questo articolo ho fatto un tentativo di collegare la realtà delle bacheche di annunci con l'implementazione tecnologica. Queste conoscenze, con le giuste capacità, dovrebbero aiutare a creare una vision e una roadmap per l'implementazione.
+In questo articolo, ho fatto un tentativo di collegare la realtà aziendale di un business di bacheche di annunci con l'implementazione tecnologica. Questa conoscenza dovrebbe aiutarti a creare una visione e un piano d'azione per l'implementazione se hai le giuste competenze.
-Come sempre, se vuoi creare qualcosa di interessante e vorresti qualche consiglio, [scrivimi](https://albertocuesta.es/)! Sono sempre felice di dare una mano.
+Come sempre, se hai intenzione di costruire qualcosa di divertente e gradiresti qualche consiglio, per favore [scrivimi](https://albertocuesta.es/)! Sono sempre felice di aiutare.
\ No newline at end of file
diff --git a/public/content/translations/it/developers/tutorials/how-to-mint-an-nft/index.md b/public/content/translations/it/developers/tutorials/how-to-mint-an-nft/index.md
index d41082d813d..cdf46213ab2 100644
--- a/public/content/translations/it/developers/tutorials/how-to-mint-an-nft/index.md
+++ b/public/content/translations/it/developers/tutorials/how-to-mint-an-nft/index.md
@@ -1,39 +1,37 @@
---
-title: Come coniare un NFT (Parte 2/3 della Serie di tutorial sugli NFT)
-description: Questo tutorial descrive come coniare un NFT sulla Blockchain di Ethereum usando il nostro contratto intelligente e Web3.
+title: Come coniare un NFT (Parte 2/3 della serie di tutorial sugli NFT)
+description: Questo tutorial descrive come coniare un NFT sulla blockchain di Ethereum usando il nostro contratto intelligente e Web3.
author: "Sumi Mudgil"
-tags:
- - "ERC-721"
- - "alchemy"
- - "solidity"
- - "contratti intelligenti"
+tags: ["ERC-721", "Alchemy", "Solidity", "contratti intelligenti"]
skill: beginner
-breadcrumb: "Coniare un NFT"
+breadcrumb: Coniare un NFT
lang: it
published: 2021-04-22
---
-[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html): $69 milioni [3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b): $11 milioni [Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens): $6 milioni
+[Beeple](https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html): 69 milioni di dollari
+[3LAU](https://www.forbes.com/sites/abrambrown/2021/03/03/3lau-nft-nonfungible-tokens-justin-blau/?sh=5f72ef64643b): 11 milioni di dollari
+[Grimes](https://www.theguardian.com/music/2021/mar/02/grimes-sells-digital-art-collection-non-fungible-tokens): 6 milioni di dollari
-Tutti loro hanno coniato i propri NFT utilizzando la potente API di Alchemy. In questo tutorial ti insegneremo come fare lo stesso in meno di 10 minuti.
+Tutti loro hanno coniato i propri NFT usando la potente API di Alchemy. In questo tutorial, ti insegneremo come fare lo stesso in \<10 minuti.
-"Coniare un NFT" è l'atto di pubblicare un'istanza unica del tuo token ERC-721 sulla blockchain. Usando il nostro contratto intelligente dalla [Parte 1 di questa serie di tutorial sugli NFT](/developers/tutorials/how-to-write-and-deploy-an-nft/), dimostriamo le nostre abilità di Web3 e coniamo un NFT. Alla fine di questo tutorial, potrai coniare tutti gli NFT che desideri (e che può permettersi il tuo portafoglio)!
+"Coniare un NFT" è l'atto di pubblicare un'istanza unica del tuo token ERC-721 sulla blockchain. Usando il nostro contratto intelligente dalla [Parte 1 di questa serie di tutorial sugli NFT](/developers/tutorials/how-to-write-and-deploy-an-nft/), mettiamo in mostra le nostre abilità con Web3 e coniamo un NFT. Alla fine di questo tutorial, sarai in grado di coniare tutti gli NFT che il tuo cuore (e il tuo portafoglio) desidera!
Iniziamo!
-## Fase 1: installa Web3 {#install-web3}
+## Passaggio 1: Installare Web3 {#install-web3}
-Se hai seguito il primo tutorial sulla creazione del tuo contratto intelligente di NFT, hai già esperienza usando Ethers.js. Web3 è simile a Ethers, trattandosi di una libreria usata per effettuare più facilmente richieste di creazione alla Blockchain di Ethereum. In questo tutorial, useremo [Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3), una libreria Web3 migliorata che offre tentativi automatici e robusto supporto a WebSocket.
+Se hai seguito il primo tutorial sulla creazione del tuo contratto intelligente per NFT, hai già esperienza nell'uso di Ethers.js. Web3 è simile a Ethers, in quanto è una libreria usata per facilitare la creazione di richieste alla blockchain di [Ethereum](/). In questo tutorial useremo [Alchemy Web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3), che è una libreria Web3 migliorata che offre tentativi automatici e un solido supporto per WebSocket.
-Nella cartella home del tuo progetto, esegui:
+Nella directory principale del tuo progetto esegui:
```
npm install @alch/alchemy-web3
```
-## Fase 2: crea un file `mint-nft.js` {#create-mintnftjs}
+## Passaggio 2: Creare un file `mint-nft.js` {#create-mintnftjs}
-Nella tua cartella di script, crea un `mint-nft.js` e aggiungi le seguenti righe di codice:
+All'interno della tua directory degli script, crea un file `mint-nft.js` e aggiungi le seguenti righe di codice:
```js
require("dotenv").config()
@@ -42,49 +40,49 @@ const { createAlchemyWeb3 } = require("@alch/alchemy-web3")
const web3 = createAlchemyWeb3(API_URL)
```
-## Fase 3: prendi l'ABI del tuo contratto {#contract-abi}
+## Passaggio 3: Ottenere l'ABI del tuo contratto {#contract-abi}
-L'ABI (Interfaccia Binaria dell'Applicazione) del nostro contratto è l'interfaccia per interagire con il nostro contratto intelligente. Puoi saperne di più sull'ABI dei contratti leggi [qui](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is). Hardhat genera automaticamente un'ABI e la salva nel file `MyNFT.json`. Per poterla usare, dovremo analizzare i contenuti aggiungendo le seguenti righe di codice al nostro `mint-nft.js`:
+L'ABI (Application Binary Interface) del nostro contratto è l'interfaccia per interagire con il nostro contratto intelligente. Puoi saperne di più sulle ABI dei contratti [qui](https://docs.alchemyapi.io/alchemy/guides/eth_getlogs#what-are-ab-is). Hardhat genera automaticamente un'ABI per noi e la salva nel file `MyNFT.json`. Per poterla usare dovremo analizzarne i contenuti aggiungendo le seguenti righe di codice al nostro file `mint-nft.js`:
```js
const contract = require("../artifacts/contracts/MyNFT.sol/MyNFT.json")
```
-Se vuoi vedere l'ABI, puoi stamparla nella tua console:
+Se vuoi vedere l'ABI puoi stamparla nella tua console:
```js
console.log(JSON.stringify(contract.abi))
```
-Per eseguire `mint-nft.js` e vedere l'ABI stampata alla console, vai alla console ed esegui:
+Per eseguire `mint-nft.js` e vedere la tua ABI stampata nella console, naviga nel tuo terminale ed esegui:
```js
node scripts/mint-nft.js
```
-## Fase 4: configura i metadati del tuo NFT usando IPFS {#config-meta}
+## Passaggio 4: Configurare i metadati per il tuo NFT usando IPFS {#config-meta}
-Se ti ricordi dal nostro tutorial nella Parte 1, la funzione del nostro contratto intelligente `mintNFT` prende un parametro tokenURl che dovrebbe risolversi a un documento JSON che descrive i metadati del NFT; che è ciò che porta realmente in vita lo NFT, consentendogli di avere proprietà configurabili, come un nome, una descrizione, un'immagine e altri attributi.
+Se ricordi dal nostro tutorial nella Parte 1, la nostra funzione del contratto intelligente `mintNFT` accetta un parametro tokenURI che dovrebbe risolversi in un documento JSON che descrive i metadati dell'NFT, che è in realtà ciò che dà vita all'NFT, permettendogli di avere proprietà configurabili, come un nome, una descrizione, un'immagine e altri attributi.
-> _Il Planetary File System (IPFS) è un protocollo decentralizzato e una rete peer-to-peer per memorizzare e condividere i dati in un file di sistema distribuito._
+> _L'Interplanetary File System (IPFS) è un protocollo decentralizzato e una rete peer-to-peer per l'archiviazione e la condivisione di dati in un file system distribuito._
-Useremo Pinata, una comoda API di IPFS e strumento per memorizzare la nostra risorsa NFT e i metadati, per essere sicuri che il nostro NFT sia realmente decentralizzato. Se non hai un conto di Pinata, registrane uno gratuito [qui](https://app.pinata.cloud) e completa i passaggi per verificare la tua email.
+Useremo Pinata, una comoda API e toolkit IPFS, per archiviare la risorsa e i metadati del nostro NFT per assicurarci che il nostro NFT sia veramente decentralizzato. Se non hai un account Pinata, registrati per un account gratuito [qui](https://app.pinata.cloud) e completa i passaggi per verificare la tua email.
-Una volta creato un conto:
+Una volta creato un account:
-- Vai alla pagina "File" e clicca il pulsante "Carica" blu in alto a sinistra alla pagina.
+- Naviga alla pagina "Files" e clicca sul pulsante blu "Upload" in alto a sinistra della pagina.
-- Carica un'immagine su Pinata, sarà la risorsa immagine del tuo NFT. Assegna alla risorsa il nome desideri
+- Carica un'immagine su Pinata: questa sarà la risorsa immagine per il tuo NFT. Sentiti libero di nominare la risorsa come preferisci
-- Dopo il caricamento, vedrai le informazioni del file nella tabella sulla pagina "File". Vedrai anche una colonna CID. Puoi copiare il CID cliccando il pulsante di copia accanto. Puoi visualizzare il tuo caricamento su: `https://gateway.pinata.cloud/ipfs/`. Puoi trovare l'immagine che abbiamo usato su IPFS [qui](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5), ad esempio.
+- Dopo il caricamento, vedrai le informazioni del file nella tabella sulla pagina "Files". Vedrai anche una colonna CID. Puoi copiare il CID cliccando sul pulsante di copia accanto ad esso. Puoi visualizzare il tuo caricamento su: `https://gateway.pinata.cloud/ipfs/`. Puoi trovare l'immagine che abbiamo usato su IPFS [qui](https://gateway.pinata.cloud/ipfs/QmZdd5KYdCFApWn7eTZJ1qgJu18urJrP9Yh1TZcZrZxxB5), per esempio.
-Per chi preferisce un apprendimento "visivo", i passaggi sopra sono riassunti qui:
+Per chi apprende in modo più visivo, i passaggi precedenti sono riassunti qui:
-
+
-Vogliamo caricare ora un altro documento su Pinata. Ma prima, dobbiamo crearlo!
+Ora, vorremo caricare un altro documento su Pinata. Ma prima di farlo, dobbiamo crearlo!
-Nella tua cartella di root, crea un nuovo file chiamato `nft-metadata.json` e aggiungi il seguente codice json:
+Nella tua directory principale, crea un nuovo file chiamato `nft-metadata.json` e aggiungi il seguente codice json:
```json
{
@@ -104,21 +102,21 @@ Nella tua cartella di root, crea un nuovo file chiamato `nft-metadata.json` e ag
}
```
-Puoi modificare liberamente i dati nel json. Puoi rimuoverli o aggiungerli alla sezione degli attributi. Soprattutto, assicurati che il campo immagine punti alla posizione della tua immagine IPFS; altrimenti, il tuo NFT includerà la foto di un cane (molto carino!).
+Sentiti libero di cambiare i dati nel json. Puoi rimuovere o aggiungere alla sezione degli attributi. La cosa più importante è assicurarsi che il campo dell'immagine punti alla posizione della tua immagine IPFS, altrimenti il tuo NFT includerà una foto di un cane (molto carino!).
-Una volta finito di modificare il file JSON, salvalo e caricalo su Pinata, seguendo gli stessi passaggi di caricamento dell'immagine.
+Una volta terminata la modifica del file JSON, salvalo e caricalo su Pinata, seguendo gli stessi passaggi che abbiamo fatto per caricare l'immagine.
-## Fase 5: crea un'istanza del tuo contratto {#instance-contract}
+## Passaggio 5: Creare un'istanza del tuo contratto {#instance-contract}
-Ora, per interagire con il nostro contratto, dobbiamo crearne un'istanza nel nostro codice. Per farlo, avremo bisogno dell'indirizzo del nostro contratto, che possiamo ottenere dalla distribuzione o da [Etherscan](https://sepolia.etherscan.io/), cercando l'indirizzo usato per distribuire il contratto.
+Ora, per interagire con il nostro contratto, dobbiamo crearne un'istanza nel nostro codice. Per farlo avremo bisogno del nostro indirizzo del contratto che possiamo ottenere dalla distribuzione o da [Blockscout](https://eth-sepolia.blockscout.com/) cercando l'indirizzo che hai usato per distribuire il contratto.
-Nell'esempio precedente, l'indirizzo del nostro contratto è 0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778.
+Nell'esempio sopra, il nostro indirizzo del contratto è 0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778.
-Poi useremo il [metodo di contratto](https://docs.web3js.org/api/web3-eth-contract/class/Contract) di Web3 per creare il nostro contratto usando l'ABI e l'indirizzo. Nel tuo file `mint-nft.js`, aggiungi quanto segue:
+Successivamente useremo il [metodo contract](https://docs.web3js.org/api/web3-eth-contract/class/Contract) di Web3 per creare il nostro contratto usando l'ABI e l'indirizzo. Nel tuo file `mint-nft.js`, aggiungi quanto segue:
```js
const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
@@ -126,11 +124,11 @@ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
```
-## Fase 6: aggiorna il file `.env` {#update-env}
+## Passaggio 6: Aggiornare il file `.env` {#update-env}
-Ora, per poter creare e inviare le transazioni alla catena di Ethereum, useremo l'indirizzo pubblico del tuo conto di Ethereum per ottenerne il nonce (spiegheremo in seguito).
+Ora, per creare e inviare transazioni alla catena di Ethereum, useremo l'indirizzo pubblico del tuo account Ethereum per ottenere il nonce dell'account (lo spiegheremo di seguito).
-Aggiungi la tua chiave pubblica al tuo file `.env`; se hai completato la parte 1 del tutorial, il nostro file `.env` dovrebbe somigliare a questo:
+Aggiungi la tua chiave pubblica al tuo file `.env`: se hai completato la parte 1 del tutorial, il nostro file `.env` dovrebbe ora apparire così:
```js
API_URL = "https://eth-sepolia.g.alchemy.com/v2/your-api-key"
@@ -138,27 +136,27 @@ PRIVATE_KEY = "your-private-account-address"
PUBLIC_KEY = "your-public-account-address"
```
-## Fase 7: crea la tua transazione {#create-txn}
+## Passaggio 7: Creare la tua transazione {#create-txn}
-Prima di tutto, definiamo una funzione denominata `mintNFT(tokenData)` e creiamo la nostra transazione facendo quanto segue:
+Per prima cosa, definiamo una funzione chiamata `mintNFT(tokenData)` e creiamo la nostra transazione facendo quanto segue:
1. Prendi la tua _PRIVATE_KEY_ e _PUBLIC_KEY_ dal file `.env`.
-1. Poi, dobbiamo trovare il nonce del conto. La specifica di nonce è usata per tracciare il numero di transazioni inviate dal tuo indirizzo, di cui necessitiamo per motivi di sicurezza e per impedire 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).
+1. Successivamente, dovremo capire il nonce dell'account. La specifica del nonce è usata per tenere traccia del numero di transazioni inviate dal tuo indirizzo, di cui abbiamo bisogno per motivi di sicurezza e per prevenire [attacchi di replay](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).
-1. Infine, configureremo la nostra transazione con le seguenti informazioni:
+1. Infine imposteremo la nostra transazione con le seguenti informazioni:
- `'from': PUBLIC_KEY` — L'origine della nostra transazione è il nostro indirizzo pubblico
-- `'to': contractAddress` — Il contratto con cui vogliamo interagire e a cui vogliamo inviare la transazione
+- `'to': contractAddress` — Il contratto con cui desideriamo interagire e a cui inviare la transazione
-- `'nonce': nonce`: l'account nonce con il numero di transazioni inviate dal nostro indirizzo
+- `'nonce': nonce` — Il nonce dell'account con il numero di transazioni inviate dal nostro indirizzo
-- `'gas': estimatedGas`: Il gas stimato necessario per completare la transazione
+- `'gas': estimatedGas` — Il gas stimato necessario per completare la transazione
-- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()` — Il calcolo che vogliamo eseguire in questa transazione, che in questo caso è il conio di un NFT
+- `'data': nftContract.methods.mintNFT(PUBLIC_KEY, md).encodeABI()` — Il calcolo che desideriamo eseguire in questa transazione, che in questo caso è coniare un NFT
-Il tuo file `mint-nft.js` dovrebbe somigliare a questo ora:
+Il tuo file `mint-nft.js` dovrebbe apparire così ora:
```js
require('dotenv').config();
@@ -174,9 +172,9 @@ Il tuo file `mint-nft.js` dovrebbe somigliare a questo ora:
const nftContract = new web3.eth.Contract(contract.abi, contractAddress);
async function mintNFT(tokenURI) {
- const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, 'latest'); //get latest nonce
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, 'latest'); // ottieni l'ultimo nonce
- //the transaction
+ // la transazione
const tx = {
'from': PUBLIC_KEY,
'to': contractAddress,
@@ -187,11 +185,11 @@ Il tuo file `mint-nft.js` dovrebbe somigliare a questo ora:
}
```
-## Fase 8: firma la transazione {#sign-txn}
+## Passaggio 8: Firmare la transazione {#sign-txn}
-Ora che abbiamo creato la nostra transazione, dobbiamo firmarla per inviarla. Ecco dove useremo la nostra chiave privata.
+Ora che abbiamo creato la nostra transazione, dobbiamo firmarla per poterla inviare. È qui che useremo la nostra chiave privata.
-`web3.eth. endSignedTransaction` ci darà l'hash della transazione, che possiamo usare per assicurarci che la nostra transazione sia stata minata e non sia stata eliminata dalla rete. Noterai nella sezione di firma della transazione che abbiamo aggiunto dei controlli degli errori, per poter sapere se la nostra transazione è passata correttamente.
+`web3.eth.sendSignedTransaction` ci darà l'hash della transazione, che possiamo usare per assicurarci che la nostra transazione sia stata minata e non sia stata scartata dalla rete. Noterai che nella sezione della firma della transazione, abbiamo aggiunto un controllo degli errori in modo da sapere se la nostra transazione è andata a buon fine.
```js
require("dotenv").config()
@@ -207,9 +205,9 @@ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
async function mintNFT(tokenURI) {
- const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //get latest nonce
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") // ottieni l'ultimo nonce
- //the transaction
+ // la transazione
const tx = {
from: PUBLIC_KEY,
to: contractAddress,
@@ -245,19 +243,19 @@ async function mintNFT(tokenURI) {
}
```
-## Fase 9: chiama `mintNFT` ed esegui il nodo `mint-nft.js` {#call-mintnft-fn}
+## Passaggio 9: Chiamare `mintNFT` ed eseguire node `mint-nft.js` {#call-mintnft-fn}
-Ricordi il `metadata.json` che hai caricato su Pinata? Ottieni il suo hashcode da Pinata e passa il seguente come un parametro alla funzione `mintNFT` `https://gateway.pinata.cloud/ipfs/`
+Ricordi il `metadata.json` che hai caricato su Pinata? Ottieni il suo codice hash da Pinata e passa quanto segue come parametro alla funzione `mintNFT` `https://gateway.pinata.cloud/ipfs/`
-Ecco come ottenere l'hashcode:
+Ecco come ottenere il codice hash:
-_Come ottenere l'hashcode dei metadati del tuo NFT su Pinata_
+_Come ottenere il codice hash dei metadati del tuo nft su Pinata_
-> Ricontrolla che l'hashcode che hai copiato si colleghi al tuo **metadata.json**, caricando `https://gateway.pinata.cloud/ipfs/` in una finestra separata. La pagina dovrebbe somigliare al seguente screenshot:
+> Controlla due volte che il codice hash che hai copiato si colleghi al tuo **metadata.json** caricando `https://gateway.pinata.cloud/ipfs/` in una finestra separata. La pagina dovrebbe apparire simile allo screenshot qui sotto:
-_La tua pagina deve mostrare i metadati in json_
+_La tua pagina dovrebbe visualizzare i metadati json_
-Nel complesso, il tuo codice dovrebbe somigliare a questo:
+Nel complesso, il tuo codice dovrebbe apparire più o meno così:
```js
require("dotenv").config()
@@ -273,9 +271,9 @@ const contractAddress = "0x5a738a5c5fe46a1fd5ee7dd7e38f722e2aef7778"
const nftContract = new web3.eth.Contract(contract.abi, contractAddress)
async function mintNFT(tokenURI) {
- const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") //get latest nonce
+ const nonce = await web3.eth.getTransactionCount(PUBLIC_KEY, "latest") // ottieni l'ultimo nonce
- //the transaction
+ // la transazione
const tx = {
from: PUBLIC_KEY,
to: contractAddress,
@@ -313,19 +311,18 @@ async function mintNFT(tokenURI) {
mintNFT("ipfs://QmYueiuRNmL4MiA2GwtVMm6ZagknXnSpQnB3z2gWbz36hP")
```
-Ora, esegui `scripts/mint-nft.js` per distribuire il tuo NFT. Dopo qualche secondo, dovresti vedere una risposta come questa nel tuo terminale:
+Ora, esegui `node scripts/mint-nft.js` per distribuire il tuo NFT. Dopo un paio di secondi, dovresti vedere una risposta come questa nel tuo terminale:
- L'hash della tua transazione è:
- 0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8
-
- Consulta il Mempool di Alchemy per visualizzare lo stato della tua transazione!
+ The hash of your transaction is: 0x301791fdf492001fcd9d5e5b12f3aa1bbbea9a88ed24993a8ab2cdae2d06e1e8
-Vai quindi alla tua [mempool di Alchemy](https://dashboard.alchemyapi.io/mempool) per vedere lo stato della transazione (se è sospesa, minata o eliminata dalla rete). Se la tua transazione è stata eliminata, è utile dare un'occhiata anche su [Sepolia Etherscan](https://sepolia.etherscan.io/) e cercare l'hash della tua transazione.
+ Check Alchemy's Mempool to view the status of your transaction!
-_Visualizza l'hash della tua transazione NFT su Etherscan_
+Successivamente, visita la tua [mempool di Alchemy](https://dashboard.alchemyapi.io/mempool) per vedere lo stato della tua transazione (se è in sospeso, minata o è stata scartata dalla rete). Se la tua transazione è stata scartata, è anche utile controllare [Blockscout](https://eth-sepolia.blockscout.com/) e cercare l'hash della tua transazione.
-Ecco fatto! Hai ora distribuito E coniato con un NFT sulla Blockchain di Ethereum `](https://any.site/ipfs/bafybeifqka2odrne5b6l5guthqvbxu4pujko2i6rx2zslvr3qxs6u5o7im) su qualsiasi sito e otterrai quel contenuto, servito in modo decentralizzato.
+
+## Svantaggi {#drawbacks}
+
+Non puoi eliminare in modo affidabile i file IPFS, quindi finché stai modificando la tua interfaccia utente, probabilmente è meglio lasciarla centralizzata o usare l'[interplanetary name system (IPNS)](https://docs.ipfs.tech/concepts/ipns/#mutability-in-ipfs), un sistema che fornisce mutabilità sopra IPFS. Naturalmente, qualsiasi cosa sia mutabile può essere censurata, nel caso di IPNS facendo pressione sulla persona con la chiave privata a cui corrisponde.
+
+Inoltre, alcuni pacchetti hanno problemi con IPFS, quindi se il tuo sito web è molto complicato potrebbe non essere una buona soluzione. E naturalmente, qualsiasi cosa si basi sull'integrazione del server non può essere decentralizzata solo avendo il lato client su IPFS.
+
+## Conclusione {#conclusion}
+
+Proprio come Ethereum ti consente di decentralizzare il database e gli aspetti della logica di business della tua dApp, IPFS ti consente di decentralizzare l'interfaccia utente. Questo ti permette di chiudere un ulteriore vettore di attacco contro la tua dApp.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
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 15d4bcf8225..1e085815af1 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,27 +1,22 @@
---
-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à
+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à"
author: "Markus Waas"
tags:
- - "create-eth-app"
- - "frontend"
- - "javascript"
- - "ethers.js"
- - "the graph"
- - "defi"
+ ["frontend", "JavaScript", "ethers.js", "the graph", "defi"]
skill: beginner
-breadcrumb: "create-eth-app"
+breadcrumb: create-eth-app
lang: it
published: 2020-04-27
source: soliditydeveloper.com
sourceUrl: https://soliditydeveloper.com/create-eth-app
---
-L'ultima volta abbiamo dato un'occhiata al [quadro generale di Solidity](https://soliditydeveloper.com/solidity-overview-2020) e abbiamo già accennato a [create-eth-app](https://github.com/PaulRBerg/create-eth-app). Ora scoprirai come usarlo, quali funzionalità sono integrate e alcune idee aggiuntive su come approfondilo. Creata da Paul Razvan Berg, fondatore di [Sablier](http://sablier.com/), quest'app avvierà lo sviluppo del tuo frontend, offrendo diverse integrazioni facoltative tra cui scegliere.
+L'ultima volta abbiamo dato un'occhiata al [quadro generale di Solidity](https://soliditydeveloper.com/solidity-overview-2020) e abbiamo già menzionato [create-eth-app](https://github.com/PaulRBerg/create-eth-app). Ora scoprirai come usarla, quali funzionalità sono integrate e ulteriori idee su come espanderla. Creata da Paul Razvan Berg, il fondatore di [Sablier](http://sablier.com/), questa app avvierà lo sviluppo del tuo frontend e include diverse integrazioni opzionali tra cui scegliere.
## Installazione {#installation}
-L'installazione richiede Yarn 0.25 o superiore (`npm install yarn -- global`). L'esecuzione è semplicissima:
+L'installazione richiede Yarn 0.25 o superiore (`npm install yarn --global`). È semplice come eseguire:
```bash
yarn create eth-app my-eth-app
@@ -29,44 +24,44 @@ cd my-eth-app
yarn react-app:start
```
-Come sistema sottostante utilizza [create-react-app](https://github.com/facebook/create-react-app). Per vedere la tua app, apri `http://localhost:3000/`. Quando sei pronto a distribuire in produzione, crea un pacchetto minimizzato con yarn build. Un modo facile per ospitarlo sarebbe [Netlify](https://www.netlify.com/). Puoi creare una repo di GitHub, aggiungerla a Netlify, configurare il comando build e hai finito! La tua app sarà ospitata e utilizzabile da tutti. E tutto gratuitamente.
+Utilizza [create-react-app](https://github.com/facebook/create-react-app) dietro le quinte. Per vedere la tua app, apri `http://localhost:3000/`. Quando sei pronto per la distribuzione in produzione, crea un pacchetto minimizzato con yarn build. Un modo semplice per ospitarlo sarebbe [Netlify](https://www.netlify.com/). Puoi creare un repository GitHub, aggiungerlo a Netlify, configurare il comando di build e hai finito! La tua app sarà ospitata e utilizzabile da tutti. E tutto questo gratuitamente.
-## Caratteristiche {#features}
+## Funzionalità {#features}
### React e create-react-app {#react--create-react-app}
-Prima di tutto, il cuore dell'app: React e tutte le funzionalità aggiuntive fornite con _create-react-app_. Usare solo questo strumento è un'ottima opzione se non vuoi integrare Ethereum. [React](https://reactjs.org/) stesso rende semplicissima la costruzione di UI interattive. Potrebbe non esser facile per i principianti come [Vue](https://vuejs.org/), ma è comunque molto usato, ha più funzionalità e, soprattutto, ha migliaia di librerie aggiuntive tra cui scegliere. _create-react-app_ è facilissimo per iniziare e include:
+Prima di tutto il cuore dell'app: React e tutte le funzionalità aggiuntive fornite con _create-react-app_. Usare solo questo è un'ottima opzione se non vuoi integrare Ethereum. [React](https://react.dev/) stesso rende la creazione di interfacce utente interattive davvero semplice. Potrebbe non essere adatto ai principianti quanto [Vue](https://vuejs.org/), ma è comunque il più utilizzato, ha più funzionalità e, cosa più importante, migliaia di librerie aggiuntive tra cui scegliere. Anche _create-react-app_ rende davvero facile iniziare a usarlo e include:
-- Supporto alla sintassi di React, JSX, ES6, TypeScript, Flow.
-- Extra linguistici oltre ES6 come l'operatore di diffusione dell'oggetto.
-- CSS auto-prefissato, così da non necessitare -webkit- o altri prefissi.
-- Un veloce esecutore di test unitari interattivi con supporto integrato per la segnalazione della copertura.
-- Un server di sviluppo live che avverte degli errori comuni.
-- Uno script di costruzione per riunire JS, CSS e immagini per la produzione, con hash e mappe sorgente.
+- Supporto per la sintassi di React, JSX, ES6, TypeScript e Flow.
+- Extra del linguaggio oltre a ES6 come l'operatore spread per gli oggetti.
+- CSS con prefissi automatici, così non hai bisogno di -webkit- o altri prefissi.
+- Un esecutore di test unitari interattivo e veloce con supporto integrato per i report di copertura.
+- Un server di sviluppo live che avvisa degli errori comuni.
+- Uno script di build per raggruppare JS, CSS e immagini per la produzione, con hash e sourcemap.
-_create-eth-app_ in particolare, fa uso dei nuovi [effetti hook](https://reactjs.org/docs/hooks-effect.html). Un metodo per scrivere componenti funzionali potenti ma molto piccoli. Vedi di seguito la sezione su Apollo per capire come vengono usati in _create-eth-app_.
+In particolare, _create-eth-app_ fa uso dei nuovi [effetti degli hook](https://legacy.reactjs.org/docs/hooks-effect.html). Un metodo per scrivere componenti cosiddetti funzionali potenti, ma molto piccoli. Consulta la sezione seguente su Apollo per scoprire come vengono utilizzati in _create-eth-app_.
### Yarn Workspaces {#yarn-workspaces}
-[Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/) ti consente di utilizzare più pacchetti e di gestirli tutti dalla cartella di root e installare le dipendenze per tutti in una volta, usando `yarn install`. Ciò è utile soprattutto per i pacchetti aggiuntivi più piccoli, come la gestione di indirizzi/ABI degli smart contract (le informazioni su dove hai distribuito quali smart contract e come comunicare con essi) o l'integrazione di Graph, entrambi parte di `create-eth-app`.
+[Yarn Workspaces](https://classic.yarnpkg.com/en/docs/workspaces/) ti consente di avere più pacchetti, ma di poterli gestire tutti dalla cartella principale e di installare le dipendenze per tutti in una volta sola usando `yarn install`. Questo ha particolarmente senso per pacchetti aggiuntivi più piccoli come la gestione degli indirizzi/ABI dei contratti intelligenti (le informazioni su dove hai distribuito quali contratti intelligenti e come comunicare con essi) o l'integrazione di The Graph, entrambi parte di `create-eth-app`.
### ethers.js {#ethersjs}
-Mentre [Web3](https://docs.web3js.org/) è ancora molto usato, nell'ultimo anno [ethers.js](https://docs.ethers.io/) ha riscosso molto successo come strumento alternativo ed è integrato in _create-eth-app_. Puoi lavorare con questo strumento, passare a Web3 o considerare di aggiornare a [ethers.js v5](https://docs.ethers.org/v5/), che ha quasi terminato la fase beta.
+Sebbene [Web3](https://docs.web3js.org/) sia ancora il più utilizzato, [ethers.js](https://docs.ethers.io/) ha ottenuto molta più trazione come alternativa nell'ultimo anno ed è quello integrato in _create-eth-app_. Puoi lavorare con questo, passare a Web3 o considerare l'aggiornamento a [ethers.js v5](https://docs.ethers.org/v5/) che è quasi fuori dalla fase beta.
-### Graph {#the-graph}
+### The Graph {#the-graph}
-[GraphQL](https://graphql.org/) è un metodo alternativo per gestire i dati rispetto a un'[API di Restful](https://restfulapi.net/). Ha diversi vantaggi rispetto alle Api di Restful, specialmente per i dati della blockchain decentralizzata. Se sei interessato al ragionamento dietro questo metodo, dai un'occhiata a [GraphQL Will Power the Decentralized Web](https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a).
+[GraphQL](https://graphql.org/) è un modo alternativo per gestire i dati rispetto a un'[API Restful](https://restfulapi.net/). Hanno diversi vantaggi rispetto alle API Restful, specialmente per i dati decentralizzati della blockchain. Se sei interessato al ragionamento alla base di questo, dai un'occhiata a [GraphQL Will Power the Decentralized Web](https://medium.com/graphprotocol/graphql-will-power-the-decentralized-web-d7443a69c69a).
-Solitamente recupereresti i dati direttamente dal tuo smart contract. Vuoi leggere l'ora dell'ultima operazione? Basta chiamare `MyContract.methods.latestTradeTime().call()`, che recupera i dati da un nodo di Ethereum nella tua dapp. E se ci fossero centinaia di punti di dati diversi? Ciò risulterebbe in centinaia di recuperi di dati al nodo, richiedendo ogni volta un [RTT](https://wikipedia.org/wiki/Round-trip_delay_time) e rendendo la tua dapp lenta e inefficace. Una scappatoia potrebbe essere una funzione di chiamata del recuperatore nel tuo contratto, in modo da restituire più dati in una volta. Questa soluzione però non è sempre ideale.
+Di solito recupereresti i dati direttamente dal tuo contratto intelligente. Vuoi leggere l'ora dell'ultimo scambio? Basta chiamare `MyContract.methods.latestTradeTime().call()` che recupera i dati da un nodo di Ethereum nella tua dApp. Ma cosa succede se hai bisogno di centinaia di punti dati diversi? Ciò comporterebbe centinaia di recuperi di dati verso il nodo, richiedendo ogni volta un [RTT](https://wikipedia.org/wiki/Round-trip_delay_time) che rende la tua dApp lenta e inefficiente. Una soluzione alternativa potrebbe essere una funzione di chiamata di recupero all'interno del tuo contratto che restituisce più dati contemporaneamente. Tuttavia, questo non è sempre l'ideale.
-E poi potresti essere interessato anche ai dati storici. Vuoi sapere non solo l'orario dell'ultima operazione, ma gli orari per tutte le operazioni che tu stesso hai mai eseguito? Usa il pacchetto subgraph _create-eth-app_, leggi la [documentazione](https://thegraph.com/docs/en/subgraphs/developing/creating/starting-your-subgraph) e adattalo ai tuoi contratti. Se stai cercando degli smart contract popolari, potrebbe anche esistere già un subgraph. Dai un'occhiata al [subgraph explorer](https://thegraph.com/explorer/).
+E poi potresti essere interessato anche ai dati storici. Vuoi conoscere non solo l'ora dell'ultimo scambio, ma gli orari di tutti gli scambi che hai mai effettuato tu stesso. Usa il pacchetto subgraph di _create-eth-app_, leggi la [documentazione](https://thegraph.com/docs/en/subgraphs/developing/creating/starting-your-subgraph) e adattalo ai tuoi contratti. Se stai cercando contratti intelligenti popolari, potrebbe esserci già un sottografo. Dai un'occhiata all'[esploratore di sottografi](https://thegraph.com/explorer/).
-Una volta che hai un grafico secondario, ti consente di scrivere una semplice richiesta nella tua dapp che recuperi tutti i dati importanti della blockchain, inclusi quelli storici che necessiti, tramite un solo recupero necessario.
+Una volta che hai un sottografo, ti consente di scrivere una semplice query nella tua dApp che recupera tutti i dati importanti della blockchain, inclusi quelli storici di cui hai bisogno, richiedendo un solo recupero.
### Apollo {#apollo}
-Grazie all'integrazione di [Apollo Boost](https://www.apollographql.com/docs/react/get-started/), puoi integrare facilmente il grafico nella tua dapp di React. Specialmente quando si utilizzano gli [hook di React e Apollo](https://www.apollographql.com/blog/apollo-client-now-with-react-hooks), recuperare i dati è tanto facile quanto scrivere una singola query di GraphQL nel tuo componente:
+Grazie all'integrazione di [Apollo Boost](https://www.apollographql.com/docs/react/get-started/) puoi facilmente integrare The Graph nella tua dApp React. Specialmente quando si usano [gli hook di React e Apollo](https://www.apollographql.com/blog/apollo-client-now-with-react-hooks), recuperare i dati è semplice come scrivere una singola query GraphQl nel tuo componente:
```js
const { loading, error, data } = useQuery(myGraphQlQuery)
@@ -80,32 +75,32 @@ React.useEffect(() => {
## Modelli {#templates}
-Inoltre, puoi scegliere tra diversi modelli. Finora puoi usare un'integrazione di Aave, Compound, Uniswap o Sablier. Aggiungono tutti importanti indirizzi di servizi degli smart contract con integrazioni di subgraph pre-realizzate. Basta aggiungere il modello al comando di creazione come in `yarn create eth-app my-eth-app --with-template aave`.
+Inoltre puoi scegliere tra diversi modelli. Finora puoi usare un'integrazione Aave, Compound, UniSwap o Sablier. Tutti aggiungono importanti indirizzi di contratti intelligenti di servizio insieme a integrazioni di sottografi predefinite. Basta aggiungere il modello al comando di creazione come `yarn create eth-app my-eth-app --with-template aave`.
### Aave {#aave}
-[Aave](https://aave.com/) è un mercato per il prestito di denaro decentralizzato. I depositanti forniscono liquidità al mercato per guadagnare un reddito passivo, mentre i debitori possono prendere in prestito usando garanzie. Una funzionalità unica di Aave sono quei [prestiti flash](https://docs.aave.com/developers/guides/flash-loans) che ti consentono di prendere in prestito denaro senza alcuna garanzia, finché restituisci il prestito entro una transazione. Questo può essere utile, ad esempio, per fornirti denaro extra sul trading d'arbitraggio.
+[Aave](https://aave.com/) è un mercato di prestito di denaro decentralizzato. I depositanti forniscono liquidità al mercato per guadagnare un reddito passivo, mentre i mutuatari sono in grado di prendere in prestito utilizzando collaterali. Una caratteristica unica di Aave sono i [prestiti lampo (flash loan)](https://aave.com/docs/developers/flash-loans) che ti consentono di prendere in prestito denaro senza alcun collaterale, a patto di restituire il prestito all'interno di una singola transazione. Questo può essere utile, ad esempio, per darti liquidità extra nel trading di arbitraggio.
-I token scambiati che ti fanno guadagnare interessi si chiamano _aTokens_.
+I token scambiati che ti fanno guadagnare interessi sono chiamati _aToken_.
-Quando scegli di integrare Aave con _create-eth-app_, otterrai un'[integrazione del subgraph](https://docs.aave.com/developers/getting-started/using-graphql). Aave usa The Graph e ti fornisce già diversi subgraph pronti all'uso su [Ropsten](https://thegraph.com/explorer/subgraph/aave/protocol-ropsten) e sulla [rete principale](https://thegraph.com/explorer/subgraph/aave/protocol) in forma [grezza](https://thegraph.com/explorer/subgraph/aave/protocol-raw) o [formattata](https://thegraph.com/explorer/subgraph/aave/protocol).
+Quando scegli di integrare Aave con _create-eth-app_, otterrai un'[integrazione del sottografo](https://docs.aave.com/developers/getting-started/using-graphql). Aave usa The Graph e ti fornisce già diversi sottografi pronti all'uso su [Ropsten](https://thegraph.com/explorer/subgraph/aave/protocol-ropsten) e sulla [rete principale](https://thegraph.com/explorer/subgraph/aave/protocol) in forma [grezza](https://thegraph.com/explorer/subgraph/aave/protocol-raw) o [formattata](https://thegraph.com/explorer/subgraph/aave/protocol).
-
+
### Compound {#compound}
-[Compound](https://compound.finance/) è simile ad Aave. L'integrazione include già il nuovo [Compound v2 Subgraph](https://medium.com/graphprotocol/https-medium-com-graphprotocol-compound-v2-subgraph-highlight-a5f38f094195). A gran sorpresa, qui i token che guadagnano interessi sono chiamati _cToken_.
+[Compound](https://compound.finance/) è simile ad Aave. L'integrazione include già il nuovo [sottografo Compound v2](https://medium.com/graphprotocol/https-medium-com-graphprotocol-compound-v2-subgraph-highlight-a5f38f094195). I token che guadagnano interessi qui sono sorprendentemente chiamati _cToken_.
### Uniswap {#uniswap}
-[Uniswap](https://uniswap.exchange/) è uno scambio decentralizzato (DEX). I fornitori di liquidità possono guadagnare commissioni fornendo i token richiesti o ether per ambe le parti di uno scambio. È ampiamente usato e dunque ha una delle liquidità più elevate per una gamma davvero ampia di token. Puoi integrarla facilmente nella tua dapp, ad esempio, per consentire agli utenti di scambiare i propri ETH per DAI.
+[Uniswap](https://uniswap.exchange/) è un exchange decentralizzato (DEX). I fornitori di liquidità possono guadagnare commissioni fornendo i token o gli ether richiesti per entrambi i lati di uno scambio. È ampiamente utilizzato e quindi ha una delle liquidità più elevate per una gamma molto ampia di token. Puoi facilmente integrarlo nella tua dApp per, ad esempio, consentire agli utenti di scambiare i loro ETH per DAI.
-Sfortunatamente, al momento della redazione del del presente articolo, l'integrazione è solo per Uniswap v1 e non per [la recente v2](https://uniswap.org/blog/uniswap-v2/).
+Sfortunatamente, al momento della stesura di questo articolo l'integrazione è solo per Uniswap v1 e non per la [v2 appena rilasciata](https://uniswap.org/blog/uniswap-v2/).
### Sablier {#sablier}
-[Sablier](https://sablier.com/) consente agli utenti di trasmettere pagamenti in denaro. Invece di un singolo giorno di pagamento, in realtà puoi ricevere denaro costantemente senza ulteriore amministrazione dopo la configurazione iniziale. L'integrazione include i [propri subgraph](https://thegraph.com/explorer/subgraph/sablierhq/sablier).
+[Sablier](https://sablier.com/) consente agli utenti di trasmettere pagamenti in denaro in streaming. Invece di un singolo giorno di paga, ottieni effettivamente i tuoi soldi costantemente senza ulteriore amministrazione dopo la configurazione iniziale. L'integrazione include il suo [sottografo dedicato](https://thegraph.com/explorer/subgraph/sablierhq/sablier).
-## E poi? {#whats-next}
+## Quali sono i prossimi passi? {#whats-next}
-Se hai domande su _create-eth-app_, vai al [server della community di Sablier](https://discord.gg/bsS8T47), dove puoi contattare gli autori di _create-eth-app_. Come passaggi iniziali, potrebbe essere utile integrare un framework dell'UI come [Material UI](https://material-ui.com/), scrivere query di GraphQL per i dati che ti servono realmente e configurare la distribuzione.
+Se hai domande su _create-eth-app_, vai al [server della community di Sablier](https://discord.gg/bsS8T47), dove puoi metterti in contatto con gli autori di _create-eth-app_. Come primi passi successivi potresti voler integrare un framework per l'interfaccia utente come [Material UI](https://mui.com/material-ui/), scrivere query GraphQL per i dati di cui hai effettivamente bisogno e configurare la distribuzione.
\ No newline at end of file
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 8f9d4673a4c..266ed1a5e1a 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,94 +1,95 @@
---
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, tra cui transazioni, blocchi e gas, interrogando i dati on-chain con lo Structured Query Language (SQL).
author: "Paul Apivat"
-tags:
- - "SQL"
- - "Interrogazioni"
- - "Transazioni"
+tags: ["SQL", "Interrogazione", "Transazioni", "dati e analisi"]
skill: beginner
-breadcrumb: "Ethereum con SQL"
+breadcrumb: Ethereum con SQL
lang: it
published: 2021-05-11
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 su Ethereum si rivolgono agli sviluppatori, ma mancano risorse educative per gli analisti di dati o per le persone che desiderano vedere 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 lo structured query language (SQL) attraverso 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 come economia per la potenza di calcolo e dovrebbero servire come base per comprendere le sfide che Ethereum affronta oggi (ad es., l'aumento dei prezzi del gas) e, cosa più importante, le discussioni sulle soluzioni di scalabilità.
### 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 viaggio di un utente su Ethereum inizia con l'inizializzazione di un account controllato dall'utente o di un'entità con un saldo in ETH. Esistono due tipi di account: 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 account 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. Mostrano, in tempo reale, dati su blocchi, transazioni, minatori, account 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/) offre questa capacità 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, l'account del contratto intelligente per la 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.
+Una cosa da notare è che tutti gli account, incluso quello della 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 dell'account su Etherscan comprende transazioni regolari e transazioni interne. Le transazioni interne, nonostante il nome, non sono _effettive_ transazioni che cambiano 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. Queste possono essere interrogate in questo modo:
```sql
WITH temp_table AS (
SELECT
hash,
- block_number,
- block_time,
"from",
"to",
value / 1e18 AS ether,
- gas_used,
- gas_price / 1e9 AS gas_price_gwei
+ data,
+ "gas_limit",
+ "gas_price" / 1e9 AS gas_price_gwei,
+ "gas_used",
+ ROUND(((gas_used / gas_limit) * 100),2) AS gas_used_pct
FROM ethereum."transactions"
WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe'
ORDER BY block_time DESC
)
SELECT
hash,
- block_number,
- block_time,
"from",
"to",
ether,
+ data,
+ gas_limit,
+ gas_price_gwei,
+ gas_used,
+ gas_used_pct,
(gas_used * gas_price_gwei) / 1e9 AS txn_fee
FROM temp_table
```
-Questo produrrà le stesse informazioni fornite sulla pagina della transazione di Etherscan. A titolo di confronto, ecco le due sorgenti:
+Questo produrrà 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 della 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).
+Puoi trovare la dashboard [qui](https://dune.com/paulapivat/Learn-Ethereum). Clicca sulla tabella per vedere l'interrogazione (vedi anche sopra).
-### Spezzare le Transazioni {#breaking_down_transactions}
+### Scomposizione 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 del mittente ("from").
+- **Valore**: Questo è l'importo di ETH trasferito (vedi la colonna `ether`).
+- **Dati**: Si tratta di dati arbitrari che sono stati sottoposti a hash (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** - la quantità massima di gas da includere come mancia al minatore
+- **maxFeePerGas** - la quantità massima di gas che si è disposti a pagare per la transazione (inclusi 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
@@ -107,87 +108,82 @@ 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 cambierà 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 vedere i dati, potremmo interrogare un numero di blocco specifico: 12396854 (il blocco più recente tra le transazioni della Ethereum Foundation al momento in cui scriviamo, 11/5/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 (ovvero, 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. Questo è 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 l'[interrogazione](https://dune.com/queries/44856/88292) su Dune Analytics:
```sql
SELECT
- time,
- number,
- hash,
- parent_hash,
- nonce
+ time,
+ number,
+ difficulty,
+ hash,
+ parent_hash,
+ nonce
FROM ethereum."blocks"
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 tempo, numero di 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 interrogazione non copre è la _lista delle transazioni_, che richiede un'interrogazione separata di seguito, e la _radice di stato_ (state root). 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 della catena (lista 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'ultimo 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:
+Come affermato sopra, ogni blocco contiene una lista di transazioni; possiamo interrogarla filtrando per un blocco specifico. Proveremo con il blocco più recente, 12396854:
```sql
SELECT * FROM ethereum."transactions"
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.
+L'aggiunta di questo singolo blocco alla catena cambia lo stato della macchina virtuale di Ethereum ([EVM](/developers/docs/evm/)). Dozzine, 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 riuscite:
```sql
-WITH temp_table AS (
- SELECT * FROM ethereum."transactions"
- WHERE block_number = 12396854 AND success = true
- ORDER BY block_time DESC
-)
SELECT
- COUNT(success) AS num_successful_txn
-FROM temp_table
+ COUNT(success) AS successful_txn
+FROM ethereum."transactions"
+WHERE block_number = 12396854 AND success = true
```
-Per il blocco 12396854, di 222 transazioni totali, 204 sono state verificate correttamente:
+Per il blocco 12396854, su 222 transazioni totali, 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 transazioni avvengono dozzine 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 viene prodotto un blocco circa ogni 15 secondi, potremmo prendere il numero di secondi in un giorno (86400) diviso per 15 per ottenere un numero medio stimato di blocchi al giorno (~ 5760).
-Il grafico per i blocchi di Ethereum prodotti al giorno (2016 - presente) è:
+Il grafico dei blocchi di Ethereum prodotti al giorno (dal 2016 a oggi) è:
-
+
-Il numero medio di blocchi prodotti giornalmente in questo periodo di tempo è di ~5.874:
+Il numero medio di blocchi prodotti quotidianamente in questo periodo di tempo è ~5.874:
-
+
Le interrogazioni sono:
```sql
-# query to visualize number of blocks produced daily since 2016
-
+-- query for daily blocks produced
SELECT
DATE_TRUNC('day', time) AS dt,
COUNT(*) AS block_count
@@ -195,8 +191,7 @@ FROM ethereum."blocks"
GROUP BY dt
OFFSET 1
-# average number of blocks produced per day
-
+-- query for average blocks produced per day
WITH temp_table AS (
SELECT
DATE_TRUNC('day', time) AS dt,
@@ -210,15 +205,15 @@ 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 quel numero, a 5.874. In alternativa, dividendo 86400 secondi per 5874 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 in base alla domanda della rete tra 12.500.000 e 25.000.000 di unità. I limiti sono necessari per evitare che dimensioni di blocco arbitrariamente grandi mettano sotto sforzo i nodi completi in termini di spazio su disco e requisiti di 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 è pensarlo 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:
-
+
```sql
SELECT
@@ -229,9 +224,9 @@ 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 utilizzato quotidianamente per pagare il calcolo eseguito sulla catena di Ethereum (ad es., inviare una transazione, chiamare un contratto intelligente, coniare un NFT). Questa è la **domanda** di spazio disponibile nei blocchi di Ethereum:
-
+
```sql
SELECT
@@ -242,23 +237,22 @@ GROUP BY dt
OFFSET 1
```
-Possiamo anche giustapporre questi due grafici insieme per vedere come si allineano **domanda e offerta**:
+Possiamo anche giustapporre questi due grafici per vedere come si allineano **domanda e offerta**:
-Dunque, possiamo comprendere i prezzi del gas come una funzione di domanda per lo spazio del blocco di Ethereum, data l'offerta disponibile.
+Pertanto possiamo comprendere i prezzi del gas come una funzione della domanda di spazio nei 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 comporterà un tempo di interrogazione particolarmente lungo, quindi filtreremo la nostra interrogazione per la quantità media di gas pagata 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 verso l'indirizzo della Ethereum Foundation nel corso degli anni. Ecco l'interrogazione:
```sql
SELECT
block_time,
- gas_price / 1e9 AS gas_price_gwei,
- value / 1e18 AS eth_sent
+ gas_price / 1e9 AS gas_price_gwei
FROM ethereum."transactions"
WHERE "to" = '\xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe'
ORDER BY block_time DESC
@@ -266,8 +260,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 come funziona la blockchain di Ethereum interrogando e prendendo confidenza 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 può essere trovata [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 un ulteriore utilizzo dei dati per esplorare il web3 [trovami su Twitter](https://twitter.com/paulapivat).
\ No newline at end of file
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 17636af14a8..0ea296a2e68 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,14 +1,10 @@
---
-title: Registrare dati dagli Smart Contract con gli eventi
-description: Introduzione agli eventi degli Smart Contract e come usarli per registrare dati
+title: Registrare i dati dai contratti intelligenti con gli eventi
+description: Un'introduzione agli eventi dei contratti intelligenti e a come puoi usarli per registrare i dati
author: "jdourlens"
-tags:
- - "contratti intelligenti"
- - "remix"
- - "solidity"
- - "eventi"
+tags: ["contratti intelligenti", "Remix", "Solidity", "eventi"]
skill: intermediate
-breadcrumb: "Registrazione eventi"
+breadcrumb: Registrazione degli eventi
lang: it
published: 2020-04-03
source: EthereumDev
@@ -16,19 +12,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 degli eventi 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 che viene 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 costruire un altro contratto estendendolo: è chiamato contratto astratto. Nel caso del nostro esempio del contatore, apparirebbe così:
```solidity
pragma solidity 0.5.17;
@@ -37,16 +33,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 unsigned int per mantenere 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;
}
@@ -54,14 +50,14 @@ contract Counter {
}
```
-Da notare:
+Nota che:
-- **Riga 5**: dichiariamo l'evento e cosa contiene, il vecchio e il nuovo valore.
+- **Riga 5**: dichiariamo il nostro evento e cosa contiene, il vecchio valore e il nuovo valore.
-- **Riga 13**: quando aumentiamo la variabile di conteggio, emettiamo l'evento.
+- **Riga 13**: Quando incrementiamo la nostra variabile count, 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 increment, vedremo che Remix lo visualizzerà automaticamente se fai 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 davvero utili per il debug dei tuoi contratti intelligenti, ma sono anche importanti se crei applicazioni utilizzate da persone diverse e semplificano l'esecuzione di analisi per tracciare e comprendere come viene utilizzato il tuo contratto intelligente. I log generati dalle transazioni vengono visualizzati nei popolari esploratori di blocchi e puoi anche, ad esempio, usarli per creare script fuori catena per ascoltare eventi specifici e intraprendere azioni quando si verificano.
\ No newline at end of file
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 97ef79ffafa..365e80ba74b 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,106 +1,109 @@
---
-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 fuori catena"
+description: "Garantire l'integrità dei dati on-chain per i dati che sono archiviati, per lo più, fuori catena"
author: Ori Pomerantz
-tags:
- - "archiviazione"
+tags: ["archiviazione"]
skill: advanced
-breadcrumb: "Prove Merkle"
+breadcrumb: Prove di Merkle
lang: it
published: 2021-12-30
---
## Introduzione {#introduction}
-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.
+Idealmente vorremmo archiviare tutto nell'archiviazione di Ethereum, che è memorizzata su migliaia di computer e ha una disponibilità estremamente elevata (i dati non possono essere censurati) e integrità (i dati non possono essere modificati in modo non autorizzato), ma l'archiviazione di una parola di 32 byte costa in genere 20.000 gas. Nel momento in cui scrivo, questo costo equivale a 6,60 $. A 21 centesimi per byte, questo è troppo costoso per molti usi.
-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 archiviare i dati in modo decentralizzato](/developers/docs/storage/). Di solito comportano un compromesso tra disponibilità e prezzo. Tuttavia, l'integrità è solitamente 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 imparerai **come** garantire l'integrità dei dati senza archiviare i dati sulla blockchain, utilizzando le [prove di Merkle](https://computersciencewiki.org/index.php/Merkle_proof).
## Come funziona? {#how-does-it-work}
-In teoria, potremmo semplicemente memorizzare l'hash dei dati sulla catena e inviare tutti i dati nelle transazioni che lo richiedono. Anche questo però sarebbe troppo costoso. Un byte di dati per una transazione costa circa 16 gas, correntemente circa mezzo centesimo, o circa 5 dollari per kilobyte. 5.000 dollari per megabyte è un prezzo comunque proibitivo per molti utilizzi, anche senza il costo supplementare connesso all'hashing dei dati.
+In teoria potremmo semplicemente archiviare l'hash dei dati on-chain e inviare tutti i dati nelle transazioni che lo richiedono. Tuttavia, questo è ancora troppo costoso. Un byte di dati per una transazione costa circa 16 gas, attualmente circa mezzo centesimo, o circa 5 $ per kilobyte. A 5000 $ per megabyte, questo è ancora troppo costoso per molti usi, anche senza il costo aggiuntivo dell'hashing dei dati.
-La soluzione consiste nel procedere ripetutamente all'hashing di diverse sottoserie di dati, quindi per i dati che non devono essere inviati è sufficiente inviare un hash. A tale scopo puoi utilizzare un albero di Merkle, una struttura di dati ad albero in cui ogni nodo rappresenta un hash dei nodi sottostanti:
+La soluzione è eseguire ripetutamente l'hash di diversi sottoinsiemi di dati, in modo che per i dati che non è necessario inviare si possa semplicemente inviare un hash. Lo si fa utilizzando un albero di Merkle, una struttura dati ad albero in cui ogni nodo è un hash dei nodi sottostanti:
-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 archiviata on-chain. Per provare un certo valore, fornisci tutti gli hash che devono essere combinati con esso per ottenere la radice. Ad esempio, per provare `C` fornisci `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 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 utilizziamo JavaScript per i calcoli fuori catena. La maggior parte delle applicazioni decentralizzate ha il proprio componente fuori 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.
+Per prima cosa dobbiamo fornire la radice di Merkle alla catena.
```javascript
const ethers = require("ethers")
```
-[Usiamo la funzione hash dal pacchetto ethers](https://docs.ethers.io/v5/api/utils/hashing/#utils-keccak256).
+[Utilizziamo la funzione di 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 la cui integrità dobbiamo verificare. I primi due byte s
+// ono un identificatore utente, e gli ultimi due byte la quantità di token che l'
+// utente possiede attualmente.
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.
+La codifica di ogni voce in un singolo intero a 256 bit si traduce in un codice meno leggibile rispetto all'utilizzo di JSON, ad esempio. Tuttavia, questo significa un'elaborazione significativamente inferiore per recuperare i dati nel contratto, quindi costi del gas molto più bassi. [Puoi leggere JSON on-chain](https://github.com/chrisdotn/jsmnSol), è solo una cattiva idea se evitabile.
```javascript
-// The array of hash values, as BigInts
+// L'array dei valori di hash, come BigInt
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.
+In questo caso i nostri dati sono valori a 256 bit per cominciare, quindi non è necessaria alcuna elaborazione. Se utilizziamo una struttura dati più complicata, come le stringhe, dobbiamo assicurarci di eseguire prima l'hash dei dati per ottenere un array di hash. Nota che questo è anche perché non ci interessa se gli utenti conoscono le informazioni di altri utenti. Altrimenti avremmo dovuto eseguire l'hash in modo 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 di hash si aspetta e il
+// BigInt che usiamo in ogni altra parte.
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 di 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 è 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). Ciò significa che quando controlliamo la prova di Merkle non dobbiamo preoccuparci se inserire il valore della prova prima o dopo il valore calcolato. Il controllo della prova di Merkle viene eseguito on-chain, quindi meno dobbiamo 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ù difficile di quanto sembri.
+La versione iniziale di questo articolo aveva la funzione di hash `hash(a^b)`.
+È stata una **pessima** idea perché significava che se si conoscevano i valori legittimi di `a` e `b` si poteva usare `b' = a^b^a'` per provare qualsiasi valore `a'` desiderato.
+Con questa funzione dovresti calcolare `b'` in modo tale che `hash(a') ^ hash(b')` sia uguale a un valore noto (il ramo successivo sulla strada 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 per indicare che un certo ramo è vuoto, non
+// ha un valore
const empty = 0n
```
-Quando il numero di valori non è una potenza intera di due, dobbiamo gestire i rami vuoti. A tale scopo, questo programma inserisce zero come segnaposto.
+Quando il numero di valori non è una potenza intera di due, dobbiamo gestire i rami vuoti. Il modo in cui questo programma lo fa è inserire zero come segnaposto.
```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)
@@ -111,13 +114,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 "sale" di un livello nell'albero di Merkle eseguendo l'hash delle 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` 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] // Risale l'albero finché non c'è un solo valore, ovvero la // radice. // // Se un livello ha un numero dispari di voci, il // codice in oneLevelUp aggiunge un valore vuoto, quindi se abbiamo, per 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)
@@ -125,57 +128,57 @@ const getMerkleRoot = (inputArray) => {
}
```
-Per ottenere la radice, scala finché non resta un solo valore.
+Per ottenere la radice, sali finché non rimane 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.
+Una prova di Merkle è costituita dai valori di cui eseguire l'hash insieme al valore da provare per riottenere la radice di Merkle. Il valore da provare è spesso disponibile da altri dati, quindi preferisco fornirlo separatamente piuttosto che 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 della lista di voci da
+// sottoporre a hash. Poiché usiamo una funzione di hash simmetrica, non
+// abbiamo bisogno della posizione dell'elemento per verificare la prova, 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 con il valore che lo precede alla prova
? currentLayer[currentN-1]
- // If it is even, add the value after it
+ // Se è pari, aggiungi il valore che lo segue
: currentLayer[currentN+1])
```
-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.
+Eseguiamo l'hash di `(v[0],v[1])`, `(v[2],v[3])`, ecc. Quindi per i valori pari abbiamo bisogno di quello successivo, per i valori dispari di quello precedente.
```javascript
- // Move to the next layer up
+ // Passa al livello successivo superiore
currentN = Math.floor(currentN/2)
currentLayer = oneLevelUp(currentLayer)
- } // while currentLayer.length > 1
+ } // while currentLayer.length > 1
return result
-} // getMerkleProof
+} // getMerkleProof
```
-### Codice on-chain {#on-chain-code}
+### Codice on-chain {#onchain-code}
-Finalmente abbiamo il codice che verifica la prova. Il codice on-chain è scritto in [Solidity](https://docs.soliditylang.org/en/v0.8.11/). L'ottimizzazione è molto più importante qui, perché il gas è relativamente costoso.
+Infine abbiamo il codice che controlla 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.
```solidity
-//SPDX-License-Identifier: Public Domain
+// SPDX-License-Identifier: Public Domain
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 utilizzando 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
@@ -186,15 +189,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 strettamente limitato, probabilmente a un
+ // proprietario
function setRoot(uint _merkleRoot) external {
merkleRoot = _merkleRoot;
- } // setRoot
+ } // 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**.
+Funzioni set e get per la radice di Merkle. Lasciare che tutti aggiornino la radice di Merkle è un'_idea estremamente pessima_ in un sistema di produzione. Lo faccio qui per motivi di semplicità per il codice di esempio. **Non farlo su un sistema in cui l'integrità dei dati è davvero importante**.
```solidity
function hash(uint _a) internal pure returns(uint) {
@@ -206,12 +209,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 un hash di 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 archiviare 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;
@@ -224,19 +227,21 @@ Questa funzione genera l'hash di una coppia. È semplicemente la traduzione di S
return temp == merkleRoot;
}
-} // MarkleProof
+} // 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 si mescolano {#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.
+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 sul livello 1 (L1), ma li elaborano sul livello 2 (L2). Il costo per inviare una prova di Merkle con una transazione è in media di 638 gas per livello (attualmente un byte nei dati di 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.
+Guardando ad esempio a [Optimism](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m), la scrittura del gas su L1 costa circa 100 gwei e il gas su L2 costa 0,001 gwei (questo è il prezzo normale, può aumentare con la congestione). Quindi, per il costo di un gas su L1 possiamo spendere centomila gas per l'elaborazione su L2. Supponendo di non sovrascrivere l'archiviazione, ciò significa che possiamo scrivere circa cinque parole nell'archiviazione su L2 al prezzo di un gas su L1. Per una singola prova di Merkle possiamo scrivere l'intero blocco di 1024 parole nell'archiviazione (supponendo che possano essere calcolate on-chain in primo luogo, piuttosto che fornite in una transazione) e avere ancora 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.
+Nella vita reale potresti non implementare mai gli alberi di Merkle da solo. Ci sono librerie ben note e controllate che puoi usare e, in generale, è meglio non implementare primitive crittografiche da soli. Ma spero che ora tu capisca 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.
+Nota che mentre le prove di Merkle preservano l'_integrità_, non preservano la _disponibilità_. Sapere che nessun altro può prendere i tuoi asset è una magra consolazione se l'archiviazione dei dati decide di negare l'accesso e non puoi nemmeno costruire un albero di Merkle per accedervi. Quindi gli alberi di Merkle sono usati al meglio con un qualche tipo di archiviazione decentralizzata, come IPFS.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
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 fad1fc3e6b8..b2a69b08d7b 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,27 +1,25 @@
---
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
-breadcrumb: "Monitorare Geth"
+breadcrumb: Monitorare Geth
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).
+- La maggior parte dei passaggi e degli esempi sono per 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 che possono essere letti sotto forma di database cronologico. Per semplificare il monitoraggio, puoi inserire questi dati in un software di visualizzazione dei dati. Ci sono diverse opzioni disponibili:
- [Prometheus](https://prometheus.io/) (modello pull)
- [InfluxDB](https://www.influxdata.com/get-influxdb/) (modello push)
@@ -30,13 +28,14 @@ Un client di Ethereum raccoglie molti dati leggibili sotto forma di database cro
- [Datadog](https://www.datadoghq.com/)
- [Chronograf](https://www.influxdata.com/time-series-platform/chronograf/)
-Esiste anche [Geth Prometheus Exporter](https://github.com/hunterlong/gethexporter), un'opzione preconfigurata con InfluxDB e Grafana.
+C'è 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 i 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}
-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 possono essere trovate nella [pagina delle versioni di Influxdata](https://portal.influxdata.com/downloads/). Scegli quella più 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
@@ -49,13 +48,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 con successo InfluxDB, assicurati che sia in esecuzione in background. Per impostazione predefinita, è raggiungibile su `localhost:8086`.
+Prima di utilizzare 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 accedere alla [shell di InfluxDB](https://docs.influxdata.com/influxdb/v1.8/tools/shell/) con questo utente.
```
influx -username 'username' -password 'password'
@@ -81,19 +81,20 @@ 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}
-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 i dati con successo, ad esempio elencando le metriche nel database. Nella shell di InfluxDB:
```
use geth
@@ -102,7 +103,8 @@ show measurements
## Configurare 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 il processo di installazione per il tuo ambiente nella documentazione di Grafana. Assicurati di installare la versione OSS se non desideri diversamente.
+Esempio di passaggi di installazione per distribuzioni Debian utilizzando il repository:
```
curl -tlsv1.3 --proto =https -sL https://packages.grafana.com/gpg.key | sudo apt-key add -
@@ -113,36 +115,38 @@ 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 su `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, cambia 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".
+Verrai reindirizzato alla home page di Grafana. Per prima cosa, configura i tuoi dati di origine. Clicca sull'icona di configurazione nella barra di sinistra e seleziona "Data sources" (Origini 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, clicca su "Add data source" (Aggiungi origine dati) per definirne una.
-
+
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 stai eseguendo gli strumenti sulla stessa macchina. Devi 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, clicca su "Save and test" (Salva e testa) e attendi che appaia la 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 configurato per leggere i dati da InfluxDB. Ora devi creare una dashboard che li interpreterà e li visualizzerà. Le proprietà delle dashboard sono codificate in file JSON che possono essere creati da chiunque e facilmente importati. Sulla barra di sinistra, clicca su "Create and Import" (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 di Geth, copia l'ID di [questa dashboard](https://grafana.com/grafana/dashboards/13877/) e incollalo nella "Import page" (Pagina di importazione) in 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 cambiare le tue configurazioni. Dipende da te! Per saperne di più su come funzionano le dashboard, fai riferimento alla [documentazione di Grafana](https://grafana.com/docs/grafana/latest/dashboards/).
+Potresti anche essere interessato agli [Avvisi](https://grafana.com/docs/grafana/latest/alerting/). Questo ti permette di configurare notifiche di avviso per quando le metriche raggiungono determinati valori. Sono supportati vari canali di comunicazione.
\ No newline at end of file
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 cf809e6af92..0224200590d 100644
--- a/public/content/translations/it/developers/tutorials/nft-minter/index.md
+++ b/public/content/translations/it/developers/tutorials/nft-minter/index.md
@@ -1,104 +1,98 @@
---
-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.
+title: Tutorial sul minter di NFT
+description: In questo tutorial, costruirai un minter di NFT e imparerai come creare una dApp full stack collegando il tuo contratto intelligente a un frontend React utilizzando MetaMask e strumenti Web3.
author: "smudgil"
-tags:
- - "solidity"
- - "NFT"
- - "alchemy"
- - "contratti intelligenti"
- - "frontend"
- - "Pinata"
+tags: ["Solidity", "NFT", "Alchemy", "contratti intelligenti", "frontend", "Pinata", "erc-721"]
skill: intermediate
-breadcrumb: "Dapp conio NFT"
+breadcrumb: dApp per coniare NFT
lang: it
published: 2021-10-06
---
-Una delle più grandi sfide per gli sviluppatori provenienti da Web2 è comprendere come connettere il proprio smart contract a un progetto di frontend, e come interagire con esso.
+Una delle sfide più grandi per gli sviluppatori provenienti da un background Web2 è capire come collegare il proprio contratto intelligente a un progetto frontend e interagirvi.
-Creando un coniatore di NFT, una semplice UI in cui è possibile inserire un link alla risorsa digitale, un titolo e una descrizione, imparerai come:
+Costruendo un minter di NFT — una semplice interfaccia utente in cui puoi inserire un link alla tua risorsa digitale, un titolo e una descrizione — imparerai come:
-- Connetterti a MetaMask tramite il progetto del tuo frontend
-- Chiamare i metodi dello smart contract dal tuo frontend
+- Connetterti a MetaMask tramite il tuo progetto frontend
+- Chiamare i metodi del contratto intelligente 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, utilizzeremo [React](https://react.dev/) come nostro framework frontend. Poiché questo tutorial è incentrato principalmente sullo sviluppo Web3, non dedicheremo molto tempo ad analizzare i fondamenti di React. Ci concentreremo invece sull'aggiunta di 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 una comprensione di livello base di React: sapere come funzionano i componenti, le prop, useState/useEffect e le chiamate di funzioni di base. Se non hai mai sentito nessuno di questi termini prima, potresti voler dare un'occhiata a questo [Tutorial introduttivo a React](https://react.dev/learn/tutorial-tic-tac-toe). Per chi apprende in modo più visivo, consigliamo vivamente questa eccellente serie di video [Full Modern React Tutorial](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, avrai sicuramente bisogno di un account Alchemy per completare questo tutorial e per costruire qualsiasi cosa sulla blockchain. Registrati per un account gratuito [qui](https://alchemy.com/).
-Iniziamo quindi!
+Senza ulteriori indugi, iniziamo!
-## 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:
+Prima ancora di iniziare a guardare il codice, è importante capire come funziona la creazione di un NFT. Prevede due passaggi:
-### Pubblicare lo smart contract di un NFT sulla blockchain di Ethereum {#publish-nft}
+### Pubblicare un contratto intelligente per 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.
+La più grande differenza tra i due standard di contratti intelligenti per NFT è che l'ERC-1155 è uno standard multi-token e include funzionalità in batch, mentre l'ERC-721 è uno standard a token singolo e pertanto supporta solo il trasferimento di un token alla volta.
-### Chiamare la funzione di conio {#minting-function}
+### Chiamare la funzione per coniare {#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.
+Di solito, questa funzione per coniare richiede di passare due variabili come parametri: primo, il `recipient`, che specifica l'indirizzo che riceverà il tuo NFT appena coniato, e secondo, 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 in realtà ciò che gli dà vita, consentendogli di avere proprietà, come un nome, una descrizione, un'immagine (o una diversa risorsa digitale) 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.
+In questo tutorial, ci concentreremo sulla parte 2, chiamando la funzione per coniare di un contratto intelligente di un NFT esistente utilizzando la nostra interfaccia utente 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) al contratto intelligente dell'NFT ERC-721 che chiameremo in questo tutorial. Se desideri imparare come lo abbiamo realizzato, ti consigliamo vivamente di dare un'occhiata al 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!
+Fantastico, ora che abbiamo capito come funziona la creazione di un NFT, cloniamo i nostri file di partenza!
-## Clonare i file iniziali {#clone-the-starter-files}
+## Clonare i file di partenza {#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.
+Per prima cosa, vai al [repository GitHub nft-minter-tutorial](https://github.com/alchemyplatform/nft-minter-tutorial) per ottenere i file di partenza 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 partenza (essenzialmente l'interfaccia utente React) per questo progetto. In questo tutorial, **lavoreremo in questa directory**, mentre impari come dare vita a questa interfaccia utente collegandola al tuo portafoglio Ethereum e a un contratto intelligente per NFT.
+- `nft-minter` contiene l'intero tutorial completato ed è lì per te come **riferimento** **se rimani bloccato.**
-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, e poi naviga nella tua 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 risiederà nella cartella `src`. Modificheremo il componente `Minter.js` e scriveremo file javascript aggiuntivi per dare al nostro progetto funzionalità Web3.
-## Fase 2: dai un'occhiata ai nostri file iniziali {#step-2-check-out-our-starter-files}
+## Passaggio 2: Dai un'occhiata ai nostri file di partenza {#step-2-check-out-our-starter-files}
-Prima di iniziare a programmare, è importante dare un'occhiata a ciò che è già disponibile nei file iniziali.
+Prima di iniziare a programmare, è importante dare un'occhiata a ciò che ci è già stato fornito nei file di partenza.
-### Metti in funzione il tuo progetto di React {#get-your-react-project-running}
+### Avviare il tuo 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.
+Iniziamo eseguendo il progetto React nel nostro browser. Il bello di React è che una volta che abbiamo il nostro progetto in esecuzione nel browser, qualsiasi modifica salvata verrà aggiornata in tempo reale 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 nella 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
```
-Così facendo, dovrebbe aprirsi http://localhost:3000/ nel browser, dove vedrai il frontend per il nostro progetto. Dovrebbe consistere in 3 campi: un luogo per inserire un link alla tua risorsa NFT, uno per inserire il nome e uno per fornire una descrizione.
+Così facendo dovrebbe aprirsi http://localhost:3000/ nel tuo browser, dove vedrai il frontend per il nostro progetto. Dovrebbe consistere in 3 campi: un posto dove inserire un link alla risorsa del tuo NFT, inserire il nome del tuo NFT e fornire una descrizione.
-Se provi a cliccare i pulsanti "Connetti Portafoglio" o "Conia NFT", noterai che non funzionano, questo perché devi ancora programmarne la funzionalità! :\)
+Se provi a cliccare sui pulsanti "Connect Wallet" o "Mint NFT", noterai che non funzionano: questo perché dobbiamo ancora programmare la loro funzionalità! :\)
### Il componente Minter.js {#minter-js}
**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 nella cartella `src` nel nostro editor e apriamo il file `Minter.js`. È importantissimo comprendere tutto in questo file, poiché è il componente React principale su cui lavoreremo.
-In cima al nostro file, abbiamo le nostre variabili di stato che aggiorneremo dopo eventi specifici.
+All'inizio di questo 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("")
@@ -106,42 +100,42 @@ 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 o hook di stato di React? Dai un'occhiata a [questa](https://legacy.reactjs.org/docs/hooks-state.html) documentazione.
-Ecco cosa rappresenta ognuna delle variabili:
+Ecco cosa rappresenta ciascuna 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
+- `status` - una stringa che contiene un messaggio da visualizzare nella parte inferiore dell'interfaccia utente
+- `name` - una stringa che memorizza il nome dell'NFT
+- `description` - una stringa che memorizza la descrizione dell'NFT
+- `url` - una stringa che è un link alla risorsa 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`, questo perché effettueremo chiamate API asincrone al loro interno! I loro nomi sono eponimi 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é gli viene passata una prop array vuota `[]` (vedi riga 3), verrà chiamato solo al _primo_ rendering del componente. Qui chiameremo il nostro listener del portafoglio e un'altra funzione del portafoglio per aggiornare la nostra interfaccia utente in modo da riflettere se un portafoglio è già connesso.
+- `connectWalletPressed` - questa funzione verrà chiamata per connettere il portafoglio MetaMask dell'utente alla nostra dApp.
+- `onMintPressed` - questa funzione verrà chiamata per coniare l'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.
+Verso la fine di questo file, abbiamo l'interfaccia utente del nostro componente. Se esamini attentamente questo codice, noterai che aggiorniamo le nostre variabili di stato `url`, `name` e `description` quando cambia l'input nei rispettivi campi di testo.
-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
+// la UI del nostro componente
return (
{status}
-
+
)
```
-Infine, vediamo dove viene aggiunto questo componente del Coniatore.
+Infine, vediamo dove viene aggiunto questo componente Minter.
-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 è iniettato 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!
+Ora che abbiamo capito con cosa stiamo lavorando, configuriamo il nostro portafoglio Ethereum!
-## Configura il tuo wallet Ethereum {#set-up-your-ethereum-wallet}
+## Configurare 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.
+Affinché gli utenti possano interagire con il tuo contratto intelligente, dovranno connettere il loro portafoglio Ethereum alla tua dApp.
-### Scarica MetaMask {#download-metamask}
+### Scaricare 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, useremo MetaMask, un portafoglio virtuale nel browser utilizzato per gestire l'indirizzo del tuo account Ethereum. Se vuoi capire meglio come funzionano le transazioni su Ethereum, dai un'occhiata a [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 crei un account, o se ne hai già uno, assicurati di passare alla "Rete di test Ropsten" in alto a destra \(in modo da non avere a che fare con denaro reale\).
-### Aggiungere ether da un Faucet {#add-ether-from-faucet}
+### Aggiungere ether da un rubinetto {#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 alcuni ETH finti. Per ottenere ETH puoi andare al [rubinetto Ropsten](https://faucet.ropsten.be/) e inserire l'indirizzo del tuo account Ropsten, quindi cliccare su "Send Ropsten Eth". Dovresti vedere gli ETH nel tuo account MetaMask poco dopo!
-### Controlla il tuo saldo {#check-your-balance}
+### Controllare 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, facciamo una richiesta [eth_getBalance](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_getbalance) utilizzando lo [strumento composer 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à la quantità di ETH nel nostro portafoglio. Dopo aver inserito l'indirizzo del tuo account MetaMask e cliccato su "Send Request", dovresti vedere una risposta come questa:
```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. Il wei è utilizzato come la più piccola denominazione di ether. La conversione da wei a eth è: 1 eth = 10¹⁸ wei. Quindi, se convertiamo 0xde0b6b3a7640000 in decimale, otteniamo 1\*10¹⁸ che equivale a 1 eth.
-Meno male! I nostri soldi finti ci sono tutti!
REACT_APP_PINATA_SECRET =
```
-Salva il file: sei pronto ora per scrivere la funzione per caricare i tuoi metadati di JSON su IPFS!
+Salva il file e poi sei pronto per iniziare a scrivere la funzione per caricare i tuoi metadati JSON su IPFS!
-### Implementa pinJSONToIPFS {#pin-json-to-ipfs}
+### Implementare pinJSONToIPFS {#pin-json-to-ipfs}
-Per nostra fortuna, Pinata ha un'[API specifica per caricare i dati JSON su IPFS](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json) e un comodo JavaScript con esempio di axios che possiamo usare, con alcune lievi modifiche.
+Fortunatamente per noi, Pinata ha un'[API specifica per caricare dati JSON su IPFS](https://docs.pinata.cloud/api-reference/endpoint/ipfs/pin-json-to-ipfs#pin-json) e un comodo esempio JavaScript con axios che possiamo usare, con alcune lievi modifiche.
-Nella cartella `utils` creiamo un altro file denominato `pinata.js` e poi importiamo il nostro codice segreto di Pinata e la chiave dal file .env, come segue:
+Nella tua cartella `utils`, creiamo un altro file chiamato `pinata.js` e poi importiamo il nostro segreto e la chiave Pinata dal file .env in questo modo:
```javascript
require("dotenv").config()
@@ -529,7 +523,7 @@ const key = process.env.REACT_APP_PINATA_KEY
const secret = process.env.REACT_APP_PINATA_SECRET
```
-Incolla quindi il codice aggiuntivo seguente nel file `pinata.js`. Non preoccuparti, analizzeremo per bene cosa significa!
+Successivamente, incolla il codice aggiuntivo qui sotto nel tuo file `pinata.js`. Non preoccuparti, analizzeremo cosa significa tutto!
```javascript
require("dotenv").config()
@@ -540,7 +534,7 @@ const axios = require("axios")
export const pinJSONToIPFS = async (JSONBody) => {
const url = `https://api.pinata.cloud/pinning/pinJSONToIPFS`
- //making axios POST request to Pinata ⬇️
+ // effettuando la richiesta POST con axios a Pinata ⬇️
return axios
.post(url, JSONBody, {
headers: {
@@ -565,63 +559,63 @@ export const pinJSONToIPFS = async (JSONBody) => {
}
```
-Quindi, cosa fa esattamente questo codice?
+Quindi cosa fa esattamente questo codice?
-Prima di tutto, importa [axios](https://www.npmjs.com/package/axios), un client HTTP basato su Promise per il browser e node.js, che useremo per creare una richiesta a Pinata.
+Per prima cosa, importa [axios](https://www.npmjs.com/package/axios), un client HTTP basato su promise per il browser e node.js, che useremo per fare una richiesta a Pinata.
-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`.
+Poi abbiamo la nostra funzione asincrona `pinJSONToIPFS`, che prende un `JSONBody` come input e la chiave e il segreto api Pinata nel suo header, il tutto per fare una richiesta POST alla loro 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 POST ha successo, la nostra funzione restituisce un oggetto JSON con il booleano `success` come true e il `pinataUrl` in cui sono stati fissati i nostri metadati. Useremo questo `pinataUrl` restituito come input `tokenURI` per la funzione per coniare del nostro contratto intelligente.
+- Se questa richiesta post fallisce, la nostra funzione restituisce un oggetto JSON con il booleano `success` come 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.
+Come per i tipi di ritorno della nostra funzione `connectWallet`, stiamo restituendo oggetti JSON in modo da poter usare i loro parametri per aggiornare le nostre variabili di stato e l'interfaccia utente.
-## Carica il tuo smart contract {#load-your-smart-contract}
+## Caricare il tuo contratto intelligente {#load-your-smart-contract}
-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`.
+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 contratto intelligente in modo da poter chiamare la sua 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 abbiamo menzionato in precedenza, in questo tutorial useremo [questo contratto intelligente per NFT esistente](https://ropsten.etherscan.io/address/0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE); tuttavia, se desideri imparare come lo abbiamo realizzato, o crearne uno tu stesso, ti consigliamo vivamente di dare un'occhiata al nostro altro 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` c'è un file `contract-abi.json`. Un'ABI è necessaria per specificare quale funzione invocherà un contratto, oltre a garantire che la funzione restituirà i dati nel formato che ti aspetti.
-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.
+Avremo anche bisogno di una chiave API Alchemy e dell'API Alchemy Web3 per connetterci alla blockchain di Ethereum e caricare il nostro contratto intelligente.
-### Crea la tua chiave API di Alchemy {#create-alchemy-api}
+### Creare la tua chiave API 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 account Alchemy, puoi generare una chiave API creando un'app. Questo ci consentirà di fare richieste alla rete di test Ropsten.
-Vai alla pagina “Crea App” nella tua dashboard di Alchemy passando su “App” nella barra di navigazione e cliccando “Crea App”.
+Naviga alla pagina "Create App" nella tua Dashboard Alchemy passando il mouse su "Apps" nella barra di navigazione e cliccando su "Create App".
-Dai un nome alla tua app (noi abbiamo scelto “Il mio primo NFT!", aggiungi una breve descrizione, seleziona “Staging” come Ambiente) serve per la contabilità della tua app e scegli "Ropsten" come rete.
+Dai un nome alla tua app, noi abbiamo scelto "My First NFT!", offri una breve descrizione, seleziona "Staging" per l'Ambiente utilizzato per la contabilità della tua app e scegli "Ropsten" per la tua rete.
-Clicca “Crea app” ed è tutto! La tua app dovrebbe apparire nella tabella seguente.
+Clicca su "Create app" e il gioco è fatto! La tua app dovrebbe apparire nella tabella sottostante.
-Fantastico, ora che abbiamo creato il nostro URL dell'API di Alchemy HTTP, copiamolo negli appunti...
+Fantastico, quindi ora che abbiamo creato il nostro URL API HTTP Alchemy, copialo negli appunti...
-…e poi aggiungiamolo al nostro file `.env`. Nel complesso, il file .env dovrebbe somigliare a questo:
+…e poi aggiungiamolo al nostro file `.env`. Nel complesso, il tuo file .env dovrebbe apparire così:
```text
REACT_APP_PINATA_KEY =
REACT_APP_PINATA_SECRET =
-REACT_APP_ALCHEMY_KEY = https://eth-ropsten.alchemyapi.io/v2/
+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).
+Ora che abbiamo l'ABI del nostro contratto e la nostra chiave API Alchemy, siamo pronti per caricare il nostro contratto intelligente utilizzando [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3).
-### Configura l'endpoint e il contratto di Web3 di Alchemy {#setup-alchemy-endpoint}
+### Configurare il tuo endpoint Alchemy Web3 e il contratto {#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:
+Per prima cosa, se non lo hai già, dovrai installare [Alchemy Web3](https://github.com/alchemyplatform/alchemy-web3) navigando nella directory home: `nft-minter-tutorial` nel terminale:
```text
cd ..
npm install @alch/alchemy-web3
```
-Torniamo quindi al nostro file `interact.js`. In cima al file, aggiungi il seguente codice per importare la tua chiave di Alchemy dal file .env e configurare il tuo endpoint di Alchemy Web3:
+Successivamente torniamo al nostro file `interact.js`. All'inizio del file, aggiungi il seguente codice per importare la tua chiave Alchemy dal tuo file .env e configurare il tuo endpoint Alchemy Web3:
```javascript
require("dotenv").config()
@@ -630,9 +624,9 @@ 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 attorno a [Web3.js](https://docs.web3js.org/), che fornisce metodi API migliorati e altri vantaggi cruciali per semplificarti la vita come sviluppatore web3. È progettato per richiedere una configurazione minima in modo da poter iniziare a usarlo subito nella tua app!
-In seguito, aggiungiamo l'ABI del nostro contratto e l'indirizzo del contratto al nostro file.
+Successivamente, aggiungiamo l'ABI del nostro contratto e l'indirizzo del contratto al nostro file.
```javascript
require("dotenv").config()
@@ -644,27 +638,27 @@ const contractABI = require("../contract-abi.json")
const contractAddress = "0x4C4a07F737Bf57F6632B6CAB089B78f62385aCaE"
```
-Una volta che abbiamo entrambi, siamo pronti a iniziare a programmare la nostra funzione di conio!
+Una volta che li abbiamo entrambi, siamo pronti per iniziare a programmare la nostra funzione per coniare!
-## Implementa la funzione mintNFT {#implement-the-mintnft-function}
+## Implementare la funzione mintNFT {#implement-the-mintnft-function}
-Nel file `interact.js`, definiamo la nostra funzione, `mintNFT`, che conierà il nostro omonimo NFT.
+All'interno del tuo file `interact.js`, definiamo la nostra funzione, `mintNFT`, che eponimamente conierà il 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.
+Poiché effettueremo numerose chiamate asincrone \(a Pinata per fissare i nostri metadati su IPFS, ad Alchemy Web3 per caricare il nostro contratto intelligente 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 per la nostra funzione saranno l'`url` della nostra risorsa digitale, il `name` e la `description`. 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:
+Naturalmente, ha senso avere una sorta di gestione degli errori di input all'inizio della funzione, in modo da uscire da questa funzione se i nostri parametri di input non sono corretti. All'interno della 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,
@@ -674,25 +668,25 @@ export const mintNFT = async (url, name, description) => {
}
```
-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` comunica che tutti i campi nella nostra interfaccia utente devono essere completati.
-### 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!
+Una volta che sappiamo che i nostri metadati sono formattati correttamente, il passaggio successivo è racchiuderli in un oggetto JSON e caricarli su IPFS tramite la funzione `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, dobbiamo prima importare la funzione `pinJSONToIPFS` nel nostro file `interact.js`. Proprio all'inizio di `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` accetta un corpo JSON. Quindi, prima di effettuare una chiamata ad essa, 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,
@@ -700,13 +694,13 @@ export const mintNFT = async (url, name, description) => {
}
}
- //make metadata
+ // crea i 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 {
@@ -718,29 +712,29 @@ 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.
+Nota, memorizziamo la risposta della nostra chiamata a `pinJSONToIPFS(metadata)` nell'oggetto `pinataResponse`. Quindi, analizziamo questo oggetto per 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 c'è un errore, restituiamo un oggetto JSON in cui il booleano `success` è false e la nostra stringa `status` comunica che la nostra chiamata è fallita. Altrimenti, estraiamo il `pinataURL` dalla `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`:
+Ora è il momento di caricare il nostro contratto intelligente utilizzando l'API Alchemy Web3 che abbiamo inizializzato all'inizio del nostro file. Aggiungi la seguente riga di codice in fondo alla funzione `mintNFT` per impostare il contratto nella variabile globale `window.contract`:
```javascript
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 nella 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 le pubblicazioni del contratto.
+ 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",
@@ -760,21 +754,21 @@ try {
}
```
-Se conosci già le transazioni di Ethereum, noterai che la struttura è abbastanza simile a quella che hai visto.
+Se hai già familiarità con le transazioni 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\)
+- Per prima cosa, impostiamo i parametri delle nostre transazioni.
+ - `to` specifica l'indirizzo del destinatario \(il nostro contratto intelligente\)
- `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.
+ - `data` contiene la chiamata al metodo `mintNFT` del nostro contratto intelligente, che riceve il nostro `tokenURI` e l'indirizzo del portafoglio dell'utente, `window.ethereum.selectedAddress`, come input
+- Quindi, effettuiamo una chiamata await, `window.ethereum.request,` in cui chiediamo a MetaMask di firmare la transazione. Nota, 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 chiederà all'utente di firmare o rifiutare la transazione.
+ - Se la transazione ha successo, la funzione restituirà un oggetto JSON in cui il booleano `success` è impostato su true e la stringa `status` invita l'utente a controllare Etherscan per maggiori informazioni sulla sua transazione.
+ - Se la transazione fallisce, la funzione restituirà un oggetto JSON in cui il booleano `success` è impostato su false e la stringa `status` comunica il messaggio di errore.
-Nel complesso, la nostra funzione `mintNFT` dovrebbe somigliare a questa:
+Nel complesso, la nostra funzione `mintNFT` dovrebbe apparire così:
```javascript
export const mintNFT = async (url, name, description) => {
- //error handling
+ // gestione degli errori
if (url.trim() == "" || name.trim() == "" || description.trim() == "") {
return {
success: false,
@@ -782,13 +776,13 @@ export const mintNFT = async (url, name, description) => {
}
}
- //make metadata
+ // crea i 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 {
@@ -798,19 +792,19 @@ export const mintNFT = async (url, name, description) => {
}
const tokenURI = pinataResponse.pinataUrl
- //load smart contract
- window.contract = await new web3.eth.Contract(contractABI, contractAddress) //loadContract();
+ // carica lo 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 le pubblicazioni del contratto.
+ 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 la transazione tramite MetaMask
try {
const txHash = await window.ethereum.request({
method: "eth_sendTransaction",
@@ -831,11 +825,11 @@ export const mintNFT = async (url, name, description) => {
}
```
-Questa è una funzione gigante! Ora, dobbiamo solo connettere la nostra funzione `mintNFT` al nostro componente `Minter.js`...
+È una funzione gigantesca! Ora, dobbiamo solo connettere la nostra funzione `mintNFT` al nostro componente `Minter.js`...
-## Connetti mintNFT al nostro frontend di Minter.js {#connect-our-frontend}
+## Connettere 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:
+Apri il tuo file `Minter.js` e aggiorna la riga `import { connectWallet, getCurrentWalletConnected } from "./utils/interact.js";` in alto in modo che sia:
```javascript
import {
@@ -845,7 +839,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 una chiamata await alla tua funzione `mintNFT` importata e aggiornare la variabile di stato `status` per riflettere se la nostra transazione ha avuto successo o è fallita:
```javascript
const onMintPressed = async () => {
@@ -854,22 +848,22 @@ const onMintPressed = async () => {
}
```
-## Distribuisci il tuo NFT a un sito web live {#deploy-your-NFT}
+## Distribuire il tuo NFT su 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 il tuo progetto live affinché gli utenti possano interagirvi? Dai un'occhiata a [questo tutorial](https://docs.alchemy.com/alchemy/tutorials/nft-minter/how-do-i-deploy-nfts-online) per distribuire il tuo Minter su un sito web live.
Un ultimo passaggio...
## Prendi d'assalto il mondo della blockchain {#take-the-blockchain-world-by-storm}
-Stiamo scherzando, sei arrivato alla fine del tutorial!
+Scherzavo, sei arrivato alla fine del tutorial!
-Per ricapitolare, creando un coniatore di NFT, hai imparato correttamente come:
+Per riassumere, costruendo un minter di NFT, hai imparato con successo come:
-- Connetterti a MetaMask tramite il progetto del tuo frontend
-- Chiamare i metodi dello smart contract dal tuo frontend
+- Connetterti a MetaMask tramite il tuo progetto frontend
+- Chiamare i metodi del contratto intelligente 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, ti piacerebbe poter mostrare gli NFT coniati tramite la tua dApp nel tuo portafoglio — quindi assicurati di dare 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 domande, siamo qui per aiutarti nel [Discord di Alchemy](https://discord.gg/gWuC7zB). Non vediamo l'ora di vedere come applicherai i concetti di questo tutorial ai tuoi progetti futuri!
\ No newline at end of file
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 e2d2f1cc106..f305196c91c 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,22 +1,25 @@
---
-title: "Guida del ponte standard di Optimism per contratti"
-description: Come funziona il ponte standard per Optimism? Perché funziona così?
+title: "Panoramica del contratto del ponte standard di Optimism"
+description: "Come funziona il ponte standard per Optimism? Perché funziona in questo modo?"
author: Ori Pomerantz
-tags:
- - "solidity"
- - "ponte"
- - "livello 2"
+tags: ["Solidity", "ponte", "livello 2"]
skill: intermediate
-breadcrumb: "Ponte Optimism"
+breadcrumb: Ponte di Optimism
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 inferiore rispetto alla rete principale di Ethereum (nota anche come livello 1 o L1) perché le transazioni vengono elaborate solo da pochi nodi, invece che da ogni nodo della rete.
+Allo stesso tempo, i dati vengono tutti scritti su L1, in modo 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 utilizzare gli asset di L1 su Optimism (o su qualsiasi altro L2), gli asset devono essere trasferiti tramite un [ponte](/bridges/#prerequisites).
+Un modo per ottenere questo risultato è che gli utenti blocchino gli asset (ETH e i [token ERC-20](/developers/docs/standards/tokens/erc-20/) sono i più comuni) su L1 e ricevano asset equivalenti da utilizzare su L2.
+Alla fine, chiunque ne entri in possesso potrebbe volerli riportare su L1 tramite il ponte.
+Quando si fa questo, gli asset vengono bruciati su L2 e poi rilasciati nuovamente 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 studiarlo come esempio di codice Solidity ben scritto.
## Flussi di controllo {#control-flows}
@@ -29,78 +32,88 @@ 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. Se si deposita un ERC-20, il depositante concede al ponte un'indennità (allowance) per spendere l'importo depositato
+2. Il depositante chiama il ponte di L1 (`depositERC20`, `depositERC20To`, `depositETH` o `depositETHTo`)
+3. Il ponte di L1 prende possesso dell'asset trasferito
+ - ETH: L'asset viene trasferito dal depositante come parte della chiamata
+ - ERC-20: L'asset viene trasferito dal ponte a se stesso utilizzando l'indennità fornita dal depositante
+4. Il ponte di L1 utilizza il meccanismo di messaggistica tra domini per chiamare `finalizeDeposit` sul ponte di 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
-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)).
-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.
+5. Il ponte di L2 verifica che la chiamata a `finalizeDeposit` sia legittima:
+ - Proviene dal contratto di messaggistica tra domini
+ - Proviene originariamente dal ponte su L1
+6. Il ponte di L2 controlla se il contratto del token ERC-20 su L2 è quello corretto:
+ - Il contratto di L2 segnala che la sua controparte di L1 è la stessa da cui provengono i token su L1
+ - Il contratto di L2 segnala che supporta l'interfaccia corretta ([utilizzando ERC-165](https://eips.ethereum.org/EIPS/eip-165)).
+7. Se il contratto di L2 è quello corretto, lo chiama per coniare il numero appropriato di token all'indirizzo appropriato. In caso contrario, avvia un processo di prelievo per consentire all'utente di reclamare i token su L1.
### Flusso di prelievo {#withdrawal-flow}
#### Livello 2 {#withdrawal-flow-layer-2}
-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
+1. Chi preleva chiama il ponte di L2 (`withdraw` o `withdrawTo`)
+2. Il ponte di L2 brucia il numero appropriato di token appartenenti a `msg.sender`
+3. Il ponte di L2 utilizza il meccanismo di messaggistica tra domini per chiamare `finalizeETHWithdrawal` o `finalizeERC20Withdrawal` sul ponte di 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
+4. Il ponte di L1 verifica che la chiamata a `finalizeETHWithdrawal` o `finalizeERC20Withdrawal` sia legittima:
+ - Proviene dal meccanismo di messaggistica tra domini
+ - Proviene originariamente dal ponte su L2
+5. Il ponte di L1 trasferisce l'asset appropriato (ETH o ERC-20) all'indirizzo appropriato
-## Codice del Livello 1 {#layer-1-code}
+## Codice di Livello 1 {#layer-1-code}
-Questo è il codice eseguito su L1, la rete principale di Ethereum.
+Questo è il codice che viene 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 funzioni e definizioni necessarie per trasferire tramite ponte 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 stesura, l'ultima versione di Solidity è la 0.8.12.
+Fino al rilascio della versione 0.9.0, non sappiamo se questo codice sarà compatibile o meno.
```solidity
-/**
- * @title IL1ERC20Bridge
- */
+/* *
+ * @title IL1ERC20Bridge */
+
+
+
interface IL1ERC20Bridge {
- /**********
- * Events *
- **********/
+ /* *********
+ * Eventi *
+ ********* */
+
+
+
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_ significa trasferimento da L1 a L2, e _prelievo_ significa 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 è lo stesso dell'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 test Kovan (42) e la rete di test Optimistic Kovan (69).
```solidity
address indexed _from,
@@ -110,7 +123,7 @@ Nella maggior parte dei casi, l'indirizzo di un ERC-20 su L1 non equivale all'in
);
```
-È possibile aggiungere note ai trasferimenti, nel qual caso sono aggiunti agli eventi che li segnalano.
+È possibile aggiungere note ai trasferimenti, nel qual caso vengono aggiunte agli eventi che li segnalano.
```solidity
event ERC20WithdrawalFinalized(
@@ -123,34 +136,51 @@ 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 di L1, questo significa l'inizializzazione dei depositi e la finalizzazione dei prelievi.
```solidity
- /********************
- * Public Functions *
- ********************/
+ /* *******************
+ * Funzioni Pubbliche *
+ ******************* */
+
+
+
+
+ /* *
+ * @dev ottiene l'indirizzo del contratto ponte L2 corrispondente.
+ * @return Indirizzo del contratto ponte L2 corrispondente. */
+
+
+
- /**
- * @dev get the address of the corresponding L2 bridge contract.
- * @return Address of the corresponding L2 bridge contract.
- */
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 è realmente necessaria, perché su L2 è un contratto pre-distribuito, quindi si trova sempre all'indirizzo `0x4200000000000000000000000000000000000010`.
+È qui per simmetria con il ponte di L2, perché l'indirizzo del ponte di L1 _non_ è banale da conoscere.
```solidity
- /**
- * @dev deposit an amount of the ERC20 to the caller's balance on L2.
- * @param _l1Token Address of the L1 ERC20 we are depositing
- * @param _l2Token Address of the L1 respective L2 ERC20
- * @param _amount Amount of the ERC20 to deposit
- * @param _l2Gas Gas limit required to complete the deposit on L2.
- * @param _data Optional data to forward to L2. This data is provided
- * solely as a convenience for external contracts. Aside from enforcing a maximum
- * length, these contracts provide no guarantees about its content.
- */
+ /* *
+ * @dev deposita un importo di ERC20 sul saldo del chiamante su L2.
+ * @param _l1Token Indirizzo dell'ERC20 L1 che stiamo depositando
+ * @param _l2Token Indirizzo del rispettivo ERC20 L2 di L1
+ * @param _amount Importo di ERC20 da depositare
+ * @param _l2Gas Limite del gas richiesto per completare il deposito su L2.
+ * @param _data Dati opzionali da inoltrare a L2. Questi dati sono forniti
+ * esclusivamente per comodità dei contratti esterni. A parte l'imposizione di una
+ * lunghezza massima, questi contratti non forniscono alcuna garanzia sul loro contenuto. */
+
+
+
+
+
+
+
+
+
+
function depositERC20(
address _l1Token,
address _l2Token,
@@ -160,20 +190,32 @@ 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` è la quantità di gas di 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 trasferisce tramite ponte gli asset allo stesso indirizzo su una blockchain diversa.
```solidity
- /**
- * @dev deposit an amount of ERC20 to a recipient's balance on L2.
- * @param _l1Token Address of the L1 ERC20 we are depositing
- * @param _l2Token Address of the L1 respective L2 ERC20
- * @param _to L2 address to credit the withdrawal to.
- * @param _amount Amount of the ERC20 to deposit.
- * @param _l2Gas Gas limit required to complete the deposit on L2.
- * @param _data Optional data to forward to L2. This data is provided
- * solely as a convenience for external contracts. Aside from enforcing a maximum
- * length, these contracts provide no guarantees about its content.
- */
+ /* *
+ * @dev deposita un importo di ERC20 sul saldo di un destinatario su L2.
+ * @param _l1Token Indirizzo dell'ERC20 L1 che stiamo depositando
+ * @param _l2Token Indirizzo del rispettivo ERC20 L2 di L1
+ * @param _to Indirizzo L2 a cui accreditare il prelievo.
+ * @param _amount Importo di ERC20 da depositare.
+ * @param _l2Gas Limite del gas richiesto per completare il deposito su L2.
+ * @param _data Dati opzionali da inoltrare a L2. Questi dati sono forniti
+ * esclusivamente per comodità dei contratti esterni. A parte l'imposizione di una
+ * lunghezza massima, questi contratti non forniscono alcuna garanzia sul loro contenuto. */
+
+
+
+
+
+
+
+
+
+
+
function depositERC20To(
address _l1Token,
address _l2Token,
@@ -184,27 +226,43 @@ Il parametro `_l2Gas` è l'importo di gas del L2 che la transazione può spender
) external;
```
-Questa funzione è quasi identica a `depositERC20`, ma ti consente di inviare l'ERC-20 a un altro indirizzo.
+Questa funzione è quasi identica a `depositERC20`, ma ti consente di inviare l'ERC-20 a un indirizzo diverso.
```solidity
- /*************************
- * Cross-chain Functions *
- *************************/
+ /* ************************
+ * Funzioni Cross-chain *
+ ************************ */
+
+
- /**
- * @dev Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the
- * L1 ERC20 token.
- * This call will fail if the initialized withdrawal from L2 has not been finalized.
+
+ /* *
+ * @dev Completa un prelievo da L2 a L1 e accredita i fondi sul saldo del destinatario del
+ * token ERC20 L1.
+ * Questa chiamata fallirà se il prelievo inizializzato da L2 non è stato finalizzato.
*
- * @param _l1Token Address of L1 token to finalizeWithdrawal for.
- * @param _l2Token Address of L2 token where withdrawal was initiated.
- * @param _from L2 address initiating the transfer.
- * @param _to L1 address to credit the withdrawal to.
- * @param _amount Amount of the ERC20 to deposit.
- * @param _data Data provided by the sender on L2. This data is provided
- * solely as a convenience for external contracts. Aside from enforcing a maximum
- * length, these contracts provide no guarantees about its content.
- */
+ * @param _l1Token Indirizzo del token L1 per cui eseguire finalizeWithdrawal.
+ * @param _l2Token Indirizzo del token L2 in cui è stato avviato il prelievo.
+ * @param _from Indirizzo L2 che avvia il trasferimento.
+ * @param _to Indirizzo L1 a cui accreditare il prelievo.
+ * @param _amount Importo di ERC20 da depositare.
+ * @param _data Dati forniti dal mittente su L2. Questi dati sono forniti
+ * esclusivamente per comodità dei contratti esterni. A parte l'imposizione di una
+ * lunghezza massima, questi contratti non forniscono alcuna garanzia sul loro contenuto. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
function finalizeERC20Withdrawal(
address _l1Token,
address _l2Token,
@@ -216,16 +274,20 @@ 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:
+I prelievi (e altri messaggi da L2 a L1) in Optimism sono un processo 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 reclamo su L1.
+ Questa transazione deve avvenire dopo la fine del [periodo di contestazione dei guasti](https://community.optimism.io/docs/how-optimism-works/#fault-proofs) per la transazione di 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 di eventi e funzioni per gli ETH.
+Queste definizioni sono molto simili a quelle definite in `IL1ERC20Bridge` sopra per gli 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 in due file perché alcuni token ERC-20 richiedono un'elaborazione personalizzata e non possono essere gestiti dal ponte standard.
+In questo modo il ponte personalizzato che gestisce tale token può implementare `IL1ERC20Bridge` e non dover trasferire anche gli ETH.
```solidity
// SPDX-License-Identifier: MIT
@@ -233,13 +295,18 @@ pragma solidity >0.5.0 <0.9.0;
import "./IL1ERC20Bridge.sol";
-/**
- * @title IL1StandardBridge
- */
+/* *
+ * @title IL1StandardBridge */
+
+
+
interface IL1StandardBridge is IL1ERC20Bridge {
- /**********
- * Events *
- **********/
+ /* *********
+ * Eventi *
+ ********* */
+
+
+
event ETHDepositInitiated(
address indexed _from,
address indexed _to,
@@ -248,7 +315,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`), tranne per l'assenza degli indirizzi dei token di L1 e L2.
+Lo stesso vale per gli altri eventi e le funzioni.
```solidity
event ETHWithdrawalFinalized(
@@ -257,42 +325,65 @@ Questo evento è quasi identico alla versione di ERC-20 (`ERC20DepositInitiated`
.
);
- /********************
- * Public Functions *
- ********************/
+ /* *******************
+ * Funzioni Pubbliche *
+ ******************* */
+
- /**
- * @dev Deposit an amount of the ETH to the caller's balance on L2.
- .
+
+
+ /* *
+ * @dev Deposita un importo di ETH sul saldo del chiamante su L2.
.
.
- */
+ . */
+
+
+
+
+
+
function depositETH(uint32 _l2Gas, bytes calldata _data) external payable;
- /**
- * @dev Deposit an amount of ETH to a recipient's balance on L2.
- .
+ /* *
+ * @dev Deposita un importo di ETH sul saldo di un destinatario su L2.
.
.
- */
+ . */
+
+
+
+
+
+
function depositETHTo(
address _to,
uint32 _l2Gas,
bytes calldata _data
) external payable;
- /*************************
- * Cross-chain Functions *
- *************************/
+ /* ************************
+ * Funzioni Cross-chain *
+ ************************ */
+
- /**
- * @dev Complete a withdrawal from L2 to L1, and credit funds to the recipient's balance of the
- * L1 ETH token. Since only the xDomainMessenger can call this function, it will never be called
- * before the withdrawal is finalized.
- .
+
+
+ /* *
+ * @dev Completa un prelievo da L2 a L1 e accredita i fondi sul saldo del destinatario del
+ * token ETH L1. Poiché solo xDomainMessenger può chiamare questa funzione, non verrà mai chiamata
+ * prima che il prelievo sia finalizzato.
.
.
- */
+ . */
+
+
+
+
+
+
+
+
function finalizeETHWithdrawal(
address _from,
address _to,
@@ -304,62 +395,86 @@ 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) viene 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
pragma solidity >0.5.0 <0.9.0;
+/* Importazioni di Interfacce */
/* Interface Imports */
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 tra domini.
+Questo messaggero tra domini è un sistema completamente diverso e merita un articolo a sé, che spero di scrivere in futuro.
```solidity
-/**
+/* *
* @title CrossDomainEnabled
- * @dev Helper contract for contracts performing cross-domain communications
+ * @dev Contratto di supporto per i contratti che eseguono comunicazioni cross-domain
*
- * Compiler used: defined by inheriting contract
- */
+ * Compilatore utilizzato: definito dal contratto che eredita */
+
+
+
+
+
+
contract CrossDomainEnabled {
- /*************
- * Variables *
- *************/
+ /* ************
+ * Variabili *
+ ************ */
+
+
+
- // Messenger contract used to send and receive messages from the other domain.
+ // Contratto Messenger utilizzato per inviare e ricevere messaggi dall'altro dominio.
address public messenger;
- /***************
- * Constructor *
- ***************/
+ /* **************
+ * Costruttore *
+ ************** */
+
+
+
+
+ /* *
+ * @param _messenger Indirizzo del CrossDomainMessenger sul livello corrente. */
+
+
- /**
- * @param _messenger Address of the CrossDomainMessenger on the current layer.
- */
constructor(address _messenger) {
messenger = _messenger;
}
```
-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 tra domini su questo livello.
+Questo parametro viene impostato una volta, nel costruttore, e non cambia mai.
```solidity
- /**********************
- * Function Modifiers *
- **********************/
+ /* *********************
+ * Modificatori di Funzione *
+ ********************* */
+
+
+
+
+ /* *
+ * Impone che la funzione modificata sia chiamabile solo da uno specifico account cross-domain.
+ * @param _sourceDomainAccount L'unico account sul dominio di origine che è
+ * autenticato per chiamare questa funzione. */
+
+
+
+
- /**
- * Enforces that the modified function is only callable by a specific cross-domain account.
- * @param _sourceDomainAccount The only account on the originating domain which is
- * authenticated to call this function.
- */
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 tra domini è accessibile da qualsiasi contratto sulla blockchain in cui è in esecuzione (sia la rete principale di Ethereum che Optimism).
+Ma abbiamo bisogno che il ponte su ciascun lato si fidi _solo_ di determinati messaggi se provengono dal ponte sull'altro lato.
```solidity
require(
@@ -368,7 +483,7 @@ La messaggistica interdominio è accessibile da qualsiasi contratto sulla blockc
);
```
-Solo i messaggi dalla messaggistica interdominio appropriata (`messenger`, come vedi di seguito) sono affidabili.
+Ci si può fidare solo dei messaggi provenienti dal messaggero tra domini appropriato (`messenger`, come vedi di seguito).
```solidity
@@ -378,7 +493,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 tra domini 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).
+Finché viene chiamata nella transazione avviata dal messaggio, può fornire queste informazioni.
Dobbiamo assicurarci che il messaggio ricevuto provenga dall'altro ponte.
@@ -387,31 +503,45 @@ Dobbiamo assicurarci che il messaggio ricevuto provenga dall'altro ponte.
_;
}
- /**********************
- * Internal Functions *
- **********************/
+ /* *********************
+ * Funzioni Interne *
+ ********************* */
+
+
+
+
+ /* *
+ * Ottiene il messenger, di solito dallo storage. Questa funzione è esposta nel caso in cui un contratto figlio
+ * debba sovrascriverla.
+ * @return L'indirizzo del contratto messenger cross-domain che dovrebbe essere utilizzato. */
+
+
+
+
- /**
- * Gets the messenger, usually from storage. This function is exposed in case a child contract
- * needs to override.
- * @return The address of the cross-domain messenger contract which should be used.
- */
function getCrossDomainMessenger() internal virtual returns (ICrossDomainMessenger) {
return ICrossDomainMessenger(messenger);
}
```
-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 tra domini.
+Utilizziamo una funzione anziché la variabile `messenger` per consentire ai contratti che ereditano da questo di utilizzare un algoritmo per specificare quale messaggero tra domini utilizzare.
```solidity
- /**
- * Sends a message to an account on another domain
- * @param _crossDomainTarget The intended recipient on the destination domain
- * @param _message The data to send to the target (usually calldata to a function with
+ /* *
+ * Invia un messaggio a un account su un altro dominio
+ * @param _crossDomainTarget Il destinatario previsto sul dominio di destinazione
+ * @param _message I dati da inviare al target (di solito calldata per una funzione con
* `onlyFromCrossDomainAccount()`)
- * @param _gasLimit The gasLimit for the receipt of the message on the target domain.
- */
+ * @param _gasLimit Il limite del gas per la ricezione del messaggio sul dominio di destinazione. */
+
+
+
+
+
+
+
function sendCrossDomainMessage(
address _crossDomainTarget,
uint32 _gasLimit,
@@ -425,7 +555,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 innesca 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)
@@ -436,20 +567,22 @@ 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, 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 codice sorgente di questo contratto è qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol).
+[Il codice sorgente per questo contratto è qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol).
```solidity
// SPDX-License-Identifier: MIT
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 un'ampia gamma di versioni di Solidity.
+Ma il ponte stesso è il nostro contratto e possiamo essere rigorosi su quale versione di Solidity utilizza.
```solidity
+/* Importazioni di Interfacce */
/* Interface Imports */
import { IL1StandardBridge } from "./IL1StandardBridge.sol";
import { IL1ERC20Bridge } from "./IL1ERC20Bridge.sol";
@@ -461,65 +594,76 @@ 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ù a riguardo qui](/developers/tutorials/erc20-annotated-code/#the-interface).
```solidity
+/* Importazioni di Librerie */
/* Library Imports */
import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol";
```
-[Come spiegato sopra](#crossdomainenabled), questo contratto è usato per la messaggistica tra livelli.
+[Come spiegato sopra](#crossdomainenabled), questo contratto viene utilizzato per la messaggistica tra livelli.
```solidity
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 per i contratti di L2 che hanno sempre lo stesso indirizzo. Questo 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).
+[Le utilità Address di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Address.sol). Vengono utilizzate per distinguere tra gli indirizzi dei contratti e quelli appartenenti agli account controllati esternamente (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.
+Nota che questa non è una soluzione perfetta, perché non c'è modo di distinguere tra chiamate dirette e chiamate effettuate dal costruttore di un contratto, ma almeno questo ci consente di identificare e prevenire alcuni errori comuni degli utenti.
```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`
+1. Revert (Annullamento)
+2. Restituire `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).
+Gestire entrambi i casi renderebbe il nostro codice più complicato, quindi utilizziamo invece [`SafeERC20` di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol), che si assicura che [tutti i fallimenti si traducano in un annullamento](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/utils/SafeERC20.sol#L96).
```solidity
-/**
+/* *
* @title L1StandardBridge
- * @dev The L1 ETH and ERC20 Bridge is a contract which stores deposited L1 funds and standard
- * tokens that are in use on L2. It synchronizes a corresponding L2 Bridge, informing it of deposits
- * and listening to it for newly finalized withdrawals.
- *
- */
+ * @dev Il ponte L1 ETH e ERC20 è un contratto che memorizza i fondi L1 depositati e i token
+ * standard che sono in uso su L2. Sincronizza un ponte L2 corrispondente, informandolo dei depositi
+ * e ascoltandolo per i prelievi appena finalizzati.
+ * */
+
+
+
+
+
+
+
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 è il modo in cui specifichiamo di utilizzare il wrapper `SafeERC20` ogni volta che utilizziamo l'interfaccia `IERC20`.
```solidity
- /********************************
- * External Contract References *
- ********************************/
+ /* *******************************
+ * Riferimenti a Contratti Esterni *
+ ******************************* */
+
+
+
address public l2TokenBridge;
```
@@ -528,51 +672,75 @@ L'indirizzo di [L2StandardBridge](#the-l2-bridge-contract).
```solidity
- // Maps L1 token to L2 token to balance of the L1 token deposited
+ // Mappa il token L1 al token L2 al saldo del token L1 depositato
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 un [array sparso bidimensionale](https://en.wikipedia.org/wiki/Sparse_matrix).
+I valori in questa struttura dati sono identificati come `deposit[L1 token addr][L2 token addr]`.
+Il valore predefinito è zero.
+Solo le celle impostate su un valore diverso vengono scritte nell'archiviazione.
```solidity
- /***************
- * Constructor *
- ***************/
+ /* **************
+ * Costruttore *
+ ************** */
+
+
+
- // This contract lives behind a proxy, so the constructor parameters will go unused.
+ // Questo contratto vive dietro un proxy, quindi i parametri del costruttore rimarranno inutilizzati.
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.
+Vogliamo poter aggiornare questo contratto senza dover copiare tutte le variabili nell'archiviazione.
+Per farlo utilizziamo un [`Proxy`](https://docs.openzeppelin.com/contracts/3.x/api/proxy), un contratto che utilizza [`delegatecall`](https://solidity-by-example.org/delegatecall/) per trasferire le chiamate a un contratto separato il cui indirizzo è memorizzato dal contratto proxy (quando si esegue l'aggiornamento si dice al proxy di cambiare quell'indirizzo).
+Quando si utilizza `delegatecall` l'archiviazione rimane quella del contratto _chiamante_, quindi i valori di tutte le variabili di stato del contratto non vengono 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 modello è che l'archiviazione del contratto che è il _chiamato_ di `delegatecall` non viene utilizzata e pertanto i valori del costruttore passati ad esso non hanno importanza.
+Questo è il motivo per cui possiamo fornire un valore senza senso al costruttore `CrossDomainEnabled`.
+È anche il motivo per cui l'inizializzazione di seguito è separata dal costruttore.
```solidity
- /******************
- * Initialization *
- ******************/
+ /* *****************
+ * Inizializzazione *
+ ***************** */
+
+
+
+
+ /* *
+ * @param _l1messenger Indirizzo del Messenger L1 utilizzato per le comunicazioni cross-chain.
+ * @param _l2TokenBridge Indirizzo del ponte standard L2. */
+
+
+
- /**
- * @param _l1messenger L1 Messenger address being used for cross-chain communications.
- * @param _l2TokenBridge L2 standard bridge address.
- */
// 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 vengono chiamate dal codice del contratto e potrebbero quindi essere dichiarate `external` invece di `public`.
+Il costo del gas delle funzioni `external` può essere inferiore, perché possono essere fornite con parametri nei calldata.
+Le funzioni dichiarate `public` devono essere accessibili dall'interno del contratto.
+I contratti non possono modificare i propri calldata, quindi i parametri devono essere in memoria.
+Quando una tale funzione viene chiamata esternamente, è necessario copiare i calldata in memoria, il che costa gas.
+In questo caso la funzione viene chiamata solo una volta, quindi l'inefficienza non ci importa.
```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 solo una volta.
+Se l'indirizzo del messaggero tra domini di L1 o del ponte dei token di L2 cambia, creiamo un nuovo proxy e un nuovo ponte che lo chiama.
+È improbabile che ciò accada, tranne 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:
+Nota che questa funzione non ha alcun meccanismo che limiti _chi_ può chiamarla.
+Ciò significa che in teoria un utente malintenzionato potrebbe aspettare fino a quando non distribuiamo il proxy e la 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 ci sono 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 vengono distribuiti direttamente da un EOA ma [in una transazione in cui un altro contratto li crea](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;
@@ -584,47 +752,62 @@ Questi sono i due parametri che il ponte deve conoscere.
```solidity
- /**************
- * Depositing *
- **************/
+ /* *************
+ * Deposito *
+ ************* */
+
+
+
+
+ /* * @dev Modificatore che richiede che il mittente sia un EOA. Questo controllo potrebbe essere aggirato da un contratto
+ * malevolo tramite initcode, ma si occupa dell'errore dell'utente che vogliamo evitare. */
+
+
- /** @dev Modifier requiring sender to be EOA. This check could be bypassed by a malicious
- * contract via initcode, but it takes care of the user error we want to avoid.
- */
modifier onlyEOA() {
- // Used to stop deposits from contracts (avoid accidentally lost tokens)
+ // Utilizzato per fermare i depositi dai contratti (evitare token persi accidentalmente)
require(!Address.isContract(msg.sender), "Account not EOA");
_;
}
```
-Per questo abbiamo bisogno delle utility `Address` di OpenZeppelin.
+Questo è il motivo per cui avevamo bisogno delle utilità `Address` di OpenZeppelin.
```solidity
- /**
- * @dev This function can be called with no data
- * to deposit an amount of ETH to the caller's balance on L2.
- * Since the receive function doesn't take data, a conservative
- * default amount is forwarded to L2.
- */
+ /* *
+ * @dev Questa funzione può essere chiamata senza dati
+ * per depositare un importo di ETH sul saldo del chiamante su L2.
+ * Poiché la funzione receive non accetta dati, un importo
+ * predefinito conservativo viene inoltrato a L2. */
+
+
+
+
+
+
receive() external payable onlyEOA {
_initiateETHDeposit(msg.sender, msg.sender, 200_000, bytes(""));
}
```
-Questa funzione serve per scopi di test. Non compare nelle definizioni dell'interfaccia: non è pensata per un uso ordinario.
+Questa funzione esiste a scopo di test.
+Nota che non appare nelle definizioni dell'interfaccia: non è per un uso normale.
```solidity
- /**
- * @inheritdoc IL1StandardBridge
- */
+ /* *
+ * @inheritdoc IL1StandardBridge */
+
+
+
function depositETH(uint32 _l2Gas, bytes calldata _data) external payable onlyEOA {
_initiateETHDeposit(msg.sender, msg.sender, _l2Gas, _data);
}
- /**
- * @inheritdoc IL1StandardBridge
- */
+ /* *
+ * @inheritdoc IL1StandardBridge */
+
+
+
function depositETHTo(
address _to,
uint32 _l2Gas,
@@ -634,30 +817,41 @@ 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
- /**
- * @dev Performs the logic for deposits by storing the ETH and informing the L2 ETH Gateway of
- * the deposit.
- * @param _from Account to pull the deposit from on L1.
- * @param _to Account to give the deposit to on L2.
- * @param _l2Gas Gas limit required to complete the deposit on L2.
- * @param _data Optional data to forward to L2. This data is provided
- * solely as a convenience for external contracts. Aside from enforcing a maximum
- * length, these contracts provide no guarantees about its content.
- */
+ /* *
+ * @dev Esegue la logica per i depositi memorizzando gli ETH e informando il Gateway ETH L2 del
+ * deposito.
+ * @param _from Account da cui prelevare il deposito su L1.
+ * @param _to Account a cui dare il deposito su L2.
+ * @param _l2Gas Limite del gas richiesto per completare il deposito su L2.
+ * @param _data Dati opzionali da inoltrare a L2. Questi dati sono forniti
+ * esclusivamente per comodità dei contratti esterni. A parte l'imposizione di una
+ * lunghezza massima, questi contratti non forniscono alcuna garanzia sul loro contenuto. */
+
+
+
+
+
+
+
+
+
+
function _initiateETHDeposit(
address _from,
address _to,
uint32 _l2Gas,
bytes memory _data
) internal {
- // Construct calldata for finalizeDeposit call
+ // Costruisce i calldata per la chiamata finalizeDeposit
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 tra domini è che il contratto di destinazione viene chiamato con il messaggio come suoi calldata.
+I contratti Solidity interpretano sempre i propri calldata in conformità con [le specifiche ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html).
+La funzione Solidity [`abi.encodeWithSelector`](https://docs.soliditylang.org/en/v0.8.12/units-and-global-variables.html#abi-encoding-and-decoding-functions) crea quei calldata.
```solidity
IL2ERC20Bridge.finalizeDeposit.selector,
@@ -670,24 +864,24 @@ 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 per rappresentare gli ETH (che non sono un token ERC-20) su L1 |
+| \_l2Token | Lib_PredeployAddresses.OVM_ETH | Il contratto di L2 che gestisce gli ETH su Optimism, `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` (questo contratto è solo per uso interno di Optimism) |
+| \_from | \_from | L'indirizzo su L1 che invia gli ETH |
+| \_to | \_to | L'indirizzo su L2 che riceve gli ETH |
+| amount | msg.value | Quantità di wei inviati (che sono già stati inviati al ponte) |
+| \_data | \_data | Dati aggiuntivi da allegare al deposito |
```solidity
- // Send calldata into L2
+ // Invia i calldata in L2
// slither-disable-next-line reentrancy-events
sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);
```
-Invia il messaggio tramite la messaggistica interdominio.
+Invia il messaggio tramite il messaggero tra domini.
```solidity
// slither-disable-next-line reentrancy-events
@@ -695,49 +889,66 @@ 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
- */
+ /* *
+ * @inheritdoc IL1ERC20Bridge */
+
+
+
function depositERC20(
- .
- .
- .
+ .
+ .
+ .
) external virtual onlyEOA {
_initiateERC20Deposit(_l1Token, _l2Token, msg.sender, msg.sender, _amount, _l2Gas, _data);
}
- /**
- * @inheritdoc IL1ERC20Bridge
- */
+ /* *
+ * @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 di ERC-20.
```solidity
- /**
- * @dev Performs the logic for deposits by informing the L2 Deposited Token
- * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom)
+ /* *
+ * @dev Esegue la logica per i depositi informando il contratto L2 Deposited Token
+ * del deposito e chiamando un gestore per bloccare i fondi L1. (es., transferFrom)
*
- * @param _l1Token Address of the L1 ERC20 we are depositing
- * @param _l2Token Address of the L1 respective L2 ERC20
- * @param _from Account to pull the deposit from on L1
- * @param _to Account to give the deposit to on L2
- * @param _amount Amount of the ERC20 to deposit.
- * @param _l2Gas Gas limit required to complete the deposit on L2.
- * @param _data Optional data to forward to L2. This data is provided
- * solely as a convenience for external contracts. Aside from enforcing a maximum
- * length, these contracts provide no guarantees about its content.
- */
+ * @param _l1Token Indirizzo dell'ERC20 L1 che stiamo depositando
+ * @param _l2Token Indirizzo del rispettivo ERC20 L2 di L1
+ * @param _from Account da cui prelevare il deposito su L1
+ * @param _to Account a cui dare il deposito su L2
+ * @param _amount Importo di ERC20 da depositare.
+ * @param _l2Gas Limite del gas richiesto per completare il deposito su L2.
+ * @param _data Dati opzionali da inoltrare a L2. Questi dati sono forniti
+ * esclusivamente per comodità dei contratti esterni. A parte l'imposizione di una
+ * lunghezza massima, questi contratti non forniscono alcuna garanzia sul loro contenuto. */
+
+
+
+
+
+
+
+
+
+
+
+
+
+
function _initiateERC20Deposit(
address _l1Token,
address _l2Token,
@@ -749,26 +960,29 @@ 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` sopra, con alcune importanti differenze.
+La prima differenza è che questa funzione riceve gli indirizzi dei token e l'importo da trasferire come parametri.
+Nel caso degli ETH, la chiamata al ponte include già il trasferimento dell'asset all'account del ponte (`msg.value`).
```solidity
- // When a deposit is initiated on L1, the L1 Bridge transfers the funds to itself for future
- // withdrawals. safeTransferFrom also checks if the contract has code, so this will fail if
- // _from is an EOA or address(0).
+ // Quando un deposito viene avviato su L1, il ponte L1 trasferisce i fondi a se stesso per futuri
+ // prelievi. safeTransferFrom controlla anche se il contratto ha del codice, quindi questo fallirà se
+ // _from è un EOA o address(0).
// slither-disable-next-line reentrancy-events, reentrancy-benign
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 agli 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'indennità 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 se 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 può avvenire in una transazione separata rispetto agli 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)
+ // Costruisce i calldata per _l2Token.finalizeDeposit(_to, _amount)
bytes memory message = abi.encodeWithSelector(
IL2ERC20Bridge.finalizeDeposit.selector,
_l1Token,
@@ -779,7 +993,7 @@ Il primo passaggio potrebbe verificarsi in una transazione separata dalle ultime
_data
);
- // Send calldata into L2
+ // Invia i calldata in L2
// slither-disable-next-line reentrancy-events, reentrancy-benign
sendCrossDomainMessage(l2TokenBridge, _l2Gas, message);
@@ -787,7 +1001,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 depositato di token alla struttura dati `deposits`.
+Potrebbero esserci più indirizzi su L2 che corrispondono allo stesso token ERC-20 di L1, quindi non è sufficiente utilizzare il saldo del ponte del token ERC-20 di L1 per tenere traccia dei depositi.
```solidity
@@ -795,13 +1010,18 @@ Aggiungi l'importo di token depositato alla struttura dei dati `deposits`. Potre
emit ERC20DepositInitiated(_l1Token, _l2Token, _from, _to, _amount, _data);
}
- /*************************
- * Cross-chain Functions *
- *************************/
+ /* ************************
+ * Funzioni Cross-chain *
+ ************************ */
+
+
+
+
+ /* *
+ * @inheritdoc IL1StandardBridge */
+
+
- /**
- * @inheritdoc IL1StandardBridge
- */
function finalizeETHWithdrawal(
address _from,
address _to,
@@ -809,20 +1029,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 di L2 invia un messaggio al messaggero tra domini di L2 che fa sì che il messaggero tra domini di 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.
+Si assicura che questo sia un messaggio _legittimo_, proveniente dal messaggero tra domini e originato dal ponte dei token di L2.
+Questa funzione viene utilizzata per prelevare ETH dal ponte, quindi dobbiamo assicurarci che venga 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 la quantità di wei in `msg.value`.
```solidity
require(success, "TransferHelper::safeTransferETH: ETH transfer failed");
@@ -831,14 +1052,16 @@ Il metodo per trasferire ETH è chiamare il destinatario indicando l'importo di
emit ETHWithdrawalFinalized(_from, _to, _amount, _data);
```
-Genera un evento riguardante il prelievo.
+Emette un evento relativo al prelievo.
```solidity
}
- /**
- * @inheritdoc IL1ERC20Bridge
- */
+ /* *
+ * @inheritdoc IL1ERC20Bridge */
+
+
+
function finalizeERC20Withdrawal(
address _l1Token,
address _l2Token,
@@ -849,17 +1072,17 @@ 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` 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 dati `deposits`.
```solidity
- // When a withdrawal is finalized on L1, the L1 Bridge transfers the funds to the withdrawer
+ // Quando un prelievo viene finalizzato su L1, il ponte L1 trasferisce i fondi a chi effettua il prelievo
// slither-disable-next-line reentrancy-events
IERC20(_l1Token).safeTransfer(_to, _amount);
@@ -868,29 +1091,44 @@ Aggiorna la struttura dei dati di `deposits`.
}
- /*****************************
- * Temporary - Migrating ETH *
- *****************************/
+ /* ****************************
+ * Temporaneo - Migrazione ETH *
+ **************************** */
+
+
+
+
+ /* *
+ * @dev Aggiunge saldo ETH all'account. Questo ha lo scopo di consentire la migrazione
+ * degli ETH da un vecchio gateway a un nuovo gateway.
+ * NOTA: Questo viene lasciato solo per un aggiornamento in modo da poter ricevere gli ETH migrati dal
+ * vecchio contratto */
+
+
+
+
+
- /**
- * @dev Adds ETH balance to the account. This is meant to allow for ETH
- * to be migrated from an old gateway to a new gateway.
- * NOTE: This is left for one upgrade only so we are able to receive the migrated ETH from the
- * old contract
- */
function donateETH() external payable {}
}
```
-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'era un'implementazione precedente del ponte.
+Quando siamo passati da quell'implementazione a questa, abbiamo dovuto spostare tutti gli asset.
+I token ERC-20 possono semplicemente essere spostati.
+Tuttavia, per trasferire ETH a un contratto è necessaria l'approvazione di quel contratto, che è ciò che ci fornisce `donateETH`.
-## 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 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 di L1.
+Se ci sono troppi token su L2, alcuni utenti non sarebbero in grado di riportare i propri asset su L1 tramite il ponte.
+Invece di un ponte affidabile, ricreeremmo essenzialmente il [sistema bancario a riserva frazionaria](https://www.investopedia.com/terms/f/fractionalreservebanking.asp).
+Se ci sono troppi token su L1, alcuni di quei token rimarrebbero bloccati per sempre all'interno del contratto del ponte perché non c'è modo di rilasciarli senza bruciare i token di 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 ha le funzioni e gli eventi di cui il ponte standard ha bisogno.
```solidity
// SPDX-License-Identifier: MIT
@@ -899,20 +1137,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 ERC-20 standard](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 lascia non specificati 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) viene 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 di L1 che è collegato tramite ponte a questo contratto.
+Nota che non abbiamo una funzione simile nella direzione opposta.
+Dobbiamo essere in grado di trasferire tramite ponte qualsiasi token di L1, indipendentemente dal fatto che il supporto per L2 fosse previsto o meno al momento della sua implementazione.
```solidity
@@ -925,11 +1167,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 tu non abbia bisogno di qualche tipo di logica personalizzata, dovresti usare questa.
```solidity
// SPDX-License-Identifier: MIT
@@ -938,7 +1182,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 verificata e deve essere abbastanza affidabile da contenere asset.
```solidity
import "./IL2StandardERC20.sol";
@@ -948,16 +1193,21 @@ 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 l'ERC-20 normalmente non richiede.
```solidity
- /**
- * @param _l2Bridge Address of the L2 standard bridge.
- * @param _l1Token Address of the corresponding L1 token.
- * @param _name ERC20 name.
- * @param _symbol ERC20 symbol.
- */
+ /* *
+ * @param _l2Bridge Indirizzo del ponte standard L2.
+ * @param _l1Token Indirizzo del token L1 corrispondente.
+ * @param _name Nome dell'ERC20.
+ * @param _symbol Simbolo dell'ERC20. */
+
+
+
+
+
+
constructor(
address _l2Bridge,
address _l1Token,
@@ -969,7 +1219,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
@@ -989,11 +1239,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 numero di funzioni supportate ed è identificata come l'[or esclusivo](https://it.wikipedia.org/wiki/Disgiunzione_esclusiva) dei [selettori di funzione ABI](https://docs.soliditylang.org/en/v0.8.12/abi-spec.html#function-selector) di quelle 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 di L2 utilizza 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 malevolo 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
@@ -1012,80 +1263,112 @@ 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 di 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 token sono tanto varie quanto il numero di modi per utilizzare l'ERC-20.
## Codice del ponte di 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 sorgente per questo contratto è qui](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol).
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;
+/* Importazioni di Interfacce */
/* Interface Imports */
import { IL1StandardBridge } from "../../L1/messaging/IL1StandardBridge.sol";
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 di 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 ETH e token ERC-20.
+ Su L2 possiamo utilizzare 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
+/* Importazioni di Librerie */
/* Library Imports */
import { ERC165Checker } from "@openzeppelin/contracts/utils/introspection/ERC165Checker.sol";
import { CrossDomainEnabled } from "../../libraries/bridge/CrossDomainEnabled.sol";
import { Lib_PredeployAddresses } from "../../libraries/constants/Lib_PredeployAddresses.sol";
+/* Importazioni di Contratti */
/* Contract Imports */
import { IL2StandardERC20 } from "../../standards/IL2StandardERC20.sol";
-/**
+/* *
* @title L2StandardBridge
- * @dev The L2 Standard bridge is a contract which works together with the L1 Standard bridge to
- * enable ETH and ERC20 transitions between L1 and L2.
- * This contract acts as a minter for new tokens when it hears about deposits into the L1 Standard
- * bridge.
- * This contract also acts as a burner of the tokens intended for withdrawal, informing the L1
- * bridge to release L1 funds.
- */
+ * @dev Il ponte Standard L2 è un contratto che lavora insieme al ponte Standard L1 per
+ * abilitare le transizioni di ETH ed ERC20 tra L1 e L2.
+ * Questo contratto agisce per coniare nuovi token quando viene a conoscenza di depositi nel ponte
+ * Standard L1.
+ * Questo contratto agisce anche come bruciatore dei token destinati al prelievo, informando il ponte
+ * L1 di rilasciare i fondi L1. */
+
+
+
+
+
+
+
+
+
contract L2StandardBridge is IL2ERC20Bridge, CrossDomainEnabled {
- /********************************
- * External Contract References *
- ********************************/
+ /* *******************************
+ * Riferimenti a Contratti Esterni *
+ ******************************* */
+
+
+
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 di L1.
+Nota che, a differenza dell'equivalente di L1, qui _abbiamo bisogno_ di questa variabile.
+L'indirizzo del ponte di L1 non è noto in anticipo.
```solidity
- /***************
- * Constructor *
- ***************/
+ /* **************
+ * Costruttore *
+ ************** */
+
+
+
+
+ /* *
+ * @param _l2CrossDomainMessenger Messenger cross-domain utilizzato da questo contratto.
+ * @param _l1TokenBridge Indirizzo del ponte L1 distribuito sulla catena principale. */
+
+
+
- /**
- * @param _l2CrossDomainMessenger Cross-domain messenger used by this contract.
- * @param _l1TokenBridge Address of the L1 bridge deployed to the main chain.
- */
constructor(address _l2CrossDomainMessenger, address _l1TokenBridge)
CrossDomainEnabled(_l2CrossDomainMessenger)
{
l1TokenBridge = _l1TokenBridge;
}
- /***************
- * Withdrawing *
- ***************/
+ /* **************
+ * Prelievo *
+ ************** */
+
+
+
+
+ /* *
+ * @inheritdoc IL2ERC20Bridge */
+
+
- /**
- * @inheritdoc IL2ERC20Bridge
- */
function withdraw(
address _l2Token,
uint256 _amount,
@@ -1095,9 +1378,11 @@ Tieni traccia dell'indirizzo del ponte L1. Nota che, a differenza dell'equivalen
_initiateWithdrawal(_l2Token, msg.sender, msg.sender, _amount, _l1Gas, _data);
}
- /**
- * @inheritdoc IL2ERC20Bridge
- */
+ /* *
+ * @inheritdoc IL2ERC20Bridge */
+
+
+
function withdrawTo(
address _l2Token,
address _to,
@@ -1109,22 +1394,35 @@ 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.
+Nota che non è necessario specificare l'indirizzo del token di L1.
+Ci si aspetta che i token di L2 ci dicano l'indirizzo dell'equivalente di L1.
```solidity
- /**
- * @dev Performs the logic for withdrawals by burning the token and informing
- * the L1 token Gateway of the withdrawal.
- * @param _l2Token Address of L2 token where withdrawal is initiated.
- * @param _from Account to pull the withdrawal from on L2.
- * @param _to Account to give the withdrawal to on L1.
- * @param _amount Amount of the token to withdraw.
- * @param _l1Gas Unused, but included for potential forward compatibility considerations.
- * @param _data Optional data to forward to L1. This data is provided
- * solely as a convenience for external contracts. Aside from enforcing a maximum
- * length, these contracts provide no guarantees about its content.
- */
+ /* *
+ * @dev Esegue la logica per i prelievi bruciando il token e informando
+ * il Gateway del token L1 del prelievo.
+ * @param _l2Token Indirizzo del token L2 in cui è stato avviato il prelievo.
+ * @param _from Account da cui prelevare il prelievo su L2.
+ * @param _to Account a cui dare il prelievo su L1.
+ * @param _amount Importo del token da prelevare.
+ * @param _l1Gas Inutilizzato, ma incluso per potenziali considerazioni di compatibilità futura.
+ * @param _data Dati opzionali da inoltrare a L1. Questi dati sono forniti
+ * esclusivamente per comodità dei contratti esterni. A parte l'imposizione di una
+ * lunghezza massima, questi contratti non forniscono alcuna garanzia sul loro contenuto. */
+
+
+
+
+
+
+
+
+
+
+
+
function _initiateWithdrawal(
address _l2Token,
address _from,
@@ -1133,17 +1431,17 @@ Queste due funzioni avviano dei prelievi. Nota che non serve specificare l'indir
uint32 _l1Gas,
bytes calldata _data
) internal {
- // When a withdrawal is initiated, we burn the withdrawer's funds to prevent subsequent L2
- // usage
+ // Quando viene avviato un prelievo, bruciamo i fondi di chi effettua il prelievo per prevenire un successivo
+ // utilizzo su L2
// slither-disable-next-line reentrancy-events
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).
+Nota che _non_ facciamo affidamento sul parametro `_from` ma su `msg.sender` che è molto più difficile da falsificare (impossibile, per quanto ne so).
```solidity
- // Construct calldata for l1TokenBridge.finalizeERC20Withdrawal(_to, _amount)
+ // Costruisce i calldata per l1TokenBridge.finalizeERC20Withdrawal(_to, _amount)
// slither-disable-next-line reentrancy-events
address l1Token = IL2StandardERC20(_l2Token).l1Token();
bytes memory message;
@@ -1173,7 +1471,7 @@ Su L1 è necessario distinguere tra ETH ed ERC-20.
);
}
- // Send message up to L1 bridge
+ // Invia il messaggio al ponte L1
// slither-disable-next-line reentrancy-events
sendCrossDomainMessage(l1TokenBridge, _l1Gas, message);
@@ -1181,13 +1479,18 @@ Su L1 è necessario distinguere tra ETH ed ERC-20.
emit WithdrawalInitiated(l1Token, _l2Token, msg.sender, _to, _amount, _data);
}
- /************************************
- * Cross-chain Function: Depositing *
- ************************************/
+ /* ***********************************
+ * Funzione Cross-chain: Deposito *
+ *********************************** */
+
+
+
+
+ /* *
+ * @inheritdoc IL2ERC20Bridge */
+
+
- /**
- * @inheritdoc IL2ERC20Bridge
- */
function finalizeDeposit(
address _l1Token,
address _l2Token,
@@ -1203,11 +1506,12 @@ 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.
+Si assicura che la fonte del messaggio sia legittima.
+Questo è importante perché questa funzione chiama `_mint` e potrebbe essere utilizzata per fornire token che non sono coperti dai token che il ponte possiede su L1.
```solidity
- // Check the target token is compliant and
- // verify the deposited token on L1 matches the L2 deposited token representation here
+ // Controlla che il token di destinazione sia conforme e
+ // verifica che il token depositato su L1 corrisponda alla rappresentazione del token depositato su L2 qui
if (
// slither-disable-next-line reentrancy-events
ERC165Checker.supportsInterface(_l2Token, 0x1d1d8b63) &&
@@ -1217,49 +1521,50 @@ 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 di L1 del contratto ERC-20 di L2 corrisponde alla fonte di L1 dei token
```solidity
) {
- // When a deposit is finalized, we credit the account on L2 with the same amount of
- // tokens.
+ // Quando un deposito viene finalizzato, accreditiamo sull'account su L2 la stessa quantità di
+ // token.
// slither-disable-next-line reentrancy-events
IL2StandardERC20(_l2Token).mint(_to, _amount);
// slither-disable-next-line reentrancy-events
emit DepositFinalized(_l1Token, _l2Token, _from, _to, _amount, _data);
```
-Se il controllo di integrità riesce, finalizza il deposito:
+Se i controlli di integrità vengono superati, finalizza il deposito:
1. Conia i token
-2. Genera l'evento appropriato
+2. Emette l'evento appropriato
```solidity
} else {
- // Either the L2 token which is being deposited-into disagrees about the correct address
- // of its L1 token, or does not support the correct interface.
- // This should only happen if there is a malicious L2 token, or if a user somehow
- // specified the wrong L2 token address to deposit into.
- // In either case, we stop the process here and construct a withdrawal
- // message so that users can get their funds out in some cases.
- // There is no way to prevent malicious token contracts altogether, but this does limit
- // user error and mitigate some forms of malicious contract behavior.
+ // O il token L2 in cui si sta depositando non concorda sull'indirizzo corretto
+ // del suo token L1, oppure non supporta l'interfaccia corretta.
+ // Questo dovrebbe accadere solo se c'è un token L2 malevolo, o se un utente in qualche modo
+ // ha specificato l'indirizzo del token L2 sbagliato in cui depositare.
+ // In entrambi i casi, interrompiamo il processo qui e costruiamo un
+ // messaggio di prelievo in modo che gli utenti possano recuperare i propri fondi in alcuni casi.
+ // Non c'è modo di prevenire del tutto i contratti di token malevoli, ma questo limita
+ // l'errore dell'utente e mitiga alcune forme di comportamento malevolo del contratto.
```
-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 utilizzando l'indirizzo del token di L2 sbagliato, vogliamo annullare il deposito e restituire i token su L1.
+L'unico modo in cui possiamo farlo da L2 è inviare un messaggio che dovrà attendere il periodo di contestazione dei guasti, ma questo è molto meglio per l'utente rispetto alla perdita permanente dei token.
```solidity
bytes memory message = abi.encodeWithSelector(
IL1ERC20Bridge.finalizeERC20Withdrawal.selector,
_l1Token,
_l2Token,
- _to, // switched the _to and _from here to bounce back the deposit to the sender
+ _to, // scambiati _to e _from qui per rimbalzare il deposito al mittente
_from,
_amount,
_data
);
- // Send message up to L1 bridge
+ // Invia il messaggio al ponte L1
// slither-disable-next-line reentrancy-events
sendCrossDomainMessage(l1TokenBridge, 0, message);
// slither-disable-next-line reentrancy-events
@@ -1269,10 +1574,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 utilizzare [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 in genere funzionano avendo asset su L1, che forniscono immediatamente per una piccola commissione (spesso inferiore al costo del gas per un prelievo dal ponte standard).
+Quando il ponte (o le persone che lo gestiscono) prevede di essere a corto di asset su L1, trasferisce asset sufficienti da L2. Poiché si tratta di prelievi molto grandi, il costo del prelievo viene 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/).
\ No newline at end of file
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 f28ca094cf4..190029e9fbc 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
@@ -1,311 +1,308 @@
---
-title: "Decompilare un contratto"
-description: Come comprendere un contratto quando non hai il codice sorgente
+title: "Reverse engineering di un contratto"
+description: Come comprendere un contratto quando non si dispone del codice sorgente
author: Ori Pomerantz
lang: it
-tags:
- - "evm"
- - "opcode"
+tags: ["evm", "opcodes"]
skill: advanced
-breadcrumb: "Reverse engineering"
+breadcrumb: Reverse engineering
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 accade è coerente, verificabile e pubblicamente disponibile. Idealmente, [i contratti dovrebbero avere il loro 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 fare il reverse engineering dei contratti esaminando 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 compilatori inversi, ma non sempre producono [risultati utilizzabili](https://etherscan.io/bytecode-decompiler?a=0x2510c039cc3b061d79e564b38836da87e31b342f). In questo articolo imparerai come fare manualmente il reverse engineering e comprendere un contratto a partire [dagli opcode](https://github.com/wolflo/evm-opcodes), oltre a 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 della EVM ed avere almeno una certa familiarità con l'assembler della 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, cliccando sulla scheda **Contract** e poi su **Switch to Opcodes View**. Otterrai una visualizzazione con 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 (jump), tuttavia, devi sapere dove si trova ciascun opcode nel codice. Per farlo, un modo è aprire un Foglio Google e incollare gli opcode nella colonna C. [Puoi saltare i passaggi seguenti creando una copia di questo foglio di calcolo già preparato](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.
+Il passaggio successivo è ottenere le posizioni corrette del codice in modo 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.
```
=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.
+Innanzitutto questa funzione aggiunge un byte per l'opcode stesso, e poi cerca `PUSH`. Gli opcode push sono speciali perché devono avere byte aggiuntivi per il valore che viene inserito (pushed). 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:
+In `A1` inserisci il primo offset, zero. Quindi, in `A2`, inserisci questa funzione e copiala e incollala di nuovo per il resto della colonna A:
```
=dec2hex(hex2dec(A1)+B1)
```
-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.
+Abbiamo bisogno che questa funzione ci dia il valore esadecimale perché i valori che vengono inseriti prima dei salti (`JUMP` e `JUMPI`) ci vengono forniti in esadecimale.
-## Il Punto d'accesso (0x00) {#the-entry-point-0x00}
+## Il Punto di Ingresso (0x00) {#the-entry-point-0x00}
-I contratti sono sempre eseguiti dal primo byte. Questa è la parte iniziale del codice:
+I contratti vengono 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 |
+| 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 |
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.
+1. Scrive 0x80 come 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 di chiamata per un contratto di Ethereum seguono [l'ABI (interfaccia binaria dell'applicazione)](https://docs.soliditylang.org/en/v0.8.10/abi-spec.html), che richiede come minimo quattro byte per il selettore di funzione. Se la dimensione dei dati di 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 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 |
-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) generano un'eccezione se si salta a un opcode che non è `JUMPDEST`. Poi guarda la CALLDATASIZE e, se è "vera" (cioè non zero), salta a 0x7C. Ci arriveremo più avanti.
-| 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 |
+| Offset | Opcode | Stack (dopo l'opcode) |
+| -----: | ---------- | -------------------------------------------------------------------------- |
+| 64 | CALLVALUE | [Wei](/glossary/#wei) forniti 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 di chiamata, leggiamo il valore di Storage[6]. Non sappiamo ancora quale sia questo valore, ma possiamo cercare le transazioni che il contratto ha ricevuto senza dati di chiamata. Le transazioni che trasferiscono semplicemente ETH senza alcun dato di chiamata (e quindi senza alcun metodo) hanno in Etherscan il metodo `Transfer`. Infatti, [la primissima transazione ricevuta dal contratto](https://etherscan.io/tx/0xeec75287a583c36bcc7ca87685ab41603494516a0f5986d18de96c8e630762e7) è 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 clicchiamo su **Click to see More**, vediamo che i dati di chiamata, chiamati dati di input, sono effettivamente vuoti (`0x`). Si noti anche che il valore è di 1.559 ETH, il 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.
+Successivamente, clicca sulla scheda **State** ed espandi il contratto di cui stiamo facendo il reverse engineering (0x2510...). Puoi vedere che `Storage[6]` è effettivamente cambiato durante la transazione e, se cambi Hex in **Number**, vedi che è diventato 1.559.000.000.000.000.000, il valore trasferito in wei (ho aggiunto le virgole per chiarezza), corrispondente al successivo valore del contratto.
![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 guardiamo i cambiamenti di stato causati 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'. 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 perché non c'è bisogno di usare l'archiviazione, che è molto costosa, quando puoi ottenere il saldo del tuo account usando `ADDRESS BALANCE`. Il primo opcode inserisce l'indirizzo stesso del contratto. Il secondo legge l'indirizzo in cima allo stack e lo sostituisce con il saldo di quell'indirizzo.
-| Offset | Opcode | Stack |
-| ------:| ------------ | --------------------------------------------- |
+| 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 | |
+| 74 | JUMP |
-Continueremo a monitorare questo codice alla destinazione del salto.
+Continueremo a tracciare questo codice alla destinazione del salto.
-| Offset | Opcode | Stack |
-| ------:| ---------- | ------------------------------------------------------------- |
+| 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 |
-Il `NOT` opera su singoli bit, quindi annulla il valore di ogni bit nel valore della chiamata.
+Il `NOT` è bit a bit, quindi inverte il valore di ogni bit nel valore della chiamata.
-| Offset | Opcode | Stack |
-| ------:| ------------ | ------------------------------------------------------------------------------- |
+| 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 | |
+| 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*` è minore di 2^256-CALLVALUE-1 o uguale ad esso. Questa sembra una logica per prevenire l'overflow. E in effetti, vediamo che dopo alcune operazioni senza senso (la scrittura in 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).
+Si noti che un tale overflow è estremamente improbabile, perché richiederebbe che il valore della chiamata più `Value*` fosse paragonabile a 2^256 wei, circa 10^59 ETH. [L'offerta totale di ETH, al momento della stesura, è inferiore a duecento milioni](https://etherscan.io/stat/supply).
-| Offset | Opcode | Stack |
-| ------:| -------- | ------------------------------------------- |
+| 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 | |
+| 1E3 | JUMP |
-Se siamo arrivati qui, ottieni `Value* + CALLVALUE` e salta all'offset 0x75.
+Se siamo arrivati fin qui, ottieni `Value* + CALLVALUE` e salta all'offset 0x75.
-| Offset | Opcode | Stack |
-| ------:| -------- | --------------------------------- |
+| 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 |
+| 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 (il che richiede che i dati di chiamata siano vuoti) aggiungiamo a `Value*` il valore della chiamata. Questo è coerente con ciò che diciamo facciano le transazioni `Transfer`.
| Offset | Opcode |
-| ------:| ------ |
+| -----: | ------ |
| 79 | POP |
| 7A | POP |
| 7B | STOP |
-Infine, cancelliamo lo stack (che non è necessario) e segnaliamo che la transazione è andata a buon fine.
+Infine, svuota lo stack (il che non è necessario) e segnala la fine con successo della transazione.
-Per riassumere tutto, ecco un diagramma di flusso per il codice iniziale.
+Per riassumere il tutto, ecco un diagramma di flusso per il codice iniziale.
-
+
## 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.
+Di proposito non ho inserito nell'intestazione cosa fa questo gestore. Il punto non è insegnarti come funziona questo specifico contratto, ma come fare ingegneria inversa sui 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 la firma del metodo non è nota (dagli offset 0x42 e 0x5D)
+- Se ci sono dati di chiamata di 1, 2 o 3 byte (dall'offset 0x63)
+- Se la firma del metodo è sconosciuta (dagli offset 0x42 e 0x5D)
| Offset | Opcode | Stack |
-| ------:| ------------ | -------------------- |
-| 7C | JUMPDEST | |
+| -----: | ------------ | -------------------- |
+| 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, una che non sono riuscito a trovare in nessuna transazione, quindi è più difficile sapere cosa significhi. Il codice sottostante lo renderà più chiaro.
| Offset | 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 |
-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 è minimamente efficiente in termini di gas quanto potrebbe esserlo.
| 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 |
-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 modifichiamo, quindi possiamo presumere 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 |
-Copia tutti i dati della chiamata nella memoria, a partire da 0x80.
+Copia tutti i dati di chiamata in 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 | |
+| 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ò agire come un [proxy](https://blog.openzeppelin.com/proxy-patterns/), chiamando l'indirizzo in Storage[3] per fare il vero lavoro. `DELEGATE_CALL` chiama un contratto separato, ma rimane nello stesso spazio di archiviazione. Ciò significa che il contratto delegato, quello per cui fungiamo da 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 a partire da 0x80, che è dove abbiamo inserito i dati di chiamata originali
+- _Dati di ritorno_: Nessuno (0x00 - 0x00) Otterremo i dati di ritorno con altri mezzi (vedi sotto)
-| 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 |
+| Offset | 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 di ritorno nel buffer di memoria a partire 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 | |
+| Offset | 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 di ritorno nel buffer 0x80 - 0x80+RETURNDATASIZE e, se la chiamata ha esito positivo, eseguiamo un `RETURN` esattamente con quel buffer.
-### DELEGATECALL fallita {#delegatecall-failed}
+### DELEGATECALL Fallita {#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 | |
+| Offset | 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 un `REVERT` con lo stesso buffer che abbiamo usato per il `RETURN` in precedenza: 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.
+Se la dimensione dei dati di chiamata è di quattro byte o più, questa 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))) |
-
-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
-
-| 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))) |
-
-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/):
-
-| Metodo | Firma del metodo | Offset a cui saltare |
-| -------------------------------------------------------------------------------------- | ---------------- | -------------------- |
-| [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 |
-| ??? | 0x81e580d3 | 0x0138 |
-| [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 |
-| ??? | 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.
+| Offset | Opcode | Stack |
+| -----: | ------------ | ------------------------------------------------------------------ |
+| D | PUSH1 0x00 | 0x00 |
+| F | CALLDATALOAD | (((Prima parola (256 bit) dei dati di chiamata))) |
+| 10 | PUSH1 0xe0 | 0xE0 (((Prima parola (256 bit) dei dati di chiamata))) |
+| 12 | SHR | (((primi 32 bit (4 byte) dei dati di chiamata))) |
+
+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 degli opcode aggiornata](https://github.com/wolflo/evm-opcodes) ci mostra che si tratta di uno scorrimento a destra (shift right)
+
+| Offset | Opcode | Stack |
+| -----: | ---------------- | ---------------------------------------------------------------------------------------------------------------- |
+| 13 | DUP1 | (((primi 32 bit (4 byte) dei dati di chiamata))) (((primi 32 bit (4 byte) dei dati di chiamata))) |
+| 14 | PUSH4 0x3cd8045e | 0x3CD8045E (((primi 32 bit (4 byte) dei dati di chiamata))) (((primi 32 bit (4 byte) dei dati di chiamata))) |
+| 19 | GT | 0x3CD8045E>primi-32-bit-dei-dati-di-chiamata (((primi 32 bit (4 byte) dei dati di chiamata))) |
+| 1A | PUSH2 0x0043 | 0x43 0x3CD8045E>primi-32-bit-dei-dati-di-chiamata (((primi 32 bit (4 byte) dei dati di chiamata))) |
+| 1D | JUMPI | (((primi 32 bit (4 byte) dei dati di chiamata))) |
+
+Dividere i test di corrispondenza della firma del metodo in due in questo modo fa risparmiare in media metà dei test. Il codice che segue immediatamente questo e il codice in `0x43` seguono lo stesso schema: `DUP1` dei primi 32 bit dei dati di chiamata, `PUSH4 (((firma del metodo>`, esecuzione di `EQ` per verificare l'uguaglianza, e poi `JUMPI` se la firma del metodo corrisponde. Ecco le firme dei metodi, i loro indirizzi e, se nota, [la definizione del metodo corrispondente](https://www.4byte.directory/):
+
+| Metodo | Firma del metodo | Offset in cui saltare |
+| -------------------------------------------------------------------------------------- | ---------------- | --------------------- |
+| [splitter()](https://www.4byte.directory/signatures/?bytes4_signature=0x3cd8045e) | 0x3cd8045e | 0x0103 |
+| ??? | 0x81e580d3 | 0x0138 |
+| [currentWindow()](https://www.4byte.directory/signatures/?bytes4_signature=0xba0bafb4) | 0xba0bafb4 | 0x0158 |
+| ??? | 0x1f135823 | 0x00C4 |
+| [merkleRoot()](https://www.4byte.directory/signatures/?bytes4_signature=0x2eb4a7ab) | 0x2eb4a7ab | 0x00ED |
+
+Se non viene trovata alcuna corrispondenza, il codice salta al [gestore del proxy a 0x7C](#the-handler-at-0x7c), nella speranza che il contratto di cui siamo un proxy abbia una corrispondenza.
## splitter() {#splitter}
| Offset | Opcode | Stack |
-| ------:| ------------ | ----------------------------- |
-| 103 | JUMPDEST | |
+| -----: | ------------ | ----------------------------- |
+| 103 | JUMPDEST |
| 104 | CALLVALUE | CALLVALUE |
| 105 | DUP1 | CALLVALUE CALLVALUE |
| 106 | ISZERO | CALLVALUE==0 CALLVALUE |
@@ -313,40 +310,40 @@ Se non è trovata alcuna corrispondenza, il codice salta al [gestore del proxy a
| 10A | JUMPI | CALLVALUE |
| 10B | PUSH1 0x00 | 0x00 CALLVALUE |
| 10D | DUP1 | 0x00 0x00 CALLVALUE |
-| 10E | REVERT | |
+| 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.
+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 degli ETH deve trattarsi di un errore e vogliamo eseguire un `REVERT` per evitare di avere quegli ETH dove non possono essere recuperati.
| Offset | Opcode | Stack |
-| ------:| ------------------------------------------------- | --------------------------------------------------------------------------- |
-| 10F | JUMPDEST | |
-| 110 | POP | |
+| -----: | ------------------------------------------------- | --------------------------------------------------------------------------- |
+| 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 |
+| 113 | SLOAD | (((Storage[3] alias il contratto per cui siamo un proxy))) |
+| 114 | PUSH1 0x40 | 0x40 (((Storage[3] alias il contratto per cui siamo un proxy))) |
+| 116 | MLOAD | 0x80 (((Storage[3] alias il contratto per cui siamo un proxy))) |
+| 117 | PUSH20 0xffffffffffffffffffffffffffffffffffffffff | 0xFF...FF 0x80 (((Storage[3] alias il contratto per cui siamo un proxy))) |
+| 12C | SWAP1 | 0x80 0xFF...FF (((Storage[3] alias il contratto per cui siamo un proxy))) |
+| 12D | SWAP2 | (((Storage[3] alias 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
+E 0x80 ora contiene l'indirizzo del proxy
| Offset | Opcode | Stack |
-| ------:| ------------ | --------- |
+| -----: | ------------ | --------- |
| 131 | PUSH1 0x20 | 0x20 0x80 |
| 133 | ADD | 0xA0 |
| 134 | PUSH2 0x00e4 | 0xE4 0xA0 |
| 137 | JUMP | 0xA0 |
-### Il Codice E4 {#the-e4-code}
+### 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.
+Questa è la prima volta che vediamo queste righe, ma sono condivise con altri metodi (vedi sotto). 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 |
@@ -354,20 +351,20 @@ Questa è la prima volta che vediamo queste righe, ma sono condivise con altri m
| E9 | SWAP2 | X 0x80 0x80 |
| EA | SUB | X-0x80 0x80 |
| EB | SWAP1 | 0x80 X-0x80 |
-| EC | RETURN | |
+| 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 in modo che il contratto esegua un `RETURN` con un buffer che è 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).
+Nel caso di `splitter()`, questo restituisce l'indirizzo per cui siamo un proxy. `RETURN` restituisce il buffer in 0x80-0x9F, che è 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()` (a parte la destinazione `JUMPI`), quindi sappiamo che anche `currentWindow()` non è `payable`.
| Offset | Opcode | Stack |
-| ------:| ------------ | -------------------- |
-| 164 | JUMPDEST | |
-| 165 | POP | |
+| -----: | ------------ | -------------------- |
+| 164 | JUMPDEST |
+| 165 | POP |
| 166 | PUSH2 0x00da | 0xDA |
| 169 | PUSH1 0x01 | 0x01 0xDA |
| 16B | SLOAD | Storage[1] 0xDA |
@@ -376,10 +373,10 @@ Il codice negli offset 0x158-0x163 è identico a quello che abbiamo visto in 0x1
### 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].
+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 |
@@ -387,39 +384,39 @@ Questo codice è condiviso anche con altri metodi. Quindi chiameremo il valore n
| DF | DUP2 | 0x80 Y 0x80 0xDA |
| E0 | MSTORE | 0x80 0xDA |
-Scrivi Y a 0x80-0x9F.
+Scrive Y in 0x80-0x9F.
| Offset | 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à stato 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()` (a parte la destinazione `JUMPI`), quindi sappiamo che anche `merkleRoot()` non è `payable`.
| Offset | Opcode | Stack |
-| ------:| ------------ | -------------------- |
-| F9 | JUMPDEST | |
-| FA | POP | |
+| -----: | ------------ | -------------------- |
+| 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`.
+Il codice negli offset 0x138-0x143 è identico a quello che abbiamo visto in 0x103-0x10E in `splitter()` (a parte la destinazione di `JUMPI`), quindi sappiamo che anche questa funzione non è `payable`.
| Offset | Opcode | Stack |
-| ------:| ------------ | ------------------------------------------------------------ |
-| 144 | JUMPDEST | |
-| 145 | POP | |
+| -----: | ------------ | ------------------------------------------------------------ |
+| 144 | JUMPDEST |
+| 145 | POP |
| 146 | PUSH2 0x00da | 0xDA |
| 149 | PUSH2 0x0153 | 0x0153 0xDA |
| 14C | CALLDATASIZE | CALLDATASIZE 0x0153 0xDA |
@@ -437,28 +434,28 @@ Il codice negli offset 0x138-0x143 è identico a quello che abbiamo visto in 0x1
| 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.
+Sembra che questa funzione accetti almeno 32 byte (una word) di dati di chiamata.
| Offset | Opcode | Stack |
-| ------:| ------ | -------------------------------------------- |
+| -----: | ------ | -------------------------------------------- |
| 19D | DUP1 | 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
| 19E | DUP2 | 0x00 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA |
-| 19F | REVERT | |
+| 19F | REVERT |
-Se non ottiene i dati della chiamata, la transazione è annullata senza alcun dato restituito.
+Se non riceve i dati di chiamata, la transazione viene annullata senza alcun dato di ritorno.
-Vediamo cosa succede se la funzione _ottiene_ i dati della chiamata che necessita.
+Vediamo cosa succede se la funzione riceve _effettivamente_ i dati di chiamata di cui ha bisogno.
| 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
+`calldataload(4)` è la prima word dei dati di 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 |
@@ -476,28 +473,28 @@ Vediamo cosa succede se la funzione _ottiene_ i dati della chiamata che necessit
| 176 | PUSH2 0x017e | 0x017EC 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 esaminare il resto opcode per opcode, possiamo [provare il decompilatore](https://etherscan.io/bytecode-decompiler?a=0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761), che produce risultati utilizzabili per tre funzioni di questo contratto. Il reverse engineering delle altre è lasciato come esercizio per il lettore.
### scaleAmountByPercentage {#scaleamountbypercentage}
-Questo è ciò che il decompilatore ci restituisce per questa funzione:
+Questo è ciò che il decompilatore ci fornisce per questa funzione:
```python
def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:
@@ -593,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, sufficienti per i due parametri. In caso contrario, 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 controllare che `_param1` non sia zero e che `_param1 * _param2` non sia negativo. Probabilmente serve a prevenire casi di wrap around (overflow).
-Infine, la funzione restituisce un valore in scala.
+Infine, la funzione restituisce un valore scalato.
### 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:
@@ -615,7 +612,7 @@ def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _pa
Qui vediamo due cose importanti:
- `_param2`, sebbene sia dichiarato come `uint256`, è in realtà un indirizzo
-- `_param1` è la finestra rivendicata, che dev'essere `currentWindow` o precedente.
+- `_param1` è la finestra che viene riscattata, che deve essere `currentWindow` o precedente.
```python
...
@@ -623,7 +620,7 @@ Qui vediamo due cose importanti:
revert with 0, 'Account already claimed the given window'
```
-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 riscattato la ricompensa per quella finestra.
```python
...
@@ -643,7 +640,7 @@ Quindi ora sappiamo che Storage[5] è un array di finestre e indirizzi, e se l'i
revert with 0, 'Invalid proof'
```
-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.
+Sappiamo che `unknown2eb4a7ab` è in realtà la funzione `merkleRoot()`, quindi questo codice sembra verificare una [prova di Merkle](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5). Ciò significa che `_param4` è una prova di Merkle.
```python
call addr(_param2) with:
@@ -651,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.
+Questo è il modo in cui un contratto trasferisce i propri ETH a un altro indirizzo (contratto o account controllato esternamente). Lo chiama con un valore che è l'importo da trasferire. Quindi sembra che si tratti di un airdrop di ETH.
```python
if not return_data.size:
@@ -661,22 +658,22 @@ 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 [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 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 il contratto tenti di inviare ETH a `_param2`. Se ci riesce, ottimo. Altrimenti, tenta di inviare [WETH](https://weth.tkn.eth.limo/). Se `_param2` è un account controllato 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.
```python
...
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 di log. [Guarda le voci di log generate](https://etherscan.io/address/0x2510c039cc3b061d79e564b38836da87e31b342f#events) e filtra per l'argomento che inizia con `0xdbd5...`. Se [clicchiamo su una delle transazioni che ha generato tale voce](https://etherscan.io/tx/0xe7d3b7e00f645af17dfbbd010478ef4af235896c65b6548def1fe95b3b7d2274) vediamo che in effetti sembra un riscatto: l'account ha inviato un messaggio al contratto di cui stiamo facendo il reverse engineering e in cambio ha ottenuto 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 a [`claim`](#claim) qui sopra. Controlla anch'essa una prova di Merkle, tenta di trasferire ETH al primo e produce lo stesso tipo di voce di log.
```python
def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
@@ -709,7 +706,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 prelevare, non c'è. Invece, c'è un ciclo su tutte le finestre che potrebbero essere riscattate.
```python
idx = 0
@@ -738,8 +735,10 @@ La differenza principale è che il primo parametro, la finestra per prelevare, n
continue
```
-Quindi, sembra una variante di `claim` che rivendica tutte le finestre.
+Quindi sembra una variante di `claim` che riscatta 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, utilizzando gli opcode o (quando funziona) il decompilatore. Come è evidente dalla lunghezza di questo articolo, il reverse engineering di un contratto non è banale, ma in un sistema in cui la sicurezza è essenziale è una competenza importante per poter verificare che i contratti funzionino come promesso.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
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 f09d935c159..b51ce641e5f 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,136 +1,132 @@
---
-title: Come trasformare un Raspberry Pi 4 in un nodo eseguendo il flashing della scheda MicroSD
-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
+title: Esegui un nodo di Ethereum su Raspberry Pi 4
+description: Flasha il tuo Raspberry Pi 4, collega un cavo ethernet, connetti il disco SSD e accendi il dispositivo per trasformare il Raspberry Pi 4 in un nodo completo di Ethereum + validatore
author: "EthereumOnArm"
-tags:
- - "client"
- - "livello di esecuzione"
- - "livello di consenso"
- - "nodi"
+tags: ["client", "livello di esecuzione", "livello di consenso", "nodi"]
lang: it
skill: intermediate
-breadcrumb: "Nodo Raspberry Pi"
+breadcrumb: Nodo Rasp Pi
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.**
-Per usare Ethereum on Arm per trasformare un Raspberry Pi in un nodo di Ethereum, si consiglia il seguente hardware:
+Per utilizzare Ethereum on Arm per trasformare un Raspberry Pi in un nodo di 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)
+- Disco SSD USB 3.0 da minimo 2 TB o un SSD con un case da USB a SATA.
- Alimentatore
- Cavo Ethernet
-- Port forwarding (vedi i client per maggiori informazioni)
-- Un case con dissipatore di calore e ventola
-- Tastiera USB, monitor e cavo HDMI (micro-HDMI) (opzionale)
+- Inoltro delle porte (vedi i client per ulteriori informazioni)
+- Un case con dissipatore e ventola
+- Tastiera USB, monitor e cavo HDMI (micro-HDMI) (Opzionale)
-## 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 piccole dimensioni. Sono ottime scelte per eseguire i nodi di Ethereum perché possono essere acquistate a basso costo, configurate in modo che tutte le loro risorse si concentrino solo sul nodo, rendendole efficienti, consumano basse quantità di energia e sono fisicamente piccole, in modo da potersi adattare in modo discreto in qualsiasi casa. È anche molto facile avviare i nodi perché la MicroSD del Raspberry Pi può essere semplicemente flashata con un'immagine precompilata, senza dover scaricare o compilare 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.
+La scheda di memoria del Raspberry Pi viene flashata con un'immagine precompilata. Questa immagine contiene tutto il necessario per eseguire un nodo di Ethereum. Con una scheda flashata, tutto ciò che l'utente deve fare è accendere il Raspberry Pi. Tutti i processi necessari per eseguire il nodo vengono avviati automaticamente. Questo funziona perché la scheda di memoria contiene un sistema operativo (OS) basato su Linux su cui vengono eseguiti automaticamente processi a livello di sistema che trasformano l'unità in un nodo di 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 porta gli utenti di Ethereum a riscontrare problemi di memoria e i client di consenso non supportano i binari a 32 bit. Per superare questo problema, il team di Ethereum on Arm è migrato 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 la formattazione del disco SSD all'installazione e all'esecuzione del software di Ethereum, nonché 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 client di consenso precompilati come servizi. Un nodo di Ethereum richiede che entrambi i client siano sincronizzati e in esecuzione. Ti è richiesto solo di scaricare e flashare l'immagine e poi 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 ripiegherà sui suoi 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 e connettersi ai peer.
-## Download immagine {#downloading-the-image}
+## Scaricare l'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 di Ethereum per Raspberry Pi 4 è un'immagine "plug and play" che installa e configura automaticamente sia il client di esecuzione che il client di consenso, configurandoli per comunicare tra loro e connettersi alla rete di Ethereum. Tutto ciò che l'utente deve fare è avviare i loro 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'hash dovrebbe dare come output: 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/) di Ethereum-su-Arm.
+Nota che le immagini per le schede Rock 5B e Odroid M1 sono disponibili alla [pagina dei download](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) di Ethereum-on-Arm.
-## Flashing della MicroSD {#flashing-the-microsd}
+## Flashare la 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 verrà utilizzata per il Raspberry Pi dovrebbe prima essere inserita in un computer desktop o laptop in modo che possa essere flashata. Quindi, i seguenti comandi da terminale flasheranno l'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 inserirvi l'immagine. Per continuare, naviga nella directory contenente l'immagine zippata:
```shell
-# unzip and flash image
+# decomprimi e flasha l'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.
+La scheda è ora flashata, quindi può essere inserita 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.
+Con la scheda SD inserita nel Raspberry Pi, collega il cavo ethernet e l'SSD, quindi accendi l'alimentazione. Il sistema operativo si avvierà e inizierà automaticamente a eseguire le attività preconfigurate che trasformano il Raspberry Pi in un nodo di Ethereum, inclusa l'installazione e la compilazione del software del client. Questo richiederà probabilmente 10-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 che tutto è installato e configurato, accedi al dispositivo tramite una connessione ssh o utilizzando direttamente il terminale se un monitor e una tastiera sono collegati alla scheda. Usa l'account `ethereum` per accedere, poiché questo ha i permessi necessari per avviare il nodo.
```shell
User: 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 utilizzando 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).
+Nota che il client di consenso si sincronizzerà in pochi minuti perché utilizza la sincronizzazione dei checkpoint. Il client di esecuzione impiegherà più tempo - potenzialmente diverse ore, e non si avvierà finché il client di consenso non avrà già terminato la sincronizzazione (questo perché il client di esecuzione ha bisogno di un bersaglio a cui sincronizzarsi, che il client di consenso sincronizzato fornisce).
-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 di Ethereum! È molto comune interagire con la rete di 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. Vedi di più 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 segnalare 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 loro nodo navigando su `ipaddress:3000`, passando `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.
+Un validatore può anche essere aggiunto opzionalmente al client di consenso. Il software del validatore consente al tuo nodo di partecipare attivamente al consenso e fornisce alla rete sicurezza criptoeconomica. Vieni ricompensato per questo lavoro in ETH. Per eseguire un validatore, devi prima avere 32 ETH, che devono essere depositati nel contratto di deposito. Il deposito può essere effettuato seguendo la guida passo-passo sul [Launchpad](https://launchpad.ethereum.org/). Fallo su un computer desktop/laptop, ma non generare le chiavi — questo può essere fatto direttamente sul Raspberry Pi.
Apri un terminale sul Raspberry Pi ed esegui il seguente comando per generare le chiavi di deposito:
@@ -140,32 +136,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.
+(Oppure scarica la [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) per eseguirla su una macchina isolata dalla rete (airgapped), 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.
+Tieni al sicuro la frase mnemonica! Il comando precedente 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 essere copiati dal Raspberry Pi al computer desktop/laptop. Questo può essere fatto utilizzando una connessione ssh o qualsiasi altro metodo di copia/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. Questo richiede l'importazione delle chiavi del validatore, l'impostazione dell'indirizzo per raccogliere le ricompense e quindi l'avvio del processo del validatore preconfigurato. L'esempio seguente è per Lighthouse—le istruzioni per altri client di consenso sono disponibili nei [documenti 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 completo di Ethereum e un validatore in esecuzione su un Raspberry Pi!
## Maggiori 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/).
+Questa pagina ha fornito una panoramica su come configurare un nodo Geth-Lighthouse e un validatore utilizzando Raspberry Pi. Istruzioni più dettagliate sono disponibili sul [sito web di Ethereum-on-Arm](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/).
-## Ogni feedback è benvenuto {#feedback-appreciated}
+## Feedback apprezzato {#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 in questo tutorial, prova a eseguire sulle reti di test, dai un'occhiata al GitHub di Ethereum on Arm, fornisci feedback, apri issue e pull request e aiuta a far progredire la tecnologia e la documentazione!
## Riferimenti {#references}
@@ -183,4 +182,4 @@ Sappiamo che Raspberry Pi ha un'enorme base di utenti che potrebbe avere un impa
12. https://raiden.network
13. https://ipfs.io
14. https://status.im
-15. https://vipnode.org
+15. https://vipnode.org
\ No newline at end of file
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..545e847bda3
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/scam-token-tricks/index.md
@@ -0,0 +1,466 @@
+---
+title: "Alcuni trucchi usati dai token truffa e come rilevarli"
+description: In questo tutorial analizziamo un token truffa per vedere alcuni dei trucchi usati dai truffatori, come li implementano e come possiamo rilevarli.
+author: Ori Pomerantz
+tags: ["truffa", "Solidity", "erc-20", "JavaScript", "TypeScript"]
+skill: intermediate
+breadcrumb: Trucchi dei token truffa
+published: 2023-09-15
+lang: it
+---
+
+In questo tutorial analizziamo [un token truffa](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82#code) per vedere alcuni dei trucchi usati dai truffatori e come li implementano. Alla fine del tutorial avrai una visione più completa dei contratti dei token ERC-20, delle loro capacità 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 usi più comuni di Ethereum è la creazione di un token negoziabile da parte di un gruppo, in un certo senso la propria valuta. Tuttavia, ovunque ci siano casi d'uso legittimi che portano valore, ci sono anche criminali che cercano di rubare quel valore per sé stessi.
+
+Puoi leggere di più su questo argomento [altrove su ethereum.org](/guides/how-to-id-scam-tokens/) dal punto di vista dell'utente. Questo tutorial si concentra sull'analisi di un token truffa per vedere come viene realizzato e come può essere rilevato.
+
+### 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 legittimo [token ARB](https://etherscan.io/token/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1).
+
+Il modo più semplice per sapere quale sia 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 reticenti, 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 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 rende più facile comprenderlo.
+
+Sebbene i distributori dei contratti possano scegliere se pubblicare o meno il codice sorgente, _non possono_ pubblicare il codice sorgente sbagliato. L'esploratore di blocchi compila il codice sorgente fornito in modo indipendente e, se non ottiene l'esatto stesso bytecode, rifiuta quel codice sorgente. [Puoi leggere di più al 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 vengono tipicamente scritti i token ERC-20 legittimi, [consulta questo tutorial](/developers/tutorials/erc20-annotated-code/).
+
+### Costanti per gli 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 abilitare l'uso di un nuovo contratto multifirma. Ci sono diversi modi per farlo.
+
+Il [contratto del token `HOP`](https://etherscan.io/address/0xc5102fe9359fd9a28f877a67e36b0f050d81a3cc#code) utilizza il pattern [`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 utilizzato per gli aggiornamenti.
+
+```solidity
+ /* *
+ * @dev Memorizza un nuovo indirizzo nello slot admin EIP1967. */
+
+
+
+ function _setAdmin(address newAdmin) private {
+ require(newAdmin != address(0), "ERC1967: new admin is the zero address");
+ StorageSlot.getAddressSlot(_ADMIN_SLOT).value = newAdmin;
+ }
+```
+
+Al contrario, il contratto `wARB` ha un `contract_owner` hardcoded.
+
+```solidity
+contract WrappedArbitrum is Context, IERC20 {
+ .
+ .
+ .
+ address deployer = 0xB50721BCf8d664c30412Cfbc6cf7a15145234ad1;
+ address public contract_owner = 0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33;
+ .
+ .
+ .
+}
+```
+
+[Questo proprietario del contratto](https://etherscan.io/address/0xb40dE7b1beE84Ff2dc22B70a049A07A13a411A33) non è un contratto che potrebbe essere controllato da account diversi in momenti diversi, ma un [account controllato esternamente ](/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 in effetti, se guardiamo su Etherscan vediamo che il truffatore ha utilizzato questo contratto solo per 12 ore (dalla [prima transazione](https://etherscan.io/tx/0xf49136198c3f925fcb401870a669d43cecb537bde36eb8b41df77f06d5f6fbc2) all'[ultima transazione](https://etherscan.io/tx/0xdfd6e717157354e64bbd5d6adf16761e5a5b3f914b1948d3545d39633244d47b)) durante il 19 maggio 2023.
+
+### La finta funzione `_transfer` {#the-fake-transfer-function}
+
+È 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: transfer from the zero address");
+ require(recipient != address(0), "ERC20: transfer to the zero address");
+
+ _beforeTokenTransfer(sender, recipient, amount);
+
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
+ _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 dal `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 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: transfer amount exceeds allowance"));
+ return true;
+ }
+```
+
+Quando guardiamo le funzioni che vengono 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: transfer from the zero address");
+ require(recipient != address(0), "ERC20: transfer to the zero address");
+
+ _beforeTokenTransfer(sender, recipient, amount);
+
+ _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
+ _balances[recipient] = _balances[recipient].add(amount);
+ if (sender == contract_owner){
+
+ sender = deployer;
+ }
+ emit Transfer(sender, recipient, amount);
+ }
+```
+
+Ci sono due potenziali campanelli d'allarme in questa funzione.
+
+- 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 il `contract_owner` invia token, questi sembrano provenire dal `deployer`.
+
+### La finta funzione di eventi `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, "Not allowed to interact");
+ _;
+}
+```
+
+Questa restrizione ha perfettamente senso, perché non vorremmo che account 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 account pool 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 una singola fonte a più destinazioni, come buste paga, airdrop, ecc. È più economico (in termini di gas) farlo in una singola transazione invece di emettere più transazioni, o persino 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 catena comunicando loro un trasferimento che non è realmente avvenuto.
+
+### La funzione `Approve` che brucia i token {#the-burning-approve-function}
+
+I contratti ERC-20 dovrebbero avere [una funzione `approve`](/developers/tutorials/erc20-annotated-code/#approve) per le indennità, e in effetti il nostro token truffa ha una tale funzione, ed è persino corretta. Tuttavia, poiché Solidity deriva dal C, fa distinzione tra maiuscole e minuscole. "Approve" e "approve" sono stringhe diverse.
+
+Inoltre, la funzionalità non è correlata ad `approve`.
+
+```solidity
+ function Approve(
+ address[] memory holders)
+```
+
+Questa funzione viene chiamata con un array di indirizzi per i detentori del token.
+
+```solidity
+ public approver() {
+```
+
+Il modificatore `approver()` si assicura che solo il `contract_owner` sia autorizzato a 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: burn amount exceeds balance");
+ _balances[0x0000000000000000000000000000000000000001] =
+ _balances[0x0000000000000000000000000000000000000001].add(amount);
+ }
+ }
+
+```
+
+Per ogni indirizzo del detentore, la funzione sposta l'intero saldo del detentore all'indirizzo `0x00...01`, di fatto bruciandolo (il vero `burn` nello standard modifica anche l'offerta totale e trasferisce i token a `0x00...00`). Ciò significa che il `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 così scadente.
+
+#### 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 è chiamata [`mint`](/developers/tutorials/erc20-annotated-code/#the-_mint-and-_burn-functions-_mint-and-_burn) (coniare).
+
+Se guardiamo nel costruttore di `wARB`, vediamo che la funzione di conio è stata rinominata in `mount` per qualche motivo, e viene chiamata cinque volte con un quinto dell'offerta iniziale, invece di una volta 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: mint to the zero address");
+```
+
+Guardando il `require`, vediamo che solo il proprietario del contratto è autorizzato a coniare. Questo è legittimo. Ma il messaggio di errore dovrebbe essere _only owner is allowed to mint_ (solo il proprietario è autorizzato a coniare) o qualcosa del genere. Invece, è l'irrilevante _ERC20: mint to the zero address_ (ERC20: conio all'indirizzo zero). Il test corretto per il conio all'indirizzo zero è `require(account != address(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 `account`, che presumibilmente è l'account che dovrebbe ricevere l'importo coniato. Ma il saldo che aumenta è in realtà quello del `contract_owner`.
+
+- Sebbene il saldo aumentato appartenga al `contract_owner`, l'evento emesso mostra un trasferimento all'`account`.
+
+### 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 fa nulla con essi. Perché averlo?
+
+```solidity
+ modifier auth() {
+ require(msg.sender == contract_owner, "Not allowed to interact");
+ _;
+ }
+
+ modifier approver() {
+ require(msg.sender == contract_owner, "Not allowed to interact");
+ _;
+ }
+```
+
+`auth` e `approver` hanno più senso, perché controllano che il contratto sia stato chiamato dal `contract_owner`. Ci aspetteremmo che certe azioni privilegiate, come il conio, siano limitate a quell'account. Tuttavia, qual è lo scopo di 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 su Etherscan. Tuttavia, questa è una soluzione centralizzata. In teoria, Etherscan potrebbe essere sovvertito o hackerato. È meglio essere in grado di capire in modo indipendente se un token è legittimo o meno.
+
+Ci sono alcuni trucchi che possiamo usare per identificare che un token ERC-20 è sospetto (che sia 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 un'indennità). [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 debbano essere dirette, piuttosto che mediate da un contratto.
+
+Ciò significa che gli eventi `Approval` che approvano la spesa da un [account controllato esternamente ](/developers/docs/accounts/#types-of-account) devono provenire da transazioni che hanno origine in quell'account e la cui destinazione è il contratto ERC-20. Qualsiasi altro tipo di approvazione da un account controllato esternamente è 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 a un nodo della rete principale di Ethereum.
+3. Esegui `pnpm install` per installare i pacchetti necessari.
+4. Esegui `pnpm susApproval` per cercare 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 all'interno dei quali cercheremo gli eventi. I fornitori di nodi in genere limitano la nostra capacità di leggere gli eventi perché la larghezza di banda può diventare costosa. Fortunatamente `wARB` non è stato in uso 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 agli account controllati esternamente. Se c'è del 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 assicurarci di sapere quale fosse 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, supponiamo 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 proprietario e se quel contratto ha chiamato direttamente il contratto ERC-20. Questo è molto più dispendioso in termini di risorse di quanto vorremmo fare.
+
+```typescript
+const txn = await getEventTxn(ev)
+```
+
+Se l'approvazione proviene da un account controllato esternamente , ottieni la transazione che l'ha causata.
+
+```typescript
+// L'approvazione è sospetta se proviene da un proprietario EOA che non è il `from` della transazione
+if (owner.toLowerCase() != txn.from.toLowerCase()) return ev
+```
+
+Non possiamo semplicemente controllare l'uguaglianza delle stringhe perché gli indirizzi sono esadecimali, quindi contengono lettere. A volte, ad esempio in `txn.from`, quelle lettere sono tutte minuscole. In altri casi, come `ev.args._owner`, l'indirizzo è in [maiuscolo e minuscolo misto per l'identificazione degli errori](https://eips.ethereum.org/EIPS/eip-55).
+
+Ma se la transazione non proviene dal proprietario, e quel proprietario è controllato esternamente, allora abbiamo una transazione sospetta.
+
+```typescript
+// È anche sospetta 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`](https://www.w3schools.com/js/js_async.asp) restituisce un oggetto `Promise`. Con la sintassi comune, `await x()`, aspettiamo che quella `Promise` venga 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`. Quindi usiamo [`Promise.all`](https://www.javascripttutorial.net/es6/javascript-promise-all/) per aspettare che tutte quelle promesse vengano risolte. Successivamente usiamo [`filter`](https://www.w3schools.com/jsref/jsref_filter.asp) su 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 account 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 certi casi, come nei componenti della 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/).
\ No newline at end of file
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..fbf00179f24
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/secret-state/index.md
@@ -0,0 +1,732 @@
+---
+title: Utilizzare la conoscenza-zero per uno stato segreto
+description: "I giochi on-chain sono limitati perché non possono mantenere alcuna informazione nascosta. Dopo aver letto questo tutorial, il lettore sarà in grado di combinare prove a conoscenza-zero e componenti server per creare giochi verificabili con un componente di stato segreto fuori catena. La tecnica per farlo sarà dimostrata creando un gioco di campo minato."
+author: Ori Pomerantz
+tags: ["server", "fuori catena", "centralizzato", "conoscenza-zero", "zokrates", "mud", "privacy"]
+skill: advanced
+breadcrumb: Stato segreto ZK
+lang: it
+published: 2025-03-15
+---
+
+_Non ci sono segreti sulla blockchain_. Tutto ciò che viene pubblicato sulla blockchain è aperto alla lettura di tutti. Questo è necessario, perché la blockchain si basa sul fatto che chiunque possa verificarla. Tuttavia, i giochi spesso si basano su uno stato segreto. Ad esempio, il gioco del [campo minato]() non ha assolutamente senso se si può semplicemente andare su un esploratore di blocchi e vedere la mappa.
+
+La soluzione più semplice è utilizzare un [componente server](/developers/tutorials/server-components/) per mantenere lo stato segreto. Tuttavia, il motivo per cui utilizziamo la blockchain è prevenire i raggiri da parte dello sviluppatore del gioco. 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 mantiene 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 la 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/) | Servire il codice del client | 4.2.1 |
+
+## Esempio del campo minato {#minesweeper}
+
+[Campo minato]() è un gioco che include una mappa segreta con un campo minato. Il giocatore sceglie di scavare in una posizione specifica. Se quella posizione ha una mina, il gioco finisce. Altrimenti, il giocatore ottiene il numero di mine negli otto quadrati 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 automaticamente quei dati con componenti fuori catena. Oltre alla sincronizzazione, MUD semplifica la fornitura del controllo degli accessi e consente ad altri utenti di [estendere](https://mud.dev/guides/extending-a-world) la nostra applicazione senza permessi.
+
+### Eseguire l'esempio del campo minato {#running-minesweeper-example}
+
+Per eseguire l'esempio del campo minato:
+
+1. Assicurati di [avere i prerequisiti installati](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`, devi 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, usa prima la freccia giù per scorrere fino alla scheda _contracts_ per vedere i contratti MUD in fase di distribuzione. Quando ricevi il messaggio _Waiting for file changes…_, i contratti sono distribuiti e gli 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.
+
+ 
+
+ Se c'è un problema con `mprocs`, puoi 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 verso [il client](http://localhost:3000), cliccare su **New Game** 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 chiavi e ha un singolo record. È utilizzata per mantenere 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. È utilizzata per mantenere una parte della configurazione, l'indirizzo del contratto verificatore (`verifier`). Avremmo potuto inserire queste informazioni nella tabella `Configuration`, ma vengono impostate da un componente diverso, il server, quindi è più semplice inserirle in una tabella separata.
+
+- `PlayerGame`: La chiave è l'indirizzo del giocatore. I dati sono:
+
+ - `gameId`: valore di 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 mantiene la mappatura inversa, da `gameId` all'indirizzo del giocatore.
+
+- `Map`: La chiave è una tupla di tre valori:
+
+ - `gameId`: valore di 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 attorno a quella posizione più uno. Non possiamo semplicemente usare il numero di bombe, perché per impostazione predefinita tutta l'archiviazione nell'EVM e tutti i valori delle righe in MUD sono zero. Dobbiamo distinguere tra "il giocatore non ha ancora scavato qui" e "il giocatore ha scavato qui e ha scoperto che ci sono zero bombe intorno".
+
+Inoltre, la comunicazione tra il client e il server avviene tramite il componente on-chain. Anche questo è implementato utilizzando le tabelle.
+
+- `PendingGame`: Richieste non servite per iniziare una nuova partita.
+- `PendingDig`: Richieste non servite per scavare in un luogo specifico in una partita specifica. Questa è una [tabella fuori catena](https://mud.dev/store/tables#types-of-tables), il che significa che non viene scritta nell'archiviazione dell'EVM, è leggibile solo fuori catena utilizzando gli eventi.
+
+### Flussi di esecuzione e dati {#execution-data-flows}
+
+Questi flussi coordinano l'esecuzione tra il client, il componente on-chain e il server.
+
+#### Inizializzazione {#initialization-flow}
+
+Quando esegui `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
+ - [Contratti](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 poi 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 al suo interno](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 [configurando 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 rilevanti esista nella memoria del server.
+
+4. Il server iscrive 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 che la parte a conoscenza-zero del server è stata inizializzata, il passaggio 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 verificatore in MUD.
+
+7. Infine, ci iscriviamo agli aggiornamenti in modo da 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'è nessuna partita in corso per questo giocatore, o ce n'è una ma con un gameId pari a zero, il client visualizza un [pulsante per una 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 `System`. 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 poi 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 verifica che il giocatore non abbia una partita in corso e, se non ce n'è una, [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 iscritta](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 fa `createGame` è [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, il che è necessario per Zokrates. Infine, `createGame` chiama [`calculateMapHash`](#calculateMapHash), per ottenere l'hash della mappa, che viene utilizzato come ID della partita.
+
+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 `System` 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 di MUD](https://mud.dev/config), [`mud.config.ts`](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/contracts/mud.config.ts#L67-L72).
+
+ L'elenco degli accessi consente a un solo indirizzo di chiamare il `System`. Questo 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 rilevanti:
+
+ - Crea la partita in `PlayerGame`.
+ - Imposta la mappatura inversa in `GamePlayer`.
+ - Rimuove 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 vinta o persa, il client [visualizza la mappa](https://github.com/qbzzt/20240901-secret-state/blob/main/packages/client/src/App.tsx#L175-L190).
+
+#### Scavare {#dig-flow}
+
+1. Il giocatore [clicca 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, se hanno esito positivo, 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 si tratta di una vittoria o di una sconfitta.
+
+## Utilizzare 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.
+
+### Eseguire l'hash della mappa {#hashing-map}
+
+Possiamo usare [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 rispetto al semplice utilizzo della 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. Esamineremo 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/). Prende un array di [elementi `field`](https://zokrates.github.io/language/types.html#field) e restituisce un `field`.
+
+L'elemento field 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 field, e in ogni field utilizziamo solo 128 bit. [La funzione `pack128`](https://github.com/Zokrates/ZoKrates/blob/latest/zokrates_stdlib/stdlib/utils/pack/bool/pack128.zok) trasforma un array di 128 bit in un `field` per questo scopo.
+
+```
+ def hashMap(bool[${width+2}][${height+2}] map) -> field {
+```
+
+Questa riga inizia 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 motivi che sono [spiegati di seguito](#why-map-border).
+
+Possiamo usare `${width+2}` e `${height+2}` perché i programmi Zokrates sono archiviati in questa applicazione come [stringhe template](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 della mappa. Il parametro della mappa ha un bordo largo una posizione tutto intorno senza alcuna bomba, motivo per cui dobbiamo aggiungere due alla larghezza e all'altezza.
+
+Il valore di ritorno è un `field` 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} {
+```
+
+Ecco come si dichiara un [ciclo `for`](https://zokrates.github.io/language/control_flow.html#for-loops) in Zokrates. Un ciclo `for` in Zokrates deve avere limiti fissi, perché sebbene sembri un ciclo, il compilatore in realtà lo "srotola". L'espressione `${width+2}` è una costante a tempo di compilazione perché `width` è impostata dal codice TypeScript prima che chiami 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])
+ ];
+```
+
+Il `pack128` per creare un array di quattro valori `field` da `map1d`. In Zokrates `array[a..b]` significa la porzione dell'array che inizia in `a` e finisce 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 direttamente `hashMap` per creare gli identificatori della partita. Tuttavia, Zokrates può chiamare solo la funzione `main` su 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}
+
+// The number of mines in location (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 facile equivalente a un'istruzione `if`. Invece, utilizzano l'equivalente dell'[operatore condizionale](https://en.wikipedia.org/wiki/Ternary_conditional_operator). Se `a` può essere zero o uno, puoi calcolare `if a { b } else { c }` come `ab+(1-a)c`.
+
+Per questo motivo, un'istruzione `if` in Zokrates valuta sempre entrambi i rami. Ad esempio, se hai 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 attorno 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. Il che 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 di Zokrates includono i loro input. Non serve a nulla sapere che ci sono cinque mine attorno a un punto a meno che tu non sappia effettivamente quale punto sia (e non puoi semplicemente abbinarlo alla tua richiesta, perché allora il prover potrebbe usare valori diversi e non dirtelo). Tuttavia, dobbiamo mantenere la mappa segreta, pur fornendola a Zokrates. La soluzione è utilizzare un parametro `private`, uno che _non_ viene rivelato dalla prova.
+
+Questo apre un'altra strada per gli abusi. Il prover potrebbe usare le coordinate corrette, ma creare una mappa con un numero qualsiasi di mine attorno 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 della partita.
+
+```
+ return (hashMap(map),
+```
+
+Il valore di ritorno qui è una tupla che include l'array dell'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 i conteggi delle mine per l'area attorno alla posizione e restituiscilo.
+
+### Utilizzare Zokrates da TypeScript {#using-zokrates-from-typescript}
+
+Zokrates ha un'interfaccia a riga di comando, ma in questo programma lo utilizziamo nel [codice TypeScript](https://zokrates.github.io/toolbox/zokrates_js.html).
+
+La libreria che contiene le definizioni di 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 solo una funzione, che è anch'essa [asincrona](https://www.w3schools.com/js/js_async.asp). Quando alla fine ritorna, 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.
+// In un sistema di produzione vorresti usare una cerimonia di setup.
+// (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 usare una [cerimonia di configurazione](https://zokrates.github.io/toolbox/trusted_setup.html#initializing-a-phase-2-ceremony) più complicata, ma questo è sufficiente per una dimostrazione. Non è un problema che gli utenti possano conoscere la chiave del prover: non possono comunque usarla per dimostrare 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 c'è bisogno di ripeterli ogni volta, solo quando cambia la dimensione della mappa. Su un sistema di produzione li faresti una volta e poi memorizzeresti l'output. L'unico motivo per cui non lo faccio qui è per motivi di 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 sono le informazioni necessarie per creare una prova a conoscenza-zero del risultato. Qui abbiamo solo bisogno dell'output.
+
+L'output è una stringa della forma `"31337"`, un numero decimale racchiuso tra virgolette. Ma l'output di cui abbiamo bisogno per `viem` è un numero esadecimale della forma `0x60A7`. Quindi usiamo `.slice(1,-1)` per rimuovere le virgolette e poi `BigInt` per convertire 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 = `
+ // Map size: ${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à prima o poi si rivelerà. Ma se l'applicazione è insicura, è probabile che rimanga nascosta per molto tempo prima di essere rivelata da qualcuno che imbroglia e se la cava con risorse che appartengono ad altri.
+
+### Permessi {#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 alle funzioni con permessi 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 errore, ma puoi aprire **MUD Dev Tools** nel gioco sul browser, cliccare su **Tables** e selezionare **app\_\_VerifierAddress**. Vedrai 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 `System` passano attraverso lo stesso controllo degli accessi, 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 della 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 viene eseguito correttamente fallisce. 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 farlo, 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
+000000000000000000000000000000000000000000000000205a65726f206b6e6f776c6564676520766572696669636174696f6
+e206661696c'
+ },
+```
+
+Quindi questo tipo di trucco fallisce.
+
+#### Prova sbagliata {#wrong-proof}
+
+Cosa succede se forniamo le informazioni corrette, ma abbiamo semplicemente 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 motivo perché accade durante la chiamata del verificatore.
+
+### Come può un utente verificare il codice zero trust? {#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 nella [transazione di distribuzione del contratto](/developers/docs/smart-contracts/deploying/). Nel caso dei `System` di 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 dimostrato.
+
+```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 di 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 sottostante 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 qualsiasi applicazione sufficientemente complessa ci sono obiettivi di progettazione in competizione che richiedono compromessi. Diamo un'occhiata ad alcuni dei compromessi e al motivo per cui la soluzione attuale è preferibile ad altre opzioni.
+
+### Perché la conoscenza-zero {#why-zero-knowledge}
+
+Per il campo minato non hai davvero bisogno della conoscenza-zero. Il server può sempre mantenere 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 la partita.
+
+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 dimostri lo stato _senza_ rivelarlo.
+
+Come tutorial, questo articolo aveva bisogno di un gioco breve e facile da capire, ma questa tecnica è più utile per i 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, controllerei 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 verificatore on-chain.
+
+### Creare le chiavi del verificatore e del prover {#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 eseguito più di una volta per una determinata dimensione del campo minato. Ancora una volta, viene eseguito solo una volta per motivi di 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 hai bisogno dell'entropia o di qualche risultato intermedio da ogni partecipante per imbrogliare sulla prova a conoscenza-zero. Se almeno un partecipante alla cerimonia è onesto ed elimina quelle informazioni, le prove a conoscenza-zero sono al sicuro da determinati attacchi. Tuttavia, non esiste _alcun meccanismo_ per verificare che le informazioni siano state eliminate da ovunque. Se le prove a conoscenza-zero sono di fondamentale importanza, vorrai 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 della chiave, 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é questo ti consente di [verificare il verificatore](#user-verify-zero-trust) una volta e poi fidarti che non cambi finché l'indirizzo del contratto per esso rimane lo stesso. Se la verifica fosse eseguita sul client, dovresti verificare il codice che ricevi ogni volta che scarichi il client.
+
+Inoltre, sebbene questo gioco sia per giocatore singolo, molti giochi blockchain sono multigiocatore. La verifica on-chain significa che verifichi la prova a conoscenza-zero solo una volta. Farlo nel client richiederebbe a ciascun 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 farla 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 e gli facciamo verificare che sia corretto. L'hashing deve essere eseguito all'interno di Zokrates, ma la corrispondenza tra l'hash restituito e l'hash on-chain può avvenire all'esterno.
+
+Tuttavia, continuiamo ad [appiattire 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. Il motivo è 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) un po' più complicato, quindi ho deciso che il guadagno in termini di prestazioni non ne vale la pena per un tutorial.
+
+- Inviare a Zokrates sia l'array unidimensionale che l'array bidimensionale. Tuttavia, questa soluzione non ci fa guadagnare nulla. Il codice Zokrates dovrebbe verificare che l'array unidimensionale fornito sia davvero la rappresentazione corretta dell'array bidimensionale. Quindi non ci sarebbe alcun guadagno in termini di prestazioni.
+
+- Appiattire l'array bidimensionale in Zokrates. Questa è l'opzione più semplice, quindi l'ho scelta.
+
+### Dove archiviare 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. Questo significa che se il tuo server muore e deve essere riavviato, tutte le informazioni che ha memorizzato vanno perse. Non solo i giocatori non sono in grado di continuare la loro partita, ma non possono nemmeno iniziare una nuova partita 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 memorizzeresti queste informazioni 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 on-chain. Ma in quali casi dovresti farlo? Ci sono due considerazioni principali.
+
+- _Gioco di lunga durata_: [Come menzionato sopra](#why-zero-knowledge), in un gioco breve puoi semplicemente pubblicare lo stato una volta che il gioco è finito e far verificare tutto in quel momento. 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à, ovvero che un'entità non stia falsificando i risultati. Quello che non possono fare è garantire che l'entità sarà ancora disponibile e risponderà ai messaggi. Nelle situazioni in cui anche la disponibilità deve essere decentralizzata, le prove a conoscenza-zero non sono una soluzione sufficiente e hai bisogno del [calcolo multipartecipante](https://en.wikipedia.org/wiki/Secure_multi-party_computation).
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
+
+### Ringraziamenti {#acknowledgements}
+
+- Alvaro Alonso ha letto una bozza di questo articolo e ha chiarito alcuni dei miei malintesi su Zokrates.
+
+Eventuali errori rimanenti sono di mia responsabilità.
\ No newline at end of file
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 bfc48a68fb7..ac029ad8141 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
@@ -1,56 +1,53 @@
---
-title: Elenco di controllo di sicurezza per gli smart contract
-description: Un flusso di lavoro suggerito per scrivere smart contract sicuri
+title: Lista di controllo per la sicurezza dei contratti intelligenti
+description: Un flusso di lavoro suggerito per scrivere contratti intelligenti sicuri
author: "Trailofbits"
-tags:
- - "smart Contract"
- - "sicurezza"
- - "Solidity"
+tags: ["contratti intelligenti", "sicurezza", "Solidity"]
skill: intermediate
-breadcrumb: "Lista di sicurezza"
+breadcrumb: Lista di controllo per la sicurezza
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.
+Ecco un processo ad alto livello che consigliamo di seguire durante la scrittura dei tuoi contratti intelligenti.
-Verifica i problemi di sicurezza noti:
+Controlla i problemi di sicurezza noti:
-- Revisiona i tuoi contratti con [Slither](https://github.com/crytic/slither). Ha oltre 40 rilevatori integrati per le vulnerabilità comuni. Eseguilo a ogni check-in con il nuovo codice e assicurati di ottenere un report pulito (o usa la modalità triage per silenziare certi problemi).
-- Revisiona i tuoi contratti con [Crytic](https://crytic.io/). Controlla 50 problemi non verificati da Slither. Crytic può aiutare il tuo team a prevenire problemi, facendo affiorare facilmente le questioni di sicurezza nelle richieste pull su GitHub.
+- Esamina i tuoi contratti con [Slither](https://github.com/crytic/slither). Ha più di 40 rilevatori integrati per le vulnerabilità comuni. Eseguilo a ogni check-in con nuovo codice e assicurati che ottenga un rapporto pulito (o usa la modalità triage per silenziare determinati problemi).
+- Esamina i tuoi contratti con [Crytic](https://crytic.io/). Controlla 50 problemi che Slither non rileva. Crytic può anche aiutare il tuo team a rimanere aggiornato, facendo emergere facilmente i problemi di sicurezza nelle Pull Request su GitHub.
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 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.
+- I tuoi contratti sono aggiornabili? Esamina il tuo codice di aggiornabilità per individuare 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 storti.
+- I tuoi contratti pretendono di essere 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.
+- Ti integri con token di terze parti? Esamina 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.
+- Esamina lo stampatore [inheritance-graph](https://github.com/trailofbits/slither/wiki/Printer-documentation#inheritance-graph) di Slither. Evita problemi di shadowing involontario e di linearizzazione C3.
+- Esamina lo stampatore [function-summary](https://github.com/trailofbits/slither/wiki/Printer-documentation#function-summary) di Slither. Segnala la visibilità delle funzioni e i controlli di accesso.
+- Esamina lo stampatore [vars-and-auth](https://github.com/trailofbits/slither/wiki/Printer-documentation#variables-written-and-authorization) di Slither. Segnala i controlli di 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.
+- 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à singola più importante per ottenere un buon risultato. È anche un prerequisito per usare una qualsiasi delle tecniche avanzate 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 a stati, sui controlli di accesso, sulle operazioni aritmetiche, sulle interazioni esterne e sulla 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 sull'ereditarietà, sulle dipendenze delle variabili, sui controlli di accesso e su altri problemi strutturali.
+- Esegui i tuoi test delle proprietà a ogni commit con [Crytic](https://crytic.io). Crytic può consumare e valutare i test delle proprietà di sicurezza in modo che tutti nel tuo team possano facilmente vedere che passano su GitHub. I test falliti possono bloccare i commit.
-Infine, ricordati dei problemi che gli strumenti automatizzati non possono facilmente trovare:
+Infine, fai attenzione ai problemi che gli strumenti automatizzati non possono trovare facilmente:
-- Mancanza di privacy: tutti gli altri possono vedere le tue transazioni mentre sono accodate nel pool
-- Transazioni in esecuzione frontale
+- Mancanza di privacy: tutti gli altri possono vedere le tue transazioni mentre sono in coda nel pool
+- Transazioni di front-running
- Operazioni crittografiche
-- Interazioni rischiose con componenti esterni della DeFi
+- Interazioni rischiose con componenti DeFi esterni
## 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.
+Gli [orari di ricevimento di Ethereum](https://calendly.com/dan-trailofbits/office-hours) si tengono ogni martedì pomeriggio. Queste sessioni individuali di 1 ora sono un'opportunità per farci qualsiasi domanda tu abbia sulla sicurezza, risolvere problemi usando i nostri strumenti e ottenere feedback dagli esperti sul tuo approccio attuale. Ti aiuteremo a lavorare su 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.
+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.
\ No newline at end of file
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 f463f014692..32c0a754c50 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
@@ -1,28 +1,26 @@
---
-title: Invio di token utilizzando ethers.js
-description: Guida per principianti per l'invio di token utilizzando ethers.js.
+title: Inviare token usando ethers.js
+description: Guida per principianti all'invio di token usando ethers.js.
author: Kim YongJun
-tags:
- - "ETHERS.JS"
- - "ERC-20"
- - "TOKEN"
+tags: ["ETHERS.JS", "ERC-20", "token"]
skill: beginner
-breadcrumb: "Inviare token"
+breadcrumb: Inviare token
lang: it
published: 2021-04-06
---
-## Invio di token utilizzando ethers.js(5.0) {#send-token}
+## Inviare token usando ethers.js(5.0) {#send-token}
### In questo tutorial imparerai come {#you-learn-about}
- Importare ethers.js
- Trasferire token
-- Imposta il prezzo del gas a seconda della situazione del traffico di rete
+- Impostare il prezzo del gas in base alla situazione del traffico di rete
### 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
+Includere ethers.js(5.0)
### Installazione {#install-ethersjs}
@@ -35,7 +33,7 @@ ES6 nel browser
```html
```
@@ -50,59 +48,59 @@ ES3(UMD) nel browser
### Parametri {#param}
-1. **`contract_address`**: Indirizzo del contratto del token (l'indirizzo del contratto è necessario quando il token che vuoi trasferire non è ether)
-2. **`send_token_amount`**: L'importo che vuoi inviare al destinatario
+1. **`contract_address`**: Indirizzo del contratto del token (l'indirizzo del contratto è necessario quando il token che si desidera trasferire non è ether)
+2. **`send_token_amount`**: L'importo che si desidera inviare al destinatario
3. **`to_address`**: L'indirizzo del destinatario
4. **`send_account`**: L'indirizzo del mittente
-5. **`private_key`**: La chiave privata del mittente per firmare la transazione e trasferire realmente i token
+5. **`private_key`**: Chiave privata del mittente per firmare la transazione e trasferire effettivamente i token
## Avviso {#notice}
-`signTransaction(tx)` è rimossa perché `sendTransaction()` lo fa internamente.
+`signTransaction(tx)` è stato rimosso perché `sendTransaction()` lo fa internamente.
-## Invio delle procedure {#procedure}
+## Procedure di invio {#procedure}
-### 1. Connettiti alla rete (rete di prova) {#connect-to-network}
+### 1. Connettersi alla rete (rete di test) {#connect-to-network}
-#### Imposta il provider (Infura) {#set-provider}
+#### Impostare il Provider (Infura) {#set-provider}
-Connettiti alla rete di prova di Ropsten
+Connettersi alla rete di test Ropsten
```javascript
window.ethersProvider = new ethers.providers.InfuraProvider("ropsten")
```
-### 2. Crea il portafoglio {#create-wallet}
+### 2. Creare il portafoglio {#create-wallet}
```javascript
let wallet = new ethers.Wallet(private_key)
```
-### 3. Connetti il portafoglio alla rete {#connect-wallet-to-net}
+### 3. Connettere il portafoglio alla rete {#connect-wallet-to-net}
```javascript
let walletSigner = wallet.connect(window.ethersProvider)
```
-### 4. Ottieni il prezzo corrente del gas {#get-gas}
+### 4. Ottenere il prezzo del gas attuale {#get-gas}
```javascript
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()`
### 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
+3. **`send_token_amount`**: la quantità di token da inviare
+4. **`gas_limit`**: limite del gas
5. **`gas_price`**: prezzo del gas
-[Vedi sotto come usarli](#how-to-use)
+[Vedi sotto per come usarlo](#how-to-use)
```javascript
const tx = {
@@ -147,9 +145,9 @@ send_token(
)
```
-### Fatto! {#success}
+### Successo! {#success}
-
+
## send_token() {#send-token-method}
@@ -169,23 +167,23 @@ function send_token(
console.log(`gas_price: ${gas_price}`)
if (contract_address) {
- // general token send
+ // invio generale di token
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")
})
- } // ether send
+ } // invio di ether
else {
const tx = {
from: send_account,
@@ -210,4 +208,4 @@ function send_token(
}
})
}
-```
+```
\ No newline at end of file
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 1858351794a..6b8cf311ff6 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,99 +1,96 @@
---
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."
+description: "Questa è una guida per principianti su come inviare transazioni su Ethereum usando 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
-breadcrumb: "Inviare transazioni"
+breadcrumb: Inviare transazioni
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 su come inviare transazioni su Ethereum usando 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 qualsiasi domanda tu possa avere! In questo tutorial, 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 serve per firmare le tue transazioni sul _backend_ per la tua app. Se vuoi integrare la firma delle tue transazioni sul frontend, dai un'occhiata all'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 agli inizi, potresti aver fatto delle ricerche su come inviare una transazione (qualcosa che dovrebbe essere piuttosto semplice) e ti sei imbattuto in una pletora di guide, ognuna delle quali dice cose diverse lasciandoti un po' sopraffatto e confuso. Se sei in questa situazione, non preoccuparti; ci siamo passati tutti a un certo punto! Quindi, prima di iniziare, chiariamo alcune cose:
### 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).
-- 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/)).
+- Questo significa che Alchemy non può firmare e inviare transazioni per tuo conto. Il motivo è per scopi di sicurezza. Alchemy non ti chiederà mai di condividere la tua chiave privata, e non dovresti mai condividere la tua chiave privata con un nodo ospitato (o con chiunque altro, se è per questo).
+- Puoi leggere dalla blockchain usando l'API principale di Alchemy, ma per scriverci dovrai usare qualcos'altro per firmare le tue transazioni prima di inviarle tramite Alchemy (questo vale per qualsiasi altro [servizio di nodi](/developers/docs/nodes-and-clients/nodes-as-a-service/)).
-### 2\. Cos'è un "firmatario"? {#what-is-a-signer}
+### 2\. Cos'è un "firmatario" (signer)? {#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 firmeranno le transazioni per te usando la tua chiave privata. In questo tutorial useremo [Alchemy web3](https://docs.alchemyapi.io/alchemy/documentation/alchemy-web3) per firmare la nostra transazione, ma potresti anche usare qualsiasi altra libreria web3.
+- Sul frontend, un buon esempio di firmatario sarebbe [MetaMask](https://metamask.io/), che firmerà e invierà transazioni per tuo conto.
### 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.
+- Ogni utente che vuole inviare una transazione sulla rete di Ethereum deve firmare la transazione (usando la propria chiave privata), al fine di convalidare che l'origine della transazione sia chi afferma di essere.
+- È importantissimo proteggere questa chiave privata, poiché avervi accesso garantisce il pieno controllo sul 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}
-- 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 transazioni. In questo tutorial useremo un file `.env`. Tuttavia, potresti anche usare un provider separato che memorizza 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` ed `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` ed `eth_sendRawTransaction` sono entrambe funzioni dell'API di Ethereum che trasmettono una transazione alla rete di Ethereum in modo che 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. Questo significa che devi prima usare [`signTransaction(tx, private_key)`](https://docs.web3js.org/api/web3-eth-accounts/function/signTransaction), per poi passare il risultato a `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 questo tutorial.
-### 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 attorno alle chiamate JSON-RPC standard che è piuttosto comune da usare nello sviluppo su Ethereum.
+- Ci sono molte librerie web3 per diversi linguaggi. In questo tutorial useremo [Alchemy Web3](https://docs.alchemy.com/reference/api-overview) che è scritta in JavaScript. Puoi dare un'occhiata ad 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 tolto di mezzo alcune di queste domande, passiamo al tutorial. 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 prelevata 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, NodeJs e npm installati. 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)
+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\. Crea 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.
+Naviga nella tua [Dashboard di Alchemy](https://dashboard.alchemyapi.io/) e crea una nuova app, scegliendo Sepolia (o qualsiasi altra rete di test) per la tua rete.
-### 2\. Richiedere ETH dal faucet di Sepolia {#request-eth-from-sepolia-faucet}
+### 2\. Richiedi ETH dal rubinetto 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 [rubinetto Sepolia di Alchemy](https://www.sepoliafaucet.com/) per ricevere ETH. Assicurati di includere il tuo indirizzo 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.
-### 3\. Crea la cartella di un nuovo progetto e `cd` al suo interno {#create-a-new-project-direction}
+### 3\. Crea una nuova directory di progetto ed entraci 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\. Installa 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 usare la libreria ethers.js, [segui le istruzioni qui](https://docs.alchemy.com/docs/how-to-send-transactions-on-ethereum).
```
npm install @alch/alchemy-web3
@@ -101,7 +98,7 @@ npm install @alch/alchemy-web3
### 5\. Installa dotenv {#install-dotenv}
-Useremo un file `.env` per memorizzare in sicurezza la nostra chiave API e la chiave privata.
+Useremo un file `.env` per memorizzare in modo sicuro la nostra chiave API e la chiave privata.
```
npm install dotenv --save
@@ -109,9 +106,9 @@ npm install dotenv --save
### 6\. Crea 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 l'URL della tua API di Alchemy, naviga nella pagina dei dettagli dell'app che hai appena creato sulla tua dashboard, clicca su "View Key" nell'angolo in alto a destra e prendi 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).
```
@@ -122,16 +119,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 committare .env! Assicurati di non condividere o esporre mai il tuo file .env a nessuno, poiché così facendo comprometti i tuoi segreti. Se stai usando il controllo di versione, aggiungi il tuo .env a un file gitignore.
### 7\. Crea 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 i nostri dati sensibili protetti in un file `.env`, iniziamo a programmare. Per il nostro esempio di invio di transazione, invieremo ETH indietro al rubinetto 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`, che è dove configureremo e invieremo la nostra transazione di esempio, e aggiungi le seguenti righe di codice:
```
async function main() {
@@ -167,45 +164,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 componenti qui presenti.
-- `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 scopi di sicurezza e per prevenire [attacchi di replay](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 inviando ETH indietro al [rubinetto 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`: Ci sono molti modi per determinare la giusta quantità di gas da includere nella tua transazione. Alchemy ha persino 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 entro 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 userà, quindi per assicurarci che la nostra transazione venga eseguita mettiamo 30000 qui.
+ - `nonce`: vedi la definizione di nonce sopra. Il nonce inizia a contare da zero.
+ - [OPZIONALE] data: Usato per inviare informazioni aggiuntive con il tuo trasferimento, o per chiamare un contratto intelligente, non richiesto per i trasferimenti di saldo, dai un'occhiata alla nota qui sotto.
+- `signedTx`: Per firmare il nostro oggetto transazione useremo il metodo `signTransaction` con la nostra `PRIVATE_KEY`
+- `sendSignedTransaction`: Una volta che abbiamo una transazione firmata, possiamo inviarla per essere inclusa 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 (data)**
+Ci sono due tipi principali di transazioni che possono essere inviate su 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 tua 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 al fine di dargli un timestamp immutabile. Il nostro campo dati dovrebbe quindi apparire come data: `web3.utils.toHex(‘IPFS hash‘)`. E ora chiunque può interrogare la catena e vedere quando quel documento è stato aggiunto.
+- Transazione di contratto intelligente: Esegui del codice di un contratto intelligente sulla catena. In questo caso, il campo dati dovrebbe contenere la funzione intelligente che desideri eseguire, insieme a eventuali parametri.
+ - Per un esempio pratico, dai un'occhiata al Passaggio 8 in questo [Tutorial 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}
-Torna al terminale o alla riga di comando ed esegui:
+Torna al tuo terminale o riga di comando ed esegui:
```
node sendTx.js
```
-### 9\. Visualizza la tua transazione nel Mempool {#see-your-transaction-in-the-mempool}
+### 9\. Vedi 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 Mempool](https://dashboard.alchemyapi.io/mempool) nella tua dashboard di Alchemy e filtra per l'app che hai creato per trovare la tua transazione. È qui che possiamo osservare la nostra transazione passare dallo stato in sospeso (pending) allo stato minato (mined) (se ha successo) o allo stato scartato (dropped) se non ha successo. 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 della transazione (tx hash), che dovrebbe portarti a una vista simile a 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 cliccando 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 su 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)_
\ No newline at end of file
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..2a4235758c7
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/server-components/index.md
@@ -0,0 +1,296 @@
+---
+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 vulnerabilità), ma in grado di interagire con le entità web3. Le stesse tecniche possono essere utilizzate anche per scrivere un agente che risponde agli eventi on-chain senza l'intervento umano."
+
+author: Ori Pomerantz
+lang: it
+tags: ["agente", "server", "fuori catena", "dApp"]
+skill: beginner
+breadcrumb: Componenti server
+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, il 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 tale server sarebbe in grado di rispondere agli eventi e alle richieste provenienti da altre fonti, come un'API, emettendo transazioni.
+
+
+
+Ci sono diverse possibili attività che un tale server potrebbe svolgere.
+
+- Detentore di uno stato segreto. Nel gaming è spesso utile non avere tutte le informazioni note al gioco a disposizione dei giocatori. Tuttavia, _non ci sono segreti sulla blockchain_, qualsiasi informazione presente nella blockchain è facile da scoprire per chiunque. Pertanto, se parte dello stato del gioco deve essere mantenuta segreta, deve essere archiviata altrove (e possibilmente far verificare gli effetti di tale stato utilizzando [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 potrebbe essere sufficiente per essere utilizzato come [oracolo](/developers/docs/oracles/).
+
+- Agente. Non succede nulla 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 modificato, 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à fatto, [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 possiede ETH sulla rete di test Holesky. Se non hai ETH su Holesky, puoi [usare questo rubinetto](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, utilizzando un indirizzo diverso da quello che possiede la chiave privata, modifica il saluto. Vedrai che il saluto viene automaticamente ripristinato.
+
+### 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/), che è 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 consente di generare le informazioni del portafoglio, incluso l'indirizzo, corrispondenti a una chiave privata.
+
+```typescript
+import { holesky } from "viem/chains"
+```
+
+Per utilizzare 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
+// Ecco come aggiungiamo le definizioni in .env a process.env.
+import * as dotenv from "dotenv"
+dotenv.config()
+```
+
+Ecco come leggiamo `.env` nell'ambiente. Ne abbiamo bisogno per la chiave privata (vedi in seguito).
+
+```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 utilizzare un contratto abbiamo bisogno del suo indirizzo e della sua [ABI](/glossary/#abi). Li forniamo entrambi qui.
+
+In JavaScript (e quindi in TypeScript) non puoi assegnare un nuovo valore a una costante, ma _puoi_ modificare l'oggetto in essa memorizzato. Utilizzando il suffisso `as const` stiamo dicendo a TypeScript che l'elenco stesso è costante e non può essere modificato.
+
+```typescript
+const publicClient = createPublicClient({
+ chain: holesky,
+ transport: http(),
+})
+```
+
+Crea un [client pubblico](https://viem.sh/docs/clients/public.html) Viem. I client pubblici non hanno una chiave privata associata e pertanto non possono inviare transazioni. Possono chiamare [funzioni `view`](https://www.tutorialspoint.com/solidity/solidity_view_functions.htm), leggere i saldi degli account, 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 qualsiasi stringa, 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, utilizziamo 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 del contratto](https://viem.sh/docs/contract/getContract). Utilizzeremo questa istanza del contratto per comunicare con il contratto on-chain.
+
+##### Lettura dalla blockchain
+
+```typescript
+console.log(`Current greeting:`, await greeter.read.greet())
+```
+
+Le funzioni del contratto 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, lo utilizziamo per accedere alla funzione [`greet`](https://eth-holesky.blockscout.com/address/0xB8f6460Dc30c44401Be26B0d6eD250873d8a50A6?tab=read_contract#cfae3217), che restituisce il saluto.
+
+JavaScript è a thread singolo, quindi quando avviamo un processo di lunga durata 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 viaggio di andata e ritorno tra il computer e un nodo della blockchain. Questo è il motivo per cui specifichiamo qui che il codice deve attendere (`await`) il risultato.
+
+Se sei interessato a come funziona, puoi [leggerlo qui](https://www.w3schools.com/js/js_promise.asp), ma in termini pratici tutto ciò che devi sapere è che devi usare `await` per i risultati se avvii un'operazione che richiede molto tempo, e che qualsiasi funzione che lo fa 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 modifica 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 contiene tutte le funzioni che scrivono nello 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, vengono forniti come elenco 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
+}
+```
+
+Segnala 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) ti 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 utilizzare 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 diversi tipi di applicazioni node JavaScript. Il tipo `module` ci consente di avere `await` nel codice di livello superiore, 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 utilizzando 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) indica quella versione o una versione superiore che non presenta modifiche incompatibili. 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 esecuzione, quando si esegue `dist/app.js`.
+
+## Conclusione {#conclusion}
+
+Il server centralizzato che abbiamo creato qui fa il suo lavoro, ovvero agire come 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 devi fidarti 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/).
\ No newline at end of file
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 dfa2b35e011..8fe243e2c3b 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,12 +1,10 @@
---
-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
+title: Configurare web3.js per usare la blockchain di Ethereum in JavaScript
+description: Scopri come impostare e configurare la libreria web3.js per interagire con la blockchain di Ethereum dalle applicazioni JavaScript.
author: "jdourlens"
-tags:
- - "web3.js"
- - "javascript"
+tags: ["web3.js", "JavaScript"]
skill: beginner
-breadcrumb: "Configurare web3.js"
+breadcrumb: configurazione di web3.js
lang: it
published: 2020-04-11
source: EthereumDev
@@ -14,39 +12,39 @@ 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 questo tutorial, vedremo come iniziare con [web3.js](https://web3js.readthedocs.io/) per interagire con la blockchain di Ethereum. Web3.js può essere usato sia nei frontend che nei backend per leggere dati dalla blockchain o effettuare transazioni e persino distribuire contratti intelligenti.
-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 una 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 per usarla nel tuo backend o in un progetto frontend che usa build, puoi installarla usando npm:
```bash
npm install web3 --save
```
-A questo punto, per importare Web3.js in uno script Node.js o un progetto frontend di Browserify, puoi usare la seguente riga di JavaScript:
+Quindi, per importare Web3.js in uno script Node.js o in un progetto frontend Browserify, puoi usare la seguente riga di JavaScript:
```js
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 abbiamo incluso la libreria nel progetto, dobbiamo inizializzarla. Il tuo progetto deve essere in grado di comunicare con la blockchain. La maggior parte delle librerie di Ethereum comunica con un [nodo](/developers/docs/nodes-and-clients/) tramite chiamate RPC. Per avviare il nostro provider Web3, istanzieremo un'istanza Web3 passando come costruttore l'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ì:
```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 ospitato, 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")
```
-Per verificare di aver configurato correttamente la nostra istanza di Web3, proveremo a recuperare il numero dell'ultimo blocco usando la funzione `getBlockNumber`. Questa funzione accetta un callback come parametro e restituisce il numero del blocco come un intero.
+Per testare di aver configurato correttamente la nostra istanza Web3, proveremo a recuperare l'ultimo numero del blocco usando la funzione `getBlockNumber`. Questa funzione accetta un callback come parametro e restituisce il numero del blocco come intero.
```js
var Web3 = require("web3")
@@ -57,7 +55,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 l'ultimo numero del 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() {
@@ -69,27 +67,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 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.
(,...)`.
+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 byte di `length` più significativi fanno parte del campo, quindi eseguiamo uno [scorrimento a destra](https://en.wikipedia.org/wiki/Logical_shift) per sbarazzarci degli altri valori.
+Questo ha l'ulteriore vantaggio di spostare il valore a destra del campo, in modo che sia il valore stesso piuttosto che il valore moltiplicato per 256qualcosa.
```solidity
@@ -160,7 +190,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 Solidity non corrisponde a nessuna delle firme delle funzioni, chiama [la funzione `fallback()`](https://docs.soliditylang.org/en/v0.8.12/contracts.html#fallback-function) (supponendo che ce ne sia una).
+Nel caso di `CalldataInterpreter`, _qualsiasi_ chiamata arriva qui perché non ci sono altre funzioni `external` o `public`.
```solidity
uint _func;
@@ -168,23 +199,27 @@ 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:
+Legge il primo byte dei calldata, che ci indica la funzione.
+Ci sono due motivi per cui una funzione non sarebbe 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 catena).
+ Non ha senso cercare di ridurre il loro costo del gas.
+2. Le 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 il 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 solo due funzioni: `transfer` (perché possiamo chiamare `transferFrom`) e `faucet` (perché possiamo trasferire i token indietro a chi ci ha chiamato).
```solidity
- // Call the state changing methods of token using
- // information from the calldata
+ // Chiama i metodi che modificano lo stato del token utilizzando
+ // le informazioni dal calldata
// faucet
if (_func == 1) {
```
-Una chiamata a `faucet()`, priva di parametri.
+Una chiamata a `faucet()`, che non ha parametri.
```solidity
token.faucet();
@@ -193,56 +228,60 @@ 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 dei token. Tuttavia, come contratto proxy, non abbiamo **bisogno** di token.
+L'account controllato esternamente (EOA) o il contratto che ci ha chiamato ne ha bisogno.
+Quindi trasferiamo tutti i nostri token a chi ci ha chiamato.
```solidity
- // transfer (assume we have an allowance for it)
+ // transfer (supponiamo di avere un'allowance per questo)
if (_func == 2) {
```
-Il trasferimento dei token richiede due parametri: l'indirizzo di destinazione e l'importo.
+Il trasferimento di token richiede due parametri: l'indirizzo di destinazione e l'importo.
```solidity
token.transferFrom(
msg.sender,
```
-Consentiamo solo ai chiamanti di trasferire i token che possiedono
+Consentiamo ai chiamanti di trasferire solo i token che possiedono
```solidity
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)
```
-Per questo contratto specifico supponiamo che il numero massimo di token che chiunque voglia trasferire entri in due byte (meno di 65536).
+Per questo particolare contratto supponiamo che il numero massimo di token che chiunque vorrebbe trasferire stia in due byte (meno di 65536).
```solidity
);
}
```
-In generale, un trasferimento richiede 35 byte di calldata:
+Nel complesso, 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 |
+| Sezione | Lunghezza | Byte |
+| ------------------- | -----: | ----: |
+| Selettore di funzione | 1 | 0 |
+| Indirizzo di destinazione | 32 | 1-32 |
+| Importo | 2 | 33-34 |
```solidity
- } // fallback
+ } // fallback
-} // contract CalldataInterpreter
+} // contract CalldataInterpreter
```
### 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 test unitario in JavaScript](https://github.com/qbzzt/ethereum.org-20220330-shortABI/blob/master/test/test.js) ci mostra come utilizzare questo meccanismo (e come verificare che funzioni correttamente).
+Supporrò che tu conosca [chai](https://www.chaijs.com/) ed [ethers](https://docs.ethers.io/v5/) e spiegherò solo le parti che si applicano specificamente al contratto.
```js
const { expect } = require("chai");
@@ -265,11 +304,12 @@ describe("CalldataInterpreter", function () {
Iniziamo distribuendo entrambi i contratti.
```javascript
- // Get tokens to play with
+ // Ottieni 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 transazioni, perché non seguiamo l'ABI.
+Invece, dobbiamo costruire la transazione noi stessi e poi inviarla.
```javascript
to: cdi.address,
@@ -278,8 +318,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 rubinetto, i dati sono un singolo byte, `0x01`.
```javascript
@@ -287,26 +329,27 @@ Ci sono due parametri che dobbiamo fornire per la transazione:
await (await signer.sendTransaction(faucetTx)).wait()
```
-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.
+Chiamiamo [il metodo `sendTransaction` del firmatario](https://docs.ethers.io/v5/api/signer/#Signer-sendTransaction) perché abbiamo già specificato la destinazione (`faucetTx.to`) e abbiamo bisogno che la transazione sia firmata.
```javascript
-// Check the faucet provides the tokens correctly
+// Verifica che il faucet fornisca i token correttamente
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 c'è bisogno di risparmiare gas sulle funzioni `view`, quindi le eseguiamo normalmente.
```javascript
-// Give the CDI an allowance (approvals cannot be proxied)
+// Fornisci un'allowance al CDI (le approvazioni non possono essere gestite tramite proxy)
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.
+Fornisce all'interprete dei calldata un'autorizzazione per poter effettuare trasferimenti.
```javascript
-// Transfer tokens
+// Trasferisci token
const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
const transferTx = {
to: cdi.address,
@@ -314,54 +357,53 @@ const transferTx = {
}
```
-Crea una transazione di trasferimento. Il primo byte è "0x02", seguito dall'indirizzo di destinazione e infine dall'importo (0x0100, ovvero 256 in decimale).
+Crea una transazione di trasferimento. Il primo byte è "0x02", seguito dall'indirizzo di destinazione e infine dall'importo (0x0100, che è 256 in decimale).
```javascript
await (await signer.sendTransaction(transferTx)).wait()
- // Check that we have 256 tokens less
+ // Verifica 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 abbia ricevuti
expect (await token.balanceOf(destAddr)).to.equal(256)
- }) // it
-}) // describe
+ }) // 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 si controlla il contratto di destinazione {#reducing-the-cost-when-you-do-control-the-destination-contract}
-## Ridurre il costo quando hai il controllo del 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 aggirano i controlli di `msg.sender` perché 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 ramo `control-contract`](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract).
-
-Se il contratto rispondesse solo alle transazioni esterne, potremmo riuscirsi con un solo contratto. Tuttavia, questo spezzerebbe la [componibilità](/developers/docs/smart-contracts/composability/). È molto meglio avere un contratto che risponda alle normali chiamate ERC-20 e un altro che risponda alle transazioni con dati della chiamata brevi.
+Se il contratto rispondesse solo a transazioni esterne, potremmo cavarcela con un solo contratto.
+Tuttavia, ciò interromperebbe la [componibilità](/developers/docs/smart-contracts/composability/).
+È molto meglio avere un contratto che risponde alle normali chiamate ERC-20 e un altro contratto che risponde alle transazioni con dati di 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 una serie 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 del CalldataInterpreter
address owner;
- // The CalldataInterpreter address
+ // L'indirizzo del 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 ne conosciamo ancora il valore.
+Questo contratto viene istanziato per primo perché il proxy si aspetta l'indirizzo del token nel suo costruttore.
```solidity
- /**
- * @dev Calls the ERC20 constructor.
- */
+ /* *
+ * @dev Chiama il costruttore ERC20. */
+
+
+
constructor(
) ERC20("Oris useless token-2", "OUT-2") {
owner = msg.sender;
@@ -371,43 +413,52 @@ Il contratto ERC-20 deve conoscere l'identità del proxy autorizzato. Tuttavia,
L'indirizzo del creatore (chiamato `owner`) è memorizzato qui perché è l'unico indirizzo autorizzato a impostare il proxy.
```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 (il CalldataInterpreter).
+ * Può essere chiamato 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");
proxy = _proxy;
- } // function setProxy
+ } // 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 un accesso privilegiato, perché può aggirare i controlli di sicurezza.
+Per assicurarci di potercene fidare, permettiamo solo a `owner` di chiamare questa funzione, e solo una volta.
+Una volta che `proxy` ha un valore reale (diverso da zero), quel valore non può cambiare, quindi anche se il proprietario decide di diventare disonesto, o la sua frase 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`.
+Per prima cosa, verifica che siamo stati chiamati dal proxy e da nessun altro.
+In caso contrario, esegue un `revert`.
```solidity
_;
}
```
-Se è così, esegui la funzione che modifichiamo.
+In caso affermativo, esegue la funzione che modifichiamo.
```solidity
+ /* Funzioni che consentono al proxy di fungere effettivamente da proxy per gli account */
/* Functions that allow the proxy to actually proxy for accounts */
function transferProxy(address from, address to, uint256 amount)
@@ -437,17 +488,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 trasferisce i token o che approva un'autorizzazione.
+Qui abbiamo una versione proxy di queste operazioni che:
-1. È modificata da `onlyProxy()`, così che nessun altro possa controllarla.
-2. Ottiene l'indirizzo che sarebbe normalmente `msg.sender` come un parametro aggiuntivo.
+1. È modificata da `onlyProxy()` in modo che a nessun altro sia permesso controllarle.
+2. Ottiene l'indirizzo che normalmente sarebbe `msg.sender` come 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 calldata è quasi identico a quello precedente, tranne per il fatto che le funzioni proxy ricevono un parametro `msg.sender` e non c'è bisogno di un'autorizzazione per il `transfer`.
```solidity
- // transfer (no need for allowance)
+ // transfer (nessun bisogno di allowance)
if (_func == 2) {
token.transferProxy(
msg.sender,
@@ -492,16 +544,17 @@ Dobbiamo dire al contratto ERC-20 di quale proxy fidarsi
```js
console.log("CalldataInterpreter addr:", cdi.address)
-// Need two signers to verify allowances
+// Sono necessari due firmatari per verificare le allowance
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 controllare `approve()` e `transferFrom()` abbiamo bisogno di un secondo firmatario.
+Lo chiamiamo `poorSigner` perché non ottiene nessuno dei nostri token (deve avere ETH, ovviamente).
```js
-// Transfer tokens
+// Trasferisci token
const destAddr = "0xf5a6ead936fb47f342bb63e676479bddf26ebe1d"
const transferTx = {
to: cdi.address,
@@ -510,10 +563,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 abbiamo bisogno di un'autorizzazione per inoltrare i trasferimenti.
```js
-// approval and transferFrom
+// approval e transferFrom
const approveTx = {
to: cdi.address,
data: "0x03" + poorSigner.address.slice(2, 42) + "00FF",
@@ -528,24 +581,18 @@ const transferFromTx = {
}
await (await poorSigner.sendTransaction(transferFromTx)).wait()
-// Check the approve / transferFrom combo was done correctly
+// Verifica che la combinazione approve / 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.
-
-### Esempio {#example-2}
-
-Se desideri vedere questi file in azione senza eseguirli tu stesso, segui questi link:
-
-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`.
+Testa le due nuove funzioni.
+Nota che `transferFromTx` richiede due parametri di indirizzo: chi fornisce l'autorizzazione e il destinatario.
## Conclusione {#conclusion}
-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.
+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 su L1 e quindi il costo delle transazioni.
+Tuttavia, come fornitori di infrastrutture alla ricerca di soluzioni generiche, le nostre capacità sono limitate.
+Come sviluppatore di dApp, hai una conoscenza specifica dell'applicazione, che ti consente 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.
+
+[Vedi qui per altri miei lavori](https://cryptodocguy.pro/).
\ No newline at end of file
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 e74be72019e..c595bfa9466 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,95 +1,92 @@
---
-title: Linee guida di sicurezza per gli Smart Contract
-description: Elenco di controllo con le linee guida di sicurezza da tenere presenti per la creazione di una dapp
+title: Linee guida per la sicurezza dei contratti intelligenti
+description: Una lista di controllo delle linee guida per la sicurezza da considerare quando si crea la propria dApp
author: "Trailofbits"
-tags:
- - "solidity"
- - "smart contract"
- - "sicurezza"
+tags: ["Solidity", "contratti intelligenti", "sicurezza"]
skill: intermediate
-breadcrumb: "Linee guida sicurezza"
+breadcrumb: Linee guida per la sicurezza
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
---
-Segui questi consigli di alto livello per creare Smart Contract più sicuri.
+Segui queste raccomandazioni di alto livello per creare contratti intelligenti più sicuri.
-## Linee guida di progettazione {#design-guidelines}
+## Linee guida per la progettazione {#design-guidelines}
-La progettazione del contratto deve essere discussa in anticipo, prima di scrivere la prima riga di codice.
+La progettazione del contratto dovrebbe essere discussa in anticipo, prima di scrivere qualsiasi riga di codice.
### Documentazione e specifiche {#documentation-and-specifications}
-La documentazione può essere scritta su diversi livelli e deve essere aggiornata durante l'implementazione dei contratti:
+La documentazione può essere scritta a diversi livelli e dovrebbe 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.
+- **Una descrizione in linguaggio semplice del sistema**, che descriva cosa fanno i contratti e qualsiasi presupposto sulla base di codice.
+- **Schemi e diagrammi architetturali**, 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 utilizzato per Solidity.
-### Calcolo sulla catena ed esterno alla catena {#on-chain-vs-off-chain-computation}
+### Calcolo on-chain vs fuori catena {#onchain-vs-offchain-computation}
-- **Mantieni quanto più codice possibile al di fuori della catena.** Il livello sulla catena deve essere il più ridotto possibile. Elabora anticipatamente i dati con il codice esternamente alla catena così che la verifica su di essa sia semplice. Ti serve un elenco ordinato? Ordina l'elenco esternamente alla catena, poi controlla solo l'ordine sulla catena.
+- **Mantieni quanto più codice possibile fuori catena.** Mantieni piccolo il livello on-chain. Pre-elabora i dati con codice fuori catena in modo tale che la verifica on-chain sia semplice. Hai bisogno di un elenco ordinato? Ordina l'elenco fuori catena, quindi controlla solo il suo ordine on-chain.
### 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 se supportare o meno l'aggiornabilità prima di scrivere qualsiasi codice. La decisione influenzerà il modo in cui strutturi il tuo codice. In generale, raccomandiamo:
-- **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:
- - 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.
+- **Privilegiare la [migrazione del contratto](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) rispetto all'aggiornabilità.** I sistemi di migrazione hanno molti degli stessi vantaggi di quelli aggiornabili, senza i loro svantaggi.
+- **Utilizzare il modello di separazione dei dati rispetto a quello delegatecallproxy.** Se il tuo progetto ha una chiara separazione dell'astrazione, l'aggiornabilità utilizzando la separazione dei dati richiederà solo pochi aggiustamenti. Il delegatecallproxy richiede esperienza con l'EVM ed è altamente soggetto a errori.
+- **Documentare la procedura di migrazione/aggiornamento prima della distribuzione.** Se devi reagire sotto stress senza alcuna linea guida, commetterai degli errori. Scrivi in anticipo la procedura da seguire. Dovrebbe includere:
+ - Le chiamate che avviano i nuovi contratti
+ - Dove sono archiviate le chiavi e come accedervi
+ - Come controllare la distribuzione! Sviluppa e testa uno script post-distribuzione.
## Linee guida per l'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.
+**Punta alla semplicità.** Usa sempre la soluzione più semplice che si adatta al tuo scopo. Qualsiasi membro del tuo team dovrebbe essere in grado di comprendere la tua soluzione.
-### Composizione della funzione {#function-composition}
+### Composizione delle 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.
+L'architettura della tua base di codice dovrebbe rendere il tuo codice facile da revisionare. Evita scelte architetturali che riducono la capacità di ragionare sulla sua correttezza.
-- **Dividi la logica del tuo sistema**, tramite più contratti o raggruppando le funzioni simili (ad esempio, autenticazione, aritmetica, ...).
-- **Scrivi funzioni piccole, con uno scopo chiaro.** Questo faciliterà il controllo e consentirà di testare singoli componenti.
+- **Dividi la logica del tuo sistema**, tramite più contratti o raggruppando funzioni simili (ad esempio, autenticazione, aritmetica, ...).
+- **Scrivi funzioni piccole, con uno scopo chiaro.** Questo faciliterà la revisione e consentirà il test dei singoli componenti.
### 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.
+- **Mantieni l'ereditarietà gestibile.** L'ereditarietà dovrebbe essere utilizzata per dividere la logica, tuttavia, il tuo progetto dovrebbe mirare a ridurre al minimo la profondità e l'ampiezza dell'albero di ereditarietà.
+- **Usa la [stampante di ereditarietà](https://github.com/crytic/slither/wiki/Printer-documentation#inheritance-graph) di Slither per controllare la gerarchia dei contratti.** La stampante di ereditarietà ti aiuterà a revisionare le dimensioni 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.
+- **Registra tutte le operazioni cruciali.** Gli eventi aiuteranno a eseguire il debug del contratto durante lo sviluppo e a monitorarlo dopo la distribuzione.
-### Evita trappole note {#avoid-known-pitfalls}
+### Evita le insidie 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/).
+- **Presta attenzione alle sezioni di avvertenza nella [documentazione di Solidity](https://docs.soliditylang.org/en/latest/).** Le sezioni di avvertenza ti informeranno sui comportamenti non ovvi 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 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.
+- **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 di copiare e incollare il codice.** Se ti affidi a una fonte esterna, devi mantenerla aggiornata con la fonte originale.
### 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.** Una suite di test estesa è fondamentale 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. Rivedi 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 ai rilevatori privati di Slither ed esegue controlli di proprietà personalizzati 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.
+- **Privilegia Solidity 0.5 rispetto a 0.4 e 0.6.** Secondo noi, Solidity 0.5 è più sicuro e ha migliori pratiche integrate rispetto a 0.4. Solidity 0.6 si è dimostrato troppo instabile per la produzione e ha bisogno di tempo per maturare.
+- **Usa una versione stabile per compilare; usa l'ultima versione per controllare gli avvisi.** Verifica che il tuo codice non abbia problemi segnalati con l'ultima versione del compilatore. Tuttavia, Solidity ha un ciclo di rilascio rapido e una storia di bug del compilatore, quindi non raccomandiamo l'ultima versione per la distribuzione (vedi la [raccomandazione sulla versione di solc](https://github.com/crytic/slither/wiki/Detector-Documentation#recommendation-33) di Slither).
+- **Non usare l'assembly inline.** L'assembly richiede esperienza con l'EVM. Non scrivere codice EVM se non hai _padroneggiato_ lo yellow paper.
-## Linee guida di distribuzione {#deployment-guidelines}
+## Linee guida per la distribuzione {#deployment-guidelines}
-Una volta sviluppato e distribuito il contratto:
+Una volta che il contratto è stato sviluppato e distribuito:
-- **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.
+- **Monitora i tuoi contratti.** Osserva i log e tieniti pronto a reagire in caso di compromissione del contratto o del portafoglio.
+- **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 scoperta una falla di sicurezza.
+- **Metti al sicuro i portafogli degli utenti privilegiati.** Segui le nostre [migliori pratiche](https://blog.trailofbits.com/2018/11/27/10-rules-for-the-secure-use-of-cryptocurrency-hardware-wallets/) se archivi le chiavi in portafogli hardware.
+- **Avere un piano di risposta agli incidenti.** Considera che i tuoi contratti intelligenti possono essere compromessi. Anche se i tuoi contratti sono privi di bug, un utente malintenzionato potrebbe prendere il controllo delle chiavi del proprietario del contratto.
\ No newline at end of file
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..45ad6a85e12
--- /dev/null
+++ b/public/content/translations/it/developers/tutorials/stealth-addr/index.md
@@ -0,0 +1,437 @@
+---
+title: "Usare gli indirizzi stealth"
+description: "Gli indirizzi stealth consentono agli utenti di trasferire asset in modo anonimo. Dopo aver letto questo articolo, sarai in grado di: spiegare cosa sono gli indirizzi stealth e come funzionano, capire come usare gli indirizzi stealth in modo da preservare l'anonimato e scrivere un'applicazione basata sul web che utilizza gli indirizzi stealth."
+author: Ori Pomerantz
+tags: ["Indirizzo stealth", "privacy", "crittografia", "Rust", "wasm"]
+skill: intermediate
+breadcrumb: Indirizzi stealth
+published: 2025-11-30
+lang: it
+sidebarDepth: 3
+---
+
+Sei Bill. Per ragioni in cui non entreremo, vuoi donare alla campagna "Alice Regina del Mondo" e far sapere ad Alice che hai donato, in modo che ti ricompensi se vince. Sfortunatamente, la sua vittoria non è garantita. C'è una campagna concorrente, "Carol Imperatrice del Sistema Solare". Se Carol vince e scopre che hai donato ad Alice, sarai nei guai. Quindi non puoi semplicemente trasferire 200 ETH dal tuo account a quello di Alice.
+
+[ERC-5564](https://eips.ethereum.org/EIPS/eip-5564) ha la soluzione. Questo ERC spiega come utilizzare gli [indirizzi stealth](https://nerolation.github.io/stealth-utils) per i trasferimenti anonimi.
+
+**Attenzione**: La crittografia alla base degli indirizzi stealth è, per quanto ne sappiamo, solida. Tuttavia, ci sono potenziali attacchi side-channel (a canale laterale). [Di seguito](#go-wrong), vedrai cosa puoi fare per ridurre questo rischio.
+
+## Come funzionano gli indirizzi stealth {#how}
+
+Questo articolo cercherà di spiegare gli indirizzi stealth 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 c'è dietro](#how-math). Se ti interessa la crittografia, leggi anche questa parte.
+
+### La versione semplice (come usare gli indirizzi stealth) {#how-use}
+
+Alice crea due chiavi private e pubblica le chiavi pubbliche corrispondenti (che possono essere combinate in un singolo meta-indirizzo a 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 solo dalle chiavi pubbliche). Usando questo segreto condiviso, Bill ottiene l'indirizzo stealth 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 stealth funzionano così) {#how-math}
+
+Gli indirizzi stealth 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* verrà utilizzata per spendere denaro dall'indirizzo stealth, 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 anche potuto inviarla ad Alice, ma supponiamo che Carol stia ascoltando).
+
+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 tutte le risorse che desidera. In futuro, se Alice vince, Bill può dirle *Rpriv* per dimostrare che le risorse provenivano 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 permette di accedere agli asset nell'indirizzo risultante 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 per la Campagna di Dominio del Mondo di Dave. Alice è disposta a far conoscere a Dave gli indirizzi pubblici e a farsi informare quando c'è più denaro disponibile, ma non vuole che lui spenda i soldi della sua campagna.
+
+Poiché la visualizzazione e la spesa utilizzano chiavi separate, Alice può dare a Dave *Vpriv*. Quindi 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 conosciuti dai diversi partecipanti.
+
+| Alice | Pubblicato | 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)* |
+| *Address=f(Ppub)* | - | *Address=f(Ppub)* | *Address=f(Ppub)* | *Address=f(Ppub)*
+| *Ppriv = Kpriv+hash(S)* | - | - | - |
+
+## Quando gli indirizzi stealth falliscono {#go-wrong}
+
+*Non ci sono segreti sulla blockchain*. Sebbene gli indirizzi stealth possano fornirti 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 stealth, ma è molto 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 dimostrarlo, ma è probabile che Bill abbia appena donato alla campagna di Alice. Carol lo penserebbe sicuramente.
+
+È facile per Bill separare la pubblicazione di *Rpub* dal finanziamento dell'indirizzo stealth (farli in momenti diversi, da indirizzi diversi). Tuttavia, questo è insufficiente. Il modello che Carol cerca è che Bill finanzi un indirizzo, e poi il fondo della campagna di Alice prelevi da esso.
+
+Una soluzione è che la campagna di Alice non prelevi i soldi direttamente, ma li usi per pagare una terza parte. Se la campagna di Alice invia 10 ETH ai Servizi per la Campagna di Dominio del Mondo di Dave, Carol sa solo che Bill ha donato a uno dei clienti di Dave. Se Dave ha abbastanza clienti, Carol non sarebbe in grado di sapere se Bill ha donato ad Alice, che compete con lei, o ad Adam, Albert o Abigail, di cui a Carol non importa nulla. Alice può includere un valore hash con il pagamento, e poi fornire a Dave la preimmagine, per dimostrare che si trattava della sua donazione. In alternativa, come notato sopra, se Alice dà a Dave la sua *Vpriv*, lui sa già da chi proveniva il pagamento.
+
+Il problema principale di questa soluzione è che richiede ad Alice di preoccuparsi della segretezza quando tale segretezza va a vantaggio di Bill. Alice potrebbe voler mantenere la sua reputazione in modo che anche l'amico di Bill, Bob, le faccia una donazione. Ma è anche possibile che non le dispiaccia esporre Bill, perché allora lui avrà paura di cosa succederà se Carol vince. Bill potrebbe finire per fornire ad Alice ancora più supporto.
+
+### Usare più livelli stealth {#multi-layer}
+
+Invece di fare affidamento su Alice per preservare la privacy di Bill, Bill può farlo da solo. Può generare più meta-indirizzi per persone fittizie, Bob e Bella. Bill invia quindi 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-a-Bob-a-Bella-ad-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 stealth al suo indirizzo noto della campagna.
+
+## Scrivere un'applicazione per indirizzi stealth {#write-app}
+
+Questo articolo spiega un'applicazione per indirizzi stealth [disponibile su GitHub](https://github.com/qbzzt/251022-stealth-addresses.git).
+
+### Strumenti {#tools}
+
+C'è [una libreria typescript per indirizzi stealth](https://github.com/ScopeLift/stealth-address-sdk) che potremmo usare. Tuttavia, le operazioni crittografiche possono essere intensive per la CPU. Preferisco implementarle 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 hai familiarità con essi, puoi usare [questo tutorial](/developers/tutorials/creating-a-wagmi-ui-for-your-contract/). Per usare Vite, abbiamo bisogno di Node.
+
+### Vedere gli indirizzi stealth 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 il repository 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; si trovano sulla stessa pagina solo per comodità.
+
+6. Come Alice, fai clic su **Generate a Stealth Meta-Address** (Genera un meta-indirizzo stealth). Questo mostrerà il nuovo indirizzo stealth e le chiavi private corrispondenti. Copia il meta-indirizzo stealth negli appunti.
+
+7. Come Bill, incolla il nuovo meta-indirizzo stealth e fai clic su **Generate an address** (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 "Private key for address generated by Bill" (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 viene compilato 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 delle dipendenze, 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/) ha bisogno di generare valori casuali. Questo 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 vero e proprio.
+
+```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 utilizza tipicamente [array](https://doc.rust-lang.org/std/primitive.array.html) di byte (`[u8; ]`) per i valori. Ma in JavaScript, utilizziamo 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 della [tupla](https://doc.rust-lang.org/std/primitive.tuple.html) ci permette di separare nuovamente quei 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 di come Rust gestisce array e vettori.
+
+L'espressione `` è chiamata [generico](https://doc.rust-lang.org/book/ch10-01-syntax.html). `N` è un parametro che controlla la lunghezza dell'array restituito. La funzione si chiama in realtà `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 pattern tipico in Rust per le funzioni che potrebbero 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 positivo (`Ok(value)`) o un errore (`Err(error)`).
+
+Il metodo `.ok()` trasforma il `Result` in un `Option`, il cui valore è il valore `Ok()` se ha 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 un `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 vengano gestiti, in un modo o nell'altro.
+
+```rust
+ if vec.len() != N { return None; }
+```
+
+Se il numero di byte non è corretto, si tratta di 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 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 l'uso della 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 stealth, la chiave pubblica da pubblicare (*Rpub*) e un valore di scansione di un byte che accelera l'identificazione di quali indirizzi pubblicati potrebbero 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 la funzione [`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 (*Address=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 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 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 un'analisi dello stack (stack trace). Quindi dai a Bill il meta-indirizzo valido e dai ad Alice un indirizzo non valido o una chiave pubblica non valida. 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 un'analisi 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 conoscerli usando [questo tutorial](/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 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 quegli 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/), crea due file che usiamo qui: un file wasm con il codice vero e proprio (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('Error loading wasm:', err)
+ alert("Wasm error: " + err)
+ }
+ }
+
+ loadWasm()
+ }, []
+ )
+```
+
+L'[`hook useEffect`](https://react.dev/reference/react/useEffect) ti permette 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 solo una volta al caricamento della pagina.
+
+La funzione dell'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 [`async`](https://en.wikipedia.org/wiki/Async/await) interna e la eseguiamo senza un `await`.
+
+**`Bill.jsx`**
+
+Questa è l'interfaccia utente per Bill. Ha una singola azione, creare un indirizzo basato sul meta-indirizzo stealth 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
+