Transazioni

Le transazioni sono istruzioni firmate crittograficamente dai conti. Un conto avvierà una transazione per aggiornare lo stato della rete di Ethereum. La transazione più semplice è il trasferimento di ETH da un conto all'altro.

Prerequisiti

Per aiutarti a comprendere meglio questa pagina, ti consigliamo di leggere, innanzitutto, sui Conti e la nostra introduzione a Ethereum.

Cos'è una transazione?

Una transazione di Ethereum si riferisce a un'azione avviata da un conto esterno, in altre parole, da un conto gestito da un umano, non da un contratto. Ad esempio, se Bob invia 1 ETH ad Alice, il conto di Bob sarà addebitato e quello di Alice sarà accreditato. Questa azione che modifica lo stato avviene all'interno di una transazione.

(opens in a new tab) Diagramma adattato da Ethereum EVM illustrated(opens in a new tab)

Le transazioni, che cambiano lo stato dell'EVM, devono essere trasmesse all'intera rete. Ogni nodo può trasmettere una richiesta di esecuzione di una transazione sull'EVM; in seguito, un validatore eseguirà la transazione e propagherà il cambiamento di stato risultante al resto della rete.

Le transazioni richiedono una commissione e devono essere incluse in un blocco validato. Per semplificare questa spiegazione, parleremo in altra sede di commissioni e di convalida.

Una transazione inviata contiene le seguenti informazioni:

• from – indirizzo del mittente che firmerà la transazione. Questo sarà un conto posseduto esternamente, in quanto i conti di contratti non possono inviare transazioni.
• recipient – l'indirizzo ricevente (se è un conto posseduto esternamente, la transazione trasferirà valore. Se è un conto di contratto, la transazione eseguirà il codice del contratto)
• signature – l'identificativo del mittente. Viene generata quando la chiave privata del mittente firma la transazione e conferma che il mittente ha autorizzato la transazione
• nonce – un contatore con incremento sequenziale, che indica il numero della transazione dal conto
• value – quantità di ETH da trasferire dal mittente al destinatario (denominata in WEI, dove 1 ETH corrisponde a 1e+18wei)
• input data - campo facoltativo per includere dati arbitrari
• gasLimit – importo massimo di unità di carburante che possono essere consumate dalla transazione. L'EVM specifica le unità di gas necessarie per ogni passaggio di calcolo
• maxPriorityFeePerGas – il prezzo massimo del carburante consumato da includere come mancia al validatore
• maxFeePerGas – la commissione massima per unità di carburante che si desidera pagare per la transazione (che include baseFeePerGas e maxPriorityFeePerGas)

Il gas è un riferimento al calcolo necessario perché un validatore elabori la transazione. Gli utenti devono pagare una commissione per questo calcolo. Il gasLimit e il maxPriorityFeePerGas determinano la commissione massima sulla transazione pagata al validatore. Di più sul Gas.

L'oggetto della transazione sarà qualcosa del genere:

1{
2  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
3  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
4  gasLimit: "21000",
5  maxFeePerGas: "300"
6  maxPriorityFeePerGas: "10"
7  nonce: "0",
8  value: "10000000000",
9}
10
Mostra tutto
 Copia

Ma l'oggetto di una transazione deve essere firmato utilizzando la chiave privata del mittente. Questo prova che la transazione è stata originata solo dal mittente e non è stata inviata in modo fraudolento.

Un client Ethereum come Geth gestirà il processo di firma.

Esempio di chiamata JSON-RPC:

1{
2  "id": 2,
3  "jsonrpc": "2.0",
4  "method": "account_signTransaction",
5  "params": [
6    {
7      "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
8      "gas": "0x55555",
9      "maxFeePerGas": "0x1234",
10      "maxPriorityFeePerGas": "0x1234",
11      "input": "0xabcd",
12      "nonce": "0x0",
13      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
14      "value": "0x1234"
15    }
16  ]
17}
18
Mostra tutto
 Copia

Esempio di risposta:

1{
2  "jsonrpc": "2.0",
3  "id": 2,
4  "result": {
5    "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
6    "tx": {
7      "nonce": "0x0",
8      "maxFeePerGas": "0x1234",
9      "maxPriorityFeePerGas": "0x1234",
10      "gas": "0x55555",
11      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
12      "value": "0x1234",
13      "input": "0xabcd",
14      "v": "0x26",
15      "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
16      "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
17      "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
18    }
19  }
20}
21
Mostra tutto
 Copia

• raw è la transazione firmata nella forma codificata prefisso di lunghezza ricorsiva (RLP)
• tx è la transazione firmata in formato JSON

Con l'hash di firma, la transazione può provare crittograficamente che proviene dal mittente ed è stata inviata alla rete.

