It's a little more complicated than the following but
Please consider that I am not developer.
Ethereum transactions are signed by the sender. So, yes, msg.sender
is frequently relied upon to identify the user. Importantly, it is not under the sender's control and it reliably indicates the source of the funds and accompanying instructions, if any. The protocol uses mathematically reliable techniques to verify that the signature could only be from the msg.sender
, so that is a good indicator. It works. Enough said.
A smart contract can use msg.sender
to track its liabilities to each user, process deliverables back to them, etc. which is always designed on a case-by-basis basis. There are popular patterns for the most common use-cases.
Sending a token is a special case and possibly a little confusing because a token is a contract. Those contracts work like spreadsheets with accounts and balances and a few methods to transfer balances. When "Alice" sends "Bob" 1 token, she sends a transaction "to" the token contract's transfer
function indicating Bob should receive 1 token. Bob is not informed, at least not directly, and that is challenge that calls for a little extra cleverness. If Bob is a contract, it did not have a chance to react.
This is worked out with a two-step process.
Alice sends the token contract and approve
instruction that indicates "Bob" has an allowance that entitles him, the contract, to seize 1 token from Alice. In step two, she sends a transaction to Bob's buy
function. Bob will check the allowance to make sure there is enough money for whatever Alice wants to buy. If so, the allowance is consumed with a transferFrom
that comes from Bob. If not, then Bob should not take the funds and Alice should revert Bob's allowance back to 0. The choreography is typically handled by a user-interface that knows what step it is on.
Hope it helps.