Transactions
Dernière modification: @MATsxm(opens in a new tab), 16 juillet 2024
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.
Schéma adapté à partir du document 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 :
depuis- l'adresse de l'expéditeur qui signera la transaction. On aura donc une adresse émettrice, car les contrats et les adresses (Accounts) ne vous permettront pas d'envoyer des transactions.to: l'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.nonce-, il s'agit d'une machine à travers laquelle un nombre maximum d'essais consécutifs est réalisé, il qualifie aussi le numéro de transactions dans la liste des transactions sortantes depuis votre adressevaleur- montants de l'Ether (ETH) à transférer de l'expéditeur au destinataire (libellé en WEI parallèlement à la valeur de l'Ether, qui atteint les 1e+18wei)input data– champ facultatif permettant d'inclure des données arbitrairesgasLimit: Quantité maximum d’unités de gaz pouvant être consommée par la transaction. La machine virtuelle d'Ethereum (EVM) donne une estimation de la quantité de gaz (unité virtuelle) nécessaire à une opération, ce qui permet de représenter les coûts informatiques d'une opération sur le réseaumaxPriorityFeePerGas: la quantité maximale de gaz à inclure comme pourboire pour le validateurmaxFeePerGas: montant maximum de gaz prêt à être payé pour la transaction (y comprisbaseFeePerGasetmaxPriorityFeePerGas)
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. gasLimit et gasPrice déterminent les frais de transaction maximum payés au validateur. 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}Afficher toutCopier
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 toutCopier
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 toutCopier
rawest la transaction signée sous forme de préfixe de longueur récursive (RLP)txest 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'.
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 depuis le sélecteur à l'aide de cette base de données(opens in a new tab).
Le reste des calldata est constitué des arguments, encodés comme indiqué dans les spécifications ABI(opens in a new tab).
Par exemple, prenons cette transaction(opens in a new tab). 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(opens in a new tab). Dans ce cas, le code source du contrat(opens in a new tab) a été chargé sur Etherscan, nous savons donc que la fonction est transfer(address,uint256).
Le reste des données est :
10000000000000000000000004f6742badb049791cd9a37ea913f2bac38d012792000000000000000000000000000000000000000000000000000000003b0559f4
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 valeur value est 0x3b0559f4 = 990206452.
Type de transaction
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 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 gwei2-- soit --30,0042 ETH
Le compte de Bob sera débité de -1,0042 ETH (1 ETH pour Alice + 0,0042 ETH en frais de gaz)
Celui 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 de +0,000210 ETH
Schéma adapté à partir du document 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 des contracts 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(opens in a new tab) ou pure(opens in a new tab), qui n'altèrent 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'utilisation de eth_call, ces fonctions view ou pure sont également fréquemment appelées en interne (c'est-à-dire à partir du contrat lui-même ou d'un autre contrat), ce qui entraîne un coût en gaz.
Cycle de vie des transactions
Voici ce qui se passe une fois qu'une transaction a été soumise :
- Le hash de la transaction vient d'être généré grâce aux fonctions de hachage (suite d'opérations mathématiques et cryptographiques) :
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é ». Grâce à ces mises à niveau, vous êtes davantage assuré que votre transaction a été réussie et qu'elle ne sera jamais altérée. Une fois qu'un bloc est "finalisé", il ne peut plus être modifié par une attaque au niveau du réseau qui coûterait plusieurs milliards de dollars.
Démonstration visuelle
Regardez Austin vous guider à travers les transactions, le gaz 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 gaz, la limite de gaz, l'adresse de destination, la valeur, les données, v, r et s. Il s'agit de champs d'application d'un RLP, qui pourraient 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(opens in a new tab) sans affecter les formats de transactions existants.
EIP-2718(opens in a new tab) spécifie la façon dont cela est géré. 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.
En fonction de la valeur TransactionType, une transaction peut être classée comme
Transactions de type 0 (Legacy) : Le format de transaction original utilisé depuis le lancement d'Ethereum. Ils n'incluent pas les 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 originelles n'ont pas de préfixe spécifique indiquant leur type dans leur forme sérialisée, et commencent par l'octet
0xf8lorsqu'elles utilisent le codage Recursive Length Prefix (RLP). La valeur TransactionType pour ces transactions est0x0.Transactions de type 1 : Introduites dans EIP-2930(opens in a new tab) dans le cadre de la mise à jour 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, contribuant ainsi potentiellement à 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ètreyParity, qui peut être soit0x0, soit0x1, indiquant la parité de la valeur y de la signature secp256k1. Elles sont identifiées en commençant par l'octet0x01, et leur valeur TransactionType est0x1.Transactions de type 2, communément appelées transactions EIP-1559, sont des transactions introduites dans EIP-1559(opens in a new tab), lors de la mise à jour 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
0x02et incluent des champs tels quemaxPriorityFeePerGasetmaxFeePerGas. 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 TransactionType pour ces transactions est0x02.
Complément d'information
Une ressource communautaire vous a aidé ? Modifiez cette page et ajoutez-la !