newPendingTransactions only return already validated transactions

[Percronos]

Hey team,

The JSON-RPC method newPendingTransactions is always returning batch of confirmed transactions while it should return unconfirmed transactions.

To Reproduce

1. Add the txpool api in the JSON RPC configuration part of the app.toml file: api = "eth,net,web3,txpool"
2. Connect to ws: wscat -c ws://localhost:8546
3. Run the method: {"jsonrpc":"2.0", "id": 1, "method": "eth_subscribe", "params": ["newPendingTransactions"]}
4. 100% of the displayed transactions have been validated several seconds ago. They all appear as a batch (seems to be at each new block validation).

Expected behavior The JSON-RPC method newPendingTransactions should return unconfirmed transactions.

This example comes from a node connected to more than 150 peers, tested on v0.6.6 to v0.6.9

Thanks

[romeroandalusia]

@thubertparis I am pretty sure that this was already analyzed by the ethermint team and they found out that it could not be implemented in practice.

[eniolasonowo]

I am experiencing the same issue. ` _Provider.on("pending", (tx) => { console.log(tx) _Provider.getTransaction(tx).then(function (transaction) { console.log(transaction); });

});`

It returns only confirmed tx.

[huahuayu]

@yihuang Would you please clarify this, only validator gets the new pending tx?

[yihuang]

@yihuang Would you please clarify this, only validator gets the new pending tx?

Yes, the event is translated from the tendermint websocket subscription tm.event='Tx', so it's confirmed tx, not mempool tx. And the tm websocket subscription seems don't support monitor mempool tx. https://docs.tendermint.com/master/tendermint-core/subscription.html

[huahuayu]

Ok, so this is my understanding:

1. Ordinary node only receives confirmed tx
2. Pending txs is broadcast between validators, so validators can read mempool in theory?
3. But even for validators, there is no subscription method to read it, one needs to implement it by themselves?

Am I right?

[soltrac]

@romeroandalusia

Thats not possible, because okexchain has a custom tendermint implementation and they do it, you there can read non validated transactions without any problem. Also, I've noticed some arbitrage bots manage to put the transaction on the same block they are backrunning, so someone has managed to implement it. I'm not sure if they are validators or not.

@huahuayu I'm not sure if validators have this problem or not, but it is real that if you read mempool (with filters or suscription), you cannot read transactions before they are inserted in the block, only after that. The thing is, I'm not sure if it is a ethermint problem or your custom implementation, because I've connected to EVMOS testnet and there I can read non validated transactions, so maybe it is a Cronos only problem. I've trying to find differences in the code between ethermint and your custom implementation and I don't see differences.

[yihuang]

The eth_pendingTransactions api can return tx in mempool no matter validator node or normal node, it's just the websocket subscription don't.

[soltrac]

The eth_pendingTransactions api can return tx in mempool no matter validator node or normal node, it's just the websocket subscription don't.

I meant eth_newPendingTransactionFilter. That one is not giving non validated transactions.

[yihuang]

The eth_pendingTransactions api can return tx in mempool no matter validator node or normal node, it's just the websocket subscription don't.

I meant eth_newPendingTransactionFilter. That one is not giving non validated transactions.

that one is same as the websocket subscription, have you tried cronos testnet? mainnet is lag behind on many new changes. it should be the same as evmos, unless I miss sth.

[soltrac]

The eth_pendingTransactions api can return tx in mempool no matter validator node or normal node, it's just the websocket subscription don't.

I meant eth_newPendingTransactionFilter. That one is not giving non validated transactions.

that one is same as the websocket subscription, have you tried cronos testnet? mainnet is lag behind on many new changes. it should be the same as evmos, unless I miss sth.

I've just tested cronos testnet with "wss://cronos-testnet-3.crypto.org:8546" and it is doing the same thing, only reading already validated transactions included already in the block.

[Percronos]

The eth_pendingTransactions api can return tx in mempool no matter validator node or normal node, it's just the websocket subscription don't.

I meant eth_newPendingTransactionFilter. That one is not giving non validated transactions.

that one is same as the websocket subscription, have you tried cronos testnet? mainnet is lag behind on many new changes. it should be the same as evmos, unless I miss sth.

I've just tested cronos testnet with "wss://cronos-testnet-3.crypto.org:8546" and it is doing the same thing, only reading already validated transactions included already in the block.

Yes, I also tested it a few days ago, same behavior.

[huahuayu]

The eth_pendingTransactions api can return tx in mempool no matter validator node or normal node, it's just the websocket subscription don't.

So how do u think, it's a bug or a solid feature?

[soltrac]

It is a bug. Asking the mempool about pending transactions should return pending transactions, not already included in block transactions.

[huahuayu]

I do think so, what's more, what the RPC can do the websockets should have no problem.

[tokinaa]

Sorry, or maybe my question is OOT for this thread.

But, someone get stuck if we use mempool / pending transactions ? i got that stuck after 30min-1hours. And then, mempool isnt running again. but log still runinng.

[huahuayu]

Sorry, or maybe my question is OOT for this thread.

But, someone get stuck if we use mempool / pending transactions ? i got that stuck after 30min-1hours. And then, mempool isnt running again. but log still runinng.

You'd better open a new issue and describe the problem in detail, how to reproduce it, and provide necessary logs.

[Percronos]

Hey @yihuang ,

Do you think it's an expected behavior, or do you know if it can be fixed in the future ?

Thanks

[silvercondor]

suggest disabling this wss endpoint to prevent further confusion.

main issue is upstream on tendermint as yihuang has previously mention

[eeldivad]

hey @soltrac I tested this on evmos testnet evmos_9000-4 as well as my cronos mainnet validator and it's the same behavior. the tx comes in batches rather than realtime. what version of evmosd are you using on evmos testnet? I would like to compare and see why it's not working for me there. do you have a public ws URL i can test with for evmos testnet?

[eeldivad]

hey @soltrac I tested this on evmos testnet evmos_9000-4 as well as my cronos mainnet validator and it's the same behavior. the tx comes in batches rather than realtime. what version of evmosd are you using on evmos testnet? I would like to compare and see why it's not working for me there. do you have a public ws URL i can test with for evmos testnet?

[yihuang]

I think this is expected behavior for foreseeable future, closing now.