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.

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.
to: l'indirizzo del destinatario (se è un conto posseduto esternamente, la transazione trasferirà il 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}
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}
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}
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'.

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

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

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

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

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

Interazioni con i contratti intelligenti

Il gas è necessario per qualsiasi transazione riguardi un contratto intelligente.

Inoltre, i contratti intelligenti possono contenere delle funzioni note come view(opens in a new tab) o pure(opens in a new tab), che non alterano lo stato del contratto. Per questo, chiamare tali funzioni da un EOA non richiederà alcun gas. La chiamata RPC sottostante per questo scenario è eth_call

A differenza di quando si accede utilizzando eth_call, queste funzioni view o pure sono comunemente chiamate anche internamente (cioè dal contratto stesso o da un altro contratto) e questo costa gas.

Ciclo di vita delle transazioni

Una volta inviata una transazione, succede quanto segue:

Un hash della transazione è stato generato crittograficamente: 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
La transazione è quindi trasmessa alla rete e aggiunta a un pool di transazione consistente in tutte le altre transazioni in sospeso della rete.
Un validatore deve scegliere la transazione e includerla in un blocco per verificarla e considerarla "riuscita".
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.

A seconda del valore di TransactionType, una transazione è classificabile come

Transazioni di Tipo 0 (Ereditarie): Il formato della transazione originale utilizzato dal lancio di Ethereum. Non includono le funzionalità dall'EIP-1559(opens in a new tab), come il calcolo dinamico delle commissioni sul gas o gli elenchi di accesso per i contratti intelligenti. Le transazioni ereditarie mancano di un prefisso specifico che ne indichi il tipo nella loro forma serializzata, che parte dal byte 0xf8 utilizzando la codifica a Prefisso di Lunghezza Ricorsiva (RLP). Il valore TransactionType per queste transazioni è 0x0.
Transazioni di Tipo 1: introdotte nell'EIP-2930(opens in a new tab) come parte dell'Aggiornamento Berlino di Ethereum, queste transazioni includono un parametro accessList. Questo elenco specifica gli indirizzi e le chiavi di memorizzazione a cui la transazione prevede di accedere, contribuendo potenzialmente a ridurre i costi del gas per le transazioni complesse che comportano contratti intelligenti. Le modifiche al mercato delle commissioni dell'EIP-1559 non sono incluse nelle transazioni di Tipo 1. Le transazioni di Tipo 1 includono anche un parametro yParity, che può essere 0x0 o 0x1, indicando la parità del valore y della firma secp256k1. Sono identificate perché iniziano con il byte 0x01 e il loro valore di TransactionType è 0x1.
Le transazioni di Tipo 2, comunemente note come transazioni EIP-1559, sono transazioni introdotte nell'EIP-1559(opens in a new tab), nell'Aggiornamento Londra di Ethereum. Sono diventate il tipo di transazione standard sulla rete di Ethereum. Queste transazioni introducono un nuovo meccanismo del mercato delle commissioni che ne migliora la prevedibilità, separando la commissione sulla transazione in una commissione di base e una di priorità. Iniziano con il byte 0x02 e includono campi come maxPriorityFeePerGas e maxFeePerGas. Le transazioni di Tipo 2 sono ora le predefinite a causa della loro flessibilità ed efficienza, favorite specialmente durante i periodi di elevata congestione della rete per la loro capacità di aiutare gli utenti a gestire le commissioni sulle transazioni in maniera più prevedibile. Il valore di TransactionType per queste transazioni è 0x2.

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!