Read the 8 states that Ethereum transactions may experience in one article

Editor's Note: This article comes fromBlockchain Camp (ID: blockchain_camp)Editor's Note: This article comes from

Blockchain Camp (ID: blockchain_camp)

Blockchain Camp (ID: blockchain_camp)

, Author: dfuse, reproduced by Odaily with authorization.

Whenever a transaction is submitted to the Ethereum network, it goes through a rather complex series of states, and not every state transition is forward - the transaction may be rolled back to an earlier state, it may be replaced by another Transaction replacements, and possibly complete forks. (The lifecycle of a transaction is described in detail below.)

Tracking the progress of a transaction in a dapp and providing a good experience for users is challenging. Today, many Ethereum-based dapps can provide an attractive but still relatively static user experience: the application can display the transaction status at a certain point in time, but must be refreshed (click to refresh or the dapp UI periodically refreshes the page) to get the information update. There are relatively more dynamic interfaces on the market, but the data granularity provided is still not fine enough, or/while at the expense of high network traffic, it imposes a high load on its underlying blockchain nodes.

Next we discuss why this is the case, and how fine-grained transaction status updates in a network- and server-efficient manner can provide a smooth user experience in dapps that meets modern standards.

secondary title

Dapp Interfaces Today

Users often need to update information during the transaction (for example, to know when the transfer is completed), so the dapp will put a "refresh" button on the interface (or automatically refresh the page for the user periodically), or the user needs to directly click on the browser's Refresh button to get updates.

Some dapps with a more mature user experience will display dynamic updates of transactions to users. They poll AJAX requests in the background, double-check their Ethereum nodes for updates, and post the updates to the frontend. Doing so is complex because the dapp must make numerous API calls querying many different data sources (including blocks, mempools, and network conditions) in order to track the lifecycle of a transaction from start to finish.

This approach has disadvantages: either the transactions are updated infrequently and the information granularity is large, causing users to want to click "refresh" repeatedly to obtain updates faster; or the dapp must poll the blockchain frequently, resulting in a large number of Network traffic, which imposes a high load on the underlying blockchain nodes.

secondary title

• Why not use an on-chain event-based interface?

• For dapp developers, doing static pages or polling has been the only two options available, reflecting the nature of the API provided by Ethereum nodes. If there is an interface based on on-chain events, which can receive transaction status updates pushed to the chain and give real-time feedback to users, dapps can provide a better user experience-while standard Ethereum nodes do not provide rich real-time transaction data.

• Ethereum nodes do provide stream reading of on-chain events, but the functionality is limited and only available through PUB/SUB functionality using Ethereum's JSON-RPC interface (not available when using GraphQL). The PUB/SUB interface allows dapps to receive notifications for some event types:

• newHeads - every time a new block header is appended to the chain

newPendingTransactions - a hash of all transactions that entered the pending state and were signed by keys available in the node (and this is rare on public nodes)

syncing - Indicates when a node starts or stops syncing

secondary title

Ethereum transaction life cycle

Ethereum transactions have complex lifecycles. Each transaction will go through multiple states (states), undergo various state changes throughout the process, and may move forward or roll back.

• secondary title

• trading status

• From submitting an Ethereum transaction to entering a block (with a certain probability of success), it will go through a series of states as follows:

• UNKNOWN (Unknown): A transaction that has not been detected or processed by the network is defined as being in the UNKOWN state.

1. PENDING: Transactions are waiting to be picked and processed by miners in what we call the mempool. Miners usually choose transactions with higher gas prices first, so transactions with lower gas prices may be in the PENDING state for a long time. Transactions with the lowest gas prices may never be selected, which would leave them in the PENDING state indefinitely.

2. IN_BLOCK: When miners successfully select a transaction and process it into a block, the transaction will enter the IN_BLOCK state. If a transaction enters the IN_BLOCK state, but the block it was in forks, the transaction may return to the PENDING state.

Another transaction from the same sender with the same nonce enters the IN_BLOCK state, or

Another transaction from the same sender with the same nonce but a 12% higher gas price enters the PENDING state

The diagram below shows these states and the transitions between them.

• secondary title

• States transition

• As shown in the figure above, transitions between states are also defined by names.

• POOLED (into the pool): Transactions in the UNKOWN (unknown) state enter the transaction pool waiting for miners to choose, called POOLED and enter the PENDING (pending) state. A transaction in the REPLACED state, if the replacement condition is no longer true (for example: in rare cases, a transaction with a low gas price in IN_BLOCK is forked and replaces it with the same nonce and send If the transaction of the former is still floating on the network), it is also possible to change to the POOLED state again.

• MINED (mined): A mined transaction is a transaction processed by a miner, which creates a block. Once mined, a transaction is considered to be in the IN_BLOCK state. Due to the peer-to-peer nature of the Ethereum network, from the perspective of a designated node, a transaction can directly enter the IN_BLOCK state from the UNKNOWN (unknown) state without explicitly passing through the PENDING (pending) state. For the same reason, a transaction can also transition directly from the REPLACED state to the IN_BLOCK state without going through the PENDING state, monitored from the perspective of a given node.

FORKED (forked): When a mined transaction is in a block that has been revoked by the network, it is a forked transaction. All transactions in that block will be forked one after another, from the IN_BLOCK (incoming block) state back to the PENDING (pending) state.

CONFIRMED: A transaction in the IN_BLOCK state will be confirmed every time its subsequent sub-block is mined.

As mentioned above, the life cycle of transactions on Ethereum is very complex, which makes it difficult for dapps to accurately track it and provide seamless and smooth updates to users.

secondary title

Effortlessly track transaction status

The dfuse platform provides a rich interface capable of streaming monitoring, which supports real-time detailed tracking of the life cycle of Ethereum transactions. The dfuse Ethereum Transaction Status Tracker API enables developers to submit Ethereum transactions and then instantly get granular status updates on the same data channel, following the progress of the transaction throughout its lifecycle.

Using GraphQL, you can monitor changes in specified types of transactions in real time, and at the same time precisely specify the data you want to receive each time a transaction changes. The dfuse platform handles the complexities of tracking transactions and streaming them to dapps in real-time as events occur.

The animation below shows a transaction going through this complex lifecycle — it goes through eight state transitions before being included in a block and confirmed.

If dfuse is not used, the dapp must access the blockchain again and again to capture all the transitions experienced by the transaction and update it to the user, and the backend code needs to be prepared to deal with each state transition.

With dfuse, dapps only need to get streaming updates over a single connection, and dfuse will track the transaction for you through the various twists and turns until its fate is finalized.

• secondary title

• A Modern Platform for Advanced Dapps

• The Lifecycle API is only a small and important part of the dfuse platform. dfuse provides a complete modern infrastructure layer for dapps, namely:

• fast,

• Scalable,