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/intro-to-ethereum/index.md b/public/content/translations/it/developers/docs/intro-to-ethereum/index.md
index 26d4c9ffb8e..da74e7a90f2 100644
--- a/public/content/translations/it/developers/docs/intro-to-ethereum/index.md
+++ b/public/content/translations/it/developers/docs/intro-to-ethereum/index.md
@@ -111,6 +111,6 @@ Uno snippet di codice riutilizzabile (programma) che uno sviluppatore pubblica n
_Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!_
-## Tutorial correlati {#related-tutorials}
+## Tutorial correlati {#visual-learner}
- [Una guida per sviluppatori a Ethereum, parte 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Un'esplorazione di Ethereum pensata per i principianti usando Python e web3.py_
diff --git a/public/content/translations/it/developers/docs/networking-layer/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.
- 
+
+
-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.
-
+
-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/)
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
{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. -SELFDESTRUCT soltanto nella stessa transazioneBLOBBASEFEESELFDESTRUCT0xEFEXTCODEHASH per recuperare l'hash del codice di un altro contratto.DELEGATECALLAA_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.
-
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.
-