Giá RPC trở nên khó hiểu khi mỗi nhà cung cấp sử dụng một đơn vị hạch toán khác nhau.

Kế hoạch raw-request đếm trực tiếp số lần gọi. Kế hoạch request-unit chuyển đổi các lần gọi thành RU. Kế hoạch API-credit có thể áp dụng hệ số nhân cho chuỗi và sản phẩm. Kế hoạch compute-unit phân bổ nhiều đơn vị hơn cho các phương thức nặng hơn so với các tác vụ đọc nhẹ.

Điểm bắt đầu đúng là một workload đã được ghi nhận, không phải hạn mức quota của nhà cung cấp.

Tách riêng các lần đọc chuẩn, các lệnh gọi theo hợp đồng, biên lai, truy vấn nhật ký, trạng thái lưu trữ, các phương thức trace và cơ chế khôi phục luồng. Sau đó cộng thêm phần mức sử dụng được ẩn bởi tổng số yêu cầu hằng tháng:

• Thử lại sau khi bị timeout và giới hạn tốc độ

• Giám sát (polling) giao dịch bị lặp lại

• Tách theo phạm vi log (log-range splitting)

• Kết nối lại WebSocket và bù các khối bị bỏ lỡ (missed-block backfills)

• Lưu lượng chuyển sang nhà cung cấp dự phòng (failover)

Các cuộc gọi đến archive xứng đáng có ngân sách riêng vì trạng thái lịch sử có thể cần bộ nhớ và cơ chế định tuyến khác nhau. Các truy vấn log cũng cần một mô hình riêng vì một lần quét logic duy nhất có thể trở thành nhiều yêu cầu RPC khi dải block phải được chia nhỏ.

Cuối cùng, hãy tách mức tiêu thụ theo tháng khỏi công suất đỉnh. Năm triệu cuộc gọi được phân bổ đều trong một tháng và năm triệu cuộc gọi được dồn vào thời điểm gần một lần ra mắt không tạo ra cùng một yêu cầu hạ tầng.

So sánh toàn bộ bài toán kinh tế theo tháng: số lượng được bao gồm, phần vượt mức, thông lượng, quyền truy cập archive, các phương pháp nâng cao, tính dự phòng và thời gian kỹ sư.

Hướng dẫn đầy đủ của TokenToolHub:

https://tokentoolhub.com/rpc-pricing-explained/

#blockchain #Web3 #RPCInfra #CryptoInfrastructure #Developers