From e97deee77fb7c78218a2b1b0dec81add2d9759e1 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Thu, 12 Feb 2026 18:31:02 +0000 Subject: [PATCH 1/3] translations: Italian part 04/13 - roadmap & staking Split from #17198. Contains 25 files. --- .../it/roadmap/account-abstraction/index.md | 113 ++----- .../it/roadmap/beacon-chain/index.md | 33 +- .../it/roadmap/danksharding/index.md | 44 ++- .../translations/it/roadmap/dencun/index.md | 4 +- .../translations/it/roadmap/fusaka/index.md | 299 ++++++++++++++++++ .../it/roadmap/fusaka/peerdas/index.md | 88 ++++++ .../it/roadmap/future-proofing/index.md | 41 ++- .../translations/it/roadmap/merge/index.md | 92 +++--- .../it/roadmap/merge/issuance/index.md | 108 +++---- .../translations/it/roadmap/pbs/index.md | 27 +- .../it/roadmap/pectra/7702/index.md | 149 +++++++++ .../translations/it/roadmap/pectra/index.md | 127 ++++++++ .../it/roadmap/pectra/maxeb/index.md | 204 ++++++++++++ .../translations/it/roadmap/scaling/index.md | 24 +- .../roadmap/secret-leader-election/index.md | 16 +- .../translations/it/roadmap/security/index.md | 40 +-- .../it/roadmap/single-slot-finality/index.md | 36 +-- .../it/roadmap/statelessness/index.md | 38 +-- .../it/roadmap/user-experience/index.md | 20 +- .../it/roadmap/verkle-trees/index.md | 27 +- .../translations/it/staking/dvt/index.md | 42 +-- .../translations/it/staking/pools/index.md | 34 +- .../translations/it/staking/saas/index.md | 30 +- .../translations/it/staking/solo/index.md | 119 +++---- .../it/staking/withdrawals/index.md | 91 +++--- 25 files changed, 1329 insertions(+), 517 deletions(-) create mode 100644 public/content/translations/it/roadmap/fusaka/index.md create mode 100644 public/content/translations/it/roadmap/fusaka/peerdas/index.md create mode 100644 public/content/translations/it/roadmap/pectra/7702/index.md create mode 100644 public/content/translations/it/roadmap/pectra/index.md create mode 100644 public/content/translations/it/roadmap/pectra/maxeb/index.md diff --git a/public/content/translations/it/roadmap/account-abstraction/index.md b/public/content/translations/it/roadmap/account-abstraction/index.md index 8695d3cd058..7048bd0f4a6 100644 --- a/public/content/translations/it/roadmap/account-abstraction/index.md +++ b/public/content/translations/it/roadmap/account-abstraction/index.md @@ -1,6 +1,6 @@ --- -title: Astrazione account -description: Una panoramica dei piani di Ethereum per rendere i conti degli utenti più semplici e sicuri +title: Astrazione dell'account +description: "Una panoramica dei piani di Ethereum per rendere i conti degli utenti più semplici e sicuri" lang: it summaryPoints: - L'astrazione del conto semplifica molto la creazione di portafogli di contratti intelligenti @@ -8,11 +8,11 @@ summaryPoints: - Le chiavi perdute o esposte sono recuperabili utilizzando svariati backup --- -# Astrazione account {#account-abstraction} +# Astrazione del conto {#account-abstraction} -Gli utenti interagiscono con Ethereum utilizzando i **[conti posseduti esternamente (EOA)](/glossary/#eoa)**. Questo è il solo modo per avviare una transazione o per eseguire un contratto intelligente. Ciò limita il modo in cui gli utenti possono interagire con Ethereum. Ad esempio, rende difficile eseguire transazioni in massa e richiede agli utenti di mantenere sempre un saldo di ETH per coprire i costi del gas. +La maggior parte degli utenti esistenti interagisce con Ethereum usando **[conti di proprietà esterna (EOA)](/glossary/#eoa)**. Ciò limita il modo in cui gli utenti possono interagire con Ethereum. Ad esempio, rende difficile eseguire lotti di transazioni e richiede agli utenti di mantenere sempre un saldo in ETH per pagare le commissioni sulle transazioni. -L'astrazione del conto è un modo per risolvere tali problemi, consentendo agli utenti di programmare flessibilmente maggiore sicurezza e una migliore esperienza degli utenti, nei propri conti. Ciò può verificarsi [aggiornando gli EOA](https://eips.ethereum.org/EIPS/eip-3074) così che possano essere controllati da contratti intelligenti, o [aggiornando i contratti intelligenti](https://eips.ethereum.org/EIPS/eip-2938), così che possano avviare transazioni. Queste opzioni richiedono entrambe modifiche al protocollo di Ethereum. Esiste un terzo percorso che comporta l'aggiunta di un [secondo sistema separato di transazioni](https://eips.ethereum.org/EIPS/eip-4337) da eseguire in parallelo al protocollo esistente. Indipendentemente dal percorso, il risultato è l'accesso a Ethereum tramite i portafogli di contratti intelligenti, supportati nativamente come parte del protocollo esistente o tramite una rete di transazioni aggiuntiva. +L'astrazione del conto è un modo per risolvere tali problemi, consentendo agli utenti di programmare flessibilmente maggiore sicurezza e una migliore esperienza degli utenti, nei propri conti. Ciò può accadere [aggiornando gli EOA](https://eips.ethereum.org/EIPS/eip-7702) (EIP-7702) in modo che possano essere controllati da smart contract. Esiste anche un'altra via che prevede l'aggiunta di un [secondo sistema di transazioni separato](https://eips.ethereum.org/EIPS/eip-4337) (EIP-4337) da eseguire in parallelo al protocollo esistente. Indipendentemente dal percorso, il risultato è l'accesso a Ethereum tramite i portafogli di contratti intelligenti, supportati nativamente come parte del protocollo esistente o tramite una rete di transazioni aggiuntiva. I portafogli di contratti intelligenti sbloccano molti benefici per l'utente, tra cui: @@ -20,107 +20,52 @@ I portafogli di contratti intelligenti sbloccano molti benefici per l'utente, tr - recuperare il proprio conto in caso di perdita delle chiavi - condividere la sicurezza del proprio conto tra svariati dispositivi o individui - pagare il gas altrui, o far pagare il proprio a qualcun altro -- raggruppare le transazioni (es. approvare ed eseguire uno scambio in una sola volta) +- raggruppare le transazioni (ad es., approvare ed eseguire uno swap in una sola volta) - incrementare le opportunità per gli svilupptori di dapp e portafogli, per innovare l'esperienza degli utenti -Tali benefici non sono oggi supportati nativamente, poiché soltanto gli account posseduti esternamente ([EOA](/glossary/#eoa)) possono avviare le transazioni. Gli EOA sono semplicemente coppie di chiavi pubblica-privata. Funzionano come segue: +Questi vantaggi non sono supportati in modo nativo oggi perché solo i conti di proprietà esterna ([EOA](/glossary/#eoa)) possono avviare le transazioni. Gli EOA sono semplicemente coppie di chiavi pubblica-privata. Funzionano come segue: -- se hai la chiave privata puoi fare _qualsiasi cosa_ entro le regole della Macchina Virtuale di Ethereum (EVM) -- se non hai la chiave privata non puoi fare _nulla_. +- se hai la chiave privata puoi fare _qualsiasi cosa_ entro le regole della macchina virtuale di Ethereum (EVM) +- se non hai la chiave privata, non puoi fare _niente_. Se perdi le tue chiavi non sono recuperabili e le chiavi rubate danno ai ladri l'accesso istantaneo a tutti i fondi in un conto. -I portafogli di contratti intelligenti sono la soluzione a tali problemi, ma a oggi sono difficili da programmare poiché, alla fine, qualsiasi logica che implementano dev'essere tradotta in una serie di transazioni dell'EOA, prima che possa essere elaborata da Ethereum. L'astrazione del conto consente ai contratti intelligenti di avviare da soli le transazioni, così che qualsiasi logica che l'utente desideri implementare possa essere programmata nel portafoglio del contratto intelligente stesso ed eseguita su Ethereum. +I portafogli smart contract sono la soluzione a questi problemi, ma oggi sono difficili da programmare perché alla fine, qualsiasi logica implementata deve essere tradotta in una serie di transazioni EOA prima di poter essere elaborata da Ethereum. L'astrazione del conto consente ai contratti intelligenti di avviare da soli le transazioni, così che qualsiasi logica che l'utente desideri implementare possa essere programmata nel portafoglio del contratto intelligente stesso ed eseguita su Ethereum. -Infine, l'astrazione del conto migliora il supporto ai portafogli di contratti intelligenti, semplificandone la creazione e aumentandone la sicurezza di utilizzo. Infine, con l'astrazione del conto, gli utenti possono godere di tutti i benefici di Ethereum, senza conoscere o interessarsi della tecnologia sottostante. +Infine, l'astrazione del conto migliora il supporto ai portafogli di contratti intelligenti, semplificandone la creazione e aumentandone la sicurezza di utilizzo. Con l'astrazione del conto, gli utenti possono godere di tutti i vantaggi di Ethereum senza dover comprendere la tecnologia sottostante. -## Oltre le frasi di seed {#beyond-seed-phrases} +## Oltre le frasi seed {#beyond-seed-phrases} -I conti odierni sono protetti utilizzando chiavi private, calcolate dalle frasi di seed. Chiunque abbia accesso a una frase di seed può scoprire facilmente la chiave privata che protegge un conto e ottenere accesso a tutte le risorse che protegge. Se una chiave privata e una frase di seed sono perdute, non sono mai recuperabili e le risorse che controllano sono congelate per sempre. Proteggere queste frasi di seed è alquanto bizzarro, persino per gli utenti esperti e il phishing delle frasi di seed è uno dei metodi più comuni per truffare gli utenti. +I conti odierni sono protetti utilizzando chiavi private, calcolate dalle frasi di seed. Chiunque abbia accesso a una frase seed può facilmente scoprire la chiave privata che protegge un account e ottenere l'accesso a tutti gli asset che questo protegge. Se una chiave privata e una frase seed vengono perse, gli asset sono permanentemente inaccessibili. La protezione di queste frasi seed è difficile, anche per gli utenti esperti, e il phishing delle frasi seed è una delle truffe più comuni. -L'astrazione del conto risolverà tale problema, utilizzando un contratto intelligente per detenere le risorse e autorizzare le transazioni. Questi contratti intelligenti sono quindi decorabili con logica personalizzata, per renderli il più sicuri e su misura possibile per l'utente. Infine, utilizzi ancora le chiavi private per controllare l'accesso al tuo conto, ma con reti di sicurezza che le rendono più facili e sicure da gestire. +L'astrazione del conto risolve questo problema utilizzando uno smart contract per detenere gli asset e autorizzare le transazioni. Gli smart contract possono includere una logica personalizzata, creata su misura per ottenere la massima sicurezza e usabilità. Gli utenti utilizzano ancora le chiavi private per controllare l'accesso, ma con misure di sicurezza avanzate. -Ad esempio, le chiavi di backup possono essere aggiunte a un portafoglio, così che se perdi o esponi accidentalmente la tua chiave principale, può essere sostituita da una nuova e sicura, con l'autorizzazione dalle chiavi di backup. Potresti proteggere ognuna di queste chiavi in un modo differente, o dividerle tra guardiani fidati. Questo rende molto più difficile, per un ladro, ottenere il pieno controllo sui tuoi fondi. Similmente, puoi aggiungere regole al portafoglio per ridurre l'impatto in caso di compromissione delle tue chiavi principali, ad esempio, potresti consentire la verifica delle transazioni di basso valore tramite un'unica firma, richiedendo invece l'approvazione di più firmatari autenticati per le transazoni di valore maggiore. Esistono anche altri modi in cui i portafogli di contratti intelligenti possono aiutarti a contrastare i ladri, ad esempio si può utilizzare una lista di autorizzazione per bloccare ogni transazione a meno che non provenga da un indirizzo attendibile, o sia verificata da svariate delle tue chiavi pre-approvate. - -### Esempi di logica di sicurezza possono essere integrati in un portafoglio del contratto intelligente: - -- **Autorizzazione multifirma**: Puoi condividere le credenziali di autorizzazione tra svariate persone o dispositivi affidabili. Quindi, il contratto, è configurabile affinché le transazioni di più di un dato valore predeterminato, richiedano l'autorizzazione da una certa porzione (ad esempio, 3/5) delle parti fidate. Ad esempio, le transazioni dal valore elevato potrebbero richiedere l'approvazione sia da un dispositivo mobile che da un portafoglio hardware, o le firme dai conti distribuiti ai membri familiari fidati. -- **Congelamento del conto**: Se un dispositivo è perduto o compromesso, il conto può essere bloccato da un altro dispositivo autorizzato, proteggendo le risorse dell'utente. -- **Recupero del conto**: Hai perso un dispositivo o hai dimenticato una password? Nel paradigma corrente, ciò significa che le tue risorse potrebbero essere state congelate per sempre. Con un portafoglio di contratti intelligenti puoi configurare un elenco di conti che possono autorizzare nuovi dispositivi e ripristinare l'accesso. -- **Imposta i limiti di transazione**: specifica le soglie giornaliere per quanto valore sia trasferibile dal conto in un giorno/una settimana/un mese. Ciò significa che, se un utente malevolo ottiene l'accesso al tuo conto, non può prelevare tutto in una volta e hai l'opportunità di congelare e ripristinare l'accesso. -- **Crea elenchi di autorizzazione**: consenti soltanto le transazioni verso certi indirizzi che sai essere sicuri. Ciò significa che _anche se_ la tua chiave privata è stata rubata, l'utente malevolo potrebbe inviare fondi soltanto ai conti di destinazione presenti nel tuo elenco. Questi elenchi di autorizzazione richiederebbero più firme per essere modificati, così che un utente malevolo non possa aggiungervi il proprio indirizzo senza avere accesso a svariate delle tue chiavi di backup. +Ad esempio, è possibile aggiungere chiavi di backup a un portafoglio, consentendo la sostituzione della chiave qualora la chiave principale venga compromessa. Ogni chiave può essere protetta in modo diverso o distribuita tra persone di fiducia, aumentando notevolmente la sicurezza. Regole aggiuntive del portafoglio possono mitigare i danni derivanti dall'esposizione della chiave, come richiedere firme multiple per transazioni di valore elevato o limitare le transazioni a indirizzi fidati. ## Migliore esperienza utente {#better-user-experience} -L'astrazione del conto consente un'**esperienza dell'utente complessiva migliore**, nonché **maggiore sicurezza**, poiché aggiunge supporto ai portafogli di contratti intelligenti, a livello del protocollo. Il motivo più importante per questo è che fornirà agli sviluppatori di contratti intelligenti, portafogli e applicazioni, molta più libertà di innovare l'esperienza degli utenti, in modi che potrebbero ancora non essere capaci di anticipare. Alcuni miglioramenti ovvi che proverrebbero dall'astrazione del conto, includono il raggruppamento delle transazioni, per velocità ed efficienza. Ad esempio, un semplice scambio dovrebbe essere un'operazione da un click, ma oggi richiede la firma di più transazioni per approvare la spesa di singoli token prima dell'esecuzione dello scambio. L'astrazione del conto rimuove quella frizione, consentendo il raggruppamento delle transazioni. Inoltre, le transazioni raggruppate potrebbero approvare precisamente il valore corretto di token necessari per ogni transazione, per poi revocare le approvazioni al suo completamento, fornendo maggiore sicurezza. - -La gestione del gas, inoltre, è di molto migliorata con l'astrazione del conto. Non solo le applicazioni possono offrire di pagare le commissioni sul gas degli utenti ma, queste, possono essere pagate in token differenti da ETH, liberando gli utenti dal dover mantenere un saldo di ETH per finanziare le transazioni. Ciò potrebbe funzionare scambiando i token dell'utente per ETH nel contratto, quindi, utilizzando gli ETH per pagare il gas. - - - -La gestione del gas è una delle frizioni principali per gli utenti di Ethereum, principalmente perché gli ETH sono la sola risorsa utilizzabile per pagare le transazioni. Immagina di avere un portafoglio con un saldo di USDC, ma nessun ETH. Non puoi spostare o scambiare quei token USDC, poiché non puoi pagare il gas. Non puoi nemmeno scambiare gli USDC per ETH, poiché anche questo costa del gas. Dovresti inviare altri ETH al tuo conto da una piattaforma di scambio o da un altro indirizzo per risolvere il problema. Con i portafogli di contratti intelligenti, invece, puoi semplicemente pagare il gas in USDC, liberando il tuo conto. Non devi più mantenere un saldo di ETH in tutti i tuoi conti. - -L'astrazione del conto, inoltre, consente agli sviluppatori di dapp di essere creativi con la gestione del gas. Ad esempio, potresti riuscire a iniziare a pagare una commissione fissa mensile alla tua DEX preferita, per delle transazioni illimitate. Le Dapp potrebbero offrire di pagare tutte le tue commissioni di gas per conto tuo, come ricompensa per aver utilizzato la loro piattaforma, o come offerta di inserimento. Per gli sviluppatori, sarebbe molto più facile innovare sul gas, quando i portafogli di contratti intelligenti sono supportati al livello del protocollo. +L'astrazione del conto migliora notevolmente l'esperienza utente e la sicurezza supportando i portafogli smart contract a livello di protocollo. Gli sviluppatori possono innovare liberamente, migliorando il raggruppamento delle transazioni per ottenere maggiore velocità ed efficienza. I semplici swap possono diventare operazioni da un clic, migliorando notevolmente la facilità d'uso. - - -Le sessioni fidate, inoltre, sono potenzialmente trasformative per le esperienze degli utenti, specialmente per applicazioni come il gaming, in cui grandi numeri di piccole transazioni, potrebbero necessitare dell'approvazione in un breve tempo. Approvare individualmente ogni transazione spezzerebbe l'esperienza di gioco, ma l'approvazione permanente non è sicura. Il portafoglio di un contratto intelligente potrebbe approvare certe transazioni per un dato tempo, fino a un valore specifico o solo per certi indirizzi. - -Inoltre, è interessante considerare come gli acquisti potrebbero cambiare, con l'astrazione del conto. Oggi, ogni transazione dev'essere approvata ed eseguita da un portafoglio pre-finanziato con un importo sufficiente del token corretto. Con l'astrazione del conto, l'esperienza potrebbe somigliare di più allo shopping online di famiglia, in cui un utente potrebbe riempire un "carrello" di oggetti e cliccare una volta per acquistare tutto insieme, con tutta la logica necessaria gestita dal contratto, non dall'utente. - -Esistono solo alcuni esempi di come le esperienze degli utenti potrebbero essere migliorate dall'astrazione del conto, ma ne esisteranno molti altri, che non abbiamo ancora immaginato. L'astrazione del conto libera gli sviluppatori dai vincoli dei EOA dei giorni nostri, consente loro di portare i migliori aspetti del web2 al web3 senza sacrificare la custodia personale e di incidere creativamente sull'inventiva di nuove esperienze degli utenti. +La gestione del gas migliora notevolmente. Le applicazioni possono pagare le commissioni sul gas degli utenti o consentire il pagamento in token diversi da ETH, eliminando la necessità di mantenere un saldo in ETH. ## Come sarà implementata l'astrazione del conto? {#how-will-aa-be-implemented} -I portafogli di contratti intelligenti, ad oggi, esistono, ma implementarli è impegnativo poiché l'EVM non li supporta. Invece, si affidano all'avvolgimento di codice relativamente complesso, intorno alle transazioni standard di Ethereum. Ethereum può modificare tale procedimento, consentendo ai contratti intelligenti di avviare le transazioni, gestendo la logica necessaria nei contratti intelligenti di Ethereum, invece che al di fuori della catena. Inoltre, inserire la logica nei contratti intelligenti, incrementa la decentralizzazione di Ethereum, poiché rimuove il bisogno di "staffettisti" operati dagli sviluppatori dei portafogli, di tradurre i messaggi firmati dall'utente, in transazioni regolari di Ethereum. - - - -EIP-2771 introduce il concetto delle meta-transazioni, che consentono a terze parti di pagare i costi del gas degli utenti senza apportare modifiche al protocollo di Ethereum. L'idea è che le transazioni firmate da un utente sono inviate a un contratto `Corriere`. Il corriere è un'entità fidata che verifica che le transazioni siano valide, prima di inviarle a un ripetitore di gas. Ciò avviene all'esterno della catena, evitando il bisogno di pagare il gas. Il ripetitore di gas passa la transazione a un contratto `Destinatario`, pagando il gas necessario per rendere la transazione eseguibile su Ethereum. La transazione è eseguita se il `Corriere` è noto ed è ritenuto attendibile dal `Destinatario`. Questo modello semplifica, per gli sviluppatori, l'implementazione di transazioni a gas zero per gli utenti. - - - - - -L'EIP-4337 è il primo passo verso il supporto dei portafogli di contratti intelligenti nativi in modo decentralizzato, senza richiedere modifiche al protocollo di Ethereum. Invece di modificare il livello del consenso per supportare i portafogli di contratti intelligenti, un nuovo sistema è aggiunto separatamente al normale protocollo di gossip della transazione. Questo sistema di livello superiore si basa su un nuovo oggetto, detto UserOperation, che impacchetta le azioni da un utente, insieme alle firme rilevanti. Questi oggetti UserOperation, quindi, sono trasmessi in un mempool dedicato, dove i validatori possono raccoglierli in una "transazione raggruppata". La transazione raggruppata rappresenta una sequenza di molti UserOperations singoli e può essere inclusa nei blocchi di Ethereum, proprio come una normale transazione, che sarà raccolta dai validatori utilizzando un simile modello di selezione che massimizza le commissioni. - -Anche il funzionamento dei portafogli cambierà sotto EIP-4337. Invece di far reimplementare da ogni portafoglio una logica di sicurezza complessa ma comune, queste funzioni saranno affidate a un contratto del portafoglio globale, noto come "punto d'accesso". Questo, gestirebbe le operazioni come il pagamento delle commissioni e l'esecuzione del codice dell'EVM, così che gli sviluppatori di portafogli possano concentrarsi sul fornire eccellenti esperienze agli utenti. - -Nota: il contratto del punto d'accesso dell'EIP-4337, è stato distribuito alla Rete Principale di Ethereum l'1 marzo 2023. Puoi visualizzare il contratto su Etherscan. - - - - - -L'EIP-2938 mira ad aggiornare il protocollo di Ethereum introducendo un nuovo tipo di transazione, AA_TX_TYPE che include tre campi: nonce, target e data, dove nonce è un contatore di transazioni, target è l'indirizzo del contratto del punto d'accesso, e data è il bytecode dell'EVM. Per eseguire queste transazioni, devono essere aggiunte due nuove istruzioni (note come codici operativi) all'EVM: NONCE e PAYGAS. Il codice operativo NONCE traccia la sequenza della transazione e PAYGAS calcola e preleva il gas necessario per eseguire la transazione dal saldo del contratto. Queste nuove funzionalità consentono a Ethereum di supportare nativamente i portafogli di contratti intelligenti, poiché l'infrastruttura necessaria è integrata nel protocollo di Ethereum. - -Nota che l'EIP-2938 non è correntemente attiva. La community, al momento, preferisce EIP-4337 poiché non richiede modifiche al protocollo. - - - - - -L'EIP-3074 mira ad aggiornare i conti posseduti esternamente di Ethereum, consentendo loro di delegare il controllo a un contratto intelligente. Ciò significa che la logica dei contratti intelligenti potrebbe approvare le transazioni originate da un EOA. Questo consentirebbe funzionalità come la sponsorizzazione del gas e le transazioni raggruppate. Perché funzioni, devono essere aggiunti due nuovi codici operativi all'EVM: AUTH e AUTHCALL. Con l'EIP-3074, i benefici del portafoglio di un contratto intelligente sono resi disponibili senza la necessità di un contratto, invece un tipo specifico di contratto privo di stato, privo di fiducia e non ggiornabile, noto come "invocatore", gestisce le transazioni. +Attualmente, i portafogli smart contract sono difficili da implementare in quanto si basano su un codice complesso che avvolge le transazioni standard. Ethereum può cambiare questa situazione consentendo agli smart contract di avviare direttamente le transazioni, incorporando la logica negli smart contract di Ethereum anziché affidarsi a relayer esterni. -Nota che EIP-3074 non è correntemente attivo. La community, al momento, preferisce EIP-4337 poiché non richiede modifiche al protocollo. +### EIP-4337: Astrazione del conto senza modifiche al protocollo - +L'EIP-4337 abilita il supporto nativo dei portafogli smart contract senza modificare il protocollo di base di Ethereum. Introduce oggetti `UserOperation` raccolti in bundle di transazioni dai validatori, semplificando lo sviluppo di portafogli. Il contratto EntryPoint dell'EIP-4337 è stato distribuito sulla Mainnet di Ethereum il 1° marzo 2023 e ha facilitato la creazione di oltre 26 milioni di portafogli smart e 170 milioni di UserOperation. -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} -I portafogli di contratti intelligenti sono già disponibili, ma sono necessari maggiori aggiornamenti per renderli il più decentralizzati e privi di permessi possibile. EIP-4337 è una proposta matura che non richiede alcuna modifica al protocollo di Ethereum, quindi è possibile che sarà implementata rapidamente. Tuttavia, gli aggiornamenti che alterano il protocollo di Ethereum non sono correntemente in sviluppo attivo, quindi potrebbe essere necessario più tempo per distribuire queste modifiche. Inoltre, è possibile che l'astrazione del conto sia raggiunta in modo soddisfacente da EIP-4337 e non sarà necessaria alcuna modifica al protocollo. +Come parte dell'aggiornamento Pectra di Ethereum, l'EIP-7702 è previsto per il 7 maggio 2025. L'EIP-4337 è stato ampiamente adottato, [con oltre 26 milioni di smart account distribuiti e più di 170 milioni di UserOperation elaborate](https://www.bundlebear.com/erc4337-overview/all). ## Letture consigliate {#further-reading} -- [erc4337.io](https://www.erc4337.io/) -- [Discussione di gruppo sull'astrazione del conto dal Devcon Bogota](https://www.youtube.com/watch?app=desktop&v=WsZBymiyT-8) -- ["Perché l'astrazione del conto è una svolta per le dapp" da Devcon Bogota](https://www.youtube.com/watch?v=OwppworJGzs) -- ["Astrazione del conto ELI5" da Devcon Bogota](https://www.youtube.com/watch?v=QuYZWJj65AY) -- [Note di "Strada all'Astrazione del Conto" di Vitalik](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists) -- [Post del blog di Vitalik sui portafogli di recupero sociale](https://vitalik.eth.limo/general/2021/01/11/recovery.html) -- [Note sull'EIP-2938](https://hackmd.io/@SamWilsn/ryhxoGp4D#What-is-EIP-2938) -- [Documentazione sull'EIP-2938](https://eips.ethereum.org/EIPS/eip-2938) -- [Note sull'EIP-4337](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a) -- [Documentazione sull'EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) -- [Documentazione sull'EIP-2771](https://eips.ethereum.org/EIPS/eip-2771) -- ["Basi dell'Astrazione del Conto": Cos'è l'Astrazione del Conto Parte I](https://www.alchemy.com/blog/account-abstraction) +- [erc4337.io](https://docs.erc4337.io/) +- [Documentazione EIP-4337](https://eips.ethereum.org/EIPS/eip-4337) +- [Documentazione EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) +- [Dashboard di adozione ERC-4337](https://www.bundlebear.com/erc4337-overview/all) +- ["Road to Account Abstraction" di Vitalik](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists) +- [Blog di Vitalik sui portafogli a recupero sociale](https://vitalik.eth.limo/general/2021/01/11/recovery.html) +- [Awesome Account Abstraction](https://github.com/4337Mafia/awesome-account-abstraction) diff --git a/public/content/translations/it/roadmap/beacon-chain/index.md b/public/content/translations/it/roadmap/beacon-chain/index.md index fdfafae0a45..5d5e5cf8cbd 100644 --- a/public/content/translations/it/roadmap/beacon-chain/index.md +++ b/public/content/translations/it/roadmap/beacon-chain/index.md @@ -6,7 +6,7 @@ template: upgrade image: /images/upgrades/core.png alt: summaryPoint1: La Beacon Chain ha introdotto il proof-of-stake all'ecosistema di Ethereum. -summaryPoint2: Si è unita alla catena di proof-of-work originale di Ethereum a settembre 2022. +summaryPoint2: "Si è unita alla catena di proof-of-work originale di Ethereum a settembre 2022." summaryPoint3: La Beacon Chain ha introdotto la logica del consenso e il protocollo di gossip dei blocchi, che ora protegge Ethereum. --- @@ -16,34 +16,34 @@ summaryPoint3: La Beacon Chain ha introdotto la logica del consenso e il protoco ## Cos'è la Beacon Chain? {#what-is-the-beacon-chain} -Beacon Chain era il nome della blockchain di proof of stake originale, lanciata nel 2020. Fu creata per assicurare che la logica di consenso di Proof of stake fosse stabile e sostenibile prima di abilitarla sulla Rete principale di Ethereum. Di conseguenza, era eseguita insieme all'Ethereum Proof of Work originale. La Beacon Chain era una catena di blocchi 'vuoti', ma la disattivazione del proof of work e l'attivazione del proof of stake su Ethereum, hanno richiesto di istruire la Beacon Chain per accettare i dati delle transazioni dai client d'esecuzione, raggrupparli in blocchi, quindi organizzarli in una blockchain utilizzando il meccanismo di consenso basato sul proof of stake. Allo stesso momento, i client originali di Ethereum hanno disattivato il proprio mining, la propagazione dei blocchi e la logica di consenso, passando tutti questi aspetti alla Beacon Chain. Questo evento è noto come [La Fusione](/roadmap/merge/). Una volta verificatasi La Fusion, non esistevano più due blockchain. Invece, ora, esiste un singolo Ethereum di proof of stake, che richiede due client differenti per nodo. La Beacon Chain è ora il livello del consenso, una rete tra pari dei client del consenso, che gestisce il gossip dei blocchi e la logica di consenso, mentre i client originali formano il livello d'esecuzione, responsabile del gossip e dell'esecuzione delle transazioni, e della gestione dello stato di Ethereum. I due livelli possono comunicare tra loro utilizzando l'Engine API. +Beacon Chain era il nome della blockchain di proof of stake originale, lanciata nel 2020. Fu creata per assicurare che la logica di consenso di Proof of stake fosse stabile e sostenibile prima di abilitarla sulla Rete principale di Ethereum. Di conseguenza, era eseguita insieme all'Ethereum Proof of Work originale. La Beacon Chain era una catena di blocchi 'vuoti', ma la disattivazione del proof of work e l'attivazione del proof of stake su Ethereum, hanno richiesto di istruire la Beacon Chain per accettare i dati delle transazioni dai client d'esecuzione, raggrupparli in blocchi, quindi organizzarli in una blockchain utilizzando il meccanismo di consenso basato sul proof of stake. Allo stesso momento, i client originali di Ethereum hanno disattivato il proprio mining, la propagazione dei blocchi e la logica di consenso, passando tutti questi aspetti alla Beacon Chain. Questo evento era noto come [La Fusione](/roadmap/merge/). Una volta verificatasi La Fusion, non esistevano più due blockchain. Invece, ora, esiste un singolo Ethereum di proof of stake, che richiede due client differenti per nodo. La Beacon Chain è ora il livello del consenso, una rete tra pari dei client del consenso, che gestisce il gossip dei blocchi e la logica di consenso, mentre i client originali formano il livello d'esecuzione, responsabile del gossip e dell'esecuzione delle transazioni, e della gestione dello stato di Ethereum. I due livelli possono comunicare tra loro utilizzando l'Engine API. ## Cosa fa la beacon chain? {#what-does-the-beacon-chain-do} -Beacon Chain è il nome dato a un libro mastro di conti che hanno condotto e coordinato la rete di [staker](/staking/) di Ethereum, prima che questi iniziassero a convalidare i blocchi reali di Ethereum. Però, essa non elabora le transazioni o gestisce le interazioni con i contratti intelligenti, poiché ciò è effettuato nel livello d'esecuzione. La Beacon Chain è responsabile di cose come la gestione dei blocchi e delle attestazioni, l'esecuzione dell'algoritmo di scelta della biforcazione e la gestione di ricompense e sanzioni. Leggi di più sulla nostra [pagina sull'architettura dei nodi](/developers/docs/nodes-and-clients/node-architecture/#node-comparison). +Beacon Chain è il nome dato a un libro mastro di conti che hanno condotto e coordinato la rete di staker di Ethereum, prima che questi iniziassero a convalidare i blocchi reali di Ethereum. Però, essa non elabora le transazioni o gestisce le interazioni con i contratti intelligenti, poiché ciò è effettuato nel livello d'esecuzione. +La Beacon Chain è responsabile di cose come la gestione dei blocchi e delle attestazioni, l'esecuzione dell'algoritmo di scelta della biforcazione e la gestione di ricompense e sanzioni. +Leggi di più sulla nostra [pagina sull'architettura dei nodi](/developers/docs/nodes-and-clients/node-architecture/#node-comparison). ## Impatto della Beacon Chain {#beacon-chain-features} ### Introduzione allo staking {#introducing-staking} -La Beacon Chain ha introdotto la [proof of stake](/developers/docs/consensus-mechanisms/pos/) in Ethereum. Questo mantiene sicura Ethereum e consente ai validatori di guadagnare più ETH nel processo. In pratica, lo staking prevede di puntare ETH per poter attivare il software del validatore. Come staker, esegui il software che crea e convalida i nuovi blocchi nella catena. +La Beacon Chain ha introdotto il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) in Ethereum. Questo mantiene sicura Ethereum e consente ai validatori di guadagnare più ETH nel processo. In pratica, lo staking prevede di puntare ETH per poter attivare il software del validatore. Come staker, esegui il software che crea e convalida i nuovi blocchi nella catena. Lo staking ha un ruolo simile a quello che aveva il [mining](/developers/docs/consensus-mechanisms/pow/mining/), ma è differente in molti modi. Il mining richiedeva ingenti spese iniziali sotto forma di hardware potente e consumi energetici, risultando in economie di scala e promuovendo la centralizzazione. Il mining, inoltre, non prevedeva alcun requisito di bloccare le risorse come garanzie, limitando la capacità del protocollo di punire gli utenti malevoli dopo un attacco. La transizione al proof of stake ha reso Ethereum significativamente più sicura e decentralizzata rispetto al proof of work. Più persone parteciperanno alla rete, più questa diventerà decentralizzata e protetta dagli attacchi. -E l'utilizzo del proof of stake come meccanismo di consenso è un componente fondamentale per [l'Ethereum sicuro, ecosostenibile e scalabile che conosciamo ora](/roadmap/vision/). - - Se sei interessato a diventare un validatore e contribuire a proteggere Ethereum, [scopri di più sullo staking](/staking/). + Se sei interessato a diventare un validatore e a contribuire a proteggere Ethereum, [scopri di più sullo staking](/staking/). -### Prepararsi allo sharding {#setting-up-for-sharding} +### Preparazione per la frammentazione {#setting-up-for-sharding} Da quando la Beacon Chain si è fusa con la Rete principale originale di Ethereum, la community di Ethereum ha iniziato a cercare di ridimensionare la rete. @@ -51,30 +51,29 @@ Il proof of stake ha il vantaggio di avere un registro di tutti i produttori di Questa responsabilità è in contrasto con il proof of work, in cui i miner non hanno obblighi verso la rete e potrebbero interrompere il mining e disattivare permanentemente il loro software del nodo in un istante, senza ripercussioni. Inoltre, non esiste alcun registro di propositori di blocchi noti e nessun modo affidabile per ripartire le responsabilità della rete in modo sicuro. -[Maggiori informazioni sullo sharding](/roadmap/danksharding/) +[Altro sulla frammentazione](/roadmap/danksharding/) ## Relazione tra gli aggiornamenti {#relationship-between-upgrades} Gli aggiornamenti di Ethereum sono tutti in qualche modo interconnessi. Quindi ricapitoliamo per vedere come la beacon chain incide sugli altri aggiornamenti. -### Beacon Chain e La Fusione {#merge-and-beacon-chain} +### La Beacon Chain e La Fusione {#merge-and-beacon-chain} Inizialmente la Beacon Chain esisteva separatamente dalla Rete principale di Ethereum, ma le due sono state fuse nel 2022. - La fusione + La Fusione -### Shard chain e beacon chain {#shards-and-beacon-chain} +### I frammenti e la Beacon Chain {#shards-and-beacon-chain} Lo sharding potrà entrare in modo sicuro nell'ecosistema Ethereum solo quando sarà presente un meccanismo di consenso proof of stake. La Beacon Chain ha introdotto lo staking, che si è 'fuso' con la Rete principale, spianando la strada allo sharding per contribuire a ridimensionare ulteriormente Ethereum. - Shard chain + Catene di frammenti -## Letture consigliate +## Ulteriori Letture -- [Maggiori informazioni sugli aggiornamenti futuri di Ethereum](/roadmap/vision) -- [Maggiori informazioni sull'architettura dei nodi](/developers/docs/nodes-and-clients/node-architecture) -- [Maggiori informazioni sul proof of stake](/developers/docs/consensus-mechanisms/pos) +- [Altro sull'architettura dei nodi](/developers/docs/nodes-and-clients/node-architecture) +- [Altro sul proof-of-stake](/developers/docs/consensus-mechanisms/pos) diff --git a/public/content/translations/it/roadmap/danksharding/index.md b/public/content/translations/it/roadmap/danksharding/index.md index 59099359eac..38971518027 100644 --- a/public/content/translations/it/roadmap/danksharding/index.md +++ b/public/content/translations/it/roadmap/danksharding/index.md @@ -11,50 +11,46 @@ summaryPoints: # Danksharding {#danksharding} -Il **Danksharding** è il metodo tramite cui Ethereum diventa una blockchain realmente scalabile ma, per arrivarci, sono necessari diversi aggiornamenti del protocollo. Il **Proto-Danksharding** è un passaggio intermedio, lungo tale percorso. Entrambi mirano a rendere le transazioni sul Livello 2 quanto più possibile economiche per gli utenti e dovrebbero ridimensionare Ethereum a >100.000 transazioni al secondo. +**Il Danksharding** è il metodo tramite cui Ethereum diventa una blockchain realmente scalabile ma, per arrivarci, sono necessari diversi aggiornamenti del protocollo. **Il Proto-Danksharding** è un passaggio intermedio lungo il percorso. Entrambi mirano a rendere le transazioni sul Livello 2 il più economiche possibile per gli utenti e dovrebbero scalare Ethereum a >100.000 transazioni al secondo. ## Cos'è il Proto-Danksharding? {#what-is-protodanksharding} -Il proto-danksharding, anche noto come [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), è un modo per i [rollup](/layer-2/#rollups) per aggiungere dati più economici ai blocchi. Il nome proviene dai due ricercatori che hanno proposto l'idea: Protolambda e Dankrad Feist. Storicamente, i rollup erano limitati nell'economicità che possono apportare alle transazioni dell'utente dal fatto che pubblicassero le proprie transazioni in `CALLDATA`. +Il Proto-Danksharding, noto anche come [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), è un modo per i [rollup](/layer-2/#rollups) di aggiungere dati più economici ai blocchi. Il nome proviene dai due ricercatori che hanno proposto l'idea: Protolambda e Dankrad Feist. Storicamente, i rollup sono stati limitati nella capacità di rendere economiche le transazioni degli utenti dal fatto che pubblicano le loro transazioni in `CALLDATA`. -Ciò è costoso perché elaborato da tutti i nodi di Ethereum e risiede per sempre sulla catena, anche se i rollup necessitano dei dati soltanto per un breve periodo di tempo. Il Proto-Danksharding introduce i blob di dati, inviabili e collegabili ai blocchi. I dati in questi blob non sono accessibili all'EVM e sono eliminati automaticamente dopo un periodo di tempo fisso (impostato a 4096 epoche al momento di scrittura, o circa 18 giorni). Ciò significa che i rollup possono inviare i propri dati in modo molto più economico, trasferendo i risparmi agli utenti finali sotto forma di transazioni più economiche. +Questo è costoso perché viene elaborato da tutti i nodi di Ethereum e rimane on-chain per sempre, anche se i rollup hanno bisogno dei dati solo per un breve periodo. Il Proto-Danksharding introduce i blob di dati, inviabili e collegabili ai blocchi. I dati in questi blob non sono accessibili all'EVM e sono eliminati automaticamente dopo un periodo di tempo fisso (impostato a 4096 epoche al momento di scrittura, o circa 18 giorni). Ciò significa che i rollup possono inviare i propri dati in modo molto più economico, trasferendo i risparmi agli utenti finali sotto forma di transazioni più economiche. -I rollup sono un metodo per scalare Ethereum raggruppando le transazioni all'esterno della catena e, in seguito, pubblicando i risultati su Ethereum. Un rollup, essenzialmente, si compone di due parti: dati e controllo dell'esecuzione. I dati sono la sequenza completa delle transazioni elaborate da un rollup per produrre il cambiamento di stato pubblicato su Ethereum. Il controllo d'esecuzione è la ri-esecuzione di tali transazioni da un utente onesto (dimostratore) per aassicurarsi che il cambiamento di stato proposto sia corretto. Per effettuare il controllo d'esecuzione, i dati della transazione devono essere disponibili per un tempo sufficiente perché chiunque possa scaricarli e controllarli. Ciò significa che qualsiasi comportamento disonesto dal sequenziatore del rollup puà essere identificato e sfidato dal dimostratore. Tuttavia, non è necessario che sia disponibile per sempre. - +I rollup sono un modo per scalare Ethereum raggruppando le transazioni off-chain per poi pubblicare i risultati su Ethereum. Un rollup, essenzialmente, si compone di due parti: dati e controllo dell'esecuzione. I dati sono la sequenza completa delle transazioni elaborate da un rollup per produrre il cambiamento di stato pubblicato su Ethereum. Il controllo d'esecuzione è la ri-esecuzione di tali transazioni da un utente onesto (dimostratore) per aassicurarsi che il cambiamento di stato proposto sia corretto. Per effettuare il controllo d'esecuzione, i dati della transazione devono essere disponibili per un tempo sufficiente perché chiunque possa scaricarli e controllarli. Ciò significa che qualsiasi comportamento disonesto dal sequenziatore del rollup puà essere identificato e sfidato dal dimostratore. Tuttavia, non è necessario che sia disponibile per sempre. - - -I rollup pubblicano gli impegni ai dati delle proprie transazioni on chain e, inoltre, rendono disponibili i dati effettivi nei blob di dati. Ciò significa che i dimostratori possono verificare che gli impegni siano validi o sfidare i dati che ritengono siano errati. Al livello del nodo, i blob di dati sono conservati nel client del consenso. I client del consenso attestano di aver visto i dati e che sono stati propagati per la rete. Se i dati fossero conservati per sempre, tali client si allargherebberò, determinando grandi requisiti hardware per l'esecuzione di nodi. Invece, i dati sono eliminati automaticamente dal nodo ogni 18 giorni. Le attestazioni del client del consenso dimostrano che vi è stata un'opportunità sufficiente, affinché i dimostratori potessero verificare i dati. I dati effettivi possono essere memorizzati off-chain dagli operatori di rollup, dagli utenti o da terzi. + +I rollup pubblicano on-chain gli impegni relativi ai dati delle loro transazioni e rendono inoltre disponibili i dati effettivi in blob di dati. Ciò significa che i dimostratori possono verificare che gli impegni siano validi o sfidare i dati che ritengono siano errati. Al livello del nodo, i blob di dati sono conservati nel client del consenso. I client del consenso attestano di aver visto i dati e che sono stati propagati per la rete. Se i dati fossero conservati per sempre, tali client si allargherebberò, determinando grandi requisiti hardware per l'esecuzione di nodi. Invece, i dati sono eliminati automaticamente dal nodo ogni 18 giorni. Le attestazioni del client del consenso dimostrano che vi è stata un'opportunità sufficiente, affinché i dimostratori potessero verificare i dati. I dati effettivi possono essere archiviati off-chain dagli operatori dei rollup, dagli utenti o da altri. ### Come sono verificati i dati dei blob? {#how-are-blobs-verified} -I rollup pubblicano le transazioni che eseguono nei blob di dati. Inoltre, pubblicano un "impegno" ai dati. Lo fanno fissando una funzione polinomiale ai dati. Questa è valutabile su vari punti. Ad esempio, se definiamo una funzione estremamente semplice `f(x) = 2x-1`, possiamo valutarla per `x = 1`, `x = 2`, `x = 3`, che danno i risultati `1, 3, 5`. Un dimostratore applica la stessa funzione ai dati, valutandoli sugli stessi punti. Se i dati originali vengono modificati, la funzione non sarà identica e quindi i valori non sono valutati in ciascun punto. In realtà, l'impegno e la prova sono più complicati poiché sono avvolti in funzioni crittografiche. +I rollup pubblicano le transazioni che eseguono nei blob di dati. Inoltre, pubblicano un "impegno" ai dati. Lo fanno fissando una funzione polinomiale ai dati. Questa è valutabile su vari punti. Ad esempio, se definiamo una funzione estremamente semplice `f(x) = 2x-1`, possiamo valutare questa funzione per `x = 1`, `x = 2`, `x = 3` ottenendo i risultati `1, 3, 5`. Un dimostratore applica la stessa funzione ai dati, valutandoli sugli stessi punti. Se i dati originali vengono modificati, la funzione non sarà identica e quindi i valori non sono valutati in ciascun punto. In realtà, l'impegno e la prova sono più complicati poiché sono avvolti in funzioni crittografiche. ### Cos'è KZG? {#what-is-kzg} -KZG sta per Kate-Zaverucha-Goldberg, i nomi dei tre [autori originali](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11) di uno schema che riduce un blob di dati a un piccolo ["impegno" crittografico](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html). Il blob di dati inviato da un rollup dev'essere verificato per assicurarsi che il rollup si stia comportando correttamente. Ciò richiede la ri-esecuzione delle transazioni nel blob da un dimostratore per verificare che l'impegno sia valido. Questo equivale, concettualmente, al metodo con cui i client d'esecuzione verificano la validità delle transazioni di Ethereum sul livello 1 utilizzando le prove di Merkle. KZG è una prova alternativa che adatta un'equazione polinomiale ai dati. L'impegno valuta la polinomiale a determinati punti di dati segreti. Un dimostratore si adatterebbe alla stessa polinomiale sui dati, valutandola agli stessi valori e verificando che i risultati corrispondano. Questo è un modo di verifica dei dati compatibile con le tecniche di conoscenza zero utilizzate da alcuni rollup ed, eventualmente, da altre parti del protocollo di Ethereum. +KZG è l'acronimo di Kate-Zaverucha-Goldberg, i nomi dei tre [autori originali](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11) di uno schema che riduce un blob di dati a un piccolo ["impegno" crittografico](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html). Il blob di dati inviato da un rollup dev'essere verificato per assicurarsi che il rollup si stia comportando correttamente. Ciò richiede la ri-esecuzione delle transazioni nel blob da un dimostratore per verificare che l'impegno sia valido. Questo equivale, concettualmente, al metodo con cui i client d'esecuzione verificano la validità delle transazioni di Ethereum sul livello 1 utilizzando le prove di Merkle. KZG è una prova alternativa che adatta un'equazione polinomiale ai dati. L'impegno valuta la polinomiale a determinati punti di dati segreti. Un dimostratore si adatterebbe alla stessa polinomiale sui dati, valutandola agli stessi valori e verificando che i risultati corrispondano. Questo è un modo di verifica dei dati compatibile con le tecniche di conoscenza zero utilizzate da alcuni rollup ed, eventualmente, da altre parti del protocollo di Ethereum. ### Cos'è la cerimonia KZG? {#what-is-a-kzg-ceremony} -La cerimonia KZG era un metodo, per molte persone da tutta la community di Ethereum, di generare collettivamente una stringa casuale segreta di numeri, utilizzabile per verificare dei dati. È molto importante che tale stringa di numeri non sia nota e non possa essere ricreata da nessuno. Per assicurarlo, ogni partecipante alla cerimonia ha ricevuto una stringa dal partecipante precedente. Quindi, creava dei nuovi valori casuali (ad esempio, consentendo al proprio browser di misurare il movimento del proprio mouse) e li mischiava con il valore precedente. Poi, inviava il valore al partecipante successivo e lo eliminava dalla propria macchina locale. Finché una persona nella cerimonia lo faceva onestamente, il valore finale non poteva essere noto a un utente malevolo. +La cerimonia KZG era un metodo, per molte persone da tutta la community di Ethereum, di generare collettivamente una stringa casuale segreta di numeri, utilizzabile per verificare dei dati. È molto importante che tale stringa di numeri non sia nota e non possa essere ricreata da nessuno. Per assicurarlo, ogni partecipante alla cerimonia ha ricevuto una stringa dal partecipante precedente. Hanno quindi creato alcuni nuovi valori casuali (ad esempio, consentendo al browser di misurare il movimento del mouse) e li hanno mescolati con il valore precedente. Poi, inviava il valore al partecipante successivo e lo eliminava dalla propria macchina locale. Finché una persona nella cerimonia lo faceva onestamente, il valore finale non poteva essere noto a un utente malevolo. La cerimonia KZG dell'EIP-4844 era aperta al pubblico e decine di migliaia di persone hanno partecipato per aggiungere la propria entropia (casualità). In totale ci sono stati oltre 140.000 contributi, rendendola la più grande cerimonia al mondo nel suo genere. Affinché la cerimonia sia compromessa, il 100% di questi partecipanti avrebbe dovuto essere attivamente disonesto. Dalla prospettiva dei partecipanti, se sanno di essere onesti, non è necessario fidarsi di nessun altro, poiché sanno di aver protetto la cerimonia (soddisfacendo individualmente il requisito del partecipante onesto "1 di N"). - - -Quando un rollup pubblica dati in un blob, fornisce un "impegno" che viene pubblicato sulla catena. Questo, è il risultato della valutazione di un adattamento polinomiale ai dati, in certi punti. Questi punti sono definiti dai numeri casuali generati nella cerimonia KZG. I dimostratori, quindi, possono valutare la polinomiale agli stessi punti, per poter verificare i dati; se arrivano agli stessi valori, allora i dati sono corretti. + +Quando un rollup pubblica i dati in un blob, fornisce un "impegno" che pubblica on-chain. Questo, è il risultato della valutazione di un adattamento polinomiale ai dati, in certi punti. Questi punti sono definiti dai numeri casuali generati nella cerimonia KZG. I dimostratori, quindi, possono valutare la polinomiale agli stessi punti, per poter verificare i dati; se arrivano agli stessi valori, allora i dati sono corretti. -Se qualcuno conoscesse le posizioni casuali utilizzate per l'impegno, sarebbe facile, per loro, generare una nuova polinomiaale che si adatti a quei punti specifici (cioè, una "collisione"). Ciò significa che potrebbero aggiungere o rimuovere i dati dal blob e, comunque, fornire una prova valida. Per impedirlo, invece di dare ai dimostratori le posizioni segrete effettive, ricevono in realtà le posizioni, avvolte in una "scatola nera" crittografica, utilizzando le curve ellittiche. Questi, infatti, rimescolano i valori in modo tale che i valori originali non siano decodificabili, ma con dimostratori e verificatori capaci in algebra, le polinomiali sono ancora valutabili ai punti rappresentati. - +Se qualcuno conosce le posizioni casuali utilizzate per l'impegno, è facile generare un nuovo polinomio che si adatti a quei punti specifici (ossia, una "collisione"). Ciò significa che potrebbero aggiungere o rimuovere i dati dal blob e, comunque, fornire una prova valida. Per impedirlo, invece di dare ai dimostratori le posizioni segrete effettive, ricevono in realtà le posizioni, avvolte in una "scatola nera" crittografica, utilizzando le curve ellittiche. Questi, infatti, rimescolano i valori in modo tale che i valori originali non siano decodificabili, ma con dimostratori e verificatori capaci in algebra, le polinomiali sono ancora valutabili ai punti rappresentati. @@ -67,29 +63,27 @@ Il Danksharding è la piena realizzazione del ridimensionamento del rollup, avvi Funziona espandendo i blob collegati ai blocchi da sei (6) nel proto-danksharding, a 64 nel Danksharding completo. Il resto delle modifiche necessarie sono tutti gli aggiornamenti al metodo di operazione dei client del consenso, per consentire loro di gestire i nuovi, grandi blob. Svariate di queste modifiche sono già sulla tabella di marcia per altri scopi, indipendenti dal Danksharding. Ad esempio, il Danksharding richiede la separazione del propositore e del costruttore, per essere implementata. Questo è un aggiornamento che separa le mansioni di costruzione e proposta dei blocchi, tra validatori differenti. Similmente, il campionamento della disponibilità dei dati è necessario per il Danksharding, ma è anche necessario per lo sviluppo di client molto leggeri, che non memorizzano molti dati storici ("client privi di stato"). - + La separazione di propositori e costruttori è necessaria per impedire ai singoli validatori di dover generare costosi impegni e prove, per 32 MB di dati del blob. Questo metterebbe a dura prova gli staker domestici e richiederebbe loro di investire in hardware più potenti, danneggiando la decentralizzazione. Invece, i costruttori di blocchi specializzati si prendono la responsabilità di questo costoso lavoro di calcolo. Poi, mettono a disposizione i propri blocchi ai propositori di blocchi per la trasmissione. Il propositore di blocchi, semplicemente, sceglie il blocco più redditizio. Chiunque può verificare i blob in modo economico e rapido, a significare che ogni normale validatore può verificare che i costruttori di blocchi si stiano comportando onestamente. Questo permette di elaborare i blob di grandi dimensioni senza sacrificare la decentralizzazione. I costruttori di blocchi malevoli potrebbero semplicemente essere esplusi dalla rete e tagliati; altri arriverebbero al loro posto, poiché la costruzione di blocchi è un'attività redditizia. - Il campionamento della disponibilità dei dati è necessario perché i validatori verifichino in modo rapido ed efficace i dati dei blob. Utilizzando il campionmento della disponibilità dei dati, i validatori possono essere davvero certi che i blob di dati fossero disponibili e che siano stati inviati correttamente. Ogni validatore può campionare casualmente alcuni punti di dati e creare una prova, a significare che nessun validatore deve verificare l'intero blob. Se mancano dei dati, saranno identificati rapidamente e il blob sarà respinto. - -### Stato attuale {#current-progress} +### Progressi attuali {#current-progress} -Il Danksharding completo dista svariati anni. Nel mentre, la cerimonia KZG si è conclusa con oltre 140.000 contributi e l'[EIP](https://eips.ethereum.org/EIPS/eip-4844) per il Proto-Danksharding è maturata. Questa proposta è stata implementata integralmente in tutte le reti di prova, ed è stata attivata sulla Rete Principale con l'aggiornamento di rete Cancun-Deneb ("Dencun"), a marzo 2024. +Il Danksharding completo dista svariati anni. Nel frattempo, la cerimonia KZG si è conclusa con oltre 140.000 contributi e l'[EIP](https://eips.ethereum.org/EIPS/eip-4844) per il Proto-Danksharding è maturato. Questa proposta è stata implementata integralmente in tutte le reti di prova, ed è stata attivata sulla Rete Principale con l'aggiornamento di rete Cancun-Deneb ("Dencun"), a marzo 2024. ### Letture consigliate {#further-reading} - [Note sul Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _Vitalik Buterin_ - [Note di Dankrad sul Danksharding](https://notes.ethereum.org/@dankrad/new_sharding) -- [Dankrad, Proto e Vitalik discutono sul Danksharding](https://www.youtube.com/watch?v=N5p0TB77flM) +- [Dankrad, Proto e Vitalik discutono del Danksharding](https://www.youtube.com/watch?v=N5p0TB77flM) - [La cerimonia KZG](https://ceremony.ethereum.org/) -- [Il discorso di Carl Beekhuizen al Devcon sulle configurazioni attendibili](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube) -- [Maggiori informazioni sul campionamento della disponibilità dei dati per i blob](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) -- [Dankrad Feist su impegni e prove del KZG](https://youtu.be/8L2C6RDMV9Q) +- [Intervento di Carl Beekhuizen alla Devcon sulle configurazioni fidate](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube) +- [Ulteriori informazioni sul campionamento della disponibilità dei dati per i blob](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Dankrad Feist sugli impegni e le prove KZG](https://youtu.be/8L2C6RDMV9Q) - [Impegni polinomiali KZG](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) diff --git a/public/content/translations/it/roadmap/dencun/index.md b/public/content/translations/it/roadmap/dencun/index.md index 6c76b980bcc..efd900a3c85 100644 --- a/public/content/translations/it/roadmap/dencun/index.md +++ b/public/content/translations/it/roadmap/dencun/index.md @@ -68,9 +68,9 @@ Sì, il Proto-Danksharding (EIP-4844) richiede aggiornamenti sia ai client d'ese I client di consenso gestiscono il software del _Validatore_, che è stato aggiornato per gestire l'aggiornamento. -## In che modo Cancun-Deneb (Dencun) influisce su Goerli o altre reti di prova di Ethereum? {#testnet-impact} +## In che modo Cancun-Deneb (Dencun) influisce sulle reti di test di Ethereum? {#testnet-impact} -- Devnets, Goerli, Sepolia e Holesky hanno tutte subito l'aggiornamento Dencun e hanno il Proto-Danksharding perfettamente funzionante +- Le devnet, Sepolia e Holesky hanno tutte subito l'aggiornamento Dencun e hanno il Proto-Danksharding perfettamente funzionante - Gli sviluppatori di rollup possono utilizzare queste reti per testare la EIP-4844 - La maggior parte degli utenti non sarà per nulla influenzato da questa modifica a ciascuna rete di prova diff --git a/public/content/translations/it/roadmap/fusaka/index.md b/public/content/translations/it/roadmap/fusaka/index.md new file mode 100644 index 00000000000..dc7b4a642a5 --- /dev/null +++ b/public/content/translations/it/roadmap/fusaka/index.md @@ -0,0 +1,299 @@ +--- +title: Fulu-Osaka (Fusaka) +description: "Scopri di più sull'aggiornamento del protocollo Fusaka" +lang: it +--- + +# Fusaka {#fusaka} + +**L'attesissimo aggiornamento Fusaka di Ethereum è stato attivato il 3 dicembre 2025** + +L'aggiornamento della rete Fusaka segue [Pectra](/roadmap/pectra/) e introduce nuove funzionalità, migliorando l'esperienza per ogni utente e sviluppatore di Ethereum. Il nome è composto dall'aggiornamento del livello di esecuzione Osaka e dalla versione del livello di consenso che prende il nome dalla stella Fulu. Entrambe le parti di Ethereum ricevono un aggiornamento che proietta la scalabilità, la sicurezza e l'esperienza utente di Ethereum nel futuro. + + + + +L'aggiornamento Fusaka è solo un singolo passo negli obiettivi di sviluppo a lungo termine di Ethereum. Scopri di più sulla [tabella di marcia del protocollo](/roadmap/) e sugli [aggiornamenti precedenti](/ethereum-forks/). + + + + +## Miglioramenti in Fusaka {#improvements-in-fusaka} + +### Scalabilità dei blob {#scale-blobs} + +#### PeerDAS {#peerdas} + +Questa è la _novità principale_ della biforcazione Fusaka, la funzionalità più importante aggiunta in questo aggiornamento. I Layer 2 attualmente pubblicano i loro dati su Ethereum in blob, il tipo di dati effimero creato appositamente per i Layer 2. Prima di Fusaka, ogni nodo completo doveva archiviare ogni blob per garantire l'esistenza dei dati. Con l'aumento del throughput dei blob, il download di tutti questi dati diventa insostenibile in termini di risorse. + +Con il [campionamento della disponibilità dei dati](https://notes.ethereum.org/@fradamt/das-fork-choice), invece di dover archiviare tutti i dati dei blob, ogni nodo sarà responsabile di un sottoinsieme dei dati dei blob. I blob sono distribuiti in modo casuale e uniforme tra i nodi della rete, con ogni nodo completo che detiene solo 1/8 dei dati, consentendo così una scalabilità teorica fino a 8x. Per garantire la disponibilità dei dati, qualsiasi porzione dei dati può essere ricostruita da un qualsiasi 50% esistente del totale, con metodi che riducono la probabilità di dati errati o mancanti a un livello crittograficamente trascurabile (da ~uno su 1020 a uno su 1024). + +Ciò mantiene sostenibili i requisiti hardware e di larghezza di banda per i nodi, abilitando al contempo la scalabilità dei blob, con conseguente maggiore scalabilità e commissioni più basse per i Layer 2. + +[Scopri di più su PeerDAS](/roadmap/fusaka/peerdas/) + +**Risorse**: + +- [Specifica tecnica dell'EIP-7594](https://eips.ethereum.org/EIPS/eip-7594) +- [DappLion su PeerDAS: scalare Ethereum oggi | ETHSofia 2024](https://youtu.be/bONWd1x2TjQ?t=328) +- [Accademico: una documentazione del PeerDAS di Ethereum (PDF)](https://eprint.iacr.org/2024/1362.pdf) + +#### Fork solo per parametri blob {#blob-parameter-only-forks} + +I Layer 2 scalano Ethereum: man mano che le loro reti crescono, devono pubblicare più dati su Ethereum. Ciò significa che Ethereum dovrà aumentare il numero di blob a loro disposizione nel tempo. Sebbene PeerDAS consenta la scalabilità dei dati dei blob, è necessario farlo in modo graduale e sicuro. + +Poiché Ethereum è un codice in esecuzione su migliaia di nodi indipendenti che richiedono un accordo sulle stesse regole, non possiamo semplicemente introdurre modifiche come l'aumento del conteggio dei blob allo stesso modo in cui si distribuisce un aggiornamento di un sito web. Qualsiasi modifica delle regole deve essere un aggiornamento coordinato in cui ogni software di nodo, client e validatore si aggiorna prima dello stesso blocco predeterminato. + +Questi aggiornamenti coordinati generalmente includono molti cambiamenti, richiedono molti test e ciò richiede tempo. Per adattarsi più rapidamente alle mutevoli esigenze dei blob dei Layer 2, i fork solo per parametri blob introducono un meccanismo per aumentare i blob senza dover attendere il programma di aggiornamento. + +I fork solo per parametri blob possono essere impostati dai client, in modo simile ad altre configurazioni come il limite di gas. Tra i principali aggiornamenti di Ethereum, i client possono concordare di aumentare i blob `target` e `max` a, ad esempio, 9 e 12, e quindi gli operatori dei nodi si aggiorneranno per partecipare a quel piccolo fork. Questi fork solo per parametri blob possono essere configurati in qualsiasi momento. + +Quando i blob furono aggiunti per la prima volta alla rete con l'aggiornamento Dencun, il target era 3. Questo valore è stato aumentato a 6 in Pectra e, dopo Fusaka, può ora essere aumentato a un ritmo sostenibile indipendentemente da questi importanti aggiornamenti di rete. + +![Grafico che mostra il conteggio medio dei blob per blocco e l'aumento dei target con gli aggiornamenti](./average-blob-count-per-block.webp) + +Fonte del grafico: [Ethereum Blobs - @hildobby, Dune Analytics](https://dune.com/hildobby/blobs) + +**Risorse**: [Specifica tecnica dell'EIP-7892](https://eips.ethereum.org/EIPS/eip-7892) + +#### Commissione di base dei blob limitata dai costi di esecuzione {#blob-base-fee-bounded-by-execution-costs} + +I Layer 2 pagano due conti quando pubblicano i dati: la commissione del blob e il gas di esecuzione necessario per verificare tali blob. Se il gas di esecuzione domina, l'asta della commissione del blob può scendere a 1 wei e smettere di essere un segnale di prezzo. + +L'EIP-7918 fissa un prezzo di riserva proporzionale per ogni blob. Quando la riserva è superiore alla commissione di base nominale del blob, l'algoritmo di aggiustamento della commissione considera il blocco come sopra il target, smette di spingere la commissione verso il basso e le consente di aumentare normalmente. Di conseguenza: + +- il mercato delle commissioni dei blob reagisce sempre alla congestione +- i Layer 2 pagano almeno una fetta significativa del calcolo che impongono ai nodi +- i picchi della commissione di base sull'EL non possono più bloccare la commissione del blob a 1 wei + +**Risorse**: + +- [Specifica tecnica dell'EIP-7918](https://eips.ethereum.org/EIPS/eip-7918) +- [Spiegazione di Storybook](https://notes.ethereum.org/@anderselowsson/AIG) + +### Scalabilità L1 {#scale-l1} + +#### Scadenza della cronologia e ricevute più semplici {#history-expiry} + +Nel luglio 2025, i client di esecuzione di Ethereum [hanno iniziato a supportare la scadenza parziale della cronologia](https://blog.ethereum.org/2025/07/08/partial-history-exp). Questo ha eliminato la cronologia più vecchia della [Fusione (Merge)](https://ethereum.org/roadmap/merge/) per ridurre lo spazio su disco richiesto dagli operatori dei nodi man mano che Ethereum continua a crescere. + +Questo EIP si trova in una sezione separata dagli "EIP Core" perché il fork non implementa effettivamente alcuna modifica: è un avviso che i team dei client devono supportare la scadenza della cronologia entro l'aggiornamento Fusaka. In pratica, i client possono implementarlo in qualsiasi momento, ma aggiungerlo all'aggiornamento lo ha inserito concretamente nella loro lista di cose da fare e ha permesso loro di testare le modifiche di Fusaka insieme a questa funzionalità. + +**Risorse**: [Specifica tecnica dell'EIP-7642](https://eips.ethereum.org/EIPS/eip-7642) + +#### Imposta limiti superiori per MODEXP {#set-upper-bounds-for-modexp} + +Fino ad ora, la precompilazione MODEXP accettava numeri di dimensioni virtualmente qualsiasi. Ciò lo rendeva difficile da testare, facile da abusare e rischioso per la stabilità del client. L'EIP-7823 stabilisce un limite chiaro: ogni numero di input può avere una lunghezza massima di 8192 bit (1024 byte). Qualsiasi valore più grande viene rifiutato, il gas della transazione viene bruciato e non si verificano cambiamenti di stato. Copre molto comodamente le esigenze del mondo reale, eliminando i casi estremi che complicavano la pianificazione del limite di gas e le revisioni di sicurezza. Questa modifica fornisce maggiore sicurezza e protezione da attacchi DoS senza influire sull'esperienza dell'utente o dello sviluppatore. + +**Risorse**: [Specifica tecnica dell'EIP-7823](https://eips.ethereum.org/EIPS/eip-7823) + +#### Limite massimo di gas per transazione {#transaction-gas-limit-cap} + +L'EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) aggiunge un limite massimo di 16.777.216 (2^24) di gas per transazione. È un rafforzamento proattivo contro gli attacchi DoS, che limita il costo nel caso peggiore di ogni singola transazione mentre aumentiamo il limite di gas del blocco. Semplifica la modellazione della validazione e della propagazione per consentirci di affrontare la scalabilità aumentando il limite di gas. + +Perché esattamente 2^24 di gas? È comodamente più piccolo del limite di gas attuale, è abbastanza grande per le distribuzioni di contratti reali e per precompilazioni pesanti, e una potenza di 2 lo rende facile da implementare su tutti i client. Questa nuova dimensione massima della transazione è simile alla dimensione media del blocco pre-Pectra, rendendola un limite ragionevole per qualsiasi operazione su Ethereum. + +**Risorse**: [Specifica tecnica dell'EIP-7825](https://eips.ethereum.org/EIPS/eip-7825) + +#### Aumento del costo del gas di `MODEXP` {#modexp-gas-cost-increase} + +MODEXP è una funzione precompilata integrata che calcola l'esponenziazione modulare, un tipo di calcolo su numeri grandi utilizzato nella verifica delle firme RSA e nei sistemi di prova. Consente ai contratti di eseguire questi calcoli direttamente senza doverli implementare da soli. + +Sviluppatori e team dei client hanno identificato MODEXP come un ostacolo principale all'aumento del limite di gas del blocco, perché il prezzo attuale del gas spesso sottostima la potenza di calcolo richiesta da determinati input. Ciò significa che una singola transazione che utilizza MODEXP potrebbe occupare la maggior parte del tempo necessario per elaborare un intero blocco, rallentando la rete. + +Questo EIP modifica il prezzo per farlo corrispondere ai costi computazionali reali: + +- aumentando il costo minimo da 200 a 500 gas e rimuovendo lo sconto di un terzo dell'EIP-2565 dal calcolo del costo generale +- aumentando il costo in modo più marcato quando l'input dell'esponente è molto lungo. se l'esponente (il numero della "potenza" che si passa come secondo argomento) è più lungo di 32 byte / 256 bit, il costo del gas aumenta molto più velocemente per ogni byte aggiuntivo +- addebitando un extra anche per basi o moduli di grandi dimensioni. Gli altri due numeri (la base e il modulo) si presume siano di almeno 32 byte; se uno dei due è più grande, il costo aumenta in proporzione alla sua dimensione + +Abbinando meglio i costi al tempo di elaborazione effettivo, MODEXP non può più causare un tempo di validazione eccessivamente lungo per un blocco. Questa modifica è una delle tante volte a rendere sicuro l'aumento del limite di gas dei blocchi di Ethereum in futuro. + +**Risorse**: [Specifica tecnica dell'EIP-7883](https://eips.ethereum.org/EIPS/eip-7883) + +#### Limite della dimensione del blocco di esecuzione RLP {#rlp-execution-block-size-limit} + +Questo crea un tetto massimo per la dimensione di un blocco: è un limite su ciò che viene _inviato_ sulla rete ed è separato dal limite di gas, che limita il _lavoro_ all'interno di un blocco. Il limite di dimensione del blocco è di 10 MiB, con una piccola tolleranza (2 MiB) riservata ai dati di consenso, in modo che tutto si adatti e si propaghi correttamente. Se un blocco risulta più grande, i client lo rifiutano. +Ciò è necessario perché i blocchi molto grandi richiedono più tempo per diffondersi e essere verificati sulla rete e possono creare problemi di consenso o essere sfruttati come vettore di attacco DoS. Inoltre, il gossip del livello di consenso non inoltra già i blocchi superiori a ~10 MiB, quindi allineare il livello di esecuzione a tale limite evita strane situazioni in cui "alcuni lo vedono, altri lo scartano". + +In dettaglio: questo è un limite alla dimensione del blocco di esecuzione codificato in [RLP](/developers/docs/data-structures-and-encoding/rlp/). 10 MiB totali, con un margine di sicurezza di 2 MiB riservato per l'inquadramento del blocco beacon. In pratica, i client definiscono + +`MAX_BLOCK_SIZE = 10.485.760` byte e + +`SAFETY_MARGIN = 2.097.152` byte, + +e rifiutano qualsiasi blocco di esecuzione il cui payload RLP superi + +`MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN` + +L'obiettivo è limitare il tempo di propagazione/validazione nel caso peggiore e allinearsi con il comportamento del gossip del livello di consenso, riducendo il rischio di riorganizzazione/DoS senza modificare la contabilità del gas. + +**Risorse**: [Specifica tecnica dell'EIP-7934](https://eips.ethereum.org/EIPS/eip-7934) + +#### Imposta il limite di gas predefinito a 60 milioni {#set-default-gas-limit-to-60-million} + +Prima di aumentare il limite di gas da 30M a 36M nel febbraio 2025 (e successivamente a 45M), questo valore non era cambiato dalla Fusione (settembre 2022). Questo EIP mira a rendere la scalabilità coerente una priorità. + +L'EIP-7935 coordina i team dei client EL per aumentare il limite di gas predefinito sopra i 45M attuali per Fusaka. È un EIP informativo, ma chiede esplicitamente ai client di testare limiti più alti sulle devnet, convergere su un valore sicuro e includere quel numero nelle loro versioni di Fusaka. + +La pianificazione della devnet punta a uno stress di ~60M (blocchi pieni con carico sintetico) e ad aumenti iterativi; la ricerca afferma che le patologie relative alla dimensione dei blocchi nel caso peggiore non dovrebbero diventare vincolanti al di sotto di ~150M. Il rollout dovrebbe essere abbinato al limite massimo di gas per transazione (EIP-7825) in modo che nessuna singola transazione possa dominare all'aumentare dei limiti. + +**Risorse**: [Specifica tecnica dell'EIP-7935](https://eips.ethereum.org/EIPS/eip-7935) + +### Migliorare la UX {#improve-ux} + +#### Visione anticipata deterministica dei proponenti {#deterministic-proposer-lookahead} + +Con l'EIP-7917, la Beacon Chain sarà a conoscenza dei prossimi proponenti di blocchi per l'epoca successiva. Avere una visione deterministica su quali validatori proporranno i blocchi futuri può abilitare le [preconferme](https://ethresear.ch/t/based-preconfirmations/17353), un impegno con il proponente imminente che garantisce che la transazione dell'utente sarà inclusa nel suo blocco senza attendere il blocco effettivo. + +Questa funzionalità avvantaggia le implementazioni dei client e la sicurezza della rete, poiché previene casi limite in cui i validatori potrebbero manipolare il programma dei proponenti. La visione anticipata consente anche una minore complessità dell'implementazione. + +**Risorse**: [Specifica tecnica dell'EIP-7917](https://eips.ethereum.org/EIPS/eip-7917) + +#### Opcode per contare gli zeri iniziali (CLZ) {#count-leading-zeros-opcode} + +Questa funzionalità aggiunge una piccola istruzione EVM, **il conteggio degli zeri iniziali (CLZ)**. Quasi tutto nell'EVM è rappresentato come un valore a 256 bit: questo nuovo opcode restituisce quanti bit zero ci sono all'inizio. Questa è una caratteristica comune in molte architetture di set di istruzioni, in quanto consente operazioni aritmetiche più efficienti. In pratica, questo riduce le scansioni di bit fatte a mano di oggi in un unico passaggio, quindi trovare il primo bit impostato, scansionare byte o analizzare campi di bit diventa più semplice ed economico. L'opcode è a basso costo fisso ed è stato confrontato per essere alla pari di un'addizione di base, il che riduce il bytecode e risparmia gas per lo stesso lavoro. + +**Risorse**: [Specifica tecnica dell'EIP-7939](https://eips.ethereum.org/EIPS/eip-7939) + +#### Precompilazione per il supporto della curva secp256r1 {#secp256r1-precompile} + +Introduce un verificatore di firma secp256r1 (P-256) integrato in stile passkey all'indirizzo fisso `0x100`, utilizzando lo stesso formato di chiamata già adottato da molti L2 e risolvendo casi limite, in modo che i contratti scritti per tali ambienti funzionino su L1 senza modifiche. + +Aggiornamento della UX! Per gli utenti, questo sblocca la firma nativa del dispositivo e le passkey. I portafogli possono attingere direttamente a Apple Secure Enclave, Android Keystore, moduli di sicurezza hardware (HSM) e FIDO2/WebAuthn: niente frase seed, onboarding più fluido e flussi multi-fattore che sembrano app moderne. Ciò si traduce in una migliore UX, un recupero più facile e modelli di astrazione dell'account che corrispondono a ciò che miliardi di dispositivi fanno già. + +Per gli sviluppatori, accetta un input di 160 byte e restituisce un output di 32 byte, rendendo facile il porting di librerie e contratti L2 esistenti. Sotto il cofano, include controlli del punto all'infinito e di confronto modulare per eliminare casi limite complessi senza interrompere i chiamanti validi. + +**Risorse**: + +- [Specifica tecnica dell'EIP-7951](https://eips.ethereum.org/EIPS/eip-7951) +- [Maggiori informazioni su RIP-7212](https://www.alchemy.com/blog/what-is-rip-7212) _(Nota che l'EIP-7951 ha sostituito il RIP-7212)_ + +### Meta {#meta} + +#### Metodo JSON-RPC `eth_config` {#eth-config} + +Si tratta di una chiamata JSON-RPC che consente di chiedere al proprio nodo quali impostazioni di fork si stanno utilizzando. Restituisce tre istantanee: `current`, `next` e `last`, in modo che validatori e strumenti di monitoraggio possano verificare che i client siano allineati per un fork imminente. + +In pratica, questo serve a risolvere una lacuna scoperta quando il fork Pectra è stato attivato sulla testnet Holesky all'inizio del 2025 con piccole errate configurazioni che hanno portato a uno stato di non finalizzazione. Questo aiuta i team di test e gli sviluppatori a garantire che i fork principali si comportino come previsto quando si passa dalle devnet alle testnet e dalle testnet alla Mainnet. + +Le istantanee includono: `chainId`, `forkId`, ora di attivazione del fork pianificata, quali precompilazioni sono attive, indirizzi delle precompilazioni, dipendenze dei contratti di sistema e il programma dei blob del fork. + +Questo EIP si trova in una sezione separata dagli "EIP Core" perché il fork non implementa effettivamente alcuna modifica: è un avviso che i team dei client devono implementare questo metodo JSON-RPC entro l'aggiornamento Fusaka. + +**Risorse**: [Specifica tecnica dell'EIP-7910](https://eips.ethereum.org/EIPS/eip-7910) + +## Domande frequenti {#faq} + +### Questo aggiornamento riguarda tutti i nodi e i validatori di Ethereum? {#does-this-upgrade-affect-all-ethereum-nodes-and-validators} +Sì, l'aggiornamento Fusaka richiede aggiornamenti sia per i [client di esecuzione che per i client di consenso](/developers/docs/nodes-and-clients/). Tutti i client principali di Ethereum rilasceranno versioni che supportano l'hard fork, contrassegnate come ad alta priorità. Puoi tenerti aggiornato su quando queste versioni saranno disponibili nei repository Github dei client, sui loro [canali Discord](https://ethstaker.org/support), sul [Discord di EthStaker](https://dsc.gg/ethstaker) o iscrivendoti al blog di Ethereum per gli aggiornamenti del protocollo. Per mantenere la sincronizzazione con la rete Ethereum dopo l'aggiornamento, gli operatori dei nodi devono assicurarsi di eseguire una versione client supportata. Si tenga presente che le informazioni sui rilasci dei client sono sensibili al fattore tempo e gli utenti devono fare riferimento agli ultimi aggiornamenti per dettagli attuali. + +### Come si converte l'ETH dopo la biforcazione dura? {#how-can-eth-be-converted-after-the-hardfork} + +- **Nessuna azione richiesta per i tuoi ETH**: a seguito dell'aggiornamento Fusaka di Ethereum, non è necessario convertire o aggiornare i propri ETH. I saldi del proprio conto rimarranno gli stessi e l'ETH che si possiede in quel momento rimarrà accessibile nella sua forma esistente dopo la biforcazione dura. +- **Attenzione alle truffe!** **chiunque ti dica di "aggiornare" il tuo ETH sta cercando di truffarti.** Non occorre fare nulla in relazione a questo aggiornamento. Le proprie risorse rimarranno completamente inalterate. Ricorda: essere informati è la migliore difesa contro le truffe. + +[Ulteriori informazioni su come riconoscere ed evitare le truffe](/security/) + +### Cosa c'entrano le zebre? {#whats-with-the-zebras} + +La zebra è la "mascotte" scelta dagli sviluppatori per Fusaka perché le sue strisce riflettono il campionamento della disponibilità dei dati basato su colonne di PeerDAS, in cui i nodi custodiscono determinate sottoreti di colonne e campionano alcune altre colonne da ogni slot dei peer per verificare che i dati dei blob siano disponibili. + +La Fusione (Merge) del 2022 [ha usato un panda](https://x.com/hwwonx/status/1431970802040127498) come mascotte per segnalare l'unione dei livelli di esecuzione e di consenso. Da allora, per ogni fork sono state scelte informalmente delle mascotte che appaiono come arte ASCII nei log dei client al momento dell'aggiornamento. È solo un modo divertente per celebrare. + +### Quali miglioramenti sono inclusi per la scalabilità L2? {#what-improvements-are-included-for-l2-scaling} + +[PeerDAS](/roadmap/fusaka/peerdas) è la caratteristica principale del fork. Implementa il campionamento della disponibilità dei dati (DAS) che sblocca una maggiore scalabilità per i rollup, scalando teoricamente lo spazio dei blob fino a 8 volte la dimensione attuale. Anche il mercato delle commissioni dei blob sarà migliorato per reagire in modo efficiente alla congestione e garantire che i L2 paghino una commissione significativa per il calcolo e lo spazio che i blob impongono ai nodi. + +### In che cosa differiscono i fork BPO? {#how-are-bpo-forks-different} + +I fork solo per parametri blob forniscono un meccanismo per aumentare continuamente il conteggio dei blob (sia target che max) dopo l'attivazione di PeerDAS, senza dover attendere un aggiornamento completamente coordinato. Ogni aumento è preconfigurato tramite hardcoding nelle versioni dei client che supportano Fusaka. + +Come utente o validatore, non è necessario aggiornare i client per ogni BPO, ma solo assicurarsi di seguire i principali hardfork come Fusaka. Questa è la stessa pratica di prima, non sono necessarie azioni speciali. È comunque consigliabile monitorare i client durante gli aggiornamenti e i BPO e mantenerli aggiornati anche tra le versioni principali, poiché correzioni o ottimizzazioni potrebbero seguire l'hardfork. + +### Qual è il programma dei BPO? {#what-is-the-bpo-schedule} + +Il programma esatto degli aggiornamenti BPO sarà determinato con le versioni di Fusaka. Segui gli [annunci del protocollo](https://blog.ethereum.org/category/protocol) e le note di rilascio dei tuoi client. + +Esempio di come potrebbe apparire: + +- Prima di Fusaka: target 6, max 9 +- All'attivazione di Fusaka: target 6, max 9 +- BPO1, poche settimane dopo l'attivazione di Fusaka: target 10, max 15, con un aumento di due terzi +- BPO2, poche settimane dopo il BPO1: target 14, max 21 + +### Questo ridurrà le commissioni su Ethereum (Layer 1)? {#will-this-lower-gas} + +Questo aggiornamento non riduce le commissioni del gas su L1, almeno non direttamente. L'obiettivo principale è avere più spazio per i blob per i dati dei rollup, riducendo quindi le commissioni sul Layer 2. Questo potrebbe avere alcuni effetti collaterali sul mercato delle commissioni L1, ma non si prevede alcun cambiamento significativo. + +### Come staker, cosa devo fare per l'aggiornamento? {#as-a-staker-what-do-i-need-to-do-for-the-upgrade} + +Come per ogni aggiornamento di rete, assicurati di aggiornare i tuoi client alle ultime versioni contrassegnate con il supporto a Fusaka. Segui gli aggiornamenti nella mailing list e gli [annunci del protocollo sul blog di EF](https://blog.ethereum.org/category/protocol) per essere informato sui rilasci. +Per convalidare la tua configurazione prima che Fusaka venga attivato sulla Mainnet, puoi eseguire un validatore sulle testnet. Fusaka viene [attivato prima sulle testnet](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement), dandoti più tempo per assicurarti che tutto funzioni e per segnalare bug. Anche i fork delle testnet sono annunciati nella mailing list e sul blog. + +### La "Visione anticipata deterministica dei proponenti" (EIP-7917) influisce sui validatori? {#does-7917-affect-validators} + +Questa modifica non cambia il funzionamento del tuo client validatore, tuttavia, fornirà maggiori informazioni sul futuro dei tuoi compiti di validatore. Assicurati di aggiornare i tuoi strumenti di monitoraggio per stare al passo con le nuove funzionalità. + +### In che modo Fusaka influisce sui requisiti di larghezza di banda per nodi e validatori? {#how-does-fusaka-affect-bandwidth-requirements-for-nodes-and-validators} + +PeerDAS apporta un cambiamento significativo nel modo in cui i nodi trasmettono i dati dei blob. Tutti i dati sono divisi in pezzi chiamati colonne su 128 sottoreti, con i nodi che si iscrivono solo ad alcune di esse. Il numero di colonne di sottorete che i nodi devono custodire dipende dalla loro configurazione e dal numero di validatori connessi. I requisiti effettivi di larghezza di banda dipenderanno dalla quantità di blob consentiti nella rete e dal tipo di nodo. Al momento dell'attivazione di Fusaka, il target di blob rimane lo stesso di prima, ma con PeerDAS, gli operatori dei nodi possono notare una diminuzione dell'utilizzo del disco per i blob e del traffico di rete. Man mano che i BPO configurano un numero maggiore di blob nella rete, la larghezza di banda necessaria aumenterà con ogni BPO. + +I requisiti dei nodi rientrano ancora nei [margini consigliati](https://eips.ethereum.org/EIPS/eip-7870) anche dopo i BPO di Fusaka. + +#### Nodi completi {#full-nodes} + +I nodi regolari senza alcun validatore si iscriveranno solo a 4 sottoreti, fornendo la custodia di 1/8 dei dati originali. Ciò significa che, con la stessa quantità di dati dei blob, la larghezza di banda del nodo per scaricarli sarebbe inferiore di un fattore otto (8). L'utilizzo del disco e la larghezza di banda di download dei blob per un normale nodo completo potrebbero diminuire di circa l'80%, a solo pochi Mb. + +#### Staking in solitaria {#solo-stakers} + +Se il nodo è utilizzato per un client validatore, deve custodire più colonne e quindi elaborare più dati. Con l'aggiunta di un validatore, il nodo si iscrive ad almeno 8 sottoreti di colonne e quindi elabora il doppio dei dati di un nodo normale, ma comunque meno di prima di Fusaka. Se il saldo del validatore è superiore a 287 ETH, verranno sottoscritte sempre più sottoreti. + +Per uno staker solitario, ciò significa che l'utilizzo del disco e la larghezza di banda di download diminuiranno di circa il 50%. Tuttavia, per costruire blocchi localmente e caricare tutti i blob sulla rete, è necessaria una maggiore larghezza di banda di upload. I costruttori locali avranno bisogno di una larghezza di banda di upload 2-3 volte superiore rispetto a prima al momento di Fusaka e con il target BPO2 di 15/21 blob, la larghezza di banda di upload finale necessaria dovrà essere circa 5 volte superiore, a 100 Mbps. + +#### Grandi validatori {#large-validators} + +Il numero di sottoreti sottoscritte cresce con l'aumento del saldo e dei validatori aggiunti al nodo. Ad esempio, con un saldo di circa 800 ETH, il nodo custodisce 25 colonne e avrà bisogno di circa il 30% in più di larghezza di banda di download rispetto a prima. L'upload necessario aumenta in modo simile ai nodi normali ed è necessario almeno 100 Mbps. + +A 4096 ETH, con 2 validatori a saldo massimo, il nodo diventa un 'supernodo' che custodisce tutte le colonne, quindi scarica e archivia tutto. Questi nodi guariscono attivamente la rete contribuendo a ripristinare i dati mancanti, ma richiedono anche molta più larghezza di banda e spazio di archiviazione. Con il target finale di blob 6 volte superiore a prima, i super nodi dovranno archiviare circa 600 GB di dati blob extra e avere una larghezza di banda di download sostenuta più veloce, intorno ai 20 Mbps. + +[Leggi maggiori dettagli sui requisiti previsti.](https://ethpandaops.io/posts/fusaka-bandwidth-estimation/#theoretical-requirements) + +### Quali modifiche all'EVM sono state implementate? {#what-evm-changes-are-implemented} + +Fusaka consolida l'EVM con nuove piccole modifiche e funzionalità. + +- Per la sicurezza durante la scalabilità, la dimensione massima di una singola transazione sarà [limitata a 16,7 milioni](https://eips.ethereum.org/EIPS/eip-7825) di unità di gas. +- Il [nuovo opcode per contare gli zeri iniziali (CLZ)](https://eips.ethereum.org/EIPS/eip-7939) è stato aggiunto all'EVM e consentirà ai linguaggi dei contratti intelligenti di eseguire determinate operazioni in modo più efficiente. +- [Il costo della precompilazione `ModExp` sarà aumentato](https://eips.ethereum.org/EIPS/eip-7883): i contratti che la utilizzano addebiteranno più gas per l'esecuzione. + +### In che modo il nuovo limite di gas di 16M influisce sugli sviluppatori di contratti? {#how-does-new-16m-gas-limit-affects-contract-developers} + +Fusaka introduce un limite alla [dimensione massima di una singola transazione a 16,7 milioni](https://eips.ethereum.org/EIPS/eip-7825) (2^24) di unità di gas. Questa è all'incirca la dimensione precedente di un blocco medio, il che la rende abbastanza grande da ospitare transazioni complesse che consumerebbero un intero blocco. Questo limite crea una protezione per i client, prevenendo potenziali attacchi DoS in futuro con un limite di gas del blocco più elevato. L'obiettivo della scalabilità è consentire a più transazioni di entrare nella blockchain senza che una singola transazione consumi l'intero blocco. + +Le normali transazioni degli utenti sono lontane dal raggiungere questo limite. Alcuni casi limite come operazioni DeFi grandi e complesse, grandi distribuzioni di contratti intelligenti o transazioni batch che mirano a più contratti potrebbero essere influenzati da questa modifica. Queste transazioni dovranno essere suddivise in transazioni più piccole o ottimizzate in un altro modo. Utilizza la simulazione prima di inviare transazioni che potrebbero raggiungere il limite. + +Il metodo RPC `eth_call` non è limitato e consentirà la simulazione di transazioni più grandi del limite effettivo della blockchain. Il limite effettivo per i metodi RPC può essere configurato dall'operatore del client per prevenire abusi. + +### Cosa significa CLZ per gli sviluppatori? {#what-clz-means-for-developers} + +I compilatori EVM come Solidity implementeranno e utilizzeranno la nuova funzione per contare gli zeri sotto il cofano. I nuovi contratti potrebbero beneficiare di un risparmio di gas se si basano su questo tipo di operazione. Segui le versioni e gli annunci delle funzionalità del linguaggio dei contratti intelligenti per la documentazione sui potenziali risparmi. + +### Ci sono modifiche per i miei contratti intelligenti esistenti? {#what-clz-means-for-developers} + +Fusaka non ha effetti diretti che potrebbero interrompere contratti esistenti o cambiarne il comportamento. Le modifiche introdotte al livello di esecuzione sono realizzate con compatibilità con le versioni precedenti, tuttavia, tieni sempre d'occhio i casi limite e il potenziale impatto. + +[Con l'aumento del costo della precompilazione `ModExp`](https://eips.ethereum.org/EIPS/eip-7883), i contratti che dipendono da essa consumeranno più gas per l'esecuzione. Se il tuo contratto si basa molto su questo e diventa più costoso per gli utenti, riconsidera come viene utilizzato. + +Considera il [nuovo limite di 16,7 milioni](https://eips.ethereum.org/EIPS/eip-7825) se le transazioni che eseguono i tuoi contratti potrebbero raggiungere dimensioni simili. + +## Letture consigliate {#further-reading} + +- [Tabella di marcia di Ethereum](/roadmap/) +- [Forkcast: Fusaka](https://forkcast.org/upgrade/fusaka) +- [Meta EIP di Fusaka](https://eips.ethereum.org/EIPS/eip-7607) +- [Annuncio sul blog della testnet di Fusaka](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement) +- [Bankless: cosa porteranno Fusaka e Pectra a Ethereum](https://www.bankless.com/read/what-fusaka-pectra-will-bring-ethereum) +- [Bankless: i prossimi aggiornamenti di Ethereum: Fusaka, Glamsterdam e oltre con Preston Van Loon](https://x.com/BanklessHQ/status/1956017743289020633?t=502) +- [The Fusaka Files](https://www.youtube.com/playlist?list=PL4cwHXAawZxpz-erUbKKUnnGoQNdF8s7Z) +- [PEEPanEIPs Explained](https://www.youtube.com/playlist?list=PL4cwHXAawZxoIenfk7OJry4rxcqX-eqBt) diff --git a/public/content/translations/it/roadmap/fusaka/peerdas/index.md b/public/content/translations/it/roadmap/fusaka/peerdas/index.md new file mode 100644 index 00000000000..6c1c3de9288 --- /dev/null +++ b/public/content/translations/it/roadmap/fusaka/peerdas/index.md @@ -0,0 +1,88 @@ +--- +title: PeerDAS +description: Informazioni su PeerDAS come parte dell'aggiornamento del protocollo Ethereum Fusaka +lang: it +--- + +# PeerDAS {#peer-das} + +Il protocollo Ethereum sta subendo il suo più significativo aggiornamento di ridimensionamento dall'[introduzione delle transazioni blob con l'EIP-4844](/roadmap/danksharding/). Come parte dell'[aggiornamento Fusaka](/roadmap/fusaka/), PeerDAS introduce un nuovo modo di gestire i dati blob, offrendo un aumento di circa un ordine di grandezza nella capacità di **[disponibilità dei dati (DA)](/developers/docs/data-availability/)** per gli L2. + +[Maggiori informazioni sulla tabella di marcia del ridimensionamento dei blob](https://blog.ethereum.org/2025/08/22/protocol-update-002) + +## Scalabilità {#scalability} + +La visione di Ethereum è quella di essere una piattaforma neutrale, sicura e decentralizzata disponibile per tutti nel mondo. Con l'aumento dell'utilizzo della rete, ciò richiede di bilanciare il trilemma di scalabilità, sicurezza e decentralizzazione della rete. Se Ethereum semplicemente aumentasse i dati gestiti dalla rete con il suo design attuale, correrebbe il rischio di sovraccaricare i [nodi su cui Ethereum si basa per la sua decentralizzazione](/developers/docs/nodes-and-clients/). La scalabilità richiede una progettazione rigorosa dei meccanismi che minimizzi i compromessi. + +Una delle strategie per raggiungere questo obiettivo è consentire un ecosistema diversificato di soluzioni di ridimensionamento di livello 2 invece di elaborare tutte le transazioni sulla Rete Principale di [livello 1 (L1)](/glossary/#layer-1). I [Livelli 2 (L2)](/glossary/#layer-2) o i [rollup](/glossary#rollups) elaborano le transazioni sulle proprie chain separate e utilizzano Ethereum per la verifica e la sicurezza. La pubblicazione dei soli commitment critici per la sicurezza e la compressione dei payload consente agli L2 di utilizzare la capacità di DA di Ethereum in modo più efficiente. A sua volta, l'L1 trasporta meno dati senza compromettere le garanzie di sicurezza, mentre gli L2 acquisiscono più utenti a costi del gas inferiori. Inizialmente, gli L2 pubblicavano i dati come `calldata` in transazioni ordinarie, che competevano con le transazioni L1 per il gas ed era poco pratico per la disponibilità di dati di massa. + +## Proto-Danksharding {#proto-danksharding} + +Il primo passo importante verso il ridimensionamento dell'L2 è stato l'aggiornamento Dencun, che ha introdotto il [Proto-Danksharding](/roadmap/danksharding/) (EIP-4844). Questo aggiornamento ha creato un nuovo tipo di dati specializzato per i rollup chiamato blob. I [blob](/developers/docs/data-availability/blockchain-data-storage-strategies/#eip-4844-blobs), o oggetti binari di grandi dimensioni, sono frammenti effimeri di dati arbitrari che non necessitano dell'esecuzione dell'EVM e che i nodi archiviano solo per un periodo di tempo limitato. Questa elaborazione più efficiente ha permesso agli L2 di pubblicare più dati su Ethereum e di scalare ulteriormente. + +Nonostante i notevoli vantaggi per il ridimensionamento, l'utilizzo dei blob è solo una parte dell'obiettivo finale. Nel protocollo attuale, ogni nodo della rete deve ancora scaricare ogni blob. Il collo di bottiglia diventa la larghezza di banda richiesta dai singoli nodi, con la quantità di dati da scaricare che aumenta direttamente con l'aumento del numero di blob. + +Ethereum non scende a compromessi sulla decentralizzazione e la larghezza di banda è uno dei parametri più sensibili. Anche con potenti risorse di calcolo ampiamente disponibili per chiunque possa permettersele, le [limitazioni della larghezza di banda in upload](https://www.speedtest.net/global-index) anche in città altamente urbanizzate di nazioni sviluppate (come [Germania](https://www.speedtest.net/global-index/germany), [Belgio](https://www.speedtest.net/global-index/belgium), [Australia](https://www.speedtest.net/global-index/australia) o [Stati Uniti](https://www.speedtest.net/global-index/united-states)) potrebbero limitare i nodi a poter essere eseguiti solo da data center se i requisiti di larghezza di banda non sono attentamente calibrati. + +Gli operatori dei nodi hanno requisiti di larghezza di banda e spazio su disco sempre più elevati man mano che i blob aumentano. La dimensione e la quantità dei blob sono limitate da questi vincoli. Ogni blob può trasportare fino a 128 kb di dati con una media di 6 blob per blocco. Questo è stato solo il primo passo verso un design futuro che utilizza i blob in un modo ancora più efficiente. + +## Campionamento della disponibilità dei dati (DAS) {#das} + +La [disponibilità dei dati](/developers/docs/data-availability/) è la garanzia che tutti i dati necessari per convalidare in modo indipendente la chain siano accessibili a tutti i partecipanti alla rete. Garantisce che i dati siano stati completamente pubblicati e possano essere utilizzati per verificare in modo trustless il nuovo stato della chain o le transazioni in entrata. + +I blob di Ethereum forniscono una forte garanzia di disponibilità dei dati che garantisce la sicurezza degli L2. Per fare questo, i nodi di Ethereum devono scaricare e archiviare i blob nella loro interezza. Ma cosa succederebbe se potessimo distribuire i blob nella rete in modo più efficiente ed evitare questa limitazione? + +Un approccio differente per archiviare i dati e garantirne la disponibilità è il **campionamento della disponibilità dei dati (DAS)**. Invece di fare in modo che ogni computer che esegue Ethereum archivi completamente ogni singolo blob, il DAS introduce una divisione decentralizzata del lavoro. Spezza l'onere dell'elaborazione dei dati distribuendo compiti più piccoli e gestibili attraverso l'intera rete di nodi. I blob vengono divisi in parti e ogni nodo scarica solo alcune parti utilizzando un meccanismo di distribuzione casuale uniforme tra tutti i nodi. + +Questo introduce un nuovo problema: dimostrare la disponibilità e l'integrità dei dati. Come può la rete garantire che i dati siano disponibili e che siano tutti corretti quando i singoli nodi detengono solo piccole parti? Un nodo malevolo potrebbe servire dati falsi e infrangere facilmente le forti garanzie di disponibilità dei dati! È qui che la crittografia viene in aiuto. + +Per garantire l'integrità dei dati, l'EIP-4844 è stato già implementato con i commitment KZG. Queste sono prove crittografiche create quando un nuovo blob viene aggiunto alla rete. Una piccola prova è inclusa in ogni blocco, e i nodi possono verificare che i blob ricevuti corrispondano al commitment KZG del blocco. + +Il DAS è un meccanismo che si basa su questo e garantisce che i dati siano sia corretti che disponibili. Il campionamento è un processo in cui un nodo interroga solo una piccola parte dei dati e la verifica rispetto al commitment. KZG è uno schema di commitment polinomiale, il che significa che qualsiasi singolo punto sulla curva polinomiale può essere verificato. Controllando solo un paio di punti sul polinomio, il client che esegue il campionamento può avere una forte garanzia probabilistica che i dati siano disponibili. + +## PeerDAS {#peer-das} + +[PeerDAS (EIP-7594)](https://eips.ethereum.org/EIPS/eip-7594) è una proposta specifica che implementa il meccanismo DAS in Ethereum, segnando probabilmente il più grande aggiornamento da La Fusione. PeerDAS è progettato per estendere i dati dei blob, dividendoli in colonne e distribuendo un sottoinsieme ai nodi. + +Per raggiungere questo obiettivo, Ethereum prende in prestito alcuni concetti matematici intelligenti: applica la codifica a cancellazione (erasure coding) in stile Reed-Solomon ai dati dei blob. I dati dei blob sono rappresentati come un polinomio i cui coefficienti codificano i dati, quindi quel polinomio viene valutato in punti aggiuntivi per creare un blob esteso, raddoppiando il numero di valutazioni. Questa ridondanza aggiunta consente il recupero da cancellazione: anche se mancano alcune valutazioni, il blob originale può essere ricostruito purché sia disponibile almeno la metà dei dati totali, comprese le parti estese. + +![Polinomio esteso](./polynomial.png) + +In realtà, questo polinomio ha migliaia di coefficienti. I commit KZG sono valori di pochi byte, qualcosa di simile a un hash, noto a tutti i nodi. Ogni nodo che detiene un numero sufficiente di punti dati può [ricostruire in modo efficiente un set completo di dati dei blob](https://arxiv.org/abs/2207.11079). + +> Curiosità: la stessa tecnica di codifica era utilizzata dai DVD. Se si graffiava un DVD, il lettore era ancora in grado di leggerlo grazie alla codifica Reed-Solomon che aggiunge le parti mancanti del polinomio. + +Storicamente, i dati nelle blockchain, che si tratti di blocchi o blob, venivano trasmessi a tutti i nodi. Con l'approccio di suddivisione e campionamento di PeerDAS, la trasmissione di tutto a tutti non è più necessaria. Dopo Fusaka, il networking del livello di consenso è organizzato in argomenti/subnet di gossip: le colonne di blob sono assegnate a subnet specifiche, e ogni nodo si iscrive a sottoinsiemi predeterminati e custodisce solo quelle parti. + +Con PeerDAS, i dati dei blob estesi vengono divisi in 128 parti chiamate colonne. I dati vengono distribuiti a questi nodi tramite un protocollo di gossip dedicato su subnet specifiche a cui si iscrivono. Ogni nodo regolare sulla rete partecipa ad almeno 8 subnet di colonna scelte casualmente. Ricevere dati da sole 8 delle 128 subnet significa che questo nodo predefinito riceve solo 1/16 di tutti i dati, ma poiché i dati sono stati estesi, questo corrisponde a 1/8 dei dati originali. + +Ciò consente un nuovo limite di ridimensionamento teorico di 8 volte rispetto all'attuale schema "tutti scaricano tutto". Con i nodi che si iscrivono a diverse subnet casuali che servono le colonne di blob, la probabilità che siano distribuiti uniformemente è molto alta e quindi ogni parte di dati esiste da qualche parte nella rete. I nodi che eseguono validatori sono tenuti a iscriversi a più subnet per ogni validatore che gestiscono. + +> Ogni nodo ha un ID univoco generato casualmente, che normalmente funge da sua identità pubblica per le connessioni. In PeerDAS, questo numero viene utilizzato per determinare il set casuale di subnet a cui deve iscriversi, risultando in una distribuzione casuale uniforme di tutti i dati dei blob. + +Una volta che un nodo ricostruisce con successo i dati originali, ridistribuisce le colonne recuperate nella rete, riparando attivamente eventuali lacune nei dati e migliorando la resilienza complessiva del sistema. I nodi connessi a validatori con un saldo combinato ≥4096 ETH devono essere un supernodo e quindi devono iscriversi a tutte le subnet di colonna di dati e custodire tutte le colonne. Questi supernodi ripareranno continuamente le lacune nei dati. La natura probabilisticamente autoriparante del protocollo consente forti garanzie di disponibilità senza limitare gli operatori domestici che detengono solo porzioni dei dati. + +![Nodi che si iscrivono alle colonne distribuite tramite subnet](./subnets.png) + +La disponibilità dei dati può essere confermata da qualsiasi nodo che detiene solo un piccolo sottoinsieme dei dati dei blob grazie al meccanismo di campionamento descritto sopra. Questa disponibilità è imposta: i validatori devono seguire nuove regole di scelta della biforcazione (fork-choice), il che significa che accetteranno e voteranno per i blocchi solo dopo aver verificato la disponibilità dei dati. + +L'impatto diretto sugli utenti (in particolare gli utenti L2) sono le commissioni più basse. Con 8 volte più spazio per i dati dei rollup, le operazioni degli utenti sulla loro chain diventano ancora più economiche con il tempo. Ma le commissioni più basse dopo Fusaka richiederanno tempo e dipenderanno dai BPO. + +## Biforcazioni solo per i parametri dei blob (BPO) {#bpo} + +La rete sarà teoricamente in grado di elaborare 8 volte più blob, ma gli aumenti dei blob sono un cambiamento che deve essere adeguatamente testato ed eseguito in modo sicuro e graduale. Le reti di prova forniscono abbastanza fiducia per distribuire le funzionalità sulla Rete Principale, ma dobbiamo garantire la stabilità della rete p2p prima di abilitare un numero significativamente più alto di blob. + +Per aumentare gradualmente il numero target di blob per blocco senza sovraccaricare la rete, Fusaka introduce le biforcazioni **[solo per i parametri dei blob (BPO)](https://ethereum-magicians.org/t/blob-parameter-only-bpo-forks/22623)**. A differenza delle biforcazioni regolari che necessitano di un'ampia coordinazione dell'ecosistema, di accordo e di aggiornamenti software, i [BPO (EIP-7892)](https://eips.ethereum.org/EIPS/eip-7892) sono aggiornamenti pre-programmati che aumentano il numero massimo di blob nel tempo senza intervento. + +Ciò significa che immediatamente dopo l'attivazione di Fusaka e l'entrata in funzione di PeerDAS, il numero di blob rimarrà invariato. Il numero di blob inizierà a raddoppiare ogni poche settimane fino a raggiungere un massimo di 48, mentre gli sviluppatori monitorano per garantire che il meccanismo funzioni come previsto e non abbia effetti negativi sui nodi che eseguono la rete. + +## Direzioni future {#future-directions} + +PeerDAS è solo un passo [verso una visione di ridimensionamento più ampia di FullDAS](https://ethresear.ch/t/fulldas-towards-massive-scalability-with-32mb-blocks-and-beyond/19529), o Danksharding. Mentre PeerDAS utilizza la codifica a cancellazione 1D per ogni singolo blob, il Danksharding completo utilizzerà uno schema di codifica a cancellazione 2D più completo sull'intera matrice di dati dei blob. L'estensione dei dati in due dimensioni crea proprietà di ridondanza ancora più forti e una ricostruzione e verifica più efficienti. La realizzazione di FullDAS richiederà notevoli ottimizzazioni della rete e del protocollo, oltre a ulteriori ricerche. + +## Letture consigliate {#further-reading} + +- [PeerDAS: Campionamento della disponibilità dei dati peer di Francesco D'Amato](https://www.youtube.com/watch?v=WOdpO1tH_Us) +- [Una documentazione del PeerDAS di Ethereum](https://eprint.iacr.org/2024/1362.pdf) +- [Dimostrazione della sicurezza di PeerDAS senza l'AGM](https://eprint.iacr.org/2025/1683) +- [Vitalik su PeerDAS, il suo impatto e i test di Fusaka](https://x.com/VitalikButerin/status/1970983281090085200) \ No newline at end of file diff --git a/public/content/translations/it/roadmap/future-proofing/index.md b/public/content/translations/it/roadmap/future-proofing/index.md index 9166a97866d..85e680f46d1 100644 --- a/public/content/translations/it/roadmap/future-proofing/index.md +++ b/public/content/translations/it/roadmap/future-proofing/index.md @@ -1,6 +1,6 @@ --- title: Rendere Ethereum a prova di futuro -description: Questi aggiornamenti cementano Ethereum come lo strato fondamentale, resiliente e decentralizzato per il futuro, indipendentemente da ciò che conterrà. +description: "Questi aggiornamenti cementano Ethereum come lo strato fondamentale, resiliente e decentralizzato per il futuro, indipendentemente da ciò che conterrà." lang: it image: /images/roadmap/roadmap-future.png alt: "Roadmap di Ethereum" @@ -11,28 +11,43 @@ Alcune parti della tabella di marcia non sono necessariamente richieste per ridi ## Resistenza quantistica {#quantum-resistance} -Parte della protezione [crittografica](/glossary/#cryptography) odierna di Ethereum sarà compromessa quando l'informatica quantistica diventerà una realtà. Sebbene i computer quantistici siano probabilmente a decenni dall'essere una vera minaccia per la crittografia moderna, Ethereum ha una struttura che ne garantisce la sicurezza nei secoli a venire. Ciò significa rendere [Ethereum resistente ai computer quantistici](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/), il prima possibile. +Parte della [crittografia](/glossary/#cryptography) che protegge l'attuale Ethereum sarà compromessa quando l'informatica quantistica diventerà una realtà. Sebbene i computer quantistici siano probabilmente a decenni dall'essere una vera minaccia per la crittografia moderna, Ethereum ha una struttura che ne garantisce la sicurezza nei secoli a venire. Ciò significa rendere [Ethereum resistente ai computer quantistici](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) il prima possibile. -La sfida affrontata dagli sviluppatori di Ethereum è che l'attuale protocollo di [proof-of-stake](/glossary/#pos) si affida a uno schema di firma molto efficiente, noto come BLS, per aggregare i voti sui [blocchi](/glossary/#block) validi. Questo schema di firme è infranto dai computer quantistici, ma le alternative resistenti a essi non sono altrettanto efficaci. +La sfida per gli sviluppatori di Ethereum è che l'attuale protocollo [proof-of-stake](/glossary/#pos) si affida a uno schema di firma molto efficiente, noto come BLS, per aggregare i voti sui [blocchi](/glossory/#block) validi. Questo schema di firme è infranto dai computer quantistici, ma le alternative resistenti a essi non sono altrettanto efficaci. -Gli [schemi di impegno "KZG"](/roadmap/danksharding/#what-is-kzg) utilizzati in svariati punti su Ethereum per generare frasi segrete crittografiche sono noti per la loro vulnerabilità ai computer quantistici. Al momento, il problema viene eluso utilizzando le "configurazioni fidate", in cui molti utenti generano casualità non decodificabili da un computer quantistico. Tuttavia, la soluzione ideale sarebbe semplicemente incorporare, piuttosto, la crittografia sicura contro i computer quantistici. Esistono due approcci principali che potrebbero divenire efficienti sostituti per lo schema BLS: la firma [basata su STARK](https://hackmd.io/@vbuterin/stark_aggregation) e [basata su reticolo](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175). **Queste sono ancora in fase di ricerca e prototipazione**. +Gli [schemi di commitment “KZG”](/roadmap/danksharding/#what-is-kzg) usati in diversi punti di Ethereum per generare segreti crittografici sono noti per essere vulnerabili ai computer quantistici. Attualmente questo viene aggiorato con l'uso di "impostazioni fidate" (per le quali la cerimonia d'impostazione principale venne completata con successo nel 2023) dove tanti utenti generano casualità non decifrabile da computer quantistici. Ad ogni modo, la soluzione ideale per il lungo termine sarebbe invece la crittografia quantistica sicura. Ci sono due approcci principali che potrebbero diventare sostituti efficienti per lo schema BLS: la firma [basata su STARK](https://hackmd.io/@vbuterin/stark_aggregation) e quella [basata su reticolo](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175). **Sono ancora attivamente in fase di ricerca e prototipazione.** - Leggi su KZG e le configurazioni fidate +[Leggi di più su KZG e configurazioni fidate](/roadmap/danksharding#what-is-kzg) -## Un Ethereum più semplice ed efficiente {#simpler-more-efficient-ethereum} +## Un Ethereum più semplice e più efficiente {#simpler-more-efficient-ethereum} -La complessità crea opportunità per bug o vulnerabilità sfruttabili dagli utenti malevoli. Dunque, parte della tabella di marcia è semplificare Ethereum e rimuovere il codice rimanente dai vari aggiornamenti, ma non più necessario o migliorabile. Una base di codice più snella e semplice è, per gli sviluppatori, più facile da mantenere, nonché da ragionare. +Complexity crea per gli hacker bug e vulnerabilità che possono essere un exploit. Per questo, parte della roadmap è semplificare Ethereum e rimuovere o modificare codice rimasto appeso in giro attraverso i diversi aggiornamenti e che non è più necessario o che possa essere migliorato da qui in poi. Una base di codice più snella e più semplice, è più facile da mantere e da ragionarci sopra per gli sviluppatori. -Esistono diversi aggiornamenti che saranno apportati alla [Macchina Virtuale di Ethereum (EVM)](/developers/docs/evm), per renderla più semplice ed efficiente. Questi includono la [rimozione del codice operativo SELFDESTRUCT](https://hackmd.io/@vbuterin/selfdestruct): un comando raramente utilizzato e non più necessario che, in certe circostanze, può essere pericoloso da usare, specialmente quando combinato con altri aggiornamenti futuri al modello di archiviazione di Ethereum. I [client di Ethereum](/glossary/#consensus-client), inoltre, supportano ancora alcuni vecchi tipi di transazioni che ormai possono essere completamente rimossi. Anche il metodo di calcolo del [gas](/glossary/#gas) è migliorabile e possono essere introdotti metodi più efficienti per il sostegno aritmetico di certe operazioni crittografiche. +Per rendere la [Macchina Virtuale di Ethereum (EVM)](/developers/docs/evm) più semplice ed efficiente, vengono continuamente ricercati e implementati dei miglioramenti. Questo coinvolge sia la gestione dei componenti legacy sia l'introduzione di ottimizzazioni. -Similmente, esistono aggiornamenti apportabili ad altre parti dei client odierni di Ethereum. Un esempio sono i client d'esecuzione e consenso odierni, che utilizzano un tipo di compressione dei dati differente. Sarebbe molto più facile e intuitivo condividere i dati tra i client, quando lo schema di compressione è unificato per l'intera rete. +**Cambiamenti implementati di recente:** -## Stato attuale {#current-progress} +- **Revisione del calcolo del gas:** il modo in cui il [gas](/glossary/#gas) viene calcolato è stato notevolmente migliorato con l'**EIP-1559 (implementato nell'aggiornamento London, 2021)**, introducendo una commissione di base e un meccanismo di burn per una determinazione dei prezzi delle transazioni più prevedibile. +- **Restrizione di `SELFDESTRUCT`:** L'opcode `SELFDESTRUCT`, sebbene usato raramente, presentava rischi potenziali. La sua funzionalità è stata fortemente **ristretta nell'aggiornamento Dencun (marzo 2024) tramite l'EIP-6780** per mitigare i pericoli, in particolare per quanto riguarda la gestione dello stato. +- **Tipi di transazione modernizzati:** sono stati introdotti nuovi formati di transazione (ad es. tramite l'**EIP-2718** e l'**EIP-4844** per i blob nell'aggiornamento Dencun) per supportare nuove funzionalità e migliorare l'efficienza rispetto ai tipi legacy. -Gran parte degli aggiornamenti necessari per rendere Ethereum a prova di futuro sono **ancora in fase di ricerca e potrebbero richiedere ancora svariati anni** per essere implementati. Aggiornamenti come la rimozione di SELFDESTRUCT e l'armonizzazione dello schema di compressione utilizzato nei client di esecuzione e di consenso potrebbero arrivare prima della crittografia a resistenza quantistica. +**Obiettivi in corso e futuri:** -**Letture consigliate** +- **Ulteriore gestione di `SELFDESTRUCT`:** sebbene limitata, la **potenziale rimozione completa** dell'opcode `SELFDESTRUCT` è ancora in fase di valutazione per futuri aggiornamenti al fine di semplificare ulteriormente lo stato dell'EVM. ([Maggiori informazioni sui problemi di SELFDESTRUCT](https://hackmd.io/@vbuterin/selfdestruct)). +- **Eliminazione graduale delle transazioni legacy:** sebbene i [client di Ethereum](/glossary/#consensus-client) supportino ancora i tipi di transazione più vecchi per la retrocompatibilità, l'obiettivo è incoraggiare la migrazione a tipi più recenti e **potenzialmente deprecare o rimuovere completamente il supporto per i formati più vecchi** in futuro. +- **Ricerca continua sull'efficienza del gas:** l'esplorazione continua verso **ulteriori perfezionamenti per il calcolo del gas**, includendo potenzialmente concetti come il gas multidimensionale per riflettere meglio l'utilizzo delle risorse. +- **Operazioni crittografiche ottimizzate:** sono in corso sforzi per **introdurre metodi più efficienti per l'aritmetica** alla base delle operazioni crittografiche utilizzate all'interno dell'EVM. + +Ci sono aggiornamenti simili che possono essere applicati ai client dei giorni attuali. Un esempio è che i client di consenso ed esecuzione attuale usano tipi di compressione dati diversi. Sarebbe ancora più semplice e più intuitivo condividere dati fra i client se lo schema di compressione fosse univoco attraverso tutta la rete. Questo resta un'area di esplorazione. + +## Progressi attuali {#current-progress} + +Molti degli aggiornamenti a lungo termine per la protezione futura, in particolare la **piena resistenza quantistica per i protocolli principali, sono ancora in fase di ricerca e potrebbero richiedere diversi anni** prima di essere implementati. + +Tuttavia, **sono già stati compiuti progressi significativi negli sforzi di semplificazione.** Ad esempio, modifiche chiave come la **restrizione di `SELFDESTRUCT` (EIP-6780)** e l'introduzione di **transazioni che trasportano blob (EIP-4844)** sono state implementate nell'**aggiornamento Dencun (marzo 2024)**. Il lavoro per armonizzare e semplificare lo schema di compressione dei client prosegue. + +**Lettura consigliata** - [Gas](/developers/docs/gas) - [EVM](/developers/docs/evm) -- [Strutture di dati](/developers/docs/data-structures-and-encoding) +- [Strutture di dati](/developers/docs/data-structures-and-encoding) \ No newline at end of file diff --git a/public/content/translations/it/roadmap/merge/index.md b/public/content/translations/it/roadmap/merge/index.md index 06cded798a0..e397b09fbbb 100644 --- a/public/content/translations/it/roadmap/merge/index.md +++ b/public/content/translations/it/roadmap/merge/index.md @@ -1,12 +1,12 @@ --- -title: La Fusione -description: 'Scopri La Fusione: quando la Rete principale di Ethereum ha adottato il Poof of stake.' +title: La fusione +description: "Scopri La Fusione: quando la Rete principale di Ethereum ha adottato il Poof of stake." lang: it template: upgrade image: /images/upgrades/merge.png alt: -summaryPoint1: La Rete Principale di Ethereum utilizza il proof-of-stake, ma non è sempre stato così. -summaryPoint2: L'aggiornamento dal meccanismo originale di proof-of-work al proof-of-stake, è stato detto La Fusione. +summaryPoint1: "La Rete Principale di Ethereum utilizza il proof-of-stake, ma non è sempre stato così." +summaryPoint2: "L'aggiornamento dal meccanismo originale di proof-of-work al proof-of-stake, è stato detto La Fusione." summaryPoint3: La Fusione si riferisce all'unione della Rete Principale di Ethereum con una blockchain di proof-of-stake separata, detta Beacon Chain, ora coesistenti come un'unica catena. summaryPoint4: La Fusione ha ridotto il consumo energetico di Ethereum di circa il 99,95%. --- @@ -17,17 +17,17 @@ summaryPoint4: La Fusione ha ridotto il consumo energetico di Ethereum di circa ## In cosa ha consistito la Fusione? {#what-is-the-merge} -La Fusione è stata l'unione del livello di esecuzione originale di Ethereum (la Rete principale che esisteva dalla [genesi](/ethereum-forks/#frontier)) con il suo nuovo livello di consenso di Proof of stake, la Beacon Chain. Ha eliminato la necessità di grandi quantità di energia richieste dal processo di mining, consentendo invece di proteggere la rete utilizzando l'ETH in staking. È stato un passo davvero emozionante nel realizzare la visione di Ethereum: maggiori scalabilità, sicurezza e sostenibilità. +La Fusione è stata l'unione del livello di esecuzione originale di Ethereum (la Rete Principale esistente dalla [genesi](/ethereum-forks/#frontier)) con il suo nuovo livello di consenso proof-of-stake, la Beacon Chain. Ha eliminato la necessità di grandi quantità di energia richieste dal processo di mining, consentendo invece di proteggere la rete utilizzando l'ETH in staking. È stato un passo davvero emozionante nel realizzare la visione di Ethereum: maggiori scalabilità, sicurezza e sostenibilità. -Inizialmente, la [Beacon Chain](/roadmap/beacon-chain/) veniva inviata separatamente dalla [Rete principale](/glossary/#mainnet). La Rete Principale di Ethereum, con tutti i suoi conti, saldi, contratti intelligenti e stati della blockchain, ha continuato a essere protetta dal [proof-of-work](/developers/docs/consensus-mechanisms/pow/), anche mentre la Beacon Chain veniva eseguita in parallelo, utilizzando il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). La Fusione si è verificata quando, finalmente, questi due sistemi si sono uniti e il Poof of Work è stata permanentemente sostituita dal Proof of stake. +Inizialmente, la [Beacon Chain](/roadmap/beacon-chain/) è stata distribuita separatamente dalla [Rete Principale](/glossary/#mainnet). La Rete Principale di Ethereum, con tutti i suoi conti, saldi, contratti intelligenti e stati della blockchain, ha continuato a essere protetta da [proof-of-work](/developers/docs/consensus-mechanisms/pow/), anche mentre la Beacon Chain veniva eseguita in parallelo utilizzando il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). La Fusione si è verificata quando, finalmente, questi due sistemi si sono uniti e il Poof of Work è stata permanentemente sostituita dal Proof of stake. Immagina Ethereum come una nave lanciata prima di essere pronta per un viaggio interstellare. Con la Beacon Chain, la community ha costruito un nuovo motore e uno scafo più resistente. Dopo test significativi, è arrivato il momento di scambiare il vecchio motore con quello nuovo durante il volo. Questo ha aggiunto il nuovo e più efficiente motore nella nave esistente, consentendole di percorrere diversi anni luce e conquistare l'universo. -## La fusione con la rete principale {#merging-with-mainnet} +## Fusione con la Rete Principale {#merging-with-mainnet} -La Proof of Work ha protetto la Rete rrincipale di Ethereum dalla genesi alla Fusione. Questo ha consentito alla blockchain di Ethereum a cui siamo tutti abituati di venire alla luce, a luglio 2015, con tutte le sue funzionalità familiari: transazioni, contratti intelligenti, conti, etc. +La Proof of Work ha protetto la Rete rrincipale di Ethereum dalla genesi alla Fusione. Questo ha consentito alla blockchain di Ethereum a cui siamo tutti abituati di venire alla luce nel luglio 2015 con tutte le sue funzionalità familiari: transazioni, contratti intelligenti, conti, ecc. Nella storia di Ethereum, gli sviluppatori si sono preparati per un'eventuale transizione dal Proof of Work al Proof of stake. Il 1° dicembre 2020, la Beacon Chain è stata creata come una blockchain separata dalla Rete principale, eseguita in parallelo. @@ -40,7 +40,7 @@ Con La Fusione, la cronologia non è andata perduta. Quando la Rete principale s -Questa transizione al Proof of stake ha cambiato il metodo di emissione dell'ether. Scopri di più sull'[emissione di ether prima e dopo La Fusione](/roadmap/merge/issuance/). +Questa transizione a proof-of-stake ha cambiato il modo in cui l'ether viene emesso. Scopri di più sull'[emissione di ether prima e dopo La Fusione](/roadmap/merge/issuance/). @@ -49,17 +49,17 @@ Questa transizione al Proof of stake ha cambiato il metodo di emissione dell'eth **La Fusione non ha modificato nulla per i detentori/utenti.** -_Vale la pena ripeterlo_: Come utente o detentore di ETH o di qualsiasi altra risorsa digitale su Ethereum, nonché come staker non operatore di nodo, **non devi fare nulla coi tuoi fondi o il tuo portafoglio per approcciare La Fusione.** Gli ETH sono sempre ETH. Non esiste nulla del tipo "vecchi ETH"/"nuovi ETH" o "ETH1"/"ETH2" e i portafogli funzioneranno esattamente allo stesso modo dopo La Fusione. Le persone che dicono altro sono probabilmente truffatori. +_Vale la pena ripeterlo_: come utente o detentore di ETH o di qualsiasi altra risorsa digitale su Ethereum, nonché come staker non operatore di nodo, **non devi fare nulla con i tuoi fondi o il tuo portafoglio in vista de La Fusione.** Gli ETH sono sempre ETH. Non esiste nulla del tipo "vecchi ETH"/"nuovi ETH" o "ETH1"/"ETH2" e i portafogli funzioneranno esattamente allo stesso modo dopo La Fusione. Le persone che dicono altro sono probabilmente truffatori. Nonostante il passaggio dal Proof of Work, l'intera cronologia di Ethereum dalla genesi è rimasta intatta e inalterata dalla transizione al Proof of stake. Qualsiasi fondo detenuto nel tuo portafoglio prima della Fusione è ancora accessibile dopo di essa. **Non è richiesta alcuna azione di aggiornamento da parte tua.** [Maggiori informazioni sulla sicurezza di Ethereum](/security/#eth2-token-scam) -### Operatori di nodi e sviluppatori di dapp {#node-operators-dapp-developers} +### Operatori di nodi e sviluppatori di dApp {#node-operators-dapp-developers} Gli elementi dell'azione chiave includono: @@ -74,26 +74,25 @@ Non impostare un `fee recipient` consentirà comunque al tuo validatore di compo Fino a La Fusione, un client di esecuzione (come Geth, Erigon, Besu o Nethermind) era sufficiente per ricevere, convalidare correttamente e propagare i blocchi oggetto di gossip dalla rete. _Dopo La Fusione_, la validità delle transazioni contenute in un payload di esecuzione dipende ora dalla validità del "blocco di consenso" in cui sono contenute. Di conseguenza, un nodo completo di Ethereum richiede ora sia un client di esecuzione che uno di consenso. Questi due client collaborano usando una nuova API Engine. L'API Engine richiede l'autenticazione usando un segreto JWT, fornito a entrambi i client, che consente la comunicazione sicura. -Gli elementi d'azione chiave includono: +Gli elementi dell'azione chiave includono: -- Installare un client di consenso oltre a un client di esecuzione -- Autenticare i client di esecuzione e di consenso con un segreto JWT condiviso, così che possano comunicare in sicurezza tra loro. +- Installa un client di consenso oltre a un client di esecuzione +- Autentica i client di esecuzione e di consenso con un segreto JWT condiviso, in modo che possano comunicare in sicurezza tra loro. Non completare i suddetti elementi farà sì che il tuo nodo risulti "offline", finché entrambi i livelli non saranno sincronizzati e autenticati. - La Fusione è stata accompagnata da modifiche al consenso, incluse anche modifiche relative a: @@ -102,27 +101,26 @@ La Fusione è stata accompagnata da modifiche al consenso, incluse anche modific
  • struttura del blocco
  • tempistiche spazio/blocco
  • modifiche ai codici operativi
    • -
  • fonti di casualità su catena on-chain
    • +
  • fonti di casualità on-chain
  • concetto di testa sicura e blocchi finalizzati
    • Per ulteriori informazioni, consulta questo post del blog di Tim Beiko su Come La Fusione Influenza il Livello d'Applicazione di Ethereum. -     ## La Fusione e il consumo energetico {#merge-and-energy} La Fusione ha segnato la fine del proof-of-work per Ethereum e ha dato inizio all’era di una rete Ethereum più sostenibile ed ecologica. Il consumo energetico di Ethereum si è ridotto di una stima del 99,95%, rendendo Ethereum una blockchain ecosostenibile. Scopri di più sul [consumo energetico di Ethereum](/energy-consumption/). -## La Fusione e il ridimensionamento {#merge-and-scaling} +## La Fusione e la scalabilità {#merge-and-scaling} -La Fusione ha inoltre gettato le basi per ulteriori aggiornamenti di scalabilità, impossibili sotto il Poof of Work, portando Ethereum un po' più vicina al raggiungimento della completa scalabilità, sicurezza e sostenibilità delinate nella [visione di Ethereum](/roadmap/vision/). +La Fusione ha anche preparato il terreno per ulteriori aggiornamenti di scalabilità non possibili con il proof-of-work, portando Ethereum un passo più vicino al raggiungimento della piena scala, sicurezza e sostenibilità previsti dalla sua [roadmap](/roadmap/). ## Equivoci su La Fusione {#misconceptions} +title="Equivoco: "Eseguire un nodo richiede di mettere in staking 32 ETH."" +contentPreview="Falso. Chiunque è libero di sincronizzare la propria copia autoverificata di Ethereum (cioè, eseguire un nodo). Non è richiesto alcun ETH, né prima de La Fusione, né dopo La Fusione, mai."> Esistono due tipi di nodi di Ethereum: i nodi che possono proporre blocchi e quelli che non possono. @@ -134,47 +132,43 @@ Eseguire un nodo che non produce blocchi è possibile per chiunque, in entrambi L'abilità per chiunque di gestire il proprio nodo è assolutamente essenziale per mantenere la decentralizzazione della rete di Ethereum. -[Ulteriori informazioni sull'esecuzione di un proprio nodo](/run-a-node/) - +[Maggiori informazione sull'esecuzione del proprio nodo](/run-a-node/) +title="Equivoco: "La Fusione non è riuscita a ridurre le commissioni sul gas."" +contentPreview="Falso. La Fusione è stata un cambio del meccanismo di consenso, non un'espansione della capacità della rete, e non è mai stata pensata per ridurre le commissioni sul gas."> Le commissioni del gas sono un prodotto della domanda di rete relativo alla capacità della rete. La Fusione ha reso obsoleto l'uso del Proof of Work, passando al Proof of stake per il consenso, ma non ha modificato significativamente alcun parametro che influenzi direttamente la capacità o il volume di rete. -Con una tabella di marcia incentrata sui rollup, gli sforzi si concentrano sul ridimensionamento delle attività degli utenti al [livello 2](/layer-2/), consentendo alla Rete Principale di Livello 1 di essere un livello di accordo decentralizzato e sicuro, ottimizzato per l'archiviazione dei dati dei rollup, per aiutare a rendere esponenzialmente più economiche le transazioni dei rollup. La transizione al Proof of stake è un precursore essenziale per realizzarlo. [Ulteriori informazioni su gas e commissioni.](/developers/docs/gas/) - +Con una tabella di marcia incentrata sui rollup, gli sforzi si concentrano sul ridimensionamento delle attività degli utenti al [livello 2](/layer-2/), consentendo alla Rete Principale di livello 1 di essere un livello di accordo decentralizzato e sicuro, ottimizzato per l'archiviazione dei dati dei rollup, per aiutare a rendere esponenzialmente più economiche le transazioni dei rollup. La transizione al Proof of stake è un precursore essenziale per realizzarlo. [Di più su gas e commissioni.](/developers/docs/gas/) -La "velocità" di una transazione è misurabile in diversi modi, incluso il tempo di inclusione in un blocco e il tempo alla finalizzazione. Entrambi cambiano lievemente, ma non in modo apprezzabile dagli utenti. +title="Equivoco: "Le transazioni sono state accelerate in modo sostanziale da La Fusione."" +contentPreview="Falso. Sebbene esistano alcune lievi modifiche, la velocità delle transazioni sul livello 1 è per lo più la stessa di prima de La Fusione."> +La "velocità" di una transazione può essere misurata in diversi modi, tra cui il tempo necessario per essere inclusa in un blocco e il tempo per la finalizzazione. Entrambi cambiano lievemente, ma non in modo apprezzabile dagli utenti. Storicamente, con il Poof of Work, l'obiettivo era avere un nuovo blocco ogni 13,3 secondi circa. Con il Poof of stake, gli slot si verificano precisamente ogni 12 secondi, e ciascuno rappresenta un'opportunità per un validatore di pubblicare un blocco. Gran parte degli slot contiene blocchi, ma non necessariamente tutti (cioè un validatore è offline). Nel Proof of stake, i blocchi sono prodotti a una frequenza del 10% circa maggiore che nel Proof of Work. Questo è stato un cambiamento abbastanza irrilevante ed è improbabile che sia notato dagli utenti. La Proof of stake ha introdotto il concetto di finalità della transazione che, precedentemente, non esisteva. Nel Proof of Work, la capacità di annullare un blocco diventa esponenzialmente più difficile all'aumentare dei blocchi minati su una transazione, ma non raggiunge mai lo zero. In modalità Proof of stake, i blocchi sono raggruppati in epoche (intervalli di 6,4 minuti contenenti 32 possibili blocchi), su cui votano i validatori. Quando termina un'epoca, i validatori votano se considerare l'epoca 'giustificata'. Se i validatori acconsentono a giustificare l'epoca, questa viene finalizzata nell'epoca successiva. Annullare le transazioni finalizzate è economicamente non redditizio, in quanto richiederebbe di ottenere e bruciare oltre un terzo dell'ETH in staking totale. - +title="Equivoco: "La Fusione ha abilitato i prelievi dello staking."" +contentPreview="Falso, ma i prelievi dello staking sono stati da allora abilitati tramite l'aggiornamento Shanghai/Capella."> Inizialmente, dopo La Fusione, gli staker potevano accedere soltanto alle mance delle commissioni e la MEV guadagnate come conseguenza delle proposte di blocchi. Queste ricompense sono accreditate a un conto non di staking, controllato dal validatore (noto come il destinatario della commissione) e sono immediatamente disponibili. Queste ricompense sono separate dalle ricompense del protocollo, per l'esecuzione dei doveri del validatore. Dall'aggiornamento della rete di Shanghai/Capella, gli staker possono ora designare un indirizzo di prelievo per iniziare a ricevere pagamenti automatici di qualsiasi saldo di staking in eccesso (ETH superiori a 32, da ricompense del protocollo). Questo aggiornamento, inoltre, ha consentito la capacità di un validatore di sbloccare e rivendicare l'intero saldo all'uscita dalla rete. -[Maggiori informazioni sui prelievi in staking](/staking/withdrawals/) - +[Di più sulle ricompense di staking](/staking/withdrawals/) -Quando l'aggiornamento di Shnanghai/Capella ha consentito i prelievi, i validatori sono stati incentivati a prelevare il proprio saldo di staking superiore a 32 ETH, poiché questi fondi non si sommano alla resa e sono altrimenti bloccati. A seconda dell'APR (determinato dagli ETH in staking totali), potrebbero esser incentivati a uscire dai loro validatori per rivendicare il proprio saldo per intero o metterne potenzialmente in staking persino di più usando le proprie ricompense per ottenere maggiori rendimenti. +contentPreview="Falso. Le uscite dei validatori sono limitate per motivi di sicurezza."> +Da quando l'aggiornamento Shanghai/Capella ha abilitato i prelievi, i validatori sono incentivati a prelevare il loro saldo di staking superiore a 32 ETH, poiché questi fondi non si aggiungono al rendimento e sono altrimenti bloccati. A seconda dell'APR (determinato dagli ETH in staking totali), potrebbero esser incentivati a uscire dai loro validatori per rivendicare il proprio saldo per intero o metterne potenzialmente in staking persino di più usando le proprie ricompense per ottenere maggiori rendimenti. Un importante avvertimento, qui, le uscite dei validatori completi sono limitate in tasso dal protocollo e soltanto un certo numero di validatori può uscire, per ogni epoca (ogni 6,4 minuti). Questo limite fluttua a second del numero di validatori attivi, ma equivale, all'incirca, allo 0,33% degli ETH in staking totali, che possono uscire dalla rete in un singolo giorno. @@ -183,7 +177,7 @@ Ciò impedisce un esodo di massa dei fondi in staking. Inoltre, previene che un L'APR, inoltre, è intenzionalmente dinamico, consentendo a un mercato di staker di bilanciare quanto desiderano essere pagati per contribuire alla protezione della rete. Se il tasso è troppo basso, i validatori usciranno a un tasso limitato dal protocollo. Questo porterà gradualmente all'aumento dell'APR per chiunque rimanga, attirando staker nuovi o di ritorno. -## Cos'è successo a 'Eth2'? {#eth2} +## Che è successo a 'Eth2?' {#eth2} Il termine 'Eth2' è stato superato. Dopo aver fuso 'Eth1' ed 'Eth2' in una singola catena, non vi è più alcun bisogno di distinguere tra le due reti di Ethereum; esiste solo Ethereum. @@ -194,7 +188,7 @@ Per limitare la confusione, la community ha aggiornato questi termini: Questi aggiornamenti della terminologia cambiano solo le convenzioni di nomenclatura, senza alterare gli obiettivi né la tabella di marcia di Ethereum. -[Scopri di più sulla rinominazione di 'Eth2'](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/) +[Scopri di più sulla ridenominazione di "Eth2"](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/) ## Relazione tra gli aggiornamenti {#relationship-between-upgrades} @@ -202,23 +196,23 @@ Gli aggiornamenti di Ethereum sono tutti in qualche modo interconnessi. Quindi, ### La Fusione e la Beacon Chain {#merge-and-beacon-chain} -La Fusione rappresenta l'adozione formale della Beacon Chain come nuovo livello di consenso al livello di esecuzione originale della Rete principale. A partire dalla Fusione, i validatori sono assegnati alla Rete principale sicura di Ethereum e il mining su [Proof of Work](/developers/docs/consensus-mechanisms/pow/) non è più un mezzo valido di produzione di blocchi. +La Fusione rappresenta l'adozione formale della Beacon Chain come nuovo livello di consenso al livello di esecuzione originale della Rete principale. Dopo La Fusione, i validatori sono assegnati a proteggere la Rete Principale di Ethereum e il mining su [proof-of-work](/developers/docs/consensus-mechanisms/pow/) non è più un mezzo valido per la produzione di blocchi. I blocchi sono invece proposti dai nodi di convalida, che ottengono ETH in staking in cambio del diritto di partecipare al consenso. Questi aggiornamenti stabiliscono le basi per gli aggiornamenti di scalabilità futuri, incluso lo sharding. - La beacon chain + La Beacon Chain ### La Fusione e l'aggiornamento di Shanghai {#merge-and-shanghai} Per poter semplificare e massimizzare l'attenzione sulla riuscita della transizione al Proof of stake, l'aggiornamento de La Fusione non ha incluso alcune funzionalità annunciate, come la possibilità di prelevare gli ETH in staking. Questa funzionalità è stata abilitata separatamente, con l'aggiornamento di Shanghai/Capella. -Per i curiosi, scoprite di più su [Cosa succede dopo la Fusione](https://youtu.be/7ggwLccuN5s?t=101), presentato da Vitalik all'evento ETHGlobal di aprile 2021. +Per i curiosi, scopri di più su [Cosa succede dopo La Fusione](https://youtu.be/7ggwLccuN5s?t=101), presentato da Vitalik all'evento ETHGlobal di aprile 2021. ### La Fusione e lo sharding {#merge-and-data-sharding} -Originariamente, il piano prevedeva di lavorare allo sharding prima della Fusione per risolvere la questione della scalabilità. Tuttavia, con il boom delle [soluzioni di ridimensionamento del livello 2](/layer-2/), la priorità si è spostata sul passaggio dal Proof of Work al Proof of stake. +Originariamente, il piano prevedeva di lavorare allo sharding prima della Fusione per risolvere la questione della scalabilità. Tuttavia, con il boom delle [soluzioni di ridimensionamento del livello 2](/layer-2/), la priorità si è spostata sul passaggio da proof-of-work a proof-of-stake. I piani per lo sharding si stanno evolvendo rapidamente, ma data la nascita e il successo delle tecnologie di livello 2 per scalare l'esecuzione delle transazioni, i piani per lo sharding hanno spostato l'attenzione sul trovare il modo ottimale per distribuire il carico per memorizzare i dati di chiamata compressi dai contratti di rollup, consentendo la crescita esponenziale della capacità di rete. Questo sarebbe impossibile senza prima passare al Proof of stake. diff --git a/public/content/translations/it/roadmap/merge/issuance/index.md b/public/content/translations/it/roadmap/merge/issuance/index.md index 78a1aeb7528..998ddc946a5 100644 --- a/public/content/translations/it/roadmap/merge/issuance/index.md +++ b/public/content/translations/it/roadmap/merge/issuance/index.md @@ -4,117 +4,117 @@ description: Analisi dell'impatto de La Fusione sull'offerta di ETH lang: it --- -# In che modo La Fusione ha influenzato l'offerta di ETH {#how-the-merge-impacts-ETH-supply} +# In che modo La Fusione ha influito sull'offerta di ETH {#how-the-merge-impacts-ETH-supply} -La Fusione ha rappresentato la transizione delle reti di Ethereum dal proof-of-work al proof-of-stake, verificatasi a settembre 2022. Il metodo di emissione degli ETH ha subito delle modifiche al momento di tale transizione. Precedentemente, i nuovi ETH erano emessi da due fonti: il livello d'esecuzione (cioè la Rete Principale) e il livello di consenso (cioè La Beacon Chain). Da La Fusione, l'emissione sul livello d'esecuzione è ora pari a zero. Analizziamolo. +La Fusione ha rappresentato la transizione della rete Ethereum da proof-of-work a proof-of-stake, avvenuta nel settembre 2022. Il metodo di emissione degli ETH ha subito delle modifiche al momento di tale transizione. In precedenza, i nuovi ETH venivano emessi da due fonti: il livello di esecuzione (ossia, la Rete Principale) e il livello di consenso (ossia, la Beacon Chain). Da La Fusione, l'emissione sul livello d'esecuzione è ora pari a zero. Analizziamolo. ## Componenti dell'emissione di ETH {#components-of-eth-issuance} Possiamo spezzare la fornitura di ETH in due forze principali: emissione e bruciatura. -L'**emissione** di ETH è il procedimento di creazione di ETH, che precedentemente non esisteva. La **bruciatura** di ETH è quando gli ETH esistenti vengono distrutti, rimuovendoli dalla circolazione. Il tasso di emissione e bruciatura viene calcolato su diversi parametri e, il saldo tra di essi, determina il tasso di inflazione/deflazione di ether risultante. +L'**emissione** di ETH è il processo di creazione di ETH che in precedenza non esisteva. La **bruciatura** di ETH si verifica quando degli ETH esistenti vengono distrutti, rimuovendoli dalla circolazione. Il tasso di emissione e bruciatura viene calcolato su diversi parametri e, il saldo tra di essi, determina il tasso di inflazione/deflazione di ether risultante. - -- Prima di passare al proof of stake, i miner emettevano approssimativamente 13.000ETH/giorno -- Gli staker emettono approssimativamente 1.700 ETH/giorno, sulla base di un totale di circa 14 milioni di ETH in staking -- L'emissione di staking esatta fluttua a seconda dell'importo totale di ETH in staking -- **Da La Fusione, restano approssimativamnte soltanto 1.700 ETH/giorno, riducendo la nuova emissione totale di ETH di circa l'88%** -- La bruciatura: questa, fluttua secondo la domanda di rete. _Se_ per un dato giorno si osserva un prezzo di gas medio di almeno 16 gwei, questo compensa effettivamente i circa 1.700 ETH emessi ai validatori e porta l'inflazione netta di ETH a zero, o meno, per quel giorno. +title="Emissione di ETH in breve"> +- Prima della transizione al proof-of-stake, ai miner venivano emessi circa 13.000 ETH/giorno +- Agli staker vengono emessi circa 1.700 ETH/giorno, sulla base di circa 14 milioni di ETH totali messi in staking +- L'emissione esatta da staking fluttua in base all'importo totale di ETH messi in staking +- **Da La Fusione, rimangono solo i ~1.700 ETH/giorno, riducendo l'emissione totale di nuovi ETH di circa l'88%** +- La bruciatura: fluttua in base alla domanda della rete. _Se_ per un dato giorno si osserva un prezzo di gas medio di almeno 16 gwei, questo compensa effettivamente i circa 1.700 ETH emessi ai validatori e porta l'inflazione netta di ETH a zero, o meno, per quel giorno. ## Pre-Fusione (storico) {#pre-merge} -### Emissione del livello d'esecuzione {#el-issuance-pre-merge} +### Emissione del livello di esecuzione {#el-issuance-pre-merge} -Sotto il proof of work, i miner interagivano soltanto con il livello d'esecuzione, venendo ricompensati con ricompense dei blocchi, se erano i primi a risolvere il blocco successivo. Dall'[aggiornamento di Costantinopoli](/ethereum-forks/#constantinople) nel 2019, questa ricompensa era di 2 ETH per blocco. I miner, inoltre, erano ricompensati per la pubblicazione di blocchi [ommer](/glossary/#ommer), blocchi validi che non finivano nella catena più lunga/canonica. Queste ricompense erano massimizzate a 1,75 ETH per ommer ed erano _da sommarsi_ alla ricompensa emessa dal blocco canonico. Il processo di mining era un'attività economicamente intensiva che, storicamente, richiedeva elevati livelli di emissione di ETH per essere sostenuta. +Sotto il proof of work, i miner interagivano soltanto con il livello d'esecuzione, venendo ricompensati con ricompense dei blocchi, se erano i primi a risolvere il blocco successivo. Dall'[aggiornamento Constantinople](/ethereum-forks/#constantinople) del 2019 questa ricompensa era di 2 ETH per blocco. I miner erano anche ricompensati per la pubblicazione di blocchi [ommer](/glossary/#ommer), che erano blocchi validi che non finivano nella catena più lunga/canonica. Queste ricompense avevano un massimo di 1,75 ETH per ommer ed erano _in aggiunta_ alla ricompensa emessa dal blocco canonico. Il processo di mining era un'attività economicamente intensiva che, storicamente, richiedeva elevati livelli di emissione di ETH per essere sostenuta. -### Emissione del livello del consenso {#cl-issuance-pre-merge} +### Emissione del livello di consenso {#cl-issuance-pre-merge} -La [Beacon Chain](/ethereum-forks/#beacon-chain-genesis) è stata attivata nel 2020. Invece dei miner, è protetta dai validatori, che utilizzano il proof of stake. Questa catena è stata avviata dagli utenti di Ethereum, che depositavano ETH a senso unico in uno smart contract sulla Rete Principale (il livello d'esecuzione), ascoltato dalla Beacon Chain, accreditando l'utente con un importo equivalente di ETH, sulla nuova catena. Fino alla Fusione, i validatori della Beacon Chain non stavano elaborando le transazioni e, fondamentalmente, arrivavano al consenso sullo stato dello stesso gruppo di validatori. +La [Beacon Chain](/ethereum-forks/#beacon-chain-genesis) è diventata operativa nel 2020. Invece dei miner, è protetta dai validatori, che utilizzano il proof of stake. Questa catena è stata avviata dagli utenti di Ethereum, che depositavano ETH a senso unico in uno smart contract sulla Rete Principale (il livello d'esecuzione), ascoltato dalla Beacon Chain, accreditando l'utente con un importo equivalente di ETH, sulla nuova catena. Fino alla Fusione, i validatori della Beacon Chain non stavano elaborando le transazioni e, fondamentalmente, arrivavano al consenso sullo stato dello stesso gruppo di validatori. -I validatori sulla Beacon Chain sono ricompensati con ETH per l'attestazione allo stato della catena e la proposta di blocchi. Le ricompense (o penalità) sono calcolate e distribuite a ogni epoca (ogni 6,4 minuti) a seconda delle prestazioni del validatore. Le ricompense del validatore sono **significativamente** inferiori a quelle di mining, emesse precedentemente sotto il proof-of-work (pari a 2 ETH circa ogni 13,5 secondi), poiché l'operazione di un nodo di convalida non è altrettanto intenso dal punto di vista economico e quindi non richiede né garantisce una ricompensa altrettanto elevata. +I validatori sulla Beacon Chain sono ricompensati con ETH per l'attestazione allo stato della catena e la proposta di blocchi. Le ricompense (o penalità) sono calcolate e distribuite a ogni epoca (ogni 6,4 minuti) a seconda delle prestazioni del validatore. Le ricompense dei validatori sono **significativamente** inferiori a quelle del mining emesse in precedenza con il proof-of-work (2 ETH ogni ~13,5 secondi), poiché la gestione di un nodo di convalida non è così intensa dal punto di vista economico e quindi non richiede né garantisce una ricompensa così alta. -### Analisi sulle emissioni pre-Fusione {#pre-merge-issuance-breakdown} +### Suddivisione dell'emissione pre-Fusione {#pre-merge-issuance-breakdown} -Offerta totale di ETH: **circa 120.520.000 ETH** (al momento della Fusione a settembre 2022) +Offerta totale di ETH: **~120.520.000 ETH** (al momento de La Fusione, a settembre 2022) **Emissione del livello d'esecuzione:** -- Era stimata a 2,08 ETH ogni 13,3 secondi\*: **circa 4.930.000** ETH emessi in un anno -- Il risultato è un tasso d'inflazione **di circa il 4,09%** (4,93M l'anno / 120,5M totali) -- \*Ciò include i 2 ETH per blocco canonico, più una media di 0,08 ETH nel tempo dai blocchi ommer. Inoltre, utilizza 13,3 secondi, l'obiettivo temporale di base del blocco senza alcuna influenza da una [bomba di difficoltà](/glossary/#difficulty-bomb). ([Vedi fonte](https://bitinfocharts.com/ethereum/)) +- Era stimata a 2,08 ETH ogni 13,3 secondi\*: **~4.930.000** ETH emessi in un anno +- Ha comportato un tasso di inflazione di **circa il 4,09%** (4,93 mln all'anno / 120,5 mln totali) +- \*Ciò include i 2 ETH per blocco canonico, più una media di 0,08 ETH nel tempo dai blocchi ommer. Usa anche 13,3 secondi, l'obiettivo di tempo del blocco di base senza alcuna influenza da parte di una [bomba di difficoltà](/glossary/#difficulty-bomb). ([Vedi la fonte](https://bitinfocharts.com/ethereum/)) **Emissione del livello d'esecuzione:** -- Utilizzando i 14.000.000 di ETH totali in staking, il tasso di emissione di ETH è approssimativamente di 1700 ETH/giorno ([Vedi fonte](https://ultrasound.money/)) -- Il risultato è **circa 620.500** ETH emessi in un anno -- Il risultato è un tasso d'inflazione **approssimativamente dello 0,52%** (620.5K l'anno / 119.3M totali) +- Utilizzando un totale di 14.000.000 di ETH in staking, il tasso di emissione di ETH è di circa 1700 ETH/giorno ([Vedi la fonte](https://ultrasound.money/)) +- Risulta in **~620.500** ETH emessi in un anno +- Ha comportato un tasso di inflazione di **circa lo 0,52%** (620,5K all'anno / 119,3 mln totali) -**Tasso di emissione annualizzato totale (pre-Fusione): circa 4,61%** (4,09% + 0,52%) +**Tasso di emissione annualizzato totale (pre-Fusione): ~4,61%** (4,09% + 0,52%) -**Circa l'88,7%** dell'emissione andava ai miner sul livello d'esecuzione (4,09 / 4,61 * 100) +**~88,7%** dell'emissione era destinata ai miner sul livello di esecuzione (4,09 / 4,61 \* 100) -**Circa l'11,3%** era emesso agli staker sul livello del consenso (0,52 / 4,61 * 100) +**~11,3%** veniva emesso agli staker sul livello di consenso (0,52 / 4,61 \* 100) ## Post-Fusione (oggi) {#post-merge} -### Emissione del livello d'esecuzione {#el-issuance-post-merge} +### Emissione del livello di esecuzione {#el-issuance-post-merge} -L'emissione del livello d'esecuzione dalla Fusione è pari a zero. Il proof-of-work non è più un mezzo valido per la produzione di blocchi, secondo le regole aggiornate del consenso. Tutta l'attività del livello d'esecuzione è impacchettata nei "blocchi della Beacon", pubblicati e attestati dai validatori del proof-of-stake. Le ricompense per l'attestazione e pubblicazione dei blocchi della Beacon sono considerate separatamente sul livello del consenso. +L'emissione del livello di esecuzione da La Fusione è pari a zero. Il proof-of-work non è più un mezzo valido per la produzione di blocchi secondo le regole aggiornate del consenso. Tutte le attività del livello di esecuzione sono impacchettate in "blocchi beacon", pubblicati e attestati dai validatori proof-of-stake. Le ricompense per l'attestazione e la pubblicazione dei blocchi beacon sono contabilizzate separatamente sul livello di consenso. -### Emissione del livello del consenso {#cl-issuance-post-merge} +### Emissione del livello di consenso {#cl-issuance-post-merge} -L'emissione del livello di consenso continua ad oggi, così come prima della Fusione, con piccole ricompense per i validtori che attestano a e propongono i blocchi. Le ricompense dei validatori continuano a maturare ai _saldi dei validatori_, gestiti nel livello del consenso. A differenza dei conti correnti (conti di "esecuzione"), che possono effettuare transazioni sulla Rete Principale, questi conti separati di Ethereum non possono operare liberamente con altri conti di Ethereum. I fondi in questi conti sono prelevabili esclusivamente a un singolo indirizzo d'esecuzione specificato. +L'emissione del livello di consenso continua oggi come prima de La Fusione, con piccole ricompense per i validatori che attestano e propongono i blocchi. Le ricompense dei validatori continuano ad accumularsi nei _saldi dei validatori_ gestiti all'interno del livello di consenso. A differenza dei conti correnti (conti di "esecuzione"), che possono effettuare transazioni sulla Rete Principale, questi conti Ethereum separati non possono effettuare liberamente transazioni con altri conti Ethereum. I fondi presenti in questi conti possono essere prelevati solo a un singolo indirizzo di esecuzione specificato. -Dall'aggiornamento di Shanghai/Capella, avvenuto ad aprile 2023, questi prelievi sono stati consentiti per gli staker. Gli staker sono incentivati a rimuovere i propri _guadagni/ricompense (per saldi superiori a 32 ETH)_, poiché, tali fondi non contribuirebbero altrimenti al loro peso di staking (che si massimizza a 32 ETH). +Dall'aggiornamento Shanghai/Capella, avvenuto nell'aprile 2023, questi prelievi sono stati abilitati per gli staker. Gli staker sono incentivati a rimuovere i loro _guadagni/ricompense (saldo superiore a 32 ETH)_ poiché questi fondi altrimenti non contribuiscono al loro peso di stake (che ha un massimo di 32). -Gli staker, inoltre, potrebbero scegliere di uscire e prelevare l'intero saldo del loro validatore. Per assicurare la stabilità di Ethereum, il numero di validatori in uscita simultanea è limitato. +Gli staker possono anche scegliere di uscire e prelevare l'intero saldo del loro validatore. Per garantire la stabilità di Ethereum, il numero di validatori che escono simultaneamente è limitato. -Approssimativamente lo 0,33% del conteggio totale dei validatori può uscire in un dato giorno. Di default, possono uscire quattro (4) validatori per epoca (ogni 6,4 minuti, o 900 al giorno). Un (1) validatore aggiuntivo può uscire per ogni 65.536 (216) validatori aggiuntivi su 262.144 (218). Ad esempio, con oltre 327.680 validatori, potrebbero uscirne cinque (5) per epoca (1.125 al giorno). Sei (6) sarebbero autorizzati con un conteggio di validatori attivi totali superiore a 393.216 e così via. +Circa lo 0,33% del numero totale di validatori può uscire in un dato giorno. Per impostazione predefinita, quattro (4) validatori possono uscire per epoca (ogni 6,4 minuti, o 900 al giorno). Un (1) validatore aggiuntivo può uscire per ogni 65.536 (216) validatori aggiuntivi oltre i 262.144 (218). Ad esempio, con oltre 327.680 validatori, cinque (5) possono uscire per epoca (1.125 al giorno). Sei (6) saranno ammessi con un conteggio totale di validatori attivi superiore a 393.216, e così via. -All'aumentare del numero di validatori che prelevano, il numero massimo di validatori in uscita sarà ridotto gradualmente a un minimo di quattro, per evitare intenzionalmente che vengano prelevati contemporaneament egrandi quantitativi destabilizzanti di ETH in staking. +Man mano che più validatori prelevano, il numero massimo di validatori in uscita sarà gradualmente ridotto a un minimo di quattro per impedire intenzionalmente che grandi quantità destabilizzanti di ETH in staking vengano prelevate contemporaneamente. -### Analisi dell'inflazione post-Fusione {#post-merge-inflation-breakdown} +### Suddivisione dell'inflazione post-Fusione {#post-merge-inflation-breakdown} -- Offerta totale di ETH: **circa 120.520.000 ETH** (al momento della Fusione a settembre 2022) -- Emissione del livello d'esecuzione: **0** -- Emissione del livello di consenso: come sopra, tasso di emissione annualizzato **approssimativo dello 0,52%** (con 14 milioni di ETH in staking totali) +- Offerta totale di ETH: **~120.520.000 ETH** (al momento de La Fusione, a settembre 2022) +- Emissione del livello di esecuzione: **0** +- Emissione del livello di consenso: come sopra, tasso di emissione annualizzato di **~0,52%** (con 14 milioni di ETH totali in staking) -Tasso di emissione annualizzato totale: **circa 0,52%** +Tasso di emissione annualizzato totale: **~0,52%** -Riduzione netta nell'emissione annuale di ETH: **circa 88,7%** ((4,61%-0,52%) / 4,61% * 100) +Riduzione netta dell'emissione annuale di ETH: **~88,7%** ((4,61% - 0,52%) / 4,61% \* 100) -## La bruciatura {#the-burn} +##  La bruciatura {#the-burn} -La forza opposta all'emissione di ETH è il tasso a cui gli ETH sono bruciati. Per l'esecuzione di una transazione su Ethereum, dev'essere pagata una commissione minima (nota come "commissione di base"), che fluttua continuamente (da blocco a blocco), a seconda dell'attività di rete. La commissione è pagata in ETH ed è _necessaria_ affinché la transazione sia considerata valida. Questa commissione viene _bruciata_ durante il procedimento della transazione, rimuovendola dalla circolazione. +La forza opposta all'emissione di ETH è il tasso a cui gli ETH sono bruciati. Per l'esecuzione di una transazione su Ethereum, dev'essere pagata una commissione minima (nota come "commissione di base"), che fluttua continuamente (da blocco a blocco), a seconda dell'attività di rete. La commissione è pagata in ETH ed è _necessaria_ perché la transazione sia considerata valida. Questa commissione viene _bruciata_ durante il processo di transazione, rimuovendola dalla circolazione. -La bruciatura delle commissioni è divenuta attiva con l'[aggiornamento di Londra](/ethereum-forks/#london) ad agosto 2021 e resta immutata da La Fusione. + +La bruciatura delle commissioni è stata introdotta con l'[aggiornamento London](/ethereum-forks/#london) nell'agosto del 2021 e da La Fusione è rimasta invariata. Oltre alla bruciatura della commissione, implementata dall'aggiornamento di Londra, i validatori, inoltre, possono incorrere in sanzioni per essere online o, peggio, possono ricevere tagli per l'infrazione di regole specifiche che minacciano la sicurezza della rete. Queste, risultano in una riduzione degli ETH dal saldo di quel validatore, che non è ricompensato direttamente a nessun altro conto, bruciandoli/rimuovendoli effettivamente dalla circolazione. -### Calcolare il prezzo medio del gas per la deflazione {#calculating-average-gas-price-for-deflation} +### Calcolo del prezzo medio del gas per la deflazione {#calculating-average-gas-price-for-deflation} Come discusso sopra, l'importo di ETH emessi in un dato giorno dipende dagli ETH in staking totali. Al momento della scrittura, questo equivale a circa 1700 ETH/giorno. @@ -124,26 +124,26 @@ Per determinare il prezzo medio del gas necessario a compensare completamente ta - `(5 blocchi/minuto) * (60 minuti/ora) = 300 blocchi/ora` - `(300 blocchi/ora) * (24 ore/giorno) = 7200 blocchi/giorno` -Ogni blocco indirizza `15x10^6 gas/blocco` ([di più sul gas](/developers/docs/gas/)). Utilizzandolo, possiamo risolvere per il prezzo medio del gas (in unità di gwei/gas), necessario per compensare l'emissione, data un'emissione totale giornaliera di 1700 ETH: +Ogni blocco ha come obiettivo `15x10^6 gas/blocco` ([maggiori informazioni sul gas](/developers/docs/gas/)). Utilizzandolo, possiamo risolvere per il prezzo medio del gas (in unità di gwei/gas), necessario per compensare l'emissione, data un'emissione totale giornaliera di 1700 ETH: -- `7200 blocchi/giorno * 15x10^6 gas/blocco *`**`Y gwei/gas`**`* 1 ETH/ 10^9 gwei = 1700 ETH/giorno` +- `7200 blocchi/giorno * 15x10^6 gas/blocco * `**`Y gwei/gas`**` * 1 ETH/ 10^9 gwei = 1700 ETH/giorno` Risolvendo per `Y`: -- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (arrotondando soltanto alle due cifre significative) +- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (arrotondando a due sole cifre significative) -Un altro metodo per riorganizzare questo ultimo passaggio sarebbe sostituire `1700` con una variabile `X` che rappresenti l'emissione giornaliera di ETH e semplificare il resto a: +Un altro modo per riorganizzare questo ultimo passaggio sarebbe sostituire `1700` con una variabile `X` che rappresenta l'emissione giornaliera di ETH e semplificare il resto in: - `Y = (X(10^3)/(7200 * 15)) = X/108` -Possiamo semplificarlo e scriverlo come una funzione di `X`: +Possiamo semplificare e scrivere questo come una funzione di `X`: -- `f(X) = X/108` dove `X` è l'emissione giornaliera di ETH, e `f(X)` rappresenta il prezzo di gwei/gas necessario per compensare tutti i nuovi ETH emessi. +- `f(X) = X/108` dove `X` è l'emissione giornaliera di ETH e `f(X)` rappresenta il prezzo in gwei/gas richiesto per compensare tutti gli ETH di nuova emissione. -Quindi, ad esempio, se `X` (emissione giornaliera di ETH) sale a 1800 secondo gli ETH totali in staking, `f(X)` (gwei necessari per compensare tutta l'emissione) sarebbe `17 gwei` (utilizzando le 2 cifre significative) +Quindi, per esempio, se `X` (emissione giornaliera di ETH) sale a 1800 in base al totale di ETH in staking, `f(X)` (i gwei richiesti per compensare tutta l'emissione) sarebbe allora di `17 gwei` (usando 2 cifre significative) -## Ulteriori letture {#further-reading} +## Letture consigliate {#further-reading} -- [La fusione](/roadmap/merge/) +- [La Fusione](/roadmap/merge/) - [Ultrasound.money](https://ultrasound.money/) - _Pannelli di controllo disponibili per visualizzare l'emissione e la bruciatura di ETH in tempo reale_ -- [Rilevare l'Emissione di Ethereum](https://www.attestant.io/posts/charting-ethereum-issuance/) - _Jim McDonald 2020_ +- [Grafici sull'emissione di Ethereum](https://www.attestant.io/posts/charting-ethereum-issuance/) - _Jim McDonald 2020_ diff --git a/public/content/translations/it/roadmap/pbs/index.md b/public/content/translations/it/roadmap/pbs/index.md index 4b0b292c707..aff397255d0 100644 --- a/public/content/translations/it/roadmap/pbs/index.md +++ b/public/content/translations/it/roadmap/pbs/index.md @@ -1,12 +1,12 @@ --- title: Separazione proponente-sviluppatore -description: Scopri come e perché i validatori di Ethereum divideranno le proprie responsabilità di costruzione e trasmissione dei blocchi. +description: "Scopri come e perché i validatori di Ethereum divideranno le proprie responsabilità di costruzione e trasmissione dei blocchi." lang: it --- -# Separazione proponente-sviluppatore {#proposer-builder-separation} +# Separazione propositore-costruttore {#proposer-builder-separation} -I validatori odierni di Ethereum creano _e_ trasmettono i blocchi. Raggruppano le transazioni che hanno sentito nella rete di gossip e le impacchettano in un blocco, inviato ai pari sulla rete di Ethereum. La **separazione tra propositore e costruttore (PBS)** divide queste mansioni tra più validatori. I costruttori di blocchi diventano responsabili della creazione dei blocchi e li offrono al propositore di blocchi, in ogni spazio. Il propositore di blocchi non può visualizzare i contenuti del blocco, semplicemente, sceglie il più profittevole, pagando una commissione al suo costruttore, prima di inviarlo i suoi pari. +I validatori odierni di Ethereum creano _e_ trasmettono i blocchi. Raggruppano le transazioni che hanno sentito nella rete di gossip e le impacchettano in un blocco, inviato ai pari sulla rete di Ethereum. **La separazione propositore-costruttore (PBS)** divide queste mansioni tra più validatori. I costruttori di blocchi diventano responsabili della creazione dei blocchi e li offrono al propositore di blocchi, in ogni spazio. Il propositore di blocchi non può visualizzare i contenuti del blocco, semplicemente, sceglie il più profittevole, pagando una commissione al suo costruttore, prima di inviarlo i suoi pari. Questo è un aggiornamento importante per svariati motivi. Primo, crea opportunità per prevenire la censura delle transazioni al livello del protocollo. Secondo, impedisce ai validatori hobbisti di essere "battuti" dalla concorrenza di utenti istituzionali, che possono meglio ottimizzare la redditività della costruzione del proprio blocco. Terzo, aiuta a ridimensionare Ethereum, consentendo gli aggiornamenti di Danksharding. @@ -16,17 +16,16 @@ La separazione dei costruttori e propositori di blocchi complica per i costrutto Ad esempio, possono essere introdotti degli elenchi di inclusione, così che quando i validatori entrano a conoscenza delle transazioni ma non le vedono incluse nei blocchi, possono imporle come necessarie nel blocco successivo. L'elenco di inclusione è generato dal mempool locale dei propositori di blocchi (l'elenco di transazioni di cui sono a conoscenza) ed è inviato ai loro pari, poco prima che un blocco sia proposto. Se una delle transazioni dall'elenco di inclusione è mancante, il propositore potrebbe rifiutare il blocco, aggiungere le transazioni mancanti prima di proporle o proporle e far sì che siano rifiutate dagli altri validatori, quando la ricevono. Inoltre, esiste una versione potenzialmente più efficiente di questa idea, che afferma che i costruttori devono utilizzare completamente lo spazio disponibile del blocco e, altrimenti, le transazioni sono aggiunte dall'elenco di inclusione del propositore. Questa è ancora un'area di ricerca attiva e la configurazione ottimale per gli elenchi di inclusione non è ancora stata determinata. -I [mempool crittografati](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3), inoltre, potrebbero rendere impossibile per costruttori e propositori, sapere quali transazioni stiano includendo in un blocco, dopo che questo è già stato trasmesso. +[I mempool crittografati](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) potrebbero anche rendere impossibile per i costruttori e i propositori sapere quali transazioni stanno includendo in un blocco, finché il blocco non è stato già trasmesso. - + Potenti organizzazioni possono spingere i validatori a censurare le transazioni da o verso certi indirizzi. I validatori si conformano a tale pressione rilevando gli indirizzi nella lista nera del proprio gruppo di transazioni e omettendoli dai blocchi che propongono. Dopo la PBS, non sarà più possibile poiché i propositori di blocchi non sapranno quali transazioni stanno trasmettendo nei propri blocchi. Potrebbe essere importante, per certi individui o app, conformarsi alle regole di censura, ad esempio, quando è emanata una legge nella loro regione. In tali casi, la conformità si verifica a livello di applicazione, mentre il protocolo rimane privo di permessi e di censura. - ## PBS e MEV {#pbs-and-mev} -Il **Valore Massimo Estraibile (MEV)** fa riferimento ai validatori che massimizzano la propria redditività, ordinando favorevolmente le transazioni. Esempi comuni includono gli scambi di arbitraggio sulle piattaforme di scambio decentralizzate (es. frontrunning di una grande vendita o un grande acquisto) o identificazione di opportunità per liquidare posizioni della DeFi. La massimizzazione del MEV richiede conoscenze tecniche sofisticate e software personalizzati aggiunti ai normali validatori, rendendo più probabile che gli operatori istituzionali surclassino i validatori individuali e hobbisti all'estrazione del MEV. Ciò significa che i rendimenti da staking potrebbero essere maggiori con operatori centralizzati, creando una forza centralizzante che disincentiva lo staking domestico. +**Il valore massimo estraibile (MEV)** si riferisce ai validatori che massimizzano la loro redditività ordinando favorevolmente le transazioni. Esempi comuni includono l'arbitraggio di swap su exchange decentralizzati (ad es., il frontrunning di una grande vendita o acquisto) o l'identificazione di opportunità per liquidare posizioni DeFi. La massimizzazione del MEV richiede conoscenze tecniche sofisticate e software personalizzati aggiunti ai normali validatori, rendendo più probabile che gli operatori istituzionali surclassino i validatori individuali e hobbisti all'estrazione del MEV. Ciò significa che i rendimenti da staking potrebbero essere maggiori con operatori centralizzati, creando una forza centralizzante che disincentiva lo staking domestico. La PBS risolve questo problema, riconfigurando l'economia del MEV. Invece del propositore di blocchi che svolge la propria ricerca del MEV seleziona semplicement eun blocco fra i tanti che gli vengono offerti dai costruttori di blocchi. I costruttori di blocchi potrebbero aver compiuto una sofisticata estrazione del MEV, ma la ricompensa va al propositore di blocchi. Ciò significa che, anche se un piccolo gruppo di costruttori di blocchi specializzati domina l'estrazione del MEV, la ricompensa potrebbe andare a qualsiasi validatore sulla rete, inclusi gli staker domestici in solo. @@ -37,15 +36,15 @@ Gli individui potrebbero essere incentivati a mettere in staking in gruppo, piut ## PBS e Danksharding {#pbs-and-danksharding} -Il danksharding è come Ethereum si ridimensionerà a circa 100.000 transazioni al secondo e minimizzerà le commissioni per gli utenti dei rollup. Si affida alla PBS poiché si somma al carico di lavoro per i costruttori di blocchi, che dovranno calcolare prove fino a 64MB dei dati di rollup, in meno di 1 secondo. Ciò probabilmente richiederà costruttori specializzati, che possano dedicare hardware importanti a questa attività. Tuttavia, nella situazione corrente, la costruzione dei blocchi potrebbe divenire sempre più centralizzata, con operatori più sofisticati e potenti, grazie all'estrazione del MEV. La separazione tra propositori e costruttori è un modo per abbracciare tale realtà, impedendogli di esercitare una forza centrale sulla validazione dei blocchi (la parte importante) o sulla distribuzione delle ricompense di staking. Un ottimo beneficio collaterale è che i costruttori di blocchi specializzati sono anche disposti e capaci di calcolare le prove di dati necessarie per il Danksharding. +Danksharding è il modo in cui Ethereum scalerà a >100.000 transazioni al secondo e minimizzerà le commissioni per gli utenti dei rollup. Si affida alla PBS poiché si somma al carico di lavoro per i costruttori di blocchi, che dovranno calcolare prove fino a 64MB dei dati di rollup, in meno di 1 secondo. Ciò probabilmente richiederà costruttori specializzati, che possano dedicare hardware importanti a questa attività. Tuttavia, nella situazione corrente, la costruzione dei blocchi potrebbe divenire sempre più centralizzata, con operatori più sofisticati e potenti, grazie all'estrazione del MEV. La separazione tra propositori e costruttori è un modo per abbracciare tale realtà, impedendogli di esercitare una forza centrale sulla validazione dei blocchi (la parte importante) o sulla distribuzione delle ricompense di staking. Un ottimo beneficio collaterale è che i costruttori di blocchi specializzati sono anche disposti e capaci di calcolare le prove di dati necessarie per il Danksharding. -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} -La PBS è in una fase di ricerca avanzata, ma esistono ancora delle importanti domande di design che devono essere risolte prima che possa essere prototipata nei client di Ethereum. Non esistono ancora delle specifiche finalizzate. Ciò significa che la PBS potrebbe ancora richiedere qualche anno. Consulta lo [stato della ricerca](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) più recente. +La PBS è in una fase di ricerca avanzata, ma esistono ancora delle importanti domande di design che devono essere risolte prima che possa essere prototipata nei client di Ethereum. Non esistono ancora delle specifiche finalizzate. Ciò significa che la PBS potrebbe ancora richiedere qualche anno. Controlla l'ultimo [stato della ricerca](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance). -## Letture consigliate {#further-reading} +## Ulteriori letture {#further-reading} -- [Stato della ricerca: resistenza alla censura sotto PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) -- [Design di mercato delle commissioni pratici per PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) +- [Stato della ricerca: resistenza alla censura con PBS](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) +- [Progettazioni del mercato delle commissioni compatibili con PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) - [PBS e resistenza alla censura](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions) -- [Elenchi di inclusione](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) +- [Liste di inclusione](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) diff --git a/public/content/translations/it/roadmap/pectra/7702/index.md b/public/content/translations/it/roadmap/pectra/7702/index.md new file mode 100644 index 00000000000..59589dc6925 --- /dev/null +++ b/public/content/translations/it/roadmap/pectra/7702/index.md @@ -0,0 +1,149 @@ +--- +title: Linee guida di Pectra 7702 +description: "Scopri di più sulla 7702 nella release Pectra" +lang: it +--- + +# Pectra 7702 + +## Sintesi {#abstract} + +L'EIP 7702 definisce un meccanismo per aggiungere codice a un EOA. Questa proposta consente agli EOA, i conti Ethereum legacy, di ricevere miglioramenti delle funzionalità a breve termine, aumentando l'usabilità delle applicazioni. Questo avviene impostando un puntatore al codice già distribuito utilizzando un nuovo tipo di transazione: 4. + +Questo nuovo tipo di transazione introduce un elenco di autorizzazioni. Ogni tupla di autorizzazione nell'elenco è definita come + +``` +[ chain_id, address, nonce, y_parity, r, s ] +``` + +**address** è la delega (bytecode già distribuito che sarà usato dall'EOA) +**chain_id** blocca l'autorizzazione a una catena specifica (o 0 per tutte le catene) +**nonce** blocca l'autorizzazione a un nonce di conto specifico +(**y_parity, r, s**) è la firma della tupla di autorizzazione, definita come keccak(0x05 || rlp ([chain_id ,address, nonce])) dalla chiave privata dell'EOA a cui si applica l'autorizzazione (chiamata anche l'autorità) + +Una delega può essere reimpostata delegando all'indirizzo nullo. + +La chiave privata dell'EOA mantiene il pieno controllo sul conto dopo la delega. Ad esempio, delegare a una Safe non rende il conto un multisig, perché c'è ancora una singola chiave che può bypassare qualsiasi politica di firma. In futuro, gli sviluppatori dovrebbero progettare partendo dal presupposto che qualsiasi partecipante al sistema possa essere un contratto intelligente. Per gli sviluppatori di contratti intelligenti, non è più sicuro dare per scontato che `tx.origin` si riferisca a un EOA. + +## Migliori pratiche {#best-practices} + +**Astrazione del Conto**: un contratto di delega dovrebbe allinearsi con gli standard più ampi di astrazione del conto (AA) di Ethereum per massimizzare la compatibilità. In particolare, dovrebbe idealmente essere conforme o compatibile con l'ERC-4337. + +**Progettazione Permissionless e Resistente alla Censura**: Ethereum valorizza la partecipazione permissionless. Un contratto di delega NON DEVE codificare in modo fisso o fare affidamento su alcun singolo relayer o servizio "di fiducia". Questo bloccherebbe il conto se il relayer andasse offline. Funzionalità come il batching (ad es., approve+transferFrom) possono essere utilizzate dall'EOA stesso senza un relayer. Per gli sviluppatori di applicazioni che desiderano utilizzare le funzioni avanzate abilitate dalla 7702 (Astrazione del Gas, Prelievi che Preservano la Privacy) avranno bisogno di un relayer. Sebbene esistano diverse architetture di relayer, la nostra raccomandazione è di usare i [bundler 4337](https://www.erc4337.io/bundlers) che puntano almeno all'[entry point 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) perché: + +- Forniscono interfacce standardizzate per il relaying +- Includono sistemi paymaster integrati +- Garantiscono la compatibilità futura +- Possono supportare la resistenza alla censura attraverso una [mempool pubblica](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool) +- Possono richiedere che la funzione init sia chiamata solo da [EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) + +In altre parole, chiunque dovrebbe essere in grado di agire come sponsor/relayer della transazione, a patto di fornire la firma valida richiesta o la UserOperation dal conto. Questo garantisce la resistenza alla censura: se non è richiesta alcuna infrastruttura personalizzata, le transazioni di un utente non possono essere bloccate arbitrariamente da un relay di controllo. Ad esempio, il [Delegation Toolkit di MetaMask](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0) funziona esplicitamente con qualsiasi bundler o paymaster ERC-4337 su qualsiasi catena, invece di richiedere un server specifico di MetaMask. + +**Integrazione delle dApp tramite le interfacce del portafoglio**: + +Dato che i portafogli inseriranno nella whitelist specifici contratti di delega per l'EIP-7702, le dApp non dovrebbero aspettarsi di richiedere direttamente le autorizzazioni 7702. L'integrazione dovrebbe invece avvenire tramite interfacce di portafoglio standardizzate: + +- **ERC-5792 (`wallet_sendCalls`)**: consente alle dApp di richiedere ai portafogli di eseguire chiamate in batch, facilitando funzionalità come il raggruppamento delle transazioni e l'astrazione del gas. + +- **ERC-6900**: consente alle dApp di sfruttare le funzionalità dei conti intelligenti modulari, come le chiavi di sessione e il recupero del conto, tramite moduli gestiti dal portafoglio. + +Utilizzando queste interfacce, le dApp possono accedere alle funzionalità dei conti intelligenti fornite dall'EIP-7702 senza gestire direttamente le deleghe, garantendo compatibilità e sicurezza tra diverse implementazioni di portafoglio. + +> Nota: non esiste un metodo standardizzato per le dApp per richiedere direttamente le firme di autorizzazione 7702. Le dApp devono affidarsi a interfacce di portafoglio specifiche come l'ERC-6900 per sfruttare le funzionalità dell'EIP-7702. + +Per maggiori informazioni: + +- [Specifica ERC-5792](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md) +- [Specifica ERC-6900](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md) + +**Evitare il Vendor Lock-In**: in linea con quanto sopra, una buona implementazione è neutrale rispetto al fornitore e interoperabile. Questo spesso significa aderire agli standard emergenti per i conti intelligenti. Ad esempio, il [Modular Account di Alchemy](https://github.com/alchemyplatform/modular-account) utilizza lo standard ERC-6900 per i conti intelligenti modulari ed è progettato pensando a un "utilizzo interoperabile e permissionless". + +**Preservazione della Privacy**: sebbene la privacy sulla catena sia limitata, un contratto di delega dovrebbe sforzarsi di minimizzare l'esposizione e la collegabilità dei dati. Ciò può essere ottenuto supportando funzionalità come i pagamenti del gas in token ERC-20 (in modo che gli utenti non debbano mantenere un saldo ETH pubblico, il che migliora la privacy e la UX) e le chiavi di sessione monouso (che riducono la dipendenza da una singola chiave a lungo termine). Ad esempio, l'EIP-7702 consente di pagare il gas in token tramite transazioni sponsorizzate e una buona implementazione renderà facile integrare tali paymaster senza divulgare più informazioni del necessario. Inoltre, la delega off-chain di alcune approvazioni (utilizzando firme verificate sulla catena) significa un minor numero di transazioni sulla catena con la chiave primaria dell'utente, favorendo la privacy. I conti che richiedono l'uso di un relayer costringono gli utenti a rivelare i loro indirizzi IP. Le PublicMempool migliorano questo aspetto: quando una transazione/UserOp si propaga attraverso la mempool, non si può dire se provenga dall'IP che l'ha inviata o se sia stata semplicemente inoltrata attraverso di esso tramite il protocollo p2p. + +**Estensibilità e Sicurezza Modulare**: le implementazioni dei conti dovrebbero essere estensibili in modo da poter evolvere con nuove funzionalità e miglioramenti della sicurezza. L'aggiornabilità è intrinsecamente possibile con l'EIP-7702 (poiché un EOA può sempre delegare a un nuovo contratto in futuro per aggiornare la sua logica). Oltre all'aggiornabilità, una buona progettazione consente la modularità, ad esempio moduli plug-in per diversi schemi di firma o politiche di spesa, senza la necessità di una ridistribuzione completa. L'Account Kit di Alchemy ne è un ottimo esempio, consentendo agli sviluppatori di installare moduli di convalida (per diversi tipi di firma come ECDSA, BLS, ecc.) e moduli di esecuzione per logiche personalizzate. Per ottenere maggiore flessibilità e sicurezza nei conti abilitati all'EIP-7702, si incoraggiano gli sviluppatori a delegare a un contratto proxy piuttosto che direttamente a un'implementazione specifica. Questo approccio consente aggiornamenti fluidi e modularità senza richiedere autorizzazioni EIP-7702 aggiuntive per ogni modifica. + +Vantaggi del pattern Proxy: + +- **Aggiornabilità**: aggiornare la logica del contratto puntando il proxy a un nuovo contratto di implementazione. + +- **Logica di Inizializzazione Personalizzata**: incorporare funzioni di inizializzazione all'interno del proxy per impostare in modo sicuro le variabili di stato necessarie. + +Ad esempio, il [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe) dimostra come un proxy possa essere utilizzato per inizializzare e gestire in modo sicuro le deleghe in conti compatibili con l'EIP-7702. + +Svantaggi del pattern Proxy: + +- **Dipendenza da attori esterni**: bisogna fare affidamento su un team esterno affinché non aggiorni a un contratto non sicuro. + +## Considerazioni sulla sicurezza {#security-considerations} + +**Guardia contro la rientranza**: con l'introduzione della delega EIP-7702, il conto di un utente può passare dinamicamente da un Conto di Proprietà Esterna (EOA) a un Contratto Intelligente (SC). Questa flessibilità consente al conto sia di avviare transazioni che di essere il destinatario di chiamate. Di conseguenza, gli scenari in cui un conto chiama se stesso ed effettua chiamate esterne avranno `msg.sender` uguale a `tx.origin`, il che mina alcune ipotesi di sicurezza che in precedenza si basavano sul fatto che `tx.origin` fosse sempre un EOA. + +Per gli sviluppatori di contratti intelligenti, non è più sicuro dare per scontato che `tx.origin` si riferisca a un EOA. Allo stesso modo, l'uso di `msg.sender == tx.origin` come protezione contro gli attacchi di rientranza non è più una strategia affidabile. + +In futuro, gli sviluppatori dovrebbero progettare partendo dal presupposto che qualsiasi partecipante al sistema possa essere un contratto intelligente. In alternativa, potrebbero implementare una protezione esplicita dalla rientranza utilizzando delle guardie di rientranza con pattern di modificatori `nonReentrant`. Consigliamo di seguire un modificatore verificato, ad es. la [Reentrancy Guard di OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol). Potrebbero anche usare una [variabile di archiviazione transitoria](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html). + +**Considerazioni sulla sicurezza dell'inizializzazione** + +L'implementazione dei contratti di delega EIP-7702 introduce specifiche sfide di sicurezza, in particolare per quanto riguarda il processo di inizializzazione. Una vulnerabilità critica si presenta quando la funzione di inizializzazione (`init`) è atomicamente accoppiata al processo di delega. In tali casi, un frontrunner potrebbe intercettare la firma della delega ed eseguire la funzione `init` con parametri alterati, prendendo potenzialmente il controllo del conto. + +Questo rischio è particolarmente pertinente quando si tenta di utilizzare implementazioni di Conti di Contratti Intelligenti (SCA) esistenti con l'EIP-7702 senza modificare i loro meccanismi di inizializzazione. + +**Soluzioni per Mitigare le Vulnerabilità di Inizializzazione** + +- Implementare `initWithSig` + Sostituire la funzione `init` standard con una funzione `initWithSig` che richiede all'utente di firmare i parametri di inizializzazione. Questo approccio garantisce che l'inizializzazione possa procedere solo con il consenso esplicito dell'utente, mitigando così i rischi di inizializzazione non autorizzata. + +- Utilizzare l'EntryPoint di ERC-4337 + Richiedere che la funzione di inizializzazione sia chiamata esclusivamente dal contratto EntryPoint di ERC-4337. Questo metodo sfrutta il framework di convalida ed esecuzione standardizzato fornito da ERC-4337, aggiungendo un ulteriore livello di sicurezza al processo di inizializzazione. + _(Vedi: [Documentazione Safe](https://docs.safe.global/advanced/eip-7702/7702-safe))_ + +Adottando queste soluzioni, gli sviluppatori possono migliorare la sicurezza dei contratti di delega EIP-7702, proteggendosi da potenziali attacchi di frontrunning durante la fase di inizializzazione. + +**Collisioni di Archiviazione** La delega del codice non cancella l'archiviazione esistente. Quando si migra da un contratto di delega a un altro, i dati residui del contratto precedente rimangono. Se il nuovo contratto utilizza gli stessi slot di archiviazione ma li interpreta in modo diverso, può causare un comportamento imprevisto. Ad esempio, se la delega iniziale era a un contratto in cui uno slot di archiviazione rappresenta un `bool`, e la delega successiva è a un contratto in cui lo stesso slot rappresenta un `uint`, la mancata corrispondenza può portare a risultati imprevedibili. + +**Rischi di phishing** Con l'implementazione della delega EIP-7702, gli asset nel conto di un utente possono essere interamente controllati da contratti intelligenti. Se un utente delega inconsapevolmente il proprio conto a un contratto malevolo, un aggressore potrebbe facilmente ottenerne il controllo e rubare i fondi. Quando si utilizza `chain_id=0` la delega viene applicata a tutti gli ID di catena. Delegare solo a un contratto immutabile (non delegare mai a un proxy), e solo a contratti che sono stati distribuiti usando CREATE2 (con initcode standard - nessun contratto metamorfico) in modo che il deployer non possa distribuire qualcosa di diverso allo stesso indirizzo altrove. Altrimenti la sua delega mette a rischio il suo conto su tutte le altre catene EVM. + +Quando gli utenti eseguono firme delegate, il contratto di destinazione che riceve la delega dovrebbe essere visualizzato in modo chiaro ed evidente per aiutare a mitigare i rischi di phishing. + +**Superficie di Fiducia Minima e Sicurezza**: pur offrendo flessibilità, un contratto di delega dovrebbe mantenere la sua logica di base minima e verificabile. Il contratto è di fatto un'estensione dell'EOA dell'utente, quindi qualsiasi difetto può essere catastrofico. Le implementazioni dovrebbero seguire le migliori pratiche della comunità di sicurezza dei contratti intelligenti. Ad esempio, le funzioni costruttore o inizializzatore devono essere protette con cura - come evidenziato da Alchemy, se si utilizza un pattern proxy con la 7702, un inizializzatore non protetto potrebbe consentire a un aggressore di prendere il controllo del conto. I team dovrebbero mirare a mantenere semplice il codice sulla catena: il contratto 7702 di Ambire è di sole ~200 righe di Solidity, minimizzando deliberatamente la complessità per ridurre i bug. È necessario trovare un equilibrio tra una logica ricca di funzionalità e la semplicità che facilita la verifica. + +### Implementazioni note {#known-implementations} + +Data la natura dell'EIP 7702, si raccomanda che i portafogli usino cautela quando aiutano gli utenti a delegare a un contratto di terze parti. Di seguito è riportato un elenco di implementazioni note che sono state verificate: + +| Indirizzo del contratto | Fonte | Controlli | +| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur) | [audits](https://github.com/Uniswap/calibur/tree/main/audits) | +| 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account) | [audits](https://github.com/alchemyplatform/modular-account/tree/develop/audits) | +| 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol) | [audits](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits) | +| 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework) | [audits](https://github.com/MetaMask/delegation-framework/tree/main/audits) | +| 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [Team AA della Ethereum Foundation](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [audits](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) | +| 0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3 | [Luganodes/Pectra-Batch-Contract](https://github.com/Luganodes/Pectra-Batch-Contract) | [audits](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | + +## Linee guida per i portafogli hardware {#hardware-wallet-guidelines} + +I portafogli hardware non dovrebbero esporre la delega arbitraria. Il consenso nello spazio dei portafogli hardware è di utilizzare un elenco di contratti deleganti fidati. Suggeriamo di consentire le implementazioni note elencate sopra e di considerare le altre caso per caso. Poiché delegare il proprio EOA a un contratto conferisce il controllo su tutti gli asset, i portafogli hardware dovrebbero essere cauti nel modo in cui implementano la 7702. + +### Scenari di integrazione per app companion {#integration-scenarios-for-companion-apps} + +#### Lazy {#lazy} + +Poiché l'EOA continua a funzionare come al solito, non c'è nulla da fare. + +Nota: alcuni asset potrebbero essere rifiutati automaticamente dal codice di delega, come gli NFT ERC 1155, e il supporto dovrebbe esserne consapevole. + +#### Consapevole {#aware} + +Notificare all'utente che è in atto una delega per l'EOA controllando il suo codice e, opzionalmente, offrire di rimuovere la delega. + +#### Delega comune {#common-delegation} + +Il fornitore di hardware inserisce nella whitelist i contratti di delega noti e ne implementa il supporto nel software companion. Si raccomanda di scegliere un contratto con pieno supporto ERC 4337. + +Gli EOA delegati a uno diverso saranno gestiti come EOA standard. + +#### Delega personalizzata {#custom-delegation} + +Il fornitore di hardware implementa il proprio contratto di delega e lo aggiunge agli elenchi, implementandone il supporto nel software companion. Si raccomanda di creare un contratto con pieno supporto ERC 4337. + +Gli EOA delegati a uno diverso saranno gestiti come EOA standard. diff --git a/public/content/translations/it/roadmap/pectra/index.md b/public/content/translations/it/roadmap/pectra/index.md new file mode 100644 index 00000000000..de7d5b3a4c7 --- /dev/null +++ b/public/content/translations/it/roadmap/pectra/index.md @@ -0,0 +1,127 @@ +--- +title: Praga-Electra (Pectra) +description: Scopri l'aggiornamento del protocollo Pectra +lang: it +--- + +# Pectra {#pectra} + +L’aggiornamento della rete Petra è seguito a [Dencun](/roadmap/dencun/) e ha introdotto modifiche sia al livello di esecuzione che al livello di consenso di Ethereum. Il nome abbreviato Petra è una combinazione di Praga ed Elettra, che sono i rispettivi nomi delle modifiche alle specifiche del livello di esecuzione e del livello di consenso. Insieme, questi cambiamenti apportano numerosi miglioramenti agli utenti, agli sviluppatori e ai validatori di Ethereum. + +Questo aggiornamento è stato attivato con successo sulla rete principale di Ethereum all'epoca `364032`, il **07-maggio-2025 alle 10:05 (UTC)**. + + + + +L'aggiornamento Pectra è solo un singolo passo negli obiettivi di sviluppo a lungo termine di Ethereum. Scopri di più sulla [tabella di marcia del protocollo](/roadmap/) e sugli [aggiornamenti precedenti](/ethereum-forks/). + + + + +## Miglioramenti in Pectra {#new-improvements} + +Pectra porta il maggior numero di [EIP](https://eips.ethereum.org/) rispetto a qualsiasi aggiornamento precedente! Ci sono molte modifiche minori ma anche alcune nuove funzionalità significative. L'elenco completo delle modifiche e dei dettagli tecnici può essere trovato nelle singole EIP incluse. + +### Codice del conto EOA {#7702} + +[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) rappresenta un passo importante verso un'[astrazione del conto](/roadmap/account-abstraction/) diffusa. Con questa funzionalità, gli utenti possono impostare il proprio indirizzo ([EOA](/glossary/#eoa)) da estendere con un contratto intelligente. L’EIP introduce un nuovo tipo di transazione con una funzione specifica: consentire ai titolari di un indirizzo di firmare un’autorizzazione che imposta il loro indirizzo per imitare uno smart contract scelto. + +Con questo EIP, gli utenti possono scegliere portafogli programmabili che consentono nuove funzionalità come il raggruppamento delle transazioni, le transazioni senza gas e l’accesso personalizzato agli asset per schemi alternativi di recupero. Questo approccio ibrido combina la semplicità degli EOA con la programmabilità dei conti basati su contratto. + +Leggi un approfondimento su 7702 [qui](/roadmap/pectra/7702/) + +### Aumento del saldo effettivo massimo {#7251} + +L'attuale saldo effettivo del validatore è esattamente di 32 ETH. È l'importo minimo necessario per partecipare al consenso ma, allo stesso tempo, il massimo che un singolo validatore può mettere in staking. + +[EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) aumenta il saldo effettivo massimo possibile a 2048 ETH, il che significa che un singolo validatore può ora mettere in staking tra 32 e 2048 ETH. Invece di multipli di 32, gli staker possono ora scegliere un importo arbitrario di ETH da mettere in staking e ricevere ricompense per ogni 1 ETH al di sopra del minimo. Ad esempio, se il saldo di un validatore cresce con le sue ricompense a 33 ETH, l'ETH extra viene considerato parte del saldo effettivo e riceve ricompense. + +Ma il vantaggio di un migliore sistema di ricompense per i validatori è solo una parte di questo miglioramento. Gli [staker](/staking/) che gestiscono più validatori possono ora aggregarli in uno solo, il che consente un'operatività più semplice e riduce il sovraccarico della rete. Poiché ogni validatore nella Bacon Chain invia una firma in ogni epoca, i requisiti di larghezza di banda aumentano con l’aumentare dei validatori e dell’elevato numero di firme da propagare. L'aggregazione dei validatori alleggerirà il carico sulla rete e aprirà nuove opzioni di scalabilità, mantenendo la stessa sicurezza economica. + +Leggi un approfondimento su maxEB [qui](/roadmap/pectra/maxeb/) + +### Aumento del throughput dei blob {#7691} + +I blob forniscono [disponibilità dei dati](/developers/docs/data-availability/#data-availability-and-layer-2-rollups) per gli L2. Sono stati introdotti nel [precedente aggiornamento della rete](/roadmap/dencun/). + +Attualmente, la rete ha come obiettivo una media di 3 blob per blocco, con un massimo di 6 blob. Con [EIP-7691](https://eips.ethereum.org/EIPS/eip-7691), il numero medio di blob sarà aumentato a 6, con un massimo di 9 per blocco, con conseguente aumento della capacità per i rollup di Ethereum. Questa EIP aiuta a colmare il divario fino a quando [PeerDAS](https://eips.ethereum.org/EIPS/eip-7594) non consentirà un numero di blob ancora più elevato. + +### Aumento del costo dei calldata {#7623} + +Prima dell'introduzione dei [blob nell'aggiornamento Dencun](/roadmap/danksharding), gli L2 utilizzavano i [calldata](/developers/docs/data-availability/blockchain-data-storage-strategies/#calldata) per archiviare i propri dati su Ethereum. Sia i blob che i calldata influiscono sull'uso della larghezza di banda di Ethereum. Mentre la maggior parte dei blocchi utilizza solo una quantità minima di calldata, i blocchi con un elevato volume di dati che contengono anche molti blob possono essere dannosi per la rete p2p di Ethereum. + +Per risolvere questo problema, [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) aumenta il prezzo dei calldata, ma solo per le transazioni con un elevato volume di dati. Questo limita la dimensione massima del blocco, fornisce un incentivo ai livelli 2 (L2) a utilizzare solo i lob e lascia oltre il 99% delle transazioni inalterate. + +### Uscite attivabili a livello di esecuzione {#7002} + +Attualmente, l’uscita di un validatore e il [prelievo dell’ETH in staking](/staking/withdrawals/) è un’operazione del livello di consenso che richiede una chiave di validatore attiva, la stessa chiave BLS utilizzata dal validatore per svolgere attività attive come le attestazioni. Le credenziali di prelievo sono una chiave fredda separata che riceve lo stake dismesso ma non può avviare l’uscita. L'unico modo per gli staker di uscire è inviare un messaggio speciale alla rete della Beacon Chain firmato con la chiave del validatore attiva. Questo risulta limitante negli scenari in cui le credenziali di prelievo e la chiave del validatore sono detenute da entità diverse o quando la chiave del validatore viene smarrita. + +[EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) introduce un nuovo contratto che può essere utilizzato per avviare l’uscita utilizzando le credenziali di prelievo del livello di esecuzione. Gli staker potranno uscire dal proprio validatore chiamando una funzione in questo contratto speciale senza la necessità della chiave di firma del validatore né di alcun accesso alla Beacon Chain. È importante notare che abilitare i prelievi dei validatori sulla catena consente protocolli di staking con presupposti di fiducia ridotti sugli operatori dei nodi. + +### Depositi dei validatori sulla catena {#6110} + +I depositi dei validatori sono attualmente elaborati dal [sondaggio eth1data](https://eth2book.info/capella/part2/deposits-withdrawals/deposit-processing/), che è una funzione sulla Beacon Chain che recupera i dati dal livello di esecuzione. È una sorta di debito tecnico risalente a prima della Fusione, quando la Beacon Chain era una rete separata e doveva preoccuparsi delle riorganizzazioni della proof-of-work. + +[EIP-6110](https://eips.ethereum.org/EIPS/eip-6110) è un nuovo modo di trasferire i depositi dal livello di esecuzione al livello di consenso, che consente un'elaborazione istantanea con minore complessità di implementazione. È un modo più sicuro di gestire i depositi nativi di Ethereum dopo la fusione. Aiuta anche a rendere il protocollo a prova di futuro, perché non richiede depositi storici per l'avvio del nodo, cosa necessaria per la scadenza della cronologia. + +### Precompilazione per BLS12-381 {#2537} + +Le precompilazioni sono un insieme speciale di contratti intelligenti integrati direttamente nella Macchina virtuale di Ethereum ([EVM](/developers/docs/evm/)). A differenza dei contratti normali, le precompilazioni non sono distribuite dagli utenti ma fanno parte dell'implementazione del client stesso, scritte nel suo linguaggio nativo (ad esempio Go, Java, ecc., non Solidity). Le precompilazioni servono per funzioni ampiamente utilizzate e standardizzate, come le operazioni crittografiche. Gli sviluppatori di contratti intelligenti possono chiamare le precompilazioni come un contratto normale, ma con maggiore sicurezza ed efficienza. + +[EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) aggiunge nuove precompilazioni per le operazioni sulle curve su [BLS12-381](https://hackmd.io/@benjaminion/bls12-381). Questa curva ellittica è diventata ampiamente utilizzata negli ecosistemi di criptovalute grazie alle sue proprietà pratiche. Più specificamente, è stata adottata dal livello di consenso di Ethereum, dove è utilizzata dai validatori. + +La nuova precompilazione aggiunge la possibilità per ogni sviluppatore di eseguire in modo semplice, efficiente e sicuro operazioni crittografiche utilizzando questa curva, ad esempio, verificando le firme. Le applicazioni sulla catena che dipendono da questa curva possono diventare più efficienti in termini di gas e più sicure affidandosi a una precompilazione invece che a un contratto personalizzato. Questo si applica principalmente alle applicazioni che vogliono ragionare sui validatori all'interno dell'EVM, ad es., pool di staking, [restaking](/restaking/), client leggeri, ponti, ma anche conoscenza-zero. + +### Servire gli hash dei blocchi storici dallo stato {#2935} + +L'EVM fornisce attualmente l'opcode `BLOCKHASH` che consente agli sviluppatori di contratti di recuperare l'hash di un blocco direttamente nel livello di esecuzione. Tuttavia, questo è limitato solo agli ultimi 256 blocchi e potrebbe diventare problematico per i client stateless in futuro. + +[EIP-2935](https://eips.ethereum.org/EIPS/eip-2935) crea un nuovo contratto di sistema in grado di servire gli ultimi 8192 hash di blocco come slot di archiviazione. Questo aiuta a rendere il protocollo a prova di futuro per l'esecuzione stateless e diventa più efficiente quando vengono adottati i verkle trie. Tuttavia, a parte questo, i rollup possono trarne vantaggio immediatamente, poiché possono interrogare il contratto direttamente con una finestra storica più lunga. + +### Spostare l'indice della commissione al di fuori dell'Attestazione {#7549} + +Il consenso della Beacon Chain si basa sui validatori che esprimono i loro voti per l'ultimo blocco e l'epoca finalizzata. L'attestazione include 3 elementi, 2 dei quali sono voti e il terzo è il valore dell'indice della commissione. + +[EIP-7549](https://eips.ethereum.org/EIPS/eip-7549) sposta questo indice al di fuori del messaggio di attestazione firmato, il che rende più facile verificare e aggregare i voti del consenso. Ciò consentirà una maggiore efficienza in ogni client di consenso e potrà apportare significativi miglioramenti delle prestazioni ai circuiti a conoscenza-zero per la prova del consenso di Ethereum. + +### Aggiungere la pianificazione dei blob ai file di configurazione EL {#7840} + +[EIP-7840](https://eips.ethereum.org/EIPS/eip-7840) è una semplice modifica che aggiunge un nuovo campo alla configurazione del client del livello di esecuzione. Configura il numero di blocchi, consentendo l'impostazione dinamica del target e del numero massimo di blob per blocco, nonché l'adeguamento delle commissioni dei blob. Con una configurazione definita direttamente, i client possono evitare la complessità di scambiare queste informazioni tramite l'API Engine. + + + + +Per saperne di più su come Pectra ti riguarda specificamente come utente, sviluppatore o validatore di Ethereum, consulta le FAQ su Pectra. + + + + +## Questo aggiornamento influisce su tutti i nodi e i validatori di Ethereum? {#client-impact} + +Sì, l'aggiornamento Pectra richiede aggiornamenti sia per i [client di esecuzione che per i client di consenso](/developers/docs/nodes-and-clients/). Tutti i principali client di Ethereum rilasceranno versioni che supportano la biforcazione dura, contrassegnate come ad alta priorità. Per mantenere la sincronizzazione con la rete Ethereum dopo l'aggiornamento, gli operatori dei nodi devono assicurarsi di eseguire una versione client supportata. Si tenga presente che le informazioni sui rilasci dei client sono sensibili al fattore tempo e gli utenti devono fare riferimento agli ultimi aggiornamenti per dettagli attuali. + +## Come si converte l'ETH dopo la biforcazione dura? {#scam-alert} + +- **Nessuna azione richiesta per i tuoi ETH**: dopo l'aggiornamento Pectra di Ethereum, non è necessario convertire o aggiornare i tuoi ETH. I saldi del proprio conto rimarranno gli stessi e l'ETH che si possiede in quel momento rimarrà accessibile nella sua forma esistente dopo la biforcazione dura. +- **Attenzione alle truffe!** **chiunque ti dica di "aggiornare" il tuo ETH sta cercando di truffarti.** Non occorre fare nulla in relazione a questo aggiornamento. Le proprie risorse rimarranno completamente inalterate. Ricorda: essere informati è la migliore difesa contro le truffe. + +[Ulteriori informazioni su come riconoscere ed evitare le truffe](/security/) + +## Preferisci un approccio visivo all'apprendimento? {#visual-learner} + + + +_Cosa c'è nell'aggiornamento Pectra?_ - Christine Kim_ + + + +_Aggiornamento Pectra di Ethereum: cosa devono sapere gli staker — Blockdaemon_ + +## Letture consigliate {#further-reading} + +- [Tabella di marcia di Ethereum](/roadmap/) +- [Domande frequenti su Pectra](https://epf.wiki/#/wiki/pectra-faq) +- [Pagina informativa Pectra.wtf](https://pectra.wtf) +- [Come Pectra migliora l'esperienza degli staker](https://www.kiln.fi/post/next-ethereum-upgrade-how-pectra-will-enhance-the-staking-experience) +- [Pagina informativa EIP7702](https://eip7702.io/) +- [Devnet di Pectra](https://github.com/ethereum/pm/blob/master/Pectra/pectra-pm.md) diff --git a/public/content/translations/it/roadmap/pectra/maxeb/index.md b/public/content/translations/it/roadmap/pectra/maxeb/index.md new file mode 100644 index 00000000000..5f0232ff4ef --- /dev/null +++ b/public/content/translations/it/roadmap/pectra/maxeb/index.md @@ -0,0 +1,204 @@ +--- +title: Pectra MaxEB +description: "Scopri di più su MaxEB nella release Pectra" +lang: it +--- + +# MaxEB {#maxeb} + +_In breve:_ L'hard fork Pectra consente ai validatori di Ethereum di optare per un saldo massimo effettivo più elevato e per il compounding, convertendo le credenziali di prelievo da **Tipo 1** a **Tipo 2**. Lo strumento ufficiale per farlo è il Launchpad. Questa operazione è irreversibile. + +## Panoramica {#overview} + +### Chi è interessato? {#who-is-affected} + +Chiunque gestisca un validatore - probabilmente qualcuno che conosce l'indice (ad es., [Validatore #12345](https://beaconcha.in/validator/12345)) di un validatore che controlla. Se utilizzi un protocollo per gestire un validatore (ad es., Lido CSM o Rocket Pool), dovrai verificare con loro se e quando supporteranno maxEB. + +Se fai staking utilizzando un token di staking liquido (ad es., rETH o stETH), non è richiesta né consigliata alcuna azione. + +### Cos'è "maxEB"? {#what-is-maxeb} + +maxEB = il Saldo Effettivo MASSIMO di un validatore. Fino all'hard fork Pectra, ogni validatore guadagna su un massimo di 32 ETH. Dopo Pectra, i validatori hanno la possibilità di guadagnare su qualsiasi saldo tra 32 e 2048 ETH, con incrementi di 1 ETH, aderendo alla modifica. + +### Come fa un validatore ad aderire? {#how-does-a-validator-opt-in} + +Un validatore aderisce alla modifica maxEB convertendo le credenziali di prelievo da **Tipo 1** a **Tipo 2**. Questa operazione può essere eseguita su [Launchpad (Azioni del validatore)](https://launchpad.ethereum.org/validator-actions) dopo l'attivazione dell'hard fork Pectra. Come per la conversione da **Tipo 0** → **Tipo 1**, la conversione da **Tipo 1** → **Tipo 2** è un processo irreversibile. + +### Cosa sono le credenziali di prelievo? {#whats-a-withdrawal-credential} + +Quando gestisci un validatore, hai un set di credenziali di prelievo. Queste possono essere trovate nel tuo file json con i dati di deposito o puoi visualizzarle nella [scheda di deposito](https://beaconcha.in/validator/12345#deposits) del tuo validatore su beaconcha.in. + +1. **Credenziali di prelievo di Tipo 0**: se le credenziali di prelievo del tuo validatore iniziano con `0x00...`, hai effettuato il deposito prima dell'hard fork Shapella e non hai ancora impostato un indirizzo di prelievo. + +![Credenziale di prelievo di Tipo 0](./0x00-wd.png) + +2. **Credenziali di prelievo di Tipo 1**: se le credenziali di prelievo del tuo validatore iniziano con `0x01...`, hai effettuato il deposito dopo l'hard fork Shapella o hai già convertito le tue credenziali da **Tipo 0** a **Tipo 1**. + +![Credenziale di prelievo di Tipo 1](./0x01-wd.png) + +3. **Credenziali di prelievo di Tipo 2**: questo nuovo tipo di credenziale di prelievo inizierà con `0x02...` e sarà abilitato dopo Pectra. I validatori con credenziali di prelievo di **Tipo 2** sono talvolta chiamati "**validatori a capitalizzazione composta**" + +| **Consentito** | **Non consentito** | +| ----------------- | ------------------ | +| ✅ Tipo 0 → Tipo 1 | ❌ Tipo 0 → Tipo 2 | +| ✅ Tipo 1 → Tipo 2 | ❌ Tipo 1 → Tipo 0 | +| | ❌ Tipo 2 → Tipo 1 | +| | ❌ Tipo 2 → Tipo 0 | + +### Rischi {#risks} + +MaxEB consente a un validatore di inviare il suo intero saldo a un altro validatore. Gli utenti che inviano una richiesta di consolidamento devono verificare la fonte e il contenuto della transazione che stanno firmando. Lo strumento ufficiale per usufruire delle funzionalità di maxEB è il Launchpad. Se decidi di utilizzare uno strumento di terze parti, devi verificare che: + +- La chiave pubblica e l'indirizzo di prelievo del validatore di origine corrispondano al validatore che controllano +- La chiave pubblica del validatore di destinazione sia corretta e appartenga a loro +- La richiesta sia una conversione, non un consolidamento, se non intendono inviare fondi a un altro validatore +- La transazione sia firmata dall'indirizzo di prelievo corretto + +**Consigliamo vivamente** di discutere di qualsiasi strumento di terze parti che si intende utilizzare con la [community di EthStaker](https://ethstaker.org/about). È un luogo utile per verificare la correttezza del proprio approccio ed evitare errori. Se si utilizza uno strumento malevolo o configurato in modo errato, **l'intero saldo del validatore potrebbe essere inviato a un validatore che non si controlla**, senza alcuna possibilità di recuperarlo. + +## Dettagli tecnici {#technical-details} + +### Il flusso {#the-flow} + +L'operazione `ConsolidationRequest` avrà due usi: + +1. Convertire un validatore esistente da **Tipo 1** a **Tipo 2** +2. Consolidare altri validatori in un validatore di **Tipo 2** esistente + +In una conversione di un validatore da **Tipo 1** a **Tipo 2**, sia l'_origine_ che la _destinazione_ saranno il validatore che si sta convertendo. L'operazione costerà del gas e sarà accodata dietro ad altre richieste di consolidamento. Questa coda è **separata** dalla coda dei depositi, non è influenzata dai nuovi depositi dei validatori e può essere visualizzata su [pectrified.com](https://pectrified.com/). + +Per consolidare i validatori, è necessario disporre di un _validatore di destinazione_ con credenziali di prelievo di **Tipo 2**. Questa è la destinazione di tutti i saldi dei validatori che vengono consolidati e l'indice che viene preservato. + +### Requisiti per la conversione al Tipo 2 {#requirements-for-converting-to-type-2} + +Ciò sarà necessario per il primo validatore convertito in **Tipo 2**. L'indice di questo validatore è preservato e attivo. Per una conversione, il _validatore di origine_ == il _validatore di destinazione_. + +Il validatore deve... + +- essere attivo +- avere credenziali di prelievo di **Tipo 1** +- non essere in stato di uscita (o soggetto a slashing) +- non avere prelievi in sospeso attivati manually (non si applica agli sweep) + +![illustrazione della conversione](./conversion.png) + +### Requisiti per il consolidamento {#requirements-for-consolidating} + +È la _stessa operazione_ della conversione, ma si verifica quando il _validatore di origine_ è diverso dal _validatore di destinazione_. L'indice del validatore di destinazione viene preservato e accetta il saldo dal validatore di origine. L'indice del validatore di origine viene impostato sullo stato `EXITED`. + +In questo caso, il validatore di origine ha tutti i requisiti di cui sopra, più: + +- è stato attivo per almeno ~27,3 ore (un `SHARD_COMMITTEE_PERIOD`) + +Il validatore di destinazione deve + +- avere credenziali di prelievo di **Tipo 2** +- non essere in stato di uscita. + +![illustrazione del consolidamento](./consolidation.png) + +### La richiesta di consolidamento {#the-consolidation-request} + +La richiesta di consolidamento sarà firmata dall'indirizzo di prelievo associato al validatore di origine e conterrà: + +1. Indirizzo del validatore di origine (ad es., `0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b`) +2. Chiave pubblica del validatore di origine (ad es., `0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c`) +3. Chiave pubblica di quel validatore di destinazione + +In una conversione, 2 e 3 saranno uguali. Questa operazione può essere eseguita su [Launchpad](https://launchpad.ethereum.org/). + +### Requisiti di firma {#signing-requirements} + +Per inviare una `ConsolidationRequest`, l'**indirizzo di prelievo del validatore di origine** deve firmare la richiesta. Questo dimostra il controllo sui fondi del validatore. + +### Cosa viene firmato? {#what-is-signed} + +Viene usata una [radice di firma](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#compute_signing_root) separata dal dominio dell'oggetto `ConsolidationRequest`. + +- **Dominio:** `DOMAIN_CONSOLIDATION_REQUEST` +- **Campi della radice di firma:** + - `source_pubkey`: `BLSPubkey` + - `target_pubkey`: `BLSPubkey` + - `source_address`: `ExecutionAddress` + +La **firma BLS** risultante viene inviata insieme alla richiesta. + +Nota: la firma viene eseguita dall'indirizzo di prelievo, non dalla chiave del validatore. + +### Prelievi parziali {#partial-withdrawals} + +I validatori con credenziali di **Tipo 1** ottengono sweep automatici e senza gas del loro saldo in eccesso (qualsiasi importo superiore a 32 ETH) verso il loro indirizzo di prelievo. Poiché il **Tipo 2** permette a un validatore di capitalizzare i saldi con incrementi di 1 ETH, non effettuerà lo sweep automatico dei saldi finché non raggiungerà 2048 ETH. I prelievi parziali sui validatori di **Tipo 2** devono essere attivati manualmente e costeranno del gas. + +## Strumenti di consolidamento {#consolidation-tooling} + +Sono disponibili diversi strumenti per gestire i consolidamenti. Lo strumento ufficiale, creato dalla Ethereum Foundation, è [Launchpad](https://launchpad.ethereum.org/en/validator-actions). Esistono anche strumenti di terze parti creati da entità della comunità di staking che possono offrire funzionalità non fornite da Launchpad. Sebbene gli strumenti qui presentati non siano controllati o approvati dalla Ethereum Foundation, i seguenti sono strumenti open source di membri noti della comunità. + +| Strumento | Sito Web | Open source | Creatore | Controllato | Interfaccia | Funzionalità degne di nota | +| ------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------ | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | +| Pectra Staking Manager | pectrastaking.com | Sì, Apache 2.0 | [Pier Two](https://piertwo.com/) | No | Interfaccia web | Wallet Connect, funziona con SAFE | +| Pectra Validator Ops CLI Tool | [GitHub](https://github.com/Luganodes/Pectra-Batch-Contract) | Sì, MIT | [Luganodes](https://www.luganodes.com/) | Sì, Quantstamp [Maggio 2025](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html) | Riga di comando | Batching, per molti validatori contemporaneamente | +| Ethereal | [GitHub](https://github.com/wealdtech/ethereal) | Sì, Apache 2.0 | [Jim McDonald](https://www.attestant.io/team/) | No | Riga di comando | Set completo di funzionalità per la gestione di validatori e nodi | +| Siren | [GitHub](https://github.com/sigp/siren) | Sì, Apache 2.0 | [Sigma Prime](https://sigmaprime.io/) | No | In parte da riga di comando, ma principalmente interfaccia web | Funziona solo se si utilizza il client di consenso Lighthouse | +| Consolideth.app | https://consolideth.app/ [GitHub](https://github.com/Stakely/consolideth) | Sì, licenze MIT | [Stakely](https://stakely.io/) | No | Interfaccia web, ospitata da Stakely e pronta per essere auto-ospitata liberamente | Supporta le principali connessioni di portafogli, incluso Safe con WalletConnect | + +## Domande frequenti {#faq} + +### L'adesione cambia la mia fortuna nelle proposte o le mie ricompense? {#change-luck-or-rewards} + +No. L'adesione non diminuisce le tue possibilità di proposta: i tuoi compiti e la selezione della proposta rimangono gli stessi. Ad esempio, se hai due validatori da 32 ETH contro un validatore da 64 ETH, avrai le stesse possibilità totali di essere selezionato per proporre un blocco e guadagnare ricompense. + +### L'adesione cambia il mio rischio di slashing? {#change-slashing-risk} + +Per gli operatori più piccoli o non professionali, la risposta breve è no. La risposta più lunga è che, per gli operatori professionali che gestiscono molti validatori per nodo con avvisi rapidi, il consolidamento in un numero inferiore di validatori potrebbe ridurre la loro capacità di reagire a uno slashing e prevenire eventi a cascata. La _penalità_ di slashing iniziale per tutti i validatori è stata drasticamente ridotta da 1 ETH (per 32 ETH) a 0,0078125 ETH (per 32 ETH) per compensare questo rischio. + +### Devo uscire dal mio validatore per effettuare la conversione? {#exit-validator} + +No. Puoi effettuare la conversione sul posto senza uscire. + +### Quanto tempo ci vorrà per convertire/consolidare? {#how-long} + +Un minimo di 27,3 ore, ma i consolidamenti sono anche soggetti a una coda. Questa coda è indipendente dalle code di deposito e prelievo e non è influenzata da esse. + +### Posso mantenere il mio indice di validatore? {#keep-validator-index} + +Sì. La conversione sul posto mantiene lo stesso indice del validatore. Se consolidi più validatori, potrai mantenere solo l'indice del _validatore di destinazione_. + +### Perderò delle attestazioni? {#miss-attestations} + +Durante un consolidamento in un altro validatore, il validatore di origine esce e c'è un periodo di attesa di ~27 ore prima che il saldo sia attivo sul validatore di destinazione. Questo periodo **non influisce sulle metriche di performance**. + +### Incorrerò in penalità? {#incur-penalties} + +No. Finché il tuo validatore è online, non incorrerai in penalità. + +### Gli indirizzi di prelievo dei validatori da consolidare devono corrispondere? {#withdrawal-addresses-match} + +No. Ma l'_origine_ deve autorizzare la richiesta dal proprio indirizzo. + +### Le mie ricompense saranno capitalizzate dopo la conversione? {#rewards-compound} + +Sì. Con le credenziali di **Tipo 2**, le ricompense superiori a 32 ETH vengono automaticamente rimesse in staking, ma non istantaneamente. A causa di un piccolo buffer (chiamato [_isteresi_](https://eth2book.info/capella/part2/incentives/balances/#hysteresis)), il tuo saldo deve raggiungere **circa 1,25 ETH in più** prima che l'extra venga rimesso in staking. Quindi, invece di capitalizzare a 33,0 ETH, avviene a 33,25 (saldo effettivo = 33 ETH), poi a 34,25 (saldo effettivo = 34 ETH) e così via. + +### Posso ancora ottenere sweep automatici dopo la conversione? {#automatic-sweep} + +Gli sweep automatici avverranno solo con saldi in eccesso superiori a 2048. Per tutti gli altri prelievi parziali, dovrai attivarli manualmente. + +### Posso cambiare idea e tornare dal Tipo 2 al Tipo 1? {#go-back-to-type1} + +No. La conversione al **Tipo 2** è irreversibile. + +### Se voglio consolidare più validatori, devo prima convertirli tutti al Tipo 2? {#consolidate-multiple-validators} + +No! Converti un validatore al Tipo 2 e poi usalo come destinazione. Tutti gli altri validatori consolidati in quella destinazione di Tipo 2 possono essere di Tipo 1 o di Tipo 2 + +### Il mio validatore è offline o ha un saldo inferiore a 32 ETH - posso comunque convertirlo? {#offline-or-below-32eth} + +Sì. Finché è attivo (non uscito) e puoi firmare con il suo indirizzo di prelievo, puoi convertirlo. + +## Risorse {#resources} + +- [Specifiche di consenso di Electra](https://github.com/ethereum/consensus-specs/blob/dev/specs/electra/beacon-chain.md): questa è la versione più 'veritiera' su cui dovresti fare affidamento. Nel dubbio, leggi le specifiche +- Non tutti si sentono a proprio agio a districarsi nel codice, quindi [questo maxEB-GPT](https://chatgpt.com/g/g-67f1650fb48081918f555e0c8d1c2ae9-maxeb-gpt) può aiutare a interpretare le specifiche. _Esonero di responsabilità: le specifiche, non l'IA, devono essere considerate come la verità, poiché l'IA potrebbe interpretare male le informazioni o fornire risposte allucinate_ +- [pectrified.com](https://pectrified.com/): visualizza lo stato dei consolidamenti, dei depositi e dei tempi di attesa della coda +- [Ethereal](https://github.com/wealdtech/ethereal): strumento CLI creato dalla comunità per la gestione delle attività comuni dei validatori +- [batch-validator-depositor](https://github.com/attestantio/batch-validator-depositor): contratto creato dalla comunità che permette di depositare più validatori di Ethereum in un'unica transazione diff --git a/public/content/translations/it/roadmap/scaling/index.md b/public/content/translations/it/roadmap/scaling/index.md index 54d6c3f2ac9..e3dcd15441b 100644 --- a/public/content/translations/it/roadmap/scaling/index.md +++ b/public/content/translations/it/roadmap/scaling/index.md @@ -1,13 +1,13 @@ --- title: Ridimensionare Ethereum -description: I rollup raggruppano le transazioni al di fuori della catena, riducendo i costi per l'utente. Tuttavia, il modo in cui i rollup utilizzano i dati al momento è troppo costoso, il che limita l'economicità delle transazioni. Il Proto-Danksharding lo corregge. +description: "I rollup raggruppano le transazioni al di fuori della catena, riducendo i costi per l'utente. Tuttavia, il modo in cui i rollup utilizzano i dati al momento è troppo costoso, il che limita l'economicità delle transazioni. Il Proto-Danksharding lo corregge." lang: it image: /images/roadmap/roadmap-transactions.png alt: "Roadmap di Ethereum" template: roadmap --- -Ethereum è ridimensionato utilizzando i [livelli 2](/layer-2/#rollups) (anche noti come rollup), che raggruppano le transazioni, inviando il risultato a Ethereum. Sebbene i rollup siano fino a otto volte meno costosi che sulla Rete Principale di Ethereum, è possibile ottimizzare ulteriormente i rollup per ridurre i costi per gli utenti finali. Inoltre, i rollup, si affidano ad alcuni componenti centralizzati che gli sviluppatori possono rimuovere, al maturare dei rollup. +Ethereum è ridimensionato utilizzando i [livelli 2](/layer-2/#rollups) (anche noti come rollup), che raggruppano le transazioni e inviano il risultato a Ethereum. Sebbene i rollup siano fino a otto volte meno costosi che sulla Rete Principale di Ethereum, è possibile ottimizzare ulteriormente i rollup per ridurre i costi per gli utenti finali. Inoltre, i rollup, si affidano ad alcuni componenti centralizzati che gli sviluppatori possono rimuovere, al maturare dei rollup. @@ -23,7 +23,7 @@ Ethereum è ridimensionato utilizzando i [livelli 2](/layer-2/#rollups) (anche n -## Rendere più economici i dati {#making-data-cheaper} +## Rendere i dati più economici {#making-data-cheaper} I rollup raccolgono grandi numeri di transazioni, le eseguono e poi inviano i risultati a Ethereum. Ciò genera molti dati che devono essere disponibili apertamente, così che tutti possano eseguire le transazioni da soli, verificando che l'operatore del rollup sia onesto. Se qualcuno trova una discrepanza, può generare una sfida. @@ -31,26 +31,28 @@ I rollup raccolgono grandi numeri di transazioni, le eseguono e poi inviano i ri Storicamente i dati dei rollup sono stati memorizzati in modo permanente su Ethereum, il che è costoso. Oltre il 90% dei costi di transazione pagati sui rollup è causato da tale archiviazione dei dati. Per ridurre i costi di transazione, possiamo spostare i dati in una nuova archiviazione temporanea a 'blob'. I blob sono più economici poiché non sono permanenti; sono eliminati da Ethereum una volta che non sono più necessari. La memorizzazione a lungo termine dei dati dei rollup diventa una responsabilità di coloro che li necessitano, come gli operatori dei rollup, le borse, i servizi di indicizzazione, etc. Aggiungere le transazioni di blob a Ethereum è parte di un aggiornamento noto come "Proto-Danksharding". -Con il Proto-Danksharding è possibile aggiungere molti blob ai blocchi di Ethereum. Ciò consente un altro ridimensionamento sostanziale (>100 volte) del volume di Ethereum e la riduzione dei costi di transazione. +Con il Proto-Danksharding è possibile aggiungere molti blob ai blocchi di Ethereum. Ciò consente un altro ridimensionamento sostanziale (>100x) del volume di Ethereum e la riduzione dei costi di transazione. ### Danksharding {#danksharding} -La seconda fase di espansione dei dati del blob è complicata, poiché richiede nuovi metodi per verificare che i dati del rollup siano disponibili sulla rete, e fa affidamento sul fatto che i [validatori](/glossary/#validator) separino le proprie responsabilità di creazione e proposta dei [blocchi](/glossary/#block). Inoltre, richiede un metodo per provare crittograficamente che i validatori abbiano verificato piccoli sotto nsiemi dei dati dei blob. +La seconda fase dell'espansione dei dati blob è complicata perché richiede nuovi metodi per verificare che i dati dei rollup siano disponibili sulla rete e si basa sul fatto che i [validatori](/glossary/#validator) separino le loro responsabilità di costruzione del [blocco](/glossary/#block) e di proposta del blocco. Inoltre, richiede un metodo per provare crittograficamente che i validatori abbiano verificato piccoli sotto nsiemi dei dati dei blob. -Questa seconda fase è nota come [“Danksharding”](/roadmap/danksharding/). **Probabilmente trascorreranno diversi anni** prima della sua completa implementazione. Il danksharding si affida ad altri sviluppi come la [separazione della costruzione e della proposta dei blocchi](/roadmap/pbs) e nuovi design della rete che consentano a essa di confermare efficientemente che i dati siano disponibili, campionando casualmente pochi kilobyte per volta, procedimento noto come [campionamento della disponibilità dei dati (o DAS)](/developers/docs/data-availability). +Questo secondo passo è noto come ["Danksharding"](/roadmap/danksharding/). Il lavoro di implementazione continua, con progressi sui prerequisiti come la [separazione della costruzione e della proposta dei blocchi](/roadmap/pbs) e nuovi design di rete che consentono alla rete di confermare in modo efficiente che i dati siano disponibili campionando casualmente pochi kilobyte alla volta, una procedura nota come [campionamento della disponibilità dei dati (DAS)](/developers/docs/data-availability). -Di più sul Danksharding +Maggiori informazioni su Danksharding ## Decentralizzare i rollup {#decentralizing-rollups} -I [rollup](/layer-2) stanno già ridimensionando Ethereum. Un [ecosistema ricco di progetti di rollup](https://l2beat.com/scaling/tvl) sta consentendo agli utenti di eseguire le transazioni rapidamente ed economicamente, con numerose garanzie di sicurezza. Tuttavia, i rollup sono stati avviati utilizzando sequenziatori centralizzati (computer che eseguono tutta l'elaborazione e aggregazione delle transazioni, prima di inviarle a Ethereum). Ciò è vulnerabile alla censura, poiché gli operatori del sequenziatore sono sanzionabili, corrompibili o, compromessi in altri modi. Al contempo, i [rollup variano](https://l2beat.com) nel modo in cui convalidano i dati in entrata. Il metodo migliore è che i "dimostratori" inviino delle [prove di frode](/glossary/#fraud-proof), o prove di validità; tuttavia, ancora non tutti i rollup ne dispongono. Persino quei rollup che utilizzano le prove di validità/frode, utilizzano un piccolo gruppo di dimostratori noti. Dunque, il prossimo passaggio critico nel ridimensionare Ethereum è distribuire la responsabilità di operare i sequenziatori e i dimostratori, tra più persone. +I [rollup](/layer-2) stanno già ridimensionando Ethereum. Un [ricco ecosistema di progetti di rollup](https://l2beat.com/scaling/tvs) consente agli utenti di effettuare transazioni in modo rapido ed economico, con una serie di garanzie di sicurezza. Tuttavia, i rollup sono stati avviati utilizzando sequenziatori centralizzati (computer che eseguono tutta l'elaborazione e aggregazione delle transazioni, prima di inviarle a Ethereum). Ciò è vulnerabile alla censura, poiché gli operatori del sequenziatore sono sanzionabili, corrompibili o, compromessi in altri modi. Allo stesso tempo, i [rollup variano](https://l2beat.com/scaling/summary) nel modo in cui convalidano i dati in entrata. Il modo migliore è che i "prover" inviino [prove di frode](/glossary/#fraud-proof) o prove di validità, ma non tutti i rollup sono ancora a quel punto. Persino quei rollup che utilizzano le prove di validità/frode, utilizzano un piccolo gruppo di dimostratori noti. Dunque, il prossimo passaggio critico nel ridimensionare Ethereum è distribuire la responsabilità di operare i sequenziatori e i dimostratori, tra più persone. Maggiori informazioni sui rollup -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} -Il Proto-Danksharding è il primo di questi elementi della tabella di marcia a essere implementato, come parte dell'aggiornamento della rete Cancun-Deneb ("Dencun"), nel marzo 2024. **Il Danksharding completo richiederà probabilmente ancora diversi anni**, poiché si basa su diversi altri punti della tabella di marcia ancora da completare. La decentralizzazione dell'infrastruttura dei rollup è probabilmente un processo graduale: esistono molti rollup differenti che stanno creando sistemi lievemente differenti e si decentralizzeranno completamente a velocità diverse. +Il Proto-Danksharding è stato implementato con successo come parte dell'aggiornamento della rete Cancun-Deneb ("Dencun") a marzo 2024. Dalla sua implementazione, i rollup hanno iniziato a utilizzare l'archiviazione blob, riducendo i costi di transazione per gli utenti ed elaborando milioni di transazioni nei blob. -[Maggiori informazioni sull'aggiornamento della rete Dencun](/roadmap/dencun/) +Il lavoro sul Danksharding completo continua, con progressi sui suoi prerequisiti come PBS (Proposer-Builder Separation) e DAS (Data Availability Sampling). La decentralizzazione dell'infrastruttura dei rollup è un processo graduale: esistono molti rollup diversi che stanno costruendo sistemi leggermente diversi e si decentralizzeranno completamente a ritmi diversi. + +[Maggiori informazioni sull'aggiornamento della rete Dencun e sul suo impatto](/roadmap/dencun/) diff --git a/public/content/translations/it/roadmap/secret-leader-election/index.md b/public/content/translations/it/roadmap/secret-leader-election/index.md index 36ef1aad78d..affa43164dd 100644 --- a/public/content/translations/it/roadmap/secret-leader-election/index.md +++ b/public/content/translations/it/roadmap/secret-leader-election/index.md @@ -8,19 +8,19 @@ summaryPoints: - Un'estensione di quest'idea è rendere casuale la selezione del validatore, per ogni spazio. --- -# Elezioni segrete del leader {#single-secret-leader-election} +# Elezione segreta di un singolo leader {#single-secret-leader-election} Nel meccanismo di consenso odierno basato sul [proof-of-stake](/developers/docs/consensus-mechanisms/pos), l'elenco di propositori di blocchi in entrata è pubblico ed è possibile mapparne gli indirizzi IP. Ciò significa che gli utenti malevoli potrebbero identificare quali valori dovrebbero proporre a un blocco e li prendono di mira con un attacco di negazione del servizio (DOS), che li lascia incapaci di proporre il proprio blocco in tempo. -Questo potrebbe creare opportunità di profitto per un utente malevolo. Ad esempio, un propositore di blocchi selezionato per lo spazio `n+1` potrebbe compiere un attacco DOS nei confronti del propositore allo spazio `n`, così che perda l'opportunità di proporre un blocco. Questo consentirebbe al propositore di blocchi che attacca di estrarre il MEV da entrambi gli slot, o di prendere tutte le transazioni che dovrebbero essere divise tra i due blocchi e invece includerli tutti in una volta, ottenendo tutte le commissioni associate. Questo potrebbe influenzare i validatori domestici più di quelli istituzionali sofisticati, che possono utilizzare metodi più avanzati per proteggersi dagli attacchi DOS e, dunque, potrebbero essere una forza centralizzante. +Questo potrebbe creare opportunità di profitto per un utente malevolo. Ad esempio, un propositore di blocchi selezionato per lo slot `n+1` potrebbe lanciare un attacco DoS al propositore nello slot `n`, facendogli perdere l'opportunità di proporre un blocco. Questo consentirebbe al propositore di blocchi che attacca di estrarre il MEV da entrambi gli slot, o di prendere tutte le transazioni che dovrebbero essere divise tra i due blocchi e invece includerli tutti in una volta, ottenendo tutte le commissioni associate. Questo potrebbe influenzare i validatori domestici più di quelli istituzionali sofisticati, che possono utilizzare metodi più avanzati per proteggersi dagli attacchi DOS e, dunque, potrebbero essere una forza centralizzante. -Esistono svariate soluzioni a questo problema. Una è la [Tecnologia del Validatore Distribuita](https://github.com/ethereum/distributed-validator-specs), che mira a diffondere le varie mansioni correlate all'operazione di un validatore tra più macchine, con ridondanza, così che sia molto più complicato, per un utente malevolo, prevenire la proposta di un blocco in uno slot particolare. Tuttavia, la soluzione più robusta è l'**Elezione Segreta di un Singolo Capo (SSLE)**. +Esistono svariate soluzioni a questo problema. Una è la [Tecnologia dei Validatori Distribuiti](https://github.com/ethereum/distributed-validator-specs), che mira a distribuire i vari compiti relativi all'esecuzione di un validatore su più macchine, con ridondanza, in modo che sia molto più difficile per un utente malintenzionato impedire che un blocco venga proposto in un particolare slot. Tuttavia, la soluzione più robusta è l'**Elezione Segreta di un Singolo Leader (SSLE)**. -## Elezione segreta di un singolo capo {#secret-leader-election} +## Elezione segreta di un singolo leader {#secret-leader-election} Nella SSLE, si utilizza una crittografia intelligente per assicurarsi che soltanto il validatore selezionato sappia di esser stato selezionato. Ciò funziona facendo inviare a ogni validatore un impegno a una frase segreta condivisa. Gli impegni sono mescolati e riconfigurati così che nessuno possa mapparli ai validatori, ma che ogni validatore sa quale gli appartiene. Poi, si sceglie un impegno a caso. Se un validatore rileva che è stato scelto il proprio impegno, sa che è il suo turno di proporre un blocco. -L'implementazione principale di quest'idea si chiama [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Che funziona come segue: +L'implementazione principale di questa idea si chiama [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Che funziona come segue: 1. I validatori si impegnano a una frase segreta condivisa. Lo schema di impegno è progettato così che possa essere vincolato all'identità di un validatore, nonché casualizzato, così che nessuna terza parte possa decodificarlo e collegare un impegno specifico a un validatore specifico. 2. All'inizio di un'epoca, una serie casuale di validatori è scelta per campionare gli impegni da 16.384 validatori, utilizzando RANDAO. @@ -31,11 +31,11 @@ L'implementazione principale di quest'idea si chiama [Whisk](https://ethresear.c Questo impedisce agli utenti malevolo di sapere in anticipo quale validatore nello specifico proporrà il prossimo blocco, impedendo l'abilità di compiere attacchi DOS. -## Elezione segreta di un capo non singolo (SnSLE) {#secret-non-single-leader-election} +## Elezione segreta di leader non singolo (SnSLE) {#secret-non-single-leader-election} -Inoltre, esiste una proposta separata che mira a creare uno scenario in cui ogni validatore ha una possibilità casuale di proporre un blocco in ogni spazio, similmente a come la proposta del blocco era decisa sotto proof-of-work, nota come **elezione segreta di un capo non singolo (SnSLE)**. Un metodo semplice per compierla è utilizzare la funzione RANDAO per selezionare casualmente i validatori nel protocollo di oggi. L'idea con RANDAO è che un numero sufficientemente casuale è generato, mischiando gli hash inviati da molti validatori indipendenti. Nella SnSLE, questi hash potrebbero essere utilizzati per scegliere il propositore di blocchi successivo, ad esempio, scegliendo l'hash dal valore più basso. L'intervallo di hash validi potrebbe essere limitato, per sintonizzarsi alla probabilità che siano selezionati dei validatori singoli in ogni spazio. Affermando che l'hash dev'essere inferiore a `2^256 * 5 / N`, dove `N` è il numero di validatori attivi, la possibilità che ogni singolo validatore sia selezionato in ogni spazio sarebbe di `5/N`. In qusto esempio, esisterebbe una probabilità del 99,3% che almeno un propositore generi un hash valido in ogni spazio. +Esiste anche una proposta separata che mira a creare uno scenario in cui ogni validatore ha una possibilità casuale di proporre un blocco in ogni slot, in modo simile a come la proposta del blocco veniva decisa con il proof-of-work, nota come **elezione segreta di leader non singolo (SnSLE)**. Un metodo semplice per compierla è utilizzare la funzione RANDAO per selezionare casualmente i validatori nel protocollo di oggi. L'idea con RANDAO è che un numero sufficientemente casuale è generato, mischiando gli hash inviati da molti validatori indipendenti. Nella SnSLE, questi hash potrebbero essere utilizzati per scegliere il propositore di blocchi successivo, ad esempio, scegliendo l'hash dal valore più basso. L'intervallo di hash validi potrebbe essere limitato, per sintonizzarsi alla probabilità che siano selezionati dei validatori singoli in ogni spazio. Affermando che l'hash deve essere inferiore a `2^256 * 5 / N` dove N = numero di validatori attivi, la possibilità che un singolo validatore venga selezionato in ogni slot sarebbe di `5/N`. In qusto esempio, esisterebbe una probabilità del 99,3% che almeno un propositore generi un hash valido in ogni spazio. -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} SSLE e SnSLE sono entrambi in fase di ricerca. Ancora non esiste una specifica finalizzata per alcuna delle due idee. SSLE e SnSLE sono proposte concorrenti che potrebbero entrambe non essere implementate. Prima di distribuirle, necessitano di ulteriore ricerca e sviluppo, prototipazione e implementazione sulle reti di prova pubbliche. diff --git a/public/content/translations/it/roadmap/security/index.md b/public/content/translations/it/roadmap/security/index.md index 11dfbd8b335..35c21971e34 100644 --- a/public/content/translations/it/roadmap/security/index.md +++ b/public/content/translations/it/roadmap/security/index.md @@ -1,48 +1,48 @@ --- -title: Un Ethereum più sicuro -description: Ethereum è la piattaforma di contratti intelligenti più sicura e decentralizzata che esista. Tuttavia, restano ancora da implementare alcuni miglioramenti in modo che Ethereum resti resiliente a qualsiasi livello di attacco anche in un futuro lontano. +title: "Un Ethereum più sicuro" +description: "Ethereum è la piattaforma di contratti intelligenti più sicura e decentralizzata che esista. Tuttavia, restano ancora da implementare alcuni miglioramenti in modo che Ethereum resti resiliente a qualsiasi livello di attacco anche in un futuro lontano." lang: it image: /images/roadmap/roadmap-security.png alt: "Roadmap di Ethereum" template: roadmap --- -**Ethereum è già una piattaforma di [contratti intelligenti](/glossary/#smart-contract) molto sicura** e decentralizzata. Tuttavia, restano ancora da implementare alcuni miglioramenti in modo che Ethereum resti resiliente a qualsiasi tipo di attacco anche in un futuro lontano. Questi includono delle lievi modifiche al modo in cui i [client di Ethereum](/glossary/#consensus-client) affrontano i [blocchi](/glossary/#block) concorrenti, nonché l'aumento della velocità a cui la rete considera ["finalizzati"](/developers/docs/consensus-mechanisms/pos/#finality) i blocchi (a significare che non sono modificabili senza estreme perdite economiche da parte dell'utente malevolo). +**Ethereum è già una piattaforma di [contratti intelligenti](/glossary/#smart-contract) molto sicura** e decentralizzata. Tuttavia, restano ancora da implementare alcuni miglioramenti in modo che Ethereum resti resiliente a qualsiasi tipo di attacco anche in un futuro lontano. Queste includono lievi modifiche al modo in cui i [client di Ethereum](/glossary/#consensus-client) gestiscono i [blocchi](/glossary/#block) in competizione, oltre ad aumentare la velocità con cui la rete considera i blocchi ["finalizzati"](/developers/docs/consensus-mechanisms/pos/#finality) (ovvero che non possono essere modificati senza estreme perdite economiche per un aggressore). -Esistono anche dei miglioramenti che complicano la censura delle transazioni, rendendo i propositori di blocchi ciechi ai contenuti effettivi dei propri blocchi, e nuovi modi per identificare quando un client sta censurando. Insieme, questi miglioramenti aggiorneranno il protocollo di [proof-of-stake](/glossary/#pos) così che gli utenti, dai privati alle aziende, abbiano una fiducia istantanea nei propri dati, app e risorse su Ethereum. +Esistono anche dei miglioramenti che complicano la censura delle transazioni, rendendo i propositori di blocchi ciechi ai contenuti effettivi dei propri blocchi, e nuovi modi per identificare quando un client sta censurando. Insieme, questi miglioramenti aggiorneranno il protocollo [proof-of-stake](/glossary/#pos) in modo che gli utenti, dai singoli alle aziende, abbiano fiducia istantanea nelle loro app, dati e asset su Ethereum. -## Prelievi di staking {#staking-withdrawals} +## Prelievi dello staking {#staking-withdrawals} -L'aggiornamento dal [proof-of-work](/glossary/#pow) al proof-of-stake è iniziato quando i pionieri di Ethereum hanno messo i propri ETH in "staking" in un contratto di deposito. Tali ETH sono utilizzati per proteggere la rete. Si è verificato un secondo aggiornamento il 12 aprile 2023, per consentire il prelievo degli ETH in staking. Da allora i validatori possono mettere in staking o prelevare liberamente gli ETH. +L'aggiornamento da [proof-of-work](/glossary/#pow) a proof-of-stake è iniziato quando i pionieri di Ethereum hanno messo in “staking” i loro ETH in un contratto di deposito. Tali ETH sono utilizzati per proteggere la rete. Si è verificato un secondo aggiornamento il 12 aprile 2023, per consentire ai validatori di prelevare gli ETH in staking. Da allora i validatori possono mettere in staking o prelevare liberamente gli ETH. Informazioni sui prelievi -## Difendersi dagli attacchi {#defending-against-attacks} +## Difesa dagli attacchi {#defending-against-attacks} -Possono essere apportati dei miglioramenti al protocollo di proof-of-stake di Ethereum. Uno è noto come [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), un algoritmo di scelta della [biforcazione](/glossary/#fork) più sicuro, che rende più difficili certi tipi di attacchi più sofisticati. +Possono essere apportati dei miglioramenti al protocollo di proof-of-stake di Ethereum. Uno è noto come [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), un algoritmo di scelta della [biforcazione](/glossary/#fork) più sicuro che rende più difficili alcuni tipi di attacchi sofisticati. -Ridurre i tempi richiesti da Ethereum per [finalizzare](/glossary/#finality) i blocchi fornirebbe una migliore esperienza dell'utente e impedirebbe i sofisticati attacchi di "riorganizzazione", in cui gli utenti malevoli tentano di rimescolare i blocchi molto recenti per estrarne profitto o censurare certe transazioni. La [**finalità dello spazio singolo (SSF)**](/roadmap/single-slot-finality/) è un **metodo per ridurre al minimo il ritardo di finalizzazione**. In questo momento, esistono 15 minuti di blocchi, che un utente malevolo potrebbe teoricamente convincere altri validatori a riconfigurare. Con la SSF, ce ne sono 0. Gli utenti, dagli individui alle app e le piattaforme di scambio, beneficiano dalla veloce garanzia che le proprie transazioni non saranno ripristinate, e la rete ne beneficia arrestando un'intera classe di attacchi. +Ridurre il tempo che Ethereum impiega per [finalizzare](/glossary/#finality) i blocchi fornirebbe una migliore esperienza utente e preverrebbe sofisticati attacchi di "riorganizzazione" (reorg), in cui gli aggressori tentano di rimescolare i blocchi più recenti per estrarre profitto o censurare determinate transazioni. La [**finalità a slot singolo (SSF)**](/roadmap/single-slot-finality/) è un **modo per ridurre al minimo il ritardo di finalizzazione**. In questo momento, esistono 15 minuti di blocchi, che un utente malevolo potrebbe teoricamente convincere altri validatori a riconfigurare. Con la SSF, ce ne sono 0. Gli utenti, dagli individui alle app e le piattaforme di scambio, beneficiano dalla veloce garanzia che le proprie transazioni non saranno ripristinate, e la rete ne beneficia arrestando un'intera classe di attacchi. -Informazioni sulla finalità dello spazio singolo +Informazioni sulla finalità a slot singolo -## Difendersi dalla censura {#defending-against-censorship} +## Difesa dalla censura {#defending-against-censorship} -La decentralizzazione impedisce agli individui o ai piccoli gruppi di [validatori](/glossary/#validator) di diventare troppo influenti. Le nuove tecnologie di staking possono aiutare ad assicurare che i validatori di Ethereum restino il più decentralizzati possibile, difendendoli da guasti hardware, software e di rete. Questo include i software che condividono le responsablità del validatore tra più [nodi](/glossary/#node). Questo è noto come **tecnologia del validatore distribuita (DVT)**. I [gruppi di staking](/glossary/#staking-pool) sono incentivati a utilizzare la DVT, poiché consente a più computer di partecipare collettivamente alla validazione, aggiungendo ridondanza e tolleranza ai guasti. Inoltre, divide le chiavi del validatore tra diversi sistemi, piuttosto che far eseguire più validatori ai singoli operatori. Questo complica la coordinazione di attacchi tra operatori disonesti contro Ethereum. Nel complesso, l'idea è quella di ricavare benefici per la sicurezza, eseguendo i validatori come _comunità_ piuttosto che come individui. +La decentralizzazione impedisce a singoli individui o a piccoli gruppi di [validatori](/glossary/#validator) di diventare troppo influenti. Le nuove tecnologie di staking possono aiutare ad assicurare che i validatori di Ethereum restino il più decentralizzati possibile, difendendoli da guasti hardware, software e di rete. Questo include software che condivide le responsabilità dei validatori su più [nodi](/glossary/#node). Questa è nota come **tecnologia del validatore distribuito (DVT)**. Le [pool di staking](/glossary/#staking-pool) sono incentivate a usare la DVT perché permette a più computer di partecipare collettivamente alla validazione, aggiungendo ridondanza e tolleranza ai guasti. Inoltre, divide le chiavi del validatore tra diversi sistemi, piuttosto che far eseguire più validatori ai singoli operatori. Questo complica la coordinazione di attacchi tra operatori disonesti contro Ethereum. Nel complesso, l'idea è di ottenere vantaggi in termini di sicurezza eseguendo i validatori come _comunità_ piuttosto che come singoli individui. -Informazioni sulla tecnologia del validatore distribuita +Informazioni sulla tecnologia del validatore distribuito -L'implementazione della **separazione tra propositore e costruttore (PBS)** migliorerà drasticamente le difese integrate di Ethereum contro la censura. La PBS consente a ogni validatore di creare un blocco e un altro per trasmetterli per la rete di Ethereum. Questo assicura che i guadagni derivati dagli algoritmi di massimizzazione del profitto professionali di costruzione dei blocchi siano condivisi equamente per la rete, **impedendo la concentrazione dello stake** con gli staker istituzionali dalle migliori prestazioni nel tempo. Il propositore di blocchi seleziona il blocco più redditizio offertogli da un mercato di costruttori di blocchi. Per censurare, spesso un propositore di blocchi dovrebbe scegliere un blocco meno redditizio, che sarebbe **economicamente irrazionale e anche ovvio per il resto dei validatori** sulla rete. +L'implementazione della **separazione tra propositore e costruttore (PBS)** migliorerà drasticamente le difese integrate di Ethereum contro la censura. La PBS consente a ogni validatore di creare un blocco e un altro per trasmetterli per la rete di Ethereum. Ciò garantisce che i guadagni derivanti da algoritmi professionali di costruzione di blocchi che massimizzano il profitto siano condivisi più equamente attraverso la rete, **impedendo la concentrazione dello stake** presso gli staker istituzionali con le migliori prestazioni nel tempo. Il propositore di blocchi seleziona il blocco più redditizio offertogli da un mercato di costruttori di blocchi. Per censurare, un propositore di blocchi dovrebbe spesso scegliere un blocco meno redditizio, il che sarebbe **economicamente irrazionale e anche ovvio per il resto dei validatori** sulla rete. Esistono potenziali componenti aggiuntivi alla PBS, quali transazioni crittografate ed elenchi d'inclusione, che potrebbero ulteriormente migliorare la resistenza alla censura di Ethereum. Questi rendono il costruttore e il propositore di blocchi cieco alle transazioni effettive incluse nei propri blocchi. -Leggi sulla separazione tra propositore e costruttore +Informazioni sulla separazione tra propositore e costruttore -## Proteggere i validatori {#protecting-validators} +## Protezione dei validatori {#protecting-validators} -È possibile che un utente malevolo sofisticato possa identificare i prossimi validatori e spammarli per impedire loro di proporre blocchi; questo è noto come un attacco di **negazione del servizio (o DoS)**. L'implementazione dell'[**elezione segreta di un capo (SLE)**](/roadmap/secret-leader-election), proteggerà da questo tipo di attacchi, impedendo ai propositori di blocchi di essere noti in anticipo. Ciò funziona rimescolando continuamente una serie di impegni crittografici che rappresentano i propositori di blocchi candidati, e utilizzarne l'ordine per determinare quale validatore sia selezionato, in modo che soltanto gli stessi validatori sappiano il proprio ordine in anticipo. +È possibile che un aggressore sofisticato possa identificare i validatori imminenti e inondarli di spam per impedire loro di proporre blocchi; questo è noto come un attacco **di negazione del servizio (DoS)**. L'implementazione dell'[**elezione segreta del leader (SLE)**](/roadmap/secret-leader-election) proteggerà da questo tipo di attacco, impedendo che i propositori di blocchi siano conoscibili in anticipo. Ciò funziona rimescolando continuamente una serie di impegni crittografici che rappresentano i propositori di blocchi candidati, e utilizzarne l'ordine per determinare quale validatore sia selezionato, in modo che soltanto gli stessi validatori sappiano il proprio ordine in anticipo. -Leggi sull'elezione segreta di un capo +Informazioni sull'elezione segreta del leader -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} -**Gli aggiornamenti di sicurezza nella tabella di marcia sono in fasi di ricerca avanzate**, ma non dovrebbero essere implementati per un po'. I prossimi passaggi per view-merge, PBS, SSF e SLE sono quelli di finalizzazione di una specifica e inizio di costruzione dei prototipi. +**Gli aggiornamenti di sicurezza sulla roadmap sono in fasi di ricerca avanzate**, ma non se ne prevede l'implementazione a breve. I prossimi passi per view-merge, PBS, SSF e SLE sono finalizzare una specifica e iniziare a costruire prototipi. diff --git a/public/content/translations/it/roadmap/single-slot-finality/index.md b/public/content/translations/it/roadmap/single-slot-finality/index.md index d8e0bc0c4a6..2e616b13e1f 100644 --- a/public/content/translations/it/roadmap/single-slot-finality/index.md +++ b/public/content/translations/it/roadmap/single-slot-finality/index.md @@ -1,12 +1,12 @@ --- -title: Finalità dello spazio singolo -description: Spiegazione della finalità dello spazio singolo +title: "Finalità dello spazio singolo" +description: "Spiegazione della finalità dello spazio singolo" lang: it --- -# Finalità dello spazio singolo {#single-slot-finality} +# Finalità a slot singolo {#single-slot-finality} -Perché un blocco di Ethereum sia finalizzato, sono necessari circa 15 minuti. Tuttavia, possiamo far validare i blocchi al meccanismo di consenso di Ethereum, in modo più efficiente, riducendo drasticamente il tempo di finalizzazione. Invece di attendere quindici minuti, i blocchi potrebbero essere proposti e finalizzati nello stesso blocco. Questo concetto è noto come **finalità dello spazio singolo (o SSF)**. +Perché un blocco di Ethereum sia finalizzato, sono necessari circa 15 minuti. Tuttavia, possiamo far validare i blocchi al meccanismo di consenso di Ethereum, in modo più efficiente, riducendo drasticamente il tempo di finalizzazione. Invece di attendere quindici minuti, i blocchi potrebbero essere proposti e finalizzati nello stesso blocco. Questo concetto è noto come **finalità a slot singolo (SSF)**. ## Cos'è la finalità? {#what-is-finality} @@ -16,9 +16,9 @@ Nel meccanismo di consenso basato sul proof-of-stake di Ethereum, la finalità s I tempi correnti per la finalità sono diventati troppo lunghi. Gran parte degli utenti non vogliono attendere 15 minuti per la finalità ed è scomodo per app e piattaforme di scambio, che potrebbero volere un volume di transazione elevato per attendere così tanto, per essere certi che le proprie transazioni siano permanenti. Inoltre, avere un ritardo tra la proposta e la finalizzazione di un blocco, crea un'opportunità per delle brevi riorganizzazioni, che un utente malevolo potrebbe utilizzare per censurare certi blocchi, o estrarre il MEV. Il meccanismo che affronta l'aggiornamento dei blocchi in fasi, inoltre, è abbastanza complesso ed è stato corretto diverse volte per chiudere delle vulnerabilità di sicurezza, rendendolo una delle parti della base di codice di Ethereum in cui è più probabile che emergano piccoli bug. Questi problemi potrebbero essere eliminati riducendo il tempo alla finalità in un singolo spazio. -## Il compromesso tra decentralizzazione, tempo e costi di gestione {#the-decentralization-time-overhead-tradeoff} +## Il compromesso tra decentralizzazione, tempo e overhead {#the-decentralization-time-overhead-tradeoff} -La garanzia di finalità non è una proprietà immediata di un nuovo blocco: ci vuole del tempo affinché un nuovo blocco sia finalizzato. Il motivo è che i validatori che rappresentano almeno i 2/3 degli ETH in staking totali sulla rete, devono votare per il blocco ("attestarlo"), perché sia considerabile come finalizzato. Ogni nodo di convalida sulla rete deve elaborare le attestazioni dagli altri nodi per poter sapere se un blocco ha ottenuto tale soglia di 2/3 o no. +La garanzia di finalità non è una proprietà immediata di un nuovo blocco: ci vuole del tempo affinché un nuovo blocco sia finalizzato. Il motivo è che i validatori che rappresentano almeno i 2/3 degli ETH totali in staking sulla rete devono votare per il blocco ("attestarlo") affinché sia considerato finalizzato. Ogni nodo di convalida sulla rete deve elaborare le attestazioni dagli altri nodi per poter sapere se un blocco ha ottenuto tale soglia di 2/3 o no. Più è breve il tempo consentito per raggiungere la finalizzazione, maggiore è la potenza di calcolo necessaria a ogni nodo perché l'elaborazione dell'attestazione sia eseguita più velocemente. Inoltre, più nodi di convalida esistono sulla rete, più attestazioni devono essere elaborate per ogni blocco, da aggiungere alla potenza d'elaborazione necessaria. Più potenza di elaborazione è necessaria, meno persone possono partecipare a causa della necessità di hardware più costoso, per operare ogni nodo di convalida. Aumentare il tempo tra blocchi riduce la potenza di calcolo necessaria a ogni nodo ma allunga il tempo di finalizzazione, poiché le attestazioni sono elaborate più lentamente. @@ -31,9 +31,9 @@ Il meccanismo di consenso corrente di Ethereum equilibra questi tre parametri: Con l'attuale design del meccanismo, per poter ridurre il tempo di finalizzazione, è necessario ridurre il numero di validatori sulla rete o aumentare i requisiti hardware per ogni nodo. Tuttavia, esistono dei miglioramenti apportabili all'elaborazione delle attestazioni che possono consentire il conteggio di ulteriori attestazioni senza aumentare i costi di gestione di ogni nodo. L'elaborazione più efficiente consentirà la determinazione della finalità in un singolo spazio, piuttosto che su due epoche. -## Percorsi allo SSF {#routes-to-ssf} +## Percorsi verso la SSF {#routes-to-ssf} - + Il meccanismo di consenso attuale combina le attestazioni da più validatori, noti come commissioni, per ridurre il numero di messaggi che ogni validatore deve elaborare per convalidare un blocco. Ogni validatore ha l'opportunità di attestare in ogni epoca (32 spazi), ma in ogni spazio, soltanto un sottoinsieme di validatori attesta, noto come 'commissione'. Lo fanno dividendosi in reti secondarie, in cui alcuni validatori sono selezionati per essere 'aggregatori'. Questi combinano ognuno tutte le firme che vedono da altri validatori nella propria rete secondaria in una singola firma aggregata. L'aggregatore che include il numero massimo di singoli contributi, ne passa la firma aggregata al propositore di blocchi, che la include nel blocco insieme alla firma aggregata da altre commissioni. @@ -44,23 +44,23 @@ In questo schema, è possibile per ogni validatore, votare esclusivamente su un Dalla progettazione del meccanismo di consenso di Ethereum, lo schema di aggregazione delle firme (BLS), è stato ben più scalabile di quanto si pensasse inizialmente, mentre è stata migliorata anche l'abilità dei client di elaborare e verificare le firme. Si è scoperto che le attestazioni di elaborazione da un gran numero di validatori è in realtà possibile, entro un singolo spazio. Ad esempio, con un milione di validatori che votano due volte per ogni spazio e con i tempi dello spazio regolati a 16 secondi, i nodi dovrebbero verificare a un tasso minimo di 125.000 aggregazioni al secondo, per elaborare tutto il milione di attestazioni nello spazio. In realtà, un normale computer richiede circa 500 nanosecondi per eseguire la verifica di una firma, a significare che se ne possono eseguire 125.000 in circa 62,5 ms; molto meno della soglia di un secondo. -Ulteriori incrementi d'efficienza potrebbero derivare dalla creazione di super-commissioni di, ad esempio, 125.000 validatori selezionati casualmente, per spazio. Solo questi validatori possono votare su un blocco e, dunque, solo questo sottoinsieme di validatori decide se un blocco è finalizzato. La bontà di questa idea dipende dal costo che vorrebbe la community per un attacco di successo su Ethereum. Questo perché, invece di richiedere i 2/3 dell'ether in staking totale, un utente malevolo potrebbe finalizzare un blocco disonesto con i 2/3 degli ether in staking _in quella super-commissione_. Questa è un'area di ricerca ancora attiva, ma sembra plausibile che perché un insieme di validatori sia abbastanza grande da richiedere le super-commissioni, il costo di attaccarne una sarebbe estremamente elevato (es., il costo denominato di ETH dell'attacco sarebbe di `2/3 * 125.000 * 32 = circa 2,6 milioni di ETH`). Il costo dell'attacco è regolabile aumentando le dimensioni dell'insieme di validatori (ad esempio, regolando le dimensioni del validatore, così che il costo dell'attacco sia pari a 1 milione di ether, 4 milioni di ether, 10 milioni di ether, etc.). I [sondaggi preliminari](https://youtu.be/ojBgyFl6-v4?t=755) della community sembrano suggerire che 1-2 milioni di ether siano un costo accettabile dell'attacco, implicando circa da 65.536 a 97.152 validatori per super-commissione. +Ulteriori guadagni di efficienza potrebbero essere ottenuti creando supercommissioni di, ad esempio, 125.000 validatori selezionati casualmente per slot. Solo questi validatori possono votare su un blocco e, dunque, solo questo sottoinsieme di validatori decide se un blocco è finalizzato. La bontà di questa idea dipende dal costo che vorrebbe la community per un attacco di successo su Ethereum. Questo perché, invece di richiedere i 2/3 del totale di ether in staking, un aggressore potrebbe finalizzare un blocco disonesto con i 2/3 degli ether in staking _in quella supercommissione_. Questa è ancora un'area di ricerca attiva, ma sembra plausibile che, per un set di validatori sufficientemente grande da richiedere le supercommissioni, il costo di attaccare uno di quei sottocomitati sarà estremamente elevato (ad esempio, il costo dell'attacco denominato in ETH sarebbe di `2/3 * 125.000 * 32 = ~2.6 milioni di ETH`). Il costo dell'attacco può essere regolato aumentando le dimensioni del set di validatori (ad esempio, regolando le dimensioni del set di validatori in modo che il costo dell'attacco sia pari a 1 milione di ether, 4 milioni di ether, 10 milioni di ether, ecc.). [Sondaggi preliminari](https://youtu.be/ojBgyFl6-v4?t=755) della community sembrano suggerire che 1-2 milioni di ether siano un costo d'attacco accettabile, il che implica ~65.536 - 97.152 validatori per supercommissione. -Tuttavia, la verifica non è la vera impasse: è l'aggregazione della firma a sfidare realmente i nodi del validatore. Ridimensionare l'aggregazione delle firme richiederebbe probabilmente l'aumento del numero di validatori per ogni rete secondaria, aumentandone il numero, o aggiungendo ulteriori livelli d'aggregazione (cioè, implementando commissioni delle commissioni). Parte della soluzione potrebbe essere consentire degli agreggatori specializzati, similmente a come la costruzione del blocco e la generaazione degli impegni per i dati dei rollup sarà affidata a costruttori di blocchi specializzati, sotto la separazione propositore-costruttore (PBS) e il Danksharding. +Tuttavia, la verifica non è la vera impasse: è l'aggregazione della firma a sfidare realmente i nodi del validatore. Per scalare l'aggregazione delle firme, sarà probabilmente necessario aumentare il numero di validatori in ogni sottorete, aumentare il numero di sottoreti o aggiungere ulteriori livelli di aggregazione (cioè, implementare commissioni di commissioni). Parte della soluzione potrebbe essere consentire degli agreggatori specializzati, similmente a come la costruzione del blocco e la generaazione degli impegni per i dati dei rollup sarà affidata a costruttori di blocchi specializzati, sotto la separazione propositore-costruttore (PBS) e il Danksharding. -## Qual è il ruolo della regola di scelta della biforcazione nello SSF? {#role-of-the-fork-choice-rule} +## Qual è il ruolo della regola di scelta della biforcazione nello SSF? Ruolo della regola di scelta della biforcazione {#role-of-the-fork-choice-rule} -Il meccanismo del consenso odierno si affida a un rigoroso accoppiamento tra il dispositivo di finalità (l'algoritmo che determina se i 2/3 dei validatori hanno attestato a una certa catena) e la regola di scelta della biforcazione (l'algoritmo che decide quale catena è quella corretta, quando ci sono più opzioni). L'algoritmo di scelta della biforcazione considera soltanto i blocchi _dall'_ultimo blocco finalizzato. Sotto lo SSF, non ci sarebbe alcun blocco da considerare per la regola di scelta della biforcazione, poiché la finalità si verifica nello stesso spazio in cui è proposto il blocco. Ciò significa che sotto lo SSF, l'algoritmo di scelta _o___ il dispositivo di finalità sarebbero attivi in ogni momento. Il dispositivo di finalità finalizzerebbe i blocchi in cui i 2/3 dei validatori erano online e stavano attestando in modo onesto. Se un blocco non riuscisse a superare la soglia dei 2/3, la regola di scelta della biforcazione entrerebbe in gioco per determinare quale catena seguire. Questo, inoltre, crea un'opportunità per mantenere il meccanismo di perdita dell'inattività che recupera una catena in cui >1/3 dei validatori è offline, sebbene con delle sfumature aggiuntive. +Il meccanismo del consenso odierno si affida a un rigoroso accoppiamento tra il dispositivo di finalità (l'algoritmo che determina se i 2/3 dei validatori hanno attestato a una certa catena) e la regola di scelta della biforcazione (l'algoritmo che decide quale catena è quella corretta, quando ci sono più opzioni). L'algoritmo di scelta della biforcazione considera solo i blocchi _a partire dall'_ultimo blocco finalizzato. Sotto lo SSF, non ci sarebbe alcun blocco da considerare per la regola di scelta della biforcazione, poiché la finalità si verifica nello stesso spazio in cui è proposto il blocco. Ciò significa che con l'SSF, in qualsiasi momento sarebbe attivo _o_ l'algoritmo di scelta della biforcazione _o_ il gadget di finalità. Il dispositivo di finalità finalizzerebbe i blocchi in cui i 2/3 dei validatori erano online e stavano attestando in modo onesto. Se un blocco non riuscisse a superare la soglia dei 2/3, la regola di scelta della biforcazione entrerebbe in gioco per determinare quale catena seguire. Questo crea anche l'opportunità di mantenere il meccanismo di "fuga di inattività" che recupera una catena in cui >1/3 dei validatori va offline, sebbene con alcune sfumature aggiuntive. -## Questioni irrisolte {#outstanding-issues} +## Questioni aperte {#outstanding-issues} -Il problema con il ridimensionamento dell'aggregazione, aumentando il numero di validatori per rete secondaria è che comporta un maggiore carico sulla rete tra pari. Il problema con l'aggiunta di livelli di aggregazioni è che è abbastanza complesso progettare e aggiungere latenza (cioè, potrebbe volerci di più per il propositore del blocco di ricevere da tutti gli aggregatori della rete secondaria). Inoltre, non è chiaro come affrontare lo scenario in cui ci siano più validatori attivi sulla rete di quanti fattibilmente ne possano essere elaborati in ogni spazio, anche con l'aggregazione di firme BLS. Una soluzione potenziale è che, poiché tutti i validatori attestano in ogni slot e non esistono commissioni sotto lo SSF, il limite di 32 ETH sul saldo effettivo potrebbe essere interamente rimosso, a significare che gli operatori che gestiscono più validatori potrebbero consolidare i propri ETH in staking ed eseguirne meno, riducendo il numero di messaggi che i nodi di convalida devono elaborare per tenere conto dell'intero insieme di validatori. Ciò si affida sull'accordo da parte dei grandi staker, di consolidare i propri validatori. Inoltre, è possibile imporre un limite fisso sul numero di validatori o sull'importo di ETH in staking, in ogni momento. Tuttavia, ciò richiede dei meccanismi per decidere quali validatori possono partecipare e quali no, responsabili di creare effetti secondari indesiderati. +Il problema con il ridimensionamento dell'aggregazione, aumentando il numero di validatori per rete secondaria è che comporta un maggiore carico sulla rete tra pari. Il problema con l'aggiunta di livelli di aggregazione è che è un'operazione complessa da ingegnerizzare e aggiunge latenza (cioè, potrebbe volerci più tempo perché il propositore del blocco riceva un riscontro da tutti gli aggregatori delle sottoreti). Inoltre, non è chiaro come affrontare lo scenario in cui ci siano più validatori attivi sulla rete di quanti fattibilmente ne possano essere elaborati in ogni spazio, anche con l'aggregazione di firme BLS. Una soluzione potenziale è che, poiché tutti i validatori attestano in ogni slot e non esistono commissioni sotto lo SSF, il limite di 32 ETH sul saldo effettivo potrebbe essere interamente rimosso, a significare che gli operatori che gestiscono più validatori potrebbero consolidare i propri ETH in staking ed eseguirne meno, riducendo il numero di messaggi che i nodi di convalida devono elaborare per tenere conto dell'intero insieme di validatori. Ciò si affida sull'accordo da parte dei grandi staker, di consolidare i propri validatori. Inoltre, è possibile imporre un limite fisso sul numero di validatori o sull'importo di ETH in staking, in ogni momento. Tuttavia, ciò richiede dei meccanismi per decidere quali validatori possono partecipare e quali no, responsabili di creare effetti secondari indesiderati. -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} -Lo SSF è nella fase di ricerca. Non dovrebbe essere rilasciata per svariati anni, probabilmente dopo altri aggiornamenti sostanziali come gli [alberi di Verkle](/roadmap/verkle-trees/) e il [Danksharding](/roadmap/danksharding/). +Lo SSF è nella fase di ricerca. Non è previsto il suo rilascio per diversi anni, probabilmente dopo altri aggiornamenti sostanziali come gli [alberi di Verkle](/roadmap/verkle-trees/) e il [Danksharding](/roadmap/danksharding/). ## Letture consigliate {#further-reading} -- [Vitalik sullo SSF all'EDCON 2022](https://www.youtube.com/watch?v=nPgUKNPWXNI) -- [Note di Vitalik: Percorsi alla finalità dello spazio singolo](https://notes.ethereum.org/@vbuterin/single_slot_finality) +- [Vitalik su SSF a EDCON 2022](https://www.youtube.com/watch?v=nPgUKNPWXNI) +- [Note di Vitalik: percorsi verso la finalità a slot singolo](https://notes.ethereum.org/@vbuterin/single_slot_finality) diff --git a/public/content/translations/it/roadmap/statelessness/index.md b/public/content/translations/it/roadmap/statelessness/index.md index f53aba916d2..700ab5521a1 100644 --- a/public/content/translations/it/roadmap/statelessness/index.md +++ b/public/content/translations/it/roadmap/statelessness/index.md @@ -4,7 +4,7 @@ description: Spiegazione della scadenza dello storico e dell'assenza di stato su lang: it --- -# Assenza di stato, scadenza di stato e scadenza dello storico {#statelessness} +# Assenza di stato, scadenza dello stato e scadenza dello storico {#statelessness} L'abilità di operare i nodi di Ethereum su hardware modesti è fondamentale per la vera decentralizzazione. Questo perché operare un nodo da' agli utenti la possibilità di verificare le informazioni, eseguendo controlli crittografici indipendentemente, piuttosto che fidandosi di una terza parte per alimentare i dati. Eseguire un nodo consente agli utenti di inviare le transazioni direttamente alla rete tra pari di Ethereum, piuttosto che doversi fidare di un intermediario. La decentralizzazione non è possibile se tali benefici sono disponibili soltanto per gli utenti con hardware costoso. Invece, i nodi dovrebbero poter operare con requisiti di elaborazione e memoria estremamente modesti, così che possano funzionare su dispositivi mobili, micro-computer o impercettibilmente su un computer di casa. @@ -12,12 +12,12 @@ Oggi, i requisiti di spazio su disco sono la principale barriera che impedisce l Dischi rigidi più economici sono utilizzabili per memorizzare i dati più vecchi, ma sono troppo lenti per tenere il passo con i blocchi in entrata. Mantenere i modelli di archiviazione correnti per i client mentre i dati diventano più economici e facili da archiviare è soltanto temporaneo e, una soluzione parziale al problema, poiché la crescita dello stato di Ethereum è 'senza limiti', a significare che i requisiti d'archiviazione possono soltanto aumentare e, i miglioramenti tecnologici dovranno sempre mantenere il passo con la continua crescita di stato. Invece, i client devono trovare metodi per verificare i blocchi e le transazioni, senza affidarsi alla ricerca dei dati sui database locali. -## Ridurre l'archiviazione per i nodi {#reducing-storage-for-nodes} +## Riduzione dell'archiviazione per i nodi {#reducing-storage-for-nodes} Esistono diversi modi per ridurre la quantità di dati che ciascun nodo deve archiviare, ciascuno dei quali richiede che il protocollo principale di Ethereum venga aggiornato in misura diversa: - **Scadenza dello storico**: consente ai nodi di scartare i dati di stato più vecchi di X blocchi, senza tuttavia modificare la gestione dei dati di stato da parte del client di Ethereum. -- **Scadenza di stato**: consente ai dati di staato non utilizzati di frequente di divenire inattivi. I dati inattivi sono ignorabili dai client, finché non sono "resuscitati". +- **Scadenza dello stato**: consente ai dati di stato non utilizzati di frequente di diventare inattivi. I dati inattivi sono ignorabili dai client, finché non sono "resuscitati". - **Assenza di stato debole**: solo i produttori di blocchi necessitano dell'accesso ai dati di stato completi, altri nodi possono verificare i blocchi senza un database di stato locale. - **Assenza di stato forte**: nessun nodo necessita dell'accesso ai dati di stato completi. @@ -42,9 +42,9 @@ La scadenza di stato fa riferimento alla rimozione dello stato dai singoli nodi, - **Scadenza per noleggio**: addebitando un "noleggio" ai conti e facendoli scadere quando il noleggio raggiunge lo zero - **Scadenza per tempo**: rendendo i conti inattivi se non si verifica alcuna lettura/scrittura a quel conto, per un dato periodo di tempo -La scadenza per noleggio potrebbe essere un noleggio diretto addebitato ai conti per mantenerli nel database dello stato attivo. La scadenza per tempo potrebbe essere un conto alla rovescia dall'ultima interazione del conto, o una scadenza periodica di tutti i conti. Potrebbero inoltre esistere dei meccanismi che combinano gli elementi dei modelli basati su tempo e affitto, ad esempio, i conti individuali persistono nello stato attivo se pagano delle piccole commissioni, prima della scadenza. Con la scadenza di stato è importante notare che lo stato inattivo **non è eliminato**, è soltanto memorizzato separatamente da quello attivo. Lo stato inattivo può essere resuscitato nello stato attivo. +La scadenza per noleggio potrebbe essere un noleggio diretto addebitato ai conti per mantenerli nel database dello stato attivo. La scadenza per tempo potrebbe essere un conto alla rovescia dall'ultima interazione del conto, o una scadenza periodica di tutti i conti. Potrebbero inoltre esistere dei meccanismi che combinano gli elementi dei modelli basati su tempo e affitto, ad esempio, i conti individuali persistono nello stato attivo se pagano delle piccole commissioni, prima della scadenza. Con la scadenza dello stato è importante notare che lo stato inattivo **non viene eliminato**, è solo archiviato separatamente dallo stato attivo. Lo stato inattivo può essere resuscitato nello stato attivo. -Questo dovrebbe probabilmente funzionare con un albero di stato per periodi di tempo specifici (forse di circa 1 anno). Ogni volta che inizia un nuovo periodo, inizia un albero di stato completamente nuovo. Solo l'albero di stato corrente è modificabile, tutti gli altri sono immutabili. I nodi di Ethereum devono contenere soltanto l'albero di stato corrente e il successivo più recente. Questo richiede un metodo per mettere in sequenza un indirizzo, con il periodo in cui esiste. Esistono [svariati metodi possibili](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607) per farlo, ma l'opzione principale richiede l'[allungamento degli indirizzi](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) per accomodare le informazioni aggiuntive, con il beneficio aggiunto che gli indirizzi più lunghi sono più sicuri. Il punto della tabella di marcia che fa questo è detto [estensione dello spazio dell'indirizzo](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485). +Questo dovrebbe probabilmente funzionare con un albero di stato per periodi di tempo specifici (forse di circa 1 anno). Ogni volta che inizia un nuovo periodo, inizia un albero di stato completamente nuovo. Solo l'albero di stato corrente è modificabile, tutti gli altri sono immutabili. I nodi di Ethereum devono contenere soltanto l'albero di stato corrente e il successivo più recente. Questo richiede un metodo per mettere in sequenza un indirizzo, con il periodo in cui esiste. Ci sono [diversi modi possibili](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607) per farlo, ma l'opzione principale richiede che [gli indirizzi vengano allungati](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) per contenere le informazioni aggiuntive, con l'ulteriore vantaggio che indirizzi più lunghi sono molto più sicuri. L'elemento della tabella di marcia che fa questo è chiamato [estensione dello spazio degli indirizzi](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485). Analogamente alla scadenza dello storico, sotto la scadenza di stato, la responsabilità di memorizzare i vecchi dati di stato è rimossa dai singoli utenti e spinta ad altre entità, come fornitori centralizzati, membri altruisti dell community o soluzioni decentralizzate più futuristiche, come la Portal Network. @@ -56,7 +56,7 @@ L'assenza di stato è un termine un po' improprio perché non si riferisce al co - sincronizzazione quasi istantanea - abilità di convalidare i blocchi fuori ordine -- nodi capaci di operare con requisiti hardware molto ridotti (es. su telefoni) +- nodi in grado di funzionare con requisiti hardware molto bassi (ad es., sui telefoni) - nodi che operano su dischi rigidi economici, perché non è richiesta alcuna lettura/scrittura del disco - compatibilità con aggiornamenti futuri alla crittografia di Ethereum @@ -66,7 +66,7 @@ L'assenza di stato debole richiede modifiche a come i nodi di Ethereum verifican **Nell'assenza di stato debole, la proposta dei blocchi richiede l'accesso ai dati di stato completi, ma la verifica dei blocchi no** -Perché ciò si verifichi, gli [alberi di Verkle](/roadmap/verkle-trees/) devono già essere stati implementati nei client di Ethereum. Gli alberi di Verkle sono strutture di dati sostitutive per memorizzare i dati di stato di Ethereum, che consentono a "testimoni" di dati di dimensioni ridotte e fisse, di essere passati tra i pari e utilizzati per verificare i blocchi, invece di verificarli rispetto ai database locali. Anche la [separazione tra propositori e costruttori](/roadmap/pbs/) è necessaria poiché consente ai costruttori di blocchi di essere nodi specializzati con hardware più potente, essendo coloro che necessitano di accedere ai dati di stato completi. +Perché ciò si verifichi, gli [alberi di Verkle](/roadmap/verkle-trees/) devono essere già stati implementati nei client di Ethereum. Gli alberi di Verkle sono strutture di dati sostitutive per memorizzare i dati di stato di Ethereum, che consentono a "testimoni" di dati di dimensioni ridotte e fisse, di essere passati tra i pari e utilizzati per verificare i blocchi, invece di verificarli rispetto ai database locali. È richiesta anche la [separazione tra propositori e costruttori](/roadmap/pbs/) poiché consente ai costruttori di blocchi di essere nodi specializzati con hardware più potente, e sono quelli che richiedono l'accesso ai dati di stato completi. @@ -85,19 +85,21 @@ L'assenza di stato forte rimuove l'esigenza per qualsiasi nodo di memorizzare i L'assenza di stato forte è stata investigata dai ricercatori, ma non è correntemente previsto che diventi parte della tabella di marcia di Ethereum: è più probabile che l'assenza di stato debole sia sufficiente per le esigenze di ridimensionamento di Ethereum. -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} -L'assenza di stato debole, la scadenza dello storico e la scadenza dello stato sono tutte in fase di ricerca ed è previsto siano distribuite tra svariati anni. Non esiste alcuna garanzia che tutte queste proposte saranno implementate, ad esempio, se la scadenza di stato è implementate per prima, non sarebbe necessario implementare anche la scadenza dello storico. Esistono anche altri punti della tabella di marcia, come gli [Alberi di Verkle](/roadmap/verkle-trees) e la [Separazione tra propositori e costruttori](/roadmap/pbs), che necessitano di essere completati per primi. +L'assenza di stato debole, la scadenza dello storico e la scadenza dello stato sono tutte in fase di ricerca ed è previsto siano distribuite tra svariati anni. Non esiste alcuna garanzia che tutte queste proposte saranno implementate, ad esempio, se la scadenza di stato è implementate per prima, non sarebbe necessario implementare anche la scadenza dello storico. Ci sono anche altri elementi della tabella di marcia, come gli [alberi di Verkle](/roadmap/verkle-trees) e la [separazione tra propositori e costruttori](/roadmap/pbs/), che devono essere completati per primi. ## Letture consigliate {#further-reading} -- [AMA sull'assenza di stato di Vitalik](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) +- [Cos'è l'Ethereum stateless?](https://stateless.fyi/) +- [AMA di Vitalik sull'assenza di stato](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) - [Una teoria sulla gestione delle dimensioni dello stato](https://hackmd.io/@vbuterin/state_size_management) -- [Limitazione dello stato di risurrezione e conflitto minimizzati](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) -- [Percorsi all'assenza di stato e alla scadenza dello stato](https://hackmd.io/@vbuterin/state_expiry_paths) -- [Specifiche dell'EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) -- [Alex Stokes sull'EIP-4444](https://youtu.be/SfDC_qUZaos) -- [Perché l'assenza di stato è così importante](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) -- [Le note del concetto originale del client privo di stato](https://ethresear.ch/t/the-stateless-client-concept/172) -- [Informazioni sulla scadenza dello stato](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) -- [Ulteriori informazioni sulla scadenza di stato](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) +- [Resurrection-conflict-minimized state bounding](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) +- [Percorsi verso l'assenza di stato e la scadenza dello stato](https://hackmd.io/@vbuterin/state_expiry_paths) +- [Specifica EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) +- [Alex Stokes su EIP-4444](https://youtu.be/SfDC_qUZaos) +- [Perché è così importante diventare stateless](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) +- [Le note sul concetto originale di client stateless](https://ethresear.ch/t/the-stateless-client-concept/172) +- [Approfondimenti sulla scadenza dello stato](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) +- [Ulteriori approfondimenti sulla scadenza dello stato](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) +- [Pagina informativa sull'Ethereum stateless](https://stateless.fyi) diff --git a/public/content/translations/it/roadmap/user-experience/index.md b/public/content/translations/it/roadmap/user-experience/index.md index 2748d708027..87974dab360 100644 --- a/public/content/translations/it/roadmap/user-experience/index.md +++ b/public/content/translations/it/roadmap/user-experience/index.md @@ -1,36 +1,36 @@ --- title: Migliorare l'esperienza degli utenti -description: Per molti, è ancora troppo complesso utilizzare Ethereum. Per incoraggiare l'adozione di massa, Ethereum deve ridurre drasticamente le proprie barriere d'accesso; gli utenti devono ricevere i benefici dell'accesso decentralizzato, privo di permessi e resistente alla censura a Ethereum, ma dev'essere privo di frizione, tanto quanto utilizzare una tradizionale app del web2. +description: "Per molti, è ancora troppo complesso utilizzare Ethereum. Per incoraggiare l'adozione di massa, Ethereum deve ridurre drasticamente le proprie barriere d'accesso; gli utenti devono ricevere i benefici dell'accesso decentralizzato, privo di permessi e resistente alla censura a Ethereum, ma dev'essere privo di frizione, tanto quanto utilizzare una tradizionale app del web2." lang: it image: /images/roadmap/roadmap-ux.png alt: "Roadmap di Ethereum" template: roadmap --- -**L'utilizzo di Ethereum dev'essere semplificato**; dalla gestione di [chiavi](/glossary/#key) e [portafogli](/glossary/#wallet) avvio di transazioni. Per facilitare l'adozione di massa, Ethereum deve aumentare drasticamente la facilità d'uso, consentendo agli utenti di sperimentare un accesso privo di permessi e resistente alla censura a Ethereum, con l'esperienza priva di attrito dell'utilizzo delle app [Web2](/glossary/#web2). +**L'utilizzo di Ethereum deve essere semplificato**; dalla gestione di [chiavi](/glossary/#key) e [portafogli](/glossary/#wallet) all'avvio delle transazioni. Per facilitare l'adozione di massa, Ethereum deve aumentare drasticamente la facilità d'uso, consentendo agli utenti di sperimentare un accesso senza permessi e resistente alla censura a Ethereum, con l'esperienza fluida dell'utilizzo delle app [Web2](/glossary/#web2). -## Oltre le frasi di seed {#no-more-seed-phrases} +## Oltre le frasi seed {#no-more-seed-phrases} I conti di Ethereum sono protetti da una coppia di chiavi, utilizzate per identificare i conti (chiave pubblica) e firmare i messaggi (chiave privata). Una chiave privata è come una password principale; consente di completare l'accesso a un conto di Ethereum. Questo è un metodo di operazione differente per le persone che hanno più dimestichezza con le banche e le app Web2, che gestiscono i conti per conto di un utente. Perché Ethereum raggiunga l'adozione di massa senza affidarsi a terze parti centralizzate, deve esistere un metodo diretto e privo di attrito per un utente, per prendere custodia delle proprie risorse e mantenere il controllo dei propri dati senza dover comprendere la crittografia delle chiavi pubbliche e private e la gestione delle chiavi. La soluzione è utilizzare portafogli di [contratti intelligenti](/glossary/#smart-contract) per interagire con Ethereum. I portafogli di contratti intelligenti creano modi per proteggere i conti se le chiavi sono perdute o rubate, opportunità per un migliore rilevamento e difesa dalle truffe e consentono ai portafogli di ottenere nuove funzionalità. Sebbene i portafogli di contratti intelligenti esistano oggi, sono imbarazzanti da creare perché il protocollo di Ethereum necessita di supportarli meglio. Questo supporto aggiuntivo è noto come astrazione del conto. -Di più sull'astrazione del conto +Maggiori informazioni sull'astrazione del conto ## Nodi per tutti -Gli utenti che eseguono [nodi](/glossary/#node) non devono fidarsi di terze parti per fornire loro i dati, e possono interagire rapidamente, privatamente e senza permessi con la [blockchain](/glossary/#blockchain) di Ethereum. Tuttavia, al momento, operare un nodo richiede una conoscenza tecnica e sostanziale spazio su disco, a significare che molte persone devono invece fidarsi degli intermediari. +Gli utenti che eseguono [nodi](/glossary/#node) non devono fidarsi di terze parti per la fornitura dei dati e possono interagire in modo rapido, privato e senza permessi con la [blockchain](/glossary/#blockchain) di Ethereum. Tuttavia, al momento, operare un nodo richiede una conoscenza tecnica e sostanziale spazio su disco, a significare che molte persone devono invece fidarsi degli intermediari. -Esistono diversi aggiornamenti che semplificheranno l'esecuzione dei nodi, riducendo di molto il consumo di risorse. Il metodo di archiviazione dei dati sarà modificato per utilizzare una struttura molto più efficiente a livello di spazio, nota come **Albero di Verkle**. Inoltre, con l'[assenza di stato](/roadmap/statelessness) o la [scadenza dei dati](/roadmap/statelessness/#data-expiry), i nodi di Ethereum non dovranno memorizzare una copia degli interi dati di stato di Ethereum, riducendo drasticamente i requisiti di spazio su disco. I [nodi leggeri](/developers/docs/nodes-and-clients/light-clients/) offriranno molti benefici dell'operare un nodo completo, ma potranno facilmente operare su smartphone o in semplici app per browser. +Esistono diversi aggiornamenti che semplificheranno l'esecuzione dei nodi, riducendo di molto il consumo di risorse. Il metodo di archiviazione dei dati sarà modificato per utilizzare una struttura più efficiente in termini di spazio, nota come un **Albero di Verkle**. Inoltre, con l'[assenza di stato](/roadmap/statelessness) o la [scadenza dei dati](/roadmap/statelessness/#data-expiry), i nodi di Ethereum non dovranno memorizzare una copia dell'intero stato di Ethereum, riducendo drasticamente i requisiti di spazio su disco. I [nodi leggeri](/developers/docs/nodes-and-clients/light-clients/) offriranno molti dei vantaggi dell'esecuzione di un nodo completo, ma potranno essere eseguiti facilmente su telefoni cellulari o all'interno di semplici app per browser. -Leggi di più sugli alberi di Verkle +Scopri di più sugli Alberi di Verkle Con questi aggiornamenti, le barriere all'esecuzione di un nodo sono ridotte effettivamente a zero. Gli utenti beneficeranno di un accesso sicuro e privo di permessi a Ethereum, senza dover sacrificare notevole spazio su disco o CPU sul proprio computer o il proprio dispositivo mobile e non dovranno affidarsi a terze parti per l'accesso a dati o alla rete, utilizzando le app. -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} -I portafogli di contratti intelligenti sono già disponibili, ma sono necessari maggiori aggiornamenti per renderli il più decentralizzati e privi di permessi possibile. L'EIP-4337 è una proposta matura che non richiede alcuna modifica al protocollo di Ethereum. Il contratto intelligente principale necessario per l'EIP-4337 è stato **distribuito a marzo 2023**. +I portafogli di contratti intelligenti sono già disponibili, ma sono necessari maggiori aggiornamenti per renderli il più decentralizzati e privi di permessi possibile. L'EIP-4337 è una proposta matura che non richiede alcuna modifica al protocollo di Ethereum. Il contratto intelligente principale richiesto per l'EIP-4337 è stato **distribuito a marzo 2023**. -**L'assenza di stato completa è ancora in fase di ricerca** e potrebbe richiedere svariati anni per essere implementata. Esistono diverse pietre miliari sul percorso alla completa assenza di stato, inclusa la scadenza dei dati, che potrebbe essere implementata prima. Devono prima essere completati altri punti della tabella di marcia, come gli [Alberi di Verkle](/roadmap/verkle-trees/) e la [Separazione tra propositori e costruttori](/roadmap/pbs/). +**L'assenza di stato completa è ancora in fase di ricerca** ed è probabile che manchino diversi anni prima che venga implementata. Esistono diverse pietre miliari sul percorso alla completa assenza di stato, inclusa la scadenza dei dati, che potrebbe essere implementata prima. Altri elementi della tabella di marcia, come gli [Alberi di Verkle](/roadmap/verkle-trees/) e la [separazione tra propositori e costruttori](/roadmap/pbs/), devono essere completati per primi. Le reti di prova degli alberi di Verkle sono già in esecuzione e la prossima fase, consiste nell'operare client che consentano gli alberi di Verkle su reti pubbliche dapprima private, quindi pubbliche. Puoi aiutare ad accelerare il progresso distribuendo contratti alle reti di prova od operando dei client delle reti di prova. diff --git a/public/content/translations/it/roadmap/verkle-trees/index.md b/public/content/translations/it/roadmap/verkle-trees/index.md index 59cae3a2e7c..52560d7342a 100644 --- a/public/content/translations/it/roadmap/verkle-trees/index.md +++ b/public/content/translations/it/roadmap/verkle-trees/index.md @@ -15,15 +15,14 @@ Gli alberi di Verkle (un neologismo tra "Impegno Vettoriale" e "Alberi di Merkle Gli alberi di Verkle sono un passaggio fondamentale sul percorso per i client di Ethereum privi di stato. I client privi di stato sono quelli che non devono memorizzare l'intero database di stato per poter convalidare i blocchi in entrata. Invece di utilizzare la propria copia dello stato di Ethereum per verificare i blocchi, utilizzano un "testimone" ai dati di stato che arriva con il blocco. Un testimone è una raccolta di pezzi individuali dei dati di stato, necessaria per eseguire una serie particolare di transazioni, nonché una prova crittografica che il testimone sia davvero parte dei dati completi. Il testimone è utilizzato _invece_ del database di stato. Perché funzioni, i testimoni devono essere molto piccoli, così che siano trasmissibili in sicurezza per la rete, in tempo per essere convalidati dai validatori entro uno spazio di 12 secondi. La struttura attuale dei dati di stato non è adatta, poiché i testimoni sono troppo grandi. Gli alberi di Verkle risolvono questo problema consentendo piccoli testimoni e rimuovendo una delle principali barriere ai client privi di stato. - + I client di Ethereum, al momento, utilizzano una struttura di dati nota come Albero di Patricia di Merkle per memorizzarne i dati di stato. Le informazioni sui singoli conti sono memorizzati come foglie su un albero e, le coppie di foglie, ricevono ripetutamente un hash finché non ne resta soltanto uno. Questo hash finale è noto come la "radice". Per verficare i blocchi, i client di Ethereum eseguono tutte le transazioni in un blocco e aggiornano il proprio albero di stato locale. Il blocco è considerato valido se la radice dell'albero locale è identica a quella fornita dal propositore di blocchi, poiché qualsiasi differenza nel calcolo effettuato dal propositore del blocco e dal nodo di convalida, formerebbe un hash di radice completamente differente. Il problema è che la verifica della blockchain richiede che ogni client memorizzi l'intero albero di stato per il blocco di testa e per diversi blocchi storici (di default, su Geth, sono mantenuti i dati di stato per 128 blocchi oltre la testa). Ciò richiede che i client abbiano accesso a una grande quantità di spazio su disco, limitando l'esecuzione dei nodi completi su hardware economici e poco potenti. Una soluzione è aggiornare l'albero di stato a una struttura più efficiente (l'albero di Verkle), riepilogabile utilizzando un piccolo "testimone" ai dati, condivisibile invece dei dati di stato completi. Riformattare i dati di stato in un albero di Verkle è una pietra miliare per spostarsi verso i client privi di stato. - ## Cos'è un testimone e perché è necessario? {#what-is-a-witness} -Verificare un blocco significa rieseguire le transazioni contenute nel blocco, applicando le modifiche all'albero di stato di Ethereum e calcolando il nuovo hash della radice. Un blocco verificato è uno il cui hash della radice di stato calcolato equivale a quello fornito con il blocco (poiché ciò preclude che il propositore del blocco abbia realmente effettuato il calcolo che dice di aver effettuato). Nei client odierni di Ethereum, aggiornare lo stato richiede l'accesso all'intero albero di stato, una grande struttura di dati che dev'essere archiviata localmente. Un testimone contiene soltanto i frammenti dei dati di stato necessari per eseguire le transazioni nel blocco. Un validatore può quindi utilizzare soltanto quei frammenti per verificare che il propositore di blocchi abbia eseguito le transazioni del blocco e aggiornato correttamente lo stato. Tuttavia, ciò significa che il testimone dev'essere trasferito tra i pari sulla rete di Ethereum abbastanza rapidamente da essere ricevuto ed elaborato da ogni nodo, in sicurezza, entro uno spazio di 12 secondi. Se il testimone è troppo grande, per alcuni nodi potrebbe volerci troppo per scaricarlo e tenere il passo con la catena. Questa è una forza centralizzante, poiché significa che soltanto i nodi con connessioni a Internet veloci, possono partecipare alla convalida dei blocchi. Con gli alberi di Verkle non è necessario memorizzare lo stato sul proprio disco rigido; _tutto_ ciò che serve per verificare un blocco, si trova nel blocco stesso. Purtroppo, i testimoni producibili dagli alberi di Merkle sono troppo grandi per supportare i client privi di stato. +Verificare un blocco significa rieseguire le transazioni contenute nel blocco, applicando le modifiche all'albero di stato di Ethereum e calcolando il nuovo hash della radice. Un blocco verificato è uno il cui hash della radice di stato calcolato equivale a quello fornito con il blocco (poiché ciò preclude che il propositore del blocco abbia realmente effettuato il calcolo che dice di aver effettuato). Nei client odierni di Ethereum, aggiornare lo stato richiede l'accesso all'intero albero di stato, una grande struttura di dati che dev'essere archiviata localmente. Un testimone contiene soltanto i frammenti dei dati di stato necessari per eseguire le transazioni nel blocco. Un validatore può quindi utilizzare soltanto quei frammenti per verificare che il propositore di blocchi abbia eseguito le transazioni del blocco e aggiornato correttamente lo stato. Tuttavia, ciò significa che il testimone dev'essere trasferito tra i pari sulla rete di Ethereum abbastanza rapidamente da essere ricevuto ed elaborato da ogni nodo, in sicurezza, entro uno spazio di 12 secondi. Se il testimone è troppo grande, per alcuni nodi potrebbe volerci troppo per scaricarlo e tenere il passo con la catena. Questa è una forza centralizzante, poiché significa che soltanto i nodi con connessioni a Internet veloci, possono partecipare alla convalida dei blocchi. Con gli alberi di Verkle non c'è bisogno di avere lo stato memorizzato sul tuo disco rigido; _tutto_ ciò di cui hai bisogno per verificare un blocco è contenuto nel blocco stesso. Purtroppo, i testimoni producibili dagli alberi di Merkle sono troppo grandi per supportare i client privi di stato. ## Perché gli alberi di Verkle consentono testimoni più piccoli? {#why-do-verkle-trees-enable-smaller-witnesses} @@ -31,34 +30,34 @@ La struttura di un Albero di Merkle rende le dimensioni dei testimoni molto gran Sotto lo schema di impegno polinomiale, i testimoni hanno dimensioni gestibili, facilmente trasferibili sulla rete tra pari. Questo consente ai client di verificare i cambiamenti di stato in ogni blocco con una quantità minima di dati. - + Le dimensioni dei testimoni variano a seconda del numero di foglie che include. Supponendo che il testimone copra 1000 foglie, un testimone per un albero di Merkle occuperebbe all'incirca 3,5 MB (ipotizzando 7 livelli all'albero). Un testimone per gli stessi dati in un albero di Verkle (ipotizzando 4 livelli all'albero) occuperebbe circa 150 kB; **circa 23 volte più piccolo**. Questa riduzione delle dimensioni del testimone consentirà ai testimoni del client di essere accettabilmente piccoli. I testimoni polinomiali variano da 0,128 a 1 kB a seconda dello specifico impegno polinomiale utilizzato. - ## Qual è la struttura di un albero di Verkle? {#what-is-the-structure-of-a-verkle-tree} - -Gli alberi di Verkle sono coppie `(key,value)` in cui le chiavi sono elementi da 32 byte composte da uno _stelo_ di 31 byte e un _suffisso_ di un singolo byte. Queste chiavi sono organizzate in nodi _estensione_ e nodi _interni_. I nodi d'estensione rappresentano un singolo stelo per 256 figli con suffissi differenti. Anche i nodi interni hanno 256 figli, ma possono essere altri nodi d'estensione. La differenza principale tra la struttura dell'albero di Verkle e dell'albero di Merkle è che il primo è molto più piatto, a significare che ci sono meno nodi intermedi che collegano una foglia alla radice e dunque sono richiesti meno dati per generare una prova. +Gli alberi di Verkle sono coppie `(key,value)` in cui le chiavi sono elementi da 32 byte composti da uno _stelo_ di 31 byte e un _suffisso_ di un singolo byte. Queste chiavi sono organizzate in nodi di _estensione_ e nodi _interni_. I nodi d'estensione rappresentano un singolo stelo per 256 figli con suffissi differenti. Anche i nodi interni hanno 256 figli, ma possono essere altri nodi d'estensione. La differenza principale tra la struttura dell'albero di Verkle e dell'albero di Merkle è che il primo è molto più piatto, a significare che ci sono meno nodi intermedi che collegano una foglia alla radice e dunque sono richiesti meno dati per generare una prova. ![](./verkle.png) [Leggi di più sulla struttura degli alberi di Verkle](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) -## Stato attuale {#current-progress} +## Progressi attuali {#current-progress} Le reti di prova dell'albero di Verkle sono già in esecuzione, ma servono ancora aggiornamenti sostanziali e straordinari, necessari a supportarli. Puoi aiutare ad accelerare il progresso distribuendo contratti alle reti di prova od operando dei client delle reti di prova. -[Guarda Guillaume Ballet spiegare la rete di prova di Verkle Condrieu](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (nota che la rete di prova Condrieu era in proof-of-work e ora è stata sostituita dalla rete di prova di Verkle Gen Devnet 6). +[Guarda Guillaume Ballet spiegare la rete di test di Verkle Condrieu](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (nota che la rete di test Condrieu era proof-of-work e ora è stata sostituita dalla rete di test Verkle Gen Devnet 6). ## Letture consigliate {#further-reading} - [Alberi di Verkle per l'assenza di stato](https://verkle.info/) - [Dankrad Feist spiega gli alberi di Verkle su PEEPanEIP](https://www.youtube.com/watch?v=RGJOQHzg3UQ) -- [Guillaume Ballet spiega gli alberi di Verkle all'ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o) -- ["Come gli alberi di Verkle rendono Ethereum snello e succinto" di Guillaume Ballet al Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs) -- [Piper Merriam sui client privi di stato dall'ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4) -- [Dankrad Fiest spiega gli alberi di Verkle e l'assenza di stato nel podcast "Zero Knowledge"](https://zeroknowledge.fm/podcast/202/) +- [Alberi di Verkle per tutti](https://web.archive.org/web/20250124132255/https://research.2077.xyz/verkle-trees) +- [Anatomia di una prova Verkle](https://ihagopian.com/posts/anatomy-of-a-verkle-proof) +- [Guillaume Ballet spiega gli alberi di Verkle a ETHGlobal](https://www.youtube.com/watch?v=f7bEtX3Z57o) +- ["Come gli alberi di Verkle rendono Ethereum snello e succinto" di Guillaume Ballet a Devcon 6](https://www.youtube.com/watch?v=Q7rStTKwuYs) +- [Piper Merriam sui client senza stato da ETHDenver 2020](https://www.youtube.com/watch?v=0yiZJNciIJ4) +- [Dankrad Feist spiega gli alberi di Verkle e l'assenza di stato sul podcast Zero Knowledge](https://zeroknowledge.fm/podcast/202/) - [Vitalik Buterin sugli alberi di Verkle](https://vitalik.eth.limo/general/2021/06/18/verkle.html) - [Dankrad Feist sugli alberi di Verkle](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) -- [Documentazione sull'EIP degli alberi di Verkle](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration) +- [Documentazione dell'EIP sugli alberi di Verkle](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration) diff --git a/public/content/translations/it/staking/dvt/index.md b/public/content/translations/it/staking/dvt/index.md index d2f9a11efe2..aa2a9d9b2ef 100644 --- a/public/content/translations/it/staking/dvt/index.md +++ b/public/content/translations/it/staking/dvt/index.md @@ -1,6 +1,6 @@ --- title: Tecnologia del validatore distribuito -description: La tecnologia del validatore distribuito consente l'operazione distribuita di un validatore di Ethereum da più parti. +description: "La tecnologia del validatore distribuito consente l'operazione distribuita di un validatore di Ethereum da più parti." lang: it --- @@ -10,7 +10,7 @@ La tecnologia del validatore distribuito (DVT) è un approccio alla sicurezza de Lo fa **dividendo la chiave privata** utilizzata per proteggere un validatore **tra molti computer** organizzati in un "cluster". Il vantaggio è che rende molto difficile, per gli utenti malevoli, l'ottenimento dell'accesso alla chiave, poiché non è memorizzata per intero su una singola macchina. Inoltre, consente a certi nodi di andare offline, poiché la firma necessaria è effettuabile da un sottoinsieme di macchine, in ogni cluster. Ciò riduce i singoli punti di guasto dalla rete, rendendo l'intero validatore più robusto. -![Un diagramma che mostra come una singola chiave del validatore è divisa in parti e distribuita su più nodi, con componenti diversi.](./dvt-cluster.png) +![Un diagramma che mostra come la chiave di un singolo validatore viene suddivisa in parti di chiave e distribuita a più nodi con componenti differenti.](./dvt-cluster.png) ## Perché ci occorre la DVT? {#why-do-we-need-dvt} @@ -20,7 +20,7 @@ I validatori generano due coppie di chiavi pubblica-privata: le chiavi del valid Utilizzando la DVT, gli staker possono partecipare allo staking mantenendo la chiave privata del validatore in archiviazione a freddo. Ciò è possibile crittografando la chiave originale del validatore completo e quindi dividendola in parti. Le parti di chiave risiedono online e sono distribuite a più nodi, che consentono l'operazione distribuita del validatore. Ciò è possibile perché i validatori di Ethereum utilizzano le firme BLS, che sono additive, il che significa che la chiave intera è ricostruibile sommandone le parti componenti. Ciò consente allo staker di mantenere in sicurezza offline la chiave "principale" del validatore intera e originale. -### Nessun punto di guasto singolo {#no-single-point-of-failure} +### Nessun singolo punto di errore {#no-single-point-of-failure} Quando un validatore è diviso tra più operatori e macchine, può resistere a singoli guasti hardware e software, senza andare offline. Il rischio di guasti è inoltre riducibile utilizzando configurazioni hardware e software differenti tra i nodi di un cluster. Questa resilienza non è disponibile per le configurazioni del validatore a nodo singolo; proviene dal livello della DVT. @@ -34,23 +34,23 @@ Senza la DVT, è più facile per i fornitori di staking supportare soltanto una **La DVT offre i seguenti benefici a Ethereum:** -1. **Decentralizzazione** del consenso di proof-of-stake di Ethereum -2. Assicura la **vitalità** della rete +1. **Decentralizzazione** del consenso proof-of-stake di Ethereum +2. Garantisce la **vitalità** della rete 3. Crea la **tolleranza ai guasti** del validatore -4. Operazione del validatore a **fiducia minimizzata** -5. Rischi di inattività e **frammentazione minimizzati** +4. **Operatività a fiducia minimizzata** del validatore +5. **Minimizzazione dei rischi di slashing** e di inattività 6. **Migliora la diversità** (client, data center, posizione, regolamentazione, ecc.) -7. **Sicurezza migliorata** della gestione della chiave del validatore +7. **Maggiore sicurezza** della gestione delle chiavi del validatore ## Come funziona la DVT? {#how-does-dvt-work} Una soluzione DVT contiene i seguenti componenti: -- **[Condivisione segreta di Shamir](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)**: I validatori utilizzano le [chiavi BLS](https://en.wikipedia.org/wiki/BLS_digital_signature). Le singole "azioni chiave" BLS sono combinabili in una singola chiave aggregata (firma). Nella DVT, la chiave privata per un validatore è la firma BLS combinata di ogni operatore nel cluster. -- **[Schema della firma di soglia](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)**: determina il numero di singole parti della chiave necessarie per firmare le azioni obbligatorie, es. 3 di 4. -- **[Generazione della chiave distribuita (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)**: processo crittografico che genera le parti di chiave ed è utilizzato per distribuire le parti di una chiave del validatore esistente o nuova ai nodi di un cluster. -- **[Calcolo multiparte (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)**: la chiave del validatore intera è generata in segreto utilizzando il calcolo multiparte. La chiave intera non è mai nota ad alcun singolo operatore, che ne conosce solo la propria parte (la propria "quota"). -- **Protocollo del consenso**: il protocollo del consenso seleziona un nodo affinché sia il propositore dei blocchi. Condividono il blocco con altri nodi nel cluster che aggiungono le proprie parti di chiave alla firma aggregata. Quando sono state aggregate abbastanza parti di chiave, il blocco viene proposto su Ethereum. +- **[Condivisione del segreto di Shamir](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** - I validatori usano le [chiavi BLS](https://en.wikipedia.org/wiki/BLS_digital_signature). Le singole "azioni chiave" BLS sono combinabili in una singola chiave aggregata (firma). Nella DVT, la chiave privata per un validatore è la firma BLS combinata di ogni operatore nel cluster. +- **[Schema di firma a soglia](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** - Determina il numero di singole parti di chiave necessarie per gli obblighi di firma, ad es., 3 su 4. +- **[Generazione di chiavi distribuita (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** - Processo crittografico che genera le parti di chiave e viene utilizzato per distribuire le parti di una chiave del validatore esistente o nuova ai nodi in un cluster. +- **[Calcolo multipartitico (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** - La chiave completa del validatore viene generata in segreto utilizzando il calcolo multipartitico. La chiave intera non è mai nota ad alcun singolo operatore, che ne conosce solo la propria parte (la propria "quota"). +- **Protocollo di consenso** - Il protocollo di consenso seleziona un nodo che funga da propositore di blocchi. Condividono il blocco con altri nodi nel cluster che aggiungono le proprie parti di chiave alla firma aggregata. Quando sono state aggregate abbastanza parti di chiave, il blocco viene proposto su Ethereum. I validatori distribuiti hanno una tolleranza al guasto integrata e possono continuare a funzionare anche se alcuni nodi singoli sono offline. Ciò significa che il cluster è resiliente anche se alcuni dei nodi al suo interno risultano essere dannosi o "pigri". @@ -58,7 +58,7 @@ I validatori distribuiti hanno una tolleranza al guasto integrata e possono cont La DVT ha implicazioni significative per il più ampio settore dello staking: -### Staker in solo {#solo-stakers} +### Staker individuali {#solo-stakers} Inoltre, la DVT consente lo staking non custodito, permettendoti di distribuire la chiave del tuo validatore tra i nodi remoti pur mantenendo la chiave completa interamente offline. Ciò significa che gli staker domestici non devono per forza sborsare per l'hardware distribuendo le parti di chiave che aiutano a rafforzarli contro potenziali attacchi. @@ -74,18 +74,18 @@ A causa delle configurazioni standard dei validatori, i gruppi di staking e i fo Anche se, tradizionalmente, si compiono sforzi per suddividere il rischio distribuendo gli stake tra più operatori, ogni operatore gestisce ancora indipendentemente uno stake significativo. Affidarsi a un singolo operatore pone rischi immensi se ha performance ridotte, riscontra tempi di inattività, viene compromesso o agisce in modo dannoso. -Facendo leva sulla DVT, la fiducia degli operatori è richiesta molto meno. **I gruppi possono consentire agli operatori di detenere stake senza necessitare della custodia delle chiavi del validatore** (poiché soltanto le parti di chiave sono utilizzate). Inoltre, consente agli stake gestiti di essere distribuiti tra più operatori (es., invece di avere un singolo operatore che gestisce 1000 validatori, la DVT consente a tali validatori di essere eseguiti collettivamente da più operatori). Diverse configurazioni dell'operatore assicureranno che se un operatore dovesse divenire inattivo, gli altri potrebbero comunque attestare. Questo risulta in ridondanza e diversificazione, che comporta prestazioni e resilienza migliori, pur massimizzando le ricompense. +Facendo leva sulla DVT, la fiducia degli operatori è richiesta molto meno. **I pool possono consentire agli operatori di detenere stake senza aver bisogno della custodia delle chiavi del validatore** (poiché vengono utilizzate solo le parti di chiave). Inoltre, consente agli stake gestiti di essere distribuiti tra più operatori (es., invece di avere un singolo operatore che gestisce 1000 validatori, la DVT consente a tali validatori di essere eseguiti collettivamente da più operatori). Diverse configurazioni dell'operatore assicureranno che se un operatore dovesse divenire inattivo, gli altri potrebbero comunque attestare. Questo risulta in ridondanza e diversificazione, che comporta prestazioni e resilienza migliori, pur massimizzando le ricompense. Un altro beneficio per minimizzare la fiducia del singolo operatore è che i gruppi di staking possono consentire una partecipazione dell'operatore più aperta e priva di autorizzazioni. Così, i servizi possono ridurre il rischio e supportare la decentralizzazione di Ethereum, utilizzando serie di operatori curate e prive di autorizzazioni, ad esempio associando gli staker domestici o minori a quelli più grandi. ## Potenziali svantaggi dell'utilizzo della DVT {#potential-drawbacks-of-using-dvt} -- **Componente aggiuntivo**: introdurre un nodo DVT aggiunge un'altra parte che potrebbe essere difettosa o vulnerabile. Un modo per mitigare tale problema è sforzarsi per maggiori implementazioni di un nodo DVT, quindi, di più client DVT (analogamente al fatto che esistono più client per i livelli del consenso e dell'esecuzione). -- **Costi operativi**: poiché la DVT distribuisce il validatore tra più parti, sono necessari più nodi per l'operazione, invece di un singolo nodo, introducendo costi operativi maggiori. -- **Latenza potenzialmente incrementata**: poiché la DVT utilizza un protocollo di consenso per raggiungere il consenso tra più nodi che operano un validatore, potrebbe introdurre una maggiore latenza. +- **Componente aggiuntivo** - l'introduzione di un nodo DVT aggiunge un'altra parte che può essere difettosa o vulnerabile. Un modo per mitigare tale problema è sforzarsi per maggiori implementazioni di un nodo DVT, quindi, di più client DVT (analogamente al fatto che esistono più client per i livelli del consenso e dell'esecuzione). +- **Costi operativi** - poiché la DVT distribuisce il validatore tra più parti, sono necessari più nodi per il funzionamento invece di un singolo nodo, il che introduce un aumento dei costi operativi. +- **Latenza potenzialmente aumentata** - poiché la DVT utilizza un protocollo di consenso per raggiungere il consenso tra i più nodi che gestiscono un validatore, può potenzialmente introdurre una maggiore latenza. -## Letture consigliate {#further-reading} +## Ulteriori letture {#further-reading} -- [Specifiche del validatore distribuito di Ethereum (alto livello)](https://github.com/ethereum/distributed-validator-specs) +- [Specifiche del validatore distribuito di Ethereum (di alto livello)](https://github.com/ethereum/distributed-validator-specs) - [Specifiche tecniche del validatore distribuito di Ethereum](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec) -- [App dimostrativa di condivisione del segreto di Shamir](https://iancoleman.io/shamir/) +- [App demo della condivisione del segreto di Shamir](https://iancoleman.io/shamir/) diff --git a/public/content/translations/it/staking/pools/index.md b/public/content/translations/it/staking/pools/index.md index 6062d36558e..af73bbd8977 100644 --- a/public/content/translations/it/staking/pools/index.md +++ b/public/content/translations/it/staking/pools/index.md @@ -1,6 +1,6 @@ --- -title: Staking in pool -description: Una panoramica di come iniziare con lo staking in pool di ETH +title: Staking condiviso +description: Scopri i pool di staking lang: it template: staking emoji: ":money_with_wings:" @@ -17,16 +17,16 @@ summaryPoints: I pool di staking sono un approccio collaborativo per consentire a molti, con quantità minori di ETH, di ottenere i 32 ETH necessari per attivare un insieme di chiavi di validazione. La funzionalità di pooling non è supportata nativamente all'interno del protocollo, quindi le soluzioni sono state sviluppate separatamente per rispondere a questa esigenza. -Alcuni pool operano utilizzando i contratti intelligenti, dove i fondi possono essere depositati in un contratto, che gestisce e traccia senza fiducia il tuo stake, e ti emette un token che rappresenta questo valore. Altri pool potrebbero non coinvolgere i contratti intelligenti ed essere invece mediati al di fuori dalla catena. +Alcuni pool operano utilizzando i contratti intelligenti, dove i fondi possono essere depositati in un contratto, che gestisce e traccia senza fiducia il tuo stake, e ti emette un token che rappresenta questo valore. Altri pool potrebbero non coinvolgere i contratti intelligenti ed essere invece mediati offchain. ## Perché mettere in stake con un pool? {#why-stake-with-a-pool} -Oltre ai vantaggi che abbiamo delineato nella nostra [introduzione allo staking](/staking/), lo staking mediante un pool viene fornito con una serie di vantaggi distinti. +Oltre ai vantaggi illustrati nella nostra [introduzione allo staking](/staking/), lo staking con un pool comporta una serie di vantaggi distinti. - - - + + + @@ -39,7 +39,7 @@ Ogni pool e gli strumenti o i contratti intelligenti che utilizzano sono stati c Tuttavia, questi token derivanti dagli ETH in staking tendono a creare comportamenti in stile cartello, in cui una grande quantità di ETH in staking finisce sotto il controllo di alcune organizzazioni centralizzate, piuttosto che distribuirsi a molti individui indipendenti. Ciò crea condizioni di censura o di estrazione del valore. Lo standard di riferimento per lo staking dovrebbe sempre prevedere l'esecuzione di validatori da parte di individui, sul proprio hardware, quando possibile. -[Di più sui rischi dello staking di token](https://notes.ethereum.org/@djrtwo/risks-of-lsd). +[Maggiori informazioni sui rischi dello staking di token](https://notes.ethereum.org/@djrtwo/risks-of-lsd). Gli indicatori d'attributo sono usati di seguito per segnalare notevoli punti di forza o debolezze che un pool di staking elencato potrebbe avere. Usa questa sezione come un riferimento per come definire tali attributi mentre stai scegliendo un pool cui unirti. @@ -53,13 +53,13 @@ Esistono una varietà di opzioni disponibili per aiutarti con la tua configurazi -Sei pregato di notare l'importanza di scegliere un servizio che prenda sul serio la [diversità del client](/developers/docs/nodes-and-clients/client-diversity/), poiché essa migliora la sicurezza della rete e limita i tuoi rischi. I servizi per i quali è dimostrato che limitano l'utilizzo dei client di maggioranza sono indicati con "diversità del client di esecuzione" e "diversità del client di consenso." +È importante scegliere un servizio che prenda sul serio la [diversità dei client](/developers/docs/nodes-and-clients/client-diversity/), poiché migliora la sicurezza della rete e limita i rischi. I servizi aventi prova della limitazione dell'utilizzo dei client di maggioranza sono indicati con "diversità del client d'esecuzione" e "diversità del client del consenso." -Hai un suggerimento per uno strumento di staking che abbiamo dimenticato? Dai un'occhiata alla nostra [politica di elenco dei prodotti](/contributing/adding-staking-products/) per verificare l'idoneità e sottoporcelo. +Hai un suggerimento per uno strumento di staking che abbiamo dimenticato? Consulta la nostra [politica di inserimento dei prodotti](/contributing/adding-staking-products/) per verificare se è idoneo e per sottoporlo a revisione. ## Domande frequenti {#faq} - + Tipicamente i token di staking ERC-20 sono emessi agli staker e rappresentano il valore dei loro ETH in staking più le ricompense. Tieni a mente che diversi pool distribuiranno ricompense di staking ai loro utenti tramite metodi lievemente differenti, ma questo è il tema comune. @@ -68,19 +68,19 @@ Subito! L'aggiornamento della rete di Shanghai/Capella è avvenuto ad aprile 202 In alternativa, i pool che utilizzano un token di staking ERC-20 consentono agli utenti di scambiare questo token sul mercato libero, permettendo di vendere la propria posizione di staking, "prelevando" i propri fondi di fatto senza rimuovere effettivamente ETH dal contratto di staking. -Di più sui prelievi di staking +Maggiori informazioni sui prelievi dello staking - -Esistono molte somiglianze tra queste opzioni di staking in pool e le borse centralizzate, come la possibilità di mettere in staking piccole quantità di ETH e farle impacchettare insieme per attivare i validatori. + +Esistono molte somiglianze tra queste opzioni di staking in pool e gli exchange centralizzati, come la possibilità di mettere in staking piccole quantità di ETH e raggrupparle per attivare i validatori. A differenza delle borse centralizzate, molte altre opzioni di staking in pool utilizzano contratti intelligenti e/o token di staking, che di solito sono token ERC-20 che possono essere conservati nel proprio portafoglio e acquistati o venduti come qualsiasi altro token. Questo offre un livello di sovranità e sicurezza, dandoti il controllo dei tuoi token, ma non ti dà ancora il controllo diretto sul client del validatore che attesta per conto tuo in background. Alcune opzioni di pooling sono più decentralizzate di altre quando si tratta di nodi che le sostengono. Per promuovere la salute e la decentralizzazione della rete, gli staker sono sempre incoraggiati a selezionare un servizio di pooling che consenta una serie di operatori del nodo decentralizzati e privi di permessi. -## Approfondimenti {#further-reading} +## Letture consigliate {#further-reading} -- [The Ethereum Staking Directory](https://www.staking.directory/) - _Eridian and Spacesider_ -- [Staking con Rocket Pool - Panoramica sullo Staking](https://docs.rocketpool.net/guides/staking/overview.html) - _RocketPool docs_ +- [La Directory dello Staking di Ethereum](https://www.staking.directory/) - _Eridian e Spacesider_ +- [Staking con Rocket Pool - Panoramica sullo staking](https://docs.rocketpool.net/guides/staking/overview.html) - _Documentazione di RocketPool_ - [Staking di Ethereum con Lido](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) - _Documentazione di supporto di Lido_ diff --git a/public/content/translations/it/staking/saas/index.md b/public/content/translations/it/staking/saas/index.md index 8569e2ca534..a93161af058 100644 --- a/public/content/translations/it/staking/saas/index.md +++ b/public/content/translations/it/staking/saas/index.md @@ -1,6 +1,6 @@ --- title: Staking come servizio -description: Una panoramica di come iniziare con lo staking in pool di ETH +description: "Scopri di più sullo staking come servizio" lang: it template: staking emoji: ":money_with_wings:" @@ -22,9 +22,9 @@ Lo staking come un servizio ("SaaS") rappresenta una categoria di servizi di sta Il protocollo di Ethereum non supporta nativamente la delegazione dello staking, quindi questi servizi sono stati creati per soddisfare questa domanda. Se hai 32 ETH da mettere in staking, ma non hai dimestichezza con l'hardware, i servizi di SaaS ti consentono di delegare la parte hardware e ottenere le ricompense del blocco nativo. - - - + + + @@ -37,7 +37,7 @@ Gli indicatori d'attributo sono usati di seguito per segnalare notevoli punti di -## Esplora i fornitori del servizio di staking {#saas-providers} +## Esplora i fornitori di servizi di staking {#saas-providers} Seguono alcuni dei fornitori di SaaS disponibili. Usa i suddetti indicatori per orientarti tra questi servizi @@ -47,13 +47,13 @@ Seguono alcuni dei fornitori di SaaS disponibili. Usa i suddetti indicatori per -Ricorda l'importanza di supportare la [diversità del client](/developers/docs/nodes-and-clients/client-diversity/) poiché migliora la sicurezza della rete e limita i tuoi rischi. I servizi per i quali è dimostrato che limitano l'utilizzo dei client di maggioranza sono indicati con "diversità del client di esecuzione" e "diversità del client di consenso." +Nota l'importanza di supportare la [diversità dei client](/developers/docs/nodes-and-clients/client-diversity/), poiché migliora la sicurezza della rete e limita i tuoi rischi. I servizi aventi prova della limitazione dell'utilizzo dei client di maggioranza sono indicati con "diversità del client d'esecuzione" e "diversità del client del consenso." ### Generatori di chiavi -Hai un suggerimento per un fornitore di staking come servizio che abbiamo dimenticato? Dai un'occhiata alla nostra [politica di elenco dei prodotti](/contributing/adding-staking-products/) per verificare l'idoneità e sottoporcelo. +Hai un suggerimento per un fornitore di staking come servizio che abbiamo dimenticato? Consulta la nostra [politica di inserimento dei prodotti](/contributing/adding-staking-products/) per verificare se è idoneo e per sottoporlo a revisione. ## Domande frequenti {#faq} @@ -61,24 +61,24 @@ Hai un suggerimento per un fornitore di staking come servizio che abbiamo diment Le disposizioni differiranno da fornitore a fornitore, ma in genere, sarai guidato alla configurazione di qualsiasi chiave di firma necessaria (una per 32 ETH) e al loro caricamento al tuo fornitore per consentirgli di validare per conto tuo. Le sole chiavi di firma non danno alcuna possibilità di prelevare, trasferire o spendere i tuoi fondi. Tuttavia, forniscono la possibilità di trasmettere voti a favore di un consenso, il che, se non fatto propriamente, può risultare in sanzioni offline o tagli. - + Sì. Ogni conto si compone sia di chiavi di firma che di chiavi di prelievo BLS. Affinché un validatore possa attestare allo stato della catena, partecipare ai comitati di sincronizzazione e proporre blocchi, le chiavi di firma devono essere prontamente accessibili dal client di un validatore. Queste devono esser connesse a Internet in qualche modo e sono dunque intrinsecamente considerate chiavi "calde". Questo è un requisito affinché il tuo validatore possa attestare e, dunque, le chiavi usate per trasferire o prelevare i fondi sono separate per motivi di sicurezza. Le chiavi di prelievo BLS sono utilizzate per firmare un messaggio una tantum che dichiara a chi dovrebbero andare le ricompense di staking del conto del livello d'esecuzione e i fondi prelevati. Una volta trasmesso questo messaggio, le chiavi di prelievo BLS non saranno più necessarie. Invece, il controllo dei fondi prelevati è permanentemente delegato all'indirizzo fornito. Ciò consente di impostare un indirizzo di prelievo protetto tramite l'archiviazione a freddo, minimizzando il rischio per i tuoi fondi del validatore, anche se qualcun altro controlla le chiavi di firma del tuo validatore. Aggiornare le credenziali di prelievo è un passaggio necessario per consentire i prelievi\*. Questo processo comporta la generazione delle chiavi di prelievo, utilizzando la tua frase di seed mnemonica. -Accertati di eseguire in sicurezza il backup di questa frase di seed, o non potrai generare le tue chiavi di prelievo quando arriverà il momento. +Assicurati di conservare questa frase seed in un luogo sicuro, o non sarai in grado di generare le tue chiavi di prelievo quando arriverà il momento. -\*Gli staker che hanno fornito un indirizzo di prelievo con il deposito iniziale non hanno necessità di impostarle. Confrontati con il tuo fornitore SaaS per ricevere assistenza con la preparazione del validatore. +\*Gli staker che hanno fornito un indirizzo di prelievo con il deposito iniziale non devono impostarlo. Confrontati con il tuo fornitore SaaS per ricevere assistenza con la preparazione del validatore. -I prelievi di staking sono stati implementati nell'aggiornamento di Shanghai/Capella, ad aprile 2023. Gli staker devono fornire un indirizzo di prelievo (se non è stato fornito al deposito iniziale) e i pagamenti delle ricompense inizieranno a essere distribuiti automaticamente su base periodica, a intervalli di pochi giorni. +Gli staker devono fornire un indirizzo di prelievo (se non è stato fornito al deposito iniziale) e i pagamenti delle ricompense inizieranno a essere distribuiti automaticamente su base periodica, a intervalli di pochi giorni. I validatori, inoltre, possono uscire interamente come tali, il che sbloccherà il loro saldo in ETH rimanente per il prelievo. I conti che hanno fornito un indirizzo di prelievo d'esecuzione e hanno completato il procedimento di uscita riceveranno interamente il proprio saldo all'indirizzo di prelievo fornito durante la successiva pulizia dei validatori. -Di più sulle ricompense di staking +Maggiori informazioni sui prelievi dello staking @@ -89,7 +89,7 @@ Fino al completamento del procedimento di taglio/uscita, questi fondi saranno tr Contatta il singolo fornitore di SaaS per ulteriori dettagli su qualsiasi opzione di garanzia o assicurazione e per le istruzioni su come fornire un indirizzo di prelievo. Se preferisci avere il pieno controllo della configurazione del tuo validatore, [scopri di più su come fare staking in solo dei tuoi ETH](/staking/solo/). -## Approfondimenti {#further-reading} +## Letture consigliate {#further-reading} -- [The Ethereum Staking Directory](https://www.staking.directory/) - _Eridian and Spacesider_ -- [Valutare i servizi di Staking](https://www.attestant.io/posts/evaluating-staking-services/) - _Jim McDonald 2020_ +- [La Directory dello Staking di Ethereum](https://www.staking.directory/) - _Eridian e Spacesider_ +- [Valutazione dei servizi di staking](https://www.attestant.io/posts/evaluating-staking-services/) - _Jim McDonald 2020_ diff --git a/public/content/translations/it/staking/solo/index.md b/public/content/translations/it/staking/solo/index.md index d1460e62efc..1404f528317 100644 --- a/public/content/translations/it/staking/solo/index.md +++ b/public/content/translations/it/staking/solo/index.md @@ -15,13 +15,13 @@ summaryPoints: ## Cos'è lo staking domestico? {#what-is-solo-staking} -Lo staking domestico è l'atto di [eseguire un nodo di Ethereum](/run-a-node/) connesso a Internet e depositare 32 ETH per attivare un [validatore](#faq), dandoti la capacità di partecipare direttamente al consenso della rete. +Lo staking domestico è l'atto di [eseguire un nodo di Ethereum](/run-a-node/) connesso a Internet e depositare 32 ETH per attivare un [validatore](#faq), dandoti la possibilità di partecipare direttamente al consenso della rete. -**Lo staking domestico aumenta la decentralizzazione della rete di Ethereum**, rendendola più resistente alla censura e robusta contro gli attacchi. Altri metodi di staking potrebbero non aiutare la rete nello stesso modo. Lo staking domestico è la migliore opzione di staking per proteggere Ethereum. +**Lo staking domestico aumenta la decentralizzazione della rete di Ethereum**, rendendo Ethereum più resistente alla censura e robusto contro gli attacchi. Altri metodi di staking potrebbero non aiutare la rete nello stesso modo. Lo staking domestico è la migliore opzione di staking per proteggere Ethereum. -Un nodo di Ethereum consiste sia nel client del livello di esecuzione (EL), che di un client del livello di consenso (CL). Questi client sono software che cooperano, insieme a una valida serie di chiavi di firma, per verificare le transazioni e i blocchi, attestare al capo corretto della catena, aggregare le attestazioni e proporre i blocchi. +Un nodo di Ethereum è composto sia da un client del livello di esecuzione (EL) che da un client del livello di consenso (CL). Questi client sono software che funzionano insieme, con un set valido di chiavi di firma, per verificare le transazioni e i blocchi, attestare la testata corretta della catena, aggregare le attestazioni e proporre i blocchi. -Gli staker domestici sono responsabili di utilizzare l'hardware necessario a eseguire questi client. Si consiglia vivamente di usare una macchina dedicata per questo, che operi da casa, il che è estremamente vantaggioso per l'integrità della rete. +Gli staker domestici sono responsabili del funzionamento dell'hardware necessario per eseguire questi client. È vivamente consigliato usare una macchina dedicata a questo scopo, che puoi gestire da casa: ciò è estremamente vantaggioso per la salute della rete. Uno staker domestico riceve ricompense direttamente dal protocollo per mantenere il proprio validatore correttamente in funzione e online. @@ -30,44 +30,44 @@ Uno staker domestico riceve ricompense direttamente dal protocollo per mantenere Lo staking domestico richiede maggiori responsabilità, ma fornisce il massimo controllo sui propri fondi e sulla propria configurazione di staking. - - - + + + ## Considerazioni prima dello staking domestico {#considerations-before-staking-solo} -Per quanto vorremmo che lo staking domestico fosse accessibile e privo di rischi per tutti, questa non è la realtà. Esistono serie considerazioni pratiche da tenere a mente prima di scegliere di mettere i propri ETH in staking domestico. +Per quanto vorremmo che lo staking domestico fosse accessibile e privo di rischi per tutti, questa non è la realtà. Ci sono alcune considerazioni pratiche e serie da tenere a mente prima di scegliere di mettere in staking i propri ETH da casa. - -Quando utilizzi il tuo nodo, dovresti dedicare del tempo a imparare come usare il software che hai scelto. Questo include la lettura della documentazione pertinente e seguire i canali di comunicazione di tali team di sviluppo. + +Quando gestisci il tuo nodo, dovresti dedicare del tempo a imparare come usare il software che hai scelto. Ciò comporta la lettura della documentazione pertinente e la consultazione dei canali di comunicazione di tali team di sviluppo. -Più comprendi il software che stai operando e il funzionamento del proof-of-stake, meno rischioso sarà come staker e più sarà facile risolvere qualsiasi problema che potrebbe sorgere lungo il percorso da operatore del nodo. +Più capisci del software che stai eseguendo e di come funziona la proof-of-stake, meno rischi correrai come staker e più facile sarà risolvere eventuali problemi che potrebbero sorgere lungo il percorso come operatore di un nodo. - -La configurazione del nodo richiede un livello di dimestichezza ragionevole con il computer, sebbene nuovi strumenti stiano semplificando le procedure con il tempo. La comprensione dell'interfaccia della riga di comando è utile, ma non più rigorosamente richiesta. + +La configurazione del nodo richiede una discreta dimestichezza con i computer, sebbene nuovi strumenti stiano rendendo questo processo più facile nel tempo. La comprensione dell'interfaccia a riga di comando è utile, ma non più strettamente necessaria. -Richiede anche una configurazione hardware molto basilare e una minima comprensione delle specifiche consigliate minime. +Richiede anche una configurazione hardware molto basilare e una certa comprensione delle specifiche minime consigliate. -Proprio come le chiavi private proteggono il tuo indirizzo di Ethereum, dovrai generare delle chiavi specificamente per il tuo validatore. Devi comprendere come mantenere al sicuro qualsiasi frase di seed o chiave privata.{' '} +Proprio come le chiavi private proteggono il tuo indirizzo Ethereum, dovrai generare chiavi specifiche per il tuo validatore. Devi capire come mantenere al sicuro qualsiasi frase seed o chiave privata. [Sicurezza di Ethereum e prevenzione delle truffe](/security/) -L'hardware, talvolta, si guasta, le connessioni di rete generano errori e il software del client a volte necessita di aggiornamenti. La manutenzione del nodo è inevitabile e richiederà occasionalmente la tua attenzione. Vorrai assicurarti di esser consapevole di qualsiasi aggiornamento di rete anticipato o di altri aggiornamenti critici del client. +L'hardware occasionalmente si guasta, le connessioni di rete danno errore e il software del client occasionalmente necessita di aggiornamenti. La manutenzione del nodo è inevitabile e occasionalmente richiederà la tua attenzione. Dovrai assicurarti di essere a conoscenza di eventuali aggiornamenti di rete previsti o di altri aggiornamenti critici del client. - -Le tue ricompense sono proporzionali al tempo in cui il tuo validatore è online e sta attestando propriamente. Le interruzioni comportano sanzioni proporzionali a quanti altri validatori sono offline nello stesso momento, ma non risultano in tagli. Anche la larghezza di banda conta, poiché le ricompense sono ridotte per le attestazioni che non sono ricevute in tempo. I requisiti varieranno, ma si consiglia un minimo di 10 Mb/s in upload e download. + +Le tue ricompense sono proporzionali al tempo in cui il tuo validatore è online e attesta correttamente. I tempi di inattività comportano sanzioni proporzionali al numero di altri validatori offline nello stesso momento, ma non si traducono in tagli. Anche la larghezza di banda è importante, poiché le ricompense diminuiscono per le attestazioni che non vengono ricevute in tempo. I requisiti possono variare, ma si consiglia un minimo di 10 Mb/s in upload e download. - -Differente dalle sanzioni di inattività per esser offline, il taglio è una sanzione molto più seria, riservata alle infrazioni malevole. Operando un client di minoranza con le tue chiavi caricate su una sola macchina per volta, il tuo rischio di esser tagliato è minimizzato. Detto ciò, tutti gli staker devono esser consapevoli dei rischi di taglio. + +A differenza delle penalità per inattività dovute all'essere offline, lo slashing è una sanzione molto più grave riservata alle infrazioni malevole. Eseguendo un client di minoranza con le tue chiavi caricate su una sola macchina alla volta, il rischio di subire uno slashing è ridotto al minimo. Detto questo, tutti gli staker devono essere consapevoli dei rischi di slashing. Ulteriori informazioni sullo slashing e sul ciclo di vita dei validatori @@ -81,25 +81,25 @@ Differente dalle sanzioni di inattività per esser offline, il taglio Quando saranno attivi, riceverai le ricompense in ETH, che saranno depositate periodicamente al tuo indirizzo di prelievo. -Se lo desideri, puoi smettere di essere un validatore; in questo modo viene meno il requisito di essere online e si interrompe qualsiasi ulteriore ricompensa. Il saldo rimanente sarà poi prelevato all'indirizzo di prelievo che hai indicato durante la configurazione. +Se lo desideri, puoi uscire dal ruolo di validatore, eliminando il requisito di essere online e interrompendo ogni ulteriore ricompensa. Il tuo saldo rimanente sarà quindi prelevato all'indirizzo di prelievo da te designato durante la configurazione. [Di più sulle ricompense di staking](/staking/withdrawals/) -## Inizia con il Launchpad di Staking {#get-started-on-the-staking-launchpad} +## Inizia a usare il Launchpad di staking {#get-started-on-the-staking-launchpad} -Il Launchpad di Staking è un'applicazione open source che ti aiuterà a diventare uno staker. Ti guiderà per la scelta dei tuoi client, la generazione delle tue chiavi e il deposito dei tuoi ETH al contratto di deposito di staking. Una lista di controllo è fornita per assicurarsi che tu abbia coperto tutto per configurare in sicurezza il tuo validatore. +Il Launchpad di staking è un'applicazione open source che ti aiuterà a diventare uno staker. Ti guiderà nella scelta dei client, nella generazione delle chiavi e nel deposito dei tuoi ETH nel contratto di deposito per lo staking. Viene fornita una checklist per assicurarsi di aver coperto tutto il necessario per configurare il proprio validatore in sicurezza. -## Cosa considerare con il nodo e gli strumenti di configurazione del client {#node-tool-considerations} +## Cosa considerare riguardo agli strumenti di configurazione di nodi e client {#node-tool-considerations} Esistono sempre più strumenti e servizi per aiutarti a mettere i tuoi ETH in staking domestico, ma ognuno presenta rischi e benefici differenti. -Gli indicatori di attributo sono usati di seguito per segnalare punti di forza e debolezze notevoli che uno strumento di staking elencato potrebbe avere. Usa questa sezione come un riferimento per come definire questi attributi mentre stai scegliendo quali strumenti usare per guidarti per il tuo percorso di staking. +Gli indicatori di attributo sono usati di seguito per segnalare punti di forza o di debolezza notevoli che uno strumento di staking elencato potrebbe avere. Usa questa sezione come riferimento per come definiamo questi attributi mentre scegli quali strumenti usare per aiutarti nel tuo percorso di staking. -## Esplora gli strumenti del nodo e di configurazione del client {#node-and-client-tools} +## Esplora gli strumenti di configurazione di nodi e client {#node-and-client-tools} Esistono una varietà di opzioni disponibili per aiutarti con la tua configurazione. Gli indicatori di cui sopra ti guideranno per gli strumenti seguenti. @@ -109,15 +109,15 @@ Esistono una varietà di opzioni disponibili per aiutarti con la tua configurazi -Ricorda l'importanza di scegliere un [client di minoranza](/developers/docs/nodes-and-clients/client-diversity/), poiché migliora la sicurezza della rete e limita i tuoi rischi. Gli strumenti che ti consentono di configurare il client di minoranza sono contrassegnati come "multi-client". +Tieni presente l'importanza di scegliere un [client di minoranza](/developers/docs/nodes-and-clients/client-diversity/) poiché migliora la sicurezza della rete e limita i tuoi rischi. Gli strumenti che ti consentono di configurare un client di minoranza sono indicati come "multi-client". ### Generatori di chiavi -Questi strumenti sono utilizzabili come un'alternativa alla [CLI di deposito di staking](https://github.com/ethereum/staking-deposit-cli/) per contribuire alla generazione di chiavi. +Questi strumenti possono essere utilizzati come alternativa alla [Staking Deposit CLI](https://github.com/ethereum/staking-deposit-cli/) per aiutare con la generazione delle chiavi. -Hai un suggerimento per uno strumento di staking che abbiamo dimenticato? Dai un'occhiata alla nostra [politica di elenco dei prodotti](/contributing/adding-staking-products/) per verificare l'idoneità e sottoporcelo. +Hai un suggerimento per uno strumento di staking che abbiamo dimenticato? Consulta la nostra [politica di inserimento dei prodotti](/contributing/adding-staking-products/) per verificare se è idoneo e per sottoporlo a revisione. ## Esplora le guide allo staking domestico {#staking-guides} @@ -129,32 +129,35 @@ Esistono alcune domande molto comuni sullo staking che meritano di essere affron -Un validatore è un'entità virtuale che risiede su Ethereum e partecipa al consenso del protocollo di Ethereum. I validatori sono rappresentati da un saldo, una chiave pubblica e altre proprietà. Un client del validatore è il software che agisce per conto del validatore detenendone e usandone la chiave privata. Un singolo client del validatore può detenere molte coppie di chiavi, controllando molti validatori. - +Un validatore è un'entità virtuale che vive su Ethereum e partecipa al consenso del protocollo di Ethereum. I validatori sono rappresentati da un saldo, una chiave pubblica e altre proprietà. Un client del validatore è il software che agisce per conto del validatore detenendone e utilizzandone la chiave privata. Un singolo client del validatore può contenere molte coppie di chiavi, controllando molti validatori. -Ogni coppia di chiavi associata ad un validatore richiede esattamente 32 ETH per esser attivata. Maggiori ETH depositati in una singola serie di chiavi non aumentano le potenziali ricompense, poiché ogni validatore è limitato a un saldo effettivo di 32 ETH. Questo significa che lo staking è effettuato in incrementi di 32 ETH, ognuno con la propria serie di chiavi e il proprio saldo. +Sì, i moderni account di validatore sono in grado di contenere fino a 2048 ETH. Gli ETH aggiuntivi oltre i 32 matureranno interessi in modo graduale, aumentando con incrementi di numeri interi man mano che il tuo saldo reale aumenta. Questo è noto come il tuo saldo effettivo. + +Per aumentare il saldo effettivo di un account, e quindi aumentare le ricompense, deve essere superata una soglia di 0,25 ETH al di sopra di qualsiasi soglia di ETH intero. Ad esempio, un account con un saldo reale di 32,9 e un saldo effettivo di 32 dovrebbe guadagnare altri 0,35 ETH per portare il suo saldo reale sopra 33,25 prima di innescare un aumento del saldo effettivo. + +Questo buffer impedisce anche che un saldo effettivo si abbassi prima di arrivare a 0,25 ETH al di sotto del proprio saldo effettivo corrente. -Non depositare più di 32 ETH per un singolo validatore. Non incrementerà le tue ricompense. Se un indirizzo di prelievo è stato impostato per il validatore, i fondi in eccesso oltre i 32 ETH saranno prelevati automaticamente a tale indirizzo durante la successiva [pulizia dei validatori](/staking/withdrawals/#validator-sweeping). +Ogni coppia di chiavi associata a un validatore richiede almeno 32 ETH per essere attivata. Qualsiasi saldo superiore a questo importo può essere prelevato in qualsiasi momento all'indirizzo di prelievo associato tramite una transazione firmata da questo indirizzo. Tutti i fondi al di sopra del saldo effettivo massimo saranno prelevati automaticamente su base periodica. -Se lo staking domestico sembra troppo impegnativo per te, prendi in considerazione di utilizzare un fornitore di [staking come servizio](/staking/saas/) o, se hai meno di 32 ETH, dai un'occhiata ai [pool di staking](/staking/pools/). +Se lo staking domestico ti sembra troppo impegnativo, considera l'utilizzo di un fornitore di [staking-as-a-service](/staking/saas/), o se hai a disposizione meno di 32 ETH, dai un'occhiata agli [staking pool](/staking/pools/). - -Andare offline quando la rete sta finalizzando correttamente NON comporterà alcun taglio. Vengono applicate piccole sanzioni di inattività se il tuo validatore non è disponibile ad attestare per una data epoca (ciascuna lunga 6,4 minuti), ma queste sono molto differenti dal taglio. Queste sanzioni sono lievemente inferiori alla ricompensa che avresti ottenuto se il validatore fosse stato disponibile ad attestare e le perdite possono esser riguadagnate approssimativamente nello stesso periodo di tempo online. + +Andare offline quando la rete sta finalizzando correttamente NON comporterà uno slashing. Piccole penalità per inattività vengono applicate se il tuo validatore non è disponibile ad attestare per una data epoca (ciascuna della durata di 6,4 minuti), ma questo è molto diverso dallo slashing. Queste penalità sono leggermente inferiori alla ricompensa che avresti guadagnato se il validatore fosse stato disponibile ad attestare, e le perdite possono essere recuperate con circa la stessa quantità di tempo trascorso di nuovo online. -Nota che le sanzioni per inattività sono proporzionali a quanti validatori sono offline contemporaneamente. Nei casi in cui una grande porzione della rete è offline in una volta sola, le sanzioni per ciascuno di questi validatori saranno maggiori rispetto a quando non è disponibile un singolo validatore. +Nota che le penalità per inattività sono proporzionali al numero di validatori offline contemporaneamente. Nei casi in cui una grande porzione della rete sia tutta offline contemporaneamente, le penalità per ciascuno di questi validatori saranno maggiori rispetto a quando un singolo validatore non è disponibile. -In casi estremi, se la rete interrompe la finalizzazione poiché più di un terzo dei validatori è offline, questi utenti subiranno quella che è nota come fuga d'inattività quadratica, una riduzione esponenziale di ETH dai conti offline dei validatori. Questo consente alla rete, eventualmente, di auto-curarsi bruciando gli ETH dei validatori inattivi finché il loro saldo non raggiunge i 16 ETH, e a quel punto saranno automaticamente espulsi dal pool del validatore. I validatori online rimanenti alla fine comprenderanno ancora oltre i 2/3 della rete, soddisfacendo la super maggioranza necessaria per finalizzare nuovamente la catena. +In casi estremi, se la rete smette di finalizzare a causa del fatto che più di un terzo dei validatori è offline, questi utenti subiranno quella che è nota come una fuga di inattività quadratica, che è un drenaggio esponenziale di ETH dagli account dei validatori offline. Ciò consente alla rete di auto-ripararsi bruciando gli ETH dei validatori inattivi finché il loro saldo non raggiunge i 16 ETH, a quel punto saranno espulsi automaticamente dal pool di validatori. I restanti validatori online finiranno per costituire di nuovo oltre i 2/3 della rete, soddisfacendo la supermaggioranza necessaria per finalizzare nuovamente la catena. - -In breve, non esiste una garanzia assoluta in questo senso, ma se agisci in buona fede, operi un client di maggioranza e mantieni le tue chiavi di firma solo su una macchina per volta, il rischio di esser tagliato è quasi pari a zero. + +In breve, non può mai essere garantito pienamente, ma se agisci in buona fede, esegui un client di minoranza e mantieni le chiavi di firma su una sola macchina alla volta, il rischio di subire un taglio è quasi nullo. -Esistono solo alcuni modi specifici che possono risultare nel taglio e nell'espulsione di un validatore dalla rete. Al momento della scrittura, i tagli che si sono verificati sono stati esclusivamente un prodotto di configurazioni hardware ridondanti in cui le chiavi di firma erano memorizzate contemporaneamente su due macchine separate. Questo può risultare inavvertitamente in un voto doppio dalle tue chiavi, il che è un'infrazione tagliabile. +Ci sono solo alcuni modi specifici che possono comportare lo slashing di un validatore e la sua espulsione dalla rete. Al momento della stesura di questo articolo, gli slashing che si sono verificati sono stati esclusivamente il prodotto di configurazioni hardware ridondanti in cui le chiavi di firma sono memorizzate su due macchine separate contemporaneamente. Questo può inavvertitamente risultare in un doppio voto da parte delle tue chiavi, che è un'infrazione passibile di slashing. -Operare un client di super maggioranza (ogni client usato da oltre 2/3 della rete), preclude anch'esso un rischio di taglio potenziale nel caso in cui il client presenti un bug che risulti in una biforcazione della catena. Questo può risultare in una biforcazione difettosa che viene finalizzata. Correggere alla catena intesa richiederebbe l'invio di un voto di contorno, provando ad annullare un blocco finalizzato. Anche questa è un'infrazione tagliabile e può esser evitata semplicemente eseguendo invece un client di minoranza. +L'esecuzione di un client di supermaggioranza (qualsiasi client utilizzato da oltre 2/3 della rete) comporta anche il rischio di potenziale slashing nel caso in cui questo client abbia un bug che si traduce in una biforcazione della catena. Questo può risultare in una biforcazione difettosa che viene finalizzata. Per tornare alla catena prevista sarebbe necessario inviare un voto surround, tentando di annullare un blocco finalizzato. Anche questa è un'infrazione passibile di slashing e può essere evitata semplicemente eseguendo un client di minoranza. I bug equivalenti in un client di minoranza non sarebbero mai finalizzati e, ciò risulterebbe in un voto di contorno, con la semplice conseguenza di sanzioni d'inattività, non tagli. @@ -164,42 +167,42 @@ I bug equivalenti in un client di minoranza non sarebbero mai finalizzati - -I client individuali potrebbero variare lievemente in termini di prestazioni e interfaccia utente, poiché ognuno è sviluppato da team differenti che usano diversi linguaggi di programmazione. Detto ciò, nessuno di essi è il "migliore." Tutti i client di produzione sono eccellenti pezzi di software, che eseguono tutti le stesse funzioni fondamentali per sincronizzarsi e interagire con la blockchain. + +I singoli client possono variare leggermente in termini di prestazioni e interfaccia utente, poiché ognuno è sviluppato da team diversi che utilizzano una varietà di linguaggi di programmazione. Detto ciò, nessuno di essi è il "migliore". Tutti i client di produzione sono software eccellenti, che svolgono tutti le stesse funzioni principali per sincronizzarsi e interagire con la blockchain. -Poiché tutti i client di produzione forniscono la stessa funzionalità di base, è davvero molto importante che tu scelga un client di minoranza, vale a dire qualsiasi client che NON sia attualmente in uso da una maggioranza di validatori sulla rete. Questo potrebbe sembrare controintuitivo, ma operare un client di maggioranza o di super maggioranza espone maggiormente al rischio di tagli nel caso di un bug in quel client. Operare un client di minoranza riduce drasticamente tali rischi. +Poiché tutti i client di produzione forniscono la stessa funzionalità di base, è in realtà molto importante che tu scelga un client di minoranza, ovvero qualsiasi client che NON sia attualmente utilizzato dalla maggioranza dei validatori sulla rete. Questo può sembrare controintuitivo, ma l'esecuzione di un client di maggioranza o supermaggioranza ti espone a un rischio maggiore di slashing in caso di bug in quel client. L'esecuzione di un client di minoranza limita drasticamente questi rischi. Scopri di più sul perché la diversità dei client è fondamentale - -Sebbene un server privato virtuale (VPS) possa essere usato come sostitutivo dell'hardware domestico, l'accesso e la posizione fisici del client del validatore sono importanti. Le soluzioni centralizzate su cloud come Amazon Web Services o Digital Ocean offrono la convenienza di non dover ottenere e operare l'hardware, a spese della centralizzazione della rete. + +Sebbene un server privato virtuale (VPS) possa essere utilizzato in sostituzione dell'hardware domestico, l'accesso fisico e la posizione del tuo client validatore sono importanti. Le soluzioni cloud centralizzate come Amazon Web Services o Digital Ocean offrono la comodità di non dover ottenere e gestire l'hardware, a scapito della centralizzazione della rete. -Più client del validatore operano su una soluzione d'archiviazione su cloud centralizzata singola, più diventa pericoloso per questi utenti. Ogni evento che porta questi fornitori offline, che sia un attacco, domande regolatorie o solo guasti energetici o a Internet, manderanno offline al contempo ogni client del validatore che si basi su tale server. +Più client validatore vengono eseguiti su un'unica soluzione di archiviazione cloud centralizzata, più diventa pericoloso per questi utenti. Qualsiasi evento che metta offline questi fornitori, che si tratti di un attacco, di richieste normative o di semplici interruzioni di corrente/internet, farà sì che ogni client validatore che si affida a questo server vada offline contemporaneamente. -Le sanzioni offline sono proporzionali a quanti altri sono offline contemporaneamente. Usare un VPS aumenta notevolmente il rischio che le sanzioni offline saranno più severe e aumenta il rischio di fughe quadratiche o tagli nel caso in cui il guasto sia abbastanza grande. Per minimizzare i tuoi rischi e i rischi alla rete, gli utenti sono vivamente incoraggiati a procurarsi e utilizzare il proprio hardware. +Le sanzioni per l'inattività sono proporzionali al numero di altri validatori offline contemporaneamente. L'utilizzo di un VPS aumenta notevolmente il rischio che le penalità per l'inattività siano più severe e aumenta il rischio di fuga quadratica o slashing nel caso in cui l'interruzione sia sufficientemente grande. Per ridurre al minimo il proprio rischio e quello della rete, gli utenti sono fortemente incoraggiati a procurarsi e a gestire il proprio hardware. - + I prelievi di ogni tipo dalla beacon chain richiedono l'impostazione delle credenziali di prelievo. -I nuovi staker le hanno impostate al momento della generazione della chiave e del deposito. Gli staker esistenti che non lo hanno già impostato, possono aggiornare le proprie chiavi per supportare questa funzionalità. +I nuovi staker impostano questo dato al momento della generazione della chiave e del deposito. Gli staker esistenti che non l'hanno ancora impostato possono aggiornare le loro chiavi per supportare questa funzionalità. Una volta impostate le credenziali di prelievo, i pagamenti delle ricompense (gli ETH accumulati oltre i 32 iniziali) saranno distribuiti periodicamente e automaticamente all'indirizzo di prelievo. Per sbloccare e ricevere il tuo intero saldo, devi inoltre completare il processo di uscita dal tuo validatore. -Di più sulle ricompense di staking +Maggiori informazioni sui prelievi dello staking -## Approfondimenti {#further-reading} +## Letture consigliate {#further-reading} -- [The Ethereum Staking Directory](https://www.staking.directory/) - _Eridian and Spacesider_ -- [Problema di diversità dei client di Ethereum](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_ +- [La Directory dello Staking di Ethereum](https://www.staking.directory/) - _Eridian e Spacesider_ +- [Il problema della diversità dei client di Ethereum](https://hackernoon.com/ethereums-client-diversity-problem) - _@emmanuelawosika 2022_ - [Aiutare la diversità dei client](https://www.attestant.io/posts/helping-client-diversity/) - _Jim McDonald 2022_ -- [La diversità del client sul livello di consenso di Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - _jmcook.eth 2022_ -- [How to: acquistare l'hardware del validatore di Ethereum](https://www.youtube.com/watch?v=C2wwu1IlhDc) - _EthStaker 2022_ -- [Suggerimenti per la prevenzione dei tagli di Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _Raul Jordan 2020_ +- [La diversità dei client sul livello di consenso di Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - _jmcook.eth 2022_ +- [Come scegliere l'hardware per un validatore di Ethereum](https://www.youtube.com/watch?v=C2wwu1IlhDc) - _EthStaker 2022_ +- [Consigli per la prevenzione dei tagli di Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - _Raul Jordan 2020_ diff --git a/public/content/translations/it/staking/withdrawals/index.md b/public/content/translations/it/staking/withdrawals/index.md index da48375cdc0..2bc70f3bb20 100644 --- a/public/content/translations/it/staking/withdrawals/index.md +++ b/public/content/translations/it/staking/withdrawals/index.md @@ -13,15 +13,11 @@ summaryPoints: - I validatori che escono interamente dallo staking riceveranno il saldo rimanente --- - -I prelievi di staking sono stati resi possibili con l'aggiornamento di Shanghai/Capella, verificatosi il 12 aprile 2023. Ulteriori informazioni su Shanghai/Capella - +**I prelievi di staking** si riferiscono a trasferimenti di ETH da un conto di un validatore sul livello di consenso di Ethereum (la Beacon Chain), al livello di esecuzione in cui possono essere effettuate transazioni. -I **prelievi di staking** si riferiscono ai trasferimenti di ETH dal conto di un validatore sul livello di consenso di Ethereum (la Beacon Chain) al livello d'esecuzione in cui possono essere spostati. +\*\*I pagamenti di ricompense dei saldi in eccesso rispetto ai 32 ETH saranno inviati automaticamente e regolarmente a un indirizzo di prelievo collegato a ogni validatore, una volta fornito dall'utente. Gli utenti, inoltre, possono **uscire interamente dallo staking**, sbloccando il proprio intero saldo del validatore. -I **pagamenti di ricompense dei saldi in eccesso** rispetto ai 32 ETH saranno inviati automaticamente e regolarmente a un indirizzo di prelievo collegato a ogni validatore, una volta fornito dall'utente. Gli utenti, inoltre, possono **uscire interamente dallo staking**, sbloccando il proprio intero saldo del validatore. - -## Ricompense di staking {#staking-rewards} +## Ricompense dello staking {#staking-rewards} I pagamenti delle ricompense sono elaborati automaticamente per i conti dei validatori attivi con un saldo effettivo massimizzato di 32 ETH. @@ -47,26 +43,26 @@ Fornire un indirizzo di prelievo è un passaggio necessario per qualsiasi conto - Ogni account validatore è assegnabile esclusivamente a un singolo indirizzo di prelievo, una sola volta. Una volta che un indirizzo è scelto e inviato al livello del consenso, ciò non è annullabile o nuovamente modificabile. Ricontrolla la proprietà e l'accuratezza dell'indirizzo fornito prima di inviarlo. +A ogni conto validatore può essere assegnato un solo indirizzo di prelievo, una sola volta. Una volta scelto e inviato un indirizzo al livello di consenso, questo non può essere annullato o modificato di nuovo. Ricontrolla la proprietà e l'accuratezza dell'indirizzo fornito prima di inviarlo.     Nel mentre, non esiste alcuna minaccia ai tuoi fondi per non averlo fornito, supponendo che la tua frase mnemonica/di seed sia rimasta al sicuro offline e non sia stata compromessa in alcun modo. La mancata aggiunta delle credenziali di prelievo lascerà semplicemente gli ETH bloccati nel conto del validatore finché non sarà fornito un indirizzo di prelievo. -## Uscire interamente dallo staking {#exiting-staking-entirely} +## Uscire completamente dallo staking {#exiting-staking-entirely} -Fornire un indirizzo di prelievo è necessario prima che _qualsiasi_ fondo possa esser trasferito all'esterno del saldo di un conto del validatore. +È necessario fornire un indirizzo di prelievo prima che _qualsiasi_ fondo possa essere trasferito dal saldo di un conto del validatore. Gli utenti che desiderano uscire interamente dallo staking, prelevando il proprio intero saldo, devono inoltre firmare e trasmettere un messaggio di "uscita volontaria" con le chiavi del validatore, avviando così il procedimento di uscita dallo staking. Ciò avviene con il tuo client validatore inviato al tuo nodo del consenso e non richiede gas. Il processo di uscita di un validatore dallo staking richiede periodi di tempo variabili, a seconda di quanti altri stanno uscendo contemporaneamente. Una volta completato, questo conto non sarà più responsabile dell'esecuzione dei doveri della rete dei validatori e non sarà più idoneo per ricevere ricompense, né avrà i propri ETH "in staking". A questo punto, il conto sarà contrassegnato come interamente "prelevabile". -Una volta che un conto è contrassegnato come "prelevabile", e le credenziali sono state fornite, un utente non deve fare altro che aspettare. I conti sono ripuliti automaticamente e continuamente dai propositori di blocchi per verificare la presenza di fondi in uscita idonei e il saldo del tuo conto sarà trasferito interamente (anche noto come "prelievo completo") durante la successiva pulizia. +Una volta che un conto è contrassegnato come "prelevabile", e le credenziali sono state fornite, un utente non deve fare altro che aspettare. I conti sono scansionati automaticamente e continuamente dai proponenti di blocco alla ricerca di fondi idonei all'uscita, e il saldo del tuo conto sarà trasferito per intero (noto anche come "prelievo completo") durante la successiva scansione. -## Quando saranno abilitati i prelievi di staking? {#when} +## Quando sono stati abilitati i prelievi di staking? {#when} -I prelievi di staking sono già operativi! La funzionalità di prelievo è stata abilitata come parte dell'aggiornamento di Shanghai/Capella, verificatosi il 12 aprile 2023. +La funzionalità di prelievo è stata abilitata come parte dell'aggiornamento Shanghai/Capella, avvenuto il **12 aprile 2023**. L'aggiornamento di Shanghai/Capella ha consentito di rivendicare gli ETH precedentemente messi in staking, in conti regolari di Ethereum. Ciò ha chiuso il ciclo della liquidità di staking e ha portato Ethereum un passo più avanti nel suo percorso per la costruzione di un ecosistema decentralizzato sostenibile, scalabile e sicuro. @@ -83,7 +79,7 @@ Dai un'occhiata a questa spiegazione dei prelievi di staking di Ethereum, di Fin -### "Pulizia" dei validatori {#validator-sweeping} +### "Scansione" del validatore {#validator-sweeping} Quando è pianificato che un validatore proponga il prossimo blocco, è necessario costruire una coda di prelievo, composta da un massimo di 16 prelievi idonei. Ciò avviene iniziando originariamente dall'indice 0 del validatore, determinando se esista un prelievo idoneo per questo conto secondo le regole del protocollo e, in tal caso, aggiungendolo alla coda. Il validatore impostato per proporre il blocco successivo riprenderà da dove si è fermato il precedente, procedendo indefinitamente in ordine. @@ -91,29 +87,29 @@ Quando è pianificato che un validatore proponga il prossimo blocco, è necessar -Pensa a un orologio analogico. La lancetta dell'orologio indica l'ora, si muove in una direzione, non salta alcuna ora e, infine, torna nuovamente all'inizio, dopo aver raggiunto l'ultimo numero.

    -Ora, invece che da 1 a 12, immagina che l'orologio vada da 0 a N (il numero totale di account validatore registrati sul livello del consenso, oltre 500.000 a gennaio 2023).

    -La lancetta dell'orologio punta al validatore successivo, che dev'essere controllato per verificare la presenza di prelievi idonei. Inizia a 0 e procede controllando tutti i conti, senza saltarne nessuno. Quando viene raggiunto l'ultimo validatore, il ciclo continua ricominciando dall'inizio. +Pensa a un orologio analogico. La lancetta dell'orologio indica l'ora, avanza in una direzione, non salta nessuna ora e alla fine torna all'inizio dopo aver raggiunto l'ultimo numero.

    +Ora, invece che da 1 a 12, immagina che l'orologio vada da 0 a N (il numero totale di conti validatore che siano mai stati registrati sul livello di consenso, oltre 500.000 a gennaio 2023).

    +La lancetta dell'orologio indica il prossimo validatore che deve essere controllato per i prelievi idonei. Inizia da 0 e procede per tutto il giro senza saltare alcun conto. Quando viene raggiunto l'ultimo validatore, il ciclo ricomincia dall'inizio.     -#### Verificare un conto per i prelievi {#checking-an-account-for-withdrawals} +#### Verifica di un conto per i prelievi {#checking-an-account-for-withdrawals} Mentre un propositore controlla i validatori per i possibili prelievi, ogni validatore verificato è valutato rispetto a una breve serie di domande per determinare se dovrebbe essere innescato un prelievo e, in tal caso, quanti ETH dovrebbero essere prelevati. 1. **È stato fornito un indirizzo di prelievo?** Se non è stato fornito alcun indirizzo di prelievo, il conto viene saltato e non viene avviato alcun prelievo. -2. **Il validatore è uscito ed è idoneo al prelievo?** Se il validatore è uscito interamente e abbiamo ricevuto l'epoca in cui tale conto è considerato come "prelevabile", sarà elaborato un prelievo completo. Questo, trasferirà l'intero saldo rimanente all'indirizzo di prelievo. -3. **Il saldo effettivo è massimizzato a 32?** Se il conto ha le credenziali di prelievo, non è interamente uscito e ha ricompense superiori a 32 in attesa, sarà elaborato un prelievo parziale, che trasferirà esclusivamente le ricompense superiori a 32 all'indirizzo di prelievo dell'utente. +2. **Il validatore è uscito ed è idoneo al prelievo?** Se il validatore è uscito completamente, e abbiamo raggiunto l'epoca in cui il suo conto è considerato "prelevabile", verrà elaborato un prelievo completo. Questo, trasferirà l'intero saldo rimanente all'indirizzo di prelievo. +3. **Il saldo effettivo ha raggiunto il massimo di 32?** Se il conto ha le credenziali di prelievo, non è uscito completamente e ha ricompense in attesa superiori a 32, verrà elaborato un prelievo parziale che trasferirà solo le ricompense superiori a 32 all'indirizzo di prelievo dell'utente. Esistono solo due azioni intraprese dagli operatori del validatore durante il ciclo di vita di un validatore che influenzano direttamente tale flusso: - Fornire le credenziali di prelievo per consentire qualsiasi forma di prelievo - Uscire dalla rete, innescando un prelievo completo -### Zero carburante {#gas-free} +### Senza gas {#gas-free} -Questo approccio ai prelievi di staking evita di richiedere agli staker di inviare manualmente una transazione richiedendo un importo particolare di ETH da prelevare. Ciò significa che **non è necessario alcun carburante (commissione di transazione)** e che il prelievo non compete per lo spazio del blocco del livello d'esecuzione esistente. +Questo approccio ai prelievi di staking evita di richiedere agli staker di inviare manualmente una transazione richiedendo un importo particolare di ETH da prelevare. Ciò significa che **non è richiesto alcun gas (commissione di transazione)** e i prelievi non competono neanche per lo spazio su blocco esistente del livello di esecuzione. ### Con quale frequenza riceverò le mie ricompense di staking? {#how-soon} @@ -123,13 +119,13 @@ Espandendo tale calcolo, possiamo stimare il tempo necessario a elaborare un dat -| Numero di prelievi | Tempo di completamento | -| :-------------------: | :--------------: | -| 400.000 | 3,5 giorni | -| 500.000 | 4,3 giorni | -| 600.000 | 5,2 giorni | -| 700.000 | 6,1 giorni | -| 800.000 | 7,0 giorni | +| Numero di prelievi | Tempo per il completamento | +| :---------------------: | :------------------------: | +| 400.000 | 3,5 giorni | +| 500.000 | 4,3 giorni | +| 600.000 | 5,2 giorni | +| 700.000 | 6,1 giorni | +| 800.000 | 7,0 giorni | @@ -138,7 +134,7 @@ Come vedi, la frequenza rallenta con l'aumento dei validatori sulla rete. Un aum ## Domande frequenti {#faq} @@ -146,11 +142,11 @@ No, il processo per fornire le credenziali di prelievo è una tantum e queste no -Impostando un indirizzo di prelievo del livello d'esecuzione, le credenziali di prelievo per quel validatore sono state cambiate permanentemente. Ciò significa che le vecchie credenziali non funzioneranno più e che le nuove credenziali dirigono a un conto del livello d'esecuzione. +Impostando un indirizzo di prelievo del livello di esecuzione, le credenziali di prelievo per quel validatore sono state modificate in modo permanente. Ciò significa che le vecchie credenziali non funzioneranno più e che le nuove credenziali dirigono a un conto del livello d'esecuzione. Gli indirizzi di prelievo possono essere un contratto intelligente (controllato dal suo codice) o un conto posseduto esternamente (EOA, controllato dalla sua chiave privata). Attualmente questi conti non hanno alcun modo di comunicare un messaggio al livello di consenso che segnali una modifica delle credenziali del validatore, e aggiungere questa funzionalità aggiungerebbe una complessità non necessaria al protocollo. @@ -158,19 +154,18 @@ Come alternativa alla modifica dell'indirizzo di prelievo per un dato validatore Se fai parte di un [pool di staking](/staking/pools/) o detieni token di staking, dovresti chiedere al tuo fornitore ulteriori dettagli su come vengono gestiti i prelievi dallo staking, poiché ogni servizio opera in modo diverso. -In generale, gli utenti dovrebbero essere liberi di rivendicare i propri ETH in staking sottostanti, o di modificare il fornitore di staking che utilizzano. Se un pool in particolare sta diventando troppo grande, è possibile uscire, riscattare i fondi e rimetterli in staking con un fornitore di dimensioni minori. O, se hai accumulato abbastanza ETH, potresti [fare staking da casa](/staking/solo/). - +In generale, gli utenti dovrebbero essere liberi di rivendicare i propri ETH in staking sottostanti, o di modificare il fornitore di staking che utilizzano. Se un pool in particolare sta diventando troppo grande, è possibile uscire, riscattare i fondi e rimetterli in staking con un fornitore di dimensioni minori. Oppure, se hai accumulato abbastanza ETH, potresti fare [staking da casa](/staking/solo/). @@ -178,7 +173,7 @@ Sì, a condizione che il tuo validatore abbia fornito un indirizzo di prelievo. @@ -186,32 +181,30 @@ eventName="read more"> No, se il tuo validatore è ancora attivo sulla rete, un prelievo completo non si verificherà automaticamente. Questo richiede l'avvio manuale di un'uscita volontaria. Una volta che un validatore ha completato il procedimento di uscita e supponendo che il conto abbia le credenziali di prelievo, il saldo rimanente sarà then prelevato durante la successivapulizia del validatore. - -I prelievi sono progettati per avvenire automaticamente, trasferendo qualsiasi ETH che non sta contribuendo attivamente allo staking. Ciò include i saldi completi dei conti che hanno completato il procedimento di uscita. +I prelievi sono progettati per avvenire automaticamente, trasferendo qualsiasi ETH che non sta contribuendo attivamente allo stake. Ciò include i saldi completi dei conti che hanno completato il procedimento di uscita. Non è possibile richiedere manualmente importi specifici di ETH da prelevare. Gli operatori del validatore dovrebbero visitare la pagina dei Prelievi del Launchpad di Staking, dove troveranno ulteriori dettagli su come preparare il proprio validatore ai prelievi, le tempistiche degli eventi e ulteriori dettagli sul funzionamento dei prelievi. -Per testare la tua configurazione su una rete di prova, visita il Launchpad di Staking della rete di prova di Holesky per iniziare. - +Per provare prima la tua configurazione su una rete di test, visita lo Staking Launchpad della rete di test Hoodi per iniziare. @@ -220,8 +213,8 @@ No. Una volta che un validatore è uscito e che il suo intero saldo è stato pre ## Letture consigliate {#further-reading} -- [Prelievi del Launchpad di Staking](https://launchpad.ethereum.org/withdrawals) -- [EIP-4895: La Beacon Chain spinge i prelievi come operazioni](https://eips.ethereum.org/EIPS/eip-4895) -- [PEEPanEIP #94: Prelievo di ETH in staking (testing) con Potuz e Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE) -- [PEEPanEIP#68: EIP-4895: Prelievi push della Beacon Chain come operazioni, con Alex Stokes](https://www.youtube.com/watch?v=CcL9RJBljUs) -- [Informazioni sul saldo effettivo del validatore](https://www.attestant.io/posts/understanding-validator-effective-balance/) +- [Prelievi di Staking Launchpad](https://launchpad.ethereum.org/withdrawals) +- [EIP-4895: prelievi push della Beacon Chain come operazioni](https://eips.ethereum.org/EIPS/eip-4895) +- [PEEPanEIP #94: Prelievo di ETH messi in stake (test) con Potuz e Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE) +- [PEEPanEIP#68: EIP-4895: prelievi push della Beacon Chain come operazioni con Alex Stokes](https://www.youtube.com/watch?v=CcL9RJBljUs) +- [Comprendere il saldo effettivo del validatore](https://www.attestant.io/posts/understanding-validator-effective-balance/) From 6c899f0aa6595ce2b1271579e2f08f1d95d81988 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Fri, 13 Feb 2026 10:36:14 +0000 Subject: [PATCH 2/3] fix(i18n): run sanitizer on Italian translations --- .../content/translations/it/bridges/index.md | 2 +- .../translations/it/community/grants/index.md | 6 +- .../translations/it/community/online/index.md | 2 +- .../it/community/research/index.md | 2 +- .../design/adding-design-resources/index.md | 2 +- .../translations/it/contributing/index.md | 3 +- public/content/translations/it/dao/index.md | 12 +- .../it/decentralized-identity/index.md | 40 ++--- public/content/translations/it/defi/index.md | 6 +- .../it/developers/docs/apis/json-rpc/index.md | 22 +-- .../it/developers/docs/blocks/index.md | 2 +- .../docs/consensus-mechanisms/poa/index.md | 4 +- .../pos/attack-and-defense/index.md | 2 +- .../pos/rewards-and-penalties/index.md | 2 +- .../pos/weak-subjectivity/index.md | 4 +- .../mining/mining-algorithms/ethash/index.md | 2 +- .../docs/data-and-analytics/index.md | 9 +- .../docs/data-availability/index.md | 4 +- .../heuristics-for-web3/index.md | 2 +- .../it/developers/docs/design-and-ux/index.md | 2 +- .../it/developers/docs/evm/index.md | 2 +- .../docs/intro-to-ethereum/index.md | 2 +- .../networking-layer/portal-network/index.md | 2 +- .../it/developers/docs/networks/index.md | 18 +-- .../client-diversity/index.md | 18 +-- .../docs/nodes-and-clients/index.md | 2 +- .../nodes-as-a-service/index.md | 2 +- .../nodes-and-clients/run-a-node/index.md | 2 +- .../it/developers/docs/oracles/index.md | 2 +- .../programming-languages/javascript/index.md | 2 +- .../it/developers/docs/scaling/index.md | 8 +- .../docs/scaling/optimistic-rollups/index.md | 2 +- .../developers/docs/scaling/plasma/index.md | 4 +- .../developers/docs/scaling/validium/index.md | 4 +- .../docs/scaling/zk-rollups/index.md | 2 +- .../docs/smart-contracts/compiling/index.md | 2 +- .../smart-contracts/composability/index.md | 2 +- .../docs/smart-contracts/languages/index.md | 18 +++ .../docs/smart-contracts/verifying/index.md | 6 +- .../it/developers/docs/storage/index.md | 2 +- .../it/developers/docs/transactions/index.md | 2 +- .../it/developers/docs/wrapped-eth/index.md | 8 +- .../tutorials/all-you-can-cache/index.md | 2 +- .../erc-721-vyper-annotated-code/index.md | 1 + .../tutorials/erc20-annotated-code/index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- .../index.md | 7 +- .../index.md | 2 +- .../index.md | 2 +- .../index.md | 4 +- .../index.md | 2 +- .../how-to-use-tellor-as-your-oracle/index.md | 2 +- .../how-to-write-and-deploy-an-nft/index.md | 2 +- .../index.md | 2 +- .../index.md | 2 +- .../index.md | 8 +- .../developers/tutorials/nft-minter/index.md | 2 +- .../index.md | 2 +- .../tutorials/run-node-raspberry-pi/index.md | 2 +- .../secure-development-workflow/index.md | 2 +- .../index.md | 2 +- .../developers/tutorials/short-abi/index.md | 10 +- .../index.md | 4 +- .../index.md | 2 +- .../token-integration-checklist/index.md | 2 +- .../uniswap-v2-annotated-code/index.md | 7 +- .../tutorials/using-websockets/index.md | 4 +- .../index.md | 2 +- .../index.md | 7 - .../translations/it/ethereum-forks/index.md | 137 ++++++++---------- .../translations/it/foundation/index.md | 12 +- .../translations/it/governance/index.md | 2 +- .../index.md | 2 +- .../it/guides/how-to-id-scam-tokens/index.md | 3 - public/content/translations/it/nft/index.md | 4 +- .../translations/it/roadmap/fusaka/index.md | 1 + .../it/roadmap/future-proofing/index.md | 2 +- .../it/roadmap/merge/issuance/index.md | 6 + .../it/roadmap/verkle-trees/index.md | 1 + .../translations/it/social-networks/index.md | 14 +- .../translations/it/staking/solo/index.md | 1 + public/content/translations/it/web3/index.md | 2 +- .../it/zero-knowledge-proofs/index.md | 30 ++-- 84 files changed, 272 insertions(+), 277 deletions(-) diff --git a/public/content/translations/it/bridges/index.md b/public/content/translations/it/bridges/index.md index 2bfc863783d..4a25cd173a7 100644 --- a/public/content/translations/it/bridges/index.md +++ b/public/content/translations/it/bridges/index.md @@ -63,7 +63,7 @@ Diciamo che vuoi possedere Bitcoin (BTC) nativi, ma hai fondi soltanto sulla Ret - Inoltre, puoi fare tutto quanto descritto sopra, usando una [borsa centralizzata](/get-eth/). Tuttavia, a meno che i tuoi fondi non siano già su una borsa, comporterebbe diversi passaggi, e sarebbe più conveniente usare un ponte. + Inoltre, puoi fare tutto quanto descritto sopra, usando una [borsa centralizzata](/get-eth). Tuttavia, a meno che i tuoi fondi non siano già su una borsa, comporterebbe diversi passaggi, e sarebbe più conveniente usare un ponte. diff --git a/public/content/translations/it/community/grants/index.md b/public/content/translations/it/community/grants/index.md index 1312d04005a..2d6d26e7ac0 100644 --- a/public/content/translations/it/community/grants/index.md +++ b/public/content/translations/it/community/grants/index.md @@ -20,7 +20,7 @@ Questi programmi supportano il grande ecosistema di Ethereum offrendo sovvenzion - [Sovvenzioni accademiche](https://esp.ethereum.foundation/academic-grants) - _Sovvenzioni per sostenere il lavoro accademico correlato a Ethereum_ - [Grantfarm di Blockworks](https://blockworks.co/grants/programs) - _Blockworks ha compilato una directory esaustiva di tutte le sovvenzioni, RDP e bug bounty._ -## Programmi per progetti specifici {#project-specific} +## Programmi per progetti specifici {#grant-list-aggregators} Questi progetti hanno creato le proprie sovvenzioni per progetti volti a sviluppare e sperimentare la propria tecnologia. @@ -35,13 +35,13 @@ Questi progetti hanno creato le proprie sovvenzioni per progetti volti a svilupp - [The Graph](https://thegraph.com/ecosystem/grants/): _Ecosistema di [The Graph](https://thegraph.com/)_ - [Programma di sovvenzioni di Uniswap](https://www.uniswapfoundation.org/approach): _community di [Uniswap](https://uniswap.org/)_ -## Finanziamento quadratico {#quadratic-funding} +## Finanziamento quadratico {#comprehensive-directories} Le radici dell'open source di Ethereum hanno portato alla crescita di un nuovo modello interessante di raccolta fondi: il finanziamento quadratico. Questo finanziamento ha il potenziale di migliorare il modo in cui finanzieremo tutti i tipi di beni pubblici in futuro. Il finanziamento quadratico assicura che i progetti che riceveranno più finanziamenti siano quelli con la domanda più esclusiva. In sintesi, i progetti che cercano di migliorare la vita del maggior numero di persone. [Maggiori informazioni sul finanziamento quadratico.](/defi/#quadratic-funding) - [Gitcoin](https://gitcoin.co/grants) - [clr.fund](https://clr.fund/) -## Lavora su Ethereum {#work-in-ethereum} +## Lavora su Ethereum {#for-developers-and-builders} Non sei pronto per iniziare il tuo progetto? Ci sono centinaia di aziende che cercano attivamente persone appassionate con cui lavorare e contribuire all'ecosistema Ethereum. Cerchi maggiori informazioni? [Dai un'occhiata ai lavori relativi a Ethereum](/community/get-involved/#ethereum-jobs) diff --git a/public/content/translations/it/community/online/index.md b/public/content/translations/it/community/online/index.md index 6f38b657f11..8a75d8f69e7 100644 --- a/public/content/translations/it/community/online/index.md +++ b/public/content/translations/it/community/online/index.md @@ -71,5 +71,5 @@ Se credi che una community dovrebbe essere aggiunta o rimossa secondo queste lin Maggiori informazioni sulle DAO - + diff --git a/public/content/translations/it/community/research/index.md b/public/content/translations/it/community/research/index.md index 61e2c88901e..ce50934e2d4 100644 --- a/public/content/translations/it/community/research/index.md +++ b/public/content/translations/it/community/research/index.md @@ -242,7 +242,7 @@ I mercati degli spazi di blocco governano l'inclusione delle transazioni dell'ut - [Progettazione del meccanismo delle commissioni sulle transazioni per la blockchain di Ethereum: un'analisi economica di EIP-1559 (Tim Roughgarden, 2020)](https://timroughgarden.org/papers/eip1559.pdf) - [Simulazioni di EIP-1559 (Gruppo di incentivi robusti)](https://ethereum.github.io/abm1559) - [Economia dei rollup dai primi principi](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url) -- [Flash Boys 2.0: frontrunning, riordinamento delle transazioni e instabilità del consenso nelle borse decentralizzate] (https://arxiv.org/abs/1904.05234) +- [Flash Boys 2.0: frontrunning, riordinamento delle transazioni e instabilità del consenso nelle borse decentralizzate](https://arxiv.org/abs/1904.05234) #### Ricerca recente {#recent-research-10} diff --git a/public/content/translations/it/contributing/design/adding-design-resources/index.md b/public/content/translations/it/contributing/design/adding-design-resources/index.md index f696b61a581..e5cf27c42f7 100644 --- a/public/content/translations/it/contributing/design/adding-design-resources/index.md +++ b/public/content/translations/it/contributing/design/adding-design-resources/index.md @@ -1,6 +1,6 @@ --- title: Aggiungere risorse di progettazione -description: Linee guida e requisiti per assicurare la qualità dei materiali di progettazione su ethereum.org +description: "Linee guida e requisiti per assicurare la qualità dei materiali di progettazione su ethereum.org" lang: it --- diff --git a/public/content/translations/it/contributing/index.md b/public/content/translations/it/contributing/index.md index bc5f4e1f2b4..e38f0602fb1 100644 --- a/public/content/translations/it/contributing/index.md +++ b/public/content/translations/it/contributing/index.md @@ -4,7 +4,7 @@ description: Scopri i vari modi in cui puoi contribuire a ethereum.org lang: it --- -# Contribuire a ethereum.org {#contributing-to-ethereumorg} +# Contribuire a ethereum.org {#contributing-to-ethereumorg} Ethereum.org è un progetto open source con oltre **12000** collaboratori che aiutano a tradurre, scrivere, progettare e mantenere il sito web. @@ -90,6 +90,7 @@ Se il tuo contributo viene aggiunto a ethereum.org, avrai una possibilità di ri [Maggiori informazioni sui OAT](https://help.galxe.com/en/articles/9645630-create-quest-rewards#h_1c5d63ba03) ### Come reclamare + 1. Unisciti al nostro [server Discord](https://discord.gg/ethereum-org). 2. Incolla un link ai tuoi contributi nel canale `#🥇 | proof-of-contribution`. 3. Attendi che un membro del nostro team ti invii un collegamento al tuo OAT. diff --git a/public/content/translations/it/dao/index.md b/public/content/translations/it/dao/index.md index 4c3071f0bf0..77019dfb643 100644 --- a/public/content/translations/it/dao/index.md +++ b/public/content/translations/it/dao/index.md @@ -1,11 +1,11 @@ --- -title: Cos'è una DAO? -metaTitle: Cos'è una DAO? | Organizzazione autonoma decentralizzata +title: "Cos'è una DAO?" +metaTitle: "Cos'è una DAO? | Organizzazione autonoma decentralizzata" description: Una panoramica delle DAO su Ethereum lang: it template: use-cases emoji: ":handshake:" -sidebarDepth: 3 +sidebarDepth: 2 image: /images/use-cases/dao-2.png alt: Rappresentazione di una votazione DAO su una proposta. summaryPoint1: Community posseduta dai membri, prive di leadership centralizzata. @@ -19,7 +19,7 @@ Una DAO è un'organizzazione posseduta collettivamente che opera per realizzare Le DAO ci consentono di lavorare con persone con la stessa mentalità provenienti da tutto il mondo, senza doversi fidare di un capo benevolo, per la gestione di fondi od operazioni. Non esiste alcun CEO che possa spendere i fondi secondo i propri capricci, o CFO che possa manipolare i libri contabili. Invece, le regole basate sulla blockchain, integrate nel codice, definiscono il funzionamento dell'organizzazione e come vengono spesi i fondi. -Contengono delle tesoriere integrate, a cui nessuno ha l'autorità di accedere senza l'approvazione del gruppo. Le decisioni sono governate da proposte e votazioni, per assicurarsi che tutti nell'organizzazione abbiano voce in capitolo, e che tutto si verifichi in modo trasparente [sulla catena](/glossary/#on-chain). +Contengono delle tesoriere integrate, a cui nessuno ha l'autorità di accedere senza l'approvazione del gruppo. Le decisioni sono governate da proposte e votazioni, per assicurarsi che tutti nell'organizzazione abbiano voce in capitolo, e che tutto si verifichi in modo trasparente [sulla catena](/glossary/#onchain). ## Perché abbiamo bisogno delle DAO? {#why-dao} @@ -70,9 +70,7 @@ Ci sono molte considerazioni da fare governando una DAO, ad esempio, come funzio Una delegazione è la versione della democrazia rappresentativa della DAO. I titolari di token delegano i voti agli utenti da loro stessi nominati e si impegnano a gestire il protocollo e a rimanere informati. -#### Un celebre esempio {#governance-example} - -[ENS](https://claim.ens.domains/delegate-ranking) – I titolari di ENS possono delegare i propri voti a membri impegnati della community perché li rappresentino. +#### Un celebre esempio {#governance-example}[ENS](https://claim.ens.domains/delegate-ranking) – I titolari di ENS possono delegare i propri voti a membri impegnati della community perché li rappresentino. ### Governance automatica delle transazioni {#governance-example} diff --git a/public/content/translations/it/decentralized-identity/index.md b/public/content/translations/it/decentralized-identity/index.md index 75457fe89fd..e57da4d582a 100644 --- a/public/content/translations/it/decentralized-identity/index.md +++ b/public/content/translations/it/decentralized-identity/index.md @@ -1,13 +1,13 @@ --- -title: Identità decentralizzata -description: Cos'è l'identità decentralizzata e perché è importante? +title: "Identità decentralizzata" +description: "Cos'è l'identità decentralizzata e perché è importante?" lang: it template: use-cases emoji: ":id:" sidebarDepth: 2 image: /images/eth-gif-cat.png -summaryPoint1: I sistemi di identità tradizionali hanno centralizzato l'emissione, manutenzione e controllo dei tuoi identificativi. -summaryPoint2: L'identità decentralizzata rimuove la dipendenza da terze parti centralizzate. +summaryPoint1: "I sistemi di identità tradizionali hanno centralizzato l'emissione, manutenzione e controllo dei tuoi identificativi." +summaryPoint2: "L'identità decentralizzata rimuove la dipendenza da terze parti centralizzate." summaryPoint3: Grazie alle cripto, gli utenti, ora, hanno nuovamente gli strumenti per emettere, detenere e controllare i propri identificativi e attestazioni. --- @@ -75,13 +75,13 @@ L'identità decentralizzata può aiutare a creare delle community online prive d Le applicazioni di concessione di sovvenzioni che utilizzano il [voto quadratico](/glossary/#quadratic-voting) sono vulnerabili agli [attacchi Sybil](/glossary/#sybil-attack) poiché il valore di una sovvenzione viene incrementato all'aumentare delle persone che votano, incentivando gli utenti a dividere i propri contributi tra più identità. Le identità decentralizzate aiutano a prevenirli, incrementando l'onere su ogni partecipante, per dimostrare che siano realmente umani, sebbene spesso senza dover rilevare informazioni private specifiche. -## Cosa sono le attestazioni? {#what-are-attestations} +## Cosa sono le attestazioni? {#national-and-government-id} Un'attestazione, è una dichiarazione effettuata da un'entità, in merito a un'altra entità. Se vivi in Italia, la patente di guida rilasciata dal Dipartimento dei Trasporti Terrestri (un'entità), attesta che tu (un'altra entità), sei legalmente autorizzato a guidare un'auto. Le attestazioni sono differenti dagli identificativi. Un'attestazione _contiene_ degli identificativi, riferiti a un'identità in particolare, ed effettua una dichiarazione su di un attributo, relativo a tale identità. Quindi, la tua patente di guida contiene degli identificativi (nome, data di nascita, indirizzo), ma è anche l'attestazione sul tuo diritto legale alla guida. -### Cosa sono gli identificativi decentralizzati? {#what-are-decentralized-identifiers} +### Cosa sono gli identificativi decentralizzati? {#case-study-bhutan-ndi} Gli identificativi tradizionali, come il tuo nome legale o l'indirizzo email, si affidano a terze parti: governi e fornitori di email. Gli identificativi decentralizzati (DID), sono differenti: non sono emessi, gestiti o controllati da alcuna entità centrale. @@ -89,21 +89,21 @@ Gli identificativi decentralizzati sono emessi, detenuti e controllati dagli ind Gli identificativi decentralizzati sono memorizzati su libri mastri distribuiti ([blockchain](/glossary/#blockchain)) o su [reti peer-to-peer](/glossary/#peer-to-peer-network). Ciò rende i DID [unici a livello globale, risolvibili con elevata disponibilità e crittograficamente verificabili](https://w3c-ccg.github.io/did-primer/). Un identificativo decentralizzato può essere associato a diverse entità, tra cui persone, organizzazioni, o istituzioni governative. -## Cosa rende possibili gli identificativi decentralizzati? {#what-makes-decentralized-identifiers-possible} +## Cosa rende possibili gli identificativi decentralizzati? {#case-study-buenos-aires-quarkid} -### 1. Crittografia a chiave pubblica {#public-key-cryptography} +### 1. Crittografia a chiave pubblica {#what-are-attestations} La crittografia a chiave pubblica è una misura di sicurezza informatica che genera una [chiave pubblica](/glossary/#public-key) e una [chiave privata](/glossary/#private-key) per un'entità. La [crittografia](/glossary/#cryptography) a chiave pubblica è utilizzata nelle reti blockchain per autenticare le identità degli utenti e dimostrare la proprietà delle risorse digitali. Alcuni identificativi decentralizzati, come un conto di Ethereum, includono chiavi pubbliche e private. La chiave pubblica identifica chi controlla il conto, mentre le chiavi private possono firmare e decrittografare i messaggi per tale conto. La crittografia a chiave pubblica fornisce le prove necessarie per autenticare le entità, oltre a prevenire i furti d'identità e l'utilizzo di false identità, utilizzando le [firme crittografiche](https://andersbrownworth.com/blockchain/public-private-keys/) per verificare tutte le dichiarazioni. -### 2. Datastore decentralizzati {#decentralized-datastores} +### 2. Datastore decentralizzati {#what-are-decentralized-identifiers} Una blockchain funge da registro di dati verificabili: una repository di informazioni aperta, affidabile e decentralizzata. L'esistenza delle blockchain pubbliche elimina l'esigenza di memorizzare gli identificativi nei registri centralizzati. Se qualcuno deve confermare la validità di un identificativo decentralizzato, può consultare la chiave pubblica associata sulla blockchain. Ciò differisce dagli identificativi tradizionali, che richiedono l'autenticazione da parte di terzi. -## Come fanno le attestazioni e gli identificativi decentralizzati a consentire l'identità decentralizzata? {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity} +## Come fanno le attestazioni e gli identificativi decentralizzati a consentire l'identità decentralizzata? {#what-makes-decentralized-identifiers-possible} L'identità decentralizzata è l'idea che le informazioni sull'identità dovrebbero essere controllate dall'individuo, private e portatili, con attestazioni e identificativi decentralizzati come blocchi di costruzione principali. @@ -115,11 +115,11 @@ Gli identificativi decentralizzati sono il motivo per cui le attestazioni sono c Inoltre, gli identificativi decentralizzati sono fondamentali per la protezione della privacy delle informazioni personali, tramite l'identità decentralizzata. Ad esempio, se un individuo invia la prova di un'attestazione (una patente di guida), la parte che verifica non necessita di controllare la validità delle informazioni nella prova. Invece, chi verifica necessita soltanto delle garanzie crittografiche dell'autenticità dell'attestazione, e dell'identità dell'organizzazione emittente, per determinare se la prova sia valida. -## Tipi di attestazioni nell'identità decentralizzata {#types-of-attestations-in-decentralized-identity} +## Tipi di attestazioni nell'identità decentralizzata {#public-key-cryptography} Le modalità di memorizzazione e recupero delle informazioni sull'attestazione, nell'ecosistema delle identità basato su Ethereum, differiscono dalla gestione tradizionale delle identità. Ecco una panoramica dei vari approcci all'emissione, memorizzazione e verifica delle attestazioni, nei sistemi di identità decentralizzati: -### Attestazioni esterne alla catena {#off-chain-attestations} +### Attestazioni esterne alla catena {#decentralized-datastores} Un timore per la memorizzazione su catena è che potrebbero contenere informazioni che gli individui desiderano mantenere private. La natura pubblica della blockchain di Ethereum, rende poco attraente la memorizzazione di tali attestazioni. @@ -131,13 +131,13 @@ Ecco uno scenario ipotetico per spiegare le attestazioni esterne alla catena: 2. Bob si candida per un lavoro e desidera dimostrare le proprie qualifiche accademiche a un datore di lavoro, quindi, condivide l'attestazione dal proprio portafoglio mobile. L'azienda (verificatore), può quindi confermare la validità dell'attestazione, verificando il DID dell'emittente (cioè, la sua chiave pubblica su Ethereum). -### Attestazioni esterne alla catena con accesso persistente {#offchain-attestations-with-persistent-access} +### Attestazioni esterne alla catena con accesso persistente {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity} In questo modo, le attestazioni sono trasformate in file JSON e memorizzate all'esterno della catena (idealmente, su una piattaforma di [archiviazione decentralizzata su cloud](/developers/docs/storage/), come IPFS o Swarm). Tuttavia, un [hash](/glossary/#hash) del file JSON è memorizzato sulla catena e collegato a un DID, tramite il registro sulla catena. Il DID associato potrebbe essere quello dell'emittente dell'attestazione, o del destinatario. Tale approccio consente alle attestazioni di ottenere persistenza basata sulla blockchain, mantenendo le informazioni delle dichiarazioni, crittografate e verificabili. Inoltre, consente la divulgazione selettiva, poiché il titolare della chiave privata può decrittografare le informazioni. -### Attestazioni sulla catena {#onchain-attestations} +### Attestazioni sulla catena {#types-of-attestations-in-decentralized-identity} Le attestazioni sulla catena sono conservate nei [contratti intelligenti](/glossary/#smart-contract) sulla blockchain di Ethereum. Il contratto intelligente (che agisce da registro), mapperà un'attestazione a un identificativo decentralizzato corrispondente sulla catena (una chiave pubblica). @@ -149,11 +149,11 @@ Ecco un esempio per dimostrare il funzionamento in pratica delle attestazioni su 3. Il contratto intelligente che vende le quote, può verificare il contratto del registro per le identità degli acquirenti verificati, rendendo possibile la determinazione di chi possa acquistare le quote e chi no. -### Token vincolati e identità {#soulbound} +### Token vincolati e identità {#offchain-attestations} I [token vincolati](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([NFT non trasferibili](/glossary/#nft)) potrebbero essere utilizzati per raccogliere informazioni univoche per un portafoglio specifico. Ciò, effettivamente, crea un'identità univoca sulla catena, vincolata a un indirizzo di Ethereum in particolare, che potrebbe includere i token rappresentanti obiettivi (ad esempio, concludere un certo corso online o superare una soglia di punteggio in un gioco), o la partecipazione della community. -## Utilizzare l'identità decentralizzata {#use-decentralized-identity} +## Utilizzare l'identità decentralizzata {#offchain-attestations-with-persistent-access} Esistono molti progetti ambiziosi che utilizzano Ethereum come base per le soluzioni di identità decentralizzata: @@ -165,9 +165,9 @@ Esistono molti progetti ambiziosi che utilizzano Ethereum come base per le soluz - **[walt.id](https://walt.id)**: _Infrastruttura open source di identità decentralizzata e portafoglio che consente a sviluppatori e organizzazioni di sfruttare l'identità auto-sovrana e gli NFT/SBT._ - **[Veramo](https://veramo.io/)**: _Un framework di JavaScript che facilita per tutti l'utilizzo di dati verificabili crittograficamente nelle proprie applicazioni._ -## Lettura consigliate {#further-reading} +## Lettura consigliate {#onchain-attestations} -### Articoli {#articles} +### Articoli {#soulbound} - [Casi d'Uso della Blockchain: La Blockchain nell'Identità Digitale](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_ - [Cos'è l'ERC-725 di Ethereum? Gestione dell'Identità Sovrana Personale sulla Blockchain](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_ @@ -175,7 +175,7 @@ Esistono molti progetti ambiziosi che utilizzano Ethereum come base per le soluz - [Cos'è l'Identità Decentralizzata e Perché Dovrebbe Interessarti?](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_ - [Introduzione all'Identità decentralizzata](https://walt.id/white-paper/digital-identity) - _Dominik Beron_ -### Video {#videos} +### Video {#use-decentralized-identity} - [Identità Decentralizzata (Sessione Live Bonus)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Un ottimo video esplicativo sull'identità decentralizzata, di Andreas Antonopolous_ - [Accedi con Ethereum e l'Identità Decentralizzata con Ceramic, IDX, React e 3ID Connect](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _Tutorial di YouTube sulla creazione di un sistema di gestione dell'identità, per creare, leggere e aggiornare il profilo di un utente, utilizzandone il portafoglio di Ethereum; di Nader Dabit_ @@ -183,7 +183,7 @@ Esistono molti progetti ambiziosi che utilizzano Ethereum come base per le soluz - [L'Internet esterno alla Catena: Identità Decentralizzata e Credenziali Verificabili](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — Presentazione dell'EthDenver del 2022, di Evin McMullen - [Credenziali verificabili spiegate](https://www.youtube.com/watch?v=ce1IdSr-Kig): Video esplicativo su YouTube con dimostrazione di Tamino Baumann -### Community {#communities} +### Community {#further-reading} - [ERC-725 Alliance su GitHub](https://github.com/erc725alliance) — _Sostenitori dello standard ERC-725 per la gestione dell'identità sulla blockchain di Ethereum_ - [Server Discord di EthID](https://discord.com/invite/ZUyG3mSXFD) — _Community per appassionati e sviluppatori, al lavoro su "Accedi con Ethereum"_ diff --git a/public/content/translations/it/defi/index.md b/public/content/translations/it/defi/index.md index 9d2ae0086cd..5e48954491e 100644 --- a/public/content/translations/it/defi/index.md +++ b/public/content/translations/it/defi/index.md @@ -1,16 +1,16 @@ --- title: Finanza decentralizzata (DeFi) -metaTitle: Cos'è la DeFi? | Benefici e utilizzi della finanza decentralizzata +metaTitle: "Cos'è la DeFi? | Benefici e utilizzi della finanza decentralizzata" description: Una panoramica sulla DeFi su Ethereum lang: it template: use-cases emoji: ":money_with_wings:" image: /images/use-cases/defi.png alt: Logo di Eth, composto da mattoncini Lego. -sidebarDepth: 3 +sidebarDepth: 2 summaryPoint1: Un'alternativa globale e aperta al sistema finanziario odierno. summaryPoint2: Prodotti che ti consentono di prendere in prestito, risparmiare, investire, scambiare, e molto altro. -summaryPoint3: Basata sulla tecnologia open source, con cui chiunque può programmare. +summaryPoint3: "Basata sulla tecnologia open source, con cui chiunque può programmare." --- La DeFi è un sistema finanziario aperto e globale, creato per l'era di Internet: un'alternativa a un sistema opaco, rigidamente controllato e tenuto insieme da infrastrutture e processi vecchi di decenni. Offre il controllo e la visibilità sul proprio denaro. Fornisce esposizione ai mercati globali e alternative alla tua valuta o alle opzioni bancarie locali. I prodotti della DeFi aprono i servizi finanziari a chiunque abbia una connessione a Internet, e sono prevalentemente posseduti e mantenuti dai loro utenti. Finora, decine di miliardi di dollari in criptovalute, sono confluiti per le applicazioni della DeFi, e crescono ogni giorno. diff --git a/public/content/translations/it/developers/docs/apis/json-rpc/index.md b/public/content/translations/it/developers/docs/apis/json-rpc/index.md index 9f2295b0800..3620b4aa658 100644 --- a/public/content/translations/it/developers/docs/apis/json-rpc/index.md +++ b/public/content/translations/it/developers/docs/apis/json-rpc/index.md @@ -58,7 +58,7 @@ Ecco alcuni esempi: - ERRATO: 0xf0f0f (dev'essere un numero di cifre pari) - ERRATO: 004200 (deve avere il prefisso 0x) -### Il parametro del blocco predefinito {#default-block} +### Il parametro del blocco predefinito {#block-parameter} I seguenti metodi hanno un parametro del blocco predefinito aggiuntivo: @@ -566,7 +566,7 @@ Restituisce il saldo del conto del dato indirizzo. **Parametri** 1. `DATA`, 20 byte - indirizzo per controllare il saldo. -2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter) ```js params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] @@ -597,7 +597,7 @@ Restituisce il valore da una posizione di archiviazione a un dato indirizzo. 1. `DATA`, 20 byte - Indirizzo di archiviazione. 2. `QUANTITY` - intero della posizione di archiviazione. -3. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +3. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter) **Restituisce** @@ -663,7 +663,7 @@ Restituisce il numero di transazioni _inviate_da un indirizzo. **Parametri** 1. `DATA`, 20 byte - indirizzo. -2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ @@ -724,7 +724,7 @@ Restituisce il numero di transazioni in un blocco corrispondente al numero di bl **Parametri** -1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block). +1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter). ```js params: [ @@ -784,7 +784,7 @@ Restituisce il numero di ommer in un blocco da un blocco che corrisponde all'has **Parametri** -1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ @@ -816,7 +816,7 @@ Restituisce il codice ad un dato indirizzo. **Parametri** 1. `DATA`, 20 byte - indirizzo -2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ @@ -1003,7 +1003,7 @@ Esegue immediatamente una nuova chiamata di messaggio senza creare una transazio - `value`: `QUANTITY` - (facoltativo) Intero del valore inviato con questa transazione - `input`: `DATA` - (facoltativo) Hash della firma del metodo e dei parametri codificati. Per i dettagli, consulta [ABI del Contratto di Ethereum nella documentazione di Solidity](https://docs.soliditylang.org/en/latest/abi-spec.html). -2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter) **Restituisce** @@ -1130,7 +1130,7 @@ Restituisce informazioni su un blocco per numero di blocco. **Parametri** -1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block). +1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter). 2. `Boolean` - Se `true` restituisce gli oggetti di transazione completi, se `falso` solo gli hash delle transazioni. ```js @@ -1243,7 +1243,7 @@ Restituisce informazioni su una transazione per hash del blocco e posizione dell **Parametri** -1. `QUANTITY|TAG`: il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block). +1. `QUANTITY|TAG`: il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#block-parameter). 2. `QUANTITY` - la posizione dell'indice della transazione. ```js @@ -1366,7 +1366,7 @@ Restituisce informazioni su un ommer di un blocco in base al numero e alla posiz **Parametri** -1. `QUANTITY|TAG` - il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, come nel [parametro predefinito del blocco](/developers/docs/apis/json-rpc/#default-block). +1. `QUANTITY|TAG` - il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, come nel [parametro predefinito del blocco](/developers/docs/apis/json-rpc/#block-parameter). 2. `QUANTITY` - la posizione dell'indice dell'ommer. ```js diff --git a/public/content/translations/it/developers/docs/blocks/index.md b/public/content/translations/it/developers/docs/blocks/index.md index ff09aa44f91..2492628c912 100644 --- a/public/content/translations/it/developers/docs/blocks/index.md +++ b/public/content/translations/it/developers/docs/blocks/index.md @@ -24,7 +24,7 @@ Per preservare la cronologia delle transazioni, i blocchi sono ordinati in modo Dopo essere stato realizzato da un validatore della rete selezionato casualmente, un blocco viene propagato al resto della rete; tutti i nodi vengono aggiunti al blocco alla fine della relativa blockchain e un nuovo validatore viene selezionato per creare il successivo. Il processo esatto di costruzione dei blocchi e il processo di invio/consenso è attualmente specificato nel protocollo "Proof of Stake" di Ethereum. -## Protocollo Proof of Stake {#proof-of-work-protocol} +## Protocollo Proof of Stake {#proof-of-stake-protocol} Proof of Stake significa quanto segue: diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md index aa10661a7cb..744486b8bdc 100644 --- a/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md +++ b/public/content/translations/it/developers/docs/consensus-mechanisms/poa/index.md @@ -1,6 +1,6 @@ --- -title: Prova di autorità (PoA) -description: Una spiegazione del protocollo di consenso a prova di autorità e del suo ruolo nell'ecosistema della blockchain. +title: "Prova di autorità (PoA)" +description: "Una spiegazione del protocollo di consenso a prova di autorità e del suo ruolo nell'ecosistema della blockchain." lang: it --- diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md index 4e939b15a83..9017d3116b8 100644 --- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md +++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -1,6 +1,6 @@ --- title: "Proof-of-stake Ethereum: attacchi e meccanismi di difesa" -description: Scopri di più sui vettori di attacco noti sul proof-of-stake di Ethereum e come è possibile difendersi da essi. +description: "Scopri di più sui vettori di attacco noti sul proof-of-stake di Ethereum e come è possibile difendersi da essi." lang: it --- diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index f4bac577534..5dabb469e8a 100644 --- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -1,6 +1,6 @@ --- title: Ricompense e sanzioni del proof-of-stake -description: Scopri di più sugli incentivi del protocollo nel proof-of-stake di Ethereum. +description: "Scopri di più sugli incentivi del protocollo nel proof-of-stake di Ethereum." lang: it --- diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md index 4c1b5628951..5c34d9ab106 100644 --- a/public/content/translations/it/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md +++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -1,6 +1,6 @@ --- -title: Soggettività debole -description: Una spiegazione della soggettività debole e del suo ruolo nell'Ethereum PoS. +title: "Soggettività debole" +description: "Una spiegazione della soggettività debole e del suo ruolo nell'Ethereum PoS." lang: it --- diff --git a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md index cee1f041f73..6b7c5c89975 100644 --- a/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md +++ b/public/content/translations/it/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -8,7 +8,7 @@ lang: it - Ethash era l'algoritmo di mining di proof-of-work di Ethereum. Il proof-of-work è ora stato **disattivato interamente** e, invece, Ethereum è ora protetto utilizzando il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). Leggi di più su [La Fusione](/roadmap/merge/), sul [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e sullo [staking](/staking/). Questa pagina è per interesse storico! + Ethash era l'algoritmo di mining di proof-of-work di Ethereum. Il proof-of-work è ora stato **disattivato interamente** e, invece, Ethereum è ora protetto utilizzando il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). Leggi di più su [La Fusione](/roadmap/merge/), sul [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) e sullo [staking](/staking/). Questa pagina è per interesse storico! diff --git a/public/content/translations/it/developers/docs/data-and-analytics/index.md b/public/content/translations/it/developers/docs/data-and-analytics/index.md index 326c2658b65..2a913ee8348 100644 --- a/public/content/translations/it/developers/docs/data-and-analytics/index.md +++ b/public/content/translations/it/developers/docs/data-and-analytics/index.md @@ -32,20 +32,21 @@ Usando [GraphQL](https://graphql.org/), gli sviluppatori possono interrogare una La [diversità dei client](/developers/docs/nodes-and-clients/client-diversity/) è importante per la salute complessiva della rete di Ethereum, poiché fornisce resilienza a bug ed exploit. Attualmente esistono vari pannelli di controllo della diversità del client, tra cui [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) ed [Ethernodes](https://ethernodes.org/). -## Dune Analytics {#dune-analytics} +## Dune Analytics {#client-diversity} [Dune Analytics](https://dune.com/) pre-elabora i dati della blockchain nelle tabelle del database relazionale (DuneSQL), consente agli utenti di richiedere i dati della blockchain utilizzando SQL e crea pannelli di controllo basati sui risultati della richiesta. I dati sulla catena sono organizzati in 4 tabelle grezze: `blocks`, `transactions`, `logs` (di eventi) e `traces` (di chiamate). I contratti e protocolli popolari sono stati decodificati e ognuno ha la propria serie di tabelle di eventi e chiamate. Queste tabelle di eventi e chiamate sono ulteriormente elaborate e organizzate in tabelle di astrazione secondo il tipo di protocolli, ad esempio dex, lending, stablecoins, ecc. -## Rete di SubQuery {#subquery-network} +## Rete di SubQuery {#dune-analytics} [SubQuery](https://subquery.network/) è un indicizzatore di dati leader del settore, che fornisce agli sviluppatori API veloci, affidabili, decentralizzate e personalizzate per i loro progetti in Web3. SubQuery emancipa gli sviluppatori da oltre 165 ecosistemi (incluso Ethereum) con dati indicizzati ricchi, per creare esperienze intuitive e immersive per i propri utenti. La Rete di SubQuery alimenta le tue inarrestabili app con una rete resiliente e un'infrastruttura decentralizzata. Utilizza gli strumenti per sviluppatori di blockchain di SubQuery per creare le applicazioni Web3 del futuro, senza dover dedicare tempo a sviluppare un backend personalizzato per le attività di elaborazione dei dati. Per iniziare, visita la [guida rapida per principianti di Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) per iniziare a indicizzare i dati della blockchain di Ethereum in pochi minuti in un ambiente locale di Docker per i test prima di distribuire il tuo progetto su un [servizio gestito da SubQuery](https://managedservice.subquery.network/) o su una [rete decentralizzata di SubQuery](https://app.subquery.network/dashboard). -## Ethernow - Programma dei dati del Mempool {#ethernow} +## Ethernow - Programma dei dati del Mempool {#sqd} + [Blocknative](https://www.blocknative.com/) fornisce l'accesso aperto al suo [archivio dei dati del mempool](https://www.ethernow.xyz/mempool-data-archive) storico di Ethereum. Questo consente ai ricercatori e ai progetti della community di esplorare il livello pre-catena della Rete Principale di Ethereum. La serie di dati è mantenuta attivamente e rappresenta il registro storico più completo degli eventi di transazione del mempool nell'ecosistema di Ethereum. Maggiori informazioni su [Ethernow](https://www.ethernow.xyz/). -## Letture consigliate {#further-reading} +## Letture consigliate {#subquery-network} - [Panoramica della rete Graph](https://thegraph.com/docs/en/about/) - [GraphQL Playground](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) diff --git a/public/content/translations/it/developers/docs/data-availability/index.md b/public/content/translations/it/developers/docs/data-availability/index.md index 7b1bb070581..369d6d81788 100644 --- a/public/content/translations/it/developers/docs/data-availability/index.md +++ b/public/content/translations/it/developers/docs/data-availability/index.md @@ -1,6 +1,6 @@ --- -title: Disponibilità dei dati -description: Una panoramica dei problemi e delle soluzioni relative alla disponibilità dei dati in Ethereum +title: "Disponibilità dei dati" +description: "Una panoramica dei problemi e delle soluzioni relative alla disponibilità dei dati in Ethereum" lang: it --- diff --git a/public/content/translations/it/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/it/developers/docs/design-and-ux/heuristics-for-web3/index.md index 2f0aaa2df51..f89f227fde2 100644 --- a/public/content/translations/it/developers/docs/design-and-ux/heuristics-for-web3/index.md +++ b/public/content/translations/it/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -1,6 +1,6 @@ --- title: 7 euristiche per la progettazione di interfacce Web3 -description: Principi per migliorare l'usabilità del Web3 +description: "Principi per migliorare l'usabilità del Web3" lang: it --- diff --git a/public/content/translations/it/developers/docs/design-and-ux/index.md b/public/content/translations/it/developers/docs/design-and-ux/index.md index 40ba1cd7f16..aa157d71d20 100644 --- a/public/content/translations/it/developers/docs/design-and-ux/index.md +++ b/public/content/translations/it/developers/docs/design-and-ux/index.md @@ -78,7 +78,7 @@ Partecipate ad organizzazioni professionali guidate dalla community o unitevi a - [We3.co](https://we3.co/) - [Openux.xyz](https://openux.xyz/) -## Sistemi di progettazione {#design-systems} +## Sistemi di progettazione {#design-systems-and-resources} - [Progettazione di Optimism](https://www.figma.com/@optimism) (Figma) - [Sistema di progettazione di Ethereum.org](https://www.figma.com/@ethdotorg) (Figma) diff --git a/public/content/translations/it/developers/docs/evm/index.md b/public/content/translations/it/developers/docs/evm/index.md index c1ae60e919f..50268badf5a 100644 --- a/public/content/translations/it/developers/docs/evm/index.md +++ b/public/content/translations/it/developers/docs/evm/index.md @@ -4,7 +4,7 @@ description: Un'introduzione alla Macchina Virtuale di Ethereum e a come si rela lang: it --- -La Macchina Virtuale di Ethereum (EVM) è un ambiente virtuale decentralizzato che esegue il codice con coerenza e sicurezza su tutti i nodi di Ethereum. I nodi eseguono l'EVM per eseguire i contratti intelligenti, utilizzando il "[gas](/gas/)" per misurare lo sforzo di calcolo necessario per le [operazioni](/developers/docs/evm/opcodes/), assicurando un'efficace allocazione delle risorse e la sicurezza della rete. +La Macchina Virtuale di Ethereum (EVM) è un ambiente virtuale decentralizzato che esegue il codice con coerenza e sicurezza su tutti i nodi di Ethereum. I nodi eseguono l'EVM per eseguire i contratti intelligenti, utilizzando il "[gas](/developers/docs/gas/)" per misurare lo sforzo di calcolo necessario per le [operazioni](/developers/docs/evm/opcodes/), assicurando un'efficace allocazione delle risorse e la sicurezza della rete. ## Prerequisiti {#prerequisites} diff --git a/public/content/translations/it/developers/docs/intro-to-ethereum/index.md b/public/content/translations/it/developers/docs/intro-to-ethereum/index.md index 26d4c9ffb8e..da74e7a90f2 100644 --- a/public/content/translations/it/developers/docs/intro-to-ethereum/index.md +++ b/public/content/translations/it/developers/docs/intro-to-ethereum/index.md @@ -111,6 +111,6 @@ Uno snippet di codice riutilizzabile (programma) che uno sviluppatore pubblica n _Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_ -## Tutorial correlati {#related-tutorials} +## Tutorial correlati {#visual-learner} - [Una guida per sviluppatori a Ethereum, parte 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Un'esplorazione di Ethereum pensata per i principianti usando Python e web3.py_ diff --git a/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md index 114400531ff..0fce61908eb 100644 --- a/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md +++ b/public/content/translations/it/developers/docs/networking-layer/portal-network/index.md @@ -82,7 +82,7 @@ La presenza di più implementazioni client indipendenti aumenta la resilienza e Se un client presenta problemi o vulnerabilità, gli altri client possono continuare a funzionare senza problemi, evitando un punto di errore singolo. Inoltre, le diverse implementazioni dei clienti favoriscono l'innovazione e la concorrenza, promuovendo miglioramenti e riducendo il rischio di monopolio all'interno dell'ecosistema. -## Letture consigliate {#futher-reading} +## Letture consigliate {#further-reading} - [La Rete Portal (Piper Merriam al Devcon di Bogotà)](https://www.youtube.com/watch?v=0stc9jnQLXA). - [Discord della Rete Portal](https://discord.gg/CFFnmE7Hbs) diff --git a/public/content/translations/it/developers/docs/networks/index.md b/public/content/translations/it/developers/docs/networks/index.md index 08b89ae21e4..e2f09ac32c0 100644 --- a/public/content/translations/it/developers/docs/networks/index.md +++ b/public/content/translations/it/developers/docs/networks/index.md @@ -84,11 +84,11 @@ Hoodi è una rete di prova per testare la convalida e lo staking. La rete Hoodi Per lanciare un Validatore sulla rete di prova Hoodi, usa il [launchpad di Hoodi](https://hoodi.launchpad.ethereum.org/en/). -### Rete di prova del livello 2 {#layer-2-testnets} +### Rete di prova del livello 2 {#ephemery} [Livello 2 (L2)](/layer-2/) è un termine collettivo per descrivere un insieme specifico di soluzioni di ridimensionamento di Ethereum. Un livello 2 è una blockchain separata che estende Ethereum ed eredita le garanzie di sicurezza di Ethereum. Solitamente le reti di prova di Livello 2 sono strettamente accoppiate alle reti di prova pubbliche di Ethereum. -#### Arbitrum Sepolia {#arbitrum-sepolia} +#### Arbitrum Sepolia {#holesky} Una rete di prova per [Arbitrum](https://arbitrum.io/). @@ -97,7 +97,7 @@ Una rete di prova per [Arbitrum](https://arbitrum.io/). - [Faucet Chainlink](https://faucets.chain.link/arbitrum-sepolia) - [Faucet Alchemy](https://www.alchemy.com/faucets/arbitrum-sepolia) -#### Optimistic Sepolia {#optimistic-sepolia} +#### Optimistic Sepolia {#layer-2-testnets} Una rete di prova per [Optimism](https://www.optimism.io/). @@ -106,7 +106,7 @@ Una rete di prova per [Optimism](https://www.optimism.io/). - [Faucet Chainlink](https://faucets.chain.link/optimism-sepolia) - [Faucet Alchemy](https://www.alchemy.com/faucets/optimism-sepolia) -#### Starknet Sepolia {#starknet-sepolia} +#### Starknet Sepolia {#arbitrum-sepolia} Una rete di prova per [Starknet](https://www.starknet.io). @@ -114,28 +114,28 @@ Una rete di prova per [Starknet](https://www.starknet.io). - [Faucet Alchemy](https://www.alchemy.com/faucets/starknet-sepolia) -## Reti private {#private-networks} +## Reti private {#optimistic-sepolia} Una rete Ethereum è una rete privata se i relativi nodi non sono connessi a una rete pubblica (ossia Rete principale o una rete di prova). In questo contesto, privato significa solo riservato o isolato, e non protetto o sicuro. -### Reti di sviluppo {#development-networks} +### Reti di sviluppo {#starknet-sepolia} Per sviluppare un'applicazione Ethereum, è consigliabile eseguirla prima su una rete privata per vedere come funziona prima di distribuirla. Come quando si crea un server locale sul computer per lo sviluppo web, è possibile creare un'istanza locale della blockchain per testare una dapp. Questo offre un'iterazione molto più veloce rispetto a una rete di prova pubblica. Ci sono progetti e strumenti dedicati a questo scopo. Scopri di più sulle [reti di sviluppo](/developers/docs/development-networks/). -### Reti di consorzio {#consortium-networks} +### Reti di consorzio {#private-networks} Il processo di consenso è controllato da una serie predefinita di nodi considerati attendibili. Un esempio può essere una rete privata di istituti accademici noti, dove ogni istituto controlla un singolo nodo e i blocchi vengono convalidati da una soglia di firmatari all'interno della rete. Se una rete Ethereum pubblica è come la rete Internet pubblica, una rete di consorzio è come una Intranet privata. -## Strumenti correlati {#related-tools} +## Strumenti correlati {#development-networks} - [Chainlist](https://chainlist.org/) _Elenco di reti EVM per connettere portafogli e fornitori all'ID della Catena e ID di Rete appropriati._ - [Catene basate su EVM](https://github.com/ethereum-lists/chains) _Repository di GitHub di metadati della catena che alimentano Chainlist._ -## Letture consigliate {#further-reading} +## Letture consigliate {#consortium-networks} - [Proposta: ciclo di vita prevedibile delle reti di prova di Ethereum](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) - [L'evoluzione delle reti di prova di Ethereum](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) diff --git a/public/content/translations/it/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/it/developers/docs/nodes-and-clients/client-diversity/index.md index 06dc895256d..63192bb54f0 100644 --- a/public/content/translations/it/developers/docs/nodes-and-clients/client-diversity/index.md +++ b/public/content/translations/it/developers/docs/nodes-and-clients/client-diversity/index.md @@ -1,6 +1,6 @@ --- -title: Diversità dei client -description: Una spiegazione generica dell'importanza della diversità di client di Ethereum. +title: "Diversità dei client" +description: "Una spiegazione generica dell'importanza della diversità di client di Ethereum." lang: it sidebarDepth: 2 --- @@ -49,15 +49,15 @@ I dati del livello di esecuzione sono stati ottenuti da [Ethernodes](https://eth I dati di diversità dei client aggiornati per il livello del consenso sono ora disponibili su [clientdiversity.org](https://clientdiversity.org/). -## Livello di esecuzione {#execution-layer} +## Livello di esecuzione {#execution-clients-breakdown} Finora, la conversazione sulla diversità dei client si è concentrata sul livello del consenso. Tuttavia, il client d'esecuzione [Geth](https://geth.ethereum.org) rappresenta correntemente circa l'85% di tutti i nodi. Questa percentuale è problematica per gli stessi motivi dei client di consenso. Ad esempio, un bug su Geth che influenzi la gestione delle transazioni o la costruzione dei carichi utili d'esecuzione potrebbe condurre alla finalizzazione da parte dei client di consenso di transazioni problematiche o contenenti bug. Ethereum sarebbe più quindi più robusto con una distribuzione più equa dei client d'esecuzione, idealmente senza alcun client che rappresenti oltre il 33% della rete. -## Usare un client di minoranza {#use-minority-client} +## Usare un client di minoranza {#consensus-clients-breakdown} Per "indirizzare" la diversità dei client non basta che i singoli utenti scelgano i client di minoranza, richiede che anche i pool di mining/validatori e le istituzioni come le dApp principali e gli scambi cambino client. Tuttavia, tutti gli utenti possono fare la propria parte nel correggere l'attuale disequilibrio e normalizzare l'uso di tutti i software di Ethereum disponibili. Dopo La Fusione, tutti gli operatori di nodi dovranno eseguire un client d'esecuzione e un client di consenso. Scegliere le combinazioni dei client suggerite di seguito aiuterà ad aumentare la diversità dei client. -### Client di esecuzione {#execution-clients} +### Client di esecuzione {#execution-layer} [Besu](https://www.hyperledger.org/use/besu) @@ -67,7 +67,7 @@ Per "indirizzare" la diversità dei client non basta che i singoli utenti scelga [Go-Ethereum](https://geth.ethereum.org/) -### Client di consenso {#consensus-clients} +### Client di consenso {#use-minority-client} [Nimbus](https://nimbus.team/) @@ -83,7 +83,7 @@ Per "indirizzare" la diversità dei client non basta che i singoli utenti scelga Gli utenti tecnici possono aiutare ad accelerare questo processo scrivendo più tutorial e documentazioni per i client di minoranza e incoraggiando i propri peer che eseguono dei nodi a migrare dai client dominanti. Le guide per passare a un client di consenso di minoranza sono disponibili su [clientdiversity.org](https://clientdiversity.org/). -## Pannelli di controllo sulla diversità dei client {#client-diversity-dashboards} +## Pannelli di controllo sulla diversità dei client {#execution-clients} Diversi pannelli di controllo forniscono statistiche sulla diversità dei client in tempo reale per il livello d'esecuzione e di consenso. @@ -95,7 +95,7 @@ Diversi pannelli di controllo forniscono statistiche sulla diversità dei client - [supermajority.info](https://supermajority.info//) - [Ethernodes](https://ethernodes.org/) -## Letture consigliate {#further-reading} +## Letture consigliate {#consensus-clients} - [Diversità dei client sul livello di consenso di Ethereum](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) - [Fusione di Ethereum: esegui il client di maggioranza a tuo rischio!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest, 24 marzo 2022_ @@ -105,7 +105,7 @@ Diversi pannelli di controllo forniscono statistiche sulla diversità dei client - [Diversità di Ethereum e come risolverla (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) - [clientdiversity.org](https://clientdiversity.org/) -## Argomenti correlati {#related-topics} +## Argomenti correlati {#client-diversity-dashboards} - [Eseguire un nodo di Ethereum](/run-a-node/) - [Nodi e client](/developers/docs/nodes-and-clients/) diff --git a/public/content/translations/it/developers/docs/nodes-and-clients/index.md b/public/content/translations/it/developers/docs/nodes-and-clients/index.md index 98eb12ebed7..74f6e768d3f 100644 --- a/public/content/translations/it/developers/docs/nodes-and-clients/index.md +++ b/public/content/translations/it/developers/docs/nodes-and-clients/index.md @@ -1,6 +1,6 @@ --- title: Nodi e client -description: Panoramica dei nodi Ethereum e del software client, come configurare un nodo e perché farlo. +description: "Panoramica dei nodi Ethereum e del software client, come configurare un nodo e perché farlo." lang: it sidebarDepth: 2 --- diff --git a/public/content/translations/it/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/it/developers/docs/nodes-and-clients/nodes-as-a-service/index.md index 8a29e3a51a0..e83c721403d 100644 --- a/public/content/translations/it/developers/docs/nodes-and-clients/nodes-as-a-service/index.md +++ b/public/content/translations/it/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -1,6 +1,6 @@ --- title: Nodi come servizio -description: Panoramica entry-level dei servizi dei nodi, dei pro e dei contro, e dei fornitori più diffusi. +description: "Panoramica entry-level dei servizi dei nodi, dei pro e dei contro, e dei fornitori più diffusi." lang: it sidebarDepth: 2 --- diff --git a/public/content/translations/it/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/it/developers/docs/nodes-and-clients/run-a-node/index.md index e3d8b368210..eda86442bcb 100644 --- a/public/content/translations/it/developers/docs/nodes-and-clients/run-a-node/index.md +++ b/public/content/translations/it/developers/docs/nodes-and-clients/run-a-node/index.md @@ -234,7 +234,7 @@ Questa sezione ti guiderà nell'avvio dei client di esecuzione. Serve solo da es Ricordati che questo è solo un esempio di base, tutte le altre impostazioni saranno predefinite. Presta attenzione alla documentazione di ogni client per conoscere i valori predefiniti, le impostazioni e le funzionalità. Per ulteriori funzionalità, ad esempio per eseguire i validatori, per il monitoraggio, ecc., fai riferimento alla documentazione del client specifico. -> Nota che i backslash `\` negli esempi servono solo a scopi di formattazione; i flag di configurazione sono definibili in una singola riga. +> Nota che i backslash `` negli esempi servono solo a scopi di formattazione; i flag di configurazione sono definibili in una singola riga. ##### Eseguire Besu diff --git a/public/content/translations/it/developers/docs/oracles/index.md b/public/content/translations/it/developers/docs/oracles/index.md index 3232aa07b4c..bac34bad496 100644 --- a/public/content/translations/it/developers/docs/oracles/index.md +++ b/public/content/translations/it/developers/docs/oracles/index.md @@ -1,6 +1,6 @@ --- title: Oracoli -description: Gli oracoli forniscono ai contratti intelligenti di Ethereum l'accesso ai dati del mondo reale, sbloccando più casi d'uso e maggiore valore per gli utenti. +description: "Gli oracoli forniscono ai contratti intelligenti di Ethereum l'accesso ai dati del mondo reale, sbloccando più casi d'uso e maggiore valore per gli utenti." lang: it --- diff --git a/public/content/translations/it/developers/docs/programming-languages/javascript/index.md b/public/content/translations/it/developers/docs/programming-languages/javascript/index.md index e6e69f0248c..81a821658c4 100644 --- a/public/content/translations/it/developers/docs/programming-languages/javascript/index.md +++ b/public/content/translations/it/developers/docs/programming-languages/javascript/index.md @@ -32,7 +32,7 @@ Di più sui [contratti intelligenti](/developers/docs/smart-contracts/). ### La macchina virtuale Ethereum {#the-ethereum-virtual-machine} -Esiste un'implementazione JavaScript della [macchina virtuale di Ethereum](/en/developers/docs/evm/), che supporta le regole più recenti relative alle diramazioni della rete. Le regole relative alle diramazioni si riferiscono alle modifiche apportate alla macchina virtuale di Ethereum (EVM) a seguito di upgrade pianificati. +Esiste un'implementazione JavaScript della [macchina virtuale di Ethereum](/developers/docs/evm/), che supporta le regole più recenti relative alle diramazioni della rete. Le regole relative alle diramazioni si riferiscono alle modifiche apportate alla macchina virtuale di Ethereum (EVM) a seguito di upgrade pianificati. È suddivisa in vari pacchetti JavaScript che puoi leggere per comprendere meglio: diff --git a/public/content/translations/it/developers/docs/scaling/index.md b/public/content/translations/it/developers/docs/scaling/index.md index 6fd3b842b9b..97da0bd92d5 100644 --- a/public/content/translations/it/developers/docs/scaling/index.md +++ b/public/content/translations/it/developers/docs/scaling/index.md @@ -1,6 +1,6 @@ --- -title: Scalabilità -description: Introduzione alle diverse opzioni di scalabilità attualmente in fase di sviluppo da parte della community Ethereum. +title: "Scalabilità" +description: "Introduzione alle diverse opzioni di scalabilità attualmente in fase di sviluppo da parte della community Ethereum." lang: it sidebarDepth: 3 --- @@ -19,7 +19,7 @@ A livello concettuale, per prima cosa occorre distinguere tra scalabilità on-ch Dovresti avere una buona conoscenza di tutti gli argomenti fondamentali. L'implementazione di soluzioni di scalabilità è un argomento avanzato, in quanto la tecnologia è meno testata sul campo e continua ad essere oggetto di ricerca e sviluppo. -## Scalabilità on-chain {#on-chain-scaling} +## Scalabilità on-chain {#onchain-scaling} La scalabilità on-chain richiede modifiche al protocollo Ethereum ([rete principale](/glossary/#mainnet) di livello 1). Per molto tempo si è pensato che lo sharding della blockchain avrebbe ridimensionato Ethereum. Questo avrebbe coinvolto la divisione della blockchain in pezzi discreti (shard), che sarebbero stati verificati da sottoinsiemi dei validatori. Tuttavia, il ridimensionamento dai rollup di livello 2 ha preso il controllo come la tecnica di ridimensionamento principale. Questa è supportata dall'aggiunta di una nuova e più economica forma di dati connessi ai blocchi di Ethereum, progettati specificamente per rendere i rollup economici per gli utenti. @@ -27,7 +27,7 @@ La scalabilità on-chain richiede modifiche al protocollo Ethereum ([rete princi Lo sharding è il processo di frammentazione di un database. Sottoinsiemi di validatori sarebbero responsabili dei singoli shard invece di tenere traccia di tutta la rete Ethereum. Un tempo destinato a essere trasferito verso il proof-of-stake prima della Fusione, lo sharding è stato per molto tempo sulla [tabella di marcia](/roadmap/) di Ethereum. Tuttavia, il rapido sviluppo dei [rollup di livello 2](#layer-2-scaling) e l'invenzione del [Dansharding](/roadmap/danksharding) (aggiunta di blob di dati di rollup ai blocchi di Ethereum che possono essere verificati in modo molto efficiente dai validatori), ha portato la community di Ethereum a preferire il ridimensionamento incentrato sui rollup piuttosto che sullo sharding. Ciò aiuterà anche a mantenere più semplice la logica del consenso di Ethereum. -## Scalabilità off-chain {#off-chain-scaling} +## Scalabilità off-chain {#offchain-scaling} Le soluzioni off-chain sono implementate separatamente dalla Rete principale di livello 1, e non richiedono alcuna modifica al protocollo Ethereum esistente. Alcune soluzioni, note come soluzioni di "livello 2", derivano la loro sicurezza direttamente dal consenso del livello 1 di Ethereum, come i [rollup ottimistici](/developers/docs/scaling/optimistic-rollups/), i [rollup a conoscenza zero](/developers/docs/scaling/zk-rollups/) o i [canali di stato](/developers/docs/scaling/state-channels/). Altre soluzioni comportano la creazione di nuove catene in varie forme, che derivano la propria sicurezza separatamente dalla Rete principale, come le [catene secondarie](#sidechains), i [validium](#validium) o le [catene Plasma](#plasma). Queste soluzioni comunicano con la Rete principale, ma derivano la loro sicurezza in modo diverso per raggiungere una serie di obiettivi. diff --git a/public/content/translations/it/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/it/developers/docs/scaling/optimistic-rollups/index.md index 65fc1e05800..ea335814158 100644 --- a/public/content/translations/it/developers/docs/scaling/optimistic-rollups/index.md +++ b/public/content/translations/it/developers/docs/scaling/optimistic-rollups/index.md @@ -28,7 +28,7 @@ Se il batch del rollup non viene contestata (cioè, tutte le transazioni sono es ## Come interagiscono i rollup ottimistici con Ethereum? {#optimistic-rollups-and-Ethereum} -I rollup ottimistici sono [soluzioni di ridimensionamento off-chain](/developers/docs/scaling/#off-chain-scaling) create per funzionare su Ethereum. Ogni rollup ottimistico è gestito da una serie di contratti intelligenti distribuiti sulla rete di Ethereum. I rollup ottimistici elaborano le transazioni al di fuori della catena principale di Ethereum, ma pubblicano le transazioni off-chain (in batch) in un contratto di rollup on-chain. Come la blockchain di Ethereum, questo registro delle transazioni è immutabile e forma la "catena di rollup ottimistico". +I rollup ottimistici sono [soluzioni di ridimensionamento off-chain](/developers/docs/scaling/#offchain-scaling) create per funzionare su Ethereum. Ogni rollup ottimistico è gestito da una serie di contratti intelligenti distribuiti sulla rete di Ethereum. I rollup ottimistici elaborano le transazioni al di fuori della catena principale di Ethereum, ma pubblicano le transazioni off-chain (in batch) in un contratto di rollup on-chain. Come la blockchain di Ethereum, questo registro delle transazioni è immutabile e forma la "catena di rollup ottimistico". L'architettura di un optimistic rollup comprende le seguenti parti: diff --git a/public/content/translations/it/developers/docs/scaling/plasma/index.md b/public/content/translations/it/developers/docs/scaling/plasma/index.md index 67acee07f30..b89cffbde83 100644 --- a/public/content/translations/it/developers/docs/scaling/plasma/index.md +++ b/public/content/translations/it/developers/docs/scaling/plasma/index.md @@ -1,6 +1,6 @@ --- title: Catene plasma -description: Un'introduzione alle catene plasma come soluzione di scalabilità, attualmente utilizzata dalla comunità Ethereum. +description: "Un'introduzione alle catene plasma come soluzione di scalabilità, attualmente utilizzata dalla comunità Ethereum." lang: it incomplete: true sidebarDepth: 3 @@ -24,7 +24,7 @@ Le funzioni del contratto Plasma, tra le altre cose, fungono da [ponte](/develop I componenti di base del quadro Plasma sono: -### Calcolo off-chain {#off-chain-computation} +### Calcolo off-chain {#offchain-computation} La velocità di elaborazione attuale di Ethereum è limitata a circa 15-20 transazioni al secondo, riducendo la possibilità a breve termine di ridimensionamento per gestire più utenti. Questo problema esiste principalmente perché il [meccanismo di consenso](/developers/docs/consensus-mechanisms/) di Ethereum richiede molti nodi peer-to-peer per verificare ogni aggiornamento allo stato della blockchain. diff --git a/public/content/translations/it/developers/docs/scaling/validium/index.md b/public/content/translations/it/developers/docs/scaling/validium/index.md index ea548046013..e5e2f46d99c 100644 --- a/public/content/translations/it/developers/docs/scaling/validium/index.md +++ b/public/content/translations/it/developers/docs/scaling/validium/index.md @@ -1,6 +1,6 @@ --- title: Validium -description: Un'introduzione a Validium come soluzione di scalabilità, attualmente utilizzata dalla comunità Ethereum. +description: "Un'introduzione a Validium come soluzione di scalabilità, attualmente utilizzata dalla comunità Ethereum." lang: it sidebarDepth: 3 --- @@ -119,7 +119,7 @@ Alcuni team, tuttavia, stanno cercando di ottimizzare gli opcode EVM esistenti p ## Come fanno i validium a ridimensionare Ethereum? {#scaling-ethereum-with-validiums} -### 1. Archiviazione dei dati off-chain {#off-chain-data-storage} +### 1. Archiviazione dei dati off-chain {#offchain-data-storage} I progetti di ridimensionamento del livello 2, come i rollup ottimistici e a conoscenza zero, rinunciano all'infinita scalabilità dei protocolli di ridimensionamento off-chain puri (ad es. [Plasma](/developers/docs/scaling/plasma/)) in cambio della sicurezza, pubblicando alcuni dati di transazione su L1. Ma questo fa sì che le proprietà di scalabilità dei rollup sia limitata dalla larghezza di banda dei dati sulla Rete principale di Ethereum (lo [sharding dei dati](/roadmap/danksharding/) propone di migliorare la capacità di archiviazione dei dati di Ethereum per questo motivo). diff --git a/public/content/translations/it/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/it/developers/docs/scaling/zk-rollups/index.md index c80610d5c15..53e0a590cd4 100644 --- a/public/content/translations/it/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/it/developers/docs/scaling/zk-rollups/index.md @@ -30,7 +30,7 @@ L'architettura principale del rollup ZK si compone dei seguenti componenti: 2. **Macchina virtuale (VM) off-chain**: benché il protocollo del rollup ZK risieda su Ethereum, l'esecuzione della transazione e l'archiviazione di stato si verificano su una macchina virtuale separata e indipendente dall'[EVM](/developers/docs/evm/). Questa VM off-chain è l'ambiente di esecuzione per le transazioni sul rollup ZK e serve da livello secondario o "livello 2" per il protocollo rollup ZK. Le prove di validità verificate sulla Rete principale di Ethereum garantiscono la correttezza delle transizioni di stato nella VM off-chain. -I rollup ZK sono "soluzioni di ridimensionamento ibride": protocolli off-chain che operano indipendentemente ma derivano la sicurezza da Ethereum. Nello specifico, la rete di Ethereum impone la validità degli aggiornamenti di stato sul rollup ZK e garantisce la disponibilità dei dati dietro ogni aggiornamento allo stato del rollup. Di conseguenza, i rollup ZK sono considerevolmente più sicuri delle soluzioni di ridimensionamento off-chain, come le [sidechain](/developers/docs/scaling/sidechains/), responsabili delle proprie proprietà di sicurezza, o i [validium](/developers/docs/scaling/validiums/), che pur verificando le transazioni su Ethereum con le prove di validità, memorizzano altrove i dati della transazione. +I rollup ZK sono "soluzioni di ridimensionamento ibride": protocolli off-chain che operano indipendentemente ma derivano la sicurezza da Ethereum. Nello specifico, la rete di Ethereum impone la validità degli aggiornamenti di stato sul rollup ZK e garantisce la disponibilità dei dati dietro ogni aggiornamento allo stato del rollup. Di conseguenza, i rollup ZK sono considerevolmente più sicuri delle soluzioni di ridimensionamento off-chain, come le [sidechain](/developers/docs/scaling/sidechains/), responsabili delle proprie proprietà di sicurezza, o i [validium](/developers/docs/scaling/validium/), che pur verificando le transazioni su Ethereum con le prove di validità, memorizzano altrove i dati della transazione. I rollup ZK si affidano al protocollo principale di Ethereum per quanto segue: diff --git a/public/content/translations/it/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/it/developers/docs/smart-contracts/compiling/index.md index d811e9e935d..13c5b8fe609 100644 --- a/public/content/translations/it/developers/docs/smart-contracts/compiling/index.md +++ b/public/content/translations/it/developers/docs/smart-contracts/compiling/index.md @@ -1,6 +1,6 @@ --- title: Compilazione dei contratti intelligenti -description: Una spiegazione del perché devi compilare i contratti intelligenti e di cosa succede effettivamente durante la compilazione. +description: "Una spiegazione del perché devi compilare i contratti intelligenti e di cosa succede effettivamente durante la compilazione." lang: it incomplete: true --- diff --git a/public/content/translations/it/developers/docs/smart-contracts/composability/index.md b/public/content/translations/it/developers/docs/smart-contracts/composability/index.md index 794afad7d10..f3366c41acc 100644 --- a/public/content/translations/it/developers/docs/smart-contracts/composability/index.md +++ b/public/content/translations/it/developers/docs/smart-contracts/composability/index.md @@ -1,5 +1,5 @@ --- -title: Componibilità dei contratti intelligenti +title: "Componibilità dei contratti intelligenti" description: lang: it incomplete: true diff --git a/public/content/translations/it/developers/docs/smart-contracts/languages/index.md b/public/content/translations/it/developers/docs/smart-contracts/languages/index.md index 8783253b63f..3620feb806f 100644 --- a/public/content/translations/it/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/it/developers/docs/smart-contracts/languages/index.md @@ -123,24 +123,32 @@ Per ulteriori informazioni, [consulta la logica di Vyper](https://vyper.readthed # Apertura asta # Parametri d'asta + # Il beneficiario riceve denaro dal miglior offerente + beneficiary: public(address) auctionStart: public(uint256) auctionEnd: public(uint256) # Stato attuale dell'asta + highestBidder: public(address) highestBid: public(uint256) # Imposta a true alla fine per non permettere più modifiche + ended: public(bool) # Tiene traccia delle offerte rimborsate in modo da poter seguire il modello di prelievo + pendingReturns: public(HashMap[address, uint256]) # Crea una semplice asta con `_bidding_time` + # tempo di offerta in secondi per conto + # dell'indirizzo del beneficiario `_beneficiary`. + @external def __init__(_beneficiary: address, _bidding_time: uint256): self.beneficiary = _beneficiary @@ -148,9 +156,13 @@ def __init__(_beneficiary: address, _bidding_time: uint256): self.auctionEnd = self.auctionStart + _bidding_time # Offerta sull'asta con il valore inviato + # insieme a questa transazione. + # Il valore sarà rimborsato solo se l'asta + # non viene vinta. + @external @payable def bid(): @@ -165,9 +177,13 @@ def bid(): self.highestBid = msg.value # Preleva un'offerta precedentemente rimborsata. Il modello di prelievo è + # utilizzato qui per evitare un problema di sicurezza. Se i rimborsi venissero inviati direttamente + # come parte di bid(), un contratto di offerta malevolo potrebbe bloccarli + # e quindi bloccare le nuove offerte più alte in arrivo. + @external def withdraw(): pending_amount: uint256 = self.pendingReturns[msg.sender] @@ -175,7 +191,9 @@ def withdraw(): send(msg.sender, pending_amount) # Termina l'asta e invia l'offerta più alta + # al beneficiario. + @external def endAuction(): # It is a good guideline to structure functions that interact diff --git a/public/content/translations/it/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/it/developers/docs/smart-contracts/verifying/index.md index f46d2fbc5f8..bffe6042b3d 100644 --- a/public/content/translations/it/developers/docs/smart-contracts/verifying/index.md +++ b/public/content/translations/it/developers/docs/smart-contracts/verifying/index.md @@ -80,7 +80,7 @@ Etherscan è lo strumento più utilizzato per verificare i contratti. Tuttavia, [Maggiori informazioni sulla verifica dei contratti su Etherscan](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327). -### Sourcify {#sourcify} +### Sourcify {#blockscout} [Sourcify](https://sourcify.dev/#/verifier) è un altro strumento, open source e decentralizzato, per verificare i contratti. Non è un esploratore di blocchi e verifica i contratti soltanto su [diverse reti basate sull'EVM](https://docs.sourcify.dev/docs/chains). Agisce da infrastruttura pubblica per la costruzione di altri strumenti e mira a consentire interazioni con i contratti più intuitive, utilizzando i commenti [ABI](/developers/docs/smart-contracts/compiling/#web-applications) e [NatSpc](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) che si trovano nel file dei metadati. @@ -90,7 +90,7 @@ Inoltre, è anche possibile recuperare i file del codice sorgente via IPFS, poic [Maggiori informazioni sulla verifica dei contratti su Sourcify](https://blog.soliditylang.org/2020/06/25/sourcify-faq/). -### Tenderly {#tenderly} +### Tenderly {#sourcify} La [piattaforma Tenderly](https://tenderly.co/) consente agli sviluppatori in Web3 di creare, testare, monitorare e gestire i contratti intelligenti. Combinando strumenti di debug con osservabilità e blocchi di costruzione dell'infrastruttura, Tenderly aiuta gli sviluppatori ad accelerare lo sviluppo dei contratti intelligenti. Per abilitare appieno le funzionalità di Tenderly, gli sviluppatori devono [eseguire la verifica del codice sorgente](https://docs.tenderly.co/monitoring/contract-verification) utilizzando svariati metodi. @@ -102,6 +102,6 @@ Verificando i contratti tramite il Pannello di controllo, devi importare il file L'utilizzo del plugin Hardhat di Tenderly consente di avere maggiore controllo sul processo di verifica con minori sforzi, consentendoti di scegliere tra una verifica automatica (senza codice) e manuale (basata sul codice). -## Letture consigliate {#further-reading} +## Letture consigliate {#tenderly} - [Verificare il codice sorgente del contratto](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) diff --git a/public/content/translations/it/developers/docs/storage/index.md b/public/content/translations/it/developers/docs/storage/index.md index ef3bd169125..b67c1ceffaf 100644 --- a/public/content/translations/it/developers/docs/storage/index.md +++ b/public/content/translations/it/developers/docs/storage/index.md @@ -1,6 +1,6 @@ --- title: Archiviazione Decentralizzata -description: Panoramica di cos'è l'archiviazione decentralizzata e degli strumenti disponibili per integrarla in una dapp. +description: "Panoramica di cos'è l'archiviazione decentralizzata e degli strumenti disponibili per integrarla in una dapp." lang: it --- diff --git a/public/content/translations/it/developers/docs/transactions/index.md b/public/content/translations/it/developers/docs/transactions/index.md index 0a3ede82e33..f2d5d47562b 100644 --- a/public/content/translations/it/developers/docs/transactions/index.md +++ b/public/content/translations/it/developers/docs/transactions/index.md @@ -106,7 +106,7 @@ Con l'hash di firma, la transazione può provare crittograficamente che proviene ### Il campo di dati {#the-data-field} -La grande maggioranza delle transazioni accede a un contratto da un conto esterno. Gran parte dei contratti è scritta in Solidity e interpreta il proprio campo dei dati secondo l'[interfaccia binaria dell'applicazione (Application Binary Interface – ABI)](/glossary/#abi/). +La grande maggioranza delle transazioni accede a un contratto da un conto esterno. Gran parte dei contratti è scritta in Solidity e interpreta il proprio campo dei dati secondo l'[interfaccia binaria dell'applicazione (Application Binary Interface – ABI)](/glossary/#abi). I primi quattro byte specificano quale funzione chiamare, usando l'hash del nome e degli argomenti della funzione. Talvolta si può identificare la funzione dal selettore, usando [questo database](https://www.4byte.directory/signatures/). diff --git a/public/content/translations/it/developers/docs/wrapped-eth/index.md b/public/content/translations/it/developers/docs/wrapped-eth/index.md index f6633c6df9d..93a7afd5584 100644 --- a/public/content/translations/it/developers/docs/wrapped-eth/index.md +++ b/public/content/translations/it/developers/docs/wrapped-eth/index.md @@ -1,6 +1,6 @@ --- -title: Che cos'è il Wrapped Ether (WETH) -description: Un'introduzione al Wrapped ether (WETH)—un wrapper per ether (ETH) compatibile con ERC20. +title: "Che cos'è il Wrapped Ether (WETH)" +description: "Un'introduzione al Wrapped ether (WETH)—un wrapper per ether (ETH) compatibile con ERC20." lang: it --- @@ -35,19 +35,16 @@ Puoi "scartare" (ovvero unwrap) WETH per ETH utilizzando il contratto intelligen Devi pagare delle commissioni del gas per avvolgere o scartare ETH utilizzando il contratto WETH. - WETH è generalmente considerato sicuro perché si basa su un contratto intelligente semplice e testato sul campo. Anche il contratto WETH è stato formalmente verificato, che è lo standard di sicurezza più elevato per i contratti intelligenti su Ethereum. - Oltre all'[implementazione canonica di WETH](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) descritta in questa pagina, ci sono altre varianti in giro. Queste possono essere token personalizzati creati dagli sviluppatori di applicazioni o versioni emesse su altre blockchain, e potrebbero comportarsi diversamente o avere proprietà di sicurezza diverse. **Ricontrolla sempre le informazioni sui token per sapere con quale implementazione di WETH stai interagendo.** - @@ -55,7 +52,6 @@ Oltre all'[implementazione canonica di WETH](https://etherscan.io/token/0xc02aaa - [Rete Principale di Ethereum](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) - [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1) - [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006) - ## Letture consigliate {#further-reading} diff --git a/public/content/translations/it/developers/tutorials/all-you-can-cache/index.md b/public/content/translations/it/developers/tutorials/all-you-can-cache/index.md index 57c7b8c3940..f6ff02e95b8 100644 --- a/public/content/translations/it/developers/tutorials/all-you-can-cache/index.md +++ b/public/content/translations/it/developers/tutorials/all-you-can-cache/index.md @@ -1,6 +1,6 @@ --- title: "Salva nella cache quanto vuoi" -description: Scopri come creare e utilizzare un contratto di memorizzazione nella cache per transazioni rollup più economiche +description: "Scopri come creare e utilizzare un contratto di memorizzazione nella cache per transazioni rollup più economiche" author: Ori Pomerantz tags: - "livello 2" diff --git a/public/content/translations/it/developers/tutorials/erc-721-vyper-annotated-code/index.md b/public/content/translations/it/developers/tutorials/erc-721-vyper-annotated-code/index.md index 1aa4513316d..ae81072d902 100644 --- a/public/content/translations/it/developers/tutorials/erc-721-vyper-annotated-code/index.md +++ b/public/content/translations/it/developers/tutorials/erc-721-vyper-annotated-code/index.md @@ -244,6 +244,7 @@ Restituisce il valore dall'HashMap `self-supportedInterfaces`, che è impostata ```python ### VIEW FUNCTIONS ### + ``` Queste sono le funzioni di visualizzazione che rendono le informazioni sui token disponibili a utenti e altri contratti. diff --git a/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md index 77d28e8c2a6..685a839b550 100644 --- a/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md @@ -1,6 +1,6 @@ --- title: "Guida dettagliata al contratto ERC-20" -description: Cosa c'è nel contratto ERC-20 di OpenZeppelin e a cosa serve? +description: "Cosa c'è nel contratto ERC-20 di OpenZeppelin e a cosa serve?" author: Ori Pomerantz lang: it tags: diff --git a/public/content/translations/it/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md b/public/content/translations/it/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md index 4530e734b93..5a4ee39d1a3 100644 --- a/public/content/translations/it/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md +++ b/public/content/translations/it/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/index.md @@ -11,7 +11,7 @@ tags: skill: beginner lang: it published: 2020-10-30 -source: Medio +source: Medium sourceUrl: https://medium.com/alchemy-api/getting-started-with-ethereum-development-using-alchemy-c3d6a45c567f --- diff --git a/public/content/translations/it/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/it/developers/tutorials/guide-to-smart-contract-security-tools/index.md index cbc0ab8e3a8..91b5bb0c29e 100644 --- a/public/content/translations/it/developers/tutorials/guide-to-smart-contract-security-tools/index.md +++ b/public/content/translations/it/developers/tutorials/guide-to-smart-contract-security-tools/index.md @@ -9,7 +9,7 @@ tags: - "sicurezza" skill: intermediate published: 2020-09-07 -source: Creare contratti sicuri +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis --- diff --git a/public/content/translations/it/developers/tutorials/hello-world-smart-contract-fullstack/index.md b/public/content/translations/it/developers/tutorials/hello-world-smart-contract-fullstack/index.md index 0a417e53d75..9bc76177f55 100644 --- a/public/content/translations/it/developers/tutorials/hello-world-smart-contract-fullstack/index.md +++ b/public/content/translations/it/developers/tutorials/hello-world-smart-contract-fullstack/index.md @@ -628,8 +628,6 @@ ETHERSCAN_API_KEY = "your-etherscan-key" ### Contratti intelligenti distribuiti su Hardhat {#hardhat-deployed-smart-contracts} - - #### Installa hardhat-etherscan {#install-hardhat-etherscan} Pubblicare i tuoi contratti su Ethereum usando Hardhat è semplice. Per iniziare è necessario installare il plugin `hardhat-etherscan`. `hardhat-etherscan` verificherà automaticamente il codice sorgente e la ABI del contratto intelligente su Etherscan. Per aggiungerlo, esegui dalla cartella `hello-world`: @@ -903,8 +901,9 @@ return ( - - + + + ) ``` diff --git a/public/content/translations/it/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md b/public/content/translations/it/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md index cec6a7b6dab..0f10e0f3195 100644 --- a/public/content/translations/it/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md +++ b/public/content/translations/it/developers/tutorials/how-to-mock-solidity-contracts-for-testing/index.md @@ -1,6 +1,6 @@ --- title: Come simulare i contratti intelligenti in Solidity per testarli -description: Perché è importante prendersi gioco dei propri contratti in fase di test +description: "Perché è importante prendersi gioco dei propri contratti in fase di test" author: Markus Waas lang: it tags: diff --git a/public/content/translations/it/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md b/public/content/translations/it/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md index bc374533d9a..91f6087b864 100644 --- a/public/content/translations/it/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md +++ b/public/content/translations/it/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md @@ -11,7 +11,7 @@ tags: - "fuzzing" skill: advanced published: 2020-04-10 -source: Creare contratti sicuri +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna --- diff --git a/public/content/translations/it/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md b/public/content/translations/it/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md index 7d97bd4a966..88e70637953 100644 --- a/public/content/translations/it/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md +++ b/public/content/translations/it/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/index.md @@ -11,7 +11,7 @@ tags: - "verifica formale" skill: advanced published: 2020-01-13 -source: Creare contratti sicuri +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore --- @@ -396,6 +396,7 @@ symbolic_var = m.make_symbolic_value() contract_account.f(symbolic_var) ## Controlla se l'esecuzione termina con REVERT o INVALID + for state in m.terminated_states: last_tx = state.platform.transactions[-1] if last_tx.result in ['REVERT', 'INVALID']: @@ -500,6 +501,7 @@ contract_account.f(symbolic_var) no_bug_found = True ## Controlla se l'esecuzione termina con REVERT o INVALID + for state in m.terminated_states: last_tx = state.platform.transactions[-1] if last_tx.result in ['REVERT', 'INVALID']: diff --git a/public/content/translations/it/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md b/public/content/translations/it/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md index 28111da448b..f4487b0edde 100644 --- a/public/content/translations/it/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md +++ b/public/content/translations/it/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/index.md @@ -11,7 +11,7 @@ tags: - "analisi statica" skill: advanced published: 2020-06-09 -source: Creare contratti sicuri +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither --- diff --git a/public/content/translations/it/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/it/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md index 8a4d38bb867..c442b02686e 100644 --- a/public/content/translations/it/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md +++ b/public/content/translations/it/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md @@ -9,7 +9,7 @@ tags: - "oracoli" skill: beginner published: 2021-06-29 -source: Documentazione di Tellor +source: Tellor Docs sourceUrl: https://docs.tellor.io/tellor/ --- diff --git a/public/content/translations/it/developers/tutorials/how-to-write-and-deploy-an-nft/index.md b/public/content/translations/it/developers/tutorials/how-to-write-and-deploy-an-nft/index.md index c7995522e44..b0b68e38c75 100644 --- a/public/content/translations/it/developers/tutorials/how-to-write-and-deploy-an-nft/index.md +++ b/public/content/translations/it/developers/tutorials/how-to-write-and-deploy-an-nft/index.md @@ -1,6 +1,6 @@ --- title: Come Scrivere e Distribuire un NFT (Parte 1/3 della Serie di tutorial sugli NFT) -description: Questo tutorial è la Parte 1 di una serie sui NFT che ti guiderà passo dopo passo alla scrittura e distribuzione del contratto intelligente di un Token Non Fungibile (token ERC-721) usando Ethereum e l'InterPlanetary File System (IPFS). +description: "Questo tutorial è la Parte 1 di una serie sui NFT che ti guiderà passo dopo passo alla scrittura e distribuzione del contratto intelligente di un Token Non Fungibile (token ERC-721) usando Ethereum e l'InterPlanetary File System (IPFS)." author: "Sumi Mudgil" tags: - "ERC-721" diff --git a/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md b/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md index 8d093e6360e..20ef58025ce 100644 --- a/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md +++ b/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/index.md @@ -1,6 +1,6 @@ --- title: Avvia lo sviluppo del frontend della tua dapp con create-eth-app -description: Una panoramica su come usare create-eth-app e le sue funzionalità +description: "Una panoramica su come usare create-eth-app e le sue funzionalità" author: "Markus Waas" tags: - "create-eth-app" diff --git a/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md b/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md index 8d093e6360e..20ef58025ce 100644 --- a/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md +++ b/public/content/translations/it/developers/tutorials/kickstart-your-dapp-frontend-development-wth-create-eth-app/index.md @@ -1,6 +1,6 @@ --- title: Avvia lo sviluppo del frontend della tua dapp con create-eth-app -description: Una panoramica su come usare create-eth-app e le sue funzionalità +description: "Una panoramica su come usare create-eth-app e le sue funzionalità" author: "Markus Waas" tags: - "create-eth-app" diff --git a/public/content/translations/it/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md b/public/content/translations/it/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md index eb020f647c1..ac53cd738cf 100644 --- a/public/content/translations/it/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md +++ b/public/content/translations/it/developers/tutorials/merkle-proofs-for-offline-data-integrity/index.md @@ -1,6 +1,6 @@ --- -title: Prove di Merkle per l'integrità dei dati offline -description: Garantire l'integrità dei dati sulla catena per i dati memorizzati principalmente al di fuori di essa +title: "Prove di Merkle per l'integrità dei dati offline" +description: "Garantire l'integrità dei dati sulla catena per i dati memorizzati principalmente al di fuori di essa" author: Ori Pomerantz tags: - "archiviazione" @@ -33,7 +33,7 @@ L'hash principale è l'unica parte che deve essere memorizzata sulla catena. Per [Il campione di codice è disponibile qui](https://github.com/qbzzt/merkle-proofs-for-offline-data-integrity). -### Codice esterno alla catena {#off-chain-code} +### Codice esterno alla catena {#offchain-code} In questo articolo usiamo JavaScript per i calcoli al di fuori della catena. Gran parte delle app decentralizzate hanno i propri componenti esterni alla catena su JavaScript. @@ -163,7 +163,7 @@ Eseguiamo l'hashing di `(v[0],v[1])`, `(v[2],v[3])`, ecc. Quindi per i valori pa }   // getMerkleProof ``` -### Codice on-chain {#on-chain-code} +### Codice on-chain {#onchain-code} Finalmente abbiamo il codice che verifica la prova. Il codice on-chain è scritto in [Solidity](https://docs.soliditylang.org/en/v0.8.11/). L'ottimizzazione è molto più importante qui, perché il gas è relativamente costoso. diff --git a/public/content/translations/it/developers/tutorials/nft-minter/index.md b/public/content/translations/it/developers/tutorials/nft-minter/index.md index 5029f29175f..6f777a22037 100644 --- a/public/content/translations/it/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/it/developers/tutorials/nft-minter/index.md @@ -183,7 +183,7 @@ return ( Mint NFT

    {status}

    - + ) ``` diff --git a/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md index 623a368b33e..20ffd103981 100644 --- a/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -1,6 +1,6 @@ --- title: "Guida del ponte standard di Optimism per contratti" -description: Come funziona il ponte standard per Optimism? Perché funziona così? +description: "Come funziona il ponte standard per Optimism? Perché funziona così?" author: Ori Pomerantz tags: - "solidity" diff --git a/public/content/translations/it/developers/tutorials/run-node-raspberry-pi/index.md b/public/content/translations/it/developers/tutorials/run-node-raspberry-pi/index.md index 0b7f03a7701..a5d4e6b6795 100644 --- a/public/content/translations/it/developers/tutorials/run-node-raspberry-pi/index.md +++ b/public/content/translations/it/developers/tutorials/run-node-raspberry-pi/index.md @@ -10,7 +10,7 @@ tags: lang: it skill: intermediate published: 2022-06-10 -source: Ethereum su ARM +source: Ethereum on ARM sourceUrl: https://ethereum-on-arm-documentation.readthedocs.io/en/latest/ --- diff --git a/public/content/translations/it/developers/tutorials/secure-development-workflow/index.md b/public/content/translations/it/developers/tutorials/secure-development-workflow/index.md index 124522bb671..4d961ea14a3 100644 --- a/public/content/translations/it/developers/tutorials/secure-development-workflow/index.md +++ b/public/content/translations/it/developers/tutorials/secure-development-workflow/index.md @@ -9,7 +9,7 @@ tags: skill: intermediate lang: it published: 2020-09-07 -source: Creare contratti sicuri +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/workflow.md --- diff --git a/public/content/translations/it/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md b/public/content/translations/it/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md index ac548d8aaa8..4db85d9821c 100644 --- a/public/content/translations/it/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md +++ b/public/content/translations/it/developers/tutorials/sending-transactions-using-web3-and-alchemy/index.md @@ -9,7 +9,7 @@ tags: skill: beginner lang: it published: 2020-11-04 -source: documentazione Alchemy +source: Alchemy docs sourceUrl: https://www.alchemy.com/docs/how-to-send-transactions-on-ethereum --- diff --git a/public/content/translations/it/developers/tutorials/short-abi/index.md b/public/content/translations/it/developers/tutorials/short-abi/index.md index 15b2ff853f5..0ebe8f089b4 100644 --- a/public/content/translations/it/developers/tutorials/short-abi/index.md +++ b/public/content/translations/it/developers/tutorials/short-abi/index.md @@ -327,7 +327,7 @@ Crea una transazione di trasferimento. Il primo byte è "0x02", seguito dall'ind }) // describe ``` -### Esempio {#example} +### Esempio {#reducing-the-cost-when-you-do-control-the-destination-contract} Se desideri vedere questi file in azione senza eseguirli tu stesso, segui questi link: @@ -337,13 +337,13 @@ Se desideri vedere questi file in azione senza eseguirli tu stesso, segui questi 4. [Chiamata a `OrisUselessToken.approve()`](https://kovan-optimistic.etherscan.io/tx/1410747). Questa chiamata deve andare direttamente al contratto del token, poiché l'elaborazione si affida al `msg.sender`. 5. [Chiamata a `transfer()`](https://kovan-optimistic.etherscan.io/tx/1410748). -## Ridurre il costo quando hai il controllo del contratto di destinazione {#reducing-the-cost-when-you-do-control-the-destination-contract} +## Ridurre il costo quando hai il controllo del contratto di destinazione {#token-sol-2} Se hai il controllo sul contratto di destinazione, puoi creare funzioni che bypassano i controlli `msg.sender` poiché si fidano dell'interprete dei calldata. [Puoi vedere un esempio di come funziona qui, nel ramo `control-contract`](https://github.com/qbzzt/ethereum.org-20220330-shortABI/tree/control-contract). Se il contratto rispondesse solo alle transazioni esterne, potremmo riuscirsi con un solo contratto. Tuttavia, questo spezzerebbe la [componibilità](/developers/docs/smart-contracts/composability/). È molto meglio avere un contratto che risponda alle normali chiamate ERC-20 e un altro che risponda alle transazioni con dati della chiamata brevi. -### Token.sol {#token-sol-2} +### Token.sol {#calldatainterpreter-sol-2} In questo esempio, possiamo modificare `Token.sol`. Questo ci permette di avere un numero di funzioni che solo il proxy può chiamare. Ecco le nuove parti: @@ -441,7 +441,7 @@ Queste sono tre operazioni che normalmente richiedono che il messaggio provenga 1. È modificata da `onlyProxy()`, così che nessun altro possa controllarla. 2. Ottiene l'indirizzo che sarebbe normalmente `msg.sender` come un parametro aggiuntivo. -### CalldataInterpreter.sol {#calldatainterpreter-sol-2} +### CalldataInterpreter.sol {#test-js-2} L'interprete dei dati della chiamata è praticamente identico a quello precedente, tranne che le funzioni in proxy ricevono un parametro `msg.sender` e non è necessaria un'indennità per `transfer`. @@ -475,7 +475,7 @@ L'interprete dei dati della chiamata è praticamente identico a quello precedent } ``` -### Test.js {#test-js-2} +### Test.js {#conclusion} Ci sono alcune modifiche tra il codice di test precedente e questo. diff --git a/public/content/translations/it/developers/tutorials/smart-contract-security-guidelines/index.md b/public/content/translations/it/developers/tutorials/smart-contract-security-guidelines/index.md index d58a2b840ee..72c04d2ac1e 100644 --- a/public/content/translations/it/developers/tutorials/smart-contract-security-guidelines/index.md +++ b/public/content/translations/it/developers/tutorials/smart-contract-security-guidelines/index.md @@ -9,7 +9,7 @@ tags: skill: intermediate lang: it published: 2020-09-06 -source: Creare contratti sicuri +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md --- @@ -27,7 +27,7 @@ La documentazione può essere scritta su diversi livelli e deve essere aggiornat - **Schema e diagrammi architettonici**, incluse le interazioni del contratto e la macchina a stati del sistema. Le [stampanti Slither](https://github.com/crytic/slither/wiki/Printer-documentation) possono aiutare a generare questi schemi. - **Documentazione approfondita sul codice**, il [formato Natspec](https://solidity.readthedocs.io/en/develop/natspec-format.html) si può usare per Solidity. -### Calcolo sulla catena ed esterno alla catena {#on-chain-vs-off-chain-computation} +### Calcolo sulla catena ed esterno alla catena {#onchain-vs-offchain-computation} - **Mantieni quanto più codice possibile al di fuori della catena.** Il livello sulla catena deve essere il più ridotto possibile. Elabora anticipatamente i dati con il codice esternamente alla catena così che la verifica su di essa sia semplice. Ti serve un elenco ordinato? Ordina l'elenco esternamente alla catena, poi controlla solo l'ordine sulla catena. diff --git a/public/content/translations/it/developers/tutorials/the-graph-fixing-web3-data-querying/index.md b/public/content/translations/it/developers/tutorials/the-graph-fixing-web3-data-querying/index.md index 1adc5485c36..74a030740b1 100644 --- a/public/content/translations/it/developers/tutorials/the-graph-fixing-web3-data-querying/index.md +++ b/public/content/translations/it/developers/tutorials/the-graph-fixing-web3-data-querying/index.md @@ -1,6 +1,6 @@ --- title: "The Graph: query di dati in Web3" -description: La blockchain è come un database ma senza SQL. Contiene tutti i dati, ma non c'è modo di accedervi. Vediamo come risolvere la situazione con The Graph e GraphQL. +description: "La blockchain è come un database ma senza SQL. Contiene tutti i dati, ma non c'è modo di accedervi. Vediamo come risolvere la situazione con The Graph e GraphQL." author: Markus Waas lang: it tags: diff --git a/public/content/translations/it/developers/tutorials/token-integration-checklist/index.md b/public/content/translations/it/developers/tutorials/token-integration-checklist/index.md index 50630419398..d6579c04b63 100644 --- a/public/content/translations/it/developers/tutorials/token-integration-checklist/index.md +++ b/public/content/translations/it/developers/tutorials/token-integration-checklist/index.md @@ -10,7 +10,7 @@ tags: - "token" skill: intermediate published: 2020-08-13 -source: Creare contratti sicuri +source: Building secure contracts sourceUrl: https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/token_integration.md --- diff --git a/public/content/translations/it/developers/tutorials/uniswap-v2-annotated-code/index.md b/public/content/translations/it/developers/tutorials/uniswap-v2-annotated-code/index.md index 23ed18a2053..82e24f12a55 100644 --- a/public/content/translations/it/developers/tutorials/uniswap-v2-annotated-code/index.md +++ b/public/content/translations/it/developers/tutorials/uniswap-v2-annotated-code/index.md @@ -1,6 +1,6 @@ --- title: "Guida dettagliata al contratto Uniswap-v2" -description: Come funziona il contratto Uniswap-v2? Perché è scritto così? +description: "Come funziona il contratto Uniswap-v2? Perché è scritto così?" author: Ori Pomerantz tags: - "solidity" @@ -55,9 +55,8 @@ Questo è il flusso più comune, usato dai trader: 3. Identifica l'importo necessario da scambiare su ogni scambio lungo il percorso. 4. Itera sul percorso. Per ogni scambio lungo il percorso, invia il token di input e poi chiama la funzione di `swap` dello scambio. In gran parte dei casi, l'indirizzo di destinazione per i token è lo scambio in pari successivo nel percorso. Nello scambio finale è presente l'indirizzo fornito dal trader. -#### Nel contratto principale (UniswapV2Pair.sol) {#in-the-core-contract-uniswapv2pairsol-2} +#### Nel contratto principale (UniswapV2Pair.sol) {#in-the-core-contract-uniswapv2pairsol-2}5. Verifica che il contratto principale non raggiri il sistema e possa mantenere liquidità sufficiente dopo lo scambio. -5. Verifica che il contratto principale non raggiri il sistema e possa mantenere liquidità sufficiente dopo lo scambio. 6. Vede quanti token aggiuntivi abbiamo, in aggiunta alle riserve note. Quell'importo è il numero di token di input ricevuti da scambiare. 7. Invia i token d'output alla destinazione. 8. Chiama `_update` per aggiornare gli importi della riserva @@ -743,7 +742,7 @@ Questa è la funzione principale della factory, per creare uno scambio in pari t (address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA); ``` -Vogliamo che l'indirizzo del nuovo scambio sia deterministico, quindi calcolabile in anticipo al di fuori della catena (questo può essere utile per le [transazioni di livello 2](/developers/docs/layer-2-scaling/)). Per farlo, dobbiamo avere un ordine coerente degli indirizzi del token, indipendentemente dall'ordine in cui li abbiamo ricevuti, quindi li ordiniamo qui. +Vogliamo che l'indirizzo del nuovo scambio sia deterministico, quindi calcolabile in anticipo al di fuori della catena (questo può essere utile per le [transazioni di livello 2](/developers/docs/scaling/)). Per farlo, dobbiamo avere un ordine coerente degli indirizzi del token, indipendentemente dall'ordine in cui li abbiamo ricevuti, quindi li ordiniamo qui. ```solidity require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS'); diff --git a/public/content/translations/it/developers/tutorials/using-websockets/index.md b/public/content/translations/it/developers/tutorials/using-websockets/index.md index 892853e0405..f96fc83dfca 100644 --- a/public/content/translations/it/developers/tutorials/using-websockets/index.md +++ b/public/content/translations/it/developers/tutorials/using-websockets/index.md @@ -9,8 +9,8 @@ tags: - "query" - "javascript" skill: beginner -source: documentazione Alchemy -sourceUrl: https://docs.alchemyapi.io/guides/using-websockets +source: Alchemy docs +sourceUrl: https://www.alchemy.com/docs/reference/best-practices-for-using-websockets-in-web3 published: 2020-12-01 --- diff --git a/public/content/translations/it/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md b/public/content/translations/it/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md index bec9d55112b..676f647e349 100644 --- a/public/content/translations/it/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md +++ b/public/content/translations/it/developers/tutorials/waffle-dynamic-mocking-and-testing-calls/index.md @@ -295,4 +295,4 @@ Il codice sorgente di questo tutorial si può trovare [qui](https://github.com/E Altri tutorial che potrebbero interessarti: -- [Test di Smart Contract con Waffle](/developers/tutorials/testing-smart-contract-with-waffle/) +- [Test di Smart Contract con Waffle](/developers/tutorials/waffle-test-simple-smart-contract/) diff --git a/public/content/translations/it/developers/tutorials/waffle-test-simple-smart-contract/index.md b/public/content/translations/it/developers/tutorials/waffle-test-simple-smart-contract/index.md index d440693878a..6b30dec8150 100644 --- a/public/content/translations/it/developers/tutorials/waffle-test-simple-smart-contract/index.md +++ b/public/content/translations/it/developers/tutorials/waffle-test-simple-smart-contract/index.md @@ -30,7 +30,6 @@ published: 2021-02-26 Il tutorial dimostra la configurazione di prova e opera utilizzando yarn, ma non ci sono problemi se preferisci npm: fornirò gli adeguati riferimenti alla [documentazione](https://ethereum-waffle.readthedocs.io/en/latest/index.html) ufficiale di Waffle. ### Installa dipendenze {#install-dependencies} - [Aggiungi](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#installation) ethereum-waffle e le dipendenze di TypeScript alle dipendenze di sviluppo del tuo progetto. ```bash @@ -38,7 +37,6 @@ yarn add --dev ethereum-waffle ts-node typescript @types/jest ``` ### Esempio di contratto intelligente {#example-smart-contract} - Durante il tutorial lavoreremo a un esempio di contratto intelligente semplice: EtherSplitter. Non fa molto, tranne che consentire a chiunque di inviare wei e dividerli uniformemente tra due destinatari predefiniti. La funzione di divisione richiede che il numero di wei sia pari, altrimenti si ripristinerà. Per entrambi i destinatari esegue un trasferimento di wei, seguito dall'emissione dell'evento Trasferimento. Posiziona il frammento del codice di EtherSplitter in `src/EtherSplitter.sol`. @@ -68,7 +66,6 @@ contract EtherSplitter { ``` ### Compila il contratto {#compile-the-contract} - Per [compilare](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#compiling-the-contract) il contratto, aggiungi il seguente elemento al file package.json: ```json @@ -91,7 +88,6 @@ Poi, crea un file di configurazione di Waffle nella cartella di root del progett Esegui `yarn build`. Di conseguenza, la cartella `build` apparirà con il contratto compilato di EtherSplitter nel formato JSON. ### Testare la configurazione {#test-setup} - Testare con Waffle richiede l'utilizzo di abbinatori Chai e Mocha, quindi, devi [aggiungerli](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests) al tuo progetto. Aggiorna il tuo file package.json e aggiungi l'elemento `test` nella parte degli script: ```json @@ -135,7 +131,6 @@ Solo due parole prima di iniziare. `MockProvider` offre una versione fittizia de Quindi, dichiariamo una variabile detta "splitter" (divisore), che è il nostro contratto fittizio EtherSplitter. È creato prima di ogni esecuzione di un singolo test dal metodo `deployContract`. Questo metodo simula la distribuzione di un contratto dal portafoglio passato come primo parametro (nel nostro caso, il portafoglio del mittente). Il secondo parametro è l'ABI e il bytecode del contratto testato; qui, passiamo il file json del contratto compilato EtherSplitter dalla cartella `build`. Il terzo parametro è un insieme con gli argomenti del costruttore del contratto che, nel nostro caso, sono gli indirizzi dei due destinatari. ### changeBalances {#changebalances} - Prima controlleremo se il metodo di divisione modifica effettivamente i saldi dei portafogli dei destinatari. Se dividiamo 50 wei dall'account del mittente, i saldi di entrambi i destinatari dovrebbero aumentare di 25 wei. Utilizzeremo l'abbinatore di Waffle "`changeBalances`: ```ts @@ -163,7 +158,6 @@ Nota che in entrambi i casi di `changeBalance` e `changeBalances`, passiamo la f Poi, testeremo se l'evento Trasferimento è stato emesso dopo ogni trasferimento di wei. Ci rivolgeremo a un altro abbinatore da Waffle: ### Emetti {#emit} - ```ts it("Emits event on the transfer to the first receiver", async () => { await expect(splitter.split({ value: 50 })) @@ -181,7 +175,6 @@ it("Emits event on the transfer to the second receiver", async () => { L'abbinatore `emit` ci consente di verificare se un contratto ha emesso un evento alla chiamata di un metodo. Come parametri all'abbinatore `emit`, forniamo il contratto fittizio che prevediamo emetterà l'evento, insieme al nome di tale evento. Nel nostro caso, il contratto fittizio è `splitter` e il nome dell'evento è `Trasferimento`. Inoltre, possiamo verificare i valori precisi degli argomenti con cui è stato emesso l'evento; passiamo altrettanti argomenti all'abbinatore `withArgs`, come previsto dalla dichiarazione del nostro evento. Nel caso del contratto EtherSplitter, passiamo gli indirizzi del mittente e del destinatario insieme all'importo trasferito di wei. ### revertedWith {#revertedwith} - Come ultimo esempio verificheremo se la transazione è stata ripristinata, nel caso di un numero dispari di wei. Utilizzeremo l'abbinatore `revertedWith`: ```ts diff --git a/public/content/translations/it/ethereum-forks/index.md b/public/content/translations/it/ethereum-forks/index.md index d5f6252e37c..b3a41fd3001 100644 --- a/public/content/translations/it/ethereum-forks/index.md +++ b/public/content/translations/it/ethereum-forks/index.md @@ -16,7 +16,6 @@ Le diramazioni si verificano quando è necessario apportare importanti aggiornam Quando sono necessari aggiornamenti in software tradizionali controllati centralmente, l'azienda pubblica una nuova versione per l'utente finale. Le blockchain funzionano diversamente perché non esiste una proprietà centrale. I [client di Ethereum](/developers/docs/nodes-and-clients/) devono aggiornare il proprio software e implementare le regole della nuova diramazione. Inoltre i creatori dei blocchi (miner in contesto Proof of Work e validatori in contesto Proof of Stake) e i nodi devono creare blocchi e convalidarli in base alle nuove regole. [Maggiori informazioni sui meccanismi di consenso](/developers/docs/consensus-mechanisms/) Queste modifiche alle regole potrebbero creare una divisione temporanea nella rete. I nuovi blocchi potrebbero essere creati in base alle nuove regole o a quelle vecchie. Le diramazioni di solito sono concordate in anticipo in modo che i client adottino le modifiche all'unisono e la diramazione legata agli upgrade diventi la catena principale. Tuttavia, in rari casi, disaccordi sulle diramazioni possono causare una divisione permanente della rete, come è successo con la creazione di Ethereum Classic con la diramazione DAO. -     @@ -59,7 +58,6 @@ Gli aggiornamenti dei livelli di esecuzione e di consenso erano inizialmente dis | ----------------- | ----------------- | ---------- | | Shanghai | Capella | "Shapella" | | Cancun | Deneb | "Dencun" | - Salta direttamente alle informazioni su alcuni degli ultimi aggiornamenti particolarmente importanti: [La Beacon Chain](/roadmap/beacon-chain/); [La Fusione](/roadmap/merge/) ed [EIP-1559](#london) @@ -68,13 +66,13 @@ Stai cercando i prossimi aggiornamenti di protocollo? [Scopri di più sui prossi -## 2024 {#2024} +## 2024 {#2025} -### Cancun-Deneb ("Dencun") {#dencun} +### Cancun-Deneb ("Dencun") {#fusaka} -#### Riepilogo di Cancun {#cancun-summary} +#### Riepilogo di Cancun {#pectra} L'aggiornamento di Cancun contiene una serie di miglioramenti all'_esecuzione_ di Ethereum, mirati a migliorarne la scalabilità, in tandem con gli aggiornamenti al consenso di Deneb. @@ -90,7 +88,6 @@ Notevolmente, include l'EIP-4844, nota come **Proto-Danksharding**, che riduce s
  • EIP-6780: SELFDESTRUCT soltanto nella stessa transazione
  • EIP-7516: Codice operativo BLOBBASEFEE
    • -     - [Rollup del Livello 2](/layer-2/) @@ -98,7 +95,7 @@ Notevolmente, include l'EIP-4844, nota come **Proto-Danksharding**, che riduce s - [Danksharding](/roadmap/danksharding/) - [Leggi le specifiche dell'aggiornamento di Cancun](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md) -#### Riepilogo di Deneb {#deneb-summary} +#### Riepilogo di Deneb {#2024} L'aggiornamento di Deneb contiene una serie di miglioramenti al _consenso_ di Ethereum, mirati a migliorarne la scalabilità. Questo aggiornamento è in tandem con gli aggiornamenti del livello di esecuzione Cancun per consentire il Proto-Danksharding (EIP-4844), insieme ad altri miglioramenti alla Beacon Chain. @@ -115,7 +112,6 @@ EIP-7514 comporta un rafforzamento dell'emissione di ETH, limitando il tasso di
  • EIP-7045: Aumento degli slot massimi di inclusione dell'attestazione
  • EIP-7514: Aggiunta del limite massimo di churn per epoca
    • -     - [Leggi le specifiche dell'aggiornamento di Deneb](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/) @@ -123,13 +119,13 @@ EIP-7514 comporta un rafforzamento dell'emissione di ETH, limitando il tasso di -## 2023 {#2023} +## 2023 {#dencun} -### Shanghai-Capella ("Shapella") {#shapella} +### Shanghai-Capella ("Shapella") {#cancun-summary} -#### Riepilogo di Shanghai {#shanghai-summary} +#### Riepilogo di Shanghai {#deneb-summary} L'aggiornamento di Shanghai ha portato i prelievi di staking al livello d'esecuzione. Insieme all'aggiornamento Capella, questo abiliterà i blocchi ad accettare le operazioni di prelievo, che consentono agli staker di prelevare i propri ETH dalla Beacon Chain al livello d'esecuzione. @@ -142,12 +138,11 @@ L'aggiornamento di Shanghai ha portato i prelievi di staking al livello d'esecuz
  • EIP-4895 – La Beacon Chain lancia i prelievi come operazioni
  • EIP-6049 - Depreca SELFDESTRUCT
    • - - [Leggi le specifiche dell'aggiornamento Shanghai](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) -#### Riepilogo di Capella {#capella-summary} +#### Riepilogo di Capella {#2023} L'aggiornamento di Capella è il terzo aggiornamento principale al livello del consenso (Beacon Chain) e ha abilitato i prelievi di staking. Capella è avvenuto contemporaneamente all'aggiornamento del livello di esecuzione di Shanghai, e ha reso disponibili le funzioni di prelievo da staking. @@ -160,13 +155,13 @@ L'aggiornamento, inoltre, ha fornito la funzionalità di pulizia automatica dei -## 2022 {#2022} +## 2022 {#shapella} -### Paris (la Fusione) {#paris} +### Paris (la Fusione) {#shanghai-summary} -#### Riepilogo {#paris-summary} +#### Riepilogo {#capella-summary} L'aggiornamento Paris è stato attivato dal passaggio da una blockchain proof-of-work di una [difficoltà totale terminale](/glossary/#terminal-total-difficulty) di 58750000000000000000000. Questo è avvenuto al blocco 15537393 il 15 settembre 2022, innescando l'aggiornamento Paris dal blocco successivo. Paris è stata la transizione [alla Fusione](/roadmap/merge/): la sua caratteristica principale è lo spegnimento dell'algoritmo di mining [proof-of-work](/developers/docs/consensus-mechanisms/pow) e della relativa logica di consenso, e l'attivazione della [proof-of-stake](/developers/docs/consensus-mechanisms/pos). Paris è stata un aggiornamento ai [client di esecuzione](/developers/docs/nodes-and-clients/#execution-clients) (equivalente a Bellatrix a livello di consenso) che ha permesso loro di ricevere istruzioni dai loro [client di consenso](/developers/docs/nodes-and-clients/#consensus-clients) collegati. Questo ha richiesto l'attivazione di una nuova serie di metodi API interni, collettivamente noti come l'[API Engine](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md). Questo è stato probabilmente l'aggiornamento più significativo nella storia di Ethereum dopo [Homestead](#homestead)! @@ -178,16 +173,15 @@ L'aggiornamento Paris è stato attivato dal passaggio da una blockchain proof-of
  • EIP-3675 – Aggiorna il consenso al Proof-of-Stake
  • EIP-4399 – Sostituisce l'opcode DIFFICULTY con PREVRANDAO
    • - --- -### Bellatrix {#bellatrix} +### Bellatrix {#2022} -#### Riepilogo {#bellatrix-summary} +#### Riepilogo {#paris} L'aggiornamento Bellatrix è stato il secondo aggiornamento programmato per la [Beacon Chain](/roadmap/beacon-chain), preparando la catena per [la Fusione](/roadmap/merge/). Porta le penalità dei validatori al valore pieno per inattività e azioni sanzionabili (slashing). Bellatrix include anche un aggiornamento alle regole di scelta della diramazione per preparare la catena per la Fusione e la transizione dall'ultimo blocco di proof-of-work al primo blocco proof-of-stake. A tale scopo occorre far sì che i client di consenso siano consapevoli della [difficoltà terminale totale](/glossary/#terminal-total-difficulty) di 58750000000000000000000. @@ -195,11 +189,11 @@ L'aggiornamento Bellatrix è stato il secondo aggiornamento programmato per la [ --- -### Gray Glacier {#gray-glacier} +### Gray Glacier {#paris-summary} -#### Riepilogo {#gray-glacier-summary} +#### Riepilogo {#bellatrix} L'aggiornamento della rete di Gray Glacier ha rimandato di tre mesi la [bomba di difficoltà](/glossary/#difficulty-bomb). Questa è l'unica modifica introdotta in questo aggiornamento ed è simile per natura agli aggiornamenti di [Arrow Glacier](#arrow-glacier) e [Muir Glacier](#muir-glacier). Modifiche simili sono state effettuate sugli aggiornamenti di rete [Byzantium](#byzantium), [Constantinople](#constantinople) e [London](#london). @@ -210,18 +204,17 @@ L'aggiornamento della rete di Gray Glacier ha rimandato di tre mesi la [bomba di
    • EIP-5133 – ritarda la bomba di difficoltà fino a settembre 2022
    - -## 2021 {#2021} +## 2021 {#bellatrix-summary} -### Arrow Glacier {#arrow-glacier} +### Arrow Glacier {#gray-glacier} -#### Riepilogo {#arrow-glacier-summary} +#### Riepilogo {#gray-glacier-summary} L'aggiornamento di rete Arrow Glacier ha rimandato la [bomba di difficoltà](/glossary/#difficulty-bomb) di diversi mesi. Questo è l'unico cambiamento introdotto in questo aggiornamento, ed è simile nella sostanza all'aggiornamento [Muir Glacier](#muir-glacier). Modifiche simili sono state effettuate sugli aggiornamenti di rete [Byzantium](#byzantium), [Constantinople](#constantinople) e [London](#london). @@ -233,22 +226,21 @@ L'aggiornamento di rete Arrow Glacier ha rimandato la [bomba di difficoltà](/gl
    • EIP-4345 – ritarda la bomba di difficoltà fino a giugno 2022
    - --- -### Altair {#altair} +### Altair {#2021} -#### Riepilogo {#altair-summary} +#### Riepilogo {#arrow-glacier} L'aggiornamento Altair è stato il primo aggiornamento pianificato per la [Beacon Chain](/roadmap/beacon-chain). Ha aggiunto il supporto per le "commissioni di sincronizzazione", abilitando i "client leggeri", aumentando le penalità per inattività e slashing per i validatori man mano che lo sviluppo procedeva verso la Fusione. - [Leggi le specifiche dell'aggiornamento di Altair](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair) -#### Curiosità! {#altair-fun-fact} +#### Curiosità! {#arrow-glacier-summary} Altair è stato il primo importante aggiornamento di rete che ha avuto un tempo di rollout esatto. Tutti gli aggiornamenti precedenti erano basati su un numero di blocco dichiarato su una catena proof-of-work, dove i tempi del blocco variavano. La Beacon Chain non richiede la risoluzione del proof-of-work e funziona invece su un sistema di epoche basato sul tempo che consiste in 32 "slot" di dodici secondi in cui i validatori possono proporre dei blocchi. Questo è il motivo per cui sapevamo esattamente quando avremmo raggiunto l'epoca 74.240 e Altair sarebbe diventato operativo! @@ -256,15 +248,15 @@ Altair è stato il primo importante aggiornamento di rete che ha avuto un tempo --- -### London {#london} +### London {#altair} -#### Riepilogo {#london-summary} +#### Riepilogo {#altair-summary} L'aggiornamento London ha introdotto l'[EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), che ha riformato il mercato delle commissioni sulle transazioni, oltre a modificare come sono gestiti i rimborsi di carburante e la pianificazione di [Ice Age](/glossary/#ice-age). -#### Cos'è l'Aggiornamento di Londra / EIP-1559? {#eip-1559} +#### Cos'è l'Aggiornamento di Londra / EIP-1559? {#altair-fun-fact} Prima dell'Aggiornamento di Londra, Ethereum disponeva di blocchi di dimensioni fisse. Nei momenti di elevata domanda di rete, questi blocchi operavano a piena capacità. Di conseguenza, gli utenti devono spesso attendere che la domanda si riduca per essere inclusi in un blocco, il che ha portato a una scadente esperienza degli utenti. L'Aggiornamento di Londra ha introdotto blocchi di dimensioni variabili a Ethereum. @@ -291,16 +283,15 @@ Questo video spiega l'EIP-1559 e i benefici che comporta: [EIP-1559 Explained](h
  • EIP-3541 - impedisce la distribuzione dei contratti che iniziano con 0xEF
  • EIP-3554 – ritarda l'Era Glaciale fino a dicembre 2021
    • - --- -### Berlin {#berlin} +### Berlin {#london} -#### Riepilogo {#berlin-summary} +#### Riepilogo {#london-summary} L'aggiornamento Berlin ha ottimizzato i costi del carburante per certe azioni dell'EVM e ha aumentato il supporto per vari tipi di transazioni. @@ -315,18 +306,17 @@ L'aggiornamento Berlin ha ottimizzato i costi del carburante per certe azioni de
  • EIP-2929 – il costo del carburante aumenta per gli opcode d'accesso allo stato
  • EIP-2930 – aggiunge elenchi d'accesso facoltativi
    • - -## 2020 {#2020} +## 2020 {#eip-1559} -### Genesi della Beacon Chain {#beacon-chain-genesis} +### Genesi della Beacon Chain {#berlin} -#### Riepilogo {#beacon-chain-genesis-summary} +#### Riepilogo {#berlin-summary} La [Beacon Chain](/roadmap/beacon-chain/) necessita di 16384 depositi da 32 ETH di staking per poter funzionare in sicurezza. Questo è successo il 27 novembre, quindi la Beacon Chain ha iniziato a produrre blocchi il 1° dicembre 2020. Questa è una prima fase importante nel percorso per raggiungere la [visione di Ethereum](/roadmap/vision/). @@ -338,11 +328,11 @@ La [Beacon Chain](/roadmap/beacon-chain/) necessita di 16384 depositi da 32 ETH --- -### Distribuzione del contratto di deposito in staking {#staking-deposit-contract} +### Distribuzione del contratto di deposito in staking {#2020} -#### Riepilogo {#deposit-contract-summary} +#### Riepilogo {#beacon-chain-genesis} Il contratto di deposito in staking ha introdotto lo [staking](/glossary/#staking) all'ecosistema di Ethereum. Nonostante fosse un contratto della [Rete principale](/glossary/#mainnet), ha avuto un impatto diretto sulla linea temporale per il lancio della [Beacon Chain](/roadmap/beacon-chain/), un importante [aggiornamento di Ethereum](/roadmap/). @@ -354,11 +344,11 @@ Il contratto di deposito in staking ha introdotto lo [staking](/glossary/#stakin --- -### Muir Glacier {#muir-glacier} +### Muir Glacier {#beacon-chain-genesis-summary} -#### Riepilogo {#muir-glacier-summary} +#### Riepilogo {#staking-deposit-contract} La diramazione Muir Glacier ha introdotto un ritardo nella [bomba di difficoltà](/glossary/#difficulty-bomb). Aumenta la difficoltà del blocco del meccanismo di consenso [Proof-of-Work](/developers/docs/consensus-mechanisms/pow/), che rischiava di peggiorare l'utilizzabilità di Ethereum, aumentando i tempi d'attesa per l'invio delle transazioni e l'uso delle dapp. @@ -370,18 +360,17 @@ La diramazione Muir Glacier ha introdotto un ritardo nella [bomba di difficoltà
    • EIP-2384 – ritarda la bomba di difficoltà per altri 4.000.000 blocchi, o circa 611 giorni.
    - -## 2019 {#2019} +## 2019 {#deposit-contract-summary} -### Istanbul {#istanbul} +### Istanbul {#muir-glacier} -#### Riepilogo {#istanbul-summary} +#### Riepilogo {#muir-glacier-summary} La diramazione Instanbul: @@ -403,16 +392,15 @@ La diramazione Instanbul:
  • EIP-2028 – riduce il costo di CallData per consentire più dati nei blocchi, buono per il [ridimensionamento del Livello 2](/developers/docs/scaling/#layer-2-scaling).
  • EIP-2200 – altre alterazioni del prezzo del carburante dell'opcode.
    • - --- -### Constantinople {#constantinople} +### Constantinople {#2019} -#### Riepilogo {#constantinople-summary} +#### Riepilogo {#istanbul} La diramazione Constantinople: @@ -431,18 +419,17 @@ La diramazione Constantinople:
  • EIP-1052: Introduce l'istruzione EXTCODEHASH per recuperare l'hash del codice di un altro contratto.
  • EIP-1234 – assicura che la blockchain non si congeli prima del proof-of-stake e riduce la ricompensa per blocco da 3 a 2 ETH.
    • - -## 2017 {#2017} +## 2017 {#istanbul-summary} -### Byzantium {#byzantium} +### Byzantium {#constantinople} -#### Riepilogo {#byzantium-summary} +#### Riepilogo {#constantinople-summary} La diramazione Byzantium: @@ -466,18 +453,17 @@ La diramazione Byzantium:
  • EIP-100 – modifica la formula di regolazione della difficoltà.
  • EIP-649 – ritarda la [bomba di difficoltà](/glossary/#difficulty-bomb) di 1 anno e riduce la ricompensa del blocco da 5 a 3 ETH.
    • - -## 2016 {#2016} +## 2016 {#2017} -### Spurious Dragon {#spurious-dragon} +### Spurious Dragon {#byzantium} -#### Riepilogo {#spurious-dragon-summary} +#### Riepilogo {#byzantium-summary} La diramazione Spurious Dragon è stata la seconda risposta agli attacchi denial of service (DoS) sulla rete (settembre/ottobre 2016) e ha reso possibile, tra l'altro: @@ -495,16 +481,15 @@ La diramazione Spurious Dragon è stata la seconda risposta agli attacchi denial
  • EIP-161 – consente la rimozione dei conti vuoti aggiunti tramite attacchi DoS.
  • EIP-170 – modifica la dimensione massima del codice che un contratto sulla blockchain può avere, a 24576 byte.
    • - --- -### Tangerine Whistle {#tangerine-whistle} +### Tangerine Whistle {#2016} -#### Riepilogo {#tangerine-whistle-summary} +#### Riepilogo {#spurious-dragon} La diramazione Tangerine Whistle è stata la prima risposta agli attacchi di denial of service (DoS) alla rete (settembre/ottobre 2016) e ha incluso: @@ -518,16 +503,15 @@ La diramazione Tangerine Whistle è stata la prima risposta agli attacchi di den
  • EIP-150 – aumenta i costi del carburante degli opcode utilizzabili negli attacchi di spam.
  • EIP-158 – riduce le dimensioni di stato rimuovendo un gran numero di conti vuoti messi nello stato a costo bassissimo a causa di bug nelle versioni precedenti del protocollo di Ethereum.
    • - --- -### Diramazione OAD {#dao-fork} +### Diramazione OAD {#spurious-dragon-summary} -#### Riepilogo {#dao-fork-summary} +#### Riepilogo {#tangerine-whistle} La diramazione OAD è stata pensata come risposta all'[attacco OAD del 2016](https://www.coindesk.com/learn/understanding-the-dao-attack/), durante il quale un contratto [OAD](/glossary/#dao) non protetto è stato privato di oltre 3,6 milioni di ETH in un solo attacco. La diramazione ha spostato i fondi dal contratto difettoso a un [nuovo contratto](https://etherscan.io/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754) con una sola funzione: il prelievo. Chi aveva perso fondi ha potuto prelevare 1 ETH per ogni 100 token OAD nel proprio portafoglio. @@ -539,11 +523,11 @@ Alcuni miner rifiutarono di creare la diramazione perché l'incidente DAO non er --- -### Homestead {#homestead} +### Homestead {#tangerine-whistle-summary} -#### Riepilogo {#homestead-summary} +#### Riepilogo {#dao-fork} La diramazione Homestead guardava al futuro. Includeva diverse modifiche al protocollo e un cambiamento che ha dato a Ethereum la possibilità di eseguire ulteriori aggiornamenti della rete. @@ -556,18 +540,17 @@ La diramazione Homestead guardava al futuro. Includeva diverse modifiche al prot
  • EIP-7 – aggiunge il nuovo opcode: DELEGATECALL
  • EIP-8 – introduce i requisiti di compatibilità progressiva a devp2p
    • - -## 2015 {#2015} +## 2015 {#dao-fork-summary} -### Frontier thawing {#frontier-thawing} +### Frontier thawing {#homestead} -#### Riepilogo {#frontier-thawing-summary} +#### Riepilogo {#homestead-summary} La diramazione Frontier Thawing ha innalzato il limite di 5.000 [gas](/glossary/#gas) per [blocco](/glossary/#block) e ha impostato il prezzo predefinito del gas a 51 [gwei](/glossary/#gwei). Ciò ha reso possibili le transazioni, che richiedono 21.000 gas. La [bomba di difficoltà](/glossary/#difficulty-bomb) è stata introdotta per assicurare una hard-fork futura verso il [proof-of-stake](/glossary/#pos). @@ -576,11 +559,11 @@ La diramazione Frontier Thawing ha innalzato il limite di 5.000 [gas](/glossary/ --- -### Frontier {#frontier} +### Frontier {#2015} -#### Riepilogo {#frontier-summary} +#### Riepilogo {#frontier-thawing} Frontier è stata un'implementazione operativa ma rudimentale del progetto Ethereum. È seguita alla positiva fase di test Olympic. Era destinata agli utenti tecnici, in particolare gli sviluppatori. I [blocchi](/glossary/#block) avevano un limite di 5.000 [gas](/glossary/#gas). Questo periodo di "disgelo" (dall'inglese thawing) ha consentito ai miner di iniziare la propria operatività e ai primi utilizzatori di installare i client senza fretta. @@ -588,9 +571,9 @@ Frontier è stata un'implementazione operativa ma rudimentale del progetto Ether -## 2014 {#2014} +## 2014 {#frontier-thawing-summary} -### Vendita di Ether {#ether-sale} +### Vendita di Ether {#frontier} @@ -600,7 +583,7 @@ Ether fu ufficialmente messo in vendita per 42 giorni. Lo potresti acquistare in --- -### Pubblicazione dello yellowpaper {#yellowpaper} +### Pubblicazione dello yellowpaper {#frontier-summary} @@ -610,9 +593,9 @@ Lo Yellow Paper, redatto dal dott. Gavin Wood, è una definizione tecnica del pr -## 2013 {#2013} +## 2013 {#2014} -### Pubblicazione del whitepaper {#whitepaper} +### Pubblicazione del whitepaper {#ether-sale} diff --git a/public/content/translations/it/foundation/index.md b/public/content/translations/it/foundation/index.md index c742def2847..d1560ff071c 100644 --- a/public/content/translations/it/foundation/index.md +++ b/public/content/translations/it/foundation/index.md @@ -1,11 +1,11 @@ --- title: Ethereum Foundation -description: Scopri di più sulla Ethereum Foundation (EF), un'organizzazione no-profit dedita al supporto di Ethereum e delle tecnologie correlate. +description: "Scopri di più sulla Ethereum Foundation (EF), un'organizzazione no-profit dedita al supporto di Ethereum e delle tecnologie correlate." hideEditButton: true lang: it --- -# Informazioni sulla Ethereum Foundation {#about-the-ethereum-foundation} +# Informazioni sulla Ethereum Foundation {#ethereum-foundation} @@ -13,16 +13,14 @@ La [Ethereum Foundation](http://ethereum.foundation/) (EF) è un'organizzazione Non è un'azienda, né una no-profit tradizionale. Il suo ruolo non è quello di controllare o guidare Ethereum, e non è l'unica organizzazione che finanzia lo sviluppo critico delle tecnologie correlate a Ethereum. L'EF fa parte di un [ecosistema](/community/) molto più ampio. -## Iniziative dell'Ethereum Foundation {#ethereum-foundation-initiatives} - -### Programma di supporto dell'ecosistema {#ecosystem-support-program} +## Iniziative dell'Ethereum Foundation {#what-the-ef-does} +### Programma di supporto dell'ecosistema {#programs-and-initiatives} Il [programma di supporto dell'ecosistema](https://esp.ethereum.foundation/) esiste per dare sostegno sia finanziario che non a progetti ed entità all'interno di tutta la community Ethereum, con lo scopo di accelerare la crescita dell'ecosistema. È un'espansione dell'originario Ethereum Grants Program, che si concentrava soprattutto sul supporto finanziario. Scopri di più sul programma di supporto dell'ecosistema, sui destinatari delle sovvenzioni passati e sul processo di candidatura per le sovvenzioni su [esp.ethereum.foundation](https://esp.ethereum.foundation/). Puoi anche consultare l'[Ecosystem Support Program Blog](https://blog.ethereum.org/category/ecosystem-support-program/) o seguire [@EF_ESP](https://twitter.com/EF_ESP) per rimanere al passo con gli ultimi annunci e le notizie più recenti. -### Devcon {#devcon} - +### Devcon {#learn-more} Fin dal 2014, Ethereum Foundation ha organizzato Devcon, la conferenza annuale per tutti gli sviluppatori Ethereum, i ricercatori, i creatori e i pensatori. Puoi accedere ai contenuti video o alle conferenze di ogni anno, a partire da quello di creazione, su [archive.devcon.org](https://archive.devcon.org/). diff --git a/public/content/translations/it/governance/index.md b/public/content/translations/it/governance/index.md index 21a0a339cf5..fc1dff16672 100644 --- a/public/content/translations/it/governance/index.md +++ b/public/content/translations/it/governance/index.md @@ -22,7 +22,7 @@ Nessuna persona possiede o controlla il protocollo Ethereum, ma è comunque nece La governance di Ethereum è il processo attraverso il quale vengono apportate modifiche al protocollo. È importante sottolineare che questo processo non ha a che fare con il modo in cui le persone e le applicazioni utilizzano il protocollo, infatti Ethereum è senza autorizzazioni. Chiunque da qualsiasi parte del mondo può partecipare ad attività on-chain. Non ci sono regole fisse su chi può o non può creare un'applicazione o inviare una transazione. Tuttavia, esiste un processo per proporre modifiche al protocollo principale, su cui vengono eseguite queste applicazioni. Poiché molte persone dipendono dalla stabilità di Ethereum, esiste una soglia di coordinamento davvero elevata per i cambiamenti principali, inclusi i processi sociali e tecnici, per garantire che ogni modifica a Ethereum sia sicura e ampiamente supportata dalla community. -### Governance on-chain e off-chain {#on-chain-vs-off-chain} +### Governance on-chain e off-chain {#onchain-vs-offchain} La tecnologia blockchain rende possibili nuove modalità di governance, conosciute come governance on-chain. Per governance on-chain si intende che le proposte di modifica al protocollo sono decise tramite il voto degli stakeholder, che in genere detengono un governance token, e la votazione avviene sulla blockchain. In alcune forme di governance on-chain, le modifiche proposte al protocollo sono già scritte nel codice e vengono implementate automaticamente nel caso in cui vengano approvate dagli stakeholder tramite la sottoscrizione di una transazione. diff --git a/public/content/translations/it/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/it/guides/how-to-create-an-ethereum-account/index.md index b171b3ceb04..245478be491 100644 --- a/public/content/translations/it/guides/how-to-create-an-ethereum-account/index.md +++ b/public/content/translations/it/guides/how-to-create-an-ethereum-account/index.md @@ -47,7 +47,7 @@ Alcune applicazioni chiederanno di salvare una "frase di recupero" segreta (a vo Come utilizzare un portafoglio - + diff --git a/public/content/translations/it/guides/how-to-id-scam-tokens/index.md b/public/content/translations/it/guides/how-to-id-scam-tokens/index.md index 3af9b81af23..ad4b9dc7072 100644 --- a/public/content/translations/it/guides/how-to-id-scam-tokens/index.md +++ b/public/content/translations/it/guides/how-to-id-scam-tokens/index.md @@ -20,7 +20,6 @@ title="Cosa è ARB?" contentPreview=''> Arbitrum è un'organizzazione che sviluppa e gestisce [rollup ottimistici](/developers/docs/scaling/optimistic-rollups/). Inizialmente Arbitrum era organizzata come società a scopo di lucro, ma poi ha preso provvedimenti per decentralizzarsi. Nell'ambito di questo processo, hanno emesso un [token di governance](/dao/#token-based-membership) negoziabile. - In Ethereum esiste una convenzione per cui, quando una risorsa non è conforme a ERC-20, ne viene creata una versione "wrapped" con il nome che inizia con "w". Quindi, ad esempio, abbiamo wBTC per bitcoin e wETH per ether. Non ha senso creare una versione wrapped di un token ERC-20 già presente su Ethereum, ma i truffatori si basano sull'apparenza di legittimità piuttosto che sulla realtà sottostante. - ## Come funzionano i token truffa? {#how-do-scam-tokens-work} @@ -42,7 +40,6 @@ title="Cosa sono i contratti intelligenti?" contentPreview=''> [I contratti intelligenti](/developers/docs/smart-contracts/) sono i programmi che vengono eseguiti sulla blockchain di Ethereum. Ogni token ERC-20, ad esempio, è implementato come un contratto intelligente. - In particolare, Arbitrum ha distribuito un contratto che utilizza il simbolo `ARB`. Ma questo non impedisce ad altre persone di distribuire un contratto che utilizza lo stesso simbolo o uno simile. Chiunque scriva il contratto può stabilire ciò che il contratto farà. diff --git a/public/content/translations/it/nft/index.md b/public/content/translations/it/nft/index.md index 3279ce0720f..a9ad889f49d 100644 --- a/public/content/translations/it/nft/index.md +++ b/public/content/translations/it/nft/index.md @@ -5,11 +5,11 @@ description: Una panoramica dei NFT su Ethereum lang: it template: use-cases emoji: ":frame_with_picture:" -sidebarDepth: 3 +sidebarDepth: 2 image: /images/infrastructure_transparent.png alt: Un logo Eth visualizzato tramite ologramma. summaryPoint1: Un modo pe rappresentare qualsiasi cosa sia univoca, come una risorsa basata su Ethereum. -summaryPoint2: I NFT stanno dando ai creatori di contenuti più potere che mai. +summaryPoint2: "I NFT stanno dando ai creatori di contenuti più potere che mai." summaryPoint3: Basati sui contratti intelligenti, sulla blockchain di Ethereum. --- diff --git a/public/content/translations/it/roadmap/fusaka/index.md b/public/content/translations/it/roadmap/fusaka/index.md index dc7b4a642a5..f04f2252c3e 100644 --- a/public/content/translations/it/roadmap/fusaka/index.md +++ b/public/content/translations/it/roadmap/fusaka/index.md @@ -186,6 +186,7 @@ Questo EIP si trova in una sezione separata dagli "EIP Core" perché il fork non ## Domande frequenti {#faq} ### Questo aggiornamento riguarda tutti i nodi e i validatori di Ethereum? {#does-this-upgrade-affect-all-ethereum-nodes-and-validators} + Sì, l'aggiornamento Fusaka richiede aggiornamenti sia per i [client di esecuzione che per i client di consenso](/developers/docs/nodes-and-clients/). Tutti i client principali di Ethereum rilasceranno versioni che supportano l'hard fork, contrassegnate come ad alta priorità. Puoi tenerti aggiornato su quando queste versioni saranno disponibili nei repository Github dei client, sui loro [canali Discord](https://ethstaker.org/support), sul [Discord di EthStaker](https://dsc.gg/ethstaker) o iscrivendoti al blog di Ethereum per gli aggiornamenti del protocollo. Per mantenere la sincronizzazione con la rete Ethereum dopo l'aggiornamento, gli operatori dei nodi devono assicurarsi di eseguire una versione client supportata. Si tenga presente che le informazioni sui rilasci dei client sono sensibili al fattore tempo e gli utenti devono fare riferimento agli ultimi aggiornamenti per dettagli attuali. ### Come si converte l'ETH dopo la biforcazione dura? {#how-can-eth-be-converted-after-the-hardfork} diff --git a/public/content/translations/it/roadmap/future-proofing/index.md b/public/content/translations/it/roadmap/future-proofing/index.md index 85e680f46d1..b546e7d39ee 100644 --- a/public/content/translations/it/roadmap/future-proofing/index.md +++ b/public/content/translations/it/roadmap/future-proofing/index.md @@ -13,7 +13,7 @@ Alcune parti della tabella di marcia non sono necessariamente richieste per ridi Parte della [crittografia](/glossary/#cryptography) che protegge l'attuale Ethereum sarà compromessa quando l'informatica quantistica diventerà una realtà. Sebbene i computer quantistici siano probabilmente a decenni dall'essere una vera minaccia per la crittografia moderna, Ethereum ha una struttura che ne garantisce la sicurezza nei secoli a venire. Ciò significa rendere [Ethereum resistente ai computer quantistici](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) il prima possibile. -La sfida per gli sviluppatori di Ethereum è che l'attuale protocollo [proof-of-stake](/glossary/#pos) si affida a uno schema di firma molto efficiente, noto come BLS, per aggregare i voti sui [blocchi](/glossory/#block) validi. Questo schema di firme è infranto dai computer quantistici, ma le alternative resistenti a essi non sono altrettanto efficaci. +La sfida per gli sviluppatori di Ethereum è che l'attuale protocollo [proof-of-stake](/glossary/#pos) si affida a uno schema di firma molto efficiente, noto come BLS, per aggregare i voti sui [blocchi](/glossary/#block) validi. Questo schema di firme è infranto dai computer quantistici, ma le alternative resistenti a essi non sono altrettanto efficaci. Gli [schemi di commitment “KZG”](/roadmap/danksharding/#what-is-kzg) usati in diversi punti di Ethereum per generare segreti crittografici sono noti per essere vulnerabili ai computer quantistici. Attualmente questo viene aggiorato con l'uso di "impostazioni fidate" (per le quali la cerimonia d'impostazione principale venne completata con successo nel 2023) dove tanti utenti generano casualità non decifrabile da computer quantistici. Ad ogni modo, la soluzione ideale per il lungo termine sarebbe invece la crittografia quantistica sicura. Ci sono due approcci principali che potrebbero diventare sostituti efficienti per lo schema BLS: la firma [basata su STARK](https://hackmd.io/@vbuterin/stark_aggregation) e quella [basata su reticolo](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175). **Sono ancora attivamente in fase di ricerca e prototipazione.** diff --git a/public/content/translations/it/roadmap/merge/issuance/index.md b/public/content/translations/it/roadmap/merge/issuance/index.md index 998ddc946a5..b8b5a09363a 100644 --- a/public/content/translations/it/roadmap/merge/issuance/index.md +++ b/public/content/translations/it/roadmap/merge/issuance/index.md @@ -62,7 +62,9 @@ Offerta totale di ETH: **~120.520.000 ETH** (al momento de La Fusione, a settemb **~11,3%** veniva emesso agli staker sul livello di consenso (0,52 / 4,61 \* 100) + + ## Post-Fusione (oggi) {#post-merge} @@ -96,7 +98,9 @@ Tasso di emissione annualizzato totale: **~0,52%** Riduzione netta dell'emissione annuale di ETH: **~88,7%** ((4,61% - 0,52%) / 4,61% \* 100) + + ##  La bruciatura {#the-burn} @@ -109,7 +113,9 @@ La forza opposta all'emissione di ETH è il tasso a cui gli ETH sono bruciati. P La bruciatura delle commissioni è stata introdotta con l'[aggiornamento London](/ethereum-forks/#london) nell'agosto del 2021 e da La Fusione è rimasta invariata. + + Oltre alla bruciatura della commissione, implementata dall'aggiornamento di Londra, i validatori, inoltre, possono incorrere in sanzioni per essere online o, peggio, possono ricevere tagli per l'infrazione di regole specifiche che minacciano la sicurezza della rete. Queste, risultano in una riduzione degli ETH dal saldo di quel validatore, che non è ricompensato direttamente a nessun altro conto, bruciandoli/rimuovendoli effettivamente dalla circolazione. diff --git a/public/content/translations/it/roadmap/verkle-trees/index.md b/public/content/translations/it/roadmap/verkle-trees/index.md index 52560d7342a..6efeedd8590 100644 --- a/public/content/translations/it/roadmap/verkle-trees/index.md +++ b/public/content/translations/it/roadmap/verkle-trees/index.md @@ -36,6 +36,7 @@ Le dimensioni dei testimoni variano a seconda del numero di foglie che include. ## Qual è la struttura di un albero di Verkle? {#what-is-the-structure-of-a-verkle-tree} + Gli alberi di Verkle sono coppie `(key,value)` in cui le chiavi sono elementi da 32 byte composti da uno _stelo_ di 31 byte e un _suffisso_ di un singolo byte. Queste chiavi sono organizzate in nodi di _estensione_ e nodi _interni_. I nodi d'estensione rappresentano un singolo stelo per 256 figli con suffissi differenti. Anche i nodi interni hanno 256 figli, ma possono essere altri nodi d'estensione. La differenza principale tra la struttura dell'albero di Verkle e dell'albero di Merkle è che il primo è molto più piatto, a significare che ci sono meno nodi intermedi che collegano una foglia alla radice e dunque sono richiesti meno dati per generare una prova. ![](./verkle.png) diff --git a/public/content/translations/it/social-networks/index.md b/public/content/translations/it/social-networks/index.md index 47d7099ccb2..2c62d2f1d3f 100644 --- a/public/content/translations/it/social-networks/index.md +++ b/public/content/translations/it/social-networks/index.md @@ -65,18 +65,18 @@ I post pubblicati su Mirror sono memorizzati permanentemente su Arweave, una pia Gli utenti utilizzano il token [ERC-20](/glossary/#erc-20) nativo della piattaforma $MIND per pagare gli articoli. Inoltre, gli utenti, possono anche guadagnare token $MIND, pubblicando contenuti popolari, contribuendo all'ecosistema e riferendo altri alla piattaforma. -## Utilizzare i social decentralizzati {#use-decentralized-social-networks} +## Utilizzare i social decentralizzati {#farcaster} - **[Status.im](https://status.im/)**: _Status è un'app di messaggistica sicura che utilizza un protocollo open source e tra pari, nonché la crittografia end-to-end per proteggere i tuoi messaggi dalle terze parti._ - **[Mirror.xyz](https://mirror.xyz/)**: _Mirror è una piattaforma di pubblicazione decentralizzata e posseduta dagli utenti basata su Ethereum, per il crowdfunding delle idee, la monetizzazione dei contenuti e la creazione di community dal valore elevato._ - **[Lens Protocol](https://lens.xyz/)**: _Lens Protocol è un grafico sociale componibile e decentralizzato che aiuta i creatori a prendere possesso dei propri contenuti, ovunque vadano nel proprio giardino digitale dell'Intenet decentralizzato._ - **[Farcaster](https://farcaster.xyz/)**: _Farcaster è un social sufficientemente decentralizzato. È un protocollo aperto che supporta molti client, proprio come l'email._ -## Social network Web2 su Ethereum {#web2-social-networks-and-ethereum} +## Social network Web2 su Ethereum {#use-decentralized-social-networks} Le piattaforme social native del [Web3](/glossary/#web3) non sono le sole che stanno tentando di incorporare la tecnologia della blockchain nei social. Anche molte piattaforme centralizzate stanno pianificando di integrare Ethereum nella propria infrastruttura: -### Reddit {#reddit} +### Reddit {#web2-social-networks-and-ethereum} Reddit ha [pubblicizzato i Punti della Community](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users): token ERC-20 che gli utenti possono guadagnare pubblicando contenuti di qualità e contribuendo alle community online (subreddit). Puoi riscattare tali token in una subreddit per ottenere privilegi e vantaggi esclusivi. Per questo progetto, Reddit sta lavorando con Arbitrum, una rete di [livello 2](/glossary/#layer-2) progettata per ridimensionare le transazioni di Ethereum. @@ -84,9 +84,9 @@ Il programma è già attivo: la subreddit r/CryptoCurrency [adopera la propria v Oltre a utilizzare i Punti della Community per sbloccare funzionalità speciali, gli utenti possono anche scambiarli per valuta legale nelle piattaforme di scambio. Inoltre, l'importo di Punti della Community posseduto da un utente ne determina l'influenza sul processo decisionale all'interno della community. -## Lettura consigliate {#further-reading} +## Lettura consigliate {#brave} -### Articoli {#articles} +### Articoli {#audius} - [Decentralizzare i social: una guida allo stack dei social di Web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) - _Coinbase Ventures_ - [I social sono la prossima grande opportunità per la decentralizzazione](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) - _Ben Goertzel_ @@ -95,12 +95,12 @@ Oltre a utilizzare i Punti della Community per sbloccare funzionalità speciali, - [In che modo la blockchain può risolvere la privacy dei social](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) - _Prableen Bajpai_ - [Decentralizzazione sufficiente per i social](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) - _Varun Srinivasan_ -### Video {#videos} +### Video {#sorare} - [Social decentralizzati spiegati](https://www.youtube.com/watch?v=UdT2lpcGvcQ) - _Coinmarketcap_ - [La blockchain DeSo vuole decentralizzare i social](https://www.youtube.com/watch?v=SG2HUiVp0rE) - _Bloomberg Technology_ - [Il futuro dei social decentralizzati, con Balaji Srinivasan, Vitalik Buterin e Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) - _ETHGlobal_ -### Community {#communities} +### Community {#twitter} - [Subreddit r/CryptoCurrency](https://www.reddit.com/r/CryptoCurrency/) diff --git a/public/content/translations/it/staking/solo/index.md b/public/content/translations/it/staking/solo/index.md index 1404f528317..76c7d3b9af0 100644 --- a/public/content/translations/it/staking/solo/index.md +++ b/public/content/translations/it/staking/solo/index.md @@ -71,6 +71,7 @@ A differenza delle penalità per inattività dovute all'essere offline, lo s Ulteriori informazioni sullo slashing e sul ciclo di vita dei validatori + diff --git a/public/content/translations/it/web3/index.md b/public/content/translations/it/web3/index.md index 3f5471f8d37..27e766f171f 100644 --- a/public/content/translations/it/web3/index.md +++ b/public/content/translations/it/web3/index.md @@ -1,5 +1,5 @@ --- -title: Cos'è Web3 e perché è importante? +title: "Cos'è Web3 e perché è importante?" description: 'Un''introduzione al Web3: la prossima evoluzione del World Wide Web e perché conta.' lang: it --- diff --git a/public/content/translations/it/zero-knowledge-proofs/index.md b/public/content/translations/it/zero-knowledge-proofs/index.md index 4f3d1b252be..2160de55c58 100644 --- a/public/content/translations/it/zero-knowledge-proofs/index.md +++ b/public/content/translations/it/zero-knowledge-proofs/index.md @@ -46,13 +46,13 @@ Gli attuali sistemi di gestione dell'identità mettono a rischio i dati personal Le dimostrazioni a conoscenza zero sono particolarmente utili nel contesto di [identità decentralizzata](/decentralized-identity/). L'identità decentralizzata (descritta anche come «identità auto-sovrana») conferisce all'individuo la possibilità di controllare l'accesso agli identificatori personali. Dimostrare la propria cittadinanza senza rivelare il proprio ID fiscale o i dettagli del passaporto è un buon esempio di come la tecnologia a conoscenza zero consente l'identità decentralizzata. -### Autenticazione {#authentication} +### Autenticazione {#proof-of-humanity} L'utilizzo di servizi online richiede la prova della tua identità e del diritto di accedere a tali piattaforme. Questo richiede spesso di fornire informazioni personali, come nomi, indirizzi e-mail, date di nascita, e così via. Potrebbe anche essere necessario memorizzare password lunghe o rischiare di perdere l'accesso. Le dimostrazioni a conoscenza zero possono, tuttavia, semplificare l'autenticazione sia per le piattaforme che per gli utenti. Una volta che una dimostrazione a conoscenza zero è stata generata utilizzando input pubblici (es., dati che attestano l'appartenenza dell'utente alla piattaforma) e input privati (es., i dati dell'utente), l'utente può semplicemente presentarlo per autenticare la propria identità quando hanno bisogno di accedere al servizio. Questo migliora l'esperienza per gli utenti e libera le organizzazioni dalla necessità di memorizzare enormi quantità di informazioni per gli utenti. -### Calcolo verificabile {#verifiable-computation} +### Calcolo verificabile {#authentication} Il calcolo verificabile è un'altra applicazione della tecnologia a conoscenza zero per migliorare i progetti blockchain. Il calcolo verificabile ci permette di esternalizzare il calcolo ad un'altra entità mantenendo i risultati verificabili. L'entità presenta il risultato insieme a un'attestazione che verifica che il programma è stato eseguito correttamente. @@ -76,7 +76,7 @@ La catena ha bisogno di un modo per convalidare le transazioni off-chain senza e I [rollup a conoscenza zero](/developers/docs/scaling/zk-rollups) e [validium](/developers/docs/scaling/validium/) sono due soluzioni di scaling off-chain che utilizzano prove di validità per fornire una scalabilità sicura. Questi protocolli eseguono centinaia di transazioni off-chain e inviano la prova di verifica su Ethereum. Questi risultati possono essere applicati immediatamente dopo che la prova è stata verificata, permettendo ad Ethereum di elaborare più transazioni senza incrementare i calcoli sul livello di base. -### Ridurre la corruzione e la collusione nelle votazioni on-chain {#secure-blockchain-voting} +### Ridurre la corruzione e la collusione nelle votazioni on-chain {#verifiable-computation} Gli schemi di voto della blockchain hanno molte caratteristiche favorevoli: sono interamente controllabili, sicuri contro gli attacchi, resistenti alla censura e liberi da vincoli geografici. Ma persino gli schemi di voto on-chain non sono immuni al problema della **collusione**. @@ -90,7 +90,7 @@ Utilizzare il voto on-chain espone il finanziamento quadratico alla collusione: Per fortuna, le nuove soluzioni, come la MACI (Infrastruttura Anti-Collusione Minima), utilizzano le prove a conoscenza zero per rendere il voto on-chain (es. i meccanismi di finanziamento quadratico) resistenti a corruzione e collusione. La MACI è una serie di contratti intelligenti e script che consentono a un amministratore centrale (detto "coordinatore") di aggregare voti e risultati _senza_ rivelare nulla sulle indicazioni di voto del singolo. Ciononostante, è ancora possibile verificare che i voti siano stati contati correttamente o confermare che un particolare individuo abbia partecipato al turno di votazioni. -#### Come funziona MACI con prove a conoscenza zero? {#how-maci-works-with-zk-proofs} +#### Come funziona MACI con prove a conoscenza zero? {#secure-blockchain-voting} All'inizio, il coordinatore distribuisce il contratto della MACI su Ethereum, dopodiché gli utenti possono iscriversi al voto (registrando la propria chiave pubblica nel contratto intelligente). Gli utenti trasmettono i voti inviando messaggi crittografati con la propria chiave pubblica al contratto intelligente (un voto valido dev'essere firmato con la chiave pubblica più recente associata all'identità dell'utente, tra gli altri criteri). Dopodiché, il coordinatore elabora tutti i messaggi al termine del periodo di voto, conteggia i voti e verifica i risultati on-chain. @@ -112,7 +112,7 @@ Ma nei casi in cui il coordinatore rimane onesto, la MACI rappresenta un potente [Maggiori informazioni su MACI](https://maci.pse.dev/). -## Come funzionano le prove a conoscenza zero? {#how-do-zero-knowledge-proofs-work} +## Come funzionano le prove a conoscenza zero? {#how-maci-works-with-zk-proofs} Una prova a conoscenza zero permette di dimostrare la verità di una dichiarazione senza condividere i contenuti dell’affermazione o rivelare come l'hai scoperta. A tal fine, i protocolli a conoscenza zero si basano su algoritmi che prendono alcuni dati in entrata e restituiscono ‘true’ o ‘false’ come risultato. @@ -136,7 +136,7 @@ Quanto sopra descrive la struttura di una “prova interattiva a conoscenze zero Un buon esempio che illustra come funzionano le prove interattive è la famosa storia di Jean-Jacques Quisquater sulla[ grotta di Ali Baba](https://en.wikipedia.org/wiki/Zero-knowledge_proof#The_Ali_Baba_cave). Nella storia, Peggy (il dimostratore) vuole dimostrare a Victor (il validatore) che conosce la frase segreta per aprire una porta magica senza rivelare la frase. -### Prove a conoscenze zero non interattive {#non-interactive-zero-knowledge-proofs} +### Prove a conoscenze zero non interattive {#how-do-zero-knowledge-proofs-work} Sebbene rivoluzionario, la prova interattiva aveva un'utilità limitata poiché richiedeva che le due parti fossero disponibili e interagissero ripetutamente. Anche se un validatore fosse convinto dell’onestà di un dimostratore, la prova non sarebbe disponibile per una verifica indipendente (il calcolo di una nuova prova richiede una nuova serie di messaggi tra il dimostratore e il validatore). @@ -148,9 +148,9 @@ La prova non interattiva riduce la comunicazione tra dimostratore e validatore, Le prove non interattive hanno rappresentato una svolta per la tecnologia a conoscenza zero e hanno stimolato lo sviluppo dei sistemi di dimostrazione utilizzati oggi. Discutiamo questi tipi di prova di seguito: -### Tipologie di prove a conoscenza zero {#types-of-zero-knowledge-proofs} +### Tipologie di prove a conoscenza zero {#non-interactive-zero-knowledge-proofs} -#### ZK-SNARK {#zk-snarks} +#### ZK-SNARK {#types-of-zero-knowledge-proofs} ZK-SNARK è un acronimo per **Zero-Knowledge Succinct Non-Interactive Argoment of Knowledge**. Il protocollo ZK-SNARK ha le seguenti qualità: @@ -170,7 +170,7 @@ La «chiave condivisa» menzionata in precedenza si riferisce a parametri pubbli Le configurazioni sulla fiducia richiedono agli utenti di fidarsi dei partecipanti alla generazione dei parametri. Tuttavia, lo sviluppo di ZK-STARK ha creato le condizioni affinché i protocolli di prova funzionino con una configurazione non affidabile. -#### ZK-STARK {#zk-starks} +#### ZK-STARK {#zk-snarks} ZK-SNARK è un acronimo per **Zero-Knowledge Succinct Non-Interactive Argoment of Knowledge**. I ZK-STARK sono simili ai ZK-SNARK, tranne per il fatto che sono: @@ -180,29 +180,29 @@ ZK-SNARK è un acronimo per **Zero-Knowledge Succinct Non-Interactive Argoment o Gli ZK-STARK producono prove più grandi rispetto agli ZK-SNARK, il che significa che generalmente hanno spese generali di verifica più elevate. Tuttavia, esistono casi (come la dimostrazione di grandi set di dati) in cui ZK-STARK può essere più conveniente rispetto a ZK-SNARK. -## Svantaggi dell'utilizzo delle prove a conoscenza zero {#drawbacks-of-using-zero-knowledge-proofs} +## Svantaggi dell'utilizzo delle prove a conoscenza zero {#zk-starks} -### Costi hardware {#hardware-costs} +### Costi hardware {#drawbacks-of-using-zero-knowledge-proofs} Generare prove a conoscenza zero comporta calcoli molto complessi, eseguiti meglio su macchine specializzate. Poiché tali macchine sono costose, sono spesso fuori dalla portata delle persone "normali". Inoltre, le applicazioni che desiderano utilizzare la tecnologia a conoscenza zero devono tenere conto dei costi dell'hardware, che potrebbero incrementare i costi per gli utenti finali. -### Costi di verifica delle prove {#proof-verification-costs} +### Costi di verifica delle prove {#hardware-costs} Anche la verifica delle prove richiede calcoli complessi e incrementa i costi di implementazione della tecnologia a conoscenza zero nelle applicazioni. Questo costo è particolarmente importante nel contesto della prova del calcolo. Ad esempio, i rollup ZK pagano approssimativamente 500.000 gas per verificare una singola prova ZK-SNARK su Ethereum, mentre le ZK-STARK richiedono commissioni persino maggiori. -### Ipotesi di fiducia {#trust-assumptions} +### Ipotesi di fiducia {#proof-verification-costs} Nelle ZN-SNARK, la Stringa di Riferimento Comune (parametri pubblici) è generata una volta ed è disponibile per il riutilizzo alle parti che desiderano partecipare al protocollo a conoscenza zero. I parametri pubblici sono creati tramite una cerimonia di configurazione attendibile, in cui partecipanti sono considerati onesti. Ma non esiste davvero un modo tramite cui gli utenti possano valutare l'onestà dei partecipanti e gli utenti devono prendere in parola gli sviluppatori. Le ZK-STARK sono libere da ipotesi di fiducia, poiché la casualità utilizzata nel generare la stringa è verificabile pubblicamente. Nel mentre, i ricercatori stanno lavorando a configurazioni non basate sulla fiducia per le ZK-SNARK per aumentare la sicurezza dei meccanismi di prova. -### Minacce del calcolo quantistico {#quantum-computing-threats} +### Minacce del calcolo quantistico {#trust-assumptions} ZK-SNARK utilizza la crittografia a curva ellittica. Sebbene oggi si presupponga che il problema del logaritmo discreto della curva ellittica sia irrisolvibile, in futuro lo sviluppo dei computer quantistici potrebbero infrangere questo modello di sicurezza. ZK-STARK è considerato immune alla minaccia dell'informatica quantistica, poiché si affida esclusivamente a funzioni di hash resistenti alla collisione per la propria sicurezza. A differenza delle coppie di chiavi pubbliche-private utilizzate nella crittografia a curva ellittica, gli hash resistenti alla collisione sono più difficili da rompere per gli algoritmi dei computer quantistici. -## Letture consigliate {#further-reading} +## Letture consigliate {#quantum-computing-threats} - [Panoramica dei casi d'uso per le prove a conoscenza zero](https://pse.dev/projects): _Privacy and Scaling Explorations Team_ - [SNARK vs. STARK vs. SNARK Ricorsivi](https://www.alchemy.com/overviews/snarks-vs-starks) _Alchemy Overviews_ From c2688c5da78bfe7b8881a16dc8ba8cfcac88d452 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sun, 15 Feb 2026 15:43:29 +0000 Subject: [PATCH 3/3] fix(i18n): correct typos and misspellings in Italian roadmap/staking translations - Fix "Poof of Work/stake" -> "proof-of-work/stake" in merge page - Fix "Bacon Chain" -> "Beacon Chain" in pectra page - Fix "Petra" -> "Pectra" and "Elettra" -> "Electra" in pectra page - Fix "lob" -> "blob" in pectra page - Fix "Rete rrincipale" -> "Rete Principale" in merge page - Fix "La Fusion" -> "La Fusione" in beacon-chain page - Fix "Dansharding"/"Dankshaarding" -> "Danksharding" in danksharding/scaling pages - Fix "dometico" -> "domestico" in solo staking page - Fix "rigurado" -> "riguardo" and "prova-di-interesse" -> "proof-of-stake" in beacon-chain description --- .../translations/it/developers/docs/scaling/index.md | 2 +- .../content/translations/it/roadmap/beacon-chain/index.md | 4 ++-- .../content/translations/it/roadmap/danksharding/index.md | 4 ++-- public/content/translations/it/roadmap/merge/index.md | 8 ++++---- public/content/translations/it/roadmap/pectra/index.md | 6 +++--- public/content/translations/it/staking/solo/index.md | 2 +- 6 files changed, 13 insertions(+), 13 deletions(-) diff --git a/public/content/translations/it/developers/docs/scaling/index.md b/public/content/translations/it/developers/docs/scaling/index.md index 97da0bd92d5..f47998f4886 100644 --- a/public/content/translations/it/developers/docs/scaling/index.md +++ b/public/content/translations/it/developers/docs/scaling/index.md @@ -25,7 +25,7 @@ La scalabilità on-chain richiede modifiche al protocollo Ethereum ([rete princi ### Sharding {#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. +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 [Danksharding](/roadmap/danksharding) (aggiunta di blob di dati di rollup ai blocchi di Ethereum che possono essere verificati in modo molto efficiente dai validatori), ha portato la community di Ethereum a preferire il ridimensionamento incentrato sui rollup piuttosto che sullo sharding. Ciò aiuterà anche a mantenere più semplice la logica del consenso di Ethereum. ## Scalabilità off-chain {#offchain-scaling} diff --git a/public/content/translations/it/roadmap/beacon-chain/index.md b/public/content/translations/it/roadmap/beacon-chain/index.md index 5d5e5cf8cbd..b15f629ff75 100644 --- a/public/content/translations/it/roadmap/beacon-chain/index.md +++ b/public/content/translations/it/roadmap/beacon-chain/index.md @@ -1,6 +1,6 @@ --- title: La Beacon Chain -description: Informati rigurado alla Beacon Chain - l'aggiornamento che ha introdotto la prova-di-interesse Ethereum. +description: Informati riguardo alla Beacon Chain - l'aggiornamento che ha introdotto il proof-of-stake di Ethereum. lang: it template: upgrade image: /images/upgrades/core.png @@ -16,7 +16,7 @@ summaryPoint3: La Beacon Chain ha introdotto la logica del consenso e il protoco ## Cos'è la Beacon Chain? {#what-is-the-beacon-chain} -Beacon Chain era il nome della blockchain di proof of stake originale, lanciata nel 2020. Fu creata per assicurare che la logica di consenso di Proof of stake fosse stabile e sostenibile prima di abilitarla sulla Rete principale di Ethereum. Di conseguenza, era eseguita insieme all'Ethereum Proof of Work originale. La Beacon Chain era una catena di blocchi 'vuoti', ma la disattivazione del proof of work e l'attivazione del proof of stake su Ethereum, hanno richiesto di istruire la Beacon Chain per accettare i dati delle transazioni dai client d'esecuzione, raggrupparli in blocchi, quindi organizzarli in una blockchain utilizzando il meccanismo di consenso basato sul proof of stake. Allo stesso momento, i client originali di Ethereum hanno disattivato il proprio mining, la propagazione dei blocchi e la logica di consenso, passando tutti questi aspetti alla Beacon Chain. Questo evento era noto come [La Fusione](/roadmap/merge/). Una volta verificatasi La Fusion, non esistevano più due blockchain. Invece, ora, esiste un singolo Ethereum di proof of stake, che richiede due client differenti per nodo. La Beacon Chain è ora il livello del consenso, una rete tra pari dei client del consenso, che gestisce il gossip dei blocchi e la logica di consenso, mentre i client originali formano il livello d'esecuzione, responsabile del gossip e dell'esecuzione delle transazioni, e della gestione dello stato di Ethereum. I due livelli possono comunicare tra loro utilizzando l'Engine API. +Beacon Chain era il nome della blockchain di proof of stake originale, lanciata nel 2020. Fu creata per assicurare che la logica di consenso di Proof of stake fosse stabile e sostenibile prima di abilitarla sulla Rete principale di Ethereum. Di conseguenza, era eseguita insieme all'Ethereum Proof of Work originale. La Beacon Chain era una catena di blocchi 'vuoti', ma la disattivazione del proof of work e l'attivazione del proof of stake su Ethereum, hanno richiesto di istruire la Beacon Chain per accettare i dati delle transazioni dai client d'esecuzione, raggrupparli in blocchi, quindi organizzarli in una blockchain utilizzando il meccanismo di consenso basato sul proof of stake. Allo stesso momento, i client originali di Ethereum hanno disattivato il proprio mining, la propagazione dei blocchi e la logica di consenso, passando tutti questi aspetti alla Beacon Chain. Questo evento era noto come [La Fusione](/roadmap/merge/). Una volta verificatasi La Fusione, non esistevano più due blockchain. Invece, ora, esiste un singolo Ethereum di proof of stake, che richiede due client differenti per nodo. La Beacon Chain è ora il livello del consenso, una rete tra pari dei client del consenso, che gestisce il gossip dei blocchi e la logica di consenso, mentre i client originali formano il livello d'esecuzione, responsabile del gossip e dell'esecuzione delle transazioni, e della gestione dello stato di Ethereum. I due livelli possono comunicare tra loro utilizzando l'Engine API. ## Cosa fa la beacon chain? {#what-does-the-beacon-chain-do} diff --git a/public/content/translations/it/roadmap/danksharding/index.md b/public/content/translations/it/roadmap/danksharding/index.md index 38971518027..524f4914bc0 100644 --- a/public/content/translations/it/roadmap/danksharding/index.md +++ b/public/content/translations/it/roadmap/danksharding/index.md @@ -6,7 +6,7 @@ summaryPoints: - Il danksharding è un aggiornamento multi-fase per migliorare la scalabilità e la capacità di Ethereum. - La prima fase, il Proto-Danksharding, aggiunge i blob di dati ai blocchi - I blob di dati offrono un modo più economico per i rollup di pubblicare i dati su Ethereum, tali costi possono essere trasferiti agli utenti sotto forma di commissioni di transazione inferiori. - - In seguito, il Dansharding completo diffonderà la responsabilità di verificare i blob di dati tra i sottoinsiemi di nodi, ridimensionando ulteriormente Ethereum, a oltre 100.000 transazioni al secondo. + - In seguito, il Danksharding completo diffonderà la responsabilità di verificare i blob di dati tra i sottoinsiemi di nodi, ridimensionando ulteriormente Ethereum, a oltre 100.000 transazioni al secondo. --- # Danksharding {#danksharding} @@ -59,7 +59,7 @@ Se qualcuno conosce le posizioni casuali utilizzate per l'impegno, è facile gen ## Cos'è il Danksharding? {#what-is-danksharding} -Il Danksharding è la piena realizzazione del ridimensionamento del rollup, avviata con il Proto-Danksharding. Il Dankshaarding comporterà enormi quantità di spazio su Ethereum, dove i rollup potranno riversare i dati compressi delle loro transazioni. Ciò significa che Ethereum potrà supportare centinaia di rollup individuali con facilità, rendendo realtà milioni di transazioni al secondo. +Il Danksharding è la piena realizzazione del ridimensionamento del rollup, avviata con il Proto-Danksharding. Il Danksharding comporterà enormi quantità di spazio su Ethereum, dove i rollup potranno riversare i dati compressi delle loro transazioni. Ciò significa che Ethereum potrà supportare centinaia di rollup individuali con facilità, rendendo realtà milioni di transazioni al secondo. Funziona espandendo i blob collegati ai blocchi da sei (6) nel proto-danksharding, a 64 nel Danksharding completo. Il resto delle modifiche necessarie sono tutti gli aggiornamenti al metodo di operazione dei client del consenso, per consentire loro di gestire i nuovi, grandi blob. Svariate di queste modifiche sono già sulla tabella di marcia per altri scopi, indipendenti dal Danksharding. Ad esempio, il Danksharding richiede la separazione del propositore e del costruttore, per essere implementata. Questo è un aggiornamento che separa le mansioni di costruzione e proposta dei blocchi, tra validatori differenti. Similmente, il campionamento della disponibilità dei dati è necessario per il Danksharding, ma è anche necessario per lo sviluppo di client molto leggeri, che non memorizzano molti dati storici ("client privi di stato"). diff --git a/public/content/translations/it/roadmap/merge/index.md b/public/content/translations/it/roadmap/merge/index.md index e397b09fbbb..93002520301 100644 --- a/public/content/translations/it/roadmap/merge/index.md +++ b/public/content/translations/it/roadmap/merge/index.md @@ -1,6 +1,6 @@ --- title: La fusione -description: "Scopri La Fusione: quando la Rete principale di Ethereum ha adottato il Poof of stake." +description: "Scopri La Fusione: quando la Rete principale di Ethereum ha adottato il proof-of-stake." lang: it template: upgrade image: /images/upgrades/merge.png @@ -21,13 +21,13 @@ La Fusione è stata l'unione del livello di esecuzione originale di Ethereum (la -Inizialmente, la [Beacon Chain](/roadmap/beacon-chain/) è stata distribuita separatamente dalla [Rete Principale](/glossary/#mainnet). La Rete Principale di Ethereum, con tutti i suoi conti, saldi, contratti intelligenti e stati della blockchain, ha continuato a essere protetta da [proof-of-work](/developers/docs/consensus-mechanisms/pow/), anche mentre la Beacon Chain veniva eseguita in parallelo utilizzando il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). La Fusione si è verificata quando, finalmente, questi due sistemi si sono uniti e il Poof of Work è stata permanentemente sostituita dal Proof of stake. +Inizialmente, la [Beacon Chain](/roadmap/beacon-chain/) è stata distribuita separatamente dalla [Rete Principale](/glossary/#mainnet). La Rete Principale di Ethereum, con tutti i suoi conti, saldi, contratti intelligenti e stati della blockchain, ha continuato a essere protetta da [proof-of-work](/developers/docs/consensus-mechanisms/pow/), anche mentre la Beacon Chain veniva eseguita in parallelo utilizzando il [proof-of-stake](/developers/docs/consensus-mechanisms/pos/). La Fusione si è verificata quando, finalmente, questi due sistemi si sono uniti e il proof-of-work è stato permanentemente sostituito dal proof-of-stake. Immagina Ethereum come una nave lanciata prima di essere pronta per un viaggio interstellare. Con la Beacon Chain, la community ha costruito un nuovo motore e uno scafo più resistente. Dopo test significativi, è arrivato il momento di scambiare il vecchio motore con quello nuovo durante il volo. Questo ha aggiunto il nuovo e più efficiente motore nella nave esistente, consentendole di percorrere diversi anni luce e conquistare l'universo. ## Fusione con la Rete Principale {#merging-with-mainnet} -La Proof of Work ha protetto la Rete rrincipale di Ethereum dalla genesi alla Fusione. Questo ha consentito alla blockchain di Ethereum a cui siamo tutti abituati di venire alla luce nel luglio 2015 con tutte le sue funzionalità familiari: transazioni, contratti intelligenti, conti, ecc. +La proof-of-work ha protetto la Rete Principale di Ethereum dalla genesi alla Fusione. Questo ha consentito alla blockchain di Ethereum a cui siamo tutti abituati di venire alla luce nel luglio 2015 con tutte le sue funzionalità familiari: transazioni, contratti intelligenti, conti, ecc. Nella storia di Ethereum, gli sviluppatori si sono preparati per un'eventuale transizione dal Proof of Work al Proof of stake. Il 1° dicembre 2020, la Beacon Chain è stata creata come una blockchain separata dalla Rete principale, eseguita in parallelo. @@ -149,7 +149,7 @@ title="Equivoco: "Le transazioni sono state accelerate in modo sostanziale contentPreview="Falso. Sebbene esistano alcune lievi modifiche, la velocità delle transazioni sul livello 1 è per lo più la stessa di prima de La Fusione."> La "velocità" di una transazione può essere misurata in diversi modi, tra cui il tempo necessario per essere inclusa in un blocco e il tempo per la finalizzazione. Entrambi cambiano lievemente, ma non in modo apprezzabile dagli utenti. -Storicamente, con il Poof of Work, l'obiettivo era avere un nuovo blocco ogni 13,3 secondi circa. Con il Poof of stake, gli slot si verificano precisamente ogni 12 secondi, e ciascuno rappresenta un'opportunità per un validatore di pubblicare un blocco. Gran parte degli slot contiene blocchi, ma non necessariamente tutti (cioè un validatore è offline). Nel Proof of stake, i blocchi sono prodotti a una frequenza del 10% circa maggiore che nel Proof of Work. Questo è stato un cambiamento abbastanza irrilevante ed è improbabile che sia notato dagli utenti. +Storicamente, con il proof-of-work, l'obiettivo era avere un nuovo blocco ogni 13,3 secondi circa. Con il proof-of-stake, gli slot si verificano precisamente ogni 12 secondi, e ciascuno rappresenta un'opportunità per un validatore di pubblicare un blocco. Gran parte degli slot contiene blocchi, ma non necessariamente tutti (cioè un validatore è offline). Nel Proof of stake, i blocchi sono prodotti a una frequenza del 10% circa maggiore che nel Proof of Work. Questo è stato un cambiamento abbastanza irrilevante ed è improbabile che sia notato dagli utenti. La Proof of stake ha introdotto il concetto di finalità della transazione che, precedentemente, non esisteva. Nel Proof of Work, la capacità di annullare un blocco diventa esponenzialmente più difficile all'aumentare dei blocchi minati su una transazione, ma non raggiunge mai lo zero. In modalità Proof of stake, i blocchi sono raggruppati in epoche (intervalli di 6,4 minuti contenenti 32 possibili blocchi), su cui votano i validatori. Quando termina un'epoca, i validatori votano se considerare l'epoca 'giustificata'. Se i validatori acconsentono a giustificare l'epoca, questa viene finalizzata nell'epoca successiva. Annullare le transazioni finalizzate è economicamente non redditizio, in quanto richiederebbe di ottenere e bruciare oltre un terzo dell'ETH in staking totale. diff --git a/public/content/translations/it/roadmap/pectra/index.md b/public/content/translations/it/roadmap/pectra/index.md index de7d5b3a4c7..340cb96a5ef 100644 --- a/public/content/translations/it/roadmap/pectra/index.md +++ b/public/content/translations/it/roadmap/pectra/index.md @@ -6,7 +6,7 @@ lang: it # Pectra {#pectra} -L’aggiornamento della rete Petra è seguito a [Dencun](/roadmap/dencun/) e ha introdotto modifiche sia al livello di esecuzione che al livello di consenso di Ethereum. Il nome abbreviato Petra è una combinazione di Praga ed Elettra, che sono i rispettivi nomi delle modifiche alle specifiche del livello di esecuzione e del livello di consenso. Insieme, questi cambiamenti apportano numerosi miglioramenti agli utenti, agli sviluppatori e ai validatori di Ethereum. +L'aggiornamento della rete Pectra è seguito a [Dencun](/roadmap/dencun/) e ha introdotto modifiche sia al livello di esecuzione che al livello di consenso di Ethereum. Il nome abbreviato Pectra è una combinazione di Praga ed Electra, che sono i rispettivi nomi delle modifiche alle specifiche del livello di esecuzione e del livello di consenso. Insieme, questi cambiamenti apportano numerosi miglioramenti agli utenti, agli sviluppatori e ai validatori di Ethereum. Questo aggiornamento è stato attivato con successo sulla rete principale di Ethereum all'epoca `364032`, il **07-maggio-2025 alle 10:05 (UTC)**. @@ -36,7 +36,7 @@ L'attuale saldo effettivo del validatore è esattamente di 32 ETH. È l'importo [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) aumenta il saldo effettivo massimo possibile a 2048 ETH, il che significa che un singolo validatore può ora mettere in staking tra 32 e 2048 ETH. Invece di multipli di 32, gli staker possono ora scegliere un importo arbitrario di ETH da mettere in staking e ricevere ricompense per ogni 1 ETH al di sopra del minimo. Ad esempio, se il saldo di un validatore cresce con le sue ricompense a 33 ETH, l'ETH extra viene considerato parte del saldo effettivo e riceve ricompense. -Ma il vantaggio di un migliore sistema di ricompense per i validatori è solo una parte di questo miglioramento. Gli [staker](/staking/) che gestiscono più validatori possono ora aggregarli in uno solo, il che consente un'operatività più semplice e riduce il sovraccarico della rete. Poiché ogni validatore nella Bacon Chain invia una firma in ogni epoca, i requisiti di larghezza di banda aumentano con l’aumentare dei validatori e dell’elevato numero di firme da propagare. L'aggregazione dei validatori alleggerirà il carico sulla rete e aprirà nuove opzioni di scalabilità, mantenendo la stessa sicurezza economica. +Ma il vantaggio di un migliore sistema di ricompense per i validatori è solo una parte di questo miglioramento. Gli [staker](/staking/) che gestiscono più validatori possono ora aggregarli in uno solo, il che consente un'operatività più semplice e riduce il sovraccarico della rete. Poiché ogni validatore nella Beacon Chain invia una firma in ogni epoca, i requisiti di larghezza di banda aumentano con l’aumentare dei validatori e dell’elevato numero di firme da propagare. L'aggregazione dei validatori alleggerirà il carico sulla rete e aprirà nuove opzioni di scalabilità, mantenendo la stessa sicurezza economica. Leggi un approfondimento su maxEB [qui](/roadmap/pectra/maxeb/) @@ -50,7 +50,7 @@ Attualmente, la rete ha come obiettivo una media di 3 blob per blocco, con un ma Prima dell'introduzione dei [blob nell'aggiornamento Dencun](/roadmap/danksharding), gli L2 utilizzavano i [calldata](/developers/docs/data-availability/blockchain-data-storage-strategies/#calldata) per archiviare i propri dati su Ethereum. Sia i blob che i calldata influiscono sull'uso della larghezza di banda di Ethereum. Mentre la maggior parte dei blocchi utilizza solo una quantità minima di calldata, i blocchi con un elevato volume di dati che contengono anche molti blob possono essere dannosi per la rete p2p di Ethereum. -Per risolvere questo problema, [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) aumenta il prezzo dei calldata, ma solo per le transazioni con un elevato volume di dati. Questo limita la dimensione massima del blocco, fornisce un incentivo ai livelli 2 (L2) a utilizzare solo i lob e lascia oltre il 99% delle transazioni inalterate. +Per risolvere questo problema, [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623) aumenta il prezzo dei calldata, ma solo per le transazioni con un elevato volume di dati. Questo limita la dimensione massima del blocco, fornisce un incentivo ai livelli 2 (L2) a utilizzare solo i blob e lascia oltre il 99% delle transazioni inalterate. ### Uscite attivabili a livello di esecuzione {#7002} diff --git a/public/content/translations/it/staking/solo/index.md b/public/content/translations/it/staking/solo/index.md index 76c7d3b9af0..b5e20af1411 100644 --- a/public/content/translations/it/staking/solo/index.md +++ b/public/content/translations/it/staking/solo/index.md @@ -1,5 +1,5 @@ --- -title: Staking dometico dei tuoi ETH +title: Staking domestico dei tuoi ETH description: Una panoramica su come iniziare a mettere i tuoi ETH in staking domestico lang: it template: staking