The Status of An Ethereum Transaction And How To Navigate Them Using Dfuse

Tram Ho

Above is an image depicting the lifecycle of a transaction on the Ethereum blockchain network. Usually we only send transactions, we can see how they are actually processed, right? Today I will talk more clearly about the state that a transaction after being posted on the Ethereum network will be handled before being added to the chain.

So whenever a transaction is posted, the network receives it and processes it by moving the transaction to different states. This can visualize these states as stairs, after passing through them they will be accepted and put into the chain. But not always the state of the transaction is always changed to move forward, sometimes there are cases when it is reversed to the previous state, replaced by another transaction or can be removed. completely.

Currently dapps enhance the user experience by showing the status of transactions just like realtime, helping users not to refresh the status while waiting for it to be processed. But they are actually just using that manually. After a certain amount of time, they send requests online to get the status. This sometimes causes quite a lot of bandwidth and sometimes slows down the application. In the following article, in addition to analyzing the status of transactions, I will introduce a solution to the problem of tracking the state of transactions that is Dfuse .

Lifecycle of Ethereum Transaction

Transaction States

Here are the states where trasaction can occur:

  • UNKNOWN : A new transaction that has been sent to the network, has not been reviewed and processed will be in UNKNOWN state
  • PENDING : A transaction is in PENDING state when it is waiting to be selected and processed by miners. They are in so-called mempool , miners often choose transactions with higher gas prices than before, so transactions with lower gas prices can stay PENDING for a long time. There are many cases where these low price gas transactions are never chosen, which results in them being permanently stuck in PENDING state.
  • IN_BLOCK : A transaction switches to IN_BLOCK state when a miner selects it and puts it in the block. However, in this state the transaction can also be reverted to PENDING state if the block containing it is forked.
  • REPLACED : A transaction may transition to the REPLACED state from the PENDING state when one of the following occurs:
    • In the first case, there are 2 transactions with the same sender and the same number of nonce are put into PENDING state, but then there is one transaction put into IN_BLOCK state first, the remaining block will be moved into REPLACED state.
    • If the second case is also two transactions with the same sender and the nonce number is put into PENDING state but there is a transaction with a gas price higher than 12%, the transaction with a lower gas price will be put into the REPLACED state.

To illustrate, let’s look at the transaction lifecycle diagram:

State Transitions

In the previous section, we talked about the state of the transaction, so in order to switch to different states, we need to have events, in this section we will talk about these events:

  • POOLED : A transaction in the UNKNOWN state will be put into the pool containing the transactions and wait there until the miners select it called POOLED and switch to PENDING state. It is also possible that a transaction is in the REPLACED state and is POOLED again, if its Replace conditions are no longer true (for example, in the rare event that a transaction in the IN_BLOCK state is forked and in a state of REPLACED then had a transaction with the same sender and nonce number and had a higher gas price still hovering there. It would then be POOLED again to put it into PENDING status)
  • MINED : mined is the process of a transaction that has been processed by the miner and put into the block. Once mined, the transaction will be in state IN_BLOCK . Due to the peer-to-peer nature of the ethereum network, a transaction state can transition directly from the UNKNOWN state to IN_BLOCK state without going through PENDING state. Similarly, there is a case where a transaction in the REPLACED state can be mined and then switched to the IN_BLOCK state without going through the PENDING state.
  • REPLACED : A transaction transitions from PENDING state to REPLACED state thanks to the Replace event. As for REPLACED state, we have mentioned the two cases above
  • FORKED : A transaction is forked when that transaction has been mined to the IN_BLOCK state and put into the block, but this block is later reversed by the network, the transactions in that block will be brought back to the PENDING state. This process is called forked. .
  • CONFIRMED : A transaction in the state IN_BLOCK is confirmed every time a subsequent block is mined.

As we can see, the life cycle of an Ethereum transaction is quite complex, which can make it difficult for dapps to track transaction status and forward it to users.

Event-driven interface

The approach of many pages and dapp is usually to track transactions and then display them to the user. It runs in the background after how many seconds it will invoke the Ethereum node to retrieve the status of the transaction and display it, making users still think it is realtime. But actually standard Ethereum nodes are not designed to provide streaming realtime data of transactions. And here we have the concept of event-driven interface, which is the interface that will receive updates pushed from the blockchain network and display them to users in realtime to increase the user experience. Unknowingly, the manual methods we mentioned above are against the concept of the event-driven interface and sometimes it reduces the user experience because it will cause bandwidth congestion in the case of many users. use.

The solution mentioned here is to use the PUB / SUB capability of Ethereum’s JSON-RPC interface. The PUB / SUB interface allows subscribers to subscribe to receive notifications of the following events:

  • newHeads : every time a new block header is added to the string
  • logs : these logs will include information about newly added blocks and information matching the pre-defined filters.
  • newPendingTransactions : the hash value of all transactions added to the pending state and signed by the key available in the node (this rarely happens in public nodes)
  • syncing : this event indicates when the node starts or stops synchronizing data

For more details, read here . These events will allow the dapp to track a transaction through the lifecycle more smoothly.

Easily track the status of transactions with dfuse

Dfuse Platform is a platform that provides streaming interface services that support the lifecycle tracking of Ethereum transactions in realtime. The Dfuse Ethereum State Tracker API will allow developers to post transactions on the platform and then it will track the status of this transaction and send back immediately when there is a status change. All of this is done on the same channel and throughout the lifecycle of the transaction.

Using GraphQL, we can subcribe a transaction to track and determine which data we want to receive when there is a change in the state of the transaction. This dfuse platform will make it easier to manage complicated tracking transacion jobs now, because when the transaction has any status changes it will immediately send it back to the dapp to show for This is really true of the event-driven interface concept.

Below we will have an image to better describe the complexity of state transitions. As an example of this transaction, it must go through 8 new state transitions to the stage to be confirmed.

If previously we would need to build a dapp with background running to constantly call the network node to get the latest information. Now, with the use of dfuse, we only need to listen for new updates from the stream data we have connected, the rest of the dfuse has to take care that it will track and send it until the transaction has been confirmed.


And so we have a more detailed view of the states that a transaction will experience in a lifecycle. Along with that is the definition of an event-driven interface and that solution is dfuse. This article I just introduced this guy dfuse and I will write one more article about how to use this guy. Thank you for your interest in reading, it is great fun and see you again in the next post

Source: dapp
Share the news now

Source : Viblo