Transactions

Les transactions sont des instructions signées cryptographiquement provenant des comptes. Un compte va initier une transaction pour mettre à jour l'état du réseau Ethereum. La transaction la plus simple consiste à transférer de l'ETH d'un compte à un autre.

Prérequis

Pour vous aider à mieux comprendre cette page, nous vous recommandons de lire d'abord Comptes et notre introduction à Ethereum.

Qu'est-ce qu'une transaction ?

Une transaction Ethereum est une action initiée par un compte externe, c'est-à-dire un compte géré par un être humain et non par un contrat. Par exemple, si Marc envoie 1 ETH à Alice, le compte de Marc doit être débité et celui d'Alice doit être crédité. Cette action, qui modifie l'état, se produit dans le cadre d'une transaction.

Diagramme adapté de Ethereum EVM illustrated (opens in a new tab)

Les transactions, qui modifient l'état de l'EVM, doivent être diffusées sur l'ensemble du réseau. N'importe quel nœud peut diffuser une demande pour qu'une transaction soit exécutée sur l'EVM. Un validateur exécutera ensuite la transaction et diffusera au reste du réseau le changement d'état qui en résultera.

Les transactions requièrent des frais et doivent être incluses dans un bloc validé. Pour simplifier ce chapitre, nous aborderons les frais de gaz et la validation dans d'autres sections.

Une transaction soumise comprend les informations suivantes :

from – l'adresse de l'expéditeur, qui signera la transaction. Il s'agira d'un compte externe, car les comptes contractuels ne vous permettront pas d'envoyer des transactions
to – l'adresse de réception (s'il s'agit d'un compte externe, la transaction transférera de la valeur). S'il s'agit d'un compte de contrat, la transaction exécutera le code du contrat.)
signature – l'identifiant de l'expéditeur. Cette signature est générée lorsque la clé privée de l'expéditeur signe la transaction, et confirme que l'expéditeur a autorisé cette transaction.
nonce - un compteur à incrémentation séquentielle qui indique le numéro de la transaction du compte
value – montant d'ETH à transférer de l'expéditeur au destinataire (exprimé en WEI, où 1 ETH équivaut à 1e+18 wei)
input data – champ facultatif pour inclure des données arbitraires
gasLimit – la quantité maximale d'unités de gaz qui peut être consommée par la transaction. L'EVM spécifie les unités de gaz requises par chaque étape de calcul
maxPriorityFeePerGas - le prix maximum du gaz consommé à inclure comme pourboire pour le validateur
maxFeePerGas - les frais maximum par unité de gaz que l'on est prêt à payer pour la transaction (incluant baseFeePerGas et maxPriorityFeePerGas)

Le gaz est une référence au calcul nécessaire au traitement de la transaction par un validateur. Les utilisateurs doivent payer des frais pour ce calcul. Les paramètres gasLimit et maxPriorityFeePerGas déterminent les frais de transaction maximums payés au validateur. En savoir plus sur le gaz.

L'objet de transaction ressemblera un peu à ceci :

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

Un objet de transaction doit être signé avec la clé privée de l'expéditeur. Cela prouve que la transaction ne pouvait venir que de l'expéditeur et n'a pas été envoyée de façon frauduleuse.

Un client Ethereum comme Geth gérera ce processus de signature.

Exemple d'appel 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}
Afficher tout

Exemple de réponse :

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}
Afficher tout

le raw est la transaction signée sous forme codée en Préfixe de longueur récursive (RLP)
le tx est la transaction signée sous forme JSON

Grâce au hachage de la signature, il est possible de prouver de façon cryptographique que la transaction provient de l'expéditeur et qu'elle a été soumise au réseau.

Le champ de données

La grande majorité des transactions accèdent à un contrat provenant d'un compte externe. La plupart des contrats sont écrits en Solidity et interprètent leur champ de données conformément à l'.

Les quatre premiers octets indiquent la fonction à appeler, en utilisant les hachages de son nom et de ses arguments. Vous pouvez parfois identifier la fonction à partir du sélecteur en utilisant cette base de données (opens in a new tab).

Le reste des données d'appel (calldata) correspond aux arguments, codés comme spécifié dans les spécifications de l'ABI (opens in a new tab).

Par exemple, regardons cette transaction (opens in a new tab). Utilisez Cliquer pour en voir plus pour voir les données d'appel (calldata).

