Aider à mettre à jour cette page

🌏

Il existe une nouvelle version de cette page, mais seulement en anglais pour le moment. Aidez-nous à traduire la dernière version.

Aucun bogue ici !🐛

Cette page n'est pas traduite. Nous laissons volontairement cette page en anglais pour le moment.

Cette page est incomplète et nous aimerions votre aide. Modifiez cette page et ajoutez tout ce que vous pensez être utile aux autres.

Transactions

Dernière modification: , Invalid DateTime
Modifier la page

Les transactions sont des instructions signées cryptographiquement depuis 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 cet article, nous vous recommandons de commencer par lire les pages 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 montrant un changement d'état de cause de la transaction Schéma adapté à partir du document Ethereum EVM illustrated

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 mineur exécutera ensuite la transaction et propagera au reste du réseau le changement d'état qui en résultera.

Les transactions impliquent le paiement de frais et doivent être minées pour être valides. Pour simplifier ce chapitre, nous aborderons les frais de gaz et le minage dans d'autres sections.

Une transaction soumise comprend les informations suivantes :

  • recipient : adresse de réception (S'il s'agit d'un compte externe, la transaction va transférer la valeur. S'il s'agit d'un compte de contrat, la transaction exécutera le code du contrat.)
  • signature : 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.
  • value : quantité d'ETH à transférer de l'expéditeur au destinataire (en WEI, une dénomination de l'ETH).
  • data : champ facultatif pour inclure des données arbitraires.
  • gasLimit : Quantité maximum d’unités de gaz pouvant être consommée par la transaction. Les unités de gaz représentent les étapes de calcul.
  • maxPriorityFeePerGas : la quantité maximale de gaz à inclure comme un pourboire pour le mineur.
  • maxFeePerGas : Montant maximum de gaz prêt à être payé 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 mineur. Les utilisateurs doivent payer des frais pour ce calcul. La gasLimit et le gasPrice déterminent les frais de transaction maximum payés au mineur. Plus d'infos 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}
10
Afficher tout
📋 Copier

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}
18
Afficher tout
📋 Copier

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}
21
Afficher tout
📋 Copier
  • raw est la transaction signée sous forme de préfixe de longueur récursive (RLP)
  • tx est la transaction signée sous la 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'interface binaire-programme (ABI).

Les quatre premiers octets indiquent la fonction à appeler, en utilisant l'empreinte numérique de son nom et de ses arguments. Vous pouvez parfois identifier la fonction depuis le sélecteur à l'aide de cette base de données.

Le reste des calldata est constitué des arguments, encodés comme indiqué dans les spécifications ABI.

Par exemple, prenons cette transaction. Utilisez Cliquer pour en voir plus pour voir les calldata.

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

Le reste des données est :

10000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279
2000000000000000000000000000000000000000000000000000000003b0559f4
3

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. La valeur value est 0x3b0559f4 = 990206452.

Type de transaction

Sur Ethereum, il existe plusieurs types de transactions :

  • Transactions ordinaires : une transaction d'un portefeuille à 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 ont un coût en gaz pour être exécutées. Les transactions simples de transfert requièrent 21 000 unités de gaz.

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

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

Le compte de Marc sera débité de -1,0042 ETH.

Celui d'Alice sera crédité de +1,0 ETH.

Les frais de base seront brûlés -0.00399 ETH

Le mineur garde le pourboire +0.000210 ETH

Du gaz est également requis pour toute interaction avec un contrat intelligent.

Diagramme montrant comment le carburant non utilisé est remboursé Schéma adapté à partir du document Ethereum EVM illustrated

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

Cycle de vie des transactions

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

  1. Quand vous envoyez une transaction, la cryptographie génère un hash de transaction : 0x97d99bc77292111a21b12c933c949d4f31684f1d6954ff477d0477538ff017
  2. La transaction est ensuite diffusée sur le réseau et incluse dans un groupe comportant de nombreuses autres transactions.
  3. Un mineur doit sélectionner votre transaction et l'inclure dans un bloc pour la vérifier et la considérer comme "réussie".
    • Il peut exister un délai d'attente à ce stade quand le réseau est occupé et que les mineurs ne sont pas en mesure de suivre.
  4. Votre transaction recevra des « confirmations ». Le nombre de confirmations est le nombre de blocs créés depuis le bloc qui a inclus votre transaction. Plus le nombre est élevé, plus la certitude que le réseau a traité et reconnu la transaction est grande.
    • Les blocs récents peuvent être réorganisés, donnant l'impression que la transaction a échoué ; cependant, la transaction peut être encore valide mais incluse dans un bloc différent.
    • La probabilité d'une réorganisation diminue à chaque bloc miné, c'est-à-dire plus le nombre de confirmations est élevé, plus la transaction est immuable.

Démonstration visuelle

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

Enveloppe de transaction saisie

Ethereum avait à l'origine un unique format pour les transactions. Chaque transaction contenait une nonce, le prix du carburant, la limite de carburant, l'adresse de destination, la valeur, les données, v, r et s. Ces champs sont encodés en RLP, pour ressembler à 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 EIP-1559 sans affecter les formats de transactions existants.

EIP-2718 : Enveloppe de transaction saisie définit un type de transaction qui sert d'enveloppe à de futurs types de transaction.

L'EIP-2718 est une nouvelle enveloppe généralisée pour les opérations saisies. Dans la nouvelle norme, les transactions sont interprétées comme :

TransactionType || TransactionPayload

Où les champs sont définis comme :

  • TransactionType : un nombre compris entre 0 et 0x7f, pour un total de 128 types de transactions possibles.
  • TransactionPayload : une table arbitraire d'octets définie par le type de transaction.

Complément d'information

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

Cette page vous a-t-elle permis de répondre à votre question ?

👈
PrécédentComptes
SuivantBlocs
👉