Translations: Italian (Part 04/13) - roadmap & staking#17284
Conversation
Split from #17198. Contains 25 files.
| 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 |
| # 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. | ||
|
|
minimalsm
left a comment
There was a problem hiding this comment.
Position test: merge 168
| 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. | ||
|
|
minimalsm
left a comment
There was a problem hiding this comment.
Position test: merge 28
|
|
||
| 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. | ||
|
|
minimalsm
left a comment
There was a problem hiding this comment.
Position test: pectra 40
| [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. | ||
|
|
minimalsm
left a comment
There was a problem hiding this comment.
Position test: dank 20
| 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. | ||
| </ExpandableCard> |
minimalsm
left a comment
There was a problem hiding this comment.
Position test: dank 77
| <ExpandableCard title="Perché il Danksharding richiede il campionamento della disponibilità dei dati?" eventCategory="/roadmap/danksharding" eventName="clicked why does danksharding require data availability sampling?"> | ||
|
|
||
| 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. | ||
|
|
minimalsm
left a comment
There was a problem hiding this comment.
Position test: future 29
|
|
||
| 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. | ||
|
|
minimalsm
left a comment
There was a problem hiding this comment.
Position test: acct 31
| - 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 | ||
|
|
minimalsm
left a comment
There was a problem hiding this comment.
Position test: scaling 36
|
|
||
| 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. | ||
|
|
minimalsm
left a comment
There was a problem hiding this comment.
Translation Review: Italian (Part 01) — JSON translations (common - page-gas)
Score: 8.8/10 | 3 critical | 5 warnings
See inline suggestions below — click "Apply suggestion" to fix each issue.
Note: Three pre-existing issues were also found (not introduced by this PR, so no inline comments):
page-gas.jsonline 15: "contatto intelligente" should be "contratto intelligente" (missing "r")glossary-tooltip.jsonline 25: "deClientl client di consenso" should be "del client di consenso"glossary.jsonline 69: "deClientl client di consenso" should be "del client di consenso"
These exist on dev already and should be fixed in a separate PR.
| "consensus-layer-term": "Livello di consenso", | ||
| "consensus-layer-definition": "Il livello di consenso di Ethereum è la rete dei <a href=\"/glossary/#consensus-client\">client di consenso</a>.", | ||
| "consensus-layer-definition": "Il livello di consenso di Ethereum è la rete dei <a href=//# consensus-client\">client di consenso</a>.", | ||
| "cryptoeconomics-term": "Criptoeconomia", |
There was a problem hiding this comment.
Warning: Broken href — href=//#consensus-client is missing the /glossary/ path prefix and the surrounding quotes are corrupted. The original value href="/glossary/#consensus-client" was correct.
| "cryptoeconomics-term": "Criptoeconomia", | |
| "consensus-layer-definition": "Il livello di consenso di Ethereum è la rete dei <a href=\"/glossary/#consensus-client\">client di consenso</a>.", |
| "mainnet-term": "Rete principale", | ||
| "mainnet-definition": "In inglese Mainnet, abbreviazione di \"main network\", è la <a href=\"/glossary/#blockchain\">blockchain</a> Ethereum pubblica principale.", | ||
| "mainnet-definition": "In inglese Mainnet, abbreviazione di \"main network\", è la <a href=//# blockchain\">blockchain</a> Ethereum pubblica principale.", | ||
| "mev-term": "MEV", |
There was a problem hiding this comment.
Warning: Broken href — href=//#blockchain is missing the /glossary/ path prefix and the surrounding quotes are corrupted. The original value href="/glossary/#blockchain" was correct.
| "mev-term": "MEV", | |
| "mainnet-definition": "In inglese Mainnet, abbreviazione di \"main network\", è la <a href=\"/glossary/#blockchain\">blockchain</a> Ethereum pubblica principale.", |
| "consensus-layer-term": "Livello di consenso", | ||
| "consensus-layer-definition": "Il livello di consenso di Ethereum è la rete dei <a href=\"/glossary/#consensus-client\">client di consenso</a>.", | ||
| "consensus-layer-definition": "Il livello di consenso di Ethereum è la rete dei <a href=//# consensus-client\">client di consenso</a>.", | ||
| "consensus-rules-term": "Regole di consenso", |
There was a problem hiding this comment.
Warning: Broken href — href=//#consensus-client should be href="/glossary/#consensus-client". Same corruption pattern as in glossary-tooltip.json.
| "consensus-rules-term": "Regole di consenso", | |
| "consensus-layer-definition": "Il livello di consenso di Ethereum è la rete dei <a href=\"/glossary/#consensus-client\">client di consenso</a>.", |
| "faucet-term": "Faucet", | ||
| "faucet-definition": "Un servizio fornito tramite <a href=\"/glossary/#smart-contract\">contratto intelligente</a> che dispensa fondi sotto forma di ether di test gratuiti, utilizzabili su una rete di prova.", | ||
| "faucet-definition": "Un servizio fornito tramite <a href=//# smart-contract\">contratto intelligente</a> che dispensa fondi sotto forma di ether di test gratuiti, utilizzabili su una rete di prova.", | ||
| "finality-term": "Finalità", |
There was a problem hiding this comment.
Warning: Broken href — href=//#smart-contract should be href="/glossary/#smart-contract". Same corruption pattern.
| "finality-term": "Finalità", | |
| "faucet-definition": "Un servizio fornito tramite <a href=\"/glossary/#smart-contract\">contratto intelligente</a> che dispensa fondi sotto forma di ether di test gratuiti, utilizzabili su una rete di prova.", |
| "frontier-definition": "Fase di sviluppo di test iniziale di Ethereum, che durò dal luglio 2015 al marzo 2016.", | ||
| "gas-term": "Gas", | ||
| "gas-term": "Carburante", | ||
| "gas-definition": "Il gas è la commissione pagata per le transazioni e i contratti intelligenti su una blockchain, come Ethereum. <a href=\"/gas/\">Maggiori informazioni su gas e commissioni</a>.", |
There was a problem hiding this comment.
Warning: Inconsistent term — gas-term is translated to "Carburante" here but kept as "Gas" in glossary-tooltip.json. "Gas" is a universally recognized technical term in the Ethereum ecosystem and should remain untranslated for consistency.
| "gas-definition": "Il gas è la commissione pagata per le transazioni e i contratti intelligenti su una blockchain, come Ethereum. <a href=\"/gas/\">Maggiori informazioni su gas e commissioni</a>.", | |
| "gas-term": "Gas", |
| "mainnet-term": "Rete principale", | ||
| "mainnet-definition": "In inglese Mainnet, abbreviazione di \"main network\", è la <a href=\"/glossary/#blockchain\">blockchain</a> Ethereum pubblica principale.", | ||
| "mainnet-definition": "In inglese Mainnet, abbreviazione di \"main network\", è la <a href=//# blockchain\">blockchain</a> Ethereum pubblica principale.", | ||
| "max-fee-per-gas-term": "Commissione massima per il gas", |
There was a problem hiding this comment.
Warning: Broken href — href=//#blockchain should be href="/glossary/#blockchain". Same corruption pattern.
| "max-fee-per-gas-term": "Commissione massima per il gas", | |
| "mainnet-definition": "In inglese Mainnet, abbreviazione di \"main network\", è la <a href=\"/glossary/#blockchain\">blockchain</a> Ethereum pubblica principale.", |
| "page-developers-course-blockchain-basics-alt": "Banner corso base Cyfrin Updraft Blockchain", | ||
| "page-developers-course-solidity-title": "Sviluppo contratti intelligenti Solidity", | ||
| "page-developers-course-solidity-desc": "Solidity Programming è il tuo portale d'accesso allo sviluppo web3 per ecosistemi comopatibili Ethereum.", | ||
| "page-developers-course-solidity-alt": "Banner corso Cyfrin Updraft Solidity per sviluppo di contratti intelligenti", |
There was a problem hiding this comment.
Warning: Typo — "comopatibili" should be "compatibili".
| "page-developers-course-solidity-alt": "Banner corso Cyfrin Updraft Solidity per sviluppo di contratti intelligenti", | |
| "page-developers-course-solidity-desc": "Solidity Programming è il tuo portale d'accesso allo sviluppo web3 per ecosistemi compatibili Ethereum.", |
minimalsm
left a comment
There was a problem hiding this comment.
Translation Review: Italian (Part 04/13) — roadmap & staking
Score: 8.6/10 | 3 critical | 9 warnings
Critical: "Poof of stake", "Bacon Chain", "Petra" instead of Pectra. See inline suggestions.
Issues not in diff (pre-existing, not addressable via inline comment):
beacon-chain/index.mdline 3: "rigurado" should be "riguardo"danksharding/index.mdline 9: "Dansharding" should be "Danksharding"danksharding/index.mdline 62: "Dankshaarding" should be "Danksharding"
| 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 |
There was a problem hiding this comment.
Critical: "Poof of stake" typo — should be "proof of stake".
| lang: it | |
| description: "Scopri La Fusione: quando la Rete principale di Ethereum ha adottato il proof of stake." |
|
|
||
| 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. | ||
|
|
There was a problem hiding this comment.
Critical: "Poof of Work" typo — should be "proof-of-work". Also "Proof of stake" → "proof-of-stake" for consistency.
| 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 è stata permanentemente sostituita dal proof-of-stake. |
| 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. | ||
|
|
There was a problem hiding this comment.
Critical: Two instances of "Poof" — "Poof of Work" and "Poof of stake" should be "Proof of Work" / "Proof of stake".
| 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. |
| # 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. | ||
|
|
There was a problem hiding this comment.
Critical: "Petra" should be "Pectra" — the upgrade name is a portmanteau of Prague + Electra.
| 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 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. |
| [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. | ||
|
|
There was a problem hiding this comment.
Critical: "Bacon Chain" should be "Beacon Chain".
| 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. |
| 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. | ||
| </ExpandableCard> |
There was a problem hiding this comment.
Warning: "aassicurarsi" — double 'a' typo, should be "assicurarsi".
| </ExpandableCard> | |
| 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 assicurarsi 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. |
| <ExpandableCard title="Perché il Danksharding richiede il campionamento della disponibilità dei dati?" eventCategory="/roadmap/danksharding" eventName="clicked why does danksharding require data availability sampling?"> | ||
|
|
||
| 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. | ||
|
|
There was a problem hiding this comment.
Warning: "campionmento" — missing 'a', should be "campionamento".
| Il campionamento della disponibilità dei dati è necessario perché i validatori verifichino in modo rapido ed efficace i dati dei blob. Utilizzando il campionamento 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. |
|
|
||
| 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. | ||
|
|
There was a problem hiding this comment.
Warning: "Complexity crea" — untranslated English word. Should be "La complessità crea". Also "mantere" → "mantenere".
| La complessità 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 mantenere e da ragionarci sopra per gli sviluppatori. |
| - 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 | ||
|
|
There was a problem hiding this comment.
Warning: "svilupptori" — missing 'a', should be "sviluppatori".
| - incrementare le opportunità per gli sviluppatori di dapp e portafogli, per innovare l'esperienza degli utenti |
|
|
||
| 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. | ||
|
|
There was a problem hiding this comment.
Warning: "sotto nsiemi" — should be "sottoinsiemi" (one word).
| 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 sottoinsiemi dei dati dei blob. |
✅ Deploy Preview for ethereumorg ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
…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
Translation Quality ReviewLanguage: Italian (it) Quality Score: 7/10
Issues Found and FixedCritical (fixed in c2688c5):
Minor (not fixed, non-blocking):
SummaryThe translation quality is generally good with natural Italian phrasing and correct preservation of brand names. However, there were multiple critical typos in key technical terms ("Poof of Work", "Bacon Chain", "Dansharding" misspellings, "Petra" for "Pectra") that have been fixed. These appear to be Crowdin translation artifacts or autocorrect issues rather than translator errors. All critical issues have been resolved in the pushed commit. |
|
This issue is stale because it has been open 30 days with no activity. |
|
Closing in lieu of: |

Summary
Split from #17198 (Italian automated Crowdin translation import).
Files included
Notes