-
Notifications
You must be signed in to change notification settings - Fork 228
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
[FR] get_raw_tx_pool(true)
without **600 KB** overhead
#4636
Comments
Appendix A: response to the
|
Maybe we should add pagination to |
@eval-exec is your idea to add two optional parameters ( |
@phroi Thank you for your suggestion. |
@eval-exec @quake I was wondering, what's stopping someone from launching DDoS on conflicted txs? What are the countermeasures in place? |
there is a limit for conflicted txs lru cache: Line 30 in 18c68f5
|
Conflicted is capped at 10k, reasonable. This means a maximum network request overhead of 600 KB per |
This effectively kills fee estimation based on the current tx pool: sloshing around 600 KB of overhead for every Additionally, I'd like to point out that from the user/dev viewpoint it was a pretty big change (respectfully to the previous implementation), but that it is almost impossible to notice it from the RPC docs. |
get_raw_tx_pool(true)
without conflicted
txsget_raw_tx_pool(true)
without **600 KB** overhead
I personally dislike working with pagination in API requests in most scenarios. It aids one scenario but it doesn't solve it, then adds code complexity and overhead for other scenarios. The overhead of responses in different methods is never going to be perfect for all uses. Some developers will need high detail, and others will need lightweight responses with only some of the data. Perhaps a middleware approach to filtering responses would give a solution that is more flexible to developer needs. Consider a new RPC call called Example Query:
Example Response:
JSONPath Plus also supports ranges. Example Query:
Example Response:
If you're dealing with a large dataset that needs pagination and response consistency, another RPC call could be added called Example Query:
Example Response:
|
Yeah, fully agree on this 💯 {
"id": 42,
"jsonrpc": "2.0",
"method": "filter",
"params": ["get_raw_tx_pool", [true], "$.result.pending[*].fee"]
} Filtering the data right before sending it with a customizable filter, interesting!! Probably already exists a standardized filtering syntax 🤔 |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
Feature Request
conflicted
addition to theget_raw_tx_pool(true)
is a welcomed new addition to the CKB node API, also it creates an issue evident by calling:curl -X POST https://mainnet.ckbapp.dev/ -d '{"jsonrpc":"2.0","method":"get_raw_tx_pool","params":[true],"id":42}'
Is your feature request related to a problem? Please describe.
get_raw_tx_pool(true)
in the latest node versions also returns theconflicted
txs. While generally speaking more information is better, in this caseconflicted
txs seems to have a low utility for most use-cases.In this case in particular, low utility data is two orders of magnitude bigger than the crucial data:
pending
andproposed
txsconflicted
txsDescribe the solution you'd like
Either:
get_raw_tx_pool(true)
and add a second parameter to include themget_raw_tx_pool(true, true)
, second parameter which defaults tofalse
.conflicted
txs, likeget_raw_tx_pool(true, false)
, second parameter which defaults totrue
.The text was updated successfully, but these errors were encountered: