Feel free to refer directly to the yellow paper or other similar baseline documents - I've been reading those documents looking for an answer to my question. I wish there were a "language-lawyer" tag similar to the one on stackoverflow, because I'll only accept an answer that proves conclusively that the answer is "yes", "no", or "unspecified" - I won't accept an answer appealing to your gut feeling.

Solidity contracts appear to operate at a significantly higher level of abstraction than the EVM itself.

For instance, to determine which contract method a transaction executes, the ethereum wiki states:

The first four bytes of the call data for a function call specifies the function to be called.

Going back to the yellow paper to figure out what happens during a message call:

The account’s associated code (identified as the fragment whose Keccak hash is σ[c]_c) is executed according to the execution model.

Now, the associated code is simply the output of the contract creation code. The yellow paper also states:

...the resultant byte sequence from the execution of the initialisation code, specifies the final body code for the newly-created account

So in the yellow paper there is no mention of contracts even having methods, much less of the first 4 bytes of the transaction data specifying which one is to be called. I gather, therefore, that it is Solidity (or another layer above the EVM itself) that outputs contract EVM bytecode that branches based on the first 4 bytes, and this is not a feature of the EVM.

Therefore, this question is probably more related to Solidity than contract execution, and may even have a different answer case-by-case for different smart contracts that are implemented.

That being said, the question is this:

Take a look at this transaction. I created a well-formed call to a smart contract, sending 1 token to an address, however onto the transaction data I concatenated the hex data 0xdeadbeef. I would like to use this as a way to attach application-specific memos.

Given that this works today, is there any reason why it wouldn't work in the future?

  • As far as I understand too short and too long data payloads are accepted. This has resulted to the exchange bugs earlier in something called "address shortening attack" – Mikko Ohtamaa May 8 '18 at 7:29

The message attached to a contract invocation is meaningless for the EVM, a advantage/limitation of this approach is smart contract languages are not limited by a hypothetical EVM ABI and can define their own ABI.

The interpretation of the message depends on the contract itself, for solidity there's a ABI specification. I didn't analyze conclusively the solidity ABI encoding but in my tests the extra data is ignored. But the ABI has changed in the past and will likely change to add new features.

As stated by @MikkoOhtamaa one bug/feature that caused problems in the past is that if the message is too short the EVM will return 0 bytes without causing error if you request data beyond the length of the message.

| improve this answer | |

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.