Le sélecteur de fonction est 0xa9059cbb. Il existe plusieurs fonctions connues avec cette signature (opens in a new tab). Dans ce cas le code source du contrat (opens in a new tab) a été téléversé sur Etherscan, nous savons donc que la fonction est transfer(address,uint256).

Le reste des données est :

10000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
2000000000000000000000000000000000000000000000000000000003b0559f4

Selon les spécifications ABI, les valeurs entières (comme les adresses, qui sont des entiers de 20 octets) apparaissent dans l'ABI sous forme de mots de 32 octets, complétées de zéros au début. Nous savons donc que l'adresse to est 4f6742badb049791cd9a37ea913f2bac38d01279 (opens in a new tab). La value est 0x3b0559f4 = 990206452.

Types de transactions

Sur Ethereum, il existe plusieurs types de transactions :

Transactions ordinaires : une transaction d'un portefeuille vers un autre.
Transactions de déploiement de contrats : une transaction sans adresse « to », où le champ de données est utilisé pour le code du contrat.
Exécution d'un contrat : une transaction qui interagit avec un contrat intelligent déployé. Dans ce cas précis, l'adresse "to" est celle du contrat intelligent.

À propos du gaz

Comme mentionné, les transactions coûtent du gaz pour être exécutées. Les transactions simples de transfert requièrent 21 000 unités de gaz.

Donc, pour que Bob envoie 1 ETH à Alice avec un baseFeePerGas de 190 gwei et un maxPriorityFeePerGas de 10 gwei, Bob devra payer les frais suivants :

1(190 + 10) * 21000 = 4 200 000 gwei
2-- soit --
30,0042 ETH

Le compte de Bob sera débité de -1,0042 ETH (1 ETH pour Alice + 0,0042 ETH de frais de gaz)

Le compte d'Alice sera crédité de +1,0 ETH

Les frais de base seront brûlés -0,00399 ETH

Le validateur conserve le pourboire +0,000210 ETH

Diagramme adapté de Ethereum EVM illustrated (opens in a new tab)

Tout gaz non utilisé dans une transaction est remboursé sur le compte de l'utilisateur.

Interactions avec les contrats intelligents

Du gaz est nécessaire pour toute transaction qui implique un contrat intelligent.

Les contrats intelligents peuvent également contenir des fonctions connues sous le nom de fonctions view (https://docs.soliditylang.org/en/latest/contracts.html#view-functions (opens in a new tab)) ou pure (https://docs.soliditylang.org/en/latest/contracts.html#pure-functions (opens in a new tab)), qui ne modifient pas l'état du contrat. Ainsi, appeler ces fonctions à partir d'un EOA ne nécessitera aucun gaz. L'appel RPC sous-jacent pour ce scénario est eth_call.

Contrairement à l'accès via eth_call, ces fonctions view ou pure sont également couramment appelées en interne (c'est-à-dire depuis le contrat lui-même ou depuis un autre contrat), ce qui coûte du gaz.

Cycle de vie des transactions

Voici ce qui se passe une fois qu'une transaction a été soumise :

Un hachage de transaction est généré par cryptographie : 0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
La transaction est ensuite diffusée sur le réseau et ajoutée à un pool de transactions composé de toutes les autres transactions réseau en attente.
Un validateur doit sélectionner votre transaction et l'inclure dans un bloc pour la vérifier et la considérer comme « réussie ».
Au fur et à mesure que le temps passe, le bloc contenant votre transaction sera mis à niveau vers « justifié » puis « finalisé ». Ces mises à niveau garantissent davantage que votre transaction a été réussie et ne sera jamais modifiée. Une fois qu'un bloc est « finalisé », il ne peut être modifié que par une attaque au niveau du réseau qui coûterait plusieurs milliards de dollars.

Une démo visuelle

Regardez Austin vous guider à travers les transactions, le gaz et le minage.

Enveloppe de transaction typée

Ethereum avait à l'origine un unique format pour les transactions. Chaque transaction contenait une nonce, le prix du gaz, la limite de gaz, l'adresse de destination, la valeur, les données, v, r et s. Ces champs sont codés en RLP, pour ressembler à quelque chose comme ceci :

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

