Best Practices
Success Rate Definition
We present users with a more stringent success rate measurement. Any request that does not receive the expected response is considered unsuccessful in our statistics. This includes, but is not limited to:
Any request that triggers BlockPI RPC restrictions, including rate limits, block range limitations, data size limitations, etc.
Any error directly returned from the node, such as non-existent methods, incorrect parameters, missing parameters, etc.
Others, such as timeout error.
Using Archive Mode
BlockPI Network RPC service allow users to set their endpoint to be with different features, such as Archive mode.
When the archive mode is on for a specific endpoint, the requests sent to this endpoint will be routed to archive nodes. And it typically takes a longer time to process due to the huge amount of data.
In this case, you would need to generate two endpoints:
one for handling regular requests.
another with Archive mode enabled exclusively for processing requests that require archive data. And send requests based on conditions.
Here is an example:
Segment Block Range in eth_getLogs
Here is another one with using the eth_getLogs. As the method consumes decent sever resource.
Our limit on eth_getLogs block range are as follows: if no parameters are included, a single eth_getLogs request is limited to 1024 blocks. If the request includes either the topic parameter or the address parameter, the limit is set to 5000.
If users need to query a block range more than this limit, you can segment it to multiple requests with certain blocks each.
Websocket Reconnection
To safeguard the system, each RPC provider sets a periodic disconnection (timeout) for WebSocket connections. In the case of BlockPI, the timeout is set to 30 minutes. Therefore, during development, users need to implement a mechanism to detect and handle reconnection when the connection is dropped. Here is a Python example:
Please note that this is just a sample code, and you may need to adapt it to your specific development environment and requirements.
HTTP Batch Call
What is a Batch Call?
A batch call is a JSON-RPC method that bundles multiple requests (like eth_call or eth_getBalance) into a single HTTP request to an endpoint. This significantly reduces network overhead and latency compared to sending requests individually. Noted that the limit of the batch number is 1000. Any request with more batch calls will be rejected.
Key Considerations:
Order: Responses are returned in the exact same order as the requests.
Independent: Requests execute separately; one failing doesn't stop the others. You must check each response for errors.
Limits: Nodes enforce limits on batch size and computational complexity. Exceeding these will cause errors.
Restrictions for Different Endpoint Types
In order to better serve different types of users and ensure the healthy and efficient operation of BlockPI RPC service network, we have implemented different restrictions on various types of endpoints. If a user triggers any of these restrictions, the system will return an error. The following table outlines these limitations:
Public
Not support WS/WSS
N/A
Public
Not support Debug_* and Trace_*
-32000
Public
Maximum request rate: 10 qps
429
Public
Maximum response body size: 3 MB
-32000
Public
Maximum block range: 1024
-32602
Public
Maximum batch size: 10
-32000
Private
Maximum block range: 5000 with address input
-32602
Private
Only support “callTracer” and ”prestateTracer” for debug method
-32000
Private HTTPS
Maximum batch size: 1000
-32000
Private WSS
Do not support batch call
-32000
All HTTPS
Do not support subscribe and filter rpc method
-32000
Last updated
Was this helpful?