Skip to content

msg.sender vs _msgSender() #50

@zcstarr

Description

@zcstarr

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions