Eth Transfer

ETH transactions are generally understood as transfer transactions, but this understanding is relatively narrow. The transaction mentioned here is a transaction in a broad sense.

Initiator of the transaction: mainly two types

1. Node serves, geth controls too.
2. Invoking node services mainly refers to clients that geth provides RPC interfaces, such as wallets.

Transaction classification: mainly two types

1. ETH transfer transaction
2. Other transactions, including transfer transactions not limited to ERC20 Token.

Transaction-related RPC interface: eth_sendTransaction And eth_sendRawTransaction

These two functions are distinguished by whether the caller needs to manually sign the final parameter

1. eth_sendTransaction: This function is only used for ETH transfers. The final signature of the parameters does not need to be manually performed by the caller. It will use the unlocked private key of the ETH address of the initiator from the current node to sign, so it needs to be called every time. When the function performs ETH transfer, the from address needs to be unlocked first.
2. eth_sendRawTransaction: A transaction function that requires the caller to use the private key of from to sign the parameter data. The current ERC20 Token transfer transactions use this function. This function can also be used for ETH transfer, but the transfer of ETH is mainly controlled by parameters.

Relationship between transactions and smart contracts

At the beginning, there is a narrow understanding of the transaction, which refers to the transaction (transfer) of the smart contract.
So, what is the relationship between the generalized transaction and the narrow transaction?
First of all, the transfer transaction first calls the RPC interface eth_sendRawTransaction, and passes the parameters required by the transfer transaction to the node. After the node gets the data, it extracts each data field, which contains the data parameter of eth_sendRawTransaction, and data is a hexadecimal character String, the content it consists of contains methodId , which corresponds to the named value of the transfer function.
Then, find the smart contract according to the to parameter, then find the function that refers to it based on the methodId of the data, and finally execute the function according to the parameters of the data such as who to transfer to and how much to transfer.
After the function is executed, regardless of the success or failure of the execution, a transaction hash value (full name is "Transaction Hash", txHash for short) will be returned

Explanation of transaction parameters

1. From
represents the address from which the transaction is initiated. If the to of the transaction is only the contract address, then the msg.sender variable in the contract code represents the from address of this address.
2.to
represents the receiving address of the current transaction. Note that the receiving address cannot be understood as the receiving address, because there are three situations for the value of to:

1. The address of the smart contract
   The transaction currently sent will be handed over to the corresponding smart contract for processing, the principle is the same as the ERC20 transfer. So when transferring ERC20 tokens, to should be the address of the smart contract.
2. The wallet address of ordinary ETH users
   is the ordinary ETH transfer, and to is the receiving address.
3. If the value is empty, the current transaction is a transaction that creates a smart contract,
   which means that the current transaction is a transaction that deploys a smart contract to the chain.

3.value: Transfer value
(1) When using eth_sendRawTransaction to transfer ERC20 Token, the value should be 0.
(2) When transferring ERC20 Token, the value to be transferred is defined in the data parameter.
(3) In When using eth_sendRawTransaction to transfer money, value must have a value, and this value is $10^{}$A large value in the form of${}^1$${}^8$$2\ast 10^{18.}$ Whenusing eth_sendRawTransaction for ETH transfer transactions, there are 3 points to note${}^{:}$

1. to should be the address of the receiving wallet
2. value corresponds to the value of ETH, not 0.
3. The data parameter is an empty string.

4. gas
This gas is gasLimit, but GasUser is used when the transaction is successful. When the transaction is successful, the extra gas fee will be returned, and the returned part is (gasLimit - GasUser)*gasPrice.

5. gasPrice
is the unit price, the unit is wei, which is a dynamic value.

6. The nonce
transaction sequence number is what prevents double spending.

7.data
This is a relatively important parameter, not only used in the transaction interface, but also used in eth_call.
The data format must meet the requirements:

1. hexadecimal format

0xa9059cbb0000000000000000000000007198ef99ac39c713ea1e333db4dc46c8b4413bf100000000000000000000000000000000000000000000000000000002cb417800

2. As above, the first 10 characters, including 0x, are methodId. Its generation method is more complicated. It is obtained by signing the name of the contract function, encrypting a specific number of bytes through Keccak256, and then converting it to hexadecimal. The following is the code for generating methodId according to the ETH version standard:

func (method Method) Id() []bety{
    
    
	return crypto.Keccak256([]byte(mothod.Sig()))[:4]
}

There are two methodIds corresponding to common functions:

• Query balance: balanceOf is 0x70a08231
• Transfer: transfer is 0xa9059cbb

3. The characters after the first 10 meet the following conditions

• Represents the parameters of the function in the smart contract
• The sorting method is arranged in the order of the contract parameters
• in hexadecimal form
• 0x is not allowed, that is, first convert to hexadecimal form and then remove the 0x character
• After removing 0x, the number of characters for each parameter is 64

举个栗子：
onMethod(arg1,arg2,....)
data的格式应该是
methodId + hex64(arg1) + hex64(arg2) + hex64(arg3) + ....

eth_sendTransaction({
    
    from:"0x...", to:"0x...",value=某数值)
最少三个参数

sendTransaction has been encapsulated by ETH. It can only be used to transfer ETH. It is essentially the same as sendRawTranscation. For the encapsulated sendTransaction, the data at this time is set as the auxiliary information for initiating the transaction, similar to a note.

The state of the transaction (lifecycle)

A total of four states

1. Unkonw (unknown state): It has not been put into the txPool ETH transaction pool. At this time, according to txHash, there is no information to use the block browser to query.
2. Pending (waiting or pending state): At this time, according to txHash, you can use the block browser to query, and you can query part of the transaction information
3. Success (success status): The transaction is successful, and any information about the transaction can be queried using the block browser according to txHash
4. Failed (failure status): The transaction failed, and the failure information and the reason for the failure were found by querying the block browser according to txHash

Because of the influence of the size of the ETH Pool, some orders will only be placed in the transaction pool and have not yet been traded. This state is called Unkwon (position state).
The reason for this is that the sorting algorithm of minter's trading orders in the trading pool is affected by GasPrice. Orders with high GasPrice will crowd out orders with low GasPrice, which may cause an order to be in Pending all the time, and may be put on hold for several days or even longer. (this situation has been encountered)

packaging of transactions

TIP: When minter packages a transaction, the step of "re-verifying the transaction" has a calculation step of a transaction gas fee inside, and the process of EVM gas calculation.