Purpose of encoding
Encoding is really generic term. It basically means "creating byte representation of something more high level".
On a EVM level there is no functions and contracts. There is just bytes. Because of that, everything what you see as a contract, function, value, etc in Solidity, has to be encoded (create a sequence of bytes).
Encoding has to follow rules. There are different rules how to encode things in EVM, depending on what you are encoding. Transactions, for example, are encoded like this:
- first 4 bytes are function selector (F)
- rest are encoded parameters (P)
Raw transaction data does look like this:
You can read more about how to encode what in solidity docs: https://docs.soliditylang.org/en/v0.8.13/abi-spec.html
Now every time an EVM client receives a transaction, it can decode that raw transaction and know which function to call and what parameters to use.
Where to use it
If you are asking where is encoded used in EVM, then answer is everywhere. Everything has to be eventually represented with bits.
If you are asking where to use encoding as a Solidity developer, you will usually use it for creating raw transactions or manipulating values (e.g. when you want to contact two string together).
To answer your questions
- Encoding creates byte strings so EVM can understand it. Compiler generates opcodes from source code, encoding creates bytecodes from opcodes.
- It is one of the encoding rules. If you are encoding function parameters, you are padding them with zeros so they always takes 32 bytes. If you don't do that, it would be ambiguous if you encoded one big 32 bytes value of few smaller (e.g. one uint256 or two uint128).
- Function signature is string representation of function from which function selector can be created. Selector is basically first 4 bytes of function signatures hash (those first 4 bytes in raw transaction).
You can read about this topic in solidity docs: https://docs.soliditylang.org/en/v0.8.13/abi-spec.html#function-selector