msg.senderとtx.originの違いは何ですか？

Ethereumスマートコントラクトの実行の基本を理解する

Ethereumブロックチェーンでは、スマートコントラクトは、トランザクションや関数呼び出しを通じて、ユーザーやその他の契約と対話します。 Solidityを使用してスマートコントラクトを開発または分析する場合、 MSG.SenderとTx.Originの違いを理解することが不可欠です。どちらも、契約の実行中に住所情報を取得するために使用されるグローバル変数ですが、それらは異なる目的を果たし、さまざまなコンテキストで異なる動作をします。

MSG.Senderは、現在の関数の直接の発信者を指します。これは、外部所有のアカウント（EOA）または別の契約です。これは、契約との現在の相互作用を誰が開始したかを決定するために最も一般的に使用される変数です。

一方、 Tx.Originは、何回の中間呼び出しが発生したかに関係なく、トランザクションの元の送信者を表します。トランザクションチェーンを開始したEOAにまでさかのぼります。

MSG.Senderがスマートコントラクトでどのように機能するか

堅牢性契約の関数が呼び出されると、 msg.sender変数が関数を直接呼び出したアドレスに設定されます。これにより、アクセス制御または許可ベースのロジックで即時発信者を識別するための信頼できるソースになります。

例えば：

 pragma solidity ^0.8.0;契約例{




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

この契約では、 MSG.Senderは、現在の所有者のみがchangeOwner関数を呼び出すことができることを保証します。別の契約が他の誰かに代わってこの関数を呼び出す場合、 MSG.Senderは元のユーザーではなくその契約になります。

Tx.Originがスマートコントラクトでどのように機能するか

Tx.Origin変数は、複数の契約呼び出しが行われたとしても、トランザクション全体を開始した外部所有アカウント（EOA）を常に指しています。これは、特に複雑な契約相互作用において、トランザクションの背後にある元のユーザーを知る必要がある場合に役立ちます。

その動作を説明する例は次のとおりです。

 pragma solidity ^0.8.0;契約{




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

このシナリオでは、EOAが契約AからcallBを呼び出す場合、次のとおりです。

• MSG.SENDER INSIND checkOrigin()は契約Aのアドレスになります。
• Tx.Originは、トランザクションを開始したEOAになります。

この区別は、中間契約ではなく元のユーザーを知ることに依存するロジックを設計する場合に重要です。

Tx.originを使用することのセキュリティへの影響

Tx..originを使用すると、特定の状況でセキュリティリスクを導入できます。主な懸念事項の1つはフィッシング攻撃です。そこでは、悪意のある契約により、ユーザーは元の送信者に基づいて機密アクションを実行する関数を呼び出すようになります。

例えば：

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

}

悪意のある契約により、 trustedUserこの関数を呼び出すトランザクションを開始し、攻撃者がTx.Originに依存するチェックをバイパスできるようになります。

したがって、 Tx.Originを使用する特定の理由がない限り、アクセス制御にMSG.Senderを使用することを一般的に推奨します。

MSG.SENDERおよびTX.ORIGINの実用的なユースケース

MSG.Senderは、所有権チェック、アクセス制御、トークン転送などの標準的な契約関数で広く使用されていますが、 Tx.Originにはより多くのニッチアプリケーションがあります。

msg.senderを使用する場合：

• 誰が現在の関数を呼んだかを知る必要があります。
• onlyOwnerようなアクセス修飾子を実装しています。
• 不正な契約が契約と対話するのを防ぎたいです。

tx.originを使用して：

• トランザクションを開始する元のユーザーを特定する必要があります。
• 他の契約によってトリガーされるべきではないロジックを実装しています。
• 紹介プログラムや、直接ユーザーインタラクションを必要とするエアドロップなどのシステムを構築しています。

ただし、フィッシング攻撃に対する誤用と脆弱性の可能性があるため、 Tx.Originには常に慎重になります。

ベストプラクティスと推奨事項

スマートコントラクトを開発するときは、これらのベストプラクティスに従って、一般的な落とし穴を避けてください。

• 特に魅力的な理由がない限り、 tx.originよりもmsg.senderを好む。
• 契約のコールフローと、実行中のMSG.SENDERとTX.ORIGINがどのように変化するかを理解してください。
• 元の俳優がEOAであることを確認する必要があるシナリオでのみTx.Originを使用してください。
• Tx.originを使用するためにコードを監査し、不必要なリスクをもたらすかどうかを評価します。

MSG.SenderとTx.Originの間のニュアンスを理解することにより、開発者はより安全で予測可能なスマートコントラクトを書くことができます。

よくある質問

Q：msg.senderは契約アドレスになることができますか？はい、 msg.senderは、誰が関数を呼んだかに応じて、外部所有のアカウント（EOA）または契約アドレスのいずれかです。契約が別の契約で関数を呼び出す場合、 MSG.Senderは呼び出し契約のアドレスになります。

Q：tx.originは常にEOAですか？はい、 Tx.Originは常にトランザクションを開始した外部所有アカウント（EOA）です。複数の契約がコールチェーンに関与している場合でも、 Tx.Originは元のユーザーアドレスのままです。

Q：tx.originを操作できますか？ Tx.Originは直接偽造できませんが、フィッシング攻撃で悪用される可能性があります。たとえば、悪意のある契約により、ユーザーは意図しないアクションを実行するトランザクションをトリガーし、 TX.ORIGIN Checkに依存して承認を得ることができます。

Q：契約でtx.originの使用を避けるべきですか？絶対に必要な場合を除き、 Tx.originの使用を避ける方が一般的に安全です。セキュリティを妥協する方法で使用できるため、多くのベストプラクティスは、アクセス制御および状態を変える機能にMSG.Senderを使用することを推奨しています。