Il campo di dati

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).

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(opens in a new tab).

Il resto dei calldata sono gli argomenti, codificati come specificato nelle specifiche dell'ABI(opens in a new tab).

Ad esempio, diamo un'occhiata a questa transazione(opens in a new tab). Usa Clicca per scoprire di più per visualizzare i calldata.

Il selettore della funzione è 0xa9059cbb. Ci sono diverse funzioni note con questa firma(opens in a new tab). In questo caso, il codice sorgente del contratto(opens in a new tab) è stato caricato su Etherscan, quindi sappiamo che la funzione è transfer(address,uint256).

Il resto dei dati è:

10000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
2000000000000000000000000000000000000000000000000000000003b0559f4
3

Secondo le specifiche ABI, i valori interi (come gli indirizzi, che sono interi da 20 byte), appaiono nell'ABI come words a 32 byte, con riempimento di zeri nella parte anteriore. Quindi sappiamo che l'indirizzo to è 4f6742badb049791cd9a37ea913f2bac38d01279(opens in a new tab). Il value è 0x3b0559f4 = 990206452.

Tipi di transazioni

Su Ethereum esistono diversi tipi di transazioni:

• Transazioni regolari: una transazione da un conto a un altro.
• Transazioni di distribuzione del contratto: una transazione senza un indirizzo 'to', in cui il campo dei dati è usato per il codice del contratto.
• Esecuzione di un contratto: una transazione che interagisce con un contratto intelligente distribuito. In questo caso, l'indirizzo 'a' è l'indirizzo del contratto intelligente.

Sul gas

Come accennato, le transazioni hanno un costo di gas per essere eseguite. Semplici transazioni di trasferimento richiedono 21.000 unità di Gas.

Quindi, perché Bob possa inviare 1 ETH ad Alice a una baseFeePerGas di 190 gwei e una maxPriorityFeePerGas di 10 gwei, Bob dovrà pagare la seguente commissione:

1(190 + 10) * 21000 = 4,200,000 gwei
2--or--
30.0042 ETH
4

Sul conto di Bob sarà addebitato -1,0042 ETH (1 ETH per Alice + 0,0042 ETH di commissioni del gas)

Il conto di Alice sarà accreditato di +1,0 ETH

La commissione base brucerà -0,00399 ETH

Il validatore riceve la mancia di oltre 0,000210 ETH

Il gas è anche necessario per qualsiasi interazione del contratto intelligente.

(opens in a new tab) Diagramma adattato da Ethereum EVM illustrated(opens in a new tab)

Il gas non utilizzato, viene rimborsato al conto dell'utente.

Ciclo di vita delle transazioni

Una volta inviata una transazione, succede quanto segue:

1. Un hash della transazione è stato generato crittograficamente: 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
2. La transazione è quindi trasmessa alla rete e aggiunta a un pool di transazione consistente in tutte le altre transazioni in sospeso della rete.
3. Un validatore deve scegliere la transazione e includerla in un blocco per verificarla e considerarla "riuscita".
4. Col passare del tempo, il blocco contenente la tua transazione sarà aggiornato a "giustificato", poi "finalizzato". Questi aggiornamenti rendono molto più certo che la transazione sia "riuscita" e che non sarà mai alterata. Una volta che un blocco è "finalizzato", l'unica cosa che potrebbe cambiarlo è un attacco a livello della rete che costerebbe molti miliardi di dollari.

Dimostrazione visiva

Guarda Austin mentre ti illustra transazioni, gas e mining.

Typed Transaction Envelope

In origine Ethereum aveva un solo formato per le transazioni. Ogni transazione conteneva un nonce, il prezzo del gas, il limite del gass, l'indirizzo di destinazione, il valore, i dati, v, r e s. Questi campi sono codificati in RLP per essere simili a questo:

RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

Ethereum si è evoluto per supportare diversi tipi di transazioni e consentire l'implementazione di nuove funzionalità, come gli elenchi d'accesso e EIP-1559(opens in a new tab), senza interferire sui precedenti formati di transazione.

EIP-2718(opens in a new tab) consente tale comportamento. Le transazioni sono interpretate come:

TransactionType || TransactionPayload

Dove i campi sono definiti come:

• TransactionType - un numero tra 0 e 0x7f, per un totale di 128 tipi di transazione possibili.
• TransactionPayload - un insieme arbitrario di byte definito dal tipo di transazione.

Letture consigliate

• EIP-2718: Typed Transaction Envelope(opens in a new tab)

Conosci una risorsa della community che ti è stata utile? Modifica questa pagina e aggiungila!

Argomenti correlati

• Conti
• Macchina virtuale Ethereum (EVM)
• Gas