Ethernet Square RPC Interface call Nonce

background

This is often the case when we use the ether-related JSON-RPC excuses to send a transaction: The transaction has been sent out and the hash value of the transaction has been obtained. Dev mode Geth is also in the normal mining, but the problem is that the transaction has not been confirmed. This type of interface can occur such as:

Eth_sendtransaction
eth_sendrawtransaction

So what causes the problem? Today we are going to take you through some of the causes of this problem. Problem Tracking

In addition to the above appearance problems, we can also progress to query the corresponding problem information.
(1) The occurrence of the above problem is often done through JSON API calls or other methods that are invoked via RPC, which are quickly confirmed if executed directly using console commands.
(2) through eth_gettransaction, we are ordered to inquire into the above transaction, but the transaction blocknumber used as null;
(3) by txpool.content name, we will see that the above transaction is in the queued queue, but is not processed.

The ultimate cause of the above phenomenon is that the Nonce value passed when the transaction was sent was incorrect. nonce Use Instructions

In order to prevent the transaction replay attack, each transaction must have a nonce random number, for each account nonce is starting from 0, when Nonce 0 of the transaction is processed, will deal with Nonce 1 of the transaction, and then add 1 of the transaction will be processed. Here are a few rules used by nonce: When the nonce is too small, the trade fair is directly rejected. When the nonce is too big, the fair is in the queue, which is the cause of the problem we described above; when sending a larger nonce value and then filling in the nonce between Nonce and the value, the transaction can still be executed. When the transaction is in the queue and the Geth client is stopped, the trade fair in the transaction queue is cleared away.

Knowing the above, you can find out if the transaction is due to the failure to send it successfully. Post Language

If you have any questions, leave a message or private contact. QQ Technology Group: 659809063. The Java version of the Geth Client API interface encapsulation and intelligent contract invocation is being written and perfected, and friends who need it can also be contacted.