Ethereum Transactions Content

Question

I am new in ethereum blockchain and I am trying to understand completely how it works.

I have read this document, but there are still some points which are not obvious to me. One of these points is about transactions. In other words, I can't understand the exact structure and content of a transaction in ethereum.

As far as I am concerned, we have two types of accounts in ethereum. Regular accounts (Externally Owned Accounts - EOA) and contract accounts. Each account is identified by its address.

So, when we want to transfer some amount of money from EOA1 to EOA2 the transaction structure is:

• Sender Id: Address of EOA1
• Reciever Id: Address of EOA2
• Amount of money: for example 1 Ether

But how about a contract transaction? For example, Suppose we have a contract with address A which has a function named Func1. So, when we call Func1 a transaction is created. But what is the content of this transaction?

these are the fields:

• Invoker id
• Contract address: In this case A
• Gas price
• Total cost = gasUsed * gasPrice

Is this correct?

Answer 1

There's plenty of data in a single Ethereum transaction. You can have a look at Etherscan which shows for example transactions. There's a breakdown of the data here: https://99bitcoins.com/how-to-read-ethereum-transactions/ .

When calling a contract, one important field is the "Input data" field. This is the "extra data" part which can be included in transactions and can contain arbitrary data. This is the part where the function to be called is written and the parameters, for example. In non-contract transactions this field is typically pretty much empty, except nothing stops you from adding data to it also then.

Input data field

As said, the input data field is where all the data is stored about function calls. Let's have an example: a random transaction of the Binance token (BNB): https://etherscan.io/tx/0x8a2d7289c32246db38196e8a18f5a029ed5c96a528d469af9594310dc3f1e293

Etherscan gives us the following data (one of the formats):

Function: transfer(address _to, uint256 _value)

MethodID: 0xa9059cbb
[0]:  0000000000000000000000003f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be
[1]:  00000000000000000000000000000000000000000000010f0cf064dd59200000

The MethodID is signature of the function to be called. The function takes two parameters, so there are two string representing the provided parameter values. All the values are encoded in hexadecimal format. The first line gives us a readable name for the function to be called (this name can be decoded from the MethodID).

In reality, the data is of course not in such human-friendly format. If you switch to the "original" view in Etherscan, you see the data is in full:

0xa9059cbb0000000000000000000000003f5ce5fbfe3e9af3971dd833d26ba9b5c936f0be00000000000000000000000000000000000000000000010f0cf064dd59200000

Etherscan opens that data to be more human-friendly.