Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement missing newPendingTransactions functionality for EVM space #2672

Open
waelsy123 opened this issue Apr 23, 2023 · 3 comments
Open
Assignees

Comments

@waelsy123
Copy link

waelsy123 commented Apr 23, 2023

Currently, the Conflux Rust implementation is missing the newPendingTransactions functionality for the EVM (Ethereum Virtual Machine) space. This feature is crucial for developers and users who rely on pending transactions for various applications and use cases. This issue aims to discuss and implement the newPendingTransactions functionality for EVM-compatible transactions in Conflux.

Motivation
Adding the newPendingTransactions feature for EVM space will provide the following benefits:

  1. Improve compatibility with Ethereum tooling and infrastructure.
  2. Enable developers to monitor and manage pending transactions effectively.
  3. Facilitate various applications and use cases that rely on pending transactions, such as DEXs, DeFi projects, and NFT marketplaces.

Requirements

To implement the newPendingTransactions feature, the following tasks need to be accomplished:

  1. Define the newPendingTransactions JSON-RPC method for the EVM space, including parameters, return types, and any required error codes.
  2. Implement the logic to track, store, and manage EVM-compatible pending transactions within the Conflux Rust codebase.
  3. Add tests for the new functionality to ensure correctness and reliability.
  4. Update the documentation to include the newPendingTransactions feature and provide examples of its usage.

Acceptance Criteria

The newPendingTransactions functionality is considered complete when:

  1. The JSON-RPC method is defined and implemented according to the specified requirements.
  2. The feature correctly tracks, stores, and manages pending EVM-compatible transactions within the Conflux Rust implementation.
  3. The new functionality is covered by adequate test cases.
  4. The documentation is updated to include the newPendingTransactions feature and its usage.

Notes

Please discuss any questions, concerns, or suggestions related to this issue in the comments below. Let's collaborate to implement this important feature for the Conflux EVM space. I can assign this task to me personally I just need technical guidance what's the best approach to achieve that.

@CRossel87a
Copy link

Hi,

Please consider prioritizing support for "newPendingTransactionsWithBody" instead of just "newPendingTransactions". With the ladder you only get the hash, which requires the user to do unnecessary calling of get_transaction to obtain the transaction struct (this burdens the node and adds lag). Primary users of this will be searchers

@peilun-conflux
Copy link
Contributor

Thanks for the interest!

newPendingTransactions has already been implemented in filter RPCs for eSpace (you can check new_pending_transaction_filter and filter_changes in rpc/impls/eth_filter.rs), so I guess we can use a similar method for the eth_pubsub. This implementation is a little bit inefficient though, because we keep an copy of all the transaction hashes in the transaction pool for each filter to find the differences.

Another thing worth noting is that this does not notify pending "phantom transactions" in eSpace, which are created by cross-space calls from core space transactions. I guess this is not an issue in most use cases here.

@waelsy123
Copy link
Author

thanks @peilun-conflux for the tip 🔥 , that's very helpful. You can assign this task to me, I will be working on it and will keep you in the loop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants