Regardons d’abord la structure de base d’une transaction, telle qu’elle est sérialisée et transmise sur le réseau Ethereum. Chaque client et application qui reçoit une transaction sérialisée la stocke en mémoire en utilisant sa propre structure de données interne, éventuellement agrémentée de métadonnées qui n’existent pas dans la transaction sérialisée du réseau elle-même. La sérialisation réseau est la seule forme standard d’une transaction.

Une transaction est un message binaire sérialisé qui contient les données suivantes :

La structure du message de transaction est sérialisée à l’aide du schéma de codage Recursive Length Prefix (RLP) (ou Préfixe de longueur récursif), qui a été créé spécifiquement pour sérialisation de données simple et parfaite dans Ethereum. Tous les nombres dans Ethereum sont codés sous forme d’entiers gros-boutiste, de longueurs multiples de 8 bits.

Notez que les étiquettes de champ (to, gas limit, etc.) sont affichées ici pour plus de clarté, mais ne font pas partie des données sérialisées de la transaction, qui contiennent les valeurs de champ codées RLP. En général, RLP ne contient aucun délimiteur de champ ou étiquette. Le préfixe de longueur de RLP est utilisé pour identifier la longueur de chaque champ. Tout ce qui dépasse la longueur définie appartient au champ suivant dans la structure.

Bien qu’il s’agisse de la structure de transaction réelle transmise, la plupart des représentations internes et des visualisations d’interface utilisateur l’agrémentent d’informations supplémentaires, dérivées de la transaction ou de la chaîne de blocs.

Par exemple, vous remarquerez peut-être qu’il n’y a pas de données "from" dans l’adresse identifiant l’EOA d’origine. En effet, la clé publique de l’EOA peut être dérivée des composants v,r,s de la signature ECDSA. L’adresse peut, à son tour, être dérivée de la clé publique. Lorsque vous voyez une transaction affichant un champ "from", qui a été ajouté par le logiciel utilisé pour visualiser la transaction. D’autres métadonnées fréquemment ajoutées à la transaction par le logiciel client incluent le numéro de bloc (une fois extrait et inclus dans la chaîne de blocs) et un ID de transaction (hachage calculé). Encore une fois, ces données sont dérivées de la transaction et ne font pas partie du message de transaction lui-même.

Le nonce est l’un des composants les plus importants et les moins compris d’une transaction. La définition du Livre jaune (voir [references]) lit :

À proprement parler, le nonce est un attribut de l’adresse d’origine ; c’est-à-dire qu’il n’a de sens que dans le contexte de l’adresse d’envoi. Cependant, le nonce n’est pas stocké explicitement dans le cadre de l’état d’un compte sur la chaîne de blocs. Au lieu de cela, il est calculé dynamiquement, en comptant le nombre de transactions confirmées provenant d’une adresse.

Il existe deux scénarios dans lesquels l’existence d’un nonce de comptage des transactions est importante : la fonctionnalité d’utilisabilité des transactions incluses dans l’ordre de création et la fonctionnalité vitale de la protection contre la duplication des transactions. Regardons un exemple de scénario pour chacun d’entre eux :

En résumé, il est important de noter que l’utilisation du nonce est en fait vitale pour un protocole basé sur le compte, contrairement au mécanisme "Unspent Transaction Output" (UTXO) du protocole Bitcoin.

Nous avons un peu parlé du gaz dans les chapitres précédents, et nous en discutons plus en détail dans [gas]. Cependant, couvrons quelques notions de base sur le rôle des composants gasPrice et gasLimit d’une transaction.

Le gaz est le carburant d’Ethereum. Le gaz n’est pas de l’ether, c’est une monnaie virtuelle distincte avec son propre taux de change par rapport à l’ether. Ethereum utilise du gaz pour contrôler la quantité de ressources qu’une transaction peut utiliser, car elle sera traitée sur des milliers d’ordinateurs à travers le monde. Le modèle de calcul ouvert (Turing-complet) nécessite une certaine forme de mesure afin d’éviter les attaques par déni de service ou les transactions gourmandes en ressources par inadvertance.

Le gaz est séparé de l’ether afin de protéger le système de la volatilité qui pourrait survenir avec les changements rapides de la valeur de l’ether, et aussi comme moyen de gérer les rapports importants et sensibles entre les coûts des diverses ressources que le gaz paie. (à savoir, calcul, mémoire et stockage).