Ethereum a évolué pour prendre en charge plusieurs types de transactions afin de permettre l'implémentation de nouvelles fonctionnalités telles que les listes d'accès et l'EIP-1559 (opens in a new tab) sans affecter les anciens formats de transaction.

C'est l'EIP-2718 (opens in a new tab) qui permet ce comportement. Les transactions sont interprétées comme :

TransactionType || TransactionPayload

Où les champs sont définis comme :

TransactionType - un nombre entre 0 et 0x7f, pour un total de 128 types de transactions possibles.
TransactionPayload - un tableau d'octets arbitraire défini par le type de transaction.

En fonction de la valeur de TransactionType, une transaction peut être classée comme suit :

Transactions de type 0 (héritées) : le format de transaction original utilisé depuis le lancement d'Ethereum. Elles n'incluent pas de fonctionnalités de l'EIP-1559 (opens in a new tab) telles que les calculs dynamiques des frais de gaz ou les listes d'accès pour les contrats intelligents. Les transactions héritées n'ont pas de préfixe spécifique indiquant leur type sous leur forme sérialisée. Elles commencent par l'octet 0xf8 lors de l'utilisation du codage par préfixe de longueur récursive (RLP). La valeur de TransactionType pour ces transactions est 0x0.
Transactions de type 1 : Introduites dans l'EIP-2930 (opens in a new tab) dans le cadre de la mise à niveau Berlin d'Ethereum, ces transactions incluent un paramètre accessList. Cette liste spécifie les adresses et les clés de stockage auxquelles la transaction s'attend à accéder, ce qui peut potentiellement aider à réduire les coûts de gaz pour les transactions complexes impliquant des contrats intelligents. Les variations du marché des frais EIP-1559 ne sont pas incluses dans les transactions de type 1. Les transactions de type 1 incluent également un paramètre yParity, qui peut être 0x0 ou 0x1, indiquant la parité de la valeur y de la signature secp256k1. Elles sont identifiées en commençant par l'octet 0x01, et leur valeur de TransactionType est 0x1.
Les transactions de type 2, communément appelées transactions EIP-1559, sont des transactions introduites dans l'EIP-1559 (opens in a new tab), lors de la mise à niveau London d'Ethereum. Elles sont devenues le type de transaction standard sur le réseau Ethereum. Ces transactions introduisent un nouveau mécanisme de marché des frais qui améliore la prévisibilité en séparant les frais de transaction en frais de base et en frais prioritaires. Elles commencent par l'octet 0x02 et incluent des champs tels que maxPriorityFeePerGas et maxFeePerGas. Les transactions de Type 2 sont désormais la norme en raison de leur flexibilité et de leur efficacité. Elles sont particulièrement appréciées pendant les périodes de forte congestion du réseau car elles permettent aux utilisateurs de gérer les frais de transaction de manière plus prévisible. La valeur de TransactionType pour ces transactions est 0x2.
Les transactions de type 3 (Blob) ont été introduites dans l'EIP-4844 (opens in a new tab) dans le cadre de la mise à niveau Dencun d'Ethereum. Ces transactions sont conçues pour gérer les données de type « blob » (Binary Large Objects) de manière plus efficace, ce qui profite particulièrement aux rollups de couche 2 en offrant un moyen de publier des données sur le réseau Ethereum à moindre coût. Les transactions Blob incluent des champs supplémentaires tels que blobVersionedHashes, maxFeePerBlobGas, et blobGasPrice. Elles commencent par l'octet 0x03, et leur valeur de TransactionType est 0x3. Les transactions « blob » constituent une amélioration significative de la disponibilité des données et des capacités d'évolutivité d’Ethereum.
Les transactions de type 4 ont été introduites dans l'EIP-7702 (opens in a new tab) dans le cadre de la mise à niveau Pectra d'Ethereum. Ces transactions sont conçues pour être compatibles avec l'abstraction de compte. Elles permettent aux EOA de se comporter temporairement comme des comptes de contrat intelligent sans compromettre leur fonctionnalité d'origine. Elles incluent un paramètre authorization_list, qui spécifie le contrat intelligent auquel l'EOA délègue son autorité. Après la transaction, le champ de code de l'EOA aura l'adresse du contrat intelligent délégué.

En savoir plus

EIP-2718 : Enveloppe de transaction typée (opens in a new tab)

Une ressource communautaire vous a aidé ? Modifiez cette page et ajoutez-la !