Ankr gần đây đã vượt qua 1 triệu yêu cầu RPC mỗi tháng, hỗ trợ một phần lớn lưu lượng Web3. Nền tảng RPC của họ hoạt động như một cầu nối giữa các ứng dụng và blockchain, xử lý các cuộc gọi từ ví, dApps, bot, indexer, rollup và nhiều hơn nữa. 🧵

Nhưng tất cả lưu lượng truy cập đó đến từ đâu? Các nguồn chính bao gồm: • Ví và giao diện người dùng • Các chỉ số / phân tích • Bot và hệ thống MEV • Rollups, L2s, cầu nối (các cuộc gọi chéo chuỗi nặng) • Một loạt các dApp nhỏ hơn trên hơn 80 mạng

Và những loại phương thức RPC nào đang được sử dụng nhiều? • Đọc thường xuyên: eth_call, eth_getBalance, eth_getBlockByNumber, v.v. • Truy vấn khoảng và nhật ký (eth_getLogs) và các cuộc gọi theo dõi/gỡ lỗi • Đăng ký qua WebSocket (đầu mới, nhật ký, giao dịch đang chờ) • Ghi (ví dụ: eth_sendRawTransaction) - ít hơn về số lượng nhưng quan trọng cho các hoạt động

Ankr mở rộng như thế nào để giữ mọi thứ nhanh chóng và đáng tin cậy? Một số chiến lược của họ: • Anycast toàn cầu + định tuyến khu vực để giảm độ trễ • Cân bằng tải nhận thức blockchain • Chuyên môn hóa đội tàu: tách biệt các đường đọc nóng, lưu trữ, theo dõi/gỡ lỗi, đường ghi Ankr • Định hình tỷ lệ, trọng số phương pháp & logic chuyển đổi được điều chỉnh theo ngữ nghĩa blockchain • Hạ tầng chuyên dụng cho các khách hàng doanh nghiệp có nhu cầu thông lượng cao

RPC là "vòi đọc/ghi" thiết yếu của Web3 - không có số dư, không có giao dịch hoán đổi, không có cầu nối nếu không có nó. Cột mốc một triệu yêu cầu của Ankr không phải là sự phóng đại; đó là tổng số mọi cuộc gọi đến trạng thái, nhật ký, đăng ký và giao dịch trên hơn 80 chuỗi. Để đạt được hiệu suất tối đa, các nhà phát triển nên sử dụng bộ nhớ đệm, gọi theo lô, gán vào các khu vực, tôn trọng trọng số phương thức và theo dõi mức sử dụng theo chuỗi/phương thức.