Le champ gasPrice dans une transaction permet à l’initiateur de la transaction de définir le prix qu’il est prêt à payer en échange de gaz. Le prix est mesuré en wei par unité de gaz. Par exemple, dans l’exemple de transaction dans [intro_chapter] votre portefeuille fixe le gasPrice à 3 gwei (3 gigawei ou 3 milliards de wei).

Les portefeuilles peuvent ajuster le gasPrice dans les transactions qu’ils génèrent pour obtenir une confirmation plus rapide des transactions. Plus le gasPrice est élevé, plus la transaction est susceptible d’être confirmée rapidement. À l’inverse, les transactions moins prioritaires peuvent avoir un prix réduit, ce qui entraîne une confirmation plus lente. La valeur minimale à laquelle gasPrice peut être défini est zéro, ce qui signifie une transaction sans frais. Pendant les périodes de faible demande d’espace dans un bloc, de telles transactions pourraient très bien être minées.

L’interface web3 propose une suggestion gasPrice, en calculant un prix médian sur plusieurs blocs (nous pouvons utiliser la console truffle ou n’importe quelle console web3 JavaScript pour le faire) :

Le deuxième champ important lié au gaz est gasLimit. En termes simples, gasLimit donne le nombre maximum d’unités de gaz que l’initiateur de la transaction est prêt à acheter pour finaliser la transaction. Pour les paiements simples, c’est-à-dire les transactions qui transfèrent de l’ether d’un EOA à un autre EOA, la quantité de gaz nécessaire est fixée à 21 000 unités de gaz. Pour calculer combien d’ether cela coûtera, vous multipliez 21 000 par le gasPrice que vous êtes prêt à payer. Par example:

Si l’adresse de destination de votre transaction est un contrat, la quantité de gaz nécessaire peut être estimée mais ne peut pas être déterminée avec précision. En effet, un contrat peut évaluer différentes conditions qui conduisent à différentes voies d’exécution, avec différents coûts totaux du gaz. Le contrat peut n’exécuter qu’un calcul simple ou un calcul plus complexe, selon des conditions indépendantes de votre volonté et imprévisibles. Pour le démontrer, regardons un exemple : nous pouvons écrire un contrat intelligent qui incrémente un compteur à chaque fois qu’il est appelé et exécute une boucle particulière un nombre de fois égal au nombre d’appels. Peut-être qu’au 100e appel, il distribue un prix spécial, comme une loterie, mais doit faire des calculs supplémentaires pour calculer le prix. Si vous appelez le contrat 99 fois, une chose se produit, mais au 100e appel, quelque chose de très différent se produit. La quantité de gaz que vous paieriez pour cela dépend du nombre d’autres transactions qui ont appelé cette fonction avant que votre transaction ne soit incluse dans un bloc. Peut-être que votre estimation est basée sur la 99e transaction, mais juste avant que votre transaction ne soit confirmée, quelqu’un d’autre appelle le contrat pour la 99e fois. Vous êtes maintenant la 100e transaction à appeler, et l’effort de calcul (et le coût du gaz) est beaucoup plus élevé.

Pour emprunter une analogie courante utilisée dans Ethereum, vous pouvez considérer gasLimit comme la capacité du réservoir de carburant de votre voiture (votre voiture est la transaction). Vous remplissez le réservoir avec autant d’essence que vous pensez qu’il en aura besoin pour le trajet (le calcul nécessaire pour valider votre transaction). Vous pouvez estimer le montant dans une certaine mesure, mais il peut y avoir des changements inattendus dans votre trajet, comme une déviation (un chemin d’exécution plus complexe), qui augmentent la consommation de carburant.

L’analogie avec un réservoir de carburant est cependant quelque peu trompeuse. Il s’agit en fait plus d’un compte de crédit pour une entreprise de station-service, où vous payez une fois le voyage terminé, en fonction de la quantité d’essence que vous avez réellement utilisée. Lorsque vous transmettez votre transaction, l’une des premières étapes de validation consiste à vérifier que le compte dont elle provient dispose de suffisamment d’ether pour payer la limite gasPrice * gaz. Mais le montant n’est pas réellement déduit de votre compte tant que la transaction n’est pas terminée. Vous n’êtes facturé que pour le gaz réellement consommé par votre transaction, mais vous devez disposer d’un solde suffisant pour le montant maximum que vous êtes prêt à payer avant d’envoyer votre transaction.

Le destinataire d’une transaction est spécifié dans le champ to. Celui-ci contient une adresse Ethereum de 20 octets. L’adresse peut être une EOA ou une adresse de contrat.

Ethereum ne valide plus ce champ. Toute valeur de 20 octets est considérée comme valide. Si la valeur de 20 octets correspond à une adresse sans clé privée correspondante, ou sans contrat correspondant, la transaction est toujours valide. Ethereum n’a aucun moyen de savoir si une adresse a été correctement dérivée d’une clé publique (et donc d’une clé privée) existante.

L’envoi d’une transaction à la mauvaise adresse va probablement brûler l’ether envoyé, le rendant à jamais inaccessible (inutilisable), puisque la plupart des adresses n’ont pas de clé privée connue et donc aucune signature ne peut être générée pour le dépenser. On suppose que la validation de l’adresse se produit au niveau de l’interface utilisateur (voir [EIP55]). En fait, il existe un certain nombre de raisons valables pour brûler de l’ether - par exemple, pour dissuader de tricher dans les canaux de paiement et autres contrats intelligents - et puisque la quantité d’ether est finie, brûler de l’ether distribue efficacement la valeur brûlée à tous les détenteurs d’ether. (proportionnellement à la quantité d’ether qu’ils contiennent).

La "charge utile" principale d’une transaction est contenue dans deux champs : value et data. Les transactions peuvent avoir à la fois une valeur et des données, uniquement une valeur, uniquement des données ou ni valeur ni données. Les quatre combinaisons sont valides.

Une transaction avec seulement une valeur est un paiement. Une transaction avec uniquement des données est une invocation. Une transaction comportant à la fois de la valeur et des données est à la fois un paiement et une invocation. Une transaction sans valeur ni données - eh bien, ce n’est probablement qu’un gaspillage de gaz ! Mais c’est encore possible.

Essayons toutes ces combinaisons. Nous allons d’abord définir les adresses source et de destination de notre portefeuille, juste pour rendre la démo plus facile à lire :

Notre première transaction ne contient qu’une valeur (paiement) et aucune charge de données :

Notre portefeuille affiche un écran de confirmation indiquant la valeur à envoyer, comme indiqué dans Portefeuille de Parity montrant une transaction avec une valeur, mais pas de données.

L’exemple suivant spécifie à la fois une valeur et une charge utile de données :

Notre portefeuille affiche un écran de confirmation indiquant la valeur à envoyer ainsi que la charge utile des données, comme indiqué dans Portefeuille de Parity montrant une transaction avec valeur et données.

La transaction suivante inclut une charge utile de données mais spécifie une valeur de zéro :

Notre portefeuille affiche un écran de confirmation indiquant la valeur zéro et la charge utile des données, comme indiqué dans Portefeuille de Parity montrant une transaction sans valeur, uniquement des données.

Notre portefeuille affiche un écran de confirmation indiquant la valeur zéro, comme indiqué dans Portefeuille de Parity montrant une transaction sans valeur et sans données.

Un cas particulier que nous devrions mentionner est une transaction qui crée un nouveau contrat sur la chaîne de blocs, le déployant pour une utilisation future. Les transactions de création de contrat sont envoyées à une adresse de destination spéciale appelée adresse zéro ; le champ to dans une transaction d’enregistrement de contrat contient l’adresse 0x0. Cette adresse ne représente ni un EOA (il n’y a pas de paire de clés privée-publique correspondante) ni un contrat. Il ne peut jamais dépenser d’ether ou initier une transaction. Il n’est utilisé que comme destination, avec la signification spéciale "créer ce contrat".

Alors que l’adresse zéro est destinée uniquement à la création de contrats, elle reçoit parfois des paiements de différentes adresses. Il y a deux explications à cela : soit c’est par accident, entraînant la perte d’ether, soit c’est une brûlure d’ether intentionnelle (détruisant délibérément l’ether en l’envoyant à une adresse d’où il ne peut jamais être dépensé). Cependant, si vous souhaitez effectuer une brûlure intentionnelle d’ether, vous devez indiquer clairement votre intention au réseau et utiliser à la place l’adresse de brpulure spécialement désignée :

Une transaction de création de contrat ne doit contenir qu’une charge utile de données contenant le code intermédiaire compilé qui créera le contrat. Le seul effet de cette transaction est de créer le contrat. Vous pouvez inclure un montant en ether dans le champ value si vous souhaitez configurer le nouveau contrat avec un solde de départ, mais cela est entièrement facultatif. Si vous envoyez une valeur (ether) à l’adresse de création de contrat sans charge utile de données (pas de contrat), l’effet est le même que l’envoi à une adresse de brûlure : il n’y a pas de contrat à créditer, donc l’ether est perdu.

Par exemple, nous pouvons créer le contrat Faucet.sol utilisé dans [intro_chapter] en créant manuellement une transaction à l’adresse zéro avec le contrat dans la charge utile des données. Le contrat doit être compilé dans une représentation en code intermédiaire. Cela peut être fait avec le compilateur Solidity :

Les mêmes informations peuvent également être obtenues à partir du compilateur en ligne Remix.

Nous pouvons maintenant créer la transaction :

Il est recommandé de toujours spécifier un paramètre to, même dans le cas d’une création de contrat sans adresse, car le coût d’envoyer accidentellement votre ether à 0x0 et de le perdre pour toujours est trop élevé. Vous devez également spécifier un gasPrice et un gasLimit.

Une fois le contrat extrait, nous pouvons le voir sur l’explorateur de blocs Etherscan, comme indiqué dans Etherscan montrant le contrat miné avec succès.

Nous pouvons regarder le reçu de la transaction pour obtenir des informations sur le contrat :

Cela inclut l’adresse du contrat, que nous pouvons utiliser pour envoyer et recevoir des fonds du contrat, comme indiqué dans la section précédente :

Après un certain temps, les deux transactions sont visibles sur Etherscan, comme indiqué dans Etherscan montrant les transactions d’envoi et de réception de fonds.

Jusqu’à présent, nous n’avons pas approfondi les détails sur les signatures numériques. Dans cette section, nous examinons le fonctionnement des signatures numériques et comment elles peuvent être utilisées pour présenter une preuve de propriété d’une clé privée sans révéler cette clé privée.

Comme mentionné dans La structure d’une transaction, le message de transaction n’inclut pas de champ "from". En effet, la clé publique de l’expéditeur peut être calculée directement à partir de la signature ECDSA. Une fois que vous avez la clé publique, vous pouvez facilement calculer l’adresse. Le processus de récupération de la clé publique du signataire est appelé récupération de la clé publique.

Étant donné les valeurs r et s qui ont été calculées dans Mathématiques ECDSA, nous pouvons calculer deux clés publiques possibles.

Tout d’abord, nous calculons deux points de courbe elliptique, R et R^', à partir de la coordonnée x r valeur qui se trouve dans la signature. Il y a deux points parce que la courbe elliptique est symétrique sur l’axe des x, de sorte que pour toute valeur x il y a deux valeurs possibles qui correspondent à la courbe, une de chaque côté de l’axe des x.

À partir de r, nous calculons également r^-1, qui est l’inverse multiplicatif de r.

Enfin, nous calculons z, qui correspond aux n bits les plus bas du hachage du message, où n est l’ordre de la courbe elliptique.

Les deux clés publiques possibles sont alors :

et:

où :

Pour rendre les choses plus efficaces, la signature de la transaction inclut une valeur de préfixe v, qui nous indique laquelle des deux valeurs R possibles est la clé publique éphémère. Si v est pair, alors R est la valeur correcte. Si v est impair, alors c’est R^'. De cette façon, nous devons calculer une seule valeur pour R et une seule valeur pour K.

Une fois qu’une transaction est signée, elle est prête à être transmise au réseau Ethereum . Les trois étapes de création, de signature et de diffusion d’une transaction se déroulent normalement en une seule opération, par exemple en utilisant web3.eth.sendTransaction. Cependant, comme vous l’avez vu dans Création et signature de transactions brutes, vous pouvez créer et signer la transaction en deux étapes distinctes. Une fois que vous avez une transaction signée, vous pouvez ensuite la transmettre à l’aide de web3.eth.sendSignedTransaction, qui prend une transaction codée en hexadécimal et signée et la transmet sur le réseau Ethereum.

