7

Is it true to say that if the first four bytes of an Ethereum's transaction does not contain one of the contract's encoded function calls, then the fallback function will be called?

In other words if contract A has two functions A::One and A::Two, and they encode to 0xabcdef12 and 0x12123a12, then does the fallback function call get called if any other input data (including none) is sent in a transaction?

Or would the transaction get rejected if it has non-zero (i.e. non-0x0) input data?

5

In Solidity, yes, if the first four bytes of an Ethereum's transaction does not contain one of the contract's encoded function calls, then the fallback function will be called.

Since contract code always runs when a contract gets a message, Solidity effectively featurized it into the fallback function.

Note that the Solidity compiler could have "disabled" the feature by generating EVM code that would always do nothing (just uses STOP opcode) or cause an exception if no function signatures match.

Would the transaction get rejected if it has non-zero (i.e. non-0x0) input data?

At the EVM level, the (input) data field of a transaction by itself has no effect on its validity (for example if a sender has sufficient balance to pay gas for the data, the transaction is valid and nodes should not reject). (Compilers or clients may have their own behavior depending on what they consider desirable or a feature for their users / use cases.)

More details

A very rough example, for conceptual purposes only, of the bytecode that an EVM compiler would produce:

method_id = first 4 bytes of msg.data
if method_id == 0x25d8dcf2 jump to 0x11
if method_id == 0xaabbccdd jump to 0x22
if method_id == 0xffaaccee jump to 0x33
other code <- Solidity fallback function code could be here
0x11:
code for function with method id 0x25d8dcf2
0x22:
code for another function
0x33:
code for another function

With such an example, the Solidity compiler might implement the fallback function code in the "other code" section above. Instead of "other code", to "disable" the fallback function, the Solidity compiler might just have used a STOP or an INVALID opcode.

Since fallback functions can be misused or abused, Vitalik Buterin suggested "establishing as a convention that fallback functions should generally not be used except in very specific cases."

  • 1
    Such a excellent answer. Thanks so much. If I could I would vote this answer of the year. – Thomas Jay Rush Feb 14 '17 at 4:25
  • 1
    I always thought it would be better if the fallback didn't exist, but now that it's not payable by default it's not so bothersome. It will fail if the fallback is not parable and it has ether. Is that right? – Thomas Jay Rush Feb 14 '17 at 4:27
  • 1
    Thank you. Correct, Solidity 0.4 made it so that a simple (zero input data) value transfer to a contract will cause an exception unless the contract's fallback function is payable. – eth Feb 14 '17 at 15:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.