Quelle est la différence entre Msg.Sender et Tx.origin?

Comprendre les bases de l'exécution du contrat intelligent Ethereum

Dans la blockchain Ethereum , les contrats intelligents interagissent avec les utilisateurs et autres contrats via des transactions et des appels de fonction. Lors du développement ou de l'analyse des contrats intelligents à l'aide de Solidity , il est essentiel de comprendre la différence entre Msg.Sender et Tx.origin . Les deux sont des variables globales utilisées pour récupérer les informations d'adresse pendant l'exécution du contrat, mais elles servent des objectifs distincts et se comportent différemment dans divers contextes.

MSG.Sender fait référence à l'appelant immédiat de la fonction actuelle. Il pourrait s'agir d'un compte détenu externe (EOA) ou d'un autre contrat. C'est la variable la plus couramment utilisée pour déterminer qui a initié l'interaction actuelle avec le contrat.

Tx.origin , en revanche, représente l'expéditeur d'origine de la transaction, quel que soit le nombre d'appels intermédiaires. Il revient à l'EOA qui a initié la chaîne de transactions.

Comment MSG.Sender fonctionne dans les contrats intelligents

Lorsqu'une fonction dans un contrat de solidité est appelée, la variable MSG.Sender est définie sur l'adresse qui a directement invoqué la fonction. Cela en fait une source fiable pour identifier l'appelant immédiat dans le contrôle d'accès ou la logique basée sur l'autorisation.

Par exemple:

 pragma solidity ^0.8.0; Exemple de contrat {


address public owner; constructor() { owner = msg.sender; } function changeOwner(address newOwner) public { require(msg.sender == owner, 'Only the owner can change ownership'); owner = newOwner; }
 }

Dans ce contrat, le MSG.Sender garantit que seul le propriétaire actuel peut appeler la fonction changeOwner . Si un autre contrat appelle cette fonction au nom de quelqu'un d'autre, Msg.Sender sera ce contrat, pas l'utilisateur d'origine.

Comment fonctionne tx.origin dans les contrats intelligents

La variable tx.origin pointe toujours vers le compte appartenant à l'extérieur (EOA) qui a lancé l'intégralité de la transaction, même si plusieurs appels de contrat sont effectués entre les deux. Il est utile lorsque vous avez besoin de connaître l'utilisateur d'origine derrière une transaction, en particulier dans les interactions contractuelles complexes.

Voici un exemple pour illustrer son comportement:

 pragma solidity ^0.8.0; contracter un {


function callB(B _b) public { _b.checkOrigin(); }
 }
 
contrat b {
 
function checkOrigin() public { emit LogOrigin(msg.sender, tx.origin); }
 }

Dans ce scénario, si un EOA appelle callB à partir du contrat A, alors:

• MSG.Sender Inside checkOrigin() sera l'adresse du contrat A.
• Tx.origin sera l'EOA qui a commencé la transaction.

Cette distinction est cruciale lors de la conception de la logique qui dépend de la connaissance de l' utilisateur d'origine plutôt que du contrat intermédiaire.

Implications de sécurité de l'utilisation de tx.origin

L'utilisation de tx.origin peut introduire des risques de sécurité dans certaines situations. L'une des principales préoccupations est les attaques de phishing , où un contrat malveillant intime les utilisateurs à appeler une fonction qui effectue des actions sensibles en fonction de l'expéditeur d'origine.

Par exemple:

 function transferFromUser(address to, uint amount) public { if (tx.origin == trustedUser) { // Perform transfer }

}

Un contrat malveillant pourrait inciter trustedUser à initier une transaction qui appelle cette fonction, permettant à l'attaquant de contourner les chèques qui reposent sur tx.origin .

Par conséquent, il est généralement recommandé d'utiliser MSG.Sender pour le contrôle d'accès, sauf si vous avez une raison spécifique d'utiliser Tx.origin .

Cas d'utilisation pratiques pour msg.sender et tx.origin

Bien que Msg.Sender soit largement utilisé dans les fonctions de contrat standard telles que les vérifications de propriété, le contrôle d'accès et les transferts de jetons, TX.Origin a plus d'applications de niche.

Utilisez Msg.Sender lorsque:

• Vous devez savoir qui a appelé la fonction actuelle.
• Vous implémentez des modificateurs d'accès comme onlyOwner .
• Vous souhaitez empêcher les contrats non autorisés d'interagir avec votre contrat.

Utilisez tx.origin lorsque:

• Vous souhaitez identifier l'utilisateur d'origine initiant la transaction.
• Vous implémentez une logique qui ne doit pas être déclenchée par d'autres contrats.
• Vous construisez des systèmes comme des programmes de référence ou des parachutistes qui nécessitent une interaction directe des utilisateurs.

Cependant, soyez toujours prudent avec Tx.origin en raison de son potentiel d'utilisation abusive et de la vulnérabilité aux attaques de phishing.

Meilleures pratiques et recommandations

Lorsque vous développez des contrats intelligents, suivez ces meilleures pratiques pour éviter les pièges courants:

• Préférez Msg.Sender à Tx.origin, sauf si vous avez une raison impérieuse de faire autrement.
• Comprenez le flux d'appel de vos contrats et comment le changement MSG.Sender et Tx.origin pendant l'exécution.
• Utilisez TX.origin uniquement dans les scénarios où vous devez vous assurer que l'acteur d'origine est un EOA.
• Audit votre code pour toute utilisation de Tx.origin et évaluez s'il introduit un risque inutile.

En comprenant les nuances entre MSG.Sender et Tx.origin , les développeurs peuvent écrire des contrats intelligents plus sûrs et prévisibles.

Questions fréquemment posées

Q: MSG.Sender peut-il être une adresse de contrat? Oui, Msg.Sender peut être soit un compte détenu externe (EOA), soit une adresse de contrat, selon qui a appelé la fonction. Si un contrat invoque une fonction dans un autre contrat, le MSG.Sender sera l'adresse du contrat d'appel.

Q: Tx.origin est-il toujours un EOA? Oui, Tx.origin est toujours le compte appartenant à l'extérieur (EOA) qui a lancé la transaction. Même si plusieurs contrats sont impliqués dans la chaîne d'appels, Tx.origin reste l'adresse utilisateur d'origine.

Q: Tx.origin peut-il être manipulé? Bien que Tx.origin ne puisse pas être forgé directement, il peut être exploité dans les attaques de phishing. Par exemple, un contrat malveillant peut inciter un utilisateur à déclencher une transaction qui effectue une action involontaire, en s'appuyant sur la vérification tx.origin pour l'autorisation.

Q: Dois-je éviter d'utiliser tx.origin dans mes contrats? Il est généralement plus sûr d'éviter d'utiliser tx.origin sauf si nécessaire. Étant donné qu'il peut être utilisé de manière à compromettre la sécurité, de nombreuses meilleures pratiques recommandent d'utiliser MSG.Sender pour le contrôle d'accès et les fonctions de changement d'état.