Pourquoi voudriez-vous séparer la signature et la transmission des transactions ? La raison la plus courante est la sécurité. L’ordinateur qui signe une transaction doit avoir des clés privées déverrouillées chargées en mémoire. L’ordinateur qui effectue la transmission doit être connecté à Internet (et exécuter un client Ethereum). Si ces deux fonctions sont sur un seul ordinateur, alors vous avez des clés privées sur un système en ligne, ce qui est assez dangereux. Séparer les fonctions de signature et de transmission et les exécuter sur différentes machines (sur un appareil hors ligne et en ligne, respectivement) est appelé signature hors ligne et est une pratique de sécurité courante.

Signature hors ligne des transactions Ethereum montre le processus :

Selon le niveau de sécurité dont vous avez besoin, votre ordinateur de "signature hors ligne" peut avoir différents degrés de séparation de l’ordinateur en ligne, allant d’un sous-réseau isolé et protégé par un pare-feu (en ligne mais séparé) à un système complètement hors ligne connu sous le nom de système air-gapped ou à espacement d’air . Dans un système à espacement d’air, il n’y a aucune connectivité réseau - l’ordinateur est séparé de l’environnement en ligne par un espace "d’air". Pour signer des transactions, vous les transférez vers et depuis l’ordinateur isolé à l’aide d’un support de stockage de données ou (mieux) d’une webcam et d’un code QR. Bien sûr, cela signifie que vous devez transférer manuellement chaque transaction que vous souhaitez signer, et cela n’évolue pas.

Bien que peu d’environnements puissent utiliser un système entièrement isolé, même un faible degré d’isolement présente des avantages significatifs en matière de sécurité. Par exemple, un sous-réseau isolé avec un pare-feu qui n’autorise qu’un protocole de file d’attente de messages peut offrir une surface d’attaque très réduite et une sécurité bien plus élevée que la signature sur le système en ligne. De nombreuses entreprises utilisent un protocole tel que ZeroMQ (0MQ) à cette fin. Avec une telle configuration, les transactions sont sérialisées et mises en file d’attente pour signature. Le protocole de mise en file d’attente transmet le message sérialisé, d’une manière similaire à un socket TCP, à l’ordinateur signataire. L’ordinateur signataire lit les transactions sérialisées à partir de la file d’attente (avec précaution), applique une signature avec la clé appropriée et les place dans une file d’attente sortante. La file d’attente sortante transmet les transactions signées à un ordinateur avec un client Ethereum qui les retire de la file d’attente et les transmet.

Le réseau Ethereum utilise un protocole de "routage par inondation". Chaque client Ethereum agit comme un nœud dans un réseau pair à pair (P2P), qui (idéalement) forme un réseau de toile. Aucun nœud de réseau n’est spécial : ils agissent tous comme des pairs égaux. Nous utiliserons le terme "nœud" pour désigner un client Ethereum qui est connecté et participe au réseau P2P.

La propagation de la transaction commence par la création (ou la réception hors ligne) par le nœud Ethereum d’origine d’une transaction signée. La transaction est validée puis transmise à tous les autres nœuds Ethereum qui sont directement connectés au nœud d’origine. En moyenne, chaque nœud Ethereum maintient des connexions avec au moins 13 autres nœuds, appelés ses voisins. Chaque nœud voisin valide la transaction dès qu’il la reçoit. S’ils conviennent qu’il est valide, ils en stockent une copie et le propagent à tous leurs voisins (sauf celui dont il provient). En conséquence, la transaction se répercute vers l’extérieur à partir du nœud d’origine, inondant à travers le réseau, jusqu’à ce que tous les nœuds du réseau aient une copie de la transaction. Les nœuds peuvent filtrer les messages qu’ils propagent, mais la valeur par défaut consiste à propager tous les messages de transaction valides qu’ils reçoivent.

