From 7a551161b39f44d19e12afd700dae60ad04dc91b Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Thu, 12 Feb 2026 18:31:07 +0000 Subject: [PATCH 1/2] translations: Italian part 10/13 - docs: data, networking, design & APIs Split from #17198. Contains 20 files. --- .../it/developers/docs/apis/backend/index.md | 98 +-- .../developers/docs/apis/javascript/index.md | 111 ++-- .../it/developers/docs/apis/json-rpc/index.md | 600 +++++++++++------- .../block-explorers/index.md | 39 +- .../docs/data-and-analytics/index.md | 63 +- .../index.md | 4 +- .../docs/data-availability/index.md | 70 +- .../data-structures-and-encoding/index.md | 10 +- .../patricia-merkle-trie/index.md | 183 +++--- .../data-structures-and-encoding/rlp/index.md | 48 +- .../data-structures-and-encoding/ssz/index.md | 45 +- .../web3-secret-storage/index.md | 195 ++++++ .../dex-design-best-practice/index.md | 2 +- .../heuristics-for-web3/index.md | 4 +- .../it/developers/docs/design-and-ux/index.md | 113 ++-- .../it/developers/docs/evm/index.md | 60 +- .../it/developers/docs/evm/opcodes/index.md | 325 +++++----- .../developers/docs/networking-layer/index.md | 74 ++- .../network-addresses/index.md | 10 +- .../networking-layer/portal-network/index.md | 26 +- 20 files changed, 1217 insertions(+), 863 deletions(-) create mode 100644 public/content/translations/it/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md diff --git a/public/content/translations/it/developers/docs/apis/backend/index.md b/public/content/translations/it/developers/docs/apis/backend/index.md index 29a89ab7e8f..54bbdd65ad6 100644 --- a/public/content/translations/it/developers/docs/apis/backend/index.md +++ b/public/content/translations/it/developers/docs/apis/backend/index.md @@ -4,91 +4,96 @@ description: Introduzione alle API client di Ethereum che permettono l'interazio lang: it --- -Per interagire con la blockchain Ethereum (ad esempio leggere i dati della blockchain e/o inviare transazioni alla rete), un'applicazione software deve connettersi a un nodo Ethereum. +Per interagire con la blockchain di Ethereum (ad esempio, leggere i dati della blockchain e/o inviare transazioni alla rete), un'applicazione software deve connettersi a un nodo Ethereum. -A tale scopo, ogni client di Ethereum implementa la specifica [JSON-RPC](/developers/docs/apis/json-rpc/), così che esista una serie uniforme di [metodi](/developers/docs/apis/json-rpc/#json-rpc-methods) a cui le applicazioni possano affidarsi. +A tale scopo, ogni client di Ethereum implementa la specifica [JSON-RPC](/developers/docs/apis/json-rpc/), in modo che esista una serie uniforme di [metodi](/developers/docs/apis/json-rpc/#json-rpc-methods) a cui le applicazioni possano affidarsi. Se desideri utilizzare un linguaggio di programmazione specifico per connetterti a un nodo Ethereum, sviluppa una soluzione personalizzata, ma tieni presente che ci sono già molte librerie all'interno dell'ecosistema che possono facilitarti la vita. Con queste librerie, gli sviluppatori possono scrivere metodi a una riga intuitivi per inizializzare le richieste RPC JSON (under the hood) che interagiscono con Ethereum. ## Prerequisiti {#prerequisites} -Potrebbe essere utile comprendere meglio lo [stack di Ethereum](/developers/docs/ethereum-stack/) e[i client di Ethereum](/developers/docs/nodes-and-clients/). +Potrebbe essere utile comprendere lo [stack di Ethereum](/developers/docs/ethereum-stack/) e i [client di Ethereum](/developers/docs/nodes-and-clients/). ## Perché usare una libreria? {#why-use-a-library} -Queste librerie eliminano buona parte della complessità legata al dover interagire direttamente con un nodo Ethereum. Forniscono inoltre funzioni di utilità (ad esempio conversione da ETH a Gwei) in modo da ridurre il tempo necessario per districarsi tra le complessità dei client Ethereum e potersi concentrare sulle funzionalità uniche dell'applicazione. +Queste librerie eliminano buona parte della complessità legata al dover interagire direttamente con un nodo Ethereum. Forniscono anche funzioni di utilità (ad es. la conversione di ETH in Gwei), così che uno sviluppatore possa dedicare meno tempo alle complessità dei client di Ethereum e più tempo alle funzionalità uniche della propria applicazione. ## Librerie disponibili {#available-libraries} -### Servizi per infrastrutture e nodi {#infrastructure-and-node-services} +### Infrastruttura e servizi per i nodi {#infrastructure-and-node-services} -**Alchemy -** **_Piattaforma di sviluppo Ethereum_** +**Alchemy -** **_Piattaforma di sviluppo di Ethereum._** - [alchemy.com](https://www.alchemy.com/) -- [Documentazione](https://docs.alchemy.com/) +- [Documentazione](https://www.alchemy.com/docs/) - [GitHub](https://github.com/alchemyplatform) - [Discord](https://discord.com/invite/alchemyplatform) -**All That Node -** **_Node-as-a-Service._** +**All That Node -** **_Nodo come servizio._** - [All That Node.com](https://www.allthatnode.com/) - [Documentazione](https://docs.allthatnode.com) - [Discord](https://discord.gg/GmcdVEUbJM) -**Blast by Bware Labs -** **_API decentralizzate per la rete principale e le reti di prova di Ethereum._** +**Blast by Bware Labs -** **_API decentralizzate per la Rete Principale di Ethereum e le reti di test._** - [blastapi.io](https://blastapi.io/) - [Documentazione](https://docs.blastapi.io) -- [Discord](https://discord.gg/bwarelabs) +- [Discord](https://discord.gg/SaRqmRUjjQ) -**BlockPi -** **_Fornire servizi RPC più efficienti e veloci_** +**BlockPi -** **_Fornisce servizi RPC più efficienti e veloci_** - [blockpi.io](https://blockpi.io/) - [Documentazione](https://docs.blockpi.io/) - [GitHub](https://github.com/BlockPILabs) - [Discord](https://discord.com/invite/xTvGVrGVZv) -**Gateway Ethereum Cloudflare** +**Gateway Ethereum di Cloudflare.** - [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/) **Etherscan - Esploratore di Blocchi e API di transazione** + - [Documentazione](https://docs.etherscan.io/) -**GetBlock-** **_Blockchain-as-a-service per lo sviluppo Web3_** +**Blockscout - Esploratore di blocchi open source** + +- [Documentazione](https://docs.blockscout.com/) + +**GetBlock -** **_Blockchain come servizio per lo sviluppo Web3_** - [GetBlock.io](https://getblock.io/) -- [Documentazione](https://getblock.io/docs/) +- [Documentazione](https://docs.getblock.io/) -**Infura -** **_L'API Ethereum come servizio_** +**Infura -** **_L'API di Ethereum come servizio._** - [infura.io](https://infura.io) - [Documentazione](https://docs.infura.io/api) - [GitHub](https://github.com/INFURA) -**Node RPC - _Conveniente fornitore di RPC-JSON dell'EVM_** +**Node RPC - _Fornitore EVM JSON-RPC conveniente_** - [noderpc.xyz](https://www.noderpc.xyz/) - [Documentazione](https://docs.noderpc.xyz/node-rpc) -**NOWNodes - _Nodi completi ed esploratori di blocchi._** +**NOWNodes -** **_Nodi completi ed esploratori di blocchi._** - [NOWNodes.io](https://nownodes.io/) -- [Documentazione](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro) +- [Documentazione](https://nownodes.gitbook.io/documentation) -**QuickNode -** **_Infrastruttura della Blockchain come servizio._** +**QuickNode -** **_Infrastruttura blockchain come servizio._** - [quicknode.com](https://quicknode.com) - [Documentazione](https://www.quicknode.com/docs/welcome) - [Discord](https://discord.gg/quicknode) -**Rivet -** **_API di Ethereum ed Ethereum Classic come servizio, supportate da software open source._** +**Rivet -** **_API di Ethereum ed Ethereum Classic come servizio, basate su software open source._** - [rivet.cloud](https://rivet.cloud) - [Documentazione](https://rivet.cloud/docs/) - [GitHub](https://github.com/openrelayxyz/ethercattle-deployment) -**Zmok -** **_Nodi di Ethereum orientati alla velocità come l'API JSON-RPC/WebSockets._** +**Zmok -** **_Nodi Ethereum orientati alla velocità come API JSON-RPC/WebSockets._** - [zmok.io](https://zmok.io/) - [GitHub](https://github.com/zmok-io) @@ -103,61 +108,61 @@ Queste librerie eliminano buona parte della complessità legata al dover interag - [Esempi](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) - [Discord](https://discord.gg/rx35NzQGSb) -**Nethereum -** **_Una libreria di integrazione .NET open source per la blockchain_** +**Nethereum -** **_Una libreria di integrazione .NET open source per la blockchain._** - [GitHub](https://github.com/Nethereum/Nethereum) - [Documentazione](http://docs.nethereum.com/en/latest/) - [Discord](https://discord.com/invite/jQPrR58FxX) -**Strumenti Python -** **_Diverse librerie per interagire con Ethereum tramite Python_** +**Python Tooling -** **_Varietà di librerie per l'interazione con Ethereum tramite Python._** -- [py.ethereum.org](https://python.ethereum.org/) +- [py.ethereum.org](https://snakecharmers.ethereum.org/) - [web3.py GitHub](https://github.com/ethereum/web3.py) - [web3.py Chat](https://gitter.im/ethereum/web3.py) -**QuikNode -** **_La piattaforma definitiva per sviluppatori di blockchain_** +**Tatum -** **_La piattaforma di sviluppo blockchain definitiva._** - [Tatum](https://tatum.io/) - [GitHub](https://github.com/tatumio/) - [Documentazione](https://docs.tatum.io/) - [Discord](https://discord.gg/EDmW3kjTC9) -**web3j -** **_Libreria di integrazione di Java/Android/Kotlin/Scala per Ethereum_** +**web3j -** **_Una libreria di integrazione Java/Android/Kotlin/Scala per Ethereum._** - [GitHub](https://github.com/web3j/web3j) -- [Docs](https://docs.web3j.io/) +- [Documentazione](https://docs.web3j.io/) - [Gitter](https://gitter.im/web3j/web3j) -### Servizi della blockchain {#blockchain-services} +### Servizi blockchain {#blockchain-services} -**BlockCypher -** **_API Web Ethereum._** +**BlockCypher -** **_API web di Ethereum._** - [blockcypher.com](https://www.blockcypher.com/) - [Documentazione](https://www.blockcypher.com/dev/ethereum/) -**Chainbase -** **_Infrastruttura dati web3 tutto in uno per Ethereum._** +**Chainbase -** **_Infrastruttura dati Web3 tutto in uno per Ethereum._** - [chainbase.com](https://chainbase.com/) - [Documentazione](https://docs.chainbase.com/) - [Discord](https://discord.gg/Wx6qpqz4AF) -**Catainstack -** **_Nodi di Ethereum elastici e dedicati come servizio_** +**Chainstack -** **_Nodi Ethereum elastici e dedicati come servizio._** - [chainstack.com](https://chainstack.com) -- [Documentazione](https://docs.chainbase.com/docs) -- [Riferimento all'API di Ethereum](https://docs.chainstack.com/reference/ethereum-getting-started) +- [Documentazione](https://docs.chainstack.com/) +- [Riferimento API di Ethereum](https://docs.chainstack.com/reference/ethereum-getting-started) -**Nodo cloud di Coinbase-** **_API per l'infrastruttura della Blockchain._** +**Coinbase Cloud Node -** **_API di infrastruttura blockchain._** -- [Nodo in cloud di Coinbase](https://www.coinbase.com/cloud) -- [Documentazione](https://docs.cloud.coinbase.com/) +- [Coinbase Cloud Node](https://www.coinbase.com/developer-platform) +- [Documentazione](https://docs.cdp.coinbase.com/) -**DataHub di Figment -** **_Servizi API Web3 con la Rete principale e le reti di prova di Ethereum._** +**DataHub by Figment -** **_Servizi API Web3 con la Rete Principale di Ethereum e le reti di test._** - [DataHub](https://www.figment.io/) - [Documentazione](https://docs.figment.io/) -**Moralis**: **_Fornitore di API EVM di livello enterprise._** +**Moralis -** **_Fornitore di API EVM di livello enterprise._** - [moralis.io](https://moralis.io) - [Documentazione](https://docs.moralis.io/) @@ -165,7 +170,7 @@ Queste librerie eliminano buona parte della complessità legata al dover interag - [Discord](https://moralis.io/joindiscord/) - [Forum](https://forum.moralis.io/) -**NFTPort -** **_Dati di Ethereum e API di Mint._** +**NFTPort -** **_API di dati e minting di Ethereum._** - [nftport.xyz](https://www.nftport.xyz/) - [Documentazione](https://docs.nftport.xyz/) @@ -178,30 +183,29 @@ Queste librerie eliminano buona parte della complessità legata al dover interag - [Documentazione](https://services.tokenview.io/docs?type=api) - [GitHub](https://github.com/Tokenview) -**Watchdata -** **_Accesso semplice e affidabile delle API alla blockchain di Ethereum._** +**Watchdata -** **_Fornisce un accesso API semplice e affidabile alla blockchain di Ethereum._** - [Watchdata](https://watchdata.io/) - [Documentazione](https://docs.watchdata.io/) - [Discord](https://discord.com/invite/TZRJbZ6bdn) -**Covalent -** **_API della blockchain arricchite per oltre 200 catene._** +**Covalent -** **_API blockchain arricchite per oltre 200 catene._** - [covalenthq.com](https://www.covalenthq.com/) - [Documentazione](https://www.covalenthq.com/docs/api/) - [GitHub](https://github.com/covalenthq) - [Discord](https://www.covalenthq.com/discord/) - ## Letture consigliate {#further-reading} _Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_ ## Argomenti correlati {#related-topics} -- [ Nodi e client](/developers/docs/nodes-and-clients/) -- [Quadri di sviluppo](/developers/docs/frameworks/) +- [Nodi e client](/developers/docs/nodes-and-clients/) +- [Framework di sviluppo](/developers/docs/frameworks/) -## Tutorial correlati {#related-tutorials} +## Guide correlate {#related-tutorials} -- [Set up Web3js to use the Ethereum blockchain in JavaScript](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Istruzioni per impostare web3.js in un progetto._ -- [Calling a Smart Contract from JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Usando il token DAI, impara come funzionano i contratti di chiamata con JavaScript_ +- [Configurare Web3js per usare la blockchain di Ethereum in JavaScript](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Istruzioni per configurare web3.js nel proprio progetto._ +- [Chiamare un contratto intelligente da JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Usando il token DAI, scopri come chiamare le funzioni dei contratti usando JavaScript._ diff --git a/public/content/translations/it/developers/docs/apis/javascript/index.md b/public/content/translations/it/developers/docs/apis/javascript/index.md index 8a53b2063f5..35dbdc1c79a 100644 --- a/public/content/translations/it/developers/docs/apis/javascript/index.md +++ b/public/content/translations/it/developers/docs/apis/javascript/index.md @@ -6,35 +6,37 @@ lang: it Per interagire con la blockchain Ethereum (ad esempio leggere i dati della blockchain e/o inviare transazioni alla rete), una web app deve connettersi a un nodo Ethereum. -Per questo scopo, ogni client di Ethereum implementa la specifica [JSON-RPC](/developers/docs/apis/json-rpc/), quindi esiste una serie uniforme di [metodi](/developers/docs/apis/json-rpc/#json-rpc-methods) su cui possono basarsi le applicazioni. +A questo scopo, ogni client Ethereum implementa la specifica [JSON-RPC](/developers/docs/apis/json-rpc/), così che ci sia un set uniforme di [metodi](/developers/docs/apis/json-rpc/#json-rpc-methods) a cui le applicazioni possono fare riferimento. Se desideri utilizzare JavaScript per connetterti a un nodo Ethereum, puoi usare Javascript vanilla, ma tieni presente che ci sono già molte librerie all'interno dell'ecosistema che possono facilitarti la vita. Con queste librerie, gli sviluppatori possono scrivere metodi a una riga intuitivi per inizializzare le richieste RPC JSON (under the hood) che interagiscono con Ethereum. -Si noti che, a partire da [La Fusione](/roadmap/merge/), per eseguire un nodo occorrono due elementi di software di Ethereum connessi (un client di esecuzione e un client di consenso). Assicurati che il tuo nodo includa sia un client di esecuzione che un client di consenso. Se il tuo nodo non si trova sulla tua macchina locale (ad es. se è in esecuzione su un'istanza AWS), occorrerà aggiornare di conseguenza gli indirizzi IP nel tutorial. Per ulteriori informazioni, consulta la nostra pagina sull'[esecuzione di un nodo](/developers/docs/nodes-and-clients/run-a-node/). +Si noti che, a partire da [La Fusione](/roadmap/merge/), per eseguire un nodo occorrono due componenti software di Ethereum connessi: un client di esecuzione e un client di consenso. Assicurati che il tuo nodo includa sia un client di esecuzione che un client di consenso. Se il tuo nodo non si trova sulla tua macchina locale (ad es. se è in esecuzione su un'istanza AWS), occorrerà aggiornare di conseguenza gli indirizzi IP nel tutorial. Per maggiori informazioni, consulta la nostra pagina su come [eseguire un nodo](/developers/docs/nodes-and-clients/run-a-node/). ## Prerequisiti {#prerequisites} -Potrebbe essere utile conoscere non solo Javascript ma anche lo [stack di Ethereum](/developers/docs/ethereum-stack/) e [i client di Ethereum](/developers/docs/nodes-and-clients/). +Oltre a comprendere JavaScript, potrebbe essere utile comprendere lo [stack di Ethereum](/developers/docs/ethereum-stack/) e i [client di Ethereum](/developers/docs/nodes-and-clients/). ## Perché usare una libreria? {#why-use-a-library} -Queste librerie eliminano buona parte della complessità legata al dover interagire direttamente con un nodo Ethereum. Assicurano inoltre funzioni di utilità (ad esempio la conversione da ETH a Gwei) per fare in modo che gli sviluppatori debbano dedidare meno tempo alle complessità dei client Ethereum e più tempo alle funzionalità specifiche dell'applicazione. +Queste librerie eliminano buona parte della complessità legata al dover interagire direttamente con un nodo Ethereum. Forniscono anche funzioni di utilità (ad es. la conversione di ETH in Gwei), così che uno sviluppatore possa dedicare meno tempo alle complessità dei client di Ethereum e più tempo alle funzionalità uniche della propria applicazione. -## Caratteristiche della libreria {#library-features} +## Funzionalità della libreria {#library-features} -### Connettersi ai nodi Ethereum {#connect-to-ethereum-nodes} +### Connettersi ai nodi di Ethereum {#connect-to-ethereum-nodes} Utilizzando i provider, queste librerie consentono di connettersi a Ethereum e leggerne i dati, tramite JSON-RPC, INFURA, Etherscan, Alchemy o MetaMask. +> **Avvertenza:** Web3.js è stato archiviato il 4 marzo 2025. [Leggi l'annuncio](https://blog.chainsafe.io/web3-js-sunset/). Prendi in considerazione l'utilizzo di librerie alternative come [ethers.js](https://ethers.org) o [viem](https://viem.sh) per i nuovi progetti. + **Esempio da Ethers** ```js -// Un BrowserProvider avvolge un fornitore Web3 standard, ciò -// che MetaMask inietta come window.ethereum in ogni pagina +// Un BrowserProvider avvolge un provider Web3 standard, che è +// ciò che MetaMask inietta come window.ethereum in ogni pagina const provider = new ethers.BrowserProvider(window.ethereum) -// Anche il plugin di MetaMask consente la firma delle transazioni per -// inviare ether e pagare per cambiare lo stato nella blockchain. +// Il plug-in di MetaMask consente anche di firmare le transazioni per +// inviare ether e pagare per cambiare lo stato all'interno della blockchain. // Per questo, abbiamo bisogno del firmatario dell'account... const signer = provider.getSigner() ``` @@ -72,12 +74,12 @@ Una volta eseguita la configurazione, sarà possibile interrogare la blockchain ### Funzionalità del portafoglio {#wallet-functionality} -Queste librerie offrono le funzionalità per creare portafogli, gestire chiavi e firmare transazioni. +Queste librerie offrono funzionalità per creare portafogli, gestire chiavi e firmare transazioni. Ecco un esempio da Ethers ```js -// Creazione di un'istanza di portafoglio da un mnemonico... +// Crea un'istanza di portafoglio da una mnemonica... mnemonic = "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol" walletMnemonic = Wallet.fromPhrase(mnemonic) @@ -88,11 +90,11 @@ walletPrivateKey = new Wallet(walletMnemonic.privateKey) walletMnemonic.address === walletPrivateKey.address // true -// L'indirizzo come una Promise per l'API del Firmatario +// L'indirizzo come Promise per l'API Signer walletMnemonic.getAddress() // { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' } -// L'indirizzo di un Portafoglio è anche disponibile sincronicamente +// Un indirizzo del portafoglio è disponibile anche in modo sincrono walletMnemonic.address // '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' @@ -110,12 +112,12 @@ walletMnemonic.mnemonic // phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol' // } -// Nota: Un portafoglio creato con una chiave privata non -// dispone di una frase mnemonica (la derivazione la previene) +// Nota: un portafoglio creato con una chiave privata non +// dispone di una mnemonica (la derivazione lo impedisce) walletPrivateKey.mnemonic // null -// Firmare un messaggio +// Firma di un messaggio walletMnemonic.signMessage("Hello World") // { Promise: '0x14280e5885a19f60e536de50097e96e3738c7acae4e9e62d67272d794b8127d31c03d9cd59781d4ee31fb4e1b893bd9b020ec67dfa65cfb51e2bdadbb1de26d91c' } @@ -124,25 +126,25 @@ tx = { value: utils.parseEther("1.0"), } -// Firmare una transazione +// Firma di una transazione walletMnemonic.signTransaction(tx) // { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' } // Il metodo connect restituisce una nuova istanza del -// Portafoglio connesso a un fornitore +// portafoglio connesso a un provider wallet = walletMnemonic.connect(provider) -// Interrogare la rete +// Interrogazione della rete wallet.getBalance() // { Promise: { BigNumber: "42" } } wallet.getTransactionCount() // { Promise: 0 } -// Inviare ether +// Invio di ether wallet.sendTransaction(tx) ``` -[Consulta la documentazione completa](https://docs.ethers.io/v5/api/signer/#Wallet) +[Leggi la documentazione completa](https://docs.ethers.io/v5/api/signer/#Wallet) Una volta eseguita la configurazione, sarà possibile: @@ -151,7 +153,7 @@ Una volta eseguita la configurazione, sarà possibile: - firmare transazioni - e molto altro... -### Interagire con le funzioni dei contratti intelligenti {#interact-with-smart-contract-functions} +### Interagire con le funzioni di un contratto intelligente {#interact-with-smart-contract-functions} Le librerie del client di JavaScript consentono alla tua applicazione di chiamare le funzioni dei contratti intelligenti, leggendo l'Interfaccia Binaria dell'Applicazione (ABI) di un contratto compilato. @@ -164,11 +166,11 @@ contract Test { uint a; address d = 0x12345678901234567890123456789012; - function Test(uint testInt) { a = testInt;} + constructor(uint testInt) { a = testInt;} event Event(uint indexed b, bytes32 c); - evento Event2(uint indexed b, bytes32 c); + event Event2(uint indexed b, bytes32 c); function foo(uint b, bytes32 c) returns(address) { Event(b, c); @@ -232,59 +234,56 @@ ethers.utils.formatEther(balance) // '2.337132817842795605' ``` -- [Funzioni di utilità Web3js](https://docs.web3js.org/api/web3-utils) -- [Funzioni utilità ethers](https://docs.ethers.io/v5/api/utils/) +- [Funzioni di utilità di Web3js](https://docs.web3js.org/api/web3-utils) +- [Funzioni di utilità di Ethers](https://docs.ethers.org/v6/api/utils/) ## Librerie disponibili {#available-libraries} -**Web3.js -** **_API JavaScript Ethereum_** +**Web3.js -** **_API JavaScript di Ethereum._** -- [Documentazione](https://docs.web3js.org/) -- [GitHub](https://github.com/ethereum/web3.js/) +- [Documentazione](https://docs.web3js.org) +- [GitHub](https://github.com/ethereum/web3.js) -**Ethers.js -** **_Implementazione completa del portafoglio Ethereum e delle utility in JavaScript e TypeScript_** +**Ethers.js -** **_Implementazione completa del portafoglio Ethereum e delle utility in JavaScript e TypeScript._** -- [Documentazione](https://docs.ethers.io/) -- [GitHub](https://github.com/ethers-io/ethers.js/) +- [Home di Ethers.js](https://ethers.org/) +- [Documentazione](https://docs.ethers.io) +- [GitHub](https://github.com/ethers-io/ethers.js) -**The Graph -** **_Protocollo per indicizzare i dati Ethereum e IPFS ed eseguire query con GraphQL_** +**The Graph -** **_Un protocollo per indicizzare i dati di Ethereum e IPFS ed eseguire query con GraphQL._** -- [Graph](https://thegraph.com/) -- [Graph Explorer](https://thegraph.com/explorer/) -- [Documentazione](https://thegraph.com/docs/) -- [GitHub](https://github.com/graphprotocol/) +- [The Graph](https://thegraph.com) +- [Graph Explorer](https://thegraph.com/explorer) +- [Documentazione](https://thegraph.com/docs) +- [GitHub](https://github.com/graphprotocol) - [Discord](https://thegraph.com/discord) -**light.js -** **_Libreria JavaScript reattiva di alto livello, ottimizzata per i light client_** - -- [GitHub](https://github.com/openethereum/js-libs/tree/master/packages/light.js) - -**Alchemyweb3 -** **_Wrapper per Web3.js con nuovi tentativi automatici e API migliorate_** - -- [Documentazione](https://docs.alchemy.com/reference/api-overview) -- [GitHub](https://github.com/alchemyplatform/alchemy-web3) +**Alchemy SDK -** **_Wrapper per Ethers.js con API avanzate._** -**Alchemy NFT API -** **_API per recuperare i dati degli NFT, inclusi proprietà, attributi dei metadati e altro_** - -- [Documentazione](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) -- [GitHub](https://github.com/alchemyplatform/alchemy-web3) +- [Documentazione](https://www.alchemy.com/docs) +- [GitHub](https://github.com/alchemyplatform/alchemy-sdk-js) **viem -** **_Interfaccia TypeScript per Ethereum._** - [Documentazione](https://viem.sh) - [GitHub](https://github.com/wagmi-dev/viem) +**Drift -** **_Meta-libreria TypeScript con caching, hook e mock di test integrati._** + +- [Documentazione](https://ryangoree.github.io/drift/) +- [GitHub](https://github.com/ryangoree/drift/) + ## Letture consigliate {#further-reading} _Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_ ## Argomenti correlati {#related-topics} -- [ Nodi e client](/developers/docs/nodes-and-clients/) -- [Quadri di sviluppo](/developers/docs/frameworks/) +- [Nodi e client](/developers/docs/nodes-and-clients/) +- [Framework di sviluppo](/developers/docs/frameworks/) -## Tutorial correlati {#related-tutorials} +## Guide correlate {#related-tutorials} -- [Set up Web3js to use the Ethereum blockchain in JavaScript](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Istruzioni per impostare web3.js in un progetto._ -- [Calling a Smart Contract from JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Usando il token DAI, impara come funzionano i contratti di chiamata con JavaScript_ -- [Sending transactions using web3 and Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– Istruzioni passo passo per l'invio di transazioni dal backend._ +- [Configurare Web3js per usare la blockchain di Ethereum in JavaScript](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Istruzioni per configurare web3.js nel proprio progetto._ +- [Chiamare un contratto intelligente da JavaScript](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– Usando il token DAI, scopri come chiamare le funzioni dei contratti usando JavaScript._ +- [Invio di transazioni con web3 e Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– Procedura dettagliata per l'invio di transazioni dal backend._ 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..3ab3c8b2397 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 @@ -6,27 +6,27 @@ lang: it Affinché un'applicazione software interagisca con la blockchain di Ethereum, leggendo i dati della blockchain o inviando transazioni alla rete, deve connettersi a un nodo di Ethereum. -Per questo scopo, ogni [client di Ethereum](/developers/docs/nodes-and-clients/#execution-clients) implementa una [specifica JSON-RPC](https://github.com/ethereum/execution-apis), quindi esiste un insieme uniforme di metodi cui le applicazioni possono affidarsi, indipendentemente dagli specifici nodi o implementazioni del client. +A questo scopo, ogni [client Ethereum](/developers/docs/nodes-and-clients/#execution-clients) implementa una [specifica JSON-RPC](https://github.com/ethereum/execution-apis), perciò esiste un set uniforme di metodi su cui le applicazioni possono fare affidamento, indipendentemente dallo specifico nodo o dall'implementazione del client. -[JSON-RPC](https://www.jsonrpc.org/specification) è un protocollo di chiamata a procedura remota (RPC) leggero e privo di stato. Definisce diverse strutture di dati e le regole per la loro elaborazione. È indipendente dal trasporto, poiché i concetti sono utilizzabili entro lo stesso processo, su prese, via HTTP o in svariati ambienti di passaggio dei messaggi. Usa JSON (RFC 4627) come formato dei dati. +[JSON-RPC](https://www.jsonrpc.org/specification) è un protocollo di chiamata di procedura remota (RPC) leggero e stateless. Definisce diverse strutture di dati e le regole per la loro elaborazione. È indipendente dal trasporto, poiché i concetti sono utilizzabili entro lo stesso processo, su prese, via HTTP o in svariati ambienti di passaggio dei messaggi. Usa JSON (RFC 4627) come formato dei dati. ## Implementazioni del client {#client-implementations} -I client di Ethereum possono usare linguaggi di programmazione diversi per l'implementazione della specifica di JSON-RPC. Visualizza la [documentazione dei singoli client](/developers/docs/nodes-and-clients/#execution-clients) per ulteriori dettagli sui linguaggi di programmazione specifici. Consigliamo di consultare la documentazione di ogni client per le informazioni più aggiornate sul supporto dell'API. +I client di Ethereum possono usare linguaggi di programmazione diversi per l'implementazione della specifica di JSON-RPC. Consulta la [documentazione dei singoli client](/developers/docs/nodes-and-clients/#execution-clients) per ulteriori dettagli sui linguaggi di programmazione specifici. Consigliamo di consultare la documentazione di ogni client per le informazioni più aggiornate sul supporto dell'API. -## Librerie utili {#convenience-libraries} +## Librerie di utilità {#convenience-libraries} -Anche se è possibile scegliere di interagire direttamente con i client di Ethereum tramite l'API di JSON-RPC, spesso esistono opzioni più semplici per gli sviluppatori di dApp. Esistono molte librerie di [JavaScript](/developers/docs/apis/javascript/#available-libraries) e dell'[API del backend](/developers/docs/apis/backend/#available-libraries) che forniscono wrapper sull'API di JSON-RPC. Con queste librerie, gli sviluppatori possono scrivere metodi intuitivi di una riga nel linguaggio di programmazione di loro scelta per inizializzare le richieste di JSON-RPC (sottostanti) che interagiscono con Ethereum. +Anche se è possibile scegliere di interagire direttamente con i client di Ethereum tramite l'API di JSON-RPC, spesso esistono opzioni più semplici per gli sviluppatori di dApp. Esistono molte librerie [JavaScript](/developers/docs/apis/javascript/#available-libraries) e [API di backend](/developers/docs/apis/backend/#available-libraries) che forniscono wrapper per l'API JSON-RPC. Con queste librerie, gli sviluppatori possono scrivere metodi intuitivi di una riga nel linguaggio di programmazione di loro scelta per inizializzare le richieste di JSON-RPC (sottostanti) che interagiscono con Ethereum. -## API del client di consenso {#consensus-clients} +## API dei client di consenso {#consensus-clients} -Questa pagina tratta principalmente dell'API di JSON-RPC usata dai client di esecuzione di Ethereum. Tuttavia, anche i client del consenso hanno un'API RPC che consente agli utenti di interrogare le informazioni sul nodo, richiedere blocchi della Beacon, lo stato della Beacon e altre informazioni correlate al consenso, direttamente da un nodo. Questa API è documentata sulla [pagina web dell'API Beacon](https://ethereum.github.io/beacon-APIs/#/). +Questa pagina tratta principalmente dell'API di JSON-RPC usata dai client di esecuzione di Ethereum. Tuttavia, anche i client del consenso hanno un'API RPC che consente agli utenti di interrogare le informazioni sul nodo, richiedere blocchi della Beacon, lo stato della Beacon e altre informazioni correlate al consenso, direttamente da un nodo. Questa API è documentata nella [pagina web dell'API Beacon](https://ethereum.github.io/beacon-APIs/#/). -Inoltre, un'API interna viene usata per la comunicazione tra client in un nodo, ovvero consente al client di consenso e al client di esecuzione di scambiarsi dati. Questa è detta "Engine API" e le specifiche sono disponibili su [GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md). +Inoltre, un'API interna viene usata per la comunicazione tra client in un nodo, ovvero consente al client di consenso e al client di esecuzione di scambiarsi dati. Questa è chiamata 'Engine API' e le specifiche sono disponibili su [GitHub](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md). -## Specifiche del client di esecuzione {#spec} +## Specifica del client di esecuzione {#spec} -[Leggi le specifiche complete dell'API JSON-RPC su GitHub](https://github.com/ethereum/execution-apis). Questa API è documentata nella [pagina web dell'API di esecuzione](https://ethereum.github.io/execution-apis/api-documentation/) e include un ispettore per provare tutti i metodi disponibili. +[Leggi la specifica completa dell'API JSON-RPC su GitHub](https://github.com/ethereum/execution-apis). Questa API è documentata nella [pagina web dell'API di esecuzione](https://ethereum.github.io/execution-apis/) e include un Inspector per provare tutti i metodi disponibili. ## Convenzioni {#conventions} @@ -58,9 +58,9 @@ 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 {#block-parameter} -I seguenti metodi hanno un parametro del blocco predefinito aggiuntivo: +I seguenti metodi hanno un parametro di blocco: - [eth_getBalance](#eth_getbalance) - [eth_getCode](#eth_getcode) @@ -68,36 +68,36 @@ I seguenti metodi hanno un parametro del blocco predefinito aggiuntivo: - [eth_getStorageAt](#eth_getstorageat) - [eth_call](#eth_call) -Quando sono effettuate richieste che agiscono sullo stato di Ethereum, il parametro dell'ultimo blocco predefinito determina l'altezza del blocco. +Quando vengono effettuate richieste che interrogano lo stato di Ethereum, il parametro del blocco fornito determina l'altezza del blocco. -Le seguenti opzioni sono possibili per il parametro defaultBlock: +Le seguenti opzioni sono possibili per il parametro del blocco: -- `HEX String` - un numero intero del blocco -- `String "earliest"` per il primo blocco o quello di genesi -- `String "latest"` - per l'ultimo blocco proposto -- `String "safe"` - per l'ultimo blocco di testa sicuro -- `String "finalized"` - per l'ultimo blocco finalizzato -- `String "pending"` - per lo stato/le transazioni in sospeso +- `Stringa HEX` - un numero di blocco intero +- `Stringa "earliest"` per il blocco più vecchio/di genesi +- `Stringa "latest"` - per l'ultimo blocco proposto +- `Stringa "safe"` - per l'ultimo blocco head sicuro +- `Stringa "finalized"` - per l'ultimo blocco finalizzato +- `Stringa "pending"` - per lo stato/le transazioni in sospeso ## Esempi -Su questa pagina forniamo esempi su come usare gli endpoint individuali dell'API JSON_RPC usando lo strumento della riga di comando, [curl](https://curl.se). Questi esempi di endpoint individuali si trovano di seguito nella sezione [esempi di Curl](#curl-examples). In seguito nella pagina, forniamo anche un [esempio completo](#usage-example) per la compilazione e la distribuzione di un contratto intelligente usando un nodo di Geth, l'API JSON_RPC e curl. +In questa pagina forniamo esempi su come usare i singoli endpoint dell'API JSON-RPC usando lo strumento a riga di comando, [curl](https://curl.se). Questi esempi di singoli endpoint si trovano di seguito nella sezione [Esempi di Curl](#curl-examples). Più avanti nella pagina, forniamo anche un [esempio end-to-end](#usage-example) per la compilazione e la distribuzione di un contratto intelligente usando un nodo Geth, l'API JSON-RPC e curl. ## Esempi di Curl {#curl-examples} -Di seguito sono riportati esempi dell'uso dell'API di JSON_RPC effettuando richieste di [curl](https://curl.se) a un nodo di Ethereum. Ogni esempio include una descrizione dell'endpoint specifico, i suoi parametri, il tipo di restituzione e un esempio definito di come dovrebbe essere utilizzato. +Di seguito sono forniti esempi di utilizzo dell'API JSON-RPC effettuando richieste [curl](https://curl.se) a un nodo Ethereum. Ogni esempio include una descrizione dell'endpoint specifico, i suoi parametri, il tipo di restituzione e un esempio definito di come dovrebbe essere utilizzato. -Le richieste di curl potrebbero restituire un messaggio d'errore correlato al tipo di contenuto. Ciò avviene perché l'opzione `--data` imposta il tipo di contenuto su `application/x-www-form-urlencoded`. Se il tuo nodo se ne lamenta, imposta manualmente l'intestazione posizionando `-H "Content-Type: application/json"` all'inizio della chiamata. Gli esempi, inoltre, non includono la combinazione di URL/IP e porta, che deve essere l'ultimo argomento fornito al curl (ad es. `127.0.0.1:8545`). Una richiesta di curl completa, comprensiva di questi dati aggiuntivi, assume la seguente forma: +Le richieste di curl potrebbero restituire un messaggio d'errore correlato al tipo di contenuto. Questo perché l'opzione `--data` imposta il tipo di contenuto su `application/x-www-form-urlencoded`. Se il tuo nodo restituisce un errore, imposta manualmente l'header inserendo `-H "Content-Type: application/json"` all'inizio della chiamata. Gli esempi, inoltre, non includono la combinazione di URL/IP e porta, che deve essere l'ultimo argomento passato a curl (ad esempio, `127.0.0.1:8545`). Una richiesta di curl completa, comprensiva di questi dati aggiuntivi, assume la seguente forma: ```shell curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545 ``` -## Gossip, Stato, Storico {#gossip-state-history} +## Gossip, Stato, Cronologia {#gossip-state-history} -Alcuni metodi base del protocollo JSON-RPC richiedono dati dalla rete di Ethereum e rientrano in tre importanti categorie:_Gossip, Stato e Storico_. Usa i collegamenti in questa sezione per passare da un metodo all'altro oppure usa la tabella di contenuti per esplorare l'intera lista di metodi. +Alcuni metodi JSON-RPC di base richiedono dati dalla rete Ethereum e rientrano in tre categorie principali: _Gossip, Stato e Cronologia_. Usa i collegamenti in questa sezione per passare da un metodo all'altro oppure usa la tabella di contenuti per esplorare l'intera lista di metodi. -### Metodi di Gossip {#gossip-methods} +### Metodi Gossip {#gossip-methods} > Questi metodi tracciano la testa della catena. Ecco come le transazioni si fanno strada all'interno della rete ed entrano nei blocchi e come i Client fanno ricerche sui nuovi blocchi. @@ -115,7 +115,7 @@ Alcuni metodi base del protocollo JSON-RPC richiedono dati dalla rete di Ethereu - [eth_call](#eth_call) - [eth_estimateGas](#eth_estimategas) -### Metodi dello Storico {#history_methods} +### Metodi di Cronologia {#history_methods} > Recupera lo storico dei record di ogni blocco fino alla genesi. Può essere paragonato a un grande file Append-Only contenente tutte le intestazioni del blocco, i corpi del blocco, i blocchi ommer (zio) e le ricevute delle transazioni. @@ -134,9 +134,9 @@ Alcuni metodi base del protocollo JSON-RPC richiedono dati dalla rete di Ethereu ## Playground dell'API di JSON-RPC -Puoi utilizzare lo [strumento playground](https://ethereum-json-rpc.com) per scoprire e provare i metodi dell'API. Inoltre, ti mostra le reti e i metodi supportati dai vari fornitori di nodi. +Puoi usare lo [strumento playground](https://ethereum-json-rpc.com) per scoprire e provare i metodi dell'API. Inoltre, ti mostra le reti e i metodi supportati dai vari fornitori di nodi. -## I metodi dell'API JSON-RPC {#json-rpc-methods} +## Metodi dell'API JSON-RPC {#json-rpc-methods} ### web3_clientVersion {#web3_clientversion} @@ -148,7 +148,7 @@ Nessuno **Restituisce** -`String` - La versione del client corrente +`String` - La versione corrente del client **Esempio** @@ -165,7 +165,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[], ### web3_sha3 {#web3_sha3} -Restituisce Keccak-256 (_non_ lo SHA3-256 standardizzato) dei dati forniti. +Restituisce il Keccak-256 (non lo SHA3-256 standardizzato) dei dati forniti. **Parametri** @@ -182,9 +182,9 @@ params: ["0x68656c6c6f20776f726c64"] **Esempio** ```js -// Request +// Richiesta curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}' -// Result +// Risultato { "id":64, "jsonrpc": "2.0", @@ -202,20 +202,20 @@ Nessuno **Restituisce** -`String` - L'id di rete corrente. +`String` - L'ID della rete corrente. L'elenco completo degli ID di rete correnti è disponibile su [chainlist.org](https://chainlist.org). Alcuni ID comuni sono: -- `1`: Rete Principale di Ethereum -- `11155111`: rete di prova Sepolia -- `560048`: rete di prova Hoodi +- `1`: Mainnet di Ethereum +- `11155111`: rete di test Sepolia +- `560048` : rete di test Hoodi **Esempio** ```js -// Request +// Richiesta curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}' -// Result +// Risultato { "id":67, "jsonrpc": "2.0", @@ -225,7 +225,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67 ### net_listening {#net_listening} -Restituisce `true` se il client sta ascoltando attivamente le connessioni di rete. +Restituisce `true` se il client è in ascolto attivo di connessioni di rete. **Parametri** @@ -233,14 +233,14 @@ Nessuno **Restituisce** -`Boolean` - `true` quando è in ascolto, altrimenti `false`. +`Boolean` - `true` se in ascolto, altrimenti `false`. **Esempio** ```js -// Request +// Richiesta curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}' -// Result +// Risultato { "id":67, "jsonrpc":"2.0", @@ -258,14 +258,14 @@ Nessuno **Restituisce** -`QUANTITY` - intero del numero di pari connessi. +`QUANTITY` - intero del numero di peer connessi. **Esempio** ```js -// Request +// Richiesta curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}' -// Result +// Risultato { "id":74, "jsonrpc": "2.0", @@ -275,7 +275,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id": ### eth_protocolVersion {#eth_protocolversion} -Restituisce la versione corrente del protocollo di Ethereum. Si noti che questo metodo [non è disponibile su Geth](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924). +Restituisce la versione corrente del protocollo di Ethereum. Nota che questo metodo [non è disponibile in Geth](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924). **Parametri** @@ -283,14 +283,14 @@ Nessuno **Restituisce** -`String` - La versione del protocollo di Ethereum corrente +`String` - La versione corrente del protocollo Ethereum **Esempio** ```js -// Request +// Richiesta curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}' -// Result +// Risultato { "id":67, "jsonrpc": "2.0", @@ -302,17 +302,21 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[] Restituisce un oggetto con i dati sullo stato di sincronizzazione o `false`. + + Prova l'endpoint nel playground + + **Parametri** Nessuno **Restituisce** -I dati restituiti precisi variano a seconda delle implementazioni del client. Tutti i client restituiscono `False` quando il nodo non si sta sincronizzando, e tutti i client restituiscono i seguenti campi. +I dati restituiti precisi variano a seconda delle implementazioni del client. Tutti i client restituiscono `False` quando il nodo non è in fase di sincronizzazione e tutti i client restituiscono i seguenti campi. -`Object|Boolean`, un oggetto con i dati dello stato di sincronizzazione o `FALSE`, quando non è in sincronizzazione: +`Object|Boolean`, un oggetto con i dati sullo stato di sincronizzazione o `FALSE`, quando non è in sincronizzazione: -- `startingBlock`: `QUANTITY` - Il blocco in cui è iniziata l'importazione (si ripristina soltanto dopo che la sincronizzazione ha raggiunto la sua testa) +- `startingBlock`: `QUANTITY` - Il blocco da cui è iniziata l'importazione (verrà reimpostato solo dopo che la sincronizzazione avrà raggiunto il blocco più recente) - `currentBlock`: `QUANTITY` - Il blocco corrente, uguale a eth_blockNumber - `highestBlock`: `QUANTITY` - Il blocco più alto stimato @@ -386,7 +390,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1} Restituisce l'indirizzo di coinbase del client. -> **Nota:** Questo metodo è stato deprecato alla **v1.14.0** e non è più supportato. Tentare di utilizzarlo risulterà in un errore "Metodo non supportato". + + Prova l'endpoint nel playground + + +> **Nota:** questo metodo è stato deprecato a partire dalla **v1.14.0** e non è più supportato. Tentare di utilizzarlo risulterà in un errore "Metodo non supportato". **Parametri** @@ -394,7 +402,7 @@ Nessuno **Restituisce** -`DATA`, 20 byte - l'indirizzo di coinbase corrente. +`DATA`, 20 byte - l'indirizzo coinbase corrente. **Esempio** @@ -413,13 +421,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":6 Restituisce l'ID della catena utilizzato per firmare le transazioni protette da riproduzione. + + Prova l'endpoint nel playground + + **Parametri** Nessuno **Restituisce** -`chainId`, valore esadecimale come stringa rappresentante l'intero dell'ID della catena corrente. +`chainId`, valore esadecimale come stringa che rappresenta l'intero dell'ID della catena corrente. **Esempio** @@ -436,7 +448,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67 ### eth_mining {#eth_mining} -Restituisce `true` se il client sta minando attivamente nuovi blocchi. Può restituire `true` soltanto per le reti di proof-of-work e potrebbe non essere disponibile in alcuni client da [La Fusione](/roadmap/merge/). +Restituisce `true` se il client sta minando attivamente nuovi blocchi. Può restituire `true` solo per le reti proof-of-work e potrebbe non essere disponibile in alcuni client dopo [la Fusione](/roadmap/merge/). + + + Prova l'endpoint nel playground + **Parametri** @@ -461,7 +477,11 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71} ### eth_hashrate {#eth_hashrate} -Restituisce il numero di hash al secondo con cui il nodo sta minando. Può restituire `true` soltanto per le reti di proof-of-work e potrebbe non essere disponibile in alcuni client da [La Fusione](/roadmap/merge/). +Restituisce il numero di hash al secondo con cui il nodo sta minando. Può restituire `true` solo per le reti proof-of-work e potrebbe non essere disponibile in alcuni client dopo [la Fusione](/roadmap/merge/). + + + Prova l'endpoint nel playground + **Parametri** @@ -488,13 +508,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":7 Restituisce una stima del prezzo corrente per gas, in wei. Ad esempio, il client di Besu esamina gli ultimi 100 blocchi e restituisce il prezzo unitario medio del gas di default. + + Prova l'endpoint nel playground + + **Parametri** Nessuno **Restituisce** -`QUANTITY` - intero del prezzo corrente del gas in wei. +`QUANTITY` - intero del prezzo del gas corrente in wei. **Esempio** @@ -513,13 +537,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":7 Restituisce un elenco di indirizzi posseduti dal client. + + Prova l'endpoint nel playground + + **Parametri** Nessuno **Restituisce** -`Array of DATA`, 20 Byte - indirizzi posseduti dal client. +`Array di DATA`, 20 byte - indirizzi di proprietà del client. **Esempio** @@ -538,13 +566,17 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1 Restituisce il numero del blocco più recente. + + Prova l'endpoint nel playground + + **Parametri** Nessuno **Restituisce** -`QUANTITY` - intero del numero di blocco corrente su cui è attivo il client. +`QUANTITY` - intero del numero del blocco corrente su cui si trova il client. **Esempio** @@ -561,12 +593,16 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id ### eth_getBalance {#eth_getbalance} -Restituisce il saldo del conto del dato indirizzo. +Restituisce il saldo dell'account a un dato indirizzo. + + + Prova l'endpoint nel playground + **Parametri** -1. `DATA`, 20 byte - indirizzo per controllare il saldo. -2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +1. `DATA`, 20 byte - indirizzo di cui controllare il saldo. +2. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter) ```js params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] @@ -593,23 +629,28 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407 Restituisce il valore da una posizione di archiviazione a un dato indirizzo. + + Prova l'endpoint nel playground + + **Parametri** -1. `DATA`, 20 byte - Indirizzo di archiviazione. -2. `QUANTITY` - intero della posizione di archiviazione. -3. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +1. `DATA`, 20 byte - indirizzo dello storage. +2. `QUANTITY` - intero della posizione nello storage. +3. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"`, `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter) **Restituisce** -`DATA` - il valore in questa posizione di archiviazione. +`DATA` - il valore in questa posizione di storage. -**Esempio** Il calcolo della posizione corretta dipende dall'archiviazione da recuperare. Considera il seguente contratto distribuito su `0x295a70b2de5e3953354a6a8344e616ed314d7251` dall'indirizzo `0x391694e7e0b0cce554cb130d723a9d27458f9298`. +**Esempio** +Il calcolo della posizione corretta dipende dallo storage da recuperare. Considera il seguente contratto distribuito a `0x295a70b2de5e3953354a6a8344e616ed314d7251` dall'indirizzo `0x391694e7e0b0cce554cb130d723a9d27458f9298`. ``` contract Storage { uint pos0; mapping(address => uint) pos1; - function Storage() { + constructor() { pos0 = 1234; pos1[msg.sender] = 5678; } @@ -658,12 +699,16 @@ curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": [ ### eth_getTransactionCount {#eth_gettransactioncount} -Restituisce il numero di transazioni _inviate_da un indirizzo. +Restituisce il numero di transazioni _inviate_ da un indirizzo. + + + Prova l'endpoint nel playground + **Parametri** 1. `DATA`, 20 byte - indirizzo. -2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +2. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ @@ -693,6 +738,10 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params Restituisce il numero di transazioni in un blocco da un blocco corrispondente al dato hash del blocco. + + Prova l'endpoint nel playground + + **Parametri** 1. `DATA`, 32 byte - hash di un blocco @@ -722,9 +771,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHa Restituisce il numero di transazioni in un blocco corrispondente al numero di blocco specificato. + + Prova l'endpoint nel playground + + **Parametri** -1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block). +1. `QUANTITY|TAG` - numero intero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter). ```js params: [ @@ -751,11 +804,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNu ### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash} -Restituisce il numero di ommer in un blocco da un blocco che corrisponde all'hash del blocco specificato. +Restituisce il numero di ommer in un blocco da un blocco corrispondente all'hash del blocco specificato. + + + Prova l'endpoint nel playground + **Parametri** -1. `DATA`, 32 Bytes - Hash di un blocco +1. `DATA`, 32 byte - hash di un blocco ```js params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"] @@ -782,9 +839,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","p Restituisce il numero di ommer in un blocco da un blocco che corrisponde all'hash del blocco specificato. + + Prova l'endpoint nel playground + + **Parametri** -1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +1. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ @@ -813,10 +874,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber", Restituisce il codice ad un dato indirizzo. + + Prova l'endpoint nel playground + + **Parametri** 1. `DATA`, 20 byte - indirizzo -2. `QUANTITY|TAG` - intero del numero di blocco, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block) +2. `QUANTITY|TAG` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter) ```js params: [ @@ -827,7 +892,7 @@ params: [ **Restituisce** -`DATA` - il codice dal dato indirizzo. +`DATA` - il codice dall'indirizzo fornito. **Esempio** @@ -844,15 +909,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA ### eth_sign {#eth_sign} -Il metodo della firma calcola una firma specifica di Ethereum con: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`. +Il metodo di firma calcola una firma specifica di Ethereum con: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`. -Aggiungendo un prefisso al messaggio si rende la firma calcolata riconoscibile come firma specifica di Ethereum. Ciò impedisce l'uso improprio in cui una dapp malevola può firmare i dati arbitrari (es. la transazione) e usare la firma per impersonare la vittima. +Aggiungendo un prefisso al messaggio si rende la firma calcolata riconoscibile come firma specifica di Ethereum. Ciò impedisce un uso improprio in cui una dApp malevola può firmare dati arbitrari (ad es. una transazione) e utilizzare la firma per impersonare la vittima. Nota: l'indirizzo con cui firmare deve essere sbloccato. **Parametri** -1. `DATA`, 20 Bytes - indirizzo +1. `DATA`, 20 byte - indirizzo 2. `DATA`, N byte - messaggio da firmare **Restituisce** @@ -874,24 +939,24 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d37 ### eth_signTransaction {#eth_signtransaction} -Firma una transazione che può essere inviata alla rete in un secondo momento utilizzando [eth_sendRawTransaction](#eth_sendrawtransaction). +Firma una transazione che può essere inviata alla rete in un secondo momento con [eth_sendRawTransaction](#eth_sendrawtransaction). **Parametri** -1. `Object` - L'oggetto della transazione +1. `Object` - L'oggetto transazione - `type`: - `from`: `DATA`, 20 byte - L'indirizzo da cui viene inviata la transazione. - `to`: `DATA`, 20 byte - (facoltativo quando si crea un nuovo contratto) L'indirizzo a cui è indirizzata la transazione. -- `gas`: `QUANTITY` - (facoltativo, predefinito: 90000) Intero del carburante fornito per l'esecuzione della transazione. Restituirà il carburante inutilizzato. -- `gasPrice`: `QUANTITY` - (facoltativo, predefinito: To-Be-Determined) Intero del gasPrice usato per ogni unità di carburante pagata, in Wei. +- `gas`: `QUANTITY` - (facoltativo, predefinito: 90000) Intero del gas fornito per l'esecuzione della transazione. Restituirà il carburante inutilizzato. +- `gasPrice`: `QUANTITY` - (facoltativo, predefinito: Da stabilire) Intero del gasPrice usato per ogni gas pagato, in Wei. - `value`: `QUANTITY` - (facoltativo) Intero del valore inviato con questa transazione, in Wei. -- `data`: `DATA` - Il codice compilato di un contratto OPPURE l'hash della firma del metodo richiamato e i parametri codificati. +- `data`: `DATA` - Il codice compilato di un contratto O l'hash della firma del metodo richiamato e i parametri codificati. - `nonce`: `QUANTITY` - (facoltativo) Intero di un nonce. Ciò permette di sovrascrivere le proprie transazioni in sospeso che utilizzano lo stesso nonce. **Restituisce** -`DATA`, L'oggetto della transazione codificata in RLP, firmato dal conto specificato. +`DATA`, l'oggetto transazione codificato in RLP firmato dall'account specificato. **Esempio** @@ -908,18 +973,18 @@ curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction"," ### eth_sendTransaction {#eth_sendtransaction} -Crea la transazione di chiamata del nuovo messaggio o la creazione di un contratto, se il campo dei dati contiene del codice, e la firma utilizzando il conto specificato in `from`. +Crea una nuova transazione di chiamata di messaggio o la creazione di un contratto, se il campo dati contiene codice, e la firma usando l'account specificato in `from`. **Parametri** -1. `Oggetto` - L'oggetto della transazione +1. `Object` - L'oggetto transazione - `from`: `DATA`, 20 byte - L'indirizzo da cui viene inviata la transazione. - `to`: `DATA`, 20 byte - (facoltativo quando si crea un nuovo contratto) L'indirizzo a cui è indirizzata la transazione. -- `gas`: `QUANTITY` - (facoltativo, predefinito: 90000) Intero del carburante fornito per l'esecuzione della transazione. Restituirà il carburante inutilizzato. -- `gasPrice`: `QUANTITY` - (facoltativo, predefinito: To-Be-Determined) Intero del gasPrice usato per ogni unità di carburante pagata. -- `value`: `QUANTITY` - (facoltativo) Intero del valore inviato con questa transazione, in Wei. -- `input`: `DATA` - Il codice compilato di un contratto O l'hash della firma del metodo invocato e i parametri codificati. +- `gas`: `QUANTITY` - (facoltativo, predefinito: 90000) Intero del gas fornito per l'esecuzione della transazione. Restituirà il carburante inutilizzato. +- `gasPrice`: `QUANTITY` - (facoltativo, predefinito: Da stabilire) Intero del gasPrice usato per ogni gas pagato. +- `value`: `QUANTITY` - (facoltativo) Intero del valore inviato con questa transazione. +- `input`: `DATA` - Il codice compilato di un contratto O l'hash della firma del metodo richiamato e dei parametri codificati. - `nonce`: `QUANTITY` - (facoltativo) Intero di un nonce. Ciò permette di sovrascrivere le proprie transazioni in sospeso che utilizzano lo stesso nonce. ```js @@ -938,9 +1003,9 @@ params: [ **Restituisce** -`DATA`, 32 Bytes - l'hash della transazione, o l'hash zero se la transazione non è ancora disponibile. +`DATA`, 32 byte - l'hash della transazione, o l'hash zero se la transazione non è ancora disponibile. -Usa [eth_getTransactionReceipt](#eth_gettransactionreceipt) quando hai creato un contratto per ottenere l'indirizzo del contratto dopo che la transazione è stata proposta in un blocco. +Usa [eth_getTransactionReceipt](#eth_gettransactionreceipt) per ottenere l'indirizzo del contratto, dopo che la transazione è stata proposta in un blocco, quando hai creato un contratto. **Esempio** @@ -961,7 +1026,7 @@ Crea una nuova transazione di chiamata di messaggio o la stipula di un contratto **Parametri** -1. `DATA`, L'oggetto transazione firmato. +1. `DATA`, i dati della transazione firmata. ```js params: [ @@ -971,9 +1036,9 @@ params: [ **Restituisce** -`DATA`, 32 Bytes - l'hash della transazione, o l'hash zero se la transazione non è ancora disponibile. +`DATA`, 32 byte - l'hash della transazione, o l'hash zero se la transazione non è ancora disponibile. -Usa [eth_getTransactionReceipt](#eth_gettransactionreceipt) quando hai creato un contratto per ottenere l'indirizzo del contratto dopo che la transazione è stata proposta in un blocco. +Usa [eth_getTransactionReceipt](#eth_gettransactionreceipt) per ottenere l'indirizzo del contratto, dopo che la transazione è stata proposta in un blocco, quando hai creato un contratto. **Esempio** @@ -990,24 +1055,28 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params" ### eth_call {#eth_call} -Esegue immediatamente una nuova chiamata di messaggio senza creare una transazione nella blockchain. Spesso utilizzato per eseguire le funzioni dei contratti intelligenti di sola lettura, ad esempio `balanceOf` per un contratto ERC-20. +Esegue immediatamente una nuova chiamata di messaggio senza creare una transazione sulla blockchain. Spesso usato per eseguire funzioni di contratti intelligenti di sola lettura, ad esempio `balanceOf` per un contratto ERC-20. + + + Prova l'endpoint nel playground + **Parametri** -1. `Object` - L'oggetto della chiamata della transazione +1. `Object` - L'oggetto della chiamata di transazione - `from`: `DATA`, 20 byte - (facoltativo) L'indirizzo da cui viene inviata la transazione. - `to`: `DATA`, 20 byte - L'indirizzo a cui è indirizzata la transazione. -- `gas`: `QUANTITY` - (facoltativo) Intero del carburante fornito per l'esecuzione della transazione. eth_call consuma zero carburante, ma questo parametro potrebbe essere necessario per alcune esecuzioni. -- `gasPrice`: `QUANTITY` - (facoltativo) Intero del gasPrice usato per ogni unità di carburante pagata +- `gas`: `QUANTITY` - (facoltativo) Intero del gas fornito per l'esecuzione della transazione. eth_call consuma zero carburante, ma questo parametro potrebbe essere necessario per alcune esecuzioni. +- `gasPrice`: `QUANTITY` - (facoltativo) Intero del gasPrice usato per ogni gas pagato - `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). +- `input`: `DATA` - (facoltativo) Hash della firma del metodo e dei parametri codificati. Per i dettagli vedi [ABI dei Contratti 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` - numero di blocco intero, o la stringa `"latest"`, `"earliest"`, `"pending"`, `"safe"` o `"finalized"`, vedi il [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter) **Restituisce** -`DATA` - Il valore di ritorno del contratto eseguito. +`DATA` - il valore restituito dal contratto eseguito. **Esempio** @@ -1024,15 +1093,19 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}] ### eth_estimateGas {#eth_estimategas} -Genera e restituisce una stima di quanto gas è necessario per consentire il completamento della transazione. La transazione non verrà aggiunta alla blockchain. Si noti che la stima potrebbe esser significativamente superiore all'importo di gas effettivamente usato dalla transazione, per vari motivi, incluse le meccaniche dell'EVM e le prestazioni del nodo. +Genera e restituisce una stima di quanto carburante è necessario per consentire il completamento della transazione. La transazione non verrà aggiunta alla blockchain. Si noti che la stima potrebbe esser significativamente superiore all'importo di gas effettivamente usato dalla transazione, per vari motivi, incluse le meccaniche dell'EVM e le prestazioni del nodo. + + + Prova l'endpoint nel playground + **Parametri** -Vedi i parametri di [eth_call](#eth_call), tranne che tutte le proprietà sono facoltative. Se non è specificato alcun limite di gas, geth usa il limite di gas del blocco dal blocco in sospeso come limite massimo. Di conseguenza, la stima restituita potrebbe non esser sufficiente per eseguire la chiamata/transazione quando l'importo di gas è superiore al limite di gas del blocco. +Vedi i parametri di [eth_call](#eth_call), con la differenza che tutte le proprietà sono facoltative. Se non è specificato alcun limite di carburante, geth usa il limite di carburante del blocco dal blocco in sospeso come limite massimo. Di conseguenza, la stima restituita potrebbe non essere sufficiente a eseguire la chiamata/transazione quando la quantità di gas è superiore al limite di gas del blocco in sospeso. **Restituisce** -`QUANTITY` - la quantità di gas utilizzato. +`QUANTITY` - la quantità di gas usata. **Esempio** @@ -1051,10 +1124,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see Restituisce informazioni su un blocco tramite hash. + + Prova l'endpoint nel playground + + **Parametri** 1. `DATA`, 32 byte - Hash di un blocco. -2. `Boolean` - Se `true` restituisce gli oggetti di transazione completi, se `falso` solo gli hash delle transazioni. +2. `Boolean` - Se `true` restituisce gli oggetti transazione completi, se `false` solo gli hash delle transazioni. ```js params: [ @@ -1065,27 +1142,27 @@ params: [ **Restituisce** -`Object` - Un oggetto blocco, o `null` quando non viene trovato alcun blocco: - -- `number`: `QUANTITY` - il numero di blocco. `null` quando è in attesa del blocco. -- `hash`: `DATA`, 32 byte - hash del blocco. `null` quando è in attesa del blocco. -- `hash`: `DATA`, 32 byte - hash del blocco genitore. -- `nonce`: `DATA`, 8 byte - hash del proof-of-work generato. `null` quando è in attesa del blocco. -- `sha3Uncles`: `DATA`, 32 byte - SHA3 dei dati ommer del blocco. -- `logsBloom`: `DATA`, 256 byte - il filtro bloom per i registri del blocco. `null` quando è in attesa del blocco. -- `transactionsRoot`: `DATA`, 32 byte - la radice dell'albero delle transazioni del blocco. -- `stateRoot`: `DATA`, 32 byte - la radice dell'albero di stato finale del blocco. -- `receiptsRoot`: `DATA`, 32 byte - la radice dell'albero delle ricevute del blocco. -- `miner`: `DATA`, 20 byte - l'indirizzo del beneficiario a cui sono state fornite le ricompense di mining. -- `difficulty`: `QUANTITY` - intero della difficoltà per questo blocco. +`Object` - Un oggetto blocco, o `null` se non è stato trovato nessun blocco: + +- `number`: `QUANTITY` - il numero del blocco. `null` se è un blocco in sospeso. +- `hash`: `DATA`, 32 byte - hash del blocco. `null` se è un blocco in sospeso. +- `parentHash`: `DATA`, 32 byte - hash del blocco genitore. +- `nonce`: `DATA`, 8 byte - hash della proof-of-work generata. `null` per un blocco in sospeso, `0x0` per i blocchi proof-of-stake (dopo la Fusione) +- `sha3Uncles`: `DATA`, 32 byte - SHA3 dei dati degli ommer nel blocco. +- `logsBloom`: `DATA`, 256 byte - il filtro bloom per i log del blocco. `null` se è un blocco in sospeso. +- `transactionsRoot`: `DATA`, 32 byte - la radice del trie delle transazioni del blocco. +- `stateRoot`: `DATA`, 32 byte - la radice del trie dello stato finale del blocco. +- `receiptsRoot`: `DATA`, 32 byte - la radice del trie delle ricevute del blocco. +- `miner`: `DATA`, 20 byte - l'indirizzo del beneficiario a cui sono state date le ricompense del blocco. +- `difficulty`: `QUANTITY` - intero della difficoltà di questo blocco. - `totalDifficulty`: `QUANTITY` - intero della difficoltà totale della catena fino a questo blocco. - `extraData`: `DATA` - il campo "dati extra" di questo blocco. -- `size`: `QUANTITY` - intero in bytes della dimensione di questo blocco. -- `gasLimit`: `QUANTITY` - il carburante massimo consentito in questo blocco. -- `gasUsed`: `QUANTITY` - il carburante totale usato da tutte le transazioni in questo blocco. -- `timestamp`: `QUANTITY` - la marca temporale unix relativa a quando il blocco è stato collazionato. -- `transactions`: `Array` - Array di oggetti transazione, o hash di transazione da 32 byte a seconda dell'ultimo parametro specificato. -- `uncles`: `Array` - Array di hash ommer. +- `size`: `QUANTITY` - intero della dimensione di questo blocco in byte. +- `gasLimit`: `QUANTITY` - il limite del gas massimo consentito in questo blocco. +- `gasUsed`: `QUANTITY` - il gas totale usato da tutte le transazioni in questo blocco. +- `timestamp`: `QUANTITY` - il timestamp unix di quando il blocco è stato raccolto. +- `transactions`: `Array` - Array di oggetti transazione o hash di transazione a 32 byte, a seconda dell'ultimo parametro fornito. +- `uncles`: `Array` - Array di hash di ommer. **Esempio** @@ -1094,10 +1171,9 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}' // Risultato { -{ -"jsonrpc": "2.0", -"id": 1, -"result": { + "jsonrpc": "2.0", + "id": 1, + "result": { "difficulty": "0x4ea3f27bc", "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32", "gasLimit": "0x1388", @@ -1120,7 +1196,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0 "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [ ] -} + } } ``` @@ -1128,10 +1204,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0 Restituisce informazioni su un blocco per numero di blocco. + + Prova l'endpoint nel playground + + **Parametri** -1. `QUANTITY|TAG` - intero del numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block). -2. `Boolean` - Se `true` restituisce gli oggetti di transazione completi, se `falso` solo gli hash delle transazioni. +1. `QUANTITY|TAG` - numero intero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter). +2. `Boolean` - Se `true` restituisce gli oggetti transazione completi, se `false` solo gli hash delle transazioni. ```js params: [ @@ -1140,7 +1220,8 @@ params: [ ] ``` -**Restituisce** Vedi [eth_getBlockByHash](#eth_getblockbyhash) +**Restituisce** +Vedi [eth_getBlockByHash](#eth_getblockbyhash) **Esempio** @@ -1149,12 +1230,16 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}' ``` -Per il risultato vedi [eth_getBlockByHash](#eth_getblockbyhash) +Risultato vedi [eth_getBlockByHash](#eth_getblockbyhash) ### eth_getTransactionByHash {#eth_gettransactionbyhash} Restituisce le informazioni su una transazione richiesta dall'hash della transazione. + + Prova l'endpoint nel playground + + **Parametri** 1. `DATA`, 32 byte - hash di una transazione @@ -1165,18 +1250,18 @@ params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"] **Restituisce** -`Object` - Un oggetto transazione, oppure `null` quando non viene trovata alcuna transazione: +`Object` - Un oggetto transazione, o `null` se non è stata trovata nessuna transazione: -- `blockHash`: `DATA`, 32 byte - hash del blocco in cui si trovava questa transazione. `null` quando è in sospeso. -- `blockNumber`: `QUANTITY` - numero di blocco in cui si trovava questa transazione. `null` quando è in sospeso. +- `blockHash`: `DATA`, 32 byte - hash del blocco in cui si trovava questa transazione. `null` se è in sospeso. +- `blockNumber`: `QUANTITY` - numero del blocco in cui si trovava questa transazione. `null` se è in sospeso. - `from`: `DATA`, 20 byte - indirizzo del mittente. -- `gas`: `QUANTITY` - carburante fornito dal mittente. -- `gasPrice`: `QUANTITY` - prezzo del carburante fornito dal mittente in Wei. +- `gas`: `QUANTITY` - gas fornito dal mittente. +- `gasPrice`: `QUANTITY` - prezzo del gas fornito dal mittente in Wei. - `hash`: `DATA`, 32 byte - hash della transazione. - `input`: `DATA` - i dati inviati insieme alla transazione. - `nonce`: `QUANTITY` - il numero di transazioni effettuate dal mittente prima di questa. -- `to`: `DATA`, 20 byte - l'indirizzo del destinatario. `null` quando è una transazione di creazione del contratto. -- `transactionIndex`: `QUANTITY` - intero della posizione dell'indice delle transazioni nel blocco. `null` quando è in sospeso. +- `to`: `DATA`, 20 byte - indirizzo del destinatario. `null` se si tratta di una transazione di creazione di contratto. +- `transactionIndex`: `QUANTITY` - intero della posizione dell'indice delle transazioni nel blocco. `null` se è in sospeso. - `value`: `QUANTITY` - valore trasferito in Wei. - `v`: `QUANTITY` - ID di recupero ECDSA - `r`: `QUANTITY` - firma r ECDSA @@ -1214,6 +1299,10 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","param Restituisce informazioni su una transazione per hash del blocco e posizione dell'indice della transazione. + + Prova l'endpoint nel playground + + **Parametri** 1. `DATA`, 32 byte - hash di un blocco. @@ -1226,7 +1315,8 @@ params: [ ] ``` -**Restituisce** Vedi [eth_getTransactionByHash](#eth_gettransactionbyhash) +**Restituisce** +Vedi [eth_getTransactionByHash](#eth_gettransactionbyhash) **Esempio** @@ -1235,15 +1325,19 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' ``` -Risultato vedi [eth_getBlockByHash](#eth_gettransactionbyhash) +Risultato vedi [eth_getTransactionByHash](#eth_gettransactionbyhash) ### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex} Restituisce informazioni su una transazione per hash del blocco e posizione dell'indice della transazione. + + Prova l'endpoint nel playground + + **Parametri** -1. `QUANTITY|TAG`: il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco predefinito](/developers/docs/apis/json-rpc/#default-block). +1. `QUANTITY|TAG` - un numero di blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"` o `"finalized"`, come nel [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter). 2. `QUANTITY` - la posizione dell'indice della transazione. ```js @@ -1253,16 +1347,17 @@ params: [ ] ``` -**Restituisce** Vedi [eth_getTransactionByHash](#eth_gettransactionbyhash) +**Restituisce** +Vedi [eth_getTransactionByHash](#eth_gettransactionbyhash) **Esempio** ```js -// Request +// Richiesta curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}' ``` -Risultato vedi [eth_getBlockByHash](#eth_gettransactionbyhash) +Risultato vedi [eth_getTransactionByHash](#eth_gettransactionbyhash) ### eth_getTransactionReceipt {#eth_gettransactionreceipt} @@ -1272,32 +1367,33 @@ Restituisce la ricevuta di una transazione tramite l'hash di transazione. **Parametri** -1. `DATA`, 32 Bytes - hash di una transazione +1. `DATA`, 32 byte - hash di una transazione ```js params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"] ``` -**Restituisce** `Object` - Un oggetto ricevuta della transazione, o `null` quando non è stata trovata nessuna ricevuta: +**Restituisce** +`Object` - Un oggetto ricevuta di transazione, o `null` se non è stata trovata alcuna ricevuta: -- `transactionHash`: `DATA`, 32 byte - hash della transazione. +- `transactionHash `: `DATA`, 32 byte - hash della transazione. - `transactionIndex`: `QUANTITY` - intero della posizione dell'indice delle transazioni nel blocco. - `blockHash`: `DATA`, 32 byte - hash del blocco in cui si trovava questa transazione. -- `blockNumber`: `QUANTITY` - numero di blocco in cui si trovava questa transazione. +- `blockNumber`: `QUANTITY` - numero del blocco in cui si trovava questa transazione. - `from`: `DATA`, 20 byte - indirizzo del mittente. -- `to`: `DATA`, 20 byte - l'indirizzo del destinatario. null quando è una transazione di creazione del contratto. -- `cumulativeGasUsed`: `QUANTITY` - La quantità totale di carburante usato nel blocco per l'esecuzione della transazione. -- `effectiveGasPrice` : `QUANTITY` - La somma della commissione di base e delle mance pagata per unità di carburante. -- `gasUsed`: `QUANTITY` - La quantità di carburante usato solo da questa specifica transazione. -- `contractAddress`: `DATA`, 20 byte - L'indirizzo del contratto creato, se la transazione consisteva nella creazione di un contratto, altrimenti `null`. -- `logs`: `Array` - Array di oggetti di registro generati da questa transazione. -- `logsBloom`: `DATA`, 256 byte - Filtro Bloom per i client leggeri per recuperare rapidamente i registri correlati. -- `type`: `QUANTITY`: intero del tipo di transazione, `0x0` per le transazioni ereditarie, `0x1` per i tipi di elenco d'accesso, `0x2` per le commissioni dinamiche. +- `to`: `DATA`, 20 byte - indirizzo del destinatario. null quando è una transazione di creazione del contratto. +- `cumulativeGasUsed` : `QUANTITY ` - La quantità totale di gas usata quando questa transazione è stata eseguita nel blocco. +- `effectiveGasPrice` : `QUANTITY` - La somma della commissione di base e della mancia pagata per unità di gas. +- `gasUsed `: `QUANTITY ` - La quantità di gas usata solo da questa specifica transazione. +- `contractAddress `: `DATA`, 20 byte - L'indirizzo del contratto creato, se la transazione era una creazione di contratto, altrimenti `null`. +- `logs`: `Array` - Array di oggetti log, che questa transazione ha generato. +- `logsBloom`: `DATA`, 256 byte - Filtro bloom per i client leggeri per recuperare rapidamente i log correlati. +- `type`: `QUANTITY` - intero del tipo di transazione, `0x0` per le transazioni legacy, `0x1` per i tipi di lista di accesso, `0x2` per le commissioni dinamiche. -Restituisce anche _in alternativa_: +Restituisce inoltre _uno dei seguenti_: -- `root` : `DATA` 32 bytes dello stateRoot post-transazione (pre Byzantium) -- `status`: `QUANTITY` o `1` (successo) o `0` (insuccesso) +- `root` : `DATA` 32 byte della state root post-transazione (pre-Byzantium) +- `status`: `QUANTITY` o `1` (successo) o `0` (fallimento) **Esempio** @@ -1333,11 +1429,15 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","para ### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex} -Restituisce informazioni su un ommer di un blocco in base all'hash e alla posizione dell'indice dell'ommer. +Restituisce informazioni su un ommer di un blocco tramite hash e posizione dell'indice dell'ommer. + + + Prova l'endpoint nel playground + **Parametri** -1. `DATA`, 32 byte - hash di un blocco. +1. `DATA`, 32 byte - L'hash di un blocco. 2. `QUANTITY` - La posizione dell'indice dell'ommer. ```js @@ -1347,7 +1447,8 @@ params: [ ] ``` -**Restituisce** Vedi [eth_getBlockByHash](#eth_getblockbyhash) +**Restituisce** +Vedi [eth_getBlockByHash](#eth_getblockbyhash) **Esempio** @@ -1356,17 +1457,21 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' ``` -Per il risultato vedi [eth_getBlockByHash](#eth_getblockbyhash) +Risultato vedi [eth_getBlockByHash](#eth_getblockbyhash) **Nota**: Un ommer non contiene transazioni individuali. ### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex} -Restituisce informazioni su un ommer di un blocco in base al numero e alla posizione dell'indice dell'ommer. +Restituisce informazioni su un ommer di un blocco tramite numero e posizione dell'indice dell'ommer. + + + Prova l'endpoint nel playground + **Parametri** -1. `QUANTITY|TAG` - il numero di un blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, come nel [parametro predefinito del blocco](/developers/docs/apis/json-rpc/#default-block). +1. `QUANTITY|TAG` - un numero di blocco, o la stringa `"earliest"`, `"latest"`, `"pending"`, `"safe"`, `"finalized"`, come nel [parametro del blocco](/developers/docs/apis/json-rpc/#block-parameter). 2. `QUANTITY` - la posizione dell'indice dell'ommer. ```js @@ -1376,7 +1481,8 @@ params: [ ] ``` -**Restituisce** Vedi [eth_getBlockByHash](#eth_getblockbyhash) +**Restituisce** +Vedi [eth_getBlockByHash](#eth_getblockbyhash) **Nota**: Un ommer non contiene transazioni individuali. @@ -1387,27 +1493,29 @@ params: [ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}' ``` -Per il risultato vedi [eth_getBlockByHash](#eth_getblockbyhash) +Risultato vedi [eth_getBlockByHash](#eth_getblockbyhash) ### eth_newFilter {#eth_newfilter} -Crea un oggetto filtro, basato sulle opzioni di filtro, per avvertire quando lo stato cambia (registri). Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges). +Crea un oggetto filtro, basato sulle opzioni di filtro, per avvertire quando lo stato cambia (registri). +Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges). -**Una nota per specificare i filtri degli argomenti:** Gli argomenti dipendono dall'ordine. Una transazione con un registro con argomenti [A, B] sarà abbinata ai seguenti filtri tematici: +**Una nota sulla specifica dei filtri per argomento:** +Gli argomenti dipendono dall'ordine. Una transazione con un registro con argomenti [A, B] sarà abbinata ai seguenti filtri tematici: -- `[]` "qualsiasi" -- `[A]`: "A in prima posizione (e tutto il resto segue)" -- `[null, B]`: "tutto nella prima posizione e B nella seconda (e tutto il resto segue)" -- `[A, B]`: "A in prima posizione e B in seconda (e tutto il resto segue)" -- `[[A, B], [A, B]]`: "(A OR B) in prima posizione e (A OR B) in seconda posizione (e tutto il resto segue)" +- `[]` "qualsiasi cosa" +- `[A]` "A in prima posizione (e qualsiasi cosa dopo)" +- `[null, B]` "qualsiasi cosa in prima posizione E B in seconda posizione (e qualsiasi cosa dopo)" +- `[A, B]` "A in prima posizione E B in seconda posizione (e qualsiasi cosa dopo)" +- `[[A, B], [A, B]]` "(A O B) in prima posizione E (A O B) in seconda posizione (e qualsiasi cosa dopo)" - **Parametri** -1. `Object` - Le opzioni del filtro: +1. `Object` - Le opzioni di filtro: -- `fromBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero intero del blocco, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato o `"pending"`, `"earliest"` per le transazioni non ancora presenti in un blocco. -- `toBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero intero del blocco, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato o `"pending"`, `"earliest"` per le transazioni non ancora presenti in un blocco. -- `address`: `DATA|Array`, 20 byte - (facoltativo) L'indirizzo del contratto oppure un elenco di indirizzi da cui dovrebbero avere origine i registri. -- `topics`: `Array of DATA`, - (facoltativo) Array di argomenti `DATA` a 32 byte. Gli argomenti dipendono dall'ordine. Ogni argomento può anche essere una matrice di DATA con opzioni "OR". +- `fromBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero di blocco intero, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato, o `"pending"`, `"earliest"` per le transazioni non ancora in un blocco. +- `toBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero di blocco intero, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato, o `"pending"`, `"earliest"` per le transazioni non ancora in un blocco. +- `address`: `DATA|Array`, 20 byte - (facoltativo) Indirizzo del contratto o un elenco di indirizzi da cui dovrebbero originare i log. +- `topics`: `Array di DATA`, - (facoltativo) Array di argomenti `DATA` a 32 byte. Gli argomenti dipendono dall'ordine. Ogni argomento può anche essere una matrice di DATA con opzioni "OR". ```js params: [ @@ -1427,7 +1535,8 @@ params: [ ] ``` -**Restituisce** `QUANTITY` - Un ID filtro. +**Restituisce** +`QUANTITY` - Un ID filtro. **Esempio** @@ -1444,11 +1553,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topic ### eth_newBlockFilter {#eth_newblockfilter} -Crea un filtro nel nodo, per avvisare quando arriva un nuovo blocco. Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges). +Crea un filtro nel nodo, per avvisare quando arriva un nuovo blocco. +Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges). -**Parametri** Nessuno +**Parametri** +Nessuno -**Restituisce** `QUANTITY` - Un ID filtro. +**Restituisce** +`QUANTITY` - Un ID filtro. **Esempio** @@ -1465,11 +1577,14 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[], ### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter} -Crea un filtro nel nodo, per avvisare quando arrivano nuove transazioni in sospeso. Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges). +Crea un filtro nel nodo, per avvisare quando arrivano nuove transazioni in sospeso. +Per verificare se lo stato è cambiato, chiama [eth_getFilterChanges](#eth_getfilterchanges). -**Parametri** Nessuno +**Parametri** +Nessuno -**Restituisce** `QUANTITY` - Un ID filtro. +**Restituisce** +`QUANTITY` - Un ID filtro. **Esempio** @@ -1486,7 +1601,8 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter" ### eth_uninstallFilter {#eth_uninstallfilter} -Disinstalla un filtro con un dato ID. Dovrebbe essere sempre chiamato quando l'orologio non è più necessario. Inoltre i filtri scadono quando non vengono richiesti con [eth_getFilterChanges](#eth_getfilterchanges) per un periodo di tempo. +Disinstalla un filtro con un dato ID. Dovrebbe essere sempre chiamato quando l'orologio non è più necessario. +Inoltre, i filtri vanno in timeout quando non vengono richiesti con [eth_getFilterChanges](#eth_getfilterchanges) per un certo periodo di tempo. **Parametri** @@ -1498,7 +1614,8 @@ params: [ ] ``` -**Restituisce** `Boolean` - `true` se il filtro è stato disinstallato con successo, altrimenti `false`. +**Restituisce** +`Boolean` - `true` se il filtro è stato disinstallato correttamente, altrimenti `false`. **Esempio** @@ -1519,7 +1636,7 @@ Metodo di sondaggio per un filtro, che restituisce un array di registri che si s **Parametri** -1. `QUANTITY` - L'ID del filtro. +1. `QUANTITY` - l'ID del filtro. ```js params: [ @@ -1527,20 +1644,24 @@ params: [ ] ``` -**Restituisce** `Array` - Array di oggetti registro, o un array vuoto se nulla è cambiato dall'ultimo sondaggio. - -- Per i filtri creati con `eth_newBlockFilter` vengono restituiti hash di blocco (`DATA`, 32 byte), ad esempio `["0x3454645634534..."]`. -- Per i filtri creati con `eth_newPendingTransactionFiltro` vengono restituiti hash di transazione (`DATA`, 32 byte), ad esempio `["0x6345343454645..."]`. -- Per i filtri creati con `eth_newFiltro` i registri sono oggetti con i seguenti parametri: - - `removed`: `TAG` - `true` quando il registro è stato rimosso, a causa di una riorganizzazione a catena. `false` se è un registro valido. - - `transactionIndex`: `QUANTITY` - numero intero della posizione dell'indice del registro nel blocco. `null` quando il registro è in sospeso. - - `transactionIndex`: `QUANTITY` - numero intero del registro della posizione dell'indice delle transazioni da cui è stato creato. `null` quando il registro è in sospeso. - - `transactionHash`: `DATA`, 32 byte - hash delle transazioni da cui è stato creato il registro. `null` quando il registro è in sospeso. - - `blockHash`: `DATA`, 32 byte - hash del blocco in cui si trovava questo registro. `null` quando è in sospeso. `null` quando il registro è in sospeso. - - `blockNumber`: `QUANTITY` il numero di blocco in cui si trovava questo registro. `null` quando è in sospeso. `null` quando il registro è in sospeso. - - `address`: `DATI`, 20 byte - indirizzo da cui è nato questo registro. - - `data`: `DATA` - contiene zero o più argomenti non indicizzati da 32 byte del registro. - - `topics`: `Array of DATA` - Array da 0 a 432 byte di `DATA` di argomenti di registro indicizzati. (In _solidity_: il primo argomento è l'_hash_ della firma dell'evento (ad es. `Deposit(address,bytes32,uint256)`), tranne se hai dichiarato l'evento con lo specificatore `anonymous` +**Restituisce** +`Array` - Array di oggetti log, o un array vuoto se non è cambiato nulla dall'ultimo polling. + +- Per i filtri creati con `eth_newBlockFilter` vengono restituiti hash di blocco (`DATA`, 32 byte), ad es., `["0x3454645634534..."]`. + +- Per i filtri creati con `eth_newPendingTransactionFilter` vengono restituiti hash di transazione (`DATA`, 32 byte), ad es., `["0x6345343454645..."]`. + +- Per i filtri creati con `eth_newFilter` i log sono oggetti con i seguenti parametri: + - `removed`: `TAG` - `true` se il log è stato rimosso a causa di una riorganizzazione della catena. `false` se è un log valido. + - `logIndex`: `QUANTITY` - intero della posizione dell'indice del log nel blocco. `null` se il log è in sospeso. + - `transactionIndex`: `QUANTITY` - intero della posizione dell'indice della transazione da cui è stato creato il log. `null` se il log è in sospeso. + - `transactionHash`: `DATA`, 32 byte - hash della transazione da cui è stato creato questo log. `null` se il log è in sospeso. + - `blockHash`: `DATA`, 32 byte - hash del blocco in cui si trovava questo log. `null` se è in sospeso. `null` se il log è in sospeso. + - `blockNumber`: `QUANTITY` - il numero del blocco in cui si trovava questo log. `null` se è in sospeso. `null` se il log è in sospeso. + - `address`: `DATA`, 20 byte - indirizzo da cui ha avuto origine questo log. + - `data`: `DATA` - dati di log non indicizzati a lunghezza variabile. (In _Solidity_: zero o più argomenti di log non indicizzati a 32 byte.) + - `topics`: `Array di DATA` - Array da 0 a 4 argomenti di log indicizzati `DATA` a 32 byte. (In _Solidity_: il primo argomento è l'_hash_ della firma dell'evento (ad es. `Deposit(address,bytes32,uint256)`), tranne se hai dichiarato l'evento con lo specificatore `anonymous`.) + - **Esempio** ```js @@ -1579,7 +1700,8 @@ params: [ ] ``` -**Restituisce** Vedi [eth_getBlockByHash](#eth_getfilterchanges) +**Restituisce** +Vedi [eth_getFilterChanges](#eth_getfilterchanges) **Esempio** @@ -1596,13 +1718,13 @@ Restituisce un array di tutti i registri che corrispondono a un dato oggetto fil **Parametri** -1. `Object` - Le opzioni del filtro: +1. `Object` - Le opzioni di filtro: -- `fromBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero intero del blocco, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato o `"pending"`, `"earliest"` per le transazioni non ancora presenti in un blocco. -- `toBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero intero del blocco, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato o `"pending"`, `"earliest"` per le transazioni non ancora presenti in un blocco. -- `address`: `DATA|Array`, 20 byte - (facoltativo) L'indirizzo del contratto oppure un elenco di indirizzi da cui dovrebbero avere origine i registri. -- `topics`: `Array of DATA`, - (facoltativo) Array di argomenti `DATA` a 32 byte. Gli argomenti dipendono dall'ordine. Ogni argomento può anche essere una matrice di DATA con opzioni "OR". -- `blockhash`: `DATI`, 32 byte - (facoltativo , **future**) Con l'aggiunta di EIP-234, `blockHash` sarà una nuova opzione di filtro che limita i registri restituiti al singolo blocco con l'hash `blockHash` da 32 byte. L'utilizzo di `blockHash` equivale a `fromBlock` = `toBlock` = il numero di blocco con hash `blockHash`. Se `blockHash` è presente nei criteri di filtraggio, non sono permessi né `fromBlock` né `toBlock`. +- `fromBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero di blocco intero, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato, o `"pending"`, `"earliest"` per le transazioni non ancora in un blocco. +- `toBlock`: `QUANTITY|TAG` - (facoltativo, predefinito: `"latest"`) Numero di blocco intero, o `"latest"` per l'ultimo blocco proposto, `"safe"` per l'ultimo blocco sicuro, `"finalized"` per l'ultimo blocco finalizzato, o `"pending"`, `"earliest"` per le transazioni non ancora in un blocco. +- `address`: `DATA|Array`, 20 byte - (facoltativo) Indirizzo del contratto o un elenco di indirizzi da cui dovrebbero originare i log. +- `topics`: `Array di DATA`, - (facoltativo) Array di argomenti `DATA` a 32 byte. Gli argomenti dipendono dall'ordine. Ogni argomento può anche essere una matrice di DATA con opzioni "OR". +- `blockHash`: `DATA`, 32 byte - (facoltativo, **futuro**) Con l'aggiunta di EIP-234, `blockHash` sarà una nuova opzione di filtro che limita i log restituiti al singolo blocco con l'hash a 32 byte `blockHash`. Usare `blockHash` è equivalente a `fromBlock` = `toBlock` = il numero del blocco con l'hash `blockHash`. Se `blockHash` è presente nei criteri di filtro, allora né `fromBlock` né `toBlock` sono consentiti. ```js params: [ @@ -1614,7 +1736,8 @@ params: [ ] ``` -**Restituisce** Vedi [eth_getBlockByHash](#eth_getfilterchanges) +**Restituisce** +Vedi [eth_getFilterChanges](#eth_getfilterchanges) **Esempio** @@ -1625,13 +1748,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics" Risultato vedi [eth_getFilterChanges](#eth_getfilterchanges) -## Esempio di utilizzo {#usage-example} +## Esempio d'uso {#usage-example} -### Distribuire un contratto utilizzando JSON_RPC {#deploying-contract} +### Distribuzione di un contratto tramite JSON-RPC {#deploying-contract} -Questa sezione include una dimostrazione di come distribuire un contratto utilizzando solo l'interfaccia RPC. Esistono vie alternative per la distribuzione di contratti in cui questa complessità viene eliminata tramite astrazione, ad esempio utilizzando librerie costruite partendo dall'interfaccia RPC, come [web3. s](https://web3js.readthedocs.io/) e [web3.py](https://github.com/ethereum/web3.py). Queste astrazioni sono generalmente più facili da capire e meno soggette a errori, ma è comunque utile capire cosa succede dietro le quinte. +Questa sezione include una dimostrazione di come distribuire un contratto utilizzando solo l'interfaccia RPC. Esistono percorsi alternativi per distribuire i contratti in cui questa complessità viene astratta, ad esempio, utilizzando librerie costruite sull'interfaccia RPC come [web3.js](https://web3js.readthedocs.io/) e [web3.py](https://github.com/ethereum/web3.py). Queste astrazioni sono generalmente più facili da capire e meno soggette a errori, ma è comunque utile capire cosa succede dietro le quinte. -Di seguito, trovi un semplice contratto intelligente chiamato `Multiply7`, che sarà distribuito usando l'interfaccia JSON-RPC a un nodo di Ethereum. Questo tutorial presuppone che il lettore stia già eseguendo un nodo Geth. Maggiori informazioni sui nodi e sui client sono disponibili [qui](/developers/docs/nodes-and-clients/run-a-node). Fare riferimento alla documentazione del singolo [client](/developers/docs/nodes-and-clients/) per capire come avviare HTTP JSON-RPC per i client non-Geth. La maggior parte dei client serve di default su `localhost:8545`. +Quello che segue è un semplice contratto intelligente chiamato `Multiply7` che sarà distribuito tramite l'interfaccia JSON-RPC a un nodo Ethereum. Questo tutorial presuppone che il lettore stia già eseguendo un nodo Geth. Maggiori informazioni su nodi e client sono disponibili [qui](/developers/docs/nodes-and-clients/run-a-node). Fai riferimento alla documentazione dei singoli [client](/developers/docs/nodes-and-clients/) per vedere come avviare l'HTTP JSON-RPC per i client non Geth. La maggior parte dei client serve per impostazione predefinita su `localhost:8545`. ```javascript contract Multiply7 { @@ -1643,7 +1766,7 @@ contract Multiply7 { } ``` -La prima cosa da fare è assicurarsi che l'interfaccia HTTP RPC sia abilitata. Questo significa che forniamo a Geth il flag `--http` all'avvio. In questo esempio usiamo il nodo Geth su una catena di sviluppo privata. Utilizzando questo approccio non abbiamo bisogno di ether sulla rete reale. +La prima cosa da fare è assicurarsi che l'interfaccia HTTP RPC sia abilitata. Ciò significa che forniamo a Geth il flag `--http` all'avvio. In questo esempio usiamo il nodo Geth su una catena di sviluppo privata. Utilizzando questo approccio non abbiamo bisogno di ether sulla rete reale. ```bash geth --http --dev console 2>>geth.log @@ -1651,10 +1774,10 @@ geth --http --dev console 2>>geth.log Questo avvierà l'interfaccia HTTP RPC su `http://localhost:8545`. -Possiamo verificare l'esecuzione dell'interfaccia recuperando l'indirizzo (ottenendo il primo indirizzo dall'array di conti) e il saldo di coinbase utilizzando [curl](https://curl.se). Si noti che i dati in questi esempi saranno diversi sul nodo locale. Se vuoi provare questi comandi, sostituisci i parametri di richiesta nella seconda richiesta di curl con il risultato restituito dalla prima. +Possiamo verificare che l'interfaccia sia in esecuzione recuperando l'indirizzo coinbase (ottenendo il primo indirizzo dall'array di account) e il saldo usando [curl](https://curl.se). Si noti che i dati in questi esempi saranno diversi sul nodo locale. Se vuoi provare questi comandi, sostituisci i parametri di richiesta nella seconda richiesta di curl con il risultato restituito dalla prima. ```bash -curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[]", "id":1}' -H "Content-Type: application/json" localhost:8545 +curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[], "id":1}' -H "Content-Type: application/json" localhost:8545 {"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]} curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545 @@ -1668,9 +1791,9 @@ web3.fromWei("0x1639e49bba16280000", "ether") // "410" ``` -Ora che ci sono ether nella nostra catena di sviluppo privata, possiamo distribuire il contratto. Il primo passo è quello di compilare il contratto Multiply7 al codice di byte che può essere inviato all'EVM. Per installare solc, il compilatore Solidity, seguire la [documentazione Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Potresti voler utilizzare una versione `solc` più vecchia che corrisponda [ alla versione del compilatore utilizzata per il nostro esempio](https://github.com/ethereum/solidity/releases/tag/v0.4.20).) +Ora che ci sono ether nella nostra catena di sviluppo privata, possiamo distribuire il contratto. Il primo passo è quello di compilare il contratto Multiply7 al codice di byte che può essere inviato all'EVM. Per installare solc, il compilatore di Solidity, segui la [documentazione di Solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Potresti voler usare una release `solc` più vecchia per farla corrispondere alla [versione del compilatore usata per il nostro esempio](https://github.com/ethereum/solidity/releases/tag/v0.4.20).) -Il passo successivo è quello di compilare il contratto Multiply7 al codice di byte che può essere inviato all'EVM. +Il passo successivo è compilare il contratto Multiply7 in bytecode che può essere inviato all'EVM. ```bash echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin @@ -1680,7 +1803,7 @@ Binary: 6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029 ``` -Ora che abbiamo il codice compilato, dobbiamo determinare quanto carburante occorre per distribuirlo. L'interfaccia RPC ha un metodo `eth_estimateGas` che ci darà una stima. +Ora che abbiamo il codice compilato, dobbiamo determinare quanto carburante occorre per distribuirlo. L'interfaccia RPC ha un metodo `eth_estimateGas` che ci fornirà una stima. ```bash curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545 @@ -1694,7 +1817,8 @@ curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from {"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"} ``` -La transazione è accettata dal nodo e viene restituito un hash di transazione. Questo hash può essere usato per tracciare la transazione. Il passo successivo è quello di determinare l'indirizzo dove il nostro contratto è distribuito. Ogni transazione eseguita creerà una ricevuta. Questa ricevuta contiene varie informazioni sulla transazione, ad esempio, in quale blocco è stata inclusa e quanto carburante è stato usato dall'EVM. Se una transazione crea un contratto, ne conterrà anche l'indirizzo. Possiamo recuperare la ricevuta con il metodo RPC `eth_getTransactionReceipt`. +La transazione è accettata dal nodo e viene restituito un hash di transazione. Questo hash può essere usato per tracciare la transazione. Il passo successivo è quello di determinare l'indirizzo dove il nostro contratto è distribuito. Ogni transazione eseguita creerà una ricevuta. Questa ricevuta contiene varie informazioni sulla transazione, ad esempio, in quale blocco è stata inclusa e quanto carburante è stato usato dall'EVM. Se una transazione +crea un contratto, ne conterrà anche l'indirizzo. Possiamo recuperare la ricevuta con il metodo RPC `eth_getTransactionReceipt`. ```bash curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545 @@ -1705,9 +1829,9 @@ Il nostro contratto è stato creato su `0x4d03d617d700cf81935d7f797f4e2ae7196482 #### Interagire con i contratti intelligenti {#interacting-with-smart-contract} -In questo esempio invieremo una transazione usando `eth_sendTransaction` al metodo `multiply` del contratto. +In questo esempio, invieremo una transazione usando `eth_sendTransaction` al metodo `multiply` del contratto. -`eth_sendTransaction` richiede diversi argomenti, in particolare `from`, `to` e `data`. `From` è l'indirizzo pubblico del nostro conto, mentre `to` è l'indirizzo del contratto. L'argomento `data` contiene un payload che definisce quale metodo deve essere chiamato e con quali argomenti. È qui che entra in gioco l'[ABI (interfaccia binaria dell'applicazione)](https://docs.soliditylang.org/en/latest/abi-spec.html). L'ABI è un file JSON che determina come definire e codificare i dati per l'EVM. +`eth_sendTransaction` richiede diversi argomenti, in particolare `from`, `to` e `data`. `from` è l'indirizzo pubblico del nostro account e `to` è l'indirizzo del contratto. L'argomento `data` contiene un payload che definisce quale metodo deve essere chiamato e con quali argomenti. È qui che entra in gioco l'[ABI (application binary interface)](https://docs.soliditylang.org/en/latest/abi-spec.html). L'ABI è un file JSON che determina come definire e codificare i dati per l'EVM. I byte del payload definiscono quale metodo viene chiamato nel contratto. Si tratta dei primi 4 byte dall'hash Keccak sul nome della funzione e sui suoi tipi di argomento, con codifica esadecimale. La funzione di moltiplicazione accetta un uint che è un alias per uint256. Ci ritroviamo quindi con: @@ -1716,13 +1840,13 @@ web3.sha3("multiply(uint256)").substring(0, 10) // "0xc6888fa1" ``` -Il passo successivo è codificare gli argomenti. Vi è solo un uint256, ad esempio il valore 6. L'ABI ha una sezione che specifica come codificare i tipi uint256. +Il passo successivo è la codifica degli argomenti. Vi è solo un uint256, ad esempio il valore 6. L'ABI ha una sezione che specifica come codificare i tipi uint256. -`int: enc(X)` è la codifica big-endian in complemento a due di X, riempita sul lato di ordine superiore (sinistro) con 0xff per X negativo e con zero > byte per X positivo, in modo tale che la lunghezza sia un multiplo di 32 byte. +`int: enc(X)` è la codifica in complemento a due big-endian di X, riempita sul lato di ordine superiore (sinistro) con 0xff per X negativo e con byte zero per X positivo, in modo che la lunghezza sia un multiplo di 32 byte. -Si ottiene la codifica `0000000000000000000000000000000000000000000000000000000000000006`. +Questo codifica in `0000000000000000000000000000000000000000000000000000000000000006`. -Combinando il selettore di funzione e l'argomento codificato, otterremo i dati `0xc6888fa100000000000000000000000000000000000000000000000000000000000000000000000000000006`. +Combinando il selettore di funzione e l'argomento codificato, i nostri dati saranno `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`. A questo punto possiamo inviare al nodo: @@ -1755,7 +1879,7 @@ Dall'invio di una transazione, è stato restituito un hash di transazione. Recup } ``` -La ricevuta contiene un registro. Questo registro è stato generato da EVM sull'esecuzione della transazione e incluso nella ricevuta. La funzione `multiply` mostra che l'evento `Print` è stato lanciato con i tempi di input 7. Poiché l'argomento per l'evento `Print` era un uint256, possiamo decodificarlo secondo le regole ABI, ottenendo così il decimale 42 previsto. Oltre ai dati, vale la pena notare che gli argomenti possono essere utilizzati per determinare quale evento ha creato il registro: +La ricevuta contiene un registro. Questo registro è stato generato dall'EVM sull'esecuzione della transazione e incluso nella ricevuta. La funzione `multiply` mostra che l'evento `Print` è stato generato con l'input moltiplicato per 7. Poiché l'argomento per l'evento `Print` era un uint256, possiamo decodificarlo secondo le regole ABI, il che ci lascerà con il decimale atteso 42. Oltre ai dati, vale la pena notare che gli argomenti possono essere utilizzati per determinare quale evento ha creato il registro: ```javascript web3.sha3("Print(uint256)") @@ -1766,8 +1890,8 @@ Questa è stata solo una breve introduzione su alcuni dei compiti più comuni, d ## Argomenti correlati {#related-topics} -- [Specifiche di JSON-RPC](http://www.jsonrpc.org/specification) -- [ Nodi e client](/developers/docs/nodes-and-clients/) +- [Specifica JSON-RPC](http://www.jsonrpc.org/specification) +- [Nodi e client](/developers/docs/nodes-and-clients/) - [API JavaScript](/developers/docs/apis/javascript/) -- [API del backend](/developers/docs/apis/backend/) +- [API di backend](/developers/docs/apis/backend/) - [Client di esecuzione](/developers/docs/nodes-and-clients/#execution-clients) diff --git a/public/content/translations/it/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/it/developers/docs/data-and-analytics/block-explorers/index.md index fd3b872c6ab..60ddb47bdca 100644 --- a/public/content/translations/it/developers/docs/data-and-analytics/block-explorers/index.md +++ b/public/content/translations/it/developers/docs/data-and-analytics/block-explorers/index.md @@ -5,7 +5,7 @@ lang: it sidebarDepth: 3 --- -I block explorer sono il tuo portale sui dati di Ethereum. Puoi usarli per vedere in tempo reale dati su blocchi, transazioni, validatori, conti e altre attività on-chain. +I block explorer sono il tuo portale sui dati di Ethereum. Puoi usarli per vedere in tempo reale i dati su blocchi, transazioni, validatori, account e altre attività on-chain. ## Prerequisiti {#prerequisites} @@ -13,19 +13,17 @@ I block explorer sono il tuo portale sui dati di Ethereum. Puoi usarli per veder ## Servizi {#services} -- [Etherscan](https://etherscan.io/): _disponibile anche in cinese, coreano, russo e giapponese_ +- [Etherscan](https://etherscan.io/) -_Disponibile anche in cinese, coreano, russo e giapponese_ - [3xpl](https://3xpl.com/ethereum) - [Beaconcha.in](https://beaconcha.in/) -- [Blockchair](https://blockchair.com/ethereum): _disponibile anche in spagnolo, francese, italiano, olandese, portoghese, russo, cinese e farsi_ +- [Blockchair](https://blockchair.com/ethereum) -_Disponibile anche in spagnolo, francese, italiano, olandese, portoghese, russo, cinese e farsi_ - [Blockscout](https://eth.blockscout.com/) - [Chainlens](https://www.chainlens.com/) - [DexGuru Block Explorer](https://ethereum.dex.guru/) - [Etherchain](https://www.etherchain.org/) -- [Ethernow](https://www.ethernow.xyz/) -- [Ethplorer](https://ethplorer.io/): _disponibile anche in cinese, spagnolo, francese, turco, russo, coreano e vietnamita_ +- [Ethplorer](https://ethplorer.io/) -_Disponibile anche in cinese, spagnolo, francese, turco, russo, coreano e vietnamita_ - [EthVM](https://www.ethvm.com/) - [OKLink](https://www.oklink.com/eth) -- [Rantom](https://rantom.app/) - [Ethseer](https://ethseer.io) ## Strumenti open source {#open-source-tools} @@ -39,7 +37,7 @@ Ethereum è trasparente per definizione, quindi tutto è verificabile. I block e Ecco un riepilogo dei tipi di dati ottenibili da un block explorer. -### Dati d'esecuzione {#execution-data} +### Dati di esecuzione {#execution-data} Ogni 12 secondi vengono aggiunti nuovi blocchi a Ethereum (a meno che un propositore del blocco salti il proprio turno), quindi un flusso di dati quasi costante viene aggiunto agli esploratori di blocchi. I blocchi contengono molti dati importanti che potrebbero risultare utili: @@ -95,7 +93,7 @@ Gli esploratori di blocchi sono diventati un punto di riferimento comune per tra - Limite di gas: I numeri massimi di unità di gas che questa transazione può consumare - Gas usato: L'importo effettivo di unità di gas che la transazione ha consumato - Prezzo del gas: Il prezzo fissato per unità di gas -- Nonce: Il numero della transazione per l'indirizzo `from` (tieni a mente che inizia a 0, quindi un nonce di `100`, sarebbe in realtà la 101° transazione inviata da questo conto +- Nonce - Il numero di transazione per l'indirizzo `from` (tenere presente che questo inizia da 0, quindi un nonce di `100` sarebbe in realtà la 101a transazione inviata da questo account) - Dati di input - Ogni informazione aggiuntiva richiesta dalla transazione ### Conti {#accounts} @@ -147,7 +145,7 @@ Alcuni dati del blocco si preoccupano della salute di Ethereum in modo più olis ## Dati del livello di consenso {#consensus-layer-data} -### Epoche {#epoch} +### Epoca {#epoch} Per motivi di sicurezza, vengono creati commissioni randomizzate di validatori alla fine di ogni epoca (ogni 6,4 minuti). I dati relativi alle epoche includono: @@ -156,7 +154,7 @@ Per motivi di sicurezza, vengono creati commissioni randomizzate di validatori a - Ora - L'ora in cui è terminata l'epoca - Attestazioni - Il numero di attestazioni nell'epoca (voti per i blocchi negli slot) - Depositi - Il numero di depositi di ETH inclusi nell'epoca (per diventare validatori, occorre mettere ETH in staking) -- Tagli - Numero di sanzioni date ai propositori di blocchi o agli attestatori +- Tagli - Numero di sanzioni date ai propositori di blocchi o attestatori - Partecipazione al voto - L'importo di ETH in staking usato per attestare i blocchi - Validatori - Numero di validatori attivi per ogni epoca - Saldo medio del validatore - Saldo medio per i validatori attivi @@ -236,21 +234,18 @@ I dati di livello superiore del livello di consenso includono quanto segue: - ETH in staking - Importo di ETH in staking nella rete - Saldo medio - Saldo medio di ETH dei validatori -## Block explorer {#block-explorers} +## Esploratori di blocchi {#block-explorers} -- [Etherscan](https://etherscan.io/) - un esploratore di blocchi che puoi usare per recuperare i dati per la Rete Principale di Ethereum e la rete di prova Sepolia -- [3xpl](https://3xpl.com/ethereum) - un esploratore di Ethereum open source e privo di inserzioni che consente di scaricare i propri dataset -- [Beaconcha.in](https://beaconcha.in/) - un esploratore di blocchi open source per la Rete Principale di Ethereum e la rete di prova di Sepolia -- [Blockchair](https://blockchair.com/ethereum): l'esploratore di Ethereum più privato. Anche per ordinare e filtrare i dati (mempool) -- [Etherchain](https://www.etherchain.org/) - un esploratore di blocchi per la rete principale di Ethereum -- [Ethplorer](https://ethplorer.io/) - un esploratore di blocchi incentrato sui token per la Rete Principale di Ethereum e la rete di prova di Sepolia -- [Rantom](https://rantom.app/): Un visualizzatore di transazioni NFT e DeFi open source e intuitivo per gli utenti, per una visione dettagliata -- [Ethernow](https://www.ethernow.xyz/): un esploratore in tempo reale delle transazioni che ti consente di visualizzare il livello pre-catena della Rete Principale di Ethereum -- [Otterscan](https://otterscan.io/) - un esploratore di blocchi open source alternativo per Ethereum +- [Etherscan](https://etherscan.io/) - un esploratore di blocchi che puoi usare per recuperare dati per la Rete Principale di Ethereum e la rete di test. +- [3xpl](https://3xpl.com/ethereum) - un esploratore di Ethereum open source e senza pubblicità che consente di scaricare i suoi set di dati. +- [Beaconcha.in](https://beaconcha.in/) - un esploratore di blocchi open source per la Rete Principale di Ethereum e la rete di test. +- [Blockchair](https://blockchair.com/ethereum) - l'esploratore di Ethereum più privato. Anche per ordinare e filtrare i dati (mempool) +- [Etherchain](https://www.etherchain.org/) - un esploratore di blocchi per la Rete Principale di Ethereum. +- [Ethplorer](https://ethplorer.io/) - un esploratore di blocchi incentrato sui token per la Rete Principale di Ethereum e la rete di test di Kovan. -## Approfondimenti {#further-reading} +## Letture consigliate {#further-reading} -_Conosci una risorsa pubblica che ti è stata utile? Modifica questa pagina e aggiungila!_ +_Conosci una risorsa della comunità che ti è stata utile? Modifica questa pagina e aggiungila!_ ## Argomenti correlati {#related-topics} 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..ea0bc0a8c72 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 @@ -1,55 +1,72 @@ --- title: Dati e analisi -description: Come ottenere analisi e dati sulla catena da utilizzare nelle dapp +description: Come ottenere dati e analisi on-chain da utilizzare nelle tue dApp lang: it --- ## Introduzione {#Introduction} -Mentre l'utilizzo della rete continua a crescere, una quantità crescente di informazioni preziose esisterà nei dati on-chain. Al rapido aumentare del volume di dati, il calcolo e l'aggregazione di queste informazioni a scopo di segnalazione o per guidare una dapp possono richiedere notevoli sforzi in termini di tempo e processi. +Con la continua crescita dell'utilizzo della rete, una quantità crescente di informazioni preziose sarà presente nei dati on-chain. Al rapido aumentare del volume di dati, il calcolo e l'aggregazione di queste informazioni a scopo di segnalazione o per guidare una dapp possono richiedere notevoli sforzi in termini di tempo e processi. Sfruttare i fornitori di dati esistenti può accelerare lo sviluppo, produrre risultati più precisi e ridurre gli sforzi di manutenzione in corso. Ciò permetterà al team di concentrarsi sulla funzionalità principale che il loro progetto si prefigge di fornire. ## Prerequisiti {#prerequisites} -Occorre comprendere il concetto base di [Block Explorers](/developers/docs/data-and-analytics/block-explorers/) per capire meglio come usarli nell'ambito dell'analisi dei dati. Inoltre, è bene familiarizzare con il concetto di [indice](/glossary/#index) per comprendere i vantaggi che offrono per un design di sistema. +Dovresti comprendere il concetto di base degli [esploratori di blocchi](/developers/docs/data-and-analytics/block-explorers/) per capire meglio come utilizzarli nel contesto dell'analisi dei dati. Inoltre, familiarizza con il concetto di [indice](/glossary/#index) per comprendere i vantaggi che aggiungono alla progettazione di un sistema. -In termini di fondamenti architettonici, occorre comprendere che cosa sono le [API](https://www.wikipedia.org/wiki/API) e [REST](https://www.wikipedia.org/wiki/Representational_state_transfer), anche a livello teorico. +In termini di fondamenti architettonici, è importante comprendere cosa sono un'[API](https://www.wikipedia.org/wiki/API) e [REST](https://www.wikipedia.org/wiki/Representational_state_transfer), anche solo in teoria. -## Esploratori dei blocchi {#block-explorers} +## Esploratori di blocchi {#block-explorers} -Molti [Esploratori di Blocchi](/developers/docs/data-and-analytics/block-explorers/) offrono gateway dell'[API](https://www.wikipedia.org/wiki/API) di [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer), che forniranno visibilità agli sviluppatori in dati in tempo reale sui blocchi, le transazioni, i validatori, i conti e altre attività on-chain. +Molti [esploratori di blocchi](/developers/docs/data-and-analytics/block-explorers/) offrono gateway [API](https://www.wikipedia.org/wiki/API) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) che forniscono agli sviluppatori visibilità sui dati in tempo reale su blocchi, transazioni, validatori, account e altre attività on-chain. -Gli sviluppatori possono quindi elaborare e trasformare questi dati per fornire agli utenti informazioni e interazioni uniche con la [blockchain](/glossary/#blockchain). Ad esempio, [Etherscan](https://etherscan.io) fornisce i dati d'esecuzione e consenso per ogni slot di 12 secondi. +Gli sviluppatori possono quindi elaborare e trasformare questi dati per offrire ai propri utenti approfondimenti e interazioni uniche con la [blockchain](/glossary/#blockchain). Ad esempio, [Etherscan](https://etherscan.io) e [Blockscout](https://eth.blockscout.com) forniscono dati di esecuzione e consenso per ogni slot di 12 secondi. ## The Graph {#the-graph} -La [rete Graph](https://thegraph.com/) è un protocollo di indicizzazione decentralizzato per l'organizzazione dei dati della blockchain. Invece di costruire e gestire archivi di dati off-chain e centralizzati per aggregare dati on-chain, con The Graph gli sviluppatori possono creare applicazioni senza server che vengono eseguite interamente su infrastrutture pubbliche. +[The Graph](https://thegraph.com/) è un protocollo di indicizzazione che fornisce un modo semplice per interrogare i dati della blockchain tramite API aperte note come sottografi. -Usando [GraphQL](https://graphql.org/), gli sviluppatori possono interrogare una qualsiasi delle API aperte curate, note come grafici secondari, per acquisire le informazioni necessarie a guidare la propria dapp. Interrogando questi grafici secondari indicizzati, i Rapporti e le dapp non solo ricevono benefici di prestazioni e scalabilità, ma anche l'accuratezza integrata, fornita dal consenso della rete. Con l'aggiunta di nuovi miglioramenti e/o sotto-grafici alla rete, i vostri progetti possono iterare rapidamente per sfruttare questi miglioramenti. +Con The Graph, gli sviluppatori possono beneficiare di: -## Diversità dei client +- Indicizzazione decentralizzata: consente l'indicizzazione dei dati della blockchain tramite più indicizzatori, eliminando così ogni singolo punto di errore +- Query GraphQL: fornisce una potente interfaccia GraphQL per l'interrogazione di dati indicizzati, rendendo il recupero dei dati estremamente semplice +- Personalizzazione: definisci la tua logica per la trasformazione e l'archiviazione dei dati della blockchain e riutilizza i sottografi pubblicati da altri sviluppatori su The Graph Network -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/). +Segui questa guida [rapida](https://thegraph.com/docs/en/quick-start/) per creare, distribuire e interrogare un sottografo in 5 minuti. + +## Diversità dei client {#client-diversity} + +La [diversità dei client](/developers/docs/nodes-and-clients/client-diversity/) è importante per la salute generale della rete di Ethereum perché fornisce resilienza a bug ed exploit. Ora esistono diverse dashboard sulla diversità dei 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](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. +[Dune Analytics](https://dune.com/) pre-elabora i dati della blockchain in tabelle di database relazionali (DuneSQL), consente agli utenti di interrogare i dati della blockchain utilizzando SQL e di creare dashboard basate sui risultati delle query. I dati on-chain sono organizzati in 4 tabelle grezze: `blocks`, `transactions`, (event) `logs` e (call) `traces`. 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. + +## SQD {#sqd} + +[SQD](https://sqd.dev/) è una piattaforma dati decentralizzata e iperscalabile, ottimizzata per fornire un accesso efficiente e senza autorizzazione a grandi volumi di dati. Attualmente serve dati storici on-chain, inclusi i log degli eventi, le ricevute delle transazioni, le tracce e le differenze di stato per transazione. SQD offre un potente toolkit per la creazione di pipeline personalizzate di estrazione ed elaborazione dei dati, raggiungendo una velocità di indicizzazione fino a 150.000 blocchi al secondo. + +Per iniziare, visita la [documentazione](https://docs.sqd.dev/) o consulta gli [esempi EVM](https://github.com/subsquid-labs/squid-evm-examples) di ciò che puoi creare con SQD. + +## SubQuery Network {#subquery-network} -## Rete di SubQuery {#subquery-network} +[SubQuery](https://subquery.network/) è un indicizzatore di dati leader che offre agli sviluppatori API veloci, affidabili, decentralizzate e personalizzate per i loro progetti 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. -[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 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 Docker locale per i test, prima di andare in produzione su un [servizio gestito di SubQuery](https://managedservice.subquery.network/) o sulla [rete decentralizzata di SubQuery](https://app.subquery.network/dashboard). -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). +## EVM Query Language {#evm-query-language} -## Ethernow - Programma dei dati del Mempool {#ethernow} -[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/). +EVM Query Language (EQL) è un linguaggio simile a SQL progettato per interrogare le catene EVM (Macchina Virtuale di Ethereum). L'obiettivo finale di EQL è supportare query relazionali complesse sugli elementi di prima classe della catena EVM (blocchi, account e transazioni), fornendo al contempo a sviluppatori e ricercatori una sintassi ergonomica per l'uso quotidiano. Con EQL, gli sviluppatori possono recuperare i dati della blockchain utilizzando una sintassi familiare simile a SQL ed eliminare la necessità di un complesso codice boilerplate. EQL supporta richieste di dati blockchain standard (ad es. recuperare il nonce e il saldo di un account su Ethereum o recuperare la dimensione e il timestamp del blocco corrente) e aggiunge continuamente supporto per richieste e set di funzionalità più complessi. -## Letture consigliate {#further-reading} +## Ulteriori letture {#further-reading} -- [Panoramica della rete Graph](https://thegraph.com/docs/en/about/) -- [GraphQL Playground](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [Esplorazione dei dati cripto I: architetture del flusso di dati](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [Panoramica di Graph Network](https://thegraph.com/docs/en/about/) +- [Graph Query Playground](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) - [Esempi di codice API su EtherScan](https://etherscan.io/apis#contracts) -- [Esploratore della Beacon Chain di Beaconcha.in](https://beaconcha.in) -- [Fondamenti di Dune](https://docs.dune.com/#dune-basics) -- [Guida iniziale rapida di Ethereum su SubQuery](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Documentazione API su Blockscout](https://docs.blockscout.com/devs/apis) +- [Esploratore della Beacon Chain Beaconcha.in](https://beaconcha.in) +- [Nozioni di base su Dune](https://docs.dune.com/#dune-basics) +- [Guida rapida di SubQuery Ethereum](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Panoramica di SQD Network](https://docs.sqd.dev/) +- [EVM Query Language](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/it/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/it/developers/docs/data-availability/blockchain-data-storage-strategies/index.md index e5864fd07db..c3eb0443967 100644 --- a/public/content/translations/it/developers/docs/data-availability/blockchain-data-storage-strategies/index.md +++ b/public/content/translations/it/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -16,7 +16,7 @@ Esistono diversi modi per archiviare le informazioni, sia direttamente sulla blo La scelta del metodo da utilizzare si basa su vari criteri: - La fonte delle informazioni. Le informazioni in calldata non possono arrivare direttamente dalla blockchain stessa. -- La destinazione delle informazioni. Calldata è disponibile solo nelle transazioni che ha avviato. Gli eventi non sono affatto accessibili onchain. +- La destinazione delle informazioni. I calldata sono disponibili solo nella transazione che li include. Gli eventi non sono affatto accessibili onchain. - Che livello di seccatura è accettabile? I computer che eseguono nodi completi possono eseguire più elaborazioni dei client leggeri in un'applicazione eseguita nel browser. - È necessario favorire un facile accesso alle informazioni da ogni nodo? - I requisiti di sicurezza. @@ -63,7 +63,7 @@ Calldata si riferisce ai byte inviati come parte della transazione. È archiviat Questo è il metodo più economico per mettere dati permanentemente nella blockchain. Il costo per byte è di 4 unità di gas di esecuzione (se il byte è zero) o 16 unità di gas (per ogni altro valore). Se i dati sono compressi, il che è una pratica standard, allora ogni valore di byte è ugualmente probabile, quindi il costo medio è di circa 15,95 unità di gas per byte. -Al momento i prezzi sono di 12 gwei/gas e 2300 $/ETH, il che significa che il costo è circa di 45 cent al kilobyte. Siccome questo era il metodo più economico prima di EIP-4844, questo è anche il metodo che i rollup utilizzavano per archiviare le informazioni sulle transazioni, che devono essere disponibili per le [contestazioni di errori](https://docs.optimism.io/stack/protocol/overview#fault-proofs), ma non devono necessariamente essere accessibili direttamente onchain. +Al momento della stesura, i prezzi sono di 12 gwei/gas e 2300 $/ETH, il che significa che il costo è di circa 45 centesimi per kilobyte. Siccome questo era il metodo più economico prima di EIP-4844, questo è anche il metodo che i rollup utilizzavano per archiviare le informazioni sulle transazioni, che devono essere disponibili per le [contestazioni di errori](https://docs.optimism.io/stack/protocol/overview#fault-proofs), ma non devono necessariamente essere accessibili direttamente onchain. Ecco gli indirizzi per vedere le transazioni pubblicate da alcuni rollup famosi. 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..c80e7b0e140 100644 --- a/public/content/translations/it/developers/docs/data-availability/index.md +++ b/public/content/translations/it/developers/docs/data-availability/index.md @@ -1,16 +1,16 @@ --- -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 --- "Non fidarti, verifica" è una massima comune su Ethereum. L'idea è che il tuo nodo possa verificare in modo indipendente che le informazioni che riceve siano corrette eseguendo tutte le transazioni nei blocchi che ricevono dai pari per assicurarsi che le modifiche proposte corrispondano precisamente a quelle calcolate indipendentemente dal nodo. Ciò significa che i nodi non devono fidarsi del fatto che i mittenti del blocco siano onesti. Ciò è impossibile se i dati sono mancanti. -La **disponibilità dei dati** si riferisce alla sicurezza che un utente può avere del fatto che i dati necessari per verificare un blocco siano realmente disponibili a tutti i partecipanti alla rete. Per i nodi completi sul livello 1 di Ethereum è relativamente semplice; il nodo completo scarica una copia di tutti i dati in ogni blocco; i dati _devono_ essere disponibili per essere scaricati affinché ciò sia possibile. Un blocco con dati mancanti sarebbe scartato piuttosto che aggiunto alla blockchain. Questa è la "disponibilità dei dati sulla catena" ed è una caratteristica delle blockchain monolitiche. I nodi completi non possono essere indotti ad 'accettare le transazioni non valide poiché scaricano ed eseguono ogni transazione per conto proprio. Tuttavia, per le blockchain modulari, i rollup di livello 2 e i client leggeri, il panorama della disponibilità dei dati è più complesso e richiede procedure di verifica più sofisticate. +**La disponibilità dei dati** si riferisce alla sicurezza che un utente può avere che i dati necessari per verificare un blocco siano realmente disponibili a tutti i partecipanti alla rete. Per i nodi completi sul livello 1 di Ethereum questo è relativamente semplice; il nodo completo scarica una copia di tutti i dati in ogni blocco - i dati _devono_ essere disponibili affinché il download sia possibile. Un blocco con dati mancanti sarebbe scartato piuttosto che aggiunto alla blockchain. Questa è la "disponibilità dei dati sulla catena" ed è una caratteristica delle blockchain monolitiche. I nodi completi non possono essere indotti ad 'accettare le transazioni non valide poiché scaricano ed eseguono ogni transazione per conto proprio. Tuttavia, per le blockchain modulari, i rollup di livello 2 e i client leggeri, il panorama della disponibilità dei dati è più complesso e richiede procedure di verifica più sofisticate. ## Prerequisiti {#prerequisites} -Dovresti avere una buona comprensione dei [fondamenti della blockchain](/developers/docs/intro-to-ethereum/), specialmente dei [meccanismi di consenso](/developers/docs/consensus-mechanisms/). Questa pagina presuppone anche che il lettore abbia familiarità con i [blocchi](/developers/docs/blocks/), le [transazioni](/developers/docs/transactions/), i [nodi](/developers/docs/nodes-and-clients/), le [soluzioni di ridimensionamento](/developers/docs/scaling/) e altri argomenti pertinenti. +Dovresti avere una buona comprensione dei [fondamenti della blockchain](/developers/docs/intro-to-ethereum/), in particolare dei [meccanismi di consenso](/developers/docs/consensus-mechanisms/). Questa pagina presuppone inoltre che il lettore abbia familiarità con [blocchi](/developers/docs/blocks/), [transazioni](/developers/docs/transactions/), [nodi](/developers/docs/nodes-and-clients/), [soluzioni di ridimensionamento](/developers/docs/scaling/) e altri argomenti rilevanti. ## Il problema della disponibilità dei dati {#the-data-availability-problem} @@ -18,67 +18,67 @@ Il problema della disponibilità dei dati è la necessità di dimostrare all'int I [nodi leggeri](/developers/docs/nodes-and-clients/light-clients) e i [rollup di Livello 2](/developers/docs/scaling) sono esempi importanti di partecipanti alla rete che richiedono forti garanzie di disponibilità dei dati ma non possono scaricare ed elaborare da soli i dati delle transazioni. Evitare di scaricare i dati delle transazioni è ciò che rende i nodi leggeri e permette ai rollup di essere soluzioni di ridimensionamento efficaci. -La disponibilità dei dati è anche un problema critico per i futuri client Ethereum ["senza stato"](/roadmap/statelessness) che non hanno bisogno di scaricare e memorizzare i dati di stato per verificare i blocchi. I client senza stato devono ancora essere certi che i dati siano disponibili _da qualche parte_ e sono stati elaborati correttamente. +La disponibilità dei dati è anche una preoccupazione critica per i futuri client Ethereum ["senza stato"](/roadmap/statelessness) che non hanno bisogno di scaricare e archiviare i dati di stato per verificare i blocchi. I client senza stato devono comunque essere certi che i dati siano disponibili _da qualche parte_ e che siano stati elaborati correttamente. -## Soluzioni di disponibilità dei dati {#data-availability-solutions} +## Soluzioni per la disponibilità dei dati {#data-availability-solutions} -### Campionamento della disponibilità dei dati (CDD) {#data-availability-sampling} +### Campionamento della disponibilità dei dati (DAS) {#data-availability-sampling} -Il Campionamento della disponibilità dei dati (DAS) è un modo per la rete di verificare la disponibilità dei dati senza gravare troppo sui singoli nodi. Ogni nodo (compresi i nodi non di staking) scarica un piccolo sottoinsieme selezionato in modo casuale dei dati totali. Scaricare con successo i campioni conferma con elevata certezza che tutti i dati sono disponibili. Ciò si basa sulla codifica di cancellazione dei dati, che espande un dato set di dati con informazioni ridondanti (il modo in cui ciò avviene è di adattare una funzione nota come _polinomiale_ sui dati e di valutare tale polinomiale in punti aggiuntivi). In questo modo è possibile recuperare i dati originali da quelli ridondanti, se necessario. Una conseguenza di questa creazione di dati è che se _qualsiasi_ dei dati originali non è disponibile, la _metà_ dei dati espansi sarà mancante! La quantità di campioni di dati scaricati da ciascun nodo può essere regolata in modo che sia _estremamente_ probabile che almeno uno dei frammenti di dati campionati da ciascun client sia mancante _se_ meno della metà dei dati è realmente disponibile. +Il Campionamento della disponibilità dei dati (DAS) è un modo per la rete di verificare la disponibilità dei dati senza gravare troppo sui singoli nodi. Ogni nodo (compresi i nodi non di staking) scarica un piccolo sottoinsieme selezionato in modo casuale dei dati totali. Scaricare con successo i campioni conferma con elevata certezza che tutti i dati sono disponibili. Questo si basa sulla codifica a cancellazione di dati, che espande un determinato set di dati con informazioni ridondanti (il modo in cui questo viene fatto è adattare una funzione nota come _polinomio_ sui dati e valutare quel polinomio in punti aggiuntivi). In questo modo è possibile recuperare i dati originali da quelli ridondanti, se necessario. Una conseguenza di questa creazione di dati è che se _qualsiasi_ dato originale non è disponibile, _metà_ dei dati espansi andrà persa! La quantità di campioni di dati scaricati da ciascun nodo può essere regolata in modo che sia _estremamente_ probabile che almeno uno dei frammenti di dati campionati da ciascun client risulti mancante _se_ meno della metà dei dati è realmente disponibile. -Il DAS sarà utilizzato per assicurarsi che gli operatori di rollup rendano disponibili i dati della propria transazione in seguito all'implementazione del [Danksharding completo](/roadmap/danksharding/#what-is-danksharding). I nodi Ethereum campioneranno in modo casuale i dati delle transazioni forniti in blob utilizzando lo schema di ridondanza spiegato sopra per garantire che tutti i dati esistano. La stessa tecnica potrebbe essere utilizzata anche per garantire che i produttori di blocchi rendano disponibili tutti i loro dati ai client leggeri sicuri. Allo stesso modo, nell'ambito della [separazione propositore-costruttore](/roadmap/pbs), solo il costruttore di blocchi sarebbe tenuto a elaborare un intero blocco - gli altri validatori verificherebbero utilizzando il campionamento della disponibilità dei dati. +Il DAS sarà utilizzato per assicurare che gli operatori di rollup rendano disponibili i dati delle loro transazioni dopo l'implementazione del [Danksharding completo](/roadmap/danksharding/#what-is-danksharding). I nodi Ethereum campioneranno in modo casuale i dati delle transazioni forniti in blob utilizzando lo schema di ridondanza spiegato sopra per garantire che tutti i dati esistano. La stessa tecnica potrebbe essere utilizzata anche per garantire che i produttori di blocchi rendano disponibili tutti i loro dati ai client leggeri sicuri. Allo stesso modo, nell'ambito della [separazione propositore-costruttore](/roadmap/pbs), solo al costruttore di blocchi sarebbe richiesto di elaborare un intero blocco; gli altri validatori verificherebbero utilizzando il campionamento della disponibilità dei dati. -### Commissioni di disponibilità dei dati {#data-availability-committees} +### Comitati per la disponibilità dei dati {#data-availability-committees} -Le commissioni di disponibilità dei dati (DAC) sono parti fidate che forniscono, o attestano, la disponibilità dei dati. Le DAC sono utilizzabili al posto di [o in combinazione delle](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS. Le garanzie fornite dalle commissioni in termini di sicurezza dipendono dalla loro composizione specifica. Ethereum utilizza sottoinsiemi di validatori a campione per attestare la disponibilità di dati per i nodi leggeri, ad esempio. +Le commissioni di disponibilità dei dati (DAC) sono parti fidate che forniscono, o attestano, la disponibilità dei dati. I DAC possono essere utilizzati al posto del, [o in combinazione con il](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAS. Le garanzie fornite dalle commissioni in termini di sicurezza dipendono dalla loro composizione specifica. Ethereum utilizza sottoinsiemi di validatori a campione per attestare la disponibilità di dati per i nodi leggeri, ad esempio. -Le DAC sono utilizzate anche da alcuni Validium. La DAC è un insieme di nodi fidati che memorizzano copie di dati offline. La DAC è necessaria per rendere i dati disponibili in caso di controversia. I membri della DAC pubblicano anche attestazioni on-chain per dimostrare la reale disponibilità di tali dati. Alcuni Validium sostituiscono le DAC con un sistema di validatori di proof of stake (PoS). Qui chiunque può diventare un validatore e memorizzare dati off-chain. Tuttavia, devono fornire una "cauzione", depositata in un contratto intelligente. Nel caso di comportamenti malevoli, come nel caso in cui il validatore trattenga dati, la cauzione può essere decurtata. Le commissioni per la disponibilità dei dati di proof-of-stake sono molto più sicure delle normali DAC perché incentivano direttamente il comportamento onesto. +Le DAC sono utilizzate anche da alcuni Validium. La DAC è un insieme di nodi fidati che memorizzano copie di dati offline. La DAC è necessaria per rendere i dati disponibili in caso di controversia. I membri del DAC pubblicano anche attestazioni sulla catena per dimostrare che i suddetti dati sono effettivamente disponibili. Alcuni Validium sostituiscono le DAC con un sistema di validatori di proof of stake (PoS). Qui, chiunque può diventare un validatore e archiviare dati fuori dalla catena. Tuttavia, devono fornire una "cauzione", depositata in un contratto intelligente. Nel caso di comportamenti malevoli, come nel caso in cui il validatore trattenga dati, la cauzione può essere decurtata. Le commissioni per la disponibilità dei dati di proof-of-stake sono molto più sicure delle normali DAC perché incentivano direttamente il comportamento onesto. ## Disponibilità dei dati e nodi leggeri {#data-availability-and-light-nodes} -I [ nodi leggeri](/developers/docs/nodes-and-clients/light-clients) devono convalidare la correttezza delle intestazioni dei blocchi che ricevono senza scaricare i dati dei blocchi. Questa leggerezza ha un costo: l'impossibilità di verificare in modo indipendente le intestazioni dei blocchi ri-eseguendo le transazioni a livello locale come fanno i nodi completi. +I [nodi leggeri](/developers/docs/nodes-and-clients/light-clients) devono convalidare la correttezza delle intestazioni dei blocchi che ricevono senza scaricare i dati del blocco. Questa leggerezza ha un costo: l'impossibilità di verificare in modo indipendente le intestazioni dei blocchi ri-eseguendo le transazioni a livello locale come fanno i nodi completi. -I nodi leggeri di Ethereum si affidano a un insieme casuale di 512 validatori assegnati a una _commissione di sincronizzazione_. La commissione di sincronizzazione che agisce come una DAC che segnala ai client leggero che i dati nell'intestazione sono corretti utilizzando una firma crittografica. La commissione di sincronizzazione aggiorna quotidianamente i dati. Ogni intestazione del blocco avverte i nodi leggeri dei validatori che si prevede autorizzino il blocco _successivo_; in questo modo non saranno indotti a fidarsi di un gruppo malintenzionato che finge di essere la vera commissione di sincronizzazione. +I nodi leggeri di Ethereum si affidano a insiemi casuali di 512 validatori assegnati a una _commissione di sincronizzazione_. La commissione di sincronizzazione che agisce come una DAC che segnala ai client leggero che i dati nell'intestazione sono corretti utilizzando una firma crittografica. La commissione di sincronizzazione aggiorna quotidianamente i dati. Ogni intestazione del blocco avvisa i nodi leggeri su quali validatori dovranno firmare il blocco _successivo_, in modo che non possano essere ingannati e indotti a fidarsi di un gruppo malevolo che finge di essere la vera commissione di sincronizzazione. -Tuttavia, cosa succede se un utente malevolo _riuscisse _in qualche modo a passare l'intestazione del blocco malevola ai client leggeri e a convincerli che è stata autorizzata da una commissione di sincronizzazione onesta? In questo caso, l'utente malevolo potrebbe includere transazioni non valide e il client leggero le accetterebbe ciecamente, dato che non è in grado di controllare in modo indipendente tutte le modifiche di stato riassunte nell'intestazione del blocco. Per proteggersi da questa eventualità, il client leggero potrebbe utilizzare le prove di frode. +Tuttavia, cosa succede se un aggressore _riesce_ in qualche modo a passare un'intestazione del blocco malevola ai client leggeri e a convincerli che è stata firmata da una commissione di sincronizzazione onesta? In questo caso, l'utente malevolo potrebbe includere transazioni non valide e il client leggero le accetterebbe ciecamente, dato che non è in grado di controllare in modo indipendente tutte le modifiche di stato riassunte nell'intestazione del blocco. Per proteggersi da questa eventualità, il client leggero potrebbe utilizzare le prove di frode. Il modo in cui funzionano queste prove di frode è che un nodo completo, vedendo una transizione di stato non valida oggetto di gossip nella rete, potrebbe generare rapidamente un piccolo pezzo di dati che dimostri che la transizione di stato proposta non può derivare da un determinato insieme di transazioni e trasmettere tali dati ai pari. I nodi leggeri potrebbero raccogliere queste prove di frode e usarle per scartare le intestazioni dei blocchi malevole, assicurando così di rimanere sulla stessa catena onesta dei nodi completi. Ciò si basa sul fatto che i nodi completi abbiano accesso ai dati completi delle transazioni. Un utente malevolo che trasmette un'intestazione di blocco malevola e non rende disponibili i dati della transazione sarebbe in grado di impedire ai nodi completi di generare prove di frode. I nodi completi potrebbero essere in grado di segnalare un avvertimento su un blocco malevolo, ma non potrebbero sostenere il loro avvertimento con una prova, perché i dati non sono stati resi disponibili per generare la prova! -La soluzione al problema della disponibilità dei dati è il DAS. I nodi leggeri scaricano piccole porzioni casuali dei dati di stato completi e utilizzano i campioni per verificare che l'intero set di dati sia disponibile. È possibile calcolare la probabilità effettiva di ipotizzare erroneamente la piena disponibilità dei dati dopo aver scaricato N porzioni a caso ([per 100 porzioni la probabilità è 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), cioè incredibilmente improbabile). +La soluzione al problema della disponibilità dei dati è il DAS. I nodi leggeri scaricano piccole porzioni casuali dei dati di stato completi e utilizzano i campioni per verificare che l'intero set di dati sia disponibile. La probabilità effettiva di ipotizzare erroneamente la piena disponibilità dei dati dopo aver scaricato N porzioni casuali può essere calcolata ([per 100 porzioni la probabilità è 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), cioè incredibilmente improbabile). Anche in questo scenario, gli attacchi che trattengono solo pochi byte potrebbero passare inosservati ai client che effettuano richieste di dati casuali. La codifica di cancellazione risolve tale problema ricostruendo piccoli pezzi mancanti di dati utilizzabili per verificare i cambiamenti di stato proposti. Una prova di frode, poi, potrebbe essere costruita utilizzando i dati ricostruiti, impedendo ai nodi leggeri di accettare le intestazioni malevole. -**Nota:** DAS e prove di frode non sono ancora state implementate per i client leggeri di Ethereum in proof-of-stake, ma sono sulla tabella di marcia e prenderanno molto probabilmente la forma di prove basate su ZK-SNARK. I client leggeri odierni si affidano a una forma di DAC: verificano le identità della commissione di sincronizzazione, quindi si fidano delle intestazioni dei blocchi firmate che ricevono. +**Nota:** il DAS e le prove di frode non sono ancora stati implementati per i client leggeri di Ethereum proof-of-stake, ma sono sulla tabella di marcia, molto probabilmente sotto forma di prove basate su ZK-SNARK. I client leggeri odierni si affidano a una forma di DAC: verificano le identità della commissione di sincronizzazione, quindi si fidano delle intestazioni dei blocchi firmate che ricevono. -## Disponibilità dei dati e rollup di livello 2 {#data-availability-and-layer-2-rollups} +## Disponibilità dei dati e rollup di Livello 2 {#data-availability-and-layer-2-rollups} -Le [soluzioni di ridimensionamento del Livello 2](/layer-2/), come i [rollup](/glossary/#rollups), riducono i costi di transazione e aumentano il volume di Ethereum, elaborando le transazioni all'esterno della catena. Le transazioni di rollup sono compresse e pubblicate in batch su Ethereum. I batch rappresentano migliaia di singole transazioni esterne alla catena in un'unica transazione su Ethereum. Ciò riduce la congestione al livello di base, riducendo le commissioni per gli utenti. +Le [soluzioni di ridimensionamento di Livello 2](/layer-2/), come i [rollup](/glossary/#rollups), riducono i costi di transazione e aumentano il volume di Ethereum elaborando le transazioni fuori dalla catena. Le transazioni di rollup sono compresse e pubblicate in batch su Ethereum. I batch rappresentano migliaia di singole transazioni fuori dalla catena in un'unica transazione su Ethereum. Ciò riduce la congestione al livello di base, riducendo le commissioni per gli utenti. -Tuttavia, è possibile fidarsi delle transazioni 'sintetiche' pubblicate su Ethereum solo se il cambiamento di stato proposto è verificabile in modo indipendente ed è confermato come il risultato dell'applicazione di tutte le singole transazioni esterne alla catena. Se gli operatori dei rollup non rendono disponibili i dati della transazione per tale verifica, potrebbero inviare dati errati a Ethereum. +Tuttavia, è possibile fidarsi delle transazioni 'riepilogative' pubblicate su Ethereum solo se la modifica dello stato proposta può essere verificata in modo indipendente e confermata come risultato dell'applicazione di tutte le singole transazioni fuori dalla catena. Se gli operatori dei rollup non rendono disponibili i dati della transazione per tale verifica, potrebbero inviare dati errati a Ethereum. -I [rollup ottimistici](/developers/docs/scaling/optimistic-rollups/) pubblicano i dati compressi delle transazioni su Ethereum e attendono un po' di tempo (tipicamente 7 giorni) per consentire ai verificatori indipendenti di verificare i dati. Se qualcuno identifica un problema, possono generare una prova di frode e utilizzarla per contestare il rollup. Questo causerebbe il ripristino della catena e l'omissione del blocco non valido. Ciò è possibile esclusivamente se i dati sono disponibili. Al momento esistono due modi in cui i rollup ottimistici pubblicano i dati delle transazioni sul L1. Alcuni rollup rendono i dati permanentemente disponibili come `CALLDATA`, che risiede permanentemente sulla catena. Con l'implementazione dell'EIP-4844, alcuni rollup, invece, pubblicano i dati delle proprie transazioni in una più economica archiviazione a blob. Questa non è permanente. I verificatori indipendenti devono interrogare i blob e presentare le proprie contestazioni entro circa 18 giorni prima che i dati siano eliminati dal livello 1 di Ethereum. La disponibilità dei dati è garantita soltanto dal protocollo di Ethereum per tale breve finestra fissa. Dopodiché, diventa la responsabilità di altre entità nell'ecosistema di Ethereum. Ogni nodo può verificare la disponibilità dei dati utilizzando il DAS, cioè scaricando piccoli campioni casuali dei dati del blob. +I [rollup ottimistici](/developers/docs/scaling/optimistic-rollups/) pubblicano i dati compressi delle transazioni su Ethereum e attendono un certo periodo di tempo (in genere 7 giorni) per consentire a verificatori indipendenti di controllare i dati. Se qualcuno identifica un problema, possono generare una prova di frode e utilizzarla per contestare il rollup. Questo causerebbe il ripristino della catena e l'omissione del blocco non valido. Ciò è possibile esclusivamente se i dati sono disponibili. Al momento esistono due modi in cui i rollup ottimistici pubblicano i dati delle transazioni sul L1. Alcuni rollup rendono i dati permanentemente disponibili come `CALLDATA`, che risiede permanentemente sulla catena. Con l'implementazione dell'EIP-4844, alcuni rollup, invece, pubblicano i dati delle proprie transazioni in una più economica archiviazione a blob. Questa non è permanente. I verificatori indipendenti devono interrogare i blob e presentare le proprie contestazioni entro circa 18 giorni prima che i dati siano eliminati dal livello 1 di Ethereum. La disponibilità dei dati è garantita soltanto dal protocollo di Ethereum per tale breve finestra fissa. Dopodiché, diventa la responsabilità di altre entità nell'ecosistema di Ethereum. Qualsiasi nodo può verificare la disponibilità dei dati utilizzando il DAS, cioè scaricando piccoli campioni casuali dei dati del blob. -I [rollup a conoscenza zero (ZK)](/developers/docs/scaling/zk-rollups) non necessitano di pubblicare i dati della transazione, poiché le [prove di validità a conoscenza zero](/glossary/#zk-proof) garantiscono la correttezza delle transizioni di stato. Tuttavia, la disponibilità dei dati è ancora un problema, poiché non possiamo garantire la funzionalità del rollup ZK (o interagirci) senza l'accesso ai suoi dati di stato. Ad esempio, gli utenti non possono conoscere i propri saldi se un operatore trattiene dettagli sullo stato del rollup. Inoltre, non possono eseguire gli aggiornamenti di stato utilizzando informazioni contenute in un blocco appena aggiunto. +I [rollup a conoscenza-zero (ZK)](/developers/docs/scaling/zk-rollups) non devono pubblicare i dati delle transazioni, poiché le [prove di validità a conoscenza-zero](/glossary/#zk-proof) garantiscono la correttezza delle transizioni di stato. Tuttavia, la disponibilità dei dati è ancora un problema, poiché non possiamo garantire la funzionalità del rollup ZK (o interagirci) senza l'accesso ai suoi dati di stato. Ad esempio, gli utenti non possono conoscere i propri saldi se un operatore trattiene dettagli sullo stato del rollup. Inoltre, non possono eseguire gli aggiornamenti di stato utilizzando informazioni contenute in un blocco appena aggiunto. ## Disponibilità dei dati vs. recuperabilità dei dati {#data-availability-vs-data-retrievability} La disponibilità dei dati è diversa dalla reperibilità dei dati. La disponibilità dei dati è la garanzia che i nodi completi siano stati capaci di accedere e verificare l'intera serie di transazioni associate a un blocco specifico. Non ne consegue necessariamente che i dati siano accessibili per sempre. -La reperibilità dei dati è la capacità dei nodi di recuperare lo _storico_ dalla blockchain. Questi dati storici non sono necessari per verificare i nuovi blocchi, sono solo necessari per sincronizzare i nodi completi dal blocco di genesi o per servire le richieste storiche. +La recuperabilità dei dati è la capacità dei nodi di recuperare le _informazioni storiche_ dalla blockchain. Questi dati storici non sono necessari per verificare i nuovi blocchi, sono solo necessari per sincronizzare i nodi completi dal blocco di genesi o per servire le richieste storiche. -Il protocollo principale di Ethereum riguarda principalmente la disponibilità dei dati, non la loro reperibilità. La recuperabilità dei dati può essere fornita da una piccola popolazione di nodi di archivio, operata da terze parti, o è distribuibile per la rete utilizzando l'archiviazione decentralizzata di file, come [Portal Network](https://www.ethportal.net/). +Il protocollo principale di Ethereum riguarda principalmente la disponibilità dei dati, non la loro reperibilità. La recuperabilità dei dati può essere fornita da una piccola popolazione di nodi di archivio gestiti da terze parti, o può essere distribuita attraverso la rete utilizzando un'archiviazione di file decentralizzata come il [Portal Network](https://www.ethportal.net/). -## Lettura consigliate {#further-reading} +## Letture consigliate {#further-reading} -- [Che diamine è la disponibilità dei dati?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) -- [Cos'è la disponibilità dei dati?](https://coinmarketcap.com/alexandria/article/what-is-data-availability) -- [Il panorama della disponibilità dei dati esterni alla catena di Ethereum](https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/) -- [Le nozioni di base sui controlli di disponibilità dei dati](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) -- [Una spiegazione dello sharding + proposta DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) -- [Una nota sulla disponibilità dei dati e la codifica di cancellazione](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) -- [Commissioni di disponibilità dei dati.](https://medium.com/starkware/data-availability-e5564c416424) -- [Commissioni di disponibilità dei dati di proof-of-stake.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) -- [Soluzioni al problema della recuperabilità dei dati](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) -- [Disponibilità dei dati, ovvero come i rollup hanno imparato a smettere di preoccuparsi e ad amare Ethereum](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) +- [WTF is Data Availability?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [What Is Data Availability?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [A primer on data availability checks](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [An explanation of the sharding + DAS proposal](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [A note on data availability and erasure coding](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [Data availability committees.](https://medium.com/starkware/data-availability-e5564c416424) +- [Proof-of-stake data availability committees.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Solutions to the data retrievability problem](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [Data Availability Or: How Rollups Learned To Stop Worrying And Love Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: Increasing Calldata Cost](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/it/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/it/developers/docs/data-structures-and-encoding/index.md index 741d0a5b654..7b46634c1ca 100644 --- a/public/content/translations/it/developers/docs/data-structures-and-encoding/index.md +++ b/public/content/translations/it/developers/docs/data-structures-and-encoding/index.md @@ -9,15 +9,15 @@ Ethereum crea, memorizza e trasferisce grandi volumi di dati. Questi dati devono ## Prerequisiti {#prerequisites} -È utile comprendere i fondamenti di Ethereum e del [software del client](/developers/docs/nodes-and-clients/). È consigliabile avere familiarità con il livello di rete e il [whitepaper di Ethereum](/whitepaper/). +Dovresti comprendere i fondamenti di Ethereum e il [software client](/developers/docs/nodes-and-clients/). È consigliabile avere familiarità con il livello di rete e [il whitepaper di Ethereum](/whitepaper/). -## Strutture di dati {#data-structures} +## Strutture dei dati {#data-structures} -### Trie di Patricia Merkle {#patricia-merkle-tries} +### Trie Merkle Patricia {#patricia-merkle-tries} I trie di Patricia Merkle sono strutture che codificano coppie chiave-valore in una prova autenticata crittograficamente e deterministica. Sono usate ampiamente nel livello d'esecuzione di Ethereum. -[Maggiori informazioni sui trie di Patricia Merkle](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) +[Maggiori informazioni sui Trie Merkle Patricia](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) ### Prefisso di Lunghezza Ricorsiva {#recursive-length-prefix} @@ -25,7 +25,7 @@ Il Prefisso di Lunghezza Ricorsiva (RLP) è un metodo di serializzazione usato a [Maggiori informazioni su RLP](/developers/docs/data-structures-and-encoding/rlp) -### Simple Serialize {#simple-serialize} +### Serializzazione Semplice {#simple-serialize} Simple Serialize (SSZ) è il formato di serializzazione dominante sul livello di consenso di Ethereum, per la sua compatibilità alla Merkle-zzazione. diff --git a/public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 1c7ad65d411..52b60b77831 100644 --- a/public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -5,19 +5,19 @@ lang: it sidebarDepth: 2 --- -Lo stato di Ethereum (la totalità di tutti i conti, i saldi e i contratti intelligenti) è codificato in una versione speciale della struttura dei dati, nota generalmente in informatica come un Albero di Merkle. Questa struttura è utile per molte applicazioni crittografiche, poiché crea una relazione verificabile tra tutti le singole parti di dati facenti parte dell'albero, dando come risultato un singolo valore di **radice** utilizzabile per provare delle cose sui dati. +Lo stato di Ethereum (la totalità di tutti i conti, i saldi e i contratti intelligenti) è codificato in una versione speciale della struttura dei dati, nota generalmente in informatica come un Albero di Merkle. Questa struttura è utile per molte applicazioni in crittografia, poiché crea una relazione verificabile tra tutti i singoli dati intrecciati nell'albero, risultando in un singolo valore di **radice** che può essere utilizzato per dimostrare fatti relativi ai dati. -La struttura dei dati di Ethereum è un 'Trie di Merkle-Patricia modificato', così detto perché prende in prestito alcune funzionalità di PATRICIA (l'Algoritmo Pratico Per Recuperare Informazioni Codificate in Alfanumerico), e poiché è progetttato per il **recupero** efficiente dei dati che costituiscono lo stato di Ethereum. +La struttura dati di Ethereum è un 'trie di Merkle-Patricia modificato', così chiamato perché prende in prestito alcune funzionalità di PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric) e perché è progettato per il recupero efficiente dei dati che compongono lo stato di Ethereum. -Un trie di Merkle-Patricia è deterministico e verificabile crittograficamente: il solo modo per generare una radice di stato è calcolandola da ogni singola parte dello stato, e due stati identici sono facilmente dimostrabili confrontando l'hash di radice e gli hash che hanno portato a esso (_una prova di Merkle_). Per contro, non esiste alcun modo per creare due stati differenti con lo stesso hash di radice, e qualsiasi tentativo di modificare lo stato con valori differenti risulterà in un hash della radice di stato differente. Teoricamente, questa struttura rappresenta il 'Sacro Graal' dell'efficienza di `O(log(n))` per inserimenti, ricerche ed eliminazioni. +Un trie di Merkle-Patricia è deterministico e crittograficamente verificabile: l'unico modo per generare una radice di stato è calcolandola da ogni singolo pezzo dello stato, e si può facilmente dimostrare che due stati sono identici confrontando l'hash della radice e gli hash che hanno portato a esso (_una prova di Merkle_). Per contro, non esiste alcun modo per creare due stati differenti con lo stesso hash di radice, e qualsiasi tentativo di modificare lo stato con valori differenti risulterà in un hash della radice di stato differente. Teoricamente, questa struttura rappresenta il "Sacro Graal" dell'efficienza `O(log(n))` per inserimenti, ricerche ed eliminazioni. -Nel prossimo futuro, Ethereum prevede di migrare a una struttura ad [Albero di Verkle](/roadmap/verkle-trees), che aprirà le porte a molte nuove possibilità per le future migliorie al protocollo. +In un futuro prossimo, Ethereum prevede di migrare a una struttura ad [Albero di Verkle](/roadmap/verkle-trees), che aprirà molte nuove possibilità per futuri miglioramenti del protocollo. ## Prerequisiti {#prerequisites} -Per meglio comprendere questa pagina, sarebbe utile avere una conoscenza di base di [hash](https://en.wikipedia.org/wiki/Hash_function), [alberi di Merkle](https://en.wikipedia.org/wiki/Merkle_tree), [trie](https://en.wikipedia.org/wiki/Trie) e [serializzazione](https://en.wikipedia.org/wiki/Serialization). Questo articolo si apre con una descrizione di un [albero radicato](https://en.wikipedia.org/wiki/Radix_tree) di base, introducendo poi gradualmente alle modifiche necessarie per la struttura di dati più ottimizzata di Ethereum. +Per comprendere meglio questa pagina, sarebbe utile avere una conoscenza di base di [hash](https://en.wikipedia.org/wiki/Hash_function), [alberi di Merkle](https://en.wikipedia.org/wiki/Merkle_tree), [trie](https://en.wikipedia.org/wiki/Trie) e [serializzazione](https://en.wikipedia.org/wiki/Serialization). Questo articolo inizia con la descrizione di un [albero radix](https://en.wikipedia.org/wiki/Radix_tree) di base, per poi introdurre gradualmente le modifiche necessarie per la struttura dati più ottimizzata di Ethereum. -## Trie della radice di base {#basic-radix-tries} +## Trie radix di base {#basic-radix-tries} In un trie della radice di base, ogni nodo si presenta così: @@ -25,146 +25,149 @@ In un trie della radice di base, ogni nodo si presenta così: [i_0, i_1 ... i_n, value] ``` -Dove `i_0 ... i_n` rappresenta i simboli dell'alfabeto (spesso binari o esadecimali), `value` è il valore terminale al nodo e i valori negli spazi `i_0, i_1 ... i_n` sono `NULL` o puntano ad (nel nostro caso, a hash di) altri nodi. Questo forma un'archiviazione di base `(chiave, valore)`. +Dove `i_0 ...` `i_n` rappresentano i simboli dell'alfabeto (spesso binario o esadecimale), `value` è il valore terminale nel nodo e i valori in `i_0, i_1 ...` gli slot `i_n` sono o `NULL` o puntatori a (nel nostro caso, hash di) altri nodi. Questo forma un archivio di base `(chiave, valore)`. -Ipotizziamo che si voglia utilizzare una struttura dei dati ad albero radicato per perdurare un ordine su una serie di coppie chiave-valore. Per trovare il valore attualmente mappato alla chiave `dog` nell'albero, occorre convertire prima `dog` in lettere dell'alfabeto (restituendo `64 6f 67`) e poi discendere l'albero seguendo tale percorso, fino a trovare il valore. Quindi, iniziare guardando l'hash radice in un database chiave/valore piatto per trovare il nodo radice dell'albero. È rappresentato come un insieme di chiavi che puntano ad altri nodi. Occorre utilizzare il valore all'indice `6` come una chiave e cercarlo nel database chiave/valore piatto per ottenere il nodo al livello inferiore. Poi si deve scegliere l'indice `4` per cercare il valore successivo, quindi, l'indice `6` e così via, finché, una volta seguito il percorso: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7` si cerca il valore del nodo e si trova il risultato. +Ipotizziamo che si voglia utilizzare una struttura dei dati ad albero radicato per perdurare un ordine su una serie di coppie chiave-valore. Per trovare il valore attualmente mappato alla chiave `dog` nel trie, si dovrebbe prima convertire `dog` in lettere dell'alfabeto (ottenendo `64 6f 67`), e poi scendere lungo il trie seguendo quel percorso fino a trovare il valore. Quindi, iniziare guardando l'hash radice in un database chiave/valore piatto per trovare il nodo radice dell'albero. È rappresentato come un insieme di chiavi che puntano ad altri nodi. Si utilizzerebbe il valore all'indice `6` come chiave e lo si cercherebbe nel DB flat chiave/valore per ottenere il nodo di un livello inferiore. Poi si sceglie l'indice `4` per cercare il valore successivo, poi l'indice `6` e così via, finché, una volta seguito il percorso: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, si cerca il valore del nodo e si restituisce il risultato. Esiste una differenza tra cercare qualcosa nel 'trie' e nel 'DB' flat chiave/valore sottostante. Entrambi definiscono degli schemi chiave/valore, ma il DB sottostante può effettuare una tradizionale ricerca di una chiave in 1 passaggio. Cercare una chiave nel trie richiede diverse ricerche DB sottostanti, per ottenere il valore finale descritto sopra. Facciamo riferimento a quest'ultimo come `path`, per eliminare ogni ambiguità. Le operazioni di aggiornamento ed eliminazione per gli alberi radicati sono definibili come segue: -``` - def update(node,path,value): - curnode = db.get(node) if node else [ NULL ] * 17 +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 newnode = curnode.copy() - if path == '': + if path == "": newnode[-1] = value else: - newindex = update(curnode[path[0]],path[1:],value) + newindex = update(curnode[path[0]], path[1:], value) newnode[path[0]] = newindex - db.put(hash(newnode),newnode) + db.put(hash(newnode), newnode) return hash(newnode) - def delete(node,path): - if node is NULL: + def delete(node_hash, path): + if node_hash is NULL: return NULL else: - curnode = db.get(node) + curnode = db.get(node_hash) newnode = curnode.copy() - if path == '': + if path == "": newnode[-1] = NULL else: - newindex = delete(curnode[path[0]],path[1:]) + newindex = delete(curnode[path[0]], path[1:]) newnode[path[0]] = newindex if all(x is NULL for x in newnode): return NULL else: - db.put(hash(newnode),newnode) + db.put(hash(newnode), newnode) return hash(newnode) ``` -Un albero Radicato di "Merkle" è costruito collegando i nodi utilizzando sinossi di hash crittografici generati deterministicamente. Questo indirizzamento del contenuto (nel DB chiave/valore `key == keccak256(rlp(value))`) fornisce una garanzia dell'integrità crittografica dei dati memorizzati. Se l'hash radice di un dato albero è noto pubblicamente, allora chiunque abbia accesso ai dati delle foglie sottostanti può costruire una prova che l'albero include un dato valore a un percorso specifico, fornendo gli hash di ogni nodo che unisce un valore specifico alla radice dell'albero. +Un albero Radicato di "Merkle" è costruito collegando i nodi utilizzando sinossi di hash crittografici generati deterministicamente. Questo indirizzamento del contenuto (nel DB chiave/valore `key == keccak256(rlp(value))`) fornisce una garanzia d'integrità crittografica dei dati archiviati. Se l'hash radice di un dato albero è noto pubblicamente, allora chiunque abbia accesso ai dati delle foglie sottostanti può costruire una prova che l'albero include un dato valore a un percorso specifico, fornendo gli hash di ogni nodo che unisce un valore specifico alla radice dell'albero. -È impossibile, per un utente malevolo, fornire una prova di una coppia `(percorso, valore)` che non esiste, poiché l'hash radice in definitiva si basa su tutti gli hash inferiori. Qualsiasi modifica sottostante modificherebbe l'hash radice. Si può pensare all'hash come una rappresentazione compressa delle informazioni strutturali sui dati, assicurata da una protezione pre-immagine della funzione di hashing. +È impossibile per un utente malintenzionato fornire la prova di una coppia `(percorso, valore)` che non esiste, poiché l'hash della radice si basa in definitiva su tutti gli hash sottostanti. Qualsiasi modifica sottostante modificherebbe l'hash radice. Si può pensare all'hash come una rappresentazione compressa delle informazioni strutturali sui dati, assicurata da una protezione pre-immagine della funzione di hashing. -Chiameremo "nibble" l'unità atomica di un albero radicato (es., un singolo carattere esadecimale o un numero binario a 4 bit). Attraversando un percorso un "nibble" per volta, come descritto sopra, i nodi possono fare riferimento massimale a 16 figli, ma includono un elemento `value`. Dunque, li rappresentiamo come un insieme di lunghezza 17. Chiamiamo questi insiemi da 17 elementi "nodi ramo". +Ci riferiremo a un'unità atomica di un albero radix (ad esempio, un singolo carattere esadecimale o un numero binario a 4 bit) come "nibble". Durante l'attraversamento di un percorso, un nibble alla volta, come descritto sopra, i nodi possono fare riferimento al massimo a 16 figli ma includono un elemento `value`. Dunque, li rappresentiamo come un insieme di lunghezza 17. Chiamiamo questi insiemi da 17 elementi "nodi ramo". -## Trie di Patricia Merkle {#merkle-patricia-trees} +## Trie Merkle Patricia {#merkle-patricia-trees} -Gli alberi radicati hanno una grande limitazione: non sono efficienti. Se si desidera memorizzare una coppia `(percorso, valore)` dove il percorso, come in Ethereum, è lungo 64 caratteri (il numero di "nibble" in `bytes32`), servirà oltre un kilobyte di spazio aggiuntivo per memorizzare un livello per carattere e, ogni ricerca o eliminazione, richiederebbe tutti e 64 i passaggi. L'albero di Patricia introdotto di seguito risolve tale problema. +Gli alberi radicati hanno una grande limitazione: non sono efficienti. Se si vuole archiviare un'associazione `(percorso, valore)` in cui il percorso, come in Ethereum, è lungo 64 caratteri (il numero di nibble in `bytes32`), servirà oltre un kilobyte di spazio extra per archiviare un livello per carattere, e ogni ricerca o eliminazione richiederà tutti i 64 passaggi. L'albero di Patricia introdotto di seguito risolve tale problema. ### Ottimizzazione {#optimization} Un nodo in un trie di Patricia Merkle è uno dei seguenti: -1. `NULL` (rappresentato come la stringa vuota) -2. `branch` Un nodo da 17 elementi `[ v0 ... v15, vt ]` -3. `leaf` Un nodo da 2 elementi `[ encodedPath, value ]` -4. `extension` Un nodo da 2 elementi `[ encodedPath, key ]` +1. `NULL` (rappresentato come stringa vuota) +2. `branch` Un nodo a 17 elementi `[ v0 ...` `v15, vt ]` +3. `leaf` Un nodo a 2 elementi `[ encodedPath, value ]` +4. `extension` Un nodo a 2 elementi `[ encodedPath, key ]` -Con i percorsi da 64 caratteri è inevitabile che dopo aver attraversato i primi pochi livelli del trie, si raggiunge un nodo privo di alcun percorso divergente per almeno parte del percorso. Per evitare di dover creare 15 nodi `NULL` sparsi lungo il percorso, abbreviamo la discesa configurando un nodo `extension` della forma `[ encodedPath, key ]`, in cui `encodedPath` contiene il "percorso parziale" a cui saltare (utilizzando una codifica compatta spiegata di seguito) e `key` è per la prossima ricerca sul database. +Con i percorsi da 64 caratteri è inevitabile che dopo aver attraversato i primi pochi livelli del trie, si raggiunge un nodo privo di alcun percorso divergente per almeno parte del percorso. Per evitare di dover creare fino a 15 nodi `NULL` sparsi lungo il percorso, si abbrevia la discesa impostando un nodo di `extension` della forma `[ encodedPath, key ]`, dove `encodedPath` contiene il "percorso parziale" da saltare (usando una codifica compatta descritta di seguito), e `key` è per la successiva ricerca nel DB. -Per un nodo `leaf`, contrassegnabile da un flag nel primo nibble del `encodedPath`, il percorso codifica tutti i frammenti precedenti del percorso del nodo e possiamo cercare direttamente il `value`. +Per un nodo `leaf`, che può essere contrassegnato da un flag nel primo nibble di `encodedPath`, il percorso codifica tutti i frammenti di percorso del nodo precedente e possiamo cercare direttamente il `value`. Tale suddetta ottimizzazione, tuttavia, introduce delle ambiguità. -Attraversando i percorsi in "nibble", potremmo finire con un numero dispari di nibble da attraversare; questo perché tutti i dati sono memorizzati nel fromato `bytes`. Non è possibile differenziare tra, ad esempio, il nibble `1` e i nibble `01` (entrambi devono essere memorizzati come `<01>`). Per specificare una lunghezza dispari, il percorso parziale è prefissato con un flag. +Quando si attraversano i percorsi in nibble, si può finire con un numero dispari di nibble da attraversare, ma poiché tutti i dati sono memorizzati in formato `bytes`. Non è possibile distinguere, ad esempio, tra il nibble `1` e i nibble `01` (entrambi devono essere memorizzati come `<01>`). Per specificare una lunghezza dispari, il percorso parziale è prefissato con un flag. ### Specifica: codifica compatta della sequenza esadecimale con terminatore facoltativo {#specification} -Il flagging sia _della lunghezza del percorso parziale rimanente, dispari o pari,_ sia del _nodo leaf o estensione_, come descritto sopra, risiede nel primo nibble del percorso parziale di qualsiasi nodo di 2 elementi. Il risultato è il seguente: +La segnalazione sia della _lunghezza del percorso parziale rimanente pari o dispari_ sia del _nodo leaf o di estensione_, come descritto sopra, risiede nel primo nibble del percorso parziale di qualsiasi nodo a 2 elementi. Il risultato è il seguente: - char hex bit | parziale tipo nodo lungh percorso - ---------------------------------------------------------- - 0 0000 | estensione pari - 1 0001 | estensione dispari - 2 0010 | terminazione (leaf) pari - 3 0011 | terminazione (leaf) dispari +| carattere esadecimale | bit | tipo di nodo parziale | lunghezza percorso | +| --------------------- | ---- | ----------------------------------- | ------------------ | +| 0 | 0000 | estensione | pari | +| 1 | 0001 | estensione | dispari | +| 2 | 0010 | terminale (leaf) | pari | +| 3 | 0011 | terminale (leaf) | dispari | -per la lunghezza del percorso rimanente pari (`0` or `2`), seguirà sempre un altro nibble di "padding" `0`. +Per una lunghezza del percorso rimanente pari (`0` o `2`), seguirà sempre un altro nibble di "padding" `0`. -``` +```python def compact_encode(hexarray): term = 1 if hexarray[-1] == 16 else 0 - if term: hexarray = hexarray[:-1] + if term: + hexarray = hexarray[:-1] oddlen = len(hexarray) % 2 flags = 2 * term + oddlen if oddlen: hexarray = [flags] + hexarray else: hexarray = [flags] + [0] + hexarray - // hexarray ha ora una lunghezza pari, il cui primo nibble si compone dei flag. - o = '' - for i in range(0,len(hexarray),2): - o += chr(16 * hexarray[i] + hexarray[i+1]) + # hexarray ora ha una lunghezza pari il cui primo nibble sono i flag. + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) return o ``` Esempi: -``` - > [ 1, 2, 3, 4, 5, ...] +```python + > [1, 2, 3, 4, 5, ...] '11 23 45' - > [ 0, 1, 2, 3, 4, 5, ...] + > [0, 1, 2, 3, 4, 5, ...] '00 01 23 45' - > [ 0, f, 1, c, b, 8, 10] + > [0, f, 1, c, b, 8, 10] '20 0f 1c b8' - > [ f, 1, c, b, 8, 10] + > [f, 1, c, b, 8, 10] '3f 1c b8' ``` Ecco il codice esteso per ottenere un nodo nel trie di Patricia Merkle: -``` - def get_helper(node,path): - if path == []: return node - if node = '': return '' - curnode = rlp.decode(node if len(node) < 32 else db.get(node)) +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) if len(curnode) == 2: (k2, v2) = curnode k2 = compact_decode(k2) - if k2 == path[:len(k2)]: - return get(v2, path[len(k2):]) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) else: - return '' + return "" elif len(curnode) == 17: - return get_helper(curnode[path[0]],path[1:]) + return get_helper(curnode[path[0]], path[1:]) - def get(node,path): + def get(node_hash, path): path2 = [] for i in range(len(path)): path2.push(int(ord(path[i]) / 16)) path2.push(ord(path[i]) % 16) path2.push(16) - return get_helper(node,path2) + return get_helper(node_hash, path2) ``` -### Esempio di Trie {#example-trie} +### Esempio di trie {#example-trie} -Supponiamo di volere un trie che contenga quattro coppie percorso/valore `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. +Supponiamo di volere un trie contenente quattro coppie percorso/valore: `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. -Per prima cosa, convertiamo sia i percorsi che i valori in `bytes`. Di seguito, le rappresentazioni reali dei byte per i _percorsi_ sono denotate da `<>`, sebbene i _valori_ siano mostrati ancora come stringhe, denotate da `"`, per maggiore facilità di comprensione (anch'essi, sarebbero in realtà `bytes`): +Per prima cosa, convertiamo sia i percorsi che i valori in `bytes`. Di seguito, le rappresentazioni effettive in byte per i _percorsi_ sono indicate da `<>`, anche se i _valori_ sono ancora mostrati come stringhe, indicate da `''`, per una più facile comprensione (anch'essi, in realtà, sarebbero `bytes`): ``` <64 6f> : 'verb' @@ -183,38 +186,38 @@ Ora, costruiamo un trie di questo tipo con le seguenti coppie chiave/valore nel hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] ``` -Quando in un nodo si fa riferimento a un altro nodo, viene inserito `H(rlp.encode(node))`, dove `H(x) = keccak256(x) if len(x) >= 32 else x` e `rlp.encode` è la funzione di codifica [RLP](/developers/docs/data-structures-and-encoding/rlp). +Quando si fa riferimento a un nodo all'interno di un altro, ciò che viene incluso è `keccak256(rlp.encode(node))`, se `len(rlp.encode(node)) >= 32`, altrimenti `node`, dove `rlp.encode` è la funzione di codifica [RLP](/developers/docs/data-structures-and-encoding/rlp). -Nota che, aggiornando un trie, si deve memorizzare la coppia chiave/valore `(keccak256(x), x)` in una tabella di ricerca persistente _se_ il nodo appena creato ha una lunghezza >= 32. Se invece il nodo è inferiore a questo valore, non è necessario memorizzare nulla, poiché la funzione f(x) = x è reversibile. +Si noti che durante l'aggiornamento di un trie, è necessario archiviare la coppia chiave/valore `(keccak256(x), x)` in una tabella di ricerca persistente _se_ il nodo appena creato ha una lunghezza >= 32. Se invece il nodo è inferiore a questo valore, non è necessario memorizzare nulla, poiché la funzione f(x) = x è reversibile. -## Trie in Ethereum {#tries-in-ethereum} +## I trie in Ethereum {#tries-in-ethereum} Tutti i trie di Merkle nel livello d'esecuzione di Ethereum usano un Trie di Patricia Merkle. Dall'intestazione di un blocco ci sono 3 radici provenienti da 3 di questi trie. -1. stateRoot -2. transactionsRoot -3. receiptsRoot +1. stateRoot +2. transactionsRoot +3. receiptsRoot -### Trie di Stato {#state-trie} +### Trie di stato {#state-trie} -Esiste un albero di stato globale ed è aggiornato ogni volta che un client elabora un blocco. In esso, un `path` è sempre: `keccak256(ethereumAddress)` e un `value` è sempre: `rlp(ethereumAccount)`. Più nello specifico, un `account` di Ethereum è un insieme di 4 elementi di `[nonce,balance,storageRoot,codeHash]`. A questo punto, vale la pena di notare che tale `storageRoot` è la radice di un altro albero di Patricia: +Esiste un albero di stato globale ed è aggiornato ogni volta che un client elabora un blocco. In esso, un `path` è sempre: `keccak256(ethereumAddress)` e un `value` è sempre: `rlp(ethereumAccount)`. Più specificamente, un `account` Ethereum è un array di 4 elementi: `[nonce,balance,storageRoot,codeHash]`. A questo punto, vale la pena notare che questo `storageRoot` è la radice di un altro trie di Patricia: -### Trie d'archiviazione {#storage-trie} +### Trie di archiviazione {#storage-trie} -Il trie d'archiviazione è dove risiedono _tutti_ i dati del contratto. Esiste un albero d'archiviazione separato per ogni conto. Per recuperare i valori a posizioni d'archiviazione specifiche a un dato indirizzo, servono l'indirizzo d'archiviazione, la posizione intera dei dati memorizzati in archiviazione e l'ID del blocco. Questi possono essere passati come argomenti al `eth_getStorageAt`, definito nell'APi di JSON-RPC, es., per recuperare i dati nello slot 0 d'archiviazione per l'indirizzo `0x295a70b2de5e3953354a6a8344e616ed314d7251`: +Il trie di archiviazione è dove risiedono _tutti_ i dati del contratto. Esiste un albero d'archiviazione separato per ogni conto. Per recuperare i valori a posizioni d'archiviazione specifiche a un dato indirizzo, servono l'indirizzo d'archiviazione, la posizione intera dei dati memorizzati in archiviazione e l'ID del blocco. Questi possono quindi essere passati come argomenti a `eth_getStorageAt` definito nell'API JSON-RPC, ad esempio per recuperare i dati nello slot di archiviazione 0 per l'indirizzo `0x295a70b2de5e3953354a6a8344e616ed314d7251`: -``` +```bash curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} ``` -Il recupero di altri elementi in archiviazione è lievemente più impegnativo, poiché deve essere calcolata prima la posizione nel trie d'archiviazione. La posizione è calcolata come l'hash `keccak256` dell'indirizzo e della posizione d'archiviazione, entrambi con padding di zeri a sinistra, fino a una lunghezza di 32 byte. Ad esempio, la posizione dei dati nello slot d'archiviazione 1 per l'indirizzo `0x391694e7e0b0cce554cb130d723a9d27458f9298` è: +Il recupero di altri elementi in archiviazione è lievemente più impegnativo, poiché deve essere calcolata prima la posizione nel trie d'archiviazione. La posizione è calcolata come l'hash `keccak256` dell'indirizzo e della posizione di archiviazione, entrambi con riempimento a sinistra di zeri (left-padded) fino a una lunghezza di 32 byte. Ad esempio, la posizione per i dati nello slot di archiviazione 1 per l'indirizzo `0x391694e7e0b0cce554cb130d723a9d27458f9298` è: -``` +```python keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) ``` @@ -227,37 +230,37 @@ undefined "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" ``` -Il `path` è dunque `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. Questo è ora utilizzabile per recuperare i dati dal trie d'archiviazione come sopra: +Il `path` è quindi `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. Questo è ora utilizzabile per recuperare i dati dal trie d'archiviazione come sopra: -``` +```bash curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} ``` -Nota: la `storageRoot` per un account di Ethereum è vuota per impostazione predefinita se non è l'account di un contratto. +Nota: lo `storageRoot` per un account Ethereum è vuoto per impostazione predefinita se non è un account di contratto. ### Trie delle transazioni {#transaction-trie} -Esiste un albero di transazioni separato per ogni blocco, anch'esso che memorizza coppie `(key, value)`. Qui, un percorso è: `rlp(transactionIndex)`, rappresentante la chiave corrispondente a un valore determinato da: +Esiste un trie delle transazioni separato per ogni blocco, che archivia sempre coppie `(chiave, valore)`. Un percorso qui è: `rlp(transactionIndex)` che rappresenta la chiave che corrisponde a un valore determinato da: -``` +```python if legacyTx: value = rlp(tx) else: value = TxType | encode(tx) ``` -Maggiori informazioni a riguardo si possono trovare nella documentazione [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). +Maggiori informazioni su questo argomento si possono trovare nella documentazione dell'[EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). ### Trie delle ricevute {#receipts-trie} -Ogni blocco ha il proprio trie delle ricevute. Qui, un `path` è: `rlp(transactionIndex)`. `transactionIndex` è il suo indice all'interno del blocco in cui è stato incluso. L'albero delle ricevute non è mai aggiornato. Analogamento all'albero delle Transazioni, esistono ricevute correnti e legacy. Per interrogare una ricevuta specifica nell'albero delle Ricevute, l'indice della transazione nel suo blocco, il carico utile di ricevute e il tipo di transazione sono necessari. La ricevuta Restituita può essere di tipo `Receipt`, definita come la concatenazione di `TransactionType` e `ReceiptPayload` o di tipo `LegacyReceipt`, definibile come `rlp([status, cumulativeGasUsed, logsBloom, logs])`. +Ogni blocco ha il proprio trie delle ricevute. Un `path` qui è: `rlp(transactionIndex)`. `transactionIndex` è il suo indice all'interno del blocco in cui è stato incluso. L'albero delle ricevute non è mai aggiornato. Analogamento all'albero delle Transazioni, esistono ricevute correnti e legacy. Per interrogare una ricevuta specifica nell'albero delle Ricevute, l'indice della transazione nel suo blocco, il carico utile di ricevute e il tipo di transazione sono necessari. La ricevuta restituita può essere di tipo `Receipt`, che è definita come la concatenazione di `TransactionType` e `ReceiptPayload` o può essere di tipo `LegacyReceipt` che è definita come `rlp([status, cumulativeGasUsed, logsBloom, logs])`. -Maggiori informazioni a riguardo si possono trovare nella documentazione [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). +Maggiori informazioni su questo argomento si possono trovare nella documentazione dell'[EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). -## Letture consigliate {#further-reading} +## Ulteriori letture {#further-reading} -- [Albero di Patricia Merkle Modificato - Come Ethereum risparmia uno stato](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) -- ["Merkling" su Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) -- [Comprendere l'albero di Ethereum](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) +- [Trie Merkle Patricia Modificato — Come Ethereum salva uno stato](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [Il "Merkling" in Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [Comprendere il trie di Ethereum](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/it/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/it/developers/docs/data-structures-and-encoding/rlp/index.md index 621017f90f4..bb3c0d4e31a 100644 --- a/public/content/translations/it/developers/docs/data-structures-and-encoding/rlp/index.md +++ b/public/content/translations/it/developers/docs/data-structures-and-encoding/rlp/index.md @@ -5,20 +5,20 @@ lang: it sidebarDepth: 2 --- -La serializzazione a prefisso di lunghezza ricorsiva (RLP) è usata ampiamente nei client d'esecuzione di Ethereum. L’RLP standardizza il trasferimento di dati tra nodi in un formato efficiente a livello di spazio. Lo scopo dell’RLP è codificare arbitrariamente gli insiemi di dati binari nidificati e l’RLP è il metodo di codifica principale usato per serializzare gli oggetti nel livello d'esecuzione di Ethereum. Lo scopo principale dell'RLP è codificare la struttura; con l'eccezione degli interi positivi, l'RLP delega la codifica dei tipi di dati specifici (es.,stringhe, virgola mobile) a protocolli di ordine superiore. Gli interi positivi devono essere rappresentati in forma binaria big-endian senza zeri iniziali (rendendo il valore intero zero equivalente all'array di byte vuoto). Gli interi positivi deserializzati con zero iniziali devono essere trattati come non validi da qualsiasi protocollo di ordine superiore che utilizzi l'RLP. +La serializzazione a prefisso di lunghezza ricorsiva (RLP) è usata ampiamente nei client d'esecuzione di Ethereum. L’RLP standardizza il trasferimento di dati tra nodi in un formato efficiente a livello di spazio. Lo scopo dell’RLP è codificare arbitrariamente gli insiemi di dati binari nidificati e l’RLP è il metodo di codifica principale usato per serializzare gli oggetti nel livello d'esecuzione di Ethereum. Lo scopo principale di RLP è codificare la struttura; ad eccezione degli interi positivi, RLP delega la codifica di tipi di dati specifici (ad es. stringhe, float) a protocolli di ordine superiore. Gli interi positivi devono essere rappresentati in forma binaria big-endian senza zeri iniziali (rendendo il valore intero zero equivalente all'array di byte vuoto). Gli interi positivi deserializzati con zero iniziali devono essere trattati come non validi da qualsiasi protocollo di ordine superiore che utilizzi l'RLP. -Per maggiori informazioni, consultare lo [yellowpaper di Ethereum (Appendice B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). +Maggiori informazioni nel [yellow paper di Ethereum (Appendice B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). Per usare l’RLP per codificare un dizionario, le due forme canoniche suggerite sono: -- usare `[[k1,v1],[k2,v2]...]` con i tasti in ordine lessicografico +- usare `[[k1,v1],[k2,v2]...]` con chiavi in ordine lessicografico - usare la codifica dell'Albero di Patricia di livello superiore come fa Ethereum ## Definizione {#definition} La codifica RLP prende un elemento. Un elemento è definito come segue: -- una stringa (ovvero insieme di byte) è un elemento +- una stringa (ossia, un array di byte) è un elemento - un elenco di elementi è un elemento - un intero posiitivo è un elemento @@ -27,7 +27,7 @@ Ad esempio, tutti i seguenti sono elementi: - una stringa vuota; - la stringa contenente la parola "gatto"; - un elenco contenente qualsiasi numero di stringhe; -- e strutture di dati più complesse come `["gatto", ["cucciolo", "vacca"], "cavallo", [[]], "maiale", [""], "pecora"]`. +- e strutture dati più complesse come `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. - il numero `100` Nota che, nel contesto del resto di questa pagina, 'stringa' significa "un certo numero di byte di dati binari"; non è utilizzata alcuna codifica speciale, e non è implicata alcuna conoscenza sul contenuto delle stringhe (tranne come richiesto dalla regola contro gli interi positivi non minimali). @@ -35,12 +35,12 @@ Nota che, nel contesto del resto di questa pagina, 'stringa' significa "un certo La codifica RLP è definita come segue: - Per un intero positivo, è convertito al più breve array di byte la cui interpretazione big-endian sia l'intero, quindi, e quindi codificato come una stringa secondo le seguenti regole. -- Per un singolo byte il cui valore è nell'intervallo `[0x00, 0x7f]` (decimale `[0, 127]`), quel byte è la propria codifica RLP. -- Altrimenti, se una stringa è lunga da 0 a 55 byte, la codifica RLP consiste in un singolo byte con valore **0x80** (dec. 128) più la lunghezza della stringa seguita dalla stringa. L'intervallo del primo byte è dunque `[0x80, 0xb7]` (dec. `[128, 183]`). -- Se una stringa è più lunga di 55 byte, la codifica RLP consiste in un singolo byte con valore **0xb7** (dec. 183) più la lunghezza in byte della lunghezza della stringa in forma binaria, seguita dalla lunghezza della stringa, seguita dalla stringa. Ad esempio, una stringa lunga 1024 byte sarebbe codificata come `\xb9\x04\x00` (dec. `185, 4, 0`), seguita dalla stringa. Qui, `0xb9` (183 + 2 = 185) come primo byte, seguito dai 2 byte `0x0400` (dec. 1024) che denotano la lunghezza della stringa effettiva. L'intervallo del primo byte è dunque `[0xb8, 0xbf]` (dec. `[184, 191]`). +- Per un singolo byte il cui valore è nell'intervallo `[0x00, 0x7f]` (decimale `[0, 127]`), quel byte è la sua stessa codifica RLP. +- Altrimenti, se una stringa è lunga da 0 a 55 byte, la codifica RLP consiste in un singolo byte con valore **0x80** (dec. 128) più la lunghezza della stringa, seguita dalla stringa. L'intervallo del primo byte è quindi `[0x80, 0xb7]` (dec. `[128, 183]`). +- Se una stringa è più lunga di 55 byte, la codifica RLP consiste in un singolo byte con valore **0xb7** (dec. 183) più la lunghezza in byte della lunghezza della stringa in formato binario, seguita dalla lunghezza della stringa, seguita dalla stringa. Ad esempio, una stringa lunga 1024 byte verrebbe codificata come `\xb9\x04\x00` (dec. `185, 4, 0`) seguita dalla stringa. Qui, `0xb9` (183 + 2 = 185) come primo byte, seguito dai 2 byte `0x0400` (dec. 1024) che indicano la lunghezza della stringa effettiva. L'intervallo del primo byte è quindi `[0xb8, 0xbf]` (dec. `[184, 191]`). - Se una stringa è lunga 2^64 byte o più, potrebbe non essere codificata. -- Se il payload totale di un elenco (cioè la lunghezza combinata di tutti i suoi elementi codificati in RLP) è lunga da 0 a 55 byte, la codifica RLP consiste in un singolo byte dal valore **0xc0**, più la lunghezza del payload, seguita dalla concatenazione delle codifiche RLP degli elementi. L'intervallo del primo byte è dunque `[0xc0, 0xf7]` (dec. `[192, 247]`). -- Se il carico utile totale di un elenco è più lungo di 55 byte, la codifica RLP consiste in un singolo byte con valore **oxf7**, più la lunghezza in byte della lunghezza del payload in forma binaria, seguita dalla lunghezza del carico utile, seguita dalla concatenazione delle codifiche RLP degli elementi. L'intervallo del primo byte è dunque `[0xf8, 0xff]` (dec. `[248, 255]`). +- Se il payload totale di un elenco (ossia la lunghezza combinata di tutti i suoi elementi codificati con RLP) è lungo da 0 a 55 byte, la codifica RLP consiste in un singolo byte con valore **0xc0** più la lunghezza del payload, seguita dalla concatenazione delle codifiche RLP degli elementi. L'intervallo del primo byte è quindi `[0xc0, 0xf7]` (dec. `[192, 247]`). +- Se il payload totale di un elenco è più lungo di 55 byte, la codifica RLP consiste in un singolo byte con valore **0xf7** più la lunghezza in byte della lunghezza del payload in formato binario, seguita dalla lunghezza del payload, seguita dalla concatenazione delle codifiche RLP degli elementi. L'intervallo del primo byte è quindi `[0xf8, 0xff]` (dec. `[248, 255]`). In codice è: @@ -62,7 +62,7 @@ def encode_length(L, offset): elif L < 256**8: BL = to_binary(L) return chr(len(BL) + offset + 55) + BL - raise Exception("input too long") + raise Exception("input too long") def to_binary(x): if x == 0: @@ -74,36 +74,36 @@ def to_binary(x): - la stringa "dog" = [ 0x83, 'd', 'o', 'g' ] - l'elenco [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` -- la stringa vuota (“null”) = `[ 0x80 ]` +- la stringa vuota ('null') = `[ 0x80 ]` - l'elenco vuoto = `[ 0xc0 ]` - l'intero 0 = `[ 0x80 ]` - il byte '\\x00' = `[ 0x00 ]` - il byte '\\x0f' = `[ 0x0f ]` - i byte '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` -- la [data rappresentazione teorica](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) di tre, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` -- la stringa "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` +- la [rappresentazione insiemistica](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) di tre, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- la stringa "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` , 'e', 'l', 'i', 't' ]` ## Decodifica RLP {#rlp-decoding} Secondo le regole e il processo della codifica RLP, l'input della decodifica RLP è considerato come un array di dati binari. Il processo di decodifica RLP è il seguente: -1. a seconda del primo byte (ovvero il prefisso) dei dati di input e decodificando il tipo di dati, la lunghezza dei dati effettivi e l'offset; +1. in base al primo byte (ossia, il prefisso) dei dati di input e decodificando il tipo di dati, la lunghezza dei dati effettivi e l'offset; -2. secondo il tipo e lo scostamento dei dati, decodificali di conseguenza, rispettando la regola di codifica minimale per gli interi positivi; +2. secondo il tipo e lo scostamento dei dati, decodificali di conseguenza, rispettando la regola di codifica minimale per gli interi positivi; -3. continua a decodificare il resto dell'input; +3. continua a decodificare il resto dell'input; Tra loro, le regole per decodificare i tipi di dati e offset sono le seguenti: -1. i dati sono una stringa se l'intervallo del primo byte (prefisso) è [0x00, 0x7f] e la stringa corrisponde esattamente al primo byte; +1. i dati sono una stringa se l'intervallo del primo byte (ossia, il prefisso) è [0x00, 0x7f], e la stringa corrisponde esattamente al primo byte stesso; -2. i dati sono una stringa se l'intervallo del primo byte è [0x80, 0xb7] e la stringa la cui lunghezza è pari al primo byte meno 0x80 segue il primo byte; +2. i dati sono una stringa se l'intervallo del primo byte è [0x80, 0xb7] e la stringa la cui lunghezza è pari al primo byte meno 0x80 segue il primo byte; -3. i dati sono una stringa se l'intervallo del primo byte è [0xb8, 0xbf] e la lunghezza della stringa la cui lunghezza in byte è pari al primo byte meno 0xb7 segue il primo byte, e la stringa segue la lunghezza della stringa; +3. i dati sono una stringa se l'intervallo del primo byte è [0xb8, 0xbf] e la lunghezza della stringa la cui lunghezza in byte è pari al primo byte meno 0xb7 segue il primo byte, e la stringa segue la lunghezza della stringa; -4. i dati sono una lista se l'intervallo del primo byte è [0xc0, 0xf7] e la concatenazione delle codifiche RLP di tutti gli elementi della lista in cui il payload totale è uguale al primo byte meno 0xc0 segue il primo byte; +4. i dati sono una lista se l'intervallo del primo byte è [0xc0, 0xf7] e la concatenazione delle codifiche RLP di tutti gli elementi della lista in cui il payload totale è uguale al primo byte meno 0xc0 segue il primo byte; -5. i dati sono una lista se l'intervallo del primo byte è [0xf8, 0xff] e il payload totale dell'elenco la cui lunghezza equivale al primo byte meno 0xf7 segue il primo byte e la concatenazione delle codifiche RLP di tutti gli elementi dell'elenco segue il payload totale dell'elenco; +5. i dati sono una lista se l'intervallo del primo byte è [0xf8, 0xff] e il payload totale dell'elenco la cui lunghezza equivale al primo byte meno 0xf7 segue il primo byte e la concatenazione delle codifiche RLP di tutti gli elementi dell'elenco segue il payload totale dell'elenco; In codice è: @@ -155,9 +155,9 @@ def to_integer(b): ## Letture consigliate {#further-reading} - [RLP in Ethereum](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) -- [Dietro le quinte di Ethereum: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Ethereum dietro le quinte: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) - [Coglio, A. (2020). Prefisso di Lunghezza Ricorsiva di Ethereum in ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) ## Argomenti correlati {#related-topics} -- [Trie di Patricia Merkle](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) +- [Patricia merkle trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/it/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/it/developers/docs/data-structures-and-encoding/ssz/index.md index 14b76b7d1a0..80c3a64b363 100644 --- a/public/content/translations/it/developers/docs/data-structures-and-encoding/ssz/index.md +++ b/public/content/translations/it/developers/docs/data-structures-and-encoding/ssz/index.md @@ -5,7 +5,7 @@ lang: it sidebarDepth: 2 --- -**Simple serialize ** è il metodo di serializzazione usato sulla Beacon Chain. Sostituisce la serializzazione RLP usata sul livello d'esecuzione ovunque nel livello del consenso, tranne che per il protocollo di scoperta dei peer. SSZ è progettata per essere deterministica e anche efficiente nell'attività di Merkle-zzazione. SSZ può essere pensato come diviso in due componenti: uno schema di serializzazione e uno schema di Merkle-zzazione, progettato per funzionare efficientemente con la struttura di dati serializzati. +**Simple serialize (SSZ)** è il metodo di serializzazione usato sulla Beacon Chain. Sostituisce la serializzazione RLP usata sul livello d'esecuzione ovunque nel livello del consenso, tranne che per il protocollo di scoperta dei peer. Per saperne di più sulla serializzazione RLP, vedi [Prefisso di lunghezza ricorsiva (RLP)](/developers/docs/data-structures-and-encoding/rlp/). SSZ è progettata per essere deterministica e anche efficiente nell'attività di Merkle-zzazione. SSZ può essere pensato come diviso in due componenti: uno schema di serializzazione e uno schema di Merkle-zzazione, progettato per funzionare efficientemente con la struttura di dati serializzati. ## Come funziona SSZ? {#how-does-ssz-work} @@ -16,7 +16,7 @@ SSZ è uno schema di serializzazione non auto-descrivente; al contrario si affid - interi non firmati - Booleani -Per tipi "compositi" complessi, la serializzazione è più complicata perché il tipo composito contiene diversi elementi che potrebbero avere tipi o dimensioni o entrambi, differenti. Quando questi oggetti hanno tutti lunghezze fisse (ovvero la dimensione degli elementi è sempre costante, indipendentemente dai valori reali), la serializzazione è semplicemente una conversione di ogni elemento nel tipo composito ordinato in stringhe di byte little-endian. Queste stringhe di byte sono unite tra loro. L'oggetto serializzato ha la rappresentazione della serie di byte degli elementi a lunghezza fissa nello stesso ordine in cui appaiono nell'oggetto deserializzato. +Per tipi "compositi" complessi, la serializzazione è più complicata perché il tipo composito contiene diversi elementi che potrebbero avere tipi o dimensioni o entrambi, differenti. Quando questi oggetti hanno tutti lunghezze fisse (ovvero, la dimensione degli elementi è sempre costante, indipendentemente dai loro valori effettivi), la serializzazione è semplicemente una conversione di ogni elemento nel tipo composito ordinato in stringhe di byte little-endian. Queste stringhe di byte sono unite tra loro. L'oggetto serializzato ha la rappresentazione della serie di byte degli elementi a lunghezza fissa nello stesso ordine in cui appaiono nell'oggetto deserializzato. Per i tipi con lunghezze variabili, nell'oggetto serializzato i dati reali sono sostituiti da un valore di "offset" nella posizione di quell'elemento. I dati reali sono aggiunti alla fine dell'oggetto serializzato. Il valore di offset è l'indice per l'inizio dei dati reali nello heap, che serve da puntatore ai byte rilevanti. @@ -59,11 +59,11 @@ diviso su righe per chiarezza: ``` [ - 37, 0, 0, 0, # codifica endiana piccola di `number1`. - 55, 0, 0, 0, # codifica endiana piccola di `number2`. - 16, 0, 0, 0, # Lo "offset" che indica dove inizia il valore di `vector` (16 endiano piccolo). - 22, 0, 0, 0, # codifica endiana piccola di `number3`. - 1, 2, 3, 4, # I valori reali in `vector`. + 37, 0, 0, 0, # codifica little-endian di `number1`. + 55, 0, 0, 0, # codifica little-endian di `number2`. + 16, 0, 0, 0, # L'"offset" che indica dove inizia il valore di `vector` (little-endian 16). + 22, 0, 0, 0, # codifica little-endian di `number3`. + 1, 2, 3, 4, # I valori effettivi in `vector`. ] ``` @@ -71,17 +71,17 @@ Questa è comunque una semplificazione: gli interi e gli zeri negli schemi di cu ``` [ - 10100101000000000000000000000000 # codifica endiana piccola di `number1` - 10110111000000000000000000000000 # codifica endiana piccola di `number2`. - 10010000000000000000000000000000 # Lo "offset" che indica dove inizia il valore di `vector` (16 endiano piccolo). - 10010110000000000000000000000000 # codifica endiana piccola di `number3`. - 10000001100000101000001110000100 # Il valore reale del campo `bytes`. + 10100101000000000000000000000000 # codifica little-endian di `number1` + 10110111000000000000000000000000 # codifica little-endian di `number2`. + 10010000000000000000000000000000 # L'"offset" che indica dove inizia il valore di `vector` (little-endian 16). + 10010110000000000000000000000000 # codifica little-endian di `number3`. + 10000001100000101000001110000100 # Il valore effettivo del campo `bytes`. ] ``` Quindi i valori reali per i tipi di lunghezza variabile sono memorizzati in uno heap alla fine dell'oggetto serializzato, con i propri offset memorizzati nelle posizioni corrette nell'elenco di campi ordinato. -Esistono anche dei casi speciali che richiedono un trattamento specifico, come il tipo `BitList` che richiede che sia aggiunto un limite di lunghezza durante la serializzazione, e poi eliminato durante la deserializzazione. I dettagli completi sono disponibili nella [specifica SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md). +Esistono anche dei casi speciali che richiedono un trattamento specifico, come il tipo `BitList` che richiede che sia aggiunto un limite di lunghezza durante la serializzazione, e poi eliminato durante la deserializzazione. I dettagli completi sono disponibili nelle [specifiche SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md). ### Deserializzazione {#deserialization} @@ -89,7 +89,7 @@ Per deserializzare questo oggetto serve lo schema. Lo schema definisce la Vedi [ssz.dev](https://www.ssz.dev/overview) per una spiegazione interattiva a riguardo. -## Merkle-zzazione {#merkleization} +## Merkleizzazione {#merkleization} L’oggetto serializzato SSZ può essere poi merkle-zzato, ovvero trasformato in una rappresentazione dell'albero di Merkle di alcuni dati. Per prima cosa, è determinato il numero di blocchi da 32 byte nell'oggetto serializzato. Queste sono le "foglie" dell'albero. Il numero totale di foglie deve essere una potenza di 2, così che l'hashing delle foglie produca infine un albero-radice con un unico hash. Se questo non avviene naturalmente, sono aggiunte delle foglie aggiuntive contenenti 32 byte di zeri. In diagramma: @@ -109,11 +109,11 @@ L’oggetto serializzato SSZ può essere poi merkle-zzato, ovvero trasformato in Ci sono anche casi in cui le foglie dell'albero non si distribuiscono naturalmente e uniformemente come nell'esempio di cui sopra. Ad esempio, la foglia 4 potrebbe essere un contenitore con diversi elementi che richiedono che sia aggiunta ulteriore "profondità" all'albero di Merkle, creando un albero non equilibrato. -Invece di far riferimento a questi elementi dell'albero come foglia X, nodo X, ecc., possiamo dare loro indici generalizzati che iniziano con radice = 1, contando da sinistra a destra per ogni livello. Questo è l'indice generalizzato spiegato sopra. Ogni elemento nell'elenco serializzato ha un indice generalizzato pari a `2**depth + idx`, dove idx è la posizione indicizzata a zero nell'oggetto serializzato e "depth" è il numero di livelli nell'albero di Merkle, determinabile come il logaritmo a base due del numero di elementi (foglie). +Invece di far riferimento a questi elementi dell'albero come foglia X, nodo X, ecc., possiamo dare loro indici generalizzati che iniziano con radice = 1, contando da sinistra a destra per ogni livello. Questo è l'indice generalizzato spiegato sopra. Ogni elemento nell'elenco serializzato ha un indice generalizzato pari a `2**depth + idx`, dove `idx` è la sua posizione indicizzata a zero nell'oggetto serializzato e `depth` è il numero di livelli nell'albero di Merkle, che può essere determinato come il logaritmo in base due del numero di elementi (foglie). ## Indici generalizzati {#generalized-indices} -Un indice generalizzato è un intero rappresentante un nodo in un albero di Merkle binario, in cui ogni nodo ha un indice generalizzato `2 ** depth + index in row`. +Un indice generalizzato è un intero che rappresenta un nodo in un albero di Merkle binario in cui ogni nodo ha un indice generalizzato `2 ** depth + index in row`. ``` 1 --depth = 0 2**0 + 0 = 1 @@ -124,11 +124,12 @@ Un indice generalizzato è un intero rappresentante un nodo in un albero di Merk Questa rappresentazione produce un indice del nodo per ogni dato nell'albero di Merkle. -## Prove multiple {#multiproofs} +## Multiprove {#multiproofs} -Fornire l'elenco di indici generalizzati rappresentanti un elemento specifico ci consente di verificarlo rispetto all'hash albero-radice. Questa radice è la nostra versione accettata della realtà. Ogni dato che ci è fornito è verificabile rispetto a quella realtà inserendolo al posto giusto nell'albero di Merkle (determinato dal suo indice generalizzato) e osservando che la radice rimane costante. Ci sono delle funzioni nelle specifiche, [qui](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs), che mostrano come calcolare la serie minima di nodi necessari a verificare i contenuti di una serie particolare di indici generalizzati. +Fornire l'elenco di indici generalizzati rappresentanti un elemento specifico ci consente di verificarlo rispetto all'hash albero-radice. Questa radice è la nostra versione accettata della realtà. Ogni dato che ci è fornito è verificabile rispetto a quella realtà inserendolo al posto giusto nell'albero di Merkle (determinato dal suo indice generalizzato) e osservando che la radice rimane costante. Ci sono funzioni nelle specifiche [qui](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) che mostrano come calcolare l'insieme minimo di nodi richiesto per verificare i contenuti di un particolare insieme di indici generalizzati. -Ad esempio, per verificare i dati nell'indice 9 nell'albero seguente, abbiamo bisogno dell'hash dei dati agli indici 8, 9, 5, 3, 1. L'hash di (8,9) dovrebbe equivalere all'hash (4), il cui hash con 5 produce 2, il cui hash con 3 produce la radice dell'albero 1. Se venissero forniti dei dati errati per 9, la radice cambierebbe: lo rileveremmo e renderemmo impossibile verificare il ramo. +Ad esempio, per verificare i dati nell'indice 9 nell'albero seguente, abbiamo bisogno dell'hash dei dati agli indici 8, 9, 5, 3, 1. +L'hash di (8,9) dovrebbe equivalere all'hash (4), il cui hash con 5 produce 2, il cui hash con 3 produce la radice dell'albero 1. Se venissero forniti dei dati errati per 9, la radice cambierebbe: lo rileveremmo e renderemmo impossibile verificare il ramo. ``` * = dati necessari per generare la prova @@ -143,7 +144,7 @@ Ad esempio, per verificare i dati nell'indice 9 nell'albero seguente, abbiamo bi ## Letture consigliate {#further-reading} - [Aggiornare Ethereum: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) -- [Aggiornare Ethereum: Merkle-zzazione](https://eth2book.info/altair/part2/building_blocks/merkleization) -- [Implementazioni di SSZ](https://github.com/ethereum/consensus-specs/issues/2138) -- [Calcolatrice SSZ](https://simpleserialize.com/) +- [Aggiornare Ethereum: Merkleizzazione](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [Implementazioni SSZ](https://github.com/ethereum/consensus-specs/issues/2138) +- [Calcolatore SSZ](https://simpleserialize.com/) - [SSZ.dev](https://www.ssz.dev/) diff --git a/public/content/translations/it/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/it/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md new file mode 100644 index 00000000000..ce9fa4fcba0 --- /dev/null +++ b/public/content/translations/it/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md @@ -0,0 +1,195 @@ +--- +title: Definizione di archiviazione segreta di Web3 +description: Definizione formale di archiviazione segreta di Web3 +lang: it +sidebarDepth: 2 +--- + +Per far funzionare la tua app su Ethereum, puoi utilizzare l'oggetto web3 fornito dalla libreria di web3.js. Fondamentalmente, comunica a un nodo locale tramite chiamate RPC. [web3](https://github.com/ethereum/web3.js/) funziona con qualsiasi nodo di Ethereum che espone un livello RPC. + +`web3` contiene l'oggetto `eth` - web3.eth. + +```js +var fs = require("fs") +var recognizer = require("ethereum-keyfile-recognizer") + +fs.readFile("keyfile.json", (err, data) => { + var json = JSON.parse(data) + var result = recognizer(json) +}) + +/** risultato + * [ 'web3', 3 ] file della chiave web3 (v3) + * [ 'ethersale', undefined ] file della chiave Ethersale + * null file della chiave non valido + */ +``` + +Questo documento descrive la **versione 3** della Web3 Secret Storage Definition. + +## Definizione {#definition} + +La codifica e decofica effettiva del file resta largamente immutata dalla versione 1, tranne nel fatto che l'algoritmo cripto non è più fisso ad AES-128-CBC (AES-128-CTR è ora il requisito minimo). Gran parte dei significati/dell'algoritmo sono simili alla versione 1, tranne `mac`, che viene fornito come SHA3 (keccak-256) delle concatenazioni dei 16 byte al secondo posto da sinistra della chiave derivata insieme al `ciphertext` completo. + +I file della chiave segreta sono archiviati direttamente in `~/.web3/keystore` (per sistemi di tipo Unix) e `~/AppData/Web3/keystore` (per Windows). Possono avere qualsiasi nome, ma una buona convenzione è `.json`, dove `` è l'UUID a 128 bit assegnato alla chiave segreta (un proxy che preserva la privacy per l'indirizzo della chiave segreta). + +Tutti questi file sono associati a una password. Per derivare la chiave segreta di un dato file `.json`, deriva prima la chiave di crittografia del file; ciò si ottiene prendendo la password del file e passandola attraverso una funzione di derivazione della chiave, come descritto dalla chiave `kdf`. I parametri statici e dinamici dipendenti da KDF per la funzione KDF sono descritti nella chiave `kdfparams`. + +PBKDF2 dev'essere supportato da tutte le implementazioni minimamente conformi, denotato però: + +- `kdf`: `pbkdf2` + +Per PBKDF2, kdfparams include: + +- `prf`: Deve essere `hmac-sha256` (potrebbe essere esteso in futuro); +- `c`: numero di iterazioni; +- `salt`: salt passato a PBKDF; +- `dklen`: lunghezza della chiave derivata. Deve essere >= 32. + +Una volta derivata la chiave del file, dovrebbe essere verificata tramite la derivazione del MAC. Il MAC dovrebbe essere calcolato come l'hash SHA3 (keccak-256) dell'array di byte formato dalle concatenazioni dei 16 byte al secondo posto da sinistra della chiave derivata con i contenuti della chiave `ciphertext`, cioè: + +```js +KECCAK(DK[16..31] ++ ) +``` + +(dove `++` è l'operatore di concatenazione) + +Questo valore deve essere confrontato con il contenuto della chiave `mac`; se sono diversi, deve essere richiesta una password alternativa (o l'operazione annullata). + +Dopo aver verificato la chiave del file, il testo cifrato (la chiave `ciphertext` nel file) può essere decifrato utilizzando l'algoritmo di crittografia simmetrica specificato dalla chiave `cipher` e parametrizzato tramite la chiave `cipherparams`. Se la dimensione della chiave derivata e la dimensione della chiave dell'algoritmo non corrispondono, lo zero è riempito, i byte a destra della chiave derivata dovrebbero essere utilizzati come la chiave per l'algoritmo. + +Tutte le implementazioni minimamente conformi devono supportare l'algoritmo AES-128-CTR, denotato tramite: + +- `cipher: aes-128-ctr` + +Questa cifratura prende i seguenti parametri, dati come chiavi alla chiave cipherparams: + +- `iv`: vettore di inizializzazione a 128 bit per il cifrario. + +La chiave per il cifrario è costituita dai 16 byte più a sinistra della chiave derivata, cioè `DK[0..15]` + +La creazione/crittografia di una chiave segreta dovrebbe essere essenzialmente l'inverso di queste istruzioni. Assicurarsi che `uuid`, `salt` e `iv` siano effettivamente casuali. + +Oltre al campo `version`, che dovrebbe fungere da identificatore "hard" della versione, le implementazioni possono anche utilizzare `minorversion` per tenere traccia di modifiche più piccole e non di rottura al formato. + +## Vettori di test {#test-vectors} + +Dettagli: + +- `Indirizzo`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` +- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` +- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` +- `Password`: `testpassword` +- `Segreto`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` + +### PBKDF2-SHA-256 {#PBKDF2-SHA-256} + +Vettore di test che utilizza `AES-128-CTR` e `PBKDF2-SHA-256`: + +Contenuto del file `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "6087dab2f9fdbbfaddc31a909735c1e6" + }, + "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", + "kdf": "pbkdf2", + "kdfparams": { + "c": 262144, + "dklen": 32, + "prf": "hmac-sha256", + "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" + }, + "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Intermedi:** + +`Chiave derivata`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` +`Corpo del MAC`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` +`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` +`Chiave del cifrario`: `f06d69cdc7da0faffb1008270bca38f5` + +### Scrypt {#scrypt} + +Vettore di prova che utilizza AES-128-CTR e Scrypt: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "740770fce12ce862af21264dab25f1da" + }, + "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" + }, + "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Intermedi:** + +`Chiave derivata`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` +`Corpo del MAC`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` +`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` +`Chiave del cifrario`: `7446f59ecc301d2d79bc3302650d8a5c` + +## Modifiche rispetto alla versione 1 {#alterations-from-v2} + +Questa versione corregge diverse incongruenze con la versione 1 pubblicata [qui](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst). In breve sono: + +- Capitalizzazione ingiustificata e incoerente (scrypt minuscolo, maiuscole miste in Kdf e MAC maiuscolo). +- Indirizzo non necessario e compromette l'anonimato. +- `Salt` è intrinsecamente un parametro della funzione di derivazione della chiave e merita di essere associato ad essa, non alla crittografia in generale. +- _SaltLen_ non necessario (basta derivarlo da Salt). +- La funzione di derivazione della chiave è data, ma l'algoritmo cripto è specificato rigidamente. +- `Version` è intrinsecamente numerico ma è una stringa (il versionamento strutturato sarebbe possibile con una stringa, ma può essere considerato fuori dall'ambito di un formato di file di configurazione che cambia raramente). +- `KDF` e `cipher` sono concetti affini, eppure sono organizzati in modo diverso. +- Il `MAC` è calcolato tramite un pezzo di dati che ignora gli spazi bianchi (!). + +Le modifiche sono state apportate al formato per restituire il seguente file, funzionalmente equivalente all'esempio dato sulla pagina collegata in precedenza: + +```json +{ + "crypto": { + "cipher": "aes-128-cbc", + "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", + "cipherparams": { + "iv": "16d67ba0ce5a339ff2f07951253e6ba8" + }, + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" + }, + "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", + "version": 1 + }, + "id": "0498f19a-59db-4d54-ac95-33901b4f1870", + "version": 2 +} +``` + +## Modifiche rispetto alla versione 2 {#alterations-from-v2} + +La versione 2 era un'implementazione iniziale in C++ con numerosi bug. Tutti gli elementi essenziali restano immutati da essa. diff --git a/public/content/translations/it/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/it/developers/docs/design-and-ux/dex-design-best-practice/index.md index c63da6300fd..802dd716f88 100644 --- a/public/content/translations/it/developers/docs/design-and-ux/dex-design-best-practice/index.md +++ b/public/content/translations/it/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -206,7 +206,7 @@ Il pulsante può anche venire **mappato all'azione** che deve essere eseguita. P ![Messaggio di errore visualizzato nella CTA principale](./17.png) -### Costruisci la tua con questo file di Figma {#build-your-own-with-this-figma-file} +## Costruisci la tua con questo file di Figma {#build-your-own-with-this-figma-file} Grazie al duro lavoro di vari protocolli, la progettazione delle DEX è migliorata parecchio. Sappiamo di quali informazioni ha bisogno l'utente, come dobbiamo visualizzarle e come far andare più liscio possibile il flusso. Speriamo che questo articolo ti abbia dato una solida panoramica dei principi UX. 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..41b12b7eeba 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 --- @@ -54,7 +54,7 @@ Le persone tengono moltissimo ai loro dati. La sicurezza è spesso una preoccupa **Esempio:** Includere i propri controlli a piè pagina, ad una dimensione ben visibile. -![Controlli citati a piè pagina nel sito](./Image2.png) +![Controlli citati a piè di pagina nel sito](./Image2.png) ### 3. L'informazione più importante è ovvia {#the-most-important-info-is-obvious} 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..6accd282446 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 @@ -6,86 +6,81 @@ lang: it Sei nuovo alla progettazione con Ethereum? Questo è il posto giusto per te. La community di Ethereum ha scritto le risorse per introdurti alle basi della progettazione e della ricerca web3. Imparerai i concetti fondamentali che potrebbero differire da altri progetti di applicazioni con cui hai familiarità. -Hai prima bisogno di una conoscenza più di base del web3? Dai un'occhiata al [**Learn Hub**](/learn/). +Hai prima bisogno di una conoscenza più di base del web3? Dai un'occhiata all'[**hub di apprendimento**](/learn/). -## Inizia con la ricerca utente {#start-with-user-research} +## Inizia con la ricerca sugli utenti {#start-with-user-research} -La progettazione efficace va oltre la creazione di interfacce utente accattivanti a livello visivo. Si tratta di comprendere a fondo i bisogni, gli obiettivi e i fattori trainanti dell'utente. Pertanto, consigliamo fortemente che tutti i progettisti adottino un processo di progettazione come il [**processo del doppio diamante**](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)), per assicurare che il loro lavoro sia consapevole e intenzionale. +La progettazione efficace va oltre la creazione di interfacce utente accattivanti a livello visivo. Si tratta di comprendere a fondo i bisogni, gli obiettivi e i fattori trainanti dell'utente. Pertanto, consigliamo vivamente a tutti i designer di adottare un processo di progettazione, come il [**processo del doppio diamante**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\)), per assicurare che il loro lavoro sia deliberato e intenzionale. -- [Il Web3 necessita di più ricercatori e progettisti di UX](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - Una panoramica dell'attuale maturità della progettazione -- [Una guida semplice alla ricerca UX](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - Una semplice guida su come fare ricerca -- [Come affrontare le decisioni di UX nel Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - Una breve panoramica di ricerca quantitativa e qualitativa e le differenze tra queste due (video, 6 minuti) -- [Essere un ricercatore ux nel web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Un punto di vista personale su cosa significhi essere un ricercatore UX nel web3 +- [Web3 ha bisogno di più ricercatori e designer UX](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) - Una panoramica sulla maturità attuale del design +- [Una guida semplice alla ricerca UX in web3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) - Guida semplice su come fare ricerca +- [Come affrontare le decisioni UX in Web3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) - Una breve panoramica sulla ricerca quantitativa e qualitativa e le differenze tra le due (video, 6 min) +- [Essere un ricercatore UX in web3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) - Un punto di vista personale su cosa significhi essere un ricercatore UX in web3 -## Studi di ricerca nel web3 {#research-in-web3} +## Studi di ricerca in web3 {#research-in-web3} Questo è un elenco curato di ricerche utente fatte nel web3 che potrebbero esserti utili nelle decisioni di progettazione e prodotto o potrebbero inspirarti a condurre nuovi studi. -| Area di interesse | Nome | -|:--------------------------------------------------------------------- |:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Integrazione delle criptovalute | [WalletConnect Pulse 2024: Opinione e utilizzo del cripto-consumatore](https://walletconnect.com/pulse-2024-crypto-consumer-report) | -| Integrazione delle criptovalute | [CRADL: la UX nelle criptovalute](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | -| Integrazione delle criptovalute | [CRADL: ingresso nelle criptovalute](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | -| Integrazione delle criptovalute | [Report sulla UX Bitcoin](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | -| Integrazione delle criptovalute | [ConSensys: lo stato della percezione del Web3 nel mondo nel 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | -| Integrazione delle criptovalute | [NEAR: accelerare il percorso di adozione](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | -| Staking | [OpenUX: UX dell'operatore del nodo in pool di Rocket](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | -| Staking | [Staking: Tendenze fondamentali, risultati e previsioni - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | -| Staking | [Staking a Più App](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | -| OAD | [Aggiornamento 2022 sulla ricerca delle DAO: di cosa hanno bisogno i costruttori di DAO?](https://blog.aragon.org/2022-dao-research-update/) | -| DeFi | [Lo stato della Defi 2024](https://stateofdefi.org/) (sondaggio in corso) | -| DeFi | [Gruppi di copertura](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | -| DeFi | [ConSensys: rapporto di ricerca sugli utenti DeFI 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | -| Metaverso | [Metaverso: report di ricerca sugli utenti](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | -| Metaverso | [Andare ad un Safari: ricerca sugli utenti nel Metaverso](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (video, 27 minuti) | -| Statistiche dell'UX di Ethereum.org | [Pannello di controllo del sondaggio sull'utilizzabilità e soddisfazione degli utenti - Ethereum.org](https://lookerstudio.google.com/reporting/0a189a7c-a890-40db-a5c6-009db52c81c9) | - -## Progettazione per il web3 {#design-for-web3} - -- [Web3 UX Design Handbook](https://web3ux.design/) - Guida pratica alla progettazione di applicazioni Web3 -- [Principi di progettazione Web3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - Un framework di regole di UX per le dapp basate su blockchain -- [Principi di progettazione blockchain](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - Lezioni apprese dal team di progettazione blockchain di IBM -- [Modello di progettazione Web3](https://www.web3designpatterns.io/)- Una libreria curata di modelli di progettazione di prodotti Web3 reali -- [W3design.io](https://w3design.io/) - Una libreria curata di flussi di UI di vari progetti nell'ecosistema -- [Neueux.com](https://neueux.com/apps) - Una libreria UI di flussi di utenti con diversi opzioni di filtro -- [Web3's Usability Crisis: What You NEED to Know!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - Una tavola rotonda sulle insidie della creazione di progetti incentrati sugli sviluppatori (video, 34 minuti) - -## Primi passi {#getting-started} - -- [Euristiche per il Web3](/developers/docs/design-and-ux/heuristics-for-web3/): 7 euristiche per la progettazione dell'interfaccia di Web3 -- [Migliori pratiche di progettazione delle DEX](/developers/docs/design-and-ux/dex-design-best-practice/): Una guida alla progettazione di borse decentralizzate - -## Casi di studio di progettazione Web3 {#design-case-studies} - -- [Deep Work Studio](https://deepwork.studio/case-studies/) -- [Manuale di UX cripto](https://www.cryptouxhandbook.com/) +| Area di interesse | Nome | +| :------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Onboarding Cripto | [The Reown Pulse 2024: Crypto Consumer Sentiment & Usage](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) | +| Onboarding Cripto | [CRADL: UX nelle criptovalute](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | +| Onboarding Cripto | [CRADL: Onboarding alle criptovalute](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | +| Onboarding Cripto | [Report sulla UX di Bitcoin](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | +| Onboarding Cripto | [Consensys: Lo stato della percezione di Web3 nel mondo 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | +| Onboarding Cripto | [NEAR: Accelerare il percorso verso l'adozione](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | +| Staking | [OpenUX: UX per gli operatori di nodi di Rocket Pool](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | +| Staking | [Staking: tendenze principali, spunti e previsioni - Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | +| Staking | [Staking multi-app](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | +| DAO | [Aggiornamento sulla ricerca sulle DAO del 2022: di cosa hanno bisogno i costruttori di DAO?](https://blog.aragon.org/2022-dao-research-update/) | +| DeFi | [Pool di copertura](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | +| DeFi | [Consensys: Report sulla ricerca sugli utenti DeFi del 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | +| Metaverso | [Metaverso: Report sulla ricerca sugli utenti](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | +| Metaverso | [Andare in safari: fare ricerca sugli utenti nel Metaverso](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (video, 27 min) | + +## Design per web3 {#design-for-web3} + +- [Manuale di progettazione UX per Web3](https://web3ux.design/) - Guida pratica alla progettazione di app Web3 +- [Principi di design per Web3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) - Un framework di regole UX per dApp basate su blockchain +- [Principi di design per la blockchain](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) - Lezioni apprese dal team di design della blockchain di IBM +- [Neueux.com](https://neueux.com/apps) - Libreria UI di flussi utente con diverse opzioni di filtro +- [La crisi di usabilità di Web3: cosa DEVI sapere!](https://www.youtube.com/watch?v=oBSXT_6YDzg) - Una tavola rotonda sulle insidie della creazione di progetti incentrati sugli sviluppatori (video, 34 min) + +## Per iniziare {#getting-started} + +- [Euristiche per Web3](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 euristiche per la progettazione di interfacce Web3 +- [Migliori pratiche per la progettazione di DEX](/developers/docs/design-and-ux/dex-design-best-practice/) - Una guida alla progettazione di exchange decentralizzati + +## Casi di studio sul design Web3 {#design-case-studies} + +- [Deep Work Studio](https://www.deepwork.studio/case-studies) - [Vendere un NFT su OpenSea](https://builtformars.com/case-studies/opensea) -- [UX del portafoglio: un'analisi di come i portafogli devono cambiare](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (video, 20 min) +- [Analisi approfondita della UX dei portafogli: come devono cambiare](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (video, 20 min) -## Ricompense di progettazione {#bounties} +## Ricompense per il design {#bounties} - [Dework](https://app.dework.xyz/bounties) - [Hackathon di Buildbox](https://app.buidlbox.io/) - [Hackathon di ETHGlobal](https://ethglobal.com/) -## Progettazione di DAO e di community {#design-daos-and-communities} +## DAO e community di design {#design-daos-and-communities} Partecipate ad organizzazioni professionali guidate dalla community o unitevi a gruppi di progettazione per discutere argomenti e tendenze legati a progetti e alla ricerca con altri membri. - [Vectordao.com](https://vectordao.com/) - [Deepwork.studio](https://www.deepwork.studio/) -- [Designer-dao.xyz](https://www.designer-dao.xyz/) - [We3.co](https://we3.co/) - [Openux.xyz](https://openux.xyz/) -## Sistemi di progettazione {#design-systems} +## Sistemi di design e altre risorse di design {#design-systems-and-resources} -- [Progettazione di Optimism](https://www.figma.com/@optimism) (Figma) -- [Sistema di progettazione di Ethereum.org](https://www.figma.com/@ethdotorg) (Figma) -- [Finity, un sistema di progettazione di Polygon](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) -- [Sistema di progettazione Kleros](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) -- [Sistema di progettazione Sicuro](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) -- [Sistema di progettazione ENS](https://thorin.ens.domains/) -- [Sistema di progettazione Mirror](https://degen-xyz.vercel.app/) +- [Design di Optimism](https://www.figma.com/@optimism) (Figma) +- [Sistema di design di Ethereum.org](https://www.figma.com/@ethdotorg) (Figma) +- [Finity, un sistema di design di Polygon](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) +- [Sistema di design di Kleros](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) +- [Sistema di design di Safe](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) +- [Sistema di design di ENS](https://thorin.ens.domains/) +- [Sistema di design di Mirror](https://degen-xyz.vercel.app/) -**Gli articoli e i progetti elencati in questa pagina non costituiscono sponsorizzazioni ufficiali** e sono forniti solo a scopo informativo. Aggiungiamo i collegamenti a questa pagina in base ai criteri della nostra [politica di inserimento](/contributing/design/adding-design-resources). Se vorresti che aggiungessimo un progetto/articolo, modifica questa pagina su [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md). +**Gli articoli e i progetti elencati in questa pagina non costituiscono sponsorizzazioni ufficiali** e sono forniti solo a scopo informativo. +Aggiungiamo link a questa pagina in base ai criteri della nostra [politica di inserimento](/contributing/design/adding-design-resources). Se desideri che aggiungiamo un progetto/articolo, modifica questa pagina su [GitHub](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md). diff --git a/public/content/translations/it/developers/docs/evm/index.md b/public/content/translations/it/developers/docs/evm/index.md index c1ae60e919f..e115c71f5d1 100644 --- a/public/content/translations/it/developers/docs/evm/index.md +++ b/public/content/translations/it/developers/docs/evm/index.md @@ -1,77 +1,87 @@ --- -title: Macchina virtuale Ethereum (EVM) +title: Macchina Virtuale Ethereum (EVM) description: Un'introduzione alla Macchina Virtuale di Ethereum e a come si relaziona allo stato, alle transazioni e ai contratti intelligenti. 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 "[gas](/developers/docs/gas/)" per misurare lo sforzo computazionale richiesto per le [operazioni](/developers/docs/evm/opcodes/), assicurando un'allocazione efficiente delle risorse e la sicurezza della rete. ## Prerequisiti {#prerequisites} -Per comprendere l'EVM, è richiesta una conoscenza di base dei termini comuni dell'informatica, come ad esempio [byte](https://wikipedia.org/wiki/Byte), [memoria](https://wikipedia.org/wiki/Computer_memory) e [stack](https://wikipedia.org/wiki/Stack_(abstract_data_type)). Sarebbe inoltre utile esser a conoscenza dei concetti crittografici e della blockchain come le [funzioni di hash](https://wikipedia.org/wiki/Cryptographic_hash_function) e l'[albero di Merkle](https://wikipedia.org/wiki/Merkle_tree). +Per comprendere l'EVM è necessaria una certa familiarità con la terminologia comune dell'informatica, come [byte](https://wikipedia.org/wiki/Byte), [memoria](https://wikipedia.org/wiki/Computer_memory) e [stack](https://wikipedia.org/wiki/Stack_\(abstract_data_type\)). Sarebbe anche utile avere familiarità con i concetti di crittografia/blockchain come le [funzioni di hash](https://wikipedia.org/wiki/Cryptographic_hash_function) e l'[albero di Merkle](https://wikipedia.org/wiki/Merkle_tree). ## Dal libro mastro alla macchina a stati {#from-ledger-to-state-machine} Per descrivere blockchain come Bitcoin, viene spesso utilizzata l'analogia con un "libro mastro distribuito", che permette l'esistenza di una valuta decentralizzata utilizzando strumenti base della crittografia. Il libro mastro mantiene un registro delle attività che deve aderire a una serie di regole che governano ciò che qualcuno può e non può fare per modificarlo. Ad esempio, un indirizzo Bitcoin non può spendere più Bitcoin di quanti ne abbia ricevuti in precedenza. Queste regole sono alla base di tutte le transazioni su Bitcoin e di molte altre blockchain. -Mentre Ethereum ha la propria criptovaluta nativa (Ether) che segue quasi esattamente le stesse regole intuitive, consente anche una funzione molto più potente: i [contratti intelligenti](/developers/docs/smart-contracts/). Per questa caratteristica più complessa, è necessaria un'analogia più complessa. Invece di essere un libro mastro distribuito, Ethereum è una [macchina di stato distribuita](https://wikipedia.org/wiki/Finite-state_machine). Lo stato di Ethereum è una grande struttura di dati che contiene non solo tutti i conti e i saldi, ma uno _stato della macchina_, che può cambiare da blocco a blocco secondo una serie predefinita di regole e che può eseguire il codice arbitrario della macchina. Le regole specifiche di cambio stato da blocco a blocco sono definite dall'EVM. +Sebbene Ethereum abbia la sua criptovaluta nativa (ether) che segue quasi esattamente le stesse regole intuitive, abilita anche una funzione molto più potente: i [contratti intelligenti](/developers/docs/smart-contracts/). Per questa caratteristica più complessa, è necessaria un'analogia più complessa. Invece di essere un libro mastro distribuito, Ethereum è una [macchina a stati](https://wikipedia.org/wiki/Finite-state_machine) distribuita. Lo stato di Ethereum è una grande struttura dati che contiene non solo tutti i conti e i saldi, ma anche uno _stato della macchina_, che può cambiare da blocco a blocco secondo una serie di regole predefinite e che può eseguire codice macchina arbitrario. Le regole specifiche di cambio stato da blocco a blocco sono definite dall'EVM. -![Ddiagramma che mostra la composizione dell'EVM](./evm.png) _Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Un diagramma che mostra la composizione dell'EVM](./evm.png) +_Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ ## La funzione di transizione di stato di Ethereum {#the-ethereum-state-transition-function} -L'EVM si comporta come una funzione matematica: dato un input, produce un output deterministico. Quindi è più utile descrivere formalmente Ethereum come avente una **funzione di transizione di stato**: +L'EVM si comporta come una funzione matematica: dato un input, produce un output deterministico. È quindi molto utile descrivere più formalmente Ethereum come avente una **funzione di transizione di stato**: ``` Y(S, T)= S' ``` -Dato un vecchio stato valido `(S)` e un nuovo set di transazioni valide `(T)`, la funzione di transizione di stato di Ethereum `Y(S, T)` produce un nuovo stato di output valido `S'` +Dato un vecchio stato valido `(S)` e un nuovo insieme di transazioni valide `(T)`, la funzione di transizione di stato di Ethereum `Y(S, T)` produce un nuovo stato di output valido `S'` ### Stato {#state} -Nel contesto di Ethereum, lo stato è un'enorme struttura di dati detta un [albero di Patricia Merkle modificato](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), che contiene tutti i [conti](/developers/docs/accounts/) collegati da hash e riducibili a un singolo hash di radice, archiviato sulla blockchain. +Nel contesto di Ethereum, lo stato è un'enorme struttura dati chiamata [Merkle Patricia Trie modificato](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), che mantiene tutti i [conti](/developers/docs/accounts/) collegati da hash e riducibili a un singolo hash radice memorizzato sulla blockchain. ### Transazioni {#transactions} Le transazioni sono istruzioni firmate crittograficamente, provenienti dai conti. Esistono due tipi di transazioni: quelle che danno luogo a chiamate di messaggio e quelle che invece danno luogo alla creazione di contratti. -La creazione del contratto risulta nella creazione di un nuovo conto del contratto, contenente bytecode compilato del [contratto intelligente](/developers/docs/smart-contracts/anatomy/). Ogni volta che un altro conto effettua una chiamata di messaggio a quel contratto, esegue il suo bytecode. +La creazione di un contratto comporta la creazione di un nuovo conto di contratto contenente il bytecode del [contratto intelligente](/developers/docs/smart-contracts/anatomy/) compilato. Ogni volta che un altro conto effettua una chiamata di messaggio a quel contratto, esegue il suo bytecode. -## Istruzioni dell'EVM {#evm-instructions} +## Istruzioni EVM {#evm-instructions} -L'EVM viene eseguita come una [macchina a stack](https://wikipedia.org/wiki/Stack_machine) con una profondità di 1024 elementi. Ogni elemento è una parola di 256 bit, scelta per la facilità d'uso con la crittografia a 256 bit (come gli hash Keccak-256 o le firme secp256k1). +L'EVM esegue come una [macchina a stack](https://wikipedia.org/wiki/Stack_machine) con una profondità di 1024 elementi. Ogni elemento è una parola di 256 bit, scelta per la facilità d'uso con la crittografia a 256 bit (come gli hash Keccak-256 o le firme secp256k1). -Durante l'esecuzione, l'EVM mantiene una _memoria_ transitoria (sotto forma di array di byte con indirizzamento a parola), che non rimane persistente tra le transazioni. +Durante l'esecuzione, l'EVM mantiene una _memoria_ transitoria (come un array di byte indirizzato a parola), che non persiste tra le transazioni. -I contratti, comunque, contengono un albero d'_archiviazione_ di Merkle Patricia (come un insieme indirizzabile alle parole contenute), associato al conto in questione e parte dello stato globale. +### Archiviazione transitoria -Il bytecode compilato del contratto intelligente è eseguito come un numero degli [opcode](/developers/docs/evm/opcodes) dell'EVM, che eseguono operazioni standard dello stack come `XOR`, `AND`, `ADD`, `SUB`, etc. L'EVM implementa anche una serie di operazioni di stack specifiche della blockchain, come `INDIRIZZO`, `SALDO`, `BLOCKHASH`, etc. +L'archiviazione transitoria è un archivio chiave-valore per transazione, a cui si accede tramite i codici operativi `TSTORE` e `TLOAD`. Persiste attraverso tutte le chiamate interne durante la stessa transazione, ma viene cancellata alla fine della transazione. A differenza della memoria, l'archiviazione transitoria è modellata come parte dello stato dell'EVM piuttosto che del frame di esecuzione, ma non viene salvata nello stato globale. L'archiviazione transitoria consente la condivisione temporanea dello stato efficiente in termini di gas tra le chiamate interne durante una transazione. -![Un diagramma che mostra dove è necessario il gas per le operazioni dell'EVM](../gas/gas.png) _Diagramma adattato da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +### Storage -## Implementazioni dell'EVM {#evm-implementations} +I contratti contengono un trie di _archiviazione_ Merkle Patricia (come un array di parole indirizzabile a parola), associato al conto in questione e parte dello stato globale. Questa archiviazione persistente si differenzia dall'archiviazione transitoria, che è disponibile solo per la durata di una singola transazione e non fa parte del trie di archiviazione persistente del conto. + +### Codici operativi + +Il bytecode del contratto intelligente compilato viene eseguito come una serie di [opcode](/developers/docs/evm/opcodes) EVM, che eseguono operazioni standard dello stack come `XOR`, `AND`, `ADD`, `SUB`, ecc. L'EVM implementa anche una serie di operazioni stack specifiche della blockchain, come `ADDRESS`, `BALANCE`, `BLOCKHASH`, ecc. Il set di opcode include anche `TSTORE` e `TLOAD`, che forniscono l'accesso all'archiviazione transitoria. + +![Un diagramma che mostra dove è necessario il gas per le operazioni EVM](../gas/gas.png) +_Diagrammi adattati da [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ + +## Implementazioni EVM {#evm-implementations} Tutte le implementazioni dell'EVM devono rispettare le specifiche descritte nello Yellowpaper di Ethereum. -Nei nove anni di storia di Ethereum, l'EVM ha subito diverse revisioni, ed esistono diverse implementazioni dell'EVM in vari linguaggi di programmazione. +Nei dieci anni di storia di Ethereum, l'EVM ha subito diverse revisioni, ed esistono diverse implementazioni dell'EVM in vari linguaggi di programmazione. -Tutti i [client Ethereum](/developers/docs/nodes-and-clients/#execution-clients) includono un'implementazione dell'EVM. Inoltre, esistono diverse implementazioni standalone, tra cui: +I [client di esecuzione di Ethereum](/developers/docs/nodes-and-clients/#execution-clients) includono un'implementazione dell'EVM. Inoltre, esistono diverse implementazioni standalone, tra cui: - [Py-EVM](https://github.com/ethereum/py-evm) - _Python_ - [evmone](https://github.com/ethereum/evmone) - _C++_ - [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ - [revm](https://github.com/bluealloy/revm) - _Rust_ -## Letture consigliate {#further-reading} +## Ulteriori letture {#further-reading} -- [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf) -- [Jellopaper o KEVM: Semantica di EVM in K](https://jellopaper.org/) +- [Yellowpaper di Ethereum](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Jellopaper, noto anche come KEVM: Semantica dell'EVM in K](https://jellopaper.org/) - [The Beigepaper](https://github.com/chronaeon/beigepaper) -- [Ethereum Virtual Machine Opcodes](https://www.ethervm.io/) -- [Documentazione di riferimento del codice operativo della macchina virtuale di Ethereum](https://www.evm.codes/) -- [Una breve introduzione alla documentazione di Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) -- [Padroneggiare Ethereum - La Macchina Virtuale di Ethereum](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) +- [Codici operativi della Macchina Virtuale di Ethereum](https://www.ethervm.io/) +- [Riferimento interattivo ai codici operativi della Macchina Virtuale di Ethereum](https://www.evm.codes/) +- [Una breve introduzione nella documentazione di Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) +- [Mastering Ethereum - La Macchina Virtuale di Ethereum](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) ## Argomenti correlati {#related-topics} diff --git a/public/content/translations/it/developers/docs/evm/opcodes/index.md b/public/content/translations/it/developers/docs/evm/opcodes/index.md index 3bc11b514ee..3856e39fe17 100644 --- a/public/content/translations/it/developers/docs/evm/opcodes/index.md +++ b/public/content/translations/it/developers/docs/evm/opcodes/index.md @@ -6,169 +6,172 @@ lang: it ## Panoramica {#overview} -Questa è una versione aggiornata della pagina di riferimento dell'EVM a [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). Tratta anche dallo [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), dal [Jello Paper](https://jellopaper.org/evm/) e dall'implementazione di [geth](https://github.com/ethereum/go-ethereum). Si tratta di un riferimento accessibile, ma non particolarmente rigoroso. Se vuoi essere certo della correttezza e consapevole di ogni caso limite, è consigliabile utilizzare lo Jello Paper o un'implementazione del client. +Questa è una versione aggiornata della pagina di riferimento EVM su [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). +Tratto anche da [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), [Jello Paper](https://jellopaper.org/evm/) e dall'implementazione di [geth](https://github.com/ethereum/go-ethereum). +Si tratta di un riferimento accessibile, ma non particolarmente rigoroso. +Se vuoi essere certo della correttezza e consapevole di ogni caso limite, è consigliabile utilizzare lo Jello Paper o un'implementazione del client. -Cerchi un riferimento interattivo? Dai un'occhiata su [evm.codes](https://www.evm.codes/). +Cerchi un riferimento interattivo? Dai un'occhiata a [evm.codes](https://www.evm.codes/). -Per le operazioni con costi del carburante dinamici, consulta [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md). +Per le operazioni con costi dinamici del gas, vedi [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md). 💡 Consiglio rapido: per visualizzare le righe intere, usa `[shift] + scorrimento` per scorrere orizzontalmente su desktop. -| Stack | Nome | Gas | Stack Iniziale | Stack Risultante | Mem / Archiviazione | Note | -|:-----:|:-------------- |:------------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 00 | STOP | 0 | | | | halt execution | -| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 | -| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 | -| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 | -| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division | -| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division | -| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus | -| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus | -| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N | -| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N | -| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 | -| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes | -| 0C-0F | _invalid_ | | | | | | -| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than | -| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than | -| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than | -| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than | -| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality | -| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero | -| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND | -| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR | -| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR | -| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT | -| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left | -| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left | -| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right | -| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right | -| 1E-1F | _invalid_ | | | | | | -| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | -| 21-2F | _invalid_ | | | | | | -| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract | -| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei | -| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx | -| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender | -| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei | -| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` | -| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes | -| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data | -| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes | -| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode | -| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | -| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes | -| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` | -| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes | -| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call | -| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 | -| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | -| 41 | COINBASE | 2 | `.` | `block.coinbase` | | indirizzo del propositore del blocco corrente | -| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block | -| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block | -| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon | -| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block | -| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack | -| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei | -| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block | -| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | -| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | commissione di base del blob del blocco corrente ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | -| 4B-4F | _invalid_ | | | | | | -| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it | -| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` | -| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory | -| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory | -| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage | -| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage | -| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest | -| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` | -| 58 | PC | 2 | `.` | `$pc` | | program counter | -| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes | -| 5A | GAS | 2 | `.` | `gasRemaining` | | | -| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data | -| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | legge la parola dall'archiviazione transiente ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | scrive la parola all'archiviazione transiente ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5E | MCOPY | 3+3\*parole+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copia la memoria da un'area a un'altra ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | -| 5F | PUSH0 | 2 | `.` | `uint8` | | spinge il valore costante 0 allo stack | -| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack | -| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack | -| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack | -| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack | -| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack | -| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack | -| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack | -| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack | -| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack | -| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack | -| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack | -| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack | -| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack | -| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack | -| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack | -| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack | -| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack | -| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack | -| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack | -| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack | -| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack | -| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack | -| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack | -| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack | -| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack | -| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack | -| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack | -| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack | -| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack | -| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack | -| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack | -| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack | -| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack | -| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack | -| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack | -| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack | -| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack | -| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack | -| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack | -| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack | -| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack | -| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack | -| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack | -| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack | -| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack | -| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack | -| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack | -| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack | -| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | -| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | -| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | -| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | -| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | -| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | -| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | -| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | -| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | -| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | -| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | -| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | -| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | -| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | -| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | -| A5-EF | _invalid_ | | | | | | -| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | -| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value | -| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] | -| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | -| F6-F9 | _invalid_ | | | | | | -| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| FB-FC | _invalid_ | | | | | | -| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | -| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | -| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | invia tutti gli ETH ad `addr`; se eseguito nella stessa transazione in cui un contratto è stato creato, lo distrugge | +| Stack | Nome | Carburante | Stack Iniziale | Stack Risultante | Mem / Archiviazione | Note | | +| :---: | :------------- | :---------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | +| 00 | STOP | 0 | | | | arresta l'esecuzione | | +| 01 | ADD | 3 | `a, b` | `a + b` | | addizione (u)int256 modulo 2\*\*256 | | +| 02 | MUL | 5 | `a, b` | `a * b` | | moltiplicazione (u)int256 modulo 2\*\*256 | | +| 03 | SUB | 3 | `a, b` | `a - b` | | sottrazione (u)int256 modulo 2\*\*256 | | +| 04 | DIV | 5 | `a, b` | `a // b` | | divisione uint256 | | +| 05 | SDIV | 5 | `a, b` | `a // b` | | divisione int256 | | +| 06 | MOD | 5 | `a, b` | `a % b` | | modulo uint256 | | +| 07 | SMOD | 5 | `a, b` | `a % b` | | modulo int256 | | +| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | addizione (u)int256 modulo N | | +| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | moltiplicazione (u)int256 modulo N | | +| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | esponenziazione uint256 modulo 2\*\*256 | | +| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [estensione del segno](https://wikipedia.org/wiki/Sign_extension) di `x` da `(b+1)` byte a 32 byte | | +| 0C-0F | _non valido_ | | | | | | | +| 10 | LT | 3 | `a, b` | `a < b` | | uint256 minore di | | +| 11 | GT | 3 | `a, b` | `a > b` | | uint256 maggiore di | | +| 12 | SLT | 3 | `a, b` | `a < b` | | int256 minore di | | +| 13 | SGT | 3 | `a, b` | `a > b` | | int256 maggiore di | | +| 14 | EQ | 3 | `a, b` | `a == b` | | uguaglianza (u)int256 | | +| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 è zero | | +| 16 | AND | 3 | `a, b` | `a && b` | | AND bit a bit | | +| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | OR bit a bit | | +| 18 | XOR | 3 | `a, b` | `a ^ b` | | XOR bit a bit | | +| 19 | NOT | 3 | `a` | `~a` | | NOT bit a bit | | +| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | byte `i`-esimo di (u)int256 `x`, da sinistra | | +| 1B | SHL | 3 | `shift, val` | `val << shift` | | scorrimento a sinistra | | +| 1C | SHR | 3 | `shift, val` | `val >> shift` | | scorrimento logico a destra | | +| 1D | SAR | 3 | `shift, val` | `val >> shift` | | scorrimento aritmetico a destra | | +| 1E-1F | _non valido_ | | | | | | | +| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | | +| 21-2F | _non valido_ | | | | | | | +| 30 | ADDRESS | 2 | `.` | `address(this)` | | indirizzo del contratto in esecuzione | | +| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | saldo, in wei | | +| 32 | ORIGIN | 2 | `.` | `tx.origin` | | indirizzo che ha originato la tx | | +| 33 | CALLER | 2 | `.` | `msg.sender` | | indirizzo del mittente del msg | | +| 34 | CALLVALUE | 2 | `.` | `msg.value` | | valore msg, in wei | | +| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | legge la parola dai dati del msg all'indice `idx` | | +| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | lunghezza dei dati del msg, in byte | | +| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copia i dati del msg | | +| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | lunghezza del codice del contratto in esecuzione, in byte | | +| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copia il bytecode del contratto in esecuzione | +| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | prezzo del gas della tx, in wei per unità di gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | | +| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | dimensione del codice all'indirizzo addr, in byte | | +| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copia il codice da `addr` | | +| 3D | RETURNDATASIZE | 2 | `.` | `size` | | dimensione dei dati restituiti dall'ultima chiamata esterna, in byte | | +| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copia i dati restituiti dall'ultima chiamata esterna | | +| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 | | +| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | | +| 41 | COINBASE | 2 | `.` | `block.coinbase` | | indirizzo del propositore del blocco corrente | | +| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | indicatore ora del blocco corrente | | +| 43 | NUMBER | 2 | `.` | `block.number` | | numero del blocco corrente | | +| 44 | PREVRANDAO | 2 | `.` | `beacon di casualità` | | beacon di casualità | | +| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | limite del gas del blocco corrente | | +| 46 | CHAINID | 2 | `.` | `chain_id` | | spinge l'attuale [id della catena](https://eips.ethereum.org/EIPS/eip-155) nello stack | | +| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | saldo del contratto in esecuzione, in wei | | +| 48 | BASEFEE | 2 | `.` | `block.basefee` | | commissione di base del blocco corrente | | +| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | | +| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | commissione di base del blob del blocco corrente ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | | +| 4B-4F | _non valido_ | | | | | | | +| 50 | POP | 2 | `_anon` | `.` | | rimuove l'elemento dalla cima dello stack e lo scarta | | +| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | legge la parola dalla memoria all'offset `ost` | | +| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | scrive una parola in memoria | | +| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | scrive un singolo byte in memoria | | +| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | legge la parola dall'archiviazione | | +| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | scrive la parola nell'archiviazione | | +| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` indica che `pc` è assegnato solo se `dst` è una jumpdest valida | | +| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1` | | +| 58 | PC | 2 | `.` | `$pc` | | contatore di programma | | +| 59 | MSIZE | 2 | `.` | `len(mem)` | | dimensione della memoria nel contesto di esecuzione corrente, in byte | | +| 5A | GAS | 2 | `.` | `gasRemaining` | | | | +| 5B | JUMPDEST | 1 | | | segna una destinazione di salto valida | una destinazione di salto valida, ad esempio una destinazione di salto non all'interno dei dati push | | +| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | legge la parola dall'archiviazione transitoria ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | scrive la parola nell'archiviazione transitoria ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copia la memoria da un'area a un'altra ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | | +| 5F | PUSH0 | 2 | `.` | `uint8` | | spinge il valore costante 0 allo stack | | +| 60 | PUSH1 | 3 | `.` | `uint8` | | spinge un valore di 1 byte nello stack | | +| 61 | PUSH2 | 3 | `.` | `uint16` | | spinge un valore di 2 byte nello stack | | +| 62 | PUSH3 | 3 | `.` | `uint24` | | spinge un valore di 3 byte nello stack | | +| 63 | PUSH4 | 3 | `.` | `uint32` | | spinge un valore di 4 byte nello stack | | +| 64 | PUSH5 | 3 | `.` | `uint40` | | spinge un valore di 5 byte nello stack | | +| 65 | PUSH6 | 3 | `.` | `uint48` | | spinge un valore di 6 byte nello stack | | +| 66 | PUSH7 | 3 | `.` | `uint56` | | spinge un valore di 7 byte nello stack | | +| 67 | PUSH8 | 3 | `.` | `uint64` | | spinge un valore di 8 byte nello stack | | +| 68 | PUSH9 | 3 | `.` | `uint72` | | spinge un valore di 9 byte nello stack | | +| 69 | PUSH10 | 3 | `.` | `uint80` | | spinge un valore di 10 byte nello stack | | +| 6A | PUSH11 | 3 | `.` | `uint88` | | spinge un valore di 11 byte nello stack | | +| 6B | PUSH12 | 3 | `.` | `uint96` | | spinge un valore di 12 byte nello stack | | +| 6C | PUSH13 | 3 | `.` | `uint104` | | spinge un valore di 13 byte nello stack | | +| 6D | PUSH14 | 3 | `.` | `uint112` | | spinge un valore di 14 byte nello stack | | +| 6E | PUSH15 | 3 | `.` | `uint120` | | spinge un valore di 15 byte nello stack | | +| 6F | PUSH16 | 3 | `.` | `uint128` | | spinge un valore di 16 byte nello stack | | +| 70 | PUSH17 | 3 | `.` | `uint136` | | spinge un valore di 17 byte nello stack | | +| 71 | PUSH18 | 3 | `.` | `uint144` | | spinge un valore di 18 byte nello stack | | +| 72 | PUSH19 | 3 | `.` | `uint152` | | spinge un valore di 19 byte nello stack | | +| 73 | PUSH20 | 3 | `.` | `uint160` | | spinge un valore di 20 byte nello stack | | +| 74 | PUSH21 | 3 | `.` | `uint168` | | spinge un valore di 21 byte nello stack | | +| 75 | PUSH22 | 3 | `.` | `uint176` | | spinge un valore di 22 byte nello stack | | +| 76 | PUSH23 | 3 | `.` | `uint184` | | spinge un valore di 23 byte nello stack | | +| 77 | PUSH24 | 3 | `.` | `uint192` | | spinge un valore di 24 byte nello stack | | +| 78 | PUSH25 | 3 | `.` | `uint200` | | spinge un valore di 25 byte nello stack | | +| 79 | PUSH26 | 3 | `.` | `uint208` | | spinge un valore di 26 byte nello stack | | +| 7A | PUSH27 | 3 | `.` | `uint216` | | spinge un valore di 27 byte nello stack | | +| 7B | PUSH28 | 3 | `.` | `uint224` | | spinge un valore di 28 byte nello stack | | +| 7C | PUSH29 | 3 | `.` | `uint232` | | spinge un valore di 29 byte nello stack | | +| 7D | PUSH30 | 3 | `.` | `uint240` | | spinge un valore di 30 byte nello stack | | +| 7E | PUSH31 | 3 | `.` | `uint248` | | spinge un valore di 31 byte nello stack | | +| 7F | PUSH32 | 3 | `.` | `uint256` | | spinge un valore di 32 byte nello stack | | +| 80 | DUP1 | 3 | `a` | `a, a` | | clona il 1° valore sullo stack | | +| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clona il 2° valore sullo stack | | +| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clona il 3° valore sullo stack | | +| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clona il 4° valore sullo stack | | +| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clona il 5° valore sullo stack | | +| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clona il 6° valore sullo stack | | +| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clona il 7° valore sullo stack | | +| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clona l'8° valore sullo stack | | +| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clona il 9° valore sullo stack | | +| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clona il 10° valore sullo stack | | +| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clona l'11° valore sullo stack | | +| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clona il 12° valore sullo stack | | +| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clona il 13° valore sullo stack | | +| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clona il 14° valore sullo stack | | +| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clona il 15° valore sullo stack | | +| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clona il 16° valore sullo stack | | +| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | | +| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | | +| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | | +| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | | +| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | | +| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | | +| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | | +| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | | +| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | | +| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | | +| A5-EF | _non valido_ | | | | | | | +| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | | +| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `fatto` | mem[retOst:retOst+retLen-1] := returndata | | | +| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `fatto` | mem[retOst:retOst+retLen-1] = returndata | uguale a DELEGATECALL, ma non propaga il msg.sender e il msg.value originali | | +| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | restituisce mem[ost:ost+len-1] | | +| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `fatto` | mem[retOst:retOst+retLen-1] := returndata | | | +| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | | +| F6-F9 | _non valido_ | | | | | | | +| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `fatto` | mem[retOst:retOst+retLen-1] := returndata | | | +| FB-FC | _non valido_ | | | | | | | +| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | ripristina(mem[ost:ost+len-1]) | | +| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | opcode non valido designato - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | | +| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | invia tutti gli ETH ad `addr`; se eseguito nella stessa transazione in cui è stato creato un contratto, distrugge il contratto | | diff --git a/public/content/translations/it/developers/docs/networking-layer/index.md b/public/content/translations/it/developers/docs/networking-layer/index.md index 4e279bab3d5..76e3336caa7 100644 --- a/public/content/translations/it/developers/docs/networking-layer/index.md +++ b/public/content/translations/it/developers/docs/networking-layer/index.md @@ -13,9 +13,9 @@ I client d'esecuzione compiono gossip sulle transazioni sulla rete tra pari del ## Prerequisiti {#prerequisites} -Per comprendere questa pagina è utile avere alcune nozioni di [nodi e client](/developers/docs/nodes-and-clients/) di Ethereum. +Per comprendere questa pagina è utile avere alcune nozioni sui [nodi e client](/developers/docs/nodes-and-clients/) di Ethereum. -## Il livello d'esecuzione {#execution-layer} +## Il livello di esecuzione {#execution-layer} I protocolli di rete del livello d'esecuzione sono divisi in due stack: @@ -27,33 +27,33 @@ Entrambi gli stack operano in parallelo. Lo stack di scoperta alimenta la nuova ### Scoperta {#discovery} -La scoperta è il processo con cui si trovano altri nodi nella rete. Questo processo è avviato usando una piccola serie di nodi d'avvio (nodi i cui indirizzi sono [codificati in modo fisso (hardcoded)](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) nel client, così che siano immediatamente trovabili e connettano il client ai peer). Questi nodi di avvio esistono solo per introdurre un nuovo nodo a una serie di peer, questo è il loro solo obiettivo, non partecipano alle normali attività del client, come la sincronizzazione della catena, e sono usati solo la primissima volta in cui il client è avviato. +La scoperta è il processo con cui si trovano altri nodi nella rete. Questo processo è avviato tramite un piccolo insieme di bootnode (nodi i cui indirizzi sono [hardcoded](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) nel client, in modo che possano essere trovati immediatamente e connettere il client ai peer). Questi nodi di avvio esistono solo per introdurre un nuovo nodo a una serie di peer, questo è il loro solo obiettivo, non partecipano alle normali attività del client, come la sincronizzazione della catena, e sono usati solo la primissima volta in cui il client è avviato. -Il protocollo usato per le interazioni tra nodo e nodo d'avvio è una forma modificata di [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f), che usa una [tabella di hash distribuita](https://en.wikipedia.org/wiki/Distributed_hash_table) per condividere elenchi di nodi. Ogni nodo ha una versione di questa tabella, contenente le informazioni necessarie per connettersi ai propri peer più vicini. Questa “vicinanza” non è geografica: la distanza è definita dalla somiglianza dell'ID del nodo. Come funzionalità di sicurezza, ogni tabella del nodo è aggiornata regolarmente. Ad esempio, nel [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), i nodi del protocollo di scoperta sono anche capaci di inviare “annunci” che indicano i protocolli secondari supportati dal client, consentendo ai peer di negoziare i protocolli che usano entrambi per comunicare. +Il protocollo utilizzato per le interazioni nodo-bootnode è una forma modificata di [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) che utilizza una [tabella di hash distribuita](https://en.wikipedia.org/wiki/Distributed_hash_table) per condividere elenchi di nodi. Ogni nodo ha una versione di questa tabella, contenente le informazioni necessarie per connettersi ai propri peer più vicini. Questa “vicinanza” non è geografica: la distanza è definita dalla somiglianza dell'ID del nodo. Come funzionalità di sicurezza, ogni tabella del nodo è aggiornata regolarmente. Ad esempio, nel protocollo di scoperta [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5), i nodi sono anche in grado di inviare 'annunci' che mostrano i sottoprocolli supportati dal client, consentendo ai peer di negoziare i protocolli che entrambi possono utilizzare per comunicare. -La scoperta inizia con una partita di PING-PONG. Un PING-PONG di successo "lega" il nuovo nodo a un nodo d'avvio. Il messaggio iniziale che avvisa un nodo d'avvio dell'esistenza di un nuovo nodo che sta accedendo alla rete è un `PING`. Questo `PING` include le informazioni in hash sul nuovo nodo, il nodo d'avvio e una marca temporale di scadenza. Il nodo d'avvio riceve il PING e restituisce un `PONG` contenente l'hash del `PING`. Se gli hash del `PING` e del `PONG` corrispondono, allora la connessione tra il nuovo nodo e il nodo d'avvio è avvenuta e i due sono "legati". +La scoperta inizia con una partita di PING-PONG. Un PING-PONG di successo "lega" il nuovo nodo a un nodo d'avvio. Il messaggio iniziale che avvisa un bootnode dell'esistenza di un nuovo nodo che entra nella rete è un `PING`. Questo `PING` include informazioni con hash sul nuovo nodo, il bootnode e una marca temporale di scadenza. Il bootnode riceve il `PING` e restituisce un `PONG` contenente l'hash del `PING`. Se gli hash di `PING` e `PONG` corrispondono, la connessione tra il nuovo nodo e il bootnode viene verificata e si dice che sono "legati". -Una volta legato, il nuovo nodo può inviare una richiesta `FIND-NEIGHBOURS` al nodo d'avvio. I dati restituiti dal nodo d'avvio includono un elenco di peer a cui il nuovo nodo può connettersi. Se i nodi non sono legati, la richiesta `FIND-NEIGHBOURS` non andrà a buon fine, quindi il nuovo nodo non potrà accedere alla rete. +Una volta legato, il nuovo nodo può inviare una richiesta `FIND-NEIGHBOURS` al bootnode. I dati restituiti dal nodo d'avvio includono un elenco di peer a cui il nuovo nodo può connettersi. Se i nodi non sono legati, la richiesta `FIND-NEIGHBOURS` non andrà a buon fine, quindi il nuovo nodo non potrà entrare nella rete. Una volta che il nodo riceve un elenco di vicini dal nodo d'avvio, inizia con ognuno di essi, uno scambio di PING-PONG. I PING-PONG riusciti legano il nuovo nodo ai suoi vicini, consentendo lo scambio di messaggi. ``` -start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours +avvia client --> connettiti al bootnode --> legati al bootnode --> trova vicini --> legati ai vicini ``` -I client di esecuzione stanno attualmente utilizzando il protocollo di ricerca [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) e c'è uno sforzo attivo per migrare al protocollo [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5). +I client di esecuzione stanno attualmente utilizzando il protocollo di scoperta [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) e c'è un impegno attivo per migrare al protocollo [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5). -#### ENR: Ethereum Node Records {#enr} +#### ENR: Ethereum Node Record {#enr} -L’[Ethereum Node Records (ENR)](/developers/docs/networking-layer/network-addresses/) è un oggetto contenente tre elementi fondamentali: una firma (hash dei contenuti del registro creato secondo qualche schema d'identità acconsentito), una sequenza numerica che monitora le modifiche al registro e un elenco arbitrario di coppie chiave-valore. Questo è un formato a prova di futuro che consente uno scambio più facile di informazioni identificative tra nuovi peer ed è preferibile rispetto al formato dell'[indirizzo di rete](/developers/docs/networking-layer/network-addresses) per i nodi di Ethereum. +L'[Ethereum Node Record (ENR)](/developers/docs/networking-layer/network-addresses/) è un oggetto che contiene tre elementi di base: una firma (hash del contenuto del record creato secondo uno schema di identità concordato), un numero di sequenza che tiene traccia delle modifiche al record e un elenco arbitrario di coppie chiave:valore. Questo è un formato a prova di futuro che consente uno scambio più semplice di informazioni identificative tra nuovi peer ed è il formato di [indirizzo di rete](/developers/docs/networking-layer/network-addresses) preferito per i nodi di Ethereum. -#### Perché la scoperta è basata su UDP? {#why-udp} +#### Perché la scoperta è basata su UDP? Perché UDP? {#why-udp} UDP non supporta le funzioni di controllo degli errori, reinvio di pacchetti non giunti a destinazione o apertura e chiusura dinamica delle connessioni, al contrario si limita a mandare un flusso continuo di informazioni a un destinatario, indipendentemente dal fatto che queste siano state correttamente ricevute. Questa funzionalità minima si traduce anche in overhead minimi, che rendono molto veloce questo tipo di connessione. Per la scoperta, in cui un nodo vuole solo comunicare la propria presenza per poter poi stabilire una connessione formale con un peer, UDP è sufficiente. Per il resto dello stack di rete, invece, UDP non è adatto. Lo scambio informativo tra nodi è abbastanza complesso e necessita dunque di un protocollo più completo di funzionalità, che possa supportare il reinvio, la verifica degli errori, etc. L’overhead aggiuntivo associato a TCP vale le maggiori funzionalità. Dunque, la maggioranza dello stack P2P opera su TCP. ### DevP2P {#devp2p} -DevP2P è esso stesso un intero stack di protocolli che Ethereum implementa per stabilire e mantenere la rete tra peer-to-peer. Dopo che i nuovi nodi accedono alla rete, le loro interazioni sono governate dai protocolli nello stack [DevP2P](https://github.com/ethereum/devp2p). Questi si basano tutti su TCP e includono il protocollo di trasporto RLPx, il protocollo via cavo e diversi protocolli secondari. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) è il protocollo che governa iniziazione, autenticazione e manutenzione delle sessioni tra nodi. RLPx codifica i messaggi usando il RLP (Recursive Length Prefix), un metodo molto efficiente in termini di spazio che codifica i dati in una struttura minimale per l'invio tra nodi. +DevP2P è esso stesso un intero stack di protocolli che Ethereum implementa per stabilire e mantenere la rete tra peer-to-peer. Dopo che i nuovi nodi entrano nella rete, le loro interazioni sono governate dai protocolli nello stack [DevP2P](https://github.com/ethereum/devp2p). Questi si basano tutti su TCP e includono il protocollo di trasporto RLPx, il protocollo via cavo e diversi protocolli secondari. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) è il protocollo che governa l'avvio, l'autenticazione e il mantenimento delle sessioni tra i nodi. RLPx codifica i messaggi usando il RLP (Recursive Length Prefix), un metodo molto efficiente in termini di spazio che codifica i dati in una struttura minimale per l'invio tra nodi. Una sessione di RLPx tra due nodi inizia con un "handshaking" crittografico iniziale, in cui il nodo invia un messaggio d'autenticazione, poi verificato dal peer. Se la verifica va a buon fine, il peer genera un messaggio di riconoscimento dell'autenticazione da restituire al nodo iniziatore. Si tratta di un processo di scambio di chiavi che consente ai nodi di comunicare privatamente e in sicurezza. Un "handshaking" crittografico andato a buon fine attiva poi entrambi i nodi spingendoli a inviare un messaggio "hello" all'altro "on the wire". Il protocollo via cavo è avviato da uno scambio di messaggi di saluto andato a buon fine. @@ -69,23 +69,23 @@ Queste sono le informazioni necessarie affinché l'interazione vada a buon fine, Insieme ai messaggi di saluto, il protocollo via cavo può anche inviare un messaggio "disconnect" che avvisa un peer che la connessione sarà chiusa. Il protocollo via cavo prevede anche messaggi PING e PONG, inviati periodicamente per mantenere aperta una sessione. Gli scambi dei protocolli RLPx e via cavo stabiliscono dunque le fondamenta della comunicazione tra i nodi, fornendo l'impalcatura per le informazioni utili da scambiare secondo un protocollo secondario specifico. -### Protocolli secondari {#sub-protocols} +### Sottoprotocolli {#sub-protocols} -#### Protocollo via cavo {#wire-protocol} +#### Protocollo wire {#wire-protocol} -Una volta che i pari sono connessi e che una sessione RLPx è stata avviata, il protocollo via cavo definisce come comunicano i pari. Inizialmente, il protocollo via cavo definiva tre mansioni principali: la sincronizzazione della catena, la propagazione del blocco e lo scambio di transazioni. Tuttavia, una volta che Ethereum è passato al proof-of-stake, la propagazione dei blocchi e la sincronizzazione della catena sono divenuti parte del livello di consenso. Lo scambio di transazioni è ancora di competenza dei client d'esecuzione. Lo scambio di transazioni si riferisce allo scambio di transazioni in sospeso tra nodi in modo che i costruttori di blocchi possano selezionarne alcune per includerle nel blocco successivo. Le informazioni dettagliate su queste attività sono disponibili [qui](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). I client che supportano questi protocolli secondari, li espongono tramite [JSON-RPC](/developers/docs/apis/json-rpc/). +Una volta che i pari sono connessi e che una sessione RLPx è stata avviata, il protocollo via cavo definisce come comunicano i pari. Inizialmente, il protocollo via cavo definiva tre mansioni principali: la sincronizzazione della catena, la propagazione del blocco e lo scambio di transazioni. Tuttavia, una volta che Ethereum è passato al proof-of-stake, la propagazione dei blocchi e la sincronizzazione della catena sono divenuti parte del livello di consenso. Lo scambio di transazioni è ancora di competenza dei client d'esecuzione. Lo scambio di transazioni si riferisce allo scambio di transazioni in sospeso tra nodi in modo che i costruttori di blocchi possano selezionarne alcune per includerle nel blocco successivo. Informazioni dettagliate su queste attività sono disponibili [qui](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). I client che supportano questi sottoprotocolli li espongono tramite [JSON-RPC](/developers/docs/apis/json-rpc/). -#### les (light ethereum subprotocol) {#les} +#### les (sottoprotocollo leggero di Ethereum) {#les} Si tratta di un protocollo minimale per sincronizzare i client leggeri. Tradizionalmente, questo protocollo è stato raramente usato perché i nodi completi devono servire i dati ai client leggeri senza esser incentivati. Il comportamento predefinito dei client d'esecuzione prevede di non servire i dati al client leggero tramite les. Maggiori informazioni sono disponibili nelle [specifiche](https://github.com/ethereum/devp2p/blob/master/caps/les.md) di les. #### Snap {#snap} -Il [protocollo snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) è un'estensione ottica che consente ai pari di scambiare istantanee degli stati recenti, consentendo ai pari di verificare i dati del conto e dell'archiviazione senza dover scaricare nodi intermedi dell'albero di Merkle. +Il [protocollo snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) è un'estensione opzionale che consente ai peer di scambiare istantanee di stati recenti, permettendo loro di verificare i dati di account e archiviazione senza dover scaricare i nodi intermedi dell'albero di Merkle. -#### Wit (witness protocol) {#wit} +#### Wit (protocollo testimone) {#wit} -Il [witness protocol](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) è un'estensione facoltativa che consente lo scambio di testimoni di stato tra peer, aiutando a sincronizzare i client in cima alla catena. +Il [protocollo witness](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) è un'estensione opzionale che consente lo scambio di testimoni di stato (state witnesses) tra peer, aiutando a sincronizzare i client con la punta della catena. #### Whisper {#whisper} @@ -97,11 +97,11 @@ I client di consenso partecipano a una rete peer-to-peer distinta, con specifich ### Scoperta {#consensus-discovery} -Analogamente ai client d'esecuzione, i client di consenso usano [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) su UDP per trovare i peer. L'implementazione del livello di consenso di discv5 differisce da quella dei client d'esecuzione solo perché include un adattatore che connette discv5 a uno stack [libP2P](https://libp2p.io/), deprecando DevP2P. Le sessioni di RLPx del livello d'esecuzione sono deprecate in favore dell’"handshaking" protetto del canale Noise di libP2P. +Similmente ai client di esecuzione, i client di consenso usano [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) su UDP per trovare i peer. L'implementazione di discv5 del livello di consenso si differenzia da quella dei client di esecuzione solo perché include un adattatore che connette discv5 a uno stack [libP2P](https://libp2p.io/), deprecando DevP2P. Le sessioni di RLPx del livello d'esecuzione sono deprecate in favore dell’"handshaking" protetto del canale Noise di libP2P. ### ENR {#consensus-enr} -L'ENR dei nodi del consenso include la chiave pubblica del nodo, l'indirizzo IP, le porte UDP e TCP e due campi specifici per il consenso: il campo di bit della subnet d'attestazione e la chiave `eth2`. Il primo rende più semplice ai nodi trovare dei peer, partecipando a reti secondarie di gossip d'attestazione specifiche. La chiave `eth2` contiene le informazioni su quale versione della biforcazione di Ethereum il nodo sta usando, garantendo che i peer si connettano all'Ethereum giusto. +L'ENR per i nodi di consenso include la chiave pubblica del nodo, l'indirizzo IP, le porte UDP e TCP e due campi specifici del consenso: il campo di bit della sottorete di attestazione e la chiave `eth2`. Il primo rende più semplice ai nodi trovare dei peer, partecipando a reti secondarie di gossip d'attestazione specifiche. La chiave `eth2` contiene informazioni su quale versione della biforcazione di Ethereum il nodo sta usando, garantendo che i peer si connettano all'Ethereum giusto. ### libP2P {#libp2p} @@ -109,7 +109,7 @@ Lo stack libP2P supporta tutte le comunicazioni dopo la scoperta. I client posso ### Gossip {#gossip} -Il dominio di gossip include tutte le informazioni che devono essere diffuse rapidamente tramite la rete. Questo include i blocchi Beacon, le prove, le attestazioni, le uscite e i tagli (slashing). La trasmissione avviene tramite libP2P gossipsub v1 e si affida a vari metadati memorizzati localmente in ogni nodo, tra cui la dimensione massima dei carichi utili di gossip da ricevere e trasmettere. Le informazioni dettagliate sul dominio del gossip sono disponibili [qui](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). +Il dominio di gossip include tutte le informazioni che devono essere diffuse rapidamente tramite la rete. Questo include i blocchi Beacon, le prove, le attestazioni, le uscite e i tagli (slashing). La trasmissione avviene tramite libP2P gossipsub v1 e si affida a vari metadati memorizzati localmente in ogni nodo, tra cui la dimensione massima dei carichi utili di gossip da ricevere e trasmettere. Informazioni dettagliate sul dominio gossip sono disponibili [qui](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). ### Richiesta-risposta {#request-response} @@ -119,25 +119,25 @@ Il dominio di richiesta-risposta contiene i protocolli per i client che richiedo SSZ sta per simple serialization (serializzazione semplice). Usa offset fissi che semplificano la decodifica di singole parti di un messaggio codificato senza dover decodificare l'intera struttura, funzione molto utile per il client di consenso, che può quindi estrarre efficientemente specifiche informazioni dai messaggi codificati. È anche progettato specificamente per integrarsi ai protocolli di Merkle, con i relativi guadagni in termini di efficienza per la Merkle-zzazione. Poiché tutti gli hash nel livello di consenso sono radici di Merkle, si ottiene un miglioramento complessivo significativo. SSZ garantisce anche rappresentazioni univoche dei valori. -## Connettere i client d'esecuzione e di consenso {#connecting-clients} +## Connessione dei client di esecuzione e di consenso {#connecting-clients} -I client del consenso e d'esecuzione, operano in parallelo. Devono esser connessi, così che il client del consenso possa fornire istruzioni al client d'esecuzione e che il client d'esecuzione possa passare pacchetti di transazioni al client del consenso per includerli nei blocchi della Beacon. La comunicazione tra i due client è ottenibile usando una connessione RPC locale. Un'API nota come [“Engine-API”](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) definisce le istruzioni inviate tra i due client. Poiché entrambi i client risiedono dietro un'identità di rete singola, condividono un ENR (Registro del Nodo di Ethereum), contenente una chiave separata per ogni client (chiave eth1 e chiave eth2). +I client del consenso e d'esecuzione, operano in parallelo. Devono esser connessi, così che il client del consenso possa fornire istruzioni al client d'esecuzione e che il client d'esecuzione possa passare pacchetti di transazioni al client del consenso per includerli nei blocchi della Beacon. La comunicazione tra i due client è ottenibile usando una connessione RPC locale. Un'API, nota come ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md), definisce le istruzioni inviate tra i due client. Poiché entrambi i client risiedono dietro un'identità di rete singola, condividono un ENR (Registro del Nodo di Ethereum), contenente una chiave separata per ogni client (chiave eth1 e chiave eth2). Un sommario del flusso di controllo è mostrato di seguito, con indicazione tra parentesi dello stack di rete rilevante. -### Quando il client del consenso non è un produttore di blocchi: {#when-consensus-client-is-not-block-producer} +### Quando il client di consenso non è un produttore di blocchi: {#when-consensus-client-is-not-block-producer} - Il client di consenso riceve un blocco tramite il protocollo di gossip dei blocchi (consenso p2p) -- Il client di consenso convalida preventivamente il blocco, ovvero si assicura che provenga da un mittente valido con i metadati corretti +- Il client di consenso pre-valida il blocco, ossia si assicura che sia arrivato da un mittente valido con metadati corretti - Le transazioni nel blocco sono inviate al livello d'esecuzione come un payload d'esecuzione (connessione RPC locale) -- Il livello d'esecuzione esegue le transazioni e convalida lo stato nell'intestazione del blocco (ovvero verifica la corrispondenza degli hash) +- Il livello di esecuzione esegue le transazioni e convalida lo stato nell'intestazione del blocco (ossia, verifica che gli hash corrispondano) - Il livello d'esecuzione ripassa i dati di convalida al livello di consenso, blocco ora considerato da convalidare (connessione RPC locale) - Il livello di consenso aggiunge il blocco alla testa della propria blockchain e lo attesta, trasmettendo l'attestazione via rete (consenso p2p) -### Quando il client del consenso è un produttore di blocchi: {#when-consensus-client-is-block-producer} +### Quando il client di consenso è un produttore di blocchi: {#when-consensus-client-is-block-producer} - Il client di consenso riceve notifica che è il prossimo produttore di blocchi (consenso p2p) -- Il livello di consenso chiama il metodo `create block` nel client d'esecuzione (RPC locale) +- Il livello di consenso chiama il metodo `create block` nel client di esecuzione (RPC locale) - Il livello d'esecuzione accede al mempool delle transazioni, popolato dal protocollo di gossip della transazione (esecuzione p2p) - Il client d'esecuzione impacchetta le transazioni in un blocco, esegue le transazioni e genera l'hash di un blocco - Il client del consenso prende le transazioni e l'hash del blocco dal client d'esecuzione e li aggiunge al blocco della beacon (RPC locale) @@ -146,10 +146,18 @@ Un sommario del flusso di controllo è mostrato di seguito, con indicazione tra Una volta che il blocco è stato attestato da sufficienti validatori, è aggiunto alla testa della catena, giustificato e, infine, finalizzato. -![](cons_client_net_layer.png) ![](exe_client_net_layer.png) +![](cons_client_net_layer.png) +![](exe_client_net_layer.png) -Schematica del livello di rete per i client del consenso e d'esecuzione, da [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) +Schema del livello di rete per i client di consenso e di esecuzione, da [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) -## Letture consigliate {#further-reading} +## Ulteriori letture {#further-reading} -[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [Specifiche di rete del livello di consenso](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [da kademlia a discv5](https://vac.dev/kademlia-to-discv5) [documentazione di kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [intro al p2p di Ethereum](https://p2p.paris/en/talks/intro-ethereum-networking/) [rapporto eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [fusione e video dei dettagli del client di eth2](https://www.youtube.com/watch?v=zNIrIninMgg) +[DevP2P](https://github.com/ethereum/devp2p) +[LibP2p](https://github.com/libp2p/specs) +[Specifiche di rete del livello di consenso](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) +[Da kademlia a discv5](https://vac.dev/kademlia-to-discv5) +[Paper di Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) +[Introduzione al p2p di Ethereum](https://p2p.paris/en/talks/intro-ethereum-networking/) +[Relazione tra eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) +[Video sui dettagli del client di The Merge ed eth2](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/it/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/it/developers/docs/networking-layer/network-addresses/index.md index 73e72ca3ecf..4bf826b6c0b 100644 --- a/public/content/translations/it/developers/docs/networking-layer/network-addresses/index.md +++ b/public/content/translations/it/developers/docs/networking-layer/network-addresses/index.md @@ -9,7 +9,7 @@ Per connettersi ai peer i nodi di Ethereum devono identificarsi con alcune infor ## Prerequisiti {#prerequisites} -Per comprendere questa pagina è necessaria qualche nozione del [livello di rete di Ethereum](/developers/docs/networking-layer/). +Per comprendere questa pagina è necessaria qualche nozione del [livello di rete](/developers/docs/networking-layer/) di Ethereum. ## Multiaddr {#multiaddr} @@ -25,15 +25,15 @@ Per un nodo di Ethereum, il multiaddr contiene l'ID del nodo (un hash della sua L’enode è un modo per identificare un nodo di Ethereum usando un formato come indirizzo URL. L'ID del nodo esadecimale è codificato nella porzione del nome utente dell'URL, separato dall'host con il simbolo @. Il nome dell'host può essere dato solo come indirizzo IP; non sono consentiti i nomi DNS. La porta nella sezione del nome del host è la porta d'ascolto TCP. Se le porte TCP e UDP (scoperta) sono differenti, la porta UDP è specificata come parametro di query "discport". -Nel seguente esempio, l'URL del nodo descrive un nodo con indirizzo IP `10.3.58.6`, porta TCP `30303` e porta di scoperta UDP `30301`. +Nell'esempio seguente, l'URL del nodo descrive un nodo con indirizzo IP `10.3.58.6`, porta TCP `30303` e porta di scoperta UDP `30301`. `enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` ## Ethereum Node Records (ENR) {#enr} -Ethereum Node Records (ENR) è un formato standardizzato per gli indirizzi di rete su Ethereum. Sostituisce i multiaddr e gli enode. Sono specialmente utili perché consentono un maggiore scambio di informazioni tra nodi. L'ENR contiene una firma, un numero di sequenza e campi che dettagliano lo schema d'identità usato per generare e convalidare le firme. L'ENR può anche essere popolato da dati arbitrari organizzati in coppie chiave-valore. Queste coppie chiave-valore contengono l'indirizzo IP del nodo e le informazioni sui sotto-protocolli che il nodo può usare. I client di consenso usano una [struttura ENR specifica](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) per identificare i nodi di avvio e prevedono anche un campo `eth2` contenente le informazioni sulla biforcazione corrente di Ethereum e la subnet di gossip dell'attestazione (questa connette il nodo a una serie particolare di coppie le cui attestazioni sono aggregate tra loro). +Ethereum Node Records (ENR) è un formato standardizzato per gli indirizzi di rete su Ethereum. Sostituisce i multiaddr e gli enode. Sono specialmente utili perché consentono un maggiore scambio di informazioni tra nodi. L'ENR contiene una firma, un numero di sequenza e campi che dettagliano lo schema d'identità usato per generare e convalidare le firme. L'ENR può anche essere popolato da dati arbitrari organizzati in coppie chiave-valore. Queste coppie chiave-valore contengono l'indirizzo IP del nodo e le informazioni sui sotto-protocolli che il nodo può usare. I client di consenso usano una [struttura ENR specifica](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) per identificare i nodi di avvio e prevedono anche un campo `eth2` contenente le informazioni sulla biforcazione corrente di Ethereum e la subnet di gossip dell'attestazione (questa connette il nodo a una serie particolare di peer le cui attestazioni sono aggregate tra loro). -## Letture consigliate {#further-reading} +## Ulteriori letture {#further-reading} -- [EIP-778: i registri dei nodi di Ethereum (Ethereum Node Records, ENR)](https://eips.ethereum.org/EIPS/eip-778) +- [EIP-778: Ethereum Node Records (ENR)](https://eips.ethereum.org/EIPS/eip-778) - [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) 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..11b354b9698 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 @@ -10,7 +10,7 @@ Per ovviare al problema dell'archiviazione su disco, sono stati sviluppati nodi La Rete Portal è un nuovo progetto di rete per Ethereum che mira a risolvere il problema della disponibilità dei dati per i nodi "leggeri" senza dover fare affidamento o sottoporre a ulteriori sforzi i nodi completi, condividendo i dati necessari in piccole porzioni attraverso la rete. -Maggiori informazioni su [nodi e client](/developers/docs/nodes-and-clients/) +Altro su [nodi e client](/developers/docs/nodes-and-clients/) ## Perché abbiamo bisogno della Rete Portal {#why-do-we-need-portal-network} @@ -18,17 +18,17 @@ I nodi di Ethereum memorizzano la propria copia completa o parziale della blockc Questa copia locale della blockchain e dei dati di stato e di ricezione associati occupa molto spazio sul disco rigido del nodo. Ad esempio, si consiglia un disco rigido da 2 TB per l'esecuzione di un nodo che utilizza [Geth](https://geth.ethereum.org) accoppiato a un client di consenso. Utilizzando la sincronizzazione snap, che memorizza solo i dati della catena da un insieme relativamente recente di blocchi, Geth occupa tipicamente circa 650 GB di spazio su disco, ma cresce di circa 14 GB a settimana (è possibile ridurre nuovamente il nodo a 650 GB periodicamente). -Ciò significa che la gestione dei nodi può essere costosa, perché una grande quantità di spazio su disco deve essere dedicata a Ethereum. Ci sono diverse soluzioni a questo problema nella tabella di marcia di Ethereum, tra cui la [scadenza dello storico](/roadmap/statelessness/#history-expiry), la [scadenza dello stato](/roadmap/statelessness/#state-expiry) e l'[assenza di stato](/roadmap/statelessness/). Tuttavia, è probabile che passino diversi anni prima che queste misure vengano implementate. Esistono anche [nodi leggeri](/developers/docs/nodes-and-clients/light-clients/) che non salvano la propria copia dei dati della catena, ma richiedono i dati di cui hanno bisogno ai nodi completi. Tuttavia, ciò significa che i nodi leggeri devono fidarsi del fatto che i nodi completi forniscano dati onesti e inoltre aumenta il carico di lavoro per i nodi completi, che devono fornire ai nodi leggeri i dati di cui hanno bisogno. +Ciò significa che la gestione dei nodi può essere costosa, perché una grande quantità di spazio su disco deve essere dedicata a Ethereum. Esistono diverse soluzioni a questo problema nella tabella di marcia di Ethereum, tra cui la [scadenza della cronologia](/roadmap/statelessness/#history-expiry), la [scadenza dello stato](/roadmap/statelessness/#state-expiry) e l'[assenza di stato](/roadmap/statelessness/). Tuttavia, è probabile che passino diversi anni prima che queste misure vengano implementate. Esistono anche [nodi leggeri](/developers/docs/nodes-and-clients/light-clients/) che non salvano la propria copia dei dati della catena, ma richiedono i dati di cui hanno bisogno ai nodi completi. Tuttavia, ciò significa che i nodi leggeri devono fidarsi del fatto che i nodi completi forniscano dati onesti e inoltre aumenta il carico di lavoro per i nodi completi, che devono fornire ai nodi leggeri i dati di cui hanno bisogno. La Rete Portal mira a fornire un modo alternativo per i nodi leggeri di ottenere i loro dati che non richieda il fare affidamento sui nodi completi o l'aumento significativo del carico di lavoro di questi ultimi. Il modo in cui ciò avverrà consiste nell'introdurre un nuovo modo per i nodi di Ethereum di condividere i dati attraverso la rete. ## Come funziona la Rete Portal? {#how-does-portal-network-work} -I nodi di Ethereum hanno protocolli rigorosi che definiscono come devono comunicare tra loro. I client di esecuzione comunicano utilizzando un insieme di sottoprotocolli noti come [DevP2P](/developers/docs/networking-layer/#devp2p), mentre i nodi di consenso utilizzano uno stack di sottoprotocolli differente chiamato [libP2P](/developers/docs/networking-layer/#libp2p). Questi definiscono i tipi di dati che possono essere trasferiti tra i nodi. +I nodi di Ethereum hanno protocolli rigorosi che definiscono come devono comunicare tra loro. I client di esecuzione comunicano utilizzando un insieme di sottoprotocolli noti come [DevP2P](/developers/docs/networking-layer/#devp2p), mentre i client di consenso utilizzano uno stack di sottoprotocolli differente chiamato [libP2P](/developers/docs/networking-layer/#libp2p). Questi definiscono i tipi di dati che possono essere trasferiti tra i nodi. -![devP2P and libP2P](portal-network-devp2p-libp2p.png) +![devP2P e libP2P](portal-network-devp2p-libp2p.png) -I nodi possono anche offrire dati specifici attraverso l'[API JSON-RPC](/developers/docs/apis/json-rpc/), che è la modalità utilizzata dalle applicazioni e dai portafogli per scambiare le informazioni con i nodi di Ethereum. Tuttavia, nessuno di questi protocolli è ideale per offrire dati ai client leggeri. +I nodi possono anche fornire dati specifici tramite l'[API JSON-RPC](/developers/docs/apis/json-rpc/), che è il modo in cui le app e i portafogli scambiano informazioni con i nodi di Ethereum. Tuttavia, nessuno di questi protocolli è ideale per offrire dati ai client leggeri. Attualmente i client leggeri non possono richiedere specifici pezzi di dati della catena tramite DevP2P o libP2p perché questi protocolli sono progettati solo per abilitare la sincronizzazione della catena, il gossip dei blocchi e le transazioni. I client leggeri non vogliono scaricare questa informazione perché questo impedirebbe loro di essere "leggeri". @@ -48,16 +48,16 @@ L'obiettivo è quello di consentire a una rete decentralizzata di client Portal - sincronizzare i dati recenti e storici della catena - recuperare i dati dello stato - trasmettere le transazioni -- eseguire le transazioni utilizzando l'[EVM](/developers/docs/evm/) +- eseguire transazioni usando l'[EVM](/developers/docs/evm/) I vantaggi di questa progettazione della rete sono: - Ridurre la dipendenza da fornitori centralizzati - Ridurre l'utilizzo della larghezza di banda di Internet - Sincronizzazione ridotta o nulla -- Accessibile a dispositivi con risorse limitate (\<1 GB di RAM, \<100 MB di spazio su disco, 1 CPU) +- Accessibile a dispositivi con risorse limitate (<1 GB di RAM, <100 MB di spazio su disco, 1 CPU) -Il diagramma seguente mostra le funzioni dei client esistenti che possono essere fornite dalla Rete Portal, consentendo agli utenti di accedere a tali funzioni su dispositivi con risorse molto limitate. +La tabella sottostante mostra le funzioni dei client esistenti che possono essere fornite dalla Rete Portal, consentendo agli utenti di accedere a tali funzioni su dispositivi con risorse molto limitate. ### Le Reti Portal @@ -69,21 +69,21 @@ Il diagramma seguente mostra le funzioni dei client esistenti che possono essere ## Diversità dei client per impostazione predefinita {#client-diversity-as-default} -Nella loro progettazione, gli sviluppatori della Rete Portal hanno deciso di creare anche tre diversi client della Rete Portal fin dal primo giorno. +Gli sviluppatori della Rete Portal hanno anche fatto la scelta progettuale di creare quattro client della Rete Portal separati fin dal primo giorno. I client della Rete Portal sono: - [Trin](https://github.com/ethereum/trin): scritto in Rust -- [Fluffy](https://nimbus.team/docs/fluffy.html): scritto in Nim +- [Fluffy](https://fluffy.guide): scritto in Nim - [Ultralight](https://github.com/ethereumjs/ultralight): scritto in Typescript -- [Shisui](https://github.com/optimism-java/shisui): scritto in Go +- [Shisui](https://github.com/zen-eth/shisui): scritto in Go La presenza di più implementazioni client indipendenti aumenta la resilienza e la decentralizzazione della rete Ethereum. 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). +- [La Rete Portal (Piper Merriam alla Devcon di Bogotà)](https://www.youtube.com/watch?v=0stc9jnQLXA). - [Discord della Rete Portal](https://discord.gg/CFFnmE7Hbs) - [Sito web della Rete Portal](https://www.ethportal.net/) From b939ccda9f4ae2f44e5db9a08026857b19d63808 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Fri, 13 Feb 2026 10:36:15 +0000 Subject: [PATCH 2/2] 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/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/intro-to-ethereum/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 +- .../it/roadmap/account-abstraction/index.md | 7 +- .../it/roadmap/beacon-chain/index.md | 4 +- .../it/roadmap/danksharding/index.md | 6 - .../it/roadmap/future-proofing/index.md | 2 +- .../translations/it/roadmap/merge/index.md | 12 +- .../it/roadmap/merge/issuance/index.md | 7 +- .../translations/it/roadmap/pbs/index.md | 3 +- .../translations/it/roadmap/scaling/index.md | 2 +- .../translations/it/roadmap/security/index.md | 4 +- .../it/roadmap/single-slot-finality/index.md | 4 +- .../it/roadmap/user-experience/index.md | 2 +- .../it/roadmap/verkle-trees/index.md | 2 - .../translations/it/social-networks/index.md | 14 +- .../translations/it/staking/dvt/index.md | 2 +- .../translations/it/staking/solo/index.md | 2 +- .../it/staking/withdrawals/index.md | 3 - public/content/translations/it/web3/index.md | 2 +- .../it/zero-knowledge-proofs/index.md | 30 ++-- 87 files changed, 262 insertions(+), 295 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/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/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/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/account-abstraction/index.md b/public/content/translations/it/roadmap/account-abstraction/index.md index 8695d3cd058..11786ab121e 100644 --- a/public/content/translations/it/roadmap/account-abstraction/index.md +++ b/public/content/translations/it/roadmap/account-abstraction/index.md @@ -1,6 +1,6 @@ --- title: Astrazione account -description: Una panoramica dei piani di Ethereum per rendere i conti degli utenti più semplici e sicuri +description: "Una panoramica dei piani di Ethereum per rendere i conti degli utenti più semplici e sicuri" lang: it summaryPoints: - L'astrazione del conto semplifica molto la creazione di portafogli di contratti intelligenti @@ -61,7 +61,6 @@ La gestione del gas, inoltre, è di molto migliorata con l'astrazione del conto. La gestione del gas è una delle frizioni principali per gli utenti di Ethereum, principalmente perché gli ETH sono la sola risorsa utilizzabile per pagare le transazioni. Immagina di avere un portafoglio con un saldo di USDC, ma nessun ETH. Non puoi spostare o scambiare quei token USDC, poiché non puoi pagare il gas. Non puoi nemmeno scambiare gli USDC per ETH, poiché anche questo costa del gas. Dovresti inviare altri ETH al tuo conto da una piattaforma di scambio o da un altro indirizzo per risolvere il problema. Con i portafogli di contratti intelligenti, invece, puoi semplicemente pagare il gas in USDC, liberando il tuo conto. Non devi più mantenere un saldo di ETH in tutti i tuoi conti. L'astrazione del conto, inoltre, consente agli sviluppatori di dapp di essere creativi con la gestione del gas. Ad esempio, potresti riuscire a iniziare a pagare una commissione fissa mensile alla tua DEX preferita, per delle transazioni illimitate. Le Dapp potrebbero offrire di pagare tutte le tue commissioni di gas per conto tuo, come ricompensa per aver utilizzato la loro piattaforma, o come offerta di inserimento. Per gli sviluppatori, sarebbe molto più facile innovare sul gas, quando i portafogli di contratti intelligenti sono supportati al livello del protocollo. - Le sessioni fidate, inoltre, sono potenzialmente trasformative per le esperienze degli utenti, specialmente per applicazioni come il gaming, in cui grandi numeri di piccole transazioni, potrebbero necessitare dell'approvazione in un breve tempo. Approvare individualmente ogni transazione spezzerebbe l'esperienza di gioco, ma l'approvazione permanente non è sicura. Il portafoglio di un contratto intelligente potrebbe approvare certe transazioni per un dato tempo, fino a un valore specifico o solo per certi indirizzi. @@ -77,7 +76,6 @@ I portafogli di contratti intelligenti, ad oggi, esistono, ma implementarli è i EIP-2771 introduce il concetto delle meta-transazioni, che consentono a terze parti di pagare i costi del gas degli utenti senza apportare modifiche al protocollo di Ethereum. L'idea è che le transazioni firmate da un utente sono inviate a un contratto `Corriere`. Il corriere è un'entità fidata che verifica che le transazioni siano valide, prima di inviarle a un ripetitore di gas. Ciò avviene all'esterno della catena, evitando il bisogno di pagare il gas. Il ripetitore di gas passa la transazione a un contratto `Destinatario`, pagando il gas necessario per rendere la transazione eseguibile su Ethereum. La transazione è eseguita se il `Corriere` è noto ed è ritenuto attendibile dal `Destinatario`. Questo modello semplifica, per gli sviluppatori, l'implementazione di transazioni a gas zero per gli utenti. - @@ -87,7 +85,6 @@ L'EIP-4337 è il primo passo verso il supporto dei portafogli di contratti intel Anche il funzionamento dei portafogli cambierà sotto EIP-4337. Invece di far reimplementare da ogni portafoglio una logica di sicurezza complessa ma comune, queste funzioni saranno affidate a un contratto del portafoglio globale, noto come "punto d'accesso". Questo, gestirebbe le operazioni come il pagamento delle commissioni e l'esecuzione del codice dell'EVM, così che gli sviluppatori di portafogli possano concentrarsi sul fornire eccellenti esperienze agli utenti. Nota: il contratto del punto d'accesso dell'EIP-4337, è stato distribuito alla Rete Principale di Ethereum l'1 marzo 2023. Puoi visualizzare il contratto su Etherscan. - @@ -95,7 +92,6 @@ Anche il funzionamento dei portafogli cambierà sotto EIP-4337. Invece di far re L'EIP-2938 mira ad aggiornare il protocollo di Ethereum introducendo un nuovo tipo di transazione, AA_TX_TYPE che include tre campi: nonce, target e data, dove nonce è un contatore di transazioni, target è l'indirizzo del contratto del punto d'accesso, e data è il bytecode dell'EVM. Per eseguire queste transazioni, devono essere aggiunte due nuove istruzioni (note come codici operativi) all'EVM: NONCE e PAYGAS. Il codice operativo NONCE traccia la sequenza della transazione e PAYGAS calcola e preleva il gas necessario per eseguire la transazione dal saldo del contratto. Queste nuove funzionalità consentono a Ethereum di supportare nativamente i portafogli di contratti intelligenti, poiché l'infrastruttura necessaria è integrata nel protocollo di Ethereum. Nota che l'EIP-2938 non è correntemente attiva. La community, al momento, preferisce EIP-4337 poiché non richiede modifiche al protocollo. - @@ -103,7 +99,6 @@ Nota che l'EIP-2938 non è correntemente attiva. La community, al momento, prefe L'EIP-3074 mira ad aggiornare i conti posseduti esternamente di Ethereum, consentendo loro di delegare il controllo a un contratto intelligente. Ciò significa che la logica dei contratti intelligenti potrebbe approvare le transazioni originate da un EOA. Questo consentirebbe funzionalità come la sponsorizzazione del gas e le transazioni raggruppate. Perché funzioni, devono essere aggiunti due nuovi codici operativi all'EVM: AUTH e AUTHCALL. Con l'EIP-3074, i benefici del portafoglio di un contratto intelligente sono resi disponibili senza la necessità di un contratto, invece un tipo specifico di contratto privo di stato, privo di fiducia e non ggiornabile, noto come "invocatore", gestisce le transazioni. Nota che EIP-3074 non è correntemente attivo. La community, al momento, preferisce EIP-4337 poiché non richiede modifiche al protocollo. - ## Stato attuale {#current-progress} diff --git a/public/content/translations/it/roadmap/beacon-chain/index.md b/public/content/translations/it/roadmap/beacon-chain/index.md index fdfafae0a45..d4529c6a841 100644 --- a/public/content/translations/it/roadmap/beacon-chain/index.md +++ b/public/content/translations/it/roadmap/beacon-chain/index.md @@ -6,7 +6,7 @@ template: upgrade image: /images/upgrades/core.png alt: summaryPoint1: La Beacon Chain ha introdotto il proof-of-stake all'ecosistema di Ethereum. -summaryPoint2: Si è unita alla catena di proof-of-work originale di Ethereum a settembre 2022. +summaryPoint2: "Si è unita alla catena di proof-of-work originale di Ethereum a settembre 2022." summaryPoint3: La Beacon Chain ha introdotto la logica del consenso e il protocollo di gossip dei blocchi, che ora protegge Ethereum. --- @@ -32,7 +32,7 @@ Lo staking ha un ruolo simile a quello che aveva il [mining](/developers/docs/co La transizione al proof of stake ha reso Ethereum significativamente più sicura e decentralizzata rispetto al proof of work. Più persone parteciperanno alla rete, più questa diventerà decentralizzata e protetta dagli attacchi. -E l'utilizzo del proof of stake come meccanismo di consenso è un componente fondamentale per [l'Ethereum sicuro, ecosostenibile e scalabile che conosciamo ora](/roadmap/vision/). +E l'utilizzo del proof of stake come meccanismo di consenso è un componente fondamentale per [l'Ethereum sicuro, ecosostenibile e scalabile che conosciamo ora](/staking/). diff --git a/public/content/translations/it/roadmap/danksharding/index.md b/public/content/translations/it/roadmap/danksharding/index.md index 59099359eac..6a853f4f77e 100644 --- a/public/content/translations/it/roadmap/danksharding/index.md +++ b/public/content/translations/it/roadmap/danksharding/index.md @@ -22,13 +22,11 @@ Ciò è costoso perché elaborato da tutti i nodi di Ethereum e risiede per semp I rollup sono un metodo per scalare Ethereum raggruppando le transazioni all'esterno della catena e, in seguito, pubblicando i risultati su Ethereum. Un rollup, essenzialmente, si compone di due parti: dati e controllo dell'esecuzione. I dati sono la sequenza completa delle transazioni elaborate da un rollup per produrre il cambiamento di stato pubblicato su Ethereum. Il controllo d'esecuzione è la ri-esecuzione di tali transazioni da un utente onesto (dimostratore) per aassicurarsi che il cambiamento di stato proposto sia corretto. Per effettuare il controllo d'esecuzione, i dati della transazione devono essere disponibili per un tempo sufficiente perché chiunque possa scaricarli e controllarli. Ciò significa che qualsiasi comportamento disonesto dal sequenziatore del rollup puà essere identificato e sfidato dal dimostratore. Tuttavia, non è necessario che sia disponibile per sempre. - I rollup pubblicano gli impegni ai dati delle proprie transazioni on chain e, inoltre, rendono disponibili i dati effettivi nei blob di dati. Ciò significa che i dimostratori possono verificare che gli impegni siano validi o sfidare i dati che ritengono siano errati. Al livello del nodo, i blob di dati sono conservati nel client del consenso. I client del consenso attestano di aver visto i dati e che sono stati propagati per la rete. Se i dati fossero conservati per sempre, tali client si allargherebberò, determinando grandi requisiti hardware per l'esecuzione di nodi. Invece, i dati sono eliminati automaticamente dal nodo ogni 18 giorni. Le attestazioni del client del consenso dimostrano che vi è stata un'opportunità sufficiente, affinché i dimostratori potessero verificare i dati. I dati effettivi possono essere memorizzati off-chain dagli operatori di rollup, dagli utenti o da terzi. - ### Come sono verificati i dati dei blob? {#how-are-blobs-verified} @@ -48,13 +46,11 @@ La cerimonia KZG dell'EIP-4844 era aperta al pubblico e decine di migliaia di pe Quando un rollup pubblica dati in un blob, fornisce un "impegno" che viene pubblicato sulla catena. Questo, è il risultato della valutazione di un adattamento polinomiale ai dati, in certi punti. Questi punti sono definiti dai numeri casuali generati nella cerimonia KZG. I dimostratori, quindi, possono valutare la polinomiale agli stessi punti, per poter verificare i dati; se arrivano agli stessi valori, allora i dati sono corretti. - Se qualcuno conoscesse le posizioni casuali utilizzate per l'impegno, sarebbe facile, per loro, generare una nuova polinomiaale che si adatti a quei punti specifici (cioè, una "collisione"). Ciò significa che potrebbero aggiungere o rimuovere i dati dal blob e, comunque, fornire una prova valida. Per impedirlo, invece di dare ai dimostratori le posizioni segrete effettive, ricevono in realtà le posizioni, avvolte in una "scatola nera" crittografica, utilizzando le curve ellittiche. Questi, infatti, rimescolano i valori in modo tale che i valori originali non siano decodificabili, ma con dimostratori e verificatori capaci in algebra, le polinomiali sono ancora valutabili ai punti rappresentati. - @@ -70,13 +66,11 @@ Funziona espandendo i blob collegati ai blocchi da sei (6) nel proto-dankshardin La separazione di propositori e costruttori è necessaria per impedire ai singoli validatori di dover generare costosi impegni e prove, per 32 MB di dati del blob. Questo metterebbe a dura prova gli staker domestici e richiederebbe loro di investire in hardware più potenti, danneggiando la decentralizzazione. Invece, i costruttori di blocchi specializzati si prendono la responsabilità di questo costoso lavoro di calcolo. Poi, mettono a disposizione i propri blocchi ai propositori di blocchi per la trasmissione. Il propositore di blocchi, semplicemente, sceglie il blocco più redditizio. Chiunque può verificare i blob in modo economico e rapido, a significare che ogni normale validatore può verificare che i costruttori di blocchi si stiano comportando onestamente. Questo permette di elaborare i blob di grandi dimensioni senza sacrificare la decentralizzazione. I costruttori di blocchi malevoli potrebbero semplicemente essere esplusi dalla rete e tagliati; altri arriverebbero al loro posto, poiché la costruzione di blocchi è un'attività redditizia. - Il campionamento della disponibilità dei dati è necessario perché i validatori verifichino in modo rapido ed efficace i dati dei blob. Utilizzando il campionmento della disponibilità dei dati, i validatori possono essere davvero certi che i blob di dati fossero disponibili e che siano stati inviati correttamente. Ogni validatore può campionare casualmente alcuni punti di dati e creare una prova, a significare che nessun validatore deve verificare l'intero blob. Se mancano dei dati, saranno identificati rapidamente e il blob sarà respinto. - ### Stato attuale {#current-progress} diff --git a/public/content/translations/it/roadmap/future-proofing/index.md b/public/content/translations/it/roadmap/future-proofing/index.md index 9166a97866d..6047829e3d4 100644 --- a/public/content/translations/it/roadmap/future-proofing/index.md +++ b/public/content/translations/it/roadmap/future-proofing/index.md @@ -1,6 +1,6 @@ --- title: Rendere Ethereum a prova di futuro -description: Questi aggiornamenti cementano Ethereum come lo strato fondamentale, resiliente e decentralizzato per il futuro, indipendentemente da ciò che conterrà. +description: "Questi aggiornamenti cementano Ethereum come lo strato fondamentale, resiliente e decentralizzato per il futuro, indipendentemente da ciò che conterrà." lang: it image: /images/roadmap/roadmap-future.png alt: "Roadmap di Ethereum" diff --git a/public/content/translations/it/roadmap/merge/index.md b/public/content/translations/it/roadmap/merge/index.md index 06cded798a0..eed70dddc1f 100644 --- a/public/content/translations/it/roadmap/merge/index.md +++ b/public/content/translations/it/roadmap/merge/index.md @@ -5,8 +5,8 @@ lang: it template: upgrade image: /images/upgrades/merge.png alt: -summaryPoint1: La Rete Principale di Ethereum utilizza il proof-of-stake, ma non è sempre stato così. -summaryPoint2: L'aggiornamento dal meccanismo originale di proof-of-work al proof-of-stake, è stato detto La Fusione. +summaryPoint1: "La Rete Principale di Ethereum utilizza il proof-of-stake, ma non è sempre stato così." +summaryPoint2: "L'aggiornamento dal meccanismo originale di proof-of-work al proof-of-stake, è stato detto La Fusione." summaryPoint3: La Fusione si riferisce all'unione della Rete Principale di Ethereum con una blockchain di proof-of-stake separata, detta Beacon Chain, ora coesistenti come un'unica catena. summaryPoint4: La Fusione ha ridotto il consumo energetico di Ethereum di circa il 99,95%. --- @@ -88,7 +88,6 @@ Gli elementi d'azione chiave includono: - Autenticare i client di esecuzione e di consenso con un segreto JWT condiviso, così che possano comunicare in sicurezza tra loro. Non completare i suddetti elementi farà sì che il tuo nodo risulti "offline", finché entrambi i livelli non saranno sincronizzati e autenticati. - Per ulteriori informazioni, consulta questo post del blog di Tim Beiko su Come La Fusione Influenza il Livello d'Applicazione di Ethereum. - ## La Fusione e il consumo energetico {#merge-and-energy} @@ -116,7 +114,7 @@ La Fusione ha segnato la fine del proof-of-work per Ethereum e ha dato inizio al ## La Fusione e il ridimensionamento {#merge-and-scaling} -La Fusione ha inoltre gettato le basi per ulteriori aggiornamenti di scalabilità, impossibili sotto il Poof of Work, portando Ethereum un po' più vicina al raggiungimento della completa scalabilità, sicurezza e sostenibilità delinate nella [visione di Ethereum](/roadmap/vision/). +La Fusione ha inoltre gettato le basi per ulteriori aggiornamenti di scalabilità, impossibili sotto il Poof of Work, portando Ethereum un po' più vicina al raggiungimento della completa scalabilità, sicurezza e sostenibilità delinate nella [visione di Ethereum](/energy-consumption/). ## Equivoci su La Fusione {#misconceptions} @@ -135,7 +133,6 @@ Eseguire un nodo che non produce blocchi è possibile per chiunque, in entrambi L'abilità per chiunque di gestire il proprio nodo è assolutamente essenziale per mantenere la decentralizzazione della rete di Ethereum. [Ulteriori informazioni sull'esecuzione di un proprio nodo](/run-a-node/) - tabella di marcia incentrata sui rollup, gli sforzi si concentrano sul ridimensionamento delle attività degli utenti al [livello 2](/layer-2/), consentendo alla Rete Principale di Livello 1 di essere un livello di accordo decentralizzato e sicuro, ottimizzato per l'archiviazione dei dati dei rollup, per aiutare a rendere esponenzialmente più economiche le transazioni dei rollup. La transizione al Proof of stake è un precursore essenziale per realizzarlo. [Ulteriori informazioni su gas e commissioni.](/developers/docs/gas/) - indirizzo di prelievo per iniziare a ricevere pagamenti automatici di qualsiasi saldo di staking in eccesso (ETH superiori a 32, da ricompense del protocollo). Questo aggiornamento, inoltre, ha consentito la capacità di un validatore di sbloccare e rivendicare l'intero saldo all'uscita dalla rete. [Maggiori informazioni sui prelievi in staking](/staking/withdrawals/) - - L'emissione di staking esatta fluttua a seconda dell'importo totale di ETH in staking - **Da La Fusione, restano approssimativamnte soltanto 1.700 ETH/giorno, riducendo la nuova emissione totale di ETH di circa l'88%** - La bruciatura: questa, fluttua secondo la domanda di rete. _Se_ per un dato giorno si osserva un prezzo di gas medio di almeno 16 gwei, questo compensa effettivamente i circa 1.700 ETH emessi ai validatori e porta l'inflazione netta di ETH a zero, o meno, per quel giorno. - ## Pre-Fusione (storico) {#pre-merge} @@ -63,7 +62,9 @@ Offerta totale di ETH: **circa 120.520.000 ETH** (al momento della Fusione a set **Circa l'11,3%** era emesso agli staker sul livello del consenso (0,52 / 4,61 * 100) + + ## Post-Fusione (oggi) {#post-merge} @@ -97,7 +98,9 @@ Tasso di emissione annualizzato totale: **circa 0,52%** Riduzione netta nell'emissione annuale di ETH: **circa 88,7%** ((4,61%-0,52%) / 4,61% * 100) + + ## La bruciatura {#the-burn} @@ -109,7 +112,9 @@ La forza opposta all'emissione di ETH è il tasso a cui gli ETH sono bruciati. P La bruciatura delle commissioni è divenuta attiva con l'[aggiornamento di Londra](/ethereum-forks/#london) ad agosto 2021 e resta immutata da La Fusione. + + Oltre alla bruciatura della commissione, implementata dall'aggiornamento di Londra, i validatori, inoltre, possono incorrere in sanzioni per essere online o, peggio, possono ricevere tagli per l'infrazione di regole specifiche che minacciano la sicurezza della rete. Queste, risultano in una riduzione degli ETH dal saldo di quel validatore, che non è ricompensato direttamente a nessun altro conto, bruciandoli/rimuovendoli effettivamente dalla circolazione. diff --git a/public/content/translations/it/roadmap/pbs/index.md b/public/content/translations/it/roadmap/pbs/index.md index 4b0b292c707..be168336e77 100644 --- a/public/content/translations/it/roadmap/pbs/index.md +++ b/public/content/translations/it/roadmap/pbs/index.md @@ -1,6 +1,6 @@ --- title: Separazione proponente-sviluppatore -description: Scopri come e perché i validatori di Ethereum divideranno le proprie responsabilità di costruzione e trasmissione dei blocchi. +description: "Scopri come e perché i validatori di Ethereum divideranno le proprie responsabilità di costruzione e trasmissione dei blocchi." lang: it --- @@ -21,7 +21,6 @@ I [mempool crittografati](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpkt Potenti organizzazioni possono spingere i validatori a censurare le transazioni da o verso certi indirizzi. I validatori si conformano a tale pressione rilevando gli indirizzi nella lista nera del proprio gruppo di transazioni e omettendoli dai blocchi che propongono. Dopo la PBS, non sarà più possibile poiché i propositori di blocchi non sapranno quali transazioni stanno trasmettendo nei propri blocchi. Potrebbe essere importante, per certi individui o app, conformarsi alle regole di censura, ad esempio, quando è emanata una legge nella loro regione. In tali casi, la conformità si verifica a livello di applicazione, mentre il protocolo rimane privo di permessi e di censura. - ## PBS e MEV {#pbs-and-mev} diff --git a/public/content/translations/it/roadmap/scaling/index.md b/public/content/translations/it/roadmap/scaling/index.md index 54d6c3f2ac9..2d511aa85e6 100644 --- a/public/content/translations/it/roadmap/scaling/index.md +++ b/public/content/translations/it/roadmap/scaling/index.md @@ -1,6 +1,6 @@ --- title: Ridimensionare Ethereum -description: I rollup raggruppano le transazioni al di fuori della catena, riducendo i costi per l'utente. Tuttavia, il modo in cui i rollup utilizzano i dati al momento è troppo costoso, il che limita l'economicità delle transazioni. Il Proto-Danksharding lo corregge. +description: "I rollup raggruppano le transazioni al di fuori della catena, riducendo i costi per l'utente. Tuttavia, il modo in cui i rollup utilizzano i dati al momento è troppo costoso, il che limita l'economicità delle transazioni. Il Proto-Danksharding lo corregge." lang: it image: /images/roadmap/roadmap-transactions.png alt: "Roadmap di Ethereum" diff --git a/public/content/translations/it/roadmap/security/index.md b/public/content/translations/it/roadmap/security/index.md index 11dfbd8b335..8526aae04e7 100644 --- a/public/content/translations/it/roadmap/security/index.md +++ b/public/content/translations/it/roadmap/security/index.md @@ -1,6 +1,6 @@ --- -title: Un Ethereum più sicuro -description: Ethereum è la piattaforma di contratti intelligenti più sicura e decentralizzata che esista. Tuttavia, restano ancora da implementare alcuni miglioramenti in modo che Ethereum resti resiliente a qualsiasi livello di attacco anche in un futuro lontano. +title: "Un Ethereum più sicuro" +description: "Ethereum è la piattaforma di contratti intelligenti più sicura e decentralizzata che esista. Tuttavia, restano ancora da implementare alcuni miglioramenti in modo che Ethereum resti resiliente a qualsiasi livello di attacco anche in un futuro lontano." lang: it image: /images/roadmap/roadmap-security.png alt: "Roadmap di Ethereum" diff --git a/public/content/translations/it/roadmap/single-slot-finality/index.md b/public/content/translations/it/roadmap/single-slot-finality/index.md index d8e0bc0c4a6..02ba9bcc682 100644 --- a/public/content/translations/it/roadmap/single-slot-finality/index.md +++ b/public/content/translations/it/roadmap/single-slot-finality/index.md @@ -1,6 +1,6 @@ --- -title: Finalità dello spazio singolo -description: Spiegazione della finalità dello spazio singolo +title: "Finalità dello spazio singolo" +description: "Spiegazione della finalità dello spazio singolo" lang: it --- diff --git a/public/content/translations/it/roadmap/user-experience/index.md b/public/content/translations/it/roadmap/user-experience/index.md index 2748d708027..3713de6141f 100644 --- a/public/content/translations/it/roadmap/user-experience/index.md +++ b/public/content/translations/it/roadmap/user-experience/index.md @@ -1,6 +1,6 @@ --- title: Migliorare l'esperienza degli utenti -description: Per molti, è ancora troppo complesso utilizzare Ethereum. Per incoraggiare l'adozione di massa, Ethereum deve ridurre drasticamente le proprie barriere d'accesso; gli utenti devono ricevere i benefici dell'accesso decentralizzato, privo di permessi e resistente alla censura a Ethereum, ma dev'essere privo di frizione, tanto quanto utilizzare una tradizionale app del web2. +description: "Per molti, è ancora troppo complesso utilizzare Ethereum. Per incoraggiare l'adozione di massa, Ethereum deve ridurre drasticamente le proprie barriere d'accesso; gli utenti devono ricevere i benefici dell'accesso decentralizzato, privo di permessi e resistente alla censura a Ethereum, ma dev'essere privo di frizione, tanto quanto utilizzare una tradizionale app del web2." lang: it image: /images/roadmap/roadmap-ux.png alt: "Roadmap di Ethereum" diff --git a/public/content/translations/it/roadmap/verkle-trees/index.md b/public/content/translations/it/roadmap/verkle-trees/index.md index 59cae3a2e7c..02bb4b09d23 100644 --- a/public/content/translations/it/roadmap/verkle-trees/index.md +++ b/public/content/translations/it/roadmap/verkle-trees/index.md @@ -18,7 +18,6 @@ Gli alberi di Verkle sono un passaggio fondamentale sul percorso per i client di I client di Ethereum, al momento, utilizzano una struttura di dati nota come Albero di Patricia di Merkle per memorizzarne i dati di stato. Le informazioni sui singoli conti sono memorizzati come foglie su un albero e, le coppie di foglie, ricevono ripetutamente un hash finché non ne resta soltanto uno. Questo hash finale è noto come la "radice". Per verficare i blocchi, i client di Ethereum eseguono tutte le transazioni in un blocco e aggiornano il proprio albero di stato locale. Il blocco è considerato valido se la radice dell'albero locale è identica a quella fornita dal propositore di blocchi, poiché qualsiasi differenza nel calcolo effettuato dal propositore del blocco e dal nodo di convalida, formerebbe un hash di radice completamente differente. Il problema è che la verifica della blockchain richiede che ogni client memorizzi l'intero albero di stato per il blocco di testa e per diversi blocchi storici (di default, su Geth, sono mantenuti i dati di stato per 128 blocchi oltre la testa). Ciò richiede che i client abbiano accesso a una grande quantità di spazio su disco, limitando l'esecuzione dei nodi completi su hardware economici e poco potenti. Una soluzione è aggiornare l'albero di stato a una struttura più efficiente (l'albero di Verkle), riepilogabile utilizzando un piccolo "testimone" ai dati, condivisibile invece dei dati di stato completi. Riformattare i dati di stato in un albero di Verkle è una pietra miliare per spostarsi verso i client privi di stato. - ## Cos'è un testimone e perché è necessario? {#what-is-a-witness} @@ -34,7 +33,6 @@ Sotto lo schema di impegno polinomiale, i testimoni hanno dimensioni gestibili, Le dimensioni dei testimoni variano a seconda del numero di foglie che include. Supponendo che il testimone copra 1000 foglie, un testimone per un albero di Merkle occuperebbe all'incirca 3,5 MB (ipotizzando 7 livelli all'albero). Un testimone per gli stessi dati in un albero di Verkle (ipotizzando 4 livelli all'albero) occuperebbe circa 150 kB; **circa 23 volte più piccolo**. Questa riduzione delle dimensioni del testimone consentirà ai testimoni del client di essere accettabilmente piccoli. I testimoni polinomiali variano da 0,128 a 1 kB a seconda dello specifico impegno polinomiale utilizzato. - ## Qual è la struttura di un albero di Verkle? {#what-is-the-structure-of-a-verkle-tree} diff --git a/public/content/translations/it/social-networks/index.md b/public/content/translations/it/social-networks/index.md index 47d7099ccb2..2c62d2f1d3f 100644 --- a/public/content/translations/it/social-networks/index.md +++ b/public/content/translations/it/social-networks/index.md @@ -65,18 +65,18 @@ I post pubblicati su Mirror sono memorizzati permanentemente su Arweave, una pia Gli utenti utilizzano il token [ERC-20](/glossary/#erc-20) nativo della piattaforma $MIND per pagare gli articoli. Inoltre, gli utenti, possono anche guadagnare token $MIND, pubblicando contenuti popolari, contribuendo all'ecosistema e riferendo altri alla piattaforma. -## Utilizzare i social decentralizzati {#use-decentralized-social-networks} +## Utilizzare i social decentralizzati {#farcaster} - **[Status.im](https://status.im/)**: _Status è un'app di messaggistica sicura che utilizza un protocollo open source e tra pari, nonché la crittografia end-to-end per proteggere i tuoi messaggi dalle terze parti._ - **[Mirror.xyz](https://mirror.xyz/)**: _Mirror è una piattaforma di pubblicazione decentralizzata e posseduta dagli utenti basata su Ethereum, per il crowdfunding delle idee, la monetizzazione dei contenuti e la creazione di community dal valore elevato._ - **[Lens Protocol](https://lens.xyz/)**: _Lens Protocol è un grafico sociale componibile e decentralizzato che aiuta i creatori a prendere possesso dei propri contenuti, ovunque vadano nel proprio giardino digitale dell'Intenet decentralizzato._ - **[Farcaster](https://farcaster.xyz/)**: _Farcaster è un social sufficientemente decentralizzato. È un protocollo aperto che supporta molti client, proprio come l'email._ -## Social network Web2 su Ethereum {#web2-social-networks-and-ethereum} +## Social network Web2 su Ethereum {#use-decentralized-social-networks} Le piattaforme social native del [Web3](/glossary/#web3) non sono le sole che stanno tentando di incorporare la tecnologia della blockchain nei social. Anche molte piattaforme centralizzate stanno pianificando di integrare Ethereum nella propria infrastruttura: -### Reddit {#reddit} +### Reddit {#web2-social-networks-and-ethereum} Reddit ha [pubblicizzato i Punti della Community](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users): token ERC-20 che gli utenti possono guadagnare pubblicando contenuti di qualità e contribuendo alle community online (subreddit). Puoi riscattare tali token in una subreddit per ottenere privilegi e vantaggi esclusivi. Per questo progetto, Reddit sta lavorando con Arbitrum, una rete di [livello 2](/glossary/#layer-2) progettata per ridimensionare le transazioni di Ethereum. @@ -84,9 +84,9 @@ Il programma è già attivo: la subreddit r/CryptoCurrency [adopera la propria v Oltre a utilizzare i Punti della Community per sbloccare funzionalità speciali, gli utenti possono anche scambiarli per valuta legale nelle piattaforme di scambio. Inoltre, l'importo di Punti della Community posseduto da un utente ne determina l'influenza sul processo decisionale all'interno della community. -## Lettura consigliate {#further-reading} +## Lettura consigliate {#brave} -### Articoli {#articles} +### Articoli {#audius} - [Decentralizzare i social: una guida allo stack dei social di Web3](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) - _Coinbase Ventures_ - [I social sono la prossima grande opportunità per la decentralizzazione](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) - _Ben Goertzel_ @@ -95,12 +95,12 @@ Oltre a utilizzare i Punti della Community per sbloccare funzionalità speciali, - [In che modo la blockchain può risolvere la privacy dei social](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) - _Prableen Bajpai_ - [Decentralizzazione sufficiente per i social](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) - _Varun Srinivasan_ -### Video {#videos} +### Video {#sorare} - [Social decentralizzati spiegati](https://www.youtube.com/watch?v=UdT2lpcGvcQ) - _Coinmarketcap_ - [La blockchain DeSo vuole decentralizzare i social](https://www.youtube.com/watch?v=SG2HUiVp0rE) - _Bloomberg Technology_ - [Il futuro dei social decentralizzati, con Balaji Srinivasan, Vitalik Buterin e Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) - _ETHGlobal_ -### Community {#communities} +### Community {#twitter} - [Subreddit r/CryptoCurrency](https://www.reddit.com/r/CryptoCurrency/) diff --git a/public/content/translations/it/staking/dvt/index.md b/public/content/translations/it/staking/dvt/index.md index d2f9a11efe2..b719b9c0de7 100644 --- a/public/content/translations/it/staking/dvt/index.md +++ b/public/content/translations/it/staking/dvt/index.md @@ -1,6 +1,6 @@ --- title: Tecnologia del validatore distribuito -description: La tecnologia del validatore distribuito consente l'operazione distribuita di un validatore di Ethereum da più parti. +description: "La tecnologia del validatore distribuito consente l'operazione distribuita di un validatore di Ethereum da più parti." lang: it --- diff --git a/public/content/translations/it/staking/solo/index.md b/public/content/translations/it/staking/solo/index.md index d1460e62efc..629e55fc205 100644 --- a/public/content/translations/it/staking/solo/index.md +++ b/public/content/translations/it/staking/solo/index.md @@ -71,6 +71,7 @@ Differente dalle sanzioni di inattività per esser offline, il taglio Ulteriori informazioni sullo slashing e sul ciclo di vita dei validatori + @@ -130,7 +131,6 @@ Esistono alcune domande molto comuni sullo staking che meritano di essere affron Un validatore è un'entità virtuale che risiede su Ethereum e partecipa al consenso del protocollo di Ethereum. I validatori sono rappresentati da un saldo, una chiave pubblica e altre proprietà. Un client del validatore è il software che agisce per conto del validatore detenendone e usandone la chiave privata. Un singolo client del validatore può detenere molte coppie di chiavi, controllando molti validatori. - diff --git a/public/content/translations/it/staking/withdrawals/index.md b/public/content/translations/it/staking/withdrawals/index.md index da48375cdc0..e0317c01898 100644 --- a/public/content/translations/it/staking/withdrawals/index.md +++ b/public/content/translations/it/staking/withdrawals/index.md @@ -166,7 +166,6 @@ eventName="read more"> Se fai parte di un [pool di staking](/staking/pools/) o detieni token di staking, dovresti chiedere al tuo fornitore ulteriori dettagli su come vengono gestiti i prelievi dallo staking, poiché ogni servizio opera in modo diverso. In generale, gli utenti dovrebbero essere liberi di rivendicare i propri ETH in staking sottostanti, o di modificare il fornitore di staking che utilizzano. Se un pool in particolare sta diventando troppo grande, è possibile uscire, riscattare i fondi e rimetterli in staking con un fornitore di dimensioni minori. O, se hai accumulato abbastanza ETH, potresti [fare staking da casa](/staking/solo/). - No, se il tuo validatore è ancora attivo sulla rete, un prelievo completo non si verificherà automaticamente. Questo richiede l'avvio manuale di un'uscita volontaria. Una volta che un validatore ha completato il procedimento di uscita e supponendo che il conto abbia le credenziali di prelievo, il saldo rimanente sarà then prelevato durante la successivapulizia del validatore. - Gli operatori del validatore dovrebbero visitare la pagina dei Prelievi del Launchpad di Staking, dove troveranno ulteriori dettagli su come preparare il proprio validatore ai prelievi, le tempistiche degli eventi e ulteriori dettagli sul funzionamento dei prelievi. Per testare la tua configurazione su una rete di prova, visita il Launchpad di Staking della rete di prova di Holesky per iniziare. -