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 Sharded TxPool #161

Closed
terencechain opened this issue Jun 6, 2018 · 8 comments
Closed

Implement Sharded TxPool #161

terencechain opened this issue Jun 6, 2018 · 8 comments
Assignees
Milestone

Comments

@terencechain
Copy link
Member

We'll need to design and implement a sharding specific transaction pool. One prominent use case of the transaction pool is for the proposer to insert fake transactions. P2P implementation may want to use the receiving of test transactions in the transaction pool. This issue will have impact to proposer implementation as opened in #111

Some questions to answer:
What are the use cases?
How will it work?
Why is it necessary rather than a global TxPool with geth’s current implementation?

@terencechain terencechain added this to the Ruby milestone Jun 6, 2018
@rauljordan
Copy link
Contributor

Hey @terenc3t this is a duplicate of #153

@terencechain
Copy link
Member Author

Ah! My bad

@prestonvanloon
Copy link
Member

I don't think this is a duplicate of #153.

#153 outlines the work to create a service to broadcast "fake" transactions through the same mechanism that the P2P library would be broadcasting them within the application. In other words, #153 is supposed to be a stub for P2P that provides a stream of transactions for the proposer to use for development and testing.

It is then up to the proposer to decide where to put these transactions. It would likely be a transaction pool so that is why we have this issue.

@rauljordan
Copy link
Contributor

This should be very minimal for Ruby release and probably piggyback off #171. We want the simplest thing possible and it probably shouldn't do much more than what #171 already does.

@terencechain
Copy link
Member Author

I have written this tx pool design doc but it might be an over kill for Ruby release
https://docs.google.com/document/d/1Arh-7L61nt_iR8REOjrmzMKyu1ZxvzovZ3qOLdmxKRo/edit#

Let's strip it down and come back with a simpler design

@nisdas
Copy link
Member

nisdas commented Aug 17, 2018

Should we close this ? we do not really know right now what shards would look like and how a txpool would be used in a shard

@terencechain
Copy link
Member Author

This is still a very valid issue and can be implemented anytime. Proposer needs a txpool to store tx, it doesn't have to do with shards, it's just a priority queue. This is up to the client team to design

@terencechain
Copy link
Member Author

Let's close this in favor of a new one when ethereum/consensus-specs#90 gets finalized

Redidacove pushed a commit to Redidacove/prysm that referenced this issue Aug 13, 2024
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

4 participants