En quelques secondes seulement, une transaction Ethereum se propage à tous les nœuds Ethereum du monde entier. Du point de vue de chaque nœud, il n’est pas possible de discerner l’origine de la transaction. Le voisin qui l’a envoyé au nœud peut être l’initiateur de la transaction ou peut l’avoir reçue de l’un de ses voisins. Pour pouvoir suivre l’origine des transactions ou interférer avec la propagation, un attaquant devrait contrôler un pourcentage significatif de tous les nœuds. Cela fait partie de la conception de la sécurité et de la confidentialité des réseaux P2P, en particulier lorsqu’elle est appliquée aux réseaux chaîne de blocs.

Bien que tous les nœuds d’Ethereum soient des pairs égaux, certains d’entre eux sont exploités par des mineurs et alimentent des transactions et des blocs vers des fermes minières, qui sont des ordinateurs dotés d’unités de traitement graphique (GPU) hautes performances. Les ordinateurs de minage ajoutent des transactions à un bloc candidat et tentent de trouver une preuve de travail qui rend le bloc candidat valide. Nous en discuterons plus en détail dans [consensus].

Sans entrer dans trop de détails, les transactions valides seront éventuellement incluses dans un bloc de transactions et, ainsi, enregistrées dans la chaîne de blocs Ethereum. Une fois minées dans un bloc, les transactions modifient également l’état du singleton Ethereum, soit en modifiant le solde d’un compte (dans le cas d’un simple paiement) soit en invoquant des contrats qui changent leur état interne. Ces modifications sont enregistrées parallèlement à la transaction, sous la forme d’un reçu de transaction, qui peut également inclure des événements. Nous examinerons tout cela beaucoup plus en détail dans [evm_chapter].

Une transaction qui a terminé son parcours depuis la création jusqu’à la signature par un EOA, la propagation et enfin l’exploitation minière a changé l’état du singleton et laissé une marque indélébile sur la chaîne de blocs.

Si vous connaissez les capacités de script de Bitcoin, vous savez qu’il est possible de créer un compte multisig Bitcoin qui ne peut dépenser des fonds que lorsque plusieurs parties signent la transaction (par exemple, 2 sur 2 ou 3 sur 4 signatures). Les transactions de valeur EOA de base d’Ethereum ne comportent aucune disposition pour les signatures multiples ; cependant, des restrictions de signature arbitraires peuvent être appliquées par des contrats intelligents avec toutes les conditions auxquelles vous pouvez penser, pour gérer le transfert d’ether et de jetons.

Pour tirer parti de cette capacité, l’ether doit être transféré dans un "contrat de portefeuille" programmé avec les règles de dépenses souhaitées, telles que les exigences de multisignature ou les limites de dépenses (ou des combinaisons des deux). Le contrat de portefeuille envoie ensuite les fonds lorsqu’il y est invité par un EOA autorisé une fois que les conditions de dépenses ont été remplies. Par exemple, pour protéger votre ether sous une condition multisig, transférez l’ether vers un contrat multisig. Chaque fois que vous souhaitez envoyer des fonds vers un autre compte, tous les utilisateurs requis devront envoyer des transactions au contrat à l’aide d’une application de portefeuille standard, autorisant effectivement le contrat à effectuer en finale la transaction.

Ces contrats peuvent également être conçus pour exiger plusieurs signatures avant d’exécuter du code local ou pour déclencher d’autres contrats. La sécurité du système est finalement déterminée par le code de contrat multisig.

La possibilité de mettre en œuvre des transactions multisignatures en tant que contrat intelligent démontre la flexibilité d’Ethereum. Cependant, c’est une épée à double tranchant, car la flexibilité supplémentaire peut entraîner des bogues qui compromettent la sécurité des schémas multisignatures. Il existe, en fait, un certain nombre de propositions pour créer une commande multisignature dans l’EVM qui supprime le besoin de contrats intelligents, du moins pour les simples schémas multisignatures M-de-N. Cela équivaudrait au système multisignature de Bitcoin, qui fait partie des règles de consensus de base et s’est avéré robuste et sécurisé.

Les transactions sont le point de départ de chaque activité dans le système Ethereum. Les transactions sont les "entrées" qui amènent la machine virtuelle Ethereum à évaluer les contrats, à mettre à jour les soldes et, plus généralement, à modifier l’état de la chaîne de blocs Ethereum. Ensuite, nous travaillerons avec des contrats intelligents de manière beaucoup plus détaillée et apprendrons à programmer dans le langage orienté contrat de Solidity.