You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our implementation of Diamond Standard EIP-2535, I've noticed a consistent pattern of directly using msg.sender instead of a more versatile _msgSender() function. This direct usage of msg.sender could potentially lead to unexpected behavior.
Detailed Explanation
The Solidity language provides a msg.sender keyword that delivers the address of the function's direct caller. However, in contexts of proxies and delegatecall, directly using msg.sender can be misleading.
The Diamond Standard (EIP-2535) uses delegatecall extensively for executing facets. Here, msg.sender in a function called via delegatecall returns the immediate caller (i.e., the proxy contract), not the original caller (which is the EOA or the contract that triggered the transaction).
This is where _msgSender() comes in. This function cleverly determines the correct original caller even in the context of delegatecall. It's designed to be compatible with various proxy patterns, including the transparent proxy pattern and meta-transaction designs.
I'll make a PR that follows this pattern.
The text was updated successfully, but these errors were encountered:
Issue Description
In our implementation of Diamond Standard EIP-2535, I've noticed a consistent pattern of directly using
msg.sender
instead of a more versatile_msgSender()
function. This direct usage ofmsg.sender
could potentially lead to unexpected behavior.Detailed Explanation
The Solidity language provides a
msg.sender
keyword that delivers the address of the function's direct caller. However, in contexts of proxies and delegatecall, directly usingmsg.sender
can be misleading.The Diamond Standard (EIP-2535) uses delegatecall extensively for executing facets. Here,
msg.sender
in a function called via delegatecall returns the immediate caller (i.e., the proxy contract), not the original caller (which is the EOA or the contract that triggered the transaction).This is where
_msgSender()
comes in. This function cleverly determines the correct original caller even in the context of delegatecall. It's designed to be compatible with various proxy patterns, including the transparent proxy pattern and meta-transaction designs.I'll make a PR that follows this pattern.
The text was updated successfully, but these errors were encountered: