Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

msg.sender vs _msgSender() #50

Open
zcstarr opened this issue Jun 5, 2023 · 1 comment
Open

msg.sender vs _msgSender() #50

zcstarr opened this issue Jun 5, 2023 · 1 comment

Comments

@zcstarr
Copy link

zcstarr commented Jun 5, 2023

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 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.

@ogarciarevett
Copy link
Contributor

Amazing! Thanks for sharing this, adding the modification to the next version and testing it right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants