Skip to content

waiting queue

When a transaction is submitted to the Ethereum network, it first enters the pending state, waiting for the node to execute it.

If the gas price in a transaction is set very low and the node is busy processing other transactions with higher gas prices, the transaction may remain pending for a longer period of time.

During the pending state, transaction initiators are allowed to change transaction fields at any time.

They can do this by sending another transaction with the same nonce.

Prerequisites to read

Daodst vs Ethereum

In Ethereum, pending blocks are generated when miners are queued for production.

These pending blocks consist of pending transactions picked by miners based on the highest gas reward paid.

This mechanism exists because block finality is not possible on the Ethereum network.

Blocks are committed with probabilistic determinism, meaning that over time (and blocks) transactions and blocks become less likely to be reverted.

Daodst is designed completely differently in this regard, as there is no concept of "pending state".

Daodst uses Tendermint Core BFT consensus to provide instant finality for transactions.

For this reason, Ethermint does not need to suspend the state mechanism, since all (if not most) transactions will be committed to the next block (the average block time on the Cosmos chain is about 8 seconds).

However, this causes problems with some Ethereum Web3 compatible queries, which may enter a pending state.

Another notable difference from Ethereum is that blocks are generated by validators, or block producers, who include transactions from their local mempool into blocks in a first-in-first-out (FIFO) fashion.

Transactions on Daodst cannot be ordered or picked from the Tendermint node mempool.

Pending status queue

Daodst will make queries to account for any unconfirmed transactions that exist in the node's transaction mempool.

Pending state queries made will be subjective and will be queried on the mempool of the target node.

So for the same query on two different nodes, the pending status will not be the same.

** JSON-RPC Calls on Pending Transactions **

  • [eth_getBalance]
  • [eth_getTransactionCount]
  • [eth_getBlockTransactionCountByNumber]
  • [eth_getBlockByNumber]
  • [eth_getTransactionByHash]
  • [eth_getTransactionByBlockNumberAndIndex]
  • [eth_sendTransaction]