[FR] get_raw_tx_pool(true) without **600 KB** overhead
#4636
Labels
b:rpc
Break RPC interface
m:tx-pool
s:discussion-needed
Status: Need to Discuss
t:enhancement
Type: Feature, refactoring.
Comments
Appendix A: response to the
|
eval-exec
added
b:rpc
|
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. |
phroi
changed the title
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 🤔 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Feature Request
conflictedaddition 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 theconflictedtxs. While generally speaking more information is better, in this caseconflictedtxs 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:
pendingandproposedtxsconflictedtxsDescribe 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.conflictedtxs, likeget_raw_tx_pool(true, false), second parameter which defaults totrue.The text was updated successfully, but these errors were encountered: