Ethereum Transaction Calls and State Changes

Let’s break down how different transaction calls work in Ethereum, and how state changes happen using a simple example🫣:

1. CALL

• Imagine Contract A wants to send 1 ETH to Contract B and run a function there.
• When Contract A makes the CALL:
• A new environment (EVM instance) is created for Contract B.
• msg.sender is Contract A, meaning Contract B knows who initiated the transaction.

• msg.value is set to 1 ETH (the amount being sent).

• State changes: Even though msg.sender is Contract A, any changes (like updating balances) happen in Contract B's storage, not Contract A’s.

2.STATICCALL

• Suppose Contract A only wants to check a balance in Contract B without changing anything.
• When Contract A uses STATICCALL:
• It’s just like CALL, but no changes are allowed—just reading data.
• msg.sender is still Contract A, but Contract B cannot change any state.

3.DELEGATECALL

• Now, let’s say Contract A wants to use Contract B’s code but with its own (Contract A’s) storage.
• When Contract A uses DELEGATECALL:
• Contract B’s code runs, but it affects Contract A’s storage.
• msg.sender: The original caller (EOA), not Contract A.

So In-short:

CALL: Contract A triggers changes in Contract B’s state.
STATICCALL: Same as CALL, but only reads data, no changes.
DELEGATECALL: Contract A runs Contract B’s code, but changes are made to Contract A’s storage.

Understanding these helps you see how smart contracts interact and manage state in #Ethereum. 💥