[ZK Stack] - Transactions stuck in mempool

[coffeexcoin]

Team or Project

Abstract

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

N/A

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

I am unable to send transactions on abstract testnet with address 0x6f6426a9b93a7567fCCcBfE5d0d6F26c1085999b

I have attempted to send multiple transactions, each with an increasing gas fee. The node returns a transaction hash but it is never included in a block. Attempting to rebroadcast the same transaction errors with "'Execution reverted with reason: known transaction. transaction with hash 0x2789…e775 is already in the system."

cast tx --rpc-url "https://api.testnet.abs.xyz" 0x2789f5cde66bc3f17147ccb81501c96dfe7302e9c3adc41e30fe3619b07fe775 shows that the transaction is in fact in the system but is not included in a block.

blockHash            
blockNumber          
from                 0x6f6426a9b93a7567fCCcBfE5d0d6F26c1085999b
transactionIndex     
effectiveGasPrice    25000000000

hash 0x2789f5cde66bc3f17147ccb81501c96dfe7302e9c3adc41e30fe3619b07fe775
type 2

chainId              11124
gas                  2000000
gasPrice             25000000000
input                0x574caef3b4f00c557f07b837f050873c2c1bd703781c37761c3b2d746ab9b2cae3d8d96b00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000144b4e581f50000000000000000000000005768560f0e24f188b44d274eaf1007ab4b3f66bc0000000000000000000000001af85e1c3501b66987689a5684be20da2443fb44000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
maxFeePerGas         25000000000
maxPriorityFeePerGas 0
nonce                819
r                    30481685095216287765165536989597171331764378802825693297276472541672055599570
s                    23461137952758455175043236462325182535929996360844619489352420967439874613113
to                   314365700007676484555058580571416115247086978996
v                    1
value                0

Expected Behavior

Transactions are included in a block when broadcast

Current Behavior

Transactions are not included in a block

Repository Link (if applicable)

No response

Additional Details

No response

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[gleenai[bot]]

It appears that your transaction is stuck in the mempool on the Abstract Testnet. This can happen for several reasons, such as network congestion or issues with the node itself. Here are a few steps you can take to troubleshoot and potentially resolve the issue:

1. Check Network Status: Verify if there are any known issues on the Abstract Testnet that could be affecting transaction processing. Sometimes, network-wide problems can cause transactions to remain stuck.

2. Increase Gas Fee: Although you've mentioned increasing the gas fee, ensure it is competitive enough to be picked up by miners. You might want to check the current average gas price on the network and adjust accordingly.

3. Nonce Management: Ensure that the nonce of your transaction is correct. Transactions might get stuck if there's a nonce gap or if the nonce used is incorrect.

4. Contact Support: If the issue persists, consider reaching out to the support team of the Abstract Testnet or the community forums for more targeted help.

Since this involves a specific testnet and detailed transaction behavior, these general steps are the best first approach. If you need further assistance, please provide additional details or errors you might be encountering.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[coffeexcoin]

AHA - There was a nonce gap - transaction was sending as 819 instead of 818.

Is there a reason the node does not reject this as an invalid nonce?

[gleenai[bot]]

In blockchain systems, nodes typically do not reject transactions with higher nonces outright because they anticipate that transactions with intervening nonces may still be broadcast. This is especially true in systems where transactions from a single account are not processed in strict order due to network delays or the asynchronous nature of transaction submissions.

Here’s why the node might not reject a transaction with a nonce gap:

1. Pending Transactions: The node might be waiting for transactions with lower nonces to be submitted. This is common in scenarios where transactions are sent out of order.

2. Mempool Management: Nodes maintain a pool of unconfirmed transactions (mempool). A transaction with a higher nonce can stay in the mempool in anticipation that missing nonce transactions will arrive and can be processed in sequence.

3. Flexibility for Users: Allowing transactions with future nonces gives users the flexibility to send transactions asynchronously without waiting for each one to be confirmed before sending the next.

To avoid such issues, it's crucial to manage nonces carefully, especially when sending multiple transactions in quick succession or retrying transactions that failed to broadcast initially. Always ensure that the nonce for each new transaction is exactly one more than the nonce of the account's last confirmed transaction.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.